diff options
author | Stephen Warren <swarren@nvidia.com> | 2012-05-24 11:38:39 +0000 |
---|---|---|
committer | Albert ARIBAUD <albert.u.boot@aribaud.net> | 2012-07-07 14:07:21 +0200 |
commit | f9f2f12e2cace3685ea0dbb6b6d78789fb75f043 (patch) | |
tree | fc78d2768741b6f81c7d57fb734f36b95f230fcd /include/onenand_uboot.h | |
parent | e87c2bda9c45bcfcc8239f6052d6fa9aec7351d6 (diff) | |
download | u-boot-imx-f9f2f12e2cace3685ea0dbb6b6d78789fb75f043.zip u-boot-imx-f9f2f12e2cace3685ea0dbb6b6d78789fb75f043.tar.gz u-boot-imx-f9f2f12e2cace3685ea0dbb6b6d78789fb75f043.tar.bz2 |
tegra: seaboard: disable SPI, move environment to eMMC
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>
Diffstat (limited to 'include/onenand_uboot.h')
0 files changed, 0 insertions, 0 deletions