Hello,

I've recently designed a custom circuit board based around the AT91SAM9G20 processor. In the same way as pg. 154 of the datasheet (http://www.atmel.com/dyn/resources/prod ... oc6384.pdf), I've hooked up a FPGA to the EBI bus interface. I've written code in Verilog for the FPGA to mimic an SRAM chip. The idea is to have the AT91SAM9G20 read data from the FPGA over the parallel EBI interface.

I've made the following modification to the AT91bootstrap code to turn on the CS0 SRAM. This code is adapted from the SAM-BA code:

writel(0x00000002, AT91C_BASE_SMC + SMC_SETUP0);
writel(0x0A0A0A06, AT91C_BASE_SMC + SMC_PULSE0);
writel(0x000A000A, AT91C_BASE_SMC + SMC_CYCLE0);
// 16-bit data bus
unsigned int regCTRL0 = ( AT91C_SMC_READMODE | AT91C_SMC_DBW_WIDTH_SIXTEEN_BITS
| AT91C_SMC_WRITEMODE
| AT91C_SMC_NWAITM_NWAIT_DISABLE
| ((0x1 << 16) & AT91C_SMC_TDF) );
writel( regCTRL0, AT91C_BASE_SMC + SMC_CTRL0);

Within a C program running on the Linux operating system, how would I directly access memory locations on the SRAM bus? The FPGA logic automatically decodes SRAM memory addresses passed on the EBI, but how would I read from SRAM within the C program?

Would I use a pointer, or would I use the mmap() function?

The FPGA mimics a standard SRAM chip similar to the one shown on pg. 154 of the datasheet. I need to read from the SRAM interface within a Linux program.

Nicholas

I am booting from SPI Dataflash, so there is no NOR flash connected to CS0 of the EBI. Only the FPGA is connected to CS0 of the EBI. Both AT91bootstrap and U-Boot are stored on the SPI dataflash.

Perhaps for Linux the SRAM CS0 startup has to be done in the board setup code?

There appears to be an example of this setup in the /linux-3.0.4/arch/arm/mach-at91/board-cpuat91.c file.

Hi there

> Within a C program running on the Linux operating system,
> how would I directly access memory locations on the SRAM bus?
> The FPGA logic automatically decodes SRAM memory addresses passed on the EBI,
> but how would I read from SRAM within the C program?

I've worked on something similar, except it really was SRAM (that also had a backup-battery). I wrote a block device driver for the SRAM "device" so that it behaves like a RAMdisk. I could then install a journaled filesystem on top of it. The filesystem was responsible for taking care of dirty shutdowns and recovering from data corruption.

I used the SRAM as a device in order to protect access to it. You do not want to merge this memory region into the generic memory pool, where it would be difficult to reserve it for any special applications.

In the device's init routine, request_mem_region() obtains a virtual kernel address. Then ioremap() maps the physical SRAM address space to the obtained virtual address.

Since the kernel owns this virtual address space, user code has to make an "I/O request", which is just a memcpy() by the driver.


> Would I use a pointer, or would I use the mmap() function?

Once you have a device driver, then you could mmap() the device. Trying to access physical memory in user mode or to map physical memory into user space violates *nix kernel security principles.

Regards

Thank you for your response, blue_z; this is very much appreciated. I think that I understand what is required to be able to write a device driver for accessing the SRAM memory locations.

1) Do I have to modify my board setup code in some fashion to let Linux know about the presence of the SRAM chip?

2) Would the Linux device driver expose a char device interface to userland code?

3) Are there any similar examples showing how a device driver might be written for SRAM?

Thank you,

Nicholas

> 1) Do I have to modify my board setup code in some fashion
> to let Linux know about the presence of the SRAM chip?

Actually that is the purpose of the probe() routine in a device driver: to determine if the device is installed, and its device number and other attributes. It it is not a removable device (i.e. it's hardwired), then there's no need for probe(), and the device driver can be unconditionally installed. When the driver "installs" itself, it also "registers" itself with the appropriate device service(s).

BTW initialization for the SRAM in at91bootstap seems inappropriate. Each boot program normally only performs initialization & functionality to accomplish the task at hand. Do you really need to access this SRAM in order to load and execute the next stage, namely U-Boot? Can GPIO initialization for the FPGA/SRAM be deferred to U-Boot, where you have more code memory available?

If you haven't tested your FPGA hardware yet, the memory read & write commands in U-Boot can be useful. The MMU is not yet enabled, so you can use physical addresses.


> 2) Would the Linux device driver expose a char device interface to userland code?

Your device has to be accessed using the standard I/O and ioctl() interface. You would need to create a node for your device in the /dev directory. Major and minor numbers need to be assigned, which links the dev node to the device driver.


> 3) Are there any similar examples showing how a device driver might be written for SRAM?

I found this *really* simple char driver example :
http://linuxgazette.net/125/mishra.html
where the "device" is an 80-byte memory buffer. Of course a lot of detail is omitted. There are other things like modifying the appropriate Kconfig file and defining CONFIG symbols to enable or disable building the driver. The author incorrectly equates "module" with "device driver". A device driver does not have to be a (loadable) module; the driver can be linked in as part of the kernel binary.

You could/should examine drivers in the kernel source tree for working code. There's also /Documentation in the kernel source tree.

BTW you should learn the kernel coding style if you're going to write or mod kernel code or drivers.

Regards

Thanks, blue_z; the idea of using memory read-write commands in U-Boot is interesting.

I'll give your suggestions a try, and I will post back what I have done here in this thread.

Here is what I did to get reading from the FPGA up and running. I can confirm that this works very well, so thank you once again, blue_z, for all of your help!

As suggested by blue_z, it is probably beneficial to set up the EBI SRAM CS0 in U-Boot or another bootloader. However, I found it easier to do this setup in At91Bootstrap. I had to adjust some of the register settings to ensure that the FPGA could respond appropriately within the time that the chip select and read signals remain active low.

unsigned int setup0 = 0x02;
unsigned int pulse0 = (50 << 24) | (45 << 16);
unsigned int cycle0 = (60 << 16);

writel(setup0, AT91C_BASE_SMC + SMC_SETUP0);
writel(pulse0, AT91C_BASE_SMC + SMC_PULSE0);
writel(cycle0, AT91C_BASE_SMC + SMC_CYCLE0);

unsigned int regCTRL0 = ( AT91C_SMC_READMODE | AT91C_SMC_DBW_WIDTH_SIXTEEN_BITS
| AT91C_SMC_WRITEMODE
| AT91C_SMC_NWAITM_NWAIT_DISABLE
| ( 0x01 << 16 ) | AT91C_SMC_BAT_BYTE_WRITE | AT91C_SMC_TDFEN ); // had to add AT91C_SMC_BAT_BYTE_WRITE
writel( regCTRL0, AT91C_BASE_SMC + SMC_CTRL0); // had to add AT91C_SMC_TDFEN

I next modified the *really* simple char driver example suggested by blue_z in the following manner.

Within the r_init(void) function, I added the following code:

// obtain a virtual kernel address using request_mem_region function
if ( request_mem_region (START_EBI_CS0 , FPGA_SRAM_MEM_SIZE, DEVICE_NAME) == NULL)
{
printk( KERN_ALERT "Unable to request virtual kernel address");
return -EBUSY;
}

// use ioremap to re-map the selected memory
mmio = ioremap(START_EBI_CS0, FPGA_SRAM_MEM_SIZE);

Outside of this function, I have the following:

// buffer used to hold all of the data
static void *mmio;

#define START_EBI_CS0 0x10000000 // from pg. 19 of the datasheet
#define FPGA_SRAM_MEM_SIZE (0x400000 * 16) // 8MB of memory for 2^22 address bits
#define DEVICE_NAME "fpga_sram" // name of the device

Then within the my_read function, I have the following lines of code to copy the memory-mapped region to userspace.

if ( copy_to_user(buff,mmio,count) != 0 )
printk( "Kernel -> userspace copy failed!\n" );
return count;

Using a userspace program to read from the device node, I can happily say that this works quite well.

Congrats on getting this working.

Regards

Thanks for your help, blue_z; and for pointing me in the right direction.