| *** tpb has joined #litex | 00:00 | |
| *** lf_ has quit IRC | 00:48 | |
| *** lf has joined #litex | 00:48 | |
| *** lkcl has quit IRC | 01:09 | |
| *** Dolu has quit IRC | 01:19 | |
| *** lkcl has joined #litex | 01:22 | |
| *** lkcl has quit IRC | 01:54 | |
| *** lkcl has joined #litex | 02:07 | |
| *** Degi has quit IRC | 04:57 | |
| *** Degi has joined #litex | 04:58 | |
| *** lkcl has quit IRC | 05:10 | |
| *** lkcl has joined #litex | 05:24 | |
| *** Bertl_zZ is now known as Bertl | 07:30 | |
| *** lkcl has quit IRC | 07:43 | |
| *** lkcl has joined #litex | 07:56 | |
| *** Bertl is now known as Bertl_oO | 08:31 | |
| *** vc33d has joined #litex | 09:23 | |
| *** vc33d has quit IRC | 09:23 | |
| *** lf_ has joined #litex | 09:47 | |
| *** lf has quit IRC | 09:47 | |
| *** lf_ has quit IRC | 09:52 | |
| *** lf has joined #litex | 09:52 | |
| *** Dolu has joined #litex | 10:07 | |
| *** key2 has joined #litex | 10:34 | |
| shorne | somlo: hello | 12:07 |
|---|---|---|
| shorne | Sorry, you pinged me on my way to work | 12:08 |
| *** CarlFK has quit IRC | 12:20 | |
| shorne | OK, so my other problem using litex-buildenv vs litex-boards is *buildenv was loading the kernel to 0x0000000 while *boards is 0x40000000 | 12:33 |
| shorne | data transfers just fine now, kernel is not booting though | 12:34 |
| somlo | shorne: sorry, I had a question about the recently upstreamed litex soc driver, but figured it out meanwhile | 12:35 |
| 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 | 12:36 |
| shorne | alright, makes sense | 12:39 |
| somlo | shorne: and I don't think it's litex_boards per se loading to 0x40000000, but rather upstream litex proper | 12:46 |
| somlo | all the 0x40000000 instances in litex-boards appear to me to be the *size* (not base address) of the sdram | 12:46 |
| 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) | 12:49 |
| somlo | e.g., it's 80000000 on rocket | 12:49 |
| 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 | 12:51 |
| shorne | but I just found an issue with the memmap | 12:51 |
| shorne | for the mor1kx soc we override to 0x0000000, but my recent patch broke that | 12:51 |
| 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... | 12:51 |
| somlo | I'm not familiar with litex-buildenv, but I assume it overrides "main_ram" to make it 0x00000000 | 12:53 |
| somlo | so any gateware/bitstream you build with it will have a different memory layout than "upstream" litex | 12:53 |
| somlo | sorry, you probably already figured this out and we're just in "violent agreement" :D | 12:54 |
| 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 | 12:59 |
| shorne | somlo: yes, we are in agreement, also already checked .dts | 13:14 |
| shorne | now it seems to be in sync with the old litex-buildenv, but still not booting | 13:15 |
| shorne | one thing I notice that is strange before bootup is this message: Copying boot.bin to 0x00000000... (11282556 bytes) | 13:16 |
| shorne | then Liftoff, the bytes count is 2x the size it should be | 13:17 |
| 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 ? | 13:19 |
| somlo | it's probably not it, but since I'm actively working on it, every problem looks like a nail :) | 13:20 |
| *** Dolu has quit IRC | 13:23 | |
| shorne | could be | 13:24 |
| shorne | let me see | 13:24 |
| *** Dolu has joined #litex | 13:59 | |
| *** Degi has quit IRC | 14:29 | |
| *** roboknight has quit IRC | 14:29 | |
| 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? | 14:47 |
| somlo | upstream submission to support 4-byte CSR data width in Linux kernel: http://lkml.iu.edu/hypermail/linux/kernel/2012.2/04633.html | 14:52 |
| tpb | Title: Linux-Kernel Archive: [PATCH v1] drivers/soc/litex: support 32-bit subregisters, 64-bit CPUs (at lkml.iu.edu) | 14:52 |
| somlo | now I'm going to really rebase https://github.com/litex-hub/linux/tree/litex-rocket-rebase on top of upstream + that patch | 14:53 |
| somlo | _florent_: maybe we should drop litex-[rocket|vexriscv]-rebase, and just create a "litex-rebase" branch to track gateware drivers for upstreaming? | 14:54 |
| somlo | we can keep track of credits (who did what) in the commit logs | 14:54 |
| somlo | thoughts? | 14:54 |
| lf | _florent_: nevermind its working my mistake | 14:56 |
| _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 | 17:23 |
| _florent_ | in the boot.json, you can also specific bootargs | 17:23 |
| _florent_ | ex: | 17:23 |
| _florent_ | https://www.irccloud.com/pastebin/CL27Dwot/ | 17:23 |
| tpb | Title: Snippet | IRCCloud (at www.irccloud.com) | 17:23 |
| _florent_ | you can find more info at: https://github.com/enjoy-digital/litex/wiki/Load-Application-Code-To-CPU | 17:24 |
| *** Degi has joined #litex | 17:24 | |
| *** CarlFK has joined #litex | 18:13 | |
| *** CarlFK has quit IRC | 18:23 | |
| *** CarlFK has joined #litex | 19:29 | |
| *** CarlFK has quit IRC | 19:35 | |
| *** CarlFK has joined #litex | 19:49 | |
| *** CarlFK has quit IRC | 19:58 | |
| *** _franck_ has quit IRC | 20:32 | |
| 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 | 21:24 |
| shorne | But I think adding support for the loaded .dtb would be a good next step | 21:24 |
| 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. | 21:27 |
| shorne | so that makes sense | 21:27 |
| *** _franck_ has joined #litex | 21:41 | |
| somlo | new "rebasing" LiteX kernel branch that subsumes litex-[vexriscv|rocket]-rebase: https://github.com/litex-hub/linux/tree/litex-rebase | 21:48 |
| somlo | equivalent to litex-rocket-rebase in terms of functionality, but builds on latest upstream (which already includes the SoC controller and LiteUART driver) | 21:49 |
| somlo | with "sausage making" covered up, each patch adds a clearly defined feature or driver | 21:50 |
| somlo | did my best to track everyone's contribution in the commit blurbs | 21:50 |
| *** CarlFK has joined #litex | 22:59 | |
| *** CarlFK has quit IRC | 23:12 | |
| *** CarlFK has joined #litex | 23:19 | |
| *** CarlFK has quit IRC | 23:28 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!