Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot it
Date: Mon, 26 Sep 2022 04:47:55 UTC
On 2022-Sep-25, at 18:04, bob prohaska <fbsd@www.zefox.net> wrote: > On Sun, Sep 25, 2022 at 03:57:34PM -0700, Mark Millard wrote: >> On 2022-Sep-25, at 12:34, bob prohaska <fbsd@www.zefox.net> wrote: >>> >>> . . . >>> >>> IIRC I did try replacing the Sabrent enclosure with the Startech >>> enclosure, which worked and seemed to implicate the Sabrent as >>> the culprit. Thus my interest in u-boot debug information. >> >> Looking at https://u-boot.readthedocs.io/en/latest/develop/logging.html >> it appears the logging availability has to be enabled at compile time: >> >> QUOTE >> Enabling logging >> >> The following options are used to enable logging >> at compile time: >> >> ??? CONFIG_LOG - Enables the logging system >> ??? CONFIG_LOG_MAX_LEVEL - Max log level to >> build (anything higher is compiled out) >> ??? CONFIG_LOG_CONSOLE - Enable writing log >> records to the console >> >> If CONFIG_LOG is not set, then no logging will be available. >> >> The above have SPL and TPL versions also, e.g. >> CONFIG_SPL_LOG_MAX_LEVEL and CONFIG_TPL_LOG_MAX_LEVEL. >> >> If logging is disabled, the default behaviour is to output >> any message at level LOGL_INFO and below. If logging is >> disabled and DEBUG is defined (at the very top of a C file) >> then any message at LOGL_DEBUG will be written. >> END QUOTE >> > > I looked at the page but didn't understand where/how to set > those parameters. Do they go in a configuration or Makefile > somewhere? I tried using > setenv CONFIG_LOG 1 > setenv CONFIG_LOG_CONSOLE 1 > setenv CONFIG_LOG_MAX_LEVEL 4 > > [The numbers were guessed at] > > All showed up in an env command, but the the resulting u-boot.bin > executable did not change size and behaves as before. It may be that they could go someplace in the same file that u-boot-rpi-arm64/files/patch-include_configs_rpi.h patches. I'd have to go exploring to find out. I'll note that: https://github.com/u-boot/u-boot/blob/master/include/configs/rpi.h shows it #defines some other CONFIG_... names, including the one that my existing patch adjusts ( CONFIG_EXTRA_ENV_SETTINGS ). This is at least suggestive. But it may be some other .h file would have to be used instead. Going in a different direction: Having the RPi* firmware and U-Boot load from a microsd card but the EFI material from the USB media likely would do you no good. U-Boot would still have to get the USB media working for its activity in order for U-Boot to find and load the EFI material that is on the USB media. It is the same problem again. Side Note: I actually boot the RPi3B that way. Note the "efi_disabled" below that prevents trying to boot FreeBSD's EFI material from the microsd card. Instead it finds and uses the EFI material on the USB media I use and EFI in turn finds the kernel on the same media as the EFI material (so the USB media). # mount -onoatime -tmsdosfs /dev/mmcsd0s1 /mnt # ls -Tld /mnt/* -rwxr-xr-x 1 root wheel 18693 Aug 5 04:11:18 2021 /mnt/COPYING.linux -rwxr-xr-x 1 root wheel 1594 Aug 5 04:11:18 2021 /mnt/LICENCE.broadcom -rwxr-xr-x 1 root wheel 240 Apr 20 19:18:14 2022 /mnt/README -rwxr-xr-x 1 root wheel 5888 Apr 20 19:25:22 2022 /mnt/armstub8-gic.bin -rwxr-xr-x 1 root wheel 5888 Apr 20 19:25:22 2022 /mnt/armstub8.bin -rwxr-xr-x 1 root wheel 27425 Aug 5 04:11:18 2021 /mnt/bcm2710-rpi-2-b.dtb -rwxr-xr-x 1 root wheel 29542 Aug 5 04:11:18 2021 /mnt/bcm2710-rpi-3-b-plus.dtb -rwxr-xr-x 1 root wheel 28923 Aug 5 04:11:18 2021 /mnt/bcm2710-rpi-3-b.dtb -rwxr-xr-x 1 root wheel 27421 Aug 5 04:11:18 2021 /mnt/bcm2710-rpi-cm3.dtb -rwxr-xr-x 1 root wheel 49825 Aug 5 04:11:18 2021 /mnt/bcm2711-rpi-4-b.dtb -rwxr-xr-x 1 root wheel 49821 Aug 5 04:11:18 2021 /mnt/bcm2711-rpi-400.dtb -rwxr-xr-x 1 root wheel 50499 Aug 5 04:11:18 2021 /mnt/bcm2711-rpi-cm4.dtb -rwxr-xr-x 1 root wheel 52456 Aug 5 04:11:18 2021 /mnt/bootcode.bin -rwxr-xr-x 1 root wheel 968 Sep 25 12:49:00 2022 /mnt/config.txt drwxr-xr-x 1 root wheel 32768 Apr 9 01:06:08 2021 /mnt/efi_disabled -rwxr-xr-x 1 root wheel 7278 Aug 5 04:11:18 2021 /mnt/fixup.dat -rwxr-xr-x 1 root wheel 5407 Aug 5 04:11:18 2021 /mnt/fixup4.dat -rwxr-xr-x 1 root wheel 3211 Aug 5 04:11:18 2021 /mnt/fixup4cd.dat -rwxr-xr-x 1 root wheel 8416 Aug 5 04:11:18 2021 /mnt/fixup4db.dat -rwxr-xr-x 1 root wheel 8418 Aug 5 04:11:18 2021 /mnt/fixup4x.dat -rwxr-xr-x 1 root wheel 3211 Aug 5 04:11:18 2021 /mnt/fixup_cd.dat -rwxr-xr-x 1 root wheel 10262 Aug 5 04:11:18 2021 /mnt/fixup_db.dat -rwxr-xr-x 1 root wheel 10262 Aug 5 04:11:18 2021 /mnt/fixup_x.dat drwxr-xr-x 1 root wheel 32768 Aug 5 04:11:18 2021 /mnt/overlays -rwxr-xr-x 1 root wheel 2959904 Aug 5 04:11:18 2021 /mnt/start.elf -rwxr-xr-x 1 root wheel 2235712 Aug 5 04:11:18 2021 /mnt/start4.elf -rwxr-xr-x 1 root wheel 799964 Aug 5 04:11:18 2021 /mnt/start4cd.elf -rwxr-xr-x 1 root wheel 3731528 Aug 5 04:11:18 2021 /mnt/start4db.elf -rwxr-xr-x 1 root wheel 2987720 Aug 5 04:11:18 2021 /mnt/start4x.elf -rwxr-xr-x 1 root wheel 799964 Aug 5 04:11:18 2021 /mnt/start_cd.elf -rwxr-xr-x 1 root wheel 4803496 Aug 5 04:11:18 2021 /mnt/start_db.elf -rwxr-xr-x 1 root wheel 3711432 Aug 5 04:11:18 2021 /mnt/start_x.elf -rwxr-xr-x 1 root wheel 0 Apr 24 03:58:58 2022 /mnt/timeout -rwxr-xr-x 1 root wheel 582752 Apr 22 14:56:24 2022 /mnt/u-boot.bin -rwxr-xr-x 1 root wheel 582752 Apr 22 13:14:58 2022 /mnt/u-boot.bin.2022.04.arm64 The above does not have FreeBSD present and has made the EFI material on the microsd card be not-found (via using the efi_disabled directory name instead). This leads U-Boot to find the EFI material on the USB media instead --where it has the normal path related names. Note: Mostly I use the most recent RPi* firmware that FreeBSD does not mishandle for the 3 configurations of RPi*'s that I have access to to test. I also use my patched U-Boot build because of an issue with the USB media that I use needing more time than normal for something. For any later RPi* dtb set that I've tried, FreeBSD crashes via use of a nullptr (plus a small offset, as I remember). It has been a while since I've checked any new dtb vintages. I also add timeout, needed or not. config.txt is my variant as well. (FreeBSD mishandles the dtb's by presuming that in the order it processes the dtb material that there will be no references before definitions, an order that dtb's are not required to follow. When FreeBSD processes a reference before it has seen the definition for what is referenced, it uses the nullptr that it has not replaced yet.) === Mark Millard marklmi at yahoo.com