The board supports following features:
- Boot media support: SD card/e.MMC/SPI flash,
- Support LCD display (optional, disabled by default),
- Support ethernet,
- Support USB mass storage.
Signed-off-by: Wenyou Yang <wenyou.yang@atmel.com>
[fix checkpatch warnings]
Signed-off-by: Andreas Bießmann <andreas.devel@googlemail.com>
There are already Kconfig options for SPI flash drivers, but we
have not moved them from config.h to defconfig files. This commit
does this in a batch.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
There are already Kconfig options for SPI drivers, but we
have not moved them from config.h to defconfig files. This
commit does this in a batch.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Add initial sun8i H3 support, only uart + mmc are supported for now.
Signed-off-by: Jens Kuske <jenskuske@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
The DFU protocol implementation in U-Boot is much faster than the
FEL protocol implementation in the boot ROM on Allwinner devices.
Using DFU instead of FEL improves the USB transfer speed from
500-900 KB/s to 3.2-3.7 MB/s. This is particularly useful for
reducing the time needed for booting systems with large initrd
images.
FEL is still useful for loading the U-Boot bootloader and a boot
script, which may then activate DFU in the following way:
setenv dfu_alt_info ${dfu_alt_info_ram}
dfu 0 ram 0
bootm ${kernel_addr_r} ${ramdisk_addr_r} ${fdt_addr_r}
The rest of the files can be transferred to the device using the
"dfu-util" tool.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Add support for storing the environment in CFI NOR flash on Juno and FVP
models.
I also removed some config values that are not used by CFI flash parts.
Juno has 1 flash part with 259 sectors. The first 255 sectors are
0x40000 (256kb) and are followed by 4 sectors of 0x10000 (64KB).
FVP models simulate a 64MB NOR flash part at base address 0x0FFC0000.
This part has 256 x 256kb sectors. We use the last sector to store the
environment.
To save the NOR flash to a file, the following parameters should be
passed to the model:
-C bp.flashloader1.fname=${FILENAME}
-C bp.flashloader1.fnameWrite=${FILENAME}
Foundation models don't simulate the NOR flash, but having NOR support
in the u-boot binary does not harm: attempting to write to the NOR will
fail gracefully.
Signed-off-by: Ryan Harkin <ryan.harkin@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
This patch allows vexpress64 targets to be compiled when
CONFIG_SYS_FLASH_CFI is enabled.
I considered using #warning instead of #error, but this just clutters up
the build output and hides real warnings.
Without this patch, you see errors during compilation like this:
include/configs/vexpress_aemv8a.h:42:2: error: #error "Unknown board
variant"
#error "Unknown board variant"
include/configs/vexpress_aemv8a.h:115:2: error: #error "Unknown board
variant"
#error "Unknown board variant"
include/configs/vexpress_aemv8a.h:280:2: error: #error "Unknown board
variant"
#error "Unknown board variant"
make[1]: *** [tools/envcrc.o] Error 1
make: *** [tools] Error 2
In file included from include/config.h:5:0,
from tools/envcrc.c:19:
Signed-off-by: Ryan Harkin <ryan.harkin@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
This patch makes the 2nd DRAM bank available on Juno only and not on
other vexpress64 targets, eg. the FVP models.
The commit below added a 2nd bank of NOR flash for Juno, but also for
all vexpress64 targets:
commit 2d0cee1ca2
Author: Liviu Dudau <Liviu.Dudau@foss.arm.com>
Date: Mon Oct 19 11:08:31 2015 +0100
vexpress64: Juno: Declare all 8GB of RAM and make them visible to the kernel.
Juno comes with 8GB RAM, but U-Boot only passes 2GB to the kernel.
Declare a secondary memory bank and set the sizes correctly.
Signed-off-by: Liviu Dudau <Liviu.Dudau@foss.arm.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Ryan Harkin <ryan.harkin@linaro.org>
Tested-by: Ryan Harkin <ryan.harkin@linaro.org>
Unfortunately, I only fully tested on Juno R0, R1 and the FVP Foundation
model. Whilst FVP Base AEMV8 models run U-Boot OK, they fail to boot
the kernel.
Signed-off-by: Ryan Harkin <ryan.harkin@linaro.org>
Acked-by: Liviu Dudau <liviu.dudau@foss.arm.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
This option only complicates the code unnecessarily, just use
CONFIG_SYS_DEF_EEPROM_ADDR as the default address if there are
only five arguments to eeprom {read/write} if this is defined.
If CONFIG_SYS_DEF_EEPROM_ADDR is not defined, we mandate all
six arguments.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
Cc: Heiko Schocher <hs@denx.de>
Reviewed-by: Heiko Schocher <hs@denx.de>
The NOR flash on Keystone 2 evms has a u-boot-spl partition size of
0x80000.
Currently burn_uboot_spi will erase 0x100000 from the spi NOR which will
cause a partial erase of the misc partition.
Fix this by correcting the erase size.
Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
Change to ns16550 uart for 10m50 devboard based on a new
Altera release.
Signed-off-by: Thomas Chou <thomas@wytron.com.tw>
Reviewed-by: Tom Rini <trini@konsulko.com>
Acked-by: Simon Glass <sjg@chromium.org>
Zap CONFIG_NS16550_SERIAL, as the unification of ns16550 drivers
is completed.
Signed-off-by: Thomas Chou <thomas@wytron.com.tw>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Unify serial_omap, and use the generic binding.
Signed-off-by: Thomas Chou <thomas@wytron.com.tw>
Reviewed-by: Tom Rini <trini@konsulko.com>
Acked-by: Simon Glass <sjg@chromium.org>
Unify serial_tegra, and use the generic binding.
Signed-off-by: Thomas Chou <thomas@wytron.com.tw>
Reviewed-by: Tom Rini <trini@konsulko.com>
Acked-by: Simon Glass <sjg@chromium.org>
Unify serial_dw, and use the generic binding.
Signed-off-by: Thomas Chou <thomas@wytron.com.tw>
Reviewed-by: Tom Rini <trini@konsulko.com>
Acked-by: Simon Glass <sjg@chromium.org>
Unify serial_keystone, and use the generic binding.
Signed-off-by: Thomas Chou <thomas@wytron.com.tw>
Reviewed-by: Tom Rini <trini@konsulko.com>
Acked-by: Simon Glass <sjg@chromium.org>
Allow console recording so that tests can use it. Also allow the console
output to be suppressed, to reduce test output 'noise'.
Signed-off-by: Simon Glass <sjg@chromium.org>
Some boards have an i8042 device. Enable the driver for all x86 boards, and
add a device tree node for those which may have this keyboard.
Also adjust the configuration so that i8042 is always separate from the VGA,
and rename the stdin driver accordingly. With this commit the keyboard will
not work, but it is fixed in the next commit.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Add a sandbox timer which get time from host os and a basic
test.
Signed-off-by: Thomas Chou <thomas@wytron.com.tw>
Reviewed-by: Simon Glass <sjg@chromium.org>
CONFIG_CONSOLE_CURSOR, CONFIG_SYS_CONSOLE_BLINK_COUNT and
CONFIG_CONSOLE_TIME are not used by any board. The implementation is not
great and stands in the way of a refactor of i8042. Drop these for now.
They can be re-introduced quite easily later, perhaps with driver-model
real-time-clock (RTC) support.
When reintroducing, it might be useful to make a few changes:
- Blink time would be more useful than blink count
- The confusing #ifdefs should be avoided
- The time functions should support driver model
- It would be best keyed off console_tstc() or some similar idle loop
rather than a particular input driver (i8042 in this case)
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
zc1571 with silicon can operate on 200MHz maximum frequency. Setup this
frequency by default and fix setting for ep108.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
OF_CONTROL is enabled by default for all Zynq boards.
The difference between two boot images is done by OF_SEPARATE
or OF_EMBED macros.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
This board uses the same CPU (8309) as VECT1. The memory however is
different since it has NAND Flash, the NOR Flash partitioning is
different and of course the FPGAs as well.
Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
Signed-off-by: Christoph Dietrich <christoph.dietrich@keymile.com>
It should be after the u-boot reserved sectors and before the env
sectors, since the solution used for kmvect1 (tell the linker to put the
firmware into the u-boot produced binary, at the end of the area) should
be the exception.
The #define is only "conditional" so that we can still support kmvect1.
Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
The hardcoded value are bad, since the address could change between
different boards.
Furthermore, the relevant #defines are set only if #undefined here, so
that they can be changed by some boards if required.
Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
The ODT parameters for km8360 set the ODT_WR_ACS bit in u-boot KM-2011.09
that is used in the release bootpackage for kmcoge5ne. During the
transition from the kmeter1 to km8360 this was changed to
ODT_RD_ONLY_CURRENT, which is uncorrect and causes faulty RAM accesses at
low temperatures.
This is now changed to ODT_WR_ONLY_CURRENT which is the equivalent of
ODT_WR_ACS.
Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
For consistency with all the other km83xx plaforms, this should also be
defined for km8309. The same settings as for km8321 are taken.
Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
On the km8321 boards is CONFIG_SYS_DDRCDR not defined, which leads to
the DDRCDR not being configured at startup and still containing the
reset value.
The required settings for our km8321 hardware designs are different than
the reset value and must be set with CONFIG_SYS_DDRCDR, that is used
by mpc83xx's cpu_init_f function at early CPU initialization.
The important settings are the DDR2 internal voltage level and the
half-strength "drivers".
In our case where the DRAM chips are soldered on board and the routing
for these signals under control, half-strength is sufficient as a few
measurements done in the lasts have shown. Since all the hardware
qualification tests have been performed with half strength, the nominal
strength settings are removed in favor of the default reset half
strength settings.
Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
We use the same settings for open firmware defines on all our powerpc
targets, so move them from the CPU specific headers to the common
powerpc header.
Signed-off-by: Holger Brunck <holger.brunck@keymile.com>
Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
128kByte and 3,986MB may be in the future too little for kernel the fdt
blob respectively the kernel image. So increase the reserved areas here,
we have the space for this.
Signed-off-by: Holger Brunck <holger.brunck@keymile.com>
Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
This board is similar to TUXX1, but it has differend FPGAs.
Signed-off-by: Christoph Dietrich <christoph.dietrich@keymile.com>
Signed-off-by: Andreas Huber <andreas.huber@keymile.com>
Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
If a DTB is found with cramfsls, the bootscript continues as expected.
If none is found, the cramfsloadfdt and boot subbootcmds are updated to
not load the DTB from cramfs and not pass it to the kernel. The kernel
thus must have an appended DTB otherwise the boot will fail.
This is required for the km_kirkwood boards that must support .esw where
the DTB sometimes is appended (for backwards compatibility) and sometimes
is passed correctly (as we do now for all newer boards).
Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
To prevent u-boot to stop accidently e.g. due to line noise on the
serial line, we now use the option CONFIG_AUTOBOOT_KEYED. We choose the
<SPACE> key for this.
Signed-off-by: Holger Brunck <holger.brunck@keymile.com>
Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
KM_ENV_BUS was used for nothing else than an direct assignment to
CONFIG_I2C_ENV_EEPROM_BUS. To avoid this, directly use
CONFIG_I2C_ENV_EEPROM_BUS instead.
Patchwork: http://patchwork.ozlabs.org/patch/399411/
Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
SeeedStudio BeagleBone Green (BBG) is clone of the BeagleBone Black (BBB) minus
the HDMI port and addition of two Grove connectors (i2c2 and usart2).
This board can be identified by the 1A value after A335BNLT (BBB) in the at24 eeprom:
1A: [aa 55 33 ee 41 33 33 35 42 4e 4c 54 1a 00 00 00 |.U3.A335BNLT....|]
http://beagleboard.org/greenhttp://www.seeedstudio.com/wiki/Beaglebone_green
In Mainline Kernel as of:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=79a4e64c679d8a0b1037da174e4aea578c80c4e6
Patch tested on BeagleBone Black (rev C) and BeagleBone Green (production model)
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
CC: Tom Rini <trini@konsulko.com>
CC: Jason Kridner <jkridner@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Use spl alternate boot device feature to define fallback to
the main boot device as it is defined by hardware.
Signed-off-by: Nikita Kiryanov <nikita@compulab.co.il>
Cc: Igor Grinberg <grinberg@compulab.co.il>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Tom Rini <trini@konsulko.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Stefano Babic <sbabic@denx.de>
BeagleBoard X15 (http://beagleboard.org/x15) support in u-boot does
actually support two different platform configuration offered by
TI. In addition to BeagleBoard X15, it also supports the TMDXEVM5728
(or more commonly known as AM5728-evm).
Information about the TI AM57xx EVM can be found here
http://www.ti.com/tool/tmdxevm5728
The EVM configuration is 1-1 compatible with BeagleBoard X15 with the
additional support for mPCIe, mSATA, LCD, touchscreen, Camera, push
button and TI's wlink8 offering.
Hence, we rename the beagle_x15 directory to am57xx to support TI
EVMs that use the AM57xx processor. By doing this we have common code
reuse. This sets the stage to have a common u-boot image solution for
multiple TI EVMs such as that already done for am335x and am437x. This
sets the stage for upcoming multiple TI EVMs that share the same code
base.
NOTE: Commit eae7ae1853 ("am437x: Add am57xx_evm_defconfig using
CONFIG_DM") introduced DT support for beagle_x15 under am57xx_evm
platform name. However, this ignored the potential confusion arising for
users as a result. To prevent this, existing beagle_x15_defconfig is
renamed as am57xx_evm_nodt_defconfig to denote that this is the "non
device tree" configuration for the same platform. We still retain
am57xx-beagle-x15.dts at this point, since we just require the common
minimum dts.
As a result of this change, users should expect changes in build
procedures('make am57xx_evm_nodt_defconfig' instead of 'make
beagle_x15_defconfig'). Hopefully, this would be a one-time change.
Signed-off-by: Steve Kipisz <s-kipisz2@ti.com>
Signed-off-by: Schuyler Patton <spatton@ti.com>
Acked-by: Nishanth Menon <nm@ti.com>
Acked-by: Lokesh Vutla <lokeshvutla@ti.com>
