Well, I got to thinking that it might be easier to patch CWiid to work with pdaXrom than to replace the entire system. Lo and behold, the latest micro version of CWiid actually compiles cleanly against the old Glibc, so there's not really a problem.
This basically means I'm less motivated to build my own system from scratch. However, this doesn't mean I'm not going to do it. It just means I'm shifting gears somewhat. Specifically:
- I have an iBook on the way, so I'm going to wait for that and use it as my sandbox. This will be infinitely more comfortable than using the Zaurus.
- I might work a little more slowly. But hey, this is my hobby, there's no resisting.
On the positive side, this means I'll be focusing my embedded efforts on the existing pdaXrom again. This benefits more people on the whole. So for the 0 people reading this blog, don't worry about it.
Sunday, March 11, 2007
Wednesday, March 7, 2007
It's Alive...
Well, I just got the first glimmer of hope that my plans will work - I got the Gentoo kernel to load the Angstrom root filesystem after being loaded through U-Boot. So basically, I'm using technology from three different distributions to load a (not very usable) system.
You can try it yourself, but there's not much to see (yet). Assuming you have pdaXrom beta4 or r121 installed on a C1000/Akita:
-Download the kernel here and copy it to an SD/MMC card or USB stick. Renaming it to "kernel-gentoo-arm.img" or somesuch is a good idea.
-Also download the pdaXrom kernel image for Akita and put it in the same location.
-Download the Angstrom filesystem tarball here. You need bzip2 installed on your Zaurus if you're using that to decompress. Take an ext3 formatted SD or MMC (it MUST be one of those; CF won't do) and extract the tarball with the following command: "tar -xvjpf [name of Angstrom tarball] -C [mount point for SD/MMC]"
-And now, get the modules that go with the Gentoo kernel here. Extract to the lib/modules directory on the SD/MMC.
-Press the reset switch inside the battery bay of the Zaurus, while holding OK; wait for the Emergency System to load.
-Move to the location of the kernel images and type the following command - "nandlogical /dev/mtd1 WRITE 0x5a0000 0x160000 [name of Gentoo kernel image]"
-Type reboot and watch the pretty OpenMoko logo.
To switch back to pdaXrom:
-Load the Emergency System again; now, repeat the command to flash the Gentoo kernel, but this time, point it to the pdaXrom kernel.
So now we have a somewhat clunky way to dual-boot between Angstrom and pdaXrom - Angstrom can live on the SD card while pdaXrom lives in the internal flash. There's still a lot to do for Etched Marble, though; Angstrom is already fairly complete. The whole point of Etched Marble is to create a new distribution and document the whole process. So now it comes down to the Linux-from-scratch goodness.
You can try it yourself, but there's not much to see (yet). Assuming you have pdaXrom beta4 or r121 installed on a C1000/Akita:
-Download the kernel here and copy it to an SD/MMC card or USB stick. Renaming it to "kernel-gentoo-arm.img" or somesuch is a good idea.
-Also download the pdaXrom kernel image for Akita and put it in the same location.
-Download the Angstrom filesystem tarball here. You need bzip2 installed on your Zaurus if you're using that to decompress. Take an ext3 formatted SD or MMC (it MUST be one of those; CF won't do) and extract the tarball with the following command: "tar -xvjpf [name of Angstrom tarball] -C [mount point for SD/MMC]"
-And now, get the modules that go with the Gentoo kernel here. Extract to the lib/modules directory on the SD/MMC.
-Press the reset switch inside the battery bay of the Zaurus, while holding OK; wait for the Emergency System to load.
-Move to the location of the kernel images and type the following command - "nandlogical /dev/mtd1 WRITE 0x5a0000 0x160000 [name of Gentoo kernel image]"
-Type reboot and watch the pretty OpenMoko logo.
To switch back to pdaXrom:
-Load the Emergency System again; now, repeat the command to flash the Gentoo kernel, but this time, point it to the pdaXrom kernel.
So now we have a somewhat clunky way to dual-boot between Angstrom and pdaXrom - Angstrom can live on the SD card while pdaXrom lives in the internal flash. There's still a lot to do for Etched Marble, though; Angstrom is already fairly complete. The whole point of Etched Marble is to create a new distribution and document the whole process. So now it comes down to the Linux-from-scratch goodness.
MMC/SD Mounting
Well, I've made just an infinitessimal bit more progress. I'm currently trying to boot the kernel compiled for the new Gentoo on Zaurus project (Russian link), but it's weird. I have to explain just a little about the pdaXrom bootloader (which I still have a bit to learn about myself).
pdaXrom beta4 and r121 (and presumably the elusive r179) use a bootloader called U-Boot, which is a universal bootloader for ARM devices. The only way to configure it is to hook up a serial terminal to the machine it's running on, so there's no way to send arguments to the kernel without said serial link. Both pdaXrom and the Gentoo/Zaurus kernel use a built-in feature that lets you compile as many arguments directly into the kernel as you like.
Now, from there, pdaXrom has an argument to boot from the internal flash. Gentoo/Zaurus boots from whatever is in the SD slot. Where it gets weird, is that it can only see the SD slot when the CF slot has a card in it. I have no idea why without hooking up a serial terminal (which I don't have) to debug.
And hey, it might just be my SD card. On the positive side, I have a kernel that boots. Now I just need an OS to load.
--Update-- Looks like it's time to compile my own kernel - I'll have to pass an init= value directly, which the Gentoo kernel doesn't do. Maybe I'll fix this whole SD problem as well.
pdaXrom beta4 and r121 (and presumably the elusive r179) use a bootloader called U-Boot, which is a universal bootloader for ARM devices. The only way to configure it is to hook up a serial terminal to the machine it's running on, so there's no way to send arguments to the kernel without said serial link. Both pdaXrom and the Gentoo/Zaurus kernel use a built-in feature that lets you compile as many arguments directly into the kernel as you like.
Now, from there, pdaXrom has an argument to boot from the internal flash. Gentoo/Zaurus boots from whatever is in the SD slot. Where it gets weird, is that it can only see the SD slot when the CF slot has a card in it. I have no idea why without hooking up a serial terminal (which I don't have) to debug.
And hey, it might just be my SD card. On the positive side, I have a kernel that boots. Now I just need an OS to load.
--Update-- Looks like it's time to compile my own kernel - I'll have to pass an init= value directly, which the Gentoo kernel doesn't do. Maybe I'll fix this whole SD problem as well.
Tuesday, March 6, 2007
After Some Experimentation...
Well, I haven't gotten OpenEmbedded working just yet. Still not sure if I want to use it in the long run - though what I'm probably gonna end up doing is a cross-compiled environment (done manually) to get my bearings, and then switch to OE when things get serious.
The main hurdle I'm running into is the kernel - for whatever reason it won't detect the MMC/SD slot while booting. This is bad because I'm wary of touching the internal flash for now. Hopefully I'll have this worked out soon.
EDIT 12:08am: I have this worked out. For some reason it just doesn't report seeing the SD card unless there's some UNIXy directories on it. Dunno why, but now I can focus on getting a working system of some sort.
The main hurdle I'm running into is the kernel - for whatever reason it won't detect the MMC/SD slot while booting. This is bad because I'm wary of touching the internal flash for now. Hopefully I'll have this worked out soon.
EDIT 12:08am: I have this worked out. For some reason it just doesn't report seeing the SD card unless there's some UNIXy directories on it. Dunno why, but now I can focus on getting a working system of some sort.
It Begins
Well, I'm declaring the beginning of the Etched Marble experiment.
Etched Marble's primary goal is for me (Ikkakujyu) to learn how to put together a Linux system. Its secondary goal is to try and make Linux at least a little easier to use, but not at the expense of configurability.
Development is currently focused on Sharp Zaurus clamshell models (SL-Cxx00, SL-C7x0/860). Once it has reached some stability there, focus will expand to PowerPC and x86/x86_64 hosts.
There are still some considerations to make as to the underlying systems, namely:
-Native compilation, or BitBake/OpenEmbedded-driven cross-compilation?
-Which package format should be used?
-uClibc or Glibc on Zaurus host?
-etc.
At the very least, a window manager has already been chosen: Enlightenment DR17. This is supposed to be alluded to in the project's name (starts with an E. I would have called it Entropy if that weren't already taken.) Outside of that, the sky's the limit.
Etched Marble's primary goal is for me (Ikkakujyu) to learn how to put together a Linux system. Its secondary goal is to try and make Linux at least a little easier to use, but not at the expense of configurability.
Development is currently focused on Sharp Zaurus clamshell models (SL-Cxx00, SL-C7x0/860). Once it has reached some stability there, focus will expand to PowerPC and x86/x86_64 hosts.
There are still some considerations to make as to the underlying systems, namely:
-Native compilation, or BitBake/OpenEmbedded-driven cross-compilation?
-Which package format should be used?
-uClibc or Glibc on Zaurus host?
-etc.
At the very least, a window manager has already been chosen: Enlightenment DR17. This is supposed to be alluded to in the project's name (starts with an E. I would have called it Entropy if that weren't already taken.) Outside of that, the sky's the limit.
Subscribe to:
Posts (Atom)