[PATCH 1/2] usb: gadget: Add a config option to set the SPL product ID
It might be desirable to have a different product ID for the SPL
gadget. Several boards use dubious hack to achieve this like adding an
hardcoded offset to the configurable main product ID.
Add a new config option to set the product ID to use in the SPL and
use it in the ethernet and download gadgets.
Signed-off-by: Alban Bedel
---
common/spl/Kconfig | 6 ++
drivers/usb/gadget/ether.c | 2 +-
drivers/usb/gadget/g_dnl.c | 2 +-
3 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index ac61b25a0660..196f3cfc5558 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -1182,6 +1182,12 @@ config SPL_USB_GADGET
if SPL_USB_GADGET
+config SPL_USB_GADGET_PRODUCT_NUM
+ hex "Product ID of the SPL USB device"
+ default 0x0
+ help
+ Product ID of the USB device emulated in SPL, reported to the host
device.
+
config SPL_USB_ETHER
bool "Support USB Ethernet drivers"
depends on SPL_NET
diff --git a/drivers/usb/gadget/ether.c b/drivers/usb/gadget/ether.c
index 430732865723..18195d3ee19b 100644
--- a/drivers/usb/gadget/ether.c
+++ b/drivers/usb/gadget/ether.c
@@ -2078,7 +2078,7 @@ static int eth_bind(struct usb_gadget *gadget)
device_desc.idVendor
__constant_cpu_to_le16(CONFIG_USB_GADGET_VENDOR_NUM);
device_desc.idProduct -
__constant_cpu_to_le16(CONFIG_USB_GADGET_PRODUCT_NUM);
+
__constant_cpu_to_le16(CONFIG_VAL(USB_GADGET_PRODUCT_NUM));
#else
device_desc.idVendor
__constant_cpu_to_le16(RNDIS_VENDOR_NUM);
diff --git a/drivers/usb/gadget/g_dnl.c b/drivers/usb/gadget/g_dnl.c
index afb7b74f3057..85297cc0e501 100644
--- a/drivers/usb/gadget/g_dnl.c
+++ b/drivers/usb/gadget/g_dnl.c
@@ -63,7 +63,7 @@ static struct usb_device_descriptor device_desc = {
.bDeviceSubClass = 0, /*0x02:CDC-modem , 0x00:CDC-serial*/
.idVendor = __constant_cpu_to_le16(CONFIG_USB_GADGET_VENDOR_NUM),
- .idProduct = __constant_cpu_to_le16(CONFIG_USB_GADGET_PRODUCT_NUM),
+ .idProduct = __constant_cpu_to_le16(CONFIG_VAL(USB_GADGET_PRODUCT_NUM)),
/* .iProduct = DYNAMIC */
/* .iSerialNumber = DYNAMIC */
.bNumConfigurations = 1,
--
2.32.0
smime.p7s
Description: S/MIME cryptographic signature
[PATCH] usb: dwc3-generic: Fix the iMX8MQ support
The binding of iMX8MQ USB controller doesn't use child nodes like the
other devices supported in this driver. To support it split the child
nodes parsing to its own function and add a field to the platform data
to indicate that we should just use the top node.
Signed-off-by: Alban Bedel
---
drivers/usb/dwc3/dwc3-generic.c | 95 +++--
1 file changed, 56 insertions(+), 39 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-generic.c b/drivers/usb/dwc3/dwc3-generic.c
index 01bd0ca190e3..defef43ff503 100644
--- a/drivers/usb/dwc3/dwc3-generic.c
+++ b/drivers/usb/dwc3/dwc3-generic.c
@@ -221,6 +221,7 @@ U_BOOT_DRIVER(dwc3_generic_host) = {
struct dwc3_glue_ops {
void (*select_dr_mode)(struct udevice *dev, int index,
enum usb_dr_mode mode);
+ int single_node;
};
void dwc3_ti_select_dr_mode(struct udevice *dev, int index,
@@ -307,54 +308,66 @@ struct dwc3_glue_ops ti_ops = {
.select_dr_mode = dwc3_ti_select_dr_mode,
};
+static int dwc3_glue_bind_node(struct udevice *parent, ofnode node,
+ enum usb_dr_mode dr_mode)
+{
+ const char *name = ofnode_get_name(node);
+ const char *driver = NULL;
+ struct udevice *dev;
+ int ret;
+
+ debug("%s: subnode name: %s\n", __func__, name);
+
+ /* if the parent node doesn't have a mode check the leaf */
+ if (!dr_mode)
+ dr_mode = usb_get_dr_mode(node);
+
+ switch (dr_mode) {
+ case USB_DR_MODE_PERIPHERAL:
+ case USB_DR_MODE_OTG:
+#if CONFIG_IS_ENABLED(DM_USB_GADGET)
+ debug("%s: dr_mode: OTG or Peripheral\n", __func__);
+ driver = "dwc3-generic-peripheral";
+#endif
+ break;
+#if defined(CONFIG_SPL_USB_HOST) || !defined(CONFIG_SPL_BUILD)
+ case USB_DR_MODE_HOST:
+ debug("%s: dr_mode: HOST\n", __func__);
+ driver = "dwc3-generic-host";
+ break;
+#endif
+ default:
+ debug("%s: unsupported dr_mode\n", __func__);
+ return -ENODEV;
+ };
+
+ if (!driver)
+ return 0;
+
+ ret = device_bind_driver_to_node(parent, driver, name,
+node, );
+ if (ret)
+ debug("%s: not able to bind usb device mode\n",
+ __func__);
+ return ret;
+}
+
static int dwc3_glue_bind(struct udevice *parent)
{
+ struct dwc3_glue_ops *ops = (struct dwc3_glue_ops
*)dev_get_driver_data(parent);
ofnode node;
int ret;
enum usb_dr_mode dr_mode;
+ if (ops->single_node)
+ return dwc3_glue_bind_node(parent, dev_ofnode(parent), 0);
+
dr_mode = usb_get_dr_mode(dev_ofnode(parent));
ofnode_for_each_subnode(node, dev_ofnode(parent)) {
- const char *name = ofnode_get_name(node);
- struct udevice *dev;
- const char *driver = NULL;
-
- debug("%s: subnode name: %s\n", __func__, name);
-
- /* if the parent node doesn't have a mode check the leaf */
- if (!dr_mode)
- dr_mode = usb_get_dr_mode(node);
-
- switch (dr_mode) {
- case USB_DR_MODE_PERIPHERAL:
- case USB_DR_MODE_OTG:
-#if CONFIG_IS_ENABLED(DM_USB_GADGET)
- debug("%s: dr_mode: OTG or Peripheral\n", __func__);
- driver = "dwc3-generic-peripheral";
-#endif
- break;
-#if defined(CONFIG_SPL_USB_HOST) || !defined(CONFIG_SPL_BUILD)
- case USB_DR_MODE_HOST:
- debug("%s: dr_mode: HOST\n", __func__);
- driver = "dwc3-generic-host";
- break;
-#endif
- default:
- debug("%s: unsupported dr_mode\n", __func__);
- return -ENODEV;
- };
-
- if (!driver)
- continue;
-
- ret = device_bind_driver_to_node(parent, driver, name,
-node, );
- if (ret) {
- debug("%s: not able to bind usb device mode\n",
- __func__);
+ ret = dwc3_glue_bind_node(parent, node, dr_mode);
+ if (ret)
return ret;
- }
}
return 0;
@@ -454,6 +467,10 @@ static int dwc3_glue_remove(struct udevice *dev)
return 0;
}
+struct dwc3_glue_ops single_node_ops = {
+ .single_node = 1,
+};
+
static const struct udevice_id dwc3_glue_ids[] = {
{ .compatible = "xlnx,zynqmp-dwc3" },
{ .compatible = "xlnx,versal-dwc3" },
@@ -464,7 +481,7 @@ static const struct udevice_id dwc3_glue_ids[] = {
{ .compatible = "rockchip,rk3328-dwc3" },
{ .compatible = "rockchip,rk3399-dwc3" },
{ .compatible = "qcom,dwc3" },
[PATCH 2/2] mach-imx: Use CONFIG_SPL_USB_GADGET_PRODUCT_NUM
Remove the hardcoded USB product ID offset for the SPL as it doesn't
work anymore for the product ID needed for iMX8 with current flashing
tools. Update all the defconfig of iMX boards that have
CONFIG_SPL_USB_GADGET enabled to still return the same product ID.
Signed-off-by: Alban Bedel
---
arch/arm/mach-imx/spl.c | 7 ---
configs/apalis_imx6_defconfig| 1 +
configs/colibri_imx6_defconfig | 1 +
configs/display5_factory_defconfig | 1 +
configs/ge_b1x5v2_defconfig | 1 +
configs/imx6q_logic_defconfig| 1 +
configs/imx7_cm_defconfig| 1 +
configs/kontron-sl-mx6ul_defconfig | 1 +
configs/mx6sabreauto_defconfig | 1 +
configs/mx6sabresd_defconfig | 1 +
configs/mx6ul_14x14_evk_defconfig| 1 +
configs/pico-dwarf-imx6ul_defconfig | 1 +
configs/pico-dwarf-imx7d_defconfig | 1 +
configs/pico-hobbit-imx6ul_defconfig | 1 +
configs/pico-hobbit-imx7d_defconfig | 1 +
configs/pico-imx6_defconfig | 1 +
configs/pico-imx6ul_defconfig| 1 +
configs/pico-imx7d_bl33_defconfig| 1 +
configs/pico-imx7d_defconfig | 1 +
configs/pico-nymph-imx7d_defconfig | 1 +
configs/pico-pi-imx6ul_defconfig | 1 +
configs/vining_2000_defconfig| 1 +
22 files changed, 21 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-imx/spl.c b/arch/arm/mach-imx/spl.c
index 64ca29677212..27a2650a0ba5 100644
--- a/arch/arm/mach-imx/spl.c
+++ b/arch/arm/mach-imx/spl.c
@@ -185,13 +185,6 @@ u32 spl_boot_device(void)
#endif /* CONFIG_MX7 || CONFIG_IMX8M || CONFIG_IMX8 */
#ifdef CONFIG_SPL_USB_GADGET
-int g_dnl_bind_fixup(struct usb_device_descriptor *dev, const char *name)
-{
- put_unaligned(CONFIG_USB_GADGET_PRODUCT_NUM + 0xfff, >idProduct);
-
- return 0;
-}
-
#define SDPV_BCD_DEVICE 0x500
int g_dnl_get_board_bcd_device_number(int gcnum)
{
diff --git a/configs/apalis_imx6_defconfig b/configs/apalis_imx6_defconfig
index 3fa1bb58a434..5b641343cd9c 100644
--- a/configs/apalis_imx6_defconfig
+++ b/configs/apalis_imx6_defconfig
@@ -37,6 +37,7 @@ CONFIG_SPL_DMA=y
CONFIG_SPL_I2C=y
CONFIG_SPL_USB_HOST=y
CONFIG_SPL_USB_GADGET=y
+CONFIG_SPL_USB_GADGET_PRODUCT_NUM=0x4fff
CONFIG_SPL_USB_SDP_SUPPORT=y
CONFIG_SYS_PROMPT="Apalis iMX6 # "
# CONFIG_CMD_ELF is not set
diff --git a/configs/colibri_imx6_defconfig b/configs/colibri_imx6_defconfig
index 04b73a8b9cb1..a946a772bccb 100644
--- a/configs/colibri_imx6_defconfig
+++ b/configs/colibri_imx6_defconfig
@@ -36,6 +36,7 @@ CONFIG_SPL_DMA=y
CONFIG_SPL_I2C=y
CONFIG_SPL_USB_HOST=y
CONFIG_SPL_USB_GADGET=y
+CONFIG_SPL_USB_GADGET_PRODUCT_NUM=0x4fff
CONFIG_SPL_USB_SDP_SUPPORT=y
CONFIG_SYS_PROMPT="Colibri iMX6 # "
# CONFIG_CMD_ELF is not set
diff --git a/configs/display5_factory_defconfig
b/configs/display5_factory_defconfig
index 45b6b9644918..8339a7c6a09f 100644
--- a/configs/display5_factory_defconfig
+++ b/configs/display5_factory_defconfig
@@ -44,6 +44,7 @@ CONFIG_SPL_SPI_LOAD=y
CONFIG_SYS_SPI_U_BOOT_OFFS=0x2
CONFIG_SPL_USB_HOST=y
CONFIG_SPL_USB_GADGET=y
+CONFIG_SPL_USB_GADGET_PRODUCT_NUM=0xb4a4
CONFIG_SPL_USB_SDP_SUPPORT=y
CONFIG_HUSH_PARSER=y
CONFIG_SYS_PROMPT="display5 factory > "
diff --git a/configs/ge_b1x5v2_defconfig b/configs/ge_b1x5v2_defconfig
index a1cf676f3f57..bf52e0541198 100644
--- a/configs/ge_b1x5v2_defconfig
+++ b/configs/ge_b1x5v2_defconfig
@@ -41,6 +41,7 @@ CONFIG_SPL_SPI_LOAD=y
CONFIG_SYS_SPI_U_BOOT_OFFS=0x11400
CONFIG_SPL_USB_HOST=y
CONFIG_SPL_USB_GADGET=y
+CONFIG_SPL_USB_GADGET_PRODUCT_NUM=0xb4a4
CONFIG_SPL_USB_SDP_SUPPORT=y
CONFIG_HUSH_PARSER=y
CONFIG_CMD_BOOTZ=y
diff --git a/configs/imx6q_logic_defconfig b/configs/imx6q_logic_defconfig
index 0a8ac8f50ab2..34b506e72c32 100644
--- a/configs/imx6q_logic_defconfig
+++ b/configs/imx6q_logic_defconfig
@@ -37,6 +37,7 @@ CONFIG_SPL_FALCON_BOOT_MMCSD=y
CONFIG_SYS_MMCSD_RAW_MODE_KERNEL_SECTOR=0x1000
CONFIG_SPL_USB_HOST=y
CONFIG_SPL_USB_GADGET=y
+CONFIG_SPL_USB_GADGET_PRODUCT_NUM=0xb4a4
CONFIG_SPL_USB_SDP_SUPPORT=y
CONFIG_SPL_WATCHDOG=y
CONFIG_SYS_PROMPT="i.MX6 Logic # "
diff --git a/configs/imx7_cm_defconfig b/configs/imx7_cm_defconfig
index c22c4d570d40..18a7054b2e5d 100644
--- a/configs/imx7_cm_defconfig
+++ b/configs/imx7_cm_defconfig
@@ -27,6 +27,7 @@ CONFIG_DEFAULT_FDT_FILE="ask"
CONFIG_SPL_I2C=y
CONFIG_SPL_USB_HOST=y
CONFIG_SPL_USB_GADGET=y
+CONFIG_SPL_USB_GADGET_PRODUCT_NUM=0xb4a4
CONFIG_SPL_USB_SDP_SUPPORT=y
# CONFIG_CMD_BOOTD is not set
CONFIG_CMD_BOOTMENU=y
diff --git a/configs/kontron-sl-mx6ul_defconfig
b/configs/kontron-sl-mx6ul_defconfig
index c4f8fdb4f5fc..65cecff52f2c 100644
--- a/configs/kontron-sl-mx6ul_defconfig
+++ b/configs/kontron-sl-mx6ul_defconfig
@@ -31,6 +31,7 @@ CONFIG_SPL_LEGACY_IMAGE_CRC_CHECK=y
CONFIG_SPL_SEPARATE_BSS=y
CONFIG_SPL_USB_HOST=y
CONFIG_SPL_USB_GADGET=y
+CONFIG_SPL_USB_GADGET_PRODUCT_NUM=0xb4a4
CONFIG_SPL_WATCHDOG=y
CONFIG_CMD_MEMTEST=y
CONFIG_CMD_GPIO=y
diff --git a/configs/mx6sabreauto_defconfig
[PATCH] devres: Use the correct devres implementation in SPL builds
When CONFIG_DEVRES is set, but CONFIG_SPL_DM is not set devres code is
not included in the SPL. But dm/devres.h only check for CONFIG_DEVRES
to select if the full implementation should be used. So if any devres
function is used in the SPL with this config the link fails.
Fix the ifdef in the dm/devres.h to also check for CONFIG_SPL_DM in
SPL builds.
Signed-off-by: Alban Bedel
---
include/dm/devres.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/dm/devres.h b/include/dm/devres.h
index 0ab277ec38e9..8765b73d5e90 100644
--- a/include/dm/devres.h
+++ b/include/dm/devres.h
@@ -30,7 +30,8 @@ struct devres_stats {
int total_size;
};
-#ifdef CONFIG_DEVRES
+/* devres is not available in SPL unless DM is enabled there */
+#if defined(CONFIG_DEVRES) && CONFIG_IS_ENABLED(DM)
#ifdef CONFIG_DEBUG_DEVRES
void *__devres_alloc(dr_release_t release, size_t size, gfp_t gfp,
--
2.32.0
smime.p7s
Description: S/MIME cryptographic signature
[PATCH] imx: spl: Default to SPD when booting from USB serial download
On the iMX platforms the USB boot is in fact boot from USB serial download and not from a USB mass storage. So returning BOOT_DEVICE_USB typically doesn't make sense as USB SPD is then used to continue booting, for this we need to return BOOT_DEVICE_BOARD. Still return BOOT_DEVICE_USB when USB mass storage support has been built in the SPL. With USB-C on both side, the programmer could switch back to device mode and use the exposed mass storage device after the serial download finished. Signed-off-by: Alban Bedel --- arch/arm/mach-imx/spl.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arm/mach-imx/spl.c b/arch/arm/mach-imx/spl.c index 64ca29677212..2c2b2b126ad7 100644 --- a/arch/arm/mach-imx/spl.c +++ b/arch/arm/mach-imx/spl.c @@ -177,7 +177,8 @@ u32 spl_boot_device(void) case QSPI_BOOT: return BOOT_DEVICE_NOR; case USB_BOOT: - return BOOT_DEVICE_USB; + return IS_ENABLED(CONFIG_SPL_USB_STORAGE) ? + BOOT_DEVICE_USB : BOOT_DEVICE_BOARD; default: return BOOT_DEVICE_NONE; } -- 2.32.0 smime.p7s Description: S/MIME cryptographic signature
[BUG] keyboard doesn't work on Olimex teres-I notebook
[ Please CC to me, I'm not subscribed to mailing list ] Hi, On u-boot release 2022.04 keyboard doesn't work in u-boot on Olimex TERES-I notebook. With git bisect I found that commit 35ae126c16a6a9149edc6638faaa247f67b8a400 is introduced this. Reverting this commit solved problem and in my test keyboard now works. -- Kind regards
Re: [PATCH] Fix spelling of "followed" in kwboot.1
On Sat, 16 Apr 2022 15:42:00 -0700 Vagrant Cascadian wrote: > Signed-off-by: Vagrant Cascadian Hello Vagrant, The commit title should be prefixed with tools: kwboot: The commit message shouldn't be empty. If you don't have anything to say, just copy commit title. Marek
Re: [PATCH 07/10] dm: core: Allow devres to be disabled in SPL
On Sun, Mar 27, 2022 at 02:26:19PM -0600, Simon Glass wrote: > At present if devres is enabled in U-Boot proper it is enabled in SPL. > We don't normally want it there, so disable it. > > Signed-off-by: Simon Glass > Tested-by: Angus Ainslie Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 02/10] sandbox: Correct loss of early output in SPL
On Sun, Mar 27, 2022 at 02:26:14PM -0600, Simon Glass wrote: > At present fputc() is used before the console is available, then write() > is used. These are not compatible. Since fputc() buffers internally it is > better to use the write(), so that a partial line is immediately > displayed. > > This has a slight effect on performance, but we are already using write() > for the vast majority of the output with no obvious impacts. > > Signed-off-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 04/10] Makefile: Avoid resetting link flags in config.mk
On Sun, Mar 27, 2022 at 02:26:16PM -0600, Simon Glass wrote: > This makes it impossible to change them elsewhere. The default value is > 'empty' anyway, so just drop it. > > Signed-off-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 03/10] Makefile: Drop a stale comment about linking
On Sun, Mar 27, 2022 at 02:26:15PM -0600, Simon Glass wrote: > The bug mentioned here is fixed, so drop the comment. > > Signed-off-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 05/10] sandbox: Allow link flags to be given
On Sun, Mar 27, 2022 at 02:26:17PM -0600, Simon Glass wrote: > At present the link flags are not used for sandbox. Update the command > line to use them. > > Signed-off-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 06/10] sandbox: Align linker lists to a 32-byte boundary
On Sun, Mar 27, 2022 at 02:26:18PM -0600, Simon Glass wrote: > Use this larger boundary to ensure that linker lists at least start on the > maximum possible alignment boundary. See also the CONFIG_LINKER_LIST_ALIGN > setting, but that is host-arch-specific, so it seems better to use the > largest value for every host architecture. > > Signed-off-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
[PATCH] i2c: ihs: intel: Fix typo in comments (actual)
s/actucal/actual/g
Signed-off-by: Michal Simek
---
drivers/i2c/ihs_i2c.c | 2 +-
drivers/i2c/intel_i2c.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/ihs_i2c.c b/drivers/i2c/ihs_i2c.c
index ecca90628e79..d715714638ff 100644
--- a/drivers/i2c/ihs_i2c.c
+++ b/drivers/i2c/ihs_i2c.c
@@ -195,7 +195,7 @@ static int ihs_i2c_xfer(struct udevice *bus, struct i2c_msg
*msg, int nmsgs)
memset(, 0, sizeof(struct i2c_msg));
/* We expect either two messages (one with an offset and one with the
-* actucal data) or one message (just data)
+* actual data) or one message (just data)
*/
if (nmsgs > 2 || nmsgs == 0) {
debug("%s: Only one or two messages are supported\n", __func__);
diff --git a/drivers/i2c/intel_i2c.c b/drivers/i2c/intel_i2c.c
index 52f7a528efe8..88674d87e8bb 100644
--- a/drivers/i2c/intel_i2c.c
+++ b/drivers/i2c/intel_i2c.c
@@ -213,7 +213,7 @@ static int intel_i2c_xfer(struct udevice *bus, struct
i2c_msg *msg, int nmsgs)
/*
* We expect either two messages (one with an offset and one with the
-* actucal data) or one message (just data)
+* actual data) or one message (just data)
*/
if (nmsgs > 2 || nmsgs == 0) {
debug("%s: Only one or two messages are supported", __func__);
--
2.35.1
Re: [PATCH v2] pstore: Support already existing reserved-memory node
Hi Daniel,
The patch only checks the existence of the reserved-memory node.
I guess that before, adding the reserved-memory node failed and so nothing
else was happening. Now, the node is found and then, it adds the ramoops
subnode to it, making it double because it is already there in your case.
But that should not happen, because the fdt_add_subnode() function should fail
if the node is already present (like it was failing for reserved-memory).
I'm going to look into it. Can you send me the device tree taht you are using
(or at least the reserved-memory part) and u-boot config ?
Detlev.
On Monday, April 11, 2022 7:00:20 P.M. EDT Daniel Golle wrote:
> Hi Detlev,
>
> I've recently tried to update U-Boot from 2022.01 to 2022.04 and
> noticed a regression introduced by the commit below.
>
> While the unwanted error message ("Add 'reserved-memory' node failed:
> FDT_ERR_EXISTS") no longer appears, I now see a lengthy kernel stack
> trace in Linux instead:
> ...
> [0.008295] sysfs: cannot create duplicate filename
> '/devices/platform/42ff.ramoops' [0.008303] CPU: 0 PID: 1 Comm:
> swapper/0 Tainted: G S5.15.33 #0 [0.008312] Hardware
> name: Bananapi BPI-R64 (DT)
> [0.008318] Call trace:
> [0.008322] dump_backtrace+0x0/0x15c
> [0.008337] show_stack+0x14/0x30
> [0.008345] dump_stack_lvl+0x64/0x7c
> [0.008355] dump_stack+0x14/0x2c
> [0.008362] sysfs_warn_dup+0x5c/0x74
> [0.008373] sysfs_create_dir_ns+0xb0/0xc0
> [0.008381] kobject_add_internal+0xbc/0x330
> [0.008392] kobject_add+0x80/0xe0
> [0.008400] device_add+0xd4/0x82c
> [0.008410] of_device_add+0x4c/0x5c
> [0.008420] of_platform_device_create_pdata+0xb8/0xf0
> [0.008428] of_platform_default_populate_init+0x58/0xcc
> [0.008437] do_one_initcall+0x4c/0x1b0
> [0.008444] kernel_init_freeable+0x230/0x294
> [0.008456] kernel_init+0x20/0x120
> [0.008463] ret_from_fork+0x10/0x20
> [0.008471] kobject_add_internal failed for 42ff.ramoops with
> -EEXIST, don't try to register things with the same name in the same
> directory. ...
>
> I assume that fdt_find_or_add_subnode() doesn't behave as expected and
> apparently adds a duplicate node having the same name.
> The pstore/ramoops reserved-memory is already defined in the fdt
> contained in the FIT image (for compatibility with older U-Boot which
> didn't care about pstore), so it should be not added again.
>
> On Mon, Feb 07, 2022 at 11:02:30AM -0500, Detlev Casanova wrote:
> > The pstore command tries to create a reserved-memory node but fails if
> >
> > it is already present with:
> > Add 'reserved-memory' node failed: FDT_ERR_EXISTS
> >
> > This patch creates the node only if it does not exist and adapts the reg
> > values sizes depending on already present #address-cells and #size-cells
> > values.
> >
> > Signed-off-by: Detlev Casanova
> > ---
> >
> > Changes in v2:
> > - Move declarations at beginning of function
> > - Use if instead of switch
> > - Reword Subject
> >
> > cmd/pstore.c | 39 ++-
> > 1 file changed, 34 insertions(+), 5 deletions(-)
> >
> > diff --git a/cmd/pstore.c b/cmd/pstore.c
> > index 9fac8c7218..cd6f6feb2f 100644
> > --- a/cmd/pstore.c
> > +++ b/cmd/pstore.c
> > @@ -11,6 +11,7 @@
> >
> > #include
> > #include
> > #include
> >
> > +#include
> >
> > struct persistent_ram_buffer {
> >
> > u32sig;
> >
> > @@ -485,6 +486,8 @@ void fdt_fixup_pstore(void *blob)
> >
> > {
> >
> > char node[32];
> > int nodeoffset;/* node offset from libfdt */
> >
> > + u32 addr_cells;
> > + u32 size_cells;
> >
> > nodeoffset = fdt_path_offset(blob, "/");
> > if (nodeoffset < 0) {
> >
> > @@ -493,14 +496,18 @@ void fdt_fixup_pstore(void *blob)
> >
> > return;
> >
> > }
> >
> > - nodeoffset = fdt_add_subnode(blob, nodeoffset, "reserved-memory");
> > + nodeoffset = fdt_find_or_add_subnode(blob, nodeoffset,
> > "reserved-memory");>
> > if (nodeoffset < 0) {
> >
> > log_err("Add 'reserved-memory' node failed: %s\n",
> >
> > fdt_strerror(nodeoffset));
> >
> > return;
> >
> > }
> >
> > - fdt_setprop_u32(blob, nodeoffset, "#address-cells", 2);
> > - fdt_setprop_u32(blob, nodeoffset, "#size-cells", 2);
> > +
> > + addr_cells = fdt_getprop_u32_default_node(blob, nodeoffset, 0,
> > "#address-cells", 2); + size_cells = fdt_getprop_u32_default_node(blob,
> > nodeoffset, 0, "#size-cells", 2); + fdt_setprop_u32(blob, nodeoffset,
> > "#address-cells", addr_cells); +fdt_setprop_u32(blob, nodeoffset,
> > "#size-cells", size_cells);
> > +
> >
> > fdt_setprop_empty(blob, nodeoffset, "ranges");
> >
> > sprintf(node, "ramoops@%llx", (unsigned long long)pstore_addr);
> >
> > @@ -509,14 +516,36 @@ void fdt_fixup_pstore(void *blob)
> >
> >
[PATCH 1/2] usb: dwc3: core: Fix warnings when building without driver model
Commit f150b8d28b4e ("usb: dwc3: Enable undefined length INCR burst
type") introduced code that assign the content of dwc->dev to a
variable. But in u-boot the type of this field changes if building
with driver model enabled or not. As this variable is then only used
once just remove it and use the struct field directly.
Another issued was also introduced in commit fb146fbc1ae5 ("usb: dwc3:
core: stop the core when it's removed") which define a static function
which is only used when the driver model is enabled. Add ifdef around
this function to suppress the warning when building without driver
model.
Signed-off-by: Alban Bedel
---
drivers/usb/dwc3/core.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index b592a487e001..fdd8c5db2460 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -465,7 +465,6 @@ static void dwc3_phy_setup(struct dwc3 *dwc)
/* set global incr burst type configuration registers */
static void dwc3_set_incr_burst_type(struct dwc3 *dwc)
{
- struct udevice *dev = dwc->dev;
u32 cfg;
if (!dwc->incrx_size)
@@ -502,7 +501,7 @@ static void dwc3_set_incr_burst_type(struct dwc3 *dwc)
case 1:
break;
default:
- dev_err(dev, "Invalid property\n");
+ dev_err(dwc->dev, "Invalid property\n");
break;
}
@@ -706,6 +705,7 @@ static void dwc3_gadget_run(struct dwc3 *dwc)
mdelay(100);
}
+#if CONFIG_IS_ENABLED(DM_USB)
static void dwc3_core_stop(struct dwc3 *dwc)
{
u32 reg;
@@ -713,6 +713,7 @@ static void dwc3_core_stop(struct dwc3 *dwc)
reg = dwc3_readl(dwc->regs, DWC3_DCTL);
dwc3_writel(dwc->regs, DWC3_DCTL, reg & ~(DWC3_DCTL_RUN_STOP));
}
+#endif
static void dwc3_core_exit_mode(struct dwc3 *dwc)
{
--
2.32.0
smime.p7s
Description: S/MIME cryptographic signature
[PATCH 1/2] usb: dwc3: core: fix warnings when building without driver model
Commit f150b8d28b4e ("usb: dwc3: Enable undefined length INCR burst
type") introduced code that assign the content of dwc->dev to a
variable. But in u-boot the type of this field changes if building
with driver model enabled or not. As this variable is then only used
once just remove it and use the struct field directly.
Another issued was also introduced in commit fb146fbc1ae5 ("usb: dwc3:
core: stop the core when it's removed") which define a static function
which is only used when the driver model is enabled. Add ifdef around
this function to suppress the warning when building without driver
model.
Signed-off-by: Alban Bedel
---
drivers/usb/dwc3/core.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index b592a487e001..fdd8c5db2460 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -465,7 +465,6 @@ static void dwc3_phy_setup(struct dwc3 *dwc)
/* set global incr burst type configuration registers */
static void dwc3_set_incr_burst_type(struct dwc3 *dwc)
{
- struct udevice *dev = dwc->dev;
u32 cfg;
if (!dwc->incrx_size)
@@ -502,7 +501,7 @@ static void dwc3_set_incr_burst_type(struct dwc3 *dwc)
case 1:
break;
default:
- dev_err(dev, "Invalid property\n");
+ dev_err(dwc->dev, "Invalid property\n");
break;
}
@@ -706,6 +705,7 @@ static void dwc3_gadget_run(struct dwc3 *dwc)
mdelay(100);
}
+#if CONFIG_IS_ENABLED(DM_USB)
static void dwc3_core_stop(struct dwc3 *dwc)
{
u32 reg;
@@ -713,6 +713,7 @@ static void dwc3_core_stop(struct dwc3 *dwc)
reg = dwc3_readl(dwc->regs, DWC3_DCTL);
dwc3_writel(dwc->regs, DWC3_DCTL, reg & ~(DWC3_DCTL_RUN_STOP));
}
+#endif
static void dwc3_core_exit_mode(struct dwc3 *dwc)
{
--
2.32.0
smime.p7s
Description: S/MIME cryptographic signature
Re: [PATCH 3/7] disk: define nullified functions for !PARTITIONS
On Tue, Apr 19, 2022 at 01:11:23PM +0900, AKASHI Takahiro wrote: > On Mon, Apr 18, 2022 at 11:09:38PM -0400, Tom Rini wrote: > > On Tue, Apr 19, 2022 at 10:01:54AM +0900, AKASHI Takahiro wrote: > > > > > Some defconfig enables CMD_PART even if none of any partition table > > > types (CONFIG_*_PARTITION) are enabled. > > > This will lead to the size growth in SPL/TPL code since disk/part.c > > > will be compiled in any way. > > > We will change disk/Kconfig later so that CONFIG_PARTITIONS is only > > > enabled when, at least, one of CONFIG_*_PARTITION is enabled. > > > > > > To make the build work (in particular, "part" command) correctly, > > > a few functions should be defined as void functions in case of > > > !CONFIG_PARTITIONS. > > > > > > Signed-off-by: AKASHI Takahiro > > > > I guess I wonder why we don't just make CMD_PART depend on PARTITIONS > > now and thus correct the few (single?) board that has this enabled > > without underlying partition code by removing the can't be functional > > cmd. > > Well, that is partially what I did in my RFC and I thought > that you declined to accept my change. > Did I misunderstand you? Yes, I wasn't clear, sorry for the confusion. Just this part of the series should be replaced with making CMD_PART depend on PARTITIONS and if there really is a use case for 'part' without PARTITION support (rather than it being an unintentionally enabled feature) we can deal with it then. The rest of the series looks good to me and I'll let Heinrich comment on the EFI specific parts. -- Tom signature.asc Description: PGP signature
Re: [PATCH] net: marvell: mvgbe: Set PHY page 0 before phy_connect
Hi Tony,
On 4/12/22 22:18, Tony Dinh wrote:
For most Kirkwood boards, the PHY page is already set to page 0
(in register 22) before phy_connect is invoked. But some board like
the Zyxel NSA310S (which uses the network chip MV88E1318S), the PHY page
is not set to page 0. There seems to be some bad data remained in
register 22 when the uclass MVGBE about to invoke phy_connect().
This patch enables the uclass MVGBE to always set the PHY page to 0
before phy_connect.
For reference, please see this discussion:
[RFC PATCH v2] arm: kirkwood: nsa310s: Use Marvell uclass mvgbe
and PHY driver for DM Ethernet.
https://lists.denx.de/pipermail/u-boot/2022-April/480946.html
I don't think that this is the correct approach. We should not set
the *Marvell* PHY page address in this MAC driver IMHO. This driver
should not have any PHY specific changes. This should be done in the
PHY driver instead. Some PHY driver or board specific code seems to be
responsible for setting a non-zero PHY page and not resetting it back
to zero. A better solution would be to locate this code path and add
this page reset to 0 there.
What do you think?
Thanks,
Stefan
This patch has been tested with the following Kirkwood boards:
NSA310S (88F6702, network chip MV88E1318S)
Sheevaplug (88F6281, network chip MV88E1318)
Pogo V4 (88F6192, network chip 88E1116R)
GF Home(88F6281, network chip 88E1116R)
Dreamplug (88F6281, network chip MV88E1318)
Dell Kace M300 (88F6282, network chip MV88E1318) - out of tree u-boot
Signed-off-by: Tony Dinh
---
drivers/net/mvgbe.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/net/mvgbe.c b/drivers/net/mvgbe.c
index 954bf86121..d2db1e584a 100644
--- a/drivers/net/mvgbe.c
+++ b/drivers/net/mvgbe.c
@@ -43,6 +43,7 @@ DECLARE_GLOBAL_DATA_PTR;
#define MV_PHY_ADR_REQUEST 0xee
#define MVGBE_SMI_REG (((struct mvgbe_registers *)MVGBE0_BASE)->smi)
+#define MVGBE_PGADR_REG22
#if defined(CONFIG_PHYLIB) || defined(CONFIG_MII) || defined(CONFIG_CMD_MII)
static int smi_wait_ready(struct mvgbe_device *dmvgbe)
@@ -745,6 +746,9 @@ static struct phy_device *__mvgbe_phy_init(struct
eth_device *dev,
miiphy_write(dev->name, MV_PHY_ADR_REQUEST, MV_PHY_ADR_REQUEST,
phyid);
+ /* Make sure the selected PHY page is 0 before connecting */
+ miiphy_write(dev->name, phyid, MVGBE_PGADR_REG, 0);
+
phydev = phy_connect(bus, phyid, dev, phy_interface);
if (!phydev) {
printf("phy_connect failed\n");
Viele Grüße,
Stefan Roese
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
[PATCH] Convert CONFIG_SYS_MEM_TOP_HIDE to Kconfig
This converts CONFIG_SYS_MEM_TOP_HIDE to Kconfig to be able to enable it
also for other boards.
Help text description is taken from comment in common/board_f.c.
It also slightly change behavior because every board defines it as 0x0 now
that's why code is enabled by default but compiler should remove it if not
defined.
Signed-off-by: Michal Simek
---
Please let me know if logic in board_f.c is not correct.
---
Kconfig | 9 +
common/board_f.c| 27 ++-
configs/origen_defconfig| 1 +
configs/s5pc210_universal_defconfig | 1 +
configs/theadorable_debug_defconfig | 1 +
configs/trats2_defconfig| 1 +
configs/trats_defconfig | 1 +
include/configs/odroid.h| 1 -
include/configs/odroid_xu3.h| 1 -
include/configs/origen.h| 2 --
include/configs/s5pc210_universal.h | 2 --
include/configs/theadorable.h | 1 -
include/configs/trats.h | 2 --
include/configs/trats2.h| 2 --
scripts/config_whitelist.txt| 1 -
15 files changed, 28 insertions(+), 25 deletions(-)
diff --git a/Kconfig b/Kconfig
index b45e60a75b93..c0fc8f798b8a 100644
--- a/Kconfig
+++ b/Kconfig
@@ -222,6 +222,15 @@ config NR_DRAM_BANKS
help
This defines the number of DRAM banks.
+config SYS_MEM_TOP_HIDE
+ hex "Hide space (in bytes) from TOP memory"
+ default 0x0
+ help
+ Subtract specified amount of memory to hide so that it won't
+ get "touched" at all by U-Boot. By fixing up gd->ram_size
+ the Linux kernel should now get passed the now "corrected"
+ memory size and won't touch it either.
+
config SYS_BOOT_GET_CMDLINE
bool "Enable kernel command line setup"
help
diff --git a/common/board_f.c b/common/board_f.c
index 5b655ad6efe4..643bb463580e 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -327,19 +327,20 @@ static int setup_dest_addr(void)
* Ram is setup, size stored in gd !!
*/
debug("Ram size: %08lX\n", (ulong)gd->ram_size);
-#if defined(CONFIG_SYS_MEM_TOP_HIDE)
- /*
-* Subtract specified amount of memory to hide so that it won't
-* get "touched" at all by U-Boot. By fixing up gd->ram_size
-* the Linux kernel should now get passed the now "corrected"
-* memory size and won't touch it either. This should work
-* for arch/ppc and arch/powerpc. Only Linux board ports in
-* arch/powerpc with bootwrapper support, that recalculate the
-* memory size from the SDRAM controller setup will have to
-* get fixed.
-*/
- gd->ram_size -= CONFIG_SYS_MEM_TOP_HIDE;
-#endif
+
+ if (CONFIG_SYS_MEM_TOP_HIDE)
+ /*
+* Subtract specified amount of memory to hide so that it won't
+* get "touched" at all by U-Boot. By fixing up gd->ram_size
+* the Linux kernel should now get passed the now "corrected"
+* memory size and won't touch it either. This should work
+* for arch/ppc and arch/powerpc. Only Linux board ports in
+* arch/powerpc with bootwrapper support, that recalculate the
+* memory size from the SDRAM controller setup will have to
+* get fixed.
+*/
+ gd->ram_size -= CONFIG_SYS_MEM_TOP_HIDE;
+
#ifdef CONFIG_SYS_SDRAM_BASE
gd->ram_base = CONFIG_SYS_SDRAM_BASE;
#endif
diff --git a/configs/origen_defconfig b/configs/origen_defconfig
index 6ffec862cd9d..b4b0d8b1464c 100644
--- a/configs/origen_defconfig
+++ b/configs/origen_defconfig
@@ -16,6 +16,7 @@ CONFIG_SPL=y
CONFIG_IDENT_STRING=" for ORIGEN"
CONFIG_SYS_LOAD_ADDR=0x43e0
CONFIG_DISTRO_DEFAULTS=y
+CONFIG_SYS_MEM_TOP_HIDE=0x10
CONFIG_BOOTCOMMAND="if mmc rescan; then echo SD/MMC found on device
${mmcdev};if run loadbootenv; then echo Loaded environment from ${bootenv};run
importbootenv;fi;if test -n $uenvcmd; then echo Running uenvcmd ...;run
uenvcmd;fi;if run loadbootscript; then run bootscript; fi; fi;load mmc
${mmcdev} ${loadaddr} uImage; bootm ${loadaddr} "
CONFIG_SYS_CONSOLE_IS_IN_ENV=y
CONFIG_SYS_CONSOLE_INFO_QUIET=y
diff --git a/configs/s5pc210_universal_defconfig
b/configs/s5pc210_universal_defconfig
index 8a34908e85cc..e70ce25b099d 100644
--- a/configs/s5pc210_universal_defconfig
+++ b/configs/s5pc210_universal_defconfig
@@ -13,6 +13,7 @@ CONFIG_ENV_OFFSET=0x7000
CONFIG_DEFAULT_DEVICE_TREE="exynos4210-universal_c210"
CONFIG_SYS_LOAD_ADDR=0x4480
CONFIG_DISTRO_DEFAULTS=y
+CONFIG_SYS_MEM_TOP_HIDE=0x10
CONFIG_USE_BOOTARGS=y
CONFIG_BOOTARGS="Please use defined boot"
CONFIG_BOOTCOMMAND="run mmcboot"
diff --git a/configs/theadorable_debug_defconfig
b/configs/theadorable_debug_defconfig
index 64ae29113e3e..bee327e7ad6d 100644
--- a/configs/theadorable_debug_defconfig
+++
Re: [PATCH 08/10] dm: core: Deal with a wrinkle with linker lists
On Sun, Mar 27, 2022 at 02:26:20PM -0600, Simon Glass wrote: > When every member of a linker list is aligned by the compiler, we can no > longer rely on the sizeof of the struct to determine the number of > entries. > > For example, if the struct size is 0x90 but every entry is aligned to 0xa0 > by the compiler, the linker list entries takes more space in memory and > the calculation of the number of entries is incorrect. For example, we may > see 0x12 entries when there are only 0x11. > > This is a real problem. There may be a general solution, although I cannot > currently think of one. So far it only bites with OF_PLATDATA_RT which > creates a pointer to each entry of the 'struct udevice' linker_list. This > does not happen without that option, so it only affects SPL. > > Work around it by manually calculating the aligned size of struct udevice, > then using that for the n_ent calculation. > > Note: the alignment fix to linker list was here: > >0b2fa98aa5e linker_lists: Fix alignment issue > > Signed-off-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/2] usb: dwc3: core: Fix warnings when building without driver model
Hi, +#if CONFIG_IS_ENABLED(DM_USB) static void dwc3_core_stop(struct dwc3 *dwc) will __maybe_unused work? -michael
Pull request: u-boot-rockchip-20220418
Hi Tom, Please pull the rockchip updates: - Add rk3066 SoC support; - Add rk3066 MK808 board support; - dts sync from kernel for rk322x, rk3288; - some other board level config update; Gitlab ci: https://source.denx.de/u-boot/custodians/u-boot-rockchip/-/pipelines/11773 Thanks, - Kever The following changes since commit 9859465bfe838bc8264d45e1a1bed847bba74bad: Merge tag 'efi-2022-07-rc1-2' of https://source.denx.de/u-boot/custodians/u-boot-efi (2022-04-15 14:29:52 -0400) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-rockchip.git tags/u-boot-rockchip-20220418 for you to fetch changes up to dcaaefdc0a7b3052e513b0e5dd2b00be4436386b: rockchip: video: mipi: add more compatible strings for rk3288/rk3399 (2022-04-18 11:25:13 +0800) Chris Morgan (2): spi: rockchip_sfc: Add missing include for dm/device_compat.h rockchip: clk: add clocks to px30_clk_enable Haolin Li (1): mmc: rockchip_sdhci: Correct error checking Johan Jonker (38): rockchip: move ROCKCHIP_STIMER_BASE to Kconfig rockchip: spl: change call condition rockchip_stimer_init() rockchip: tpl: change call condition rockchip_stimer_init() rockchip: tpl: use IS_ENABLED for timer_init() call condition rockchip: timer: add OF_PLATDATA support for dw-apb-timer rockchip: timer: dw-apb-timer: fix whitespace in U_BOOT_DRIVER structure rockchip: mmc: rockchip_dw_mmc: fix ciu clock index rockchip: mmc: rockchip_dw_mmc: add rk3066/rk3188 support rockchip: serial: restyle the serial_rockchip.c driver rockchip: serial: move driver alias to serial_rockchip.c rockchip: serial: rename U_BOOT_DRIVER name to rockchip_uart rockchip: serial: Kconfig: add select SYS_NS16550 to config ROCKCHIP_SERIAL rockchip: serial: Kconfig: allow ROCKCHIP_SERIAL enabled in TPL rockchip: rk3066-power: sync power domain dt-binding header from Linux arm: dts: rockchip: fix rk3xxx-u-boot.dtsi arm: dts: rockchip: fix include rk3xxx-u-boot.dtsi arm: dts: rockchip: add rk3066a.dtsi arm: dts: rockchip: add rk3066a-mk808.dts rockchip: tools: add rk3066 support to rkcommon.c rockchip: rk3066: add core support rockchip: rk3066: add Rikomagic MK808 board rockchip: rk3066: add mk808_defconfig doc: rockchip: restyle rockchip.rst doc: rockchip: add px30/rk3326 boards and examples doc: rockchip: add rk3066 Rikomagic MK808 rockchip: rk3228-power: sync power domain dt-binding header from Linux rockchip: rk3228-cru: sync the clock dt-binding header from Linux arm: dts: rockchip: move all rk322x u-boot specific properties in separate dtsi files arm: dts: rockchip: sync rk322x.dtsi from Linux arm: dts: rockchip: sync rk3229-evb.dts from Linux rockchip: rk3288-power: sync power domain dt-binding header from Linux rockchip: rk3288-cru: sync the clock dt-binding header from Linux arm: dts: rockchip: move all rk3288 u-boot specific properties in separate dtsi files rockchip: fix boot_devices constants board: google: veyron: add more DT files to MAINTAINERS board: rk3288: add more DT files to MAINTAINERS rockchip: video: rk_edp: add more rk3288 edp node options rockchip: video: mipi: add more compatible strings for rk3288/rk3399 Paweł Jarosz (4): rockchip: rk3066: add grf header file rockchip: rk3066: add clock driver for rk3066 soc rockchip: rk3066: add rk3066 pinctrl driver rockchip: rk3066: add sdram driver Peter Cai (1): adc: rockchip-saradc: add support for getting reference voltage value Vagrant Cascadian (2): rockchip: Enable SCSI in distro bootcmd for rk3399. rockchip: Enable AHCI/SCSI/SATA on rockpro64-rk3399. arch/arm/dts/Makefile | 3 + arch/arm/dts/rk3066a-mk808-u-boot.dtsi | 49 ++ arch/arm/dts/rk3066a-mk808.dts | 216 ++ arch/arm/dts/rk3066a-u-boot.dtsi| 4 + arch/arm/dts/rk3066a.dtsi | 879 +++ arch/arm/dts/rk3188-u-boot.dtsi | 1 + arch/arm/dts/rk3188.dtsi| 1 - arch/arm/dts/rk3229-evb-u-boot.dtsi | 28 + arch/arm/dts/rk3229-evb.dts | 223 +- arch/arm/dts/rk3229.dtsi| 52 ++ arch/arm/dts/rk322x-u-boot.dtsi | 56 ++ arch/arm/dts/rk322x.dtsi| 879 ++- arch/arm/dts/rk3288-evb-u-boot.dtsi | 11 + arch/arm/dts/rk3288-evb.dts | 11 - arch/arm/dts/rk3288-firefly-u-boot.dtsi | 31 + arch/arm/dts/rk3288-firefly.dts | 17 - arch/arm/dts/rk3288-firefly.dtsi| 3 - arch/arm/dts/rk3288-miqi-u-boot.dtsi| 20 +
[PATCH v2 0/2] Support various block interfaces for avb and bcb
Hello. Originally bcb and avb utilities implementation relay on mmc block devices. This patch series adds an optional interface parameter to those utilities, which gives the ability to use bcb and avb on various block devices. The patch set was tested using xenguest_arm64 based board and pvblock interface. Changes for v2: - Removed patch #3 as not actual for mainline Andrii Chepurnyi (2): cmd: bcb: introduce optional interface parameter to bcb cmd: avb: introduce optional interface parameter to avb init cmd/avb.c| 13 - cmd/bcb.c| 65 ++-- common/avb_verify.c | 28 +++ doc/android/avb2.rst | 2 +- doc/android/bcb.rst | 33 -- include/avb_verify.h | 11 +++- 6 files changed, 77 insertions(+), 75 deletions(-) -- 2.25.1
[PATCH v2 1/2] cmd: bcb: introduce optional interface parameter to bcb
From: Andrii Chepurnyi
From: Andrii Chepurnyi
Originally, bcb implementation relay on mmc block devices.
The interface parameter will give the ability to use bcb with
various block devices by choosing the exact interface type.
By default (if no interface parameter is provided) mmc interface
will be used.
Signed-off-by: Andrii Chepurnyi
---
cmd/bcb.c | 65 +++--
doc/android/bcb.rst | 33 ---
2 files changed, 51 insertions(+), 47 deletions(-)
diff --git a/cmd/bcb.c b/cmd/bcb.c
index 92f4d27990..bfe395558e 100644
--- a/cmd/bcb.c
+++ b/cmd/bcb.c
@@ -26,6 +26,7 @@ enum bcb_cmd {
static int bcb_dev = -1;
static int bcb_part = -1;
static struct bootloader_message bcb __aligned(ARCH_DMA_MINALIGN) = { { 0 } };
+static struct blk_desc *bcb_blk_desc;
static int bcb_cmd_get(char *cmd)
{
@@ -51,6 +52,9 @@ static int bcb_is_misused(int argc, char *const argv[])
switch (cmd) {
case BCB_CMD_LOAD:
+ if (argc != 3 && argc != 4)
+ goto err;
+ break;
case BCB_CMD_FIELD_SET:
if (argc != 3)
goto err;
@@ -115,25 +119,23 @@ static int bcb_field_get(char *name, char **fieldp, int
*sizep)
static int __bcb_load(int devnum, const char *partp)
{
- struct blk_desc *desc;
struct disk_partition info;
u64 cnt;
char *endp;
int part, ret;
- desc = blk_get_devnum_by_type(IF_TYPE_MMC, devnum);
- if (!desc) {
+ if (!bcb_blk_desc) {
ret = -ENODEV;
goto err_read_fail;
}
part = simple_strtoul(partp, , 0);
if (*endp == '\0') {
- ret = part_get_info(desc, part, );
+ ret = part_get_info(bcb_blk_desc, part, );
if (ret)
goto err_read_fail;
} else {
- part = part_get_info_by_name(desc, partp, );
+ part = part_get_info_by_name(bcb_blk_desc, partp, );
if (part < 0) {
ret = part;
goto err_read_fail;
@@ -144,12 +146,12 @@ static int __bcb_load(int devnum, const char *partp)
if (cnt > info.size)
goto err_too_small;
- if (blk_dread(desc, info.start, cnt, ) != cnt) {
+ if (blk_dread(bcb_blk_desc, info.start, cnt, ) != cnt) {
ret = -EIO;
goto err_read_fail;
}
- bcb_dev = desc->devnum;
+ bcb_dev = bcb_blk_desc->devnum;
bcb_part = part;
debug("%s: Loaded from mmc %d:%d\n", __func__, bcb_dev, bcb_part);
@@ -170,15 +172,15 @@ err:
static int do_bcb_load(struct cmd_tbl *cmdtp, int flag, int argc,
char * const argv[])
{
- char *endp;
- int devnum = simple_strtoul(argv[1], , 0);
+ int ret = blk_get_device_by_str((argv[3]) ? argv[3] : "mmc", argv[1],
_blk_desc);
- if (*endp != '\0') {
- printf("Error: Device id '%s' not a number\n", argv[1]);
+ if (ret < 0) {
+ printf("Error: Device id '%s' or interface '%s' is not
valid\n", argv[1],
+ (argv[3]) ? argv[3] : "mmc");
return CMD_RET_FAILURE;
}
- return __bcb_load(devnum, argv[2]);
+ return __bcb_load(bcb_blk_desc->devnum, argv[2]);
}
static int __bcb_set(char *fieldp, const char *valp)
@@ -281,24 +283,22 @@ static int do_bcb_dump(struct cmd_tbl *cmdtp, int flag,
int argc,
static int __bcb_store(void)
{
- struct blk_desc *desc;
struct disk_partition info;
u64 cnt;
int ret;
- desc = blk_get_devnum_by_type(IF_TYPE_MMC, bcb_dev);
- if (!desc) {
+ if (!bcb_blk_desc) {
ret = -ENODEV;
goto err;
}
- ret = part_get_info(desc, bcb_part, );
+ ret = part_get_info(bcb_blk_desc, bcb_part, );
if (ret)
goto err;
cnt = DIV_ROUND_UP(sizeof(struct bootloader_message), info.blksz);
- if (blk_dwrite(desc, info.start, cnt, ) != cnt) {
+ if (blk_dwrite(bcb_blk_desc, info.start, cnt, ) != cnt) {
ret = -EIO;
goto err;
}
@@ -373,21 +373,22 @@ static int do_bcb(struct cmd_tbl *cmdtp, int flag, int
argc, char *const argv[])
U_BOOT_CMD(
bcb, CONFIG_SYS_MAXARGS, 1, do_bcb,
"Load/set/clear/test/dump/store Android BCB fields",
- "load - load BCB from mmc :\n"
- "bcb set - set BCB to \n"
- "bcb clear [] - clear BCB or all fields\n"
- "bcb test - test BCB against \n"
- "bcb dump - dump BCB \n"
- "bcb store- store BCB back to mmc\n"
+ "load[] - load BCB from
:[]\n"
+ "bcb set- set BCB to \n"
+ "bcb clear []- clear BCB or all fields\n"
+
[PATCH v2 2/2] cmd: avb: introduce optional interface parameter to avb init
From: Andrii Chepurnyi
From: Andrii Chepurnyi
Originally, avb implementation relay on mmc block devices.
The interface parameter will give the ability to use avb with
various block devices by choosing the exact interface type.
By default (if no interface parameter is provided) mmc interface
will be used.
Signed-off-by: Andrii Chepurnyi
---
cmd/avb.c| 13 +
common/avb_verify.c | 28 ++--
doc/android/avb2.rst | 2 +-
include/avb_verify.h | 11 ++-
4 files changed, 26 insertions(+), 28 deletions(-)
diff --git a/cmd/avb.c b/cmd/avb.c
index 783f51b816..6fdbdc708f 100644
--- a/cmd/avb.c
+++ b/cmd/avb.c
@@ -17,17 +17,14 @@ static struct AvbOps *avb_ops;
int do_avb_init(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
{
- unsigned long mmc_dev;
-
- if (argc != 2)
+ if (argc != 2 && argc != 3)
return CMD_RET_USAGE;
- mmc_dev = hextoul(argv[1], NULL);
-
if (avb_ops)
avb_ops_free(avb_ops);
- avb_ops = avb_ops_alloc(mmc_dev);
+ avb_ops = avb_ops_alloc(argv[1], (argc == 3) ? argv[2] : "mmc");
+
if (avb_ops)
return CMD_RET_SUCCESS;
@@ -419,7 +416,7 @@ int do_avb_write_pvalue(struct cmd_tbl *cmdtp, int flag,
int argc,
}
static struct cmd_tbl cmd_avb[] = {
- U_BOOT_CMD_MKENT(init, 2, 0, do_avb_init, "", ""),
+ U_BOOT_CMD_MKENT(init, 3, 0, do_avb_init, "", ""),
U_BOOT_CMD_MKENT(read_rb, 2, 0, do_avb_read_rb, "", ""),
U_BOOT_CMD_MKENT(write_rb, 3, 0, do_avb_write_rb, "", ""),
U_BOOT_CMD_MKENT(is_unlocked, 1, 0, do_avb_is_unlocked, "", ""),
@@ -455,7 +452,7 @@ static int do_avb(struct cmd_tbl *cmdtp, int flag, int
argc, char *const argv[])
U_BOOT_CMD(
avb, 29, 0, do_avb,
"Provides commands for testing Android Verified Boot 2.0 functionality",
- "init - initialize avb2 for \n"
+ "init [] - initialize avb2 for []\n"
"avb read_rb - read rollback index at location \n"
"avb write_rb - write rollback index to \n"
"avb is_unlocked - returns unlock status of the device\n"
diff --git a/common/avb_verify.c b/common/avb_verify.c
index 0520a71455..e086dc6760 100644
--- a/common/avb_verify.c
+++ b/common/avb_verify.c
@@ -338,7 +338,6 @@ static struct mmc_part *get_partition(AvbOps *ops, const
char *partition)
{
int ret;
u8 dev_num;
- int part_num = 0;
struct mmc_part *part;
struct blk_desc *mmc_blk;
@@ -347,22 +346,8 @@ static struct mmc_part *get_partition(AvbOps *ops, const
char *partition)
return NULL;
dev_num = get_boot_device(ops);
- part->mmc = find_mmc_device(dev_num);
- if (!part->mmc) {
- printf("No MMC device at slot %x\n", dev_num);
- goto err;
- }
-
- if (mmc_init(part->mmc)) {
- printf("MMC initialization failed\n");
- goto err;
- }
+ mmc_blk = get_blk(ops);
- ret = mmc_switch_part(part->mmc, part_num);
- if (ret)
- goto err;
-
- mmc_blk = mmc_get_blk_desc(part->mmc);
if (!mmc_blk) {
printf("Error - failed to obtain block descriptor\n");
goto err;
@@ -976,7 +961,8 @@ free_name:
* AVB2.0 AvbOps alloc/initialisation/free
*
*/
-AvbOps *avb_ops_alloc(int boot_device)
+
+AvbOps *avb_ops_alloc(const char *boot_device, const char *interface)
{
struct AvbOpsData *ops_data;
@@ -999,7 +985,13 @@ AvbOps *avb_ops_alloc(int boot_device)
ops_data->ops.read_persistent_value = read_persistent_value;
#endif
ops_data->ops.get_size_of_partition = get_size_of_partition;
- ops_data->mmc_dev = boot_device;
+ ops_data->mmc_dev = simple_strtoul(boot_device, NULL, 16);
+ ops_data->blk = NULL;
+ if (interface && (blk_get_device_by_str(interface, boot_device,
_data->blk) < 0)) {
+ printf("Error - failed to obtain block descriptor for devce=%s
if=%s\n",
+ boot_device, interface);
+ return NULL;
+ }
return _data->ops;
}
diff --git a/doc/android/avb2.rst b/doc/android/avb2.rst
index a072119574..8fa54338fd 100644
--- a/doc/android/avb2.rst
+++ b/doc/android/avb2.rst
@@ -38,7 +38,7 @@ AVB 2.0 U-Boot shell commands
Provides CLI interface to invoke AVB 2.0 verification + misc. commands for
different testing purposes::
-avb init - initialize avb 2.0 for
+avb init [] - initialize avb2 for []
avb verify - run verification process using hash data from vbmeta structure
avb read_rb - read rollback index at location
avb write_rb - write rollback index to
diff --git a/include/avb_verify.h b/include/avb_verify.h
index 1e787ba666..ff70cb26f8 100644
--- a/include/avb_verify.h
+++ b/include/avb_verify.h
@@ -32,6
[PATCH 2/2] imx: Fix build error
From: Ye Li Fix wrong environment.h and remove DECLARE_GLOBAL_DATA_PTR Fixes: 30e39ac7c9 (imx: imx7 Support for Manufacturing Protection) Signed-off-by: Ye Li Reviewed-by: Gaurav Jain --- arch/arm/mach-imx/cmd_mfgprot.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/arch/arm/mach-imx/cmd_mfgprot.c b/arch/arm/mach-imx/cmd_mfgprot.c index aed3b2f83d..ec8a8756f7 100644 --- a/arch/arm/mach-imx/cmd_mfgprot.c +++ b/arch/arm/mach-imx/cmd_mfgprot.c @@ -12,13 +12,11 @@ #include #include #include -#include +#include #include #include #include -DECLARE_GLOBAL_DATA_PTR; - /** * do_mfgprot() - Handle the "mfgprot" command-line command * @cmdtp: Command data struct pointer -- 2.25.1
[PATCH 1/2] imx: Update FSL_MFGPROT config for iMX8M
From: Ye Li Update the Kconfig and Makefile to allow build for iMX8M and restrict the build only in u-boot. Signed-off-by: Ye Li Reviewed-by: Gaurav Jain --- arch/arm/mach-imx/Kconfig | 2 +- arch/arm/mach-imx/Makefile | 4 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig index 9aa1d84336..ad0fb36502 100644 --- a/arch/arm/mach-imx/Kconfig +++ b/arch/arm/mach-imx/Kconfig @@ -137,7 +137,7 @@ config CMD_NANDBCB config FSL_MFGPROT bool "Support the 'mfgprot' command" - depends on IMX_HAB && ARCH_MX7 + depends on IMX_HAB && (ARCH_MX7 || ARCH_IMX8M) help This option enables the manufacturing protection command which can be used has a protection feature for Manufacturing diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile index 77e72702bb..aa0b6447f1 100644 --- a/arch/arm/mach-imx/Makefile +++ b/arch/arm/mach-imx/Makefile @@ -38,8 +38,12 @@ ifeq ($(SOC),$(filter $(SOC),mx7)) obj-y += cpu.o obj-$(CONFIG_SYS_I2C_MXC) += i2c-mxv7.o obj-$(CONFIG_ENV_IS_IN_MMC) += mmc_env.o +endif +ifeq ($(SOC),$(filter $(SOC),mx7 imx8m)) +ifneq ($(CONFIG_SPL_BUILD),y) obj-$(CONFIG_FSL_MFGPROT) += cmd_mfgprot.o endif +endif ifeq ($(SOC),$(filter $(SOC),mx5 mx6 mx7)) obj-$(CONFIG_IMX_VIDEO_SKIP) += video.o endif -- 2.25.1
Re: [PATCH] usb: dwc3-generic: Fix the iMX8MQ support
Hi Alban,
On 2022-04-19 01:07, Alban Bedel wrote:
The binding of iMX8MQ USB controller doesn't use child nodes like the
other devices supported in this driver. To support it split the child
nodes parsing to its own function and add a field to the platform data
to indicate that we should just use the top node.
I'm not clear on what this is fixing. Doesn't the original code deal
with a devicetree stanza that has the information in either the node or
the parent.
Which case does this fix ?
Thanks
Angus
Signed-off-by: Alban Bedel
---
drivers/usb/dwc3/dwc3-generic.c | 95 +++--
1 file changed, 56 insertions(+), 39 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-generic.c
b/drivers/usb/dwc3/dwc3-generic.c
index 01bd0ca190e3..defef43ff503 100644
--- a/drivers/usb/dwc3/dwc3-generic.c
+++ b/drivers/usb/dwc3/dwc3-generic.c
@@ -221,6 +221,7 @@ U_BOOT_DRIVER(dwc3_generic_host) = {
struct dwc3_glue_ops {
void (*select_dr_mode)(struct udevice *dev, int index,
enum usb_dr_mode mode);
+ int single_node;
};
void dwc3_ti_select_dr_mode(struct udevice *dev, int index,
@@ -307,54 +308,66 @@ struct dwc3_glue_ops ti_ops = {
.select_dr_mode = dwc3_ti_select_dr_mode,
};
+static int dwc3_glue_bind_node(struct udevice *parent, ofnode node,
+ enum usb_dr_mode dr_mode)
+{
+ const char *name = ofnode_get_name(node);
+ const char *driver = NULL;
+ struct udevice *dev;
+ int ret;
+
+ debug("%s: subnode name: %s\n", __func__, name);
+
+ /* if the parent node doesn't have a mode check the leaf */
+ if (!dr_mode)
+ dr_mode = usb_get_dr_mode(node);
+
+ switch (dr_mode) {
+ case USB_DR_MODE_PERIPHERAL:
+ case USB_DR_MODE_OTG:
+#if CONFIG_IS_ENABLED(DM_USB_GADGET)
+ debug("%s: dr_mode: OTG or Peripheral\n", __func__);
+ driver = "dwc3-generic-peripheral";
+#endif
+ break;
+#if defined(CONFIG_SPL_USB_HOST) || !defined(CONFIG_SPL_BUILD)
+ case USB_DR_MODE_HOST:
+ debug("%s: dr_mode: HOST\n", __func__);
+ driver = "dwc3-generic-host";
+ break;
+#endif
+ default:
+ debug("%s: unsupported dr_mode\n", __func__);
+ return -ENODEV;
+ };
+
+ if (!driver)
+ return 0;
+
+ ret = device_bind_driver_to_node(parent, driver, name,
+node, );
+ if (ret)
+ debug("%s: not able to bind usb device mode\n",
+ __func__);
+ return ret;
+}
+
static int dwc3_glue_bind(struct udevice *parent)
{
+ struct dwc3_glue_ops *ops = (struct dwc3_glue_ops
*)dev_get_driver_data(parent);
ofnode node;
int ret;
enum usb_dr_mode dr_mode;
+ if (ops->single_node)
+ return dwc3_glue_bind_node(parent, dev_ofnode(parent), 0);
+
dr_mode = usb_get_dr_mode(dev_ofnode(parent));
ofnode_for_each_subnode(node, dev_ofnode(parent)) {
- const char *name = ofnode_get_name(node);
- struct udevice *dev;
- const char *driver = NULL;
-
- debug("%s: subnode name: %s\n", __func__, name);
-
- /* if the parent node doesn't have a mode check the leaf */
- if (!dr_mode)
- dr_mode = usb_get_dr_mode(node);
-
- switch (dr_mode) {
- case USB_DR_MODE_PERIPHERAL:
- case USB_DR_MODE_OTG:
-#if CONFIG_IS_ENABLED(DM_USB_GADGET)
- debug("%s: dr_mode: OTG or Peripheral\n", __func__);
- driver = "dwc3-generic-peripheral";
-#endif
- break;
-#if defined(CONFIG_SPL_USB_HOST) || !defined(CONFIG_SPL_BUILD)
- case USB_DR_MODE_HOST:
- debug("%s: dr_mode: HOST\n", __func__);
- driver = "dwc3-generic-host";
- break;
-#endif
- default:
- debug("%s: unsupported dr_mode\n", __func__);
- return -ENODEV;
- };
-
- if (!driver)
- continue;
-
- ret = device_bind_driver_to_node(parent, driver, name,
-node, );
- if (ret) {
- debug("%s: not able to bind usb device mode\n",
- __func__);
+ ret = dwc3_glue_bind_node(parent, node, dr_mode);
+ if (ret)
return ret;
- }
}
return 0;
@@ -454,6 +467,10 @@ static int dwc3_glue_remove(struct udevice *dev)
return 0;
}
+struct dwc3_glue_ops single_node_ops = {
+ .single_node = 1,
+};
+
static const struct udevice_id dwc3_glue_ids[] = {
{ .compatible = "xlnx,zynqmp-dwc3" },
Re: [PATCH v2] pstore: Support already existing reserved-memory node
Hey Daniel,
I see that the node is called ramoops@0x42ff. We usually don't set the 0x
in device tree nodes, and that's why the fdt_add_subnode function doesn't see
it and add ramoops@42ff (it just compares the text). For Linux, both nodes
are the same and it complains.
I think the best course of action here is to remove that '0x' in your dts, so
that u-boot sees it as the pstore node.
Regards,
Detlev.
On Monday, April 18, 2022 7:50:36 P.M. EDT Daniel Golle wrote:
> Hi Detlev,
>
> On Mon, Apr 18, 2022 at 02:46:21PM -0400, Detlev Casanova wrote:
> > Hi Daniel,
> >
> > The patch only checks the existence of the reserved-memory node.
> >
> > I guess that before, adding the reserved-memory node failed and so nothing
> > else was happening. Now, the node is found and then, it adds the ramoops
> > subnode to it, making it double because it is already there in your case.
> >
> > But that should not happen, because the fdt_add_subnode() function should
> > fail if the node is already present (like it was failing for
> > reserved-memory).
> >
> > I'm going to look into it. Can you send me the device tree taht you are
> > using (or at least the reserved-memory part) and u-boot config ?
>
> Thank you for your reply and for taking a look at what's going on.
>
> reserved-memory bits in dts:
> https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/boot/uboot-m
> ediatek/patches/050-mt7622-enable-pstore.patch
>
> u-boot config:
> https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/boot/uboot-m
> ediatek/patches/404-add-bananapi_bpi-r64_defconfigs.patch
>
>
> Cheers
>
>
> Daniel
>
> > Detlev.
> >
> > On Monday, April 11, 2022 7:00:20 P.M. EDT Daniel Golle wrote:
> > > Hi Detlev,
> > >
> > > I've recently tried to update U-Boot from 2022.01 to 2022.04 and
> > > noticed a regression introduced by the commit below.
> > >
> > > While the unwanted error message ("Add 'reserved-memory' node failed:
> > > FDT_ERR_EXISTS") no longer appears, I now see a lengthy kernel stack
> > > trace in Linux instead:
> > > ...
> > > [0.008295] sysfs: cannot create duplicate filename
> > > '/devices/platform/42ff.ramoops' [0.008303] CPU: 0 PID: 1 Comm:
> > > swapper/0 Tainted: G S5.15.33 #0 [0.008312] Hardware
> > > name: Bananapi BPI-R64 (DT)
> > > [0.008318] Call trace:
> > > [0.008322] dump_backtrace+0x0/0x15c
> > > [0.008337] show_stack+0x14/0x30
> > > [0.008345] dump_stack_lvl+0x64/0x7c
> > > [0.008355] dump_stack+0x14/0x2c
> > > [0.008362] sysfs_warn_dup+0x5c/0x74
> > > [0.008373] sysfs_create_dir_ns+0xb0/0xc0
> > > [0.008381] kobject_add_internal+0xbc/0x330
> > > [0.008392] kobject_add+0x80/0xe0
> > > [0.008400] device_add+0xd4/0x82c
> > > [0.008410] of_device_add+0x4c/0x5c
> > > [0.008420] of_platform_device_create_pdata+0xb8/0xf0
> > > [0.008428] of_platform_default_populate_init+0x58/0xcc
> > > [0.008437] do_one_initcall+0x4c/0x1b0
> > > [0.008444] kernel_init_freeable+0x230/0x294
> > > [0.008456] kernel_init+0x20/0x120
> > > [0.008463] ret_from_fork+0x10/0x20
> > > [0.008471] kobject_add_internal failed for 42ff.ramoops with
> > > -EEXIST, don't try to register things with the same name in the same
> > > directory. ...
> > >
> > > I assume that fdt_find_or_add_subnode() doesn't behave as expected and
> > > apparently adds a duplicate node having the same name.
> > > The pstore/ramoops reserved-memory is already defined in the fdt
> > > contained in the FIT image (for compatibility with older U-Boot which
> > > didn't care about pstore), so it should be not added again.
> > >
> > > On Mon, Feb 07, 2022 at 11:02:30AM -0500, Detlev Casanova wrote:
> > > > The pstore command tries to create a reserved-memory node but fails if
> > > >
> > > > it is already present with:
> > > > Add 'reserved-memory' node failed: FDT_ERR_EXISTS
> > > >
> > > > This patch creates the node only if it does not exist and adapts the
> > > > reg
> > > > values sizes depending on already present #address-cells and
> > > > #size-cells
> > > > values.
> > > >
> > > > Signed-off-by: Detlev Casanova
> > > > ---
> > > >
> > > > Changes in v2:
> > > > - Move declarations at beginning of function
> > > > - Use if instead of switch
> > > > - Reword Subject
> > > >
> > > > cmd/pstore.c | 39 ++-
> > > > 1 file changed, 34 insertions(+), 5 deletions(-)
> > > >
> > > > diff --git a/cmd/pstore.c b/cmd/pstore.c
> > > > index 9fac8c7218..cd6f6feb2f 100644
> > > > --- a/cmd/pstore.c
> > > > +++ b/cmd/pstore.c
> > > > @@ -11,6 +11,7 @@
> > > >
> > > > #include
> > > > #include
> > > > #include
> > > >
> > > > +#include
> > > >
> > > > struct persistent_ram_buffer {
> > > >
> > > > u32sig;
> > > >
> > > > @@ -485,6 +486,8 @@ void fdt_fixup_pstore(void *blob)
> > > >
> > > > {
> > > >
> > > > char node[32];
> > > >
Re: [PATCH v2] pstore: Support already existing reserved-memory node
Hi Daniel,
On Tuesday, April 19, 2022 12:14:07 P.M. EDT Daniel Golle wrote:
> Hi Detlev,
>
> On Tue, Apr 19, 2022 at 09:58:00AM -0400, Detlev Casanova wrote:
> > Hey Daniel,
> >
> > I see that the node is called ramoops@0x42ff. We usually don't set the
> > 0x in device tree nodes, and that's why the fdt_add_subnode function
> > doesn't see it and add ramoops@42ff (it just compares the text). For
> > Linux, both nodes are the same and it complains.
> >
> > I think the best course of action here is to remove that '0x' in your dts,
> > so that u-boot sees it as the pstore node.
>
> I tried the change you suggest and remove the '0x' prefix and indeed that
> works, the lengthy kernel warning about duplicate nodes and sysfs
> entries are gone and pstore works as expected.
> I've hence committed that change to OpenWrt:
>
> https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=fc245338d6e02e61fa
> 7ecbd1a828aed97cdbef88
>
> However, now there is another error message in U-Boot output:
> Add 'ramoops@42ff' node failed: FDT_ERR_EXISTS
>
> I figured that this is not a problem as previously (ie. before your
> patch) even the exitence of the 'reserved-memory' node would result in
> the 'ramoops' node not being added while now it really just errors out
> in case of exactly that 'ramoops' node already existing, which is fine.
That's right, you can see that error message as "You activated pstore in the
config to make me add the ramoops node, but it's already there. I cannot do my
job" :)
> Thank you again for resolving this issue!
>
>
> Cheers
>
>
> Daniel
>
> > Regards,
> >
> > Detlev.
> >
> > On Monday, April 18, 2022 7:50:36 P.M. EDT Daniel Golle wrote:
> > > Hi Detlev,
> > >
> > > On Mon, Apr 18, 2022 at 02:46:21PM -0400, Detlev Casanova wrote:
> > > > Hi Daniel,
> > > >
> > > > The patch only checks the existence of the reserved-memory node.
> > > >
> > > > I guess that before, adding the reserved-memory node failed and so
> > > > nothing
> > > > else was happening. Now, the node is found and then, it adds the
> > > > ramoops
> > > > subnode to it, making it double because it is already there in your
> > > > case.
> > > >
> > > > But that should not happen, because the fdt_add_subnode() function
> > > > should
> > > > fail if the node is already present (like it was failing for
> > > > reserved-memory).
> > > >
> > > > I'm going to look into it. Can you send me the device tree taht you
> > > > are
> > > > using (or at least the reserved-memory part) and u-boot config ?
> > >
> > > Thank you for your reply and for taking a look at what's going on.
> > >
> > > reserved-memory bits in dts:
> > > https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/boot/ubo
> > > ot-m ediatek/patches/050-mt7622-enable-pstore.patch
> > >
> > > u-boot config:
> > > https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/boot/ubo
> > > ot-m ediatek/patches/404-add-bananapi_bpi-r64_defconfigs.patch
> > >
> > >
> > > Cheers
> > >
> > >
> > > Daniel
> > >
> > > > Detlev.
> > > >
> > > > On Monday, April 11, 2022 7:00:20 P.M. EDT Daniel Golle wrote:
> > > > > Hi Detlev,
> > > > >
> > > > > I've recently tried to update U-Boot from 2022.01 to 2022.04 and
> > > > > noticed a regression introduced by the commit below.
> > > > >
> > > > > While the unwanted error message ("Add 'reserved-memory' node
> > > > > failed:
> > > > > FDT_ERR_EXISTS") no longer appears, I now see a lengthy kernel stack
> > > > > trace in Linux instead:
> > > > > ...
> > > > > [0.008295] sysfs: cannot create duplicate filename
> > > > > '/devices/platform/42ff.ramoops' [0.008303] CPU: 0 PID: 1
> > > > > Comm:
> > > > > swapper/0 Tainted: G S5.15.33 #0 [0.008312]
> > > > > Hardware
> > > > > name: Bananapi BPI-R64 (DT)
> > > > > [0.008318] Call trace:
> > > > > [0.008322] dump_backtrace+0x0/0x15c
> > > > > [0.008337] show_stack+0x14/0x30
> > > > > [0.008345] dump_stack_lvl+0x64/0x7c
> > > > > [0.008355] dump_stack+0x14/0x2c
> > > > > [0.008362] sysfs_warn_dup+0x5c/0x74
> > > > > [0.008373] sysfs_create_dir_ns+0xb0/0xc0
> > > > > [0.008381] kobject_add_internal+0xbc/0x330
> > > > > [0.008392] kobject_add+0x80/0xe0
> > > > > [0.008400] device_add+0xd4/0x82c
> > > > > [0.008410] of_device_add+0x4c/0x5c
> > > > > [0.008420] of_platform_device_create_pdata+0xb8/0xf0
> > > > > [0.008428] of_platform_default_populate_init+0x58/0xcc
> > > > > [0.008437] do_one_initcall+0x4c/0x1b0
> > > > > [0.008444] kernel_init_freeable+0x230/0x294
> > > > > [0.008456] kernel_init+0x20/0x120
> > > > > [0.008463] ret_from_fork+0x10/0x20
> > > > > [0.008471] kobject_add_internal failed for 42ff.ramoops with
> > > > > -EEXIST, don't try to register things with the same name in the same
> > > > > directory. ...
> > > > >
> > > > > I assume that fdt_find_or_add_subnode() doesn't behave as expected
> > > > > and
[PATCH] include: configs: am**x/j721e/j721s2_evm.h: Move the stack pointer init address in arm64
Currently, in case of arm64 bootloader and U-Boot the stack pointer is initialized at an offset of NON_SECURE_MSRAM_SIZE from arm64 SPL's text base address. After jumping to arm64, execution is done out of DDR. Therefore, having an offset corresponding to the size of MSRAM does not have any significance. Instead, initialize the stack pointer after an offset of 4MB from the SPL text base address. This helps in allocating larger memory for stack. ┌┐0x8008 ││ │ arm64 SPL│ ├┤ │▲ │ ││ │ │ STACK │ ├┤0x8048 │ Memory for Load│ │ Buffer Allocation │ ├┤0x8080 ││ │U-Boot Image│ ││ └┘ Signed-off-by: Aswath Govindraju --- Notes: - Verified SD and DFU boot modes on platforms where this change will have an effect and are supported - AM64 - SD boot mode, https://pastebin.ubuntu.com/p/YDBjhTqwSK/ - DFU boot mode, https://pastebin.ubuntu.com/p/Xsjn4h7h2W/ - "Error setting up memory banksize. -22" This error was present even without the changes done by this patch - J721e - SD boot mode, https://pastebin.ubuntu.com/p/NpVvKjMMxc/ - DFU boot mode, https://pastebin.ubuntu.com/p/MZPS4Wmkj5/ - J7200 - SD boot mode, https://pastebin.ubuntu.com/p/QyyC8WFsS2/ - DFU boot mode, https://pastebin.ubuntu.com/p/Nmjf3mVRyH/ - J721s2 - SD boot mode, https://pastebin.ubuntu.com/p/xh96CP8ndB/ - AM654 - SD boot mode, https://pastebin.ubuntu.com/p/DbFjFSvj2C/ include/configs/am64x_evm.h | 3 +-- include/configs/am65x_evm.h | 3 +-- include/configs/j721e_evm.h | 3 +-- include/configs/j721s2_evm.h | 3 +-- 4 files changed, 4 insertions(+), 8 deletions(-) diff --git a/include/configs/am64x_evm.h b/include/configs/am64x_evm.h index 135cb3c2ee20..d84a8db97ede 100644 --- a/include/configs/am64x_evm.h +++ b/include/configs/am64x_evm.h @@ -24,8 +24,7 @@ #define CONFIG_SPL_MAX_SIZECONFIG_SYS_K3_MAX_DOWNLODABLE_IMAGE_SIZE #if defined(CONFIG_TARGET_AM642_A53_EVM) -#define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SPL_TEXT_BASE +\ - CONFIG_SYS_K3_NON_SECURE_MSRAM_SIZE - 4) +#define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SPL_TEXT_BASE + SZ_4M) #else /* * Maximum size in memory allocated to the SPL BSS. Keep it as tight as diff --git a/include/configs/am65x_evm.h b/include/configs/am65x_evm.h index 55fa6419e33d..b1f9050f3f5b 100644 --- a/include/configs/am65x_evm.h +++ b/include/configs/am65x_evm.h @@ -19,8 +19,7 @@ /* SPL Loader Configuration */ #ifdef CONFIG_TARGET_AM654_A53_EVM -#define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SPL_TEXT_BASE +\ -CONFIG_SYS_K3_NON_SECURE_MSRAM_SIZE) +#define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SPL_TEXT_BASE + SZ_4M) #else /* * Maximum size in memory allocated to the SPL BSS. Keep it as tight as diff --git a/include/configs/j721e_evm.h b/include/configs/j721e_evm.h index df3c16540ba3..2590ee6b0140 100644 --- a/include/configs/j721e_evm.h +++ b/include/configs/j721e_evm.h @@ -20,8 +20,7 @@ /* SPL Loader Configuration */ #if defined(CONFIG_TARGET_J721E_A72_EVM) || defined(CONFIG_TARGET_J7200_A72_EVM) -#define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SPL_TEXT_BASE +\ -CONFIG_SYS_K3_NON_SECURE_MSRAM_SIZE) +#define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SPL_TEXT_BASE + SZ_4M) #define CONFIG_SYS_UBOOT_BASE 0x5028 /* Image load address in RAM for DFU boot*/ #else diff --git a/include/configs/j721s2_evm.h b/include/configs/j721s2_evm.h index f0d56b8778ee..a5505f079b43 100644 --- a/include/configs/j721s2_evm.h +++ b/include/configs/j721s2_evm.h @@ -21,8 +21,7 @@ /* SPL Loader Configuration */ #if defined(CONFIG_TARGET_J721S2_A72_EVM) || defined(CONFIG_TARGET_J7200_A72_EVM) -#define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SPL_TEXT_BASE +\ -CONFIG_SYS_K3_NON_SECURE_MSRAM_SIZE) +#define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SPL_TEXT_BASE + SZ_4M) #define CONFIG_SYS_UBOOT_BASE 0x5028 /* Image load address in RAM for DFU boot*/ #else -- 2.17.1
[PATCH] i.MX8 crypto/fsl: Enable fsl CAAM rng driver
rng driver enabled to read random number using caam.
Signed-off-by: Gaurav Jain
---
drivers/crypto/fsl/jr.c | 8 +++-
drivers/crypto/fsl/rng.c | 8 +++-
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/fsl/jr.c b/drivers/crypto/fsl/jr.c
index 85a3dac796..acd29924f7 100644
--- a/drivers/crypto/fsl/jr.c
+++ b/drivers/crypto/fsl/jr.c
@@ -767,8 +767,14 @@ init:
return -1;
}
#if CONFIG_IS_ENABLED(OF_CONTROL)
- if (ofnode_valid(scu_node))
+ if (ofnode_valid(scu_node)) {
+ if (IS_ENABLED(CONFIG_DM_RNG)) {
+ ret = device_bind_driver(NULL, "caam-rng", "caam-rng",
NULL);
+ if (ret)
+ printf("Couldn't bind rng driver (%d)\n", ret);
+ }
return ret;
+ }
#endif
#ifdef CONFIG_FSL_CORENET
diff --git a/drivers/crypto/fsl/rng.c b/drivers/crypto/fsl/rng.c
index 0636494805..b568c337a6 100644
--- a/drivers/crypto/fsl/rng.c
+++ b/drivers/crypto/fsl/rng.c
@@ -26,10 +26,16 @@ struct caam_rng_priv {
static int caam_rng_read_one(struct caam_rng_priv *priv)
{
+ struct udevice *dev;
int size = ALIGN(CAAM_RNG_MAX_FIFO_STORE_SIZE, ARCH_DMA_MINALIGN);
int ret;
- ret = run_descriptor_jr(priv->desc);
+ if (uclass_get_device_by_driver(UCLASS_MISC, DM_DRIVER_GET(caam_jr),
) || !dev) {
+ printf("No CAAM device\n");
+ return -ENODEV;
+ }
+
+ ret = misc_ioctl(dev, CAAM_JR_RUN_DESC, priv->desc);
if (ret < 0)
return -EIO;
--
2.25.1
Re: [PATCH] Convert CONFIG_SYS_MEM_TOP_HIDE to Kconfig
On Tue, Apr 19, 2022 at 02:01:02PM +0200, Michal Simek wrote: > This converts CONFIG_SYS_MEM_TOP_HIDE to Kconfig to be able to enable it > also for other boards. > Help text description is taken from comment in common/board_f.c. > It also slightly change behavior because every board defines it as 0x0 now > that's why code is enabled by default but compiler should remove it if not > defined. > > Signed-off-by: Michal Simek I sent https://patchwork.ozlabs.org/project/uboot/patch/20220406143332.4057117-1-tr...@konsulko.com/ recently do to this. And yes, a default of 0x0 works, I used CONFIG_VAL(..) to evaluate it instead, but either would be fine. -- Tom signature.asc Description: PGP signature
Re: [PATCH] Convert CONFIG_SYS_MEM_TOP_HIDE to Kconfig
On 4/19/22 16:25, Tom Rini wrote: On Tue, Apr 19, 2022 at 02:01:02PM +0200, Michal Simek wrote: This converts CONFIG_SYS_MEM_TOP_HIDE to Kconfig to be able to enable it also for other boards. Help text description is taken from comment in common/board_f.c. It also slightly change behavior because every board defines it as 0x0 now that's why code is enabled by default but compiler should remove it if not defined. Signed-off-by: Michal Simek I sent https://patchwork.ozlabs.org/project/uboot/patch/20220406143332.4057117-1-tr...@konsulko.com/ recently do to this. And yes, a default of 0x0 works, I used CONFIG_VAL(..) to evaluate it instead, but either would be fine. ok. Good then please ignore this one. M
Re: [PATCH v2] pstore: Support already existing reserved-memory node
Hi Detlev,
On Tue, Apr 19, 2022 at 09:58:00AM -0400, Detlev Casanova wrote:
> Hey Daniel,
>
> I see that the node is called ramoops@0x42ff. We usually don't set the 0x
> in device tree nodes, and that's why the fdt_add_subnode function doesn't see
> it and add ramoops@42ff (it just compares the text). For Linux, both
> nodes
> are the same and it complains.
>
> I think the best course of action here is to remove that '0x' in your dts, so
> that u-boot sees it as the pstore node.
I tried the change you suggest and remove the '0x' prefix and indeed that
works, the lengthy kernel warning about duplicate nodes and sysfs
entries are gone and pstore works as expected.
I've hence committed that change to OpenWrt:
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=fc245338d6e02e61fa7ecbd1a828aed97cdbef88
However, now there is another error message in U-Boot output:
Add 'ramoops@42ff' node failed: FDT_ERR_EXISTS
I figured that this is not a problem as previously (ie. before your
patch) even the exitence of the 'reserved-memory' node would result in
the 'ramoops' node not being added while now it really just errors out
in case of exactly that 'ramoops' node already existing, which is fine.
Thank you again for resolving this issue!
Cheers
Daniel
>
> Regards,
>
> Detlev.
>
> On Monday, April 18, 2022 7:50:36 P.M. EDT Daniel Golle wrote:
> > Hi Detlev,
> >
> > On Mon, Apr 18, 2022 at 02:46:21PM -0400, Detlev Casanova wrote:
> > > Hi Daniel,
> > >
> > > The patch only checks the existence of the reserved-memory node.
> > >
> > > I guess that before, adding the reserved-memory node failed and so nothing
> > > else was happening. Now, the node is found and then, it adds the ramoops
> > > subnode to it, making it double because it is already there in your case.
> > >
> > > But that should not happen, because the fdt_add_subnode() function should
> > > fail if the node is already present (like it was failing for
> > > reserved-memory).
> > >
> > > I'm going to look into it. Can you send me the device tree taht you are
> > > using (or at least the reserved-memory part) and u-boot config ?
> >
> > Thank you for your reply and for taking a look at what's going on.
> >
> > reserved-memory bits in dts:
> > https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/boot/uboot-m
> > ediatek/patches/050-mt7622-enable-pstore.patch
> >
> > u-boot config:
> > https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/boot/uboot-m
> > ediatek/patches/404-add-bananapi_bpi-r64_defconfigs.patch
> >
> >
> > Cheers
> >
> >
> > Daniel
> >
> > > Detlev.
> > >
> > > On Monday, April 11, 2022 7:00:20 P.M. EDT Daniel Golle wrote:
> > > > Hi Detlev,
> > > >
> > > > I've recently tried to update U-Boot from 2022.01 to 2022.04 and
> > > > noticed a regression introduced by the commit below.
> > > >
> > > > While the unwanted error message ("Add 'reserved-memory' node failed:
> > > > FDT_ERR_EXISTS") no longer appears, I now see a lengthy kernel stack
> > > > trace in Linux instead:
> > > > ...
> > > > [0.008295] sysfs: cannot create duplicate filename
> > > > '/devices/platform/42ff.ramoops' [0.008303] CPU: 0 PID: 1 Comm:
> > > > swapper/0 Tainted: G S5.15.33 #0 [0.008312] Hardware
> > > > name: Bananapi BPI-R64 (DT)
> > > > [0.008318] Call trace:
> > > > [0.008322] dump_backtrace+0x0/0x15c
> > > > [0.008337] show_stack+0x14/0x30
> > > > [0.008345] dump_stack_lvl+0x64/0x7c
> > > > [0.008355] dump_stack+0x14/0x2c
> > > > [0.008362] sysfs_warn_dup+0x5c/0x74
> > > > [0.008373] sysfs_create_dir_ns+0xb0/0xc0
> > > > [0.008381] kobject_add_internal+0xbc/0x330
> > > > [0.008392] kobject_add+0x80/0xe0
> > > > [0.008400] device_add+0xd4/0x82c
> > > > [0.008410] of_device_add+0x4c/0x5c
> > > > [0.008420] of_platform_device_create_pdata+0xb8/0xf0
> > > > [0.008428] of_platform_default_populate_init+0x58/0xcc
> > > > [0.008437] do_one_initcall+0x4c/0x1b0
> > > > [0.008444] kernel_init_freeable+0x230/0x294
> > > > [0.008456] kernel_init+0x20/0x120
> > > > [0.008463] ret_from_fork+0x10/0x20
> > > > [0.008471] kobject_add_internal failed for 42ff.ramoops with
> > > > -EEXIST, don't try to register things with the same name in the same
> > > > directory. ...
> > > >
> > > > I assume that fdt_find_or_add_subnode() doesn't behave as expected and
> > > > apparently adds a duplicate node having the same name.
> > > > The pstore/ramoops reserved-memory is already defined in the fdt
> > > > contained in the FIT image (for compatibility with older U-Boot which
> > > > didn't care about pstore), so it should be not added again.
> > > >
> > > > On Mon, Feb 07, 2022 at 11:02:30AM -0500, Detlev Casanova wrote:
> > > > > The pstore command tries to create a reserved-memory node but fails if
> > > > >
> > > > > it is already present with:
> > > > > Add 'reserved-memory' node
[PATCH v3] bosch: Add initial board support for ACC
The Bosch ACC (Air Center Control) Board is based on the i.MX6D.
Signed-off-by: Philip Oberfichtner
---
Changes in v3:
- Rename acc to bosch-acc
- Sync device tree with Linux
Changes in v2:
- Adapt defconfig and device tree to new bootcount driver
- Clean up CONFIG_ENV_FLAGS_LIST_STATIC
- Fix style issues in device trees
- Migrate CONFIG options to Kconfig
This board supports depends on:
- "Add pmic bootcount driver", patchwork id 291027
- "crypto/fsl: Fallback to SW sha1/256 is misaligned buffers",
patchwork id 270524
- Linux Device Tree patch, see below
The Device Tree is currently being mainlined into Linux. The
DT in this board support patch will be kept in sync as the DT
patch for Linux evolves. The Linux patch is tracked under
http://patchwork.ozlabs.org/project/devicetree-bindings/list/?series=294727
The only difference compared to the Linux DT is the removal of
usbphynop properties. They are defined in the Linux version of
imx6qdl.dtsi, but not in the u-boot version.
---
arch/arm/dts/Makefile|1 +
arch/arm/dts/imx6q-bosch-acc-u-boot.dtsi | 80 ++
arch/arm/dts/imx6q-bosch-acc.dts | 1036 ++
arch/arm/mach-imx/mx6/Kconfig| 15 +
board/bosch/acc/Kconfig | 19 +
board/bosch/acc/MAINTAINERS |9 +
board/bosch/acc/Makefile |6 +
board/bosch/acc/acc.c| 755
configs/imx6q_bosch_acc_defconfig| 110 +++
include/configs/imx6q-bosch-acc.h| 128 +++
10 files changed, 2159 insertions(+)
create mode 100644 arch/arm/dts/imx6q-bosch-acc-u-boot.dtsi
create mode 100644 arch/arm/dts/imx6q-bosch-acc.dts
create mode 100644 board/bosch/acc/Kconfig
create mode 100644 board/bosch/acc/MAINTAINERS
create mode 100644 board/bosch/acc/Makefile
create mode 100644 board/bosch/acc/acc.c
create mode 100644 configs/imx6q_bosch_acc_defconfig
create mode 100644 include/configs/imx6q-bosch-acc.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 644ba961a2..418e0ee655 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -768,6 +768,7 @@ endif
ifneq ($(CONFIG_MX6Q)$(CONFIG_MX6QDL),)
dtb-y += \
imx6-apalis.dtb \
+ imx6q-bosch-acc.dtb \
imx6q-cm-fx6.dtb \
imx6q-cubox-i.dtb \
imx6q-cubox-i-emmc-som-v15.dtb \
diff --git a/arch/arm/dts/imx6q-bosch-acc-u-boot.dtsi
b/arch/arm/dts/imx6q-bosch-acc-u-boot.dtsi
new file mode 100644
index 00..37c182d318
--- /dev/null
+++ b/arch/arm/dts/imx6q-bosch-acc-u-boot.dtsi
@@ -0,0 +1,80 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/* Copyright (C) 2022 Denx Software Engineering GmbH
+ * Philip Oberfichtner
+ */
+
+/ {
+ chosen {
+ stdout-path =
+ };
+
+ soc {
+ u-boot,dm-spl;
+
+ bus@200 {
+ u-boot,dm-spl;
+
+ spba-bus@200 {
+ u-boot,dm-spl;
+ };
+ };
+
+ bus@210 {
+ u-boot,dm-spl;
+ };
+ };
+
+ bootcount {
+ compatible = "u-boot,bootcount-pmic";
+ pmic = <>;
+ };
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
diff --git a/arch/arm/dts/imx6q-bosch-acc.dts b/arch/arm/dts/imx6q-bosch-acc.dts
new file mode 100644
index 00..d0f6ba0cc4
--- /dev/null
+++ b/arch/arm/dts/imx6q-bosch-acc.dts
@@ -0,0 +1,1036 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Support for the i.MX6-based Bosch ACC board.
+ *
+ * Copyright (C) 2016 Garz & Fricke GmbH
+ * Copyright (C) 2018 DENX Software Engineering GmbH, Heiko Schocher
+ * Copyright (C) 2018 DENX Software Engineering GmbH, Niel Fourie
+ * Copyright (C) 2019-2021 Bosch Thermotechnik GmbH, Matthias Winker
+ */
+
+/dts-v1/;
+
+#include
+#include "imx6q.dtsi"
+
+/ {
+ model = "Bosch ACC";
+ compatible = "bosch,imx6q-acc", "fsl,imx6q";
+
+ aliases {
+ serial0 =
+ serial1 =
+
+ i2c0 =
+ i2c1 =
+ i2c2 =
+ /* eMMC is connected to USDHC interface 4, but shall get the
name 0 */
+ mmc0 =
+ /* SC-Cards is connected to USDHC interface 2, but shall get
the name 1 */
+ mmc1 =
+ };
+
+ backlight {
+ status = "okay";
+
+ compatible = "pwm-backlight";
+ /* The last value is the PWM period in nano-seconds!
+* -> 5 kHz = 200 µS = 200.000 ns
+*/
+
Re: Pull request: u-boot-rockchip-20220418
On Tue, Apr 19, 2022 at 05:17:05PM +0800, Kever Yang wrote: > Hi Tom, > > Please pull the rockchip updates: > - Add rk3066 SoC support; > - Add rk3066 MK808 board support; > - dts sync from kernel for rk322x, rk3288; > - some other board level config update; > > Gitlab ci: > https://source.denx.de/u-boot/custodians/u-boot-rockchip/-/pipelines/11773 > > Thanks, > - Kever > > The following changes since commit 9859465bfe838bc8264d45e1a1bed847bba74bad: > > Merge tag 'efi-2022-07-rc1-2' of > https://source.denx.de/u-boot/custodians/u-boot-efi (2022-04-15 14:29:52 > -0400) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-rockchip.git > tags/u-boot-rockchip-20220418 > > for you to fetch changes up to dcaaefdc0a7b3052e513b0e5dd2b00be4436386b: > > rockchip: video: mipi: add more compatible strings for rk3288/rk3399 > (2022-04-18 11:25:13 +0800) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
[PATCH 1/1] dm: fix formatting of uclass dump
Insert an empty line after each uclass independent of whether it has
devices or not.
Signed-off-by: Heinrich Schuchardt
---
drivers/core/dump.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/core/dump.c b/drivers/core/dump.c
index f2f9cacc56..253e5bb4b5 100644
--- a/drivers/core/dump.c
+++ b/drivers/core/dump.c
@@ -89,8 +89,6 @@ void dm_dump_uclass(void)
continue;
printf("uclass %d: %s\n", id, uc->uc_drv->name);
- if (list_empty(>dev_head))
- continue;
uclass_foreach_dev(dev, uc) {
dm_display_line(dev, i);
i++;
--
2.34.1
Re: [PATCH] nds32: Remove the architecture
On Wed, Apr 06, 2022 at 09:21:25AM -0400, Tom Rini wrote: > As removal of nds32 has been ack'd for the Linux kernel, remove support > here as well. > > Cc: Rick Chen > Signed-off-by: Tom Rini Ping? -- Tom signature.asc Description: PGP signature
Re: tools/image-host.c build error
On Tue, Apr 19, 2022 at 09:02:14PM +0200, Mark Kettenis wrote: > Hello Philippe, > > commit 6e052d1cbafbedbfba73070da483111f2ae68e5a broke building u-boot > on OpenBSD: > > tools/image-host.c:1208:10: error: use of undeclared identifier 'ENODATA' > > The problem here is that ENODATA isn't in POSIX proper (it is part of > the obsolete XSI STREAMS option so typically absent on systems with > BSD heritage). So ENODATA should not be used in the host tools that > are part of U-Boot. I would simply replace it with EINVAL, but maybe > you have a different opinion. > > I can send a proper patch if so desired. Please do. Sadly, I don't see BSD host options in Azure, which is where we have our Windows/macOS build tests done. -- Tom signature.asc Description: PGP signature
Re: [PATCH 2/2] arm: layerscape: Disable erratum A009007 on LS1021A, LS1043A, and LS1046A
On 2/22/22 1:38 PM, Sean Anderson wrote: > This erratum is reported to cause problems on these processors [1-3]. > The problem is usually with the clocking, which is supposed to be > configured by the RCW [4]. However, if it is not set, or if the default > clocking is not correct, then this erratum will cause an SError. > However, according to Ran Wang in [1]: > >> ... this erratum is used to pass USB compliance test only, you could >> disable this workaround on your board if you don't any USB issue on >> normal use case, I think it's fine. > > So just disable this erratum by default for these processors. > > [1] https://lore.kernel.org/all/761ddd61-05c1-d9b8-ac90-b8f425afd...@denx.de/ > [2] > https://community.nxp.com/t5/Layerscape/LS1046A-U-BOOT-HALT-AT-ERRATUM-A0090078/m-p/742993 > [3] > https://community.nxp.com/t5/QorIQ/Why-does-the-LS1043A-U-Boot-hang-at-code-that-fixes-erratum/m-p/644412 > [4] > https://source.codeaurora.org/external/qoriq/qoriq-components/rcw/tree/ls1046ardb/usb_phy_freq.rcw > > Signed-off-by: Sean Anderson > --- > > arch/arm/cpu/armv7/ls102xa/Kconfig| 1 - > arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 2 -- > 2 files changed, 3 deletions(-) > > diff --git a/arch/arm/cpu/armv7/ls102xa/Kconfig > b/arch/arm/cpu/armv7/ls102xa/Kconfig > index 6a948d7ba7..cec93a27db 100644 > --- a/arch/arm/cpu/armv7/ls102xa/Kconfig > +++ b/arch/arm/cpu/armv7/ls102xa/Kconfig > @@ -7,7 +7,6 @@ config ARCH_LS1021A > select SYS_FSL_ERRATUM_A008407 > select SYS_FSL_ERRATUM_A008850 > select SYS_FSL_ERRATUM_A008997 if USB > - select SYS_FSL_ERRATUM_A009007 if USB > select SYS_FSL_ERRATUM_A009008 if USB > select SYS_FSL_ERRATUM_A009663 > select SYS_FSL_ERRATUM_A009798 if USB > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig > b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig > index 9bb870dcd8..f5a18053e6 100644 > --- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig > +++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig > @@ -74,7 +74,6 @@ config ARCH_LS1043A > select SYS_FSL_DDR_VER_50 > select SYS_FSL_ERRATUM_A008850 if !TFABOOT > select SYS_FSL_ERRATUM_A008997 > - select SYS_FSL_ERRATUM_A009007 > select SYS_FSL_ERRATUM_A009008 > select SYS_FSL_ERRATUM_A009660 if !TFABOOT > select SYS_FSL_ERRATUM_A009663 if !TFABOOT > @@ -112,7 +111,6 @@ config ARCH_LS1046A > select SYS_FSL_ERRATUM_A008511 if !TFABOOT > select SYS_FSL_ERRATUM_A008850 if !TFABOOT > select SYS_FSL_ERRATUM_A008997 > - select SYS_FSL_ERRATUM_A009007 > select SYS_FSL_ERRATUM_A009008 > select SYS_FSL_ERRATUM_A009798 > select SYS_FSL_ERRATUM_A009801 > ping? Can someone from NXP comment on this (either for or against)? --Sean
[PATCH] usb: xhci-dwc3: Support role switch default role
When the device tree indicates support for role switching through
the "usb-role-switch" property, take the "role-switch-default-mode"
property into account when deciding which role to put the
controller into.
This makes USB devices work on Apple M1 systems where the device
tree may include a "dr_mode" property that is set to "otg", but
where we need to put the controller into "host" mode to see
devices connected to the type-C ports.
Signed-off-by: Mark Kettenis
---
drivers/usb/common/common.c | 16
drivers/usb/host/xhci-dwc3.c | 6 ++
include/linux/usb/otg.h | 10 ++
3 files changed, 32 insertions(+)
diff --git a/drivers/usb/common/common.c b/drivers/usb/common/common.c
index ee0c064f1f..cff86a51ae 100644
--- a/drivers/usb/common/common.c
+++ b/drivers/usb/common/common.c
@@ -40,6 +40,22 @@ enum usb_dr_mode usb_get_dr_mode(ofnode node)
return USB_DR_MODE_UNKNOWN;
}
+enum usb_dr_mode usb_get_role_switch_default_mode(ofnode node)
+{
+ const char *dr_mode;
+ int i;
+
+ dr_mode = ofnode_read_string(node, "role-switch-default-mode");
+ if (!dr_mode)
+ return USB_DR_MODE_UNKNOWN;
+
+ for (i = 0; i < ARRAY_SIZE(usb_dr_modes); i++)
+ if (!strcmp(dr_mode, usb_dr_modes[i]))
+ return i;
+
+ return USB_DR_MODE_UNKNOWN;
+}
+
static const char *const speed_names[] = {
[USB_SPEED_UNKNOWN] = "UNKNOWN",
[USB_SPEED_LOW] = "low-speed",
diff --git a/drivers/usb/host/xhci-dwc3.c b/drivers/usb/host/xhci-dwc3.c
index bec0d98081..1dbd65dfaa 100644
--- a/drivers/usb/host/xhci-dwc3.c
+++ b/drivers/usb/host/xhci-dwc3.c
@@ -209,6 +209,12 @@ static int xhci_dwc3_probe(struct udevice *dev)
writel(reg, _reg->g_usb2phycfg[0]);
dr_mode = usb_get_dr_mode(dev_ofnode(dev));
+ if (dr_mode == USB_DR_MODE_OTG &&
+ dev_read_bool(dev, "usb-role-switch")) {
+ dr_mode = usb_get_role_switch_default_mode(dev_ofnode(dev));
+ if (dr_mode == USB_DR_MODE_UNKNOWN)
+ dr_mode = USB_DR_MODE_OTG;
+ }
if (dr_mode == USB_DR_MODE_UNKNOWN)
/* by default set dual role mode to HOST */
dr_mode = USB_DR_MODE_HOST;
diff --git a/include/linux/usb/otg.h b/include/linux/usb/otg.h
index c19b916be9..5d0dac950e 100644
--- a/include/linux/usb/otg.h
+++ b/include/linux/usb/otg.h
@@ -27,6 +27,16 @@ enum usb_dr_mode {
*/
enum usb_dr_mode usb_get_dr_mode(ofnode node);
+/**
+ * usb_get_dr_mode() - Get dual role mode for given device
+ * @node: ofnode of the given device
+ *
+ * The function gets phy interface string from property
+ * 'role-switch-defaulr-mode', and returns the correspondig enum
+ * usb_dr_mode
+ */
+enum usb_dr_mode usb_get_role_switch_default_mode(ofnode node);
+
/**
* usb_get_maximum_speed() - Get maximum speed for given device
* @node: ofnode of the given device
--
2.35.1
[PATCH] arm: apple: Point stdout-path to framebuffer when keyboard present
Unless you have a spare Apple Silicon machine, getting access to
the serial port on Apple Silicon machines requires special
hardware. Given that most machines come with a built-in screen
the framebuffer is likely to be the most convenient output device
for most users. While U-Boot will output to both serial and
framebuffer, OSes might not. Therefore set stdout-path to point
at /chosen/framebuffer when a keyboard is connected to the machine.
This behaviour can be overridden by setting the "stdout" variable
in the U-Boot environment. I addition to that keep the serial
console as the default when running under the m1n1 hypervisor.
The m1n1 hypervisor virtualizes the serial port such that it
can be easily accessed from any other machine with a USB port.
Signed-off-by: Mark Kettenis
Reviewed-by: Janne Grunau
Tested-by: Janne Grunau
---
arch/arm/Kconfig| 1 +
arch/arm/mach-apple/board.c | 40 +
2 files changed, 41 insertions(+)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index efe33a58e1..138ba1b073 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -994,6 +994,7 @@ config ARCH_APPLE
select DM_VIDEO
select IOMMU
select LINUX_KERNEL_IMAGE_HEADER
+ select OF_BOARD_SETUP
select OF_CONTROL
select PINCTRL
select POSITION_INDEPENDENT
diff --git a/arch/arm/mach-apple/board.c b/arch/arm/mach-apple/board.c
index ffc1301cf5..1525a9edee 100644
--- a/arch/arm/mach-apple/board.c
+++ b/arch/arm/mach-apple/board.c
@@ -5,6 +5,7 @@
#include
#include
+#include
#include
#include
@@ -461,3 +462,42 @@ int board_late_init(void)
return 0;
}
+
+int ft_board_setup(void *blob, struct bd_info *bd)
+{
+ struct udevice *dev;
+ const char *stdoutname;
+ int node, ret;
+
+ /*
+* Modify the "stdout-path" property under "/chosen" to point
+* at "/chosen/framebuffer if a keyboard is available and
+* we're not running under the m1n1 hypervisor.
+* Developers can override this behaviour by dropping
+* "vidconsole" from the "stdout" environment variable.
+*/
+
+ /* EL1 means we're running under the m1n1 hypervisor. */
+ if (current_el() == 1)
+ return 0;
+
+ ret = uclass_find_device(UCLASS_KEYBOARD, 0, );
+ if (ret < 0)
+ return 0;
+
+ stdoutname = env_get("stdout");
+ if (!stdoutname || !strstr(stdoutname, "vidconsole"))
+ return 0;
+
+ /* Make sure we actually have a framebuffer. */
+ node = fdt_path_offset(blob, "/chosen/framebuffer");
+ if (node < 0 || !fdtdec_get_is_enabled(blob, node))
+ return 0;
+
+ node = fdt_path_offset(blob, "/chosen");
+ if (node < 0)
+ return 0;
+ fdt_setprop_string(blob, node, "stdout-path", "/chosen/framebuffer");
+
+ return 0;
+}
--
2.35.1
tools/image-host.c build error
Hello Philippe, commit 6e052d1cbafbedbfba73070da483111f2ae68e5a broke building u-boot on OpenBSD: tools/image-host.c:1208:10: error: use of undeclared identifier 'ENODATA' The problem here is that ENODATA isn't in POSIX proper (it is part of the obsolete XSI STREAMS option so typically absent on systems with BSD heritage). So ENODATA should not be used in the host tools that are part of U-Boot. I would simply replace it with EINVAL, but maybe you have a different opinion. I can send a proper patch if so desired. Thanks, Mark
[PATCH] misc: Fix always compiling MISC even for SPL/TPL
We should only build support for misc if the appropriate SPL/TPL symbol
is defined.
Fixes: aaba703fd0 ("spl: misc: Allow misc drivers in SPL and TPL")
Signed-off-by: Sean Anderson
---
drivers/misc/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index f22eff601a..b7a8ef68ab 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -3,7 +3,7 @@
# (C) Copyright 2000-2007
# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
-obj-$(CONFIG_MISC) += misc-uclass.o
+obj-$(CONFIG_$(SPL_TPL_)MISC) += misc-uclass.o
obj-$(CONFIG_$(SPL_TPL_)CROS_EC) += cros_ec.o
obj-$(CONFIG_$(SPL_TPL_)CROS_EC_SANDBOX) += cros_ec_sandbox.o
--
2.35.1.1320.gc452695387.dirty
[PATCH] arm: apple: Don't clear framebuffer
Enable CONFIG_NO_FB_CLEAR to preserve the Asahi logo. Since that logo is drawn on a black background also enable CONFIG_SYS_WHITE_ON_BLACK such that text printed by U-Boot is still visible. Signed-off-by: Mark Kettenis --- configs/apple_m1_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configs/apple_m1_defconfig b/configs/apple_m1_defconfig index b73e54111d..886fc4a6fe 100644 --- a/configs/apple_m1_defconfig +++ b/configs/apple_m1_defconfig @@ -13,5 +13,7 @@ CONFIG_NVME_APPLE=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_USB_KEYBOARD=y +CONFIG_SYS_WHITE_ON_BLACK=y +CONFIG_NO_FB_CLEAR=y CONFIG_VIDEO_SIMPLE=y # CONFIG_GENERATE_SMBIOS_TABLE is not set -- 2.35.1
Re: Handle unaligned read at fs layer?
On Sat, Apr 16, 2022 at 08:54:48AM +0800, Qu Wenruo wrote: > Hi U-boot fs guys, > > With my previous rework on U-boot btrfs, and my own btrfs-fuse project, > it turns out that, although U-boot implements its fs with a very fuse > like interface, there are still some quality-of-life features missing. > > One of the most obvious one is making each fs to handle unaligned read. > > This is especially obvious when comparing btrfs-fuse btrfs_file_read() > against U-boot btrfs_file_read(). > > They share almost the same main loop, but btrfs_file_read() in U-boot > have two extra handling, for unaligned leading sector and unaligned > tailing sector. > > > So I just did a quick check on the other fses, it turns out that we have > a very different behaviors: > > - FAT > - Ext4 > Have the handling for both tailing and ending block. > > - Btrfs > My code, doing unaligned leading/tailing block manually. > (the tailing part looks unnecessary though) > > - Ubifs > Explicitly reject read with non-aligned offset. > > - Squshfs > Explicitly reject read with non-zero offset. > > - Erofs > Have the handling for tailing unaligned part, but doesn't seem to > handle unaligned start part. > > Thus if we have a proper common routine for unaligned read routine (get > the file length, read the first and the last unaligned block, then let > the .read callback to handle the aligned range), then all fs drivers > would have a much better life. > > Mind me to do such small but quality-of-life improve for all involved fses? > (This will need a new call back to query the blocksize of each fs though) If it seems like something that would generally improve fs support, and I think that's what you're saying here, yes, please. Thanks. -- Tom signature.asc Description: PGP signature
Re: Falcon Mode Support For Uncompressed Kernel Images
On Wed, Feb 02, 2022 at 04:53:11PM -0500, Nathan Barrett-Morrison wrote:
> Hi Tom,
>
> I've attached version 2 of the patch. I believe this should adhere more
> closely to your suggestions.
>
> Keep in mind, CONFIG_IS_ENABLED will not work for checking
> CMD_BOOTI/CMD_BOOTZ in this case, as there is no CONFIG_SPL_CMD_BOOTx. So,
> I'm just directly checking if it's defined instead.
>
> I verified both CONFIG_IS_ENABLED() and IS_ENABLED() did not work.
>
> Sincerely,
> Nathan
>
> On Mon, Jan 31, 2022 at 10:35 AM Tom Rini wrote:
>
> > On Mon, Jan 31, 2022 at 10:23:58AM -0500, Nathan Barrett-Morrison wrote:
> >
> > > Hi Tom,
> > >
> > > Yea, I'm not sure if uncompressed ARM32 would work, but I don't believe
> > it
> > > was ever working to begin with... as bootz_setup is being called right
> > now
> > > ( @
> > https://source.denx.de/u-boot/u-boot/-/blob/master/common/spl/spl.c#L366
> > > )
> > >
> > > My intent was for SPL_OS_BOOT_UNCOMPRESSED to only be used for platforms
> > > which need booti_setup (ARM64, ...).
> > >
> > > So... I could add a dependency on ARM64 in the config option or I could
> > > remove the option altogether and let the booti_setup fail and fallback to
> > > bootz_setup. Would either of those work for you?
> >
> > The code and logic overall needs a bit of refactoring to support
> > "booti", "bootz" and also FIT images. I believe FIT images are how
> > anyone doing falcon mode on arm64 has worked thus far. booti/bootz
> > should only be an option when CMD_BOOTI/Z is set, and FIT should depend
> > on SPL_LOAD_FIT already.
> >
> > --
> > Tom
> >
> From 5d37f2a930e7cb3455b6ec925ec6e67b40d4c022 Mon Sep 17 00:00:00 2001
> From: Nathan Barrett Morrison
> Date: Wed, 2 Feb 2022 15:05:18 -0500
> Subject: [PATCH v2] Add in the ability to load and boot an uncompressed kernel
> image during the Falcon Mode boot sequence.
>
> This is required for architectures which do not support compressed kernel
> images (i.e. ARM64). This is only used while not booting via FIT image.
>
> Signed-off-by: Nathan Barrett-Morrison
> Cc: Tom Rini
> ---
> Changes for v2:
>- Remove original SPL_OS_BOOT_UNCOMPRESSED option and check via CMD_BOOTI
> and CMD_BOOTZ instead
>
> arch/arm/lib/Makefile | 5 -
> common/spl/spl.c | 21 +
> 2 files changed, 25 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
> index c48e1f622d..57e49f69f7 100644
> --- a/arch/arm/lib/Makefile
> +++ b/arch/arm/lib/Makefile
> @@ -36,7 +36,10 @@ obj-$(CONFIG_CMD_BOOTZ) += bootm.o zimage.o
> obj-$(CONFIG_SYS_L2_PL310) += cache-pl310.o
> else
> obj-$(CONFIG_$(SPL_TPL_)FRAMEWORK) += spl.o
> -obj-$(CONFIG_SPL_FRAMEWORK) += zimage.o
> +ifdef CONFIG_SPL_FRAMEWORK
> +obj-$(CONFIG_CMD_BOOTI) += image.o
> +obj-$(CONFIG_CMD_BOOTZ) += zimage.o
> +endif
> obj-$(CONFIG_OF_LIBFDT) += bootm-fdt.o
> endif
> ifdef CONFIG_ARM64
> diff --git a/common/spl/spl.c b/common/spl/spl.c
> index f51d1f3205..1f6b3f1ac8 100644
> --- a/common/spl/spl.c
> +++ b/common/spl/spl.c
> @@ -104,6 +104,11 @@ int __weak bootz_setup(ulong image, ulong *start, ulong
> *end)
> {
>return 1;
> }
> +
> +int __weak booti_setup(ulong image, ulong *relocated_addr, ulong *size, bool
> force_reloc)
> +{
> + return 1;
> +}
> #endif
>
> /* Weak default function for arch/board-specific fixups to the
> spl_image_info */
> @@ -354,6 +359,21 @@ int spl_parse_image_header(struct spl_image_info
> *spl_image,
> #endif
>
> #if CONFIG_IS_ENABLED(OS_BOOT)
> +#if defined(CMD_BOOTI)
> + ulong start, size;
> +
> + if (!booti_setup((ulong)header, , , 0)) {
> + spl_image->name = "Linux";
> + spl_image->os = IH_OS_LINUX;
> + spl_image->load_addr = start;
> + spl_image->entry_point = start;
> + spl_image->size = size;
> + debug(SPL_TPL_PROMPT
> + "payload Image, load addr: 0x%lx size: %d\n",
> + spl_image->load_addr, spl_image->size);
> + return 0;
> + }
> +#elif defined(CMD_BOOTZ)
> ulong start, end;
>
> if (!bootz_setup((ulong)header, , )) {
> @@ -367,6 +387,7 @@ int spl_parse_image_header(struct spl_image_info
> *spl_image,
> spl_image->load_addr, spl_image->size);
> return 0;
> }
> +#endif
> #endif
>
> if (!spl_parse_board_header(spl_image, (const void *)header,
> sizeof(*header)))
Sorry for the late response. Attached patches aren't picked up by
patchwork. I think this looks OK, but can you please re-send it
directly rather than as attachment? Thanks.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH] net: marvell: mvgbe: Set PHY page 0 before phy_connect
Hi Stefan,
On Tue, Apr 19, 2022 at 3:29 AM Stefan Roese wrote:
>
> Hi Tony,
>
> On 4/12/22 22:18, Tony Dinh wrote:
> > For most Kirkwood boards, the PHY page is already set to page 0
> > (in register 22) before phy_connect is invoked. But some board like
> > the Zyxel NSA310S (which uses the network chip MV88E1318S), the PHY page
> > is not set to page 0. There seems to be some bad data remained in
> > register 22 when the uclass MVGBE about to invoke phy_connect().
> >
> > This patch enables the uclass MVGBE to always set the PHY page to 0
> > before phy_connect.
> >
> > For reference, please see this discussion:
> > [RFC PATCH v2] arm: kirkwood: nsa310s: Use Marvell uclass mvgbe
> > and PHY driver for DM Ethernet.
> > https://lists.denx.de/pipermail/u-boot/2022-April/480946.html
>
> I don't think that this is the correct approach. We should not set
> the *Marvell* PHY page address in this MAC driver IMHO. This driver
> should not have any PHY specific changes. This should be done in the
> PHY driver instead. Some PHY driver or board specific code seems to be
> responsible for setting a non-zero PHY page and not resetting it back
> to zero. A better solution would be to locate this code path and add
> this page reset to 0 there.
>
> What do you think?
My initial thought was similar to yours, in that if we can do this in
the Marvell PHY driver, it would be the best. However, the Marvell PHY
driver start() and config() are invoked too late in the code calling
sequence. The phy_connect() would fail if the page is not 0. And since
we have the mmi_phy_write() call to set the "Set phy address of the
port" (see code excerpt below), I thought it is also appropriate to
set the page to 0 here.
I realized it is an assumption to say because this MVGBE uclass is
only used for the Marvell Alaska chip in the Kirkwood boards, the
register 22 is the correct one.
So perhaps we need a suggestion from the maintainers (to: cc: on this
email) where it would be the best place to do this. In the old ad-hoc
code, this setting to page 0 was done in the board file reset_phy(),
which is invoked early on by board_r.
Thanks,
Tony
=
drivers/net/mvgbe.c
static struct phy_device *__mvgbe_phy_init(struct udevice *dev,
struct mii_dev *bus,
phy_interface_t phy_interface,
int phyid)
#else
static struct phy_device *__mvgbe_phy_init(struct eth_device *dev,
struct mii_dev *bus,
phy_interface_t phy_interface,
int phyid)
#endif
{
struct phy_device *phydev;
/* Set phy address of the port */
miiphy_write(dev->name, MV_PHY_ADR_REQUEST, MV_PHY_ADR_REQUEST,
phyid);
/* Make sure the selected PHY page is 0 before connecting */
miiphy_write(dev->name, phyid, MVGBE_PGADR_REG, 0);
phydev = phy_connect(bus, phyid, dev, phy_interface);
if (!phydev) {
printf("phy_connect failed\n");
return NULL;
}
phy_config(phydev);
phy_startup(phydev);
return phydev;
}
#endif /* CONFIG_PHYLIB || CONFIG_DM_ETH */
> Thanks,
> Stefan
>
> > This patch has been tested with the following Kirkwood boards:
> >
> > NSA310S (88F6702, network chip MV88E1318S)
> > Sheevaplug (88F6281, network chip MV88E1318)
> > Pogo V4 (88F6192, network chip 88E1116R)
> > GF Home(88F6281, network chip 88E1116R)
> > Dreamplug (88F6281, network chip MV88E1318)
> > Dell Kace M300 (88F6282, network chip MV88E1318) - out of tree u-boot
> >
> > Signed-off-by: Tony Dinh
> > ---
> >
> > drivers/net/mvgbe.c | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/net/mvgbe.c b/drivers/net/mvgbe.c
> > index 954bf86121..d2db1e584a 100644
> > --- a/drivers/net/mvgbe.c
> > +++ b/drivers/net/mvgbe.c
> > @@ -43,6 +43,7 @@ DECLARE_GLOBAL_DATA_PTR;
> >
> > #define MV_PHY_ADR_REQUEST 0xee
> > #define MVGBE_SMI_REG (((struct mvgbe_registers *)MVGBE0_BASE)->smi)
> > +#define MVGBE_PGADR_REG 22
> >
> > #if defined(CONFIG_PHYLIB) || defined(CONFIG_MII) ||
> > defined(CONFIG_CMD_MII)
> > static int smi_wait_ready(struct mvgbe_device *dmvgbe)
> > @@ -745,6 +746,9 @@ static struct phy_device *__mvgbe_phy_init(struct
> > eth_device *dev,
> > miiphy_write(dev->name, MV_PHY_ADR_REQUEST, MV_PHY_ADR_REQUEST,
> >phyid);
> >
> > + /* Make sure the selected PHY page is 0 before connecting */
> > + miiphy_write(dev->name, phyid, MVGBE_PGADR_REG, 0);
> > +
> > phydev = phy_connect(bus, phyid, dev, phy_interface);
> > if (!phydev) {
> > printf("phy_connect failed\n");
>
> Viele Grüße,
> Stefan Roese
>
> --
> DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office:
Re: Falcon Mode Support For Uncompressed Kernel Images
Hi Tom,
Let's see if this works any better. Using a new mail client that is supposed
to not modify whitespace:
>From f1c34333f79996bd2927a60f4858c01699431cba Mon Sep 17 00:00:00 2001
From: Nathan Barrett Morrison
Date: Wed, 2 Feb 2022 15:05:18 -0500
Subject: [PATCH v2] Add in the ability to load and boot an uncompressed kernel
image during the Falcon Mode boot sequence.
This is required for architectures which do not support compressed kernel
images (i.e. ARM64). This is only used while not booting via FIT image.
Signed-off-by: Nathan Barrett-Morrison
Cc: Tom Rini
---
Changes for v2:
- Remove original SPL_OS_BOOT_UNCOMPRESSED option and check via CMD_BOOTI
and CMD_BOOTZ instead
arch/arm/lib/Makefile | 5 -
common/spl/spl.c | 21 +
2 files changed, 25 insertions(+), 1 deletion(-)
diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index c603fe61bc..08b7475e37 100644
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile
@@ -36,7 +36,10 @@ obj-$(CONFIG_CMD_BOOTZ) += bootm.o zimage.o
obj-$(CONFIG_SYS_L2_PL310) += cache-pl310.o
else
obj-$(CONFIG_$(SPL_TPL_)FRAMEWORK) += spl.o
-obj-$(CONFIG_SPL_FRAMEWORK) += zimage.o
+ifdef CONFIG_SPL_FRAMEWORK
+obj-$(CONFIG_CMD_BOOTI) += image.o
+obj-$(CONFIG_CMD_BOOTZ) += zimage.o
+endif
obj-$(CONFIG_OF_LIBFDT) += bootm-fdt.o
endif
ifdef CONFIG_ARM64
diff --git a/common/spl/spl.c b/common/spl/spl.c
index c9750ee163..7b86443f1b 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -107,6 +107,11 @@ int __weak bootz_setup(ulong image, ulong *start, ulong
*end)
{
return 1;
}
+
+int __weak booti_setup(ulong image, ulong *relocated_addr, ulong *size, bool
force_reloc)
+{
+return 1;
+}
#endif
/* Weak default function for arch/board-specific fixups to the spl_image_info
*/
@@ -366,6 +371,21 @@ int spl_parse_image_header(struct spl_image_info
*spl_image,
#endif
#if CONFIG_IS_ENABLED(OS_BOOT)
+#if defined(CMD_BOOTI)
+ ulong start, size;
+
+ if (!booti_setup((ulong)header, , , 0)) {
+ spl_image->name = "Linux";
+ spl_image->os = IH_OS_LINUX;
+ spl_image->load_addr = start;
+ spl_image->entry_point = start;
+ spl_image->size = size;
+ debug(SPL_TPL_PROMPT
+ "payload Image, load addr: 0x%lx size: %d\n",
+ spl_image->load_addr, spl_image->size);
+ return 0;
+ }
+#elif defined(CMD_BOOTZ)
ulong start, end;
if (!bootz_setup((ulong)header, , )) {
@@ -379,6 +399,7 @@ int spl_parse_image_header(struct spl_image_info *spl_image,
spl_image->load_addr, spl_image->size);
return 0;
}
+#endif
#endif
if (!spl_parse_board_header(spl_image, bootdev, (const void
*)header, sizeof(*header)))
--
2.30.2
On 4/19/22 16:30, Tom Rini wrote:
> On Wed, Feb 02, 2022 at 04:53:11PM -0500, Nathan Barrett-Morrison wrote:
>> Hi Tom,
>>
>> I've attached version 2 of the patch. I believe this should adhere more
>> closely to your suggestions.
>>
>> Keep in mind, CONFIG_IS_ENABLED will not work for checking
>> CMD_BOOTI/CMD_BOOTZ in this case, as there is no CONFIG_SPL_CMD_BOOTx. So,
>> I'm just directly checking if it's defined instead.
>>
>> I verified both CONFIG_IS_ENABLED() and IS_ENABLED() did not work.
>>
>> Sincerely,
>> Nathan
>>
>> On Mon, Jan 31, 2022 at 10:35 AM Tom Rini wrote:
>>
>>> On Mon, Jan 31, 2022 at 10:23:58AM -0500, Nathan Barrett-Morrison wrote:
>>>
Hi Tom,
Yea, I'm not sure if uncompressed ARM32 would work, but I don't believe
>>> it
was ever working to begin with... as bootz_setup is being called right
>>> now
( @
>>> https://source.denx.de/u-boot/u-boot/-/blob/master/common/spl/spl.c#L366
)
My intent was for SPL_OS_BOOT_UNCOMPRESSED to only be used for platforms
which need booti_setup (ARM64, ...).
So... I could add a dependency on ARM64 in the config option or I could
remove the option altogether and let the booti_setup fail and fallback to
bootz_setup. Would either of those work for you?
>>>
>>> The code and logic overall needs a bit of refactoring to support
>>> "booti", "bootz" and also FIT images. I believe FIT images are how
>>> anyone doing falcon mode on arm64 has worked thus far. booti/bootz
>>> should only be an option when CMD_BOOTI/Z is set, and FIT should depend
>>> on SPL_LOAD_FIT already.
>>>
>>> --
>>> Tom
>>>
>
>> From 5d37f2a930e7cb3455b6ec925ec6e67b40d4c022 Mon Sep 17 00:00:00 2001
>> From: Nathan Barrett Morrison
>> Date: Wed, 2 Feb 2022 15:05:18 -0500
>> Subject: [PATCH v2] Add in the ability to load and boot an uncompressed
>> kernel
>> image during the Falcon Mode boot sequence.
>>
>> This is required for architectures which do not
Re: [PATCH 1/1] drivers: add memory disk support
On Tue, Apr 19, 2022 at 11:16:41PM +0200, Heinrich Schuchardt wrote: > In some scenarios it is desirable to package U-Boot with other files into > a single blob. This patch allows to embed a memory disk into the U-Boot > binary. This memory disk can be accessed like any other block > device as 'mem 0'. > > Signed-off-by: Heinrich Schuchardt What's the use case for this, which isn't covered by some combination of U-Boot being in a FIT image and the "load a firmware blob" that we have today? Thanks! -- Tom signature.asc Description: PGP signature
drivers: mtd: spi: Use correct 4 byte mode enablement for ISSI SPI flash devices alongside spi-nor-tiny.c subsystem
Hi All, I noticed this was missing from the spi-nor-tiny.c subsystem while trying to use an ISSI SPI flash device with the U-Boot SPL. This patch will allow 4 byte addressing mode to be enabled with ISSI flash devices while inside the U-Boot SPL / using spi-nor-tiny.c. Sincerely, Nathan >From 218e00fcaea8c5795e792af09f5d21fc19e3d831 Mon Sep 17 00:00:00 2001 From: Nathan Barrett-Morrison Date: Wed, 26 Jan 2022 13:43:53 -0500 Subject: [PATCH] drivers: mtd: spi: Use correct 4 byte mode enablement for ISSI SPI flash devices alongside spi-nor-tiny.c subsystem Signed-off-by: Nathan Barrett-Morrison Cc: Jagan Teki Cc: Vignesh R CC: Tom Rini --- drivers/mtd/spi/spi-nor-tiny.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/mtd/spi/spi-nor-tiny.c b/drivers/mtd/spi/spi-nor-tiny.c index 68152ce3b4..130917aaa8 100644 --- a/drivers/mtd/spi/spi-nor-tiny.c +++ b/drivers/mtd/spi/spi-nor-tiny.c @@ -219,6 +219,7 @@ static inline int set_4byte(struct spi_nor *nor, const struct flash_info *info, case SNOR_MFR_MICRON: /* Some Micron need WREN command; all will accept it */ need_wren = true; + case SNOR_MFR_ISSI: case SNOR_MFR_MACRONIX: case SNOR_MFR_WINBOND: if (need_wren) -- 2.34.1
Falcon Mode Support For Uncompressed Kernel Images
Hi Tom,
While trying to bring up Falcon Mode boot on an ARM64 board, I discovered
that there is no path which allows you to use an uncompressed kernel image
(booti). I've added this path and attached the relevant patch.
Sincerely,
Nathan
>From f1c34333f79996bd2927a60f4858c01699431cba Mon Sep 17 00:00:00 2001
From: Nathan Barrett-Morrison
Date: Wed, 2 Feb 2022 15:05:18 -0500
Subject: [PATCH v2] Add in the ability to load and boot an uncompressed kernel
image during the Falcon Mode boot sequence.
This is required for architectures which do not support compressed kernel
images (i.e. ARM64). This is only used while not booting via FIT image.
Signed-off-by: Nathan Barrett-Morrison
Cc: Tom Rini
---
Changes for v2:
- Remove original SPL_OS_BOOT_UNCOMPRESSED option and check via CMD_BOOTI
and CMD_BOOTZ instead
arch/arm/lib/Makefile | 5 -
common/spl/spl.c | 21 +
2 files changed, 25 insertions(+), 1 deletion(-)
diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index c603fe61bc..08b7475e37 100644
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile
@@ -36,7 +36,10 @@ obj-$(CONFIG_CMD_BOOTZ) += bootm.o zimage.o
obj-$(CONFIG_SYS_L2_PL310) += cache-pl310.o
else
obj-$(CONFIG_$(SPL_TPL_)FRAMEWORK) += spl.o
-obj-$(CONFIG_SPL_FRAMEWORK) += zimage.o
+ifdef CONFIG_SPL_FRAMEWORK
+obj-$(CONFIG_CMD_BOOTI) += image.o
+obj-$(CONFIG_CMD_BOOTZ) += zimage.o
+endif
obj-$(CONFIG_OF_LIBFDT) += bootm-fdt.o
endif
ifdef CONFIG_ARM64
diff --git a/common/spl/spl.c b/common/spl/spl.c
index c9750ee163..7b86443f1b 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -107,6 +107,11 @@ int __weak bootz_setup(ulong image, ulong *start, ulong
*end)
{
return 1;
}
+
+int __weak booti_setup(ulong image, ulong *relocated_addr, ulong *size, bool
force_reloc)
+{
+return 1;
+}
#endif
/* Weak default function for arch/board-specific fixups to the spl_image_info
*/
@@ -366,6 +371,21 @@ int spl_parse_image_header(struct spl_image_info
*spl_image,
#endif
#if CONFIG_IS_ENABLED(OS_BOOT)
+#if defined(CMD_BOOTI)
+ ulong start, size;
+
+ if (!booti_setup((ulong)header, , , 0)) {
+ spl_image->name = "Linux";
+ spl_image->os = IH_OS_LINUX;
+ spl_image->load_addr = start;
+ spl_image->entry_point = start;
+ spl_image->size = size;
+ debug(SPL_TPL_PROMPT
+ "payload Image, load addr: 0x%lx size: %d\n",
+ spl_image->load_addr, spl_image->size);
+ return 0;
+ }
+#elif defined(CMD_BOOTZ)
ulong start, end;
if (!bootz_setup((ulong)header, , )) {
@@ -379,6 +399,7 @@ int spl_parse_image_header(struct spl_image_info *spl_image,
spl_image->load_addr, spl_image->size);
return 0;
}
+#endif
#endif
if (!spl_parse_board_header(spl_image, bootdev, (const void
*)header, sizeof(*header)))
--
2.30.2
Re: [PATCH 1/5] patman: test_util: Fix printing results for failed tests
On Sat, 2 Apr 2022 at 11:06, Alper Nebi Yasak wrote: > > When printing a python tool's test results, the entire list of failed > tests and their tracebacks are reprinted for every failed test. This > makes the test output quite unreadable. Fix the loop to print failures > and tracebacks one at a time. > > Signed-off-by: Alper Nebi Yasak > --- > > tools/patman/test_util.py | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Simon Glass
Re: [PATCH 2/5] patman: test_util: Handle nonexistent tests while loading tests
On Sat, 2 Apr 2022 at 11:06, Alper Nebi Yasak wrote: > > It's possible to request a specific test to run when trying to run a > python tool's tests. If we request a nonexistent test, the unittest > loaders generate a fake test that reports this as an error. However, we > get these fake tests even when the test exists, because test_util can > load tests from multiple places one by one and the test we want only > exists in one. > > The test_util helpers currently remove these fake tests when printing > test results, but that's more of a workaround than a proper solution. > Instead, don't even try to load the missing tests. > > Signed-off-by: Alper Nebi Yasak > --- > > tools/patman/test_util.py | 21 + > 1 file changed, 5 insertions(+), 16 deletions(-) Reviewed-by: Simon Glass
Re: [PATCH 5/5] patman: test_util: Print test stdout/stderr within test summaries
On Sat, 2 Apr 2022 at 11:06, Alper Nebi Yasak wrote: > > While running tests for a python tool, the tests' outputs get printed in > whatever order they happen to run, without any indication as to which > output belongs to which test. Unittest supports capturing these outputs > and printing them as part of the test summaries, but when a failure or > error occurs it switches back to printing as the tests run. Testtools > and subunit tests can do the same as their parts inherit from unittest, > but they don't outright expose this functionality. > > On the unittest side, enable output buffering for the custom test result > class. Try to avoid ugly outputs by not printing stdout/stderr before > the test summary for low verbosity levels and for successful tests. > > On the subunit side, implement a custom TestProtocolClient that enables > the same underlying functionality and injects the captured streams as > additional test details. This causes them to be merged into their test's > error traceback message, which is later rebuilt into an exception and > passed to our unittest report class. > > Signed-off-by: Alper Nebi Yasak > --- > The way I had to do this for concurrencytest feels hacky, so I am > ambivalent towards this patch. I'm actually fine with re-running a > failing binman test alone with --debug -v6 to get better, isolated > output from it. Yes that's what I tend to do, but I think we should try this patch. We can always drop it in a future release if it causes problems. > > tools/concurrencytest/concurrencytest.py | 83 +++- > tools/patman/test_util.py| 33 +- > 2 files changed, 112 insertions(+), 4 deletions(-) Reviewed-by: Simon Glass
Re: binman and faked blobs failures
Hi, On Sat, 16 Apr 2022 at 11:30, Alper Nebi Yasak wrote: > > On 12/04/2022 00:28, Tom Rini wrote: > > [...] > > > > Note that nothing changed for the board but on the second build now the > > faked blob is unhappy and causes a failure message that I don't see the > > first time, and probably shouldn't see this time either? This is a > > problem for me in that it's on most x86 boards and so makes it easier to > > miss other real build failures in my testing. > > Yeah, the root cause here is that fake files created in the first build > are interpreted as actual files in subsequent builds. Simon already > added a TODO in binman.rst for cleaning them up, I intend to give it a > try but didn't have the time to experiment. Yes, this is: - Put faked files into a separate subdir and remove them on start-up, to avoid seeing them as 'real' files on a subsequent run I believe it is quite easy, since we create the fake files in a single place - check_fake_fname() - and can simply add another subdir into the path we create (e.g. 'fakeblobs/'. Then, when binman, it can remove that subdir, in control.py before tools.finalise_output_dir() is called. The test for it should not be too bad either. Alper if you have time, give it a crack. Otherwise I can look at it, but will be out for a few weeks so not sure when. Regards, Simon
Re: [PATCH 3/7] binman: Don't reset offset/size if image doesn't allow repacking
On Sun, 27 Mar 2022 at 09:32, Alper Nebi Yasak wrote: > > When an image has the 'allow-repack' property, binman includes the > original offset and size properties from the image description in the > fdtmap. These are later used as the packing constraints when replacing > entries in an image, so other unconstrained entries can be freely > positioned. > > Replacing an entry in an image without 'allow-repack' (and therefore the > original offsets) follows the same logic and results in entries being > merely concatenated. Instead, skip resetting the calculated offsets and > sizes to the missing originals for these images so that every entry is > constrained to its existing offset/size. > > Add tests that replace an entry with smaller or equal-sized data, in an > image that doesn't allow repacking. Attempting to do so with bigger-size > data is already an error that is already being tested. > > Signed-off-by: Alper Nebi Yasak > --- > > tools/binman/control.py | 2 +- > tools/binman/ftest.py | 21 + > 2 files changed, 22 insertions(+), 1 deletion(-) Reviewed-by: Simon Glass
Re: [PATCH 3/5] patman: test_util: Use unittest text runner to print test results
On Sat, 2 Apr 2022 at 11:06, Alper Nebi Yasak wrote: > > The python tools' test utilities handle printing test results, but the > output is quite bare compared to an ordinary unittest run. Delegate > printing the results to a unittest text runner, which gives us niceties > like clear separation between each test's result and how long it took to > run the test suite. > > Unfortunately it does not print info for skipped tests by default, but > this can be handled later by a custom test result subclass. It also does > not print the tool name; manually print a heading that includes the > toolname so that the outputs of each tool's tests are distinguishable in > the CI output. > > Signed-off-by: Alper Nebi Yasak > --- > > tools/binman/main.py | 8 ++ > tools/buildman/main.py| 8 ++ > tools/dtoc/main.py| 9 +++--- > tools/dtoc/test_fdt.py| 8 +++--- > tools/patman/main.py | 8 ++ > tools/patman/test_util.py | 58 ++- > 6 files changed, 38 insertions(+), 61 deletions(-) > Reviewed-by: Simon Glass
Re: [PATCH 1/1] drivers: add memory disk support
On 4/19/22 23:26, Tom Rini wrote: On Tue, Apr 19, 2022 at 11:16:41PM +0200, Heinrich Schuchardt wrote: In some scenarios it is desirable to package U-Boot with other files into a single blob. This patch allows to embed a memory disk into the U-Boot binary. This memory disk can be accessed like any other block device as 'mem 0'. Signed-off-by: Heinrich Schuchardt What's the use case for this, which isn't covered by some combination of U-Boot being in a FIT image and the "load a firmware blob" that we have today? Thanks! "U-Boot being in a FIT image" requires a loader that understands FIT. "load a firmware blob" requires a block device or a network file system. If you put U-Boot's payload into the U-Boot blob, you need neither a separate block device nor a network file system. Packaging into U-Boot makes most sense where follow-up binaries are tightly integrated: * adding a custom graphical boot manager as EFI application * adding iPXE * delivering device-trees Best regards Heinrich
Re: [PATCH 2/7] binman: Collect bintools for images when replacing entries
On Sun, 27 Mar 2022 at 09:32, Alper Nebi Yasak wrote: > > Binman entries can use other executables to compute their data, usually > in their ObtainContents() methods. Subclasses of Entry_section would use > bintools in their BuildSectionData() method instead, which is called > from several places including their Pack(). > > These binary tools are resolved correctly while building an image from a > device-tree description so that they can be used from these methods. > However, this is not being done when replacing entries in an image, > which can result in an error as the Pack() methods attempt to use them. > > Collect and resolve entries' bintools also when replacing entries to fix > Pack() errors. Add a way to mock bintool usage in the testing entry type > and tests that check bintools are being resolved for such an entry. > > Signed-off-by: Alper Nebi Yasak > --- > > tools/binman/control.py | 1 + > tools/binman/etype/_testing.py| 36 + > tools/binman/ftest.py | 38 ++ > .../binman/test/232_replace_with_bintool.dts | 39 +++ > 4 files changed, 114 insertions(+) > create mode 100644 tools/binman/test/232_replace_with_bintool.dts Reviewed-by: Simon Glass
Re: [PATCH 7/7] binman: Refuse to replace sections for now
On Sun, 27 Mar 2022 at 09:32, Alper Nebi Yasak wrote:
>
> Binman interfaces allow attempts to replace any entry in the image with
> arbitrary data. When trying to replace sections, the changes in the
> section entry's data are not propagated to its child entries. This,
> combined with how sections rebuild their contents from its children,
> eventually causes the replaced contents to be silently overwritten by
> rebuilt contents equivalent to the original data.
>
> Add a simple test for replacing a section that is currently failing due
> to this behaviour, and mark it as an expected failure. Also, raise an
> error when replacing a section instead of silently pretending it was
> replaced.
>
> Signed-off-by: Alper Nebi Yasak
> ---
>
> tools/binman/etype/section.py | 3 +++
> tools/binman/ftest.py | 9
> .../test/234_replace_section_simple.dts | 23 +++
> 3 files changed, 35 insertions(+)
> create mode 100644 tools/binman/test/234_replace_section_simple.dts
Reviewed-by: Simon Glass
Is it not better to assertRaises() and check that the error message is
as expected?
>
> diff --git a/tools/binman/etype/section.py b/tools/binman/etype/section.py
> index ccac658c1831..bd67238b9199 100644
> --- a/tools/binman/etype/section.py
> +++ b/tools/binman/etype/section.py
> @@ -788,6 +788,9 @@ def ReadChildData(self, child, decomp=True,
> alt_format=None):
> data = new_data
> return data
>
> +def WriteData(self, data, decomp=True):
> +self.Raise("Replacing sections is not implemented yet")
> +
> def WriteChildData(self, child):
> return True
>
> diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
> index 43bec4a88841..058651cc18a0 100644
> --- a/tools/binman/ftest.py
> +++ b/tools/binman/ftest.py
> @@ -5641,6 +5641,15 @@ def testReplaceFitSubentryLeafSmallerSize(self):
> self.assertIsNotNone(path)
> self.assertEqual(expected_fdtmap, fdtmap)
>
> +@unittest.expectedFailure
> +def testReplaceSectionSimple(self):
> +"""Test replacing a simple section with arbitrary data"""
> +new_data = b'w' * len(COMPRESS_DATA + U_BOOT_DATA)
> +data, expected_fdtmap, _ = self._RunReplaceCmd(
> +'section', new_data,
> +dts='234_replace_section_simple.dts')
> +self.assertEqual(new_data, data)
> +
>
> if __name__ == "__main__":
> unittest.main()
> diff --git a/tools/binman/test/234_replace_section_simple.dts
> b/tools/binman/test/234_replace_section_simple.dts
> new file mode 100644
> index ..c9d5c3285615
> --- /dev/null
> +++ b/tools/binman/test/234_replace_section_simple.dts
> @@ -0,0 +1,23 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/dts-v1/;
> +
> +/ {
> + binman {
> + allow-repack;
> +
> + u-boot-dtb {
> + };
> +
> + section {
> + blob {
> + filename = "compress";
> + };
> +
> + u-boot {
> + };
> + };
> +
> + fdtmap {
> + };
> + };
> +};
> --
> 2.35.1
>
Re: [PATCH 5/7] binman: Create FIT subentries in the FIT section, not its parent
Hi Alper, On Sun, 27 Mar 2022 at 09:32, Alper Nebi Yasak wrote: > > When reading images from a file, each entry's data is read from its > parent section as specified in the Entry.Create() call that created it. > The FIT entry type has been creating its subentries under its parent > (their grandparent), as creating them under the FIT entry resulted in an > error until FIT was converted into a proper section. > > FIT subentries have their offsets relative to the FIT section, and > reading those offsets in the parent section results in wrong data. The > subentries rightfully belong under the FIT entries, so create them > there. Add tests checking that we can extract the correct data for a FIT > entry and its subentries. > > Signed-off-by: Alper Nebi Yasak > --- > > tools/binman/etype/fit.py | 2 +- > tools/binman/ftest.py | 35 + > tools/binman/test/233_fit_extract_replace.dts | 74 +++ > 3 files changed, 110 insertions(+), 1 deletion(-) > create mode 100644 tools/binman/test/233_fit_extract_replace.dts Reviewed-by: Simon Glass It's great to be able to replace data in FITs. It's quite a complex case, but very useful I think. Regards, Simon
Re: [PATCH 1/1] drivers: add memory disk support
On Tue, Apr 19, 2022 at 11:55:00PM +0200, Heinrich Schuchardt wrote: > On 4/19/22 23:26, Tom Rini wrote: > > On Tue, Apr 19, 2022 at 11:16:41PM +0200, Heinrich Schuchardt wrote: > > > > > In some scenarios it is desirable to package U-Boot with other files into > > > a single blob. This patch allows to embed a memory disk into the U-Boot > > > binary. This memory disk can be accessed like any other block > > > device as 'mem 0'. > > > > > > Signed-off-by: Heinrich Schuchardt > > > > What's the use case for this, which isn't covered by some combination of > > U-Boot being in a FIT image and the "load a firmware blob" that we have > > today? Thanks! > > "U-Boot being in a FIT image" requires a loader that understands FIT. Fortunately, that's U-Boot. > "load a firmware blob" requires a block device or a network file system. No, we have various cases where we bundle inside of the image various black boxes, in various ways. > If you put U-Boot's payload into the U-Boot blob, you need neither a > separate block device nor a network file system. What is the use case for this? > Packaging into U-Boot makes most sense where follow-up binaries are tightly > integrated: [re-ordering this list, sorry] > * delivering device-trees Yes, we can do that today, select the right one at run time, and even pass that along to EFI via the appropriate config table entry. > * adding iPXE Rather than fetching this from the network, to continue to fetch and load applications from the network? > * adding a custom graphical boot manager as EFI application Why can't this be loaded from the disk? What I would like to see is the proof of concept / design that makes use of this, that can't make use of the existing facilities we have for doing similar concepts already. Or that aren't something that should be done within U-Boot, if necessary. -- Tom signature.asc Description: PGP signature
Re: [PATCH 2/2] arch: layerscape: Add SFP binding
Hi Sean, > This adds an SFP binding for the processors it is present on. I have > only tested this for the LS1046A. > > Signed-off-by: Sean Anderson There is an upstream binding Documentation/devicetree/bindings/nvmem/fsl,layerscape-sfp.yaml Are you aware of that? Could you submit a patch there to add your new compatibles? Esp. because you are using a clock which isn't described in the upstream binding. I'm curious, do you need the clock? I only know the LS1028A and it seems you don't have to turn on any clock there. It might also be the case I've missed something. -michael
U-Boot and switching away from arch/arm/mach-imx/mkimage_fit_atf.sh
Hey all,
Currently, the following defconfigs are the only ones left using the
above mentioned script, rather than binman, to generate the final
binaries:
configs/cgtqmx8_defconfig
configs/imx8mm-icore-mx8mm-ctouch2_defconfig
configs/imx8mm-icore-mx8mm-edimm2.2_defconfig
What's needed to migrate these platforms over? There are examples such
as 7d926c9544c2 ("imx8mm_venice: switch to use binman to pack images")
for how to perform such a migration. Thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH 1/2] arm: layerscape: Add sfp driver
On 4/19/22 4:58 PM, Sean Anderson wrote: > This adds a driver for the Security Fuse Processor (SFP) present on > LS1012A, LS1021A, LS1043A, and LS1046A processors. It holds the > Super-Root Key (SRK), One-Time-Programmable Master Key (OTPMK), and > other "security" related fuses. Similar devices (sharing the same name) > are present on other processors, but for the moment this just supports > the LS2 variants. > > The mirror registers are loaded during power-on reset. All mirror > registers must be programmed or read at once. Because of this, `fuse > prog` will program all fuses, even though only one might be specified. > To prevent accidentally burning through all your fuse programming cycles > with something like `fuse prog 0 0 A B C D`, we limit ourselves to one > programming cycle per reset. Fuses are numbered based on their address. > The fuse at 0x1e80200 is 0, the fuse at 0x1e80204 is 1, etc. > > The TA_PROG_SFP supply must be enabled when programming fuses, but must > be disabled when reading them. Typically this supply is enabled by > inserting a jumper or by setting a register in the board's FPGA. I've > also added support for using a regulator. This could be helpful for > automatically issuing the FPGA write, or for toggling a GPIO controlling > the supply. > > I suggest using the following procedure for programming: > > 1. Override the fuses you wish to program >=> fuse override 0 2 A B C D > 2. Inspect the values and ensure that they are what you expect >=> fuse sense 0 2 4 > 3. Enable TA_PROG_SFP > 4. Issue a program command using OSPR0 as a dummy. Since it contains the >write-protect bit you will usually want to write it last anyway. >=> fuse prog 0 0 0 > 5. Disable TA_PROG_SFP > 6. Read back the fuses and ensure they are correct >=> fuse read 0 2 4 > > Signed-off-by: Sean Anderson > --- I forgot to mention this, but this patch depends on https://lore.kernel.org/u-boot/20220419191245.3749739-1-sean.ander...@seco.com/T/#u
[PATCH 1/1] drivers: add memory disk support
In some scenarios it is desirable to package U-Boot with other files into
a single blob. This patch allows to embed a memory disk into the U-Boot
binary. This memory disk can be accessed like any other block
device as 'mem 0'.
Signed-off-by: Heinrich Schuchardt
---
MAINTAINERS | 6 ++
common/board_r.c | 4 +
drivers/Kconfig | 2 +
drivers/Makefile | 1 +
drivers/block/blk-uclass.c | 2 +
drivers/memdisk/Kconfig | 13
drivers/memdisk/Makefile | 11 +++
drivers/memdisk/memdisk-uclass.c | 22 ++
drivers/memdisk/memdisk.c| 128 +++
drivers/memdisk/memdisk_file.S | 17
include/asm-generic/sections.h | 2 +
include/blk.h| 1 +
include/dm/uclass-id.h | 1 +
include/memdisk.h| 28 +++
14 files changed, 238 insertions(+)
create mode 100644 drivers/memdisk/Kconfig
create mode 100644 drivers/memdisk/Makefile
create mode 100644 drivers/memdisk/memdisk-uclass.c
create mode 100644 drivers/memdisk/memdisk.c
create mode 100644 drivers/memdisk/memdisk_file.S
create mode 100644 include/memdisk.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 34446127d4..be71f8d9b7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -930,6 +930,12 @@ T: git git://github.com/ARM-software/u-boot.git
F: drivers/video/mali_dp.c
F: drivers/i2c/i2c-versatile.c
+MEMDISK
+M: Heinrich Schuchardt
+S: Supported
+F: drivers/memdisk/
+F: include/memdisk.h
+
MICROBLAZE
M: Michal Simek
S: Maintained
diff --git a/common/board_r.c b/common/board_r.c
index 8dc87ed2be..f416dbd17e 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -37,6 +37,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -700,6 +701,9 @@ static init_fnc_t init_sequence_r[] = {
#ifdef CONFIG_CMD_ONENAND
initr_onenand,
#endif
+#ifdef CONFIG_MEMDISK
+ initr_memdisk,
+#endif
#ifdef CONFIG_MMC
initr_mmc,
#endif
diff --git a/drivers/Kconfig b/drivers/Kconfig
index b26ca8cf70..bf475c25e7 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -56,6 +56,8 @@ source "drivers/led/Kconfig"
source "drivers/mailbox/Kconfig"
+source "drivers/memdisk/Kconfig"
+
source "drivers/memory/Kconfig"
source "drivers/misc/Kconfig"
diff --git a/drivers/Makefile b/drivers/Makefile
index 4e7cf28440..3c2906b9c5 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_$(SPL_TPL_)FIRMWARE) +=firmware/
obj-$(CONFIG_$(SPL_TPL_)I2C) += i2c/
obj-$(CONFIG_$(SPL_TPL_)INPUT) += input/
obj-$(CONFIG_$(SPL_TPL_)LED) += led/
+obj-$(CONFIG_$(SPL_TPL_)MEMDISK) += memdisk/
obj-$(CONFIG_$(SPL_TPL_)MMC) += mmc/
obj-y += mtd/
obj-$(CONFIG_$(SPL_)MULTIPLEXER) += mux/
diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-uclass.c
index f1e4a85646..4beec38f71 100644
--- a/drivers/block/blk-uclass.c
+++ b/drivers/block/blk-uclass.c
@@ -23,6 +23,7 @@ static const char *if_typename_str[IF_TYPE_COUNT] = {
[IF_TYPE_ATAPI] = "atapi",
[IF_TYPE_USB] = "usb",
[IF_TYPE_DOC] = "doc",
+ [IF_TYPE_MEMDISK] = "mem",
[IF_TYPE_MMC] = "mmc",
[IF_TYPE_SD]= "sd",
[IF_TYPE_SATA] = "sata",
@@ -40,6 +41,7 @@ static enum uclass_id if_type_uclass_id[IF_TYPE_COUNT] = {
[IF_TYPE_ATAPI] = UCLASS_INVALID,
[IF_TYPE_USB] = UCLASS_MASS_STORAGE,
[IF_TYPE_DOC] = UCLASS_INVALID,
+ [IF_TYPE_MEMDISK] = UCLASS_MEMDISK,
[IF_TYPE_MMC] = UCLASS_MMC,
[IF_TYPE_SD]= UCLASS_INVALID,
[IF_TYPE_SATA] = UCLASS_AHCI,
diff --git a/drivers/memdisk/Kconfig b/drivers/memdisk/Kconfig
new file mode 100644
index 00..03f646539c
--- /dev/null
+++ b/drivers/memdisk/Kconfig
@@ -0,0 +1,13 @@
+config MEMDISK
+ bool "Support embedded memory disk"
+ select HAVE_BLOCK_DEVICE
+ help
+This option allows to embed a memory disk.
+
+config MEMDISK_FILE
+ string "Memory disk file"
+ depends on MEMDISK
+ default "memdisk.img"
+ help
+File to be embedded as memory disk.
+It can be accessed as block device 'mem 0'.
diff --git a/drivers/memdisk/Makefile b/drivers/memdisk/Makefile
new file mode 100644
index 00..09d6de22d2
--- /dev/null
+++ b/drivers/memdisk/Makefile
@@ -0,0 +1,11 @@
+ifeq ($(CONFIG_MEMDISK),y)
+
+obj-y += \
+ memdisk.o \
+ memdisk-uclass.o \
+ memdisk_file.o
+
+MEMDISK_FILE := $(subst $\",,$(CONFIG_MEMDISK_FILE))
+$(obj)/memdisk_file.o: $(srctree)/$(MEMDISK_FILE)
+
+endif
diff --git a/drivers/memdisk/memdisk-uclass.c b/drivers/memdisk/memdisk-uclass.c
new file mode 100644
index 00..b7b96f91a4
--- /dev/null
+++ b/drivers/memdisk/memdisk-uclass.c
@@ -0,0 +1,22 @@
+// SPDX-License-Identifier:
Re: Falcon Mode Support For Uncompressed Kernel Images
One more time --
>From f1c34333f79996bd2927a60f4858c01699431cba Mon Sep 17 00:00:00 2001
From: Nathan Barrett-Morrison
Date: Wed, 2 Feb 2022 15:05:18 -0500
Subject: [PATCH v2] Add in the ability to load and boot an uncompressed kernel
image during the Falcon Mode boot sequence.
This is required for architectures which do not support compressed kernel
images (i.e. ARM64). This is only used while not booting via FIT image.
Signed-off-by: Nathan Barrett-Morrison
Cc: Tom Rini
---
Changes for v2:
- Remove original SPL_OS_BOOT_UNCOMPRESSED option and check via CMD_BOOTI
and CMD_BOOTZ instead
arch/arm/lib/Makefile | 5 -
common/spl/spl.c | 21 +
2 files changed, 25 insertions(+), 1 deletion(-)
diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index c603fe61bc..08b7475e37 100644
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile
@@ -36,7 +36,10 @@ obj-$(CONFIG_CMD_BOOTZ) += bootm.o zimage.o
obj-$(CONFIG_SYS_L2_PL310) += cache-pl310.o
else
obj-$(CONFIG_$(SPL_TPL_)FRAMEWORK) += spl.o
-obj-$(CONFIG_SPL_FRAMEWORK) += zimage.o
+ifdef CONFIG_SPL_FRAMEWORK
+obj-$(CONFIG_CMD_BOOTI) += image.o
+obj-$(CONFIG_CMD_BOOTZ) += zimage.o
+endif
obj-$(CONFIG_OF_LIBFDT) += bootm-fdt.o
endif
ifdef CONFIG_ARM64
diff --git a/common/spl/spl.c b/common/spl/spl.c
index c9750ee163..7b86443f1b 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -107,6 +107,11 @@ int __weak bootz_setup(ulong image, ulong *start, ulong
*end)
{
return 1;
}
+
+int __weak booti_setup(ulong image, ulong *relocated_addr, ulong *size, bool
force_reloc)
+{
+return 1;
+}
#endif
/* Weak default function for arch/board-specific fixups to the spl_image_info
*/
@@ -366,6 +371,21 @@ int spl_parse_image_header(struct spl_image_info
*spl_image,
#endif
#if CONFIG_IS_ENABLED(OS_BOOT)
+#if defined(CMD_BOOTI)
+ ulong start, size;
+
+ if (!booti_setup((ulong)header, , , 0)) {
+ spl_image->name = "Linux";
+ spl_image->os = IH_OS_LINUX;
+ spl_image->load_addr = start;
+ spl_image->entry_point = start;
+ spl_image->size = size;
+ debug(SPL_TPL_PROMPT
+ "payload Image, load addr: 0x%lx size: %d\n",
+ spl_image->load_addr, spl_image->size);
+ return 0;
+ }
+#elif defined(CMD_BOOTZ)
ulong start, end;
if (!bootz_setup((ulong)header, , )) {
@@ -379,6 +399,7 @@ int spl_parse_image_header(struct spl_image_info *spl_image,
spl_image->load_addr, spl_image->size);
return 0;
}
+#endif
#endif
if (!spl_parse_board_header(spl_image, bootdev, (const void
*)header, sizeof(*header)))
--
2.30.2
On 4/19/22 17:16, Nathan Barrett-Morrison wrote:
> Hi Tom,
>
> Let's see if this works any better. Using a new mail client that is supposed
> to not modify whitespace:
>
> From f1c34333f79996bd2927a60f4858c01699431cba Mon Sep 17 00:00:00 2001
> From: Nathan Barrett Morrison
> Date: Wed, 2 Feb 2022 15:05:18 -0500
> Subject: [PATCH v2] Add in the ability to load and boot an uncompressed kernel
> image during the Falcon Mode boot sequence.
>
> This is required for architectures which do not support compressed kernel
> images (i.e. ARM64). This is only used while not booting via FIT image.
>
> Signed-off-by: Nathan Barrett-Morrison
> Cc: Tom Rini
> ---
> Changes for v2:
>- Remove original SPL_OS_BOOT_UNCOMPRESSED option and check via CMD_BOOTI
> and CMD_BOOTZ instead
>
> arch/arm/lib/Makefile | 5 -
> common/spl/spl.c | 21 +
> 2 files changed, 25 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
> index c603fe61bc..08b7475e37 100644
> --- a/arch/arm/lib/Makefile
> +++ b/arch/arm/lib/Makefile
> @@ -36,7 +36,10 @@ obj-$(CONFIG_CMD_BOOTZ) += bootm.o zimage.o
> obj-$(CONFIG_SYS_L2_PL310) += cache-pl310.o
> else
> obj-$(CONFIG_$(SPL_TPL_)FRAMEWORK) += spl.o
> -obj-$(CONFIG_SPL_FRAMEWORK) += zimage.o
> +ifdef CONFIG_SPL_FRAMEWORK
> +obj-$(CONFIG_CMD_BOOTI) += image.o
> +obj-$(CONFIG_CMD_BOOTZ) += zimage.o
> +endif
> obj-$(CONFIG_OF_LIBFDT) += bootm-fdt.o
> endif
> ifdef CONFIG_ARM64
> diff --git a/common/spl/spl.c b/common/spl/spl.c
> index c9750ee163..7b86443f1b 100644
> --- a/common/spl/spl.c
> +++ b/common/spl/spl.c
> @@ -107,6 +107,11 @@ int __weak bootz_setup(ulong image, ulong *start, ulong
> *end)
> {
>return 1;
> }
> +
> +int __weak booti_setup(ulong image, ulong *relocated_addr, ulong *size, bool
> force_reloc)
> +{
> + return 1;
> +}
> #endif
>
> /* Weak default function for arch/board-specific fixups to the
> spl_image_info */
> @@ -366,6 +371,21 @@ int spl_parse_image_header(struct spl_image_info
> *spl_image,
>
Re: Falcon Mode Support For Uncompressed Kernel Images
On Tue, Apr 19, 2022 at 05:31:52PM -0400, Nathan Barrett-Morrison wrote: > Hi Tom, > > While trying to bring up Falcon Mode boot on an ARM64 board, I discovered > that there is no path which allows you to use an uncompressed kernel image > (booti). I've added this path and attached the relevant patch. > > Sincerely, > Nathan > > From f1c34333f79996bd2927a60f4858c01699431cba Mon Sep 17 00:00:00 2001 > From: Nathan Barrett-Morrison > Date: Wed, 2 Feb 2022 15:05:18 -0500 > Subject: [PATCH v2] Add in the ability to load and boot an uncompressed kernel > image during the Falcon Mode boot sequence. > > This is required for architectures which do not support compressed kernel > images (i.e. ARM64). This is only used while not booting via FIT image. > > Signed-off-by: Nathan Barrett-Morrison > Cc: Tom Rini Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature
Re: spl: spi: Raw Kernel Image Support for Falcon Mode Boot Via SPI Devices
Hi Nathan, On 4/19/22 5:38 PM, Nathan Barrett-Morrison wrote: > [You don't often get email from nathan.morri...@timesys.com. Learn why this > is important at http://aka.ms/LearnAboutSenderIdentification.] > > Hi Tom, > > I believe this patch is still relevant, so I'm resubmitting it. It was > previously marked as superseded. > > Thanks, > Nathan > > From 0bb98a42bcb01c078f63513d9151d307dbfd6ccd Mon Sep 17 00:00:00 2001 > From: Nathan Barrett-Morrison > Date: Tue, 19 Apr 2022 17:35:21 -0400 > Subject: [PATCH v2] Allow Falcon Mode boot to use raw kernel image when > booting > via SPI. > > When using Falcon Mode boot with a raw, unwrapped kernel image, the > bootz_setup() call inside of spl_parse_image_header() is > unreachable because the mkimage header magic check in spi_load_image_os() > will never pass. This check is entirely redundant and unnecessary, > as the spl_parse_image_header() call will also check for IH_MAGIC. > > Signed-off-by: Nathan Barrett-Morrison > Cc: Tom Rini > --- > Changes for v2: >- Remove proposed CONFIG_SYS_SPI_KERNEL_SKIP_HEADER option, as we've > determined the entire check is redundant and unnecessary. Just delete it > instead. > > common/spl/spl_spi.c | 3 --- > 1 file changed, 3 deletions(-) > > diff --git a/common/spl/spl_spi.c b/common/spl/spl_spi.c > index cf3f7ef4c0..22e9c87eae 100644 > --- a/common/spl/spl_spi.c > +++ b/common/spl/spl_spi.c > @@ -34,9 +34,6 @@ static int spi_load_image_os(struct spl_image_info > *spl_image, > spi_flash_read(flash, CONFIG_SYS_SPI_KERNEL_OFFS, sizeof(*header), >(void *)header); > > - if (image_get_magic(header) != IH_MAGIC) > - return -1; > - > err = spl_parse_image_header(spl_image, bootdev, header); > if (err) > return err; > -- > 2.30.2 > Can you see if [1] fixes your problem? You will also need the first patch in the series. --Sean [1] https://lore.kernel.org/u-boot/20220401190405.1932697-8-sean.ander...@seco.com/
Re: spl: spi: Raw Kernel Image Support for Falcon Mode Boot Via SPI Devices
Hi Sean, Thanks for the response. I don't have my embedded board I'm doing this on quite up to this version of U-Boot, but it does appear your patchset should resolve my issue in the future. So please disregard my patch, I think we're good! Sincerely, Nathan On 4/19/22 17:43, Sean Anderson wrote: > Hi Nathan, > > On 4/19/22 5:38 PM, Nathan Barrett-Morrison wrote: >> [You don't often get email from nathan.morri...@timesys.com. Learn why this >> is important at http://aka.ms/LearnAboutSenderIdentification.] >> >> Hi Tom, >> >> I believe this patch is still relevant, so I'm resubmitting it. It was >> previously marked as superseded. >> >> Thanks, >> Nathan >> >> From 0bb98a42bcb01c078f63513d9151d307dbfd6ccd Mon Sep 17 00:00:00 2001 >> From: Nathan Barrett-Morrison >> Date: Tue, 19 Apr 2022 17:35:21 -0400 >> Subject: [PATCH v2] Allow Falcon Mode boot to use raw kernel image when >> booting >> via SPI. >> >> When using Falcon Mode boot with a raw, unwrapped kernel image, the >> bootz_setup() call inside of spl_parse_image_header() is >> unreachable because the mkimage header magic check in spi_load_image_os() >> will never pass. This check is entirely redundant and unnecessary, >> as the spl_parse_image_header() call will also check for IH_MAGIC. >> >> Signed-off-by: Nathan Barrett-Morrison >> Cc: Tom Rini >> --- >> Changes for v2: >>- Remove proposed CONFIG_SYS_SPI_KERNEL_SKIP_HEADER option, as we've >> determined the entire check is redundant and unnecessary. Just delete it >> instead. >> >> common/spl/spl_spi.c | 3 --- >> 1 file changed, 3 deletions(-) >> >> diff --git a/common/spl/spl_spi.c b/common/spl/spl_spi.c >> index cf3f7ef4c0..22e9c87eae 100644 >> --- a/common/spl/spl_spi.c >> +++ b/common/spl/spl_spi.c >> @@ -34,9 +34,6 @@ static int spi_load_image_os(struct spl_image_info >> *spl_image, >> spi_flash_read(flash, CONFIG_SYS_SPI_KERNEL_OFFS, sizeof(*header), >>(void *)header); >> >> - if (image_get_magic(header) != IH_MAGIC) >> - return -1; >> - >> err = spl_parse_image_header(spl_image, bootdev, header); >> if (err) >> return err; >> -- >> 2.30.2 >> > > Can you see if [1] fixes your problem? You will also need the first patch in > the series. > > --Sean > > [1] > https://lore.kernel.org/u-boot/20220401190405.1932697-8-sean.ander...@seco.com/
Re: [PATCH 1/7] binman: Fix unique names having '/.' for images read from files
On Sun, 27 Mar 2022 at 09:32, Alper Nebi Yasak wrote: > > Binman can embed a copy of the image description into the images it > builds as a fdtmap entry, but it omits the /binman/ prefix > from the node paths while doing so. When reading an already-built image > file, entries are reconstructed using this fdtmap and their associated > nodes still lack that prefix. > > Some entries like fit and vblock create intermediate files whose names > are based on an entry unique name. This name is constructed from their > node's path by concatenating the parents with dots up to the binman > node, e.g. /binman/image/foo/bar becomes 'image.foo.bar'. > > However, we don't have this /binman/image prefix when replacing entries > in such an image. The /foo/bar entry we read when doing so erroneously > has the unique name of '/.foo.bar', causing permission errors when the > entry attempts to create files based on that. > > Fix the unique-name generation by stopping at the '/' node like how it > stops at the binman node. As the unique names are used as filenames, add > tests that check if they're safe to use as filenames. > > Signed-off-by: Alper Nebi Yasak > --- > > tools/binman/entry.py| 2 +- > tools/binman/ftest.py| 31 > tools/binman/test/230_unique_names.dts | 34 ++ > tools/binman/test/231_unique_names_multi.dts | 38 > 4 files changed, 104 insertions(+), 1 deletion(-) > create mode 100644 tools/binman/test/230_unique_names.dts > create mode 100644 tools/binman/test/231_unique_names_multi.dts Reviewed-by: Simon Glass
Re: [PATCH 6/7] binman: Test replacing non-section entries in FIT subsections
On Sun, 27 Mar 2022 at 09:32, Alper Nebi Yasak wrote: > > A previous patch fixes binman to correctly extract FIT subentries. This > makes it easier to test replacing these entries as we can write tests > using an existing helper function that relies on extracting the replaced > entry. > > Add tests that replace leaf entries in FIT subsections with data of > various sizes. Replacing the subsections or the whole FIT section does > not work yet due to the section contents being re-built from unreplaced > subentries' data. > > Signed-off-by: Alper Nebi Yasak > --- > > tools/binman/ftest.py | 38 ++ > 1 file changed, 38 insertions(+) Reviewed-by: Simon Glass
Re: spl: spi: Raw Kernel Image Support for Falcon Mode Boot Via SPI Devices
Hi Nathan,
On 4/19/22 5:49 PM, Nathan Barrett-Morrison wrote:
> [You don't often get email from nathan.morri...@timesys.com. Learn why this
> is important at http://aka.ms/LearnAboutSenderIdentification.]
>
> Hi Sean,
>
> Thanks for the response. I don't have my embedded board I'm doing this on
> quite up to this version of U-Boot, but it does appear your patchset should
> resolve my issue in the future. So please disregard my patch, I think we're
> good!
Actually, I'm not sure it will resolve your issue, since you seem to be having
issues
with falcon boot, which I didn't modify. Can you try the following patch in
addition
to the ones I linked above? I haven't tested it at all, so ymmv.
diff --git a/common/spl/spl_spi.c b/common/spl/spl_spi.c
index 037db1a19f..0ab8a10300 100644
--- a/common/spl/spl_spi.c
+++ b/common/spl/spl_spi.c
@@ -18,41 +18,6 @@
#include
#include
-#if CONFIG_IS_ENABLED(OS_BOOT)
-/*
- * Load the kernel, check for a valid header we can parse, and if found load
- * the kernel and then device tree.
- */
-static int spi_load_image_os(struct spl_image_info *spl_image,
-struct spl_boot_device *bootdev,
-struct spi_flash *flash,
-struct image_header *header)
-{
- int err;
-
- /* Read for a header, parse or error out. */
- spi_flash_read(flash, CONFIG_SYS_SPI_KERNEL_OFFS, sizeof(*header),
- (void *)header);
-
- if (image_get_magic(header) != IH_MAGIC)
- return -1;
-
- err = spl_parse_image_header(spl_image, bootdev, header);
- if (err)
- return err;
-
- spi_flash_read(flash, CONFIG_SYS_SPI_KERNEL_OFFS,
- spl_image->size, (void *)spl_image->load_addr);
-
- /* Read device tree. */
- spi_flash_read(flash, CONFIG_SYS_SPI_ARGS_OFFS,
- CONFIG_SYS_SPI_ARGS_SIZE,
- (void *)CONFIG_SYS_SPL_ARGS_ADDR);
-
- return 0;
-}
-#endif
-
static ulong spl_spi_fit_read(struct spl_load_info *load, ulong sector,
ulong count, void *buf)
{
@@ -71,6 +36,29 @@ unsigned int __weak spl_spi_get_uboot_offs(struct spi_flash
*flash)
return CONFIG_SYS_SPI_U_BOOT_OFFS;
}
+static int spi_do_load_image(struct spl_image_info *spl_image,
+struct spl_boot_device *bootdev,
+struct spl_load_info *load,
+unsigned int payload_offs)
+{
+ int ret;
+ struct image_header *header;
+
+ header = spl_get_load_buffer(-sizeof(*header), sizeof(*header));
+
+ /* mkimage header is 64 bytes. */
+ ret = spi_flash_read(flash, payload_offs, sizeof(*header),
+(void *)header);
+ if (ret) {
+ debug("%s: Failed to read from SPI flash (err=%d)\n",
+ __func__, ret);
+ return ret;
+ }
+
+ return spl_load(spl_image, bootdev, , header, 0,
+ payload_offs);
+}
+
/*
* The main entry for SPI booting. It's necessary that SDRAM is already
* configured and available since this code loads the main U-Boot image
@@ -82,7 +70,6 @@ static int spl_spi_load_image(struct spl_image_info
*spl_image,
int err = 0;
unsigned int payload_offs;
struct spi_flash *flash;
- struct image_header *header;
struct spl_load_info load = {
.bl_len = 1,
.read = spl_spi_fit_read,
@@ -106,31 +93,24 @@ static int spl_spi_load_image(struct spl_image_info
*spl_image,
load.dev = flash;
payload_offs = spl_spi_get_uboot_offs(flash);
- header = spl_get_load_buffer(-sizeof(*header), sizeof(*header));
-
if (CONFIG_IS_ENABLED(OF_REAL)) {
payload_offs = ofnode_conf_read_int("u-boot,spl-payload-offset",
payload_offs);
}
#if CONFIG_IS_ENABLED(OS_BOOT)
- if (spl_start_uboot() || spi_load_image_os(spl_image, bootdev, flash,
header))
-#endif
- {
- /* Load u-boot, mkimage header is 64 bytes. */
- err = spi_flash_read(flash, payload_offs, sizeof(*header),
-(void *)header);
- if (err) {
- debug("%s: Failed to read from SPI flash (err=%d)\n",
- __func__, err);
- return err;
- }
-
- err = spl_load(spl_image, bootdev, , header, 0,
- payload_offs);
+ if (spl_start_uboot()) {
+ err = spi_do_load_image(spl_image, bootdev, ,
+ CONFIG_SYS_SPI_KERNEL_OFFS);
+ if (!err)
+ /* Read device tree. */
+ return spi_flash_read(flash, CONFIG_SYS_SPI_ARGS_OFFS,
+
Re: [PATCH 1/1] drivers: add memory disk support
On 4/19/22 23:54, Simon Glass wrote: > Hi Heinrich, > > On Tue, 19 Apr 2022 at 15:14, Heinrich Schuchardt > wrote: >> >> In some scenarios it is desirable to package U-Boot with other files into >> a single blob. This patch allows to embed a memory disk into the U-Boot >> binary. This memory disk can be accessed like any other block >> device as 'mem 0'. >> >> Signed-off-by: Heinrich Schuchardt >> --- >> MAINTAINERS | 6 ++ >> common/board_r.c | 4 + >> drivers/Kconfig | 2 + >> drivers/Makefile | 1 + >> drivers/block/blk-uclass.c | 2 + >> drivers/memdisk/Kconfig | 13 >> drivers/memdisk/Makefile | 11 +++ >> drivers/memdisk/memdisk-uclass.c | 22 ++ >> drivers/memdisk/memdisk.c| 128 +++ >> drivers/memdisk/memdisk_file.S | 17 >> include/asm-generic/sections.h | 2 + >> include/blk.h| 1 + >> include/dm/uclass-id.h | 1 + >> include/memdisk.h| 28 +++ >> 14 files changed, 238 insertions(+) >> create mode 100644 drivers/memdisk/Kconfig >> create mode 100644 drivers/memdisk/Makefile >> create mode 100644 drivers/memdisk/memdisk-uclass.c >> create mode 100644 drivers/memdisk/memdisk.c >> create mode 100644 drivers/memdisk/memdisk_file.S >> create mode 100644 include/memdisk.h > > Can this use binman to create the image and find the memdisk? binman requires board specific layout information. I cannot see how binman would help for a Kconfig option that can be switched on and off for any board. binman may provide addresses in the control device-tree which later could be relocated. But this seems to result in a larger image size. Best regards Heinrich > > Regards, > Simon
Re: [PATCH 1/1] drivers: add memory disk support
On Wed, Apr 20, 2022 at 12:20:43AM +0200, Heinrich Schuchardt wrote: > On 4/19/22 23:54, Simon Glass wrote: > > Hi Heinrich, > > > > On Tue, 19 Apr 2022 at 15:14, Heinrich Schuchardt > > wrote: > >> > >> In some scenarios it is desirable to package U-Boot with other files into > >> a single blob. This patch allows to embed a memory disk into the U-Boot > >> binary. This memory disk can be accessed like any other block > >> device as 'mem 0'. > >> > >> Signed-off-by: Heinrich Schuchardt > >> --- > >> MAINTAINERS | 6 ++ > >> common/board_r.c | 4 + > >> drivers/Kconfig | 2 + > >> drivers/Makefile | 1 + > >> drivers/block/blk-uclass.c | 2 + > >> drivers/memdisk/Kconfig | 13 > >> drivers/memdisk/Makefile | 11 +++ > >> drivers/memdisk/memdisk-uclass.c | 22 ++ > >> drivers/memdisk/memdisk.c| 128 +++ > >> drivers/memdisk/memdisk_file.S | 17 > >> include/asm-generic/sections.h | 2 + > >> include/blk.h| 1 + > >> include/dm/uclass-id.h | 1 + > >> include/memdisk.h| 28 +++ > >> 14 files changed, 238 insertions(+) > >> create mode 100644 drivers/memdisk/Kconfig > >> create mode 100644 drivers/memdisk/Makefile > >> create mode 100644 drivers/memdisk/memdisk-uclass.c > >> create mode 100644 drivers/memdisk/memdisk.c > >> create mode 100644 drivers/memdisk/memdisk_file.S > >> create mode 100644 include/memdisk.h > > > > Can this use binman to create the image and find the memdisk? > > binman requires board specific layout information. I cannot see how binman > would help for a Kconfig option that can be switched on and off for any > board. > > binman may provide addresses in the control device-tree which later could be > relocated. But this seems to result in a larger image size. This is something analogous to the initrd/initramfs framework within the Linux kernel, yes? -- Tom signature.asc Description: PGP signature
Re: [PATCH] cmd: Add pause command
On Mon, Dec 20, 2021 at 10:49:46PM -0500, Samuel Dionne-Riel wrote: > This command is being introduced with the goal of allowing user-friendly > "generic use case" U-Boot builds to pause until user input under some > situations. > > The main use case would be when a boot failure happens, to pause until > the user has had time to acknowledge the current state. > > Signed-off-by: Samuel Dionne-Riel > --- > cmd/Kconfig | 7 +++ > cmd/Makefile | 1 + > cmd/pause.c | 35 +++ > 3 files changed, 43 insertions(+) > create mode 100644 cmd/pause.c Sorry for the delay. Please don't make this default, and also please add a test for the command. Thanks. -- Tom signature.asc Description: PGP signature
[PATCH 1/2] arm: layerscape: Add sfp driver
This adds a driver for the Security Fuse Processor (SFP) present on LS1012A, LS1021A, LS1043A, and LS1046A processors. It holds the Super-Root Key (SRK), One-Time-Programmable Master Key (OTPMK), and other "security" related fuses. Similar devices (sharing the same name) are present on other processors, but for the moment this just supports the LS2 variants. The mirror registers are loaded during power-on reset. All mirror registers must be programmed or read at once. Because of this, `fuse prog` will program all fuses, even though only one might be specified. To prevent accidentally burning through all your fuse programming cycles with something like `fuse prog 0 0 A B C D`, we limit ourselves to one programming cycle per reset. Fuses are numbered based on their address. The fuse at 0x1e80200 is 0, the fuse at 0x1e80204 is 1, etc. The TA_PROG_SFP supply must be enabled when programming fuses, but must be disabled when reading them. Typically this supply is enabled by inserting a jumper or by setting a register in the board's FPGA. I've also added support for using a regulator. This could be helpful for automatically issuing the FPGA write, or for toggling a GPIO controlling the supply. I suggest using the following procedure for programming: 1. Override the fuses you wish to program => fuse override 0 2 A B C D 2. Inspect the values and ensure that they are what you expect => fuse sense 0 2 4 3. Enable TA_PROG_SFP 4. Issue a program command using OSPR0 as a dummy. Since it contains the write-protect bit you will usually want to write it last anyway. => fuse prog 0 0 0 5. Disable TA_PROG_SFP 6. Read back the fuses and ensure they are correct => fuse read 0 2 4 Signed-off-by: Sean Anderson --- MAINTAINERS| 5 + drivers/misc/Kconfig | 14 ++ drivers/misc/Makefile | 1 + drivers/misc/ls2_sfp.c | 350 + 4 files changed, 370 insertions(+) create mode 100644 drivers/misc/ls2_sfp.c diff --git a/MAINTAINERS b/MAINTAINERS index 7a9e3156f4..6a302b35e2 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -271,6 +271,11 @@ F: drivers/spi/spi-qup.c F: drivers/net/mdio-ipq4019.c F: drivers/rng/msm_rng.c +ARM LAYERSCAPE SFP +M: Sean Anderson +S: Maintained +F: drivers/misc/ls2_sfp.c + ARM MARVELL KIRKWOOD ARMADA-XP ARMADA-38X ARMADA-37XX ARMADA-7K/8K M: Stefan Roese S: Maintained diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index 7029bb7b5c..2a86c42017 100644 --- a/drivers/misc/Kconfig +++ b/drivers/misc/Kconfig @@ -224,6 +224,20 @@ config JZ4780_EFUSE help This selects support for the eFUSE on Ingenic JZ4780 SoCs. +config LS2_SFP + bool "Layerscape Security Fuse Processor" + depends on FSL_LSCH2 || ARCH_LS1021A + depends on MISC + imply DM_REGULATOR + help + This adds support for the Security Fuse Processor found on Layerscape + SoCs. It contains various fuses related to secure boot, including the + Super Root Key hash, One-Time-Programmable Master Key, Debug + Challenge/Response values, and others. Fuses are numbered according + to their four-byte offset from the start of the bank. + + If you don't need to read/program fuses, say 'n'. + config MXC_OCOTP bool "Enable MXC OCOTP Driver" depends on ARCH_IMX8M || ARCH_MX6 || ARCH_MX7 || ARCH_MX7ULP || ARCH_VF610 diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile index b7a8ef68ab..4926671833 100644 --- a/drivers/misc/Makefile +++ b/drivers/misc/Makefile @@ -50,6 +50,7 @@ obj-$(CONFIG_IMX8ULP) += imx8ulp/ obj-$(CONFIG_LED_STATUS) += status_led.o obj-$(CONFIG_LED_STATUS_GPIO) += gpio_led.o obj-$(CONFIG_MPC83XX_SERDES) += mpc83xx_serdes.o +obj-$(CONFIG_$(SPL_TPL_)LS2_SFP) += ls2_sfp.o obj-$(CONFIG_$(SPL_)MXC_OCOTP) += mxc_ocotp.o obj-$(CONFIG_MXS_OCOTP) += mxs_ocotp.o obj-$(CONFIG_NUVOTON_NCT6102D) += nuvoton_nct6102d.o diff --git a/drivers/misc/ls2_sfp.c b/drivers/misc/ls2_sfp.c new file mode 100644 index 00..df54b0c89e --- /dev/null +++ b/drivers/misc/ls2_sfp.c @@ -0,0 +1,350 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (C) 2022 Sean Anderson + * + * This driver supports the Security Fuse Processor device found on some + * Layerscape processors. At the moment, we only support a few processors. + * This driver was written with reference to the Layerscape SDK User + * Guide [1] and the ATF SFP driver [2]. + * + * [1] https://docs.nxp.com/bundle/GUID-487B2E69-BB19-42CB-AC38-7EF18C0FE3AE/page/GUID-27FC40AD-3321-4A82-B29E-7BB49EE94F23.html + * [2] https://source.codeaurora.org/external/qoriq/qoriq-components/atf/tree/drivers/nxp/sfp?h=github.com/master + */ + +#define LOG_CATEGORY UCLASS_MISC +#include +#include +#include +#include +#include +#include +#include +#include +#include + +DECLARE_GLOBAL_DATA_PTR; + +#define SFP_INGR 0x20 +#define SFP_SVHESR 0x24 +#define SFP_SFPCR
[PATCH 2/2] arch: layerscape: Add SFP binding
This adds an SFP binding for the processors it is present on. I have
only tested this for the LS1046A.
Signed-off-by: Sean Anderson
---
arch/arm/dts/fsl-ls1012a.dtsi | 7 +++
arch/arm/dts/fsl-ls1043a.dtsi | 7 +++
arch/arm/dts/fsl-ls1046a.dtsi | 7 +++
arch/arm/dts/ls1021a.dtsi | 7 +++
4 files changed, 28 insertions(+)
diff --git a/arch/arm/dts/fsl-ls1012a.dtsi b/arch/arm/dts/fsl-ls1012a.dtsi
index 0ea899c7d7..510d863a66 100644
--- a/arch/arm/dts/fsl-ls1012a.dtsi
+++ b/arch/arm/dts/fsl-ls1012a.dtsi
@@ -34,6 +34,13 @@
#size-cells = <2>;
ranges;
+ sfp: efuse@1e8 {
+ compatible = "fsl,ls1021a-sfp";
+ reg = <0x0 0x1e8 0x0 0x1000>;
+ clocks = < 4 0>;
+ clock-names = "ipg";
+ };
+
clockgen: clocking@1ee1000 {
compatible = "fsl,ls1012a-clockgen";
reg = <0x0 0x1ee1000 0x0 0x1000>;
diff --git a/arch/arm/dts/fsl-ls1043a.dtsi b/arch/arm/dts/fsl-ls1043a.dtsi
index 52dc5a9638..13a999f6f4 100644
--- a/arch/arm/dts/fsl-ls1043a.dtsi
+++ b/arch/arm/dts/fsl-ls1043a.dtsi
@@ -38,6 +38,13 @@
#size-cells = <2>;
ranges;
+ sfp: efuse@1e8 {
+ compatible = "fsl,ls1021a-sfp";
+ reg = <0x0 0x1e8 0x0 0x1000>;
+ clocks = < 4 0>;
+ clock-names = "ipg";
+ };
+
clockgen: clocking@1ee1000 {
compatible = "fsl,ls1043a-clockgen";
reg = <0x0 0x1ee1000 0x0 0x1000>;
diff --git a/arch/arm/dts/fsl-ls1046a.dtsi b/arch/arm/dts/fsl-ls1046a.dtsi
index a60cbf11fc..f7026e16e0 100644
--- a/arch/arm/dts/fsl-ls1046a.dtsi
+++ b/arch/arm/dts/fsl-ls1046a.dtsi
@@ -37,6 +37,13 @@
#size-cells = <2>;
ranges;
+ sfp: efuse@1e8 {
+ compatible = "fsl,ls1021a-sfp";
+ reg = <0x0 0x1e8 0x0 0x1000>;
+ clocks = < 4 0>;
+ clock-names = "ipg";
+ };
+
clockgen: clocking@1ee1000 {
compatible = "fsl,ls1046a-clockgen";
reg = <0x0 0x1ee1000 0x0 0x1000>;
diff --git a/arch/arm/dts/ls1021a.dtsi b/arch/arm/dts/ls1021a.dtsi
index 86192cbb7f..1e1b52eab4 100644
--- a/arch/arm/dts/ls1021a.dtsi
+++ b/arch/arm/dts/ls1021a.dtsi
@@ -81,6 +81,13 @@
interrupts = ;
};
+ sfp: efuse@1e8 {
+ compatible = "fsl,ls1021a-sfp";
+ reg = <0x0 0x1e8 0x0 0x1000>;
+ clocks = <_clk 1>;
+ clock-names = "ipg";
+ };
+
dcfg: dcfg@1ee {
compatible = "fsl,ls1021a-dcfg", "syscon";
reg = <0x1ee 0x1>;
--
2.35.1.1320.gc452695387.dirty
[PATCH] board: ls1046afrwy: Remove Manish Tomar's email
Manish Tomar's email bounces. Remove it, and reassign the config he was maintaining to the primary maintainer for the board. Signed-off-by: Sean Anderson --- board/freescale/ls1046afrwy/MAINTAINERS | 4 1 file changed, 4 deletions(-) diff --git a/board/freescale/ls1046afrwy/MAINTAINERS b/board/freescale/ls1046afrwy/MAINTAINERS index cb8aa8c378..8f360e1820 100644 --- a/board/freescale/ls1046afrwy/MAINTAINERS +++ b/board/freescale/ls1046afrwy/MAINTAINERS @@ -5,8 +5,4 @@ F: board/freescale/ls1046afrwy/ F: board/freescale/ls1046afrwy/ls1046afrwy.c F: include/configs/ls1046afrwy.h F: configs/ls1046afrwy_tfa_defconfig - -LS1046AFRWY_SECURE_BOOT BOARD -M: Manish Tomar -S: Maintained F: configs/ls1046afrwy_tfa_SECURE_BOOT_defconfig -- 2.35.1.1320.gc452695387.dirty
Re: Falcon Mode Support For Uncompressed Kernel Images
On Tue, Apr 19, 2022 at 05:16:21PM -0400, Nathan Barrett-Morrison wrote:
> Hi Tom,
>
> Let's see if this works any better. Using a new mail client that is supposed
> to not modify whitespace:
>
> From f1c34333f79996bd2927a60f4858c01699431cba Mon Sep 17 00:00:00 2001
> From: Nathan Barrett Morrison
> Date: Wed, 2 Feb 2022 15:05:18 -0500
> Subject: [PATCH v2] Add in the ability to load and boot an uncompressed kernel
> image during the Falcon Mode boot sequence.
>
> This is required for architectures which do not support compressed kernel
> images (i.e. ARM64). This is only used while not booting via FIT image.
>
> Signed-off-by: Nathan Barrett-Morrison
> Cc: Tom Rini
> ---
> Changes for v2:
>- Remove original SPL_OS_BOOT_UNCOMPRESSED option and check via CMD_BOOTI
> and CMD_BOOTZ instead
Whitespace is fine, but since it's in reply to the previous email, that
really throws patchwork for a loop so this doesn't show up yet. Please
do this is a new thread, thanks.
>
> arch/arm/lib/Makefile | 5 -
> common/spl/spl.c | 21 +
> 2 files changed, 25 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
> index c603fe61bc..08b7475e37 100644
> --- a/arch/arm/lib/Makefile
> +++ b/arch/arm/lib/Makefile
> @@ -36,7 +36,10 @@ obj-$(CONFIG_CMD_BOOTZ) += bootm.o zimage.o
> obj-$(CONFIG_SYS_L2_PL310) += cache-pl310.o
> else
> obj-$(CONFIG_$(SPL_TPL_)FRAMEWORK) += spl.o
> -obj-$(CONFIG_SPL_FRAMEWORK) += zimage.o
> +ifdef CONFIG_SPL_FRAMEWORK
> +obj-$(CONFIG_CMD_BOOTI) += image.o
> +obj-$(CONFIG_CMD_BOOTZ) += zimage.o
> +endif
> obj-$(CONFIG_OF_LIBFDT) += bootm-fdt.o
> endif
> ifdef CONFIG_ARM64
> diff --git a/common/spl/spl.c b/common/spl/spl.c
> index c9750ee163..7b86443f1b 100644
> --- a/common/spl/spl.c
> +++ b/common/spl/spl.c
> @@ -107,6 +107,11 @@ int __weak bootz_setup(ulong image, ulong *start, ulong
> *end)
> {
>return 1;
> }
> +
> +int __weak booti_setup(ulong image, ulong *relocated_addr, ulong *size, bool
> force_reloc)
> +{
> + return 1;
> +}
> #endif
>
> /* Weak default function for arch/board-specific fixups to the
> spl_image_info */
> @@ -366,6 +371,21 @@ int spl_parse_image_header(struct spl_image_info
> *spl_image,
> #endif
>
> #if CONFIG_IS_ENABLED(OS_BOOT)
> +#if defined(CMD_BOOTI)
> + ulong start, size;
> +
> + if (!booti_setup((ulong)header, , , 0)) {
> + spl_image->name = "Linux";
> + spl_image->os = IH_OS_LINUX;
> + spl_image->load_addr = start;
> + spl_image->entry_point = start;
> + spl_image->size = size;
> + debug(SPL_TPL_PROMPT
> + "payload Image, load addr: 0x%lx size: %d\n",
> + spl_image->load_addr, spl_image->size);
> + return 0;
> + }
> +#elif defined(CMD_BOOTZ)
> ulong start, end;
>
> if (!bootz_setup((ulong)header, , )) {
> @@ -379,6 +399,7 @@ int spl_parse_image_header(struct spl_image_info
> *spl_image,
> spl_image->load_addr, spl_image->size);
> return 0;
> }
> +#endif
> #endif
>
> if (!spl_parse_board_header(spl_image, bootdev, (const void
> *)header, sizeof(*header)))
> --
> 2.30.2
>
> On 4/19/22 16:30, Tom Rini wrote:
> > On Wed, Feb 02, 2022 at 04:53:11PM -0500, Nathan Barrett-Morrison wrote:
> >> Hi Tom,
> >>
> >> I've attached version 2 of the patch. I believe this should adhere more
> >> closely to your suggestions.
> >>
> >> Keep in mind, CONFIG_IS_ENABLED will not work for checking
> >> CMD_BOOTI/CMD_BOOTZ in this case, as there is no CONFIG_SPL_CMD_BOOTx. So,
> >> I'm just directly checking if it's defined instead.
> >>
> >> I verified both CONFIG_IS_ENABLED() and IS_ENABLED() did not work.
> >>
> >> Sincerely,
> >> Nathan
> >>
> >> On Mon, Jan 31, 2022 at 10:35 AM Tom Rini wrote:
> >>
> >>> On Mon, Jan 31, 2022 at 10:23:58AM -0500, Nathan Barrett-Morrison wrote:
> >>>
> Hi Tom,
>
> Yea, I'm not sure if uncompressed ARM32 would work, but I don't believe
> >>> it
> was ever working to begin with... as bootz_setup is being called right
> >>> now
> ( @
> >>> https://source.denx.de/u-boot/u-boot/-/blob/master/common/spl/spl.c#L366
> )
>
> My intent was for SPL_OS_BOOT_UNCOMPRESSED to only be used for platforms
> which need booti_setup (ARM64, ...).
>
> So... I could add a dependency on ARM64 in the config option or I could
> remove the option altogether and let the booti_setup fail and fallback to
> bootz_setup. Would either of those work for you?
> >>>
> >>> The code and logic overall needs a bit of refactoring to support
> >>> "booti", "bootz" and also FIT images. I believe FIT images are how
> >>> anyone doing falcon mode on arm64 has worked thus
drivers: mtd: spi: Allow Quad I/O enablement for ISSI SPI flash devices alongside spi-nor-tiny.c subsystem
Hi All,
I noticed this was missing from the spi-nor-tiny.c subsystem while trying to
use an ISSI SPI flash device with the U-Boot SPL.
This patch will allow Quad (4x) I/O mode to be enabled with ISSI flash devices
while inside the U-Boot SPL / using spi-nor-tiny.c.
Sincerely,
Nathan
>From 1a7fd52f21d3d3ad4b2ff736a9ea3c1affb9c007 Mon Sep 17 00:00:00 2001
From: Nathan Barrett-Morrison
Date: Wed, 26 Jan 2022 13:44:39 -0500
Subject: [PATCH] drivers: mtd: spi: Allow Quad I/O enablement for ISSI SPI
flash devices alongside spi-nor-tiny.c subsystem
Signed-off-by: Nathan Barrett-Morrison
Cc: Jagan Teki
Cc: Vignesh R
CC: Tom Rini
---
drivers/mtd/spi/spi-nor-tiny.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mtd/spi/spi-nor-tiny.c b/drivers/mtd/spi/spi-nor-tiny.c
index 130917aaa8..4957448d11 100644
--- a/drivers/mtd/spi/spi-nor-tiny.c
+++ b/drivers/mtd/spi/spi-nor-tiny.c
@@ -664,6 +664,7 @@ static int spi_nor_setup(struct spi_nor *nor, const struct
flash_info *info,
switch (JEDEC_MFR(info)) {
#ifdef CONFIG_SPI_FLASH_MACRONIX
case SNOR_MFR_MACRONIX:
+ case SNOR_MFR_ISSI:
err = macronix_quad_enable(nor);
break;
#endif
--
2.34.1
spl: spi: Raw Kernel Image Support for Falcon Mode Boot Via SPI Devices
Hi Tom, I believe this patch is still relevant, so I'm resubmitting it. It was previously marked as superseded. Thanks, Nathan >From 0bb98a42bcb01c078f63513d9151d307dbfd6ccd Mon Sep 17 00:00:00 2001 From: Nathan Barrett-Morrison Date: Tue, 19 Apr 2022 17:35:21 -0400 Subject: [PATCH v2] Allow Falcon Mode boot to use raw kernel image when booting via SPI. When using Falcon Mode boot with a raw, unwrapped kernel image, the bootz_setup() call inside of spl_parse_image_header() is unreachable because the mkimage header magic check in spi_load_image_os() will never pass. This check is entirely redundant and unnecessary, as the spl_parse_image_header() call will also check for IH_MAGIC. Signed-off-by: Nathan Barrett-Morrison Cc: Tom Rini --- Changes for v2: - Remove proposed CONFIG_SYS_SPI_KERNEL_SKIP_HEADER option, as we've determined the entire check is redundant and unnecessary. Just delete it instead. common/spl/spl_spi.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/common/spl/spl_spi.c b/common/spl/spl_spi.c index cf3f7ef4c0..22e9c87eae 100644 --- a/common/spl/spl_spi.c +++ b/common/spl/spl_spi.c @@ -34,9 +34,6 @@ static int spi_load_image_os(struct spl_image_info *spl_image, spi_flash_read(flash, CONFIG_SYS_SPI_KERNEL_OFFS, sizeof(*header), (void *)header); - if (image_get_magic(header) != IH_MAGIC) - return -1; - err = spl_parse_image_header(spl_image, bootdev, header); if (err) return err; -- 2.30.2
Re: [PATCH 2/2] arch: layerscape: Add SFP binding
Hi Michael, On 4/19/22 7:26 PM, Michael Walle wrote: Hi Sean, This adds an SFP binding for the processors it is present on. I have only tested this for the LS1046A. Signed-off-by: Sean Anderson There is an upstream binding Documentation/devicetree/bindings/nvmem/fsl,layerscape-sfp.yaml I see it will be added in 5.18, neat. Are you aware of that? I am now. Could you submit a patch there to add your new compatibles? Sure. I didn't know there was an upstream binding, but I'll try and add these properties. Esp. because you are using a clock which isn't described in the upstream binding. I'm curious, do you need the clock? I only know the LS1028A and it seems you don't have to turn on any clock there. It might also be the case I've missed something. You need the clock to set the programming duration properly. See the probe function for this driver. For read-only access, it is not necessary. --Sean
Re: [PATCH v2] soc: xilinx: versal: fix out of bounds array access
On 16/04/22, Jorge Ramirez-Ortiz wrote:
> The call to xilinx_pm_request requires an array of a larger size.
>
> Signed-off-by: Jorge Ramirez-Ortiz
> ---
> drivers/soc/soc_xilinx_versal.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/soc/soc_xilinx_versal.c b/drivers/soc/soc_xilinx_versal.c
> index f8bcd9ab40..3d8c25c19b 100644
> --- a/drivers/soc/soc_xilinx_versal.c
> +++ b/drivers/soc/soc_xilinx_versal.c
> @@ -45,7 +45,7 @@ static const struct soc_ops soc_xilinx_versal_ops = {
> static int soc_xilinx_versal_probe(struct udevice *dev)
> {
> struct soc_xilinx_versal_priv *priv = dev_get_priv(dev);
> - u32 ret_payload[4];
> + u32 ret_payload[PAYLOAD_ARG_CNT];
all good? can this be merged?
> int ret;
>
> priv->family = versal_family;
> --
> 2.34.1
>
[PATCH] tools: kwboot: Fix spelling of "followed" in kwboot.1
Fix spelling of "followed" in kwboot.1 manpage. Series: 2 Signed-off-by: Vagrant Cascadian --- Changes in v2: Use "tools: kwboot:" prefix. Add full commit message. doc/kwboot.1 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/kwboot.1 b/doc/kwboot.1 index f555ff26a2..d663bf1f77 100644 --- a/doc/kwboot.1 +++ b/doc/kwboot.1 @@ -74,7 +74,7 @@ BootROM's standard input and BootROM's terminal echo are active and working fine. To workaround this BootROM bug with standard output, it is possible to manually overwrite BootROM variables stored in SRAM which BootROM use for checking if standard output is enabled or not. To enable BootROM -standard output on UART, type this command folled by ENTER key: +standard output on UART, type this command followed by ENTER key: .RS 1.2i .TP -- 2.35.1
RE: [PATCH 2/2] arm: layerscape: Disable erratum A009007 on LS1021A, LS1043A, and LS1046A
Hi Sean, > -Original Message- > From: Sean Anderson > Sent: Wednesday, April 20, 2022 3:32 AM > To: u-boot@lists.denx.de; Priyanka Jain > Cc: Yinbo Zhu ; Ran Wang ; Prabhakar > Kushwaha ; Tom > Rini > Subject: Re: [PATCH 2/2] arm: layerscape: Disable erratum A009007 on LS1021A, > LS1043A, and LS1046A > > On 2/22/22 1:38 PM, Sean Anderson wrote: > > This erratum is reported to cause problems on these processors [1-3]. > > The problem is usually with the clocking, which is supposed to be > > configured by the RCW [4]. However, if it is not set, or if the > > default clocking is not correct, then this erratum will cause an SError. > > However, according to Ran Wang in [1]: > > > >> ... this erratum is used to pass USB compliance test only, you could > >> disable this workaround on your board if you don't any USB issue on > >> normal use case, I think it's fine. > > > > So just disable this erratum by default for these processors. > > > > [1] > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore > > .kernel.org%2Fall%2F761ddd61-05c1-d9b8-ac90-b8f425afde6c%40denx.de%2F& > > amp;data=05%7C01%7Cran.wang_1%40nxp.com%7C3a19547d54eb46a572cc08da223b > > 3cff%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637859935071826709%7 > > CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1 > > haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=0QLVw7ZIW9SYBrTqtCIfFClz > > eA63jn72oAMlw18Y6FA%3Dreserved=0 > > [2] > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcomm > > unity.nxp.com%2Ft5%2FLayerscape%2FLS1046A-U-BOOT-HALT-AT-ERRATUM-A0090 > > 078%2Fm-p%2F742993data=05%7C01%7Cran.wang_1%40nxp.com%7C3a19547d5 > > 4eb46a572cc08da223b3cff%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6 > > 37859935071826709%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi > > V2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=dTV6k > > AUn%2BqNDzdXEoEb0EwJEzqbTcFBVFeFpy3XbcnM%3Dreserved=0 > > [3] > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcomm > > unity.nxp.com%2Ft5%2FQorIQ%2FWhy-does-the-LS1043A-U-Boot-hang-at-code- > > that-fixes-erratum%2Fm-p%2F644412data=05%7C01%7Cran.wang_1%40nxp. > > com%7C3a19547d54eb46a572cc08da223b3cff%7C686ea1d3bc2b4c6fa92cd99c5c301 > > 635%7C0%7C0%7C637859935071826709%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wL > > jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C& > > amp;sdata=5xJd%2BrKCd8b%2Ft8AovVisDuLAsg%2B7aJz%2FA4wZp7echB0%3Dr > > eserved=0 [4] > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsour > > ce.codeaurora.org%2Fexternal%2Fqoriq%2Fqoriq-components%2Frcw%2Ftree%2 > > Fls1046ardb%2Fusb_phy_freq.rcwdata=05%7C01%7Cran.wang_1%40nxp.com > > %7C3a19547d54eb46a572cc08da223b3cff%7C686ea1d3bc2b4c6fa92cd99c5c301635 > > %7C0%7C0%7C637859935071826709%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw > > MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C > > ;sdata=I9mZiTLAofR7%2F0aWsLvOGoI%2B9xEDhPmRJADbBOZiwwU%3Dreserved > > =0 > > > > Signed-off-by: Sean Anderson Acked-by: Ran Wang > > --- > > > > arch/arm/cpu/armv7/ls102xa/Kconfig| 1 - > > arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 2 -- > > 2 files changed, 3 deletions(-) > > > > diff --git a/arch/arm/cpu/armv7/ls102xa/Kconfig > > b/arch/arm/cpu/armv7/ls102xa/Kconfig > > index 6a948d7ba7..cec93a27db 100644 > > --- a/arch/arm/cpu/armv7/ls102xa/Kconfig > > +++ b/arch/arm/cpu/armv7/ls102xa/Kconfig > > @@ -7,7 +7,6 @@ config ARCH_LS1021A > > select SYS_FSL_ERRATUM_A008407 > > select SYS_FSL_ERRATUM_A008850 > > select SYS_FSL_ERRATUM_A008997 if USB > > - select SYS_FSL_ERRATUM_A009007 if USB > > select SYS_FSL_ERRATUM_A009008 if USB > > select SYS_FSL_ERRATUM_A009663 > > select SYS_FSL_ERRATUM_A009798 if USB diff --git > > a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig > > b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig > > index 9bb870dcd8..f5a18053e6 100644 > > --- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig > > +++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig > > @@ -74,7 +74,6 @@ config ARCH_LS1043A > > select SYS_FSL_DDR_VER_50 > > select SYS_FSL_ERRATUM_A008850 if !TFABOOT > > select SYS_FSL_ERRATUM_A008997 > > - select SYS_FSL_ERRATUM_A009007 > > select SYS_FSL_ERRATUM_A009008 > > select SYS_FSL_ERRATUM_A009660 if !TFABOOT > > select SYS_FSL_ERRATUM_A009663 if !TFABOOT @@ -112,7 +111,6 @@ > > config ARCH_LS1046A > > select SYS_FSL_ERRATUM_A008511 if !TFABOOT > > select SYS_FSL_ERRATUM_A008850 if !TFABOOT > > select SYS_FSL_ERRATUM_A008997 > > - select SYS_FSL_ERRATUM_A009007 > > select SYS_FSL_ERRATUM_A009008 > > select SYS_FSL_ERRATUM_A009798 > > select SYS_FSL_ERRATUM_A009801 > > > > ping? Can someone from NXP comment on this (either for or against)? I am not longer take USB ownership for Layerscape platforms. Please also include my colleague Jun for any further review. Thanks & Regards, Ran
Re: [PATCH 3/7] disk: define nullified functions for !PARTITIONS
On Wed, Apr 20, 2022 at 11:17:21AM +0900, AKASHI Takahiro wrote: > Hi Tom, > > On Tue, Apr 19, 2022 at 08:12:07AM -0400, Tom Rini wrote: > > On Tue, Apr 19, 2022 at 01:11:23PM +0900, AKASHI Takahiro wrote: > > > On Mon, Apr 18, 2022 at 11:09:38PM -0400, Tom Rini wrote: > > > > On Tue, Apr 19, 2022 at 10:01:54AM +0900, AKASHI Takahiro wrote: > > > > > > > > > Some defconfig enables CMD_PART even if none of any partition table > > > > > types (CONFIG_*_PARTITION) are enabled. > > > > > This will lead to the size growth in SPL/TPL code since disk/part.c > > > > > will be compiled in any way. > > > > > We will change disk/Kconfig later so that CONFIG_PARTITIONS is only > > > > > enabled when, at least, one of CONFIG_*_PARTITION is enabled. > > > > > > > > > > To make the build work (in particular, "part" command) correctly, > > > > > a few functions should be defined as void functions in case of > > > > > !CONFIG_PARTITIONS. > > > > > > > > > > Signed-off-by: AKASHI Takahiro > > > > > > > > I guess I wonder why we don't just make CMD_PART depend on PARTITIONS > > > > now and thus correct the few (single?) board that has this enabled > > > > without underlying partition code by removing the can't be functional > > > > cmd. > > > > > > Well, that is partially what I did in my RFC and I thought > > > that you declined to accept my change. > > > Did I misunderstand you? > > > > Yes, I wasn't clear, sorry for the confusion. Just this part of the > > series should be replaced with making CMD_PART depend on PARTITIONS and > > if there really is a use case for 'part' without PARTITION support > > (rather than it being an unintentionally enabled feature) we can deal > > with it then. The rest of the series looks good to me and I'll let > > Heinrich comment on the EFI specific parts. > > I do understand what you expect here, but, what I call, "nullified > function" technique is already used in several places. > For instance, take blk_get_device_part_str() function which has > a nullified version of definition in include/part.h. > It is used without explicit dependency on CONFIG_PARTITIONS at: > cmd/zfs.c > cmd/disk.c > cmd/reiser.c > cmd/fat.c > env/ext4.c > env/fat.c > > So I would like to propose to create another patch that you expect (and > what I did in RFC) instead of removing this patch because the latter > has no negative effect. > > If you agree, I will post it as a separate patch. OK, lets go with that then, thanks! -- Tom signature.asc Description: PGP signature
[PATCH 1/2] riscv: ae350: Fix OF_BOARD boot failure
From: Rick Chen
Enable OF_HAS_PRIOR_STAGE for ae350 boards with OF_BOARD
Fixes: 239d22c79520 ("fdt: Enable OF_HAS_PRIOR_STAGE for most boards with
OF_BOARD")
Signed-off-by: Rick Chen
---
board/AndesTech/ax25-ae350/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/board/AndesTech/ax25-ae350/Kconfig
b/board/AndesTech/ax25-ae350/Kconfig
index e50f505a2b..91eec35f47 100644
--- a/board/AndesTech/ax25-ae350/Kconfig
+++ b/board/AndesTech/ax25-ae350/Kconfig
@@ -35,5 +35,6 @@ config BOARD_SPECIFIC_OPTIONS # dummy
imply SMP
imply SPL_RAM_SUPPORT
imply SPL_RAM_DEVICE
+ imply OF_HAS_PRIOR_STAGE
endif
--
2.17.1
[PATCH 2/2] riscv: ae350: Fix OF_BOARD boot failure
From: Rick Chen
Disable BINMAN_FDT for ae350 boards which don't actually use it.
Fixes: 836eac7c6fe3 ("fdt: Make OF_BOARD a bool option")
Signed-off-by: Rick Chen
---
configs/ae350_rv32_spl_defconfig | 1 +
configs/ae350_rv32_spl_xip_defconfig | 1 +
configs/ae350_rv64_spl_defconfig | 1 +
configs/ae350_rv64_spl_xip_defconfig | 1 +
4 files changed, 4 insertions(+)
diff --git a/configs/ae350_rv32_spl_defconfig b/configs/ae350_rv32_spl_defconfig
index 2924c892f7..d46e8711c2 100644
--- a/configs/ae350_rv32_spl_defconfig
+++ b/configs/ae350_rv32_spl_defconfig
@@ -15,6 +15,7 @@ CONFIG_SPL_LOAD_FIT_ADDRESS=0x0020
CONFIG_SYS_MONITOR_BASE=0x8800
CONFIG_BOOTDELAY=3
CONFIG_BOARD_EARLY_INIT_F=y
+# CONFIG_BINMAN_FDT is not set
CONFIG_SYS_PROMPT="RISC-V # "
CONFIG_CMD_IMLS=y
CONFIG_CMD_MMC=y
diff --git a/configs/ae350_rv32_spl_xip_defconfig
b/configs/ae350_rv32_spl_xip_defconfig
index 91e88a3341..7f15761329 100644
--- a/configs/ae350_rv32_spl_xip_defconfig
+++ b/configs/ae350_rv32_spl_xip_defconfig
@@ -17,6 +17,7 @@ CONFIG_SPL_LOAD_FIT_ADDRESS=0x8001
CONFIG_SYS_MONITOR_BASE=0x8800
CONFIG_BOOTDELAY=3
CONFIG_BOARD_EARLY_INIT_F=y
+# CONFIG_BINMAN_FDT is not set
CONFIG_SYS_PROMPT="RISC-V # "
CONFIG_CMD_IMLS=y
CONFIG_CMD_MMC=y
diff --git a/configs/ae350_rv64_spl_defconfig b/configs/ae350_rv64_spl_defconfig
index 27ea0b72f7..dfa4b823db 100644
--- a/configs/ae350_rv64_spl_defconfig
+++ b/configs/ae350_rv64_spl_defconfig
@@ -16,6 +16,7 @@ CONFIG_SPL_LOAD_FIT_ADDRESS=0x0020
CONFIG_SYS_MONITOR_BASE=0x8800
CONFIG_BOOTDELAY=3
CONFIG_BOARD_EARLY_INIT_F=y
+# CONFIG_BINMAN_FDT is not set
CONFIG_SYS_PROMPT="RISC-V # "
CONFIG_CMD_IMLS=y
CONFIG_CMD_MMC=y
diff --git a/configs/ae350_rv64_spl_xip_defconfig
b/configs/ae350_rv64_spl_xip_defconfig
index 1c1bda6ee9..4b590e5950 100644
--- a/configs/ae350_rv64_spl_xip_defconfig
+++ b/configs/ae350_rv64_spl_xip_defconfig
@@ -18,6 +18,7 @@ CONFIG_SPL_LOAD_FIT_ADDRESS=0x8001
CONFIG_SYS_MONITOR_BASE=0x8800
CONFIG_BOOTDELAY=3
CONFIG_BOARD_EARLY_INIT_F=y
+# CONFIG_BINMAN_FDT is not set
CONFIG_SYS_PROMPT="RISC-V # "
CONFIG_CMD_IMLS=y
CONFIG_CMD_MMC=y
--
2.17.1
[PATCH] riscv: ae350: Fix xip config boot failure
From: Rick Chen
It will fail to boot with ae350_rv[32|64]_spl_xip_defconfig.
It need to add OONFIG_XIP to get the specific HW address for DTB.
Also drop OF_SEPARATE in board_fdt_blob_setup() because it will
never reach here anyway.It only allow OF_BOARD to call
board_fdt_blob_setup() in fdtdec_setup().
Fixes: 2e8d2f88439d ("riscv: Remove OF_PRIOR_STAGE from RISC-V boards")
Signed-off-by: Rick Chen
---
board/AndesTech/ax25-ae350/ax25-ae350.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/board/AndesTech/ax25-ae350/ax25-ae350.c
b/board/AndesTech/ax25-ae350/ax25-ae350.c
index d6a4291..9ca7fdf 100644
--- a/board/AndesTech/ax25-ae350/ax25-ae350.c
+++ b/board/AndesTech/ax25-ae350/ax25-ae350.c
@@ -54,13 +54,20 @@ ulong board_flash_get_legacy(ulong base, int banknum,
flash_info_t *info)
return 0;
}
+#define ANDES_HW_DTB_ADDRESS 0xF200
void *board_fdt_blob_setup(int *err)
{
*err = 0;
+
#if defined(CONFIG_OF_BOARD)
- return (void *)(ulong)gd->arch.firmware_fdt_addr;
-#elif defined(CONFIG_OF_SEPARATE)
+#if (defined(CONFIG_XIP) && CONFIG_IS_ENABLED(RISCV_MMODE))
+ if (fdt_magic(CONFIG_SYS_FDT_BASE) == FDT_MAGIC)
return (void *)CONFIG_SYS_FDT_BASE;
+ return (void *)ANDES_HW_DTB_ADDRESS;
+#else
+
+ return (void *)(ulong)gd->arch.firmware_fdt_addr;
+#endif
#else
*err = -EINVAL;
return NULL;
--
2.7.4
Re: [PATCH 3/7] disk: define nullified functions for !PARTITIONS
Hi Tom, On Tue, Apr 19, 2022 at 08:12:07AM -0400, Tom Rini wrote: > On Tue, Apr 19, 2022 at 01:11:23PM +0900, AKASHI Takahiro wrote: > > On Mon, Apr 18, 2022 at 11:09:38PM -0400, Tom Rini wrote: > > > On Tue, Apr 19, 2022 at 10:01:54AM +0900, AKASHI Takahiro wrote: > > > > > > > Some defconfig enables CMD_PART even if none of any partition table > > > > types (CONFIG_*_PARTITION) are enabled. > > > > This will lead to the size growth in SPL/TPL code since disk/part.c > > > > will be compiled in any way. > > > > We will change disk/Kconfig later so that CONFIG_PARTITIONS is only > > > > enabled when, at least, one of CONFIG_*_PARTITION is enabled. > > > > > > > > To make the build work (in particular, "part" command) correctly, > > > > a few functions should be defined as void functions in case of > > > > !CONFIG_PARTITIONS. > > > > > > > > Signed-off-by: AKASHI Takahiro > > > > > > I guess I wonder why we don't just make CMD_PART depend on PARTITIONS > > > now and thus correct the few (single?) board that has this enabled > > > without underlying partition code by removing the can't be functional > > > cmd. > > > > Well, that is partially what I did in my RFC and I thought > > that you declined to accept my change. > > Did I misunderstand you? > > Yes, I wasn't clear, sorry for the confusion. Just this part of the > series should be replaced with making CMD_PART depend on PARTITIONS and > if there really is a use case for 'part' without PARTITION support > (rather than it being an unintentionally enabled feature) we can deal > with it then. The rest of the series looks good to me and I'll let > Heinrich comment on the EFI specific parts. I do understand what you expect here, but, what I call, "nullified function" technique is already used in several places. For instance, take blk_get_device_part_str() function which has a nullified version of definition in include/part.h. It is used without explicit dependency on CONFIG_PARTITIONS at: cmd/zfs.c cmd/disk.c cmd/reiser.c cmd/fat.c env/ext4.c env/fat.c So I would like to propose to create another patch that you expect (and what I did in RFC) instead of removing this patch because the latter has no negative effect. If you agree, I will post it as a separate patch. -Takahiro Akashi > -- > Tom
