[U-Boot-Users] [PATCH] NAND_SPL: Remove initdram() call from nand_boot()
This patch removes the SDRAM initilization call initdram() from nand_boot(). This is done mainly because I experienced problems with some boards like Kilauea (405EX), which don't have internal SRAM (OCM) and relocation needs to be done to SDRAM before the NAND controller can get accessed. When initdram() is called later on in nand_boot(), this can lead to problems with variables in the bss sections like nand_ecc_pos[].
Signed-off-by: Stefan Roese sr@denx.de --- nand_spl/nand_boot.c | 11 +++++------ 1 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/nand_spl/nand_boot.c b/nand_spl/nand_boot.c index bc57725..563a80b 100644 --- a/nand_spl/nand_boot.c +++ b/nand_spl/nand_boot.c @@ -221,20 +221,19 @@ static int nand_load(struct mtd_info *mtd, int offs, int uboot_size, uchar *dst) return 0; }
+/* + * The main entry for NAND booting. It's necessary that SDRAM is already + * configured and available since this code loads the main U-Boot image + * from NAND into SDRAM and starts it from there. + */ void nand_boot(void) { - ulong mem_size; struct nand_chip nand_chip; nand_info_t nand_info; int ret; void (*uboot)(void);
/* - * Init sdram, so we have access to memory - */ - mem_size = initdram(0); - - /* * Init board specific nand support */ nand_info.priv = &nand_chip;
Stefan Roese wrote:
This patch removes the SDRAM initilization call initdram() from nand_boot(). This is done mainly because I experienced problems with some boards like Kilauea (405EX), which don't have internal SRAM (OCM) and relocation needs to be done to SDRAM before the NAND controller can get accessed. When initdram() is called later on in nand_boot(), this can lead to problems with variables in the bss sections like nand_ecc_pos[].
Are there any existing platforms that need an initdram() added elsewhere to accomodate this?
-Scott
On Monday 02 June 2008, Scott Wood wrote:
Stefan Roese wrote:
This patch removes the SDRAM initilization call initdram() from nand_boot(). This is done mainly because I experienced problems with some boards like Kilauea (405EX), which don't have internal SRAM (OCM) and relocation needs to be done to SDRAM before the NAND controller can get accessed. When initdram() is called later on in nand_boot(), this can lead to problems with variables in the bss sections like nand_ecc_pos[].
Are there any existing platforms that need an initdram() added elsewhere to accomodate this?
Currently only the 4xx ones. I sent the patch for them a few minutes ago as you already noticed.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================
Stefan Roese wrote:
This patch removes the SDRAM initilization call initdram() from nand_boot(). This is done mainly because I experienced problems with some boards like Kilauea (405EX), which don't have internal SRAM (OCM) and relocation needs to be done to SDRAM before the NAND controller can get accessed. When initdram() is called later on in nand_boot(), this can lead to problems with variables in the bss sections like nand_ecc_pos[].
Signed-off-by: Stefan Roese sr@denx.de
Acked-by: Scott Wood scottwood@freescale.com
Please send via the 4xx tree in order for the initdram move to be atomic.
-Scott
On Monday 02 June 2008, Scott Wood wrote:
Stefan Roese wrote:
This patch removes the SDRAM initilization call initdram() from nand_boot(). This is done mainly because I experienced problems with some boards like Kilauea (405EX), which don't have internal SRAM (OCM) and relocation needs to be done to SDRAM before the NAND controller can get accessed. When initdram() is called later on in nand_boot(), this can lead to problems with variables in the bss sections like nand_ecc_pos[].
Signed-off-by: Stefan Roese sr@denx.de
Acked-by: Scott Wood scottwood@freescale.com
Please send via the 4xx tree in order for the initdram move to be atomic.
OK, will do.
Thanks.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================
participants (2)
-
Scott Wood -
Stefan Roese