system page importation and variables

QNX Newsgroups (Archives) qnx.bsp
1

Hello!

This is a re-post of a question from a month ago or so:

We have an i486-type embedded system(s) which run QNX/Neutrino/Momentics
6.2. I am attempting to develop the necessary code and methdology
to dispense with the BIOS (and associated probing) to allow for
faster boots and a greater level of embedding.

I am currently working on the startup program, the IPL being
finished or nearly so.

I am attempting to determine the best way to load parameters
into the system page. I have the parameters, but I am not
sure what variable names (or equivalent) I should use to load
the page. Also, if the structures in the page are dynamic,
I am not sure how to set their sizes. I have been and continue
to study the documentation on the system, however, I would
love to hear from someone who has done this before and might
be able to supply some additonal information.

Thank you.

Richard B.

2

Richard Bonomo,6289 Chamberlin,263-4683, <bonomo@sal.wisc.edu> wrote:

Hello!

This is a re-post of a question from a month ago or so:

We have an i486-type embedded system(s) which run QNX/Neutrino/Momentics
6.2. I am attempting to develop the necessary code and methdology
to dispense with the BIOS (and associated probing) to allow for
faster boots and a greater level of embedding.

I am currently working on the startup program, the IPL being
finished or nearly so.

I am attempting to determine the best way to load parameters
into the system page. I have the parameters, but I am not
sure what variable names (or equivalent) I should use to load
the page. Also, if the structures in the page are dynamic,
I am not sure how to set their sizes. I have been and continue
to study the documentation on the system, however, I would
love to hear from someone who has done this before and might
be able to supply some additonal information.

Hi Richard,

Sorry about the late reply.

Which documentation have you been looking at? In the following
docs:

“Building Embedded Systems”
→ “Customizing Image Startup Programs”
→ “Structure of the System Page”
→ “The Startup Library”

…there are quite detailed descriptions of the various system
page structures, as well as the functions that can be used to
initialize and populate the system page. Aside from this documentation,
I think your best bet would be to examine the startup code for boards
which have already been done.

As for the sizes of the various syspage structures, it’s not something
you normally need to worry about. For example, the intrinfo section of
the syspage will grow depending on the number of entries you have in
your init_intrinfo() routine, but the structure size of each entry is fixed,
so you don’t actually need to specify a size anywhere.

If you have questions about startup or the syspage that you can’t find
the answer to in the docs described above, then we’ll try to answer it
here; however, you may need to make your questions a bit more specific…
for example, which parameters are you attempting to load into the syspage?

\

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

3

Dave Green wrote:

Richard Bonomo,6289 Chamberlin,263-4683, <> bonomo@sal.wisc.edu> > wrote:
Hello!

This is a re-post of a question from a month ago or so:

We have an i486-type embedded system(s) which run QNX/Neutrino/Momentics
6.2. I am attempting to develop the necessary code and methdology
to dispense with the BIOS (and associated probing) to allow for
faster boots and a greater level of embedding.

I am currently working on the startup program, the IPL being
finished or nearly so.

I am attempting to determine the best way to load parameters
into the system page. I have the parameters, but I am not
sure what variable names (or equivalent) I should use to load
the page. Also, if the structures in the page are dynamic,
I am not sure how to set their sizes. I have been and continue
to study the documentation on the system, however, I would
love to hear from someone who has done this before and might
be able to supply some additonal information.

Hi Richard,

Sorry about the late reply.

Which documentation have you been looking at? In the following
docs:

“Building Embedded Systems”
→ “Customizing Image Startup Programs”
→ “Structure of the System Page”
→ “The Startup Library”

Yes, I have been studying that. (It has been a while now, so
my recollection may be hazy.)

…there are quite detailed descriptions of the various system
page structures, as well as the functions that can be used to
initialize and populate the system page. Aside from this documentation,
I think your best bet would be to examine the startup code for boards
which have already been done.

I haven’t seen much in the way of startup code for BIOS-less x86 systems,
at least not that we have (QNX 6.2 Momentics). Perhaps more BSP’s have
been issued?

As for the sizes of the various syspage structures, it’s not something
you normally need to worry about. For example, the intrinfo section of
the syspage will grow depending on the number of entries you have in
your init_intrinfo() routine, but the structure size of each entry is
fixed, so you don’t actually need to specify a size anywhere.

If you have questions about startup or the syspage that you can’t find
the answer to in the docs described above, then we’ll try to answer it
here; however, you may need to make your questions a bit more specific…
for example, which parameters are you attempting to load into the syspage?

I am attempting to directly load parameters from these (see after
this for a code snippet):
************ syspage.txt start *********
Header size=0x009c, Total Size=0x08d8, #Cpu=1, Type=0
Section:system_private offset:0x01d0 size:0x0068
syspage ptr user:ff511000 kernel:ff512000
cpupage ptr user:ff511b10 kernel:ff512b10 spacing:32
kdebug info:00000000 callback:00000000
boot pgms: idx=0
0) base paddr:0040c000 start addr:ff80d504
ramsize:01f96400 pagesize:00001000
Section:qtime offset:0x0130 size:0x0048
boot:4059c076 CPS:0000000000123565 rate/scale:838095345/-15 intr:0
Section:callout offset:0x00a0 size:0x0048
reboot:ff5129f0 power:00000000
timer_load:ff512a1a reload:00000000 value:ff512a41
0) display:ff512a5a poll:ff512a76 break:ff512a93

  1. display:00000000 poll:00000000 break:00000000
    Section:cpuinfo offset:0x0178 size:0x0020
  2. cpu:000001e6 flags:c000001d speed:00000042 cache i/d:255/255 name:83
    Section:cacheattr offset:0x08d8 size:0x0000
    Section:meminfo offset:0x0238 size:0x0070
    t:1 a:00001000 s:0000b000 t:1 a:00011f90 s:00084470 t:1 a:00100000
    s:0030b4d8
    t:2 a:0040b4d8 s:0017cd90 t:3 a:0040b4d8 s:0017cd90 t:1 a:00588268
    s:01a77d98
    Section:asinfo offset:0x05b8 size:0x01e0
  3. 00000000-0000ffff o:ffff a:0000 p:100 c:00000000 n:21
  4. 00000000-ffffffff o:ffff a:0010 p:100 c:00000000 n:24
  5. 00000000-00ffffff o:0020 a:0010 p:100 c:00000000 n:31
  6. 06000000-ffefffff o:0020 a:0003 p:100 c:00000000 n:35
  7. fff00000-ffffffff o:0020 a:0005 p:100 c:00000000 n:42
    00a0) 00000000-000963ff o:0040 a:0017 p:100 c:00000000 n:46
    00c0) 00100000-00ffffff o:0040 a:0037 p:100 c:00000000 n:46
    00e0) 01000000-01ffffff o:0020 a:0017 p:100 c:00000000 n:46
  8. 0040b4d8-00588267 o:0020 a:0005 p:100 c:00000000 n:178
  9. 0040b4d8-00588267 o:0020 a:0007 p:100 c:00000000 n:186
  10. 00001000-0000bfff o:00a0 a:0007 p:100 c:00000000 n:194
  11. 00011f90-000963ff o:00a0 a:0007 p:100 c:00000000 n:194
  12. 00100000-0040b4d7 o:00c0 a:0007 p:100 c:00000000 n:194
    01a0) 00588268-00ffffff o:00c0 a:0027 p:100 c:00000000 n:194
    01c0) 01000000-01ffffff o:00e0 a:0007 p:100 c:00000000 n:194
    Section:hwinfo offset:0x0398 size:0x0220
  13. size:3 tag:3 isize:3, iname:0, owner:65535, kids:2
  14. size:3 tag:17 isize:3, iname:9, owner:0, kids:2
  15. size:3 tag:3 isize:3, iname:50, owner:12, kids:1
  16. size:4 tag:63 isize:11, iname:54, owner:24, kids:0
    00 00 00 00
  17. size:1 tag:70
  18. size:6 tag:74
    02 00 00 00 70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  19. size:3 tag:17 isize:3, iname:31, owner:0, kids:4
  20. size:3 tag:3 isize:7, iname:106, owner:80, kids:0
  21. size:4 tag:111
    00 09 10 00 eb 03 09 00 a0 33 02 00
  22. size:3 tag:3 isize:3, iname:124, owner:80, kids:1
  23. size:4 tag:63 isize:13, iname:129, owner:120, kids:0
    00 00 00 00
  24. size:2 tag:135
    01 00 00 00
  25. size:1 tag:70
  26. size:6 tag:74
    05 00 00 00 60 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  27. size:3 tag:3 isize:3, iname:139, owner:80, kids:1
  28. size:4 tag:63 isize:21, iname:146, owner:184, kids:0
    00 00 00 00
  29. size:2 tag:135
    04 00 00 00
  30. size:1 tag:70
  31. size:6 tag:74
    07 00 00 00 f8 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  32. size:2 tag:135
    03 00 00 00
  33. size:6 tag:74
    07 00 00 00 f8 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  34. size:3 tag:3 isize:3, iname:151, owner:80, kids:1
  35. size:4 tag:63 isize:11, iname:160, owner:280, kids:0
    00 00 00 00
  36. size:1 tag:70
  37. size:6 tag:74
    07 00 00 00 78 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  38. size:3 tag:3 isize:3, iname:124, owner:12, kids:1
  39. size:4 tag:63 isize:33, iname:171, owner:336, kids:0
    00 00 00 00
  40. size:1 tag:70
  41. size:6 tag:74
    00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  42. size:6 tag:74
    00 01 00 00 00 ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  43. size:6 tag:74
    00 40 03 00 00 00 0a 00 00 00 00 00 00 00 20 00 00 00 00 00
  44. size:6 tag:74
    00 a0 02 00 00 60 0d 00 00 00 00 00 00 00 20 00 00 00 00 00
  45. size:2 tag:135
    0e 00 00 00
  46. size:2 tag:135
    0f 00 00 00
    Section:typed_strings offset:0x02a8 size:0x0020
    off:0 type:2 string:‘st5ka’
    off:12 type:5 string:‘x86pc’
    Section:strings offset:0x02c8 size:0x00d0
    [0]‘hw’ [3]‘Group’ [9]‘unknown’ [17]‘Bus’ [21]‘io’ [24]‘memory’ [31]‘isa’
    [35]‘device’ [42]‘rom’ [46]‘ram’ [50]‘rtc’ [54]‘mc146818’ [63]‘Device’
    [70]‘pad’ [74]‘location’ [83]‘AMD486DX2WT Stepping 4’ [106]‘disk’
    [111]‘diskgeometry’ [124]‘misc’ [129]‘pckbd’ [135]‘irq’ [139]‘serial’
    [146]‘8250’ [151]‘parallel’ [160]‘centronics’ [171]‘in-use’ [178]‘imagefs’
    [186]‘bootram’ [194]‘sysram’
    Section:intrinfo offset:0x0798 size:0x0140
  47. vector_base:00000000, #vectors:7, cascade_vector:7fffffff
    cpu_intr_base:00000030, cpu_intr_stride:1, flags:0000
    id => flags:0800, size:0000, rtn:ff5128d8
    eoi => flags:0000, size:0004, rtn:ff5128d8
    mask:ff5128dc, unmask:ff5128ed, config:00000000
  48. vector_base:00000007, #vectors:1, cascade_vector:7fffffff
    cpu_intr_base:00000037, cpu_intr_stride:1, flags:0000
    id => flags:0000, size:000b, rtn:ff512900
    eoi => flags:0000, size:0004, rtn:ff51290b
    mask:ff51290f, unmask:ff512918, config:00000000
  49. vector_base:00000008, #vectors:7, cascade_vector:7fffffff
    cpu_intr_base:00000038, cpu_intr_stride:1, flags:0000
    id => flags:0800, size:0004, rtn:ff512921
    eoi => flags:0000, size:0004, rtn:ff512925
    mask:ff512929, unmask:ff51293a, config:00000000
  50. vector_base:0000000f, #vectors:1, cascade_vector:7fffffff
    cpu_intr_base:0000003f, cpu_intr_stride:1, flags:0000
    id => flags:0000, size:000f, rtn:ff51294d
    eoi => flags:0000, size:0004, rtn:ff51295c
    mask:ff512960, unmask:ff512969, config:00000000
  51. vector_base:80000000, #vectors:2, cascade_vector:7fffffff
    cpu_intr_base:00000002, cpu_intr_stride:0, flags:a000
    id => flags:0000, size:001b, rtn:ff512972
    eoi => flags:1000, size:002a, rtn:ff51298d
    mask:ff5129b7, unmask:ff5129cb, config:ff5129e1
    Section:boxinfo offset:0x0198 size:0x0028
    hw_flags:00000440
    Section:diskinfo offset:0x01c0 size:0x0010
  52. cyls:03eb heads:0010 sectors:0009 nblocks:000233a0
    Section:smpinfo offset:0x08d8 size:0x0000
    Section:gdt offset:0x0068
    base:ff512b30
    off:00 base:1a873b49 limit:ca8c0fff off:08 base:ff512b30 limit:0000013f
    off:10 base:ff511c70 limit:0000031f off:18 base:f3a3d251 limit:000e0536
    off:20 base:ff511b10 limit:0000001f off:28 base:76bc55e5 limit:00091b83
    off:30 base:dbfa7746 limit:8d027fff off:38 base:6d8bf796 limit:12135fff
    off:40 base:dd52b62b limit:c03d0fff off:48 base:3d29b857 limit:f502afff
    off:50 base:e174d976 limit:000001bf off:58 base:74d862f2 limit:00030807
    off:60 base:305f0f2c limit:0002893a off:68 base:8eb4148e limit:000b660a
    off:70 base:171d1ede limit:000ba886 off:78 base:ff400000 limit:00000fff
    off:80 base:00000000 limit:ffffffff off:88 base:00000000 limit:ffffffff
    off:90 base:00000000 limit:ffffffff off:98 base:00000000 limit:ffffffff
    off:a0 base:ff512bd8 limit:00000027 off:a8 base:8d4e1dd9 limit:0004b621
    off:b0 base:0d09e3a8 limit:1b54ffff off:b8 base:02164b7b limit:00025a8b
    off:c0 base:00000000 limit:ffffffff off:c8 base:00000000 limit:ffffffff
    off:d0 base:c97a9c15 limit:000474b1 off:d8 base:2ac2bf56 limit:0005dc2a
    off:e0 base:00000000 limit:ffffffff off:e8 base:00000000 limit:ffffffff
    off:f0 base:00000000 limit:ffffffff off:f8 base:00000000 limit:ffffffff
    Section:idt offset:0x006c
    base:ff512c70
    Section:pgdir offset:0x0070
    Page Directory 0000c000
    0001-0000e007 03fd-0000d007 03fe-0000f007 03ff-0000c005

