Identifying Primecells

Identifying Primecells

[jonsmirl at gmail.com]

I'm working on device tree support for the NXP LPC3130. To do this
right I need to know what specific Primecells were used in the chip.
How do I identify the primecell numbers for the devices? It is a
926ejs core.


-- 
Jon Smirl
jonsmirl at gmail.com

Identifying Primecells

[Rob Herring]

On 09/22/2011 01:19 PM, jonsmirl at gmail.com wrote:
> I'm working on device tree support for the NXP LPC3130. To do this
> right I need to know what specific Primecells were used in the chip.
> How do I identify the primecell numbers for the devices? It is a
> 926ejs core.
> 

I'm not sure I understand the question.

The primecell periph id numbers are only in the DT if they are wrong in
the h/w for some reason. The compatible property should contain the
device model number (i.e. "arm,pl011" for the uart).

Rob

Identifying Primecells

[jonsmirl at gmail.com]

On Fri, Sep 23, 2011 at 8:46 AM, Rob Herring <robherring2@gmail.com> wrote:
> On 09/22/2011 01:19 PM, jonsmirl at gmail.com wrote:
>> I'm working on device tree support for the NXP LPC3130. To do this
>> right I need to know what specific Primecells were used in the chip.
>> How do I identify the primecell numbers for the devices? It is a
>> 926ejs core.
>>
>
> I'm not sure I understand the question.
>
> The primecell periph id numbers are only in the DT if they are wrong in
> the h/w for some reason. The compatible property should contain the
> device model number (i.e. "arm,pl011" for the uart).

So how do I figure out which id numbers to use for the NXP LPC3130?
Is the UART a pl011?


>
> Rob
>



-- 
Jon Smirl
jonsmirl at gmail.com

Identifying Primecells

[Rob Herring]

On 09/23/2011 08:11 AM, jonsmirl at gmail.com wrote:
> On Fri, Sep 23, 2011 at 8:46 AM, Rob Herring <robherring2@gmail.com> wrote:
>> On 09/22/2011 01:19 PM, jonsmirl at gmail.com wrote:
>>> I'm working on device tree support for the NXP LPC3130. To do this
>>> right I need to know what specific Primecells were used in the chip.
>>> How do I identify the primecell numbers for the devices? It is a
>>> 926ejs core.
>>>
>>
>> I'm not sure I understand the question.
>>
>> The primecell periph id numbers are only in the DT if they are wrong in
>> the h/w for some reason. The compatible property should contain the
>> device model number (i.e. "arm,pl011" for the uart).
> 
> So how do I figure out which id numbers to use for the NXP LPC3130?
> Is the UART a pl011?
> 
The chip's documentation or ARM's documentation. The existing board
code. Read each periph ID register.

Or the ones with drivers in the kernel:
find drivers -name '*pl[0-3]*'

Rob

Identifying Primecells

[jonsmirl at gmail.com]

On Fri, Sep 23, 2011 at 9:30 AM, Rob Herring <robherring2@gmail.com> wrote:
> On 09/23/2011 08:11 AM, jonsmirl at gmail.com wrote:
>> On Fri, Sep 23, 2011 at 8:46 AM, Rob Herring <robherring2@gmail.com> wrote:
>>> On 09/22/2011 01:19 PM, jonsmirl at gmail.com wrote:
>>>> I'm working on device tree support for the NXP LPC3130. To do this
>>>> right I need to know what specific Primecells were used in the chip.
>>>> How do I identify the primecell numbers for the devices? It is a
>>>> 926ejs core.
>>>>
>>>
>>> I'm not sure I understand the question.
>>>
>>> The primecell periph id numbers are only in the DT if they are wrong in
>>> the h/w for some reason. The compatible property should contain the
>>> device model number (i.e. "arm,pl011" for the uart).
>>
>> So how do I figure out which id numbers to use for the NXP LPC3130?
>> Is the UART a pl011?
>>
> The chip's documentation or ARM's documentation. The existing board
> code. Read each periph ID register.

Kernel support is out of tree, I'm trying to get it into shape for
submission. Nothing in the existing driver code mentions the
peripheral ID. I've asked NXP to identify them and they have not
responded.

Is peripheral use documented at ARM for the lpc3130? What I don't know
is if the peripherals have been modified or replaced with an
alternative implementation.

So I guess I need to figure out how to read the ID register.

>
> Or the ones with drivers in the kernel:
> find drivers -name '*pl[0-3]*'
>
> Rob
>



-- 
Jon Smirl
jonsmirl at gmail.com

Identifying Primecells

[Pawel Moll]

> Is peripheral use documented at ARM for the lpc3130? What I don't know
> is if the peripherals have been modified or replaced with an
> alternative implementation.
> 
> So I guess I need to figure out how to read the ID register.

I'm not sure what your problem exactly is, but if you want to know what
PeriphID for PL011 is, have a look here:

http://infocenter.arm.com/help/topic/com.arm.doc.ddi0183g/I18381.html

So if your UART is PL011, reading four 8-bit wide registers at
* base + 0xfe0
* base + 0xfe4
* base + 0xfe8
* base + 0xfec
should give you (respectively):
* 0x11
* 0x10
* 0x_4 (_ depends on the cell revision)
* 0x00

Of course AMBA bus match_id will do this for you so, as I said, I'm not
sure what the problem is...

If you don't know what the base address is, well, only NXP and their
datasheet can help you here.

Cheers!

Pawe?

Identifying Primecells

[jonsmirl at gmail.com]

On Fri, Sep 23, 2011 at 10:10 AM, Pawel Moll <pawel.moll@arm.com> wrote:
>> Is peripheral use documented at ARM for the lpc3130? What I don't know
>> is if the peripherals have been modified or replaced with an
>> alternative implementation.
>>
>> So I guess I need to figure out how to read the ID register.
>
> I'm not sure what your problem exactly is, but if you want to know what
> PeriphID for PL011 is, have a look here:
>
> http://infocenter.arm.com/help/topic/com.arm.doc.ddi0183g/I18381.html
>
> So if your UART is PL011, reading four 8-bit wide registers at
> * base + 0xfe0
> * base + 0xfe4
> * base + 0xfe8
> * base + 0xfec
> should give you (respectively):
> * 0x11
> * 0x10
> * 0x_4 (_ depends on the cell revision)
> * 0x00
>
> Of course AMBA bus match_id will do this for you so, as I said, I'm not
> sure what the problem is...

My registers don't seem to match up with the pl011 documentation...

Table 437. Register overview: UART (register base address 0x1500 1000)
Name	R/W	Address	Offset		Description
RBR	R	0x000	Receiver Buffer Register
THR	W	0x000	Transmitter Holding Register
DLL	R/W	0x000	Divisor Latch LSB
DLM	R/W	0x004	Divisor Latch MSB
IER	R/W	0x004	Interrupt	Enable Register
IIR	R	0x008	Interrupt	Identification Register
FCR	W	0x008	FIFO Control Register
LCR	R/W	0x00C	Line	 Control Register
MCR	R/W	0x010	Modem Control Register
LSR	R	0x014	Line Status Register
MSR	R	0x018	Modem Status Register
SCR	R/W	0x01C			Scratch Register
-	-	0x020			Reserved
ICR	R/W	0x024	IrDA	 Control Register
FDR	R/W	0x028	Fractional Divider Register
-	-	0x02C	Reserved
POP	W	0x030	NHP Pop Register
MODE	R/W	0x034	NHP Mode Selection Register
-	-	0x038-0xFD4	Reserved
INTCE	W	0xFD8	Interrupt	Clear Enable Register
INTSE	W	0xFDC	Interrupt	Set Enable Register
INTS	R	0xFE0	Interrupt	Status Register
INTE	R	0xFE4	Interrupt	Enable Register



>
> If you don't know what the base address is, well, only NXP and their
> datasheet can help you here.
>
> Cheers!
>
> Pawe?
>
>
>
>



-- 
Jon Smirl
jonsmirl at gmail.com

Identifying Primecells

[jonsmirl at gmail.com]

On Fri, Sep 23, 2011 at 10:17 AM, jonsmirl at gmail.com <jonsmirl@gmail.com> wrote:
>>
>> Of course AMBA bus match_id will do this for you so, as I said, I'm not
>> sure what the problem is...

The problem is that I have a bunch of drivers for all of the
peripherals that were written by NXP. But the kernel has standardized
drivers for a lot of the primecells. If the LPC3130 has used a
standard primecell I want to get rid of the NXP supplied driver and
switch to the standard one.  But in order to do that I need to
identify the peripherals that are unmodified primecells.

-- 
Jon Smirl
jonsmirl at gmail.com

Identifying Primecells

[Pawel Moll]

> My registers don't seem to match up with the pl011 documentation...
<...>
> INTCE	W	0xFD8	Interrupt	Clear Enable Register
> INTSE	W	0xFDC	Interrupt	Set Enable Register
> INTS	R	0xFE0	Interrupt	Status Register
> INTE	R	0xFE4	Interrupt	Enable Register

... nor any other PrimeCell, actually :-)

"Compliant" PrimeCells must have the PCellID in the last 4 registers:

http://infocenter.arm.com/help/topic/com.arm.doc.ddi0183g/I54776.html

* base + 0xff0 = 0x0d
* base + 0xff4 = 0xf0
* base + 0xff8 = 0x05
* base + 0xffc = 0xb1

Cheers!

Pawe?

Identifying Primecells

[jonsmirl at gmail.com]

On Fri, Sep 23, 2011 at 10:22 AM, Pawel Moll <pawel.moll@arm.com> wrote:
>> My registers don't seem to match up with the pl011 documentation...
> <...>
>> INTCE W ? ? ? 0xFD8 ? Interrupt ? ? ? Clear Enable Register
>> INTSE W ? ? ? 0xFDC ? Interrupt ? ? ? Set Enable Register
>> INTS ?R ? ? ? 0xFE0 ? Interrupt ? ? ? Status Register
>> INTE ?R ? ? ? 0xFE4 ? Interrupt ? ? ? Enable Register
>
> ... nor any other PrimeCell, actually :-)
>
> "Compliant" PrimeCells must have the PCellID in the last 4 registers:

I scanned though 0xff0/f for all of the devices. The only one that had
anything that makes sense is the Multiport Memory Controller -
0xb105f00d

So it looks like NXP made almost all of their own peripherals. Which
means I have to clean up the drivers for all of them.


> http://infocenter.arm.com/help/topic/com.arm.doc.ddi0183g/I54776.html
>
> * base + 0xff0 = 0x0d
> * base + 0xff4 = 0xf0
> * base + 0xff8 = 0x05
> * base + 0xffc = 0xb1
>
> Cheers!
>
> Pawe?
>
>
>



-- 
Jon Smirl
jonsmirl at gmail.com

Identifying Primecells

[Russell King - ARM Linux]

On Fri, Sep 23, 2011 at 10:17:32AM -0400, jonsmirl at gmail.com wrote:
> My registers don't seem to match up with the pl011 documentation...
> 
> Table 437. Register overview: UART (register base address 0x1500 1000)
> Name	R/W	Address	Offset		Description
> RBR	R	0x000	Receiver Buffer Register
> THR	W	0x000	Transmitter Holding Register
> DLL	R/W	0x000	Divisor Latch LSB
> DLM	R/W	0x004	Divisor Latch MSB
> IER	R/W	0x004	Interrupt	Enable Register
> IIR	R	0x008	Interrupt	Identification Register
> FCR	W	0x008	FIFO Control Register
> LCR	R/W	0x00C	Line	 Control Register
> MCR	R/W	0x010	Modem Control Register
> LSR	R	0x014	Line Status Register
> MSR	R	0x018	Modem Status Register
> SCR	R/W	0x01C			Scratch Register

This looks like an 8250 like clone.  You might be about to get away
with using a platform device for the 8250 driver specifying an io
shift of 2, base address 0x15001000.

What worries me is the extra registers below, and whether they need to
be programmed to something at runtime (rather than just being able to
rely on the standard 8250 register set.)

> -	-	0x020			Reserved
> ICR	R/W	0x024	IrDA	 Control Register
> FDR	R/W	0x028	Fractional Divider Register
> -	-	0x02C	Reserved
> POP	W	0x030	NHP Pop Register
> MODE	R/W	0x034	NHP Mode Selection Register
> -	-	0x038-0xFD4	Reserved
> INTCE	W	0xFD8	Interrupt	Clear Enable Register
> INTSE	W	0xFDC	Interrupt	Set Enable Register
> INTS	R	0xFE0	Interrupt	Status Register
> INTE	R	0xFE4	Interrupt	Enable Register

