fast 6000 kernel, along with special libsdl

[xjqian]

The fast kernel is awesome. thanks for keeping up the good work. however, I do have some question related to the kernel thing.

First of all, my original understanding of a NAND restore is to wipe out everything and the system should look exactly as before. but the kernel flashing make me confused
 
(1) on ffpe fast kernel, I restored NAND image from stock sharp kernel
I found except for the alphanumerical keys, all the other parts of my keyboards were all maped wrong. Other symptoms like reboot didn't work, neither from Qtopia nor from console. The styles in Appearance setting are missing. If I chose to rotate screen to the other orientatino in the Appearance, my z froze. All sorts of weird things. I have to flash it back to the stock kernel+rom to correct for it.

(2) on no-ffpe fast kernel, I restored NAND image from ffpe enabled fast kernel
The "dang dang" notification sound everytime you reboot are gone. Some game from Znester won't work anymore. That's the only ones I noticed, but there is a difference. The "dang dang" sound didn't recover even I swich back to the no-ffpe kernel.

So, can some body explain the relationship between kernel and NAND to me? seems my understandings of the basics are wrong here?

And I'm pretty sure the firefox, konqueror etc. frozen problem in debian must be caused by the ffpe as I switched back and forth several times. adf, how did you get around this problem?


btw, when I switch between no-ffpe and ffpe fast kernel, I assume I don't need to replace those lib/modules and symb links again. Am I right?

[guylhem]

But... since you are already revving up your toolchain....   any luck compiling a softfloat mplayer?  I'd love to give it a spin if you have (though the reglar mplayer is working pretty nicely)

and....  any thoughts on pushing qtopia 2.1 through the soft-float chain to see what happens? Though that sounds like a headache waiting to happen.... and with a maybe limited payoff to boot.  I had heard rumor that the hancom stuff installed with hancom libs on a softfloat system would be ok though......
[div align=\"right\"][a href=\"index.php?act=findpost&pid=63486\"][{POST_SNAPBACK}][/a][/div]

Thanks a lot for the kind message. I'm happy I'm helping someone besides myself. There're other tweaks I should post - let's say I have a very "customised" SL6000 :-)

Bust first, a clarification for the precedent message with a nand question: nand reflash may or may not overwrite the kernel- depends on what you flash. On a sl6000 you have 2 (!) copies of the kernel and 2 filesystems. A couple is normally used, while the other kernel+filesystem couple is used only during reflash (so you can reflash if shit happens)

Then that reflash process only reflash what it's asked. If it does the kernel - fine. If it doesn't... you just overwrite the normal filesystem, which creates a weird previous-kernel+flashed-filesystem couple used for normal operations. How can you find out if your flash is correct ? Use uname -a. Read my flash pages to simply overwrite the kernel and keep the rest intact -because there's no reason to reflash everything unless you do something very bad, likely under root with the root partition mounted rw.

That being said, I unfortunately don't have enough time to do all I'd like, so I have to make an agenda. Here's my current agenda for the Sl6000:
 - 1. learn qtopia. Will help a lot with many issues (phone app, calendar, ...) I have. And I should have done that much earlier !!
 - 2. update the kernel to match tetsu's version. take advantage of that to fix the kerboard problems (basically I tried to remap internal keyboard so it would play nice with an external usb keyboard in console mode. I also wanted to remap events to short/long apps keypresses. Bad idea. I screwed up big. I'll also compile iptables modules - will help a lot.
 - 3. try to tweak the libsdl a little more. I am very interested in cwaig acceleration stuff. But I can't do that alone :-) mplayer acceleration would also be very interesting.
 - 4. then play with softfloat. a libsdl/mplayer/emulators suite with video acceleration *AND* softfloat would be interesting : I think vga video playback at a good framerate might be possible
 - 5. make hostap work with usb wireless card. possible - someone did hack that, but a) with an old version of hostap  only gave the source to Jouli who couldn't send me a copy (lost file IIRC). Has to be done again from scratch, but would help with kismet, wellenreiter and co.
 - 6. finally try to do a full rom with softfloat. this goes last because I'm still curious about the opie/qtopia situation, and because more people could do that besides me - with more efficiency since they're used to do roms :-) But with the opie/qtopia story, I still don't know exactly what I should do.

Anyway IMHO the most important for the SL6000 right now would be video acceleration.

From the chip documentation:

.7.3 2D Graphics Acceleration
TC6393XB supports the acceleration as below.
- Fill
- SourceCopy
- StretchBLT
- LineDraw

