Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot it
- In reply to: Mark Millard : "Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot it"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Tue, 04 Oct 2022 20:59:06 UTC
On 2022-Oct-4, at 01:25, Mark Millard <marklmi@yahoo.com> 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