[ipxe-devel] i354 support in the intel driver

[Patrick Agrain]

Hello,

Le 01/10/2015 15:15, Michael Brown a écrit :
> On 30/09/15 16:43, Patrick Agrain wrote:
>> I tought that a first step could be to add the PCI_ROM() macro with the
>> correct IDs, so that the device should be, at least, probed.
>> The console output let me think that this is even not reached.
>>
>> Am I missing anything in the procedure ?
>> Is there a way to increase the debug level ?
>>
>> <snip>
>>
>> Booting from ROM...
>> Booting from c100:0361
>> iPXE (PCI 00:14.0) starting execution...ok
>>
>> Note: from here it hangs...
>
> So, it looks as though you may not be successfully reaching main(). 
> This kind of problem is difficult to track down outside of a VM, 
> unless you have some kind of hardware debugger available.
Though I have a hardware debugger, I'm not able to pick up a location 
where to put a breakpoint. This is the code where I hang:
<...>
F000:FF08 0000             ADD         byte ptr [BX+SI],AL
F000:FF0A 66E89CACFFFF     CALL        near32 ptr abac
F000:FF10 6631C0           XOR         EAX,EAX
F000:FF13 E6F0             OUT         f0,AL
F000:FF15 B020             MOV         AL,20
F000:FF17 E6A0             OUT         a0,AL
F000:FF19 E620             OUT         20,AL
F000:FF1B 66BA26000000     MOV         EDX,00000026
F000:FF21 67668D442402     LEA         EAX,dword ptr [ESP]+02
F000:FF27 664A             DEC         EDX
F000:FF29 67C6041000       MOV         byte ptr [EAX][EDX],00
F000:FF2E 6685D2           TEST        EDX,EDX
F000:FF31 75F4             JNE         short ptr ff27
F000:FF33 67C74424260002   MOV         word ptr [ESP]+26,0200
F000:FF3A 66BA87D50000     MOV         EDX,0000d587
F000:FF40 660FB7D2         MOVZX       EDX,DX
F000:FF44 66E89D9AFFFF     CALL        near32 ptr 99e7
F000:FF4A 6683C428         ADD         ESP,00000028
F000:FF4E 66C3             RETN
F000:FF50 CD19             INT         19
F000:FF52 CB               RETF
F000:FF53 CF               IRET <------------------------
>
> My recommendation would be to first find the simplest and most 
> reliable mechanism available for debug output on this board.  If you 
> have a debug I/O port available (similar to port 0xe9 in qemu VMs) 
> then use that.  If you have a text-mode VGA console attached, then try 
> writing directly to video memory at 0xb8000.  You ideally want 
> something that can work even in the middle of a transition from real 
> to protected mode.
The target is a Mohon Peak CRB. I will now try to output something on 
port 80h for which 7-segments LEDs are foreseen.
Keep you in touch.
>
> Once you have something sufficiently robust, try adding output between 
> the point that the "ok" is printed (the "call print_message" for 
> exec_message_post_install in arch/i386/prefix/romprefix.S) and the 
> point that the "initialising devices" message gets printed (in 
> core/main.c).
Find out the code portion to check:
<...>
     /* Print message indicating successful installation */
     movw    $exec_message_post_install, %si
     xorw    %di, %di
     call    print_message  <---- "ok"

     /* Set up real-mode stack */
     movw    %bx, %ss
     movw    $_estack16, %sp

     /* Jump to .text16 segment */
     pushw    %ax
     pushw    $1f
     lret
     .section ".text16", "awx", @progbits
1:
     /* Retrieve PCI bus:dev.fn, if applicable */
.ifeqs    BUSTYPE, "PCIR"
     movw    init_pci_busdevfn, %ax
.endif

     /* Set up %ds for access to .data16 */
     movw    %bx, %ds

     /* Store PCI bus:dev.fn, if applicable */
.ifeqs    BUSTYPE, "PCIR"
#ifdef AUTOBOOT_ROM_FILTER
     movw    %ax, autoboot_busdevfn
#endif /* AUTOBOOT_ROM_FILTER */
.endif

     /* Call main() */
     pushl    $main
     pushw    %cs
     call    prot_call
     popl    %eax /* discard */
<...>
>
> Michael
Kind regards,
Patrick