Johan Jonker [Sat, 30 Nov 2024 21:18:57 +0000 (22:18 +0100)]
doc: remove redundant Rockchip bindings
Most Rockchip device tree related bindings are converted to YAML
and available in the U-boot /dts/upstream/Bindings/ directory.
Remove all redundant U-boot entries.
Sam Protsenko [Wed, 11 Dec 2024 02:17:02 +0000 (20:17 -0600)]
boot: fdt: Handle already reserved memory in boot_fdt_reserve_region()
The boot_fdt_add_mem_rsv_regions() function can be called twice, e.g.
first time during the board init (as a part of LMB init), and then when
booting the OS with 'booti' command:
That consequently leads to the attempt of reserving the same memory
areas (described in the 'reserved-memory' dts node) in LMB. The
lmb_add_region_flags() returns -EEXIST error code in such cases, but
boot_fdt_reserve_region() handles all negative error codes as a failure
to reserve fdt memory region, printing corresponding error messages,
which are essentially harmless, but misleading. For example, this is the
output of 'booti' command on E850-96 board:
The mentioned false positive error messages are observed starting with
commit 1d9aa4a283da ("lmb: Fix the allocation of overlapping memory
areas with !LMB_NONE"), which removes the check for the already added
memory regions in lmb_add_region_flags(), making it return -1 for
!LMB_NONE cases. Another commit 827dee587b75 ("fdt: lmb: add reserved
regions as no-overwrite") changes flags used for reserving memory in
boot_fdt_add_mem_rsv_regions() from LMB_NONE to LMB_NOOVERWRITE. So
together with the patch mentioned earlier, it makes
lmb_add_region_flags() return -1 when called from
boot_fdt_reserve_region().
Since then, the different patch was implemented, returning -EEXIST error
code in described cases, which is:
lmb: Return -EEXIST in lmb_add_region_flags() if region already added
Handle -EEXIST error code as a normal (successful) case in
lmb_reserve_flags() and don't print any messages.
Fixes: 1d9aa4a283da ("lmb: Fix the allocation of overlapping memory areas with !LMB_NONE") Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Tested-by: Michal Simek <michal.simek@amd.com>
Sam Protsenko [Wed, 11 Dec 2024 02:17:01 +0000 (20:17 -0600)]
lmb: Return -EEXIST in lmb_add_region_flags() if region already added
An attempt to add the already added LMB region using
lmb_add_region_flags() ends up in lmb_addrs_overlap() check, which
eventually leads to either returning 0 if 'flags' is LMB_NONE, or -1
otherwise. It makes it impossible for the user of this function to catch
the case when the region is already added and differentiate it from
regular errors. That in turn may lead to incorrect error handling in the
caller code, like reporting misleading errors or interrupting the normal
code path where it could be treated as the normal case. An example is
boot_fdt_reserve_region() function, which might be called twice (e.g.
during board startup in initr_lmb(), and then during 'booti' command
booting the OS), thus trying to reserve exactly the same memory regions
described in the device tree twice, which produces an error message on
second call.
Return -EEXIST error code in case when the added region exists and it's
not LMB_NONE; for LMB_NONE return 0, to conform to unit tests
(specifically test_alloc_addr() in test/lib/lmb.c) and the preferred
behavior described in commit 1d9aa4a283da ("lmb: Fix the allocation of
overlapping memory areas with !LMB_NONE"). The change of
lmb_add_region_flags() return values is described in the table below:
Rework all affected functions and their documentation. Also fix the
corresponding unit test which checks reserving the same region with the
same flags to account for the changed return value.
No functional change is intended (by this patch itself).
Fixes: 1d9aa4a283da ("lmb: Fix the allocation of overlapping memory areas with !LMB_NONE") Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Tested-by: Michal Simek <michal.simek@amd.com>
Peter Robinson [Fri, 11 Oct 2024 17:09:11 +0000 (18:09 +0100)]
board: rpi: Pass CMA through from firmware DT
For a lot of usecases, such as display, camera, media
the Raspberry Pi needs a lot more CMA than distros
configure as default so we should pass this parameter
through so things work as expected. Fix a spelling
mistake while we're at it.
Signed-off-by: Peter Robinson <pbrobinson@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Acked-by: Matthias Brugger <mbrugger@suse.com>
Marek Vasut [Thu, 28 Nov 2024 04:11:19 +0000 (05:11 +0100)]
arm64: renesas: Disable AVB1 and AVB2 on R8A779G0 V4H White Hawk board
The U-Boot is currently not capable of handling ethernet-phy-ieee802.3-c45
PHYs correctly, and also does not handle MDIO bus wide reset-gpios property.
Until proper C45 PHY support lands in U-Boot, disable AVB1/AVB2 interfaces.
This only disables the two MACs with 88Q2110/88Q2112 100/1000BASE-T1 PHYs
on ethenet sub-board, the main board AVB0 ethernet is unaffected.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Paul Barker [Wed, 20 Nov 2024 09:48:29 +0000 (09:48 +0000)]
pinctrl: rzg2l: Support Ethernet TXC output enable
On the RZ/G2L SoC family, the direction of the Ethernet TXC/TX_CLK
signal is selectable to support an Ethernet PHY operating in either MII
or RGMII mode. By default, the signal is configured as an input and MII
mode is supported. The ETH_MODE register can be modified to configure
this signal as an output to support RGMII mode.
As this signal is be default an input, and can optionally be switched to
an output, it maps neatly onto an `output-enable` property in the device
tree.
Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com> Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Paul Barker [Wed, 20 Nov 2024 09:48:28 +0000 (09:48 +0000)]
pinctrl: rzg2l: Support 2.5V PVDD for Ethernet interfaces
The Ethenet interfaces on the Renesas RZ/G2L SoC family can operate at
multiple power supply voltages: 3.3V (default value), 2.5V and 1.8V.
rzg2l_pinconf_set() is extended to support the 2.5V setting, with a
check to ensure this is only used on Ethernet interfaces as it is not
supported on the SD & QSPI interfaces.
While we're modifying rzg2l_pinconf_set(), drop the unnecessary default
value for pwr_reg as it is set in every branch of the following if
condition.
Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com> Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Paul Barker [Tue, 19 Nov 2024 19:36:26 +0000 (19:36 +0000)]
clk: rzg2l: Ignore enable for core clocks
In the RZ/G2L family, core clocks are always on and can't be disabled.
However, drivers which are shared with other SoCs may call clk_enable()
or clk_enable_bulk() for a clock referenced in the device tree which
happens to be a core clock on the RZ/G2L. To avoid the need for
conditionals in these drivers, simply ignore attempts to enable a core
clock.
Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com> Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
When MbedTLS TLS features were added MBEDTLS_HAVE_TIME was defined as part
of enabling https:// support. However that pointed to the wrong function
which could crash if it received a NULL pointer.
Looking closer that function is not really needed, as it only seems to
increase the RNG entropy by using 4b of the current time and date.
The reason that was enabled is that lwIP was unconditionally requiring it,
although it's configurable and can be turned off.
Since lwIP doesn't use that field anywhere else, make it conditional and
disable it from our config.
Vincent Stehlé [Fri, 6 Dec 2024 07:58:53 +0000 (08:58 +0100)]
arm: qemu: fix update_info declaration
Add a missing comma in the update_info structure declaration.
This fixes the following build error when building with
EFI_RUNTIME_UPDATE_CAPSULE or EFI_CAPSULE_ON_DISK:
board/emulation/qemu-arm/qemu-arm.c:52:9: error: request for member ‘images’ in something not a structure or union
Fixes: cccea18813c4 ("efi_loader: add the number of image entries in efi_capsule_update_info") Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com> Cc: Masahisa Kojima <masahisa.kojima@linaro.org> Cc: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi> Cc: Tom Rini <trini@konsulko.com>
Sughosh Ganu [Mon, 2 Dec 2024 07:06:24 +0000 (12:36 +0530)]
lmb: prohibit allocations above ram_top even from same bank
There are platforms which set the value of ram_top based on certain
restrictions that the platform might have in accessing memory above
ram_top, even when the memory region is in the same DRAM bank. So,
even though the LMB allocator works as expected, when trying to
allocate memory above ram_top, prohibit this by marking all memory
above ram_top as reserved, even if the said memory region is from the
same bank.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org> Tested-by: Andreas Schwab <schwab@suse.de>
Two fixes for the EFI subsystem coming via the TPM tree as agreed by Heinrich
The LMB patch fixes a failure in SystemReady testing. Nothing bad happens
without the patch in the device operation, but the return values are wrong
and SCT tests fail for MemoryAllocationServicesTest category.
The second is a shielding the device against mistakes in the definition of
struct fields needed by the capsule update mechanism. Instead of crashing,
print a humna readable message of what's wrong.
lmb: Fix the allocation of overlapping memory areas with !LMB_NONE
At the moment the LMB allocator will return 'success' immediately on two
consecutive allocations if the second one is smaller and the flags match
without resizing the reserved area.
This is problematic for two reasons, first of all the new updated
allocation won't update the size and we end up holding more memory than
needed, but most importantly it breaks the EFI SCT tests since EFI
now allocates via LMB.
More specifically when EFI requests a specific address twice with the
EFI_ALLOCATE_ADDRESS flag set, the first allocation will succeed and
update the EFI memory map. Due to the LMB behavior the second allocation
will also succeed but the address ranges are already in the EFI memory
map due the first allocation. EFI will then fail to update the memory map,
returning EFI_OUT_OF_RESOURCES instead of EFI_NOT_FOUND which break EFI
conformance.
So let's remove the fast check with is problematic anyway and leave LMB
resize and calculate address properly. LMB will now
- try to resize the reservations for LMB_NONE
- return -1 if the memory is not LMB_NONE and already reserved
The LMB code needs some cleanup in that part, but since we are close to
2025.01 do the easy fix and plan to refactor it later.
Also update the dm tests with the new behavior.
Fixes: commit 22f2c9ed9f53 ("efi: memory: use the lmb API's for allocating and freeing memory") Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
efi_loader: Check for a valid fw_name before auto generating GUIDs
The gen_v5_guid() is a void and does no error checking with pointers
being available etc. Instead it expects all things to be in place to
generate GUIDs. If a board capsule definition is buggy and does not
define the firmware names when enabling capsule updates, the board will
crash trying to bring up the EFI subsystem.
Check for a valid firmware name before generating GUIDs.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Evgeny Bachinin [Mon, 25 Nov 2024 09:15:07 +0000 (12:15 +0300)]
common: relocate fdt_blob in global_data for FDTSRC_EMBED case
Patch resolves two kind of bugs, one of which is vulnerability related
to KASLR.
=== Issue briefly ===
Working with FDT (via non-relocated gd::fdt_blob) from inside bootm
command may lead to the reading the garbage instead of FDT nodes. And
this can result in various side-effects depending on DTS nodes, being
parsed during bootm.
But below is my specific story how I faced with this issue due to
MESON_RNG probing failure.
=== Bugs description ===
1) Bug is revealed on:
* configuration below
* U-boot 2024.10 - f919c3a889f ("Prepare v2024.10")
It seems, the following patch is a trigger: ea955eea4f ("fdt: automatically add /chosen/kaslr-seed if DM_RNG is enabled")
Generally, CONFIG_OF_EMBED=y & CONFIG_RNG_MESON=y are the most
valuable ones for reproducing the issue.
```
CONFIG_ARCH_FIXUP_FDT_MEMORY=y
CONFIG_CMD_FDT=y
CONFIG_DEFAULT_FDT_FILE=""
CONFIG_FDT_64BIT=y
CONFIG_OF_BOARD_SETUP=y
CONFIG_OF_CONTROL=y
CONFIG_OF_EMBED=y
CONFIG_OF_LIBFDT_ASSUME_MASK=0x0
CONFIG_OF_LIBFDT_OVERLAY=y
CONFIG_OF_LIBFDT=y
CONFIG_OF_LIST="meson-axg-our-device-name"
CONFIG_OF_REAL=y
CONFIG_OF_TRANSLATE=y
CONFIG_SUPPORT_OF_CONTROL=y
CONFIG_SYS_FDT_PAD=0x3000
CONFIG_TOOLS_OF_LIBFDT=y
CONFIG_DM_RNG=y
CONFIG_RNG_MESON=y
```
2) Due to CONFIG_OF_EMBED, the DTS is embedded into U-boot ELF and
accessible via __dtb_dt_begin symbol.
On early boot stage (board_f.c) the fdtdec_setup() is called only
once before U-boot's relocation into top of RAM. fdtdec_setup()
initializes gd::fdt_blob for FDTSRC_EMBED case:
```
gd->fdt_blob = dtb_dt_embedded();
gd->fdt_src = FDTSRC_EMBED;
```
3) Then reloc_fdt() is called in board_f.c
But due to CONFIG_OF_EMBED=y the reloc_fdt() does not update
gd::fdt_blob value (strictly speaking, it is impossible for
CONFIG_OF_EMBED=y, because U-boot ELF has not been relocated yet
at this moment).
As a result after relocation we get fdt_blob, pointing to DTS address
before relocation:
```
# bdinfo
<...>
relocaddr = 0x000000000fedf000
reloc off = 0x000000000eedf000
<...>
fdt_blob = 0x010ce6c0 << points to __dtb_dt_begin before relocation
new_fdt = 0x0000000000000000 << empty erroneously
fdt_size = 0x0000000000000000 << zero erroneously
```
4) During bootm command (according to our ITS-config file) the Linux
is loaded into 0x01080000 (which is very close to fdt_blob addr
0x010ce6c0).
```
## Loading kernel from FIT Image at 04000000 ...
Trying 'kernel' kernel subimage
<...>
Load Address: 0x01080000
```
So Linux image overwrites the gd::fdt_blob memory location
in RAM (0x010ce6c0).
5) Issue:
Hence any manipulation with DTS (say, via FDT API) inside
implementation of bootm command leads to accessing the fdt_blob area
with garbage, that can lead to two situations:
Almost the same as in (5.1), but 2 situations happen (depending on
the value of garbage):
* call to fdt_offset_ptr_() :: fdt_off_dt_struct(fdt)
returns not so big garbage, leading to tagp, being inside RAM.
* or calculations of absoffset inside fdt_offset_ptr() leads to
failure of the one of if() conditions with NULL as retval.
Result is fdt_next_tag() interprets the tagp as FDT_END. And we are
returning from our callstack via functions' error paths, leading to
"No RNG device" and "KASLR disabled due to lack of seed":
```
fdt_kaslrseed()
uclass_get_device()
<...>
device_probe()
device_of_to_plat()
meson_rng_of_to_plat()
clk_get_by_name()
clk_get_by_name_nodev()
<...>
fdt_stringlist_search()
fdt_getprop()
fdt_get_property_namelen_()
fdt_first_property_offset()
fdt_check_node_offset_()
fdt_next_tag():
```
tagp = fdt_offset_ptr(fdt, offset, FDT_TAGSIZE);
```
fdt_next_tag() tagp:0000000001890677
fdt_next_tag() ram_top:0x10000000 (tagp is inside RAM)
uclass_get_device_tail():486 device_probe() ret:-22
No RNG device
Starting kernel ...
[ 0.000000] Linux version 6.9.12
[ 0.000000] KASLR disabled due to lack of seed
```
Mark Kettenis [Tue, 26 Nov 2024 19:12:14 +0000 (20:12 +0100)]
Makefile: avoid non-standard sed expressions
The '?' that is used in the sed expression that determines MK_ARCH
is part of the extended regular expression syntax, but the default
behaviour of sed as specified by POSIX is to use only basic regular
expression syntax. Use the equivalent '\{0,1\}' instead as
suggested by the OpenBSD re_format(7) man page.
Fixes: 04b1d84221d5 ("Makefile: fix empty MK_ARCH when using ccache") Signed-off-by: Mark Kettenis <kettenis@openbsd.org> Reviewed-by: Marek Vasut <marex@denx.de> Tested-by: Quentin Schulz <quentin.schulz@cherry.de>
Jerome Forissier [Tue, 26 Nov 2024 14:45:06 +0000 (15:45 +0100)]
net: lwip: wget: fix legacy syntax
Commit 356011f7ac25 ("lwip: fix code style issues") has inadvertently
broken the support for the legacy syntax:
=> wget 192.168.0.16:test.bin
invalid uri, no file path
Invalid URL. Use http(s)://
The reason is two calls to strncpy() were replaced by strlcpy() without
paying attention to the fact that they are not equivalent in the present
case. Since we are using a character counter (n) and since we do not
depend on having a properly null-terminated string at each step in the
parsing, strlcpy() is not justified and strncpy() is the right tool for
the job. So use it again.
Reported-by: Tom Rini <trini@konsulko.com> Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Ilias Apalodimas [Fri, 29 Nov 2024 17:08:13 +0000 (19:08 +0200)]
Revert "efi_memory: do not add U-Boot memory to the memory map"
This reverts commit ("commit a68c9ac5d8af ("efi_memory: do not add
U-Boot memory to the memory map").
This code was removed when the EFI subsystem started using LMB calls for
the reservations. In hindsight it unearthed two problems.
The e820 code is adding u-boot memory as EfiReservedMemory while it
should look at what LMB added and decide instead of blindly overwriting
it. The reason this worked is that we marked that code properly late,
when the EFI came up. But now with the LMB changes, the EFI map gets
added first and the e820 code overwrites it.
The second problem is that we never mark SetVirtualAddressMap as runtime
code, which we should according to the spec. Until we fix this the
current hack can't go away, at least for architectures that *need* to
call SVAM.
More specifically x86 currently requires SVAM and sets the NX bit for
pages not marked as *_CODE. So unless we do that late, it will crash
trying to execute from non-executable memory. It's also worth noting
that x86 calls SVAM late in the boot, so this will work until someone
decides to overwrite/use BootServicesCode from the OS.
Notably arm64 disables it explicitly if the VA space is > 48bits, so
doesn't suffer from any of these problems.
This doesn't really deserve a fixes tag, since it brings back a hack to
remedy a situation that was wrong long before that commit, but in case
anyone hits the same bug ...
Simon sent the original revert in the link, but we need a proper
justification for it.
- Make DRAM coding GPIOs available before relocation on Data Modul
i.MX8M Mini/Plus eDM SBC because the DRAM configuration GPIO straps
must be accessible in SPL and before relocation because the GPIOs are
sampled both in U-Boot SPL as well as early on in U-Boot proper.
- Pick safe DRAM size on failure on Data Modul i.MX8M Mini/Plus eDM SBC
instead of failing with hang() or panic().
- Replace YModem with SDP on Data Modul i.MX8M Mini eDM SBC SPL since
SDP is much more flexible.
- Deduplicate Data Modul i.MX8M eDM SBC defconfigs.
- Perform plain boot in altbootcmd on Data Modul i.MX8M Mini/Plus eDM
SBC.
Jerome Forissier [Fri, 15 Nov 2024 16:45:14 +0000 (17:45 +0100)]
test/cmd/wget.c: move net_test_wget() to the cmd test suite
Since net_test_wget() is testing a command and is in test/cmd it should
be in the 'cmd' test suite, not 'lib'.
Saving and restoring the values of the environment variables that the
test manipulates is necessary to avoid a regression when running the
whole ut test suite. A minimal reproducer is:
Marek Vasut [Fri, 29 Nov 2024 00:35:43 +0000 (01:35 +0100)]
ARM: dts: imx: Enable PCIe and NVMe on Data Modul i.MX8M Mini eDM SBC
Enable PCIe/NVMe support on Data Modul i.MX8M Mini eDM SBC. Except for
the configuration options which are enabled, add slight adjustment
to board u-boot.dtsi, which is necessary as there is currently no
driver for the I2C PCIe clock generator. Since the generator is
strapped to be always on, it is possible to supplant the generator
functionality by fixed-clock.
Marek Vasut [Fri, 29 Nov 2024 02:41:47 +0000 (03:41 +0100)]
ARM: imx: Replace YModem with SDP on Data Modul i.MX8M Mini eDM SBC SPL
The YModem support in SPL was never really used on this device,
the SDP support is much more convenient on i.MX8M Mini based
hardware. Replace the YModem support with SDP support.
The SDP can be utilized by forcing the board into SDP boot mode
by grounding test point right next to silkscreen label U30, and
then by using mfgtools 'uuu -brun spl flash.bin' once the device
enumerates on host system USB bus. The SDP capable USB port is
available on the USB micro-B port on the base board.
Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Peng Fan <peng.fan@nxp.com>
Marek Vasut [Fri, 29 Nov 2024 00:13:56 +0000 (01:13 +0100)]
ARM: imx: Deduplicate Data Modul i.MX8M eDM SBC defconfigs
Deduplicate defconfigs for all Data Modul i.MX8M eDM SBC systems by factoring
out the common parts into generic imx8m_data_modul.config and including
those using the #include <configs/...> preprocessor macro in the current
set of board specific defconfigs. The preprocessor macro is applicable
to defconfigs as well.
This introduces no functional change, the resulting .config is almost
identical for all Data Modul i.MX8M eDM SBC systems, except for slight
alignment in DEBUG_UART and SYS_PBSIZE.
Marek Vasut [Fri, 29 Nov 2024 00:13:55 +0000 (01:13 +0100)]
ARM: imx: Perform plain boot in altbootcmd on Data Modul i.MX8M Mini/Plus eDM SBC
The current A/B switching preparatory altbootcmd is confusing
to users, replace it with plain 'run bootcmd' which can be
replaced by proper A/B switching altbootcmd when the matching
updater is added on top of the platform. By default, keep the
boot counter incrementing, but do not do any A/B partition
switching.
Marek Vasut [Fri, 29 Nov 2024 00:13:54 +0000 (01:13 +0100)]
ARM: dts: imx: Pick safe DRAM size on failure on Data Modul i.MX8M Mini/Plus eDM SBC
In case gpio_request_list_by_name_nodev() in board dmo_get_memcfg()
returns error code, pick a safe default DRAM configuration instead
of bailing out with some sort of hang() or panic(). The BIT(2)|BIT(0)
strap option is the lowest known option of 2 GiB , use that.
Marek Vasut [Fri, 29 Nov 2024 00:13:53 +0000 (01:13 +0100)]
ARM: dts: imx: Make DRAM coding GPIOs available before relocation on Data Modul i.MX8M Mini/Plus eDM SBC
The DRAM configuration GPIO straps must be accessible in SPL and before
relocation because the GPIOs are sampled both in U-Boot SPL as well as early
on in U-Boot proper. The already present bootph-pre-ram DT property made the
GPIO controllers available in SPL, but not early on in U-Boot proper, which
made gpio_request_list_by_name_nodev() in board dmo_get_memcfg() fail. Add
missing bootph-some-ram DT property to all GPIO controllers which are
referenced in dmo,ram-coding-gpios DT property to make those GPIO
controllers available early in U-Boot proper as well.
Fixes: 8c103c33fb14 ("dm: dts: Convert driver model tags to use new schema") Signed-off-by: Marek Vasut <marex@denx.de>
Yuri Zaporozhets [Tue, 19 Nov 2024 20:59:59 +0000 (21:59 +0100)]
configs: enable CONFIG_PCI_REGION_MULTI_ENTRY=y in sifive_unmatched_defconfig
Currently, the PCI subsystem selects the small "region 2" (which starts at 0x7000000)
as bus_addr/phys_addr. As a consequence, the BAR0 on PCIe video card cannot be initialized,
because it simply doesn't fit into 0x1000000 bytes size of "region 2".
U-Boot should use "region 1" instead (the one which starts at 0x60090000), because
it has much bigger size (0xFF70000), and easily accomodates BAR0 of the video card.
Linux kernel also uses 0x60090000 as bus_start/phys_start.
Signed-off-by: Yuri Zaporozhets <yuriz@vodafonemail.de> Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
To restore MMC boot, enable SPL_SYS_MMCSD_RAW_MODE and recover
SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION and
SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION.
Fixes: 2a00d73d081 ("spl: mmc: Try to clean up raw-mode options") Signed-off-by: Andreas Schwab <schwab@suse.de> Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
With the move from script based booting to using bootmeth a lot of
environment variables have changed. To always use the default environment
it is recommendable to erase the environment stored in the SPI flash.
This can be done with the 'env erase' sub-command.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Yuri Zaporozhets [Mon, 11 Nov 2024 19:24:04 +0000 (20:24 +0100)]
spl: increase SPL_SYS_MALLOC_SIZE when using BIOSEMU on RISC-V
If BIOSEMU is compiled for RISC-V (SiFive Unmatched board) and the function
dm_pci_run_vga_bios() is executed, U-Boot stops with error message saying
that the SPL malloc pool is too small. So increase the default pool size
when both BIOSEMU and RISCV parameters are set.
Signed-off-by: Yuri Zaporozhets <yuriz@qrv-systems.net> Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
david regan [Wed, 13 Nov 2024 06:27:14 +0000 (22:27 -0800)]
mtd: rawnand: brcmnand: Default bcmbca parameter_page_big_endian to zero
Set parameter_page_big_endian to zero for bcmbca
Signed-off-by: david regan <dregan@broadcom.com> Reviewed-by: William Zhang <william.zhang@broadcom.com> Reviewed-by: Anand Gore <anand.gore@broadcom.com>
Chris Packham [Mon, 25 Nov 2024 19:55:53 +0000 (08:55 +1300)]
arm: mvebu: Add Allied Telesis x250 board
The x250 and SE250 are series of 10G L2+ switches from Allied Telesis.
There are a number of them in the range but as far as U-Boot is
concerned all the CPU block components are the same so there's only one
board defined.
Signed-off-by: Chris Packham <judge.packham@gmail.com> Reviewed-by: Stefan Roese <sr@denx.de>
Tony Dinh [Thu, 21 Nov 2024 19:02:27 +0000 (11:02 -0800)]
arm: kirkwood: Enable bootstd for Sheevaplug board
Enable bootstd for Sheevaplug board.
Remove JFFS2 support. See JFFS2 Vulnerability[1].
Enable LTO to keep board size within limit.
Move default envs to text-base environment
Tony Dinh [Mon, 18 Nov 2024 19:34:59 +0000 (11:34 -0800)]
arm: mvebu: Disable JFFS2 support for Kirkwood and Armada XP boards
These boards don't use JFFS2 file system for booting so remove it.
Ref: https://lore.kernel.org/u-boot/20241114233005.GN3600562@bill-the-cat/T/#t Signed-off-by: Tony Dinh <mibodhi@gmail.com> Acked-by: Phil Sutter <phil@nwl.cc> Reviewed-by: Stefan Roese <sr@denx.de>
Ion Agorria [Tue, 26 Nov 2024 07:29:56 +0000 (09:29 +0200)]
usb: ci_udc: don't use "advance" feature when setting address
In the older USB controllers like for example in ChipIdea controller
used by the Tegra 2 the "USBADRA: Device Address Advance" bitflag
does not exist, so the new device address set during SET_ADDRESS
can't be deferred by hardware, which causes the host to not recognize
the device and give an error.
Instead store it until ep completes to apply the change into the hw
register as Linux kernel does. This should fix regression on old and
and be compatible with newer controllers.
spi: Fix missed rename from SPI_ADVANCE to SPI_STACKED_PARALLEL
Fix missed rename from SPI_ADVANCE to SPI_STACKED_PARALLEL. This fixes
an issue encountered while testing the Zynq-7000 QSPI parallel Flash
implementation.
projects / u-boot.git / log