| Age | Commit message (Collapse) | Author |
|---|
|
Rename renesas,inversion to renesas,column-inversion according to latest
schema.
Signed-off-by: Svyatoslav Ryhel <[email protected]>
|
|
Add debug log prints with a message that SKU is unknown.
Signed-off-by: Ion Agorria <[email protected]>
Signed-off-by: Svyatoslav Ryhel <[email protected]>
|
|
Until now all Tegra chips except Tegra20 had a fallback if SKU is not
known. This caused issues previously when certain SKU wasn't known. Add a
fallback for Tegra20 aligning it with other Tegra SoC generations.
Signed-off-by: Ion Agorria <[email protected]>
Signed-off-by: Svyatoslav Ryhel <[email protected]>
|
|
Add definition for Tegra20 SKU 0x4 / A04 found in Sony Tablet P.
Signed-off-by: Ion Agorria <[email protected]>
Signed-off-by: Svyatoslav Ryhel <[email protected]>
|
|
Simon Glass <[email protected]> says:
Each arch does something slightly different before booting the OS. Some
archs even do different things depending on the CPU type.
It is quite hard to know what actually happens in the final milliseconds
before the OS boot.
This series attempts to start cleaning up U-Boot in this area.
The basic intent is to create a new bootm_final() function which can be
called by all archs. It provides some flags for a couple of necessary
variations but otherwise it is generic.
All architectures are converted over to use this new function.
board_quiesce_devices() is moved into bootm_final() so that all archs
benefit from it.
This series fixes a bug in device_remove() is fixed where removing a
parent with specialised flags (e.g. DM_REMOVE_ACTIVE_ALL) could leave
children activated, since they do not match the flags. This fixes is
needed to avoid bootm_final() causing test failures on sandbox.
Future work could take this a little further:
- Convert EFI loader to use the same function
- Improve comments for cleanup_before_linux() across architectures
- Support fake-run tracing on all archs
Link: https://lore.kernel.org/r/[email protected]
|
|
Add a call to bootm_final() before the simulated kernel jump. This
adds the "Starting kernel" message, bootstage tracking,
board_quiesce_devices() and dm_remove_devices_active() which were not
previously called on sandbox.
Signed-off-by: Simon Glass <[email protected]>
|
|
Add a call to bootm_final() before jumping to the kernel. This adds
the "Starting kernel" message, bootstage tracking,
board_quiesce_devices() and dm_remove_devices_active() which were not
previously called on Xtensa.
Signed-off-by: Simon Glass <[email protected]>
|
|
Add a call to bootm_final() before jumping to the kernel. This adds
the "Starting kernel" message, bootstage tracking,
board_quiesce_devices() and dm_remove_devices_active() which were not
previously called on SH.
Signed-off-by: Simon Glass <[email protected]>
|
|
Add a call to bootm_final() before jumping to the kernel. This adds
the "Starting kernel" message, bootstage tracking,
board_quiesce_devices() and dm_remove_devices_active() which were not
previously called on Nios2.
Signed-off-by: Simon Glass <[email protected]>
|
|
Add a call to bootm_final() before jumping to the kernel. This adds
the "Starting kernel" message, bootstage tracking,
board_quiesce_devices() and dm_remove_devices_active() which were not
previously called on m68k.
Signed-off-by: Simon Glass <[email protected]>
Acked-by: Angelo Dureghello <[email protected]>
Tested-by: Angelo Dureghello <[email protected]>
Acked-by: Kuan-Wei Chiu <[email protected]>
|
|
Replace the open-coded bootstage_fdt_add_report() and
bootstage_report() with a call to bootm_final(). This also adds the
"Starting kernel" message, board_quiesce_devices() and
dm_remove_devices_active() which were not previously called on
PowerPC.
Signed-off-by: Simon Glass <[email protected]>
|
|
Replace the open-coded bootstage_fdt_add_report() and
bootstage_report() with a call to bootm_final(). This also adds the
"Starting kernel" message, board_quiesce_devices() and
dm_remove_devices_active() which were not previously called on MIPS.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Daniel Schwierzeck <[email protected]>
|
|
Replace the open-coded printf and bootstage_mark_name with a call to
bootm_final(). This also adds board_quiesce_devices() and
dm_remove_devices_active() which were not previously called on
MicroBlaze.
Signed-off-by: Simon Glass <[email protected]>
|
|
Replace the open-coded printf and bootstage_mark_name with a call to
bootm_final(). This also adds board_quiesce_devices() and
dm_remove_devices_active() which were not previously called on ARC.
Signed-off-by: Simon Glass <[email protected]>
|
|
The ARM announce_and_cleanup() duplicates the common pre-boot steps.
Replace it with a call to bootm_final().
Drop the ARM weak board_quiesce_devices() definition since it is now
called from bootm_final() and the generic weak definition in bootm.h
is used instead.
Note that the printf() ordering changes slightly: it now prints before
bootstage processing rather than after, matching x86 and RISC-V.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
The RISC-V announce_and_cleanup() duplicates the common pre-boot
steps. Replace it with a call to bootm_final().
Move board_quiesce_devices() into bootm_final() so it is available to
all architectures. Drop the RISC-V weak definition and header
declaration since the generic one in bootm.h is used instead.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
The x86 code in bootm_announce_and_cleanup() is very similar to the new
bootm_final() function, so just use the latter.
Signed-off-by: Simon Glass <[email protected]>
|
|
Quentin Schulz <[email protected]> says:
This migrates the last user of the legacy LED API, IMX233-OLinuXino and
net/bootp.c, to the modern LED framework.
I do have concern about being able to use BOOTP in SPL? In which case, I
should probably add an additional check on CONFIG_IS_ENABLED(LED) in
addition to IS_ENABLED(CONFIG_LED_BOOT)?
I haven't tested this as I do not own an IMX233-OLinuXino, so please
give this a try if you own this device.
Then, since there's no user left of this legacy API, it is entirely
removed.
Link: https://lore.kernel.org/r/[email protected]
|
|
No user of the legacy LED API anymore (except Sunxi with the PinePhone
but that is now a Sunxi-specific implementation), so let's remove
anything related.
Signed-off-by: Quentin Schulz <[email protected]>
|
|
This migrates the last user of the legacy LED API, IMX233-OLinuXino, to
the modern LED framework.
The current implementation does the following:
- lit the LED when booting,
- turn off the LED the moment a BOOTP packet is received,
The first step is easily reproduced by using the
/options/u-boot/boot-led property to point at the LED. Unfortunately,
the boot-led is only lit by U-Boot proper at the very end of the boot
process, much later than currently. We can however force the LED on
whenever the GPIO LED driver is bound by marking the LED as
default-state = "on", and this happens slightly before board_init() is
called. We then do not need /options/u-boot/boot-led property for that
anymore.
However, the second step relies on /options/u-boot/boot-led and
CONFIG_LED_BOOT being set to reproduce the same behavior and requires us
to migrate net/bootp.c to the modern LED framework at the same time to
keep bisectability.
I couldn't figure out how to map CONFIG_LED_STATUS_BIT=778 to an actual
GPIO on the SoC but according to the schematics[1] only one LED is
present. I couldn't also map the SoC pin number to an actual GPIO from
the IMX23 manual, but there's already one GPIO LED specified in the
Device Tree so my guess is all of those are one and the same.
This was only build tested as I do not own this device.
[1] https://github.com/OLIMEX/OLINUXINO/blob/master/HARDWARE/iMX233-OLinuXino-Mini/1.%20Latest%20hardware%20revision/iMX233-OLINUXINO-MINI%20hardware%20revision%20E/iMX233-OLINUXINO-MINI_Rev_E.pdf
Signed-off-by: Quentin Schulz <[email protected]>
|
|
https://gitlab.denx.de/u-boot/custodians/u-boot-imx into next
CI: https://source.denx.de/u-boot/custodians/u-boot-imx/-/pipelines/29557
- Add support for i.MX952.
- Add support for XPI1 on imx943_evk.
|
|
https://source.denx.de/u-boot/custodians/u-boot-sunxi into next
For once, replacing the legacy LED API with a more lean alternative,
just for sunxi's SPL. IIUC, this would be one step closer to dropping
this deprecated subsystem altogether.
Also adding two DRAM cleanups for the A133 SoC. There is a third patch
which requires some changes, will care about that later.
Gitlab CI passed, and I booted that briefly on an A133 board and some
board with a GPIO controlled power LED.
|
|
There is a mistmatch between Allwinner's dram_para BSP definitions and the
parameters names in mainline u-boot for TPR1-3. What we call TPR1 is actually
MR22 while TPR2 is TPR0 and TPR3 is TPR1. MR22 does get written to the
corresponding register. This only concerns LPDDR4 support.
Introduce a new Kconfig entry for MR22 and proceed with the rename.
Update the only config currently using it.
See the list of parameters from the Allwinner BSP at the end of:
https://linux-sunxi.org/A133/DRAMC
Note that the H616/H6 code is coherent with this new TPR0 definition
(and does not use TPR1 and MR22).
Signed-off-by: Paul Kocialkowski <[email protected]>
Sponsored-by: MEC Electronics GmbH <https://www.mec.at/>
Acked-by: Jernej Skrabec <[email protected]>
|
|
Some of the offsets for the DRAM PHY dx delays are wrong (as compared
to the H616 code and the reference binary) since the
mctl_phy_dx_delay0_inner function does not perform the correct
calculation for some of them.
Introduce a mctl_phy_dx_delay0_inner0 to fix the incorrect offsets and
rename the existing function to mctl_phy_dx_delay0_inner1 for the
offsets it correctly handles.
Also add memory barriers that are also present in the H616 code while
at it.
This fixes detection of 4 GiB DRAM on some boards using LPDDR4.
Signed-off-by: Paul Kocialkowski <[email protected]>
Sponsored-by: MEC Electronics GmbH <https://www.mec.at/>
Acked-by: Jernej Skrabec <[email protected]>
|
|
Bring U-Boot support for the BeagleV-Fire by adding a device tree and
supporting board files etc.
Signed-off-by: Jamie Gibbons <[email protected]>
Reviewed-by: Leo Yu-Chi Liang <[email protected]>
|
|
With this patch, XSPI1 are functional on the i.MX943 EVK board.
Signed-off-by: Alice Guo <[email protected]>
|
|
The XSPI SET GMID command is used to assign GMID ownership to the
requester, allowing access to protected XSPI control registers. This API
must be called in SPL if XSPI GMID-protected settings need to be
modified. Otherwise, XSPI configuration depends on the previous GMID
owner to provide the correct settings.
Signed-off-by: Ye Li <[email protected]>
Signed-off-by: Alice Guo <[email protected]>
Reviewed-by: Peng Fan <[email protected]>
|
|
Add support for i.MX952 15x15 lpddr4x board support.
Signed-off-by: Peng Fan <[email protected]>
Signed-off-by: Ye Li <[email protected]>
Signed-off-by: Alice Guo <[email protected]>
|
|
Add U-Boot specific device tree configuration for i.MX952 EVK board.
Signed-off-by: Alice Guo <[email protected]>
Reviewed-by: Peng Fan <[email protected]>
|
|
On i.MX952, WDG3 and WDG4 are not used for system reset. PSCI is used
instead. Keep WDG3 and WDG4 in their default state rather than
explicitly disabling them.
Signed-off-by: Alice Guo <[email protected]>
|
|
Add basic SoC support for i.MX952:
- Add CONFIG_IMX952 Kconfig option
- Include i.MX952 clock and power headers
- Set CPU speed grade to 1.7GHz for i.MX952
Signed-off-by: Alice Guo <[email protected]>
Reviewed-by: Peng Fan <[email protected]>
Reviewed-by: David Zang <[email protected]>
|
|
Extend get_imageset_end() to handle i.MX952.
Signed-off-by: Alice Guo <[email protected]>
Reviewed-by: Peng Fan <[email protected]>
|
|
Extend display_life_cycle() to support i.MX952.
Signed-off-by: Alice Guo <[email protected]>
Reviewed-by: Peng Fan <[email protected]>
|
|
Add CPU type definition and detection macro for i.MX952 SoC.
Signed-off-by: Alice Guo <[email protected]>
Reviewed-by: Peng Fan <[email protected]>
|
|
System Manager(SM) has implemented the MISC protocol to retrieve DDR
information. Using this API, U-Boot can obtain the DDR size dynamically
instead of relying on static configuration macros.
This change addresses the DDR ECC enabled case, where 1/8 of the total
DDR size is reserved for ECC data. The scmi_misc_ddrinfo() returns the
DDR size with EEC overhead already deducted.
Implementation details:
- Query the DDR size via scmi_misc_ddrinfo()
- Replace direct REG_DDR_CS[0,1]_BNDS register reads with SCMI call
- Switch from PHYS_SDRAM[x]_SIZE macros to runtime detection
- For backward compatibility with older SM firmware, fall back to
static PHYS_SDRAM[x]_SIZE configuration if the SCMI call fails
Signed-off-by: Ye Li <[email protected]>
Signed-off-by: Alice Guo <[email protected]>
Reviewed-by: Peng Fan <[email protected]>
|
|
We are trying to get rid of the legacy LED API and PinePhone is one of
the last ones requiring it.
Unlike all other users of the legacy LED API, PinePhone is controlling
the GPIO LED in SPL. Unfortunately, Sunxi doesn't enable DM support in
SPL because of tight space constraints, so we cannot make use of the
modern LED framework as that is based on DM_GPIO.
Since PinePhone is the last user of this API, I'm moving the logic to
Sunxi SPL code and will let this community decide how to handle this hot
potato.
The logic is extremely simplified as only one GPIO LED is currently
controlled in SPL by PinePhone. No need for handling multiple LEDs or
inverted polarity, let's keep it simple.
This however allows us to use the modern LED framework once in U-Boot
proper since this logic won't collide with the new framework.
Since the only misc drivers that were compiled in SPL were guarded by
CONFIG_LED_STATUS and CONFIG_LED_STATUS_GPIO, we can also disable
CONFIG_SPL_DRIVERS_MISC (which does nothing anymore).
This also saves some space for PinePhone in SPL and proper.
Tested-by: Andre Przywara <[email protected]>
Signed-off-by: Quentin Schulz <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
pcb_revision is stored in the pcb_revision field of ATOM4. Correct it.
Move the function description to the header file.
Return 0 instead of 0xFF if read_eeprom() fails.
Reviewed-by: Heinrich Schuchardt <[email protected]>
Fixes: aea1bd95b61e ("eeprom: starfive: Enable ID EEPROM configuration")
Signed-off-by: Hal Feng <[email protected]>
|
|
Directly return the DDR size instead of the field of 'DxxxExxx'.
Move the function description to the header file.
Return 0 instead of 0xFF if read_eeprom() fails.
Reviewed-by: Heinrich Schuchardt <[email protected]>
Fixes: aea1bd95b61e ("eeprom: starfive: Enable ID EEPROM configuration")
Signed-off-by: Hal Feng <[email protected]>
|
|
Siddharth Vadapalli <[email protected]> says:
This series adds PCIe endpoint boot support for the TI J784S4 SoC.
Series is based on commit f9ffeec4bdc ("board: toradex: Make A53 get RAM
size from DT in K3 boards") of the master branch of U-Boot.
PCIe Boot Logs (J784S4-EVM running Linux as Root-Complex transfers
bootloaders to another J784S4-EVM configured for PCIe Boot):
https://gist.github.com/Siddharth-Vadapalli-at-TI/2d157003818441fe79a139d0dec1058a
Link: https://lore.kernel.org/r/[email protected]
|
|
To enable PCIe boot on J784S4 SoC SERDES0 and PCIE1 should be enabled
and configured at the R5 stage. Add the required clk-data and dev-data
for SERDES0 and PCIE1.
Signed-off-by: Hrushikesh Salunke <[email protected]>
Signed-off-by: Siddharth Vadapalli <[email protected]>
Reviewed-by: Udit Kumar <[email protected]>
|
|
https://source.denx.de/u-boot/custodians/u-boot-dfu into next
u-boot-dfu-20260316
DFU:
* Make DFU_WRITE_ALT symbol available outside of DFU
* Fix PCI subclass_code warning in spl_dfu
Usb Gadget:
* Mark udc_disconnect() as static
|
|
Rockchip RK356x supports up to 8 GiB DRAM, however U-Boot only includes
the initial 32-bit 0-4 GiB addressable range in its memory map,
something that matches gd->ram_top and current expected memory available
for use in U-Boot.
The vendor DRAM init blobs add following ddr_mem rk atags [1]:
4 GiB: [0x0, 0xf0000000) and [0x1f0000000, 0x200000000)
8 GiB: [0x0, 0x200000000)
Add the remaining 64-bit 4-8 GiB addressable range, that already is
reported to OS, to the U-Boot memory map to more correctly describe all
available and addressable DRAM of RK356x. While at it also add the
missing UL suffix to the PCIe address range for consistency.
[1] https://gist.github.com/Kwiboo/6d983693c79365b43c330eb3191cbace
Acked-by: Quentin Schulz <[email protected]>
Signed-off-by: Jonas Karlman <[email protected]>
Reviewed-by: Kever Yang <[email protected]>
|
|
This series from Dominik Haller <[email protected]> adds and enables
support for the PMIC ESM node on some phycore-som based platforms.
Link: https://lore.kernel.org/r/[email protected]
|
|
Add the PMIC ESM node which is responsible for triggering the PMIC
reset.
Signed-off-by: Dominik Haller <[email protected]>
|
|
Sparsh Kumar <[email protected]> says:
This series updates the Resource Management (RM) configuration files
for AM62 family devices to align with the TIFS v11.02.09 firmware.
Background
----------
With the latest TIFS firmware (v11.02.09), an additional virtual
interrupt and event is reserved for MCU cores to DM usage on am62x,
am62ax, and am62px devices. This series brings the rm-cfg and
tifs-rm-cfg files in sync with these firmware changes across both
TI reference boards and vendor boards.
These changes are backward compatible with older TIFS firmware versions.
Additionally, the am62x platform was originally introduced without a
tifs-rm-cfg.yaml file, unlike other platforms in the AM62 family.
This series addresses that gap and enables tifs-rm-cfg in binman for
am625-sk and am62p-sk platforms.
Changes
-------
TI reference boards (patches 1-4):
- Update rm-cfg.yaml for am62x, am62ax, am62px
- Sync am62px tifs-rm-cfg.yaml with TIFS firmware template
- Add missing tifs-rm-cfg.yaml for am62x
- Enable tifs-rm-cfg in binman for am625-sk and am62p-sk
Vendor boards (patches 5-9):
- beagleplay (am62x-based)
- phytec phycore_am62x
- toradex verdin-am62
- phytec phycore_am62ax
- toradex verdin-am62p
with the required interrupt reservation. The tifs-rm-cfg.yaml files
cannot be updated without access to the corresponding SysConfig files,
as both rm-cfg.yaml and tifs-rm-cfg.yaml must remain in sync.
Link: https://lore.kernel.org/r/[email protected]
|
|
Add rcfg_yaml_tifs node override to use tifs-rm-cfg.yaml instead of
the default rm-cfg.yaml for am625-sk and am62p-sk platforms.
This enables binman to include the tifs-rm-cfg.yaml configuration
when building tiboot3 images, bringing these platforms in line with
other K3 devices like am62a-sk that already use tifs-rm-cfg.yaml.
This builds on the tifs-rm-cfg files added/updated earlier in this series.
Signed-off-by: Sparsh Kumar <[email protected]>
Reviewed-by: Neha Malcom Francis <[email protected]>
|
|
Updates the polarities for the GPIOs on the sc594
EZKIT carrier board for the newest revision, Rev D.
The new carrier board revision has different polarities
for some GPIOs. This patch updates the sc594 entries
to match the sc598 entries that were updated in a previous
commit, as both SOMs can utilize the EZKIT.
Note that these updates are for the EZKIT carrier
board used by both sc598 and sc594 SOMs, not the SOMs themselves.
Fixes: be79378 ("board: adi: Add support for SC594")
Signed-off-by: Caleb Ethridge <[email protected]>
Reviewed-by: Greg Malysa <[email protected]>
|
|
The R5 SPL requires 32-bit address mappings for OSPI1(QSPI) access.
Override the OSPI1 node with appropriate 32-bit register ranges to
enable proper address translation on the 32-bit R5 core, while
preserving 64-bit mappings for A72 cores. While at it, remove the
disabled status override for ospi1 node to support booting from
qspi.
Signed-off-by: Anurag Dutta <[email protected]>
|
|
The correct configuration symbol is CONFIG_SOUND.
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
https://source.denx.de/u-boot/custodians/u-boot-ufs into next
- ufs_hba_ops callbacks cleanup
- Rockchip UFS reset support
- UFS support in SPL
|
