linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Grant Likely <grant.likely@secretlab.ca>
To: "Németh Márton" <nm127@freemail.hu>
Cc: linuxppc-dev Development <linuxppc-dev@ozlabs.org>,
	David Gibson <david@gibson.dropbear.id.au>
Subject: Re: Freescale MPC5554 device tree (was: cross-compiling Linux for PowerPC e200 core?)
Date: Mon, 22 Mar 2010 08:59:43 -0600	[thread overview]
Message-ID: <fa686aa41003220759m438472efra2b889e54c73aef1@mail.gmail.com> (raw)
In-Reply-To: <4BA70E28.9080007@freemail.hu>

2010/3/22 N=E9meth M=E1rton <nm127@freemail.hu>:
> Hi Grant,
>
> thanks for the comments, I solved some of the points you mentioned. I nee=
d some
> more time to work on the others. In the meantime I send the intermediate =
version.
>
> Grant Likely wrote:
>> 2010/3/13 N=E9meth M=E1rton <nm127@freemail.hu>:
> [...]
>>> + =A0 =A0 =A0 memory@40000000 {
>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 device_type =3D "memory";
>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 reg =3D <0x40000000 0x10000>; =A0 =A0 // =
32KiB internal SRAM
>>> + =A0 =A0 =A0 };
>>
>> Oh.... this is the small SRAM. =A0yeah, you should move this under the
>> appropriate bridge node, remove the device_type property, and add a
>> compatible property. =A0Memory nodes at the root like this are used to
>> describe what is basically main memory (what Linux will execute out
>> of). =A0You'll want a new memory node for the external ram hooked up to
>> the 5554.
>
> Yes, it is the small one (actually 64KiB, I corrected the comment also).
> I added the external memory of the MPC5554DEMO evaluation board which has
> a size of 512KiB.

Yikes.  Half a meg is tiny for running Linux.

> Would it be possible to program the uncompressed kernel to the FLASH so
> it can run directly from there? I guess for the code and the constant sec=
tions
> the FLASH could be a good place. Then cstart has to initialize the initia=
lized
> variables by copying data from FLASH to RAM and fill the BSS area with ze=
ro.

Hmmm.  I don't know if anyone has kernel execute in place (XIP)
working on PowerPC.

>
> [...]
>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 siu@3f89000 { =A0 =A0 =A0=
 =A0 =A0 // System Integration Unit
>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 compatibl=
e =3D "fsl,mpc5554-siu";
>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 reg =3D <=
0x03f90000 0x4000>;
>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 interrupt=
s =3D <45 1 =A0 =A0 =A0// External Interrupt Overrun 0-15
>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 46 1 =A0 =A0 =A0// External Interrupt 0
>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 47 1 =A0 =A0 =A0// External Interrupt 1
>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 48 1 =A0 =A0 =A0// External Interrupt 2
>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 49 1 =A0 =A0 =A0// External Interrupt 3
>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 50 1>; =A0 =A0// External Interrupt 4-15
>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 };
>>
>> This doesn't look quite right.... /me goes to look at the 5554
>> reference manual....
>>
>> Okay, so all the external IRQs go through the SIU then, even though
>> the first 4 get passed straight through to the intc? =A0And I see that
>> all the level/edge sensing and masking/acknowledging is done at the
>> SIU level, not the intc level, correct? =A0So, what you effectively have
>> is the SIU is *another* interrupt controller that is cascaded to the
>> intc. =A0Therefore you need to add the following to this node:
>>
>> #interrupt-cells =3D <2>; =A0 // cell1:extirq#, cell2:level/edge flags
>> interrupt-controller;
>>
>> Also give the node a label so that nodes for external devices can
>> reference it for hooking up external irqs by overriding the top-level
>> interrupt-parent property.
>>
>> Also, it would appear that intc interrupts don't have any level/edge
>> configuration associated with them. =A0They are either asserted, or they
>> are not, correct? =A0At the moment you're specifying every intc
>> interrupt with 2 cells, and the 2nd cell is always '1'. =A0I think you
>> can change #interrupt-cells to <1> in the intc node and drop the '1'
>> everywhere.
>>
>> When you write your intc driver, you'll also need to write the
>> cascaded driver for the external IRQs.
>
> I tried to solve this point but I'm not quite sure whether the SIU interr=
upt
> numbers shall be kept on the siu@3f89000 node or not.

Yes, you'll want the irq numbers to remain in the siu node because
those are the 'cascade' irqs that the siu raises when the external
irqs are asserted.

