With both RTCs enabled, the rpi_rtc is probed as the first one, making the
on-board RTC unused by default. Since the CM5's RTC peripheral can't be used on
Yellow, as the VBAT pin is not connected, disable it completely to fix RTC.
(cherry picked from commit 9d643edb54)
The I/O operations on the eMMC can sometimes fail and lock up completely, and
disabling CQE on the sdio1 (mmc0) interface seems to solve the issue. While it
is a known (and potentially resolved) issue [1] for SD cards in Raspberry Pi's
Linux fork, it is not acknowledged neither resolved for CM5's eMMC. With CQE
enabled, the device usually locks up within the first 10 first boots, when the
swap file is being created. After disabling CQE, no error occurred after more
that 100 cold boots (every time with swap file removed).
[1] https://github.com/raspberrypi/linuxissues/6349
(cherry picked from commit c514d6b482)
For yet unknown root cause, the eMMC interface sometimes fails to initialize
properly, delaying boot for up to 130 seconds. This can be reduced by ~100s by
disabling SD and SDIO modes on the sdio1 interface used for mmc0 before a
better patch is found.
(cherry picked from commit 489de0b2fb)
Build cypress_m8 driver as module for all targets - some of them had it in
their base defconfig while some not. It is required e.g. for UPB PIM (Powerline
Interface Module).
Fixes#3690
(cherry picked from commit d57e507764)
Sync the DTS with changes added in newer commits merged after the initial
Yellow/CM5 DTS was written. The sdio1 node now has HS400 mode enabled and
sd_io_1v8_reg has been changed to regulator-fixed.
(cherry picked from commit b288cd212a)
If HAOS on Yellow is booted for the first time with NVMe data disk present, it
should be preferred over the empty eMMC data partition. This will ease
reinstall of the system and migration from CM4 to CM5. All other data disks
(e.g. if a USB drive is used for them) are still treated as before, requiring
manual adoption using the Supervisor repair.
(cherry picked from commit 98ac7f0170)
Add Hailo-8 firmware binary for Rasperry Pi AI accelerators. The version needs
to be determined from the Git history of the kernel sources, as the driver
source code is included in the RPi downstream kernel and the version string
can't be found in the code directly.
Fixes#3663
* Add Makefile variable for Supervisor channel
Allow to set the release channel pre-installed Home Assistant components
like Supervisor and add-on are fetched from. This channel is then also
used at runtime.
* Use choice instead of string variable
* Fix channel in Supervisor updater.json config
* Add newlines
As stated in the docs [1], post-install hook is not executed if the slot
already has an install hook defined. Merge the post-install hook with the
install hook to fix CM5 migration for Yellow.
[1] https://rauc.readthedocs.io/en/latest/using.html#slot-hooks
The timeout of 90s was introduced before it was ensured that the timesync
systemd unit starts after network is online. Now with that, it makes less sense
to wait that long - if network is unreachable at the point the time
synchronization starts, and the server fails to reply on the first sync, the
polling interval is exponentially increased and the benefit of waiting for more
attempts is doubtful.
Since another synchronization attempt is done after network changes its state,
we should rely on that instead of having the 90 seconds interval as a waiting
period for plugging the network cable. Worst case, there are other mechanisms
that should set the time to a reasonably accurate value, making the NTP sync
less importart for most of the cases.
* Move RPi U-Boot patches to version-specific directory
We will need to use different series for 2024.10 which would be used as the
base for CM5 support.
* Remove common.h include from the fileenv cmd
It doesn't seem to be used and common.h has been removed in newer U-Boot.
* Use U-Boot 2024.10 with BCM2712 PCIe patches for Yellow
Use rebased patchset from v2024.01 with the first patch removed. Add patches
needed for PCIe initialization and use rpi_arm64_defconfig as the base config
for both CM4 and CM5.
* Add device tree for CM5 on HA Yellow and adjust config
Add device tree definition based on the CM5 device tree with BCM2712D0 changes
applied, and add nodes required for the on-board peripherals of Yellow.
Currently the difference in serial numbering still requires either changes in
this device tree, or userspace changes to create correct symlinks to make HA
configuration directly compatible with CM4 on Yellow.
* Add config.txt migration for conditional device_tree options
* Fix typos and minor issues found by CodeRabbit
* RaspberryPi: Update kernel to 6.6.51 - stable_20241008
* Update rpi-firmware to version for kernel 6.6.51
* buildroot 2ffac68a74...19027bc796 (1):
> package/rpi-firmware: bump to version 1.20241008 for kernel 6.6.51
Guest agent doesn't start because if HyperV Enlightenments are enabled, the
virtualization gets detected incorrectly. Backport Systemd patch that fixes the
detection, allowing the guest-agent service to meet its dependencies.
This patch should be no longer needed after update of Systemd to v256, or in
case the patch gets eventually backported to the v254 stable branch.
Fixes#3565
* Relocate HAOS Systemd drop-ins to /usr/lib/systemd
With some exceptions, Systemd drop-ins overriding default unit configuration
have been placed to `/etc/systemd/system`. This is meant for user overrides of
those, or per `man 5 systemd.unit` for "system unites created by the
administrator". Relocate all of these to `/usr/lib/systemd` which should be
used as path for units "installed by the distribution package manager" which is
closer to what we're trying to achieve.
This will make it easier to detect changes to unit files once we enable the
possibility to edit the content of /etc.
* Patch systemd-timesyncd.service instead of replacing it fully
If the system fails to boot, some kernel messages may not be shown before the
system fully boots. Enable the debug option for rescue shell options to have an
easy way to see those without modifying GRUB options. This will increase log
verbosity and turn on debug logging for Systemd as well [1].
[1] https://www.freedesktop.org/software/systemd/man/latest/systemd.html#debug
Bump labgrid to latest release. None of the changes require adjustments in the
tests. Remove pytest from requirements.txt, it's not needed anymore, so let pip
to resolve the correct (latest) version from labgrid's dependencies. With these
new dependencies, previous DeprecationWarnings on Python 3.12 are gone now.
* Update Docker to v27.2.0
Update Docker and containerd to latest supported version.
* buildroot a2c10a16a0...c68e03d96b (3):
> package/containerd: bump version to v1.7.21
> package/docker-cli: bump version to v27.2.0
> package/docker-engine: bump version to v27.2.0
* package/hassio: update DinD container to v27.2
If an attempt to access R2 artifacts is made before the files exist, the 404
reply gets cached and it's not possible to access the file after it's been
created without purging the cache, essentially doing a cache poisoning for
future build artifacts. To avoid it, list all files that have been created by
the build and call the purge cache API.
As there's a limit for number of files that can be purged in a single API call
[1], the GNU split utility is used to split intermediary list of files to
chunks of 30 URLs, which is then converted to a JSON array and passed to the
curl command.
[1] https://developers.cloudflare.com/api/operations/zone-purge#purge-cached-content-by-url
HP t520 have been reported to have the same issues as Atom boards with bad UEFI
firmware that doesn't work well with the new EFI loader used since GRUB 2.12.
Apply the patch to use legacy loader for its CPU ID as well.
Fixes#3557
Fix AX210 firmware files, this time for real. In #3549 we still had only
ucode and pnvm files for AX211, AX210 was still missing the pnvm file,
because its ucode was provided through IWLWIFI_22000 without appropriate
pnvm file. Both AX210 and AX211 firmwares are now installed with
IWLWIFI_6E which includes both pnvm and ucode files.
Also some firmwares which are not used by the current kernel can be
removed, because the kernel always only loads the most recent one.
* buildroot 01188d9c38...a2c10a16a0 (2):
> Revert "package/linux-firmware: exclude some files from compression"
> package/linux-firmware: fix AX210 support, stick to latest supported ucode API, reorganize the split
Fixes#3477
Since updating to Buildroot 2024.02, the iwlwifi loads a different version of
firmware for Intel AX cards (reported on AX210) which also needs the pnvm file.
However, unlike firmwares, the load method is different and the driver can't
load a compressed file. Disable compression for all .pnvm files to fix this.
* buildroot baa16784d2...55be56d521 (1):
> package/linux-firmware: exclude some files from compression
Fixes#3477
(cherry picked from commit d3a43a4ca4)
Since updating to Buildroot 2024.02, the iwlwifi loads a different version of
firmware for Intel AX cards (reported on AX210) which also needs the pnvm file.
However, unlike firmwares, the load method is different and the driver can't
load a compressed file. Disable compression for all .pnvm files to fix this.
* buildroot baa16784d2...55be56d521 (1):
> package/linux-firmware: exclude some files from compression
Fixes#3477
With #3523 as inspiration, it might be useful to wait for buttons to be
released, e.g. in case when they become stuck. Also indicate the button
operation (wipe, boot files removal, UMS) has been handled by turning on the
yellow LED.
* Improve LED naming in U-Boot DTS
Port Stefan's patch from Linux patchset to U-Boot.
* Implement device wipe using the hardware button on Green
Unlike Yellow, Green doesn't have a way to easily wipe the device, e.g. if the
user forgets the password - in that case the only option is to use a microSD
card and reflash the system. Fortunately, Green has a hardware button wired to
the PMIC chip which exposes the button state in one of the registers. Read this
value in U-Boot and decide if cmdline flag for device wipe should be set - same
as we do on Yellow.
Also enable LED driver and command in U-Boot. In the current implementation, if
the button is held for ~5 seconds when plugging in the device (this time
includes DDR training, SPL, etc.), the yellow LED turns solid to indicate wipe
is about the start. When the Linux kernel starts, the kernel LED driver takes
over and starts blinking in heartbeat pattern. Because it takes a while to load
the kernel, the LED stays solid for 2-3 seconds, which should be enough to
recognize it was acknowledged.
* Wait for button to be released before wiping
Enable NTFS and exFAT drivers, as they're not in defconfigs of all platforms and may be useful when mounting removable drives.
Fixes#2723
Co-authored-by: Jan Čermák <sairon@users.noreply.github.com>
With default console on HDMI (tty0), we lost the console on the serial port. It
may be useful for debugging, let's enable it for new installs with the same
speed as bootloader (to avoid the need for baud rate switching).
Follow-up to #3412. While we haven't seen any issues so far, it's mentioned in
the original patch series we took inspiration from that HS200 works more
reliably, so enable it in Green's defconfig by amending the patch.
(cherry picked from commit 0452965fb0)
While mksquashfs uses this value by default, Genimage's default is 4K. This is
far too low value and results in slower kernel load, especially on embedded
boards with a flash drive. Explicitly set it to 128K to generate same images as
in pre-genimage builds.
(cherry picked from commit edba18f6c4)
We previously reverted the bump because we were unsure where the eMMC issues
are coming from. Now we know some of them were caused by incompatible eMMCs
then never worked from the beggining, and attempt to fix them (by changing the
frequency) caused some other side effects. Bump U-Boot back to the version used
generally and continue from there.
(cherry picked from commit 50a0062ee6)
Follow-up to #3412. While we haven't seen any issues so far, it's mentioned in
the original patch series we took inspiration from that HS200 works more
reliably, so enable it in Green's defconfig by amending the patch.
While mksquashfs uses this value by default, Genimage's default is 4K. This is
far too low value and results in slower kernel load, especially on embedded
boards with a flash drive. Explicitly set it to 128K to generate same images as
in pre-genimage builds.
We previously reverted the bump because we were unsure where the eMMC issues
are coming from. Now we know some of them were caused by incompatible eMMCs
then never worked from the beggining, and attempt to fix them (by changing the
frequency) caused some other side effects. Bump U-Boot back to the version used
generally and continue from there.
* add Documentation category
* add Dependencies (to easily filter them out if not needed in changelog)
* adjust the order a bit to have user-facing changes first
* Test landing page is reachable without internet connection
Add test that checks user is able to access the landing page even when HAOS has
no internet connection. We still need some sort of outgoing connectivity, so
outgoing connection attempts don't end up with "network is unreachable". To
simulate this, restricted network is created for the QEMU instance used in the
test, and when everything is started, unresponsive default gateway is added.
This intents to test regression that was fixed by
home-assistant/supervisor#5204, Supervisor 2024.7.0+ is thus needed for this
test to pass.
* Bump requirements for tests
* Use GRUB2 legacy loader only on some Intel Atom boards specifically
Previous revert of GRUB2 change that introduced usage of the generic EFI loader
for all x86 boards in #3324 caused regressions, the one confirmed is #3348.
This commit adds a specific patch that identifies the broken platforms based
on SMBIOS data gathered in #3305 and falls back to the legacy loader there.
Tested on Intel D525MW (falls back) and QEMU (no fallback).
* Enable GRUB's smbios module
Having smbios command in GRUB can help in future debugging, e.g. to add more
CPUs that should use the linux loader fallback.
Genimage sets the first usable LBA to the offset of the first partition. While
it shouldn't be an issue in theory, Windows may do some nasty things with the
GPT header afterwards which breaks the Raspberry Pi bootloader, manifesting as
Before purpose of this behavior is clarified in [1], add a downstream patch
that sets the first usable LBA back to 34, which was the value that was used
before migrating to Genimage in #3388. Since changing this value (hopefully)
doesn't have any other consequences, and the images now should be closer to
pre-genimage builds, no more side-effects are expected from this change.
[1] https://www.github.com/pengutronix/genimage/issues/262Fixes#3437
Rockchip config fragment had EROFS compression explicitly disabled. Remove that
option and also remove the EROFS one, as it's already set in common config.
Reduce verbosity from deactivated Docker mounts, triggered by the Docker
healthcheck. These messages do not carry any value for us and logs supplied by
users are often spammed mostly with these. Moreover, they sometimes cause
confusion that something is wrong, see for example #3021.
Unfortunately, it's not possible to use LogFilterPatterns= here, because it's
not applied to these messages, as explicitly said in the docs:
Filtering is based on the unit for which LogFilterPatterns= is defined
meaning log messages coming from systemd(1) about the unit are not taken
into account.
runc 1.2.0 supposedly should fix this, but it's unclear when it would be
available, so let's stick to this solution (reducing verbosity from debug to
notice for all units `run-docker-*.mount`) for the time being.
* Use name.sh functions for paths in genimage
Paths for images generated outside of genimage were not used in genimage
definitions. Use them as the single source of truth.
Images generated by genimage itself (e.g. kernel.img) don't need to use those
functions, so remove the unused ones.
* Use EROFS instead of SquashFS for root FS
* Enabled EROFS in common kernel fragment
* RootFS image switched to EROFS with options to get decent compression
* rootfstype removed from kernel command line
* Get size of correct FS image in GH build summary
While not as bad as in 87a6c84, because the grubenv already exists in the
image, RAUC still complains about missing ORDER on the very first boot on
aarch64. Populate the environment in the same way as we do for other GRUB
platforms.
With upgrade path enforced in standard HAOS upgrade procedure, we don't need to
keep some old code anymore. This means that upgrade from some very old HAOS
version (pre-8.0) to HAOS 13+ will fail in the install-check hook but this is
rather desirable.
RAUC currently doesn't know the version of the booted slot when booted for the
first time or after wiping the data partition. As a result `ha os info` is
missing this information too.
As there's no built-in mechanism for generating these data by RAUC itself, add
a oneshot service that checks if the boot slot information is contained in the
rauc.db and if not, then generate it.
RAUC seems to cope quite well even with bogus data contained in rauc.db but in
any case, a test has been added to check that everything works as expected.
On the very first boot, grubenv doesn't exist and loading and saving it
silently fails. However, it is later created by the hassos-persists script and
the missing information are added by grub.cfg on the next boot. As the
consequence, when RAUC tries to get information from grubenv on the first boot,
ORDER variable is missing and the slot is reported as bad.
Fixes#3376
We still face occasional build errors when fetching from the Docker registry
fails and is not retried with the Skopeo's built-in retry mechanism that was
enabled in #1866. This happens on some network failures, or when premature EOF
is returned when fetching the HTTP data. Seems we're not the only ones having
such issues [1].
To workaround this, add a generic retry shell function that simply retries when
the command ends with a non-zero status, no matter what was the actual cause of
the error.
[1] https://www.github.com/containers/common/issues/654
Very often we have to ask for further details about the hardware that HAOS is
running on. Add a required field that asks for these details - in the end it
should't complicate the form a lot and might result in faster turnaround of
resolving the issues.
Also adjust the question about the upgrade and swap the order (people often
don't care and keep the pre-selected value).
When Green starts, there is an error indicating the MMC write failed when
saving the bootstate:
storing env...
MMC write: dev # 0, block # 1214464, count 64 ... mmc write failed 0 blocks written: ERROR
This results in the boot count not being updated properly if the boot fails.
Seems to be a known issue for this platform, disabling the DDR52 mode (which is
the same what upstream does for other RK356x boards [1]) fixes the issues and
the bootstate is updated correctly.
[1] https://patchwork.ozlabs.org/project/uboot/patch/20240204205312.2342868-2-jonas@kwiboo.se/
As we don't have proper solution for #3319 and #3351 yet, revert to
previous U-Boot which was proven working. This is intended as a
workaround but as there's nothing in the latest U-Boot that will be
really missed on N2, we can stay on the older version for the time
being.
This also means reverting the "40 MHz hack" back to the 24 MHz one.
Since this patch only applies to N2 (meson gx), it can stay along the
common hardkernel uboot patches.
The compression is necessary for successful generic-x86-64 build.
* buildroot 770f939463...b9520eedc6 (1):
> package/linux-firmware: fix compression after bad merge
* Bump buildroot to 2024.02.3
* buildroot 691077e577...770f939463 (1):
> Merge tag '2024.02.3' into 2024.02.x-haos
* package/hassio: update dind to version 26.0 used in current buildroot
* Use Genimage for declarative image layout instead of s[fg]disk and dd
* Change partition type to hybrid for M1, M1S and Green
This is what it really is, so just make sure only one "fix" function is
called.
* Change efi BOOT_SYS to gpt
There is no reason to have separate efi and boot sys, since all boards
that use efi also use grub as the loader.
* Change BOOT_SYS to more explanatory PARTITION_TABLE_TYPE
* Add units to DISK_SIZE
* Add forced-primary patch and use it in MBR images
* Avoid disabling SC2155, remove old comments
The preferred console (which is used for printing the systemd boot log)
is the last one specified in the cmdline boot arguments. Make sure it is
always tty0, i.e. the first graphical console.
In some places tty1 was used - change it to tty0 which is commonly used,
and in HAOS points to tty1 anyway.
The only exception is the Yellow, which doesn't have an HDMI port, so
the serial console is used as the preferred one instead.
For ASUS Tinker, use a versioned cmdline.txt file instead of in-place
generating it in the post-build hook.
* RaspberryPi: Update kernel to 6.6.31 - stable_20240529
* Unify Linux patches after RPi update to non-conflicting 6.6.31
* Bump buildroot to update rpi-firmware
* buildroot 9af2384782...691077e577 (1):
> package/rpi-firmware: bump to version 1.20240529 for kernel 6.6.31
* Reintroduce IPv6 reachability probe patch for RPi lost after refactoring
In #3384 we moved the patches around, which results in version-specific
patches not applied for RPi linux-custom build. Copy the missing IPv6
reachability probe patch to the RPi patches directory.
* Only copy IPv6 reachability probe patch to top-level linux patches
Instead of copying the patch to RPi directory and renumbering the
patches, only copy it upper level so it's applied for all linux versions
other than 6.6.31.
* Linux: Update kernel to 6.6.31
* https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.6.31
* Update patch workarounding Z-Wave.me USB issues
Linux commit 480c3abbba36628dab063b9ca218bb28090e5b46 changed code that
is reverted by the patch. Use a version-specific patch directory again
for upstream Linux patches before RPi kernel is updated to 6.6.31+.
ODROID M1, M1S and Green historically used git repo as the source. Now
that we use the same version for all boards, use always use distribution
tarball for consistency and more efficient caching.
Cherry-picked downstream-only patch lost in Buildroot 2024.02 bump.
* buildroot 34e790c5da...9af2384782 (1):
> package/openvmtools: bump version to 12.3.0
Fixes#3366
RPi 5 config uses BR2_LINUX_KERNEL_INSTALL_INTREE_OVERLAYS which builds
the device tree overlays from the Linux tree when building the kernel.
The overlays directory also contains overlay_map.dtb which is necessary
to correctly map overlays without RPi version suffix to the
platform-specific ones. Without this, some peripherals may not work
correctly on Pi 5 without any obvious error messages in the kernel log
because an incorrect (Pi 4) overlay is used as the default.
Fixes#3321
* buildroot cc0481f40e...0a64bfe8f1 (1):
> Install overlay_map.dtb when using in-tree DT overlays
(cherry picked from commit fce19b7846)
Enable libkcapi in generic kernel config. The bloat is minimal and the
options are enabled on most distributions. These modules are also needed
for Bluetooth Mesh and adding them fixes compatibility with some HCI USB
adapters.
Fixes#3322
(cherry picked from commit 67315f86d4)
RPi 5 config uses BR2_LINUX_KERNEL_INSTALL_INTREE_OVERLAYS which builds
the device tree overlays from the Linux tree when building the kernel.
The overlays directory also contains overlay_map.dtb which is necessary
to correctly map overlays without RPi version suffix to the
platform-specific ones. Without this, some peripherals may not work
correctly on Pi 5 without any obvious error messages in the kernel log
because an incorrect (Pi 4) overlay is used as the default.
Fixes#3321
* buildroot cc0481f40e...0a64bfe8f1 (1):
> Install overlay_map.dtb when using in-tree DT overlays
Enable libkcapi in generic kernel config. The bloat is minimal and the
options are enabled on most distributions. These modules are also needed
for Bluetooth Mesh and adding them fixes compatibility with some HCI USB
adapters.
Fixes#3322
This fixes "Warning: your password will expire in 0 days." message
shown on tty login since Buildroot bump in HAOS 12.2.
* buildroot 9f5750121a...d29893dd98 (1):
> package/linux-pam: bump to version 1.6.1
GRUB 2.12 release contains a change of the loader [1] used for loading
the kernel on x86_64 platform. This change was identified to cause boot
failure on some old Intel Atom boards with the NM10 chipset, and
possibly some others. Revert this patch before we get a more proper fix
for the issue.
[1] https://git.savannah.gnu.org/cgit/grub.git/commit/?id=cfbfae1aef0694b416aa199291cfef7596cdfc20Fixes#3305
It seems that forcing 24MHz clocks is problematic for newer 32GB
Kingston based eMMC modules on ODROID-N2(+). Use what downstream
U-Boot is using as f_max, which is 40MHz.
Fixes: #3227
With #3281 we hit the maximum length of the quirks parameter. Since
cmdline.txt changes are not applied on OS update, only new installs of
12.2 are affected, effectively disabling all quirks until this patch
lands in future OS release.
Fixes#3308
Make sure all Raspberry Pi devices using the BCM2837 SoC (or the SiP
version RP3A0 of it) are deployed. This especially makes sure that
we only deploy the downstream device trees (named bcm2710*) and deploy
device trees for the CM3 as well as the Zero 2 and Zero 2 W consistently
for 32-bit and 64-bit.
* RaspberryPi: Update kernel to 6.6.20 - 6f16847710cc0502450788b9f12f0a14d3429668
Used version specified in RPi OS release notes [1].
[1] https://downloads.raspberrypi.org/raspios_arm64/release_notes.txt
* Update RPi Buildroot defconfigs for v6.6.y kernel
* Update RPi kernel patches for v6.6.y kernel
* Amended old patches to accomodate for new DTS paths
* Removed 6.6.25 patches -> moved to the common folder
* Added patch to fix Yellow DTS compilation
* Bump buildroot to update rpi-firmware
* buildroot b45d671fe3...9f5750121a (1):
> package/rpi-firmware: bump to version for (untagged) kernel v6.6.20
* Remove kernel v6.1.y config fragments, as they're not needed anymore
* Only run HA CLI interactively if stdout is a terminal
Flags for running HA CLI commands in an interactive shell added in #3238
cause the command to fail if the process is not running in a terminal.
This is needed for example for the fsfreeze hook, otherwise the command
fails, as seen in this trace when the hook is executed:
-----------
+ '[' thaw '=' freeze ]
+ '[' thaw '=' thaw ]
+ echo 'File system thaw requested, thawing Home Assistant'
File system thaw requested, thawing Home Assistant
+ ha backups thaw
the input device is not a TTY
------------
However, for example on Proxmox this message is not logged anywhere and
the hook just fails silently (i.e. it doesn't cause the backup to fail).
Fixes#3251
* Use -i also when not running in a terminal
(cherry picked from commit 78d281fce1)
CP15 barrier instruction emulation only exists on arm64 architecture.
Avoid sysctl writing an error to the journal when the setting doesn't
exist by prepending a dash.
(cherry picked from commit 889b561ca1)
Booting from a ADATA SD600Q fails when connected to a USB 3.0 port on RPi4. Adding it to the quirks list resolves the issue.
(cherry picked from commit 5ee9cef8c8)
* Only run HA CLI interactively if stdout is a terminal
Flags for running HA CLI commands in an interactive shell added in #3238
cause the command to fail if the process is not running in a terminal.
This is needed for example for the fsfreeze hook, otherwise the command
fails, as seen in this trace when the hook is executed:
-----------
+ '[' thaw '=' freeze ]
+ '[' thaw '=' thaw ]
+ echo 'File system thaw requested, thawing Home Assistant'
File system thaw requested, thawing Home Assistant
+ ha backups thaw
the input device is not a TTY
------------
However, for example on Proxmox this message is not logged anywhere and
the hook just fails silently (i.e. it doesn't cause the backup to fail).
Fixes#3251
* Use -i also when not running in a terminal
CP15 barrier instruction emulation only exists on arm64 architecture.
Avoid sysctl writing an error to the journal when the setting doesn't
exist by prepending a dash.
Since buildroot commit 3ceb8c97bcb6753740fa27a58b8e0dc00dbbbd19, systemd
has new option BR2_PACKAGE_SYSTEMD_VCONSOLE_DEFAULT_KEYMAP which
defaults to "us". With this option specified, systemd-console depends on
kbd package and causes the following message to be printed during
startup on HAOS:
systemd-vconsole-setup[253]: sh: gzip: not found
This comes from the loadkeys call which tries to open the gzipped file,
so likely the kbd package should also depend on gzip. However, since we
don't want the kbd package at this point, I'm leaving this for later
investigation and simply unsetting the new option to revert to
pre-2024.02 setup.
List Nabu Casa appliances under boards README.md
* Home Assistant Green
* Home Assistant Yellow (based custom carrier board and powered by a Raspberry Pi 4 Compute Module)
* Home Assistant Blue (based on ODROID-N2+)
The official description says:
Multipath TCP (MPTCP) connections send and receive data over multiple
subflows in order to utilize multiple network paths. Each subflow uses
the TCP protocol, and TCP options carry header information for MPTCP.
Thanks to MPTCP, being able to use multiple paths in parallel or
simultaneously brings new use-cases:
- Seamless handovers: switching from one path to another while
preserving established connections -- Apple is using it for this
reason since 2013.
- Best network selection: using the "best" available path (latency,
losses, cost, bandwidth) -- one path can be used as a "backup" one.
- Network aggregation: using multiple paths at the same time to have a
higher throughput -- e.g. to combine a fixed an mobile network to
send files faster.
For example, for HA, it is possible to keep a SSH connection alive when
switching from one network to another (e.g. while travelling).
To be able to use MPTCP, both ends need to support it. An application
has to request it, by creating an MPTCP socket instead of a TCP one.
The rest in unchanged. An alternative is to use 'mptcpize' tool, which
relies on LD_PRELOAD to create an MPTCP socket instead of a TCP one.
Note that a MPTCP-enabled server continues to accept regular TCP
connections that do not use the Multipath TCP extension without any
performance impact. When a connection request is received, and is linked
to a listening socket with MPTCP support, the kernel will simply check
if MPTCP options are present. If not, the accepted socket will be a
"plain" TCP one, with the same impact as before.
To use multiple paths at the same time, additional IP addresses need to
be configured, e.g. via the 'ip' tool (IPRoute2).
MPTCP in the kernel is enabled in most main Linux distributions (Debian,
Ubuntu, RedHat, Fedora, etc.), but in more specific ones like Raspbian.
It is available in the Linux kernel since v5.6.
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
* Update Buildroot to tag 2024.02 with rebased HAOS patchset
* udisks2: update to v2.10.1
* Updated to version 2.10.x compatible with libblockdev v3
* Rebased patches to new codebase
* Autoreconf patch is not needed anymore
* libblockdev-nvme is now hard dependency of udisks daemon
* patches/grub2: remove upstreamed efidisk patch
* patches/network-manager: update multiple gateway patch
* package/os-agent: fix go download
After the Go update, build fails with the following error on mod vendor:
GOPROXY list is not the empty string, but contains no entries
Turns out this step is not having the environment variables set, use
those used for download to fix it.
* package/xe-guest-utilities: set DL env for go mod vendor
* Bump buildroot to fix missing unit file from nfs-utils
* buildroot 3f950a1aee...a1b2d12f32 (1):
> package/nfs-utils: only install fsidd binary and unit file with enabled nfsd
* CI: install flake8 for pr-checks runner
Use distribution package, as it's what's used in Buidlroot's Gitlab CI
Docker image at buildroot/support/docker/Dockefile.
* Disable check for Upstream section in the patch header for now
It was introduced in latest BR - disable it for now and re-enable
for HAOS in a later separate PR.
Fix regression caused by #3224 which introduced version-specific
directory for linux patches, causing the upper-level patch not being
applied. Copy the patch to the version folder instead. Also we need
to keep it in the upper directory for RPi kernels.
(cherry picked from commit 8226323a1b)
The test was missing --no-progress flag, which only manifested after
merging #3238 - causing the CLI to run in an interactive pseudotty.
(cherry picked from commit 122dd1c288)
Use -i (--interactive) and -t (--tty) to start the HA CLI interactively.
This is required by some commands like the new device wipe command added
with https://github.com/home-assistant/cli/pull/464.
(cherry picked from commit fe1978f98f)
Fix regression caused by #3224 which introduced version-specific
directory for linux patches, causing the upper-level patch not being
applied. Copy the patch to the version folder instead. Also we need
to keep it in the upper directory for RPi kernels.
Use -i (--interactive) and -t (--tty) to start the HA CLI interactively.
This is required by some commands like the new device wipe command added
with https://github.com/home-assistant/cli/pull/464.
The in-tree driver introduced in HAOS 12.0 is having random issues,
so revert back to the stable OOT driver that was used before for now.
Also it add it to RPi 2 and Yellow where it's been missing the whole
time.
Fixes#3205
Revert changes in the USB driver causing Z-Wave sticks (Z-Wave.me a
and Aeotec at least) failing to enumerate. Issue is reported upstream
but reverting the patches is a feasible workaround for the time being.
Refs #2995
Remove the mentions of petitboot, as it's not normally used on M1S.
Document possibility to use SD card boot and alternative method of
reflashing the eMMC from an OS running from an SD card.
With recent change of Azure VM type, the disk layout has changed and
the build of ova target fails with insufficient space. Since there
is now plenty of space on /mnt partition, we can use that, just like
we've been using it for cache for now.
Ref: https://github.com/easimon/maximize-build-space/issues/39#issuecomment-1935591779
* Copy Odroid-m1 config for new odroid-m1s board
* config: Adjust names and paths for odroid-m1s
* configs: Use rk3566 blobs for ATF
* set correct fdt in uboot.ush
* Add linux patches with Odroid-m1s devicetree
Synced from Hardkernel unofficial 6.1 tree
ae33b44557/arch/arm64/boot/dts/rockchip/rk3566-odroid-m1s.dts
With additional cleanup and fixes for mainline linux
* Add Odroid M1S to Github actions
* uboot: Patch boot order to set SD Card first
* Create u-boot placeholder partion for odroid-m1s also
* Switch u-boot to full odroid-m1s config
* cherry-pick emmc stability improvements
* Generalise u-boot to use ${devtype} instead of hardcoded mmc
* Remove deprecated snps, reset options from device tree
* re-enable uboot ethernet
* Create common kernel config for Rockchip aarch64 boards
* Green: drop kernel option already included in main config
* Move rockchip RNG patchset to common folder
* Odroid-m1 has no board specific patches now
We added drivers for Realtek cards readers in #3005, however it also
needs MMC drivers in order to make card reading possible. Enable both
USB and PCI versions of those (each about ~40 kB).
Fixes#3167
* Update issue template with better links to logs, add CLI instructions
Legacy supervisor_logs target (which is currently kind of broken) replaced
with standard logs with provider specified. Added instructions how to get
logs in HA CLI.
* Apply suggestions from code review
Co-authored-by: Stefan Agner <stefan@agner.ch>
* RaspberryPi: Update kernel to 6.1.73 - stable_20240124
* Bump rpi-firmware to version for RPi Linux 6.1.73
* buildroot f844f7f725...0ab96d7c0d (1):
> package/rpi-firmware: bump to version for stable_20240124 kernel
ODROID XU4 fails to boot after update to Linux 6.6. Comparing downstream
kernel config with upstream exynos defconfig shows it has various lockdep
options enabled, and PROVE_LOCKING seems to be the one that causes the
issue. It seems it (or any of PROVE_RCU, TRACE_IRQFLAGS or
PREEMPTIRQ_TRACEPOINTS) which get enabled along with it) probably
triggers some timing issues on the I2C bus, which causes the main PMIC
to fail to properly initialize all voltages.
Since these options should not have any real impact on our system, the
easiest option is to disable them. If we need them, or want to stay
closer to upstream defconfig, further debugging is needed.
Fixes#3137
We originally enabled it in 0ebcdcb9dc
but later reverted the patch in 5b927389b8
because of backward compatibility issues. Since we're going to 12.0,
there is now hopefully enough room for seamless transition.
Co-authored-by: Stefan Agner <stefan@agner.ch>
* Use separate path for v6.1.y and v6.6.y kernel config fragments
Since we're now maintaining Linux configs for two different versions,
it may happen that we want to add some options only to one of the
versions. While the Kconfig might figure the invalid options itself,
our config checking tooling would spam us with warnings. This commit
splits the configs to two directories. This pattern is used only for
the common fragments, more specific ones are usually sharing the same
Linux version anyway.
* Add back options removed in v6.6.y to v6.1.y kernel config fragments
* Linux: Update kernel 6.6.15
* Update buildroot packages to work with Linux 6.6
* Fix top-level and pc patches of linux
* Update tinker patch series
* Drop Odroid M1 patches
M1 is now supported in upstream.
* Update Hardkernel patches
Needed larger refactoring because of 379ae64609c7a3301b60483eb65bd8bc78f76328
* Update Green patches
* Update Odroid XU4 patches
Removing the TMU patch/hack for now, need to check if it's still needed.
If it is indeed, then it needs slighter rewrite.
* Move Rockchip RNG patches to M1 and Green dirs
* Update rtl88x2bu package to fix build
* Update gasket package to fix build
* Fix eq3_char_loop build
* Use fan53555 instead of custom rk860x driver
* Fix kernel base configs and fragments after 6.6 update
Mostly removed options that have been removed between releases. Only
a few options have been renamed, then there's bunch of options that
had dependencies added so they are available only on some architectures,
which are not those that we're using.
* Remove deprecated regulator-compatible from Green DTS
Generate list of changelogs if we're bumping to the next patch release.
If major or minor version is bumped, the commit message contains only
the title, like before.
Also fix English in the commit title of RPi bump.
Odroid M1 was using 1056 MHz blob for RAM training, although it can run
at 1560 MHz. Use the correct file for M1 and update it to latest version,
along with ARM Trusted Firmware blob.
(cherry picked from commit 1f45aaf359)
We don't really use the MMC environment, so disable it by default. This
prevents the following warning at startup:
Loading Environment from MMC... *** Warning - bad CRC, using default environment
(cherry picked from commit f263326ef8)
It seems that the Ethernet initialization in U-Boot causes significant
packet drops in Linux on some board. On a ODROID-M1 with 8GB of RAM, a
packet loss rate of ~20% has been observed. From the user point of view
it feels like a massive slow down (SSH feels very slow, Home Assistant
loads very slow or not at all).
Disabling the Ethernet controller driver avoids initialization in U-Boot
and makes Ethernet work correctly again in Linux.
While at it, drop the previously board specific configs. They haven't
been used and the board seemed fine without them.
(cherry picked from commit bd3cae5300)
Odroid M1 was using 1056 MHz blob for RAM training, although it can run
at 1560 MHz. Use the correct file for M1 and update it to latest version,
along with ARM Trusted Firmware blob.
We don't really use the MMC environment, so disable it by default. This
prevents the following warning at startup:
Loading Environment from MMC... *** Warning - bad CRC, using default environment
It seems that the Ethernet initialization in U-Boot causes significant
packet drops in Linux on some board. On a ODROID-M1 with 8GB of RAM, a
packet loss rate of ~20% has been observed. From the user point of view
it feels like a massive slow down (SSH feels very slow, Home Assistant
loads very slow or not at all).
Disabling the Ethernet controller driver avoids initialization in U-Boot
and makes Ethernet work correctly again in Linux.
While at it, drop the previously board specific configs. They haven't
been used and the board seemed fine without them.
Enabling CONFIG_EXPERT, which was a dependency of some options we try
to set by our config fragments, had a side-effect of toggling some other
options, most importantly the framebuffer console support. Enable the
options found by diffing old and new kernel configs.
Fixes#3112
(cherry picked from commit 3d234144a2)
Enabling CONFIG_EXPERT, which was a dependency of some options we try
to set by our config fragments, had a side-effect of toggling some other
options, most importantly the framebuffer console support. Enable the
options found by diffing old and new kernel configs.
Fixes#3112
* ../../../buildroot 55120df0b7...512a487366 (3):
> package/linux-firmware: add WiFi and BT firmware for MT7921 and MT7922
> package/dbus-broker: fix legal info
> package/rtl8821cu: fix legal info
Since we're using a custom os_prefix for dual boot on RPi 5, overlays
can be also present in different directories. Raspberry Pi's bootloader
has a strange feature that it only respects os_prefix if the directory
with overlays contains a README file:
https://www.raspberrypi.com/documentation/computers/config_txt.html#overlay_prefix
While rpi-firmware package touches the file when copying overlays to
the destination directory, for RPi 5 we are using BR2_LINUX_KERNEL_INSTALL_INTREE_OVERLAYS
option which does not copy or create it. Ensure it is present (no matter
if we're using intree on rpi-firmware overlays) in the hassos-hook.
Fixes#3079
(also removed invalid mention about the README from config.txt)
* Remove all non-existing kernel config symbols
* Remove unapplied x86 Intel sound options
These are missing various subsystem dependencies and were never in fact
enabled, assuming they're rather exotic and removing them completely.
* Add missing dependencies, adjust tristate values, remove nonsense
* Use KERNEL_LZ4 only for non-aarch64
Since aarch64 doesn't use self-extracting kernel:
https://patchwork.kernel.org/project/linux-arm-kernel/patch/20190119185540.20526-1-tobias.johannes.klausmann@mni.thm.de/
* Extract PCI options to device-support-pci fragment (renamed from device-support-pcie)
RPi 4+ should use this fragment too, since CM4 has PCIe support.
* Rename RPi's kernel-32b fragment to kernel-armv7
* Bump U-Boot to 2024.01 for Raspberry Pi and Home Assistant Yellow
* Regenerated using --no-thread
By default git creates some email headers. We can minimize them using
--no-thread.
* Fix build for Yellow
* Update U-Boot for ASUS Tinker Board
* Update U-Boot for Khadas VIM3
* Update U-Boot for ODROID-M1
* Update U-Boot for Home Assistant Green
* Update U-Boot for ODROID-C2/C4/N2/XU4
It seems that the PCIe driver is not enabled for Khadas VIM3. Enable it
by default.
Note to make use of the M2X extension board, the following commands need
to be executed on the U-Boot command line:
```
HAOS> i2c dev 0
Setting bus to 0
HAOS> i2c mw 0x18 0x33 1
```
Wrong arch for arm64 produces few false check results resulting
from some symbols in arm64 tree not being loaded. We can use raw
$(ARCH) variable for arm, only need to translate aarch64 -> arm64.
Using apt-key for managing Debian repo keys has been deprecated for a
while now. While it currently works ok, seems to be broken in bookworm. This migrates to storing keys in trusted.gpg.d as recommended by the warning messages when using apt-key.
* buildroot 153f1461f6...55120df0b7 (8):
> package/linux-firmware: bump version to 20231211
> package/linux-firmware: bump version to 20231030
> package/linux-firmware: add iwlwifi quz firmware
> package/linux-firmware: add new option for Marvell prestera firmware
> package/linux-firmware: bump version to 20230804
> package/linux-firmware: bump version to 20230625
> package/linux-firmware: add QCA9377 BT firmware
> package/linux-firmware: bump version to 20230515
Path to cmdline is set in tryboot.txt to cmdline-tryboot.txt before
attempting A/B boot. After successful boot, tryboot.txt is relocated
to config.txt, yet the config path of cmdline is not changed and remains
set to cmdline-tryboot.txt which doesn't exist anymore at that point,
causing following reboots to fail.
Fixes#3065
The value of ```self_signed_cert``` is being set incorrectly, resulting in a failed build, as the self signed certs aren't copied correctly.
Updated so the value is set from ```self_signed_cert``` and not ```self_signed```
* Revert kernel patch causing failures on CIFS share disk usage
The issue was reported upstream, waiting for a fix there. Reverting the
patch for a quick resolution of the bug that breaks some things in HA
and add-ons badly.
Refs #3041
* Move the patch to 6.1.71 subdirectory
That way Raspberry Pi's kernel won't be patched (unless it's the same
version which it's currently not).
The Raspberry Pi 2 was based on Cortex-A7 in first revisions, then
Cortex-A53. However, both ar armv7 architectures, and that is also how
the Operating System itself is configured. Use the correct architecture
for Supervisor.
The hassos-supervisor script should recreate the container
automatically on first boot after update.
Since Supervisor itself is written in Python this shouldn't affect much.
However, the Supervisor uses it's architecture as default architecture
when building local add-on and uses it as default architecture for
multi-arch container images. This is also where this error got noticed
(see https://github.com/home-assistant/supervisor/issues/4402#issuecomment-1865979421).
The Raspberry Pi 2 was based on Cortex-A7 in first revisions, then
Cortex-A53. However, both ar armv7 architectures, and that is also how
the Operating System itself is configured. Use the correct architecture
for Supervisor.
The hassos-supervisor script should recreate the container
automatically on first boot after update.
Since Supervisor itself is written in Python this shouldn't affect much.
However, the Supervisor uses it's architecture as default architecture
when building local add-on and uses it as default architecture for
multi-arch container images. This is also where this error got noticed
(see https://github.com/home-assistant/supervisor/issues/4402#issuecomment-1865979421).
* Remove duplicated step uploading ova QEMU image for the test job
Instead of uploading the file twice with a fixed name, upload it in the
same step that is used for unpublished builds and pass the version string
to the test job.
* Update .github/workflows/test.yaml
Co-authored-by: Stefan Agner <stefan@agner.ch>
---------
Co-authored-by: Stefan Agner <stefan@agner.ch>
Generate the certificate only once and make it available. The preferred
option that doesn't generate warnings would be to use secrets in the
repository config, in that case no certificate is generated or archived.
Enable PCI card reader found on some Intel NUC models, along with the USB
drivers as well.
Adds two new modules (listed with size):
30104 /lib/modules/6.1.68-haos/kernel/drivers/misc/cardreader/rtsx_usb.ko
167240 /lib/modules/6.1.68-haos/kernel/drivers/misc/cardreader/rtsx_pci.ko
Fixes#2688
There is bunch of kernel config options that are not propagated
correctly to the kernel configuration after fragments are merged
and processed by Kconfig. Current Buildroot tools are not good at
discovering these - while we cleaned up most inconsistencies by using
linux-diff-config and output from the merge_config.sh script, there
are still options that were removed or get a different value than
intended because of dependencies, etc.
This commit adds a Python script that is using Kconfiglib to parse
current kernel's Kconfig files and the generated .config and compare
the requested values from individual kernel config fragments. The
script can be used manually by running `make linux-check-dotconfig`
from the buildroot directory (with path to BR2_EXTERNAL directory set)
and it's called also from the CI, where it generates Github Workflow
warning annotations when some of the values are not present or when set
incorrectly.
The kconfiglib.py is checked-in to the repo as well, because the library
is currently abandoned on PyPI and packaged version has a bug that causes
errors parsing Kconfigs in newer Linux versions, fixed in outstanding
pull request ulfalizer/Kconfiglib#119 - so version from this PR is used
here.
If pypi/support#2526 is ever resolved, we could remove it from our repo
and use pip for installing the package as a requirement during build
of the build container.
Add new firmwares and enable them for all targets.
Bloat in rootfs in my x86_64 test build was ~2.16 MiB.
Buildroot bump:
* buildroot 8a75878da4...4c89661fd1 (2):
> package/linux-firmware: add WiFi and BT firmware for MT7921 and MT7922
> package/linux-firmware: add rtw89 firmware files
Make it possible to run build on feature branches by adding a flag that
can be used to select whether the build output will be uploaded to the
R2 artifacts bucket or kept only as build artifact on GH. The latter is
also used for 3rd party repos, allowing builds in forked repositories.
Feature builds are using Unix timestamp as the dev version suffix. This
makes them easily distiguishable, yet it makes them appear to be newer
than standard daily dev version builds when compared by AwesomeVersion.
Compress firmware files from linux-firmware using ZSTD algorithm.
This should grant us some more space to add more firmwares and should
not have any major performance impact, because firmwares are not accessed
frequently.
Includes buildroot submodule bump:
* buildroot 07e08e01b2...8a75878da4 (1):
> linux-firmware: add option for firmware files compression
This allows for rudimentary image/partition size tracking between builds,
potentially this could be further extended with more useful information
about the build (TBD).
* Add initial Raspberry Pi 5 buildroot config
* Add machine-id support via cmdline.txt
* Add new entry if entry is missing
* Don't overwrite cmdline.txt when adding machine-id
Use sed to append the new cmdline parameter to the first line.
* Skeleton script for RAUC custom bootloader interface
* Deploy kernel/device-tree into a RAUC slot specific directory
This allows us to use the os_prefix feature to switch between slot A and
B. Compared to the boot_partition option, this option allows to use a
shared config.txt and cmdline.txt, which makes it more like how HAOS
currently works on other Raspberry Pis.
* Deploy new kernel/device-tree to correct slot on installation
* Increase boot size to 128MB
This makes sure we can store up to three kernels (slot A, B and an
temporary one while installing the OTA update).
* Initial tryboot implementation using os_prefix
* Make sure to delete the old slot completely
* Add Busybox xargs for tryboot bootloader script
* Compare tryboot bootloader file silently
* Revert "Increase boot size to 128MB"
This reverts commit 7f2c69b58f02f500d6aeee4f0a419046899b5e38.
* Use compressed kernel
* Address shellcheck
* Address shellcheck issue in rauc-hook
* Fix shellcheck for rpi-tryboot.sh
* Do not follow source - it gets checked separately
* Correctly set the slot to boot
* Apply suggestions from code review
Co-authored-by: Jan Čermák <sairon@users.noreply.github.com>
* Drop serial console from default cmdline.txt
* Resync rpi5_64_defconfig with rpi4_64_defconfig
* Improve machine-id match
Only match actual hexadecimal characters.
* Deploy firmware overlays to OS prefix directory
* Add Raspberry Pi 5 to documentation
* Bump buildroot
* buildroot fd1dc86f40...f13ad03408 (1):
> linux: add in-tree device tree overlay support
* Install device tree overlays from Kernel sources
* Drop RPi RF modules for now
No Raspberry Pi 5 specific device tree overlays are available, drop RPi
RF mod for now.
* Use Raspberry 5 specific identifiers for Supervisor/OS Agent
* Bump buildroot
* buildroot f13ad03408...07e08e01b2 (1):
> linux: fix add in-tree device tree overlay support
* Revert "Drop RPi RF modules for now"
This reverts commit 46fc1701e4.
---------
Co-authored-by: Jan Čermák <sairon@users.noreply.github.com>
There is no sanity check when creating OS images, so when some of the
partitions gets too big, part of its data may get overwritten by the
following partition, resulting in corrupted image. Add checks for the
defined partition sizes and bail out if they're too big.
* Fix Supervisor image corruption detection
When multiple images match the reference, multiple IDs are passed as a
single argument to docker image rm, leading to an error:
Error response from daemon: page not found
Make sure to pass the ids as separate argument to make the delete work
in any case.
* Cleanup reusing Supervisor from an old/unused reference
As noted in #2113, we don't need this logic anymore after a major OS
releases. So simply drop the logic to also make the image corruption
detection work again.
* Make sure image IDs are sorted to make them unique
Current mainline contains support for two more WiFi cards in the mt7921u
driver that only use a proprietary VID/PID but are compatible with the
standard driver. Backport support for those via a simple driver patch.
Fixes#2926
* Fix Supervisor image corruption detection
When multiple images match the reference, multiple IDs are passed as a
single argument to docker image rm, leading to an error:
Error response from daemon: page not found
Make sure to pass the ids as separate argument to make the delete work
in any case.
* Cleanup reusing Supervisor from an old/unused reference
As noted in #2113, we don't need this logic anymore after a major OS
releases. So simply drop the logic to also make the image corruption
detection work again.
* Make sure image IDs are sorted to make them unique
Preemptively enable larger set of WiFi drivers for all platforms and add more firmwares for them with the aim to harmonize WiFi device support among all boards and to have implicit support of devices that users might want to use. Targets `generic_aarch64`, `generic_x86_64` and `ova` also include options and firmwares for cards that are using PCI/PCIe bus - support for these is in a separate config fragment.
Especially the `generic_x86_64` is currently very tight with the rootfs space, so I had to do some triaging and select only sensible drivers and firmwares - especially archaic PCMCIA devices or devices not supporting only 802.11g or lower standards were among the first that I removed during the triaging - we can consider enabling those but this time on an someone's explicit need to have them enabled.
This closes#2815 and replaces large part of #2761, also potentially addresses (at least) these: #2806, #2783, #2841, #2776, #2725, #2600
-------------
* Remove WiFi options from generic and board kernel config fragments
* Enable MMC in OVA kernel
This is needed for SDIO drivers to work. Use the same options as we
currently use for generic_x86_64.
* Add CRYPTO_MICHAEL_MIC to the common kernel config
This is requirement for TKIP and is a dependency of ATH11K driver.
* Add kernel config fragments with wireless cards support
* Add firmwares for WiFi cards
* Enable more Bluetooth device drivers
* Remove kernel HCI driver if no WiFi/Bluetooth module present (#2944)
If the WiFi/Bluetooth module is not present on the SDIO bus, remove the
HCI driver. This avoids hci0 interface to be present. Current Home
Assistant Core versions show a Bluetooth device as soon as a hci device
is present. With this change there won't be a Bluetooth device shown.
* Update buildroot-external/package/pi-bluetooth/hcidisable.service
Co-authored-by: Jan Čermák <sairon@users.noreply.github.com>
---------
Co-authored-by: Jan Čermák <sairon@users.noreply.github.com>
* Do not start hciuart.service if krnbt is used
Avoid starting (and failing to start) hciuart.service if krnbt is used.
This avoid unnecessary failed services showing up.
* Update buildroot-external/package/pi-bluetooth/hciuart.service
Co-authored-by: Jan Čermák <sairon@users.noreply.github.com>
* Drop duplicate bluetooth in path
* Avoid bthelper@hci0.service failing
* Revert "Avoid bthelper@hci0.service failing"
This reverts commit f79777e63e.
* Add ExecConditiono to bthelper@.service as well
---------
Co-authored-by: Jan Čermák <sairon@users.noreply.github.com>
* Remove kernel HCI driver if no WiFi/Bluetooth module present (#2944)
If the WiFi/Bluetooth module is not present on the SDIO bus, remove the
HCI driver. This avoids hci0 interface to be present. Current Home
Assistant Core versions show a Bluetooth device as soon as a hci device
is present. With this change there won't be a Bluetooth device shown.
* Update buildroot-external/package/pi-bluetooth/hcidisable.service
Co-authored-by: Jan Čermák <sairon@users.noreply.github.com>
---------
Co-authored-by: Jan Čermák <sairon@users.noreply.github.com>
* Do not start hciuart.service if krnbt is used
Avoid starting (and failing to start) hciuart.service if krnbt is used.
This avoid unnecessary failed services showing up.
* Update buildroot-external/package/pi-bluetooth/hciuart.service
Co-authored-by: Jan Čermák <sairon@users.noreply.github.com>
* Drop duplicate bluetooth in path
* Avoid bthelper@hci0.service failing
* Revert "Avoid bthelper@hci0.service failing"
This reverts commit f79777e63e.
* Add ExecConditiono to bthelper@.service as well
---------
Co-authored-by: Jan Čermák <sairon@users.noreply.github.com>
* Generate self-signed certificates for development
To simplify development generate a self-signed certificate on first
build. Also make sure that the self-signed certificate is being added
the RAUC keyring so that manual updates can be performed.
* Add self-signed certificat independent of deployment type
* Add a warning when building with self-signed certificate
Bluetooth initialization was broken on Yellow because RPi's kernel
started to use initialization by the kernel driver by default, yet
changes from the miniuart-bt overlay are applied directly to Yellow
DTS and had to be updated too. This commit replaces the previous
patch forcing the miniUART usage for Bluetooth with a new one which
is based on the current miniuart-bt-overlay.dts.
Also added a little warning to the RPi kernel bump script, so the
future me/us don't do the same mistake as I did.
* buildroot 20ea6bedda...a48cc458e7 (1):
> package/rpi-firmware: bump to version for stable_20231030 kernel
Reduce fully-expanded configs versioned in our repository to defconfigs
containing only the necessary options. Just like #2923, this change does
not alter the resulting kernel .config in any way for the affected
platforms (Tinker, Odroid C2/C4/N2).
For tinker and amlogic-based targets we're using checked-in kernel
configs generated by kconfig for some old kernel revisions. Check in
current config before we clean it up and reduce to a smaller stub later.
Clean up all kernel configs and fragments from non-existing kernel
options, invalid choice values and choices that trigger warnings
during kernel package configuration.
Here's an example of warnings triggered for Yellow:
.config:8531:warning: override: MODULE_COMPRESS_NONE changes choice state
.config:8536:warning: override: ZSWAP_COMPRESSOR_DEFAULT_LZ4 changes choice state
.config:8537:warning: override: ZSWAP_ZPOOL_DEFAULT_ZSMALLOC changes choice state
.config:8543:warning: override: CPU_FREQ_DEFAULT_GOV_ONDEMAND changes choice state
.config:8717:warning: override: reassigning to symbol CGROUP_HUGETLB
.config:8767:warning: symbol value 'm' invalid for XFRM
.config:8852:warning: symbol value 'm' invalid for MEDIA_CONTROLLER_DVB
.config:8972:warning: symbol value 'm' invalid for SND_HDA_I915
There were also some options that are set in our or default configs
but end up patched by `KCONFIG_(DIS|EN)ABLE_OPT` in package makefiles,
these options are now explicitly set in our fragments too. For example
this was toggled for `generic_aarch64`:
CONFIG_DEFAULT_SECURITY_APPARMOR n -> y
CONFIG_DEFAULT_SECURITY_DAC y -> n
CONFIG_GCC_PLUGINS y -> n
The only goal of this commit is to make sure no warnings appear
anymore and the resulting kernel configs remain unchanged. This will
allow us to create tools for sanity checks of our kernel config
overrides. There is one single change in `ova` config resulting from
previously invalid `m` option for a bool value:
-# CONFIG_9P_FS_POSIX_ACL is not set
+CONFIG_9P_FS_POSIX_ACL=y
* Use kernel local version for HAOS compiled Linux kernel
Use the local version config option to add "haos" to the system's Linux
kernel version to indicate the kernel is built specifically for Home
Assistant OS. This makes sure to overwrite any other local version (e.g.
provided by Raspberry Pi kernel's defconfig) and makes it easier to
verify something is running on HAOS since the string will be visible in
any Container using `uname -a`.
* Add dash in front
* Add missing dependency to kernel.config
* Move CONFIG_IIO up to follow Kconfig hieararchy
---------
Co-authored-by: Jan Čermák <sairon@users.noreply.github.com>
2023-11-01 17:42:27 +01:00
369 changed files with 18148 additions and 21077 deletions
label:Did the problem occur after upgrading the Operating System?
default:0
options:
- "Yes"
- "No"
- "Yes"
- type:textarea
validations:
required:true
attributes:
label:Hardware details
description:>
Provide details about the hardware used for your install.
This is especially important for bare-metal x86 installations.
If you have any USB devices attached, please list them here.
For VMs, include the hypervisor type and version.
- type:textarea
validations:
required:true
@@ -80,10 +94,10 @@ body:
attributes:
label:Anything in the Supervisor logs that might be useful for us?
description:>
Supervisor Logs can be found in [Settings -> System -> Logs](https://my.home-assistant.io/redirect/logs/)
then choose `Supervisor` in the top right.
Supervisor Logs can be found in [Settings -> System -> Logs](https://my.home-assistant.io/redirect/logs/?provider=supervisor)
then choose `Supervisor` in the top right. Alternatively enter `ha supervisor logs` in the Home Assistant CLI.
[](https://my.home-assistant.io/redirect/supervisor_logs/)
[](https://my.home-assistant.io/redirect/logs/?provider=supervisor)
render:txt
- type:textarea
validations:
@@ -91,8 +105,8 @@ body:
attributes:
label:Anything in the Host logs that might be useful for us?
description:>
Host Logs can be found in [Settings -> System -> Logs](https://my.home-assistant.io/redirect/logs/)
then choose `Host` in the top right.
Host Logs can be found in [Settings -> System -> Logs](https://my.home-assistant.io/redirect/logs/?provider=host)
then choose `Host` in the top right. Alternatively enter `ha host logs` in the Home Assistant CLI.
- [Home Assistant Yellow](https://www.home-assistant.io/yellow/) (based custom carrier board and powered by a Raspberry Pi 4 Compute Module)
- [Home Assistant Blue](https://www.home-assistant.io/blue/) (based on ODROID-N2+)
- Raspberry Pi
- Pi 5 ([4 GB](https://www.raspberrypi.com/products/raspberry-pi-5/?variant=raspberry-pi-5-4gb) and [8 GB](https://www.raspberrypi.com/products/raspberry-pi-5/?variant=raspberry-pi-5-8gb) model) 64-bit
- Pi 4 Model B ([1 GB](https://www.raspberrypi.com/products/raspberry-pi-4-model-b/?variant=raspberry-pi-4-model-b-1gb), [2 GB](https://www.raspberrypi.com/products/raspberry-pi-4-model-b/?variant=raspberry-pi-4-model-b-2gb), [4 GB](https://www.raspberrypi.com/products/raspberry-pi-4-model-b/?variant=raspberry-pi-4-model-b-4gb) and [8 GB](https://www.raspberrypi.com/products/raspberry-pi-4-model-b/?variant=raspberry-pi-4-model-b-8gb) model) 32-bit or 64-bit (recommended)
- [Pi 3 Model B](https://www.raspberrypi.com/products/raspberry-pi-3-model-b/) and [B+](https://www.raspberrypi.com/products/raspberry-pi-3-model-b-plus/) 32-bit or 64-bit (recommended)
Home Assistant OS 12 and newer support the ODROID-M1S board.
## SD-card
ODROID-M1S can boot HAOS directly from an SD card, as it has higher priority than the system on the eMMC. Simply flash the image to the SD card using your favorite tool and insert it to the micro SD slot on the board. This works even when the eMMC is wiped, or when it contains the factory-default U-Boot SPL loader, which is still able to load U-Boot provided in the HAOS image. In the second case, however, if the SD card fails to probe (e.g. due to a hardware failure), the system on the eMMC may be booted instead of HAOS.
## eMMC
HAOS can be installed directly to the eMMC using a special boot image, to do that:
1. Download the _UMS Utility_ image: [`ODROID-M1S_EMMC2UMS.img`][1]. The _UMS Utility_ is a special image that switches ODROID-M1S to USB Mass Storage device.
2. Use balenaEtcher or another tool to flash the _UMS utility_ onto an SD card.
3. Plug-in that SD card to your ODROID-M1S and boot it. Connect your PC to the Micro USB OTG port.
4. The eMMC will show as a drive on your PC and you can directly flash the HAOS image with balenaEther.
Installing HAOS replaces the firmware and SPL on the eMMC with the mainline version provided by HAOS. As a result, it is not possible to use the SD card with the EMMC2UMS image anymore, because the mainline SPL is not compatible with U-Boot in the EMMC2UMS image at this time (February 2024). This does not pose any problem for standard use, just makes it more complicated in case you want to return to the Hardkernel-provided OS.
A reliable way of reflashing the eMMC in this case is to use HAOS booted from an SD card. To do that, insert the SD card with HAOS to the micro SD slot and plug the board in. Once the device boots to the HA CLI, enter `login` to enter the root shell and use `curl` to download an image and `dd` it to the eMMC block device:
This way the device will start in the UMS mode on the next boot with the SD card removed. Alternatively you can use the [Hardkernel installer image][2] directly instead of the EMMC2UMS image.
## NVMe
Booting directly from NVMe is not supported. The NVMe card can be used as a data disk.
## Technical notes on boot flow
The Home Assistant OS image is bootable by the SoC directly. Refer to the [boot sequence documentation][3] for the details on what part of the boot is executed from the eMMC and what from the SD card. The steps documented above should however cover all scenarios that a standard user may encounter during usage.
## Console
By default, console access is available on the serial header (UART) and on HDMI.
The serial console's baudrate is 1500000 by default.
The systemd startup messages will only appear on the serial console by default.
To show the messages on the HDMI console instead, add the console manually
to the `cmdline.txt` file on the boot partition (e.g. `console=tty0`).
## GPIO
Odroid-M1S introduces a new 14pin expansion header. Refer to [the ODROID wiki][4].
At this point not all functionality is supported by the upstream kernel used by Home Assistant OS.
@@ -4,6 +4,8 @@ Home Assistant Operating System (formerly HassOS) is a Linux based operating sys
Home Assistant Operating System uses Docker as its container engine. By default it deploys the Home Assistant Supervisor as a container. Home Assistant Supervisor in turn uses the Docker container engine to control Home Assistant Core and Add-Ons in separate containers. Home Assistant Operating System is **not** based on a regular Linux distribution like Ubuntu. It is built using [Buildroot](https://buildroot.org/) and it is optimized to run Home Assistant. It targets single board compute (SBC) devices like the Raspberry Pi or ODROID but also supports x86-64 systems with UEFI.
[](https://www.openhomefoundation.org/)
## Features
- Lightweight and memory-efficient
@@ -14,6 +16,7 @@ Home Assistant Operating System uses Docker as its container engine. By default
## Supported hardware
- Nabu Casa
- Raspberry Pi
- Hardkernel ODROID
- Asus Tinker Board
@@ -37,7 +40,7 @@ The Home Assistant Operating System documentation can be found on the [Home Assi
### Components
- **Bootloader:**
- [Barebox](https://barebox.org/) for devices that support UEFI
- [GRUB](https://www.gnu.org/software/grub/) for devices that support UEFI
- [U-Boot](https://www.denx.de/wiki/U-Boot) for devices that don't support UEFI
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
