The function sha256_csum_wd is defined in lib/sha256.c
and in lib/mbedtls/sha256.c. To avoid duplicating this
function (and future function), we move this function
to the file lib/sha256_common.c
Reviewed-by: Raymond Mao <raymond.mao@linaro.org>
Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com>
The attribute __packed was defined in the file
tools/renesas_spkgimage.h but this attribute is
already defined in linux/compiler_attributes.h.
So we include <linux/compiler_attributes.h.h>
and do not define __packed.
Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com>
The attribute __packed was defined in the file
tools/kwbimage.h but this attribute is already
defined in linux/compiler_attributes.h. So we
include <linux/compiler_attributes.h.h> and
do not define __packed.
Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com>
One can use ccache by keeping ccache in PATH or by providing the full
path to ccache as well. Providing the full path to ccache fails as the
current regex tries to look for ccache being the initial token during
filtering.
Do a greedy search to remove anything before ccache for regex matching.
Fixes: 04b1d84221 ("Makefile: fix empty MK_ARCH when using ccache")
Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>
commit e27bddff4b ("imx8m: Restrict usable memory to space below 4G boundary")
tried to adjust the usable memory limits on a 4GB boundary.
ram_top is described as 'top address of RAM used by U-Boot' and we want
to preserve that. This is defined as a phys_addr_t and unfortunately
its size differs across architectures. This has lead us to a weird
state where 32bit boards define it 'SZ_4GB - 1' and 64bit boards as
'SZ_4GB' unless it was otherwise defined.
With some recent LMB changes and specifically
commit 1a48b0be93 ("lmb: prohibit allocations above ram_top even from same bank")
the board fails to boot properly although the commit above is correct
since it's making sure that no memory above ram_top is usable -- but
added to our memory map so EFI can hand it over to the booted OS.
The reason for that is that during the LMB init we add all usable memory
in lmb_add_memory(). In that function any memory above ram_top gets added
as 'reserved' for LMB. With the current values tha's set to 0xFFFF_FFFF
for this board. Later LMB is trying to protect the memory area U-Boot lives
in with lmb_reserve_common(). The latter fails though since it tries to
add U-Boot top (which is 0xFFFF_FFFF as well) to U-Boot 'bottom'. This call
will fail since 1 byte of that memory range is already marked as 'reserved'.
Since we are close to the release, LMB seems to assume that the address
is rounded up and is the 'next address' and so does parsing and adding
memory ranges from DT files, bump the ram_top of the board by 1byte.
In the long run we should change all of the above and have 32b and 64b
platforms define ram_top identically.
Add a Fixes tag although the commit is correct, so people can figure out
the broken scenarios in the future.
Suggested-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Fixes: commit 1a48b0be93 ("lmb: prohibit allocations above ram_top even from same bank")
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Reported-by: João Paulo Gonçalves <jpaulo.silvagoncalves@gmail.com>
Closes: https://lore.kernel.org/all/20241216114231.qpfwug3zfqkxn3d5@joaog-nb.corp.toradex.com/
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Fixes: 74f88b7221 ("ARM: imx: imx8m: Fix board_get_usable_ram_top()")
("Enable EFI_LOADER_BOUNCE_BUFFER") is not the correct fix for the
problem it describes.
The change of memory addressing leading to side-effects in commit
22f2c9ed9f ("efi: memory: use the lmb API's for allocating and
freeing memory") is remedied by commit 1a48b0be93 ("lmb: prohibit
allocations above ram_top even from same bank").
This reverts commit 9c792ab336.
eth_get_dev() returns NULL if no network device is available.
Not checking the return value leads to a crash when the device
pointer is dereferenced.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org>
If the dns command cannot find a network interface, we should return
CMD_RETFAIURE and not -1 (CMD_RET_USAGE).
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org>
There have been a few changes to the areas that this file documents
without having regenerated the file. Do so now.
Signed-off-by: Tom Rini <trini@konsulko.com>
The content of CONFIG_OF_SPL_REMOVE_PROPS is the same in both
STM32MP15xx DHCOM and DHCOR defconfigs, deduplicate the content
into stm32mp15_dhsom.config .
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
The access-controllers DT property is not useful in STM32MP15xx SPL,
remove it to reduce SPL control DT size. No functional change.
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Commit 2a00d73d08 ("spl: mmc: Try to clean up raw-mode options")
broke booting from SD card on STM32MP15xx , reinstate raw mode SD
boot configuration options and select the correct raw mode partition
for STM32MP15xx to fix SD boot on STM32MP15xx DHSOM.
Fixes: 2a00d73d08 ("spl: mmc: Try to clean up raw-mode options")
Reported-by: Patrice Chotard <patrice.chotard@foss.st.com>
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
The root oscillators reference used to be in rcc node since
3d15245502 ("ARM: dts: stm32mp1: explicit clock reference needed by RCC clock driver")
however this is not part of upstream stm32mp151.dtsi . The
RCC driver does need this reference, reinstate it locally.
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
The root oscillators reference used to be in rcc node since
3d15245502 ("ARM: dts: stm32mp1: explicit clock reference needed by RCC clock driver")
however this is not part of upstream stm32mp151.dtsi . The
RCC driver does need this reference, reinstate it globally.
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Tested-by: Patrice Chotard <patrice.chotard@foss.st.com>
Since commit 6534d26ee9 ("lmb: do away with arch_lmb_reserve()"),
STM32F746-disco hangs when loading device tree just before starting
kernel:
Retrieving file: /stm32f746-disco.dtb
Kernel image @ 0xc0008000 [ 0x000000 - 0x19ae00 ]
Flattened Device Tree blob at c0408000
Booting using the fdt blob at 0xc0408000
Working FDT set to c0408000
Loading Device Tree to c05f8000, end c05ff71c ...
Adjust STACK_SIZE to 16KB for STM32 MCUs (F4/F7 and H7) boards
to fix kernel boot process as some of these boards embeds a limited
amount of memory.
Fixes: 6534d26ee9 ("lmb: do away with arch_lmb_reserve()")
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Previously, all LMB marked with LMB_NOMAP (above and below ram_top)
are considered as invalid entry in TLB.
Since commit 1a48b0be93 ("lmb: prohibit allocations above ram_top
even from same bank") all LMB located above ram_top are now marked
LMB_NOOVERWRITE and no more LMB_MAP.
This area above ram_top is reserved for OPTEE and must not be cacheable,
otherwise this leads to a Panic on some boards (Issue on STM32MP135F-DK).
Restore previous behavior by marking invalid entry all TLB above ram_top.
Fixes: 1a48b0be93 ("lmb: prohibit allocations above ram_top even from same bank")
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
cc: Sughosh Ganu <sughosh.ganu@linaro.org>
Acked-by: Sughosh Ganu <sughosh.ganu@linaro.org>
I have an original rpi installed now, loaded with OS Lite (32-bit)
Add an entry for it so that it can be used for testing.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
This patch was written before the XPL change-over. Update the Makefile
condition to the new way.
Signed-off-by: Simon Glass <sjg@chromium.org>
Fixes: ae3b5928d6 ("x86: coreboot: Allow building an expo for...")
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
The logic in get_details() retrieves the default source directory from
the Labgrid settings. This is convenient for interactive use, since it
allows pytests to be run from any directory and still find the source
tree.
However, it is not actually correct.
Gitlab sets the current directory to the source tree and expects that to
be used. At present it is ignored. The result is that Gitlab builds
whatever happens to be in the default source directory, ignoring the
tree it is supposed to be building.
Fix this by using the directory of the source tree, always. This is
obtained by looking at the grandparent of the conftest.py file.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reported-by: Tom Rini <trini@konsulko.com>
Fixes: bf89a8f1fc ("test: Introduce the concept of a role")
Tested-by: Tom Rini <trini@konsulko.com>
In case DM drivers probe earlier than board clock setup is done
init of basic clocks should be done in CAR driver probe as well.
Add it to avoid possible clock related problems.
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Return PLL id into struct clk if PLL is parsed from device
tree instead of throwing an error. Allow requesting PLL
clock rate via get_rate op.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
On 64bit systems the timer value might be truncated to a 32bit value
causing malfunctions. For example on ARM the timer might start from 0
again only after a cold reset. The 32bit overflow occurs after a bit
more than 49 days (1000 Hz counter) so booting after that time may lead
to a surprise because the board might become stuck requiring a cold
reset.
Signed-off-by: Ronald Wahl <ronald.wahl@legrand.com>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
buf was used as destination and as parameter to sprintf
which triggers an undefined behaviour.
This commit removes this usage of sprintf and uses strcat
to append strings to buf variable.
Signed-off-by: Francois Berder <fberder@outlook.fr>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Without this patch, there will be error indicating that
"Cannot use 64 bit addresses with SDMA", and the booting
process will stuck.
please see full boot log below
U-Boot 2022.04-g18185931 (Sep 11 2024 - 13:15:30 +0800)
SoC: LS1028AE Rev1.0 (0x870b0010)
Clock Configuration:
CPU0(A72):1500 MHz CPU1(A72):1500 MHz
Bus: 400 MHz DDR: 1600 MT/s
Reset Configuration Word (RCW):
00000000: 3c004010 00000030 00000000 00000000
00000010: 00000000 018f0000 0030c000 00000000
00000020: 020031a0 00002580 00000000 00003296
00000030: 00000000 00000010 00000000 00000000
00000040: 00000000 00000000 00000000 00000000
00000050: 00000000 00000000 00000000 00000000
00000060: 00000000 00000000 200e705a 00000000
00000070: bb580000 00000000
Model: LS1028A RDB Board
Board: LS1028AE Rev1.0-RDB, Version: C, boot from SD
FPGA: v8 (RDB)
SERDES1 Reference : Clock1 = 100.00MHz Clock2 = 100.00MHz
DRAM: 3.9 GiB
DDR 3.9 GiB (DDR4, 32-bit, CL=11, ECC on)
Using SERDES1 Protocol: 47960 (0xbb58)
PCIe1: pcie@3400000 Root Complex: no link
PCIe2: pcie@3500000 Root Complex: x1 gen2
Core: 45 devices, 22 uclasses, devicetree: separate
WDT: Started watchdog@c000000 with servicing (60s timeout)
WDT: Started watchdog@c010000 with servicing (60s timeout)
MMC: FSL_SDHC: 0, FSL_SDHC: 1
Loading Environment from MMC... *** Warning - bad CRC, using default environment
EEPROM: Invalid ID (ff ff ff ff)
In: serial
Out: serial
Err: serial
SEC0: RNG instantiated
Net:
Warning: enetc-0 (eth0) using random MAC address - d2:9b:a5:37:7b:b5
eth0: enetc-0
Warning: enetc-2 (eth1) using random MAC address - ca:57:11:de:de:cb
, eth1: enetc-2, eth2: swp0, eth3: swp1, eth4: swp2, eth5: swp3
Hit any key to stop autoboot: 0
Trying load HDP firmware from SD..
switch to partitions #0, OK
mmc0 is current device
Device: FSL_SDHC
Manufacturer ID: 9f
OEM: 5449
Name: SD32G
Bus Speed: 50000000
Mode: SD High Speed (50MHz)
Rd Block Len: 512
SD version 3.0
High Capacity: Yes
Capacity: 28.9 GiB
Bus Width: 4-bit
Erase Group Size: 512 Bytes
MMC read: dev # 0, block # 18944, count 512 ... 512 blocks read: OK
Loading hdp firmware from 0x00000000a0000000 offset 0x0000000000002000
Loading hdp firmware Complete
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
** Unable to read file / **
Failed to load '/'
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
Scanning disk mmc@2140000.blk...
Scanning disk mmc@2150000.blk...
Found 7 disks
ERROR: invalid device tree
Found EFI removable media binary efi/boot/bootaa64.efi
981992 bytes read in 44 ms (21.3 MiB/s)
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
WARNING could not find node vivante,gc: FDT_ERR_NOTFOUND.
Booting /efi\boot\bootaa64.efi
Cannot use 64 bit addresses with SDMA
Error reading cluster
** Unable to read file /efi/boot/grubaa64.efi **
Unexpected return from initial read: Device Error, buffersize 29D790
Failed to load image ￢ : Device Error
start_image() returned Device Error
EFI LOAD FAILED: continuing...
switch to partitions #0, OK
mmc1(part 0) is current device
Scanning mmc 1:1...
** Unable to read file / **
Failed to load '/'
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
BootOrder not defined
EFI boot manager: Cannot load any image
Scanning mmc 1:2...
** Unable to read file / **
Failed to load '/'
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
BootOrder not defined
EFI boot manager: Cannot load any image
starting USB...
Bus usb@3100000: Register 200017f NbrPorts 2
Starting the controller
USB XHCI 1.00
Bus usb@3110000: Register 200017f NbrPorts 2
Starting the controller
USB XHCI 1.00
scanning bus usb@3100000 for devices... 1 USB Device(s) found
scanning bus usb@3110000 for devices... 1 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
Device 0: unknown device
Trying load from SD ...
switch to partitions #0, OK
mmc0 is current device
Device: FSL_SDHC
Manufacturer ID: 9f
OEM: 5449
Name: SD32G
Bus Speed: 50000000
Mode: SD High Speed (50MHz)
Rd Block Len: 512
SD version 3.0
High Capacity: Yes
Capacity: 28.9 GiB
Bus Width: 4-bit
Erase Group Size: 512 Bytes
MMC read: dev # 0, block # 32768, count 81920 ... 81920 blocks read: OK
Wrong Image Format for bootm command
ERROR: can't get kernel image!
Signed-off-by: Wei Ming Chen <jj251510319013@gmail.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Board introductions have a feature list which isn't formatted properly
according to rST and is thus rendered incorrectly.
Fix this by adding the missing newlines in the appropriate places.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Add a blank line after title "Specification:" to
make it render correctly html.
And also remove the useless > in bash code block.
Signed-off-by: Andy Yan <andyshrk@163.com>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
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.
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Although it has historically been different, the current standard
spelling of the neutral singular possessive pronoun is "its".
Signed-off-by: J. Neuschäfer <j.ne@posteo.net>
Since commit 61ff13283c ("board: sl28: move to OF_UPSTREAM") USB0 is
broken because the former u-boot soc dtsi was setting dr_mode to "host"
but the linux device tree isn't. That is because linux fully supports
OTG but u-boot doesn't. Therefore, u-boot only ever enabled host mode
and never OTG mode. Add it to our board "-u-boot.dtsi" to fix it.
Fixes: 61ff13283c ("board: sl28: move to OF_UPSTREAM")
Reported-by: Heiko Thiery <heiko.thiery@gmail.com>
Signed-off-by: Michael Walle <mwalle@kernel.org>
Tested-by: Heiko Thiery <heiko.thiery@gmail.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Network is broken on variant 3 boards since commit 61ff13283c ("board:
sl28: move to OF_UPSTREAM") because it was removing the variant 3
handling. That is because at that time the var3 device tree was not
upstream. FWIW variant 3 is actually the same as the base variant, but
I've missed that the -u-boot.dtsi is not inlcuded in this case which
will set the ethernet alias. Now that the var3 device tree is upstream,
just re-add it to the SPL handling again.
Fixes: 61ff13283c ("board: sl28: move to OF_UPSTREAM")
Signed-off-by: Michael Walle <mwalle@kernel.org>
Reviewed-by: Heiko Thiery <heiko.thiery@gmail.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
