01:29 <somlo> shoragan: I just submitted litex issue #922 re. failure to init DRAM on ecp5. "thankfully" it also manifests on vexriscv, as you pointed out, so it's not just me as the lonely, cranky rocket-chip dude experiencing trouble :)

01:30 <cr1901> There was a bug on orangecrab for this (linux-on-litex version)

01:32 <somlo> cr1901: can you please cross-link them (add a mention, I think, should be enough)? Sorry, didn't notice yours before opening a potential dupe

02:13 <cr1901> somlo: Let's see if I can find it

02:16 <cr1901> somlo: Might not be related, sorry https://github.com/litex-hub/linux-on-litex-vexriscv/issues/174

02:16 <cr1901> also this has been fixed for a while and I didn't notice

02:30 <somlo> cr1901: ok, thanks for checking!

06:44 <shoragan> somlo, thanks!

07:29 <geertu> _florent_: Bummer. Then I must have been misled since forever by seeing the BIOS being rebuilt...

07:31 <geertu> Is there an easy way to reload the BIOS to RAM? Recompiling the gateware is very time-consuming when debugging the BIOS.

07:42 <zyp> I think the BIOS is stored in a blockram used as rom, i.e. not writable

07:44 <geertu> zyp: So the only way would be to load it to a different address in RAM. And if it's not relocatable, relink it to the right target address first.

07:56 <_florent_> geertu: In fact you can configure the ROM to be in read/write mode

07:57 <_florent_> and then use one of the LiteX bridge to reconfigure the ROM and reboot the CPU

07:58 <_florent_> that's used for example in LiteDRAM's bench where we need an easy way to evaluate the changes of the calibration software

07:59 <_florent_> https://github.com/enjoy-digital/litedram/blob/master/bench/arty.py#L76 to configure the ROM in read/write mode

08:00 <_florent_> and we then reload the BIOS over Etherbone with this simple script: https://github.com/enjoy-digital/litedram/blob/master/bench/common.py#L111-L127

08:01 <_florent_> This is done over Etherbone here could be done also with the UART/SPI/JTAG/PCIe/USB bridges

08:32 <_florent_> somlo: The DRAM/ECP5 issue is fixed, a update was required to liblitedram for the ECP5 case: https://github.com/enjoy-digital/litex/commit/d3560e57729493320fe28c7334bebaffbea73d22

08:33 <_florent_> a/an

09:14 <shoragan> _florent_, thanks :)

11:05 <somlo> _florent_: thanks, we're back in business! :)

11:05 <_florent_> good!

11:29 <shoragan> somlo, _florent_: i can confirm it works again with vexriscv. with rocket, i still have the issue that no bios shows up (just a single garbage byte on serial)

11:33 <shoragan> i've tested the simulation, which works. i'm not sure what to look for in the logs: https://github.com/jluebbe/linux-on-litex-rocket/runs/2663652794

12:44 <somlo> shoragan: I think the key to the problem you're experiencing with rocket must be somewhere in the difference between our tooling (os, toolchain build, etc.). I built fedora rpms of the latest yosys/trellis/nextpnr as of some 24 hours ago, and with the updated python-cpu-rocket and _florent_'s latest litex fix, it's working perfectly well on this end

13:43 <shoragan> somlo, yes it seems that way... to avoid local "contamination", i tried with the hdl-containers, but i still get a non-booting bios

13:46 <shoragan> so maybe i need to set up a fedora VM... you're using fedora 34?

16:25 <somlo> shoragan: just recently updated to f34, yes; the latest toolchain RPMs are on my todo list for tonight to push into the official fedora repos, which should take a few days until they make it all the way into updates

16:29 <shoragan> somlo, ok. then i'm going to wait for your results with the latest master versions of the toolchain before trying to reproduce the versions currently in fedora :)

19:19 <nickoe> Anyone tried to run android on a litex soc there even is a port for risvc. :S

19:20 <nickoe> Mm, it do look like some kind of recent riscv port is available https://www.xda-developers.com/android-risc-v-port/

19:20 <cr1901> That would imply building Android, probably one of the most brutally difficult builds I know of

19:21 <gatecat> I don't think any of the LiteX SoCs are fast enough for Android

19:21 <cr1901> Not with that attitude :)

19:25 <nickoe> https://plctlab.github.io/aosp/create-a-minimal-android-system-for-riscv.html

19:26 <nickoe> cr1901: Difficult? It is easy.

19:26 <nickoe> gatecat: well, I guess that depends on what the intention or requirements of the system are.

19:28 <nickoe> mm, I just tried to setup a new litex env, but it apears that it is stuck intalling nmigen

19:28 <nickoe> [installing nmigen]...

19:28 <nickoe> WARNING: The wheel package is not available.

19:29 <nickoe> And it does not appear to move on

19:29 <nickoe> Or does this step just take quite some time?

19:37 <_florent_> somlo, Melkhior: We just validated with Dolu his USB Host core (FS) with LiteX & VexRiscv-SMP & Linux, so you'll soon be able to plug very various peripherals in your Linux systems :) (we'll also be able to integrate it with Rocket)

19:37 <zyp> nice

19:40 <_florent_> It only requires 2 IOs and a declaration in the .dts, no specific driver to write

19:42 <nickoe> _florent_: Did you see this? https://github.com/enjoy-digital/litedram/issues/251#issuecomment-835897878 I am not intending to keep it open for ever if possible, but I wonder if that "difference" I observed is expected.

19:48 <_florent_> nickoe: I saw it and indeed remember also noticing this difference last year. I'm planning to have a closer look to make the behaviour similar between sim & hardware, but haven't spent the time yet

19:48 <shoragan> _florent_, nice! so it uses an existing kernel driver?

19:48 <_florent_> nickoe: can you keep it open? I'll close it when it will be fixed

19:49 <nickoe> _florent_: Also, I don't have any of the reference boards, so I could not test it on a "known good" project

19:49 <_florent_> shoragan: yes, it's using the generic-ohci driver

19:49 <_florent_> https://github.com/enjoy-digital/litex_vexriscv_smp_usb_host/blob/master/litex_json2dts.py#L236

19:49 <shoragan> good :)

19:50 <shoragan> so it's 1.1 only, right?

20:08 <zyp> 1.1 is not a speed, usb2 encompasses earlier speed modes as well

20:40 <nickoe> _florent_: ok, if you can confirm it is not just a fluke in my setup, good, I will keep it open.

21:25 <somlo> _florent_: that's really interesting, looking forward to it

21:40 <shoragan> zyp, yes. but OHCI is 1.1 only, as far as i know.

21:43 <zyp> that is true

23:22 <nickoe> mmm, how do I set the clock domain for a module?

23:23 <nickoe> Isn't it something like:

23:23 <nickoe> self.clock_domains.cd_bbfilter = cd_bbfilter = ClockDomain()

23:23 <nickoe> self.comb += self.cd_bbfilter.clk.eq(ClockSignal("mycustomclockname"))

23:37 <nickoe> mm, my FSM in there is still using sys clk