Status Report 2004-11-02

[Stefan Reinauer]

Hi,

after some more changes like the removed 64k limit for linuxbios rom
images here a new status report about the current image builds.

NOTE: Many boards are broken at the moment. If anyone here can supply
fixes, please do so. The situation is almost fatal given that the
changes to do are mostly time consuming but not really complex.

As a generic goal we should work on reducing the impact of such changes
by adapting the structure. Example: Having a per board fallback mechanism 
seems overkill.. The only difference among all boards seem to be the
included files from the north bridge and southbridge directories. These
could easily be autogenerated from the config tool.

The less files one port has, the easier it is to adapt to new changes.
Long term this raises code quality and the number of new ports.

Stefan

Stefan Reinauer  writes:
> Hi,
>
> after some more changes like the removed 64k limit for linuxbios rom
> images here a new status report about the current image builds.
>
> NOTE: Many boards are broken at the moment. If anyone here can supply
> fixes, please do so.

I intend to look at this.  I'm fighting a nasty cold right now so I'm doing so
moving very fast.
> The situation is almost fatal given that the
> changes to do are mostly time consuming but not really complex.
>
> As a generic goal we should work on reducing the impact of such changes
> by adapting the structure. Example: Having a per board fallback mechanism 
> seems overkill.. The only difference among all boards seem to be the
> included files from the north bridge and southbridge directories. These
> could easily be autogenerated from the config tool.

I agree to some extent.  Having a default chipset implementation of
a fallack mechanism could be useful.  In the general case you need to
be per board.  But there is no reason not to provide helper functions.

At least with the code in C.  Someone can modify the code and
have a reasonable chance of it working on ports they cannot test.
> The less files one port has, the easier it is to adapt to new changes.
> Long term this raises code quality and the number of new ports.

The vision is to get enough pieces into a general framework so we can
freeze the APIs or at least put them in serious slush mode.  Getting
nearly everything into the device tree as we have looks like a significant
step in that direction.

The big remaining piece is to figure out how to get irq routing into a generic
framework.  Right now we have some functional hacks but code reuse is hard.

Eric