From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1865 invoked by alias); 20 Apr 2005 10:57:19 -0000 Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Received: (qmail 1789 invoked from network); 20 Apr 2005 10:57:07 -0000 Received: from unknown (HELO carallon.f9.co.uk) (80.229.37.120) by sourceware.org with SMTP; 20 Apr 2005 10:57:07 -0000 Received: from [192.168.42.8] by carallon.com (MDaemon.PRO.v7.2.1.R) with ESMTP id md50000004974.msg for ; Wed, 20 Apr 2005 11:59:42 +0100 Message-ID: <4266361A.5050802@carallon.com> Date: Wed, 20 Apr 2005 12:10:00 -0000 From: Will Wagner User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) MIME-Version: 1.0 To: Gary Thomas CC: eCos Discussion References: <42663119.306@carallon.com> <1113994224.1030.170.camel@hermes> In-Reply-To: <1113994224.1030.170.camel@hermes> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-Sender: willw@carallon.com X-Spam-Processed: carallon.f9.co.uk, Wed, 20 Apr 2005 11:59:42 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.42.8 X-Return-Path: will_wagner@carallon.com X-MDaemon-Deliver-To: ecos-discuss@ecos.sourceware.org Subject: Re: [ECOS] Dual Port RAM on MPC8xx X-SW-Source: 2005-04/txt/msg00209.txt.bz2 Thanks very much for that. Not sure how I missed it. In the alloc function instead of if ((bd < QUICC_BD_BASE) || (bd > QUICC_BD_END)) { // Most likely not set up - make a guess :-( bd = *nextBd = QUICC_BD_BASE+0x400; } Why not just check the reset has been called? Seems odd to need that guess? Gary Thomas wrote: > On Wed, 2005-04-20 at 11:38 +0100, Will Wagner wrote: > >>I'm trying to understand how the allocation of DPRAM is done in the >>function _mpc8xx_allocBd in cpm.c. >> >>Can someone explain why nextBD is initialised as: >> >>static short *nextBd = (short *)(CYGHWR_HAL_VSR_TABLE + 0x1F0); >> >>Presumably this is so that redboot and an application can cooperate when >>using the DPRAM? Why is this address chosen and when is it's contents >>ever initialised? >> >>Presumably it may not have been initialised as in _mpc8xx_allocBd there >>is this code: >> >> if ((bd < QUICC_BD_BASE) || (bd > QUICC_BD_END)) { >> // Most likely not set up - make a guess :-( >> bd = *nextBd = QUICC_BD_BASE+0x400; >> } >> >>I guess this is starting 0x400 into the DPRAM so that an apllication >>doesn't reuse any DPRAM used by redboot? Is this correct? I can find >>where redboot ever initialises this memory so I can't see how it works. >> >>Any help in understanding this is much appreciated. > > > Look about 10 lines below the "static short" line you quoted :-) > This value gets set when the CPM has been reset. > > The point is to keep track [minimally] of what DPRAM is in use > and, yes, one wants applications to know and respect the allocations > that RedBoot has already made. > > The choice was just an unused place in memory. This region of > memory already holds similar data that is shared between RedBoot > and applications. > -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss