OESF Portables Forum
Model Specific Forums => Sharp Zaurus => Zaurus - pdaXrom => Topic started by: louigi600 on April 29, 2007, 05:22:26 am
-
PdaXrom kernel has remained pretty much the same since beta4 (2.6.16) and now over
at kernel.org version 2.6.21.1 stable is avalible ... and that means that we are about 1
year behind current kernel developement.
Also over at OZ the have fixed quite a few things from which we could also benefit.
Can anyone help me retreive the patch sequence for the OZ kernel ?
... this will help me merge pdaXrom specific patches with all the stuff that OZ already
have fixed.
-
http://projects.gentoo.ru/gentoo-pda/wiki/...%9A%D0%9F%D0%9A (http://projects.gentoo.ru/gentoo-pda/wiki/%D0%A1%D0%B1%D0%BE%D1%80%D0%BA%D0%B0%20%D1%8F%D0%B4%D0%B5%D1%80%20%D0%B4%D0%BB%D1%8F%20%D0%9A%D0%9F%D0%9A) for example. Or look for scripts at http://www.openembedded.org/filebrowser/or...packages/linux/ (http://www.openembedded.org/filebrowser/org.openembedded.dev/packages/linux/) ( linux-rp_2.6.20.bb + linux-rp.inc )
-
If you get this built and working, please post the steps involved for building and installing it. I'd like to to build it for my C3100 for the DM9601 driver.
Thanks, and best of luck!
-
If you get this built and working, please post the steps involved for building and installing it. I'd like to to build it for my C3100 for the DM9601 driver.
Thanks, and best of luck!
[div align=\"right\"][a href=\"index.php?act=findpost&pid=160071\"][{POST_SNAPBACK}][/a][/div]
I have been lookin at upgrading the kernel to the newest for the past few months and I haven't had enough time to focus on pdaXrom to get that implemented...
I'm going to try to find time to get back in to it... but it is time allowing..
Late
-
If you get this built and working, please post the steps involved for building and installing it. I'd like to to build it for my C3100 for the DM9601 driver.
Thanks, and best of luck!
It is easy to do with gentoo. Just use ebuild from gentoo-pda overlay
If you don't you must apply folowing patches (in this order):
#!/bin/bash
DOSRC = "http://www.do13.de/openzaurus/patches"
RPSRC = "http://www.rpsys.net/openzaurus/patches/archive"
JLSRC = "http://www.cs.wisc.edu/~lenz/zaurus/files"
BASRC = "http://www.orca.cx/zaurus/patches"
CHSRC = "http://oz.drigon.com/patches"
TKSRC = "http://www.informatik.hu-berlin.de/~tkunze/zaurus/patches"
SRC_URI = "http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.20.tar.bz2 \
http://www.kernel.org/pub/linux/kernel/v2.6/patch-2.6.20.6.bz2 \
http://opensource.wolfsonmicro.com/~lg/asoc/asoc-v0.13.3.patch \
${RPSRC}/oprofile_always_bt_arm-r0.patch \
${RPSRC}/lzo_kernel-r0.patch \
${RPSRC}/lzo_jffs2-r0.patch \
${RPSRC}/lzo_crypto-r0a.patch \
${RPSRC}/lzo_jffs2_lzomode-r0.patch \
${RPSRC}/lzo_jffs2_sysfs-r0.patch \
${RPSRC}/hx2750_base-r28.patch \
${RPSRC}/hx2750_bl-r8.patch \
${RPSRC}/hx2750_pcmcia-r2.patch \
${RPSRC}/pxa_keys-r7.patch \
${RPSRC}/tsc2101-r16.patch \
${RPSRC}/hx2750_test1-r6.patch \
${RPSRC}/pxa_timerfix-r0.patch \
${RPSRC}/input_power-r6.patch \
${RPSRC}/pxa25x_cpufreq-r2.patch \
${RPSRC}/sharpsl_pm_fixes1-r0.patch \
${RPSRC}/pm_changes-r1.patch \
${RPSRC}/usb_add_epalloc-r3.patch \
${RPSRC}/usb_pxa27x_udc-r3.patch \
${RPSRC}/kexec-arm-r4a.patch \
${RPSRC}/locomo_kbd_tweak-r1.patch \
${RPSRC}/poodle_pm-r3.patch \
${RPSRC}/pxa27x_overlay-r5.patch \
${RPSRC}/w100_extaccel-r0.patch \
${RPSRC}/w100_extmem-r0.patch \
file://hostap-monitor-mode.patch \
file://serial-add-support-for-non-standard-xtals-to-16c950-driver.patch \
${RPSRC}/logo_oh-r0.patch.bz2 \
${RPSRC}/logo_oz-r2.patch.bz2 \
${RPSRC}/pxa-linking-bug.patch \
${RPSRC}/mmcsd_large_cards-r0.patch \
${RPSRC}/mmcsd_no_scr_check-r0.patch \
${RPSRC}/integrator_rgb-r1.patch \
${RPSRC}/pxa_cf_initorder_hack-r1.patch \
file://pxa-serial-hack.patch \
file://connectplus-remove-ide-HACK.patch \
file://squashfs3.0-2.6.15.patch;status=external \
file://vesafb-tng-1.0-rc2-2.6.20-rc2.patch;status=external \
file://sharpsl-rc-r1.patch \
file://defconfig-c7x0 \
file://defconfig-hx2000 \
file://defconfig-collie \
file://defconfig-poodle \
file://defconfig-akita \
file://defconfig-spitz \
file://defconfig-qemuarm \
file://defconfig-qemux86 \
file://defconfig-tosa "
wget ${SRC_URI}
http://www.openembedded.org/repo/org.opene...defconfig-spitz (http://www.openembedded.org/repo/org.openembedded.dev/packages/linux/linux-rp-2.6.20/defconfig-spitz) - config for spitz/borzoi/terrier (you just need to enable jffs support and change cmdline to boot from mtdblock)
-
In fact the only thing you need to build OZ kernel 2.6.20 is http://www.openembedded.org/repo/org.opene...ux/linux-rp.inc (http://www.openembedded.org/repo/org.openembedded.dev/packages/linux/linux-rp.inc) and http://www.openembedded.org/repo/org.opene...ux-rp_2.6.20.bb (http://www.openembedded.org/repo/org.openembedded.dev/packages/linux/linux-rp_2.6.20.bb)
This is sh-scripts that will download most files (except of 2 or 3 you need to download manualy) and patch the kernel.
-
If you get this built and working, please post the steps involved for building and installing it. I'd like to to build it for my C3100 for the DM9601 driver.
Thanks, and best of luck!
[div align=\"right\"][a href=\"index.php?act=findpost&pid=160071\"][{POST_SNAPBACK}][/a][/div]
I have been lookin at upgrading the kernel to the newest for the past few months and I haven't had enough time to focus on pdaXrom to get that implemented...
I'm going to try to find time to get back in to it... but it is time allowing..
Late
[div align=\"right\"][a href=\"index.php?act=findpost&pid=160076\"][{POST_SNAPBACK}][/a][/div]
If there's anything I can do to help push this along, let me know.
-
http://projects.gentoo.ru/gentoo-pda/wiki/...%9A%D0%9F%D0%9A (http://projects.gentoo.ru/gentoo-pda/wiki/%D0%A1%D0%B1%D0%BE%D1%80%D0%BA%D0%B0%20%D1%8F%D0%B4%D0%B5%D1%80%20%D0%B4%D0%BB%D1%8F%20%D0%9A%D0%9F%D0%9A) for example. Or look for scripts at http://www.openembedded.org/filebrowser/or...packages/linux/ (http://www.openembedded.org/filebrowser/org.openembedded.dev/packages/linux/) ( linux-rp_2.6.20.bb + linux-rp.inc )
[div align=\"right\"][a href=\"index.php?act=findpost&pid=160056\"][{POST_SNAPBACK}][/a][/div]
Thanks Civil ... those are very good starting pointers.
Capn_Fish of caurse I'll share anything good that might come out of this.
InSearchOf yea but maybe you can help me anyway ... it will cost less time and if I get anywhere then I can tell you what I did.
Unfortunately today I'm working on mt external battery charger ... but I'll get pack to this tomorrow.
-
I have been lookin at upgrading the kernel to the newest for the past few months and I haven't had enough time to focus on pdaXrom to get that implemented...
I think the only problem is updating pdaXrom-specific patches (if they exists). Most of other work has been done by OZ (look at http://www.openembedded.org/filebrowser/or...packages/linux/ (http://www.openembedded.org/filebrowser/org.openembedded.dev/packages/linux/) - there you can find sh-scripts for building kernel - it won't take much time to make your own)
-
does it make sense to incorporate pdaxrom as a distro into the openembbed build environment?
I'm sure it's possible and would benefit both sides but not sure how much political issues, if any, it will arouse.
-
does it make sense to incorporate pdaxrom as a distro into the openembbed build environment?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=160096\"][{POST_SNAPBACK}][/a][/div]
Summary: We (OE + OZ) offered that long ago, but pdaX wasn't interested.
-
does it make sense to incorporate pdaxrom as a distro into the openembbed build environment?
I'm sure it's possible and would benefit both sides but not sure how much political issues, if any, it will arouse.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=160096\"][{POST_SNAPBACK}][/a][/div]
One thing I am pretty sure about is that at the end of the day using which distro or "rom" simply doesn't matter, let alone any ego war. What he wants is simply a usable and stable working environment, and no mere hacker's dream toy.
-
I don't really get the whole OE thing. What benefits would there be to switching to OE?
-
I don't really get the whole OE thing. What benefits would there be to switching to OE?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=160116\"][{POST_SNAPBACK}][/a][/div]
In the past, when most OZ users were using OPIE rather than GPE and everything was based around 2.4 kernels, there was a big difference between OZ and pdaXrom. Now, that everyone is moving to a 2.6 kernel and EABI, there isn't so much of a difference anymore. OE is the builder tool to build OZ/Angstrom similar to the pdaXrom builder. The advantages of the pdaXrom builder was that it could spit out a X86 as well as a ARM version of pdaXrom. The X86 version could be booted off a CDROM or used from inside VMWare or other virtual machines. In addition, pdaXrom builder also build a ready to use native zgcc image for the Zaurus. These and the fact that pdaXrom was still based around 2.4 kernel which was although slower than the 2.6 kernel, much more stable and supported all the Zaurus' (clamshell models) hardware, and glibc 2.2 which made it easy to port to Sharp/Cacko, ie pdaXqtrom.
Now, there isn't much of a differentiator anymore. Everything is aiming at using 2.6 kernel, the use of EABI means that the latest glibc and gcc will be used. The only difference will be the packaging and even in that, both distros are becoming more and more similar in that regard. One difference that remains is the ipk format, but that isn't a big issue.
CJK was one of the reason pdaXrom was more popular for some people, but it isn't really supported well in the latest of either distros. Application wise, OZ/Angstrom tends to only provide optimised applications that run quickly and use little resources, whereas pdaXrom enphazised on supporting almost any opensource linux application that users wanted to use on their Zaurus.
So to answer the question, the difference would be much smaller these days, but the effort to convert everything to using OE would be quite considered and what gain would that provide? It isn't like pdaXrom doesn't have a build tool yet or its current tool doesn't do the job properly, so there isn't really a point in moving to OE.
-
hmmmm. what in particular prevents one from grabbin pdax source and putting it all in OE, or putting all of Angstrom through the pdaX builder? Other tha the simple pain of rounding up the sources in a useable fashion, that is. It seems to me that if they are getting that close, and it has seemed that we are looking at pretty much the same kernel for 2.6, then it would simply be a matter of time and ambition yes? no?
-
hmmmm. what in particular prevents one from grabbin pdax source and putting it all in OE, or putting all of Angstrom through the pdaX builder? Other tha the simple pain of rounding up the sources in a useable fashion, that is. It seems to me that if they are getting that close, and it has seemed that we are looking at pretty much the same kernel for 2.6, then it would simply be a matter of time and ambition yes? no?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=160171\"][{POST_SNAPBACK}][/a][/div]
what is preventing businesses from replacing all their windows machines with linux and just telling their users, just use this from now on?
users/developers need to spend time learning how to use the new beast, some processes need to be changed in order to accomodate the new tools, some things that were possible with the old system are not possible anymore..., how is anyone going to get any work done while all this is happening? seriously, everyone is busy with implementing new features/fixing bugs/writing docs, why would anyone want to waste time doing something like this only to find out, the users dont want their system to be changed and/or the new system broke feature x,y,z..., so who got so much time to waste? you? even if you have the time and ambition to do so, how are you going to convince the users to stop working and forget about what they know and learn about a new system before continuing their work..., would you be happy if someone told you to stop driving your car and wait for a boat to be build and then ditch the car and use the boat to get around instead....
-
hmmmm. what in particular prevents one from grabbin pdax source and putting it all in OE, or putting all of Angstrom through the pdaX builder? Other tha the simple pain of rounding up the sources in a useable fashion, that is. It seems to me that if they are getting that close, and it has seemed that we are looking at pretty much the same kernel for 2.6, then it would simply be a matter of time and ambition yes? no?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=160171\"][{POST_SNAPBACK}][/a][/div]
Putting the pdaX patches in OE would be a considerably smaller effort than putting all of OE in the pdaX builder. Good luck with manually sorting out dependencies, manually writing the ipk control files and manually writing the ptxdist buildrules for the >2000 packages that are in OE.
-
I have been lookin at upgrading the kernel to the newest for the past few months and I haven't had enough time to focus on pdaXrom to get that implemented...
I think the only problem is updating pdaXrom-specific patches (if they exists). Most of other work has been done by OZ (look at http://www.openembedded.org/filebrowser/or...packages/linux/ (http://www.openembedded.org/filebrowser/org.openembedded.dev/packages/linux/) - there you can find sh-scripts for building kernel - it won't take much time to make your own)
[div align=\"right\"][a href=\"index.php?act=findpost&pid=160089\"][{POST_SNAPBACK}][/a][/div]
Yes there must be something specific to pdaxrom because as fas as I understand pdaxrom kernel does not ignore what u-boot passes to it and we have a pretty different nand flash partitioning.
I've attemted to use angstrom kernel with pdaxrom root filesystem on pdaxrom nand partitioning .... but I had more problems dew to the partition scheme the kernel was built with (and maybe more that I did not have the time to investigate).
-
Putting the pdaX patches in OE would be a considerably smaller effort than putting all of OE in the pdaX builder. Good luck with manually sorting out dependencies, manually writing the ipk control files and manually writing the ptxdist buildrules for the >2000 packages that are in OE.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=160173\"][{POST_SNAPBACK}][/a][/div]
Koen can I get hold of you for a few seconds ?
Can you PM me or contact me via skype or icq ?
-
Thanks for the info. One more question:
What's EABI?
-
Thanks for the info. One more question:
What's EABI?
[div align=\"right\"][{POST_SNAPBACK}][/a][/div] (http://index.php?act=findpost&pid=160187\")
Here is [a href=\"http://http://wiki.debian.org/ArmEabiPort#head-c19223b1bb614d3065443309d6b8fedc8944ce46]EABI[/url] explained in a nutshell.
-
I downloaded kernel sources 2.6.21.1 and these are the OZ patches I managed to apply.
The ones commented were ither:
rejected
not found
not intresting for me
or any combination of above
#oprofile_always_bt_arm-r0.patch
lzo_kernel-r0.patch
lzo_jffs2-r0.patch
lzo_crypto-r0a.patch
lzo_jffs2_lzomode-r0.patch
lzo_jffs2_sysfs-r0.patch
hx2750_base-r28.patch
hx2750_bl-r8.patch
pxa_keys-r7.patch
tsc2101-r16.patch
hx2750_test1-r6.patch
pxa_timerfix-r0.patch
input_power-r6.patch
pxa25x_cpufreq-r2.patch
sharpsl_pm_fixes1-r0.patch
pm_changes-r1.patch
usb_add_epalloc-r3.patch
usb_pxa27x_udc-r3.patch
#kexec-arm-r4a.patch
locomo_kbd_tweak-r1.patch
poodle_pm-r3.patch
pxa27x_overlay-r5.patch
w100_extaccel-r0.patch
w100_extmem-r0.patch
#hostap-monitor-mode.patch not in oz patch archive ... pdaxrom one got rejected
#serial-add-support-for-non-standard-xtals-to-16c950-driver.patch not in oz
#getting from pdaxrom patches
serial-add-support-for-non-standard-xtals-to-16c950-driver.patch
logo_oh-r0.patch.bz2
logo_oz-r2.patch.bz2
pxa-linking-bug.patch
mmcsd_large_cards-r0.patch
mmcsd_no_scr_check-r0.patch
integrator_rgb-r1.patch
pxa_cf_initorder_hack-r1.patch
#pxa-serial-hack.patch not in oz ... getting from pdaxrom
pxa-serial-hack.patch
#connectplus-remove-ide-HACK.patch not in oz ... getting from pdaxrom
connectplus-remove-ide-HACK.patch
#skipping squashfs3.0-2.6.15.patch I do not intend to use squashfs
#vesafb-tng-1.0-rc2-2.6.20-rc2.patch could not find
#sharpsl-rc-r1.patch
I'll try building what I now have and see how I get on.
-
#vesafb-tng-1.0-rc2-2.6.20-rc2.patch could not find
You just don't whant to look through links...http://www.openembedded.org/filebrowser/org.openembedded.dev/packages/linux/linux-rp-2.6.20
there are:
add-oz-release-string.patch
connectplus-remove-ide-HACK.patch
defconfig-akita
defconfig-c7x0
defconfig-spitz
hostap-monitor-mode.patch
orinoco-remove-all-which-are-in-hostap-HACK.patch
pxa-serial-hack.patch
serial-add-support-for-non-standard-xtals-to-16c950-driver.patch
sharpsl-rc-r1.patch
squashfs3.0-2.6.15.patch
vesafb-tng-1.0-rc2-2.6.20-rc2.patch
wm97xx-lcdnoise-r0.patch
Some of them you couldn't find...
Everything in OZ-sciprts exists and can be downloaded.
P.S. Maybe you'll need http://opensource.wolfsonmicro.com/~lg/aso...c-v0.13.4.patch (http://opensource.wolfsonmicro.com/~lg/asoc/asoc-v0.13.4.patch) (it is for sound support)
P.S.S. Maybe you also need to look http://rpsys.net/openzaurus/patches/ (http://rpsys.net/openzaurus/patches/) here for newer versions of some patches (for example kexec-r5 in http://rpsys.net/openzaurus/patches/archive/ (http://rpsys.net/openzaurus/patches/archive/) )
P.S.S.S. And squashfs patch won't apply even if you whant it to. You need to use newer version + a little bug-fix patch for ARM to get it compile...
-
Ok I decided to use the same kernel that OZ is currently using (2.6.20.6).
With a little extra downloading I managed to apply these patches
asoc-v0.13.3.patch.bz2
oprofile_always_bt_arm-r0.patch.bz2
lzo_kernel-r0.patch.bz2
lzo_jffs2-r0.patch.bz2
lzo_crypto-r0a.patch.bz2
lzo_jffs2_lzomode-r0.patch.bz2
lzo_jffs2_sysfs-r0.patch.bz2
hx2750_base-r28.patch.bz2
hx2750_bl-r8.patch.bz2
pxa_keys-r7.patch.bz2
tsc2101-r16.patch.bz2
hx2750_test1-r6.patch.bz2
pxa_timerfix-r0.patch.bz2
input_power-r6.patch.bz2
pxa25x_cpufreq-r2.patch.bz2
sharpsl_pm_fixes1-r0.patch.bz2
pm_changes-r1.patch.bz2
usb_add_epalloc-r3.patch.bz2
usb_pxa27x_udc-r3.patch.bz2
kexec-arm-r4a.patch.bz2
locomo_kbd_tweak-r1.patch.bz2
poodle_pm-r3.patch.bz2
pxa27x_overlay-r5.patch.bz2
w100_extaccel-r0.patch.bz2
w100_extmem-r0.patch.bz2
hostap-monitor-mode.patch.bz2
orinoco-remove-all-which-are-in-hostap-HACK.patch.bz2
serial-add-support-for-non-standard-xtals-to-16c950-driver.patch.bz2
logo_oh-r0.patch.bz2
logo_oz-r2.patch.bz2
pxa-linking-bug.patch.bz2
mmcsd_large_cards-r0.patch.bz2
mmcsd_no_scr_check-r0.patch.bz2
integrator_rgb-r1.patch.bz2
pxa_cf_initorder_hack-r1.patch.bz2
pxa-serial-hack.patch.bz2
connectplus-remove-ide-HACK.patch.bz2
#skipping squashfs3.0-2.6.15.patch I do not intend to use squashfs
vesafb-tng-1.0-rc2-2.6.20-rc2.patch.bz2
sharpsl-rc-r1.patch.bz2
without any errors but still I get this error when building:
arch/arm/common/built-in.o: In function `sharpsl_battery_thread':
scoop.c:(.text+0x11bc): undefined reference to `apm_queue_event'
arch/arm/common/built-in.o: In function `sharpsl_fatal_isr':
scoop.c:(.text+0x1588): undefined reference to `apm_queue_event'
arch/arm/common/built-in.o: In function `sharpsl_pm_probe':
scoop.c:(.init.text+0xe4): undefined reference to `apm_get_power_status'
make: *** [.tmp_vmlinux1] Error 1
This is in the kernel linking phase I guess close to having it all done.
Anyone have any idea ?
-
Ok I decided to use the same kernel that OZ is currently using (2.6.20.6).
With a little extra downloading I managed to apply these patches
asoc-v0.13.3.patch.bz2
oprofile_always_bt_arm-r0.patch.bz2
lzo_kernel-r0.patch.bz2
lzo_jffs2-r0.patch.bz2
lzo_crypto-r0a.patch.bz2
lzo_jffs2_lzomode-r0.patch.bz2
lzo_jffs2_sysfs-r0.patch.bz2
hx2750_base-r28.patch.bz2
hx2750_bl-r8.patch.bz2
pxa_keys-r7.patch.bz2
tsc2101-r16.patch.bz2
hx2750_test1-r6.patch.bz2
pxa_timerfix-r0.patch.bz2
input_power-r6.patch.bz2
pxa25x_cpufreq-r2.patch.bz2
sharpsl_pm_fixes1-r0.patch.bz2
pm_changes-r1.patch.bz2
usb_add_epalloc-r3.patch.bz2
usb_pxa27x_udc-r3.patch.bz2
kexec-arm-r4a.patch.bz2
locomo_kbd_tweak-r1.patch.bz2
poodle_pm-r3.patch.bz2
pxa27x_overlay-r5.patch.bz2
w100_extaccel-r0.patch.bz2
w100_extmem-r0.patch.bz2
hostap-monitor-mode.patch.bz2
orinoco-remove-all-which-are-in-hostap-HACK.patch.bz2
serial-add-support-for-non-standard-xtals-to-16c950-driver.patch.bz2
logo_oh-r0.patch.bz2
logo_oz-r2.patch.bz2
pxa-linking-bug.patch.bz2
mmcsd_large_cards-r0.patch.bz2
mmcsd_no_scr_check-r0.patch.bz2
integrator_rgb-r1.patch.bz2
pxa_cf_initorder_hack-r1.patch.bz2
pxa-serial-hack.patch.bz2
connectplus-remove-ide-HACK.patch.bz2
#skipping squashfs3.0-2.6.15.patch I do not intend to use squashfs
vesafb-tng-1.0-rc2-2.6.20-rc2.patch.bz2
sharpsl-rc-r1.patch.bz2
without any errors but still I get this error when building:
arch/arm/common/built-in.o: In function `sharpsl_battery_thread':
scoop.c:(.text+0x11bc): undefined reference to `apm_queue_event'
arch/arm/common/built-in.o: In function `sharpsl_fatal_isr':
scoop.c:(.text+0x1588): undefined reference to `apm_queue_event'
arch/arm/common/built-in.o: In function `sharpsl_pm_probe':
scoop.c:(.init.text+0xe4): undefined reference to `apm_get_power_status'
make: *** [.tmp_vmlinux1] Error 1
This is in the kernel linking phase I guess close to having it all done.
Anyone have any idea ?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=160220\"][{POST_SNAPBACK}][/a][/div]
prolly need to add -lapm
-
One thing I am pretty sure about is that at the end of the day using which distro or "rom" simply doesn't matter, let alone any ego war. What he wants is simply a usable and stable working environment, and no mere hacker's dream toy.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=160110\"][{POST_SNAPBACK}][/a][/div]
What benefits would there be to switching to OE?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=160116\"][{POST_SNAPBACK}][/a][/div]
It isn't like pdaXrom doesn't have a build tool yet or its current tool doesn't do the job properly, so there isn't really a point in moving to OE.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=160160\"][{POST_SNAPBACK}][/a][/div]
The benefit or point is that finally the Z community (mostly developers or developers wannabe) can see the light of of a unified builder, single kernel tree + patches, and etc. Yes (with my reservation), this may be less of a concern for the users.
Not many people here can keep up with every development like Meanie. Although I'd like to help both sides but keeping track of both oe and pdaXrom builder at the same time will drive me insane.
-
hmmmm. what in particular prevents one from grabbin pdax source and putting it all in OE, or putting all of Angstrom through the pdaX builder? Other tha the simple pain of rounding up the sources in a useable fashion, that is. It seems to me that if they are getting that close, and it has seemed that we are looking at pretty much the same kernel for 2.6, then it would simply be a matter of time and ambition yes? no?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=160171\"][{POST_SNAPBACK}][/a][/div]
good communication skill and open-minded developers.
-
The benefit or point is that finally the Z community (mostly developers or developers wannabe) can see the light of of a unified builder, single kernel tree + patches, and etc. Yes (with my reservation), this may be less of a concern for the users.
That's why i am exploring the possibility of adopting OpenBSD right now.
(Yes, i know, it's not Linux. But ... does it REALLY matter to me?)
Not many people here can keep up with every development like Meanie. Although I'd like to help both sides but keeping track of both oe and pdaXrom builder at the same time will drive me insane.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=160233\"][{POST_SNAPBACK}][/a][/div]
To be honest, Meanie is no common user; he's an exceptional power user and hacker.
And you can easily count how many Z owners like Meanie in the Z community.
IMHO, if development keeps going in a too developer-centric way without much open-mindedness, i can only see the diminishment of the legend of Z and the Z community because of the detachment from the user base.
-
Really I did not want to start a holy war like Torvalds/Tanenbaum on whether or not to use OE. Obviously anything that will make the build of future kernels, for the pdaxrom distribution, easier is absolutely wellcome (but is not the main objective of this thread).
Once said that I'll add that for the moment I'm not prepared to setup the OE build environment.
Currently I prefer to understand better what I'm doing and thus I prefer to build my stuff from a plain cross compile toolchain.
I know that what I'm doing is probably too manual to be of any direct use to pdaxrom (and probably most other people too) but non the less the experience that comes out of it will probably be usefull when it will come to updating pdaxrom distribution kernel.
Now back to the main discussion:
Last night I managed to get the default config (the one that is picked up if you remove .config or if you run "make mrproper) to build (with all the patches I listed above unchaijed). So I'll go trought the whole config file I copied from the pdaxrom 2.6.16 kernel trying to find out what feature breaks the kernel build when enabled.
Menie:
I don't understand what you mean by : "prolly need to add -lapm".
What exactly do I need to add ?
-
Really I did not want to start a holy war like Torvalds/Tanenbaum on whether or not to use OE. Obviously anything that will make the build of future kernels, for the pdaxrom distribution, easier is absolutely wellcome (but is not the main objective of this thread).
[div align=\"right\"][a href=\"index.php?act=findpost&pid=160239\"][{POST_SNAPBACK}][/a][/div]
Sorry for hijacking your thread. My intension was just to point out one possibility, since 2.6 kernel gives us an opportunity to unify things and avoid reinventing-the-wheel. For the record, I'm not an oe developer and I will shut up now.
-
Ok ... I manually checked every single entry in the menuconfig ... (copying the old .config from the 2.6.16 kernel does not work ... not sure why because I've used thid technique many times when upgrading kernel)
Anyway I also applied some pdaxrom specifig patches:
0218_linux-2.6.16-bootargs.patch.bz2 (for the u-boot boot parameters)
and part of
0200_linux-2.6.16-pxa27x-ovl.patch.bz2
I got as far as linking kernel again:
drivers/built-in.o: In function `tosaled_amber_set':
ledtrig-ide-disk.c:(.text+0x70d30): undefined reference to `tosascoop_jc_device'
drivers/built-in.o: In function `tosaled_green_set':
ledtrig-ide-disk.c:(.text+0x70d68): undefined reference to `tosascoop_jc_device'
make: *** [.tmp_vmlinux1] Error 1
Anyone have any ideas ?
-
I got as far as linking kernel again:
drivers/built-in.o: In function `tosaled_amber_set':
ledtrig-ide-disk.c:(.text+0x70d30): undefined reference to `tosascoop_jc_device'
drivers/built-in.o: In function `tosaled_green_set':
ledtrig-ide-disk.c:(.text+0x70d68): undefined reference to `tosascoop_jc_device'
make: *** [.tmp_vmlinux1] Error 1
[div align=\"right\"][{POST_SNAPBACK}][/a][/div] (http://index.php?act=findpost&pid=160250\")
Those are specific to tosa (6000l). Tosaled_amber/green_set are probably the functions to control the led light behavior. You can certainly comment those out if you don't care about tosa support or take a look at [a href=\"http://www.do13.de/openzaurus/]http://www.do13.de/openzaurus/[/url]. Maybe you are missing some tosa specific patches.
-
Those are specific to tosa (6000l). Tosaled_amber/green_set are probably the functions to control the led light behavior. You can certainly comment those out if you don't care about tosa support or take a look at http://www.do13.de/openzaurus/ (http://www.do13.de/openzaurus/). Maybe you are missing some tosa specific patches.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=160251\"][{POST_SNAPBACK}][/a][/div]
Yep I figured that out ... I accidentally enabled this feature:
"LED Support for the Sharp SL-6000 series"
I had it already removed when I rescanned the thread for updates ;-)
Now I have another error:
MODPOST vmlinux
OBJCOPY arch/arm/boot/Image
Kernel: arch/arm/boot/Image is ready
AS arch/arm/boot/compressed/head.o
GZIP arch/arm/boot/compressed/piggy.gz
AS arch/arm/boot/compressed/piggy.o
CC arch/arm/boot/compressed/misc.o
AS arch/arm/boot/compressed/head-xscale.o
AS arch/arm/boot/compressed/head-sharpsl.o
LD arch/arm/boot/compressed/vmlinux
OBJCOPY arch/arm/boot/zImage
Kernel: arch/arm/boot/zImage is ready
Building modules, stage 2.
MODPOST 249 modules
WARNING: drivers/usb/gadget/pxa2xx_udc.o - Section mismatch: reference to .init.text:pxa2xx_udc_probe from .data between '$d' (at offset 0x0) and 'memory'
WARNING: drivers/usb/gadget/pxa2xx_udc.o - Section mismatch: reference to .exit.text:pxa2xx_udc_remove from .data between '$d' (at offset 0x4) and 'memory'
WARNING: "wm8731_dai" [sound/soc/pxa/snd-soc-corgi.ko] undefined!
WARNING: "soc_codec_dev_wm8731" [sound/soc/pxa/snd-soc-corgi.ko] undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2
Any ieas ?
-
Ok I removed anothe option for the corgi soc .... now it's building.
I'm attaching my config and the patche sequence I used.
BTW: my config should also fix iptables in pdaxrom current ;-)
-
Ok I't boots but the kernel flash layout (whether detected or sculptured in code) is all wrong .... so do not try unless you want to corrupt data in the root .
I get the defaulr OZ layout with
root on /dev/mtd2
home on /dev/mtd3
In pdaxrom there should be on mtd3 at all and just the bog root: anyone know howto fix this ?
-
Ok it's also necessary to patch manually 0215_linux-2.6.16-nandparts.patch.bz2 as it gets rejected. (it's easy ... very simple patch).
Now it's working ;-)
Thanks to everyone who contributed.
In any case there is other problems that arise with the new kernel:
in X I get a shatow of everithing in the menu bar,
there is some problems with the touch screen activating multiple clicks when only 1 click is actually done (especially in the window operation buttons),
after exiting from X the text console is even more fucked up.
-
The work I've done so far seems to be working and my C760 is currently running with such a kernel but the /etc/rc.d/init.d/zaurushw thing broke.
it depends on these 2 pdaxrom specific patches:
0212_linux-2.6.16-pxafb-spitz.patch.bz2
linux-2.6.16-sharpsl-param.patch.bz2
Unfortunately the functions targeted by these patches have changed so much that my programming skills make it impossible for me to apply the patches manually.
Can anyone help me ?
-
I've managed to boot into kernel 2.6.21.1 (root on sd - rootfs is gentoo 2006.1 EABI ).
Just a few changes into existing patches... If anyone interested I can post updated versions of them.
-
I've managed to boot into kernel 2.6.21.1 (root on sd - rootfs is gentoo 2006.1 EABI ).
Just a few changes into existing patches... If anyone interested I can post updated versions of them.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=160485\"][{POST_SNAPBACK}][/a][/div]
Yes please do
-
Some patches for 2.6.21.1 kernel.
P.S. It's tar.bz2 archive in tar archive...
Most of patches are OZ's one. pxa27x_udc have only one modification - name of one header changed in 2.6.21 kernel. lzo_kernel - a little typo (misssing ";" ) and a patch for asoc - fixing kernel bug #8429 (a typo in kernel).
P.S. asoc 0.13.0 (a part for Zauruses) is no in mainline kernel. As kexec-patch is.
-
Ok got it building and booting to with a plain cross toolchain from pdaxrom ... but apparently there is an issue with suspend in this version (2.6.21.1).
I'm working with Civil to see if we can fix it (his 3100 is also afflicted).
-
Does this mean there'll be a working 2.6.21 kernel for pdaX, with a DM9601 driver (can you tell I really want my USB-to-Ethernet adapter working?)?
-
Does this mean there'll be a working 2.6.21 kernel for pdaX, with a DM9601 driver (can you tell I really want my USB-to-Ethernet adapter working?)?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=160554\"][{POST_SNAPBACK}][/a][/div]
Well ... fully working kernel for pdaxrom will require some developer work to get all the things working for the distro.
Me and Civil are working to get the basics working ... hoping that the developers will benefit from our experiments.
Keep in mind that there is also issues with touchscreen behaviour so even if we get the basics working it still needs work done by developers to become usable in the distro.
-
Does this mean there'll be a working 2.6.21 kernel for pdaX, with a DM9601 driver (can you tell I really want my USB-to-Ethernet adapter working?)?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=160554\"][{POST_SNAPBACK}][/a][/div]
Well ... fully working kernel for pdaxrom will require some developer work to get all the things working for the distro.
Me and Civil are working to get the basics working ... hoping that the developers will benefit from our experiments.
Keep in mind that there is also issues with touchscreen behaviour so even if we get the basics working it still needs work done by developers to become usable in the distro.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=160555\"][{POST_SNAPBACK}][/a][/div]
I appreciate your efforts. Hope this leads to a 2.6.21 kernel being put into pdaX.
-
Just a reminder ... this is where the 2.6.21 kernel (and 2.6.20.6) were left.
ASAP I'll see if 2.6.21.4 is any better ... but looking at the changelog I see no changes addressing the issues that were afflicting Z devices.
I'll try to find the time to see if there are any new patches ....
Also I must try to make my build script automatically download newest patches from ZO and apply them automatically to kernel sources .... the process is too manual to be repeated every time there is new patches avalible.
-
Ok this is the current state:
InSearchOf hase managed to apply all pdaXrom specific patches to 2.6.21,
Over at OZ they have a recepy for 2.6.21 so probbably they have fixed some of the issues afflicting our experiments,
with a few adjustments I managed to apply OZ patches for 2.6.21 to 2.6.21.5 and some pdaXrom specific patches (kernel builds but I've not tested yet on any device),
I've still not yet managed to get the zaurushw and nanlogical specific patches applied to 2.6.21.5.
It would be intresting to merge our efforts ;-)
-
Over at OZ they have a recepy for 2.6.21 so probbably they have fixed some of the issues afflicting our experiments,
I doubt this is true, we closed OZ project months ago. I think you mean to advertise Angstrom for us :-)
-
I doubt this is true, we closed OZ project months ago. I think you mean to advertise Angstrom for us :-)
[div align=\"right\"][{POST_SNAPBACK}][/a][/div] (http://index.php?act=findpost&pid=164285\")
Yea ... I probabbly meant OE ... anyway the recepy is
[a href=\"http://www.openembedded.org/filebrowser/org.openembedded.dev/packages/linux/linux-rp-2.6.21]http://www.openembedded.org/filebrowser/or...linux-rp-2.6.21[/url]
and the archive where I got the patches is
http://www.rpsys.net/openzaurus/patches/archive/ (http://www.rpsys.net/openzaurus/patches/archive/)
-
It would be intresting to merge our efforts ;-)[div align=\"right\"][a href=\"index.php?act=findpost&pid=164268\"][{POST_SNAPBACK}][/a][/div]
Our kernel team is open for properly made patches. Keep in mind that any Zaurus support patches which goes to mainline goes through our kernel guys.
-
Our kernel team is open for properly made patches. Keep in mind that any Zaurus support patches which goes to mainline goes through our kernel guys.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=164287\"][{POST_SNAPBACK}][/a][/div]
Although that's not what I meant right now (I was talking about merging InSearcOf's work with mine), the idea is good but tending a little off topic.
I mean I do not want to start another holy war about pdaXrom's and OE's way of life.
Right now pdaxrom's current kernel is desparately old and has some severe consequences so the very first thing would be to get it alligned with what's avalible now (in terms of what's gotten fixed for Z). Once we reach this situation we can talk about this again.
-
louigi600: does it really have to look like "we, pdaX team, will get recent work done by OE Zaurus kernel hackers, add own hacks/patches and ignore the fact that we can cooperate" again?
Think about cooperation from beginning - otherwise you will get back one day just to see that we already done some of your fixes and that your new code need to be cleaned up, split into separate patches and updated to our code.
-
Think about cooperation from beginning - otherwise you will get back one day just to see that we already done some of your fixes and that your new code need to be cleaned up, split into separate patches and updated to our code.
Oh yeah, I forgot you guys were gods and did everything right.
Everyone should just RELAX -- if the pdaXrom devs want to do their own thing, let them -- it is after all their distribution to develop. Although merging pdaXrom and Angstrom would help in some respects, it would also prevent innovation from competing teams -- which is a good thing in my opinion. Also, the two distributions are completely different -- if they merge both sides (or at least one side, and I can tell who that would be) would lose out on some existing functionality (like being able to use a real web browser...but I won't go there).
Why is it that Angstrom/OZ people ALWAYS seem to want to conquer the Z market? The way I see it, the more options the better. It would be nice to allow sharing of code liberally throughout in both directions to avoid reinventing the wheel, but past that, it's not worth discussing unless both sides are clearly interested.
I'm really not trying to bait -- I just think those with sticks up their arses need to lighten up.
-
Think about cooperation from beginning - otherwise you will get back one day just to see that we already done some of your fixes and that your new code need to be cleaned up, split into separate patches and updated to our code.
Oh yeah, I forgot you guys were gods and did everything right.
Everyone should just RELAX -- if the pdaXrom devs want to do their own thing, let them -- it is after all their distribution to develop. Although merging pdaXrom and Angstrom would help in some respects, it would also prevent innovation from competing teams -- which is a good thing in my opinion. Also, the two distributions are completely different -- if they merge both sides (or at least one side, and I can tell who that would be) would lose out on some existing functionality (like being able to use a real web browser...but I won't go there).
Why is it that Angstrom/OZ people ALWAYS seem to want to conquer the Z market? The way I see it, the more options the better. It would be nice to allow sharing of code liberally throughout in both directions to avoid reinventing the wheel, but past that, it's not worth discussing unless both sides are clearly interested.
I'm really not trying to bait -- I just think those with sticks up their arses need to lighten up.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=164327\"][{POST_SNAPBACK}][/a][/div]
I agree
Late
-
Oh yeah, I forgot you guys were gods and did everything right.
Atleast we got 2.6 kernel working on all Zaurus models ;D
Everyone should just RELAX -- if the pdaXrom devs want to do their own thing, let them -- it is after all their distribution to develop. Although merging pdaXrom and Angstrom would help in some respects, it would also prevent innovation from competing teams -- which is a good thing in my opinion. Also, the two distributions are completely different -- if they merge both sides (or at least one side, and I can tell who that would be) would lose out on some existing functionality (like being able to use a real web browser...but I won't go there).[div align=\"right\"][a href=\"index.php?act=findpost&pid=164327\"][{POST_SNAPBACK}][/a][/div]
I am not talking about distributions merge but kernel work merge. For me pdaX distribution can live like it is now and I think that it will evolve and works. Do some stuff from it go to OE based distros (and vice versa) does not matter too much for me. But I do prefer to have more cooperation work when it comes to kernel stuff. For example during 2.6.22 development PXA suspend/resume got broken - finding why took many hours but finally Richard came with fix. I would like to avoid situations when pdaX kernel team will invent same stuff as OE Zaurus kernel team (and vice versa) in same time.
Why is it that Angstrom/OZ people ALWAYS seem to want to conquer the Z market? The way I see it, the more options the better. It would be nice to allow sharing of code liberally throughout in both directions to avoid reinventing the wheel, but past that, it's not worth discussing unless both sides are clearly interested.[div align=\"right\"][a href=\"index.php?act=findpost&pid=164327\"][{POST_SNAPBACK}][/a][/div]
For apps/distro work I do not need pdaX/Angstrom/OZ/etc merging. But for kernel I want to have cooperation as we spent too much time to get it working.
-
Well Hrw, does your SDL support a framebuffer console mode (fbcon) that rotates the screen from the native portrait mode back to landscape? I noticed that 2.6 kernels don't seem to support SDL as well as the previous 2.4 kernels. pdaXrom's R198 SDL is very slow in X11 mode, but FBCON is very fast, although still suffers from the rotation issues as it's drawing straight to the portait oriented framebuffer. I'm moving back to the 2.4 kernels due to this.
-
I agree with HRW. Ideally, make uboot an optional component, ie default kernel without uboot requirement/compatible with other distros, and then have special edition for advanced users with uboot support.
makes flashing and reflashing easier as well...
-
Hrw and T3_slider .... you're directing these sort of comment to the wrong person.
Personally I'm no experienced progremmer and I find the friction between the different Z distros really stupid.
I obviously did not explain myself right:
I love the idea but I'm only a tester in the team so I cannot decide wether the whole team wants to collaborate (but I see som positive feedback from some other team members).
I just wantetd to avoid talking about other stuff here ... this thread is a help request not a debate on if and how pdaXrom and OE should collaborate.
I must also say, and explain why, I strogly dissagre with a rather diffused opinion that says "there should be only one really good distro for Z".
For me that is very very wrong. The thins we need mosts are:
much much better collaboration,
much better flexibility * and
spend a little more time helping those who wish to become more experienced.
*: there is a big problem behind this. I frequently wish to customize my Z but nearly equally frequently it's not possible because of a non open source dependeny. If it's not because it's not open then it's not been developed enough to make it flexible and if it's not being developed enough then there is not enough documentation on it.
Meanie ... getting rid of sharp loader is a good example. I dissagree with you as it's probabbly one of the biggest obstacles in flexibility because it has many other dependencies in the partition where it lies.
People are looking for multi boot because they cannot customize any distro to do all they want to do. If the dostros were made more flexible people would stop looking for multi boot and choose whicever distro they like best and customize it to their needs ... and they will be very happy users.
OK ... once this is said ... I'm willing to collaborate with anyone ... whether it be from OE or even from another planet. Contact me via PM and we can arange for more efficient ways of comunicating and exchanging knowlege/work.
Back to work .... I want to get 2.6.21.5 working on pdaXrom without braking anything while keeping all tthat has been fixed since 2.6.16 ;-)
-
Well Hrw, does your SDL support a framebuffer console mode (fbcon) that rotates the screen from the native portrait mode back to landscape? I noticed that 2.6 kernels don't seem to support SDL as well as the previous 2.4 kernels. pdaXrom's R198 SDL is very slow in X11 mode, but FBCON is very fast, although still suffers from the rotation issues as it's drawing straight to the portait oriented framebuffer. I'm moving back to the 2.4 kernels due to this.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=164336\"][{POST_SNAPBACK}][/a][/div]
On C7x0 C860 zaurus the framebuffer is rotated in hardware by fbcon, making it as fast in portrait as in landscape. We also have a supreme gfx hacker has worked out 90% of accelleration of the w100 chip so this machine really shift gfx very fast (even Xv video works in X).
On C1000/3x00 machine its plain pxafb, and I was under the impression that is always in portrait and the console just renders the text with a 90 degrees rotation in landscape mode. If this is wrong and pxafb can be rotated properly then feel free to dig up the code. It would make X go a whole lot faster as well as fb based stuff.
-
This thread is not about debating what's better or not.
Please please stop it.
Let's keep the atmosphere in a woking collaboration ... not a debate.
-
Let's keep the atmosphere in a woking collaboration ... not a debate.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=164353\"][{POST_SNAPBACK}][/a][/div]
I think we are :-D zottd asked specific questions about fbcon which I answered.
-
Anyone know if since 2.6.16 any Zaurus stuff in drivers/misc/ moved to anywhere else ?
I'm just wondering if this patch is being applied in the right path ?
--- linux/drivers/misc/Kconfig~ 2006-05-19 15:19:51.000000000 +0000
+++ linux/drivers/misc/Kconfig 2006-05-19 15:58:08.000000000 +0000
@@ -28,5 +28,8 @@
If unsure, say N.
-endmenu
+config SHARPSL_PARAM
+ bool "Device driver for SHARP SL parameters tuning"
+ depends on PXA_SHARPSL
+endmenu
Even if I adjust the patch so that i applies kernel will not build:
CC drivers/misc/sharpsl-param/sharpsl_param.o
drivers/misc/sharpsl-param/sharpsl_param.c:21:21: asm/apm.h: No such file or directory
make[3]: *** [drivers/misc/sharpsl-param/sharpsl_param.o] Error 1
make[2]: *** [drivers/misc/sharpsl-param] Error 2
make[1]: *** [drivers/misc] Error 2
make: *** [drivers] Error 2
BTW: I've 2.6.21.5 kernel building booting on my C760 without this patch.
-
asm/apm.h -> linux/apm_emulation.h
-
asm/apm.h -> linux/apm_emulation.h
[div align=\"right\"][a href=\"index.php?act=findpost&pid=164444\"][{POST_SNAPBACK}][/a][/div]
I Could not find linux/apm_emulation.h:
CC drivers/misc/sharpsl-param/sharpsl_param.o
drivers/misc/sharpsl-param/sharpsl_param.c:21:33: linux/apm_emulation.h: No such file or directory
make[3]: *** [drivers/misc/sharpsl-param/sharpsl_param.o] Error 1
make[2]: *** [drivers/misc/sharpsl-param] Error 2
make[1]: *** [drivers/misc] Error 2
make: *** [drivers] Error 2
I guess it should be linux/apm-emulation.h .... with this ti builds.
Thanks Hrw.
-
Ok it builds and zaurushw seems to be working (at least on my C760).
Nandlogical is working again (althought I did nothing to try to fix it ... maybe the older kenrels had it broke or maybe the OE patches fixed it [althought this last one is unlikely because they do not use nandlogical from 2.6 kernel env]).
Amongst the the issues I noticed with 2.6.20.6 and 2.6.21.1 only one remains: the odd behaviour in X.
Initailly everything seems fine untill you press the close window button (not sire if the same happens with any window button) or even any desktop icon:
first press seems as if you missed it (feels like the thing has been selected),
seconf press actually does the job (closes the window or opens the icon),
from then on this is the behaviour of all buttos and icons (even the gcalk on-screen buttons).
I'm not sure where the problem is but this did not happen with 2.6.16 kernel.
is there a specific patch to fix that or is there some X settings that must be tweeged ?
P.S. I've still to fix all the issues with 2.6.21.5 and 2.6.21.6 is out !!!!
Thank God that in the changelog there is only NETFILTER stuff ;-)
-
I'm now tring to combine old OZ's patches and handhelds kernel (to make unified ebuild for gentoo for both pda's I have). I thik I'll try to build it soon and post results here.
louigi600
Where can I get your modified patches?
-
My work on kernel can be gotten from here (http://svn.drun.net/svn/slackurus/trunk/sources/a/kernel/)
username=anonymous and blank password.
If you want to use the buildscript you will also need master config file (http://svn.drun.net/svn/slackurus/trunk/sources/config) and common functions (http://svn.drun.net/svn/slackurus/trunk/sources/functions).
I'm still lost about the odd behavour in X ... anyone have any ideas ?
-
My work on kernel can be gotten from here (http://svn.drun.net/svn/slackurus/trunk/sources/a/kernel/)
username=anonymous and blank password.
If you want to use the buildscript you will also need master config file (http://svn.drun.net/svn/slackurus/trunk/sources/config) and common functions (http://svn.drun.net/svn/slackurus/trunk/sources/functions).
I'm still lost about the odd behavour in X ... anyone have any ideas ?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=164508\"][{POST_SNAPBACK}][/a][/div]
I recognize the behaviour you describe from RC12. When pressing the close or maximize button they keep pressed. I don't know, I had the idea that recalbration worked somewhat.
-
I did recalibrate pointer ... but it got no better.
Anyone have any other ideas ?
-
I did recalibrate pointer ... but it got no better.
Anyone have any other ideas ?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=164519\"][{POST_SNAPBACK}][/a][/div]
The X issue sounds like behavior lisfted when I was looking at ZBochs. I don't know if the website is still up, but the guy saaid that one tap put the mouse button down, and onther lifted it up. Is the kernel doing that on you, possibly?
-
The X issue sounds like behavior lisfted when I was looking at ZBochs. I don't know if the website is still up, but the guy saaid that one tap put the mouse button down, and onther lifted it up. Is the kernel doing that on you, possibly?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=164524\"][{POST_SNAPBACK}][/a][/div]
Intresting ... is is possible ... the feeling i had was one tap selected object and the next activated .... but that was just a feeling ... I've no evidence though.
Ither way basically that is what is happening.
The only thing I've changed is setup is actually the kernel (and kernel modules) so I guess the kernel is somehow involved in the trick ;-)
Sash suggested that plying with tslib settings might help ... but I've no idea how to do that.
-
The X issue sounds like behavior lisfted when I was looking at ZBochs. I don't know if the website is still up, but the guy saaid that one tap put the mouse button down, and onther lifted it up. Is the kernel doing that on you, possibly?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=164524\"][{POST_SNAPBACK}][/a][/div]
Intresting ... is is possible ... the feeling i had was one tap selected object and the next activated .... but that was just a feeling ... I've no evidence though.
Ither way basically that is what is happening.
The only thing I've changed is setup is actually the kernel (and kernel modules) so I guess the kernel is somehow involved in the trick ;-)
Sash suggested that plying with tslib settings might help ... but I've no idea how to do that.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=164526\"][{POST_SNAPBACK}][/a][/div]
I may also be an issue with on of the OE patches your using... they may have something conflicting with our configuration... just a thought :-/
Late
-
I may also be an issue with on of the OE patches your using... they may have something conflicting with our configuration... just a thought :-/
Late
[div align=\"right\"][a href=\"index.php?act=findpost&pid=164528\"][{POST_SNAPBACK}][/a][/div]
I'm using a mixture of OE and pdaXrom patches ... but it's very possible.
The odd thing is that during the calibration everything is fine ... and, once X is up, first click is ok ... all the other ar wrong !!
Anyway I found /etc/ts.conf: anyone have any suggestions on what to change to resolve the problem ?
InSearchOf ... I'd like to try the patches you used on 2.6.21 ... where can I get the patches you fixed up for 2.6.21 ?
-
What's in your ts.conf? That may give a clue.
Here's mine (r198, C3100, not changed AFAIK)
module_raw input
module pthres pmin=1
#module variance delta=30
module dejitter delta=100
module linear
-
What's in your ts.conf? That may give a clue.
Here's mine (r198, C3100, not changed AFAIK)
module_raw input
module pthres pmin=1
#module variance delta=30
module dejitter delta=100
module linear[div align=\"right\"][a href=\"index.php?act=findpost&pid=164535\"][{POST_SNAPBACK}][/a][/div]
Mine was the same ... I uncommented out the
module variance delta=30
line ... but it got no better (I was expecting that because "variance delta" does not sound as if it has anything to do with number of clicks)
-
2.6.22 is out !
The changelod is quite big, and has ARM fixes, but I think that is cumulative since 2.6.21 ?
Well whatever ... I've 8 patches out of the 38 I'm using that no longer apply:
lzo_jffs2_lzomode-r0.patch
lzo_jffs2_sysfs-r0.patch
input_power-r7.patch
w100_extaccel-r0.patc
mmcsd_large_cards-r0.patch
mmcsd_no_scr_check-r0.patch
sharpsl-rc-r1.patch
have any of these gotten into the kernel or is it just that source changed slightly ?
-
It's unlikely that they got in; it's almost certainly changes that conflict with the patches.
As for the touchscreen stuff, X has to interpret the data it gets from the ts device, and the case of the working 2.4 can be one of two things:
1) Kernel ts device outputs sensible data (whatever that means), X reads it sensibly
2) Kernel ts device outputs weird data, X expects the weirdness and reconstructs the correct data.
If the 2.6 ts device has gone from weird to sensible, or sensible to weird, or weird to a different kind of weird, then X is getting something unexpected and isn't interpreting it correctly.
Obviously, you want both sides behaving sensibly, so if the 2.6 ts device is now sensible, the patch should be made to the X code and vice versa.
There was an earlier thread regarding the X ts code in beta3 where there was a somewhat similar problem (and patches for X's tslib.c); that might be a starting point:
https://www.oesf.org/forums/index.php?showtopic=16557&st=0 (https://www.oesf.org/forums/index.php?showtopic=16557&st=0)
-
Thanks pelrun .... I'll see if I've time for that too although I was hoping not to go into X stuff myself ;-)
Where has this code moved to in 2.6.22:
drivers/input/power.c ?
Apparently it's drivers/input/power.c has been removed altogether.
-
2.6.22 is in Poky
-
Ok ... lets leave 2.6.22 for a moment.
With the use of 2.6.21.5 (and for that matter this also happened on 2.6.20.6) I've lost the ability to boot from SD/MMC.
Looking at the kernel messages while booting I notice this difference:
2.6.16 initializes SD/MM right after setting the RTC to unixtime + a few seconds ... detects partitions and mounts root.
With 2.6.21.5 i see the kernel panic right after the RTC stuff ... so i looks like it's attempting to access SD/MMC before having initialized it.
As anyone any ideas ?
This is a chunk of dmesg while booting from SD/MMC with 2.6.16
sa1100-rtc sa1100-rtc: setting the system clock to 1970-01-01 00:00:09 (9)
mmcblk0: mmc0:a3f6 SD256 249088KiB
mmcblk0: p1
kjournald starting. Commit interval 5 seconds
EXT3 FS on mmcblk0p1, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem).
And this is a chunk of dmesg while booting from nand with 2.6.21.5 (notice when mmc is initialized):
sa1100-rtc sa1100-rtc: setting the system clock to 1970-01-01 00:00:09 (9)
VFS: Mounted root (jffs2 filesystem).
Freeing init memory: 76K
mmcblk0: mmc0:a3f6 SD256 249088KiB
mmcblk0: p1
Here's the panic while attempting to boot from SD:
sa1100-rtc sa1100-rtc: setting the system clock to 1970-01-01 00:00:09 (9)
VFS: Cannot open root device "mmcblk0p1" or unknown-block(0,0)
Please append a correct "root=" boot option
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
I've attached the full dmesg for all the 3 cases above.
-
I've tried to apply CFS patches (Compleatly Fair Scheduler - new CPU shceduler, that will be included in kernel 2.6.23)... It acts very-very strange... Some times it says "Oops" on startup, but if it doesn't a boot to login prompt took a lot of time - for me it was around 12h(!) to boot...
-
I've tried to apply CFS patches (Compleatly Fair Scheduler - new CPU shceduler, that will be included in kernel 2.6.23)... It acts very-very strange... Some times it says "Oops" on startup, but if it doesn't a boot to login prompt took a lot of time - for me it was around 12h(!) to boot...
[div align=\"right\"][a href=\"index.php?act=findpost&pid=164772\"][{POST_SNAPBACK}][/a][/div]
12hr boot is better then No boot
Late
-
I've got 2.6.22 patched and booting with my husky but:
none of the issues I had before were resolved,
sd/mmc has severe problems across suspend/resume,
leaving the device suspended for some time will drain the battery (I need the external power to boot),
reflashing the original kernel after the 2.6.22 was used has given me a corrupt root filesystem (I guess some incomatibilities between nandlogical and 2.6.22).
-
My work on kernel can be gotten from here (http://svn.drun.net/svn/slackurus/trunk/sources/a/kernel/)
username=anonymous and blank password.
If you want to use the buildscript you will also need master config file (http://svn.drun.net/svn/slackurus/trunk/sources/config) and common functions (http://svn.drun.net/svn/slackurus/trunk/sources/functions).
I'm still lost about the odd behavour in X ... anyone have any ideas ?
[div align=\"right\"][{POST_SNAPBACK}][/a][/div] (http://index.php?act=findpost&pid=164508\")
The 2.6.21.5 kernel I was talking about above can be built with [a href=\"http://www.codesourcery.com/gnu_toolchains/arm/download.html]Code Sourcery[/url] xross toolchain.
I've not had the time yet to test if it actuallu boots and works normally but I was able to build it.
In order to use the EABI toolchain use this script:
#!/bin/bash
. /etc/profile
CROSS=arm-none-eabi-
CROSS_COMPILE=$CROSS
ARCH=arm
PATH=/arm-2007q1/bin:$PATH
export ARCH CROSS CROSS_COMPILE CFLAGS PATH
echo "Type exit for leave eabi cross environment."
/bin/bash
-
why note use kernel build in OE in pdaXrom distro ?
-
just a notice:
im boot pdaXii13 with angstrom last kernel i have some problems like modules not instaled and detection system of pdaxii13
maybe with some fixex can be possible.
-
just a notice:
im boot pdaXii13 with angstrom last kernel i have some problems like modules not instaled and detection system of pdaxii13
maybe with some fixex can be possible.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=165116\"][{POST_SNAPBACK}][/a][/div]
Angstrom kernel is 2.6 while pdaxii13 is 2.4 ... I think a lot of things will brake.
If you insist you can copy the modules form angstrom's /lib/modules/2.6.* to your /lib/modules/
-
i know louigi600, i think the better usage for this kernel is with pdaXrom 198+, i make this test just to check the possibility, i do not use it in pdaxii13.
but, why you try make a kernel with this already exist ? is a posibillity to you use angstrom kernel and why not, develop in ?
-
i know louigi600, i think the better usage for this kernel is with pdaXrom 198+, i make this test just to check the possibility, i do not use it in pdaxii13.
;-)
but, why you try make a kernel with this already exist ?
Angstrom kernel is built with OE (and maybe some Angtrom specific patches).
A kernel thus built will brake some things in pdaXrom (like u-boot parameters and zaurushw).
I'm not targetting primarely Angstrom but pdaXrom so my goal would be to benefit from all that has been fixed since 2.6.16 + all the pdaXrom specific stuff.
I was trying EABI toolchain for personal intrest so I attempted to build an EABI capable kernel.
is a posibillity to you use angstrom kernel and why not, develop in ?
I'm not developing anything but just collecting fixtes from here and ther, adjusting them so that they apply to the kernel I'm trying to use and testing if the result is any better that the kernel that comes with r197/198.
Also whether pdaXrom kernel developement should or should not be merged with OE kernel developement is not a matter of discussion here but I'm very happy and gratefull that help has come from people involved on many distributions.
A lot more things could be said about this but in short I hope that this will contribute positively to:
newer kernel for pdaXrom (with more things functional and less problems),
a cooperative attitude between all the various distribution developers (at least for kernel developement) and
have yet another option for people wishing to dual boot different distributions.
-
well,
i make some testes with pdaxrom 198 and angstrom kernel, some points
1 - kernel work with minor bugs
2 - USB network work like a charm =]
2 - i extract the jffs2 form 198 and put in hda1 so i boot form hd no flash used =/
3 - my unique problem is compiler diferences: examples
alsa utilities cannot comunicate via ioctl
ERROR: alsamixer: function snd_mixer_load failed: Inappropriate ioctl for device
maybe if pdaxrom gcc 4.x and glibc 2.3.x, can be possible do it, but need recompile many things
maybe use OE kernel as a central kernel to emebebed devices is the best choice i think...
Also whether pdaXrom kernel developement should or should not be merged with OE kernel developement is not a matter of discussion here but I'm very happy and gratefull that help has come from people involved on many distributions.
my idea is always have a updated kernel, like a 2.6.23 with CFS and other, and if a "central kernel" (not especific the OE kernel) can be used, we can focus on distro develop like important softwares..
btw,
what stage are you kernel ? actually
-
2.6.21.5 builds and works with some issues (it even builds EABI but I've not yet tested).
2.6.22 builds but my setup is currently too unsafe for any real use.
2.6.23 does not exist yet (2.6.22.1 is current stable at kernel.org).
-
my idea is always have a updated kernel, like a 2.6.23 with CFS and other, and if a "central kernel" (not especific the OE kernel) can be used, we can focus on distro develop like important softwares..
CFS is currently (as patches for 2.6.22) totaly unusable. Maybe it was changed in 2.6.22-git, but I don't know.
2.6.23 does not exist yet (2.6.22.1 is current stable at kernel.org).
2.6.22-git will become 2.6.23 one day... Currently they just haven't changed version yet.
-
louigi600,
how you test kernels ?
-
louigi600,
how you test kernels ?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=165183\"][{POST_SNAPBACK}][/a][/div]
Currently I use my c760 for testing (so I flash the kernel and reboot basically).
As soon as I've some time I'll look into qemu which I gather should be able to emulate akita.
Incidently the EABI kernel I built boots but I was unable to run my silly "hello world!" EABI test binary ... so something is not quite right (but this might be because the eabi binary wants eabi libraries I guess even the most simple binary will look for ld-linux).
Today, if I've the time, I'll try using Angstrom root filesystem chrooted (I still cannot boot from mmc/sd with 2.6.21.5) to see if the kernel I built works (but I my run into other gcc version build problems .... I'm using gcc4.2 eabi toolchain and have no idea what the Angstom toolchain uses).
-
Ok I got partial functionality with Angstrom chrooted (I could not start up GUI correctly but I got the X server starting).
So I'd call it at least a partial success ;-)
BTW my C760 has broken audio so I've no idea how my kernel is doing with sound !
Another thing that I may not have put in evidence: my kernel setuo is probabbly only good for Cxx0 devices since I've not yet used any Cxx00 specific patches.
-
tomorrow I'm gonna try it on my 860 to test audio behaviour. We'll speak about it in the morning
-
tomorrow I'm gonna try it on my 860 to test audio behaviour. We'll speak about it in the morning
[div align=\"right\"][a href=\"index.php?act=findpost&pid=165259\"][{POST_SNAPBACK}][/a][/div]
Scoutme .... what's up ?
I curious to know what happened on your 860 .... and maybe I'm not the only one ;-)
-
I'm running kernel 2.6.22 now. It seems to be rather stable. Just need to enable CONFIG_MMC_UNSAFE_RESUME (only becouse of root on sd)
-
Poky guys have 2.6.22 and Jpmatrix has tested it on some Z.
There is a blog about it ofer at tyrannozaurus (http://www.tyrannozaurus.com/?q=node/1013).
I was looking at the way the use OE to build to figure out where they have patches and recepies ... apparently they do not keep it on the official OE site.
Well I haven't had the time to look carfully into it but they have svn here (http://svn.o-hand.com/view/poky/).
I guess that Hrw was telling us just this when he stated that 2.6.22 is poky.
I'm running kernel 2.6.22 now. It seems to be rather stable. Just need to enable CONFIG_MMC_UNSAFE_RESUME (only becouse of root on sd)
What are you using to build 2.6.22 and what patches are you applying ?
When I used OE patches with some adjustments I also managed to get corruption of the root jffs2 filesystem along with other power problems (that's why I temporarely stopped experimenting with 2.6.22). I haven't made any more attempts since then.
-
I haven't tried jffs2 yet. No power problems here.
List of patches:
base patchset (most of patches are OZ's - using numbers before to make it patch in proper order):
01-lzo_kernel-r3.patch
02-lzo_jffs2-r2.patch
03-lzo_crypto-r2.patch
03-lzo_jffs2_lzomode-r1.patch
04-lzo_jffs2_sysfs-r1.patch
05-hx2750_base-r28.patch
06-hx2750_bl-r9.patch
07-hx2750_pcmcia-r2.patch
08-pxa_keys-r7.patch
09-tsc2101-r16.patch
10-hx2750_test1-r6.patch
11-pxa_timerfix-r0.patch
12-input_power-r9.patch
13-pxa25x_cpufreq-r2.patch
14-sharpsl_pm_fixes1-r0.patch
15-pm_changes-r1.patch
16-usb_add_epalloc-r3.patch
17-usb_pxa27x_udc-r5.patch
18-locomo_kbd_tweak-r1.patch
19-poodle_pm-r3.patch
20-pxa27x_overlay-r5.patch
21-w100_extaccel-r1.patch
23-qemuarm_scsi_fix-r0.patch
24-logo_oh-r0.patch.bz2
25-logo_oz-r2.patch.bz2
26-pxa-linking-bug.patch
27-mmcsd_large_cards-r1.patch
28-mmcsd_no_scr_check-r1.patch
29-integrator_rgb-r1.patch
30-pxa_cf_initorder_hack-r1.patch
31-nandparts.patch
33-sharpsl-param.patch
Extra patchset:
1900-ext4-updates-2.6.22.patch
1910-reiser4-2.6.22.patch
1920-udf-2.50-2.6.22.patch
1930-unionfs-2.6.22.patch
60-powertop-2.6.22.patch
-
This is a developement topic and hence any future comments should go into the new pdaxrom developement (https://www.oesf.org/forums/index.php?showforum=154) forum.