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? ADLO -- is/should be version-independant analysis buildrom -- not related to Jordan's buildrom? Needed in v2? dump_mmcr getpir lbtdump -- Do we need this at all? Can't lxbios do the same? mptable probe_superio resetcf
Projects which should _not_ be moved ------------------------------------
newconfig -- v2-specific optionlist -- v2-specific options -- needed for v2 build, but we have a fork in v3 (FIXME?) romcc -- not used in v3 vgabios -- we use a different/modified version in v3, so leave this
Already moved ------------- flashrom lxbios
Comments welcome.
If nobody complains, I'll move the projects tomorrow or so.
Another discussion is needed as to which of the utilities we should draw back into v2/v3 via svn:externals (IMHO _not_ all of them, only often-used ones). After a quick look I'd suggest the following:
- adlo (while we're at it, we should rename it from ADLO to adlo, IMO) This will be used often for booting Windows and OpenBSD soon...
- flashrom (already done), often used for flashing.
- lxbios (already done), often used for changing options.
Commens welcome.
Uwe.
* Uwe Hermann uwe@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 rombios.bin.
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 work.
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.
On Mon, Aug 27, 2007 at 10:33:18AM +0200, Stefan Reinauer wrote:
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.
Good idea, I like it. So abuild stays in v2 for now?
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 rombios.bin.
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.
Yep, if ADLO is integral part of v3 that's even better.
analysis
Not sure if this is needed anymore. I think it has to do with used files and dependencies.
Drop it? Leave it in v2?
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.
Ok, stays in v2.
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.
Well, I wouldn't rule out SC520 support in v3. But will this tool be needed in v3 (if it ever has SC520 support)?
getpir
Not sure. We might want to keep it around, but I think it needs some work.
Yes, definately, but it's already useful today and I think it's version-independant so it should go into util/.
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.
OK. Does lxbios support everything lbtdump does? If so I'd even say we remove it.
mptable
same as getpir
Yep, should go into util/, IMO.
probe_superio
yeah this one!
Agreed.
resetcf
This needs to be integrated in FILO or even better GRUB2 and should probably not be moved on.
OK.
So here's the updated plan:
- Move probe_superio to util/superio-detect (rename it while we're at it). - Move getpir to util/. - Move mptable to util/.
Everything else stays where it is. Looks good?
Uwe.
On 30.08.2007 13:37, Uwe Hermann wrote:
So here's the updated plan:
- Move probe_superio to util/superio-detect (rename it while we're at it).
It does much more than detection these days. It also has the ability to verify and dump SuperI/O configuration. Can we think about the name a little bit more?
- Move getpir to util/.
- Move mptable to util/.
Everything else stays where it is. Looks good?
Nice.
Carl-Daniel
On Thu, Aug 30, 2007 at 08:03:34PM +0200, Carl-Daniel Hailfinger wrote:
On 30.08.2007 13:37, Uwe Hermann wrote:
So here's the updated plan:
- Move probe_superio to util/superio-detect (rename it while we're at it).
It does much more than detection these days. It also has the ability to verify and dump SuperI/O configuration. Can we think about the name a little bit more?
'superiotool'.
And then add an interface like this:
$ superiotool --detect IT8712F
$ superiotool --dump [...]
$ superiotool --verify
etc...
- Move getpir to util/.
- Move mptable to util/.
Everything else stays where it is. Looks good?
Nice.
Done.
Uwe.
On Sat, Sep 01, 2007 at 09:02:24PM +0200, Carl-Daniel Hailfinger wrote:
On 01.09.2007 20:40, Peter Stuge wrote:
On Sat, Sep 01, 2007 at 01:12:00PM +0200, Uwe Hermann wrote:
'superiotool'
+1
Good name.
OK, moved and renamed.
Uwe.
* Uwe Hermann uwe@hermann-uwe.de [070830 13:37]:
On Mon, Aug 27, 2007 at 10:33:18AM +0200, Stefan Reinauer wrote:
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.
Good idea, I like it. So abuild stays in v2 for now?
yepp.
analysis
Not sure if this is needed anymore. I think it has to do with used files and dependencies.
Drop it? Leave it in v2?
Leave it.
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.
Well, I wouldn't rule out SC520 support in v3. But will this tool be needed in v3 (if it ever has SC520 support)?
No, it wouldn't.
SC520 is basically dead, and never was really wide spread I think. Of course we don't want to rule out any ports. If someone finds out he needs the tool while doing the port to v3, it can still be moved.
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.
OK. Does lxbios support everything lbtdump does? If so I'd even say we remove it.
Not sure if it does. I agree though.
-
Carl-Daniel Hailfinger -
Peter Stuge -
Stefan Reinauer -
Uwe Hermann