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

[Rick Chen <rickchen36@gmail.com>]

Hi Lukas and Anup

>
> Hi Rick,
>
> On Fri, 2019-08-02 at 14:18 +0530, Anup Patel wrote:
> > On Fri, Aug 2, 2019 at 2:11 PM Rick Chen <rickchen36@gmail.com> wrote:
> > > Hi Lukas
> > >
> > > > Hi Rick,
> > > >
> > > > On Thu, 2019-08-01 at 11:32 +0800, Rick Chen wrote:
> > > > > Hi Lukas
> > > > >
> > > > > > > From: Lukas Auer [mailto:lukas.auer at aisec.fraunhofer.de]
> > > > > > > Sent: Sunday, July 28, 2019 11:57 PM
> > > > > > > To: u-boot at lists.denx.de
> > > > > > > Cc: Atish Patra; Rick Jian-Zhi Chen(陳建志); Bin Meng; Sagar Kadam; Alistair
> > > > > > > Francis; Anup Patel; Troy Benjegerdes; Lukas Auer; Abel Vesa; Alex Kiernan;
> > > > > > > Alex Marginean; Alexander Graf; Andreas Dannenberg; Andrew F. Davis; Anup
> > > > > > > Patel; Anup Patel; Atish Patra; Chris Packham; Eugeniu Rosca; Heiko Schocher;
> > > > > > > Heinrich Schuchardt; Jagan Teki; Jean-Jacques Hiblot; Jens Wiklander; Joe
> > > > > > > Hershberger; Kever Yang; Lokesh Vutla; Lukasz Majewski; Marek Vasut; Marek
> > > > > > > Vasut; Marek Vasut; Markus Klotzbuecher; Michal Simek; Paul Burton; Peng
> > > > > > > Fan; Philipp Tomsich; Philippe Reynes; Ryder Lee; Shawn Guo; Simon Glass;
> > > > > > > Simon Goldschmidt; Stefan Roese; Stefano Babic; Tien Fong Chee; Vignesh R;
> > > > > > > Weijie Gao; Ye Li
> > > > > > > Subject: [PATCH v2 00/11] SPL support for RISC-V
> > > > > > >
> > > > > > > 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 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
> > > > > > >
> > > > >
> > > > > Great job !
> > > > >
> > > >
> > > > Thank you!
> > > >
> > > > > I also try to run the spl flow on ax25-ae350 platform.
> > > > > But encounter some problems. I am still debugging.
> > > > >
> > > > > Following is the error message:
> > > > > :
> > > > > U-Boot SPL 2019.07-10574-ge6ef7ec-dirty (Aug 01 2019 - 10:09:45 +0800)
> > > > > Trying to boot from RAM
> > > > >
> > > > > U-Boot 2019.07-10574-ge6ef7ec-dirty (Aug 01 2019 - 10:09:45 +0800)
> > > > >
> > > > > DRAM:  exception code: 5 , Load access fault , epc 1212654 , ra 1200ffe
> > > > > ### ERROR ### Please RESET the board ###
> > > > >
> > > > > Do you have some comments ?
> > > > >
> > > >
> > > > It is difficult to judge without the exact configuration. Is your
> > > > current git tree available somewhere?
> > >
> > > No, it is not available yet.
> > > And you don't have the ax25-ae350 board, it is still in vain if the
> > > git tree is available.
> > >
> > > > The error is quite strange, because it already booted U-Boot proper. So
> > > > the error does not happen in code, which has been directly modified by
> > > > this series. Perhaps it is trying to initialize something twice (once
> > > > in SPL and again in U-Boot proper)? Can you check at what location the
> > > > error occurs?
> > >
> > > I found that the exception occurred in get_ram_size() of ax25-ae350.c
> > > when it try to load the memory address 0x10000.
> > > But the access of 0x20000 is ok.
> > >
> > > I try to mark the get_ram_size() and do not execute it, U-Boot proper
> > > can boot successfully as below:
> > >
> > > U-Boot SPL 2019.07-10574-ge6ef7ec-dirty (Aug 02 2019 - 16:07:54 +0800)
> > > Trying to boot from RAM
> > >
> > > U-Boot 2019.07-10574-ge6ef7ec-dirty (Aug 02 2019 - 16:07:54 +0800)
> > > DRAM:  1 GiB
> > > Flash: 64 MiB
> > > MMC:   mmc at f0e00000: 0
> > > Loading Environment from SPI Flash... SF: Detected mx25u1635e with
> > > page size 256 Bytes, erase size 4 KiB, total 2 MiB
> > > *** Warning - bad CRC, using default environment
> > > In:    serial at f0300000
> > > Out:   serial at f0300000
> > > Err:   serial at f0300000
> > > Net:   no alias for ethernet0
> > > Warning: mac at e0100000 (eth0) using random MAC address - 36:13:4d:06:b8:fd
> > > eth0: mac at e0100000
> > > Hit any key to stop autoboot:  0
> > > RISC-V #
> > >
> > > So I tried to trace openSBI and found the BANNER of openSBI was not printed.
> > > Is it correct ?
> >
> > Yes, U-Boot SPL is passing SBI_SCRATCH_NO_BOOT_PRINTS option to
> > OpenSBI due to which you don't see any prints. Although, error prints from
> > OpenSBI will be still available.
> >
>
> If you want to enable the OpenSBI banner, you can remove the option in
> common/spl/spl_opensbi.c.
>
> > > Any idea about why the access of memory address(0x10000) will fail ?
> > > I guess it seem relative to pmp configuration.
> >
> > If it is PMP access checks then you should get ACCESS faults error
> > prints from OpenSBI.
> >
>
> The access violation you are seeing is strange and I am not sure why
> OpenSBI does not print any errors. It does seem like a problem with the
> PMP configuration though.
>

