Pin mux utility?

Pin mux utility?

[Steve Sakoman]

Is anyone aware of a utility to report the state of pin mux settings?

I'd like to verify that u-boot is setting things up properly.

Steve

RE: Pin mux utility?

[Gadiyar, Anand]

> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org 
> [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Steve Sakoman
> 
> Is anyone aware of a utility to report the state of pin mux settings?
> 
> I'd like to verify that u-boot is setting things up properly.

How about reading the pin-mux registers directly?

Re: Pin mux utility?

[Steve Sakoman]

> How about reading the pin-mux registers directly?

That's the backup plan.  I was hoping there might be the equivalent of
the pxaregs utility for the pxa architecture - it produces a nicely
formatted text report of the current state of all pins and even allows
you to modify them.

Steve

RE: Pin mux utility?

[Gadiyar, Anand]

> > How about reading the pin-mux registers directly?
> 
> That's the backup plan.  I was hoping there might be the equivalent of
> the pxaregs utility for the pxa architecture - it produces a nicely
> formatted text report of the current state of all pins and even allows
> you to modify them.
> 

Din't know about that. Neat! Thanks for pointing it out,

- Anand

Re: Pin mux utility?

[David Brownell]

On Friday 29 August 2008, Steve Sakoman wrote:
> Is anyone aware of a utility to report the state of pin mux settings?
> 
> I'd like to verify that u-boot is setting things up properly.

CONFIG_OMAP_MUX_WARNINGS helps for some definitions of "properly":
when Linux needs one setting, but the boot loader leaves a different
one, you get a warning.  That's usually interpreted as u-boot doing
it wrong, except on devboards where the boot loader can't actually
know about all external hardware that might be hooked up (and how).

- Dave

Re: Pin mux utility?

[Igor Stoppa]

Hi,
On Fri, 2008-08-29 at 10:17 -0700, ext David Brownell wrote:
> On Friday 29 August 2008, Steve Sakoman wrote:
> > Is anyone aware of a utility to report the state of pin mux settings?
> > 
> > I'd like to verify that u-boot is setting things up properly.
> 
> CONFIG_OMAP_MUX_WARNINGS helps for some definitions of "properly":
> when Linux needs one setting, but the boot loader leaves a different
> one, you get a warning.  That's usually interpreted as u-boot doing
> it wrong, except on devboards where the boot loader can't actually
> know about all external hardware that might be hooked up (and how)

I'm probably a bit off topic, but since Tony started promoting the
concept of multi-arch binary, well, i see it as a huge limitation the
fact that the bootloader is expected to the right thing.

When thinking about our Nokia HW vs the TI SDP, even the bootloader is
different (yes, we should move to uboot and i couldn't be happier, but
it's not gonna happen at the moment).

In the multi arch case (but even single-arch, if we would like to
support multiple boards with one single kernel binary) i see as a much
more reasonable solution the case where the bootloader passes the board
id to the kernel and the kernel loads the board-specific configuration
in the form of a module.

DVFS for example defeats the idea that the bootloader would be enough to
setup properly the clock tree (of course it will do it, but only for 1
OP and the setting can get lost the first time another OP is selected).

Imho the bootloader should just do what the name suggests: load the
kernel and boot it. In as minimal configuration as possible.

-- 

Cheers, Igor

---

Igor Stoppa
Maemo Software - Nokia Devices R&D - Helsinki

Re: Pin mux utility?

[David Brownell]

On Friday 29 August 2008, Igor Stoppa wrote:
> > > I'd like to verify that u-boot is setting things up properly.
> > 
> > CONFIG_OMAP_MUX_WARNINGS helps for some definitions of "properly":
> > when Linux needs one setting, but the boot loader leaves a different
> > one, you get a warning.  That's usually interpreted as u-boot doing
> > it wrong, except on devboards where the boot loader can't actually
> > know about all external hardware that might be hooked up (and how)
> 
> I'm probably a bit off topic, but since Tony started promoting the
> concept of multi-arch binary, well, i see it as a huge limitation the
> fact that the bootloader is expected to the right thing.

The boot loader knows exactly what it's dealing with.  And by the
time it get past very early boot, so does Linux ...


> In the multi arch case (but even single-arch, if we would like to
> support multiple boards with one single kernel binary) i see as a much
> more reasonable solution the case where the bootloader passes the board
> id to the kernel and the kernel loads the board-specific configuration
> in the form of a module.

How the kernel gets that config data doesn't matter.  The current
solution is that all supported boards have setup code (board-XYZ.c
object code) statically linked.  Most of the board init code runs
at arch_initcall() time ... and it's keyed using the board ID.  CPU
setup code runs a bit earlier.


> DVFS for example defeats the idea that the bootloader would be enough to
> setup properly the clock tree (of course it will do it, but only for 1
> OP and the setting can get lost the first time another OP is selected).

I've not looked at recent clock tree issues.  $SUBJECT is about
pinmux, not clock tree.  I have no problems with the notion that
Linux not rely on the boot loader to set up esoteric stuff.


> Imho the bootloader should just do what the name suggests: load the
> kernel and boot it. In as minimal configuration as possible.

There's a lot to be said for not relying on boot loaders to do much
more than loading and starting a kernel.  Kernel requirements have a
tendancy to evolve over time, while boot loaders tend to never get
upgraded ... so kernels tend to set things up, regardless.

The whole "rely on boot loader to do ABC" bit can only make sense
in special contexts ... like a Nokia product team which has the
processes in place to clearly define "ABC" and test it.  For many
development boards that's often not practical.  And of course, the
logical extension of relying on bootloaders is what you see in PCs
with BIOS and ACPI; yeech!

- Dave

Re: Pin mux utility?

[Tony Lindgren]

* David Brownell <david-b@pacbell.net> [080829 11:12]:
> On Friday 29 August 2008, Igor Stoppa wrote:
> > > > I'd like to verify that u-boot is setting things up properly.
> > > 
> > > CONFIG_OMAP_MUX_WARNINGS helps for some definitions of "properly":
> > > when Linux needs one setting, but the boot loader leaves a different
> > > one, you get a warning.  That's usually interpreted as u-boot doing
> > > it wrong, except on devboards where the boot loader can't actually
> > > know about all external hardware that might be hooked up (and how)
> > 
> > I'm probably a bit off topic, but since Tony started promoting the
> > concept of multi-arch binary, well, i see it as a huge limitation the
> > fact that the bootloader is expected to the right thing.
> 
> The boot loader knows exactly what it's dealing with.  And by the
> time it get past very early boot, so does Linux ...
> 
> 
> > In the multi arch case (but even single-arch, if we would like to
> > support multiple boards with one single kernel binary) i see as a much
> > more reasonable solution the case where the bootloader passes the board
> > id to the kernel and the kernel loads the board-specific configuration
> > in the form of a module.
> 
> How the kernel gets that config data doesn't matter.  The current
> solution is that all supported boards have setup code (board-XYZ.c
> object code) statically linked.  Most of the board init code runs
> at arch_initcall() time ... and it's keyed using the board ID.  CPU
> setup code runs a bit earlier.
> 
> 
> > DVFS for example defeats the idea that the bootloader would be enough to
> > setup properly the clock tree (of course it will do it, but only for 1
> > OP and the setting can get lost the first time another OP is selected).
> 
> I've not looked at recent clock tree issues.  $SUBJECT is about
> pinmux, not clock tree.  I have no problems with the notion that
> Linux not rely on the boot loader to set up esoteric stuff.
> 
> 
> > Imho the bootloader should just do what the name suggests: load the
> > kernel and boot it. In as minimal configuration as possible.
> 
> There's a lot to be said for not relying on boot loaders to do much
> more than loading and starting a kernel.  Kernel requirements have a
> tendancy to evolve over time, while boot loaders tend to never get
> upgraded ... so kernels tend to set things up, regardless.
> 
> The whole "rely on boot loader to do ABC" bit can only make sense
> in special contexts ... like a Nokia product team which has the
> processes in place to clearly define "ABC" and test it.  For many
> development boards that's often not practical.  And of course, the
> logical extension of relying on bootloaders is what you see in PCs
> with BIOS and ACPI; yeech!

Yeah. We should set the pin configuration in board-*.c files.
It still does not leave out the option of only setting the pins in
bootloader if somebody wants to do that.

Tony