i.MX交叉编译openssl

freescale的i.MX采用了yocto的框架编译。提取toolchain并安装后,在toolchain的安装目录有一个脚本可以用来设置交叉编译的环境变量。 ISSUE 但是当使用此环境变量编译openssl后,会出现以下问题: [crayon-684417ebd44d2762382410/] FIXes 此时可以通过手动配置编译环境解决: 重新开一个shell 设置交叉编译器目录到PATH [crayon-684417ebd44d6522091923/] 采用通用32位配置Autoconf [crayon-684417ebd44d7899109381/] 修改Makefile中的CC为交叉编译器的GCC,注意不要忘了后面的参数 [crayon-684417ebd44d8324917013/] 编译 [crayon-684417ebd44d9832833356/] 参考 http://berniechenopenvpn.blogspot.com/2015/10/wpasupplicant-am335x.html
端午国庆自驾游

端午国庆自驾游

2015/9/26号出发,经沈阳、27号在沈阳休息游玩一天,到长白山西坡,在到长白山北坡,经蛟河到长春,在回沈阳休息,最后经盘锦到北戴河小住,4号回京。 总计5个大人,1个小孩,话费11K - 12K。    

HOWTO Cross Compile and Configurate net-snmp

Precondition Hardware platform: ATMEL SAM9X5 Series Cross-compile tool: denx eldk-4.2 CrossCompile openssl denx的eldk-4.2版本的arm编译器自带的openssl库版本为0.9.8b,在编译net-snmp的时候configure会出错: checking for BIO_dgram_get_peer... configure: error: DTLS support requires a newer version of OpenSSL 所以需要使用高版本的openssl。 $ git clone git://git.openssl.org/openssl.git…

ATMEL SAM9X5烧写引导文件

介绍 ATMEL的SAM9X5系列CPU在设定从CPU内部的BOOTROM启动后,如果在启动过程中没有发现NANDFLASH、SPI FLASH、DATA FLASH或者I2C FLASH中具备可用的引导文件,则会启动SAMBA服务。此时用户可以通过串口或者USB对SAM9X5的启动FLASH进行编程。但是由于使用串口进行SAMBA控制的时候经常无反应,故建议使用USB接口(USB接口为SAM9X5的Device接口)。 使用SAMBA烧写启动文件 识别/安装USB驱动 如果CPU启动的SAMBA服务,则CPU在DBG口显示RomBOOT,同时电脑会发现一个新硬件(如果CPU找到了启动文件或者启动文件出错则不会有新硬件发现): 安装驱动,完成后如下:   连接目标板 打开SAMBA软件,选择安装的USB转SERIAL的设备,选择连接: 由于我们采用NAND FLASH作为启动芯片,选择NandFlash选项卡: 烧写启动文件 烧写Bootstrap步骤:“Enable NandFlash” -> “Pmecc configuration" -> "Send Boot File",其中PMECC配置如下:   由于我们用的SAMSUNG的K9F2G08U0C-SIB0: Block(Erase) size是0x20000 Page size是2048…

SAM9X5 NANDFLASH预烧写工程生成

背景 之前公司用ATMEL的SAM9G25,采用NAND FLASH启动,ECC采用CPU自带的PMECC控制器硬件产生和检测,虽然PMECC采用BCH编码,但是由于变种很多,在周立功的SmartPRO 5000U-PLUS编程器中找不到与之对应的ECC算法。后来为了能使用编程器预烧写FLASH,便从Bootstrap、uboot和uImage全部采用linux mtd Ecc校验算法。 做法 首先确定烧写启动文件(包括Bootstrap 、uboot、uImage和Ramdisk)的所有扇区均无坏块。 执行: nanddump -o -s <start_addr> -l <size> -f <filename> /dev/mtdx 其中-o意思是输出oob数据区 这样我们分别dump出启动文件的各个部分。即可在SmartPRO 5000U-PLUS编程器中使用,在编程器选择ECC信息时需要选择文件自带OOB区即可。

How to Cross Compile openssl

下载 [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…

FreeScale QorIQ Build failure

编译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 #…

Intel 82551强制模式

最近遇到了一个问题,公司之前设计的产品在旁路网络的时候只旁路了百兆4根线,结果造成用户在使用的过程中一旦将网络盘路后两端的装置无法正常协商成功。后来只能将两端的装置强制为百兆全双工,我们的设备依旧为自动协商。 后来我们的产品在运行过程中出现了协商时为百兆全双工、时为百兆半双工。在百兆半双工的情况下会造成网络故障。 开始以为是Intel 82551网络协商问题,后来查了一下网络自动协商的规范,原来在一端强制、一端自动的时候只能协商网络速度,而不能协商双工与半双工,在一端强制的情况下,另外一端也必须强制对端的速率和双工。 于是通过options=0x70强制网卡驱动在加载的时候为百兆全双工。但是又遇到了另外一个问题:网口在ifdown/ifup或者拔掉在插上的时候检测link非常慢,需要5分钟以上,这个肯定是不正常的。 接着google,但是毫无进展。后来查看到82551的DS中对MDI/MDI-X有一个切换时间的选择配置,想一下我们的装置也配置了MDI/MDI-X自适应,会不会是这个问题呢。 马上修改驱动禁止MDI/MDI-X自适应,网口检测马上好了,接着打开MDI/MDI-X自适应,同时修改切换时间从80ms到105ms,问题解决。 怀疑是网络设计信号完整性不是很好,检测link时间过长而导致MDI/MDI-X切换。   参考资料: http://en.wikipedia.org/wiki/Autonegotiation

CrossCompile snmpd

$ ./configure --build=i386-linux --host=arm-linux --enable-mini-agent --disable-ipv6 --with-endianness=little --disable-manuals --disable-ucd-snmp-compatibility --enable-as-needed --disable-embedded-perl --without-perl-modules --disable-snmptrapd-subagent --disable-applications --disable-scripts $ make LDFLAGS="-static"

MPC8309 NAND Flash启动

之前我做了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…