Freescale MPC5554 device tree (was: cross-compiling Linux for PowerPC e200 core?)
Grant Likely
grant.likely at secretlab.ca
Tue Mar 23 01:59:43 EST 2010
2010/3/22 Németh Márton <nm127 at freemail.hu>:
> Hi Grant,
>
> thanks for the comments, I solved some of the points you mentioned. I need some
> more time to work on the others. In the meantime I send the intermediate version.
>
> Grant Likely wrote:
>> 2010/3/13 Németh Márton <nm127 at freemail.hu>:
> [...]
>>> + memory at 40000000 {
>>> + device_type = "memory";
>>> + reg = <0x40000000 0x10000>; // 32KiB internal SRAM
>>> + };
>>
>> Oh.... this is the small SRAM. yeah, you should move this under the
>> appropriate bridge node, remove the device_type property, and add a
>> compatible property. Memory nodes at the root like this are used to
>> describe what is basically main memory (what Linux will execute out
>> of). You'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 sections
> the FLASH could be a good place. Then cstart has to initialize the initialized
> variables by copying data from FLASH to RAM and fill the BSS area with zero.
Hmmm. I don't know if anyone has kernel execute in place (XIP)
working on PowerPC.
>
> [...]
>>> + siu at 3f89000 { // System Integration Unit
>>> + compatible = "fsl,mpc5554-siu";
>>> + reg = <0x03f90000 0x4000>;
>>> + interrupts = <45 1 // External Interrupt Overrun 0-15
>>> + 46 1 // External Interrupt 0
>>> + 47 1 // External Interrupt 1
>>> + 48 1 // External Interrupt 2
>>> + 49 1 // External Interrupt 3
>>> + 50 1>; // External Interrupt 4-15
>>> + };
>>
>> 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? And I see that
>> all the level/edge sensing and masking/acknowledging is done at the
>> SIU level, not the intc level, correct? So, what you effectively have
>> is the SIU is *another* interrupt controller that is cascaded to the
>> intc. Therefore you need to add the following to this node:
>>
>> #interrupt-cells = <2>; // 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. They are either asserted, or they
>> are not, correct? At the moment you're specifying every intc
>> interrupt with 2 cells, and the 2nd cell is always '1'. I 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 interrupt
> numbers shall be kept on the siu at 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.
>>> + emios at 3fa0000 { // Modular Timer System
>>> + compatible = "fsl,mpc5554-emios";
>>> + reg = <0x03fa0000 0x4000>;
>>> + interrupts = <51 1 // Channel 0
>>> + 52 1 // Channel 1
>>> + 53 1 // Channel 2
>>> + 54 1 // Channel 3
>>> + 55 1 // Channel 4
>>> + 56 1 // Channel 5
>>> + 57 1 // Channel 6
>>> + 58 1 // Channel 7
>>> + 59 1 // Channel 8
>>> + 60 1 // Channel 9
>>> + 61 1 // Channel 10
>>> + 62 1 // Channel 11
>>> + 63 1 // Channel 12
>>> + 64 1 // Channel 13
>>> + 65 1 // Channel 14
>>> + 66 1 // Channel 15
>>> + 202 1 // Channel 16
>>> + 203 1 // Channel 17
>>> + 204 1 // Channel 18
>>> + 205 1 // Channel 19
>>> + 206 1 // Channel 20
>>> + 207 1 // Channel 21
>>> + 208 1 // Channel 22
>>> + 209 1>; // 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. But 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 match
> which comment.
You could do it in this style to keep the verbosity down:
interrupts = <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
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
More information about the Linuxppc-dev
mailing list