Where communities thrive

  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
Repo info
  • Jun 18 12:45
    Dolu1990 commented #448
  • Jun 18 12:40
    piegamesde commented #448
  • Jun 18 12:26
    typingArtist commented #448
  • Jun 18 10:56
    Dolu1990 commented #284
  • Jun 18 10:54
    Dolu1990 commented #448
  • Jun 17 15:08
    jiegec commented #449
  • Jun 17 14:51
    kartikp4892 opened #449
  • Jun 17 07:22
    kartikp4892 commented #438
  • Jun 17 07:21
    kartikp4892 closed #438
  • Jun 17 07:21
    kartikp4892 commented #438
  • Jun 17 07:19
    kartikp4892 commented #438
  • Jun 16 14:33

    Dolu1990 on scala_2.12_dev

    version++ Binary mux are now symplifed wh… Merge branch 'dev' into scala_2… (compare)

  • Jun 16 11:58

    Dolu1990 on dev

    Binary mux are now symplifed wh… (compare)

  • Jun 16 10:52
    piegamesde commented #284
  • Jun 16 10:47
    piegamesde opened #448
  • Jun 16 10:12
    volatile-static commented #445
  • Jun 16 10:12
    volatile-static commented #445
  • Jun 16 09:11
    Dolu1990 commented #445
  • Jun 16 09:11
    Dolu1990 commented #445
  • Jun 16 09:09
    volatile-static commented #445

Im trying to do a cross compilation of a linux module on fpga under linux v5.10.1 (SpinalSaxon)
the toolchain is version = 8.3.0-1.2
I downloaded v5.10.1 and extracted the kernelheaders to compile with ,
when loading, it tells me invalid ELF headers on the target
Invalid ELF headers.

on buildroot , kernel headers are same as kernel being build .

I tried to cross compile a helloworld.c with riscv-none-embed-gcc , the same toolchain as the Saxonspinal but i have
helloworld [201]: unhandled signal 4 code 0x1 at 0x000100ac in helloworld[10000+3000] on the target

what is the problem ?
thank you

i never tried to compile a kernel module as a .ko
usualy, i tried to stick everything to the buildroot flow toi avoid too much enoyance XD
i'm not sure to understand
You want to compile a user space app ?
or a kernel module ?
one thing is that the toolchaine used to compile bootloaders and barmetal apps isn't the same than the one used to compile linux apps

