Trying to boot JH7110 RISCV-V CPU from MMC

[Jaehoon Chung]

Hi,

> -----Original Message-----
> From: U-Boot <u-boot-bounces at lists.denx.de> On Behalf Of Roland Ruckerbauer
> Sent: Wednesday, June 28, 2023 4:52 AM
> To: u-boot at lists.denx.de; yanhong.wang at starfivetech.com
> Subject: Trying to boot JH7110 RISCV-V CPU from MMC
> 
> Hi!
> 
> I am trying to use upstream u-boot + opensbi, to boot my visionfive2 SBC
> I got from external SD card. I had not much luck with the vendor
> provided images / tools, they seem to have a lot of hard coded stuff and
> just won`t work correctly.
> 
> With upstream u-boot I followed the doc/board/starfive/visionfive2.rst
> to the point, but unfortunately it did not work.
> 
> First I ran into an issue, where the chip would pick up a random SPL
> somewhere else on the SD card, and so I could not test my build.
> I fixed it by completely erasing the whole sdcard to make sure there can
> be no other SPL/Uboot on it. This worked, but unfortunately
> the sd card I made with the steps from
> doc/board/starfive/visionfive2.rst still did not work.
> 
> I managed to figure out, that I need to make special modifications to
> the first 2 sectors of the sd card (protective MBR and GPT header), using
> https://protect2.fireeye.com/v1/url?k=61d64ba7-00ade130-61d7c0e8-74fe4860001d-
> 48ffcb4bd9c5658e&q=1&e=38e576e4-b8ca-4e7f-92e3-90b65f990704&u=https%3A%2F%2Fgithub.com%2Fstarfive-
> tech%2FTools%2Ftree%2Fmaster%2Fspl_tool. Calling
> spl_tool -i -f /dev/sdb on my sdcard patches the first sectors with an
> invalid
> SPL, and also a offset to the backup SPL (which is the primary one I
> flashed according to the documentation).
> 
> Maybe this should be added to the docu, otherwise it will not work, or
> worse, load some other SPL also on the SD card and cause confusion.
> There also is a mention in the docu, that the boot ROM searches for the
> SPL by looking for the offset of its partition in the GPT with a specific
> GUID. Not sure where this information comes from, but testing showed,
> that its probably not true.
> 
> 
> Now to my actual problem, hopefully someone can help:
> 
> The sdcard I built with u-boot and opensbi can now boot the spl, and
> also start opensbi and load u-boot. Unfortunately
> the init_sequence_r now fails with an error: initcall sequence
> 00000000fffe0738 failed at call 0000000040216240 (err=-19)

Did you find what's caused? It seems it's not working fine with latest yet.
It seems that your analysis is right way.

When I have tested on v2023.07-rc1, it's booting fine.
So I did the git bisect from v2023.07-rc1 to master.

2023-05-04 16:50 -0600 Simon Glass                           * [HEAD] [refs/bisect/bad] dm: Emit the arch_cpu_init_dm() even only before relocation
2023-05-04 16:55 -0600 Simon Glass                           * [refs/bisect/good-44dc33042f8465764bddeba4e4b362dd5372b74a] coreboot: Enable ms command

After applied the below patch, visionfive2 doesn't work fine.

55171aedda88d12666e2a1bbc661dea1bec65337 is the first bad commit
commit 55171aedda88d12666e2a1bbc661dea1bec65337
Author: Simon Glass <sjg at chromium.org>
Date:   Thu May 4 16:50:45 2023 -0600

    dm: Emit the arch_cpu_init_dm() even only before relocation

    The original function was only called once, before relocation. The new
    one is called again after relocation. This was not the intent of the
    original call. Fix this by renaming and updating the calling logic.

    With this, chromebook_link64 makes it through SPL.

    Fixes: 7fe32b3442f0 ("event: Convert arch_cpu_init_dm() to use events")
    Signed-off-by: Simon Glass <sjg at chromium.org>
    Reviewed-by: Bin Meng <bmeng.cn at gmail.com>

 arch/arm/mach-imx/imx8/cpu.c        | 2 +-
 arch/arm/mach-imx/imx8m/soc.c       | 2 +-
 arch/arm/mach-imx/imx8ulp/soc.c     | 2 +-
 arch/arm/mach-imx/imx9/soc.c        | 2 +-
 arch/arm/mach-omap2/am33xx/board.c  | 2 +-
 arch/arm/mach-omap2/hwinit-common.c | 2 +-
 arch/mips/mach-pic32/cpu.c          | 2 +-
 arch/nios2/cpu/cpu.c                | 2 +-
 arch/riscv/cpu/cpu.c                | 2 +-
 arch/x86/cpu/baytrail/cpu.c         | 2 +-
 arch/x86/cpu/broadwell/cpu.c        | 2 +-
 arch/x86/cpu/ivybridge/cpu.c        | 2 +-
 arch/x86/cpu/quark/quark.c          | 2 +-
 arch/x86/lib/fsp2/fsp_init.c        | 2 +-
 doc/develop/event.rst               | 6 +++---
 drivers/core/root.c                 | 4 ++--
 drivers/cpu/microblaze_cpu.c        | 2 +-
 include/event.h                     | 2 +-
 18 files changed, 21 insertions(+), 21 deletions(-)


Best Regards,
Jaehoon Chung

> 
> Digging through the source and some printf debugging revealed to me,
> that initr_dm_devices() fails, because it can not find
> a timer device with in dm_timer_init() call.
> 
> For the JH7110 and pretty much any other RISCV chip the timer device
> should be provided by the SBI, which is functioning correctly as far as
> I can tell. I searched for it in the u-boot code, and figured out that
> riscv_timer uboot driver should be probed, when the booting cpu is bound to
> its driver in the riscv_cpu_bind() function.
> 
> Unfortunately it seems like this cpu driver bind function is never
> called before the initcall sequence crashed because of the missing timer
> device.
> 
> That is pretty much everything I could figure out on my own until now,
> but I am not sure what exactly is going wrong.
> Hopefully it has nothing to do with how my local setup compiles the
> code. u-boot seems to be using many tricks like the U_BOOT_DRIVER() macro
> and others, maybe some of them do not guarantee to create entries in a
> specific order, and the code accidentally depends on a specific order.
> 
> Maybe somebody can give me some pointers, I would appreciate it.
> 
> Greetings,
> Roland Ruckerbauer