This patch add support for the Silica Pengwyn board [1]
The board is based on a TI AM3354 CPU [2]
All jumpers removed it will boot from the SDcard, the console is on
UART1 accessible via the FDTI -> USB. The on board NAND flash is
supported and can act as boot medium, depending on jumper settings.
USB Host, USB Device and Ethernet are also provided but untested.
[1]
http://www.silica.com/product/silica-pengwyn-board.html
[2]
http://www.ti.com/product/am3354
Signed-off-by: Lothar Felten <lothar.felten@gmail.com>
[trini: Move CONFIG_BOARD_LATE_INIT into am335x_evm.h, drop unused
spi0_pin_mux from Pengwyn support]
Signed-off-by: Tom Rini <trini@ti.com>
To make managing the environment easier, add DFUARGS to
CONFIG_EXTRA_ENV_SETTINGS. Then we set DFUARGS down in the DFU part of
the file, and include (or not) the NAND part, based on if NAND is set.
Signed-off-by: Tom Rini <trini@ti.com>
This patch adds new CONFIG_NAND_OMAP_ECCSCHEME, replacing other distributed
CONFIG_xx used for selecting NAND ecc-schemes.
This patch aims at solving following issues.
1) Currently ecc-scheme is tied to SoC platform, which prevents user to select
other ecc-schemes also supported in hardware. like;
- most of OMAP3 SoC platforms use only 1-bit Hamming ecc-scheme, inspite
the fact that they can use higher ecc-schemes like 8-bit ecc-schemes with
software based error detection (OMAP_ECC_BCH4_CODE_HW_DETECTION_SW).
- most of AM33xx SoC plaforms use 8-bit BCH ecc-scheme for now, but hardware
supports BCH16 ecc-scheme also.
2) Different platforms use different CONFIG_xx to select ecc-schemes, which
adds confusion for user while migrating platforms.
- *CONFIG_NAND_OMAP_ELM* which enables ELM hardware engine, selects only
8-bit BCH ecc-scheme with h/w based error-correction (OMAP_ECC_BCH8_CODE_HW)
whereas ELM hardware engine supports other ecc-schemes also like; BCH4,
and BCH16 (in future).
- *CONFIG_NAND_OMAP_BCH8* selects 8-bit BCH ecc-scheme with s/w based error
correction (OMAP_ECC_BCH8_CODE_HW_DETECTION_SW).
- *CONFIG_SPL_NAND_SOFTECC* selects 1-bit Hamming ecc-scheme using s/w library
Thus adding new *CONFIG_NAND_OMAP_ECCSCHEME* de-couples ecc-scheme dependency
on SoC platform and NAND driver. And user can select ecc-scheme independently
foreach board.
However, selection some hardware based ecc-schemes (OMAP_ECC_BCHx_CODE_HW) still
depends on presence of ELM hardware engine on SoC. (Refer doc/README.nand)
Signed-off-by: Pekon Gupta <pekon@ti.com>
ELM hardware engine which is used for ECC error detection, is present on all
latest OMAP SoC (like OMAP4xxx, OMAP5xxx, DRA7xxx, AM33xx, AM43xx). Thus ELM
driver should be moved to common drivers/mtd/nand/ folder so that all SoC
having on-chip ELM hardware engine can re-use it.
This patch has following changes:
- mv arch/arm/include/asm/arch-am33xx/elm.h arch/arm/include/asm/omap_elm.h
- mv arch/arm/cpu/armv7/am33xx/elm.c drivers/mtd/nand/omap_elm.c
- update Makefiles
- update #include <asm/elm.h>
- add CONFIG_NAND_OMAP_ELM to compile driver/mtd/nand/omap_elm.c
and include in all board configs using AM33xx SoC platform.
Signed-off-by: Pekon Gupta <pekon@ti.com>
- add omap24xx driver to new multibus/multiadpater support
- adapted all config files, which uses this driver
Tested on the am335x based siemens boards rut, dxr2 and pxm2
posted here:
http://patchwork.ozlabs.org/patch/263211/
Signed-off-by: Heiko Schocher <hs@denx.de>
Tested-by: Tom Rini <trini@ti.com>
Cc: Lars Poeschel <poeschel@lemonage.de>
Cc: Steve Sakoman <sakoman@gmail.com>
Cc: Thomas Weber <weber@corscience.de>
Cc: Tom Rix <Tom.Rix@windriver.com>
Cc: Grazvydas Ignotas <notasas@gmail.com>
Cc: Enric Balletbo i Serra <eballetbo@iseebcn.com>
Cc: Luca Ceresoli <luca.ceresoli@comelit.it>
Cc: Igor Grinberg <grinberg@compulab.co.il>
Cc: Ilya Yanok <yanok@emcraft.com>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Nishanth Menon <nm@ti.com>
Cc: Pali Rohár <pali.rohar@gmail.com>
Cc: Peter Barada <peter.barada@logicpd.com>
Cc: Nagendra T S <nagendra@mistralsolutions.com>
Cc: Michael Jones <michael.jones@matrix-vision.de>
Cc: Raphael Assenat <raph@8d.com>
Acked-by: Igor Grinberg <grinberg@compulab.co.il>
Acked-by: Stefano Babic <sbabic@denx.de>
Some am33xx boards may not use the RTC block for bootcount (as it may
not be wired up for the board) and use some other facility. So add
another symbol for the bootcount driver for the IP block.
Acked-by: Heiko Schocher <hs@denx.de>
Signed-off-by: Tom Rini <trini@ti.com>
Upon further inspection and review and chatting with kernel folks, what
happens here is that what mmcblk# a device gets is based on probe order.
So a system with an SD card inserted with place eMMC on mmcblk1, but
without an SD card, it will be on mmcblk0. So U-boot can only provide a
best guess. In this case, if no SD card is present, we would want to
pass mmcblk0p2 still. If an SD card is present, it woudl be able to
provide a uEnv.txt that would be loaded (even if the kernel is NOT
there) which can still update mmcroot variable.
This reverts commit 827512fb11.
Cc: Robert P. J. Day <rpjday@crashcourse.ca>
Signed-off-by: Tom Rini <trini@ti.com>
If, in CONFIG_BOOTCOMMAND, the environment switches both the mmcdev
and bootpart variables to refer to MMC device 1, it would make sense
that the mmcroot env variable should switch to that device as well.
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
Add a am33xx_spl_board_init (and enable the PMICs) that we may see,
depending on the board we are running on. In all cases, we see if we
can rely on the efuse_sma register to tell us the maximum speed. In the
case of Beaglebone White, we need to make sure we are on AC power, and
are on later than rev A1, and then we can ramp up to the PG1.0 maximum
of 720Mhz. In the case of Beaglebone Black, we are either on PG2.0 that
supports 1GHz or PG2.1. As PG2.0 may or may not have efuse_sma set, we
cannot rely on this probe. In the case of the GP EVM, EVM SK and IDK we
need to rely on the efuse_sma if we are on PG2.1, and the defaults for
PG1.0/2.0.
Signed-off-by: Tom Rini <trini@ti.com>
Somewhere along the line of refactoring the am335x header files, the
kernel image load was lost, so put it back in.
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
We create two new files, include/configs/ti_armv7_common.h for all of
the common IP blocks and related features / commands we share in
virtually all of our platforms. We then create
include/configs/ti_am335x_common.h for everything common to the am335x
SoC leaving just the board specific parts to
include/configs/ti_am335x_common.h.
Signed-off-by: Tom Rini <trini@ti.com>
Adding a new CONFIG_OMAP_COMMON which is included by all boards
that needs to build cpu/armv7/omap-common folder.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Some boards, such as the BeagleBone Black, have an eMMC chip intstead
of NAND. We can use the eMMC boot partition to store the environment,
since it isn't used for anything else. This allows us to have a
configurable environment on those boards.
Signed-off-by: Justin Waters <justin.waters@timesys.com>
The BeagleBone Black can boot from either the MMC card
or eMMC chip on board. We should try both interfaces.
This modification also allows a graceful fallback if
a device exists but boot images are not present on it.
Changes for v2:
* Fix boot partition - it should always show up as mmcblk0p2
* Fix missing FDT load
Signed-off-by: Justin Waters <justin.waters@timesys.com>
Many modern U-Boot ports enable command line editing and
a history buffer. The am335x_evm configuration is fairly
comprehensive as it is, so a few extra kb should not be
noticable, and it adds a very convenient feature.
Signed-off-by: Justin Waters <justin.waters@timesys.com>
Give the user the ability to disable NAND support by defining
CONFIG_NO_NAND. This will allow custom hardware to easily support
this configuration.
Signed-off-by: Justin Waters <justin.waters@timesys.com>
[trini: Make apply on top of other series]
Signed-off-by: Tom Rini <trini@ti.com>
NOR requires that s_init be within the first 4KiB of the image so that
we can perform the rest of the required pinmuxing to talk with the rest
of NOR that we are found on. When NOR_BOOT is set we save our
environment in NOR at 512KiB and a redundant copy at 768KiB. We avoid
using SPL for this case and u-boot.bin is written directly to the start
of NOR.
We enclose the DMM-related parts of arch/arm/cpu/armv7/am33xx/emif4.c
with TI81xx checks as at this time U-Boot does not discard unused
sections in the main build and this code relies on functions specific to
(and only provided in) ti81xx-related code.
Cc: Albert ARIBAUD <albert.u.boot@aribaud.net>
Signed-off-by: Steve Kipisz <s-kipisz2@ti.com>
Signed-off-by: Tom Rini <trini@ti.com>
This patch adds support for the NOR module that attaches
to the memory cape for a Beaglebone board. This does not
add booting support; only support so that you can boot from
SD/MMC and see the NOR module so that it can be programmed.
Signed-off-by: Steve Kipisz <s-kipisz2@ti.com>
[trini: Clean up config changes slightly]
Signed-off-by: Tom Rini <trini@ti.com>
- Style cleanup (# define -> #define)
- Due to ROM issues, redudant loading isn't feasible, so drop.
- Given extra space, increase max size of U-Boot to 512KiB
- Correct env size to match usage (we had not re-defined ENV_SIZE).
- Given extra space, keep env size as 128KiB, add redundant environment.
Reviewed-by: Peter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: Tom Rini <trini@ti.com>
We always set a CONFIG_ENV_IS_...somewhere... so drop the initial define
of NOWHERE.
Reviewed-by: Peter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: Tom Rini <trini@ti.com>
We use CONFIG_CMD_SPL_WRITE_SIZE when reading/writing the args portion
of falcon mode to NAND. Previously it was half the size of the
eraseblock which is too small, increase to eraseblock size.
Signed-off-by: Tom Rini <trini@ti.com>
The previous location used for the "args" portion of falcon mode was too
small to allow for a device tree to be saved there, so move the location
slightly and increase the size. In addition, our previous kernel
location was part of the area we set aside for U-Boot itself, so move it
up a bit higher.
Signed-off-by: Tom Rini <trini@ti.com>
Reviewed-by: Peter Korsgaard <jacmet@sunsite.dk>
Now that we have falcon mode enabled, the partiton numbers for NAND have
changed, and we need to list entries for updating these parts of the
system. While adding falcon mode entires for eMMC (raw), we round up
the limit on U-Boot for ease of math later.
Signed-off-by: Tom Rini <trini@ti.com>
Reviewed-by: Peter Korsgaard <jacmet@sunsite.dk>
In a714321 we add a check at the end of findfdt to make sure we have
updated it from undefined and if not, warn the user. This however
forgot a ';' on the end of the previous last test.
Signed-off-by: Tom Rini <trini@ti.com>
There will need the environment in SPL for reasons other than network
support (in particular, hwconfig contains info for how to set up DDR).
Add a new symbol CONFIG_SPL_ENV_SUPPORT to replace CONFIG_SPL_NET_SUPPORT
for environment in common/Makefile.
Signed-off-by: Ying Zhang <b40530@freescale.com>
Reviewed-by: Tom Rini <trini@ti.com>
Signed-off-by: Andy Fleming <afleming@freescale.com>
In the omap4, omap5 and am335x common files add a check to ensure that the fdtfile is
defined after the findfdt macro has run. If the file is not defined then warn the user that the
dtb file is not defined.
Signed-off-by: Dan Murphy <dmurphy@ti.com>
Reviewed-by: Tom Rini <trini@ti.com>
Jump into full u-boot mode if a 'c' character is received on the uart.
We need to adjust the spl bss/malloc area to not overlap with the
loadaddr of the kernel (sdram + 32k), so move it past u-boot instead.
For raw mmc, we store the kernel parameter area in the free space after
the MBR (if used). For nand, we use the last sector of the partition
reserved for u-boot.
This also enables the spl command in the full u-boot so the kernel
parameter area snapshot can be created.
Signed-off-by: Peter Korsgaard <peter.korsgaard@barco.com>
The location of valid scratch space is dependent on SoC, so move that
there. On OMAP4+ we continue to use SRAM_SCRATCH_SPACE_ADDR. On
am33xx/ti814x we want to use what the ROM defines as "public stack"
which is the area after our defined download image space. Correct the
comment about and location of CONFIG_SPL_TEXT_BASE.
Signed-off-by: Tom Rini <trini@ti.com>
Prior to Sricharan's cleanup of the boot parameter saving code, we
did not make use of NON_SECURE_SRAM_START on am33xx, so it wasn't a
problem that the address was pointing to the middle of our running SPL.
Correct to point to the base location of the download image area.
Increase CONFIG_SPL_TEXT_BASE to account for this scratch area being
used. As part of correcting these tests, make use of the fact that
we've always been placing our stack outside of the download image area
(which is fine, once the downloaded image is run, ROM is gone) so
correct the max size test to be the ROM defined top of the download area
to where we link/load at.
Signed-off-by: Tom Rini <trini@ti.com>
---
Changes in v2:
- Fix typo noted by Peter Korsgaard
The boot parameters passed from SPL to UBOOT
must be saved as a part of uboot's gd data
as early as possible, before we will inadvertently
overwrite it. So adding a arch_cpu_init for the required
Socs to save it.
Signed-off-by: Sricharan R <r.sricharan@ti.com>
[trini: Add igep0033 hunk]
Signed-off-by: Tom Rini <trini@ti.com>
The boot parameters are read from individual variables
assigned for each of them. This been corrected and now
they are stored as a part of the global data 'gd'
structure. So read them from 'gd' instead.
Signed-off-by: Sricharan R <r.sricharan@ti.com>
[trini: Add igep0033 hunk]
Signed-off-by: Tom Rini <trini@ti.com>
As part of a review of a recent patch to add a new AM335x board, Tom
found several duplicate and/or unused #defines.
This patch simply removes them.
The two affected configs have been recompiled to check nothing was
broken (from a compilation point of view !!)
Reported-by: Tom Rini <trini@ti.com>
Signed-off-by: Mark Jackson <mpfj-list@mimc.co.uk>
- Add CONFIG_DFU_NAND, CONFIG_DFU_MMC
- Set dfu_alt_info_nand, dfu_alt_info_emmc and dfu_alt_info_mmc to show
working examples for those cases.
- Increase CONFIG_SYS_MAXARGS due to hush parsing bugs that would
otherwise disallow 'setenv dfu_alt_info ${dfu_alt_info_nand}'.
- Enable CONFIG_FAT_WRITE to allow updating on MMC
Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com>
Signed-off-by: Tom Rini <trini@ti.com>
