Adding a device to the device tree source?

[datho]

A custom board based on the LS1021A-TWR is under development, and an Arria 5 GZ FPGA is attached to the ARM processor's IFC bus. According to the documentation on the Integrated Flash Controller (IFC), we can use the generic ASIC protocol on the IFC bus to interface to the FPGA. We are using Chip Select 3 as the CS for the FPGA, and we know the size of the FPGA. How do I configure the LS1021A-TWR.dts so that it would include the FPGA, and use the Generic ASIC protocol to access it? I'm not sure what needs to be placed in the compatibility field to grab the Linux driver that uses the generic ASIC protocol.

[scottwood]

There is no "Linux driver that uses the generic ASIC protocol".  You need to write your own driver to drive your chip, that binds to a compatible string that you choose, that describes the chip.

[datho]

Thanks for replying so soon, where can I view the current drivers for the IFC? The compatible field for the nor flash is "cfi-flash" but I have no idea which driver it's referring to.

I'm hoping that this can give me some insight into how the drivers are structured and what needs to be in them.

[scottwood]

Compatibles don't refer to drivers.  They describe hardware, and drivers bind to them.  "cfi-flash" is bound to by drivers/mtd/maps/physmap_of.c.

What specific functionality are you looking for?  The chipselect configuration should be done by U-Boot.  drivers/memory/fsl_ifc.c will handle error interrupts but otherwise isn't relevant.  You have a custom chip and that needs a custom driver, that maps the memory region and accesses whatever is located there.

[datho]

I'm trying to flash a load into the entire FPGA, so I'm just looking to write to the FPGA. If I'm understanding this correctly, I could accomplish this by having a memory mapped file for the FPGA.

Would it be a problem if I tried to write to the internal IFC registers to try and force the board to write to memory bank 3? I could just restore the registers back to their original values after I was done writing.

I was able to find the physmap_of.c file, but not the fsl_ifc.c file. I'm using QorIQ SDK v1.8.

[scottwood]

drivers/memory/fsl_ifc.c is in SDK v1.8.

What do you mean by "write to the internal IFC registers to try and force..."?  Which registers?  Again, in U-Boot you should make sure that the chipselect is set up (CPSR3/CSOR3), and that a LAW covers the address you've assigned.

After that, your Linux driver (or you can mmap /dev/mem if you prefer) just needs to ioremap() that address range, and access it.  You do not need to touch any IFC registers after the initial U-Boot setup.

[datho]

I wasn't able to call ioremap() on the ls1021a-twr since "#include <sys/io.h>" didn't define it. I don't think there's a header file for it on the ls1021atwr. Is there a way to get the library for ioremap? If not, is there an alternative to calling ioremap?

[scottwood]

ioremap() is a kernel function.  From userspace, use mmap() on /dev/ram.

[datho]

How do I handle chip select and setup CPSR3/CSOR3 in U-boot? Can I just set the variables in U-boot or do I need to edit something in the QorIQ SDK and recompile a new u-boot image? How and where would I set a LAW?

[scottwood · Accepted solution]

It's done at compile time.  You can find the macros for controlling CSPR/CSOR in the board header file.  Ignore the comment about a LAW -- that applies to powerpc, not arm.

[datho]

I found a ls1021atwr.h file, but I have no idea where the header file is being included or what new variables I need to define in order to change the CSPR3 and CSOR3 registers. The variables that already exist in the ls1021atwr.h file either don't specify a memory bank or specify memory bank 0 but none utilize memory bank 3.

Some of the relevant variables that currently exist in ls1021atwr.h:

#define CONFIG_SYS_NOR0_CSPR_EXT (0x0)

define CONFIG_SYS_NOR0_CSPR (CSPR_PHYS_ADDR(CONFIG_SYS_FLASH_BASE_PHYS) | \

                                                                 CSPR_PORT_SIZE_16 | \

                                                                     CSPR_MSEL_NOR | \

                                                                      CSPR_V)

#define CONFIG_SYS_NOR_CSOR (CSOR_NOR_ADM_SHIFT(4) | \                                                                                                                                 CSOR_NOR_TRHZ_80)

I'm trying to add my own variables that follow the structure of this header file.

For example:

#define CONFIG_SYS_GPCM3_CSPR_EXT (0x0)

#define CONFIG_SYS_GPCM3_CSPR (CSPR_PHYS_ADDR(CONFIG_SYS_FLASH) | \

                                                                     CSPR_MSEL_GPCM | \

                                                                     CSPR_V)

#define CONFIG_SYS_GPCM_CSOR (CSOR_GPCM_GPMODE(1) | \

                                                                 CSOR_GPCM_TRHZ_80)

CONFIG_SYS_NOR_CSOR doesn't specify a memory bank. Does that mean they just write to all IFC_CSOR registers 0-6?

Am I specifying variables correctly? I don't know where constants like CSOR_NOR_TRHZ_80 are defined. I also have no idea what's using this header file.

How can I ioremap an address that maps to memory bank 3? All 32 bit addresses on the LS1021A-TWR have documented use or are "reserved". mmap only accepts 32 bit values for the offset field, so I don't see how to access a different memory bank.

[scottwood]

The header is included by the build system.  drivers/misc/fsl_ifc.c is the file that is using the macros in question.

CONFIG_SYS_NOR_CSOR is only used to define CONFIG_SYS_CSOR0.  It's done this way because there are some boards where there are multiple NOR banks and/or where NOR and NAND chipselects can be switched based on which is used as the boot source.  For your device you can just directly define CONFIG_SYS_CSOR3 and CONFIG_SYS_CSPR3.

The address you choose needs to be in one of the IFC regions (see section 2.2 "Fixed memory map").  From the board header it looks like the area between 0x6800_0000 and 0x7fb0_0000 is free.  Also note that you can use mmap with up to 44-bit offsets, provided you build your program with large file support (#define _FILE_OFFSET_BITS 64 before including any headers).

[datho]

It took awhile for me to confirm that the changes I made would work, I recently changed to the rev.2 LS1021a-twr and had to reprogram all the changes we made in a new QorIQ SDK (1.9). The u-boot works, thanks so much for your help.

[Pavel]

Use mmap command. It is a POSIX-compliant Linux/Unix system call that maps files or devices into memory.

It is a method of memory-mapped file I/O.

For example, look at the following links (http://en.wikipedia.org/wiki/Mmap) and

(http://beej.us/guide/bgipc/output/html/multipage/mmap.html).

Have a great day,
Pavel

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[datho]

I was using mmap to read from internal registers in my Linux application project. I believe that for mmap to work for my purposes I would need a file similar to /dev/mem that would map out the FPGA internals. Do you have good documentation on creating a memory mapped file? Or is there a file on the Linux platform that will allow me to write to an address in memory bank 3 (therefore using chip select 3)?