Re: [microblaze-uclinux] New Board - UBoot

[Michal Simek <monstr@xxxxxxxxx>]

Hi Mak,


> Hello,
> 
> Here is the output you needed.
> =================================================
> FS-BOOT First Stage Bootloader (c) 2006 PetaLogix
> =================================================
> FS-BOOT: System initialisation completed.
> FS-BOOT: No existing image in FLASH.  Starting image download.
> FS-BOOT: Waiting for SREC image....
> FS-BOOT: Image download successful.
> FS-BOOT: Warning image location differ from default boot location. Image will no
> t boot automatically after POR.
> FS-BOOT: Press 'n' to boot old image.
> FS-BOOT: Use new image.
> FS-BOOT: Booting image...
> SDRAM :
> SDRAM: 0xc0000000/0x40000000, TEXT_BASE 0xfffc0000, addr 0x0


addr = 0 is bad case - that's why u-boot failed. because in 32bit
0xc0000000 + 0x40000000 = 0.

>         Enabling caches :
>                 Icache:OK
>                 Dcache:OK
> 
> ERROR: Insufficient memory to initialize u-boot.
> Check system address map and memory size.
> ### ERROR ### Please RESET the board ###
> /*================================================================*/
> 
> I have also tried some experiments on the same file, with Software and
> Hardware Configuration.
> Under Software Platform Settings -> OS and Libraries I had set the
> "main memory size" to Half of the DDR2 size. Then I built the image
> again and downloaded the board. This time I has gone somewhat ahead.
> But before the initialization completes the system restarts. Here is
> the output.
> =================================================
> FS-BOOT First Stage Bootloader (c) 2006 PetaLogix
> =================================================
> FS-BOOT: System initialisation completed.
> FS-BOOT: No existing image in FLASH.  Starting image download.
> FS-BOOT: Waiting for SREC image....
> FS-BOOT: Image download successful.
> FS-BOOT: Warning image location differ from default boot location. Image will no
> t boot automatically after POR.
> FS-BOOT: Press 'n' to boot old image.
> FS-BOOT: Use new image.
> FS-BOOT: Booting image...
> SDRAM :
> 
> BASE: c0000000
> SIZE: 20000000
> Address: e0000000
>         Enabling caches :
>                 Icache:OK
>                 Dcache:OK
> 
> CFG_MONITOR_LEN: 40000
> Address: dffc0000
> Mem bound test: Address dffc0000        U-Boot Start:0xdffc0000
> 
> Mem bound test: Address dff60000        Malloc Start:0xdff60000
> 
> Mem bound test: Address dff5ffd0        Board Info Start:0xdff5ffd0
> 
> Mem bound test: Address dff4ffd0        Boot Parameters Start:0xdf
> =================================================
> FS-BOOT First Stage Bootloader (c) 2006 PetaLogix
> =================================================
> FS-BOOT: System initialisation completed.
> FS-BOOT: No existing image in FLASH.  Starting image download.
> FS-BOOT: Waiting for SREC image....
> /*================================================================*/
> I tried the same experiment in the hardware also where the DDR2 size
> is reduces to half. But this time also the same behavior.
> I could not imagine the link between restarting the system and
> changing the value in SW/HW to manually override the main memory size?

1. Please do update to latest petalinux code from svn server.
2. Please do full memory test.
3. manual overriding parameters just change memory size - then you have to call
petalinux-copy-autoconfig script.
4. System restarting could be caused by many reason - exception, bad program
behaviour and others. In some cases I saw that reset were caused u-boot position
in memory -> this could be caused by unaligned exception. Changing TEXT_BASE
could be good way. You can manually rewrite this value in
board/petalogix/microblaze-auto/config.mk


> When I have reduced the size in hardware it automatically get mapped
> to another address. And while changing the "main memory size" in
> software, I was not utilizing the upper half of the memory. So has it
> something to do with the RAM mapping as currently it is mapped to the
> top of the memory? EDK does not allow me to map the RAM elsewhere
> because of the size. it gives me the error that "Least significant 30
> bits of base adders must be 0"

Memory address position shouldn't be an issue. IMHO EDK allows you to place this
memory from 0x40000000 or 0x80000000 too.

Regards,
Michal

___________________________
microblaze-uclinux mailing list
microblaze-uclinux@xxxxxxxxxxxxxx
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/