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@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/barebox
