[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Testing boot loaders



On Tue, Feb 28, 2017 at 07:38:28PM +0000, Mark Morgan Lloyd wrote:
> I wonder whether I could ask a general question, with a particular focus on
> Debian ARM devices.
> 
> I've got in front of me a file containing the image of an SD-Card that I've
> exfiltrated from a Kobo ereader onto which somebody wants me to put Debian.
> It appears to have a common or garden partition table at the start, live and
> recovery filesystems, and then a large storage area:
> 
> Device     Boot   Start     End Sectors  Size Id Type
> kobo.bin1         49152  573440  524289  256M 83 Linux
> kobo.bin2        573441 1097729  524289  256M 83 Linux
> kobo.bin3       1097730 7744511 6646782  3.2G  b W95 FAT32
> 
> I believe that there's a configured copy of U-Boot and the kernel in the
> unpartitioned area at the start of the device, there isn't any jump code in
> the partition table.
> 
> The device is based on the "Freescale MX50 Reference Design Platform", and
> kernel sources etc. are available on Github, I think I can see that the boot
> loader's entry is at 0xF8006458.
> 
> Is it possible to use Qemu or some comparable emulator to check the boot
> sequence in situ, i.e. without breaking the U-Boot and kernel images out
> into separate files?

Well in case you don't know, at least on the i.MX51 the boot code is
at offset 1024 bytes from the start of the device (so slightly after
the partition table).  I suspect the i.MX50 probably does the same, so
the u-boot or other boot code should be found between 1K and the start
of the first partition.

My guess would be .bin1 and .bin2 are primary and backup system
partitions, with the FAT32 purely for ebook storage and exposed as a
disk when a USB connection to another machine is made.

-- 
Len Sorensen


Reply to: