Re: [meta-raspberrypi] Problem with RPI_USE_U_BOOT with RaspberryPi4


Jean-Philippe Lebel
 

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@...> 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

Join yocto@lists.yoctoproject.org to automatically receive all group messages.