[U-Boot-Users] [PATCH, 4th resend] Support uImage files for the AVR32 architecture

[U-Boot-Users] [PATCH, 4th resend] Support uImage files for the AVR32 architecture

[Haavard Skinnemoen]

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,			"",		"",		},
 };
 
-- 
1.4.1.1

[U-Boot-Users] [PATCH, 4th resend] Support uImage files for the AVR32 architecture

[Stefan Roese]

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

[U-Boot-Users] [PATCH, 4th resend] Support uImage files for the AVR32 architecture

[Ulf Samuelsson]

----- 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 at 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 at nto.atmel.com
AT90 AVR Applications Group: mailto:avr at atmel.com
AT91 ARM Applications Group: mailto:at91support at atmel.com
FPSLIC Application Group: mailto:fpslic at atmel.com
Best AVR  link: www.avrfreaks.net

[U-Boot-Users] [PATCH, 4th resend] Support uImage files for the AVR32 architecture

[Haavard Skinnemoen]

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

[U-Boot-Users] [PATCH, 4th resend] Support uImage files for the AVR32 architecture

[Haavard Skinnemoen]

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

[U-Boot-Users] [PATCH, 4th resend] Support uImage files for the AVR32 architecture

[Stefan Roese]

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

[U-Boot-Users] [PATCH, 4th resend] Support uImage files for the AVR32 architecture

[Haavard Skinnemoen]

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

[U-Boot-Users] [PATCH, 4th resend] Support uImage files for the AVR32 architecture

[Stefan Roese]

On Monday 09 October 2006 16:55, Haavard Skinnemoen wrote:
> Ah, thanks a lot! I'll tell all internal users to upgrade as soon as
> possible.

I'll try to find the time to review and apply the remaining AVR32 patches 
sometime this week.

Best regards,
Stefan