[PATCH] arm: kirkwood: Convert to DM Serial for various Kirkwood boards

2022-12-29 Thread Tony Dinh
For Kirkwood boards, it is necessary to have early malloc in DRAM area
when Driver Model for Serial is enabled. Please see Michael's patch here:
https://lore.kernel.org/u-boot/20220817193809.1059688-20-mich...@walle.cc/

This patch enables the early malloc in DRAM for all Kirkwood boards.
Note that this will work for boards that have either non-DM serial
and DM_SERIAL. Also, add the CONFIG_KIRKWOOD_COMMON option to enable
DM_SERIAL as a common option for boards that have been tested.

Signed-off-by: Tony Dinh 
---

 arch/arm/mach-kirkwood/Kconfig | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/arch/arm/mach-kirkwood/Kconfig b/arch/arm/mach-kirkwood/Kconfig
index c8a193dd4c..45cc932636 100644
--- a/arch/arm/mach-kirkwood/Kconfig
+++ b/arch/arm/mach-kirkwood/Kconfig
@@ -12,6 +12,19 @@ config KW88F6281
 config SHEEVA_88SV131
bool
 
+config KIRKWOOD_COMMON
+   bool
+   select DM_SERIAL
+
+config HAS_CUSTOM_SYS_INIT_SP_ADDR
+bool "Use a custom location for the initial stack pointer address"
+default y
+
+config CUSTOM_SYS_INIT_SP_ADDR
+hex "Static location for the initial stack pointer"
+depends on HAS_CUSTOM_SYS_INIT_SP_ADDR
+default 0x5ff000
+
 choice
prompt "Marvell Kirkwood board select"
optional
@@ -25,6 +38,7 @@ config TARGET_DREAMPLUG
bool "DreamPlug Board"
select KW88F6281
select SHEEVA_88SV131
+   select KIRKWOOD_COMMON
 
 config TARGET_DS109
bool "Synology DS109"
@@ -40,6 +54,7 @@ config TARGET_SHEEVAPLUG
bool "SheevaPlug Board"
select FEROCEON_88FR131
select KW88F6281
+   select KIRKWOOD_COMMON
 
 config TARGET_LSXL
bool "lsxl Board"
@@ -47,16 +62,19 @@ config TARGET_LSXL
select KW88F6281
select BOARD_EARLY_INIT_R
select MISC_INIT_R
+   select KIRKWOOD_COMMON
 
 config TARGET_POGO_E02
bool "pogo_e02 Board"
select FEROCEON_88FR131
select KW88F6281
+   select KIRKWOOD_COMMON
 
 config TARGET_POGO_V4
bool "Pogoplug V4 Board"
select FEROCEON_88FR131
select KW88F6192
+   select KIRKWOOD_COMMON
 
 config TARGET_DNS325
bool "dns325 Board"
@@ -67,6 +85,7 @@ config TARGET_ICONNECT
bool "iconnect Board"
select FEROCEON_88FR131
select KW88F6281
+   select KIRKWOOD_COMMON
 
 config TARGET_KM_KIRKWOOD
bool "KM Kirkwood Board"
@@ -92,11 +111,13 @@ config TARGET_DOCKSTAR
bool "Dockstar Board"
select FEROCEON_88FR131
select KW88F6281
+   select KIRKWOOD_COMMON
 
 config TARGET_GOFLEXHOME
bool "GoFlex Home Board"
select FEROCEON_88FR131
select KW88F6281
+   select KIRKWOOD_COMMON
 
 config TARGET_NAS220
bool "BlackArmor NAS220"
@@ -107,6 +128,7 @@ config TARGET_NSA310S
bool "Zyxel NSA310S"
select FEROCEON_88FR131
select KW88F6192
+   select KIRKWOOD_COMMON
 
 config TARGET_SBx81LIFKW
bool "Allied Telesis SBx81GS24/SBx81GT40/SBx81XS6/SBx81XS16"
-- 
2.30.2



[PATCH 1/1] Dockerfile: add package texinfo

2022-12-29 Thread Heinrich Schuchardt
In preparation of adding the infodocs target to our CI install the
prerequisite texinfo software package.

Signed-off-by: Heinrich Schuchardt 
---
 tools/docker/Dockerfile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/docker/Dockerfile b/tools/docker/Dockerfile
index 42ab81283d..2f566d3fb3 100644
--- a/tools/docker/Dockerfile
+++ b/tools/docker/Dockerfile
@@ -109,6 +109,7 @@ RUN apt-get update && apt-get install -y \
srecord \
sudo \
swig \
+   texinfo \
util-linux \
uuid-dev \
virtualenv \
-- 
2.37.2



[PATCH 1/1] doc: building documentation

2022-12-29 Thread Heinrich Schuchardt
Provide a man-page describing how to build the U-Boot documentation.

Signed-off-by: Heinrich Schuchardt 
---
 doc/build/documentation.rst | 90 +
 doc/build/index.rst |  1 +
 2 files changed, 91 insertions(+)
 create mode 100644 doc/build/documentation.rst

diff --git a/doc/build/documentation.rst b/doc/build/documentation.rst
new file mode 100644
index 00..896264dd7c
--- /dev/null
+++ b/doc/build/documentation.rst
@@ -0,0 +1,90 @@
+.. SPDX-License-Identifier: GPL-2.0+:
+
+Building documentation
+==
+
+The U-Boot documentation is based on the Sphinx documentation generator.
+
+HTML documentation
+--
+
+The *htmldocs* target is used to build the HTML documentation. It uses the
+`Read the Docs Sphinx theme 
`_.
+
+.. code-block:: bash
+
+# Create Python environment 'myenv'
+python3 -m venv myenv
+# Activate the Python environment
+. myenv/bin/activate
+# Install build requirements
+python3 -m pip install -r doc/sphinx/requirements.txt
+# Build the documentation
+make htmldocs
+# Deactivate the Python environment
+deactivate
+# Display the documentation in a graphical web browser
+x-www-browser doc/output/index.html
+
+Infodoc documentation
+-
+
+The *infodocs* target builds both a texinfo and an info file:
+
+.. code-block:: bash
+
+# Create Python environment 'myenv'
+python3 -m venv myenv
+# Activate the Python environment
+. myenv/bin/activate
+# Install build requirements
+python3 -m pip install -r doc/sphinx/requirements.txt
+# Build the documentation
+make infodocs
+# Deactivate the Python environment
+deactivate
+# Display the documentation
+info doc/output/texinfo/u-boot.info
+
+PDF documentation
+-
+
+The *pdfdocs* target is meant to be used to build PDF documenation.
+As v2023.01 it fails with 'LaTeX Error: Too deeply nested'.
+
+We can use texi2pdf instead:
+
+.. code-block:: bash
+
+# Create Python environment 'myenv'
+python3 -m venv myenv
+# Activate the Python environment
+. myenv/bin/activate
+# Install build requirements
+python3 -m pip install -r doc/sphinx/requirements.txt
+# Build the documentation
+make texinfodocs
+# Deactivate the Python environment
+deactivate
+# Convert to PDF
+texi2pdf doc/output/texinfo/u-boot.texi
+
+Texinfo documentation
+-
+
+To build only the texinfo documentation the *texinfodocs* target is used:
+
+.. code-block:: bash
+
+# Create Python environment 'myenv'
+python3 -m venv myenv
+# Activate the Python environment
+. myenv/bin/activate
+# Install build requirements
+python3 -m pip install -r doc/sphinx/requirements.txt
+# Build the documentation
+make texinfodocs
+# Deactivate the Python environment
+deactivate
+
+The output is in file *doc/output/texinfo/u-boot.texi*.
diff --git a/doc/build/index.rst b/doc/build/index.rst
index 9a8105db21..dc9cde4001 100644
--- a/doc/build/index.rst
+++ b/doc/build/index.rst
@@ -12,3 +12,4 @@ Build U-Boot
docker
tools
buildman
+   documentation
-- 
2.37.2



Re: [PATCH 00/17] Support android boot image v3/v4

2022-12-29 Thread Tom Rini
On Sat, 26 Nov 2022 17:59:14 +0100, Safae Ouajih wrote:

> * This is based on Roman Stratiienko's work to support boot image header 
> version 3 and 4.
> 
> * This supports the new boot image headers v3, v4 and bootconfig feature.
> https://source.android.com/docs/core/architecture/bootloader/boot-image-header
> https://source.android.com/docs/core/architecture/bootloader/implementing-bootconfig
> 
> - Tested on Amlogic Khadas vim3l, a reference board for Android Open Source 
> Project
>   https://www.khadas.com/vim3l
> 
> [...]

This series causes the test/py/tests/test_android/test_abootimg.py tests to
fail:
FAILED test/py/tests/test_android/test_abootimg.py::test_abootimg - ValueError: 
U-Boot exite...
and likely that test needs to be expanded for these new formats too.

-- 
Tom



[PATCH] fs/btrfs: handle data extents, which crosss stripe boundaries, correctly

2022-12-29 Thread Qu Wenruo
[BUG]
Since btrfs supports single device RAID0 at mkfs time after btrfs-progs
v5.14, if we create a single device raid0 btrfs, and created a file
crossing stripe boundary:

  # mkfs.btrfs -m dup -d raid0 test.img
  # mount test.img mnt
  # xfs_io -f -c "pwrite 0 128K" mnt/file
  # umount mnt

Since btrfs is using 64K as stripe length, above 128K data write is
definitely going to cross at least one stripe boundary.

Then u-boot would fail to read above 128K file:

 => host bind 0 /home/adam/test.img
 => ls host 0
 <   > 131072  Fri Dec 30 00:18:25 2022  file
 => load host 0 0 file
 BTRFS: An error occurred while reading file file
 Failed to load 'file'

[CAUSE]
Unlike tree blocks read, data extent reads doesn't consider cases in which
one data extent can cross stripe boundary.

In read_data_extent(), we just call btrfs_map_block() once and read the
first mapped range.

And if the first mapped range is smaller than the desired range, it
would return error.

But since even single device btrfs can utilize RAID0 profiles, the first
mapped range can only be at most 64K for RAID0 profiles, and cause false
error.

[FIX]
Just like read_whole_eb(), we should call btrfs_map_block() in a loop
until we read all data.

Since we're here, also add extra error messages for the following cases:

- btrfs_map_block() failure
  We already have the error message for it.

- Missing device
  This should not happen, as we only support single device for now.

- __btrfs_devread() failure

With this bug fixed, btrfs driver of u-boot can properly read the above
128K file, and have the correct content:

 => host bind 0 /home/adam/test.img
 => ls host 0
 <   > 131072  Fri Dec 30 00:18:25 2022  file
 => load host 0 0 file
 131072 bytes read in 0 ms
 => md5sum 0 0x2
 md5 for  ... 0001 ==> d48858312a922db7eb86377f638dbc9f
 ^^^ Above md5sum also matches.

Reported-by: Sam Winchenbach 
Signed-off-by: Qu Wenruo 
---
 fs/btrfs/disk-io.c | 49 +-
 1 file changed, 27 insertions(+), 22 deletions(-)

diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index 3f0d9f1c113b..7eaa7e949604 100644
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -541,34 +541,39 @@ struct extent_buffer* read_tree_block(struct 
btrfs_fs_info *fs_info, u64 bytenr,
 int read_extent_data(struct btrfs_fs_info *fs_info, char *data, u64 logical,
 u64 *len, int mirror)
 {
-   u64 offset = 0;
+   u64 orig_len = *len;
+   u64 cur = logical;
struct btrfs_multi_bio *multi = NULL;
struct btrfs_device *device;
int ret = 0;
-   u64 max_len = *len;
 
-   ret = btrfs_map_block(fs_info, READ, logical, len, , mirror,
- NULL);
-   if (ret) {
-   fprintf(stderr, "Couldn't map the block %llu\n",
-   logical + offset);
-   goto err;
-   }
-   device = multi->stripes[0].dev;
+   while (cur < logical + orig_len) {
+   u64 cur_len = logical + orig_len - cur;
 
-   if (*len > max_len)
-   *len = max_len;
-   if (!device->desc || !device->part) {
-   ret = -EIO;
-   goto err;
-   }
-
-   ret = __btrfs_devread(device->desc, device->part, data, *len,
- multi->stripes[0].physical);
-   if (ret != *len)
-   ret = -EIO;
-   else
+   ret = btrfs_map_block(fs_info, READ, cur, _len, ,
+ mirror, NULL);
+   if (ret) {
+   error("Couldn't map the block %llu", cur);
+   goto err;
+   }
+   device = multi->stripes[0].dev;
+   if (!device->desc || !device->part) {
+   error("devid %llu is missing", device->devid);
+   ret = -EIO;
+   goto err;
+   }
+   ret = __btrfs_devread(device->desc, device->part,
+   data + (cur - logical), cur_len,
+   multi->stripes[0].physical);
+   if (ret != cur_len) {
+   error("read failed on devid %llu physical %llu",
+ device->devid, multi->stripes[0].physical);
+   ret = -EIO;
+   goto err;
+   }
+   cur += cur_len;
ret = 0;
+   }
 err:
kfree(multi);
return ret;
-- 
2.39.0



Re: Possible bug in BTRFS w/ Duplication

2022-12-29 Thread Qu Wenruo




On 2022/12/29 22:12, Heinrich Schuchardt wrote:

On 12/28/22 21:51, Sam Winchenbach wrote:

Hello,

Hello, I have hit the following situation when trying to load files 
from a BTRFS partition with duplication enabled.


You mean multi-device?

For DUP/RAID1 duplication, they don't have stripe limitation at all.

Thus I believe you're talking about RAID0 (which doesn't have any 
duplication/extra mirrors) or RAID10 or RAID5/6?


But for now, we don't support multi-device in U-boot yet, thus I'm not 
sure what situation you're talking about.


Mind to run the following command?

 # btrfs fi usage 



In the first example I read a 16KiB file - __btrfs_map_block() changes 
the length to something larger than the file being read. This works 
fine, as length is later clamped to the file size.


In the second example, __btrfs_map_block() changes the length 
parameter to something smaller than the file (the size of a stripe).  
This seems to break this check here:


 read = len;
 num_copies = btrfs_num_copies(fs_info, logical, len);
 for (i = 1; i <= num_copies; i++) {
 ret = read_extent_data(fs_info, dest, logical, , i);
 if (ret < 0 || read != len) {
 continue;
 }
 finished = true;
 break;
 }

The problem being that read is always less than len.

I am not sure if __btrfs_map_block is changing "len" to the incorrect 
value, or if there is some logic in "read_extent_data" that isn't 
correct. Any pointers on how this code is supposed to work would be 
greatly appreciated.

Thanks.


Thanks for reporting the issue

$ scripts/get_maintainer.pl -f fs/btrfs/volumes.c

suggests to include

"Marek Behún"  (maintainer:BTRFS)
Qu Wenruo  (reviewer:BTRFS)
linux-bt...@vger.kernel.org

to the communication.

Best regards

Heinrich



=== EXAMPLE 2 ===
Zynq> load mmc 1:0 0 16K
[btrfs_file_read,fs/btrfs/inode.c:710] === read the aligned part ===
[btrfs_read_extent_reg,fs/btrfs/inode.c:458] before read_extent_data 
(ret = 0, read = 16384, len = 16384)
[read_extent_data,fs/btrfs/disk-io.c:547] before __btrfs_map_block 
(len = 16384)
[read_extent_data,fs/btrfs/disk-io.c:550] after __btrfs_map_block (len 
= 28672)
[read_extent_data,fs/btrfs/disk-io.c:565] before __btrfs_devread (len 
= 16384)
[read_extent_data,fs/btrfs/disk-io.c:568] after __btrfs_devread (len = 
16384)
[btrfs_read_extent_reg,fs/btrfs/inode.c:460] after read_extent_data 
(ret = 0, read = 16384, len = 16384)

cur: 0, extent_num_bytes: 16384, aligned_end: 16384
16384 bytes read in 100 ms (159.2 KiB/s)

=== EXAMPLE 2 ===
Zynq> load mmc 1:0 0 32K
[btrfs_file_read,fs/btrfs/inode.c:710] === read the aligned part ===
[btrfs_read_extent_reg,fs/btrfs/inode.c:458] before read_extent_data 
(ret = 0, read = 32768, len = 32768)
[read_extent_data,fs/btrfs/disk-io.c:547] before __btrfs_map_block 
(len = 32768)
[read_extent_data,fs/btrfs/disk-io.c:550] after __btrfs_map_block (len 
= 12288)
[read_extent_data,fs/btrfs/disk-io.c:565] before __btrfs_devread (len 
= 12288)
[read_extent_data,fs/btrfs/disk-io.c:568] after __btrfs_devread (len = 
12288)


So the first 3 sectors are before the stripe boundary and we read it 
correctly.


[btrfs_read_extent_reg,fs/btrfs/inode.c:460] after read_extent_data 
(ret = 0, read = 12288, len = 32768)
[btrfs_read_extent_reg,fs/btrfs/inode.c:458] before read_extent_data 
(ret = 0, read = 12288, len = 32768)
[read_extent_data,fs/btrfs/disk-io.c:547] before __btrfs_map_block 
(len = 12288)
[read_extent_data,fs/btrfs/disk-io.c:550] after __btrfs_map_block (len 
= 12288)


I believe this is the problem.

If we're reading the full 32K, and the first 12K is in the first stripe, 
we should then try to map the remaining 20K, not the 12K again.


I'll look into the situation.
But if you can provide the image or the dump, it can greatly help the 
debugging.


Thanks,
Qu

[read_extent_data,fs/btrfs/disk-io.c:565] before __btrfs_devread (len 
= 12288)
[read_extent_data,fs/btrfs/disk-io.c:568] after __btrfs_devread (len = 
12288)
[btrfs_read_extent_reg,fs/btrfs/inode.c:460] after read_extent_data 
(ret = 0, read = 12288, len = 32768)

file: fs/btrfs/inode.c, line: 468
cur: 0, extent_num_bytes: 32768, aligned_end: 32768
-> btrfs_read_extent_reg: -5, line: 758
BTRFS: An error occurred while reading file 32K
Failed to load '32K'





Sam Winchenbach
Embedded Software Engineer III
Tethers Unlimited, Inc. | Connect Your Universe | www.tethers.com
swinchenb...@tethers.com | C: 207-974-6934
11711 North Creek Pkwy # D113, Bothell, WA 98011-8808, USA




Re: CONFIG migration quirk

2022-12-29 Thread Tom Rini
On Thu, Dec 29, 2022 at 04:54:35PM -0600, Simon Glass wrote:
> Hi Tom,
> 
> If I:
> 
> 1. Revert 9ef3ba85bf3 kbuild: Remove checking for adhoc CONFIG symbols
> 2. rm scripts/config_whitelist.txt
> 3. run ./scripts/build-whitelist.sh
> 
> Then I get about 930 unmirgrated CONFIG options:
> 
> $ wc scripts/config_whitelist.txt
>   930   930 21243 scripts/config_whitelist.txt
> 
> It seems that some of them are still there. I noticed this when
> looking at CONFIG_VIDEO_FONT_4X6
> 
> Am I missing something?

So, it's why I've not quite said we've migrated _everything_.  There's
now a much smaller / odder set of CONFIG values left to deal with, or
ignore. If you do:
$ git grep -E '^#[[:blank:]]*(define|undef)[[:blank:]]*CONFIG_' :^arch/arm/dts/ 
:^scripts/kconfig/lkc.h :^include/linux/kconfig.h | wc -l
606

And of those, 406 are "CONFIG_SYS" and so should just get regex'd to
CFG_SYS. There's also a few more ignore paths that should go in that
grep, such as doc/ and tools/.  What's left after that is seeing if any
of those are used, or if there's any more cases of defining defaults in
code instead of Kconfig.

I'm also a bit less concerned about this in that I've made checkpatch.pl
complain about any additional #define CONFIG / #undef CONFIG anywhere
(and I check that for everything as I merge), and CI is now more strict,
but not 100% strict yet.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 0/5] vidconsole: refactoring and support for wider fonts

2022-12-29 Thread Mark Kettenis
> From: Dzmitry Sankouski 
> Date: Mon, 26 Dec 2022 22:49:24 +0300
> 
> Modern mobile phones typically have high pixel density.
> Bootmenu is hardly readable on those with 8x16 font.
> 
> This patch series aims to add wider fonts for devices with high ppi.
> 
> Add 16x32 ter font from linux, and allow font size configuration.
> Use new font in starqltechn board.

There was a patchset related to this earlier this year that is still
in limbo:

  https://patchwork.ozlabs.org/project/uboot/list/?series=280178

No idea which is the better approach.


CONFIG migration quirk

2022-12-29 Thread Simon Glass
Hi Tom,

If I:

1. Revert 9ef3ba85bf3 kbuild: Remove checking for adhoc CONFIG symbols
2. rm scripts/config_whitelist.txt
3. run ./scripts/build-whitelist.sh

Then I get about 930 unmirgrated CONFIG options:

$ wc scripts/config_whitelist.txt
  930   930 21243 scripts/config_whitelist.txt

It seems that some of them are still there. I noticed this when
looking at CONFIG_VIDEO_FONT_4X6

Am I missing something?

Regards,
Simon


Re: [PATCH 3/5] video console: add support for fonts wider than 1 byte

2022-12-29 Thread Simon Glass
Hi Dzmitry,

