how do i load Onboard NIC driver and how to use it ?
hi , Brendan
i should tell you my routine's run environment:
1 my routine is written into the NIC's option ROM.
2 the NIC is installed in client machine( not in PXE server).
3 the disk of client machine doesn't have any OS.
4 i could not configure the BIOS (or NIC ROM) on the client machine to boot from network. the reason is my routine is a part of my product, it will sell out, i can't make any client configure this, because all client don't want to do this.
so, i must load the onboard NIC's driver and connect the server use DHCP, and downland bootstrap use TFTP, by myself(in my routine in NIC's ROM in client machine). it means the all PXE routine in BIOS must done by myself, but except the NIC's UNDI driver, i only load it and call UNDI interface.
i do it like this:
step 1: I change the segment and offset of int 19h interrupt routine into my own routine.
step 2: i load the Onboard NIC's driver in my own routine. so ,i can transmit and receive data use UNDI function through NIC.
step 3: i connect the PXE server. then download bootstrap routine.
i have done step 1.
i don't know how to do step 2(how to load onboard NIC's driver). so i can't coutinue.
i did some test today.
i found BIOS load Onboard NIC's Driver after call int 19h. may be load Onboard NIC's Driver in 19h interrupt .
so , if i know how to load Onboard NIC's driver in 19h interrupt routine.
i could do my step 2.
i decide to try to track 19h interrupt routine.
i should tell you my routine's run environment:
1 my routine is written into the NIC's option ROM.
2 the NIC is installed in client machine( not in PXE server).
3 the disk of client machine doesn't have any OS.
4 i could not configure the BIOS (or NIC ROM) on the client machine to boot from network. the reason is my routine is a part of my product, it will sell out, i can't make any client configure this, because all client don't want to do this.
so, i must load the onboard NIC's driver and connect the server use DHCP, and downland bootstrap use TFTP, by myself(in my routine in NIC's ROM in client machine). it means the all PXE routine in BIOS must done by myself, but except the NIC's UNDI driver, i only load it and call UNDI interface.
i do it like this:
step 1: I change the segment and offset of int 19h interrupt routine into my own routine.
step 2: i load the Onboard NIC's driver in my own routine. so ,i can transmit and receive data use UNDI function through NIC.
step 3: i connect the PXE server. then download bootstrap routine.
i have done step 1.
i don't know how to do step 2(how to load onboard NIC's driver). so i can't coutinue.
i did some test today.
i found BIOS load Onboard NIC's Driver after call int 19h. may be load Onboard NIC's Driver in 19h interrupt .
so , if i know how to load Onboard NIC's driver in 19h interrupt routine.
i could do my step 2.
i decide to try to track 19h interrupt routine.
Just For Fun
Hi,
If you're writing your own NIC ROM, then you need to write everything that should be in that NIC's ROM, including your own NIC driver, your own UNDI, your own DHCP code, your own TFTP code, your own PXE API/s, etc. The BIOS itself contains none of this.
I have no idea why you'd want to do this (I assumed you wanted to write a PXE boot loader for an OS, and not a device's ROM). Maybe playing with this thing for a while will save you a lot of work...
Cheers,
Brendan
If I understand you correctly (I'm guessing a bit), then...david wrote:i should tell you my routine's run environment:
1 my routine is written into the NIC's option ROM.
2 the NIC is installed in client machine( not in PXE server).
3 the disk of client machine doesn't have any OS.
4 i could not configure the BIOS (or NIC ROM) on the client machine to boot from network. the reason is my routine is a part of my product, it will sell out, i can't make any client configure this, because all client don't want to do this.
so, i must load the onboard NIC's driver and connect the server use DHCP, and downland bootstrap use TFTP, by myself(in my routine in NIC's ROM in client machine). it means the all PXE routine in BIOS must done by myself, but except the NIC's UNDI driver, i only load it and call UNDI interface.
If you're writing your own NIC ROM, then you need to write everything that should be in that NIC's ROM, including your own NIC driver, your own UNDI, your own DHCP code, your own TFTP code, your own PXE API/s, etc. The BIOS itself contains none of this.
I have no idea why you'd want to do this (I assumed you wanted to write a PXE boot loader for an OS, and not a device's ROM). Maybe playing with this thing for a while will save you a lot of work...
None of that makes sense for a "Network Bootstrap Program" (a boot loader that uses PXE to boot an OS from network); and none of it makes sense for a device's ROM (which needs to comply with the relevant (PCI?) specifications for device ROMs). In both cases you shouldn't need to do anything with Int 0x19.david wrote:i do it like this:
step 1: I change the segment and offset of int 19h interrupt routine into my own routine.
step 2: i load the Onboard NIC's driver in my own routine. so ,i can transmit and receive data use UNDI function through NIC.
step 3: i connect the PXE server. then download bootstrap routine.
You can do step 3 without doing step 1 or step 2 - just use etherboot if the computer doesn't already support booting from network.david wrote:i have done step 1.
i don't know how to do step 2(how to load onboard NIC's driver). so i can't coutinue.
At 6:00 in the morning I wanted to see cars driving around town but there weren't many. To fix this, at 7:30 in the morning I stuck my finger in my eye. This worked well - at 9:00 in the morning there were cars driving around everywhere. Now all I need to do is figure out how to stop the pain and I'll be able to see lots of cars driving around anytime I like.david wrote:i did some test today.
i found BIOS load Onboard NIC's Driver after call int 19h. may be load Onboard NIC's Driver in 19h interrupt .
so , if i know how to load Onboard NIC's driver in 19h interrupt routine.
i could do my step 2.
i decide to try to track 19h interrupt routine.
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
I know how to do.
1: Scan memory to find PXE image from 0C0000h to 0F0000h.
2: Find UNDI Loader's offset in UNDI ROM ID Structure. then call it.
3: Find PXE API entry point for 16-bit stack segment in !PXE structure, It also is UNDI API entry point.
4: Call PXENV_START_UNDI PXENV_STOP_UNDI PXENV_UNDI_STARTUP PXENV_UNDI_CLEANUP and so on.
5: then, you can transmit packet, and hook the ISR to receive data using UNDI driver.
I give my best regards to you.
Thanks.
I will send my testing code to you If you want.
1: Scan memory to find PXE image from 0C0000h to 0F0000h.
2: Find UNDI Loader's offset in UNDI ROM ID Structure. then call it.
3: Find PXE API entry point for 16-bit stack segment in !PXE structure, It also is UNDI API entry point.
4: Call PXENV_START_UNDI PXENV_STOP_UNDI PXENV_UNDI_STARTUP PXENV_UNDI_CLEANUP and so on.
5: then, you can transmit packet, and hook the ISR to receive data using UNDI driver.
I give my best regards to you.
Thanks.
I will send my testing code to you If you want.
Just For Fun
Can you send me your testing code?david wrote:I know how to do.
1: Scan memory to find PXE image from 0C0000h to 0F0000h.
2: Find UNDI Loader's offset in UNDI ROM ID Structure. then call it.
3: Find PXE API entry point for 16-bit stack segment in !PXE structure, It also is UNDI API entry point.
4: Call PXENV_START_UNDI PXENV_STOP_UNDI PXENV_UNDI_STARTUP PXENV_UNDI_CLEANUP and so on.
5: then, you can transmit packet, and hook the ISR to receive data using UNDI driver.
I give my best regards to you.
Thanks.
I will send my testing code to you If you want.
well seeing as how it is English sarcasm... it would make sense that most native English speakers would get it.
PXE sounds interesting to implement... kind of a pain, and that's why im not wasting my time right now on it in an experimental kernel, but i will probably get around to it sometime.
PXE sounds interesting to implement... kind of a pain, and that's why im not wasting my time right now on it in an experimental kernel, but i will probably get around to it sometime.
Website: https://joscor.com
yeah same, its a long way down on my todo though.01000101 wrote:well seeing as how it is English sarcasm... it would make sense that most native English speakers would get it.
PXE sounds interesting to implement... kind of a pain, and that's why im not wasting my time right now on it in an experimental kernel, but i will probably get around to it sometime.
actually everything is at the moment, i struggle to find time to browse (never mind post) on here, and i havn't had time to work on my OS for a month or so
Because the two replies after Brendan's were by david, and MarkOS, neither of which are native English speakers and neither of which seemed to realise he was being sarcastic.jal wrote:Why do you think this is the case?JamesM wrote:Can only native English speakers understand Brendan's blatant sarcasm or something...?
JAL
The post was meant in jest!
Cheers,
James
But david was replying to other parts of the post, and MarkOS was replying to david's post, not Brandan's. I agree that david shows poor understanding of the issues Brandan raises, but choosing to ignore a sarcastic remark does not mean failure to understand it. On the other hand, I'm pretty sure there are quite some native English speakers who wouldn't have gotten what the poke-in-eye part refers to.JamesM wrote:Because the two replies after Brendan's were by david, and MarkOS, neither of which are native English speakers and neither of which seemed to realise he was being sarcastic.
The post was meant in jest!
JAL