embedding Photon

Hi,

I am trying to embed Photon on a 4Mb flash memory. I was able to do so, but
there are some performance problems.
If I create an image, rename to .altboot, and boot, everything works fine.
However, if I use mkrom, write to flash memory and boot, everything works
except that everything runs a lot slower than it should run. But, if I boot
on flash, wait a few minutes and run Photon script, everything works
perfectly.
Did anyone have similar problems embedding Photon? I would like to here from
you all, Photon “embedders”! :slight_smile:


Regards,

Ricardo Kazumi Ashikawa

“Ricardo Kazumi Ashikawa” <ashikawa@dixtal.com.br> wrote in message
news:9r46pg$fth$1@inn.qnx.com

Hi,

I am trying to embed Photon on a 4Mb flash memory. I was able to do so,
but
there are some performance problems.
If I create an image, rename to .altboot, and boot, everything works fine.
However, if I use mkrom, write to flash memory and boot, everything works
except that everything runs a lot slower than it should run. But, if I
boot
on flash, wait a few minutes and run Photon script, everything works
perfectly.
Did anyone have similar problems embedding Photon? I would like to here
from
you all, Photon “embedders”! > :slight_smile:

Never seen such a problem. In my case I don’t include any Photon component
in the .boot.

Regards,

Ricardo Kazumi Ashikawa

Hi,

I am trying to embed Photon on a 4Mb flash memory. I was able to do so,
but
there are some performance problems.
If I create an image, rename to .altboot, and boot, everything works
fine.
However, if I use mkrom, write to flash memory and boot, everything
works
except that everything runs a lot slower than it should run. But, if I
boot
on flash, wait a few minutes and run Photon script, everything works
perfectly.
Did anyone have similar problems embedding Photon? I would like to here
from
you all, Photon “embedders”! > :slight_smile:


Never seen such a problem. In my case I don’t include any Photon
component
in the .boot.

Neither do I! .boot just boot to esh and run a script that starts Photon.


Regards,

Ricardo Kazumi Ashikawa

Sorry, but I was wrong about performance!
Even if I wait several minutes before running Photon script, boot is slower
when running from flash, comparing to running as .altboot.
Does anyone have any clues on what is happening?
What is the difference between booting from extended bios (using mkrom) and
booting from .altboot? Is there anything I am missing?


Regards,

Ricardo Kazumi Ashikawa

Hi,

I am trying to embed Photon on a 4Mb flash memory. I was able to do so,
but
there are some performance problems.
If I create an image, rename to .altboot, and boot, everything works fine.
However, if I use mkrom, write to flash memory and boot, everything works
except that everything runs a lot slower than it should run. But, if I
boot
on flash, wait a few minutes and run Photon script, everything works
perfectly.
Did anyone have similar problems embedding Photon? I would like to here
from
you all, Photon “embedders”! > :slight_smile:

Ricardo Kazumi Ashikawa <ashikawa@dixtal.com.br> wrote:

Sorry, but I was wrong about performance!
Even if I wait several minutes before running Photon script, boot is slower
when running from flash, comparing to running as .altboot.
Does anyone have any clues on what is happening?
What is the difference between booting from extended bios (using mkrom) and
booting from .altboot? Is there anything I am missing?



Regards,

Ricardo Kazumi Ashikawa

There should be no difference between booting from an image on a hard
disk, and the identical image in flash via a BIOS extension, provided
that the BIOS has completed configuring the system in each case.
Remember, the BIOS extension that you generate consists of two stages.
The first stage is responsible for copying itself to DRAM just under
1M, and then re-vectoring the int19 disk boot code to some other
location. It then sets up the second stage (the image_*_ext() functions)
to be vectored at int19, and then returns control to the BIOS. The
second stage doesn’t get executed until the BIOS has completed all
of its work, and attempts to boot from disk, by calling int19.
At this point, the QNX IPL code gets executed instead.

It’s possible that after the first stage of the IPL has finished
re-vectoring, that instead of doing a RET to return control to the
BIOS, it simply continues on and calls main() of the IPL, which goes
ahead and boots from flash. In this case, it’s possible that the BIOS
had more work to do, and is never given a chance to complete.

When you boot the .altboot image from hard disk, is it being involked
by pressing a key to interrupt the flash boot routines, or is the
BIOS extension IPL somehow being bypassed altogether?


At this point, have you been able to rule out Photon as part of
the problem? Can you show a difference in performance between
booting to a text console from flash and from disk?

If so, could you please post the build file used to create the
boot image?


Hi,

I am trying to embed Photon on a 4Mb flash memory. I was able to do so,
but
there are some performance problems.
If I create an image, rename to .altboot, and boot, everything works fine.
However, if I use mkrom, write to flash memory and boot, everything works
except that everything runs a lot slower than it should run. But, if I
boot
on flash, wait a few minutes and run Photon script, everything works
perfectly.
Did anyone have similar problems embedding Photon? I would like to here
from
you all, Photon “embedders”! > :slight_smile:

Dave Green (dgreen@qnx.com)

QNX Software Systems Ltd.
http://www.qnx.com

There should be no difference between booting from an image on a hard
disk, and the identical image in flash via a BIOS extension, provided
that the BIOS has completed configuring the system in each case.
Remember, the BIOS extension that you generate consists of two stages.
The first stage is responsible for copying itself to DRAM just under
1M, and then re-vectoring the int19 disk boot code to some other
location. It then sets up the second stage (the image_*_ext() functions)
to be vectored at int19, and then returns control to the BIOS. The
second stage doesn’t get executed until the BIOS has completed all
of its work, and attempts to boot from disk, by calling int19.
At this point, the QNX IPL code gets executed instead.

It’s possible that after the first stage of the IPL has finished
re-vectoring, that instead of doing a RET to return control to the
BIOS, it simply continues on and calls main() of the IPL, which goes
ahead and boots from flash. In this case, it’s possible that the BIOS
had more work to do, and is never given a chance to complete.

Well… I really do not know what is done at extended BIOS, since I am using
mkrom from QNX to do this. I just coded an IPL that copy image from flash to
DRAM, used mkrom on IPL, padded output to 32 kb (flash page size) and joined
to boot image.
Perhaps there is some BIOS configuration missing on IPL, but I do not know
what it could be. As I have little experience dealing with extended BIOS, I
do not know exactly what is to be done before giving control to IPL. I
thought mkrom would could deal with this.


When you boot the .altboot image from hard disk, is it being involked
by pressing a key to interrupt the flash boot routines, or is the
BIOS extension IPL somehow being bypassed altogether?

I just copy boot image I created to /.altboot and press ESC on boot time.


At this point, have you been able to rule out Photon as part of
the problem? Can you show a difference in performance between
booting to a text console from flash and from disk?

Even without Photon, performance is worse when booting from flash. For
example, when I run ‘pidin mem’, scroll is slower when booting from flash.


If so, could you please post the build file used to create the
boot image?

Below is boot build file. I #'ed photon start script file ‘ph-start’ since
there is noticible lower performance even in text mode.

#build file
[virtual=x86/bios +compress] boot = {
startup-bios
PATH=/proc/boot:/bin LD_LIBRARY_PATH=/proc/boot:/dev/shmem:/usr/lib:/lib
procnto
}

[+script] startup.script = {
seedres

pci-bios &
waitfor /dev/pci

io-net -d ne2000 -p ttcpip -p qnet host=p9
waitfor /dev/socket

devc-con &
reopen /dev/con1

[pri=20r] devc-pty &

pipe &

mqueue &

devc-ser8250 -u1 2f8,3 &
waitfor /dev/ser1

[+session] LD_LIBRARY_PATH=/proc/boot:/usr/lib:/lib:/phembed/lib esh &

LD_LIBRARY_PATH=/proc/boot:/usr/lib:/lib:/phembed/lib /phembed/ph-start

}

[type=link] /usr/lib/ldqnx.so.2 = /proc/boot/libc.so
[type=link] /phembed/lib/libAp.so = /phembed/lib/libAp.so.2
[type=link] /phembed/lib/libdisputil.so = /phembed/lib/libdisputil.so.2
[type=link] /phembed/lib/libffb.so = /phembed/lib/libffb.so.2
[type=link] /phembed/lib/libph.so = /phembed/lib/libph.so.2
[type=link] /phembed/lib/libphexlib.so = /phembed/lib/libphexlib.so.2
[type=link] /phembed/lib/libphrender.so = /phembed/lib/libphrender.so.2

libc.so
libcpp.so
libm.so
npm-ttcpip.so
npm-qnet.so
devn-ne2000.so

[data=copy]
esh

[+optional prefix=/bin]
seedres
pci-bios
io-net
devc-pty
devc-con
pipe
mqueue
devc-ser8250
esh
echo
on
ls
ps
pidin

[+raw] /phembed=…/phembed


Below is photon start script file.

#!/bin/esh
export PHOTON_PATH=/phembed

cd /phembed/bin

echo starting Photon…

on -p12 ./Photon &
on -w /dev/photon -W10

echo starting Photon Font Manager…

on -p12 ./phfontFF -d/phembed/font_repository -j -s 50K &
on -w /dev/phfont -W10

echo starting Graphics driver…

on -p12 ./io-graphics -g800x600x16 -dldevg-svga.so -I0 -d0x1039,0x6306 &

echo starting Keyboard/Mouse driver…

on -p12 ./devi-hirun kbd fd -d/dev/kbd msoft -R fd -d/dev/ser1 &

echo starting Led Resource Manager…

…/LedManager &
on -w /dev/led -W10

echo starting Sound Resource Manager…

…/SoundManager &
on -w /dev/sound -W10

echo starting Eeprom/Keyboard Resource Manager…

…/EepromKbdManager &
on -w /dev/eeprom -W10

echo starting PhAB Application

on -p12 ./Int &

ps -A -o pid,pri,args



And finally /phembed directory contents.

phembed:


bin
font_repository
lib
ph-start

phembed/bin:


EepromKbdManager
Encoder
Int
LedManager
Photon
SoundManager
devi-hirun
io-graphics
mqueue
phfontFF

phembed/font_repository:


fontdir
fontext
fontkey
fontmap
fonttype
phcursor.phf
tt2001m_.ttf
tt2002m_.ttf
tt2003m_.ttf
tt2004m_.ttf
tt2009m_.ttf
tt2011m_.ttf

phembed/lib:


devg-svga.so
devg-vesabios.so
libAp.so.2
libdisputil.so.2
libffb.so.2
libph.so.2
libphexlib.so.2
libphrender.so.2



Regards,

Ricardo Kazumi Ashikawa

Operating System Tech Support <os@qnx.com> wrote:

“Ricardo Kazumi Ashikawa” <> ashikawa@dixtal.com.br> > wrote in message
news:9r6roc$6n3$> 1@inn.qnx.com> …
Well… I really do not know what is done at extended BIOS, since I am
using
mkrom from QNX to do this. I just coded an IPL that copy image from flash
to
DRAM, used mkrom on IPL, padded output to 32 kb (flash page size) and
joined
to boot image.
Perhaps there is some BIOS configuration missing on IPL, but I do not know
what it could be. As I have little experience dealing with extended BIOS,
I
do not know exactly what is to be done before giving control to IPL. I
thought mkrom would could deal with this.

In your code where you revector INT19 (cstart_int19.s) take a look at the
section where the code performs the revectoring (L1:). At the end of that
section, after the INT19 has been revectored, there should be a return (back
to the BIOS), but there isn’t. If you stick a “RETN” (or equal) at the end
of the L1: section, this should allow the BIOS to continue to setup the
board, and finally call INT19 to boot.

-Adam

D’oh!

This is what I had suspected earlier; however, I thought maybe you had
modified the cstart_int19.s code, and possibly removed the RETN; instead,
it turns out it was never there to begin with!

L1:
movw $0x0000,%ax
movw %ax,%es
movw $L2,%ax
xchgw %es:(0x00000064),%ax
movw %ax,%es:(0x000003e0)
movw %cs,%ax
xchgw %es:(0x00000066),%ax
movw %ax,%es:(0x000003e2)
RETN

^^^^

With this RETN in place, control should transfer back to the BIOS after
re-vectoring, and the BIOS can complete its initialization. Then, when
int19 gets called, the remainder of the IPL will execute.

Sorry for the confusion.


Dave Green (dgreen@qnx.com)

QNX Software Systems Ltd.
http://www.qnx.com

In your code where you revector INT19 (cstart_int19.s) take a look at the
section where the code performs the revectoring (L1:). At the end of that
section, after the INT19 has been revectored, there should be a return
(back
to the BIOS), but there isn’t. If you stick a “RETN” (or equal) at the
end
of the L1: section, this should allow the BIOS to continue to setup the
board, and finally call INT19 to boot.

Hi,

Well. As I am using cstart_int19.s from sc400ext, I guess it is correct. I
was checking code and, if I put RETN at the end of L1 section, int 19 will
not be revectored. So, if I do this, IPL is bypassed… And that is what
happened after this change.

Below is the cstart_int19.s I am using… Would you please show me
corrections on this code so that I solve my problem?


Regards,

Ricardo Kazumi Ashikawa



.file “cstart”
…text
.code16gcc
.align 2
.globl _start
…macro RETN
.byte 0xcb
…endm

_start: .byte 0x00,0x00,0x00,0x00,0x00,0x00
L1:
movw $0x0000,%ax
movw %ax,%es
movw $L2,%ax
xchgw %es:(0x00000064),%ax
movw %ax,%es:(0x000003e0)
movw %cs,%ax
xchgw %es:(0x00000066),%ax
movw %ax,%es:(0x000003e2)

L2:
int $0x12
addw %ax,%ax
movb %cs:(0x00000002),%cl
xorb %ch,%ch
subw %cx,%ax
shlw $0x05,%ax
movw %ax,%es
movw %cs,%ax
movw %ax,%ds
xchgb %cl,%ch
cld
xorw %si,%si
xorw %di,%di
repe; movsw
cli
movw %es,%ax
movw %ax,%ds
movw %ax,%ss
movw $0x1000,%sp
sti
pushw %ax
pushw $L3
RETN

L3:
call main
done:
int $0xf8
…data
.align 16

…data
.align 1

…data
.align 1

…bss
.align 1

…data
.align 2
…zero 0x00000100

“Ricardo Kazumi Ashikawa” <ashikawa@dixtal.com.br> wrote in message
news:9r6roc$6n3$1@inn.qnx.com

Well… I really do not know what is done at extended BIOS, since I am
using
mkrom from QNX to do this. I just coded an IPL that copy image from flash
to
DRAM, used mkrom on IPL, padded output to 32 kb (flash page size) and
joined
to boot image.
Perhaps there is some BIOS configuration missing on IPL, but I do not know
what it could be. As I have little experience dealing with extended BIOS,
I
do not know exactly what is to be done before giving control to IPL. I
thought mkrom would could deal with this.

In your code where you revector INT19 (cstart_int19.s) take a look at the
section where the code performs the revectoring (L1:). At the end of that
section, after the INT19 has been revectored, there should be a return (back
to the BIOS), but there isn’t. If you stick a “RETN” (or equal) at the end
of the L1: section, this should allow the BIOS to continue to setup the
board, and finally call INT19 to boot.

-Adam

Ricardo Kazumi Ashikawa <ashikawa@dixtal.com.br> wrote:

In your code where you revector INT19 (cstart_int19.s) take a look at the
section where the code performs the revectoring (L1:). At the end of that
section, after the INT19 has been revectored, there should be a return
(back
to the BIOS), but there isn’t. If you stick a “RETN” (or equal) at the
end
of the L1: section, this should allow the BIOS to continue to setup the
board, and finally call INT19 to boot.

Hi,

Well. As I am using cstart_int19.s from sc400ext, I guess it is correct.

Not quite; the RETN after the L1 section should be there.

I
was checking code and, if I put RETN at the end of L1 section, int 19 will
not be revectored. So, if I do this, IPL is bypassed… And that is what
happened after this change.

I’m not sure what you mean here… When the BIOS executes the BIOS
extension, the L1 portion (which does the re-vectoring) gets executed,
and then returns control to the BIOS. When the BIOS has finished, and
calls int19 to boot from disk, the L2 section below gets executed
instead of the regular int19 disk boot code. The part at the bottom
of section L2 is to transfer execution of the code from flash, where
we are still executing from, to the proper offset in DRAM, where the
L2 section copied the IPL to.

When main() is called, the user is given the option to press a key to stop
the flash boot. If the key is pressed, main() returns back to the
L3 section, where int 0xf8 is called. That is the vector where the
int19 disk boot code was re-vectored to, and the board boots from
hard disk. If a key is not pressed, then main() continues on to
call the image_*_ext() functions.



Below is the cstart_int19.s I am using… Would you please show me
corrections on this code so that I solve my problem?



Regards,

Ricardo Kazumi Ashikawa



.file “cstart”
.text
.code16gcc
.align 2
.globl _start
.macro RETN
.byte 0xcb
.endm

_start: .byte 0x00,0x00,0x00,0x00,0x00,0x00
L1:
movw $0x0000,%ax
movw %ax,%es
movw $L2,%ax
xchgw %es:(0x00000064),%ax
movw %ax,%es:(0x000003e0)
movw %cs,%ax
xchgw %es:(0x00000066),%ax
movw %ax,%es:(0x000003e2)
RETN



L2:
int $0x12
addw %ax,%ax
movb %cs:(0x00000002),%cl
xorb %ch,%ch
subw %cx,%ax
shlw $0x05,%ax
movw %ax,%es
movw %cs,%ax
movw %ax,%ds
xchgb %cl,%ch
cld
xorw %si,%si
xorw %di,%di
repe; movsw
cli
movw %es,%ax
movw %ax,%ds
movw %ax,%ss
movw $0x1000,%sp
sti
pushw %ax
pushw $L3
RETN

L3:
call main
done:
int $0xf8
.data
.align 16

.data
.align 1

.data
.align 1

.bss
.align 1

.data
.align 2
.zero 0x00000100

Dave Green (dgreen@qnx.com)

QNX Software Systems Ltd.
http://www.qnx.com

Well. As I am using cstart_int19.s from sc400ext, I guess it is correct.

Not quite; the RETN after the L1 section should be there.

Yes. You are right. Now that I analyzed L1 section, it is really revectoring
int 19h to L2 section and storing original int 19h code to int f8h.


I
was checking code and, if I put RETN at the end of L1 section, int 19
will
not be revectored. So, if I do this, IPL is bypassed… And that is what
happened after this change.

I’m not sure what you mean here… When the BIOS executes the BIOS
extension, the L1 portion (which does the re-vectoring) gets executed,
and then returns control to the BIOS. When the BIOS has finished, and
calls int19 to boot from disk, the L2 section below gets executed
instead of the regular int19 disk boot code. The part at the bottom
of section L2 is to transfer execution of the code from flash, where
we are still executing from, to the proper offset in DRAM, where the
L2 section copied the IPL to.

When main() is called, the user is given the option to press a key to stop
the flash boot. If the key is pressed, main() returns back to the
L3 section, where int 0xf8 is called. That is the vector where the
int19 disk boot code was re-vectored to, and the board boots from
hard disk. If a key is not pressed, then main() continues on to
call the image_*_ext() functions.

I had already tried to put RETN at the end of L1 section.
I still did not understand why, but when I do that, extended BIOS is not
executed… I put hlt command to check if L1 section is executed, but
system does not halt. Any clues on what is happening?


Regards,

Ricardo Kazumi Ashikawa

Ricardo Kazumi Ashikawa <ashikawa@dixtal.com.br> wrote:

Well. As I am using cstart_int19.s from sc400ext, I guess it is correct.

Not quite; the RETN after the L1 section should be there.

Yes. You are right. Now that I analyzed L1 section, it is really revectoring
int 19h to L2 section and storing original int 19h code to int f8h.



I
was checking code and, if I put RETN at the end of L1 section, int 19
will
not be revectored. So, if I do this, IPL is bypassed… And that is what
happened after this change.

I’m not sure what you mean here… When the BIOS executes the BIOS
extension, the L1 portion (which does the re-vectoring) gets executed,
and then returns control to the BIOS. When the BIOS has finished, and
calls int19 to boot from disk, the L2 section below gets executed
instead of the regular int19 disk boot code. The part at the bottom
of section L2 is to transfer execution of the code from flash, where
we are still executing from, to the proper offset in DRAM, where the
L2 section copied the IPL to.

