You don’t have to build ‘Uboot image’ using that tool. If you generate QNX
boot image in ELF multiboot-compatible format (this is supported starting
from 6.3 I think) Uboot can load it directly by “bootelf” command.
One neat feature that you can use is that Uboot has ‘autoboot’ command
that can include a sequence of commands. It also tries to verify an image
before jumping and skips the jump if it is invalid. Together these
features allow for something like this:
autoboot=“bootelf; tftp; bootm primary write xxxxxxx; reset”
(not sure about the bootm - it might have been some other command, it’s
been few years…).
Which means ‘try to boot, if that fails try to TFTP and reflash the boot
image, then reset’.
This allows fail-safe boot using network, which is nice during development
when you can mess up your board. If you want to deploy a new image all you
have to do is to put in onto your TFTP server and invalidate the image
signature on the board (this can be done by interrupting the autoboot with
ESC and using command like “erase 2:2”). The target will pick it up and
reflash itself on next boot…
– igor
“Jan Raddatz” <> jan.raddatz@gmail.com> > wrote in message
news:e698cg$g11$> 1@inn.qnx.com> …
Dear Dave,
thanks a lot for your quick answer. It sounds similar to Pierre’s answer
and I will try to get it running at Uni now.
Thanks again and have a great day !
Jan
“Dave Green” <> dgreen@dgreen.ott.qnx.com> > schrieb im Newsbeitrag
news:e695om$e6e$> 1@inn.qnx.com> …
Jan Raddatz <> jan.raddatz@gmail.com> > wrote:
Dear Newsgroup,
actually I am trying to port QNX onto the DNP9200 Board and I ran into
another problem.
We managed to create a complete QNX Image with our own Startup Programm
written as described in the QNX documentation.
Since UBoot does a lot of hardware initialization we have not written
our
own IPL programm and want to use UBoot.
For testing the image we want to start it via UBoot and executing the
startup by jumping to our startup code entry point.
The question is:
Is that possible and if so how do we find out the adress of the entry
point
of our startup code?
Booting QNX from U-Boot is possible, and quite common. There are various
ways
of specifying the start address for U-Boot to jump to, depending on what
type
of image you generated.
Here are some examples - assume DRAM starts at 0xA0000000.
In your build file, if you have:
[image=0xa0020000]
[virtual=armle,binary]
when you generate the image, you will obtain an offset where the QNX
image
execution begins:
mkifs -vvvv build image.bin
Offset Size Entry Ramoff Target=Host
a0020000 100 ---- — Startup-header
a0020100 c008 a00224e0 — /tmp/DAA065960
^^^^^^^^
this is the address for U-Boot to jump to (startup_vaddr)
So, at the U-Boot prompt, you would download and run the image as
follows:
U-Boot=>tftpboot 0xA0020000 /xfer/image
…[image loads]
U-Boot=>go 0xA00224e0
The problem with this method is, if you change the startup code at all,
the
entry address may change, and it’s tiresome to obtain the address each
time,
and manually enter it. A better method is to configure your build file
as follows:
[image=0xa0020000]
[virtual=armle,raw]
A ‘raw’ format image is the same as a binary, except it has a jump
instruction,
right at the beginning, which jumps to startup_vaddr. So, each time you
load the
image, you can enter:
U-Boot=>tftpboot 0xA0020000 /xfer/image.raw
…[image loads]
U-Boot=>go 0xA0020000
Actually we are try to use the offset value that is printed when
building
the QNX image.
At the moment UBoot says: Starting Kernel…
And thats all…
Thanks a lot in advance!
Greetings
Jan
\
David Green (> dgreen@qnx.com> )
QNX Software Systems Ltd.
http://www.qnx.com
\