We are about to switch to Kconfig in the next commit.
But there are something to get done beforehand.
In Kconfig, include/generated/autoconf.h defines boolean
CONFIG macros as 1.
CONFIG_SPL and CONFIG_TPL, if defined, must be set to 1.
Otherwise, when switching to Kconfig, the build log
would be sprinkled with warning messages like this:
warning: "CONFIG_SPL" redefined [enabled by default]
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Some architecture needs extra device tree setup. Instead of adding
yet another hook, convert arch_fixup_memory_node to be a generic
FDT fixup function.
[maz: collapsed 3 patches into one, rewrote commit message]
Signed-off-by: Ma Haijun <mahaijuns@gmail.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
This patch moves some board specific NAND configs:
- FROM: generic config file 'ti_armv7_common.h'
- TO: individual board config files using these configs.
So that each board can independently set the value as per its design.
Following configs are affected in this patch:
CONFIG_SYS_NAND_U_BOOT_OFFS: <refer doc/README.nand>
CONFIG_CMD_SPL_NAND_OFS: <refer doc/README.falcon>
CONFIG_SYS_NAND_SPL_KERNEL_OFFS: <refer doc/README.falcon>
CONFIG_CMD_SPL_WRITE_SIZE: <refer doc/README.falcon>
This patch also updates documentation for few of above NAND configs.
Signed-off-by: Pekon Gupta <pekon@ti.com>
Fixes commit a0a37183bd
ARM: omap: merge GPMC initialization code for all platform
1) NAND device are not directly memory-mapped to CPU address-space, they are
indirectly accessed via following GPMC registers:
- GPMC_NAND_COMMAND_x
- GPMC_NAND_ADDRESS_x
- GPMC_NAND_DATA_x
Therefore from CPU's point of view, NAND address-map can be limited to just
above register addresses. But GPMC chip-select address-map can be configured
in granularity of 16MB only.
So this patch uses GPMC_SIZE_16M for all NAND devices.
2) NOR device are directly memory-mapped to CPU address-space, so its
address-map size depends on actual addressable region in NOR FLASH device.
So this patch uses CONFIG_SYS_FLASH_SIZE to derive GPMC chip-select address-map
size configuration.
Signed-off-by: Pekon Gupta <pekon@ti.com>
This patch adds clock definitions and commands to support Keystone2
K2E SOC.
Signed-off-by: Hao Zhang <hzhang@ti.com>
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
This patch adds a common config header file for all the Keystone II
EVM platforms. It combines a lot of general definitions in one file.
The common header included in the EVM should be specific configuration
header.
Acked-by: Murali Karicheri <m-karicheri2@ti.com>
Signed-off-by: Hao Zhang <hzhang@ti.com>
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
This patch moves K2HK board directory to a common Keystone II board
directory. The Board related common functions are moved to a common
keystone board file.
Acked-by: Murali Karicheri <m-karicheri2@ti.com>
Signed-off-by: Hao Zhang <hzhang@ti.com>
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
Use KS2_ prefix in all definitions, for that replace K2HK_ prefix and
add KS2_ prefix where it's needed. It requires to change names also
in places where they're used. Align lines and remove redundant
definitions in kardware-k2hk.h at the same time.
Using common KS2_ prefix helps resolve redundant redefinitions and
adds opportunity to use KS2_ definition across a project not thinking about
what SoC should be used. It's more convenient and we don't need to worry
about the SoC type in common files, hardware.h will think about that.
The hardware.h decides definitions of what SoC to use.
Acked-by: Murali Karicheri <m-karicheri2@ti.com>
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
Add script to automate NAND flash process. As for now the board has
two burn scripts - burn to boot from SPI NOR flash and burn to boot
from AEMIF NAND flash, rename burn_uboot script to burn_uboot_spi.
Also update README to contain NAND burn U-boot process description.
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
Acked-by: Murali Karicheri <m-karicheri2@ti.com>
The Keystone SoCs use the same NAND driver as Davinci.
This patch adds opportunity to write Keystone U-boot image to NAND
device using appropriate RBL ECC layout. This is needed only if RBL
boots U-boot from NAND device and that's supposed that raw u-boot
partition is used only for writing image.
The main problem is that default Davinci ECC layout is different from
Keystone RBL layout. To read U-boot image the RBL needs that image was
written using RBL ECC layout.
The BBT table is written using default Davinci layout and has to
be updated using one. The BBT can be updated only while erasing
chip or by forced bad block assigning, so erase function has to
use native ecc layout in order to be able to write BBT correctly.
So if we're writing to NAND U-boot address we use RBL layout for
others we use default ECC layout.
Also remove definition for CONFIG_CMD_NAND_ECCLAYOUT as there is no
reasons to use ECC layout commands. It was added by mistake.
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
Add in an init function for the drivers/power framework so we can dump
and read the registers via i2c.
Cc: Łukasz Majewski <l.majewski@samsung.com>
Signed-off-by: Tom Rini <trini@ti.com>
As this is a weak function that we may override, provide a prototype for
it.
Cc: Łukasz Majewski <l.majewski@samsung.com>
Signed-off-by: Tom Rini <trini@ti.com>
The alt board has R8A7794, 1GB DDR3-SDRAM, USB, Ethernet, QSPI,
MMC, SDHI and more.
This commit supports the following functions:
- DDR3-SDRAM
- SCIF
- I2C
- Ethernet
- QSPI
Signed-off-by: Hisashi Nakamura <hisashi.nakamura.ak@renesas.com>
Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Some boards will have devices which are not in the device tree and do not
have platform data. They may be programnatically created, for example.
Add a hook which boards can use to bind those devices early in boot.
Signed-off-by: Simon Glass <sjg@chromium.org>
Some devices (particularly bus devices) must track their children, knowing
when a new child is added so that it can be set up for communication on the
bus.
Add a child_pre_probe() method to provide this feature, and a corresponding
child_post_remove() method.
Signed-off-by: Simon Glass <sjg@chromium.org>
Some device types can have child devices and want to store information
about them. For example a USB flash stick attached to a USB host
controller would likely use this space. The controller can hold
information about the USB state of each of its children.
The data is stored attached to the child device in the 'parent_priv'
member. It can be auto-allocated by dm when the child is probed. To
do this, add a per_child_auto_alloc_size value to the parent driver.
Signed-off-by: Simon Glass <sjg@chromium.org>
Devices can have childen that can be addressed by a simple index, the
sequence number or a device tree offset. Add functions to access a child
in each of these ways.
The index is typically used as a fallback when the sequence number is not
available. For example we may use a serial UART with sequence number 0 as
the console, but if no UART has sequence number 0, then we can fall back
to just using the first UART (index 0).
The device tree offset function is useful for buses, where they want to
locate one of their children. The device tree can be scanned to find the
offset of each child, and that offset can then find the device.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present only root nodes in the device tree are scanned for devices.
But some devices can have children. For example a SPI bus may have
several children for each of its chip selects.
Add a function which scans subnodes and binds devices for each one. This
can be used for the root node scan also, so change it.
A device can call this function in its bind() or probe() methods to bind
its children.
Signed-off-by: Simon Glass <sjg@chromium.org>
Each device that was bound from a device tree has an node that caused it to
be bound. Add functions that find and return a device based on a device tree
offset.
Signed-off-by: Simon Glass <sjg@chromium.org>
In U-Boot it is pretty common to number devices from 0 and access them
on the command line using this numbering. While it may come to pass that
we will move away from this numbering, the possibility seems remote at
present.
Given that devices within a uclass will have an implied numbering, it
makes sense to build this into driver model as a core feature. The cost
is fairly small in terms of code and data space.
With each uclass having numbered devices we can ask for SPI port 0 or
serial port 1 and receive a single device.
Devices typically request a sequence number using aliases in the device
tree. These are resolved when the device is probed, to deal with conflicts.
Sequence numbers need not be sequential and holes are permitted.
At present there is no support for sequence numbers using static platform
data. It could easily be added to 'struct driver_info' if needed, but it
seems better to add features as we find a use for them, and the use of -1
to mean 'no sequence' makes the default value somewhat painful.
Signed-off-by: Simon Glass <sjg@chromium.org>
Aliases are used to provide U-Boot's numbering of devices, such as:
aliases {
spi0 = "/spi@12330000";
}
spi@12330000 {
...
}
This tells us that the SPI controller at 12330000 is considered to be the
first SPI controller (SPI 0). So we have a numbering for the SPI node.
Add a function that returns the numbering for a node assume that it exists
in the list of aliases.
Signed-off-by: Simon Glass <sjg@chromium.org>
For sandbox we have a fallback console which is used very early in
U-Boot, before serial drivers are available. Rather than try to guess
when to switch to the real console, add a flag so we can be sure. This
makes sure that sandbox can always output a panic() message, for example,
and avoids silent failure (which is very annoying in sandbox).
Signed-off-by: Simon Glass <sjg@chromium.org>
The current functions for adding and removing devices require a device name.
This is not convenient for driver model, which wants to store a pointer to
the relevant device. Add new functions which provide this feature and adjust
the old ones to call these.
Signed-off-by: Simon Glass <sjg@chromium.org>
Initialise devices marked 'pre-reloc' and make them available prior to
relocation. Note that this requires pre-reloc malloc() to be available.
Signed-off-by: Simon Glass <sjg@chromium.org>
Driver model currently only operates after relocation is complete. In this
state U-Boot typically has a small amount of memory available. In adding
support for driver model prior to relocation we must try to use as little
memory as possible.
In addition, on some machines the memory has not be inited and/or the CPU
is not running at full speed or the data cache is off. These can reduce
execution performance, so the less initialisation that is done before
relocation the better.
An immediately-obvious improvement is to only initialise drivers which are
actually going to be used before relocation. On many boards the only such
driver is a serial UART, so this provides a very large potential benefit.
Allow drivers to mark themselves as 'pre-reloc' which means that they will
be initialised prior to relocation. This can be done either with a driver
flag or with a 'dm,pre-reloc' device tree property.
To support this, the various dm scanning function now take a 'pre_reloc_only'
parameter which indicates that only drivers marked pre-reloc should be
bound.
Signed-off-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>
If we are to have driver model before relocation we need to support some
way of calling memory allocation routines.
The standard malloc() is pretty complicated:
1. It uses some BSS memory for its state, and BSS is not available before
relocation
2. It supports algorithms for reducing memory fragmentation and improving
performace of free(). Before relocation we could happily just not support
free().
3. It includes about 4KB of code (Thumb 2) and 1KB of data. However since
this has been loaded anyway this is not really a problem.
The simplest way to support pre-relocation malloc() is to reserve an area
of memory and allocate it in increasing blocks as needed. This
implementation does this.
To enable it, you need to define the size of the malloc() pool as described
in the README. It will be located above the pre-relocation stack on
supported architectures.
Note that this implementation is only useful on machines which have some
memory available before dram_init() is called - this includes those that
do no DRAM init (like tegra) and those that do it in SPL (quite a few
boards). Enabling driver model preior to relocation for the rest of the
boards is left for a later exercise.
Signed-off-by: Simon Glass <sjg@chromium.org>
- Fix base address of I2C2 as 0x118100 instead of 0x119000.
- Add definitions for I2C3 & I2C4.
Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
Reviewed-by: York Sun <yorksun@freescale.com>
On some platforms, CSn FTIM2.TCH is set to zero which is invalid,
an invalid hold time makes DUT timing variances, whether it works
or not on luck.
Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
Reviewed-by: York Sun <yorksun@freescale.com>
Internal SRAM has been incresed from 8KB to 16KB for IFC cotroller ver 2.0.
Update the page offset calculation logic to support the same.
Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
Reviewed-by: York Sun <yorksun@freescale.com>
