RE: iPaq Linux Install Problem

Glenn,

During the install, we use two copies of the bootldr: one linked to run from
DRAM, one linked to run from flash. The osloader contains an image of the
first, which it loads into DRAM and jumps to. The osloader that you were
using contained a copy of the 2.8.4 bootldr that does not recognize your
flash chips. It doesn't matter that what you downloaded to it was the new
one, because that doesn't run until you reset the unit after you write the
bootldr to flash.

We understand how to fix that problem -- we had a version of the osloader in
v0.13 that recognized the other flash chips, but we removed it today because
several units have failed to boot after full or partial installs of v0.13.
We have not figured out what the problem is yet, so I guess we're declaring
a moratorium on new installs until we can prevent whatever the problem is.
I'm hoping we can have a new release ready by the end of the week.

-Jamey

> -----Original Message-----
> From: Glenn Neufeld [mailto:neuf_at_netcom.com]
> Sent: Wednesday, September 06, 2000 12:43 PM
> To: handhelds_at_handhelds.org
> Subject: [Handhelds] iPaq Linux Install Problem
>
>
> 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
>
> _______________________________________________
> Handhelds mailing list
> Handhelds_at_handhelds.org
> http://handhelds.org/mailman/listinfo/handhelds
>
Received on Wed Sep 06 2000 - 10:10:06 EDT