[U-Boot-Users] data abort

[U-Boot-Users] data abort

[Glenson Muthedan]

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.

[U-Boot-Users] data abort

[Wolfgang Denk]

Hello,

in message <3F659CD2.1040102@gmx.de> 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.
...
> 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.

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

> 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

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

[U-Boot-Users] data abort

[Robert Schwebel]

On Mon, Sep 15, 2003 at 01:04:50PM +0200, Glenson Muthedan 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.
> (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
> ****************************************************

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

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

[U-Boot-Users] data abort

[Anders Larsen]

Wolfgang Denk <wd@denx.de> schreibt:
>in message <3F659CD2.1040102@gmx.de> 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.
>...
>> 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)!
>
>> 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

[U-Boot-Users] data abort

[Robert Schwebel]

On Mon, Sep 15, 2003 at 01:48:22PM +0200, Anders Larsen wrote:
> Well, 0.01% > 0%  - the PXA implementation is broken ;-)

Hmm, seriously :-) 

> 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 :-) 

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

[U-Boot-Users] data abort

[Anders Larsen]

Robert Schwebel <robert@schwebel.de> schreibt:
>On Mon, Sep 15, 2003 at 01:48:22PM +0200, Anders Larsen wrote:
>> 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 */

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

[U-Boot-Users] data abort

[Robert Schwebel]

On Mon, Sep 15, 2003 at 02:58:51PM +0200, Anders Larsen wrote:
> 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 */

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

[U-Boot-Users] data abort

[Glenson Muthedan]

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.


Wolfgang Denk wrote:
 > Fix your SDRAM initialization.

Robert Schwebel wrote:
 > Sounds like memory problems. Are you sure you did your RAM
 > initialization correct?

Anders Larsen wrote:
 > ...or because ListCreate() can't allocate a (writable) block of RAM.
 > ...

[U-Boot-Users] data abort

[Wolfgang Denk]

Dear Glenson,

in message <3F6759D6.3070406@gmx.de> 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".

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

> 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

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

[U-Boot-Users] data abort

[Woodruff, Richard]

I had similar problems with the 925 when I first enabled devices via
devices_init, the arm code does not do selective remapping.  Inside
devices_init() should be a conditional for ARM only.  I suspect your -pxa
patch wiped this or other such code out.

Regards,

Richard W.   

> -----Original Message-----
> From: Glenson Muthedan [mailto:glenson at gmx.de] 
> Sent: Tuesday, September 16, 2003 1:44 PM
> To: u-boot-users at lists.sourceforge.net
> Subject: Re: [U-Boot-Users] data abort
> 
> 
> 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.
> 
> 
> Wolfgang Denk wrote:
>  > Fix your SDRAM initialization.
> 
> Robert Schwebel wrote:
>  > Sounds like memory problems. Are you sure you did your RAM
>  > initialization correct?
> 
> Anders Larsen wrote:
>  > ...or because ListCreate() can't allocate a (writable) 
> block of RAM.  > ...
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf 
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
> 

[U-Boot-Users] data abort

[Anders Larsen]

Glenson Muthedan <glenson@gmx.de> schreibt:
>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

[U-Boot-Users] data abort

[Wolfgang Denk]

Dear Anders,

in message <fc.004c4e48001cb53e3b9aca0046c440fa.1cb55e@rea.de> 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

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

[U-Boot-Users] data abort

[Anders Larsen]

Wolfgang Denk <wd@denx.de> schreibt:
>Dear Anders,
>
>in message <fc.004c4e48001cb53e3b9aca0046c440fa.1cb55e@rea.de> 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().

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

[U-Boot-Users] data abort

[Glenson Muthedan]

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.


Anders Larsen wrote:
> 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
> 
>