Upgrading Android Kernel

[Rudolf Tammekivi]

My device has 2.6.35.7 source code provided, but I want to upgrade it to 3.0. Most of the 2.6.35.7 sources are from CodeAurora, which are modifed by manufacturer, and I have already downloaded the 3.0 base for msm. What are the mandatory things I need to modify in order to make it boot? Like CPU, display, memory.

[jagan]

What is your device QC Chipset?

-If you your phone chipset supports the downloaded msm kernel, try to download msm-2.6.35[chipset supportable].

do the diff b/w   msm-2.6.35 to your device kernel, identify the device spec changes & apply them on msm-3.0.

Be-careful you need to do it in a procedural way.

Regards,

Jagan.

On Sat, Jan 21, 2012 at 11:46 PM, Rudolf Tammekivi <rtamm...@gmail.com> wrote:

My device has 2.6.35.7 source code provided, but I want to upgrade it to 3.0. Most of the 2.6.35.7 sources are from CodeAurora, which are modifed by manufacturer, and I have already downloaded the 3.0 base for msm. What are the mandatory things I need to modify in order to make it boot? Like CPU, display, memory.

--
unsubscribe: android-kerne...@googlegroups.com
website: http://groups.google.com/group/android-kernel

[Rudolf Tammekivi]

It's MSM7x30, and when I am browsing through the manufacturer's code,
I see they have taken the msm7x30 board and simply modified for their
needs. So I am currently trying to do the same.
What do you mean by "procedural way"? I did an early build, after the
boot logo, it simply turned off/screen turned off, USB did not work. I
did try this on the recovery, because that should not need all things
Android needs, right?

Is there a way to save the log somewhere (like /cache or /data), so I
could check what did not work and get a start somewhere.

On Jan 24, 8:41 am, jagan <402ja...@gmail.com> wrote:
> What is your device QC Chipset?
> -If you your phone chipset supports the downloaded msm kernel, try to
> download msm-2.6.35[chipset supportable].
> do the diff b/w   msm-2.6.35 to your device kernel, identify the device
> spec changes & apply them on msm-3.0.
>
> Be-careful you need to do it in a procedural way.
>
> Regards,
> Jagan.
>

[jagan]

Is there a way to save the log somewhere (like /cache or /data), so I
could check what did not work and get a start somewhere.

> there is a debug procedure called, RAM_CONSOLE, find it on google[enough info]

Regards,

Jagan.

[Rudolf Tammekivi]

The ram_console is very interesting, but how should I get it, if it
does not boot? Does it matter if I boot recovery or Android?

On Jan 24, 10:01 pm, jagan <402ja...@gmail.com> wrote:
> Is there a way to save the log somewhere (like /cache or /data), so I
> could check what did not work and get a start somewhere.> there is a debug procedure called, RAM_CONSOLE, find it on google[enough
>
> info]
>
> Regards,
> Jagan.
>

[jagan]

Usually when we'r directly working on device, RAM_CONSOLE is better choice.

To setup this we have a ram_console driver at drivers/staging/android path [enable it] & you just create a 

platform device entry in BSP code.

Once you have any crash/hang happening on your device, for next the reboot try to dump the log from

/proc/last_kmsg [where you can get the previous crash log]...debug it

Regards,

Jagan.

[Rudolf Tammekivi]

I said it does not boot (crashes directly on boot, does not do a
reboot), so that's not an option. But now I am thinking MMC is not
working... My device has all partitions on one MMC. And is there a way
to somehow initialize USB before anything else? To see whether it
works or not...

On Jan 25, 6:41 pm, jagan <402ja...@gmail.com> wrote:
> Usually when we'r directly working on device, RAM_CONSOLE is better choice.
>
> To setup this we have a ram_console driver at drivers/staging/android path
> [enable it] & you just create a
> platform device entry in BSP code.
>
> Once you have any crash/hang happening on your device, for next the reboot
> try to dump the log from
> /proc/last_kmsg [where you can get the previous crash log]...debug it
>
> Regards,
> Jagan.
>

[jagan]

That's what, I too taking about.

If your device doesn't boot, unable to see any logs....So try to enable RAM_CONSOLE in working & as well

as non-working kernel [your case].

Boot the non-working kernel first & try to boot the working kernel & get the crash log.

BR, Jagan.

[Rudolf Tammekivi]

So it works in any case. Thanks, I'll check it out and post the
result.

On Feb 1, 8:55 am, jagan <402ja...@gmail.com> wrote:
> That's what, I too taking about.
>
> If your device doesn't boot, unable to see any logs....So try to enable
> RAM_CONSOLE in working & as well
> as non-working kernel [your case].
> Boot the non-working kernel first & try to boot the working kernel & get
> the crash log.
>
> BR, Jagan.
>

[Rudolf Tammekivi]

I think I managed to get ram_console working on the working kernel, it
gives this in kmsg:

<6>[1, swapper] [ 0.256378] ram_console: got buffer at 3a00000,
size 40000
<6>[1, swapper] [ 0.256408] ram_console: no valid data in buffer
(sig = 0x20008808)
<6>[1, swapper] [ 0.256561] console [ram-1] enabled

But is there a way to do a manual panic, to see whether it outputs the
log or not?

Regards,
Rudolf.

[Rudolf Tammekivi]

I had the address wrong, so upon reboot, it got stuck. I modified it
to be the last part of the RAM, and the sig seems to be 0xffffffff
always. I'd like to know how to "force" a panic, so I could check
whether it writes something or is the sig still 0xffffffff. The size
is 1M.

As I understand, when panic happens, RAM stays full of memory. Then,
when reboot, ram_console checks if there is a sig with the data, and
then writes it to last_kmsg, right?