Fail to boot Linux with FPU enabled #331
Comments
|
Hi, There was a recent update related to the FPU, it maybe related. Can you send me your opensbi / Linux / Buildroot images ? What git hash do you have for the pythondata-cpu-vexriscv_smp ? Thanks :D |
|
hmm also, if you can send me your linux elf file that would be great :D |
|
Keep in mind that I'm not using the standard memory map, this is my boot.json: With RAM being from 0xb0000000 to 0xd0000000. The linux kernel version is the latest one that comes with cloning http://github.com/buildroot/buildroot, and I'm using master for pythondata-cpu-vexriscv_smp. For the Linux elf file give me a little bit of time, because I need to regenerate it. In the meantime, I'll try with the commit you suggested. Thanks for the quick response! |
|
I still get the same errors with the suggested commit. This is my .elf: |
|
If it helps, this is my linux.config: And this is my litex_vexriscv_defconfig: |
Hooo, hmmm Is the first bug : Appearing each time you run the system ? or sometime it changes ? |
|
Also, thanks for all the file / info ^^ |
|
It appears each time. The other ones sometimes change depending on the compilation flags (FPU=y/n, RVC=y/n). |
|
So currently i have simulations running with linux-on-litex-vexriscv One thing, about litex-hub/pythondata-cpu-vexriscv_smp@e8ce95b, Also, were you testing with a fresh Litex install ? (To have a idea of the setup ^^) |
|
Can you send me your dts ? (device tree) |
|
I'm generating the .v outside of linux-on-litex-vexriscv, so no problem there! Yes, I have a fresh litex install (maybe one day old). Here is my dts: I also tried simulating the system with renode and everything worked fine and I was able to boot linux, so I think that the software stack is correctly generated. |
|
Hmmm, so yeah, probably some hardware issue, the only thing i can think about to track dawn the issue / regression cause would be to test with |
|
So i found something, your config use main memory mapped at > 0x80000000 |
|
Here is the hardcoded uncached memory range specification : Could be in your case : |
|
Sorry, I forgot to mention that I have the following diff in pythondata-cpu-vexriscv_smp: diff --git a/src/main/scala/vexriscv/demo/smp/VexRiscvSmpLitexCluster.scala b/src/main/scala/vexriscv/demo/smp/VexRiscvSmpLitexCluster.scala
index 3454577..a58aca4 100644
--- a/src/main/scala/vexriscv/demo/smp/VexRiscvSmpLitexCluster.scala
+++ b/src/main/scala/vexriscv/demo/smp/VexRiscvSmpLitexCluster.scala
@@ -151,8 +151,8 @@ object VexRiscvLitexSmpClusterCmdGen extends App {
cpuConfigs = List.tabulate(cpuCount) { hartId => {
val c = vexRiscvConfig(
hartId = hartId,
- ioRange = address => address.msb,
- resetVector = 0,
+ ioRange = address => (address(31 downto 28) === 0x3),//0x3),
+ resetVector = 0xA0000000l,//0xA0000000l,
iBusWidth = iBusWidth,
dBusWidth = dBusWidth,
iCacheSize = iCacheSize,
@@ -321,4 +321,4 @@ object VexRiscvLitexSmpClusterOpenSbi extends App{
}
}
}
-}
\ No newline at end of file
+} |
|
I may have found a potential problem. I have the following example code: What I'm seeing in my simulation is that, when the data_width is 32 bits, then this code translates to what it should: a 32-bit read to address 0x30012004, followed by a 32-bit write to address 0x30012000. But when data_width is 64 bits, then I see a 64-bit read to address 0x30012000, followed by a 32-bit write to address 0x30012000. Which means that if address 0x30012000 has a register that does something after reading it, this could be changing the expected behavior. Which would explain why when data_width is 32 bits, I'm seeing: And when data_width is 64 bits, I'm seeing: That would explain the weird behavior for the uart, and could also explain why the kernel fails to boot in case something like that is happening anywhere else. |
|
Hoo nice :) |
|
The simulation with the basic example goes back to working as expected, I'm synthesizing now with fpu=True to check whether it works in hw. Is this 64-bit bus access "bug" a real bug or is it a feature? I just saw a read transaction that shouldn't be there, but there may be other stuff like that which eventually caused linux to fail at boot. Thanks again for the help :) |
|
so, i think it's mostly some missmatch between the Wishbone config from the SpinalHDL side and the litex side. So mostly, a configuration bug. Probably we should just enfoce the wishbone to always be 32 bits no matter what. Thanks too ^^ |
|
With this configuration, I can't even boot the bios.bin. And I think it's got something to do with the fact that I'm now seeing some transactions with SEL=0 in the simulation. Like this: Or like this: Currently, my architecture is just ignoring those accesses and returning ACK immediately without forwarding that transaction to the actual memory, but I don't know if that's what the cpu expects and if that may be what's causing the problems. |
|
I got it to work. But when I got to Linux, I got the same errors as in the beginning. Linux starts to boot, but then it gets a lot of errors and it ends with a kernel panic. Seems to be something specific of the FPU. |
Yes, this can happen when a SC (store conditional) is rejected.
That should be good. So if i understand well, all the memory request are going to the wishbone in your case ? no litedram involved right ? |
|
Yes, that's correct. Everything's going to the wishbone and I'm not using the litedram. Along with all the binaries, I could send you the verilog I'm using if it helps to reproduce the problem. |
|
Sure that could help :) |
|
Here is everything: |
|
Hi, sorry for the delay :/ So i tried on my side on some hardware, and things seems to work fine on my tests. (linux 5.10 and 6.2 are ok with rv32imafdc) |
|
Hello, no worries. The git hash of the buildroot repo is 61ba55e9cce6884295e47fdf33554e6877bd0747 and the git hash for the linux repo inside buildroot is ae80e67c6b48bbedcd13db753237a25b3dec8301. |
|
Hi, I'm not successfuly reproducing the issue XD Do you have a way to run a simulation of you system until the crash happen ? |
I successfully booted Linux with FPU disabled. When I enable FPU, I get the following errors:
After that:
After that, some more warnings/errors, and finally:
This is all using the same bios.bin/opensbi.bin/Image/rootfs.cpio/rv32.dtb that the one that works if the bitfile doesn't have FPU (compiled with abi=ilp32 arch=rv32i).
I get the same errors if I specifically compile Linux/Buildroot using the FPU/ISA_F/ISA_D flags, and using abi=ilp32d and arch=rv32imafdc.
The configuration I'm using is:
--cpu-count 1 --dcache-width 64 --icache-width 64 --dcache-ways 1 --icache-ways 1 --without-coherent-dma --dtlb-size 4 --itlb-size 4 --dcache-size 4096 --icache-size 4096 --with-fpu --with-wishbone-memory --with-rvc
The board is a SmartFusion2 running at 80MHz without timing failures.
Please let me know if I can provide any more information.
The text was updated successfully, but these errors were encountered: