public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
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

  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