The board is a custom board based on the PXA270 reference design. The
customer is designing it in-house. They claim the flash can’t be programmed
with JTAG but they are using the same parts as the reference design. I will
investigate.
Ken Schumm <> kwschumm@qsolv.com> > wrote:
Thanks for the info. Das U-Boot is a great name.
This is on a PXA270 XScale/ARM processor.
The part we’re missing is how the IPL gets in the dead iron in the first
place and what it runs out of. With a completely blank board with zero
code
in it how would you get the IPL loaded into it from a PC? JTAG? There
has to
be some code running on the dead board end of the cable to the laptop.
A completely dead board must be reflashed using a JTAG tool, or else by
removing the flash from a socket, and programming it in an external
programmer.
Many Intel Xscale reference boards have two seperate banks of flash, and
the bank that is booted from is selectable by a switch or jumper. This
enables
you to keep a “safe” bank, which contains the Intel bootloader (BBU or
some
variant) in one bank, and use the other bank for placing your experimental
IPL or bootloader code in.
If you have only one bank of flash, and the boards are dead from the
factory,
then you’ll definitely need a JTAG tool to program them for the first
time.
Can you XIP directly out of flash these days or does it have to get
copied
to RAM? If copied to RAM then there has to be code at the reset vector
to
copy the code and jump to it.
Native QNX Initial Program Loader (IPL) code is what normally executes at
the reset vector, locates the image in flash, copies the startup code to
DRAM, and then executes the startup code in DRAM. The startup code itself
copies the rest of the OS image from flash to DRAM, prior to starting the
Neutrino kernel.
Conversely, a bootloader typically copies the entire OS image to DRAM,
either from flash, or over a TFTP connection.
XIP OS images are supported, but you still require some DRAM available for
program data. There are also some restrictions on using an XIP OS image:
-it can’t be compressed
-if a flash filesystem is in use, it can’t reside in the same flash array
as the flash filesystem
Unless you have a limited amount of DRAM available, you wouldn’t normally
use XIP.
Is your PXA270 board a reference platform, or custom built hardware?
If it truly comes to you as a “brick”, it will likely come with some
JTAG software and hardware, to allow you to program the board.
Maybe I’m missing something obvious here.
“Igor Kovalenko” <> kovalenko@comcast.net> > wrote in message
news:dhime6$450$> 1@inn.qnx.com> …
What platform it is supposed to be?
On PPC, ARM and some others you may be able to use one of the popular
Linux-based bootloaders. I have used PPCboot (now known as Das U-Boot)
to
do
exactly what you’re looking for. There’s also RedBoot.
On x86 you can use PXE (most newer BIOSes support it) - I have done
that
too
(well, the flash was a CF card on IDE interface, but it still qualifies
as
flash does not it). Some BIOSes for industrial/embedded boards also
have
an
option to ‘jump to flash’ (there is usually half of it unused).
The way it worked is I generated ‘install CD’ that would go into a
laptop.
The laptop gets hooked up to the board over ethernet and runs a simple
configuration applet. Once you set your parameters (you need stuff like
name, IP, netmask, serial port to use, baud rate, flash configuration
data
and whatever else you may want to preset during installation) a
TFTP/DHCP
server starts up on laptop and serves the boot image to the client (the
board) from that CD.
Once the image is transferred, it loads up DHCP /TFTP client and
requests
those config parameters (using extended DHCP fields if needed). A boot
script then formats the flash and pulls a fixed ‘package list’ file
from
the
laptop that contains names of the rest of the stuff to download and
install,
then goes through the list (I had a convention that for each .tgz file
there
was a .sh script to download along and the .sh script would be executed
on
target in order to install the .tgz properly - post-install
configuration
specific to that tarball, etc).
Then it fixes up various config files, writes a boot image to the board
(I
used the same boot image and ‘smart’ boot script that can detect
whether
it
is a fresh installation or a regular boot using hostname), etc. And
eventually reboots the target so that after reboot it is ready to
accept
‘telnet’ from your laptop.
We shipped couple systems designed this way and it worked quite well.
You
can walk up to a dead piece of iron with any non-preconfigured Windows
laptop, stick a CD into it and do the installation with almost no
manual
intervention. We also had one system where whatever target-specific
information was needed would be pulled from a floppy or a USB flash
drive
so
you only had to prepare it once for a given target and reinstall with
no
human intervention at all if a system board needs to be changed. It was
also
pretty flexible - once you work out the kinks, the procedure and boot
images
does not change anymore. If you have a new version of your software to
install, you only need to place a new ‘package list’ and new tarballs
onto
the CD. That was integrated into the source control and build system,
so
whenever we had a new build it would run a script that generated ISO
image
for that ‘install CD’.
Saved us tons of time on testing, both in terms of time needed to
install
and time lost due to human errors during installations.
– igor
“Ken Schumm” <> kwschumm@qsolv.com> > wrote in message
news:> 2gpoj11begqhjnsrjjbchj8sr722ael1tq@4ax.com> …
It’s been about 15 years since I’ve done any embedded work on boards
without a BIOS. Back then we used to burn all the code into an eprom
and the reset vector would cause execution to begin in the eprom
code.
I’m working on a new project where the customer wants to manufacture
the boards with onboard flash, then hook it up to ethernet and turn
it
on and have the code get loaded into flash over ethernet.
That’s a nice idea but there are a few problems I see.
First, some IPL code has to be built into the board during
manufacture
before the rest of the code can be downloaded from ethernet to flash.
Second, AFAIK you can’t XIP directly out of flash. At least that used
to be the case.
Has anyone come up with a brilliant solution for this chicken-and-egg
problem? I don’t see a solution other than to burn a small eprom and
IPL from that.
\
David Green (> dgreen@qnx.com> )
QNX Software Systems Ltd.
http://www.qnx.com