Arty A7-100T Boot Linux Panic about irqchip.

[Comet959]

the issue metioned on:
litex-hub/linux-on-litex-rocket#40 (comment)

i found the arty.dts had a node with interrupts-extended: <&L4 11 >

L1: interrupt-controller@c000000 {
			#interrupt-cells = <1>;
			compatible = "riscv,plic0";
			interrupt-controller;
			interrupts-extended = <&L4 11 &L4 9>;
			reg = <0xc000000 0x4000000>;
			reg-names = "control";
			riscv,max-priority = <7>;
			riscv,ndev = <8>;
		};

and my Linux can't get thr irq 11 's handler.
How can i debug this?

[Comet959]

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?

[AndrewD]

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?

[gsomlo]

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 9156d79).

[AndrewD]

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.

[trabucayre]

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.

[Comet959]

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.

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: litex-hub/linux-on-litex-rocket#41 (comment)

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!

[AndrewD]

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.

[Comet959]

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.

[gsomlo]

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.

[Comet959]

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 chipsalliance/rocket-chip#3296 , but I still haven't figured out how to support H extension specifically. Can you explain it to me?
@gsomlo

[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 #1878 (comment)