Endianness depends on CPU architecture. CONFIG_CPU_(BIG/LITTLE)_ENDIAN should
be enabled on target or subtarget based on SoC architecture.
Fixes warning:
$ make kernel_oldconfig CONFIG_TARGET=subtarget
...
.config:1008:warning: override: CPU_LITTLE_ENDIAN changes choice state
....
Summary:
- ARC - only the CONFIG_CPU_BIG_ENDIAN symbol is defined for this architeture.
If it is disabled then the processor operates in LITTLE_ENDIAN mode (default),
- ARM32 - CONFIG_CPU_LITTLE_ENDIAN symbol available since kernel 5.19. This
option should be enabled after OpenWRT moves to kernel 6.x. After refreshing
the kernel, the symbol disappears,
- ARM64 - enabled CONFIG_CPU_LITTLE_ENDIAN,
- MIPS - enabled relevant symbols,
- POWERPC - enabled CONFIG_CPU_BIG_ENDIAN,
- UML - Symbols are not defined for this architecture,
- X86 - always little endian. Symbols are not defined for this architecture.
Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl>
Broadcom's U-Boot contains environment data blocks. They need to be
found (offsets aren't predefined) to access env variables.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
All targets expect the malta target already activate the CONFIG_GPIOLIB
option. Move it to generic kernel configuration and also activate it for
malta.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
This fixes problem of overwriting BCM4908 U-Boot and DTB files by
BCM4912 ones. That bug didn't allow booting BCM4908 devices.
Fixes: f4c2dab544 ("uboot-bcm4908: add BCM4912 build")
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
In theory we could have just 1 bootfs image for all devices as each
device has its own entry in the "configurations" node. It doesn't work
well with default configuration though.
If something goes wrong U-Boot SPL can be interrupted (by pressing A) to
enter its minimalistic menu. It allows ignoring boardid. In such case
bootfs default configuration is used.
For above reason each SoC family (BCM4908, BCM4912) should have its own
bootfs built. It allows each of them to have working default
configuration.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
This is now built-in, enable so it won't propagate on target configs.
Link: https://lkml.org/lkml/2022/1/3/168
Fixes: 79e7a2552e ("kernel: bump 5.15 to 5.15.44")
Fixes: 0ca9367069 ("kernel: bump 5.10 to 5.10.119")
Signed-off-by: Tomasz Maciej Nowak <tmn505@gmail.com>
(Link to Kernel's commit taht made it built-in,
CRYPTO_LIB_BLAKE2S[_ARM|_X86] as it's selectable, 5.10 backport)
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
As the upcoming release will be based on Linux 5.10 only, remove all
kernel configuration as well as patches for Linux 5.4.
There were no targets still actively using Linux 5.4.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
exit in preinit script was stopping whole process
Fixes: 93259e8ca2 ("bcm4908: support "rootfs_data" on U-Boot devices")
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
1. Create "rootfs_data" dynamicaly
U-Boot firmware images can contain only 2 UBI volumes: bootfs (container
with U-Boot + kernel + DTBs) and rootfs (e.g. squashfs). There is no way
to include "rootfs_data" UBI volume or make firmware file tell U-Boot to
create one.
For that reason "rootfs_data" needs to be created dynamically. Use
preinit script to handle that. Fire it right before "mount_root" one.
2. Relate "rootfs_data" to flashed firmware
As already explained flashing new firmware with U-Boot will do nothing
to the "rootfs_data". It could result in new firmware reusing old
"rootfs_data" overlay UBI volume and its file. Users expect a clean
state after flashing firmware (even if flashing the same one).
Solve that by reading flash counter of running firmware and storing it
in "rootfs_data" UBI volume. Every mismatch will result in wiping old
data.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Each of
- CRYPTO_AEAD2
- CRYPTO_AEAD
- CRYPTO_GF128MUL
- CRYPTO_GHASH
- CRYPTO_HASH2
- CRYPTO_HASH
- CRYPTO_MANAGER2
- CRYPTO_MANAGER
- CRYPTO_NULL2
either directly required for mac80211 crypto support, or directly
selected by such options. Support for the mac80211 crypto was enabled in
the generic config since c7182123b9 ("kernel: make cryptoapi support
needed by mac80211 built-in"). So move the above options from the target
configs to the generic config to make it clear why do we need them.
CC: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com>
Both CLANG_VERSION and LLD_VERISON are autogenerated runtime
configuration options, so add them to the kernel configuration filter
and remove from generic and per-target configs to keep configs clean.
Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com>
BCM4908 devices with U-Boot use pkgtb firmware format. It's based on
U-Boot's FIT: DTB with configurations, images & embedded data.
This format contains bootfs, rootfs and optionally a first stage U-Boot
loader. Contained images need to be extracted & flashed.
Broadcom used two sets of firmwares: main & backup. It uses UBI volumes
"metadata1" & "metadata2" for storing U-Boot env variables with info
about flashed images.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
This results in setting format specific data (format info, extract
commands) in a single function. It should help maintaining sysupgrade
code.
This change has been tested on Asus GT-AC5300 and Netgear R8000P.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
This target does not activate CONFIG_PCI kernel configuration option, do
not activate the PCI feature. This will deactivate some PCI drivers
which are not building without PCI support in the kernel.
If PCI_SUPPORT or PCIE_SUPPORT are activated in the kernel configuration
the feature flag will be automatically set by the build system again.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Deactivate all the symbols of the B53 DSA driver in the generic kernel
configuration. Multiple targets are now using this drivers and they
only need some of the options.
This fixes the bcm4908 build which didn't deactivate all of the options.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
bootfs still needs more work before it's ready.
For some unknown reason model RAXE500 uses board id RAX220.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
