vc33d has quit [Remote host closed the connection]
lf_ has joined #litex
lf has quit [Ping timeout: 260 seconds]
lf_ has quit [Ping timeout: 258 seconds]
lf has joined #litex
Dolu has joined #litex
key2 has joined #litex
<shorne>
somlo: hello
<shorne>
Sorry, you pinged me on my way to work
CarlFK has quit [Quit: Leaving.]
<shorne>
OK, so my other problem using litex-buildenv vs litex-boards is *buildenv was loading the kernel to 0x0000000 while *boards is 0x40000000
<shorne>
data transfers just fine now, kernel is not booting though
<somlo>
shorne: sorry, I had a question about the recently upstreamed litex soc driver, but figured it out meanwhile
<somlo>
I'm testing an update to support the newly-default 32-bit csr-data-width in upstream LiteX, and will submit a patch as soon as that's ready
<shorne>
alright, makes sense
<somlo>
shorne: and I don't think it's litex_boards per se loading to 0x40000000, but rather upstream litex proper
<somlo>
all the 0x40000000 instances in litex-boards appear to me to be the *size* (not base address) of the sdram
<somlo>
and, in upstream litex, the main ram start address is 0x40000000 by default (in soc_core.py), but can be overridden by the cpu ("main_ram" property)
<somlo>
e.g., it's 80000000 on rocket
<shorne>
well, if I have a boot.json and specify to load by rootfs.cpio to 0x0000000 it never loads, if I set 0x4000000 it works
<shorne>
but I just found an issue with the memmap
<shorne>
for the mor1kx soc we override to 0x0000000, but my recent patch broke that
<somlo>
right, it's hardcoded in the gateware (once you have a bitstream) -- so by then you need to load wherever the bitstream expects you to...
<somlo>
I'm not familiar with litex-buildenv, but I assume it overrides "main_ram" to make it 0x00000000
<somlo>
so any gateware/bitstream you build with it will have a different memory layout than "upstream" litex
<somlo>
sorry, you probably already figured this out and we're just in "violent agreement" :D
<somlo>
oh, and make sure you update the .dts/.dtb to reflect the new memory start address too -- that may be one reason why the kernel won't boot properly, after it gets loaded
<shorne>
somlo: yes, we are in agreement, also already checked .dts
<shorne>
now it seems to be in sync with the old litex-buildenv, but still not booting
<shorne>
one thing I notice that is strange before bootup is this message: Copying boot.bin to 0x00000000... (11282556 bytes)
<shorne>
then Liftoff, the bytes count is 2x the size it should be
<somlo>
shorne: shot in the dark -- was your csr-data-width different with litex-buildenv (e.g., 8), vs. the now-default 32 in upstream litex ?
<somlo>
it's probably not it, but since I'm actively working on it, every problem looks like a nail :)
Dolu has quit [Ping timeout: 264 seconds]
<shorne>
could be
<shorne>
let me see
Dolu has joined #litex
Degi has quit [Quit: ZNC 1.6.6+deb1ubuntu0.2 - http://znc.in]
roboknight has quit [Remote host closed the connection]
<lf>
_florent_: thx for the bitstream. that on ist working but when i build it on my system it does not work. i updated Yosys 0.9+3780 (git sha1 d15c63eff) and nextpnr-ecp5 84c55f89 and it still did not work. is there a know working version i can try?
<somlo>
_florent_: maybe we should drop litex-[rocket|vexriscv]-rebase, and just create a "litex-rebase" branch to track gateware drivers for upstreaming?
<somlo>
we can keep track of credits (who did what) in the commit logs
<somlo>
thoughts?
<lf>
_florent_: nevermind its working my mistake
<_florent_>
shorne: I've not tested Linux with mor1kx, but I remember discussing with Mateusz who had to set R1 register pointing to the address of the .dtb in memory
<_florent_>
in the boot.json, you can also specific bootargs
<somlo>
equivalent to litex-rocket-rebase in terms of functionality, but builds on latest upstream (which already includes the SoC controller and LiteUART driver)
<somlo>
with "sausage making" covered up, each patch adds a clearly defined feature or driver
<somlo>
did my best to track everyone's contribution in the commit blurbs