I change pmpcfg0 from 0x1f18 to 0x1f1f and 0x10000 can be accessed.

==========
gdb message
==========
(gdb) p/x $pmpcfg0
$12 = {0x1f1f, pmp0cfg = {0x1f, a = 0x3}, pmp1cfg = {0x1f, a = 0x3},
  pmp2cfg = {0x0, a = 0x0}, pmp3cfg = {0x0, a = 0x0}, pmp4cfg = {0x0,
    a = 0x0}, pmp5cfg = {0x0, a = 0x0}, pmp6cfg = {0x0, a = 0x0}, pmp7cfg = {
    0x0, a = 0x0}}

U-Boot SPL 2019.07-10574-ge6ef7ec-dirty (Aug 02 2019 - 16:07:54 +0800)
Trying to boot from RAM

============
u-boot message
============

U-Boot 2019.07-10574-ge6ef7ec-dirty (Aug 02 2019 - 16:07:54 +0800)

DRAM:  1 GiB
Flash: 64 MiB
MMC:   mmc at f0e00000: 0
Loading Environment from SPI Flash... SF: Detected mx25u1635e with
page size 256 Bytes, erase size 4 KiB, total 2 MiB
*** Warning - bad CRC, using default environment

In:    serial at f0300000
Out:   serial at f0300000
Err:   serial at f0300000
Net:   no alias for ethernet0

Warning: mac at e0100000 (eth0) using random MAC address - ea:d7:a7:97:06:2c
eth0: mac at e0100000
Hit any key to stop autoboot:  0
RISC-V #
RISC-V # md.b 0x10000
00010000: ef 80 c2 00 aa 87 3e 85 6f c0 22 26 ef c2 02 22    ......>.o."&..."
00010010: 17 25 03 00 13 05 05 03 ef a0 2f 92 19 c5 41 46    .%......../...AF
00010020: 81 45 ef 80 e2 13 6f c0 e2 23 83 b7 01 00 17 25    .E....o..#.....%
00010030: 03 00 13 05 25 ff 80 67 84 6b ef a0 0f 90 a2 87    ....%..g.k......
RISC-V #

Thanks
Rick

> Thanks,
> Lukas