Add Das U-Boot fork to image builder

[chroco]

U-boot is set at v2024.10 and modified to boot OreSat boards.

Add a patch for image-builder/tools/build_images.sh to use /boot/extlinux/extlinux.conf.

Remove depricated /boot/uEnv/oresat-dev-uEnv.txt.

Add image-builder and u-boot as submodules and modify Makefile to build them. Reorganize oresat-linux with u-boot and image-builder submodules in the same folder.

Add example EEPROM boot strings and u-boot console commands to UBOOT_README.md.

Add scripts/write_uboot.sh. This script can be used to flash u-boot to a sd card.

[ThirteenFish]

Since we now have our own custom config in am335x_oresat.config this file can be deleted. We start from u-boot's am335x_evm_defconfig so there's no need to keep a copy of it ourselves.

[ThirteenFish]

It's a bit confusing that this file is named extlinux. While it does contain some extlinux config options, it also contains bootloader and kernel parameters as well. Additionally the other confs in hwpack are all named after boards. Going by the second line comment it looks like the original name was going to be oresat.conf (don't forget to update this) but I can see why the name was changed, that directory is getting a bit overloaded on the .conf names. How about something like oresat-board.conf or oresat-bootloader.conf?

[ThirteenFish]

This entire block of config can just be deleted except maybe loops_per_jiffy. These are all weird for a variety of reasons:

• usbnet_mem does not get set so explicitly unsetting it doesn't do anything. It's also used in only two places, keeping a minimum amount of free virtual memory around and in SOC.sh, an apparently vestigial boot config script that is no longer used.
• dtb also does not get set explicitly anywhere and is used in both the defunct files uEnv.txt and SOC.sh
• SERIAL is only used in SOC.sh. ttyO0 also conflicts with the ttyS0 set in extlinux.
• drm_device_identifier is the default video out, of which we have none.
• rng_core being set to default_quality=100 is one of those suspicious numbers. It's supposed to be 0-1024 and controls how much to trust a CPU's hwrng, the max value being trust completely. The concern here is the hwrng may be compromised but the benefit is getting a lot of entropy quickly speeds up boot. I wonder if they wanted to go for max trust for quick boot but thought the scale was 0-100. Either way we don't really care about compromised hwrngs so we'd want the max value which the kernel defaults to if this value is unset.
• loops_per_jiffy in the admin docs claim that this can be auto-detected at boot but may slow down the boot by up to a couple hundered milliseconds. It also says to determine the right value we should boot first in auto-detect mode and then ask the kernel what value it picked and use that number in the setting so we should verify that for ourselves before committing to it. Or just see if there's a noticeable slowdown in boot by removing it and leave it off if there isn't.
• uboot_cape_overlays is commented out, delete it. Also we don't use cape overlays.
• conf_eeprom_compare is not used in sdcard_setup.sh. Apparently that feature got dropped a while ago but they forgot to remove it from the example configs.

[ThirteenFish]

This should utilize the features of make better. make is more than a shellscript with names, it is its own whole tool with its own language and rules. The general mindset is to try to write rules where the left hand side (the targets) are the files you want to produce and the right hand side (the prerequisites) are the files they are produced from. I'll recommend giving the make manual a browse - it's well written and in-depth.

Take for example the u-boot rule below. In the rule recipe it uses the shell to test for the existence of files, but that's the prime function of make rules. make will build targets if they don't exist (and are older than the prerequisites) for you. The magic of make is if most of your rule targets are files it will selectively only build the files that need to be built. For the u-boot rule specifically the outputs are the files MLO and u-boot-dtb.img so those should go in the target place. Because this rule produces two targets it needs the specialized group target as opposed to the default independent targets. For prerequisites u-boot specifically wants to input the config am335x_oresat.config because we'll likely change that during normal development. It also technically it depends on the whole u-boot project but we shouldn't be touching those files outside of updating the submodule so it can suffice to ensure it's initialized. The rule becomes:

$(UBOOT_REPO)/MLO $(UBOOT_REPO)/u-boot-dtb.img &: $(CONFIG) test
	KCONFIG_CONFIG=../$(CONFIG) $(FLAGS) make -C $(UBOOT_REPO)

Note that u-boot doesn't actually depend on device_trees any more and the mrproper call should be done in clean to avoid unnecessary u-boot rebuilding.

The next rule where make should be used for checking files instead of the shell is test. This one is a little more awkward because a glaring hole of make in my opinion is there's no good way to check if a directory is empty. The recommended way is to pick a sentinel file to check and for submodules a good pick is the readme. Additionally the make function $(error) should be used for reporting errors. So test becomes:

$(UBOOT_REPO)/README $(IMAGE_BUILDER_REPO)/readme.md :
	$(error $(dir $@) not initialized. Hint: git submodule update --init)

Note that these are independent instead of group targets so the u-boot related rule can depend only on the u-boot repo and not care about the image-builder repo and vice versa. Also $(dir $@) to get the directory name of the current target.

Finally the variable $(list) isn't used, but I think I can see what you were trying to go for, I think you were missing $@ which expands to the name of the current target:

$(list):
	./build_images.sh $@

Now you can say make c3 instead of make board=c3. Note that this rule is missing prerequisites that should be there.

Putting it all together the whole makefile should look something like:

CONFIG ?= am335x_oresat.config
boards = c3 cfc dev dxwifi generic gps star-tracker

ARCH= $(shell uname -m)
ifeq ($(ARCH), armv7l)
	FLAGS =
else
	FLAGS = ARCH=arm CROSS_COMPILE=arm-none-eabi-
endif

.PHONY: all clean $(boards)

all: c3

$(boards): build_images.sh device_trees u-boot/MLO u-boot/u-boot-dtb.img | image_builder/readme.md
	./build_images.sh $@

device_trees:
	make -C ../device_trees

u-boot/MLO u-boot/u-boot-dtb.img &: $(CONFIG) | u-boot/README
	KCONFIG_CONFIG=../$(CONFIG) $(FLAGS) make -C u-boot

u-boot/README image-builder/readme.md:
	$(error $(dir $@) not initialized. Hint: git submodule update --init)

clean:
	rm -f image_builder/configs/oresat*
	rm -f image_builder/target/chroot/oresat*
	rm -f image_builder/tools/hwpack/extlinux.conf
	make mrproper -C u-boot
	make clean -C ../device_trees

Ideally the device_trees target should be file-based as well but it would be much easier to do with changes to that makefile first so I've left this as is. Note also:

• Ensuing .PHONY has only real rules in them
• clean cleans only the things that this makefile generates (it's no longer producing setup_sdcard.sh.rej)
• using | to indicate that we only care about the existence of the following prerequisites, not update time. These are known as order-only prerequisites. Good for directory and submodule related stuff.
• Using ?= to indicate an input parameter. It's reasonable that we during development might want to test with a differently named config file and so conditional assignment is the conventional way to indicate it
• Folding in other path names. We probably don't want to have the image-builder, device_trees, or u-boot paths to be configurable, and it's a bit more readable then to bake them into the use locations directly. Picking which things to turn into variables is a bit of a matter of taste but too much use of variables as simple renames can make things harder to read. If we do want them configurable then they should be ?= conditionally assigned.
• defaulting to c3 if no board has been specified.

As more of build_images.sh gets moved into this makefile we can then be much more selective about which things get built.

[ThirteenFish]

This is good, this is the file that we should be storing for u-boot configs in the oresat-linux project. The only thing is possibly document in the README what this file is based on (am335x_evm_defconfig) and our changed config options (CONFIG_BOOTDELAY). Alternatively this information could go in the commit message, as long as it's clear, and then further commits changing this file can also keep a log of what config options were changed.