Skip navigation.
Home
The QNX Community Portal

View topic - Booting up on a new board design

Booting up on a new board design

Read-only archive of qnx.cafe (generail discussion forum) at inn.qnx.com

Booting up on a new board design

Postby kwschumm » Thu Sep 29, 2005 10:20 pm

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.
kwschumm
Senior Member
 
Posts: 306
Joined: Fri Sep 17, 2004 12:46 pm

Re: Booting up on a new board design

Postby Igor Kovalenko » Fri Sep 30, 2005 6:38 am

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.
Igor Kovalenko
 

Re: Booting up on a new board design

Postby kwschumm » Fri Sep 30, 2005 2:32 pm

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.

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.

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.

kwschumm
Senior Member
 
Posts: 306
Joined: Fri Sep 17, 2004 12:46 pm

Re: Booting up on a new board design

Postby Dave Green » Fri Sep 30, 2005 2:54 pm

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
Dave Green
 

Re: Booting up on a new board design

Postby kwschumm » Fri Sep 30, 2005 3:12 pm

Very helpful info, Dave, thank you!

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.

Thanks a bunch!

Ken

"Dave Green" <dgreen@qnx.com> wrote in message
news:dhjjj5$p2m$1@inn.qnx.com...
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
kwschumm
Senior Member
 
Posts: 306
Joined: Fri Sep 17, 2004 12:46 pm

Re: Booting up on a new board design

Postby David Gibbs » Fri Sep 30, 2005 4:58 pm

Ken Schumm <kwschumm@qsolv.com> wrote:
Thanks for the info. Das U-Boot is a great name.

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.

The IPL generally executes directly out of flash. (Dave already discussed
further stuff.)

The issue with Flash is that, generally, you can't both execute out of
it and modify the contents at the same time -- the program (and erase)
modes make it unreadable, which if you're doing XIP is a problem. During
IPL, though, you're not modifying the flash, so (assuming it is linearly
mapped, the usual case), you can XIP the IPL, but usually don't want to
for the rest of the image.

-David
--
David Gibbs
QNX Training Services
dagibbs@qnx.com
David Gibbs
 

Re: Booting up on a new board design

Postby kwschumm » Fri Sep 30, 2005 7:06 pm

The last flash I worked with was a pain to read. You had to write an
address, wait a tiny bit, then read a word. Lather, rinse, repeat. I know on
that flash there was no way to XIP. May have been the board, not the flash.
That board wasn't intended to boot off the flash.

Anyway, thanks everyone, it's all clear now.

"David Gibbs" <dagibbs@qnx.com> wrote in message
news:dhjqs3$ll$4@inn.qnx.com...
Ken Schumm <kwschumm@qsolv.com> wrote:
Thanks for the info. Das U-Boot is a great name.

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.

The IPL generally executes directly out of flash. (Dave already discussed
further stuff.)

The issue with Flash is that, generally, you can't both execute out of
it and modify the contents at the same time -- the program (and erase)
modes make it unreadable, which if you're doing XIP is a problem. During
IPL, though, you're not modifying the flash, so (assuming it is linearly
mapped, the usual case), you can XIP the IPL, but usually don't want to
for the rest of the image.

-David
--
David Gibbs
QNX Training Services
dagibbs@qnx.com
kwschumm
Senior Member
 
Posts: 306
Joined: Fri Sep 17, 2004 12:46 pm

Re: Booting up on a new board design

Postby David Gibbs » Fri Sep 30, 2005 8:15 pm

Ken Schumm <kwschumm@qsolv.com> wrote:
The last flash I worked with was a pain to read. You had to write an
address, wait a tiny bit, then read a word. Lather, rinse, repeat. I know on
that flash there was no way to XIP. May have been the board, not the flash.
That board wasn't intended to boot off the flash.

Wow. I mean wow. I don't think I've heard of any flash in ages that
worked like that.

-David
--
David Gibbs
QNX Training Services
dagibbs@qnx.com
David Gibbs
 

Re: Booting up on a new board design

Postby kwschumm » Sat Oct 01, 2005 3:02 am

"David Gibbs" <dagibbs@qnx.com> wrote in message
news:dhk6cv$92n$1@inn.qnx.com...
Ken Schumm <kwschumm@qsolv.com> wrote:
The last flash I worked with was a pain to read. You had to write an
address, wait a tiny bit, then read a word. Lather, rinse, repeat. I
know on
that flash there was no way to XIP. May have been the board, not the
flash.
That board wasn't intended to boot off the flash.

