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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox