data abort

U-Boot-Users Glenson Muthedan 4 participants 13 messages Sep 15, 2003 – Sep 17, 2003

Share & tools

Glenson Muthedan

author

2003-09-15 11:04 UTC #0 lore raw

Hello everybody!

First of all thanks to Wolfgang Denk and Robert Schwebel for the helpful instructions to get started with U-Boot and BDI2000.

Now, I've a new problem: When U-Boot starts I can see following outsputs
through "cu", before the system stops due to a data abort.
(My board: PXA250, 32MB SDRAM, 32MB Strataflash, etc.)

****************************************************
U-Boot 0.4.0 (Sep 15 2003 - 12:09:08)

U-Boot code: A1FE0000 -> A1FF5728 BSS: -> A1FF6BD4 DRAM Configuration:
Bank #0: a0000000 32 MB
Flash: 32 MB
data abort
undefined instruction
undefined instruction
undefined instruction
****************************************************

I put some printf-lines(beginning with GM) in the soucecode to see where the execution stops. Here, my debug-output:

****************************************************
U-Boot 0.4.0 (Sep 15 2003 - 12:23:05)

U-Boot code: A1FE0000 -> A1FF5870 BSS: -> A1FF6D1C DRAM Configuration:
Bank #0: a0000000 32 MB
Flash: 32 MB

GM: lib_arm/board.c; entering devices_init()

GM: common/devices.c; entering ListCreate()

GM: common/lists.c; after 'list = (list_t) (NewHandle (sizeof
(ListStruct)))'
GM: common/lists.c; list = 0badc108
GM: common/lists.c; *list = a1ff10a0
data abort
prefetch abort
prefetch abort
prefetch abort
prefetch abort
****************************************************

If I understand right, this exception occurs due to access to the contents of the created list. For example at the line(lists.c:
ListCreate): (*list)->numItems = 0;

Why does this happen? I'm quite sure that my Flash and SDRAM are working properly. Can somebody suggest a way to workaround this problem?

Thanks.
Glenson Muthedan.

Wolfgang Denk

2003-09-15 11:29 UTC #1 lore raw

Hello,

Quoted 3 lines · in message <[email protected]> you wrote:

Now, I've a new problem: When U-Boot starts I can see following outsputs
through "cu", before the system stops due to a data abort.

...

Quoted 8 lines

U-Boot code: A1FE0000 -> A1FF5728 BSS: -> A1FF6BD4 DRAM Configuration:
Bank #0: a0000000 32 MB
Flash: 32 MB
data abort
undefined instruction
undefined instruction
undefined instruction

There is a 99.99% likelyhood of SDRAM error.

Quoted 2 lines

If I understand right, this exception occurs due to access to the contents of the created list. For example at the line(lists.c:

Most probably it occurs because you are reading garbage from RAM.

Quoted 2 lines

Why does this happen? I'm quite sure that my Flash and SDRAM are working properly. Can somebody suggest a way to workaround this problem?

Fix your SDRAM initialization.

Best regards,

Wolfgang Denk

Signature · 4 lines

Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
There are very few personal problems that cannot be solved through  a
suitable application of high explosives.

Anders Larsen

2003-09-15 11:48 UTC #2 lore raw

Wolfgang Denk <[email protected]> schreibt:

Quoted 6 lines

Quoted 2 lines · in message <[email protected]> you wrote:
Now, I've a new problem: When U-Boot starts I can see following
outsputs
Quoted 1 line
through "cu", before the system stops due to a data abort.
...

Quoted 8 lines

Quoted 6 lines
U-Boot code: A1FE0000 -> A1FF5728 BSS: -> A1FF6BD4 DRAM Configuration:
Bank #0: a0000000 32 MB
Flash: 32 MB
data abort
undefined instruction
There is a 99.99% likelyhood of SDRAM error.

Well, 0.01% > 0% - the PXA implementation is broken ;-)

It looks a lot like the PXA problem that bit me last week; _armboot_real_end is never initialized, so U-Boot crashes when start_armboot() calls mem_malloc_init(_armboot_real_end)!

Quoted 5 lines

Quoted 3 lines
If I understand right, this exception occurs due to access to the contents of the created list. For example at the line(lists.c:
Most probably it occurs because you are reading garbage from RAM.

...or because ListCreate() can't allocate a (writable) block of RAM.

As a workaround, add this snippet

	/*
	 * Following code is just bug workaround, remove it if not neccessary
	 */

	/* cpu/xscale/cpu.c does not set armboot_real_end that is used for
	   malloc pool.*/
	if ( _armboot_real_end == 0xbadc0de )
		_armboot_real_end = TEXT_BASE - CFG_MALLOC_LEN;

to board_init().
If the problem persists, then Wolfgang is right about RAM HW problems...

I'll submit a patch to fix this once and for all RSN...

Cheers
Anders

Robert Schwebel

2003-09-15 12:51 UTC #3 lore raw

Quoted 1 line · Anders Larsen

Well, 0.01% > 0% - the PXA implementation is broken ;-)

Hmm, seriously :-)

Quoted 3 lines

