I have a great amplifier that sadly no longer gets any support (a Kickstarter gone bad). It can however be upgraded with an .img file. The unit runs Linux and the OS is installed on some kind of embedded storage (not a disk drive)
I have tried writing the img to an SD card with no success. A lot of Kickstarter backers will be very happy if we can figure this one out.
Thanks
Update:
$ file usbupgrade_O.0.31.69.img
usbupgrade_O.0.31.69.img: data
Using binwalk as suggested by #duskwuff gave the following info:
$ binwalk usbupgrade_O.0.31.69.img
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
4096 0x1000 uImage header, header size: 64 bytes, header CRC: 0xC2CEE548, created: 2016-04-19 06:16:47, image size: 3219180 bytes, Data Address: 0x10008000, Entry Point: 0x10008000, data CRC: 0x47F1092, OS: Linux, CPU: ARM, image type: OS Kernel Image, compression type: none, image name: "Linux-3.0.35"
20871 0x5187 gzip compressed data, maximum compression, from Unix, NULL date (1970-01-01 00:00:00)
5246976 0x501000 OpenSSL encryption, salted, salt: 0x-187DE192-39315650
130464447 0x7C6BABF StuffIt Deluxe Segment (data): f$
148645351 0x8DC25E7 VMware4 disk image
So I guess it is an uImage. I´m a bit surprised of the VMware4 disk image, is this normal to include in this kind of images?
Related
I'm trying to analyze and understand an embedded system that runs linux.
I'm pretty new to linux boot process, embedded linux etc, so I have to learn a lot but prefer learning by doing. So analyzing a system is the way I try to understand all this.
I already got some insight and learnt a lot in just looking at the bootmsg, checking some scripts and provided files (firmware) and trying to understand what's going on by just searching for answers here and elsewhere in the net. This might also be the reason for some wrong expressions I might use, I hope you can understand anyways. Atm I am not able to ask the creator of this system directly, so I hope you might help me out with some answers here.
So the System got a SOC (Marvell Armada-370 88F6707-A1) with some Flash (128 MiB - Hynix NAND (HY27U1G8F2BTR)) and DRAM (512 MB) and seems to load the bootload U-Boot from SPI flash (1MB).
As mentioned above as U-Boot is used as bootloader which then loads some Linux version 3.2.34. I think I already understand quite a bit of the general boot process here, but got some questions depending the provided bootargs.
Following is an excerpt of the printenv command (U-Boot environment)
image_name=uImage
mtdids=nand0=nand0
mtdparts=mtdparts=nand0:8m(kernel),6m(Initrd),-(rootfs)
select0=nand info
load0=nand read.e 0x02000000 0 360000
loadr0=nand read.e 0x04000000 800000 300000
boot=bootm 0x02000000 0x4000000
bootcmd=run beep select0 load0 loadr0 boot || run beep beep beep errled
bootargs=console=ttyS0,115200 root=ubi0:rootfs ubi.mtd=3,2048 initrd=0x12000000 rootfstype=ubifs
beep=beep
I see that they load the kernel and compressed ramdisk content into ram load0=nand read.e 0x02000000 0 360000 and loadr0=nand read.e 0x04000000 800000 300000. The kernel at start looks at 0x04000000 for the ramdisk_image and uncompresses to use the content for initial rootfs. Then the usual process with linuxrc / init begins... at the end the normal file system from nand (here rootfs partition of ubi device 0) is loaded as stated in kernel command line (root=ubi0:rootfs ubi.mtd=3,2048 rootfstype=ubifs). This is what I understood is happening here and might be pretty straight forward.
What I'm wondering now is the following bootargs part initrd=0x12000000. I don't quite get why they provide a different address here when we already let the kernel know about the real of the compressed ramdisk (as a second parameter of bootm).
I started the system with and without this parameter and it seems there are no differences.
As in my understanding of reading about that initrd= argument is that it seems to do the same as the second parameter that is already passed to bootm, it tells the kernel where to find an initrd to load the initial rootfs.
Could anyone explain why we here pass two different locations to an initrd to the kernel? Is this just some obsolete stuff that was forgotten to remove or is there a reason for?
Thanks in advance for your help.
I hope I haven't missed anything and the question wasn't already answered here somewhere, but I couldn't find anything.
edit-2:
Thanks to #sawdust in the comments I understood better what actually is going on here and saw the importance to add some more information to the question so an answer will be clearer to understand.
Here is a short excerpt of the bootmsg
> bootm 0x02000000 0x4000000
## Booting kernel from Legacy Image at 02000000 ...
Image Name: Linux-3.2.34
Created: 2013-08-15 4:18:54 UTC
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 3464064 Bytes = 3.3 MB
Load Address: 00008000
Entry Point: 00008000
Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 04000000 ...
Image Name:
Created: 2013-09-10 10:38:37 UTC
Image Type: ARM Linux RAMDisk Image (gzip compressed)
Data Size: 3030739 Bytes = 2.9 MB
Load Address: 12000000
Entry Point: 12000000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
I also always missed some information in this part of bootm that might have already gave a hint on what's happening here. And might have in correlation to the presence of same address should have lead to the path of answer.
edit-1: Added some more information about the hardware
edit-2: Added bootmsg for more information
There are a lots of question teaching how to create a DMG file from Linux. But none of them is clear about how to add compression to it.
I usually create a DMG package to redistribute to MacOS, but I would like to add compression as Apple specifies.
Did anyone have a chance to try a tool that supports compression during DMG packing?
Similar questions without compression:
How can I generate a DMG file from a folder in Linux?
How to create dmg file in Centos through command line
It depends. Here is a good analysis of the .dmg format. From that document, the compression is specified for each block chunk:
Table: DMG blxx types
Type Scheme Meaning
0x00000000 --- Zero-Fill
0x00000001 UDRW/UDRO RAW or NULL compression (uncompressed)
0x00000002 --- Ignored/unknown
0x80000004 UDCO Apple Data Compression (ADC)
0x80000005 UDZO zLib data compression
0x80000006 UDBZ bz2lib data compression
0x7ffffffe --- No blocks - Comment: +beg and +end
0xffffffff --- No blocks - Identifies last blxx entry
To convert the gist of #Valerio's comment into a proper answer so nobody else misses it like I almost did:
According to this answer by #uckelman:
instal libdmg-hfsplus
Run dmg uncompressed.dmg compressed.dmg
I'm trying to understand embedded Linux principles and can't figure out addresses at u-boot output.
For example, I have UDOO board based on i.MX6 quad processor and I got following output from U-Boot:
U-Boot 2013.10-rc3 (Jan 20 2014 - 13:33:34)
CPU: Freescale i.MX6Q rev1.2 at 792 MHz
Reset cause: POR
Board: UDOO
DRAM: 1 GiB
MMC: FSL_SDHC: 0
No panel detected: default to LDB-WVGA
Display: LDB-WVGA (800x480)
In: serial
Out: serial
Err: serial
Net: using phy at 6
FEC [PRIME]
Warning: FEC MAC addresses don't match:
Address in SROM is 00:c0:08:88:a5:e6
Address in environment is 00:c0:08:88:9c:ce
Hit any key to stop autoboot: 0
Booting from mmc ...
4788388 bytes read in 303 ms (15.1 MiB/s)
## Booting kernel from Legacy Image at 12000000 ...
Image Name: Linux-3.0.35
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 4788324 Bytes = 4.6 MiB
Load Address: 10008000
Entry Point: 10008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
Starting kernel ...
I don't understand the value of Load address 0x10008000. According to documentation for this particular processor, at address zone 0x10000000 - 0xffffffff is mapped main memory. But what is 0x8000 offset? I can't figure out reason for this value.
I also don't understand address 0x12000000, where the kernel image is loaded from. Is there mapped memory region for SD card?
Please, can you give me some explanation for these addresses or even better, some references to resources about this topic. My goal is to learn how to port u-boot and Linux kernel to another boards.
Thank you!
If you check the environment variables of the u-boot, you will find that kernel image is copied from boot device to the RAM location(Here, 12000000) through command like fatload.
Now, This is not the LOADADDRESS. You give LOADADDRESS to command line while compiling the kernel, This address is mostly at 32K offset from start of the RAM in Physical address space of the processor.
Your RAM is mapped at 10000000 and kernel LOADADDRESS is 10008000(32K offset). bootm command uncompress the kernel image from 12000000 to 10008000 address and then calls the kernel entry point.
check out include/configs folder. It contains all the board definitions
i.MX uboot include/configs
To port uboot to another port, base on a very similar board and modify from there.
Is there any C# way to check an ISO file is valid or not i.e. valid Iso format or any other check possible or not.
The scenario is like, if any text file(or any other format file) is renamed to ISO and given it for further processing. I want to check weather this ISO file is a valid ISO file or not? Is there any way exist programmatically like to check any property of the file or file header or any other things
Thanks for any reply in advance
To quote the wiki gods:
There is no standard definition for ISO image files. ISO disc images
are uncompressed and do not use a particular container format; they
are a sector-by-sector copy of the data on an optical disc, stored
inside a binary file. ISO images are expected to contain the binary
image of an optical media file system (usually ISO 9660 and its
extensions or UDF), including the data in its files in binary format,
copied exactly as they were stored on the disc. The data inside the
ISO image will be structured according to the file system that was
used on the optical disc from which it was created.
reference
So you basically want to detect whether a file is an ISO file or not, and not so much check the file, to see if it's valid (e.g. incomplete, corrupted, ...) ?
There's no easy way to do that and there certainly is not a C# function (that I know of) that can do this.
The best way to approach this is to guess the amount of bytes per block stored in the ISO.
Guess, or simply try all possible situations one by one, unless you have an associated CUE file that actually stores this information. PS. If the ISO is accompanied by a same-name .CUE file then you can be 99.99% sure that it's an ISO file anyway.
Sizes would be 2048 (user data) or 2352 (raw or audio) bytes per block. Other sizes are possible as well !!!! I just mentioned the two most common ones. In case of 2352 bytes per block the user data starts at an offset in this block. Usually 16 or 24 depending on the Mode.
Next I would try to detect the CD/DVD file-systems. Assume that the image starts at sector 0 (although you could for safety implement a scan that assumes -150 to 16 for instance).
You'll need to look into specifics of ISO9660 and UDF for that. Sectors 16, 256 etc. will be interesting sectors to check !!
Bottom line, it's not an easy task to do and you will need to familiarize yourself with optical disc layouts and optical disc file-systems (ISO9660, UDF but possibly also HFS and even FAT on BD).
If you're digging into this I strongly suggest to get IsoBuster (www.isobuster.com) to help you see what the size per block is, what file systems there are, to inspect the different key blocks etc.
In addition to the answers above (and especially #peter's answer): I recently made a very simple Python tool for the detection of truncated/incomplete ISO images. Definitely not validation (which as #Jake1164 correctly points out is impossible), but possibly useful for some scenarios nevertheless. It also supports ISO images that contain Apple (HFS) partitions. For more details see the following blog post:
Detecting broken ISO images: introducing Isolyzer
And the software's Github repo is here:
Isolyzer
You may run md5sum command to check the integrity of an image
For example, here's a list of ISO: http://mirrors.usc.edu/pub/linux/distributions/centos/5.4/isos/x86_64/
You may run:
md5sum CentOS-5.4-x86_64-LiveCD.iso
The output is supposed to be the same as 1805b320aba665db3e8b1fe5bd5a14cc, which you may find from here:
http://mirrors.usc.edu/pub/linux/distributions/centos/5.4/isos/x86_64/md5sum.txt
I'm working on embedded platform (Broadcom's bcm5358u processor with MIPS core), where I need extra partitions for the purpose of further upgrade procedure. The filesystem used is SquashFS, so I modified 'struct mtd_partition' accordingly, which is passed to MTD related code, and I ended up with this:
#cat /proc/partitions
major minor #blocks name
- 31 0 128 mtdblock0
- 31 0 128 mtdblock0
- 31 1 6016 mtdblock1
- 31 2 4573 mtdblock2
- 31 3 6016 mtdblock3
- 31 4 4445 mtdblock4
- 31 5 4160 mtdblock5
- 31 6 64 mtdblock6
Now I want to be able to mount /dev/mtdblock4 as a temporary storage during system upgrade, but I can't do this, because it appears that this partition mtdblock4 doesn't have any FS installed. The kernel image and FS are integrated in one image, which is flashed down the /dev/mtdblock2 (which is supplied as root_fs to kernel).
I see only one solution: create a empty squashFS image, write it on /dev/mtdblock4 and may be it will work as I want (?). Is there a way to, like, format the partition on the fly, whenever the kernel boots, or it violates the MTD concepts?
Thanks.
You can mount a JFFS2 filesystem on an empty (erased) flash. It will automatically
"format" the flash partition at mount time. Squashfs is not a good candidate, because it is a read-only filesystem.
Is there a reason you can't create a mount a new FS on the fly?
You definitely do not want an empty squashFS image. If you want temporary writeable storage you can use something like a tmpfs volume. If you need to support a system reboot, you can use JFFS on a raw flash device. You should be able to format/mount the MTD devices just like any other block device.
Thanks for responses.
Yes, SquashFS is read-only, but nevertheless I'm able to update my system via Web interface provided by the platform vendor. The platform SDK provides API to directly access MTD from user space.