Ah... I see the problem. Any time I download files from old.hackndev.com, I get an Access Denied page instead of the actual tar.bz2.

Try this version:

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

You'll need stdiolib.prc as well:

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

Alex, thanks for responding.

How exactly do I install StdioLib? I've tried various combinations of placing the .prc's in palm/launcher on my SD card, but none of them are visible when the card's inserted.

HARET/P shows a blank screen, then exits. I'm assuming this is due to a failure to find StdioLib.

Never mind... I copied it using FileZ, and HARET starts up ok.

In case anyone's interested, here are the register values... I'm assuming LCCR4/5 aren't relevant, since the instructions don't suggest dumping them?

Register: LCCR0 : value 062000e1
reserved (27-31) 0 00000000
lddalt (26-26) 1 00000001
ouc (25-25) 1 00000001
cmdim (24-24) 0 00000000
rdstm (23-23) 0 00000000
lcdt (22-22) 0 00000000
oum (21-21) 1 00000001
bsm0 (20-20) 0 00000000
pdd (12-19) 0 00000000
qdm (11-11) 0 00000000
dis (10-10) 0 00000000
dpd ( 9- 9) 0 00000000
reserved ( 8- 8) 0 00000000
pas ( 7- 7) 1 00000001
eofm0 ( 6- 6) 1 00000001
ium ( 5- 5) 1 00000001
sofm0 ( 4- 4) 0 00000000
ldm ( 3- 3) 0 00000000
sds ( 2- 2) 0 00000000
cms ( 1- 1) 0 00000000
enb ( 0- 0) 1 00000001

Register: LCCR1 : value 13070d3f
blw (24-31) 19 00000013
elw (16-23) 7 00000007
hsw (10-15) 3 00000003
ppl ( 0- 9) 319 0000013f

Register: LCCR2 : value 0768013f
bfw (24-31) 7 00000007
efw (16-23) 104 00000068
vsw (10-15) 0 00000000
lpp ( 0- 9) 319 0000013f

Register: LCCR3 : value 04300005
pdfor (30-31) 0 00000000
bpp3 (29-29) 0 00000000
reserved (28-28) 0 00000000
dpc (27-27) 0 00000000
bpp (24-26) 4 00000004
oep (23-23) 0 00000000
pcp (22-22) 0 00000000
hsp (21-21) 1 00000001
vsp (20-20) 1 00000001
api (16-19) 0 00000000
acb ( 8-15) 0 00000000
pcd ( 0- 7) 5 00000005

I'm grovelling through the pxafb.c code right now to try and figure out how to convert these to display mode values. Any help is hugely appreciated.

Cheers!

Just for the fun of it, I tried building a Treo 680 kernel from the linux-hnd tree to see if it would work on my 700p. (I'm not sure if I'm doing any of this correctly - just playing around at this point).

I'm actually using the Android SDK cross-tools (in the prebuilt/linux-x86/toolchain/arm-eabi-4.2.1) folder. I started with the default palmt680 config, and disabled loadable module support so I don't need a ramdisk. I also disabled sound and networking, in case the kernel size is too large. At this point I'd just like to see some boot messages.

