u-boot相关powerpc处理器

xuhui250

原帖由 readkernel 于 2009-12-7 17:54 发表
把flash的那个全局变量所在的地址块映射到程序需要访问的地址上(虚拟地址)，打开MMU

肯定不能这样解决。MMU功能映射到FLASH，这个数据还是不能修改的。
我看看u-boot如何链接，然后在给个答案。

u-boot有个链接脚本u-boot.lds在各board下面，另外和TEXT_BASE一起决定第一条指令定位到哪里。

大鬼不动

学习了

readkernel

感觉问题不是lz描述的那么复杂
把D-cache关掉或在全局变量定义的地方加个volatile试一试

bitliu1983

mmu只是做虚拟地址和实际物理地址的映射问题，这个是由于编译，链接阶段的地址和运行地址不一致造成的。
不过我们想做的是在boot后，再干这个事情，或者说，之前是实地址，或是BAT映射，起来后我从新初始化mmu，然后改为页地址映射。
我们试验了另一个方案，采用redboot+启动linux方式。
boot和系统不编译到一个bin文件中。从boot起来后，再拷贝os的bin到TEXT_BASE的地方。这样两个bin文件就不存在地址共享和重定位问题了，不过这需要试试。

[ 本帖最后由 bitliu1983 于 2009-12-11 09:34 编辑 ]

bitliu1983

原帖由 readkernel 于 2009-12-8 10:21 发表
感觉问题不是lz描述的那么复杂
把D-cache关掉或在全局变量定义的地方加个volatile试一试

不行，D-cache和这个应该没关系，我们关掉了指令cache和数据cache。连TLB和BAT都清理了。
volatile是对外设访问时，加的一个不优化选项。和全局变量地址重映射还没关系。

readkernel

从flash引导，在ram重定位后，在访问全局变量之前，把ram的物理地址映射到虚拟地址0xfe000000，当然你的bin文件有多大就映射多少页，然后打开mmu。估计所谓的arm引导后flash和ram地址自动转换也是通过mmu转了一下，因为总线上的ram和flash接法已经决定了片选的物理地址

如果你嫌这样太麻烦，可以在引导代码里自己做自定义全局变量symbol重定位，但这样更麻烦

[ 本帖最后由 readkernel 于 2009-12-11 10:56 编辑 ]

bitliu1983

原帖由 readkernel 于 2009-12-11 10:49 发表
从flash引导，在ram重定位后，在访问全局变量之前，把ram的物理地址映射到虚拟地址0xfe000000，当然你的bin文件有多大就映射多少页，然后打开mmu。估计所谓的arm引导后flash和ram地址自动转换也是通过mmu转了一 ...

在ram重定位后，在访问全局变量之前，把ram的物理地址映射到虚拟地址0xfe000000?
这个方法估计工作量很大，还有一点，我们系统会做mmu，配置相应的读写访问属性和权限。
但是我们物理地址和实际地址是一一对应的。就是地址空间是划分好了的，哪里是栈，哪里是text段，哪里是data段。到后面的外设空间。
如果映射到0xfe000000，那么后续系统就很难做了，带来其它问题。

bitliu1983

对，还有一个问题，因为起来后，flash地址是0xfe000000，那flash地址起始也得从新映射到其它地址空间。

readkernel

-mrelocatable

* On ppc32 we compile with -mrelocatable, which means that references
* to extern and static variables get relocated automatically.
* On ppc64 we have to relocate the references explicitly with
* RELOC.  (Note that strings count as static variables.)

去看看arch\powerpc\kernel\prom_init.c
获许会对你的实现有帮助

[ 本帖最后由 readkernel 于 2009-12-13 21:49 编辑 ]

xuhui250

不好意思，这么才回来。

如果关键就是你这个A函数在哪里被执行的呢？而后C语言又是在那个地方执行呢？

从你描述来看，都应该是在RAM中运行了，这样的话最好的调试方法就是将两个函数中globala的地址打印处理，
这样好分析你访问的地址究竟是否是同一个。