02:03 <cr1901> https://github.com/cr1901/orangecrab-feather Well, I'm finally satisfied enough with this to release at least a first version

02:10 <Wolfvak> "SoC will hang if until USB serial port is open." I think its because either RTS/CTS is wired to RST?

02:11 <Wolfvak> also, was LiteSDCard fixed for ECP5 targets? its kind of a shame to be limited to 1/4 the "intended" bandwidth of an SD card...

02:11 <cr1901> In ValentyUSB?

02:11 <cr1901> I'm not sure, on either of your points

02:12 <cr1901> Does ValentyUSB even expose RTS/CTS to the user?

02:18 <Wolfvak> weird, could've sworn that was the explanation for how the SoC wouldn't boot until you opened the port with a terminal emulator

02:23 <cr1901> https://github.com/enjoy-digital/litex/blob/master/litex/soc/cores/uart.py#L281-L298 This code should fix the hang for non-USB serial ports

02:24 <cr1901> As for SD card being limited to 1/4 bandwidth, Idk if the orangecrab routes all signals required for full speed SD card.

02:24 <cr1901> I just used the most basic option :D

02:25 <Wolfvak> they're there in r0.2 https://github.com/litex-hub/litex-boards/blob/master/litex_boards/platforms/gsd_orangecrab.py#L171-L176

02:26 <cr1901> oops

02:26 <cr1901> well, that's something I can look into later :P

02:27 <Wolfvak> this is the issue https://github.com/litex-hub/linux-on-litex-vexriscv/issues/255

02:27 <Wolfvak> mmm, just looked at the latest comment, might try it out myself now :p

02:43 <Wolfvak> welp, it definitely detects the card but can't initialize it, oh well

06:38 <trabucayre> tnt: great! But it's not after power cycle no ?

06:39 <trabucayre> But it's not fix your issue to communicates with USER1 I assume

06:40 <tnt> trabucayre: haven't tried a full power cycle. But I will soon when I start work this morning :)

06:41 <tnt> No, that's unrelated, just more convenient to program than use vivado lab :p I didn't know openfpgaloader supported ZynqMP at all. (also I only had the xilinx platform cable and not a digilent hs3 until yesterday).

06:42 <trabucayre> zynqmp support is quite new :)

06:43 <trabucayre> with powercycle you will see another idcode (unconfigured device)

06:43 <trabucayre> something like https://github.com/trabucayre/openFPGALoader/blob/master/src/part.hpp#L63

06:45 <trabucayre> xilinx platform is something like smt2 ?

06:53 <tnt> https://www.xilinx.com/products/boards-and-kits/hw-usb-ii-g.html

06:53 <tnt> It has a FX2 and a CPLD inside.

07:15 <tnt> trabucayre: yup, indeed {0x08e80126, {"xilinx", "zynqmp_cfgn","xczu11eg", 4}},

07:16 <tnt> trabucayre: btw, openocd has 'ftdi_tdo_sample_edge falling' option to work on higher tck rate, would be nice to have that in openfpga loader too. Can't get above 10M without it.

07:18 <_florent_> cr1901: no worries, my 4 months son just wanted to eat and it's difficult to tell him to wait :)

07:19 <_florent_> cr1901: but I'm not sure what is not clear on your side regarding auto_flush. Without autoflush, we basically have: TX FIFO's source -> UART's source --> PHY's sink

07:20 <_florent_> cr1901: and we insert auto_flush between TX_FIFO's source and UART's source, the be able to flush the TX FIFO without waiting for the UART's source ready signal

07:20 <_florent_> cr1901: but data is of course lost

07:21 <_florent_> Wolfvak: I should indeed look at #255 issue, I'm not sure it's really ECP5 related but seems to happen on some ECP5 boards

07:23 <_florent_> tnt: JTAGPHY's FSM has been created initially for the specific 7-series usecase and is fixed to 10-bit DR, but it should be possible to adapt it with minor modifications

07:24 <tnt> _florent_: the issue isn't so much with 10-bit DR but the fact in theory the host should be able to shift as much bits as he want and only in capture/update state should the DR be loaded/interpreted.