By using this hardware accelerator, you can realize improvement in a performance and reduction of power consumption.

6.7.3.1 Fill
The “Fill” function of TC6393XB supports as below.
- Rectangle field range: 1 ~ 1,024 Pixel x 1 ~ 1,024Pixel
- Fill color: 16bit color
- Support function: Raster Operation (ROP3)
6.7.3.2 SourceCopy
The “SourceCopy” function of TC6393XB supports as below.
- Rectangle field range: 1 ~ 1,024 Pixel x 1 ~ 1,024Pixel
- Support function: Raster Operation (ROP3), Transparent
6.7.3.3 StretchBLT
The “StretchBLT” function of TC6393XB supports as below.
- Rectangle field range: 1 ~ 1,024 Pixel x 1 ~ 1,024Pixel
The “StretchBLT” function of TC6393XB does not support Raster Operation (ROP3) and Transparent. And, it is not possible that the expansion and reduction ratio of vertical is different from one of horizontal.
6.7.3.4 LineDraw
The “LineDraw” function of TC6393XB supports as below.
- Rectangle field range: 1 ~ 1,024 Pixel x 1 ~ 1,024Pixel
- Draw color: 16bit color
- Support function: Raster Operation (ROP3)

Yet there's no information on how to do that. And even if there was, I don't now ATM how it should be implemented in mplayer/libsdl. So congrats to cwaig for the work he did - he is making that possible. From the mere possibility to a full implementation in mplayer and libsdl, there's a long long way! If there're other SL6000 hackers, let's try to do something !

[adf]

outstanding agenda.... all the stuff that is needed and I don't know how to do and am not likely to learn in time.
thanks again

[cwaig]

