Add support for SST 4KB sector granularity. Many recent SST flashes, i.e. SST39VF3201B and similar of this family are declared CFI-conformant from SST. They support CFI query, but implement 2 different sector sizes in the same memory: a 64KB sector (they call it "block", std AMD erase cmd=0x30), and a 4KB sector (they call it "sector", erase cmd=0x50). Also, CFI query on these chips, reading from address 0x2dh of cfi query struct, detects a number of secotrs for the 4KB granularity (flinfo shows it). For all other aspects, they are CFI compliant, so, as Linux do, i think it's a good idea to handle these chips in the CFI driver, with a fixup to allow 4KB granularity, as should be expected, instead of 64KB. Signed-off-by: Angelo Dureghello <sysamfw@gmail.com> Signed-off-by: Stefan Rose <sr@denx.de>
Move all the C runtime setup code from every start.S in arch/arm into arch/arm/lib/crt0.S. This covers the code sequence from setting up the initial stack to calling into board_init_r(). Also, rewrite the C runtime setup and make functions board_init_*() and relocate_code() behave according to normal C semantics (no jumping across the C stack any more, etc). Some SPL targets had to be touched because they use start.S explicitly or for some reason; the relevant maintainers and custodians are cc:ed. Signed-off-by: Albert ARIBAUD <albert.u.boot@aribaud.net>
This required manual merging drivers/mtd/nand/Makefile and adding am335x_evm support for CONFIG_SPL_NAND_DRIVERS
In order to mx53 ROM to properly load the U-boot image, its header size should
be multiple of 512 bytes.
This issue was observed with gcc 4.6.2/4.7.3, which caused data aborts:
U-Boot 2013.01-rc2-00172-gf8cfcf1-dirty (Dec 26 2012 - 13:13:28)
Board: MX53 LOCO
I2C: ready
DRAM: 1 GiB
MMC: FSL_SDHC: 0, FSL_SDHC: 1
In: serial
Out: serial
Err: serial
CPU: Freescale i.MX53 family rev2.1 at 1000 MHz
Reset cause: WDOG
Net: FEC
Warning: FEC using MAC address from net device
Hit any key to stop autoboot: 0
data abort
MAYBE you should read doc/README.arm-unaligned-accesses
pc : [<aff72220>] lr : [<aff721fc>]
sp : af565e20 ip : af566918 fp : 00000000
r10: 00000003 r9 : affabb5b r8 : af565f58
r7 : 00000000 r6 : 36747fff r5 : af5668e8 r4 : 36747fff
r3 : af5668ec r2 : af5668eb r1 : 00000000 r0 : af5668e8
Flags: NzcV IRQs off FIQs off Mode SVC_32
Resetting CPU ...
resetting ...
,and this patch fixes it.
Also, even though the ROUND macro is already defined in common.h,
the reason for redefining it in image.h is explained by Stefano Babic:
"I will remark a previous comment - even if including common.h seems a
good idea to avoid duplications, it makes tools like mkimage to depend
on the selected board, because <board>_config must run. Even if this is
not a problem for us u-boot developers, it becomes an issue when these
tools are included in distros (like u-boot-tools in Ubuntu) and cannot
be packaged."
Signed-off-by: Troy Kisky <troy.kisky@boundarydevices.com>
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Looks like the original comment came from a copy and paste from mx31ads.h. It does not have a context on mx51evk anymore, so delete it. Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
It makes more sense to use on-board eMMC to store environments. The boot partition 1 is selected by default. Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
The on-board number of available usdhc devices is something board specific. The patch moves CONFIG_SYS_FSL_USDHC_NUM out of mx6qsabre_common.h and adds usdhc2 and usdhc4 support for mx6qsabresd board. To keep the default mmc device for environment same as before (usdhc3), it moves CONFIG_SYS_MMC_ENV_DEV out of mx6qsabre_common.h and changes it to 1 for mx6qsabresd. Signed-off-by: Shawn Guo <shawn.guo@linaro.org>