Long story short, I wanted to update Mer 0.16 to use Debian SID repos instead of Ubuntu, which led to udev being updated, which now necessitates a kernel upgrade.

Anyway, I grabbed the latest CodeSourcery arm-none-linux-gnueabi toolchain, checked out the 2.6.32 branch of the Linux-OMAP git, used a supposedly working config from http://natisbad.org/N810/index.html, and built a kernel. That went OK, so I booted into Maemo and copied the new modules to the initfs (I figure they're necessary to boot anything).

After flashing the kernel, I don't even get to the bootmenu, it just shuts down at the Nokia logo. Any ideas as to what I'm doing wrong here? I'm guessing it has something to do with the initfs, but am hardly knowledgeable in that area.

I really don't care about messing anything up, for what it's worth, so don't worry about that. Also, I'm running Gentoo, if that makes a difference.

Thanks.

Try building 2.6.30-rc8 first since that is supposed to be working and see if it boots. You should probably also enable rd mode and disable watchdogs.

Yeah, I probably should, but shouldn't even a vanilla kernel boot to some extent, at least to the boot menu?

Also, is there some way to get boot output over USB?

Termana had a 2.6.33 working without bigger issue, I think..

Any links to the aforementioned stuff? My search only turned up Android stuff which, if I remember rightly, only really works with Android.

I did try building the stock Diablo 2.6.21 kernel, which booted at least to the initfs, so at least I know my setup is capable of building a booting kernel.

So with the latest Linux-OMAP head (2.6.34-rc3, I believe, I don't know the exact commit), the built kernel behaves a little differently. Instead of just sitting there at the "Nokia" pre-initfs screen, it shuts down after ~2 seconds.

I'll try copying modules over and see if that helps, but any other thoughts/ideas/anything?

Well, that didn't work.

Questions:

1. There's got to be a better way to test kernels than choosing commits, building, flashing, etc. Any guides I've missed? Any way to at least get some boot output over USB or something?

2. Is there a better place to be poking around for this stuff? People I should be contacting?

3. Even building the exact revision specified with the supposedly working config doesn't boot (same behavior as other builds; wait a bit, shutdown). The config doesn't work on it's own, though, it needs TSC2005 (touchscreen driver, I believe) added to compile. Maybe my setup's messed up?

Thanks.

I managed to get 2.6.29 booting using directions here:

http://maemodeviceitself.blogspot.co...et-tablet.html

It doesn't fully boot, though (just shuts down after a while on the screen with the two hands). Also an issue is that the keyboard doesn't seem to work- no choosing what to boot into in bootmenu.

I got the STL45xx Wi-Fi driver to build against it as well, though obviously haven't tested it.

Any thoughts (on these issues or otherwise) would be great; fixes or help would be even better.

See also this thread (very non-obvious title so you may have missed it).

Well, hopefully this'll be the last issue (wireless potentially aside).

Every kernel I've tried that's not the Diablo one doesn't boot fully (to either Maemo or Mer). It looks like it will (see previous post), but then shuts down. From the Mer boot output, it seems to not even always be at the same point.

I'm in R&D mode ("sudo flasher --enable-rd-mode --set-rd-flags=no-omap-wd,no-lifeguard-reset,no-ext-wd" is the command I've used), since, if I'm not, it just reboots pretty much right away.

For what it's worth, Maemo shuts down very shortly after getting to the desktop when in R&D mode as well, when using the standard 2.6.21 kernel.

So what am I doing wrong? My impression was that disabling all the watchdogs and lifeguard reset should prevent this.

EDIT: It would seem that xserver-xomap doesn't work with the updated kernels...

EDIT2: Disabling the watchdog prevent shutdown option (in the kernel, 2.6.33 w/patches from linked thread) lets me at least stop the rebooting when Xomap fails to start, but isn't helpful aside from that.