<br><br><div class="gmail_quote">On Fri, Jun 25, 2010 at 3:23 AM, Michael Brown <span dir="ltr"><<a href="mailto:mbrown@fensystems.co.uk">mbrown@fensystems.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Thursday 24 Jun 2010 20:14:35 Glenn Brown wrote:<br>
> Since you say "our OS" it sounds like you are writing your own OS.<br>
> If so, I expect you might work around the BIOS not loading and<br>
> initializing the gPXE ROM by having the OS do it. Specifically:<br>
> Scan the PCI bus for Ethernet network devices with<br>
> PCI expansion ROMs.<br>
> Scan the PCI expansion ROM chain for the ROM compatible<br>
> with your architecture.<br>
> Copy the ROM into low memory allocated from the BIOS.<br>
> Call the ROM's POST entry point.<br>
> I believe that would register PXE and UNDI, assuming the BIOS still<br>
> provides the necessary PCI access and low memory allocation support<br>
> required by gPXE.<br>
<br>
</div>The problem is that various BIOS services will no longer be available / be<br>
safe to use once the (presumably protected mode) OS has loaded. Some<br>
services, such as PMM, become unavailable even before the OS's first-stage<br>
bootloader can execute.<br></blockquote><div><br></div><div><div>I would like to have a try of Glenn's idea if UNDI Loader cannot functions well, that's must be interesting! While, as Michael said, the key is various BIOS services become available or unsafe to use. Is it possible to modify OS or add some function to reactive these services? </div>
</div><div>PMM: POST Memory Management? what's this .....</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
> If your OS runs in 32-bit or 64-bit mode, using 16-bit PXE/UNDI must be<br>
> horribly complex. However, I believe gPXE can provide an EFI SNP<br>
> interface over PXE, possibly hiding the complexity, and providing a<br>
> 64-bit interface that can be used on 32-bit and 64-bit systems. So, if<br>
> you make your OS expect the EFI SNP interface, then you may be able to<br>
> layer the OS over both PXE/UNDI via a gPXE shim, or over native EFI<br>
> drivers.<br>
<br>
</div>The EFI specification authors seem to think that would be a sensible way to<br>
write an OS network driver. It may be a viable option; I'm not aware of<br>
anyone having done it yet. (Performance is likely to suck, for a start.)<br><font class="Apple-style-span" color="#888888"><br></font></blockquote><div> </div><div>EFI, sounds good! Maybe it is more valuable for me to try it, which my boss talked about with me and suggested to do some investigation about, several days ago. Any instructions about it?</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><font color="#888888">
Michael<br>
</font></blockquote></div><br><div>For your interest, here is some information about our OS:</div><div>Firstly, it's derived from NetBSD at very beginning, but till now, it is totally different from its forefather. Apparently, it is based on X86 arch, and a 32 bit OS, and its arm version is just on development. </div>
<div>Secondly, it's rather small, say 4M~9M, not just a kernel, including some specialized applications. It would be embedded into our own hardware, so actually, it is a 32-bit UNIX-like OS for embedded system. Also it has its own boot loader.</div>
<div>Finally, our goal is keep it small, fast and security as possible as we can.</div><div><br></div><div>Since it is proprietary, so no GPL code with it, that means we cannot use Linux driver directly. Moreover, due to its kernel become too different from NetBSD, it also become tricky to port BSD drivers. (We have tried to move it back to be with BSD heart, but it failed eventually). So, if UNDI works, it will be great for us! Therefore, it becomes a researching project. However, unfortunately, till now, I don't find a positive comment about UNDI driver used in PM mode, but all about complexity, big performance hit and so on. Maybe, eventually, it would be die out ... Anyway, I still want to push it because I find it really interesting and I can learn a lot, esp. from you all and the community:).</div>
<div><br></div><div>Till now, I develop it on Bochs by booting from network using gpxe and cancelling it to turn to disk boot, so that there will be !PXE in memory. And then, in kernel, I start UNDI driver. I can send packet successfully, but still have problem receive packets because there is no interrupt arrived, and I'm not yet clear about the mechanism of UNDI interrupt. Can I receive INT of UNDI in PM mode? I notice gpxe registers its IRQ handler to BIOS interrupt vector, is it a MUST? Any suggestion?</div>
<div> </div><div>Since English is not native language for me, so maybe it is a little hard to understand, if any mistake or non-native expression, please help point out, if you like. It will be help for me. I'm struggling for GRE&TOEFL ...</div>
<div><br></div><div><br></div><div>Thanks, Thanks, Thanks,</div><div>Sean</div><div><br>
</div><div><br></div><div><br></div><div><br></div>