ARM Machine SoC I/O setup and PAD initialization code

ARM Machine SoC I/O setup and PAD initialization code

[David Jander]

Hi all,

Having some experience with powerpc linux and being fairly new to ARM, I 
wonder about the following I have observed on ARM-linux so far:

General machine initialization like I/O-multiplexing and I/O-pad setup seems 
to be done twice most of the time: Once in the bootloader (i.e. u-boot), and 
once in the machine support file in the linux kernel. This seems awfully 
redundant and error-prone to me. Why is it like this?

Shouldn't I/O-pad setup and such stuff be duty of the bootloader alone? Why do 
I see so much platform setup code in the linux kernel that repeats this?

For example:
arch/arm/plat-mxc/include/mach/iomux-mx51.h

#define MX51_UART1_PAD_CTRL     (PAD_CTL_HYS | PAD_CTL_PKE | PAD_CTL_PUE | \
                                 PAD_CTL_DSE_HIGH)
...

IMHO this shouldn't be in the kernel, much less in this place. This define 
assumes somehow that on every i.MX51 based board I should configure any UART1 
pad as having high drive-strength and a pull-up. What drive strength the pad 
should have is a decision that the board hardware-designer must make 
individually for each board and pin of the UART. It cannot be something as 
generic as to put it into such a header-file. The kernel definitely shouldn't 
mess with those things.

So, why is it done like this?
Is it historically grown like this, and has noone yet had the time to fix 
this?
Or is it that boot-loaders on ARM in general don't do hardware setup correctly 
so that it has to be re-done in the kernel? What about fixing bootloaders 
then?

Best regards,

-- 
David Jander
Protonic Holland.

ARM Machine SoC I/O setup and PAD initialization code

[Russell King - ARM Linux]

On Wed, Jul 21, 2010 at 10:29:29AM +0200, David Jander wrote:
> General machine initialization like I/O-multiplexing and I/O-pad setup seems 
> to be done twice most of the time: Once in the bootloader (i.e. u-boot), and 
> once in the machine support file in the linux kernel. This seems awfully 
> redundant and error-prone to me. Why is it like this?

I answer your question only once - rather than the number of times you've
asked it in this email.

We do IO mux setup in the kernel for two reasons:

1. we don't trust boot loaders to do the right thing, especially when we
   have a plethora of boot loaders - or even no boot loader - to deal with.

2. on some platforms and SoCs, it's necessary to change the IO mux setup
   at runtime.

> What about fixing bootloaders then?

Forget fixing boot loaders; that's a total and utter lost cause.  Boot
loaders generally don't seem to even be capable of passing a block of
information correctly to the kernel, or even getting one simple value
in a register correct.

Boot loaders really can't be trusted, and the less we rely upon them,
the better.

ARM Machine SoC I/O setup and PAD initialization code

[Simon Horman]

On Wed, Jul 21, 2010 at 09:47:26AM +0100, Russell King - ARM Linux wrote:
> On Wed, Jul 21, 2010 at 10:29:29AM +0200, David Jander wrote:
> > General machine initialization like I/O-multiplexing and I/O-pad setup seems 
> > to be done twice most of the time: Once in the bootloader (i.e. u-boot), and 
> > once in the machine support file in the linux kernel. This seems awfully 
> > redundant and error-prone to me. Why is it like this?
> 
> I answer your question only once - rather than the number of times you've
> asked it in this email.
> 
> We do IO mux setup in the kernel for two reasons:
> 
> 1. we don't trust boot loaders to do the right thing, especially when we
>    have a plethora of boot loaders - or even no boot loader - to deal with.
> 
> 2. on some platforms and SoCs, it's necessary to change the IO mux setup
>    at runtime.
> 
> > What about fixing bootloaders then?
> 
> Forget fixing boot loaders; that's a total and utter lost cause.  Boot
> loaders generally don't seem to even be capable of passing a block of
> information correctly to the kernel, or even getting one simple value
> in a register correct.
> 
> Boot loaders really can't be trusted, and the less we rely upon them,
> the better.

Would it be feasible to  use Linux + kexec as the boot loader as
a long term solution to fixing boot loaders by eliminating them?

I believe Magnus Damn (CCed) amongst others have done work
in this area, though I'm not sure that it was on ARM.

ARM Machine SoC I/O setup and PAD initialization code

[Russell King - ARM Linux]

On Thu, Jul 22, 2010 at 11:32:53AM +0900, Simon Horman wrote:
> Would it be feasible to  use Linux + kexec as the boot loader as
> a long term solution to fixing boot loaders by eliminating them?

So what you're proposing is that a broken boot loader should boot a
version of Linux to fix the pin MUX, which then kexecs a kernel which
doesn't have that code?

What's the point of that - when the first kernel will be able to run
the system?

ARM Machine SoC I/O setup and PAD initialization code

[Simon Horman]

On Thu, Jul 22, 2010 at 08:20:34AM +0100, Russell King - ARM Linux wrote:
> On Thu, Jul 22, 2010 at 11:32:53AM +0900, Simon Horman wrote:
> > Would it be feasible to  use Linux + kexec as the boot loader as
> > a long term solution to fixing boot loaders by eliminating them?
> 
> So what you're proposing is that a broken boot loader should boot a
> version of Linux to fix the pin MUX, which then kexecs a kernel which
> doesn't have that code?
> 
> What's the point of that - when the first kernel will be able to run
> the system?

Ok, point taken, its impossible to remove the boot loaders.

ARM Machine SoC I/O setup and PAD initialization code

[Magnus Damm]

On Thu, Jul 22, 2010 at 4:29 PM, Simon Horman <horms@verge.net.au> wrote:
> On Thu, Jul 22, 2010 at 08:20:34AM +0100, Russell King - ARM Linux wrote:
>> On Thu, Jul 22, 2010 at 11:32:53AM +0900, Simon Horman wrote:
>> > Would it be feasible to ?use Linux + kexec as the boot loader as
>> > a long term solution to fixing boot loaders by eliminating them?
>>
>> So what you're proposing is that a broken boot loader should boot a
>> version of Linux to fix the pin MUX, which then kexecs a kernel which
>> doesn't have that code?
>>
>> What's the point of that - when the first kernel will be able to run
>> the system?
>
> Ok, point taken, its impossible to remove the boot loaders.

I disagree. We already use upstream Linux as a boot loader on SuperH.

For ARM and other architectures check out the ELC2010 presentation by
Greg Ungerer here:
http://elinux.org/images/7/7b/LinuxWithoutABootLoader.pdf

For SH and a more zoomed our perspective have a look at my presentation:
http://elinux.org/images/2/2f/ELC-2010-Damm-Kexec.pdf

Cheers,

/ magnus

ARM Machine SoC I/O setup and PAD initialization code

[Eric Miao]

On Thu, Jul 22, 2010 at 10:38 AM, Magnus Damm <magnus.damm@gmail.com> wrote:
> On Thu, Jul 22, 2010 at 4:29 PM, Simon Horman <horms@verge.net.au> wrote:
>> On Thu, Jul 22, 2010 at 08:20:34AM +0100, Russell King - ARM Linux wrote:
>>> On Thu, Jul 22, 2010 at 11:32:53AM +0900, Simon Horman wrote:
>>> > Would it be feasible to ?use Linux + kexec as the boot loader as
>>> > a long term solution to fixing boot loaders by eliminating them?
>>>
>>> So what you're proposing is that a broken boot loader should boot a
>>> version of Linux to fix the pin MUX, which then kexecs a kernel which
>>> doesn't have that code?
>>>
>>> What's the point of that - when the first kernel will be able to run
>>> the system?
>>
>> Ok, point taken, its impossible to remove the boot loaders.
>
> I disagree. We already use upstream Linux as a boot loader on SuperH.
>
> For ARM and other architectures check out the ELC2010 presentation by
> Greg Ungerer here:
> http://elinux.org/images/7/7b/LinuxWithoutABootLoader.pdf
>
> For SH and a more zoomed our perspective have a look at my presentation:
> http://elinux.org/images/2/2f/ELC-2010-Damm-Kexec.pdf
>

I agree with Magnus, that kernel as a bootloader is a good idea to go.

And the kexecboot works awesome on my zaurus, I like that very much
instead of flashing my device with a series of awkward steps.

Looking into shmobile, there are some specially customized _defconfig
to support that. More _defconfig in ARM might not be a good idea, but I
guess we can solve that in a different way though.
> Cheers,
>
> / magnus
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>

ARM Machine SoC I/O setup and PAD initialization code

[Magnus Damm]

On Thu, Jul 22, 2010 at 5:49 PM, Eric Miao <eric.y.miao@gmail.com> wrote:
> On Thu, Jul 22, 2010 at 10:38 AM, Magnus Damm <magnus.damm@gmail.com> wrote:
>> On Thu, Jul 22, 2010 at 4:29 PM, Simon Horman <horms@verge.net.au> wrote:
>>> On Thu, Jul 22, 2010 at 08:20:34AM +0100, Russell King - ARM Linux wrote:
>>>> On Thu, Jul 22, 2010 at 11:32:53AM +0900, Simon Horman wrote:
>>>> > Would it be feasible to ?use Linux + kexec as the boot loader as
>>>> > a long term solution to fixing boot loaders by eliminating them?
>>>>
>>>> So what you're proposing is that a broken boot loader should boot a
>>>> version of Linux to fix the pin MUX, which then kexecs a kernel which
>>>> doesn't have that code?
>>>>
>>>> What's the point of that - when the first kernel will be able to run
>>>> the system?
>>>
>>> Ok, point taken, its impossible to remove the boot loaders.
>>
>> I disagree. We already use upstream Linux as a boot loader on SuperH.
>>
>> For ARM and other architectures check out the ELC2010 presentation by
>> Greg Ungerer here:
>> http://elinux.org/images/7/7b/LinuxWithoutABootLoader.pdf
>>
>> For SH and a more zoomed our perspective have a look at my presentation:
>> http://elinux.org/images/2/2f/ELC-2010-Damm-Kexec.pdf
>>
>
> I agree with Magnus, that kernel as a bootloader is a good idea to go.
>
> And the kexecboot works awesome on my zaurus, I like that very much
> instead of flashing my device with a series of awkward steps.

