This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

dm365 HPI, AEMIF, & EM_CE1

Hello, I am trying to connect 2 dm365's via HPI using the EMIF expansion connectors on 2 EVMs. I am first trying to simply verify that the 2nd chip enable on the dm365 acting as host (CE1, CS3) is truly mapped to the ASYNC EMIF data address at 0x04000000.

These are the steps I've taken to set this up and see if it works. Then below, I have a few questions.

1. PINMUX2:0x0000005a - verified pin is EM_CE1 (not GIO55), plus other EMIF pins are correct

2. AEMIF registers
    A2CR:0x00000001 - 16 bit data bus, other settings per aysnc. SRAM example in sprufi1a.pdf (Table 22)
    NANDFCR:0x00000001 - CS3 is not enabled for NAND

3. Reserved memory and ioremap'd ASYNC EMIF Data (CE1) address (0x04000000) using the standard (platform_get_resource/request_mem_region/ioremap_nocache function calls. This appears to have worked:

root@192.168.1.105:~# cat /proc/iomem
01c20000-01c2001f : serial
01c21000-01c21040 : i2c_davinci.1
  01c21000-01c21040 : i2c_davinci
01c21c00-01c21fff : watchdog
  01c21c00-01c21fff : watchdog
01c64000-01c645ff : musb_hdrc
01c66000-01c667ff : dm_spi.0
  01c66000-01c667ff : dm_spi
01c69000-01c693ff : rtc_davinci_dm365.0
01c69400-01c697ff : dm365_keypad
01d02000-01d03fff : soc-audio
  01d02000-01d03fff : soc-audio
01d06000-01d0601f : serial
01d07000-01d07fff : ctrl_regs
01d08000-01d09fff : wrapper_ram
01d0a000-01d0afff : wrapper_ctrl_regs
01d0b000-01d0b7ff : mdio_regs
01d10000-01d10fff : nand_davinci.0
  01d10060-01d10fff : nand_davinci
01d11000-01d113ff : davinci-mmc.0
02000000-02003fff : nand_davinci.0
  02000000-02003fff : nand_davinci
02004000-02007fff : nand_davinci.0
  02004000-02007fff : nand_davinci
04000000-04003fff : hpi_davinci.0
80000000-84bfffff : System RAM
  80039000-8039d667 : Kernel text
  8039e000-8044ade3 : Kernel data

I added a debug printout to see the resulting virtual address (0xc5008000) that "should" result in CE1 going low (pin32 on J14 header on EVM):
hpi_host_probe - res->start:0x04000000 res_size(res):16384 info->ce:1 info->hpi_res->start:0x04000000 info->hpi_io:0xc5008000

4. However, when I probe this pin while reading or writing to 0xc5008000, I never see it go low.

root@192.168.1.105:~# cat /sys/class/hpi/host/test
test_show - returning count:16 buf:This is a test!
test_show - reading info->hpi_io:0xc5008000 ==> 0x1234
This is a test!
root@192.168.1.105:~# cat /sys/class/hpi/host/test
test_show - returning count:16 buf:This is a test!
test_show - reading info->hpi_io:0xc5008000 ==> 0x1234
This is a test!
root@192.168.1.105:~# echo 0xface > /sys/class/hpi/host/test
test_store - count:7 buf:0xface
root@192.168.1.105:~# cat /sys/class/hpi/host/test
test_show - returning count:16 buf:This is a test!
test_show - reading info->hpi_io:0xc5008000 ==> 0xface
This is a test!
root@192.168.1.105:~# cat /sys/class/hpi/host/test
test_show - returning count:16 buf:This is a test!
test_show - reading info->hpi_io:0xc5008000 ==> 0xface
This is a test!

5. FYI...I tried a similar experiment probing the CE0 pin to see if it goes low during NAND flash accesses, and it does.

So, here are my questions:
1. Does the above procedure look correct?
2. Are there any other related registers that I need to configure?
3. Has anyone ever used the dm365 as an HPI host or slave (or both like I am trying)?

Thanks for any anwsers or other info you may have on the topic. Please let me know if you have any questions.

Regards,
-Craig

  • Update: From u-boot, I am able to read/write to 0x04000000 and observe the EM_CE1 (and other realted EM_Ax pins) toggle on the connector, so at least I know the chip works ;)

    So, I guess my problem is the code in Linux. I used the nand-davinci.c code as an example. As I showed above, I see the entry in /proc/iomem and I am using the virtual address returned, but something is not working in the kernel to generate the 0x04000000 based address on the bus. I thought something in the nand setup is undoing what I setup in my hpi driver (the hpi driver loads first), but I rebuilt the kernel without it and it still doesn't work. 

  • Problem solved!

    Bug in the setup function that was dropping down and undoing all the mapping (error handling for failures)...just needed to add a return before the cleanup.