Open Jerryy959 opened 5 months ago
Btw, i'm new on fpga, another question is that where the irq number come from ? Is it come from the litex design or rocketchip?
Btw, i'm new on fpga, another question is that where the irq number come from ? Is it come from the litex design or rocketchip?
It could come from litex_json2dts_linux, but doesn't seem to.
Maybe it's hard coded in linux-on-litex-rocket?
On Fri, May 31, 2024 at 07:26:35PM -0700, AndrewD wrote:
Btw, i'm new on fpga, another question is that where the irq number come from ? Is it come from the litex design or rocketchip?
It could come from litex_json2dts_linux, but doesn't seem to.
Maybe it's hard coded in linux-on-litex-rocket?
IRQs from LiteX devices come from the contents of csr.csv (generated
during build using --csr-csv ./csr.sv
), and must each be incremented
by 1 when used with a rocket-specific DTS.
I believe litex-json2dts-linux might have been updated to do this for rocket by now (commit 9156d790).
It looks like linux-on-litex-rocket
recommends a specific dts which is almost guaranteed to be wrong and the source of the reported error.
@Comet959 if you are using that dts (which I suspect is the case), it would be way better to try the dts generated by litex-json2dts-linux
for your exact soc. You just need to generate csr.json by specifying the appropriate command line switch to the target build, then run litex-json2dts-linux
with that json file.
You could test using this repository.
linux sub-directory contains a buildroot external with a rocket defconfig using an uptodate linux kernel and a dts generated using litex-json2dts-linux
.
It looks like
linux-on-litex-rocket
recommends a specific dts which is almost guaranteed to be wrong and the source of the reported error. @Comet959 if you are using that dts (which I suspect is the case), it would be way better to try the dts generated bylitex-json2dts-linux
for your exact soc. You just need to generate csr.json by specifying the appropriate command line switch to the target build, then runlitex-json2dts-linux
with that json file.
Thanks for it! I have tried to use litex-json2dts-linux
to generate my dts. This problem seems to be solved.
But i meet a new problem mentioned here: https://github.com/litex-hub/linux-on-litex-rocket/issues/41#issue-2329088891
My dts have no irq 12 , but booting info shows me that irq 12 nobody cared, i don't know how to think it. Can you give me some suggestion. Thanks!
But i meet a new problem mentioned here
@Comet959 I think you will have more success if you look at the repository mentioned by @trabucayre above. I believe it will build everything needed to run a known working configuration. I haven't personally used rocket or followed the docs you mentioned, so I can only provide limited help. linux-on-litex-rocket is also 2 years old and a lot has changed since then.
But i meet a new problem mentioned here
@Comet959 I think you will have more success if you look at the repository mentioned by @trabucayre above. I believe it will build everything needed to run a known working configuration. I haven't personally used rocket or followed the docs you mentioned, so I can only provide limited help. linux-on-litex-rocket is also 2 years old and a lot has changed since then.
🎉Thanks very much! I have already run the test successfully, all works fine. I definitely couldn't have done it without your help. @trabucayre @AndrewD I can't thank you enough. This issue can be closed.
FWIW, I just updated linux-on-litex-rocket to use "fresh" component commits and opensbi (instead of the old, deprecated BBL). Examples include boards I have available to work with:
It should be relatively straightforward to adapt one of the DTS examples to a new board, and rebuild a dedicated opensbi firmware blob to fit the new bitstream.
FWIW, I just updated linux-on-litex-rocket to use "fresh" component commits and opensbi (instead of the old, deprecated BBL). Examples include boards I have available to work with:
- nexys-video
- acorn baseboard mini
- lambdaconcept ecpix5
It should be relatively straightforward to adapt one of the DTS examples to a new board, and rebuild a dedicated opensbi firmware blob to fit the new bitstream.
This is really something worth celebrating。
Another thing that puzzles me is about the ISA extension. I want to enable the H-extension when compiling rocketchip, but as you can see in the picture above, isa does not show support for the H extension.
I saw this issue also mentioned related issues https://github.com/chipsalliance/rocket-chip/issues/3296 , but I still haven't figured out how to support H extension specifically. Can you explain it to me? @gsomlo
I want to enable the H-extension when compiling rocketchip
H extension is supported only when using:
... --cpu-type rocket --cpu-variant full ...
When you build your .dts file, use the core parameters (e.g., isa
string) in one of the pythondata-cpu-rocket/pythondata_cpu_rocket/verilog/generated-src/freechips.rocketchip.system.LitexConfig_full_*.dts
files as a starting point.
Note that pythondata-cpu-rocket
is a fair bit behind upstream
rocket-chip: upstream made a set of major changes that make it less
suitable for use with LiteX, and I haven't had time to try again since
https://github.com/enjoy-digital/litex/pull/1878#issuecomment-1972217232
the issue metioned on: https://github.com/litex-hub/linux-on-litex-rocket/issues/40#issue-2324887509
i found the arty.dts had a node with interrupts-extended: <&L4 11 >
and my Linux can't get thr irq 11 's handler. How can i debug this?