<BroderTuck>
"so everyone putting a new board dts file together simply have to know what are they doing. I see no way for escaping from that need."
<BroderTuck>
which makes me question the idea (maybe it's actually already outdated, but libv used to champion it) that it's users who should supply dts files, not devs.
hazardchem has quit [Read error: Connection reset by peer]
hazardchem has joined #linux-sunxi
<apritzel>
sdfgsdfs: what is your kernel command line, exactly? Should be printed in the kernel boot log.
<apritzel>
because if it contains "console=tty1", then you won't see any output on the serial. It would need to be "console=ttyS0,115200n8" instead
<sdfgsdfs>
well, where do the messages "booting Linux on physical cpu 0" "bootconsole [earlycon0] enabled" etc. come from? i figured earlybootk, no? and when does the devicetree console name prop get used?
<sdfgsdfs>
from earlyprintk* i meant
<sdfgsdfs>
I also tried setting console=sunxi-uart,0x05000000 and that didn't do anything... do you still want to see my bootargs (sans MAC addrs)?
<apritzel>
sdfgsdfs: the early messages indeed come from earlycon (there is no earlyprintk in arm64), which is somewhat separate from the real console
<apritzel>
"tty1" would be the first *graphical* console, so typically HDMI - if you have a driver for that and something connected, that is, so not on mainline at the moment
<apritzel>
"sunxi-uart" is a misguided driver name used only by the vendor kernel, that does nothing in mainline
<sdfgsdfs>
I don't know if my kernel is mainline or not. it's what is on the device spi nor flash
<apritzel>
oh no!
<apritzel>
that's not mainline, typically
<sdfgsdfs>
none of the bootargs pass earlycon, just earlyprintk. this is a cortex a53, so definitely arm64.
<apritzel>
the good news is: earlyprintk doesn't do any harm ;-) but it doesn't do anything on arm64 either
<apritzel>
(unless OrangePi hacked that badly, but I doubt it)
<apritzel>
I don't know how the vendor kernel names the console, but have you tried "ttyS0"?
<sdfgsdfs>
is there any smarter way to figure out what the hardcoded device is for earlycon, other than reversing the flash image??
<sdfgsdfs>
I have not tried that yet.
<apritzel>
how just "earlycon" works is to look at the "stdout-path" property in the DT
<sdfgsdfs>
yeah I just read that
<sdfgsdfs>
so it'd have to be /dev/console0 which is what I figured?
<apritzel>
/dev/console0 is just an alias, if there is nothing in the first place, I don't think it will help
<apritzel>
it should be "console=ttyS0", really
<apritzel>
definitely specifying the address as the console parameter is wrong, that only works for earlycon, if you don't have a stdout-path in the DT: "earlycon=uart,mmio32,0x50000000"
<apritzel>
(uart is short for uart8250, which happens to be the same device as the IBM PC UART, hence the generic short name)
<apritzel>
since you point at v4.14, is that the kernel version from the SPI flash that you are running?
<sdfgsdfs>
I added "earlycon=uart,mmio32,0x50000000" to the boot args and the kernel prints nothing now
<sdfgsdfs>
no, I just pasted some documentation from the googs
<sdfgsdfs>
the kernel i'm booting is [ 0.000000] Linux version 4.9.170 (orangepi@ubuntu) (gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05) ) #15 SMP PREEMPT Thu Jun 29 17:36:03 CST 2023
<apritzel>
ah, yeah, even worse. 4.9 is from 2016, so that's the usual outdated and bad vendor kernel
warpme has quit [Ping timeout: 480 seconds]
<sdfgsdfs>
does that change any of the semantics of earlycon/earlyprintk/console?
<apritzel>
hard to say, they hack it like there is no tomorrow, so all bets are off
<apritzel>
I think this sunxi-uart points in that direction, there is nothing like that in mainline
<apritzel>
anyway, if you don't need HDMI video output, you should switch to mainline
<apritzel>
there is little appetite in here to work around the horribly broken and outdated vendor kernel ...
<sdfgsdfs>
oh nevermind, i forgot i was looking at a much newer kernel version
<apritzel>
yeah, that's vendor kernel nonsense, where they use a different UART driver, so the earlycon name is different
<apritzel>
if you are using this kernel, this should work, though
<apritzel>
sdfgsdfs: keep in mind that "older" and "newer" kernel doesn't mean too much, it could still be a vendor kernel, with random changes, regardless of the version number it prints
<apritzel>
I think there are v6.1(?) vendor kernels for the H616/H618 out there, but there are not much better than that 4.9 one
<apritzel>
but again: the mainline documentation will not really help you, since it's a hacked vendor kernel, and they change random things
<apritzel>
I would recommend not to waste your time with this kernel, instead look into using a modern mainline based kernel
<sdfgsdfs>
ok
<apritzel>
there should be community based images with more mainliney kernels out there, like Armbian or such. Otherwise any recent self compiled or distro kernel should work
warpme has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
warpme has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
<tokyovigilante>
Have just pushed v3 of the DE33 patches, and LCD and HDMI are working out-of-tree on top of that, so the Orange Pi support should be pretty good now. Hopefully the DE33 code at least makes it into 6.12, and the LCD is pretty easy on top. HDMI may need more work for mainline as there are a few patches to the common code mixed in with the sun4i driver changes there.