>>>>> "Jifl" == Jonathan Larmour writes: >> So instead of making the change now, for all anoncvs targets >> and with no possiblity of testing on most of those targets, I >> want to do the work in eCosPro first. It can then be merged >> into a future anoncvs release, once I am confident that it is >> not going to break anything. Jifl> Why can it not be in both? Why should eCosPro be special Jifl> with respect to a changing API? And incompatible. Switching the flash subsystem to initialize via static constructors means that the h/w init order changes for every platform that uses RedBoot, and very possibly some of the remaining platforms as well. Currently flash initialization happens after cyg_start() has started running. All static constructors have already run. Virtual vectors have been sorted out. The memory map has been sorted via HAL_MEM_REAL_REGION_TOP() if necessary. Any bist() self-test code has run. Some other RedBoot init code may have run as well. Switching to a static constructor means that the flash initialization will now happen much earlier, before cyg_start(). Now, it is likely that on most platforms that won't cause any problems - it worked fine on the platform I tried. But we may easily have overlooked some dependency somewhere which means that other platforms will stop working, so that if anybody decides to rebuild and install RedBoot after 3.0 they'll end up with a brick. Rolling out this change in anoncvs means that it will affect every single target in one fell swoop. Rolling it out in eCosPro means that we get to test the new code one or a small number of ports at a time, as we do new ports. Typically we'll make very sure that we have a way of unbricking any board we are porting to, before we start messing about with the flash. So if there are problems with the new code, we can find them and fix them prior to any eCosPro release, with no risk of affecting either our customers or anoncvs users. Over a period of time the new code will be run on a variety of hardware with different flash setups. What I am proposing is pretty much the same strategy that was adopted for the flash V2 work. That did not immediately go into the anoncvs trunk because it was considered too dangerous a change. Instead it went into a separate branch, for those anoncvs users wanting the new functionality, and it went into eCosPro. Partly due to the latter, by now flash V2 has been used on sufficiently many different targets that we believe there is very little risk of it breaking the world for typical anoncvs users, so the code has been merged into the trunk. Now, for most application developers this is a storm in a teacup. It really does not matter all that much whether the flash auto-initializes or whether they need to make an extra init call from inside their application. So, we have a change that offers very little benefit to users, which significantly changes the order in which nearly all targets initialize, which may cause some number of targets to break and leave users with bricks, being put into the source tree very close to release after not very much testing. The more I worked on this, the more I realized this was a really bad idea. >>>>> "Jifl" == Jonathan Larmour writes: Jifl> externC cyg_flash_printf *cyg_flash_set_printf( const cyg_flashaddr_t Jifl> base, cyg_flash_printf *pf); Jifl> which associates the printf function of flash at base 'base' Jifl> with function 'pf', returning its previous setting. There Jifl> would also be: #define CYG_FLASH_SET_PRINTF_ALL Jifl> ((cyg_flashaddr_t)-1); Jifl> which is used to set all devices' printf functions (and Jifl> always return NULL). Jifl> We can instantly deprecate use of cyg_flash_init with Jifl> non-NULL argument. And if the messiness is too much to deal Jifl> with after all, we can continue with cyg_flash_init, and in Jifl> future it would be more or less #defined to Jifl> cyg_flash_set_printf. The discussion on all this back in November involved an incompatible API change, changing cyg_flash_init() so that it no longer took any arguments. That meant we had to add new functions for setting the printf function, e.g. cyg_flash_set_global_printf() and cyg_flash_set_printf(). Now, there are no longer any plans to change the prototype of cyg_flash_init(). It will continue to take a printf function, and act as cyg_flash_set_global_printf(). However we'll probably want to mark it as deprecated to make sure that people are aware things are done a bit differently than before. Since for 3.0 it will still be necessary for applications to call cyg_flash_init(), and since cyg_flash_init() still takes a printf pointer, there is very little point in implementing the set_printf() functions right now. It would only affect application code that currently calls cyg_flash_init() multiple times with different arguments, to change the printf function at run-time. I suspect that very few applications do that. If they do then in future they'll get multiple compile-time warnings about cyg_flash_init() being deprecated, as opposed to just a single warning about cyg_flash_init() and no warnings about the cyg_flash_set_global_printf() calls. So, a change that is likely to benefit very few users, and negligible future harm if we leave the API as it is right now. Again, the most sensible thing to do is to leave things as they are and come back to this after the release. 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