Good to hear!

> Looking into shmobile, there are some specially customized _defconfig
> to support that. More _defconfig in ARM might not be a good idea, but I
> guess we can solve that in a different way though.

On SuperH (arch/sh), the multiple defconfigs are there to give users a
known working boot loader configuration. They may not be there for
long though.

To build a kernel that can be burned into the reset vector in NOR
flash on SuperH, you simply use the romImage target instead of zImage
or uImage. The romImage target makes sure low level setup code (memory
setup etc) is included in the kernel image.

I recently got MMC boot working on SuperH, so by selecting
CONFIG_ROMIMAGE_MMCIF=y you can now build a romImage that can be dd:ed
into an MMC card and booted straight by the MASK ROM. Nothing ground
breaking - but at least it's available upstream. I'd like to share
parts of that code with ARM SH-Mobile, but I still have not figured
out how to integrate it cleanly on ARM.

Cheers,

/ magnus

ARM Machine SoC I/O setup and PAD initialization code

[Russell King - ARM Linux]

On Thu, Jul 22, 2010 at 10:49:14AM +0200, Eric Miao wrote:
> I agree with Magnus, that kernel as a bootloader is a good idea to go.
> 
> And the kexecboot works awesome on my zaurus, I like that very much
> instead of flashing my device with a series of awkward steps.

Yes, it can be nice (it's been around for over ten years now) - but
what I'm saying is that if you have this stuff in the kernel already,
and the kernel knows what platform you're on...

Well, you know this because PXA is one of the platforms which handles
pin muxing really well.

Let's not get distracted by the issue of eliminating the boot loader -
the original email in this thread was basically asking "why do we have
pin mux code in both boot loaders and the kernel" which has already
been answered several times over.

ARM Machine SoC I/O setup and PAD initialization code

[Russell King - ARM Linux]

On Thu, Jul 22, 2010 at 04:29:48PM +0900, Simon Horman wrote:
> On Thu, Jul 22, 2010 at 08:20:34AM +0100, Russell King - ARM Linux wrote:
> > On Thu, Jul 22, 2010 at 11:32:53AM +0900, Simon Horman wrote:
> > > Would it be feasible to  use Linux + kexec as the boot loader as
> > > a long term solution to fixing boot loaders by eliminating them?
> > 
> > So what you're proposing is that a broken boot loader should boot a
> > version of Linux to fix the pin MUX, which then kexecs a kernel which
> > doesn't have that code?
> > 
> > What's the point of that - when the first kernel will be able to run
> > the system?
> 
> Ok, point taken, its impossible to remove the boot loaders.

No, my point was that if you're going to put pin mux code into the
kernel, there's no point building the pin mux code out of the kernel
which you're going to use to run your device.

So, what we tend to do as a general rule on ARM is to put the pin mux
code into the kernel so that we're less reliant on any boot loader to
get it right.  And as I've already said, we have some cases where we
need to change the pin muxing at runtime, and at least one case where
it needs to be changed by the device driver operating on the pins.

ARM Machine SoC I/O setup and PAD initialization code

[Simon Horman]

On Thu, Jul 22, 2010 at 09:46:49AM +0100, Russell King - ARM Linux wrote:
> On Thu, Jul 22, 2010 at 04:29:48PM +0900, Simon Horman wrote:
> > On Thu, Jul 22, 2010 at 08:20:34AM +0100, Russell King - ARM Linux wrote:
> > > On Thu, Jul 22, 2010 at 11:32:53AM +0900, Simon Horman wrote:
> > > > Would it be feasible to  use Linux + kexec as the boot loader as
> > > > a long term solution to fixing boot loaders by eliminating them?
> > > 
> > > So what you're proposing is that a broken boot loader should boot a
> > > version of Linux to fix the pin MUX, which then kexecs a kernel which
> > > doesn't have that code?
> > > 
> > > What's the point of that - when the first kernel will be able to run
> > > the system?
> > 
> > Ok, point taken, its impossible to remove the boot loaders.

For the record, what I was proposing was removing the broken boot loader
and replacing it with something that isn't broken. And I was wondering
if that is feasible or not. But as you point out (elsewhere) that
may not be relevant to the original question.

> No, my point was that if you're going to put pin mux code into the
> kernel, there's no point building the pin mux code out of the kernel
> which you're going to use to run your device.
> 
> So, what we tend to do as a general rule on ARM is to put the pin mux
> code into the kernel so that we're less reliant on any boot loader to
> get it right.  And as I've already said, we have some cases where we
> need to change the pin muxing at runtime, and at least one case where
> it needs to be changed by the device driver operating on the pins.

Ok, so the boot-loader is irrelevant to the pin mux code in the kernel?

ARM Machine SoC I/O setup and PAD initialization code

[Grant Likely]

On Thu, Jul 22, 2010 at 1:29 AM, Simon Horman <horms@verge.net.au> wrote:
> On Thu, Jul 22, 2010 at 08:20:34AM +0100, Russell King - ARM Linux wrote:
>> On Thu, Jul 22, 2010 at 11:32:53AM +0900, Simon Horman wrote:
>> > Would it be feasible to ?use Linux + kexec as the boot loader as
>> > a long term solution to fixing boot loaders by eliminating them?
>>
>> So what you're proposing is that a broken boot loader should boot a
>> version of Linux to fix the pin MUX, which then kexecs a kernel which
>> doesn't have that code?
>>
>> What's the point of that - when the first kernel will be able to run
>> the system?
>
> Ok, point taken, its impossible to remove the boot loaders.

The engineering and artistry comes in choosing how much to restrict
the responsibilities of the boot firmware.  It needs to be restricted
enough to contain limit the risk & breakage, but not enough to make it
unusable.  Fail when a flaw forces a risky boot firmware upgrade.

g.

ARM Machine SoC I/O setup and PAD initialization code

[Magnus Damm]

On Thu, Jul 22, 2010 at 4:20 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Thu, Jul 22, 2010 at 11:32:53AM +0900, Simon Horman wrote:
>> Would it be feasible to ?use Linux + kexec as the boot loader as
>> a long term solution to fixing boot loaders by eliminating them?
>
> So what you're proposing is that a broken boot loader should boot a
> version of Linux to fix the pin MUX, which then kexecs a kernel which
> doesn't have that code?

I think Simon was proposing to remove the broken boot loader.

> What's the point of that - when the first kernel will be able to run
> the system?

If you boot straight into a Linux kernel (CONFIG_ZBOOT_ROM on ARM ?)
and use that to boot your real system, then at least you only need one
copy of pinmux setup code. If it gets executed once or twice is a
matter of system configuration IMO.

That aside, not trusting the boot loader is probably a good idea. =)

/ magnus

ARM Machine SoC I/O setup and PAD initialization code

[David Jander]

Hi all,

Thanks for all the reactions.

On Thursday 22 July 2010 10:16:17 am Magnus Damm wrote: 
> <linux@arm.linux.org.uk> wrote:
> > On Thu, Jul 22, 2010 at 11:32:53AM +0900, Simon Horman wrote:
> >> Would it be feasible to  use Linux + kexec as the boot loader as
> >> a long term solution to fixing boot loaders by eliminating them?
> >
> > So what you're proposing is that a broken boot loader should boot a
> > version of Linux to fix the pin MUX, which then kexecs a kernel which
> > doesn't have that code?
> 
> I think Simon was proposing to remove the broken boot loader.

IMO, if a bootloader is broken (in any way), it needs replacing. Be it with 
another bootloader or directly with the kernel.
I am working on i.MX51 right now, and that chip has it's own tiny bootloader 
in ROM, which is able to load an image from SPI-NOR, SDHC, NAND, and some 
other places, as well as initialize the DRAM controller with settings 
contained at the beginning of the boot image. In theory it could just as well 
boot a linux kernel directly. There is no real need for RedBoot, u-boot or 
whatever other bootloader. In that case, all hardware setup code needs to be 
done in the boot-code of the kernel.

> > What's the point of that - when the first kernel will be able to run
> > the system?
> 
> If you boot straight into a Linux kernel (CONFIG_ZBOOT_ROM on ARM ?)
> and use that to boot your real system, then at least you only need one
> copy of pinmux setup code. If it gets executed once or twice is a
> matter of system configuration IMO.

That sounds a lot "saner" to me than having two asynchronous and different 
copies of setup-code, which could be a potential nightmare, besides not being 
really maintainable.

> That aside, not trusting the boot loader is probably a good idea. =)

Why? If there's a boot-loader, it should know the correct hardware setup much 
better than any other piece of software.
Its fundamental role _IS_ basic hardware setup!

If bootloaders are broken, and delivered with the hardware, you should either 
complain to the hardware manufacturer or fix the bootloader yourself if 
possible... but not work around it.

Most of the time, if there are minor hardware changes, the linux kernel 
shouldn't be involved if it is not necessary. The BIOS/Bootloader should 
implement the necessary setup changes (if any). That way you don't need 
different kernels for different hardware revisions.

The rationale is simple: The bootloader is bound to and unique to the specific 
board configuration and -revision, whereas the kernel shoudn't change for a 
given platform. Ideally one whould compile one kernel for a generic type of 
i.MX51 machine, and that kernel should just work on all of them, that are 
generic enough. An example of how to accomplish this is Open-Firmware device-
tree support on the PowerPC architecture.

