Re: [PATCH v4 2/5] lib/lz4: update LZ4 decompressor module

[Jonathan Liu]

52,7 +454,7 @@ _copy_match:
>   while (op < copyEnd)
>   *op++ = *match++;
>   } else {
> - memcpy(op, match, mlen);
> + LZ4_memcpy(op, match, mlen);
>   }
>   op = copyEnd;
>   if (op == oend)
> @@ -466,7 +468,7 @@ _copy_match:
>   op[2] = match[2];
>   op[3] = match[3];
>   match += inc32table[offset];
> - memcpy(op + 4, match, 4);
> + LZ4_memcpy(op + 4, match, 4);
>   match -= dec64table[offset];
>   } else {
>   LZ4_copy8(op, match);
> diff --git a/lib/lz4_wrapper.c b/lib/lz4_wrapper.c
> index 4d48e7b0e8..e09c8d7057 100644
> --- a/lib/lz4_wrapper.c
> +++ b/lib/lz4_wrapper.c
> @@ -80,7 +80,7 @@ int ulz4fn(const void *src, size_t srcn, void *dst, size_t 
> *dstn)
>
>   if (block_header & LZ4F_BLOCKUNCOMPRESSED_FLAG) {
>   size_t size = min((ptrdiff_t)block_size, (ptrdiff_t)(end - out));
> - memcpy(out, in, size);
> + LZ4_memcpy(out, in, size);
>   out += size;
>   if (size < block_size) {
>   ret = -ENOBUFS; /* output overrun */
>
>
> Thanks,
>
> Jianan
>
> On 2024/5/26 16:06, Jonathan Liu wrote:
>
> Hi Gao,
>
> On Sat, 25 May 2024 at 02:52, Gao Xiang  wrote:
>
> Hi,
>
> On 2024/5/24 22:26, Jonathan Liu wrote:
>
> Hi Jianan,
>
> On Sat, 26 Feb 2022 at 18:05, Huang Jianan  wrote:
>
> Update the LZ4 compression module based on LZ4 v1.8.3 in order to
> use the newest LZ4_decompress_safe_partial() which can now decode
> exactly the nb of bytes requested.
>
> Signed-off-by: Huang Jianan 
>
> I noticed after this commit LZ4 decompression is slower.
> ulz4fn function call takes 1.209670 seconds with this commit.
> After reverting this commit, the ulz4fn function call takes 0.587032 seconds.
>
> I am decompressing a LZ4 compressed kernel (compressed with lz4 v1.9.4
> using -9 option for maximum compression) on RK3399.
>
> Any ideas why it is slower with this commit and how the performance
> regression can be fixed?
>
> Just the quick glance, I think the issue may be due to memcpy/memmove
> since it seems the main difference between these two codebases
> (I'm not sure which LZ4 version the old codebase was based on) and
> the new version mainly relies on memcpy/memmove instead of its own
> versions.
>
> Would you mind to check the assembly how memcpy/memset is generated
> on your platform?
>
> Here is the assembly (-mcpu=cortex-a72.cortex-a53 -march=armv8-a+crc+crypto):
> 0028220c :
> #if !CONFIG_IS_ENABLED(TINY_MEMSET)
> unsigned long cl = 0;
> int i;
>
> /* do it one word at a time (32 bits or 64 bits) while possible */
> if ( ((ulong)s & (sizeof(*sl) - 1)) == 0) {
>   28220c:   f2400803andsx3, x0, #0x7
>   282210:   540002c1b.ne282268   // b.any
> for (i = 0; i < sizeof(*sl); i++) {
> cl <<= 8;
> cl |= c & 0xff;
>   282214:   92401c26and x6, x1, #0xff
> unsigned long cl = 0;
>   282218:   d284mov x4, #0x0// #0
>   28221c:   52800105mov w5, #0x8// #8
> cl |= c & 0xff;
>   282220:   aa0420c4orr x4, x6, x4, lsl #8
> for (i = 0; i < sizeof(*sl); i++) {
>   282224:   710004a5subsw5, w5, #0x1
>   282228:   54c1b.ne282220   // b.any
> }
> while (count >= sizeof(*sl)) {
>   28222c:   cb030045sub x5, x2, x3
>   282230:   f1001cbfcmp x5, #0x7
>   282234:   54000148b.hi28225c   // b.pmore
>   282238:   d343fc43lsr x3, x2, #3
>   28223c:   928000e4mov x4, #0xfff8 // #-8
>   282240:   9b047c63mul x3, x3, x4
>   282244:   8b030042add x2, x2, x3
>   282248:   cb030003sub x3, x0, x3
> unsigned long *sl = (unsigned long *) s;
>   28224c:   d284mov x4, #0x0// #0
> count -= sizeof(*sl);
> }
> }
> #endif  /* fill 8 bits at a time */
> s8 = (char *)sl;
> while (count--)
>   282250:   eb04005fcmp x2, x4
>   282254:   54e1b.ne282270   // b.any
> *s8++ = c;
>
> return s;
> }
>   282258:   d65f03c0ret
> *sl++ = cl;
>   28225c:   f8236804str x4, [x0, x3]
> count -= sizeof(*sl);
>   282260:   91002063add x3, x3, #0x8
>   282264:   17f2b

Re: [PATCH v4 2/5] lib/lz4: update LZ4 decompressor module

[Jonathan Liu]

Hi Gao,

On Sat, 25 May 2024 at 02:52, Gao Xiang  wrote:
>
> Hi,
>
> On 2024/5/24 22:26, Jonathan Liu wrote:
> > Hi Jianan,
> >
> > On Sat, 26 Feb 2022 at 18:05, Huang Jianan  wrote:
> >>
> >> Update the LZ4 compression module based on LZ4 v1.8.3 in order to
> >> use the newest LZ4_decompress_safe_partial() which can now decode
> >> exactly the nb of bytes requested.
> >>
> >> Signed-off-by: Huang Jianan 
> >
> > I noticed after this commit LZ4 decompression is slower.
> > ulz4fn function call takes 1.209670 seconds with this commit.
> > After reverting this commit, the ulz4fn function call takes 0.587032 
> > seconds.
> >
> > I am decompressing a LZ4 compressed kernel (compressed with lz4 v1.9.4
> > using -9 option for maximum compression) on RK3399.
> >
> > Any ideas why it is slower with this commit and how the performance
> > regression can be fixed?
>
> Just the quick glance, I think the issue may be due to memcpy/memmove
> since it seems the main difference between these two codebases
> (I'm not sure which LZ4 version the old codebase was based on) and
> the new version mainly relies on memcpy/memmove instead of its own
> versions.
>

> Would you mind to check the assembly how memcpy/memset is generated
> on your platform?

Here is the assembly (-mcpu=cortex-a72.cortex-a53 -march=armv8-a+crc+crypto):
0028220c :
#if !CONFIG_IS_ENABLED(TINY_MEMSET)
unsigned long cl = 0;
int i;

/* do it one word at a time (32 bits or 64 bits) while possible */
if ( ((ulong)s & (sizeof(*sl) - 1)) == 0) {
  28220c:   f2400803andsx3, x0, #0x7
  282210:   540002c1b.ne282268   // b.any
for (i = 0; i < sizeof(*sl); i++) {
cl <<= 8;
cl |= c & 0xff;
  282214:   92401c26and x6, x1, #0xff
unsigned long cl = 0;
  282218:   d284mov x4, #0x0// #0
  28221c:   52800105mov w5, #0x8// #8
cl |= c & 0xff;
  282220:   aa0420c4orr x4, x6, x4, lsl #8
for (i = 0; i < sizeof(*sl); i++) {
  282224:   710004a5subsw5, w5, #0x1
  282228:   54c1b.ne282220   // b.any
}
while (count >= sizeof(*sl)) {
  28222c:   cb030045sub x5, x2, x3
  282230:   f1001cbfcmp x5, #0x7
  282234:   54000148b.hi28225c   // b.pmore
  282238:   d343fc43lsr x3, x2, #3
  28223c:   928000e4mov x4, #0xfff8 // #-8
  282240:   9b047c63mul x3, x3, x4
  282244:   8b030042add x2, x2, x3
  282248:   cb030003sub x3, x0, x3
unsigned long *sl = (unsigned long *) s;
  28224c:   d284mov x4, #0x0// #0
count -= sizeof(*sl);
}
}
#endif  /* fill 8 bits at a time */
s8 = (char *)sl;
while (count--)
  282250:   eb04005fcmp x2, x4
  282254:   54e1b.ne282270   // b.any
*s8++ = c;

return s;
}
  282258:   d65f03c0ret
*sl++ = cl;
  28225c:   f8236804str x4, [x0, x3]
count -= sizeof(*sl);
  282260:   91002063add x3, x3, #0x8
  282264:   17f2b   28222c 
unsigned long *sl = (unsigned long *) s;
  282268:   aa0003e3mov x3, x0
  28226c:   17f8b   28224c 
*s8++ = c;
  282270:   38246861strbw1, [x3, x4]
  282274:   91000484add x4, x4, #0x1
  282278:   17f6b   282250 

0028227c :
__used void * memcpy(void *dest, const void *src, size_t count)
{
unsigned long *dl = (unsigned long *)dest, *sl = (unsigned long *)src;
char *d8, *s8;

if (src == dest)
  28227c:   eb01001fcmp x0, x1
  282280:   54000100b.eq2822a0   // b.none
return dest;

/* while all data is aligned (common case), copy a word at a time */
if ( (((ulong)dest | (ulong)src) & (sizeof(*dl) - 1)) == 0) {
  282284:   aa010003orr x3, x0, x1
  282288:   f2400863andsx3, x3, #0x7
  28228c:   54000120b.eq2822b0   // b.none
  282290:   aa0003e4mov x4, x0
  282294:   d283mov x3, #0x0// #0
}
}
/* copy the reset one byte at a time */
d8 = (char *)dl;
s8 = (char *)sl;
while (count--)
  282298:  

[PATCH] sandbox: enable support for the unlz4 command

[Jonathan Liu]

This does not work with sandbox at present. Fix it up to use map_sysmem()
to convert an address to a pointer.

Signed-off-by: Jonathan Liu 
---
 cmd/unlz4.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/cmd/unlz4.c b/cmd/unlz4.c
index 5f20838e899..4b66794a72c 100644
--- a/cmd/unlz4.c
+++ b/cmd/unlz4.c
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 static int do_unlz4(struct cmd_tbl *cmdtp, int flag, int argc,
@@ -26,7 +27,7 @@ static int do_unlz4(struct cmd_tbl *cmdtp, int flag, int argc,
return CMD_RET_USAGE;
}
 
-   ret = ulz4fn((void *)src, src_len, (void *)dst, _len);
+   ret = ulz4fn(map_sysmem(src, 0), src_len, map_sysmem(dst, dst_len), 
_len);
if (ret) {
printf("Uncompressed err :%d\n", ret);
return 1;
-- 
2.44.0

Re: [PATCH v4 2/5] lib/lz4: update LZ4 decompressor module

[Jonathan Liu]

Hi Jianan,

On Sat, 26 Feb 2022 at 18:05, Huang Jianan  wrote:
>
> Update the LZ4 compression module based on LZ4 v1.8.3 in order to
> use the newest LZ4_decompress_safe_partial() which can now decode
> exactly the nb of bytes requested.
>
> Signed-off-by: Huang Jianan 

I noticed after this commit LZ4 decompression is slower.
ulz4fn function call takes 1.209670 seconds with this commit.
After reverting this commit, the ulz4fn function call takes 0.587032 seconds.

I am decompressing a LZ4 compressed kernel (compressed with lz4 v1.9.4
using -9 option for maximum compression) on RK3399.

Any ideas why it is slower with this commit and how the performance
regression can be fixed?

Thanks.

Regards,
Jonathan

Re: rk3399 issue: no DMA in Linux with mainline TF-A and U-Boot SPL

[Jonathan Liu]

Hi Kever,

I also see this issue when switching between Rockchip ATF and Upstream ATF.

Versions:
Rockchip DDR Blob - rk3399_ddr_800MHz_v1.30.bin
Rockchip Miniloader - rk3399_miniloader_v1.30.bin
Rockchip ATF - rk3399_bl31_v1.36.elf
Upstream ATF - git://git.trustedfirmware.org/TF-A/trusted-firmware-a.git,
git tag v2.8.0, with RK3399_BAUDRATE changed from 115200 to 150 in
plat/rockchip/rk3399/rk3399_def.h
U-Boot - git://git.denx.de/u-boot.git, git tag v2022.01

Results:
Rockchip DDR Blob + Rockchip Miniloader + Rockchip ATF + U-Boot = DMA working
  dma-pl330 ff6d.dma-controller: Loaded driver for PL330 DMAC-241330
  dma-pl330 ff6d.dma-controller:   DBUFF-32x8bytes Num_Chans-6
Num_Peri-12 Num_Events-12
  dma-pl330 ff6e.dma-controller: Loaded driver for PL330 DMAC-241330
  dma-pl330 ff6e.dma-controller:   DBUFF-128x8bytes
Num_Chans-8 Num_Peri-20 Num_Events-16
Rockchip DDR Blob + Rockchip Miniloader + Upstream ATF + U-Boot = DMA
not working
  OF: amba_device_add() failed (-19) for /bus/dma-controller@ff6d
  OF: amba_device_add() failed (-19) for /bus/dma-controller@ff6e

I can't check the Rockchip ATF source code as it isn't available.
Any idea what is different between Rockchip ATF and Upstream ATF for
DMA to work properly?

Regards,
Jonathan

On Mon, 3 Apr 2023 at 18:38, Kever Yang  wrote:
>
> Hi Christoph,
>
>  The ARM PL330 DMA driver in kernel only relate to:
>
> - DTS kernel used, can be check in /proc/device-tree/
>
> - kernel driver which should mach the compatible name.
>
> This driver should has nothing to do with U-Boot SPL or TF-A, because we
> don't have any special setting for PL330 in loader stage.
>
>
> Thanks,
>
> - Kever
>
> On 2023/4/3 03:01, Christoph Fritz wrote:
> > Hello Kever,
> >
> >   on a rk3399, booting current U-Boot SPL with mainline TF-A leads to
> > missing DMA (and no sound) on Linux.
> >
> > However, when using rockchip its so called mini-loader
> > (rk3399_miniloader_v1.26.bin) and their BL31 (rk3399_bl31_v1.35.elf) to
> > boot, DMA works perfectly fine.
> >
> > Tested on a custom rk3399 board and on ROCK Pi4.
> >
> > Attached to this mail are two boot logs with some debug prints:
> >
> >   - good_amba_log.txt (DMA works)
> >   - no_amba_log.txt (no DMA device)
> >
> > The main difference I can spot between the two logs is that on Linux
> > (drivers/amba/bus.c) AMBA_CID (0xb105f00d) cannot be found. Instead,
> > only some CORESIGHT_CIDs (presumably for debugging) and four 0x
> > CIDs are detected.
> >
> > As a result, the "PL330 DMAC-241330" driver does not load. My theory is
> > that DMA needs to be allowed somewhere in the undocumented syscon-
> > registers, similar to what U-Boot is already doing for eMMC in
> > arch_cpu_init() (arch/arm/mach-rockchip/rk3399/rk3399.c).
> >
> > Any ideas?
> >
> > Or maybe I'm just missing some configuration?
> >
> > Since multiple software projects are involved (TF-A, OP-TEE, U-Boot,
> > Linux), I Cc'ed a bit.
> >
> >   Thanks
> >-- Christoph

Re: Loading from squashfs with zstd compression slower than ext4

[Jonathan Liu]

Hi Tom,

On Fri, 2 Jun 2023 at 03:09, Tom Rini  wrote:
>
> On Thu, Jun 01, 2023 at 02:10:21PM +1000, Jonathan Liu wrote:
> > Hi Simon,
> >
> > On Thu, 1 Jun 2023 at 11:27, Jonathan Liu  wrote:
> > >
> > > Hi Simon,
> > >
> > > On Thu, 1 Jun 2023 at 03:13, Simon Glass  wrote:
> > > >
> > > > Hi Jonathan,
> > > >
> > > > On Wed, 31 May 2023 at 06:52, Jonathan Liu  wrote:
> > > > >
> > > > > Hi All,
> > > > >
> > > > > I noticed that loading from squashfs with zstd compression is
> > > > > significantly slower than ext4 on RK3399 using U-Boot 2022.01. The
> > > > > filesystem is located on eMMC.
> > > > >
> > > > > I have CONFIG_BLOCK_CACHE=y in .config and am using the generic load 
> > > > > command.
> > > > >
> > > > > ext4:
> > > > > 15682578 bytes read in 366 ms (40.9 MiB/s)
> > > > >
> > > > > SquashFS with zstd compression:
> > > > > 15685001 bytes read in 2339 ms (6.4 MiB/s)
> > > > >
> > > > > Any suggestions on how to speed up loading from SquashFS with zstd 
> > > > > compression?
> > >
> > > >
> > > > Could it just be that zstd is slow? Have you tried lz4?
> > > >
> >
> > >
> > > I tried LZ4 but get "Error: unknown compression type."
> > > It seems the SquashFS decompressor only supports lzo, gzip and zstd -
> > > https://source.denx.de/u-boot/u-boot/-/blob/master/fs/squashfs/sqfs_decompressor.c
> > >
> > > ext4:
> > > 15682578 bytes read in 366 ms (40.9 MiB/s)
> > >
> > > SquashFS with lzo compression (~129 MiB squashfs):
> > > 15686657 bytes read in 1032 ms (14.5 MiB/s)
> > >
> > > SquashFS with gzip compression (~116 MiB squashfs):
> > > 15686657 bytes read in 1494 ms (10 MiB/s)
> > >
> > > SquashFS with zstd compression (~107 MiB squashfs):
> > > 15685001 bytes read in 2339 ms (6.4 MiB/s)
> >
> > SquashFS with zstd compression seems to be even slower after zstd was
> > updated to 1.5.2 in U-Boot.
> >
> > SquashFS with zstd compression (~107 MiB squashfs), with zstd 1.5.2
> > update cherry-picked from
> > https://source.denx.de/u-boot/u-boot/-/commit/4b9b25d943ff95c7421cab261333fc29852fe3b1:
> > 15686657 bytes read in 2726 ms (5.5 MiB/s)

>
> OK, so is zstd supposed to be fast decompression? Are there some
> optimizations in the library we could be enabling (or at least asking to
> enable via Kconfig) but aren't?
>

CONFIG_ZSTD_LIB_MINIFY enabled (default)
15686657 bytes read in 2707 ms (5.5 MiB/s)

CONFIG_ZSTD_LIB_MINIFY disabled
15686657 bytes read in 2342 ms (6.4 MiB/s)

It seems the zstd decompression performance regression after update to
zstd 1.5.2 is caused by CONFIG_ZSTD_LIB_MINIFY being enabled by
default.

Regards,
Jonathan

Re: Loading from squashfs with zstd compression slower than ext4

[Jonathan Liu]

Hi Simon,

On Thu, 1 Jun 2023 at 14:10, Jonathan Liu  wrote:
> On Thu, 1 Jun 2023 at 11:27, Jonathan Liu  wrote:
> > On Thu, 1 Jun 2023 at 03:13, Simon Glass  wrote:
> > > On Wed, 31 May 2023 at 06:52, Jonathan Liu  wrote:
> > > >
> > > > Hi All,
> > > >
> > > > I noticed that loading from squashfs with zstd compression is
> > > > significantly slower than ext4 on RK3399 using U-Boot 2022.01. The
> > > > filesystem is located on eMMC.
> > > >
> > > > I have CONFIG_BLOCK_CACHE=y in .config and am using the generic load 
> > > > command.
> > > >
> > > > ext4:
> > > > 15682578 bytes read in 366 ms (40.9 MiB/s)
> > > >
> > > > SquashFS with zstd compression:
> > > > 15685001 bytes read in 2339 ms (6.4 MiB/s)
> > > >
> > > > Any suggestions on how to speed up loading from SquashFS with zstd 
> > > > compression?
> >
> > >
> > > Could it just be that zstd is slow? Have you tried lz4?
> > >
>
> >
> > I tried LZ4 but get "Error: unknown compression type."
> > It seems the SquashFS decompressor only supports lzo, gzip and zstd -
> > https://source.denx.de/u-boot/u-boot/-/blob/master/fs/squashfs/sqfs_decompressor.c
> >
> > ext4:
> > 15682578 bytes read in 366 ms (40.9 MiB/s)
> >
> > SquashFS with lzo compression (~129 MiB squashfs):
> > 15686657 bytes read in 1032 ms (14.5 MiB/s)
> >
> > SquashFS with gzip compression (~116 MiB squashfs):
> > 15686657 bytes read in 1494 ms (10 MiB/s)
> >
> > SquashFS with zstd compression (~107 MiB squashfs):
> > 15685001 bytes read in 2339 ms (6.4 MiB/s)
>
> SquashFS with zstd compression seems to be even slower after zstd was
> updated to 1.5.2 in U-Boot.
>
> SquashFS with zstd compression (~107 MiB squashfs), with zstd 1.5.2
> update cherry-picked from
> https://source.denx.de/u-boot/u-boot/-/commit/4b9b25d943ff95c7421cab261333fc29852fe3b1:
> 15686657 bytes read in 2726 ms (5.5 MiB/s)

If I use unsquashfs on the same board to decompress the same file
using a single processor, it is much faster:
# sync; echo 3 > /proc/sys/vm/drop_caches; time unsquashfs -p 1
/dev/mmcblk1p1 /boot/test-file
Parallel unsquashfs: Using 1 processor
1 inodes (120 blocks) to write

[=|]
120/120 100%

created 1 files
created 2 directories
created 0 symlinks
created 0 devices
created 0 fifos
real0m 0.19s
user0m 0.16s
sys 0m 0.12s

Regards,
Jonathan

Re: Loading from squashfs with zstd compression slower than ext4

[Jonathan Liu]

Hi Simon,

On Thu, 1 Jun 2023 at 11:27, Jonathan Liu  wrote:
>
> Hi Simon,
>
> On Thu, 1 Jun 2023 at 03:13, Simon Glass  wrote:
> >
> > Hi Jonathan,
> >
> > On Wed, 31 May 2023 at 06:52, Jonathan Liu  wrote:
> > >
> > > Hi All,
> > >
> > > I noticed that loading from squashfs with zstd compression is
> > > significantly slower than ext4 on RK3399 using U-Boot 2022.01. The
> > > filesystem is located on eMMC.
> > >
> > > I have CONFIG_BLOCK_CACHE=y in .config and am using the generic load 
> > > command.
> > >
> > > ext4:
> > > 15682578 bytes read in 366 ms (40.9 MiB/s)
> > >
> > > SquashFS with zstd compression:
> > > 15685001 bytes read in 2339 ms (6.4 MiB/s)
> > >
> > > Any suggestions on how to speed up loading from SquashFS with zstd 
> > > compression?
>
> >
> > Could it just be that zstd is slow? Have you tried lz4?
> >

>
> I tried LZ4 but get "Error: unknown compression type."
> It seems the SquashFS decompressor only supports lzo, gzip and zstd -
> https://source.denx.de/u-boot/u-boot/-/blob/master/fs/squashfs/sqfs_decompressor.c
>
> ext4:
> 15682578 bytes read in 366 ms (40.9 MiB/s)
>
> SquashFS with lzo compression (~129 MiB squashfs):
> 15686657 bytes read in 1032 ms (14.5 MiB/s)
>
> SquashFS with gzip compression (~116 MiB squashfs):
> 15686657 bytes read in 1494 ms (10 MiB/s)
>
> SquashFS with zstd compression (~107 MiB squashfs):
> 15685001 bytes read in 2339 ms (6.4 MiB/s)

SquashFS with zstd compression seems to be even slower after zstd was
updated to 1.5.2 in U-Boot.

SquashFS with zstd compression (~107 MiB squashfs), with zstd 1.5.2
update cherry-picked from
https://source.denx.de/u-boot/u-boot/-/commit/4b9b25d943ff95c7421cab261333fc29852fe3b1:
15686657 bytes read in 2726 ms (5.5 MiB/s)

Regards,
Jonathan

Re: Loading from squashfs with zstd compression slower than ext4

[Jonathan Liu]

Hi Simon,

On Thu, 1 Jun 2023 at 03:13, Simon Glass  wrote:
>
> Hi Jonathan,
>
> On Wed, 31 May 2023 at 06:52, Jonathan Liu  wrote:
> >
> > Hi All,
> >
> > I noticed that loading from squashfs with zstd compression is
> > significantly slower than ext4 on RK3399 using U-Boot 2022.01. The
> > filesystem is located on eMMC.
> >
> > I have CONFIG_BLOCK_CACHE=y in .config and am using the generic load 
> > command.
> >
> > ext4:
> > 15682578 bytes read in 366 ms (40.9 MiB/s)
> >
> > SquashFS with zstd compression:
> > 15685001 bytes read in 2339 ms (6.4 MiB/s)
> >
> > Any suggestions on how to speed up loading from SquashFS with zstd 
> > compression?

>
> Could it just be that zstd is slow? Have you tried lz4?
>

I tried LZ4 but get "Error: unknown compression type."
It seems the SquashFS decompressor only supports lzo, gzip and zstd -
https://source.denx.de/u-boot/u-boot/-/blob/master/fs/squashfs/sqfs_decompressor.c

ext4:
15682578 bytes read in 366 ms (40.9 MiB/s)

SquashFS with lzo compression (~129 MiB squashfs):
15686657 bytes read in 1032 ms (14.5 MiB/s)

SquashFS with gzip compression (~116 MiB squashfs):
15686657 bytes read in 1494 ms (10 MiB/s)

SquashFS with zstd compression (~107 MiB squashfs):
15685001 bytes read in 2339 ms (6.4 MiB/s)

Regards,
Jonathan

Loading from squashfs with zstd compression slower than ext4

[Jonathan Liu]

Hi All,

I noticed that loading from squashfs with zstd compression is
significantly slower than ext4 on RK3399 using U-Boot 2022.01. The
filesystem is located on eMMC.

I have CONFIG_BLOCK_CACHE=y in .config and am using the generic load command.

ext4:
15682578 bytes read in 366 ms (40.9 MiB/s)

SquashFS with zstd compression:
15685001 bytes read in 2339 ms (6.4 MiB/s)

Any suggestions on how to speed up loading from SquashFS with zstd compression?

Thanks.

Regards,
Jonathan

Re: BTRFS Support btrload, btrls

[Jonathan Liu]

Hi Ottinger,

Perhaps you can enable CONFIG_CMD_FS_GENERIC=y in your config and try
to use the generic commands - size, load, save, ls, ln, fstype,
fstypes?

Regards,
Jonathan

On Tue, 30 May 2023 at 22:07, Ottinger Georg  wrote:
>
>
> Hi Everybody,
>
> I am currently evaluating filesystems that can be used reliable on eMMC 
> storage, which support transparent compression.
>
> I see that U-Boot supports btrfs. But I don't understand how to load for 
> example a kernel image from the fs, I was expecting 'btrload' as an analog to 
> 'ext4load' or 'fatload'.
>
> Is there a reason why this commands are not implemented?
>
> When I do patch the file cmd/btfs.c to add 'btrload' I do get a working 
> U-Boot capable of loading DT and kernal image from btrfs.
>
> '''
> char subvolname[1];
>
> int do_btr_fsload(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
> {
>
> subvolname[0] = '\0';
>
> return do_load(cmdtp, flag, argc, argv, FS_TYPE_BTRFS);
> }
>
>
> U_BOOT_CMD(
> btrload,7,  0,  do_btr_fsload,
> "load binary file from a btr filesystem",
> " []   \n"
> "- Load binary file 'filename' from 'dev' on 'interface'\n"
> "  to address 'addr' from better filesystem.\n"
> "  the load stops on end of file.\n"
> "  All numeric parameters are assumed to be hex."
> );
> '''
>
> Are there any known stability issues, why 'btrload' and 'btrfs' are not 
> included in the current U-Boot?
> Or is there an alternative to 'btrload' to load a kernelimage from fs to ram?
>
> thanks,
> Georg
>
>
> Georg Ottinger
>
> Software Engineer
>
> RESEARCH & DEVELOPMENT
>
> ABATEC GmbH
>
> [https://abatec.at/email/phone.jpg]
>
> +43767227720532
>
> [https://abatec.at/email/email.jpg]
>
> g.ottin...@abatec.at
>
> [https://abatec.at/email/site.jpg]
>
> www.abatec.at
>
> [https://abatec.at/email/location.jpg]
>
> Oberregauer Straße 48, 4844 Regau
>
> [cid:1d2b374d-7ca8-4b52-8b3c-319d1b53c9aa]
>
>
>
> UID-Nr.: ATU67696059  Firmenbuchnummer: FN 390305d  Firmenbuchgericht: Wels
>

[PATCH v2] sysreset: gpio: fix gpio_reboot_request return value

[Jonathan Liu]

It should return -EINPROGRESS if successful otherwise sysreset-uclass
will continue to the next sysreset device.

Signed-off-by: Jonathan Liu 
Reviewed-by: Simon Glass 
---
 drivers/sysreset/sysreset_gpio.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/sysreset/sysreset_gpio.c b/drivers/sysreset/sysreset_gpio.c
index dfca10ccc8..de42b59354 100644
--- a/drivers/sysreset/sysreset_gpio.c
+++ b/drivers/sysreset/sysreset_gpio.c
@@ -17,6 +17,7 @@ struct gpio_reboot_priv {
 static int gpio_reboot_request(struct udevice *dev, enum sysreset_t type)
 {
struct gpio_reboot_priv *priv = dev_get_priv(dev);
+   int ret;
 
/*
 * When debug log is enabled please make sure that chars won't end up
@@ -26,7 +27,11 @@ static int gpio_reboot_request(struct udevice *dev, enum 
sysreset_t type)
debug("GPIO reset\n");
 
/* Writing 1 respects polarity (active high/low) based on gpio->flags */
-   return dm_gpio_set_value(>gpio, 1);
+   ret = dm_gpio_set_value(>gpio, 1);
+   if (ret < 0)
+   return ret;
+
+   return -EINPROGRESS;
 }
 
 static struct sysreset_ops gpio_reboot_ops = {
-- 
2.40.0

[PATCH] sysreset: gpio: fix gpio_reboot_request return value

[Jonathan Liu]

It should return -EINPROGRESS if successful otherwise sysreset-uclass
will continue to the next sysreset device.

Signed-off-by: Jonathan Liu 
---
 drivers/sysreset/sysreset_gpio.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/sysreset/sysreset_gpio.c b/drivers/sysreset/sysreset_gpio.c
index dfca10ccc8..d12e491ffe 100644
--- a/drivers/sysreset/sysreset_gpio.c
+++ b/drivers/sysreset/sysreset_gpio.c
@@ -17,6 +17,7 @@ struct gpio_reboot_priv {
 static int gpio_reboot_request(struct udevice *dev, enum sysreset_t type)
 {
struct gpio_reboot_priv *priv = dev_get_priv(dev);
+   int r;
 
/*
 * When debug log is enabled please make sure that chars won't end up
@@ -26,7 +27,11 @@ static int gpio_reboot_request(struct udevice *dev, enum 
sysreset_t type)
debug("GPIO reset\n");
 
/* Writing 1 respects polarity (active high/low) based on gpio->flags */
-   return dm_gpio_set_value(>gpio, 1);
+   r = dm_gpio_set_value(>gpio, 1);
+   if (r < 0)
+   return r;
+
+   return -EINPROGRESS;
 }
 
 static struct sysreset_ops gpio_reboot_ops = {
-- 
2.40.0

[PATCH] ram: rk3399: add missing high row detection

[Jonathan Liu]

For 2 GB LPDDR4 single-rank RAM with 16 rows, the Rockchip ddr init bin
prints:
"Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=2048MB"

U-Boot TPL prints:
"BW=32 Col=10 Bk=8 CS0 Row=16/15 CS=1 Die BW=16 Size=2048MB"

Add missing high row detection so that U-Boot TPL prints Row=16, same as
the Rockchip ddr init bin:
"BW=32 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=2048MB"

Signed-off-by: Jonathan Liu 
---
 drivers/ram/rockchip/sdram_rk3399.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/ram/rockchip/sdram_rk3399.c 
b/drivers/ram/rockchip/sdram_rk3399.c
index b1fea04e84..b597448203 100644
--- a/drivers/ram/rockchip/sdram_rk3399.c
+++ b/drivers/ram/rockchip/sdram_rk3399.c
@@ -2749,6 +2749,8 @@ static u64 dram_detect_cap(struct dram_info *dram,
/* detect cs1 row */
sdram_detect_cs1_row(cap_info, params->base.dramtype);
 
+   sdram_detect_high_row(cap_info);
+
/* detect die bw */
sdram_detect_dbw(cap_info, params->base.dramtype);
 
-- 
2.40.0

Re: [U-Boot] [linux-sunxi] [PATCH] ARM: HYP/non-sec: Don't enable ARMV7_LPAE for old sunxi kernels

[Jonathan Liu]

Hi Jagan,

On Fri., 22 Mar. 2019 at 4:05 am, Jagan Teki 
wrote:

> On Tue, Mar 19, 2019 at 11:09 AM Jonathan Liu  wrote:
> >
> > Old sunxi kernels fail to boot with ARMV7_LPAE enabled.
>
> Any idea why? I don't have relevant stuff with to test this.
>
I don't know why. It failed to boot linux-sunxi 3.4.104 kernel on A20
OLinuXino-MICRO after updating from 2018.07 to 2018.09-rc1 and would hang
at "Starting kernel...".

I bisected the issue to:
https://git.denx.de/?p=u-boot.git;a=commit;h=d32e86bde8a31a49cf4a9b233ad91ecdfc96ba2a

No problems booting mainline kernel.

Thanks.

Regards,
Jonathan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] ARM: HYP/non-sec: Don't enable ARMV7_LPAE for old sunxi kernels

[Jonathan Liu]

Old sunxi kernels fail to boot with ARMV7_LPAE enabled.

Signed-off-by: Jonathan Liu 
---
 arch/arm/cpu/armv7/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/cpu/armv7/Kconfig b/arch/arm/cpu/armv7/Kconfig
index 73d57a2aae..cdb7e402b4 100644
--- a/arch/arm/cpu/armv7/Kconfig
+++ b/arch/arm/cpu/armv7/Kconfig
@@ -53,7 +53,7 @@ config ARMV7_PSCI_NR_CPUS
 config ARMV7_LPAE
bool "Use LPAE page table format" if EXPERT
depends on CPU_V7A
-   default y if ARMV7_VIRT
+   default y if ARMV7_VIRT && !OLD_SUNXI_KERNEL_COMPAT
---help---
Say Y here to use the long descriptor page table format. This is
required if U-Boot runs in HYP mode.
-- 
2.21.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [linux-sunxi] [PATCH 5/5] sunxi: doc: Add basic fastboot example

[Jonathan Liu]

Hi Priit,

On Wed, 24 Oct 2018 at 04:21, Priit Laes  wrote:
>
> From: Priit Laes 
>
> Signed-off-by: Priit Laes 
> ---
>  board/sunxi/README.fastboot | 98 ++-
>  1 file changed, 98 insertions(+)
>  create mode 100644 board/sunxi/README.fastboot
>
> diff --git a/board/sunxi/README.fastboot b/board/sunxi/README.fastboot
> new file mode 100644
> index 000..470fa6f
> --- /dev/null
> +++ b/board/sunxi/README.fastboot
> @@ -0,0 +1,98 @@
> +Using fastboot on sunxi devices
> +===
> +

> +Fastboot is a diagnostic protocol, primarily used to modify the
> +filesystems on the flash device via USB or UDP. It requires that
> +the device is started in a boot loader or Seconday Boot Loader mode.

"Seconday" -> "Secondary"

> +
> +This document currently walks through an installation with a device
> +with eMMC storage.
> +
> +Prerequisites
> +-
> +
> +* fastboot binaries installed on client machine
> +* sunxi-tools installed on client machine (optional)
> +* u-boot tools (mkimage)
> +* u-boot binaries for the target sunxi device
> +* filesystem images
> +  * root file system containing operating system
> +  * vfat file system
> +* Sunxi device connected to client via OTG port
> +
> +Getting your device into Fastboot mode
> +--
> +
> +To enter into fastboot mode, execute the `fastboot` command in
> +U-Boot:
> +
> +$ fastboot usb 0
> +
> +On the client machine, you can check whether the device is visible
> +using the `fastboot devices` command. And for fun, you can also
> +fetch the bootloader version using the fastboot protocol:
> +
> +$ fastboot devices
> +1234567890abcdef   fastboot
> +$ fastboot getvar bootloader-version
> +bootloader-version: U-Boot 2018.11-rc2-00033-ge3beca3a2f
> +finished. total time: 0.000s
> +
> +Preparing the device for flashing
> +-
> +
> +Now that the device is in the fastboot mode, we can continue with
> +creating the partitions on the device. By default, u-boot for sunxi
> +defines following partitions:
> +
> +* loader1 - partition for secondary program loader
> +* loader2 - partition for u-boot
> +* esp - EFI system partition, also used for u-boot to look up boot.scr
> +* system  - Root partition for system
> +
> +These partitions have also assigned GUID's according to Discoverable
> +Partitions Specification [1], to enable automatic discovery of partitions
> +and their mountpoints.
> +
> +You can start by formatting the internal storage by executing the
> +`fastboot oem format` command from client:
> +
> +$ fastboot oem format
> +
> +This equivalent to running the `gpt write mmc 1 $partitions` from u-boot.
> +
> +[1] 
> https://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/
> +
> +Flashing the device
> +---
> +
> +Now that we have the partitions created, all that is left for us
> +is to flash the data.
> +

> +`loader1` is used for storing the Seconday Program Loader, in our
> +case, it is the `spl/sunxi-spl.bin` in the u-boot directory:

"Seconday" -> "Secondary"

> +
> +$ fastboot flash loader1 spl/sunxi-spl.bin
> +
> +`loader2` is for storing the u-boot binary. `u-boot.img` in the
> +u-boot source directory:
> +
> +$ fastboot flash loader2 u-boot.img
> +
> +`esp` partition (EFI System Partition) can be kept empty, although
> +if it is VFAT partition, u-boot automatically looks up the `boot.scr`
> +file for device-specific configuration. (You can create empty vfat
> +partition by `fallocate -l 32M esp.img && mkfs.vfat esp.img`)
> +
> +$ fastboot flash esp esp.img
> +
> +`system` partition is where the operating system resides. Creating
> +that is left as an exercise to the reader.
> +
> +$ fastboot flash system system.img
> +
> +Now, if everything has been properly set up (aka proper kernel
> +with machine-specific dtb installed on system.img, and boot.scr
> +on esp partition), you can reboot the machine:
> +
> +$ fastboot reboot
> --
> git-series 0.9.1
>
> --
> You received this message because you are subscribed to the Google Groups 
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

Regards,
Jonathan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [linux-sunxi] [PATCHv6 12/28] net: Add ability to set MAC address via EEPROM

[Jonathan Liu]

Hi Olliver,

On 15 May 2017 at 18:02, Olliver Schinagl  wrote:
> This patch allows Kconfig to enable and set parameters to make it
> possible to read the MAC address from an EEPROM. The net core layer then
> uses this information to read MAC addresses from this EEPROM.
>
> Besides the various tuneables as to how to access the eeprom (bus,
> address, addressing mode/length, 2 configurable that are EEPROM generic
> (e.g. SPI or some other form of access) which are:
>
> NET_ETHADDR_EEPROM_OFFSET, indicating where in the EEPROM the start of
> the MAC address is. The default is 8 allowing for 8 bytes before the MAC
> for other purposes (header MAGIC for example).

Note that Olimex has started to write their own data to the EEPROM for
their A20 boards:
https://github.com/OLIMEX/OLINUXINO/blob/master/SOFTWARE/A20/A20-eeprom-contents/Olimex-A20-EEPROM-september-2017.pdf

>
> NET_ETHADDR_EEPROM_CRC8, indicating the MAC is appended with a CRC8-CCIT
> checksum that should be verified.
>
> Currently only I2C eeproms have been tested and thus only those options
> are available, but shouldn't be a limit. NET_ETHADDR_EEPROM_SPI can be
> just as created and added.
>
> The code currently first checks if there is a non-zero MAC address in
> the eeprom. If that fails to be the case, the read_rom_hwaddr can be
> used by a board to supply the MAC in other ways.
>
> If both these fails, the other code is still in place to query the
> environent, which then can be used to override the hardware supplied
> data.
>
> Signed-off-by: Olliver Schinagl 

Regards,
Jonathan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2] rpi: passthrough of the firmware provided FDT blob

[Jonathan Liu]

Hi Stephen,

On 8 November 2016 at 14:14, Stephen Warren  wrote:
> On 11/07/2016 07:44 AM, Cédric Schieli wrote:
>>
>> Raspberry firmware used to pass a FDT blob at a fixed address (0x100),
>> but this is not true anymore. The address now depends on both the
>> memory size and the blob size [1].
>>
>> If one wants to passthrough this FDT blob to the kernel, the most
>> reliable way is to save its address from the r2/x0 register in the
>> U-Boot entry point and expose it in a environment variable for
>> further processing.
>>
>> This patch just does this:
>> - save the provided address in the global variable fw_dtb_pointer
>> - expose it in ${fdt_addr} if it points to a a valid FDT blob
>>
>> There are many different ways to use it. One can, for example, use
>> the following script which will extract from the tree the command
>> line built by the firmware, then hand over the blob to a previously
>> loaded kernel:
>>
>> if fdt addr ${fdt_addr}
>> then
>> fdt get value bootargs /chosen bootargs
>> bootz ${kernel_addr_r} - ${fdt_addr}
>> fi
>
>
> FWIW, I'd just hard-code the commands into any script that I wrote, and
> avoid the if test completely. If the FW doesn't pass a DTB, the system isn't
> going to boot correctly anyway, and I'd only use this custom script in a
> situation I know that it'd work.
>
>> Alternatively, users relying on sysboot/pxe can simply omit any FDT
>> statement in their extlinux.conf file, U-Boot will automagically pick
>> ${fdt_addr} and pass it to the kernel.
>>
>> Please note that for this to work the U-Boot binary must be tagged
>> with a recent version of the mkknlimg script found in the Rasperry
>> Fundation's kernel tree:
>>
>> /scripts/mkknlimg --dtok /u-boot.bin /boot/u-boot.bin
>>
>> [1] https://www.raspberrypi.org/forums//viewtopic.php?f=107=134018
>
>
> I believe the very latest firmware has been fixed to default to DTB rather
> than ATAGs, since essentially nothing uses ATAGs any more. At least, Phil
> mentioned that sometime; I haven't tracked the status of that change or
> tested it.
>
>> diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
>
>
>> +#ifdef CONFIG_ARM64
>> +void save_boot_params(unsigned long dtb)
>> +#else
>> +void save_boot_params(unsigned long r0, unsigned long r1, unsigned long
>> dtb)
>> +#endif
>> +{
>> +   fw_dtb_pointer = dtb;
>> +   save_boot_params_ret();
>> +}
>
>
> I think you need to write that function in assembly. This "function" is
> called very early during U-Boot startup, before any stack pointer is set up.
> You can't guarantee that a function written in C won't attempt to use the
> stack, although admittedly with the current code, Makefile, and the Ubuntu
> compilers, it just happens not to.

Apparently tegra also uses a C function for save_boot_params in
arch/arm/mach-tegra/board.c...

The comment in arch/arm/include/asm/system.h suggests that
save_boot_params() can be written in C:
/**
 * save_boot_params_ret() - Return from save_boot_params()
 *
 * If you provide save_boot_params(), then you should jump back to this
 * function when done. Try to preserve all registers.
 *
 * If your implementation of save_boot_params() is in C then it is acceptable
 * to simply call save_boot_params_ret() at the end of your function. Since
 * there is no link register set up, you cannot just exit the function. U-Boot
 * will return to the (initialised) value of lr, and likely crash/hang.
 *
 * If your implementation of save_boot_params() is in assembler then you
 * should use 'b' or 'bx' to return to save_boot_params_ret.
 */
void save_boot_params_ret(void);

As mentioned in the commit that added it:
commit 5519912164698b634893913b4408fee736d01d06
Author: Simon Glass 
Date:   Mon May 4 11:31:03 2015 -0600

arm: Add a prototype for save_boot_params_ret()

It is convenient for some boards to implement save_boot_params() in C rather
than assembler. Provide a way to return in this case.

Signed-off-by: Simon Glass 
Reviewed-by: Joe Hershberger 

>
> Aside from that issue, this version looks fine.

Regards,
Jonathan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] rpi: save firmware provided boot param for later use

[Jonathan Liu]

Hi Cédric,

On 6 November 2016 at 21:06, Cédric Schieli <cschi...@gmail.com> wrote:
>
> 2016-11-06 1:36 GMT+01:00 Jonathan Liu <net...@gmail.com>:
>>
>> I did a similar patch without noticing you already submitted this series.
>> The save_boot_params function can be written in C instead of assembly
>> and placed in rpi.c.
>> See
>> https://lists.yoctoproject.org/pipermail/yocto/2016-November/032934.html
>> for how to write save_boot_params in C as this can simplify your
>> patch. It also has a U-Boot script for using the FDT provided by the
>> firmware, though you would need to change ${fdt_addr_r} to
>> ${fw_fdt_addr} for it to work with your patch series.
>
>
> I do not have a strong opinion on wether save_boot_params should be C or
> assembly code. I'll opt for what the maintainers prefer here.
>
> Regarding the script, I'll include a example in my next version. I don't
> like the idea to hijack ${fdt_addr_r} as it is documented as a pointer to
> where one can manually load a custom FDT blob. If we make it points to the
> firmware provided one and the user manually loads a bigger blob, unexpected
> results may happen.

Yes, I prefer your method of storing it in a separate environment variable.

Regards,
Jonathan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] rpi: save firmware provided boot param for later use

[Jonathan Liu]

Hi Cédric,

On 3 November 2016 at 05:06, Cédric Schieli  wrote:
> At U-Boot entry point, the r2 register holds the address of the
> firmware provided boot param. Let's save it for further processing.
>
> Signed-off-by: Cédric Schieli 
> ---
>
>  board/raspberrypi/rpi/Makefile|  1 +
>  board/raspberrypi/rpi/lowlevel_init.S | 26 ++
>  include/configs/rpi.h |  4 
>  3 files changed, 31 insertions(+)
>  create mode 100644 board/raspberrypi/rpi/lowlevel_init.S
>
> diff --git a/board/raspberrypi/rpi/Makefile b/board/raspberrypi/rpi/Makefile
> index 4ce2c98..dcb25ac 100644
> --- a/board/raspberrypi/rpi/Makefile
> +++ b/board/raspberrypi/rpi/Makefile
> @@ -5,3 +5,4 @@
>  #
>
>  obj-y  := rpi.o
> +obj-y  += lowlevel_init.o
> diff --git a/board/raspberrypi/rpi/lowlevel_init.S 
> b/board/raspberrypi/rpi/lowlevel_init.S
> new file mode 100644
> index 000..446a70b
> --- /dev/null
> +++ b/board/raspberrypi/rpi/lowlevel_init.S
> @@ -0,0 +1,26 @@
> +/*
> + * (C) Copyright 2016
> + * Cédric Schieli 
> + *
> + * SPDX-License-Identifier:GPL-2.0+
> + */
> +
> +#include 
> +
> +.global fw_boot_param
> +fw_boot_param:
> +   .word 0x
> +
> +/*
> + * Routine: save_boot_params (called after reset from start.S)
> + * Description: save ATAG/FDT address provided by the firmware at boot time
> + */
> +
> +.global save_boot_params
> +save_boot_params:
> +
> +   /* The firmware provided ATAG/FDT address can be found in r2 */
> +   str r2, fw_boot_param
> +
> +   /* Returns */
> +   b   save_boot_params_ret
> diff --git a/include/configs/rpi.h b/include/configs/rpi.h
> index 8d4ad5d..2d1e619 100644
> --- a/include/configs/rpi.h
> +++ b/include/configs/rpi.h
> @@ -208,5 +208,9 @@
> ENV_MEM_LAYOUT_SETTINGS \
> BOOTENV
>
> +#ifndef __ASSEMBLY__
> +/* Firmware provided boot param */
> +extern const void *fw_boot_param;
> +#endif
>
>  #endif
> --
> 2.7.3

I did a similar patch without noticing you already submitted this series.
The save_boot_params function can be written in C instead of assembly
and placed in rpi.c.
See https://lists.yoctoproject.org/pipermail/yocto/2016-November/032934.html
for how to write save_boot_params in C as this can simplify your
patch. It also has a U-Boot script for using the FDT provided by the
firmware, though you would need to change ${fdt_addr_r} to
${fw_fdt_addr} for it to work with your patch series.

Regards,
Jonathan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] ARM: rpi: update memory layout env. var. documentation

[Jonathan Liu]

Hi Stephen,

Looks good to me then. I wasn't sure how U-Boot was typically used on the
RPi.

Regards,
Jonathan

On Sunday, 7 February 2016, Stephen Warren <swar...@wwwdotorg.org> wrote:

> On 02/06/2016 12:30 AM, Jonathan Liu wrote:
> > Hi Stephen,
> >
> > I actually read the DT loaded by RPi's binary firmware on an RPi 2 in a
> > U-Boot script:
> > fdt addr ${fdt_addr_r} && fdt get value bootargs /chosen bootargs
> > fatload mmc 0:1 ${kernel_addr_r} uImage
> > bootm ${kernel_addr_r} - ${fdt_addr_r}
> >
> > Essentially this loads the kernel with the same arguments and DT that
> > RPi's binary firmware would have used if it booted the kernel directly
> > with device tree support. This allows for the normal patching of the
> > kernel arguments and device tree to be done by the RPi binary firmware
> > so that things like reading the serial number in /proc/cpuinfo works.
> >
> > A trailer is added to u-boot.bin with "mkknlimg --dtok u-boot.bin
> > u-boot.bin" for the FW to enable device tree support and load the
> > patched device tree to 0x0100.
> >
> > So I am not sure about the comment that the DT loaded by the FW is
> > typically ignored by U-Boot scripts.
>
> This is a very unusual use-case. Typically the reason for using U-Boot
> in the first place is so that U-Boot has full control over the kernel,
> DT, and command-line. This way, users can configure all these aspects
> the exact same way on an RPi running U-Boot as on any other system
> running U-Boot. Mixing configuration between config.txt and the
> scripts/config-files that U-Boot reads/executes isn't typical, since it
> involves board-specific config file. As such, I believe the comment is
> correct for the common case, and already admits that other cases are
> possible.
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 1/2] ARM: rpi: update memory layout env. var. documentation

[Jonathan Liu]

Hi Stephen,

I actually read the DT loaded by RPi's binary firmware on an RPi 2 in a
U-Boot script:
fdt addr ${fdt_addr_r} && fdt get value bootargs /chosen bootargs
fatload mmc 0:1 ${kernel_addr_r} uImage
bootm ${kernel_addr_r} - ${fdt_addr_r}

Essentially this loads the kernel with the same arguments and DT that RPi's
binary firmware would have used if it booted the kernel directly with
device tree support. This allows for the normal patching of the kernel
arguments and device tree to be done by the RPi binary firmware so that
things like reading the serial number in /proc/cpuinfo works.

A trailer is added to u-boot.bin with "mkknlimg --dtok u-boot.bin
u-boot.bin" for the FW to enable device tree support and load the patched
device tree to 0x0100.

So I am not sure about the comment that the DT loaded by the FW is
typically ignored by U-Boot scripts.

Regards,
Jonathan

On Saturday, 6 February 2016, Stephen Warren <swar...@wwwdotorg.org
<javascript:_e(%7B%7D,'cvml','swar...@wwwdotorg.org');>> wrote:

> Update rpi-common.h's documentation that describes the rationale for
> choosing various addresses for standardized variables used by boot
> scripts. This comment was correct when written, but not updated when some
> of the values were changed.
>
> Fixes: 14006a567105 ("rpi: set fdt_addr_r to 0x0100 to match default
> ...device_tree_address")
> Cc: Jonathan Liu <net...@gmail.com>
> Cc: Daniel Stone <dani...@collabora.com>
> Signed-off-by: Stephen Warren <swar...@wwwdotorg.org>
> ---
>  include/configs/rpi-common.h | 16 +++-
>  1 file changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/include/configs/rpi-common.h b/include/configs/rpi-common.h
> index 72f1e2d60b8f..00a5266dad15 100644
> --- a/include/configs/rpi-common.h
> +++ b/include/configs/rpi-common.h
> @@ -144,8 +144,14 @@
>  /*
>   * Memory layout for where various images get loaded by boot scripts:
>   *
> - * scriptaddr can be pretty much anywhere that doesn't conflict with
> something
> - *   else. Put it low in memory to avoid conflicts.
> + * I suspect address 0 is used as the SMP pen on the RPi2, so avoid this.
> + *
> + * fdt_addr_r simply shouldn't overlap anything else. However, the RPi's
> + *   binary firmware loads a DT to address 0x100, so we choose this
> address to
> + *   match it. This allows custom boot scripts to pass this DT on to Linux
> + *   simply by not over-writing the data at this address. When using
> U-Boot,
> + *   U-Boot (and scripts it executes) typicaly ignore the DT loaded by
> the FW
> + *   and loads its own DT from disk (triggered by boot.scr or
> extlinux.conf).
>   *
>   * pxefile_addr_r can be pretty much anywhere that doesn't conflict with
>   *   something else. Put it low in memory to avoid conflicts.
> @@ -159,11 +165,11 @@
>   *   this up to 16M allows for a sizable kernel to be decompressed below
> the
>   *   compressed load address.
>   *
> - * fdt_addr_r simply shouldn't overlap anything else. Choosing 32M allows
> for
> - *   the compressed kernel to be up to 16M too.
> + * scriptaddr can be pretty much anywhere that doesn't conflict with
> something
> + *   else. Choosing 32M allows for the compressed kernel to be up to 16M.
>   *
>   * ramdisk_addr_r simply shouldn't overlap anything else. Choosing 33M
> allows
> - *   for the FDT/DTB to be up to 1M, which is hopefully plenty.
> + *   for any boot script to be up to 1M, which is hopefully plenty.
>   */
>  #define ENV_MEM_LAYOUT_SETTINGS \
> "fdt_addr_r=0x0100\0" \
> --
> 1.9.1
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] rpi: set fdt_addr_r to 0x00000100 to match default device_tree_address

[Jonathan Liu]

Raspberry Pi by default loads the FDT to 0x0100 so set fdt_addr_r to
match and move scriptaddr to 0x0200 to avoid clobbering the FDT.

Signed-off-by: Jonathan Liu net...@gmail.com
---
 include/configs/rpi-common.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/configs/rpi-common.h b/include/configs/rpi-common.h
index 8830a10..06836cd 100644
--- a/include/configs/rpi-common.h
+++ b/include/configs/rpi-common.h
@@ -163,10 +163,10 @@
  *   for the FDT/DTB to be up to 1M, which is hopefully plenty.
  */
 #define ENV_MEM_LAYOUT_SETTINGS \
-   scriptaddr=0x\0 \
+   fdt_addr_r=0x0100\0 \
pxefile_addr_r=0x0010\0 \
kernel_addr_r=0x0100\0 \
-   fdt_addr_r=0x0200\0 \
+   scriptaddr=0x0200\0 \
ramdisk_addr_r=0x0210\0 \
 
 #define BOOT_TARGET_DEVICES(func) \
-- 
2.5.0

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot