jonas.larsson at netinsight.net
Fri Aug 15 18:04:40 CEST 2003
On Fri, 2003-08-15 at 17:50, Marc Singer wrote:
> > > That's an interesting idea, though I'm not sure I can see how it would
> > > be valuable in practice. Do you have systems where the hardware setup
> > > is identitical but the ARM CPU is different?
> > Nope. The arch number specifies what kind of arm-board the kernel is
> > booting on. One kernel binary is in my case able to handle 3 different
> > versions of boards (and its hard or dangerous to find out by probing
> > the board). The number is used to tell the kernel about how irq-lines
> > etc are wired on the board. Perhaps the name 'arch' is a bad choice,
> > perhaps "arm-mach" is better.
> Yes, I understand that. It is also important that the board setup be
> compatible which is the responsibility of uboot. Which seems to be
> true in your case. None of the Arm chips I've used have this feature.
> While they can be dynamically detected without danger, it is just as
> easy to make separate u-boot builds for each.
> Which chips are you using?
I'm working on an U-boot port to StrongARM (SA110) [ensa285]. Our
board are based the ebsa285 eval board but are in some parts different
(such as irq-mapping to networking chips). It is quite easy to have the
same kernel for all the boards and handle the differences with the
machine number. I cannot detect the board type in u-boot, hence
I added the arch env variable.
For sure I could hard-code each mach nbr in my board dependent code at
compile time. But this would mean more release management on my behalf.
With the arch env its just a factory setting to be made.
I will submit a patch for the ebsa285 eval board later on.
Whats your preference: patch system at sourceforge or mailing list?
More information about the U-Boot