[U-Boot-Users] [PATCH, 4th resend] Support uImage files for the AVR32 architecture
Define IH_CPU_AVR32, make it possible to generate AVR32 uImage files with mkimage and make cmd_bootm recognize them.
Signed-off-by: Haavard Skinnemoen hskinnemoen@atmel.com ---
I've already sent this patch three times to the list, and I have still not gotten any response. It is really important for us to know if you intend to merge this or not; until then, there is no point for us to change the architecture ID as there will still be a possibility that someone else comes along and takes it.
Keeping the current AVR32 architecture ID will mean that our version of busybox will be incompatible with the upstream version because it clashes with the Blackfin ID. And the longer it takes before we get an "official" ID, the harder it will be for us to change it.
So if we don't get this issue resolved soon, I see no point in trying to contribute our changes back to you at all. This would be very unfortunate and effectively create an incompatible fork of u-boot with small chances of ever merging in the future.
It's up to you.
Haavard
common/cmd_bootm.c | 3 +++ include/image.h | 1 + tools/mkimage.c | 1 + 3 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c index fdf7180..2168e67 100644 --- a/common/cmd_bootm.c +++ b/common/cmd_bootm.c @@ -260,6 +260,8 @@ #elif defined(__nios2__) if (hdr->ih_arch != IH_CPU_NIOS2) #elif defined(__blackfin__) if (hdr->ih_arch != IH_CPU_BLACKFIN) +#elif defined(__avr32__) + if (hdr->ih_arch != IH_CPU_AVR32) #else # error Unknown CPU type #endif @@ -1236,6 +1238,7 @@ #endif case IH_CPU_INVALID: arch = "Invalid CPU"; break; case IH_CPU_ALPHA: arch = "Alpha"; break; case IH_CPU_ARM: arch = "ARM"; break; + case IH_CPU_AVR32: arch = "AVR32"; break; case IH_CPU_I386: arch = "Intel x86"; break; case IH_CPU_IA64: arch = "IA64"; break; case IH_CPU_MIPS: arch = "MIPS"; break; diff --git a/include/image.h b/include/image.h index 139df0b..d9f2d46 100644 --- a/include/image.h +++ b/include/image.h @@ -76,6 +76,7 @@ #define IH_CPU_NIOS 13 /* Nios-32 */ #define IH_CPU_MICROBLAZE 14 /* MicroBlaze */ #define IH_CPU_NIOS2 15 /* Nios-II */ #define IH_CPU_BLACKFIN 16 /* Blackfin */ +#define IH_CPU_AVR32 17 /* AVR32 */
/* * Image Types diff --git a/tools/mkimage.c b/tools/mkimage.c index fea3e5b..2cb2524 100644 --- a/tools/mkimage.c +++ b/tools/mkimage.c @@ -94,6 +94,7 @@ table_entry_t arch_name[] = { { IH_CPU_SPARC, "sparc", "SPARC", }, { IH_CPU_SPARC64, "sparc64", "SPARC 64 Bit", }, { IH_CPU_BLACKFIN, "blackfin", "Blackfin", }, + { IH_CPU_AVR32, "avr32", "AVR32", }, { -1, "", "", }, };
Hi Haavard,
On Friday 22 September 2006 14:09, Haavard Skinnemoen wrote:
I've already sent this patch three times to the list, and I have still not gotten any response. It is really important for us to know if you intend to merge this or not; until then, there is no point for us to change the architecture ID as there will still be a possibility that someone else comes along and takes it.
Yes, we intend to merge you patches, but I can't tell you right now if they will be accepted as is or if additional changes are required. Wolfgang is on vacation and hopefully we will find the time in the not too far future to catch up with the pending patches.
Keeping the current AVR32 architecture ID will mean that our version of busybox will be incompatible with the upstream version because it clashes with the Blackfin ID. And the longer it takes before we get an "official" ID, the harder it will be for us to change it.
Is there already an AVR32 architecture ID? I can't see one. It seems you are creating the new ID #17, right? How does it "clash" with the Blackfin ID?
So if we don't get this issue resolved soon, I see no point in trying to contribute our changes back to you at all. This would be very unfortunate and effectively create an incompatible fork of u-boot with small chances of ever merging in the future.
It could only be a problem, if another architecture ID patch is in our U-Boot patch queue, _before_ your patch is incorporated. I don't have an overview right now, but find it very unlikely.
Sorry for the inconvenience. Please be assured that we really what to change this pending patches dilemma we are in right now.
Best regards, Stefan
----- Original Message ----- From: "Stefan Roese" sr@denx.de To: u-boot-users@lists.sourceforge.net Cc: "Wolfgang Denk" wd@denx.de; "Haavard Skinnemoen" hskinnemoen@atmel.com Sent: Friday, September 22, 2006 7:09 PM Subject: Re: [U-Boot-Users] [PATCH,4th resend] Support uImage files for the AVR32 architecture
Hi Haavard,
On Friday 22 September 2006 14:09, Haavard Skinnemoen wrote:
I've already sent this patch three times to the list, and I have still not gotten any response. It is really important for us to know if you intend to merge this or not; until then, there is no point for us to change the architecture ID as there will still be a possibility that someone else comes along and takes it.
Yes, we intend to merge you patches, but I can't tell you right now if they will be accepted as is or if additional changes are required. Wolfgang is on vacation and hopefully we will find the time in the not too far future to catch up with the pending patches.
Keeping the current AVR32 architecture ID will mean that our version of busybox will be incompatible with the upstream version because it clashes with the Blackfin ID. And the longer it takes before we get an "official" ID, the harder it will be for us to change it.
Is there already an AVR32 architecture ID? I can't see one. It seems you are creating the new ID #17, right? How does it "clash" with the Blackfin ID?
So if we don't get this issue resolved soon, I see no point in trying to contribute our changes back to you at all. This would be very unfortunate and effectively create an incompatible fork of u-boot with small chances of ever merging in the future.
It could only be a problem, if another architecture ID patch is in our U-Boot patch queue, _before_ your patch is incorporated. I don't have an overview right now, but find it very unlikely.
Sorry for the inconvenience. Please be assured that we really what to change this pending patches dilemma we are in right now.
Since this is quite an important patch you could consider giving it priority.
If there is anything about the patch which you do not like, I am sure that you can modify this manually - It is very simple.
In fact, you could just decide to assign an architecture Id to the AVR32 and tell Haavard which to use.
Any forthcoming patch from anyone else using that id, then of course has to be rejected.
Best regards, Stefan
Best Regards Ulf Samuelsson ulf@atmel.com Atmel Nordic AB Mail: Box 2033, 174 02 Sundbyberg, Sweden Visit: Kavallerivägen 24, 174 58 Sundbyberg, Sweden Phone +46 (8) 441 54 22 Fax +46 (8) 441 54 29 GSM +46 (706) 22 44 57
Technical support when I am not available: AT89 C51 Applications Group: mailto:micro.hotline@nto.atmel.com AT90 AVR Applications Group: mailto:avr@atmel.com AT91 ARM Applications Group: mailto:at91support@atmel.com FPSLIC Application Group: mailto:fpslic@atmel.com Best AVR link: www.avrfreaks.net
On 9/22/06, Stefan Roese sr@denx.de wrote:
Hi Haavard,
On Friday 22 September 2006 14:09, Haavard Skinnemoen wrote:
I've already sent this patch three times to the list, and I have still not gotten any response. It is really important for us to know if you intend to merge this or not; until then, there is no point for us to change the architecture ID as there will still be a possibility that someone else comes along and takes it.
Yes, we intend to merge you patches, but I can't tell you right now if they will be accepted as is or if additional changes are required. Wolfgang is on vacation and hopefully we will find the time in the not too far future to catch up with the pending patches.
Ok, thanks. I'm not in that much of a hurry getting everything merged, but the architecture ID issue has the potential of becoming a major blocker in the future, so I'd really like to get it resolved as soon as possible.
If you (or Wolfgang) could just reserve an ID for us in some way (for example by adding a comment saying something like "ID #17 is reserved for AVR32"), that would be fine too.
Keeping the current AVR32 architecture ID will mean that our version of busybox will be incompatible with the upstream version because it clashes with the Blackfin ID. And the longer it takes before we get an "official" ID, the harder it will be for us to change it.
Is there already an AVR32 architecture ID? I can't see one. It seems you are creating the new ID #17, right? How does it "clash" with the Blackfin ID?
That's true, but we're already shipping development boards with u-boot version 1.1.4 pre-installed (and the source code + patches on CD.) In that version, AVR32 has ID #16, which is the same as the one Blackfin uses in the u-boot git tree.
Changing the AVR32 architecture ID will cause problems for our users, so we'd really prefer to do it as soon as possible, and make sure that it never happens again. That's why this issue is so important for us to get resolved.
So if we don't get this issue resolved soon, I see no point in trying to contribute our changes back to you at all. This would be very unfortunate and effectively create an incompatible fork of u-boot with small chances of ever merging in the future.
It could only be a problem, if another architecture ID patch is in our U-Boot patch queue, _before_ your patch is incorporated. I don't have an overview right now, but find it very unlikely.
Ok, I'd really appreciate it if you could try to find out within a week or two.
Sorry for the inconvenience. Please be assured that we really what to change this pending patches dilemma we are in right now.
Yeah, I understand that you have a huge backlog. Please let me know if there's anything I can do to make things easier for you.
I've requested a public GIT repository hosted by Atmel so that future merges may be less painful. I don't know exactly when it will be up and running, though.
Haavard
On Fri, 22 Sep 2006 19:34:11 +0200 "Haavard Skinnemoen" hskinnemoen@gmail.com wrote:
So if we don't get this issue resolved soon, I see no point in trying to contribute our changes back to you at all. This would be very unfortunate and effectively create an incompatible fork of u-boot with small chances of ever merging in the future.
It could only be a problem, if another architecture ID patch is in our U-Boot patch queue, _before_ your patch is incorporated. I don't have an overview right now, but find it very unlikely.
Ok, I'd really appreciate it if you could try to find out within a week or two.
So...it's been more than two weeks now. Can you reserve ID #17 (or a different one) for AVR32?
Haavard
On Friday 22 September 2006 14:09, Haavard Skinnemoen wrote:
Define IH_CPU_AVR32, make it possible to generate AVR32 uImage files with mkimage and make cmd_bootm recognize them.
Signed-off-by: Haavard Skinnemoen hskinnemoen@atmel.com
Applied. Thanks.
Best regards, Stefan
On Mon, 9 Oct 2006 14:54:14 +0200 Stefan Roese sr@denx.de wrote:
On Friday 22 September 2006 14:09, Haavard Skinnemoen wrote:
Define IH_CPU_AVR32, make it possible to generate AVR32 uImage files with mkimage and make cmd_bootm recognize them.
Signed-off-by: Haavard Skinnemoen hskinnemoen@atmel.com
Applied. Thanks.
Ah, thanks a lot! I'll tell all internal users to upgrade as soon as possible.
Haavard
participants (4)
-
Haavard Skinnemoen -
Haavard Skinnemoen -
Stefan Roese -
Ulf Samuelsson