UART Route setting

UART Route setting

[Henbin Chang]

[-- Attachment #1: Type: text/plain, Size: 178 bytes --]

Hi,

Could anyone know how to modify UART Route setting through dts, driver or
other mechanism?

Or I have to find a point to modify it e.g. board_init() in the u-boot.

Thanks.

[-- Attachment #2: Type: text/html, Size: 273 bytes --]

Re: UART Route setting

[Oskar Senft]

[-- Attachment #1: Type: text/plain, Size: 1188 bytes --]

Hi Henbin

It's funny that you ask, since I had just started to look into the same
problem.

I'd like to change the UART routing on an AST2500 when a client connects to
the obmc-console-server. The use case is to dynamically connect the host's
UART to a UART owned by the BMC.

I was thinking of writing a kernel driver that would expose the config
options from the HICRA register on AST2500 as /sys files. Each file
represents the target UART1..5 and IO1..5. The file value represents the
source UART1..5 and IO1..5. Not all combinations are supported by the
Aspeed, so I'd add the necessary checks and error reporting into the code.

An alternative would be to just use /dev/mem to do that, but my
understanding is that default support for that is going away or has gone
away.

Oskar.


---------- Forwarded message ----------
> From: Henbin Chang <henbinchang@gmail.com>
> Date: Wed, Aug 1, 2018 at 12:11 AM
> Subject: UART Route setting
> To: OpenBMC Maillist <openbmc@lists.ozlabs.org>
>
>
> Hi,
>
> Could anyone know how to modify UART Route setting through dts, driver
> or other mechanism?
>
> Or I have to find a point to modify it e.g. board_init() in the u-boot.
>
> Thanks.
>

[-- Attachment #2: Type: text/html, Size: 1889 bytes --]

Re: UART Route setting

[Henbin Chang]

[-- Attachment #1: Type: text/plain, Size: 2213 bytes --]

Hi Oskar,

Thanks your response.

In my machine design, the host uses AST2500 UART2 to implement console
redirection.
To make openbmc host consle/ipmi SOL workable, I use the 'local-tty =
ttyS2' setting and manually change the UART route (UART2<->UART3).

I found  VUART be used for host console after I checked some openpower
machines. Thus, they didn't meet this problem.

I also tried to look for any related discussion but got nothing.
To avoid any loss, I sent a mail to ask if any approach to change the UART
route under openbmc framework.

Currently, I add a hard code (modify HICRA regiser) in u-boot as the
workaround.

The suggestions you provided are good if the dynamic UART  route changing
is needed.

I may write a driver to handle the default UART route. It can be
enabled/disabled and get the the default UART route setting from machine dts,
and then modify the HICRA register.

Thanks.
Henbin.

2018-08-02 0:16 GMT+08:00 Oskar Senft <osk@google.com>:

> Hi Henbin
>
> It's funny that you ask, since I had just started to look into the same
> problem.
>
> I'd like to change the UART routing on an AST2500 when a client connects
> to the obmc-console-server. The use case is to dynamically connect the
> host's UART to a UART owned by the BMC.
>
> I was thinking of writing a kernel driver that would expose the config
> options from the HICRA register on AST2500 as /sys files. Each file
> represents the target UART1..5 and IO1..5. The file value represents the
> source UART1..5 and IO1..5. Not all combinations are supported by the
> Aspeed, so I'd add the necessary checks and error reporting into the code.
>
> An alternative would be to just use /dev/mem to do that, but my
> understanding is that default support for that is going away or has gone
> away.
>
> Oskar.
>
>
> ---------- Forwarded message ----------
>> From: Henbin Chang <henbinchang@gmail.com>
>> Date: Wed, Aug 1, 2018 at 12:11 AM
>> Subject: UART Route setting
>> To: OpenBMC Maillist <openbmc@lists.ozlabs.org>
>>
>>
>> Hi,
>>
>> Could anyone know how to modify UART Route setting through dts, driver
>> or other mechanism?
>>
>> Or I have to find a point to modify it e.g. board_init() in the u-boot.
>>
>> Thanks.
>>
>

[-- Attachment #2: Type: text/html, Size: 3648 bytes --]

Re: UART Route setting

[Oskar Senft]

[-- Attachment #1: Type: text/plain, Size: 2729 bytes --]

Hi Henbin

I think we should be able to configure default settings for the routing
with the driver that I'm working on. I guess that could be done via DTS or
by just applying settings via /sys during boot.

What do you think?

For my use case, I'll need the setting to be changed back and forth during
runtime from the obmc-console-server.

Oskar.

On Wed, Aug 1, 2018, 8:30 PM Henbin Chang <henbinchang@gmail.com> wrote:

> Hi Oskar,
>
> Thanks your response.
>
> In my machine design, the host uses AST2500 UART2 to implement console
> redirection.
> To make openbmc host consle/ipmi SOL workable, I use the 'local-tty =
> ttyS2' setting and manually change the UART route (UART2<->UART3).
>
> I found  VUART be used for host console after I checked some openpower
> machines. Thus, they didn't meet this problem.
>
> I also tried to look for any related discussion but got nothing.
> To avoid any loss, I sent a mail to ask if any approach to change the UART
> route under openbmc framework.
>
> Currently, I add a hard code (modify HICRA regiser) in u-boot as the
> workaround.
>
> The suggestions you provided are good if the dynamic UART  route changing
> is needed.
>
> I may write a driver to handle the default UART route. It can be
> enabled/disabled and get the the default UART route setting from machine
> dts, and then modify the HICRA register.
>
> Thanks.
> Henbin.
>
> 2018-08-02 0:16 GMT+08:00 Oskar Senft <osk@google.com>:
>
>> Hi Henbin
>>
>> It's funny that you ask, since I had just started to look into the same
>> problem.
>>
>> I'd like to change the UART routing on an AST2500 when a client connects
>> to the obmc-console-server. The use case is to dynamically connect the
>> host's UART to a UART owned by the BMC.
>>
>> I was thinking of writing a kernel driver that would expose the config
>> options from the HICRA register on AST2500 as /sys files. Each file
>> represents the target UART1..5 and IO1..5. The file value represents the
>> source UART1..5 and IO1..5. Not all combinations are supported by the
>> Aspeed, so I'd add the necessary checks and error reporting into the code.
>>
>> An alternative would be to just use /dev/mem to do that, but my
>> understanding is that default support for that is going away or has gone
>> away.
>>
>> Oskar.
>>
>>
>> ---------- Forwarded message ----------
>>> From: Henbin Chang <henbinchang@gmail.com>
>>> Date: Wed, Aug 1, 2018 at 12:11 AM
>>> Subject: UART Route setting
>>> To: OpenBMC Maillist <openbmc@lists.ozlabs.org>
>>>
>>>
>>> Hi,
>>>
>>> Could anyone know how to modify UART Route setting through dts, driver
>>> or other mechanism?
>>>
>>> Or I have to find a point to modify it e.g. board_init() in the u-boot.
>>>
>>> Thanks.
>>>
>>
>

[-- Attachment #2: Type: text/html, Size: 4602 bytes --]

Re: UART Route setting

[Andrew Jeffery]

Hi Oskar, Henbin,

On Thu, 2 Aug 2018, at 10:32, Oskar Senft wrote:
> Hi Henbin
> 
> I think we should be able to configure default settings for the routing
> with the driver that I'm working on. I guess that could be done via DTS or
> by just applying settings via /sys during boot.

Have you explored writing a pinmux driver for it? It's effectively what these
registers represent.

It was something that wound up down the bottom of my todo list.

This enables configuring the routing via DTS, though doing it dynamically
from userspace might be a bit harder.

Cheers,

Andrew

Re: UART Route setting

[Oskar Senft]

[-- Attachment #1: Type: text/plain, Size: 914 bytes --]

Hi Andrew

Thanks for the suggestion. I see that the register would map quite nicely
to pinmux. However, the ability to change the configuration from user space
is critical. How could that be done via pinmux?

Thanks
Oskar.


On Wed, Aug 1, 2018, 9:18 PM Andrew Jeffery <andrew@aj.id.au> wrote:

> Hi Oskar, Henbin,
>
> On Thu, 2 Aug 2018, at 10:32, Oskar Senft wrote:
> > Hi Henbin
> >
> > I think we should be able to configure default settings for the routing
> > with the driver that I'm working on. I guess that could be done via DTS
> or
> > by just applying settings via /sys during boot.
>
> Have you explored writing a pinmux driver for it? It's effectively what
> these
> registers represent.
>
> It was something that wound up down the bottom of my todo list.
>
> This enables configuring the routing via DTS, though doing it dynamically
> from userspace might be a bit harder.
>
> Cheers,
>
> Andrew
>

[-- Attachment #2: Type: text/html, Size: 1363 bytes --]

Re: UART Route setting

[Lei YU]

On Thu, Aug 2, 2018 at 9:55 AM Oskar Senft <osk@google.com> wrote:
>
> Hi Andrew
>
> Thanks for the suggestion. I see that the register would map quite nicely to pinmux. However, the ability to change the configuration from user space is critical. How could that be done via pinmux?

I believe Andrew Jeffery's [bmc-misc-ctr][1] driver is perfect for this
requirement:
1. You can define related registers in dts and expose as sysfs attributes
2. User space is able to read/write the sysfs attributes to do what you need
   to configure.

[1]: https://patchwork.ozlabs.org/cover/942322/

Re: UART Route setting

[Oskar Senft]

[-- Attachment #1: Type: text/plain, Size: 829 bytes --]

Interesting suggestion, that looks promising, thank you?

What's the state of that driver? I.e. where do we expect it to land?

Thanks
Oskar.

On Wed, Aug 1, 2018, 10:12 PM Lei YU <mine260309@gmail.com> wrote:

> On Thu, Aug 2, 2018 at 9:55 AM Oskar Senft <osk@google.com> wrote:
> >
> > Hi Andrew
> >
> > Thanks for the suggestion. I see that the register would map quite
> nicely to pinmux. However, the ability to change the configuration from
> user space is critical. How could that be done via pinmux?
>
> I believe Andrew Jeffery's [bmc-misc-ctr][1] driver is perfect for this
> requirement:
> 1. You can define related registers in dts and expose as sysfs attributes
> 2. User space is able to read/write the sysfs attributes to do what you
> need
>    to configure.
>
> [1]: https://patchwork.ozlabs.org/cover/942322/
>

[-- Attachment #2: Type: text/html, Size: 1416 bytes --]

Re: UART Route setting

[Andrew Jeffery]

On Thu, 2 Aug 2018, at 12:50, Oskar Senft wrote:
> Interesting suggestion, that looks promising, thank you?
> 
> What's the state of that driver? I.e. where do we expect it to land?

If you think the bmc-misc-ctrl series is useful, please reply to the
upstream thread to outline all of your use-cases. There's a lot of push-
back on using the devicetree to describe these features, and I haven't
had a lot of feedback on the acceptability of the rest (driver itself,
userspace ABI).

The more evidence we have of this being necessary/useful the better.

Cheers,

Andrew

> 
> Thanks
> Oskar.
> 
> On Wed, Aug 1, 2018, 10:12 PM Lei YU <mine260309@gmail.com> wrote:
> 
> > On Thu, Aug 2, 2018 at 9:55 AM Oskar Senft <osk@google.com> wrote:
> > >
> > > Hi Andrew
> > >
> > > Thanks for the suggestion. I see that the register would map quite
> > nicely to pinmux. However, the ability to change the configuration from
> > user space is critical. How could that be done via pinmux?
> >
> > I believe Andrew Jeffery's [bmc-misc-ctr][1] driver is perfect for this
> > requirement:
> > 1. You can define related registers in dts and expose as sysfs attributes
> > 2. User space is able to read/write the sysfs attributes to do what you
> > need
> >    to configure.
> >
> > [1]: https://patchwork.ozlabs.org/cover/942322/
> >

Re: UART Route setting

[Avi Fishman]

On Thu, Aug 2, 2018 at 6:34 AM Andrew Jeffery <andrew@aj.id.au> wrote:
>
> On Thu, 2 Aug 2018, at 12:50, Oskar Senft wrote:
> > Interesting suggestion, that looks promising, thank you?
> >
> > What's the state of that driver? I.e. where do we expect it to land?
>
> If you think the bmc-misc-ctrl series is useful, please reply to the
> upstream thread to outline all of your use-cases. There's a lot of push-
> back on using the devicetree to describe these features, and I haven't
> had a lot of feedback on the acceptability of the rest (driver itself,
> userspace ABI).
>
> The more evidence we have of this being necessary/useful the better.

Oskar,
Here is the link to put your support:
https://lore.kernel.org/patchwork/patch/961584/

>
> Cheers,
>
> Andrew
>
> >
> > Thanks
> > Oskar.
> >
> > On Wed, Aug 1, 2018, 10:12 PM Lei YU <mine260309@gmail.com> wrote:
> >
> > > On Thu, Aug 2, 2018 at 9:55 AM Oskar Senft <osk@google.com> wrote:
> > > >
> > > > Hi Andrew
> > > >
> > > > Thanks for the suggestion. I see that the register would map quite
> > > nicely to pinmux. However, the ability to change the configuration from
> > > user space is critical. How could that be done via pinmux?
> > >
> > > I believe Andrew Jeffery's [bmc-misc-ctr][1] driver is perfect for this
> > > requirement:
> > > 1. You can define related registers in dts and expose as sysfs attributes
> > > 2. User space is able to read/write the sysfs attributes to do what you
> > > need
> > >    to configure.
> > >
> > > [1]: https://patchwork.ozlabs.org/cover/942322/
> > >



-- 
Regards,
Avi

Re: UART Route setting

[Oskar Senft]

[-- Attachment #1: Type: text/plain, Size: 2419 bytes --]

Thanks! After reading the various comments on the thread, I do understand
the argument that we're missing some abstraction by exposing individual
bits of HW registers to user space. While it's certainly MUCH better than
/dev/mem and particularly useful during rapid development, I still somewhat
feel that it would be beneficial in the long-run to use a proper
abstraction layer with /sys as interface to explicitly expose the "dozens"
of configuration options.

I'm that having an explicit driver that only exposes the HICRA (to
configure UART routing) as abstract symbols would be beneficial. Do you
think I'd find support for getting that submitted?

On Thu, Aug 2, 2018 at 11:00 AM Avi Fishman <avifishman70@gmail.com> wrote:

> On Thu, Aug 2, 2018 at 6:34 AM Andrew Jeffery <andrew@aj.id.au> wrote:
> >
> > On Thu, 2 Aug 2018, at 12:50, Oskar Senft wrote:
> > > Interesting suggestion, that looks promising, thank you?
> > >
> > > What's the state of that driver? I.e. where do we expect it to land?
> >
> > If you think the bmc-misc-ctrl series is useful, please reply to the
> > upstream thread to outline all of your use-cases. There's a lot of push-
> > back on using the devicetree to describe these features, and I haven't
> > had a lot of feedback on the acceptability of the rest (driver itself,
> > userspace ABI).
> >
> > The more evidence we have of this being necessary/useful the better.
>
> Oskar,
> Here is the link to put your support:
> https://lore.kernel.org/patchwork/patch/961584/
>
> >
> > Cheers,
> >
> > Andrew
> >
> > >
> > > Thanks
> > > Oskar.
> > >
> > > On Wed, Aug 1, 2018, 10:12 PM Lei YU <mine260309@gmail.com> wrote:
> > >
> > > > On Thu, Aug 2, 2018 at 9:55 AM Oskar Senft <osk@google.com> wrote:
> > > > >
> > > > > Hi Andrew
> > > > >
> > > > > Thanks for the suggestion. I see that the register would map quite
> > > > nicely to pinmux. However, the ability to change the configuration
> from
> > > > user space is critical. How could that be done via pinmux?
> > > >
> > > > I believe Andrew Jeffery's [bmc-misc-ctr][1] driver is perfect for
> this
> > > > requirement:
> > > > 1. You can define related registers in dts and expose as sysfs
> attributes
> > > > 2. User space is able to read/write the sysfs attributes to do what
> you
> > > > need
> > > >    to configure.
> > > >
> > > > [1]: https://patchwork.ozlabs.org/cover/942322/
> > > >
>
>
>
> --
> Regards,
> Avi
>

[-- Attachment #2: Type: text/html, Size: 3640 bytes --]

Re: UART Route setting

[Patrick Venture]

On Wed, Aug 1, 2018 at 8:33 PM, Andrew Jeffery <andrew@aj.id.au> wrote:
> On Thu, 2 Aug 2018, at 12:50, Oskar Senft wrote:
>> Interesting suggestion, that looks promising, thank you?
>>
>> What's the state of that driver? I.e. where do we expect it to land?
>
> If you think the bmc-misc-ctrl series is useful, please reply to the
> upstream thread to outline all of your use-cases. There's a lot of push-
> back on using the devicetree to describe these features, and I haven't
> had a lot of feedback on the acceptability of the rest (driver itself,
> userspace ABI).
>
> The more evidence we have of this being necessary/useful the better.

I just skimmed that message, and we're looking for a mechanism to set
in the kernel some bits in the hwstrapping and other hardware
registers to do things like restrict P2A ranges, disable lpc2ahb
stuff, etc.  Things we had hacked into the mach-aspeed.c (iirc), and I
wasn't sure it made sense to write a half dozen small drivers to
control these individual things -- would these kind of use cases fall
under this misc driver?

>
> Cheers,
>
> Andrew
>
>>
>> Thanks
>> Oskar.
>>
>> On Wed, Aug 1, 2018, 10:12 PM Lei YU <mine260309@gmail.com> wrote:
>>
>> > On Thu, Aug 2, 2018 at 9:55 AM Oskar Senft <osk@google.com> wrote:
>> > >
>> > > Hi Andrew
>> > >
>> > > Thanks for the suggestion. I see that the register would map quite
>> > nicely to pinmux. However, the ability to change the configuration from
>> > user space is critical. How could that be done via pinmux?
>> >
>> > I believe Andrew Jeffery's [bmc-misc-ctr][1] driver is perfect for this
>> > requirement:
>> > 1. You can define related registers in dts and expose as sysfs attributes
>> > 2. User space is able to read/write the sysfs attributes to do what you
>> > need
>> >    to configure.
>> >
>> > [1]: https://patchwork.ozlabs.org/cover/942322/
>> >

Re: UART Route setting

[Andrew Jeffery]

On Sat, 4 Aug 2018, at 00:29, Patrick Venture wrote:
> On Wed, Aug 1, 2018 at 8:33 PM, Andrew Jeffery <andrew@aj.id.au> wrote:
> > On Thu, 2 Aug 2018, at 12:50, Oskar Senft wrote:
> >> Interesting suggestion, that looks promising, thank you?
> >>
> >> What's the state of that driver? I.e. where do we expect it to land?
> >
> > If you think the bmc-misc-ctrl series is useful, please reply to the
> > upstream thread to outline all of your use-cases. There's a lot of push-
> > back on using the devicetree to describe these features, and I haven't
> > had a lot of feedback on the acceptability of the rest (driver itself,
> > userspace ABI).
> >
> > The more evidence we have of this being necessary/useful the better.
> 
> I just skimmed that message, and we're looking for a mechanism to set
> in the kernel some bits in the hwstrapping and other hardware
> registers to do things like restrict P2A ranges, disable lpc2ahb
> stuff, etc.  Things we had hacked into the mach-aspeed.c (iirc), and I
> wasn't sure it made sense to write a half dozen small drivers to
> control these individual things -- would these kind of use cases fall
> under this misc driver?

Yes, everything you listed there was a strong motivation for the series.

Cheers

Andrew

Re: UART Route setting

[Patrick Venture]

+kunyi@

PTAL - I know we're looking for a way to move the hacks forward
properly, a driver or driver(s) is apparently already in the works,
albeit with upstream resistance.

Patrick

On Fri, Aug 3, 2018 at 3:03 PM, Andrew Jeffery <andrew@aj.id.au> wrote:
>
>
> On Sat, 4 Aug 2018, at 00:29, Patrick Venture wrote:
>> On Wed, Aug 1, 2018 at 8:33 PM, Andrew Jeffery <andrew@aj.id.au> wrote:
>> > On Thu, 2 Aug 2018, at 12:50, Oskar Senft wrote:
>> >> Interesting suggestion, that looks promising, thank you?
>> >>
>> >> What's the state of that driver? I.e. where do we expect it to land?
>> >
>> > If you think the bmc-misc-ctrl series is useful, please reply to the
>> > upstream thread to outline all of your use-cases. There's a lot of push-
>> > back on using the devicetree to describe these features, and I haven't
>> > had a lot of feedback on the acceptability of the rest (driver itself,
>> > userspace ABI).
>> >
>> > The more evidence we have of this being necessary/useful the better.
>>
>> I just skimmed that message, and we're looking for a mechanism to set
>> in the kernel some bits in the hwstrapping and other hardware
>> registers to do things like restrict P2A ranges, disable lpc2ahb
>> stuff, etc.  Things we had hacked into the mach-aspeed.c (iirc), and I
>> wasn't sure it made sense to write a half dozen small drivers to
>> control these individual things -- would these kind of use cases fall
>> under this misc driver?
>
> Yes, everything you listed there was a strong motivation for the series.
>
> Cheers
>
> Andrew

Re: UART Route setting

[Kun Yi]

[-- Attachment #1: Type: text/plain, Size: 1916 bytes --]

Thanks Patrick. I was aware of the driver but haven't thoroughly checked
the email thread. IMO it's a great idea and something I've hoped for. Will
post some comments in the thread for support.

On Mon, Aug 6, 2018 at 9:48 AM Patrick Venture <venture@google.com> wrote:

> +kunyi@
>
> PTAL - I know we're looking for a way to move the hacks forward
> properly, a driver or driver(s) is apparently already in the works,
> albeit with upstream resistance.
>
> Patrick
>
> On Fri, Aug 3, 2018 at 3:03 PM, Andrew Jeffery <andrew@aj.id.au> wrote:
> >
> >
> > On Sat, 4 Aug 2018, at 00:29, Patrick Venture wrote:
> >> On Wed, Aug 1, 2018 at 8:33 PM, Andrew Jeffery <andrew@aj.id.au> wrote:
> >> > On Thu, 2 Aug 2018, at 12:50, Oskar Senft wrote:
> >> >> Interesting suggestion, that looks promising, thank you?
> >> >>
> >> >> What's the state of that driver? I.e. where do we expect it to land?
> >> >
> >> > If you think the bmc-misc-ctrl series is useful, please reply to the
> >> > upstream thread to outline all of your use-cases. There's a lot of
> push-
> >> > back on using the devicetree to describe these features, and I haven't
> >> > had a lot of feedback on the acceptability of the rest (driver itself,
> >> > userspace ABI).
> >> >
> >> > The more evidence we have of this being necessary/useful the better.
> >>
> >> I just skimmed that message, and we're looking for a mechanism to set
> >> in the kernel some bits in the hwstrapping and other hardware
> >> registers to do things like restrict P2A ranges, disable lpc2ahb
> >> stuff, etc.  Things we had hacked into the mach-aspeed.c (iirc), and I
> >> wasn't sure it made sense to write a half dozen small drivers to
> >> control these individual things -- would these kind of use cases fall
> >> under this misc driver?
> >
> > Yes, everything you listed there was a strong motivation for the series.
> >
> > Cheers
> >
> > Andrew
>


-- 
Regards,
Kun

[-- Attachment #2: Type: text/html, Size: 2765 bytes --]