Right now you need different BSPs for all different i.MX51 boards (you can 
compile them all in at once, ok), and potentially also for different revisions 
of the same board.

The discussion sparked unintentionally by this thread is quite interesting, 
and it seems that there are (as always) more than one possible solution 
(kexec, etc). May I suggest Open-Firmrea device-trees and fixed bootloaders as 
another one?

@Russell: I know, I am being optimistic and arrogant here, my excuses if that 
offends you, but I simply can't believe the general state of bootloaders and 
hardware platforms for ARM is so terribly broken, that it can't be fixed in 
"the right way".

As for my own part of responsibility, I am designing a new ARM-based board 
right now (actually working on a prototype already), and I am determined to 
deliver a bootloader that does all hardware setup correctly, and the linux BSP 
I am writing will have no pad-setup code whatsoever. That's a promise!

Best regards,

-- 
David Jander
Protonic Holland.

ARM Machine SoC I/O setup and PAD initialization code

[Russell King - ARM Linux]

On Thu, Jul 22, 2010 at 02:10:09PM +0200, David Jander wrote:
> 
> Hi all,
> 
> Thanks for all the reactions.
> 
> On Thursday 22 July 2010 10:16:17 am Magnus Damm wrote: 
> > <linux@arm.linux.org.uk> wrote:
> > > On Thu, Jul 22, 2010 at 11:32:53AM +0900, Simon Horman wrote:
> > >> Would it be feasible to  use Linux + kexec as the boot loader as
> > >> a long term solution to fixing boot loaders by eliminating them?
> > >
> > > So what you're proposing is that a broken boot loader should boot a
> > > version of Linux to fix the pin MUX, which then kexecs a kernel which
> > > doesn't have that code?
> > 
> > I think Simon was proposing to remove the broken boot loader.
> 
> IMO, if a bootloader is broken (in any way), it needs replacing. Be it with 
> another bootloader or directly with the kernel.

We've just been discussing the boot loader on Versatile Express which
doesn't pass memory information to the kernel.  I'm of the opinion that
this should be fixed.

Unfortunately, there's always a great deal of resistance to fixing boot
loaders, and instead work-arounds get submitted to the kernel (as has
been tried today with Versatile Express).  It almost never happens that
the boot loader(s) get fixed - even if the workaround is refused to be
merged.

> Why? If there's a boot-loader, it should know the correct hardware setup much 
> better than any other piece of software.
> Its fundamental role _IS_ basic hardware setup!

The more you trust the boot loader, the more problems you are going to
have, it's as simple as that.  These things aren't extensively tested.
They're generally not tested past "oh, we got a boot loader prompt.
oh, it can load a kernel.  oh, it can call into the kernel.  ok, job
done, ship it."

That's about as far as boot loader development goes.

This is one reason why I wrote the ARM Linux kernel booting document
some 8 years ago, which specifies the _minimum_ of information that a
boot loader needs to supply the kernel needs to be able to boot.  Fat
lot of good that did - as far as I'm concerned, writing documentation
is a total and utter waste of my time and resources.  It just gets
ignored.

So I now just don't bother with any documentation _at_ _all_.

> @Russell: I know, I am being optimistic and arrogant here, my excuses if that 
> offends you, but I simply can't believe the general state of bootloaders and 
> hardware platforms for ARM is so terribly broken, that it can't be fixed in 
> "the right way".

I've been on at people for _years_ about it.  It doesn't matter who you
moan at, there's very little change.  I've come to the conclusion that
for the vast majority of cases, it's simply impossible to change this
sorry state of affairs.

It's one reason why I'm quietly horrified but the thought of DT on ARM.
Given that vendors are the ones responsible for creating the current
situation with boot loaders, and the same vendors will be responsible
for creating the DTs, I forsee that DT will be a similar pile of crap
as the current boot loaders are - and we will end up either ignoring
the DT information, or we'll end up with lots of work-arounds in the
kernel to fix up broken DT information.

ARM Machine SoC I/O setup and PAD initialization code

[Mark Brown]

On Thu, Jul 22, 2010 at 02:10:09PM +0200, David Jander wrote:

> IMO, if a bootloader is broken (in any way), it needs replacing. Be it with 
> another bootloader or directly with the kernel.

If you don't have JTAG access (either due to device limitations or due
to lack of data from the vendor of a reference platform you're using)
replacing a bootloader can be rather more stressful than it's worth.

> That sounds a lot "saner" to me than having two asynchronous and different 
> copies of setup-code, which could be a potential nightmare, besides not being 
> really maintainable.

Well, from the point of view of using systems like this all you need the
bootloader to do is to set the system up enough to load the kernel and
start it running.  You don't need it to understand anything else about
the rest of the system, which means you're less reliant on the quality
of the bootloader.

ARM Machine SoC I/O setup and PAD initialization code

[David Jander]

On Thursday 22 July 2010 02:56:52 pm Mark Brown wrote:
> On Thu, Jul 22, 2010 at 02:10:09PM +0200, David Jander wrote:
> > IMO, if a bootloader is broken (in any way), it needs replacing. Be it
> > with another bootloader or directly with the kernel.
> 
> If you don't have JTAG access (either due to device limitations or due
> to lack of data from the vendor of a reference platform you're using)
> replacing a bootloader can be rather more stressful than it's worth.

I agree, but I simply can't believe ARM platform designers all do such a bad 
job at firmware (=bootloader) development in general, which is in sharp 
contrast to what I have learned from previous PowerPC developments.

Maybe the difference is in the market: PowerPC is more geared towards an 
industrial embedded market (high demand of robustness and reliability), while 
ARM comes from a pure consumer market, and is just lately making inroads into 
industrial applications.

> > That sounds a lot "saner" to me than having two asynchronous and
> > different copies of setup-code, which could be a potential nightmare,
> > besides not being really maintainable.
> 
> Well, from the point of view of using systems like this all you need the
> bootloader to do is to set the system up enough to load the kernel and
> start it running.  You don't need it to understand anything else about
> the rest of the system, which means you're less reliant on the quality
> of the bootloader.

How can you assume that kernel-developers know how to correcly set-up the slew 
rate and drive-strength of an I/O-pin for a given platform if the manufacturer 
itself didn't do it nor document it!??
Even if it works with one guessed setting, there is a potential EMC impact 
that needs to be taken care of.

There are important hardware-design decisions after each of those settings! If 
we continue this amateuristic approach, ARM-linux platforms will never get 
taken seriously in more demanding environments. This really needs to change.

Best regards,

-- 
David Jander
Protonic Holland.

ARM Machine SoC I/O setup and PAD initialization code

[Russell King - ARM Linux]

On Thu, Jul 22, 2010 at 03:31:58PM +0200, David Jander wrote:
> On Thursday 22 July 2010 02:56:52 pm Mark Brown wrote:
> > Well, from the point of view of using systems like this all you need the
> > bootloader to do is to set the system up enough to load the kernel and
> > start it running.  You don't need it to understand anything else about
> > the rest of the system, which means you're less reliant on the quality
> > of the bootloader.
> 
> How can you assume that kernel-developers know how to correcly set-up the
> slew rate and drive-strength of an I/O-pin for a given platform if the
> manufacturer itself didn't do it nor document it!??
> Even if it works with one guessed setting, there is a potential EMC impact 
> that needs to be taken care of.

You're making some assumptions there - you're assuming that the people
doing the kernel aren't connected with the vendor.

This is rarely the case - as the vendor wants their end product to work.
If they take a random boot loader, and a random kernel, and hopes that
the final combination falls within EMC limits, then they're failing in
their duty.

They need to test that their final product meets the EMC regulations
before marketing it, and if it doesn't then they need to rework it in
some way to make it meet the regulations - be that by hardware redesign,
or getting the software configuration correct.

But sadly, "getting the software configuration correct" normally means
modifying the kernel rather than fixing the boot loader - because it's
easier and less risky to put fix the (vendor) kernels than it is to
touch the boot loader.

> There are important hardware-design decisions after each of those
> settings! If we continue this amateuristic approach, ARM-linux
> platforms will never get taken seriously in more demanding
> environments. This really needs to change.

"we continue this amateuristic approach" - you think we really have some
choice in this?  We have very little influence on this point.

If boot loaders were coded in such a way that it was very difficult to
get stuff wrong, then there'd be less of an issue.  By that I mean basic
stuff such as taking the results of the RAM detection function(s) (which
are platform specific, and presumably the boot loader does know how much
RAM it has to deal with for its own internal malloc etc) and ensuring
this gets passed to the kernel boot handler in an arch specific way.

I'm sure that uboot knows how much memory is present already.  It's
just that for whatever reason, the code which sets up the tagged list
isn't implemented in such a way that it always gets passed to the
kernel independently of board specifics.

ARM Machine SoC I/O setup and PAD initialization code

[David Jander]

On Thursday 22 July 2010 03:54:31 pm Russell King - ARM Linux wrote:
> > There are important hardware-design decisions after each of those
> > settings! If we continue this amateuristic approach, ARM-linux
> > platforms will never get taken seriously in more demanding
> > environments. This really needs to change.
> 
> "we continue this amateuristic approach" - you think we really have some
> choice in this?  We have very little influence on this point.

You do. I work for a hardware manufacturer and we are listening!

Also, Canonical might have some important weight here (Linaro).... and they 
may just as well listen also.

Best regards,

-- 
David Jander

ARM Machine SoC I/O setup and PAD initialization code

[Russell King - ARM Linux]

