From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3682 invoked by alias); 11 Nov 2003 01:19:28 -0000 Mailing-List: contact ecos-discuss-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@sources.redhat.com Received: (qmail 3671 invoked from network); 11 Nov 2003 01:19:27 -0000 Received: from unknown (HELO atheros.com) (65.212.155.130) by sources.redhat.com with SMTP; 11 Nov 2003 01:19:27 -0000 Received: from [10.10.16.35] (account adrian HELO atheros.com) by atheros.com (CommuniGate Pro SMTP 4.0.6) with ESMTP id 4567797 for ecos-discuss@sources.redhat.com; Mon, 10 Nov 2003 17:19:20 -0800 Message-ID: <3FB03907.1070604@atheros.com> Date: Tue, 11 Nov 2003 01:19:00 -0000 From: Adrian Caceres User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'ecos-discuss@sources.redhat.com'" References: <1068142394.13745.6883.camel@hermes> In-Reply-To: <1068142394.13745.6883.camel@hermes> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [ECOS] ECOS development model X-SW-Source: 2003-11/txt/msg00144.txt.bz2 I was a tad surprised by the answer below regarding what version of ECOS should an app developer use so I was wondering what did I miss: - What is open source community development model for ECOS? Many open source projects have some form of a stable release model where some form of testing has been performed and it is somewhat "blessed" by the maintainers. I thought/assumed that ECOS had a similar model and that 2.0 was a stable version. And that it would be expected for an ECOS user to base a new project off such stable version. And that going forwards there would be other stable releases such as 2.1 or 3.0, etc. So I was a tad surprised that Gary recommended the use of the CVS tree directly . I would have expected that the CVS tree was really the ECOS development source tree, that it would suffer from the instability such a source would have, and thus would not be a recommended choice for someone developing an app for it. Did I miss something? Was the context of the thread below regarding a feature that is going into the ECOS source tree and I missed it? thanks adrian Gary Thomas wrote: >On Thu, 2003-11-06 at 11:13, Snider, Marc wrote: > > >>Makes sense, Gary. Thanks for the pointers... Assuming I'm otherwise >>entirely comfortable with what version 1.3.1 provides, will I need to go to >>(do you advise) version 2.0 before making these mods or is 1.3.1 adequate? >> >> >> > >1.3.1 is too out of date - don't even think about it. > >Use the latest from CVS - that's the best approach. > > > >>Thanks again, >>Marc >> >> >>-----Original Message----- >>From: Gary Thomas [mailto:gary@mlbassoc.com] >>Sent: Thursday, November 06, 2003 12:42 PM >>To: Snider, Marc >>Cc: 'ecos-discuss@sources.redhat.com' >>Subject: RE: [ECOS] Redboot image load via PCI bus? >> >> >>On Thu, 2003-11-06 at 10:37, Snider, Marc wrote: >> >> >>>My thought was to provide the standard I/O device driver routines (open, >>>close, read...) on top of the PCI accesses and thus shield the higher >>> >>> >>layer >> >> >>>loader code. I'd make it look like the image data was coming from >>> >>> >>somewhere >> >> >>>else like the flash. It looks like do_load doesn't care where the image >>>data comes from as long as the native format (in my case likely SREC) is >>>maintained... >>> >>>Yes, the host does have access to the memory on the target system, but it >>>would be preferable to pull the data from the host as opposed to pushing >>> >>> >>it >> >> >>>from there to the target... >>> >>> >>> >>Understood. If you look carefully at how the "load" command works, >>you won't need to make *any* changes directly to it, but just add a >>new I/O method. Also, I'd suggest that you put your new PCI method >>in your platform HAL - there is no need to mess about with the core >>of RedBoot. >> >>note: a lot of care has been taken (by me) to allow such extensions >>without any [direct] changes to the RedBoot tree. >> >>... Ah, the joy of tables. >> >> >> >>>Marc >>> >>> >>>-----Original Message----- >>>From: Gary Thomas [mailto:gary@mlbassoc.com] >>>Sent: Thursday, November 06, 2003 11:46 AM >>>To: Snider, Marc >>>Cc: 'ecos-discuss@sources.redhat.com' >>>Subject: Re: [ECOS] Redboot image load via PCI bus? >>> >>> >>>On Thu, 2003-11-06 at 09:45, Snider, Marc wrote: >>> >>> >>>>Is there a canned method implemented somewhere for loading an image via >>>> >>>> >>>the >>> >>> >>>>PCI bus (from another host), as opposed to using the network or loading >>>> >>>> >>>from >>> >>> >>>>flash? I'd like to load an image from a control host across the PCI >>>> >>>> >>bus >> >> >>>>and then burn it to flash... I'm assuming that if there isn't then >>>> >>>> >>I'll >> >> >>>>need to modify the do_load command and provide a set of I/O routines >>>> >>>> >>that >> >> >>>>map PCI accesses into standard I/O convention... >>>> >>>>I'm on a PowerPC440 platform, if the platform matters. >>>> >>>> >>>What method would you use to access the image via the PCI? >>>Can your host access the memory on the board? >>> >>>-- >>>Gary Thomas >>>MLB Associates >>> >>> -- Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos and search the list archive: http://sources.redhat.com/ml/ecos-discuss