[U-Boot-Users] [PATCH] AT91SAM9263 Board files
Wolfgang Denk
wd at denx.de
Fri Feb 2 01:07:18 CET 2007
In message <022e01c74631$4177caa0$01c4af0a at atmel.com> you wrote:
>
> There are even files there which are larger than the mailing list limit.
> The CPU header files are ~ 100-200 kB.
> The USB host support is > 40 kB.
...uncompressed, I guess.
> This means that I cannot supply everything as a patch.
> I *must* due to the size of the patch supply as several patches, each below
> 40 kB.
right. so (1) compress it, and (2) create a series of numbered
patches as everybody else is doing this.
> I wrote an application which splits a large file into one patch
> per file in the target system, so all patches can be applied in any order.
> The Atmel U-Boot contains 4 new boards, and the patch
> for Makefile and MAKEALL contains all four boards.
No. The support for each board should be separated and sumbitrted
independently, i. e. each patch will add just one target to Makefile
and MAKEALL. Please see the patch requirements in the README.
> If that needs to be split up into 4 patches, then there have to be a
> patch order for those two files.
Yes, of course.
> * "cmp" support for dataflash
> * "crc" support for dataflash
Don't bother about this. It will not be accepted.
> In the end I would like to move all boards down to the
> "board/atmel" directory at the end of the
That would be good [and needs no significant patch size, as git is
clever enough to recognize file renames and just includes meta
information in the patches it creates].
> I think it would be easier if we broke down things into smaller parts.
Yes, it is. But a patch is a patch, not a tarball, and it has a
description, a changelog, and eventually a sequence number. Please
see the README.
> First I would like to move of the dataflash support to the driver directory.
I'm not sure this makes sense, given the fact that this will be soon
(?) reworked.
> Then adding patches for the ARM926 based cpu/board directories,
> but without any references to these patches in Makefiles/MAKEALL.
> At the end a patch which would make them buildable.
No. Each patch is supposed to be independent of the others. It should
be possible to apply only the first N patches of your sequenbce and
get a useful, buildable code version - otherwise you will always have
to rework the whole sequence if patch N+1 gets rejected for a reason
or another.
But all this is documented in the README.
> This would during a short period give some "dangling" or unused code
> I know you don't like that, so how proceed with such a large patchset,
> where things depend on each other?
Split it in orthogonal chunks. That's what they do with Linux, and
what we have been doing with U-Boot for a long, long time.
> I dont have any git server which I can use for this.
You don't need a git server. Use a local repositoy, and git to create
the patches.
> Will try to get access to www.atmel.no like Haavard
> but I do not know know if it is possible and if it is, when it is possible.
It's not needed.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Ill-chosen abstraction is particularly evident in the design of the
ADA runtime system. The interface to the ADA runtime system is so
opaque that it is impossible to model or predict its performance,
making it effectively useless for real-time systems.
- Marc D. Donner and David H. Jameson.
More information about the U-Boot
mailing list