From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11383 invoked by alias); 19 Mar 2003 14:38:06 -0000 Mailing-List: contact ecos-maintainers-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: ecos-maintainers-owner@sources.redhat.com Received: (qmail 11250 invoked from network); 19 Mar 2003 14:38:03 -0000 Subject: Re: New CPM/DPRAM allocator From: Gary Thomas To: Nick Garnett Cc: John Dallaway , eCos Maintainers In-Reply-To: References: <200303180848.24682.jld@ecoscentric.com> <1048014798.7462.3684.camel@hermes.chez-thomas.org> <200303191019.45969.jld@ecoscentric.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-4) Date: Wed, 19 Mar 2003 14:38:00 -0000 Message-Id: <1048084683.7462.4976.camel@hermes.chez-thomas.org> Mime-Version: 1.0 X-SW-Source: 2003-03/txt/msg00027.txt.bz2 On Wed, 2003-03-19 at 04:07, Nick Garnett wrote: > John Dallaway writes: > > > A few of questions: > > > > 1) Does this incompatibilty affect _all_ targets which run both RedBoot and > > eCos? > > Just PowerPC QUICC targets, like the MBX, Adder or Viper, for example. > > > 2) Could the new allocator implementation be modified in any way to preserve > > compatibility? > > Possibly. But I'll defer to Gary on this one. > The more I look at this, the less I understand why it fails now. The new allocation scheme should not clash - i.e. mixing new eCos with old RedBoot should be OK. Perhaps if I can figure out why this is failing, I can propose a change which will not cause problems. > > 3) To what extent might the new allocator perturb eCos functionality other > > than by a stepwise "it will work or it will be completely broken". > > It shouldn't affect anything else. Failure modes are hard to specify > since they depend on the contents of what is currently an > uninitialized location in RAM. Different instances of RedBoot might > have different values there. > > We might even be able to add a test to the DPRAM code to detect an old > RedBoot and generate an error message before proceeding. > > > 4) Is a further break in compatibility possible as potential issues with the > > new allocator are ironed out? > > Unlikely. The code is only a handful of lines. > > > > > We need to determine how to manage the switch over to the new CPM/DPRAM > > allocator smoothly for everyone. From my perspective, it is certainly > > unfortunate that this innovation has arrived between 2.0 beta and 2.0 > > final. Were it not for the break in compatibility, I would vote against > > incorporating this change for 2.0 final since the change will (to a certain > > extent) invalidate beta testing by the net community. However, it would > > also be undesirable for 2.0 final RedBoot to be incompatible with anonCVS > > eCos from day 1. Users are likely to want to stick with a release version > > of the firmware while experimenting with eCos from anonCVS. > > > > It only affects a handful of boards: MBX, VIPER, ADDER, TS1000. QUICC2 > targets like the tS6 and VADS are not affected, and non-QUICC MPC8xx > targets like the CMA28x and FADS boards are not affected. > > -- > Nick Garnett eCos Kernel Architect > http://www.ecoscentric.com/ The eCos and RedBoot experts -- ------------------------------------------------------------ Gary Thomas | MLB Associates | Consulting for the +1 (970) 229-1963 | Embedded world http://www.mlbassoc.com/ | email: | gpg: http://www.chez-thomas.org/gary/gpg_key.asc ------------------------------------------------------------