结贴：AM335x打开MMU和CACHE后，定时器的寄存器写出错

只看该作者 · 2012-11-5 16:14

本帖最后由 nicholasldf 于 2012-11-26 09:45 编辑

使用是TI提供的AM335X_StarterWare_02_00_00_07，裸机驱动库。

初始化MPU PLL为720M，
不打开MMU和CACHE，CPU速度运行的很慢，执行i=720000;while(i--);用了80多mS，速度很慢了。

打开MMU和CACHE之后，用了将近4mS，这个才是正常的值。

问题是打开MMU和CACHE之后，有的代码运行的有问题，比如定时器初始化，寄存器根本就没有写进去。

1万 · 2012-11-5 16:27

USB驱动，楼主网google一下，只要是TI的应该都可以用

只看该作者 · 2012-11-5 16:50

USB驱动不行啊，就是TI提供的驱动，安装出错，TI现在还没有答复。
JLINK调试也用不起来，连接后说是ICE-PICK找不到，TI代理拿了英蓓特的开发板回去测试，TI的XDS连接不上，但是XDS可以连接TI的原装开发板，于是他说确定是英蓓特板子的JTAG有问题。在英蓓特网站发帖子咨询他们JTAG是否用仿真器成功调试过，至今还未回帖。
现在程序不打开MMU和CACHE又慢，打开了又有问题。

我本想只打开ICACHE，关闭DCACHE，这样就不用考虑数据同步的问题，但还是一样的问题。

之前用9260，只打开ICACHE，也没用碰到这样的问题啊

郁闷ing

只看该作者 · 2012-11-5 21:46

打开cache，驱动出现问题的话，首先需要考虑的是一致性问题，所有涉及DMA的区域一律不建议用cache，只有当你对cache，DMA以及你的系统完全理解之后，能够做到在每次DMA前后自己手动刷新cache才可以使用。其次需要注意的是硬件寄存器区域不应该cache，否则可能导致你向硬件寄存器发出的指令没有真正传达下去，也有可能传达下去但是顺序不对。
只打开icache不出问题这并不奇怪，因为代码区多数情况下是只读区域（除非你做了动态修改的机制），打开icache只会优化读速度而不会遭遇到写所碰到的各种问题，dcache才是出问题最多的地方。

只看该作者 · 2012-11-5 22:12

本帖最后由 nicholasldf 于 2012-11-5 22:14 编辑

4# xinzha

谢谢回复
我觉得只打开ICACHE，关闭DCACHE，虽然速度比同时打开ICACHE和DCACHE慢了点，但是不用担心程序运行有什么问题，程序是只读区域，根据程序执行的暂时局部性原理，速度会有较大的提升。
但是AM335X这样试了，还是一样的问题:(，不知何解？

片上外设寄存器地址空间是非CACHE，而且不可Execute的。
芯片外设寄存器MMU设置
/*
** Define Device Memory Region. The region between OCMC and DDR is
** configured as device memory, with R/W access in user/privileged modes.
** Also, the region is marked 'Execute Never'.
*/
REGION regionDev = {
                     MMU_PGTYPE_SECTION, START_ADDR_DEV, NUM_SECTIONS_DEV,
                     MMU_MEMTYPE_DEVICE_SHAREABLE,
                     MMU_REGION_NON_SECURE,
                     MMU_AP_PRV_RW_USR_RW  | MMU_SECTION_EXEC_NEVER,
                     (unsigned int*)pageTable
                     };
DDR3区域才是打开CACHE的，可执行的
/*
** Define DDR memory region of AM335x. DDR can be configured as Normal
** memory with R/W access in user/privileged modes. The cache attributes
** specified here are,
** Inner - Write through, No Write Allocate
** Outer - Write Back, Write Allocate
*/
REGION regionDdr = {
                     MMU_PGTYPE_SECTION, START_ADDR_DDR, NUM_SECTIONS_DDR,
                     MMU_MEMTYPE_NORMAL_NON_SHAREABLE(MMU_CACHE_WT_NOWA,
                                                      MMU_CACHE_WB_WA),
                     MMU_REGION_NON_SECURE, MMU_AP_PRV_RW_USR_RW,
                     (unsigned int*)pageTable
                     };

只看该作者 · 2012-11-5 22:16

2# 阿南
驱动安装不了的问题：
驱动下载地址http://beagleboard.org/static/beaglebone/latest/README.htm?1352124987
USB驱动问题，两个都安装不了，PC操作系统是windows XP professional 2002
安装BONE_DRV.exe时，弹出设备驱动程序安装向导对话框：“设备驱动程序安装向导不支持当前的语言，请与向你提供此软件包的供应商联系。”
安装BONE_D64.exe时，弹出BeagleBoard Drivers Archive:error对话框：“Error during execution ""dpinst.exe"". %1不是有效的Win32应用程序”。

1万 · 2012-11-6 09:50

下载试装了下，那个确实出现了语言问题。

1万 · 2012-11-6 11:39

俺用原装板子.用openocd调试.没什么问题...没必要用jlink

变量volatile试试呢.写进去再读...
建议跑Linux.别裸奔了...没意义

只看该作者 · 2012-11-6 11:52

本帖最后由 nicholasldf 于 2012-11-6 11:58 编辑

8# icecut
thanks

原来就是裸奔的，现在升级CPU罢了，有的产品也未必适合用linux吧:)。。
至于linux，另一款是基于AM335X+linux的。。

