u-boot.git/nand_spl, branch v2009.08-rc2

ppc4xx: Canyonlands-NAND-boot: Support 2 Crucial 512MByte SODIMM's

2009-07-30T05:22:18Z

Some Canyonlands boards are equipped with different SODIMM's. This is no problem with the "normal" NOR booting Canyonlands U-Boot, since it automatically detects the SODIMM's via SPD data and correctly configures them. But the NAND booting version is different. Here we only have 4k of image size to completely setup the hardware, including DDR2 setup. So we need to use a fixed DDR2 setup here. This doesn't work for different SODIMM's right now. Currently only this Crucial SODIMM is support: CT6464AC667.8FB (dual ranked) Now some boards are shipped with this SODIMM: CT6464AC667.4FE (single ranked) This patch now supports both SODIMM's by configuring first for the dual ranked DIMM. A quick shows, if this module is really installed. If this test fails, the DDR2 controller is re-configured for the single ranked SODIMM. Tested with those SODIMM's: CT6464AC667.8FB (dual ranked) CT6464AC667.4FE (single ranked) Signed-off-by: Stefan Roese

nand/ppc4xx: Move PPC4xx NAND driver to common NAND driver directory

2009-07-16T22:52:02Z

Signed-off-by: Stefan Roese Cc: Scott Wood Signed-off-by: Scott Wood

nand_spl: Fix cmd_ctrl usage in nand_boot.c.

2009-07-07T22:58:10Z

When adding large page NAND support to this file, I had a misunderstanding about the exact semantics of NAND_CTRL_CHANGE (which isn't documented anywhere I can find) -- it is apparently just a hint to drivers, which aren't required to preserve the old value for subsequent non-"change" invocations. This change makes nand_boot.c no longer assume this. Note that this happened to work by chance with some NAND drivers, which don't preserve the value, but treat 0 equivalently to NAND_CTRL_ALE. I don't have hardware to test this, so any testing is appreciated. Signed-off-by: Scott Wood

nand_spl: read environment early, when booting from NAND using nand_spl

2009-07-07T22:58:07Z

Currently, when booting from NAND using nand_spl, in the beginning the default environment is used until later in boot process the dynamic environment is read out. This way environment variables that must be interpreted early, like the baudrate or "silent", cannot be modified dynamically and remain at their default values. Fix this problem by reading out main and redundand (if used) copies of the environment in the nand_spl code. Signed-off-by: Guennadi Liakhovetski Signed-off-by: Scott Wood

MX31: Add NAND SPL boot support to i.MX31 PDK board.

2009-07-06T19:53:18Z

Signed-off-by: Magnus Lilja

MX31: Add NAND SPL for i.MX31.

2009-06-21T14:18:12Z

This patch adds the NAND SPL framework needed to boot i.MX31 boards from NAND. It has been tested on a i.MX31 PDK board with large page NAND. Small page NANDs should work as well, but this has not been tested. Note: The i.MX31 NFC uses a non-standard layout for large page NANDs, whether this is compatible with a particular setup depends on how the NAND device is programmed by the flash programmer (e.g. JTAG debugger). The patch is based on the work by Maxim Artamonov. Signed-off-by: Maxim Artamonov Signed-off-by: Magnus Lilja

Fix e-mail address of Gary Jennejohn.

2009-05-15T20:11:59Z

Signed-off-by: Detlev Zundel

Fix all linker script to handle all rodata sections

2009-03-20T21:39:12Z

A recent gcc added a new unaligned rodata section called '.rodata.str1.1', which needs to be added the the linker script. Instead of just adding this one section, we use a wildcard ".rodata*" to get all rodata linker section gcc has now and might add in the future. However, '*(.rodata*)' by itself will result in sub-optimal section ordering. The sections will be sorted by object file, which causes extra padding between the unaligned rodata.str.1.1 of one object file and the aligned rodata of the next object file. This is easy to fix by using the SORT_BY_ALIGNMENT command. This patch has not be tested one most of the boards modified. Some boards have a linker script that looks something like this: *(.text) . = ALIGN(16); *(.rodata) *(.rodata.str1.4) *(.eh_frame) I change this to: *(.text) . = ALIGN(16); *(.eh_frame) *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) This means the start of rodata will no longer be 16 bytes aligned. However, the boundary between text and rodata/eh_frame is still aligned to 16 bytes, which is what I think the real purpose of the ALIGN call is. Signed-off-by: Trent Piepho

SIMPC8313 board: fix out of tree building.

2009-03-09T09:51:39Z

Fix typo in makefile which broke out of tree builds. Also use expolicit "rm" instead of "ln -sf" which is known to be unreliable. Signed-off-by: Wolfgang Denk

Merge branch 'master' of git://git.denx.de/u-boot-nand-flash

2009-01-28T22:14:22Z