Hi Aneesh,
On Wed, Sep 21, 2011 at 7:21 AM, Aneesh V <ane...@ti.com> wrote:
> Hi Simon,
>
> On Wednesday 21 September 2011 03:04 AM, Simon Glass wrote:
>> Hi Anthony,
>>
>> On Tue, Sep 20, 2011 at 7:22 AM, GROYER, Anthony
>> <anthony.gro...@airliquide.com> wrote:
>>>
>>> Hello,
>>>
>>> I came back on a discussion started on April 2011.
>>>
>>> The use of the initial patches for the CONFIG_SYS_SKIP_ARM_RELOCATION
>>> features has revealed two issues.
>>>
>>> First issue: the calculation of the relocation offset was done only if the
>>> relocation is actually done. So we could reach a point where r9 has a wrong
>>> value, since it has never been used before (in my case, this bug happens
>>> without JTAG). The first diff moves the relocation offset calculation
>>> before the test of a relocation need.
>>>
>>> Second issue: board_init_r was thinking the memory area for the malloc is
>>> just below the code, whereas the board_init_f had allocated some space for
>>> the malloc at the end of the SDRAM. If the code is located at the base of
>>> the SDRAM with CONFIG_SYS_SKIP_ARM_RELOCATION defined, the malloc area does
>>> not point to a correct memory address.
>>> The 2 other diff store the calculated malloc start address in a global data
>>> member so that it can be used in board_init_r().
>>
>> Thanks for coming back to this. Hopefully you can do patches for the
>> other CPU types also as Albert requests - and I can test armv7 when
>> you do that. This feature is one that I use a lot with an ICE and I
>> would like to see it in U-Boot.
>
> Are you looking for CONFIG_SYS_SKIP_ARM_RELOCATION? I think Anthony is
> only fixing couple of issues uncovered by the original 'skip
> relocation' patch but I don't think CONFIG_SYS_SKIP_ARM_RELOCATION
> itself is getting accepted.
I see. That is sad, because skipping relocation is very useful for
development. Why do we make things harder for devs than they need to
be?
Regards,
Simon
>
> best regards,
> Aneesh
>
>>
>> Regards,
>> Simon
>>
>>>
>>> Index: arch/arm/cpu/arm926ejs/start.S
>>> ===================================================================
>>> --- arch/arm/cpu/arm926ejs/start.S (révision 1083)
>>> +++ arch/arm/cpu/arm926ejs/start.S (révision 1113)
>>> @@ -196,6 +196,10 @@
>>> mov r4, r0 /* save addr_sp */
>>> mov r5, r1 /* save addr of gd */
>>> mov r6, r2 /* save addr of destination */
>>> + /* set relocation offset here for all cases:
>>> + relocation or not */
>>> + ldr r0, _TEXT_BASE /* r0 <- Text base */
>>> + sub r9, r6, r0 /* r9 <- relocation offset */
>>>
>>> /* Set up the stack
>>> */
>>> stack_setup:
>>> @@ -218,8 +222,6 @@
>>> /*
>>> * fix .rel.dyn relocations
>>> */
>>> - ldr r0, _TEXT_BASE /* r0 <- Text base */
>>> - sub r9, r6, r0 /* r9 <- relocation offset */
>>> ldr r10, _dynsym_start_ofs /* r10 <- sym table ofs */
>>> add r10, r10, r0 /* r10 <- sym table in FLASH */
>>> ldr r2, _rel_dyn_start_ofs /* r2 <- rel dyn start ofs */
>>> Index: arch/arm/include/asm/global_data.h
>>> ===================================================================
>>> --- arch/arm/include/asm/global_data.h (révision 1083)
>>> +++ arch/arm/include/asm/global_data.h (copie de travail)
>>> @@ -69,6 +69,7 @@
>>> unsigned long mon_len; /* monitor len */
>>> unsigned long irq_sp; /* irq stack pointer */
>>> unsigned long start_addr_sp; /* start_addr_stackpointer */
>>> + unsigned long start_addr_malloc; /* start_addr_malloc */
>>> unsigned long reloc_off;
>>> #if !(defined(CONFIG_SYS_NO_ICACHE) && defined(CONFIG_SYS_NO_DCACHE))
>>> unsigned long tlb_addr;
>>> Index: arch/arm/lib/board.c
>>> ===================================================================
>>> --- arch/arm/lib/board.c (révision 1138)
>>> +++ arch/arm/lib/board.c (copie de travail)
>>> @@ -367,6 +367,7 @@
>>> * reserve memory for malloc() arena
>>> */
>>> addr_sp = addr - TOTAL_MALLOC_LEN;
>>> + gd->start_addr_malloc = addr_sp;
>>> debug ("Reserving %dk for malloc() at: %08lx\n",
>>> TOTAL_MALLOC_LEN >> 10, addr_sp);
>>> /*
>>> @@ -445,7 +446,6 @@
>>> {
>>> char *s;
>>> bd_t *bd;
>>> - ulong malloc_start;
>>> #if !defined(CONFIG_SYS_NO_FLASH)
>>> ulong flash_size;
>>> #endif
>>> @@ -473,9 +473,7 @@
>>> post_output_backlog ();
>>> #endif
>>>
>>> - /* The Malloc area is immediately below the monitor copy in DRAM */
>>> - malloc_start = dest_addr - TOTAL_MALLOC_LEN;
>>> - mem_malloc_init (malloc_start, TOTAL_MALLOC_LEN);
>>> + mem_malloc_init (gd->start_addr_malloc, TOTAL_MALLOC_LEN);
>>>
>>> #if !defined(CONFIG_SYS_NO_FLASH)
>>> puts ("Flash: ");
>>>
>>> Regards,
>>> Anthony Groyer
>>>
>>>> On Wed, Apr 20, 2011 at 11:56 PM, Aneesh V <ane...@ti.com> wrote:
>>>>> Hi Simon, Wolfgang,
>>>>>
>>>>> On Thursday 21 April 2011 12:04 AM, Simon Glass wrote:
>>>>>>
>>>>>> On Fri, Mar 25, 2011 at 11:35 AM, Albert ARIBAUD<albert.arib...@free.fr>
>>>>>> wrote:
>>>>>>>
>>>>>>> Le 25/03/2011 17:12, Aneesh V a écrit :
>>>>>>>
>>>>>>>> Another problem I have with relocation is that it makes debugging with
>>>>>>>> JTAG debugers more difficult. The addresses of symbols in the ELF
>>>>>>>> target are no longer valid. Of course, you can load the symbols at an
>>>>>>>> offset from the original location. But one has to first enable debug
>>>>>>>> prints, find the relocation offset, use it while loading the symbols
>>>>>>>> before you can do source level debugging.
>>>>>>>
>>>>>>> Actually you don't need recompiling: simply set a breakpoint at the
>>>>>>> entry of relocate_code and once you hit the bp, look up r2: it contains
>>>>>>> the destination. If you want the offset rather than the absolute
>>>>>>> address, set the breakpoint right after the 'sub r9, r6, r0' round line
>>>>>>> 222: r9 will then give you the offset. Unload the current symbols,
>>>>>>> reload the symbols with the relevant offset, and there you go.
>>>>>>
>>>>>> I would like to revisit this thread. I'm not sure how other people do
>>>>>> development in U-Boot but I like to use an ICE and a source-level
>>>>>> debugger for any significant effort. I think it should be possible to
>>>>>> use a JTAG debugging just by loading the u-boot ELF file and running.
>>>>>>
>>>>>> With this patch (or something similar) this is possible. Without it,
>>>>>> it is painful.
>>>>>>
>>>>>> To be clear, we are not talking here about creating a platform that
>>>>>> doesn't use relocation, just that for development purposes it is
>>>>>> convenient to be able to disable it.
>>>>>
>>>>> Actually, I am not even sure why relocation shouldn't be disabled in my
>>>>> platform for good. It may be useful to have things such as the frame
>>>>> buffer at the end of available memory. But, IMHO, that can still be
>>>>> done without relocating u-boot. That's what the patch does.Am I missing
>>>>> something?
>>>>
>>>> Well relocation does remove a lot of this ad-hoc positioning of things
>>>> at compile time. I think it is desirable. My point is that it is not
>>>> engineer-friendly during development, and we should have an easy way
>>>> to disable it for debugging / JTAG purposes.
>>>>
>>>> Regards,
>>>> Simon
>>>>
>>>>>
>>>>>>
>>>>>> Looking at the December thread
>>>>>> http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/88067/focus=88262
>>>>>>
>>>>>> Aneesh:
>>>>>>>>
>>>>>>>> Shouldn't we provide a CONFIG option by which users can disable
>>>>>>>> Elf relocation?
>>>>>>
>>>>>> Wolfgang:
>>>>>>>
>>>>>>> Why should we? It would just make the code even more complicated, and
>>>>>>> require a lot of additional test cases.
>>>>>>
>>>>>> From what I can see this is a new CONFIG option, two ifdefs in the
>>>>>> board.c file, and optionally disabling the -pie position-independent
>>>>>> executable option to reduce size. It is pretty trivial:
>>>>>>
>>>>>> arch/arm/config.mk | 2 ++
>>>>>> arch/arm/lib/board.c | 5 +++++
>>>>>> 2 files changed, 7 insertions(+), 0 deletions(-)
>>>>>>
>>>>>> Regards,
>>>>>> Simon
>>>>>>
>>>>>>>
>>>>>>> Amicalement,
>>>>>>> --
>>>>>>> Albert.
>>>>>>> _______________________________________________
>>>>>>> U-Boot mailing list
>>>>>>> U-Boot@lists.denx.de
>>>>>>> http://lists.denx.de/mailman/listinfo/u-boot
>>>>>>>
>>>>>
>>>> _______________________________________________
>>>> U-Boot mailing list
>>>> U-Boot@lists.denx.de
>>>> http://lists.denx.de/mailman/listinfo/u-boot
>>>>
>>> _______________________________________________
>>> U-Boot mailing list
>>> U-Boot@lists.denx.de
>>> http://lists.denx.de/mailman/listinfo/u-boot
>>>
>> _______________________________________________
>> U-Boot mailing list
>> U-Boot@lists.denx.de
>> http://lists.denx.de/mailman/listinfo/u-boot
>
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
