at91_wdt struct is only used by spl, remove this reference and the struct
itself.
Signed-off-by: Zixun LI <admin@hifiphile.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Rasmus Villemoes <ravi@prevas.dk> says:
While looking through list.h, I saw that the regular list_* helpers
(and one of the hlist_* ones) still contain the prefetch() that was
removed in linux 14 years ago. It doesn't do anything, but makes the
macros harder to read, so get rid of it, and the fallback, no-op
definition that they relied on. That requires removing a few uses
outside list.h as well.
checkpatch warns about some whitespace issues in list.h, but as I've
copied whole kerneldoc+#define blocks directly from the linux kernel,
I think it's better to just accept that so that we don't introduce
needless diffs. The "macro argument reuse" arguments should also be
ignored, as e.g. the "member" arguments are obviously always just bare
identifiers, and the "pos" arguments must be assigned to multiple
times.
Link: https://lore.kernel.org/r/20250507121246.518691-1-ravi@prevas.dk
None of the list helpers use prefetch() anymore, and no C code relies
on getting this definition from list.h. In any case, such an arch/cpu
specific thing does not belong in a header that just consists of cpp
helper macros.
Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
AFAICT, CONFIG_CPU_HAS_PREFETCH has never existed as a proper Kconfig
symbol in U-Boot, nor has any board include file ever defined it.
Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
These all end up using the no-op prefetch() defined in linux/list.h,
because the only possible real implementation is in
arch/mips/include/asm/processor.h, which is behing
CONFIG_CPU_HAS_PREFETCH which is nowhere defined.
In order to be able to drop that fallback definition from list.h,
first remove all uses.
Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
The use of prefetch() in these list helpers was dropped back in 2011
in linux (e66eed651fd1 ("list: remove prefetching from regular list
iterators")). No arch in U-Boot defines any actual prefetch(), and as
the referenced commit says, it's usually not a win anyway.
Whole-sale sync of list.h is not really feasible, but we can
synchronize the macros containing a prefetch() with their linux
implementations as of v6.15-rc5, also importing the various helpers
needed, e.g. list_is_head() and list_next_entry().
Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
Contrary to the datasheet, setting both DETACH and PULLD_DIS bits to 1
does not always drive the DP and DM lines to high-impedance. This
prevents the host from reliably detecting a USB disconnect and subsequent
reconnect.
The symptom is that the first gadget command (e.g., dhcp) succeeds, while
subsequent commands (e.g., nfs) fail.
Disabling and re-enabling the controller entirely, instead of toggling the
PULLD_DIS bit, reliably generates a disconnect event.
The Linux driver works correctly because gadget_disconnect/gadget_connect
are always followed by gadget_udc_start/gadget_udc_stop. In U-Boot
pullup() is used solely.
This behavior has been observed on the SAM9X60-Curiosity and
AT91SAM9G25-EK boards and has been reported to Microchip.
Signed-off-by: Zixun LI <admin@hifiphile.com>
Link: https://lore.kernel.org/r/20250602-pullup-v1-1-edcde5a050dd@hifiphile.com
[mkorpershoek: reworded commit title + comment to usba_udc_pullup()]
Signed-off-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Remove duplicate .ops assignment that was overriding the correct
ti_musb_gadget_ops with musb_usb_ops (host ops) in the ti_musb_peripheral
driver. This was causing U-Boot crashes when trying to call the
handle_interrupts operation since the wrong ops structure was being used.
Fixes: 7d98dbcc3d ("usb: musb-new: Add support for DM_USB")
Fixes: 281eaf1ed8 ("usb: gadget: musb: Convert interrupt handling to usb_gadget_generic_ops")
Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Link: https://lore.kernel.org/r/20250611171031.840277-1-kory.maincent@bootlin.com
Signed-off-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
The third_arg for a dfu alt is read as an integer and is overloaded for
different supported backends. For ext4 and fat, this third_arg
represents the partition and forms the dev part string, which should
have its partition in hex. This commit fixes dfu ext4/fat usage for
devices with ten or more partitions.
Signed-off-by: Ivan Pang <ipman@amazon.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Link: https://lore.kernel.org/r/20250611050127.38011-1-ipman@amazon.com
Signed-off-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Writing to eMMC on RK3528 is affected with the same or a similar issue
as on RK3588, where eMMC must init to HS200 at least once to fully work.
Trying to write u-boot-rockchip.bin to eMMC fails with:
=> mmc write $fileaddr 40 5000
MMC write: dev # 0, block # 64, count 20480 ... mmc write failed
0 blocks written: ERROR
For U-Boot to enable HS200 mode the mmc-hs200-1_8v prop must be defined
in the device tree. Linux does not seem to be affected and is able to
detect and use HS200 without this prop.
Enable use of HS200 and fix eMMC write on RK3528 by adding the missing
mmc-hs200-1_8v prop for affected boards:
=> mmc write $fileaddr 40 5000
MMC write: dev # 0, block # 64, count 20480 ... 20480 blocks written: OK
Fixes: b112a44531 ("board: rockchip: Add minimal generic RK3528 board")
Fixes: ccbddf6453 ("board: rockchip: Add Radxa E20C")
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Raspberry Pi 5 can now have up to 16 GiB of RAM where the memory spans 8
DRAM banks in total. Increase the config value to 8 to initialize the
whole RAM. Without this change, kernel only sees 8 GiB of RAM on the 16
GiB CM5 as reported in [1].
[1] https://github.com/home-assistant/operating-system/issues/3989
Signed-off-by: Jan Čermák <sairon@sairon.cz>
Reviewed-by: Matthias Brugger <mbrugger@suse.com>
Sync bitfield.h header with Linux 6.15 version. Mainly is to permit the
introduction of FIELD_PREP_CONST. The bug.h header changed to
build_bug.h doesn't cause any regression as we also ship split header
similar to how it's done with in Linux.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
The GENMASK/GENMASK_ULL macro requires inclusion of linux/bitops.h
header. It does currently work as bitfield.h includes it indirectly
but this will change when bitfield.h will be synced with new Linux
version.
Also raw printf require linux/bug.h header (also currently included
indirectly by bitfield.h)
Explicitly include the headers to fix future compilation error.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
The WARN macro requires inclusion of linux/bug.h header. It does
currently work as bitfield.h includes it indirectly but this will
change when bitfield.h will be synced with new Linux version.
Explicitly include the header to fix future compilation error.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
The WARN macro requires inclusion of linux/bug.h header. It does
currently work as bitfield.h includes it indirectly but this will
change when bitfield.h will be synced with new Linux version.
Explicitly include the header to fix future compilation error.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
E Shattow <e@freeshell.de> says:
Make consistent use of lowercase hexadecimal prefix '0x' throughout U-Boot.
There are a few remaining uses of uppercase 'X' to denote hexadecimal prefix
or placeholder in documentation and error messages.
External devicetree-rebasing dts/upstream and the generated code of
xilinx/zynq are ignored for the series.
Link: https://lore.kernel.org/r/20250606224558.1117422-1-e@freeshell.de
Use consistent lowercase hex prefix style in drivers/*
Does not change hex prefix case in allcaps uppercase style error messages
Signed-off-by: E Shattow <e@freeshell.de>
Use consistent lowercase hex prefix style in board/*
Does not change auto-generated files in xilinx/zynq/*/ps7_init_gpl.c
Signed-off-by: E Shattow <e@freeshell.de>
Rasmus Villemoes <ravi@prevas.dk> says:
There's really no reason for the gd pointer to have the volatile
qualifier.
In fact, I claim that it's completely unnecessary and just pessimizes
code generation and forces ugly casts in lots of places. For example,
see the casts in drivers/core/tag.c where elements are added to
gd->dm_taglist, or a helper such as cyclic_get_list() that should not
be needed.
Also, it is what ends up standing in the way of an otherwise
innocent code cleanup of list.h:
https://lore.kernel.org/u-boot/20250522165656.GB2179216@bill-the-cat/
Note that riscv, x86 as well as arm64 with LTO enabled has not had
this volatile qualifier, so it's unlikely there's any generic code
that depends on it.
Link: https://lore.kernel.org/r/20250604195612.2312979-1-ravi@prevas.dk
It's slightly ironic that riscv at very first had the gd pointer
volatile qualified [6020faf62c ("riscv: nx25: include: Add header
files to support RISC-V")], removed that back in 2018
[40717eb849 ("riscv: checkpatch: Fix use of volatile")], and then in
2020 this helper was added [6b9966e1aa ("riscv: define function
set_gd()")] which needlessly had volatile in the prototype.
Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
The global gd pointer is no longer volatile-qualified. Callers of this
helper function have been updated to no longer use volatile-qualifed
temporary variables, so update the prototype accordingly.
Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
The global gd pointer is no longer volatile-qualified, so drop that
qualifier from these bookkeeping variables.
Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
The global gd pointer is no longer volatile-qualified, so drop that
qualifier from these bookkeeping variables.
Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Now that the global gd pointer is no longer volatile-qualified,
there's no reason for the temporary variables used for
saving/restoring it to have that qualifier.
Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
Tested-by: Anshul Dalal <anshuld@ti.com>
The way DECLARE_GLOBAL_DATA_PTR is used, the stuff under #if 0 can
never compile as you cannot have a non-constant initializer at global
scope (and one would get linker errors as well because the 'gd' symbol
would be defined in multiple TUs).
Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
Acked-by: Angelo Dureghello <angelo@kernel-space.org>
There's a bunch of other places where this qualifier should be
dropped, e.g. in the set_gd() prototype and for various variables used
for stashing the value in the mach-imx/ directory and elsewhere. But
that will be done in follow-up patches.
Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
Tested-by: Anshul Dalal <anshuld@ti.com>
This patch is to solve the sandbox building error:
$ make O=build-sandbox -s sandbox_defconfig
$ make O=build-sandbox -s -j2
/usr/bin/ld: /tmp/u-boot.27rzOu.ltrans58.ltrans.o: undefined reference to symbol 'pthread_kill@@GLIBC_2.2.5'
/usr/bin/ld: /lib/x86_64-linux-gnu/libpthread.so.0: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
[...]
Fixes: b989f9ed9f ("test: lib: add initjmp() test")
Signed-off-by: Raymond Mao <raymond.mao@linaro.org>
Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org>
Tested-by: Patrice Chotard <patrice.chotard@foss.st.com>
This function is currently a misnomer at times as we have cases where it
passes arguments to the image. In preparation for making that be a more
common case rename this function to jump_to_image(...). In order to do
this, rename jump_to_image in board_init_r(...) to jumper so that we do
not have a conflict.
Signed-off-by: Simon Glass <sjg@chromium.org>
[trini: Reword the commit message, adding missing cases of
jump_to_image_no_args()]
Signed-off-by: Tom Rini <trini@konsulko.com>
Sukrut Bellary <sbellary@baylibre.com> says:
This patch series adds the support for
1. In am33xx SoC[1], enhanced capture (eCAP) supports auxiliary PWM (APWM).
This series adds the PWM driver support for the APWM feature for eCAP on
AM33xx. AM335X_ECAP0_IN_PWM0_OUT is used to enable the backlight.
2. Fix build warning in ti-ehrpwm driver in dev_deb().
3. Enable eCAP0 PWM and LCD pin muxing to support splash screen on
AM335x EVM[2].
[1] AM335x TRM - https://www.ti.com/lit/ug/spruh73q/spruh73q.pdf
[2] AM335x EVM - https://www.ti.com/tool/TMDXEVM3358
per discussion on the earlier patch series,
https://lore.kernel.org/all/20250319202516.3300444-1-sbellary@baylibre.com/
dropping the device tree changes in this series due to OF_UPSTREAM
conflict.
As we are dropping the DT patch, started with the new series instead of
V2.
This series doesn't contain defconfig changes since we don't want to
enable LCD, splash screen and PWM support by default.
Enabling splash screen and PWM support in defconfig causes u-boot crash
on AM335x based beaglebone black. This will be handled in a separate
patch.
Link: https://lore.kernel.org/r/20250530212232.1686613-1-sbellary@baylibre.com
On AM335x EVM[1],
1. pin AM335X_ECAP0_IN_PWM0_OUT is used to enable the
backlight. ECAP0 can be configured in single channel PWM mode.
If CONFIG_PWM_TI_ECAP is enabled, perform eCAP0 pin muxing.
2. Pins LCD_DATA0 - LCD_DATA15, gpmc_ad8 - gpmc_ad15 and
lcd_vsync, lcd_sync, lcd_ac_bias_en, lcd_pclk are used for driving LCD.
If CONFIG_AM335X_LCD is enabled, perform the LCD pin muxing.
This is required to enable splash screen support on AM335x EVM.
[1] AM335x EVM - https://www.ti.com/tool/TMDXEVM3358
Signed-off-by: Sukrut Bellary <sbellary@baylibre.com>
