Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot it

On 2022-Sep-27, at 21:51, bob prohaska <[email protected]> wrote:

> On Tue, Sep 27, 2022 at 07:25:09PM -0700, Mark Millard wrote:
>> 
>> Beyond enable_uart=1 there is, quoting from:
> [snip] 
>> "uart_2ndstage=1" 
> Also added to config.txt
> 
>> 
>> For the current purposes, dtdebug=1 probably does
>> not provide anything of interest. But it is
>> available to enable as well.
> 
> Added to config.txt as well. 
> 
> In general there isn't much additional output from u-boot. 
> On a successful try I see what begins as (I think) bootcode.bin output:
> .....
> MESS:00:00:24.909927:0: Device tree loaded to 0x4000 (size 0x7374)
> MESS:00:00:24.918100:0: uart: Set PL011 baud rate to 103448.300000 Hz
> MESS:00:00:24.924351:0: uart: Baud rate change done...
> MESS:00:00:24.927765:0: uart: Baud rate change done...
> 
> Next u-boot takes over
> 
> U-Boot 2022.04 (Sep 27 2022 - 20:04:31 -0700)

There are almost 2 hours between 20:04:31 -0700
and the 21:51 when your Email arrived.

None of the output that I reported as showing up
shows in your report. YOu can look at:

https://lists.freebsd.org/archives/freebsd-arm/2022-September/001804.html

to see the U-Boot output that I got (via use in
an RPi4B).

Are you sure that the u-boot.bin on the msdosfs
has the new content?

> DRAM:  948 MiB
> RPI 3 Model B (0xa02082)
> Core:  69 devices, 10 uclasses, devicetree: board
> MMC:   mmc@7e300000: 2
> Loading Environment from FAT... In:    serial
> Out:   vidconsole
> Err:   vidconsole
> Net:   No ethernet found.
> starting USB...
> Bus usb@7e980000: USB DWC2
> scanning bus usb@7e980000 for devices... 6 USB Device(s) found
>       scanning usb for storage devices... 1 Storage Device(s) found
> Hit any key to stop autoboot:  0 
> MMC Device 0 not found
> no mmc device at slot 0
> MMC Device 1 not found
> no mmc device at slot 1
> Card did not respond to voltage select! : -110
> 
> Device 0: Vendor: SABRENT  Rev: 1214 Prod: 
>            Type: Hard Disk
>            Capacity: 953869.7 MB = 931.5 GB (1953525168 x 512)
> ... is now current device
> Scanning usb 0:1...
> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
> Card did not respond to voltage select! : -110
> Scanning disk [email protected]...
> Disk [email protected] not ready
> Scanning disk usb_mass_storage.lun0...
> Found 3 disks
> Missing RNG device for EFI_RNG_PROTOCOL
> No EFI system partition
> BootOrder not defined
> EFI boot manager: Cannot load any image
> Found EFI removable media binary efi/boot/bootaa64.efi
> 1262604 bytes read in 38 ms (31.7 MiB/s)
> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
> Booting /efi\boot\bootaa64.efi
> 
> But, that's it. Is that what one would expect? 

No.

> Failed attempts are more terse:
> 
> U-Boot 2022.04 (Sep 27 2022 - 20:04:31 -0700)
> 
> DRAM:  948 MiB
> RPI 3 Model B (0xa02082)
> Core:  69 devices, 10 uclasses, devicetree: board
> MMC:   mmc@7e300000: 2
> Loading Environment from FAT... In:    serial
> Out:   vidconsole
> Err:   vidconsole
> Net:   No ethernet found.
> starting USB...
> Bus usb@7e980000: USB DWC2
> scanning bus usb@7e980000 for devices... 6 USB Device(s) found
>       scanning usb for storage devices... 0 Storage Device(s) found
> Hit any key to stop autoboot:  0 
> MMC Device 0 not found
> no mmc device at slot 0
> MMC Device 1 not found
> no mmc device at slot 1
> Card did not respond to voltage select! : -110
> 
> Device 0: unknown device
> Waiting for Ethernet connection... done. 
> 
> I imagined u-boot would be more talkative,
> similar to the MESS..... output from bootcode.bin

Look at:

https://lists.freebsd.org/archives/freebsd-arm/2022-September/001804.html

for some of what to expect.

> The output from make reports
> ===>  Applying extra patch patches for u-boot-rpi-arm64-2022.04_1 from /usr/ports/sysutils/u-boot-rpi-arm64/files/
> No such line 209 in input file, ignoring

That is the same 209 reference from patch-include_configs_rpi.h
use that we exchanged about before. patch deals with finding the
match at the new line number (that as sufficiently close to the
original line number): there is no line 209 or 210 and the
matching text is at a smaller line number.

> Strangely, it doesn't report which patch didn't work.
> The directory contains
> patch-common_usb.c        patch-common_usb__storage.c  patch-lib_efi__loader_efi__console.c
> patch-common_usb__hub.c   patch-include_configs_rpi.h  rpi_arm64_fragment
> 
> No idea whether it matters. 
> 

By itself, it is just an informational message and
is expected.

===
Mark Millard
marklmi at yahoo.com