[ECOS] Dual Port RAM on MPC8xx

[ECOS] Dual Port RAM on MPC8xx

[Will Wagner]

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.

Will Wagner


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Dual Port RAM on MPC8xx

[Gary Thomas]

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.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Dual Port RAM on MPC8xx

[Will Wagner]

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

Re: [ECOS] Dual Port RAM on MPC8xx

[Gary Thomas]

On Wed, 2005-04-20 at 11:59 +0100, Will Wagner wrote:
> 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?
> 

This was to handle the case where you ran an application with an old
RedBoot and resetting the CPM would break existing I/O setups.

> 
> 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.
> > 
> 
> 
-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Serial Port in non-blocking mode

[Gatien Gillon]

I'm trying to make my AT91EB55 board communicate with a PC, when using the 
cyg_io_read function the program waits for an input wich is not what i want. 
In non blocking mode I keep on getting 0x0's when reading the port even if I 
have sended some characters.
Is there a way of reading the serial port and getting what's in the buffer 
without blocking the program if it's empty ?
Thanks 



-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Serial Port in non-blocking mode

[Andrew Lunn]

On Thu, Apr 21, 2005 at 05:02:09PM +0200, Gatien Gillon wrote:
> I'm trying to make my AT91EB55 board communicate with a PC, when using the 
> cyg_io_read function the program waits for an input wich is not what i 
> want. In non blocking mode I keep on getting 0x0's when reading the port 
> even if I have sended some characters.

Are you getting 0x0 as well as, or instead of?

        Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Serial Port in non-blocking mode

[Gatien Gillon]

I'm getting 0x0 instead of the caracter ... I'll send the code of my 
applciation tomorrow

----- Original Message ----- 
From: "Andrew Lunn" <andrew@lunn.ch>
To: "Gatien Gillon" <ggillon@ulb.ac.be>
Cc: <ecos-discuss@sources.redhat.com>
Sent: Thursday, April 21, 2005 5:39 PM
Subject: Re: [ECOS] Serial Port in non-blocking mode


> On Thu, Apr 21, 2005 at 05:02:09PM +0200, Gatien Gillon wrote:
>> I'm trying to make my AT91EB55 board communicate with a PC, when using 
>> the
>> cyg_io_read function the program waits for an input wich is not what i
>> want. In non blocking mode I keep on getting 0x0's when reading the port
>> even if I have sended some characters.
>
> Are you getting 0x0 as well as, or instead of?
>
>        Andrew
>
> -- 
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
> 



-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss