linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
* questions about mpc82xx_ads and porting to other, similar, platform
@ 2007-07-13  8:51 Alexandros Kostopoulos
  2007-07-13 18:24 ` Scott Wood
  0 siblings, 1 reply; 2+ messages in thread
From: Alexandros Kostopoulos @ 2007-07-13  8:51 UTC (permalink / raw)
  To: linuxppc-dev

Hello all,

I am trying to port kernel 2.6.22.1 to my own platform, which incorporat=
es  =

an mpc8275 chip. I'm using platform code for mpc82xx_ads as a template (=
is  =

this right in the first place?). I have a couple of questions:

1. mpc82xx_ads.c uses init_scc_ioports function to initialize the scc  =

uarts. However, this function is only used by the code in
arch/powerpc/sysdev/fsl_soc.c, and spefically in fs_enet_of_init(), whic=
h  =

is used to initialize the ethernet driver and not the cpm_uart driver.
On the other hand, cpm_uart_of_init() function seems to be the one that =
 =

initializes the uarts in cpm, and actually makes use of the device-id,  =

model, rx-clock and tx-clock properties of the scc nodes in OF tree. So,=
  =

AFAICT, init_scc_ioports should not be there, since it won't be actually=
  =

called at all (although I have not actually tested this - I haven't yet =
 =

managed to boot the kernel). Instead, cpm_uart_of_init should take care =
of  =

everything, except for the pport initialization, which is done in u-boot=
  =

anyway (at least in my case). Any thoughts on this?

2. I have also some questions regarding the device tree. Why are there t=
wo  =

nodes regarding the interrupt controller in there? and in the top level =
 =

node, what does this property means:  reg =3D <f8200000 f8200004>; ?
Finally, in the memory node, the reg property defines a second mem regio=
n,  =

(f4500000 f4500020). What is this? maybe a special memory mapped  =

peripheral of this board? If I have a board with many mem configurations=
  =

(e.g. it uses a DIMM SDRAM what can be changed), what value should I pla=
ce  =

in the mem node? I have to change dts every time I insert a new DIMM?

any help would be greatly appreciated,

thank you in advance

Alex

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: questions about mpc82xx_ads and porting to other, similar, platform
  2007-07-13  8:51 questions about mpc82xx_ads and porting to other, similar, platform Alexandros Kostopoulos
@ 2007-07-13 18:24 ` Scott Wood
  0 siblings, 0 replies; 2+ messages in thread
From: Scott Wood @ 2007-07-13 18:24 UTC (permalink / raw)
  To: Alexandros Kostopoulos; +Cc: linuxppc-dev

On Fri, Jul 13, 2007 at 11:51:15AM +0300, Alexandros Kostopoulos wrote:
> I am trying to port kernel 2.6.22.1 to my own platform, which incorporates  
> an mpc8275 chip. I'm using platform code for mpc82xx_ads as a template (is  
> this right in the first place?). I have a couple of questions:

I suggest waiting until I can get my 8xx/82xx patchset out (which should
happen early next week...  it would have been earlier if I hadn't gotten
distracted trying to get PCI to work right).  It addresses the things you
point out.

> 1. mpc82xx_ads.c uses init_scc_ioports function to initialize the scc
> uarts. However, this function is only used by the code in
> arch/powerpc/sysdev/fsl_soc.c, and spefically in fs_enet_of_init(),
> which is used to initialize the ethernet driver and not the cpm_uart
> driver. On the other hand, cpm_uart_of_init() function seems to be the
> one that initializes the uarts in cpm, and actually makes use of the
> device-id, model, rx-clock and tx-clock properties of the scc nodes in
> OF tree. So, AFAICT, init_scc_ioports should not be there, since it
> won't be actually called at all (although I have not actually tested
> this - I haven't yet managed to boot the kernel). Instead,
> cpm_uart_of_init should take care of everything, except for the pport
> initialization, which is done in u-boot anyway (at least in my case).
> Any thoughts on this?

All such port configuration callbacks are removed in my patchset; the
bootloader and/or platform code is responsible for setting it up.

> 2. I have also some questions regarding the device tree. Why are there two  
> nodes regarding the interrupt controller in there? 

There are two interrupt controllers on the mpc8272ads: one for PCI, and
another for everything else.

> and in the top level node, what does this property means: reg =
> <f8200000 f8200004>; 

It means the device tree is buggy.  It should say <f8200000 8>.

> Finally, in the memory node, the reg property defines a second mem
> region, (f4500000 f4500020). What is this? 

More device tree brokenness.  It's the board control and status register
block, which has nothing to do with memory.

> maybe a special memory mapped peripheral of this board? If I have a
> board with many mem configurations (e.g. it uses a DIMM SDRAM what can
> be changed), what value should I place in the mem node? I have to
> change dts every time I insert a new DIMM?

No, u-boot or the bootwrapper should fill in the memory size.

-Scott

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2007-07-13 18:25 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-07-13  8:51 questions about mpc82xx_ads and porting to other, similar, platform Alexandros Kostopoulos
2007-07-13 18:24 ` Scott Wood

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).