The BR2_GCC_ENABLE_LTO config used to enable LTO on compiler level. That
config symbol doesn't exist anymore. Instead, LTO is enabled by default
with GCC.
However, there is a new flag named BR2_ENABLE_LTO which enables LTO in
packages. So far it doesn't look like that packages we are using support
the flag, but that might get added in the feature. Opt-in already today.
* Determine git reference in prepare step
We can determin the git reference used once in the prepare step.
* Build HAOS builder in prepare step
Instead of building the build container multiple times, simply build it
once in the prepare step. This saves some GitHub Runner time (as we only
need to create the builder once).
* Drop per PR builds
Drop the per PR builds which are based on pull_request_target. These
make things more complicated with the recent changes requiring two
deployment approvals since we use the environment in for the prepare
and build job now. It will also interfere with future expansions.
We should consider readding the feature using `pull_request` and
subsequent `workflow_run` trigger, as suggested by
https://securitylab.github.com/research/github-actions-preventing-pwn-requests/.
* Simplify board filter
In case a group with the same id as used outside the container already
exists, do not create a group inside the container.
It seems that GitHub Action runners started to use primary group id 999
which is the default group id used by the Docker daemon.
Home Assistant Green uses a SPI NOR flash storage. One can use dd to
write to the SPI NOR flash, but this is problematic if a unit has bad
blocks. Add MTD tools, specifically flashcp, to enable SPI NOR
flashing support.
Update U-Boot board configuration for Home Assistant Green. This moves
all Green specific board configuration into the U-Boot source code
patches. The "sf probe" command now picks up the correct SPI bus by
default.
* Initial commit of Home Assistant Green board support
* Add Home Assistant Green boot files
* HA Green board configs
* board/nabucasa: Unsupport rtc rk808
* Use odroid-m1 as Supervisor machine for now
* Green: linux: pmic: set set PWRON_LP_OFF_TIME 12s
* green: Update U-Boot to 2023.07.02
* green: supports usb boot
* green: uboot-boot.ush use rk3566-ha-green.dtb
* green: spinor supports uboot
* green: use U-Boot provided devtype as boot device type
* green: Fix polarity of power key
The power key is low active. Add patch to avoid accidential long press
being reported to user space.
* green: uboot: eeprom: add CONFIG_ENV_OVERWRITE
* green: uboot: eerprom: add mac read
* green: fix-cpufreq null issue
* green: board aliases ethernet0
* green: uboot mac set ethernet0
* green: uboot add serial-number read
* green: Update kernel 6.1.39
* green: add green to the build matrix
* green: fix 339d13 & 9b9416 can not boot from usb
* green: changfe sd mode, change led default state
* green: uboot add board.c to read eeprom info
* green: enable uboot to read eeprom info
* green: delete boot.scr read eeprom function
* green: change spl loader uboot order:sd-emmc-spi_nor
* green: serialnum change to 18 bytes
* green: Update kernel 6.1.43
* green: use hwrng support from ODROID-M1
* green: Use latest Rockchip BL31/DDR binaries
* change led_act polarity
* green: Disable watchdog
The watchdog on Green seems to not reliably reset the system. For now
disable the driver to avoid systemd making use of it.
* green: Update kernel 6.1.44
* green: Fix Supervisor Machine
Use odroid-m1 for now as Supervisor machine (used to download the
landing page).
* green: emmc use hs200 to increase speed
* green: use green as Supervisor machine
* green: Update kernel 6.1.45
* green: add Green to the kernel documentation
---------
Co-authored-by: Zhangqun Ming <north_sea@qq.com>
Co-authored-by: syan <syan.cham@gmail.com>
Use the official rkbin repository for Rockchip binaries. Use the
binaries from an older git hash which provide the very same binaries
(by hash). This makes sure we use the same DDR version as currently used
by the Hardkernel in their SPI flash bootloader (DDR v1.09).
* Including the RTW8821ce driver module to support Wifi on the KAMRUI AK1 PRO micro PC. It is a low-cost Intel Celeron N5105 that I think should work well for Home Assistant. However, it does not use Intel radios, it needs Realtek drivers.
* also need the firmware for the rtl8821ce
* Use hosted GitHub Action runners
Instead of using self-hosted runners use the hosted GitHub Action
runners. Officially the GitHub Action runners have a maximum of 14GB
free space available. However, a single Home Assistant OS build requires
up to 23GB (the ova board seems to require most because of the various
output image formats).
This PR adds some tricks to make use of the GitHub hosted GitHub Action
runners still, namely:
- Build and download cache is stored on /mnt which offers an additional
10GB of disk space
- Some tools/SDKs on the runner get removed from the root disk to free
up some disk space.
Other than that building on the hosted GitHub Action runners seems
straight forward. The build time is significantly longer (from ~30
minutes on the current AMD Ryzen 7950X build machine to 1 hours 30
minutes even with cache). But since we can build all boards in parallel
now, the overall build time will likely be shorted.
* Remove top-level release directory
The top-level release directory adds another copy of the images. This is
unnecessary for our release process now. Save the additional space and
time requirement. It comes with a slight downside for developers, but
also helps to save disk space on dev machines.
The chosen GitHub action sets MIME types correctly and allows glob
uploads. Also upload directly from the output directory. This way we can
remove the unnecessary copy to the release directory in the future.
Add patches for the hardware random number generator part of the
Rockchip RK3568. This avoids dbus-broker startup failure seen on some
Hardkernel ODROID-M1 devices due to lack of entropy.
On some platforms (it seems to be pronounced on Intel NUC systems)
Bluetooth advertisements suddenly stop after a short while. Currently
there are work arounds in place to restart the HCI controller to keep
receiving the advertisements.
Advertisements have been received fine with Linux 5.15. This change
reverts a commit which has been isolated to be the culprit.
In case a system takes a bit longer to boot (e.g. due to SWAP
initialization on first boot, especially on a system with lots of memory
and not very fast strage, e.g. an ODROID-M1 using an SD card) we might
time-out waiting for time synchronization before the time
synchronization service even got started. By ordering the
systemd-time-wait-sync.service after the network is online, the timeout
of this service should be started much later. With that the
systemd-time-wait-sync.service shouldn't timeout any longer.