It looks a lot like the PXA problem that bit me last week; _armboot_real_end is never initialized, so U-Boot crashes when start_armboot() calls mem_malloc_init(_armboot_real_end)!

Well, start_armboot() calls only _armboot_real_end when CONFIG_VFD is defined. Guess why -ptx has a nice warning in the sourcecode that this code has probably never run :-)

Quoted 1 line

I'll submit a patch to fix this once and for all RSN...

That indeed would bring you the title "u-boot developer of the month" ;)

Robert

Signature · 5 lines

 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
     Hornemannstra?e 12,  31137 Hildesheim, Germany
    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4

Anders Larsen

2003-09-15 12:58 UTC #4 lore raw

Robert Schwebel <[email protected]> schreibt:

Quoted 8 lines · Anders Larsen

Quoted 3 lines
It looks a lot like the PXA problem that bit me last week; _armboot_real_end is never initialized, so U-Boot crashes when start_armboot() calls mem_malloc_init(_armboot_real_end)!
Well, start_armboot() calls only _armboot_real_end when CONFIG_VFD is defined. Guess why -ptx has a nice warning in the sourcecode that this code has probably never run :-)

Hi Robert,
start_armboot() references _armboot_real_end *regardless* of the setting of CONFIG_VFD, see lib_arm/board.c:

#ifdef CONFIG_VFD
# ifndef PAGE_SIZE
# define PAGE_SIZE 4096
# endif
/*
* reserve memory for VFD display (always full pages)
*/
/* armboot_real_end is defined in the board-specific linker script */
! addr = (_armboot_real_end + (PAGE_SIZE - 1)) & ~(PAGE_SIZE - 1);
size = vfd_setmem (addr);
gd->fb_base = addr;
/* round to the next page boundary */
addr += size;
addr = (addr + (PAGE_SIZE - 1)) & ~(PAGE_SIZE - 1); mem_malloc_init (addr);
#else
/* armboot_real_end is defined in the board-specific linker script */
! mem_malloc_init (_armboot_real_end);
#endif /* CONFIG_VFD */

Quoted 3 lines

Quoted 1 line
I'll submit a patch to fix this once and for all RSN...
That indeed would bring you the title "u-boot developer of the month" ;)

:-)

Cheers
Anders

Robert Schwebel

2003-09-15 13:44 UTC #5 lore raw

Quoted 20 lines · Anders Larsen

start_armboot() references _armboot_real_end *regardless* of the setting of CONFIG_VFD, see lib_arm/board.c:

#ifdef CONFIG_VFD
# ifndef PAGE_SIZE
# define PAGE_SIZE 4096
# endif

(quoted diff) +0 -0

 	/*
 	 * reserve memory for VFD display (always full pages)
 	 */
 	/* armboot_real_end is defined in the board-specific linker script */
 !	addr = (_armboot_real_end + (PAGE_SIZE - 1)) & ~(PAGE_SIZE - 1);
 	size = vfd_setmem (addr);
 	gd->fb_base = addr;
 	/* round to the next page boundary */
 	addr += size;
 	addr = (addr + (PAGE_SIZE - 1)) & ~(PAGE_SIZE - 1);
 	mem_malloc_init (addr);
 #else
 	/* armboot_real_end is defined in the board-specific linker script */

Quoted 2 lines

! mem_malloc_init (_armboot_real_end);
#endif /* CONFIG_VFD */

Not in -ptx:

#ifdef CONFIG_VFD
[...]

#else
        /* FIXME: shouldn't the board info structure be between malloc      */
        /* area and u-boot code?                                            */

        /* malloc area is below startaddress of u-boot in RAM */
        mem_malloc_init(_armboot_start - CFG_MALLOC_LEN);

#endif /* CONFIG_VFD */

Robert

Signature · 5 lines

 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
     Hornemannstra?e 12,  31137 Hildesheim, Germany
    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4

Glenson Muthedan

author

2003-09-16 18:43 UTC #6 lore raw

In reply to Anders Larsen

Hello!

Thank you guys for your kind help. My SDRAM initialization was not correct. Now, having done some changes, everything seems to work smoothly except one line in devices_init() in the file common/devices.c

The execution stops at the line
gd->flags |= GD_FLG_DEVINIT; /* device initialization done */

Then, sometimes a "prefetch abort" occurs, sometimes it just hangs.

When I comment this line, U-Boot runs up to the bootloader-prompt without any problem. So I hope, the line above is not a crucial one if I only have to do with the serial console. But I'm interested to know what you think about this temporary solution; am I running into problems later?

Regards.
Glenson.

Quoted 1 line · Wolfgang Denk

Fix your SDRAM initialization.

Quoted 2 lines · Robert Schwebel

Sounds like memory problems. Are you sure you did your RAM initialization correct?

Quoted 2 lines · Anders Larsen

...or because ListCreate() can't allocate a (writable) block of RAM.
...

Wolfgang Denk

2003-09-16 20:26 UTC #7 lore raw

Dear Glenson,

Quoted 5 lines · in message <[email protected]> you wrote:

The execution stops at the line
gd->flags |= GD_FLG_DEVINIT; /* device initialization done */
Then, sometimes a "prefetch abort" occurs, sometimes it just hangs.

