mail archive of the barebox mailing list
 help / color / mirror / Atom feed
* [PATCH] imx-image: Fix uninitialized add_barebox_header
@ 2021-05-26  6:58 Trent Piepho
  2021-05-27  7:11 ` Sascha Hauer
  0 siblings, 1 reply; 4+ messages in thread
From: Trent Piepho @ 2021-05-26  6:58 UTC (permalink / raw)
  To: barebox; +Cc: Trent Piepho

From: Trent Piepho <tpiepho@gmail.com>

It's set to 1 if the -b option is used, but is neither initialized nor
set to 0 if not.  Since the barebox image building recipies only uses -b
with this tool, it wasn't noticed.

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.

Signed-off-by: Trent Piepho <tpiepho@gmail.com>
---
 scripts/imx/imx-image.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/imx/imx-image.c b/scripts/imx/imx-image.c
index 3e277e82f..b97f56189 100644
--- a/scripts/imx/imx-image.c
+++ b/scripts/imx/imx-image.c
@@ -770,7 +770,7 @@ int main(int argc, char *argv[])
 	int outfd;
 	int dcd_only = 0;
 	int now = 0;
-	int add_barebox_header;
+	int add_barebox_header = 0;
 	uint32_t barebox_image_size = 0;
 	struct config_data data = {
 		.image_ivt_offset = 0xffffffff,
-- 
2.26.2


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] imx-image: Fix uninitialized add_barebox_header
  2021-05-26  6:58 [PATCH] imx-image: Fix uninitialized add_barebox_header Trent Piepho
@ 2021-05-27  7:11 ` Sascha Hauer
  2021-05-27  8:13   ` Trent Piepho
  0 siblings, 1 reply; 4+ messages in thread
From: Sascha Hauer @ 2021-05-27  7:11 UTC (permalink / raw)
  To: Trent Piepho; +Cc: barebox

On Tue, May 25, 2021 at 11:58:56PM -0700, Trent Piepho wrote:
> From: Trent Piepho <tpiepho@gmail.com>
> 
> It's set to 1 if the -b option is used, but is neither initialized nor
> set to 0 if not.  Since the barebox image building recipies only uses -b
> with this tool, it wasn't noticed.

Applied to master, thanks.

> 
> 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.

Sascha

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] imx-image: Fix uninitialized add_barebox_header
  2021-05-27  7:11 ` Sascha Hauer
@ 2021-05-27  8:13   ` Trent Piepho
  2021-05-27  9:21     ` Sascha Hauer
  0 siblings, 1 reply; 4+ messages in thread
From: Trent Piepho @ 2021-05-27  8:13 UTC (permalink / raw)
  To: Sascha Hauer; +Cc: Trent Piepho, barebox

On Thu, May 27, 2021 at 12:11 AM Sascha Hauer <sha@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.

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] imx-image: Fix uninitialized add_barebox_header
  2021-05-27  8:13   ` Trent Piepho
@ 2021-05-27  9:21     ` Sascha Hauer
  0 siblings, 0 replies; 4+ messages in thread
From: Sascha Hauer @ 2021-05-27  9:21 UTC (permalink / raw)
  To: Trent Piepho; +Cc: Trent Piepho, barebox

On Thu, May 27, 2021 at 01:13:29AM -0700, Trent Piepho wrote:
> On Thu, May 27, 2021 at 12:11 AM Sascha Hauer <sha@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

You are probably not aware of the barebox_update command which handles
all these ugly details and does more for you like powerfail safe update
on devices that support it or checking the image type before flashing
it.

Putting the bootloader in a partition has its problems as well, like you
have to create a very special partition table. Anyway, you made some
valid arguments. How about adding a Kconfig option that lets you decide
which images you want to have? That would also be a good place to
document the differences.

Just changing the behaviour of the '-b' option might not be the best
idea as this was introduced to insert the initial barebox opcode into
the image, not to prepend another header to the image. I think we should
introduce a new option for this purpose.

Sascha

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2021-05-27  9:23 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-05-26  6:58 [PATCH] imx-image: Fix uninitialized add_barebox_header Trent Piepho
2021-05-27  7:11 ` Sascha Hauer
2021-05-27  8:13   ` Trent Piepho
2021-05-27  9:21     ` Sascha Hauer

mail archive of the barebox mailing list

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://lore.barebox.org/barebox/0 barebox/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 barebox barebox/ https://lore.barebox.org/barebox \
		barebox@lists.infradead.org barebox@lists.infradead.org
	public-inbox-index barebox

Example config snippet for mirrors.


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git