[U-Boot] [RFC][PATCH v2 17/19] arm cp15: setup mmu and enable dcache
Ben Gardiner
bengardiner at nanometrics.ca
Wed Aug 11 15:31:38 CEST 2010
Hello Heiko,
On Wed, Aug 11, 2010 at 1:56 AM, Heiko Schocher <hs at denx.de> wrote:
> Hello Ben,
>
> Thanks for trying this patches!
My pleasure! Thank you for doing the hard work.
> Ben Gardiner wrote:
>> On Fri, Aug 6, 2010 at 12:44 PM, Ben Gardiner
>> <bengardiner at nanometrics.ca> wrote:
>> I did get an openocd debugger going with uboot on the da850 (see the
>
> Good!
:)
>> It looks like execution goes off into the weeds at
>> arch/arm/cpu/arm926ejs/start.S:294
>>
>> 288 ldr r2, _board_init_r
>> 289 sub r2, r2, r0
>> 290 add r2, r2, r7 /* position from board_init_r in RAM */
>> 291 /* setup parameters for board_init_r */
>> 292 mov r0, r5 /* gd_t */
>> 293 mov r1, r7 /* dest_addr */
>> 294 /* jump to it ... */
>> 295 mov lr, r2
>> 296 mov pc, lr
>>
>> board_init_r == 0xc10804e4 , $r0 == 0xc1080000 and $r7 == 0x7fff0000
>
> r7 == 0x7fff0000 seems totally wrong to me ... this would result that
> relocated board_init_r start @0x7fff04e4 ... thats not in RAM!
>
>> It turns out that the region I have assigned to CONFIG_SYS_SDRAM_BASE
>> (0x80000000) was reading as all 0' so even though get_ram_size was
>> returning 128M to dram_init, storing it in gd->ram_size didn't work.
>> Ditto for CONFIG_SYS_SDRAM_BASE set to 0xffff0000. I think this means
>> that only the DDR is available when UBL hands-off to u-boot.
>
> Why this values for CONFIG_SYS_SDRAM_BASE? They cannot work!
> As I see in the include/configs/da850evm.h file:
>
> #define PHYS_SDRAM_1 DAVINCI_DDR_EMIF_DATA_BASE /* DDR Start */
>
> so, RAM starts @DAVINCI_DDR_EMIF_DATA_BASE (=0xc0000000)
>
> -> CONFIG_SYS_SDRAM_BASE should/must be @0xc0000000
I was trying to "find another (not dram) area in which we can use for
an intial stack" as you suggested in <4C5B9DB5.7020009 at denx.de>. I
think I must have misunderstood what needed to be changed to
accomplish this.
> (Better would be a non RAM location for initial stack,
> but I don;t know if we have some area on this cpu for that)
8k at 0xffff0000 is an 'Arm local RAM' region and 128k at 0x80000000 is a
'Shared RAM' region. But neither seemed to be read as anything other
than 0x0000 when I was debugging. I think there would need to be some
magic writes first to enable these regions.
> Can you try
>
> http://git.denx.de/?p=u-boot/u-boot-testing.git;a=shortlog;h=refs/heads/arm-reloc-and-cache-support
>
> + remove in include/configs/da850evm.h
> line 42: #define CONFIG_SKIP_RELOCATE_UBOOT /* to a proper address, init done */
>
> ?
>
> If it don;t work, can you make a breakpoint in
> arch/arm/cpu/arm926ejs/start.S relocate_code and provide a register
> dump? And can you find out whats stored in gd->ram_size?
Most definitely. I'll get back to you shortly.
Best Regards,
Ben Gardiner
---
Nanometrics Inc.
http://www.nanometrics.ca
More information about the U-Boot
mailing list