RaYmAn has quit [Remote host closed the connection]
RaYmAn has joined #litex
RaYmAn has quit [Client Quit]
RaYmAn has joined #litex
<mc6808>
_florent_: tristates don't seem to be generated correctly for spiflash on any of the efinix boards. I get:
<mc6808>
[EFX-0265 ERROR] Bi-directional port 'spiflash_mosi' is not supported in this device.
<trabucayre>
mc6808: in fact you have to provides at top verilog IN, OUT, OE pins instead of inout ...
<trabucayre>
but for iface.py you have to provides spi_flash_mosi ...
<mc6808>
trabucayre: Yes: The signals in .peri.xml are actually: spiflash_mosi_{IN,OUT,OE}. I'm not sure how to tweak the verilog generation...
<trabucayre>
I've spent time this week-end to find a way to fix this issue...
<trabucayre>
maybe copy io dict in get_verilog to replace spiflash_{mosi,miso} by the 3 required signals ...
<_florent_>
mc6808, trabucayre: For now Bi-directionnal IOs are indeed not yet supported. I'll also have a closer look at it. With the Efinix toolchain, you are not doing instances of the IOs/PLL primitives in your HDL but you have to expose the primitives' ports at the top level, which is a bit different than traditionnal approaches and so need to be integrated correctly in the LiteX flow. _franck_ already did this work for the PLL, but we have to
<_florent_>
also do it for the IOs and other eventual primitives requiring it.
<_florent_>
_franck_: Thanks. I think it should be possible to encapsulate this in a SDRTristate special as we are doing with the other toolchains (but without requiring passing the platform as you suggested when we discussed together). I'll try to do a test on this (QSPI Flash / I2C are good candidate to test this).
<tnt>
err, this is just awful ... ( the efinix approach ) ...
zjason` is now known as zjason
<_florent_>
tnt: This is clearly not simplifying things... and should probably have been handled by the toolchain. With LiteX/Python we still have some flexibility to abstract this and make it similar to the other toolchains but this is going to be more painful when doing regular Verilog/SV/VHDL designs where you'll have almost similar constraints than when designing ASICs with an IO Pad Ring.
<_florent_>
tnt: But even with LiteX, it will only works fine for native LiteX code, when importing external code, we'll also have to modify it (integrating a verilog core with a tristate IO will not be possible without modification).
<_florent_>
Maybe they'll reconsider this choice later and will revisit the toolchain to handle this
<tnt>
Yeah ... PLL instances signals having to be brought to top-level IO ... iewww ... Is it the same for instances of BRAMs ?
<_florent_>
tnt: no, RAM/DSPs are considered in the fabric/digital part :)
<_florent_>
Hi indy, PCIe on ECP5 is not currently supported in LiteX. It would requires using the use of the proprietary Lattice PHY or the one from PLDA ($$$) or having an open-source PCIe PHY (which would probably be something between 3-6 months full time work to have something usable).
<_florent_>
I already used the one from PLDA on ECP3/ECP5, it's working fine but you have to pay $$$ for it... :)
<tpb>
Title: ECP5-PCIe/ECP5-PCIe: A PCIe interface for the ECP5 FPGA written in nMigen - ECP5-PCIe - Codeberg.org (at codeberg.org)
<_florent_>
indy: This is interesting yes but this would still requires probably requires a few weeks/months of work.
<_florent_>
indy: This would be interesting to explore this further, but for now I'm not aware of anyone looking at it.
<_florent_>
One of the aims of the Acorn baseboard is also to be able to capture/record SerDes based links and being able to capture PCIe with it could be useful to create a PCIe PHY
mc6808_ has joined #litex
<mc6808_>
_florent_: a special for SDRTristate sounds good, I was hoping it could be done like this in some way and was going to have a look. But I've got a bit of learning to do feel truely useful in this space :)
mc6808_ has quit [Client Quit]
kgugala has quit [Quit: WeeChat 3.3]
Guest78 has quit [Quit: Client closed]
mc6808 has quit [Quit: Client closed]
indy has quit [Read error: Connection reset by peer]
indy has joined #litex
indy has quit [Ping timeout: 260 seconds]
indy has joined #litex
C-Man has quit [Ping timeout: 258 seconds]
<mntmn>
quick risc-v noob question: when using CROSS_COMPILE=riscv64-linux-gnu-, how do i make sure the binary targets rv32ima?
<cr1901>
I thought litex chooses the right arch for you based on the core/variant you chose
<cr1901>
the right set of riscv extensions*
<mntmn>
yeah, but my goal is to cross compile some extra binaries outside of litex to run on the target
<mntmn>
possibly i want crosstool-ng and a special toolchain for rv32ima?
<cr1901>
Oh, I think I misunderstand what you want and can't help you, sorry :(
<mntmn>
ok, no problem
<cr1901>
(As in "I don't know", not "I don't want to help" :P)
<mntmn>
ah i see now that buildroot already built/checked out a riscv32-... toolchain
<tnt>
mntmn: -march=rv32i -mabi=ilp32
<tnt>
or rv32ima I guess in your case.
<mntmn>
tnt: thanks. i tried that and it _almost_ works.
<tnt>
almost ?
andresmanelli has joined #litex
<mntmn>
tnt: yeah
<mntmn>
tnt: i need to point it to the 32 bit libs etc
<mntmn>
currently i get problems when linking with libc like "ABI is incompatible with that of the selected emulation"
<mntmn>
> target emulation `elf64-littleriscv' does not match `elf32-littleriscv'
<mntmn>
i guess i should rather build a rv32 toolchain from scratch
<tnt>
That should work just fine ...
<tnt>
But if you're doing compilation and linking in separate steps, you'll need equivalent options for the linker I guess.
<tnt>
I just give all my sources to gcc in one call and directly produce the output binary, so it knows how to call the linker properly.
<mntmn>
yeah, in my case i was trying to cross compile an existing package and that would be a bit more involved
<tnt>
did you make sure you had the march and mabi option in LDFLAGS too ?
<mntmn>
no, let me try
<mntmn>
tnt: the remaining problem is that i have to tell ld the path to the 32 bit libc.so.6 somehow
<mntmn>
by default it wants to use /lib32/libc.so.6 which is x86
<mntmn>
i guess the risc64 toolchain in debian is not "multilib"
<tnt>
huh, if it's trying to read x86 that's nothing to do with risc32 vs riscv64
<tnt>
you probably need a -sysroot something or some other cross compile magic. I only build embedded firmware nothing "applicative" that links dynamically.
<acathla>
I have 4 instances of the same module, how can I access them in a loop? Something like "self.submodules.name[i] = MYMODULE()" would be nice
<tnt>
you might have to encode the name ... setattr(self.submodules, 'name_%d' % i, MYMODULE()) and getattr(self.submodules, 'name_%d' % i)
<acathla>
That seems to work, thanks tnt
<acathla>
except that I need to getattr(self, ... instead of self.submodules, same as usual in migen
<mntmn>
tnt: in the meantime i built a riscv32 toolchain and it works fine
<_florent_>
already validated with Linux-on-Litex-Vexriscv
<mntmn>
_florent_: can it be used as a host?
<_florent_>
yes
<mntmn>
_florent_: ah that's awesome... the only problem is that i have an ULPI phy chip in the way
<DerekKozel[m]>
I'll grab your openocd and try it
<DerekKozel[m]>
Thanks
<DerekKozel[m]>
Thanks ilia__s for the info as well
<DerekKozel[m]>
I'm rushing a little to update our setup here for a student's final demo. We have a known working setup, but hoping to get a small processing block connected to the LitePCIe and show that it all works with the latest.
<_florent_>
mntmn: Otherwise, a few weeks ago I started playing with Ultraembedded's USB CDC device core, havent' spent enough time to got it working, but it can maybe be useful to create a wrapper around the USB Host core:
<_florent_>
mntmn: I think Melkhior here is also using it
<DerekKozel[m]>
Bother. building OpenOCD is triggering errors.
<_florent_>
ilia__s: I'm not sure, but that's possible there was a software write protection enabled by default on the Acorn
<ilia__s>
well, I for sure modified some flash content, it does not boot anymore
<_florent_>
ilia__s: I remember having troubles flashing the Acorn at some point, I'll do a test tomorrow
<DerekKozel[m]>
solved build error by adding -no-pie
<DerekKozel[m]>
Thanks Florent
<DerekKozel[m]>
I'm noticing that the kernel module isn't logging any messages to dmesg, but I can see with modprobe -vv that it's registering a custom logger. Have the messages moved?
<mntmn>
_florent_: thanks, that gist is interesting
<_florent_>
DerekKozel[m]: the driver code hasn't been modified recently
<DerekKozel[m]>
Oh! it found the flash but dies with errors during writing.
<_florent_>
ilia__s: Thanks, I'll push the change to the repo tomorrow
mc6808 has joined #litex
<DerekKozel[m]>
Worked here too. And Flashing successfully worked around getting the kernel to persist the image despite thunderbolt power cycling even on a hot reboot
<DerekKozel[m]>
edit-> image persists, thus kernel picks it up correctly.