蜗窝科技

能否介绍下确定一款SOC的频点和电压的原则或方法？比如拿到一款新的SOC，我们应该给它选定哪些频点和电压呢。个人理解选好了这个，再加上cpufreq的软件框架，才能很好的达到power优化的目标吧？

@printk:可以给个你优化的例子吗？具体哪些点，耗时多少，做了哪些优化，优化后耗时多少。 还有个疑问：把kernel读出来 vs 解压kernel， 更大的kernel读出来的时间肯定更长，优化这个时间 vs 优化解压的时间，哪个更好，要对比一下吧？ 就uboot来说，我感觉主要有两个功能，一个是把kernel拷贝到内存，另一个是调试。 在发布的时候，其实调试功能是不需要的，仅需要第一个功能。 firstboot也是可以把kernel拷贝到内存的，这样发布的时候就可以不要uboot了。 ps: 1、firstboot是指把uboot拷贝到内存的这个boot，imx6中可能不是这个名字。 2、建议楼主说明你优化的kernel和uboot版本。 kernel 3.0以上版本，大多用了设备树，uboot具有调试设备树的功能，所以uboot有可能悄悄改了设备树，如果不要uboot，需要确定uboot是如何改了设备树。 3、uboot一般是读取固定大小的kernel和文件系统进内存。例如kernel是2.9M，uboot可能固定读4M，不会去管真正的kernel是多大，建议楼主确认下你的uboot是否是这样。 还有两个记不清楚的地方，说出来供楼主参考。 我以前粗略看过kernel的汇编部分，记得在汇编里好像会把真正的kernel搬运到新的内存地址，这个地方应该也可以优化。 读内核时，开启dma，应该可以读的更快吧

@bear20081015：涨姿势了，原来cache里面的内容已经pre-decode了，这样可以节省很多decode动作，进而节省power。多谢分享。

@Jackson：是啊，没办法，这是guoqing。 我用的是公司邮箱，是可以用的。

@linuxer：@linuxer, linuxer。 我问了下ARM的人，他们的意思是说icache里面确实存储的是40个bit，是memory中的32bit指令经过predecoder得到的。还给了一个转换公式，不过我尝试了一下，似乎不是很对，还在等他们的进一步回复。供你参考。 [From Jim Sykes - ARM Technical Support] Cortex-A5/A7/A53 store a special extended format in the I$ which is: For Cortex-A5/A7: 18 bits Thumb / 36 bits ARM For Cortex-A53: 20 bits Thumb / 40 bits ARM aarch32 or aarch64 This is related to changes to the instruction decode logic – a predecoder is added before the I$ - the main decoder is simplified and this leads to power and area savings. We do not have a script or documentation for this I$ format, however the tarmac logger contains functions to decode the instructions – when used with code below. The below SystemVerilog code can reverse the translations done in the predecode process for Cortex-A53. This includes snippets of code which show how to turn the 40-bit encoding in the I-cache into the 32-bit memory view (or at least as close as possible, the translation isn’t entirely two-way). For the code below "icb_encoding_for_reconstruction" is the 40-bit value from the I-cache, and "pfb_to_raw_encoding" is the 32-bit memory view of that value. ARM A64: if (icb_encoding_for_reconstruction[18:13] == 6'b000000) begin // We need first to check if the original encoding was undef or unpred pfb_to_raw_encoding[31:28] = icb_encoding_for_reconstruction[39:36]; pfb_to_raw_encoding[27:0] = {icb_encoding_for_reconstruction[11:0],icb_encoding_for_reconstruction[35:20]}; end else begin // normal case pfb_to_raw_encoding[31:0] = t32_to_a64(icb_encoding_for_reconstruction); end

@wowo：Gmail登录不上了

@Jackson：换个邮箱吧，最好能用gmail，或者公司的邮箱更好。

您好我订阅的时候 出现了 Sorry, we were unable to deliver your message to the following address. <majordomo@vger.kernel.org>: Remote host said: 553 5.7.1 Hello [98.138.229.47], for your MAIL FROM address <qianshiyilv@yahoo.com> policy analysis reported: Your address is not liked source for email [MAIL_FROM] --- Below this line is a copy of the message. 请问这是怎么回事

@wowo：@蜗蜗： 1 应该是醒来了，boot cpu sleep时，停在了cpu的power collapse（这个不大清楚究竟有什么特别的）。resume时，可以获知reason，前后间隔时间有10s。 2 电流表50ms采样一次，精度应该是够的。

@xie1230：我们需要先理解一点：DTS文件描述的是platform bus上的platform设备。 这也是为什么linux kernel of模块只会帮忙解析DTS中第2级别（例如i2c controller）的节点，因为只有这一级别的节点才是根正苗红的platform device。 然后再回到i2c bus下面的设备，它已经不是platform设备了（虽然很多driver也会为其创建platform设备），因此，kernel of模块就不会帮忙解析。那么谁解析呢？i2c bus driver。这就是为什么i2c设备的DTS node放到了i2c controller下面，也因此就没有i2c bus number的困扰了。 最后，i2c device设备的DTS node，本质上也是DTS node，只要能拿到它的句柄，一样可以通过of接口解析其中的properties。