Stalemate in booting QNX on an Embedded card

We are using latest QNX 4.25 with patch D.

We are going to boot QNX on a embedded card with:

  • Pentium 166 with Intel TX and PIIX4 chip set without any
    other standard PC peripheral component (serial, video,
    keyboard controller, disk, etc…)

  • PCI bus is connected to an Intel 82558 Ethernet controller

  • No bios present (neither basic nor pci) but the card is
    equipped with a custom firmware that we can partially handle

  • The custom firmware at the beginning programs the parameters
    of the pci interface of the 82558

  • We are using an ICE with Jtag for this work

  • We customized etherboot on the card and we are able to load QNX
    from a bootpd server on the network.

  • The PIC and the PIT are placed at the standard addresses, and
    the clock has normal PC frequency, so on the paper I did
    not expect to find any problem, especially with Proc32 that
    is finding something wrong.

  • I suppose that Proc32 find some inconsistency so it decides
    to stop and to attempt rebooting. I would like to discover the
    cause in order to properly adapt the firmware before jumping
    from Etherboot to QNX.

More in details:

  • I attach the build file of the kernel we are using.

  • We traced the initialization sequence of the kernel and we
    verified that:

  1. boot-nobios ends without evident problems and pass control
    through a IRET to Proc32.

  2. After a while we find Proc32 in an end-less loop with interrupt
    flag disabled.

  3. By means of several tests and checks of the stack we verified that:

The loop is at address:

  • 18:1A58 that belongs to the function starting at 18:1954, it seems
    to be the code that is attempting to reboot the system
  • The function is called from 18:E60 that seems to be the common
    part of the exception handler starting from 18:E0A.
  • The exception code is 0xD (ACCVIOL)
  • The source point of the exception is at F0:15734 where I find
    an INT F3, that causes ACCVIOL because it is out of the current
    IDT limit.
  • F0:15734 belongs to a function starting from F0:15725 that
    is called from F0:63E6
  • F0:63E6 belongs to a function starting from F0:63D2 that is
    called from F0:650B
  • F0:650B belongs to a function starting from F0:6481 that is
    called from F0:665D

I hope it is enough for you to understand what it is happening
and to give us the proper suggestions.

Thanks in advance

The build file of the kernel is (we attempted several variations):

$ boot-nobios -A -I -O -V -P -d -f -t -g-1 -M 100000,1F00000

$ Proc32 -l 2 -P 27

$ Slib32

$ Slib16

$ Net -n 3 -T

$ Net.ether82557 -p F000 -i 5

$ sinit -r //1/ TERM=qnx TZ=$(TZ)

| Enrico Bendinelli | Prisma Engineering srl |
| | Via Petrocchi 4 20127 MILANO ITALY |
| | Tel. +39 02 26113507 Fax. 26113597 |

In order to discover the reason of the problem of my previous
message, we tried to run a kernel based on boot-nobios but on
a standard PC card and using netboot.

We created two kernels where the only change was using
boot-nobios instead of boot.

The kernel generated with normal boot always works fine, the
one generated with boot-nobios hangs at the initialization
without any diagnostic.

We tried the same couple of tests changing the other options
for boot or boot-nobios and we were never able to have the
second one working.

So we are going to go back with boot in the activity project and
to develop some bios stubs in order to finally have QNX working.

I would like to a have a clarification of this question.

Does some new version of boot-nobios exist ?


| Enrico Bendinelli | Prisma Engineering srl |
| | Via Petrocchi 4 20127 MILANO ITALY |
| | Tel. +39 02 26113507 Fax. 26113597 |