Christophe Hannoyer
|
Re: Diskboot, io-hid and ps2ser
|
Christophe Hannoyer
10/01/2009 8:20 AM
post39166
|
Re: Diskboot, io-hid and ps2ser
Hi all,
Nobody can help me on this issue?
I'm in contact with the BIOS developer and we want to try to see if there is a possibility to fix the problem there.
Can I have at least more information (source code?) about the error message 'error sending to device'?
It seems also to be related with this:
http://community.qnx.com/sf/discussion/do/listPosts/projects.core_os/discussion.newcode.topc9406
And there Malte Mundt told that it's a known problem. Can someone give more details?
The solution he gave on that topic can help to get the system to run but it's really annoying to have to do the
installation on a first system to use on an other one.
Christophe
|
|
|
Christophe Hannoyer
|
Re: Diskboot, io-hid and ps2ser
|
Christophe Hannoyer
10/19/2009 4:59 AM
post40189
|
Re: Diskboot, io-hid and ps2ser
Really nobody?
Is there a way to get at least the source code to see if this can be fixed at the BIOS level?
|
|
|
Christophe Hannoyer
|
Re: Diskboot, io-hid and ps2ser
|
Christophe Hannoyer
10/20/2009 5:39 AM
post40308
|
Re: Diskboot, io-hid and ps2ser
I'm sorry for this 3rd reply to myself but this problem is really annoying for our customer and I still expect that
someone in the QNX team in charge of this can handle this.
Today I get this report form your BIOS developer. It show that the problem is inside of diskboot and then we can't solve
the problem without the help of QNX.
Thanks,
Christophe
Here is the report:
I have a F18 and the emulator connected. During the message 'Now starting io-hid' I can see, that the QNX-code access to
the port 64.
Normally, there is a register from the keyboard controller which returns a value (for example a key is available or not
available).
But in our case there is nothing and the return value is FFh; QNX testing the return value in a loop in the hope of
status change.
But there is no change and QNX reports: 'error sending to device'.
From my side I would say, that QNX doesn't support a "legacy-free PC" design (like our F17/F18/F19).
Legacy-free means, among other things, that there is no keyboard controller on the I/O ports 60h and 64h.
The chipset of the F17/F18/F19 support this legacy mode and provides a special functionality at the USB controller.
For the USB controller it is possible to configure normal PCI Interrupts or SMI Interrupts. Furthermore it is possible
to select that a read on port 64h will cause an SMI event. With the help of this mechanism it possible to install a code
at the SMI handler, that could be able to emulate a keyboard controller.
The BIOS configures the USB controller in this way and the keyboard emulation is active during the BIOS-POST, at DOS and
for example at the GRUB bootloader.
What happens if QNX starts?
QNX reinitialize the USB controllers and confígures 'normal' PCI interrupts and switch-off the functionality that a
read on port 64h will cause an SMI interrupts (I can see that also with the emulator).
--> So it is not possible to install a code that can emulate a keyboard controller.
Sorry, but this is also valid for the F19P. It is necessary that QNX supports the USB keyboard with a proper USB stack.
Code-Loop during 'Now starting io-hid':
00F3:B820F753 8B4714 MOV EAX,dword ptr [EDI]+14 <-------------
00F3:B820F756 890424 MOV dword ptr [ESP],EAX |
00F3:B820F759 E8729BFFFF CALL near32 ptr b82092d0 |
00F3:B820F75E 83EE01 SUB ESI,00000001 |
00F3:B820F761 740A JE short ptr b820f76d |
00F3:B820F763 8B572C MOV EDX,dword ptr [EDI]+2c |
00F3:B820F766 EC IN AL,DX <---- DX = 64 |
00F3:B820F767 A802 TEST AL,02 AL = FF |
00F3:B820F769 75E8 JNE short ptr b820f753 -------------------
00F3:B820F76B EB19 JMP short ptr b820f786
00F3:B820F76D 8B8360010000 MOV EAX,dword ptr [EBX]+00000160
00F3:B820F773 833802 CMP dword ptr [EAX],00000002
00F3:B820F776 7E0E JLE short ptr b820f786
00F3:B820F778 8D83E9DFFFFF LEA EAX,dword ptr [EBX]-00002017
00F3:B820F77E 890424 MOV dword ptr [ESP],EAX
00F3:B820F781 E81A9AFFFF CALL near32 ptr b82091a0
|
|
|