07:25 <_florent_> tnt: I think just modifying the last state could do it: here: https://github.com/enjoy-digital/litex/blob/master/litex/soc/cores/jtag.py#L469, instead of returning to "XFER-READY", going to a "XFER-DONE" state that does nothing should do it

07:26 <tnt> that might work in this specific case, but not in the general case of an arbitrary chain I think. Because you have no idea if the first shifted 10 bit are for you.

07:27 <_florent_> tnt: only the first 10-bit of the transfer would then be used, but we have to see if it's convenient for the software

07:27 <tnt> I'll try to just use a normal shift register and use capture/update state and then remove the -endsate DRPAUSE.

07:31 <tnt> trabucayre: oh, my bad, there is something like that already (FtdiJtagMPSSE::config_edge()) but at least here only the read_mode needs changing, write_mode still need to be MPSSE_WRITE_NEG.

07:37 <trabucayre> tnt: I have to find a xilinx cable to add support. I may useful

07:39 <trabucayre> config_edge is an internal method used according to hardware. It's not efficient because it's not always true...

07:39 <trabucayre> works with artyA7 first generation but not with new arty boards ...

12:13 <Wolfvak> _florent_, I'm mostly interested in this issue because without it the SD card can read at around a glorious 80KiB/s (on linux)

12:48 <Wolfvak> ok nvm after retrying a few times it managed to boot into linux

12:48 <Wolfvak> but it seems like the prebuilt kernel doesnt support mmc (or the generated dts doesnt include it, not sure yet)

13:13 <tnt> Well, good news is I got JTAGBone to work on the ZynqMP

13:13 <tnt> bad news is it's _SLOW_ ...

13:25 <cr1901> _florent_: I still need to wake up but... I get how the autoflush is supposed to work I think (save a minor q which can wait)

13:25 <cr1901> I'm confused because I think the way I use the terms "source" and "sink" don't match the way you use them. And it makes me second guess my understanding especially when reading the source.

13:26 <cr1901> In your explanation above, I don't understand why you're connecting a TX FIFO source to a UART source (without the autoflush). I thought sources connected to sinks.

15:12 <_florent_> tnt: great, congrats! JTAGBone is useful but indeed probably not very fast (I've been mostly using it to do control/status and LiteScope).

15:14 <_florent_> cr1901: TX FIFO is internal to the module, so when connecting its source to UART's source, we basically just exposing it to the outside

15:16 <_florent_> tnt: you probably already saw it but you might be interested:

15:16 <_florent_> https://twitter.com/9600/status/1501211308649287680

15:16 <_florent_> https://www.crowdsupply.com/lime-micro/limesdr-mini-2-0

15:16 <tpb> Title: LimeSDR Mini 2.0 | Crowd Supply (at www.crowdsupply.com)

15:55 <tnt> _florent_: litescope is what I wanted it for, I was hoping it'd be faster than uart but it's like 10x slower ...

15:58 <_florent_> tnt: I just saw the comment is the issue

15:59 <_florent_> tnt: is the slowliness related to the use of drscan?

15:59 <tnt> _florent_: pretty sure it is. Looking at litescope trace, I can see a massive gap between individual drscan.

16:00 <tnt> (and by massive, I mean 99% of the trace is idle between commands)

16:01 <_florent_> tnt: ok, and do you think we could have a kind of hybrid mode between the old one and new one, where the gateware learn the number of bits from initial command and we could then burst them as we were doing before to speed up things?

16:08 <tnt> Not sure about the "learning" part (at least in the generic case).

16:09 <tnt> ATM I'm hesitating between writing a streaming sw to replace openocd that would use the mpsse more efficiently and trying to hack the logic to emulate the old mode.

16:10 <tnt> anyway, gotta head out for now. I'll be back ina couple hours.

16:14 <_florent_> Regarding LiteX integration, it would be easier to keep using OpenOCD and a logic that maybe less generic (that could learn of be configured from parameters)

16:15 <_florent_> at least as a first step