83xx immap_qe.h -> SIR type def error?

[Russell McGuire]

I should state, I am looking at the MPC8360ERM.pdf Rev 2.0

-Russ

> -----Original Message-----
> From: Russell McGuire [mailto:rmcguire at videopresence.com]
> Sent: Friday, February 01, 2008 1:03 PM
> To: 'Kumar Gala'
> Cc: 'linuxppc-embedded at ozlabs.org'
> Subject: RE: 83xx immap_qe.h -> SIR type def error?
> 
> Kumar,
> 
> Yes in the main memeory map they are just listed as 1K RAM blocks.
> However, in the UM Section 36.6.1 <pg 36-12 or pg 1728 in the PDF>.
> 
> It gives the breakout for the RAM, which clearly indicates 16 bit fields.
> <Here is a short clip from Figure 36-8>
> 
> Access: Read/Write
> 0 1 2 3 4 5 6 7 10 11 13 14 15
> MCC SWTR SSEL 1 SSEL 2 SSEL 3 SSEL 4 SGS CSEL CNT BYT LST
> Figure 36-8. SI RAM Entry for UCC
> 
> Honest, mistake as if I were writing the header file I'd not have time to
> ready all 2000+ pages of the UM. We find these only as somebody goes in an
> tries to use them.
> And I am guessing not a lot of customers use the SI block.
> 
> -Russ
> > -----Original Message-----
> > From: Kumar Gala [mailto:galak at kernel.crashing.org]
> > Sent: Friday, February 01, 2008 6:56 AM
> > To: rmcguire at videopresence.com
> > Cc: linuxppc-embedded at ozlabs.org
> > Subject: Re: 83xx immap_qe.h -> SIR type def error?
> >
> >
> > On Feb 1, 2008, at 5:47 AM, Russell McGuire wrote:
> >
> > > All Freescale,
> > >
> > > Not sure if this is the place to post this, but I have run across
> > > what I
> > > consider to be a possible type error in the immap_qe.h file, for the
> > > asm/powerpc branch.
> > >
> > > In the file immap_qe.h
> > >
> > > /* SI Routing Tables */
> > > struct sir {
> > > 	u8  tx[0x400];
> > > 	u8  rx[0x400];
> > > 	u8  res0[0x800];
> > > }
> > >
> > > Shouldn't these types be defined as __be16 ?
> > >
> > > According to the Freescale manual this is a 16 bit field, not an 8-bit
> > > field.
> > >
> > > Spent an hour trying to figure out why I couldn't fill this field
> > > out with
> > > upper 8 bits last night.
> > >
> > > Thoughts?
> >
> > I'm guessing it was done this way since they are just looked as base
> > offsets.  Where in the UM do you see anything about them being 16-bit
> > quantities?  (I'm really know little about this).
> >
> > - k