IPL for Atmel and/or AMD flash devices...

QNX Newsgroups (Archives) qnx.rtos
1

Hi…

I wonder which IPL sample applies for the Atmel and AMD flash devices?
These devices are sector based devices. How do I get information
regarding where the flash resides in memory? I I know this, I could use
the generic flash.

http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/22288.pdf
http://www.atmel.com/dyn/resources/prod_documents/DOC0518.PDF



Thanks.

Regards…

Miguel.

2

Hi…

The correct ‘flash’ device for the Prometheus board is AT93C46. This is
a EEPROM device. Do we have drivers for EEPROM devices? How would I
write an IPL for this type of device? Thanks.

Regards…

Miguel.

Link to device:

http://www.atmel.com/dyn/products/product_card.asp?family_id=647&family_name=Serial+EEPROM&part_id=1913




Miguel Simon wrote:

Hi…

I wonder which IPL sample applies for the Atmel and AMD flash devices?
These devices are sector based devices. How do I get information
regarding where the flash resides in memory? I I know this, I could use
the generic flash.

http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/22288.pdf

http://www.atmel.com/dyn/resources/prod_documents/DOC0518.PDF



Thanks.

Regards…

Miguel.

3

Miguel Simon <simon@ou.edu> wrote:

Hi…

The correct ‘flash’ device for the Prometheus board is AT93C46. This is
a EEPROM device. Do we have drivers for EEPROM devices? How would I
write an IPL for this type of device? Thanks.

When you say ‘IPL’, do you mean Initial Program Loader, that is, the
very first code that will execute when power is applied? If so, then
the IPL doesn’t care what type of device it’s executed out of, as long
as the device is seen by the CPU as linear memory. The device that
you’ve named is a 3 wire serial EEPROM, which is not linear memory,
so it can’t be used as the primary boot device for the board.

If this is the same Prometheus board that you were asking about
in an earlier thread, it appears that the only boot device on
this board is the 2M flash which stores the BIOS, and has free
space for user applications. If you want to eliminate the BIOS
altogether, and write a native QNX IPL for this board, it will
likely involve erasing the BIOS image, and placing your IPL code
there instead. This may not be as scary as it sounds -the docs
indicate that there is a command interpreter built into the CPU
that can be used to reprogram the BIOS, should it get erased or
become corrupted.

We don’t have a generic driver to program serial EEPROM devices,
so you’d have to write a small program to interface with it,
as per the spec sheet for the device. For the 2M flash, if it is mapped
linearly, then there’s a good chance that our generic flash driver,
devf-generic, would work. If not, a dedicated flash driver for this
component would be fairly straightforward, using an existing flash
driver source as a starting point. If the flash is paged (that is,
only a small 8k or 16k window of the flash is visible at any given
time), then a custom flash driver is definitely necessary.

Note that you don’t need a flash driver to run QNX on the board;
the IPL could be made to load an OS image serially, directly to
memory, or to copy an OS image from flash to DRAM. However, you
may need a flash driver to program the IPL and OS image into
flash in the first place, if the utilities that come with the
board aren’t capable of doing that.


Regards…

Miguel.

Link to device:

http://www.atmel.com/dyn/products/product_card.asp?family_id=647&family_name=Serial+EEPROM&part_id=1913



Miguel Simon wrote:
Hi…

I wonder which IPL sample applies for the Atmel and AMD flash devices?
These devices are sector based devices. How do I get information
regarding where the flash resides in memory? I I know this, I could use
the generic flash.

http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/22288.pdf

http://www.atmel.com/dyn/resources/prod_documents/DOC0518.PDF



Thanks.

Regards…

Miguel.
\

–

David Green (dgreen@qnx.com)
QNX Software Systems Ltd.
http://www.qnx.com

4

Hi Dave…

Thanks for your reply. Here are some comments.

Dave Green wrote:

Miguel Simon <> simon@ou.edu> > wrote:

Hi…


The correct ‘flash’ device for the Prometheus board is AT93C46. This is
a EEPROM device. Do we have drivers for EEPROM devices? How would I
write an IPL for this type of device? Thanks.


When you say ‘IPL’, do you mean Initial Program Loader, that is, the
very first code that will execute when power is applied? If so, then

yes.

the IPL doesn’t care what type of device it’s executed out of, as long
as the device is seen by the CPU as linear memory. The device that
you’ve named is a 3 wire serial EEPROM, which is not linear memory,
so it can’t be used as the primary boot device for the board.

I thought that the IPL has a portion for assembly language where you can
do things such as talk to the serial EEPROM? From the documentation
from the DiamondSystems, when the Prometheus board boots, it lands on
this ‘flash’ device to execute the BIOS. Would this not be the primary
boot device for the Prometheus board then?

If I read correctly, you say that the IPL cannot be the primary boot
device because the device is not linearly mapped. Is this always the case?

If this is the same Prometheus board that you were asking about
in an earlier thread, it appears that the only boot device on
this board is the 2M flash which stores the BIOS, and has free

This 2M flash is indeed the same 3 wire serial EEPROM above. They call
it a ‘flash’ device, but indeed it is not. This serial EEPROM is where
the original BIOS for the prometheus lives.

space for user applications. If you want to eliminate the BIOS
altogether, and write a native QNX IPL for this board, it will
likely involve erasing the BIOS image, and placing your IPL code
there instead. This may not be as scary as it sounds -the docs
indicate that there is a command interpreter built into the CPU
that can be used to reprogram the BIOS, should it get erased or
become corrupted.

Correct. This is a very benign environment for this very reason.


We don’t have a generic driver to program serial EEPROM devices,
so you’d have to write a small program to interface with it,

Ok, I see.

as per the spec sheet for the device. For the 2M flash, if it is mapped
linearly, then there’s a good chance that our generic flash driver,

No. The 2M flash is the same serial EEPROM. :frowning:

devf-generic, would work. If not, a dedicated flash driver for this
component would be fairly straightforward, using an existing flash
driver source as a starting point. If the flash is paged (that is,
only a small 8k or 16k window of the flash is visible at any given
time), then a custom flash driver is definitely necessary.

I suppose that I will have to dive into this pool then…

Note that you don’t need a flash driver to run QNX on the board;
the IPL could be made to load an OS image serially, directly to
memory, or to copy an OS image from flash to DRAM. However, you

If I read correctly, you say that perhaps I can read the EEPROM serially
directly into memory. This is an idea worth the effort.

may need a flash driver to program the IPL and OS image into
flash in the first place, if the utilities that come with the
board aren’t capable of doing that.

I think that the utilities that come with the bard are capable of doing
this. In other words, once I write an IPL, then I should be able to dump
it into the EEPROM with the provided utilities. I think that I only need
to get the IPL to read from the EEPROM serially and put the information
in RAM.

Thanks for your help.

Best Regards…

Miguel.

Regards…


Miguel.


Link to device:


http://www.atmel.com/dyn/products/product_card.asp?family_id=647&family_name=Serial+EEPROM&part_id=1913





Miguel Simon wrote:

Hi…

I wonder which IPL sample applies for the Atmel and AMD flash devices?
These devices are sector based devices. How do I get information
regarding where the flash resides in memory? I I know this, I could use
the generic flash.

http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/22288.pdf

http://www.atmel.com/dyn/resources/prod_documents/DOC0518.PDF



Thanks.

Regards…

Miguel.


\

5

Miguel Simon <simon@ou.edu> wrote:

Hi Dave…

Thanks for your reply. Here are some comments.

Dave Green wrote:
Miguel Simon <> simon@ou.edu> > wrote:

Hi…


The correct ‘flash’ device for the Prometheus board is AT93C46. This is
a EEPROM device. Do we have drivers for EEPROM devices? How would I
write an IPL for this type of device? Thanks.


When you say ‘IPL’, do you mean Initial Program Loader, that is, the
very first code that will execute when power is applied? If so, then

yes.

the IPL doesn’t care what type of device it’s executed out of, as long
as the device is seen by the CPU as linear memory. The device that
you’ve named is a 3 wire serial EEPROM, which is not linear memory,
so it can’t be used as the primary boot device for the board.

I thought that the IPL has a portion for assembly language where you can
do things such as talk to the serial EEPROM? From the documentation
from the DiamondSystems, when the Prometheus board boots, it lands on
this ‘flash’ device to execute the BIOS. Would this not be the primary
boot device for the Prometheus board then?

No, the assembly portion of the IPL is typically where the memory
controller and an initial stack are set up, so that subroutines
can be called and returned from, at which point execution can
change to ‘C’ language code. It is possible in an IPL to have code
to read a boot image, for example, from a non-linear device (such as
a serial EEPROM or NAND flash), copy that code to linear DRAM memory,
and execute it from there.

If I read correctly, you say that the IPL cannot be the primary boot
device because the device is not linearly mapped. Is this always the case?

Yes. There must be some form of linear storage available for the CPU
to execute its initial boot code from.

If this is the same Prometheus board that you were asking about
in an earlier thread, it appears that the only boot device on
this board is the 2M flash which stores the BIOS, and has free

This 2M flash is indeed the same 3 wire serial EEPROM above. They call
it a ‘flash’ device, but indeed it is not. This serial EEPROM is where
the original BIOS for the prometheus lives.

Are you sure about this? The first part number you mentioned (AT93C46)
is described as a 3-wire serial EEPROM, available in sizes of 1k, 2k,
or 4k. I don’t see how this can be the same as the “2 MEG, 16 bit wide
integrated flash memory” described in the docs…

space for user applications. If you want to eliminate the BIOS
altogether, and write a native QNX IPL for this board, it will
likely involve erasing the BIOS image, and placing your IPL code
there instead. This may not be as scary as it sounds -the docs
indicate that there is a command interpreter built into the CPU
that can be used to reprogram the BIOS, should it get erased or
become corrupted.

Correct. This is a very benign environment for this very reason.



We don’t have a generic driver to program serial EEPROM devices,
so you’d have to write a small program to interface with it,

Ok, I see.

as per the spec sheet for the device. For the 2M flash, if it is mapped
linearly, then there’s a good chance that our generic flash driver,

No. The 2M flash is the same serial EEPROM. > :frowning:

Again, I’m not convinced that this is the case. I’d recommend
getting the board schematics from the manufacturer. That should
tell the whole story.

devf-generic, would work. If not, a dedicated flash driver for this
component would be fairly straightforward, using an existing flash
driver source as a starting point. If the flash is paged (that is,
only a small 8k or 16k window of the flash is visible at any given
time), then a custom flash driver is definitely necessary.

I suppose that I will have to dive into this pool then…


Note that you don’t need a flash driver to run QNX on the board;
the IPL could be made to load an OS image serially, directly to
memory, or to copy an OS image from flash to DRAM. However, you

If I read correctly, you say that perhaps I can read the EEPROM serially
directly into memory. This is an idea worth the effort.

may need a flash driver to program the IPL and OS image into
flash in the first place, if the utilities that come with the
board aren’t capable of doing that.

I think that the utilities that come with the bard are capable of doing
this. In other words, once I write an IPL, then I should be able to dump
it into the EEPROM with the provided utilities. I think that I only need
to get the IPL to read from the EEPROM serially and put the information
in RAM.

Thanks for your help.

Best Regards…

Miguel.




Regards…


Miguel.


Link to device:


http://www.atmel.com/dyn/products/product_card.asp?family_id=647&family_name=Serial+EEPROM&part_id=1913





Miguel Simon wrote:

Hi…

I wonder which IPL sample applies for the Atmel and AMD flash devices?
These devices are sector based devices. How do I get information
regarding where the flash resides in memory? I I know this, I could use
the generic flash.

http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/22288.pdf

http://www.atmel.com/dyn/resources/prod_documents/DOC0518.PDF



Thanks.

Regards…

Miguel.



\

–

David Green (dgreen@qnx.com)
QNX Software Systems Ltd.
http://www.qnx.com

6

Hi Dave…

Thanks…

Dave Green wrote:

This 2M flash is indeed the same 3 wire serial EEPROM above. They call
it a ‘flash’ device, but indeed it is not. This serial EEPROM is where
the original BIOS for the prometheus lives.


Are you sure about this? The first part number you mentioned (AT93C46)
is described as a 3-wire serial EEPROM, available in sizes of 1k, 2k,
or 4k. I don’t see how this can be the same as the “2 MEG, 16 bit wide
integrated flash memory” described in the docs…

No, I am not sure… You must be right. I am not sure how I got on that
tangent, but obviously what you say makes sense.

This is what I have done:

  1. Using the current bios, I programed the chip select to access the
    window where the flash seems to be
  2. the generic flash driver works. I can see the flash now. It seems
    that is linearly mapped

question:

  1. once I compile the IPL, have the boot image, and have the flash
    filesystem, how do I transfer this to the flash?

I thinks that I use the following:

mkrec => for the IPL
mkifs => for the bootimage
mkefs => for the flahs filesystem

How do I put all of this together in fhash?

Thanks…

Miguel.




Thanks for your help…

Regards.

7

Hi Dave…

Regarding the flash device, it seems to be linearly mapped. I can get it
to boot in DOS. I can get the devf-generic to see the flash and mount
it as /dev/fs0 and /dev/fs0p0. But I cannot erase the flash (the action
fails), nor can I write to it (it blocks).

When I boot in DOS, it does behave as a disk, but I cannot transfer the
.boot image to there because none of the DOS utilities recognize the
file, or complain about something else.

Any help is most appreciated.


Here is what I have done (aside to what is above):

  1. got the sc400 BSP source code, adapted the best I knew how,
  2. did the following:

mkrec -s32k -ffull -r ipl-sc400 > ipl-bin.pad
mkrec -ffull -s128k ipl-bin.pad > sc400.rom
cat sc400.rom sc400.rom > sc400_256.rom

  1. changed the build file to have:

[virtual=x86,nobios +compress].bootstrap={
startup-bios -D0x3f.115200 -vvv
PATH=/proc/boot procnto -vv
}

…

  1. mkifs -vv sc400.build sc400.ifs

  2. cat sc400_256.rom sc400.ifs > new.rom

  3. uploaded the new rom to the board using the proper utilities…

  4. …and nothing worked (as expected)


    Then… another way…

    \

  5. this time I used the ipl-sc400_ext which is the one that we use with
    the bios and:

  6. did the following:

mkrec -s32k -ffull -r ipl-sc400_ext > ipl-bin.pad
mkrec -ffull -s128k ipl-bin.pad > sc400.rom

  1. changed the build file to have:

[virtual=x86,bios +compress].bootstrap={
startup-sc400 -D0x3f.115200 -vvv
PATH=/proc/boot procnto -vv
}

  1. cat bios.rom sc400.rom sc400.ifs > new.rom

  2. uploaded the new.rom to the flash… but it did not work either.


    I wonder if you have some suggestions? I appreciate it.

Best regards…

8

Miguel Simon <simon@ou.edu> wrote:

Hi Dave…

Thanks…

Dave Green wrote:

This 2M flash is indeed the same 3 wire serial EEPROM above. They call
it a ‘flash’ device, but indeed it is not. This serial EEPROM is where
the original BIOS for the prometheus lives.


Are you sure about this? The first part number you mentioned (AT93C46)
is described as a 3-wire serial EEPROM, available in sizes of 1k, 2k,
or 4k. I don’t see how this can be the same as the “2 MEG, 16 bit wide
integrated flash memory” described in the docs…

No, I am not sure… You must be right. I am not sure how I got on that
tangent, but obviously what you say makes sense.

This is what I have done:

  1. Using the current bios, I programed the chip select to access the
    window where the flash seems to be
  2. the generic flash driver works. I can see the flash now. It seems
    that is linearly mapped

question:

  1. once I compile the IPL, have the boot image, and have the flash
    filesystem, how do I transfer this to the flash?

I thinks that I use the following:

mkrec => for the IPL
mkifs => for the bootimage
mkefs => for the flahs filesystem

This is correct.

How do I put all of this together in fhash?

Simply ‘cat’ the three images together, creating a single file which
is the total size of the flash. However, the IPL will likely need to
sit at the ‘top’ of the image, with the first instruction of the IPL
lined up with the reset vector. I’d suggest forgetting about the OS
image and EFS image for the time being, and just focus on building
the IPL, positioning it at the correct offset in the flash, and getting
something to appear on screen (or out of a debug serial port).

Thanks…

Miguel.



Thanks for your help…

Regards.

–

David Green (dgreen@qnx.com)
QNX Software Systems Ltd.
http://www.qnx.com

9

Miguel Simon <simon@ou.edu> wrote:

Hi Dave…

Regarding the flash device, it seems to be linearly mapped. I can get it
to boot in DOS. I can get the devf-generic to see the flash and mount
it as /dev/fs0 and /dev/fs0p0. But I cannot erase the flash (the action
fails), nor can I write to it (it blocks).

Some boards have the flash wired with additional control lines to ensure
against accidental erasure. There may be a GPIO line or something similar,
tied to a write protect or write enable pin on the flash, and in addition
to running the flash driver, the GPIO line needs to be asserted in the
correct state to enable writes to the flash. You’ll probably need board
schematics to determine this, or perhaps the source to the DOS utilities
used to write to the flash will indicate what needs to be done.

When I boot in DOS, it does behave as a disk, but I cannot transfer the
.boot image to there because none of the DOS utilities recognize the
file, or complain about something else.

It sounds like the DOS utilities for working with the flash are
restricted to certain operations. It also sounds like you’re close
to having the QNX flash driver working, so if you don’t get anywhere
with the DOS utilities, I’d focus on getting the QNX flash driver
able to erase and write.

Any help is most appreciated.



Here is what I have done (aside to what is above):

  1. got the sc400 BSP source code, adapted the best I knew how,
  2. did the following:

mkrec -s32k -ffull -r ipl-sc400 > ipl-bin.pad
mkrec -ffull -s128k ipl-bin.pad > sc400.rom
cat sc400.rom sc400.rom > sc400_256.rom

  1. changed the build file to have:

[virtual=x86,nobios +compress].bootstrap={
startup-bios -D0x3f.115200 -vvv
PATH=/proc/boot procnto -vv
}

…

  1. mkifs -vv sc400.build sc400.ifs

  2. cat sc400_256.rom sc400.ifs > new.rom

  3. uploaded the new rom to the board using the proper utilities…

  4. …and nothing worked (as expected)

The IPL needs to be located in flash at the correct offset, such
that it will be executed at the reset vector. You’ve placed it
at the bottom of the image, where it won’t be seen or executed.

