Ronald G Minnich <[EMAIL PROTECTED]> writes:
> On 17 Aug 2001, Eric W. Biederman wrote:
>
> > Ollie Lho <[EMAIL PROTECTED]> writes:
> >
> > > "Eric W. Biederman" wrote:
> > > >
> > > > My biggest question. Does the docipl case need a 16bit entry point?
> > > > Probably.
> > > >
> > >
> > > I guess so. Ron had done another mission impossible that put ipl.S
> > > into 32Bit mode for Ali chipset. Maybe he has something to tell.
>
> the 32bit ipl.S had a 16bit entry point and went in to 32-bit mode via the
> usual lgdt & longjmp sequence. The .S produced a 1Mbyte .o, of which only
> the last 512 bytes mattered.
>
> that needed a tail -c 512 which I did by hand as I did not know what to do
> with the build situation as it is.
>
> > Looking into this I am realizing we need to a little more flexible on
> > how we build the linker script. The case for the asus_cua with
> > the protected mode startup logic is also have serious problems
> > with my new build.
>
> Since the Acer guys have eliminated the protected mode in ipl.S this is
> suddenly less of a problem.
>
> > So I'm going to implement something like mainboardinit for the linker
> > script ...
>
> come again?
I'm looking at a couple of different usages of linuxBIOS and many of
them of the interesting ones involve an ipl.S. Without using mkrom
this messes up the build for several boards.
One of the things that we have done that has worked well, is raminit,
that I generalized into mainboardinit for the creation of crt0.S.
With a little care I should be able to build something similiar for
the linker script. I then should be able to centralize the build
about building the linuxbios target. And then use:
objcopy -j .section_foo target_foo
For most of the interesting targets.
At any rate I need to find some solution or replaceing mkrom using
linker scripts and code was a loss, because it breaks the build
for the asus/cua and the sis/docipl cases.
Eric
