[PATCH] imx-image: Fix uninitialized add_barebox_header

[Trent Piepho]

On Thu, May 27, 2021 at 12:11 AM Sascha Hauer <sha at pengutronix.de> wrote:
> On Tue, May 25, 2021 at 11:58:56PM -0700, Trent Piepho wrote:
> > Note that ommiting -b, so as to not add a barebox header, still adds a
> > 1024 byte header, it's just blank.  I think it would be better if it was
> > not added at all.  If flashing to an SD card or eMMC main block, this
> > header overlaps the partition table, and so needs to not be flashed.
> > It's not part of the imx image.  It's just padding to place the imx
> > image at the correct location w.r.t. the start of flash.
>
> The idea is that you can put the imx image at the beginning of an SD/MMC
> card without knowing any offsets. Yes, you'll overwrite the partition
> table in that case, but once you know that you can skip/seek 512 bytes
> on both the image and the card and be done. Note that with newer i.MX
> SoCs like i.MX8 the offset was changed to 33k to support GPT partition
> tables. With i.MX8MP they changed the offset again to 32k. I think
> Having to know all these offsets is not better than the current
> situation.

It's still possible to use GPT with imx6-7.  The GPT table only uses
the 2nd sector (bytes 512-1023) as a fixed location.  The rest of the
GPT data has pointers to it from that sector and can be anywhere.
Convention is to place it immediately after, where it overlaps the imx
image, but it doesn't have to be there.  Five years ago I had to add
this feature to gptfdisk, but it's the option --move-main-table now.

Speaking of partition tables,it's possible to add the bootloader as a
partition.  Then I don't need to know the offset as the partition
table handles that.  And it means the bootloader shows up as being on
the disk, instead of hiding inside unallocated space, waiting to get
wiped out by something that doesn't think unallocated space needs to
be preserved.  And the partition has a size, so flashing to it will
not go past the end and clobber anything else.  Using unallocated
space on the whole disk device involves a much riskier dd command.

And I need to know where the bootloader is to make that partition
table.  So adding the padding to the image didn't help me to not need
to know where the bootloader goes.

When I make the sd image, I need to add an extra step to the script to
strip the padding, so I still need to know the offset there, and keep
it correct.  I.e., both the code that strips the padding and the code
that places the bootloader into the correct location in the image need
to know the size.

U-boot doesn't do this padding with its images, so any script that
makes a sd/emmc image for u-boot in buildroot, yocto, etc. needs to be
adapted for barebox to strip the header.

When it comes to flashing, I'm not aware of a good way to flash
barebox from barebox.  If it was unpadded, I'd just write it to a
partition.  But with padding and the default of no partition for
barebox, I do this:

# Ugly hack, specify size as 767kB, since we don't know the total file size, and
# that's all NXP's chosen env location allows barebox.  We need to use memcpy to
# skip the first 1kB, but memcpy has no option to use the source size.
echo "Ignore 'ran out of data' message that follows"
memcpy -s /mnt/nfs/barebox-nxp-imx6ul-evk.img -d /dev/mmc1 0x400 0x400 0xbfc00

But other than during bootloader development, no one flashes just the
bootloader.  It's all part of the build system that makes the full
image.  Everyone flashes that for new boards or uses their software
update system on existing ones.  So just the need to deal with header
stripping the image building portion remains.