When main() is called, the user is given the option to press a key to stop
the flash boot. If the key is pressed, main() returns back to the
L3 section, where int 0xf8 is called. That is the vector where the
int19 disk boot code was re-vectored to, and the board boots from
hard disk. If a key is not pressed, then main() continues on to
call the image_*_ext() functions.

I had already tried to put RETN at the end of L1 section.
I still did not understand why, but when I do that, extended BIOS is not
executed… I put hlt command to check if L1 section is executed, but
system does not halt. Any clues on what is happening?

It really should halt; I don’t see how placing an extra instruction
could cause the whole thing to not even execute. Are you sure you ran
mkrom against the new IPL after you modified and rebuilt it? If not,
there will be no valid signature or checksum at the beginning of the
BIOS extension, and that would cause it to not execute.

At this point, I would suggest that you contact the hardware and / or
BIOS manufacturer, and find out some more detail on exactly how the
BIOS scans for and executes the BIOS extension.


Dave Green (dgreen@qnx.com)

QNX Software Systems Ltd.
http://www.qnx.com

I had already tried to put RETN at the end of L1 section.
I still did not understand why, but when I do that, extended BIOS is not
executed… I put hlt command to check if L1 section is executed, but
system does not halt. Any clues on what is happening?

It really should halt; I don’t see how placing an extra instruction
could cause the whole thing to not even execute. Are you sure you ran
mkrom against the new IPL after you modified and rebuilt it? If not,
there will be no valid signature or checksum at the beginning of the
BIOS extension, and that would cause it to not execute.

Yes. I am sure I used mkrom on the new IPL I created. It does not matter
what I change in the IPL code, it does not work anymore. I suspect that
there is a bug in mkrom. As I could see, mkrom just write a 6-byte header
and pad with ffh at the end to a 1024-byte boundary, right? I would like to
know what this 6-byte header means, and how checksum is calculated…


At this point, I would suggest that you contact the hardware and / or
BIOS manufacturer, and find out some more detail on exactly how the
BIOS scans for and executes the BIOS extension.

Regards,

Ricardo Kazumi Ashikawa

I had already tried to put RETN at the end of L1 section.
I still did not understand why, but when I do that, extended BIOS is not
executed… I put hlt command to check if L1 section is executed, but
system does not halt. Any clues on what is happening?

It really should halt; I don’t see how placing an extra instruction
could cause the whole thing to not even execute. Are you sure you ran
mkrom against the new IPL after you modified and rebuilt it? If not,
there will be no valid signature or checksum at the beginning of the
BIOS extension, and that would cause it to not execute.

At this point, I would suggest that you contact the hardware and / or
BIOS manufacturer, and find out some more detail on exactly how the
BIOS scans for and executes the BIOS extension.

Sorry, I guess mkrom is running correctly. Problem here is that I am not
able to revect int 19h to L2 section, and I do not know why.
We already have an embedded system using same flash and extended BIOS
mechanism, and it is working perfectly. However, even if I get same code and
use on L1 section, it does not work. Are you sure L2 section is correct? I
did not check it yet…


Regards,

Ricardo Kazumi Ashikawa

I had already tried to put RETN at the end of L1 section.
I still did not understand why, but when I do that, extended BIOS is
not
executed… I put hlt command to check if L1 section is executed, but
system does not halt. Any clues on what is happening?

It really should halt; I don’t see how placing an extra instruction
could cause the whole thing to not even execute. Are you sure you ran
mkrom against the new IPL after you modified and rebuilt it? If not,
there will be no valid signature or checksum at the beginning of the
BIOS extension, and that would cause it to not execute.

At this point, I would suggest that you contact the hardware and / or
BIOS manufacturer, and find out some more detail on exactly how the
BIOS scans for and executes the BIOS extension.

Sorry, I guess mkrom is running correctly. Problem here is that I am not
able to revect int 19h to L2 section, and I do not know why.
We already have an embedded system using same flash and extended BIOS
mechanism, and it is working perfectly. However, even if I get same code
and
use on L1 section, it does not work. Are you sure L2 section is correct? I
did not check it yet…

Problem solved!!! Some of x86 boards here has another extended BIOS that
revects int 19h too, so, L2 section was never executed.
However, our target board does not have this extended BIOS and everything
worked perfectly.

Thank you all that helped me making my embedded system run!!!


Ricardo Kazumi Ashikawa