- simple_panel: support timing parsing from EDID
- dw_hdmi: fix gcc-14 compiler warnings
- dw_hdmi: support vendor PHY for HDMI
- rockchip: add Rockchip INNO HDMI PHY driver
- rockchip: RK3328 HDMI and VOP support
- evb-rk3328: enable vidconsole support
- Tegra DC and DSI improvements and Tegra 114 support
- add LG LG070WX3 MIPI DSI panel driver
- add Samsung LTL106HL02 MIPI DSI panel driver
- add Toshiba TC358768 RGB to DSI bridge support
- add basic support for the Parade DP501 transmitter
- Tegra 3 panel and bridge driver improvements
- simplefb: modernise DT parsing
- fdt_simplefb: Enumerate framebuffer info from video handoff
- preserve framebuffer if SPL is passing video hand-off
- fdt_support: allow reserving FB region without simplefb
Devarsh Thakkar [Thu, 22 Feb 2024 13:08:10 +0000 (18:38 +0530)]
boot: Move framebuffer reservation to separate helper
Create separate helper for just reserving framebuffer region without
creating or enabling simple-framebuffer node.
This is useful for scenarios where user want to preserve the bootloader
splash screen till OS boots up and display server gets started without
displaying anything else in between and thus not requiring
simple-framebuffer.
Signed-off-by: Devarsh Thakkar <devarsht@ti.com> Reviewed-by: Nikhil M Jain <n-jain1@ti.com>
Devarsh Thakkar [Thu, 22 Feb 2024 13:08:09 +0000 (18:38 +0530)]
video: Assume video to be active if SPL is passing video hand-off
If SPL is passing video handoff structure to U-boot then it is safe to
assume that SPL has already enabled video and that's why it is passing
video handoff structure to U-boot so that U-boot can preserve the
framebuffer.
Signed-off-by: Devarsh Thakkar <devarsht@ti.com> Reviewed-by: Nikhil M Jain <n-jain1@ti.com>
Devarsh Thakkar [Thu, 22 Feb 2024 13:08:08 +0000 (18:38 +0530)]
boot: fdt_simplefb: Enumerate framebuffer info from video handoff
Enable and update simple-framebuffer node using the video handoff
bloblist if video was enabled at SPL stage and corresponding video
bloblist was received at u-boot proper with necessary parameters.
Signed-off-by: Devarsh Thakkar <devarsht@ti.com> Reviewed-by: Nikhil M Jain <n-jain1@ti.com>
Caleb Connolly [Fri, 16 Feb 2024 18:38:06 +0000 (18:38 +0000)]
video: simplefb: modernise DT parsing
simplefb was using old style FDT parsing which doesn't behave well in
combination with livetree. Update it to use ofnode instead and add a
missing null check for the "format" property.
Jonas Schwöbel [Wed, 31 Jan 2024 06:57:18 +0000 (08:57 +0200)]
video: bridge: add basic support for the Parade DP501 transmitter
The Parade DP501 is a DP & DVI/HDMI dual-mode transmitter. It
enables an RGB/Parallel SOC output to be converted, packed and
serialized into either DP or TMDS output device. Only DisplayPort
functionality of this transmitter has been implemented and tested.
Signed-off-by: Jonas Schwöbel <jonasschwoebel@yahoo.de> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
LTL106HL02 is a color active matrix TFT (Thin Film Transistor)
liquid crystal display (LCD) that uses amorphous silicon TFT as
switching devices. This model is composed of a TFT LCD panel, a
driver circuit and a backlight unit. The resolution of a 10.6"
contains 1920 x 1080 pixels and can display up to 16,8M color
with wide viewing angle.
Co-developed-by: Jonas Schwöbel <jonasschwoebel@yahoo.de> Signed-off-by: Jonas Schwöbel <jonasschwoebel@yahoo.de> Co-developed-by: Svyatoslav Ryhel <clamor95@gmail.com> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com> Signed-off-by: Anton Bambura <jenneron@protonmail.com>
Svyatoslav Ryhel [Wed, 31 Jan 2024 06:57:15 +0000 (08:57 +0200)]
video: panel: add LG LG070WX3 MIPI DSI panel driver
The LD070WX3 is a Color Active Matrix Liquid Crystal Display with
an integral Light Emitting Diode (LED) backlight system. The
matrix employs a-Si Thin Film Transistor as the active element. It
is a transmissive type display operating in the normally Black
mode. This TFT-LCD has 7.0 inches diagonally measured active
display area with WXGA resolution (800 by 1280 pixel array).
Svyatoslav Ryhel [Tue, 23 Jan 2024 17:16:29 +0000 (19:16 +0200)]
video: tegra20: dsi: add T114 support
Existing Tegra DSI driver mostly fits T114 apart MIPI calibration
which on T114 has dedicated driver. To resolve this MIPI calibration
logic was split for pre-T114 and T114+ devices.
Tested-by: Ion Agorria <ion@agorria.com> # HTC One X Tested-by: Svyatoslav Ryhel <clamor95@gmail.com> # Nvidia Tegratab T114 Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com> Reviewed-by: Thierry Reding <treding@nvidia.com>
Svyatoslav Ryhel [Tue, 23 Jan 2024 17:16:23 +0000 (19:16 +0200)]
video: tegra20: dc: configure behavior if PLLD/D2 is used
If DISP1 is a PLLD/D2 child, it cannot go over 370MHz. The cause
of this is not quite clear. This can be overcomed by further
halving the PLLD/D2 if the target parent rate is over 800MHz.
This way DISP1 and DSI clocks will have the same frequency. The
shift divider in this case has to be calculated from the
original PLLD/D2 frequency and is passed from the DSI driver.
Tested-by: Andreas Westman Dorcsak <hedmoo@yahoo.com> # ASUS Grouper E1565 Tested-by: Ion Agorria <ion@agorria.com> # HTC One X Tested-by: Svyatoslav Ryhel <clamor95@gmail.com> # Nvidia Tegratab T114 Tested-by: Jonas Schwöbel <jonasschwoebel@yahoo.de> # Microsoft Surface 2 Signed-off-by: Jonas Schwöbel <jonasschwoebel@yahoo.de> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com> Acked-by: Thierry Reding <treding@nvidia.com>
Svyatoslav Ryhel [Tue, 23 Jan 2024 17:16:19 +0000 (19:16 +0200)]
video: tegra20: dc: pass DC id to internal devices
Tegra SoC has 2 independent display controllers called DC_A and
DC_B, they are handled differently by internal video devices like
DSI and HDMI controllers so it is important for last to know
which display controller is used to properly set up registers.
To achieve this, a pipe field was added to pdata to pass display
controller id to internal Tegra SoC devices.
Tested-by: Agneli <poczt@protonmail.ch> # Toshiba AC100 T20 Tested-by: Robert Eckelmann <longnoserob@gmail.com> # ASUS TF101 Tested-by: Andreas Westman Dorcsak <hedmoo@yahoo.com> # ASUS Grouper E1565 Tested-by: Ion Agorria <ion@agorria.com> # HTC One X Tested-by: Svyatoslav Ryhel <clamor95@gmail.com> # Nvidia Tegratab T114 Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
- Make i.MX93 boot less verbose.
- Remove unneedd environment variables from Toradex i.MX boards.
- Use gpio-hog on verdin-imx8mm/imx8mp.
- Add PCIe support for i.MX8MM.
- Add TPM support for imx8m*-venice.
The SMBIOS configuration table does not point to a paragraph-aligned
(16 byte aligned) address. The reason is that in write_tables() rom_addr is
not aligned and copied to gd->arch.smbios_start.
The Simple Firmware Interface requires that the SFI table is paragraph-
aligned but our code does not guarantee this.
As all tables written in write_tables() must be paragraph-aligned, we
should implement the address rounding in write_tables() and not in table
specific routines like copy_pirq_routing_table().
Add paragraph-alignment in write_tables().
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Since we support SetVariableRT now add the relevant tests
- Search for the RTStorageVolatile and VarToFile variables after EBS
- Try to update with invalid variales (BS, RT only)
- Try to write a variable bigger than our backend storage
- Write a variable that fits and check VarToFile has been updated
correclty
- Append to the variable and check VarToFile changes
- Try to delete VarToFile which is write protected
- Try to add/delete runtime variables
- Verify VarToFile contains a valid file format
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
efi_loader: add an EFI variable with the file contents
Previous patches enabled SetVariableRT using a RAM backend.
Although EBBR [0] defines a variable format we can teach userspace tools
and write the altered variables, it's better if we skip the ABI
requirements completely.
So let's add a new variable, in its own namespace called "VarToFile"
which contains a binary dump of the updated RT, BS and, NV variables
and will be updated when GetVariable is called.
Some adjustments are needed to do that.
Currently we discard BS-only variables in EBS(). We need to preserve
those on the RAM backend that exposes the variables. Since BS-only
variables can't appear at runtime we need to move the memory masking
checks from efi_var_collect() to efi_get_next_variable_name_mem()/
efi_get_variable_mem() and do the filtering at runtime.
We also need an efi_var_collect() variant available at runtime, in order
to construct the "VarToFile" buffer on the fly.
All users and applications (for linux) have to do when updating a variable
is dd that variable in the file described by "RTStorageVolatile".
Linux efivarfs uses a first 4 bytes of the output to represent attributes
in little-endian format. So, storing variables works like this:
Suggested-by: Ard Biesheuvel <ardb@kernel.org> # dumping all variables to a variable Co-developed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> # contributed on efi_var_collect_mem() Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
efi_loader: Add OS notifications for SetVariable at runtime
Previous patches enable SetVariable at runtime using a volatile storage
backend using EFI_RUNTIME_SERVICES_DATA allocared memory. Since there's
no recommendation from the spec on how to notify the OS, add a volatile
EFI variable that contains the filename relative to the ESP. OS'es
can use that file and update it at runtime
When we store EFI variables on file we don't allow SetVariable at runtime,
since the OS doesn't know how to access or write that file. At the same
time keeping the U-Boot drivers alive in runtime sections and performing
writes from the firmware is dangerous -- if at all possible.
For GetVariable at runtime we copy runtime variables in RAM and expose them
to the OS. Add a Kconfig option and provide SetVariable at runtime using
the same memory backend. The OS will be responsible for syncing the RAM
contents to the file, otherwise any changes made during runtime won't
persist reboots.
It's worth noting that the variable store format is defined in EBBR [0]
and authenticated variables are explicitly prohibited, since they have
to be stored on a medium that's tamper and rollback protected.
- pre-patch
$~ mount | grep efiva
efivarfs on /sys/firmware/efi/efivars type efivarfs (ro,nosuid,nodev,noexec,relatime)
$~ efibootmgr -n 0001
Could not set BootNext: Read-only file system
- post-patch
$~ mount | grep efiva
efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)
FWTS runtime results
Skipped tests are for SetVariable which is now supported
'Passed' test is for QueryVariableInfo which is not yet supported
Test: UEFI miscellaneous runtime service interface tests.
Test for UEFI miscellaneous runtime service interfaces 6 skipped
Stress test for UEFI miscellaneous runtime service i.. 1 skipped
Test GetNextHighMonotonicCount with invalid NULL par.. 1 skipped
Test UEFI miscellaneous runtime services unsupported.. 1 passed
Test: UEFI Runtime service variable interface tests.
Test UEFI RT service get variable interface. 1 passed
Test UEFI RT service get next variable name interface. 4 passed
Test UEFI RT service set variable interface. 8 passed
Test UEFI RT service query variable info interface. 1 skipped
Test UEFI RT service variable interface stress test. 2 passed
Test UEFI RT service set variable interface stress t.. 4 passed
Test UEFI RT service query variable info interface s.. 1 skipped
Test UEFI RT service get variable interface, invalid.. 5 passed
Test UEFI RT variable services unsupported status. 1 passed, 3 skipped
Masahisa Kojima [Mon, 4 Dec 2023 04:30:14 +0000 (13:30 +0900)]
efi_loader: use event callback for initrd deregistration
Currently efi_initrd_deregister() is called in bootefi.c
when the image started from bootefi command returns.
Since efi_guid_event_group_return_to_efibootmgr event is
implemented, so let's use this event for invoking
initrd deregistration.
Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Tested-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
board: toradex: imx: Remove not needed env variables
Remove not needed variables from environment and include config files.
- setup variable used to be executed from some bootscript, however
it's not required and there is no point on having this small helper
here
- boot_file, kernel_file, ip_dyn variables are not used anywhere
- fdt_fixup variable is just set empty
- defargs, vidargs variables used to be used from some bootscript,
however there is no point on having it here and even old legacy
bootscript can work without them
- removed CONFIG_ENABLE_DDR_TRAINING_DEBUG, this is a leftover from
some copy/paste
On colibri imx6ull/imx7 NAND module, remove consoleblank=0, this is
already the Linux kernel default therefore useless.
Various Linux Kernel command line options removed are not-existing
left-over that applied to some old NXP i.MX downstream branch
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Tim Harvey [Wed, 17 Apr 2024 20:01:53 +0000 (13:01 -0700)]
board: gateworks: venice: fix dt adjustment for gw73xx baseboard for imx8mp
The GW73xx baseboard needs a PCI dt adjustment for revC/D based on a
change of the PCIe switch. Make sure we are only doing this for a pci
based ethernet to avoid causing a boot hang when the ethernet1 alias
points to eqos or fec. To know this is a pcie device ensure the alias
begins with the pcie controller.
arm: dts: verdin-imx8mm/imx8mp: use gpio-hog for sleep moci
In Linux, we allow sleep moci to be turned off when the carrier board
supports it and the system is in suspend. In U-Boot, however, we want
the sleep moci to be always on. So we use a gpio hog and disable the
regulator. This change is necessary because we switched to upstream
device tree files with commit 23fe2def1edf
("verdin-imx8mm/verdin-imx8mp: move imx verdins to OF_UPSTREAM"). A
recent upstream patch removes the gpio hog from the Linux device tree,
so we need to add it to the u-boot dtsi. The following patch will remove
the gpio hog from the Linux device tree:
https://lore.kernel.org/linux-devicetree/20240405160720.5977-1-eichest@gmail.com/
The U-Boot patch can be applied without it and will not break the build.
Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com>
Tom Rini [Fri, 19 Apr 2024 13:28:43 +0000 (07:28 -0600)]
Merge tag 'u-boot-stm32-20240419' of https://source.denx.de/u-boot/custodians/u-boot-stm
MP1:
_ Add OHCI HCD support for STM32MP15xx DHSOM
_ Report OTP-CLOSED instead of rev.? on closed STM32MP15xx
_ Initialize TAMP_SMCR BKP..PROT fields on STM32MP15xx
_ Jump to ep on successful resume in PSCI suspend code
_ Add FASTBOOT support for STM32MP13
_ Fix/Rework key and leds management for STM32MP13/15
_ net: dwc_eth_qos: Clean up STM32 glue code and add STM32MP13xx support
MP2:
_ Add stm32-fmc-ebi support
_ Add: sdmmc2 support and fix AARCH64 compilation
ARM: dts: stm32: Update red led node for stm32mp157c-ed1-scmi-u-boot
As indicated in kernel led dt-bindings, label is a deprecated
property, so remove it and use led node's name instead for
u-boot,error-led property.
Rename red led node's name to led-red.
Remove status property which is useless.
Add compatible = "gpio-leds"; which is not present in kernel DT.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
ARM: dts: stm32: Don't probe red led at boot for stm32mp157c-ed1-scmi-u-boot
red led and button dedicated to fastboot share the same gpio GPIOA13.
Led driver is probed early so the corresponding gpio is taken and
configured in output which forbid fastboot and stm32prog button usage.
To avoid this, remove the "default-state" property from red led node.
This will avoid to trigger the led driver probe() to configure the led
default state during startup.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
ARM: dts: stm32: Update red led node for stm32mp157c-ed1-u-boot
As indicated in kernel led dt-bindings, label is a deprecated
property, so remove it and use led node's name instead for
u-boot,error-led property.
Rename red led node's name to led-red.
Remove status property which is useless.
Add compatible = "gpio-leds" which is not present in kernel DT.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
ARM: dts: stm32: Don't probe red led at boot for stm32mp157c-ed1-u-boot
red led and button dedicated to fastboot share the same gpio GPIOA13.
Led driver is probed early so the corresponding gpio is taken and
configured in output which forbid fastboot and stm32prog button usage.
To avoid this, remove the "default-state" property from red led node.
This will avoid to trigger the led driver probe() to configure the led
default state during startup.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
ARM: dts: stm32: Update u-boot, boot-led for stm32mp157a-dk1-u-boot
As indicated in kernel led dt-bindings, label is a deprecated
property, so remove it and use blue led node's name instead
for u-boot,boot-led property.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
ARM: dts: stm32: Update red led node for stm32mp157a-dk1-u-boot
As indicated in kernel led dt-bindings, label is a deprecated
property, so remove it and use red led node's name instead
for u-boot,error-led property.
Rename red led node's name to led-red.
Remove status property which is useless.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
ARM: dts: stm32: Don't probe red led at boot for stm32mp157a-dk1-u-boot
red led and button dedicated to fastboot share the same gpio GPIOA13.
Led driver is probed early so the corresponding gpio is taken and
configured in output which forbid fastboot and stm32prog button usage.
To avoid this, remove the "default-state" property from red led node.
This will avoid to trigger the led driver probe() to configure the led
default state during startup.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
ARM: dts: stm32: Add led-blue for stm32mp157a-dk1-scmi-u-boot
As indicated in kernel led dt-bindings, label is a deprecated
property, so remove it and use blue led node's name instead
for u-boot,boot-led property.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
ARM: dts: stm32: Update red led node for stm32mp157a-dk1-scmi-u-boot
As indicated in kernel led dt-bindings, label is a deprecated
property, so remove it and use red led node's name instead
for u-boot,error-led property.
Rename "red" led node's name to "led-red".
Remove status property which is useless.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
ARM: dts: stm32: Don't probe red led at boot for stm32mp157a-dk1-scmi-u-boot
red led and button dedicated to fastboot share the same gpio GPIOA13.
Led driver is probed early so the corresponding gpio is taken and
configured in output which forbid fastboot and stm32prog button usage.
To avoid this, remove the "default-state" property from red led node.
This will avoid to trigger the led driver probe() to configure the led
default state during startup.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
ARM: dts: stm32: Don't probe led-red/led-blue at boot for stm32mp135f-dk-u-boot
led-red and button dedicated to fastboot share the same gpio GPIOA13.
led-blue and button dedicated to stm32prog share the same gpio GPIOA14.
Led driver is probed early so the corresponding gpio is taken and
configured in output which forbid fastboot and stm32prog button usage.
To avoid this, remove the "default-state" property from led-red and
led-blue led's node.
This will avoid to trigger the led driver probe() to configure the led
default state during startup.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
ARM: dts: stm32: Add gpio-keys for stm32mp135f-dk-u-boot
Add 2 gpio-keys :
_ button-user-1 for stm32prog mode activation.
_ update button-user's label (defined in kernel DT) to match label
requested in board_key_check() for fastboot mode activation.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
projects / u-boot.git / log
