iPaq Linux Install Problem

From: Glenn Neufeld <neuf_at_netcom.com>
Date: Wed, 06 Sep 2000 09:43:09 -0700

Hello all...

        While installing Linux on my iPaq, I ran into some problems. The bad news
is that I can't seem to get the bootldr that I installed (2.9.0 from the
v0.13 dist) to write to flash.

        Playing with it (and reading the bootldr code) gives me the feeling that
the bootldr is either identifying my Flash incorrectly, or this particular
unit has a Flash chip in it that is new and/or different in some way.

        The first error I get is similar to the incorrect size error that I have
seen on the list. Here's a fragment of a session in HyperTerm where I try
to download the v0.12 kernel (zImage-2.4.0-test5-rmk2-np1-hh3). The
download apparently works flawlessly, but Flash programming does not take
place:

-----------------------------------------
boot> load kernel
ready for xmodem download..
Download Successful
00077100 bytes loaded to C0000000
img_size is too large for region: E59F0624
done.
boot>
-----------------------------------------

        Could this be a simple download error or cable problem? I would think
that even the slightest random modification to the code would render it
unusable....

        Curious, I found the flash_type command in the bootldr sources, as well as
the amd and intel sector and region descriptions. So I tried this:

-----------------------------------------
boot> flash_type
Flash types supported:
   28F128J3A
Current flash type is DABT
00000A18
EA00008B
-----------------------------------------

        Note that here, the 'boot>' prompt never re-appears, and hard resetting
the unit is the only way to get it back.

        So, the questions would be:

        1) Is DABT a Flash type at all?
        2) Can the bootldr be modified to recognize this (assuming the information
is available and it's a valid, new flash type).
        3) Is there a series of steps using bootldr commands that will allow me to
replace the bootldr when and if an appropriate one can be cons'ed. e.g.
setting override and/or other params, and then loading another bootldr?
        4) Is my assumption correct in that the Flash is not getting programmed
because the bootldr has no way to erase it first?

        This last point (4) comes from my reckless attempt to re-load the bootldr
using another cable. It's not a happy tune, but it goes something like this:

-----------------------------------------
boot> load bootldr
loading flash region bootldr
using xmodem
ready for xmodem download..
Download Successful
0000E180 bytes loaded to C0000400

programming flash...erasing ...
No flash descriptor: erase flash range
erase error!
boot>

-----------------------------------------

        No flash descriptor, indeed! Actually, I feel lucky that this failed - it
probably would have taken my iPaq over the edge into paperweight-ville.

        This situation is actually not too bad - although I can't go forward to
Linux, or backward to WinCE, the potential for getting one or the other to
load is still there!

        Here's a suggestion that might help the debugging process - please feel
free to tell me it's not well thought out, because it's not: Perhaps if
everyone with the capability ran the flash_type routine, and then supplied
it to you with the unit's serial number/manufacture date, it might point
out just exactly where in production this as-yet-unidentified change took
place, so that users could check and see that they have the right
bootldr/kernel versions, or discover pre-install that the code for their
machine is not yet ready. Then there'd be a few less install failures,
assuming that everyone has more patience than me (a good assumption!).

        Of course, you may already have that information from the factory...

        So, despite my best efforts, I haven't been able locked up the iPaq
yet. I'll be checking the list for new developments: you guys are pretty
amazing, turning out all this code at warp speed! Keep it up, and I'll let
you know when I finally kill the thing completely. :)P

-Glenn

neuf_at_netcom.com
Received on Wed Sep 06 2000 - 09:40:16 EDT

This archive was generated by hypermail 2.2.0 : Mon Jul 25 2005 - 17:20:41 EDT