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
Solved! Go to Solution.
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, |
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
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, |