[okl4-developer] okl4 on arm1136jfs goes haywire

[Ashish Bijlani]

Hi Geoffrey,

I tried loading the kernel to 0x8010 0000 (this is the start of the
ram in machines.py file under the platform) which now i believe maps
to f000 0000, still I observe the same behavior? Am I missing
something? What should be the load addr in RAM if it starts at 0x8000
0000?

Thanks,
Ashish

On Mon, Jul 21, 2008 at 11:17 PM, Ashish Bijlani
<ashish.bijlani at gmail.com> wrote:
> 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
>>>
>>
>> --
>>
>>
>