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

On 2022-Oct-4, at 01:25, Mark Millard <[email protected]> wrote:

> I found a configuration that gets the RPi3 EDK2 and FreeBSD
> combination to have the serial console working. You can try
> booting and operating via the RPi3 EDK2 UEFI materials.
> 
> However, microsd cards should still not be mounted/used from
> a FreeBSD that has been booted via RPi3 EDK2. Bluetooth is
> disabled as part of getting a working serial console.
> 
> I ended up with a RPi3 EDK2 microsd card for use in booting
> that has:

I should have also shown the likes of
(USB microsd card reader/writer in use):

=>      63  61145025    da3  MBR  (29G)
        63      1985         - free -  (993K)
      2048  61143040  da3s1  fat32  (29G)

via the likes of:

# gpart add -i1 -b2048 -tfat32 da3

after the gpart create command.

A smaller slice/partition with newfs_msdos placing
fat16 ( so: -F16 on the command line instead of -F32 )
also worked for booting. But for the above I used:

# newfs_msdos -F32 /dev/da3s1

The detailed MBR type for the slice/partition set via
gpart does not seem to have to be an exact match for
16 vs. 32 in newfs_msdos but keeping them tracking is
probably a good idea.

> # mount -onoatime -tmsdosfs /dev/da3s1 /mnt
> # find /mnt -print
> /mnt
> /mnt/RPI_EFI.fd
> /mnt/bootcode.bin
> /mnt/config.txt
> /mnt/fixup.dat
> /mnt/start.elf
> /mnt/Readme.md
> /mnt/bcm2710-rpi-3-b-plus.dtb
> /mnt/bcm2710-rpi-3-b.dtb
> /mnt/bcm2710-rpi-cm3.dtb
> /mnt/firmware
> /mnt/firmware/Readme.txt
> /mnt/firmware/brcmfmac43455-sdio.txt
> /mnt/firmware/brcmfmac43455-sdio.bin
> /mnt/firmware/brcmfmac43455-sdio.clm_blob
> /mnt/firmware/LICENCE_bin+clm_blob.txt
> /mnt/firmware/brcmfmac43430-sdio.clm_blob
> /mnt/firmware/brcmfmac43430-sdio.txt
> /mnt/firmware/brcmfmac43430-sdio.bin
> /mnt/firmware/LICENSE_txt.txt
> /mnt/overlays
> /mnt/overlays/disable-bt.dtbo
> 
> All but the 2 "overlays" lines are based on the content of:
> 
> https://github.com/pftf/RPi3/releases/download/v1.37/RPi3_UEFI_Firmware_v1.37.zip
> 
> disable-bt.dtbo is a copy of one from a RPi* firmware
> used for booting FreeBSD on RPi*s. It is not in the .zip
> file.
> 
> I adjusted config.txt to indicate to use the disable-bt.dtbo :
> 
> # more /mnt/config.txt
> arm_64bit=1
> disable_commandline_tags=2
> disable_overscan=1
> enable_uart=1
> uart_2ndstage=1
> armstub=RPI_EFI.fd
> device_tree_address=0x1f0000
> device_tree_end=0x200000
> #
> # Local addition(s):
> dtoverlay=disable-bt
> 
> (The file has a carriage returns at the end of each
> line. Some editors show such characters as ^M .
> The characters could be deleted if desired.)
> 
> I'll note that the firmware/* content is likely of
> no use for FreeBSD at this point but I did not
> remove it. It should be okay to not have it present.
> 
> I'll note that the output from "uart_2ndstage=1" does
> not actually display during the boot sequence. (Sent
> to the wrong internal UART, as if dtoverlay=disable-bt
> had not been used, from what I understand.)
> 
> Using that microsd card in the RPi3B should try to
> boot. The EFI prompt will timeout and continue to the
> next stage (so far as it is successful, anyway). If
> it all works, it will get to the "login: " prompt.
> I'm not familiar with what the error reporting would
> be like if it also has troubles with your equipment.
> 
> You hit the return key to explicitly continue at the
> EFI prompt. The Escape key can be used instead to get
> into the menu system for controlling the UEFI
> settings.
> 
> If it gets far enough, the UEFI will try to find the
> EFI/BOOT/* on your USB media's msdosfs. If found, it
> will then load the FreeBSD loader and  then start it
> --and things would then be back in familiar territory.
> 
> 
> The above actually boots via a default setting that likely
> should be replaced. The related menu/field nesting is:
> 
> Device Manager
>    Raspberry Pi Configuration
>        Advanced Configuration
>            System Table Selection <ACPI + Devicetree>
> 
> Picking just Devicetree instead, then saving, and then
> exiting the nested menus via a sequence of Escape key
> presses, until back to the initial display, one can
> then select Reset and it will start over based on the
> new setting. The save actually updates an area in the
> RPI_EFI.fd file.
> 
> (The issue is that the ACPI information is odd:
> Microsoft specific, not standard. So if the ACPI
> information is used things are possibly not
> complete/correct.)
> 



===
Mark Millard
marklmi at yahoo.com