As of upstream commit cbd91e89e4
we can use the default BR2_riscv_g to select IMAFD extensions and
still be able to enable additional extensions, such as the C extension
in our cse.
Suggested-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yu Chien Peter Lin <peterlin@andestech.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
In commit 2423d9f16b (Merge tag '2023.08-rc2' into next), we missed
the fact that util-linux on next is a newer version than on master,
version which includes the patch we backported on master.
Unsurprisingly, that patch no longer applies; drop it.
Reported-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
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>
