[U-Boot] ARM mach-types.h (was: Re: [PATCH 1/5] add DOCKSTAR machine type)
Dear all,
#define MACH_TYPE_WLAN_COMPUTER 2966 +#define MACH_TYPE_DOCKSTAR 2998
NAK. We don't edit mach-types.h manually.
If you need it updated, please send a request to do so to the acting ARM custodian (ahem).
But also note that we always sync against the current mainline Linux kernel, and this does not have an entry for DOCKSTAR yet (it ends at WLAN_COMPUTER), so a new sync would not change the file yet.
Since it apparently takes roughly two months for additions to the database at http://www.arm.linux.org.uk/developer/machines/ (last entry: 3061 right now) to trickle to the u-boot file, there seems to be a need for an interim solution.
Currently I conditionally add the MACH_TYPE_xxx locally to the <board>.h file, but I am quite sure a patch with that would be rejected...
Of course best would be to get rid of mach-types.h completely. It does not really seem suited to differentiate between board variants...
Reinhard
Dear Reinhard Meyer,
In message 4C873717.6000403@emk-elektronik.de you wrote:
Since it apparently takes roughly two months for additions to the database at http://www.arm.linux.org.uk/developer/machines/ (last entry: 3061 right now) to trickle to the u-boot file, there seems to be a need for an interim solution.
In theory it would be possible to sync against www.arm.linux.org.uk directly, but people with better ARM knowledge than me recommended not to do that, but refer to a more stable reference like the mainline Linux kernel instead.
I'm open to suggestions.
Currently I conditionally add the MACH_TYPE_xxx locally to the <board>.h file, but I am quite sure a patch with that would be rejected...
Right. This is not a good idea.
Of course best would be to get rid of mach-types.h completely. It does not really seem suited to differentiate between board variants...
You want to fight this flamewar with RMK, not me :-)
Best regards,
Wolfgang Denk
Dear Wolfgang Denk,
Dear Reinhard Meyer,
In message4C873717.6000403@emk-elektronik.de you wrote:
Since it apparently takes roughly two months for additions to the database at http://www.arm.linux.org.uk/developer/machines/ (last entry: 3061 right now) to trickle to the u-boot file, there seems to be a need for an interim solution.
In theory it would be possible to sync against www.arm.linux.org.uk directly, but people with better ARM knowledge than me recommended not to do that, but refer to a more stable reference like the mainline Linux kernel instead.
I'm open to suggestions.
I'd allow manual adding of a #define MACH_TYPE_xxxx at the end of the list provided its value is higher than the last "official" entry. Once the official list reaches or goes beyond that value the manual line(s) would be removed. Not being a shell script guru, I think that could be easily done.
Another option would be to derive the file directly from above website.
One catch remains, of course: I someone changed their entry at the database, compilation of u-boot for that board could break. I think that entries that have propagated to the mainline Linux kernel cannot be changed anymore.
I'd also think the u-boot mach-type.h could do well without all the function definitions. I have not grepped, however, if someone in u-boot uses them.
Reinhard
Dear Reinhard Meyer,
In message 4C874C02.9030801@emk-elektronik.de you wrote:
I'm open to suggestions.
I'd allow manual adding of a #define MACH_TYPE_xxxx at the end of the list provided its value is higher than the last "official" entry. Once the official list reaches or goes beyond that value the manual line(s) would be removed. Not being a shell script guru, I think that could be easily done.
No. This will quicklly result in a maze of merge conflicts.
We will always only update the file as a whole. THe only option I'm willing to discuss is where to get the file from.
One catch remains, of course: I someone changed their entry at the database, compilation of u-boot for that board could break. I think that entries that have propagated to the mainline Linux kernel cannot be changed anymore.
Right. Which is exactly the reason for syncing against this version.
I'd also think the u-boot mach-type.h could do well without all the function definitions. I have not grepped, however, if someone in u-boot uses them.
I don;t think we do. But as mentioned above, we don;t want to mess with this file, we just update it as is.
Best regards,
Wolfgang Denk
Wolfgang Denk schrieb:
Dear Reinhard Meyer,
In message 4C874C02.9030801@emk-elektronik.de you wrote:
I'm open to suggestions.
I'd allow manual adding of a #define MACH_TYPE_xxxx at the end of the list provided its value is higher than the last "official" entry. Once the official list reaches or goes beyond that value the manual line(s) would be removed. Not being a shell script guru, I think that could be easily done.
No. This will quicklly result in a maze of merge conflicts.
Not sure about that. I was thinking of a simple script that reads Linux' mach-types.h (or arch/arm/tools/mach-types directly) and generates the u-boot's mach-types.h file on the fly. That way only the #define lines could be generated, producing a less than 100k files instead of > 1MB.
The same script would read the existing mach-types.h file, scanning for something like
/* MANUAL ENTRIES START */ #define MACH_TYPE_XYZ 4711 #define MACH_TYPE_ABC 4712 /* MANUAL ENTRIES END */
and retain lines that are still above the official limit. A commit should show only "+" for the new official definitions and a "-" for all automagically removed manual definitions.
Otherwise:
It essentially means one can send patches for a new ARM based board only if the MACH_TYPE has trickled through all the instances.
This is, somehow, unpleasing:). We should not "punish" ourselves in u-boot just because someone has invented a method to prolong time-to-market ;)
Reinhard
Dear Reinhard Meyer,
In message 4C875885.9020709@emk-elektronik.de you wrote:
Not sure about that. I was thinking of a simple script that reads Linux' mach-types.h (or arch/arm/tools/mach-types directly) and generates the u-boot's mach-types.h file on the fly. That way only the #define lines could be generated, producing a less than 100k files instead of > 1MB.
I don't think mach-types.h is worth spending so much effort on it, and coming up with another set of tools, incompatible to everything else in the world.
The same script would read the existing mach-types.h file, scanning for something like
/* MANUAL ENTRIES START */ #define MACH_TYPE_XYZ 4711 #define MACH_TYPE_ABC 4712 /* MANUAL ENTRIES END */
I will not accept this. It willonly result in people adding entries that have not been registered so they cause conflicts sooner or later. We have been there before, and it did not work. I will not go back there.
Otherwise:
It essentially means one can send patches for a new ARM based board only if the MACH_TYPE has trickled through all the instances.
Right. But this should be no problem, as you can register your MACH_ID as early as you want.
This is, somehow, unpleasing:). We should not "punish" ourselves in u-boot just because someone has invented a method to prolong time-to-market ;)
Just react in a pro-active way and register your machines as soon as you start working on the hardware design, and everything is well.
Best regards,
Wolfgang Denk
No. This will quicklly result in a maze of merge conflicts.
We will always only update the file as a whole. THe only option I'm willing to discuss is where to get the file from.
One catch remains, of course: I someone changed their entry at the
database,
compilation of u-boot for that board could break. I think that entries
that
have propagated to the mainline Linux kernel cannot be changed anymore.
Right. Which is exactly the reason for syncing against this version.
I'd also think the u-boot mach-type.h could do well without all the
function
definitions. I have not grepped, however, if someone in u-boot uses them.
I don;t think we do. But as mentioned above, we don;t want to mess with this file, we just update it as is.
Best regards,
Wolfgang Denk
We are in sync with the latest in linux kernel
Take a look at
http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=history;f=ar...
Regards, Sandeep
Dear Paulraj, Sandeep,
We are in sync with the latest in linux kernel
Take a look at
http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=history;f=ar...
Please read the whole thread.
The point was that the kernel is about 2 months behind the entries in http://www.arm.linux.org.uk/developer/machines/
Best Regards, Reinhard
Dear "Paulraj, Sandeep",
In message 0554BEF07D437848AF01B9C9B5F0BC5DA8AA8E17@dlee01.ent.ti.com you wrote:
We are in sync with the latest in linux kernel
Yes, I know.
The problem we're discussing is that the version of mach-types.h as included in the mainline LInux kernel tree is relatively old when compared to the current state of the ARM machine registry. The question was if we should risk using something else as reference.
Best regards,
Wolfgang Denk
Yes, I know.
The problem we're discussing is that the version of mach-types.h as included in the mainline LInux kernel tree is relatively old when compared to the current state of the ARM machine registry. The question was if we should risk using something else as reference.
There is no need to use something different. Somebody needs to ask Russell King for an ARM sync request.
Regards, Sandeep
Am 08.09.2010 22:05, schrieb Paulraj, Sandeep:
Yes, I know.
The problem we're discussing is that the version of mach-types.h as included in the mainline LInux kernel tree is relatively old when compared to the current state of the ARM machine registry. The question was if we should risk using something else as reference.
There is no need to use something different. Somebody needs to ask Russell King for an ARM sync request.
Regards, Sandeep
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Hello,
mach-types is updated in linux kernel.
Thomas
participants (4)
-
Paulraj, Sandeep -
Reinhard Meyer -
Thomas Weber -
Wolfgang Denk