Re: Flash subsystem update

[Bart Veer <bartv at ecoscentric dot com>]

>>>>> "John" == John Dallaway <john@dallaway.org.uk> writes:

    John> Hi Jifl and Bart
    John> John Dallaway wrote:

    >> We need to contain further slippage as far as practically
    >> possible and push forward with eCos 3.0. I would therefore like
    >> to ensure we have a well-understood plan for addressing this
    >> issue in a realistic timescale. Firstly, we need to understand
    >> the issues that Bart encountered in detail. Bart, can you
    >> provide this detail today please? Does Jifl's proposed
    >> workaround work for you?

    John> Bart, thank you for the details of the technical issues.

    John> Jifl, I think Bart makes some valid points regarding a
    John> cautious roll out of any revised Flash API. I also
    John> appreciate your own perspective regarding adoption the new
    John> API as part of the new major version of eCos.

    John> Personally, I would prefer that we seize this opportunity to
    John> switch API rather than wait for the next major release of
    John> eCos beyond 3.0. If we switch now, the onus would be on the
    John> eCos community to deliver a verdict on the changes through
    John> diligent testing over the beta period and I would hope that
    John> the eCos maintainers could commit to verify RedBoot across a
    John> diverse sample of the boards we have to hand. We do have the
    John> option to extend the beta period, or push out a second beta,
    John> if it proves necessary.

I am not sure why we are still discussing this.

By far the most sensible thing to do right now is to leave things
exactly as they are. The functionality change is of interest to very
few if any users. It may be interesting to us in the long term if we
want to statically initialize more subsystems, but that does not
require anything to be done today. There are no significant API
compatibility implications: all of the functions that exist today will
continue to exist; one of them will become pretty much irrelevant and
users will be warned that they can safely remove it and save a few
bytes, but it will continue to exist.

If things go wrong, the result may be not a simple test failure. It
may be a bricked board, and not everybody will have facilities for
unbricking. I have had enough experience with different boards over
the years to know that getting the flash working right may be tricky
and that there may be subtle interactions between subsystems.

So, I don't see an upside for changing anoncvs now. The downside is,
at best, delaying the release further and, at worst, breaking things
completely for some ports and users ending up with bricked boards.
There is a sensible way forward to introduce and test the changes
gradually, rather than forcing it for all 116 anoncvs targets in one
go with minimal testing. From my perspective it is a no-brainer.

I have far too many other things to get on with right now, so I have
no interest in discussing this any further. I do not intend to return
to this subject until after the 3.0 release. If I do find some more
time to spend on eCos 3.0 it will be used for something that actually
matters, e.g. sorting out the C++ support for the synthetic target.

Bart

-- 
Bart Veer                                   eCos Configuration Architect
eCosCentric Limited    The eCos experts      http://www.ecoscentric.com/
Barnwell House, Barnwell Drive, Cambridge, UK.      Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
Besuchen Sie uns vom 3.-5.03.09 auf der Embedded World 2009, Stand 11-300
Visit us at Embedded World 2009, Nürnberg, Germany, 3-5 Mar, Stand 11-300