Currently, WLAN DHCP is only enabled when the value of
PRESET_NET_USE_STATIC is explicitly set to 0. It is not enabled when
this configuration is uncommented or omitted. This change adjusts the
behavior so that DHCP is enabled by default unless a static network
configuration is used.
Signed-off-by: Marcello Sylvester Bauer <marcello.bauer@9elements.com>
* rockchip: Add NanoPi M5 board support to edge kernel
* rockchip64: enable Rockchip ASoC drivers and codecs in kernel config
* config: Fix audio Kconfig tristate hierarchy
Set CONFIG_SOUND, CONFIG_SND, and CONFIG_SND_SOC to built-in (y)
to allow Rockchip audio drivers to be built-in instead of being
silently downgraded to modules by olddefconfig.
* nanopi-m5: Add asound.state for audio configuration
* nanopi-m5: Fix SAI2 clock output
XpressReal(https://xpressreal.io/) is a family of Single Board Computers
developed in collaboration between Fyde Innovations, Radxa and Realtek.
XpressReal T3 is the first product in the family - a small form factor
high performance single board computer powered by the Realtek RTD1619B,
which runs FydeOS/openFyde and Linux!
Now we are adding the awesome Armbian Linux support for XpressReal T3!
This commit introduces some binary files that XpressReal T3 needed:
- firmware/realtek/rtd1619b
These binaries are the firmware for rtd1619b peripherals
(including the audio decoder, video decoder, etc.).
- u-boot-fw.tar.gz
This contains some co-processor firmware,
which needs to be loaded by u-boot in the early stage of boot.
- u-boot-prebuilt.tar.gz
These are hwsettings related files, used for tasks such as DDR initialization.
These files come from the rtd1619b SDK, which has already been open-sourced on our github:
- [firmware](https://github.com/XpressReal/linux-sdk/tree/main/meta-xpressreal/recipes-kernel/linux-firmware/files/rtd1619b)
- [u-boot prebuilts](https://github.com/XpressReal/linux-sdk/tree/main/meta-xpressreal/recipes-bsp/u-boot/files/prebuilt/rtd1619b)
Texas Instruments maintains a custom apt repository [0] that contains:
* tools like k3conf, which run on K3 devices
* TI's versions of upstream packages (such as mesa)
* out-of-tree drivers and firmware for graphics, wifi etc
Therefore, add TI's custom repository as the highest priority repository
in the filesystem. Doing this ensures that if apt finds a version of a
package that exists in both upstream Debian and the TI repository, it
picks the latter.
Additionally, introduce K3_PACKAGES variable to store a list of packages
that should be installed by-default in a K3 image. Initialize it to hold
TI's CC33xx packages.
Also set EXTRAWIFI to "no" in `current` image.
[0] https://github.com/TexasInstruments/ti-debpkgs
Co-authored-by: Suhaas Joshi <s-joshi@ti.com>
Signed-off-by: Suhaas Joshi <s-joshi@ti.com>
* helios4: fix wake-on-lan (wol)
- added ethtool package
- enable wol on all ethernet interfaces
- support common systemd.net-naming-schemes (ethX/endX/enoX)
* Update helios4-wol.service
Removed test code.
* Update helios4-wol.service
Fix bug after retesting.
- we might want to have different welcome colors for stable and nightly images
- this adds another branding option alongside with VENDOR, VENDORURL, VENDORSUPPORT, ...
fix: /usr/lib/armbian/armbian-firstlogin: line 406:
break: only meaningful in a `for', `while', or `until' loop
Signed-off-by: Martin Schmiedel <Martin.Schmiedel@tq-group.com>
While it is unusual to run both NetworkManager and systemd-networkd
simultaneiously and doing so can cause startup problems, there is
nothing inherently wrong with doing so: the services are not
incompatible and some people run both, each managing different
interfaces.
The Armbian build framework enables one or the other but not both.
Therefore, if both are enabled at first login, it is probably because
the user has manually modified the image. In this case, trust that the
user knows what they are doing and don't disable one of them.
NetworkManager and systemd-networkd should never both be enabled
at the same time. In this case, disable systemd-networkd, with
message to the user that this is being done.
Avoid waiting for the NetworkManager-wait-online or
systemd-networkd-wait-online service to complete in the midst of
prompting for root account password.
