All of lore.kernel.org
 help / color / mirror / Atom feed
* [U-Boot] NAND bootloader, SPL<->NUB offset for large page NAND
@ 2010-04-16 11:29 Peter Vollmer
  2010-04-16 21:37 ` Scott Wood
  0 siblings, 1 reply; 3+ messages in thread
From: Peter Vollmer @ 2010-04-16 11:29 UTC (permalink / raw)
  To: u-boot

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   0x00100000
#define CONFIG_SYS_NAND_U_BOOT_START 0x00100100
#define CONFIG_SYS_NAND_U_BOOT_OFFS  (128 << 10)
#define CONFIG_SYS_NAND_U_BOOT_RELOC 0x00010000
#define CONFIG_SYS_NAND_U_BOOT_RELOC_SP (CONFIG_SYS_NAND_U_BOOT_RELOC +  
0x10000)


Thanks for any insight & best regards

-- 
Peter Vollmer
Innominate Security Technologies AG
Berlin / Germany

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [U-Boot] NAND bootloader, SPL<->NUB offset for large page NAND
  2010-04-16 11:29 [U-Boot] NAND bootloader, SPL<->NUB offset for large page NAND Peter Vollmer
@ 2010-04-16 21:37 ` Scott Wood
  2010-04-19 16:26   ` Peter Vollmer
  0 siblings, 1 reply; 3+ messages in thread
From: Scott Wood @ 2010-04-16 21:37 UTC (permalink / raw)
  To: u-boot

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [U-Boot] NAND bootloader, SPL<->NUB offset for large page NAND
  2010-04-16 21:37 ` Scott Wood
@ 2010-04-19 16:26   ` Peter Vollmer
  0 siblings, 0 replies; 3+ messages in thread
From: Peter Vollmer @ 2010-04-19 16:26 UTC (permalink / raw)
  To: u-boot

On Fri, 16 Apr 2010 23:37:42 +0200, Scott Wood <scottwood@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

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2010-04-19 16:26 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-04-16 11:29 [U-Boot] NAND bootloader, SPL<->NUB offset for large page NAND Peter Vollmer
2010-04-16 21:37 ` Scott Wood
2010-04-19 16:26   ` Peter Vollmer

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.