On Fri, Jul 23, 2010 at 12:35:40PM +0200, David Jander wrote:
> On Thursday 22 July 2010 03:54:31 pm Russell King - ARM Linux wrote:
> > > There are important hardware-design decisions after each of those
> > > settings! If we continue this amateuristic approach, ARM-linux
> > > platforms will never get taken seriously in more demanding
> > > environments. This really needs to change.
> > 
> > "we continue this amateuristic approach" - you think we really have some
> > choice in this?  We have very little influence on this point.
> 
> You do. I work for a hardware manufacturer and we are listening!

Well, do _something_ about it then rather than endlessly discussing it.
Make sure that your boot loader is correct for all your platforms, and
then we can rely on it to be right for your platforms and omit the
setup on them.

But you won't be able to influence all hardware manufacturers.

> Also, Canonical might have some important weight here (Linaro).... and they 
> may just as well listen also.

I doubt Linaro can change the way hardware manufacturers behave either.

ARM Ltd have been going around trying to teach silicon vendors about
feeding their changes back to the kernel, and it's taken them about a
decade for this stuff to happen.

How long do you think it'll take for board-level manufacturers to get
the big picture?  I wouldn't be surprised if it takes at least another
decade.

As you seem to have a problem with the current setup, then please pick
up the campaign banner and start trying to teach the hardware vendors
about the Right Way(tm) to do things - which means addressing your
concerns _to_ the people who create them, not the people who end up
having to live with the resulting mess.

ARM Machine SoC I/O setup and PAD initialization code

[Mark Brown]

On Thu, Jul 22, 2010 at 03:31:58PM +0200, David Jander wrote:
> On Thursday 22 July 2010 02:56:52 pm Mark Brown wrote:

> > If you don't have JTAG access (either due to device limitations or due
> > to lack of data from the vendor of a reference platform you're using)
> > replacing a bootloader can be rather more stressful than it's worth.
> 
> I agree, but I simply can't believe ARM platform designers all do such a bad 
> job at firmware (=bootloader) development in general, which is in sharp 
> contrast to what I have learned from previous PowerPC developments.

> Maybe the difference is in the market: PowerPC is more geared towards an 
> industrial embedded market (high demand of robustness and reliability), while 
> ARM comes from a pure consumer market, and is just lately making inroads into 
> industrial applications.

I suspect it's more that there are vastly fewer PowerPC vendors out
there so much less independant development - compared to ARM the PowerPC
devices are *very* homogenous.

> > Well, from the point of view of using systems like this all you need the
> > bootloader to do is to set the system up enough to load the kernel and
> > start it running.  You don't need it to understand anything else about
> > the rest of the system, which means you're less reliant on the quality
> > of the bootloader.

> How can you assume that kernel-developers know how to correcly set-up the slew 
> rate and drive-strength of an I/O-pin for a given platform if the manufacturer 
> itself didn't do it nor document it!??

Usually the people doing the kernel bringup on an actual end system will
be part of the same organisation that does the hardware design - if
there's a problem the kernel developer can usually locate the orginal
hardware designer.

> Even if it works with one guessed setting, there is a potential EMC impact 
> that needs to be taken care of.

As I said, even if the bootloader *can* be updated at least some users
are likely to refuse point blank to do so if they don't have a recovery
mechanism that they trust and prefer to fix the code up in a part of the
system they can recover easily if it fails.  The determination of these
paramters may come after the original bootloader is written (since they
may depend in part on measurement, for example).  Another issue can be
that in development simultaneously deploying bootloader and kernel
updates can be more difficult than deploying a single image so people
prefer to keep everything in one place.

The reliability concerns also apply to updates done in the field (eg,
when rolling out new functionality) - anything that may require fallback
to JTAG is fail.

> There are important hardware-design decisions after each of those settings! If 
> we continue this amateuristic approach, ARM-linux platforms will never get 
> taken seriously in more demanding environments. This really needs to change.

I'm not sure what you believe is amateurish about this approach?
Clearly if you think that the kernel should have no involvement in
configuring the system then there's a problem but that's not a given.

For various reasons ARM systems have pretty much ended up in a position
like PCs where the bootloader is responsible for starting the kernel and
not much else.

ARM Machine SoC I/O setup and PAD initialization code

[David Jander]

On Thursday 22 July 2010 04:20:43 pm Mark Brown wrote:
> On Thu, Jul 22, 2010 at 03:31:58PM +0200, David Jander wrote:
> > On Thursday 22 July 2010 02:56:52 pm Mark Brown wrote:
> > > If you don't have JTAG access (either due to device limitations or due
> > > to lack of data from the vendor of a reference platform you're using)
> > > replacing a bootloader can be rather more stressful than it's worth.
> >
> > I agree, but I simply can't believe ARM platform designers all do such a
> > bad job at firmware (=bootloader) development in general, which is in
> > sharp contrast to what I have learned from previous PowerPC developments.
> >
> > Maybe the difference is in the market: PowerPC is more geared towards an
> > industrial embedded market (high demand of robustness and reliability),
> > while ARM comes from a pure consumer market, and is just lately making
> > inroads into industrial applications.
> 
> I suspect it's more that there are vastly fewer PowerPC vendors out
> there so much less independant development - compared to ARM the PowerPC
> devices are *very* homogenous.

That could indeed be part of the reason... but there are not _so_ few PowerPC 
vendors actually: Chips are made by Freescale, AMCC and IBM mainly (PASemi 
used to exist also), but boards and workstations are made by quite a lot of 
vendors (we are one ;-)

> > > Well, from the point of view of using systems like this all you need
> > > the bootloader to do is to set the system up enough to load the kernel
> > > and start it running.  You don't need it to understand anything else
> > > about the rest of the system, which means you're less reliant on the
> > > quality of the bootloader.
> >
> > How can you assume that kernel-developers know how to correcly set-up the
> > slew rate and drive-strength of an I/O-pin for a given platform if the
> > manufacturer itself didn't do it nor document it!??
> 
> Usually the people doing the kernel bringup on an actual end system will
> be part of the same organisation that does the hardware design - if
> there's a problem the kernel developer can usually locate the orginal
> hardware designer.

Then why can't they get the boot-loader fixed?
We develop and manufacture hardware and also do bootloader and kernel porting 
in one company.
First comes the board design, including design validation criteria and a lot 
of that information is used later during bootloader development. Then comes 
manufacturing of prototypes and work on porting u-boot. One of the design 
goals that also apply to u-boot is always standarization wherever that is 
practical. Until now we have mostly only worked on PowerPC platforms, and 
there things are fairly easy: Make u-boot initialize the hardware completely, 
write a DTS (Device-tree source file) for the chosen linux kernel, add 2 or 3 
lines of code into a generic BSP file for your SoC, configure and compile the 
kernel and everything just works.
Well, of course it always is some sort of iterative process before the DTS is 
100% correct, but it is faily simple. You can rely on all SoC drivers to be 
generic and independent of your specific board and that, provided the correct 
DT, drivers and hardware will find each other and work. I/O setup is the sole 
duty of u-boot.

There is a small chance that u-boot may need to get changed later on, but that 
chance always exists, even if I/O setup was done in the kernel. U-boot can 
easily be replaced by a running linux system, the only thing that has to be 
taken care of is not touching power while flashing, as well as verifying the 
flashed image before reboot. The boot-loader itself is supposed to be factory 
tested and shouldn't brick your device. Also, you usually don't need to change 
the boot-loader that often.
PC-manufacturers also ship BIOS upgrades every now and then.

> > Even if it works with one guessed setting, there is a potential EMC
> > impact that needs to be taken care of.
> 
> As I said, even if the bootloader *can* be updated at least some users
> are likely to refuse point blank to do so if they don't have a recovery
> mechanism that they trust and prefer to fix the code up in a part of the
> system they can recover easily if it fails.  The determination of these
> paramters may come after the original bootloader is written (since they
> may depend in part on measurement, for example).

Measurement for design-characterization is done on prototypes, not on 
production devices.
If you do your homework in the bootloader during the product prototype phase, 
chances that you ever need to change I/O-setup later are very small, so this 
doesn't seem a valid argument to me.

> Another issue can be
> that in development simultaneously deploying bootloader and kernel
> updates can be more difficult than deploying a single image so people
> prefer to keep everything in one place.

"In development" is when the product isn't finished yet, so what is the big 
deal of updating the bootloader then?
I would prefer a good architecture over a patched workaround any day.

> The reliability concerns also apply to updates done in the field (eg,
> when rolling out new functionality) - anything that may require fallback
> to JTAG is fail.

New functionality that hasn't been thought of during development would need 
different hardware anyway, and if that functional upgrade has been thought of 
during initial design, that thought should have included the boot-loader IMHO.

> > There are important hardware-design decisions after each of those
> > settings! If we continue this amateuristic approach, ARM-linux platforms
> > will never get taken seriously in more demanding environments. This
> > really needs to change.
> 
> I'm not sure what you believe is amateurish about this approach?

Clarification: Amateuristish was meant as much or even more for 
hardware/bootloader development as for the kernel part. Don't just feel 
offended, but you can't tell me that delivering hardware with a half-baked 
bootloader to a kernel developer and letting him hack/guess the I/O 
initialization together that the boot-loader got wrong doesn't sound very 
professional to me.

> Clearly if you think that the kernel should have no involvement in
> configuring the system then there's a problem but that's not a given.

Well, let's try to make it a given. I think we mostly agree that it would be 
better tha way.
On PC platforms it is that way also: There is the BIOS that needs to do all 
low-level setup stuff. It is never done in the linux kernel nor in the NT-
kernel.

> For various reasons ARM systems have pretty much ended up in a position
> like PCs where the bootloader is responsible for starting the kernel and
> not much else.

You forget the BIOS! ;-)
PC's have a BIOS that does HW init stuff, _that's_ why the bootloader doesn't 
have to do it there.
The problem is that on ARM the bootloader also has the task of the BIOS 
because there isn't any.

Best regards,

-- 
David Jander
Protonic Holland.

ARM Machine SoC I/O setup and PAD initialization code

[Russell King - ARM Linux]

On Fri, Jul 23, 2010 at 12:18:07PM +0200, David Jander wrote:
> Then why can't they get the boot-loader fixed?

You're asking the WRONG people.

> Clarification: Amateuristish was meant as much or even more for 
> hardware/bootloader development as for the kernel part. Don't just feel 
> offended, but you can't tell me that delivering hardware with a half-baked 
> bootloader to a kernel developer and letting him hack/guess the I/O 
> initialization together that the boot-loader got wrong doesn't sound very 
> professional to me.

To make the same point yet again: I would like a working boot loader
for one of my boards, so that I can use it productively.  Despite
asking for one, I've still to receive such a thing.

So, you can call one of the largest silicon manufacturers on the planet
"amateurish" if you wish... that's not going to make them change.

Now, there's little point continuing to discuss this - we've made the
situation plainly clear to you, and also pointed out that it's out of
our control.  So what's the point in continuing to tell us that we're
doing it all wrong?

Please, talk to the people who do boot loaders about your issues with
their code, rather than the people who have to live with the crap produced
by those people.

ARM Machine SoC I/O setup and PAD initialization code

[Mark Brown]

On Fri, Jul 23, 2010 at 12:18:07PM +0200, David Jander wrote:
> On Thursday 22 July 2010 04:20:43 pm Mark Brown wrote:

> > I suspect it's more that there are vastly fewer PowerPC vendors out
> > there so much less independant development - compared to ARM the PowerPC
> > devices are *very* homogenous.

> That could indeed be part of the reason... but there are not _so_ few PowerPC 
> vendors actually: Chips are made by Freescale, AMCC and IBM mainly (PASemi 
> used to exist also), but boards and workstations are made by quite a lot of 
> vendors (we are one ;-)

This is a vanishingly small number of chip vendors (and hence original
BSPs, which are the main issue here) in comparison with the ARM market.

> > Usually the people doing the kernel bringup on an actual end system will
> > be part of the same organisation that does the hardware design - if
> > there's a problem the kernel developer can usually locate the orginal
> > hardware designer.

> Then why can't they get the boot-loader fixed?

In extreme cases the bootloader may be provided as binary by the SoC
vendor and not changable, but there can also be the other concerns I
mentioned with things like deploying updates throughout the team.
Sometimes the bootloader code supplied with the BSP is entertainingly
baroque and discourages changes even if they are technically possible.

Also remember that many of the people doing upstream work are doing it
on various generic reference platforms rather than boards they
themselves have manufactured and may therefore have problems getting the
access that you get with commercial devices.

> Well, of course it always is some sort of iterative process before the DTS is 
> 100% correct, but it is faily simple. You can rely on all SoC drivers to be 
> generic and independent of your specific board and that, provided the correct 
> DT, drivers and hardware will find each other and work. I/O setup is the sole 
> duty of u-boot.

In process terms this is generally true of ARM also, it's just that
everything tends to be included in the kernel.

> There is a small chance that u-boot may need to get changed later on, but that 
> chance always exists, even if I/O setup was done in the kernel. U-boot can 
> easily be replaced by a running linux system, the only thing that has to be 
> taken care of is not touching power while flashing, as well as verifying the 
> flashed image before reboot. The boot-loader itself is supposed to be factory 
> tested and shouldn't brick your device. Also, you usually don't need to change 
> the boot-loader that often.

Technically being able to replace the bootloader and being willing to
take the risk of bricking the system are not the same thing. 

> > As I said, even if the bootloader *can* be updated at least some users
> > are likely to refuse point blank to do so if they don't have a recovery
> > mechanism that they trust and prefer to fix the code up in a part of the
> > system they can recover easily if it fails.  The determination of these
> > paramters may come after the original bootloader is written (since they
> > may depend in part on measurement, for example).

> Measurement for design-characterization is done on prototypes, not on 
> production devices.
> If you do your homework in the bootloader during the product prototype phase, 
> chances that you ever need to change I/O-setup later are very small, so this 
> doesn't seem a valid argument to me.

You need to at lest reverify all this stuff in form factor, and
obviously if you're using a reference board from a manufacturer rather
than an actual system the concept of production is somewhat vauge.

> > Another issue can be
> > that in development simultaneously deploying bootloader and kernel
> > updates can be more difficult than deploying a single image so people
> > prefer to keep everything in one place.

> "In development" is when the product isn't finished yet, so what is the big 
> deal of updating the bootloader then?
> I would prefer a good architecture over a patched workaround any day.

You need a mechanism to ensure all the engineers are applying bootloader
updates to their systems when required.  It's not insurmountable, but
it's one more thing that needs doing.

> > The reliability concerns also apply to updates done in the field (eg,
> > when rolling out new functionality) - anything that may require fallback
> > to JTAG is fail.

> New functionality that hasn't been thought of during development would need 
> different hardware anyway, and if that functional upgrade has been thought of 
> during initial design, that thought should have included the boot-loader IMHO.

Not at all, people do ship systems with hardware physically present but
no software support and then add software support later especially with
reference designs.

> Clarification: Amateuristish was meant as much or even more for 
> hardware/bootloader development as for the kernel part. Don't just feel 
> offended, but you can't tell me that delivering hardware with a half-baked 
> bootloader to a kernel developer and letting him hack/guess the I/O 
> initialization together that the boot-loader got wrong doesn't sound very 
> professional to me.

This is only a problem if you assume the bootloader is responsible for
doing the pin setup - clearly if it was supposed to do that and it
didn't there's an issue.  If instead you merely expect the bootloader to
load and start the kernel then so long as the kernel is running the
bootloader did what it was supposed to do.

> > Clearly if you think that the kernel should have no involvement in
> > configuring the system then there's a problem but that's not a given.

> Well, let's try to make it a given. I think we mostly agree that it would be 
> better tha way.

I don't actually see a problem with the current situation.

As others have said you're welcome to try, but it's not the most
tractable problem ever and it's not immediately obvious that it's the
best use of time.  Given the concerns that exist about bootloader
quality it's not clear that there's much enthusiasm for increasing the
level of reliance on the bootloader.

> On PC platforms it is that way also: There is the BIOS that needs to do all 
> low-level setup stuff. It is never done in the linux kernel nor in the NT-
> kernel.

This isn't entirely true, the BIOS is handing off a partially
initialised system and init is completed by the kernel.

ARM Machine SoC I/O setup and PAD initialization code

[david at protonic.nl]

> On Fri, Jul 23, 2010 at 12:18:07PM +0200, David Jander wrote:
>> That could indeed be part of the reason... but there are not _so_ few
>> PowerPC
>> vendors actually: Chips are made by Freescale, AMCC and IBM mainly
>> (PASemi
>> used to exist also), but boards and workstations are made by quite a lot
>> of
>> vendors (we are one ;-)
>
> This is a vanishingly small number of chip vendors (and hence original
> BSPs, which are the main issue here) in comparison with the ARM market.

Ok I agree.

>> > Usually the people doing the kernel bringup on an actual end system
>> will
>> > be part of the same organisation that does the hardware design - if
>> > there's a problem the kernel developer can usually locate the orginal
>> > hardware designer.
>
>> Then why can't they get the boot-loader fixed?
>
> In extreme cases the bootloader may be provided as binary by the SoC
> vendor and not changable, but there can also be the other concerns I
> mentioned with things like deploying updates throughout the team.
> Sometimes the bootloader code supplied with the BSP is entertainingly
> baroque and discourages changes even if they are technically possible.

Well, I know one manufacturer delivering such a bootloader with their
evaluation kit, but I'd never expect anyone to actually use that one in
production!? Isn't it meant as a mere example?

> Also remember that many of the people doing upstream work are doing it
> on various generic reference platforms rather than boards they
> themselves have manufactured and may therefore have problems getting the
> access that you get with commercial devices.

