00:11 <somlo> _florent_: re. spi- vs lite- sdcard booting, I added an unconditional return here: https://github.com/enjoy-digital/litex/blob/master/litex/soc/software/bios/boot.c#L589

00:11 <tpb> Title: litex/boot.c at master · enjoy-digital/litex · GitHub (at github.com)

00:12 <somlo> then I did `mr 0x80000000 0x200` to compare what got loaded from the sdcard via spi- vs lite-

00:12 <somlo> and the first 0x200 bytes are the same :)

00:13 <somlo> so now I'm back to not knowing why booting with litesdcard hangs at "Liftoff!" whereas booting with spi-sdcard doesn't hang...

00:15 <somlo> I actually did have it working with both spi- and lite- before the fatfs switch-over; but now that spi- works with fatfs, litesdcard should too, but doesn't. That's the question currently nagging me...

00:45 <somlo> well, doing a `crc 0x80000000 13126480` gets me different values on the boot.bin blob loaded via SPI (d0505b43) vs. litesdcard (f3aefc83)

00:46 <somlo> that'd be the same boot.bin blob loaded from the same sdcard... So nothing as obvious as consistently swapped bytes... Maybe it's a failed-by-too-much timing problem, I should try at slower Fmax...

02:04 <mithro> @benh_ - I've been meaning to reply to your email but just haven't gotten around to it because of the other stuff happening () -- The include "trick" for having two separate modules can be done a large number of different ways -- I *think* it could just be done with a bunch of consts function pointers and the compiler should be able to optimize away the indirection

02:07 <benh_> mithro: any reason why the if() would be a problem though ?

02:07 <benh_> I would assume on linux-capable SoCs the cost would be negligible compared to the IO

02:11 <mithro> @benh_ I less worried about the performance and more worried about certain developers complaining about regmap "infecting" the "nice clean MMIO version" -- It becomes much harder to complain if there is no runtime cost

02:32 <benh_> mithro: :-)

02:33 <benh_> mithro: #including C file is usually frowned upon... there are good reasons to occasionally do it but in this case I suspect it won't fly

02:35 <mithro> @benh_ -- I thought I said that I wouldn't suggest we should use that exact implementation -- just something which has the same runtime cost as that -- as I mentioned I'm pretty sure there are multiple ways to make that happen?

02:37 <mithro> I'm not good enough in C to get a const function pointer version close to right when typing directly into an email

02:43 <benh_> mithro: fundamentally, either we have a runtime cost and a single driver, or no runtime cost and two builds of the driver

02:44 <benh_> mithro: now we could build the drivers as some kind of .a and then have two variants provide different accessors and link against it

02:44 <benh_> mithro: but I wouldn't even try to do that with the kernel build system

02:45 <benh_> mithro: my idea for now is to just have the call into the litex code to "map" the csrs and have the opaque object etc...

02:45 <benh_> mithro: but with no conditionals and no regmap path, just direct mmio *for now*

02:45 <benh_> and when somebody wants to add regmap, it can be done without modifying the drivers

02:45 <benh_> by just updating the map call and the accessors

06:24 <keesj_> pretty serious stuff being done using nmigen https://harmoninstruments.com/blog/

06:24 <tpb> Title: Harmon Instruments (at harmoninstruments.com)

12:03 <benh_> _florent_: I was wondering ... would it be realistic to run litedram at 128Mhz instead of 100 ? (so about 1Ghz out of the DRAM)

12:03 <benh_> I don't think we would make timing with microwatt at that speed with our current design (we struggle enough at 100) but just curious

12:04 <benh_> (it's a nice round divisor of our architected timebase freq which is 512Mhz)

12:21 <_florent_> benh_: IIRC 125MHz is working correctly on Arty/Vexriscv, so 128MHz should also work

12:36 <_florent_> benh: https://hastebin.com/qigoyequhu.rb (there are some timings violations in the SoC, but the DRAM is working)

12:36 <tpb> Title: hastebin (at hastebin.com)

12:45 <_florent_> somlo: i also want to get current litesdcard version working but i've not been able to look at it yet. From the tests i did, i also had some data corruption.

13:22 <somlo> _florent_: just for completenes, after dropping FMax to 60MHz (and passing timing in vivado) I still had data corruption with litesdcard, so it wasn't a side effect of failing timing (by *too* much)

13:34 <keesj> is there some documentation / example somewhere of creating a hello world c file (possibly reusing the software/* libraries (like the bios)

13:35 <keesj> if possible .. I would like to keet it minimal (e.g. include the platform header and .. wire a simple hello world)

15:10 <_florent_> keesj: this should be useful: https://github.com/litex-hub/fpga_101/tree/master/lab004

15:10 <tpb> Title: fpga_101/lab004 at master · litex-hub/fpga_101 · GitHub (at github.com)

15:32 <NickTern> Hello. Can u tell me how i can build litehhyperbus core? at the output I will get a Verilog file and roughly speaking I can use it in my design as an ip? recently started studying litex sorry if the question is simple

23:33 <tpearson-mobile> has the Wishbone 32 bit master to 8 bit slave automatic downconverter received any real testing?

23:34 <tpearson-mobile> so far I'm seeing some really odd behavior out of it, including only ever getting data from the last byte in a 32-bit master bus word

23:35 <tpearson-mobile> I also don't really see a short-circuit if the CPU is doing an 8-bit read, it literally looks like it tries to read 32 bits, one byte at a time, from the slave, then masks off the unwanted bytes?