Skip navigation.
Home
The QNX Community Portal

View topic - system page importation and variables

system page importation and variables

Read-only archive of qnx.bsp (Discuss building an image, flashing a board or using a BSP) at inn.qnx.com

system page importation and variables

Postby bonomo » Fri May 20, 2005 12:00 am

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.
bonomo
Active Member
 
Posts: 26
Joined: Mon Feb 23, 2004 10:39 pm

Re: system page importation and variables

Postby Dave Green » Tue Jun 14, 2005 12:40 pm

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
Dave Green
 

Re: system page importation and variables

Postby bonomo » Tue Jun 14, 2005 6:00 pm

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
0) 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
0000) 00000000-0000ffff o:ffff a:0000 p:100 c:00000000 n:21
0020) 00000000-ffffffff o:ffff a:0010 p:100 c:00000000 n:24
0040) 00000000-00ffffff o:0020 a:0010 p:100 c:00000000 n:31
0060) 06000000-ffefffff o:0020 a:0003 p:100 c:00000000 n:35
0080) 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
0100) 0040b4d8-00588267 o:0020 a:0005 p:100 c:00000000 n:178
0120) 0040b4d8-00588267 o:0020 a:0007 p:100 c:00000000 n:186
0140) 00001000-0000bfff o:00a0 a:0007 p:100 c:00000000 n:194
0160) 00011f90-000963ff o:00a0 a:0007 p:100 c:00000000 n:194
0180) 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
0) size:3 tag:3 isize:3, iname:0, owner:65535, kids:2
12) size:3 tag:17 isize:3, iname:9, owner:0, kids:2
24) size:3 tag:3 isize:3, iname:50, owner:12, kids:1
36) size:4 tag:63 isize:11, iname:54, owner:24, kids:0
00 00 00 00
52) size:1 tag:70
56) size:6 tag:74
02 00 00 00 70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80) size:3 tag:17 isize:3, iname:31, owner:0, kids:4
92) size:3 tag:3 isize:7, iname:106, owner:80, kids:0
104) size:4 tag:111
00 09 10 00 eb 03 09 00 a0 33 02 00
120) size:3 tag:3 isize:3, iname:124, owner:80, kids:1
132) size:4 tag:63 isize:13, iname:129, owner:120, kids:0
00 00 00 00
148) size:2 tag:135
01 00 00 00
156) size:1 tag:70
160) size:6 tag:74
05 00 00 00 60 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
184) size:3 tag:3 isize:3, iname:139, owner:80, kids:1
196) size:4 tag:63 isize:21, iname:146, owner:184, kids:0
00 00 00 00
212) size:2 tag:135
04 00 00 00
220) size:1 tag:70
224) size:6 tag:74
07 00 00 00 f8 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00
248) size:2 tag:135
03 00 00 00
256) size:6 tag:74
07 00 00 00 f8 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00
280) size:3 tag:3 isize:3, iname:151, owner:80, kids:1
292) size:4 tag:63 isize:11, iname:160, owner:280, kids:0
00 00 00 00
308) size:1 tag:70
312) size:6 tag:74
07 00 00 00 78 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00
336) size:3 tag:3 isize:3, iname:124, owner:12, kids:1
348) size:4 tag:63 isize:33, iname:171, owner:336, kids:0
00 00 00 00
364) size:1 tag:70
368) size:6 tag:74
00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
392) size:6 tag:74
00 01 00 00 00 ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00
416) size:6 tag:74
00 40 03 00 00 00 0a 00 00 00 00 00 00 00 20 00 00 00 00 00
440) size:6 tag:74
00 a0 02 00 00 60 0d 00 00 00 00 00 00 00 20 00 00 00 00 00
464) size:2 tag:135
0e 00 00 00
472) 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
0) 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
1) 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
2) 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
3) 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
4) 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
0) 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) */
<and so forth>
******************** 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.
bonomo
Active Member
 
Posts: 26
Joined: Mon Feb 23, 2004 10:39 pm

Re: system page importation and variables

Postby Dave Green » Tue Jun 14, 2005 7:56 pm

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
Dave Green
 

Re: system page importation and variables

Postby bonomo » Tue Jun 14, 2005 10:00 pm

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
bonomo
Active Member
 
Posts: 26
Joined: Mon Feb 23, 2004 10:39 pm

Re: system page importation and variables

Postby Igor Kovalenko » Wed Jun 15, 2005 5:38 am

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
Igor Kovalenko
 

Re: system page importation and variables

Postby bonomo » Wed Jun 15, 2005 5:27 pm

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...
bonomo
Active Member
 
Posts: 26
Joined: Mon Feb 23, 2004 10:39 pm

Re: system page importation and variables

Postby Igor Kovalenko » Wed Jun 15, 2005 6:55 pm

"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
Igor Kovalenko
 

Re: system page importation and variables

Postby bonomo » Wed Jun 15, 2005 8:00 pm

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
bonomo
Active Member
 
Posts: 26
Joined: Mon Feb 23, 2004 10:39 pm

Re: system page importation and variables

Postby Dave Green » Wed Jun 15, 2005 8:28 pm

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
Dave Green
 

Re: system page importation and variables

Postby bonomo » Wed Jun 15, 2005 10:00 pm

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
bonomo
Active Member
 
Posts: 26
Joined: Mon Feb 23, 2004 10:39 pm

Re: system page importation and variables

Postby Igor Kovalenko » Wed Jun 15, 2005 10:24 pm

"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
Igor Kovalenko
 

Re: system page importation and variables

Postby bonomo » Thu Jun 16, 2005 9:09 pm

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
bonomo
Active Member
 
Posts: 26
Joined: Mon Feb 23, 2004 10:39 pm

porting Qnx to DNP9200

Postby Bachir B. » Mon May 22, 2006 12:49 pm

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.
Bachir B.
 


Return to qnx.bsp

Who is online

Users browsing this forum: No registered users and 1 guest