From: Heiko Schocher <hs@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [RFC][PATCH v2 17/19] arm cp15: setup mmu and enable dcache
Date: Wed, 11 Aug 2010 07:56:44 +0200 [thread overview]
Message-ID: <4C623B9C.80902@denx.de> (raw)
In-Reply-To: <AANLkTim42rhr-957XwTNWXhAzzDPiJPx11zyBT9790Jr@mail.gmail.com>
Hello Ben,
Thanks for trying this patches!
Ben Gardiner wrote:
> On Fri, Aug 6, 2010 at 12:44 PM, Ben Gardiner
> <bengardiner@nanometrics.ca> wrote:
>> On Fri, Aug 6, 2010 at 12:32 PM, Reinhard Meyer
>> <reinhard.meyer@emk-elektronik.de> wrote:
>>> The value loaded into SP is IN the location at PC+808... look there.
>>>> About in 0xc1080078+0x0328 give or take a word.
>>>>
>>> And well, the location is mentioned right behind the ;
>>>
>>> c1080078: e59fd328 ldr sp, [pc, #808] ; c10803a8
>>> <fiq+0x48>
>> Right. My mistake.
>>
>> Thank you Reinhard and Wolfgang for helping me out here. The values at
>> the location c10803a8 are correct in all cases.
>>
>> I guess I will definitely need to use a jtag debugger here to figure
>> out what's going wrong.
>
> I did get an openocd debugger going with uboot on the da850 (see the
Good!
> post to the openocd dev list for the board and target configuration
> files for the da850 and omapl138 [1]).
>
> 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 tried putting the initial stack pointer in DDR with:
> #define CONFIG_SYS_SDRAM_BASE 0xc0000000
Ok.
> #define CONFIG_SYS_INIT_SP_ADDR (0xc0700000 - 16)
This is somewhere in RAM, so I think that should work.
(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)
> and found that I could get the furthest into booting if I also did:
> #define CONFIG_SKIP_RELOCATE_UBOOT and
No, this is definitely wrong. With that define, code gets not
copied to the calculated relocation address!
> diff --git a/arch/arm/cpu/arm926ejs/start.S b/arch/arm/cpu/arm926ejs/start.S
> index cb27cee..a228b53 100644
> --- a/arch/arm/cpu/arm926ejs/start.S
> +++ b/arch/arm/cpu/arm926ejs/start.S
> @@ -286,8 +286,10 @@ _nand_boot: .word nand_boot
> #else
> ldr r0, _TEXT_BASE
> ldr r2, _board_init_r
> +#ifndef CONFIG_SKIP_RELOCATE_UBOOT
> sub r2, r2, r0
> add r2, r2, r7 /* position from board_init_r in RAM */
> +#endif /* #ifndef CONFIG_SKIP_RELOCATE_UBOOT */
Hmm.. with that, you use in r2 the not relocated address
from board_init_r ... thats not what we want.
> /* setup parameters for board_init_r */
> mov r0, r5 /* gd_t */
> mov r1, r7 /* dest_addr */
>
> along with:
> #define CONFIG_RELOC_FIXUP_WORKS
That is not the right way. Without that, for example the fixup from
the commandtable is not done, so your commands are broken.
> to avoid some of the reloc stuff in arch/arm/lib/board.c. But then the
> boot fails because the serial device cannot be registered as stdout
> because calloc fails which results in an invalid puts function
> pointer.
>
> I'm not sure what to try next -- any help would be appreciated.
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?
Thanks!
bye
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
next prev parent reply other threads:[~2010-08-11 5:56 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-29 10:45 [U-Boot] [RFC][PATCH 17/19] arm cp15: setup mmu and enable dcache Heiko Schocher
2010-07-30 9:11 ` Nick Thompson
2010-07-30 9:31 ` Alessandro Rubini
2010-07-30 9:32 ` Heiko Schocher
2010-07-30 9:57 ` Nick Thompson
2010-07-30 10:13 ` Heiko Schocher
2010-08-03 10:16 ` [U-Boot] [RFC][PATCH v2 " Heiko Schocher
2010-08-05 18:22 ` Ben Gardiner
2010-08-06 5:29 ` Heiko Schocher
2010-08-06 15:41 ` Ben Gardiner
2010-08-06 15:46 ` Wolfgang Denk
2010-08-06 16:14 ` Ben Gardiner
2010-08-06 16:27 ` Reinhard Meyer
2010-08-06 16:32 ` Reinhard Meyer
2010-08-06 16:44 ` Ben Gardiner
2010-08-10 17:45 ` Ben Gardiner
2010-08-11 5:56 ` Heiko Schocher [this message]
2010-08-11 13:31 ` Ben Gardiner
2010-08-11 13:53 ` Ben Gardiner
2010-08-11 17:06 ` Heiko Schocher
2010-08-11 19:56 ` Wolfgang Denk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C623B9C.80902@denx.de \
--to=hs@denx.de \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.