On Tue, 6 Oct 2015, Richard Rauch wrote: > It seems, they will not put any port to official open source > repository if it could disturb commercial interests > (eCosCentric/eCosPro...).
I am not affiliated with eCosCentric/eCosPro somehow. Nohow. > I will give just one example when we tried to make a port public: > http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001649 further > activities, if you search for in detail: > http://bugs.ecos.sourceware.org/buglist.cgi?quicksearch=at91sam9G45 > beside this there was email traffic as well with the maintainers, but > finally there was no success! Just now I looked on one issue (half-hour only). I tried the latest BUG from the 'at91sam9G45' set, this one http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001796 The said: >> One main objective of this patch is to ensure the existing ports do >> not break because of these extensions. Getting ahead, I must say that I never try to review any patches which do massive changes in HAL, especially when a delta for *.S sources takes a few screens and this is such a case, look, please http://bugs.ecos.sourceware.org/attachment.cgi?id=2125&action=diff This surely does infect many (if not all) ARM targets. Why I never try? At first I have no such competence and secondly I have no test farm for the most infected hardware. Could you play an assembler code in a mind? I cannot, sorry. I can try to check such a proof >> One main objective of this patch is to ensure the existing ports do >> not break because of these extensions. So, I did a proper checkout and applied the patches. No build errors. Great. I got hold eCos ARM7TDMI target, flashed "new" RedBoot image, Redboot started. Great! Then I downloaded `tm_basic' on the target, 'go' and the test hung. GDB session: the same (I could not even break the test). I rolled back the changes, re-built RedBoot and eCos tests (notice that checkout was a medium of 2012) and got all things worked. Q: Should a maintainer take JTAG and continue to deepen in the "issue" in such cases when new things do break the existing things? Do you really think such a delta (only arm/arch part) hg diff --stat packages/hal/arm/arch/current/ packages/hal/arm/arch/current/include/hal_arch.h | 20 +- packages/hal/arm/arch/current/include/hal_intr.h | 174 +++------ packages/hal/arm/arch/current/src/arm_stub.c | 5 +- packages/hal/arm/arch/current/src/context.S | 45 +- packages/hal/arm/arch/current/src/hal_misc.c | 3 +- packages/hal/arm/arch/current/src/vectors.S | 437 +++++++++------------- 6 files changed, 291 insertions(+), 393 deletions(-) can break nothing? I think this BUG could not found enthusiasts among the maintainers as they even more skilled than me. Perhaps, they understood: the patch will break important things even without a live experiment. I believe that Bernd Edinger (Hi Bernd!) did a herculean job and new folks would get new horizons with new AT91 families. But what's about old folk, old targets? When somebody ask, is eCos dying? I read, is old folk (okay targets :-) dying? Sure, but that takes a time. Perhaps, we have to make obsolete some targets. What criteria is? Age? Poll? I.e. majority against maintainers? Back to at91sam9 distribution. What I would advice? I would advise to create EPK (eCos package) which will make obsolete "old" hardware and offer "new" stuff. New folks be happy (no mess with patches). Why not? What do I regret? I regret that in 2013 I have not found even a half-hour for testing. But most likely I've seen this BUG and thought, this work has no chance to be applied AS IS, it needs a few man-months of work the experts and I am not big expert here. Sergei -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