Let's suppose I did something like this :

 val testApbBmb = BmbToApb3Generator(SizeMapping(0x38000, 4 KiB))
    addressWidth = 32,
    dataWidth = 32
  val testApbArea = Handle(new Area {
    val myreg = Reg(UInt(32 bit)).init(U"x03020100")
    val busCtrl = Apb3SlaveFactory(testApbBmb.output)
    busCtrl.readAndWrite(myreg, address = 0x8000)

is it normal, that accessing to the address where the apb is mapped ( here is 0x10038000 ) produces an address on PADDR = 0x8000, instead of zero ?

im trying to compile my module on my computer and load it to the fpga : cross compilation , i use this script to generate kernelheaders from the linux used on the fpga
#prepare linux headers  to Cross Compile module 


    export PATH=~/opt/xpack-riscv-none-embed-gcc/bin:$PATH


    cd /home/tiempo/Documents/LarbiIntership/Ipc_driver/compiled/cross_com/linux

    make  ARCH=riscv  CROSS_COMPILE=$Prefix O=$KernelHeader  mrproper;

    make  ARCH=riscv  CROSS_COMPILE=$Prefix O=$KernelHeader        defconfig;

    make -j 8 ARCH=riscv  CROSS_COMPILE=$Prefix O=$KernelHeader  modules_prepare;
@sabbari There no operation done on the address itself, it always go through, so, maybe the issue is that the addressWidth of the apb config is too large
Basicaly, instead of addressWidth = 32, should have addressWidth = 12, ?
@Aliliche What are you defining as a module ?
a kernel module ? (.ko) ?
One thing, is that ARCH=riscv is likely not enough
Normaly, when using a RISC-V gcc which support multiple arch configuration, you need :
@Dolu1990 in my Makefile
If KERNELRELEASE is defined, we've been  invoked from the kernel build system
# and can use its language 


    obj-m :=  tiempo_ipc.o

#Otherwize we were called directly from the command line ; invlok kbuild system 

    KERNELDIR ?="./KernelHeaders/"
    PWD := $(shell pwd)
.PHONY : modules
    $(MAKE)  -C $(KERNELDIR)  M=$(PWD) modules


.PHONY: clean 
    $(MAKE) -C $(KERNELDIR) M=$(PWD) clean 

CFLAGS_tiempo_ipc.o := -DDEBUG
and this is the script for compialtion
and this is the script for compilation

    export PATH=$PATH:/home/tiempo/opt/xpack-riscv-none-embed-gcc/bin

#build module 
    make  ARCH=riscv  CROSS_COMPILE=riscv-none-embed-

#info module

    echo "module informations"

    modinfo tiempo_ipc.ko
-march=rv32imafdc -mabi=ilp32d
(in the case you have the very recent version of SaxonSoc Arty which has the FPU and the compressed instruciton set)
To be honnest, i have no idea which compilation toolchaine should be used to compile a .ko
1 reply
The thing about the xpack stuff is that is made to compile baremetal things
maybe, adding the module into the kernel used by the SaxonSoc buildroot, selecting that module in the menuconfig, and then looking how buildroot/linux compiles it could help
@Dolu1990 , I try to only enable reset mode to async, the fmax changes from 99 to 105. in other words, the other two items matter more than reset. I'd like to ask what's the trade off by enabling them: InstructionCacheConfig =>
twoCycleRam = false,
twoCycleCache = true,
IBusCachedPlugin =>
injectorStage = true,
@Dolu1990 this is what i am doing , it work well , but it takes time because the linux is booted in ram.
i have to rebuild and load every time i change something on code . and i have to do some stuff i user space so i need to cross compile codes cause we dont have compiler on buildroot
for dev, what i usualy do, is linux in a tftp and the filesystem in a nfs

when the wfi is active, then you can be sure that nor the fetch, nor the data cache are requesting stuff

Is there some minimum cycle delay after issuing wfi after which the disabling is safe?


the ibus will still be active

Does this really matter? If the core is disabled (or more like frozen), doesn't pc simply stay at whatever value it was at that time? If so, the IBus memory would simply keep feeding the same rsp back to the core and the core would simply continue from where it left off after being enabled again.
The DBus interface is another thing, though, since there's muxing involved.


Basicaly, instead of addressWidth = 32, should have addressWidth = 12, ?

@Dolu1990 . Yes by reducing the address width it works, but if I imagine a scenario where the APB is mapped to an address that doesn't end with zeros, then it will not work. Anyway, I just wanted to be sure about this.
Thank you for your response :)

@selendym Now that i think about it, one ibus may be in flight :/

Does this really matter?

Yes, because the i$ will miss the bus response, and will be stuck there forever

the IBus memory would simply keep feeding the same rsp

But some additional logic will be required

So to me, the best solution would realy be to monitor the bus activity externaly
When you want to halt the CPU then you will have to halt all new trafic going out of the CPU (But not halt the travis which was already on the bus)
And wait that all ongoing transactions are done
and finaly you can clear the clock enable
why it repose this error?
i configed the baudrate,and can generateVerilog

Is there any way to generate register array in verilog? For example if I write below in spinalHDL

val data = Vec(UInt(8 bits), 1024)

I want it generate register array in verilog as shown below:

reg [7:0] data[1024];

Not sure if Vec has some configuration to do that?
Basically Vec generates data_1, data_2, data_3......data_1024 and make generated verilog file too long.

@WANGHAITAO-FPGA All good ? you set the SpinalConfig(defaultClockDomainFrequency = FixedFrequency(100 MHz))).generateVerilog(xxx) ?
@kartikp4892 You want to infer a ram block ? if yes, then use Mem instead of Vec
Ah ok. Mem works. Thanks
Hi, @Dolu1990 . I'd like to ask what's the trade off by enabling them: InstructionCacheConfig => twoCycleRam = false,
twoCycleCache = true,
IBusCachedPlugin => injectorStage = true.
@Dolu1990 . btw, i just tried generating Vex with new spinal v1.5 release, it's amazing.. only a few unnamed _zz_xx left now. well done! :)
Mostly, branch penality
thanks ^^
So, still many name are infered using https://spinalhdl.github.io/SpinalDoc-RTD/SpinalHDL/Structuring/naming.html#in-last-resort, which isn't always greate