* [meta-raspberrypi] Problem with RPI_USE_U_BOOT with RaspberryPi4
@ 2022-01-12 1:57 Jean-Philippe Lebel
2022-01-12 8:59 ` AW: [yocto] " Matthias Klein
0 siblings, 1 reply; 8+ messages in thread
From: Jean-Philippe Lebel @ 2022-01-12 1:57 UTC (permalink / raw)
To: yocto
[-- Attachment #1: Type: text/plain, Size: 834 bytes --]
Hello,
I'm trying to create a simple image that uses the RPI_USE_U_BOOT option but the pi hangs with the rainbow image. I'm able to generate bootable images when not using the RPI_USE_U_BOOT option (but I need to use swupdate). I have the same problem with using the Hardknott branch, leading me to think the problem is not the layer but the way I use it.
For my last test, I used the latest meta-raspberrypi without any modification. In other words, I'm using the default/basic configuration.
the default local.conf file has been edited to add the following two lines at the end
MACHINE = 'raspberrypi4'
RPI_USE_U_BOOT = "1"
I'm building the image using
> bitbake core-image-base
And I'm burning the generated .wic image to my sd card.
What am I missing? Is there any other configuration I must do?
Thanks
[-- Attachment #2: Type: text/html, Size: 977 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread* AW: [yocto] [meta-raspberrypi] Problem with RPI_USE_U_BOOT with RaspberryPi4 2022-01-12 1:57 [meta-raspberrypi] Problem with RPI_USE_U_BOOT with RaspberryPi4 Jean-Philippe Lebel @ 2022-01-12 8:59 ` Matthias Klein 2022-01-12 13:37 ` Jean-Philippe Lebel 2022-01-12 20:37 ` Jean-Philippe Lebel 0 siblings, 2 replies; 8+ messages in thread From: Matthias Klein @ 2022-01-12 8:59 UTC (permalink / raw) To: jp, yocto [-- Attachment #1: Type: text/plain, Size: 777 bytes --] Hello Jean-Philippe, >I'm trying to create a simple image that uses the RPI_USE_U_BOOT option but the pi hangs with the rainbow image. I'm able to generate bootable images when not using the RPI_USE_U_BOOT option (but I need to use swupdate). >I have the same problem with using the Hardknott branch, leading me to think the problem is not the layer but the way I use it. For me the combination of raspberrypi4-64 machine, U-Boot and RAUC (instead of swupdate) works. I think the raspberrypi4 should also work (but haven't tested it). I built and tested my (Poky master branch based) image this morning: https://github.com/matthiasklein/meta-yocto-coffee-rpi I don't use HDMI output though, but a serial console (ENABLE_UART = "1"). Best regards, Matthias [-- Attachment #2: Type: text/html, Size: 2969 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [yocto] [meta-raspberrypi] Problem with RPI_USE_U_BOOT with RaspberryPi4 2022-01-12 8:59 ` AW: [yocto] " Matthias Klein @ 2022-01-12 13:37 ` Jean-Philippe Lebel 2022-01-12 20:37 ` Jean-Philippe Lebel 1 sibling, 0 replies; 8+ messages in thread From: Jean-Philippe Lebel @ 2022-01-12 13:37 UTC (permalink / raw) To: Matthias Klein; +Cc: yocto [-- Attachment #1: Type: text/plain, Size: 2313 bytes --] Thanks Matthias for your input. I have the same problem using the raspberrypi4-64 target. On my end, the mere fact of enabling RPI_USE_U_BOOT yields a non-bootable image. The image I generated/burned can be found here: https://www.dropbox.com/s/6glmmgtx0pcd06t/core-image-base-raspberrypi4-64-20220112004201.rootfs.wic.bz2?dl=0 Thanks a lot. ------------- Jean-Philippe Lebel, ing. MBA jp@lebel.pro http://www.lebel.pro cell: 418-931-3800 *AVIS IMPORTANT:* Ce courriel est strictement réservé à l'usage de la (des) personne(s) à qui il est adressé et peut contenir de l'information privilégiée et confidentielle. Toute divulgation, distribution, copie, ou autre utilisation de ce courriel par une autre personne est strictement prohibée. Si vous avez reçu ce courriel par erreur, veuillez s'il vous plaît communiquer immédiatement avec l'expéditeur et détruire le courriel sans en faire de copie sous quelque forme. *WARNING:* This e-mail contains confidential information intended only for the person(s) named above. If you are not the intended recipient you are hereby notified that any disclosure, copying, distribution, or any other use of this e-mail is strictly prohibited. If you have received this e-mail by mistake, please notify us immediately and destroy this e-mail without making any copy of any kind. On Wed, Jan 12, 2022 at 3:59 AM Matthias Klein <matthias.klein@optimeas.de> wrote: > Hello Jean-Philippe, > > > > >I'm trying to create a simple image that uses the RPI_USE_U_BOOT option > but the pi hangs with the rainbow image. I'm able to generate bootable > images when not using the RPI_USE_U_BOOT option (but I need to use > swupdate). > > >I have the same problem with using the Hardknott branch, leading me to > think the problem is not the layer but the way I use it. > > For me the combination of raspberrypi4-64 machine, U-Boot and RAUC > (instead of swupdate) works. > > I think the raspberrypi4 should also work (but haven't tested it). > > > > I built and tested my (Poky master branch based) image this morning: > https://github.com/matthiasklein/meta-yocto-coffee-rpi > > > > I don't use HDMI output though, but a serial console (ENABLE_UART = "1"). > > > > Best regards, > > Matthias > > > [-- Attachment #2: Type: text/html, Size: 4269 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [yocto] [meta-raspberrypi] Problem with RPI_USE_U_BOOT with RaspberryPi4 2022-01-12 8:59 ` AW: [yocto] " Matthias Klein 2022-01-12 13:37 ` Jean-Philippe Lebel @ 2022-01-12 20:37 ` Jean-Philippe Lebel 2022-01-12 21:45 ` Jerome Oufella 1 sibling, 1 reply; 8+ messages in thread From: Jean-Philippe Lebel @ 2022-01-12 20:37 UTC (permalink / raw) To: yocto [-- Attachment #1: Type: text/plain, Size: 1136 bytes --] For a reason I can't quite understand, everything stated working when I added ENABLE_UART = "1" Does anyone understand the relation between ENABLE_UART = "1" and RPI_USE_U_BOOT = "1" ? Thanks ------------- Jean-Philippe On Wed, Jan 12, 2022 at 3:59 AM Matthias Klein <matthias.klein@optimeas.de> wrote: > Hello Jean-Philippe, > > > > >I'm trying to create a simple image that uses the RPI_USE_U_BOOT option > but the pi hangs with the rainbow image. I'm able to generate bootable > images when not using the RPI_USE_U_BOOT option (but I need to use > swupdate). > > >I have the same problem with using the Hardknott branch, leading me to > think the problem is not the layer but the way I use it. > > For me the combination of raspberrypi4-64 machine, U-Boot and RAUC > (instead of swupdate) works. > > I think the raspberrypi4 should also work (but haven't tested it). > > > > I built and tested my (Poky master branch based) image this morning: > https://github.com/matthiasklein/meta-yocto-coffee-rpi > > > > I don't use HDMI output though, but a serial console (ENABLE_UART = "1"). > > > > Best regards, > > Matthias > > > [-- Attachment #2: Type: text/html, Size: 2472 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [yocto] [meta-raspberrypi] Problem with RPI_USE_U_BOOT with RaspberryPi4 2022-01-12 20:37 ` Jean-Philippe Lebel @ 2022-01-12 21:45 ` Jerome Oufella 2022-01-14 15:39 ` Jean-Philippe Lebel 0 siblings, 1 reply; 8+ messages in thread From: Jerome Oufella @ 2022-01-12 21:45 UTC (permalink / raw) To: Jean-Philippe Lebel; +Cc: yocto On Jan 12, 2022, at 3:37 PM, Jean-Philippe Lebel wrote: > For a reason I can't quite understand, everything stated working when I added > ENABLE_UART = "1" > > Does anyone understand the relation between ENABLE_UART = "1" and RPI_USE_U_BOOT > = "1" ? > > Thanks > > ------------- > Jean-Philippe The documentation mentions a relationship between enable_uart and (lower) core frequency on some hardware variants - could there be a side-effect (if yes, maybe gpu_freq/arm_freq could play a factor) ? Jerome ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [yocto] [meta-raspberrypi] Problem with RPI_USE_U_BOOT with RaspberryPi4 2022-01-12 21:45 ` Jerome Oufella @ 2022-01-14 15:39 ` Jean-Philippe Lebel 2022-01-14 20:40 ` Marc Ferland 0 siblings, 1 reply; 8+ messages in thread From: Jean-Philippe Lebel @ 2022-01-14 15:39 UTC (permalink / raw) To: yocto [-- Attachment #1: Type: text/plain, Size: 4063 bytes --] I finally received my UART cable, giving me more details about where the boot sequence fails. Just a quick summary of my tests - Enabling UART does indeed "fix" the issue when working from the meta-raspberrypi AND yocto master. - Enabling UART has no impact when working from the meta-raspberrypi and yocto hardknott branch (which I need to support) - image doesn't boot - Backporting the meta-raspberrypi master branch to hardknott does NOT fix the problem. Here is the uboot log (failing). U-Boot 2021.01 (Jan 11 2021 - 18:11:43 +0000) DRAM: 1.9 GiB RPI 4 Model B (0xb03114) MMC: mmcnr@7e300000: 1, emmc2@7e340000: 0 *Loading Environment from FAT... ** No partition table - mmc 0 *** In: serial Out: serial Err: serial Net: eth0: ethernet@7d580000 PCIe BRCM: link up, 5.0 Gbps x1 (SSC) starting USB... Bus xhci_pci: Register 5000420 NbrPorts 5 Starting the controller USB XHCI 1.00 scanning bus xhci_pci for devices... 2 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device ** No partition table - mmc 0 ** Card did not respond to voltage select! : -110 Here is a normal uboot sequence U-Boot 2021.10 (Oct 04 2021 - 15:09:26 +0000) DRAM: 1.9 GiB RPI 4 Model B (0xb03114) MMC: mmcnr@7e300000: 1, mmc@7e340000: 0 *Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1... In: serial* Out: vidconsole Err: vidconsole Net: eth0: ethernet@7d580000 PCIe BRCM: link up, 5.0 Gbps x1 (SSC) starting USB... Bus xhci_pci: Register 5000420 NbrPorts 5 Starting the controller USB XHCI 1.00 scanning bus xhci_pci for devices... 2 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot.scr 262 bytes read in 6 ms (42 KiB/s) ## Executing script at 02400000 23202304 bytes read in 997 ms (22.2 MiB/s) Saving Environment to FAT... OK Moving Image from 0x80000 to 0x200000, end=1960000 ## Flattened Device Tree blob at 2eff3600 Booting using the fdt blob at 0x2eff3600 Using Device Tree in place at 000000002eff3600, end 000000002f002f13 Starting kernel ... Basically, the failing Uboot can't find the partition table. Any idea why? Thanks ------------- Jean-Philippe Lebel, ing. MBA *AVIS IMPORTANT:* Ce courriel est strictement réservé à l'usage de la (des) personne(s) à qui il est adressé et peut contenir de l'information privilégiée et confidentielle. Toute divulgation, distribution, copie, ou autre utilisation de ce courriel par une autre personne est strictement prohibée. Si vous avez reçu ce courriel par erreur, veuillez s'il vous plaît communiquer immédiatement avec l'expéditeur et détruire le courriel sans en faire de copie sous quelque forme. *WARNING:* This e-mail contains confidential information intended only for the person(s) named above. If you are not the intended recipient you are hereby notified that any disclosure, copying, distribution, or any other use of this e-mail is strictly prohibited. If you have received this e-mail by mistake, please notify us immediately and destroy this e-mail without making any copy of any kind. On Wed, Jan 12, 2022 at 4:45 PM Jerome Oufella < jerome.oufella@savoirfairelinux.com> wrote: > On Jan 12, 2022, at 3:37 PM, Jean-Philippe Lebel wrote: > > > For a reason I can't quite understand, everything stated working when I > added > > ENABLE_UART = "1" > > > > Does anyone understand the relation between ENABLE_UART = "1" and > RPI_USE_U_BOOT > > = "1" ? > > > > Thanks > > > > ------------- > > Jean-Philippe > > The documentation mentions a relationship between enable_uart and > (lower) core frequency on some hardware variants - could there be a > side-effect (if yes, maybe gpu_freq/arm_freq could play a factor) ? > > Jerome > [-- Attachment #2: Type: text/html, Size: 5650 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [yocto] [meta-raspberrypi] Problem with RPI_USE_U_BOOT with RaspberryPi4 2022-01-14 15:39 ` Jean-Philippe Lebel @ 2022-01-14 20:40 ` Marc Ferland 2022-01-14 21:02 ` Jean-Philippe Lebel 0 siblings, 1 reply; 8+ messages in thread From: Marc Ferland @ 2022-01-14 20:40 UTC (permalink / raw) To: Jean-Philippe Lebel; +Cc: yocto On Fri, Jan 14, 2022 at 10:39 AM Jean-Philippe Lebel <jp@lebel.pro> wrote: > > I finally received my UART cable, giving me more details about where the boot sequence fails. > > Just a quick summary of my tests > - Enabling UART does indeed "fix" the issue when working from the meta-raspberrypi AND yocto master. > - Enabling UART has no impact when working from the meta-raspberrypi and yocto hardknott branch (which I need to support) - image doesn't boot > - Backporting the meta-raspberrypi master branch to hardknott does NOT fix the problem. > > Here is the uboot log (failing). > > U-Boot 2021.01 (Jan 11 2021 - 18:11:43 +0000) > > DRAM: 1.9 GiB > RPI 4 Model B (0xb03114) > MMC: mmcnr@7e300000: 1, emmc2@7e340000: 0 > Loading Environment from FAT... ** No partition table - mmc 0 ** > In: serial > Out: serial > Err: serial > Net: eth0: ethernet@7d580000 > PCIe BRCM: link up, 5.0 Gbps x1 (SSC) > starting USB... > Bus xhci_pci: Register 5000420 NbrPorts 5 > Starting the controller > USB XHCI 1.00 > scanning bus xhci_pci for devices... 2 USB Device(s) found > scanning usb for storage devices... 0 Storage Device(s) found > Hit any key to stop autoboot: 0 > switch to partitions #0, OK > mmc0 is current device > ** No partition table - mmc 0 ** > Card did not respond to voltage select! : -110 > > Here is a normal uboot sequence > > U-Boot 2021.10 (Oct 04 2021 - 15:09:26 +0000) > > DRAM: 1.9 GiB > RPI 4 Model B (0xb03114) > MMC: mmcnr@7e300000: 1, mmc@7e340000: 0 > Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1... In: serial > Out: vidconsole > Err: vidconsole > Net: eth0: ethernet@7d580000 > PCIe BRCM: link up, 5.0 Gbps x1 (SSC) > starting USB... > Bus xhci_pci: Register 5000420 NbrPorts 5 > Starting the controller > USB XHCI 1.00 > scanning bus xhci_pci for devices... 2 USB Device(s) found > scanning usb for storage devices... 0 Storage Device(s) found > Hit any key to stop autoboot: 0 > switch to partitions #0, OK > mmc0 is current device > Scanning mmc 0:1... > Found U-Boot script /boot.scr > 262 bytes read in 6 ms (42 KiB/s) > ## Executing script at 02400000 > 23202304 bytes read in 997 ms (22.2 MiB/s) > Saving Environment to FAT... OK > Moving Image from 0x80000 to 0x200000, end=1960000 > ## Flattened Device Tree blob at 2eff3600 > Booting using the fdt blob at 0x2eff3600 > Using Device Tree in place at 000000002eff3600, end 000000002f002f13 > > Starting kernel ... > > Basically, the failing Uboot can't find the partition table. > Well is there a partition table? Can you share what you are doing to flash your uSD? Maybe it's just some manipulation error. Marc ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [yocto] [meta-raspberrypi] Problem with RPI_USE_U_BOOT with RaspberryPi4 2022-01-14 20:40 ` Marc Ferland @ 2022-01-14 21:02 ` Jean-Philippe Lebel 0 siblings, 0 replies; 8+ messages in thread From: Jean-Philippe Lebel @ 2022-01-14 21:02 UTC (permalink / raw) To: Marc Ferland; +Cc: yocto [-- Attachment #1: Type: text/plain, Size: 4541 bytes --] Hello Marc, I doubt this is a manipulation issue (at least in regards to burning the image). meta-raspberrypi master, yocto master -> works (core-image-base, stock, no modification beside RPI_USE_U_BOOT="1") meta-raspberrypi hardknott, yocto hardknott -> doesn't work (core-image-base, stock, no modification beside RPI_USE_U_BOOT="1") That being said, I've inspected both the working image and the non-working one and they look very similar (files and structure). I will take a closer look at the format. Thanks ------------- Jean-Philippe Lebel, ing. MBA jp@lebel.pro http://www.lebel.pro cell: 418-931-3800 *AVIS IMPORTANT:* Ce courriel est strictement réservé à l'usage de la (des) personne(s) à qui il est adressé et peut contenir de l'information privilégiée et confidentielle. Toute divulgation, distribution, copie, ou autre utilisation de ce courriel par une autre personne est strictement prohibée. Si vous avez reçu ce courriel par erreur, veuillez s'il vous plaît communiquer immédiatement avec l'expéditeur et détruire le courriel sans en faire de copie sous quelque forme. *WARNING:* This e-mail contains confidential information intended only for the person(s) named above. If you are not the intended recipient you are hereby notified that any disclosure, copying, distribution, or any other use of this e-mail is strictly prohibited. If you have received this e-mail by mistake, please notify us immediately and destroy this e-mail without making any copy of any kind. On Fri, Jan 14, 2022 at 3:40 PM Marc Ferland <marc.ferland@gmail.com> wrote: > On Fri, Jan 14, 2022 at 10:39 AM Jean-Philippe Lebel <jp@lebel.pro> wrote: > > > > I finally received my UART cable, giving me more details about where the > boot sequence fails. > > > > Just a quick summary of my tests > > - Enabling UART does indeed "fix" the issue when working from the > meta-raspberrypi AND yocto master. > > - Enabling UART has no impact when working from the meta-raspberrypi and > yocto hardknott branch (which I need to support) - image doesn't boot > > - Backporting the meta-raspberrypi master branch to hardknott does NOT > fix the problem. > > > > Here is the uboot log (failing). > > > > U-Boot 2021.01 (Jan 11 2021 - 18:11:43 +0000) > > > > DRAM: 1.9 GiB > > RPI 4 Model B (0xb03114) > > MMC: mmcnr@7e300000: 1, emmc2@7e340000: 0 > > Loading Environment from FAT... ** No partition table - mmc 0 ** > > In: serial > > Out: serial > > Err: serial > > Net: eth0: ethernet@7d580000 > > PCIe BRCM: link up, 5.0 Gbps x1 (SSC) > > starting USB... > > Bus xhci_pci: Register 5000420 NbrPorts 5 > > Starting the controller > > USB XHCI 1.00 > > scanning bus xhci_pci for devices... 2 USB Device(s) found > > scanning usb for storage devices... 0 Storage Device(s) found > > Hit any key to stop autoboot: 0 > > switch to partitions #0, OK > > mmc0 is current device > > ** No partition table - mmc 0 ** > > Card did not respond to voltage select! : -110 > > > > Here is a normal uboot sequence > > > > U-Boot 2021.10 (Oct 04 2021 - 15:09:26 +0000) > > > > DRAM: 1.9 GiB > > RPI 4 Model B (0xb03114) > > MMC: mmcnr@7e300000: 1, mmc@7e340000: 0 > > Loading Environment from FAT... Unable to read "uboot.env" from > mmc0:1... In: serial > > Out: vidconsole > > Err: vidconsole > > Net: eth0: ethernet@7d580000 > > PCIe BRCM: link up, 5.0 Gbps x1 (SSC) > > starting USB... > > Bus xhci_pci: Register 5000420 NbrPorts 5 > > Starting the controller > > USB XHCI 1.00 > > scanning bus xhci_pci for devices... 2 USB Device(s) found > > scanning usb for storage devices... 0 Storage Device(s) found > > Hit any key to stop autoboot: 0 > > switch to partitions #0, OK > > mmc0 is current device > > Scanning mmc 0:1... > > Found U-Boot script /boot.scr > > 262 bytes read in 6 ms (42 KiB/s) > > ## Executing script at 02400000 > > 23202304 bytes read in 997 ms (22.2 MiB/s) > > Saving Environment to FAT... OK > > Moving Image from 0x80000 to 0x200000, end=1960000 > > ## Flattened Device Tree blob at 2eff3600 > > Booting using the fdt blob at 0x2eff3600 > > Using Device Tree in place at 000000002eff3600, end 000000002f002f13 > > > > Starting kernel ... > > > > Basically, the failing Uboot can't find the partition table. > > > > Well is there a partition table? Can you share what you are doing to > flash your uSD? Maybe it's just some manipulation error. > > Marc > [-- Attachment #2: Type: text/html, Size: 6251 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2022-01-14 21:02 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-01-12 1:57 [meta-raspberrypi] Problem with RPI_USE_U_BOOT with RaspberryPi4 Jean-Philippe Lebel 2022-01-12 8:59 ` AW: [yocto] " Matthias Klein 2022-01-12 13:37 ` Jean-Philippe Lebel 2022-01-12 20:37 ` Jean-Philippe Lebel 2022-01-12 21:45 ` Jerome Oufella 2022-01-14 15:39 ` Jean-Philippe Lebel 2022-01-14 20:40 ` Marc Ferland 2022-01-14 21:02 ` Jean-Philippe Lebel
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.