Hi Dan Carpenter,
I have verified it on the little-endian platform, such as ASPEED AST2600.
I think put_unaligned_be32() and htonl() functions have no effect on big-endian
platforms.
And keep put_unaligned_be32() to help access the unaligned memory, such as
pchecksum variable.
Thanks,
Jacky
_
On Sat, Mar 02, 2024 at 05:52:43PM +0100, Marek Vasut wrote:
> The following changes since commit abd4fb5ac13215733569925a06991e0a182ede14:
>
> Merge patch series "Dockerfile: Build coreboot from source" (2024-02-27
> 16:28:57 -0500)
>
> are available in the Git repository at:
>
> https://
On Tue, 27 Feb 2024 17:05:40 +0100, Marek Vasut wrote:
> Rename R-Mobile to Renesas all over the place because the chips are
> made by Renesas, while only a subset of them is from the R-Mobile line.
>
> Marek Vasut (19):
> ARM: renesas: Drop remnants of R8A7740 support
> ARM: renesas: Drop un
According to README CFG_SYS_BOOTMAPSZ section, in case both "bootm_low" and
"bootm_size" variables are defined, "bootm_mapsize" variable is not defined
and CFG_SYS_BOOTMAPSZ macro is not defined, all data for the Linux kernel
must be between "bootm_low" and "bootm_low" + "bootm_size".
Currently, f
Hello Christopher,
On 2024-03-02 15:50, Christopher Obbard wrote:
When debugging the SPL boot order, the node ID of a device which hasn't
been found is printed but it can be quite hard to relate that to the
specific devicetree node. To aid debugging, print the node path as well
as
the ID.
Ori
Hello Christopher,
On 2024-03-02 15:50, Christopher Obbard wrote:
Fix a simple spelling mistake in a comment.
I'd suggest that the main part of the patch subject is adjusted
a bit, e.g. to something like "fix a typo".
Otherwise, looking good to me.
Reviewed-by: Dragan Simic
Signed-off-by:
Hello Ilias,
On Fri, Mar 1, 2024 at 10:41 AM Ilias Apalodimas <
ilias.apalodi...@linaro.org> wrote:
> Hi Igor,
>
> On Thu, 29 Feb 2024 at 21:11, Igor Opaniuk wrote:
> >
> > Hi Ilias,
> >
> > On Wed, Feb 14, 2024 at 7:34 PM Igor Opaniuk
> wrote:
> >>
> >> - Address some spelling errors and typos
The usage of the common.h include file is deprecated [1], and has already
been removed from several files.
Get rid of all inclusions in the "drivers/tee" directory, and replace it
with required include files directly where needed.
[1] doc/develop/codingstyle.rst
Signed-off-by: Igor Opaniuk
---
Add read/write tests for optee_rpmb cmd.
Signed-off-by: Igor Opaniuk
---
(no changes since v1)
test/py/tests/test_optee_rpmb.py | 20
1 file changed, 20 insertions(+)
create mode 100644 test/py/tests/test_optee_rpmb.py
diff --git a/test/py/tests/test_optee_rpmb.py b/test
Support CMD_OPTEE_RPMB for SANDBOX configurations.
Test:
$ ./u-boot -d arch/sandbox/dts/test.dtb
...
=> optee_rpmb write_pvalue test_variable test_value
Wrote 11 bytes
=> optee_rpmb read_pvalue test_variable 11
Read 11 bytes, value = test_value
Reviewed-by: Mattijs Korpershoek
Tested-by: Mattijs
Fix spelling errors in comments.
Reviewed-by: Heinrich Schuchardt
Reviewed-by: Ilias Apalodimas
Signed-off-by: Igor Opaniuk
---
Changes in v2:
- Applied R-b tags
drivers/tee/sandbox.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/tee/sandbox.c b/drivers/
Fix OPTEE_TA_AVB symbol description in Kconfig:
s/"write"rb"/"write_rb"/g
Reviewed-by: Heinrich Schuchardt
Reviewed-by: Ilias Apalodimas
Signed-off-by: Igor Opaniuk
---
Changes in v2:
- Applied R-b tags
drivers/tee/optee/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --g
- Address some spelling errors and typos
- Support CMD_OPTEE_RPMB for SANDBOX configurations and add python tests
- Remove common.h inclusion for drivers/tee
Changes in v2:
- Fixed chimp_optee.c:37:9: error: implicit declaration of function 'memset'
- Applied R-b and T-b tags
Igor Opaniuk (5):
Hello Christopher,
On 2024-03-02 15:34, Christopher Obbard wrote:
Some variants of the ROCK Pi 4 series contain an SPI flash chip, which
can
be booted from. This patch enables support in U-Boot for building the
image for the SPI flash, support for booting U-Boot from the SPI flash
chip and supp
Hi Christopher,
On 2024-03-02 17:12, Christopher Obbard wrote:
> Hi Jonas,
>
> On Sat, 2024-03-02 at 16:28 +0100, Jonas Karlman wrote:
>> Hi Christopher,
>>
>> On 2024-03-02 15:34, Christopher Obbard wrote:
>>> Some variants of the ROCK Pi 4 series contain an SPI flash chip, which can
>>> be boot
Hello Leon,
On 2024-03-02 14:17, Leon M. Busch-George wrote:
From: "Leon M. Busch-George"
The error message "bc: command not found" is easily missed since the
build continues.
bc is not a part of coreutils or base-devel. POSIX sh can also do the
calculation.
Signed-off-by: Leon M. Busch-Georg
With the stack and text base used by U-Boot SPL and proper on RK3328
there is a high likelihood of overlapping when U-Boot proper + FDT nears
or exceeded 1 MiB in size.
Currently the following memory layout is typically used on RK3328:
[0, 256K) - SPL binary
[ 256K, 2M) - TF-A / reserved
[
Currently the following memory layout is typically used on RK356x:
[0, 256K) - SPL binary
[ 256K, 2M) - TF-A / reserved
[ -X, 4M) - SPL pre-reloc stack (SPL_STACK)
[-128K, 4M) - pre-reloc malloc heap (SPL_SYS_MALLOC_F_LEN)
[ -X, 6M) - SPL reloc stack (SPL_STACK_R_ADDR)
[ 5M, 6
With the stack and text base used by U-Boot SPL and proper on RK3399
there is a high likelihood of overlapping when U-Boot proper + FDT nears
or exceeded 1 MiB in size.
Currently the following memory layout is typically used on RK3399:
[0, 256K) - SPL binary
[ 256K, 2M) - TF-A / reserved
[
Currently the following memory layout is typically used on RK3588:
[0, 256K) - SPL binary
[ 256K, 2M) - TF-A / reserved
[ -X, 4M) - SPL pre-reloc stack (SPL_STACK)
[ 3.5M, 4M) - pre-reloc malloc heap (SPL_SYS_MALLOC_F_LEN)
[ -X, 6M) - SPL reloc stack (SPL_STACK_R_ADDR)
[ 5M, 6
Currently the following memory layout is typically used on RK3308:
[0, 256K) - SPL binary
[ 256K, 2M) - TF-A / reserved
[ -X, 4M) - SPL pre-reloc stack (SPL_STACK)
[ -8K, 4M) - pre-reloc malloc heap (SPL_SYS_MALLOC_F_LEN)
[ 4M, +8K) - SPL bss (SPL_BSS_START_ADDR, SPL_BSS_MAX_SIZE)
On Rockchip the typical aarch64 boot steps are as follows:
- BROM load TPL to SRAM
- TPL init full DRAM
- use stack in SRAM at TPL_STACK addr
- use malloc heap on stack, size is TPL_SYS_MALLOC_F_LEN
- TPL jump back to BROM
- BROM load SPL to beginning of DRAM
- SPL init storage devices
- use
Trying to run U-Boot proper close to 1 MiB in size with debug logging
something similar to following can be observed:
FDT 002fc4e0 gd 002fddf0
FDT overlap
resetting ...
System reset not supported on this platform
### ERROR ### Please RESET the board ###
Fix this by chang
The following changes since commit abd4fb5ac13215733569925a06991e0a182ede14:
Merge patch series "Dockerfile: Build coreboot from source" (2024-02-27
16:28:57 -0500)
are available in the Git repository at:
https://source.denx.de/u-boot/custodians/u-boot-sh.git master-riic
for you to fetch c
Hi Jonas,
On Sat, 2024-03-02 at 16:28 +0100, Jonas Karlman wrote:
> Hi Christopher,
>
> On 2024-03-02 15:34, Christopher Obbard wrote:
> > Some variants of the ROCK Pi 4 series contain an SPI flash chip, which can
> > be booted from. This patch enables support in U-Boot for building the
> > image
Hi Christopher,
On 2024-03-02 15:34, Christopher Obbard wrote:
> Some variants of the ROCK Pi 4 series contain an SPI flash chip, which can
> be booted from. This patch enables support in U-Boot for building the
> image for the SPI flash, support for booting U-Boot from the SPI flash
> chip and su
On Tue, Feb 20, 2024 at 01:11:38PM +0530, Love Kumar wrote:
> Add a test for reset commands which performs resetting of CPU, It does
> COLD reset by default and WARM reset with -w option.
>
> Signed-off-by: Love Kumar
> Reviewed-by: Tom Rini
> ---
> Changes in v2:
> - Set bootmode through boar
Hi Tom,
On Sat, Mar 2, 2024 at 12:31 AM Tom Rini wrote:
> On Sun, Feb 11, 2024 at 07:56:16PM +0100, Igor Opaniuk wrote:
>
> > From: Igor Opaniuk
> >
> > Drop old implementation and use hash_command() instead, as
> > how it's currently done for crc32 and sha1sum cmds.
> >
> > Test:
> > => md5sum
Drop old implementation and use hash_command() instead, as
how it's currently done for crc32 and sha1sum cmds.
Test:
=> md5sum 0x6000 0x200
md5 for 6000 ... 61ff ==> e6bbbe95f5b41996f4a9b9af7bbd4050
Signed-off-by: Igor Opaniuk
---
Changes in v2:
- Addressed build issues on some plat
When debugging the SPL boot order, the node ID of a device which hasn't
been found is printed but it can be quite hard to relate that to the
specific devicetree node. To aid debugging, print the node path as well as
the ID.
Original debug message:
board_boot_order: could not map node @73c to
Fix a simple spelling mistake in a comment.
Signed-off-by: Christopher Obbard
---
arch/arm/mach-rockchip/spl-boot-order.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-rockchip/spl-boot-order.c
b/arch/arm/mach-rockchip/spl-boot-order.c
index 2c39a215c10..e54
This series contains some trivial fixes.
The first patch fixes a spelling mistake in a comment.
The second patch adds the full devicetree node path (rather than just the
ID) in the debug message when a boot device can't be found.
This series may be found at [0].
[0]:
https://gitlab.collabora.c
Some variants of the ROCK Pi 4 series contain an SPI flash chip, which can
be booted from. This patch enables support in U-Boot for building the
image for the SPI flash, support for booting U-Boot from the SPI flash
chip and support in U-Boot for accessing the SPI flash using `sf` commands.
Not al
This series brings up and enables booting from the SPI flash present on
some variants of the ROCK Pi 4 in U-Boot.
The first patch syncs the ROCK Pi 4A devicetree from Linux, which contains
the SPI flash node.
The second patch enables support in U-Boot for the SPI flash chip and
booting U-Boot fro
To prepare for ROCK Pi 4A SPI flash support, sync the DTS from Linux which
includes an SPI flash node.
Kernel tag: v6.6-rc1
Kernel commits:
- eddf73029770 ("arm64: dts: rockchip: Enable internal SPI flash for ROCK \
Pi 4A/B/C")
Signed-off-by: Christopher Obbard
---
arch/arm/
On Sat, Mar 02, 2024 at 12:35:12PM +0800, hanyuan wrote:
> Hi Tom,
>
> Thanks for reviewing! I am not quite sure about the tests which
> you refer to. Is it the CI in the gitlab? I think this patch is simple
> and it doesn’t occur any errors during my work these days, thus I tested
> it manually
From: "Leon M. Busch-George"
The error message "bc: command not found" is easily missed since the
build continues.
bc is not a part of coreutils or base-devel. POSIX sh can also do the
calculation.
Signed-off-by: Leon M. Busch-George
---
Makefile | 4 ++--
1 file changed, 2 insertions(+), 2 de
No device tree in U-Boot or linux use the wrong spelling used in code.
Use correct property name as defined in dwc3 bindings.
Fixes: 062790f46131 ("usb: xhci-dwc3: Add USB2 PHY configuration")
Signed-off-by: Jonas Karlman
---
drivers/usb/host/xhci-dwc3.c | 2 +-
1 file changed, 1 insertion(+),
Hi Mattijs,
On 2024-03-01 16:18, Mattijs Korpershoek wrote:
> Hi Jonas, thank you for the patch.
>
> On lun., févr. 26, 2024 at 13:36, Jonas Karlman wrote:
>
>> On 2024-02-26 11:18, Marek Vasut wrote:
>>> On 2/26/24 10:50 AM, Jonas Karlman wrote:
On 2024-02-26 09:22, Marek Vasut wrote:
>>>
> From: Peter Robinson
> Date: Sat, 2 Mar 2024 11:20:31 +
>
> The EFI spec states that the ESP can be any of FAT12/16/32 but for
> compatibility doesn't necssarily require the partition to be the
> EFI partition table ID of 0xef. A number of arm devices will not
> find their firmware on a FA
The EFI spec states that the ESP can be any of FAT12/16/32 but for
compatibility doesn't necssarily require the partition to be the
EFI partition table ID of 0xef. A number of arm devices will not
find their firmware on a FAT partition with an ID of 0xef so also
allow the original FAT12/16/32 parti
> From: Peter Robinson
> Date: Sat, 2 Mar 2024 10:54:36 +
Hi Peter,
> The EFI spec states that the ESP can be any of FAT12/16/32 but for
> compatibility doesn't necssarily require the partition to be the
> EFI partition table ID of 0xef. A number of arm devices will not
> find their firmwar
The EFI spec states that the ESP can be any of FAT12/16/32 but for
compatibility doesn't necssarily require the partition to be the
EFI partition table ID of 0xef. A number of arm devices will not
find their firmware on a FAT partition with an ID of 0xef so also
allow the original FAT12/16/32 parti
On Sun, 25 Feb 2024 at 14:23, Mark Kettenis wrote:
>
> > From: Peter Robinson
> > Date: Sun, 25 Feb 2024 14:14:55 +
> >
> > The EFI spec states that the ESP can be any of FAT12/16/32 but for
> > compatibility doesn't necssarily require the partition to be the
> > EFI partition table ID of 0xe
On 27/02/2024 16:05, Marek Vasut wrote:
> Rename R-Mobile to Renesas all over the place because the chips are
> made by Renesas, while only a subset of them is from the R-Mobile line.
>
> Marek Vasut (19):
> ARM: renesas: Drop remnants of R8A7740 support
> ARM: renesas: Drop unused sh_sdhi.h
>
45 matches
Mail list logo
