| *** tpb <[email protected]> has joined #litex | 00:00 | |
| cr1901 | https://github.com/cr1901/orangecrab-feather Well, I'm finally satisfied enough with this to release at least a first version | 02:03 |
|---|---|---|
| *** zjason` <zjason`[email protected]> has joined #litex | 02:07 | |
| Wolfvak | "SoC will hang if until USB serial port is open." I think its because either RTS/CTS is wired to RST? | 02:10 |
| 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:11 |
| *** zjason <[email protected]> has quit IRC (Ping timeout: 272 seconds) | 02:11 | |
| cr1901 | Does ValentyUSB even expose RTS/CTS to the user? | 02:12 |
| 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:18 |
| 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:23 |
| 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:24 |
| 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:25 |
| cr1901 | oops | 02:26 |
| cr1901 | well, that's something I can look into later :P | 02:26 |
| 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:27 |
| Wolfvak | welp, it definitely detects the card but can't initialize it, oh well | 02:43 |
| *** Degi <[email protected]> has quit IRC (Ping timeout: 240 seconds) | 02:59 | |
| *** Degi <[email protected]> has joined #litex | 03:00 | |
| *** shenki <[email protected]> has quit IRC (Quit: leaving) | 05:48 | |
| *** shenki <[email protected]> has joined #litex | 05:52 | |
| trabucayre | tnt: great! But it's not after power cycle no ? | 06:38 |
| trabucayre | But it's not fix your issue to communicates with USER1 I assume | 06:39 |
| tnt | trabucayre: haven't tried a full power cycle. But I will soon when I start work this morning :) | 06:40 |
| 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:41 |
| trabucayre | zynqmp support is quite new :) | 06:42 |
| 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:43 |
| trabucayre | xilinx platform is something like smt2 ? | 06:45 |
| 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. | 06:53 |
| tnt | trabucayre: yup, indeed {0x08e80126, {"xilinx", "zynqmp_cfgn","xczu11eg", 4}}, | 07:15 |
| 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:16 |
| _florent_ | cr1901: no worries, my 4 months son just wanted to eat and it's difficult to tell him to wait :) | 07:18 |
| _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:19 |
| _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:20 |
| _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:21 |
| _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:23 |
| 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:24 |
| _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:25 |
| 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:26 |
| _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:27 |
| 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:31 |
| trabucayre | tnt: I have to find a xilinx cable to add support. I may useful | 07:37 |
| 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 ... | 07:39 |
| *** FabM <[email protected]> has joined #litex | 08:55 | |
| *** TMM_ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 09:32 | |
| *** TMM_ <[email protected]> has joined #litex | 09:32 | |
| 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:13 |
| 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) | 12:48 |
| tnt | Well, good news is I got JTAGBone to work on the ZynqMP | 13:13 |
| tnt | bad news is it's _SLOW_ ... | 13:13 |
| 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:25 |
| 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. | 13:26 |
| *** zjason` is now known as zjason | 13:40 | |
| _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:12 |
| _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:14 |
| _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:16 |
| *** FabM <FabM!~FabM@armadeus/team/FabM> has quit IRC (Quit: Leaving) | 15:50 | |
| 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:55 |
| _florent_ | tnt: I just saw the comment is the issue | 15:58 |
| _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. | 15:59 |
| tnt | (and by massive, I mean 99% of the trace is idle between commands) | 16:00 |
| _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:01 |
| tnt | Not sure about the "learning" part (at least in the generic case). | 16:08 |
| 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:09 |
| tnt | anyway, gotta head out for now. I'll be back ina couple hours. | 16:10 |
| _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:14 |
| _florent_ | at least as a first step | 16:15 |
| *** joseng <[email protected]> has joined #litex | 20:11 | |
| *** _florent_ <[email protected]> has quit IRC (Read error: Connection reset by peer) | 23:41 | |
| *** _florent_ <[email protected]> has joined #litex | 23:41 | |
| *** gatecat <[email protected]> has quit IRC (Read error: No route to host) | 23:41 | |
| *** tucanae47_ <[email protected]> has quit IRC (Read error: No route to host) | 23:41 | |
| *** alanvgreen <[email protected]> has quit IRC (Read error: Connection reset by peer) | 23:41 | |
| *** gatecat <[email protected]> has joined #litex | 23:41 | |
| *** alanvgreen <[email protected]> has joined #litex | 23:42 | |
| *** tucanae47_ <[email protected]> has joined #litex | 23:42 | |
| *** mikolajw <mikolajw!~mikolajtc@2001:470:69fc:105::3b02> has quit IRC (Ping timeout: 252 seconds) | 23:44 | |
| *** mikolajw <mikolajw!~mikolajtc@2001:470:69fc:105::3b02> has joined #litex | 23:59 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!