From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29701 invoked by alias); 19 Mar 2003 18:26:44 -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 29532 invoked from network); 19 Mar 2003 18:26:42 -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> <200303191019.45969.jld@ecoscentric.com> <200303191545.45265.jld@ecoscentric.com> <1048093613.7462.5303.camel@hermes.chez-thomas.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-4) Date: Wed, 19 Mar 2003 18:26:00 -0000 Message-Id: <1048098401.9579.5496.camel@hermes.chez-thomas.org> Mime-Version: 1.0 X-SW-Source: 2003-03/txt/msg00036.txt.bz2 On Wed, 2003-03-19 at 11:22, Nick Garnett wrote: > Gary Thomas writes: > > > On Wed, 2003-03-19 at 08:45, John Dallaway wrote: > > > Nick Garnett wrote: > > > > > > > > 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. > > > > > > Good. Not as pervasive as I suspected. It looks like Gary is investigating > > > why the incompatibility is there at all. Hopefully he can resolve the > > > compatibility issue. I will delay my vote on accepting this into the 2.0 > > > branch pending his report. > > > > I've just tried this - CVS latest eCos + old (2.0beta) RedBoot > > on the Adder and I can't see a failure. I tried both the default > > and net templates. > > > > Nick - any ideas how I can duplicate the failure? > > > > I'm afraid not. I was, until Monday, using the default RedBoot > installed by A&M on the board. Maybe there were other changes since > that was made that make this problem go away. > > As explained elsewhere, what I saw was the value at > (CYGHWR_HAL_VSR_TABLE + 0x1F0) was 0xFFFF. This caused > _mpc8xx_allocBd() to reset it to QUICC_BD_BASE and start allocating > network rxbds from there. At some point during that process it > obviously overwrote something being used by redboot's serial device, > which then went haywire. > > I don't see how the code as it stands can avoid this. How does the new > eCos know where to allocate BDs to avoid trampling on an old RedBoot's > BDs? Just allocating from the start it seems bound to trample on > something important. Only that the old code didn't use 0x2000 for it's buffers, but 0x2800 (for the serial ports). The only driver that this should affect would be the serial driver in the installed RedBoot. If the new allocator is using a different "base", then there should be no conflict. Do you recall what configurations/templates/etc you were using? -- ------------------------------------------------------------ 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 ------------------------------------------------------------