Nand Flash本地加载根文件系统后telnet不能登录

本文介绍了一种在更新内核后遇到的telnet登录失败的问题及其解决方案。通过对比旧内核的行为并检查设备文件和权限配置,最终解决了无法通过telnet远程登录的问题。
问题:

目标板中的bootstrap、U-Boot、根文件系统和内核都升级到新的版本中,并且已经通过Nand Flash本地成功加载根文件系统。

但是,在主机的terminal窗口中,不能通过telnet方式登录目标板,而目标板中已经把telnet服务启动了。

dingq@dingq-u1204:~$ telnet 192.168.37.244
Trying 192.168.37.244...
Connected to 192.168.37.244.
Escape character is '^]'.
Connection closed by foreign host.
dingq@dingq-u1204:~$
提示无法通过telnet连接到目标板。

解决办法:

1. google这段时间老是抽风,一天当中没有多少时间能用的。没办法,只好放狗去搜了。

首先有高手说,使用命令

telnet localhost
或
telnet 127.0.0.1
来验证一下telnet服务安装是否正确,如果本机上telnet自己能正常连接,说明telnet服务的安装正确。

2. 在不能telnet登录的目标板上使用命令

telnet 127.0.0.1
出现如下提示:

/ # telnet 127.0.0.1
telnet: cannot connect to remote host (127.0.0.1): Connection refused
/ #
3. 找一台使用原来内核的目标板,通过Nand Flash本地加载根文件系统进入shell界面后,使用命令

telnet 127.0.0.1
可以成功跳出登录界面,登录成功后使用exit命令退回到console界面。
4. 两相对比,说明烧写新的内核的目标板上的telnetd工作不正常。

《构建嵌入式linux系统》一书中,设置网络服务->使用Telnet进行网络登录->常犯的错误一节中提到,如果已经执行了telnet监控程序并且可以网络运行正常(可以ping到其他主机),需要确认以下操作:

××××存在/dev/ptmx,而且ptmx是以主编号为5、次编号为2的字符设备;如果不是,使用命令

mknod /dev/ptmx c 5 2
来建立它。
××××内核已经启用对devpts虚拟文件系统的支持(也就是/proc/filesystems文件中存在devpts的项目);如果不是,需要启用CONFIG_UNIX98_PTYS这个内核构建选项;

××××存在/dev/pts目录,而且devpts虚拟文件系统被正确挂载(检查mount命令的执行结果);如果不是,使用如下命令来挂载它:

mkdir /dev/pts && mount -t devpts none /dev/pts
5. 根据4中所述,检查/dev目录下的文件,发现没有ptmx文件,所以,在rcS启动脚本中加入下面一行

/bin/mknod /dev/ptmx c 5 2
再次重启目标板,使用命令telnet来登录自己就可以跳出登录界面了。

但是,还有问题。使用root登录时,用空输入作为密码来登录总是不能进入。

6. 到烧写原来内核的目标板中查了以下,发现/etc目录下有这么几个文件,passwd、shadow和group。

将这三个文件通过tftp上传到/tftpboot,然后再下载到新的目标板中的/etc目录,重启新目标板,能够成功使用telnet登录自己。

在开发主机的terminal窗口能成功登录进目标板。

至此,问题解决。




2.软件分析 2.1.问题描述 2025年3月期间,在中电星河本部通过反复上下电数台A2主板成功复现C6678 Linux系统版本接收机FPGA启动失败遗留问题,接收机指示灯与上位机工作状态灯均出现红色告警,接收机FPGA未正常启动。连接telnet后,输入dmsg指令查看Linux系统日志,发现接收机上电时Mount挂载NandFlash文件系统过程中报Check Error告警,文件系统在接收机上电启动时未能正常mount挂载,导致NandFlash中的FPGA1.bin、FPGA2.bin、FPGA3.bin程序文件无法加载成功。 待Linux系统正常启动后,手动输入start.sh脚本中的"time mount -t jffs2 -0 sync/dev/mtdblock5/nand_disk/ "指令,NandFlash文件系统正常挂载,通过FTP获取该故障NandFLash中的FPGA1.bin、FPGA2.bin、FPGA3.bin镜像文件至PC本地,并对比其正常程序文件,发现部分镜像文件的二进制数据在不同地址段出现损坏。 一开始以为上述故障现象与接收机下电/上电存在强相关关系,且偶发出现,综合该类型接收机NandFlash历史故障信息及公司的复现情况,得出如下初步结论:接收机硬件上下电过程与该故障复现存在相关性;软件上可针对Linux系统启动过程进行优化。 采取的解决措施包括:a)在C6678 EMIF初始化与NandFlash 驱动加载命令行前增加3s延时,规避上电过程中的不稳定状态阶段。b)将与NandFlash相关命令行间增加少量,在写保护操作前、jffs2文件系统挂载前分别增加3s延时,在拷贝FPGA镜像文件前、卸载jffs2前增加1s延时,避免Linux非实时性操作问题。 在上述优化后,降低了出错概率但是多台设备长时间上下电仍然还会存在偶发文件损坏现象,且最新测试发现在系统软复位(不限于上下电)过程中也出现该问题。出现该问题的过程Linux端会稳定的伴随报错:JFFS2 notice:(123)check_node_data:wrong data CRC in data node at 0x05be2e1c:read 0x3005c91d,calculate 0x9ceec087。因此本次软件排查主要从内核层面进行分析,主要是从以下2个方向入手:a)Nand Flash挂载的根文件系统格式;b)Nand Flash的驱动; 2.2.问题定位 2.2.1.故障树 接收机上电或软复位后,FPGA镜像自Nand Flash加载失败。故障树顶层为“Flash内文件损坏”。向下分三支:一、EMIF接口时序参数与硬件不匹配,读采样窗口偏移,引入位翻转;二、ECC策略强度或布局与实际Flash位错率不符,未能纠正错误;三、写保护机制缺失,复位过程中总线乱写,将垃圾数据写入镜像块。系统层JFFS2在EMIF尚未稳定、电源噪声尚存时过早挂载,进一步放大了上述底层错误,最终表现为CRC校验失败、镜像失效。若改用UBIFS,其自带更强CRC与日志恢复,可在同等硬件缺陷下仍保持挂载成功。因此,应从同步修正EMIF时序、提升ECC等级、启用 early-write-protection、延后文件系统挂载四点着手,切断故障链。 图 4 软件故障树 2.2.2.实验定位 根据故障树描述,顶层问题有两个定位方向。为进一步对定位方向进行判断,设计以下实验。 1.实验一 实验目的 当程序异常时,手动将Nand Flash挂载成jffs2格式,看是否能挂载成功,验证JFFS2映像是否损坏? 实验操作 每次出现异常时,手动挂载一次Nand Flash,连接telnet df -h查看挂载情况。 测试结果 每次df -h查看是仍能挂载分区,且还能正常往Nand Flash里读写数据,则JFFS2映像未损坏 2.实验二 实验目的 将与NandFlash相关命令行间增加延时、jffs2文件系统挂载前分别增加延时,在拷贝FPGA镜像文件前、卸载jffs2前增加延时,保证emif稳定后进行Nand Flash挂载,然后进行压力测试,验证是否emif初始化未稳定挂载导致的CRC错误? 实验操作 进行长时间压测后查看Nand Flash文件是否出现损坏。 测试结果 长时间压测后,7台设备中仍偶发文件损坏现象,则不是该原因导致。 3.实验三 实验目的 尝试将Nand Flash不进行文件系统的挂载,直接对Nand Flash进行递增数数据流的读写压测,验证是否由挂载格式导致的数据损坏还是纯Nand Flash驱动导致的数据损坏? 实验操作 1)修改自启动脚本,屏蔽jffs2格式的Nand Flash挂载,增加nandtest指令进行全盘范围的读写测试; 2)测试结束后每1分钟进行一次系统软复位:reboot; 3)每次将读写测试结果进行计数记录,正确或异常分别存储到相应的技术文本中。 4)7台设备同时开始压测 修改的脚本内容如下: #Nand Flash读写测试 ERR_FILE="/nor_disk/err_nct.txt" [ -f "$ERR_FILE" ] && ERR_CNT=$(cat "$ERR_FILE") || ERR_CNT=0 RIGHT_FILE="/nor_disk/right_nct.txt" [ -f "$RIGHT_FILE" ] && RIGHT_CNT=$(cat "$RIGHT_FILE") || RIGHT_CNT=0 NANDTEST_LOG="/tmp/nandtest.log" MOUNTNAND_LOG="/tmp/mounttest.log" nandtest -p 1 -k -l 0x8000000 /dev/mtd5 >"$NANDTEST_LOG" 2>&1 # 判断本次是否出现 compare failed if grep -q "compare failed" "$NANDTEST_LOG"; then ERR_CNT=$((ERR_CNT + 1)) echo "$ERR_CNT" > "$ERR_FILE" sync # 立即落盘,防掉电 fi if grep -q "Finished pass 1 successfully" "$NANDTEST_LOG"; then RIGHT_CNT=$((RIGHT_CNT + 1)) echo "$RIGHT_CNT" > "$RIGHT_FILE" sync # 立即落盘,防掉电 fi 测试结果 7台设备中由3台设备出现,读写不一致的测试结果,且每次异常的时候查看日志打印,发现读写的数据会出现1位翻转的错误。截图如下: 通过以上3个实验可初步定位,Nand Flash的文件损坏基本与jffs2格式文件系统挂载无关,与Nand Flash的驱动强相关。 2.2.3.驱动对Nand Flash的影响 从故障树得知:Nand Flash驱动对文件读写的影响主要包括几部分: EMIF 初始化:把 C6678 的 External Memory Interface 寄存器(A1CR、A2CR、时钟分频、TA、hold/setup 等)配成与 NAND 颗粒 tRC/tWC/tWP/tREH 完全匹配的时序,同时打开 WAIT 握手或关闭延长,保证总线采样窗口落在数据有效区。 ECC 策略:在页写时实时计算校验码,页读时纠错并上报 bit-flip 数量;同时把 syndrome 放到约定 OOB 偏移,避免与坏块标记、文件系统内部标记冲突。 写保护:通过 GPIO/WP# 引脚或 on-die 写保护寄存器,在复位、电源抖动、软件跑飞期间把 PROGRAM/ERASE 命令屏蔽掉,确保代码区、BBT、环境变量等关键块不被误改。 为进一步对定位方向进行更精准判断,尝试以下实验。 1.实验一 实验目的 走查C6678手册和现有驱动代码的emif初始化部分代码,针对时序优化后,进行压力测试,验证emif初始化是否异常? 实验操作 每台设备加载新的驱动,然后进行上下电压力测试,查看Nand Flash文件是否出现损坏。 测试结果 长时间压测后,7台设备中仍偶发文件损坏现象,则不是该原因导致。 2.实验二 实验目的 走查c6678的手册、Nand Flash的手册MT29F1G16ABBDAH4 128MB NandFLash手册,验证ECC策略是否正确? 实验操作 走查手册与NandFlash驱动ECC部分代码,发现NAND 的 ECC 需求(≥4-bit)≫EMIF16 硬件能力(1-bit),现有驱动中用的4-bit的硬件ECC,但是C6678的EMIF16并不支持该硬件ECC策略。 测试结果 比对手册和代码发现ECC策略不匹配。 针对写保护异常问题,硬件上通过IO控制Nand Flash,仍会出现该问题,基本可排除写保护的相关影响。通过以上两个实验及分析可知,目前问题可基本定位为Nand Flash的驱动ECC策略存在问题。 2.2.4.总结 通过系统化的实验验证与故障树分析,已将 FPGA 镜像加载失败的根本原因锁定在 NAND Flash 驱动层 ECC 策略配置错误。实验表明,文件损坏与 JFFS2 文件系统挂载无关,而是纯 NAND 驱动在读写过程中引入的位翻转未被有效纠正所致。进一步比对 C6678 EMIF16 控制器手册与 MT29F1G16ABBDAH4 NAND Flash 规格确认,EMIF16 硬件仅支持 1-bit ECC,而当前驱动启用了硬件4-bit ECC 策略,存在能力失配,导致纠错失败、数据静默损坏。EMIF 时序优化与写保护机制排查未显著改善问题,进一步佐证 ECC 策略为关键缺陷点。后续应将 ECC 策略降级为 1-bit,并启用软件 ECC 补充或多页冗余校验机制,最终需从驱动层彻底修正 ECC 实现,切断故障链,确保镜像加载可靠性。根据上述文字定位出的问题,给出一段机理分析
最新发布
11-05
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值