Buildroot is generating images for an embedded device where they should run. This is working very well. In those images, the rootfs is included.
Due to some research, I’d like to look into that generated file (e.g. different compression modes set by the Buildroot were applied and now shall be checked if they were correctly done), but I can’t find something useful in the Net.
As far as I know, the difference between a uImage and zImage is just a small header, so u-boot is able to read that binary file. But I can open neither uImage nor the zImage.
Can anyone give me a hint of how to decompress those (u/z)Images on the host?
Answers:
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
Method 1
mkimage -l uImage
Will dump the information in the header.
tail -c+65 < uImage > out
Will get the content.
tail -c+65 < uImage | gunzip > out
will get it uncompressed if it was gzip-compressed.
If that was an initramfs, you can do cpio -t < out or pax < out to list the content.
If it’s a ramdisk image, you can try and mount it with:
mount -ro loop out /mnt
file out could tell you more about what it is.
Method 2
U-Boot brings its own dumpimage tool (find it in the tools directory of your U-Boot tree)
Of course it works with simple images, but it also supports the old-style multi images
$ ~2/tools/dumpimage -l uMulti Image Name: Created: Thu Aug 31 19:54:29 2017 Image Type: ARM Linux Multi-File Image (uncompressed) Data Size: 5678650 Bytes = 5545.56 kB = 5.42 MB Load Address: 10008000 Entry Point: 10008000 Contents: Image 0: 5028760 Bytes = 4910.90 kB = 4.80 MB Image 1: 602111 Bytes = 588.00 kB = 0.57 MB Image 2: 47762 Bytes = 46.64 kB = 0.05 MB $ ~2/tools/dumpimage -i uMulti kernel.extracted $ ~2/tools/dumpimage -i uMulti -p 1 initramfs.extracted $ ~2/tools/dumpimage -i uMulti -p 2 device-tree.extracted
Have not tried it with new style FIT images yet, but I guess it should just work.
Method 3
In case there are several images inside here is a quick bash script to extract them all into the files image_0, image_1, …:
#!/bin/bash
src_file=uImage
declare -ia sizes=( $(mkimage -l "$src_file" |
awk '/^ +Image [0-9]+/ { print $3 }') )
declare -i offset="68+4*${#sizes[@]}"
declare -i size
for i in "${!sizes[@]}"; do
size=${sizes[$i]}
echo "Unpacking image_$i"
dd if="$src_file" of="image_$i" bs=1 skip="$offset" count="$size"
# going to offset of next file while rounding to 4 byte multiple
offset+=$(( size + (4 - size % 4) % 4 ))
done
You then need to check then what is what (could be a packed Linux kernel, archive with files, device tree, …). file and binwalk (http://binwalk.org/) might be helpful.
Method 4
7z “just works” for me, though this may be specific to OpenWRT and SquashFS. I tried it based on a comment on the OpenWRT forums.
$ file image.bin image.bin: u-boot legacy uImage, OpenWrt fullimage, Linux/MIPS, Multi-File Image (Not compressed), 11334834 bytes, Mon Apr 12 09:59:28 2021, Load Address: 00000000, Entry Point: 00000000, Header CRC: 0XDFDE3FF5, Data CRC: 0X7704142B $ 7z x image.bin 7-Zip [64] 17.04 : Copyright (c) 1999-2021 Igor Pavlov : 2017-08-28 p7zip Version 17.04 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,16 CPUs x64) Scanning the drive for archives: 1 file, 11334898 bytes (11 MiB) Extracting archive: image.bin -- Path = image.bin Type = SquashFS Offset = 2097224 Physical Size = 9237674 Headers Size = 47040 File System = SquashFS 4.0 Method = XZ Cluster Size = 262144 Big-endian = - Created = 2021-04-12 04:59:26 Characteristics = DUPLICATES_REMOVED EXPORTABLE 0x600 Code Page = UTF-8 Everything is Ok Folders: 145 Files: 2518 Size: 36789620 Compressed: 11334898
All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0