Well actually Sleep_Walker is working on the 680. He has booting, touchscreen, bluetooth and keyboard working. Currently having some difficulty with suspend and GSM.

If you have a Centro, you could help! Run Cocoboot on it and tell us the values from the "CPU", "Memory" and "LCD registers" options in the "Info" menu. Also run "Dump MMU" with an SD card inserted and paste the contents of the memorymap.txt file created on the SD card. We should be able to make it at least boot with just with those values. If you're willing to do a bit of testing we can probably get the keyboard working too.

Most of the development happens on IRC in #hackndev on irc.freenode.net. That's really the best place to be if you want to be up to date. We just post something on the site from time to time when it occurs to us. :P

Verizon Wireless branded blue Centro (CDMA)
Memory:
RAM base: 0xa0000000
size: 32 mb (0x1d0c000)
Phys TTB: 0xa1ffc000
Virt TTB: 0x1ffc000

LCD Registers: resets phone.
LCD Test: resets phone.
Dump MMU: writes empty file and resets phone.
CPU:
Machine: D062
CPU ID: 0x69054117
CPU: Intel PXA27x

Cocoboot runs to the "ok" after loading Zimage and initrd.gz then resets phone.

Any help is appreciated.
Keep up the good work!

Hmm.. That's problematic as the LCD registers are fairly important. The reset also happens on the 680, so I'll have to look into what is happening and update Cocoboot, but I can't right at the moment.

Likely the values are the same as the 650 and 680 but to be on the safe side we'd better make sure. The other way to do it is to dump them manually with haret/p. If you'd like to try that (it's pretty quick and easy), grab haret/p from here:

http://releases.hackndev.com/tools/haretp/haretp-treo.prc

To run haret/p you'll also need the stdiolib.prc library if you don't already have it installed, you can get it from here:

http://www.ppcompiler.org/file/StdioLib.zip

When you run haret/p you should get a white screen with black text and a prompt like:

HARET/P
VERSION 1.1
>

Type in this command: (be careful to get it right, missing a zero or something like that will most likely reboot the phone)

dump 94000000

You should get something like:

94000000: 062000E11207113F (then some gibberish characters that we don't care about)

Do the same for:

> dump 94000008

94000008: 0705053F04700007

Please check whether the numbers are the same as the ones I've posted (which are from the 680). If they're different please post what they are here. If you get just get a reset on typing the dump command, let us know too, it would mean things have changed quite a bit in the Centro compared to every other PXA palm.

Just to explain, these are the PXA's LCCR registers we're dumping. These configure how the CPU talks to the LCD, and hold settings like how fast to update, how long to wait after writing each line of the display and so forth. It's important we get them right or the screen will just display gibberish in Linux. How they're interpreted is documented in the CPU's developer manual:

http://pubs.gumstix.org/documents/PXA%20Documentation/PXA270/PXA270%20Pr...

Once we have the LCD register values I'll make up a zImage for you to try with Cocoboot.

The numbers are the same as those you posted. Wish I was more experienced with linux and less than 17 years out of practice programming... :p ...or I could be more help. No better incentive to work on my linux literacy than the potential of getting it on this Centro, though!
Thanks again! I'll be happy to help however I can getting this to work.

ARM Linux machine registered: 1944 (centro)

I'll build a zImage and add support to Cocoboot tonight or tomorrow when I have time.

Here's a few more dumps for anyone with a Centro and some spare time to try in haret/p. These are the GPIO registers, they set how the CPU pins are configured for communicating with other components on the board. They'll help get us started on figuring out how to talk to the keypad, modem, bluetooth etc. Please turn on all the functions you can (bluetooth, phone, infrared, insert an SD card etc) before dumping.

Pin-level and directions:

dump 90e00000
dump 90e00008
dump 90e00010

Alternate functions:

dump 90e00054
dump 90e0005c
dump 90e00064
dump 90e0006c

Extended GPIO level and directions:

dump 90e00100
dump 90e0010c

Pin-level and directions:
dump 90e00000: 148d01fefc025cc4
dump 90e00008: 88cd6fffcf7b1400
dump 90e00010: ffff2bc3d3ffffff
Alternate functions:
dump 90e00054: 0c000000a5000012
dump 90e0005c: 69988050aaa00008
dump 90e00064: 02aaaaaa44440000
dump 90e0006c: 02aa95ff00001400
Extended GPIO level and directions:
dump 90e00100: 01e81f8100000000
dump 90e0010c: 006dff8100000000

The first two (90e00000 and 90e00008) change a few digits if dumped more than once.

Now I'm starting to get excited.
I'm quite enjoying this process.

Sorry, I haven't had a chance to build Centro zImage yet. Been busy debugging some 680 issues (that will probably affect Centro too). I have however made a new 0.5.1 release of Cocoboot which adds the Centro's Linux machine number. Grab from here:

http://releases.hackndev.com/tools/cocoboot/

Delete it off your phone's internal storage first, before trying the new version or it'll (silently) run the old version.

Please confirm it says "1944 Palm Centro" at the top of the Cocoboot main window.

Now, since the Centro has the same LCD settings as the 680 you could try a 680 kernel. Grab Sleep_Walker's from here:

http://sleepwalker.hackndev.com/kernel/zImage-k27x-sw1

Save that file to your SD card and rename it as just "zImage". Then run that new version of Cocoboot, but don't press boot immediately. Instead, change the number in the top left corner from "1944" to "1230". This is to trick Linux into thinking it's running on a 680 instead of a Centro (otherwise it'll just hang cause it thinks its on an unsupported machine).

You don't need a initrd.gz. Then press boot and see if you get Linux boot messages, or it resets, or the LCD fades to white, or it just hangs.

New cocoboot does recognize my device as 1944 Palm Centro.
With that zImage and 1230 in machine type, cocoboot loads zImage, says OK, and device resets.
I really appreciate the time you're putting into this.
Thanks again!

Drat. Well this is going to be difficult to track down. The only thing I can suggest is the same Cocoboot debugging process I mentioned to strags:

http://hackndev.com/node/222#comment-842

Ok, tried that process and got the same results posted in the linked thread... cocoboot-10 hangs and -9 resets. No initrd. Changed machine to 1230 as stated. Guess I'll have to get off my lazy behind and install my SDK to start working on this too. Still pretty cool to have this in active process instead of endless web searches looking for a plug-n-play solution.
Wheee! I haven't had this much fun since I had to disassemble the 32K ROM in my TRS-80 CoCo to find the sound registers to make a primitive digitizer... Guess that shows my age, eh?
Kudos for your help!

I think I've found the problem:

http://hackndev.com/node/222#comment-848

Please try 0.5.2 and see if it helps. :-)

Heh. Good luck. I've been using Debian recently so I installed the old, old, prc-tools packages from sarge which worked ok.

hmmm... the virt ttb address is corrected when running 0.5.2 but it still resets immediately after loading the zImage... so fast that I can't see if it says ok or not. I'm gonna get on installing my SDK tonight so I can participate more fully in this.
OMG, the Palm SDK is such a pain... I'm reformatting my extra computer to Gentoo so I can have an easier time, I hope...
I'm also not sure that the zImage is loading before reset running the 0.5.2 cocoboot, I don't see any numbers or an OK before the reset anymore.
edited again:
another hard reset to clean my system (third since I started this, but still no more than I usually have to do for trying old/weird apps anyway), and downloaded new copies of the linked zImage and cocoboot 0.5.2, now cocoboot loads the 680's zImage and then hangs. No reset anymore, but certainly not from anything I've done :P
Noticed that strags has gotten to login prompt on his 700p? Awesome. If I was only as competent...

Boot! Boot!
Muahahahahaha!
Sleep_walker's work is coming along great, his kernel for the 680 works with the cocoboot 0.5.2 on my Centro all the way to trying to load the root fs, where it hangs at:

No filesystem could mount root, tried: squashfs msdos
Kernel panic - not syncing: VFS: unable to mount root fs on unknown block (1,0)

if I add the treo650 initrd.gz to the root of my SD, and type:
init=/linuxrc
on the command line of cocoboot, there is an additional error during boot right before the two I just listed, about RAM... I'll run it again and edit in the complete error in a few, I just had to post the success you all have provided for me!
Thank you!
edit: OK, it doesn't require the command-line entry of init=/linuxrc to give the RAMDISK error, just having initrd.gz present is enough. The complete error:
RAMDISK: Couldn't find valid RAM disk image starting at 0.
I am using a treo 650 initrd.gz, might be old, gonna search and make sure my filesystem files are up-to-date. Oh yeah, I forgot to mention, the hang in cocoboot at the end of my previous post was caused my not changing the machine i.d. in cocoboot to 1230.

hey i got different numbers from haret/p.

94000008 0605053f04700007

just want to help

Hi ibussatti,

That's interesting. The difference is in the "Beginning of frame wait count" which is how the top of the display is positioned. It could mean that the top of the screen will be off by one pixel when using the 680 kernel.

Thanks for letting us know!

bigsupersquid, great to hear it's working!

Either the SD driver is not working or you haven't got a root filesystem setup correctly. Here's what I do at the moment.

Partition an SD card into two partitions:

1. 50mb or so FAT16 or FAT32 (this is for Palm OS stuff and for putting Cocoboot and zImage)
2. the rest is an ext3 partition to install Linux into.

For development work, I have Debian/armel installed on the card (instructions) so that I can install a full gcc and others tools just using apt-get without having to bother compiling anything. This requires you to have USB networking working though (or you can boot it on a different handheld, or in qemu and install stuff).

I then use no initrd and set the command-line in Cocoboot to:

root=/dev/mmcblk0p2 rootdelay=1

The root option tells Linux to boot the second partition on the MMC (SD) card and the rootdelay tells it to wait one second before booting off it. This is because it takes a little while for the card to be detected.

You can save typing that in all the time by creating a file cocoboot.conf in the FAT partition of your SD card containing:

cmdline=root=/dev/mmcblk0p2 rootdelay=1

See the wiki for other stuff you can configure in cocoboot.conf.

Sleep_Walker and kEdAR use some other complicated scheme involving initrds, ramdisks, squashfs and unionfs. Which I suppose might be faster but probably uses more memory. I haven't tried their way, but there's an initrd and kernel modules for it on the 680.

I think the way you're supposed to use it is to rename the kernel to "zImage" and the initrd to "initrd.gz" (or create a cocoboot.conf that points at them) and put them in the root directory of the SD card. The create a "linux2ram" directory to put squashfs files in. I suppose you can install additional things by grabbing more squashfs files from kEdAR's website.

Partition...ummm...
Spent some hours trying to find a way to partition SD card with Win-doze last night/this morning, but it just won't do it. Gotta go to work, will play later.
Thanks for info, instructions, and help!

Ah. You're on Windows? That's going to make life difficult. Maybe there is a way but I wouldn't know, I almost never have to use Windows. I doubt Windows has support for ext3 though, so you'll probably really need a Linux box of some kind, even a live cd of some sort would do.

On Linux one would do this, where /dev/sdX is the SD card device. Be careful you don't accidentally partition your hard disk instead. If you don't know the device name, plug and unlplug it and it should be mentioned by the output of the command "dmesg | tail".

You'll need to do this all as root, so do "sudo -i" to switch to root first. This will erase your SD, so backup anything you want to keep first.

fdisk /dev/sdX
d (delete any existing partition)
n (create a partition)
p (primary)
1 (partition #1)
(enter) (start at the first cylinder)
+50m (size of about 50 mb)
t (select partition type)
6 (FAT16)

n (create a partition)
p (primary)
2 (partition #2)
(enter) (start at first free cylinder)
(enter) (end at last free cylinder)

wq (save and exit)

Then format the partitions with:

mkfs.msdos /dev/sdX1
mkfs.ext3 /dev/sdX2

Mount them and copy stuff on:

mkdir /mnt/palmos /mnt/linux
mount /dev/sdX1 /mnt/palmos

mkdir -p /mnt/palmos/palm/Launcher
cp cocoboot.prc /mnt/palmos/palm/Launcher
cp cocoboot.conf zImage /mnt/palmos

Unpack Debian:

tar -C /mnt/linux -jxvpf ~/debian-lenny-armel-20081004.rootfs.tar.bz2

Unmount, ready to go:

umount /mnt/palmos
umount /mnt/tmp

I've heard some people report that Palm OS doesn't like the FAT filesystems created on a PC and tries to format them again when you put SD card in. This hasn't happened to me, but if it happens to you, one workaround I've heard is to let Palm OS format it, then resize the partition with something like gparted and create the ext3 partition in the freed up space.

thx for the data.
I do have an ext2 translation software for my MicroBofft Win-Doze box, but not ext3. I've wanted to switch to linux for a long time, it's just been too easy to tolerate Win-Doze since I lack hardware drivers for linux to use many of my toys. Recently tried 2 different live cds (loonix and ubuntu) and fried my MicroBofft install plus couldn't get either cd to output more than a vertical line when the boot got past text mode. Ugh. You say Debian is good for development? I'll try that flavor on my "new" box. My last linux experience was redhat 5, a while ago.
I am so looking fwd to portable linux to play/learn with.
Too wordy? sorry ;)
I think this forum/site is just awesome, with active developers who give us newbies a hand up? wow!

> since I lack hardware drivers for linux to use many of my toys.

Strange. Linux has very good hardware support these days, it's not often that I run across something that doesn't work. I guess some of the more obscure peripherals and things like wireless and TV cards made by one or two resistant companies are unsupported though.

> Recently tried 2 different live cds (loonix and ubuntu) and fried my MicroBofft install

How did you manage to fry the Microsoft install? Did you try installing them? Normally a live cd shouldn't touch the hard disk. :-/

> plus couldn't get either cd to output more than a vertical line when the boot got past text mode.

What sort of video card do you have? I've never heard of that happening before. This guy mentions vertical green lines on an Nvidia 6600GT:

http://ubuntuforums.org/archive/index.php/t-321483.html

The thread is a few years old though and I've seen Ubuntu run fine on Nvidia 6600s before.

> You say Debian is good for development? I'll try that flavor on my "new" box.

Well, it's really just a preference, you can generally do anything on any distro, it just might be slightly different how things are done. I just like Debian on the handheld for development as opposed to Angstrom or something else built using OpenEmbedded as I can use Debian's large set of pre-compiled packages. It's no good for production handheld use as it uses a lot of disk-space, as it's a distro intended for desktop PCs and servers.

Debian is a distro that several others including Ubuntu are based upon. Ubuntu is basically just Debian with a focus on being more user-friendly and making things just work out of the box. I'd normally suggest starting with Ubuntu for a desktop PC, as it comes with a lot of stuff pre-configured and pre-installed. Using straight Debian can be a better option for servers or when you've become more experienced and know exactly which packages you need and how to configure them.

Another option is to run Linux inside a virtual machine such as VirtualBox inside Windows. This means you don't have to worry about any hardware issues and can mess around content that you won't be able to break anything. You can even configured USB devices to be "passed-through" to the virtual machine, so for example if you have a USB memory card reader you can partition it from within the virtual Linux box.

yah, I got crusty old hardware which never used to have linux support. Dunno what crashed my system when trying live cds, couldn't see what was happening. don't care, I reformat windoze almost as often as I hard reset my palm (often.) video card ati allinwonder agp (rage pro 128mb). also same video problem with builtin mobo video on 10 yr old box. debian installed fine on my alternate box last night, 1.5 hr iso download 1 hr to install. looks great. expect things will get interesting soon as I need software for my palm-as-modem and the install cd only supports windoze and mac. thanks again for the help and feedback, tonight I should have time to format/partition my sd for more experimentation.

Got card partitioned and debian-lenny unpacked on partition 2 using ext3 fs. now cocoboot doesn't see the cocoboot.conf file in the fat root directory but does see/load the zImage, and when I manually type the root=/dev/mmcblk0p2 rootdelay=1 on the command line,
I get a new error at the same place in the boot sequence...
VFS cannot open root device "mmcblk0p2" or unknown-block (0,0)
please append a correct "root=" boot option
followed by the kernel panic error.
perhaps I set up something wrong on the card, I will look into it more tomorrow.
you mentioned a sd driver issue perhaps? is there an easy way to check that on my end?
I really appreciate all your time and help with you've given me on this, Alex. Hope all my questions don't interfere with your own projects.

My pin level diferent too

Pin-level and directions:
dump 90e00000: 04a503fffc02ddc4
dump 90e00008: 8ccd3fffcf7b1400
dump 90e00010: ffff2bc3d3ffffff
Alternate functions:
dump 90e00054: 0c000000a5000012
dump 90e0005c: 69988050aaa00008
dump 90e00064: 02aaaaaa44440000
dump 90e0006c: 02aa95ff00001400
Extended GPIO level and directions:
dump 90e00100: 01e81f8100000000
dump 90e0010c: 006dff8100000000

hey ibussatti, I noticed that at least 3 of those dumps changed somewhat everytime I dumped them myself, even without exiting haret/p. I am curious, what version of the Centro do you have? Is the radio GSM or CDMA? I've read that the GSM version has the aGPS unlocked, where the Sprint and Verizon models have CDMA radios and both cannot access the aGPS functions except externally from the service provider. If you have a GSM model (I think AT&T Centros are GSM) I am very interested in picking apart the GPIO differences to find out how to trigger the aGPS functionality. If you want to see a nifty GPS data output screen built into the phone, you could try to type on the phone keypad (in telephone mode):
##56228466#
or on the Verizon model,
#*#56228466#
this spells ##location# on a phone keypad, by the way.
The screen which comes up is chock-full of GPS function readouts, but on my model there is some kind of software block which makes every function on that menu read zeroes. The same command works on other Palm Treos as well for anyone else who wants to look at it.

bigsupersquid,

Hmm. Try increasing the rootldelay option a bit. If its detecting the card there should be a message near the end of the output (but before the error) listing the partitions. It sounds like it's not detecting the card at all. My guess is something in the 680 image might be breaking the Centro.

The aGPS stuff is probably just a regular modem AT-command. The fact you're getting zeros could mean either your network hasn't enabled it or perhaps you have a firmware version that doesn't support it (I've seen some comments that it requires a firmware update).

ibussatti,

Yep, some of the pin levels win vary all the time as data is transmitted and such. That's normal.

I try but gave me an message operation failed.

by the way it is at&t

hi Alex,
i try on me Centro GSM:
i try 0.5.2, self make from git+your patch from 700p thread, also i try change in mach.c D062 (CDMA Centro ?) to D061 (GSM Centro) - still cocoboot reset, stil i have in info/memory Virt TTB: 0x1ffc000 :(
* cocoboot in all case show model 0 unknown, i manual type 1230.

Centro Black GSM:
CPU:
Machine:D061
CPU ID: 0x69054117
CPU: Intel PXA27x

Memory:
RAM base: 0xa0000000
Size: 32mb (0x1b5c000)
Phys TTB: 0xa1ffc000
Virt TTB: 0x1ffc000

LCD register: reset phone
LCD test: reset phone

Haret:
dump 94000000: 062000E11207113F
dump 94000008: 0705053F04700007

Hi kEdAR,

Ah. If you still got model 0 unknown it means the change did not work. Try this, have two entries:

{ 'D061', 1944, "Palm Centro (GSM)" },
{ 'D062', 1944, "Palm Centro (CDMA)" },

Also make sure to delete Cocoboot off internal storage before putting on the new version, or it'll get stuck with the old version. You could try renaming a menu or something in include/cocoboot.rcp to make sure your changed version is actually running, no the old version.

Also it looks like I missed pushing the Centro patch to get_tt_offset() (also in mach.c). I'll do that shortly but for now add a Centro case to the switch, like this:

switch (mach_table[mach].linux_id) {
case 909: /* Treo 650 */
case 1230: /* Treo 680 */
case 1944: /* Centro */
return 0;

Edit: I made the changes as Cocoboot 0.5.3. Please try and see if it helps. As always, ensure to delete Cocoboot off the device before installing new version.

thx :)
now with 0.5.3:
- show right model 1944 - Centro GSM
- info/memory show right Virt TTB: 0xa1ffc000
- LCD Registers - still reset centro
- LCD test - don't reset from now ! - display shaking, value is not readable, after off/on centro is readable: 0x00000000
- and boot - DON'T reset ! :) - kernel load ok, initrd don't know... centro is freezed on cocoboot screen

btw: before all me test i sure remove cocoboot and settings from ram ;)
i try also after HR..

edit:
- Info/DumpMMU - too don't reset in 0.5.3:
08000000-08000000 -> 08000000-08000000
20000000-21f00000 -> a2000000-a3f00000
64000000-64900000 -> a1500000-a1e00000
66000000-66200000 -> a1200000-a1400000
73100000-74000000 -> a0100000-a1000000
90000000-91800000 -> 40000000-41800000
94000000-94000000 -> 44000000-44000000
98000000-98000000 -> 48000000-48000000
9c000000-9c000000 -> 4c000000-4c000000
a0000000-a0000000 -> 50000000-50000000
a8000000-a8000000 -> 58000000-58000000
f0000000-f0000000 -> 5c000000-5c000000
fef00000-fef00000 -> 00000000-00000000

edit2:
if i disable initrd loading, and try load only kernel - freezed same as with initrd

kEdAR, it freezes with Sleep_Walker's 680 kernel and manually entering 1230 in machine box?

Well there's a few possible causes that immediately come to mind:

* Linux machine ID is becoming corrupt so it's not getting the 1230 and Linux is saying unsupported machine.

* Something in the 680 kernel is hanging things... possibly a GPIO that's wired differently.

* Corruption of zImage during copy (unlikely)

Not very easy to debug though.

Thanks for the memory map, I've started collating the info here:

http://hackndev.com/trac/wiki/CentroHardware?version=1

> Size: 32mb (0x1b5c000)

doh, this detection is still failing. I will have to come up with a better way of doing it. It doesn't hurt though, linux will just see the first 32mb and you can override it if necessary by specifying mem=64m in kernel command-line.

alex, thanks for the cocoboot update and your continued work on this.
cocoboot 0.5.3 recognizes the full 64mb of memory on my CDMA Centro.
LCD registers resets.
LCD test works but screen goes fuzzy afterwards.
MMU dump works now, too:
08000000-08000000 -> 08000000-08000000
20000000-21d00000 -> a2000000-a3d00000
64000000-64900000 -> a1500000-a1e00000
66000000-66200000 -> a1200000-a1400000
73100000-74100000 -> a0000000-a1000000
74200000-74200000 -> a3f00000-a3f00000
90000000-91800000 -> 40000000-41800000
94000000-94000000 -> 44000000-44000000
98000000-98000000 -> 48000000-48000000
9c000000-9c000000 -> 4c000000-4c000000
a0000000-a0000000 -> 50000000-50000000
a8000000-a8000000 -> 58000000-58000000
f0000000-f0000000 -> 5c000000-5c000000
fef00000-fef00000 -> 00000000-00000000

However, the cocoboot.conf file in my SD card root directory doesn't seem to show up in cocoboot, whether I format the SD card with my Centro, with Win-doze, or in Linux.
I even found a driver hack to allow me to partition the SD card in Windoze... the main difference is that Windoze recognizes partitions formed in Linux but not the other way around. Partition the card with gparted, and the Centro gripes about the card not having a correct bootfile(?)and won't write to the card, and parted won't work at all (says unsupported because of uneven cylinder boundary). Partition in Windoze and the Centro sees the card fine and can write to it, but cocoboot still doesn't see the cocoboot.conf file anymore... it hasn't seen it since cocoboot 0.5.2 (I tried to download the 0.5.1 and it recognizes my Centro now... acts like 0.5.2 and 0.5.3 regarding the cocoboot.conf). SleepWalker's zImage still won't see the ext3 partition either, no change in the error message, but I think it might be related to how Cocoboot can't find the cocoboot.conf file anymore. Is there a way to put the root filesystem in the FAT32 partition? SleepWalker's zImage looks at msdos it says.
Sorry I've not been around, my desktop was down for days due to living-room re-arrangment and it's hard to type on the Centro.

Latest Cocoboot Works for me on a Sprint Centro CDMA with Sleep_Walker's 680 kernel and manually entering 1230
LCD registers resets the Centro.
didn't try the LCD Test or the MMU dump

I'm on a Mac so I used diskutil to partition my SD card:
diskutil partitionDisk disk1 MBRFormat "MS-DOS" sd1 50M "MS-DOS" sd2 0b
it finds the cocoboot.conf and the zImage, not using initrd

I have this set in my cocoboot.conf:
cmdline=root=/dev/mmcblk0p2 rootdelay=1

I get this during boot up:
VFS cannot open root device "mmcblk0p2" or unknown-block (0,0)
please append a correct "root=" boot option

Maybe the delay isn't long enough or maybe the zImage isn't seeing the device or is it because both partitions are msdos. I read in here that sleepwalkers zImage looks for an msdos partition? is that right? if mmcblk0p2 is not the right device then what should I be looking for? how could I find out?

> Is there a way to put the root filesystem in the FAT32 partition?

Hmm. This reminds me of one of my old projects. Assuming Sleep_Walker's kernel has FAT32 support, grab initramfs-rootfs-menu.gz and rename it to initrd.gz. Put it on your SD card along with the zImage.

Now, make or find an ext2 rootfs image (ext2 files from other device bootpacks will probably work). If you just have a tarball you can turn it into a filesystem image by doing this. Change count in the dd line to the size you want it to be (so in this example it's 256mb):

dd if=/dev/zero of=example.rootfs.ext2 bs=1048576 count=256
mkfs.ext2 example.rootfs.ext2
mkdir tmp
sudo mount -o loop example.rootfs.ext2 tmp
cd tmp
sudo tar -zpxvf .../example-tarball.tar.gz
cd ..
sudo umount tmp

Pop it in the FAT32 partition along with your zImage and initrd.gz. Run cocoboot, give a blank command-line. Boot. The initrd should attempt to mount all partitions that Linux can detect, it'll then prompt to choose your rootfs from a menu. Normally you can use the d-pad to do this but the key mappings may be wrong on the Centro, since they're for the 680.

I've committed an initial centro machine to our 2.6.27 tree. Here's a zImage if someone would like to test whether it works (it might not, I have no idea). Note that you DON'T need to change the machine number in the top left corner of Cocoboot to "1230" for this image. Please leave it as "1944". (If you get a machine number of 0, upgrade to Cocoboot 0.5.3)

zImage-centro-2.6.27-00066-gb7ff8ec (config)

Rename it to just "zImage" on your SD card.

This definitely has FAT32, ext2 and ext3 support, so if you're having trouble with Sleep_Walker's kernel, try this one. USB ethernet might also work if you connect to your PC and use Cocoboot "USB Console" menu option before booting Linux.

OK!
Alex, your Centro zImage boots! the first time I tried it, I thought it locked up because it sat for a while in the cocoboot screen, but I tried it again on principle... when I was sure it had frozen again, I popped out my Centro's battery (the only way to power off/reset this thing), but as I was doing so, I saw the boot sequence start scrolling. Ran it again with more patience, and it got to the kernel panic (because this card had no partitions), but saw it did recognize mmcblk0 sd device. Gparted my card (fat32,ext3,swap), reformatted the fat32 with my hacked Windoze device so my Centro could write to it, put your debian/lenny fs in the ext3 partition, and got booted all the way to login. A few fatal errors showed up during boot but didn't stop the process... the last one on screen I copied down:
Mounting local filesystems... mount: special device /dev/mmcblk0p1 does not exist failed.
the time showed up right but the date shows 1938 (SleepWalker's kernel got the date right somehow). Was able to login as root, was prompted to change password and got to prompt. Alpha part of keyboard works but no numbers, so I rebooted my Centro and jumped on here to update this post! WOW! So close now! Thanks for your expertise, Alex!

per theorian's post:
I meant that in the boot text, sleep_walker's kernel looks for squashfs, msdos when it can't open root fs, but only if I don't specify root=/dev/mmcblk0p2 rootdelay=1 on the command line. Apparently I am causing some issue myself regarding the cocoboot.conf file not opening... good to know.
edit: Ok, cocoboot.conf is working now... silly me, didn't have a CRLF (ASCII 13 decimal, or press Enter for you young'uns) at the end of the cmdline=... in cocoboot.conf, but still get the kernel panic. also tried unpacking debian rootfs in the FAT partition just to see if it'd work, with no cmdline entry and with root=/dev/mmcblk0p1 and again with root=/dev/ as well. Blah.

mounting root from ext2 image on fat32... Nice instructions, Alex, but it appears SleepWalker's zImage just doesn't "see" any of the partitions on my Centro's SD card. same kernel panic, and it won't load the initrd.gz either, although cocoboot sees it. too bad about that, but since the zImage you provided does boot all the way to the command prompt I am quite pleased with the lovely progress. I'm a little embarrased to not provide more help than being a test mule, but I'm learning! Maybe relatively soon I can compile my own zImage for testing. Thanks again for all your hard work!

-> alex: yes i try sw1, and manual 1230.. but corrupted initrd .. :) ok, i recopy initrd and 0.5.3 show me first kernel panic :) after this i consulted with sleep_walker and try 0.5.3 with your modification .. and initrd is loaded ! i try me old rootfs for t3 and Opie booted :) finaly i try me 27x build (for all palms with 27x supported by hnd 2.6.21 :) too boot fine to Opie :)

-> bigsupersquid: [i]LCD test works but screen goes fuzzy afterwards.[/i] - try power off/on - on me centro-gsm i see 0x00000000

Please try sw1 with sw cocoboot :) http://sleepwalker.hackndev.com/cocoboot.prc
For boot direct from ext2 secondary partition add in cocoboot.conf to cmdline line: "part=mmcblk0p2"
As rootfs you can try anny rootfs in squashfs from http://kedar.palmlinux.cz.
Put *.squashfs to /linux2ram dir on first fat partition (also file modules-k27x-sw1.squashfs put here)
btw:If you put more that one rootfs-*.squashfs file, you must create text file modlist-somename.txt, in this file put name of rootfs*.squashfs that your choice. Some rootfs need kedar_changes.squashfs in /linux2ram and in modlist-somename.txt (one name per line).Look as example to modlist for LinuxExpo image, find on me page 21.4.2007 :) Select modlist is using cmdline parameter "mod", add mod=somename to cocoboot.conf.

bigsupersquid, excellent! :)

The 1938 time thing is due to a difference in Epoch. Palm OS stores the time as the number of seconds that have passed since January 1 1904, while Linux stores it as the number of seconds since January 1 1970.

Our 2.6.21 tree has a hack applied to make Linux interpret it the same way Palm OS, but I haven't applied it in 2.6.27 since I don't think it would be accepted in the upstream kernel (as is anyway). The eventual goal is that you'll just be able to build a regular kernel from kernel.org, so I've been trying to keep the number of patches to a minimum.

Looks like the hwclock --setepoch command may be the "right" way to fix it, I haven't tried it though and the PXA RTC driver may not currently support that option (in which case we will need to patch it).

-> kEdAR: LCD test: yes, power cycle clears fuzzies from screen, also a boot thru cocoboot fixes screen issues as well. I forgot to mention that cocoboot 0.5.3 does give an output from LCD test as well as the fuzzies, same 0x00000000 as you get.

tried squashfs, messed up a few times, sw1 kernel does recognize the squashfs with sw cocoboot machine i.d. 1230 (0.5.3 still doesn't see filesystem even with initrd whether i.d. 1230 or 1944, but sw cocoboot does) but I haven't got all the files right yet... edited out my stupids, want to try more after working on the car :)
edit: get partway thru boot, but get "can't parse modules.dep" errors and says "system halted."
tried opiemini and gpe squashfs rootfs, but both act the same.

-> Alex: after more testing, I have found the following issues in the Centro kernel:
during the boot sequence, I see the follwing errors.

PXA CPU 27x max frequency not defined (pxa27x_maxfreq) assuming pxa271 with 416000kHz frequency

Driver 'SD' needs updating - please use bus_type methods

mmc0: host does not support reading read-only switch, asuming write-enable.

ETX3-fs: INFO: recovery required on readonly filesystem.

