[coreboot] ADLO for buildrom

[Uwe Hermann]

On Wed, Apr 30, 2008 at 04:24:47PM -0600, Myles Watson wrote:
> > > Index: adlo/elf/elf-header-065kb.payload
> > > Index: adlo/elf/elf-header-068kb.payload
> > 
> > Not sure I like storing blobs in svn. How were they generated?
> 
> By hand with a hex editor.
> 
>  If
> > possible we should store the "source" or some scripts which generates
> > them on-the-fly in svn? This won't hold up a commit though, can be
> > done later. Hm, seems they're hand-crafted, but I'd still like a
> > small script which "crafts" them better than storing blobs nobody
> > can read or understand.
> 
> I'd love a script that crafts them.  Using readelf -a and trial and error
> gets old.

Yep, we should put this on a TODO list (trac).


> > Also, v2's ADLO has three of those, what's the difference to these?
> 
> There used to be a 64K payload for the 16-bit BIOS and a 128K payload for
> the 32-bit BIOS that added other features like ACPI.  Now the 32-bit BIOS
> fits into 64K, so no need for the 128-bit ELF headers.  The reason there are
> two is that I hope to be able to use kexec to load ADLO so that the kernel
> can initialize all the hardware on the motherboard correctly.  Kexec can't
> handle ELFs that have data that isn't page-aligned.  The 68K payload has
> that 4K-aligned loader.

OK, fine. Would it hurt to use the aligned version for non-kexec too?
Any drawbacks?


> > > Index: adlo/loader.s
> > > ===================================================================
> > > --- adlo/loader.s	(revision 0)
> > > +++ adlo/loader.s	(revision 0)
> > > @@ -0,0 +1,467 @@
> > > +;*****************************************************
> > > +; $Id: loader.s,v 1.1 2002/11/25 02:07:53 rminnich Exp $
> > > +;*****************************************************
> > 
> > Hm, who wrote this code originally and what license applies?
> > 
> > Juding from
> > 
> > http://tracker.coreboot.org/trac/coreboot/log/trunk/LinuxBIOSv1/util/ADLO?
> > rev=702
> > 
> > http://tracker.coreboot.org/trac/coreboot/browser/trunk/LinuxBIOSv1/util/A
> > DLO/README.1st?rev=702
> > 
> > http://tracker.coreboot.org/trac/coreboot/browser/trunk/LinuxBIOSv1/util/A
> > DLO/CAST?rev=702
> > it seems the code was checked in by Ron, but actually implemented by
> > Adam Sulmicki with the help of others:
> > 
> >    "Most of the analysis, design and implementation of the project was
> > done by
> >     me, Adam Sulmicki."
> > 
> > Is this correct?
> 
> Good question.  I haven't been around this project that long.  Ron?
> 
> I'm hoping we'll replace it very soon, though.

OK, then it probably doesn't matter much. If and how can the loader be
integrated upstream? That's probably the best place to store it, correct?


> > > +-; code it is loaded into memory at 0x7C00
> > > ++; code it is loaded into memory at 0x7000
> > 
> > Why? Please explain. Is this board-specific or payload-specific?
> > Can it be a variable, selectable in a config file later?
> > Surely in buildrom, but also for manual builds...
> 
> This is part of what should go away.  The BIOS has to get loaded at the
> correct address for callbacks to work.  This loader needs to get loaded
> somewhere else, then copy its payload to the right spot.  I'd love for the
> loading part to get taken over by Coreboot.  Then we could just set up the
> CMOS values separately and not depend on being loaded into a hard-coded
> location in RAM.

Can you elaborate? What would coreboot need to do exactly (in addition
what we already to for other payloads)? Is any of that board-specific?

What do you mean with CMOS values here? Where are they used in ADLO?
Not yet, but you plan to do later?


> > This is needed for ADLO but not legacybios? Can we also change ADLO
> > to not require it, or is that impossible?
> 
> I hope someone will do it soon.  It would take me some time, since I'm not
> really familiar with assembly, but it really isn't too much code.

OK, sounds good. So there's not _real_ reason to continue using it.


> > Let's use "ADLO" in strings everywhere, as that seems to be the
> > "official" name.
> 
> Sure.  Once we replace the loader there will be nothing left of the original
> but the name, but the name's fine.

Hm, if it's completely gone later, I think we should also eliminate
the ADLO name (but not just yet).

It's just coreboot+legacybios then, correct? So we'll probably call
it legacybios (or BOCHS BIOS?). We'll see...


> > > Index: packages/legacybios/legacybios.mk
> > > ===================================================================
> > > --- packages/legacybios/legacybios.mk	(revision 0)
> > > +++ packages/legacybios/legacybios.mk	(revision 0)
> > [...]
> > > +LEGACYBIOS_TARBALL=legacybios-$(LEGACYBIOS_TAG).tar.gz
> > > +LEGACYBIOS_SOURCE=legacybios-$(LEGACYBIOS_TAG).tar.gz
> > 
> > Why are both needed?
 
Is this required?


Testing the code now in QEMU and hardware, will report back.


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org