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

newer
[U-Boot-Users] AT91SAM9260EK with...

Nikhil Gautam

15 Feb 2008 15 Feb '08

6:22 p.m.

Hi Everyone,

I am try to use the u-boot to program the NOR flash on my proprietary board based on AMCC sequoia board. I can boot from 1Gb NAND flash ok but everytime I try access the last 4K of NOR flash, U-boot gives me following error and reboots:-

{{{ U-Boot$ md 0xFFFFF000 fffff000:Bus Fault @ 0x00000000, fixup 0x00000000 Machine check in kernel mode. Caused by (from msr): regs 0fe8fca8 Unknown values in msr NIP: 00000000 XER: 20000000 LR: 0FF6412C REGS: 0fe8fca8 TRAP: 0200 DAR: 041F0000 MSR: 00000000 EE: 0 PR: 0 FP: 0 ME: 0 IR/DR: 00

GPR00: 0FF6412C 0FE8FD98 7FFFFFFF EF600300 00000000 00000001 00000001 C838AE89 GPR08: 0FF5145C 00000000 01FCA055 03F940AB 0FE8FB50 041F0000 0FFACD00 0EED0000 GPR16: 00000000 00000000 00000000 00000000 0FE8FDA0 00000040 0FE8FDA0 0FE8FDA0 GPR24: 00000000 00000100 00000010 00000004 FFFFF000 0FE8FF40 0FFADB58 0FE8FDA0 Call backtrace: machine check }}}

I get the same error if I press "ENTER" after u-boot gives me the prompt. If I type some command its ok and then its fine thereafter.

I know the NOR flash is ok because I used BDI to program it and also I can access this address when I boot from NOR flash.

Any Clue?

Thanks In Advance!

Nikhil Gautam

Show replies by date

Jerry Van Baren

15 Feb 15 Feb

7:15 p.m.

Nikhil Gautam wrote:

...

Hi Everyone,

I am try to use the u-boot to program the NOR flash on my proprietary board based on AMCC sequoia board. I can boot from 1Gb NAND flash ok but everytime I try access the last 4K of NOR flash, U-boot gives me following error and reboots:-

{{{ U-Boot$ md 0xFFFFF000 fffff000:Bus Fault @ 0x00000000, fixup 0x00000000 Machine check in kernel mode. Caused by (from msr): regs 0fe8fca8 Unknown values in msr NIP: 00000000 XER: 20000000 LR: 0FF6412C REGS: 0fe8fca8 TRAP: 0200 DAR: 041F0000 MSR: 00000000 EE: 0 PR: 0 FP: 0 ME: 0 IR/DR: 00

GPR00: 0FF6412C 0FE8FD98 7FFFFFFF EF600300 00000000 00000001 00000001 C838AE89 GPR08: 0FF5145C 00000000 01FCA055 03F940AB 0FE8FB50 041F0000 0FFACD00 0EED0000 GPR16: 00000000 00000000 00000000 00000000 0FE8FDA0 00000040 0FE8FDA0 0FE8FDA0 GPR24: 00000000 00000100 00000010 00000004 FFFFF000 0FE8FF40 0FFADB58 0FE8FDA0 Call backtrace: machine check }}}

I get the same error if I press "ENTER" after u-boot gives me the prompt. If I type some command its ok and then its fine thereafter.

I know the NOR flash is ok because I used BDI to program it and also I can access this address when I boot from NOR flash.

Any Clue?

Thanks In Advance!

Nikhil Gautam

Hi Nikhil,

If I understand you correctly, this sounds like improperly initialized variables in your build. This is very likely a (build | link | initialization | relocation) issue (pick any combination).

The "md 0xFFFFF000" command is using the default value for the number of objects, which comes from a static variable dp_last_length that is initialized to 0x40 (see common/cmd_mem.c): uint dp_last_length = 0x40;

If dp_last_length is not initialized properly to 0x40 on start up, unexpected things are going to happen. I don't see an obvious path to an illegal access to location 0x00000000, but it could be.

In addition, if you hit <enter> with no command the first time your board boots, the command parser tries to run the last command you executed. Of course, there *is no* "last command", which ties into my theory of uninitialized static/global variables.

I would suspect your link control isn't linking the static variable initialization in the right section or your (compiler's) initialization of the static variables isn't working as expected.

HTH, gvb

Nikhil Gautam

19 Feb 19 Feb

8:32 p.m.

Hi HTH,

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.

I didn't see any obvious problem with the global and static initialization.

Nikhil

...

Hi Nikhil,

If I understand you correctly, this sounds like improperly initialized variables in your build. This is very likely a (build | link | initialization | relocation) issue (pick any combination).