modprobe: FATAL: Could not load /lib/modules/2.6.27-00066-gb7ff8ec/modules.dep: No such file or directory
->(I opened the filesystem from my desktop computer and /lib/modules/ is empty.)

Setting the system clock.
Cannot access the Hardware Clock via any known method.
Use the --debug option to see the details of our search for an access method.
Unable to set system clock to: Wed Oct 5 00:24:49 UTC 1938 (warning).
->(comes up twice.)

Loading kernel modules...FATAL: Could not load /lib/modules/2.6.27-00066-gb7ff8ec/modules.dep: No such file or directory

Setting kernel variables (/etc/sysctl.conf)...Unknown H2 value! (88) Assume 100.
done.
Mounting local filesystems...mount: special device /dev/mmcblk0p1 does not exist
failed.

after login, typing dir shows nothing.
typing time gives me
real 0m0.000s
user 0m0.000s
sys 0m0.000s

If I let it run with or without login for about 5 minutes or so, the screen goes solid grey until any key pressed, then screen goes vertical colored lines.

Per my post to kEdAR, sw1 kernel boots with squashfs with sw cocoboot machine id 1230, but cocoboot 0.5.3 does not with the same filesystem configuration and machine id, just gets to the kernel panic. also, sw1 zImage sees the time/date correctly.

