Sean Anderson [Sun, 28 Feb 2021 21:29:51 +0000 (16:29 -0500)]
hush: Fix assignments being misinterpreted as commands
If there were no variable substitutions in a command, then initial
assignments would be misinterpreted as commands, instead of being skipped
over. This is demonstrated by the following example:
Farhan Ali [Wed, 24 Feb 2021 23:25:53 +0000 (15:25 -0800)]
mtd: Update fail_addr when erase fails due to bad blocks
For all other erase failures, the fail_addr is updated with the
failing address. Only in the case of erase failure due to bad block
detection, the fail_addr is not updated. This change simply updates
the fail_addr for this specific scenario so that it is consistent with
the rest of the code.
Signed-off-by: Farhan Ali <farhan.ali@broadcom.com>
Peter Robinson [Wed, 17 Feb 2021 17:06:53 +0000 (17:06 +0000)]
Tegra: remove e2220-1170 board
It's an old bringup board with out upstream Linux or L4T support
Signed-off-by: Peter Robinson <pbrobinson@gmail.com> Cc: Stephen Warren <swarren@nvidia.com> Cc: Tom Warren <twarren@nvidia.com> Acked-by: Stephen Warren <swarren@nvidia.com>
leads to a hanging system requiring to physically reset the system:
FDT and ATAGS support not compiled in - hanging
### ERROR ### Please RESET the board ###
For systems where physical access is difficult hanging is a poor choice.
It is preferable to reset the system when U-Boot reaches a state that is
not recoverable.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
Joel Stanley [Wed, 17 Feb 2021 03:20:42 +0000 (13:50 +1030)]
hash: Allow for SHA512 hardware implementations
Similar to support for SHA1 and SHA256, allow the use of hardware hashing
engine by enabling the algorithm and setting CONFIG_SHA_HW_ACCEL /
CONFIG_SHA_PROG_HW_ACCEL.
lib: optee: migration optee_copy_fdt_nodes for OF_LIVE support
The optee_copy_fdt_nodes is only used to copy op-tee nodes
of U-Boot device tree (from gd->fdt_blob when OF_LIVE is not activated)
to external device tree but it is not compatible with OF_LIVE.
This patch migrates all used function fdt_ functions to read node on
old_blob to ofnode functions, compatible with OF_LIVE and remove this
parameter "old_blob".
The generated "device tree" is checked on stm32mp platform with OF_LIVE
activated.
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Tom Rini [Sun, 11 Apr 2021 11:40:25 +0000 (07:40 -0400)]
Merge tag 'video-2021-07-rc1' of https://source.denx.de/u-boot/custodians/u-boot-video
- rk3399 eDP support
- pwm backlight without a known period_ns
- add Chrome OS EC PWM driver
- Kconfig SIMPLE_PANEL DM_GPIO dependency
- remove mb862xx driver remnants
- fix KiB format in reserve_video() debug trace
- fix tegra124 sor CSTM LVDS_EN_ENABLE/DISABLE config
- fix line padding calculation for 16 and 24 BPP bitmaps
video: Fix line padding calculation for 16 and 24 BPP bitmaps
Each row in the pixel array in the bitmap file is padded
if necessary so the row size is always a multiple of 4 bytes.
In current code the complement of row size to a multiple of
4 bytes is further unnecessarily multiplied by the pixel size.
This results in incorrect displaying of bitmaps having row size
that is not a multiple of 4 bytes. Fix this by removing
the unnecessary multiplication.
board_f: cosmetic: change the debug trace to KB in reserve_video
Update the debug trace for the reserved video memory to KB as indicated
in the message with "%luk"; before the patch the computed size
gd->relocaddr - addr is in bytes.
This patch aligns the debug trace in reserve_video() with others
functions, for example on stm32mp157c-dk2:
- Reserving 3080192k for video at: dfd00000
+ Reserving 3008k for video at: dfd00000
Reserving 873k for U-Boot at: dfc25000
Reserving 32776k for malloc() at: ddc23000
Reserving 72 Bytes for Board Info at: ddc22fb0
Reserving 280 Bytes for Global Data at: ddc22e90
Reserving 119072 Bytes for FDT at: ddc05d70
Reserving 0x278 Bytes for bootstage at: ddc05af0
Fixes: 5630d2fbc50f3035 ("board: Show memory for frame buffers") Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Trevor Woerner [Mon, 15 Mar 2021 22:52:45 +0000 (18:52 -0400)]
finish removing mb862xx video driver
drivers/video/mb862xx.c was removed in commit 9c1e098fb92de38f0017585658dd50c3009c84ab from December 2020, however, this
last little remnant in drivers/video/cfb_console.c remained.
Asherah Connor [Wed, 3 Mar 2021 03:46:47 +0000 (14:46 +1100)]
video: SIMPLE_PANEL depends on DM_GPIO
SIMPLE_PANEL currently only depends on PANEL && BACKLIGHT, but the code
makes references to dm_gpio_set_value and gpio_request_by_name. These
are defined in drivers/gpio/gpio-uclass.c, so a dependency on DM_GPIO
corrects these link errors:
aarch64-linux-gnu-ld.bfd: drivers/built-in.o: in function `simple_panel_set_backlight':
/home/kameliya/u-boot/drivers/video/simple_panel.c:42: undefined reference to `dm_gpio_set_value'
aarch64-linux-gnu-ld.bfd: drivers/built-in.o: in function `simple_panel_enable_backlight':
/home/kameliya/u-boot/drivers/video/simple_panel.c:27: undefined reference to `dm_gpio_set_value'
aarch64-linux-gnu-ld.bfd: drivers/built-in.o: in function `simple_panel_of_to_plat':
/home/kameliya/u-boot/drivers/video/simple_panel.c:72: undefined reference to `gpio_request_by_name'
This issue is only exposed if you have a board which enables
CONFIG_DM_VIDEO without CONFIG_DM_GPIO; so far, none do, but soon a QEMU
board may.
This PWM is used in rk3399-gru-bob and rk3399-gru-kevin to control
the display brightness. We can only change the duty cycle, so on
set_config() we just try to match the duty cycle that dividing duty_ns
by period_ns gives us. To disable, we set the duty cycle to zero while
keeping the old value for when we want to re-enable it.
The cros_ec_set_pwm_duty() function is taken from Depthcharge's
cros_ec_set_bl_pwm_duty() but modified to use the generic pwm type.
The driver itself is very loosely based on rk_pwm.c for the general pwm
driver structure.
The devicetree binding file is from Linux, before it was converted to
YAML at 5df5a577a6b4 ("dt-bindings: pwm: Convert google,cros-ec-pwm.txt
to YAML format") in their repo.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
video: backlight: Support PWMs without a known period_ns
The PWM device provided by Chrome OS EC doesn't really support anything
other than setting a relative duty cycle. To support it as a backlight,
this patch makes the PWM period optional in the device tree and pretends
the valid brightness range is its period_ns.
Also adds a sandbox test for a PWM channel that has a fixed period,
checking that the resulting duty_cycle matches on a set_config() even if
the requested period_ns can't be set.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Tom Rini [Sun, 21 Feb 2021 01:06:30 +0000 (20:06 -0500)]
ppc: Remove Cyrus_P5020 and P5040 boards
These boards have not been converted to CONFIG_DM_MMC by the deadline.
Remove them. As the P5020 is the last ARCH_P5020 platform, remove that
support as well.
Cc: Andy Fleming <afleming@gmail.com> Cc: Priyanka Jain <priyanka.jain@nxp.com> Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
Tom Rini [Wed, 10 Feb 2021 02:42:56 +0000 (21:42 -0500)]
drivers: ata: Remove mvsata_ide driver
The mvsata_ide driver was due for DM conversion by v2019.07. As that
has long passed, remove the driver and disable it in the boards which
had enabled it.
Tom Rini [Wed, 10 Feb 2021 02:42:50 +0000 (21:42 -0500)]
ppc: Remove MPC8349ITX board
This board relies on using CONFIG_LIBATA but does not enable CONFIG_AHCI. The
deadline for this conversion was the v2019.07 release. The use of CONFIG_AHCI
requires CONFIG_DM. The deadline for this conversion was v2020.01. Remove
this board.
Tom Rini [Wed, 10 Feb 2021 02:42:48 +0000 (21:42 -0500)]
arm: Remove ot1200 board
This board relies on using CONFIG_LIBATA but does not enable CONFIG_AHCI. The
deadline for this conversion was the v2019.07 release. In order to
convert to using the DWC SATA driver under DM further migrations are
required.
Cc: Christian Gmeiner <christian.gmeiner@gmail.com> Signed-off-by: Tom Rini <trini@konsulko.com> Acked-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Tom Rini [Wed, 10 Feb 2021 02:42:47 +0000 (21:42 -0500)]
arm: Remove dms-ba16 board
This board relies on using CONFIG_LIBATA but does not enable CONFIG_AHCI. The
deadline for this conversion was the v2019.07 release. The use of CONFIG_AHCI
requires CONFIG_DM. The deadline for this conversion was v2020.01. Remove
this board.
Cc: Akshay Bhat <akshaybhat@timesys.com> Cc: Ken Lin <Ken.Lin@advantech.com.tw> Signed-off-by: Tom Rini <trini@konsulko.com>
efi_loader: efi_esrt: Fix the build warning for 32 bit systems
Fix the build warning when building for 32 bit systems by using the
length modifier for size_t.
lib/efi_loader/efi_esrt.c: In function ‘efi_esrt_populate’:
include/efi_loader.h:126:8: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 8 has type ‘size_t’ {aka ‘unsigned int’} [-Wformat=]
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
* UEFI spec 2.9 introduced a new memory type EFI_UNACCEPTED_MEMORY_TYPE.
Add it to enum EFI_MEMORY_TYPE.
* Add missing EFI_MEMORY_CPU_CRYPTO constant
* Improve description of EFI_PERSISTENT_MEMORY_TYPE
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
./include/linker_lists.h:224: warning:
Function parameter or member '_type' not described in 'll_entry_ref'
./include/linker_lists.h:224: warning:
Function parameter or member '_name' not described in 'll_entry_ref'
./include/linker_lists.h:224: warning:
Function parameter or member '_list' not described in 'll_entry_ref'
Fixes: 851144350b6f ("linker_lists: Allow use in data structures") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
Ilias Apalodimas [Sat, 27 Mar 2021 08:56:07 +0000 (10:56 +0200)]
efi_loader: Cleanup get_var duplication
get_var() is defined statically in efi_bootmgr.c and doesn't properly
check a buffer allocation. Remove it completely and use the exported
function from efi_var_common.c that does the same thing
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
rockchip: video: vop: Fix format of fbbase in debug string
The debug string printing the device name, framebuffer address and of node
is using %lu as format for the framebuffer address, which is not so nice.
Change it to %lx.
Signed-off-by: Arnaud Patard <arnaud.patard@rtp-net.org> Tested-by: Peter Robinson <pbrobinson@gmail.com>
In the code, the default polarity is set to positive/positive,
which is neither normal polarity or inverted polarity. It's
only the hardware default. This leads to booting linux with
wrong polarity setting.
Update the code to use PWM_DUTY_POSTIVE | PWM_INACTIVE_NEGATIVE
by default instead.
Signed-off-by: Arnaud Patard <arnaud.patard@rtp-net.org> Tested-by: Peter Robinson <pbrobinson@gmail.com>
According to linux commit "drm/rockchip: analogix_dp: add rk3399 eDP
support" (82872e42bb1501dd9e60ca430f4bae45a469aa64), rk3288 and rk3399
eDP IPs are nearly the same, the difference is in the grf register
(SOC_CON6 versus SOC_CON20). So, change the code to use the right
register on each IP.
The clocks don't seem to be the same, the eDP clock is not at index 1
on rk3399, so don't try changing the clock at index 1 to rate 0 on
rk3399.
Signed-off-by: Arnaud Patard <arnaud.patard@rtp-net.org> Tested-by: Peter Robinson <pbrobinson@gmail.com>
rockchip: video: vop: Use endpoint compatible string to find VOP mode
The current code is using an hard coded enum and the of node reg value of
endpoint to find out if the endpoint is mipi/hdmi/lvds/edp/dp. The order
is different between rk3288, rk3399 vop little, rk3399 vop big.
A possible solution would be to make sure that the rk3288.dtsi and
rk3399.dtsi files have "expected" reg value or an other solution is
to find the kind of endpoint by comparing the endpoint compatible value.
This patch is implementing the more flexible second solution.
Signed-off-by: Arnaud Patard <arnaud.patard@rtp-net.org> Tested-by: Peter Robinson <pbrobinson@gmail.com>
Tom Rini [Fri, 9 Apr 2021 17:10:59 +0000 (13:10 -0400)]
Merge tag 'u-boot-stm32-20210409' of https://source.denx.de/u-boot/custodians/u-boot-stm
Add rt-thread art-pi board support based on STM32H750 SoC
Add Engicam i.Core STM32MP1 SoM
Add FIP header support for STM32programmer
Update uart number when no serial device found for STM32MP1
Remove board_check_usb_power function when ADC flag is not set
Update SPL size limitation for STM32MP1
Set soc_type, soc_pkg, soc_rev env variables for STM32MP1
Marek Vasut [Wed, 31 Mar 2021 12:15:09 +0000 (14:15 +0200)]
arm: stm32mp1: Set soc_type, soc_pkg, soc_rev env variables
Split up get_soc_name(), clean the decoding up a bit, and set up
environment variables which contain the SoC type, package, revision.
This is useful on SoMs, where multiple SoC options are populated.
Signed-off-by: Marek Vasut <marex@denx.de> Cc: Patrick Delaunay <patrick.delaunay@st.com> Cc: Patrice Chotard <patrice.chotard@st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
A now removed comment promises to "limit SYSRAM usage to first 128 KB".
This would imply that only SYSRAM from 0x2ffc0000 - 0x2ffe0000 would be
used. This is not what happens at all.
First, SPL_MAX_SIZE is referenced from SPL_TEXT_BASE, which on all
existing configs is set to 0x2ffc2500, not SYSRAM_BASE (0x2ffc0000).
Some of it is in the first 128 KiB and some of it is in the second
128 KiB chunk of SYSRAM.
Second, SPL_MAX_SIZE, does not restrict the BSS size. While a valiant
attempt is made via SPL_BSS_MAX_SIZE, the value of 0x00100000 is much
larger than SYSRAM, and doesn't account for the non-BSS sections.
Because we're putting the .text and .bss in the same boat, the correct
way to limit them together is via SPL_MAX_FOOTPRINT. With the current
SPL_TEXT_BASE, we couldn't limit even a very basic SPL to the first
128 KiB, and there is no technical reason to do so. Because of this,
simply allow the SPL to use all SYSRAM.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
CONFIG_SPL_BSS_START_ADDR is only used on a few mach- linker scripts.
stm32mp1 uses the generic script under arch/arm/cpu/u-boot-spl.lds,
which does not make use of this definition.
The SPL BSS starts in SRAM, right after .text, .rodata, .data, and
.u_boot_list. A very short version of the STM32MP1 memory map is:
* SYSRAM: 2ffc0000 - 30000000 <- all of SPL is here
* DRAM: c0000000+
0xC0200000 is a DRAM address, and has nothing to do with SPL. It is
just very misleading to have it next to CONFIG_SPL_BSS_MAX_SIZE, or to
have it at all.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Since commit 03f1f78a9b44 ("spl: fit: Prefer a malloc()'d buffer for
loading images"), FIT images must be malloc()'d before being loaded.
The old size of 1 MiB is suitable for FIT images with u-boot and an
FDT, but something containing a linux kernel is almost sure to fail.
It's safe to extend malloc all the way to 0xc2000000, but no further.
Linux likes to be loaded at 0xc2000000, so we use that as our cutoff
point. This gives us 29 MiB of malloc() space, which suited for more
complex FIT images including several DTBs, kernel, and OP-TEE images.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
stm32mp1: remove the board_check_usb_power function when ADC is not activated
Simplify the code of the function board_check_usb_power
based in CONFIG_ADC and adc_measurement; the function is removed by the
linker when the CONFIG_ADC is not activated.
stm32mp: update uart number in trace of serial device not found
Align the uart number in the trace of setup_boot_mode() with the name of
the uart/usart device (start at 1) and not with the instance value
(start at 0), i.e. the serial device sequence number and the index in
serial_addr[].
Fixes: f49eb16c17e2c ("stm32mp: stm32prog: replace alias by serial
device sequence number")
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
projects / u-boot.git / log