[U-Boot-Users] 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
On Fri, Aug 15, 2003 at 02:21:48PM +0200, Jonas Larsson wrote:
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?
On Fri, 2003-08-15 at 17:19, Marc Singer wrote:
On Fri, Aug 15, 2003 at 02:21:48PM +0200, Jonas Larsson wrote:
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?
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
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?
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?
/ Jonas
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'.
I will submit a patch for the ebsa285 eval board later on.
Excellent.
Whats your preference: patch system at sourceforge or mailing list?
Read the ./README section called "Submitting Patches".
Cheers.
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
participants (3)
-
Jonas Larsson -
Marc Singer -
Wolfgang Denk