[U-Boot] [U-Boot-Users] Request: s3c24xx getting its own start.S file ?

[Harald Welte]

Hi Jean-Christophe,

On Mon, Aug 18, 2008 at 11:03:32PM +0200, Wolfgang Denk wrote:
> In message <20080707072909.GA4412 at prithivi.gnumonks.org> Harald Welte wrote:
> > 
> > the problem is tha the main makefile always wants to build
> > cpu/arm920t/start.o, and I don't see an easy way how it could be
> > modified to build cpu/arm920t/s3c24x0/start.o instead.  At least until
> > now I don't see an infrastructure for this.
> > 
> > > > the attached patch, where the cpu/arm920t/start.S #includes a
> > > > cpu/arm920t/s3c24x0/start.S file.
> > > > 
> > > > It's not really nice, but otherwise I assure you anyone touching the
> > > > arm920t start.S file again will find itself in #ifdef/endif hell, once
> > > > all my s3c24xx related patches would be merged...
> > > 
> > > I really dislike the code duplication.
> > 
> > same here.  but I'd rather duplicate some 50-100 lines than have 300
> > lines of completely unreadable #ifdef hell.
> ...
> 
> This falls mostly into your (i. e. ARM custodian) bailiwick. Could you
> please make sure that we don't lose this thread? Thanks.

JC: can you please comment on this?

I'd really like to 'fork' the arm920t/start.S in order to have a s3c24xx
specific part.  The many various boot related #ifdefs make the s3c24xx specific
bit hard enough to read, not even talking about other arm920t based systems.

I have an entire pile of patches waiting for a decision on this.  I've
converted my s3c24xx related (and openmoko related) patches to work on top of a
s3c24xx separate start.S now and I think the code looks much clearer (please
see the original thread leading to this mail)

Also: Would you want to get my s3c24xx related work based on your ARM custodian
tree, or based on the main u-boot tree?
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080822/eb5c1b42/attachment.pgp