Serial Over Lan (SOL) no login prompt on Linux IRQ mode

[Oskar Senft]

I just stumbled across this old-ish thread. I did run into a similar
problem ages ago. The problem is that the SIRQ polarity used by the
Aspeed must match what the "receiving end" (usually the PCH) is
expecting. I agree that the Aspeed doc is missing some details here. I
believe they might have clarified this on AST2600. Anyway, this
setting can be changed in the DTS via aspeed,lpc-interrupts [1] or at
runtime via the sysfs node sirq_polarity [2]. On the board I'm working
on (TYAN S7106 and S8036), this had to be set to HIGH:

&vuart {
    status = "okay";

    /* We enable the VUART here, but leave it in a state that does
     * not interfere with the SuperIO. The goal is to have both the
     * VUART and the SuperIO available and decide at runtime whether
     * the VUART should actually be used. For that reason, configure
     * an "invalid" IO address and an IRQ that is not used by the
     * BMC.
     */

    aspeed,lpc-io-reg = <0xffff>;
    aspeed,lpc-interrupts = <15 IRQ_TYPE_LEVEL_HIGH>;
};

Note that this change hasn't been added to upstream
aspeed-bmc-tyan-s7106.dts yet, just because I'm slow ...

Note that I previously introduced aspeed,sirq-polarity-sense for the
DTS, which tried to do this automatically, but it turned out to cause
issues, so it has been deprecated

I hope this write-up helps anyone in the future.

Oskar.

[1]: https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/serial/8250.yaml#L204
[2]: https://github.com/torvalds/linux/blob/master/Documentation/ABI/stable/sysfs-driver-aspeed-vuart#L17

On Tue, Jul 27, 2021 at 5:30 AM Paul Fertser <fercerpav at gmail.com> wrote:
>
> On Tue, Jul 27, 2021 at 11:53:57AM +0300, Konstantin Klubnichkin wrote:
> > SIRQ polarity is something I didn't try, will do it. And yes, SIRQ bit is zero,
> > but all other bits are also zero in that register, that confuses me.
>
> I was also able to manually export the SIRQ pin via sysfs and when
> manually toggling it the host was seeing UART interrupts and getting
> data to and from VUART. That lead nowhere though, so we resorted to
> hardware routing in ast2500 between "real UARTs".
>
> > Instead I configure UART routing by direct writing to registers via /dev/mem
> > (yes, I know that it's a bad practive, but it's development).
>
> Should work the same.
>
> > With the routing I have absolutely no data in BMC UARTs neither during POST nor
> > is OS.
> > What I'm missing is how that routing works. Is it on-crystal or UART need to be
> > routed to SoC pins thus TX/RX are connected via pins?
>
> With the configuration as shown the host is sending data to and from
> "COM1" (0x3f8,4) and any program on BMC is able to interact with it
> via /dev/ttyS2, without any additional hardware connections, all
> purely in software, the routing happens inside aspeed. Do not forget
> to enable ttyS2 in your board's DTS. VUART is not involved at all.
>
> --
> Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
> mailto:fercerpav at gmail.com