Commit f62fb99941c6 fixed handling of all rodata sections by using a
wildcard combined with calls to ld's builtin functions SORT_BY_ALIGNMENT()
and SORT_BY_NAME().  Unfortunately these functions were only
introduced with biunutils version 2.16, so the modification broke
building with all tool chains using older binutils.

This patch makes it work again.  This is done by omitting the use of
these functions for such old tool chains.  This will result in
slightly larger target binaries, as the rodata sections are no longer
in optimal order alignment-wise which reauls in unused gaps, but the
effect was found to be insignificant - especially compared to the fact
that you cannot build U-Boot at all in the current state.

As ld seems to have no support for conditionals we run the linker
script through the C preprocessor which can be easily used to remove
the unwanted function calls.

Note that the C preprocessor must be run with the "-ansi" (or a
"-std=") option to make sure all the system-specific predefined
macros outside the reserved namespace are suppressed. Otherise, cpp
might for example substitute "powerpc" to "1", thus corrupting for
example "OUTPUT_ARCH(powerpc)" etc.

Signed-off-by: Wolfgang Denk <wd@denx.de>
Cc: Mike Frysinger <vapier@gentoo.org>

The code copy data from NAND flash block by block, so when
the data length isn't a whole-number multiple of the block
size, it will overlap the rest space.

Signed-off-by: Mingkai Hu <Mingkai.hu@freescale.com>
Signed-off-by: Scott Wood <scottwood@freescale.com>

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 <sr@denx.de>

Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Scott Wood <scottwood@freescale.com>
Signed-off-by: Scott Wood <scottwood@freescale.com>

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 <scottwood@freescale.com>

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 <lg@denx.de>
Signed-off-by: Scott Wood <scottwood@freescale.com>

Signed-off-by: Magnus Lilja <lilja.magnus@gmail.com>

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 <scn1874@yandex.ru>
Signed-off-by: Magnus Lilja <lilja.magnus@gmail.com>

Signed-off-by: Detlev Zundel <dzu@denx.de>

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 <xyzzy@speakeasy.org>