<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
<jevinskie[m]>
Link status also shows as up via MDIO
<jevinskie[m]>
Verified with both litescope on the clocks themselves (from eth’s crg submod) and via counters
<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 (:
<jevinskie[m]>
Crap, it’s fed by a silabs clock gen, not the fpga.
<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
<sajattack[m]>
Oh yeah
<sajattack[m]>
I thought the buildroot was the last thing loaded though
<sajattack[m]>
ie it could fill the rest of ram
nickoe has quit [Ping timeout: 252 seconds]
<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?
<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
michalsieron has joined #litex
<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
<_florent_>
I think the KC705 uses this PHY, this could be worth comparing your hardware/code vs this board/target
michalsieron has quit [Remote host closed the connection]
michalsieron has joined #litex
michalsieron has quit [Remote host closed the connection]
<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
<jevinskie[m]>
Also not generating the 125 MHz clock on gtx regardless of if I’m passing it to the phy
<jevinskie[m]>
BTW, florent, litex’s CSRs, *bone bridges and litex_server are so fantastic, it feels like I have superpowers :P
<_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.
<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
<shenki>
it jumps to the payload and I don't see any output
<shenki>
are there issues with using the prebuilt opensbi and litex master?
<sajattack[m]>
does this mean I need to not use ilp32d?
_franck_0 has joined #litex
_franck_ has quit [Ping timeout: 268 seconds]
_franck_0 is now known as _franck_
_franck_5 has joined #litex
FabM has quit [Quit: Leaving]
Martoni42 has joined #litex
_franck_ has quit [Ping timeout: 265 seconds]
_franck_5 is now known as _franck_
<Melkhior>
sajattack[m]: ilp32d requires support in the entire system - kernel, buildroot, compiler, binutils, gdb, ... (and likely run on RV32G)
<Melkhior>
that's what I use, so it is usable :-)
<sajattack[m]>
ok
msh has quit [Read error: Connection reset by peer]
msh has joined #litex
cr1901 has joined #litex
Martoni42 has quit [Ping timeout: 268 seconds]
<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
<tpw_rules>
and i'm really mystified in general about how everything works and i'm not usre hwo to learn more
<shorne>
shenki: are you perhaps trying to test the .dts kernel params?
<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
<tpb>
Title: hastebin (at hastebin.com)
<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?
<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 :)
<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...
<tpb>
Title: head.S « kernel « openrisc « arch - kernel/git/torvalds/linux.git - Linux kernel source tree (at git.kernel.org)
nickoe has joined #litex
<shorne>
The secondary_release is triggered by (__cpu_up) in smp.c (should be the same on RISC-V)
<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.
<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)
<shorne>
Nice, the bits in OpenRISC might be more simple, but it should help understand how the secondary cores get released.
<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.
<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...
<shorne>
well, for RISC-V I remember one thing. There is this thing called IPI
<shorne>
inter process interrups, which are used to send messages between cores
<somlo>
that's a thing on x86 as well, iirc
<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
<shorne>
For OpenRISC and most architectures we do IPI with external interrupts
<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 :)
<shorne>
for RISC-V, they do IPI via the SBI
<shorne>
so maybe they don't need external itnerrupts enabled
<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)
<sorear>
the problem with "all cores enter the kernel at once" is that it requires all of your bootloader stages to be SMP-aware
<somlo>
and I think step #1 is updating crt0.S...
<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.
<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 :)
<shorne>
or by irqbalancer
<shorne>
But in terms of the console, its usually handled by CPU0 until it gets handed over later with irq smp_affinity changes
<shorne>
somlo: did you see my recent changes for json2dts?
<somlo>
I know Rocket has a built in PLIC, whereas vexriscv is a bit different in terms of how irq handling is done
<sorear>
BBL is but (if memory serves) u-boot isn't and requires the use of a spintable instead
<shorne>
One change I did is change bootparams: earlycon=sbi to earlycon=liteuart,0x{:x}
<somlo>
shorne: I saw them "fly by", didn't look too closely :)
<somlo>
I did try both of those in the dts I compile into BBL, (earlicon sbi vs. directly liteuart) -- both seem to work
<somlo>
the latter is probably cheaper (saves a trap into m-mode to have bbl handle it there)
<shorne>
I see, in terms of litex bios having issues its not going to be related to the linux console settings
<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)
<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/
<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 :)
<somlo>
sorry, mixing a bunch of cheesy metaphors :D
<shorne>
I see, yeah you will need the bootloader / pre kernel stuff understand SMP too
<shorne>
haha you'll be able to Wrangle this issue