[9fans] loading plan 9 directly from linuxbios

[9fans] loading plan 9 directly from linuxbios

[ron minnich]

I'm working to get plan 9 to load directly from linuxbios. The first
problem I've hit is that Plan 9 assumes that the gdt table is set up by
9load in a friendly fashion. Because linuxbios has to accomodate so many
different OSes with directly conflicting GDT setups, it's not really
practical to try to make linuxbios have a plan 9 friendly gdt. I'd like to
have plan 9 just set up its own gdt correctly.

I'm trying to get this to work but am still at the 'system wedges up'
stage. here is my (doubtless incorrect) code. Can somebody remind me what
the MSW is.

Also what is a reasonable way to do this:
	$PADDR($tgdtptr(SB))
or is that impossible?


TEXT _start0x00100020(SB),$0
        CLI            /* make sure interrupts are off */
        /* for linuxbios. */
        /* now set up the gdt so we have sane plan 9 style gdts. */
        MOVL    $tgdtptr(SB), AX
        ANDL    $~KZERO, AX
        MOVL    (AX), GDTR
/*      MOVL    $tgdtptr(SB),GDTR /**/
        MOVW    $1, AX
        MOVW AX,MSW
/*
 *      clear prefetch queue (weird code to avoid optimizations)
 */
        DELAY

/*
 *      set all segs
 */
        MOVW    $(1<<3),AX      /**/
        MOVW    AX,DS
        MOVW    AX,SS
        MOVW    AX,ES
        MOVW    AX,FS
        MOVW    AX,GS

/*      JMP     $(2<<3):$mode32bit(SB) /**/
         BYTE   $0xEA
         LONG   $mode32bit-KZERO(SB)
         WORD   $(2<<3)

TEXT    mode32bit(SB),$0
	/* end linuxbios stuff */
        MOVL    $PADDR(CPU0PDB), DI             /* clear 4 pages for the
tables
etc. */
        XORL    AX, AX
        MOVL    $(4*BY2PG), CX
        SHRL    $2, CX

etc.
etc.



The GDT is this:

/* for linuxbios mods. *
/*
 *  gdt to get us to 32-bit/segmented/unpaged mode
 */
TEXT    tgdt(SB),$0

        /* null descriptor */
        LONG    $0
        LONG    $0

        /* data segment descriptor for 4 gigabytes (PL 0) */
        LONG    $(0xFFFF)
        LONG    $(SEGG|SEGB|(0xF<<16)|SEGP|SEGPL(0)|SEGDATA|SEGW)

        /* exec segment descriptor for 4 gigabytes (PL 0) */
        LONG    $(0xFFFF)
        LONG    $(SEGG|SEGD|(0xF<<16)|SEGP|SEGPL(0)|SEGEXEC|SEGR)

/*
 *  pointer to initial gdt
 */
TEXT    tgdtptr(SB),$0

        WORD    $(3*8)
        LONG    $tgdt-KZERO(SB)



I suspect the tgdtptr is bogus ... probably an 0x8000xxxx address.

Any hints welcome.

ron

Re: [9fans] loading plan 9 directly from linuxbios

[Charles Forsyth]

>>Also what is a reasonable way to do this:
>>	$PADDR($tgdtptr(SB))
>>or is that impossible?

that's impossible.

masking it off as you do is fine.

>>I suspect the tgdtptr is bogus ... probably an 0x8000xxxx address.

i'd expect so, although nm on the executable will show you.

the deeper problem is that (as i understand it) you're entering the code
in real mode, which is of course quite unreal.  in that case you'll
need to do what 9load does in l.s (using x16.h) to write the real mode
code, because 8a/8l isn't very good at 16-bit code
(though 8l could make it easier, with some as yet unquantified amount of work).

i'd put it what's needed a separate l16.s prefix, using x16.h
to write it (most of what you need is at the start of 9load's l.s),
then link l16.$O in front of a slightly modified l.$O and enter the kernel at l16.$O's start.

Re: [9fans] loading plan 9 directly from linuxbios

[C H Forsyth]

>>i'd put it what's needed a separate l16.s prefix, using x16.h

i meant: i'd put what's needed in ...

Re: [9fans] loading plan 9 directly from linuxbios

[ron minnich]

On Wed, 29 Oct 2003, Charles Forsyth wrote:

> the deeper problem is that (as i understand it) you're entering the code
> in real mode, which is of course quite unreal.  in that case you'll need
> to do what 9load does in l.s (using x16.h) to write the real mode code,
> because 8a/8l isn't very good at 16-bit code (though 8l could make it
> easier, with some as yet unquantified amount of work).