System page at phys:00011000 user:ff511000 kern:ff512000
Starting next program at vff80d504
***************** syspage.txt end *************************

Here is a code snippet from main.c to demonstrate what I am attempting.
I realize that I may be completely wrong in determining the
variables used to load the system page structures. That is one
reason I have been asking around…

****************** source program snippet from startup main.c ****

//
// In a virtual system we need to initialize the page tables
//

if(shdr->flags1 & STARTUP_HDR_FLAGS1_VIRTUAL) init_mmu();
/*
OK, we are going to cheat big time here. Rather than try to re-write all
the initialization functions for the RTD-PC104 board, we will simply load
the system page with values gleaned from the running system. Of course,
this means the startup program may have to be modified if the hardware is
altered. I may try to generalize this a bit later if it seems warranted.
RLB 3/2004

Skip the next several lines.
//
---------------------------------------------------------------------//
//
//
// The following routines have hardware or system dependancies
which //
// may need to be changed on a non-PC compatible system. The
default //
// routines assume a BIOS is present. If you do not have a bios you
//
// will need to replace these routines with ones of your own.
//
//
//
init_intrinfo();
init_qtime();
init_cacheattr();
init_cpuinfo();
init_hwinfo();
add_string("/cfg/bus/pci=bios");
add_typed_string(_CS_MACHINE, “AMDSC400”);
//
//
//
---------------------------------------------------------------------//
Insert the appropriate system page entries here: */

/* instead of init_intrinfo (offset = 0x0798, size = 0x0140) /
lsp.intrinfo.offset = 0x0798;
lsp.intrinfo.size = 0x0140;
lsp.intrinfo.0.vector_base = 0x0;
lsp.intrinfo.0.num_vectors = 0x7;
lsp.intrinfo.0.cascade_vector = 0x7fffffff;
lsp.intrinfo.0.cpu_intr_base = 0x30;
lsp.intrinfo.0.cpu_intr_stride = 0x1;
lsp.intrinfo.0.flags = 0x0;
lsp.intrinfo.0.id.genflags = 0x800;
lsp.intrinfo.0.id.size = 0x0;
lsp.intrinfo.0.id.rtn = 0xff5128d8;
lsp.intrinfo.0.eoi.genflags = 0x0;
lsp.intrinfo.0.eoi.size = 0x4;
lsp.intrinfo.0.eoi.rtn = 0xff5128d8;
lsp.intrinfo.0.mask = ff5128dc;
lsp.intrinfo.0.unmask = ff5128ed;
lsp.intrinfo.0.config = 0x0;
/ /
/ /
lsp.intrinfo.1.vector_base = 0x7;
lsp.intrinfo.1.num_vectors = 0x1;
lsp.intrinfo.1.cascade_vector = 0x7fffffff;
lsp.intrinfo.1.cpu_intr_base = 0x37;
lsp.intrinfo.1.cpu_intr_stride = 0x1;
lsp.intrinfo.1.flags = 0x0;
lsp.intrinfo.1.id.genflags = 0x0;
lsp.intrinfo.1.id.size = 0xb;
lsp.intrinfo.1.id.rtn = ff512900;
lsp.intrinfo.1.eoi.genflags = 0x0;
lsp.intrinfo.1.eoi.size = 0x4;
lsp.intrinfo.1.eoi.rtn = 0xff51290b;
lsp.intrinfo.1.mask = 0xff51290f;
lsp.intrinfo.1.unmask = 0xff512918;
lsp.intrinfo.1.config = 0x0;
/ /
lsp.intrinfo.2.vector_base = 0x8;
lsp.intrinfo.2.num_vectors = 0x7;
lsp.intrinfo.2.cascade_vector = 0x7fffffff;
lsp.intrinfo.2.cpu_intr_base = 0x38;
lsp.intrinfo.2.cpu_intr_stride = 0x1;
lsp.intrinfo.2.flags = 0x0;
lsp.intrinfo.2.id.genflags = 0x800;
lsp.intrinfo.2.id.size = 0x4;
lsp.intrinfo.2.id.rtn = 0xff512921;
lsp.intrinfo.2.eoi.genflags = 0x0;
lsp.intrinfo.2.eoi.size = 0x4;
lsp.intrinfo.2.eoi.rtn = 0xff512925;
lsp.intrinfo.2.mask = 0xff512929;
lsp.intrinfo.2.unmask = 0xff51293a;
lsp.intrinfo.2.config = 0x0;
/ /
lsp.intrinfo.3.vector_base = 0xf;
lsp.intrinfo.3.num_vectors = 0x1;
lsp.intrinfo.3.cascade_vector = 0x7fffffff;
lsp.intrinfo.3.cpu_intr_base = 0x3f;
lsp.intrinfo.3.cpu_intr_stride = 0x1;
lsp.intrinfo.3.flags = 0x0;
lsp.intrinfo.3.id.genflags = 0x0;
lsp.intrinfo.3.id.size = 0xf;
lsp.intrinfo.3.id.rtn = 0xff51294d;
lsp.intrinfo.3.eoi.genflags = 0x0;
lsp.intrinfo.3.eoi.size = 0x4;
lsp.intrinfo.3.eoi.rtn = ff51295c;
lsp.intrinfo.3.mask = ff512960;
lsp.intrinfo.3.unmask = ff512969;
lsp.intrinfo.3.config = 0x0;
/ /
lsp.intrinfo.4.vector_base = 0x80000000;
lsp.intrinfo.4.num_vectors = 0x2;
lsp.intrinfo.4.cascade_vector = 0x7fffffff;
lsp.intrinfo.4.cpu_intr_base = 0x2;
lsp.intrinfo.4.cpu_intr_stride = 0x0;
lsp.intrinfo.4.flags = 0xa000;
lsp.intrinfo.4.id.genflags = 0x0;
lsp.intrinfo.4.id.size = 0x1b;
lsp.intrinfo.4.id.rtn = 0xff512972;
lsp.intrinfo.4.eoi.genflags = 0x1000;
lsp.intrinfo.4.eoi.size = 0x2a;
lsp.intrinfo.4.eoi.rtn = 0xff51298d;
lsp.intrinfo.4.mask = 0xff5129b7;
lsp.intrinfo.4.unmask = 0xff5129cb;
lsp.intrinfo.4.config = 0xff5129e1;
/ /
/ instead of init_qtime (offset = 0x0130, size = 0x0048) */
lsp.qtime.boot_time = 405c076;
lsp.qtime.cycles_per_second = 0000000000123565;
lsp.qtime.timer_rate = 838095345;
lsp.qtime.timer_scale = 15;
lsp.qtime.intr = 0;

/* instead of cacheattr (offset = 0x08d8, size = 0) */

******************** end of source code snippet *************

Will this approach work?
What is the proper way to reference the system page structures
when attemmpting a direct load in this way?

Thank you!

Richard B.

4

Richard Bonomo,6289 Chamberlin,263-4683, <bonomo@sal.wisc.edu> wrote:

[snip]

Will this approach work?

I’m doubtful that this could be made to work; at the very least, it would
be a delicate juggling act - any one change will affect the (hard-coded) offsets
of everything that comes after it. I definitely wouldn’t recommend this
approach.

What is the proper way to reference the system page structures
when attemmpting a direct load in this way?

I don’t think it’s ever been done before, so there really is no
‘proper’ way… I’m not sure I understand why you are approaching it
this way - a startup for a non-BIOS x86 system is done the same way
as for any other platform - why don’t you want to just use the normal
startup library calls to populate the syspage?

Thank you!

Richard B.

–

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

5

Dave Green wrote:

Richard Bonomo,6289 Chamberlin,263-4683, <> bonomo@sal.wisc.edu> > wrote:

[snip]

Will this approach work?

I’m doubtful that this could be made to work; at the very least, it would
be a delicate juggling act - any one change will affect the (hard-coded)
offsets of everything that comes after it. I definitely wouldn’t recommend
this approach.

What is the proper way to reference the system page structures
when attemmpting a direct load in this way?

I don’t think it’s ever been done before, so there really is no
‘proper’ way… I’m not sure I understand why you are approaching it
this way - a startup for a non-BIOS x86 system is done the same way
as for any other platform - why don’t you want to just use the normal
startup library calls to populate the syspage?

Thank you!

Richard B.
\

I am perhaps being naive! Since there is to be no BIOS, so I need to
have some way of populating the system page without recourse to the
BIOS probes that some of the startup library calls use. The only “example”
for x86 systems that bsp-6.2.0 has is the sc400. It does have some
material for non-BIOS IPL, but the startup source program main.c has
a notation that the calls it makes assumes a BIOS is present, and, if you
don’t have one, you must substitute your own. Having no examples to
work from, it seemed to me that the most straight-forward thing to do would
be to simply load the system page variables with the appropriate values,
all of which are known.

Does this answer your question?
What [totally obvious to everyone else thing] am I missing here?
Is the bsp I have loaded somehow incomplete?

Rich

6

Have you looked at ‘Embedded BIOS’ from General Software? Depending on your
needs, it may make your life a lot easier. They claim it has been used in CE
devices with boot time at around 1 sec.

The way it works is you get a ‘BIOS kit’ with some sort of ‘tuning’
application. You tune it for your specific hardware and the tool generates a
custom BIOS that’s just good enough to boot your particular target (rather
than being generic bloated slow typical BIOS).

– igor

“Richard Bonomo,6289 Chamberlin,263-4683,” <bonomo@sal.wisc.edu> wrote in
message news:d8ngm7$b35$1@inn.qnx.com…

Dave Green wrote:

Richard Bonomo,6289 Chamberlin,263-4683, <> bonomo@sal.wisc.edu> > wrote:

[snip]

Will this approach work?

I’m doubtful that this could be made to work; at the very least, it would
be a delicate juggling act - any one change will affect the (hard-coded)
offsets of everything that comes after it. I definitely wouldn’t
recommend
this approach.

What is the proper way to reference the system page structures
when attemmpting a direct load in this way?

I don’t think it’s ever been done before, so there really is no
‘proper’ way… I’m not sure I understand why you are approaching it
this way - a startup for a non-BIOS x86 system is done the same way
as for any other platform - why don’t you want to just use the normal
startup library calls to populate the syspage?

Thank you!

Richard B.




I am perhaps being naive! Since there is to be no BIOS, so I need to
have some way of populating the system page without recourse to the
BIOS probes that some of the startup library calls use. The only
“example”
for x86 systems that bsp-6.2.0 has is the sc400. It does have some
material for non-BIOS IPL, but the startup source program main.c has
a notation that the calls it makes assumes a BIOS is present, and, if you
don’t have one, you must substitute your own. Having no examples to
work from, it seemed to me that the most straight-forward thing to do
would
be to simply load the system page variables with the appropriate values,
all of which are known.

Does this answer your question?
What [totally obvious to everyone else thing] am I missing here?
Is the bsp I have loaded somehow incomplete?

Rich

7

Igor Kovalenko wrote:

Have you looked at ‘Embedded BIOS’ from General Software? Depending on
your needs, it may make your life a lot easier. They claim it has been
used in CE devices with boot time at around 1 sec.

The way it works is you get a ‘BIOS kit’ with some sort of ‘tuning’
application. You tune it for your specific hardware and the tool generates
a custom BIOS that’s just good enough to boot your particular target
(rather than being generic bloated slow typical BIOS).

– igor

snip

An interesting thought, though I would really like to just eliminate the
BIOS completely. As far as I know, the QNX/RTP device drivers do not need
it…

I am curious to see what Dave Green’s response will be, as I am curious to
see if I am somehow overlooking an elephant in the living room…

8

“Richard Bonomo,6289 Chamberlin,263-4683,” <bonomo@sal.wisc.edu> wrote in
message news:d8pkei$ho$1@inn.qnx.com…

Igor Kovalenko wrote:

Have you looked at ‘Embedded BIOS’ from General Software? Depending on
your needs, it may make your life a lot easier. They claim it has been
used in CE devices with boot time at around 1 sec.

The way it works is you get a ‘BIOS kit’ with some sort of ‘tuning’
application. You tune it for your specific hardware and the tool
generates
a custom BIOS that’s just good enough to boot your particular target
(rather than being generic bloated slow typical BIOS).

– igor

snip
An interesting thought, though I would really like to just eliminate the
BIOS completely. As far as I know, the QNX/RTP device drivers do not need
it…

Heh. That’s what they make you to believe, but it isn’t always true.
In any case, having BIOS gives you an abstraction layer, so your code may be
more generic. Otherwise you’re really married to your hardware.

– igor

9

Igor Kovalenko wrote:

“Richard Bonomo,6289 Chamberlin,263-4683,” <> bonomo@sal.wisc.edu> > wrote in
message news:d8pkei$ho$> 1@inn.qnx.com> …
Igor Kovalenko wrote:

Have you looked at ‘Embedded BIOS’ from General Software? Depending on
your needs, it may make your life a lot easier. They claim it has been
used in CE devices with boot time at around 1 sec.

The way it works is you get a ‘BIOS kit’ with some sort of ‘tuning’
application. You tune it for your specific hardware and the tool
generates
a custom BIOS that’s just good enough to boot your particular target
(rather than being generic bloated slow typical BIOS).

– igor

snip
An interesting thought, though I would really like to just eliminate the
BIOS completely. As far as I know, the QNX/RTP device drivers do not need
it…

Heh. That’s what they make you to believe, but it isn’t always true.
In any case, having BIOS gives you an abstraction layer, so your code may
be more generic. Otherwise you’re really married to your hardware.

– igor

We are most certainly married to the hardware at this point.
Regarding the drivers: one thing I need to determine is how dependent
the devb-doc driver is on BIOS calls, and if they can be substituted
for in some way, if we need to use that particular device…

Rich

10

Richard Bonomo,6289 Chamberlin,263-4683, <bonomo@sal.wisc.edu> wrote:

Dave Green wrote:

Richard Bonomo,6289 Chamberlin,263-4683, <> bonomo@sal.wisc.edu> > wrote:

[snip]

Will this approach work?

I’m doubtful that this could be made to work; at the very least, it would
be a delicate juggling act - any one change will affect the (hard-coded)
offsets of everything that comes after it. I definitely wouldn’t recommend
this approach.

What is the proper way to reference the system page structures
when attemmpting a direct load in this way?

I don’t think it’s ever been done before, so there really is no
‘proper’ way… I’m not sure I understand why you are approaching it
this way - a startup for a non-BIOS x86 system is done the same way
as for any other platform - why don’t you want to just use the normal
startup library calls to populate the syspage?

Thank you!

Richard B.




I am perhaps being naive! Since there is to be no BIOS, so I need to
have some way of populating the system page without recourse to the
BIOS probes that some of the startup library calls use. The only “example”
for x86 systems that bsp-6.2.0 has is the sc400. It does have some
material for non-BIOS IPL, but the startup source program main.c has
a notation that the calls it makes assumes a BIOS is present, and, if you
don’t have one, you must substitute your own. Having no examples to
work from, it seemed to me that the most straight-forward thing to do would
be to simply load the system page variables with the appropriate values,
all of which are known.

I suspect what may be throwing you off is the comment you found in the
sc400 startup code:

// The following routines have hardware or system dependancies which
// may need to be changed on a non-PC compatible system. The default
// routines assume a BIOS is present. If you do not have a bios you
// will need to replace these routines with ones of your own.

This comment is somewhat misleading, and might make you think that
there are all sorts of INT10 BIOS calls going on in the x86 startup
library - there aren’t.

You are working with a PC compatible system, so for the most part,
the same routines can be called whether or not you have a BIOS. In
some cases, however, you may need to copy the routine from the
startup library into your local startup directory, and modify it
accordingly.

For example, if a particular startup library routine (init_raminfo(),
for instance) was failing to work on your system, you could
just make your own init_raminfo(), which does an add_ram() call
for each area of DRAM. In a system with 32M of DRAM, you would:

add_ram(0,(640 * 1024)); // add the first 640k
add_ram(MEG(1), MEG(31); // add from 1 meg to 32M

The init_intrinfo() call could probably used as is, along with
init_qtime(), etc.


Does this answer your question?
What [totally obvious to everyone else thing] am I missing here?
Is the bsp I have loaded somehow incomplete?

Rich

–

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

11

Dave Green wrote:

Richard Bonomo,6289 Chamberlin,263-4683, <> bonomo@sal.wisc.edu> > wrote:
Dave Green wrote:

Richard Bonomo,6289 Chamberlin,263-4683, <> bonomo@sal.wisc.edu> > wrote:

[snip]

Will this approach work?

I’m doubtful that this could be made to work; at the very least, it
would be a delicate juggling act - any one change will affect the
(hard-coded) offsets of everything that comes after it. I definitely
wouldn’t recommend this approach.

What is the proper way to reference the system page structures
when attemmpting a direct load in this way?

I don’t think it’s ever been done before, so there really is no
‘proper’ way… I’m not sure I understand why you are approaching it
this way - a startup for a non-BIOS x86 system is done the same way
as for any other platform - why don’t you want to just use the normal
startup library calls to populate the syspage?

Thank you!

Richard B.




I am perhaps being naive! Since there is to be no BIOS, so I need to
have some way of populating the system page without recourse to the
BIOS probes that some of the startup library calls use. The only
“example”
for x86 systems that bsp-6.2.0 has is the sc400. It does have some
material for non-BIOS IPL, but the startup source program main.c has
a notation that the calls it makes assumes a BIOS is present, and, if you
don’t have one, you must substitute your own. Having no examples to
work from, it seemed to me that the most straight-forward thing to do
would be to simply load the system page variables with the appropriate
values, all of which are known.

I suspect what may be throwing you off is the comment you found in the
sc400 startup code:

// The following routines have hardware or system dependancies which
// may need to be changed on a non-PC compatible system. The default
// routines assume a BIOS is present. If you do not have a bios you
// will need to replace these routines with ones of your own.

This comment is somewhat misleading, and might make you think that
there are all sorts of INT10 BIOS calls going on in the x86 startup
library - there aren’t.

You are working with a PC compatible system, so for the most part,
the same routines can be called whether or not you have a BIOS. In
some cases, however, you may need to copy the routine from the
startup library into your local startup directory, and modify it
accordingly.

For example, if a particular startup library routine (init_raminfo(),
for instance) was failing to work on your system, you could
just make your own init_raminfo(), which does an add_ram() call
for each area of DRAM. In a system with 32M of DRAM, you would:

add_ram(0,(640 * 1024)); // add the first 640k
add_ram(MEG(1), MEG(31); // add from 1 meg to 32M

The init_intrinfo() call could probably used as is, along with
init_qtime(), etc.


Does this answer your question?
What [totally obvious to everyone else thing] am I missing here?
Is the bsp I have loaded somehow incomplete?

Rich

Dear Dave,

Yes, I was being thrown off by that comment. I took the two sentences
to be somewhat independent, such that they depended on a BIOS
even on an x86 system. This makes life much easier… THANKS!
(I would also suggest rewording that a bit…)

Rich

12

“Richard Bonomo,6289 Chamberlin,263-4683,” <bonomo@sal.wisc.edu> wrote in
message news:d8pu2j$7cl$1@inn.qnx.com…

Igor Kovalenko wrote:

“Richard Bonomo,6289 Chamberlin,263-4683,” <> bonomo@sal.wisc.edu> > wrote in
message news:d8pkei$ho$> 1@inn.qnx.com> …
Igor Kovalenko wrote:

Have you looked at ‘Embedded BIOS’ from General Software? Depending on
your needs, it may make your life a lot easier. They claim it has been
used in CE devices with boot time at around 1 sec.

The way it works is you get a ‘BIOS kit’ with some sort of ‘tuning’
application. You tune it for your specific hardware and the tool
generates
a custom BIOS that’s just good enough to boot your particular target
(rather than being generic bloated slow typical BIOS).

– igor

snip
An interesting thought, though I would really like to just eliminate the
BIOS completely. As far as I know, the QNX/RTP device drivers do not
need
it…

Heh. That’s what they make you to believe, but it isn’t always true.
In any case, having BIOS gives you an abstraction layer, so your code may
be more generic. Otherwise you’re really married to your hardware.

– igor

We are most certainly married to the hardware at this point.

I understand that, but consider this. In a few years hardware either gets
revised because of competitive pressure or discontinued. That has been my
experience anyway. New chipsets come out and this stuff needs to be
reworked… There’s always this temptation to hardcode everything and make
it ‘simple’, but if you plan to keep your product alive for years to come it
is a bad idea. After several years you end up with several different
hardware revisions in the field and maintaining separate software builds for
all of them becomes a royal pain.

– igor

13

Igor Kovalenko wrote:

“Richard Bonomo,6289 Chamberlin,263-4683,” <> bonomo@sal.wisc.edu> > wrote in
message news:d8pu2j$7cl$> 1@inn.qnx.com> …
Igor Kovalenko wrote:

“Richard Bonomo,6289 Chamberlin,263-4683,” <> bonomo@sal.wisc.edu> > wrote
in message news:d8pkei$ho$> 1@inn.qnx.com> …
Igor Kovalenko wrote:

Have you looked at ‘Embedded BIOS’ from General Software? Depending on
your needs, it may make your life a lot easier. They claim it has been
used in CE devices with boot time at around 1 sec.

The way it works is you get a ‘BIOS kit’ with some sort of ‘tuning’
application. You tune it for your specific hardware and the tool
generates
a custom BIOS that’s just good enough to boot your particular target
(rather than being generic bloated slow typical BIOS).

– igor

snip
An interesting thought, though I would really like to just eliminate
the BIOS completely. As far as I know, the QNX/RTP device drivers do
not need
it…

Heh. That’s what they make you to believe, but it isn’t always true.
In any case, having BIOS gives you an abstraction layer, so your code
may be more generic. Otherwise you’re really married to your hardware.

– igor

We are most certainly married to the hardware at this point.

I understand that, but consider this. In a few years hardware either gets
revised because of competitive pressure or discontinued. That has been my
experience anyway. New chipsets come out and this stuff needs to be
reworked… There’s always this temptation to hardcode everything and make
it ‘simple’, but if you plan to keep your product alive for years to come
it is a bad idea. After several years you end up with several different
hardware revisions in the field and maintaining separate software builds
for all of them becomes a royal pain.

– igor

Certainly, if we are dealing with a “product,” this is a critical
consideration. I am dealing with a small number of prototype devices which
will be used in the “field” (well, mostly in space). If this thing ever
should be produced in quantity, it will have to be reworked, anyway, for a
manufacturing environment.

I am already experiencing similar troubles with devices we built originally
to work with DEC proprietary buses (DRV-11, I think). We decided to migrate
to the ECP port, since x86 boxes had become fast enough, and the ECP port
was fast enough. We figured that the parallel port would be a nice stable
i/o channel – safe to design to. Now they are beginning to disappear
too… Argh…

Never the less, I will probably look into your suggestion eventually,
especially if it is easily mated with the other OS loading software.

Rich

14

hello,

we try to port QNX onto the DNP9200 Board.

We use the Integrator-BSP to create a Flash-Filesystem Image.
The problem is that when we compile the project, the compiler breaks because
of missing libraries or header files.

In the Docu we found this:

Include <sys/f3s_mtd.h> instead of <sys/f3s_api.h>, <sys/f3s_spec.h>,
<sys/f3s_socket.h>, <sys/f3s_comp.h>, or <sys/f3s_flash.h>.
but although the compiler needs the header file: “f3s_api.h”

we dont’t know how to continue…

thanks,

Hannes R. and Bachir B.