<marcan>
those will tell you what kind of fault happened
<marcan>
ADR has the physical address (with some stuff in the top bits)
<kettenis>
thanks, will do
<kettenis>
thanks to m1n1 I can now easily switch between the correllium preloader and, erh, well m1n1 ;)
<marcan>
:)
<marcan>
fwiw, you can do msr((3, 3, 15, 8, 0), 0) with shell.py before chainloading u-boot
<marcan>
that's what preloader does, which just shoves all those errors under the carpet
<marcan>
but it might help confirm we're not dealing with something else here
<marcan>
ah, but that won't do it for SMP secondaries
<marcan>
though I think that one is per cluster
<marcan>
if so you have a 50/50 chance depending on the cpu :)
<marcan>
either way, let me know what values you get, I can do a quick experiment to confirm what they mean
<kettenis>
still running only on the first core
<marcan>
should work then
<kettenis>
yup, that "fixes" it
<kettenis>
will look at those IMPDEF registers
<kettenis>
thanks for the hints
<marcan>
np! let me know how it goes
<marcan>
I'll take the chance to document those registers a bit more, now that I have more tools to experiment with
<kettenis>
that'd be great
<kettenis>
one issue I'm facing is that "TTY mode" doesn't seem to work for me
<kettenis>
at least it doesn't show any serial output from u-boot and my kernel
<kettenis>
could very well be that the miniterm implementation in the python serial module is broken on OpenBSD
<jannau>
kettenis: serial console in uboot was working for me with u-boot a0de919efcd and trivial patches for the compatible strings, I think with miniterm
<kettenis>
I'm talking about the python miniterm implementation here
<kettenis>
if I use cu(4) I see the serial output
<kettenis>
ah, looks like our exuart(4) driver is touching a register that it shouldn't
<kettenis>
shouldn't be too difficult to fix
<kettenis>
dinner first though
<kettenis>
thanks again marcan
<kettenis>
do you want the register values?
<marcan>
might be useful, yeah
<marcan>
I was just running some tests to update the docs
<jannau>
I think I saw serial output from u-boot in python miniterm booted from m1n1
<kettenis>
L2C_ERR_STS 0x11000ffc00000082
<kettenis>
L2C_ERR_ADR 0x28000023520002c
<kettenis>
L2C_ERR_INF 0x2
<kettenis>
0x235200000 is the physical address of the uart
<marcan>
I *think* 82 means recursive fault, but maybe it doesn't
<marcan>
L2C_ERR_INF 2 I'm not sure about
<marcan>
the top bits in ADR are what I see for writes
<marcan>
ah, I just repro'd
<marcan>
I get that for 16-bit or 8-bit writes to that register
<marcan>
2C is UFRACVAL supposedly
<marcan>
I think this bus interface only allows 32-bit writes