[U-Boot] [RFC][PATCH v2 17/19] arm cp15: setup mmu and enable dcache

[Ben Gardiner]

On Fri, Aug 6, 2010 at 1:29 AM, Heiko Schocher <hs at denx.de> wrote:
> Hello Ben,
>
> Ben Gardiner wrote:
>> I'm sorry I don't have more details than that, it is serial-console
>> connected only and there is no jtag debugger setup here (yet).
>
> I think you must debug this ...
>
>> I'm not sure if the board was dead because of my failure to merge the
>> patch that did not apply cleanly or if it is because of the
>> CONFIG_SYS_INIT_SP_ADDR 'Fix this' in the da850evm.h -- I haven't
>> changed the value from 'CONFIG_SYS_SDRAM_BASE + 0x1000 -+
>> CONFIG_SYS_GBL_DATA_SIZE' introduced in 15/19.
>
> Ah, so your board is the da850evm, right? This should be no problem,
> as dram is setup at this point, but we should find another (not dram)
> area, which we can use for an initial stack.

Yes. I'm sorry I forgot to mention that up-front.

Thanks for the idea. I think that there are two possible regions for
the initial stack. I have tried putting the initial stack in the
'shared ram' region and the 'ARM local RAM' region. In both cases I
did this by redefining CONFIG_SYS_INIT_SP_ADDR in the
include/configs/da850evm.h file.

First, for the 'shared ram' region which is 128k at 0x80000000 I tried:
#define CONFIG_SYS_INIT_SP_ADDR (0x80000000 + 128*1024 -1)

The board did not come up, and I think it is because the ldr argument
is limited; it appears that the value loaded into sp is wrong:

c1080078 <call_board_init_f>:
c1080078:       e59fd328        ldr     sp, [pc, #808]  ; c10803a8 <fiq+0x48>
c108007c:       e3a00000        mov     r0, #0  ; 0x0
c1080080:       eb00017f        bl      c1080684 <board_init_f>

Then for the 'ARM local RAM' which is 8k at 0xffff0000 I tried:
#define CONFIG_SYS_INIT_SP_ADDR (0xffff0000 + 8*1024 -1)

The board still did not come up event though the proper value _is_
being loaded into sp:

c1080078 <call_board_init_f>:
c1080078:       e3e0da0e        mvn     sp, #57344      ; 0xe000
c108007c:       e3a00000        mov     r0, #0  ; 0x0
c1080080:       eb00017f        bl      c1080684 <board_init_f>

But maybe this region is not available so early, I don't really know.

I then tried modifying the call_board_init_f routine so that it loaded
the start of the region into sp and added to it the CONFIG_STACK_SIZE
macro:

c1080078 <call_board_init_f>:
c1080078:       e3a0d102        mov     sp, #-2147483648        ; 0x80000000
c108007c:       e28dd701        add     sp, sp, #262144 ; 0x40000
c1080080:       e3a00000        mov     r0, #0  ; 0x0
c1080084:       eb00017e        bl      c1080684 <board_init_f>

which gets a reasonable address into sp for this early setup, but the
board still doesn't come up.

I'm currently at a loss. I'll get an emulator on this board setup soon.

I'd appreciate anyone's insights into my problems here even if it is
to say I'm totally missing the point. :)

>> I would be happy to test the next version of the series but it would
>> be much easier to do so if there was a branch in u-boot-testing as
>> suggested by Detlev.
>
> Ok.

Thank you for making this series available in u-boot-testing.


Best Regards,
Ben Gardiner

---
Nanometrics Inc.
http://www.nanometrics.ca