Loading Images FAQ

Bootloader
TFTP
JTag
Miscellaneous

From Bootloader

I cannot get the release 7.1 bootldr to install on the stargate. When I try and upload, I get the following message:

    boot> load bootldr
     0x00040000 0x00000000loading flash region bootldr
    using xmodem
    C0002EE80 bytes loaded to A0000400
    Not loading bootldr into flash
    Downloaded image does not have ARCHITECTURE_MAGIC=01050059
    Instead found=0104000E

You have to load it through JTAG the first time according to the README file because magic numbers don't match. Do to some complications, we can not use "load bootldr" to upgrade the bootldr. Basically, the old bootldr thought it was a SA-1110, so it won't let us upgrade to the PXA.

 

There is another way which is a bit more complicated but easier in some ways.

  1. in the bootldr, unprotect the bootldr flash blocks (something like pflash 0x0000 0x40000 0)
  2. boot linux
  3. copy the bootldr.bin image to linux somwhere
  4. cat < bootldr.bin > /dev/mtdblock/0
  5. reboot
  6. (maybe re-enable protection on the flash: pflash 0x0000 0x40000 1)

Just be careful -- if you screw this up, then you *will* need to go find a jtag. However, then you're just back to where you were before :-).

TFTP

I am trying to load a root partition via TFTP and getting retries as shown below. Does this mean it's getting timeouts (e.g. tftp server not responding)? Or some sort of NACK or other hard error (e.g. failed check, permission denied, etc)?

    boot> load root
    partition root is a jffs2 partition: 
     expecting .jffs2 or wince_image.gz.
     After receiving file, will automatically uncompress .gz images
    loading flash region root
    using tftp
    IP: 131.179.144.51 netmask: 255.255.255.0 gateway: 131.179.144.1
    Boot server: 131.179.144.22
    TFTP loading 'stargate/root.jffs2' to a0000400
    eth addr: 00:b0:d0:71:26:34
    TFTP from server 131.179.144.22
    Filename 'stargate/root.jffs2'.
    Load address: 0xa0000400
    Loading: T T T T T T T T T 
    Retry count exceeded; starting again
    eth addr: 00:b0:d0:71:26:34
    TFTP from server 131.179.144.22
    Filename 'stargate/root.jffs2'.
    Load address: 0xa0000400
    Loading: T T T T T T T T T 
    Retry count exceeded; starting again
    ...

The "T"s are timeouts. I got these continuously when my license to WinAgents expired. I also got them intermittently when I used the TFTP server in Santa Clara while I was in Hillsboro.

JTAG

For those that use the JTAG cable (MEMEC Model IJC-2), you may have issues getting access to the parallel port if the parallel port mode in the BIOS is set to 'Bi-Directional'.

To fix this, set the parallel port mode to 'ECP' in the machine BIOS.

I can't seem to find the JTAG cable IJC-2 mentioned in the JTAG programming guide at either www.memecdesign.com or www.insight-electronics.com.

I didn't make any head way on their web site in mid 2003 so I called them at 888 488 4133. I asked for a JTAG Cable (IJC-2). The associated part numbers on my packing invoice are:

You need both pieces. It were $60 plus $15 shipping in 2003.

 

Using JFlash_mm from Intel and the JTAG connector, I have so far been unable to successfully transfer the full ~190K bootldr that comes with release 7.0. Using three different stargates (Rev. 1.1 and Rev. 1.1 w/ the green wire fix) and a total of approx. 10 attempts, it seems to never get the whole thing over successfully and fails at random places. I can transfer the much smaller bootldr that comes with Release 5 probably 80% of the time (it's about 100K). I've tried the following things:

  1. Erasing the entire flash using option E before installing, as suggested by the JFlash_mm guide.
  2.  I've verified the flash using option V.
  3. I've edited the .dat file to use WORD mode instead of BUFFER mode.
  4. Using "split" to reduce the size of the bootldr and transferred it in pieces. The problem is that JFlash_mm erases the entire block of memory (about 262K) at the start of each invocation, this doesn't work.

Questions:

  1. Is there a way to tell JFlash_mm not to erase the memory block before writing, other than modifying the source code?
  2. Someone suggested to me that these transfer errors are due to a timing issue and that I might have better luck if I can adjust the transfer rate. Does this sound like a good idea? I don't know how to tell JFlash_mm to adjust its transfer rate.
  3. Am I the only one seeing these horrible error rates?
  4. Is there a version of JFlash-Linux that works with the stargates?

I've seen the verify problem when loading larger images via JFlash. The JFlash verify process that immediately follows the write process will show errors. However, if you rerun JFlash with the verify-only option, everything checks out OK. My guess is that the flash does not get put back into normal read mode before the first verify and JFlash shows fictitious errors...

I loaded a new bootldr onto my Stargate. It will not come up to the prompt correctly. So I tried to flash a good one in with JTAG. But I can't get it to load. Has anyone ever seen the following error and have worked around it.

 
    C:\Program Files\Intel Corporation\JFlash_MM>jflashmm 
    dbpxa250_C bootldr

    JFLASH Version 5.01.006
    COPYRIGHT (C) 2000 - 2003 Intel Corporation

    PLATFORM SELECTION:
     Processor=             DBPXA250
     Development System=    Lubbock
     Data Version=          1.0

    DBPXA250 revision ??
    Found flash type: 28F128J3A

    Erasing block at address 0
    Error, Block erase timed out

    C:\Program Files\Intel Corporation\JFlash_MM>

Yes, I have seen this one. Something went wrong in programming the bootloader and the JTAG pod that we use couldn't get control of the board to program it over.

I had to use a better JTAG probe (one from Corelis) to recover from this. For example: PCI-1149.1/Turbo
http://www.corelis.com/products/JTAG_Controllers.htm

Miscellaneous

How do I protect flash partitions?

To protect the flash, you can type something like:

pflash 0 0x140000 1

Which will protect the bootldr, params, and kernel -- which should make them read-only at a hardware level, I think.

So undo it, simply use a "0" instead of a "1" in the last column

My attempt to load the bootldr from the kernel isn't working. Can you tell be what I am doing wrong? See below.

    stargate:~# cd /tmp
    stargate:/tmp#scp root@clyde:/stargate/bootldr .
    root@clyde.jf.intel.com's password:
    bootldr 100% |*****************************| 188 KB 00:01
    stargate:/tmp# cat bootldr > /dev/mtdblock/0
    cat: write error: Operation not permitted

The bootldr FLASH sectors are probably protected -- but, you can't unprotect them through linux, so you're kinda not in a good place. Basically, you either need a working bootldr command prompt, or a working JTAG… :-(