| Age | Commit message (Collapse) | Author |
|---|
|
Also sync with kernel OneNAND codes
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Scott Wood <scottwood@freescale.com>
|
|
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
|
|
onenand_print_device_info():
- Now returns a string to be placed in mtd->name,
rather than calling printf.
- Remove verbose parameter as it becomes useless.
Signed-off-by: Fathi Boudra <fabo@debian.org>
Signed-off-by: Scott Wood <scottwood@freescale.com>
|
|
While locally preparing some U-Boot patches for ARM based OMAP3 boards, some
using OneNAND and some using NAND, we found some differences in OneNAND and
NAND command address handling.
As this might confuse users (it already confused us), we like to align OneNAND
and NAND address handling.
The issue is that cmd_onenand.c subtracts the onenand base address from the
addresses you type into the u-boot command line so, unlike nand, you can't
use addresses relative to the start of the onenand part e.g. this won't work:
onenand read 82000000 280000 400000
you have to use:
onenand read 82000000 20280000 400000
Looking at recent git, the only board currently using OneNAND is Apollon, and
for this the OneNAND base address is 0 (apollon.h)
#define CFG_ONENAND_BASE 0x00000000
so patch below won't break any existing boards and will align OneNAND and NAND
handling on boards where OneNAND base address is != 0.
Signed-off-by: Steve Sakoman <sakoman@gmail.com>
Signed-off-by: Manikandan Pillai <mani.pillai@ti.com>
Signed-off-by: Dirk Behme <dirk.behme@gmail.com>
|
|
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
|
|
It mis-calculates the block address.
Also fix DECLARE_GLOBAL_DATA_PTR in env_onenand.
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
|
|
[PATCH 3/3] OneNAND support (take #2)
OneNAND support at U-Boot
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
|