Wait a second... how can you do development of BSP stuff for a product on
an essentially different evaluation platform?
I am starting to finally understand why things are as they are now. My
excuses if it upset someone in the way.... :-(

>> Well, of course it always is some sort of iterative process before the
>> DTS is
>> 100% correct, but it is faily simple. You can rely on all SoC drivers to
>> be
>> generic and independent of your specific board and that, provided the
>> correct
>> DT, drivers and hardware will find each other and work. I/O setup is the
>> sole
>> duty of u-boot.
>
> In process terms this is generally true of ARM also, it's just that
> everything tends to be included in the kernel.

Well, if you want to include _everything_ in the kernel, that's fine, but
then don't use a bootloader, and set the rules accordingly. My primary
concern is about there not being a single place for this. It's in the BL
and in the kernel, and sometimes things are setup differently in both
places!

>> There is a small chance that u-boot may need to get changed later on,
>> but that
>> chance always exists, even if I/O setup was done in the kernel. U-boot
>> can
>> easily be replaced by a running linux system, the only thing that has to
>> be
>> taken care of is not touching power while flashing, as well as verifying
>> the
>> flashed image before reboot. The boot-loader itself is supposed to be
>> factory
>> tested and shouldn't brick your device. Also, you usually don't need to
>> change
>> the boot-loader that often.
>
> Technically being able to replace the bootloader and being willing to
> take the risk of bricking the system are not the same thing.

If a PC does not work correctly (especially with a new feature or OS),
manufacturers publish BIOS upgrades. People accept them as long as it's
not too often. Heck, even game-console manufacturers sometimes remotely
upgrade their bootloaders, and users don't even have the option to say no.
And yes, I mean the actual bootloader, not just the firmware of the
console.

>[...]
>> Measurement for design-characterization is done on prototypes, not on
>> production devices.
>> If you do your homework in the bootloader during the product prototype
>> phase,
>> chances that you ever need to change I/O-setup later are very small, so
>> this
>> doesn't seem a valid argument to me.
>
> You need to at lest reverify all this stuff in form factor, and
> obviously if you're using a reference board from a manufacturer rather
> than an actual system the concept of production is somewhat vauge.

Ok. I never expected so many developers actually developing on evaluation
platforms instead of real prototypes. At least not BSP stuff.

>> > Another issue can be
>> > that in development simultaneously deploying bootloader and kernel
>> > updates can be more difficult than deploying a single image so people
>> > prefer to keep everything in one place.
>
>> "In development" is when the product isn't finished yet, so what is the
>> big
>> deal of updating the bootloader then?
>> I would prefer a good architecture over a patched workaround any day.
>
> You need a mechanism to ensure all the engineers are applying bootloader
> updates to their systems when required.  It's not insurmountable, but
> it's one more thing that needs doing.

Sorry, I am still baffled at how that can be a problem... I mean they are
engineers, developing a product together, right? I'll take your word, but
I am surprised.

>> > The reliability concerns also apply to updates done in the field (eg,
>> > when rolling out new functionality) - anything that may require
>> fallback
>> > to JTAG is fail.
>
>> New functionality that hasn't been thought of during development would
>> need
>> different hardware anyway, and if that functional upgrade has been
>> thought of
>> during initial design, that thought should have included the boot-loader
>> IMHO.
>
> Not at all, people do ship systems with hardware physically present but
> no software support and then add software support later especially with
> reference designs.

Well, I was referring to actual products, not reference designs. When we
develop a product, we use the datasheet and reference manuals for the
design, and the reference design schematics to get a better idea of what
the chip maker intended or omitted from the datasheet. Then we make a
prototype of our design, which is 95% identical to the actually shipped
product most of the time, and then we write a bootloader for it (mostly
just porting u-boot), after that we develop a linux BSP, if possible from
a git-tree as close to mainline as possible for that chip. And just after
that do application developers get a chance to try out the software on our
board.
I naively thought most manufacturers did something similar. I understand
now that I was wrong. Sorry. But it does hurt!

>> Clarification: Amateuristish was meant as much or even more for
>> hardware/bootloader development as for the kernel part. Don't just feel
>> offended, but you can't tell me that delivering hardware with a
>> half-baked
>> bootloader to a kernel developer and letting him hack/guess the I/O
>> initialization together that the boot-loader got wrong doesn't sound
>> very
>> professional to me.
>
> This is only a problem if you assume the bootloader is responsible for
> doing the pin setup - clearly if it was supposed to do that and it
> didn't there's an issue.

It seems the most logical place to do it. Has the linux kernel (on x86)
ever cared about DRAM timings, or PCI slew-rate settings, delay trimming,
etc...? I think not. And hopefully it shouldn't. But if it needs to (for
ARM), then let's find a sane way of specifying the settings, hopefully in
a way that is not related to re-useable code (drivers and such stuff). See
the example given in my original post.

> If instead you merely expect the bootloader to
> load and start the kernel then so long as the kernel is running the
> bootloader did what it was supposed to do.

In the light of that, linux bootling linux seems a smart thing to do.
Makes me think of RedBoot, which is the HAL from eCos (which once was
Linux, remember) and a bootloader on top of that.

>[...]
>> On PC platforms it is that way also: There is the BIOS that needs to do
>> all
>> low-level setup stuff. It is never done in the linux kernel nor in the
>> NT-
>> kernel.
>
> This isn't entirely true, the BIOS is handing off a partially
> initialised system and init is completed by the kernel.

Device/driver initialization, but never low-level stuff like DRAM timing
or PCI delay calibration, drive strength an slew-rates. And at least
things are standardized to a safe degree and agreed upon (or pushed down
the developers throat, however you may want to call it).

This has been an interesting discussion, but I don't want to upset any
more people here. I just want to ask one more question, being new to
ARM-linux: What setup should I chose for our products then? What would be
more in tune with the most desireable long-term goal of ARM-linux booting?

1. u-boot doing all pad/IO setup and loading linux.
2. u-boot just loading linux and doing only the minimum IO-setup necessary
for that job, and write a linux BSP that does ALL IO-init
3. Don't use u-boot at all, and investigate Magnus's Kexec technique?
4. Something else?

On PowerPC, anyone would probably have said 1. eyes closed. Now I am not
so sure anymore... please help.
Thanks to everyone for answering so far.

Best regards,

-- 
David Jander.

ARM Machine SoC I/O setup and PAD initialization code

[Jason McMullan]

On Fri, Jul 23, 2010 at 2:38 PM, <david@protonic.nl> wrote:
>
> This has been an interesting discussion, but I don't want to upset any
> more people here. I just want to ask one more question, being new to
> ARM-linux: What setup should I chose for our products then? What would be
> more in tune with the most desireable long-term goal of ARM-linux booting?
>
> 1. u-boot doing all pad/IO setup and loading linux.
> 2. u-boot just loading linux and doing only the minimum IO-setup necessary
> for that job, and write a linux BSP that does ALL IO-init
> 3. Don't use u-boot at all, and investigate Magnus's Kexec technique?
> 4. Something else?
>
>
Option (1) is the best bet for a *production* device (your scenario).

For me (as a SoC company BSP engineer, trying to make a zillion
disparate customers all happy) I use option (4):

  a) A minimial (<16k) boot block, that reads a config out of flash, and
runs...
  b) A small DDR (and other devices) init routine (<32k) out of flash, and
then...
  c) Linux

(a) Doesn't set up *anything* other than the serial UART. It is primarily
    for reading the config, and performing the load order from flash as
    requested by the config.
(b) Contains all the 'real' chip/pad/board initialization, that would be
    per-production board specific.
(c) Doesn't need to set up pads/pins, assumes (b) took care of it.

So, this is kinda like option (1), except that we use our own minimal loader
and board setup instead of U-Boot.  The source code for (a) and (b) are
provided
as examples to our customers.

-- 
Jason S. McMullan
Netronome Systems, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20100723/d8f81dc7/attachment-0001.html>

ARM Machine SoC I/O setup and PAD initialization code

[Robert Schwebel]

David,

On Fri, Jul 23, 2010 at 08:38:50PM +0200, david at protonic.nl wrote:
> > Sometimes the bootloader code supplied with the BSP is
> > entertainingly baroque and discourages changes even if they are
> > technically possible.
>
> Well, I know one manufacturer delivering such a bootloader with their
> evaluation kit, but I'd never expect anyone to actually use that one
> in production!? Isn't it meant as a mere example?

That's theory. In practise, board vendors often just take what they got
from the chip vendor, hack around until it *somehow* boots and ship it.
Having worked on the Phytec cpu modules for the last years, we've even
seen that the vendors of the custom base boards reuse the machine number
of the eval kits, don't care about the error messages from the kernel
and ship.

And even if you try to make the bootloader high quality: ARM chip
manufacturers tend to keep lots of important errata secret. The i.MX
NAND controller has a bug which lets you interpret the wrong bits as the
factory bad block info - it took years until someone noticed, because it
just works (but with the wrong blocks marked as bad). This sort of bugs
often need bootloader fixes - but what do you do if you have some 100k
devices already shipped?

I second Russell's theroy: bootloaders cannot be trusted. That's why we
follow the pattern to init everything in Linux that's possible.

> Well, if you want to include _everything_ in the kernel, that's fine,
> but then don't use a bootloader, and set the rules accordingly.

People have done that. The downside is: The bootloader quite often is a
powerful debug tool during development. You can do things while Linux
and complexity stays out of the way. You can network boot quickly and
look into registers.

That's the reason why in the Barebox bootloader, we follow the paradigm
of supporting only what's necessary in the bootloader, and even for
that, we have Kbuild and can switch functionality on (during
development) and off (during production). If things have a reason for
being in the bootloader, they have a well defined place. We even have
modules, which makes it possible to fix issues in binary bootloaders
which have already been deployed into the field.

> > You need a mechanism to ensure all the engineers are applying
> > bootloader updates to their systems when required. It's not
> > insurmountable, but it's one more thing that needs doing.
>
> Sorry, I am still baffled at how that can be a problem... I mean they
> are engineers, developing a product together, right? I'll take your
> word, but I am surprised.

Please don't expect that large scale enterprise companies have the same
level of pragmatic professionalism which is standard in this community.

Quite often the people in the teams don't even know how to build their
components, because some people at the end of the world are responsible
for generating packets out of code, on a time scale of several weeks.
It's quite common to manage several thousands of requirements in highly
expensive Requirements Engineering tools, but not even the core
developers are able to build the same code out of some SCM repository.

> In the light of that, linux bootling linux seems a smart thing to do.
> Makes me think of RedBoot, which is the HAL from eCos (which once was
> Linux, remember) and a bootloader on top of that.

That's theory. RedBoot is so ... 90ies that it actually hurts. If you
want something that feels familiar for a Linux developer, use Barebox.

kexec is a good idea only in theory. Last time we tried it, it needed
something like 6 s additional boot time. Inacceptable - we bring Qt
based GUI systems into the application in 6 s, and automotive systems
into userspace in 336 ms. Not to mention that the first kernel needs to
be brought up as well.

rsc
-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

ARM Machine SoC I/O setup and PAD initialization code

[Magnus Damm]

On Sat, Jul 24, 2010 at 6:03 AM, Robert Schwebel
<r.schwebel@pengutronix.de> wrote:
> kexec is a good idea only in theory. Last time we tried it, it needed
> something like 6 s additional boot time. Inacceptable - we bring Qt
> based GUI systems into the application in 6 s, and automotive systems
> into userspace in 336 ms. Not to mention that the first kernel needs to
> be brought up as well.

I disagree with your "in theory only" stamp on kexec. I've used kexec
for rebooting and crash dumping on i386, x86_64, ia64, ARM and SH. 10
years ago before kexec I booted Linux from Linux on Powerpc using the
"relf" kernel module. I know that closed-source RTOS has booted
themselves for ages, look at vxWorks and/or pSOS if you happen to be
interested in history.

The two presentations pointed out earlier in this thread clearly show
how to build kexec based boot loaders which boot in one second. The
overhead of kexec itself is almost nothing. I'm sure you can discuss
the details of the kexec implementation with Eric Biederman if you'd
like.

That aside, the 6 s number looks familiar from earlier Barebox
presentations that I've eyed through before. When did you test it? Do
you remember what platform and which kernel version? Are you using a
full Gnome desktop in your boot loader? =)

I'm sure there still are valid reasons why people chose to duplicate
driver development though traditional boot loaders like Barebox or
U-boot. One valid reason may be size of the boot loader, another may
be speed.

The 6 s difference you point out is just strange IMO. I'm not sure
what you are booting with your boot loader. Is it a Linux kernel? If
so, are you trying to say that kexec itself is slow or that the kernel
is slow?

ARM Machine SoC I/O setup and PAD initialization code

[Robert Schwebel]

On Mon, Jul 26, 2010 at 10:37:20AM +0900, Magnus Damm wrote:
> On Sat, Jul 24, 2010 at 6:03 AM, Robert Schwebel
> <r.schwebel@pengutronix.de> wrote:
> > kexec is a good idea only in theory. Last time we tried it, it
> > needed something like 6 s additional boot time. Inacceptable - we
> > bring Qt based GUI systems into the application in 6 s, and
> > automotive systems into userspace in 336 ms. Not to mention that the
> > first kernel needs to be brought up as well.
>
> I disagree with your "in theory only" stamp on kexec. I've used kexec
> for rebooting and crash dumping on i386, x86_64, ia64, ARM and SH.

That's a good usecase, I agree.

> The two presentations pointed out earlier in this thread clearly show
> how to build kexec based boot loaders which boot in one second. The
> overhead of kexec itself is almost nothing. I'm sure you can discuss
> the details of the kexec implementation with Eric Biederman if you'd
> like.

We'll re-do the tests, in order to measure some hard facts. It may turn
out that we have learned more things since we made the last numbers :)

> That aside, the 6 s number looks familiar from earlier Barebox
> presentations that I've eyed through before. When did you test it? Do
> you remember what platform and which kernel version? Are you using a
> full Gnome desktop in your boot loader? =)

On MX35 we boot a naked kernel into a custom /sbin/init application in
336 ms with barebox, starting the measurement at the first assembler
instruction which can be influenced in software.

I think it's a question of what you want to have. The 6 s boot is with:

- Barebox from NAND
- booting the kernel from NAND
- kernel config with everything built in which is needed in the system
- init based userspace
- dbus + some related services
- Qt
- system based on ipkg packages

and it is measured up to the point where the qt application is fully
operational.

> From my point of view it always makes sense to optimize the kernel
> boot up time. This because it will improve the start up time of your
> final kernel _and_ your boot loader as well if you use kexec.

Seconded. What can be done in the kernel should be done in the kernel.

rsc
-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

ARM Machine SoC I/O setup and PAD initialization code

[Mark Brown]

On Fri, Jul 23, 2010 at 08:38:50PM +0200, david at protonic.nl wrote:
> > On Fri, Jul 23, 2010 at 12:18:07PM +0200, David Jander wrote:

> > In extreme cases the bootloader may be provided as binary by the SoC
> > vendor and not changable, but there can also be the other concerns I
> > mentioned with things like deploying updates throughout the team.
> > Sometimes the bootloader code supplied with the BSP is entertainingly
> > baroque and discourages changes even if they are technically possible.

> Well, I know one manufacturer delivering such a bootloader with their
> evaluation kit, but I'd never expect anyone to actually use that one in
> production!? Isn't it meant as a mere example?

Well, if it already does the job why would you want to change it?  Given
that a large proportion of systems boot in an identical fashion it's
likely that an off the shelf bootloader is more than capable of doing
the job.  It certainly seems crazy to write one from scratch given the
rather large range of existing ones, at most a bit of customisation
might be expected.

> > Also remember that many of the people doing upstream work are doing it
> > on various generic reference platforms rather than boards they
> > themselves have manufactured and may therefore have problems getting the
> > access that you get with commercial devices.

> Wait a second... how can you do development of BSP stuff for a product on
> an essentially different evaluation platform?
> I am starting to finally understand why things are as they are now. My
> excuses if it upset someone in the way.... :-(

I'm talking about upstream work here - people working on the stuff that
ends up in the mainline kernel.  A large part of that is done on widely
available reference boards rather than custom systems since either
people are trying to use the reference systems in various applications 
or they wish to provide examples others can actually run here.

People working on consumer or industrial systems are much less likely to
contribute upstream, even if they are enthusiastic about that they may
be using an old BSP from the vendor or carrying sufficient out of tree
code to cause problems.  There may well be no interest at all in
contributing upstream.

> > In process terms this is generally true of ARM also, it's just that
> > everything tends to be included in the kernel.

> Well, if you want to include _everything_ in the kernel, that's fine, but
> then don't use a bootloader, and set the rules accordingly. My primary
> concern is about there not being a single place for this. It's in the BL
> and in the kernel, and sometimes things are setup differently in both
> places!

The bootloader is still useful in that it allows you to replace the
system images without JTAG and can provide a basic hardware diagnosis
environment (without things like VM or multitasking to worry about).

> > Technically being able to replace the bootloader and being willing to
> > take the risk of bricking the system are not the same thing.

> If a PC does not work correctly (especially with a new feature or OS),
> manufacturers publish BIOS upgrades. People accept them as long as it's
> not too often. Heck, even game-console manufacturers sometimes remotely
> upgrade their bootloaders, and users don't even have the option to say no.
> And yes, I mean the actual bootloader, not just the firmware of the
> console.

Mass production commercial hardware tends to get rather more testing and
better support from their vendors than chip reference boards do for most
users.  The support structure and expectations in the two environments
are totally different and can't really be compared.

> > You need a mechanism to ensure all the engineers are applying bootloader
> > updates to their systems when required.  It's not insurmountable, but
> > it's one more thing that needs doing.

> Sorry, I am still baffled at how that can be a problem... I mean they are
> engineers, developing a product together, right? I'll take your word, but
> I am surprised.

Think of teams of fifty or more developers, somtimes distributed
geographically or organisationally, of varying degrees of skill.  The
communication overheads alone aren't trivial.

> > Not at all, people do ship systems with hardware physically present but
> > no software support and then add software support later especially with
> > reference designs.

> Well, I was referring to actual products, not reference designs. When we
> develop a product, we use the datasheet and reference manuals for the

A very great proportion of upstream kernel work is done on reference
designs of one form or another.  This means that the needs of reference 
designs are important to kernel developers, and the fact that systems
are often based on reference designs and intended to boot initially with
the reference design BSP means that even users working off on their own
care about them.

> design, and the reference design schematics to get a better idea of what
> the chip maker intended or omitted from the datasheet. Then we make a
> prototype of our design, which is 95% identical to the actually shipped
> product most of the time, and then we write a bootloader for it (mostly
> just porting u-boot), after that we develop a linux BSP, if possible from
> a git-tree as close to mainline as possible for that chip. And just after
> that do application developers get a chance to try out the software on our
> board.

> I naively thought most manufacturers did something similar. I understand
> now that I was wrong. Sorry. But it does hurt!

That's *broadly* similar but much more waterfall than you'd see on a big
project.  You'd also expect to see more spins of the system as it
progresses from a probable development system to a form factor system
with plastics, and there may be substantial integration effort if
there's lots of vendor code to merge in.

> > This is only a problem if you assume the bootloader is responsible for
> > doing the pin setup - clearly if it was supposed to do that and it
> > didn't there's an issue.

> It seems the most logical place to do it. Has the linux kernel (on x86)
> ever cared about DRAM timings, or PCI slew-rate settings, delay trimming,
> etc...? I think not. And hopefully it shouldn't. But if it needs to (for
> ARM), then let's find a sane way of specifying the settings, hopefully in

Things like DRAM mostly need to be set up prior to boot since the
bootloader tends to need them to do anything, never mind the kernel.
It's mostly the pin mux stuff that the kernel deals with.

> a way that is not related to re-useable code (drivers and such stuff). See
> the example given in my original post.

That's exactly what pretty much everyone is doing - there's a pin
configuration API that's totally separate to the drivers except in cases
where you need to change function at runtime.

> This has been an interesting discussion, but I don't want to upset any
> more people here. I just want to ask one more question, being new to
> ARM-linux: What setup should I chose for our products then? What would be
> more in tune with the most desireable long-term goal of ARM-linux booting?
> 
> 1. u-boot doing all pad/IO setup and loading linux.
> 2. u-boot just loading linux and doing only the minimum IO-setup necessary
> for that job, and write a linux BSP that does ALL IO-init
> 3. Don't use u-boot at all, and investigate Magnus's Kexec technique?
> 4. Something else?

I'd go for option 2 as we currently are, though I do prefer a bootloader
that doesn't require uImages (if only because mkimage seems to do such
nasty things with I/O, must debug that sometime).

ARM Machine SoC I/O setup and PAD initialization code

[Nicolas Pitre]