When you say that you uploaded the image to the board using the
proper utilities, I’m assuming you mean the DOS utilities. Did
you overwrite the BIOS with your image? That’s the only way
this is going to work (once you get the IPL placed correctly
within the image).

As for the stuff below, using ipl-sc400_ext is not correct
for this situation. This is a BIOS extension IPL, which is
intended to be placed into a free area of the BIOS. Some
BIOSes will scan within themselves for BIOS extensions,
such as video BIOSes, etc. The Phoenix BIOS on the SC400
had this capability, so we’d patch the BIOS with an extension
which would be executed after the BIOS had done the other
hardware initialization. Unless you intend to use the BIOS
as the primary boot code (which I suspect you don’t), then
ipl-sc400_ext is not applicable here.

I’d suggest the following:

-forget about the OS image and the EFS image for the time
being. Focus on only generating the IPL code, and padding
it out such that the reset vector appears at the proper
offset within the image.

-put something in the IPL code, as early as possible, to
let you know if it’s executing. Ideally you could put
something out the serial port, but it will be necessary
to initialize the serial port first (note how the sc400
IPL initializes the serial port in _start.S, and then
displays a string out the serial port right away).
Perhaps your hardware has an LED which can be accessed
directly. You could turn on the LED right away in your
IPL, which would let you know if your code is executing
or not.

-study the ‘buildrom’ script in the SC400 IPL, to see
how the reset vector is being generated. Once the
binary IPL is generated, the first call to ‘mkrec’
simply pads that binary out to 32k. The second
call to mkrec is the one that actually generates the
reset vector, which is basically an instruction that
gets placed at the very top of the image, and is a
‘jmp’ instruction to the beginning of the IPL code.

If you look at the sc400.lnk file, you’ll see:
rom : ORIGIN = 0x000f7fe0, LENGTH = 0x2000

If you then look at the x86/o/ipl-sc400.map file,
after you’ve generated the IPL, you’ll see:
Name Origin Length
stack 0x00000000 0x00001000
ram1 0x00001000 0x00001000
rom 0x000f7fe0 0x00002000

So, 0xf7fe0 is where the beginning of the IPL code
will be, in an address space of 1M (which is all that
the x86 CPU can see when it initially boots, in real
mode). Now, once you’ve run the second mkrec command,
it will generate a reset vector to jump to address
0xf7fe0 once the board boots. If you make an IPL
image which is only 128k, it must be placed at the
TOP of the flash. Once you get the flash driver working,
determine where in the 2M flash that the system BIOS
resides (i.e. at the top of the first MEG, at the
top of the second MEG, etc). This will indicate where
in flash your 128k IPL image should sit…



Then… another way…



8. this time I used the ipl-sc400_ext which is the one that we use with
the bios and:

  1. did the following:

mkrec -s32k -ffull -r ipl-sc400_ext > ipl-bin.pad
mkrec -ffull -s128k ipl-bin.pad > sc400.rom

  1. changed the build file to have:

[virtual=x86,bios +compress].bootstrap={
startup-sc400 -D0x3f.115200 -vvv
PATH=/proc/boot procnto -vv
}

  1. cat bios.rom sc400.rom sc400.ifs > new.rom

  2. uploaded the new.rom to the flash… but it did not work either.



    I wonder if you have some suggestions? I appreciate it.

Best regards…

–

David Green (dgreen@qnx.com)
QNX Software Systems Ltd.
http://www.qnx.com

10

Hi Dave…

Thank you so much. I have food to digest now.

A naive question… Is it possible to get QNX going (that is, the build
image) from DOS? Can we force DOS to do this for us? Thanks.

Regards…

Miguel.


Dave Green wrote:

Miguel Simon <> simon@ou.edu> > wrote:

Hi Dave…


Regarding the flash device, it seems to be linearly mapped. I can get it
to boot in DOS. I can get the devf-generic to see the flash and mount
it as /dev/fs0 and /dev/fs0p0. But I cannot erase the flash (the action
fails), nor can I write to it (it blocks).


Some boards have the flash wired with additional control lines to ensure
against accidental erasure. There may be a GPIO line or something similar,
tied to a write protect or write enable pin on the flash, and in addition
to running the flash driver, the GPIO line needs to be asserted in the
correct state to enable writes to the flash. You’ll probably need board
schematics to determine this, or perhaps the source to the DOS utilities
used to write to the flash will indicate what needs to be done.


When I boot in DOS, it does behave as a disk, but I cannot transfer the
.boot image to there because none of the DOS utilities recognize the
file, or complain about something else.


It sounds like the DOS utilities for working with the flash are
restricted to certain operations. It also sounds like you’re close
to having the QNX flash driver working, so if you don’t get anywhere
with the DOS utilities, I’d focus on getting the QNX flash driver
able to erase and write.


Any help is most appreciated.