The "md 0xFFFFF000" command is using the default value for the number of objects, which comes from a static variable dp_last_length that is initialized to 0x40 (see common/cmd_mem.c): uint dp_last_length = 0x40;

If dp_last_length is not initialized properly to 0x40 on start up, unexpected things are going to happen. I don't see an obvious path to an illegal access to location 0x00000000, but it could be.

In addition, if you hit <enter> with no command the first time your board boots, the command parser tries to run the last command you executed. Of course, there *is no* "last command", which ties into my theory of uninitialized static/global variables.

I would suspect your link control isn't linking the static variable initialization in the right section or your (compiler's) initialization of the static variables isn't working as expected.

HTH, gvb

On Feb 15, 2008 10:15 AM, Jerry Van Baren gerald.vanbaren@ge.com wrote:

...

Nikhil Gautam wrote:

...
Hi Everyone,

I am try to use the u-boot to program the NOR flash on my proprietary board based on AMCC sequoia board. I can boot from 1Gb NAND flash ok but everytime I try access the last 4K of NOR flash, U-boot gives me following error and reboots:-

{{{ U-Boot$ md 0xFFFFF000 fffff000:Bus Fault @ 0x00000000, fixup 0x00000000 Machine check in kernel mode. Caused by (from msr): regs 0fe8fca8 Unknown values in msr NIP: 00000000 XER: 20000000 LR: 0FF6412C REGS: 0fe8fca8 TRAP: 0200 DAR: 041F0000 MSR: 00000000 EE: 0 PR: 0 FP: 0 ME: 0 IR/DR: 00

GPR00: 0FF6412C 0FE8FD98 7FFFFFFF EF600300 00000000 00000001 00000001 C838AE89 GPR08: 0FF5145C 00000000 01FCA055 03F940AB 0FE8FB50 041F0000 0FFACD00 0EED0000 GPR16: 00000000 00000000 00000000 00000000 0FE8FDA0 00000040 0FE8FDA0 0FE8FDA0 GPR24: 00000000 00000100 00000010 00000004 FFFFF000 0FE8FF40 0FFADB58 0FE8FDA0 Call backtrace: machine check }}}

I get the same error if I press "ENTER" after u-boot gives me the prompt. If I type some command its ok and then its fine thereafter.

I know the NOR flash is ok because I used BDI to program it and also I can access this address when I boot from NOR flash.

Any Clue?

Thanks In Advance!

Nikhil Gautam

Stefan Roese

8:50 p.m.

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@denx.de =====================================================================

k b

11:54 p.m.

New subject: [U-Boot-Users] read from serial port

Hi, I'm using u-boot-1.2.0 and want to know if there is easy way to read serial port.

So here's what i'm trying to achieve, 1) my commands get called based on user's input on the serial port. but there on after as the my command i interactive i would want to read users input on the serial port. Is there a straight forward way ot do this.

-KB _________________________________________________________________ Climb to the top of the charts! Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan

Nikhil Gautam

20 Feb 20 Feb

9:10 p.m.

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@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@denx.de =====================================================================

Stefan Roese

25 Feb 25 Feb

2:54 p.m.

Hi Nikhil,

On Wednesday 20 February 2008, Nikhil Gautam wrote:

...

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.

I suggest that you look at the TLB setup with the BDI2000 when U-Boot is up and running, before trying to dump the last 4k from U-Boot:

=> tlb 0 63

This will show you the currently configured TLB's.

...

When I boot from 256Mb NAND flash, I don't see this problem. Its only when I boot from 1Gb NAND flash.

And 1Gb is large page, right?

Best regards, Stefan

Stefan Roese

8 Apr 8 Apr

8:54 a.m.

Hi Nikhil,

On Wednesday 20 February 2008, Nikhil Gautam wrote:

...

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.

Did you get this problem fixed on your board? If yes, what was it?

I'm asking because I'm currently adding 2k page size NAND device support to nand_spl and I'm seeing some strange exception on my target after running from SDRAM.

Thanks.

Best regards, Stefan

Stefan Roese

10:21 a.m.

On Tuesday 08 April 2008, Stefan Roese wrote:

...

...
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.

Did you get this problem fixed on your board? If yes, what was it?

I'm asking because I'm currently adding 2k page size NAND device support to nand_spl and I'm seeing some strange exception on my target after running from SDRAM.

Never mind. I found my problem. One size was set incorrectly. Now I can boot successfully from 2k page size NAND devices. Patch for review will follow soon.

Best regards, Stefan

6237

Age (days ago)

6290

Last active (days ago)

List overview

Download

8 comments

4 participants

tags (0)

participants (4)

Jerry Van Baren
k b
Nikhil Gautam
Stefan Roese