Thanks again!

Treo 755p

I thought I'd add in my Sprint (CDMA) Treo 755p to the mix. My results are below the > commands. Device currently comes up as 0/Unknown device. Used cocoboot 0.5.3. The LCD/MMU menu options also seem to reboot my treo. Will probably try to boot a kernel later today or tomorrow, if I have time. Please let me know if you need any more info.

-puk

Machine: D060
CPU ID: 0x69054117
CPU: Intel PXA27x

Memory:
RAM base: 0xa0000000
Size: 32mb (0x1b000000)
Phys TTB: 0xa1ffc000
Virt TTB: 0x1ffc000

> dump 94000000
062000E1130F0D3F
> dump 94000008
0705053F04700007

Pin-level and directions:
> dump 90e00000: 148d01fefc025cc4
60150FEFFC02DC12
> dump 90e00008: 88cd6fffcf7b1400
8B416F00CFBB1C00
> dump 90e00010: ffff2bc3d3ffffff
FFFFAB8FF2FFFFFF

Alternate functions:
> dump 90e00054: 0c000000a5000012
0C800000A5000012
> dump 90e0005c: 69988050aaa00008
6990000AAAA00008
> dump 90e00064: 02aaaaaa44440000
22AAAAAA41440002
> dump 90e0006c: 02aa95ff00001400
56AA95FF00000001

