Tina方案开发一探

1.编译,打包

 2.烧录：

选择量产卡：

烧录成功：

 3.将卡插入平台，BROM卡启动程序将加载SD卡中的固件，至于最终是卡量产，开始卡启动，则取决于固件本身的定义。

使用phonix suit的烧录步骤：

插着USB线，按住左上角的UBOOT键，再按复位，之后松开复位，之后再松开UBOOT键，系统自动进入烧录模式。

---

4.关于内核调试：

默认情况下，内核打开了CONFIG_CC_OPTIMIZE_FOR_SIZE 和关闭了CONFIG_DEBUG_INFO，造成在DS5调试内核的时候，无法获取到足够的调试信息，表现之一便是无法看到完整的调用堆栈.

 将这两个选项进行正确配置后，重新编译内核即可：

 之后，便可以看到完整的堆栈信息了：

我们追踪一下卡驱动的处理流程：

 插上TF卡，内核probe到之后会读取分区信息生成设备节点，可以看到generic_make_request将make_request_fn打印出来，地址为0xc01d5260;

根据符号表，查找到此函数为：

继续顺藤摸瓜，根据blk_queue_bio的调用链条追踪到下面的函数，我们打印request_fn，看能否找到和sunxi sdmmc的联系:

测试如下：

根据符号表找到入口的地址为：

好了，终于看到和MMC的联系了!

具体位置在下图，它是Linux内核的框架层代码，挂接在mmc_blk_probe的调用路径当中，做法符合Linux一贯的套路，将卡驱动公共的部分抽取出来做成公共框架，而客制化部分的卡控制器则通过框架接口注册进系统，公共部分由框架处理，卡差异化部分则调用具体的驱动实现。

---

打开valgrind调试:

---

5:CDR启动脚本：

应用代码和启动配置在eyseempp目录下，配置脚本也在这里。

6:NNA配置使能

可见，受到CONFIG_SUNXI_NNA控制的源文件只有nna_sunxi.o.

运行后，会出现字符设备节点/dev/nna,主设备号246, 次设备号0,NNA应用一般依赖两个设备,nna和g2d，g2d存在的目的是为了将大图进行缩放，因为做NNA网络处理，一般用比较小的图就够了，不但快，而且节省资源，其它需要的节点还有/dev/ion, /dev/mem, /dev/cedar_dev等。

7:Tina带EMMC和不带EMMC的差异

常见的编译错误以及处理方式：

 出现这种错误一般是因为linux内核目录的user_headers/头文件目录被误删除导致的，这种误操作没有被构建系统察觉，所以也不会再次生成，导致所有依赖内核头文件的应用包都编译不过，这个时候，只要进入内核目录，执行

make ARCH=arm INSTALL_HDR_PATH=./user_headers headers_install

重新生成头文件目录即可.这种做法符合Linux一贯的做法，在Linux Kernel环境下的做法可参考下面博客:

ubuntu18.04内核编译升级_papaofdoudou的博客-CSDN博客

 至于这个关联是如何建立起来的，参看下图

在构建系统中，产生这个配置是在：

关于方案的编译选项配置

默认的编译选项来自于这里:

编译OpenCV:

OpenCV是一套开源的计算机视觉算法库，里面包含图像处理与计算机视觉的通用算法，Tina构建系统支持对OpenCV的配置和编译。

文件系统：

 /usr目录是一个独立的文件系统，类型为squashfs. 通过 crootfs可以切换到构建系统的rootfs目录下：

cout，可以看到usr.fex，file查看其类型，可以看到其是squashfs文件系统镜像文件。

包括rootfs文件系统也是一样

添加自启动：

cdevice进入：

重新编译，进入到crootfs,发现生效。

Tina按键输入输出的获取：

demo开发板上的常用按键事件如何获取呢？可以通过tina /dev/input/eventX设备节点：

用cat 命令尝试一下,用event0，试过event1不管用，可能是映射到其它设备，并非按键.

cat /dev/input/event1

可以看到，随着每次按键被按下，控制台有字符打印出来，打印乱码是由于控制台无法解析对应的二进制案件值的原因，无他原因.

几个和输入相关设备文件系统节点：

查看tina加载模块：

执行lsmod

查看显示图层信息：

cat /sys/class/disp/disp/attr/sys

初始化系统环境的一个绝佳地点：

比如挂载磁盘，导出环境变量等，都可以写在这里。

添加模块加载检查，没有的化编译出错。

添加环境变量的另外一个地方 /etc/profile

---

结束！