mx50 EIM_BCLK problems and WEIM_BASE_ADDR

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

mx50 EIM_BCLK problems and WEIM_BASE_ADDR

Jump to solution
1,490 Views
jayakumar2
Contributor V

Hi freescale friends,

I'm working with a i.mx508 board, very similar to the RD3 board. I've been trying to get an fpga interfaced on CS1 and hitting a set of problems. Here are the details:

a) WEIM_BASE_ADDR

In the 2.6.35.3 release, the code says:

arch/arm/plat-mxc/include/mach/mx5x.h:

#define WEIM_BASE_ADDR          (AIPS2_BASE_ADDR + 0x000DA000)

That seems incorrect to me because IMX50RM.pdf shows that WEIM is at:

Addresses: EIM_CS0GCR1 is 63FD_8000h base + 0h offset = 63FD_8000h

(page 1135)

but if I change the value of WEIM_BASE_ADDR in mx5x.h to be + 0xD8000, I then get an unhandled fault upon read access of that address/register.

XXXjaya reached setup_cs1:2399 weimbase physical=0x63fd8000

XXXjaya reached setup_cs1:2400 weimbase ioremap=0xa086e000

XXXjaya reached setup_cs1:2420

Unhandled fault: external abort on non-linefetch (0x008) at 0xa086e000


where the code was:

weim_base = ioremap(MX53_BASE_ADDR(WEIM_BASE_ADDR), SZ_4K);

        printk(KERN_INFO "XXXjaya reached %s:%d weimbase physical=0x%x\n", __func__, __LINE__, MX53_BASE_ADDR(WEIM_BASE_ADDR));

        printk(KERN_INFO "XXXjaya reached %s:%d weimbase ioremap=0x%p\n", __func__, __LINE__, weim_base);

    reg = readl(weim_base + 0x0);
    printk(KERN_INFO "XXXjaya %s:%d EIM base=0x%x\n", __func__, __LINE__, reg)

btw, I'm using the MX53_BASE_ADDR macro there because the mx5x.h header has its AIPS2_BASE_ADDR as + 0x2000_0000 of the actual value.


Anyone have any ideas why I'm getting a unhandled fault? Looking at mm.c, it looks like this range has a valid 1MB mapping setup.

b) If I leave WEIM_BASE alone, ie: to get 0x63FD_A000, then when I set the registers using:

ioremap(MX53_BASE_ADDR(WEIM_BASE_ADDR), SZ_4K);

    __raw_writel(0x0021008F, weim_base + 0x18);
    __raw_writel(0x00001000, weim_base + 0x1C);
    __raw_writel(0x0C300010, weim_base + 0x20);
    __raw_writel(0x00000008, weim_base + 0x24);
    __raw_writel(0x08600008, weim_base + 0x28);
    __raw_writel(0x00000000, weim_base + 0x2C);

The register writes succeed and I can read them back. When I test with this, I see EIM_CS1 assert, EIM_LBA and EIM_RW too when I do a userspace 32-bit read from 0xF400_0000 (via mmap of /dev/mem). But EIM_BCLK does not get driven. I've tried various settings for the EIM config registers, eg: BCM/SRW/SRD and not getting BCLK at all. My guess is that since WEIM_BASE is wrong in mx5x.h, I'm just getting the default behavior for WEIM which might be one where BCLK doesn't get asserted.

btw, I've enabled weim_clk and it shows up in /proc/cpu/clocks.


root@freescale ~$ cat /proc/cpu/clocks | grep -i eim

weim_clk1-0                         ______    2    66666666 (66MHz)
weim_clk-0                          PA____    1   133333333 (133MHz)


I'd appreciate any advice on what to look at or debug. If anyone could confirm that EIM_BCLK should assert for a 32-bit read/write, that would also be useful.


Thanks,

jaya

Labels (1)
Tags (2)
0 Kudos
1 Solution
733 Views
GraceH
Senior Contributor II

Have you configured EIM PIN Mux correctly? In mx50_rdp.c, you can see the EIM pins are configured as KEY and GPIO


MX50_PAD_EIM_DA0__KEY_COL4,
MX50_PAD_EIM_DA1__KEY_ROW4,
MX50_PAD_EIM_DA2__KEY_COL5,
MX50_PAD_EIM_DA3__KEY_ROW5,
MX50_PAD_EIM_DA4__KEY_COL6,
MX50_PAD_EIM_DA5__KEY_ROW6,
MX50_PAD_EIM_DA6__KEY_COL7,
MX50_PAD_EIM_DA7__KEY_ROW7,
/*EIM pads */
MX50_PAD_EIM_DA8__GPIO_1_8,
MX50_PAD_EIM_DA9__GPIO_1_9,
MX50_PAD_EIM_DA10__GPIO_1_10,
MX50_PAD_EIM_DA11__GPIO_1_11,
MX50_PAD_EIM_DA12__GPIO_1_12,
MX50_PAD_EIM_DA13__GPIO_1_13,
MX50_PAD_EIM_DA14__GPIO_1_14,
MX50_PAD_EIM_DA15__GPIO_1_15,
MX50_PAD_EIM_CS2__GPIO_1_16,
MX50_PAD_EIM_CS1__GPIO_1_17,
MX50_PAD_EIM_CS0__GPIO_1_18,
MX50_PAD_EIM_EB0__GPIO_1_19,
MX50_PAD_EIM_EB1__GPIO_1_20,
MX50_PAD_EIM_WAIT__GPIO_1_21,
MX50_PAD_EIM_BCLK__GPIO_1_22,
MX50_PAD_EIM_RDY__GPIO_1_23,
MX50_PAD_EIM_OE__GPIO_1_24,
MX50_PAD_EIM_RW__GPIO_1_25,
MX50_PAD_EIM_LBA__GPIO_1_26,


