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

Re: Testing boot loaders



On 28/02/17 22:30, Lennart Sorensen wrote:
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.

Yes, I agree. What I don't know yet is whether there's a comparatively straightforward way to copy the loader (plus its header etc.) into the appropriate area of Qemu's address space and then transfer to it. Ideally after that there would be enough startup messages to indicate that the kernel was running, even if there wasn't emulated framebuffer hardware.

I think that the latest Qemu might have MX50 support, but at this stage it's the initial boot that's interesting.

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.

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]


Reply to: