_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://freenode.irclog.whitequark.org/litex
tpb has quit [Remote host closed the connection]
tpb has joined #litex
lf_ has quit [Ping timeout: 268 seconds]
lf has joined #litex
lkcl has quit [Ping timeout: 240 seconds]
Dolu has quit [Ping timeout: 240 seconds]
lkcl has joined #litex
lkcl has quit [Ping timeout: 246 seconds]
lkcl has joined #litex
Degi has quit [Ping timeout: 240 seconds]
Degi has joined #litex
lkcl has quit [Ping timeout: 260 seconds]
lkcl has joined #litex
Bertl_zZ is now known as Bertl
lkcl has quit [Ping timeout: 256 seconds]
lkcl has joined #litex
Bertl is now known as Bertl_oO
vc33d has joined #litex
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> upstream submission to support 4-byte CSR data width in Linux kernel: http://lkml.iu.edu/hypermail/linux/kernel/2012.2/04633.html
<tpb> Title: Linux-Kernel Archive: [PATCH v1] drivers/soc/litex: support 32-bit subregisters, 64-bit CPUs (at lkml.iu.edu)
<somlo> now I'm going to really rebase https://github.com/litex-hub/linux/tree/litex-rocket-rebase on top of upstream + that patch
<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
<_florent_> ex:
<tpb> Title: Snippet | IRCCloud (at www.irccloud.com)
Degi has joined #litex
CarlFK has joined #litex
CarlFK has quit [Ping timeout: 264 seconds]
CarlFK has joined #litex
CarlFK has quit [Ping timeout: 268 seconds]
CarlFK has joined #litex
CarlFK has quit [Ping timeout: 260 seconds]
_franck_ has quit [Ping timeout: 256 seconds]
<shorne> _florent_: thank's I am working through Mateusz howto (it seems he doesn't use the external .dtb) but kernel builtin which I am also using
<shorne> But I think adding support for the loaded .dtb would be a good next step
<shorne> OpenRISC linux expects the DTB at r3, but setting the address in R1 and calling boot(r1, r2, r3, addr), as the bios does, will move r1 to r3.
<shorne> so that makes sense
_franck_ has joined #litex
<somlo> new "rebasing" LiteX kernel branch that subsumes litex-[vexriscv|rocket]-rebase: https://github.com/litex-hub/linux/tree/litex-rebase
<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
CarlFK has joined #litex
CarlFK has quit [Ping timeout: 260 seconds]
CarlFK has joined #litex
CarlFK has quit [Ping timeout: 268 seconds]