[U-Boot-Users] U-boot Bus Fault Error while accessing NOR flash

Nikhil Gautam nikhilgautam1 at gmail.com
Wed Feb 20 21:10:25 CET 2008


Hi Stefan,

Below is the most of my init.S file. You are correct about the
faulting location. But I can see in the init.S file that this address
location is defined as "AC_R|AC_W|AC_X|SA_G" so I think I should be
able to at least read it. When I boot from 256Mb NAND flash, I don't
see this problem. Its only when I boot from 1Gb NAND flash.

Thanks,

Nikhil

Init.S file:-


/* General */
#define TLB_VALID   0x00000200
#define _256M       0x10000000

/* Supported page sizes */

#define SZ_1K	    0x00000000
#define SZ_4K	    0x00000010
#define SZ_16K	    0x00000020
#define SZ_64K	    0x00000030
#define SZ_256K	    0x00000040
#define SZ_1M	    0x00000050
#define SZ_8M       0x00000060
#define SZ_16M	    0x00000070
#define SZ_256M	    0x00000090

/* Storage attributes */
#define SA_W	    0x00000800	    /* Write-through */
#define SA_I	    0x00000400	    /* Caching inhibited */
#define SA_M	    0x00000200	    /* Memory coherence */
#define SA_G	    0x00000100	    /* Guarded */
#define SA_E	    0x00000080	    /* Endian */

/* Access control */
#define AC_X	    0x00000024	    /* Execute */
#define AC_W	    0x00000012	    /* Write */
#define AC_R	    0x00000009	    /* Read */


	/* TLB#0: vxWorks needs this entry for the Machine Check interrupt,  */
	tlbentry( 0x40000000, SZ_256M, 0, 0, AC_R|AC_W|AC_X|SA_G|SA_I )

	/* TLB#1: TLB-entry for DDR SDRAM (Up to 2GB) */
	tlbentry( CFG_SDRAM_BASE, SZ_256M, CFG_SDRAM_BASE, 0,
AC_R|AC_W|AC_X|SA_G|SA_I ) /* CFG_SDRAM_BASE 0x00000000 */

	/* TLB#2: TLB-entry for EBC (CPLD control) */
	tlbentry( CFG_BCSR_BASE, SZ_256M, CFG_BCSR_BASE, 1,
AC_R|AC_W|AC_X|SA_G|SA_I ) /* CFG_BCSR_BASE 0xc0000000 */

	/*
	 * TLB#3: BOOT_CS (FLASH) must be forth. Before relocation SA_I can
be off to use the
	 * speed up boot process. It is patched after relocation to enable SA_I
	 */
#ifndef CONFIG_NAND_SPL
	tlbentry( CFG_BOOT_BASE_ADDR, SZ_256M, CFG_BOOT_BASE_ADDR, 1,
AC_R|AC_W|AC_X|SA_G ) /* CFG_BOOT_BASE_ADDR 0xf0000000 */
#else
	tlbentry( CFG_NAND_BOOT_SPL_SRC, SZ_4K, CFG_NAND_BOOT_SPL_SRC, 1,
AC_R|AC_W|AC_X|SA_G ) /* CFG_NAND_BOOT_SPL_SRC 0xfffff000 */
#endif

#ifdef CFG_INIT_RAM_DCACHE
	/* TLB-entry for init-ram in dcache (SA_I must be turned off!) */
	tlbentry( CFG_INIT_RAM_ADDR, SZ_64K, CFG_INIT_RAM_ADDR, 0,
AC_R|AC_W|AC_X|SA_G ) /* CFG_INIT_RAM_ADDR 0xe0010000 */
#endif

	/* TLB-entry for NAND */
	tlbentry( CFG_NAND_ADDR, SZ_1K, CFG_NAND_ADDR, 1,
AC_R|AC_W|AC_X|SA_G|SA_I ) /* CFG_NAND_ADDR 0xd0000000 */

	/* TLB-entry for Internal Registers & OCM */
	tlbentry( 0xe0000000, SZ_16M, 0xe0000000, 0,  AC_R|AC_W|AC_X|SA_I )

	/* TLB-entry for EBC (FPGA control) */
	tlbentry( 0xEA000000, SZ_1M, 0xEA000000, 1, AC_R|AC_W|AC_X|SA_G|SA_I )

	/*TLB-entry PCI registers*/
	tlbentry( 0xEEC00000, SZ_1K, 0xEEC00000, 1,  AC_R|AC_W|AC_X|SA_G|SA_I )

	/* TLB-entry for peripherals */
	tlbentry( 0xEF000000, SZ_16M, 0xEF000000, 1, AC_R|AC_W|AC_X|SA_G|SA_I)

	tlbtab_end

#if defined(CONFIG_NAND_U_BOOT) && !defined(CONFIG_NAND_SPL)
	/*
	 * For NAND booting the first TLB has to be reconfigured to full size
	 * and with caching disabled after running from RAM!
	 */
#define TLB00	TLB0(CFG_BOOT_BASE_ADDR, SZ_256M) /* CFG_BOOT_BASE_ADDR
0xf0000000 */
#define TLB01	TLB1(CFG_BOOT_BASE_ADDR, 1)
#define TLB02	TLB2(AC_R|AC_W|AC_X|SA_G|SA_I)



On Feb 19, 2008 11:50 AM, Stefan Roese <sr at denx.de> wrote:
> On Tuesday 19 February 2008, Nikhil Gautam wrote:
> > Thanks for the information. My problem is that "md 0xFFFFE000" and any
> > other read command up to this address works fine. Its just when I try
> > to read @ 0xFFFF F000 I see this problem.
>
> This problem with accessing the last 4k after NAND booting looks like a
> problem with either cache or TLB setup to me. Please keep in mind, that while
> booting via NAND the IPL (initial program loader) included in the PPC loads
> exactly 4k of code into the i-cache at the last 4k. So this is exactly your
> faulting location.
>
> Note: I have not seen such issues with the NAND booting 4xx board I tested on
> so far.
>
> 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 at denx.de
> =====================================================================
>




More information about the U-Boot mailing list