View solution in original post

0 Kudos
2 Replies
733 Views
jayakumar2
Contributor V

Just an update to this. We don't understand why or how, but performing a md.l f0000000 20 (ie: a CS0 range access) while in u-boot and then subsequently doing the same setup (no changes) causes the accesses to work (ie: system no longer hangs):

root@freescale ~$ /unit_tests/memtool -32 f0000000 20

Reading 0x20 count starting at address 0xF0000000

0xF0000000:  0001FFFF 00030002 00050004 EEABEEAA

0xF0000010:  00090008 EEAFEEAE 000D000C EEABEEAA

0xF0000020:  00110010 00130012 00150014 EEABEEAA

0xF0000030:  00190018 001B001A 001D001C EEABEEAA

Does anyone have a possible explanation for this? My guess is that doing the md.l access in u-boot has some side effect on the cache/TLB that makes this work? Relevant register settings below.

root@freescale ~$ /unit_tests/memtool -32 53fd4000 20

Reading 0x20 count starting at address 0x53FD4000

0x53FD4000: 000012FF 00000000 00000034 00000000

0x53FD4010: 00000000 0A080980 00010006 F321F133

0x53FD4020: 00000000 00410000 00400040 00400040

0x53FD4030: 00000000 00000000 02080000 00000000

0x53FD4040: 00000000 00000000 00000000 00000000

0x53FD4050: 00000000 03000021 00000000 FFFFFFFF

0x53FD4060: 000A00F0 00000000 150300C1 000003C0

0x53FD4070: 0C303400 00000000 00000C00 000D3000

root@freescale ~$ /unit_tests/memtool -32 63fda000 26

Reading 0x26 count starting at address 0x63FDA000

0x63FDA000: 00610089 00001002 1C022000 00000000

0x63FDA010: 1C092480 00000000 00010080 00001000

0x63FDA020: 00000000 00000000 00000000 00000000

0x63FDA030: 00010080 00001000 00000000 00000000

0x63FDA040: 00000000 00000000 00010080 00001000

0x63FDA050: 00000000 00000000 00000000 00000000

0x63FDA060: 00010080 00001000 00000000 00000000

0x63FDA070: 00000000 00000000 00010080 00001000

0x63FDA080: 00000000 00000000 00000000 00000000

0x63FDA090: 00000020 00000010

root@freescale ~$ /unit_tests/memtool -32 53fa8000 20

Reading 0x20 count starting at address 0x53FA8000

0x53FA8000: 00000000 00190005 00000000 00000000

0x53FA8010: 00000000 00000016 00000000 00000000

0x53FA8020: 00000001 00000001 00000001 00000001

0x53FA8030: 00000001 00000001 00000001 00000001

0x53FA8040: 00000010 00000010 00000010 00000010

0x53FA8050: 00000001 00000001 00000001 00000001

0x53FA8060: 00000001 00000001 00000001 00000000

0x53FA8070: 00000000 00000000 00000000 00000001

root@freescale ~$ /unit_tests/memtool -32 f0000000 20

Reading 0x20 count starting at address 0xF0000000

0xF0000000: EEBBEEBA 00030002 00050004 00070006

0xF0000010: EEBBEEBA 000B000A 000D000C 000F000E

0xF0000020: EEBBEEBA 00130012 00150014 00170016

0xF0000030: EEBBEEBA 001B001A 001D001C 001F001E

0xF0000040: EEBBEEBA 00230022 00250024 00270026

0xF0000050: EEBBEEBA 002B002A 002D002C 002F002E

0xF0000060: EEBBEEBA 00330032 00250024 00370036

0xF0000070: EEBBEEBA 003B003A 003D003C 003F003E

0 Kudos
734 Views
GraceH
Senior Contributor II

Have you configured EIM PIN Mux correctly? In mx50_rdp.c, you can see the EIM pins are configured as KEY and GPIO


MX50_PAD_EIM_DA0__KEY_COL4,
MX50_PAD_EIM_DA1__KEY_ROW4,
MX50_PAD_EIM_DA2__KEY_COL5,
MX50_PAD_EIM_DA3__KEY_ROW5,
MX50_PAD_EIM_DA4__KEY_COL6,
MX50_PAD_EIM_DA5__KEY_ROW6,
MX50_PAD_EIM_DA6__KEY_COL7,
MX50_PAD_EIM_DA7__KEY_ROW7,
/*EIM pads */
MX50_PAD_EIM_DA8__GPIO_1_8,
MX50_PAD_EIM_DA9__GPIO_1_9,
MX50_PAD_EIM_DA10__GPIO_1_10,
MX50_PAD_EIM_DA11__GPIO_1_11,
MX50_PAD_EIM_DA12__GPIO_1_12,
MX50_PAD_EIM_DA13__GPIO_1_13,
MX50_PAD_EIM_DA14__GPIO_1_14,
MX50_PAD_EIM_DA15__GPIO_1_15,
MX50_PAD_EIM_CS2__GPIO_1_16,
MX50_PAD_EIM_CS1__GPIO_1_17,
MX50_PAD_EIM_CS0__GPIO_1_18,
MX50_PAD_EIM_EB0__GPIO_1_19,
MX50_PAD_EIM_EB1__GPIO_1_20,
MX50_PAD_EIM_WAIT__GPIO_1_21,
MX50_PAD_EIM_BCLK__GPIO_1_22,
MX50_PAD_EIM_RDY__GPIO_1_23,
MX50_PAD_EIM_OE__GPIO_1_24,
MX50_PAD_EIM_RW__GPIO_1_25,
MX50_PAD_EIM_LBA__GPIO_1_26,


0 Kudos