atommann has quit [Remote host closed the connection]
atommann has joined #litex
atommann has quit [Remote host closed the connection]
atommann has joined #litex
<benh>
_florent_: so I grabbed one of those Acorn CLE-215+, gosh that fan noise is annoying ! :-)
<benh>
_florent_: I'll get the jtag sorted and will probably use it for playing with Microwatt+LiteX... do you guys have SW to put on the host side of the PCIe ?
<benh>
I want to take out that fan but that means I also want to monitor the temperature :)
<benh>
do you know of a way to figure out if it's a speed grade 2 or 3 other than removing the heatsink ?
kgugala has joined #litex
<futarisIRCcloud>
Almost all the CLE-215+ are speed grade 2. If you want speed grade 3, the CLE-101 might be... I don't think anyone has checked those.
kgugala_ has quit [Ping timeout: 264 seconds]
st-gourichon-fid has joined #litex
<_florent_>
benh: there is a simple driver to access simple periperals and operate the DMA
<_florent_>
benh: you can get the driver and generate the header for it by adding --driver argument to the target
<tpb>
Title: Check PCIe bus rescan after loading bitstream. · Issue #36 · enjoy-digital/litepcie · GitHub (at github.com)
kgugala has quit [Quit: -a- Connection Timed Out]
kgugala has joined #litex
<atommann>
Hi _florent_, I tried to boot from a SDCard but failed.
<_florent_>
atommann: so you just tested the default kc705 support in linux-litex-vexriscv?
<atommann>
I just read the discussion between pdp7 and somlo (IRC log on 2020-03-27), seems that some specific type of SD card must be used.
<atommann>
Yes, I didn't use the pre-built binaries. I used the generated files.
<atommann>
Do I need to use some special recipes?
<_florent_>
atommann: we currently only support SDCard >= version 2.0
<_florent_>
atommann: can you share your bitstream, i have a kc705 near me and could test
<atommann>
OK. soon I'll email it to you.
<_florent_>
ok thanks
<atommann>
sent
<atommann>
Oh, I guess the problem is my SD card is below version 2.0.
<atommann>
Now I go out to grab an adapter to try the "HC" ones.
kgugala_ has joined #litex
kgugala has quit [Ping timeout: 264 seconds]
<_florent_>
atommann: thanks for your bistream, i tested it with 2 SDCard and it was working. There are still probably corner cases we need to catch with SDCard boot, so it's possible if you have issues with SDCards that should be supported (>=version2.0), please fill an issue.
scanakci has quit [Quit: Connection closed for inactivity]
<benh>
_florent_: heh ok... I was looking at acorn*.py and couldn't quite figure out how the uart is hooked up ... I'll dig again tonight or tomorrow
<benh>
I assume you have two uarts register sets, one litex "core" side and one pcie side with fifos in between ?
<_florent_>
benh: yes exactly, that's what is done when using the crossover uart, we create 2 UARTs: one for the CPU, one for us and both are interconnected
<jaseg>
Hey there, I'm having some trouble getting the etherbone bridge to work on nexys video (xc7a200t w/ RGMMII GbE). I got TFTP bootloading to work with no trouble at all.
<jaseg>
When the host probes the device over UDP the device only sometimes responds. This response always looks garbled: The UDP packet's headers look alright but the content is some random byte repeated (like 00 00 00 00 or 4f 4f 4f 4f ) and there is always 8 more bytes in the packet than idicated in the UDP header.
<jaseg>
Is there some tutorial/doc on etherbone w/ RGMII? I've only been able to find some code examples but I'm still a bit unclear on e.g. what clocking the phy/udp/etherbone cores expect.
<atommann>
_florent_, Do you think the "wifi-SD card idea" is doable?
<jaseg>
_florent_: that seems to be the problem. So if I instantiate it with add_etherbone(phy=..., clock_domain='sys') it should work with only a 100Mhz sys clock? In that case, where do the 125MHz come from? Is that derived from the RGMII's clock or do I have to supply it from the system PLL?
<atommann>
but netboot is also convenient while testing Linux driver and other stuff.
atommann has quit [Remote host closed the connection]
<_florent_>
jaseg: when setting clock_domain="sys", the ethcore will run in eth_tx clock domain (so at 125MHz) and the clock domain crossing will be done in the Etherbone core
atommann has joined #litex
<jaseg>
_florent_: that was the problem, it's working now. Thank you for the help!
<_florent_>
jaseg: great!
<_florent_>
i will improve this to avoid this problem
<_florent_>
atommann: wifi SD cards could probably work yes, but i never tested such cards
<_florent_>
atommann: but netboot will probably be easier/faster
<atommann>
OK. I'll buy a card and try out.
<_florent_>
wifi SD cards would be interesting with boards that don't have Ethernet
<_florent_>
with FT254 FIFO we also have interesting upload speed (600KB/s)
<_florent_>
with a UART baudrate of 3Mbauds it's 250KB/s
<_florent_>
with ValentyUSB it's around 160KB/s
<_florent_>
so that's already acceptable for the size of the binaries we currently have
<TMM>
Oh, this looks like an interesting project!
<zyp>
how come ValentyUSB is so slow?
<TMM>
Has anyone had any luck symbiflow and litex?
<_florent_>
zyp: haven't really looked, i just used it
<_florent_>
TMM: the arty target can be build with symbiflow
<tpb>
Title: integration/soc/etherbone: always run ethcore in eth_tx clock domain … · enjoy-digital/litex@23a95be · GitHub (at github.com)
<TMM>
100MHz is enough for my purposes. :)
<TMM>
Basically my goal is to build a computer from chips, I've done it before with 8bit micros. I've built some 6502 and z80 computers and some weird multi-processor things. I want to build something now that could theoretically be at least a little useful. My original plan was to use 68k processors but those aren't really available anymore. I've also looked into some power chips. Someone suggested I look at risc-v but the asics for sale are all highly
<TMM>
integrated SoCs which I don't really want. Plopping a single chip on a board doesn't really seem very challenging as a project. So I was thinking maybe prototyping a cpu and some peripherals in an fpga then, en later designing a board with several of those fpgas on it, some dram slots and headers etc.
<TMM>
Does that sound like something that could at least in theory work? The alternative would be I guess to buy some NXP power cores and build a board. There's not a lot else out there now that's not a soc with integrated everything
<TMM>
I think integrated dram controllers and pcie is ok. The alternative would probably be some power cpus with a not-really-optional northbridge which is effectively the same anyway
<_florent_>
interesting, LiteX could provide you a good framework for that to integrate the different cores in different FPGAs (SoCs) and make them communicate
<jaseg>
_florent_: thanks, that sounds like a good solution.
<zyp>
TMM, the problem is that once you plop down a fpga for the cpu, it gets kinda hard to justify doing stuff outside the fpga that would be easier to just put in the fpga next to the cpu
<TMM>
zyp: that's probably true, maybe if I set my goals to be higher than can fit on a single fpga? I want to make a computer that's a bit more like an Amiga than say a PC, that is I want to have a bunch of kind of specialized 'chips' to do things rather than have a lot of 'raw cpu' power. (There's no need for this computer to be particularly practical, I want it to be fun to use and program)
<zyp>
anything that can fit in two fpgas can also fit in one larger fpga :)
<zyp>
up until the fpgas don't get larger, but you've run out of money well before then
<TMM>
right, but I guess a constraint may be that symbiflow won't support the very biggest ones? :)
<zyp>
I don't think you need a particularly big FPGA to fit the full feature set of an Amiga
atommann has quit [Remote host closed the connection]
atommann has joined #litex
<atommann>
Hi _florent_, how can I mount the SD card? (can not see the /dev/sd* device)
<TMM>
zyp: well, the goal isn't to make an amiga clone but I understand your point. It's probable that the stuff I'm actually able to design will fit in a moderately sized fpga by itself
<daveshah>
No idea how Litex does it but do you have a /dev/mmcblk* device?
<daveshah>
That is what Linux uses for real SD/MMC ports
<atommann>
no, can't see any /dev/mmc* device.
<benh>
futarisIRCcloud: ok. is there a way to check other than removing the heatsink ?
<_florent_>
probably just a configuration issue, but i haven't been able to look at it yet
<atommann>
Thanks.
<benh>
TMM: there are enough Amiga clones out there already :-)
<benh>
I bought a minimig board a few years back ... in order to turn it into a Mac+ :-) That was my first real experience tackling fpgas (verilog back then)
<tpb>
Title: GitHub - litex-hub/linux at litex-rocket-rebase (at github.com)
<somlo>
(kernel should be backward-compatible with 32-bit CPUs like vexriscv, even though it says "rocket" :)
ambro718 has joined #litex
<somlo>
for proper SD-mode (litesdcard), I still have to replicate _forent_'s latest update on twitter, before trying the antmicro litex_mmc driver (and tweaking it until it works in linux)
<atommann>
Hi somlo, thanks, I'll try.
<somlo>
_florent_, what was the trellisboard command line you used to build the bitstream for that litesdcard boot demo on twitter?
<atommann>
The "wifi sd card method" is not possible, I asked two suppliers, they only supports one-way transferring.
CarlFK has quit [Ping timeout: 260 seconds]
<somlo>
atommann: having never heard of a "wifi sd card" before today, I had to look it up :) Appears to be a thing that acts as a regular SD card (over the SD card pins), but also allows being *read* over wifi (even while mounted as an SD card)
<somlo>
I guess the part where it's read-only over wifi is what makes it unhelpful as a workaround for the lack of other networking options on, e.g., an fpga dev board
<atommann>
These wifi sd cards are designed for old cameras.
<atommann>
I am checking if Toshiba FlashAir cards support upload function.
<futarisIRCcloud>
wifi sd cards are generally an ARM system that also supports a sd device.
<futarisIRCcloud>
benh: from the thread on eevblog, it seems that you can't find speed grade from inside the FPGA.
<atommann>
it's possible with FlashAir, people use it with 3D printers.
<tpb>
Title: How to set up wireless printing with Toshiba FlashAir SD cards - Prusa Printers (at blog.prusaprinters.org)
<futarisIRCcloud>
FT245 gives reasonable speed considering USB Full-Speed is only 12Mbps
CarlFK has joined #litex
<pdp7>
atommann:
<pdp7>
oops
<pdp7>
atommann: i have tried recently but i want to
<pdp7>
i bought a 4GB and 8Gb, 16GB and 64GB
<pdp7>
i hope one will work :)
<pdp7>
_florent_: is there a list of suggested cards to buy?
<pdp7>
i just grabbed some one from amazon.de but in the hopes one would work
<somlo>
atommann, pdp7, _florent_: litesdcard *used* to be picky about which cards it would work with a while back (when pdp7 and I had that conversation). Then, around the time of commit 5cc7a988, I was able to use all my cards with both spi-mode and litesdcard
<atommann>
Thanks for this message.
<somlo>
even *more* recent changes to litesdcard broke it completely for me (on all models of sd card, whether they used to work with the old version or not) but afaik _florent_ isn't done updating litesdcard yet, so I assume all (most) recent sdcards will end up working OK :)
<atommann>
It's good to know :)
<somlo>
atommann: as of right now, spi-mode is rock solid, but the linux spi-mmc driver adds a LOT of overhead, so it's much slower in linux than on bare-metal
kgugala has joined #litex
kgugala has quit [Read error: Connection reset by peer]
kgugala has joined #litex
kgugala_ has quit [Ping timeout: 246 seconds]
kgugala has quit [Read error: Connection reset by peer]
peepsalot has quit [Quit: Connection reset by peep]
peepsalot has joined #litex
<somlo>
_florent_: oh, I'll have to figure out how to extract a "standard" litex build command from that
<somlo>
one obvious candidate for what's different from what I've been doing is probably the csr-data-width... Let me try with 8, see if I can get something wiggling that way
tcal_ has joined #litex
tcal has quit [Remote host closed the connection]
Swimming1ode has joined #litex
tcal_ has quit [Ping timeout: 240 seconds]
y2kbugger_ has joined #litex
captain_morgan0 has joined #litex
SwimmingCode has quit [Ping timeout: 246 seconds]
keesj has quit [Ping timeout: 246 seconds]
Degi has quit [Ping timeout: 246 seconds]
y2kbugger has quit [Ping timeout: 246 seconds]
y2kbugger_ is now known as y2kbugger
Degi has joined #litex
captain_morgan has quit [Ping timeout: 264 seconds]
captain_morgan0 is now known as captain_morgan
npcomp has quit [Ping timeout: 264 seconds]
npcomp has joined #litex
keesj has joined #litex
<_florent_>
somlo: i could sent you the next bitstream i test if you want, just to see if you reproduce my results with your different sdcards
_whitelogger has joined #litex
<somlo>
_florent_:ok, please do that, thanks! -- btw, I built linux-on-litex-vexriscv bitstreams for both trellisboard and nexys4ddr but when I push it to the board with openocd (I skipped the "--load" part), I get garbage on the terminal
<somlo>
is the linux-on-litex-vexriscv using a different terminal baud rate (i.e., not 115200)?
<_florent_>
somlo: the baudrate is 1000000
<somlo>
oh, with that baud rate I can boot the nexys4ddr bitstream and load a boot.bin blob (it's the wrong blob, since it's a rocket bbl+kernel payload, but load it I can)
<somlo>
now, I need to figure out what else is different (besides the baud rate) between a bitstream built within linux-on-litex-vexriscv and a "proper" upstream-litex one
<_florent_>
somlo: i will also look at this, i'm using linux-on-litex-vexriscv because it's convenient to see if the images are loaded correctly (linux booting), but the default targets should also work
atommann has quit [Quit: Leaving]
<_florent_>
somlo: --csr-data-width=32 makes the default target work
<somlo>
_florent_: I've been using --csr-data-width=32 all along (unsuccessfully). What's the full command line you used for the default target?
<somlo>
_florent_ -- I'll have to dig into it a bit more systematically, since for me, using that command (without the --load part, which I'm doing manually via openocd), it still hangs
<somlo>
probably some weird thing I'm doing wrong, but looks like I will have to figure it out the "maximum effort" route :D
scanakci has joined #litex
Skip has quit [Remote host closed the connection]
<TMM>
I think I'm going to go the FPGA route, I think it'll be fun to implement some custom instructions for my little machine, and it seems that that should all be at least achievable with litex :)
<TMM>
I'll see how I'm going to fashion a 'computer' out of it later I suppose. Building the OS and monitor thing I was planning to do is probably going to be the hard part
<somlo>
TMM: LiteX is (in its most general form) a 'computer' -- you get a wishbone bus, with a choice of CPUs as the master, and a choice of peripherals (ethernet, sdcard, uart, etc, etc.) as slaves. It's possible to use some of the peripherals as standalone IP blocks, or to connect a new CPU to drive the "computer", or to connect additional (non-LiteX) IP blocks to the wishbone bus
<somlo>
so if you bring your own CPU, you'll get a LiteX computer with a new cpu model (in addition to what's already supported)
<somlo>
oh, and AXI is also supported in addition to WB, so if your CPU or peripherals already have an AXI interface and no WB, you can connect them as well