_florent_ changed the topic of #litex to: LiteX FPGA SoC builder and Cores / Github : https://github.com/enjoy-digital, https://github.com/litex-hub / Logs: https://libera.irclog.whitequark.org/litex
gatecat has quit [Ping timeout: 264 seconds]
gatecat_ has joined #litex
acathla has quit [Ping timeout: 264 seconds]
acathla has joined #litex
tweakoz has quit [Quit: Leaving.]
<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 :)
<cr1901> There was a bug on orangecrab for this (linux-on-litex version)
<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
_whitelogger has joined #litex
_whitelogger has joined #litex
<cr1901> somlo: Let's see if I can find it
<cr1901> somlo: Might not be related, sorry https://github.com/litex-hub/linux-on-litex-vexriscv/issues/174
<cr1901> also this has been fixed for a while and I didn't notice
<somlo> cr1901: ok, thanks for checking!
shenki has joined #litex
Degi_ has joined #litex
Degi has quit [Ping timeout: 264 seconds]
Degi_ is now known as Degi
_whitelogger has joined #litex
Guest66 has joined #litex
awordnot has quit [Ping timeout: 272 seconds]
awordnot has joined #litex
dolbeau_ is now known as Melkhior
_whitelogger has joined #litex
<shoragan> somlo, thanks!
<geertu> _florent_: Bummer. Then I must have been misled since forever by seeing the BIOS being rebuilt...
<geertu> Is there an easy way to reload the BIOS to RAM? Recompiling the gateware is very time-consuming when debugging the BIOS.
<zyp> I think the BIOS is stored in a blockram used as rom, i.e. not writable
<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.
<_florent_> geertu: In fact you can configure the ROM to be in read/write mode
<_florent_> and then use one of the LiteX bridge to reconfigure the ROM and reboot the CPU
<_florent_> that's used for example in LiteDRAM's bench where we need an easy way to evaluate the changes of the calibration software
<_florent_> https://github.com/enjoy-digital/litedram/blob/master/bench/arty.py#L76 to configure the ROM in read/write mode
<_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
<_florent_> This is done over Etherbone here could be done also with the UART/SPI/JTAG/PCIe/USB bridges
shenki has quit [*.net *.split]
vup has quit [*.net *.split]
tmbinc1 has quit [*.net *.split]
vup has joined #litex
shenki has joined #litex
tmbinc1 has joined #litex
<_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
<_florent_> a/an
<shoragan> _florent_, thanks :)
gatecat_ has quit []
gatecat_ has joined #litex
Guest66 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
gatecat_ is now known as gatecat
anuejn has joined #litex
<somlo> _florent_: thanks, we're back in business! :)
<_florent_> good!
<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)
<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
<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
<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
<shoragan> so maybe i need to set up a fedora VM... you're using fedora 34?
cr1901 has left #litex [#litex]
cr1901 has joined #litex
Guest66 has joined #litex
<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
<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 :)
Guest66 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<nickoe> Anyone tried to run android on a litex soc there even is a port for risvc. :S
<nickoe> Mm, it do look like some kind of recent riscv port is available https://www.xda-developers.com/android-risc-v-port/
<cr1901> That would imply building Android, probably one of the most brutally difficult builds I know of
<gatecat> I don't think any of the LiteX SoCs are fast enough for Android
<cr1901> Not with that attitude :)
<nickoe> cr1901: Difficult? It is easy.
<nickoe> gatecat: well, I guess that depends on what the intention or requirements of the system are.
<nickoe> mm, I just tried to setup a new litex env, but it apears that it is stuck intalling nmigen
<nickoe> [installing nmigen]...
<nickoe> WARNING: The wheel package is not available.
<nickoe> And it does not appear to move on
<nickoe> Or does this step just take quite some time?
<_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)
<zyp> nice
<_florent_> It only requires 2 IOs and a declaration in the .dts, no specific driver to write
<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.
<_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
<shoragan> _florent_, nice! so it uses an existing kernel driver?
<_florent_> nickoe: can you keep it open? I'll close it when it will be fixed
<nickoe> _florent_: Also, I don't have any of the reference boards, so I could not test it on a "known good" project
<_florent_> shoragan: yes, it's using the generic-ohci driver
<shoragan> good :)
<shoragan> so it's 1.1 only, right?
<zyp> 1.1 is not a speed, usb2 encompasses earlier speed modes as well
<nickoe> _florent_: ok, if you can confirm it is not just a fluke in my setup, good, I will keep it open.
peeps[zen] has joined #litex
cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #litex
sorear has quit [Ping timeout: 272 seconds]
sorear has joined #litex
Xesxen has quit [Read error: Connection reset by peer]
Xesxen has joined #litex
peepsalot has quit [Ping timeout: 272 seconds]
Stary has quit [Ping timeout: 272 seconds]
Stary has joined #litex
<somlo> _florent_: that's really interesting, looking forward to it
<shoragan> zyp, yes. but OHCI is 1.1 only, as far as i know.
<zyp> that is true
Guest66 has joined #litex
Guest66 has quit [Client Quit]
<nickoe> mmm, how do I set the clock domain for a module?
<nickoe> Isn't it something like:
<nickoe> self.clock_domains.cd_bbfilter = cd_bbfilter = ClockDomain()
<nickoe> self.comb += self.cd_bbfilter.clk.eq(ClockSignal("mycustomclockname"))
<nickoe> mm, my FSM in there is still using sys clk