>>>>> "John" == John Dallaway 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