[U-Boot] [RFC PATCH 00/11] SPL support for RISC-V

Auer, Lukas lukas.auer at aisec.fraunhofer.de
Wed Jul 24 15:02:48 UTC 2019


Hi Bin,

On Wed, 2019-07-24 at 21:49 +0800, Bin Meng wrote:
> Hi Lukas,
> 
> On Wed, Jul 24, 2019 at 5:23 PM Auer, Lukas
> <lukas.auer at aisec.fraunhofer.de> wrote:
> > Hi Bin,
> > 
> > On Wed, 2019-07-24 at 10:55 +0800, Bin Meng wrote:
> > > Hi Lukas,
> > > 
> > > On Wed, Jul 24, 2019 at 5:34 AM Auer, Lukas
> > > <lukas.auer at aisec.fraunhofer.de> wrote:
> > > > Hi Bin,
> > > > 
> > > > On Tue, 2019-07-23 at 16:32 +0800, Bin Meng wrote:
> > > > > Hi Lukas,
> > > > > 
> > > > > On Mon, Jul 22, 2019 at 2:00 AM Lukas Auer
> > > > > <lukas.auer at aisec.fraunhofer.de> wrote:
> > > > > > This series adds support for SPL to RISC-V U-Boot. Images can be booted
> > > > > > via OpenSBI (FW_DYNAMIC firmware) or by directly jumping to them. In the
> > > > > > former case, OpenSBI and U-Boot proper are bundled as a FIT image and
> > > > > > made available to U-Boot SPL. Currently, only the QEMU board enables
> > > > > > U-Boot SPL with a dedicated configuration. It uses RAM as SPL boot
> > > > > > device.
> > > > > > 
> > > > > > On many RISC-V CPUs, the device tree is provided to U-Boot by the
> > > > > > first stage bootloader. This requires changes to U-Boot SPL (patches 1,
> > > > > > 2 and 3), which modify the behavior on other boards as well. To get
> > > > > > feedback on this, I am therefore sending this series as RFC first.
> > > > > > 
> > > > > > To test this series, OpenSBI has to be compiled first. The
> > > > > > fw_dynamic.bin binary must be copied into the U-Boot root directory.
> > > > > > Alternatively, the location of the binary can be specified with the
> > > > > > OPENSBI environment variable. U-Boot can then be build as normal using
> > > > > > the configuration qemu-riscv64_spl_defconfig for 64-bit builds or
> > > > > > qemu-riscv32_spl_defconfig for 32-bit builds. The outputs from the build
> > > > > > process are the U-Boot SPL binary (spl/u-boot-spl.bin) and the U-Boot
> > > > > > FIT image (u-boot.itb) containing U-Boot proper and OpenSBI.
> > > > > > 
> > > > > > U-Boot can be run in QEMU with the following command.
> > > > > > 
> > > > > > qemu-system-riscv64 -nographic -machine virt -kernel spl/u-boot-spl \
> > > > > >         -device loader,file=u-boot.itb,addr=0x80200000
> > > > > > 
> > > > > 
> > > > > Nice job done! It looks the SPL support was cleanly implemented.
> > > > > 
> > > > 
> > > > Thank you very much! :)
> > > > 
> > > > > I've tested this series, on qemu-riscv64 with UP and SMP, both work fine.
> > > > > However when testing on qemu-riscv32, the U-Boot proper does not boot.
> > > > > Please have a look.
> > > > > 
> > > > > Regards,
> > > > > Bin
> > > > 
> > > > Thank you for reviewing and testing the series!
> > > > 
> > > > Do you mean that the U-Boot prompt does not appear? Testing the series
> > > 
> > > I mean U-Boot proper, the S-mode payload that SPL loads.
> > > 
> > > > on qemu-riscv32, I get the U-Boot prompt from U-Boot proper. I did not
> > > > try to boot Linux on qemu-riscv32, however. I will try that tomorrow.
> > > 
> > > After debugging myself, it turns out to be a false alarm. Sorry about that.
> > > 
> > > I was using a 64-bit OpenSBI fw_dynamic.bin. Looks OpenSBI doc does
> > > not clearly mention how 32-bit build is to be done, and I will send a
> > > patch for that. After switching a 32-bit OpenSBI firmware now I am
> > > able to boot to 32-bit U-Boot proper.
> > > 
> > 
> > No problem. You are right, that should be stated more clearly in the
> > OpenSBI docs. Thanks for testing again!
> 
> One thing just occurred to me, is that did you try using binman to
> package SPL + OpenSBI + U-Boot proper into one image?
> 
> I am not sure whether this is the preferred way going forward, hence I
> added Simon for his comments.
> 

Yes, I did try it out, but decided not to include it in this series,
because at least for QEMU it was easier to just use the QEMU device
loader to load the FIT image into memory.

What I did was to use binman to package SPL and the U-Boot FIT image.
Information on the location of the FIT image is then available to    
U-Boot SPL. This makes it possible for the SPL RAM driver to load the
FIT image without knowing where it is located beforehand, which is
really nice. I did not try to use binman to package the individual
components instead of the FIT image.

We might be able to use binman on the HiFive Unleashed board. The
bootloader already loads the complete image into memory. We would
therefore not have to include any MMC code into U-Boot SPL and could
just use the SPL RAM driver and binman to find the FIT image.

Thanks,
Lukas


More information about the U-Boot mailing list