[LinuxBIOS] [PATCH] Common code base for Advantech PCM-5820, ASI MB_5BLMP, BCOM WinNET100

Stefan Reinauer stepan at coresystems.de
Wed Oct 24 01:09:39 CEST 2007


* Uwe Hermann <uwe at hermann-uwe.de> [071024 00:08]:
> Sure, but working on v3 doesn't mean we necessarily have to let v2 bitrot.
 
Unfortunately it's v3 that bitrots.. :(

> The bigger problem is more recent boards. Look at m57sli, a8n_e, etc.
> Those not only contain board-specific config items (which would be
> ideal), but rather board-specific _code_ (which is not nice and we should
> avoid that in v3), and worse they contain (contrary to GX1/440BX)
> a _lot_ of duplicated or near-duplicated code.

The right answer is to advance the structure of LinuxBIOS in a way that
no code is needed anymore per board. stuff like pirq, mptable, acpi
could be derived from a well written config.lb/dtc.

> Config.lb:
> 
>  - Can easily be made totally generic to work for _every_ board we use.
>    The only really specific part in there is the static device tree,
>    all the other blurb could as well be in a common file.
> 
>    Hm, do Config.lb/Option.lb files support an #include-like mechanisms?
 
Yes, and in v3 we cleaned this up. Let's not put our v3 effort in v2.
This will make v3 die and v2 will be a half hearted solution..

> Options.lb:
> 
>  - Not needed at all, IMHO. We could just drop them all, I think.
>    95% of those files is the same for each board, the rest can be
>    easily set to some sane default and overridden in
>    targets/.../Config.lb as needed.

Forget about this stuff for v2. It's not nice, I agree. But it's a
design issue. You're at best fighting windmills here.
 
> Other files, such as get_bus_conf.c, irq_tables.c, mptable.c,
> resourcemap.c etc. are twistly little mazes. They partly hardcode
> information such as the number of certain devices in C code etc.
> This is where it gets really ugly. I'm not sure I can be bothered to
> create patches to fix _that_ in v2, but I'd really appreciate it if
> v3 would have that kind of information as a simple config value part
> of the dts.

Yes, in v3 we should, no, we must work on autocreating all those.

dtc is the only mainboard specific information source in the end.

If you have ideas, please make that happen for v3, rather than "wasting
time" on v2.

Because once we got that done, porting new boards will be so much easier
than now, and no long cleanups are required.

> > #ifdef/#elif is really ugly. At least do #include instead?
> 
> Could be done, yes. Would such a patch be accepted?

... Patches to v3, doing the "right thing(tm)" are definitely preferred.

Stefan

-- 
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