Help New Kernel For Pdaxrom

[Meanie]

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....

[koen]

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.

[louigi600]

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)
[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).

[louigi600]

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 ?

[Capn_Fish]

Thanks for the info. One more question:

What's EABI?

[louigi600]

Thanks for the info. One more question:

What's EABI?
[div align=\"right\"][{POST_SNAPBACK}][/a][/div]

Here is [a href=\"http://http://wiki.debian.org/ArmEabiPort#head-c19223b1bb614d3065443309d6b8fedc8944ce46]EABI[/url] explained in a nutshell.

[louigi600]

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.

[Civil]

#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 (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...

[louigi600]

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 ?

[Meanie]

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

[xjqian]

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.

[xjqian]

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.

[ZDevil]

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.

[louigi600]

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 ?

[xjqian]

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.