<somlo>
is there a good "man page" equivalent for migen's "Record" ? Somehow it isn't mentioned in the migen documentation, and reading through genlib/record.py isn't really straightforward...
rj_ has joined #litex
rj_ has quit [Quit: rj_]
rj_ has joined #litex
rj_ has quit [Ping timeout: 268 seconds]
Degi_ has joined #litex
Degi has quit [Ping timeout: 246 seconds]
Degi_ is now known as Degi
Bertl is now known as Bertl_zZ
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
_whitelogger has joined #litex
tpb has quit [Disconnected by services]
tpb has joined #litex
Melkhior has joined #litex
<geertu>
Melkhior: You're right. An OrangeCrab with a dual-core SPARC CPU would be about half as fast as the 125 KEUR SS1000 when I was at university
<Melkhior>
@geertu Maybe not a fully loaded SS1000, they were able to fit 8 SuperSPARC... though I don't think they were > 50 MHz as standard, or perhaps in the 1000E?
<Melkhior>
You probably stlll need a bigger FPGA than that, if only to fit the FPUs... but we're getting there!
<Melkhior>
@Finde T1 is V9 so 64 bits, and openpiton targets quite a few cores... an interesting project, but another one that may require a (too) big FPGA...
<Melkhior>
Anyway this week-end I finally ran out of space: needed 100.47% of my A7-35k to fit the dual-VexRiscv LiteX with all my extra instructions!
<Melkhior>
Now I know why hardware people worry about space and sharing resources and won't write HW like it's just regular SW :-)
<Melkhior>
Another funny thing about the sd-card Linux driver on my board: it was working fine to read test binaries of the sd-card in SMP mode. Then I ran out of space and used a single core... and the binaries would be randomly corrupted and unusable! Mounting/md5sum/unmounting would have been a decent RNG : -) Disabled some instructions to save space, went
<Melkhior>
back to dual-core, and now the sd-card works again in Linux (it's working no matter what to read the Image and rootfs in either UP or SMP from the firmware).
ambro718 has joined #litex
Melkhior has quit [Quit: Ping timeout (120 seconds)]
Melkhior has joined #litex
ambro718 has quit [Quit: Konversation terminated!]
Bertl_zZ is now known as Bertl
<somlo>
Melkhior: re. sdcard in linux, (assuming you're using the same driver that's currently in the litex-rebase branch of litex-hub/linux)
<Melkhior>
@somlo will try that next time I try a UP kernel
<Melkhior>
s/kernel/bitstream/
<Melkhior>
with two (VexRiscv) cores it seems to always work...
<somlo>
Melkhior: not sure which version of the sdcard driver is in geertu's 5.11 kernel (wondering/hoping it's the same)
<geertu>
somlo: somlo: It's based on a rebase of your tree from a while ago
<geertu>
somlo: Compared to your current tree, it lacks recent updates to "LiteX: driver for LiteSDCard (mmc)". But I haven't really used the SDcard, except for a quick heck if it works (i.e. dd | hexdump )
<geertu>
s/heck/check/
tucanae47 has quit [Read error: Connection reset by peer]
carlomaragno has quit [Read error: Connection reset by peer]
flammit has quit [Read error: Connection reset by peer]
alanvgreen has quit [Read error: Connection reset by peer]
rohitksingh has quit [Read error: Connection reset by peer]
esden has quit [Read error: Connection reset by peer]
daveshah has quit [Read error: Connection reset by peer]
tannewt has quit [Read error: Connection reset by peer]
davidlattimore has quit [Read error: Connection reset by peer]
ric96 has quit [Ping timeout: 265 seconds]
Claude has quit [Read error: Connection reset by peer]
y2kbugger has quit [Read error: Connection reset by peer]
levi has quit [Read error: No route to host]
sorear has quit [Read error: Connection reset by peer]
tucanae47 has joined #litex
carlomaragno has joined #litex
alanvgreen has joined #litex
esden has joined #litex
davidlattimore has joined #litex
ric96 has joined #litex
<Melkhior>
Speaking of cheap FPGA - would Litex be able to work with the MAX10 and peripherals in this $37 board: <https://www.arrow.com/en/products/deca/arrow-development-tools> ? That's really, really cheap for 512 MiB of RAM ! But I don't know that litedram would support it (or any of the other peripherals...)
sorear has joined #litex
flammit has joined #litex
rohitksingh has joined #litex
y2kbugger has joined #litex
daveshah has joined #litex
tannewt has joined #litex
Claude has joined #litex
levi has joined #litex
<Melkhior>
Well this board has a 10M50DAF484C6G, the supported de10nano uses a 10M50DAF484C7G - just a speed grade difference ? So it would be a peripheral issue...
<Melkhior>
s/de10nano/de10lite/
<somlo>
geertu: might be worth me trying to apply whatever is in *your* tree and not in litex_rebase to the latter, so we can all work from the same tree... e.g., litex_rebase's first five patches are the stuff that's currently winding its way upstream via shorne's tree; I know there's at least one of your patches in the same situation, so we should throw it on top of that pile in litex-rebase...
<somlo>
maybe also add a vexriscv-specific defconfig to make it easy to build...
<geertu>
somlo: Sure. I've just rebased my local tree to v5.11-rc7, but haven't pushed it out, as it contains some more wip.
<somlo>
and/or for whatever CPU you most frequently use
<geertu>
somlo: I have a litex_vexriscv_defconfig in my tree; -)
<geertu>
I don't use it myself, though.
<somlo>
geertu: this should all hopefully get easier once the fundamentals are upstream and all we're left with are device drivers and defconfigs :)
<geertu>
somlo: You're still at v5.11-rc6?
<somlo>
I'm at whatever was current in upstream yesterday (currently 108 commits behind torvalds:master)
FFY00 has joined #litex
<somlo>
I have it so that I can just rebase litex-rebase whenever I fetch an updated master
<geertu>
Melkhior: I pushed out my rebase to v5.11-rc7, minus my wip
<geertu>
somlo: It's easier for other people if you stick to tagged bases
<geertu>
Melkhior: For me, "dd if=/dev/mmcblk0 count=10 | hexdump -C" always gives the same output
<geertu>
(vexriscv-smp with 1 core)
<somlo>
we can make that choice, but the cool thing is we don't *have* to -- nothing litex-specific currently in litex-rebase is tied to a specific version or rc or anything...
<geertu>
somlo: Some of the fixes I had in my tree are now in rc7
<somlo>
the only occasional merge conflict is related to surrounding context lines in a makefile or Kconfig here and there, when other drivers get added upstream -- and last time that happened two months ago :)
<geertu>
somlo: sure, for the LiteX drivers
<somlo>
right -- keeping litex drivers up to date w.r.t. the latest kernel is what "litex-rebase" is meant to do
<Melkhior>
@geertu It also works for me if I have two cores - at least that's what appear to be the case... single core corrupts data:-( So I run dual, I still can fit my tests so far
<geertu>
Melkhior: strange. Perhaps it works for me because of Warning: Max frequency for clock '$glbnet$sys_clk': 56.46 MHz (FAIL at 64.00 MHz)
<geertu>
;-)
<Melkhior>
Currently running VexRiscv @96 MHz as 100 MHz wasn't reliable anymore with too many instructions
<somlo>
Melkhior: are you getting any errors from the sdcard driver e.g. "command failed, status 2" or similar?
<Melkhior>
@somlo Not sure, I don't think so but I'm not 100% certain... I didn't thoroughly investigate, switched back to dual-core to check if that was still working, it was, so I suck with that :-)
<Melkhior>
I'll have to check next time I try single-core
<somlo>
because for me (single-core rocket) I get perfect behavior on bare-metal bios, and lots of timeouts and breakage when I try to enable multi-block transfers -- and it all seems somehow timing related
<somlo>
and, intuitively, your dual-core-works story seems to suggest that the sdcard hardware likes to enjoy one CPU's full undivided "attention" somehow (don't laugh, I'm trying to form a hypothesis here, rubbing my remaining two brain cells together :)
<somlo>
by adding "SDPHY(sdcard_pads, self.platform.device, self.clk_freq, cmd_timeout=10e-1, data_timeout=10e-1)"
<somlo>
to get the single-block/cmd17-only linux sdcard driver to stop running into command/data/dma timeouts
<Melkhior>
@somlo not laughing, some weird timing issues that are masked by the dual-core being more available is what I was guessing as well. It also works fine in the BIOS with single- and dual- VexRiscv (but not single Rocket...)
<somlo>
still no good idea why that still won't improve multi-block (cmd-18) behavior, if I try to turn that on :(
<somlo>
single rocket works great for me in the bios (on nexys4ddr with vivado, but also on the trellis board and ecpix5). But under linux it's even more flakey on ecp5 than on xilinx
Melkhior has quit [Quit: Connection closed]
Melkhior has joined #litex
<somlo>
Melkhior: I even disabled interrupts while in litex_request() (in the sdcard driver, single-core rocket), but that didn't seem to help
Melkhior has quit [Quit: Ping timeout (120 seconds)]
<somlo>
so I guess there's no way around doing it with "Maximum Effort (TM)" and undertanding everything about the underlying litesdcard FSMs, streams, migen records, the whole nine yards...
Melkhior has joined #litex
<Melkhior>
_florent_ If I read correctly https://github.com/enjoy-digital/litedram, there's no generic DDR3 PHY, it's always FPGA-specific, so as there's is none for the MAX10 the memory on the Deca board would not work with litedram ?
<Melkhior>
@somlo Yes, but I don't have the skill to debug the sd-card... I still can use it to boot much faster than serial & load binaries w/o recreating the rootfs, I'm already quite happy with that
<somlo>
Melkhior: that's nice (honestly happy for you, honestly not being sarcastic) :) Sadly for me, I want to boot Fedora on ecpix5 and/or the trellisboard, and it's still too slow for that :D
<somlo>
I managed to mount, chroot to /mnt, and run nextpnr-ecp5 and yosys, but it takes like 5 minutes for the binaries to load from sdcard and execute :)
<Melkhior>
@somlo ouch:-) to completely self-host the Rocket build I suppose ? Impressive achievement even if it's not fast :-)
<tpb>
Title: A Trustworthy, Free (Libre), Linux Capable, Self-Hosting 64bit RISC-V Computer (at www.contrib.andrew.cmu.edu)
<Melkhior>
Yes I know the project, that's what got me interested in LiteX in the first place :-)
<somlo>
the example uses spi-mode sdcard, but "native" litesdcard is only significantly faster on bare metal, and about as slow under linux... Which is why that's my current obsession :)
<Melkhior>
I have a profesionnal interest in RISC-V so I follow the news
<somlo>
and yeah, once I can build bitstream from source on the board for which I'm building it, I can retire (or sell out and become a $$$$ consultant, or whatever, wouldn't matter anymore :D :D)
<Melkhior>
:-)
<somlo>
it's a bucket list thing, you see :D
<Melkhior>
... and then you can go back to OSX in QEMU/KVM;-) that was a while ago...
<Melkhior>
... or do a macox-on-litex-microwatt, the circle would be complete :-)
<somlo>
heh, digging through the edk2 sources is a traumatic experience, would not recommend it if *fun* is what you're after...
mikeK_de10nano has joined #litex
<mikeK_de10nano>
hello
tannewt has quit [Read error: Connection reset by peer]
tannewt has joined #litex
esden has quit [Read error: Connection reset by peer]
esden has joined #litex
kgugala has joined #litex
kgugala_ has quit [Ping timeout: 264 seconds]
<mikeK_de10nano>
hello
<mikeK_de10nano>
OK, So I fianlly got Litex to compile for the DE10-nano. But I cannot seem to load it from the litex build scripts??
<mikeK_de10nano>
Info: Quartus Prime Convert_programming_file was successful. 0 errors, 0 warnings