Here is what I have done (aside to what is above):

\

  1. got the sc400 BSP source code, adapted the best I knew how,
  2. did the following:


    mkrec -s32k -ffull -r ipl-sc400 > ipl-bin.pad
    mkrec -ffull -s128k ipl-bin.pad > sc400.rom
    cat sc400.rom sc400.rom > sc400_256.rom

    \
  3. changed the build file to have:


    [virtual=x86,nobios +compress].bootstrap={
    startup-bios -D0x3f.115200 -vvv
    PATH=/proc/boot procnto -vv
    }


    …

    \
  4. mkifs -vv sc400.build sc400.ifs

    \
  5. cat sc400_256.rom sc400.ifs > new.rom

    \
  6. uploaded the new rom to the board using the proper utilities…

    \
  7. …and nothing worked (as expected)


    The IPL needs to be located in flash at the correct offset, such
    that it will be executed at the reset vector. You’ve placed it
    at the bottom of the image, where it won’t be seen or executed.

When you say that you uploaded the image to the board using the
proper utilities, I’m assuming you mean the DOS utilities. Did
you overwrite the BIOS with your image? That’s the only way
this is going to work (once you get the IPL placed correctly
within the image).

As for the stuff below, using ipl-sc400_ext is not correct
for this situation. This is a BIOS extension IPL, which is
intended to be placed into a free area of the BIOS. Some
BIOSes will scan within themselves for BIOS extensions,
such as video BIOSes, etc. The Phoenix BIOS on the SC400
had this capability, so we’d patch the BIOS with an extension
which would be executed after the BIOS had done the other
hardware initialization. Unless you intend to use the BIOS
as the primary boot code (which I suspect you don’t), then
ipl-sc400_ext is not applicable here.

I’d suggest the following:

-forget about the OS image and the EFS image for the time
being. Focus on only generating the IPL code, and padding
it out such that the reset vector appears at the proper
offset within the image.

-put something in the IPL code, as early as possible, to
let you know if it’s executing. Ideally you could put
something out the serial port, but it will be necessary
to initialize the serial port first (note how the sc400
IPL initializes the serial port in _start.S, and then
displays a string out the serial port right away).
Perhaps your hardware has an LED which can be accessed
directly. You could turn on the LED right away in your
IPL, which would let you know if your code is executing
or not.

-study the ‘buildrom’ script in the SC400 IPL, to see
how the reset vector is being generated. Once the
binary IPL is generated, the first call to ‘mkrec’
simply pads that binary out to 32k. The second
call to mkrec is the one that actually generates the
reset vector, which is basically an instruction that
gets placed at the very top of the image, and is a
‘jmp’ instruction to the beginning of the IPL code.

If you look at the sc400.lnk file, you’ll see:
rom : ORIGIN = 0x000f7fe0, LENGTH = 0x2000

If you then look at the x86/o/ipl-sc400.map file,
after you’ve generated the IPL, you’ll see:
Name Origin Length
stack 0x00000000 0x00001000
ram1 0x00001000 0x00001000
rom 0x000f7fe0 0x00002000

So, 0xf7fe0 is where the beginning of the IPL code
will be, in an address space of 1M (which is all that
the x86 CPU can see when it initially boots, in real
mode). Now, once you’ve run the second mkrec command,
it will generate a reset vector to jump to address
0xf7fe0 once the board boots. If you make an IPL
image which is only 128k, it must be placed at the
TOP of the flash. Once you get the flash driver working,
determine where in the 2M flash that the system BIOS
resides (i.e. at the top of the first MEG, at the
top of the second MEG, etc). This will indicate where
in flash your 128k IPL image should sit…




Then… another way…



8. this time I used the ipl-sc400_ext which is the one that we use with
the bios and:


9. did the following:


mkrec -s32k -ffull -r ipl-sc400_ext > ipl-bin.pad
mkrec -ffull -s128k ipl-bin.pad > sc400.rom


10. changed the build file to have:


[virtual=x86,bios +compress].bootstrap={
startup-sc400 -D0x3f.115200 -vvv
PATH=/proc/boot procnto -vv
}


11. cat bios.rom sc400.rom sc400.ifs > new.rom


12. uploaded the new.rom to the flash… but it did not work either.



I wonder if you have some suggestions? I appreciate it.


Best regards…
\

11

Miguel Simon <simon@ou.edu> wrote:

Hi Dave…

Thank you so much. I have food to digest now.

A naive question… Is it possible to get QNX going (that is, the build
image) from DOS? Can we force DOS to do this for us? Thanks.

You might be able to use the DOS utilities to copy the image to
flash, but that’s about it.

Regards…

Miguel.



Dave Green wrote:
Miguel Simon <> simon@ou.edu> > wrote:

Hi Dave…


Regarding the flash device, it seems to be linearly mapped. I can get it
to boot in DOS. I can get the devf-generic to see the flash and mount
it as /dev/fs0 and /dev/fs0p0. But I cannot erase the flash (the action
fails), nor can I write to it (it blocks).


Some boards have the flash wired with additional control lines to ensure
against accidental erasure. There may be a GPIO line or something similar,
tied to a write protect or write enable pin on the flash, and in addition
to running the flash driver, the GPIO line needs to be asserted in the
correct state to enable writes to the flash. You’ll probably need board
schematics to determine this, or perhaps the source to the DOS utilities
used to write to the flash will indicate what needs to be done.


When I boot in DOS, it does behave as a disk, but I cannot transfer the
.boot image to there because none of the DOS utilities recognize the
file, or complain about something else.


It sounds like the DOS utilities for working with the flash are
restricted to certain operations. It also sounds like you’re close
to having the QNX flash driver working, so if you don’t get anywhere
with the DOS utilities, I’d focus on getting the QNX flash driver
able to erase and write.


Any help is most appreciated.



Here is what I have done (aside to what is above):

\

  1. got the sc400 BSP source code, adapted the best I knew how,
  2. did the following:


    mkrec -s32k -ffull -r ipl-sc400 > ipl-bin.pad
    mkrec -ffull -s128k ipl-bin.pad > sc400.rom
    cat sc400.rom sc400.rom > sc400_256.rom

    \
  3. changed the build file to have:


    [virtual=x86,nobios +compress].bootstrap={
    startup-bios -D0x3f.115200 -vvv
    PATH=/proc/boot procnto -vv
    }


    …

    \
  4. mkifs -vv sc400.build sc400.ifs

    \
  5. cat sc400_256.rom sc400.ifs > new.rom

    \
  6. uploaded the new rom to the board using the proper utilities…

    \
  7. …and nothing worked (as expected)


    The IPL needs to be located in flash at the correct offset, such
    that it will be executed at the reset vector. You’ve placed it
    at the bottom of the image, where it won’t be seen or executed.

When you say that you uploaded the image to the board using the
proper utilities, I’m assuming you mean the DOS utilities. Did
you overwrite the BIOS with your image? That’s the only way
this is going to work (once you get the IPL placed correctly
within the image).

As for the stuff below, using ipl-sc400_ext is not correct
for this situation. This is a BIOS extension IPL, which is
intended to be placed into a free area of the BIOS. Some
BIOSes will scan within themselves for BIOS extensions,
such as video BIOSes, etc. The Phoenix BIOS on the SC400
had this capability, so we’d patch the BIOS with an extension
which would be executed after the BIOS had done the other
hardware initialization. Unless you intend to use the BIOS
as the primary boot code (which I suspect you don’t), then
ipl-sc400_ext is not applicable here.

I’d suggest the following:

-forget about the OS image and the EFS image for the time
being. Focus on only generating the IPL code, and padding
it out such that the reset vector appears at the proper
offset within the image.

-put something in the IPL code, as early as possible, to
let you know if it’s executing. Ideally you could put
something out the serial port, but it will be necessary
to initialize the serial port first (note how the sc400
IPL initializes the serial port in _start.S, and then
displays a string out the serial port right away).
Perhaps your hardware has an LED which can be accessed
directly. You could turn on the LED right away in your
IPL, which would let you know if your code is executing
or not.

-study the ‘buildrom’ script in the SC400 IPL, to see
how the reset vector is being generated. Once the
binary IPL is generated, the first call to ‘mkrec’
simply pads that binary out to 32k. The second
call to mkrec is the one that actually generates the
reset vector, which is basically an instruction that
gets placed at the very top of the image, and is a
‘jmp’ instruction to the beginning of the IPL code.

If you look at the sc400.lnk file, you’ll see:
rom : ORIGIN = 0x000f7fe0, LENGTH = 0x2000

If you then look at the x86/o/ipl-sc400.map file,
after you’ve generated the IPL, you’ll see:
Name Origin Length
stack 0x00000000 0x00001000
ram1 0x00001000 0x00001000
rom 0x000f7fe0 0x00002000

So, 0xf7fe0 is where the beginning of the IPL code
will be, in an address space of 1M (which is all that
the x86 CPU can see when it initially boots, in real
mode). Now, once you’ve run the second mkrec command,
it will generate a reset vector to jump to address
0xf7fe0 once the board boots. If you make an IPL
image which is only 128k, it must be placed at the
TOP of the flash. Once you get the flash driver working,
determine where in the 2M flash that the system BIOS
resides (i.e. at the top of the first MEG, at the
top of the second MEG, etc). This will indicate where
in flash your 128k IPL image should sit…




Then… another way…



