Re: Good news

sorry everyone, squirrelmail doesn't get the reply addr, so here are our
two mails, and my reply.

I wrote:

>> Hello
>> We have good news, we are sure that haret can successfully finish his
>> job, we added the video ram fill code just in front of the last jump
>> instruction, and it works.
>
> Good, so we can begin getting the kernel to do things.
>
>> when I run haret, the penguin disappears
>> and the total screen's color changed to blue. And after I run the
>> newest cvs haret, with only ram address in memory.cpp is changed (to
>> 0xa8000000), it died, but after I poke the reset button (soft
>> reset),it actually execute a hard reset. but without changing the ram
>> base address (keep 0xa0000000), it execute a soft reset. so, I think
>> our ram base address is correct and the kernel is loaded.(some parts
>> of ram has be changed at 0xa8000000 case, so wince automatically do a
>> hard reset to clear the ram and reboot)
>
> If this is changed i think we might need to change the adresses the pxa
> framebuffer driver uses also. This is something to figure out and test.
>
>> And I have tried the kernel you sent me , doesn't work, and no seiral
>> output, can you get serial output with this kernel with
>> "console=ttyS0" command ?
>
> I have no serial cable, i do have a infrared sender/receiver, but i
> haven't been able to get my computer receiver working. I think this should
> work with a working serial cable.
>
> I think a logical next step is to put the assambler code to make the sceen
> blue into the kernel and move it step by step. This is a straight forward
> way of discovering the problem, if it doesn't work the problem isn't in
> the kernel. (well, if you are correct, it has to be ;) but at least the
> possibilities for what the problem is are shrinking.)
>
>> --
>> Fisherss
>> fisherss_at_gmail.com
>
> Mvg,
> Môshe van der Sterre
> http://www.moshe.nl/
> http://www.coecu.nl/

Fisherss wrote:

>> If this is changed i think we might need to change the adresses the pxa
>> framebuffer driver uses also. This is something to figure out and test.
> So do you know where should I change ? in which file ?
> My video ram address is the same as x30, (0x5c001000,physical
> address),is this the framebuffer's address ?
>
>> I think a logical next step is to put the assambler code to make the
>> sceen
>> blue into the kernel and move it step by step. This is a straight
>> forward
>> way of discovering the problem, if it doesn't work the problem isn't in
>> the kernel. (well, if you are correct, it has to be ;) but at least the
>> possibilities for what the problem is are shrinking.)
> I think so. Do you know which file is the first section of kernel
> after compiled?
> some one told me it should be head.S, and other told me it shouldn't be
> that.
>
> --
> Fisherss
> fisherss_at_gmail.com

And i reply:

> So do you know where should I change ? in which file ?
> My video ram address is the same as x30, (0x5c001000,physical
> address),is this the framebuffer's address ?

I need te check that out (i'm not home right now), it is in aximx??_lcd.c,
but i don't know what to change exactly, and we better first try to see
how far the kernel goes.

> I think so. Do you know which file is the first section of kernel
> after compiled?
> some one told me it should be head.S, and other told me it shouldn't be
> that.

definitly in arch/arm/boot, we shouldn't put code where the kernel is
busy, but anywhere that gets executed very soon should be fine.

> --
> Fisherss
> fisherss_at_gmail.com

Mvg,
Môshe van der Sterre
http://www.moshe.nl/
http://www.coecu.nl/
Received on Wed May 25 2005 - 08:46:19 EDT