STM32MP157A-DK1测评 (6) Cortex-A7 Linux下的程序环境

cruelfox 发表于 2020-4-26 21:55

<div class='showpostmsg'>　　官方提供的 STM32MP1_Yocto_SDK_V1.2.0.xz 开发包提供了 STM32MP157 Linux应用程序开发需要的工具。解开以后里面的安装文件是一个巨大的 .sh 脚本文件（数据包含在内），需要在 x86_64 Linux 环境下运行。安装之后主要会得到两个目录树（均位于sysroots子目录下）：

　　cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi

　　x86_64-ostl_sdk-linux

　　第一个是似乎完整的 ARM Linux 系统目录，里面的程序是给 STM32MP157 运行的。可以把这些目录复制到 SD 卡的一个分区上去实验，这上面有很多开发用的文件，还有调试用的文件。第二个是运行于 x86_64 Linux 下的开发工具，包含了开发 STM32MP157 Linux 程序需要的交叉编译工具，还有QEMU模拟器、OpenOCD、x86_64编译工具、Python等。 
　　值得说一下的是，x86_64-ostl_sdk-linux 里面的程序对运行它的 Linux 环境依赖度很小。我当初自己编译 32位 OpenOCD 来用是因为要装(编译)一套 x86_64 环境才能运行这里面的 OpenOCD；而后来等我编译了一个 x86_64 内核之后，发现ST的包是自带所有运行库的，安装过程中（用了一个Python程序）把 dynamic linker 的路径写死到每个执行文件里面了，就不依赖原有系统上的库了，只要 x86_64 内核版本够就行。

 

　　要编译一个最简单的能在开发板 Linux 下运行的 C 程序需要用到以上这两个目录的内容。虽然第一个里面的程序都不是给 PC 运行的，但编译程序时需要的头文件和库文件在这里；第二个有 PC 上运行的编译工具但缺少了目标系统的C运行库。

　　先做一个测试程序出来：

<div aria-label="代码段小部件" contenteditable="false" role="region" tabindex="-1">
<pre data-widget="codesnippet">
<code class="hljs language-cpp">int main()
{
printf("From Linux (Cortex-A7) 0x%X\n",main);
}</code></pre>
<img src="data:image/gif;base64,R0lGODlhAQABAPABAP///wAAACH5BAEKAAAALAAAAAABAAEAAAICRAEAOw==" /><span style="background-color: rgba(220, 220, 220, 0.498039); background-image: url(https://bbs.eeworld.com.cn/static/editor/plugins/widget/images/handle.png); top: -15px; left: 0px; display: block; background-position: initial initial; background-repeat: initial initial;"><img height="15" role="presentation" src="data:image/gif;base64,R0lGODlhAQABAPABAP///wAAACH5BAEKAAAALAAAAAABAAEAAAICRAEAOw==" title="点击并拖拽以移动" width="15" /></div>

　　我把 #include<stdio.h> 给省去了，为的是编译C源文件时不使用头文件，GCC会警告但这儿没关系。在 PC Linux 下执行编译命令：

　　$ arm-ostl-linux-gcc -c -O -mcpu=cortex-a7 test.c

然后就生成了一个 test.o 目标文件。不妨查看一下反汇编代码：

$ arm-ostl-linux-objdump -d test.o

test.o:     file format elf32-littlearm

Disassembly of section .text:

00000000 <main>: 
   0:   e92d4010        push    {r4, lr} 
   4:   e3001000        movw    r1, #0 
   8:   e3401000        movt    r1, #0 
   c:   e3000000        movw    r0, #0 
  10:   e3400000        movt    r0, #0 
  14:   ebfffffe        bl      0 <printf> 
  18:   e3a00000        mov     r0, #0 
  1c:   e8bd8010        pop     {r4, pc} 
　　这是使用的 ARM 模式的指令，调用了一个入口地址未定的子程序 (printf)

 

　　然后要生成开发板的 Linux 下运行的可执行文件，需要 (1) 和运行库链接，得以使用 printf 函数的实现。(2) 链接上启动代码，由启动代码初始化环境，调用 main 函数。现在没有直接用 GCC 命令生成可执行文件，是因为需要的C库文件不在默认路径下（交叉工具目录不包含）。一试的话就会发现报错：crt1.o  crti.o crtbegin.o crtend.o crtn.o 目标文件找不到，-lc, -lgcc 等要链接的库文件找不到。

　　试图手工解决一下，将文件路径用参数提供给 GCC，连接刚才编译过的目标文件:

