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:
-
boot-nobios ends without evident problems and pass control
through a IRET to Proc32. -
After a while we find Proc32 in an end-less loop with interrupt
flag disabled. -
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
Enrico
The build file of the kernel is (we attempted several variations):
sys/boot-nobios
$ boot-nobios -A -I -O -V -P -d -f -t -g-1 -M 100000,1F00000
sys/Proc32
$ Proc32 -l 2 -P 27
sys/Slib32
$ Slib32
sys/Slib16
$ Slib16
/bin/Net
$ Net -n 3 -T
/bin/Net.ether82557
$ Net.ether82557 -p F000 -i 5
/bin/sinit
$ sinit -r //1/ TERM=qnx TZ=$(TZ)