<sajattack>
can you guys help me get to linux-on-litex next?
<_florent_>
sajattack: the bios seems indeed to be working, but you setup does not seem that convenient to use :)
<sajattack>
indeed
<sajattack>
I at least converted the bytes to ascii now
<sajattack>
so it's a little better
<sajattack>
maybe I can make it a bit more interactive too
<_florent_>
to use linux-on-litex-vexrisc, you need a 32MB memory and on the de10 nano, the DDR3 seems connected to the HPS, so not sure that's easy to access to it from the fabric
<sajattack>
oh shit I think I typed this in backwards because quartus
<sajattack>
so how does this work if they don't have the sdram module?
<sajattack>
I'm looking at versa_ecp5 and you're using SoCSDRAM
<sajattack>
_florent_: ^
<sajattack>
I guess I add a flag like you do with ethernet
m4ssi has quit [Read error: Connection reset by peer]
<sajattack>
anyone there?
<acathla>
hi sajattack
<sajattack>
if I push some weird WIP code can you take a look at it and tell me how to do it properly?
<sajattack>
I'm getting this error and also I'm committing some python/migen crimes migen.fhdl.module.FinalizeError: CPU needs "rom" to be defined as memory or linker region
<acathla>
sajattack, you probably need to define a rom region in your new flash definition
<sajattack>
what flash definition?
<acathla>
ah, you were talking only about sdram, I didn't backlog enough
<acathla>
anyway, your SoC need to have a rom region where you put your bios/bootloader/code to boot to, even if it's in SDRAM.
<acathla>
I guess, i'm learning too...
<sajattack>
where do I define that?
<sajattack>
I checked existing boards platform and target files and didn't see anything with "rom" other than "from" in imports
<sajattack>
maybe I'll just try running linux-with-litex as the builder now
<somlo>
xobs: then, restore generated/csr.h to use csr_readl() and csr_writel() with shifts
<somlo>
would that work for you?
<xobs>
somlo: I think it would, yes. Thank you!
<somlo>
cool, i'll cook something up for export.py to do that, then...
<somlo>
xobs: just saw your last reply on github, so question re. naming convention: stick with readl/writel (as in, "long")? Or rather go with csr_read_sub[reg]() and csr_write_sub[reg]() instead? These are after all subregister accessors, not full-CSR ones... :)
<xobs>
Sure, you can do csr_x_sub().
<xobs>
I just followed the Linux convention. I tend to think of CSRs as being 8-bit registers with contents spread across multiple fields, but I'm not sure anyone else does that.
<xobs>
Comes from working with odd-sized peripherals. Like the i.MX6, which had an 8-bit PWM IP core taken straight from a Coldfire.
<xobs>
So `csr_readl()` and `csr_writel()` made sense to me. But I definitely see the confusion, so for this particular instance `csr_x_sub()` could work nicely!
<somlo>
I'm used to MMIO registers of 32 and 64 bits, so my instinct is to encapsulate the scatter/gather "striping" of the underlying 8-bit limitation as much as possible :)
<somlo>
particularly since LiteX now supports 32bit subregisters, and might support 64bits with a bit more cleanup...
<somlo>
ok, so csr_x_sub() it is, then -- thanks for your patience :)
<xobs>
I think I'll be moving to 32-bit CSRs, because it makes the software simpler and doesn't impact performance too much. It makes no difference with Fomu, and seems fine with Betrusted, too.