BTX & etc

The real one question, to find answer to, was: use PXE in protected mode (which is hazy documented in Intel specs and PXE SDK), or do everything in real mode, except memory copy routines, which start protected mode and end it after copy operation (this case is good, but limits usage of commonly used fuctions, that I wanted to use from libstand).

Now I am thinking, the best way – to use BTX and virtual 86 mode or do something similar on basis of BTX v86 monitor and protect mode initialisation.

So, here again to ways:

1. implement “disk via http” for loader (as PXE here: libi386/pxe.c ) and use tcp lib for that.

2. make independent solution based on tcp lib and initialisation code similar to BTX, but it needs more reading, how kernel loads if no drive is specified.

common in this two cases is – tcp lib, so I’ll start from this. Then best choice to do code in common way “disk via http”, that will test main tcp lib code work and usability. And then will be time to think about independent solution, which requires more information about kernel arguments and more understanding of bootinfo struct usage.

Although libstand will be used, calls to it functions (memory allocation, timer, console out) will be through wrappers with `pxe_` prefix. That will be useful, if somewhere in future I’ll decide not use libstand, also it may be more flexible for porting or code usage in other OS, which have no libstand.

Well, libi386/pxe.c already uses such prefix (pxe_open(), pxe_enable() and etc), but I think usage will be different and there would not any naming problems. For “drive over http” will be used `pxe_http_` prefix.

I think first recieve/send buffers will be static to avoid dynamic allocation. In case of this project it’s possible, cause pxe_http code must handle practically one connection most of time.

Hm, today I’ll try to include pxe_http dummy support to loader and look how it works. After success I’ll sync some files via perforce. And we’ll see if I understand tuning p4 client correctly.

2 Responses to “BTX & etc”

  1. gcooper says:

    Just curious — what particular portion of the specs are hazy? Maybe I can rattle a few bushes for you over in Folsom :).

  2. taleks says:

    Well, in fact all specs throughout :) It’s based on 16 bit real mode code. All examples are also using 16 bit asm code or 16bit C.

    The only thing that is definitly – that protected mode with 32 bit stack is not suppoprted in some UNDI functions. But it’s not said e.g., when PXE! structure fields related to segments selectors are filled if system starts in real mode and my code will start PM. It’s said “filles in by UNDI before any calls are made”. But, how it’ll find selector in my space? Or I must use this selector and load GDT uusing provided values. And etc. It’s a little bit hazy for me.

    Thanks for you help suggestion, but as I see in Etherboot and other PXE related projects (pxeboot in FreeBSD), main trick is to go in real mode (to be more correct: virtual 86 mode) before calling PXE and UNDI functions, so I’ll do the same and thus it will not be protected mode problems in working with PXE. At least, I hope for that.