Re: [PATCH 1/2] mach-snapdragon/mach-ipq40xx: fix, merge and refactoring
On Tue, Oct 25, 2022 at 3:31 AM Andrey Volkov wrote:
>
> SoC: qcom: Add missing Qualcomm's SOCs definitions to the arch KConfig
>
> From: Andrey VOLKOV
>
> Add APQ8016/APQ8096/QCS40X decls to the KConfig, convert SDM845 declaration
> to the hidden one (selected by target),
> and update mach-snapdragon/Makefile accordingly.
>
> Also move 'CONFIG_ARM64' choice to the new declarations, since 'Snapdragon'
> contains Cortex A7A members too.
>
> Signed-off-by: Andrey VOLKOV
I like this cleanup effort, however, can you rebase this to apply on the master?
I would like to use this as a base of moving IPQ40xx to use Linux DTS
and keep it in sync.
Regards,
Robert
> ---
> arch/arm/Kconfig |1 -
> arch/arm/mach-snapdragon/Kconfig | 23 +--
> arch/arm/mach-snapdragon/Makefile | 31
> ++---
> arch/arm/mach-snapdragon/pinctrl-snapdragon.c |2 +-
> drivers/reset/reset-qcom.c|2 +-
> 5 files changed, 40 insertions(+), 19 deletions(-)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 2e83394052..a25b7f6d99 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1098,7 +1098,6 @@ config ARCH_RMOBILE
>
> config ARCH_SNAPDRAGON
> bool "Qualcomm Snapdragon SoCs"
> -select ARM64
> select DM
> select DM_GPIO
> select DM_SERIAL
> diff --git a/arch/arm/mach-snapdragon/Kconfig
> b/arch/arm/mach-snapdragon/Kconfig
> index 092706..83dd2c07a1 100644
> --- a/arch/arm/mach-snapdragon/Kconfig
> +++ b/arch/arm/mach-snapdragon/Kconfig
> @@ -9,10 +9,27 @@ config SYS_MALLOC_F_LEN
> config SPL_SYS_MALLOC_F_LEN
> default 0x2000
>
> +config APQ8016
> +bool
> +select ARM64
> +default n
> +
> +config APQ8096
> +bool
> +select ARM64
> +default n
> +
> config SDM845
> -bool "Qualcomm Snapdragon 845 SoC"
> +bool
> +select ARM64
> +select LINUX_KERNEL_IMAGE_HEADER
> default n
> +
> +config QCS40X
> +bool
> +select ARM64
> select LINUX_KERNEL_IMAGE_HEADER
> +default n
>
> config LNX_KRNL_IMG_TEXT_OFFSET_BASE
> default 0x8000
> @@ -23,6 +40,7 @@ choice
> config TARGET_DRAGONBOARD410C
> bool "96Boards Dragonboard 410C"
> select BOARD_LATE_INIT
> +select APQ8016
> select ENABLE_ARM_SOC_BOOT0_HOOK
> help
>Support for 96Boards Dragonboard 410C. This board complies with
> @@ -37,6 +55,7 @@ config TARGET_DRAGONBOARD410C
>
> config TARGET_DRAGONBOARD820C
> bool "96Boards Dragonboard 820C"
> +select APQ8096
> help
>Support for 96Boards Dragonboard 820C. This board complies with
>96Board Open Platform Specifications. Features:
> @@ -71,7 +90,7 @@ config TARGET_STARQLTECHN
>
> config TARGET_QCS404EVB
> bool "Qualcomm Technologies, Inc. QCS404 EVB"
> -select LINUX_KERNEL_IMAGE_HEADER
> +select QCS40X
> help
>Support for Qualcomm Technologies, Inc. QCS404 evaluation board.
>Features:
> diff --git a/arch/arm/mach-snapdragon/Makefile
> b/arch/arm/mach-snapdragon/Makefile
> index cbaaf23f6b..00997196ab 100644
> --- a/arch/arm/mach-snapdragon/Makefile
> +++ b/arch/arm/mach-snapdragon/Makefile
> @@ -2,20 +2,23 @@
> #
> # (C) Copyright 2015 Mateusz Kulikowski
>
> +obj-y += clock-snapdragon.o
> +obj-y += pinctrl-snapdragon.o
> +
> obj-$(CONFIG_SDM845) += clock-sdm845.o
> obj-$(CONFIG_SDM845) += sysmap-sdm845.o
> obj-$(CONFIG_SDM845) += init_sdm845.o
> -obj-$(CONFIG_TARGET_DRAGONBOARD820C) += clock-apq8096.o
> -obj-$(CONFIG_TARGET_DRAGONBOARD820C) += sysmap-apq8096.o
> -obj-$(CONFIG_TARGET_DRAGONBOARD410C) += clock-apq8016.o
> -obj-$(CONFIG_TARGET_DRAGONBOARD410C) += sysmap-apq8016.o
> -obj-y += misc.o
> -obj-y += clock-snapdragon.o
> -obj-y += dram.o
> -obj-y += pinctrl-snapdragon.o
> -obj-y += pinctrl-apq8016.o
> -obj-y += pinctrl-apq8096.o
> -obj-y += pinctrl-qcs404.o
> -obj-y += pinctrl-sdm845.o
> -obj-$(CONFIG_TARGET_QCS404EVB) += clock-qcs404.o
> -obj-$(CONFIG_TARGET_QCS404EVB) += sysmap-qcs404.o
> +obj-$(CONFIG_SDM845) += pinctrl-sdm845.o
> +
> +obj-$(CONFIG_APQ8096) += clock-apq8096.o
> +obj-$(CONFIG_APQ8096) += sysmap-apq8096.o
> +obj-$(CONFIG_APQ8096) += pinctrl-apq8096.o
> +
> +obj-$(CONFIG_APQ8016) += clock-apq8016.o
> +obj-$(CONFIG_APQ8016) += sysmap-apq8016.o
> +obj-$(CONFIG_APQ8016) += pinctrl-apq8016.o
> +obj-$(CONFIG_APQ8016) += misc.o dram.o
> +
> +obj-$(CONFIG_QCS40X) += clock-qcs404.o
> +obj-$(CONFIG_QCS40X) += sysmap-qcs404.o
> +obj-$(CONFIG_QCS40X) += pinctrl-qcs404.o
> diff --git a/arch/arm/mach-snapdragon/pinctrl-snapdragon.c
> b/arch/arm/mach-snapdragon/pinctrl-snapdragon.c
> index ab884ab6bf..4ed4ab4d4c 100644
> --- a/arch/arm/mach-snapdragon/pinctrl-snapdragon.c
> +++ b/arch/arm/mach-snapdragon/pinctrl-snapdragon.c
> @@ -149,7 +149,7 @@ static const struct udevice_id msm_pinctrl_ids[] = {
> { }
> };
>
> -U_BOOT_DRIVER(pinctrl_snapdraon) = {
> +U_BOOT_DRIVER(pinctrl_snapdragon) =
Re: [PATCH] mx6cuboxi: migrate to DM_SERIAL
Hi Baruch, On Thu, Nov 3, 2022 at 1:04 PM Baruch Siach wrote: > > Add the needed DT overrides to enable UART in SPL. > > Cc: Fabio Estevam > Signed-off-by: Baruch Siach Thanks for the conversion: Reviewed-by: Fabio Estevam
[PATCH 2/2] wandboard: Select DM_SERIAL
From: Fabio Estevam The conversion to DM_SERIAL is mandatory, so select this option. Signed-off-by: Fabio Estevam --- configs/wandboard_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/wandboard_defconfig b/configs/wandboard_defconfig index 70b4cf9ffaa3..33d9db56e1cb 100644 --- a/configs/wandboard_defconfig +++ b/configs/wandboard_defconfig @@ -72,6 +72,7 @@ CONFIG_PINCTRL_IMX6=y CONFIG_DM_PMIC=y CONFIG_DM_PMIC_PFUZE100=y CONFIG_DM_SCSI=y +CONFIG_DM_SERIAL=y CONFIG_MXC_UART=y CONFIG_DM_THERMAL=y CONFIG_USB=y -- 2.25.1
[PATCH] wandboard: Pass mmc aliases
From: Fabio Estevam
Originally, the mmc aliases node was present in imx6qdl-wandboard.dtsi.
After the sync with Linux in commit d0399a46e7cd ("imx6dl/imx6qdl:
synchronise device trees with linux"), the aliases node is gone as
the upstream version does not have it.
This causes a regression in which the SD card cannot be found anymore:
Since commit the aliases node has been removed
U-Boot 2022.10-00999-gcca41ed3d63f-dirty (Nov 03 2022 - 22:07:38 -0300)
CPU: Freescale i.MX6QP rev1.0 at 792 MHz
Reset cause: POR
DRAM: 2 GiB
Core: 62 devices, 17 uclasses, devicetree: separate
PMIC: PFUZE100 ID=0x10
MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2
Loading Environment from MMC... MMC: no card present
*** Warning - No block device, using default environment
Fix it by passing the alias node in the u-boot.dtsi file to
restore the original behaviour where the SD card (esdhc3) was
mapped to mmc0.
Fixes: d0399a46e7cd ("imx6dl/imx6qdl: synchronise device trees with linux")
Signed-off-by: Fabio Estevam
---
arch/arm/dts/imx6dl-wandboard-revd1-u-boot.dtsi | 1 +
arch/arm/dts/imx6q-wandboard-revd1-u-boot.dtsi | 1 +
arch/arm/dts/imx6qdl-wandboard-u-boot.dtsi | 9 +
arch/arm/dts/imx6qp-wandboard-revd1-u-boot.dtsi | 1 +
4 files changed, 12 insertions(+)
create mode 100644 arch/arm/dts/imx6dl-wandboard-revd1-u-boot.dtsi
create mode 100644 arch/arm/dts/imx6q-wandboard-revd1-u-boot.dtsi
create mode 100644 arch/arm/dts/imx6qdl-wandboard-u-boot.dtsi
create mode 100644 arch/arm/dts/imx6qp-wandboard-revd1-u-boot.dtsi
diff --git a/arch/arm/dts/imx6dl-wandboard-revd1-u-boot.dtsi
b/arch/arm/dts/imx6dl-wandboard-revd1-u-boot.dtsi
new file mode 100644
index ..6785db754b79
--- /dev/null
+++ b/arch/arm/dts/imx6dl-wandboard-revd1-u-boot.dtsi
@@ -0,0 +1 @@
+#include "imx6qdl-wandboard-u-boot.dtsi"
diff --git a/arch/arm/dts/imx6q-wandboard-revd1-u-boot.dtsi
b/arch/arm/dts/imx6q-wandboard-revd1-u-boot.dtsi
new file mode 100644
index ..6785db754b79
--- /dev/null
+++ b/arch/arm/dts/imx6q-wandboard-revd1-u-boot.dtsi
@@ -0,0 +1 @@
+#include "imx6qdl-wandboard-u-boot.dtsi"
diff --git a/arch/arm/dts/imx6qdl-wandboard-u-boot.dtsi
b/arch/arm/dts/imx6qdl-wandboard-u-boot.dtsi
new file mode 100644
index ..46c4b3b31f4a
--- /dev/null
+++ b/arch/arm/dts/imx6qdl-wandboard-u-boot.dtsi
@@ -0,0 +1,9 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include "imx6qdl-u-boot.dtsi"
+
+/ {
+ aliases {
+ mmc0 =
+ };
+};
diff --git a/arch/arm/dts/imx6qp-wandboard-revd1-u-boot.dtsi
b/arch/arm/dts/imx6qp-wandboard-revd1-u-boot.dtsi
new file mode 100644
index ..6785db754b79
--- /dev/null
+++ b/arch/arm/dts/imx6qp-wandboard-revd1-u-boot.dtsi
@@ -0,0 +1 @@
+#include "imx6qdl-wandboard-u-boot.dtsi"
--
2.25.1
Re: Running u-boot standalone hello_world on an image partition with qemu
Hi Simon, Thanks for getting back to me I'm developing on an ubuntu x86 machine, trying to run the u-boot hello_world standalone application which resides on an image |sd.img| which contains a partition I've compiled u-boot (|v2022.10|) with |qemu-x86_64_defconfig| I run qemu with "|qemu-system-x86_64 -m 1024 -nographic -bios u-boot.rom -drive format=raw,file=sd.img"| u-boot starts up, doesn't find a script, doesn't detect tftp, and awaits a command. If I type |"ext4ls ide 0:1|", I can clearly see hello_world.bin (|3932704 hello_world.bin|). When I do a |ext4load ide 0:1 0x4 hello_world.bin| (in preparation for |go 4 This is another test|), qemu/u-boot restarts. 0x4 is the |CONFIG_STANDALONE_LOAD_ADDR| for x86. I have also tried making an image of hello_world |"mkimage -n "Hello stand alone" -A x86_64 -O u-boot -T standalone -C none -a 0x4 -d hello_world.bin -v hello_world.img|" and tried to load the image into 0x4 with the intention of using |bootm| in case of cache issues - qemu/u-boot still resets. Could anyone possibly point out the basic mistake I'm making? Is the app linked to start at that address. Could you try 'dcache off' before the 'go'? Do you have a debugger? The standalone Makefile sets up the start address at 0x4 (CONFIG_STANDALONE_LOAD_ADDR), so I'm assuming that hello_world.bin is correctly linked to that address. I'm unable to even try 'dcache off' before 'go' as the 'ext4load' at CONFIG_STANDALONE_LOAD_ADDR causes a restart. As I mentioned to Tom Rini, all I'm trying to do at the moment is develop a standalone program using u-boot and qemu on my x86 ubuntu machine and then target a platform (riscv or arm) at a later date. Thanks again for your reply Nick
Re: Running u-boot standalone hello_world on an image partition with qemu
Hi Tom, Thanks for getting back to me I'm developing on an ubuntu x86 machine, trying to run the u-boot hello_world standalone application which resides on an image |sd.img| which contains a partition I've compiled u-boot (|v2022.10|) with |qemu-x86_64_defconfig| I run qemu with "|qemu-system-x86_64 -m 1024 -nographic -bios u-boot.rom -drive format=raw,file=sd.img"| u-boot starts up, doesn't find a script, doesn't detect tftp, and awaits a command. If I type |"ext4ls ide 0:1|", I can clearly see hello_world.bin (|3932704 hello_world.bin|). When I do a |ext4load ide 0:1 0x4 hello_world.bin| (in preparation for |go 4 This is another test|), qemu/u-boot restarts. 0x4 is the |CONFIG_STANDALONE_LOAD_ADDR| for x86. I have also tried making an image of hello_world |"mkimage -n "Hello stand alone" -A x86_64 -O u-boot -T standalone -C none -a 0x4 -d hello_world.bin -v hello_world.img|" and tried to load the image into 0x4 with the intention of using |bootm| in case of cache issues - qemu/u-boot still resets. Could anyone possibly point out the basic mistake I'm making? Using the standalone API on platforms where we support UEFI applications is strongly discouraged. If some part of the UEFI support in U-Boot is lacking for your use case we strongly encourage patches adding support for that (as we're doing right now for enhancing SPI support). All I'm trying to do at the moment is develop a standalone program usingqemu (with -kvm) on my x86 ubuntu machine and then target a platform (riscv or arm) at a later date. The instructions in Readme.standalone, loading at a load address of 0x4, cause a restart of the boot process - mind you saying that, loading to a higher address (say 0x100) works but I'm unable to perform a 'go' as the non-relocatable standalone needs to be at 0x4 (CONFIG_STANDALONE_LOAD_ADDR) If you can suggest a way forward for developing a u-boot standalone on an x86 machine, I would be hugely grateful! Thanks again Nick
Re: [PATCH v1] power: regulator: Add support for NPCM845
Hi Jaehoon
Thanks for your review.
and sorry for regulator-force-microvolt. It's a wrong description for
this driver.
The driver followed normal property use
-regulator-min-microvolt
-regulator-max-microvolt
It is our npcm845 bmc feature and no pmic for this regulator.
i will followed your suggestion to modify and upstream v2 patch.
Your comments are all welcome.
Best regards,
Jim
On Thu, Nov 3, 2022 at 6:14 AM Jaehoon Chung wrote:
>
> Hi,
>
> > -Original Message-
> > From: Jim Liu [mailto:jim.t90...@gmail.com]
> > Sent: Tuesday, November 1, 2022 11:21 AM
> > To: jim.t90...@gmail.com; jjl...@nuvoton.com; ys...@nuvoton.com;
> > kw...@nuvoton.com;
> > jh80.ch...@samsung.com
> > Cc: u-boot@lists.denx.de
> > Subject: [PATCH v1] power: regulator: Add support for NPCM845
> >
> > Add support for setting NPCM845 voltage supply
> >
> > regulator-force-microvolt is npcm proprietary property to
> > set the voltage level.
>
> What is regulator-force-microvolt. I didn't find this property in u-boot /
> kernel side.
> If I missed something, could you explain it?
>
> And Is there no pmic for this regulator?
>
> >
> > Signed-off-by: Jim Liu
> > ---
> > drivers/power/regulator/Kconfig | 8 ++
> > drivers/power/regulator/Makefile| 1 +
> > drivers/power/regulator/npcm8xx_regulator.c | 133
> > 3 files changed, 142 insertions(+)
> > create mode 100644 drivers/power/regulator/npcm8xx_regulator.c
> >
> > diff --git a/drivers/power/regulator/Kconfig
> > b/drivers/power/regulator/Kconfig
> > index c519e066ef..e5f06874de 100644
> > --- a/drivers/power/regulator/Kconfig
> > +++ b/drivers/power/regulator/Kconfig
> > @@ -128,6 +128,14 @@ config DM_REGULATOR_MAX77686
> > features for REGULATOR MAX77686. The driver implements get/set api
> > for:
> > value, enable and mode.
> >
> > +config DM_REGULATOR_NPCM8XX
> > + bool "Enable driver for NPCM8xx voltage supply"
>
> "Enable Driver Model for "
>
>
> > + depends on DM_REGULATOR && ARCH_NPCM8XX
> > + help
> > + Enable support for configuring voltage supply on NPCM8XX SoC. The
> > + voltage supplies support two voltage levels and the driver
> > implements
> > + get/set api for setting the value.
> > +
> > config DM_REGULATOR_FAN53555
> > bool "Enable Driver Model for REGULATOR FAN53555"
> > depends on DM_PMIC_FAN53555
> > diff --git a/drivers/power/regulator/Makefile
> > b/drivers/power/regulator/Makefile
> > index bc736068bc..68e4c0f9dd 100644
> > --- a/drivers/power/regulator/Makefile
> > +++ b/drivers/power/regulator/Makefile
> > @@ -9,6 +9,7 @@ obj-$(CONFIG_REGULATOR_ACT8846) += act8846.o
> > obj-$(CONFIG_REGULATOR_AS3722) += as3722_regulator.o
> > obj-$(CONFIG_$(SPL_)DM_REGULATOR_DA9063) += da9063.o
> > obj-$(CONFIG_DM_REGULATOR_MAX77686) += max77686.o
> > +obj-$(CONFIG_DM_REGULATOR_NPCM8XX) += npcm8xx_regulator.o
> > obj-$(CONFIG_$(SPL_)DM_PMIC_PFUZE100) += pfuze100.o
> > obj-$(CONFIG_$(SPL_)DM_REGULATOR_BD71837) += bd71837.o
> > obj-$(CONFIG_$(SPL_)DM_REGULATOR_PCA9450) += pca9450.o
> > diff --git a/drivers/power/regulator/npcm8xx_regulator.c
> > b/drivers/power/regulator/npcm8xx_regulator.c
> > new file mode 100644
> > index 00..7903287132
> > --- /dev/null
> > +++ b/drivers/power/regulator/npcm8xx_regulator.c
> > @@ -0,0 +1,133 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright (c) 2022 Nuvoton Technology Corp.
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#define REG_VSRCR0xf08000e8 /* Voltage Supply Control Register */
> > +
> > +/* Supported voltage levels (uV) */
> > +static const u32 volts_type1[] = { 330, 180 };
> > +static const u32 volts_type2[] = { 100, 180 };
> > +#define VOLT_LEV00
> > +#define VOLT_LEV11
> > +
> > +struct volt_supply {
> > + char *name;
> > + const u32 *volts;
> > + u32 reg_shift; /* Register bit offset for setting voltage */
> > +};
> > +
> > +static const struct volt_supply npcm8xx_volt_supps[] = {
> > + {"v1", volts_type1, 0},
> > + {"v2", volts_type1, 1},
> > + {"v3", volts_type1, 2},
> > + {"v4", volts_type1, 3},
> > + {"v5", volts_type1, 4},
> > + {"v6", volts_type1, 5},
> > + {"v7", volts_type1, 6},
> > + {"v8", volts_type1, 7},
> > + {"v9", volts_type1, 8},
> > + {"v10", volts_type1, 9},
> > + {"v11", volts_type2, 10},
> > + {"v12", volts_type1, 11},
> > + {"v13", volts_type1, 12},
> > + {"v14", volts_type2, 13},
> > + {"vsif", volts_type1, 14},
> > + {"vr2", volts_type1, 30},
> > +};
> > +
> > +static const struct volt_supply *npcm8xx_volt_supply_get(const char *name)
> > +{
> > + int i;
> > +
> > + for (i = 0; i < ARRAY_SIZE(npcm8xx_volt_supps); i++) {
> > + if (!strcmp(npcm8xx_volt_supps[i].name, name))
> > + return _volt_supps[i];
> > + }
> > +
> > +
[PATCH v3 3/3] efi_loader: Let networking support depend on NETDEVICES
From: Jan Kiszka
CONFIG_NET does not imply that there are actually network devices
available. Neither does CONFIG_NETDEVICES, but it is much closer, and
changing to this dependency obsoletes the check in Kconfig because it
means DM_ETH.
Along this change, make sure that efi_net_set_dhcp_ack is always
defined, at least as stub.
Suggested-by: Tom Rini
Signed-off-by: Jan Kiszka
---
include/efi_loader.h | 10 +++---
lib/efi_loader/Kconfig | 1 -
lib/efi_loader/Makefile | 2 +-
lib/efi_loader/efi_device_path.c | 8 +++-
lib/efi_loader/efi_setup.c | 10 +-
lib/efi_selftest/Makefile| 2 +-
6 files changed, 17 insertions(+), 16 deletions(-)
diff --git a/include/efi_loader.h b/include/efi_loader.h
index 0c6c95ba464..43816491a23 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -94,8 +94,6 @@ void efi_restore_gd(void);
/* Call this to set the current device name */
void efi_set_bootdev(const char *dev, const char *devnr, const char *path,
void *buffer, size_t buffer_size);
-/* Called by networking code to memorize the dhcp ack package */
-void efi_net_set_dhcp_ack(void *pkt, int len);
/* Print information about all loaded images */
void efi_print_image_infos(void *pc);
@@ -118,7 +116,6 @@ static inline void efi_restore_gd(void) { }
static inline void efi_set_bootdev(const char *dev, const char *devnr,
const char *path, void *buffer,
size_t buffer_size) { }
-static inline void efi_net_set_dhcp_ack(void *pkt, int len) { }
static inline void efi_print_image_infos(void *pc) { }
static inline efi_status_t efi_launch_capsules(void)
{
@@ -127,6 +124,13 @@ static inline efi_status_t efi_launch_capsules(void)
#endif /* CONFIG_IS_ENABLED(EFI_LOADER) */
+#if CONFIG_IS_ENABLED(EFI_LOADER) && CONFIG_IS_ENABLED(NETDEVICES)
+/* Called by networking code to memorize the dhcp ack package */
+void efi_net_set_dhcp_ack(void *pkt, int len);
+#else
+static inline void efi_net_set_dhcp_ack(void *pkt, int len) { }
+#endif
+
/* Maximum number of configuration tables */
#define EFI_MAX_CONFIGURATION_TABLES 16
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index 41756ea5396..68e6c2531e1 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -11,7 +11,6 @@ config EFI_LOADER
# We need EFI_STUB_32BIT to be set on x86_32 with EFI_STUB
depends on !EFI_STUB || !X86 || X86_64 || EFI_STUB_32BIT
depends on BLK
- depends on DM_ETH || !NET
depends on !EFI_APP
default y if !ARM || SYS_CPU = armv7 || SYS_CPU = armv8
select CHARSET
diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
index f8e8afe1284..8738757dd2c 100644
--- a/lib/efi_loader/Makefile
+++ b/lib/efi_loader/Makefile
@@ -68,7 +68,7 @@ obj-y += efi_watchdog.o
obj-$(CONFIG_EFI_ESRT) += efi_esrt.o
obj-$(CONFIG_VIDEO) += efi_gop.o
obj-$(CONFIG_BLK) += efi_disk.o
-obj-$(CONFIG_NET) += efi_net.o
+obj-$(CONFIG_NETDEVICES) += efi_net.o
obj-$(CONFIG_GENERATE_ACPI_TABLE) += efi_acpi.o
obj-$(CONFIG_GENERATE_SMBIOS_TABLE) += efi_smbios.o
obj-$(CONFIG_EFI_RNG_PROTOCOL) += efi_rng.o
diff --git a/lib/efi_loader/efi_device_path.c b/lib/efi_loader/efi_device_path.c
index acae007f26f..171ee2b4679 100644
--- a/lib/efi_loader/efi_device_path.c
+++ b/lib/efi_loader/efi_device_path.c
@@ -613,7 +613,7 @@ __maybe_unused static void *dp_fill(void *buf, struct
udevice *dev)
*vdp = ROOT;
return [1];
}
-#ifdef CONFIG_NET
+#ifdef CONFIG_NETDEVICES
case UCLASS_ETH: {
struct efi_device_path_mac_addr *dp =
dp_fill(buf, dev->parent);
@@ -1052,7 +1052,7 @@ struct efi_device_path *efi_dp_from_uart(void)
return buf;
}
-#ifdef CONFIG_NET
+#ifdef CONFIG_NETDEVICES
struct efi_device_path *efi_dp_from_eth(void)
{
void *buf, *start;
@@ -1169,10 +1169,8 @@ efi_status_t efi_dp_from_name(const char *dev, const
char *devnr,
return EFI_INVALID_PARAMETER;
if (!strcmp(dev, "Net")) {
-#ifdef CONFIG_NET
- if (device)
+ if (CONFIG_IS_ENABLED(NETDEVICES) && device)
*device = efi_dp_from_eth();
-#endif
} else if (!strcmp(dev, "Uart")) {
if (device)
*device = efi_dp_from_uart();
diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c
index a340bc38806..cec799d93e2 100644
--- a/lib/efi_loader/efi_setup.c
+++ b/lib/efi_loader/efi_setup.c
@@ -331,11 +331,11 @@ efi_status_t efi_init_obj_list(void)
if (ret != EFI_SUCCESS)
goto out;
}
-#ifdef CONFIG_NET
- ret = efi_net_register();
- if (ret != EFI_SUCCESS)
- goto out;
-#endif
+ if (IS_ENABLED(CONFIG_NETDEVICES)) {
+ ret = efi_net_register();
+ if (ret !=
[PATCH v3 1/3] efi_loader: Avoid overwriting previous outputs on console screen clearing
From: Jan Kiszka
Before clearing the screen, ensure that no previous output of firmware
or UEFI programs will be overwritten on serial devices or other
streaming consoles. This helps generating complete boot logs.
Tested regarding multi-output against qemu-x86_defconfig.
Signed-off-by: Jan Kiszka
---
lib/efi_loader/efi_console.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c
index 4d08dd3763a..6ce0fcc168d 100644
--- a/lib/efi_loader/efi_console.c
+++ b/lib/efi_loader/efi_console.c
@@ -461,10 +461,16 @@ static efi_status_t EFIAPI efi_cout_set_attribute(
}
/**
- * efi_cout_clear_screen() - clear screen
+ * efi_clear_screen() - clear screen
*/
static void efi_clear_screen(void)
{
+ unsigned int row;
+
+ /* Avoid overwriting previous outputs on streaming consoles */
+ for (row = 1; row < efi_cout_modes[efi_con_mode.mode].rows; row++)
+ printf("\n");
+
/*
* The Linux console wants both a clear and a home command. The video
* uclass does not support [H without coordinates, yet.
--
2.35.3
[PATCH v3 0/3] efi_loader: console and network dependency improvements
Update of previously sent patches "efi_loader: Improve console screen clearing and reset" "efi_loader: Let networking support depend on NETDEVICES" bundled into one series. Changes to earlier versions: - rebased console reset improvements over master - split up into overwrite protection and background color fix - addressed missing efi_net_set_dhcp_ack symbol - converted some #ifdefs to CONFIG_IS_ENABLED Jan Jan Kiszka (3): efi_loader: Avoid overwriting previous outputs on console screen clearing efi_loader: Set default console colors on efi_cout_clear_screen if needed efi_loader: Let networking support depend on NETDEVICES include/efi_loader.h | 10 +++--- lib/efi_loader/Kconfig | 1 - lib/efi_loader/Makefile | 2 +- lib/efi_loader/efi_console.c | 14 +- lib/efi_loader/efi_device_path.c | 8 +++- lib/efi_loader/efi_setup.c | 10 +- lib/efi_selftest/Makefile| 2 +- 7 files changed, 30 insertions(+), 17 deletions(-) -- 2.35.3
[PATCH v3 2/3] efi_loader: Set default console colors on efi_cout_clear_screen if needed
From: Jan Kiszka
Ensures a consistent background color of the whole screen for succeeding
outputs as both demanded by the spec and implemented in EDK2 as well.
Signed-off-by: Jan Kiszka
---
lib/efi_loader/efi_console.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c
index 6ce0fcc168d..4228a509caf 100644
--- a/lib/efi_loader/efi_console.c
+++ b/lib/efi_loader/efi_console.c
@@ -495,6 +495,12 @@ static efi_status_t EFIAPI efi_cout_clear_screen(
{
EFI_ENTRY("%p", this);
+ /* Set default colors if not done yet */
+ if (efi_con_mode.attribute == 0) {
+ efi_con_mode.attribute = 0x07;
+ printf(ESC "[0;37;40m");
+ }
+
efi_clear_screen();
return EFI_EXIT(EFI_SUCCESS);
--
2.35.3
Re: [PATCH 1/1] efi_loader: avoid EFI_CALL() for clearing screen
On 04.11.22 08:25, Jan Kiszka wrote:
> On 15.10.22 12:15, Heinrich Schuchardt wrote:
>> Carve out function efi_clear_screen.
>>
>
> This does not motivate *why* you prefer to not use efi_cout_clear_screen
> anymore.
Why this in principle still hold...
>
> A side effect of this is that the screen will not longer be filled with
> a new background color, leading to lines that are written with that new
> background but only for the actual text length. Attached a screenshot to
> visualize this. Was that intended? Not saying it's necessarily critical.
...strike that: I lost some bits from my "efi_loader: Improve console
screen clearing and reset" patch while rebasing, and those were
responsible for also setting the background color consistently. Seems I
need to work on my own commit message too.
Jan
>
> Jan
>
> PS: This is with proper console scrolling in place to avoid overwriting.
> Will send an update of my related patch soon.
>
>> Signed-off-by: Heinrich Schuchardt
>> ---
>> lib/efi_loader/efi_console.c | 26 +-
>> 1 file changed, 17 insertions(+), 9 deletions(-)
>>
>> diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c
>> index 3354b217a9..6d4784e140 100644
>> --- a/lib/efi_loader/efi_console.c
>> +++ b/lib/efi_loader/efi_console.c
>> @@ -460,6 +460,20 @@ static efi_status_t EFIAPI efi_cout_set_attribute(
>> return EFI_EXIT(EFI_SUCCESS);
>> }
>>
>> +/**
>> + * efi_cout_clear_screen() - clear screen
>> + */
>> +static void efi_clear_screen(void)
>> +{
>> +/*
>> + * The Linux console wants both a clear and a home command. The video
>> + * uclass does not support [H without coordinates, yet.
>> + */
>> +printf(ESC "[2J" ESC "[1;1H");
>> +efi_con_mode.cursor_column = 0;
>> +efi_con_mode.cursor_row = 0;
>> +}
>> +
>> /**
>> * efi_cout_clear_screen() - clear screen
>> *
>> @@ -475,13 +489,7 @@ static efi_status_t EFIAPI efi_cout_clear_screen(
>> {
>> EFI_ENTRY("%p", this);
>>
>> -/*
>> - * The Linux console wants both a clear and a home command. The video
>> - * uclass does not support [H without coordinates, yet.
>> - */
>> -printf(ESC "[2J" ESC "[1;1H");
>> -efi_con_mode.cursor_column = 0;
>> -efi_con_mode.cursor_row = 0;
>> +efi_clear_screen();
>>
>> return EFI_EXIT(EFI_SUCCESS);
>> }
>> @@ -510,7 +518,7 @@ static efi_status_t EFIAPI efi_cout_set_mode(
>> return EFI_EXIT(EFI_UNSUPPORTED);
>>
>> efi_con_mode.mode = mode_number;
>> -EFI_CALL(efi_cout_clear_screen(this));
>> +efi_clear_screen();
>>
>> return EFI_EXIT(EFI_SUCCESS);
>> }
>> @@ -536,7 +544,7 @@ static efi_status_t EFIAPI efi_cout_reset(
>> efi_con_mode.attribute = 0x07;
>> printf(ESC "[0;37;40m");
>> /* Clear screen */
>> -EFI_CALL(efi_cout_clear_screen(this));
>> +efi_clear_screen();
>>
>> return EFI_EXIT(EFI_SUCCESS);
>> }
>
--
Siemens AG, Technology
Competence Center Embedded Linux
[PATCH v3 1/1] usb: storage: continue probe on "Invalid device"
Fixes a crash during probing of sd card readers without medium present. Seen with the device below but reported for many other devices. idVendor 0x0bda Realtek Semiconductor Corp. idProduct 0x0326 Card reader bcdDevice 11.24 iManufacturer 1 Realtek iProduct2 USB3.0 Card Reader iSerial 3 201404081410 Link: https://github.com/AsahiLinux/linux/issues/44 Link: https://lists.denx.de/pipermail/u-boot/2022-July/489717.html Signed-off-by: Janne Grunau Reviewed-by: Simon Glass Reviewed-by: Marek Vasut --- common/usb_storage.c | 1 + 1 file changed, 1 insertion(+) diff --git a/common/usb_storage.c b/common/usb_storage.c index eaa31374ef73..f9204552a683 100644 --- a/common/usb_storage.c +++ b/common/usb_storage.c @@ -239,6 +239,7 @@ static int usb_stor_probe_device(struct usb_device *udev) ret = device_unbind(dev); if (ret) return ret; + continue; } ret = blk_probe_or_unbind(dev); -- 2.37.4
Re: [PATCH v2 1/1] usb: storage: continue probe on "Invalid device"
On 2022-11-03 23:23:52 +0100, Marek Vasut wrote: > On 11/3/22 22:36, Janne Grunau wrote: > > On 2022-09-28 04:20:52 -0600, Simon Glass wrote: > > > +Marek Vasut > > > +Tom Rini > > > > > > On Sun, 25 Sept 2022 at 23:07, Janne Grunau wrote: > > > > > > > > On 2022-08-10 21:54:22 +0200, Janne Grunau wrote: > > > > > Fixes a crash during probing of sd card readers without medium > > > > > present. > > > > > > > > > > Link: https://github.com/AsahiLinux/linux/issues/44 > > > > > Link: https://lists.denx.de/pipermail/u-boot/2022-July/489717.html > > > > > Signed-off-by: Janne Grunau > > > > > --- > > > > > Changes since v1: > > > > > - changed unconditiona return to "continue" as proposed by AKASHI > > > > > Takahiro > > > > > > > > > > common/usb_storage.c | 1 + > > > > > 1 file changed, 1 insertion(+) > > > > > > > > > > diff --git a/common/usb_storage.c b/common/usb_storage.c > > > > > index eaa31374ef73..f9204552a683 100644 > > > > > --- a/common/usb_storage.c > > > > > +++ b/common/usb_storage.c > > > > > @@ -239,6 +239,7 @@ static int usb_stor_probe_device(struct > > > > > usb_device *udev) > > > > >ret = device_unbind(dev); > > > > >if (ret) > > > > >return ret; > > > > > + continue; > > > > >} > > > > > > > > > >ret = blk_probe_or_unbind(dev); > > > > > > > > ping. Is there anything holding up merging this fix? > > > > ping2 > > > > This fixes a 100% reproducible crash when an USB storage device with > > "medium not ready" is connected. > > Can you please CC me next time when submitting these kinds of USB fixes ? sure, the cc list was the get_maintainers.pl output. > Also, can you tell which device this is ? I don't think the device matters but I'm seeing this problem with Bus 002 Device 005: ID 0bda:0326 Realtek Semiconductor Corp. Card reader Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 3.00 bDeviceClass0 bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 9 idVendor 0x0bda Realtek Semiconductor Corp. idProduct 0x0326 Card reader bcdDevice 11.24 iManufacturer 1 Realtek iProduct2 USB3.0 Card Reader iSerial 3 201404081410 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x002c bNumInterfaces 1 bConfigurationValue 1 iConfiguration 4 CARD READER bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 800mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 80 Bulk-Only iInterface 5 Bulk-In, Bulk-Out, Interface Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 7 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 7 Binary Object Store Descriptor: bLength 5 bDescriptorType15 wTotalLength 0x0016 bNumDeviceCaps 2 USB 2.0 Extension Device Capability: bLength 7 bDescriptorType16 bDevCapabilityType 2 bmAttributes 0xf41e BESL Link Power Management (LPM) Supported BESL value 1024 us Deep BESL value61440 us SuperSpeed USB Device Capability: bLength10 bDescriptorType16 bDevCapabilityType 3 bmAttributes 0x02 Latency Tolerance Messages (LTM) Supported wSpeedsSupported 0x000e Device can operate at Full Speed (12Mbps) Device can operate at High Speed (480Mbps) Device can operate at SuperSpeed (5Gbps) bFunctionalitySupport 1 Lowest fully-functional device speed is Full Speed (12Mbps) bU1DevExitLat 10 micro seconds bU2DevExitLat1023 micro seconds can't get debug descriptor: Resource temporarily unavailable Device Status: 0x001c (Bus
Re: [PATCH 1/1] efi_loader: avoid EFI_CALL() for clearing screen
On 15.10.22 12:15, Heinrich Schuchardt wrote:
> Carve out function efi_clear_screen.
>
This does not motivate *why* you prefer to not use efi_cout_clear_screen
anymore.
A side effect of this is that the screen will not longer be filled with
a new background color, leading to lines that are written with that new
background but only for the actual text length. Attached a screenshot to
visualize this. Was that intended? Not saying it's necessarily critical.
Jan
PS: This is with proper console scrolling in place to avoid overwriting.
Will send an update of my related patch soon.
> Signed-off-by: Heinrich Schuchardt
> ---
> lib/efi_loader/efi_console.c | 26 +-
> 1 file changed, 17 insertions(+), 9 deletions(-)
>
> diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c
> index 3354b217a9..6d4784e140 100644
> --- a/lib/efi_loader/efi_console.c
> +++ b/lib/efi_loader/efi_console.c
> @@ -460,6 +460,20 @@ static efi_status_t EFIAPI efi_cout_set_attribute(
> return EFI_EXIT(EFI_SUCCESS);
> }
>
> +/**
> + * efi_cout_clear_screen() - clear screen
> + */
> +static void efi_clear_screen(void)
> +{
> + /*
> + * The Linux console wants both a clear and a home command. The video
> + * uclass does not support [H without coordinates, yet.
> + */
> + printf(ESC "[2J" ESC "[1;1H");
> + efi_con_mode.cursor_column = 0;
> + efi_con_mode.cursor_row = 0;
> +}
> +
> /**
> * efi_cout_clear_screen() - clear screen
> *
> @@ -475,13 +489,7 @@ static efi_status_t EFIAPI efi_cout_clear_screen(
> {
> EFI_ENTRY("%p", this);
>
> - /*
> - * The Linux console wants both a clear and a home command. The video
> - * uclass does not support [H without coordinates, yet.
> - */
> - printf(ESC "[2J" ESC "[1;1H");
> - efi_con_mode.cursor_column = 0;
> - efi_con_mode.cursor_row = 0;
> + efi_clear_screen();
>
> return EFI_EXIT(EFI_SUCCESS);
> }
> @@ -510,7 +518,7 @@ static efi_status_t EFIAPI efi_cout_set_mode(
> return EFI_EXIT(EFI_UNSUPPORTED);
>
> efi_con_mode.mode = mode_number;
> - EFI_CALL(efi_cout_clear_screen(this));
> + efi_clear_screen();
>
> return EFI_EXIT(EFI_SUCCESS);
> }
> @@ -536,7 +544,7 @@ static efi_status_t EFIAPI efi_cout_reset(
> efi_con_mode.attribute = 0x07;
> printf(ESC "[0;37;40m");
> /* Clear screen */
> - EFI_CALL(efi_cout_clear_screen(this));
> + efi_clear_screen();
>
> return EFI_EXIT(EFI_SUCCESS);
> }
--
Siemens AG, Technology
Competence Center Embedded Linux
