Re: [U-Boot] NAND bootloader, SPL-NUB offset for large page NAND
On Fri, 16 Apr 2010 23:37:42 +0200, Scott Wood scottw...@freescale.com wrote: We do use the remaining 124 KiB for the payload -- see e.g. MPC8536DS.h. We just set CONFIG_SYS_NAND_U_BOOT_OFFS to zero, and CONFIG_SYS_NAND_U_BOOT_START to 4KiB after the destination. The SPL will be loaded twice, but who cares? Thanks a lot, that really helped me. -- Peter Vollmer Innominate Security Technologies AG Berlin / Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] NAND bootloader, SPL-NUB offset for large page NAND
Hi,
I have a question regarding the usage of CPU's with the Freescale ELBC
nand controller, in my case a MPC8313, and large page NAND (i.e.pagesize =
2048+64 bytes, blocksize = 128k):
In nand_spl/nand_boot_fsl_elbc.c , static void nand_load(unsigned int
offs, int uboot_size, uchar *dst) first does a check if the given offset
to the NUB part of the bootloader is one block, i.e. 128 k in case of
large page NAND.
...
if (offs (block_size - 1)) {
puts(bad offset\n);
for (;;);
}
...
Is this offset of one block really necessary? AFAIU the SPL bootloader
needs to fit into the 4-Kbyte SPL boot block for execute-in-place boot
loading.
I could imagine to just use the remaining ~124k of the first block
(guaranteed to be valid for large page NAND) for a good part of the NUB
part of the bootloader. The bad-block skipping part would become effective
for the following blocks nevertheless. Is there a reason to have the NUB
part start in its own NAND block ?
These are my NAND-settings (based on MPC8313ERDB.h, but with large page
NAND)
#define CONFIG_SYS_MAX_NAND_DEVICE 1
#define CONFIG_MTD_NAND_VERIFY_WRITE
#define CONFIG_CMD_NAND 1
#define CONFIG_NAND_FSL_ELBC 1
#define CONFIG_SYS_NAND_PAGE_SIZE (2 10) /* NAND chip page size
(large page) */
#define CONFIG_SYS_NAND_BLOCK_SIZE (128 10) /* NAND chip block size
(large page) */
#define CONFIG_SYS_64BIT_VSPRINTF /* needed for nand_util.c */
#define CONFIG_SYS_NAND_U_BOOT_SIZE (512 10)
#define CONFIG_SYS_NAND_U_BOOT_DST 0x0010
#define CONFIG_SYS_NAND_U_BOOT_START 0x00100100
#define CONFIG_SYS_NAND_U_BOOT_OFFS (128 10)
#define CONFIG_SYS_NAND_U_BOOT_RELOC 0x0001
#define CONFIG_SYS_NAND_U_BOOT_RELOC_SP (CONFIG_SYS_NAND_U_BOOT_RELOC +
0x1)
Thanks for any insight best regards
--
Peter Vollmer
Innominate Security Technologies AG
Berlin / Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] NAND bootloader, SPL-NUB offset for large page NAND
On Fri, Apr 16, 2010 at 01:29:26PM +0200, Peter Vollmer wrote:
Hi,
I have a question regarding the usage of CPU's with the Freescale ELBC
nand controller, in my case a MPC8313, and large page NAND (i.e.pagesize =
2048+64 bytes, blocksize = 128k):
In nand_spl/nand_boot_fsl_elbc.c , static void nand_load(unsigned int
offs, int uboot_size, uchar *dst) first does a check if the given offset
to the NUB part of the bootloader is one block, i.e. 128 k in case of
large page NAND.
...
if (offs (block_size - 1)) {
puts(bad offset\n);
for (;;);
}
...
Is this offset of one block really necessary?
Without it we'd need to special-case the bad block handling.
AFAIU the SPL bootloader
needs to fit into the 4-Kbyte SPL boot block for execute-in-place boot
loading.
I could imagine to just use the remaining ~124k of the first block
(guaranteed to be valid for large page NAND) for a good part of the NUB
part of the bootloader. The bad-block skipping part would become effective
for the following blocks nevertheless. Is there a reason to have the NUB
part start in its own NAND block ?
We do use the remaining 124 KiB for the payload -- see e.g. MPC8536DS.h. We
just set CONFIG_SYS_NAND_U_BOOT_OFFS to zero, and
CONFIG_SYS_NAND_U_BOOT_START to 4KiB after the destination. The SPL will be
loaded twice, but who cares?
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