Hi all (guyhelm - got your PM the other day, just hadn't got round to replying...)

The TC6393 accelleration stuff doesn't require any extra kernel level support at all 'coz the API's exposed via the fb driver.

I'd kind of worked out that it could do some of the stuff that's listed in the info Guylhem posted from looking at the kernel driver header files. Not had much time to look into it any further (rectangles working, line draw partially working, but not fully).

What I was thinking was that as a first step it'd be a doddle to add the hardware rectangle code I've already got working to SDL for a first cut at a proper SL6000 specific build, but it won't actually get us that much of a performance boost in everyday use.

But....what I'm also thinking is that I could take the Sharp QTE library, pull out the QWS objection file from it, add in a patched version where rectangles are drawn using the hardware and voila - super fast Qtopia on the SL6000. That would really be worth the effort if Sharp haven't done it already, as there's a lot of rectangle drawing in the Qtopia GUI....

(of course, I'll try to work out the rest of the hardware stuff as well)

[guylhem]

Hi all (guyhelm - got your PM the other day, just hadn't got round to reply

That's fine. There's no hurry.

What I was thinking was that as a first step it'd be a doddle to add the hardware rectangle code I've already got working to SDL for a first cut at a proper SL6000 specific build, but it won't actually get us that much of a performance boost in everyday use.

Excellent - I will send you want a copy of my latest sources. Please tell me your email.
You may also want to track the "off-by-20-pixels" display bug I couldn't fix.

But....what I'm also thinking is that I could take the Sharp QTE library, pull out the QWS objection file from it, add in a patched version where rectangles are drawn using the hardware and voila - super fast Qtopia on the SL6000. That would really be worth the effort if Sharp haven't done it already, as there's a lot of rectangle drawing in the Qtopia GUI....

SDL won't be for everyday use, but it can easily be tested (SDL test apps display framerate...) and it should be much easier than recompiling qtopia. Moreover since we don't have sharp non-free extension (ex: libsl, libdtm...) many non-free apps won't run on a free built.

(of course, I'll try to work out the rest of the hardware stuff as well)

I'll try to take care of hostap/usb. Besides that, it might be interesting to include Z axis to the touchscreen driver - especially for Petite Peinture.. I've got a patch from Wolfson if you want to give it a try.

[cwaig]

But....what I'm also thinking is that I could take the Sharp QTE library, pull out the QWS objection file from it, add in a patched version where rectangles are drawn using the hardware and voila - super fast Qtopia on the SL6000. That would really be worth the effort if Sharp haven't done it already, as there's a lot of rectangle drawing in the Qtopia GUI....

SDL won't be for everyday use, but it can easily be tested (SDL test apps display framerate...) and it should be much easier than recompiling qtopia. Moreover since we don't have sharp non-free extension (ex: libsl, libdtm...) many non-free apps won't run on a free built.

Slight misunderstanding there - what I intend to do is a hack of the Sharp supplied QPE binary library - it hopefully won't impact on compatibility at all

[adf]

fabulous.... with any luck at all we will see Qtopia2.1 Rom from Qtopia (according to lpotter) guylhem's kernel/libSDL with further refinements and cwaigs sharp QTE hack arriving in the near future. Hammering them all together might make something pretty interesting

[pldrouin]

I've compiled the kernel with iptables support and support for my Socket ethernet card and these two things work very well, along with the SD module from the Sharp ROM. However, I'm unable to use the wi-fi card. I've copied the p80211 module from the Sharp rom and have loaded it, but when I try to connect with the wi-fi card, my Z freezes and need to be rebooted. What could be wrong?

Thanks

[selfabuse]

I've compiled the kernel with iptables support and support for my Socket ethernet card and these two things work very well, along with the SD module from the Sharp ROM. However, I'm unable to use the wi-fi card. I've copied the p80211 module from the Sharp rom and have loaded it, but when I try to connect with the wi-fi card, my Z freezes and need to be rebooted. What could be wrong?

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

When I was messing around w/ the Fast Kernel, I noticed that I had to insmod a bunch of USB modules or my wireless would do just what you're describing.

make sure you have all the following modules either compiled in to the kernel itself, or insmodded

p80211.o
usbcore.o
usb_ochi_tc6393.o
prism2_usb.o


Regards,
-ross

[pldrouin]

I've compiled the kernel with iptables support and support for my Socket ethernet card and these two things work very well, along with the SD module from the Sharp ROM. However, I'm unable to use the wi-fi card. I've copied the p80211 module from the Sharp rom and have loaded it, but when I try to connect with the wi-fi card, my Z freezes and need to be rebooted. What could be wrong?

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

When I was messing around w/ the Fast Kernel, I noticed that I had to insmod a bunch of USB modules or my wireless would do just what you're describing.

make sure you have all the following modules either compiled in to the kernel itself, or insmodded

p80211.o
usbcore.o
usb_ochi_tc6393.o
prism2_usb.o


Regards,
-ross
[div align=\"right\"][a href=\"index.php?act=findpost&pid=64388\"][{POST_SNAPBACK}][/a][/div]

I didn't have prism2_usb. Thanks a lot!!! Can I compile this prism3_usb module or I have to use the Sharp one? For now I've simply copied it from the Sharp ROM and it works fine...

[selfabuse]

I didn't have prism2_usb. Thanks a lot!!! Can I compile this prism3_usb module or I have to use the Sharp one? For now I've simply copied it from the Sharp ROM and it works fine...
[div align=\"right\"][a href=\"index.php?act=findpost&pid=64391\"][{POST_SNAPBACK}][/a][/div]

I've never tried compiling it myself on the Z, but I am pretty sure that the sources are available. I'll see if I can track down the source for it and post a link when I do.

Regards,
-ross

[xjqian]

Updates:

* I just found the second CF in my sled is fully accessible even the battery in the sled is depleted or removed. Thanks for this feature. However, are there anyway I can view both batteries status from the battery-changeCCCRapplet. or put it another way, are there any alternative methods to change CCCR without installing the applet?
* the backlight (aka. rotation) button is a little buggy. in portrait mode, i can turn backligh off, but can never turn it back on afterwards. in landscape, i can turn baklight on, but can never turn it off. anybody else got this problem? besides, I have to hold a certain time (sweet spot) to get the rotation work properly. holding it too short or too long will just keep the screen refreshing, but no rotation.

[guylhem]

Hello

I have to tweak battery-changeCCCRapplet code. I am starting to play with qtopia so it should be possible.

Regarding the light/rotation problem, this is due to my keyboard experiments. It will be fixed in the next release.

[Bedman]

Hello all,

i have one question.
The 2.6 Kernel will come to the Zauri. But till now only for 5xxx and Cxxx models, but not for the 6000.
Wouldn't it be much better to get the 2.6 Kernel done on the 6000 and do the optimizations to that Kernel.
So here is the question to you geeks. Would you port the 2.6 Kernel to the 6000L.
Here is the status off the current porting: http://www.rpsys.net/openzaurus

Thx for taking this in consideration

Bedman

[adf]

an optimized tweaked 2.6 on the 6k is kind of a holy grail, I think. It is, (like most development) beyond my skill. I'd sure love to get my hands on one though
The thing is, it only really makes sense in a custom compiled qtopia rom or in openzaurus., since ( I think, am I right?) that it would not be compiled in gcc 2.95, but rather 3.4.