Kernel source for 2008HE
 

I've been trying to locate the exact kernel source for 2008HE on 770 which identifies itself as
Linux - 2.6.16.27-omap1 #1 PREEMPT arm5tejl1 unknown

The binary comes in the SU-18_2008HACKER_4.2007.50-6_PR_F5_MR0_ARM.bin package, is 1268864 bytes long and the md5 is 4eb9d9c8d177fd5a6c81ebbd1272daf5. I've been trying to compile the exact same binary using the kernel-source-2.6.16_2.6.16.rel-osso29.tar.gz from the repository, but I can't get a binary zImage to match exactly. So it seems this kernel has at least some patches added to it.

Can someone point me to the sources and .config file used to build the kernel image in the 2008HACKER version ?

I'm interested because when using Fanoush's MMC kernels I got frequent crashes and reboots, while when using this kernel the device is quite stable. I intend to apply a patch to enable hardware scaling (which I need for running a lowres game) and the Fanoush patches to this stable kernel if I can first build an identical binary copy from the sources.

Re: Kernel source for 2008HE
 

You already have the right one.
http://repository.maemo.org/pool/gre...source-2.6.16/

You can't match it exactly at least due to compile date/time/machine '/proc/version' info included inside image. Due to zImage compression this may make whole image different. What is the length difference?

make n770_defconfig (?)

Hmm, the only unstable code is the 'overclocked' MMC, do you have troubles also with lower MMC speed kernels ? http://fanoush.wz.cz/maemo/#sdhc Particularly the 12MHz one?
EDIT:
And BTW, all those kernels have source patches and .config inside so you can omit just the MMC one (but anyway, disabling MMC multiblock writing and changing clock to 12 MHz should do the same trick). What MMC card you have? Maybe trying different card would make the device more stable?
Which patch it is? 770 hardware can do only pixel doubling (i.e. 2x) not full scalling and pixel doubling is already available in every 770 kernel so what would such patch provide? Well it can do also pixel halving but that feature is not so useful :-)

Re: Kernel source for 2008HE
 

Quick reply, thanks :)

1268864 2009-09-08 06:07 zImage
1279676 2008-04-08 08:54 zImage-12MHz
1279680 2008-04-08 08:56 zImage-24MHz

The first kernel is the one in 2008SE package; the second ones are your binaries. My closest binary seems to be

1270552 Sep 8 16:16 zImage

Based on compressed size difference, I'd say that something in the code is changed around there.

Tried it, it doesn't yield the same kernel; true, I don't see how the config may have changed, but not a bad idea to ask :)

Very unstable, I tried all three versions (12, 24, 48 MHz), all crashes with device reset within minutes of bootup. With the kernel included in the 2008HE, I had 12 hours of uptime streaming live radio, browsing the web, etc. This happens regardless if I use the MMC/swap file or not. Did you apply the wireless driver patches to your MMC kernels ?

It's actually screen rotate. The game draws in lanscape orientation and then I hardware rotate and double the screen. The codebase comes from Nintendo DS, and I sticked the two screens together with rotation and doubling to match the 770 screen; it doesn't fit perfectly, but good enough if you're not picky.

Re: Kernel source for 2008HE
 

And the one you built from clean repository sources is unstable too?
wireless driver is not in kernel so no, the fix is in module in initfs, 2008HE has it, kernel does not matter
Ah I see. Can you point me to the patch? I have actually tried something like that years ago (extending omapfb with rectangle rotation ioctl) but never finished/published it since it would need people to flash different kernel just to play some game. Also it would work sensibly only in full screen mode or square window.

EDIT: just checked old mail and I remember you now, sorry, we discussed it years ago and you sent your version of the code.

Re: Kernel source for 2008HE
 

Yep :o

You're right. But I tested several times with controlled conditions, changing just the kernel moves the device from rebooting every couple of minutes to stable for hours (actually it didn't crash so far on me with this kernel !).

It's very quick'n'dirty, allowing direct access from the game to the rotate method. Since I can't distribute the game, I didn't intend to distribute the patch, but it is here http://sandel.homeip.net/screenrotate.patch.

Re: Kernel source for 2008HE
 

It's obvious that something is changed in that kernel that makes my 770 go from unusable to actually pretty good. If I could move the MMC to 24MHz with the device remaining stable, I'd be able to pursue other projects with this platform.

Re: Kernel source for 2008HE
 

That's pretty strange. Will try to build it too just for fun and check the size. Maybe the difference can be in compiler version or compiler options?

Well, actually Nokia had/has different environment for building firmware then they later publish in SDK repository. With N800 it happened once that they shipped buggy and different kernel in SDK but later fixed it. Also they keep/kept separate debian changelog and version numbers in such firmware building environment so the version in /proc/version does not match. Maybe some bugfix patch could slip away too after all?

Yes, that's exactly the code you sent in mail previously. Thanks.

Re: Kernel source for 2008HE
 

