spitz (zaurus sl-c3000) support

Hi!

I got spitz machine today. I thought oz3.5.3 for spitz would be 2.6-based, but found out that I'm not _that_ fortunate.

What's the status of spitz? I see log from 2.6.12-rc boot, and pages at http://www.orca.cx/zaurus/ seem to be old...

Is there simple way to tell spitz and tosa apart (like without opening the machine)?

Aha, I realized that spitz support came into 2.6.14-rc2, so something definitely _is_ happening. Are there newer patches than orca.cx somewhere?

Pavel

Thanks, Sharp!

oz 3.5.4 is due for release soon and will hopefully have a 2.6 option for spitz.

Its outdated now.

At what level? machine_is_spitz() and machine_is_tosa()? There are some checks in the sharpsl head file to auto detect all the Zaurus machines and set the machine numbers. For those two machines the difference is the presence of the tc6393 chip in tosa. See head-sharpsl.S

I got a spitz recently which moved 2.6 for it forwards a lot. Have a look at:

http://www.rpsys.net/openzaurus/

This file should give you an idea of which patches to apply in what order:
http://www.rpsys.net/openzaurus/temp/linux-openzaurus_2.6.14-rc1.bb

With my patch series applied, we're missing usb client (usb host works) and sound support.

Mainline is missing power management and currently fails to compile without my patch series but I'm working on that.

Richard

Hi!

Is there chance to get preview version somewhere? 2.6-capable userland would be very nice (and zImage would help, too, just for a demo :-).

I was thinking about "huh, is this machine tosa or spitz", but it is labeled SL-C3000, so it should be spitz.

Wildly offtopic... I got poweradapter with spitz (with funny design) that says 100V (and lot of japanese letters).. I guess it would be very bad idea to try it at 240V?

Quite a long list; what is $RPSRC -- that is where are those patches really placed? Is there some way I can help you (besides obviously testing)?

Yes, asm/arch/ohci.h seems to be missing... But I should probably do update, I'm at rc2 with my zaurus hacks now.

Pavel

Thanks, Sharp!

I'm no sure offical preview images exist but here's something I built myself recently:

http://www.rpsys.net/openzaurus/temp/spitz/

Rename the gpe or opie file "hdimage1.tgz" to flash depending on what flavoured image you'd like. You need the other files including gnu-tar. You don't need an initrd.bin file as under 2.6 we can boot directly from the microdrive.

I'm hoping these work - I'm not sure I've tried one of them... :)

Correct. Tosa is SL-C6000.

Trust me, its a very bad idea...

Its declared in:
http://www.rpsys.net/openzaurus/temp/linux-openzaurus.inc

so $RPSRC = http://www.rpsys.net/openzaurus/patches

You probably don't need the ipaq hx2750 or tosa patches, they're just part of my tree. The top 15 patches have been merged since -rc1 came out (they were in the process of being merged at the time).

That's still a problem although a patch queued for 2.6.15 will add that file so I'm in two minds as to what to do with it. There's also an issue with struct pxafb_device which I've agreed a solution to, just need to write the patch and I think a reference to the battery device sneaked into mainline when it shouldn't have done.

I'm open to any help in getting the none ipaq/tosa things merged with mainline. Have a look through them patch series and see if there's anything you fancy taking on. Most of them are simple fixes although some are nasty hacks we need to find some way of doing nicely.

The biggest thing is the battery/power management patch. I've just agreed some changes to enable it to stand a chance of making mainline. It probably needs more coding style cleanup.

There's also sound to get working although so code arrived yesterday which should help with that. The usb client code exists in handheld.org's kernel26 cvs tree. We need to extract it, fix any bugs and talk to the usb developers about it.

Its a shame you don't have a C1000 as there's a nasty bit of coding someone with such a device needs to do to complete mainline 2.6 support (I2C driver for its IO Expander to enable access to its extra GPIOs).

Richard

Hi!

Thanks. Kernel works, even with 3.5.3 opie. [But touchscreen gets extremely interesting, you have to click top-right corner to get it to register click in bottom-left].

