Pdaxrom B3 For C3000

[zi99y]

In my experience, all linux distros area about tweaking around until you get a useable OS, pdaxrom beta 3 is just another distro in the same way.

I realise it may take some people quite a while to get it working properly, but that's only because it's so highly customisable.

Things I would add to make beta3 more usable:

I would recommend using fluxbox for speed.

Ensure the Latest hostap drivers are installed by default (for Planex CF wifi and maybe others)

Get a decent keymap in there, like meanies.

[danboid]

I have heard some people say that as long as you use the menu feature (as opposed to using the on/off button) and you suspend when there isn't heavy disk activity then the feature is pretty reliable. 

Really?

Can any c3000 owners running pdaXb2 confirm that you can reliably suspend on 1st attempt without the HD LED staying on by clicking on a menu (menu? Where? Is this a matchbox app you're referring to?) option instead of pushing the on/off button? If this is true I'll likely give pdaXrom another go as I'm sick of waiting for OZ to catch up in functionality, although as has been mentioned it is faster and stabler in some respects thanks to the 2.6 kernel.

[fooman]

I tried flashing to pdaXrom 1.1.0beta1 for C3k (beta 2).  I tried it out for about 1-2 hours and then decided to switch back to Cacko.  I applied Meanie's fixes but I could never get my Z to properly restore.  I suspended by using the menu function or the on/off button.  Then I waited about a minute or so for everything to settle down.

When I hit the on/off button to restore the Z, I saw the HDD light go on for a few seconds but after I waited, nothing else happened for at least a minute.  Then I hit the on/off button again.  Sometimes nothing happened but other times the screen would appear again but everything was frozen.  The only way to get the Z working again was to hit the reset button in the battery compartment.

I use a CF Ethernet card with my C3000.  Someone else reported a similar problem with suspend/restore, reported here.  I think I may have tried it with my CF Wifi card with similar results.  But I gave up because even though the Sharp/Cacko ROM is old, at least I can get it to work without too much hassle.    

I was sorry to see this because I've read a lot about pdaXrom and I really wanted to use it.  But at least for me, suspend/restore was a showstopper.

[kahm]

I'd love to see a stable pdaxrom for the 3000. I just wiped THCs beta 2 off my 3000 in favour of the Sharp Rom. (To be used for Kanji study..) If a stable version could be made I'd be very happy to have firefox back again

[danboid]

A very experienced programmer (says he's been using emacs for 20 years!) has been in touch with me. He owns a C3000 and is very keen to help out in the development of pdaXrom for our platform but he's been having problems registering with OESF. I told offroadgeek about his problems but Ian still hasn't heard anything and still isn't registered.

If anyone is able to help him with getting registered or wants to discuss what he might be able to do in improving pdaX on c3k then you can get in touch with Ian at tanjianenator@googlemail.com

[zi99y]

Great that someone else is interested in contributing. I saw a post from InSearchOf mentioning he was interested in working on some pdaxrom development, I'd volunteer myself but I'm rather inundated with Windows development (boo hisss )

[chrisluu]

Well, I had a little bit of time today, so I took a look at the kathrin-1.1.0beta3-akita zip file and started comparing it to ThC's pdaXrom-c3000beta2 release to see what would need to be done to get a nice stable version of pdaXrom running on the c3000. Personally, pdaXrom did exactly what I needed to, but I couldn't stand the instability of it (when I used beta2, I would have to reboot my zaurus constantly due to FS errors), which got me to switch to OpenZaurus, where I had no stability problems except if I didn't touch my zaurus for a while.

Looking through the initrd files, we should be able to use the same root structure without too much hassle. We'd just have to figure out the bare minimum we'd want flashed onto the ROM in order to pivot to the hard drive and go from there. We could also probably use the same initrd file, if I'm not mistaken, as all it does is pivot the root to the hard drive. I may have a go at flashing the pdaXrom-c3000beta2 with only replacing the hdimage1.tgz with the beta3 ripped root directory.

The main problem is that we'd still be using the same kernel that ThC compiled for beta2, in the tools.tar file. I've compiled kernels before, but never for the zaurus, so I don't really have an environment setup to do it, nor do I know anything about the pdaXrom build tools or where the proper patches are to patch the kernel with what is necessary. Is anyone still even interested in this at all? I guess I got kind of tired of no one really taking any initiative in getting proper C3000 support. I'm really rather busy though, so I'll help when I can, but we need as much help as we can. Let's also document everything we do as much as possible so future people can take over as necessary.

[Meanie]

Well, I had a little bit of time today, so I took a look at the kathrin-1.1.0beta3-akita zip file and started comparing it to ThC's pdaXrom-c3000beta2 release to see what would need to be done to get a nice stable version of pdaXrom running on the c3000. Personally, pdaXrom did exactly what I needed to, but I couldn't stand the instability of it (when I used beta2, I would have to reboot my zaurus constantly due to FS errors), which got me to switch to OpenZaurus, where I had no stability problems except if I didn't touch my zaurus for a while.

Looking through the initrd files, we should be able to use the same root structure without too much hassle. We'd just have to figure out the bare minimum we'd want flashed onto the ROM in order to pivot to the hard drive and go from there. We could also probably use the same initrd file, if I'm not mistaken, as all it does is pivot the root to the hard drive. I may have a go at flashing the pdaXrom-c3000beta2 with only replacing the hdimage1.tgz with the beta3 ripped root directory.

The main problem is that we'd still be using the same kernel that ThC compiled for beta2, in the tools.tar file. I've compiled kernels before, but never for the zaurus, so I don't really have an environment setup to do it, nor do I know anything about the pdaXrom build tools or where the proper patches are to patch the kernel with what is necessary. Is anyone still even interested in this at all? I guess I got kind of tired of no one really taking any initiative in getting proper C3000 support. I'm really rather busy though, so I'll help when I can, but we need as much help as we can. Let's also document everything we do as much as possible so future people can take over as necessary.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=145986\"][{POST_SNAPBACK}][/a][/div]

i've just been doing the same thing.
my findings is that we can use the pdaXrom-c3000beta2 to create a beta3.

there would be 3 things we need to update/fix

hdimage.tgz contains the rootfs for the c3000 so we can easily customise/update this file. i would overlay it with the root image of akita and then apply some fixes and add more pre-installed apps.

update the kernel. since it is a 2.4.20 kernel i was thinking to replace the zImage file inside tools.tar with the latest Tetsu zImage and extract the corresponding tetsu modules ipk over the lib directory inside hdimage.tgz

finally, i would fix initrd.bin up a bit. all it does is load a minimal oz rootfs image onto the flash which then pivots to the microdrive. it basically works, but has a few minor bugs such as trying to boot off the external CF if its inserted instead of the microdrive. i would also want to add some tools like fsck onto there so it can do some sanity checks on the microdrive before mounting it. some boot menu ala altboot could also be added there to allow optional booting off the external CF or SD card.

i probably could do all that given time, except i have no idea how to extract the initrd.bin file from a Z directly. i think it needs to be done from a linux pc.

[chrisluu]

Sounds good. For the fixes, do you basically mean the fixes you have here:

http://www.users.on.net/~hluc/myZaurus/custom-pdaxrom.html

or are there other fixes that need to be applied? Customizing hdimage.tgz is probably the last thing we need to do, as it's simply a matter of providing the root fs that will be booted (like you said, changing default programs and such).

Your kernel idea sounds good. I didn't think about using the Tetsu kernel as I've never used it before.

In terms of initrd, couldn't we just modify the initrd provided in beta2 with the fixes listed on your site to provide the fsck, and the external CF card fixes? We can work on improving the initrd with a boot menu and such after we get a booting system, I think, with the improved kernel and updated root fs.

Why do you need to rip the initrd.bin from a Zaurus file? If we're just applying fixes to an existing initrd, couldn't we just mount it, fix it, unmount it, and re-rip it from the /dev/mtdblock0? I'm not terribly familiar with the whole process yet, so I'm not exactly sure.

[Meanie]

Sounds good. For the fixes, do you basically mean the fixes you have here:

http://www.users.on.net/~hluc/myZaurus/custom-pdaxrom.html

or are there other fixes that need to be applied? Customizing hdimage.tgz is probably the last thing we need to do, as it's simply a matter of providing the root fs that will be booted (like you said, changing default programs and such).

Your kernel idea sounds good. I didn't think about using the Tetsu kernel as I've never used it before.

In terms of initrd, couldn't we just modify the initrd provided in beta2 with the fixes listed on your site to provide the fsck, and the external CF card fixes? We can work on improving the initrd with a boot menu and such after we get a booting system, I think, with the improved kernel and updated root fs.

Why do you need to rip the initrd.bin from a Zaurus file? If we're just applying fixes to an existing initrd, couldn't we just mount it, fix it, unmount it, and re-rip it from the /dev/mtdblock0? I'm not terribly familiar with the whole process yet, so I'm not exactly sure.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=145988\"][{POST_SNAPBACK}][/a][/div]

yep, basically those fixes as a minimum. there probably are more fixes others could suggest.

as for the initrd.bin file, i agree we should first get a stable working one first before adding extra features. the problem is that its a mtd block and jffs2 file formatted image. its not so straight forward to extract, modify and rebuild, at least not from Sharp ROM.

[chrisluu]

Just for fun, I played around with the initrd and tried to build my own with the beta2 initrd and applying your fixes. I used the instructions here:

https://www.oesf.org/index.php?title=C3000_Device_Specifics

to extract, modify, and rebuild the initrd, including the SHARP header. Unfortunately, when I tried to boot with this initrd, I got these errors:

Code: [Select]

CLEANMARKER node found at 0x00280000 has totlen 0xc != normal 0x0
VFS: Mounted root (jffs2 filesystem) readonly.
Freeing init memory: 80K
and then it just hung, so I'm assuming there's something I don't know about building an initrd file (quite likely). I also tried to use a new tools.tar file with Tetsu's kernel and new hdimage.tgz with the beta3 files and also the /lib/modules/2.4.20 folder replaced with the one provided with Tetsu's modules ipk then tried to boot with ThC's original initrd, but this also gave me problems. It said that it couldn't parse the modules.dep file (which has a file length of 0) and also it couldn't find the pcmcia/ide-cs.o file, which doesn't exist. I've never used Tetsu's kernel before... are these modules possibly built into the kernel and we need to modify the initrd to not require that module?

[Meanie]

Just for fun, I played around with the initrd and tried to build my own with the beta2 initrd and applying your fixes. I used the instructions here:

https://www.oesf.org/index.php?title=C3000_Device_Specifics

to extract, modify, and rebuild the initrd, including the SHARP header. Unfortunately, when I tried to boot with this initrd, I got these errors:

Code: [Select]

CLEANMARKER node found at 0x00280000 has totlen 0xc != normal 0x0
VFS: Mounted root (jffs2 filesystem) readonly.
Freeing init memory: 80K
and then it just hung, so I'm assuming there's something I don't know about building an initrd file (quite likely). I also tried to use a new tools.tar file with Tetsu's kernel and new hdimage.tgz with the beta3 files and also the /lib/modules/2.4.20 folder replaced with the one provided with Tetsu's modules ipk then tried to boot with ThC's original initrd, but this also gave me problems. It said that it couldn't parse the modules.dep file (which has a file length of 0) and also it couldn't find the pcmcia/ide-cs.o file, which doesn't exist. I've never used Tetsu's kernel before... are these modules possibly built into the kernel and we need to modify the initrd to not require that module?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=146002\"][{POST_SNAPBACK}][/a][/div]

not sure about the initrd.bin bit, but if you send me a tarball of its content, then I could give it a go also.

as for the modules, did you replace the existing lib directory with the lib directory of tetsu's modules? it does not contain everything, but rather is a set of updatede modules so you would need the existing module files and just copy the tetsu ones on top to overwrite and replace some of them.

[chrisluu]

not sure about the initrd.bin bit, but if you send me a tarball of its content, then I could give it a go also.

as for the modules, did you replace the existing lib directory with the lib directory of tetsu's modules? it does not contain everything, but rather is a set of updatede modules so you would need the existing module files and just copy the tetsu ones on top to overwrite and replace some of them.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=146022\"][{POST_SNAPBACK}][/a][/div]

Oh, I thought Tetsu's ipk provided all the necessary modules. I'll try that again. I've attached a tar.gz of the modified initrd I tried. It's got the two fixes you have on your website applied (to provide fsck and to boot even with an external CF card inserted), but it didn't work for me.

Well, I just tried it with Tetsu's module ipk overlaying the original beta 3 hdimage.tgz's modules and I still get the same error. Sure enough, even after not replacing, but overlaying Tetsu's modules, there is still no ide-cs.o module. Maybe ThC's compiled kernel had that built in (so that he wouldn't need the module in the initrd), but Tetsu's kernel does not. I'm not sure.

[realm]

Another way you can run whatever distro you want on your 3k i described in my post here:

https://www.oesf.org/forums/index.php?showtopic=21540&hl=

The nice thing about just using the Oz kernel and installer to install pdaxrom is you can run any version of pdaxrom, because the oz kernel boots from the c3k hard drive, so its transparent to pdaxrom. there is a SMALL probability that because the modules and kernel could have been compiled with different options of a problem coming up, but i use the hostap driver, hid for a usb kb, and usb-storage for a hd and never had any stability issues.

Using the oz kernel to boot a standard pdaxrom install also helps keep us from making a c3k fork of pdaxrom, more effort can then be focused on pdaxrom itself, and not workaround hacks. the only thing that should be put in place for pdaxrom in reguards to the 3k is change the kernel option on the 3k distro to boot from (names here may be wrong, i'm going from memory) /dev/hda1 instead of /dev/mtblock1.

on the suspend issue i always suspend with apm --suspend, and never have any problems, the button just seems to give me issues, so i don't use it.

I hope this helps some ppl, enjoy

[chrisluu]

Another way you can run whatever distro you want on your 3k i described in my post here:

https://www.oesf.org/forums/index.php?showtopic=21540&hl=

The nice thing about just using the Oz kernel and installer to install pdaxrom is you can run any version of pdaxrom, because the oz kernel boots from the c3k hard drive, so its transparent to pdaxrom. there is a SMALL probability that because the modules and kernel could have been compiled with different options of a problem coming up, but i use the hostap driver, hid for a usb kb, and usb-storage for a hd and never had any stability issues.

Using the oz kernel to boot a standard pdaxrom install also helps keep us from making a c3k fork of pdaxrom, more effort can then be focused on pdaxrom itself, and not workaround hacks. the only thing that should be put in place for pdaxrom in reguards to the 3k is change the kernel option on the 3k distro to boot from (names here may be wrong, i'm going from memory) /dev/hda1 instead of /dev/mtblock1.

on the suspend issue i always suspend with apm --suspend, and never have any problems, the button just seems to give me issues, so i don't use it.

I hope this helps some ppl, enjoy
[div align=\"right\"][a href=\"index.php?act=findpost&pid=146079\"][{POST_SNAPBACK}][/a][/div]

Well, I think using the OZ kernel works just fine for maybe Beta 4 and 1.10r121 because they run on a 2.6 kernel. Beta 3 runs on a 2.4 kernel, so I don't think it'd work. Out of curiosity, I just tried it and it wouldn't boot up with the Beta 3 hdimage1.tgz at all (froze after displaying the OpenZaurus logo).

One of the main reasons I'd like to use a pdaXrom-based kernel is for the BVDD support, which OZ doesn't support. They're working on their own method of acceleration, but that will take some time to get out. Being able to have an accelerated Mplayer and to use psx4zaurus is a major plus for me.