Give more flexibility to define configs that can be interpreted by make, e.g. to
define fallback values of configs like in the example below.
Before this change, the config lines:
#define CONFIG_SPL_MAX_SIZE 2048
#define CONFIG_SPL_PAD_TO CONFIG_SPL_MAX_SIZE
would have been changed in autoconfig.mk into:
CONFIG_SPL_MAX_SIZE=2048
CONFIG_SPL_PAD_TO="CONFIG_SPL_MAX_SIZE"
Hence, a make recipe using as an argument to $(OBJCOPY):
--pad-to=$(CONFIG_SPL_PAD_TO)
would have issued:
--pad-to="CONFIG_SPL_MAX_SIZE"
which means nothing for $(OBJCOPY) and makes it fail.
Thanks to this change, the config lines above are changed in autoconfig.mk into:
CONFIG_SPL_MAX_SIZE=2048
CONFIG_SPL_PAD_TO=$(CONFIG_SPL_MAX_SIZE)
Hence, the make recipe above now issues:
--pad-to=2048
as expected from the defined config.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
Reviewed-by: Tom Rini <trini@ti.com>
The purpose of .globl is to export symbols for ld, not to declare external
symbols.
By the way, use the ENTRY() and ENDPROC() macros to define functions rather than
using .global directly.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
Use __image_copy_end instead of __bss_start for the end of the image to
relocate. This is the same as commit 033ca72, but applied to all ARM start.S.
This is a more appropriate symbol naming for an image copy & relocate feature,
and this also saves a useless copy of data put between __image_copy_end and
__bss_start in linker scripts (e.g. relocation information, or MMU
initialization tables used only before jumping to the relocated image).
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
Commit e05e5de7fa made ARM's relocate_code()
return to its caller, but it did not update its declaration accordingly.
Fixing this function declaration fixes dropped C code following calls to
relocate_code().
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
_TEXT_BASE must be set to CONFIG_SPL_TEXT_BASE for generic SPL, and to
CONFIG_SYS_TEXT_BASE for non-SPL builds.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
Reviewed-by: Tom Rini <trini@ti.com>
The syndrome functions should use the page number passed as argument instead of
the page number saved upon NAND_CMD_READ0.
This does not make any difference if the NAND_NO_AUTOINCR option is set, but
otherwise this fixes accesses to the wrong pages.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
Acked-by: Scott Wood <scottwood@freescale.com>
The page number indicated in the debug trace of mxc_nand_read_oob_syndrome() did
not match the page being worked on.
By the way, replace the GCC-specific __FUNCTION__ with __func__.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
Acked-by: Scott Wood <scottwood@freescale.com>
Add support for the Samsung K9LAG08U0M NAND Flash (2-GiB MLC NAND Flash, 2-kiB
pages, 256-kiB blocks, 30-ns R/W cycles, 1 CS) on mx53ard.
eNFC_CLK_ROOT is set up with a cycle time of 37.5 ns (400 MHz / 3 / 5) for this
board, which satisfies the 30-ns NF R/W cycle requirement.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
Tested-by: Fabio Estevam <fabio.estevam@freescale.com>
Add some abstraction to NFC definitions so that some parts of the current code
can also be used for future i.MX5 code.
Clean up a few things by the way.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
Acked-by: Scott Wood <scottwood@freescale.com>
Tested-by: Fabio Estevam <fabio.estevam@freescale.com>
Currently is_16bit_nand() is a per SoC function and it decides the bus nand
width by reading some boot related registers.
This method works when NAND is the boot medium, but does not work if another
boot medium is used. For example: booting from a SD card and then using NAND
to store the environment variables, would lead to the following error:
NAND bus width 16 instead 8 bit
No NAND device found!!!
0 MiB
Use CONFIG_SYS_NAND_BUSWIDTH_16BIT symbol to decide the bus width.
If it is defined in the board file, then consider 16-bit NAND bus-width,
otherwise assume 8-bit NAND is used.
This also aligns with Documentation/devicetree/bindings/mtd/nand.txt, which
states:
nand-bus-width : 8 or 16 bus width if not present 8
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Acked-by: Scott Wood <scottwood@freescale.com>
Reviewed-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
Introduce CONFIG_SYS_NAND_BUSWIDTH_16BIT option so that other NAND controller
drivers could use it when a 16-bit NAND is deployed.
drivers/mtd/nand/ndfc has CONFIG_SYS_NDFC_16BIT, so just rename it, so that
other NAND drivers could reuse the same symbol.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Acked-by: Scott Wood <scottwood@freescale.com>
Reviewed-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
The omap5_uevm platform has eMMC, and it makes sense to say that our
default env storage shall reside there. Other platforms may not, so
move this choice to the EVM config. In addition, we should provide some
way to partition the flash for later usage, so take advantage of the GPT
partition table support code and allow that to be setup with some
reasonable defaults.
Cc: Sricharan R <r.sricharan@ti.com>
Signed-off-by: Tom Rini <trini@ti.com>
In the case of booting from certain peripherals, such as UART, we must
not see what the device descriptor says for RAW or FAT mode because in
addition to being nonsensical, it leads to a hang. This is why we have
a test currently for the boot mode being within range. The problem
however is that on some platforms we get MMC2_2 as the boot mode and not
the defined value for MMC2, and in others we get the value for MMC2_2.
This is required to fix eMMC booting on omap5_uevm.
Tested on am335x_evm (UART, NAND, SD), omap3_beagle (NAND, SD on
classic, SD only on xM rev C5) and omap5_uevm (SD, eMMC).
Signed-off-by: Tom Rini <trini@ti.com>
Commit "8602114 omap: emif: configure emif only when required"
breaks SDRAM_AUTO_DETECTION.
The issue is dmm_init() depends on emif_sizes[](SDRAM Auto detection)
done in do_sdram_init(). The above commit moves dmm_init() above
do_sdram_init() because of which dmm_init() uses uninitialized
emif_sizes[].
So instead of using global emif_sizes[], get sdram details locally
and calculate emif sizes.
Reported-by: Michael Cashwell <mboards@prograde.net>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
V2 fixes line wrap issue of the patch itself.
UART3 was enabled twice instead of UART4.
One more cosmetic change in a comment on EMIF clock.
Signed-off-by: Lubomir Popov <lpopov@mm-sol.com>
Reviewed-by: R Sricharan <r.sricharan@ti.com>
We shall remove these OMAP4/5-specific options in v2013.07, barring
insufficient progress on the kernel side.
Cc: Sricharan R <r.sricharan@ti.com>
Signed-off-by: Tom Rini <trini@ti.com>
So with OMAP added to multi platform kernel,
the uImage no more contains a valid load address.
With the uboot already supporting zImage,
change the default boot command to bootz
instead.
Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Sricharan R <r.sricharan@ti.com>
Tested-by: Nishanth Menon <nm@ti.com>
Now with kernel moving to all device tree, the default
boot command is changed to pass the device tree blob.
Also, adding the findfdt command to get the dt-blob
based on the board.
Thanks to Tom Rini <trini@ti.com> for suggesting this.
Signed-off-by: Sricharan R <r.sricharan@ti.com>
For production systems it is better to use script images since
they are protected by checksums and carry valuable information
like name and timestamp. Also, you can't validate the content
passed to env import.
But for development, it is easier to use the env import command and
plain text files instead of script-images.
Since both OMAP5evm/uevm boards are used primarily for development,
we allow U-Boot to load env var from a text file in case that an
boot.scr script-image is not present.
The variable uenvcmd (if existent) will be executed (using run) after
uEnv.txt was loaded. If uenvcmd doesn't exist the default boot sequence
will be started.
Inspired by commit: d70f54808d
(omap4: allow the use of a plain text env file instead boot scripts)
Signed-off-by: Sricharan R <r.sricharan@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Tested-by: Sricharan R <r.sricharan@ti.com>
While booting with dt blob, if fdt_high is not set to
0xffffffff, the dt blob gets relocated to a high ram address,
which the kernel is not able to use without HIGHMEM.
So set it to 0xffffffff to avoid the issue.
Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Sricharan R <r.sricharan@ti.com>
Tested-by: Nishanth Menon <nm@ti.com>
The omap5-uevm is the reference board name for OMAP5 soc
based platform. So rename it accordingly.
Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Sricharan R <r.sricharan@ti.com>
Tested-by: Nishanth Menon <nm@ti.com>
The function get_timer() should return time in ms and CONFIG_SYS_HZ
should be set to 1000 by default. Fix both of these items.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
The omap2420-h4 board is using a RAM based address as the linker
location for code. This is causing several problems when attempting
to run the latest u-boot code base on this board from flash. Update
the default linker location for code to be in NOR flash. Please note
that OMAP maps the NOR flash to address 0x08000000 by default and so
use this as the default address for the NOR flash.
Also remove legacy code that attempts to calculate where in flash the
sdata structure, that holds the memory interface configuration data,
is located. By changing the default linker location for code to flash
this is no longer necessary.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
The size of the DRAM for the omap2420-h4 board is getting setup in the
dram_init() function. However, for the current u-boot release this is
too late and needs to be done in dram_init_banksize(). Therefore, add
a dram_init_banksize() function for the omap2420-h4 board and setup the
DRAM size there.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Signed-off-by: Andreas Bießmann <andreas.devel@googlemail.com>
Cc: Tom Rini <trini@ti.com>
Cc: Thomas Weber <weber@corscience.de>
Cc: Ilya Yanok <ilya.yanok@cogentembedded.com>
Cc: Scott Wood <scottwood@freescale.com>
The kernel states:
---8<---
The OMAP3 GPMC hardware BCH engine computes remainder polynomials, it does not
provide automatic error location and correction: this step is implemented using
the BCH library.
--->8---
And we do so in u-boot.
This implementation uses the same layout for BCH8 but it is fix. The current
provided layout does only work with 64 Byte OOB.
Signed-off-by: Andreas Bießmann <andreas.devel@googlemail.com>
Cc: Tom Rini <trini@ti.com>
Cc: Ilya Yanok <ilya.yanok@cogentembedded.com>
Cc: Scott Wood <scottwood@freescale.com>
Cc: Mansoor Ahamed <mansoor.ahamed@ti.com>
Cc: Thomas Weber <thomas.weber.linux@googlemail.com>
With uppcoming BCH support on OMAP devices we need to decide between differnt
algorithms when switching the ECC engine. Currently we support 1-bit hammign
and 8-bit BCH on HW backend.
In order to switch between differnet ECC algorithms we need to change the
interface of omap_nand_switch_ecc() also.
Signed-off-by: Andreas Bießmann <andreas.devel@googlemail.com>
Cc: Tom Rini <trini@ti.com>
Cc: Thomas Weber <thomas.weber.linux@googlemail.com>
This patch adds BCH8 ooblayout for NAND as provided by
0e618ef0a6a33cf7ef96c2c824402088dd8ef48c in linux kernel. This Layout is
currently only provided for 64 byte OOB.
Signed-off-by: Andreas Bießmann <andreas.devel@googlemail.com>
Cc: Tom Rini <trini@ti.com>
Cc: Ilya Yanok <ilya.yanok@cogentembedded.com>
Cc: Scott Wood <scottwood@freescale.com>
Reviewed-by: Tom Rini <trini@ti.com>
arch/arm/include/asm/arch-am33xx/omap_gpmc.h and
arch/arm/include/asm/arch-omap3/omap_gpmc.h are almost the same, consolidate
the common parts into a new header.
Introduce a new asm/omap_gpmc.h which defines the command part and pulls in
the architecture specific one.
Signed-off-by: Andreas Bießmann <andreas.devel@googlemail.com>
Cc: Tom Rini <trini@ti.com>
Reviewed-by: Tom Rini <trini@ti.com>
This patch adds the BCH result registers to register mapping for OMAP3 gpmc.
Signed-off-by: Andreas Bießmann <andreas.devel@googlemail.com>
Cc: Tom Rini <trini@ti.com>
Cc: Ilya Yanok <ilya.yanok@cogentembedded.com>
Cc: Scott Wood <scottwood@freescale.com>
Reviewed-by: Tom Rini <trini@ti.com>
Flush UART3 xmit on enable if TEMT is broken
On some OMAP3 devices when UART3 is configured for boot mode before SPL starts
only THRE bit is set. We have to empty the transmitter before initialization
starts. This patch avoids the use of CONFIG_SYS_NS16550_BROKEN_TEMT.
Signed-off-by: Manfred Huber <man.huber@arcor.de>
Tested-by: Javier Martinez Canillas <javier@dowhile0.org>
Tested-by: Andreas Bießmann <andreas.devel@googlemail.com>
We must not assume ROM has enabled the clock for MMC1.
Reported-by: Koen Kooi <koen@dominion.thruhere.net>
Signed-off-by: Tom Rini <trini@ti.com>
Acked-by: Peter Korsgaard <jacmet@sunsite.dk>
This is done already for am335x in
59dcf970d1 and also applies for pcm051.
It powers down the IO receiver when not performing read which helps
reducing the overall power consuption in low power states
(suspend/standby).
Signed-off-by: Lars Poeschel <poeschel@lemonage.de>
Do not config MUSB to highspeed mode if CONFIG_USB_GADGET_DUALSPEED
is not set, in which case Ether gadget only operates in fullspeed.
Reviewed-by: Tom Rini <trini@ti.com>
Signed-off-by: Bin Liu <b-liu@ti.com>
On TI AM335x devices, MUSB has bulk split/combine feature enabled
in the ConfigData register, but the current MUSB driver does not
support it yet. Therefore, disable the feature for now, until the
driver adds the support.
One usecase which is broken because of this feature is that Ether
gadget stops working in Fullspeed mode (by un-defining
CONFIG_USB_GADGET_DUALSPEED)
After desabled this feature, MUSB driver send packets in proper size
(no more than 64 bytes) in Fullspeed mode.
This has been validated with Ether gadget in Fullspeed mode on AM335x
EVM.
Signed-off-by: Bin Liu <b-liu@ti.com>
Atmel change to new logo since 2012. This patch update the logo to new one.
Signed-off-by: Josh Wu <josh.wu@atmel.com>
Signed-off-by: Andreas Bießmann <andreas.devel@googlemail.com>
Reviewing the ECSPI reset handling shows two issues:
1. For the enable/reset bit (MXC_CSPICTRL_EN) in the control reg
(ECSPIx_CONGREG) the i.MX6 technical reference manual states:
-- cut --
ECSPIx_CONREG[0]: EN: Writing zero to this bit disables the block
and resets the internal logic with the exception of the ECSPI_CONREG.
-- cut --
Note the exception mentioned: The CONREG itself isn't reset.
Fix this by manually writing the reset value 0 to the whole register.
This sets the EN bit to zero, too (i.e. includes the old
~MXC_CSPICTRL_EN).
2. We want to reset the whole SPI block here. So it makes no sense
to first read the old value of the CONREG and write it back, later.
This will give us the old (historic/random) value of the CONREG back.
And doesn't reset the CONREG.
To get a clean CONREG after the reset of the block, too, don't use
the old (historic/random) value of the CONREG while doing the reset.
And read the clean CONREG after the reset.
This was found while working on a SPI boot device where the i.MX6 boot
ROM has already initialized the SPI block. The initialization by the
boot ROM might be different to what the U-Boot driver wants to configure.
I.e. we need a clean reset of SPI block, including the CONREG.
Signed-off-by: Dirk Behme <dirk.behme@de.bosch.com>
CC: Stefano Babic <sbabic@denx.de>
CC: Fabio Estevam <fabio.estevam@freescale.com>
Apparently, CONFIG_SYS_HZ must be 1000. Change this, and fix the timer
driver to conform to this.
Have the timer implementation export a custom API get_timer_us() for use
by the BCM2835 MMC API, which needs us resolution for a HW workaround.
Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
board/freescale/mx6qsabrelite/README explain a procedure to
update the SPI-NOR on the SabreLite board without Freescale
manufacturing tool but following this procedure leads to both
"sf erase" and "sf write" failing on a mx6qsabrelite board:
MX6QSABRELITE U-Boot > sf probe 1
MX6QSABRELITE U-Boot > sf erase 0 0x40000
SPI flash erase failed
MX6QSABRELITE U-Boot > sf write 0x10800000 0 0x40000
SPI flash write failed
This is because the chip-select 1 is wrong and the correct
value is 0x7300.
Since commit c1173bd0 ("sf command: allow default bus and chip selects")
the chip-select and bus arguments for the sf probe command are optional
so let's just remove it and use "sf probe" instead.
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
CONFIG_SYS_FSL_USDHC_NUM is not used for wandboard.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Acked-by: Otavio Salvador <otavio@ossystems.com.br>
Benoît Thébaudeau