You mean I should place tar binary on flashcard, because updater.sh needs it? [What is updater.sh anyway, xor 0x5e encrypted shell script?!]

Oh, okay, one more question. Do you trust your battery charging code enough to leave spitz overnight in charger? I would hate to be awaken by angry lithium ;-).

Pavel

Thanks, Sharp!

Yes, there's a bug in the opie (qte specifically) calibration code which is fixed in 3.5.4 (I fixed it). I ended up replacing qte's algorithm with a decent 5 point one.

Yes, place the file as gnu.tar on the flashcard with updater.sh. updater.sh is indeed an "encrypted" shell script! There are tools around to decode/encode it.

My spitz has been left plugged in all the time with my charging code and has yet to explode. ;-) Its very similar to the c7x0 code which people have happily been using for a while in OpenZaurus c7x0 2.6. Spitz does contain a charging chip which should prevent major damage to the battery. The software just tries to help it along...

Cheers,

Richard

Hi!

...

Yes, now it updated correctly. Thanks!

Charge led does not go off, but pavouk (has c7x0) told me that's pretty much normal. It made me a bit nervous.
Pavel

Boycott Kodak -- for their patent abuse against Java.

The charge LED should go off but it won't if the device isn't suspended as when running, the device draws enough current to keep the charger active.

Help on improving the charging code is of course welcome ;-)

Richard

Hi!

Of course :-). Question: is there some reasonable way to get the spitz patches, or maybe to just get all of your patches? I was doing

#!/bin/bash
# # > #http://www.rpsys.net/openzaurus/temp/linux-openzaurus_2.6.14-rc1.bb # #
# # Quite a long list; what is $RPSRC -- that is where are those #patches
# # really placed?
#
#Its declared in:
#http://www.rpsys.net/openzaurus/temp/linux-openzaurus.inc

RPSRC=http://www.rpsys.net/openzaurus/patches

# You probably don't need the ipaq hx2750 or tosa patches, they're just

# part of my tree. The top 15 patches have been merged since -rc1 came
out
# (they were in the process of being merged at the time).

for A in pxa_i2c_fixes-r0.patch pxa_ohci_platform-r1.patch pxa_ohci_suspend-r0.patch poodle_irda-r0.patch ide_not_removable-r0.patch sharpsl_pm-r8.patch corgi_pm-r4.patch spitz_base_extras-r2.patch spitz_pm-r4.patch spitz_kbd_fix1-r0.patch spitzcf-r3.patch pxa_timerfix-r0.patch pxa_remove_static-r0.patch pxa_irda-r4.patch corgi_irda-r3.patch pxa_rtc-r1.patch input_power-r2.patch jffs2_longfilename-r0.patch sharpsl_bl_kick-r1.patch corgi_snd-r10.patch pxa2xx-ir-dma-r0.patch tc6393-device-r5.patch tc6393_nand-r6.patch pcmcia_dev_ids-r2.patch mmc_timeout-r0.patch pxa_cf_initorder_hack-r1.patch; do
# wget $RPSRC/$A
cat /data/l/zaurus/spitz.patches/$A | cg-patch
pshell
done

.... but that's ather poor trick. Few patches broke the download (slow line here), and few of them broke compilation later...

Pavel

Thanks, Sharp!

[MTD] Update the pre-CFI Sharp driver sharps.c so it compiles. map_read32 / map_write32 no longer exist in the kernel so the driver is totally broken as it stands. The replacement functions use different parameters resulting in the other changes.

Change collie to use this driver until someone works out why the cfi driver fails on that machine.

Index: linux-2.6.14/arch/arm/mach-sa1100/collie.c
===================================================================
@@ -119,7 +119,7 @@
 }
 
 static struct flash_platform_data collie_flash_data = {
-	.map_name	= "cfi_probe",
+	.map_name	= "sharp",
 	.set_vpp	= collie_set_vpp,
 	.parts		= collie_partitions,
 	.nr_parts	= ARRAY_SIZE(collie_partitions),