* Re: Getting Atmel AT91SAM9 into eCos [not found] <1266877649.3024.105.camel@localhost.localdomain> @ 2010-02-23 9:26 ` John Dallaway 2010-02-23 9:58 ` Evgeniy Dushistov 2010-03-08 13:11 ` John Dallaway 0 siblings, 2 replies; 10+ messages in thread From: John Dallaway @ 2010-02-23 9:26 UTC (permalink / raw) To: Daniel Helgason, eCos Maintainers, Evgeniy Dushistov; +Cc: Martin Laabs Hi Daniel, Evgeniy and eCos maintainers Daniel Helgason wrote: > I have seen many messages on the eCos mailing lists about getting > AT91SAM9 support into eCos. I'm writing directly to you in hopes of > getting some movement on this. I know this is off the mailing list but I > wanted to get initial input directly from people whose opinions I have > come to respect before I add yet another message to the mailing list > about this subject. [ snip ] > If there was ever a time to consider pushing the AT91SAM9 devices into > eCos, this could be it! I am asking you for your thoughts on how to > proceed from here. Thanks! I am not an expert on ARM7/ARM9 differences but there are several eCos maintainers who have experience with multiple ARM variants and are well positioned to review the AT91SAM9 patch. I do not think motivation should be an issue here. We all wish to see eCos move forward and AT91SAM9 support is clearly very good for the project. My main concern is that we don't break eCos support for older ARM platforms in the process of improving the hardware abstraction for future platform ports. Is there an eCos maintainer with the necessary ARM expertise who can volunteer for the review of this contribution? Ref: http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000819 John Dallaway eCos maintainer ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Getting Atmel AT91SAM9 into eCos 2010-02-23 9:26 ` Getting Atmel AT91SAM9 into eCos John Dallaway @ 2010-02-23 9:58 ` Evgeniy Dushistov 2010-02-23 16:53 ` Gary Thomas 2010-03-08 13:11 ` John Dallaway 1 sibling, 1 reply; 10+ messages in thread From: Evgeniy Dushistov @ 2010-02-23 9:58 UTC (permalink / raw) To: John Dallaway; +Cc: Daniel Helgason, eCos Maintainers, Martin Laabs On Tue, Feb 23, 2010 at 09:26:15AM +0000, John Dallaway wrote: > Hi Daniel, Evgeniy and eCos maintainers > > Daniel Helgason wrote: > > > I have seen many messages on the eCos mailing lists about getting > > AT91SAM9 support into eCos. I'm writing directly to you in hopes of > > getting some movement on this. I know this is off the mailing list but I > > wanted to get initial input directly from people whose opinions I have > > come to respect before I add yet another message to the mailing list > > about this subject. > > [ snip ] > > > If there was ever a time to consider pushing the AT91SAM9 devices into > > eCos, this could be it! I am asking you for your thoughts on how to > > proceed from here. Thanks! > > I am not an expert on ARM7/ARM9 differences but there are several eCos > maintainers who have experience with multiple ARM variants and are well > positioned to review the AT91SAM9 patch. I do not think motivation > should be an issue here. We all wish to see eCos move forward and > AT91SAM9 support is clearly very good for the project. > > My main concern is that we don't break eCos support for older ARM > platforms in the process of improving the hardware abstraction for > future platform ports. > Actually, I and Filip Navara implemented AT91SAM7X and at91sam9263 support for qemu, one of the most recent version can be found here: git://github.com/Dushistov/qemu_at91sam9263.git It can run linux, freertos, ecos. So if there is interest, I can create binaries of qemu for linux OS, so maintainers who have sam7 hardware, but have no sam9, or vice versa, or completly have no development boards can run and test eCos. -- /Evgeniy ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Getting Atmel AT91SAM9 into eCos 2010-02-23 9:58 ` Evgeniy Dushistov @ 2010-02-23 16:53 ` Gary Thomas 2010-02-23 17:50 ` Evgeniy Dushistov 0 siblings, 1 reply; 10+ messages in thread From: Gary Thomas @ 2010-02-23 16:53 UTC (permalink / raw) To: Evgeniy Dushistov Cc: John Dallaway, Daniel Helgason, eCos Maintainers, Martin Laabs On 02/23/2010 03:01 AM, Evgeniy Dushistov wrote: > On Tue, Feb 23, 2010 at 09:26:15AM +0000, John Dallaway wrote: >> Hi Daniel, Evgeniy and eCos maintainers >> >> Daniel Helgason wrote: >> >>> I have seen many messages on the eCos mailing lists about getting >>> AT91SAM9 support into eCos. I'm writing directly to you in hopes of >>> getting some movement on this. I know this is off the mailing list but I >>> wanted to get initial input directly from people whose opinions I have >>> come to respect before I add yet another message to the mailing list >>> about this subject. >> >> [ snip ] >> >>> If there was ever a time to consider pushing the AT91SAM9 devices into >>> eCos, this could be it! I am asking you for your thoughts on how to >>> proceed from here. Thanks! >> >> I am not an expert on ARM7/ARM9 differences but there are several eCos >> maintainers who have experience with multiple ARM variants and are well >> positioned to review the AT91SAM9 patch. I do not think motivation >> should be an issue here. We all wish to see eCos move forward and >> AT91SAM9 support is clearly very good for the project. >> >> My main concern is that we don't break eCos support for older ARM >> platforms in the process of improving the hardware abstraction for >> future platform ports. >> > > Actually, I and Filip Navara implemented AT91SAM7X and at91sam9263 > support for qemu, one of the most recent version can be found here: > git://github.com/Dushistov/qemu_at91sam9263.git > It can run linux, freertos, ecos. > > So if there is interest, I can create binaries of qemu for linux OS, > so maintainers who have sam7 hardware, but have no sam9, or > vice versa, or completly have no development boards can run > and test eCos. How do you configure Qemu to run eCos on these platforms? -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Getting Atmel AT91SAM9 into eCos 2010-02-23 16:53 ` Gary Thomas @ 2010-02-23 17:50 ` Evgeniy Dushistov 0 siblings, 0 replies; 10+ messages in thread From: Evgeniy Dushistov @ 2010-02-23 17:50 UTC (permalink / raw) To: Gary Thomas Cc: John Dallaway, Daniel Helgason, eCos Maintainers, Martin Laabs On Tue, Feb 23, 2010 at 09:53:28AM -0700, Gary Thomas wrote: > On 02/23/2010 03:01 AM, Evgeniy Dushistov wrote: > > On Tue, Feb 23, 2010 at 09:26:15AM +0000, John Dallaway wrote: > >> Hi Daniel, Evgeniy and eCos maintainers > >> > >> Daniel Helgason wrote: > >> > >>> I have seen many messages on the eCos mailing lists about getting > >>> AT91SAM9 support into eCos. I'm writing directly to you in hopes of > >>> getting some movement on this. I know this is off the mailing list but I > >>> wanted to get initial input directly from people whose opinions I have > >>> come to respect before I add yet another message to the mailing list > >>> about this subject. > >> > >> [ snip ] > >> > >>> If there was ever a time to consider pushing the AT91SAM9 devices into > >>> eCos, this could be it! I am asking you for your thoughts on how to > >>> proceed from here. Thanks! > >> > >> I am not an expert on ARM7/ARM9 differences but there are several eCos > >> maintainers who have experience with multiple ARM variants and are well > >> positioned to review the AT91SAM9 patch. I do not think motivation > >> should be an issue here. We all wish to see eCos move forward and > >> AT91SAM9 support is clearly very good for the project. > >> > >> My main concern is that we don't break eCos support for older ARM > >> platforms in the process of improving the hardware abstraction for > >> future platform ports. > >> > > > > Actually, I and Filip Navara implemented AT91SAM7X and at91sam9263 > > support for qemu, one of the most recent version can be found here: > > git://github.com/Dushistov/qemu_at91sam9263.git > > It can run linux, freertos, ecos. > > > > So if there is interest, I can create binaries of qemu for linux OS, > > so maintainers who have sam7 hardware, but have no sam9, or > > vice versa, or completly have no development boards can run > > and test eCos. > > How do you configure Qemu to run eCos on these platforms? > Get sources of qemu from git url above, then ./configure --target-list="arm-softmmu arm-linux-user armeb-linux-user" && make To run eCos on at91sam9263, you need something like ./arm-softmmu/qemu-system-arm -serial tcp::4445,server -M at91sam9263ek -pflash ../pflash-redboot.img & #to get access to dbgu port telnet localhost 4445 pflash-redboot.img is image 8M nor flash, it can be created by: qemu-img create pflash-redboot.img 8M dd if=redboot.bin of=pflash-redboot.img ... For at91sam7x things little simplier, you need something like: ./arm-softmmu/qemu-system-arm -serial tcp::4445,server -M at91pes -kernel <name>.elf you can run qemu with "-s -S" and connect to it using arm-eabi-gdb to port 1234. -- /Evgeniy ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Getting Atmel AT91SAM9 into eCos 2010-02-23 9:26 ` Getting Atmel AT91SAM9 into eCos John Dallaway 2010-02-23 9:58 ` Evgeniy Dushistov @ 2010-03-08 13:11 ` John Dallaway 2010-03-08 13:54 ` Jonathan Larmour 1 sibling, 1 reply; 10+ messages in thread From: John Dallaway @ 2010-03-08 13:11 UTC (permalink / raw) To: eCos Maintainers; +Cc: Evgeniy Dushistov, Daniel Helgason eCos maintainers John Dallaway wrote: > Daniel Helgason wrote: > >> I have seen many messages on the eCos mailing lists about getting >> AT91SAM9 support into eCos. I'm writing directly to you in hopes of >> getting some movement on this. I know this is off the mailing list but I >> wanted to get initial input directly from people whose opinions I have >> come to respect before I add yet another message to the mailing list >> about this subject. > > [ snip ] > >> If there was ever a time to consider pushing the AT91SAM9 devices into >> eCos, this could be it! I am asking you for your thoughts on how to >> proceed from here. Thanks! > > I am not an expert on ARM7/ARM9 differences but there are several eCos > maintainers who have experience with multiple ARM variants and are well > positioned to review the AT91SAM9 patch. I do not think motivation > should be an issue here. We all wish to see eCos move forward and > AT91SAM9 support is clearly very good for the project. > > My main concern is that we don't break eCos support for older ARM > platforms in the process of improving the hardware abstraction for > future platform ports. > > Is there an eCos maintainer with the necessary ARM expertise who can > volunteer for the review of this contribution? There has been no response to this. The review of Evgeniy's patch is particularly important at present to avoid merging issues for various new and planned platform ports on ARM7/9. It is also important that the variant abstraction re-work is reviewed by someone with real expertise in the area. What do you suggest? Should we ask for a volunteer from the wider eCos community to review the patch in this instance? John Dallaway eCos maintainer ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Getting Atmel AT91SAM9 into eCos 2010-03-08 13:11 ` John Dallaway @ 2010-03-08 13:54 ` Jonathan Larmour 2010-03-08 15:59 ` John Dallaway 0 siblings, 1 reply; 10+ messages in thread From: Jonathan Larmour @ 2010-03-08 13:54 UTC (permalink / raw) To: John Dallaway; +Cc: eCos Maintainers, Evgeniy Dushistov, Daniel Helgason John Dallaway wrote: > eCos maintainers > > John Dallaway wrote: > > >>Daniel Helgason wrote: >> >> >>>I have seen many messages on the eCos mailing lists about getting >>>AT91SAM9 support into eCos. I'm writing directly to you in hopes of >>>getting some movement on this. I know this is off the mailing list but I >>>wanted to get initial input directly from people whose opinions I have >>>come to respect before I add yet another message to the mailing list >>>about this subject. >> >>[ snip ] >> >> >>>If there was ever a time to consider pushing the AT91SAM9 devices into >>>eCos, this could be it! I am asking you for your thoughts on how to >>>proceed from here. Thanks! >> >>I am not an expert on ARM7/ARM9 differences but there are several eCos >>maintainers who have experience with multiple ARM variants and are well >>positioned to review the AT91SAM9 patch. I do not think motivation >>should be an issue here. We all wish to see eCos move forward and >>AT91SAM9 support is clearly very good for the project. >> >>My main concern is that we don't break eCos support for older ARM >>platforms in the process of improving the hardware abstraction for >>future platform ports. >> >>Is there an eCos maintainer with the necessary ARM expertise who can >>volunteer for the review of this contribution? > > > There has been no response to this. > > The review of Evgeniy's patch is particularly important at present to > avoid merging issues for various new and planned platform ports on > ARM7/9. It is also important that the variant abstraction re-work is > reviewed by someone with real expertise in the area. > > What do you suggest? Should we ask for a volunteer from the wider eCos > community to review the patch in this instance? In truth, the main reason I (and probably others) have been studiously ignoring this is because the patch is far-reaching. That doesn't make it bad, but there's a lot of risk (and effort) here, with potential knock-on for ports we can't retest easily, and effects for any eCos user's own ports we don't have in our repo. It would also be hard to apply such a patch while using CVS, due to its problems with moving things around. I will kick off a discussion about VCS's because w.r.t this patch or otherwise, it needs to be resolved. To do that, I need to go through the past discussion in the community and summarise what people have already said, then reopen discussion in the community. I'll try and do something this week. Although I'll be away next week. It doesn't feel right saying that we can't do something with the patch till we've switched VCS, but the practicalities do mean that there may be reasons to wait. It's likely this work would need to be committed initially on a branch. But again a reason for a new VCS is that merging from branch to trunk is much much much saner than with CVS, especially with moved files, renames, etc. (assuming the branch was made from the new VCS). Jifl -- ------["The best things in life aren't things."]------ Opinions==mine ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Getting Atmel AT91SAM9 into eCos 2010-03-08 13:54 ` Jonathan Larmour @ 2010-03-08 15:59 ` John Dallaway 2010-03-09 2:00 ` Sergei Gavrikov 2010-03-09 16:25 ` Jonathan Larmour 0 siblings, 2 replies; 10+ messages in thread From: John Dallaway @ 2010-03-08 15:59 UTC (permalink / raw) To: Jonathan Larmour; +Cc: eCos Maintainers, Evgeniy Dushistov, Daniel Helgason Hi Jifl and all Jonathan Larmour wrote: > John Dallaway wrote: > >> eCos maintainers >> >> John Dallaway wrote: >> >>> Daniel Helgason wrote: >>> >>>> I have seen many messages on the eCos mailing lists about getting >>>> AT91SAM9 support into eCos. I'm writing directly to you in hopes of >>>> getting some movement on this. I know this is off the mailing list >>>> but I >>>> wanted to get initial input directly from people whose opinions I have >>>> come to respect before I add yet another message to the mailing list >>>> about this subject. >>> >>> [ snip ] >>> >>>> If there was ever a time to consider pushing the AT91SAM9 devices into >>>> eCos, this could be it! I am asking you for your thoughts on how to >>>> proceed from here. Thanks! >>> >>> I am not an expert on ARM7/ARM9 differences but there are several eCos >>> maintainers who have experience with multiple ARM variants and are well >>> positioned to review the AT91SAM9 patch. I do not think motivation >>> should be an issue here. We all wish to see eCos move forward and >>> AT91SAM9 support is clearly very good for the project. >>> >>> My main concern is that we don't break eCos support for older ARM >>> platforms in the process of improving the hardware abstraction for >>> future platform ports. >>> >>> Is there an eCos maintainer with the necessary ARM expertise who can >>> volunteer for the review of this contribution? >> >> There has been no response to this. >> >> The review of Evgeniy's patch is particularly important at present to >> avoid merging issues for various new and planned platform ports on >> ARM7/9. It is also important that the variant abstraction re-work is >> reviewed by someone with real expertise in the area. >> >> What do you suggest? Should we ask for a volunteer from the wider eCos >> community to review the patch in this instance? > > In truth, the main reason I (and probably others) have been studiously > ignoring this is because the patch is far-reaching. That doesn't make it > bad, but there's a lot of risk (and effort) here, with potential > knock-on for ports we can't retest easily, and effects for any eCos > user's own ports we don't have in our repo. > > It would also be hard to apply such a patch while using CVS, due to its > problems with moving things around. I will kick off a discussion about > VCS's because w.r.t this patch or otherwise, it needs to be resolved. I agree that the VCS debate needs to happen, but it seems dangerous to link patch review with VCS changes in the sense that it introduces further (unquantified) delay to the review of patches which have already been pending for many months. I am happy to volunteer for the hard graft of working with CVS if it will help to get things moving on the ARM7/ARM9 front. > It doesn't feel right saying that we can't do something with the patch > till we've switched VCS, but the practicalities do mean that there may > be reasons to wait. > > It's likely this work would need to be committed initially on a branch. > But again a reason for a new VCS is that merging from branch to trunk is > much much much saner than with CVS, especially with moved files, > renames, etc. (assuming the branch was made from the new VCS). Having just had a more detailed look, it appears that the new ARM7 package is only used by the ARM7 AT91 platforms as the patch stands today. It is less invasive than I had imagined. The other ARM7 platforms are untouched. So I think we could phase in use of the new ARM7 package for new ports only. The changes to the ARM9 variant package are more of an all-or-nothing proposition but we have several ports to ARM9 platforms in progress within the eCos community so the changes will certainly get tested. However, some of the ARM9 platforms supported within the eCos repository are obsolete and are likely to never be tested again so if we break such platform support it will probably stay broken forever. Jifl, should we think in terms of a ARM9 v2 variant package (like flash v2) to mitigate the risk? If we can manage the risk and manage the CVS effort, the remaining major obstacle to progress would be the verification that the abstractions are correct. Perhaps an hour of effort for someone with the appropriate experience? John Dallaway eCos maintainer ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Getting Atmel AT91SAM9 into eCos 2010-03-08 15:59 ` John Dallaway @ 2010-03-09 2:00 ` Sergei Gavrikov 2010-03-09 16:30 ` Jonathan Larmour 2010-03-09 16:25 ` Jonathan Larmour 1 sibling, 1 reply; 10+ messages in thread From: Sergei Gavrikov @ 2010-03-09 2:00 UTC (permalink / raw) To: John Dallaway Cc: Jonathan Larmour, eCos Maintainers, Evgeniy Dushistov, Daniel Helgason Hi all [ snip nothing ] John Dallaway wrote: > Hi Jifl and all > > Jonathan Larmour wrote: > >> John Dallaway wrote: >> >>> eCos maintainers >>> >>> John Dallaway wrote: >>> >>>> Daniel Helgason wrote: >>>> >>>>> I have seen many messages on the eCos mailing lists about getting >>>>> AT91SAM9 support into eCos. I'm writing directly to you in hopes of >>>>> getting some movement on this. I know this is off the mailing list >>>>> but I wanted to get initial input directly from people whose >>>>> opinions I have come to respect before I add yet another message to >>>>> the mailing list about this subject. >>>> >>>> [ snip ] >>>> >>>>> If there was ever a time to consider pushing the AT91SAM9 devices >>>>> into eCos, this could be it! I am asking you for your thoughts on >>>>> how to proceed from here. Thanks! >>>> >>>> I am not an expert on ARM7/ARM9 differences but there are several >>>> eCos maintainers who have experience with multiple ARM variants and >>>> are well positioned to review the AT91SAM9 patch. I do not think >>>> motivation should be an issue here. We all wish to see eCos move >>>> forward and AT91SAM9 support is clearly very good for the project. >>>> >>>> My main concern is that we don't break eCos support for older ARM >>>> platforms in the process of improving the hardware abstraction for >>>> future platform ports. >>>> >>>> Is there an eCos maintainer with the necessary ARM expertise who can >>>> volunteer for the review of this contribution? >>> >>> There has been no response to this. >>> >>> The review of Evgeniy's patch is particularly important at present to >>> avoid merging issues for various new and planned platform ports on >>> ARM7/9. It is also important that the variant abstraction re-work is >>> reviewed by someone with real expertise in the area. >>> >>> What do you suggest? Should we ask for a volunteer from the wider eCos >>> community to review the patch in this instance? >> >> In truth, the main reason I (and probably others) have been studiously >> ignoring this is because the patch is far-reaching. That doesn't make >> it bad, but there's a lot of risk (and effort) here, with potential >> knock-on for ports we can't retest easily, and effects for any eCos >> user's own ports we don't have in our repo. >> >> It would also be hard to apply such a patch while using CVS, due to its >> problems with moving things around. I will kick off a discussion about >> VCS's because w.r.t this patch or otherwise, it needs to be resolved. > > I agree that the VCS debate needs to happen, but it seems dangerous to > link patch review with VCS changes in the sense that it introduces > further (unquantified) delay to the review of patches which have already > been pending for many months. By other hand we had gone almost whole circle of such debates. AFAIR, the community in the most agreed with that any distributed VC system will help us to move things more quickly. The question was: Git or HG. We know that what eCosCentric chose. It seems we have not to debate during a few months again. There were a few summaries on the list. > I am happy to volunteer for the hard graft of working with CVS if it > will help to get things moving on the ARM7/ARM9 front. to be or to call for? >> It doesn't feel right saying that we can't do something with the patch >> till we've switched VCS, but the practicalities do mean that there may >> be reasons to wait. Switching to new VCS is good time to think about ARM7/9 sorting in a background, again and again. I do not think that we can be the experts with all nowadays and future *smart* lines either from Atmel or from other vendors. Atmel named SAM line *Smart* (http://en.wikipedia.org/wiki/AT91SAM) to "encode" 3 CPU cores in SAM line: ARM7DTMI, ARM926, Cortex-M3. We know about the same "smart" lines from NXP, for example, etc. The next lines (=targets) will come soon. And do you think that reorganizing an existing arm/* branch can give us some kind of "AT91-centric" ARM7 package? >> It's likely this work would need to be committed initially on a branch. >> But again a reason for a new VCS is that merging from branch to trunk >> is much much much saner than with CVS, especially with moved files, >> renames, etc. (assuming the branch was made from the new VCS). The arrived AT91SAM9 port is the first bird. So, I would agree with Jonathan that distributed VCS would help us to do smart things with the sources likes CPU vendors do smart things with the ARM cores. I'm sorry, I have no answer on the John's "far-reaching" question the below, but, IMO "ARM9 v2" branch under CVS control can take the same long period as "FLASH v2" took the time under CVS before that was merged with mainstream. Let's get even first experimental trunk of eCos under DVCS. It is important that with distributed VCS of eCos we would collaborate with contributors more effectively. Well, this is my look/feel only. Sergei > Having just had a more detailed look, it appears that the new ARM7 > package is only used by the ARM7 AT91 platforms as the patch stands > today. It is less invasive than I had imagined. The other ARM7 platforms > are untouched. So I think we could phase in use of the new ARM7 package > for new ports only. The changes to the ARM9 variant package are more of > an all-or-nothing proposition but we have several ports to ARM9 > platforms in progress within the eCos community so the changes will > certainly get tested. However, some of the ARM9 platforms supported > within the eCos repository are obsolete and are likely to never be > tested again so if we break such platform support it will probably stay > broken forever. > > Jifl, should we think in terms of a ARM9 v2 variant package (like flash > v2) to mitigate the risk? > > If we can manage the risk and manage the CVS effort, the remaining major > obstacle to progress would be the verification that the abstractions are > correct. Perhaps an hour of effort for someone with the appropriate > experience? > > John Dallaway > eCos maintainer ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Getting Atmel AT91SAM9 into eCos 2010-03-09 2:00 ` Sergei Gavrikov @ 2010-03-09 16:30 ` Jonathan Larmour 0 siblings, 0 replies; 10+ messages in thread From: Jonathan Larmour @ 2010-03-09 16:30 UTC (permalink / raw) To: Sergei Gavrikov Cc: John Dallaway, eCos Maintainers, Evgeniy Dushistov, Daniel Helgason [ snip good stuff from Sergei ] On 09/03/10 02:00, Sergei Gavrikov wrote: > > I'm sorry, I have no answer on the John's "far-reaching" question the > below, but, IMO "ARM9 v2" branch under CVS control can take the same > long period as "FLASH v2" took the time under CVS before that was merged > with mainstream. One of the main difficulties there was directly because of CVS. The trunk had moved on (particularly in RedBoot's flash support), so there was a lot of overhead to merging. These merge headaches would be much less with a modern VCS, so it won't be as scary to merge. Which is a big reason why people kept putting it off. > Let's get even first experimental trunk of eCos under > DVCS. It is important that with distributed VCS of eCos we would > collaborate with contributors more effectively. Well, this is my > look/feel only. Clearly you're keen on distributed :-). I agree, but we'll discuss elsewhere. I'll try and get a mail out today. Jifl ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Getting Atmel AT91SAM9 into eCos 2010-03-08 15:59 ` John Dallaway 2010-03-09 2:00 ` Sergei Gavrikov @ 2010-03-09 16:25 ` Jonathan Larmour 1 sibling, 0 replies; 10+ messages in thread From: Jonathan Larmour @ 2010-03-09 16:25 UTC (permalink / raw) To: John Dallaway; +Cc: eCos Maintainers, Evgeniy Dushistov, Daniel Helgason On 08/03/10 15:59, John Dallaway wrote: > Jonathan Larmour wrote: >> >> It would also be hard to apply such a patch while using CVS, due to its >> problems with moving things around. I will kick off a discussion about >> VCS's because w.r.t this patch or otherwise, it needs to be resolved. > > I agree that the VCS debate needs to happen, but it seems dangerous to > link patch review with VCS changes in the sense that it introduces > further (unquantified) delay to the review of patches which have already > been pending for many months. I know it's not ideal, hence my comment about it not feeling right, but this patch in particular may justify it. > I am happy to volunteer for the hard graft of working with CVS if it > will help to get things moving on the ARM7/ARM9 front. It's not to do with hard graft using CVS. It's to do with proper configuration management, and tracking changes, and sensible merges. This patch moves a lot of stuff around between files. The right process for getting this support in (in a new VCS) is to create a branch, apply the patch, then make further changes and test in the branch, then merge to trunk. Of course once in the branch, anyone can start using it if they really want to. And as Sergei says I think the time is right to bring the VCS discussion to a close without it needing to drag out too long. >> It doesn't feel right saying that we can't do something with the patch >> till we've switched VCS, but the practicalities do mean that there may >> be reasons to wait. >> >> It's likely this work would need to be committed initially on a branch. >> But again a reason for a new VCS is that merging from branch to trunk is >> much much much saner than with CVS, especially with moved files, >> renames, etc. (assuming the branch was made from the new VCS). > > Having just had a more detailed look, it appears that the new ARM7 > package is only used by the ARM7 AT91 platforms as the patch stands > today. Yes but there are quite a few of those and they are popular. All sorts of people out there will have made their own ports. With things moving around, those ports break. It's not just a case of keeping the ports checked in to CVS working. > It is less invasive than I had imagined. The other ARM7 platforms > are untouched. So I think we could phase in use of the new ARM7 package > for new ports only. The changes to the ARM9 variant package are more of > an all-or-nothing proposition but we have several ports to ARM9 > platforms in progress within the eCos community so the changes will > certainly get tested. However, some of the ARM9 platforms supported > within the eCos repository are obsolete and are likely to never be > tested again so if we break such platform support it will probably stay > broken forever. We have to consider people's ports out there. People don't ship product based on an eval board - they have their own ports for their own hardware. Breakage should not be done lightly; it may well be necessary, but in that case we really have to be sure the abstractions are right to prevent having to break it again. (And having a VCS which can manage change sets will also make it a lot clearer to see what changes are required specifically to replicate the changes needed). > Jifl, should we think in terms of a ARM9 v2 variant package (like flash > v2) to mitigate the risk? Indeed I am advocating something like "flash v2" (which FAOD was always an informal name), which means development takes place on a branch and gets merged to trunk when we're happy with it, replacing what's there. FAOD it would be bad to have a new ARM9v2 package in the trunk. For the same reasons of avoiding unnecessary breakage of ports above, we'd have to keep it round forever. > If we can manage the risk and manage the CVS effort, the remaining major > obstacle to progress would be the verification that the abstractions are > correct. Perhaps an hour of effort for someone with the appropriate > experience? No, much more. From my own quick view of the sources, the idea looks roughly right, but the detail needs refinement. Jifl ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2010-03-09 16:30 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <1266877649.3024.105.camel@localhost.localdomain> 2010-02-23 9:26 ` Getting Atmel AT91SAM9 into eCos John Dallaway 2010-02-23 9:58 ` Evgeniy Dushistov 2010-02-23 16:53 ` Gary Thomas 2010-02-23 17:50 ` Evgeniy Dushistov 2010-03-08 13:11 ` John Dallaway 2010-03-08 13:54 ` Jonathan Larmour 2010-03-08 15:59 ` John Dallaway 2010-03-09 2:00 ` Sergei Gavrikov 2010-03-09 16:30 ` Jonathan Larmour 2010-03-09 16:25 ` Jonathan Larmour
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).