08:36 <benh> _florent_: hola ! do you happen to know which one is pin 2 on the picoezmate connector ? (the jtag one for the acorn)

08:38 <benh> the pin on the flash side or tthe pin on the side of the other pico (P2) ?

08:38 <benh> if you don't know I'll dig out the multimeter... it's just in a box between offices right now

08:51 <zyp> I asked the same question a couple of weeks ago :)

08:52 <zyp> 12:06:26 < zyp> wiring up jtag to my cle-215 now, can somebody confirm which end of the connector is pin 1?

08:52 <zyp> 12:15:33 < zyp> nevermind, I measured it out, pin 1 is closest to the m.2 connector edge

10:02 <benh> zyp: hehe, so towards the flash chip

10:03 <benh> with my phone zooming I can see a faint triangle pointing at it which I can't see with my bare eyes so that's matches :)

10:03 <benh> probably too tired to do a half decent soldering job tonight tho

12:32 <benh> allright, time to try this thing out, jtag seems to work

12:32 <benh> $ ./acorn_cle_215.py --build --with-pcie --driver

12:32 <benh> litex.build.generic_platform.ConstraintError: Resource not found: serial:None

12:32 <benh> (skipped the backtrace)

12:32 <benh> I must be missing something...

12:34 <benh> ah --uart-name=crossover... should be default for acorn

12:44 <benh> on another note, how does litex --load or --flash work ? openocd ? How do I teach it about my hacked up FTDI JTAG cable ?

12:44 <benh> I've hacked up xc3sprogs...

12:53 <_florent_> benh: yes we should improve default/unsupported config, i have ideas on it but need to work on others things first

12:54 <benh> _florent_: we need a PCI vendor ID :-)

12:54 <benh> or ask a vendor to donate us a few device IDs ;-)

12:54 <benh> interesting, the horrid fan on that thing speeds up during programming... I thought it was running at a fixed speed of the 3.3v rail..

12:56 <_florent_> benh: it's indeed probably controlled by one IO with a PWM

12:57 <benh> ok, I'll look at the schematics again later

12:57 <benh> what is that litex_server referenced on the github issue ?

12:58 <zyp> schematics says fan gets fixed 3.3V

13:00 <zyp> benh, https://github.com/enjoy-digital/litex/blob/master/litex/tools/litex_server.py

13:00 <tpb> Title: litex/litex_server.py at master · enjoy-digital/litex · GitHub (at github.com)

13:01 <benh> zyp: thanks

13:01 <benh> zyp: yeah that's what I thought I remembered... but the fans definitly zip up when programming

13:02 <benh> and a tiny bit on host reboot

13:02 <benh> haven't managed to talk to the uart yet but I see the LEDs dancing so it's working :-)

13:02 <zyp> that sounds worrying, could be a sign the power supply from the slot is not very well regulated

13:03 <benh> zyp: possibly ... it's a PCIe cable card (one of those cheap one that uses a USB cable), it gets power via a SATA power cable

13:03 <benh> it's a temporary setup... I'll put the toy in a proper slot at some point on a test system

13:04 <benh> that I can remotely turn on/off

13:04 <zyp> ah

13:04 <benh> I'll probably run a UART on P2 as well, it's 3.3v and my FTDI toy has 2 channels

13:05 <benh> so it can do UART on the one that isn't doing JTAG

13:05 <benh> (afaik the FTDI 2232H is 3.3V IOs and I don't think that ClickUSB thingy has any voltage conversion)

13:07 <benh> _florent_: your kernel driver doesn't build against 5.7 :-)

13:08 <benh> it's missing #include <linux/poll.h> and #include <linux/cdev.h>

13:08 <_florent_> benh: possible, i'm still on an old kernel

13:09 <_florent_> benh: just for info: https://github.com/enjoy-digital/litepcie/pull/33/files

13:09 <tpb> Title: Kernel driver improvements by sergachev · Pull Request #33 · enjoy-digital/litepcie · GitHub (at github.com)

13:09 <_florent_> sorry: https://github.com/enjoy-digital/litepcie/pull/33

13:09 <tpb> Title: Kernel driver improvements by sergachev · Pull Request #33 · enjoy-digital/litepcie · GitHub (at github.com)

13:09 <benh> allright, it works

13:09 <benh> :-)

13:09 <benh> I have the vexriscv console, I'll play with microwatt and clean up my setup later

13:10 <_florent_> but with #33 there is still an issue when unloading, so it's not yet merged

13:10 <benh> _florent_: ah that PR has the fix for the missing includes

13:10 <benh> I could help if I had a bit more time ... maybe ask joel ?

13:10 <zyp> benh, I'm planning to play with usb over P2 eventually

13:10 <benh> the little spare time I have I want to spend in integrating our interrupt controller in litex

13:11 <benh> and maybe finally spend time on the CSR accessor business

13:11 <benh> zyp: ok

13:11 <benh> do those Artix support partial reconfig ?

13:11 <zyp> AFAIK yes

13:11 <benh> dunno if that's something mere mortals like us can use but it would be nice to have a fixed PCIe UART + management

13:12 <benh> and be able to use that to reprogram whatever we hack on

13:12 <benh> to avoid the jtag cable etc...

13:12 <benh> that said I know nothing about how you practically use partial reconfig

13:13 <benh> zyp: keep the USB thing optional, I don't want to accidentally fry something with my UART attached to it :-)

13:13 <benh> isn't USB 5V ?

13:13 <_florent_> benh: sure no problem, that was just for info, i haven't been able to look at it yet

13:13 <zyp> benh, VBUS is 5V but signalling is 3.3V

13:14 <benh> zyp: ah ok

13:15 <benh> allright, bed time ! at least the toy works ! I though I'd never get it, it took 2 month to arrive

13:15 <benh> Fabien (the seller in France) had given up and refunded me !

13:16 <benh> I'm too nice, I sent him his money back via paypal :)

13:16 <benh> this is the best bargain you can get for such a big Artix I reckon !

13:16 <benh> there's a guy on evblog talking of doing a base board to host it that would provide a PCIe clock and a host slot

13:17 <zyp> yeah, mine also took over a month

13:17 <benh> _florent_: I'm thinking ...maybe mithro can get us some PCI device IDs...

13:18 <benh> _florent_: we could do simpler than DT initially maube ... a little ROM that has the CSR "base" and a table of 8-bit IP "ID" (0 = nothing, 1 = UART etc..)

13:18 <benh> or something simple like that

13:18 <benh> a full DT would be better but runtime DT innjection in Linux isn't really a thing yet

13:19 <benh> from there the driver would pop sub-devices for the various functions on the card exposed to PCIe and match them against the exact same driver we would use for native litex SoCs

13:19 <benh> anyway, food for thoughts

13:19 <benh> cia

15:25 <somlo> _florent_: interesting... with SDCARD_MULTIPLE_BLOCK_SUPPORT undefined, the standard upstream (i.e., not linux-on-litex-vexriscv) build doesn't hang, and instead loads *very* *slowly* (testing w. nexys4ddr & rocket)

15:26 <somlo> got lost in the sauce trying to compare what is being built with linux-on-litex-vexriscv vs. the default upstream. Maybe I should compare the csv files, but not sure that's all there is to it in terms of side-by-side comparison

15:27 <somlo> anyway, I gotta go afk for a few hours, during which I'll see if the blob actually loads without corruption :)

16:04 <_florent_> somlo: with SDCARD_MULTIPLE_BLOCK_SUPPORT undefined, it should be at least as fast as SPI mode

18:13 <_florent_> somlo: if you have time, i would be interested by some feedback with uptstream litesdcard/litex

18:14 <_florent_> somlo: the gateware changes should alsmost be done, i'll continue on next monday

18:42 <mithro> benh: Are you suggesting that Google could donate some? I feel like it might be easier to get IBM to do so? :-P

18:59 <mithro> But if you do actually have a concrete request I can look into it

19:16 <somlo> _florent_: the mystery as far as I'm concerned is what (and how to narrow it down precisely) is the difference between an upstream nexys4ddr.py build (with vexriscv) and a make.py nexys4ddr build in linux-on-litex-vexriscv... I get lost in the python inheritance relationships, but that's where I'm sure we (I) will find why the latter works (and fast), while the former hangs...

22:42 <satnav> Hello, I have SPI flash populated in my evaluation board with ICE40HX1K as FPGA. I did SPI flash XiP according to the example in icebreaker.py example but I have issues when I running my soc python script and let LiteX build it. it fails in bios linking phase.

22:42 <satnav> these are the error

22:42 <satnav> riscv64-unknown-elf-ld: ../libbase/libbase-nofloat.a(progress.o): in function `show_progress':/home/barakg/playground/litex/litex/litex/soc/software/libbase/progress.c:44: undefined reference to `__muldi3'/home/barakg/playground/litex/litex/litex/soc/software/bios/Makefile:68: recipe for target 'bios.elf' failed

22:43 <satnav> can someone tell me why it fails or encounter with this problem and knows how to solve it?

22:44 <satnav> this is the code https://pastebin.com/KT7ByQ8T

22:44 <tpb> Title: #!/usr/bin/env python3 import argparse import os from migen import * fro - Pastebin.com (at pastebin.com)

22:44 <satnav> thanks!

23:10 <somlo> _florent_: with litesdcard b55de0e and litex 2bfa372b, I get fast loading of boot.bin from sdcard with vexriscv (linux variant)

23:12 <somlo> doesn't yet work well with rocket -- there's some weird slowness with outputting progress on boot.bin. Probably some 32 vs 64 bit thing, I'll try to figure it out over the weekend

23:19 <satnav> there's an option or flag to compile only the bios?

23:20 <satnav> without the gateware

23:46 <benh> mithro: not at this point, but if LiteX SoCs as PCIe slaves is something that potentially takes off, we might want to see if we can snag an ID from somebody

23:47 <benh> might even be in the LF/RH space

23:47 <benh> as long as it's one and we have another mechanism on top for the device to self-describe