自编译猫盘u-boot，解决掉IP

mynetdisk 发表于 2022-4-27 01:52
刷这个成功迁移并进入群晖
# y0 |1 Y/ }3 r6 w% T
可惜重启后又出现卡 Starting kernel ... 问题

哦，那应该是因为emmc引导顺序在群晖之前，但是群晖的u-boot提供的设备树与Linux不兼容。
9 B( ]" {' X* G; m$ j8 }. G7 h0 ^! b你把emmc中的Debian抹掉就好了。

2 w2 t% U& i/ Y! ?5 V$ a

fhh 发表于 2022-4-27 08:04
哦，那应该是因为emmc引导顺序在群晖之前，但是群晖的u-boot提供的设备树与Linux不兼容。
你把emmc中的De ...

谢谢 F 大
0 l9 x% N8 G# u我前面没描述清楚，我的情况是这样：

: }/ L" U' [& |" @1.
启动时 TTL 默认显示 syno mode，然后在 Starting kernel ... 卡住
( O7 ?+ r; e9 p' g按住 RESET 5S 上电启动 TTL 显示 mmc mode，能正常进 Debian
- N. l' N( D/ H0 l2 q
+ U# G2 {# ~& N" I2.
% ?9 T: V* a6 |1 Q刚刷 u-boot 之后可以进群晖（也有一次刚刷完 uboot 就进不了群晖）
之后某次重启后 syno mode 就卡在 Starting kernel ...（但 mmc mode 仍然可以进 debian）
+ U3 O) D  P* J一旦出现卡 Starting kernel ...，再重启 N 次也还是卡 Starting kernel ...，直到下次刷 uboot 通常可以暂时解决
* I$ g, U: D# H' \, p1 d
3.
一次 saveenv 后重启卡 Starting kernel ...，以为跟这个有关，之后试验排除了此可能【2022-04-29 修订：我又不确定了，今天试了刷 uboot 重启几次正常启动群晖的情况下，saveenv 后重启就卡 Starting kernel ... 了，也许真像你说的是 uboot 分区表有问题（从而导致 saveenv 破坏了什么东西？）】
9 q! G6 o/ T7 T一次进 debian 后重启卡 Starting kernel ...，以为是 debian 自动修改了 uboot 环境变量，之后试验排除了此可能
( c  X8 }. z3 b0 |2 J+ {U盘、硬盘都拔掉试过，排除了这两种设备问题的可能

mynetdisk 发表于 2022-4-27 09:13
谢谢 F 大
我前面没描述清楚，我的情况是这样：

) a, m' U! K& y; q7 K, G3 i看上去像是u-boot中分区表配置错误，或者是你的spi nor flash出现了故障。
" m. V( J0 p9 g3 l- t3 |+ z6 t我想询问一下：
. {) I/ |' D- Q# X) F1.在刷我修改之前的u-boot之前（也就是在使用Soul的U-boot的时候），你会遇到这个情况吗？
8 g/ q0 o. ?. m2.在你卡在Starting kernel的时候，还能够进入emmc环境下的Debian吗？如果能，请问你能够在Debian下把spi flash的数据读取出来，以分析一下是否出现了错误吗？
如果可以的话，请提供一下无法正常启动时期的spi nor flash的备份镜像(应该是/dev目录下的各个mtdblock，以及/proc/mtd分区表)，我需要根据这些信息进行分析。
谢谢！

fhh 发表于 2022-4-27 10:15
看上去像是u-boot中分区表配置错误，或者是你的spi nor flash出现了故障。
4 r" B. S5 o/ @  f5 [我想询问一下：
" L/ `9 `2 u6 `8 R% A$ X9 b: u1.在刷我修改之 ...

看上去像是u-boot中分区表配置错误
, m& c- F% G3 S0 [. F% y7 ~  k--- 应该不是，因为并不是换了 uboot 之后出现卡 Starting kernel ... 问题，刚刷 uboot 后通常可以用，第 N 次重启之后可能出现 Starting kernel ...，之后再重启也必然这样，只能重新刷 uboot（注：不代表一定是 uboot 这里出了错，因为每次重刷 uboot 后需要重装群晖 DSM，所以也可能是因为重装 DSM 而暂时解决了问题）
1 B) O8 K: j2 k- w7 Q1 Q% m
或者是你的spi nor flash出现了故障
* ]! b- z7 ]) _& v* q, ]--- uboot bubt 命令刷写 SPI FLASH 后会不会校验呢，如果有校验，证明 FLASH 本身读写应该没问题，而是否后续 FLASH 数据出问题待确定
7 o2 x& @6 R( N6 ]+ i1 ]$ J
6 H4 a/ D$ r1 E4 r; K在刷我修改之前的u-boot之前（也就是在使用Soul的U-boot的时候），你会遇到这个情况吗？
--- 原来的 uboot 就会，并非你的修改导致的，是在 emmc 装了 debian 之后出现的（没改 uboot 启动顺序），不知道是不是巧合
, V6 u& w- m9 e* N( W% X* k2 j- G
6 O8 k5 C7 `' U7 E# C在你卡在Starting kernel的时候，还能够进入emmc环境下的Debian吗？
7 Z" f8 t; k2 F: G  h4 \8 A0 o--- 能，引导群晖卡在 Starting kernel ...，而按住 RESET 5S 重新上电引导 Debian 能正常进系统
- e1 I  `- @" T; l. e% g5 A8 j
请问你能够在Debian下把spi flash的数据读取出来，以分析一下是否出现了错误吗？.
--- 卡 Starting kernel ... 前后的 uboot 环境变量我对比过，是一样的。而整个 spi 的 flash 8M 镜像没有前后对比过，按理说除了环境变量以外其它部分应该是只读的？

$ I' n- M( i( D: Z- b: c% l请提供一下无法正常启动时期的spi nor flash的备份镜像(应该是/dev目录下的各个mtdblock，以及/proc/mtd分区表
, ~( c% t) u; w4 L! K--- 好的，晚上回家备份

mynetdisk 发表于 2022-4-27 09:13
2 M& O* W- A# T谢谢 F 大
我前面没描述清楚，我的情况是这样：

我之前说：
一次 saveenv 后重启卡 Starting kernel ...，以为跟这个有关，之后试验排除了此可能
* G8 M2 j! r4 {6 ?2 A4 a5 i
现在我又不确定了，今天试了刷 uboot 重启几次正常启动群晖的情况下，saveenv 后重启就卡 Starting kernel ... 了，也许真像你说的是 uboot 分区表有问题（从而导致 saveenv 破坏了什么东西？）

mynetdisk 发表于 2022-4-27 10:50
7 X: T$ {: J& Q! _9 @: ]7 V/ a看上去像是u-boot中分区表配置错误
--- 应该不是，因为并不是换了 uboot 之后出现卡 Starting kernel ...  ...

1 Z* P2 Y) w2 t& x做设计这么多年，spi flash 从来没有出现过问题。所有spi flash故障都可以用其他问题来解释。
这个应该可以排除。

fhh 发表于 2022-4-26 18:08
U-boot有一部分问题。
2 J7 q) d/ b4 y# S) a我的做法是修改设备树，让Linux在重新初始化网卡的时候把功率拉到最大。
因为没有 ...

4 R8 K5 m6 q: C* @# c8 `soul确实通过uboot修改了掉IP问题。不过没有开放。当时我测试过。具体改了啥不太清楚。还是要通过手册来查找哪里出的问题，慢慢来试试。

QQ66566 发表于 2022-4-29 06:39
8 f7 n+ A. F0 H) R* c- @" ?+ F6 K, lsoul确实通过uboot修改了掉IP问题。不过没有开放。当时我测试过。具体改了啥不太清楚。还是要通过手册来查 ...

: d- x- y8 ~) f* Y+ c是的。
5 r1 n5 m7 a, U只要u-boot不初始化PHY，其上电以后的默认配置不被覆盖，就不会掉IP。
8 [* x( }8 q0 q但是代价就是U-boot无法使用网卡，以及这其实算是一种……“鸵鸟”解法？
% }1 x# Y. G! L. P$ J6 E我的解法是修改设备树，使得它被初始化后，再次把信号增益数据填入。
我认为这样才算是这个问题的真正正确解法。

QQ66566 发表于 2022-4-29 06:31
) n) J+ K) ^) _6 N8 T3 X做设计这么多年，spi flash 从来没有出现过问题。所有spi flash故障都可以用其他问题来解释。
# w& I4 x' V; m2 Z& h- }这个应该可 ...

/ I$ N! C/ [2 D6 s" ^$ e我的意思是，设备树中关于spi的分区配置错误，导致群晖把数据写入了其他的分区中。我在观察他的分区表的时候，发现u-boot中的分区配置，与手动dd出来的分区表……并不一致。
; E  E% w) w; |0 c+ f按照设备树中定义的分区表dd出来的分区，全都是无效数据。
换而言之，u-boot通过设备树暴露给群晖的分区，本身就是错误的。
4 @% q: C* y+ U) o- A我现在希望通过他的dump来分析u-boot和群晖究竟采取了哪一份分区表，以此来进行修复。
. t, e2 C$ @- q/ }: _9 H1 x& `