-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Booting into linux on simulation #12
Comments
Last time I tried this was a very long time ago. Make sure you have
However, simulating 64-bit rocket running the full tftp download sequence is about an order of magnitude less entertaining than watching paint dry. So, I remember replacing |
Hm I'm still not getting it to start unfortunately.
This is the
Console output before things get stuck:
Maybe I'm not waiting long enough but for blackparrot and vexriscv at least the |
The |
I revisited this issue and made some progress. Surprisingly I ran into a kernel panic.
|
On Thu, Jun 24, 2021 at 04:32:06AM -0700, developandplay wrote:
I revisited this issue and made some progress. Surprisingly I ran into a
kernel panic.
[ 2.362676] Oops - load access fault [#1]
[ 2.390956] Call Trace:
[ 2.391978] [<ffffffff802420a6>] litex_soc_ctrl_probe+0x3e/0x106
[ 2.394077] [<ffffffff80267f80>] platform_probe+0x3e/0x7c
Likely a CSR access in `litex_soc_ctrl_probe` triggering a cpu fault.
Could it be a lingering after-effect of fixing 64/32/16/8 bit access
strobes?
|
If you are referring to my access strobe fix for blackparrot then I don't think so. Unless you also ran into some strobe access problems on Rocket that I'm not aware of. |
On Sat, Jun 26, 2021 at 06:03:53PM -0700, developandplay wrote:
If you are referring to my access strobe fix for blackparrot then I don't
think so.
You're right, this is still using the RocketChip -- my mistake :)
The "load access fault" appears to happen here:
https://github.com/litex-hub/linux/blob/litex-rebase/drivers/soc/litex/litex_soc_ctrl.c#L45
... with the "bad address" being 0xffffffd004001b04 (presumably of the
32-bit scratch register, but that should be cross-referenced with the
csr map of the simulation).
This means CSR access is still somehow broken (in the simulator, since
it seems to work fine on a number of FPGAs)...
|
Is there some sort of (legitimate) address translation happening? |
On Sun, Jun 27, 2021 at 07:26:53AM -0700, developandplay wrote:
Is there some sort of (legitimate) address translation happening?
The scratch register should be at 0x12000004 according to the CSR map.
Yeah. On the ecpix5, csr_base is at 0x12000000 physical, but the value
for soc_ctl_dev->base returned by devm_platform_ioremap_resource() will
be 0xffffffd004016000, here:
https://github.com/litex-hub/linux/blob/litex-rebase/drivers/soc/litex/litex_soc_ctrl.c#L102
***EDIT***: I just noticed that, while we both have the same physical CSR base address (0x12000000), your "virtual" CSR has an extra offset of 0x1b00. Not sure yet whether that's an artefact of platform_ioremap on two different "platforms", or a typo somewhere in e.g. a DTS file...
|
Thanks for the EDIT now I have something to look into. |
For linux-on-litex-blackparrot we are setting the
ROM_BOOT_ADDRESS
inlitex_sim.py
to0x80000000
.However even with that change I didn't manage to boot into linux with rocket.
Do you have exact steps that you followed to accomplish that?
Using a method other than side loading would be fine as well of course.
I just want to make sure that I'm having a reproducible boot into linux in simulation before I further attempt it on my ulx3s and arty7.
For the ulx3s so far I'm reliably getting into the bios. On the arty7 I encounter some memory errors with newer versions of litex.
The text was updated successfully, but these errors were encountered: