From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4877 invoked by alias); 19 Mar 2003 18:22:25 -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 4859 invoked from network); 19 Mar 2003 18:22:25 -0000 To: Gary Thomas Cc: John Dallaway , eCos Maintainers Subject: Re: New CPM/DPRAM allocator References: <200303180848.24682.jld@ecoscentric.com> <200303191019.45969.jld@ecoscentric.com> <200303191545.45265.jld@ecoscentric.com> <1048093613.7462.5303.camel@hermes.chez-thomas.org> From: Nick Garnett Date: Wed, 19 Mar 2003 18:22:00 -0000 In-Reply-To: <1048093613.7462.5303.camel@hermes.chez-thomas.org> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-03/txt/msg00035.txt.bz2 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. -- Nick Garnett eCos Kernel Architect http://www.ecoscentric.com/ The eCos and RedBoot experts