linux(imx6ul)开机内核kernel播放动画（连续刷png图片或者jpg图片）

最新推荐文章于 2023-10-23 08:46:53 发布

青澜爸爸

最新推荐文章于 2023-10-23 08:46:53 发布

阅读量4.7k

点赞数 4

分类专栏： linux 文章标签：开机动画 imx6 linux kernel

本文链接：https://blog.csdn.net/spark550/article/details/87876573

版权

linux 专栏收录该内容

49 篇文章 3 订阅

订阅专栏

新鲜出炉，热乎的

前言：

我们当前的设备对界面亮起来的速度要求比较高，开机需要在3s内show出界面，在我们当前的配置下imx6ul+nandflash的情况下，难度比较大，我们之前做到的结果，通过裁剪内核减少读取内容，并且加快读取速度，基本上只能做到4s前后，那已经是裁减了比较多的东西了，连调试的信息都裁剪掉了。但是看了下友商的东西，起来2.5s就能出图像，略略操蛋。

这波不能忍啊：

大概评估了一下应该是这么做的。不然不可能这么快，因为是一样的核一样的nand。

就是干：

方案大概是有的，主要步骤如下：
上电>启动内核>优先加载动画驱动>开线程，线程中不断执行读和刷framebuffer的功能>刷完进应用层
套路就这个样子。接下去大概说下中间碰到的坑。

大坑:

这个是我自己的原因。我一开始选择并不是开线程，而是通过定时器去刷，每单位时间读取一次刷新一次。刷新没有问题，可以正常刷新。但是读取就不对了，查了好久，到最后的结果是因为定时器内，不能使用mtd的读取的函数，这是一个中断，不允许运行带schedule的操作，但是mtd读取的过程中，通过源码可以知道，需要发送命令，然后dma接收数据等等一系列带schedule的操作。所以一读取就报错，一读取就死机。后来直接改成线程就好了。可以读取了。
能读能刷了这下，但是我们的nand是128M的，文件系统已经占据了很多空间了。如果我们的图像使用bmp或者raw的存储格式的话，能存下的数据特别少。那肯定不能让文件系统的分区减下来吧。所以我们打算使用png解码出来再刷。png解码再linux user space倒是好弄的，再内核里面，要解码就比较麻烦了，很多库都没有。后来我们找到了这个lodepng，不需要其他库一个c一个h就能够解码，但是解码过程中需要调用realloc和一些系列函数，内核也没有，所以直接从网上找了一些realloc及其他函数的源码。
这下编译是能过了，但是remalloc出错了。如果直接在user space内编译并且使用lodepng的话，没有任何问题，但是在内核下，通过不断地跟踪发现，是realloc了一个新的空间，新的空间比老的空间size更小，查了下realloc的函数介绍，说是不允许这种骚操作的。那为毛在user space是可以通过的？！于是在ubuntu下面尝试了一下，发现直接remalloc一个小的空间，并没有出错误。而且应该是运行成功了（这一步存疑，并不知道到底有没有运行成功，但是没有报错，但是我并没有去验证空间的size有没有改变，所以不知道到底有没有成功），接下来我就此u十六日内核内自己找的realloc，允许malloc一个更小的空间。编译通过。运行单张图片通过。
动画就得刷起来，我们使用的是不断读png解码刷图像的做法，所以直接上多图片，发现每次运行到第三张图片的时候就会报错，按照这么来说要么是读取的未解压的数据不对，要么就是lodepng里面有一些变量没有重新赋值导致的，通过各种查查查，发现我们的源数据在读取的时候又一些位丢了，这个就很操蛋了。通过再一次各种查查查发现是在两个page交界处，会存在丢位，参考了一下内核中mtdchar.c里面的做法，每次读1page，不要跨page读，成功。
完成之后，已经能够完全播放所有的图片了，设置一下时间就是动画，但是试了一下效果还是不行，因为mtd的驱动加载的比较晚，基本上是要到最后才加载，这样的话整个开机动画就被这个拖累了。修改驱动的加载顺序是关键，查了一些资料，主要还是一个修改modules_init的做法为其他init的函数的方法，这个方法主要是将驱动的优先级提上来，早点加载。但是mtd是平台驱动，还modules_init比较麻烦，所以我没有使用。第二个是通过调整makefile的顺序来调整加载顺序。打开driver下的makefile，把mtd，lcd，backlight所属的文件夹的指令的语句提前。这样也可以修改驱动的加载顺序。把驱动加载提前。

最终：

最后得到的效果为手掐1.8-1.9s可以看到开机动画，但是开机动画比较卡，这个有几个原因，一个是处理器不是很给力，一个是图片我们用的是全屏的png，比较大，运算量也比较大，如果换成小的图片会好一点。

结束啦。

后续：

由于开机动画有一定的卡顿，所以我们又尝试了使用libjpeg-turbo进行解码，除了在解码部分不一样之外其他几乎没有差别。
解码方面：
解码速度比较
初步查看代码之后发现在turbo里面使用了simd的加速，在arm端即是neon,经过我们在用户空间上的测试发现通过neon可以带来非常大的性能提升。于是进行了代码的移植，代码一直过程中没有遇到什么较大的问题，但是发现一旦开启neon，显示就会出错，应该是对neon的操作不对造成的。但是发现在不使用neon的情况下，速度相较于png的解码，已经快了很多，所以还是选择了libjpeg，并且继续对neon的调试。