In commit eb2f2886b2 ("package/swupdate:
add staging install"), the swupdate package was changed to also be
installed in the staging directory, as it provides an API to external
programs, through libraries and headers.
Back then the commit log said:
This patch installs headers and libs to STAGING_DIR, to prevent a
header name collision a subdirectory /usr/include/swupdate creates.
And indeed a custom INCLUDEDIR was specified. However, installing
swupdate headers in /usr/include/swupdate/ doesn't work well, as
progress_ipc.h (installed by swupdate) does a #include
<swupdate_status.h>, which doesn't work as swupdate_status.h is also
in /usr/include/swupdate/ instead of /usr/include/.
To address this Daniel Lang submitted a patch [0], which was proposed
to upstream swupdate to fix this header inclusion. The patch was
rejected by upstream saying that the swupdate header files should be
installed in /usr/include.
Currently, swupdate installs only 3 headers files:
/usr/include/network_ipc.h
/usr/include/swupdate_status.h
/usr/include/progress_ipc.h
To the best of our knowledge, this doesn't conflict with any other
header files installed by other packages. A good proof of that is that
even Debian (which has many more packages than Buildroot) also
installs swupdate headers directly in /usr/include.
In addition, the original submitter of
eb2f2886b2 said "I'm not remember what
was a problem. Probably network_ipc.h but Im not sure now. I think
it's safe to install this headers to /usr/include w/o subdir if this
collision was met only in my environment. PS: currently I don't see
any collisions with this files."
So, we switch to installing swupdate into their standard location.
[0] https://patchwork.ozlabs.org/project/buildroot/patch/VI1P190MB0493D233ECC579510F8C0FC69FB29@VI1P190MB0493.EURP190.PROD.OUTLOOK.COM/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Tested-by: Daniel Lang <dalang@gmx.at>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Let's select the RVA option as Andes 45-series CPUs support IMAFDC
extensions.
Signed-off-by: Yu Chien Peter Lin <peterlin@andestech.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Buildroot commit 8f1418b5dd bumped the
version of gnupg2 on the next branch causing a build error:
server.c:(.text+0xbf8): undefined reference to `ks_ldap_help_variables'
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Commit 0e19425c77 ("package/libassuan: bump to version 2.5.6") moved
the sha256 hash below a link that provides the hash directly. The key
check comment now appears to refer to license hashes, which does not
make sense.
Remove the redundant key check comment.
Cc: Julien Olivain <ju.o@free.fr>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Certain TI K3 devices such as AM62x and AM62Ax require a Device Manager
(DM) firmnware to be made available to the U-Boot build, which will get
packaged into the "tispl.bin" image tree blob during A53 SPL build.
Without that DM firmware U-Boot will not be functional. To support this,
add a config option called BR2_TARGET_UBOOT_NEEDS_TI_K3_DM to enable
this feature, and another option BR2_TARGET_UBOOT_TI_K3_DM_SOC to allow
setting the name of the SOC which needs to match the corresponding
folder name in the ti-linux-firmware Git repository.
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The TI K3 R5 loader package essentially is a wrapper to build a special
version of U-boot SPL used as part of a multi-stage boot flow on TI K3
devices, and as such needs full flexibility as to specifying the U-Boot
sources used for the build. To accomodate this, add the same options as
already available in the regular U-Boot package. For most use cases, the
same source settings (repo URL, versions, etc.) should be used for both
ti-k3-r5-loader and uboot packages.
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The hss-payload-generator cannot find where u-boot.bin is when looking
for it using the config.yaml. Update syntax issues and working
directories. Fix the post image script to allow an image to get built.
Signed-off-by: Jamie Gibbons <jamie.gibbons@microchip.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
By default, when Busybox is enabled, it uses the
package/busybox/busybox.config configuration file, even on noMMU
configurations. As this default configuration enables the 'ash' shell
which isn't available for noMMU targets, Busybox falls back to
enabling the 'hush' shell, but without enabling a number of its
sub-options that are quite relevant. In particular, it doesn't enable
umask, which is used in our startup scripts.
In order to have a default configuration that is more sensible, this
commit changes the Busybox package to use
package/busybox/busybox-minimal.config by default for noMMU
configurations.
Signed-off-by: Jesse Taube <Mr-Bossman075@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Enclosure LED Utilities
ledmon and ledctl are userspace tools designed to control storage
enclosure LEDs. The user must have root privileges to use these tools.
These tools use the SGPIO and SES-2 protocols to monitor and control LEDs.
They been verified to work with Intel(R) storage controllers (i.e. the
Intel(R) AHCI controller) and have not been tested with storage controllers of
other vendors (especially SAS/SCSI controllers).
For backplane enclosures attached to ISCI controllers, support is limited to
Intel(R) Intelligent Backplanes.
Signed-off-by: Maksim Kiselev <bigunclemax@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Commit 2a5d90a595 (configs/rock5b: Add patches to fix gcc12 warnings)
introduced the kernel patches in an incorrect directory.
Fix that by moving them in the proper location.
Reported-by: Kilian Zinnecker <kilian.zinnecker@mail.de>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Since it was introduced in 5a6087d62e (toolchain: add powerpc SPE ABI
support), the CLASSIC vs. SPE choice for the ABI was never really a
choice: CPU without SPE could only use the CLASSIC ABI, while CPUs with
SPE could only use the SPE ABI.
Commit b4c824562b (powerpc: add BR2_POWERPC_CPU_HAS_SPE to replace
adhoc deps/checks) added a blind option that CPUs with SPE would select
rather than duplicate the ad-hoc dependencies in both CLASSIC and SPE
ABI options. Since then, it was even more obvious that the ABI choice
was really not a choice, as the two options have mutually exclusive
conditions.
Drop the useless choice, and directly use the blind option as selected
by the specific CPUs.
We don't need legacy handling, because the situation fixes itself.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Joel Stanley <joel@jms.id.au>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Other packages, or rootfs overlays, may install certificates, so only
create the certificate bundle as a target-finalize hook.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
