As you may have guessed, the same personal circumstances affected this development cycle too.
Read more in the previous announcement.

What's new?

A part of the changes were made to help future proof releases, by reducing the direct involvement required from any particular individual.

See also the milestone and git history:

• https://github.com/Tow-Boot/Tow-Boot/issues?q=milestone%3A2023.07-007
• release-2022.07-006...release-2023.07-007

New boards

• libreComputer-amlS905xCc (#213)
• orangePi-pc2 (#229)
• libreComputer-allH3CcH5 @shvetsnikita (#256)
• friendlyElec-nanoPiM1 @shvetsnikita (#257)
• friendlyElec-nanoPiM1Plus @shvetsnikita (#275)

Dependencies

Some of the dependencies have been updated:

• The build tooling (Nixpkgs) has been updated.
• U-Boot 2022.07 → 2023.07
• TF-A 2.6 → 2.9
• crust-firmware 0.5 → untagged revision from 2023-02-28

Continuous Integration (#201)

With initial help from @jirutka, Tow-Boot changes are now built automatically using GitHub Actions.

These builds are the ones being uploaded to the release tag, removing one manual operation from the release workflow.

Use of a unified tree (#238)

Tow-Boot changes on top of U-Boot are now tracked as branches in a repository.

This removes all the patches from the main Tow-Boot repository. This also ensures none of the patch conflict in unintended ways, as they are now always applied.

With these changes, it is also now possible to test against a stock U-Boot using the same build tooling.
This is mainly useful to verify whether or not our changes to U-Boot are causing observed issues.

uSWID support

uSWID data is now generated and appended to out platform firmware binaries.

At this current point in time, it is not used by Tow-Boot or any of its tooling.
It does, however, hash the full build inputs information through using the $out path of the derivation as part of the tag-id value.

Board-specific improvements

All Rockchip

Rockchip devices now support powering off from U-Boot (and thus UEFI) properly.

Additional mentions

Sometimes it happens that contributions can't be used, be it because they were superseded by something else, implemented differently, or unneeded past an update.

The linked PRs should include the actual resolution in use in the comments.

Here's those that I think deserve a mention:

• @ArenM who got caught re-doing the TF-A update I already has in a branch #250
• @IreneKnapp who took an early stab at updating the base U-Boot #220

U-Boot notes

Since U-Boot changes are now independently tracked the release notes are too.

• Fix booting defconfig kernels on RK3399 @artemist (#3)[https://github.com/Tow-Boot/U-Boot/pull/3]

I'm probably missing some notable changes here.
Though I think mainly they were cleanups to either make them more upstreamable, or work better in a unified tree.

See also the tag commit for a complete overview of the changes compared to U-Boot:

• https://github.com/Tow-Boot/U-Boot/releases/tag/tb-2023.07-007
• Tow-Boot/U-Boot@v2023.07...tb-2023.07-007

I won't go into the details of what happened, but note that I am looking into future-proofing the project such that a long hiatus like that will not depend on a single individual.
Read more in a small announcement I shared previously in the matrix room.

What's new?

A few months late, this update syncs Tow-Boot with version 2022.07 of U-Boot.

See also the milestone and git history:

• https://github.com/Tow-Boot/Tow-Boot/issues?q=milestone%3A2022.07-006
• release-2021.10-005...release-2022.07-006

Misc. Changes

• Tow-Boot exposes itself better as being not exactly U-Boot #206
• SMBIOS information is now more globally correct #207

Documentation changes

• Documentation fixes around serial usage #182 (@psstoyanov)

Board-specific changes

• Amlogic

  • Predictable boot order has been fixed (prefers eMMC before SD)

• Pinephone Pro

  • Prevent the proximity sensor for being broken #194 (@antoniprzybylik)
  • Ensure GPIO for STK3311 is configured in an expected state #195 (@antoniprzybylik)
  • The PMIC gets configured eagerly to prevent bootloop once an OS starts. #211

Additional mentions

Sometimes it happens that contributions can't be used, be it because they were superseded by something else, implemented differently, or unneeded past an update.

The linked PRs should include the actual resolution in use in the comments.

Here's those that I think deserve a mention:

• @pinkuuu1 attempted to fix the Pinephone Pro PMIC bootloop #168
• @jirutka attempted to get USB working working at boot on RockPi4 #199
• @axelsimon attempted to fix a device cross-link issue in the docs #221

That's pretty much it.

If you're not booting your operating system via UEFI, there is no need to upgrade.

Time was scarce to do what I expected to do for this release, and even then I ended up releasing way late.

This release improves device information made available through SMBIOS tables. This data is available when the Operating System is booted through UEFI, and before would often present the fallback data.

So instead of having the system advertise their identity as Unknown Product made by Unknown, the system will show useful information.

This information will either be the platform-specific information added to the driver, like in #135 by @MartijnBraam. Some systems in upstream U-Boot already provide that information, and it will be preferred.

Since it would be preferable to always have useful information, fallback information is now taken from the Tow-Boot knowledge of the current build #158 when the system does not include data. The upstream data is preferred as it improves compatibility with non Tow-Boot implementations.

In platform-specific changes, The ODROID-N2+ support was improved with support for its XT25Q64D SPI Flash chip #149, by @ulrikstrid.

See also other documentation fixes and minor fixes, listed in the milestone:

• https://github.com/Tow-Boot/Tow-Boot/milestone/3?closed=1

Thank you @CRTified, @MartijnBraam, @ulrikstrid, @flokli, and @tpwrules for the contributions.

What's new?

All of this:

• https://github.com/Tow-Boot/Tow-Boot/milestone/2?closed=1

But here's some highlights

Phone and tablet UX

With #67, we now build Tow-Boot with a user experience optimized for phones, while supporting the use case of phones without display enablement in U-Boot.

These builds should enable users to live the dream of EBBR but on their phones.

Rework of the build infra

#78 is more for Tow-Boot developers. It changes from an ad-hoc functional build pipeline, which was getting hard to maintain, to a build system building on top of the modules system used also by NixOS.

This provides better semantics for the developers, reducing needless repetitions.

Operating System Boot Order fixes

With the -003 release, a form of regression slipped through that changed the boot order of some boards. When fixing the regression, it was observed that there was less consistency than assumed in the boot order.

Boot order has been reviewed with #92, and verified to be consistent across platforms. Internal storage devices are preferred to external devices.

New boards

• pine64-pinephoneA64
• pine64-pinephonePro
• radxa-zero2
• radxa-RockPi4 (A/B) (Thank you @CRTified)

Hello! 👋

Not a lot of changes. Dependencies updates, and two new boards.

I'm still marking this as a pre-release, under the same caveats as previously described. Mainly that this is probably fine for daily use, but lacking mainly in documentation. After all, the main changes here are version upgrade in dependencies, no behaviour should differ.

(Just in time to be outdated? Yeah, just over a week after the release of U-Boot 2022.01!)

New boards

• odroid-N2 (Thank you @L-as)
• radxa-RockPi4C (Tank you @CRTified)

U-Boot 2021.04 → 2021.10

This is a simple upgrade, changes have been rebased on top of 2021.10. I don't know if there's anything to be truly excited about.

There are regressions upstream for RK3399 boards and eMMC, but they all have been taken care of using already upstreamed or being-upstreamed changes.

TF-A 2.5 → 2.6

A simple upgrade, yet again.

The suspend patch for the Pinebook Pro has been dropped, as it was mainlined.

Hi!

I was surprised by some uses of Tow-Boot outside of the initial soft launch circle! But it's not like it's a problem or anything, the reception was good :).

I'm making what should have been "soft launch release 2", which is mainly bug fixes, and some improvements. I still haven't taken the time to look into making the life easier for non-Nix users, which was the main goal for the actual next "less soft" launch.

Anyway, here's what's in this release.

Changes

With #34, we are now producing distinct builds for SPI installation, and shared storage. These variants have one major distinction: the SPI build saves the environment to the SPI Flash, while the other (noenv) does not allow saving the environment. Note that in a future update, saving the environment will be added as a feature for shared storage installations.

SPI Flashing has been improved in #36. Some hardening steps have been added, mainly to ensure that in the event of a stray reset, the SPI Flash would not be used as a boot option during the boot process. This should reduce most risks in updating the SPI Flash contents. Additionally, the installer now verifies it is installing to the right board.

A website is now produced from the documentation. (#40)

With #22, we are now providing all patches, in addition to the configuration, used to build the released binaries. This means that a user should be able to "rehydrate" a working tree on top of the correct U-Boot version and build the equivalent product. Helps show the recipe to the secret sauce!

Support was added for a new board the Olimex Teres-I in #26, by @Thra11.

Breaking changes

Updating SPI Flash from 001 to 002

In Tow-Boot 001, there was no validation for the board when installing or upgrading the SPI Flash.

With the update to 002, changes in #36, upgrading now checks for $board_identifier, which will be unset on Tow-Boot 001.

On some platforms it is not an issue. E.g. on Allwinner A64, the Boot ROM firmware load order starts with SD, so it should use the firmware from the SD card, which will have the appropriate identifier.

On many other platforms, e.g. amlogic and rockchip, this is not the case.

The workaround is to run env default board_identifier from the firmware console before updating. Another workaround would be to completely erase the SPI Flash, which does not validate the board identifier. Then rebooting and installing should work. Neither option is better than the other, pick the one you prefer.

File names change

The file naming scheme has changed. All boards now produce artifacts with approximately the same names. This is not really a breaking change, but really more something to be aware of for external instructions. (#34)

Environment

If any builds were using the environment, e.g. from FAT32, EXT4, or SPI, it is almost definitive that with this release it will either not work anymore (for shared storage installations) or the environment will be lost this upgrade for SPI installations. This is by design, first to reduce confusion from stray environments left by other U-Boot installs, and second, to reduce confusion about the provenance of the environment. (#34)

Harmonized baud rate

With this release, all boards use the 115200 serial baud rate. Nothing needs to be done on your device. Just be aware when using a serial connection. (#33)

Other changes

• #11 minor fix to the "fast graphical console" workaround, preventing garbage on scroll
• #16 fixes to PDCurses without vidconsole
• #17 cancels ^C effects while running autoboot
• #20 fixes wording on rescan usb option (@b-)
• #35 fixes logo on Raspberry Pi family
• #38 Nixpkgs checkout updated
• #39 arm-trusted firmware upgraded from 2.4 to 2.5

Device-specific

• #13 customizes default FDT for the Pinebook Pro, providing battery fuel gauge nodes (@zhaofengli)
• #21 works around UEFI poweroff issues on RK3399 devices

Build notes

Built using

 $ env -i nix-build release.nix

Known issues

• Upgrading from release 001 may be problematic on platforms that did not have setexpr enabled in 001. (#45)

Read the unveiling post:

• https://samuel.dionne-riel.com/blog/2021/05/10/unveiling-tow-boot.html

Built using

 $ env -i nix-build release.nix

Known issues

Using saveenv with the SPI builds may render the system unbootable.

See: #19