u-boot.lists.denx.de archive mirror
 help / color / mirror / Atom feed
From: Roland Ruckerbauer <mail@ruabmbua.dev>
To: u-boot@lists.denx.de, yanhong.wang@starfivetech.com
Subject: Trying to boot JH7110 RISCV-V CPU from MMC
Date: Tue, 27 Jun 2023 21:51:51 +0200	[thread overview]
Message-ID: <e6cd461d-151e-3557-f58a-6118836f8e6a@ruabmbua.dev> (raw)

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://github.com/starfive-tech/Tools/tree/master/spl_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)

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


             reply	other threads:[~2023-06-28 12:46 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20230628124713epcas1p162e14619ac9fc518e44290597291f30c@epcas1p1.samsung.com>
2023-06-27 19:51 ` Roland Ruckerbauer [this message]
2023-07-27  8:12   ` Trying to boot JH7110 RISCV-V CPU from MMC Jaehoon Chung
2023-07-27  8:42     ` Roland Ruckerbauer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e6cd461d-151e-3557-f58a-6118836f8e6a@ruabmbua.dev \
    --to=mail@ruabmbua.dev \
    --cc=u-boot@lists.denx.de \
    --cc=yanhong.wang@starfivetech.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).