一路跟踪进去，有volatile的
DMTimerPreScalerClkEnable(SOC_DMTIMER_2_REGS, DMTIMER_PRESCALER_CLK_DIV_BY_16);

----->

HWREG(baseAdd + DMTIMER_TCLR) |= (ptv & (DMTIMER_TCLR_PTV | DMTIMER_TCLR_PRE));

----->

#define HWREG(x) (*((volatile unsigned int *)(x)))
监控变量加上volatile也是一样的结果
volatile unsigned int num1,num2,cnt;

只看该作者 · 2012-11-7 12:01

本帖最后由 nicholasldf 于 2012-11-7 12:05 编辑

等待TI支持反馈真是非常的缓慢，在英蓓特开发板和TI EVM原装开发板都测试了，都存在这个问题，不过现象不一样。
在英蓓特开发板：写到定时器TCLR寄存器的是47，读回来的是1，时钟分频位bit2-bit5和重载位bit1写不进去
在 TI EVM原装开发板：写到定时器TCLR寄存器的是47，读回来的是45，重载位bit1写不进去
关闭MMU和CACHE之后，两块开发板读取回来的都是正确值47。

还是得自己查看ARM内核资料。

为什么要使能MMU和CACHE，一是提升速度，不然速度非常慢，二是使能非对齐访问。

ARMv7已经支持非对齐地址访问，但有些条件：
·
CP15 的系统控制寄存器(SCTLR), bit.A = 0, (bit.U = 1, 对于ARMv7已经默认置1了，不可改).
·
访问的地址空间必须为Normal memory, 访问Device memory或Strongly memory都会引发alignment fault的Data Abort。而如果MMU disable的话，所有的memory都被当作Strongly memory处理（这句话没找到出处，来自ARM support回复的mail)。所以MMU必须enable，memory类型由页表项的C, B, TEX[2:0]决定,这部分可以查阅 <ARM Architecture Reference Manual ARMv7-A and ARMv7-R edition>的:B3.7 Memory region attributes.

如果目标处理器选择了ARMv6、ARMv7-A(如Cortex-A8)、ARMv7-R，编译器的缺省选项是--unaligned_access, 而如果选择了ARMv6以前的版本，或ARMv7-M体系的处理器，缺省选项是--no_unaligned_access。
对于选项--no_unaligned_access，编译器会自动将C语言对非对齐地址的变量的访问，转化成若干个字节操作。

如果你的目标平台是ARMv6或ARMv7-AR，但是在你的代码中，MMU是disable的，那你应该手动添加编译选项--no_unaligned_access，让编译器来帮你处理非对齐访问。

ARM内核默认存储器类型是Strongly ordered的，在IAR，我们没有指定--no_unaligned_access，所以前阵子调试USB转串口以及CANOPEN时，老出现data abort异常。所以要么指定--no_unaligned_access让IAR生产非对齐访问的额外代码，要么配置ARM内核使能非对齐访问。最后当然是选择配置ARM内核硬件的方式，原因是效率高，不会像--no_unaligned_access那样生成额外的代码来存取非对齐地址上的数据。所以就要使能MMU，把DDR的存储器类型设置为Normal类型。

TI原来的MMU初始化代码，设置DDR3和芯片内置SRAM为Normal类型，设置片上寄存器区域为Device类型。

但是，看了arm的Cortex-A8手册Cortex_a8_r3p2.pdf的246页，ARM V7A定义了三种存储器类型：Strongly ordered、Device、Normal，其中Strongly ordered 类型是noncacheable, nonbufferable, and serialized，等待总线的应答回来后，才执行下一条指令（This type of memory flushes all buffers and waits for acknowledge from the bus before executing the next instruction）。而Device类型是noncacheable，device stores can be buffered，也就是有个buffer在里面。

在使能MMU和CACHE之前，所有存储器类型都是Strongly ordered类型的，我们的问题也没有出现。
使能MMU和CACHE之前，DDR和片内SRAM存储器类型都是Normal类型，片上寄存器区域为Device类型，问题就出现了。
之前一直考虑DDR的配置，因为整个程序、堆、栈都在DDR里面，怎么改都一样。

片上寄存器区域为Device类型，应该没什么问题，但是考虑到有个buffer，试着改回到Strongly ordered类型，结果问题没有了，可以准确的写定时器寄存器了。

不知道是否这个原因，ARM定义了Device类型，应该就是指片上外设区域的，不能cache，不支持非对齐访问。需要进一步看arm_architecture_reference_manual V7-AR.pdf，先初步这样跑着吧。