>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 emios@3fa0000 { =A0 =A0 =
=A0 =A0 // Modular Timer System
>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 compatibl=
e =3D "fsl,mpc5554-emios";
>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 reg =3D <=
0x03fa0000 0x4000>;
>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 interrupt=
s =3D <51 1 =A0 =A0 =A0// Channel 0
>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 52 1 =A0 =A0 =A0// Channel 1
>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 53 1 =A0 =A0 =A0// Channel 2
>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 54 1 =A0 =A0 =A0// Channel 3
>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 55 1 =A0 =A0 =A0// Channel 4
>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 56 1 =A0 =A0 =A0// Channel 5
>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 57 1 =A0 =A0 =A0// Channel 6
>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 58 1 =A0 =A0 =A0// Channel 7
>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 59 1 =A0 =A0 =A0// Channel 8
>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 60 1 =A0 =A0 =A0// Channel 9
>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 61 1 =A0 =A0 =A0// Channel 10
>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 62 1 =A0 =A0 =A0// Channel 11
>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 63 1 =A0 =A0 =A0// Channel 12
>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 64 1 =A0 =A0 =A0// Channel 13
>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 65 1 =A0 =A0 =A0// Channel 14
>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 66 1 =A0 =A0 =A0// Channel 15
>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 202 1 =A0 =A0 // Channel 16
>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 203 1 =A0 =A0 // Channel 17
>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 204 1 =A0 =A0 // Channel 18
>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 205 1 =A0 =A0 // Channel 19
>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 206 1 =A0 =A0 // Channel 20
>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 207 1 =A0 =A0 // Channel 21
>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 208 1 =A0 =A0 // Channel 22
>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 209 1>; =A0 // Channel 23
>>
>> These long lists bother me, but looking at the manual they seem to
>> describe the actual hardware architecture, so I think they are
>> probably fine. =A0But you may want to compact your formatting somewhat.
>> You can probably list more than one channel per
>> source line in the file.
>>
>> Ditto through the rest of the file.
>
> I would keep the list like this because in this case it is easy to find
> which comment belongs to which interrupt number. Otherwise one would need
> to count the interrupt numbers and the comment to find out which number m=
atch
> which comment.

You could do it in this style to keep the verbosity down:

      interrupts =3D <51 52 53 54 55 56 57 58  // Channels 0-7
                    59 60 61 62 63 64 65 66  // Channels 8-15
                    202 203 204 205 206 207 208 209>;  // Channel 16-23

--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

  reply	other threads:[~2010-03-22 15:00 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-07  6:50 cross-compiling Linux for PowerPC e200 core? Németh Márton
2010-03-08 17:34 ` Grant Likely
2010-03-08 18:44   ` Németh Márton
2010-03-08 19:08     ` Grant Likely
2010-03-09  7:02       ` Németh Márton
2010-03-09  7:35         ` Grant Likely
2010-03-11  6:11           ` Freescale MPC5554 device tree (was: cross-compiling Linux for PowerPC e200 core?) Németh Márton
2010-03-11  6:23             ` David Gibson
2010-03-12  6:26               ` Németh Márton
2010-03-12 12:14                 ` Grant Likely
2010-03-12 22:36                   ` David Gibson
2010-03-12 23:04                     ` Grant Likely
2010-03-13  3:22                       ` Segher Boessenkool
2010-03-13  3:21                     ` Segher Boessenkool
2010-03-13 11:59                   ` Németh Márton
2010-03-17 18:12                     ` Németh Márton
2010-03-17 19:02                     ` Grant Likely
2010-03-22  6:28                       ` Németh Márton
2010-03-22 14:59                         ` Grant Likely [this message]
2010-03-23  5:45                           ` Németh Márton
2010-03-30  6:54                       ` Németh Márton
2010-03-08 17:47 ` cross-compiling Linux for PowerPC e200 core? Segher Boessenkool
2010-03-08 18:49   ` Németh Márton
2010-03-08 20:41     ` Segher Boessenkool
     [not found]     ` <53452.84.105.60.153.1268080871.squirrel__48847.2990495667$1268080944$gmane$org@gate.crashing.org>
2010-03-09 14:24       ` Detlev Zundel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=fa686aa41003220759m438472efra2b889e54c73aef1@mail.gmail.com \
    --to=grant.likely@secretlab.ca \
    --cc=david@gibson.dropbear.id.au \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=nm127@freemail.hu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
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).