freakazoid333 has quit [Ping timeout: 255 seconds]
aerkiaga has quit [Remote host closed the connection]
<dramforever_>
dh`, jrtc27: thanks for the info!
<dramforever_>
For me it's a bit more about whether anyone has seen this behavior before, when working on, well, anything? Because surely I can't be the only person getting fetch page faults
<drmpeg>
Although whenever I see sun(number)i or sunxi, I think of Sun Microsystems, not Allwinner.
<dh`>
dramforever: you could well be the only person crosschecking stval against sepc
Noisytoot has quit [Ping timeout: 268 seconds]
<dh`>
ordinary trap code won't do that, it'll just save the pc value and pass the stval address to the VM system, then return to the pc value and never notice or care if they don't match
Noisytoot has joined #riscv
<dh`>
and ordinarily, someone applying the workaround you mentioned will by default only engage it on the processor it applies to without thinking very hard about it
<dramforever__>
so i probably should expect to be hitting all the weird cases
<dramforever__>
Repo description for those who don't want to bother going through the link: WIP: A fork of OpenSBI, with software-emulated hypervisor extension support
<conchuod>
I need (parts of) that or else I don't see any output
<conchuod>
Prob just down to what uart I am using, but I completely forgot about it
<mmind00>
I guess I'm not seeing _that_ because my cmdline comes from the pxe config right now ... though I'd have thought that the chosen node _should_ also set the correct terminal? ... But looks like it doesn't?
<mmind00>
conchuod: interesting question would be if you see the move from earlycon over to the regular tty in your kernel log?
<conchuod>
I also see a "Failed to initialize '/soc/timer@2050000': -22"
<conchuod>
"[ 0.008637] irq: no irq domain found for interrupt-controller@6010000 !"
<conchuod>
hmm
<mmind00>
I'm definitly _not_ seeing that ... strange
<conchuod>
I rebuilt again, just hung this time
<conchuod>
trying /again/
<conchuod>
Maybe I am just making a hames of things, dunno.
<conchuod>
I am on Linux version 6.0.0-rc1-00030-g9c1ba73cde81-dirty
<conchuod>
So effectively identical to you
<conchuod>
I think I am just missing your merge commits
<mmind00>
the patches are also limited enough that neither of us should've missed any :-) ... so really I guess the defconfig
<mmind00>
conchuod: hmm, funny question: where do you get your devicetree from?
<conchuod>
I did see the panic that Ron had, so there's something wrong somewhere in the kernel - but it is rc1...
<conchuod>
I don't use out of tree devicetrees
<mmind00>
no I meant does your dt come from u-boot ... or is it built from the kernel sources?
<conchuod>
Oh, is the d1 the one where it needs to come from outside the kernel?
<mmind00>
smaeul is advocating for that ... dtbs being firmware and all ;-) ... so from what I remember the firmware builds for the d1 boards are set up to supply the dtb to the kernel from u-boot
<conchuod>
Right, in this case my dtb is outside of the kernel sources. Usually I do a fitimage and the dtb is from the kernel.
<conchuod>
For the d1 I do a booti with ${fdtcontroladdr}
<mmind00>
conchuod: yep, that is what I'm running ... fit-image ... that's also the reason why there is the "hacked-in" memory node in my branch ;-)
<mmind00>
but yeah, there is the possibility that the dt you're running may be different
<conchuod>
Yeah, that's a good call. I'll have to check what this u-boot is. May end up going down the hacked memory node route b/c having to update u-boot for a kernel dtb is a pain
<conchuod>
I have no interest in reprogramming my boards if I can help it
<mmind00>
in an ideal world, the dtb should be part of the firmware and shouldn't need to change, as the bindings would be reviewed and stable ... but that doesn't really work while things are still in flux :-)
<conchuod>
Yup, I've felt that a lot too.
<conchuod>
We made a mess of our dts really, none of us really knew that much about it & we were working on something pretty old too.
<conchuod>
For customers they could easily take that approach though, and tbh I don't think it is that big of a deal if things change around before your soc is in actual production.
<conchuod>
your defconfig hangs around the same place too.
<conchuod>
hmm the interrupt controller stuff maybe had to change to comply with what Maz wanted
cousteau has quit [Quit: ♫ I can't forget the day I shot that network down ♫]
brazuca has joined #riscv
brazuca has quit [Ping timeout: 252 seconds]
<smaeul>
conchuod: where did you get "earlyprintk=sunxi-uart,0x02500000" from? earlyprintk is not a valid kernel parameter on riscv, and there is no such sunxi-uart driver.
<smaeul>
hanging after debug_vm_pgtable suggests a missing driver (or driver/compatible mismatch)
frkzoid has joined #riscv
<smaeul>
you can debug with deferred_probe_timeout
<smaeul>
you definitely need an updated DTB, as Rob had me rearrange the LDO bindings