[U-Boot-Users] [PATCH] Generic Support for Motorola i.MX architecture
wd at denx.de
Tue Aug 3 15:27:50 CEST 2004
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
Yes, it makes sense, in so far as the cpu/<processor> directory is
explicitely intended to hold all code that is specific to the
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.
> 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
> 2.) Or creating (by Makefile) links to the generic sources:
> LINKS = start.S interrupts.c cpu.c
> ln -s ../arm920t/$@ $@ (oder s.ä.)
Both methods don't look really attractive to me. If ther eis common
code, it shall remain in the common directory.
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''
More information about the U-Boot