Status Of 2.6 For Akita (sl-c1000) In Oz/gpe

[lardman]

Try something like this:

org.openembedded.dev/packages/linux/linux-openzaurus-2.6.14-git3/defconfig-cxx00

Si

[rpurdie]

I'd recommend anyone wanting to build 2.6 kernels for cxx00 devices to use the .dev branch. Recent 2.6 kernels have much better support for these devices but need too many changes to allow them to be imported into the release branch.

3.5.4 will not be released with a 2.6 kernel for the cxx00 but should be closely followed by a 3.5.4.1 release from the dev branch with images/2.6 kernels for these devices. A testing release of 3.5.4.1 is available at

http://ewi546.ewi.utwente.nl/mirror/sam.rp...urus/autobuild/

I'm aware the fstabs need fixing for borzoi/spitz (/home and /mnt/hdd should be automount) and that there are probably two copies of the hostap kernel module installed. Both have been fixed in OE since these images were generated.

[obergix]

Try something like this:

org.openembedded.dev/packages/linux/linux-openzaurus-2.6.14-git3/defconfig-cxx00

Si
[div align=\"right\"][a href=\"index.php?act=findpost&pid=107174\"][{POST_SNAPBACK}][/a][/div]

Thx.

I've integrated it in the .bb and changed accordingly linux-openzaurus.conf for it to be used.

The kernel compilation starts, but then stops on compilation error :

Code: [Select]

| sound/arm/pxa2xx-ac97.c: In function `pxa2xx_ac97_read':
| sound/arm/pxa2xx-ac97.c:52: warning: assignment from incompatible pointer type
| sound/arm/pxa2xx-ac97.c: In function `pxa2xx_ac97_write':
| sound/arm/pxa2xx-ac97.c:90: warning: assignment from incompatible pointer type
| sound/arm/pxa2xx-ac97.c: At top level:
| sound/arm/pxa2xx-ac97.c:184: warning: initialization from incompatible pointer type
| sound/arm/pxa2xx-ac97.c:192: warning: initialization from incompatible pointer type
| sound/arm/pxa2xx-ac97.c: In function `pxa2xx_ac97_suspend':
| sound/arm/pxa2xx-ac97.c:284: error: incompatible type for argument 2 of `pxa2xx_ac97_do_suspend'
| sound/arm/pxa2xx-ac97.c: In function `pxa2xx_ac97_probe':
| sound/arm/pxa2xx-ac97.c:353: warning: passing arg 2 of `snd_card_set_pm_callback' from incompatible pointer type
| make[2]: *** [sound/arm/pxa2xx-ac97.o] Erreur 1
| make[1]: *** [sound/arm] Erreur 2
| make: *** [sound] Erreur 2
| FATAL: oe_runmake failed
No much progress then in .oz354 ...

[obergix]

A testing release of 3.5.4.1 is available at

http://ewi546.ewi.utwente.nl/mirror/sam.rp...urus/autobuild/
[div align=\"right\"][a href=\"index.php?act=findpost&pid=107230\"][{POST_SNAPBACK}][/a][/div]

I've tested these (gpe / akita) and I've got problems resuming after a suspend.

When pressing the on button to resume, the mail led flashes, and that's all : no resuming

[lardman]

Have you reported it on the bugtracker?

Si

[obergix]

Have you reported it on the bugtracker?

Si
[div align=\"right\"][{POST_SNAPBACK}][/a][/div]

Not yet.. but I should.^H^H^H : done : #547 (http://bugs.openembedded.org/show_bug.cgi?id=547)

However, one previous problem with apm that I've reported doesn't seem to attract much interest : [a href=\"http://bugs.openembedded.org/show_bug.cgi?id=496]http://bugs.openembedded.org/show_bug.cgi?id=496[/url] (nor the workaround suggested : http://bugs.openembedded.org/show_bug.cgi?id=497 ) ... not very encouraging for users

[lardman]

There are only so many people with commit rights, and it's only those with a C1000 who will be willing to commit something (after they've tested it).

I also note that you make no explicit mention of the version of OZ you're running, nor the kernel version (I see the field which says OpenZaurus 3.5.3, but iirc there were no 3.5.3 images for the Akita, so this is a bit confusing).

The suspend script is useful, but ideally the apm behaviour would be fixed. Iirc, someone was talking about this bug on irc and noting that it may be a kernel issue rather than something to do with su.

If you have a specific issue which you think ought to be addressed, you'd be advised to get on irc on either #oe or #openzaurus and talk to the appropriate person (RP might be suitable, but you've not said what kernel version so I can't be sure).


Si

[obergix]

I also note that you make no explicit mention of the version of OZ you're running, nor the kernel version (I see the field which says OpenZaurus 3.5.3, but iirc there were no 3.5.3 images for the Akita, so this is a bit confusing).

Yeah, it happened on 3.5.4RC ... and btw, a corresponding value in version in bugtracker would be great

And the 2.4 standard kernel (only one available for akita onthat one

Sorry for not giving this detail in my report in the first place.

The suspend script is useful, but ideally the apm behaviour would be fixed. Iirc, someone was talking about this bug on irc and noting that it may be a kernel issue rather than something to do with su.

Indeed ... but in the meantime.... a usable workaround may help

If you have a specific issue which you think ought to be addressed, you'd be advised to get on irc on either #oe or #openzaurus and talk to the appropriate person (RP might be suitable, but you've not said what kernel version so I can't be sure).

I do that from time to time... but expect developers to read the bug tracker sometimes too

Thx.

[lardman]

They will read it, but as apm is closely related to the kernel they won't tend to respond unless they know this info, etc.

Anyway, I fear you may have troubles (with that kernel) as no-one really wants to fiddle with the rubbish Sharp kernel code. The 2.6.x kernel is the main thrust of work now and it's coming along nicely for the Akita afaik.

That said, as a temporary workround, your su thing might be acceptable if you must run with an old kernel - I believe the c1000 image will be released with a 2.4.20 kernel. Perhaps ask about this on irc and see whether any of the devs with a c1000 has had the same issue.


Si

[obergix]

FYI, interesting discussion about suspend/resume problems on akita with 2.6 in :
https://www.oesf.org/forums/index.php?showt...ndpost&p=108123

[obergix]

Just a note to report I've just tested gpe-image (gpe-image-akita-20060102193451.rootfs.img + zImage-2.6.14+2.6.15-rc7-akita-20060102193451.bin) generated in .dev on my akita.

The kernel stops the boot with the following messages when booted without the compact flash inserted :

Code: [Select]

VFS: Cannot open root device "hda1" or unknown-block(0,0)
Please append a correct "root=" boot option
Kernel panic - not syncing: VFS: Unable ro mount root fs on unknown-block(0,0)
And with the CF inserted, more or less the same :

Code: [Select]

Probing IDE interface ide0...
hda: SAMSUNG CF/ATA, CFA DISK drive
...
ide0: reset: success
 hda1
ide-cs: hda: Vcc = 3.3, Vpp = 0.0
Kernel panic - not syncing: VFS: Unable ro mount root fs on unknown-block(3,1)
As far as I understand that, it looks like the kernel is told to boot off an IDE drive... maybe the config for a SL-C3x00 ? ... but on the akita, no IDE boot device : only JFFS flash, I think...

Hope this helps,

[lardman]

Yes, looks like that is the case.

Can you add this to the bugtracker please: http://bugs.openembedded.org/


Si

[obergix]

Can you add this to the bugtracker please ?
[div align=\"right\"][{POST_SNAPBACK}][/a][/div]

Done : [a href=\"http://bugs.openembedded.org/show_bug.cgi?id=573]http://bugs.openembedded.org/show_bug.cgi?id=573[/url]

[obergix]

Just a note to report I've just tested gpe-image (gpe-image-akita-20060102193451.rootfs.img + zImage-2.6.14+2.6.15-rc7-akita-20060102193451.bin) generated in .dev on my akita.

[div align=\"right\"][a href=\"index.php?act=findpost&pid=109421\"][{POST_SNAPBACK}][/a][/div]

Just to tell you that the bug has been fixed, and at first sight, it looks like the 2.6 is working pretty well now for akita in .dev...

Will need additional testing, though

at least looks like it boots, suspends and resumes allright !

[obergix]

Will need additional testing, though

[div align=\"right\"][a href=\"index.php?act=findpost&pid=109765\"][{POST_SNAPBACK}][/a][/div]

My DLink DCF-660W wireless card doesn't seem to work out of the box... whereas it worked allright in 2.4 (3.5.4RC for instance).

However, after modprobing hostap-cs, I made it work. Dunno why it didn't recognize it automatically.

Now, it's dropbear which seems not to respond pretty well...

Actually no... it's just a bit slower than before to respond.

Cool, looks like it works !