Some Issues with real hardware and PXE

[timmil...@gmail.com]

Hello all,

I am attempting to run BMOS on an Asus X99-A motherboard with an Intel I7-5820K cpu. I can PXE boot the board just fine. I see the output from Pure64 (so I think, could be from the Intel Lan controller, and it is fast to disappear), it seems as though the kernel does in fact boot as I will get random binary (0's and 1's) on the screen. I have yet to see a cursor or have anyway to debug it. I did add a ; to comment out the init_hdd. I had the thought that maybe it was because I had the MB overclocked and BMOS was getting the stock clock speed from the cpu and not getting my real clock speed, so I reset the MB back to stock clock settings. I also have the thought that maybe the Intel SpeedStep is causing an issue? Any input or ideas would be welcomed.

I think my next test will be to lock it in Pure64 to see what point it starts to go south and then move to the kernel and stop the cpu one part at a time. Not sure how I can debug it enough to gather useful info. I really don't have a desire to run in a emulator unless I have to.

-Tim

[Tim M]

OK, I have narrowed it to the NIC driver. I have an Intel I218V NIC on board and the driver is N/A. Anyone have an idea of where to start to write my own? I am comfy working in ASM, just need a starting point.

[42Bastian]

Am 19.09.2015 22:57, schrieb Tim M:
> OK, I have narrowed it to the NIC driver. I have an Intel I218V NIC on
> board and the driver is N/A. Anyone have an idea of where to start to write
> my own? I am comfy working in ASM, just need a starting point.

Get all the information about the NIC you can get.
If you do not mind making your driver GPL, check out the Linux driver.

--
42Bastian

[Tim M]

Got the network going now. Just had to add a few lines to the existing drivers.asm. The i8254 driver was in fact the same as what I needed after looking at the freeBSD driver from Intel. I added this: dd 0x15598086 ;I218-V dd 0x155A8086 ;I218LM dd 0x15A18086 ;I218-V again. Now I get a MAC from the NIC on boot. I am still having the original issue that the code takes off into the weeds when it does the cli in app_clear. This issue is isolated to this MB/CPU combo. I have been testing the same code on an older Core2 Duo and it runs as expected. Will be adding some debug code today and try to see why is it crashing. Does anyone know a way I can JTAG the CPU? being able to step the code on the problem hardware would be best.

-Tim

[Ian Seyler]

Intel is pretty good about documenting their hardware. I used their SDM to write the i8254x driver. Does that mobo have a serial port?

So you just added some new PCI IDs? Does send/receive work?

Also, you can add a 'jmp $' anywhere in the code to effectively halt the kernel and see when it doesn't crash anymore. I've used this before when debugging real hardware.

-Ian

[Tim M]

Ian,

I have narrowed it down that I need to write a CPU driver for this combo/ MB has a footprint for RS232 connector, but it is not populated. I essentially had the same jmp as you asked for. Mine was loop: jmp loop and if I have that like so:

ap_clear: ; All cores start here on first start-up and after an exception

;DEBUG CODEl

loop:

jmp loop ;halt instructions for debugging

;END DEBUG CODE

cli ; Disable interrupts on this core

it will halt the cpu. I will try to comment out the serial port init and report back.

-Tim

[Tim M]

Still went into no mans land. I really think it is the CPU driver myself. Any ideas of more testing?

[Tim M]

I think I am onto the problem. The MOBO uses an acpiV5, which also explains why it doen't report the cpu speed and numbers of cores correctly. Time to sort it out and fix it.

-Tim

On Monday, September 21, 2015 at 9:34:51 AM UTC-4, Ian Seyler wrote:

[Ian Seyler]

CPU speed is calculated with the rdtsc opcode. It's not the ideal method but generally works OK.

ACPI v5 should still be compatible but I will have to do some research to see what has changed.

-Ian