Entering from linuxbios and also from 9load, you are entering plan 9 in
32-bit protected mode with the gdt set up. The issue from linuxbios is
that the gdt is not Plan9-compatible. I think it is probably good hygiene
for plan 9 to be able to operate under other loaders than 9load, so
overall it is probably good for Plan 9 to assume

- machine is in protected mode (but no paging turned on)
- gdt is maybe right, but maybe wrong
- lgdt can be used in 32-bit mode
- plan 9 should reload the gdt in l.s, 32-bit instructions, before
  it sets up paging

ron

Re: [9fans] loading plan 9 directly from linuxbios

[David Presotto]

It's good hygeine but you have to assume something.  Assuming 32 bit mode
is already way too much, we're in 16 bit mode when entered from the normal
BIOS.

Re: [9fans] loading plan 9 directly from linuxbios

[ron minnich]

On Wed, 29 Oct 2003, David Presotto wrote:

> It's good hygeine but you have to assume something.  Assuming 32 bit mode
> is already way too much, we're in 16 bit mode when entered from the normal
> BIOS.

in plan 9? I know that's the way it is in 9load, but in plan 9 it looks to
me like it assume that 9load enters plan 9 in protected mode. 9load sets
up protected mode as far as i can see.

ron

Re: [9fans] loading plan 9 directly from linuxbios

[ron minnich]

On Wed, 29 Oct 2003, ron minnich wrote:

> On Wed, 29 Oct 2003, David Presotto wrote:
>
> > It's good hygeine but you have to assume something.  Assuming 32 bit mode
> > is already way too much, we're in 16 bit mode when entered from the normal
> > BIOS.
>
> in plan 9? I know that's the way it is in 9load, but in plan 9 it looks to
> me like it assume that 9load enters plan 9 in protected mode. 9load sets
> up protected mode as far as i can see.

foolish me, I misunderstand. Dave, you're taking this further than I
thought about. I'm always ignoring those commercial BIOSen with their
penchant of entering your code in 16-bit mode, possibly I'm blocking out
bad memories.

To start, I'm going to go with the protected-mode assumption as I want to
get the EPIA boards booting Plan 9 direct from flash. Then, later, we can
get into the lovely 16-bit issue. The problem there is Plan 9 loads at
0x100000 and that's a pain to deal with in 16-bit mode. We're going to
need a little hook in the low 640K to set those things up. It starts to
suck at that point.

ron

Re: [9fans] loading plan 9 directly from linuxbios

[C H Forsyth]

>>that the gdt is not Plan9-compatible. I think it is probably good hygiene

what is incompatible about the gdt?
to what is it initialised?

Re: [9fans] loading plan 9 directly from linuxbios

[ron minnich]

On Wed, 29 Oct 2003, C H Forsyth wrote:

> >>that the gdt is not Plan9-compatible. I think it is probably good hygiene
>
> what is incompatible about the gdt?
> to what is it initialised?


linuxbios follows the linux gdt setup. offset 10 is code, offset 18 is
data. ds, es, etc. are set to 18, cs is set to 10.

Plan 9 sets GDT SEL 8 to data; and ds, etc. need to be set to 8.

Currently I am exploding in Plan 9 after linuxbios loads it and I am
almost certain it is due to this incompatibility.

ron

RE: [9fans] loading plan 9 directly from linuxbios

[ron minnich]

On Wed, 29 Oct 2003, Tiit Lankots wrote:

> >stage. here is my (doubtless incorrect) code. Can somebody
> >remind me what
> >the MSW is.
>
> MSW is the low 16 bits of CR0. Writing 1 into it sets the PE bit
> (i.e. switches to protected mode).

Thanks, I found that last night too, this is good to have confirmation.

I clearly don't need this from linuxbios, as it's already in protected
mode, but I see no harm in leaving it in.

ron

RE: [9fans] loading plan 9 directly from linuxbios

[Tiit Lankots]

>stage. here is my (doubtless incorrect) code. Can somebody 
>remind me what 
>the MSW is.

MSW is the low 16 bits of CR0. Writing 1 into it sets the PE bit
(i.e. switches to protected mode).

Tiit