Extended GPIO level and directions:
> dump 90e00100: 01e81f8100000000
018C1F8100000000
> dump 90e0010c: 006dff8100000000
01F5FF8100000000

Hello everybody ! Happy to see guys working on Centro !

I have a little problem when installing the debian on my palm... i've done all things :
-> 3 partitions : FAT32, EXT2 and SWAP)
-> Extracted debian-lenny-armel-20081004.rootfs.tar.bz2 to ext2 partition with tar -jxvpf
-> Got a damn useless busybox !
BUT :
-> only initrd.k27x-sw1.gz and zImage-k27x-sw1 works for me (i've tried many initrd and zImage) and
-> ONLY WITH 1230 Machine Number ! The other (1944 ???) freeze cocoboot (Loading initrd.gz ...OK / Loading ZImage...OK, then freeze (waited 1 hour !!!))

And only a simple question : hoy to have a azerty keymap ?

Thanks, fladnaG

PS: Sorry for my very bad english, i'm French and i don't learn my english lessons ;)

EDIT : OK, Linux boots now... but always the same problem with the azerty kbd....

Alex,

I'm using your kernel with Armedslack in my Centro and it works fine. But it will be great if you recompile this kernel with nfs support. Can you do this, please?

Thanks!
Oda

Owners of Palm Treo 680 and Palm Centro 685 (GSM), please test this kernel.

