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