In message 410F766F.2020106@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