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.
Full Version: Help New Kernel For Pdaxrom
OESF Forums > Distros, Development, and Model Specific Forums > Distro Support and Discussion > pdaXrom
http://projects.gentoo.ru/gentoo-pda/wiki/...%9A%D0%9F%D0%9A for example. Or look for scripts at http://www.openembedded.org/filebrowser/or...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!
Thanks, and best of luck!
QUOTE(Capn_Fish @ Apr 29 2007, 11:25 AM)
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!
Thanks, and best of luck!
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
QUOTE
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!
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):
CODE
#!/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}
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 - 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 and http://www.openembedded.org/repo/org.opene...ux-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.
This is sh-scripts that will download most files (except of 2 or 3 you need to download manualy) and patch the kernel.
QUOTE(InSearchOf @ Apr 29 2007, 11:28 AM)
QUOTE(Capn_Fish @ Apr 29 2007, 11:25 AM)
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!
Thanks, and best of luck!
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 there's anything I can do to help push this along, let me know.
QUOTE(Civil @ Apr 29 2007, 11:54 AM)
http://projects.gentoo.ru/gentoo-pda/wiki/...%9A%D0%9F%D0%9A for example. Or look for scripts at http://www.openembedded.org/filebrowser/or...packages/linux/ ( linux-rp_2.6.20.bb + linux-rp.inc )
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.
QUOTE
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/ - 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.
I'm sure it's possible and would benefit both sides but not sure how much political issues, if any, it will arouse.
QUOTE(xjqian @ Apr 30 2007, 01:34 AM)
does it make sense to incorporate pdaxrom as a distro into the openembbed build environment?
Summary: We (OE + OZ) offered that long ago, but pdaX wasn't interested.
QUOTE(xjqian @ Apr 30 2007, 03:34 AM)
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.
I'm sure it's possible and would benefit both sides but not sure how much political issues, if any, it will arouse.
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?
QUOTE(Capn_Fish @ Apr 30 2007, 09:47 PM)
I don't really get the whole OE thing. What benefits would there be to switching to OE?
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?
QUOTE(adf @ May 1 2007, 05:43 PM)
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?
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....
QUOTE(adf @ May 1 2007, 07:43 AM)
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?
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.
QUOTE(Civil @ Apr 30 2007, 01:11 AM)
QUOTE
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/ - there you can find sh-scripts for building kernel - it won't take much time to make your own)
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).
QUOTE(koen @ May 1 2007, 10:08 AM)
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.
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?
What's EABI?
QUOTE(Capn_Fish @ May 1 2007, 01:34 PM)
Thanks for the info. One more question:
What's EABI?
What's EABI?
Here is EABI 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.
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.
QUOTE
#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:
QUOTE
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
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 (it is for sound support)
P.S.S. Maybe you also need to look http://rpsys.net/openzaurus/patches/ here for newer versions of some patches (for example kexec-r5 in 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 ?
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 ?
QUOTE(louigi600 @ May 2 2007, 07:22 AM)
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 ?
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 ?
prolly need to add -lapm
QUOTE(ZDevil @ Apr 30 2007, 03:13 AM)
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.
QUOTE(Capn_Fish @ Apr 30 2007, 06:47 AM)
What benefits would there be to switching to OE?
QUOTE(Meanie @ Apr 30 2007, 09:06 PM)
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.
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.
QUOTE(adf @ May 1 2007, 02:43 AM)
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?
good communication skill and open-minded developers.
QUOTE(xjqian @ May 2 2007, 06:58 AM)
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?)
QUOTE(xjqian @ May 2 2007, 06:58 AM)
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.
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 ?
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 ?
QUOTE(louigi600 @ May 2 2007, 03:04 AM)
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).
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 ?
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 ?
QUOTE(louigi600 @ May 2 2007, 05:30 AM)
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
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
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/. Maybe you are missing some tosa specific patches.
QUOTE(xjqian @ May 2 2007, 12:35 PM)
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/. Maybe you are missing some tosa specific patches.
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 ;-)
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 ?
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.
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 ?
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.
Just a few changes into existing patches... If anyone interested I can post updated versions of them.
QUOTE(Civil @ May 4 2007, 11:17 PM)
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.
Just a few changes into existing patches... If anyone interested I can post updated versions of them.
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.
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).
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?)?
QUOTE(Capn_Fish @ May 5 2007, 10:52 PM)
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?)?
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.
QUOTE(louigi600 @ May 5 2007, 04:10 PM)
QUOTE(Capn_Fish @ May 5 2007, 10:52 PM)
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?)?
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.
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.
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 ;-)
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 ;-)
QUOTE(louigi600 @ Jul 4 2007, 05:14 AM)
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 :-)
QUOTE(XorA @ Jul 4 2007, 01:04 PM)
I doubt this is true, we closed OZ project months ago. I think you mean to advertise Angstrom for us :-)
Yea ... I probabbly meant OE ... anyway the recepy is
http://www.openembedded.org/filebrowser/or...linux-rp-2.6.21
and the archive where I got the patches is
http://www.rpsys.net/openzaurus/patches/archive/
QUOTE(louigi600 @ Jul 4 2007, 07:14 AM)
It would be intresting to merge our efforts ;-)
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.
QUOTE(Hrw @ Jul 4 2007, 01:27 PM)
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.
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.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.