Add a function to read the dip_switch on kmcoge5un. If the
switch is set the actual_bank is set to 0 and this SW is
booted.
Signed-off-by: Thomas Herzmann <thomas.herzmann@keymile.com>
Signed-off-by: Holger Brunck <holger.brunck@keymile.com>
Remove config options from boards.cfg and simply add one switch
per board and differ afterwards in km_kirkwood.h between the features.
More boards are upcoming and therefore it's easier to have this
at one place.
Signed-off-by: Holger Brunck <holger.brunck@keymile.com>
Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
cc: Gerlando Falauto <gerlando.falauto@keymile.com>
cc: Prafulla Wadaskar <prafulla@marvell.com>
This adds a first support of the FPGA download for a PCIe FPGA based
on the BOCO2 CPLD.
This takes place in 3 steps, all done accessing the SPICTRL reg of the
BOCO2:
1) start the FPGA config with an access to the FPGA_PROG bit
2) later in the boot sequence, wait for the FPGA_DONE bit to toggle to 1
for the end of the FPGA configuration (with a timeout)
3) reset the FPGA
4) finally remove the access to its config EEPROM from the FPGA so that
the CPU can update the FPGA configuration when the kernel is running
The boards with a PCIe FPGA but without BOCO2 still are supported.
The config option name is CONFIG_KM_FPGA_CONFIG
Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
Signed-off-by: Holger Brunck <holger.brunck@keymile.com>
cc: Gerlando Falauto <gerlando.falauto@keymile.com>
cc: Prafulla Wadaskar <prafulla@marvell.com>
The additional headerfile is unneeded here, we can use the generic
km_kirkwood.h instead. And we can use the better config option
KM_PIGGY4_88E6061 for the specific features for boards with this
design in km_arm.c.
Signed-off-by: Holger Brunck <holger.brunck@keymile.com>
Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
cc: Gerlando Falauto <gerlando.falauto@keymile.com>
cc: Prafulla Wadaskar <prafulla@marvell.com>
Use the generic header km_kirkwood.h and get rid of the
board specific header.
changes for v2: rebased because of changes in other patches
Signed-off-by: Holger Brunck <holger.brunck@keymile.com>
Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
cc: Gerlando Falauto <gerlando.falauto@keymile.com>
cc: Prafulla Wadaskar <prafulla@marvell.com>
For u-boot this board is similar to mgcoge3un. But some differences
are present. We have a different SDRAM on it and therefore a new
SDRAM config file. Additionaly this board has a direct MAC/MAC
connection from the kirkwood to a marvell simple switch without a
phy inbetween, this needs a new configuration for the mvgbe driver.
Signed-off-by: Holger Brunck <holger.brunck@keymile.com>
Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
cc: Gerlando Falauto <gerlando.falauto@keymile.com>
cc: Prafulla Wadaskar <prafulla@marvell.com>
This board is similar to portl2, but it has the u-boot environment
in a SPI NOR flash and not in an i2c eeprom like portl2 have.
Some other details:
- IVM EEPROM is at adress: pca9547:70:9
- PCI is enabled
- PIGGY4 is connected via MV88E6352 simple switch. There is no phy
between the simple switch and the kirkwood.
Signed-off-by: Holger Brunck <holger.brunck@keymile.com>
Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
cc: Gerlando Falauto <gerlando.falauto@keymile.com>
cc: Prafulla Wadaskar <prafulla@marvell.com>
The current configuration selects an incorrect NAND ECC layout,
which causes u-boot to write HW ECC data incorrectly.
This patch selects the right layout.
Signed-off-by: Nikita Kiryanov <nikita@compulab.co.il>
Currently on OMAP4/5 platforms, many kernel drivers are dependent
upon the bootloaders for mux, dpll and clock configurations.
This should not be the case and bootloaders should set only the
minimum required for the uboot functionality and kernel boot.
Note that this is going to break the kernel drivers. But this
is the only way to get things fixed in the kernel.
Signed-off-by: R Sricharan <r.sricharan@ti.com>
We overwrite these weak functions from the kirkwood spi code to
use our own method to be able to switch between the SPI NOR and
the NAND flash. This is needed e.g. to update the u-boot. The former
command do_spi_toggle can therefore be removed. And the usage of
this command is removed from the u-boot update command in the
u-boot environment.
Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
Signed-off-by: Prafulla Wadaskar <prafulla@marvell.com>
cc: Holger Brunck <holger.brunck@keymile.com>
cc: Prafulla Wadaskar <prafulla@marvell.com>
This patch adds support for both the Linkstation Live (LS-CHLv2) and
Linkstation Pro (LS-XHL) by Buffalo.
Signed-off-by: Michael Walle <michael@walle.cc>
Cc: Prafulla Wadaskar <prafulla@marvell.com>
Add new function eth_random_enetaddr() to generate a locally administered
ethernet address.
Signed-off-by: Michael Walle <michael@walle.cc>
Acked-by: Joe Hershberger <joe.hershberger@gmail.com>
Replace rand() with the functions from lib/. The link-local network code
stores its own seed, derived from the MAC address. Thus making it
independent from calls to srand() in other modules.
Signed-off-by: Michael Walle <michael@walle.cc>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
We used to have an arbitrary value, which can be a problem if we have a
u-boot image that is bigger than this value.
This patch is dependant on the whole km/arm series and will be included
in the v3 of the series if there is one.
Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
cc: Holger Brunck <holger.brunck@keymile.com>
cc: Gerlando Falauto <gerlando.falauto@keymile.com>
cc: Prafulla Wadaskar <prafulla@marvell.com>
This is already defined in the generic kirkwood header.
Signed-off-by: Holger Brunck <holger.brunck@keymile.com>
Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
cc: Gerlando Falauto <gerlando.falauto@keymile.com>
cc: Prafulla Wadaskar <prafulla@marvell.com>
This config option sounds like the it is responsible for the
update of the environment, but it is the u-boot update handling.
Therefore we adapt it to a more apropriate naming.
Signed-off-by: Holger Brunck <holger.brunck@keymile.com>
Signed-off-by: Prafulla Wadaskar <prafulla@marvell.com>
Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
cc: Gerlando Falauto <gerlando.falauto@keymile.com>
cc: Prafulla Wadaskar <prafulla@marvell.com>
Some other kirkwood boards from keymile will follow. They will have some
small differences, but we want to use the km_kirkwood.h for all to
distinguish them. This patch a preparation for this.
Signed-off-by: Holger Brunck <holger.brunck@keymile.com>
Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
cc: Gerlando Falauto <gerlando.falauto@keymile.com>
cc: Prafulla Wadaskar <prafulla@marvell.com>
On at91sam platforms, u-boot grew larger than the allocated size in
dataflash, the layout was:
bootstrap 0x00000000
ubootenv 0x00004200
uboot 0x00008400
kernel 0x00042000
fs 0x00252000
u-boot with the defconfig doesn't seem to fit in 0x42000 - 0x8400 =
0x39C00 bytes anymore.
Now, the layout is:
bootstrap 0x00000000
ubootenv 0x00004200
uboot 0x00008400
kernel 0x00084000
fs 0x00294000
Signed-off-by: Alexandre Belloni <alexandre.belloni@piout.net>
Signed-off-by: Andreas Bießmann <andreas.devel@googlemail.com>
According to include/i2c.h:
"/*
* Many boards/controllers/drivers don't support an I2C slave interface so
* provide a default slave address for them for use in common code. A real
* value for CONFIG_SYS_I2C_SLAVE should be defined for any board which does
* support a slave interface.
*/
#ifndef CONFIG_SYS_I2C_SLAVE
#define CONFIG_SYS_I2C_SLAVE 0xfe
#endif
"
As the mxc_i2c driver does not support slave mode, there is no need
to define CONFIG_SYS_I2C_SLAVE in i.MX board file.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
According to include/i2c.h:
"/*
* Many boards/controllers/drivers don't support an I2C slave interface so
* provide a default slave address for them for use in common code. A real
* value for CONFIG_SYS_I2C_SLAVE should be defined for any board which does
* support a slave interface.
*/
#ifndef CONFIG_SYS_I2C_SLAVE
#define CONFIG_SYS_I2C_SLAVE 0xfe
#endif
"
As the mxc_i2c driver does not support slave mode, there is no need
to define CONFIG_SYS_I2C_SLAVE in i.MX board file.
Cc: Jason Liu <r64343@freescale.com>
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
According to include/i2c.h:
"/*
* Many boards/controllers/drivers don't support an I2C slave interface so
* provide a default slave address for them for use in common code. A real
* value for CONFIG_SYS_I2C_SLAVE should be defined for any board which does
* support a slave interface.
*/
#ifndef CONFIG_SYS_I2C_SLAVE
#define CONFIG_SYS_I2C_SLAVE 0xfe
#endif
"
As the mxc_i2c driver does not support slave mode, there is no need
to define CONFIG_SYS_I2C_SLAVE in i.MX board file.
Cc: Jason Liu <r64343@freescale.com>
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
According to include/i2c.h:
"/*
* Many boards/controllers/drivers don't support an I2C slave interface so
* provide a default slave address for them for use in common code. A real
* value for CONFIG_SYS_I2C_SLAVE should be defined for any board which does
* support a slave interface.
*/
#ifndef CONFIG_SYS_I2C_SLAVE
#define CONFIG_SYS_I2C_SLAVE 0xfe
#endif
"
As the mxc_i2c driver does not support slave mode, there is no need
to define CONFIG_SYS_I2C_SLAVE in i.MX board file.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
According to include/i2c.h:
"/*
* Many boards/controllers/drivers don't support an I2C slave interface so
* provide a default slave address for them for use in common code. A real
* value for CONFIG_SYS_I2C_SLAVE should be defined for any board which does
* support a slave interface.
*/
#ifndef CONFIG_SYS_I2C_SLAVE
#define CONFIG_SYS_I2C_SLAVE 0xfe
#endif
"
As the mxc_i2c driver does not support slave mode, there is no need
to define CONFIG_SYS_I2C_SLAVE in i.MX board file.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
According to include/i2c.h:
"/*
* Many boards/controllers/drivers don't support an I2C slave interface so
* provide a default slave address for them for use in common code. A real
* value for CONFIG_SYS_I2C_SLAVE should be defined for any board which does
* support a slave interface.
*/
#ifndef CONFIG_SYS_I2C_SLAVE
#define CONFIG_SYS_I2C_SLAVE 0xfe
#endif
"
As the mxc_i2c driver does not support slave mode, there is no need
to define CONFIG_SYS_I2C_SLAVE in i.MX board file.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Cc: Marek Vasut <marex@denx.de>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Wolfgang Denk <wd@denx.de>
Acked-by: Marek Vasut <marex@denx.de>
Original code was assuming that the fuse revision version for all mx53loco boards
based on Dialog PMIC was the same, which is not the case.
Force the revision of all Dialog-based boards to 0.
This fixes a kernel crash when PMIC is accessed in the 2.6.35 kernel
for Dialog rev E boards.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Reduce the environment size (128KB => 16KB) to improve the environment
operations time (e.g. reading, ecc calculation).
Also, remove the unused CONFIG_SYS_ENV_SECT_SIZE.
Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
We reduce the bootdelay from 10s to 3s to give users a short but usable
window to interrupt the boot process if needed.
Signed-off-by: Tom Rini <trini@ti.com>
- change gpio pin settings:
- gpio pin 6[13] (PLC reset) default value low
- gpio pin 6[0] (TPM reset) default value low
- 4 new GPIO pins
pin i/o name
- 3[9] input Board Type
- 2[7] input HW-ID0
- 2[6] input HW-ID1
- 2[3] input HW-ID2
- read board type and hw id from gpio pins on the enbw_cmc board,
and use board type for setting up different gpio pin settings.
- do not pass "davinci_mmc.use_dma=0" to linux, as MMC now
works with DMA.
- update logbuf support:
store post word in RTC scratch register
- add support for configuring KSZ8864RMN switch through
a config file on u-boot startup. For more infos see:
doc/README.switch_config
Signed-off-by: Heiko Schocher <hs@denx.de>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Tom Rini <tom.rini@gmail.com>
Cc: Christian Riesch <christian.riesch@omicron.at>
Cc: Sandeep Paulraj <s-paulraj@ti.com>
Fix the .dts file USB unit addresses not to duplicate each-other.
Fix the board name string to indicate the vendor is Compulab not NVIDIA.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Acked-by: Igor Grinberg <grinberg@compulab.co.il>
Walk the BIT and BCT to find the ODMDATA word in the
CustomerData field and put it into Scratch20 reg for
use by kernel, etc.
Built all Tegra builds OK; Booted on Seaboard and saw
ODMDATA in PMC scratch20 was the same as the value in my
burn-u-boot.sh file (0x300D8011). NOTE: All flash utilities
will have to specify the odmdata (nvflash --odmdata n) on
the command line or via a cfg file, or built in to their
BCT.
Signed-off-by: Tom Warren <twarren@nvidia.com>
Acked-by: Stephen Warren <swarren@wwwdotorg.org>
The SPI hardware on Seaboard is too broken to use; it is muxed with the
console UART and requires evil interactions between the SPI and UART
drivers to work even partially. The current code in U-Boot is not
sufficient to make this work correctly; auto boot is aborted due to
corruption in the UART RX channel interrupting it.
Instead, move the environment to eMMC, at the end of the second boot
sector. This should not conflict with any other eMMC usage, irrespective
of whether the board boots from SPI, NAND, or eMMC: if U-Boot is stored
in eMMC, it will be stored well below this location. The kernel only
uses the general area of the eMMC once booted, not the boot sectors.
Boards that are derivatives of Seaboard don't have the muxing issue,
and should/could have a separate U-Boot configuration file that does
enable SPI if desired.
Alternatively, the environment could be stored in NAND flash, but we
currently have no driver for that controller.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Cc: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Store the environment in eMMC, at the end of the second boot sector.
This should not conflict with any other eMMC usage: U-Boot is stored
well below this location, and the kernel only uses the general area
of the eMMC once booted, not the boot sectors.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
