Dear Wolfgang,
Thanks for your patience.
2010/12/15 Wolfgang Denk wd@denx.de
Dear Macpaul Lin,
In message 1292398049-3606-1-git-send-email-macpaul@andestech.com you wrote:
Some device drivers and their header files will invoke some definitions for assembly code. If a device is required to be initilized in board.S or in lowlevel_init.S, such memory controller, flash controller, power control units. Sometimes we both need to access these devices in bootstrap process and later in normal operation period.
I don't understand what you mean. Do you have a specific example where anything like this actually happens?
Consider there are two different SoCs share the same peripheral devices. That is, two different SoC licensed the same device IP.
1. Include path problem. For example, Faraday a320 uses the same peripheral as AndesTech ag101. A320 and Ag101 will include the same header files for the same peripheral devices which are built-in into the SoC.
These SoC built-in devices include, ftsmc020.c (flash controller, arch/arm/cpu/arm920t/a320/ftsmc020.c), ftsmc020.h (flash controller, arch/arm/include/asm/arch-a320/ftsmc020.h),
ftpmu010.h (power controller, arch/arm/include/asm/arch-a320/ftpmu010.h), ftsdmc020.h (SDRAM controller, arch/arm/include/asm/arch-a320/ftsdmc020.h), fttmr010.h (RTC, arch/arm/include/asm/arch-a320/fttmr010.h).
The flash controller ftsmc020 has both assembly (offset table) and C code (structure). The other devices as assembly code only because they will be initialized in lowlevel_init.S or in board.S
1.1 At current situation, if ag101 want to include the device header file above, the code whether in "include/configs/adp-ag101.h" or in lowlevel_init.S will looks like.
#define CONFIG_FTSMC020 #ifdef CONFIG_FTSMC020 #include "../../../arch/arm/includes/asm/arch-a320/ftsmc020.h"
1.2 Even we move those header files into proper place, this problem still occur. For example, if we put ftsmc020.h and ftsmc020.c into "drivers/mtd" folder. The code in "faraday/a320evb/lowlevel_init.S" will exist #include "../../../drivers/mtd/ftsdmc020.h" and in "includes/configs/adp-ag101" will exist: #ifdef CONFIG_FTSMC020 #include "../../../drivers/mtd/ftsdmc020.h"
2. ftsmc020.c, ftsmc020.h, ftpmu010.h, ftsdmc020.h, fttmr010.h These files and headers should be put into drivers folder since there are multiple SoC share the same device controllers.
3. There is possibility we initialize device in lowlevel_init.S then reconfigure it in C level code. Such as sdram controller and flash controller. 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.
4. 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 instead of "board/Marvell/common/". Unless the policy is that we should create a specific folder for a company that sell SoC built-in devices. Like "board/Faraday/common". Otherwise it should be classified into "drivers" folder.
However, even we created a folder specific for a set of built-in devices, we still encounter the include path like: board/esd/cpci750/sdram_init.c:44:#include "../../Marvell/common/i2c.h"
5. Some shared header files of devices like "ftpmu010.h". The header file "ftpmu010.h" has only register and offset definitions. Should this kind of file go to "drivers" folder or go to "include" folder? 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.
Hence the definitions of these drivers in the
header files is required to be found in cpu and board folders. Moreover, these devices is usually built into multiple different SoC with different architectures. So the header files should be able to be shared among the SoCs.
If this happens, these header files should be at some sufficiently common location?
Add this CPPFLAGS += -I$(TOPDIR)/drivers into the default include PATH will avoid such code "#include "../../../../../drivers/mtd/flash.h"
You should always stop, lean back and start thinking where you went wrong whenever you encounter something that starts like this:
#include "../../../../../xxxThis simply does not make sense.
Best regards,
Wolfgang Denk