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.
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
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
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
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
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
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. ...
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
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
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
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
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
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
participants (4)
-
Anders Larsen -
Glenson Muthedan -
Robert Schwebel -
Wolfgang Denk