Re: RPI5 16GB panic on boot [.dtb files]

On Feb 3, 2025, at 21:48, Mark Millard <[email protected]> wrote:

> On Feb 3, 2025, at 12:23, Mark Millard <[email protected]> wrote:
> 
>> This note just reports on the list of bcm2712*.dtb files
>> on a normal/modern RaspiOS64 boot media (my abbreviation).
>> 
>> # ls -lodT /mnt/bcm2712*.dtb
>> -rwxr-xr-x  1 root wheel uarch 81163 Jan 27 17:19:54 2025 /mnt/bcm2712-rpi-5-b.dtb
>> -rwxr-xr-x  1 root wheel uarch 81119 Jan 27 17:19:54 2025 /mnt/bcm2712-rpi-500.dtb
>> -rwxr-xr-x  1 root wheel uarch 81620 Jan 27 17:19:54 2025 /mnt/bcm2712-rpi-cm5-cm4io.dtb
>> -rwxr-xr-x  1 root wheel uarch 81682 Jan 27 17:19:54 2025 /mnt/bcm2712-rpi-cm5-cm5io.dtb
>> -rwxr-xr-x  1 root wheel uarch 81661 Jan 27 17:19:54 2025 /mnt/bcm2712-rpi-cm5l-cm4io.dtb
>> -rwxr-xr-x  1 root wheel uarch 81723 Jan 27 17:19:54 2025 /mnt/bcm2712-rpi-cm5l-cm5io.dtb
>> -rwxr-xr-x  1 root wheel uarch 81167 Jan 27 17:19:54 2025 /mnt/bcm2712d0-rpi-5-b.dtb
>> 
>> The EDK2 implementation is set up based on just one of those, actually
>> likely and older vintage by content instead: bcm2712-rpi-5-b.dtb
>> 
>> My guess is that your new 16 GiByte RPi5B is intended to be
>> used with the modern content of: bcm2712d0-rpi-5-b.dtb
>> 
>> Booting with the RPi* config.txt also indicating:
>> 
>> enable_uart=1
>> uart_2ndstage=1
>> dtdebug=1
>> disable_commandline_tags=1
>> 
>> likely would answer that: it would likely report on what .dtb
>> file the firmware tries to find first, for example.
>> 
>> I also expect that the EDK2 would need to be updated to also
>> handle some of the various differences, whatever they are.
>> 
>> I'll remind that the live .dtb can have adjustments made by
>> the RPi* firmware after the .dtb is loaded by the firmware.
>> 
>> My classic techinque of discovering what is in the live Device
>> Tree provided to the FreeBSD loader is via having U-Boot list
>> the content of the Device Tree it is set up to hand over. (I
>> do this rarely and so have to re-figure-out the details each
>> time.)
> 
> I did an experiment with a FreeBSD U-Boot context after
> having copied over the bcm2712-*.dtb files to the
> 2025-Jan-30's stable/14 snapshot's msdosfs .

I forgot to specify some likely-important context
for the above: I set up an microsd-card-only boot
media context. No presumption of USB access or the
like.

So the 2025-Jan-30 stable/14 snapshot had been
dd'd to the microsd card before I added the
bcm2712-*.dtb files to the msdosfs on the
microsd card.

This was inspired by what I read about 2024.07 of
U-Boot being able to handle such a limited context.
The 2025-Jan-30 stable/14 snapshot is 2024.07 of
U-Boot based and uses a def_config that uses the
RPi firmware supplied *.dtb file instead of one of
the U-Boot embedded ones.

> 
> The boot looks to have been stopped by lack of a
> "armstub8-2712.bin" so not having the right implmentation
> in place for later stages, like u-boot.bin :
> 
> . . .
>  6.64 BMD "armstub8-2712.bin" not found
>  6.65 fs_open: 'armstub8-2712.bin' 
>  6.68 Loading 'u-boot.bin' to 0x00000000 offset 0x200000
>  6.04 Read u-boot.bin bytes   630976 hnd 0x30e
> . . .
> 
> The existing armstub8-gic.bin may well be insufficient
> or inappropriate for an RPi5. Note that the config.txt :
> 
> # more /mnt/config.txt 
> [all]
> arm_64bit=1
> dtparam=audio=on,i2c_arm=on,spi=on
> dtoverlay=mmc
> dtoverlay=disable-bt
> device_tree_address=0x4000
> kernel=u-boot.bin
> 
> [pi4]
> hdmi_safe=1
> armstub=armstub8-gic.bin
> 
> 
> leaves the armstub name at the default for an rpi5.
> Now we know the naming convention for the RPi5 (and
> related): armstub8-2712.bin
> 

This problem prevented U-Boot from getting to a stage
were I could have it stop at U-Boot's prompt. (Such
might not be the only thing at issue but just the
first problem hit.)


===
Mark Millard
marklmi at yahoo.com