monitor.c:19:10: fatal error: 'SDL2/SDL.h' file not found
程序没有自带SDL的库,simulator在macOS下跑不起来。
macOS也用不到mingw编译环境,可以考虑优化优化减小下体积。
一位乌克兰的国际友人已经分享在论坛了
sysfs的gpio,或者使用libgpio
打时序,量波形,SPI屏幕没有反馈只看白屏太正常了,之前调ili9488就遇到过有路信号时序不对白屏的
@smiletiger
你看看CCU部分PLL的Spread Spectrum描述就有了,不过据我近场测试来看,它对峰值基本没用,
平均值倒是下降不少,不晓得准峰值会不会好点。你可以试试,分享下。
T113也是支持展频的,至少LVDS和RGB都支持,MIPI我没试过就不知道有没有了
用近场探头扫扫,看看辐射路径呗。
全志把Can驱动部分写到了optee里面,除了Can我记得Ve也在里面,不嫌麻烦可以逆向,我记得awol上有can的逻辑支持
还有你的只读文件系统内脚本是不有等待,你先整个空的进去看看堵塞3秒的问题还在不
loglevel没改对吧,你这一条日志几个ms,怎么看都是没关闭打印的状态
我知道,我的意思是tina驱动支持了?我记得只有T527明确提到了linux的gpu支持。大部分平台全志也就只能安卓用用。
T527可以,507旧不晓得了,你确认没选错?
uboot环境变量不对吧,你是不是改了什么
有点久了,视频应该是没有了,具体现象很明显。
用qt5的webegine显示一个静态画面,只要网页没有动画,大概率会得到一个渲染中的画面,点击下鼠标就恢复了。
主动调用pandisplay是能够显示出最终画面的,当时还是觉得双缓冲哪里有问题,就在QT渲染结束的50ms后强制刷了一次屏幕。
大佬,要不研究下A133的QT双缓冲切换问题。在静态画面下,最后一帧在缓冲内一直不显示的毛病。
未初始化时读版本信息都会卡死,跑飞
没遇到过,估计还是时钟或者SRAM配置问题
这问题论坛之前有人遇到过,我记得是tick函数实现要改下
没了解过你这个场景,看起来像是用的他们的快速启动方案吧,我记得uboot是有个打印的。
默认pack不加任何参数,就是nosecure。
打包的时候有个nosecure模式,默认就是
可以去掉啊,这东西没有强制要求的
没有问题,boot0是闭源代码,全志就没打算让你折腾
web engine 需要gles库支持,但是它自己没有装载,你帮他装上就行
毕竟马甲太多了,全开放没发赚钱,你这个大概率是sysconfig不对,拿到sdk没哦
DISP属性里面有个大小,默认会开启缩放,到了内核就不用了
D1S和T113同源的,只要内核的话你直接用D1S的就行,D1s我记得是直接开放的。
默认SDK是要花钱买还有NDA挺麻烦的。
builder只需要调用下setup_ui和events_init就行了啊
把boot删掉就行
没有中断还是触发中断就死了,如果是进去就死了,还是要排查下异常向量表。
没说具体型号,原因是他们有NDA协议但我不知道范围,不敢乱说。
厂商是用的国芯的片子,前面两位大佬提到的方式我在它手册里面看了下,都没有。
他们的ISP下载是可以通过类似FUSE机制关闭掉,关掉就不再有ISP功能了,不然我也不会想到这种野路子。
在默认ISP下载时后会自动关闭ISP下载功能,强制从内部NOR启动,只是在demo中提供了自己在程序中通过GPIO来恢复的方法。
但是调试不小心搞坏固件了,我确实还是第一次遇到这种情况,想常见的STM32、GD32这些都没有遇到这毛病。
目前在调试MCU遇到一个问题,手贱吧swd的gpio功能改了,但是功能又没有开发好系统直接跑飞了。
现在上电连接jlink下载时会弹出失败,它是有两级boot的,而且启动期间swd是默认状态。
我在想一个可不可以在我初始化gpio功能前将他停下来,目前找了下没有发现相关资料,
有没有大佬可以指点下,我在想目前有两种思路,尝试把它救回来:
1. 让jlink在设备上电后用默认swd强制halt,看了看wiki没发现有相关的,都是先connect再halt的
2. 尝试让daplink实现类似功能,不知道有没有现成已经做好的方案,google了好久也没找到
DRAM不是就是用内部ldo供电的么,人家FUSE还专门设置了逻辑针对不同片子给不同电压
先排查下是不是进异常了,再确认下tick是不是还在走,我遇到基本都是这两问题
你得直觉是对的,全志的spl的ecc比较特别,需要额外处理下就行
他不是写这么DLAB
F1C在800x480下双缓冲模式打开,拖拽全屏demo只能到22帧左右
这个我之前研究过,就是C++等runtime的准备需求:
init_array/ctors:是gcc拓展__attribute__((construct))的拓展,一般还会兼职做C++的静态对象初始化。
ctors现在在很多高版本的gcc已经见不到了,init_array可以做到优先级控制,ctor会合并到init_array中
同理那两个也很清楚了,详细可以参考下newlib/newlib/libc/misc/init.c
其实如果你用高版本的gcc还能发现gcov这些也需要实现在连接脚本中
配合newlib的桩函数就可以愉快的使用baremetal c++了
你要确认你得rootfs是完整可运行的,可以用qemu-arm-static测试测试,它反馈没问题大概率没问题
肯定是有的瑟,之前安卓系统不支持glibc兼容性问题多,就是完整将rootfs打入再有init启动容器运行实现,
安卓做显示后台就是标准C++程序
容器lxc、直接chroot打包带上就行了,各跑各的环境,进程间通信应急还是可以的
确认下cache开了没,spi速度如何,CPU频率多少
这个太慢了,你确认过uboot的频率是不是100M哦,我没记错的话它默认用的24M时钟
从日志上看,你这uboot内核装载才4M/s的速度,远低于裸机的12M/s
全志那个boot_package.cfg那里面有所有运行需要的数据,然后再uboot.bin的header部分有部分数据是
boot0修改的,然后部分初始化比如显示需要现在uboot初始化再到内核才能正常。
最简单的就是写个xfel分payload直接装载内核和设备树这些,尽量绕开全志的tina引导
很明显没正对,Tina的uboot是一个打包文件需要分开解压一堆文件。可以看看boot0的代码,你得手动布好才行。
还不如直接用主线uboot启动,但是tina的linux会遇到一堆问题,非必要不建议折腾了
A64有mali_blob这东西啊?我还以为A64一直只有lima+mesa这组合呢
cma设置大点
你是不是用了weston初始化了drm,我记得它有个bug用fb的时候不要用drm
换个内核试试,我记得当时我在f1c上测试都没有这么低,会不会是版本问题
usb_bulk_send() ERROR -7: Operation timed out
这个出现在内存初始化后了,大概率在SPL里面跑飞了,你多加点打印点,检查下内存电源再试试
这个时候理论应该回到FEL模式,继续下载uboot
你这个是虚拟机还是实体的,我这个22.04都没问题
你用timer2哇,我记得linux下面timer0是做clockevent,timer1是做clocksource吧,也就timer2没有用到了,我感觉是被修改了
phonixsuit 有linux版本,用那个就行
那就只能自己努力拉
去linux的panle-simple.c下面找个1024*600的配置就行,一般这些屏的参数区别不大,对照填进去就行了,不过我记得RTT并没有合并F1C的显示啊
https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/panel/panel-simple.c
https://github.com/nminaylov/F1C100s_projects 这位大佬的项目甚至还在更新,可以参考学习学习
linux内核input内的杂项配置能看到个uinput配置,打开就行了
全志的工具有linux版本,直接按照配置来就行
这个是怎看出来的呢?
linux 有ubi磨损这些都抽象好了,直接用就完了
你先把用户添加到dailout组,然后用普通权限执行minicom就能保存了
滤波没有处理好
这个pwm的用法不对,建议去看看内核的文档,pwm不像spi他并没有实现类bus方法,
节点写这里是没有设备的,把它放到根路径下去就行了
没记错的话,v3s的lcd显示是lichee修改后的,主线框架没有支持这个型号的。
你按照提示关闭掉这些不需要的模块不就好了,内核启动需要TEE,注释掉那部分就行了
直接进入fel肯定是boot0的格式或者位置或者校验方法不对,上面配置都是uboot配置都没到那步
感觉像是cache一致性问题
理论上都是一个位置,看看是不是被什么复写了吧
感谢!这么操作是不是重启后就无效了?可以改dts或者源码吗?
肯定是可以的瑟, sun4i_tcon.c内改下就行了
#define SUN4I_TCON0_CTL_SWAP_RB_ENABLE BIT(23)
regmap_update_bits(tcon->regs, SUN4I_TCON0_CTL_REG,
SUN4I_TCON0_CTL_SWAP_RB_ENABLE,
SUN4I_TCON0_CTL_SWAP_RB_ENABLE);
T507就是A133的马甲之一吧,直接用A133的手册呗
最近发现一个神奇的现象,在linux下用devmem访问DRAMC区域就会发现数据不对。
比如devmem 0x1c01000 会得到0x000800c8,换下个地址也是这样的。但是如果
是在boot下时能够正常访问这个地址的,有知道为什么不?
换个buildroot版本吧,我记得systemd时含有udev的确实也用不到那个包
一般也不再start.s内吧,start.s主要就是初始化runtime运行时,一般也就保护下寄存器,初始化栈位置,初始化bss,然后就进入C环境了
一般跳转运行都在很靠后面了,具体可以参考下uboot的spl实现,jump_to_image_linux函数。
有的,不是又一堆的FRM寄存器么,那个就是。只不过de端你要用rgb888,DMA模式只支持565,不需要抖动了。同样很好奇软件抖动,你是自己写了个混合算法?
试用了一下,在F1C上也移植了下,感觉还是很nice原生就有DFB,但是不知道为啥如果假如select轮询后,linuxfb会出现有的timer会不触发,死循环是没这个问题的,估计还是自己的问题,总体感觉还是很不错,打印机demo也就1m左右
在高版本的linux上安装,需要手动改下代码才行,高版本GCC会把一些警告当错误
@海石生风
提升慢速IO的方法用cache是没错的,因为一般SOC设计下会出现片内SRAM并非与高速总线连接的现象。
在A64做裸机内存测试就发现,其片内SRAM连接的是AHB1的总线上IO性能也低到离谱。但是同样在不开启
MMU环境下在DDR上测试反而还好些。在此时如果在打开cache,两者差距其实并不明显,确实也能说明
都是由于低速IO引起。。
AXI本身就是低延迟高带宽的片内总线,它的访问速度应该是略慢于cpu的cache访问的,但是这个针对的是
高性能CPU本身而言,其cache的是位于CPU装载单元前。参考M7的内核结构图也能看出。这部分Cache
的SRAM访问速度肯定是略快于AXI总线的,不知道我理解有没有什么问题。
而片内SRAM其本身也未必是个慢速设备,M7的TCM号称0访问延迟,在NXP的RT1xxxx上也是使用的片内SRAM
实现,只是通过不同配置连接不同总线,依旧可以实现低延迟的传输,看起来应该与cache同级别,这个偏题了。
回到这个ACM32F4的芯片上,M33并没有在IP上设计cache,我也认为这个应该是SOC厂商自己加的,它应该属于
片外cache这种机制。即在原有的C-AHB和S-AHB总线上连接了一个cache,再由这个cache去控制慢速IO状态。
这个应该类似于STM32L5对外部cache的设计。而ACM32F4在SRAM的描述上提到了访问可以无延迟,所以对于
这样一个SOC的SRAM再做一个DCache确实也没什么意义。当然这也只是猜测,最好还是希望FAE能开放下这部分。
最近在尝试ACM32F4遇到两个头大的问题,航芯的FAE估计不对个人服务,没通过只好靠自己尝试解决下。
1. CMSIS的pack内的SVD文件不带寄存器位描述,rust包无法获取到位级别,欢迎大家一起补充。
解决方案:使用svdtools对官方文件进行描述补丁,在使用svd2rust进行解析。
项目地址: https://github.com/shaoxi2010/acm32f4
点灯项目: https://github.com/shaoxi2010/acm32f4-rs
更新了基本库使用和ICACHE的反编译代码。
2. ACM32F4在文档内提到一个非常有意思的东西L1Cache,之前接触到的Cache都是在有MMU环境下,这个
不带MMU环境的Cache还是第一次见,故对其产生了研究兴趣,因为手册上没有任何地方提及到cache使用,
但在其accelerate.a中观察到其实现。
首先是当前能获取到信息:
1. L1Cache位于Bus matrix之上,也就是C-AHB连接到ICache,S-AHB连接到了DCache
2. AHB1 和 AHB2 的时钟频率一致且等于系统频率,且处理器可以以 180MHz 的系统频率无等待地访问 SRAM。
3. 并未提及eFlash和SRAM有相同访问周期,故可能有延迟。
4. 从库函数解析上看,也实现了clean、invalid方法,但是在enable时没看到DCache的逻辑。
根据上述信息可以得出几个推论:
1. 同周期访问SRAM不就是Cache的功能么,那么DCache应该不需要连接到SRAM,大概率是外部内存。
当然我也没看到哪里支持外部内存,可能是为后续产品实现准备的。
2. 不知道DCache实现了标记内存为写透还是缓存的模型,按照现有给出来的数据,SRAM等外设进行cache
感觉就是画蛇添足。感觉大概率也是外部存储区域会使用Cache,其他都不用来减少编码复杂度,期待FAE
解答下。
3. ICache部分看上去只能与ROM和eFlash相连了,这部分的Cache应能提高程序执行性能,并且并不会影响
到代码的复杂度,感觉就ACM32F4目前状态而言,打开ICache将优化指令访问性能,提高执行效率。
4. 根据前面的推导和猜测可以大致猜想到,ACM32F4的cache模型应该与stm32l5的模型非常近似,可能这就是
对标产品。不确定仅猜测,附上stm32l5对L1Cache的解释说明。
an5212-using-stm32-cache-to-optimize-performance-and-power-efficiency-stmicroelectronics.pdf
所有时钟保持下载默认状态下,不开启ICache下执行eFlash Checksum时间约10s,打开ICache后提升到约4s。
证明ICache对eFlash的程序访问提升还是相当明显的。项目工程就是点灯工程。
测试日志如下:
11:43:54.997 checksum code without cache :start
11:44:04.945 checksum code without cache:end 517fa2f0
11:44:04.945 checksum code with cache :start
11:44:08.556 checksum code with cache:end 517fa2f0
11:44:09.058 blink led!
3. 目前发现程序断电后,直接插入后执行时常和效率完全不匹配明显慢了很多,估计是时钟源变了,需要继续分析下。
那个是clean后从新编译速度还行,rust的硬伤挺多的,C调用在这里面很小,因为ABI的调用规则是一样的。蛋疼反而再一些奇奇怪怪的地方,航芯的SVD里没有寄存器描述,库类型系统检查的优势完全反而弄得到处都得unsafe,算下来还不如C得头文件。格式化字符串会导致容量暴涨,这个FLASH大还好,f103上还是挺难取舍得。
在晕哥店里捡个漏拿便宜开发板,趁现在兴致还在赶紧玩玩。由于平常使用Mac和linux环境居多,基本不在window下开发,
受海石生风大佬的帖子感觉应该可行。最近在学习RUST,不久前stable部分的组建也完善了现在用RUST开发已经不在需要
arm-none-gcc的支持可以使用llvm实现全套编译,顺便可以省下几个G的工具链。目前cortex-m下rust支持很简单,cargo-embed
可以实现管理下载编译调试一条龙,probe-rs项目也可以支持CMIS包,svd2rust可以实现基本寄存器库,配合cortex-m和
cortex-m-rt支持,点个灯还是没有问题,简单记录分享下,尝试白嫖。
1. 需要安装rust相关组建
rustup default stable #使用稳定版工具链
rustup component add llvm-tools-preview #安装llvm工具链
rustup target add thumbv8m.main-none-eabihf #安装M33标准库
cargo install cargo-embed cargo-generate cargo-binutils target-gen svd2rust #安装辅助工具集
2. 下载修改的模版到本地,在官方基础上修改为stm32f103并使用cargo-embed管理,也添加了acm32的描述文件。
可以使用CMIS的pack用target-gen生成yaml描述,具体参考probe-rs项目
已修改好项目地址: https://github.com/shaoxi2010/cortex-m-quickstart
3. 使用cargo generate生成led项目 cargo generate --git ./cortex-m-quickstart -n acm32f4-rs
4. 生成acm32f40x寄存器库信息
a.先在acm32f4-rs的同级目录下新建一个rust库,使用cargo new --lib acm32f40x创建一个lib
b.使用pack文件解压出svd文件,并将ACM32F4.svd文件拷到acm32f40x目录下
c.使用svd2rust -i ACM32F4.svd生成代码,将生成的lib.rs文件拷贝到src目录下
d.强迫症患者用rustfmt对生成文件进行重新格式化,库就算搞定了
PS:pack文件下是没有寄存器feild描述,比较坑爹,没发使用位方法,但是我看stm32是有的。。。
5. 回到led项目,将刚生成的寄存器库添加到Cargo.toml文件中
6. 其他修改参考rust的cortex-m的说明即可,可参考芯片yaml文件。
7. 在Embed.toml文件修改[default.general]下的chip = "ACM32F403RET7"
8. 写点逻辑代码编个简单的LED程序,完成。
9. 最后接上USB,连接电路板,cargo embed执行下载调试。
点灯完整项目可参考: https://github.com/shaoxi2010/acm32f4-rs
运行效果如下:
imx6好像有这样的功能,全志只能叠层显示
不用的,uboot是通用的,当然前提你用的是bsp的东西才行,主线的话逆向下就行了
有三个条件,A33的用新版本,boot0需要替换为新版本,sys_config.fex修改
一直不对是什么现象哦,有没有用点屏器试过?
有点怀疑你是不是没开什么选项,建议你先用带ramfs得系统启动,尝试手动挂载下看看缺少什么东西不。
看上去是设备不存在的问题,改下env的log等级看看完整的打印吧
1.速率这个我记得uboot得设备树还有个配置要改下
2.挂载慢这个问题应该也是jffs扫描,先排查下mtd得性能吧,确认下频率和双线是否打开的
3.随机种子这个是由于中断数量不够glibc在内核头文件较高时会阻塞get_random,三个办法:a.增加中断数量 b.修改crng内核 c.将glibc内核头文件换到3.10前
我这边就简单说下大致思路吧,我感觉就是分析-验证不断重复优化就完了。
1. 常规优化部分,比如关闭uboot的delay、关闭不必要的串口打印、关闭不必要的功能,先看看基本情况。
2. 还不理想就统计各个阶段的时常,先找到消耗最大的问题点,再去排查影响。比如:
a)boot阶段的spi性能很差,也没有开启dma使用双线模式
b)内核解压缩阶段,受CPU和内存性能gzip本身就很慢但lzo压缩会快很多
c)内核启动阶段,通过初始化时间上看,spinand坏块扫描消耗很大,ubi挂载也比较慢
d)程序启动阶段,分析是卡在IO上还是卡在CPU上
3. 根据性能问题点去针对性修改,
a) boot阶段直接重写,打开cache并使用双线spi驱动加载,再使用lz4进行提前解压缩,权衡spi读取速度和解压缩速度提高空间利用率,约14M/s
b) 针对主线spinand内核架构多次的buffer,重写了spinand驱动,避免访问2字节也读一页,命令多次重发,多次memcpy,IO提升到8M/s
c) 针对ubi层级慢,使用快速挂载减少扫描,选择压缩模式到lzo,得到最佳权衡性能
d)对应用进行裁减,减少load的数量级,比如使用musl的libc,去除掉C++功能,排查调度器,将CPU尽量让给UI程序,选择一些小的UI框架提升也挺大的
欸,里面提到的SMP有些芯片多核是自动启动的是些啥芯片哦,能否告诉一下型号避免踩坑呢?
f1c不是说控制器没有quad模式么
异常后能恢复?还是一直卡着了,一直卡着可以排查下波形,可以能一直被拉低了。
A路1.8V, B路DRAM应该是1.35V,内存初始化后会变成1.5V,你这现象先去排查硬件问题吧,估计哪里没整对。
好炫酷
lvgl的drm驱动实现我也不是很了解,看他们描述说的是VSYNC信号的同步等待引起的,
但是按理说应该不会引起CPU上升这么多,你可尝试改小usleep值看下呢降低任务延迟看看。
CPU的值你可以去top看看,lvgl的实际值确实要比top统计的高不少,不确定它的计算标准。
5.4的没注意过,4.19的修改我提到过
直接用waitpid捕获退出类型,检测退出返回值不是正常退出就重拉
这问题很早就被解决了啊,主线的uboot已经支持了从nand进行boot,控制器这块代码也有
了,而且我记得没错内核连DMA都支持了,控制器确实有坑但影响不大。其中最大的坑确实
也和博客中说的一致,就是pagesize和ecc的问题,这个大佬们已经分享出来了。其实参照
uboot的自身文档board/sunxi/README.nand,你就可以获得一个主线带nand启动的uboot。
链接: https://linux-sunxi.org/NAND
章节:More information on BROM NAND
就用uboot的命令就行了,用loadz从串口加载到内存,在SPINAND可以用mtd命令写进去,看你uboot支持了
这么神奇的啊,话说RISCV的BROM在那个位置弄出来的啊
@xboot
这个CPU之前恰巧分析过一些,当时为了删除TEE做了第二核启动的linux逻辑。
实际上启动第二核心很简单,就两个东西。中断我没看到有什么被劫持的地方,
也可能是我没找到吧。而且T113的BROM就是确实也是ARM代码开始的,听代理
说这两个die是存在差异的,所以我也不确定是不是还有RSICV的核心在里面。
一个是brom代码dump一下就能看到的入口地址,就在开头位置。
第二就是打开手册里面提到的C0_RST_CTRL,将核心1打开。
cpuboot_membase = 0x070005c4
cpuxcfg_membase = 0x09010000
参考代码如下
writel(__pa_symbol(secondary_startup), cpuboot_membase + cpu*4);
/* Deassert the CPU core in reset */
reg = readl(cpuxcfg_membase);
writel(reg | BIT(cpu), cpuxcfg_membase)
基于之前对f1c200快速启动项目的研究,抽离出基本的在arm9处理器上最基本运行代码。
适配串口后同样能在f1c200上跑起来,供大家一起研究共同进步。
git地址: https://github.com/shaoxi2010/rust-arm9
项目目标
由于目前rust官方没有提供arm9的裸机环境支持,但是本身又不想放弃f1c200这个便宜又实在的平台。
这里就单纯的抛砖引玉作用了,吸引大家一起来研究下arm9的rust开发。
代码参考来源xboot,大佬真强。
使用rust与c开发的优缺点
1. cargo的存在使得rust不用在额外学习makefile等,简化项目管理统一编译
2. rust本身提供了很多基础实现,可以很方便的使用
3. rust提供的抽象可以很直观的理解代码含义,自身命名空间有效解决隔离问题
4. rust的抽象成本非常低,异常逻辑完善,debug起来很直观
5. rust的格式化字符串消耗较大,但灵活度高,在小内存比较难控制
6. rust的内联汇编与GCC内联汇编有些许的不一样,需要一定的学习成本
实现原理
核心思想与gcc编译内核一致,只要需要rust生成代码时,去除掉允许库相关依赖,程序严格
上来讲是可以允许在裸机环境。这时我们在采用arm-none-eabi-gcc的链接功能,将程序链接
成为一个完整环境即可,即可以同时将C与RUST一同编译链接实现。
在编写程序中遇到的问题
1. 首先裸机开发需要link.lds链接文件,需要将text,data,rodata(不链接没有字符串),bss段
2. 在start的启动汇编上需要设置sp地址否则会发现程序异常跑飞,qemu反复验证
3. 启动汇编需要清理bss段,否则static变量会出问题,qemu反复验证
4. rust内连汇编切记,会引起寄存器变化一定要使用inout实现,否则变量可能会被认为不变而不会对寄存器赋值直接跑飞,反汇编
5. 对于cpu操作应当详细参考arm手册,操作cp异常也可能会导致程序卡死,cache_flush卡死,qemu联调发现
6. rust的目标armv5te-unknown-linux-gnueabi目标会使用动态链接器,如Scrt1.o、libc,需要添加-no-pie和-no-stdlib避免链接
7. unwind在裸机环境并不支持,需要关闭栈回溯功能使用profile下panic = "abort"
8. __aeabi_unwind_cpp_pr0和eh_personality方法依赖于libgcc,也是栈回溯的一部分,空实现就行。
9. 关闭mmu并不会对数据进行flush操作,需要手动flush相关内容,不知道是不是ARM9特有
10. asm与gloabl_asm均会对{}进行解析处理,arm指令内带{}需要使用{{}}包装,或者使用raw模式,参见rust内联汇编文档
11. mmu的页彪需要对齐,否则会卡死在打开mmu上,qemu联调
程序运行与程序验证
1. 首先使用rustup target add armv5te-unknown-linux-gnueabi添加rust的arm9支持 (nightly)
2. 使用apt install arm-none-eabi-gcc安装arm工具链
3. 使用cargo build --release 生成二进制
4. 使用 arm-none-eabi-objcopy --binray target/armv5te-unknown-linux-gnueabi/release/rust-arm9 arm9生成裸机运行二进制
5. 下载目标机器
QEMU虚拟化运行和gdb联调
在实际环境下可能没有设备可以调试,使用QEMU虚拟机调试是很有效的办法。
QMUE 平台
1. 当前代码平台适配versatilepb即ARM Versatile/PB (ARM926EJ-S)
2. 使用qemu-system-arm -M versatilepb -serial stdio -display none -kernel target/armv5te-unknown-linux-gnueabi/release/rust-arm9运行
3. 即可看到hello world 输出
GDB联合调试
1. 添加QEMU调试参数-s -S运行即qemu-system-arm -s -S -M versatilepb -serial stdio -display none -kernel target/armv5te-unknown-linux-gnueabi/release/rust-arm9
2. 使用gdb-multiarch target/armv5te-unknown-linux-gnueabi/release/rust-arm9加载GDB
3. 进入gdb后使用target remote :1234,即可看到程序停在入口_start
4. 使用break等命令添加断点,或者反汇编等操作,一步步监视运行,调试程序bug
v3s有512M?不是64M么
工作时经常会遇到需要DHCP进行上网,由需要设置静态IP进行访问,太麻烦了
所以记录分享下linux和windows同时设置DHCP和静态IP的方法。
window:按照大佬的说法是需要打开系统的一个属性dhcpstaticipcoexistence
1. netsh interface ipv4 set interface interface="interface name" dhcpstaticipcoexistence=enabled
2. netsh interface ipv4 add address "interface name" 192.168.x.xxx 255.255.255.0
linux:简单很多,netowrkmanager默认配置就是DHCP在其基础上添加一个静态IP就行
1. nmcli connection edit "connection"
2. set ipv4.addresses 192.168.x.xxx/24 提示修改为manual填no就行
打开swap就行了,缺点就是慢,这么小的内存不适合debian
the spidev need a device tree node, such as this.
&spi0 {
spidev@0 {
compatible = "rohm,dh2228fv";
reg = <0>;
spi-max-frequency = <24000000>;
};
};
挺好用的,最开始是因为qt5的tslib驱动不支持旋转,然后就用了这个方案了。
check the device tree compatible property, try "rohm,dh2228fv"
恩,加个-d就是一个后台的daemon程序
因为用的是ts_uinput,会将原始坐标做一次tslib转换后再生成新的event设备为符合屏幕转换的点信息。
所以没有用tslib驱动,用的evdev驱动
不同内核修改方法是不一样的,这个是4.19的修改方法, 将sun4i_frambuffer.c的32修改为16就行了。
我记得5.4应该是要修改panle属性还是什么来着,已经忘记了。
int sun4i_framebuffer_init(struct drm_device *drm)
{
drm_mode_config_reset(drm);
drm->mode_config.max_width = 8192;
drm->mode_config.max_height = 8192;
drm->mode_config.funcs = &sun4i_de_mode_config_funcs;
drm->mode_config.helper_private = &sun4i_de_mode_config_helpers;
return drm_fb_cma_fbdev_init(drm, 16, 0);
}
F133 全志不是还有meli系统嘛,去找代理拿资源嘛
可能是编译没选对吧,看下二进制的架构信息吧
是不是没有平台优化哦,你用newlib的汇编试一下哇
商业授权多少钱哦?
参照qt的文档说明,没看到那个什么qt-config工具,大佬有了解的?
恩,感觉你这么说换cpu的成本确实比换屏幕低了不少啊,屏幕质量如何哦?f1c话说能点亮mipi?
还有,为啥不选个横屏呢,这种奇怪得应用我记得只在mipi上常见,还是说成本控制原因
噗,打了一串网络有问题,没得了。
说结论吧,我觉得你这两个都能做到,毕竟现在f1c得状态已经解决你得需求了。
而且我觉得这两个应该还有空间,可以进一步优化,应该还能留下裕量。
首先,90度旋转问题应该是问题点,因为不连续问题,对cache得友好程度很差,
A133得cv旋转1080p耗时在20ms左右,neon加速旋转5ms左右,跟默认得
V3s折合我觉得应该在10ms左右。如果能用neon应该更快。
其次,AWTK我记得是有脏矩阵,而且还是三缓冲,这边得拷贝应该也是有无法避免
得耗时,你可以看下能不能关掉。
最后,我觉得F133得G2D适配,估计没那么容易,而且我也没测试过它得G2D这里
就不做评论了,我觉得吧它应该不会比neon慢,毕竟专用加速芯片了。
你要能用上这个还是有提升的,在QT的环境下并不支持全志G2D,而且就
字体渲染这些基本用不到G2D,感觉多一点的就bitbilt操作吧还有就是
旋转了,对于基本没怎么用到这些,性能提升很微弱。这种还不如双缓冲
多层绘制感知来的强。而且最重要得一点这东西需要驱动和应用支持。。。
我也不知道你想干嘛,但是不上高分720p以上,CPU基本够用了,就看你要求
帧率有多少了,其他得可能只能你自己确认了。
这个看你怎么去应用了,F133的RSICV性能下在QT4性能测试是明显弱于同世代的T113,
T113我还跑在800M下F133为1G,估计还是RSICV的生态这块还做的不怎么样。目前发现
整形的性能是要弱于ARM,浮点性能好于ARM,整体GUI百万次调用基本都慢于ARM,浮点
影响较大的椭圆要由于ARM,最大的差距还是freetype字体渲染,慢了5倍估计和freetype
平台优化代码相关。反正我觉得RISCV还是不成熟,价格也没有优势,等降价吧。
这两个本身没什么区别只是gcc -mfloat-abi=hard option这个存在默认值的差异。
最大的差异还是CALL standard的参数栈规则不一样,我记得也就只是浮点数存在差异。
这个东西也就影响性能在函数参数传递有一定的性能下降,对于这么高级的CPU影响应该
没有那么大。而且根据arm的说明The default for --target=arm-arm-none-eabi is softfp.
softfp是含有了vfpv的浮点加速的,也就是你指定了fpu浮点单元,他就能提供浮点优化
代码,理论上不应该有这么大的性能差异。
经过验证,确实可以输出音频。使用转换器转换为48000Hz的16bit深度wav,后
可以正常的播放,NAND使用空间约60M,wave约74M。感觉可以学习aw-ol的大佬
试着把这个demo放出声来。
eabi指的是abi的借口调用规则,和硬件浮点没关系啊,你打开优化选项就行了
arm-none-eabi应该通吃的,我内核v3s和f1c都用这个,省事
对着驱动代码,把codec这块的输入输出整理一下不知道理解有没有问题。
用CODEC的时候时常发现卡死、没声音等问题主要还是输入输出源没配置好。
找了一大圈也没找到分析这个怎么使用的,小弟久对着驱动整理下,F1c200的
datasheet和驱动对应关系。不知道对不对,还请大佬指点。
通过tiny mix contents可以看到当前系统所有的可控制模块
Number of controls: 25
ctl type num name value
0 INT 1 DAC Playback Volume 63 (range 0->63)
1 INT 1 Headphone Playback Volume 0 (range 0->63)
2 BOOL 2 Headphone Playback Switch Off, Off
3 INT 1 Line In Playback Volume 0 (range 0->7)
4 INT 1 FM In Playback Volume 0 (range 0->7)
5 INT 1 Mic In Playback Volume 3 (range 0->7)
6 INT 1 Mic Boost Volume 4 (range 0->7)
7 INT 1 ADC Capture Volume 3 (range 0->7)
8 BOOL 1 ADC Mixer Right Out Capture Switch Off
9 BOOL 1 ADC Mixer Left Out Capture Switch Off
10 BOOL 1 ADC Mixer Line In Capture Switch Off
11 BOOL 1 ADC Mixer Right FM In Capture Switch Off
12 BOOL 1 ADC Mixer Left FM In Capture Switch Off
13 BOOL 1 ADC Mixer Mic Capture Switch Off
14 BOOL 1 Left Mixer Right DAC Playback Switch Off
15 BOOL 1 Left Mixer Left DAC Playback Switch Off
16 BOOL 1 Left Mixer FM In Playback Switch Off
17 BOOL 1 Left Mixer Line In Playback Switch Off
18 BOOL 1 Left Mixer Mic In Playback Switch Off
19 BOOL 1 Right Mixer Left DAC Playback Switch Off
20 BOOL 1 Right Mixer Right DAC Playback Switch Off
21 BOOL 1 Right Mixer FM In Playback Switch Off
22 BOOL 1 Right Mixer Line In Playback Switch Off
23 BOOL 1 Right Mixer Mic In Playback Switch Off
24 ENUM 2 Headphone Source Playback Route , DACMixer, , DACMixer
根据上图推论:
1.录音时:
tinymix set 13 1 #打开MIC到ADC输入
tinycap cap.wav #开始录音
这个验证OK
2.播放时:
tinymix set 24 DAC #打开headphones到DAC输出,不使用Mixer
tinymix set 2 1 #打开headphones输出开关
tinymix set 1 40 #设置增益为40
tinyplay cap.wav
这个验证能播放,但是我没喇叭不知道有没有声音
看到LVGL支持了DRM,按道理F1C200的驱动情况下也能支持双缓冲效果。
简单的测试了下,支持还是很可以的,看上去也就是CPU有点高。
对比了下CPU和top看到的存在较大的差异,可能计算方式不一样吧?
修改使用tslib的ts_uinput来校准输入,模拟为event1
修改使用libdrm的输出,输出双缓冲。
验证代码,应该要修改下Makefile的CFLAGS下的路径
https://github.com/shaoxi2010/lv_port_linux_frame_buffer
有没有在调频,之前我遇到过CPU降频时,A33出现过类似现象。将CPU调度器调为performance就好了。
shaoxi2010 说:kekemuyu 说:2s进ui太牛了,是用的spi falsh吗?
是的,Tiny200自带的兆易spinand。不过目前目前整个rootfs也就十多M,感觉换nor应该更划算点吧。
楼主牛人!可以提供一个烧录固件体验一下吗?
目前打算自己用,抱歉。如果你也想做优化我可以提供思路。
@shaoxi2010
nor比nand慢很多吧
因为目前看起来nor和nand都支持双线读模式,而nor的读操作省掉了loadpage和waitstatus
每2k就可以少发几个指令,可以少调度少IO,按道理应该更加明显,当然我没片子没测试过。
仅理论推断。
2s进ui太牛了,是用的spi falsh吗?
是的,Tiny200自带的兆易spinand。不过目前目前整个rootfs也就十多M,感觉换nor应该更划算点吧。
去掉QT后有明显的提升,目前上电到启动可以做到在2s显示画面。
耗时一个月总算达到理想值了,真不容易啊。
[00-10-26.876] [0]Shaoxi2010 f1c loader
[00-10-26.894] [14]DRAM: 64M
[00-10-26.894] [16]MMU:83ffc000
[00-10-26.894] [16]heap:82ffc000-83ffbffc
[00-10-26.915] [39] load: fdt 262144
[00-10-27.382] [501] load: kernel 7515276
[00-10-27.387] [501]start kernel at 0x80008000 fdt at 0x82ffc800!
[00-10-28.302] The framebuffer device was opened successfully.
[00-10-28.328] 480x272, 16bpp
[00-10-28.334] The framebuffer device was mapped to memory successfully.
[00-10-30.313] Starting syslogd: OK
[00-10-30.348] Starting klogd: OK
[00-10-30.449] Running sysctl: OK
[00-10-30.474] Starting mdev... OK
[00-10-31.539] modprobe: can't change directory to '/lib/modules': No such file or directory
[00-10-31.595] Initializing random number generator: OK
[00-10-31.618] Saving random seed: OK
[00-10-31.700] Starting network: ip: socket: Function not implemented
[00-10-31.714] ip: socket: Function not implemented
[00-10-31.714] FAIL
[00-10-31.824]
[00-10-31.829] Welcome to Tiny200
排查发现在drm_probe_fbhepler下确实存在panle延迟初始化,但其对启动优化没影响,只是干扰了启动时间判断
掏出了多年未使用的逻辑分析仪,抓了下启动时间。
目前对系统侧面启动优化已经靠近极限,也就只剩下100ms左右的坏快扫描。
通过GPIO对启动整个流程检测确认,以reset上升为起点,用逻辑分析仪器抓波形。
1. spinand上电brom到运行boot0耗时约200ms,难道是我之前打错了?
2. boot0启动解压kernel消耗500ms
3. kernel进入到kernel计时开始40ms左右
4. kernel完成到init开始,500ms
5. fb panle的perpare从kernel启动耗时1.35s,难道是异步的?
6. 剩余时间为应用层耗时
结论:
1. boot的记时与内核记时是准确的,逻辑分析仪抓取
2. 上电到启动到init总共约1.2s左右
3. drm显示不知道为什么会有延迟初始化现象,可能会阻塞qt启动
4. 目前感觉最大的性能瓶颈在CPU和NAND的IO上,可能换NOR会有更好性能
5. 目前主要瓶颈集中在应用层,看起来更换掉QT5应该会有更好的性能
经过不懈努力排查,目前能做到3s左右进入QT5的时钟demo。但从目前来看还有比较多的疑惑项。
1. 示波器观察上电到启动bootloader约100ms
2. bootloader解压成Image,引导linux启动花费500ms,排除内核解压逻辑。
3. 进入内核观察dmesg打印,fb初始化大约在350ms
但是仔细比对视频帧发现,其实阶段时间不对。
1. 从上电到fb由白变黑时常大约是2s左右,统计只有不到1s。
2. fb变白到qt起来基本上1s左右,基本符合。
看起来从Image启动到内核计时开始有约解决1s的时间耗在了不知道的地方,不知道这个结论对不对?
不知道大佬们研究过这一段启动时间没有,感觉有点不对劲。
启动日志如下:
[21-41-23.660] tiny200 login:
[21-41-23.660] [0]Shaoxi2010 f1c loader
[21-41-23.684] [14]DRAM: 64M
[21-41-23.684] [16]MMU:83ffc000
[21-41-23.684] [16]heap:82ffc000-83ffbffc
[21-41-23.698] [39] load: fdt 262144
[21-41-24.164] [500] load: kernel 7515276
[21-41-24.190] [500]start kernel at 0x80008000 fdt at 0x82ffc800!
[21-41-25.952] QFbVtHandler: socketpair() failed (Function not implemented)
[21-41-27.123] Starting syslogd: OK
[21-41-27.154] Starting klogd: OK
[21-41-27.247] Running sysctl: OK
[21-41-27.271] Starting mdev... OK
[21-41-28.280] modprobe: can't change directory to '/lib/modules': No such file or directory
[21-41-28.332] Initializing random number generator: OK
[21-41-28.353] Saving random seed: OK
[21-41-28.429] Starting network: ip: socket: Function not implemented
[21-41-28.442] ip: socket: Function not implemented
[21-41-28.443] FAIL
[21-41-28.553]
[21-41-28.568] Welcome to Tiny200
[21-41-30.178] tiny200 login: root
[21-41-30.197] login[112]: root login on 'console'
[21-41-32.904] # dmesg
[21-41-32.923] [ 0.000000] Booting Linux on physical CPU 0x0
[21-41-32.937] [ 0.000000] Linux version 4.19.223 (parallels@debian-gnu-linux-10) (gcc version 7.3.1 20180622 (release) [ARM/embedded-7-branch revision 261907] (15:7-2018-q2-6)) #102 Sun Jan 9 20:54:06 CST 2022
[21-41-32.948] [ 0.000000] CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=0005317f
[21-41-32.958] [ 0.000000] CPU: VIVT data cache, VIVT instruction cache
[21-41-32.958] [ 0.000000] OF: fdt: Machine model: Tiny200
[21-41-32.958] [ 0.000000] Memory policy: Data cache writeback
[21-41-32.967] [ 0.000000] On node 0 totalpages: 16384
[21-41-32.975] [ 0.000000] Normal zone: 128 pages used for memmap
[21-41-32.975] [ 0.000000] Normal zone: 0 pages reserved
[21-41-32.975] [ 0.000000] Normal zone: 16384 pages, LIFO batch:3
[21-41-32.986] [ 0.000000] random: get_random_bytes called from start_kernel+0x70/0x35c with crng_init=0
[21-41-32.993] [ 0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[21-41-32.993] [ 0.000000] pcpu-alloc: [0] 0
[21-41-33.003] [ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 16256
[21-41-33.014] [ 0.000000] Kernel command line: console=ttyS1,115200 loglevel=4 root=ubi0 ubi.mtd=4 rootfstype=ubifs ubi.fm_autoconvert=1 cma=16m lpj=598528
[21-41-33.021] [ 0.000000] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
[21-41-33.029] [ 0.000000] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
[21-41-33.041] [ 0.000000] Memory: 58308K/65536K available (3191K kernel code, 203K rwdata, 1104K rodata, 1024K init, 197K bss, 7228K reserved, 0K cma-reserved)
[21-41-33.041] [ 0.000000] Virtual kernel memory layout:
[21-41-33.047] [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB)
[21-41-33.054] [ 0.000000] fixmap : 0xffc00000 - 0xfff00000 (3072 kB)
[21-41-33.061] [ 0.000000] vmalloc : 0xc4800000 - 0xff800000 ( 944 MB)
[21-41-33.067] [ 0.000000] lowmem : 0xc0000000 - 0xc4000000 ( 64 MB)
[21-41-33.074] [ 0.000000] modules : 0xbf000000 - 0xc0000000 ( 16 MB)
[21-41-33.080] [ 0.000000] .text : 0x(ptrval) - 0x(ptrval) (4184 kB)
[21-41-33.087] [ 0.000000] .init : 0x(ptrval) - 0x(ptrval) (1024 kB)
[21-41-33.094] [ 0.000000] .data : 0x(ptrval) - 0x(ptrval) ( 204 kB)
[21-41-33.101] [ 0.000000] .bss : 0x(ptrval) - 0x(ptrval) ( 198 kB)
[21-41-33.108] [ 0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[21-41-33.108] [ 0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[21-41-33.115] [ 0.000044] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 89478484971ns
[21-41-33.126] [ 0.000106] clocksource: timer: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 79635851949 ns
[21-41-33.133] [ 0.000325] Calibrating delay loop (skipped) preset value.. 299.26 BogoMIPS (lpj=598528)
[21-41-33.140] [ 0.000357] pid_max: default: 32768 minimum: 301
[21-41-33.147] [ 0.000698] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[21-41-33.155] [ 0.000719] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[21-41-33.155] [ 0.001777] CPU: Testing write buffer coherency: ok
[21-41-33.163] [ 0.003366] Setting up static identity map for 0x80100000 - 0x8010003c
[21-41-33.163] [ 0.008529] devtmpfs: initialized
[21-41-33.174] [ 0.014679] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
[21-41-33.181] [ 0.014719] futex hash table entries: 256 (order: -1, 3072 bytes)
[21-41-33.188] [ 0.014876] pinctrl core: initialized pinctrl subsystem
[21-41-33.196] [ 0.017109] DMA: preallocated 256 KiB pool for atomic coherent allocations
[21-41-33.196] [ 0.036961] SCSI subsystem initialized
[21-41-33.204] [ 0.037260] usbcore: registered new interface driver usbfs
[21-41-33.211] [ 0.037378] usbcore: registered new interface driver hub
[21-41-33.218] [ 0.037489] usbcore: registered new device driver usb
[21-41-33.218] [ 0.038235] Advanced Linux Sound Architecture Driver Initialized.
[21-41-33.226] [ 0.039022] clocksource: Switched to clocksource timer
[21-41-33.234] [ 0.045209] workingset: timestamp_bits=30 max_order=14 bucket_order=0
[21-41-33.243] [ 0.068338] io scheduler noop registered (default)
[21-41-33.243] [ 0.068358] io scheduler mq-deadline registered
[21-41-33.252] [ 0.080202] suniv-pinctrl 1c20800.pinctrl: initialized sunXi PIO driver
[21-41-33.252] [ 0.101924] Serial: 8250/16550 driver, 8 ports, IRQ sharing disabled
[21-41-33.260] [ 0.106589] console [ttyS1] disabled
[21-41-33.267] [ 0.126876] 1c25400.serial: ttyS1 at MMIO 0x1c25400 (irq = 26, base_baud = 6250000) is a 16550A
[21-41-33.275] [ 0.127076] console [ttyS1] enabled
[21-41-33.275] [ 0.134453] panel-simple panel: panel supply power not found, using dummy regulator
[21-41-33.284] [ 0.134659] panel-simple panel: Linked as a consumer to regulator.0
[21-41-33.291] [ 0.136297] SCSI Media Changer driver v0.25
[21-41-33.291] [ 0.137309] sun6i-spinand 1c05000.spi: speed clock 100000000
[21-41-33.300] [ 0.137335] sun6i-spinand 1c05000.spi: fifo depth 64
[21-41-33.309] [ 0.138510] 5 fixed-partitions partitions found on MTD device (null)
[21-41-33.309] [ 0.138529] Creating 5 MTD partitions on "(null)":
[21-41-33.315] [ 0.138557] 0x000000000000-0x000000080000 : "spl"
[21-41-33.324] [ 0.139942] 0x000000080000-0x000000180000 : "u-boot"
[21-41-33.324] [ 0.140742] random: fast init done
[21-41-33.324] [ 0.141579] 0x000000180000-0x0000001c0000 : "dtb"
[21-41-33.331] [ 0.142595] 0x0000001c0000-0x0000007c0000 : "kernel"
[21-41-33.339] [ 0.148596] 0x0000007c0000-0x000007f80000 : "rootfs"
[21-41-33.339] [ 0.207685] random: crng init done
[21-41-33.346] [ 0.257719] usbcore: registered new interface driver usb-storage
[21-41-33.354] [ 0.258511] usb_phy_generic usb_phy_generic.0.auto: usb_phy_generic.0.auto supply vcc not found, using dummy regulator
[21-41-33.362] [ 0.258709] usb_phy_generic usb_phy_generic.0.auto: Linked as a consumer to regulator.0
[21-41-33.369] [ 0.271390] musb-hdrc musb-hdrc.1.auto: MUSB HDRC host driver
[21-41-33.377] [ 0.271462] musb-hdrc musb-hdrc.1.auto: new USB bus registered, assigned bus number 1
[21-41-33.384] [ 0.273058] hub 1-0:1.0: USB hub found
[21-41-33.385] [ 0.273189] hub 1-0:1.0: 1 port detected
[21-41-33.385] [ 0.275200] i2c /dev entries driver
[21-41-33.396] [ 0.277320] input: ns2009_ts as /devices/platform/soc/1c27000.twi/i2c-0/0-0048/input/input0
[21-41-33.403] [ 0.279493] sunxi-wdt 1c20ca0.watchdog: Watchdog enabled (timeout=16 sec, nowayout=0)
[21-41-33.412] [ 0.281031] sunxi-mmc 1c0f000.mmc: Linked as a consumer to regulator.1
[21-41-33.419] [ 0.307578] sunxi-mmc 1c0f000.mmc: initialized, max. request size: 16384 KB
[21-41-33.427] [ 0.309895] usbcore: registered new interface driver usbhid
[21-41-33.427] [ 0.309909] usbhid: USB HID core driver
[21-41-33.434] [ 0.313210] sun4i-codec 1c23c00.codec: ASoC: Failed to create component debugfs directory
[21-41-33.443] [ 0.317374] sun4i-codec 1c23c00.codec: Codec <-> 1c23c00.codec mapping ok
[21-41-33.451] [ 0.335660] sun4i-backend 1e60000.display-backend: Couldn't find matching frontend, frontend features disabled
[21-41-33.459] [ 0.336298] sun4i-drm display-engine: bound 1e60000.display-backend (ops 0xc044f6d0)
[21-41-33.468] [ 0.337392] sun4i-drm display-engine: bound 1c0c000.lcd-controller (ops 0xc044e590)
[21-41-33.477] [ 0.337419] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[21-41-33.484] [ 0.337425] [drm] No driver support for vblank timestamp query.
[21-41-33.484] [ 0.339506] sun4i-drm display-engine: fb0: DRM emulated frame buffer device
[21-41-33.493] [ 0.340442] [drm] Initialized sun4i-drm 1.0.0 20150629 for display-engine on minor 0
[21-41-33.500] [ 0.341375] ubi0: default fastmap pool size: 45
[21-41-33.500] [ 0.341392] ubi0: default fastmap WL pool size: 22
[21-41-33.509] [ 0.341400] ubi0: attaching mtd4
[21-41-33.509] [ 0.410738] ubi0: attached by fastmap
[21-41-33.516] [ 0.410757] ubi0: fastmap pool size: 45
[21-41-33.524] [ 0.410765] ubi0: fastmap WL pool size: 22
[21-41-33.524] [ 0.422128] ubi0: attached mtd4 (name "rootfs", size 119 MiB)
[21-41-33.532] [ 0.422150] ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
[21-41-33.540] [ 0.422162] ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
[21-41-33.547] [ 0.422173] ubi0: VID header offset: 2048 (aligned 2048), data offset: 4096
[21-41-33.555] [ 0.422182] ubi0: good PEBs: 956, bad PEBs: 2, corrupted PEBs: 0
[21-41-33.563] [ 0.422193] ubi0: user volume: 1, internal volumes: 1, max. volumes count: 128
[21-41-33.570] [ 0.422207] ubi0: max/mean erase counter: 4/1, WL threshold: 4096, image sequence number: 1526521727
[21-41-33.579] [ 0.422219] ubi0: available PEBs: 0, total reserved PEBs: 956, PEBs reserved for bad PEB handling: 38
[21-41-33.579] [ 0.422589] of_cfs_init
[21-41-33.579] [ 0.422683] of_cfs_init: OK
[21-41-33.586] [ 0.422864] ALSA device list:
[21-41-33.587] [ 0.422879] #0: F1C100s Audio Codec
[21-41-33.595] [ 0.424360] ubi0: background thread "ubi_bgt0d" started, PID 54
[21-41-33.595] [ 0.459605] UBIFS (ubi0:0): recovery needed
[21-41-33.602] [ 0.497383] UBIFS (ubi0:0): recovery deferred
[21-41-33.611] [ 0.497594] UBIFS (ubi0:0): UBIFS: mounted UBI device 0, volume 0, name "rootfs", R/O mode
[21-41-33.618] [ 0.497614] UBIFS (ubi0:0): LEB size: 126976 bytes (124 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
[21-41-33.627] [ 0.497635] UBIFS (ubi0:0): FS size: 114405376 bytes (109 MiB, 901 LEBs), journal size 9023488 bytes (8 MiB, 72 LEBs)
[21-41-33.636] [ 0.497644] UBIFS (ubi0:0): reserved for root: 0 bytes (0 KiB)
[21-41-33.645] [ 0.497664] UBIFS (ubi0:0): media format: w4/r0 (latest is w5/r0), UUID 25CC3243-8C84-41A3-8BD7-5455775BCE75, small LPT model
[21-41-33.653] [ 0.499196] VFS: Mounted root (ubifs filesystem) readonly on device 0:13.
[21-41-33.660] [ 0.500304] devtmpfs: mounted
[21-41-33.667] [ 0.505190] Freeing unused kernel memory: 1024K
[21-41-33.667] [ 0.505295] Run /sbin/init as init process
[21-41-33.668] [ 0.621317] UBIFS (ubi0:0): completing deferred recovery
[21-41-33.680] [ 0.753700] UBIFS (ubi0:0): background thread "ubifs_bgt0_0" started, PID 57
[21-41-33.680] [ 0.759538] UBIFS (ubi0:0): deferred recovery completed
我试了下f1c200启动模拟时钟也就1秒点,上电启动到显示也就3秒
挂载devtmpfs到/dev就行
又经过不懈的努力优化了内核IO性能,目前看上去从spinand启动开始到shell差不多1.9S左右。
感觉目前最大的瓶颈就在于这个128M的SPINAND的初始化和UBI扫描时间,做成只读压缩系统应该还能提高部分性能。
不知道大神们还有没有优化思路,目前感觉也就刚达到达神的状态。
[22-41-17.989] #
[22-41-17.990] [0]Shaoxi2010 f1c loader
[22-41-18.017] [15]DRAM: 64M
[22-41-18.017] [16]MMU:83ffc000
[22-41-18.017] [16]heap:82ffc000-83ffbffc
[22-41-18.564] [575] load: kernel 7528880
[22-41-18.588] [596] load: fdt 262144
[22-41-18.607] [597]start kernel at 0x80008000 fdt at 0x82ffc000!
[22-41-18.909] [ 0.278473] musb-sunxi 1c13000.usb: Invalid or missing 'dr_mode' property
[22-41-19.880] Starting syslogd: OK
[22-41-19.949] Starting klogd: OK
[22-41-20.164] Running sysctl: OK
[22-41-20.216] Starting mdev... OK
[22-41-21.135] modprobe: can't change directory to '4.19.223': No such file or directory
[22-41-21.258] Initializing random number generator: OK
[22-41-21.302] Saving random seed: OK
[22-41-21.488] Starting network: ip: socket: Function not implemented
[22-41-21.520] ip: socket: Function not implemented
[22-41-21.535] FAIL
[22-41-21.571] Starting telnetd: OK
[22-41-21.698]
[22-41-21.723] Welcome to Tiny200
[22-41-24.836] Tiny200 login: root
[22-41-24.862] login[114]: root login on 'console'
[22-41-27.198] # dmesg
[22-41-27.229] [ 0.000000] Booting Linux on physical CPU 0x0
[22-41-27.246] [ 0.000000] Linux version 4.19.223 (parallels@debian-gnu-linux-10) (gcc version 7.3.1 20180622 (release) [ARM/embedded-7-branch revision 261907] (15:7-2018-q2-6)) #86 Wed Jan 5 22:38:05 CST 2022
[22-41-27.257] [ 0.000000] CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=0005317f
[22-41-27.268] [ 0.000000] CPU: VIVT data cache, VIVT instruction cache
[22-41-27.268] [ 0.000000] OF: fdt: Machine model: Tiny200
[22-41-27.268] [ 0.000000] Memory policy: Data cache writeback
[22-41-27.277] [ 0.000000] On node 0 totalpages: 16384
[22-41-27.285] [ 0.000000] Normal zone: 128 pages used for memmap
[22-41-27.285] [ 0.000000] Normal zone: 0 pages reserved
[22-41-27.285] [ 0.000000] Normal zone: 16384 pages, LIFO batch:3
[22-41-27.296] [ 0.000000] random: get_random_bytes called from start_kernel+0x7c/0x3dc with crng_init=0
[22-41-27.303] [ 0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[22-41-27.303] [ 0.000000] pcpu-alloc: [0] 0
[22-41-27.312] [ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 16256
[22-41-27.318] [ 0.000000] Kernel command line: console=ttyS1,115200 loglevel=4 root=ubi0 ubi.mtd=4 rootfstype=ubifs cma=16M lpj=598528
[22-41-27.328] [ 0.000000] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
[22-41-27.335] [ 0.000000] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
[22-41-27.345] [ 0.000000] Memory: 58284K/65536K available (3740K kernel code, 216K rwdata, 1156K rodata, 1024K init, 210K bss, 7252K reserved, 0K cma-reserved)
[22-41-27.351] [ 0.000000] Virtual kernel memory layout:
[22-41-27.359] [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB)
[22-41-27.366] [ 0.000000] fixmap : 0xffc00000 - 0xfff00000 (3072 kB)
[22-41-27.374] [ 0.000000] vmalloc : 0xc4800000 - 0xff800000 ( 944 MB)
[22-41-27.374] [ 0.000000] lowmem : 0xc0000000 - 0xc4000000 ( 64 MB)
[22-41-27.381] [ 0.000000] modules : 0xbf000000 - 0xc0000000 ( 16 MB)
[22-41-27.388] [ 0.000000] .text : 0x(ptrval) - 0x(ptrval) (4733 kB)
[22-41-27.395] [ 0.000000] .init : 0x(ptrval) - 0x(ptrval) (1024 kB)
[22-41-27.395] [ 0.000000] .data : 0x(ptrval) - 0x(ptrval) ( 217 kB)
[22-41-27.401] [ 0.000000] .bss : 0x(ptrval) - 0x(ptrval) ( 211 kB)
[22-41-27.408] [ 0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[22-41-27.415] [ 0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[22-41-27.424] [ 0.000041] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 89478484971ns
[22-41-27.430] [ 0.000105] clocksource: timer: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 79635851949 ns
[22-41-27.437] [ 0.000495] Console: colour dummy device 80x30
[22-41-27.445] [ 0.000593] Calibrating delay loop (skipped) preset value.. 299.26 BogoMIPS (lpj=598528)
[22-41-27.452] [ 0.000621] pid_max: default: 32768 minimum: 301
[22-41-27.459] [ 0.000967] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[22-41-27.466] [ 0.000989] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[22-41-27.473] [ 0.001986] CPU: Testing write buffer coherency: ok
[22-41-27.473] [ 0.003627] Setting up static identity map for 0x80100000 - 0x8010003c
[22-41-27.481] [ 0.007842] devtmpfs: initialized
[22-41-27.488] [ 0.013759] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
[22-41-27.496] [ 0.013799] futex hash table entries: 256 (order: -1, 3072 bytes)
[22-41-27.496] [ 0.013960] pinctrl core: initialized pinctrl subsystem
[22-41-27.506] [ 0.015996] DMA: preallocated 256 KiB pool for atomic coherent allocations
[22-41-27.506] [ 0.038346] SCSI subsystem initialized
[22-41-27.513] [ 0.038635] usbcore: registered new interface driver usbfs
[22-41-27.520] [ 0.038765] usbcore: registered new interface driver hub
[22-41-27.528] [ 0.038877] usbcore: registered new device driver usb
[22-41-27.528] [ 0.039542] Advanced Linux Sound Architecture Driver Initialized.
[22-41-27.534] [ 0.040408] clocksource: Switched to clocksource timer
[22-41-27.542] [ 0.062174] NetWinder Floating Point Emulator V0.97 (double precision)
[22-41-27.550] [ 0.064725] workingset: timestamp_bits=30 max_order=14 bucket_order=0
[22-41-27.550] [ 0.091463] io scheduler noop registered (default)
[22-41-27.558] [ 0.091483] io scheduler mq-deadline registered
[22-41-27.566] [ 0.103702] suniv-pinctrl 1c20800.pinctrl: initialized sunXi PIO driver
[22-41-27.574] [ 0.126017] Serial: 8250/16550 driver, 8 ports, IRQ sharing disabled
[22-41-27.574] [ 0.130816] console [ttyS1] disabled
[22-41-27.583] [ 0.151098] 1c25400.serial: ttyS1 at MMIO 0x1c25400 (irq = 26, base_baud = 6250000) is a 16550A
[22-41-27.583] [ 0.151227] console [ttyS1] enabled
[22-41-27.594] [ 0.157964] panel-simple panel: panel supply power not found, using dummy regulator
[22-41-27.601] [ 0.158153] panel-simple panel: Linked as a consumer to regulator.0
[22-41-27.609] [ 0.159631] SCSI Media Changer driver v0.25
[22-41-27.617] [ 0.160716] sun6i-spinand 1c05000.spi: speed clock 100000000
[22-41-27.617] [ 0.160743] sun6i-spinand 1c05000.spi: fifo depth 64
[22-41-27.625] [ 0.161891] 5 fixed-partitions partitions found on MTD device (null)
[22-41-27.632] [ 0.161911] Creating 5 MTD partitions on "(null)":
[22-41-27.632] [ 0.161938] 0x000000000000-0x000000080000 : "spl"
[22-41-27.640] [ 0.163246] 0x000000080000-0x000000180000 : "u-boot"
[22-41-27.640] [ 0.163941] random: fast init done
[22-41-27.648] [ 0.165094] 0x000000180000-0x0000001c0000 : "dtb"
[22-41-27.655] [ 0.166166] 0x0000001c0000-0x0000007c0000 : "kernel"
[22-41-27.655] [ 0.172125] 0x0000007c0000-0x000007f80000 : "rootfs"
[22-41-27.655] [ 0.226417] random: crng init done
[22-41-27.663] [ 0.278046] usbcore: registered new interface driver usb-storage
[22-41-27.670] [ 0.278473] musb-sunxi 1c13000.usb: Invalid or missing 'dr_mode' property
[22-41-27.678] [ 0.285422] musb-sunxi: probe of 1c13000.usb failed with error -22
[22-41-27.685] [ 0.285759] udc-core: couldn't find an available UDC - added [zero] to list of pending drivers
[22-41-27.693] [ 0.285879] i2c /dev entries driver
[22-41-27.700] [ 0.288016] input: ns2009_ts as /devices/platform/soc/1c27000.twi/i2c-0/0-0048/input/input0
[22-41-27.708] [ 0.290071] sunxi-wdt 1c20ca0.watchdog: Watchdog enabled (timeout=16 sec, nowayout=0)
[22-41-27.716] [ 0.291507] sunxi-mmc 1c0f000.mmc: Linked as a consumer to regulator.1
[22-41-27.716] [ 0.318203] sunxi-mmc 1c0f000.mmc: initialized, max. request size: 16384 KB
[22-41-27.725] [ 0.320605] usbcore: registered new interface driver usbhid
[22-41-27.731] [ 0.320617] usbhid: USB HID core driver
[22-41-27.739] [ 0.323718] sun4i-codec 1c23c00.codec: ASoC: Failed to create component debugfs directory
[22-41-27.739] [ 0.327871] sun4i-codec 1c23c00.codec: Codec <-> 1c23c00.codec mapping ok
[22-41-27.749] [ 0.345837] sun4i-backend 1e60000.display-backend: Couldn't find matching frontend, frontend features disabled
[22-41-27.760] [ 0.346446] sun4i-drm display-engine: bound 1e60000.display-backend (ops 0xc04dbcc4)
[22-41-27.767] [ 0.347495] sun4i-drm display-engine: bound 1c0c000.lcd-controller (ops 0xc04dab74)
[22-41-27.775] [ 0.347520] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[22-41-27.782] [ 0.347527] [drm] No driver support for vblank timestamp query.
[22-41-27.782] [ 0.397668] Console: switching to colour frame buffer device 60x34
[22-41-27.793] [ 0.414385] sun4i-drm display-engine: fb0: DRM emulated frame buffer device
[22-41-27.800] [ 0.415472] [drm] Initialized sun4i-drm 1.0.0 20150629 for display-engine on minor 0
[22-41-27.808] [ 0.416570] ubi0: attaching mtd4
[22-41-27.808] [ 0.659808] ubi0: scanning is finished
[22-41-27.815] [ 0.670860] ubi0: attached mtd4 (name "rootfs", size 119 MiB)
[22-41-27.815] [ 0.670883] ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
[22-41-27.826] [ 0.670893] ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
[22-41-27.833] [ 0.670904] ubi0: VID header offset: 2048 (aligned 2048), data offset: 4096
[22-41-27.841] [ 0.670913] ubi0: good PEBs: 956, bad PEBs: 2, corrupted PEBs: 0
[22-41-27.848] [ 0.670923] ubi0: user volume: 1, internal volumes: 1, max. volumes count: 128
[22-41-27.856] [ 0.670936] ubi0: max/mean erase counter: 2/0, WL threshold: 4096, image sequence number: 1935136571
[22-41-27.865] [ 0.670946] ubi0: available PEBs: 0, total reserved PEBs: 956, PEBs reserved for bad PEB handling: 38
[22-41-27.865] [ 0.671300] of_cfs_init
[22-41-27.873] [ 0.671378] of_cfs_init: OK
[22-41-27.873] [ 0.671542] ALSA device list:
[22-41-27.880] [ 0.671555] #0: F1C100s Audio Codec
[22-41-27.888] [ 0.673152] ubi0: background thread "ubi_bgt0d" started, PID 53
[22-41-27.888] [ 0.698797] UBIFS (ubi0:0): recovery needed
[22-41-27.888] [ 0.741555] UBIFS (ubi0:0): recovery deferred
[22-41-27.898] [ 0.741775] UBIFS (ubi0:0): UBIFS: mounted UBI device 0, volume 0, name "rootfs", R/O mode
[22-41-27.909] [ 0.741797] UBIFS (ubi0:0): LEB size: 126976 bytes (124 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
[22-41-27.916] [ 0.741817] UBIFS (ubi0:0): FS size: 114659328 bytes (109 MiB, 903 LEBs), journal size 9023488 bytes (8 MiB, 72 LEBs)
[22-41-27.927] [ 0.741827] UBIFS (ubi0:0): reserved for root: 0 bytes (0 KiB)
[22-41-27.937] [ 0.741846] UBIFS (ubi0:0): media format: w4/r0 (latest is w5/r0), UUID 87713502-C622-4350-A244-286A7160446F, small LPT model
[22-41-27.944] [ 0.743048] VFS: Mounted root (ubifs filesystem) readonly on device 0:13.
[22-41-27.944] [ 0.743941] devtmpfs: mounted
[22-41-27.951] [ 0.748134] Freeing unused kernel memory: 1024K
[22-41-27.959] [ 0.748250] Run /sbin/init as init process
[22-41-27.959] [ 0.931684] UBIFS (ubi0:0): completing deferred recovery
[22-41-27.967] [ 0.956984] UBIFS (ubi0:0): background thread "ubifs_bgt0_0" started, PID 56
[22-41-27.967] [ 0.962054] UBIFS (ubi0:0): deferred recovery completed
怀疑没改drm驱动,这个Linux版本感觉接口不一样了
加logo主要是想验证下是压缩启动划算还是不压缩划算,目前看上去红利很小。
经过不懈的努力总算把loader给初步调试通了,目前从nand引导启动,测试波形发现上电到boot0运行
示波器发现约200ms,启动到loader后,目前加载kernel 4M 约278ms,解压logo图片使用lz4压缩
读取数据1.2M,解压后2.7M。目前cpu为600M、spinand为100M,使用双线读取,目前看上来spinand读取性能
在14.4M/s左右,解压缩折合为5M/s左右。实际主要还是慢在内核阶段,新编写load加载时间约300ms,
相当于uboot来说相同配置估计有几百ms提升,对整体启动约13s系统而言几乎没变化。时间上电到linux显示logo
用了接近2s左右,还是太慢了。目前内核不压缩在近10M,用空间来换速度差异不大,不知道大神们还有没有优化思路?
日志如下。
[0]Shaoxi2010 f1c loader
[15]DRAM: 64M
[16]MMU:83ffc000
[16]heap:837fc000-83ffbffc
[34] load: dtb ok
[480] decompress: logo ok
[758] load: kernel ok
[758]start kernel!
这个问题我找到原因了,还是自己迁移代码时将MMU的逻辑写错误了,反复对比汇编和ir发现逻辑行为不符合。
挂掉的原因应该是页表初始化问题,访问直接就异常了,目前通过qemu调试已经可以了等下实体机测试下就知道了。
考虑到启动需要解压缩和修改设备树信息,还是觉得优先打开cache要合理的多。
开MMU主要应对之前发现的两个问题
1. SRAM下栈变量和全局变量访问速度很慢,严重的拖慢了高频次操作
2. 不开启cache下DDR下的访问速度也是很难接受的
受到了论坛大佬帖子的启发,也想做个f1c200的快速启动loader看下能不能尽快启动系统。
最近在学习rust,所以正好使用rust来练练手,也算增加点新血液吧。
由于rust没有发现带armv5的target目标,这里就用了下armv5te-unknown-linux-gnueabi的目标。
由于后端链接使用的是arm-none-eabi,所以基本上只用cargo管理项目,rust生成中间代码,gcc生成汇编和C程序
最后用gcc链接便可运行。
目前只实现了最简单的led点亮,和串口输出功能。
内存初始化代码,借用xboot大佬代码使用ffi实现,mmu等参照从写。
目前用release版本大约在3.4k,还是能满足基本,rust抽象还是相当爽的。
目前遇到一个问题,小弟实在没看出来哪里有毛病,系统在初始化mmu后直接跑飞了,我用反汇编看了
实在没看出哪里有毛病。求大神指点迷津,没思路了。
pub fn turn_on(&self) {
mmu_ttb_set(self.base);
mmu_inv_tlb();
mmu_domain_set(3);
mmu_enable();
crate::led_on(); //这里执行不到了
icache_enable();
dcache_enable();
}
源代码项目:https://github.com/shaoxi2010/loader
是我的描述不太清楚,一个是我想知道你打印里面有个brom时间,这个是怎么算出来的?第二就是bootloader拉起内核时间是多少呢,想看下和uboot相比有多大的优势。
太强了,想问下重写后bootloader花了多少时间呢?
谢谢大佬分享,想请教一个问题,auto_set_timing_para这个函数里面的ddr参数时怎么一个个对应起来的呢?
看起来像参照的主线uboot的代码,不知道能不能分享下思路呢?
看起来就像启动成功了一样,安卓这块不熟,是不是分区卷标这些不对
而且init报错是没找到挂载吧,看上去也和NAND无关。
[ 11.482002] init: Failed to mount required partitions early ..
[00.771]workmode = 0,storage type = 2
从日志上来看他就没有从nand启动,而是从emmc上启动的,你确定有nand?还是全志不支持这个nand?
你这个有没有NAND哦,把日志打全嘛
在哪买得到呢?
今天遇到一个很神奇的现象,在A133下QT5的EGLFS在绘制静态画面时,会无法显示出来,必须要点一下触发绘制事件后才能
正常的显示,这个问题我记得之前在全志的A64上同样也遇到过,不知道是EVENT少了个,还是双缓冲切换的有问题,有大佬
遇到过同样的问题么?
device没记错是写入2,然后内核打开CDC组件就行了
linux上有ethtool接口可以直接看到link状态
嵌入式的Qt5是全屏应用,没得标题栏,要么打开window manager要么用回qt4
缺少了gstreamer组件吧,也有可能是dbus的权限不对
USB端子不够了,中间有HUB就去掉HUB,还不行连到电脑看看到底需要多少个端子
很有意思啊,我还有个疑问,大佬时怎么推测出这些符号的呢?很想了解下这个重构elf的过程,我试了下ghidra目前无法打开riscv的bin文件,但是可以打开elf文件,大佬能分享思路或者过程下不?
D1 BROM ELF版本
blob.zip
好奇这个ELF版本是在那里找到的,大佬能指点下么?
再不行就强制指定为SDR50看下
看起来不像内核配置问题,uboot识别很正常呢,不过有点奇怪A33的emmc应该是8线的但是你的只有四线模式,
你把内核的sys_config也改为4线试下吧。
你用的主线驱动吧,这个问题我遇到过,他们BSP是有个失败重试机制,重置一下控制器就好了,主线的驱动缺少了这部分就会卡在这。
将重试逻辑移植到主线上也能解决这个问题的。
大神,这个能在macOS下编译一个么,试了下NEMU但是无法编译出可以在用户态下运行的程序
感觉不太可能啊,双LVDS分奇偶信号啊,输入感觉都不够
启动时单线的,uboot也是单线的,主线linux也是单线的,但是linux有patch可以打开双线读取模式
>ns2009这破玩意,就不是给人用的。
楼主是遇到啥坑了吗?有没避坑经验?
1块钱的小玩意要求不要太高了,主要就遇到几个坑,目前都转xpt的芯片了:
1. 中断管脚状态会乱触发,按不按有时都有中断,可以用轮询实现
2. 它的adc不稳定会出现偶发性很大的抖动,这个勉强通过滤波可以解决
3. 最致命的还是力度不够的时候,它的压力值和采样都不准,建议不踩压力
4. 我试过xyz,yzx等顺序,嗯从波形上看它就很夸张,也并没有解决任何问题,好像xpt的芯片采样顺序对结果影响很大
没用过这么大的,128M的我这很正常
不太现实,我记得那对库都有接近100M去了
顺带一提的是,当编译选择位32位的时候是没有问题。
gcc main.c test.c -m32 -lrt -lpthread
更加印证了上述的逻辑。
很感兴趣的问题,拿着楼主的代码仔细的走了走发现这个问题其实还是编译器对未声明的函数默认状态处理的问题。
当函数不存在声明的时候,应该默认为int func(void)作为函数的状态的,这个可以通过调用约定和反汇编看到,只存在rax返回值,且默认还清零了。
故gcc将这个64位地址截断为32位的int值再拓展到了64位上去了,这才是后面段错误的核心原因。
看来这种不明显的警告很多时候还是非常危险,应该多确认下是否有异常。
1. 通过gdb进入到getpshm函数内,打印data地址信息,发现该地址是个正确地址
(gdb) p data
$3 = 0x7ffff7ffb000 '\377' <repeats 20 times>
2. 手动将程序执行到程序的末尾位置,打印返回值寄存器信息。此时返回值是一个正常的状态
(gdb) info registers eax
eax 0xf7ffb000 -134238208
(gdb) info registers rax
rax 0x7ffff7ffb000 140737354117120
3. 继续程序执行,完成函数,打印返回值寄存器信息,此时异常已经发生。
(gdb) info registers rax
rax 0xfffffffff7ffb000 -134238208
(gdb) info registers eax
eax 0xf7ffb000 -134238208
4. 继续执行到memset时,该地址空间处于不可访问空间地址,写操作必然崩溃而引起segment fault。
(gdb) disassemble
Dump of assembler code for function subthread:
0x0000555555555249 <+0>: endbr64
0x000055555555524d <+4>: push %rbp
0x000055555555524e <+5>: mov %rsp,%rbp
0x0000555555555251 <+8>: sub $0x20,%rsp
0x0000555555555255 <+12>: mov %rdi,-0x18(%rbp)
0x0000555555555259 <+16>: mov $0x0,%eax
0x000055555555525e <+21>: callq 0x555555555312 <getpshm>
=> 0x0000555555555263 <+26>: cltq //cltq指令,特指%eax->%rax的符号拓展转换,等价于movslq %eax,%rax
0x0000555555555265 <+28>: mov %rax,-0x8(%rbp)
0x0000555555555269 <+32>: lea 0xd94(%rip),%rdi # 0x555555556004
0x0000555555555270 <+39>: callq 0x5555555550e0 <puts@plt>
0x0000555555555275 <+44>: cmpq $0x0,-0x8(%rbp)
0x000055555555527a <+49>: je 0x55555555529e <subthread+85>
0x000055555555527c <+51>: mov -0x8(%rbp),%rax
0x0000555555555280 <+55>: mov $0x14,%edx
0x0000555555555285 <+60>: mov $0xff,%esi
0x000055555555528a <+65>: mov %rax,%rdi
0x000055555555528d <+68>: callq 0x555555555120 <memset@plt>
0x0000555555555292 <+73>: lea 0xd7e(%rip),%rdi # 0x555555556017
0x0000555555555299 <+80>: callq 0x5555555550e0 <puts@plt>
0x000055555555529e <+85>: mov $0x1,%edi
0x00005555555552a3 <+90>: callq 0x555555555150 <sleep@plt>
0x00005555555552a8 <+95>: jmp 0x55555555529e <subthread+85>
End of assembler dump.
你用tty驱动啊,那个你插入多少个都行
其实最有效的方法就是去查看驱动的probe函数,看看他往那里注册的。毕竟有些有有些也没有,这个只能看驱动。
sht3x.c:
hwmon_dev = devm_hwmon_device_register_with_groups(dev,
client->name,
data,
attribute_groups);
ad799x.c:
ret = iio_device_register(indio_dev);
ts2007.c:
err = input_register_device(input_dev);
看看模块所属的框架位置,去寻找对应的操作操作手段就行了,例如这玩意就是在hwmon下,应该通过sys就能读取
为什么海思要特意把yaffs2加进来,是ubifs不稳定?
ubifs对硬件是有要求的,他是假设了某些硬件场景下是不会出异常的,比如flash的页面不写入或者不擦就不应该出现异常,或者信号问题指令执行错误等,所以他在扫描过程中只用了表头文件,内容错误是发现不了的,如果硬件异常可能会整个崩溃,yaffs这点不一样,这个是能校验的都校验,在最大程度上去避免异常,所以yaffs的鲁棒性要好很多。毕竟也不知道大家的硬件设计能力,还不如保险点,而且在128M以下两个真的没什么明显的差距,最大的缺陷应该是在yaffs的均衡算法,由于他没有历史数据,所以反复重启的情况下,前面块的寿命可能较快达到上限。
下载要积分啊,用readelf看看运行头对不对,这个感觉就是工具链错了
这部分是实现dts的修改
cp sys_config.fex sys_config2.fex
sed -i "s/\(\[dram\)_para\(\]\)/\1\2/g" sys_config2.fex
sed -i "s/\(\[nand[0-9]\)_para\(\]\)/\1\2/g" sys_config2.fex
${RUN_DIR}/bin/dtc -@ -O dtb -o ${2} \
-b 0 \
-F sys_config2.fex \
-I dts \
${1}.pre
这个就是这部分实现了uboot和boot0修改
printf "update bootloader\n"
update_boot0 boot0_nand.fex sys_config.bin NAND > /dev/null
update_boot0 boot0_sdcard.fex sys_config.bin SDMMC_CARD > /dev/null
#update_boot0 boot0_spinor.fex sys_config.bin SDMMC_CARD > /dev/null
update_fes1 fes1.fex sys_config.bin > /dev/null
update_uboot -no_merge u-boot.fex sys_config.bin > /dev/null
然后影响boot和uboot是通过update_boot0和update_uboot修改了二进制head部分的二进制,从而影响到串口输出
这个你可以看看内核下的script的dts程序源码,全志在其基础上修改了源码,添加了一个参数-F专用于修改sysconfig到dts上去
跑个linux不就行了,A133的linux驱动基本很完善,opengl都有
楼主用的RGB还是MIPI啊,我这个感觉在高频下RGB信号不稳定,时钟会变不晓得是那的问题
大佬,同样的思路我在R818上试了下,有个段错误啊有没有什么思路
# gst-launch-1.0 filesrc location=2.mp4 ! qtdemux ! h264parse ! omxh264dec ! aut
ovideoconvert ! fbdevsink
Setting pipeline to PAUSED ...
debug : cedarc <AwOmxComponentInit:38>:OMXCORE: aw_omx_component_init 27d7f5e0
debug : omx_vdec <__AwOmxVdecInit:1139>:++++++++++++++++++++++omx begin++++++++++++++++++
debug : omx_vdec <__AwOmxVdecInit:1140>:name = OMX.allwinner.video.decoder.avc
debug : cedarc <CdcMessageQueueCreate:51>:nMessageSize = 40
debug : cedarc <AwOmxComponentSetCallbacks:331>:OMXCORE: aw_omx_component_set_callbacks 27d7f5e0, 9b650958 , 27e2b
3b0
debug : omx_vdec <__AwOmxVdecSetCallbacks:1890>:===== vdec set callbacks
Pipeline is PREROLLING ...
debug : omx_vdec <AwOmxVdecPortSetDefinitioin:191>:port:<<<<<<<<in,nBufferCountActual = 2, mBufferCntActual = 2
debug : omx_vdec <AwOmxVdecPortSetDefinitioin:191>:port:<<<<<<<<in,nBufferCountActual = 2, mBufferCntActual = 2
error : omx_vdec <AwOmxVdecPortGetFormat:280>:erro: pParamData->nIndex > m_sPortFormatType.nIndex
debug : omx_vdec <controlSetState:419>:current state:OMX_StateLoaded, target state:OMX_StateIdle
debug : omx_vdec <doStateWaitforResources2Idle:629>:bEnabled[1],[1],bPopulated[0],[0]
debug : omx_vdec <AwOmxVdecPortAddBuffer:390>:<<<<<<<<in port add buffer: 0x7f99135010
debug : omx_vdec <AwOmxVdecPortAddBuffer:390>:<<<<<<<<in port add buffer: 0x7f98b34010
Caught SIGSEGV
debug : omx_vdec <doStateWaitforResources2Idle:629>:bEnabled[1],[1],bPopulated[1],[0]
exec gdb failed: No such file or directory
debug : omx_vdec <doStateWaitforResources2Idle:629>:bEnabled[1],[1],bPopulated[1],[0]
Spinning. Please run 'gdb gst-launch-1.0 1101' to continue debugging, Ctrl-C to quit, or Ctrl-\ to dump core.
debug : omx_vdec <doStateWaitforResources2Idle:629>:bEnabled[1],[1],bPopulated[1],[0]
....
debug : omx_vdec <doStateWaitforResources2Idle:629>:bEnabled[1],[1],bPopulated[1],[0]
warning: omx_vdec <doStateWaitforResources2Idle:644>:Idle transition failed
warning: omx_vdec <controlSetState:449>:Transit current state:OMX_StateLoaded --> target state:OMX_StateIdle --Fail
ed!
和v3s一模一样,改下uboot就能用了,用A33的内存初始化就好了
翻墙挂代理基本操作
rom boot阶段能打印log吗
shaoxi2010 说:串口我记得不是suart吧,有有可能是sysconfig的debug属性没开吧,按理应该打印当前的内存配置信息
能打印的,我直接诶找的代理帮忙调试的,他们发过来的安卓能看到
串口我记得不是suart吧,有有可能是sysconfig的debug属性没开吧,按理应该打印当前的内存配置信息
可以改成自动识别试一下,看你那内存测试是能通过的原理上应该不会有问题,就是不小的你选的那个内存配置对的上不,原则上只要能下载fes0也是会有打印的,可以接上串口看看
我记得SDK本身就不会黑啊
int sun4i_framebuffer_init(struct drm_device *drm)
{
int ret;
drm_mode_config_reset(drm);
drm->mode_config.max_width = 8192;
drm->mode_config.max_height = 8192;
drm->mode_config.funcs = &sun4i_de_mode_config_funcs;
drm->mode_config.helper_private = &sun4i_de_mode_config_helpers;
ret = drm_fb_cma_fbdev_init(drm, 32, 0); //这里改到24或者16就行
return ret;
}
没写reg吧,drm加载的时候simplefb会自动卸载的
有个专门做这个的程序叫ifplugd,busybox内提供了,可配合ifup一起,很符合楼主要求
我记得可以用的,但是有点问题,brom代码并不是标准的SPINAND模型,软重启可能出现片选切换问题,无法正常启动
坑网积分还有这种功能,海景房又近了点
可能就是运气撇,DRAM就是有问题,这个现象上量还是很常见的
内核代码有问题,你得改改代码,内核极性配置不一样,你对下寄存器就知道了。
lvds本来就是差分信号嘛,是不是时钟配置这些不对吧?
就是使能这个选项就对了
理论上内核修改代码就可以,uboot应该可以直接支持,你可以试下
纯理论上应该是可以的,主线的A33确认修改后是ok的,A64应该也可以
你看看调试信息麻,写的很清楚,这个肯定找不到阿,要仔细点。
m25p80 spi0.0: mx25l25635e (32768 Kbytes)
mtdid=<spi32766.0> num_parts=<6>
QTAV啥都有了
应该不会啊,你有选择镜像么?