AM3352 Freeze on writing to NOR

Evan Carson

Hi,

I recently updated from an older kernel to the linux-3.2.0-psp04.06.00.1 package. I've been seeing a problem where writing to a NOR flash will occasionally freeze up the system completely. We have a two bank NOR flash multiplexed address/data bus and we are using a JFFS2 partition spanning across both banks.

In the previous kernel we were using the GPMC config registers were initialized by u-boot and were not touched by the kernel, is this still the case in this release?

Is there any sysfs or procfs file that can dump the contents of these registers in linux? Is there anything that might be changing them behind the scenes?

What kind of configuration is needed in order to configure a NOR flash device in the newest kernel? It looks like in the EVM there is a call to initialize the gpmc as a platform device (omap_init_gpmc) for a NAND flash, is there a similar setup for NOR that I might be missing?

Any tips for how to debug this would be appreciated.

Thanks,

Evan Carson

over 11 years ago

0 Miroslav Kiradzhiyski XID over 11 years ago

TI__Mastermind 25235 points

Hi Evan,

Please read this post, where I have explained about the NOR drivers in the Linux kernel: http://e2e.ti.com/support/arm/sitara_arm/f/791/p/329121/1147017.aspx#1147017

Evan Carson said:
In the previous kernel we were using the GPMC config registers were initialized by u-boot and were not touched by the kernel, is this still the case in this release?

I believe the GPMC registers are still configured in the U-Boot.

Evan Carson said:
Is there any sysfs or procfs file that can dump the contents of these registers in linux? Is there anything that might be changing them behind the scenes?

I don't know about a /sys or /proc file system access to the registers, but you can write a simple C program to read from /dev/mem. Example snippet:

void read_mem(unsigned int reg_addr, unsigned int *reg_val, int access_width)
{
    int fd;
    void *mem_map, *mem_addr;
    fd = open("/dev/mem" , O_RDWR|O_SYNC);
    mem_map = mmap(0, MEM_SIZE, PROT_READ|PROT_WRITE, MAP_SHARED, fd, reg_addr & ~MEM_MASK);
    mem_addr = mem_map + (reg_addr & MEM_MASK);
    printf("0x%08X\n", *(uint32_t*)mem_addr);
    close(fd);
}

Best regards,
Miroslav

0 Evan Carson over 11 years ago in reply to Miroslav Kiradzhiyski XID

Prodigy 80 points

Hi Miroslav,

Thank you for this information. There were some changes within these files between the two kernels. Unfortunately, porting them forward didn't seem to change the behavior.

One thing I did try is dialing back the GPMC config registers in u-boot to more conservative timing values (previously we had tuned these to be as fast as possible without violating timing). This changed the behavior so that now instead of the system freezing up I see errors like these when writing to the partition:

[ 8329.305184] Node totlen on flash (0xffffffff) != totlen from node ref (0x0000065c)
[ 8329.715194] Node CRC ffffffff != calculated CRC f09e7845 for node at 03b2a6c8
[ 8338.162211] Node CRC ffffffff != calculated CRC f09e7845 for node at 03b2a6c8
[ 8345.671899] Node totlen on flash (0x40001044) != totlen from node ref (0x00001044)
[ 8345.700237] Node totlen on flash (0x00205054) != totlen from node ref (0x00001044)
[ 8345.716212] Node totlen on flash (0x234b536c) != totlen from node ref (0x00001044)

I suspect the problem is somehow timing related as the changes in u-boot made a big difference(errors instead of system freeze). We have been running these timing values on many other identical boards for a long time and have not seen any problems. On this particular board I can go back and forth from old to new kernels and the errors only appear with the new kernel.

Has anything else changed that might have altered the memory timing?

Aside from the GPMC_CONFIGx registers is there anything else in the chip that controls this interface? Core voltages? Clock setup?

Thanks,

Evan

Processors

Processors forum

AM3352 Freeze on writing to NOR