本帖最后由 tll 于 2013-10-3 10:45 编辑
因为看到老外做arm模拟器在avr单片机上跑linux启动bash(花6小时),感觉自己也要试试,要是能在我的Huluboard(和UNO配置一样,328p)上跑linux我该多高兴啊,但不管是否成功,能学到是最好
于是先从kernel抓起,找准一个以前编译的内核,启动ubuntu,没错,uImage,就你了。- root@ubuntu:~/kernel/linux-sunxi-sunxi-3.4/output#
- hexdump -C uImage -n 64
- 00000000 27 05 19 56 7f 91 23 3a 51 a1 53 0b 00 3f dd 28 |'..V..#:Q.S..?.(|
- 00000010 40 00 80 00 40 00 80 00 83 e5 d5 e1 05 02 02 00 |@...@...........|
- 00000020 4c 69 6e 75 78 2d 33 2e 34 2e 34 33 00 00 00 00 |Linux-3.4.43....|
- 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
- 00000040
复制代码 uImage的前64个字节是文件头,后面是zImage
我们可以试试:- root@ubuntu:~/kernel/linux-sunxi-sunxi-3.4/output# hexdump -C uImage -n 70
- 00000000 27 05 19 56 7f 91 23 3a 51 a1 53 0b 00 3f dd 28 |'..V..#:Q.S..?.(|
- 00000010 40 00 80 00 40 00 80 00 83 e5 d5 e1 05 02 02 00 |@...@...........|
- 00000020 4c 69 6e 75 78 2d 33 2e 34 2e 34 33 00 00 00 00 |Linux-3.4.43....|
- 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
- 00000040 00 00 a0 e1 00 00 |......|
- 00000046
- root@ubuntu:~/kernel/linux-sunxi-sunxi-3.4/output# hexdump -C zImage -n 6
- 00000000 00 00 a0 e1 00 00 |......|
- 00000006
- root@ubuntu:~/kernel/linux-sunxi-sunxi-3.4/output#
复制代码 大家应该看出来了吧?uImage(以下可能简称u)后面的6个字节和zImage(同理可能简称)的前6字节一致,也就是说,要从uImage里提取zImage,一个dd命令即可,dd if=uImage of=zImage bs=1 seek=64,不知道对不对……
好吧,研究kernel,看u-boot的code比较合适,因为u-boot是启动kernel的
u-boot下:
include/image.h
跳过一些code,来啦!
系统代码,CPU代码,映像格式,压缩格式- /*
- * Operating System Codes
- */
- #define IH_OS_INVALID 0 /* Invalid OS */
- #define IH_OS_OPENBSD 1 /* OpenBSD */
- #define IH_OS_NETBSD 2 /* NetBSD */
- #define IH_OS_FREEBSD 3 /* FreeBSD */
- #define IH_OS_4_4BSD 4 /* 4.4BSD */
- #define IH_OS_LINUX 5 /* Linux */
- #define IH_OS_SVR4 6 /* SVR4 */
- #define IH_OS_ESIX 7 /* Esix */
- #define IH_OS_SOLARIS 8 /* Solaris */
- #define IH_OS_IRIX 9 /* Irix */
- #define IH_OS_SCO 10 /* SCO */
- #define IH_OS_DELL 11 /* Dell */
- #define IH_OS_NCR 12 /* NCR */
- #define IH_OS_LYNXOS 13 /* LynxOS */
- #define IH_OS_VXWORKS 14 /* VxWorks */
- #define IH_OS_PSOS 15 /* pSOS */
- #define IH_OS_QNX 16 /* QNX */
- #define IH_OS_U_BOOT 17 /* Firmware */
- #define IH_OS_RTEMS 18 /* RTEMS */
- #define IH_OS_ARTOS 19 /* ARTOS */
- #define IH_OS_UNITY 20 /* Unity OS */
- #define IH_OS_INTEGRITY 21 /* INTEGRITY */
- #define IH_OS_OSE 22 /* OSE */
- #define IH_OS_PLAN9 23 /* Plan 9 */
- /*
- * CPU Architecture Codes (supported by Linux)
- */
- #define IH_ARCH_INVALID 0 /* Invalid CPU */
- #define IH_ARCH_ALPHA 1 /* Alpha */
- #define IH_ARCH_ARM 2 /* ARM */
- #define IH_ARCH_I386 3 /* Intel x86 */
- #define IH_ARCH_IA64 4 /* IA64 */
- #define IH_ARCH_MIPS 5 /* MIPS */
- #define IH_ARCH_MIPS64 6 /* MIPS 64 Bit */
- #define IH_ARCH_PPC 7 /* PowerPC */
- #define IH_ARCH_S390 8 /* IBM S390 */
- #define IH_ARCH_SH 9 /* SuperH */
- #define IH_ARCH_SPARC 10 /* Sparc */
- #define IH_ARCH_SPARC64 11 /* Sparc 64 Bit */
- #define IH_ARCH_M68K 12 /* M68K */
- #define IH_ARCH_MICROBLAZE 14 /* MicroBlaze */
- #define IH_ARCH_NIOS2 15 /* Nios-II */
- #define IH_ARCH_BLACKFIN 16 /* Blackfin */
- #define IH_ARCH_AVR32 17 /* AVR32 */
- #define IH_ARCH_ST200 18 /* STMicroelectronics ST200 */
- #define IH_ARCH_SANDBOX 19 /* Sandbox architecture (test only) */
- #define IH_ARCH_NDS32 20 /* ANDES Technology - NDS32 */
- #define IH_ARCH_OPENRISC 21 /* OpenRISC 1000 */
- /*
- * Image Types
- *
- * "Standalone Programs" are directly runnable in the environment
- * provided by U-Boot; it is expected that (if they behave
- * well) you can continue to work in U-Boot after return from
- * the Standalone Program.
- * "OS Kernel Images" are usually images of some Embedded OS which
- * will take over control completely. Usually these programs
- * will install their own set of exception handlers, device
- * drivers, set up the MMU, etc. - this means, that you cannot
- * expect to re-enter U-Boot except by resetting the CPU.
- * "RAMDisk Images" are more or less just data blocks, and their
- * parameters (address, size) are passed to an OS kernel that is
- * being started.
- * "Multi-File Images" contain several images, typically an OS
- * (Linux) kernel image and one or more data images like
- * RAMDisks. This construct is useful for instance when you want
- * to boot over the network using BOOTP etc., where the boot
- * server provides just a single image file, but you want to get
- * for instance an OS kernel and a RAMDisk image.
- *
- * "Multi-File Images" start with a list of image sizes, each
- * image size (in bytes) specified by an "uint32_t" in network
- * byte order. This list is terminated by an "(uint32_t)0".
- * Immediately after the terminating 0 follow the images, one by
- * one, all aligned on "uint32_t" boundaries (size rounded up to
- * a multiple of 4 bytes - except for the last file).
- *
- * "Firmware Images" are binary images containing firmware (like
- * U-Boot or FPGA images) which usually will be programmed to
- * flash memory.
- *
- * "Script files" are command sequences that will be executed by
- * U-Boot's command interpreter; this feature is especially
- * useful when you configure U-Boot to use a real shell (hush)
- * as command interpreter (=> Shell Scripts).
- */
- #define IH_TYPE_INVALID 0 /* Invalid Image */
- #define IH_TYPE_STANDALONE 1 /* Standalone Program */
- #define IH_TYPE_KERNEL 2 /* OS Kernel Image */
- #define IH_TYPE_RAMDISK 3 /* RAMDisk Image */
- #define IH_TYPE_MULTI 4 /* Multi-File Image */
- #define IH_TYPE_FIRMWARE 5 /* Firmware Image */
- #define IH_TYPE_SCRIPT 6 /* Script file */
- #define IH_TYPE_FILESYSTEM 7 /* Filesystem Image (any type) */
- #define IH_TYPE_FLATDT 8 /* Binary Flat Device Tree Blob */
- #define IH_TYPE_KWBIMAGE 9 /* Kirkwood Boot Image */
- #define IH_TYPE_IMXIMAGE 10 /* Freescale IMXBoot Image */
- #define IH_TYPE_UBLIMAGE 11 /* Davinci UBL Image */
- #define IH_TYPE_OMAPIMAGE 12 /* TI OMAP Config Header Image */
- #define IH_TYPE_AISIMAGE 13 /* TI Davinci AIS Image */
- #define IH_TYPE_KERNEL_NOLOAD 14 /* OS Kernel Image, can run from any load address */
- #define IH_TYPE_PBLIMAGE 15 /* Freescale PBL Boot Image */
- /*
- * Compression Types
- */
- #define IH_COMP_NONE 0 /* No Compression Used */
- #define IH_COMP_GZIP 1 /* gzip Compression Used */
- #define IH_COMP_BZIP2 2 /* bzip2 Compression Used */
- #define IH_COMP_LZMA 3 /* lzma Compression Used */
- #define IH_COMP_LZO 4 /* lzo Compression Used */
复制代码 还有个define:- #define IH_MAGIC 0x27051956 /* Image Magic Number */
- #define IH_NMLEN 32 /* Image Name Length */
复制代码 接下来是struct:- /*
- * Legacy format image header,
- * all data in network byte order (aka natural aka bigendian).
- */
- typedef struct image_header {
- __be32 ih_magic; /* Image Header Magic Number */
- __be32 ih_hcrc; /* Image Header CRC Checksum */
- __be32 ih_time; /* Image Creation Timestamp */
- __be32 ih_size; /* Image Data Size */
- __be32 ih_load; /* Data Load Address */
- __be32 ih_ep; /* Entry Point Address */
- __be32 ih_dcrc; /* Image Data CRC Checksum */
- uint8_t ih_os; /* Operating System */
- uint8_t ih_arch; /* CPU architecture */
- uint8_t ih_type; /* Image Type */
- uint8_t ih_comp; /* Compression Type */
- uint8_t ih_name[IH_NMLEN]; /* Image Name */
- } image_header_t;
- typedef struct image_info {
- ulong start, end; /* start/end of blob */
- ulong image_start, image_len; /* start of image within blob, len of image */
- ulong load; /* load addr for the image */
- uint8_t comp, type, os; /* compression, type of image, os type */
- } image_info_t;
复制代码 经过查询发现IH_NMLEN = 32,于是判断后32byte是内核名字,果然- root@ubuntu:~/kernel/linux-sunxi-sunxi-3.4/output# hexdump -C uImage -n 32
- 00000000 27 05 19 56 7f 91 23 3a 51 a1 53 0b 00 3f dd 28 |'..V..#:Q.S..?.(|
- 00000010 40 00 80 00 40 00 80 00 83 e5 d5 e1 05 02 02 00 |@...@...........|
- 00000020
- root@ubuntu:~/kernel/linux-sunxi-sunxi-3.4/output# hexdump -C uImage -n 32 -s 32
- 00000020 4c 69 6e 75 78 2d 33 2e 34 2e 34 33 00 00 00 00 |Linux-3.4.43....|
- 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
- 00000040
- root@ubuntu:~/kernel/linux-sunxi-sunxi-3.4/output#
复制代码 前面一直没想起来,去找各个位置定义,后来突然想起struct里的定义和位置有关
大家参考这个:- root@ubuntu:~/kernel/linux-sunxi-sunxi-3.4/output# hexdump -C uImage -n 32
- 00000000 27 05 19 56 7f 91 23 3a 51 a1 53 0b 00 3f dd 28 |'..V..#:Q.S..?.(|
- 00000010 40 00 80 00 40 00 80 00 83 e5 d5 e1 05 02 02 00 |@...@...........|
- 00000020
复制代码 根据struct的定义,发现32字节的末尾有05 02 02 00,它们的定义在上面有贴,uint8_t类型,就是8个bit,一个byte:
05 Linux
02 ARM
02 KERNEL
00 无压缩
然后继续往前,__be32类型,32个bit有符号,也就是4个byte,struct里面写的是dcrc,看注释,data的crc,那么就是zImage的crc,这个嘛,用crc32程序看看(crc32是根据ubuntu提示安装的,叫libarchive-zip-perl)- root@ubuntu:~/kernel/linux-sunxi-sunxi-3.4/output# crc32 zImage
- 83e5d5e1
- root@ubuntu:~/kernel/linux-sunxi-sunxi-3.4/output#
复制代码 大家往上看,是不是有个83 e5 d5 e1?说明是正确的
再来,两个address
40 00 80 00 40 00 80 00
两个都是40 00 80 00
参考这个帖子,里面有内核引导数据:http://cn.cubieboard.org/forum.php?mod=viewthread&tid=601&extra=
没错,对了,就是40008000
再来,00 35 DD 28,是大小,data size,就是zImage的size
先用计算机换成10进制
0x0035dd28=4185384
然后呢:- root@ubuntu:~/kernel/linux-sunxi-sunxi-3.4/output# ls -l zImage
- -rwxr-xr-x 1 root root 4185384 Oct 2 17:58 zImage
- root@ubuntu:~/kernel/linux-sunxi-sunxi-3.4/output#
复制代码 啊哈~
接下来,timestamp,时间戳。
51 a1 53 0b=1369527051
网上找个时间戳转换工具http://tool.chinaz.com/Tools/unixtime.aspx
转换得2013年5月26日格林尼治标准时间+0800上午8时10分51秒
上面的hcrc个我就觉得有点奇怪了,header里面调header的CRC?!
附上函数:- int image_check_hcrc(const image_header_t *hdr)
- {
- ulong hcrc;
- ulong len = image_get_header_size();
- image_header_t header;
- /* Copy header so we can blank CRC field for re-calculation */
- memmove(&header, (char *)hdr, image_get_header_size());
- image_set_hcrc(&header, 0);
- hcrc = crc32(0, (unsigned char *)&header, len);
- return (hcrc == image_get_hcrc(hdr));
- }
复制代码 为啥用memmove,为啥不直接调用hdr?初学C,感觉有点奇怪
看了下:http://blog.csdn.net/ecbtnrt/article/details/6707113
看着一堆include的h文件发晕,大家有啥办法自动检测函数位置不?
跳过,继续,magic魔术,是判断是不是所需镜像的
内部定义:- #define IH_MAGIC 0x27051956 /* Image Magic */
复制代码 正好里面是27 05 19 56,也正好了
看的文章:
http://atmel.eefocus.com/article ... tml?sort=1098_0_0_0
http://bbs.chinaunix.net/thread-1916502-1-1.html
http://os.chinaunix.net/a2009/1203/1000/000001000100.shtml
http://www.360doc.com/content/09/0727/00/26398_4475381.shtml
http://blog.csdn.net/linweig/article/details/5044978
http://blog.csdn.net/ecbtnrt/article/details/6707113
|