烽火HG680-MC_強刷固件_『雙自由版』

LPP_robey · 發(fā)表于 2025-1-1 00:15

minyun 發(fā)表于 2024-12-31 14:56
你改fstab不掛載tvcertificate的參數是什么？我發(fā)現幾個不同的固件包內這個fstab.c2p都長一個樣，不知是不 ...

你這個文件不是有一行掛載tvcertificate的嗎？把這行注釋掉，最前面加個#就行了，然后系統(tǒng)就不會掛載這個分區(qū)了，節(jié)省20秒開機時間。。。

LPP_robey · 發(fā)表于 2025-1-1 00:16

羅波波發(fā)表于 2024-12-31 17:24
嘗試指定偏移量貌似不支持。到時候親自串口uboot-c2p#分區(qū)一下就明白了，系統(tǒng)比通常的人類想象更聰明。 ...

USB轉TTL小板預計周末到貨，屆時開搞，哈哈

LPP_robey · 發(fā)表于 2025-1-1 01:36

羅波波發(fā)表于 2024-12-27 10:21
【注意】B_HG680-MC_2+X_重分區(qū)_〖雙自由版〗，+已優(yōu)化++12月23日重新上傳+任何emmc容量的均可正常刷入。 ...

還是非常不解，虛心請教。
這個到底優(yōu)化了什么？怎么實現的任何emmc容量都能刷？萬一某個emmc實際容量小呢？

（現在越來越覺得我的磚機懸案不是因為缺少tvcertificate分區(qū)，而是因為emmc容量問題導致的）

羅波波 · 發(fā)表于 2025-1-2 12:11

LPP_robey 發(fā)表于 2025-1-1 01:36
還是非常不解，虛心請教。
這個到底優(yōu)化了什么？怎么實現的任何emmc容量都能刷？萬一某個emmc實際容量小 ...

你想的太復雜了。還是那句話，一切等到你親自重建分區(qū)就明白了！

LPP_robey · 發(fā)表于 2025-1-2 15:03

羅波波發(fā)表于 2025-1-2 12:11
你想的太復雜了。還是那句話，一切等到你親自重建分區(qū)就明白了！

先說說唄，實在心癢癢，我不一定重建分區(qū)（TTL看清楚我的2023和2024兩個盒子分區(qū)及EMMC尺寸后再定），而是希望知道這個原理后再決定是否重建分區(qū)，因為即使沒有tvcertificate分區(qū)，也可以通過不掛載tvcertificate的方式提高啟動速度，如果2024年開始官方都不用這個分區(qū)了，肯定有其原因，為何一定要重建這個分區(qū)呢？

羅波波 · 發(fā)表于 2025-1-2 16:42

本帖最后由羅波波于 2025-1-3 09:21 編輯

我不知道神馬原理，只知道結果。你要是知道了可以貼出來說說，我也壓根不關心神馬原理。按你的邏輯知道原理也不一定重建分區(qū)，那就直接按自己的方法搞不完了？那還用的著糾結神馬重建分區(qū)？這樣還能省出一些容量呢，值得鼓勵。還可進一步試驗能否不掛載其它神馬分區(qū)進而刪除這些多余分區(qū)，容量能省更多呢，如此啟動時間也正常了、容量也節(jié)省了、最關鍵的——避免了重分區(qū)的風險！何樂而不為呢？支持你搞，到時候單獨發(fā)個貼，讓更多的人擴展一下思路。。。。。。

LPP_robey · 發(fā)表于 2025-1-4 15:19

羅波波發(fā)表于 2025-1-2 12:11
你想的太復雜了。還是那句話，一切等到你親自重建分區(qū)就明白了！

