Page MenuHomeFreeBSD

RISC-V u-boot ports
ClosedPublic

Authored by mhorne on Jul 19 2020, 11:07 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sat, Apr 20, 6:03 PM
Unknown Object (File)
Fri, Apr 12, 9:59 AM
Unknown Object (File)
Fri, Apr 12, 9:19 AM
Unknown Object (File)
Sat, Mar 30, 7:08 PM
Unknown Object (File)
Mar 18 2024, 4:02 AM
Unknown Object (File)
Mar 2 2024, 4:31 PM
Unknown Object (File)
Mar 2 2024, 4:31 PM
Unknown Object (File)
Mar 2 2024, 4:31 PM

Details

Summary

This adds two new ports: sysutils/u-boot-qemu-riscv64 and
sysutils/u-boot-sifive-fu540 for the QEMU and HiFive Unleashed platforms
respectively.

For QEMU, a simple u-boot payload is provided that can be specified on
the command line. It runs in supervisor mode, and should be paired with
OpenSBI.

For the FU540, there are two u-boot bootloaders provided. First, u-boot
SPL which runs in machine mode and will locate and launch the u-boot FIT
image. Second, the FIT binary which contains u-boot proper, the FU540
FDT, and a copy of OpenSBI.

Test Plan

Tested in QEMU using the incantation provided in pkg-descr. U-boot can
successfully locate and launch loader.efi.

Testing for the Unleashed is a little more difficult. QEMU's sifive_u
target is good enough to be able to launch the basic u-boot binary (with
some tweaks), but it is not possible to test the SPL+FIT combo without a
real board. I did my best to create the instructions in pkg-descr based
on u-boot's documentation [1], but I have no way to verify that is
actually boots.

[1] https://github.com/u-boot/u-boot/blob/master/doc/board/sifive/fu540.rst

Diff Detail

Repository
rP FreeBSD ports repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

mhorne created this revision.

@philip @kp @nick I'm hoping one of you would be able to test this on your SiFive board. As I've mentioned I have no way to do so. u-boot SPL is essentially a drop-in replacement for SiFive's FSBL, so hopefully the instructions I have left look somewhat familiar to you.

If you don't have time to test it or we can't get it to boot, then I would be fine with committing just the QEMU part.

Yeah. I can take a look later this afternoon.

Is this also supposed to work from the on-board NOR flash?

sysutils/u-boot-master/Makefile
106 ↗(On Diff #74674)

Add here UBOOT_PLIST_QEMU= u-boot.bin
YOu can then remove the plist in the u-boot-qemu-riscv64 port (And I'll clean the other qemu u-boot ports after).

sysutils/u-boot-qemu-riscv64/Makefile
12 ↗(On Diff #74674)

No need to specify the version if it's the same as u-boot-master.

Good for me, thanks and feel free to commit with Approved-by : u-boot (manu@)

This revision is now accepted and ready to land.Jul 20 2020, 1:25 PM

Yeah. I can take a look later this afternoon.

Is this also supposed to work from the on-board NOR flash?

Seems like it. There is some info in the patch series.

You might have to create the partitions beginning at block 40, not 64 like I have above.

EDIT: actually, that series didn't make it into the v2020.07 release. So the answer is "not yet"

I didn't manage to get this booting yesterday. But the boot switches on my SiFive board are a little confused. Continuing to poke at this today.

I didn't manage to get this booting yesterday. But the boot switches on my SiFive board are a little confused. Continuing to poke at this today.

Any luck? I will commit the QEMU bits this week, but IMO there is no rush on the sifive portion.

This revision was automatically updated to reflect the committed changes.

I've not had a chance to poke at this further. It's been busy recently. I'll pick this up again this week. Thanks for keeping my feet close to the fire!

Rebase and fix up the fu540 port. I will see about getting someone to test this with the new GENERICSD image.

Rebase and fix up the fu540 port. I will see about getting someone to test this with the new GENERICSD image.

test described in freebsd-riscv@freebsd.org
Regards

Hi,
I have created the following installation instruction and extensively tested on the hardware
(gpart failed in the definitely necessary alignment of first-lba: 34) :

  • ("typecode=3:a503" is freebsd-ufs (not needed to only boot u-boot))
  • boot jumper MSEL2 has to be switched up to boot from u-boot)

installation instruction :

+++ sysutils/u-boot-sifive-fu540/pkg-descr
@@ -0,0 +1,13 @@
+U-Boot loader and related files for the SiFive Unleashed (FU540).
+
+prep your uSD (assumed here that your uSD-device is /dev/da2 ) :
+
+1.: pkg install gdisk
+--
+2.: sgdisk --clear --set-alignment=2 --new=1:34:2081 --change-name=1:loader1 --typecode=1:5B193300-FC78-40CD-8002-E86C45580B47 --new=2:2082:10273 --change-name=2:loader2 --typecode=2:2E54B353-1271-4842-806F-E436D6AF6985 --new=3:10274: --change-name=3:rootfs --typecode=3:a503 /dev/da2
+--
+3.: dd f=/usr/local/share/u-boot/u-boot-sifive-fu540/u-boot-spl.bin of=/dev/da2p1 conv=sync
+--
+4.: dd if=/usr/local/share/u-boot/u-boot-sifive-fu540/u-boot.itb of=/dev/da2p2 conv=sync
+
+WWW: https://www.denx.de/wiki/U-Boot

U-Boot SPL 2020.10 (Dec 13 2020 - 18:41:31 +0000)
Trying to boot from MMC1

U-Boot 2020.10 (Dec 13 2020 - 18:41:31 +0000)

CPU: rv64imafdc
Model: SiFive HiFive Unleashed A00
DRAM: 8 GiB
MMC: spi@10050000:mmc@0: 0
Loading Environment from SPIFlash... SF: Detected is25wp256 with page size 256 Bytes, erase size 4 KiB, total 32 MiB

  • Warning - bad CRC, using default environment

In: serial@10010000
Out: serial@10010000
Err: serial@10010000
Net: eth0: ethernet@10090000
Hit any key to stop autoboot: 0
switch to partitions #0, OK
mmc0 is current device

  • Unrecognized filesystem type **

SF: Detected is25wp256 with page size 256 Bytes, erase size 4 KiB, total 32 MiB
device 0 offset 0x1fff000, size 0x1000
SF: 4096 bytes @ 0x1fff000 Read: OK... bla bla

well, to add : Warning - bad CRC, using default environment simply means that the next step to do is to fill the freebsd-ufs partition up with the root filesystem and to create an (loader-)env for u-boot. after saveenv the crc-warning will be gone.So maybe the additional creation of an ms-basic-data partition with the content of the loader-env will be needed.

This revision is now accepted and ready to land.Dec 16 2020, 1:44 PM

@maciphone2_googlemail.com thank you for the thorough testing. I'll have to look into why gpart(8) can't generate partitions starting at LBA 34, but it was the reason my instructions differed from the ones provided by u-boot. Did you find the required alignment documented anywhere? So far I have not found it.

@manu does the port still look okay to your eye?

well, to add : Warning - bad CRC, using default environment simply means that the next step to do is to fill the freebsd-ufs partition up with the root filesystem and to create an (loader-)env for u-boot. after saveenv the crc-warning will be gone.So maybe the additional creation of an ms-basic-data partition with the content of the loader-env will be needed.

We can try again with booting the GENERICSD image after the next snapshot is released on Thursday. FreeBSD's SD card images don't usually contain loader-env (as far as I know), but they do contain a FAT partition for EFI where one could be saved.

Yup still good to me.

@mhorne

@maciphone2_googlemail.com thank you for the thorough testing. I'll have to look into why gpart(8) can't generate partitions starting at LBA 34, but it was the reason my instructions differed from the ones provided by u-boot. Did you find the required alignment documented anywhere? So far I have not found it.

yes, after I realized that it needs the 34-start-LBA-alignment I even found it documented (by the SiFive-creators in u-boot) :

https://lists.denx.de/pipermail/u-boot/2020-May/413447.html

We can try again with booting the GENERICSD image after the next snapshot is released on Thursday. FreeBSD's SD card images don't usually contain loader-env (as far as I know), but they do contain a FAT partition for EFI where one could be saved.

yes, exactly, and assuming you will align the whole GENERICSD image BEFORE the snap release via sgdisk we simply could say in pkg-descr :

prep your boot jumpers for u-boot :

   USB   LED    Mode Select                  Ethernet
 +===|___|==****==+-+-+-+-+-+-+=================|******|===+
 |                | | | | |X| |                 |      |   |
 |                | | | | | | |                 |      |   |
 |        HFXSEL->|X|X|X|X| |X|                 |______|   |
 |                +-+-+-+-+-+-+                            |
 |        RTCSEL-----/ 0 1 2 3 <--MSEL                     |
 |                                                         |

(assumed here that /dev/da2 is our uSD-device) :
dd if=/usr/local/share/u-boot/u-boot-sifive-fu540/u-boot-spl.bin of=/dev/da2p1 conv=sync
dd if=/usr/local/share/u-boot/u-boot-sifive-fu540/u-boot.itb of=/dev/da2p2 conv=sync

( no -bs=xx, no seek=xxxplease !!! ;-) &
gpart is the wrong tool in this case (I tried nearly every possible dd-seek-combination with starts @ LBA40 or @ LBA63)
and the SiFive-people even didn't use the tux-'parted`-tool too.

Regards

@mhorne

@maciphone2_googlemail.com thank you for the thorough testing. I'll have to look into why gpart(8) can't generate partitions starting at LBA 34, but it was the reason my instructions differed from the ones provided by u-boot. Did you find the required alignment documented anywhere? So far I have not found it.

yes, after I realized that it needs the 34-start-LBA-alignment I even found it documented (by the SiFive-creators in u-boot) :

https://lists.denx.de/pipermail/u-boot/2020-May/413447.html

I went looking at the u-boot source today, and indeed they hardcode the LBA for loader2 to 2082, which explains why it was failing for you while loading the u-boot FIT image.

Unlike u-boot, SiFive's fsbl (First Stage Bootloader) seems to be smart enough to search for the correct GPT partition GUID and load that. If you were so inclined you could use that instead of u-boot-spl.bin, and it should allow these partitions to be placed anywhere on the disk.

That being said, I'm happy to provide instructions just to use the required scheme at the moment.

We can try again with booting the GENERICSD image after the next snapshot is released on Thursday. FreeBSD's SD card images don't usually contain loader-env (as far as I know), but they do contain a FAT partition for EFI where one could be saved.

yes, exactly, and assuming you will align the whole GENERICSD image BEFORE the snap release via sgdisk we simply could say in pkg-descr :

prep your boot jumpers for u-boot :

   USB   LED    Mode Select                  Ethernet
 +===|___|==****==+-+-+-+-+-+-+=================|******|===+
 |                | | | | |X| |                 |      |   |
 |                | | | | | | |                 |      |   |
 |        HFXSEL->|X|X|X|X| |X|                 |______|   |
 |                +-+-+-+-+-+-+                            |
 |        RTCSEL-----/ 0 1 2 3 <--MSEL                     |
 |                                                         |

(assumed here that /dev/da2 is our uSD-device) :
dd if=/usr/local/share/u-boot/u-boot-sifive-fu540/u-boot-spl.bin of=/dev/da2p1 conv=sync
dd if=/usr/local/share/u-boot/u-boot-sifive-fu540/u-boot.itb of=/dev/da2p2 conv=sync

( no -bs=xx, no seek=xxxplease !!! ;-) &
gpart is the wrong tool in this case (I tried nearly every possible dd-seek-combination with starts @ LBA40 or @ LBA63)
and the SiFive-people even didn't use the tux-'parted`-tool too.

Regards

Thanks again, I will commit this tonight or tomorrow.