Re: [PATCH v2] common: console: Fix print complete stdio device list
On Wed, Jan 17, 2024 at 8:37 PM Patrice Chotard
wrote:
>
> In case CONSOLE_MUX and SYS_CONSOLE_IS_IN_ENV are on and
> stdin or stdout or stderr are missing in environment, as fallback, get
> these either from stdio_devices[std] or stdio_devices[std]->name.
>
> Fixes: 6b343ab38d ("console: Print out complete stdio device list")
>
> Signed-off-by: Patrice Chotard
>
> ---
>
> Changes in v2:
> - simplify code suggested by Bin Meng
>
> common/console.c | 27 ---
> 1 file changed, 12 insertions(+), 15 deletions(-)
>
Reviewed-by: Bin Meng
Re: [PATCH] common: console: Fix print complete stdio device list
On Wed, Jan 17, 2024 at 12:13 AM Patrice Chotard
wrote:
>
> In case CONSOLE_MUX and SYS_CONSOLE_IS_IN_ENV are on and
> stdin or stdout or stderr are missing in environment, as fallback, get
> these either from stdio_devices[std] or stdio_devices[std]->name.
>
> Fixes: 6b343ab38d ("console: Print out complete stdio device list")
>
> Signed-off-by: Patrice Chotard
> ---
>
> common/console.c | 23 +++
> 1 file changed, 11 insertions(+), 12 deletions(-)
>
> diff --git a/common/console.c b/common/console.c
> index cad65891fc9..8bfcfce5643 100644
> --- a/common/console.c
> +++ b/common/console.c
> @@ -1049,6 +1049,11 @@ int console_clear(void)
> return 0;
> }
>
> +static char *get_stdio(const u8 std)
> +{
> + return stdio_devices[std] ? stdio_devices[std]->name : "No devices
> available!";
> +}
> +
> static void stdio_print_current_devices(void)
> {
> char *stdinname, *stdoutname, *stderrname;
> @@ -1060,19 +1065,13 @@ static void stdio_print_current_devices(void)
> stdoutname = env_get("stdout");
> stderrname = env_get("stderr");
>
> - stdinname = stdinname ? : "No input devices available!";
> - stdoutname = stdoutname ? : "No output devices available!";
> - stderrname = stderrname ? : "No error devices available!";
> + stdinname = stdinname ? : get_stdio(stdin);
> + stdoutname = stdoutname ? : get_stdio(stdout);
> + stderrname = stderrname ? : get_stdio(stderr);
> } else {
> - stdinname = stdio_devices[stdin] ?
> - stdio_devices[stdin]->name :
> - "No input devices available!";
> - stdoutname = stdio_devices[stdout] ?
> - stdio_devices[stdout]->name :
> - "No output devices available!";
> - stderrname = stdio_devices[stderr] ?
> - stdio_devices[stderr]->name :
> - "No error devices available!";
> + stdinname = get_stdio(stdin);
> + stdoutname = get_stdio(stdout);
> + stderrname = get_stdio(stderr);
> }
>
> /* Print information */
> --
This can be further simplified to:
char *stdinname = NULL;
char *stdoutname = NULL;
char *stderrname NULL;
if (CONFIG_IS_ENABLED(CONSOLE_MUX) &&
CONFIG_IS_ENABLED(SYS_CONSOLE_IS_IN_ENV)) {
/* stdin stdout and stderr are in environment */
stdinname = env_get("stdin");
stdoutname = env_get("stdout");
stderrname = env_get("stderr");
}
stdinname = stdinname ? : get_stdio(stdin);
stdoutname = stdoutname ? : get_stdio(stdout);
stderrname = stderrname ? : get_stdio(stderr);
Regards,
Bin
Re: [PATCH 2/2] coreboot: Switch to a monospaced font
+ Tom and Anatolij,
On Mon, Jan 8, 2024 at 5:33 PM Dragan Simic wrote:
>
> On 2024-01-08 10:29, Mark Kettenis wrote:
> >> From: Simon Glass
> >> Date: Sun, 7 Jan 2024 17:14:55 -0700
> >>
> >> The default font is proportional, with different character widths.
> >> Select a monospace font for coreboot so that the 'dm tree' output
> >> lines
> >> up correctly.
> >>
> >> Update the coreboot tests to match.
> >
> > To be honest, I think defaulting to a proportional font is wrong as a
> > default for something like U-Boot.
>
> I agree, it makes very little sense to default to a proportional font.
>
So we should revert
commit b093753471c1a30d680868a9f4d9f6db090bf0b7 ("video: Add a default
TrueType font")
Regards,
Bin
Re: [PATCH v2 00/19] x86: expo: Add support for editing coreboot CMOS RAM settings
Hi Simon, On Sat, Jan 6, 2024 at 9:38 AM Simon Glass wrote: > > Hi Bin, > > On Fri, Jan 5, 2024 at 4:06 PM Bin Meng wrote: > > > > Hi Simon, > > > > On Sat, Jan 6, 2024 at 4:12 AM Simon Glass wrote: > > > > > > Hi Bin, > > > > > > On Thu, Jan 4, 2024 at 4:02 PM Bin Meng wrote: > > > > > > > > Hi Simon, > > > > > > > > On Thu, Jan 4, 2024 at 11:11 PM Simon Glass wrote: > > > > > > > > > > U-Boot provides support for editing settings with an 'expo', as well > > > > > as > > > > > reading and writing settings to CMOS RAM. > > > > > > > > > > This series integrates expo functionality with coreboot, using the > > > > > sysinfo table to get a list of settings, creating an expo with them > > > > > and > > > > > allowing them to be edited. > > > > > > > > > > A new CI test provides coverage for some coreboot-related commands. > > > > > For > > > > > this to work, a number of minor tweaks are made to existing tests, so > > > > > that they pass on coreboot (x86) or at least are skipped when they > > > > > cannot pass. Likely most of these fixes will apply to other boards > > > > > too. > > > > > > > > > > It includes several other fixes and improvements: > > > > > - new -m flag for 'bootflow scan' so it can display a menu > > > > > automatically > > > > > - Fix for video-scrolling crash with Truetype > > > > > - menu items can now have individual integer values > > > > > - menu items are lined up according to the width of all menu labels > > > > > > > > > > Changes in v2: > > > > > - Avoid using common.h > > > > > - Avoid using common.h > > > > > - Rebase to -next > > > > > > > > > > Simon Glass (19): > > > > > video: Add a dark-grey console colour > > > > > video: Avoid starting a new line to close to the bottom > > > > > expo: Place menu items to the right of all labels > > > > > expo: Set the initial next_id to 1 > > > > > expo: Use standard numbering for save and discard > > > > > expo: Allow menu items to have values > > > > > expo: Add a little more cedit CMOS logging > > > > > expo: Support menu-item values in cedit > > > > > expo: Drop unneceesary calls to expo_str() > > > > > expo: Drop scene_title_set() > > > > > expo: Add forward declaration for udevice to cedit > > > > > x86: coreboot: Enable unit tests > > > > > x86: CI: Update coreboot > > > > > x86: coreboot: Add a test for cbsysinfo command > > > > > x86: coreboot: Show the option table > > > > > x86: coreboot: Enable support for the configuration editor > > > > > x86: coreboot: Add a command to check and update CMOS RAM > > > > > x86: coreboot: Allow building an expo for editing CMOS config > > > > > x86: Enable RTC command by default > > > > > > > > > > .azure-pipelines.yml | 2 +- > > > > > .gitlab-ci.yml| 2 +- > > > > > arch/sandbox/dts/cedit.dtsi | 3 + > > > > > arch/x86/dts/coreboot.dts | 7 + > > > > > boot/Makefile | 4 + > > > > > boot/cedit.c | 191 +++ > > > > > boot/expo.c | 3 + > > > > > boot/expo_build.c | 36 ++--- > > > > > boot/expo_build_cb.c | 245 > > > > > ++ > > > > > boot/scene.c | 61 ++-- > > > > > boot/scene_internal.h | 30 +++- > > > > > boot/scene_menu.c | 26 +++- > > > > > boot/scene_textline.c | 3 +- > > > > > cmd/Kconfig | 12 ++ > > > > > cmd/cedit.c | 28 > > > > > cmd/x86/Makefile | 1 + > > > > > cmd/x86/cbcmos.c | 139 + > > > > > cmd/x86/cbsysinfo.c | 73 - > > > > > configs/coreboot64_defconfig
Re: [PATCH v2 00/19] x86: expo: Add support for editing coreboot CMOS RAM settings
Hi Simon, On Sat, Jan 6, 2024 at 4:12 AM Simon Glass wrote: > > Hi Bin, > > On Thu, Jan 4, 2024 at 4:02 PM Bin Meng wrote: > > > > Hi Simon, > > > > On Thu, Jan 4, 2024 at 11:11 PM Simon Glass wrote: > > > > > > U-Boot provides support for editing settings with an 'expo', as well as > > > reading and writing settings to CMOS RAM. > > > > > > This series integrates expo functionality with coreboot, using the > > > sysinfo table to get a list of settings, creating an expo with them and > > > allowing them to be edited. > > > > > > A new CI test provides coverage for some coreboot-related commands. For > > > this to work, a number of minor tweaks are made to existing tests, so > > > that they pass on coreboot (x86) or at least are skipped when they > > > cannot pass. Likely most of these fixes will apply to other boards too. > > > > > > It includes several other fixes and improvements: > > > - new -m flag for 'bootflow scan' so it can display a menu automatically > > > - Fix for video-scrolling crash with Truetype > > > - menu items can now have individual integer values > > > - menu items are lined up according to the width of all menu labels > > > > > > Changes in v2: > > > - Avoid using common.h > > > - Avoid using common.h > > > - Rebase to -next > > > > > > Simon Glass (19): > > > video: Add a dark-grey console colour > > > video: Avoid starting a new line to close to the bottom > > > expo: Place menu items to the right of all labels > > > expo: Set the initial next_id to 1 > > > expo: Use standard numbering for save and discard > > > expo: Allow menu items to have values > > > expo: Add a little more cedit CMOS logging > > > expo: Support menu-item values in cedit > > > expo: Drop unneceesary calls to expo_str() > > > expo: Drop scene_title_set() > > > expo: Add forward declaration for udevice to cedit > > > x86: coreboot: Enable unit tests > > > x86: CI: Update coreboot > > > x86: coreboot: Add a test for cbsysinfo command > > > x86: coreboot: Show the option table > > > x86: coreboot: Enable support for the configuration editor > > > x86: coreboot: Add a command to check and update CMOS RAM > > > x86: coreboot: Allow building an expo for editing CMOS config > > > x86: Enable RTC command by default > > > > > > .azure-pipelines.yml | 2 +- > > > .gitlab-ci.yml| 2 +- > > > arch/sandbox/dts/cedit.dtsi | 3 + > > > arch/x86/dts/coreboot.dts | 7 + > > > boot/Makefile | 4 + > > > boot/cedit.c | 191 +++ > > > boot/expo.c | 3 + > > > boot/expo_build.c | 36 ++--- > > > boot/expo_build_cb.c | 245 ++ > > > boot/scene.c | 61 ++-- > > > boot/scene_internal.h | 30 +++- > > > boot/scene_menu.c | 26 +++- > > > boot/scene_textline.c | 3 +- > > > cmd/Kconfig | 12 ++ > > > cmd/cedit.c | 28 > > > cmd/x86/Makefile | 1 + > > > cmd/x86/cbcmos.c | 139 + > > > cmd/x86/cbsysinfo.c | 73 - > > > configs/coreboot64_defconfig | 2 + > > > configs/coreboot_defconfig| 6 + > > > doc/board/coreboot/coreboot.rst | 6 + > > > doc/develop/cedit.rst | 9 +- > > > doc/develop/expo.rst | 26 +++- > > > doc/usage/cmd/cbcmos.rst | 45 ++ > > > doc/usage/cmd/cbsysinfo.rst | 99 > > > doc/usage/cmd/cedit.rst | 91 ++- > > > doc/usage/index.rst | 1 + > > > drivers/video/vidconsole-uclass.c | 4 +- > > > drivers/video/video-uclass.c | 3 + > > > include/cedit.h | 2 + > > > include/expo.h| 51 +-- > > > include/test/cedit-test.h | 30 ++-- > > > include/video.h | 4 +- > > > include/video_console.h | 8 + > > > test/boot/cedit.c | 22 ++- > > > test/boot/expo.c | 26 +++- > > > test/boot/files/e
[PATCH] doc: coreboot: Update stale graphics enabling instructions
From: Bin Meng With latest coreboot (e.g.: v4.22.01), the instructions to enable graphics support has changed. Refresh the doc. Signed-off-by: Bin Meng --- doc/board/coreboot/coreboot.rst | 11 +-- 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/doc/board/coreboot/coreboot.rst b/doc/board/coreboot/coreboot.rst index f2c6452b5b..8408461617 100644 --- a/doc/board/coreboot/coreboot.rst +++ b/doc/board/coreboot/coreboot.rst @@ -32,10 +32,9 @@ of _x86boot_start (in arch/x86/cpu/start.S). If you want to use ELF as the coreboot payload, change U-Boot configuration to use CONFIG_OF_EMBED instead of CONFIG_OF_SEPARATE. -To enable video you must enable these options in coreboot: +To enable video you must enable CONFIG_GENERIC_LINEAR_FRAMEBUFFER in coreboot: - - Set framebuffer graphics resolution (1280x1024 32k-color (1:5:5)) - - Keep VESA framebuffer + - Devices->Display->Framebuffer mode->Linear "high resolution" framebuffer At present it seems that for Minnowboard Max, coreboot does not pass through the video information correctly (it always says the resolution is 0x0). This @@ -184,9 +183,9 @@ boot as a coreboot payload, based on a known-good build of coreboot. To update the `coreboot.rom` file which is used: -#. Build coreboot with `CONFIG_LINEAR_FRAMEBUFFER=y`. If using `make menuconfig` - this is under - `Devices ->Display->Framebuffer mode->Linear "high resolution" framebuffer`. +#. Build coreboot with `CONFIG_GENERIC_LINEAR_FRAMEBUFFER=y`. If using + `make menuconfig`, this is under + `Devices->Display->Framebuffer mode->Linear "high resolution" framebuffer`. #. Compress the resulting `coreboot.rom`:: -- 2.34.1
Re: [PATCH v2 00/19] x86: expo: Add support for editing coreboot CMOS RAM settings
Hi Simon, On Thu, Jan 4, 2024 at 11:11 PM Simon Glass wrote: > > U-Boot provides support for editing settings with an 'expo', as well as > reading and writing settings to CMOS RAM. > > This series integrates expo functionality with coreboot, using the > sysinfo table to get a list of settings, creating an expo with them and > allowing them to be edited. > > A new CI test provides coverage for some coreboot-related commands. For > this to work, a number of minor tweaks are made to existing tests, so > that they pass on coreboot (x86) or at least are skipped when they > cannot pass. Likely most of these fixes will apply to other boards too. > > It includes several other fixes and improvements: > - new -m flag for 'bootflow scan' so it can display a menu automatically > - Fix for video-scrolling crash with Truetype > - menu items can now have individual integer values > - menu items are lined up according to the width of all menu labels > > Changes in v2: > - Avoid using common.h > - Avoid using common.h > - Rebase to -next > > Simon Glass (19): > video: Add a dark-grey console colour > video: Avoid starting a new line to close to the bottom > expo: Place menu items to the right of all labels > expo: Set the initial next_id to 1 > expo: Use standard numbering for save and discard > expo: Allow menu items to have values > expo: Add a little more cedit CMOS logging > expo: Support menu-item values in cedit > expo: Drop unneceesary calls to expo_str() > expo: Drop scene_title_set() > expo: Add forward declaration for udevice to cedit > x86: coreboot: Enable unit tests > x86: CI: Update coreboot > x86: coreboot: Add a test for cbsysinfo command > x86: coreboot: Show the option table > x86: coreboot: Enable support for the configuration editor > x86: coreboot: Add a command to check and update CMOS RAM > x86: coreboot: Allow building an expo for editing CMOS config > x86: Enable RTC command by default > > .azure-pipelines.yml | 2 +- > .gitlab-ci.yml| 2 +- > arch/sandbox/dts/cedit.dtsi | 3 + > arch/x86/dts/coreboot.dts | 7 + > boot/Makefile | 4 + > boot/cedit.c | 191 +++ > boot/expo.c | 3 + > boot/expo_build.c | 36 ++--- > boot/expo_build_cb.c | 245 ++ > boot/scene.c | 61 ++-- > boot/scene_internal.h | 30 +++- > boot/scene_menu.c | 26 +++- > boot/scene_textline.c | 3 +- > cmd/Kconfig | 12 ++ > cmd/cedit.c | 28 > cmd/x86/Makefile | 1 + > cmd/x86/cbcmos.c | 139 + > cmd/x86/cbsysinfo.c | 73 - > configs/coreboot64_defconfig | 2 + > configs/coreboot_defconfig| 6 + > doc/board/coreboot/coreboot.rst | 6 + > doc/develop/cedit.rst | 9 +- > doc/develop/expo.rst | 26 +++- > doc/usage/cmd/cbcmos.rst | 45 ++ > doc/usage/cmd/cbsysinfo.rst | 99 > doc/usage/cmd/cedit.rst | 91 ++- > doc/usage/index.rst | 1 + > drivers/video/vidconsole-uclass.c | 4 +- > drivers/video/video-uclass.c | 3 + > include/cedit.h | 2 + > include/expo.h| 51 +-- > include/test/cedit-test.h | 30 ++-- > include/video.h | 4 +- > include/video_console.h | 8 + > test/boot/cedit.c | 22 ++- > test/boot/expo.c | 26 +++- > test/boot/files/expo_ids.h| 3 +- > test/boot/files/expo_layout.dts | 5 +- > test/cmd/Makefile | 1 + > test/cmd/coreboot.c | 119 +++ > tools/expo.py | 33 +++- > 41 files changed, 1309 insertions(+), 153 deletions(-) > create mode 100644 boot/expo_build_cb.c > create mode 100644 cmd/x86/cbcmos.c > create mode 100644 doc/usage/cmd/cbcmos.rst > create mode 100644 test/cmd/coreboot.c > I have applied all patches in the queue to u-boot-x86/master. When testing coreboot with the graphics console, I found a regression. See below: With u-boot/master, I got: https://ibb.co/swt8ZQ5 With u-boot-x86/master, I got: https://ibb.co/5MZ76mC As you can see, the text is crooked and misaligned. I didn't have time to locate which commit(s) is the culprit. Would you please take a look? Regards, Bin
[PATCH] tools: docker: Drop the git user name and email configuration
Since commit b45ab9ca6621 ("CI: Update to QEMU 8.0.3"), the manual
patch applying was removed, hence there is no need to do a git user
name and email configuration.
Signed-off-by: Bin Meng
---
tools/docker/Dockerfile | 3 ---
1 file changed, 3 deletions(-)
diff --git a/tools/docker/Dockerfile b/tools/docker/Dockerfile
index c4a2596b48..c12ed0fd9b 100644
--- a/tools/docker/Dockerfile
+++ b/tools/docker/Dockerfile
@@ -179,9 +179,6 @@ RUN git clone git://git.savannah.gnu.org/grub.git /tmp/grub
&& \
RUN git clone https://gitlab.com/qemu-project/qemu.git /tmp/qemu && \
cd /tmp/qemu && \
git checkout v8.0.3 && \
- # config user.name and user.email to make 'git am' happy
- git config user.name u-boot && \
- git config user.email u-b...@denx.de && \
./configure --prefix=/opt/qemu
--target-list="aarch64-softmmu,arm-softmmu,i386-softmmu,m68k-softmmu,mips-softmmu,mips64-softmmu,mips64el-softmmu,mipsel-softmmu,ppc-softmmu,riscv32-softmmu,riscv64-softmmu,sh4-softmmu,x86_64-softmmu,xtensa-softmmu"
&& \
make -j$(nproc) all install && \
rm -rf /tmp/qemu
--
2.34.1
Re: [PATCH 00/34] x86: expo: Add support for editing coreboot CMOS RAM settings
Hi Simon, On Sun, Dec 31, 2023 at 8:43 PM Simon Glass wrote: > > Hi Bin, > > On Sun, Dec 31, 2023 at 2:59 AM Bin Meng wrote: > > > > Hi Simon, > > > > On Wed, Nov 15, 2023 at 9:24 PM Simon Glass wrote: > > > > > > Hi Bin, > > > > > > On Sun, 1 Oct 2023 at 19:16, Simon Glass wrote: > > > > > > > > U-Boot provides support for editing settings with an 'expo', as well as > > > > reading and writing settings to CMOS RAM. > > > > > > > > This series integrates expo functionality with coreboot, using the > > > > sysinfo table to get a list of settings, creating an expo with them and > > > > allowing them to be edited. > > > > > > > > A new CI test provides coverage for some coreboot-related commands. For > > > > this to work, a number of minor tweaks are made to existing tests, so > > > > that they pass on coreboot (x86) or at least are skipped when they > > > > cannot pass. Likely most of these fixes will apply to other boards too. > > > > > > > > It includes several other fixes and improvements: > > > > - new -m flag for 'bootflow scan' so it can display a menu automatically > > > > - Fix for video-scrolling crash with Truetype > > > > - menu items can now have individual integer values > > > > - menu items are lined up according to the width of all menu labels > > > > > > > > > > > > Simon Glass (34): > > > > test: Run tests that don't need devices > > > > test: Add a new suite for commands > > > > test: Add helper to skip to partial console line > > > > test: Make UT_LIB_ASN1 depend on sandbox > > > > test: Run bootstd tests only on sandbox > > > > test: Handle use of stack pointer in bdinfo > > > > test: bdinfo: Add missing asserts > > > > test: fdt: Add a special case for real boards > > > > test: font: Add dependencies on fonts > > > > test: event: Only run test_event_probe() on sandbox > > > > test: lmb: Move tests into the lib suite > > > > test: print: Skip test on x86 > > > > video: Add a function to clear the display > > > > sandbox: Add a dummy booti command > > > > bootstd: Add a menu option to bootflow scan > > > > video: Add a dark-grey console colour > > > > video: Avoid starting a new line to close to the bottom > > > > expo: Place menu items to the right of all labels > > > > expo: Set the initial next_id to 1 > > > > expo: Use standard numbering for save and discard > > > > expo: Allow menu items to have values > > > > expo: Add a little more cedit CMOS logging > > > > expo: Support menu-item values in cedit > > > > expo: Drop unneceesary calls to expo_str() > > > > expo: Drop scene_title_set() > > > > expo: Add forward declaration for udevice to cedit > > > > x86: coreboot: Enable unit tests > > > > x86: CI: Update coreboot > > > > x86: coreboot: Add a test for cbsysinfo command > > > > x86: coreboot: Show the option table > > > > x86: coreboot: Enable support for the configuration editor > > > > x86: coreboot: Add a command to check and update CMOS RAM > > > > x86: coreboot: Allow building an expo for editing CMOS config > > > > x86: Enable RTC command by default > > > > > > > > .azure-pipelines.yml | 2 +- > > > > .gitlab-ci.yml| 2 +- > > > > arch/sandbox/dts/cedit.dtsi | 3 + > > > > arch/sandbox/lib/bootm.c | 7 + > > > > arch/x86/dts/coreboot.dts | 7 + > > > > boot/Makefile | 4 + > > > > boot/cedit.c | 191 +++ > > > > boot/expo.c | 3 + > > > > boot/expo_build.c | 36 ++--- > > > > boot/expo_build_cb.c | 244 ++ > > > > boot/scene.c | 61 ++-- > > > > boot/scene_internal.h | 30 +++- > > > > boot/scene_menu.c | 26 +++- > > > > boot/scene_textline.c | 3 +- > > > > cmd/Kconfig | 14 +- > > > > cmd/bootflow.c| 27 +++- > > > > cmd/booti.c
Re: [PATCH 00/34] x86: expo: Add support for editing coreboot CMOS RAM settings
Hi Simon, On Wed, Nov 15, 2023 at 9:24 PM Simon Glass wrote: > > Hi Bin, > > On Sun, 1 Oct 2023 at 19:16, Simon Glass wrote: > > > > U-Boot provides support for editing settings with an 'expo', as well as > > reading and writing settings to CMOS RAM. > > > > This series integrates expo functionality with coreboot, using the > > sysinfo table to get a list of settings, creating an expo with them and > > allowing them to be edited. > > > > A new CI test provides coverage for some coreboot-related commands. For > > this to work, a number of minor tweaks are made to existing tests, so > > that they pass on coreboot (x86) or at least are skipped when they > > cannot pass. Likely most of these fixes will apply to other boards too. > > > > It includes several other fixes and improvements: > > - new -m flag for 'bootflow scan' so it can display a menu automatically > > - Fix for video-scrolling crash with Truetype > > - menu items can now have individual integer values > > - menu items are lined up according to the width of all menu labels > > > > > > Simon Glass (34): > > test: Run tests that don't need devices > > test: Add a new suite for commands > > test: Add helper to skip to partial console line > > test: Make UT_LIB_ASN1 depend on sandbox > > test: Run bootstd tests only on sandbox > > test: Handle use of stack pointer in bdinfo > > test: bdinfo: Add missing asserts > > test: fdt: Add a special case for real boards > > test: font: Add dependencies on fonts > > test: event: Only run test_event_probe() on sandbox > > test: lmb: Move tests into the lib suite > > test: print: Skip test on x86 > > video: Add a function to clear the display > > sandbox: Add a dummy booti command > > bootstd: Add a menu option to bootflow scan > > video: Add a dark-grey console colour > > video: Avoid starting a new line to close to the bottom > > expo: Place menu items to the right of all labels > > expo: Set the initial next_id to 1 > > expo: Use standard numbering for save and discard > > expo: Allow menu items to have values > > expo: Add a little more cedit CMOS logging > > expo: Support menu-item values in cedit > > expo: Drop unneceesary calls to expo_str() > > expo: Drop scene_title_set() > > expo: Add forward declaration for udevice to cedit > > x86: coreboot: Enable unit tests > > x86: CI: Update coreboot > > x86: coreboot: Add a test for cbsysinfo command > > x86: coreboot: Show the option table > > x86: coreboot: Enable support for the configuration editor > > x86: coreboot: Add a command to check and update CMOS RAM > > x86: coreboot: Allow building an expo for editing CMOS config > > x86: Enable RTC command by default > > > > .azure-pipelines.yml | 2 +- > > .gitlab-ci.yml| 2 +- > > arch/sandbox/dts/cedit.dtsi | 3 + > > arch/sandbox/lib/bootm.c | 7 + > > arch/x86/dts/coreboot.dts | 7 + > > boot/Makefile | 4 + > > boot/cedit.c | 191 +++ > > boot/expo.c | 3 + > > boot/expo_build.c | 36 ++--- > > boot/expo_build_cb.c | 244 ++ > > boot/scene.c | 61 ++-- > > boot/scene_internal.h | 30 +++- > > boot/scene_menu.c | 26 +++- > > boot/scene_textline.c | 3 +- > > cmd/Kconfig | 14 +- > > cmd/bootflow.c| 27 +++- > > cmd/booti.c | 2 +- > > cmd/cedit.c | 28 > > cmd/cls.c | 25 +-- > > cmd/x86/Makefile | 1 + > > cmd/x86/cbcmos.c | 141 + > > cmd/x86/cbsysinfo.c | 73 - > > common/console.c | 31 > > configs/coreboot64_defconfig | 2 + > > configs/coreboot_defconfig| 6 + > > configs/tools-only_defconfig | 3 +- > > doc/board/coreboot/coreboot.rst | 6 + > > doc/develop/cedit.rst | 9 +- > > doc/develop/expo.rst | 26 +++- > > doc/usage/cmd/bootflow.rst| 5 + > > doc/usage/cmd/cbcmos.rst | 45 ++ > > doc/usage/cmd/cbsysinfo.rst | 99 > > doc/usage/cmd/cedit.rst | 91 ++- > > doc/usage/index.rst | 1 + > > drivers/video/vidconsole-uclass.c | 4 +- > > drivers/video/video-uclass.c | 3 + > > include/cedit.h | 1 + > > include/console.h | 10 ++ > > include/expo.h| 51 +-- > > include/test/cedit-test.h | 30 ++-- > > include/test/cmd.h| 15 ++ > > include/test/suites.h | 1 + > > include/test/ut.h | 30 > > include/video.h | 4 +- > > include/video_console.h | 8
Re: [PATCH 2/2] smbios: copy QEMU tables
Hi Heinrich, On Thu, Dec 21, 2023 at 6:50 PM Heinrich Schuchardt wrote: > > QEMU provides SMBIOS tables with detailed information. We should not try to > replicate them in U-Boot. > > If we want to inform about U-Boot, we can add a Firmware Inventory > Information (type 45) table in future. > > Signed-off-by: Heinrich Schuchardt > --- > drivers/misc/Kconfig| 8 ++ > drivers/misc/Makefile | 1 + > drivers/misc/qfw_smbios.c | 195 > lib/efi_loader/efi_smbios.c | 4 +- > 4 files changed, 207 insertions(+), 1 deletion(-) > create mode 100644 drivers/misc/qfw_smbios.c > > diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig > index e8e4400516..3d885f12c8 100644 > --- a/drivers/misc/Kconfig > +++ b/drivers/misc/Kconfig > @@ -561,6 +561,14 @@ config QFW_MMIO > Hidden option to enable MMIO QEMU fw_cfg interface. This will be > selected by the appropriate QEMU board. > > +config QFW_SMBIOS > + bool > + default y if ARM64 > + default y if RISCV && 64BIT Would you add QEMU x86 support as well? > + depends on QFW && SMBIOS > + help > + Hidden option to read SMBIOS tables from QEMU. > + > config I2C_EEPROM > bool "Enable driver for generic I2C-attached EEPROMs" > depends on MISC [snip] Regards, Bin
Re: [PATCH v3 4/9] risc-v: add ACPI fields to global data
On Tue, Dec 19, 2023 at 8:24 PM Heinrich Schuchardt wrote: > > Add fields for the location of ACPI tables to the global data. nits: I believe the tag should be 'riscv' instead of 'risc-v'. > > Signed-off-by: Heinrich Schuchardt > Reviewed-by: Simon Glass > --- > v3: > let tables in global data depend on CONFIG_(SPL_)ACPI > v2: > no change > --- > arch/riscv/include/asm/global_data.h | 6 ++ > 1 file changed, 6 insertions(+) > Otherwise, Reviewed-by: Bin Meng
Re: [PATCH v3 8/9] configs: qemu: add config fragment for ACPI
Hi Heinrich, On Tue, Dec 19, 2023 at 8:25 PM Heinrich Schuchardt wrote: > > Provide a configuration fragment to enable ACPI on QEMU. > > Signed-off-by: Heinrich Schuchardt > Acked-by: Ilias Apalodimas > Reviewed-by: Simon Glass > --- > v3: > no change > v2: > no change > --- > MAINTAINERS | 1 + > board/emulation/configs/acpi.config | 3 +++ > doc/board/emulation/acpi.rst| 23 +++ > doc/board/emulation/index.rst | 1 + > 4 files changed, 28 insertions(+) > create mode 100644 board/emulation/configs/acpi.config > create mode 100644 doc/board/emulation/acpi.rst > > diff --git a/MAINTAINERS b/MAINTAINERS > index 25f2bb80de..bf437b253b 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -53,6 +53,7 @@ Maintainers List (try to look for most precise areas first) > ACPI: > M: Simon Glass > S: Maintained > +F: board/emulation/configs/acpi.config > F: cmd/acpi.c > F: lib/acpi/ > > diff --git a/board/emulation/configs/acpi.config > b/board/emulation/configs/acpi.config > new file mode 100644 > index 00..b7ed811e33 > --- /dev/null > +++ b/board/emulation/configs/acpi.config > @@ -0,0 +1,3 @@ > +CONFIG_CMD_QFW=y > +CONFIG_ACPI=y > +CONFIG_GENERATE_ACPI_TABLE=y > diff --git a/doc/board/emulation/acpi.rst b/doc/board/emulation/acpi.rst > new file mode 100644 > index 00..e1208ca51e > --- /dev/null > +++ b/doc/board/emulation/acpi.rst > @@ -0,0 +1,23 @@ > +.. SPDX-License-Identifier: GPL-2.0+ > + > +ACPI on QEMU > + > + > +QEMU can provide ACPI tables on ARM, RISC-V, and x86. ACPI support on RISC-V landed on QEMU in a pretty recent version. Would you mind documenting its version? I haven't checked QEMU yet. Is ACPI default on in QEMU for Arm and RISC-V virt? If not, we should document QEMU commands to enable ACPI. > + > +The following settings are needed:: > + > +CONFIG_CMD_QFW=y > +CONFIG_ACPI=y > +CONFIG_GENERATE_ACPI_TABLE=y > + > +On x86 these settings are already included in the defconfig files. ARM and > +RISC-V default to use device-trees. > + > +Instead of updating the configuration manually you can add the configuration > +fragment `acpi.config` to the make command for initializing the > configuration. > +E.g. > + > +.. code-block:: bash > + > +make qemu-riscv64_smode_defconfig acpi.config > diff --git a/doc/board/emulation/index.rst b/doc/board/emulation/index.rst > index 932c65adeb..d3d6b8f3d8 100644 > --- a/doc/board/emulation/index.rst > +++ b/doc/board/emulation/index.rst > @@ -6,6 +6,7 @@ Emulation > .. toctree:: > :maxdepth: 1 > > + acpi > blkdev > ../../usage/semihosting > qemu-arm > -- Regards, Bin
Re: [PATCH v4 09/12] x86: Enable SSE in 64-bit mode
Hi Tom, On Wed, Nov 15, 2023 at 12:22 AM Tom Rini wrote: > > On Tue, Nov 14, 2023 at 09:49:08AM +0800, Bin Meng wrote: > > Hi Tom, > > > > On Tue, Nov 14, 2023 at 7:52 AM Tom Rini wrote: > > > > > > On Tue, Nov 14, 2023 at 07:46:36AM +0800, Bin Meng wrote: > > > > Hi Tom, > > > > > > > > On Tue, Nov 14, 2023 at 6:59 AM Tom Rini wrote: > > > > > > > > > > On Mon, Nov 13, 2023 at 03:28:13PM -0700, Simon Glass wrote: > > > > > > Hi Bin, > > > > > > > > > > > > On Mon, 13 Nov 2023 at 15:08, Bin Meng wrote: > > > > > > > > > > > > > > Hi Simon, > > > > > > > > > > > > > > On Mon, Nov 13, 2023 at 4:03 AM Simon Glass > > > > > > > wrote: > > > > > > > > > > > > > > > > This is needed to support Truetype fonts. In any case, the > > > > > > > > compiler > > > > > > > > expects SSE to be available in 64-bit mode. Provide an option > > > > > > > > to enable > > > > > > > > SSE so that hardware floating-point arithmetic works. > > > > > > > > > > > > > > > > Signed-off-by: Simon Glass > > > > > > > > Suggested-by: Bin Meng > > > > > > > > --- > > > > > > > > > > > > > > > > Changes in v4: > > > > > > > > - Use a Kconfig option > > > > > > > > > > > > > > > > arch/x86/Kconfig | 8 > > > > > > > > arch/x86/config.mk| 4 > > > > > > > > arch/x86/cpu/x86_64/cpu.c | 12 > > > > > > > > drivers/video/Kconfig | 1 + > > > > > > > > 4 files changed, 25 insertions(+) > > > > > > > > > > > > > > > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > > > > > > > > index 99e59d94c606..6b532d712ee8 100644 > > > > > > > > --- a/arch/x86/Kconfig > > > > > > > > +++ b/arch/x86/Kconfig > > > > > > > > @@ -723,6 +723,14 @@ config ROM_TABLE_SIZE > > > > > > > > hex > > > > > > > > default 0x1 > > > > > > > > > > > > > > > > +config X86_HARDFP > > > > > > > > + bool "Support hardware floating point" > > > > > > > > + help > > > > > > > > + U-Boot generally does not make use of floating point. > > > > > > > > Where this is > > > > > > > > + needed, it can be enabled using this option. This > > > > > > > > adjusts the > > > > > > > > + start-up code for 64-bit mode and changes the > > > > > > > > compiler options for > > > > > > > > + 64-bit to enable SSE. > > > > > > > > > > > > > > As discussed in another thread, this option should be made global > > > > > > > to > > > > > > > all architectures and by default no. > > > > > > > > > > > > > > > + > > > > > > > > config HAVE_ITSS > > > > > > > > bool "Enable ITSS" > > > > > > > > help > > > > > > > > diff --git a/arch/x86/config.mk b/arch/x86/config.mk > > > > > > > > index 26ec1af2f0b0..2e3a7119e798 100644 > > > > > > > > --- a/arch/x86/config.mk > > > > > > > > +++ b/arch/x86/config.mk > > > > > > > > @@ -27,9 +27,13 @@ ifeq ($(IS_32BIT),y) > > > > > > > > PLATFORM_CPPFLAGS += -march=i386 -m32 > > > > > > > > else > > > > > > > > PLATFORM_CPPFLAGS += $(if $(CONFIG_SPL_BUILD),,-fpic) > > > > > > > > -fno-common -march=core2 -m64 > > > > > > > > + > > > > > > > > +ifndef CONFIG_X86_HARDFP > > > > > > > > PLATFORM_CPPFLAGS += -mno-mmx -mno-sse > > > > > > > > endif > > > > > > > > > > > > > > > > +endif # I
Re: [PATCH v4 09/12] x86: Enable SSE in 64-bit mode
Hi Tom, On Tue, Nov 14, 2023 at 7:52 AM Tom Rini wrote: > > On Tue, Nov 14, 2023 at 07:46:36AM +0800, Bin Meng wrote: > > Hi Tom, > > > > On Tue, Nov 14, 2023 at 6:59 AM Tom Rini wrote: > > > > > > On Mon, Nov 13, 2023 at 03:28:13PM -0700, Simon Glass wrote: > > > > Hi Bin, > > > > > > > > On Mon, 13 Nov 2023 at 15:08, Bin Meng wrote: > > > > > > > > > > Hi Simon, > > > > > > > > > > On Mon, Nov 13, 2023 at 4:03 AM Simon Glass wrote: > > > > > > > > > > > > This is needed to support Truetype fonts. In any case, the compiler > > > > > > expects SSE to be available in 64-bit mode. Provide an option to > > > > > > enable > > > > > > SSE so that hardware floating-point arithmetic works. > > > > > > > > > > > > Signed-off-by: Simon Glass > > > > > > Suggested-by: Bin Meng > > > > > > --- > > > > > > > > > > > > Changes in v4: > > > > > > - Use a Kconfig option > > > > > > > > > > > > arch/x86/Kconfig | 8 > > > > > > arch/x86/config.mk| 4 > > > > > > arch/x86/cpu/x86_64/cpu.c | 12 > > > > > > drivers/video/Kconfig | 1 + > > > > > > 4 files changed, 25 insertions(+) > > > > > > > > > > > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > > > > > > index 99e59d94c606..6b532d712ee8 100644 > > > > > > --- a/arch/x86/Kconfig > > > > > > +++ b/arch/x86/Kconfig > > > > > > @@ -723,6 +723,14 @@ config ROM_TABLE_SIZE > > > > > > hex > > > > > > default 0x1 > > > > > > > > > > > > +config X86_HARDFP > > > > > > + bool "Support hardware floating point" > > > > > > + help > > > > > > + U-Boot generally does not make use of floating point. > > > > > > Where this is > > > > > > + needed, it can be enabled using this option. This adjusts > > > > > > the > > > > > > + start-up code for 64-bit mode and changes the compiler > > > > > > options for > > > > > > + 64-bit to enable SSE. > > > > > > > > > > As discussed in another thread, this option should be made global to > > > > > all architectures and by default no. > > > > > > > > > > > + > > > > > > config HAVE_ITSS > > > > > > bool "Enable ITSS" > > > > > > help > > > > > > diff --git a/arch/x86/config.mk b/arch/x86/config.mk > > > > > > index 26ec1af2f0b0..2e3a7119e798 100644 > > > > > > --- a/arch/x86/config.mk > > > > > > +++ b/arch/x86/config.mk > > > > > > @@ -27,9 +27,13 @@ ifeq ($(IS_32BIT),y) > > > > > > PLATFORM_CPPFLAGS += -march=i386 -m32 > > > > > > else > > > > > > PLATFORM_CPPFLAGS += $(if $(CONFIG_SPL_BUILD),,-fpic) -fno-common > > > > > > -march=core2 -m64 > > > > > > + > > > > > > +ifndef CONFIG_X86_HARDFP > > > > > > PLATFORM_CPPFLAGS += -mno-mmx -mno-sse > > > > > > endif > > > > > > > > > > > > +endif # IS_32BIT > > > > > > + > > > > > > PLATFORM_RELFLAGS += -fdata-sections -ffunction-sections > > > > > > -fvisibility=hidden > > > > > > > > > > > > KBUILD_LDFLAGS += -Bsymbolic -Bsymbolic-functions > > > > > > diff --git a/arch/x86/cpu/x86_64/cpu.c b/arch/x86/cpu/x86_64/cpu.c > > > > > > index 2647bff891f8..5ea746ecce4d 100644 > > > > > > --- a/arch/x86/cpu/x86_64/cpu.c > > > > > > +++ b/arch/x86/cpu/x86_64/cpu.c > > > > > > @@ -10,6 +10,7 @@ > > > > > > #include > > > > > > #include > > > > > > #include > > > > > > +#include > > > > > > > > > > > > DECLARE_GLOBAL_DATA_PTR; > > > > > > > > > > > > @@ -39,11 +40,22 @@ int x86_mp_init(void) > > > > > >
Re: [PATCH v4 09/12] x86: Enable SSE in 64-bit mode
Hi Tom,
On Tue, Nov 14, 2023 at 6:59 AM Tom Rini wrote:
>
> On Mon, Nov 13, 2023 at 03:28:13PM -0700, Simon Glass wrote:
> > Hi Bin,
> >
> > On Mon, 13 Nov 2023 at 15:08, Bin Meng wrote:
> > >
> > > Hi Simon,
> > >
> > > On Mon, Nov 13, 2023 at 4:03 AM Simon Glass wrote:
> > > >
> > > > This is needed to support Truetype fonts. In any case, the compiler
> > > > expects SSE to be available in 64-bit mode. Provide an option to enable
> > > > SSE so that hardware floating-point arithmetic works.
> > > >
> > > > Signed-off-by: Simon Glass
> > > > Suggested-by: Bin Meng
> > > > ---
> > > >
> > > > Changes in v4:
> > > > - Use a Kconfig option
> > > >
> > > > arch/x86/Kconfig | 8
> > > > arch/x86/config.mk| 4
> > > > arch/x86/cpu/x86_64/cpu.c | 12
> > > > drivers/video/Kconfig | 1 +
> > > > 4 files changed, 25 insertions(+)
> > > >
> > > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> > > > index 99e59d94c606..6b532d712ee8 100644
> > > > --- a/arch/x86/Kconfig
> > > > +++ b/arch/x86/Kconfig
> > > > @@ -723,6 +723,14 @@ config ROM_TABLE_SIZE
> > > > hex
> > > > default 0x1
> > > >
> > > > +config X86_HARDFP
> > > > + bool "Support hardware floating point"
> > > > + help
> > > > + U-Boot generally does not make use of floating point. Where
> > > > this is
> > > > + needed, it can be enabled using this option. This adjusts the
> > > > + start-up code for 64-bit mode and changes the compiler
> > > > options for
> > > > + 64-bit to enable SSE.
> > >
> > > As discussed in another thread, this option should be made global to
> > > all architectures and by default no.
> > >
> > > > +
> > > > config HAVE_ITSS
> > > > bool "Enable ITSS"
> > > > help
> > > > diff --git a/arch/x86/config.mk b/arch/x86/config.mk
> > > > index 26ec1af2f0b0..2e3a7119e798 100644
> > > > --- a/arch/x86/config.mk
> > > > +++ b/arch/x86/config.mk
> > > > @@ -27,9 +27,13 @@ ifeq ($(IS_32BIT),y)
> > > > PLATFORM_CPPFLAGS += -march=i386 -m32
> > > > else
> > > > PLATFORM_CPPFLAGS += $(if $(CONFIG_SPL_BUILD),,-fpic) -fno-common
> > > > -march=core2 -m64
> > > > +
> > > > +ifndef CONFIG_X86_HARDFP
> > > > PLATFORM_CPPFLAGS += -mno-mmx -mno-sse
> > > > endif
> > > >
> > > > +endif # IS_32BIT
> > > > +
> > > > PLATFORM_RELFLAGS += -fdata-sections -ffunction-sections
> > > > -fvisibility=hidden
> > > >
> > > > KBUILD_LDFLAGS += -Bsymbolic -Bsymbolic-functions
> > > > diff --git a/arch/x86/cpu/x86_64/cpu.c b/arch/x86/cpu/x86_64/cpu.c
> > > > index 2647bff891f8..5ea746ecce4d 100644
> > > > --- a/arch/x86/cpu/x86_64/cpu.c
> > > > +++ b/arch/x86/cpu/x86_64/cpu.c
> > > > @@ -10,6 +10,7 @@
> > > > #include
> > > > #include
> > > > #include
> > > > +#include
> > > >
> > > > DECLARE_GLOBAL_DATA_PTR;
> > > >
> > > > @@ -39,11 +40,22 @@ int x86_mp_init(void)
> > > > return 0;
> > > > }
> > > >
> > > > +/* enable SSE features for hardware floating point */
> > > > +static void setup_sse_features(void)
> > > > +{
> > > > + asm ("mov %%cr4, %%rax\n" \
> > > > + "or %0, %%rax\n" \
> > > > + "mov %%rax, %%cr4\n" \
> > > > + : : "i" (X86_CR4_OSFXSR | X86_CR4_OSXMMEXCPT) : "eax");
> > > > +}
> > > > +
> > > > int x86_cpu_reinit_f(void)
> > > > {
> > > > /* set the vendor to Intel so that native_calibrate_tsc() works
> > > > */
> > > > gd->arch.x86_vendor = X86_VENDOR_INTEL;
> > > > gd->arch.has_mtrr = true;
> > > > + if (IS_ENABLED(CONFIG_X86_HARDFP))
> > > > + setup_sse_features();
> > > >
> > > > return 0;
> > > > }
> &
Re: [PATCH v4 09/12] x86: Enable SSE in 64-bit mode
Hi Simon,
On Mon, Nov 13, 2023 at 4:03 AM Simon Glass wrote:
>
> This is needed to support Truetype fonts. In any case, the compiler
> expects SSE to be available in 64-bit mode. Provide an option to enable
> SSE so that hardware floating-point arithmetic works.
>
> Signed-off-by: Simon Glass
> Suggested-by: Bin Meng
> ---
>
> Changes in v4:
> - Use a Kconfig option
>
> arch/x86/Kconfig | 8
> arch/x86/config.mk| 4
> arch/x86/cpu/x86_64/cpu.c | 12
> drivers/video/Kconfig | 1 +
> 4 files changed, 25 insertions(+)
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 99e59d94c606..6b532d712ee8 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -723,6 +723,14 @@ config ROM_TABLE_SIZE
> hex
> default 0x1
>
> +config X86_HARDFP
> + bool "Support hardware floating point"
> + help
> + U-Boot generally does not make use of floating point. Where this is
> + needed, it can be enabled using this option. This adjusts the
> + start-up code for 64-bit mode and changes the compiler options for
> + 64-bit to enable SSE.
As discussed in another thread, this option should be made global to
all architectures and by default no.
> +
> config HAVE_ITSS
> bool "Enable ITSS"
> help
> diff --git a/arch/x86/config.mk b/arch/x86/config.mk
> index 26ec1af2f0b0..2e3a7119e798 100644
> --- a/arch/x86/config.mk
> +++ b/arch/x86/config.mk
> @@ -27,9 +27,13 @@ ifeq ($(IS_32BIT),y)
> PLATFORM_CPPFLAGS += -march=i386 -m32
> else
> PLATFORM_CPPFLAGS += $(if $(CONFIG_SPL_BUILD),,-fpic) -fno-common
> -march=core2 -m64
> +
> +ifndef CONFIG_X86_HARDFP
> PLATFORM_CPPFLAGS += -mno-mmx -mno-sse
> endif
>
> +endif # IS_32BIT
> +
> PLATFORM_RELFLAGS += -fdata-sections -ffunction-sections -fvisibility=hidden
>
> KBUILD_LDFLAGS += -Bsymbolic -Bsymbolic-functions
> diff --git a/arch/x86/cpu/x86_64/cpu.c b/arch/x86/cpu/x86_64/cpu.c
> index 2647bff891f8..5ea746ecce4d 100644
> --- a/arch/x86/cpu/x86_64/cpu.c
> +++ b/arch/x86/cpu/x86_64/cpu.c
> @@ -10,6 +10,7 @@
> #include
> #include
> #include
> +#include
>
> DECLARE_GLOBAL_DATA_PTR;
>
> @@ -39,11 +40,22 @@ int x86_mp_init(void)
> return 0;
> }
>
> +/* enable SSE features for hardware floating point */
> +static void setup_sse_features(void)
> +{
> + asm ("mov %%cr4, %%rax\n" \
> + "or %0, %%rax\n" \
> + "mov %%rax, %%cr4\n" \
> + : : "i" (X86_CR4_OSFXSR | X86_CR4_OSXMMEXCPT) : "eax");
> +}
> +
> int x86_cpu_reinit_f(void)
> {
> /* set the vendor to Intel so that native_calibrate_tsc() works */
> gd->arch.x86_vendor = X86_VENDOR_INTEL;
> gd->arch.has_mtrr = true;
> + if (IS_ENABLED(CONFIG_X86_HARDFP))
> + setup_sse_features();
>
> return 0;
> }
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index 6f319ba0d544..39c82521be16 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -180,6 +180,7 @@ config CONSOLE_ROTATION
>
> config CONSOLE_TRUETYPE
> bool "Support a console that uses TrueType fonts"
> + select X86_HARDFP if X86
This should be "depends on HARDFP", indicating that the TrueType
library is using hardware fp itself, and user has to explicitly turn
the hardware fp Kconfig option on.
"Select" does not work for architectures that does not have the
"enabling hardware fp" logic in place.
> help
> TrueTrype fonts can provide outline-drawing capability rather than
> needing to provide a bitmap for each font and size that is needed.
> --
Regards,
Bin
Re: [PATCH v3 09/12] x86: Enable SSE in 64-bit mode
Hi Simon, On Mon, Nov 13, 2023 at 4:02 AM Simon Glass wrote: > > Hi Bin, > > On Mon, 6 Nov 2023 at 08:36, Tom Rini wrote: > > > > On Mon, Nov 06, 2023 at 06:26:15PM +0800, Bin Meng wrote: > > > + Tom, > > > > > > Hi Simon, > > > > > > On Mon, Nov 6, 2023 at 12:29 AM Simon Glass wrote: > > > > > > > > Hi Bin, > > > > > > > > On Sun, 5 Nov 2023 at 14:05, Bin Meng wrote: > > > > > > > > > > Hi Simon, > > > > > > > > > > On Mon, Oct 2, 2023 at 9:15 AM Simon Glass wrote: > > > > > > > > > > > > This is needed to support Truetype fonts. In any case, the compiler > > > > > > expects SSE to be available in 64-bit mode. Enable it. > > > > > > > > > > > > Signed-off-by: Simon Glass > > > > > > Suggested-by: Bin Meng > > > > > > --- > > > > > > > > > > > > (no changes since v1) > > > > > > > > > > > > arch/x86/config.mk| 1 - > > > > > > arch/x86/cpu/x86_64/cpu.c | 11 +++ > > > > > > 2 files changed, 11 insertions(+), 1 deletion(-) > > > > > > > > > > > > > > > > I didn't suggest we enable SSE for x86. This is the wrong approach. > > > > > > > > > > We should rewrite the Truetype support codes to avoid using > > > > > float/double types. > > > > > > > > > > This way the Truetype codes can be used on any other architectures > > > > > without the need for the compiler to emit explicit floating > > > > > instructions. > > > > > > > > I am not aware of any such library. At present, enabling truetype on > > > > coreboot64 causes a hang. > > > > > > > > > > If that's the case, we will have to either: > > > > > > - Switch all U-Boot builds' to use software float (e.g. -msoft-float) > > > which unfortunately depends on the compiler runtime intrinsics. > > > - Introduce a Kconfig option for hard float enabling and let each > > > architecture to decide whether it implements it or not, and update > > > Truetype to depend on the hard float. > > > > We generally do -msoft-float already, so introducing that for x86, and > > some Kconfig logic to ensure that no one else steps on this particular > > bug sounds reasonable. > > Yes soft float seems to be not-much-used on x86. For 64-bit chips the > compiler seems to assume that hardfp is available. We have compiler flags to ensure the compiler does not generate SSE instructions. Yes, I know SSE is in almost every x86 processor we see nowadays. > > So perhaps the best thing is to introduce a HARDFP option to x86 only. This option should be global as some other arches also don't have hardware fp, like RISC-V whose fp extension is optional. Regards, Bin
Re: [PATCH v3 09/12] x86: Enable SSE in 64-bit mode
+ Tom, Hi Simon, On Mon, Nov 6, 2023 at 12:29 AM Simon Glass wrote: > > Hi Bin, > > On Sun, 5 Nov 2023 at 14:05, Bin Meng wrote: > > > > Hi Simon, > > > > On Mon, Oct 2, 2023 at 9:15 AM Simon Glass wrote: > > > > > > This is needed to support Truetype fonts. In any case, the compiler > > > expects SSE to be available in 64-bit mode. Enable it. > > > > > > Signed-off-by: Simon Glass > > > Suggested-by: Bin Meng > > > --- > > > > > > (no changes since v1) > > > > > > arch/x86/config.mk| 1 - > > > arch/x86/cpu/x86_64/cpu.c | 11 +++ > > > 2 files changed, 11 insertions(+), 1 deletion(-) > > > > > > > I didn't suggest we enable SSE for x86. This is the wrong approach. > > > > We should rewrite the Truetype support codes to avoid using float/double > > types. > > > > This way the Truetype codes can be used on any other architectures > > without the need for the compiler to emit explicit floating > > instructions. > > I am not aware of any such library. At present, enabling truetype on > coreboot64 causes a hang. > If that's the case, we will have to either: - Switch all U-Boot builds' to use software float (e.g. -msoft-float) which unfortunately depends on the compiler runtime intrinsics. - Introduce a Kconfig option for hard float enabling and let each architecture to decide whether it implements it or not, and update Truetype to depend on the hard float. Regards, Bin
Re: [PATCH v2] x86: serial: ns16550: Allow the UART to be silently disabled
Hi Simon, On Thu, Nov 2, 2023 at 2:04 AM Simon Glass wrote: > > U-Boot normally requires a UART. When booting from coreboot it is > sometimes just not available, e.g. when no sysinfo or DBG2 information > is provided. > > In this case we need to continue running, since the display can be used. > Add a flag to disable serial for this case. > > This allows U-Boot to start up and operation from the display, instead > of hanging on start-up. > > This could perhaps be hidden behind a Kconfig option to reduce code > size. I think using a generic Kconfig option and filtering this out in the generic serial probe code is better than what is proposed in this patch. > > Signed-off-by: Simon Glass > --- > > Changes in v2: > - Drop RFC tag since there were no comments > > drivers/serial/ns16550.c | 17 +++-- > drivers/serial/serial_coreboot.c | 1 + > include/ns16550.h| 1 + > 3 files changed, 17 insertions(+), 2 deletions(-) > Regards, Bin
Re: [PATCH v3 08/12] video: Drop unnecessary truetype operations from SPL
On Mon, Oct 2, 2023 at 11:32 AM Simon Glass wrote: > > Saving and restoring entries is used for expo and for the command line, > which we don't use in SPL. Drop these methods. > > Signed-off-by: Simon Glass > --- > > Changes in v3: > - Add new patch to drop unnecessary truetype operations from SPL > > drivers/video/console_truetype.c | 10 ++ > 1 file changed, 10 insertions(+) > Reviewed-by: Bin Meng
Re: [PATCH v3 06/12] expo: Correct background colour
On Mon, Oct 2, 2023 at 9:30 AM Simon Glass wrote: > > Use the correct background colour when using white-on-black. > > Signed-off-by: Simon Glass > --- > > (no changes since v1) > > boot/expo.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > Reviewed-by: Bin Meng
Re: [PATCH v3 01/12] efi: Correct handling of frame buffer
On Mon, Oct 2, 2023 at 10:23 AM Simon Glass wrote:
>
> The efi_gop driver uses private fields from the video uclass to obtain a
> pointer to the frame buffer. Use the platform data instead.
>
> Check the VIDEO_COPY setting to determine which frame buffer to use. Once
> the next stage is running (and making use of U-Boot's EFI boot services)
> U-Boot does not handle copying from priv->fb to the hardware framebuffer,
> so we must allow EFI to write directly to the hardware framebuffer.
>
> We could provide a function to read this, but it seems better to just
> document how it works. The original change ignored an explicit comment
> in the video.h file ("Things that are private to the uclass: don't use
> these in the driver") which is why this was missed when the VIDEO_COPY
> feature was added.
>
> Signed-off-by: Simon Glass
> Fixes: 8f661a5b662 ("efi_loader: gop: Expose fb when 32bpp")
> ---
>
> (no changes since v2)
>
> Changes in v2:
> - Rebase to -next
> - Add some more comments to the header file
> - Add fixes tag
>
> include/video.h | 9 ++---
> lib/efi_loader/efi_gop.c | 12 +++-
> 2 files changed, 13 insertions(+), 8 deletions(-)
>
Reviewed-by: Bin Meng
Re: [PATCH v3 04/12] x86: coreboot: Add a boot script
On Mon, Oct 2, 2023 at 9:14 AM Simon Glass wrote: > > Provide the user with a list of available boot options. Selecting one > causes it to be booted. Pressing causes U-Boot to return to the > command-line prompt. > > Signed-off-by: Simon Glass > --- > > Changes in v3: > - Clear the screen before booting > > Changes in v2: > - Add new patch to add a coreboot boot script > > configs/coreboot64_defconfig | 1 + > configs/coreboot_defconfig | 1 + > 2 files changed, 2 insertions(+) > Reviewed-by: Bin Meng
Re: [PATCH v3 09/12] x86: Enable SSE in 64-bit mode
Hi Simon, On Mon, Oct 2, 2023 at 9:15 AM Simon Glass wrote: > > This is needed to support Truetype fonts. In any case, the compiler > expects SSE to be available in 64-bit mode. Enable it. > > Signed-off-by: Simon Glass > Suggested-by: Bin Meng > --- > > (no changes since v1) > > arch/x86/config.mk| 1 - > arch/x86/cpu/x86_64/cpu.c | 11 +++ > 2 files changed, 11 insertions(+), 1 deletion(-) > I didn't suggest we enable SSE for x86. This is the wrong approach. We should rewrite the Truetype support codes to avoid using float/double types. This way the Truetype codes can be used on any other architectures without the need for the compiler to emit explicit floating instructions. Regards, Bin
Re: [PATCH v2 0/9] ufs: Add a PCI UFS controller support
+ Marek, On Wed, Oct 11, 2023 at 9:16 PM Bin Meng wrote: > > This adds a PCI UFS controller support and enables the support on > QEMU RISC-V for testing. > > Requiring QEMU v8.2+. > > This series is avaiable at u-boot-x86/ufs for testing. > > Changes in v2: > - fix a build warning > > Bin Meng (9): > ufs: Correct the UFS terminlogy > ufs: Add a line feed to the end of some dev_xxx() messages > cmd: kconfig: Make ufs prompt look similar to other commands > cmd: ufs: Correct the help text > pci_ids: Add Red Hat vendor and device IDs > ufs: Allow mmio registers on the PCI bus > ufs: Add a PCI based UFS controller driver > ufs: Handle UFS 3.1 controllers > qemu: riscv: Enable UFS support > > board/emulation/qemu-riscv/Kconfig | 2 ++ > cmd/Kconfig| 2 +- > cmd/ufs.c | 2 +- > doc/board/emulation/qemu-riscv.rst | 8 +- > drivers/ufs/Kconfig| 11 > drivers/ufs/Makefile | 1 + > drivers/ufs/ufs-pci.c | 45 ++ > drivers/ufs/ufs-uclass.c | 2 +- > drivers/ufs/ufs.c | 31 > drivers/ufs/ufs.h | 1 + > include/pci_ids.h | 7 + > 11 files changed, 97 insertions(+), 15 deletions(-) > create mode 100644 drivers/ufs/ufs-pci.c > Ping?
[PATCH v2 1/9] ufs: Correct the UFS terminlogy
UFS stands for Universal Flash Storage, not Subsytem. Signed-off-by: Bin Meng --- (no changes since v1) cmd/Kconfig | 2 +- drivers/ufs/ufs-uclass.c | 2 +- drivers/ufs/ufs.c| 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/cmd/Kconfig b/cmd/Kconfig index 6470b138d2..a59c67e333 100644 --- a/cmd/Kconfig +++ b/cmd/Kconfig @@ -1536,7 +1536,7 @@ config CMD_TSI148 Turndra tsi148 device. See the command help for full details. config CMD_UFS - bool "Enable UFS - Universal Flash Subsystem commands" + bool "Enable UFS - Universal Flash Storage commands" depends on UFS help "This provides commands to initialise and configure universal flash diff --git a/drivers/ufs/ufs-uclass.c b/drivers/ufs/ufs-uclass.c index ceea30c4a9..ffae811d46 100644 --- a/drivers/ufs/ufs-uclass.c +++ b/drivers/ufs/ufs-uclass.c @@ -1,6 +1,6 @@ // SPDX-License-Identifier: GPL-2.0 /** - * ufs-uclass.c - Universal Flash Subsystem (UFS) Uclass driver + * ufs-uclass.c - Universal Flash Storage (UFS) Uclass driver * * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com */ diff --git a/drivers/ufs/ufs.c b/drivers/ufs/ufs.c index 7c48d57f99..f534d6e29f 100644 --- a/drivers/ufs/ufs.c +++ b/drivers/ufs/ufs.c @@ -1,6 +1,6 @@ // SPDX-License-Identifier: GPL-2.0+ /** - * ufs.c - Universal Flash Subsystem (UFS) driver + * ufs.c - Universal Flash Storage (UFS) driver * * Taken from Linux Kernel v5.2 (drivers/scsi/ufs/ufshcd.c) and ported * to u-boot. -- 2.34.1
[PATCH v2 8/9] ufs: Handle UFS 3.1 controllers
Extend the version check to handle UFS 3.1 controllers as well.
Tested on QEMU emulated UFS 3.1 controller.
Signed-off-by: Bin Meng
---
(no changes since v1)
drivers/ufs/ufs.c | 3 ++-
drivers/ufs/ufs.h | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/ufs/ufs.c b/drivers/ufs/ufs.c
index fb2a607ef1..6287ce91a3 100644
--- a/drivers/ufs/ufs.c
+++ b/drivers/ufs/ufs.c
@@ -1953,7 +1953,8 @@ int ufshcd_probe(struct udevice *ufs_dev, struct
ufs_hba_ops *hba_ops)
hba->version != UFSHCI_VERSION_11 &&
hba->version != UFSHCI_VERSION_20 &&
hba->version != UFSHCI_VERSION_21 &&
- hba->version != UFSHCI_VERSION_30)
+ hba->version != UFSHCI_VERSION_30 &&
+ hba->version != UFSHCI_VERSION_31)
dev_err(hba->dev, "invalid UFS version 0x%x\n",
hba->version);
diff --git a/drivers/ufs/ufs.h b/drivers/ufs/ufs.h
index 9daaf03d22..816a5ce0ca 100644
--- a/drivers/ufs/ufs.h
+++ b/drivers/ufs/ufs.h
@@ -782,6 +782,7 @@ enum {
UFSHCI_VERSION_20 = 0x0200, /* 2.0 */
UFSHCI_VERSION_21 = 0x0210, /* 2.1 */
UFSHCI_VERSION_30 = 0x0300, /* 3.0 */
+ UFSHCI_VERSION_31 = 0x0310, /* 3.1 */
};
/* Interrupt disable masks */
--
2.34.1
[PATCH v2 4/9] cmd: ufs: Correct the help text
Remove the additional space and use "sub-system" for consistency with other commands like "scsi" and "usb". Signed-off-by: Bin Meng --- (no changes since v1) cmd/ufs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cmd/ufs.c b/cmd/ufs.c index 143e946370..2c8d88df18 100644 --- a/cmd/ufs.c +++ b/cmd/ufs.c @@ -32,6 +32,6 @@ static int do_ufs(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]) } U_BOOT_CMD(ufs, 3, 1, do_ufs, - "UFS sub system", + "UFS sub-system", "init [dev] - init UFS subsystem\n" ); -- 2.34.1
[PATCH v2 5/9] pci_ids: Add Red Hat vendor and device IDs
Red Hat, Inc. donates a part of its device ID range [1] to QEMU, to be used for virtual devices. This commit adds several typical devices that are useful in U-Boot. [1] https://www.qemu.org/docs/master/specs/pci-ids.html Signed-off-by: Bin Meng --- (no changes since v1) include/pci_ids.h | 7 +++ 1 file changed, 7 insertions(+) diff --git a/include/pci_ids.h b/include/pci_ids.h index 88b0a64045..b63bf45168 100644 --- a/include/pci_ids.h +++ b/include/pci_ids.h @@ -1363,6 +1363,13 @@ #define PCI_DEVICE_ID_XILINX_HAMMERFALL_DSP 0x3fc5 #define PCI_DEVICE_ID_XILINX_HAMMERFALL_DSP_MADI 0x3fc6 +/* Per https://www.qemu.org/docs/master/specs/pci-ids.html */ +#define PCI_VENDOR_ID_REDHAT0x1b36 +#define PCI_DEVICE_ID_REDHAT_SDHCI 0x0007 +#define PCI_DEVICE_ID_REDHAT_XHCI 0x000d +#define PCI_DEVICE_ID_REDHAT_NVME 0x0010 +#define PCI_DEVICE_ID_REDHAT_UFS0x0013 + #define PCI_VENDOR_ID_INIT 0x1101 #define PCI_VENDOR_ID_CREATIVE 0x1102 /* duplicate: ECTIVA */ -- 2.34.1
[PATCH v2 6/9] ufs: Allow mmio registers on the PCI bus
Check if the UFS controller is on the PCI bus, and get its register
base address accordingly.
Signed-off-by: Bin Meng
---
(no changes since v1)
drivers/ufs/ufs.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/ufs/ufs.c b/drivers/ufs/ufs.c
index 96801866d3..fb2a607ef1 100644
--- a/drivers/ufs/ufs.c
+++ b/drivers/ufs/ufs.c
@@ -1914,6 +1914,7 @@ int ufshcd_probe(struct udevice *ufs_dev, struct
ufs_hba_ops *hba_ops)
struct ufs_hba *hba = dev_get_uclass_priv(ufs_dev);
struct scsi_plat *scsi_plat;
struct udevice *scsi_dev;
+ void __iomem *mmio_base;
int err;
device_find_first_child(ufs_dev, _dev);
@@ -1927,7 +1928,14 @@ int ufshcd_probe(struct udevice *ufs_dev, struct
ufs_hba_ops *hba_ops)
hba->dev = ufs_dev;
hba->ops = hba_ops;
- hba->mmio_base = dev_read_addr_ptr(ufs_dev);
+
+ if (device_is_on_pci_bus(ufs_dev)) {
+ mmio_base = dm_pci_map_bar(ufs_dev, PCI_BASE_ADDRESS_0, 0, 0,
+ PCI_REGION_TYPE, PCI_REGION_MEM);
+ } else {
+ mmio_base = dev_read_addr_ptr(ufs_dev);
+ }
+ hba->mmio_base = mmio_base;
/* Set descriptor lengths to specification defaults */
ufshcd_def_desc_sizes(hba);
--
2.34.1
[PATCH v2 7/9] ufs: Add a PCI based UFS controller driver
This adds a simple PCI based UFS controller driver with a QEMU
emulated UFS controller on the PCI bus.
Requiring QEMU v8.2+.
Signed-off-by: Bin Meng
---
Changes in v2:
- fix a build warning
drivers/ufs/Kconfig | 11 +++
drivers/ufs/Makefile | 1 +
drivers/ufs/ufs-pci.c | 45 +++
3 files changed, 57 insertions(+)
create mode 100644 drivers/ufs/ufs-pci.c
diff --git a/drivers/ufs/Kconfig b/drivers/ufs/Kconfig
index 0e0cc58e3d..42797ce052 100644
--- a/drivers/ufs/Kconfig
+++ b/drivers/ufs/Kconfig
@@ -15,6 +15,17 @@ config CADENCE_UFS
This selects the platform driver for the Cadence UFS host
controller present on present TI's J721e devices.
+config UFS_PCI
+ bool "PCI bus based UFS Controller support"
+ depends on PCI && UFS
+ help
+ This selects the PCI UFS Host Controller Interface. Select this if
+ you have UFS Host Controller with PCI Interface.
+
+ If you have a controller with this interface, say Y here.
+
+ If unsure, say N.
+
config TI_J721E_UFS
bool "Glue Layer driver for UFS on TI J721E devices"
help
diff --git a/drivers/ufs/Makefile b/drivers/ufs/Makefile
index 4f3344fd4e..13f1e689ef 100644
--- a/drivers/ufs/Makefile
+++ b/drivers/ufs/Makefile
@@ -6,4 +6,5 @@
obj-$(CONFIG_UFS) += ufs.o ufs-uclass.o
obj-$(CONFIG_CADENCE_UFS) += cdns-platform.o
obj-$(CONFIG_TI_J721E_UFS) += ti-j721e-ufs.o
+obj-$(CONFIG_UFS_PCI) += ufs-pci.o
obj-$(CONFIG_UFS_RENESAS) += ufs-renesas.o
diff --git a/drivers/ufs/ufs-pci.c b/drivers/ufs/ufs-pci.c
new file mode 100644
index 00..ad41358727
--- /dev/null
+++ b/drivers/ufs/ufs-pci.c
@@ -0,0 +1,45 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2023 tinylab.org
+ * Author: Bin Meng
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include "ufs.h"
+
+static int ufs_pci_bind(struct udevice *dev)
+{
+ struct udevice *scsi_dev;
+
+ return ufs_scsi_bind(dev, _dev);
+}
+
+static int ufs_pci_probe(struct udevice *dev)
+{
+ int err;
+
+ err = ufshcd_probe(dev, NULL);
+ if (err)
+ dev_err(dev, "%s failed (ret=%d)\n", __func__, err);
+
+ return err;
+}
+
+U_BOOT_DRIVER(ufs_pci) = {
+ .name = "ufs_pci",
+ .id = UCLASS_UFS,
+ .bind = ufs_pci_bind,
+ .probe = ufs_pci_probe,
+};
+
+static struct pci_device_id ufs_supported[] = {
+ { PCI_DEVICE(PCI_VENDOR_ID_REDHAT, PCI_DEVICE_ID_REDHAT_UFS) },
+ {},
+};
+
+U_BOOT_PCI_DEVICE(ufs_pci, ufs_supported);
--
2.34.1
[PATCH v2 9/9] qemu: riscv: Enable UFS support
This enables UFS support for QEMU RISC-V 'virt' machine. Signed-off-by: Bin Meng --- (no changes since v1) board/emulation/qemu-riscv/Kconfig | 2 ++ doc/board/emulation/qemu-riscv.rst | 8 +++- 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/board/emulation/qemu-riscv/Kconfig b/board/emulation/qemu-riscv/Kconfig index d56b4b5bc1..f3ee1f6e90 100644 --- a/board/emulation/qemu-riscv/Kconfig +++ b/board/emulation/qemu-riscv/Kconfig @@ -82,5 +82,7 @@ config BOARD_SPECIFIC_OPTIONS # dummy imply USB_XHCI_PCI imply USB_KEYBOARD imply CMD_USB + imply UFS + imply UFS_PCI endif diff --git a/doc/board/emulation/qemu-riscv.rst b/doc/board/emulation/qemu-riscv.rst index 61137bcbf1..8a5eb1eda5 100644 --- a/doc/board/emulation/qemu-riscv.rst +++ b/doc/board/emulation/qemu-riscv.rst @@ -131,7 +131,13 @@ An attached disk can be emulated in RISC-V virt machine by adding:: -drive if=none,file=riscv64.img,format=raw,id=mydisk \ -device ide-hd,drive=mydisk,bus=ahci.0 -You will have to run 'scsi scan' to use it. +or alternatively attach an emulated UFS:: + +-device ufs,id=ufs0 \ +-drive if=none,file=test.img,format=raw,id=lun0 \ +-device ufs-lu,drive=lun0,bus=ufs0 + +You will have to run 'scsi scan' to use them. A video console can be emulated in RISC-V virt machine by removing "-nographic" and adding:: -- 2.34.1
[PATCH v2 3/9] cmd: kconfig: Make ufs prompt look similar to other commands
At present the 'ufs' command prompt does not look similar like other commands. Update it. Signed-off-by: Bin Meng --- (no changes since v1) cmd/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cmd/Kconfig b/cmd/Kconfig index a59c67e333..0b4e76c262 100644 --- a/cmd/Kconfig +++ b/cmd/Kconfig @@ -1536,7 +1536,7 @@ config CMD_TSI148 Turndra tsi148 device. See the command help for full details. config CMD_UFS - bool "Enable UFS - Universal Flash Storage commands" + bool "ufs - Universal Flash Storage commands" depends on UFS help "This provides commands to initialise and configure universal flash -- 2.34.1
[PATCH v2 2/9] ufs: Add a line feed to the end of some dev_xxx() messages
Add a line feed to improve readability of some dev_xxx() messages.
Signed-off-by: Bin Meng
---
(no changes since v1)
drivers/ufs/ufs.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/ufs/ufs.c b/drivers/ufs/ufs.c
index f534d6e29f..96801866d3 100644
--- a/drivers/ufs/ufs.c
+++ b/drivers/ufs/ufs.c
@@ -320,7 +320,7 @@ static int ufshcd_disable_tx_lcc(struct ufs_hba *hba, bool
peer)
UIC_ARG_MPHY_TX_GEN_SEL_INDEX(i)),
0);
if (err) {
- dev_err(hba->dev, "%s: TX LCC Disable failed, peer =
%d, lane = %d, err = %d",
+ dev_err(hba->dev, "%s: TX LCC Disable failed, peer =
%d, lane = %d, err = %d\n",
__func__, peer, i, err);
break;
}
@@ -441,7 +441,7 @@ static int ufshcd_make_hba_operational(struct ufs_hba *hba)
ufshcd_enable_run_stop_reg(hba);
} else {
dev_err(hba->dev,
- "Host controller not ready to process requests");
+ "Host controller not ready to process requests\n");
err = -EIO;
goto out;
}
@@ -930,7 +930,7 @@ static int ufshcd_copy_query_response(struct ufs_hba *hba)
memcpy(hba->dev_cmd.query.descriptor, descp, resp_len);
} else {
dev_warn(hba->dev,
-"%s: Response size is bigger than buffer",
+"%s: Response size is bigger than buffer\n",
__func__);
return -EINVAL;
}
@@ -1179,11 +1179,11 @@ static int ufshcd_read_desc_length(struct ufs_hba *hba,
enum desc_idn desc_id,
_len);
if (ret) {
- dev_err(hba->dev, "%s: Failed to get descriptor header id %d",
+ dev_err(hba->dev, "%s: Failed to get descriptor header id %d\n",
__func__, desc_id);
return ret;
} else if (desc_id != header[QUERY_DESC_DESC_TYPE_OFFSET]) {
- dev_warn(hba->dev, "%s: descriptor header id %d and desc_id %d
mismatch",
+ dev_warn(hba->dev, "%s: descriptor header id %d and desc_id %d
mismatch\n",
__func__, header[QUERY_DESC_DESC_TYPE_OFFSET],
desc_id);
ret = -EINVAL;
@@ -1302,7 +1302,7 @@ int ufshcd_read_desc_param(struct ufs_hba *hba, enum
desc_idn desc_id,
/* Sanity checks */
if (ret || !buff_len) {
- dev_err(hba->dev, "%s: Failed to get full descriptor length",
+ dev_err(hba->dev, "%s: Failed to get full descriptor length\n",
__func__);
return ret;
}
@@ -1323,14 +1323,14 @@ int ufshcd_read_desc_param(struct ufs_hba *hba, enum
desc_idn desc_id,
_len);
if (ret) {
- dev_err(hba->dev, "%s: Failed reading descriptor. desc_id %d,
desc_index %d, param_offset %d, ret %d",
+ dev_err(hba->dev, "%s: Failed reading descriptor. desc_id %d,
desc_index %d, param_offset %d, ret %d\n",
__func__, desc_id, desc_index, param_offset, ret);
goto out;
}
/* Sanity check */
if (desc_buf[QUERY_DESC_DESC_TYPE_OFFSET] != desc_id) {
- dev_err(hba->dev, "%s: invalid desc_id %d in descriptor header",
+ dev_err(hba->dev, "%s: invalid desc_id %d in descriptor
header\n",
__func__, desc_buf[QUERY_DESC_DESC_TYPE_OFFSET]);
ret = -EINVAL;
goto out;
--
2.34.1
[PATCH v2 0/9] ufs: Add a PCI UFS controller support
This adds a PCI UFS controller support and enables the support on QEMU RISC-V for testing. Requiring QEMU v8.2+. This series is avaiable at u-boot-x86/ufs for testing. Changes in v2: - fix a build warning Bin Meng (9): ufs: Correct the UFS terminlogy ufs: Add a line feed to the end of some dev_xxx() messages cmd: kconfig: Make ufs prompt look similar to other commands cmd: ufs: Correct the help text pci_ids: Add Red Hat vendor and device IDs ufs: Allow mmio registers on the PCI bus ufs: Add a PCI based UFS controller driver ufs: Handle UFS 3.1 controllers qemu: riscv: Enable UFS support board/emulation/qemu-riscv/Kconfig | 2 ++ cmd/Kconfig| 2 +- cmd/ufs.c | 2 +- doc/board/emulation/qemu-riscv.rst | 8 +- drivers/ufs/Kconfig| 11 drivers/ufs/Makefile | 1 + drivers/ufs/ufs-pci.c | 45 ++ drivers/ufs/ufs-uclass.c | 2 +- drivers/ufs/ufs.c | 31 drivers/ufs/ufs.h | 1 + include/pci_ids.h | 7 + 11 files changed, 97 insertions(+), 15 deletions(-) create mode 100644 drivers/ufs/ufs-pci.c -- 2.34.1
[PATCH 9/9] qemu: riscv: Enable UFS support
This enables UFS support for QEMU RISC-V 'virt' machine. Signed-off-by: Bin Meng --- board/emulation/qemu-riscv/Kconfig | 2 ++ doc/board/emulation/qemu-riscv.rst | 8 +++- 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/board/emulation/qemu-riscv/Kconfig b/board/emulation/qemu-riscv/Kconfig index d56b4b5bc1..f3ee1f6e90 100644 --- a/board/emulation/qemu-riscv/Kconfig +++ b/board/emulation/qemu-riscv/Kconfig @@ -82,5 +82,7 @@ config BOARD_SPECIFIC_OPTIONS # dummy imply USB_XHCI_PCI imply USB_KEYBOARD imply CMD_USB + imply UFS + imply UFS_PCI endif diff --git a/doc/board/emulation/qemu-riscv.rst b/doc/board/emulation/qemu-riscv.rst index 61137bcbf1..8a5eb1eda5 100644 --- a/doc/board/emulation/qemu-riscv.rst +++ b/doc/board/emulation/qemu-riscv.rst @@ -131,7 +131,13 @@ An attached disk can be emulated in RISC-V virt machine by adding:: -drive if=none,file=riscv64.img,format=raw,id=mydisk \ -device ide-hd,drive=mydisk,bus=ahci.0 -You will have to run 'scsi scan' to use it. +or alternatively attach an emulated UFS:: + +-device ufs,id=ufs0 \ +-drive if=none,file=test.img,format=raw,id=lun0 \ +-device ufs-lu,drive=lun0,bus=ufs0 + +You will have to run 'scsi scan' to use them. A video console can be emulated in RISC-V virt machine by removing "-nographic" and adding:: -- 2.34.1
[PATCH 8/9] ufs: Handle UFS 3.1 controllers
Extend the version check to handle UFS 3.1 controllers as well.
Tested on QEMU emulated UFS 3.1 controller.
Signed-off-by: Bin Meng
---
drivers/ufs/ufs.c | 3 ++-
drivers/ufs/ufs.h | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/ufs/ufs.c b/drivers/ufs/ufs.c
index fb2a607ef1..6287ce91a3 100644
--- a/drivers/ufs/ufs.c
+++ b/drivers/ufs/ufs.c
@@ -1953,7 +1953,8 @@ int ufshcd_probe(struct udevice *ufs_dev, struct
ufs_hba_ops *hba_ops)
hba->version != UFSHCI_VERSION_11 &&
hba->version != UFSHCI_VERSION_20 &&
hba->version != UFSHCI_VERSION_21 &&
- hba->version != UFSHCI_VERSION_30)
+ hba->version != UFSHCI_VERSION_30 &&
+ hba->version != UFSHCI_VERSION_31)
dev_err(hba->dev, "invalid UFS version 0x%x\n",
hba->version);
diff --git a/drivers/ufs/ufs.h b/drivers/ufs/ufs.h
index 9daaf03d22..816a5ce0ca 100644
--- a/drivers/ufs/ufs.h
+++ b/drivers/ufs/ufs.h
@@ -782,6 +782,7 @@ enum {
UFSHCI_VERSION_20 = 0x0200, /* 2.0 */
UFSHCI_VERSION_21 = 0x0210, /* 2.1 */
UFSHCI_VERSION_30 = 0x0300, /* 3.0 */
+ UFSHCI_VERSION_31 = 0x0310, /* 3.1 */
};
/* Interrupt disable masks */
--
2.34.1
[PATCH 7/9] ufs: Add a PCI based UFS controller driver
This adds a simple PCI based UFS controller driver with a QEMU
emulated UFS controller on the PCI bus.
Requiring QEMU v8.2+.
Signed-off-by: Bin Meng
---
drivers/ufs/Kconfig | 11 +++
drivers/ufs/Makefile | 1 +
drivers/ufs/ufs-pci.c | 45 +++
3 files changed, 57 insertions(+)
create mode 100644 drivers/ufs/ufs-pci.c
diff --git a/drivers/ufs/Kconfig b/drivers/ufs/Kconfig
index 0e0cc58e3d..42797ce052 100644
--- a/drivers/ufs/Kconfig
+++ b/drivers/ufs/Kconfig
@@ -15,6 +15,17 @@ config CADENCE_UFS
This selects the platform driver for the Cadence UFS host
controller present on present TI's J721e devices.
+config UFS_PCI
+ bool "PCI bus based UFS Controller support"
+ depends on PCI && UFS
+ help
+ This selects the PCI UFS Host Controller Interface. Select this if
+ you have UFS Host Controller with PCI Interface.
+
+ If you have a controller with this interface, say Y here.
+
+ If unsure, say N.
+
config TI_J721E_UFS
bool "Glue Layer driver for UFS on TI J721E devices"
help
diff --git a/drivers/ufs/Makefile b/drivers/ufs/Makefile
index 4f3344fd4e..13f1e689ef 100644
--- a/drivers/ufs/Makefile
+++ b/drivers/ufs/Makefile
@@ -6,4 +6,5 @@
obj-$(CONFIG_UFS) += ufs.o ufs-uclass.o
obj-$(CONFIG_CADENCE_UFS) += cdns-platform.o
obj-$(CONFIG_TI_J721E_UFS) += ti-j721e-ufs.o
+obj-$(CONFIG_UFS_PCI) += ufs-pci.o
obj-$(CONFIG_UFS_RENESAS) += ufs-renesas.o
diff --git a/drivers/ufs/ufs-pci.c b/drivers/ufs/ufs-pci.c
new file mode 100644
index 00..bf697106a0
--- /dev/null
+++ b/drivers/ufs/ufs-pci.c
@@ -0,0 +1,45 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2023 tinylab.org
+ * Author: Bin Meng
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include "ufs.h"
+
+static int ufs_pci_bind(struct udevice *dev)
+{
+ struct udevice *scsi_dev;
+
+ return ufs_scsi_bind(dev, _dev);
+}
+
+static int ufs_pci_probe(struct udevice *dev)
+{
+ int err;
+
+ err = ufshcd_probe(dev, NULL);
+ if (err)
+ dev_err(dev, "%s failed (ret=%d)\n", err);
+
+ return err;
+}
+
+U_BOOT_DRIVER(ufs_pci) = {
+ .name = "ufs_pci",
+ .id = UCLASS_UFS,
+ .bind = ufs_pci_bind,
+ .probe = ufs_pci_probe,
+};
+
+static struct pci_device_id ufs_supported[] = {
+ { PCI_DEVICE(PCI_VENDOR_ID_REDHAT, PCI_DEVICE_ID_REDHAT_UFS) },
+ {},
+};
+
+U_BOOT_PCI_DEVICE(ufs_pci, ufs_supported);
--
2.34.1
[PATCH 5/9] pci_ids: Add Red Hat vendor and device IDs
Red Hat, Inc. donates a part of its device ID range [1] to QEMU, to be used for virtual devices. This commit adds several typical devices that are useful in U-Boot. [1] https://www.qemu.org/docs/master/specs/pci-ids.html Signed-off-by: Bin Meng --- include/pci_ids.h | 7 +++ 1 file changed, 7 insertions(+) diff --git a/include/pci_ids.h b/include/pci_ids.h index 88b0a64045..b63bf45168 100644 --- a/include/pci_ids.h +++ b/include/pci_ids.h @@ -1363,6 +1363,13 @@ #define PCI_DEVICE_ID_XILINX_HAMMERFALL_DSP 0x3fc5 #define PCI_DEVICE_ID_XILINX_HAMMERFALL_DSP_MADI 0x3fc6 +/* Per https://www.qemu.org/docs/master/specs/pci-ids.html */ +#define PCI_VENDOR_ID_REDHAT0x1b36 +#define PCI_DEVICE_ID_REDHAT_SDHCI 0x0007 +#define PCI_DEVICE_ID_REDHAT_XHCI 0x000d +#define PCI_DEVICE_ID_REDHAT_NVME 0x0010 +#define PCI_DEVICE_ID_REDHAT_UFS0x0013 + #define PCI_VENDOR_ID_INIT 0x1101 #define PCI_VENDOR_ID_CREATIVE 0x1102 /* duplicate: ECTIVA */ -- 2.34.1
[PATCH 6/9] ufs: Allow mmio registers on the PCI bus
Check if the UFS controller is on the PCI bus, and get its register
base address accordingly.
Signed-off-by: Bin Meng
---
drivers/ufs/ufs.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/ufs/ufs.c b/drivers/ufs/ufs.c
index 96801866d3..fb2a607ef1 100644
--- a/drivers/ufs/ufs.c
+++ b/drivers/ufs/ufs.c
@@ -1914,6 +1914,7 @@ int ufshcd_probe(struct udevice *ufs_dev, struct
ufs_hba_ops *hba_ops)
struct ufs_hba *hba = dev_get_uclass_priv(ufs_dev);
struct scsi_plat *scsi_plat;
struct udevice *scsi_dev;
+ void __iomem *mmio_base;
int err;
device_find_first_child(ufs_dev, _dev);
@@ -1927,7 +1928,14 @@ int ufshcd_probe(struct udevice *ufs_dev, struct
ufs_hba_ops *hba_ops)
hba->dev = ufs_dev;
hba->ops = hba_ops;
- hba->mmio_base = dev_read_addr_ptr(ufs_dev);
+
+ if (device_is_on_pci_bus(ufs_dev)) {
+ mmio_base = dm_pci_map_bar(ufs_dev, PCI_BASE_ADDRESS_0, 0, 0,
+ PCI_REGION_TYPE, PCI_REGION_MEM);
+ } else {
+ mmio_base = dev_read_addr_ptr(ufs_dev);
+ }
+ hba->mmio_base = mmio_base;
/* Set descriptor lengths to specification defaults */
ufshcd_def_desc_sizes(hba);
--
2.34.1
[PATCH 4/9] cmd: ufs: Correct the help text
Remove the additional space and use "sub-system" for consistency with other commands like "scsi" and "usb". Signed-off-by: Bin Meng --- cmd/ufs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cmd/ufs.c b/cmd/ufs.c index 143e946370..2c8d88df18 100644 --- a/cmd/ufs.c +++ b/cmd/ufs.c @@ -32,6 +32,6 @@ static int do_ufs(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]) } U_BOOT_CMD(ufs, 3, 1, do_ufs, - "UFS sub system", + "UFS sub-system", "init [dev] - init UFS subsystem\n" ); -- 2.34.1
[PATCH 1/9] ufs: Correct the UFS terminlogy
UFS stands for Universal Flash Storage, not Subsytem. Signed-off-by: Bin Meng --- cmd/Kconfig | 2 +- drivers/ufs/ufs-uclass.c | 2 +- drivers/ufs/ufs.c| 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/cmd/Kconfig b/cmd/Kconfig index 6470b138d2..a59c67e333 100644 --- a/cmd/Kconfig +++ b/cmd/Kconfig @@ -1536,7 +1536,7 @@ config CMD_TSI148 Turndra tsi148 device. See the command help for full details. config CMD_UFS - bool "Enable UFS - Universal Flash Subsystem commands" + bool "Enable UFS - Universal Flash Storage commands" depends on UFS help "This provides commands to initialise and configure universal flash diff --git a/drivers/ufs/ufs-uclass.c b/drivers/ufs/ufs-uclass.c index ceea30c4a9..ffae811d46 100644 --- a/drivers/ufs/ufs-uclass.c +++ b/drivers/ufs/ufs-uclass.c @@ -1,6 +1,6 @@ // SPDX-License-Identifier: GPL-2.0 /** - * ufs-uclass.c - Universal Flash Subsystem (UFS) Uclass driver + * ufs-uclass.c - Universal Flash Storage (UFS) Uclass driver * * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com */ diff --git a/drivers/ufs/ufs.c b/drivers/ufs/ufs.c index 7c48d57f99..f534d6e29f 100644 --- a/drivers/ufs/ufs.c +++ b/drivers/ufs/ufs.c @@ -1,6 +1,6 @@ // SPDX-License-Identifier: GPL-2.0+ /** - * ufs.c - Universal Flash Subsystem (UFS) driver + * ufs.c - Universal Flash Storage (UFS) driver * * Taken from Linux Kernel v5.2 (drivers/scsi/ufs/ufshcd.c) and ported * to u-boot. -- 2.34.1
[PATCH 0/9] ufs: Add a PCI UFS controller support
This adds a PCI UFS controller support and enables the support on QEMU RISC-V for testing. Requiring QEMU v8.2+. This series is avaiable at u-boot-x86/ufs for testing. Bin Meng (9): ufs: Correct the UFS terminlogy ufs: Add a line feed to the end of some dev_xxx() messages cmd: kconfig: Make ufs prompt look similar to other commands cmd: ufs: Correct the help text pci_ids: Add Red Hat vendor and device IDs ufs: Allow mmio registers on the PCI bus ufs: Add a PCI based UFS controller driver ufs: Handle UFS 3.1 controllers qemu: riscv: Enable UFS support board/emulation/qemu-riscv/Kconfig | 2 ++ cmd/Kconfig| 2 +- cmd/ufs.c | 2 +- doc/board/emulation/qemu-riscv.rst | 8 +- drivers/ufs/Kconfig| 11 drivers/ufs/Makefile | 1 + drivers/ufs/ufs-pci.c | 45 ++ drivers/ufs/ufs-uclass.c | 2 +- drivers/ufs/ufs.c | 31 drivers/ufs/ufs.h | 1 + include/pci_ids.h | 7 + 11 files changed, 97 insertions(+), 15 deletions(-) create mode 100644 drivers/ufs/ufs-pci.c -- 2.34.1
[PATCH 3/9] cmd: kconfig: Make ufs prompt look similar to other commands
At present the 'ufs' command prompt does not look similar like other commands. Update it. Signed-off-by: Bin Meng --- cmd/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cmd/Kconfig b/cmd/Kconfig index a59c67e333..0b4e76c262 100644 --- a/cmd/Kconfig +++ b/cmd/Kconfig @@ -1536,7 +1536,7 @@ config CMD_TSI148 Turndra tsi148 device. See the command help for full details. config CMD_UFS - bool "Enable UFS - Universal Flash Storage commands" + bool "ufs - Universal Flash Storage commands" depends on UFS help "This provides commands to initialise and configure universal flash -- 2.34.1
[PATCH 2/9] ufs: Add a line feed to the end of some dev_xxx() messages
Add a line feed to improve readability of some dev_xxx() messages.
Signed-off-by: Bin Meng
---
drivers/ufs/ufs.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/ufs/ufs.c b/drivers/ufs/ufs.c
index f534d6e29f..96801866d3 100644
--- a/drivers/ufs/ufs.c
+++ b/drivers/ufs/ufs.c
@@ -320,7 +320,7 @@ static int ufshcd_disable_tx_lcc(struct ufs_hba *hba, bool
peer)
UIC_ARG_MPHY_TX_GEN_SEL_INDEX(i)),
0);
if (err) {
- dev_err(hba->dev, "%s: TX LCC Disable failed, peer =
%d, lane = %d, err = %d",
+ dev_err(hba->dev, "%s: TX LCC Disable failed, peer =
%d, lane = %d, err = %d\n",
__func__, peer, i, err);
break;
}
@@ -441,7 +441,7 @@ static int ufshcd_make_hba_operational(struct ufs_hba *hba)
ufshcd_enable_run_stop_reg(hba);
} else {
dev_err(hba->dev,
- "Host controller not ready to process requests");
+ "Host controller not ready to process requests\n");
err = -EIO;
goto out;
}
@@ -930,7 +930,7 @@ static int ufshcd_copy_query_response(struct ufs_hba *hba)
memcpy(hba->dev_cmd.query.descriptor, descp, resp_len);
} else {
dev_warn(hba->dev,
-"%s: Response size is bigger than buffer",
+"%s: Response size is bigger than buffer\n",
__func__);
return -EINVAL;
}
@@ -1179,11 +1179,11 @@ static int ufshcd_read_desc_length(struct ufs_hba *hba,
enum desc_idn desc_id,
_len);
if (ret) {
- dev_err(hba->dev, "%s: Failed to get descriptor header id %d",
+ dev_err(hba->dev, "%s: Failed to get descriptor header id %d\n",
__func__, desc_id);
return ret;
} else if (desc_id != header[QUERY_DESC_DESC_TYPE_OFFSET]) {
- dev_warn(hba->dev, "%s: descriptor header id %d and desc_id %d
mismatch",
+ dev_warn(hba->dev, "%s: descriptor header id %d and desc_id %d
mismatch\n",
__func__, header[QUERY_DESC_DESC_TYPE_OFFSET],
desc_id);
ret = -EINVAL;
@@ -1302,7 +1302,7 @@ int ufshcd_read_desc_param(struct ufs_hba *hba, enum
desc_idn desc_id,
/* Sanity checks */
if (ret || !buff_len) {
- dev_err(hba->dev, "%s: Failed to get full descriptor length",
+ dev_err(hba->dev, "%s: Failed to get full descriptor length\n",
__func__);
return ret;
}
@@ -1323,14 +1323,14 @@ int ufshcd_read_desc_param(struct ufs_hba *hba, enum
desc_idn desc_id,
_len);
if (ret) {
- dev_err(hba->dev, "%s: Failed reading descriptor. desc_id %d,
desc_index %d, param_offset %d, ret %d",
+ dev_err(hba->dev, "%s: Failed reading descriptor. desc_id %d,
desc_index %d, param_offset %d, ret %d\n",
__func__, desc_id, desc_index, param_offset, ret);
goto out;
}
/* Sanity check */
if (desc_buf[QUERY_DESC_DESC_TYPE_OFFSET] != desc_id) {
- dev_err(hba->dev, "%s: invalid desc_id %d in descriptor header",
+ dev_err(hba->dev, "%s: invalid desc_id %d in descriptor
header\n",
__func__, desc_buf[QUERY_DESC_DESC_TYPE_OFFSET]);
ret = -EINVAL;
goto out;
--
2.34.1
[PATCH] mmc: pci: Drop the superfluous cast
dm_pci_map_bar() return a value of (void *) already, hence no need to cast it again before assigning to host->ioaddr. Signed-off-by: Bin Meng --- drivers/mmc/pci_mmc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/mmc/pci_mmc.c b/drivers/mmc/pci_mmc.c index 9fb7044029..4d163ccba0 100644 --- a/drivers/mmc/pci_mmc.c +++ b/drivers/mmc/pci_mmc.c @@ -50,8 +50,8 @@ static int pci_mmc_probe(struct udevice *dev) desc = mmc_get_blk_desc(>mmc); desc->removable = !(plat->cfg.host_caps & MMC_CAP_NONREMOVABLE); - host->ioaddr = (void *)dm_pci_map_bar(dev, PCI_BASE_ADDRESS_0, 0, 0, PCI_REGION_TYPE, - PCI_REGION_MEM); + host->ioaddr = dm_pci_map_bar(dev, PCI_BASE_ADDRESS_0, 0, 0, + PCI_REGION_TYPE, PCI_REGION_MEM); host->name = dev->name; host->cd_gpio = priv->cd_gpio; host->mmc = >mmc; -- 2.34.1
[PATCH] net: e1000: Drop e1000_eth_ids[]
e1000_eth_ids holds compatible strings for e1000 devices, but it
is meaningless as e1000 is a PCI device and there is no such
compatible string assigned to e1000 by the DT bindings community.
Drop it.
Signed-off-by: Bin Meng
---
drivers/net/e1000.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/net/e1000.c b/drivers/net/e1000.c
index 41e6ba760e..84a2a7cf90 100644
--- a/drivers/net/e1000.c
+++ b/drivers/net/e1000.c
@@ -5718,15 +5718,9 @@ static const struct eth_ops e1000_eth_ops = {
.write_hwaddr = e1000_write_hwaddr,
};
-static const struct udevice_id e1000_eth_ids[] = {
- { .compatible = "intel,e1000" },
- { }
-};
-
U_BOOT_DRIVER(eth_e1000) = {
.name = "eth_e1000",
.id = UCLASS_ETH,
- .of_match = e1000_eth_ids,
.bind = e1000_eth_bind,
.probe = e1000_eth_probe,
.ops= _eth_ops,
--
2.34.1
Re: [PATCH 10/15] cmd: blk_common: Use macros for the return values
Hi Simon,
On Mon, Oct 2, 2023 at 9:42 AM Simon Glass wrote:
>
> Hi Bin,
>
> On Tue, 26 Sept 2023 at 02:54, Bin Meng wrote:
> >
> > Avoid using magic number 0/1 for the command result.
> >
> > Signed-off-by: Bin Meng
> > ---
> >
> > cmd/blk_common.c | 14 +++---
> > 1 file changed, 7 insertions(+), 7 deletions(-)
> >
> > diff --git a/cmd/blk_common.c b/cmd/blk_common.c
> > index 9f9d4327a9..ad9b16dc09 100644
> > --- a/cmd/blk_common.c
> > +++ b/cmd/blk_common.c
> > @@ -25,18 +25,18 @@ int blk_common_cmd(int argc, char *const argv[], enum
> > uclass_id uclass_id,
> > case 2:
> > if (strncmp(argv[1], "inf", 3) == 0) {
> > blk_list_devices(uclass_id);
> > - return 0;
> > + return CMD_RET_SUCCESS;
>
> I really don't like this...0 is success.
>
> > } else if (strncmp(argv[1], "dev", 3) == 0) {
> > if (blk_print_device_num(uclass_id, *cur_devnump)) {
> > printf("\nno %s devices available\n",
> > if_name);
> > return CMD_RET_FAILURE;
> > }
> > - return 0;
> > + return CMD_RET_SUCCESS;
> > } else if (strncmp(argv[1], "part", 4) == 0) {
> > if (blk_list_part(uclass_id))
> > printf("\nno %s partition table
> > available\n",
> >if_name);
> > - return 0;
> > + return CMD_RET_SUCCESS;
> > }
> > return CMD_RET_USAGE;
> > case 3:
> > @@ -49,7 +49,7 @@ int blk_common_cmd(int argc, char *const argv[], enum
> > uclass_id uclass_id,
> > } else {
> > return CMD_RET_FAILURE;
> > }
> > - return 0;
> > + return CMD_RET_SUCCESS;
> > } else if (strncmp(argv[1], "part", 4) == 0) {
> > int dev = (int)dectoul(argv[2], NULL);
> >
> > @@ -58,7 +58,7 @@ int blk_common_cmd(int argc, char *const argv[], enum
> > uclass_id uclass_id,
> >if_name, dev);
> > return CMD_RET_FAILURE;
> > }
> > - return 0;
> > + return CMD_RET_SUCCESS;
> > }
> > return CMD_RET_USAGE;
> >
> > @@ -80,7 +80,7 @@ int blk_common_cmd(int argc, char *const argv[], enum
> > uclass_id uclass_id,
> >
> > printf("%ld blocks read: %s\n", n,
> >n == cnt ? "OK" : "ERROR");
> > - return n == cnt ? 0 : 1;
> > + return n == cnt ? CMD_RET_SUCCESS : CMD_RET_FAILURE;
>
> CMD_RET_FAILURE is OK, but I would prefer not to use CMD_RET_SUCCESS.
> It is 0 and always will be.
>
> It encourages people to do things like:
>
> if (ret == CMD_RET_SUCCESS)
>
> instead of
>
> if (!ret)
I see your concern. However we don't change the return value type to
enum, so people can still use
if (!ret)
I would still defend that we should use CMD_RET_SUCCESS.
This is like EXIT_XXX defined in stdlib.h:
#define EXIT_FAILURE 1/* Failing exit status. */
#define EXIT_SUCCESS 0/* Successful exit status. */
One should use predefined macros whenever possible.
>
> It would eventually creep into everything, including our clean error handling.
>
> > } else if (strcmp(argv[1], "write") == 0) {
> > phys_addr_t paddr = hextoul(argv[2], NULL);
> > lbaint_t blk = hextoul(argv[3], NULL);
> > @@ -98,7 +98,7 @@ int blk_common_cmd(int argc, char *const argv[], enum
> > uclass_id uclass_id,
> >
> > printf("%ld blocks written: %s\n", n,
> >n == cnt ? "OK" : "ERROR");
> > - return n == cnt ? 0 : 1;
> > + return n == cnt ? CMD_RET_SUCCESS : CMD_RET_FAILURE;
> > } else {
> > return CMD_RET_USAGE;
> > }
> > --
Regards,
Bin
Re: SSE instructions
Hi Simon,
On Thu, Sep 28, 2023 at 10:20 PM Simon Glass wrote:
>
> Hi Bin,
>
> On Thu, 28 Sept 2023 at 08:15, Bin Meng wrote:
> >
> > Hi Simon,
> >
> > On Thu, Sep 28, 2023 at 10:41 AM Simon Glass wrote:
> > >
> > > Hi Bin,
> > >
> > > U-Boot 64-bit on x86 disables sse, but when enabling Truetype I get a
> > > compiler error:
> > >
> > > drivers/video/console_truetype.c: In function 'frac':
> > > drivers/video/console_truetype.c:30:15: error: SSE register return
> > > with SSE disabled
> > > 30 | static double frac(double val)
> > >
> > > Do you know how to enable SSE for 64-bit?
> > >
> >
> > The following patch could enable SSE for 64-bit:
> >
> > diff --git a/arch/x86/config.mk b/arch/x86/config.mk
> > index 26ec1af2f0..250d7c9948 100644
> > --- a/arch/x86/config.mk
> > +++ b/arch/x86/config.mk
> > @@ -27,7 +27,7 @@ ifeq ($(IS_32BIT),y)
> > PLATFORM_CPPFLAGS += -march=i386 -m32
> > else
> > PLATFORM_CPPFLAGS += $(if $(CONFIG_SPL_BUILD),,-fpic) -fno-common
> > -march=core2 -m64
> > -PLATFORM_CPPFLAGS += -mno-mmx -mno-sse
> > +PLATFORM_CPPFLAGS += -mno-mmx
> > endif
> >
> > However as Heinrich mentioned, U-Boot codes should be written in a
> > "floating point free" way.
> >
> > The fix should really be updating console_truetype.c to use integers
> > instead of using float/double.
>
> Yes, I can do that, but it hangs going into 64-bit mode, which is
> presumably why the flag was added. In fact it was your commit!
Yeah, indeed it was commit dd4611dea435 ("x86: Ensure no instruction
sets of MMX/SSE are generated in 64-bit build") and the commit message
said the reason.
>
> Is there some missing init somewhere?
>
I believe we should turn on X86_CR4_OSFXSR | X86_CR4_OSXMMEXCPT on CR4
to enable SSE.
Regards,
Bin
Re: SSE instructions
Hi Simon, On Thu, Sep 28, 2023 at 10:41 AM Simon Glass wrote: > > Hi Bin, > > U-Boot 64-bit on x86 disables sse, but when enabling Truetype I get a > compiler error: > > drivers/video/console_truetype.c: In function 'frac': > drivers/video/console_truetype.c:30:15: error: SSE register return > with SSE disabled > 30 | static double frac(double val) > > Do you know how to enable SSE for 64-bit? > The following patch could enable SSE for 64-bit: diff --git a/arch/x86/config.mk b/arch/x86/config.mk index 26ec1af2f0..250d7c9948 100644 --- a/arch/x86/config.mk +++ b/arch/x86/config.mk @@ -27,7 +27,7 @@ ifeq ($(IS_32BIT),y) PLATFORM_CPPFLAGS += -march=i386 -m32 else PLATFORM_CPPFLAGS += $(if $(CONFIG_SPL_BUILD),,-fpic) -fno-common -march=core2 -m64 -PLATFORM_CPPFLAGS += -mno-mmx -mno-sse +PLATFORM_CPPFLAGS += -mno-mmx endif However as Heinrich mentioned, U-Boot codes should be written in a "floating point free" way. The fix should really be updating console_truetype.c to use integers instead of using float/double. Regards, Bin
Re: [PATCH 09/15] blk: blkmap: Support mapping to device of any block size
Hi Tobias,
On Wed, Sep 27, 2023 at 3:29 AM Tobias Waldekranz wrote:
>
> On tis, sep 26, 2023 at 16:43, Bin Meng wrote:
> > At present if a device to map has a block size other than 512,
> > the blkmap map process just fails. There is no reason why we
> > can't just use the block size of the mapped device.
>
> Won't this be very confusing to the user?
I don't see any confusion.
>
> The blkmap device uses a fixed block size of 512:
>
> https://source.denx.de/u-boot/u-boot/-/blob/master/drivers/block/blkmap.c?ref_type=heads#L393
Yes, the blkmap device was originally created with a fixed block size
of 512, and that's fine.
>
> So if I map a slice of a 4k device into a blkmap, then
>
> blkmap read 0x8000 0 1
>
> would copy 4k instead of 512 bytes from the lower device to 0x8000,
> even though the blkmap reports a block size of 512.
>
> It seems to me that the expected behavior would be that only the first
> 512 bytes would be copied in the command above.
No, the blkmap block size was later updated to match the real
underlying device parameter during the map process. So it will copy
all 4k to 0x8000.
>
> >
> > Signed-off-by: Bin Meng
> > ---
> >
> > drivers/block/blkmap.c | 10 +-
> > 1 file changed, 5 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/block/blkmap.c b/drivers/block/blkmap.c
> > index f6acfa8927..149a4cac3e 100644
> > --- a/drivers/block/blkmap.c
> > +++ b/drivers/block/blkmap.c
> > @@ -171,11 +171,11 @@ int blkmap_map_linear(struct udevice *dev, lbaint_t
> > blknr, lbaint_t blkcnt,
> >
> > bd = dev_get_uclass_plat(bm->blk);
> > lbd = dev_get_uclass_plat(lblk);
> > - if (lbd->blksz != bd->blksz)
> > - /* We could support block size translation, but we
> > - * don't yet.
> > - */
>
> Hence this comment ^
This comment was completely removed with the new updates. There is no
need to do any block size translation. We could just use whatever
block size the lower device is using, hence this patch.
>
> > - return -EINVAL;
> > + if (lbd->blksz != bd->blksz) {
> > + /* update to match the mapped device */
> > + bd->blksz = lbd->blksz;
> > + bd->log2blksz = LOG2(bd->blksz);
> > + }
> >
> > linear = malloc(sizeof(*linear));
> > if (!linear)
> > --
Regards,
Bin
Re: [PATCH 00/15] blk: sandbox: Support binding a device with a given logical block size
Hi Heinrich, On Tue, Sep 26, 2023 at 4:58 PM Heinrich Schuchardt wrote: > > On 9/26/23 10:43, Bin Meng wrote: > > At present on Sandbox when binding to a host backing file, the host > > block device is created with a hard-coded 512 bytes block size. > > > > Such assumption works for most cases, but for situation that with a raw > > image file dump from a pre-formatted GPT partitioned disk image from a > > 4KiB block size device, when binding this file to a host device and mapping > > this device to a blkmap, "blkmap" command like "blkmap part" won't work > > correctly, due to block size mismatch during parsing the partition table. > > > > This series updates Sandbox block driver, as well as the blkmap driver, > > to get rid of the hard-coded 512 bytes block size assumption. > > > > This series is available at u-boot-x86/blk for testing. > > It is really good to have an easy way to test other block sizes. > > We can also use QEMU for alternative block sizes: > > $ qemu-system-riscv64 -device nvme,help > logical_block_size= > physical_block_size= Yeah, please report any issue you find. > > In the commit messages, please, make it clear that you refer to logical > block sizes and not to the physical block size. For drivers we rarely care about physical_block_size as they always operate on LBA. But I can write it down clearly that logical block size is used. Regards, Bin
[PATCH 15/15] disk: part: Handle blkmap device in print_part_header()
Print out the blkmap device type when showing partition header for
a blkmap device.
Signed-off-by: Bin Meng
---
disk/part.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/disk/part.c b/disk/part.c
index 493e04943b..6997a89775 100644
--- a/disk/part.c
+++ b/disk/part.c
@@ -309,6 +309,9 @@ static void print_part_header(const char *type, struct
blk_desc *dev_desc)
case UCLASS_EFI_MEDIA:
puts("EFI");
break;
+ case UCLASS_BLKMAP:
+ puts("BLKMAP");
+ break;
default:
printf("UNKNOWN(%d)", dev_desc->uclass_id);
break;
--
2.25.1
[PATCH 14/15] disk: part: Print out the unknown device uclass id
It's helpful to output the device uclass id for unknown devices
during the debugging process.
Signed-off-by: Bin Meng
---
disk/part.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/disk/part.c b/disk/part.c
index eec02f5898..493e04943b 100644
--- a/disk/part.c
+++ b/disk/part.c
@@ -310,7 +310,7 @@ static void print_part_header(const char *type, struct
blk_desc *dev_desc)
puts("EFI");
break;
default:
- puts("UNKNOWN");
+ printf("UNKNOWN(%d)", dev_desc->uclass_id);
break;
}
printf (" device %d -- Partition Type: %s\n\n",
--
2.25.1
[PATCH 13/15] dm: blk: Drop blk_{read,write}_devnum()
blk_{read,write}_devnum() are no longer used by anywhere in the
source tree. Drop them.
Signed-off-by: Bin Meng
---
drivers/block/blk-uclass.c | 29 -
include/blk.h | 26 --
2 files changed, 55 deletions(-)
diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-uclass.c
index 9407621fb2..a4c6cf194c 100644
--- a/drivers/block/blk-uclass.c
+++ b/drivers/block/blk-uclass.c
@@ -315,35 +315,6 @@ int blk_show_device(enum uclass_id uclass_id, int devnum)
return 0;
}
-ulong blk_read_devnum(enum uclass_id uclass_id, int devnum, lbaint_t start,
- lbaint_t blkcnt, void *buffer)
-{
- struct blk_desc *desc;
- ulong n;
- int ret;
-
- ret = blk_get_desc(uclass_id, devnum, );
- if (ret)
- return ret;
- n = blk_dread(desc, start, blkcnt, buffer);
- if (IS_ERR_VALUE(n))
- return n;
-
- return n;
-}
-
-ulong blk_write_devnum(enum uclass_id uclass_id, int devnum, lbaint_t start,
- lbaint_t blkcnt, const void *buffer)
-{
- struct blk_desc *desc;
- int ret;
-
- ret = blk_get_desc(uclass_id, devnum, );
- if (ret)
- return ret;
- return blk_dwrite(desc, start, blkcnt, buffer);
-}
-
int blk_select_hwpart(struct udevice *dev, int hwpart)
{
const struct blk_ops *ops = blk_get_ops(dev);
diff --git a/include/blk.h b/include/blk.h
index 0cd758d6f7..e1477df3b6 100644
--- a/include/blk.h
+++ b/include/blk.h
@@ -718,32 +718,6 @@ int blk_print_device_num(enum uclass_id uclass_id, int
devnum);
*/
int blk_print_part_devnum(enum uclass_id uclass_id, int devnum);
-/**
- * blk_read_devnum() - read blocks from a device
- *
- * @uclass_id: Block device type
- * @devnum:Device number
- * @start: Start block number to read (0=first)
- * @blkcnt:Number of blocks to read
- * @buffer:Address to write data to
- * Return: number of blocks read, or -ve error number on error
- */
-ulong blk_read_devnum(enum uclass_id uclass_id, int devnum, lbaint_t start,
- lbaint_t blkcnt, void *buffer);
-
-/**
- * blk_write_devnum() - write blocks to a device
- *
- * @uclass_id: Block device type
- * @devnum:Device number
- * @start: Start block number to write (0=first)
- * @blkcnt:Number of blocks to write
- * @buffer:Address to read data from
- * Return: number of blocks written, or -ve error number on error
- */
-ulong blk_write_devnum(enum uclass_id uclass_id, int devnum, lbaint_t start,
- lbaint_t blkcnt, const void *buffer);
-
/**
* blk_select_hwpart_devnum() - select a hardware partition
*
--
2.25.1
[PATCH 12/15] cmd: blk_common: Stop using hard-coded block size for Sandbox operations
commit 3d2fc7971454 ("cmd: blk: Allow generic read/write operations to work in
sandbox")
used the hard-coded block size (512) for accessing the sandbox host
device. Now that we have added support for non-512 block size for both
Sandbox host device and blkmap driver, let's stop using the hard-coded
block size.
Signed-off-by: Bin Meng
---
cmd/blk_common.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/cmd/blk_common.c b/cmd/blk_common.c
index ad9b16dc09..02ac92837b 100644
--- a/cmd/blk_common.c
+++ b/cmd/blk_common.c
@@ -67,15 +67,19 @@ int blk_common_cmd(int argc, char *const argv[], enum
uclass_id uclass_id,
phys_addr_t paddr = hextoul(argv[2], NULL);
lbaint_t blk = hextoul(argv[3], NULL);
ulong cnt = hextoul(argv[4], NULL);
+ struct blk_desc *desc;
void *vaddr;
ulong n;
+ int ret;
printf("\n%s read: device %d block # "LBAFU", count %lu
... ",
if_name, *cur_devnump, blk, cnt);
- vaddr = map_sysmem(paddr, 512 * cnt);
- n = blk_read_devnum(uclass_id, *cur_devnump, blk, cnt,
- vaddr);
+ ret = blk_get_desc(uclass_id, *cur_devnump, );
+ if (ret)
+ return CMD_RET_FAILURE;
+ vaddr = map_sysmem(paddr, desc->blksz * cnt);
+ n = blk_dread(desc, blk, cnt, vaddr);
unmap_sysmem(vaddr);
printf("%ld blocks read: %s\n", n,
@@ -85,15 +89,19 @@ int blk_common_cmd(int argc, char *const argv[], enum
uclass_id uclass_id,
phys_addr_t paddr = hextoul(argv[2], NULL);
lbaint_t blk = hextoul(argv[3], NULL);
ulong cnt = hextoul(argv[4], NULL);
+ struct blk_desc *desc;
void *vaddr;
ulong n;
+ int ret;
printf("\n%s write: device %d block # "LBAFU", count
%lu ... ",
if_name, *cur_devnump, blk, cnt);
- vaddr = map_sysmem(paddr, 512 * cnt);
- n = blk_write_devnum(uclass_id, *cur_devnump, blk, cnt,
-vaddr);
+ ret = blk_get_desc(uclass_id, *cur_devnump, );
+ if (ret)
+ return CMD_RET_FAILURE;
+ vaddr = map_sysmem(paddr, desc->blksz * cnt);
+ n = blk_dwrite(desc, blk, cnt, vaddr);
unmap_sysmem(vaddr);
printf("%ld blocks written: %s\n", n,
--
2.25.1
[PATCH 11/15] dm: blk: Rename get_desc() and make it externally visible
get_desc() can be useful outside blk-uclass.c. Let's change it to
an API and make it externally visible.
Signed-off-by: Bin Meng
---
drivers/block/blk-uclass.c | 26 --
include/blk.h | 12
2 files changed, 20 insertions(+), 18 deletions(-)
diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-uclass.c
index 614b975e25..9407621fb2 100644
--- a/drivers/block/blk-uclass.c
+++ b/drivers/block/blk-uclass.c
@@ -176,17 +176,7 @@ struct blk_desc *blk_get_by_device(struct udevice *dev)
return NULL;
}
-/**
- * get_desc() - Get the block device descriptor for the given device number
- *
- * @uclass_id: Interface type
- * @devnum:Device number (0 = first)
- * @descp: Returns block device descriptor on success
- * Return: 0 on success, -ENODEV if there is no such device and no device
- * with a higher device number, -ENOENT if there is no such device but there
- * is one with a higher number, or other -ve on other error.
- */
-static int get_desc(enum uclass_id uclass_id, int devnum, struct blk_desc
**descp)
+int blk_get_desc(enum uclass_id uclass_id, int devnum, struct blk_desc **descp)
{
bool found_more = false;
struct udevice *dev;
@@ -238,7 +228,7 @@ int blk_list_part(enum uclass_id uclass_id)
int ret;
for (ok = 0, devnum = 0;; ++devnum) {
- ret = get_desc(uclass_id, devnum, );
+ ret = blk_get_desc(uclass_id, devnum, );
if (ret == -ENODEV)
break;
else if (ret)
@@ -261,7 +251,7 @@ int blk_print_part_devnum(enum uclass_id uclass_id, int
devnum)
struct blk_desc *desc;
int ret;
- ret = get_desc(uclass_id, devnum, );
+ ret = blk_get_desc(uclass_id, devnum, );
if (ret)
return ret;
if (desc->type == DEV_TYPE_UNKNOWN)
@@ -278,7 +268,7 @@ void blk_list_devices(enum uclass_id uclass_id)
int i;
for (i = 0;; ++i) {
- ret = get_desc(uclass_id, i, );
+ ret = blk_get_desc(uclass_id, i, );
if (ret == -ENODEV)
break;
else if (ret)
@@ -295,7 +285,7 @@ int blk_print_device_num(enum uclass_id uclass_id, int
devnum)
struct blk_desc *desc;
int ret;
- ret = get_desc(uclass_id, devnum, );
+ ret = blk_get_desc(uclass_id, devnum, );
if (ret)
return ret;
printf("\nIDE device %d: ", devnum);
@@ -310,7 +300,7 @@ int blk_show_device(enum uclass_id uclass_id, int devnum)
int ret;
printf("\nDevice %d: ", devnum);
- ret = get_desc(uclass_id, devnum, );
+ ret = blk_get_desc(uclass_id, devnum, );
if (ret == -ENODEV || ret == -ENOENT) {
printf("unknown device\n");
return -ENODEV;
@@ -332,7 +322,7 @@ ulong blk_read_devnum(enum uclass_id uclass_id, int devnum,
lbaint_t start,
ulong n;
int ret;
- ret = get_desc(uclass_id, devnum, );
+ ret = blk_get_desc(uclass_id, devnum, );
if (ret)
return ret;
n = blk_dread(desc, start, blkcnt, buffer);
@@ -348,7 +338,7 @@ ulong blk_write_devnum(enum uclass_id uclass_id, int
devnum, lbaint_t start,
struct blk_desc *desc;
int ret;
- ret = get_desc(uclass_id, devnum, );
+ ret = blk_get_desc(uclass_id, devnum, );
if (ret)
return ret;
return blk_dwrite(desc, start, blkcnt, buffer);
diff --git a/include/blk.h b/include/blk.h
index 4a4365fbbf..0cd758d6f7 100644
--- a/include/blk.h
+++ b/include/blk.h
@@ -504,6 +504,18 @@ const char *blk_get_devtype(struct udevice *dev);
*/
struct blk_desc *blk_get_by_device(struct udevice *dev);
+/**
+ * blk_get_desc() - Get the block device descriptor for the given device number
+ *
+ * @uclass_id: Interface type
+ * @devnum:Device number (0 = first)
+ * @descp: Returns block device descriptor on success
+ * Return: 0 on success, -ENODEV if there is no such device and no device
+ * with a higher device number, -ENOENT if there is no such device but there
+ * is one with a higher number, or other -ve on other error.
+ */
+int blk_get_desc(enum uclass_id uclass_id, int devnum, struct blk_desc
**descp);
+
#else
#include
/*
--
2.25.1
[PATCH 10/15] cmd: blk_common: Use macros for the return values
Avoid using magic number 0/1 for the command result.
Signed-off-by: Bin Meng
---
cmd/blk_common.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/cmd/blk_common.c b/cmd/blk_common.c
index 9f9d4327a9..ad9b16dc09 100644
--- a/cmd/blk_common.c
+++ b/cmd/blk_common.c
@@ -25,18 +25,18 @@ int blk_common_cmd(int argc, char *const argv[], enum
uclass_id uclass_id,
case 2:
if (strncmp(argv[1], "inf", 3) == 0) {
blk_list_devices(uclass_id);
- return 0;
+ return CMD_RET_SUCCESS;
} else if (strncmp(argv[1], "dev", 3) == 0) {
if (blk_print_device_num(uclass_id, *cur_devnump)) {
printf("\nno %s devices available\n", if_name);
return CMD_RET_FAILURE;
}
- return 0;
+ return CMD_RET_SUCCESS;
} else if (strncmp(argv[1], "part", 4) == 0) {
if (blk_list_part(uclass_id))
printf("\nno %s partition table available\n",
if_name);
- return 0;
+ return CMD_RET_SUCCESS;
}
return CMD_RET_USAGE;
case 3:
@@ -49,7 +49,7 @@ int blk_common_cmd(int argc, char *const argv[], enum
uclass_id uclass_id,
} else {
return CMD_RET_FAILURE;
}
- return 0;
+ return CMD_RET_SUCCESS;
} else if (strncmp(argv[1], "part", 4) == 0) {
int dev = (int)dectoul(argv[2], NULL);
@@ -58,7 +58,7 @@ int blk_common_cmd(int argc, char *const argv[], enum
uclass_id uclass_id,
if_name, dev);
return CMD_RET_FAILURE;
}
- return 0;
+ return CMD_RET_SUCCESS;
}
return CMD_RET_USAGE;
@@ -80,7 +80,7 @@ int blk_common_cmd(int argc, char *const argv[], enum
uclass_id uclass_id,
printf("%ld blocks read: %s\n", n,
n == cnt ? "OK" : "ERROR");
- return n == cnt ? 0 : 1;
+ return n == cnt ? CMD_RET_SUCCESS : CMD_RET_FAILURE;
} else if (strcmp(argv[1], "write") == 0) {
phys_addr_t paddr = hextoul(argv[2], NULL);
lbaint_t blk = hextoul(argv[3], NULL);
@@ -98,7 +98,7 @@ int blk_common_cmd(int argc, char *const argv[], enum
uclass_id uclass_id,
printf("%ld blocks written: %s\n", n,
n == cnt ? "OK" : "ERROR");
- return n == cnt ? 0 : 1;
+ return n == cnt ? CMD_RET_SUCCESS : CMD_RET_FAILURE;
} else {
return CMD_RET_USAGE;
}
--
2.25.1
[PATCH 09/15] blk: blkmap: Support mapping to device of any block size
At present if a device to map has a block size other than 512,
the blkmap map process just fails. There is no reason why we
can't just use the block size of the mapped device.
Signed-off-by: Bin Meng
---
drivers/block/blkmap.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/block/blkmap.c b/drivers/block/blkmap.c
index f6acfa8927..149a4cac3e 100644
--- a/drivers/block/blkmap.c
+++ b/drivers/block/blkmap.c
@@ -171,11 +171,11 @@ int blkmap_map_linear(struct udevice *dev, lbaint_t
blknr, lbaint_t blkcnt,
bd = dev_get_uclass_plat(bm->blk);
lbd = dev_get_uclass_plat(lblk);
- if (lbd->blksz != bd->blksz)
- /* We could support block size translation, but we
-* don't yet.
-*/
- return -EINVAL;
+ if (lbd->blksz != bd->blksz) {
+ /* update to match the mapped device */
+ bd->blksz = lbd->blksz;
+ bd->log2blksz = LOG2(bd->blksz);
+ }
linear = malloc(sizeof(*linear));
if (!linear)
--
2.25.1
[PATCH 06/15] cmd: host: Print out the block size of the host device
It's useful if we can print out the block size of the host device
in the "host info" command.
Signed-off-by: Bin Meng
---
cmd/host.c | 7 ---
test/dm/host.c | 20 ++--
2 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/cmd/host.c b/cmd/host.c
index 2334ccd9bc..c33c2a9787 100644
--- a/cmd/host.c
+++ b/cmd/host.c
@@ -160,8 +160,8 @@ static void show_host_dev(struct udevice *dev)
return;
desc = dev_get_uclass_plat(blk);
- printf("%12lu %-15s %s\n", (unsigned long)desc->lba, plat->label,
- plat->filename);
+ printf("%12lu %6lu %-15s %s\n", (unsigned long)desc->lba, desc->blksz,
+ plat->label, plat->filename);
}
static int do_host_info(struct cmd_tbl *cmdtp, int flag, int argc,
@@ -179,7 +179,8 @@ static int do_host_info(struct cmd_tbl *cmdtp, int flag,
int argc,
return CMD_RET_FAILURE;
}
- printf("%3s %12s %-15s %s\n", "dev", "blocks", "label", "path");
+ printf("%3s %12s %6s %-15s %s\n",
+ "dev", "blocks", "blksz", "label", "path");
if (dev) {
show_host_dev(dev);
} else {
diff --git a/test/dm/host.c b/test/dm/host.c
index 19f6c67462..580b14cf79 100644
--- a/test/dm/host.c
+++ b/test/dm/host.c
@@ -114,7 +114,7 @@ static int dm_test_cmd_host(struct unit_test_state *uts)
/* first check 'host info' with binding */
ut_assertok(run_command("host info", 0));
- ut_assert_nextline("dev blocks label path");
+ ut_assert_nextline("dev blocks blksz label path");
ut_assert_console_end();
ut_assertok(run_commandf("host bind -r test2 %s", filename));
@@ -126,8 +126,8 @@ static int dm_test_cmd_host(struct unit_test_state *uts)
ut_asserteq(true, desc->removable);
ut_assertok(run_command("host info", 0));
- ut_assert_nextline("dev blocks label path");
- ut_assert_nextline(" 0 4096 test2 2MB.ext2.img");
+ ut_assert_nextline("dev blocks blksz label path");
+ ut_assert_nextline(" 0 4096512 test2
2MB.ext2.img");
ut_assert_console_end();
ut_assertok(run_commandf("host bind fat %s", filename2));
@@ -139,9 +139,9 @@ static int dm_test_cmd_host(struct unit_test_state *uts)
ut_asserteq(false, desc->removable);
ut_assertok(run_command("host info", 0));
- ut_assert_nextline("dev blocks label path");
- ut_assert_nextline(" 0 4096 test2 2MB.ext2.img");
- ut_assert_nextline(" 1 2048 fat 1MB.fat32.img");
+ ut_assert_nextline("dev blocks blksz label path");
+ ut_assert_nextline(" 0 4096512 test2
2MB.ext2.img");
+ ut_assert_nextline(" 1 2048512 fat
1MB.fat32.img");
ut_assert_console_end();
ut_asserteq(1, run_command("host info test", 0));
@@ -149,8 +149,8 @@ static int dm_test_cmd_host(struct unit_test_state *uts)
ut_assert_console_end();
ut_assertok(run_command("host info fat", 0));
- ut_assert_nextline("dev blocks label path");
- ut_assert_nextline(" 1 2048 fat 1MB.fat32.img");
+ ut_assert_nextline("dev blocks blksz label path");
+ ut_assert_nextline(" 1 2048512 fat
1MB.fat32.img");
ut_assert_console_end();
/* check 'host dev' */
@@ -186,8 +186,8 @@ static int dm_test_cmd_host(struct unit_test_state *uts)
ut_assert_console_end();
ut_assertok(run_command("host info", 0));
- ut_assert_nextline("dev blocks label path");
- ut_assert_nextline(" 1 2048 fat 1MB.fat32.img");
+ ut_assert_nextline("dev blocks blksz label path");
+ ut_assert_nextline(" 1 2048512 fat
1MB.fat32.img");
ut_assert_console_end();
return 0;
--
2.25.1
[PATCH 08/15] cmd: blkmap: Make map_handlers[] and its .fn static
These are only used in cmd/blkmap.c.
Signed-off-by: Bin Meng
---
cmd/blkmap.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/cmd/blkmap.c b/cmd/blkmap.c
index b34c013072..ef74ebc003 100644
--- a/cmd/blkmap.c
+++ b/cmd/blkmap.c
@@ -25,7 +25,8 @@ struct map_handler {
map_parser_fn fn;
};
-int do_blkmap_map_linear(struct map_ctx *ctx, int argc, char *const argv[])
+static int do_blkmap_map_linear(struct map_ctx *ctx, int argc,
+ char *const argv[])
{
struct blk_desc *lbd;
int err, ldevnum;
@@ -58,7 +59,7 @@ int do_blkmap_map_linear(struct map_ctx *ctx, int argc, char
*const argv[])
return CMD_RET_SUCCESS;
}
-int do_blkmap_map_mem(struct map_ctx *ctx, int argc, char *const argv[])
+static int do_blkmap_map_mem(struct map_ctx *ctx, int argc, char *const argv[])
{
phys_addr_t addr;
int err;
@@ -80,7 +81,7 @@ int do_blkmap_map_mem(struct map_ctx *ctx, int argc, char
*const argv[])
return CMD_RET_SUCCESS;
}
-struct map_handler map_handlers[] = {
+static struct map_handler map_handlers[] = {
{ .name = "linear", .fn = do_blkmap_map_linear },
{ .name = "mem", .fn = do_blkmap_map_mem },
--
2.25.1
[PATCH 07/15] blk: blkmap: Make bind/unbind routines static
These 2 are only used in drivers/block/blkmap.c.
Signed-off-by: Bin Meng
---
drivers/block/blkmap.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/block/blkmap.c b/drivers/block/blkmap.c
index 409aa46de2..f6acfa8927 100644
--- a/drivers/block/blkmap.c
+++ b/drivers/block/blkmap.c
@@ -383,7 +383,7 @@ U_BOOT_DRIVER(blkmap_blk) = {
.ops= _blk_ops,
};
-int blkmap_dev_bind(struct udevice *dev)
+static int blkmap_dev_bind(struct udevice *dev)
{
struct blkmap *bm = dev_get_plat(dev);
struct blk_desc *bd;
@@ -410,7 +410,7 @@ int blkmap_dev_bind(struct udevice *dev)
return 0;
}
-int blkmap_dev_unbind(struct udevice *dev)
+static int blkmap_dev_unbind(struct udevice *dev)
{
struct blkmap *bm = dev_get_plat(dev);
struct blkmap_slice *bms, *tmp;
--
2.25.1
[PATCH 05/15] blk: host_dev: Sanity check on the size of host backing file
Since we are emulating a block device, its size should be multiple
of the configured block size.
Signed-off-by: Bin Meng
---
drivers/block/host_dev.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/block/host_dev.c b/drivers/block/host_dev.c
index 0b43f80a86..30c7415793 100644
--- a/drivers/block/host_dev.c
+++ b/drivers/block/host_dev.c
@@ -58,6 +58,11 @@ static int host_sb_attach_file(struct udevice *dev, const
char *filename)
size = os_filesize(fd);
desc = dev_get_uclass_plat(blk);
+ if (size % desc->blksz) {
+ printf("The size of host backing file '%s' is not multiple of "
+ "the device block size\n", filename);
+ goto err_fname;
+ }
desc->lba = size / desc->blksz;
/* write this in last, when nothing can go wrong */
--
2.25.1
[PATCH 04/15] blk: host_dev: Make host_sb_detach_file() and host_sb_ops static
They are only used in drivers/block/host_dev.c.
Signed-off-by: Bin Meng
---
drivers/block/host_dev.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/block/host_dev.c b/drivers/block/host_dev.c
index 31c7814054..0b43f80a86 100644
--- a/drivers/block/host_dev.c
+++ b/drivers/block/host_dev.c
@@ -73,7 +73,7 @@ err_fname:
return ret;
}
-int host_sb_detach_file(struct udevice *dev)
+static int host_sb_detach_file(struct udevice *dev)
{
struct host_sb_plat *plat = dev_get_plat(dev);
int ret;
@@ -123,7 +123,7 @@ static int host_sb_bind(struct udevice *dev)
return 0;
}
-struct host_ops host_sb_ops = {
+static struct host_ops host_sb_ops = {
.attach_file= host_sb_attach_file,
.detach_file= host_sb_detach_file,
};
--
2.25.1
[PATCH 03/15] blk: sandbox: Support binding a device with a given logical block size
Allow optionally set the logical block size of the host device to
bind in the "host bind" command. If not given, defaults to 512.
Signed-off-by: Bin Meng
---
cmd/host.c | 16 +---
drivers/block/host-uclass.c | 15 ---
include/sandbox_host.h | 7 +--
test/dm/blk.c | 7 ---
test/dm/host.c | 6 +++---
5 files changed, 37 insertions(+), 14 deletions(-)
diff --git a/cmd/host.c b/cmd/host.c
index b924940ffb..2334ccd9bc 100644
--- a/cmd/host.c
+++ b/cmd/host.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
static int do_host_load(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
@@ -45,6 +46,7 @@ static int do_host_bind(struct cmd_tbl *cmdtp, int flag, int
argc,
struct udevice *dev;
const char *label;
char *file;
+ unsigned long blksz = DEFAULT_BLKSZ;
int ret;
/* Skip 'bind' */
@@ -59,12 +61,19 @@ static int do_host_bind(struct cmd_tbl *cmdtp, int flag,
int argc,
argv++;
}
- if (argc != 2)
+ if (argc < 2 || argc > 3)
return CMD_RET_USAGE;
label = argv[0];
file = argv[1];
+ if (argc > 2) {
+ blksz = dectoul(argv[2], NULL);
+ if (blksz < DEFAULT_BLKSZ || !is_power_of_2(blksz)) {
+ printf("blksz must be >= 512 and power of 2\n");
+ return CMD_RET_FAILURE;
+ }
+ }
- ret = host_create_attach_file(label, file, removable, );
+ ret = host_create_attach_file(label, file, removable, blksz, );
if (ret) {
printf("Cannot create device / bind file\n");
return CMD_RET_FAILURE;
@@ -253,7 +262,8 @@ U_BOOT_CMD(
"host save hostfs -[] - "
"save a file to host\n"
"host size hostfs - - determine size of file on host\n"
- "host bind [-r] - bind \"host\" device to file\n"
+ "host bind [-r] [] - bind \"host\" device to
file,\n"
+ " and optionally set the device's logical block size\n"
" -r = mark as removable\n"
"host unbind - unbind file from \"host\" device\n"
"host info [] - show device binding & info\n"
diff --git a/drivers/block/host-uclass.c b/drivers/block/host-uclass.c
index 6460d968c2..b3647e3ce3 100644
--- a/drivers/block/host-uclass.c
+++ b/drivers/block/host-uclass.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -29,7 +30,8 @@ struct host_priv {
struct udevice *cur_dev;
};
-int host_create_device(const char *label, bool removable, struct udevice
**devp)
+int host_create_device(const char *label, bool removable, unsigned long blksz,
+ struct udevice **devp)
{
char dev_name[30], *str, *label_new;
struct host_sb_plat *plat;
@@ -68,6 +70,12 @@ int host_create_device(const char *label, bool removable,
struct udevice **devp)
struct blk_desc *desc = dev_get_uclass_plat(blk);
desc->removable = removable;
+
+ /* update blk device's block size with the provided one */
+ if (blksz != desc->blksz) {
+ desc->blksz = blksz;
+ desc->log2blksz = LOG2(desc->blksz);
+ }
}
plat = dev_get_plat(dev);
@@ -95,12 +103,13 @@ int host_attach_file(struct udevice *dev, const char
*filename)
}
int host_create_attach_file(const char *label, const char *filename,
- bool removable, struct udevice **devp)
+ bool removable, unsigned long blksz,
+ struct udevice **devp)
{
struct udevice *dev;
int ret;
- ret = host_create_device(label, removable, );
+ ret = host_create_device(label, removable, blksz, );
if (ret)
return log_msg_ret("cre", ret);
diff --git a/include/sandbox_host.h b/include/sandbox_host.h
index ebd7d99b47..f7a5fc6723 100644
--- a/include/sandbox_host.h
+++ b/include/sandbox_host.h
@@ -74,10 +74,11 @@ int host_detach_file(struct udevice *dev);
* @label: Label of the attachment, e.g. "test1"
* @removable: true if the device should be marked as removable, false
* if it is fixed. See enum blk_flag_t
+ * @blksz: logical block size of the device
* @devp: Returns the device created, on success
* Returns: 0 if OK, -ve on error
*/
-int host_create_device(const char *label, bool removable,
+int host_create_device(const char *label, bool removable, unsigned long blksz,
struct udevice **devp);
/**
@@ -87,11 +88,13 @@ int host_create_
[PATCH 02/15] cmd: host: Mandate the filename parameter in the 'bind' command
At present the host bind command does not require filename to be
provided. When it is not given NULL is passed to the host device
driver, which ends up failure afterwards.
Change to mandate the filename so that it is useful.
Signed-off-by: Bin Meng
---
cmd/host.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/cmd/host.c b/cmd/host.c
index fb1cb1fdd1..b924940ffb 100644
--- a/cmd/host.c
+++ b/cmd/host.c
@@ -59,10 +59,10 @@ static int do_host_bind(struct cmd_tbl *cmdtp, int flag,
int argc,
argv++;
}
- if (argc > 2)
+ if (argc != 2)
return CMD_RET_USAGE;
label = argv[0];
- file = argc > 1 ? argv[1] : NULL;
+ file = argv[1];
ret = host_create_attach_file(label, file, removable, );
if (ret) {
@@ -253,7 +253,7 @@ U_BOOT_CMD(
"host save hostfs -[] - "
"save a file to host\n"
"host size hostfs - - determine size of file on host\n"
- "host bind [-r] [] - bind \"host\" device to file\n"
+ "host bind [-r] - bind \"host\" device to file\n"
" -r = mark as removable\n"
"host unbind - unbind file from \"host\" device\n"
"host info [] - show device binding & info\n"
--
2.25.1
[PATCH 01/15] blk: Use a macro for the typical block size
Avoid using the magic number 512 directly.
Signed-off-by: Bin Meng
---
common/usb_storage.c | 4 ++--
drivers/ata/dwc_ahsata.c | 3 ++-
drivers/ata/fsl_sata.c | 3 ++-
drivers/ata/sata_mv.c| 3 ++-
drivers/ata/sata_sil.c | 3 ++-
drivers/block/blkmap.c | 2 +-
drivers/block/host_dev.c | 2 +-
drivers/mmc/mmc-uclass.c | 2 +-
drivers/nvme/nvme.c | 2 +-
include/blk.h| 2 ++
10 files changed, 16 insertions(+), 10 deletions(-)
diff --git a/common/usb_storage.c b/common/usb_storage.c
index 85774220ef..35c656db0d 100644
--- a/common/usb_storage.c
+++ b/common/usb_storage.c
@@ -219,8 +219,8 @@ static int usb_stor_probe_device(struct usb_device *udev)
snprintf(str, sizeof(str), "lun%d", lun);
ret = blk_create_devicef(udev->dev, "usb_storage_blk", str,
-UCLASS_USB, usb_max_devs, 512, 0,
-);
+UCLASS_USB, usb_max_devs,
+DEFAULT_BLKSZ, 0, );
if (ret) {
debug("Cannot bind driver\n");
return ret;
diff --git a/drivers/ata/dwc_ahsata.c b/drivers/ata/dwc_ahsata.c
index 6a4d861bf1..b4d4e39c9b 100644
--- a/drivers/ata/dwc_ahsata.c
+++ b/drivers/ata/dwc_ahsata.c
@@ -880,7 +880,8 @@ int dwc_ahsata_scan(struct udevice *dev)
device_find_first_child(dev, );
if (!blk) {
ret = blk_create_devicef(dev, "dwc_ahsata_blk", "blk",
-UCLASS_AHCI, -1, 512, 0, );
+UCLASS_AHCI, -1, DEFAULT_BLKSZ,
+0, );
if (ret) {
debug("Can't create device\n");
return ret;
diff --git a/drivers/ata/fsl_sata.c b/drivers/ata/fsl_sata.c
index 972101b29c..969bc191f8 100644
--- a/drivers/ata/fsl_sata.c
+++ b/drivers/ata/fsl_sata.c
@@ -888,7 +888,8 @@ static int fsl_ata_probe(struct udevice *dev)
for (i = 0; i < nr_ports; i++) {
snprintf(sata_name, sizeof(sata_name), "fsl_sata%d", i);
ret = blk_create_devicef(dev, "sata_fsl_blk", sata_name,
-UCLASS_AHCI, -1, 512, 0, );
+UCLASS_AHCI, -1, DEFAULT_BLKSZ,
+0, );
if (ret) {
debug("Can't create device\n");
return ret;
diff --git a/drivers/ata/sata_mv.c b/drivers/ata/sata_mv.c
index 18c7a66db1..1abea0b309 100644
--- a/drivers/ata/sata_mv.c
+++ b/drivers/ata/sata_mv.c
@@ -1076,7 +1076,8 @@ static int sata_mv_probe(struct udevice *dev)
for (i = 0; i < nr_ports; i++) {
ret = blk_create_devicef(dev, "sata_mv_blk", "blk",
-UCLASS_AHCI, -1, 512, 0, );
+UCLASS_AHCI, -1, DEFAULT_BLKSZ,
+0, );
if (ret) {
debug("Can't create device\n");
continue;
diff --git a/drivers/ata/sata_sil.c b/drivers/ata/sata_sil.c
index b5e150d568..43a91a7912 100644
--- a/drivers/ata/sata_sil.c
+++ b/drivers/ata/sata_sil.c
@@ -730,7 +730,8 @@ static int sil_pci_probe(struct udevice *dev)
for (i = sata_info.portbase; i < sata_info.maxport; i++) {
snprintf(sata_name, sizeof(sata_name), "sil_sata%d", i);
ret = blk_create_devicef(dev, "sata_sil_blk", sata_name,
-UCLASS_AHCI, -1, 512, 0, );
+UCLASS_AHCI, -1, DEFAULT_BLKSZ,
+0, );
if (ret) {
debug("Can't create device\n");
return ret;
diff --git a/drivers/block/blkmap.c b/drivers/block/blkmap.c
index 2bb0acc20f..409aa46de2 100644
--- a/drivers/block/blkmap.c
+++ b/drivers/block/blkmap.c
@@ -390,7 +390,7 @@ int blkmap_dev_bind(struct udevice *dev)
int err;
err = blk_create_devicef(dev, "blkmap_blk", "blk", UCLASS_BLKMAP,
-dev_seq(dev), 512, 0, >blk);
+dev_seq(dev), DEFAULT_BLKSZ, 0, >blk);
if (err)
return log_msg_ret("blk", err);
diff --git a/drivers/block/host_dev.c b/drivers/block/host_dev.c
index 64422417b7..31c7814054 100644
--- a/drivers/block/host_dev.c
+++ b/drivers/block/host_dev.c
@@ -105,7 +105,7 @@ static int host_sb_bind(struct udevice *dev)
int ret;
ret = blk_create_devicef(dev, "sandbox_host_blk", "blk", UCLASS_H
[PATCH 00/15] blk: sandbox: Support binding a device with a given logical block size
At present on Sandbox when binding to a host backing file, the host
block device is created with a hard-coded 512 bytes block size.
Such assumption works for most cases, but for situation that with a raw
image file dump from a pre-formatted GPT partitioned disk image from a
4KiB block size device, when binding this file to a host device and mapping
this device to a blkmap, "blkmap" command like "blkmap part" won't work
correctly, due to block size mismatch during parsing the partition table.
This series updates Sandbox block driver, as well as the blkmap driver,
to get rid of the hard-coded 512 bytes block size assumption.
This series is available at u-boot-x86/blk for testing.
Test log (512 block size):
=> host bind 0 test.img
=> host info
dev blocks blksz label path
0 262144512 0 test.img
=> blkmap create 0
Created "0"
=> blkmap map 0 0 4 linear host 0 0
Block 0x0+0x4 mapped to block 0x0 of "host 0"
=> blkmap info
Device 0: Vendor: U-Boot Rev: 1.0 Prod: blkmap
Type: Hard Disk
Capacity: 128.0 MB = 0.1 GB (262144 x 512)
=> blkmap part
Partition Map for BLKMAP device 0 -- Partition Type: EFI
PartStart LBA End LBA Name
Attributes
Type GUID
Partition GUID
1 0x0022 0x00bd "u-boot-spl"
attrs: 0x
type: 5b193300-fc78-40cd-8002-e86c45580b47
(5b193300-fc78-40cd-8002-e86c45580b47)
guid: 0bb6bb6e-4aac-4c27-be03-016b01e7b941
2 0x0822 0x0c84 "u-boot"
attrs: 0x
type: 2e54b353-1271-4842-806f-e436d6af6985
(2e54b353-1271-4842-806f-e436d6af6985)
guid: 91d50814-8e31-4cc0-97dc-779e1dc59056
3 0x0c85 0xcc84 "rootfs"
attrs: 0x0004
type: 0fc63daf-8483-4772-8e79-3d69d8477de4
(linux)
guid: 42799722-6e55-46e6-afa9-529e7af3f03b
Test log (4096 block size):
=> host bind 0 test.img 4096
=> host info
dev blocks blksz label path
032768 4096 0 test.img
=> blkmap create 0
Created "0"
=> blkmap map 0 0 8000 linear host 0 0
Block 0x0+0x8000 mapped to block 0x0 of "host 0"
=> blkmap info
Device 0: Vendor: U-Boot Rev: 1.0 Prod: blkmap
Type: Hard Disk
Capacity: 128.0 MB = 0.1 GB (32768 x 4096)
=> blkmap part
Partition Map for BLKMAP device 0 -- Partition Type: EFI
PartStart LBA End LBA Name
Attributes
Type GUID
Partition GUID
1 0x0100 0x1fff "primary"
attrs: 0x
type: 0fc63daf-8483-4772-8e79-3d69d8477de4
(linux)
guid: eba904d7-72c1-4dbd-bb4e-36be49cba5e3
2 0x2000 0x7ffa "primary"
attrs: 0x00000000
type: 0fc63daf-8483-4772-8e79-3d69d8477de4
(linux)
guid: c48c360e-db47-46da-ab87-26416fad3cd3
Bin Meng (15):
blk: Use a macro for the typical block size
cmd: host: Mandate the filename parameter in the 'bind' command
blk: sandbox: Support binding a device with a given logical block size
blk: host_dev: Make host_sb_detach_file() and host_sb_ops static
blk: host_dev: Sanity check on the size of host backing file
cmd: host: Print out the block size of the host device
blk: blkmap: Make bind/unbind routines static
cmd: blkmap: Make map_handlers[] and its .fn static
blk: blkmap: Support mapping to device of any block size
cmd: blk_common: Use macros for the return values
dm: blk: Rename get_desc() and make it externally visible
cmd: blk_common: Stop using hard-coded block size for Sandbox
operations
dm: blk: Drop blk_{read,write}_devnum()
disk: part: Print out the unknown device uclass id
disk: part: Handle blkmap device in print_part_header()
cmd/blk_common.c| 34 +++--
cmd/blkmap.c| 7 ++---
cmd/host.c | 25 +-
common/usb_storage.c| 4 +--
disk/part.c | 5 +++-
drivers/ata/dwc_ahsata.c| 3 ++-
drivers/ata/fsl_sata.c | 3 ++-
drivers/ata/sata_mv.c | 3 ++-
drivers/ata/sata_sil.c | 3 ++-
drivers/block/blk-uclass.c | 51 +
drivers/block/blkmap.c | 16 ++--
drivers/block/host-uclass.c | 15 ---
drivers/block/host_dev.c| 11 +---
drivers/mmc/mmc-uclass.c| 2 +-
drivers/nvme/nvme.c | 2 +-
include/blk.h | 40 ++---
include/sandbox_host.h | 7 +++--
test/dm/blk.c | 7 ++---
test/dm/host.c | 26 +--
19 files changed, 129 insertions(+), 135 deletions(-)
--
2.25.1
Please pull u-boot-x86 into -next
Hi Tom, The following changes since commit 5d2fae79c7d60eaf7f50322e4ec125d2f58544e9: Merge tag 'xilinx-for-v2024.01-rc1-v2' of https://source.denx.de/u-boot/custodians/u-boot-microblaze into next (2023-09-21 10:51:58 -0400) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-x86.git tags/x86-pull-20230922 for you to fetch changes up to 5728246dfa11400d4f7aa8262ea630d8c09a85b9: x86: doc: coreboot: Mention 64-bit Linux distros (2023-09-22 06:05:40 +0800) - Add bootstd support to 64-bit efi payload - Fix a bug of missing setting size of initrd in pxeboot - Allow Python packages to be dropped - Reland "x86: Move FACP table into separate functions" - Fixes for chromebook_link64 and chromebook_samus_tpl - Fixes and improvements for coreboot - x86 documentation updates Andy Shevchenko (1): x86: Prevent from missing the FADT chaining Simon Glass (35): Allow Python packages to be dropped x86: coreboot: Avoid a declaration after a label Reland "x86: Move FACP table into separate functions"" x86: doc: Document the -cdrom issues I ran into dm: core: Allow marking driver model as dead x86: broadwell: Show the memory delay x86: Add some log categories x86: samus_tpl: Correct text base and alloc sizes x86: spl: Change the condition for copying U-Boot to RAM x86: broadwell: Avoid initing the CPU twice x86: broadwell: Set up MTRRs x86: dm: Mark driver model as dead when disabling CAR x86: doc: Update the list of supported Chromebooks x86: coreboot: Document cbmem console struct x86: Update cbmem driver x86: coreboot: Add IDE and SATA x86: coreboot: Enable standard boot x86: coreboot: Rearrange arch_cpu_init() x86: Set the CPU vendor in SPL x86: Allow APCI in SPL x86: coreboot: Look for DBG2 UART in SPL too x86: coreboot: Enable CONFIG_SYS_NS16550_MEM32 x86: coreboot: Drop USB init on startup x86: coreboot: Align options between coreboot and coreboot64 x86: coreboot: Enable VIDEO_COPY efi: x86: Correct the condition for installing ACPI tables x86: smbios: Add a Kconfig indicating SMBIOS-table presence bootstd: Keep track of use of usb stop Record the position of the SMBIOS tables efi: Use the installed SMBIOS tables x86: coreboot: Record the position of the SMBIOS tables x86: doc: Move into its own directory x86: doc: Update summaries and add links x86: doc: Split out manual booting into its own file x86: doc: coreboot: Mention 64-bit Linux distros Thomas Mittelstaedt (3): x86: efi-payload64: Add support for SCSI devices x86: efi-payload64: Add bootstd support x86: pxeboot: bugfix: Set variable for size of initrd Troy Kisky (1): x86: cpu: i386: cpu: only set pci_ram_top if CONFIG_IS_ENABLED(PCI) Makefile| 9 +++ arch/arm/include/asm/global_data.h | 3 + arch/riscv/include/asm/global_data.h| 3 + arch/sandbox/include/asm/global_data.h | 1 + arch/x86/cpu/apollolake/acpi.c | 13 ++-- arch/x86/cpu/baytrail/acpi.c| 23 +--- arch/x86/cpu/broadwell/cpu.c| 10 ++-- arch/x86/cpu/broadwell/sdram.c | 2 + arch/x86/cpu/coreboot/Kconfig | 1 + arch/x86/cpu/coreboot/coreboot.c| 16 ++--- arch/x86/cpu/i386/cpu.c | 2 +- arch/x86/cpu/intel_common/mrc.c | 18 +- arch/x86/cpu/quark/acpi.c | 23 +--- arch/x86/cpu/tangier/acpi.c | 23 +--- arch/x86/cpu/x86_64/cpu.c | 7 +++ arch/x86/dts/chromebook_samus.dts | 1 + arch/x86/dts/coreboot.dts | 1 + arch/x86/include/asm/acpi_table.h | 2 - arch/x86/include/asm/coreboot_tables.h | 17 +- arch/x86/include/asm/global_data.h | 1 + arch/x86/lib/acpi_table.c | 15 - arch/x86/lib/coreboot/cb_sysinfo.c | 1 + arch/x86/lib/init_helpers.c | 7 +-- arch/x86/lib/spl.c | 5 +- arch/x86/lib/tables.c | 3 + arch/x86/lib/tpl.c | 2 + board/Marvell/mvebu_armada-37xx/board.c | 3 +- board/coreboot/coreboot/coreboot.c | 14 ++--- boot/bootdev-uclass.c | 27 + boot/pxe_utils.c| 2 +- common/spl/spl.c| 2 +- configs/chromebook_samus_tpl_defconfig | 4 +- configs/coreboot64_defconfig| 25 configs/coreboot_defconfig | 21 --- configs/efi-x86_payload64_defconfig | 6 +- doc/arch/index.rst | 2 +- doc/arch/x86/index.rst | 12 doc/arch/x86/manual_boot.rst| 276
Re: [NEW FEATURE] RFC: Add Intel GMBUS support
+Simon Hi Eric, On Fri, Sep 22, 2023 at 6:10 AM Eric Schikschneit wrote: > > I have begun working on adding support for the Intel Graphics Management bus > to U-Boot. Currently the x86 bring up process (as explored on the Baytrail > series of Atom SOCs) relys on the Intel Video BIOS to do all setup and > configuration of the GPU. This method of adding video support works on > earlier versions of the silicon. With later versions I have found that the > OEM BIOS needs to capture the monitor data over the GMBUS in order to > initialize the GPU properly. I have logic analyzer captures available for > anyone who is curious. My purpose for this patch is a skeleton placeholder > that I will be working from, and I am asking for community collaboration with > this. I have hardware available for testing as needed, and some details can > be provided upon request. Would you share the documentation that describes the Intel GM bus, if publicly available? Based on the info you provided, did you mean with later new revision BayTrail chips, the video bios initialization is not enough in U-Boot? AFAIU, the U-Boot BayTrail support relies on Intel FSP to do any chipset-specific work, including the video bios setup. Regards, Bin
Re: [PATCH v7 2/3] x86: coreboot: Drop USB init on startup
On Thu, Sep 21, 2023 at 9:37 PM Simon Glass wrote: > > This is very annoying as it is quite slow on many machines. Also, U-Boot > has an existing 'preboot' mechanism to enable this feature if desired. > > Drop this code so that it is possible to choose whether to init USB or > not. > > Use the existing USE_PREBOOT mechanism instead. > > Signed-off-by: Simon Glass > --- > > Changes in v7: > - Add docs about how USB keyboard works on coreboot > > Changes in v5: > - Make use of the uSE_PREBOOT mechanism > > arch/x86/cpu/coreboot/Kconfig| 1 + > arch/x86/cpu/coreboot/coreboot.c | 4 > doc/board/coreboot/coreboot.rst | 7 +++ > 3 files changed, 8 insertions(+), 4 deletions(-) > Reviewed-by: Bin Meng series applied to u-boot-x86/next, thanks!
Re: [PATCH v7 1/3] fixup: Move python control earlier in Makefile
On Thu, Sep 21, 2023 at 9:37 PM Simon Glass wrote: > > Move this control into the common area of the main Makefile, so it > applies to non-build rules as well. This allows 'make mrproper' to handle > python files as it should. > > This should be squashed into: > >65a33eba10d Allow Python packages to be dropped > > Signed-off-by: Simon Glass > --- > > Changes in v7: > - Add new fixup patch to move python control earlier in Makefile > > Makefile | 17 + > 1 file changed, 9 insertions(+), 8 deletions(-) > squashed into "65a33eba10d Allow Python packages to be dropped" on u-boot-x86/next, thanks!
Re: [PATCH v5 00/20] x86: efi: Fixes and improvements for coreboot
Hi Simon, On Thu, Sep 21, 2023 at 1:27 PM Bin Meng wrote: > > Hi Simon, > > On Wed, Sep 20, 2023 at 11:00 AM Simon Glass wrote: > > > > This little series fixes various bugs and annoyances in coreboot and > > coreboot64. > > > > With this both coreboot and coreboot64 start up and work reasonably well > > on Brya (x86 Chromebook) and U-Boot can boot common Linux distros. > > > > - Make coreboot64 debug UART start reliably > > - Avoid the long USB-init delay on startup > > - Correct the timer speed on coreboo64 > > - Fix a bootstd cros bug (will likely be squashed into another patch) > > - Fix the terribly slow console scrolling > > > > With v2 I have also brought in some lost x86 patches so they are all in > > one series. > > > > Changes in v5: > > - Use 'lzma' instead of 'LZMA' > > - Drop unwanted space > > - Correct 'teechnique' typo in commit message > > - Make use of the uSE_PREBOOT mechanism > > > > Changes in v4: > > - Fix arm and riscv > > - Rewrite this to use events instead > > > > Changes in v3: > > - Allow SMBIOS if EFI_LOADER is enabled > > - Reword the help > > - Use log_debug() to show the message > > - Squash in the next patch > > > > Changes in v2: > > - Update the malloc size too > > - Add new patch > > - Add new patch > > - Add new patch > > - Add new patch > > - Add new patch > > - Add new patch > > - Add new patch > > - Add new patch > > - Add new patch > > > > Simon Glass (20): > > x86: coreboot: Add IDE and SATA > > x86: coreboot: Enable standard boot > > x86: coreboot: Rearrange arch_cpu_init() > > x86: Set the CPU vendor in SPL > > x86: Allow APCI in SPL > > x86: coreboot: Look for DBG2 UART in SPL too > > x86: coreboot: Enable CONFIG_SYS_NS16550_MEM32 > > x86: coreboot: Drop USB init on startup > > x86: coreboot: Align options between coreboot and coreboot64 > > x86: coreboot: Enable VIDEO_COPY > > efi: x86: Correct the condition for installing ACPI tables > > x86: smbios: Add a Kconfig indicating SMBIOS-table presence > > bootstd: Keep track of use of usb stop > > Record the position of the SMBIOS tables > > efi: Use the installed SMBIOS tables > > x86: coreboot: Record the position of the SMBIOS tables > > x86: doc: Move into its own directory > > x86: doc: Update summaries and add links > > x86: doc: Split out manual booting into its own file > > x86: doc: coreboot: Mention 64-bit Linux distros > > > > Patch #8 needs to respin to address PREBOOT comment > Path#18 does not apply. > > Patch#13, 15 v6 version are applied. > > Reset patches in this series are applied to u-boot-x86/next, thanks! The CI still fails on u-boot-x86/next which is already rebased on origin/next. https://source.denx.de/u-boot/custodians/u-boot-x86/-/pipelines/17784 Regards, Bin
Re: [PATCH v5 00/20] x86: efi: Fixes and improvements for coreboot
Hi Simon, On Wed, Sep 20, 2023 at 11:00 AM Simon Glass wrote: > > This little series fixes various bugs and annoyances in coreboot and > coreboot64. > > With this both coreboot and coreboot64 start up and work reasonably well > on Brya (x86 Chromebook) and U-Boot can boot common Linux distros. > > - Make coreboot64 debug UART start reliably > - Avoid the long USB-init delay on startup > - Correct the timer speed on coreboo64 > - Fix a bootstd cros bug (will likely be squashed into another patch) > - Fix the terribly slow console scrolling > > With v2 I have also brought in some lost x86 patches so they are all in > one series. > > Changes in v5: > - Use 'lzma' instead of 'LZMA' > - Drop unwanted space > - Correct 'teechnique' typo in commit message > - Make use of the uSE_PREBOOT mechanism > > Changes in v4: > - Fix arm and riscv > - Rewrite this to use events instead > > Changes in v3: > - Allow SMBIOS if EFI_LOADER is enabled > - Reword the help > - Use log_debug() to show the message > - Squash in the next patch > > Changes in v2: > - Update the malloc size too > - Add new patch > - Add new patch > - Add new patch > - Add new patch > - Add new patch > - Add new patch > - Add new patch > - Add new patch > - Add new patch > > Simon Glass (20): > x86: coreboot: Add IDE and SATA > x86: coreboot: Enable standard boot > x86: coreboot: Rearrange arch_cpu_init() > x86: Set the CPU vendor in SPL > x86: Allow APCI in SPL > x86: coreboot: Look for DBG2 UART in SPL too > x86: coreboot: Enable CONFIG_SYS_NS16550_MEM32 > x86: coreboot: Drop USB init on startup > x86: coreboot: Align options between coreboot and coreboot64 > x86: coreboot: Enable VIDEO_COPY > efi: x86: Correct the condition for installing ACPI tables > x86: smbios: Add a Kconfig indicating SMBIOS-table presence > bootstd: Keep track of use of usb stop > Record the position of the SMBIOS tables > efi: Use the installed SMBIOS tables > x86: coreboot: Record the position of the SMBIOS tables > x86: doc: Move into its own directory > x86: doc: Update summaries and add links > x86: doc: Split out manual booting into its own file > x86: doc: coreboot: Mention 64-bit Linux distros > Patch #8 needs to respin to address PREBOOT comment Path#18 does not apply. Patch#13, 15 v6 version are applied. Reset patches in this series are applied to u-boot-x86/next, thanks! The reset Regards, Bin
Re: [PATCH v5 08/20] x86: coreboot: Drop USB init on startup
Hi Simon, On Wed, Sep 20, 2023 at 9:37 PM Heinrich Schuchardt wrote: > > On 20.09.23 13:50, Marek Vasut wrote: > > On 9/20/23 09:19, Heinrich Schuchardt wrote: > >> On 9/20/23 05:00, Simon Glass wrote: > >>> This is very annoying as it is quite slow on many machines. Also, U-Boot > >>> has an existing 'preboot' mechanism to enable this feature if desired. > >>> > >>> Drop this code so that it is possible to choose whether to init USB or > >>> not. > >>> > >>> Use the existing USE_PREBOOT mechanism instead. > >>> > >>> Signed-off-by: Simon Glass > >>> --- > >>> > >>> Changes in v5: > >>> - Make use of the uSE_PREBOOT mechanism > >>> > >>> arch/x86/cpu/coreboot/Kconfig| 1 + > >>> arch/x86/cpu/coreboot/coreboot.c | 4 > >>> 2 files changed, 1 insertion(+), 4 deletions(-) > >>> > >>> diff --git a/arch/x86/cpu/coreboot/Kconfig > >>> b/arch/x86/cpu/coreboot/Kconfig > >>> index b97c27790419..178f8ad18162 100644 > >>> --- a/arch/x86/cpu/coreboot/Kconfig > >>> +++ b/arch/x86/cpu/coreboot/Kconfig > >>> @@ -25,6 +25,7 @@ config SYS_COREBOOT > >>> imply FS_CBFS > >>> imply CBMEM_CONSOLE > >>> imply X86_TSC_READ_BASE > >>> +imply USE_PREBOOT > >> > >> For automatic initialization of the PCI bus we have CONFIG_PCI_INIT_R. > >> Wouldn't it be preferable to also have a CONFIG_USB_INIT_R instead of > >> relying on console commands in CONFIG_PREBOOT? > > > > I'd much prefer 'preboot=usb init' or whatever console command, since > > this is not hard-coded into the U-Boot binary and can be overridden by > > user if the 'usb init' is inconvenient/unnecessary/... without replacing > > and/or rebuilding the U-Boot binary. > > Just for the record this means using CONFIG_PREBOOT: > > include/env_default.h: > > #ifdef CONFIG_PREBOOT_DEFINED > "preboot="CONFIG_PREBOOT"\0" > #endif > > Thank you for the clarification. Will you update the coreboot documentation to mention the PREBOOT mechanism to initialize USB so that a USB keyboard can be used as the input for the U-Boot console? Regards, Bin
Re: [PATCH v5 07/20] x86: coreboot: Enable CONFIG_SYS_NS16550_MEM32
On Wed, Sep 20, 2023 at 11:00 AM Simon Glass wrote: > > The debug UART on modern machines uses a 32-bit wide transfer. Without > this, setting debug output causes a hang or no output. It is not obvious > (when enabling CONFIG_DEBUG_UART) that this is needed. > > Enable 32-bit access to avoid this trap. > > Signed-off-by: Simon Glass > --- > > (no changes since v1) > > configs/coreboot64_defconfig | 1 + > configs/coreboot_defconfig | 1 + > 2 files changed, 2 insertions(+) > Reviewed-by: Bin Meng
Re: [PATCH v4 2/2] x86: Update cbmem driver
Hi Simon,
On Wed, Sep 20, 2023 at 10:59 AM Simon Glass wrote:
>
> Hi Bin,
>
> On Tue, 19 Sept 2023 at 02:47, Bin Meng wrote:
> >
> > Hi Simon,
> >
> > On Mon, Sep 11, 2023 at 3:13 AM Simon Glass wrote:
> > >
> > > This driver is not actually built since a Kconfig was never created for
> > > it.
> > >
> > > Add a Kconfig (which is already implied by COREBOOT) and update the
> > > implementation to avoid using unnecessary memory. Drop the #ifdef at the
> > > top since we can rely on Kconfig to get that right.
> > >
> > > To enable it (in addition to serial and video), use:
> > >
> > >setenv stdout serial,vidconsole,cbmem
> > >
> > > Signed-off-by: Simon Glass
> > > ---
> > >
> > > Changes in v4:
> > > - Add some comments to help understand the overflow mechanism
> > >
> > > Changes in v2:
> > > - Update to support the new overflow mechanism
> > >
> > > drivers/misc/Kconfig | 8 +++
> > > drivers/misc/cbmem_console.c | 43 ++--
> > > 2 files changed, 34 insertions(+), 17 deletions(-)
> > >
> > > diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> > > index a6e3f62ecb09..c930e4a361bf 100644
> > > --- a/drivers/misc/Kconfig
> > > +++ b/drivers/misc/Kconfig
> > > @@ -122,6 +122,14 @@ config VEXPRESS_CONFIG
> > > configuration bus on the Arm Versatile Express boards via
> > > a sysreg driver.
> > >
> > > +config CBMEM_CONSOLE
> > > + bool "Write console output to coreboot cbmem"
> > > + depends on X86
> > > + help
> > > + Enables console output to the cbmem console, which is a memory
> > > + region set up by coreboot to hold a record of all console
> > > output.
> > > + Enable this only if booting from coreboot.
> > > +
> > > config CMD_CROS_EC
> > > bool "Enable crosec command"
> > > depends on CROS_EC
> > > diff --git a/drivers/misc/cbmem_console.c b/drivers/misc/cbmem_console.c
> > > index 8bbe33d414da..3cbe9fb1a46a 100644
> > > --- a/drivers/misc/cbmem_console.c
> > > +++ b/drivers/misc/cbmem_console.c
> > > @@ -5,27 +5,37 @@
> > >
> > > #include
> > > #include
> > > -#ifndef CONFIG_SYS_COREBOOT
> > > -#error This driver requires coreboot
> > > -#endif
> > > -
> > > #include
> > >
> > > -struct cbmem_console {
> > > - u32 buffer_size;
> > > - u32 buffer_cursor;
> > > - u8 buffer_body[0];
> > > -} __attribute__ ((__packed__));
> > > -
> > > -static struct cbmem_console *cbmem_console_p;
> > > -
> > > void cbmemc_putc(struct stdio_dev *dev, char data)
> > > {
> > > - int cursor;
> > > + const struct sysinfo_t *sysinfo = cb_get_sysinfo();
> > > + struct cbmem_console *cons;
> > > + uint pos, flags;
> > > +
> > > + if (!sysinfo)
> > > + return;
> > > + cons = sysinfo->cbmem_cons;
> > > + if (!cons)
> > > + return;
> > > +
> > > + pos = cons->cursor & CBMC_CURSOR_MASK;
> > > +
> > > + /* preserve the overflow flag if present */
> > > + flags = cons->cursor & ~CBMC_CURSOR_MASK;
> > > +
> > > + cons->body[pos++] = data;
> > > +
> > > + /*
> > > +* Deal with overflow - the flag may be cleared by another
> > > program which
> > > +* reads the buffer out, e.g. Linux
> > > +*/
> >
> > U-Boot is not memory resident, so this does not sound like a correct
> > overflow mechanism to me.
>
> I am not sure what you mean. This logic is used in coreboot and some
> payloads, so I want to do the same in U-Boot. It basically let's
> U-Boot handle an overflow properly by setting the overflow flag. A
> later program (e.g. Linux) can then tell that that an overflow
> occurred.
>
Okay, I modified the comment to
/*
* Deal with overflow - the flag may be cleared by another program which
* reads the buffer out later, e.g. Linux
*/
which makes more sense.
applied to u-boot-x86/next, thanks!
Regards,
Bin
Re: [PATCH v4 1/2] x86: coreboot: Document cbmem console struct
On Mon, Sep 11, 2023 at 3:13 AM Simon Glass wrote:
>
> Coreboot changed a few years ago to include an overflow flag. Update the
> structure to match this.
>
> This comes from coreboot commit:
>
>6f5ead14b4 ("mb/google/nissa/var/joxer: Update eMMC DLL settings")
>
> Note: There are several implementations of this in coreboot. I have chosen
> to follow the one in src/lib/cbmem_console.c
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v4:
> - Reword commit and change title
>
> Changes in v3:
> - Drop __packed as it does nothing useful
>
Reviewed-by: Bin Meng
Re: [PATCH v4 2/2] x86: Update cbmem driver
Hi Simon,
On Mon, Sep 11, 2023 at 3:13 AM Simon Glass wrote:
>
> This driver is not actually built since a Kconfig was never created for
> it.
>
> Add a Kconfig (which is already implied by COREBOOT) and update the
> implementation to avoid using unnecessary memory. Drop the #ifdef at the
> top since we can rely on Kconfig to get that right.
>
> To enable it (in addition to serial and video), use:
>
>setenv stdout serial,vidconsole,cbmem
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v4:
> - Add some comments to help understand the overflow mechanism
>
> Changes in v2:
> - Update to support the new overflow mechanism
>
> drivers/misc/Kconfig | 8 +++
> drivers/misc/cbmem_console.c | 43 ++--
> 2 files changed, 34 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> index a6e3f62ecb09..c930e4a361bf 100644
> --- a/drivers/misc/Kconfig
> +++ b/drivers/misc/Kconfig
> @@ -122,6 +122,14 @@ config VEXPRESS_CONFIG
> configuration bus on the Arm Versatile Express boards via
> a sysreg driver.
>
> +config CBMEM_CONSOLE
> + bool "Write console output to coreboot cbmem"
> + depends on X86
> + help
> + Enables console output to the cbmem console, which is a memory
> + region set up by coreboot to hold a record of all console output.
> + Enable this only if booting from coreboot.
> +
> config CMD_CROS_EC
> bool "Enable crosec command"
> depends on CROS_EC
> diff --git a/drivers/misc/cbmem_console.c b/drivers/misc/cbmem_console.c
> index 8bbe33d414da..3cbe9fb1a46a 100644
> --- a/drivers/misc/cbmem_console.c
> +++ b/drivers/misc/cbmem_console.c
> @@ -5,27 +5,37 @@
>
> #include
> #include
> -#ifndef CONFIG_SYS_COREBOOT
> -#error This driver requires coreboot
> -#endif
> -
> #include
>
> -struct cbmem_console {
> - u32 buffer_size;
> - u32 buffer_cursor;
> - u8 buffer_body[0];
> -} __attribute__ ((__packed__));
> -
> -static struct cbmem_console *cbmem_console_p;
> -
> void cbmemc_putc(struct stdio_dev *dev, char data)
> {
> - int cursor;
> + const struct sysinfo_t *sysinfo = cb_get_sysinfo();
> + struct cbmem_console *cons;
> + uint pos, flags;
> +
> + if (!sysinfo)
> + return;
> + cons = sysinfo->cbmem_cons;
> + if (!cons)
> + return;
> +
> + pos = cons->cursor & CBMC_CURSOR_MASK;
> +
> + /* preserve the overflow flag if present */
> + flags = cons->cursor & ~CBMC_CURSOR_MASK;
> +
> + cons->body[pos++] = data;
> +
> + /*
> +* Deal with overflow - the flag may be cleared by another program
> which
> +* reads the buffer out, e.g. Linux
> +*/
U-Boot is not memory resident, so this does not sound like a correct
overflow mechanism to me.
> + if (pos >= cons->size) {
> + pos = 0;
> + flags |= CBMC_OVERFLOW;
> + }
>
> - cursor = cbmem_console_p->buffer_cursor++;
> - if (cursor < cbmem_console_p->buffer_size)
> - cbmem_console_p->buffer_body[cursor] = data;
> + cons->cursor = flags | pos;
> }
>
> void cbmemc_puts(struct stdio_dev *dev, const char *str)
> @@ -40,7 +50,6 @@ int cbmemc_init(void)
> {
> int rc;
> struct stdio_dev cons_dev;
> - cbmem_console_p = lib_sysinfo.cbmem_cons;
>
> memset(_dev, 0, sizeof(cons_dev));
>
Regards,
Bin
Re: [PATCH v2 0/9] x86: Fixes for chromebook_link64 and chromebook_samus_tpl
On Thu, Sep 7, 2023 at 11:58 PM Simon Glass wrote: > > These boards have various problems which prevent them from booting. In > the case of link there was a recent regression with PCI probing added to > SPL. For samus_tpl it needs a few tweaks to get things back up and > running. > > This series resolves all known issues. > > For v2, the 'Avoid starting up PCI automatically in SPL' patch has been > replaced with a global_data flag. > > Changes in v2: > - Add new patch to allow marking driver model as dead > - Reword commit message for clarity and to fix typo > - Add new patch to mark driver model as dead when disabling CAR > > Simon Glass (9): > dm: core: Allow marking driver model as dead > x86: broadwell: Show the memory delay > x86: Add some log categories > x86: samus_tpl: Correct text base and alloc sizes > x86: spl: Change the condition for copying U-Boot to RAM > x86: broadwell: Avoid initing the CPU twice > x86: broadwell: Set up MTRRs > x86: dm: Mark driver model as dead when disabling CAR > x86: doc: Update the list of supported Chromebooks > series applied to u-boot-x86/next, thanks!
Re: [PATCH v2 7/9] x86: broadwell: Set up MTRRs
On Thu, Sep 7, 2023 at 11:58 PM Simon Glass wrote: > > The current condition does not handle the samus_tpl case where it sets > up the RAM in SPL but needs to commit the MTRRs in U-Boot proper. > > Add another case to handle this and update the comment. > > Signed-off-by: Simon Glass > --- > > (no changes since v1) > > arch/x86/lib/init_helpers.c | 7 +++ > 1 file changed, 3 insertions(+), 4 deletions(-) > Reviewed-by: Bin Meng
Re: [PATCH v2 8/9] x86: dm: Mark driver model as dead when disabling CAR
On Thu, Sep 7, 2023 at 11:58 PM Simon Glass wrote: > > When turning off CAR, set the flag to make sure that nothing tries to use > driver model in SPL before jumping to U-Bot proper, since its tables are > in CAR. > > Signed-off-by: Simon Glass > --- > > Changes in v2: > - Add new patch to mark driver model as dead when disabling CAR > > arch/x86/lib/spl.c | 3 +++ > 1 file changed, 3 insertions(+) > Reviewed-by: Bin Meng
Re: [PATCH v2 1/9] dm: core: Allow marking driver model as dead
On Thu, Sep 7, 2023 at 11:58 PM Simon Glass wrote: > > On x86 devices we use CAR (Cache-As-RAM) to hold the malloc() region in > SPL, since SDRAM is not set up yet. This means that driver model stores > its tables in this region. > > When preparing to jump from SPL to U-Boot proper, we must disable CAR, so > that the CPU can uses the caches normally. This means that driver model > tables become inaccessible. From there until we jump to U-Boot proper, we > must avoid using driver model. > > This is only a problem on boards which operate this way, for example > chromebook_link64 > > Add a flag to indicate that driver model is dead and should not be used. > It can be used in SPL to avoid hanging the machine. > > Signed-off-by: Simon Glass > --- > > Changes in v2: > - Add new patch to allow marking driver model as dead > > common/spl/spl.c | 2 +- > include/asm-generic/global_data.h | 5 +++++ > 2 files changed, 6 insertions(+), 1 deletion(-) > Reviewed-by: Bin Meng
Re: [PATCH] x86: doc: Document the -cdrom issues I ran into
On Sat, Sep 2, 2023 at 2:08 AM Simon Glass wrote: > > Add a note about using -cdrom with QEMU. > > Suggested-by: Bin Meng > Signed-off-by: Simon Glass > --- > > doc/board/emulation/qemu-x86.rst | 3 +++ > 1 file changed, 3 insertions(+) > Reviewed-by: Bin Meng applied to u-boot-86/next, thanks!
Re: [PATCH v3 1/2] Reland "x86: Move FACP table into separate functions""
On Sat, Sep 2, 2023 at 1:27 AM Simon Glass wrote: > > Each board has its own way of creating this table. Rather than calling the > acpi_create_fadt() function for each one from a common acpi_write_fadt() > function, just move the writer into the board-specific code. > > Co-developed-by: Andy Shevchenko > Signed-off-by: Andy Shevchenko > Signed-off-by: Simon Glass > Tested-by: Andy Shevchenko > --- > (Now fixed - thank you Andy!) > > Make another attempt to land this. It apparently breaks Edison but I > cannot test that board, nor can I work out what is wrong with the code. > > Previous test report is here: > >https://lore.kernel.org/all/yga9z7sbfaev6...@smile.fi.intel.com/ > > Looking at the image, the method is definitely present: > >$ nm /tmp/b/edison/u-boot |grep acpi_writer >0115fde0 D _u_boot_list_2_acpi_writer_2_0base >0115fdf0 D _u_boot_list_2_acpi_writer_2_1facs >0115fe00 D _u_boot_list_2_acpi_writer_2_3dsdt >0115fe10 D _u_boot_list_2_acpi_writer_2_4gnvs >0115fe20 D _u_boot_list_2_acpi_writer_2_5csrt >0115fe30 D _u_boot_list_2_acpi_writer_2_5fadt >0115fe40 D _u_boot_list_2_acpi_writer_2_5mcfg >0115fe50 D _u_boot_list_2_acpi_writer_2_5spcr >0115fe60 D _u_boot_list_2_acpi_writer_2_5tcpa >0115fe70 D _u_boot_list_2_acpi_writer_2_5tpm2 >0115fe80 D _u_boot_list_2_acpi_writer_2_5x86 >0115fe90 D _u_boot_list_2_acpi_writer_2_6ssdt >0115fea0 D _u_boot_list_2_acpi_writer_2_8dev > > I wonder if the code in quark_write_fadt() is not being called? > > 'acpi list' shows what tables are installed. On minnowmax there is no > difference with or without this patch. Perhaps someone with sharper eyes > than me can figure this out? > > The mechanism is that the functions to be called are put in a linker list, > each element being declared using ACPI_WRITER(function_name). > > Then acpi_write_all() is called to write each one. Debugging could be > added to that function, perhaps? > > Changes in v3: > - None (just added the tags since patchwork doesn't do Co-developed-by) > > Changes in v2: > - Squash in the fix from Andy Shevchenko > > arch/x86/cpu/apollolake/acpi.c| 17 + > arch/x86/cpu/baytrail/acpi.c | 27 +++ > arch/x86/cpu/quark/acpi.c | 27 +++ > arch/x86/cpu/tangier/acpi.c | 27 +++ > arch/x86/include/asm/acpi_table.h | 2 -- > arch/x86/lib/acpi_table.c | 15 --- > 6 files changed, 70 insertions(+), 45 deletions(-) > series applied to u-boot-x86/next, thanks!
Re: [PATCH v3 2/2] x86: Prevent from missing the FADT chaining
On Sat, Sep 2, 2023 at 1:27 AM Simon Glass wrote: > > From: Andy Shevchenko > > Recent approach with FADT writer shows that there is > a room for subtle errors. Prevent this from happening > again by introducing acpi_add_fadt() helper. > > Signed-off-by: Andy Shevchenko > Signed-off-by: Simon Glass > --- > > (no changes since v1) > > arch/x86/cpu/apollolake/acpi.c | 6 +- > arch/x86/cpu/baytrail/acpi.c | 6 +- > arch/x86/cpu/quark/acpi.c | 6 +- > arch/x86/cpu/tangier/acpi.c| 6 +- > include/acpi/acpi_table.h | 7 +++ > 5 files changed, 11 insertions(+), 20 deletions(-) > Reviewed-by: Bin Meng
Re: [PATCH v1 1/2] TO BE FOLDED: x86: tangier: Add FADT to the chain
On Tue, Sep 19, 2023 at 3:28 PM Bin Meng wrote: > > Hi Andy, > > On Fri, Aug 25, 2023 at 9:52 PM Andy Shevchenko > wrote: > > > > The Simon's patch missed the FADT to be added to the chain, hence all > > the issues on Intel Tangier. > > > > Signed-off-by: Andy Shevchenko > > --- > > arch/x86/cpu/tangier/acpi.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/arch/x86/cpu/tangier/acpi.c b/arch/x86/cpu/tangier/acpi.c > > index 01b30553818c..ffaa56ab6f87 100644 > > --- a/arch/x86/cpu/tangier/acpi.c > > +++ b/arch/x86/cpu/tangier/acpi.c > > @@ -52,6 +52,8 @@ static int tangier_write_fadt(struct acpi_ctx *ctx, > > > > header->checksum = table_compute_checksum(fadt, header->length); > > > > + acpi_add_table(ctx, fadt); > > + > > acpi_inc(ctx, sizeof(struct acpi_fadt)); > > > > return 0; > > -- > > Which commit should we squash this patch in? > Ah, I see this patch is already included in Simon's patch: https://patchwork.ozlabs.org/project/uboot/patch/20230901112707.v3.1.I61008e563b1209243a9a7f2b66073b4737ff82d1@changeid/ I am going to apply Simon's patch unless you guys say I am looking at the wrong patch :) Regards, Bin
Re: [PATCH 1/2] Allow Python packages to be dropped
On Fri, Sep 1, 2023 at 3:13 AM Simon Glass wrote: > > Hi Tom, > > On Thu, 31 Aug 2023 at 11:48, Tom Rini wrote: > > > > On Thu, Aug 31, 2023 at 11:20:52AM -0600, Simon Glass wrote: > > > > > When building in a portage chroot, we do not have the environment needed > > > to build pylibfdt. It is instead build as a separate package. > > > > > > Provide a build option to tell U-Boot to skip this part of the build. We > > > still need it to use binman, etc. but don't need it to build its > > > dependencies. > > > > > > Signed-off-by: Simon Glass > > > Reviewed-by: Mike Frysinger > > > --- > > > > > > Makefile | 8 > > > > Can we do this via Kconfig instead? It looks like we don't need to do > > this part of the build for coreboot, yes? And so if we can drop it from > > other builds as well that might help speed up CI. > > Yes it could. But I really don't like changing the board config on the > fly - we have things like 'select BINMAN' now and it just gets messy. > In the normal course of events we want to build the python things and > the build won't work without it (e.g. binman will fail). But where the > build environment has installed binman separate, it knows better. > > So I don't think this is a board config thing, > > > > > [snip] > > > +The tools-only build bytes pylibfdt by default. To disable this, use the > > > > "build bytes" should probably be "builds" I suspect. > > Yes, thanks. > Corrected "build bytes" to "builds bytes", and series applied to u-boot-x86/next, thanks! Regards, Bin
Re: [PATCH v1 1/2] TO BE FOLDED: x86: tangier: Add FADT to the chain
Hi Andy, On Fri, Aug 25, 2023 at 9:52 PM Andy Shevchenko wrote: > > The Simon's patch missed the FADT to be added to the chain, hence all > the issues on Intel Tangier. > > Signed-off-by: Andy Shevchenko > --- > arch/x86/cpu/tangier/acpi.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/x86/cpu/tangier/acpi.c b/arch/x86/cpu/tangier/acpi.c > index 01b30553818c..ffaa56ab6f87 100644 > --- a/arch/x86/cpu/tangier/acpi.c > +++ b/arch/x86/cpu/tangier/acpi.c > @@ -52,6 +52,8 @@ static int tangier_write_fadt(struct acpi_ctx *ctx, > > header->checksum = table_compute_checksum(fadt, header->length); > > + acpi_add_table(ctx, fadt); > + > acpi_inc(ctx, sizeof(struct acpi_fadt)); > > return 0; > -- Which commit should we squash this patch in? Regards, Bin
Re: [PATCH v4 20/20] x86: doc: coreboot: Mention 64-bit Linux distros
On Thu, Aug 24, 2023 at 5:11 AM Simon Glass wrote: > > Add a little more detail as to why coreboot64 is preferred for booting > Linux distros. > > Signed-off-by: Simon Glass > --- > > (no changes since v2) > > Changes in v2: > - Add new patch > > doc/board/coreboot/coreboot.rst | 2 ++ > 1 file changed, 2 insertions(+) > Reviewed-by: Bin Meng
Re: [PATCH v4 11/20] efi: x86: Correct the condition for installing ACPI tables
On Thu, Aug 24, 2023 at 5:11 AM Simon Glass wrote: > > It is not always the case that U-Boot builds the ACPI tables itself. For > example, when booting from coreboot, the ACPI tables are built by > coreboot. > > Correct the Makefile condition so that U-Boot can pass on tables built > by a previous firmware stage. > > Tidy up the installation-condition code while we are here. > > Signed-off-by: Simon Glass > Reviewed-by: Ilias Apalodimas > --- > > (no changes since v2) > > Changes in v2: > - Add new patch > > lib/efi_loader/Makefile| 2 +- > lib/efi_loader/efi_setup.c | 10 +- > 2 files changed, 6 insertions(+), 6 deletions(-) > Reviewed-by: Bin Meng
Re: [PATCH v4 19/20] x86: doc: Split out manual booting into its own file
On Thu, Aug 24, 2023 at 5:11 AM Simon Glass wrote: > > Move this out of the main file since for simple users it is easier to > rely on standard boot. > > Signed-off-by: Simon Glass > --- > > (no changes since v2) > > Changes in v2: > - Add new patch > > doc/arch/x86/index.rst | 1 + > doc/arch/x86/manual_boot.rst | 276 +++ > doc/arch/x86/x86.rst | 272 +- > 3 files changed, 280 insertions(+), 269 deletions(-) > create mode 100644 doc/arch/x86/manual_boot.rst > Reviewed-by: Bin Meng
Re: [PATCH v4 18/20] x86: doc: Update summaries and add links
On Thu, Aug 24, 2023 at 5:11 AM Simon Glass wrote: > > Refresh the summary information so it is more up-to-date. Add links to > the coreboot and slimbootloader docs. > > Signed-off-by: Simon Glass > --- > > (no changes since v2) > > Changes in v2: > - Add new patch > > doc/arch/x86/x86.rst | 17 ++--- > 1 file changed, 10 insertions(+), 7 deletions(-) > Reviewed-by: Bin Meng
Re: [PATCH v4 17/20] x86: doc: Move into its own directory
On Thu, Aug 24, 2023 at 5:11 AM Simon Glass wrote:
>
> There is enough material that it makes sense to split this up into
> several files. Create an x86/ directory for this purpose.
>
> Signed-off-by: Simon Glass
> ---
>
> (no changes since v2)
>
> Changes in v2:
> - Add new patch
>
> doc/arch/index.rst | 2 +-
> doc/arch/x86/index.rst | 11 +++
> doc/arch/{ => x86}/x86.rst | 6 +++---
> 3 files changed, 15 insertions(+), 4 deletions(-)
> create mode 100644 doc/arch/x86/index.rst
> rename doc/arch/{ => x86}/x86.rst (99%)
>
Reviewed-by: Bin Meng
Re: [PATCH v4 16/20] x86: coreboot: Record the position of the SMBIOS tables
On Thu, Aug 24, 2023 at 5:11 AM Simon Glass wrote: > > Make a note of where coreboot installed the SMBIOS tables so that we can > pass this on to EFI. > > Signed-off-by: Simon Glass > --- > > (no changes since v2) > > Changes in v2: > - Add new patch > > arch/x86/lib/coreboot/cb_sysinfo.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/x86/lib/coreboot/cb_sysinfo.c > b/arch/x86/lib/coreboot/cb_sysinfo.c > index dfbc80c430e..f7fd9ea5bcb 100644 > --- a/arch/x86/lib/coreboot/cb_sysinfo.c > +++ b/arch/x86/lib/coreboot/cb_sysinfo.c > @@ -471,6 +471,7 @@ int get_coreboot_info(struct sysinfo_t *info) > return -ENOENT; > gd->arch.coreboot_table = addr; > gd_set_acpi_start(map_to_sysmem(info->rsdp)); > + gd_set_smbios_start(info->smbios_start); use map_to_sysmem() too? > gd->flags |= GD_FLG_SKIP_LL_INIT; > > return 0; > -- Reviewed-by: Bin Meng Regards, Bin
Re: [PATCH v4 14/20] Record the position of the SMBIOS tables
On Thu, Aug 24, 2023 at 5:11 AM Simon Glass wrote: > > Remember where these end up so that we can pass this information on to > the EFI layer. > > Signed-off-by: Simon Glass > --- > > Changes in v4: > - Fix arm and riscv > > Changes in v2: > - Add new patch > > arch/arm/include/asm/global_data.h | 3 +++ > arch/riscv/include/asm/global_data.h | 3 +++ > arch/sandbox/include/asm/global_data.h | 1 + > arch/x86/include/asm/global_data.h | 1 + > arch/x86/lib/tables.c | 3 +++ > include/asm-generic/global_data.h | 8 ++++ > 6 files changed, 19 insertions(+) > Reviewed-by: Bin Meng
Re: [PATCH v4 12/20] x86: smbios: Add a Kconfig indicating SMBIOS-table presence
On Thu, Aug 24, 2023 at 5:11 AM Simon Glass wrote: > > When booted from coreboot, U-Boot does not build the SMBIOS tables, but > it should still pass them on to the OS. Add a new option which indicates > whether SMBIOS tables are present, however they were built. > > Flip the ordering so that the dependency is listed first, which is less > confusing. > > Adjust GENERATE_SMBIOS_TABLE to depend on this new symbol. > > Signed-off-by: Simon Glass > Reviewed-by: Heinrich Schuchardt > --- > > (no changes since v3) > > Changes in v3: > - Allow SMBIOS if EFI_LOADER is enabled > - Reword the help > > Changes in v2: > - Add new patch > > lib/Kconfig | 15 ++++++- > 1 file changed, 14 insertions(+), 1 deletion(-) > Reviewed-by: Bin Meng
Re: [PATCH v4 10/20] x86: coreboot: Enable VIDEO_COPY
On Thu, Aug 24, 2023 at 5:11 AM Simon Glass wrote: > > At least on modern machines the write-back mechanism for the frame buffer > is quite slow when scrolling, since it must read the entire frame buffer > and write it back. > > Enable the VIDEO_COPY feature to resolve this problem. > > Signed-off-by: Simon Glass > --- > > (no changes since v1) > > arch/x86/dts/coreboot.dts| 1 + > configs/coreboot64_defconfig | 1 + > configs/coreboot_defconfig | 1 + > drivers/video/coreboot.c | 12 > 4 files changed, 15 insertions(+) > Reviewed-by: Bin Meng
Re: [PATCH v4 09/20] x86: coreboot: Align options between coreboot and coreboot64
On Thu, Aug 24, 2023 at 5:11 AM Simon Glass wrote: > > These two builds are similar but have some different options for not good > reason. Line them up to be as similar as possible. > > Signed-off-by: Simon Glass > --- > > (no changes since v2) > > Changes in v2: > - Update the malloc size too > > configs/coreboot64_defconfig | 7 +++ > configs/coreboot_defconfig | 9 - > 2 files changed, 7 insertions(+), 9 deletions(-) > Reviewed-by: Bin Meng
