[ECOS] Hosed ipaq

[Gary Thomas]

On 15-Jun-2001 Nick Clarey wrote:
> Howdy,
> 
> <snip>
> 
>>    I wish I could say this louder, write it bigger, make it stronger, etc.
>> 
>>    We want you to use (or at least test) RedBoot on the iPAQ, but the 
>>    instructions have to be followed.  Anything less is simply asking for
>>    trouble.
> 
> Yeah, fine. My iPAQ didn't have WinCE on it to start with, and your 
> instructions took that as the starting point. So I tried something a 
> little different. Obviously, said attempt met with failure.

Sorry to have been so harsh, but we have to get this message across.

> 
> Could you tell me (please) what I've done wrong? Other than, obviously, 
> not following your instructions :->

You must have been working from a very old RedBoot, possibly not even one
released by us.  I do recall that there were differences in the memory map
from what was originally contributed by 3GLab and the final product.

In particular:
  4) Created a current RedBoot ROM image, flashed it into ROM at 0x50200000 
  (virtual) as a test, checked the first couple of bytes, looked like it had 
  worked ok.

  5) Flashed image from (4) into ROM at 0x50100000 (virtual), because the 
  old RedBoot image had swapped 0x50000000 and 0x50100000 (virtual) around 
  (so said physaddr). Physaddr reports that 0x50100000 virtual == 0x00000000 
  physical, so that ought to mean that I now have the RedBoot ROM image 
  living at 0x0 physical.

This is certainly no longer the case:
  RedBoot> phys 0x50000000
  Virtual addr 0x50000000 = physical addr 0x00000000
  RedBoot> phys 0x50100000
  Virtual addr 0x50100000 = physical addr 0x00100000
  RedBoot> phys 0x00000000
  Virtual addr 0x00000000 = physical addr 0xc0000000

So, here's my conjecture.  If you built RedBoot/ROM straight from the current
setup, it is designed to run at 0x50040000 (eCos programs are not position
independent).  You ended up putting this image into the Flash at 0x00000000
(physical addr), which is the boot sector.  This simply won't work.

Frankly, I'm not sure why it did anything at all at this point.

Quite possibly trying to load code at 0xc0000000 via GDB caused some additional
failure.  In particular, since GDB runs within the mapped eCos environment,
loading to that address would be particularly dangerous.  The eCos MMU tables
are stored at 0xc0004000.  As soon as GDB started writing to them, the roof
would have caved in.  Quite possibly some following event actually scribbled
over the boot flash code.

One of the things in the new instructions is to write protect the boot flash
code.  It is frightenly easy to write to the flash memory on the iPAQ and
the possibility of writing over the boot code is all too real.