Well, it's obviously not the same kernel. I just tested kernel host mode, and it crashes (reboot) when inserting ohci-hcd.ko, which previously went fine. So far it's either WiFi or Host mode so far with this kernel.

I'll dig deeper to see what can be done; if someone @ Nokia can shed some light, it would be great - while I don't see the 770 as a useful handheld device, I think it may be a great platform for remote control photo cameras and such :).

Re: Kernel source for 2008HE
 

Looks like it is from same source, at least according to changelogs, same kernel is in all HE versions and latest OS2006 firmware. Flasher prints
According to debian changelog inside
http://repository.maemo.org/pool/gre.../su-18-kernel/
it is indeed built from osso29 source.

Could you paste full /proc/version string? Maybe the compiler is different? I have similar size to yours when compiled inside 2.2/Gregale SDK (gcc version 3.4.4 (release) (CodeSourcery ARM 2005q3-2)) but I have just compiled it with uclibc toolchain (gcc version 3.4.2 (release) (CodeSourcery ARM Q3D 2004)) which is used for compiling 770 initfs binaries and the size is 1268820 bytes which is pretty near. The binary is here, I have not tested it at all. Also when thinking about it maybe 2.0 SDK could have same older compiler too? EDIT: no, it has same 3.4.4

Still, all my kernels are rock solid on my device so I wonder how different compiler could cause erratic behaviour only on some 770s.

Re: Kernel source for 2008HE
 

I've always been amazed at my device instability, and always wondered how you guys had the patience to put up with it. WIth the new kernel however for the first time the device is rock solid ( including gphoto2, I've managed to get it to work in USB host mode, it needs manually disabling g_file_storage and manually mounting swap !), so this is why I'm digging deeper.

The 'good' kernel version string is:
Linux version 2.6.16.27-omap1 (bifh1@doree) (gcc version 3.4.2 (release) (CodeSourcery ARM Q3D 2004)) #1 PREEMPT Tue Sep 19 16:46:58 EEST 2006

I'm using gcc version 3.4.4 (release) (CodeSourcery ARM 2005q3-2), which is the standard gcc in the SDK; I'm gonna test your binary kernel and see how stable it is. If it's stable, should we suspect a gcc 3.4.4 bug ?

Later EDIT: No crashes in the few minutes I've been testing the your kernel; with old kernels I usually saw a crash in this timeframe. So it appears the gcc version matters, at least for my device... Do you have a link to where I can download the version you used for this binary ? I'm also gonna build a 4.1 gcc for armel just to give it a test.

Re: Kernel source for 2008HE
 

I'm not sure, but hopefully it is one of those two scratchbox-toolchain-arm-gcc3.4.cs-uclibc-* in http://scratchbox.org/download/files...0.9.8/tarball/ . EDIT: it is the non-sf one.

In scratchbox when installed it appears in /scratchbox/compilers/arm-linux-gcc3.4.cs-uclibc0.9.27 and in scratchbox target info I also see name arm-linux-gcc3.4.cs-uclibc0.9.27. I have extracted the tar.gz version into my regular 1.0.x scratchbox, created new scratchbox target with this compiler via sb-menu and it works.

It could be interesting to check System.map vmlinux etc. from both compilers and see where in the code is the difference. Could be compiler bug but in theory it could be also faulty RAM in your device. You may be just lucky to have kernel with specific 'correct' bits in specific location.

Re: Kernel source for 2008HE
 

I don't think I have the patience to disassemble both kernels and check differences; this would be the starting point to hunt a gcc bug.

Very good point ! How do I test that ? Did you find anything in the initfs that would allow RAM testing in factory tests ?

I'm thinking compiling a kernel with just enough features to boot the device, run the FB and modify the initfs to run as init a modified memtest to output to framebuffer should yield some results. If I can find some spare hours tonight I'll try it, but otherwise it will have to wait until next week.

Re: Kernel source for 2008HE
 

It is quite unlikely so maybe first lets change something harmless like patching with just rotation patch or slightly change kernel configuration (like disabling Magic SysRq key in Kernel hacking section) and see if the stability is gone. if not then add various combinations of other patches. Either it remains stable (compiler bug or faulty ram in not changed code) or specific patch breaks it (code bug) it or it will be random (faulty RAM somewhere in changed code?).
[/QUOTE]
No. Some memtester that could be run from userspace is mentioned in the wifi memory corruption bug page. However if faulty bit(s) is only in the place where kernel code resides one would need to boot custom code to test it or maybe hack the kernel to uncompress itself into different RAM space and then test it from userspace.

Re: Kernel source for 2008HE
 

Hi,

I just build the gcc 4.4.1 targeted to ARM, and the vanilla kernel using the gcc 4.4.1.

I got it out at
1262256 Sep 18 20:06 arch/arm/boot/zImage

I'll test it later tonight, and if stable I'll throw in the MMC patches for 48, 24, 12 MHz.

If those are stable as well, I'll release new kernel images.

Re: Kernel source for 2008HE
 

Can you share gcc 4.4.1 packages for armel?