On Mon, 26 Dec 2022 at 13:50, Dzmitry Sankouski  wrote:
>
> Devices with high ppi may benefit from wider fonts.
>
> Current width implementation is limited by 1 byte, i.e. 8 bits.
> New version iterates VIDEO_FONT_BYTE_WIDTH times, to process all
> width bytes, thus allowing fonts wider than 1 byte.
>
> Signed-off-by: Dzmitry Sankouski 
> ---
>  drivers/video/console_simple.c | 79 ++
>  include/video_font_4x6.h   |  2 +
>  include/video_font_data.h  |  2 +
>  3 files changed, 47 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/video/console_simple.c b/drivers/video/console_simple.c
> index 20087a30af..3ae1fbdc89 100644
> --- a/drivers/video/console_simple.c
> +++ b/drivers/video/console_simple.c
> @@ -61,30 +61,32 @@ static int fill_char_horizontally(uchar *pfont, void 
> **line, struct video_priv *
>  {
> int ret;
> void *dst;
> -   u8 mask = 0x80;
> -
> +   u8 mask;
> ret = check_bpix_support(vid_priv->bpix);
> if (ret)
> return ret;
>
> -   for (int col = 0; col < VIDEO_FONT_WIDTH; col++) {
> -   dst = *line;
> -   for (int row = 0; row < VIDEO_FONT_HEIGHT; row++) {
> -   u32 value = (pfont[row * VIDEO_FONT_BYTE_WIDTH + col] 
> & mask) ?
> -   vid_priv->colour_fg :
> -   vid_priv->colour_bg;
> -
> -   ret = fill_pixel_and_goto_next(,
> -  value,
> -  
> VNBYTES(vid_priv->bpix),
> -  direction
> -   );
> +   for (int col = 0; col < VIDEO_FONT_BYTE_WIDTH; col++) {
> +   mask = 0x80;
> +   for (int bit = 0; bit < 8; bit++) {
> +   dst = *line;
> +   for (int row = 0; row < VIDEO_FONT_HEIGHT; row++) {
> +   u32 value = (pfont[row * 
> VIDEO_FONT_BYTE_WIDTH + col] & mask) ?
> +   vid_priv->colour_fg :
> +   vid_priv->colour_bg;
> +
> +   ret = fill_pixel_and_goto_next(,
> +  value,
> +  
> VNBYTES(vid_priv->bpix),
> +  direction
> +   );
> +   }
> +   if (direction)
> +   *line += vid_priv->line_length;
> +   else
> +   *line -= vid_priv->line_length;
> +   mask >>= 1;
> }
> -   if (direction)
> -   *line += vid_priv->line_length;
> -   else
> -   *line -= vid_priv->line_length;
> -   mask >>= 1;
> }
> return ret;
>  }
> @@ -101,24 +103,29 @@ static int fill_char_vertically(uchar *pfont, void 
> **line, struct video_priv *vi
> return ret;
> for (int row = 0; row < VIDEO_FONT_HEIGHT; row++) {
> dst = *line;
> -   uchar bits = pfont[row];
> -
> -   for (int i = 0; i < VIDEO_FONT_WIDTH; i++) {
> -   u32 value = (bits & 0x80) ?
> -   vid_priv->colour_fg :
> -   vid_priv->colour_bg;
> -
> -   ret = fill_pixel_and_goto_next(,
> -  value,
> -  
> VNBYTES(vid_priv->bpix),
> -  direction
> -   );
> -   bits <<= 1;
> +   uchar bits;
> +
> +   for (int i = 0; i < VIDEO_FONT_BYTE_WIDTH; i++) {
> +   bits = pfont[i];
> +   for (int bit = 0; bit < 8; bit++) {
> +   u32 value = (bits & 0x80) ?
> +   vid_priv->colour_fg :
> +   vid_priv->colour_bg;
> +
> +   ret = fill_pixel_and_goto_next(,
> +  value,
> +  
> VNBYTES(vid_priv->bpix),
> +  direction
> +   );
> +   bits <<= 1;
> +   }
> }
> if (direction)
> *line -= vid_priv->line_length;
> else
> 

Re: [PATCH 4/5] video console: add 16x32 ter font from linux

2022-12-29 Thread Simon Glass
Hi Dzmitry,

On Tue, 27 Dec 2022 at 07:44, Dzmitry Sankouski  wrote:
>
> Modern mobile phones typically have high pixel density.
> Bootmenu is hardly readable on those with 8x16 font.
>
> Add 16x32 ter font from linux, and allow font size configuration.

That second bit should really be in a separate (previous) commit.

> Set 16x32 font for starqltechn board.

This should be in the next commit.

>
> Signed-off-by: Dzmitry Sankouski 
> ---
>  configs/starqltechn_defconfig |1 +
>  drivers/video/Kconfig |   23 +
>  include/video_font.h  |6 +-
>  include/video_font_ter16x32.h | 2068 +
>  4 files changed, 2096 insertions(+), 2 deletions(-)
>  create mode 100644 include/video_font_ter16x32.h

Can we test this? With truetype we actually allow multiple fonts to be
built, so we can select one at runtime.

Regards,
Simon


Re: [PATCH v1 1/1] arm64: versal: enable config_of_separate

2022-12-29 Thread Simon Glass
On Fri, 23 Dec 2022 at 02:57, Neal Frager  wrote:
>
> Enable CONFIG_OF_SEPARATE, so that the u-boot.dtb is built by default for
> versal devices.
>
> Signed-off-by: Neal Frager 
> ---
>  configs/xilinx_versal_virt_defconfig | 1 +
>  1 file changed, 1 insertion(+)

Reviewed-by: Simon Glass 

For the commit subject, it should really be OF_SEPARATE (you can leave
off the CONFIG_ but it should be in CAPS).


Re: [PATCH u-boot 2/2] Makefile: Build working u-boot-dtb.bin target also for mpc85xx

2022-12-29 Thread Simon Glass
Hi Pali,

On Wed, 28 Dec 2022 at 14:06, Pali Rohár  wrote:
>
> U-Boot build process currently always produces broken u-boot-dtb.bin binary
> for PowerPC mpc85xx architecture on boards which needs mpc85xx reset
> vector. For these boards this (intermediate) binary is not used as input
> for any other Makefile target on this architecture, so there is no real
> problem with it.
>
> But it is not a good idea to produce broken binaries during build phase. So
> try to improve it. Binary u-boot-dtb.bin should contains u-boot code with
> DTB blob. Such binary for those boards is build by binman. So change binman
> output file name from u-boot.bin to u-boot-dtb.bin and then let generic
> Makefile rule to generate final u-boot.bin from u-boot-dtb.bin. And finally
> disable generic u-boot-dtb.bin rule for mpc85xx.
>
> Signed-off-by: Pali Rohár 
> ---
>  Makefile  | 17 -
>  arch/powerpc/dts/socrates-u-boot.dtsi |  2 +-
>  arch/powerpc/dts/u-boot.dtsi  |  2 +-
>  3 files changed, 10 insertions(+), 11 deletions(-)

Can you instead use a new filename, like u-boot-powerpc.bin for this?

I'm not  fan of adding SoC-specific rules in the Makefile - in fact
one of the goals of binman is to drop these.

Regards,
Simon


Re: [PATCH 2/5] video console: refactoring and optimization

2022-12-29 Thread Simon Glass
Hi Dzmitry,

On Mon, 26 Dec 2022 at 13:50, Dzmitry Sankouski  wrote:
>
> - get rid of code duplications in switch across bpp values
> - extract common pixel fill logic in two functions one per
> horizontal and vertical filling
> - rearrange statements in put_xy* methods in unified way
> - replace types - uint*_t to u*
>
> Signed-off-by: Dzmitry Sankouski 
> ---
>  drivers/video/console_simple.c | 508 -
>  1 file changed, 184 insertions(+), 324 deletions(-)

This looks like a nice tidy up.

Is there a code-size or performance penalty with this? E.g. with
CONFIG_CONSOLE_ROTATION disabled

Please can you comment the functions property so we know what they do?

Regards,
Simon


Re: [PATCH v2 1/2] lib: zstd: update to latest Linux zstd 1.5.2

2022-12-29 Thread Simon Glass
Hi Brandon,

On Tue, 27 Dec 2022 at 09:16, Brandon Maier  wrote:
>
> Update the zstd implementation to match Linux zstd 1.5.2 from commit
> 2aa14b1ab2.
>
> This was motivated by running into decompression corruption issues when
> trying to uncompress files compressed with newer versions of zstd. zstd
> users also claim significantly improved decompression times with newer
> zstd versions which is a side benefit.
>
> Original zstd code was copied from Linux commit 2aa14b1ab2 which is a
> custom-built implementation based on zstd 1.3.1. Linux switched to an
> implementation that is a copy of the upstream zstd code in Linux commit
> e0c1b49f5b, this results in a large code diff. However this should make
> future updates easier along with other benefits[1].
>
> This commit is a straight mirror of the Linux zstd code, except to:
> - update a few #include that do not translate cleanly
>   - linux/swab.h -> asm/byteorder.h
>   - linux/limits.h -> linux/kernel.h
>   - linux/module.h -> linux/compat.h
> - remove assert() from debug.h so it doesn't conflict with u-boot's
>   assert()
> - strip out the compressor code as was done in the previous u-boot zstd
> - update existing zstd users to the new Linux zstd API
> - add a new KConfig option that sets zstd build options to minify code
>   based on zstd's ZSTD_LIB_MINIFY[2].
>
> These changes were tested by booting a zstd 1.5.2 compressed kernel inside a
> FIT. And the squashfs changes by loading a file from zstd compressed squashfs
> with sqfsload. buildman was used to compile test other boards and check for
> binary bloat, as follows:
>
> > $ buildman -b zstd2 --boards 
> > dh_imx6,m53menlo,mvebu_espressobin-88f3720,sandbox,sandbox64,stm32mp15_dhcom_basic,stm32mp15_dhcor_basic,turris_mox,turris_omnia
> >  -sS
> > Summary of 3 commits for 9 boards (8 threads, 1 job per thread)
> > 01: Merge tag 'tpm-23122022' of 
> > https://source.denx.de/u-boot/custodians/u-boot-tpm
> >arm:  w+   m53menlo dh_imx6
> > 02: lib: zstd: update to latest Linux zstd 1.5.2
> >aarch64: (for 2/2 boards) all +535.5 rodata +965.5 text -430.0
> >arm: (for 5/5 boards) all +4489.6 rodata +940.0 text +3549.6

That's a pretty stiff penalty. Do you know what has changed? Does it
support a lot more optional features? If so, could we make it optional
(even if default y)?


> >sandbox: (for 2/2 boards) all +12.0 rodata +768.0 text -756.0
>
> [1] 
> https://github.com/torvalds/linux/commit/e0c1b49f5b674cca7b10549c53b3791d0bbc90a8
> [2] 
> https://github.com/facebook/zstd/blob/f302ad8811643c428c4e3498e28f53a0578020d3/lib/libzstd.mk#L31
>
> Signed-off-by: Brandon Maier 
> ---
> v2:
> - zstd_decompress(): Handle junk at the end of the decompression buffer
>   by checking actual size with zstd_find_frame_compressed_size().
> ---
>  fs/squashfs/sqfs_decompressor.c   |   15 +-
>  include/linux/zstd.h  | 1244 ++--
>  include/linux/zstd_errors.h   |   77 +
>  include/linux/zstd_lib.h  | 2551 +
>  lib/Kconfig   |   15 +
>  lib/zstd/Makefile |   35 +-
>  lib/zstd/bitstream.h  |  344 ---
>  lib/zstd/common/bitstream.h   |  446 +++
>  lib/zstd/common/compiler.h|  184 ++
>  lib/zstd/common/cpu.h |  194 ++
>  lib/zstd/common/debug.c   |   24 +
>  lib/zstd/common/debug.h   |   92 +
>  lib/zstd/common/entropy_common.c  |  357 +++
>  lib/zstd/common/error_private.c   |   56 +
>  lib/zstd/common/error_private.h   |  145 +
>  lib/zstd/common/fse.h |  711 +
>  lib/zstd/common/fse_decompress.c  |  390 +++
>  lib/zstd/common/huf.h |  358 +++
>  lib/zstd/common/mem.h |  261 ++
>  lib/zstd/common/portability_macros.h  |   93 +
>  lib/zstd/common/zstd_common.c |   83 +
>  lib/zstd/common/zstd_deps.h   |  125 +
>  lib/zstd/common/zstd_internal.h   |  443 +++
>  lib/zstd/decompress.c | 2516 
>  lib/zstd/decompress/huf_decompress.c  | 1740 +++
>  lib/zstd/decompress/zstd_ddict.c  |  241 ++
>  lib/zstd/decompress/zstd_ddict.h  |   44 +
>  lib/zstd/decompress/zstd_decompress.c | 2131 ++
>  lib/zstd/decompress/zstd_decompress_block.c   | 2072 +
>  lib/zstd/decompress/zstd_decompress_block.h   |   68 +
>  .../decompress/zstd_decompress_internal.h |  228 ++
>  lib/zstd/decompress_sources.h |   34 +
>  lib/zstd/entropy_common.c |  213 --
>  lib/zstd/error_private.h  |   43 -
>  lib/zstd/fse.h|  545 
>  lib/zstd/fse_decompress.c |  302 --
>  

Re: [PATCH 1/5] video console: unite normal and rotated files

2022-12-29 Thread Simon Glass
Hi Dzmitry,

On Mon, 26 Dec 2022 at 13:49, Dzmitry Sankouski  wrote:
>
> Put video console driver code in one file.

This isn't quite true as we still have TrueType.

Also, what combine them?

>
> Signed-off-by: Dzmitry Sankouski 
> ---
>  drivers/video/Kconfig |   8 +-
>  drivers/video/Makefile|   3 +-
>  drivers/video/console_normal.c| 178 --
>  .../{console_rotate.c => console_simple.c}| 166 
>  4 files changed, 171 insertions(+), 184 deletions(-)
>  delete mode 100644 drivers/video/console_normal.c
>  rename drivers/video/{console_rotate.c => console_simple.c} (75%)

Regards,
Simon


Re: Rockchip RK3328 4-byte addressing problem in SPI

2022-12-29 Thread Simon Glass
+Kever Yang

On Thu, 22 Dec 2022 at 18:30, Marcin Woźniak  wrote:
>
> Hello,
>
> I would like to let you know how i've lost about 2 weeks because of lack
> of Rockchip BOOTROM documentation.
>
> I tried to use Mainline Uboot to Boot NanoPI R2S using soldered SPI
> Winbond 25Q256 chip.
>
> I had to make some patches in Uboot core files to make it work.
>
> First one adds SPI boot device. File
> |arch/arm/mach-rockchip/rk3328/rk3328.c with adding: |
>
> |[BROM_BOOTSOURCE_SPINOR] "/spi@ff19", |const char * const
> boot_devices ||
>
> Second was |arch/arm/mach-rockchip/spl-boot-order.c and last if statement:|
>
> |if (!uclass_get_device_by_of_offset(UCLASS_SPI, node, )) return
> BOOT_DEVICE_SPI;|
>
> ||
>
> This patch is added because RockChip SPI driver is using UCLASS_SPI
> instead of SPI_FLASH so boot device wasn't connecting with right DM
> Driver rk_spi.c
>
> Third one fixed SPL and it was added at the end: |drivers/spi/rk_spi.c
> |
>
> |DM_DRIVER_ALIAS(rockchip_rk3288_spi, rockchip_rk3328_spi);|
>
> After that board booted successfully. Second bigger problem was a
> mistake and lack of RockChip Bootrom documentation.
>
> I've soldered 32Mbyte Flash and didn't know that U-Boot in SPL was
> switching it's 3-byte address mode to 4-byte one to gain access to full
> 32 Mbytes.
>
> The problem was that board booted in cold-start but after issuing
> "reset" - it was going to MASKROM mode like no SPI was soldered or empty.
>
> After loosing two weeks i figured that RockChip bootrom talks to SPI
> using only 3-byte addressing.
>
> So leaving 4-byte switched by UBoot SPI chip made it unusable to
> RockChip Bootrom. I found this by dumping Bootrom and decompiling it.
>
> I don't know if it's enough information to make a patch to MainLine  (at
> least for SPI boot in RK3328).
>
> Problem with 3-byte addressing is a complete different story.
>
> Sorry for my "unproffesional" mail. I am writing this type of message
> for a first time.
>
> Marcin
>
>
>
> ||
>
> 
>
> ||


Re: [PATCH 2/2] test: compression: use ut_assert for errors

2022-12-29 Thread Simon Glass
On Wed, 28 Dec 2022 at 16:54, Brandon Maier  wrote:
>
> Use the ut_assert macros for more useful error messages.
>
> Signed-off-by: Brandon Maier 
> ---
>  test/compression.c | 56 +-
>  1 file changed, 25 insertions(+), 31 deletions(-)
>

Reviewed-by: Simon Glass 


Re: [PATCH 1/2] test: compression: check with trailing garbage in input

2022-12-29 Thread Simon Glass
On Wed, 28 Dec 2022 at 16:54, Brandon Maier  wrote:
>
> The Linux kernel appends 4 bytes to the end of compressed kernel Images
> containing the uncompressed image size. They are used to make
> self-decompressing Images easier. However for archs that don't support
> self-decompression, like ARM64, U-Boot must be able to decompress the
> image with the garbage data.
>
> The existing decompressors already support this. This unit test was
> added while working on zstd support as upstream zstd will error if there
> is garbage data in the input buffer, and special care was needed to
> support this.
>
> Signed-off-by: Brandon Maier 
> ---
>  test/compression.c | 9 +
>  1 file changed, 9 insertions(+)

Reviewed-by: Simon Glass 


Re: [PATCH 5/5] video console: remove unused 4x6 font

2022-12-29 Thread Simon Glass
Hi Dzmitry,

On Mon, 26 Dec 2022 at 13:50, Dzmitry Sankouski  wrote:
>
> Remove video_font_4x6.h file because it's unused.
>
> Signed-off-by: Dzmitry Sankouski 
> ---
>  drivers/video/Kconfig|6 -
>  include/video_font.h |4 +-
>  include/video_font_4x6.h | 2155 --
>  3 files changed, 1 insertion(+), 2164 deletions(-)
>  delete mode 100644 include/video_font_4x6.h
>

I do think this is useful, e.g. on small displays. How about adding a
Kconfig for it instead?

Regards,
Simon


Re: [PATCH 2/2] cmd: net: wget: fix Kconfig dependency

2022-12-29 Thread Simon Glass
On Wed, 28 Dec 2022 at 09:27, Michael Walle  wrote:
>
> The wget command uses TCP, but fails to select PROT_TCP in Kconfig.
> Instead it selects the non-existing symbol TCP. Fix the typo.
>
> Signed-off-by: Michael Walle 
> ---
>  cmd/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Simon Glass 


Re: [PATCH] CI: Rework rockchip jobs in Azure

2022-12-29 Thread Simon Glass
On Tue, 27 Dec 2022 at 10:48, Tom Rini  wrote:
>
> The rockchip job is getting close to the hard time limit in Azure for
> the free tier. Split this in to 32bit and 64bit board jobs.
>
> Signed-off-by: Tom Rini 
> ---
>  .azure-pipelines.yml | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)

Reviewed-by: Simon Glass 


Re: [PATCH v2 2/2] test: compression: add zstd uncompression test

2022-12-29 Thread Simon Glass
Hi Brandon,

On Tue, 27 Dec 2022 at 11:45, Maier, Brandon L Collins
 wrote:
>
> Hi Sean,
>
> > From: Sean Anderson 
> > On 12/27/22 09:46, Brandon Maier wrote:
> > > +static const unsigned long zstd_compressed_size = 197;
> >
> > You can use ARRAY_SIZE (or sizeof) for this.
>
> sizeof() - 1 as it's a string, but I had put the size here manually as that's 
> what all the other tests do. I can switch them all to sizeof() if that is 
> preferred.

Yes I think it is better too, but please change the others in a separate patch.

Regards,
Simon


Re: Broken socrates board (Was: Re: Broken commit de47ff536363289f92f85ed1e4901724d238432d)

2022-12-29 Thread Simon Glass
Hi Pali,

On Wed, 28 Dec 2022 at 11:51, Pali Rohár  wrote:
>
> On Wednesday 28 December 2022 17:50:43 Pali Rohár wrote:
> > And back to this issue...
> >
> > On Tuesday 02 August 2022 11:13:38 Pali Rohár wrote:
> > > Hello Tom!
> > >
> > > Your commit de47ff536363289f92f85ed1e4901724d238432d ("Convert
> > > CONFIG_SYS_MPC85XX_NO_RESETVEC to Kconfig") seems to be broken.
> > >
> > > If you look at P1020RDB-PD_defconfig file change in this commit there is:
> > >
> > > --- a/configs/P1020RDB-PD_defconfig
> > > +++ b/configs/P1020RDB-PD_defconfig
> > > @@ -9,6 +9,7 @@ CONFIG_MPC85xx=y
> > >  # CONFIG_CMD_ERRATA is not set
> > >  CONFIG_TARGET_P1020RDB_PD=y
> > >  CONFIG_MPC85XX_HAVE_RESET_VECTOR=y
> > > +CONFIG_SYS_MPC85XX_NO_RESETVEC=y
> > >  CONFIG_MP=y
> > >  CONFIG_FIT=y
> > >  CONFIG_FIT_VERBOSE=y
> > >
> > > Which does not make sense to me.
> > >
> > > First thing is that CONFIG_MPC85XX_HAVE_RESET_VECTOR and
> > > CONFIG_SYS_MPC85XX_NO_RESETVEC are exclusive options. You can either
> > > disable generating of reset vector in image or enable it. What is
> > > expected from the result when you ask Kconfig to both enable and disable
> > > it? First specified option win? Or last specified win? Or random of
> > > those two options win? It is not really clear for me.
> >
> > Experiments proved that CONFIG_SYS_MPC85XX_NO_RESETVEC wins over
> > CONFIG_MPC85XX_HAVE_RESET_VECTOR. So problematic commit
> > de47ff536363289f92f85ed1e4901724d238432d effectively disabled reset
> > vectors in more defconfig files.
> >
> > > Second thing is that reset vector is required for (parallel) NOR booting
> > > and your change is adding CONFIG_SYS_MPC85XX_NO_RESETVEC=y to defconfig
> > > for NOR, which to my guess make image non-bootable and broken.
> >
> > And this is truth. CONFIG_SYS_MPC85XX_NO_RESETVEC=y in defconfig broke
> > booting from parallel FLASH NOR memory. Without reset vector, u-boot
> > from FLASH cannot be booted.
> >
> > When I manually disabled CONFIG_SYS_MPC85XX_NO_RESETVEC for P2020 then
> > together with CONFIG_SDCARD fix, I was able to boot U-Boot from FLASH.
> >
> > So kconfig conversion in commit de47ff536363289f92f85ed1e4901724d238432d
> > was done incorrectly. Because in 2022.04 CONFIG_SYS_MPC85XX_NO_RESETVEC
> > was really not enabled in config.h for FLASH defconfigs.
> >
> > > And seems that other defconfig files in that change have similar issues.
> >
> > Tom, would you fix this commit de47ff536363289f92f85ed1e4901724d238432d
> > too? I do not know how you did that kconfig conversion but fix could be
> > straightforward. By boolean logic CONFIG_MPC85XX_HAVE_RESET_VECTOR xor
> > CONFIG_SYS_MPC85XX_NO_RESETVEC can be defined. Not both at the same
> > time.
> >
> > By moveconfig.py following defconfigs are affected:
> >
> > $ ./tools/moveconfig.py -f MPC85XX_HAVE_RESET_VECTOR SYS_MPC85XX_NO_RESETVEC
> > 9 matches
> > P1020RDB-PC P1010RDB-PB_36BIT_NOR P1010RDB-PA_36BIT_NOR P1020RDB-PC_36BIT 
> > P1010RDB-PA_NOR P1010RDB-PB_NOR P2020RDB-PC P2020RDB-PC_36BIT P1020RDB-PD
>
> And there is one _interesting_ board:
>
> $ for arch in `git grep 'config ARCH' arch/powerpc/cpu/mpc85xx/Kconfig | sed 
> 's/.* //'`; do ./tools/moveconfig.py -f $arch ~MPC85XX_HAVE_RESET_VECTOR 
> ~SYS_MPC85XX_NO_RESETVEC; done | grep -v ' matches\|^$'
> socrates
>
> (I do not know how to easily tell moveconfig.py to do OR, so I called in
> more times in loop).
>
> socrates_defconfig is the only one mpc85xx board which does not have
> enabled reset vectors nor disabled reset vectors.
>
> As it boots from flash too, it should have reset vector in its binary.
> I have looked into compiled u-boot ELF binary and reset vector is there.
> So good.
>
> But in u-boot.bin binary it is not, so it is broken.
>
> Checking with v2022.04 release and it is quite interesting. U-Boot build
> process produce more *.bin binaries:
>
> -rw-r--r-- 1 pali pali 530613 dec 28 17:57 u-boot.bin
> -rw-r--r-- 1 pali pali 530613 dec 28 17:57 u-boot-dtb.bin
> -rwxr-xr-x 1 pali pali 524288 dec 28 17:57 u-boot-nodtb.bin
> -rw-r--r-- 1 pali pali 655360 dec 28 17:57 u-boot-socrates.bin
>
> u-boot.bin and u-boot-dtb.bin are broken. u-boot-nodtb.bin is
> intermediate and u-boot-socrates.bin seems to be correct (contains reset
> vector at correct offset and also has DTB file in it).
>
> U-Boot master build only broken u-boot.bin and does *not* build correct
> u-boot-socrates.bin.
>
> I bisected this issue why u-boot-socrates.bin stopped being building.
> And reason is my commit 5af42eafd7e1 ("Makefile: Reduce usage of custom
> mpc85xx u-boot.bin target"). It is binman who built "correct" binary and
> that commit deselected it.
>
> I looked again at CONFIG_MPC85XX_HAVE_RESET_VECTOR symbol and its
> meaning is currently "build only intermediate binaries for binman,
> separate one for u-boot main code, separate one for reset vector,
> separate for DTB and let binman to merge them via standard powerpc
> config binman file arch/powerpc/dts/u-boot.dtsi to output u-boot.bin."
>

Re: [PATCH 1/2] net: wget: fix implicit declaration

2022-12-29 Thread Simon Glass
On Wed, 28 Dec 2022 at 09:27, Michael Walle  wrote:
>
> The compiler complains about the missing declaration of print_size():
> net/wget.c:415:3: warning: implicit declaration of function ‘print_size’ 
> [-Wimplicit-function-declaration]
>
> Fix it.
>
> Signed-off-by: Michael Walle 
> ---
>  net/wget.c | 1 +
>  1 file changed, 1 insertion(+)

Reviewed-by: Simon Glass 


Re: [PATCH v3 2/3] net: fm: Add firmware name parameter

2022-12-29 Thread Simon Glass
Hi Sean,

On Thu, 29 Dec 2022 at 10:53, Sean Anderson  wrote:
>
> In order to read the firmware from the filesystem, we need a file name.
> Read the firmware name from the device tree, using the firmware-name
> property. This property is commonly used in Linux to determine the
> correct name to use (and can be seen in several device trees in U-Boot).
>
> Signed-off-by: Sean Anderson 
> Reviewed-by: Ramon Fried 
> ---
>
> (no changes since v1)
>
>  drivers/net/fm/fm.c | 15 ---
>  drivers/net/fm/fm.h |  2 +-
>  2 files changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/fm/fm.c b/drivers/net/fm/fm.c
> index 055dd61fbe..457200e766 100644
> --- a/drivers/net/fm/fm.c
> +++ b/drivers/net/fm/fm.c
> @@ -8,6 +8,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -353,7 +354,7 @@ static void fm_init_qmi(struct fm_qmi_common *qmi)
>
>  /* Init common part of FM, index is fm num# like fm as above */
>  #ifdef CONFIG_TFABOOT
> -int fm_init_common(int index, struct ccsr_fman *reg)
> +int fm_init_common(int index, struct ccsr_fman *reg, const char 
> *firmware_name)
>  {
> int rc;
> void *addr = NULL;
> @@ -448,7 +449,7 @@ int fm_init_common(int index, struct ccsr_fman *reg)
> return fm_init_bmi(index, >fm_bmi_common);
>  }
>  #else
> -int fm_init_common(int index, struct ccsr_fman *reg)
> +int fm_init_common(int index, struct ccsr_fman *reg, const char 
> *firmware_name)
>  {
> int rc;
>  #if defined(CONFIG_SYS_QE_FMAN_FW_IN_NOR)
> @@ -561,6 +562,8 @@ static const struct udevice_id fman_ids[] = {
>
>  static int fman_probe(struct udevice *dev)
>  {
> +   const char *firmware_name = NULL;
> +   int ret;
> struct fman_priv *priv = dev_get_priv(dev);
>
> priv->reg = (struct ccsr_fman *)(uintptr_t)dev_read_addr(dev);
> @@ -570,7 +573,13 @@ static int fman_probe(struct udevice *dev)
> return -EINVAL;
> }
>
> -   return fm_init_common(priv->fman_id, priv->reg);
> +   ret = dev_read_string_index(dev, "firmware-name", 0, _name);
> +   if (ret && ret != -EINVAL) {
> +   dev_dbg(dev, "Could not read firmware-name\n");
> +   return ret;
> +   }
> +
> +   return fm_init_common(priv->fman_id, priv->reg, firmware_name);
>  }
>
>  static int fman_remove(struct udevice *dev)
> diff --git a/drivers/net/fm/fm.h b/drivers/net/fm/fm.h
> index ba858cc24b..a2d5b03429 100644
> --- a/drivers/net/fm/fm.h
> +++ b/drivers/net/fm/fm.h
> @@ -106,7 +106,7 @@ struct fm_port_global_pram {
>
>  void *fm_muram_alloc(int fm_idx, size_t size, ulong align);
>  void *fm_muram_base(int fm_idx);
> -int fm_init_common(int index, struct ccsr_fman *reg);
> +int fm_init_common(int index, struct ccsr_fman *reg, const char 
> *firmware_name);

Please add a full function comment.

>  int fm_eth_initialize(struct ccsr_fman *reg, struct fm_eth_info *info);
>  phy_interface_t fman_port_enet_if(enum fm_port port);
>  void fman_disable_port(enum fm_port port);
> --
> 2.35.1.1320.gc452695387.dirty
>

Regards,
Simon


Re: [PATCH v3 3/3] net: fm: Support loading firmware from a filesystem

2022-12-29 Thread Simon Glass
Hi Sean,

On Thu, 29 Dec 2022 at 10:54, Sean Anderson  wrote:
>
> This adds a new method to load Fman firmware from a filesystem. This
> allows users to use regular files instead of hard-coded offsets for the
> firmware.
>
> Signed-off-by: Sean Anderson 
> Reviewed-by: Ramon Fried 
> ---
>
> (no changes since v1)
>
>  drivers/net/fm/fm.c | 25 -
>  drivers/qe/Kconfig  |  4 
>  2 files changed, 28 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/fm/fm.c b/drivers/net/fm/fm.c
> index 457200e766..e1fba24471 100644
> --- a/drivers/net/fm/fm.c
> +++ b/drivers/net/fm/fm.c
> @@ -5,6 +5,7 @@
>   */
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -452,7 +453,29 @@ int fm_init_common(int index, struct ccsr_fman *reg, 
> const char *firmware_name)
>  int fm_init_common(int index, struct ccsr_fman *reg, const char 
> *firmware_name)
>  {
> int rc;
> -#if defined(CONFIG_SYS_QE_FMAN_FW_IN_NOR)
> +#if defined(CONFIG_SYS_QE_FMAN_FW_IN_FS)

Cam this use C code?

> +   struct udevice *fs_loader;
> +   void *addr = malloc(CONFIG_SYS_QE_FMAN_FW_LENGTH);

For this you can use something like:

IF_ENABLED_INT(CONFIG_SYS_QE_FMAN_FW_IN_FS, CONFIG_SYS_QE_FMAN_FW_LENGTH)

so that C works

> +
> +   if (!addr)
> +   return -ENOMEM;
> +
> +   rc = get_fs_loader(_loader);
> +   if (rc) {
> +   debug("could not get fs loader: %d\n", rc);
> +   return rc;
> +   }
> +
> +   if (!firmware_name)
> +   firmware_name = "fman.itb";
> +
> +   rc = request_firmware_into_buf(fs_loader, firmware_name, addr,
> +  CONFIG_SYS_QE_FMAN_FW_LENGTH, 0);
> +   if (rc < 0) {
> +   debug("could not request %s: %d\n", firmware_name, rc);
> +   return rc;
> +   }
> +#elif defined(CONFIG_SYS_QE_FMAN_FW_IN_NOR)
> void *addr = (void *)CONFIG_SYS_FMAN_FW_ADDR;
>  #elif defined(CONFIG_SYS_QE_FMAN_FW_IN_NAND)
> size_t fw_length = CONFIG_SYS_QE_FW_LENGTH;
> diff --git a/drivers/qe/Kconfig b/drivers/qe/Kconfig
> index c44a81f69a..89a75c175b 100644
> --- a/drivers/qe/Kconfig
> +++ b/drivers/qe/Kconfig
> @@ -27,6 +27,10 @@ choice
> depends on FMAN_ENET || QE
> default SYS_QE_FMAN_FW_IN_ROM
>
> +config SYS_QE_FMAN_FW_IN_FS
> +   depends on FS_LOADER && FMAN_ENET
> +   bool "Filesystem"

Should this be a choice? In any case it needs some decent help!
e
> +
>  config SYS_QE_FMAN_FW_IN_NOR
> bool "NOR flash"
>
> --
> 2.35.1.1320.gc452695387.dirty
>

Regards,
Simon


Re: [PATCH u-boot] ata: Fix dependency for CONFIG_SATA_SIL

2022-12-29 Thread Simon Glass
On Thu, 29 Dec 2022 at 11:15, Pali Rohár  wrote:
>
> sata_sil.c is PCI driver and without CONFIG_PCI is building of U-Boot failing:
>
>   LD  u-boot
> ld.bfd: drivers/ata/sata_sil.o: in function `sil_exec_cmd':
> drivers/ata/sata_sil.c:148: undefined reference to `dm_pci_phys_to_bus'
> ld.bfd: drivers/ata/sata_sil.o: in function `sil_pci_probe':
> drivers/ata/sata_sil.c:687: undefined reference to `dm_pci_get_bdf'
> ld.bfd: drivers/ata/sata_sil.c:691: undefined reference to 
> `dm_pci_read_config16'
> ld.bfd: drivers/ata/sata_sil.c:701: undefined reference to 
> `dm_pci_map_bar'
> ld.bfd: drivers/ata/sata_sil.c:704: undefined reference to 
> `dm_pci_map_bar'
> ld.bfd: drivers/ata/sata_sil.c:713: undefined reference to 
> `dm_pci_write_config16'
> ld.bfd: drivers/ata/sata_sil.c:717: undefined reference to 
> `dm_pci_read_config16'
> ld.bfd: drivers/ata/sata_sil.o: in function `sil_cmd_identify_device':
> drivers/ata/sata_sil.c:256: undefined reference to `dm_pci_phys_to_bus'
> ld.bfd: drivers/ata/sata_sil.o: in function `sil_sata_rw_cmd':
> drivers/ata/sata_sil.c:330: undefined reference to `dm_pci_phys_to_bus'
> ld.bfd: drivers/ata/sata_sil.o: in function `sil_sata_rw_cmd_ext':
> drivers/ata/sata_sil.c:377: undefined reference to `dm_pci_phys_to_bus'
> make: *** [Makefile:1778: u-boot] Error 1
>
> Signed-off-by: Pali Rohár 
> ---
>  drivers/ata/Kconfig | 1 +
>  1 file changed, 1 insertion(+)

Reviewed-by: Simon Glass 


Re: sandbox: "Reset Status: WARM Reset Status: COLD"

2022-12-29 Thread Simon Glass
Hi Heinrich,

On Thu, 29 Dec 2022 at 03:18, Heinrich Schuchardt  wrote:
>
> Hello Simon,
>
> the sandbox prints the following line when started:
> "Reset Status: WARM Reset Status: COLD"

This seems to be when you use the -T flag.

>
> This does not make much sense. Either the last reset was WARM or COLD
> but not both.
>

Indeed!

> sandbox_sysreset_get_status() and sandbox_warm_sysreset_get_status()
> should determine the reset status before printing anything incorrect.
>
> After executing the reset command
>
> state->last_sysreset == 4
>
> This cannot be correct. It seems to be due to:
>
> arch/sandbox/cpu/state.c:365:   state->last_sysreset = SYSRESET_COUNT;
>
> state_reset_for_test() should only be called in tests.

It needs to be called at init also. But actually the name is
confusing. How about state_reset_common() or something like that?

For testing we have two sysreset devices. Perhaps print_resetinfo()
should only print the first?

Regards,
Simon


Re: [PATCH] PowerPC: Update dependencies on *SYS_MPC85XX_NO_RESETVEC

2022-12-29 Thread Tom Rini
On Thu, Dec 29, 2022 at 09:50:03AM -0500, Tom Rini wrote:

> In 96699f097a02 ("powerpc: mpc85xx: Use binman to embed dtb inside
> U-Boot") we introduce CONFIG_MPC85XX_HAVE_RESET_VECTOR and do so via
> Kconfig. However, much later in de47ff536363 ("Convert
> CONFIG_SYS_MPC85XX_NO_RESETVEC to Kconfig") I converted the symbol that
> is the inverse of this to Kconfig. This should have included a
> dependency on the first symbol as they are logically opposite.
> 
> The dependency being missing lead to some platforms being broken at
> runtime due to discarding the require reset vector.
> 
> Fixes: de47ff536363 ("Convert CONFIG_SYS_MPC85XX_NO_RESETVEC to Kconfig")
> Reported-by: Pali Rohár 
> Signed-off-by: Tom Rini 
> Tested-by: Pali Rohár 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] PowerPC: Rework PBL location choice

2022-12-29 Thread Tom Rini
On Wed, Dec 28, 2022 at 10:52:51AM -0500, Tom Rini wrote:

> When converting CONFIG_SDCARD and CONFIG_SPIFLASH to Kconfig, one set of
> uses wasn't converted correctly. Allow for the case where platforms
> don't rely on "PBL" to boot but instead use other mechanisms. See the
> link below for more details.
> 
> Link: https://lore.kernel.org/all/20220802091338.f4g45ldhc7qbg6hm@pali/
> Fixes: d433c74eecdc ("Convert CONFIG_SDCARD et al to Kconfig")
> Tested-by: Pali Rohár 
> Signed-off-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 2/2] cmd: net: wget: fix Kconfig dependency

2022-12-29 Thread Tom Rini
On Wed, Dec 28, 2022 at 04:27:15PM +0100, Michael Walle wrote:

> The wget command uses TCP, but fails to select PROT_TCP in Kconfig.
> Instead it selects the non-existing symbol TCP. Fix the typo.
> 
> Signed-off-by: Michael Walle 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 1/2] net: wget: fix implicit declaration

2022-12-29 Thread Tom Rini
On Wed, Dec 28, 2022 at 04:27:14PM +0100, Michael Walle wrote:

> The compiler complains about the missing declaration of print_size():
> net/wget.c:415:3: warning: implicit declaration of function ‘print_size’ 
> [-Wimplicit-function-declaration]
> 
> Fix it.
> 
> Signed-off-by: Michael Walle 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] CI: Rework rockchip jobs in Azure

2022-12-29 Thread Tom Rini
On Tue, Dec 27, 2022 at 11:48:08AM -0500, Tom Rini wrote:

> The rockchip job is getting close to the hard time limit in Azure for
> the free tier. Split this in to 32bit and 64bit board jobs.
> 
> Signed-off-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: Pull request for efi-2023-01-rc5-2

2022-12-29 Thread Tom Rini
On Thu, Dec 29, 2022 at 02:54:07PM +0100, Heinrich Schuchardt wrote:

> The following changes since commit adcee0791f3318ead9b22879e2ce9409f400dcab:
> 
>   Merge https://source.denx.de/u-boot/custodians/u-boot-pmic
> (2022-12-26 21:00:20 -0500)
> 
> are available in the Git repository at:
> 
>   https://source.denx.de/u-boot/custodians/u-boot-efi.git
> tags/efi-2023-01-rc5-2
> 
> for you to fetch changes up to f557cf08b974c359ad3c53a87297d19fe13ff4f0:
> 
>   efi_loader: use u16_strlen() in efi_var_mem_ins() (2022-12-29
> 12:52:39 +0100)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] PowerPC: Update dependencies on *SYS_MPC85XX_NO_RESETVEC

2022-12-29 Thread Pali Rohár
On Thursday 29 December 2022 09:50:03 Tom Rini wrote:
> In 96699f097a02 ("powerpc: mpc85xx: Use binman to embed dtb inside
> U-Boot") we introduce CONFIG_MPC85XX_HAVE_RESET_VECTOR and do so via
> Kconfig. However, much later in de47ff536363 ("Convert
> CONFIG_SYS_MPC85XX_NO_RESETVEC to Kconfig") I converted the symbol that
> is the inverse of this to Kconfig. This should have included a
> dependency on the first symbol as they are logically opposite.
> 
> The dependency being missing lead to some platforms being broken at
> runtime due to discarding the require reset vector.
> 
> Fixes: de47ff536363 ("Convert CONFIG_SYS_MPC85XX_NO_RESETVEC to Kconfig")
> Reported-by: Pali Rohár 
> Signed-off-by: Tom Rini 

Tested-by: Pali Rohár 

Together with "PowerPC: Rework PBL location choice" patch, U-Boot can be
booted on P2020 based board from FLASH NOR (P2020RDB-PC_defconfig) and
also from SD card (P2020RDB-PC_SDCARD_defconfig).

Thanks for this patch!!

> ---
>  arch/powerpc/cpu/mpc85xx/Kconfig| 6 +++---
>  configs/P1010RDB-PA_36BIT_NOR_defconfig | 1 -
>  configs/P1010RDB-PA_NOR_defconfig   | 1 -
>  configs/P1010RDB-PB_36BIT_NOR_defconfig | 1 -
>  configs/P1010RDB-PB_NOR_defconfig   | 1 -
>  configs/P1020RDB-PC_36BIT_defconfig | 1 -
>  configs/P1020RDB-PC_defconfig   | 1 -
>  configs/P1020RDB-PD_defconfig   | 1 -
>  configs/P2020RDB-PC_36BIT_defconfig | 1 -
>  configs/P2020RDB-PC_defconfig   | 1 -
>  10 files changed, 3 insertions(+), 12 deletions(-)
> 
> diff --git a/arch/powerpc/cpu/mpc85xx/Kconfig 
> b/arch/powerpc/cpu/mpc85xx/Kconfig
> index 24d3f1f20c25..9d12bf168d95 100644
> --- a/arch/powerpc/cpu/mpc85xx/Kconfig
> +++ b/arch/powerpc/cpu/mpc85xx/Kconfig
> @@ -1459,14 +1459,14 @@ config SYS_FSL_USB_DUAL_PHY_ENABLE
>  
>  config SYS_MPC85XX_NO_RESETVEC
>   bool "Discard resetvec section and move bootpg section up"
> - depends on MPC85xx
> + depends on MPC85xx && !MPC85XX_HAVE_RESET_VECTOR
>   help
> If this variable is specified, the section .resetvec is not kept and
> the section .bootpg is placed in the previous 4k of the .text section.
>  
>  config SPL_SYS_MPC85XX_NO_RESETVEC
>   bool "Discard resetvec section and move bootpg section up, in SPL"
> - depends on MPC85xx && SPL
> + depends on MPC85xx && SPL && !MPC85XX_HAVE_RESET_VECTOR
>   help
> If this variable is specified, the section .resetvec is not kept and
> the section .bootpg is placed in the previous 4k of the .text section,
> @@ -1474,7 +1474,7 @@ config SPL_SYS_MPC85XX_NO_RESETVEC
>  
>  config TPL_SYS_MPC85XX_NO_RESETVEC
>   bool "Discard resetvec section and move bootpg section up, in TPL"
> - depends on MPC85xx && TPL
> + depends on MPC85xx && TPL && !MPC85XX_HAVE_RESET_VECTOR
>   help
> If this variable is specified, the section .resetvec is not kept and
> the section .bootpg is placed in the previous 4k of the .text section,
> diff --git a/configs/P1010RDB-PA_36BIT_NOR_defconfig 
> b/configs/P1010RDB-PA_36BIT_NOR_defconfig
> index dcf74f5d6af5..42f736350a40 100644
> --- a/configs/P1010RDB-PA_36BIT_NOR_defconfig
> +++ b/configs/P1010RDB-PA_36BIT_NOR_defconfig
> @@ -10,7 +10,6 @@ CONFIG_SYS_INIT_RAM_LOCK=y
>  CONFIG_TARGET_P1010RDB_PA=y
>  CONFIG_MPC85XX_HAVE_RESET_VECTOR=y
>  CONFIG_ENABLE_36BIT_PHYS=y
> -CONFIG_SYS_MPC85XX_NO_RESETVEC=y
>  CONFIG_PCIE1=y
>  CONFIG_PCIE2=y
>  CONFIG_PHYS_64BIT=y
> diff --git a/configs/P1010RDB-PA_NOR_defconfig 
> b/configs/P1010RDB-PA_NOR_defconfig
> index 537d8bf576b0..587defcc79d8 100644
> --- a/configs/P1010RDB-PA_NOR_defconfig
> +++ b/configs/P1010RDB-PA_NOR_defconfig
> @@ -10,7 +10,6 @@ CONFIG_SYS_INIT_RAM_LOCK=y
>  CONFIG_TARGET_P1010RDB_PA=y
>  CONFIG_MPC85XX_HAVE_RESET_VECTOR=y
>  CONFIG_ENABLE_36BIT_PHYS=y
> -CONFIG_SYS_MPC85XX_NO_RESETVEC=y
>  CONFIG_PCIE1=y
>  CONFIG_PCIE2=y
>  CONFIG_SYS_MONITOR_LEN=786432
> diff --git a/configs/P1010RDB-PB_36BIT_NOR_defconfig 
> b/configs/P1010RDB-PB_36BIT_NOR_defconfig
> index 92a7e0966936..b772edf305b0 100644
> --- a/configs/P1010RDB-PB_36BIT_NOR_defconfig
> +++ b/configs/P1010RDB-PB_36BIT_NOR_defconfig
> @@ -10,7 +10,6 @@ CONFIG_SYS_INIT_RAM_LOCK=y
>  CONFIG_TARGET_P1010RDB_PB=y
>  CONFIG_MPC85XX_HAVE_RESET_VECTOR=y
>  CONFIG_ENABLE_36BIT_PHYS=y
> -CONFIG_SYS_MPC85XX_NO_RESETVEC=y
>  CONFIG_PCIE1=y
>  CONFIG_PCIE2=y
>  CONFIG_PHYS_64BIT=y
> diff --git a/configs/P1010RDB-PB_NOR_defconfig 
> b/configs/P1010RDB-PB_NOR_defconfig
> index 3e16470608e5..10ab2c04d660 100644
> --- a/configs/P1010RDB-PB_NOR_defconfig
> +++ b/configs/P1010RDB-PB_NOR_defconfig
> @@ -10,7 +10,6 @@ CONFIG_SYS_INIT_RAM_LOCK=y
>  CONFIG_TARGET_P1010RDB_PB=y
>  CONFIG_MPC85XX_HAVE_RESET_VECTOR=y
>  CONFIG_ENABLE_36BIT_PHYS=y
> -CONFIG_SYS_MPC85XX_NO_RESETVEC=y
>  CONFIG_PCIE1=y
>  CONFIG_PCIE2=y
>  CONFIG_SYS_MONITOR_LEN=786432
> diff --git a/configs/P1020RDB-PC_36BIT_defconfig 
> b/configs/P1020RDB-PC_36BIT_defconfig
> index 

[PATCH u-boot] ata: Fix dependency for CONFIG_SATA_SIL

2022-12-29 Thread Pali Rohár
sata_sil.c is PCI driver and without CONFIG_PCI is building of U-Boot failing:

  LD  u-boot
ld.bfd: drivers/ata/sata_sil.o: in function `sil_exec_cmd':
drivers/ata/sata_sil.c:148: undefined reference to `dm_pci_phys_to_bus'
ld.bfd: drivers/ata/sata_sil.o: in function `sil_pci_probe':
drivers/ata/sata_sil.c:687: undefined reference to `dm_pci_get_bdf'
ld.bfd: drivers/ata/sata_sil.c:691: undefined reference to 
`dm_pci_read_config16'
ld.bfd: drivers/ata/sata_sil.c:701: undefined reference to `dm_pci_map_bar'
ld.bfd: drivers/ata/sata_sil.c:704: undefined reference to `dm_pci_map_bar'
ld.bfd: drivers/ata/sata_sil.c:713: undefined reference to 
`dm_pci_write_config16'
ld.bfd: drivers/ata/sata_sil.c:717: undefined reference to 
`dm_pci_read_config16'
ld.bfd: drivers/ata/sata_sil.o: in function `sil_cmd_identify_device':
drivers/ata/sata_sil.c:256: undefined reference to `dm_pci_phys_to_bus'
ld.bfd: drivers/ata/sata_sil.o: in function `sil_sata_rw_cmd':
drivers/ata/sata_sil.c:330: undefined reference to `dm_pci_phys_to_bus'
ld.bfd: drivers/ata/sata_sil.o: in function `sil_sata_rw_cmd_ext':
drivers/ata/sata_sil.c:377: undefined reference to `dm_pci_phys_to_bus'
make: *** [Makefile:1778: u-boot] Error 1

Signed-off-by: Pali Rohár 
---
 drivers/ata/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index a063b221cd1f..3fe53d6d4f3a 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -135,6 +135,7 @@ config SATA_MV
 
 config SATA_SIL
bool "Enable Silicon Image SIL3131 / SIL3132 / SIL3124 SATA driver 
support"
+   depends on PCI
select AHCI
select LIBATA
help
-- 
2.20.1



[PATCH v3 3/3] net: fm: Support loading firmware from a filesystem

2022-12-29 Thread Sean Anderson
This adds a new method to load Fman firmware from a filesystem. This
allows users to use regular files instead of hard-coded offsets for the
firmware.

Signed-off-by: Sean Anderson 
Reviewed-by: Ramon Fried 
---

(no changes since v1)

 drivers/net/fm/fm.c | 25 -
 drivers/qe/Kconfig  |  4 
 2 files changed, 28 insertions(+), 1 deletion(-)

diff --git a/drivers/net/fm/fm.c b/drivers/net/fm/fm.c
index 457200e766..e1fba24471 100644
--- a/drivers/net/fm/fm.c
+++ b/drivers/net/fm/fm.c
@@ -5,6 +5,7 @@
  */
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -452,7 +453,29 @@ int fm_init_common(int index, struct ccsr_fman *reg, const 
char *firmware_name)
 int fm_init_common(int index, struct ccsr_fman *reg, const char *firmware_name)
 {
int rc;
-#if defined(CONFIG_SYS_QE_FMAN_FW_IN_NOR)
+#if defined(CONFIG_SYS_QE_FMAN_FW_IN_FS)
+   struct udevice *fs_loader;
+   void *addr = malloc(CONFIG_SYS_QE_FMAN_FW_LENGTH);
+
+   if (!addr)
+   return -ENOMEM;
+
+   rc = get_fs_loader(_loader);
+   if (rc) {
+   debug("could not get fs loader: %d\n", rc);
+   return rc;
+   }
+
+   if (!firmware_name)
+   firmware_name = "fman.itb";
+
+   rc = request_firmware_into_buf(fs_loader, firmware_name, addr,
+  CONFIG_SYS_QE_FMAN_FW_LENGTH, 0);
+   if (rc < 0) {
+   debug("could not request %s: %d\n", firmware_name, rc);
+   return rc;
+   }
+#elif defined(CONFIG_SYS_QE_FMAN_FW_IN_NOR)
void *addr = (void *)CONFIG_SYS_FMAN_FW_ADDR;
 #elif defined(CONFIG_SYS_QE_FMAN_FW_IN_NAND)
size_t fw_length = CONFIG_SYS_QE_FMAN_FW_LENGTH;
diff --git a/drivers/qe/Kconfig b/drivers/qe/Kconfig
index c44a81f69a..89a75c175b 100644
--- a/drivers/qe/Kconfig
+++ b/drivers/qe/Kconfig
@@ -27,6 +27,10 @@ choice
depends on FMAN_ENET || QE
default SYS_QE_FMAN_FW_IN_ROM
 
+config SYS_QE_FMAN_FW_IN_FS
+   depends on FS_LOADER && FMAN_ENET
+   bool "Filesystem"
+
 config SYS_QE_FMAN_FW_IN_NOR
bool "NOR flash"
 
-- 
2.35.1.1320.gc452695387.dirty



[PATCH v3 2/3] net: fm: Add firmware name parameter

2022-12-29 Thread Sean Anderson
In order to read the firmware from the filesystem, we need a file name.
Read the firmware name from the device tree, using the firmware-name
property. This property is commonly used in Linux to determine the
correct name to use (and can be seen in several device trees in U-Boot).

Signed-off-by: Sean Anderson 
Reviewed-by: Ramon Fried 
---

(no changes since v1)

 drivers/net/fm/fm.c | 15 ---
 drivers/net/fm/fm.h |  2 +-
 2 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/drivers/net/fm/fm.c b/drivers/net/fm/fm.c
index 055dd61fbe..457200e766 100644
--- a/drivers/net/fm/fm.c
+++ b/drivers/net/fm/fm.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -353,7 +354,7 @@ static void fm_init_qmi(struct fm_qmi_common *qmi)
 
 /* Init common part of FM, index is fm num# like fm as above */
 #ifdef CONFIG_TFABOOT
-int fm_init_common(int index, struct ccsr_fman *reg)
+int fm_init_common(int index, struct ccsr_fman *reg, const char *firmware_name)
 {
int rc;
void *addr = NULL;
@@ -448,7 +449,7 @@ int fm_init_common(int index, struct ccsr_fman *reg)
return fm_init_bmi(index, >fm_bmi_common);
 }
 #else
-int fm_init_common(int index, struct ccsr_fman *reg)
+int fm_init_common(int index, struct ccsr_fman *reg, const char *firmware_name)
 {
int rc;
 #if defined(CONFIG_SYS_QE_FMAN_FW_IN_NOR)
@@ -561,6 +562,8 @@ static const struct udevice_id fman_ids[] = {
 
 static int fman_probe(struct udevice *dev)
 {
+   const char *firmware_name = NULL;
+   int ret;
struct fman_priv *priv = dev_get_priv(dev);
 
priv->reg = (struct ccsr_fman *)(uintptr_t)dev_read_addr(dev);
@@ -570,7 +573,13 @@ static int fman_probe(struct udevice *dev)
return -EINVAL;
}
 
-   return fm_init_common(priv->fman_id, priv->reg);
+   ret = dev_read_string_index(dev, "firmware-name", 0, _name);
+   if (ret && ret != -EINVAL) {
+   dev_dbg(dev, "Could not read firmware-name\n");
+   return ret;
+   }
+
+   return fm_init_common(priv->fman_id, priv->reg, firmware_name);
 }
 
 static int fman_remove(struct udevice *dev)
diff --git a/drivers/net/fm/fm.h b/drivers/net/fm/fm.h
index ba858cc24b..a2d5b03429 100644
--- a/drivers/net/fm/fm.h
+++ b/drivers/net/fm/fm.h
@@ -106,7 +106,7 @@ struct fm_port_global_pram {
 
 void *fm_muram_alloc(int fm_idx, size_t size, ulong align);
 void *fm_muram_base(int fm_idx);
-int fm_init_common(int index, struct ccsr_fman *reg);
+int fm_init_common(int index, struct ccsr_fman *reg, const char 
*firmware_name);
 int fm_eth_initialize(struct ccsr_fman *reg, struct fm_eth_info *info);
 phy_interface_t fman_port_enet_if(enum fm_port port);
 void fman_disable_port(enum fm_port port);
-- 
2.35.1.1320.gc452695387.dirty



[PATCH v3 1/3] misc: fs_loader: Add function to get the chosen loader

2022-12-29 Thread Sean Anderson
The fs_loader device is used to pull in settings via the chosen node.
However, there was no library function for this, so arria10 was doing it
explicitly. This function subsumes that, and uses ofnode_get_chosen_node
instead of navigating the device tree directly. Because fs_loader pulls
its config from the environment by default, it's fine to create a device
with nothing backing it at all. Doing this allows enabling
CONFIG_FS_LOADER without needing to modify the device tree.

Signed-off-by: Sean Anderson 
Reviewed-by: Simon Glass 
Reviewed-by: Ramon Fried 
---

(no changes since v1)

 arch/arm/mach-k3/common.c |  2 +-
 arch/arm/mach-omap2/boot-common.c |  2 +-
 drivers/fpga/socfpga_arria10.c| 24 ++--
 drivers/misc/fs_loader.c  | 27 +++
 include/fs_loader.h   | 12 
 5 files changed, 43 insertions(+), 24 deletions(-)

diff --git a/arch/arm/mach-k3/common.c b/arch/arm/mach-k3/common.c
index d5e1f8e2e7..a2adb791f6 100644
--- a/arch/arm/mach-k3/common.c
+++ b/arch/arm/mach-k3/common.c
@@ -181,7 +181,7 @@ int load_firmware(char *name_fw, char *name_loadaddr, u32 
*loadaddr)
if (!*loadaddr)
return 0;
 
-   if (!uclass_get_device(UCLASS_FS_FIRMWARE_LOADER, 0, )) {
+   if (!get_fs_loader()) {
size = request_firmware_into_buf(fsdev, name, (void *)*loadaddr,
 0, 0);
}
diff --git a/arch/arm/mach-omap2/boot-common.c 
b/arch/arm/mach-omap2/boot-common.c
index d104f23b3e..9a342a1bf9 100644
--- a/arch/arm/mach-omap2/boot-common.c
+++ b/arch/arm/mach-omap2/boot-common.c
@@ -214,7 +214,7 @@ int load_firmware(char *name_fw, u32 *loadaddr)
if (!*loadaddr)
return 0;
 
-   if (!uclass_get_device(UCLASS_FS_FIRMWARE_LOADER, 0, )) {
+   if (!get_fs_loader()) {
size = request_firmware_into_buf(fsdev, name_fw,
 (void *)*loadaddr, 0, 0);
}
diff --git a/drivers/fpga/socfpga_arria10.c b/drivers/fpga/socfpga_arria10.c
index 3b785e67d0..b69107aa33 100644
--- a/drivers/fpga/socfpga_arria10.c
+++ b/drivers/fpga/socfpga_arria10.c
@@ -787,32 +787,12 @@ int socfpga_loadfs(fpga_fs_info *fpga_fsinfo, const void 
*buf, size_t bsize,
u32 phandle;
 
node = get_fpga_mgr_ofnode(ofnode_null());
-
-   if (ofnode_valid(node)) {
-   phandle_p = ofnode_get_property(node, "firmware-loader", );
-   if (!phandle_p) {
-   node = ofnode_path("/chosen");
-   if (!ofnode_valid(node)) {
-   debug("FPGA: /chosen node was not found.\n");
-   return -ENOENT;
-   }
-
-   phandle_p = ofnode_get_property(node, "firmware-loader",
-  );
-   if (!phandle_p) {
-   debug("FPGA: firmware-loader property was not");
-   debug(" found.\n");
-   return -ENOENT;
-   }
-   }
-   } else {
+   if (!ofnode_valid(node)) {
debug("FPGA: FPGA manager node was not found.\n");
return -ENOENT;
}
 
-   phandle = fdt32_to_cpu(*phandle_p);
-   ret = uclass_get_device_by_phandle_id(UCLASS_FS_FIRMWARE_LOADER,
-phandle, );
+   ret = get_fs_loader();
if (ret)
return ret;
 
diff --git a/drivers/misc/fs_loader.c b/drivers/misc/fs_loader.c
index 5b4d03639c..ccf5c7a803 100644
--- a/drivers/misc/fs_loader.c
+++ b/drivers/misc/fs_loader.c
@@ -15,6 +15,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -297,6 +299,31 @@ U_BOOT_DRIVER(fs_loader) = {
.priv_auto  = sizeof(struct firmware),
 };
 
+static struct device_plat default_plat = { 0 };
+
+int get_fs_loader(struct udevice **dev)
+{
+   int ret;
+   ofnode node = ofnode_get_chosen_node("firmware-loader");
+
+   if (ofnode_valid(node))
+   return uclass_get_device_by_ofnode(UCLASS_FS_FIRMWARE_LOADER,
+  node, dev);
+
+   /* Try the first device if none was chosen */
+   ret = uclass_first_device_err(UCLASS_FS_FIRMWARE_LOADER, dev);
+   if (ret != -ENODEV)
+   return ret;
+
+   /* Just create a new device */
+   ret = device_bind(dm_root(), DM_DRIVER_GET(fs_loader), "default-loader",
+ _plat, ofnode_null(), dev);
+   if (ret)
+   return ret;
+
+   return device_probe(*dev);
+}
+
 UCLASS_DRIVER(fs_loader) = {
.id = UCLASS_FS_FIRMWARE_LOADER,
.name   = "fs-loader",
diff --git a/include/fs_loader.h b/include/fs_loader.h
index 

[PATCH v3 0/3] net: fm: Add support for loading firmware from filesystem

2022-12-29 Thread Sean Anderson
This adds support for loading Fman firmware from a filesystem using the
firmware loader subsystem. It was originally part of [1], but has been
split off because it is conceptually separate.

[1] 
https://lore.kernel.org/u-boot/20220324182306.2037094-1-sean.ander...@seco.com/

Changes in v3:
- Rebased onto u-boot/next

Changes in v2:
- Split series into two

Sean Anderson (3):
  misc: fs_loader: Add function to get the chosen loader
  net: fm: Add firmware name parameter
  net: fm: Support loading firmware from a filesystem

 arch/arm/mach-k3/common.c |  2 +-
 arch/arm/mach-omap2/boot-common.c |  2 +-
 drivers/fpga/socfpga_arria10.c| 24 ++-
 drivers/misc/fs_loader.c  | 27 +
 drivers/net/fm/fm.c   | 40 +++
 drivers/net/fm/fm.h   |  2 +-
 drivers/qe/Kconfig|  4 
 include/fs_loader.h   | 12 ++
 8 files changed, 84 insertions(+), 29 deletions(-)

-- 
2.35.1.1320.gc452695387.dirty



[PATCH] PowerPC: Update dependencies on *SYS_MPC85XX_NO_RESETVEC

2022-12-29 Thread Tom Rini
In 96699f097a02 ("powerpc: mpc85xx: Use binman to embed dtb inside
U-Boot") we introduce CONFIG_MPC85XX_HAVE_RESET_VECTOR and do so via
Kconfig. However, much later in de47ff536363 ("Convert
CONFIG_SYS_MPC85XX_NO_RESETVEC to Kconfig") I converted the symbol that
is the inverse of this to Kconfig. This should have included a
dependency on the first symbol as they are logically opposite.

The dependency being missing lead to some platforms being broken at
runtime due to discarding the require reset vector.

Fixes: de47ff536363 ("Convert CONFIG_SYS_MPC85XX_NO_RESETVEC to Kconfig")
Reported-by: Pali Rohár 
Signed-off-by: Tom Rini 
---
 arch/powerpc/cpu/mpc85xx/Kconfig| 6 +++---
 configs/P1010RDB-PA_36BIT_NOR_defconfig | 1 -
 configs/P1010RDB-PA_NOR_defconfig   | 1 -
 configs/P1010RDB-PB_36BIT_NOR_defconfig | 1 -
 configs/P1010RDB-PB_NOR_defconfig   | 1 -
 configs/P1020RDB-PC_36BIT_defconfig | 1 -
 configs/P1020RDB-PC_defconfig   | 1 -
 configs/P1020RDB-PD_defconfig   | 1 -
 configs/P2020RDB-PC_36BIT_defconfig | 1 -
 configs/P2020RDB-PC_defconfig   | 1 -
 10 files changed, 3 insertions(+), 12 deletions(-)

diff --git a/arch/powerpc/cpu/mpc85xx/Kconfig b/arch/powerpc/cpu/mpc85xx/Kconfig
index 24d3f1f20c25..9d12bf168d95 100644
--- a/arch/powerpc/cpu/mpc85xx/Kconfig
+++ b/arch/powerpc/cpu/mpc85xx/Kconfig
@@ -1459,14 +1459,14 @@ config SYS_FSL_USB_DUAL_PHY_ENABLE
 
 config SYS_MPC85XX_NO_RESETVEC
bool "Discard resetvec section and move bootpg section up"
-   depends on MPC85xx
+   depends on MPC85xx && !MPC85XX_HAVE_RESET_VECTOR
help
  If this variable is specified, the section .resetvec is not kept and
  the section .bootpg is placed in the previous 4k of the .text section.
 
 config SPL_SYS_MPC85XX_NO_RESETVEC
bool "Discard resetvec section and move bootpg section up, in SPL"
-   depends on MPC85xx && SPL
+   depends on MPC85xx && SPL && !MPC85XX_HAVE_RESET_VECTOR
help
  If this variable is specified, the section .resetvec is not kept and
  the section .bootpg is placed in the previous 4k of the .text section,
@@ -1474,7 +1474,7 @@ config SPL_SYS_MPC85XX_NO_RESETVEC
 
 config TPL_SYS_MPC85XX_NO_RESETVEC
bool "Discard resetvec section and move bootpg section up, in TPL"
-   depends on MPC85xx && TPL
+   depends on MPC85xx && TPL && !MPC85XX_HAVE_RESET_VECTOR
help
  If this variable is specified, the section .resetvec is not kept and
  the section .bootpg is placed in the previous 4k of the .text section,
diff --git a/configs/P1010RDB-PA_36BIT_NOR_defconfig 
b/configs/P1010RDB-PA_36BIT_NOR_defconfig
index dcf74f5d6af5..42f736350a40 100644
--- a/configs/P1010RDB-PA_36BIT_NOR_defconfig
+++ b/configs/P1010RDB-PA_36BIT_NOR_defconfig
@@ -10,7 +10,6 @@ CONFIG_SYS_INIT_RAM_LOCK=y
 CONFIG_TARGET_P1010RDB_PA=y
 CONFIG_MPC85XX_HAVE_RESET_VECTOR=y
 CONFIG_ENABLE_36BIT_PHYS=y
-CONFIG_SYS_MPC85XX_NO_RESETVEC=y
 CONFIG_PCIE1=y
 CONFIG_PCIE2=y
 CONFIG_PHYS_64BIT=y
diff --git a/configs/P1010RDB-PA_NOR_defconfig 
b/configs/P1010RDB-PA_NOR_defconfig
index 537d8bf576b0..587defcc79d8 100644
--- a/configs/P1010RDB-PA_NOR_defconfig
+++ b/configs/P1010RDB-PA_NOR_defconfig
@@ -10,7 +10,6 @@ CONFIG_SYS_INIT_RAM_LOCK=y
 CONFIG_TARGET_P1010RDB_PA=y
 CONFIG_MPC85XX_HAVE_RESET_VECTOR=y
 CONFIG_ENABLE_36BIT_PHYS=y
-CONFIG_SYS_MPC85XX_NO_RESETVEC=y
 CONFIG_PCIE1=y
 CONFIG_PCIE2=y
 CONFIG_SYS_MONITOR_LEN=786432
diff --git a/configs/P1010RDB-PB_36BIT_NOR_defconfig 
b/configs/P1010RDB-PB_36BIT_NOR_defconfig
index 92a7e0966936..b772edf305b0 100644
--- a/configs/P1010RDB-PB_36BIT_NOR_defconfig
+++ b/configs/P1010RDB-PB_36BIT_NOR_defconfig
@@ -10,7 +10,6 @@ CONFIG_SYS_INIT_RAM_LOCK=y
 CONFIG_TARGET_P1010RDB_PB=y
 CONFIG_MPC85XX_HAVE_RESET_VECTOR=y
 CONFIG_ENABLE_36BIT_PHYS=y
-CONFIG_SYS_MPC85XX_NO_RESETVEC=y
 CONFIG_PCIE1=y
 CONFIG_PCIE2=y
 CONFIG_PHYS_64BIT=y
diff --git a/configs/P1010RDB-PB_NOR_defconfig 
b/configs/P1010RDB-PB_NOR_defconfig
index 3e16470608e5..10ab2c04d660 100644
--- a/configs/P1010RDB-PB_NOR_defconfig
+++ b/configs/P1010RDB-PB_NOR_defconfig
@@ -10,7 +10,6 @@ CONFIG_SYS_INIT_RAM_LOCK=y
 CONFIG_TARGET_P1010RDB_PB=y
 CONFIG_MPC85XX_HAVE_RESET_VECTOR=y
 CONFIG_ENABLE_36BIT_PHYS=y
-CONFIG_SYS_MPC85XX_NO_RESETVEC=y
 CONFIG_PCIE1=y
 CONFIG_PCIE2=y
 CONFIG_SYS_MONITOR_LEN=786432
diff --git a/configs/P1020RDB-PC_36BIT_defconfig 
b/configs/P1020RDB-PC_36BIT_defconfig
index ce0ba0e37574..368fc79d50c5 100644
--- a/configs/P1020RDB-PC_36BIT_defconfig
+++ b/configs/P1020RDB-PC_36BIT_defconfig
@@ -11,7 +11,6 @@ CONFIG_SYS_INIT_RAM_LOCK=y
 CONFIG_TARGET_P1020RDB_PC=y
 CONFIG_MPC85XX_HAVE_RESET_VECTOR=y
 CONFIG_ENABLE_36BIT_PHYS=y
-CONFIG_SYS_MPC85XX_NO_RESETVEC=y
 CONFIG_PCIE1=y
 CONFIG_PCIE2=y
 CONFIG_PHYS_64BIT=y
diff --git a/configs/P1020RDB-PC_defconfig b/configs/P1020RDB-PC_defconfig
index aae886b75c4e..764ff06a47ca 100644
--- a/configs/P1020RDB-PC_defconfig
+++ 

Re: Possible bug in BTRFS w/ Duplication

2022-12-29 Thread Heinrich Schuchardt

On 12/28/22 21:51, Sam Winchenbach wrote:

Hello,

Hello, I have hit the following situation when trying to load files from a 
BTRFS partition with duplication enabled.

In the first example I read a 16KiB file - __btrfs_map_block() changes the 
length to something larger than the file being read. This works fine, as length 
is later clamped to the file size.

In the second example, __btrfs_map_block() changes the length parameter to 
something smaller than the file (the size of a stripe).  This seems to break 
this check here:

 read = len;
 num_copies = btrfs_num_copies(fs_info, logical, len);
 for (i = 1; i <= num_copies; i++) {
 ret = read_extent_data(fs_info, dest, logical, , i);
 if (ret < 0 || read != len) {
 continue;
 }
 finished = true;
 break;
 }

The problem being that read is always less than len.

I am not sure if __btrfs_map_block is changing "len" to the incorrect value, or if there 
is some logic in "read_extent_data" that isn't correct. Any pointers on how this code is 
supposed to work would be greatly appreciated.
Thanks.


Thanks for reporting the issue

$ scripts/get_maintainer.pl -f fs/btrfs/volumes.c

suggests to include

"Marek Behún"  (maintainer:BTRFS)
Qu Wenruo  (reviewer:BTRFS)
linux-bt...@vger.kernel.org

to the communication.

Best regards

Heinrich



=== EXAMPLE 2 ===
Zynq> load mmc 1:0 0 16K
[btrfs_file_read,fs/btrfs/inode.c:710] === read the aligned part ===
[btrfs_read_extent_reg,fs/btrfs/inode.c:458] before read_extent_data (ret = 0, 
read = 16384, len = 16384)
[read_extent_data,fs/btrfs/disk-io.c:547] before __btrfs_map_block (len = 16384)
[read_extent_data,fs/btrfs/disk-io.c:550] after __btrfs_map_block (len = 28672)
[read_extent_data,fs/btrfs/disk-io.c:565] before __btrfs_devread (len = 16384)
[read_extent_data,fs/btrfs/disk-io.c:568] after __btrfs_devread (len = 16384)
[btrfs_read_extent_reg,fs/btrfs/inode.c:460] after read_extent_data (ret = 0, 
read = 16384, len = 16384)
cur: 0, extent_num_bytes: 16384, aligned_end: 16384
16384 bytes read in 100 ms (159.2 KiB/s)

=== EXAMPLE 2 ===
Zynq> load mmc 1:0 0 32K
[btrfs_file_read,fs/btrfs/inode.c:710] === read the aligned part ===
[btrfs_read_extent_reg,fs/btrfs/inode.c:458] before read_extent_data (ret = 0, 
read = 32768, len = 32768)
[read_extent_data,fs/btrfs/disk-io.c:547] before __btrfs_map_block (len = 32768)
[read_extent_data,fs/btrfs/disk-io.c:550] after __btrfs_map_block (len = 12288)
[read_extent_data,fs/btrfs/disk-io.c:565] before __btrfs_devread (len = 12288)
[read_extent_data,fs/btrfs/disk-io.c:568] after __btrfs_devread (len = 12288)
[btrfs_read_extent_reg,fs/btrfs/inode.c:460] after read_extent_data (ret = 0, 
read = 12288, len = 32768)
[btrfs_read_extent_reg,fs/btrfs/inode.c:458] before read_extent_data (ret = 0, 
read = 12288, len = 32768)
[read_extent_data,fs/btrfs/disk-io.c:547] before __btrfs_map_block (len = 12288)
[read_extent_data,fs/btrfs/disk-io.c:550] after __btrfs_map_block (len = 12288)
[read_extent_data,fs/btrfs/disk-io.c:565] before __btrfs_devread (len = 12288)
[read_extent_data,fs/btrfs/disk-io.c:568] after __btrfs_devread (len = 12288)
[btrfs_read_extent_reg,fs/btrfs/inode.c:460] after read_extent_data (ret = 0, 
read = 12288, len = 32768)
file: fs/btrfs/inode.c, line: 468
cur: 0, extent_num_bytes: 32768, aligned_end: 32768
-> btrfs_read_extent_reg: -5, line: 758
BTRFS: An error occurred while reading file 32K
Failed to load '32K'





Sam Winchenbach
Embedded Software Engineer III
Tethers Unlimited, Inc. | Connect Your Universe | www.tethers.com
swinchenb...@tethers.com | C: 207-974-6934
11711 North Creek Pkwy # D113, Bothell, WA 98011-8808, USA




Pull request for efi-2023-01-rc5-2

2022-12-29 Thread Heinrich Schuchardt

The following changes since commit adcee0791f3318ead9b22879e2ce9409f400dcab:

  Merge https://source.denx.de/u-boot/custodians/u-boot-pmic
(2022-12-26 21:00:20 -0500)

are available in the Git repository at:

  https://source.denx.de/u-boot/custodians/u-boot-efi.git
tags/efi-2023-01-rc5-2

for you to fetch changes up to f557cf08b974c359ad3c53a87297d19fe13ff4f0:

  efi_loader: use u16_strlen() in efi_var_mem_ins() (2022-12-29
12:52:39 +0100)


Pull request for efi-2023-01-rc5-2

Documentation:

* Reorganize existing TI docs and add K3 generation page
* Add texinfodocs and infodocs targets
* Update qemu-ppce500 documentation
* Use "changesets" not "csets" in statistics pages

UEFI

* Fix merging of preseeded non-volatile variables
* Fix a return value in the  EFI_HII_DATABASE_PROTOCOL
* Set UEFI specification version to 2.10


Bryan Brattlof (2):
  doc: ti: reorganize existing ti docs
  doc: ti: add the K3 generation page

Heinrich Schuchardt (5):
  doc: improve wget man-page
  efi_loader: set IMAGE_FILE_LARGE_ADDRESS_AWARE
  efi_loader: set UEFI specification version to 2.10
  efi_loader: typo non-volatile in efi_var_restore
  efi_loader: use u16_strlen() in efi_var_mem_ins()

Ilias Apalodimas (1):
  efi_loader: avoid adding variables twice

Maxim Cournoyer (1):
  doc: add texinfodocs and infodocs targets

Pali Rohár (1):
  doc: board: qemu-ppce500: Update supported and unsupported

Tom Rini (1):
  doc: Use "changesets" not "csets" in statistics pages

Vincent Stehlé (1):
  efi_loader: fix get_package_list_handle() status

 Makefile |   2 +-
 arch/arm/lib/crt0_aarch64_efi.S  |   1 +
 arch/riscv/lib/crt0_riscv_efi.S  |  17 +-
 doc/Makefile |  10 +
 doc/board/emulation/qemu-ppce500.rst |   8 +-
 doc/board/ti/am335x_evm.rst  |   5 +-
 doc/board/ti/am62x_sk.rst|   4 +-
 doc/board/ti/index.rst   |   5 +-
 doc/board/ti/j721e_evm.rst   |   4 +-
 doc/board/ti/k3.rst  | 274
+++
 doc/conf.py  |   6 +-
 doc/develop/statistics/u-boot-stats-v1.3.0.rst   |   2 +-
 doc/develop/statistics/u-boot-stats-v1.3.1.rst   |   2 +-
 doc/develop/statistics/u-boot-stats-v1.3.2.rst   |   2 +-
 doc/develop/statistics/u-boot-stats-v1.3.3.rst   |   2 +-
 doc/develop/statistics/u-boot-stats-v1.3.4.rst   |   2 +-
 doc/develop/statistics/u-boot-stats-v2008.10.rst |   2 +-
 doc/develop/statistics/u-boot-stats-v2009.01.rst |   2 +-
 doc/develop/statistics/u-boot-stats-v2009.03.rst |   2 +-
 doc/develop/statistics/u-boot-stats-v2009.06.rst |   2 +-
 doc/develop/statistics/u-boot-stats-v2009.08.rst |   2 +-
 doc/develop/statistics/u-boot-stats-v2009.11.rst |   2 +-
 doc/develop/statistics/u-boot-stats-v2010.03.rst |   2 +-
 doc/develop/statistics/u-boot-stats-v2010.06.rst |   2 +-
 doc/develop/statistics/u-boot-stats-v2010.09.rst |   2 +-
 doc/develop/statistics/u-boot-stats-v2010.12.rst |   2 +-
 doc/develop/statistics/u-boot-stats-v2011.03.rst |   2 +-
 doc/develop/statistics/u-boot-stats-v2011.06.rst |   2 +-
 doc/develop/statistics/u-boot-stats-v2011.09.rst |   2 +-
 doc/develop/statistics/u-boot-stats-v2011.12.rst |   2 +-
 doc/develop/statistics/u-boot-stats-v2012.04.rst |   2 +-
 doc/develop/statistics/u-boot-stats-v2012.07.rst |   2 +-
 doc/develop/statistics/u-boot-stats-v2012.10.rst |   2 +-
 doc/develop/statistics/u-boot-stats-v2013.07.rst |   2 +-
 doc/develop/statistics/u-boot-stats-v2013.10.rst |   2 +-
 doc/develop/statistics/u-boot-stats-v2014.01.rst |   2 +-
 doc/develop/statistics/u-boot-stats-v2014.04.rst |   2 +-
 doc/develop/statistics/u-boot-stats-v2014.07.rst |   2 +-
 doc/develop/statistics/u-boot-stats-v2014.10.rst |   2 +-
 doc/develop/statistics/u-boot-stats-v2015.01.rst |   2 +-
 doc/develop/statistics/u-boot-stats-v2015.04.rst |   2 +-
 doc/develop/statistics/u-boot-stats-v2015.07.rst |   2 +-
 doc/develop/statistics/u-boot-stats-v2015.10.rst |   2 +-
 doc/develop/statistics/u-boot-stats-v2016.01.rst |   2 +-
 doc/develop/statistics/u-boot-stats-v2016.03.rst |   2 +-
 doc/develop/statistics/u-boot-stats-v2016.05.rst |   2 +-
 doc/develop/statistics/u-boot-stats-v2016.07.rst |   2 +-
 doc/develop/statistics/u-boot-stats-v2016.09.rst |   2 +-
 doc/develop/statistics/u-boot-stats-v2016.11.rst |   2 +-
 doc/develop/statistics/u-boot-stats-v2017.01.rst |   2 +-
 doc/develop/statistics/u-boot-stats-v2017.03.rst |   2 +-
 doc/develop/statistics/u-boot-stats-v2017.05.rst |   2 +-
 doc/develop/statistics/u-boot-stats-v2017.07.rst |   2 +-
 doc/develop/statistics/u-boot-stats-v2017.09.rst |   2 +-
 doc/develop/statistics/u-boot-stats-v2017.11.rst |   2 +-
 

[PATCH 3/3] efi_loader: adjust sorting of capsules

2022-12-29 Thread Heinrich Schuchardt
Up to now we only compared the first letter of the capsule name to sort
them alphabetically. Properly sort by the Unicode alphabet.

Signed-off-by: Heinrich Schuchardt 
---
 lib/efi_loader/efi_capsule.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/lib/efi_loader/efi_capsule.c b/lib/efi_loader/efi_capsule.c
index 1163a2ee30..0997cd248f 100644
--- a/lib/efi_loader/efi_capsule.c
+++ b/lib/efi_loader/efi_capsule.c
@@ -1108,10 +1108,13 @@ static efi_status_t efi_capsule_scan_dir(u16 ***files, 
unsigned int *num)
/* ignore an error */
EFI_CALL((*dirh->close)(dirh));
 
-   /* in ascii order */
-   /* FIXME: u16 version of strcasecmp */
+   /*
+* Capsule files are applied in case insensitive alphabetic order
+*
+* TODO: special handling of rightmost period
+*/
qsort(tmp_files, count, sizeof(*tmp_files),
- (int (*)(const void *, const void *))strcasecmp);
+ (int (*)(const void *, const void *))u16_strcasecmp);
*files = tmp_files;
*num = count;
ret = EFI_SUCCESS;
-- 
2.37.2



[PATCH 2/3] test: unit test for u16_strcasecmp()

2022-12-29 Thread Heinrich Schuchardt
Provide a unit test for u16_strcasecmp().

Signed-off-by: Heinrich Schuchardt 
---
 test/unicode_ut.c | 25 +
 1 file changed, 25 insertions(+)

diff --git a/test/unicode_ut.c b/test/unicode_ut.c
index 3547aeffe7..382b796516 100644
--- a/test/unicode_ut.c
+++ b/test/unicode_ut.c
@@ -624,6 +624,31 @@ static int unicode_test_utf_to_upper(struct 
unit_test_state *uts)
 }
 UNICODE_TEST(unicode_test_utf_to_upper);
 
+static int unicode_test_u16_strcasecmp(struct unit_test_state *uts)
+{
+   ut_assert(u16_strcasecmp(u"abcd", u"abcd") == 0);
+   ut_assert(u16_strcasecmp(u"aBcd", u"abcd") == 0);
+   ut_assert(u16_strcasecmp(u"abcd", u"abCd") == 0);
+   ut_assert(u16_strcasecmp(u"abcdE", u"abcd") > 0);
+   ut_assert(u16_strcasecmp(u"abcd", u"abcdE") < 0);
+   ut_assert(u16_strcasecmp(u"abcE", u"abcd") > 0);
+   ut_assert(u16_strcasecmp(u"abcd", u"abcE") < 0);
+   ut_assert(u16_strcasecmp(u"abcd", u"abcd") == 0);
+   ut_assert(u16_strcasecmp(u"abcd", u"abcd") == 0);
+   if (CONFIG_IS_ENABLED(EFI_UNICODE_CAPITALIZATION)) {
+   /* Cyrillic letters */
+   ut_assert(u16_strcasecmp(u"\x043a\x043d\x0438\x0433\x0430",
+u"\x041a\x041d\x0418\x0413\x0410") == 
0);
+   ut_assert(u16_strcasecmp(u"\x043a\x043d\x0438\x0433\x0430",
+u"\x041a\x041d\x0418\x0413\x0411") < 
0);
+   ut_assert(u16_strcasecmp(u"\x043a\x043d\x0438\x0433\x0431",
+u"\x041a\x041d\x0418\x0413\x0410") > 
0);
+   }
+
+   return 0;
+}
+UNICODE_TEST(unicode_test_u16_strcasecmp);
+
 static int unicode_test_u16_strncmp(struct unit_test_state *uts)
 {
ut_assert(u16_strncmp(u"abc", u"abc", 3) == 0);
-- 
2.37.2



[PATCH 1/3] lib: add function u16_strcasecmp()

2022-12-29 Thread Heinrich Schuchardt
Provide a function for comparing UTF-16 strings in a case insensitive
manner.

Signed-off-by: Heinrich Schuchardt 
---
 include/charset.h | 13 +
 lib/charset.c | 26 ++
 2 files changed, 39 insertions(+)

diff --git a/include/charset.h b/include/charset.h
index e900fd789a..6e79d7152e 100644
--- a/include/charset.h
+++ b/include/charset.h
@@ -173,6 +173,19 @@ s32 utf_to_lower(const s32 code);
  */
 s32 utf_to_upper(const s32 code);
 
+/**
+ * u16_strcasecmp() - compare two u16 strings case insensitively
+ *
+ * @s1:first string to compare
+ * @s2:second string to compare
+ * @n: maximum number of u16 to compare
+ * Return: 0  if the first n u16 are the same in s1 and s2
+ * < 0 if the first different u16 in s1 is less than the
+ * corresponding u16 in s2
+ * > 0 if the first different u16 in s1 is greater than the
+ */
+int u16_strcasecmp(const u16 *s1, const u16 *s2);
+
 /**
  * u16_strncmp() - compare two u16 string
  *
diff --git a/lib/charset.c b/lib/charset.c
index bece4985bf..b1842755eb 100644
--- a/lib/charset.c
+++ b/lib/charset.c
@@ -350,6 +350,32 @@ s32 utf_to_upper(const s32 code)
return ret;
 }
 
+/*
+ * u16_strcasecmp() - compare two u16 strings case insensitively
+ *
+ * @s1:first string to compare
+ * @s2:second string to compare
+ * @n: maximum number of u16 to compare
+ * Return: 0  if the first n u16 are the same in s1 and s2
+ * < 0 if the first different u16 in s1 is less than the
+ * corresponding u16 in s2
+ * > 0 if the first different u16 in s1 is greater than the
+ */
+int u16_strcasecmp(const u16 *s1, const u16 *s2)
+{
+   int ret = 0;
+   s32 c1, c2;
+
+   for (;;) {
+   c1 = utf_to_upper(utf16_get());
+   c2 = utf_to_upper(utf16_get());
+   ret = c1 - c2;
+   if (ret || !c1 || c1 == -1 || c2 == -1)
+   break;
+   }
+   return ret;
+}
+
 /*
  * u16_strncmp() - compare two u16 string
  *
-- 
2.37.2



[PATCH 3/3] efi_loader: adjust sorting of capsules

2022-12-29 Thread Heinrich Schuchardt
The UEFI specification requires to apply capsules in alphabetical order.
The current implementation only sorted by the first letter due to using
strcmp() which will stop at the first zero byte.

* Provide function u16_strcasecmp() for case insensitive comparision of
  UTF-16 strings
* Provide a unit test for u16_strcasecmp()
* Use the function to sort capsules.

We do not implement the special handling of the rightmost period of
capsule names yet.

Heinrich Schuchardt (3):
  lib: add function u16_strcasecmp()
  test: unit test for u16_strcasecmp()
  efi_loader: adjust sorting of capsules

 include/charset.h| 13 +
 lib/charset.c| 27 +++
 lib/efi_loader/efi_capsule.c |  9 ++---
 test/unicode_ut.c| 25 +
 4 files changed, 71 insertions(+), 3 deletions(-)

-- 
2.37.2



Re: [PATCH 0/5] add support for hs bootflows to am62a

2022-12-29 Thread Kamlesh Gurudasani
Bryan Brattlof  writes:

> Hello everyone!
>
> Texas Instruments has started to enable security settings inside all the
> boot ROM and TIFS firmware in all of their SoCs. One of the few changes
> this brings is ROM and TIFS will now begin protecting the RAM regions
> they're using with firewalls.
>
> This means the wakeup domain's SPL will need to move the stack and heap
> to HSM RAM to ensure it stays within its allotted memory regions as well
> as move the needed boot information to the main domain's bootloaders that
> will no longer have access to HSM RAM.
>
> We will also need to edit the bootcmd to pull in the kernel and dtb's
> fitImage if uboot is enforcing the high security bootflow. While we're
> editing this bootcmd, we can also take the opportunity to convert it to
> a distro_bootcmd macro.
>
> Thanks for reviewing!
> ~Bryan
>
> Bryan Brattlof (5):
>   configs: restrict am62ax wakup SPL size
>   configs: am62a: move stack and heap to HSM RAM
>   arm: mach-k3: copy bootindex to OCRAM for main domain SPL
>   configs: am62a: convert bootcmd to distro_bootcmd
>   configs: am62a: use kernel fitImage when using secure bootflow
>
>  arch/arm/mach-k3/Kconfig  |  4 ++-
>  arch/arm/mach-k3/am62a7_init.c| 16 +++--
>  .../arm/mach-k3/include/mach/am62a_hardware.h | 17 +-
>  configs/am62ax_evm_a53_defconfig  |  1 -
>  configs/am62ax_evm_r5_defconfig   | 15 +---
>  include/configs/am62ax_evm.h  | 34 +--
>  6 files changed, 74 insertions(+), 13 deletions(-)
>
>
> base-commit: 52d91e1c20b399ddab276e2c03e5788ed5e5fdd2
> -- 
> 2.39.0

All patches look good to me.

Reviewed-by: Kamlesh Gurudasani 

Thanks


Re: Bug#1012269: u-boot-exynos on Odroid XU4 searches for exynos5422-smdk5420xu4.dtb instead of exynos5422-odroidxu4.dtb

2022-12-29 Thread Jochen Sprickerhof

* Vagrant Cascadian  [2022-12-28 18:00]:

Hrm. This suggests the fix might not have been effective, which should
have been included in 2022.07... CCing upstream...

commit e744bf3a4ba442a0e9ee1c509c70e1452e3a15d0
Author: Tom Rini 
Date:   Wed Jun 8 14:30:14 2022 -0400

odroid_xu3: Fix board environment variable

When migrating CONFIG_CONS_INDEX to Kconfig, on this platform we changed
what "board" evaluated to in the environment.  This in turn meant that
we would no longer try and find the correct fdtfile via the normal
distro boot logic.  Fix this by overriding board in the default
environment, as done on other platforms where CONFIG_SYS_BOARD is not
what we want to be in the board environment variable.

Fixes: f76750d11133 ("Convert CONFIG_CONS_INDEX et al to Kconfig")
Reported-by: Gabriel Hojda 
Tested-by: Gabriel Hojda 
Signed-off-by: Tom Rini 


Alternately... did you at any point run saveenv? This might have stored
the incorrect value... and then it might not probe for the correct
value.


I'm sure I never did that. Out of interest, where would it save the 
environment? Afaik there is no persistent memory on the Odroid XU4 
besids the emmc/sd card and my system uses a simple extlinux.conf 
generated by u-boot-menu.


Cheers Jochen


signature.asc
Description: PGP signature


[PATCH 1/1] efi_loader: use u16_strlen() in efi_var_mem_ins()

2022-12-29 Thread Heinrich Schuchardt
Don't duplicate library functionality.

Signed-off-by: Heinrich Schuchardt 
---
 lib/efi_loader/efi_var_mem.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/lib/efi_loader/efi_var_mem.c b/lib/efi_loader/efi_var_mem.c
index 0bac594e00..d71ccb31df 100644
--- a/lib/efi_loader/efi_var_mem.c
+++ b/lib/efi_loader/efi_var_mem.c
@@ -142,14 +142,10 @@ efi_status_t __efi_runtime efi_var_mem_ins(
 {
u16 *data;
struct efi_var_entry *var;
-   u32 var_name_len;
 
var = (struct efi_var_entry *)
  ((uintptr_t)efi_var_buf + efi_var_buf->length);
-   for (var_name_len = 0; variable_name[var_name_len]; ++var_name_len)
-   ;
-   ++var_name_len;
-   data = var->name + var_name_len;
+   data = var->name + u16_strlen(var->name) + 1;
 
if ((uintptr_t)data - (uintptr_t)efi_var_buf + size1 + size2 >
EFI_VAR_BUF_SIZE)
-- 
2.37.2



sandbox: "Reset Status: WARM Reset Status: COLD"

2022-12-29 Thread Heinrich Schuchardt

Hello Simon,

the sandbox prints the following line when started:
"Reset Status: WARM Reset Status: COLD"

This does not make much sense. Either the last reset was WARM or COLD
but not both.

sandbox_sysreset_get_status() and sandbox_warm_sysreset_get_status()
should determine the reset status before printing anything incorrect.

After executing the reset command

   state->last_sysreset == 4

This cannot be correct. It seems to be due to:

arch/sandbox/cpu/state.c:365:   state->last_sysreset = SYSRESET_COUNT;

state_reset_for_test() should only be called in tests.

Best regards

Heinrich


Re: [PATCH 1/1] efi_loader: typo non-volatile in efi_var_restore

2022-12-29 Thread Ilias Apalodimas
On Thu, 29 Dec 2022 at 10:25, Heinrich Schuchardt
 wrote:
>
> It is volatile variables that we do not allow to be restored from file.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  lib/efi_loader/efi_var_file.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/efi_loader/efi_var_file.c b/lib/efi_loader/efi_var_file.c
> index 3d58caa13d..de9ba8de99 100644
> --- a/lib/efi_loader/efi_var_file.c
> +++ b/lib/efi_loader/efi_var_file.c
> @@ -176,7 +176,7 @@ efi_status_t efi_var_restore(struct efi_var_file *buf, 
> bool safe)
> data = var->name + u16_strlen(var->name) + 1;
>
> /*
> -* Secure boot related and non-volatile variables shall only 
> be
> +* Secure boot related and volatile variables shall only be
>  * restored from U-Boot's preseed.
>  */
> if (!safe &&
> --
> 2.37.2
>
Reviewed-by: Ilias Apalodimas 


[PATCH 1/1] efi_loader: typo non-volatile in efi_var_restore

2022-12-29 Thread Heinrich Schuchardt
It is volatile variables that we do not allow to be restored from file.

Signed-off-by: Heinrich Schuchardt 
---
 lib/efi_loader/efi_var_file.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/efi_loader/efi_var_file.c b/lib/efi_loader/efi_var_file.c
index 3d58caa13d..de9ba8de99 100644
--- a/lib/efi_loader/efi_var_file.c
+++ b/lib/efi_loader/efi_var_file.c
@@ -176,7 +176,7 @@ efi_status_t efi_var_restore(struct efi_var_file *buf, bool 
safe)
data = var->name + u16_strlen(var->name) + 1;
 
/*
-* Secure boot related and non-volatile variables shall only be
+* Secure boot related and volatile variables shall only be
 * restored from U-Boot's preseed.
 */
if (!safe &&
-- 
2.37.2



Re: [PATCH] efi_loader: avoid adding variables twice

2022-12-29 Thread Heinrich Schuchardt

On 12/29/22 07:55, Ilias Apalodimas wrote:

When the efi subsystem starts we restore variables that are both in a
file or stored into the .efi_runtime section of U-Boot.  However once
a variable gets created or changed the preseeded entries will end up in
the file.  As a consequence on the next boot we will end up adding
identical variable entries twice.

Fix this by checking if the to be inserted variable already exists.
Also swap the restoration order and start with the file instead of the
builtin variables,  so a user can replace the preseeded ones if needed.

Tested-by: Leo Yan 
Signed-off-by: Ilias Apalodimas 


With this version updating variables does not work anymore.

Thanks for sending v2.

Best regards

Heinrich


[PATCH v2] efi_loader: avoid adding variables twice

2022-12-29 Thread Ilias Apalodimas
When the efi subsystem starts we restore variables that are both in a
file or stored into the .efi_runtime section of U-Boot.  However once
a variable gets created or changed the preseeded entries will end up in
the file.  As a consequence on the next boot we will end up adding
identical variable entries twice.

Fix this by checking if the to be inserted variable already exists.
Also swap the restoration order and start with the file instead of the
builtin variables,  so a user can replace the preseeded ones if needed.

Tested-by: Leo Yan 
Signed-off-by: Ilias Apalodimas 
---
changes since v1:
- Move the check in efi_var_restore(), since it would break updating
  variables in efi_var_mem_ins()

 lib/efi_loader/efi_var_file.c | 2 ++
 lib/efi_loader/efi_variable.c | 6 +++---
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/lib/efi_loader/efi_var_file.c b/lib/efi_loader/efi_var_file.c
index 3d58caa13da2..d70a72d12684 100644
--- a/lib/efi_loader/efi_var_file.c
+++ b/lib/efi_loader/efi_var_file.c
@@ -187,6 +187,8 @@ efi_status_t efi_var_restore(struct efi_var_file *buf, bool 
safe)
continue;
if (!var->length)
continue;
+   if (efi_var_mem_find(>guid, var->name, NULL))
+   continue;
ret = efi_var_mem_ins(var->name, >guid, var->attr,
  var->length, data, 0, NULL,
  var->time);
diff --git a/lib/efi_loader/efi_variable.c b/lib/efi_loader/efi_variable.c
index 8ca2d85694c8..503a33ed65c5 100644
--- a/lib/efi_loader/efi_variable.c
+++ b/lib/efi_loader/efi_variable.c
@@ -425,6 +425,9 @@ efi_status_t efi_init_variables(void)
if (ret != EFI_SUCCESS)
return ret;

+   ret = efi_var_from_file();
+   if (ret != EFI_SUCCESS)
+   return ret;
if (IS_ENABLED(CONFIG_EFI_VARIABLES_PRESEED)) {
ret = efi_var_restore((struct efi_var_file *)
  __efi_var_file_begin, true);
@@ -432,9 +435,6 @@ efi_status_t efi_init_variables(void)
log_err("Invalid EFI variable seed\n");
}

-   ret = efi_var_from_file();
-   if (ret != EFI_SUCCESS)
-   return ret;

return efi_init_secure_state();
 }
--
2.38.1