Dear Wolfgang,
2010/12/16 Wolfgang Denk wd@denx.de:
Dear Macpaul Lin,
- There is possibility we initialize device in lowlevel_init.S then
reconfigure it in C level code. Such as sdram controller and flash controller.
SDRAM should not be initialized in lowlevel_init.S. Please use the (new for ARM, shared with PPC which has always been using this) model where RAM initialization is done in dram_init(), i. e. as part of the init sequence in arch/arm/lib/board.c
For example, in "arch/arm/include/asm/arch-at91/at91_mc.h" and in "arch/arm/include/asm/arch-a320/ftsmc020.h" There both exist assembly offset and C type structures. Once other SoC use the same device controller whether in lowlevel_int.S and in board.c, it will have include problem as described in #1 and in #2.
See above - this means that the header file needs to be moved to acommon include directory.
- If you execute 'grep -rnH "../../Marvell/" *' in the root of u-boot
code, you will find the similar situation about sharing header files with same devices. Includes, pci.h, memory.h, core.h, i2c.h. I guess even these devices is built-in in the SoC (chip), it is better to go to "drivers" folder
drivers is not a common include directory, and thus not the right place.
instead of "board/Marvell/common/".
That may be true.
Since they are configured like a device drivers in a SoC (in board.c or in lowlevel_init.S). I guess they should be put into "drivers" folder.
If this is common driver code, the code itself should be moved to drivers (and then, and only then, the header files with the code).
Best regards,
Wolfgang Denk
Your opinion is understood.
1. I will trying to make those shared devices being configurable as C drivers instead of assembly definitions as possible. 2. For those devices which is hard/unnecessary to write a driver, I will take effort on creating a common folder something like include/faraday or include/faraday/common to collect those definitions.