| *** tpb <[email protected]> has joined #litex | 00:00 | |
| *** shenki <[email protected]> has quit IRC (Ping timeout: 250 seconds) | 00:56 | |
| *** shenki <[email protected]> has joined #litex | 00:57 | |
| *** Coldberg <[email protected]> has quit IRC (Ping timeout: 268 seconds) | 01:36 | |
| jevinskie[m] | Any idea why I’m only getting a 25 MHz rx clock and no activity on tx clk with an 88e1111 PHY (intel max10 dev kit) even after turning off autoneg and setting 100 mode manually via mdio (and resetting plenty). The data shows up fine on RX as well | 02:25 |
|---|---|---|
| jevinskie[m] | Link status also shows as up via MDIO | 02:26 |
| jevinskie[m] | Verified with both litescope on the clocks themselves (from eth’s crg submod) and via counters | 02:28 |
| *** alainlou <[email protected]> has quit IRC (Quit: Client closed) | 02:54 | |
| *** alainlou <[email protected]> has joined #litex | 03:00 | |
| *** alainlou <[email protected]> has quit IRC (Ping timeout: 256 seconds) | 03:15 | |
| jevinskie[m] | I ported libliteeth’s MDIO commands to remoteclient so you don’t need a soft core. It’s slow but it works :) https://gist.github.com/jevinskie/426b28c43cf6e2b74faa2beac710026b | 03:26 |
| *** Degi_ <[email protected]> has joined #litex | 03:48 | |
| *** Degi <[email protected]> has quit IRC (Ping timeout: 252 seconds) | 03:48 | |
| *** Degi_ is now known as Degi | 03:48 | |
| *** FabM <FabM!~FabM@2a03:d604:103:600:6f7c:26b8:c7ea:7b6f> has joined #litex | 04:39 | |
| *** shenki <[email protected]> has quit IRC (Ping timeout: 268 seconds) | 04:41 | |
| *** shenki <[email protected]> has joined #litex | 04:42 | |
| *** shenki <[email protected]> has quit IRC (Ping timeout: 268 seconds) | 05:10 | |
| *** shenki <[email protected]> has joined #litex | 05:10 | |
| *** shenki <[email protected]> has quit IRC (Ping timeout: 260 seconds) | 05:29 | |
| *** shenki <[email protected]> has joined #litex | 05:29 | |
| jevinskie[m] | Doh, I bet I know what it is. Found out Rx clk is derived from the incoming eth signals by the phy but the tx clk from the phy is derived from a 25 MHz clock I’m not feeding it (: | 06:28 |
| jevinskie[m] | Crap, it’s fed by a silabs clock gen, not the fpga. | 06:41 |
| Melkhior | sajattack[m]: if the buldroot is too big, you need to change the memory map loaded at boot so that there's enough space for it | 07:04 |
| sajattack[m] | Oh yeah | 07:04 |
| sajattack[m] | I thought the buildroot was the last thing loaded though | 07:05 |
| sajattack[m] | ie it could fill the rest of ram | 07:05 |
| *** nickoe <[email protected]> has quit IRC (Ping timeout: 252 seconds) | 07:06 | |
| jevinskie[m] | Hmm, 25 MHz is documented as a default output of the silabs clock gen. If MDIO works fine, it has to be getting a clock, right? | 07:06 |
| Melkhior | in the json it is, but something somewhere (sorry, machine with the code is off) in the Litex source codes is pointing Linux at the memory it can use | 07:06 |
| *** michalsieron <[email protected]> has joined #litex | 07:07 | |
| Melkhior | so if rootf is is at 0x41000000 and linux uses from 0x42000000, you can only fit 16 MiB of FS before running into trouble | 07:07 |
| sajattack[m] | Aha | 07:08 |
| Melkhior | https://github.com/enjoy-digital/litex/blob/694878a35a2f792ad195ff9c585d689467a76b1d/litex/tools/litex_json2dts_linux.py#L35-L39 | 07:12 |
| Melkhior | https://github.com/enjoy-digital/litex/blob/694878a35a2f792ad195ff9c585d689467a76b1d/litex/tools/litex_json2dts_linux.py#L630 | 07:13 |
| Melkhior | Might be just that | 07:13 |
| _florent_ | jevinskie[m]: IIRC the 88e1111 has a GMII interface in 1Gbps mode, MII interface in 100Mbps mode and the clocking is different between these modes: https://github.com/enjoy-digital/liteeth/blob/master/liteeth/phy/gmii.py#L64-L65 | 07:16 |
| _florent_ | I think the KC705 uses this PHY, this could be worth comparing your hardware/code vs this board/target | 07:17 |
| *** michalsieron <[email protected]> has quit IRC (Remote host closed the connection) | 07:23 | |
| *** michalsieron <[email protected]> has joined #litex | 07:23 | |
| *** michalsieron <[email protected]> has quit IRC (Remote host closed the connection) | 07:26 | |
| jevinskie[m] | Yes I’m trying to use it in 100/mii mode and I’m instantiating a mii phy (I also have gtx commented out). Thanks I’ll take a look at that board | 07:44 |
| jevinskie[m] | Also not generating the 125 MHz clock on gtx regardless of if I’m passing it to the phy | 07:45 |
| jevinskie[m] | BTW, florent, litex’s CSRs, *bone bridges and litex_server are so fantastic, it feels like I have superpowers :P | 07:49 |
| _florent_ | jevinskie[m]: Thanks, this indeed allow you to control/observe things in the FPGA with the confort of your traditional dev environment/tools :) I'm using it a lot to design new cores/peripherals and later to investigate issues on hardware. | 08:07 |
| *** TMM_ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 08:30 | |
| *** TMM_ <[email protected]> has joined #litex | 08:30 | |
| *** shenki <[email protected]> has quit IRC (Ping timeout: 268 seconds) | 08:44 | |
| *** shenki <[email protected]> has joined #litex | 08:44 | |
| *** shenki <[email protected]> has quit IRC (Ping timeout: 260 seconds) | 09:14 | |
| *** shenki <[email protected]> has joined #litex | 09:14 | |
| *** pauluzs <pauluzs!~Pauluzs@2a02:a461:635a:1:fd13:bd3:d77e:168d> has quit IRC (Ping timeout: 260 seconds) | 09:32 | |
| *** pauluzs <pauluzs!~Pauluzs@2a02:a461:635a:1:93e1:a4f6:f446:ce02> has joined #litex | 09:44 | |
| shenki | i'm attempting to boot linux on vexriscv. I've built myself a soc and have grabbed the prebuilt linux/opensbi/rootfs, which I'm loading over ethernet | 09:50 |
| shenki | it jumps to the payload and I don't see any output | 09:50 |
| shenki | are there issues with using the prebuilt opensbi and litex master? | 09:50 |
| shenki | i built the soc from litex-boards: | 09:52 |
| shenki | litex_boards/targets/digilent_arty.py --output-dir build/arty-vexriscv --cpu-type vexriscv_smp --cpu-variant=linux --with-ethernet --variant a7-100 --csr-json build/arty-vexriscv/system.json --build --load | 09:52 |
| _florent_ | shenki: it's probably related the a specific CSR/Interrupt/Mem Mapping: https://github.com/litex-hub/linux-on-litex-vexriscv/blob/master/soc_linux.py#L56-L69 | 09:55 |
| _florent_ | we should indeed allow building it directly from LiteX-Boards, but this is probably not yet supported | 09:56 |
| _florent_ | can you try to re-integrate this mapping in the digilent_arty target and see if it improves things? | 09:56 |
| *** shenki <[email protected]> has quit IRC (Ping timeout: 268 seconds) | 10:06 | |
| *** shenki <[email protected]> has joined #litex | 10:07 | |
| shenki | _florent_: to fix it, I need to build a opensbi against my generated soc? | 10:45 |
| *** pauluzs <pauluzs!~Pauluzs@2a02:a461:635a:1:93e1:a4f6:f446:ce02> has quit IRC (Quit: Leaving) | 10:57 | |
| _florent_ | shenki: if you don't use soc_linux's mapping, updating opensbi's CSR mapping should indeed work | 11:11 |
| *** indy <[email protected]> has quit IRC (Ping timeout: 245 seconds) | 11:50 | |
| *** indy <[email protected]> has joined #litex | 11:51 | |
| *** TMM_ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 12:06 | |
| *** TMM_ <[email protected]> has joined #litex | 12:06 | |
| shenki | thanks, I updated the uart base address in opensbi and then I got it working | 13:12 |
| shenki | my device tree wasn't correct, so I couldn't see the early printk messages without sbi console working | 13:12 |
| shenki | if not for that i might have booted straight through with the prebuilt opensbi | 13:13 |
| shenki | i'm now trying to build a kernel from upstream. it's not doing much; no output after opensbi | 13:25 |
| *** cr1901 <cr1901!~William@2601:8d:8600:911:d12a:5ac6:c44f:6445> has quit IRC (Ping timeout: 252 seconds) | 14:03 | |
| geertu | shenki: You need to build a kernel from litex-hub/linux#linux-rebase | 14:15 |
| sajattack[m] | lmao https://hastebin.com/ayuradehap.yaml | 14:55 |
| tpb | Title: hastebin (at hastebin.com) | 14:55 |
| sajattack[m] | do I need to define a custom linker script to define my memory regions? | 14:58 |
| sajattack[m] | scientific progress goes boink https://hastebin.com/jusenepehu.properties | 15:28 |
| tpb | Title: hastebin (at hastebin.com) | 15:28 |
| sajattack[m] | does this mean I need to not use ilp32d? | 15:28 |
| *** _franck_0 <[email protected]> has joined #litex | 15:49 | |
| *** _franck_ <[email protected]> has quit IRC (Ping timeout: 268 seconds) | 15:51 | |
| *** _franck_0 is now known as _franck_ | 15:51 | |
| *** _franck_5 <[email protected]> has joined #litex | 15:55 | |
| *** FabM <FabM!~FabM@armadeus/team/FabM> has quit IRC (Quit: Leaving) | 15:55 | |
| *** Martoni42 <Martoni42!~Martoni@2a03:d604:103:600:2ad2:44ff:fe23:2f72> has joined #litex | 15:56 | |
| *** _franck_ <[email protected]> has quit IRC (Ping timeout: 265 seconds) | 15:57 | |
| *** _franck_5 is now known as _franck_ | 15:57 | |
| Melkhior | sajattack[m]: ilp32d requires support in the entire system - kernel, buildroot, compiler, binutils, gdb, ... (and likely run on RV32G) | 16:21 |
| Melkhior | that's what I use, so it is usable :-) | 16:21 |
| sajattack[m] | ok | 16:24 |
| *** msh <[email protected]> has quit IRC (Read error: Connection reset by peer) | 16:43 | |
| *** msh <[email protected]> has joined #litex | 16:43 | |
| *** cr1901 <cr1901!~William@2601:8d:8600:911:70fb:6a50:fd5:35b3> has joined #litex | 18:04 | |
| *** Martoni42 <Martoni42!~Martoni@2a03:d604:103:600:2ad2:44ff:fe23:2f72> has quit IRC (Ping timeout: 268 seconds) | 19:00 | |
| tpw_rules | is there good documentation on the litex ecosystem anywhere? i am trying to get a crossover uart running and it compiles now, but i don't know what to do from there | 19:09 |
| tpw_rules | and i'm really mystified in general about how everything works and i'm not usre hwo to learn more | 19:12 |
| tpw_rules | sure how* | 19:12 |
| _florent_ | tpw_rules: this can be useful to understand the bridges: https://github.com/enjoy-digital/litex/wiki/Use-Host-Bridge-to-control-debug-a-SoC | 19:25 |
| shorne | shenki: are you perhaps trying to test the .dts kernel params? | 20:31 |
| somlo | anyone have (a pointer to) an explanation of what additional initialization magic happens for vexriscv_smp in addition to what is done for the single-core case? I think the relevant diff is this: http://hastebin.com/ixademekoy.diff | 21:08 |
| tpb | Title: hastebin (at hastebin.com) | 21:08 |
| somlo | looks like hart #0 goes straight to bss_init, everyone else spins in an smp_slave loop, then everyone (?) eventually jumps to the address in smp_lottery_target? | 21:10 |
| somlo | except in line #68-69 of the diff we no longer enable external interrupt sources (like we used to for single-core), wondering why that's not a problem :) | 21:10 |
| somlo | Anyway, if there's a write-up somewhere on what the moving parts (and choreography) actually look like, I'd much appreciate the link... | 21:11 |
| shorne | somlo: I don't have a write up but I went through it when I did the SMP upstreaming work for openrisc , I did a presentation on it https://elinux.org/images/2/2b/Openrisc_smp_2017.pdf | 21:17 |
| shorne | but that doesn't discuss the CPU booting handoff | 21:17 |
| shorne | I think it is a bit generic though... | 21:17 |
| shorne | in Openrisc we just sit and wait for secondary_release flag: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/openrisc/kernel/head.S?h=v5.15-rc1#n713 | 21:20 |
| tpb | Title: head.S « kernel « openrisc « arch - kernel/git/torvalds/linux.git - Linux kernel source tree (at git.kernel.org) | 21:20 |
| *** nickoe <[email protected]> has joined #litex | 21:21 | |
| shorne | The secondary_release is triggered by (__cpu_up) in smp.c (should be the same on RISC-V) | 21:22 |
| shorne | When the secondary cpu's get releases the finish setup and jump to secondary_start_kernel. Which boots them then marks them as enabled in the kernel bookkeeping. | 21:25 |
| somlo | shorne: thanks! In the mean time I also found this: https://www.sifive.com/blog/all-aboard-part-6-booting-a-risc-v-linux-kernel | 21:26 |
| somlo | which suggests that basically all harts but 0 are looping until boot_helper() is ready to jump into linux (or bbl, or whatever was loaded into RAM by the BIOS) | 21:26 |
| shorne | Nice, the bits in OpenRISC might be more simple, but it should help understand how the secondary cores get released. | 21:26 |
| shorne | For openrisc all cores boot up to ram address 0x100, the program code is the same for each for they check their COREID, CORE-0 goes ahead and all others wait. | 21:28 |
| somlo | the only weird think is that for single-core external interrupts are enabled right before calling the bios main() function, but that's *NOT* the case on smp, which feels weird to me... | 21:28 |
| shorne | well, for RISC-V I remember one thing. There is this thing called IPI | 21:28 |
| shorne | inter process interrups, which are used to send messages between cores | 21:29 |
| somlo | that's a thing on x86 as well, iirc | 21:29 |
| shorne | that is how IRQ balancing is handled too, i.e. CPU0 may say, hey CPU1 can you take over hanlding IRQ 23 now? and the masking is moved from CPU0 to CPU1 | 21:29 |
| shorne | For OpenRISC and most architectures we do IPI with external interrupts | 21:30 |
| somlo | not sure how it applies here, but worth following up... I'll have a look at your slides as well, maybe after staring at everything for a few iterations something will end up making sense :) | 21:30 |
| shorne | for RISC-V, they do IPI via the SBI | 21:30 |
| shorne | so maybe they don't need external itnerrupts enabled | 21:30 |
| somlo | for context, I've built a multicore Rocket (4 fpu-less cores fit on e.g. a nexys4ddr), and I'm trying to get it to load the bios (right now I'm getting crickets on the console) | 21:31 |
| sorear | the problem with "all cores enter the kernel at once" is that it requires all of your bootloader stages to be SMP-aware | 21:31 |
| somlo | and I think step #1 is updating crt0.S... | 21:31 |
| shorne | somlo: not sure if you caught it is my thought is the on RISC-V because they do IPI via the SBI instructions they don't need external interrupts enabled. They will be enabled when IRQ balancing happens by the kernel later. | 21:33 |
| somlo | I *think* BBL is, but I haven't made it that far yet -- getting no output on the console from LiteX bios (no big surprise there) which is why my first step was to diff the uni-vs-multi core vexriscv crt0.S files :) | 21:33 |
| shorne | or by irqbalancer | 21:33 |
| shorne | But in terms of the console, its usually handled by CPU0 until it gets handed over later with irq smp_affinity changes | 21:34 |
| shorne | somlo: did you see my recent changes for json2dts? | 21:34 |
| somlo | I know Rocket has a built in PLIC, whereas vexriscv is a bit different in terms of how irq handling is done | 21:35 |
| sorear | BBL is but (if memory serves) u-boot isn't and requires the use of a spintable instead | 21:35 |
| shorne | One change I did is change bootparams: earlycon=sbi to earlycon=liteuart,0x{:x} | 21:36 |
| somlo | shorne: I saw them "fly by", didn't look too closely :) | 21:36 |
| shorne | https://github.com/enjoy-digital/litex/pull/1032/files | 21:36 |
| somlo | I did try both of those in the dts I compile into BBL, (earlicon sbi vs. directly liteuart) -- both seem to work | 21:37 |
| somlo | the latter is probably cheaper (saves a trap into m-mode to have bbl handle it there) | 21:37 |
| shorne | I see, in terms of litex bios having issues its not going to be related to the linux console settings | 21:37 |
| somlo | shorne: I don't get the litex logo and memtest output, way before I'd ever jump into anything loaded from "media" (like bbl, or the kernel, or anything like that) | 21:38 |
| somlo | so my multiple cores seem to be tripping over each other due to a single-core-only crt0.S in soc/cores/cpu/rocket/ | 21:39 |
| somlo | I'll probably hit another brick wall once the built-in bios loads and I try to boot something, but that's a bridge I'll have to cross later :) | 21:39 |
| somlo | sorry, mixing a bunch of cheesy metaphors :D | 21:40 |
| shorne | I see, yeah you will need the bootloader / pre kernel stuff understand SMP too | 21:42 |
| shorne | haha you'll be able to Wrangle this issue | 21:43 |
| *** alainlou <[email protected]> has joined #litex | 21:55 | |
| alainlou | EE majors! Why would adding header cables to the address bus solve any problems? (full details of my question here: https://github.com/litex-hub/litex-boards/issues/253#issuecomment-917727037) | 22:02 |
| *** geertu <[email protected]> has quit IRC (Ping timeout: 252 seconds) | 23:03 | |
| *** geertu <[email protected]> has joined #litex | 23:20 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!