8. this time I used the ipl-sc400_ext which is the one that we use with
the bios and:


9. did the following:


mkrec -s32k -ffull -r ipl-sc400_ext > ipl-bin.pad
mkrec -ffull -s128k ipl-bin.pad > sc400.rom


10. changed the build file to have:


[virtual=x86,bios +compress].bootstrap={
startup-sc400 -D0x3f.115200 -vvv
PATH=/proc/boot procnto -vv
}


11. cat bios.rom sc400.rom sc400.ifs > new.rom


12. uploaded the new.rom to the flash… but it did not work either.



I wonder if you have some suggestions? I appreciate it.


Best regards…

\

–

David Green (dgreen@qnx.com)
QNX Software Systems Ltd.
http://www.qnx.com

12

Hi Dave…

Can I use loadqnx.sys from DOS?

Where can I find a copy of loadqnx.sys? If this works, this will be a
quick and dirty way, and then, with time, I can do the IPL the correct way.

Thanks.

Regards…

Miguel.

13

Miguel Simon <simon@ou.edu> wrote:

Hi Dave…

Can I use loadqnx.sys from DOS?

http://www.openqnx.com/Article213.html
has a link to the loadqnx.sys
it works for Windows 9X, don’t know about DOS.
But I had success using GRUB with DOS, Win2k, WinXP, Linux,
or any OSes that supports FAT.

Where can I find a copy of loadqnx.sys? If this works, this will be a
quick and dirty way, and then, with time, I can do the IPL the correct way.

14

Hi Frank…

Thanks. I got it, and it works all right. Thanks.

Regards…

Miguel.


Frank Liu wrote:

Miguel Simon <> simon@ou.edu> > wrote:

Hi Dave…

Can I use loadqnx.sys from DOS?


http://www.openqnx.com/Article213.html
has a link to the loadqnx.sys
it works for Windows 9X, don’t know about DOS.
But I had success using GRUB with DOS, Win2k, WinXP, Linux,
or any OSes that supports FAT.


Where can I find a copy of loadqnx.sys? If this works, this will be a
quick and dirty way, and then, with time, I can do the IPL the correct way.

15

Hi Dave…

I will follow your suggestions, and I am sure that I will have more
questions. At least I understand a little better. I appreciate your help
greatly. Thanks.

Regards…

Miguel.

Dave Green wrote:

Miguel Simon <> simon@ou.edu> > wrote:

Hi…


The correct ‘flash’ device for the Prometheus board is AT93C46. This is
a EEPROM device. Do we have drivers for EEPROM devices? How would I
write an IPL for this type of device? Thanks.


When you say ‘IPL’, do you mean Initial Program Loader, that is, the
very first code that will execute when power is applied? If so, then
the IPL doesn’t care what type of device it’s executed out of, as long
as the device is seen by the CPU as linear memory. The device that
you’ve named is a 3 wire serial EEPROM, which is not linear memory,
so it can’t be used as the primary boot device for the board.

If this is the same Prometheus board that you were asking about
in an earlier thread, it appears that the only boot device on
this board is the 2M flash which stores the BIOS, and has free
space for user applications. If you want to eliminate the BIOS
altogether, and write a native QNX IPL for this board, it will
likely involve erasing the BIOS image, and placing your IPL code
there instead. This may not be as scary as it sounds -the docs
indicate that there is a command interpreter built into the CPU
that can be used to reprogram the BIOS, should it get erased or
become corrupted.

We don’t have a generic driver to program serial EEPROM devices,
so you’d have to write a small program to interface with it,
as per the spec sheet for the device. For the 2M flash, if it is mapped
linearly, then there’s a good chance that our generic flash driver,
devf-generic, would work. If not, a dedicated flash driver for this
component would be fairly straightforward, using an existing flash
driver source as a starting point. If the flash is paged (that is,
only a small 8k or 16k window of the flash is visible at any given
time), then a custom flash driver is definitely necessary.

Note that you don’t need a flash driver to run QNX on the board;
the IPL could be made to load an OS image serially, directly to
memory, or to copy an OS image from flash to DRAM. However, you
may need a flash driver to program the IPL and OS image into
flash in the first place, if the utilities that come with the
board aren’t capable of doing that.



Regards…


Miguel.


Link to device:


http://www.atmel.com/dyn/products/product_card.asp?family_id=647&family_name=Serial+EEPROM&part_id=1913





Miguel Simon wrote:

Hi…

I wonder which IPL sample applies for the Atmel and AMD flash devices?
These devices are sector based devices. How do I get information
regarding where the flash resides in memory? I I know this, I could use
the generic flash.

http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/22288.pdf

http://www.atmel.com/dyn/resources/prod_documents/DOC0518.PDF



Thanks.

Regards…

Miguel.


\