Pali Rohár [Mon, 1 Aug 2022 13:31:46 +0000 (15:31 +0200)]
board: freescale: p1_p2_rdb_pc: Turn off watchdog before reset
P1/P2 RDB boards have external max6370 watchdog connected to CPLD and this
watchdog is not deactivated on board reset. So if it is active during board
reset, it can trigger another reset when CPU is booting U-Boot. To prevent
possible infinite reset loop caused by external watchdog, turn it off
before reset.
Do it via a new board_reset_prepare() callback which is called from
do_reset() function before any reset sequence.
Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Pali Rohár [Mon, 1 Aug 2022 13:31:45 +0000 (15:31 +0200)]
board: freescale: p1_p2_rdb_pc: Avoid usage of CPLD's system reset register
CPLD's system reset register is buggy and requires workaround in U-Boot.
So use this kind of board reset only when there is no other reset option.
Introduce a new board_reset_last() callback which is last-stage
board-specific reset and implement CPLD's system reset in this new
board_reset_last() callback instead of board_reset() callback.
Pali Rohár [Mon, 1 Aug 2022 13:31:44 +0000 (15:31 +0200)]
board: freescale: p1_p2_rdb_pc: Add workaround for non-working watchdog
If watchdog timer was already set to non-disabled value then it means that
watchdog timer was already activated, has already expired and caused CPU
reset. If this happened then due to CPLD firmware bug, writing to wd_cfg
register has no effect and therefore it is not possible to reactivate
watchdog timer again. Watchdog starts working again after CPU reset via
non-watchdog method.
Implement this workaround (reset CPU when it was reset by watchdog) to make
watchdog usable again. Watchdog timer logic on these P1/P2 RDB boards is
connected to CPLD, not to SoC itself.
Note that reset does not occur immediately after calling do_reset(), but
after few ms later as real reset is done by CPLD. So it is normal that
function do_reset() returns. Therefore hangs after calling do_reset() to
prevent CPU execution of the rest U-Boot code.
Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Pali Rohár [Mon, 1 Aug 2022 13:31:43 +0000 (15:31 +0200)]
board: freescale: p1_p2_rdb_pc: Add workaround for board reset reboot loop
CPLD's system reset register on P1/P2 RDB boards is not autocleared after
flipping it. If this register is set to one in 100ms after reset starts
then CPLD triggers another CPU reset.
This means that trying to reset board via CPLD system reset register cause
reboot loop. To prevent this reboot loop, the only workaround is to try to
clear CPLD's system reset register as early as possible. U-Boot is already
doing it in its board_early_init_f() function, which seems to be enough as
register is cleared prior CPLD triggers another reset.
But board_early_init_f() is not called from SPL and therefore usage of SPL
can cause reboot loop.
To prevent reboot loop when using SPL, call board_early_init_f() function
in SPL too. For accessing CPLD memory space it is needed to have CPLD entry
in TLB.
With this change it is possible to trigger board reset via CPLD's system
reset register on P2020 RDB board.
Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Sean Anderson [Tue, 30 Aug 2022 21:01:07 +0000 (17:01 -0400)]
ddr: fsl: Make bank_addr_bits reflect actual bits
In both the Freescale DDR controller and the SPD spec, bank address bits
are stored as the number of bank address bits minus 2. For example, if a
chip had 8 banks (3 total bank address bits), the value of
bank_addr_bits would be 1. This is rather surprising for users
configuring their memory manually, since they can't set bank_addr_bits
to the actual number of bank address bits. Rectify this.
There is at least one example of this kind of mistake already, in
board/freescale/t102xrdb/ddr.c. The documented MT40A512M8HX has two bank
address bits, but bank_addr_bits was set to 2, implying 4 bank address
bits. Such a value is reserved in BA_BITS_CS, but I suspect the
controller simply ignores the top bit, making this kind of mistake
harmless, if misleading.
Fixes: e8a7f1c32b5 ("powerpc/t1023rdb: Add T1023 RDB board support") Signed-off-by: Sean Anderson <sean.anderson@seco.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Sean Anderson [Tue, 30 Aug 2022 20:54:39 +0000 (16:54 -0400)]
ddr: fsl: Reduce the size of interactive options
The interactive mode uses large several tables of options which can be
configured. However, much of the contents of these tables are
repetetive. For example, no struct is larger than half a kilobyte, so
the offset only takes up 9 bits. Similarly, the size is only ever 4 or
8, and printhex is a boolean. Reduce the size of these fields. This
reduces the size of the options tables by around 10 KiB. However, the
largest contributor to the size of the options tables is the use of a
pointer for the strings. A better approach would be to use a separate
array of strings, and store an integer index in the options tables.
However, this would require a large re-architecting of this file.
Signed-off-by: Sean Anderson <sean.anderson@seco.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Michael Walle [Tue, 23 Aug 2022 09:30:17 +0000 (11:30 +0200)]
board: sl28: support dynamic prompts
Depending on the boot source, set different CLI prompts. This will help
the user to figure out in which mode the bootloader was started. There
are two special modes: failsafe and SDHC boot.
Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Michael Walle [Tue, 23 Aug 2022 09:30:14 +0000 (11:30 +0200)]
armv8: layerscape: spl: mark OCRAM as non-secure
By default the OCRAM is marked as secure. While the SPL runs in EL3 and
thus can access it, DMA devices cannot. Mark the whole OCRAM as
non-secure.
This will fix MMC and SD card boot on LS1028A when using SPL instead of
TF-A.
Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Peng Fan <peng.fan@nxp.com>
rockchip: allow to build SPI images even without HAS_ROM option
This prepares for the creation of a u-boot-rockchip-spi.bin image
similar to u-boot-rockchip.bin to the exception it's destined for
SPI-NOR flashes instead of MMC storage medium.
Cc: Quentin Schulz <foss+uboot@0leil.net> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
rockchip: remove binman temporary files when cleaning
Binman mkimage entry generates temporary files so let's remove them
when calling `make clean`.
Fixes: 9b312e26fc77 ("rockchip: Enable building a SPI ROM image on jerry") Cc: Quentin Schulz <foss+uboot@0leil.net> Reported-by: Johan Jonker <jbx6244@gmail.com> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
binman: add support for skipping file concatenation for mkimage
Some image types handled by mkimage require the datafiles to be passed
independently (-d data1:data2) for specific handling of each. A
concatenation of datafiles prior to passing them to mkimage wouldn't
work.
That is the case for rkspi for example which requires page alignment
and only writing 2KB every 4KB.
This adds the ability to tell binman to pass the datafiles without
prior concatenation to mkimage, by adding the multiple-data-files
boolean property to the mkimage node.
rockchip: rk3399: sync spl_boot_devices_tbl and boot_devices node paths
While technically not a bug, let's have some consistency in paths
returned by u-boot,spl-boot-order look-up and the one saved in
u-boot,spl-boot-device by syncing spl_boot_devices_tbl and boot_devices
node paths.
rockchip: rk3399: fix incorrect boot-device in u-boot, spl-boot-device
On RK3399, mmc0 is eMMC and mmc1 is SD card, c.f. console:
MMC: mmc@fe320000: 1, mmc@fe330000: 0
In arch/arm/mach-rockchip/spl-boot-order.c:board_boot_order, the
boot_device (BOOT_DEVICE_*) value is gotten from spl_node_to_boot_device
function. Said function returns BOOT_DEVICE_MMC1 for mmc0 (eMMC) and
BOOT_DEVICE_MMC2 for mmc1 (SD card).
Since the SD card controller is at mmc@fe320000, it should be associated
with BOOT_DEVICE_MMC2 and not BOOT_DEVICE_MMC1. Same applies to eMMC.
John Keeping [Thu, 14 Jul 2022 14:18:37 +0000 (15:18 +0100)]
rockchip: rk3308: fix same-as-spl boot order
Rockchip SoCs need the boot_devices array defined in order to map the
bootloader's value to a U-Boot device. Implement this for rk3308.
Signed-off-by: John Keeping <john@metanate.com> Reviewed-by: Philipp Tomsich <philipp.tomsich@vrull.eu> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
John Keeping [Thu, 14 Jul 2022 14:09:12 +0000 (15:09 +0100)]
rockchip: rk3308: fix rockchip_dnl_key_pressed() on roc-cc
Commit 6aa4fe3912 ("dm: core: Rename and fix uclass_get_by_name_len()")
changed uclass_get_device_by_name() to an exact match when previously it
behaved as a prefix match.
The roc-cc code relied on this prefix match by only specifying part of
the device name. Fix this by using the full name including the address.
Signed-off-by: John Keeping <john@metanate.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
rockchip: rk3399: boot_devices: fix eMMC node name
When idbloader.img is flashed on the eMMC, the SPL still tries to load
from SPI-NOR first.
This is due to an incorrect look-up in the Device Tree. Since commit 822556a93459 ("arm: dts: sync the Rockhip 3399 SoCs from Linux"), the
node name (but not label) changed from sdhci@fe330000 to mmc@fe330000
meaning U-Boot SPL is not looking for the correct node name anymore and
fails to find the "same-as-spl" node when eMMC is the medium from which
the SPL booted.
Lee Jones [Thu, 11 Aug 2022 07:58:48 +0000 (08:58 +0100)]
ram: rk3399: Conduct memory training at 400MHz
Currently the default initialisation frequency is 50MHz. Although
this does appear to be suitable for some LPDDR4 RAM chips, training at
this low frequency has been seen to cause Column errors, leading to
Capacity check errors on others.
Here we force RAM initialisation to happen at 400MHz before ramping up
to the final value running value of 800MHz after everything has been
successfully configured.
Link: https://lore.kernel.org/u-boot/Yo4v3jUeHXTovjOH@google.com/ Suggested-by: YouMin Chen <cym@rock-chips.com> Signed-off-by: Lee Jones <lee@kernel.org> Tested-by: Xavier Drudis Ferran <xdrudis@tinet.cat> Reviewed-by: Kever Yang <kever.yang@rock-chips.com> Tested-by: Michal Suchánek <msuchanek@suse.de>
Johan Jonker [Mon, 2 May 2022 09:42:22 +0000 (11:42 +0200)]
arm: dts: rockchip: rk3288: rename mmc nodenames
The boot_devices constants for rk3288 were changed to match the
binding, but the dtsi file was not synced.
Fix by renaming the rk3288 mmc node names.
Also correct the clock name for "ciu-drive".
Signed-off-by: Johan Jonker <jbx6244@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Simon Glass [Wed, 31 Aug 2022 03:05:38 +0000 (21:05 -0600)]
tpm: Allow committing non-volatile data
Add an option to tell the TPM to commit non-volatile data immediately it
is changed, rather than waiting until later. This is needed in some
situations, since if the device reboots it may not write the data.
Add definitions for the rest of the Cr50 commands while we are here.
Simon Glass [Wed, 31 Aug 2022 03:05:35 +0000 (21:05 -0600)]
tpm: sandbox: Allow init of TPM in a different phase
At present the emulator assumes that the TPM is inited in the same phase
where it is used. But in fact SPL may init the TPM, so we don't want to
complain when U-Boot proper later uses it. Remove this check.
It might be best to save this information into the device state for the
TPM, so that we can make sure the TPM was inited at some point. For now,
this seems good enough.
Simon Glass [Wed, 31 Aug 2022 03:05:32 +0000 (21:05 -0600)]
tpm: Require a digest source when extending the PCR
This feature is used for measured boot, so we can add a log entry to the
TCPA with some information about where the digest comes from. It is not
currently supported in the TPM drivers, but add it to the API so that
code which expects it can signal its request.
Tom Rini [Sat, 3 Sep 2022 11:44:22 +0000 (07:44 -0400)]
Merge tag 'efi-2022-10-rc4-2' of https://source.denx.de/u-boot/custodians/u-boot-efi
Pull request of efi-2022-10-rc4-2
UEFI:
* provide EFI Conformance Profile Table
* fix display of NVMe EUI-64
* fixes for Simple Text Input Ex Protocol
* fix exception unit-test on non-x86 sandbox
Jose Marinho [Fri, 17 Dec 2021 12:55:05 +0000 (12:55 +0000)]
efi: ECPT add EBBRv2.0 conformance profile
Display the EBBRv2.0 conformance in the ECPT table.
The EBBRv2.0 conformance profile is set in the ECPT if
CONFIG_EFI_EBBR_2_0_CONFORMANCE=y.
Signed-off-by: Jose Marinho <jose.marinho@arm.com>
Add dependencies for CONFIG_EFI_EBBR_2_0_CONFORMANCE.
Enable the setting by default. Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Jose Marinho [Thu, 23 Dec 2021 14:51:07 +0000 (14:51 +0000)]
efi: Create ECPT table
The ECPT table will be included in the UEFI specification 2.9+.
The ECPT table was introduced in UEFI following the code-first path. The
acceptance ticket can be viewed at:
https://bugzilla.tianocore.org/show_bug.cgi?id=3591
The Conformance Profiles table is a UEFI configuration table that contains
GUID of the UEFI profiles that the UEFI implementation conforms with.
The ECPT table is created when CONFIG_EFI_ECPT=y.
The config is set by default.
Signed-off-by: Jose Marinho <jose.marinho@arm.com> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
efi_selftest: on sandbox use host specific assembly
The selftest checking the handling of exceptions in UEFI binaries is using
assembly to provide an undefined instruction. On the sandbox the correct
form of the instruction depends on the host architecture.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
efi_loader: compliance Simple Text Input Ex Protocol
We cannot expect the buffers passed to the input protocols to be zero
filled. If only modifier keys are pressed, we have to return EFI_NOT_READY
but we still have to fill the key structure.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
qianfan Zhao [Mon, 22 Aug 2022 01:18:31 +0000 (09:18 +0800)]
drivers: usb: fastboot: Fix full-speed usb descriptor
The host will report such error message if the fastboot device work in
full-speed mode: "Duplicate descriptor for config 1 interface 0
altsetting 0, skipping"
Fastboot device ack both full and high speed interface descriptors when
work in full-speed mode, that's will cause this issue.
Fix it.
Signed-off-by: qianfan Zhao <qianfanguijin@163.com> Reviewed-by: John Keeping <john@metanate.com>
The compatible values used for device nodes representing Renesas Reduced
Pin Count Interfaces were based on preliminary versions of the Device
Tree Bindings.
Correct them in both DTSi files and drivers, to match the final DT
Bindings.
Note that there are no DT bindings for RPC-IF on RZ/A1 yet, hence the
most logical SoC-specific value is used, without specifying a
family-specific value.
ARM: renesas: Propagate RPC-IF enablement to subsequent software
As the Renesas Reduced Pin Count Interface may be locked by TF-A, it is
disabled by default[1]. When unlocked, TF-A passes a DT fragment to
enable it, which is applied to the U-Boot DT[2].
Unlike the memory layout, the RPC-IF enablement is not propagated to
subsequent software. Hence e.g. Linux cannot know if the RPC-IF is
locked or not, and will lock-up when trying to access the RPC-IF when
locked.
Fix this by checking if the RPC-IF is enabled in the TF-A DT fragment, and
setting the status of the RPC-IF device node in the target DT, if
present, to "okay". Do this only when a "flash" subnode is found, to
avoid errors in subsequent software when the RPC-IF is not intended to
be used.
Note that this requires the status of the RPC-IF node to be set to
"disabled" in the target DT, just like in the U-Boot DT.
[1] commit 3d5f45c95c9db73d ("ARM: dts: rmobile: Disable RPC HF by
default")
[2] commit 361377dbdbc9f0f5 ("ARM: rmobile: Merge prior-stage firmware
DT fragment into U-Boot DT on Gen3")
According to the Generic Names Recommendation in the Devicetree
Specification Release v0.3, and the DT Bindings for the Renesas Reduced
Pin Count Interface, the node name for a Renesas RPC-IF device should be
"spi". Especially on R-Car Gen3 and RZ/G2, the node name matters, as
the node is enabled by passing a DT fragment from TF-A to U-Boot, and
from U-Boot to subsequent software.
Fix this by renaming the device nodes from "rpc" to "spi".
dt/bindings: Add bindings for FWU Metadata mtd storage
Add bindings needed for accessing the FWU metadata regions.
These include the compatible string which point to the access
method, the actual device which stores the FWU metadata and
the offsets for both metadata regions.
The current patch adds basic bindings needed for accessing the
metadata structure on non-GPT mtd regions.
Tom Rini [Mon, 29 Aug 2022 16:59:35 +0000 (12:59 -0400)]
github: Update PR template for new "Patches" content
The old "Patches" wiki page is not available anymore. Now that the
content has been integrated with the submitting_patches document,
reference that instead.
Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Tom Rini [Mon, 29 Aug 2022 16:59:34 +0000 (12:59 -0400)]
doc: process, sending_patches: Update and correct the old "Patches" content
- Use gender-neutral language to refer to the user, consistently.
- Reference the checkpatch document.
- Move the section on commit message tags to the process document and
reference this in sending_patches.rst.
- Reword the custodian workflow process section to refer to this new
section, integrate some of the wording from there in this new section.
- Update the comment about GPLv2 applying to August 2022, to be clear
this still is correct.
- Reword the section about MAKEALL to talk about local build testing and
link to the CI document.
- Reference the system_configuration document for the note about
modifying existing code.
- Reword the patchwork flow section.
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Tom Rini <trini@konsulko.com>
Tom Rini [Mon, 29 Aug 2022 16:59:33 +0000 (12:59 -0400)]
doc: sending_patches.rst: Incorporate the old "Patches" wiki content
Import as-is much of the old "Patches" wiki page to the current
sending_patches.rst file. This means we need to move patman to being
included in the higher level ToC and add a reference for "Custodians" in
the process document. A very minimal amount of content changing and
rewording is done here as part of the import, in order to make the
conversion easier.
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Patrice Chotard [Tue, 30 Aug 2022 14:56:28 +0000 (16:56 +0200)]
doc: Add gpio status output fields description
Add gpio status output fields description and one output example.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Tweak the formatting. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Only probed block devices are available in the UEFI sub-system. Multiple
block devices may be involved in the boot process. So we have to make sure
that all block devices are probed. Another reason is that we store UEFI
variables on the ESP which may be on any block device.
Fixes: a9bf024b2933 ("efi_loader: disk: a helper function to create efi_disk objects from udevice") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Sean Anderson [Tue, 30 Aug 2022 20:32:27 +0000 (16:32 -0400)]
arm: smh: Fix uninitialized parameters with newer GCCs
Newer versions of GCC won't initialize parts of structures which don't
appear to be used. This results in uninitialized semihosting parameters
passed via R1. Fix this by marking the inline assembly as clobbering
memory.
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
Mark Kettenis [Mon, 29 Aug 2022 11:34:01 +0000 (13:34 +0200)]
tools: mkimage: fix build with recent LibreSSL
LibreSSL 3.5.0 and later (also shipped as part of OpenBSD 7.1 and
and later) have an opaque RSA object and do provide the
RSA_get0_* functions that OpenSSL provides.
Fixes: 2ecc354b8e46 ("tools: mkimage: fix build with LibreSSL") Signed-off-by: Mark Kettenis <kettenis@openbsd.org> Reviewed-by: Jonathan Gray <jsg@jsg.id.au>
Daniel Golle [Sat, 27 Aug 2022 03:17:28 +0000 (04:17 +0100)]
image-fit: don't set compression if it can't be read
fit_image_get_comp() should not set value -1 in case it can't read
the compression node. Instead, leave the value untouched in that case
as it can be absent and a default value previously defined by the
caller of fit_image_get_comp() should be used.
As a result the warning message
WARNING: 'compression' nodes for ramdisks are deprecated, please fix your .its file!
no longer shows if the compression node is actually absent.
Signed-off-by: Daniel Golle <daniel@makrotopia.org> Reviewed-by: Simon Glass <sjg@chromium.org>
Marek Vasut [Fri, 26 Aug 2022 21:15:56 +0000 (23:15 +0200)]
i2c: fix stack buffer overflow vulnerability in i2c md command
This reinstates fix from commit 8f8c04bf1ebb ("i2c: fix stack buffer
overflow vulnerability in i2c md command") without the changes unrelated
to the actual fix. Avoid the underflow by setting only nbytes and
linebytes as unsigned integers.
Signed-off-by: Marek Vasut <marex@denx.de> Cc: Heiko Schocher <hs@denx.de> Cc: Nicolas Iooss <nicolas.iooss+uboot@ledger.fr> Cc: Simon Glass <sjg@chromium.org> Cc: Tim Harvey <tharvey@gateworks.com> Acked-by: Tim Harvey <tharvey@gateworks.com>
The commit is largely wrong and breaks most of i2c command functionality.
The problem described in the aforementioned commit commit message is valid,
however the commit itself does many more changes unrelated to fixing that
one problem it describes. Those extra changes, namely the handling of i2c
device address length as unsigned instead of signed integer, breaks the
expectation that address length may be negative value. The negative value
is used by DM to indicate that address length of device does not change.
Signed-off-by: Marek Vasut <marex@denx.de> Cc: Heiko Schocher <hs@denx.de> Cc: Nicolas Iooss <nicolas.iooss+uboot@ledger.fr> Cc: Simon Glass <sjg@chromium.org> Cc: Tim Harvey <tharvey@gateworks.com> Reviewed-by: Simon Glass <sjg@chromium.org>
There are three different kinds of EEPROM possibly present on boards.
1. 1byte address. For those we should avoid 2byte address in order
not to rewrite the data. Second byte of the address can potentially
be interpreted as the data to write.
2. 2byte address with defined behaviour. When we try to use 1byte
address they just return "FF FF FF FF ... FF"
3. 2byte address with undefined behaviour (for instance, 24LC32AI).
When we try to use 1byte address, then their internal read
pointer is changed to some value. Subsequential reads may be
broken.
To gracefully handle both case #1 and case #3 we read all required
data from EEPROM at once (about 80 bytes). So either all the data is
valid or we fallback to 2byte address.
common/console.c: prevent pre-console buffer contents from being added to itself
I do not have any non-serial output devices, so a
print_pre_console_buffer(PRE_CONSOLE_FLUSHPOINT2_EVERYTHING_BUT_SERIAL)
does nothing for me.
However, I was manually inspected the pre-console buffer using md.b,
and I noticed that the early part of it was repeated. The reason is
that the first call of print_pre_console_buffer(), from
console_init_f(), ends up invoking puts() with the contents of the
buffer at that point, and puts() at that point ends up in the else
branch of
if (gd->flags & GD_FLG_DEVINIT) {
/* Send to the standard output */
fputs(stdout, s);
} else {
/* Send directly to the handler */
pre_console_puts(s);
serial_puts(s);
}
so indeed the contents is added again.
That can be somewhat confusing (both when reading the buffer manually,
but also if it did actually come out on some device). So disable all
use of the pre-console buffer while print_pre_console_buffer() is
emitting it.
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Reviewed-by: Simon Glass <sjg@chromium.org>
Pali Rohár [Sun, 7 Aug 2022 19:04:22 +0000 (21:04 +0200)]
distroboot: ubifs: Add support for specifying UBI header offset
Some UBI partitions may use non-standard UBI header offset. For attaching
these UBI partitions it is required to pass second argument with offset to
"ubi part" command.
Therefore extend distroboot to allow specifying additional optional 6th
argument with UBI header offset. This offset is set in new distroboot
variable ${bootubioff} which may be used by distroboot script to e.g.
properly pass this value to linux kernel command line for proper mounting
of rootfs by kernel. This variable is set to empty string (cleared) when
UBI header offset is not specified into distroboot BOOT_TARGET_DEVICES
macro.
Usage of helper macro BOOTENV_DEV_UBIFS_BOOTUBIOFF in this change is there
as a type check. It ensures that in BOOT_TARGET_DEVICES macro was specified
UBIFS func with either 5 or 6 arguments. If not then cpp throws compile
error.
Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Tom Rini <trini@konsulko.com>
Tests should be in order of the test-file numbers. Sort the tests
according to the test-file numbers and rework the test-file numbers to
eliminate duplicate numbers.
Signed-off-by: Stefan Herbrechtsmeier <stefan.herbrechtsmeier@weidmueller.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Hector Martin [Sun, 31 Jul 2022 06:31:31 +0000 (15:31 +0900)]
nvme: Do a clean NVMe shutdown
The brute-force controller disable method can end up racing controller
initialization and causing a crash when we shut down Apple ANS2 NVMe
controllers. Do a proper controlled shutdown, which does block until
things are quiesced properly. This is nicer in general for all
controllers.
Signed-off-by: Hector Martin <marcan@marcan.st> Tested-by: Mark Kettenis <kettenis@openbsd.org> (firefly-rk3399)
PCIe config space has address range 0-4095. So do not allow reading from
addresses outside of this range. Lot of U-Boot drivers do not expect that
passed value is not in this range. PCI DM read function is extended to
fill read value to all ones or zeros when it fails as U-Boot callers
ignores return value.
Calling U-Boot command 'pci display.b 0.0.0 0 0x2000' now stops printing
config space at the end (before 0x1000 address).
Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Stefan Roese <sr@denx.de>
- kirkwood: pogo_v4 & nsa310s: Add distro boot (Tony)
- kirkwood: add DM timer support and use it on lsxl boards (Michael)
- kirkwood: convert the Buffalo Linkstation LS-CHLv2 and XHL boards
to DM (Michael)
- mvebu: turris_mox/omnia: misc improments (Pali)
- mvebu: mbus: Fix mbus driver to work also after U-Boot relocation (Pali)
Michael Walle [Wed, 17 Aug 2022 19:38:08 +0000 (21:38 +0200)]
board: lsxl: disable eth0
The board has only one network interface. The linux kernel will
gracefully skip a the ethernet interface if no connected PHY could be
probed. u-boot on the other hand will throw an error message. The kernel
device tree is about to be fixed. For now, just disable the ethernet
interface in our -u-boot.dtsi.
Signed-off-by: Michael Walle <michael@walle.cc> Reviewed-by: Stefan Roese <sr@denx.de>
projects / u-boot.git / log