* Ronald G Minnich <[EMAIL PROTECTED]> [020417 04:00]:
> > i stripped down inthandler.c so testbios branches into the
> > specific intXX_handler function. This works fine, but leads
> > to the next problem, which has already been discussed on this list.
>
> I sleazed it out to keep things simple. I have int handler stuff from the
> X11 stuff that just does direct I/O. In the program I do an iopl(3) (you
> probably saw this)
Next thing i was wondering about is the calls to setup_int() and
finish_int(). What exactly are these there for? Looks like interrupts
are planned to be executed with a 'different set' of x86 registers.
Is this needed vor running the thing in vm86 mode later on?
> I think we just stick with direct I/O, but in linuxbios we can always call
> linuxbios functions (see src/bios/bioscall.c for int1a support that has
> been tested and works).
Maybe it makes sense to make this configurable during compile time. If
this works, I could finally get rid of the crappy commercial x86
emulation used in Milo.
> > Has anyone played with loading several elf payloads in a row?
>
> this begins to look perilously like an operating system ... several elf
> payloads in a row ... oh boy. It worries me.
It don't need to. This is a pretty common way of having firmware
configurable. AMI and Award do the same thing, using lh5 packed
payload files melted together. They have utilities merging or extracting
those. If a motherboard has onboard vga, you just add the vga bios to
the image and you're done.
> if we go down the path this far we ought to see about putting a really
> small OS in there. It's a shame linux no longer qualifies as a "really
> small" OS.
The Linux way has served pretty good up to now. So did etherboot. But as
all software, operating systems are mostly written to solve a certain
problem set, thus often not including "slim kernel with small polling
drivers".
Therefore in long term I want to get the OpenBIOS evaluator far enough
to be executed as payload. This will then be capable of intializing
components. And yes, there are quite some nv, ati, permedia2 cards
supported by this as well. If not, a slim and generic vga-testbios can
solve this. This evaluator exists and is capable of executing fcode
bytecode already, but it's currently being redesigned to be a lot
smaller (<20k executable)
Best regards,
Stefan Reinauer
--
Ok hex 4666 dup negate do i 4000 dup 2* negate do " *" 0 dup 2dup 1e 0 do
2swap * e >>a 2* 5 pick + -rot - j + dup dup * e >>a rot dup dup * e >>a
rot swap 2dup + 10000 > if 3drop 3drop " " 0 dup 2dup leave then loop
2drop 2drop type 268 +loop cr drop 5de +loop
