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

[Haavard Skinnemoen]

On 9/22/06, Stefan Roese <sr at 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