[okl4-developer] okl4 faults on arm1136

[Ashish Bijlani]

Hi Geoffrey,

How do I verify if the bootinfo is being patched correctly? Is there
some linker script that does it?

Thanks,
Ashish

On Tue, Jul 22, 2008 at 9:04 PM, Geoffrey Lee <glee at ok-labs.com> wrote:
> On Tue, Jul 22, 2008 at 08:59:39PM -0500, Ashish Bijlani wrote:
>> Here are more debugging messages:
>>
>> Debug: Setting up rootserver mappings: V:3000 P:8012a000 S:1000 (0)
>> Debug: Setting up rootserver mappings: V:100000 P:801a0000 S:39984 (1)
>> Debug: Setting up rootserver mappings: V:142000 P:80602000 S:3e02c (2)
>> Debug: Setting up rootserver mappings: V:2000 P:80123000 S:1000 (3)
>> Debug: Setting up rootserver mappings: V:200000 P:80700000 S:100000 (4)
>>
>> The system doesn't seem to be loading rootserver info properly in the
>> function "asm_switch_to".
>> I guess the stack pointer "sp" in function "asm_switch_to" is not
>> being setup correctly.
>>
>> I see the following line commented out in function "init_root_servers"
>>
>> /** @todo FIXME: Enable once user-level crt0's are fixed - awiggins. */
>> //tcb->set_user_sp((addr_t)(server_info->sp));
>
>
> Hi Ashish,
>
> Please have a look at the user-level crt0.  You will find the sp for the
> roottask is set to zero, and the stack address is obtained from
> the bootinfo.
>
>>
>> Why is the stack pointer not set as per the rootserver info struct?
>>
>> Function "asm_switch_to" passes STACK_TOP as the stack pointer to the
>> roottask. Could this be the reason?
>
>
> No, the behavior of asm_switch_to() is correct.  What you see in
> asm_switch_to() is the kernel stack pointer being reset to STACK_TOP
> and has nothing to do with the value of the user thread's stack pointer.
>
>
>>
>> -Ashish
>
>        -gl
>
>>
>>
>> On Tue, Jul 22, 2008 at 8:30 PM, Ashish Bijlani
>> <ashish.bijlani at gmail.com> wrote:
>> > Hi,
>> >
>> > OKL4 faults on arm1136jfs when starting the roottask at addr
>> > 0xf000e0c0 with stack top = 0x3f8 and stack size 1024 bytes. Any idea
>> > why? I'm loading okl4 at 0x8010 0000 (start of the RAM).
>> >
>> > Below are the boot msgs:
>> >
>> > Uncompressing OKL4.....................done, booting the kernel.
>> > Info: Interrupt Controller found at 0xf90fe000 (rev. 2.1) with 96 interrupts
>> > OKL4 - (provider: Open Kernel Labs) built on Jul 22 2008 04:23:06
>> > using gcc version 3.4.4.
>> > Initializing kernel debugger...
>> > Initializing interrupts...
>> > Info: Disabling FIQs
>> > Processor Id => 4107b362: v6, ARM1136, rev 2
>> > VFP CoProcessor Supported
>> > VFP System Id => 410120b4: ARM, Format 1, Precision Single+Double,
>> > VFPv2, PartNo 20, Rev 5,
>> > Initializing timer...
>> > Info: Unmasking IRQ 37
>> > TLB lock: vectors @ ffff0000
>> > TLB lock: utcb @ ff000000
>> > TLB lock: kernel @ f0000000
>> > Locked kernel into TLB
>> > Init mutexids for 256 mutexs
>> > Init clistids for 16 clists
>> > Initialising scheduler...
>> > Switching to idle thread
>> > Debug: Moving to addr f00079e4 with stack f001f3f8
>> > Initializing root servers
>> > root-servers: utcb_area: eff00100 (64KB)
>> > creating root server (00000001)
>> > Debug: System Started
>> > Debug: Current Thread ID = 0x1d1e1d1e
>> > Debug: Next Thread ID = 0x00000001
>> >
>> > Thanks,
>> > Ashish
>> >
>>
>> _______________________________________________
>> Developer mailing list
>> Developer at okl4.org
>> https://lists.okl4.org/mailman/listinfo/developer
>>
>
> --
>
>