[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