mwleeds@mailtundra.com <mwleeds@mailtundra.com> says:
This patch series is needed to get U-Boot to boot from a ZFS filesystem
on an aarch64 computer. Some of the patches are not architecture specific
and would be needed to boot ZFS on other platforms as well. The ZFS
support in U-Boot hasn't been substantively touched in several years and
to me it seems like it must have been broken for a long time on all
platforms, but I have only tested on aarch64.
Since there doesn't seem to be a mantainer for this area who I can cc,
I'm hoping these patches get seen and pulled in by a general U-Boot
maintainer.
[trini: Per Igor's comment and Phaedrus agreement, dropped his Tested-by
on the patches themselves]
Without this patch, the while loop being modified goes on infinitely,
but with the patch I am able to boot linux on zfs on a jetson tx2 nx.
It seems like this code was never tested because the logic is clearly
wrong. The function do_div(a,b) does a division that modifies the first
parameter to have a = a / b, and returns the remainder of the division.
So clearly in the usual case when file->offset = 0, the line
"blkid = do_div(blkid, blksz);" just results in blkid being set to zero
on every iteration of the loop, rather than being incremented as blocks
are read. Hence the zeroth block is read over and over and this becomes
an infinite loop.
So instead capture the remainder of the division in a "blkoff" variable,
and use that to properly calculate the memory address to move from in
memmove() below.
For example, if file->offset were 1337, on the first iteration of the
loop blkid would be 0 and blkoff would be 1337. If the blksz is 131072
(as it was for me), that amount of data would be copied into
data->file_buf. movesize would be 131072 - 1337 = 129735 so 129735 bytes
would be moved into buf. On the second iteration of the loop (assuming
there is one), red would be 129735, blkid would be 1, blkoff would be 0,
and 131072 bytes would be copied into buf. And so on...
Signed-off-by: Phaedrus Leeds <mwleeds@mailtundra.com>
As evidenced by how other filesystems handle it, a return value of 0
from fs_devread() means failure; nonzero means success. The opposite
assumption was being made in zfs.c for the use of zfs_devread() so fix
the confusion by making zfs_devread() return 0 on success.
It probably doesn't make sense to change the handling of zfs_devread()
in zfs.c instead, because as it is it matches the semantics of the other
functions there.
Signed-off-by: Phaedrus Leeds <mwleeds@mailtundra.com>
Without this patch, when trying to boot zfs using U-Boot on a Jetson TX2
NX (which is aarch64), I get a CPU reset error like so:
"Synchronous Abort" handler, esr 0x96000021
elr: 00000000800c9000 lr : 00000000800c8ffc (reloc)
elr: 00000000fff77000 lr : 00000000fff76ffc
x0 : 00000000ffb40f04 x1 : 0000000000000000
x2 : 000000000000000a x3 : 0000000003100000
x4 : 0000000003100000 x5 : 0000000000000034
x6 : 00000000fff9cc6e x7 : 000000000000000f
x8 : 00000000ff7f84a0 x9 : 0000000000000008
x10: 00000000ffb40f04 x11: 0000000000000006
x12: 000000000001869f x13: 0000000000000001
x14: 00000000ff7f84bc x15: 0000000000000010
x16: 0000000000002080 x17: 00000000001fffff
x18: 00000000ff7fbdd8 x19: 00000000ffb405f8
x20: 00000000ffb40dd0 x21: 00000000fffabe5e
x22: 000000ea77940000 x23: 00000000ffb42090
x24: 0000000000000000 x25: 0000000000000000
x26: 0000000000000000 x27: 0000000000000000
x28: 0000000000bab10c x29: 00000000ff7f85f0
Code: d00001a0 9103a000 94006ac6 f9401ba0 (f9400000)
Resetting CPU ...
This happens when be64_to_cpu() is called on a value that exists at a
memory address that's 4 byte aligned but not 8 byte aligned (e.g. an
address ending in 04). The call stack where that happens is:
check_pool_label() ->
zfs_nvlist_lookup_uint64(vdevnvlist, ZPOOL_CONFIG_ASHIFT,...) ->
be64_to_cpu()
Signed-off-by: Phaedrus Leeds <mwleeds@mailtundra.com>
Fixes: 4d3c95f5ea7c ("zfs: Add ZFS filesystem support")
This code was hitting the error code path whenever malloc() succeeded
rather than when it failed, so presumably this part of the code hasn't
been tested. I had to apply this fix (and others) to get U-Boot to boot
from ZFS on an Nvidia Jetson TX2 NX SoM (an aarch64 computer).
Signed-off-by: Phaedrus Leeds <mwleeds@mailtundra.com>
If tcp_seq_num is wrap around, tcp_seq_num >= initial_data_seq_num
isn't satisfied and store_block() isn't called.
The condition has a wrap around issue, so it is fixed in this patch.
Signed-off-by: Yasuharu Shibata <yasuharu.shibata@gmail.com>
Reviewed-by: Michael Trimarchi <michael@amarulasolutions.com>
Suggested-by: Michael Trimarchi <michael@amarulasolutions.com>
Reported-by: Tim Harvey <tharvey@gateworks.com>
Tested-by: Fabio Estevam <festevam@denx.de>
The server sends multiple packets without waiting for an ACK
by window control and if some packets are dropped,
wget will return an ACK including the dropped packets.
Following log indicates this issue.
wget_handler() wget: Transferring, seq=97bbdd4a, ack=30,len=580
wget_handler() wget: Transferring, seq=97bbedca, ack=30,len=580
First packet of TCP sequence number is 0x97bbdd4a.
Second packet of TCP sequence number should be 0x97bbe2ca,
however it is 0x97bbedca and returns its ACK, so the server
suppose that 0x97bbe2ca and 0x97bbedca are received appropriately.
In this case, 0x97bbe2ca was lost and the data of wget was broken.
In this patch, next_data_seq_num holds the next expected
TCP sequence number.
If the TCP sequence number different from next_data_seq_num,
trying to retransmit the packet.
Signed-off-by: Yasuharu Shibata <yasuharu.shibata@gmail.com>
Tested-by: Fabio Estevam <festevam@gmail.com>
CI:
https://source.denx.de/u-boot/custodians/u-boot-imx/-/pipelines/20348
- Update the imx_rgpio2p to only access one address as per the
dt-schema.
- Remove unused imx9_cpu.c file.
- Only use the LPUART ipg clk for i.MX7ULP.
- Use the correct anatop base for accessing the PLL clocks on i.MX93.
- Add option to reprogram FPGA every reboot, enable this as default in
chameleonv3 defconfig.
- Fixes: Rename CONFIG_SPL_SOCFPGA_SEC_REG to CONFIG_SPL_SOCFPGA_DT_REG,
so the driver can be built when CONFIG_SPL_SOCFPGA_DT_REG is set in
defconfig.
The i.MX8ULP/93 gpio dt-schema have been updated to only have one
address entry, update the driver to support it.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
The value defaults to 0 and is ignored by dw_mmc code, so the other
users are not affected.
Setting this explicitly fixes some weird reading error found on Hi3798MV200.
Fixes: 8a5dc8140e62 ("mmc: hi6220_dw_mmc: add compatible for HC2910 support")
Signed-off-by: Yang Xiwen <forbidden405@outlook.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
This can avoid hardcoding a clock rate in driver. Also can enable the
clocks and deassert the resets if the pre-bootloader does not do this
for us.
Currently only enabled for Hi3798MV200.
Signed-off-by: Yang Xiwen <forbidden405@outlook.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Place the SDR104/HS200/HS400 checks into the mmc_deinit() and always
call it. This simplifies the code and removes ifdeffery. No functional
change is expected.
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
Do not access SCC when sending commands during tuning operation as that
will disrupt the tuning operation. The tuning operation is adjusting the
SCC settings itself in execute_tuning callback.
When renesas_sdhi_execute_tuning() is called by the MMC core code, a loop
which consists of renesas_sdhi_prepare_tuning(), mmc_send_tuning() and
renesas_sdhi_compare_scc_data() iterates over each SCC tuning tap.
The renesas_sdhi_prepare_tuning() configures the SCC tuning tap number into
hardware, mmc_send_tuning() triggers transfer of tuning block which depends
on the bus mode for which the bus is currently being tuned, this information
is supplied by the MMC core code, and finally renesas_sdhi_compare_scc_data()
tests the received tuning block for validity.
Because renesas_sdhi_prepare_tuning() configures the SCC tuning tap into
the hardware to fit the tuning operation, mmc_send_tuning() which triggers
command transfer using renesas_sdhi_send_cmd() must not manipulate with
the SCC in any way. Currently renesas_sdhi_send_cmd() does unconditionally
call renesas_sdhi_check_scc_error(), which may adjust the SCC tuning tap
position by writing RENESAS_SDHI_SCC_TAPSET, which would overwrite the
required tuning configuration set by renesas_sdhi_prepare_tuning() and
disrupt the tuning operation.
Fix this by skipping the renesas_sdhi_check_scc_error() call in case the
MMC subsystem is in tuning state. This way, the SCC settings are left
unmodified by command transfer during tuning operation.
Reviewed-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Tested-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Set generic mmc->tuning flag when performing tuning to indicate
this condition to drivers. Drivers may use this to bypass various
checks during tuning.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
This hs400_tuning is a flag, make it bool. No functional change.
This will be useful in the following patch, which adds another
more generic flag, where the compiler can better use the space
now reserved for the u8 to store more flags in it.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
The current code uses the state of tuning block received by SCC to
determine whether or not to send transmission stop command. This is
not correct. Use the state of tuning block transfer to determine
whether or not to send transmission stop command instead, because
the transmission stop command has to be sent in case the tuning
block transfer failed.
This requires two changes, separate variable to store and check the
state of tuning block received by SCC, and another separate variable
to store and check return value from transmission stop command.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Tested-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
In case a CRC error occurs during DMA transfer, the transfer completion
flag is not set in TMIO_SD_DMA_INFO1 and the transfer would eventually
time out. The timeout could be very long in case the transfer consists
of a large amount of blocks, the base timeout is 10 seconds and every
block adds 100 us more.
In case a CRC error does occur, a completion flag is set in a different
register, TMIO_SD_INFO1. Use this other completion flag to detect DMA
transfer ended and stop waiting for TMIO_SD_DMA_INFO1 completion flag.
This reduces the lengthy timeout in case of an error. The unconditional
check of TMIO_SD_DMA_INFO2 register for DMA related errors must not be
skipped in any case to actually recognize the DMA error and report it.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Tested-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
The PL180/MMCI driver is implied to use CONFIG_DM and the ARM
defconfigs such as configs/vexpress_ca9x4_defconfig will get it
as well.
With a simple oneline to default to not being the v2 variant,
the original ARM MMCI variant works fine with the driver as well.
The IP version actually needs to be read out from a register on
the ARM versions, but we will simply assume we are running on the
original hardware if arm,primecell-periphid is not explicitly
specified in the device tree.
Drop the !CONFIG_DM code and depend on DM_MMC.
Tested on the Versatile Express CA9x4 board.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
With MMC_PWRSEQ enabled the following link issue may happen when
building SPL and SPL_PWRSEQ is not enabled.
aarch64-linux-gnu-ld.bfd: drivers/mmc/meson_gx_mmc.o: in function `meson_mmc_probe':
drivers/mmc/meson_gx_mmc.c:295: undefined reference to `pwrseq_set_power'
Fix this by adding a SPL_MMC_PWRSEQ Kconfig option used to enable mmc
pwrseq support in SPL.
Also add depends on DM_GPIO to fix following link issue:
aarch64-linux-gnu-ld.bfd: drivers/mmc/mmc-pwrseq.o: in function `mmc_pwrseq_set_power':
drivers/mmc/mmc-pwrseq.c:26: undefined reference to `gpio_request_by_name'
aarch64-linux-gnu-ld.bfd: drivers/mmc/mmc-pwrseq.c:29: undefined reference to `dm_gpio_set_value'
aarch64-linux-gnu-ld.bfd: drivers/mmc/mmc-pwrseq.c:31: undefined reference to `dm_gpio_set_value'
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Acked-by: Ferass El Hafidi <vitali64pmemail@protonmail.com>
If the CSD register contains a reserved value (4 - 7) in bits 0:2 of the
TRAN_SPEED field, a buffer overrun occurs. Resize the mapping table.
According to the original report
https://lore.kernel.org/u-boot/20180826231332.2491-11-erosca@de.adit-jv.com/
reserved values have been observed resulting in a buffer overrun.
Reported-by: Eugeniu Rosca <erosca@de.adit-jv.com>
Fixes: 272cc70b211e ("Add MMC Framework")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Commit 3f190c55a4211215914126b74357344342329943
("drivers: misc: Add socfpga_dtreg driver for Intel SoCFPGA")
This commit rename CONFIG_SPL_SOCFPGA_SEC_REG to CONFIG_SPL_SOCFPGA_DT_REG
in Makefile.
Signed-off-by: Wan Yee Lau <wan.yee.lau@intel.com>
Add Kconfig that enables FPGA reprogramming with warm boot on Arria 10.
This option allows to change the bitstream on the filesystem and apply
changes with warm reboot without the need for a power cycle.
Signed-off-by: Michał Barnaś <barnas@google.com>
The second patch is by Arseniy Krasnov and adds basic support for Amlogic
Meson NAND controller on AXG.
The following four patches are by Alexander Dahl and apply some fixes to
drivers/mtd/nand/raw/ and port some changes applied in Linux.
The following patch is by Bruce Suen and adds support for XTX SPINAND.
Finally, the last patch is again by Arseniy Krasnov and adds access to
OTP region, supporting info, dump, write and lock operations.
-----BEGIN PGP SIGNATURE-----
iQJYBAABCgBCFiEE6GOTDNYiFygVXvMmQBtB6IWRjvEFAmYb2iwkHGRhcmlvLmJp
bmFjY2hpQGFtYXJ1bGFzb2x1dGlvbnMuY29tAAoJEEAbQeiFkY7xQsIQAKCD8fbL
swGIcqJhC4uzF9mi1aeElCRYIy4uXYsu5ZBVM3dXjzxOH6J0luskEbIqJLpP5RWY
wKtE09qBM5jZWmSAaH338SJdAqb/YR8+OC8mkAlYxx6Z77JNyb7zYePixRVceBUr
zSRMlU6S1V+t3yWfv+hB7PWSoD5mpqRMK72UGeDjn+MBppsaGzghPKkSj8TMYRPE
VPjZ/0qCdUdE7D2/4JNDdLsWZGTby+xz9wZ7xh/MXRgBG+TnZe1hf9+jxp5XW4Mw
Mig44gBp97z0HgQYPv3K7COUY+Ljhq8S/kUw6gIajS9/mrHHNGy5Afh+bSUezwY1
Bn5+c2DvNfMln+jIFsstZfd0RKioxYm9xyBGnIIJbJAXofEK58UcBtABd4Bwjz5O
2/twvLZtGwLRHfzqSxNg29Nuccn9HXHVYYiCsiXs5S5FBAAJO4TzN1dQZdsY9bmH
H1LO+jn0KkGPtUZHTeNYEJL/t7vQwrdc05ZLF/chx72IxDf6ZYX4b7vAYLW6lndV
eaRQtlkAwZytwYrR43uZAHrGGoS2CAIw8/hYYbh8xa9IGAgDYfG+cAQHeGCN1Yml
QqwGclHyUmT7XUCtIpSldREngOAJPfIdmSo777SkP9z5IPIAFbfAnfHFz4SFQFTv
deCNjA6gNKVIIchS1e5VQA+m4z5iAjHAMdZ1
=vjgL
-----END PGP SIGNATURE-----
Merge tag 'u-boot-nand-20240414' of https://source.denx.de/u-boot/custodians/u-boot-nand-flash
The first patch is by Weizhao Ouyang and avoids sf probe crashes.
The second patch is by Arseniy Krasnov and adds basic support for Amlogic
Meson NAND controller on AXG.
The following four patches are by Alexander Dahl and apply some fixes to
drivers/mtd/nand/raw/ and port some changes applied in Linux.
The following patch is by Bruce Suen and adds support for XTX SPINAND.
Finally, the last patch is again by Arseniy Krasnov and adds access to
OTP region, supporting info, dump, write and lock operations.
Add access to OTP region. It supports info, dump, write and lock
operations. Usage example:
'mtd otpread nand0 u 0 1024' - dump 1024 bytes of user area starting
from offset 0 of device 'nand0'.
'mtd otpwrite nand0 10 11223344' - write binary data 0x11, 0x22, 0x33,
0x44 to offset 10 to user area of device 'nand0'.
'mtd otplock nand0 0 1024' - lock 1024 bytes of user area starting
from offset 0 of device 'nand0'.
'mtd otpinfo nand0 f' - show info about factory area of device 'nand0'.
Link: https://lore.kernel.org/all/20240326223919.3781-1-avkrasnov@salutedevices.com
Signed-off-by: Arseniy Krasnov <avkrasnov@salutedevices.com>
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Add support for XTX XT26G0xA and XT26xxxD. The driver is ported from
linux-6.7.1. This driver is tested on Banana BPI-R3 with XT26G01A and
XT26G12D.
Link: https://lore.kernel.org/all/20240312014314.15454-1-bruce_suen@163.com
Signed-off-by: Bruce Suen <bruce_suen@163.com>
Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Introduced with commit 6a8dfd57220d ("nand: atmel: Add DM based NAND
driver") when driver was initially ported from Linux. The context
around this and especially the code itself suggests 'read' is meant
instead of write.
The fix is the same as accepted in Linux already with mainline Linux
kernel commit 1c60e027ffde ("mtd: nand: raw: atmel: Fix comment in
timings preparation").
Link: https://lore.kernel.org/all/20240320090214.40465-6-ada@thorsis.com
Link: https://lore.kernel.org/linux-mtd/20240307172835.3453880-1-miquel.raynal@bootlin.com/T/#t
Signed-off-by: Alexander Dahl <ada@thorsis.com>
Reviewed-by: Michael Trimarchi <michael@amarulasolutions.com>
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
One tab in general. One tab plus two spaces for help text.
Link: https://lore.kernel.org/all/20240320090214.40465-4-ada@thorsis.com
Signed-off-by: Alexander Dahl <ada@thorsis.com>
Reviewed-by: Michael Trimarchi <michael@amarulasolutions.com>
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Introduced in upstream Linux with commit 7a08dbaedd365 for release v5.0.
When the new atmel nand driver was backported to U-Boot with commit
6a8dfd57220d ("nand: atmel: Add DM based NAND driver") that definition
was added to the driver instead of the header file. Move it over to the
other definitions with the same help text it has in Linux.
Code actually using this has not been ported over to raw nand base yet.
Link: https://lore.kernel.org/all/20240320090214.40465-3-ada@thorsis.com
Signed-off-by: Alexander Dahl <ada@thorsis.com>
Reviewed-by: Michael Trimarchi <michael@amarulasolutions.com>
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
In every other place in this file the macro is used, make it consistent.
Link: https://lore.kernel.org/all/20240320090214.40465-2-ada@thorsis.com
Fixes: 9d1806fadc24 ("mtd: nand: Get rid of mtd variable in function calls")
Signed-off-by: Alexander Dahl <ada@thorsis.com>
Reviewed-by: Michael Trimarchi <michael@amarulasolutions.com>
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Basic support for Amlogic Meson NAND controller on AXG. This version
works at only first EDO mode.
Based on Linux version 6.7.0-rc4.
Link: https://lore.kernel.org/all/20240210223927.570043-1-avkrasnov@salutedevices.com
Signed-off-by: Arseniy Krasnov <avkrasnov@salutedevices.com>
Reviewed-by: Michael Trimarchi <michael@amarulasolutions.com>
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Handle the return value of spi_flash_probe_bus_cs() to avoid sf probe
crashes.
Link: https://lore.kernel.org/all/20240104114619.280513-1-o451686892@gmail.com
Signed-off-by: Weizhao Ouyang <o451686892@gmail.com>
Reviewed-by: Michael Trimarchi <michael@amarulasolutions.com>
Acked-by: Michal Simek <michal.simek@amd.com>
Reviewed-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Documentation:
* bump build dependency idna to 3.7
* update docker image reference to latest
* fix section levels in gen_compile_commands
* fix references to trace doc
UEFI:
* eliminate duplicate runtime section definitions
* let 'EFI using ACPI tables at' be a debug message
* sanitize efi_tcg2_final_events_table definition
* move efi_var_collect to common functions
* improve error messages in variables unit test by using
EFI_UNSUPPORTED for private authenticated variables
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEK7wKXt3/btL6/yA+hO4vgnE3U0sFAmYaTz8ACgkQhO4vgnE3
U0tH+w/8CfC10gOWcBd0zKyJIB/jwnJAKZc3mFVwFF9FjeM7XlVsb3uthHV6hVdu
BS7MNSwv5LR8ZqEjtdcLFIsMUjwPCO/Gu1xaTfuMYnrQkOQEOAZU8AFY9gMiyhN0
WndbyO8lszLBV/PV8Nqh4rIV7uzFYqcIxn8XvsjQ1fuhU+3HnepYcdV7P/eVaA4i
HpuUpmvsnig1xaw+Cm6KbfOhgf9eYmjJn/PTmBnkJwh+7PHzQAC6J+1Sx+Mz2g7S
9qiuRaim+phdr5DO8bkzrHzK/0b6Civof3hhYdfh8jARaitnhEmJX8LFICe3Er7C
dqGeoDogwfvCvQV9ykZidE7vr4DK0UFxJ5A8eswHuD8l28rXeQJKvPEx7y75W9Ht
pj30/+LZ542UHhJZTGO3Oi7dKz3icX7ouaoV4qtXOYG0+UgrygSgNdR7zeNk0XGq
0x2OWgohPZxeb36e1Uqq4dAm9ARPpRia33ZN8JN8Qs4SQA3y0Lye6/Q5KiNT0n72
kzI1P6TdZamUWvfr1NzwUZz+LryozbI4bOw0uHP4jefG4chb/TSWftuXTrTvzBl1
1CLYYYWqC8t5XNz8ypXKtcSuYKKQZkIsJsEF1NBd5L8hWttKAhvbfuykTOVUAttg
wOmvJX1lsNczMh2/3aS2Pf3fqOSfM30lXu4kyop1dWEDmtWOlhc=
=PpZf
-----END PGP SIGNATURE-----
Merge tag 'efi-2024-07-rc1-2' of https://source.denx.de/u-boot/custodians/u-boot-efi
Pull request efi-2024-07-rc1-2
Documentation:
* bump build dependency idna to 3.7
* update docker image reference to latest
* fix section levels in gen_compile_commands
* fix references to trace doc
UEFI:
* eliminate duplicate runtime section definitions
* let 'EFI using ACPI tables at' be a debug message
* sanitize efi_tcg2_final_events_table definition
* move efi_var_collect to common functions
* improve error messages in variables unit test by using
EFI_UNSUPPORTED for private authenticated variables
While we unlikely to have an issue with CVE-2024-3651, it is simple
enough to bump our version of idna to receive the fix, do so.
Reported-by: GitHub dependabot
Signed-off-by: Tom Rini <trini@konsulko.com>
Tested-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
The README.trace has been moved and converted to rst in commit dce26c7d56ed
("doc: move README.trace to HTML documentation"); fix all the remaining
references to this file.
Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com>
Cc: Tom Rini <trini@konsulko.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
The length of the variable name typically is not 1.
Neither the length of the variable name nor the size of the appended
data is known in the include.
* Define the size of element variable_name as variable.
* Remove the unusable element variable_data.
Addresses-Coverity-ID: 467400 Out-of-bounds read
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