On Thu, 22 Jul 2010, David Jander wrote:

> On Thursday 22 July 2010 02:56:52 pm Mark Brown wrote:
> > On Thu, Jul 22, 2010 at 02:10:09PM +0200, David Jander wrote:
> > > IMO, if a bootloader is broken (in any way), it needs replacing. Be it
> > > with another bootloader or directly with the kernel.
> > 
> > If you don't have JTAG access (either due to device limitations or due
> > to lack of data from the vendor of a reference platform you're using)
> > replacing a bootloader can be rather more stressful than it's worth.
> 
> I agree, but I simply can't believe ARM platform designers all do such a bad 
> job at firmware (=bootloader) development in general, which is in sharp 
> contrast to what I have learned from previous PowerPC developments.

Well, this obviously didn't impair the success of the ARM architecture, 
nor did crappy BIOS has impaired the x86 architecture.  Becoming 
"mainstream" as the ARM architecture is becoming is always bound to 
create crap on the edges, such as poorly revised bootloader code.  And 
just as on X86, it is often better to simply not rely too much on the 
bootloader.  Mistakes and bugs will always happen in both the kernel and 
the bootloader.  But it is much more easier and efficient resource wise 
to fix a config bug in the kernel and updating it on the affected kernel 
than it is for fixing the same bug in the bootloader and updating the 
bootloader there.

> How can you assume that kernel-developers know how to correcly set-up the slew 
> rate and drive-strength of an I/O-pin for a given platform if the manufacturer 
> itself didn't do it nor document it!??

You can't.  But the kernel can be fixed while in many cases the 
bootloader practically can't.

> Even if it works with one guessed setting, there is a potential EMC impact 
> that needs to be taken care of.

What I've implemented so far is the ability to either set some 
parameters, or keep the existing ones, but not require for the kernel to 
have to setup everything up.  So if you don't know the right value for a 
setting as a kernel developer then you may just elect to leave it alone 
and hope that the bootloader has set it right.

> There are important hardware-design decisions after each of those settings! If 
> we continue this amateuristic approach, ARM-linux platforms will never get 
> taken seriously in more demanding environments. This really needs to change.

You are more than welcome to change this state of affairs.  And if you 
truly succeed where we all failed so far then it will only be a matter 
of removing the made redundant and useless setup code in the kernel.


Nicolas

ARM Machine SoC I/O setup and PAD initialization code

[David Jander]

On Thursday 22 July 2010 05:00:56 pm Nicolas Pitre wrote:
> On Thu, 22 Jul 2010, David Jander wrote:
> > On Thursday 22 July 2010 02:56:52 pm Mark Brown wrote:
> > > On Thu, Jul 22, 2010 at 02:10:09PM +0200, David Jander wrote:
> > > > IMO, if a bootloader is broken (in any way), it needs replacing. Be
> > > > it with another bootloader or directly with the kernel.
> > >
> > > If you don't have JTAG access (either due to device limitations or due
> > > to lack of data from the vendor of a reference platform you're using)
> > > replacing a bootloader can be rather more stressful than it's worth.
> >
> > I agree, but I simply can't believe ARM platform designers all do such a
> > bad job at firmware (=bootloader) development in general, which is in
> > sharp contrast to what I have learned from previous PowerPC developments.
> 
> Well, this obviously didn't impair the success of the ARM architecture,
> nor did crappy BIOS has impaired the x86 architecture.  Becoming
> "mainstream" as the ARM architecture is becoming is always bound to
> create crap on the edges, such as poorly revised bootloader code.  And
> just as on X86, it is often better to simply not rely too much on the
> bootloader.  Mistakes and bugs will always happen in both the kernel and
> the bootloader.  But it is much more easier and efficient resource wise
> to fix a config bug in the kernel and updating it on the affected kernel
> than it is for fixing the same bug in the bootloader and updating the
> bootloader there.

Not quite. On x86, you have the BIOS, and you really do need to rely on the 
BIOS to setup such low-level stuff correctly, and no, you cannot fix that in 
the kernel!
Even more so: The linux kernel is exactly the same binary for every PC it runs 
on. That's possible, because in the PC world (as crappy as it is otherwise) 
there actually _is_ a standard.

> > Even if it works with one guessed setting, there is a potential EMC
> > impact that needs to be taken care of.
> 
> What I've implemented so far is the ability to either set some
> parameters, or keep the existing ones, but not require for the kernel to
> have to setup everything up.  So if you don't know the right value for a
> setting as a kernel developer then you may just elect to leave it alone
> and hope that the bootloader has set it right.

Well, that's essentially the whole problem I see. Why not try to create a 
standard for such stuff on ARM. Maybe we would need the power of a few big 
players to get it in, maybe Linaro, or some other. IMHO it's about time there 
is more standardization on the ARM platforms that manufacturers do apply in 
their designs.

> > There are important hardware-design decisions after each of those
> > settings! If we continue this amateuristic approach, ARM-linux platforms
> > will never get taken seriously in more demanding environments. This
> > really needs to change.
> 
> You are more than welcome to change this state of affairs.  And if you
> truly succeed where we all failed so far then it will only be a matter
> of removing the made redundant and useless setup code in the kernel.

Please, my intention is not to be arrogant. I just want to make sure there is 
a need for something like OF from PowerPC or a similar standard. Introducing 
the change is another problem... let's just try to agree on something in the 
first place.

Of course, I will do what I can to help move in the right direction, and once 
there is a good standard, you have my word that I'll make sure all my hardware 
designs will adhere to it.

Best regards,

-- 
David Jander
Protonic Holland.

ARM Machine SoC I/O setup and PAD initialization code

[Rob Herring]

David,

On Thu, 2010-07-22 at 14:10 +0200, David Jander wrote:
> Hi all,
> 
> Thanks for all the reactions.
> 
> On Thursday 22 July 2010 10:16:17 am Magnus Damm wrote: 
> > <linux@arm.linux.org.uk> wrote:
> > > On Thu, Jul 22, 2010 at 11:32:53AM +0900, Simon Horman wrote:
> > >> Would it be feasible to  use Linux + kexec as the boot loader as
> > >> a long term solution to fixing boot loaders by eliminating them?
> > >
> > > So what you're proposing is that a broken boot loader should boot a
> > > version of Linux to fix the pin MUX, which then kexecs a kernel which
> > > doesn't have that code?
> > 
> > I think Simon was proposing to remove the broken boot loader.
> 
> IMO, if a bootloader is broken (in any way), it needs replacing. Be it with 
> another bootloader or directly with the kernel.
> I am working on i.MX51 right now, and that chip has it's own tiny bootloader 
> in ROM, which is able to load an image from SPI-NOR, SDHC, NAND, and some 
> other places, as well as initialize the DRAM controller with settings 
> contained at the beginning of the boot image. In theory it could just as well 
> boot a linux kernel directly. There is no real need for RedBoot, u-boot or 
> whatever other bootloader. In that case, all hardware setup code needs to be 
> done in the boot-code of the kernel.

MX51 ROM does not setup DRAM. So you still need some code to setup DRAM
and probably a few other things. For example the ROM may be broken like
a bootloader, but it is certainly not fixable without chip revision.
Also, the bootloader update process may be corruptible and brick your
device. So the bootloader is never updated and it has the fallback
capability for kernel updates.

What you can do is move bootloader features (and feature creep) like
networking, display, different media, etc. into the kernel and minimal
userspace.

> 
> > > What's the point of that - when the first kernel will be able to run
> > > the system?
> > 
> > If you boot straight into a Linux kernel (CONFIG_ZBOOT_ROM on ARM ?)
> > and use that to boot your real system, then at least you only need one
> > copy of pinmux setup code. If it gets executed once or twice is a
> > matter of system configuration IMO.
> 
> That sounds a lot "saner" to me than having two asynchronous and different 
> copies of setup-code, which could be a potential nightmare, besides not being 
> really maintainable.
> 
> > That aside, not trusting the boot loader is probably a good idea. =)
> 
> Why? If there's a boot-loader, it should know the correct hardware setup much 
> better than any other piece of software.
> Its fundamental role _IS_ basic hardware setup!
> 
> If bootloaders are broken, and delivered with the hardware, you should either 
> complain to the hardware manufacturer or fix the bootloader yourself if 
> possible... but not work around it.
> 
> Most of the time, if there are minor hardware changes, the linux kernel 
> shouldn't be involved if it is not necessary. The BIOS/Bootloader should 
> implement the necessary setup changes (if any). That way you don't need 
> different kernels for different hardware revisions.
> 
> The rationale is simple: The bootloader is bound to and unique to the specific 
> board configuration and -revision, whereas the kernel shoudn't change for a 
> given platform. Ideally one whould compile one kernel for a generic type of 
> i.MX51 machine, and that kernel should just work on all of them, that are 
> generic enough. An example of how to accomplish this is Open-Firmware device-
> tree support on the PowerPC architecture.

We build 1 kernel image for 3 MX5x chips for 5 boards already.

Regards,
Rob

ARM Machine SoC I/O setup and PAD initialization code

[Linus Walleij]

2010/7/21 David Jander <david.jander@protonic.nl>:

> General machine initialization like I/O-multiplexing and I/O-pad setup seems
> to be done twice most of the time: Once in the bootloader (i.e. u-boot), and
> once in the machine support file in the linux kernel. This seems awfully
> redundant and error-prone to me. Why is it like this?

I cannot talk for all platforms but on some systems I've worked with
it's not touched by the boot loader but all done by the kernel.

One reason is to keep the bootloader smallish.

Another reason is the ability to slam a kernel into primary memory
and just boot it, with *something else* than a boot loader, e.g.
JTAG. Which proves to be extremely convenient at times.

Yours,
Linus Walleij