Check if "gd" is really held in a register, as it should be, and where it points to. See the README notes about "initial data".

Quoted 2 lines

When I comment this line, U-Boot runs up to the bootloader-prompt without any problem. So I hope, the line above is not a crucial one if I

It is somewhat crucial, especially as errors here indicate problems with a very important mechanism.

Quoted 2 lines

only have to do with the serial console. But I'm interested to know what you think about this temporary solution; am I running into problems later?

Most definitely there will be more problems.

Best regards,

Wolfgang Denk

Signature · 4 lines

Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Unser Kopf ist rund, damit das Denken die Richtung wechseln kann.
                                                   -- Francis Picabia

Anders Larsen

2003-09-17 08:57 UTC #8 lore raw

In reply to Glenson Muthedan

Glenson Muthedan <[email protected]> schreibt:

Quoted 8 lines

Thank you guys for your kind help. My SDRAM initialization was not correct. Now, having done some changes, everything seems to work smoothly except one line in devices_init() in the file common/devices.c
The execution stops at the line
gd->flags |= GD_FLG_DEVINIT; /* device initialization done */
Then, sometimes a "prefetch abort" occurs, sometimes it just hangs.

Hi Glenson,

does it happen immediately at that line, or did you add any debug output?

As soon as GD_FLG_DEVINIT is set, the output functions (puts, printf, ...) will search for the output device in a lookup table, which unfortunately has not yet been initialized at that point (the lookup table is initialized in console_init_r() which is called *after* devices_init() has completed).

Perhaps the line "gd->flags |= GD_FLG_DEVINIT;" should better be moved to console_init_r() ?

Cheers
Anders

Wolfgang Denk

2003-09-17 10:02 UTC #9 lore raw

Dear Anders,

Quoted 9 lines · in message <[email protected]> you wrote:

As soon as GD_FLG_DEVINIT is set, the output functions (puts, printf, ...) will search for the output device in a lookup table, which unfortunately has not yet been initialized at that point (the lookup table is initialized in console_init_r() which is called *after* devices_init() has completed).
Perhaps the line "gd->flags |= GD_FLG_DEVINIT;" should better be moved to console_init_r() ?

...but there is no output happening between devices_init() and console_init_r().

Best regards,

Wolfgang Denk

Signature · 5 lines

Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
When properly administered, vacations do not  diminish  productivity:
for every week you're away and get nothing done, there's another when
your boss is away and you get twice as much done.  -- Daniel B. Luten

Anders Larsen

2003-09-17 10:08 UTC #10 lore raw

Wolfgang Denk <[email protected]> schreibt:

Quoted 10 lines

Dear Anders,
Quoted 7 lines · in message <[email protected]> you wrote:
As soon as GD_FLG_DEVINIT is set, the output functions (puts, printf, ...) will search for the output device in a lookup table, which unfortunately has not yet been initialized at that point (the lookup table is initialized in console_init_r() which is called *after* devices_init() has completed).

Quoted 5 lines

Quoted 2 lines
Perhaps the line "gd->flags |= GD_FLG_DEVINIT;" should better be moved to console_init_r() ?
...but there is no output happening between devices_init() and console_init_r().

...which is why I asked Glenson if he had eventually added any (debug) output statement.

I still think we should move the line in question to close this window of (potential) crashes.

Cheers
Anders

Glenson Muthedan

author

2003-09-17 14:17 UTC #11 lore raw

In reply to Anders Larsen

Hi Anders,

Ohh, yes! You're right. I had put some printf-lines in board.c between devices_init() and console_init_r(). As you explained, removing those lines solved that problem. Now U-Boot seems to run quite normal.

Thanks.
Glenson.

Quoted 18 lines · Anders Larsen

Hi Glenson,
does it happen immediately at that line, or did you add any debug output?
As soon as GD_FLG_DEVINIT is set, the output functions (puts, printf, ...) will search for the output device in a lookup table, which unfortunately has not yet been initialized at that point (the lookup table is initialized in console_init_r() which is called *after* devices_init() has completed).
Perhaps the line "gd->flags |= GD_FLG_DEVINIT;" should better be moved to console_init_r() ?
Cheers
Anders

Robert Schwebel

2003-09-15 11:42 UTC #12 lore raw

In reply to Glenson Muthedan

Quoted 7 lines · Glenson Muthedan

Now, I've a new problem: When U-Boot starts I can see following outsputs
through "cu", before the system stops due to a data abort.
(My board: PXA250, 32MB SDRAM, 32MB Strataflash, etc.)
****************************************************
U-Boot 0.4.0 (Sep 15 2003 - 12:09:08)

Quoted 9 lines

U-Boot code: A1FE0000 -> A1FF5728 BSS: -> A1FF6BD4 DRAM Configuration:
Bank #0: a0000000 32 MB
Flash: 32 MB
data abort
undefined instruction
undefined instruction
undefined instruction
****************************************************

Sounds like memory problems. Are you sure you did your RAM initialization correct?

Robert

Signature · 5 lines

 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
     Hornemannstra?e 12,  31137 Hildesheim, Germany
    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4