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

From: Mark Millard <marklmi_at_yahoo.com>
Date: Wed, 28 Sep 2022 17:57:41 UTC
On 2022-Sep-28, at 10:28, bob prohaska <fbsd@www.zefox.net> wrote:

> [removed Klaus from cc, added freebsd-uboot@freebsd.org] 
> On Tue, Sep 27, 2022 at 10:45:36PM -0700, Mark Millard wrote:
>> 
>> There are almost 2 hours between 20:04:31 -0700
>> and the 21:51 when your Email arrived.
>> 
> 
> The delay between compile and email seems ok. 
> 
>> 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?
>> 
> 
> I'm still doing something wrong, but haven't found it yet. 

If the patch files are in place for what poudriere uses
for /usr/ports/sysutils/u-boot-rpi-arm64/ , poudriere
based port building should then work.

Is there a log file of the port build output that you
could post? For manual make activity one can use something
like the script command to also have the output sent out
to a log file.

> After cleaninug up old files and re-running make and make 
> install, find locates:

The output during the make would be a good cross check
on what is in the build and if the patches are being
applied to a fresh extraction of the source code.

> root@pelorus:~ # sum /boot/msdos/u-boot.bin
> 4933 570 /boot/msdos/u-boot.bin

Those 570's indicate the smaller file size. The larger
size from being a debug build is likely to be more like
587.

(Your and my checksums would be unlikely to match
due to details of build environment differences
that control some aspects of code generation. But
the sizes should be similar.)

The sum output, of itself, does not show file timestamps
and more detailed size figures that would also be evidence.

> root@pelorus:~ # sum /usr/local/share/u-boot/u-boot-rpi-arm64/u-boot.bin
> 4933 570 /usr/local/share/u-boot/u-boot-rpi-arm64/u-boot.bin
> 
> root@pelorus:~ # sum /usr/ports/sysutils/u-boot-rpi-arm64/work/u-boot-2022.04/u-boot.bin
> 4933 570 /usr/ports/sysutils/u-boot-rpi-arm64/work/u-boot-2022.04/u-boot.bin
> 
> root@pelorus:~ # sum /usr/ports/sysutils/u-boot-rpi-arm64/work/stage/usr/local/share/u-boot/u-boot-rpi-arm64/u-boot.bin
> 4933 570 /usr/ports/sysutils/u-boot-rpi-arm64/work/stage/usr/local/share/u-boot/u-boot-rpi-arm64/u-boot.bin
> 
> At the same time:
> root@pelorus:~ # ls /usr/ports/sysutils/u-boot-rpi-arm64/files
> 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

Did the build sequence re-extract the source code and
apply all the patch files to the result?

> There' still no additional output from u-boot,

As expected, given the u-boot.bin is too small to be
a debug build. Until you produce the bigger variant
of the file, there will be no debug or other logging.
Probably no reason to even copy over the smaller file
variants to the boot media.

> although with enough
> re-trying the machine still boots: 
> 
> U-Boot 2022.04 (Sep 28 2022 - 09:02:56 -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... 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)
> [normal boot follows]
> 
> A file copying error on my part seems most likely. I'll try again
> this afternoon.

===
Mark Millard
marklmi at yahoo.com