Patches
I have a question regarding submitting patches.
Should I send them to the mailing list or to the patch tracking system at sourceforge? I've submitted a patch to sourcforge already.
The patch adds support for an environment variable 'arch' which is passed as the ARM machine number to the kernel if set. The u-boot behaviour is unchanged if 'arch' is not defined.
/ Jonas
Quoted 9 lines · Jonas Larsson
I have a question regarding submitting patches.
Should I send them to the mailing list or to the patch tracking system at sourceforge? I've submitted a patch to sourcforge already.
The patch adds support for an environment variable 'arch' which is passed as the ARM machine number to the kernel if set. The u-boot behaviour is unchanged if 'arch' is not defined.
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?
Quoted 7 lines · Marc Singer
Quoted 6 lines · Jonas Larsson
I have a question regarding submitting patches.
Should I send them to the mailing list or to the patch tracking system at sourceforge? I've submitted a patch to sourcforge already.
Quoted 7 lines
Quoted 3 lines
The patch adds support for an environment variable 'arch' which is passed as the ARM machine number to the kernel if set. The u-boot behaviour is unchanged if 'arch' is not defined.
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.
/ Jonas
Quoted 11 lines
Quoted 3 lines
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?
Quoted 12 lines · Marc Singer
Quoted 11 lines
Quoted 3 lines
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.
Quoted 7 lines
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?
/ Jonas
Quoted 3 lines
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 can see what you mean.
BTW, 'arm-arch' or 'arm-arch-number' is probably a better name for the variable than 'arch'.
Quoted 1 line
I will submit a patch for the ebsa285 eval board later on.
Excellent.
Quoted 1 line
Whats your preference: patch system at sourceforge or mailing list?
Read the ./README section called "Submitting Patches".
Cheers.
Quoted 2 lines · In message <1060963480.26299.67.camel@doris> you wrote:
Whats your preference: patch system at sourceforge or mailing list?
Mailing list, please.
If I'd knew how to do that I'd turn of the SF features as I find them difficult to use, so I tend to ignore them.
Best regards,
Wolfgang Denk
Signature · 4 lines
Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de "May the forces of evil become confused on the way to your house." - George Carlin