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

fhh

mynetdisk 发表于 2022-4-27 01:52
2 j) P" _7 d" p  E$ G- v$ C刷这个成功迁移并进入群晖
/ q3 t; Y; T+ P/ a  B6 c- Q9 z
可惜重启后又出现卡 Starting kernel ... 问题

/ M7 |  G% t( i9 U% F& E2 M哦，那应该是因为emmc引导顺序在群晖之前，但是群晖的u-boot提供的设备树与Linux不兼容。
* {% F  Z8 s8 s你把emmc中的Debian抹掉就好了。

mynetdisk

fhh 发表于 2022-4-27 08:04
哦，那应该是因为emmc引导顺序在群晖之前，但是群晖的u-boot提供的设备树与Linux不兼容。
% v, t3 I6 P$ Z3 i& |. s6 x5 _你把emmc中的De ...

+ s7 k+ E, z& n  y: ?8 @谢谢 F 大
我前面没描述清楚，我的情况是这样：
/ ^2 t. v( X* p
) E, M/ G) H. n/ e1.
0 m6 `3 N* a$ N3 D; M启动时 TTL 默认显示 syno mode，然后在 Starting kernel ... 卡住
+ g, G- y8 M3 o3 s7 x5 ^按住 RESET 5S 上电启动 TTL 显示 mmc mode，能正常进 Debian
# `$ _8 [: \1 W
) O6 `3 i& W% V' [2.
4 V7 |! ]! }2 R- |刚刷 u-boot 之后可以进群晖（也有一次刚刷完 uboot 就进不了群晖）
4 A/ k% f# w6 @+ ?1 }3 O! \( @5 u之后某次重启后 syno mode 就卡在 Starting kernel ...（但 mmc mode 仍然可以进 debian）
一旦出现卡 Starting kernel ...，再重启 N 次也还是卡 Starting kernel ...，直到下次刷 uboot 通常可以暂时解决
6 M5 J) H: ^4 n( z. B- |
8 ?0 y" w0 h# j/ Z3.
& Z  _# v+ \$ B& U  J一次 saveenv 后重启卡 Starting kernel ...，以为跟这个有关，之后试验排除了此可能【2022-04-29 修订：我又不确定了，今天试了刷 uboot 重启几次正常启动群晖的情况下，saveenv 后重启就卡 Starting kernel ... 了，也许真像你说的是 uboot 分区表有问题（从而导致 saveenv 破坏了什么东西？）】
一次进 debian 后重启卡 Starting kernel ...，以为是 debian 自动修改了 uboot 环境变量，之后试验排除了此可能
2 J* p7 @, z5 H5 W/ u& T3 A, A" i6 WU盘、硬盘都拔掉试过，排除了这两种设备问题的可能

fhh

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

看上去像是u-boot中分区表配置错误，或者是你的spi nor flash出现了故障。
我想询问一下：
5 H) O, u% K2 f% ]3 o1.在刷我修改之前的u-boot之前（也就是在使用Soul的U-boot的时候），你会遇到这个情况吗？
2.在你卡在Starting kernel的时候，还能够进入emmc环境下的Debian吗？如果能，请问你能够在Debian下把spi flash的数据读取出来，以分析一下是否出现了错误吗？
3 o, y2 v% Z/ ^& T8 ~0 t: _如果可以的话，请提供一下无法正常启动时期的spi nor flash的备份镜像(应该是/dev目录下的各个mtdblock，以及/proc/mtd分区表)，我需要根据这些信息进行分析。
0 X/ y+ p, D! L- X8 H: b谢谢！

mynetdisk

fhh 发表于 2022-4-27 10:15
看上去像是u-boot中分区表配置错误，或者是你的spi nor flash出现了故障。
我想询问一下：
1.在刷我修改之 ...

看上去像是u-boot中分区表配置错误
2 |4 J' k. X! w% U6 K1 s; D9 ], ^- b--- 应该不是，因为并不是换了 uboot 之后出现卡 Starting kernel ... 问题，刚刷 uboot 后通常可以用，第 N 次重启之后可能出现 Starting kernel ...，之后再重启也必然这样，只能重新刷 uboot（注：不代表一定是 uboot 这里出了错，因为每次重刷 uboot 后需要重装群晖 DSM，所以也可能是因为重装 DSM 而暂时解决了问题）
8 g$ g5 L, }/ o' V' U( Y
% o! G' X9 {$ Y. O: ^# w" B或者是你的spi nor flash出现了故障
$ x# _" g; ?) N# L: i--- uboot bubt 命令刷写 SPI FLASH 后会不会校验呢，如果有校验，证明 FLASH 本身读写应该没问题，而是否后续 FLASH 数据出问题待确定
: U3 D4 Q/ w  l: }: `* |0 ^
* P8 z9 B" _( {# _& N在刷我修改之前的u-boot之前（也就是在使用Soul的U-boot的时候），你会遇到这个情况吗？
--- 原来的 uboot 就会，并非你的修改导致的，是在 emmc 装了 debian 之后出现的（没改 uboot 启动顺序），不知道是不是巧合

在你卡在Starting kernel的时候，还能够进入emmc环境下的Debian吗？
, ]8 z( V; X3 t# Q7 \--- 能，引导群晖卡在 Starting kernel ...，而按住 RESET 5S 重新上电引导 Debian 能正常进系统

请问你能够在Debian下把spi flash的数据读取出来，以分析一下是否出现了错误吗？.
--- 卡 Starting kernel ... 前后的 uboot 环境变量我对比过，是一样的。而整个 spi 的 flash 8M 镜像没有前后对比过，按理说除了环境变量以外其它部分应该是只读的？
3 r/ C9 N" D& J- ?& o( e
请提供一下无法正常启动时期的spi nor flash的备份镜像(应该是/dev目录下的各个mtdblock，以及/proc/mtd分区表
. h4 ?% i3 J1 Q; W6 U8 [3 r6 U--- 好的，晚上回家备份

mynetdisk

mynetdisk 发表于 2022-4-27 09:13
* c; Z% s, g. q2 P- L) K谢谢 F 大
. |# Q8 @3 t9 Y  o; ~我前面没描述清楚，我的情况是这样：

5 f1 h5 R- {- _4 y2 n' |我之前说：
$ ^6 ^5 Q* _' g1 r一次 saveenv 后重启卡 Starting kernel ...，以为跟这个有关，之后试验排除了此可能

现在我又不确定了，今天试了刷 uboot 重启几次正常启动群晖的情况下，saveenv 后重启就卡 Starting kernel ... 了，也许真像你说的是 uboot 分区表有问题（从而导致 saveenv 破坏了什么东西？）

QQ66566

mynetdisk 发表于 2022-4-27 10:50
! k& B9 q  x$ E# Z2 d( @1 {7 I, i看上去像是u-boot中分区表配置错误
--- 应该不是，因为并不是换了 uboot 之后出现卡 Starting kernel ...  ...

4 ?9 M0 b% i, {3 K做设计这么多年，spi flash 从来没有出现过问题。所有spi flash故障都可以用其他问题来解释。
+ y; r* i1 `  @- u! A这个应该可以排除。

QQ66566

fhh 发表于 2022-4-26 18:08
U-boot有一部分问题。
5 p8 p+ m2 K" Q. v% t我的做法是修改设备树，让Linux在重新初始化网卡的时候把功率拉到最大。
( Q# L% n3 I* S' {* k因为没有 ...

soul确实通过uboot修改了掉IP问题。不过没有开放。当时我测试过。具体改了啥不太清楚。还是要通过手册来查找哪里出的问题，慢慢来试试。

fhh

QQ66566 发表于 2022-4-29 06:39
' {. `" v% l4 s+ u( vsoul确实通过uboot修改了掉IP问题。不过没有开放。当时我测试过。具体改了啥不太清楚。还是要通过手册来查 ...

7 b) R, u/ h/ w& U. N1 c是的。
# {' J' d; Q. C6 h. A, v& v/ V) U. M1 v只要u-boot不初始化PHY，其上电以后的默认配置不被覆盖，就不会掉IP。
% X( u2 H& x  d! q2 v# U, n: X但是代价就是U-boot无法使用网卡，以及这其实算是一种……“鸵鸟”解法？
我的解法是修改设备树，使得它被初始化后，再次把信号增益数据填入。
我认为这样才算是这个问题的真正正确解法。

fhh

; l3 v! g' X  @5 g

QQ66566 发表于 2022-4-29 06:31
7 D" P  w2 ?5 ^+ a! w6 Q) Q2 n做设计这么多年，spi flash 从来没有出现过问题。所有spi flash故障都可以用其他问题来解释。
2 A* J" i& z- c! p这个应该可 ...

9 ]1 W. C+ o7 w我的意思是，设备树中关于spi的分区配置错误，导致群晖把数据写入了其他的分区中。我在观察他的分区表的时候，发现u-boot中的分区配置，与手动dd出来的分区表……并不一致。
6 d1 R- W/ r8 Q3 }3 w0 Y按照设备树中定义的分区表dd出来的分区，全都是无效数据。
换而言之，u-boot通过设备树暴露给群晖的分区，本身就是错误的。
* u" }5 m/ M+ q我现在希望通过他的dump来分析u-boot和群晖究竟采取了哪一份分区表，以此来进行修复。
4 u' i1 e0 A3 }$ O. `