[U-Boot-Users] [PATCH] Generic Support for Motorola i.MX architecture

[Wolfgang Denk]

In message <410F766F.2020106 at imc-berlin.de> you wrote:
>
> Does it make sense to put processor specific peripheral code into 
> cpu/arm920t directory (like s3c24x0_serial.c or imx_interrupts.c or usb c
> ode)!?

Yes, it makes sense, in so far as the  cpu/<processor>  directory  is
explicitely  intended  to  hold  all  code  that  is  specific to the
<processor> CPU.

It might make sense to add an additionallevel of directories,  i.  e.
turn s3c24x0_* or imx_* into s3c24x0/* and imx/* resp.

> Although the AT91RM9200 is based on a ARM9 it has it's own directory.

Which is IMHO a bad thing.

> I understand that copying the same code again and again won't make sense.

Indeed.

> A while ago I suggested to create cpu/imx, cpu/s3c24x0 etc. and put all the 
> cpu specific stuff in there.

Agreed. Please submit a patch.

> To avoid copying the arm9 generic code one could do:

ARM9 generic code should stay in cpu/arm920t/

> 1.) cpu/at91rm9200/Makefile:
> 
>      OBJS    = ../arm920t/interrupts.o ../arm920t/cpu.o \
>                serial.o at91rm9200_ether.o at45.o
> 
>      start.S has to be a link "start.S -> ../arm920t/start.S" since

No.

> 2.) Or creating (by Makefile) links to the generic sources:
> 
>      LINKS = start.S interrupts.c cpu.c
> 
>      $(LINKS)
>          ln -s ../arm920t/$@ $@    (oder s.ä.)

No.

> Comments?

Both methods don't look really attractive to me. If ther  eis  common
code, it shall remain in the common directory.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Any sufficiently advanced technology is indistinguishable from magic.
Clarke's Third Law       - _Profiles of the Future_ (1962; rev. 1973)
                  ``Hazards of Prophecy: The Failure of Imagination''