Unfortunately cocoboot seems to load the resulting zImage, and then the phone insta-reboots :(

Maybe I'm doing it all wrong, or maybe the 680 isn't close enough to a 700.

I've just made a 0.5.1 release of Cocoboot that (seems to) fix some reset problems on the 680, maybe it'll help on 700p too:

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

If you install off an SD card, make sure to delete it off the phone's internal memory first, or it'll silently run the old version.

Note to try a 680 kernel image, you'll have to ask Cocoboot to supply the 680's machine number so Linux thinks it's running on the 680. Change the number in the top left corner to "1230".

> I'm grovelling through the pxafb.c code right now to try and figure out how to convert these to display mode values.

static struct pxafb_mode_info treo700p_lcd_modes[] = {
{
.pixclock = 115384, // pcd = 5
.xres = 320, // ppl = 319 (+1)
.yres = 320, // lpp = 319 (+1)
.bpp = 16,
.hsync_len = 4, // hsw = 3 (+1)
.vsync_len = 1, // vsw = 0 (+1)

.left_margin = 20, // blw = 19 (+1)
.right_margin = 8, // elw = 7 (+1)
.upper_margin = 8, // bfw = 7 (+1)
.lower_margin = 105, // efw = 104 (+1)
},
};

static struct pxafb_mach_info treo700p_lcd_screen = {
.modes = treo700p_lcd_modes,
.num_modes = ARRAY_SIZE(treo700p_lcd_modes),
.lcd_conn = LCD_COLOR_TFT_16BPP | // active display (pas=1)
LCD_PCLK_EDGE_FALL,
};

Alex, thanks for your help on this. Unfortunately, the behaviour is exactly as it was before - instant reboot.

I tried a few things - in particular, putting an infinite loop in head.S, in the hopes that it would hang rather than reboot (I'm assuming interrupts are disabled?) - at least that way I'd know for sure that the kernel code is being executed.

Sadly, it still seems to reboot immediately, no matter what I do. Not sure what to try next. I'm happy to provide any register/mem dumps, but I appreciate that you may not have a lot of time to spend on this. Thanks again for your help so far.

Yes, interrupts are disabled. Hmmm. Okay, the fact you put a loop in a head.S and it still reset means it's dying in Cocoboot, normally a crash of some sort in the kernel will result in a hang anyway.

Firstly, you're not using an initrd right? Sleep_Walker finds it to be really unstable on 680, while I don't and about the only difference is he is using an initrd and I'm not.

Okay, about the only thing I can suggest trying is to move an infinite loop through the Cocoboot boot code to try and pinpoint exactly where the reset is occurring. I assume you don't have the Palm OS SDK setup (it's a bit of a pain to setup, as prc-tools and such aren't maintained anymore), so I've built a bunch of binaries with loops in different places. The associated patch shows where the loop is.

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

I suggest first starting at Cocoboot-10.prc to make sure the loop is working, it has the loop at the very start of the boot process. Then to minimize the number of tests you have to do, do a binary search to find the spot where it starts resetting. To do this try Cocoboot-5.prc. If it resets try halfways between that and the smallest number you've seen that hangs (Cocoboot-10) so 7. If it instead hangs try halfway between that and the largest number you've seen that resets (assumming Cocoboot-1.prc) so 3. Repeat until you find the boundary.

As always, remember to delete cocoboot out of internal storage before trying a new version, if your using an SD card to run them, otherwise it'll run the old version out of the internal storage.

Hey Alex,

Correct - I'm not using an initrd.

I actually just started trying to get the Palm SDK up and running so I can build cocoboot. I'm following these instructions, but I'm on debian, not gentoo - so it may take me a while to get stuff working. In the meantime I'll try your debug cocoboot versions and post back momentarily.

Cheers,
Ben

Ok... unfortunately, it looks like the crash is fairly early on, since cocoboot-10 hangs, but cocoboot-9 resets the device.

Incidentally, does changing the machine id in cocoboot make any different to cocoboot, or is it just a parameter that's passed to the kernel?

Edit: looking at your patches, it's crashing in virt_to_phys() ?

Ah! virt_to_phys -- I know what's wrong now!

Phys TTB: 0xa1ffc000
Virt TTB: 0x1ffc000

Ah ha!

That should be:

Phys TTB: 0xa1ffc000
Virt TTB: 0xa1ffc000

Try this:

http://releases.hackndev.com/tools/cocoboot/cocoboot-0.5.2.prc

Check the CPU option under info and make sure it now says "Virt TTB: 0xa1ffc000".

The machine id that you can edit is just passed to the kernel. Internally it also uses it to determine the translation table base address (as the treos are different to the PDA palms here and I can't think of way to autodetect it), but it calculates that before display the dialog, so you don't have a chance to edit it.

The 0.5.2 Cocoboot is 0.5.1 with this patch:

diff --git a/m68k/mach.c b/m68k/mach.c
index d192fae..5764ed2 100644
--- a/m68k/mach.c
+++ b/m68k/mach.c
@@ -96,6 +96,8 @@ UInt32 get_tt_offset()
switch (mach_table[mach].linux_id) {
case 909: /* Treo 650 */
case 1230: /* Treo 680 */
+ case 1421: /* Treo 700p */
+ case 1944: /* Centro */
return 0;
default:
return get_ram_base();

Sorry about that, must have missed it when we added the 700p and Centro machines to Cocoboot.

Hey Alex,

Looks like that did the trick - it's definitely getting into the kernel now. Still reboots immediately, but I can at least throw an infinite loop in the kernel and get it to hang. Now I just need to begin the long debugging process.

I got pretty close to getting the Palm SDK + tools installed, but good lord, they don't make it easy :)

Thanks!

Cheers,
Ben

Hey Alex,

Slow progress, I'm afraid. (My ARM/Kernel knowledge is pretty limited)

In any case, I spent some time trying to figure out why it wasn't getting into start_kernel() - seems it was crashing in arm/kernel/head.S (took me a while to find the block that's commented out for the 650).

It's now getting into start_kernel(), but shortly after, everything goes black. I can't tell if it's powered off, or just turned off all the backlights. I'm continuing to insert infinite loops to see if I can pinpoint where stuff is happening.

The LCD_COLOR_TFT_16BPP and LCD_PCLK_EDGE_FALL constants aren't defined in the code I have - which I got from git://git.hackndev.com/linux-hnd. Am I fetching the kernel from the wrong place?

A little more info... it's now getting into do_initcalls (init/main.c). Tracking these calls down is going to be harder, because I still don't have any real way of debugging. I suppose it was a bit naive of me to expect that the hardware would be sufficiently similar to actually see things on the screen :(

Do you have a good technique for figuring out GPIO assignments?

Edit: Aaah... found the "!machine_is_xscale_treo650()" in pxafb.c - ... now I'm getting a brief flash (about half a screen) of text before the LCD goes blank. Progress!

Edit: Ok... I feel pretty dumb now - I added code to flash the screen, so I could count how many initcalls it got through. Turns out it was hanging in customize_machine() ... which calls the pxa/palmt700-specific machine init code. I tracked the crash down to:

SET_PALMT700_GPIO(GREEN_LED,0);
SET_PALMT700_GPIO(KEYB_BL,0);
SET_PALMT700_GPIO(VIBRA,0);

All I had to do is comment these out, and I get all the way to a login prompt :)

Excellent. Yes, sorry I should have mentioned about the pxafb.c thing, that's actually a kernel bug in pxafb when using a non-passive LCD that's been fixed in Linux 2.6.27.

An explantion about the different kernel versions: we've got two kernel tress in the git repository, "linux-hnd" and "linux-2.6". "linux-hnd" is our old tree that we've always worked on (and was previously hosted on sourceforge SVN), it's based on the handhelds.org kernel tree which in turn is based on 2.6.21 and has lots of patches for extra handheld stuff. Recently some of us have been trying to rebase our work on the standard 2.6.27 kernel tree, since most of the important patches have been incorporated and our linux-hnd branch is starting to get pretty out of date. Also we'd like to eventually push on changes into the upstream kernel so we get the benefit of not having to maintain everything ourselves.

Sleep_Walker has been working with linux-hnd since it had more complete support for the 650 and we had some trouble getting 2.6.27 to work on the 680 immediately. I've since managed to sort out those problems and have it working fine now. So there's basic 680 support in linux-2.6 as well now, but I haven't had a chance to port all of Sleep_Walker's work yet.

Edit: I originally had some notes on GPIO hunting in this post. I've fleshed them out into a more detailed guide in the wiki.

I suggest creating a page on our wiki similar to the 680 hardware one so you can take notes of your findings. There's a tool mentioned in my tracing guide that can help generate an initial GPIO table for the wiki. You can attach your gpiotrace logs to it as well. Please let me know if you have any trouble signing into and editing the wiki, it should be synced with the forum accounts but I haven't tested it thoroughly.

If you'd like to start committing your kernel changes back to the git respository, please email me (ato at meshy dot org) an SSH public key and I'll set you up with commit access to the git repository.

Alex,

Awesome, thanks for typing up the GPIO guide. I've been a bit tied up over the last couple of days, but I'll give it a shot some time this week. Once I get some GPIOs figured out, I'll drop you a line about commit access.

Cheers,
Ben

Hey Alex,

Sorry - have been busy for the past week. I've finally had a chance to get back to the 700p. I'm trying to get networking working first - since it seems like that'll make development go a whole lot faster. I have a kernel with network support booting just fine on the treo (not sure what changed, because this wasn't working a week or so ago!), but I can't get my Linux PC to set up the necessary usb0 interface.

I'm running debian etch - do you happen to know what modules I need in order to see usb0?

Cheers,
Ben

Hmmm... scratch that - seems to be working. Not sure what I did!

Should I be using GPIOED or GPIOEDNG?

Edit: Something is very flaky. Every so often, after making a trivial change to the kernel, it'll stop booting at all. I'll try to debug the problem, and it'll start working again - I'll remove my debug code, and it'll continue to work. Very odd.

Aha... ok. Think I solved the previous flakiness - it was actually in the copying of the zImage to the SD-card. I mount the card with "-o sync", and everything seems a lot more reliable.

Now I have a reliably-booting kernel with USB networking enabled. I ssh'd in, installed gcc, ruby, and bunch of other goodies.

I got gpio-dir/val working, and wrote a few scripts to toggle output pins.

The 700p seems to be much closer in GPIO assignment to the 650 than the 680. Serves me right for making the dumb assumption that these numbers represented some kind of meaningful sequence.

Edit: Ok. Now I feel really stupid. Targetting a 650 seems to generate a kernel that boots just fine on a 700p (just have to enter 909 in Cocoboot). I think I had tried this before, and it didn't work (must have been doing something else wrong). From that point on, I just based everything off the 680p code. It might have been better to stick with the 650 as a base.

Edit edit: In case you're interested, building from the linux-2.6 tree works just as well!

Interesting. Well that makes sense, the 700p has a device id of "D052" while 680 is "D053", so it was actually designed before the 680. It also looks a lot more like the 650 from the photos in Palm's disassembly instructions (separate modem board). I wonder, you might be able to make a GSM version of the 700 by using the modem board from a GSM 650. ;-)

Edit: ignore.

I followed Michael Sheldon's article on Treo 650 and it worked fine in my Palm Treo 700p. So the 700p might be really an improved version of the 650 version, but not 680.

I have installed the files he posted in his blog end entered the number 909 (Treo 650's ID). It took a minute to load. Now I can use a lot of applications bundled with the Angstron-Opie distribution.

But some things didn't work (or I could configure):
Bluetooth;
Phisical Keybord;
System Clock;
etc.

Although this, I'm really happy after spending some nights trying to find a proper version for 700p (that doesn't exist at this moment).

That's why I love the Open Source Initiative! There's always some one working to find solutions to tecnological needs. I'm not experienced in hacking for mobile divices or PDAs, but I'm very optimistic about it.

Congratulations to you all from Hack'n Dev!

The 700p seems to have the same keyboard layout as the 680p - but the GPIOs seem to correspond to the 650p.