[okl4-developer] okl4 on arm1136jfs goes haywire

[Ashish Bijlani]

Hi,

I'm loading binary file at address 0x8000 8000 which maps to 0xf000 000 virtual

-ashish

On Mon, Jul 21, 2008 at 10:55 PM, Geoffrey Lee <glee at ok-labs.com> wrote:
> On Fri, Jul 18, 2008 at 12:11:16PM -0500, Ashish Bijlani wrote:
>> Hi,
>>
>
> Hi Ashish
>
> Can you let us know how you are booting the binary (ELF load, as
> binary image, etc?), and which address you loaded it to in physical
> memory?
>
>        -gl
>
>> I'm trying to run okl4 on arm1136jfs. The kernel seems to be going
>> haywire once virtual memory is switched on. Any ideas why? Am I not
>> passing memory info correctly? Could it be because of the compiler
>> flags?
>>
>> The config file is pasted below :-
>>
>> class Device(arm1136js):
>>     memory = arm1136js.memory.copy()
>>     cpp_defines = arm1136js.cpp_defines
>>
>> class Board(Device):
>>     virtual = False
>>     memory = Device.memory.copy()
>>     memory['physical'] = [Region(0x80008000L, 0x88000000L)]
>>
>> Please note that I'm compiling code for arm1136jfs and using configs
>> from arm1136js class in "arch/arm/tools/machine.py". I'm using
>> gcc-3.4.4.
>>
>> Upon disassembling the image.boot, I can see kernel.kspace section is
>> loaded at 0x8002c00 (physical) and 0xf0024000 (virtual)
>>
>> From Section Headers:
>> kernel.kspace 00004000  8002c000  8002c000  0002c000  2**14 CONTENTS,
>> ALLOC, LOAD, DATA
>>
>> From Symbol Table:
>> f0024000 l    d  kernel.kspace  00000000
>> f0024000 g     O kernel.kspace  00004000 _kernel_space_pagetable
>>
>> Kernel goes haywire immediately after "switch_to_virt()" in
>> "init_memory()". It seems to be accessing kernel page tables/page dir
>> at address 0x8002e000  and 0x8002fc00. It then goes on forever as if
>> in a loop. Looks like the virtual-physical translation causes it to
>> loop forever.
>>
>> I'm using gcc-3.4.4. Below is the code generated by the assembler
>>
>> Here r1 = 0x80008000 is "phybase" in the function "init_memory", which
>> is the start of the ram - mentioned in the device specific config.
>>
>> "
>> 800245ec:       ee012f10        mcr     15, 0, r2, cr1, cr0, {0}
>> 800245f0:       e261320f        rsb     r3, r1, #-268435456     ;
>> 0xf0000000  { if r1=0x80008000 then r3 = 0x6FFF8000, which is
>> "_start"}
>> 800245f4:       e08dd003        add     sp, sp, r3
>> 800245f8:       e08f0003        add     r0, pc, r3 {r0 = 0xF001C5F8 =
>> virtual(pc = 0x800245c) }
>> 800245fc:       e1a0f000        mov     pc, r0  { pc becomes
>> physical(0xF001C5F8) = 0x800245c -- which means it'll keep looping
>> here??? }
>> 80024600:       e1a00007        mov     r0, r7 { Shouldn't this be the
>> addr loaded in pc in the above stmt in order to go to the next stmt? }
>>
>> "
>> Upon carefully observing the above generated code, I noticed that the
>> addr loaded in "pc" should be virtual(0x80024600), so that control
>> goes to the next stmt with MMU enabled. This means that the value
>> loaded in r3 be 0xF0000000(VIRT_ADDR_RAM) + 4 (1 address word). This
>> in turn means that in "switch_to_virt()"  the value of
>> "KERNEL_RO_OFFSET" should be (VIRT_ADDR_RAM - *(physbase)) + 4.
>>
>> Does this logic make sense? Am I missing something? Or the code is
>> generated incorrectly? Please lemme know.
>>
>> However, when I tried changing "KERNEL_RO_OFFSET" to  "(VIRT_ADDR_RAM
>> - *(physbase)) + 4", there was no behavior changed observed in the
>> kernel. The kernel still seems to be going haywire immediately after
>> "switch_to_virt()" in "init_memory()". It seems to be accessing kernel
>> page tables/page dir at address 0x8002e000  and 0x8002fc00. It then
>> goes on forever as if in a loop. Looks like the virtual-physical
>> translation causes it to loop forever.
>>
>> Am I missing something? Kindly lemme know.
>>
>> Any help would be appreciated.
>>
>> Thanks,
>> Ashish
>>
>> _______________________________________________
>> Developer mailing list
>> Developer at okl4.org
>> https://lists.okl4.org/mailman/listinfo/developer
>>
>
> --
>
>