下载 [crayon-684417ebd46c9980637251/] 编译 openssl-0.9.7a [crayon-684417ebd46cc794180141/] openssl-1.0.0 and later 查看支持的平台 [crayon-684417ebd46cd630666670/] 配置参数&编译 [crayon-684417ebd46ce721910164/] Status of different versions: OpenSSL 1.0.1 through 1.0.1f (inclusive) are vulnerable OpenSSL 1.0.1g is NOT vulnerable OpenSSL 1.0.0…
编译fsl的QorIQ的时候可能会出现如下错误: | checking for gnumake... make | checking version of make... 4.0, bad | checking for gnumsgfmt... no 目前发现类似的还有makeinfo。系统为dabian 8.0 其实是fsl配置的时候判断过于严谨。 根据编译上下文找到对应的configuration文件,修改 if test -z "$MAKE"; then ac_verc_fail=yes else #…
之前我做了MPC8309+K9F5608U0D (16MB)的启动。一直想把移植过程写出来,后来耽搁了也没写。正好这次公司定MPC8309 CPU方案准备采用K9F2G08U0C(256MB)。移植完后就有了下面的文章。 前景提要 之前移植K9F5608U0C的时候可谓复杂。我们最早焊的是64M的K9F1208U0C,但是Freescale的Code Warrior上只有K9F5608U0D的选项。本着Dev的考虑,我认为1208和5608仅仅在与前者比后者多了几个Block,产品ID不一样,于是我试着改了一下Code Warrior的FPDeviceConfig.xml。 结果惊奇的发现在FPDeviceConfig.xml文件中,K9F5608U0D的manufacturerid是35,id是75。这个不合道理啊。如果按照Freescale的CWFLASHPROWP.pdf上所述,SamSung的manufacturerid应该是EC,id应该是75。于是我把manufacturerid和id来回调换,都不成。于是我直接直接换了一片K9F5608U0D,又找FAE要了他机器上面的K9F5608x0D.elf和K9F5608x0D_utility.elf。终于可以用CW烧写NAND Flash了。 移植K9F2G08SU0C 有了上次的经验,我试了一下CW自带的K9F2G08X0A。结果很悲剧,还是无法操作FLASH,我看了看它的manufacturerid和id,分别被设置成23和EC。还是猜不透。 我又翻读了AN3859.pdf文档,AN3859上说:"Samsung uses its own algorithm for flash programming, not compatible with other vendors"。如果本身自带的elf不行的话只有自己编写适合自己所用芯片的algorithem文件了。于是我找到了CW目录下的NAND Flash例程。而他的例程针对的是MPC8360和K9NBG08U5M,NAND Flash和我目前所用差距太大,直接在CPU上仿真发现老是进入取指异常。而查看它的源码有了点新发现。它的getFlashID实现中: [crayon-684417ebd4811379445720/] 看起来manufacturerid取的是第3个字节,id取的是第二个字节,于是我有来回倒腾manufacturerid和id。最终一无所获。 实在没有办法,我在Freescale的论坛上发了帖子。同时我试图先通过NOR Flash启动,然后在u-boot下将编好的U-boot下载到NAND…