http://sleepwalker.hackndev.com/release/GSM/7/

Hi,

I have a Centro GSM (1944), here's are the results of the test:

1. I've renamed zImage-GSM-sw7 to zImage overwriting the existing one
2. I've decompressed modules.GSM.sw7.tar.bz2 in the root of the linux partition (that added the 2.6.31-rc4-GSM-sw7 under /lib/modules)
3. Tried to Boot cocoboot 0.5.3
4. Loading /zImage... 1576520 b OK (the command line value is: root=/dev/mmcblk0p2 rootdelay=1)
5. After loading the zImage the Centro freezes. I waited more than 10 minutes... Nothing, had to remove the battery.

Maybe I did something wrong?

And which files EXACTLY u copied on your memory card?

No, the approach looks fine.
1] Have you tried it more times?
2] could you retest it with your Centro without running applications like hacks, pTunes, skins and font changing stuff and other applications running on background?
3] is GSM on or off?

If you know, what files are needed, you probably know where to place it. If you don't try to use install_script.sh from Downloads section or read it a bit.

Generally you need:

on your FAT partition of card:

/zImage - main linux kernel
/cocoboot.conf - configuration of bootloader (mainly for setting kernel, initrd (if used), kernel commandline parameters etc)
/initrd.gz - if you want to use it

you also need root filesystem - you can have it on another partition of card, on NFS (if you can), on loopback (ext2 or squashfs with some unionfs to keep changes)

there is also good idea for some swap space...

My kernel builds contains kernel itself, modules which you have to put to your root filesystem somehow, kernel configuration (to be able to build your kernel).

I hope this gives you the answer...

Could you please create wiki page containing this and fix my broken English? Thanks!