romcc fixes for AMD64

[Stefan Reinauer]

Hi,

with the attached fix romcc is able to compile all of auto.c
for the freebios2 amd64 targets. To keep all changes clean 
and visible, they're encapsulated in ifdefs.

Note: This fix alone does not make LinuxBIOS compile on AMD64
completely yet. GCC and ld need the -m32 in some places at least
to compile everything.

Is there any need in going 64bit for the LinuxBIOS C payload
on Opteron? Since the kernel does long mode switching itself
this should not be the case, but maybe there are different 
opinions.

Next fail I saw after romcc passed auto.c was the following:
/home/stepan/freebios2/src/superio/NSC/pc87360/superio.c:61: warning: `pnp_read_enable' defined but not used
/tmp/ccLriZXb.s: Assembler messages:
/tmp/ccLriZXb.s:243: Error: Incorrect register `%rdx' used with `l' suffix
/tmp/ccLriZXb.s:245: Error: Incorrect register `%rdx' used with `l' suffix
make: *** [superio.o] Error 1

Greetings,
Stefan

[ron minnich]

On Tue, 16 Sep 2003, Stefan Reinauer wrote:
> Is there any need in going 64bit for the LinuxBIOS C payload on Opteron?
> Since the kernel does long mode switching itself this should not be the
> case, but maybe there are different opinions.

I think maybe when we start putting > 4 GB memory on these machines, I 
don't know how we're going to zero memory absent a true 64-bit C payload.

ron

[Stefan Reinauer]

* ron minnich  [030916 16:19]:
> I think maybe when we start putting > 4 GB memory on these machines, I 
> don't know how we're going to zero memory absent a true 64-bit C payload.

This could be done using the Opterons PAE feature. Currently I see a
tradeoff between LinuxBIOS image size and the design conflict when going
away from 16bit firmware on 32bit systems while staying with 32bit on
a 64bit platform.

Stefan

[ron minnich]

On Tue, 16 Sep 2003, Stefan Reinauer wrote:
> This could be done using the Opterons PAE feature. Currently I see a
> tradeoff between LinuxBIOS image size and the design conflict when going
> away from 16bit firmware on 32bit systems while staying with 32bit on
> a 64bit platform.

this won't last very long here. 36 bits only gets us to 64 GB -- too 
small.

LinuxBIOS has run in 64-bit mode on a 64-bit platform -- the alpha. I see 
no real issue with going to 64-bit opteron mode.

rno

ron minnich  writes:
> On Tue, 16 Sep 2003, Stefan Reinauer wrote:
> > This could be done using the Opterons PAE feature. Currently I see a
> > tradeoff between LinuxBIOS image size and the design conflict when going
> > away from 16bit firmware on 32bit systems while staying with 32bit on
> > a 64bit platform.
>
> this won't last very long here. 36 bits only gets us to 64 GB -- too 
> small.

PAE is really has 64bit addresses in the page tables.  Intel implements
36bits physical and AMD 40bits of physical address space.
> LinuxBIOS has run in 64-bit mode on a 64-bit platform -- the alpha. I see 
> no real issue with going to 64-bit opteron mode.

Neither do I.  I have memory initialization working for all 64bits in 
32bit physical mode, so it isn't needed at the moment.  But there is
a noticeable performance hit.

Any dynamic page table based solution though needs to move out of
romcc compiled code, and into the normal part of LinuxBIOS where we
already have memory initialized.  That's not a bad idea anyway given
how slow it is to do memory writes over hypertransport before the link
speed is configured up.
> rno

Eric

Stefan Reinauer  writes:
> Hi,
>
> with the attached fix romcc is able to compile all of auto.c
> for the freebios2 amd64 targets. To keep all changes clean 
> and visible, they're encapsulated in ifdefs.
>
> Note: This fix alone does not make LinuxBIOS compile on AMD64
> completely yet. GCC and ld need the -m32 in some places at least
> to compile everything.

The -m32 can easily be added in the compiler over rides so that is simple
enough.
> Is there any need in going 64bit for the LinuxBIOS C payload
> on Opteron? Since the kernel does long mode switching itself
> this should not be the case, but maybe there are different 
> opinions.

There is not any need yet.  But there are certainly advantages.
So far keeping it 32bit has made things simpler.  Ideally I'd
like to be able to do either.
> Next fail I saw after romcc passed auto.c was the following:
> /home/stepan/freebios2/src/superio/NSC/pc87360/superio.c:61: warning:
> `pnp_read_enable' defined but not used
> /tmp/ccLriZXb.s: Assembler messages:
> /tmp/ccLriZXb.s:243: Error: Incorrect register `%rdx' used with `l' suffix
> /tmp/ccLriZXb.s:245: Error: Incorrect register `%rdx' used with `l' suffix
> make: *** [superio.o] Error 1

Hmm.  This looks like an inline assembler problem.

Eric