minyun 发表于 2024-12-31 14:56
你改fstab不挂载tvcertificate的参数是什么？我发现几个不同的固件包内这个fstab.c2p都长一个样，不知是不 ...
你这个文件不是有一行挂载tvcertificate的吗？把这行注释掉，最前面加个#就行了，然后系统就不会挂载这个分区了，节省20秒开机时间。。。
罗波波 发表于 2024-12-31 17:24
尝试指定偏移量貌似不支持。到时候亲自串口uboot-c2p#分区一下就明白了，系统比通常的人类想象更聪明。 ...
USB转TTL小板预计周末到货，届时开搞，哈哈
罗波波 发表于 2024-12-27 10:21
【注意】B_HG680-MC_2+X_重分区_〖双自由版〗，+已优化++12月23日重新上传+任何emmc容量的均可正常刷入。 ...
还是非常不解，虚心请教。
这个到底优化了什么？怎么实现的任何emmc容量都能刷？万一某个emmc实际容量小呢？
（现在越来越觉得我的砖机悬案不是因为缺少tvcertificate分区，而是因为emmc容量问题导致的）
LPP_robey 发表于 2025-1-1 01:36
还是非常不解，虚心请教。
这个到底优化了什么？怎么实现的任何emmc容量都能刷？万一某个emmc实际容量小 ...
你想的太复杂了。还是那句话，一切等到你亲自重建分区就明白了！
罗波波 发表于 2025-1-2 12:11
你想的太复杂了。还是那句话，一切等到你亲自重建分区就明白了！
先说说呗，实在心痒痒，我不一定重建分区（TTL看清楚我的2023和2024两个盒子分区及EMMC尺寸后再定），而是希望知道这个原理后再决定是否重建分区，因为即使没有tvcertificate分区，也可以通过不挂载tvcertificate的方式提高启动速度，如果2024年开始官方都不用这个分区了，肯定有其原因，为何一定要重建这个分区呢？
本帖最后由 罗波波 于 2025-1-3 09:21 编辑
我不知道神马原理，只知道结果。你要是知道了可以贴出来说说，我也压根不关心神马原理。按你的逻辑知道原理也不一定重建分区，那就直接按自己的方法搞不完了？那还用的着纠结神马重建分区？这样还能省出一些容量呢，值得鼓励。还可进一步试验能否不挂载其它神马分区进而删除这些多余分区，容量能省更多呢，如此启动时间也正常了、容量也节省了、最关键的——避免了重分区的风险！何乐而不为呢？支持你搞，到时候单独发个贴，让更多的人扩展一下思路。。。。。。
罗波波 发表于 2025-1-2 12:11
你想的太复杂了。还是那句话，一切等到你亲自重建分区就明白了！
对比了两个重分区版本的分区脚本，发现最新固件对userdata的分区大小固定为4G，以适应不同emmc容量的硬件（其他分区分完以后，这里至少也能剩下4G？），怀疑这样可能会损失一些容量，纯猜测，求楼主确认，多谢。
既然这里不能指定剩余容量全部分给userdata分区，那么目前来看没有完美的重分区方案：如果分小了会浪费空间，分大了会导致分区失败进而无法执行后续的刷机命令且容易变砖。
这样来看，怎么都没有完美的分区方案，所以我做新固件的整体思路就是不再重新分区。
我这方面经验不足，不知道tvcertificate分区是干什么用的，但既然存在某些盒子没有这个分区，那么我想新做的固件就不放这个文件了，这样对于没有这个分区的盒子来说不会因为刷到这里而失败，对于有这个分区的盒子来说也能保留这个分区的数据不动（推测也不影响使用，待验证）。
如果楼主知道我这个思路有什么坑，烦请提前指正，多谢~
@罗波波 @cquzhang
LPP_robey 发表于 2025-1-4 15:19
对比了两个重分区版本的分区脚本，发现最新固件对userdata的分区大小固定为4G，以适应不同emmc容量的硬 ...
这个思路的缺点是对于有tvcertificate分区的盒子来说，等于刷了北京版原始固件后，这个分区就再也不用了，整体上会浪费这个分区的8MB空间（原本可以通过重分区把空间分给userdata分区来用的），但重分区实在风险太大，无法应对各种版本和容量的emmc，所以浪费8MB空间而避免重分区失败，也相对值得吧。。。
罗波波 发表于 2025-1-2 16:42
我不知道神马原理，只知道结果。你要是知道了可以贴出来说说，我也压根不关心神马原理。按你的逻辑知道原理 ...
理解。
我从来就不想重分区是因为觉得没有完美的重分区方案（既适应各种容量的emmc又能最大程度的利用emmc的所有空间），想请教并知道原理是为了印证“从来就不想重分区”这个思路的方向是否足够正确？
其实想节省容量的话，势必还是要通过重分区的方式把不再使用的分区容量分给userdata，这样只要涉及重分区，就无法精确指定正确的userdata分区大小来适应各种尺寸的emmc容量，所以只能两权相害取其轻，以浪费最小的空间作为代价来避免重分区带来的风险，即：舍弃tvcertificate这个8MB的分区，最多浪费这8MB。
已验证：
北京移动20240301版本的盒子（已刷机，非原始固件），无tvcertificate分区。
待验证：
1、北京移动20230514原版盒子是否无tvcertificate分区？fstab.c2p文件里是否不挂载tvcertificate分区？
2、基于第1条做出来的固件，是否可以正常使用在其他省份或者版本的盒子上，即北京移动原版固件的各分区数据是否可以和其他各版本的tvcertificate分区数据共存并正常使用？
肯定会单独发贴，把固件的特性以及过程都讲清楚哈，届时还请大佬多指点，共同优化。
小结：一切都源于烽火这盒子各种版本存在不同的EMMC规格和容量，且tvcertificate分区不一定原始存在。
厂家搞这么多版本不考虑维护成本，也给咱们业余玩家刷机带来了各种风险和问题，如果有厂家的人能出来说说背后的原因和思路就好了。。。