- 博客(10)
- 收藏
- 关注
RSS订阅原创 select函数延时机制的一些探索
如图中代码所示usleep 10000 us 延时使得select函数有时间更新readfds集合中套接字状态值，原先使用的是MUL_PRINTF打印函数，歪打正着产生延时效果，后干脆使用usleep延时函数果然可以，也就是说selcect监听套接字集合，并不是同时产生检测到它们的状态变化，A套接字有消息，还要过一段时间才能检测到B套接字是否有消息，延时一会，才能用FD_ISSET(g_Multicast_test.broadcast_fd[i], &readfds)准确判断该套接字的状态。
2024-04-22 17:18:06
175
原创 UBI 文件appfs文件系统升级的实现过程
所以我加了sleep 10 等待10s再执行，但是只能减少挂载失败的概率。睡眠时间越长挂载失败的概率越低。但是还是不能杜绝这种现象发生。最近在将appfs的ubi文件系统更新挂载在nandflash的mtd4分区,琢磨的出来的指令如下。要想完全杜绝这种现象需要重启，重启之后没有该设备的挂载的信息，这样就可以避免卸载失败的现象。但是上面那部分指令有个问题，在嵌入式软件上执行的时候卸载指令的时候会出现下面这种情况。上面的指令只能作为参考，读者在应用启动脚本的烧写指令时候需要某些逻辑调整。
2023-11-13 19:05:56
227
原创 UBI mount：mounting /dev/ubi0_1 on /mnt/apps on /mnt/apps failed: No such file or directory 这种问题解决办法
对ubi0_0挂载的ubi0:rootfs 文件内容进行一些读写操作后，比如cp /mnt/apps/config到/etc/当中，再进行软件升级操作，再按照步骤1进行操作，再启动时没有发现出现这个现象。前一段时间我做了ubi 文件系统，可是升级软件文件后，也就是将/mnt/apps里面的文件全部用cp指令拷贝新的同名文件覆盖旧的同名文件、便出现上图这种情况。1、2步骤操作20多次后，系统挂载文件系统的时候并没有出现上图的状况了。2、后来没有出现这种情况了 ，升级了五六次又重新出现上图这种事情了。
2023-10-24 14:28:39
267
原创 chipselect 0 already in use 这种问题的解决思路
刚开始以为是linux 内核代码出了问题，里面有bug，后来换了一个版本的内核源码，发现没有这个问题，确定硬件没有问题，并且给旧的源码更换了正常运行的内核的sun8i-v3s-licheepi-zero.dts，结果还是出现设备树文件 chipselect 0 already in use这个错误,于是钻研了很久，以为chipselect 0 该设备已经被占用，肯定是设备树出了问题，内核在启用驱动设备的过程中已经占用了chipselect 0。打印没有加成功，加上有别的事情这个问题就先挂着了。
2023-08-07 16:03:23
481
原创 jffs2_scan_eraseblock(): Magic bitmask 0x1985 的解决办法
于是尝试将menuconfig 中的 Device Drivers > Memory Technology Device (MTD) support > SPI-NOR device support->Use small 4096 B erase sectors 选项取消选中，将[*]改为[ ]，如下图。在网上找了很多网页资料，这是由于flash 不支持4k块擦除导致的，需要在spi-nor.c中将。最近在给V3S的flash烧录jffs文件系统镜像结果出现了如下图所示这种打印。
2023-07-06 18:55:22
1105
1
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人