$ arm-ostl-linux-gcc test.o -B /opt/stm32mp1/sysroots/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/usr/lib -L /opt/stm32mp1/sysroots/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/usr/lib -L /opt/stm32mp1/sysroots/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/lib 
/opt/stm32mp1/sysroots/x86_64-ostl_sdk-linux/usr/libexec/arm-ostl-linux-gnueabi/gcc/arm-ostl-linux-gnueabi/8.2.0/real-ld: skipping incompatible /lib/libc.so.6 when searching for /lib/libc.so.6 
/opt/stm32mp1/sysroots/x86_64-ostl_sdk-linux/usr/libexec/arm-ostl-linux-gnueabi/gcc/arm-ostl-linux-gnueabi/8.2.0/real-ld: cannot find /lib/libc.so.6 
/opt/stm32mp1/sysroots/x86_64-ostl_sdk-linux/usr/libexec/arm-ostl-linux-gnueabi/gcc/arm-ostl-linux-gnueabi/8.2.0/real-ld: cannot find /usr/lib/libc_nonshared.a 
/opt/stm32mp1/sysroots/x86_64-ostl_sdk-linux/usr/libexec/arm-ostl-linux-gnueabi/gcc/arm-ostl-linux-gnueabi/8.2.0/real-ld: cannot find /lib/ld-linux-armhf.so.3 
collect2: error: ld returned 1 exit status 
　　尽管依赖的文件路径已经找到了，但在 libc.so 的处理上出了问题。因为 LD 链接 libc.so 的时候(这是一个文本文件)被告诉使用 /lib/libc.so.6 和 /usr/lib/libc_nonshared.a 文件，这是我本机x86 Linux系统目录里的文件，当然不正确。解决办法之一是编辑那个 libc.so 文件(或者编辑后另存一个在别的地方)，把SDK的路径写进去。而 ld-linux-armhf.so.3 这个文件，因为和本机系统没有冲突，就复制一个到 /lib 下好了。

　　经过这番调整以后，库文件路径问题解决了，但又出现新的错误：

/opt/stm32mp1/sysroots/x86_64-ostl_sdk-linux/usr/libexec/arm-ostl-linux-gnueabi/gcc/arm-ostl-linux-gnueabi/8.2.0/real-ld: error: a.out uses VFP register arguments, test.o does not 
/opt/stm32mp1/sysroots/x86_64-ostl_sdk-linux/usr/libexec/arm-ostl-linux-gnueabi/gcc/arm-ostl-linux-gnueabi/8.2.0/real-ld: failed to merge target specific data of file test.o 
collect2: error: ld returned 1 exit status

　　这是链接程序报说 test.o 与要生成的可执行文件在参数传递上不匹配，即 ABI 不兼容。在 MCU 开发中也可能发生这样的问题。我在编译 test.c 的时候没有指定用 VFP（浮点处理器），于是重新编译一下，加上 -mfloat-abi=hard 选项。

　　然后就编译成功了。把可执行文件用网络传到开发板上试运行：

root@stm32mp1:/tmp# ./test 
From Linux (Cortex-A7) 0x103D8

　　程序运行成功。main() 函数的入口地址是 0x103D8

　　还有一种生成可执行文件的办法是在开发板上运行链接程序 arm-ostl-linux-gnueabi-ld (包含在SDK的 cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi 目录里面)，利用 PC 上交叉编译得到（因为 SDK 没有提供 cortex-a 上运行的 GCC, 只提供了 binutils 软件）的目标文件 test.o. 事先需要把用得着的文件传到开发板Linux文件系统中。

root@stm32mp1:/tmp# arm-ostl-linux-gnueabi-ld test.o crt1.o crti.o crtn.o /lib/libc.so.6 --as-needed /usr/lib/libc_nonshared.a -I /lib/ld-linux-armhf.so.3 -o test

 

　　注意，回顾 STM32MP157A 的内存地址排布，SDRAM 的地址空间在 0xC0000000 以上，而 0x103D8 这本来是 ROM 空间的地址。很明显，这里 0x103D8 不是实际的物理地址，而是虚拟内存地址——Cortex-A7具有MMU (内存管理单元)，实现了地址转换。

　　为了方便测试 Linux 程序看到的内存空间是什么样的，把程序改写一下：

<div aria-label="代码段小部件" contenteditable="false" role="region" tabindex="-1">
<pre data-widget="codesnippet">
<code class="hljs language-cpp">#include<stdio.h>
#include<stdlib.h>
int main(int argc, char *argv[])
{
unsigned int addr, *ptr;
char *ep;
int i;
if(argc<2)
{
printf("Address?\n");
return 1;
}
addr=strtoul(argv[1],&ep,16);
if(ep==argv[1])
{
printf("Bad number.\n");
return 2;
}
ptr=(unsigned int *)(addr & 0xFFFFFFFC);
printf("MEM 0x%08X read:", ptr);
for(i=0;i<4;i++)
{
printf(" %08X", *ptr);
ptr++;
}
printf("\n");
}</code></pre>
<img src="data:image/gif;base64,R0lGODlhAQABAPABAP///wAAACH5BAEKAAAALAAAAAABAAEAAAICRAEAOw==" /><span style="background-color: rgba(220, 220, 220, 0.498039); background-image: url(https://bbs.eeworld.com.cn/static/editor/plugins/widget/images/handle.png); top: -15px; left: 0px; display: block; background-position: initial initial; background-repeat: initial initial;"><img height="15" role="presentation" src="data:image/gif;base64,R0lGODlhAQABAPABAP///wAAACH5BAEKAAAALAAAAAABAAEAAAICRAEAOw==" title="点击并拖拽以移动" width="15" /></div>

　　编译之：

$ arm-ostl-linux-gcc rmem.c -I/opt/stm32mp1/sysroots/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/usr/include -B /opt/stm32mp1/sysroots/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/usr/lib/ -L. -L/opt/stm32mp1/sysroots/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/usr/lib -L/opt/stm32mp1/sysroots/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/lib -mfloat-abi=hard -mcpu=cortex-a7 -O -o rmem

测试：

root@stm32mp1:/tmp# ./rmem 103d8 
MEM 0x000103D8 read: 00010511 E59F3014 E59F2014 E08F3003 
root@stm32mp1:/tmp# ./rmem 10000 
MEM 0x00010000 read: 464C457F 00010101 00000000 00000000 
root@stm32mp1:/tmp# ./rmem 0 
Segmentation fault (core dumped) 
root@stm32mp1:/tmp# ./rmem 8000 
Segmentation fault (core dumped) 
root@stm32mp1:/tmp# ./rmem 2ffc8000 
Segmentation fault (core dumped) 
root@stm32mp1:/tmp# ./rmem c0001000 
Segmentation fault (core dumped) 
root@stm32mp1:/tmp# ./rmem 40000000 
Segmentation fault (core dumped) 
root@stm32mp1:/tmp# ./rmem 50000000 
Segmentation fault (core dumped) 
root@stm32mp1:/tmp# ./rmem e0000000 
Segmentation fault (core dumped) 
　　结果是——除了程序自己用到的一小段地址空间可读外，整个32-bit地址空间几乎是禁止直接访问的。系统将自己保护起来了，这和在评测的(3) (4)篇中，没有使用操作系统环境运行程序的效果不一样。保护起来可以防止恶意的程序、有bug的程序破坏系统，对硬件访问加也了一层控制（比如现在不能直接访问GPIO的寄存器喽)。

 

　　在 Linux 下运行的程序，要访问硬件设备，正规方式是通过内核中的硬件驱动程序作桥梁。对习惯 MCU 开发方式的人来说可能这样有些绕，但从安全性、可移植性角度优势就大多了。和硬件设备寄存器、IRQ、DMA等打交道的事情，就交给内核程序开发者。

　　比如操作 GPIO，可以从系统设备 /dev/gpioxxxx 下手；操作串口可以从 /dev/ttyxxxx 下手。有的硬件可以用脚本程序操作，不需要编写C代码。

 

　　那么有没有非正规的办法，直接在程序中访问硬件设备的寄存器呢？我网上搜了一下，一种可能的办法是用 /dev/mem 设备访问物理地址空间。仿照个写个读物理地址内容的程序：

<pre>
<code class="language-cpp">#include<stdio.h>
#include<stdlib.h>
#include<unistd.h>
#include<sys/mman.h>
#include<fcntl.h>
int main(int argc, char *argv[])
{
unsigned int addr, base, *ptr, *vb;
char *ep;
int i, fd, offset;
if(argc<2)
{
 printf("Address?\n");
 return 1;
}
addr=strtoul(argv,&ep,16);
if(ep==argv)
{
 printf("Bad number.\n");
 return 2;
}
base=addr &0xFFFFFC00;
offset=(addr-base)&0xFF0;
fd=open("/dev/mem",O_RDWR|O_SYNC);
if(!fd)
{
 printf("Failed to access /dev/mem\n");
 return 3;
}
vb=mmap(0,1024,PROT_READ|PROT_WRITE,MAP_SHARED,fd,base);
ptr=(unsigned int)vb+offset;
printf("MEM 0x%08X (alias 0x%08X) read:", base+offset,ptr);
fflush(stdout);
for(i=0;i<4;i++)
{
 printf(" %08X", *ptr);
 ptr++;
}
close(fd);
munmap(vb,1024);
printf("\n");
}</code></pre>

　　编译运行测试：

root@stm32mp1:/tmp# ./rphy 0x2ffc1000 
MEM 0x2FFC1000 (alias 0xB6F8E000) read: 668148DF 0450BAC1 477FF993 4E5E4A05 
root@stm32mp1:/tmp# ./rphy 0x10000000 
MEM 0x10000000 (alias 0xB6FE8000) read: 6C591EEC 791E5FFE 504168EF 28AA1917 
root@stm32mp1:/tmp# ./rphy 0x0 
MEM 0x00000000 (a[  147.492075] Unhandled fault: external abort on non-linefetch (0x008) at 0xb6efc000 
[  147.499632] pgd = c216a94f 
[  147.502326] *pgd=cf77b835, *pte=00000783, *ppte=00000e33 
lias 0xB6EFC000) read:Bus error (core dumped) 
root@stm32mp1:/tmp# ./rphy 44004000 
MEM 0x44004000 (alias 0xB6F69000) read: 00000000 00000000 00000000 00000000 
root@stm32mp1:/tmp# ./rphy 40010000 
MEM 0x40010000 (alias 0xB6F1A000) read: 2400000D 00800000 54800000 0000022C 
root@stm32mp1:/tmp# ./rphy 50002000 
MEM 0x50002000 (alias 0xB6F81000) read: 00000000 00000000 00000000 00000000 
root@stm32mp1:/tmp# ./rphy 5800D000 
MEM 0x5800D000 (alias 0xB6F1F000) read: 01000010 00001212 0002A026 00000000 
root@stm32mp1:/tmp# ./rphy 5a003000 
MEM 0x5A003000 (a[  298.718977] Unhandled fault: external abort on non-linefetch (0x1008) at 0xb6ff8008 
[  298.726616] pgd = c77eb1e7 
[  298.729312] *pgd=cf722835, *pte=5a003783, *ppte=5a003e33 
lias 0xB6FF8000) read:Bus error (core dumped) 
　　也不是所有物理地址都可以访问。有的访问会出错，结果就是程序崩溃。GPIOA的寄存器 (在0x50002000处) 读不到真实值。UART4 的寄存器好象能被访问。

　　那么用这个办法，向 UART4 的 TDR 寄存器写数据会怎样？(UART4->TDR 地址是 0x40010028)　现在需要对重定位的虚拟地址进行写操作——mmap() 返回的地址加上偏移量。实验结果是在串口终端里面看到了字符！

　　这意味着 Linux 下运行的程序，只要有办法（绕过MMU的保护）访问片上设备寄存器的物理地址，就仍然可以用直接寄存器访问去操控硬件——虽然一般没有必要这么做。

 
此内容由EEWORLD论坛网友cruelfox原创，如需转载或用于商业用途需征得作者同意并注明出处
</div><script> var loginstr = '<div class="locked">查看本帖全部内容，请<a href="javascript:;" style="color:#e60000" class="loginf">登录</a>或者<a href="https://bbs.eeworld.com.cn/member.php?mod=register_eeworld.php&action=wechat" style="color:#e60000" target="_blank">注册</a></div>';

if(parseInt(discuz_uid)==0){
(function($){
var postHeight = getTextHeight(400);
$(".showpostmsg").html($(".showpostmsg").html());
$(".showpostmsg").after(loginstr);
$(".showpostmsg").css({height:postHeight,overflow:"hidden"});
})(jQuery);
} </script><script type="text/javascript">(function(d,c){var a=d.createElement("script"),m=d.getElementsByTagName("script"),eewurl="//counter.eeworld.com.cn/pv/count/";a.src=eewurl+c;m.parentNode.insertBefore(a,m)})(document,523)</script>

okhxyyo 发表于 2020-4-27 14:37

精彩！这个测评活动即将结束了哦~将会在4月29日结束。如果还有内容未完成，记得赶紧写哦

hotsauce1861 发表于 2020-4-28 13:06

认真看完，　　

这意味着 Linux 下运行的程序，只要有办法（绕过MMU的保护）访问片上设备寄存器的物理地址，就仍然可以用直接寄存器访问去操控硬件——虽然一般没有必要这么做。

 

这个想法很厉害<img height="50" src="https://bbs.eeworld.com.cn/static/editor/plugins/hkemoji/sticker/onion/Onion--101.gif" width="50" />

页: [1]

电子工程世界-论坛's Archiver

STM32MP157A-DK1测评 (6) Cortex-A7 Linux下的程序环境