Wow. I mean wow. I don't think I've heard of any flash in ages that
worked like that.

That was on a new product that was completed late last year. I'm not sure
why they chose that particular part. Maybe they got a good deal on some
really old stock.
kwschumm
Senior Member
 
Posts: 306
Joined: Fri Sep 17, 2004 12:46 pm

Re: Booting up on a new board design

Postby Igor Kovalenko » Sat Oct 01, 2005 5:36 am

"David Gibbs" <dagibbs@qnx.com> wrote in message
news:dhjqs3$ll$4@inn.qnx.com...
Ken Schumm <kwschumm@qsolv.com> wrote:
Thanks for the info. Das U-Boot is a great name.

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.

The IPL generally executes directly out of flash. (Dave already discussed
further stuff.)

The issue with Flash is that, generally, you can't both execute out of
it and modify the contents at the same time -- the program (and erase)
modes make it unreadable, which if you're doing XIP is a problem. During
IPL, though, you're not modifying the flash, so (assuming it is linearly
mapped, the usual case), you can XIP the IPL, but usually don't want to
for the rest of the image.

So your hardware looks quite a bit like our phones these days. Yes,
initially you run dead iron through JTAG. No, you can't indeed directly
program flash through JTAG. What we do is load a piece of code called
'ramloader' through JTAG/RVD (ARM debugger) and run it. It has support for
flash and USB, so once it runs we can flash a real bootloader through USB.
Then it reboots and you can flash the rest through USB too.

We do actually modify the flash we are running from and we are doing XIP.
But it is very very tricky. ARM design is not really conductive to that, you
have to worry about what's in the CPU pipeline, what's in the return buffer,
what's in the cache, etc. We only can do it because we don't run a 'real
OS'. Sitting right on the hardware ...

-- igor
Igor Kovalenko
 

Re: Booting up on a new board design

Postby kwschumm » Sat Oct 01, 2005 2:49 pm

"Igor Kovalenko" <kovalenko@comcast.net> wrote in message
news:dhl75t$13u$1@inn.qnx.com...
"David Gibbs" <dagibbs@qnx.com> wrote in message
news:dhjqs3$ll$4@inn.qnx.com...
[...]


So your hardware looks quite a bit like our phones these days. Yes,
initially you run dead iron through JTAG. No, you can't indeed directly
program flash through JTAG. What we do is load a piece of code called
'ramloader' through JTAG/RVD (ARM debugger) and run it. It has support for
flash and USB, so once it runs we can flash a real bootloader through USB.
Then it reboots and you can flash the rest through USB too.

That's what we discovered, and we're trying to come up with a scheme to JTAG
the IPL into flash. Is 'ramloader' something you guys wrote?

We do actually modify the flash we are running from and we are doing XIP.
But it is very very tricky. ARM design is not really conductive to that,
you
have to worry about what's in the CPU pipeline, what's in the return
buffer,
what's in the cache, etc. We only can do it because we don't run a 'real
OS'. Sitting right on the hardware ...

Sounds tricky. The flash on our system won't be modified after shipment so
that shouldn't be a problem.
kwschumm
Senior Member
 
Posts: 306
Joined: Fri Sep 17, 2004 12:46 pm

Re: Booting up on a new board design

Postby Igor Kovalenko » Sun Oct 02, 2005 7:34 am

A great thing about U-Boot was that it allowed to have a sequence of
commands as default 'boot command' and it was smart enough to check image
header/checksum before attempting to jump into it.

That provided for a 'fail safe' boot command, sort of 'boot; erase; tftp;
reflash; reset'. If the image is found to be invalid then the first boot
won't execute and it will proceed to download and reflash an image, then
reset and the cycle goes on until it succeeds. This command does not ever
needs to be changed, if you want to force a fresh install you only need to
interrupt the boot sequence (hit some key from a serial console) and
manually erase 1 block that keeps the image header...

"Ken Schumm" <kwschumm@qsolv.com> wrote in message
news:dhji48$oa8$1@inn.qnx.com...
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.

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.

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.



Igor Kovalenko
 


Return to qnx.cafe

Who is online

Users browsing this forum: No registered users and 1 guest