From: Oskar Senft <osk@google.com>
To: Paul Fertser <fercerpav@gmail.com>,
"openbmc@lists.ozlabs.org" <openbmc@lists.ozlabs.org>,
Konstantin Klubnichkin <kitsok@yandex-team.ru>
Subject: Re: Serial Over Lan (SOL) no login prompt on Linux IRQ mode
Date: Wed, 24 Nov 2021 15:33:37 -0500 [thread overview]
Message-ID: <CABoTLcS+fPz=De0-tzOrzhwPd-b+tJ7M5H74+Qc=AiYM4vG3Pg@mail.gmail.com> (raw)
In-Reply-To: <20210727093015.GQ875@home.paul.comp>
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@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@gmail.com
prev parent reply other threads:[~2021-11-24 20:34 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-27 6:54 Serial Over Lan (SOL) no login prompt on Linux IRQ mode AKASH G J
2019-12-27 7:33 ` Yong Li
2019-12-30 0:02 ` AKASH G J
2021-07-26 14:36 ` Konstantin Klubnichkin
2021-07-26 14:52 ` Paul Fertser
2021-07-26 16:42 ` Konstantin Klubnichkin
2021-07-26 16:51 ` Paul Fertser
2021-07-27 8:53 ` Konstantin Klubnichkin
2021-07-27 9:30 ` Paul Fertser
2021-11-24 20:33 ` Oskar Senft [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CABoTLcS+fPz=De0-tzOrzhwPd-b+tJ7M5H74+Qc=AiYM4vG3Pg@mail.gmail.com' \
--to=osk@google.com \
--cc=fercerpav@gmail.com \
--cc=kitsok@yandex-team.ru \
--cc=openbmc@lists.ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).