對比了兩個重分區(qū)版本的分區(qū)腳本，發(fā)現最新固件對userdata的分區(qū)大小固定為4G，以適應不同emmc容量的硬件（其他分區(qū)分完以后，這里至少也能剩下4G？），懷疑這樣可能會損失一些容量，純猜測，求樓主確認，多謝。
既然這里不能指定剩余容量全部分給userdata分區(qū)，那么目前來看沒有完美的重分區(qū)方案：如果分小了會浪費空間，分大了會導致分區(qū)失敗進而無法執(zhí)行后續(xù)的刷機命令且容易變磚。
這樣來看，怎么都沒有完美的分區(qū)方案，所以我做新固件的整體思路就是不再重新分區(qū)。

我這方面經驗不足，不知道tvcertificate分區(qū)是干什么用的，但既然存在某些盒子沒有這個分區(qū)，那么我想新做的固件就不放這個文件了，這樣對于沒有這個分區(qū)的盒子來說不會因為刷到這里而失敗，對于有這個分區(qū)的盒子來說也能保留這個分區(qū)的數據不動（推測也不影響使用，待驗證）。

如果樓主知道我這個思路有什么坑，煩請?zhí)崆爸刚嘀x~
@羅波波 @cquzhang

LPP_robey · 發(fā)表于 2025-1-4 15:23

LPP_robey 發(fā)表于 2025-1-4 15:19
對比了兩個重分區(qū)版本的分區(qū)腳本，發(fā)現最新固件對userdata的分區(qū)大小固定為4G，以適應不同emmc容量的硬 ...

這個思路的缺點是對于有tvcertificate分區(qū)的盒子來說，等于刷了北京版原始固件后，這個分區(qū)就再也不用了，整體上會浪費這個分區(qū)的8MB空間（原本可以通過重分區(qū)把空間分給userdata分區(qū)來用的），但重分區(qū)實在風險太大，無法應對各種版本和容量的emmc，所以浪費8MB空間而避免重分區(qū)失敗，也相對值得吧。。。

LPP_robey · 發(fā)表于 2025-1-4 15:41

羅波波發(fā)表于 2025-1-2 16:42
我不知道神馬原理，只知道結果。你要是知道了可以貼出來說說，我也壓根不關心神馬原理。按你的邏輯知道原理 ...

理解。
我從來就不想重分區(qū)是因為覺得沒有完美的重分區(qū)方案（既適應各種容量的emmc又能最大程度的利用emmc的所有空間），想請教并知道原理是為了印證“從來就不想重分區(qū)”這個思路的方向是否足夠正確？

其實想節(jié)省容量的話，勢必還是要通過重分區(qū)的方式把不再使用的分區(qū)容量分給userdata，這樣只要涉及重分區(qū)，就無法精確指定正確的userdata分區(qū)大小來適應各種尺寸的emmc容量，所以只能兩權相害取其輕，以浪費最小的空間作為代價來避免重分區(qū)帶來的風險，即：舍棄tvcertificate這個8MB的分區(qū)，最多浪費這8MB。

已驗證：
北京移動20240301版本的盒子（已刷機，非原始固件），無tvcertificate分區(qū)。

待驗證：
1、北京移動20230514原版盒子是否無tvcertificate分區(qū)？fstab.c2p文件里是否不掛載tvcertificate分區(qū)？
2、基于第1條做出來的固件，是否可以正常使用在其他省份或者版本的盒子上，即北京移動原版固件的各分區(qū)數據是否可以和其他各版本的tvcertificate分區(qū)數據共存并正常使用？

肯定會單獨發(fā)貼，把固件的特性以及過程都講清楚哈，屆時還請大佬多指點，共同優(yōu)化。

LPP_robey · 發(fā)表于 2025-1-4 15:55

小結：一切都源于烽火這盒子各種版本存在不同的EMMC規(guī)格和容量，且tvcertificate分區(qū)不一定原始存在。
廠家搞這么多版本不考慮維護成本，也給咱們業(yè)余玩家刷機帶來了各種風險和問題，如果有廠家的人能出來說說背后的原因和思路就好了。。。

› 運營商IPTV / 有線電視 / 廣電機頂盒 › 中國移動魔百盒

烽火HG680-MC_強刷固件_『雙自由版』

烽火HG680-MC_強刷固件_『雙自由版』