Becuase the board select menu in arch/arm/Kconfig is too big,
move the OMAP3 board select menu to omap3/Kconfig.
Move also common settings (CONFIG_SYS_CPU="armv7" and
CONFIG_SYS_SOC="omap3
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Reviewed-by: Tom Rini <trini@ti.com>
We have switched to Kconfig and the boards.cfg file is going to
be removed. We have to retrieve the board status and maintainers
information from it.
The MAINTAINERS format as in Linux Kernel would be nice
because we can crib the scripts/get_maintainer.pl script.
After some discussion, we chose to put a MAINTAINERS file under each
board directory, not the top-level one because we want to collect
relevant information for a board into a single place.
TODO:
Modify get_maintainer.pl to scan multiple MAINTAINERS files.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Suggested-by: Tom Rini <trini@ti.com>
Acked-by: Simon Glass <sjg@chromium.org>
This commit adds:
- arch/${ARCH}/Kconfig
provide a menu to select target boards
- board/${VENDOR}/${BOARD}/Kconfig or board/${BOARD}/Kconfig
set CONFIG macros to the appropriate values for each board
- configs/${TARGET_BOARD}_defconfig
default setting of each board
(This commit was automatically generated by a conversion script
based on boards.cfg)
In Linux Kernel, defconfig files are located under
arch/${ARCH}/configs/ directory.
It works in Linux Kernel since ARCH is always given from the
command line for cross compile.
But in U-Boot, ARCH is not given from the command line.
Which means we cannot know ARCH until the board configuration is done.
That is why all the "*_defconfig" files should be gathered into a
single directory ./configs/.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Acked-by: Simon Glass <sjg@chromium.org>
At present stdio device functions do not get any clue as to which stdio
device is being acted on. Some implementations go to great lengths to work
around this, such as defining a whole separate set of functions for each
possible device.
For driver model we need to associate a stdio_dev with a device. It doesn't
seem possible to continue with this work-around approach.
Instead, add a stdio_dev pointer to each of the stdio member functions.
Note: The serial drivers have the same problem, but it is not strictly
necessary to fix that to get driver model running. Also, if we convert
serial over to driver model the problem will go away.
Code size increases by 244 bytes for Thumb2 and 428 for PowerPC.
22: stdio: Pass device pointer to stdio methods
arm: (for 2/2 boards) all +244.0 bss -4.0 text +248.0
powerpc: (for 1/1 boards) all +428.0 text +428.0
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Marek Vasut <marex@denx.de>
Reviewed-by: Marek Vasut <marex@denx.de>
- When CONFIG_DISPLAY_CPUINFO is not enabled,
print_cpuinfo() should be defined as an empty function
in a header, include/common.h
- Remove #ifdef CONFIG_DISPLAY_CPUINFO .. #endif
from caller, common/board_f.c and arch/arm/lib/board.c
- Remove redundant prototypes in arch/arm/lib/board.c,
arch/arm/include/asm/arch-am33x/sys_proto.h and
board/nokia/rx51/rx51.h, keeping the one in include/common.h
- Add #ifdef CONFIG_DISPLAY_CPUINFO to the func definition
where it is missing
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
u-boot standard i2c read prototype is
i2c_read(addr, reg, 1, &buf, 1)
twl4030_i2c_read_u8(u8 addr, u8 *val, u8 reg)
does not provide consistency, so switch the prototype to be
consistent with rest of u-boot i2c operations:
twl4030_i2c_read_u8(u8 addr, u8 reg, u8 *val)
Signed-off-by: Nishanth Menon <nm@ti.com>
u-boot standard i2c register write prototype is
i2c_reg_write(u8 addr, u8 reg, u8 val)
twl4030_i2c_write_u8(u8 addr, u8 val, u8 reg)
does not provide consistency, so switch the prototype to be
consistent with rest of u-boot i2c operations:
twl4030_i2c_write_u8(u8 addr, u8 reg, u8 val)
Signed-off-by: Nishanth Menon <nm@ti.com>
Masahiro Yamada
Simon Glass
Wolfgang Denk
Nishanth Menon
Nikita Kiryanov
Pali Rohár