| *** tpb <[email protected]> has joined #litex | 00:00 | |
| *** shoragan <shoragan!~shoragan@user/shoragan> has quit IRC (Ping timeout: 250 seconds) | 00:53 | |
| *** shoragan <shoragan!~shoragan@user/shoragan> has joined #litex | 00:56 | |
| mc6808 | _florent_: I've created PR for litex and litex-boards with some efinix tweaks and basic xyloni support | 02:04 |
|---|---|---|
| *** TMM_ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 02:14 | |
| *** TMM_ <[email protected]> has joined #litex | 02:14 | |
| *** Degi <[email protected]> has quit IRC (Ping timeout: 252 seconds) | 02:38 | |
| *** Degi <[email protected]> has joined #litex | 02:39 | |
| *** RaYmAn <[email protected]> has quit IRC (Remote host closed the connection) | 03:48 | |
| *** RaYmAn <[email protected]> has joined #litex | 05:33 | |
| *** RaYmAn <[email protected]> has quit IRC (Client Quit) | 05:34 | |
| *** RaYmAn <[email protected]> has joined #litex | 05:34 | |
| mc6808 | _florent_: tristates don't seem to be generated correctly for spiflash on any of the efinix boards. I get: | 05:46 |
| mc6808 | [EFX-0265 ERROR] Bi-directional port 'spiflash_mosi' is not supported in this device. | 05:46 |
| trabucayre | mc6808: in fact you have to provides at top verilog IN, OUT, OE pins instead of inout ... | 05:47 |
| trabucayre | but for iface.py you have to provides spi_flash_mosi ... | 05:48 |
| 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... | 05:49 |
| trabucayre | I've spent time this week-end to find a way to fix this issue... | 05:53 |
| trabucayre | maybe copy io dict in get_verilog to replace spiflash_{mosi,miso} by the 3 required signals ... | 05:54 |
| _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 | 06:23 |
| _florent_ | also do it for the IOs and other eventual primitives requiring it. | 06:23 |
| _franck_ | I did this in order to use i2c: https://github.com/fjullien/efinix_litex_board/blob/main/video/simple_hdmi.py#L174-L231 | 06:46 |
| _franck_ | It's not automated for now | 06:47 |
| _franck_ | mc6808, trabucayre: ^ | 06:47 |
| indy | hi all, any update on ecp5 pcie? | 06:53 |
| *** FabM <[email protected]> has joined #litex | 06:59 | |
| *** _franck_5 <[email protected]> has joined #litex | 07:09 | |
| *** _franck_ <[email protected]> has quit IRC (Ping timeout: 245 seconds) | 07:11 | |
| *** _franck_5 is now known as _franck_ | 07:11 | |
| _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). | 07:15 |
| tnt | err, this is just awful ... ( the efinix approach ) ... | 07:23 |
| *** zjason` is now known as zjason | 07:29 | |
| _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. | 07:31 |
| _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). | 07:33 |
| _florent_ | Maybe they'll reconsider this choice later and will revisit the toolchain to handle this | 07:35 |
| tnt | Yeah ... PLL instances signals having to be brought to top-level IO ... iewww ... Is it the same for instances of BRAMs ? | 07:35 |
| _florent_ | tnt: no, RAM/DSPs are considered in the fabric/digital part :) | 07:41 |
| _florent_ | https://www.efinixinc.com/art/trion-block-diagram.png | 07:41 |
| _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). | 08:19 |
| _florent_ | I already used the one from PLDA on ECP3/ECP5, it's working fine but you have to pay $$$ for it... :) | 08:20 |
| indy | _florent_, i was watching https://codeberg.org/ECP5-PCIe/ECP5-PCIe and it looked promising | 08:27 |
| tpb | Title: ECP5-PCIe/ECP5-PCIe: A PCIe interface for the ECP5 FPGA written in nMigen - ECP5-PCIe - Codeberg.org (at codeberg.org) | 08:27 |
| _florent_ | indy: This is interesting yes but this would still requires probably requires a few weeks/months of work. | 08:33 |
| _florent_ | indy: This would be interesting to explore this further, but for now I'm not aware of anyone looking at it. | 08:35 |
| _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 | 08:36 |
| *** mc6808_ <[email protected]> has joined #litex | 08:39 | |
| 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 :) | 08:42 |
| *** mc6808_ <[email protected]> has quit IRC (Client Quit) | 08:44 | |
| *** kgugala <[email protected]> has quit IRC (Quit: WeeChat 3.3) | 09:44 | |
| *** Guest78 <[email protected]> has quit IRC (Quit: Client closed) | 11:19 | |
| *** mc6808 <[email protected]> has quit IRC (Quit: Client closed) | 11:43 | |
| *** indy <[email protected]> has quit IRC (Read error: Connection reset by peer) | 12:11 | |
| *** indy <[email protected]> has joined #litex | 12:12 | |
| *** indy <[email protected]> has quit IRC (Ping timeout: 260 seconds) | 12:17 | |
| *** indy <[email protected]> has joined #litex | 12:20 | |
| *** C-Man <[email protected]> has quit IRC (Ping timeout: 258 seconds) | 12:33 | |
| mntmn | quick risc-v noob question: when using CROSS_COMPILE=riscv64-linux-gnu-, how do i make sure the binary targets rv32ima? | 12:47 |
| cr1901 | I thought litex chooses the right arch for you based on the core/variant you chose | 12:48 |
| cr1901 | the right set of riscv extensions* | 12:49 |
| mntmn | yeah, but my goal is to cross compile some extra binaries outside of litex to run on the target | 12:49 |
| mntmn | possibly i want crosstool-ng and a special toolchain for rv32ima? | 12:50 |
| cr1901 | Oh, I think I misunderstand what you want and can't help you, sorry :( | 12:51 |
| mntmn | ok, no problem | 12:51 |
| cr1901 | (As in "I don't know", not "I don't want to help" :P) | 12:51 |
| mntmn | ah i see now that buildroot already built/checked out a riscv32-... toolchain | 12:52 |
| tnt | mntmn: -march=rv32i -mabi=ilp32 | 12:56 |
| tnt | or rv32ima I guess in your case. | 12:56 |
| mntmn | tnt: thanks. i tried that and it _almost_ works. | 12:57 |
| tnt | almost ? | 12:58 |
| *** andresmanelli <[email protected]> has joined #litex | 12:59 | |
| mntmn | tnt: yeah | 13:00 |
| mntmn | tnt: i need to point it to the 32 bit libs etc | 13:01 |
| mntmn | currently i get problems when linking with libc like "ABI is incompatible with that of the selected emulation" | 13:02 |
| mntmn | > target emulation `elf64-littleriscv' does not match `elf32-littleriscv' | 13:02 |
| mntmn | i guess i should rather build a rv32 toolchain from scratch | 13:06 |
| tnt | That should work just fine ... | 13:10 |
| tnt | But if you're doing compilation and linking in separate steps, you'll need equivalent options for the linker I guess. | 13:10 |
| 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. | 13:11 |
| mntmn | yeah, in my case i was trying to cross compile an existing package and that would be a bit more involved | 13:23 |
| tnt | did you make sure you had the march and mabi option in LDFLAGS too ? | 13:26 |
| mntmn | no, let me try | 13:30 |
| mntmn | tnt: the remaining problem is that i have to tell ld the path to the 32 bit libc.so.6 somehow | 13:33 |
| mntmn | by default it wants to use /lib32/libc.so.6 which is x86 | 13:35 |
| mntmn | i guess the risc64 toolchain in debian is not "multilib" | 13:37 |
| tnt | huh, if it's trying to read x86 that's nothing to do with risc32 vs riscv64 | 13:56 |
| tnt | you probably need a -sysroot something or some other cross compile magic. I only build embedded firmware nothing "applicative" that links dynamically. | 13:57 |
| 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 | 14:04 |
| tnt | you might have to encode the name ... setattr(self.submodules, 'name_%d' % i, MYMODULE()) and getattr(self.submodules, 'name_%d' % i) | 14:06 |
| acathla | That seems to work, thanks tnt | 14:29 |
| acathla | except that I need to getattr(self, ... instead of self.submodules, same as usual in migen | 14:30 |
| mntmn | tnt: in the meantime i built a riscv32 toolchain and it works fine | 14:34 |
| mntmn | tnt: this one https://github.com/riscv-collab/riscv-gnu-toolchain | 14:34 |
| *** andresmanelli <[email protected]> has quit IRC () | 15:57 | |
| *** TMM_ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 16:02 | |
| *** TMM_ <[email protected]> has joined #litex | 16:02 | |
| mntmn | are there any usb (1/2/3) host controller solutions compatible with linux-on-litex-vexriscv? | 17:13 |
| mntmn | assuming i have an external ULPI PHY | 17:21 |
| mntmn | i guess i would need some kind of generic UTMI implementation in FPGA and a host controller driver for that? | 17:33 |
| *** C-Man <[email protected]> has joined #litex | 17:35 | |
| *** shenki <[email protected]> has quit IRC (Ping timeout: 268 seconds) | 17:59 | |
| DerekKozel[m] | _florent_: Does the --flash option work on the CLE-215+ via JTAG? I get:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/3c1a0a85e0dbb231aad19cafcd774c5c4ebfe1e6) | 18:08 |
| *** shenki <[email protected]> has joined #litex | 18:11 | |
| *** photon70 <[email protected]> has joined #litex | 18:18 | |
| *** photon70 <[email protected]> has quit IRC (Quit: Lost terminal) | 18:23 | |
| *** Wolf0 <Wolf0!~Wolf0@user/wolf0> has quit IRC (Ping timeout: 240 seconds) | 18:23 | |
| *** Wolf0 <Wolf0!~Wolf0@user/wolf0> has joined #litex | 18:23 | |
| *** zjason` <zjason`[email protected]> has joined #litex | 19:25 | |
| *** zjason <[email protected]> has quit IRC (Ping timeout: 252 seconds) | 19:27 | |
| ilia__s | DerekKozel[m]: does not work for me yet; detects s25fl256s, modifies some content but fails at verification | 20:03 |
| ilia__s | with latest openocd | 20:03 |
| _florent_ | DerekKozel[m]: IIRC it was working (with https://github.com/enjoy-digital/openocd) | 20:08 |
| _florent_ | I could test tomorrow | 20:09 |
| _florent_ | mntmn: For USB 1, there is the USB OHCI core: https://github.com/enjoy-digital/litex/blob/master/litex/soc/cores/usb_ohci.py | 20:12 |
| _florent_ | already validated with Linux-on-Litex-Vexriscv | 20:12 |
| mntmn | _florent_: can it be used as a host? | 20:17 |
| _florent_ | yes | 20:17 |
| mntmn | _florent_: ah that's awesome... the only problem is that i have an ULPI phy chip in the way | 20:18 |
| DerekKozel[m] | I'll grab your openocd and try it | 20:18 |
| DerekKozel[m] | Thanks | 20:18 |
| DerekKozel[m] | Thanks ilia__s for the info as well | 20:18 |
| 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. | 20:19 |
| _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: | 20:22 |
| _florent_ | https://gist.github.com/enjoy-digital/92f80584727e171fc2af76766b83a3ba | 20:22 |
| ilia__s | _florent_: your fork of openocd fails the same way | 20:24 |
| _florent_ | mntmn: for the OHCI core: https://twitter.com/enjoy_digital/status/1397470599262482433 | 20:25 |
| _florent_ | mntmn: I think Melkhior here is also using it | 20:26 |
| DerekKozel[m] | Bother. building OpenOCD is triggering errors. | 20:29 |
| _florent_ | ilia__s: I'm not sure, but that's possible there was a software write protection enabled by default on the Acorn | 20:30 |
| ilia__s | well, I for sure modified some flash content, it does not boot anymore | 20:31 |
| _florent_ | ilia__s: I remember having troubles flashing the Acorn at some point, I'll do a test tomorrow | 20:31 |
| DerekKozel[m] | solved build error by adding -no-pie | 20:32 |
| DerekKozel[m] | Thanks Florent | 20:32 |
| 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? | 20:32 |
| mntmn | _florent_: thanks, that gist is interesting | 20:34 |
| _florent_ | DerekKozel[m]: the driver code hasn't been modified recently | 20:34 |
| DerekKozel[m] | Oh! it found the flash but dies with errors during writing. | 20:34 |
| DerekKozel[m] | https://pastebin.com/Wp691uG2 | 20:34 |
| tpb | Title: make: Leaving directory '/home/dkozel/src/litex/build/sqrl_acorn/software/bios' - Pastebin.com (at pastebin.com) | 20:34 |
| DerekKozel[m] | Thanks for the confirmation. I'll dig more into my setup for the kernel module. | 20:35 |
| _florent_ | DerekKozel[m]: That's possible doing something similar to https://github.com/enjoy-digital/openocd/commit/d481b0ac66c97881a4301c175748153a25c63e6b to the SPI Flash used on the Acorn would allow you to write correctly | 20:37 |
| DerekKozel[m] | Ok. I'll try that, thanks | 20:38 |
| *** Guest78 <[email protected]> has joined #litex | 20:39 | |
| _florent_ | here: https://github.com/enjoy-digital/openocd/blob/d481b0ac66c97881a4301c175748153a25c63e6b/src/flash/nor/spi.c#L60 | 20:40 |
| _florent_ | change 0xdc to 0xd8 | 20:41 |
| ilia__s | _florent_: this worked! | 20:51 |
| _florent_ | ilia__s: Thanks, I'll push the change to the repo tomorrow | 20:59 |
| *** mc6808 <[email protected]> has joined #litex | 21:52 | |
| 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 | 22:55 |
| DerekKozel[m] | edit-> image persists, thus kernel picks it up correctly. | 22:55 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
