Brook Milligan <br...@nmsu.edu> writes: >> On Jun 24, 2022, at 12:45 PM, Jason Thorpe <thor...@me.com> wrote: >> >>> On Jun 24, 2022, at 11:02 AM, Brook Milligan <br...@nmsu.edu> wrote: >>> >>> build.sh works great to create, for example, binary/gzimg/armv7.img.gz. >>> >>> However, that is not necessarily a bootable image, at least on some >>> systems. In addition, various u-boot magic files must be added to >>> the FAT partition at the beginning of armv7.img to make it >>> bootable. >> >> installboot(8) (and the tool-ified version) has support for plopping the >> correct uboot into the image. You need to install the uboot packages first. > > Thanks. So all that is needed is the following (for cross compiling): > > gzip -c -d < /path/to/release/evbarm-earmv7hf/binary/gzimg/armv7.img.gz > > /tmp/armv7.img > env INSTALLBOOT_UBOOT_PATHS=/path/to/pkg/share/u-boot > /path/to/tools/bin/nbinstallboot -m evbarm -o board=ti,am335x-bone-black > /tmp/armv7.img > > Does it make sense to consider a command line option for installboot that > sets the u-boot path so the environment variable is not needed? > > In answer to my original question, I think this means that all the > images on armbsd.org can be created with a loop over the various > boards with each iteration running the two commands above. Is that > correct? Is that what is happening?
As someone on the outside, I think it would be good to have checked-in scripts with comments about what they depend on. I can see that those that do this think that's unnecessary, but also that it is documentation of the process for almost everybody else.
signature.asc
Description: PGP signature
