How to copy OS image from flash to RAM on Sandpoint MPC8245?

Dear All,

I try to install QNX on Sandpoint with MPC8245 processor running DINK 12.3
QNX runs fine when it’s compiled for RAM unfortunately hangs when it’s programmed into local
PMC flash (from address 0xff000000 or whatever) and started from there.
I suspect that may be QNX doesn’t initialize Sandpoint completely when it runs on “bare” platform
without running DINK first.

One of the obvious workarounds is to copy OS image into RAM by “mv ff000000 ff100000 100000”
and then “go 1f1c48” to avoid wasting 6 min. every time when I need to download OS image thru RS-232
port.
Unfortunately mv treats Flash memory space as 64-bit and incorrectly copies data to RAM.

Is there any way to tell DINK to treat Flash memory space as 8-bit?


Regards,
Alex


Alex Ivchenko, Ph.D.
United Electronic Industries, Inc.
“The High-Performance Alternative ™”

611 Neponset Street
Canton, MA 02021
Tel:(781)821-2890 x222 Fax:(781)821-2891
http://www.ueidaq.com

Alex Ivchenko <aivchenko@ueidaq.com> wrote:
: Dear All,

: I try to install QNX on Sandpoint with MPC8245 processor running DINK 12.3
: QNX runs fine when it’s compiled for RAM unfortunately hangs when it’s programmed into local
: PMC flash (from address 0xff000000 or whatever) and started from there.
: I suspect that may be QNX doesn’t initialize Sandpoint completely when it runs on “bare” platform
: without running DINK first.


Alex,

I sent you a lengthy e-mail yesterday concerning this issue; did you not get
it? Did you get an updated QNX IPL at the same time as the new
startup-sandpoint? If not, the IPL you have knows nothing about the
8245 and may not be correctly initializing it.

\

John

Alex Ivchenko <aivchenko@ueidaq.com> wrote:
: Dear All,

: I try to install QNX on Sandpoint with MPC8245 processor running DINK 12.3
: QNX runs fine when it’s compiled for RAM unfortunately hangs when it’s programmed into local
: PMC flash (from address 0xff000000 or whatever) and started from there.
: I suspect that may be QNX doesn’t initialize Sandpoint completely when it runs on “bare” platform
: without running DINK first.

: One of the obvious workarounds is to copy OS image into RAM by “mv ff000000 ff100000 100000”
: and then “go 1f1c48” to avoid wasting 6 min. every time when I need to download OS image thru RS-232
: port.
: Unfortunately mv treats Flash memory space as 64-bit and incorrectly copies data to RAM.

: Is there any way to tell DINK to treat Flash memory space as 8-bit?


Hi Alex,


Here’s my e-mail from yesterday:


From jwall Mon Mar 4 08:46:16 2002
Subject: Re: sandpoint-flash build file
To: aivchenko@ueidaq.com (Alex Ivchenko)
Date: Mon, 4 Mar 2002 08:46:16 -0500 (EST)
From: “John Wall” <jwall@qnx.com>
In-Reply-To: <3C7FEADB.5EC61F4A@ueidaq.com> from “Alex Ivchenko” at Mar 01, 2002 03:55:55 PM
X-Mailer: ELM [version 2.5 PL0b1]
Content-Length: 4779
Status: RO

This is a multi-part message in MIME format.
--------------DC283424D812EEF79D0AF411
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit

Hi, John,

Sorry for bothering you again.

Let me explain what I try to accomplish, may be there is simpler way to do it.

I’d like to:

  1. Start QNX from 1MB user flash available on Unity X4 MPC8245 plugged into Sandpoint X3.
  2. Initialize proc, serial, memory, PCI, etc. Then load IDE driver, mount partition on CompactFlash
    device (master on primary IDE) and proceed with whatever specified in /etc/rc.d

Q1: Is it the best way to go?

As good as any :wink:


I wrote a small build script and built OS image.
When I build OS image for RAM, download it (for 6 minutes), then with “go 1f1c48” it starts
correctly. It finds IDE, NIC, etc., mounts file system, etc.

When I built it for Flash, and program Sandpoint, it starts but hangs after the first “Rolling”
message (on devc-ser8250 …)

This is strange. The exact same image works correctly when downloaded to
RAM (using DINK32)? Since I have not setup the Sandpoint in the exact manner
as you could you please answer the following:

→ Does the image from flash execute directly from the reset
vector, i.e. does the QNX IPL take control before anything else?

→ Can you please comment out devc-ser8250 from the build file. Also,
comment out the reopen statement(s). Does the system now bring
you to a shell prompt.

→ Did you get an updated IPL for the 8245? The IPL that ships
with the BSP (like startup) does not support the 8245.


→ Simplify the build file.


So far I have no clue why this can happen…

I switch SW2[1] to boot from PCI ROM (DINK) and SW2[5] to enable write to local (PMC) flash.

Flash code is compiled for FFF00000
I do:
dl -k -o 200000 (FFF00000+200000=100000)
fu -l 100000 ff000000 100000

Then I switch SW2[1] to boot from local Flash.

First OS loads but hangs shortly.

Q2: why does it happen? Should I copy OS to RAM first and start from there?
Have you ever tested running whole image from the flash without serial download?

Yes, all systems have been tested executing images from flash.
If you take a look at the building embedded systems manual, you’ll
note that a large part of the IPLs job is to properly locate startup
in RAM.

I use 16MB CompactFlash sitting on eide interface.
I load:
devb-eide eide ioport=0xfe0001f0,irq=114 blk automount=/dev/hd0t6:/hd &

Q3: Is it correct for CompactFlash drive?

Yes; you mentioned above that the IDE works fine (image downloaded directly
to ram). There is no difference whether the image is loaded from flash or
via serial.


I have a few other questions:

I built OS RAM image in two directories:
C:\qnxsdk\QNXsdk\target\qnx6\boot\build
and
C:\qnxsdk\QNXsdk\target\qnx6\ppcbe\boot\build\

Image from the first directory works fine, image from the second directory hangs Sandpoint.
When you comp files you can see the difference.
I used the same sandpoint.build file

Actually, sandpoint.build files (identical!) are located:
C:\qnxsdk\QNXsdk\target\qnx6\usr\src\bsp-6.1.0\ppc\sandpoint\images
C:\qnxsdk\QNXsdk\target\qnx6\usr\src\bsp-6.1.0\ppc\sandpoint\scratch\ppcbe\boot\build
C:\qnxsdk\QNXsdk\target\qnx6\boot\build
C:\qnxsdk\QNXsdk\target\qnx6\ppcbe\boot\build\

When you:
mkifs sandpoint.build sandpoint.img ALL four .img files are different

Only file compiled in: C:\qnxsdk\QNXsdk\target\qnx6\boot\build\ runs fine

Q4: What is the right directory to build RAM image? What is the reason to have all these trees?
Where is the right place to build image?

You should be building from the sandpoint\images directory. You should be using
the Makefiles to build from this directory (includes special switches
to build stuff in from the scratch directory).

How are you determining that the images are different? Note, all images
contain a timestamp that will make them produce different cksums.

Is Driver for National Semiconductor’s MacPHYTER NS83815 Ethernet adapters supported on PPC
platform? I saw devn-ns83815.so for x86 and other platforms but not for PPC.

I believe the next release may have it for PPC. If this is a requirement
I would suggest contacting your QNX sales rep.

Q5: where I can get driver for 83815 for QNX for Sandpoint? Should I write my own? I can follow the
same path you guys did - take Linux driver and port it to QNX.

I don’t see much reason to do this … I don’t see any reason that it isn’t
available for PPC. Your sales rep can help you (either getting the source
or providing a PPC version).



\

John




: –
: Regards,
: Alex

: –
: Alex Ivchenko, Ph.D.
: United Electronic Industries, Inc.
: “The High-Performance Alternative ™”
: –
: 611 Neponset Street
: Canton, MA 02021
: Tel:(781)821-2890 x222 Fax:(781)821-2891
: http://www.ueidaq.com


John Wall
QSSL
Custom Engineering Group (R&D)

John,

I sent you a lengthy e-mail yesterday concerning this issue; did you not get
it? Did you get an updated QNX IPL at the same time as the new
No, I did not.



startup-sandpoint? If not, the IPL you have knows nothing about the
8245 and may not be correctly initializing it.
No, I did not. I got only new startup-sandpoint from David @ QNX.

Probably this is the cause.


Regards,
Alex


Alex Ivchenko, Ph.D.
United Electronic Industries, Inc.
“The High-Performance Alternative ™”

611 Neponset Street
Canton, MA 02021
Tel:(781)821-2890 x222 Fax:(781)821-2891
http://www.ueidaq.com

John,

I wrote a small build script and built OS image.
When I build OS image for RAM, download it (for 6 minutes), then with “go 1f1c48” it starts
correctly. It finds IDE, NIC, etc., mounts file system, etc.

When I built it for Flash, and program Sandpoint, it starts but hangs after the first “Rolling”
message (on devc-ser8250 …)
Well, I got new files today from QNX tech support.

In some strange reason it doesn’t work with RAM too…
When I load previously compiled images it goes, but not with new images.
I recompiled libstartup.a and libipl.a with the new files.

I’ll try to recompile with old startup-sandpoint to see what’s wrong…


→ Does the image from flash execute directly from the reset
vector, i.e. does the QNX IPL take control before anything else?
Yes



→ Can you please comment out devc-ser8250 from the build file. Also,
comment out the reopen statement(s). Does the system now bring
you to a shell prompt.
I tried it. Then it hangs up on waitfor /dev/pipe



→ Did you get an updated IPL for the 8245? The IPL that ships
with the BSP (like startup) does not support the 8245.
Today I got updated. No luck.



Yes, all systems have been tested executing images from flash.
Correct. Start from flash and download code thru serial interface.

This is default.
I try to have everything in the flash.


Regards,
Alex


Alex Ivchenko, Ph.D.
United Electronic Industries, Inc.
“The High-Performance Alternative ™”

611 Neponset Street
Canton, MA 02021
Tel:(781)821-2890 x222 Fax:(781)821-2891
http://www.ueidaq.com