[ECOS] redboot RAM and it's memory address

[ECOS] redboot RAM and it's memory address

[Holger Schurig]

Okay, after I followed the textbook and compiled eCos CVS for my XScale PXA 
(Accelent IDP) target, I got no more errors and 
install/bin/redboot.{elf|bin|img|srec}.

My aim is to let the current bootloader (where I don't have source) let the 
system initialize and run my redboot in RAM. The current bootloader can 
execute Linux, so there should be a way to let it execute something 
different.

So, speaking of Linux: when I arm-elf-objdump vmlinux (that is what the 
current bootloader gets, in some WinCE NK.BIN format), then I see

c0008000 <stext>:
c0008000:       e1a0c000        mov     r12, r0
c0008004:       e3a000d3        mov     r0, #211        ; 0xd3
c0008008:       e121f000        msr     CPSR_c, r0

but when I arm-elf-objdump install/bin/redboot.elf, then I see

00020000 <__exception_handlers>:
   20000:       e59ff018        ldr     pc, [pc, #18]   ; 20020 <vectors>
   20004:       e59ff018        ldr     pc, [pc, #18]   ; 20024 
<.undefined_instruction>
...
00020020 <vectors>:
   20020:       00020040        andeq   r0, r2, r0, asr #32
...
00020040 <reset_vector>:
   20040:       e3a00000        mov     r0, #0  ; 0x0
   20044:       e59f1388        ldr     r1, [pc, #388]  ; 203d4 
<_eCos_id+0x14>



My question:

I guess I have to simple edit 
ecos/packages/hal/arm/xscale/idppxa/current/include/pkgconf/mlt_arm_xscale_idppxa_ram.h 
and mlt_arm_xscale_idppxa_ram.ldi so that it uses 0xc0008000, too?  Maybe 
something like

#include <cyg/infra/cyg_type.inc>

MEMORY
{
    ram : ORIGIN = 0xc0000000, LENGTH = 0x02000000
}

SECTIONS
{
    SECTIONS_BEGIN
    SECTION_fixed_vectors    (ram, 0xc0000020,           LMA_EQ_VMA)
    SECTION_rom_vectors      (ram, 0xc0008000,           LMA_EQ_VMA)
    SECTION_text             (ram,          ALIGN (0x4), LMA_EQ_VMA)
    SECTION_fini             (ram,          ALIGN (0x4), LMA_EQ_VMA)
    SECTION_rodata           (ram,          ALIGN (0x4), LMA_EQ_VMA)
    SECTION_rodata1          (ram,          ALIGN (0x4), LMA_EQ_VMA)
    SECTION_fixup            (ram,          ALIGN (0x4), LMA_EQ_VMA)
    SECTION_gcc_except_table (ram,          ALIGN (0x4), LMA_EQ_VMA)
    SECTION_data             (ram,          ALIGN (0x4), LMA_EQ_VMA)
    SECTION_bss              (ram,          ALIGN (0x4), LMA_EQ_VMA)
    CYG_LABEL_DEFN(__heap1) = ALIGN (0x8);
    SECTIONS_END
}

Greetings, Holger


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] redboot RAM and it's memory address

[Jonathan Larmour]

Holger Schurig wrote:
> 
> So, speaking of Linux: when I arm-elf-objdump vmlinux (that is what the 
> current bootloader gets, in some WinCE NK.BIN format), then I see
> 
> c0008000 <stext>:
> c0008000:       e1a0c000        mov     r12, r0
> c0008004:       e3a000d3        mov     r0, #211        ; 0xd3
> c0008008:       e121f000        msr     CPSR_c, r0
> 
> but when I arm-elf-objdump install/bin/redboot.elf, then I see
> 
> 00020000 <__exception_handlers>:
>    20000:       e59ff018        ldr     pc, [pc, #18]   ; 20020 <vectors>
>    20004:       e59ff018        ldr     pc, [pc, #18]   ; 20024 
> <.undefined_instruction>
> ...
> 00020020 <vectors>:
>    20020:       00020040        andeq   r0, r2, r0, asr #32
> ...
> 00020040 <reset_vector>:
>    20040:       e3a00000        mov     r0, #0  ; 0x0
>    20044:       e59f1388        ldr     r1, [pc, #388]  ; 203d4 
> <_eCos_id+0x14>

Doesn't necessarily matter. execution starts at the start address defined 
in the ELF header, not just the beginning of the file. These may be different.

> My question:
> 
> I guess I have to simple edit 
> ecos/packages/hal/arm/xscale/idppxa/current/include/pkgconf/mlt_arm_xscale_idppxa_ram.h 
> and mlt_arm_xscale_idppxa_ram.ldi so that it uses 0xc0008000, too? 

If that's where the board manual says the RAM is, then that would 
ordinarily be better, *but* there is a known limitation in the ARM eCos 
port, which means RAM must be mapped to 0x0. That can be done by the 
startup code tweaking the MMU mappings though. You may have to write this. 
That idppxa port is nothing to do with us - I haven't seen it, and so 
can't help. Complain to Intel (assuming they did it, as the Lubbock port 
is in the same boat) that they should submit it for inclusion in the 
public eCos.

Jifl
-- 
eCosCentric       http://www.eCosCentric.com/       <info@eCosCentric.com>
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] redboot RAM and it's memory address

[Mark Salter]

> Holger Schurig wrote:
>> 
>> So, speaking of Linux: when I arm-elf-objdump vmlinux (that is what the 
>> current bootloader gets, in some WinCE NK.BIN format), then I see
>> 
>> c0008000 <stext>:
>> c0008000:       e1a0c000        mov     r12, r0
>> c0008004:       e3a000d3        mov     r0, #211        ; 0xd3
>> c0008008:       e121f000        msr     CPSR_c, r0
>> 
>> but when I arm-elf-objdump install/bin/redboot.elf, then I see
>> 
>> 00020000 <__exception_handlers>:
>> 20000:       e59ff018        ldr     pc, [pc, #18]   ; 20020 <vectors>
>> 20004:       e59ff018        ldr     pc, [pc, #18]   ; 20024 
>> <.undefined_instruction>
>> ...
>> 00020020 <vectors>:
>> 20020:       00020040        andeq   r0, r2, r0, asr #32
>> ...
>> 00020040 <reset_vector>:
>> 20040:       e3a00000        mov     r0, #0  ; 0x0
>> 20044:       e59f1388        ldr     r1, [pc, #388]  ; 203d4 
>> <_eCos_id+0x14>

...

>> My question:
>> 
>> I guess I have to simple edit 
>> ecos/packages/hal/arm/xscale/idppxa/current/include/pkgconf/mlt_arm_xscale_idppxa_ram.h 
>> and mlt_arm_xscale_idppxa_ram.ldi so that it uses 0xc0008000, too? 

Don't be fooled by the 0xc0008000 in vmlinux. That is a kernel virtual address
and tells you nothing about where the physical address may be. The vmlinux code
is position independent up to the point where linux turns on the MMU. RAM where
that code runs may or may not be 0xc0008000.

--Mark

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] redboot RAM and it's memory address

[Holger Schurig]

> That idppxa port is nothing to do with us - I haven't seen it, and so
> can't help. Complain to Intel (assuming they did it, as the Lubbock port
> is in the same boat) that they should submit it for inclusion in the
> public eCos.

The idppxa port is not done by Intel, I try to do it. Note that I *try* it, 
I'm sometimes feeling very stupid. For example, only up to today I've got the 
RAM initialisation of the idppxa working (not necessarily correct, timings 
may be overly slow).

Because I derived my works on GPLed code (e.g. the hal/arm/xscale/verde and 
hal/arm/xscale/iq80321 directories), the result will also be GPL, but 
currently nothing works really. At least it compiles now cleanly with your 
help.


The not-yet-working stuff is available from 
http://www.mn-logistik.de/unsupported/pxa250/ if anybody is interested.


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] redboot RAM and it's memory address

[Holger Schurig]

> That idppxa port is nothing to do with us - I haven't seen it, and so
> can't help. Complain to Intel (assuming they did it, as the Lubbock port
> is in the same boat) that they should submit it for inclusion in the
> public eCos.

The idppxa port is not done by Intel, I try to do it. Note that I *try* it, 
I'm sometimes feeling very stupid. For example, only up to today I've got the 
RAM initialisation of the idppxa working (not necessarily correct, timings 
may be overly slow).

Because I derived my works on GPLed code (e.g. the hal/arm/xscale/verde and 
hal/arm/xscale/iq80321 directories), the result will also be GPL, but 
currently nothing works really. At least it compiles now cleanly with your 
help. I have to do at least

- get virtual memory right
- memory initialisation (today I've go the memory initialized with my BDI2000
  JTAG gadget, so I know the principle)
- flash support

My *NOT*YET*WORKING* stuff is available at 
http://www.mn-logistik.de/unsupported/pxa250/redboot.tar.bz2


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] redboot RAM and it's memory address

[Holger Schurig]

> Don't be fooled by the 0xc0008000 in vmlinux. That is a kernel virtual
> address and tells you nothing about where the physical address may be. The
> vmlinux code is position independent up to the point where linux turns on
> the MMU. RAM where that code runs may or may not be 0xc0008000.

Okay, that makes sense. The PXA250 has SDRAM physically at  A000 0000 ...


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] redboot RAM and it's memory address

[Holger Schurig]

> Don't be fooled by the 0xc0008000 in vmlinux. That is a kernel virtual
> address and tells you nothing about where the physical address may be. The
> vmlinux code is position independent up to the point where linux turns on
> the MMU. RAM where that code runs may or may not be 0xc0008000.

Okay, that makes sense. The PXA250 has SDRAM physically at  A000 0000 ...


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss