[ipxe-devel] i354 support in the intel driver

[Patrick Agrain]

BTW, I forgot to mention that I already faced such a behavior several 
months ago when trying to patch a more recent iPXE snapshot with the igb 
driver. At that time, I made no deeper investigation and kept what was 
working.

a) First patch was made with a snapshot from 6th of february.
b) The operation mentioned above was performed with a snapshot from ... 
(I cannot remember).
c) And now, trying to patch the intel driver, I use a clone from 24th of 
september.
d) I also backported the intel driver patch( from c) ) into the snapshot 
from 06th of february.

Result:
a) works (still today...)
b) and c) doesn't.
d) works (not like a), but we are going much further than b) and c) ). 
Here, I think that the intel patch is not complete.

Using a snapshot from later than this from 06th of february fails like 
b) and c).
Hope it may help to surround the problem.
Kind regards,
Patrick

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.
>
> 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.
>
> 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).
>
> Michael