ChanServ changed the topic of #armlinux to: ARM kernel talk [Upstream kernel, find your vendor forums for questions about their kernels] | https://libera.irclog.whitequark.org/armlinux
Shailangsa_ has joined #armlinux
mvaittin has quit [Remote host closed the connection]
psydroid has quit [Write error: Connection reset by peer]
shoragan[m] has quit [Write error: Connection reset by peer]
a3f has quit [Read error: Connection reset by peer]
psydroid has joined #armlinux
scosu_ has joined #armlinux
scosu has quit [Ping timeout: 276 seconds]
shoragan[m] has joined #armlinux
mvaittin has joined #armlinux
a3f has joined #armlinux
wwilly has joined #armlinux
prabhakarlad has quit [Quit: Client closed]
Nact has quit [Quit: Konversation terminated!]
abelvesa has quit [*.net *.split]
Fridtjof has quit [*.net *.split]
javierm has quit [*.net *.split]
xdarklight has quit [*.net *.split]
pjw has quit [*.net *.split]
hauke has quit [*.net *.split]
sven has quit [*.net *.split]
ukleinek has quit [*.net *.split]
javierm_ has joined #armlinux
ukleinek_ has joined #armlinux
abelvesa_ has joined #armlinux
libera- has joined #armlinux
hauke has joined #armlinux
pjw has joined #armlinux
sven has joined #armlinux
Fridtjof has joined #armlinux
iivanov has joined #armlinux
libera- is now known as xdarklight
xdarklight has quit [Changing host]
xdarklight has joined #armlinux
ukleinek_ is now known as ukleinek
bps has joined #armlinux
frieder has joined #armlinux
<ukleinek>
narmstrong: do you have an idea about how the UART of the oxnas CPU could be special? We don't see any output on the console from userspace and if the baudrate is set using earlycon to the value that we already use to communicate in U-Boot we only see trash
<ukleinek>
narmstrong: After a warm reset from the vendor Linux the UART works
guillaume_g has joined #armlinux
sszy has joined #armlinux
bps has quit [Ping timeout: 240 seconds]
prabhakarlad has joined #armlinux
matthias_bgg has joined #armlinux
bps has joined #armlinux
bps has joined #armlinux
bps has quit [Changing host]
Pali has joined #armlinux
Pali has quit [Ping timeout: 240 seconds]
<narmstrong>
ukleinek: I only ran the kernel on the PogoPlug Series 3 with a "mainline" u-boot, so maybe the vendor u-boot doesn't leave the uart in a correct state
<narmstrong>
ukleinek: what do you mean by " warm reset from the vendor Linux the UART" ?
<ukleinek>
narmstrong: it's rather strange. We see the boot log, but the shell (with init=/bin/sh) doesn't appear
<ukleinek>
narmstrong: when the vendor OS is booted once and we boot mainline linux after a reboot, we see the output
<ukleinek>
Misanthropos: that's it, right?
<narmstrong>
ukleinek: indeed rather strange
<narmstrong>
the uart is a ns16550a, not aware of any specific stuff
<ukleinek>
we suspect it has something to do with baud rate setting. because when we specify the baudrate that is used in u-boot already in the earlycon parameter we only see trashed chars
<Misanthropos>
ukleinek, narmstrong yes that right, only after a warm reset of the oem kernel we can boot into our custom kernel
<Misanthropos>
otherwise it hangs at /init
<Misanthropos>
it could be a missing initialisation of a different hardware component though
<ukleinek>
but funny enough after some time we see the kernel log message that the random pool is initialized, so the UART still works after userspace opened it.
<Misanthropos>
ukleinek, you could check both boot logs when the machine arrives... maybe you will see something
<ukleinek>
probably this would be a trivial to debug problem if the UART worked reliably :-)
<Misanthropos>
that means to me, the uart is fine... something else is missing
<narmstrong>
maybe clocking
<Misanthropos>
but thats just speculation :-)
<narmstrong>
maybe the clock input is not the right one and the source clock changes
* ukleinek
doesn't know the 8250, but I would expect that in this case the kernel log message wouldn't make it through
<ukleinek>
s/8250/8250 driver/
<narmstrong>
did you look at the openwrt patchset ? maybe they solved this already without upstreaming it
* Misanthropos
shakes his head
* ukleinek
didn't spot anything either
<narmstrong>
AFAIK The clock scheme is definitely wrong, someone leaked me the clock tree and it must be wrong...
<Misanthropos>
meaning the clock is set correctly by the OEM and wont change on a warm boot? that could explain the findings
<narmstrong>
yes
<narmstrong>
I suspect the u-boot I have on the PogoPlug Series 3 does the same
<narmstrong>
as an experiment, disable code that sets the baudrate in the 8250...
<ukleinek>
narmstrong: yeah, that and instrumenting the register reads and writes is my plan
<ukleinek>
maybe booting the openwrt kernel would be an idea, too.
<narmstrong>
looking at the clock tree, there is a mux between PLLA & xtal for the peripheral clocks
<narmstrong>
maybe the plla and the mux aren't set correctly on the first boot
<ukleinek>
narmstrong: and for the console output the clk parent is switched back?
<narmstrong>
ukleinek: I think at the first boot, the mux is on xtal, so mainline linux does the wrong calculation when setting baudate from init (boot uses the already programmed rate), but booting from vendor kernel does the right PLLA & mux init so warm reboot has the right setup for mainline
<ukleinek>
narmstrong: do you understand my doubt?
<narmstrong>
the mux isn't handled at all on mainline
<narmstrong>
not even plla, we assume it's already set by the bootloader
<narmstrong>
at the time I did not have the clock tree
<ukleinek>
narmstrong: the thing is, after /dev/console is opened in userspace we still see output via printk, so the output only fails for userspace
<narmstrong>
ukleinek: oh, I wasn't aware of that at all
<ukleinek>
but if opening /dev/console would change the baud setting, I'd expect that printk was scrambled, too
<narmstrong>
ukleinek: how is this possible ?
<ukleinek>
narmstrong: I had now idea, so I thought I'd ask the oxnas expert :-)
<ukleinek>
s/now/no/
<narmstrong>
ukleinek: I think a TTY expert is need here
<narmstrong>
I don't think the TTY layer can change baurate between printk & /dev/console user
<ukleinek>
my best guess up to now is: /dev/console uses the fifo and printk doesn't. And somehow the fifo is blocked
<narmstrong>
yes it's something possible, maybe there is a missing quirk to be enabled
<ukleinek>
Misanthropos already checked the obvious registers in the UART, but there is no change after warmboot. So either it's somewhere else or in the shadowed register bank
<narmstrong>
there is an UARTA register `"Setting this bit causes RXRDY# and TXRDY# signals to respond more rapidly to accesses to the Rx and Tx FIFOs, enabling better compatibility with DMA engines"`
<narmstrong>
0x44200120 bit 0
<ukleinek>
Misanthropos: this is about &uart2, so I guess we have to look at 0x44900120
<ukleinek>
narmstrong: how big is the register space for the UART? we only compared the first 0x40 values