[LinuxBIOS] [PATCH] Move common utilities to util/

Stefan Reinauer stepan at coresystems.de
Mon Aug 27 10:33:18 CEST 2007

* Uwe Hermann <uwe at hermann-uwe.de> [070827 10:16]:
> Hi,
> here's my proposal for moving (via 'svn mv') common utilities which are
> not specific to a certain version of LinuxBIOS into the global util/
> (they are now in the v2 util/).
> Todo
> ----
> abuild         -- needs discussion; will it work for v3 eventually?

No, I think we want to migrate this to use Jordan's buildrom instead and
thus lower the complexity and number of tools that can be used to build
LinuxBIOS images. Less tools, better tools.

> ADLO           -- is/should be version-independant

There was a patch floating around that integrates ADLO directly into v3,
with ADLO being the loader, not the payload. So the payload would be

I think merging the few lines of ADLO code into LinuxBIOS v3 directly
makes a whole lot of sense. ADLO mostly consists of chipset specific
initialization that we do in LinuxBIOS in some way or the other already,
so it does not belong in the payload. Think of ADLO as an alternative to
the ELF loader.

> analysis

Not sure if this is needed anymore. I think it has to do with used files
and dependencies.

> buildrom       -- not related to Jordan's buildrom? Needed in v2?

It's v2 only -- It does "cat normal fallback > linuxbios.rom". So some
kind of predecessor of lar.

> dump_mmcr

sc520 specific. I doubt we will ever need this outside of v2. AMD
replaced the SC520 series with Geode. So since I doubt v3 will ever have
sc520 support, this should stay and die with v2.

> getpir

Not sure. We might want to keep it around, but I think it needs some

> lbtdump        -- Do we need this at all? Can't lxbios do the same?

I added this when lxbios was not part of the tree. We can let this
bit rot in the v2 tree, but lets not move it on.

> mptable

same as getpir

> probe_superio

yeah this one!

> resetcf

This needs to be integrated in FILO or even better GRUB2 and should
probably not be moved on.
> Projects which should _not_ be moved
> ------------------------------------
> newconfig      -- v2-specific
> optionlist     -- v2-specific

They're both gone in v3

> options        -- needed for v2 build, but we have a fork in v3 (FIXME?)
No need to fix anything here. The v2 tool works with v2. We don't want
to break 50+ boards because we add new features to v3, but we don't want
to be limited to the v2 code either. 

> romcc          -- not used in v3
> vgabios        -- we use a different/modified version in v3, so leave this

If we go back having a userspace utility to do this, it should link
against the x86emu library we have in v3. I propose this library should
be enhanced so it can be used by Xorg and we can go one codebase. Anyone? ;)

> If nobody complains, I'll move the projects tomorrow or so.
Please don't move any projects without them being actively used for new
development. I agree we should move probe_superio (and possibly rename
it) but there is no need to move any others.

There are so many more pressing issues in v3 that need to be sorted out.

coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: info at coresystems.dehttp://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866

More information about the coreboot mailing list