Identifying Primecells

[Linus Walleij]

2011/9/23 jonsmirl at gmail.com <jonsmirl@gmail.com>:

> So it looks like NXP made almost all of their own peripherals. Which
> means I have to clean up the drivers for all of them.

Totally from-scratch IP blocks exist but is uncommon.

When there are no helpfull primecell IDs giving the secret
of ancestry away readily, fall back to comparing register maps,
this usually reveals the family of hardware and possible
ancestors. (Like was quickly done for the 8250 derivate
serial.)

Yours,
Linus Walleij

Identifying Primecells

[Vitaly Wool]

Hi,

On Fri, Sep 23, 2011 at 9:11 PM, jonsmirl at gmail.com <jonsmirl@gmail.com> wrote:
> On Fri, Sep 23, 2011 at 10:22 AM, Pawel Moll <pawel.moll@arm.com> wrote:
>>> My registers don't seem to match up with the pl011 documentation...
>> <...>
>>> INTCE W ? ? ? 0xFD8 ? Interrupt ? ? ? Clear Enable Register
>>> INTSE W ? ? ? 0xFDC ? Interrupt ? ? ? Set Enable Register
>>> INTS ?R ? ? ? 0xFE0 ? Interrupt ? ? ? Status Register
>>> INTE ?R ? ? ? 0xFE4 ? Interrupt ? ? ? Enable Register
>>
>> ... nor any other PrimeCell, actually :-)
>>
>> "Compliant" PrimeCells must have the PCellID in the last 4 registers:
>
> I scanned though 0xff0/f for all of the devices. The only one that had
> anything that makes sense is the Multiport Memory Controller -
> 0xb105f00d
>
> So it looks like NXP made almost all of their own peripherals. Which
> means I have to clean up the drivers for all of them.
>

I have a vague recollection that some time ago NXP was using UARTs
that were basically 8250-compatible but with some twist. You may also
want to check the pnx8xxx_uart implementation for another type of
UARTs NXP used to have on their MIPS boards.

~Vitaly

Identifying Primecells

[jonsmirl at gmail.com]

On Sat, Sep 24, 2011 at 7:15 PM, Vitaly Wool <vitalywool@gmail.com> wrote:
> Hi,
>
> On Fri, Sep 23, 2011 at 9:11 PM, jonsmirl at gmail.com <jonsmirl@gmail.com> wrote:
>> On Fri, Sep 23, 2011 at 10:22 AM, Pawel Moll <pawel.moll@arm.com> wrote:
>>>> My registers don't seem to match up with the pl011 documentation...
>>> <...>
>>>> INTCE W ? ? ? 0xFD8 ? Interrupt ? ? ? Clear Enable Register
>>>> INTSE W ? ? ? 0xFDC ? Interrupt ? ? ? Set Enable Register
>>>> INTS ?R ? ? ? 0xFE0 ? Interrupt ? ? ? Status Register
>>>> INTE ?R ? ? ? 0xFE4 ? Interrupt ? ? ? Enable Register
>>>
>>> ... nor any other PrimeCell, actually :-)
>>>
>>> "Compliant" PrimeCells must have the PCellID in the last 4 registers:
>>
>> I scanned though 0xff0/f for all of the devices. The only one that had
>> anything that makes sense is the Multiport Memory Controller -
>> 0xb105f00d
>>
>> So it looks like NXP made almost all of their own peripherals. Which
>> means I have to clean up the drivers for all of them.
>>
>
> I have a vague recollection that some time ago NXP was using UARTs
> that were basically 8250-compatible but with some twist. You may also
> want to check the pnx8xxx_uart implementation for another type of
> UARTs NXP used to have on their MIPS boards.

I have a driver for the chip. It is a 8250 compatible that has been
extended with DMA support.

I've drivers for all of the peripherals on the chip. As I start
sending them out for RFC maybe we can identify them as variants of
drivers already in the kernel so that I don't add 20 new drivers if
some are redundant.

-- 
Jon Smirl
jonsmirl at gmail.com