[PATCH v2] bootstage: Add SPL support
Allow usage of the bootstage facilities in SPL.
Signed-off-by: Marek Vasut
Cc: Simon Glass
---
V2: Fix multiple misuses of BOOTSTAGE vs SHOW_BOOT_PROGRESS
---
arch/x86/cpu/cpu.c| 2 +-
board/siemens/iot2050/board.c | 2 +-
common/Kconfig.boot | 9 +
common/init/board_init.c | 2 +-
common/spl/spl.c | 2 +-
include/bootstage.h | 2 +-
6 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/arch/x86/cpu/cpu.c b/arch/x86/cpu/cpu.c
index 01dece5769c..86f53e78d24 100644
--- a/arch/x86/cpu/cpu.c
+++ b/arch/x86/cpu/cpu.c
@@ -178,7 +178,7 @@ int default_print_cpuinfo(void)
return 0;
}
-#if CONFIG_IS_ENABLED(BOOTSTAGE)
+#if CONFIG_IS_ENABLED(SHOW_BOOT_PROGRESS)
void show_boot_progress(int val)
{
outb(val, POST_PORT);
diff --git a/board/siemens/iot2050/board.c b/board/siemens/iot2050/board.c
index b2110978ae0..16ae2ffc174 100644
--- a/board/siemens/iot2050/board.c
+++ b/board/siemens/iot2050/board.c
@@ -250,7 +250,7 @@ void spl_board_init(void)
{
}
-#if CONFIG_IS_ENABLED(LED) && CONFIG_IS_ENABLED(BOOTSTAGE)
+#if CONFIG_IS_ENABLED(LED) && CONFIG_IS_ENABLED(SHOW_BOOT_PROGRESS)
/*
* Indicate any error or (accidental?) entering of CLI via the red status LED.
*/
diff --git a/common/Kconfig.boot b/common/Kconfig.boot
index 9b84a8d005f..d0d0dbd09a3 100644
--- a/common/Kconfig.boot
+++ b/common/Kconfig.boot
@@ -696,6 +696,15 @@ config SHOW_BOOT_PROGRESS
-150 common/cmd_nand.c Incorrect FIT image format
151 common/cmd_nand.c FIT image format OK
+config SPL_SHOW_BOOT_PROGRESS
+ bool "Show boot progress in a board-specific manner"
+ depends on SPL
+ help
+ Defining this option allows to add some board-specific code (calling
+ a user-provided function show_boot_progress(int) that enables you to
+ show the system's boot progress on some display (for example, some
+ LEDs) on your board. For details see SHOW_BOOT_PROGRESS.
+
endmenu
menu "Boot media"
diff --git a/common/init/board_init.c b/common/init/board_init.c
index 0965b96fa3a..eab5ee13953 100644
--- a/common/init/board_init.c
+++ b/common/init/board_init.c
@@ -166,7 +166,7 @@ void board_init_f_init_reserve(ulong base)
board_init_f_init_stack_protection();
}
-#if CONFIG_IS_ENABLED(BOOTSTAGE)
+#if CONFIG_IS_ENABLED(SHOW_BOOT_PROGRESS)
/*
* Board-specific Platform code can reimplement show_boot_progress () if needed
*/
diff --git a/common/spl/spl.c b/common/spl/spl.c
index be09c19351a..d95a29b3655 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -61,7 +61,7 @@ binman_sym_declare(ulong, spl, size);
/* Define board data structure */
static struct bd_info bdata __attribute__ ((section(".data")));
-#if CONFIG_IS_ENABLED(BOOTSTAGE)
+#if CONFIG_IS_ENABLED(SHOW_BOOT_PROGRESS)
/*
* Board-specific Platform code can reimplement show_boot_progress () if needed
*/
diff --git a/include/bootstage.h b/include/bootstage.h
index f837a387c8c..8d1989ac0e5 100644
--- a/include/bootstage.h
+++ b/include/bootstage.h
@@ -220,7 +220,7 @@ enum bootstage_id {
*/
ulong timer_get_boot_us(void);
-#if defined(USE_HOSTCC) || !CONFIG_IS_ENABLED(BOOTSTAGE)
+#if defined(USE_HOSTCC) || !CONFIG_IS_ENABLED(SHOW_BOOT_PROGRESS)
#define show_boot_progress(val) do {} while (0)
#else
/**
--
2.33.0
Re: Pull request for efi-2022-01-rc1
On Fri, Oct 22, 2021 at 02:14:14PM +0200, Heinrich Schuchardt wrote: > The following changes since commit fb1018106a7bbb1a0d723029f6760b1b1b4d306d: > > Merge branch '2021-10-19-assorted-changes' (2021-10-19 20:45:12 -0400) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-efi.git > tags/efi-2022-01-rc1 > > for you to fetch changes up to af484011f12e2aa37bcf4f9cbb4258dea4ef14ac: > > efi_loader: Fix link of EFI apps with ld.lld (2021-10-21 03:46:04 +0200) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 0/7] arm64: dts: imx8mm: use common binman configuration and further clean-up
On Sat, 2021-10-23 at 01:15 +0200, Marcel Ziswiler wrote: > From: Marcel Ziswiler > > > With the move to using binman to generate SPL aka u-boot-spl-ddr.bin and > U-Boot proper aka u-boot.itb every board now covers such configuration > in its own U-Boot specific device tree include. Move the comon part of > that configuration to the common imx8mm-u-boot.dtsi include file. > > The initial patch fixes an issue with intermediate binary naming for the > imx8mm-cl-iot-gate. And subsequent patches further clean up that dtsi. > > This series is based on my refresh of Adam's imx8mm_beacon switch to > binman patch [1], my refresh of Michael's sl28 patches [2] Sorry, there was a misunderstanding on my side. This i.MX 8M Mini patch series, of course, does not depend on anything sl28 which is fsl-qoriq based hardware. Thanks to Michael for pointing that out and sorry again! > and Tim's > switching imx8mm_venice to using binman to pack images [3]. > > [1] https://marc.info/?l=u-boot=163493902915471 > [2] https://marc.info/?l=u-boot=163494122816224 > [3] https://marc.info/?l=u-boot=163355140309636 > > Changes in v3: > - Integrated imx8mm_beacon as well. > - Re-based on top of imx/master. > > Changes in v2: > - New patch preparing cl-iot-gate. > - New patch preparing cl-iot-gate. > - Morph common binman dtsi into regular common u-boot dtsi as discussed > on mailing list. > - Re-based. > - Rather than doing that clean-up to the separate binman dtsi now do it > to the common u-boot dtsi one. > - Rather than doing that clean-up to the separate binman dtsi now do it > to the common u-boot dtsi one. > - Rather than doing that clean-up to the separate binman dtsi now do it > to the common u-boot dtsi one. > > Changes in v1: > - This was suggested by Simon on my earlier patch set upon which we > decided to first break this up into a common binman dtsi and then > subsequently do such further improvements. > > Marcel Ziswiler (7): > imx8mm-cl-iot-gate: fix imximage intermediate binary naming > arm64: dts: imx8mm-cl-iot-gate-u-boot.dtsi: alphabetically re-order > arm64: dts: imx8mm-cl-iot-gate-u-boot.dtsi: use common > imx8mm-u-boot.dtsi > arm64: dts: imx8mm: use common binman configuration > arm64: dts: imx8mm-u-boot.dtsi: alphabetically re-order properties > arm64: dts: imx8mm-u-boot.dtsi: explicitly add spl filename > arm64: dts: imx8mm-u-boot.dtsi: improve odd blob-ext naming > > arch/arm/dts/imx8mm-beacon-kit-u-boot.dtsi | 122 -- > .../dts/imx8mm-cl-iot-gate-optee-u-boot.dtsi | 209 -- > arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi | 188 +++- > arch/arm/dts/imx8mm-evk-u-boot.dtsi | 123 --- > arch/arm/dts/imx8mm-u-boot.dtsi | 149 - > arch/arm/dts/imx8mm-venice-u-boot.dtsi | 119 -- > arch/arm/dts/imx8mm-verdin-u-boot.dtsi | 122 +- > .../imximage-8mm-lpddr4.cfg | 2 +- > 8 files changed, 212 insertions(+), 822 deletions(-)
Re: [PATCH v4 0/5] board: sl28: target refresh
On Sat, 2021-10-23 at 00:19 +0200, Marcel Ziswiler wrote: > From: Marcel Ziswiler > > > Note that this re-base is only compile tested. > > Changes in v4: > - Re-based on top of imx/master. > > Changes in v3: > - none > - use CONFIG_EFI_CAPSULE_FIRMWARE_FIT instead of > CONFIG_EFI_CAPSULE_FIRMWARE_RAW > > Changes in v2: > - none > - new patch > > Frieder Schrempf (1): > doc: board: kontron: sl28: Reduce section levels and change title > > Michael Walle (4): > board: sl28: enable EFI_SET_TIME support > board: sl28: generate FIT update image > board: sl28: enable EFI UpdateCapsule support > board: sl28: add update image documentation > > .../dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi | 35 ++- > configs/kontron_sl28_defconfig | 7 +++ > doc/board/kontron/sl28.rst | 45 --- > include/configs/kontron_sl28.h | 2 + > 4 files changed, 72 insertions(+), 17 deletions(-) Sorry, there was a misunderstanding on my side. Please just disregard this v4. Thanks!
Re: [PATCH v4 0/5] board: sl28: target refresh
Hi Michael On Sat, 2021-10-23 at 01:28 +0200, Michael Walle wrote: > Hi Marcel, > > Am 2021-10-23 01:09, schrieb Marcel Ziswiler: > > Sorry, I did not want to upset anybody. I probably should have asked > > first before doing this. > > You could have said the below in the cover letter. Then > I'd have at least an idea what is going on ;) > > > On Sat, 2021-10-23 at 00:52 +0200, Michael Walle wrote: > > > Hi Marcel, > > > > > > Am 2021-10-23 00:19, schrieb Marcel Ziswiler: > > > > From: Marcel Ziswiler > > > > > > > > > > > > Note that this re-base is only compile tested. > > > > > > Care to explain what this is? Why are you taking my patchset > > > and make a new version of it and rebasing it on the wrong > > > tree? > > > > You might have noticed that Stefano has a hard time applying some > > patch sets due to continuing conflicts. > > Therefore in trying to further the binman clean-up [1] were I am just > > about to post a new version as well, I > > took the liberty to re-fresh all the patches my series bases on which > > have not seen any care for more than a > > month. I re-based them on top of Stefano's u-boot-imx/master branch > > which I am very certain is exactly the tree > > stuff needs to be re-based to, not? > > This is a layerscape SoC board whose patches usually go through > u-boot-fsl-qoriq. Apart from the one doc fix there should be no > dependency on the u-boot-imx tree. I just took Frieder's doc fix > because my last patch depends on it, (in a sense that it doesn't > apply without it). The imx tree should be fine without the fix, > it's just that the generated doc is messed up for the kontron > boards. Hm, now as you say it I am also wondering a little bit why it slipped into my dependency list. And then, of course, nobody noticed anything (;-p). > I think you don't really need this for your series. > > > > Did I miss something? > > > > Not sure. If you still feel my work is of no help to the community I > > am more than happy to abandon any of it. > > Now knowing why you did it, it's fine; its just the wrong > tree. Yep, now I see it. And my re-base does not even make any sense in this case. I guess, your v3 was and is still just fine for the u-boot-fsl-qoriq/master branch. Let me just cancel this v4 then. I am really sorry and hope I did not disturb anything. > -michael Cheers Marcel
[PATCH v2 1/2] net: brcm: netXtreme driver
From: Bharat Gooty
Broadcom bnxt L2 driver support. Used by the Broadcom
iproc platforms.
Signed-off-by: Bharat Gooty
Reviewed-by: Ramon Fried
Signed-off-by: Roman Bacik
---
Changes in v2:
- rebase and remove DM_PCI dependency from BNXT_ETH
- remove tautology assignment from debug_resp()
drivers/net/Kconfig |1 +
drivers/net/Makefile|1 +
drivers/net/bnxt/Kconfig|6 +
drivers/net/bnxt/Makefile |5 +
drivers/net/bnxt/bnxt.c | 2025 +++
drivers/net/bnxt/bnxt_dbg.h | 537 ++
drivers/net/bnxt/pci_ids.h | 17 +
include/broadcom/bnxt.h | 419
include/broadcom/bnxt_hsi.h | 889 +++
include/broadcom/bnxt_ver.h | 22 +
10 files changed, 3922 insertions(+)
create mode 100644 drivers/net/bnxt/Kconfig
create mode 100644 drivers/net/bnxt/Makefile
create mode 100644 drivers/net/bnxt/bnxt.c
create mode 100644 drivers/net/bnxt/bnxt_dbg.h
create mode 100644 drivers/net/bnxt/pci_ids.h
create mode 100644 include/broadcom/bnxt.h
create mode 100644 include/broadcom/bnxt_hsi.h
create mode 100644 include/broadcom/bnxt_ver.h
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 6c12959f3794..8dc81a3d6cf9 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -1,6 +1,7 @@
source "drivers/net/phy/Kconfig"
source "drivers/net/pfe_eth/Kconfig"
source "drivers/net/fsl-mc/Kconfig"
+source "drivers/net/bnxt/Kconfig"
config ETH
def_bool y
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index e4078d15a99f..1d9fbd6693cc 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -101,3 +101,4 @@ obj-$(CONFIG_HIGMACV300_ETH) += higmacv300.o
obj-$(CONFIG_MDIO_SANDBOX) += mdio_sandbox.o
obj-$(CONFIG_FSL_ENETC) += fsl_enetc.o fsl_enetc_mdio.o
obj-$(CONFIG_FSL_LS_MDIO) += fsl_ls_mdio.o
+obj-$(CONFIG_BNXT_ETH) += bnxt/
diff --git a/drivers/net/bnxt/Kconfig b/drivers/net/bnxt/Kconfig
new file mode 100644
index ..edc319a10625
--- /dev/null
+++ b/drivers/net/bnxt/Kconfig
@@ -0,0 +1,6 @@
+config BNXT_ETH
+ bool "BNXT PCI support"
+ depends on DM_ETH
+ help
+ This driver implements support for bnxt pci controller
+ driver of ethernet class.
diff --git a/drivers/net/bnxt/Makefile b/drivers/net/bnxt/Makefile
new file mode 100644
index ..a9d6ce00d5e0
--- /dev/null
+++ b/drivers/net/bnxt/Makefile
@@ -0,0 +1,5 @@
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright 2019-2021 Broadcom.
+
+# Broadcom nxe Ethernet driver
+obj-y += bnxt.o
diff --git a/drivers/net/bnxt/bnxt.c b/drivers/net/bnxt/bnxt.c
new file mode 100644
index ..144df587f7e4
--- /dev/null
+++ b/drivers/net/bnxt/bnxt.c
@@ -0,0 +1,2025 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2019-2021 Broadcom.
+ */
+
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "bnxt_dbg.h"
+#include "pci_ids.h"
+
+#define bnxt_down_chip(bp) bnxt_hwrm_run(down_chip, bp, 0)
+#define bnxt_bring_chip(bp)bnxt_hwrm_run(bring_chip, bp, 1)
+
+static const char banner[] = DRV_MODULE_DESC " v" UBOOT_MODULE_VER ",";
+static const char fw_ver[] = " FW v";
+
+static int num_cards; /* Number of bnxt devices seen so far */
+
+static void display_banner(struct bnxt *bp)
+{
+ int i;
+
+ printf(banner);
+ printf(fw_ver);
+ printf("%d.%d.", bp->fw_maj, bp->fw_min);
+ printf("%d.%d\n", bp->fw_bld, bp->fw_rsvd);
+ printf("ETH MAC: ");
+ for (i = 0; i < ETH_ALEN; i++) {
+ printf("%02x", bp->mac_set[i]);
+ if (i != (ETH_ALEN - 1))
+ printf(":");
+ }
+
+ printf(", Port(%d), PF(%d)\n", bp->port_idx, bp->ordinal_value);
+}
+
+/* Broadcom ethernet driver PCI APIs. */
+static void bnxt_bring_pci(struct bnxt *bp)
+{
+ u16 cmd_reg = 0;
+
+ pci_read_word16(bp->pdev, PCI_VENDOR_ID, >vendor_id);
+ pci_read_word16(bp->pdev, PCI_DEVICE_ID, >device_id);
+ pci_read_word16(bp->pdev,
+ PCI_SUBSYSTEM_VENDOR_ID,
+ >subsystem_vendor);
+ pci_read_word16(bp->pdev, PCI_SUBSYSTEM_ID, >subsystem_device);
+ pci_read_word16(bp->pdev, PCI_COMMAND, >cmd_reg);
+ pci_read_byte(bp->pdev, PCICFG_ME_REGISTER, >pf_num);
+ pci_read_byte(bp->pdev, PCI_INTERRUPT_LINE, >irq);
+ bp->bar0 = pci_map_bar(bp->pdev, PCI_BASE_ADDRESS_0, PCI_REGION_MEM);
+ bp->bar1 = pci_map_bar(bp->pdev, PCI_BASE_ADDRESS_2, PCI_REGION_MEM);
+ bp->bar2 = pci_map_bar(bp->pdev, PCI_BASE_ADDRESS_4, PCI_REGION_MEM);
+ cmd_reg = bp->cmd_reg | PCI_COMMAND_MEMORY | PCI_COMMAND_MASTER;
+ cmd_reg |= PCI_COMMAND_INTX_DISABLE; /* disable intr */
+ pci_write_word(bp->pdev, PCI_COMMAND, cmd_reg);
+ pci_read_word16(bp->pdev, PCI_COMMAND, _reg);
+ dbg_pci(bp, __func__, cmd_reg);
+}
+
+int
Re: [PATCH v10 3/9] env: Allow U-Boot scripts to be placed in a .env file
Hi all, My 2 cents. As a maintainer for some hobbyist downstream u-boots (tracking mainline) and some out-of-tree u-boots, I do lots of envs scripting. The most common scenario for me is to create an env by combining 2 or more strings. Examples, init_usb, init_sata, init_sata_usb and so on, i.e concatenating "init" with the device name(s). The device names might be some other envs, and so on. Note that I used _ (underscore) and could end up with an env name that has trailing underscore. So I can see the trailing + in env names might occur often in some existing scripts. It's just my preference to use underscore, but someone else might use a + sign! OTOH, It never occurred to me that I can use a backward slash \ in env names. Since we use this escape character in ./include/configs/someboard.h CONFIG_EXTRA_ENV_SETTINGS as a linebreak, I think perhaps nobody would have attempted to make use of that in the env name. So I agree with Tom, we could disallow \ in env name, and use it as a separator during parsing. Such as in the following 2 assignments, the 1st is appending the string bar to foo, the 2nd is assigning the string bar to foo+. foo\+=bar foo+\=bar Thanks, Tony
Re: [PATCH v4 0/5] board: sl28: target refresh
Hi Marcel, Am 2021-10-23 01:09, schrieb Marcel Ziswiler: Sorry, I did not want to upset anybody. I probably should have asked first before doing this. You could have said the below in the cover letter. Then I'd have at least an idea what is going on ;) On Sat, 2021-10-23 at 00:52 +0200, Michael Walle wrote: Hi Marcel, Am 2021-10-23 00:19, schrieb Marcel Ziswiler: > From: Marcel Ziswiler > > > Note that this re-base is only compile tested. Care to explain what this is? Why are you taking my patchset and make a new version of it and rebasing it on the wrong tree? You might have noticed that Stefano has a hard time applying some patch sets due to continuing conflicts. Therefore in trying to further the binman clean-up [1] were I am just about to post a new version as well, I took the liberty to re-fresh all the patches my series bases on which have not seen any care for more than a month. I re-based them on top of Stefano's u-boot-imx/master branch which I am very certain is exactly the tree stuff needs to be re-based to, not? This is a layerscape SoC board whose patches usually go through u-boot-fsl-qoriq. Apart from the one doc fix there should be no dependency on the u-boot-imx tree. I just took Frieder's doc fix because my last patch depends on it, (in a sense that it doesn't apply without it). The imx tree should be fine without the fix, it's just that the generated doc is messed up for the kontron boards. I think you don't really need this for your series. Did I miss something? Not sure. If you still feel my work is of no help to the community I am more than happy to abandon any of it. Now knowing why you did it, it's fine; its just the wrong tree. -michael
[PATCH v2 2/2] cmd: brcm: netXtreme commands
From: Bharat Gooty
Following netXtreme commands are supported:-
Device probe, remove, supported speeds, get/set speeds and
get/set MAC address.
Signed-off-by: Bharat Gooty
Signed-off-by: Roman Bacik
---
(no changes since v1)
cmd/Kconfig | 2 +
cmd/broadcom/Kconfig | 10 ++
cmd/broadcom/Makefile | 3 +-
cmd/broadcom/bnxt.c | 237 ++
4 files changed, 251 insertions(+), 1 deletion(-)
create mode 100644 cmd/broadcom/Kconfig
create mode 100644 cmd/broadcom/bnxt.c
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 5b30b13e438f..e054292dbcd0 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -1953,6 +1953,8 @@ endmenu
source "cmd/ti/Kconfig"
+source "cmd/broadcom/Kconfig"
+
config CMD_BOOTSTAGE
bool "Enable the 'bootstage' command"
depends on BOOTSTAGE
diff --git a/cmd/broadcom/Kconfig b/cmd/broadcom/Kconfig
new file mode 100644
index ..6f16b09d1425
--- /dev/null
+++ b/cmd/broadcom/Kconfig
@@ -0,0 +1,10 @@
+menu "Broadcom specific command line interface"
+
+config BNXT_ETH_CMD
+ bool "BNXT commands"
+ depends on BNXT_ETH
+ help
+ Broadcom NXS ethernet controller commands. Commands supported are:-
+ Driver probe, Driver remove, Supported speeds, get/set MAC address
and get/set Link speeds.
+
+endmenu
diff --git a/cmd/broadcom/Makefile b/cmd/broadcom/Makefile
index 62268d98d0dd..0027c1c15e5a 100644
--- a/cmd/broadcom/Makefile
+++ b/cmd/broadcom/Makefile
@@ -1,6 +1,7 @@
# SPDX-License-Identifier: GPL-2.0+
-# Copyright 2020 Broadcom
+# Copyright 2020-2021 Broadcom
obj-y += chimp_boot.o
obj-y += nitro_image_load.o
obj-y += chimp_handshake.o
+obj-$(CONFIG_BNXT_ETH_CMD) += bnxt.o
diff --git a/cmd/broadcom/bnxt.c b/cmd/broadcom/bnxt.c
new file mode 100644
index ..b9d1e59a74fb
--- /dev/null
+++ b/cmd/broadcom/bnxt.c
@@ -0,0 +1,237 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2021 Broadcom
+ */
+
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static int do_bnxt_set_link(struct bnxt *bp, char *link_str)
+{
+ bp->link_set = simple_strtoul(link_str, NULL, 16);
+
+ switch (bp->link_set) {
+ case LINK_SPEED_DRV_AUTONEG:
+ printf("- AutoNeg Not Supported\n");
+ return 0;
+ case LINK_SPEED_DRV_1G:
+ if (!(bp->support_speeds & PORT_QCFG_SUPPORT_SPEEDS_1GB)) {
+ printf("- 1 GBPS: Link Speed is not supported\n");
+ return 0;
+ }
+
+ break;
+ case LINK_SPEED_DRV_10G:
+ if (!(bp->support_speeds & PORT_QCFG_SUPPORT_SPEEDS_10GB)) {
+ printf("- 10 GBPS: Link Speed is not supported\n");
+ return 0;
+ }
+
+ break;
+ case LINK_SPEED_DRV_25G:
+ if (!(bp->support_speeds & PORT_QCFG_SUPPORT_SPEEDS_25GB)) {
+ printf("- 25 GBPS: Link Speed is not supported\n");
+ return 0;
+ }
+
+ break;
+ case LINK_SPEED_DRV_40G:
+ printf("- 40 GBPS Not Supported\n");
+ return 0;
+ case LINK_SPEED_DRV_50G:
+ if (!(bp->support_speeds & PORT_QCFG_SUPPORT_SPEEDS_50GB)) {
+ printf("- 50 GBPS: Link Speed is not supported\n");
+ return 0;
+ }
+
+ break;
+ case LINK_SPEED_DRV_100G:
+ if (!(bp->support_speeds & PORT_QCFG_SUPPORT_SPEEDS_100GB)) {
+ printf("- 100 GBPS: Link Speed is not supported\n");
+ return 0;
+ }
+
+ break;
+ case LINK_SPEED_DRV_200G:
+ if (!(bp->support_speeds & PORT_QCFG_SUPPORT_SPEEDS_200GB)) {
+ printf("- 200 GBPS: Link Speed is not supported\n");
+ return 0;
+ }
+
+ break;
+ case LINK_SPEED_DRV_2_5G:
+ if (!(bp->support_speeds & PORT_QCFG_SUPPORT_SPEEDS_2_5GB)) {
+ printf("- 2.5 GBPS: Link Speed is not supported\n");
+ return 0;
+ }
+
+ break;
+ case LINK_SPEED_DRV_100M:
+ if (!(bp->support_speeds & PORT_QCFG_SUPPORT_SPEEDS_100MB)) {
+ printf("- 100 MBPS: Link Speed is not supported\n");
+ return 0;
+ }
+
+ break;
+ default:
+ printf("- Invalid Link Speed specified\n");
+ return CMD_RET_USAGE;
+ }
+
+ prn_link_speed(bp->link_set, 1);
+
+ return bnxt_set_link_speed(bp);
+}
+
+static int do_bnxt_set_mac(struct bnxt *bp, char *mac_str)
+{
+ struct eth_pdata *plat = dev_get_plat(bp->pdev);
+
[PATCH v2 2/2] cmd: brcm: netXtreme commands
From: Bharat Gooty
Following netXtreme commands are supported:-
Device probe, remove, supported speeds, get/set speeds and
get/set MAC address.
Signed-off-by: Bharat Gooty
Signed-off-by: Roman Bacik
---
(no changes since v1)
cmd/Kconfig | 2 +
cmd/broadcom/Kconfig | 10 ++
cmd/broadcom/Makefile | 3 +-
cmd/broadcom/bnxt.c | 237 ++
4 files changed, 251 insertions(+), 1 deletion(-)
create mode 100644 cmd/broadcom/Kconfig
create mode 100644 cmd/broadcom/bnxt.c
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 5b30b13e438f..e054292dbcd0 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -1953,6 +1953,8 @@ endmenu
source "cmd/ti/Kconfig"
+source "cmd/broadcom/Kconfig"
+
config CMD_BOOTSTAGE
bool "Enable the 'bootstage' command"
depends on BOOTSTAGE
diff --git a/cmd/broadcom/Kconfig b/cmd/broadcom/Kconfig
new file mode 100644
index ..6f16b09d1425
--- /dev/null
+++ b/cmd/broadcom/Kconfig
@@ -0,0 +1,10 @@
+menu "Broadcom specific command line interface"
+
+config BNXT_ETH_CMD
+ bool "BNXT commands"
+ depends on BNXT_ETH
+ help
+ Broadcom NXS ethernet controller commands. Commands supported are:-
+ Driver probe, Driver remove, Supported speeds, get/set MAC address
and get/set Link speeds.
+
+endmenu
diff --git a/cmd/broadcom/Makefile b/cmd/broadcom/Makefile
index 62268d98d0dd..0027c1c15e5a 100644
--- a/cmd/broadcom/Makefile
+++ b/cmd/broadcom/Makefile
@@ -1,6 +1,7 @@
# SPDX-License-Identifier: GPL-2.0+
-# Copyright 2020 Broadcom
+# Copyright 2020-2021 Broadcom
obj-y += chimp_boot.o
obj-y += nitro_image_load.o
obj-y += chimp_handshake.o
+obj-$(CONFIG_BNXT_ETH_CMD) += bnxt.o
diff --git a/cmd/broadcom/bnxt.c b/cmd/broadcom/bnxt.c
new file mode 100644
index ..b9d1e59a74fb
--- /dev/null
+++ b/cmd/broadcom/bnxt.c
@@ -0,0 +1,237 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2021 Broadcom
+ */
+
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static int do_bnxt_set_link(struct bnxt *bp, char *link_str)
+{
+ bp->link_set = simple_strtoul(link_str, NULL, 16);
+
+ switch (bp->link_set) {
+ case LINK_SPEED_DRV_AUTONEG:
+ printf("- AutoNeg Not Supported\n");
+ return 0;
+ case LINK_SPEED_DRV_1G:
+ if (!(bp->support_speeds & PORT_QCFG_SUPPORT_SPEEDS_1GB)) {
+ printf("- 1 GBPS: Link Speed is not supported\n");
+ return 0;
+ }
+
+ break;
+ case LINK_SPEED_DRV_10G:
+ if (!(bp->support_speeds & PORT_QCFG_SUPPORT_SPEEDS_10GB)) {
+ printf("- 10 GBPS: Link Speed is not supported\n");
+ return 0;
+ }
+
+ break;
+ case LINK_SPEED_DRV_25G:
+ if (!(bp->support_speeds & PORT_QCFG_SUPPORT_SPEEDS_25GB)) {
+ printf("- 25 GBPS: Link Speed is not supported\n");
+ return 0;
+ }
+
+ break;
+ case LINK_SPEED_DRV_40G:
+ printf("- 40 GBPS Not Supported\n");
+ return 0;
+ case LINK_SPEED_DRV_50G:
+ if (!(bp->support_speeds & PORT_QCFG_SUPPORT_SPEEDS_50GB)) {
+ printf("- 50 GBPS: Link Speed is not supported\n");
+ return 0;
+ }
+
+ break;
+ case LINK_SPEED_DRV_100G:
+ if (!(bp->support_speeds & PORT_QCFG_SUPPORT_SPEEDS_100GB)) {
+ printf("- 100 GBPS: Link Speed is not supported\n");
+ return 0;
+ }
+
+ break;
+ case LINK_SPEED_DRV_200G:
+ if (!(bp->support_speeds & PORT_QCFG_SUPPORT_SPEEDS_200GB)) {
+ printf("- 200 GBPS: Link Speed is not supported\n");
+ return 0;
+ }
+
+ break;
+ case LINK_SPEED_DRV_2_5G:
+ if (!(bp->support_speeds & PORT_QCFG_SUPPORT_SPEEDS_2_5GB)) {
+ printf("- 2.5 GBPS: Link Speed is not supported\n");
+ return 0;
+ }
+
+ break;
+ case LINK_SPEED_DRV_100M:
+ if (!(bp->support_speeds & PORT_QCFG_SUPPORT_SPEEDS_100MB)) {
+ printf("- 100 MBPS: Link Speed is not supported\n");
+ return 0;
+ }
+
+ break;
+ default:
+ printf("- Invalid Link Speed specified\n");
+ return CMD_RET_USAGE;
+ }
+
+ prn_link_speed(bp->link_set, 1);
+
+ return bnxt_set_link_speed(bp);
+}
+
+static int do_bnxt_set_mac(struct bnxt *bp, char *mac_str)
+{
+ struct eth_pdata *plat = dev_get_plat(bp->pdev);
+
[PATCH v3 7/7] arm64: dts: imx8mm-u-boot.dtsi: improve odd blob-ext naming
From: Marcel Ziswiler
Rather than using odd implicit blob-ext naming, explicitly specify the
type to be of blob-ext and therefore also simplify the node naming.
Signed-off-by: Marcel Ziswiler
Reviewed-by: Peng Fan
---
(no changes since v2)
Changes in v2:
- Rather than doing that clean-up to the separate binman dtsi now do it
to the common u-boot dtsi one.
Changes in v1:
- This was suggested by Simon on my earlier patch set upon which we
decided to first break this up into a common binman dtsi and then
subsequently do such further improvements.
arch/arm/dts/imx8mm-u-boot.dtsi | 27 ++-
1 file changed, 18 insertions(+), 9 deletions(-)
diff --git a/arch/arm/dts/imx8mm-u-boot.dtsi b/arch/arm/dts/imx8mm-u-boot.dtsi
index 8feb0f2592a..7882fe73167 100644
--- a/arch/arm/dts/imx8mm-u-boot.dtsi
+++ b/arch/arm/dts/imx8mm-u-boot.dtsi
@@ -39,24 +39,28 @@
filename = "u-boot-spl.bin";
};
- blob_1: blob-ext@1 {
+ 1d-imem {
filename = "lpddr4_pmu_train_1d_imem.bin";
size = <0x8000>;
+ type = "blob-ext";
};
- blob_2: blob-ext@2 {
+ 1d_dmem {
filename = "lpddr4_pmu_train_1d_dmem.bin";
size = <0x4000>;
+ type = "blob-ext";
};
- blob_3: blob-ext@3 {
+ 2d_imem {
filename = "lpddr4_pmu_train_2d_imem.bin";
size = <0x8000>;
+ type = "blob-ext";
};
- blob_4: blob-ext@4 {
+ 2d_dmem {
filename = "lpddr4_pmu_train_2d_dmem.bin";
size = <0x4000>;
+ type = "blob-ext";
};
};
@@ -89,8 +93,9 @@
load = ;
type = "standalone";
- uboot_blob: blob-ext {
+ uboot_blob {
filename = "u-boot-nodtb.bin";
+ type = "blob-ext";
};
};
@@ -102,8 +107,9 @@
load = <0x92>;
type = "firmware";
- atf_blob: blob-ext {
+ atf_blob {
filename = "bl31.bin";
+ type = "blob-ext";
};
};
@@ -120,8 +126,9 @@
description = "NAME";
type = "flat_dt";
- uboot_fdt_blob: blob-ext {
+ uboot_fdt_blob {
filename = "u-boot.dtb";
+ type = "blob-ext";
};
};
};
@@ -143,14 +150,16 @@
filename = "flash.bin";
pad-byte = <0x00>;
- spl: blob-ext@1 {
+ spl {
filename = "spl.bin";
offset = <0x0>;
+ type = "blob-ext";
};
- binman_uboot: blob-ext@2 {
+ binman_uboot: uboot {
filename = "u-boot.itb";
offset = <0x57c00>;
+ type = "blob-ext";
};
};
};
--
2.26.2
[PATCH v3 4/7] arm64: dts: imx8mm: use common binman configuration
From: Marcel Ziswiler
With the move to using binman to generate SPL aka u-boot-spl-ddr.bin and
U-Boot proper aka u-boot.itb every board now covers such configuration
in its own U-Boot specific device tree include. Move the comon part of
that configuration to the common imx8mm-u-boot.dtsi include file.
Signed-off-by: Marcel Ziswiler
Reviewed-by: Peng Fan
---
Changes in v3:
- Integrated imx8mm_beacon as well.
- Re-based on top of imx/master.
Changes in v2:
- Morph common binman dtsi into regular common u-boot dtsi as discussed
on mailing list.
- Re-based.
arch/arm/dts/imx8mm-beacon-kit-u-boot.dtsi| 122
.../dts/imx8mm-cl-iot-gate-optee-u-boot.dtsi | 124 ++--
arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi | 105 --
arch/arm/dts/imx8mm-evk-u-boot.dtsi | 123
arch/arm/dts/imx8mm-u-boot.dtsi | 133 ++
arch/arm/dts/imx8mm-venice-u-boot.dtsi| 119
arch/arm/dts/imx8mm-verdin-u-boot.dtsi| 122 +---
7 files changed, 147 insertions(+), 701 deletions(-)
diff --git a/arch/arm/dts/imx8mm-beacon-kit-u-boot.dtsi
b/arch/arm/dts/imx8mm-beacon-kit-u-boot.dtsi
index 3c034a85e35..73ddfdade6a 100644
--- a/arch/arm/dts/imx8mm-beacon-kit-u-boot.dtsi
+++ b/arch/arm/dts/imx8mm-beacon-kit-u-boot.dtsi
@@ -6,10 +6,6 @@
#include "imx8mm-u-boot.dtsi"
/ {
- binman: binman {
- multiple-images;
- };
-
wdt-reboot {
compatible = "wdt-reboot";
wdt = <>;
@@ -104,121 +100,3 @@
{
u-boot,dm-spl;
};
-
- {
-u-boot-spl-ddr {
- filename = "u-boot-spl-ddr.bin";
- pad-byte = <0xff>;
- align-size = <4>;
- align = <4>;
-
- u-boot-spl {
- align-end = <4>;
- };
-
- blob_1: blob-ext@1 {
- filename = "lpddr4_pmu_train_1d_imem.bin";
- size = <0x8000>;
- };
-
- blob_2: blob-ext@2 {
- filename = "lpddr4_pmu_train_1d_dmem.bin";
- size = <0x4000>;
- };
-
- blob_3: blob-ext@3 {
- filename = "lpddr4_pmu_train_2d_imem.bin";
- size = <0x8000>;
- };
-
- blob_4: blob-ext@4 {
- filename = "lpddr4_pmu_train_2d_dmem.bin";
- size = <0x4000>;
- };
- };
-
- spl {
- filename = "spl.bin";
-
- mkimage {
- args = "-n spl/u-boot-spl.cfgout -T imx8mimage -e
0x7e1000";
-
- blob {
- filename = "u-boot-spl-ddr.bin";
- };
- };
- };
-
- itb {
- filename = "u-boot.itb";
-
- fit {
- description = "Configuration to load ATF before U-Boot";
- #address-cells = <1>;
- fit,external-offset = ;
-
- images {
- uboot {
- description = "U-Boot (64-bit)";
- type = "standalone";
- arch = "arm64";
- compression = "none";
- load = ;
-
- uboot_blob: blob-ext {
- filename = "u-boot-nodtb.bin";
- };
- };
-
- atf {
- description = "ARM Trusted Firmware";
- type = "firmware";
- arch = "arm64";
- compression = "none";
- load = <0x92>;
- entry = <0x92>;
-
- atf_blob: blob-ext {
- filename = "bl31.bin";
- };
- };
-
- fdt {
- description = "NAME";
- type = "flat_dt";
- compression = "none";
-
- uboot_fdt_blob: blob-ext {
- filename = "u-boot.dtb";
- };
- };
- };
-
- configurations {
- default = "conf";
-
- conf {
-
[PATCH v3 6/7] arm64: dts: imx8mm-u-boot.dtsi: explicitly add spl filename
From: Marcel Ziswiler
Explicitly add SPL aka u-boot-spl.bin filename.
Signed-off-by: Marcel Ziswiler
Reviewed-by: Peng Fan
---
(no changes since v2)
Changes in v2:
- Rather than doing that clean-up to the separate binman dtsi now do it
to the common u-boot dtsi one.
arch/arm/dts/imx8mm-u-boot.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/dts/imx8mm-u-boot.dtsi b/arch/arm/dts/imx8mm-u-boot.dtsi
index 770282d2b98..8feb0f2592a 100644
--- a/arch/arm/dts/imx8mm-u-boot.dtsi
+++ b/arch/arm/dts/imx8mm-u-boot.dtsi
@@ -36,6 +36,7 @@
u-boot-spl {
align-end = <4>;
+ filename = "u-boot-spl.bin";
};
blob_1: blob-ext@1 {
--
2.26.2
[PATCH v3 5/7] arm64: dts: imx8mm-u-boot.dtsi: alphabetically re-order properties
From: Marcel Ziswiler
Alphabetically re-order properties.
Signed-off-by: Marcel Ziswiler
Reviewed-by: Peng Fan
---
(no changes since v2)
Changes in v2:
- Rather than doing that clean-up to the separate binman dtsi now do it
to the common u-boot dtsi one.
arch/arm/dts/imx8mm-u-boot.dtsi | 34 -
1 file changed, 17 insertions(+), 17 deletions(-)
diff --git a/arch/arm/dts/imx8mm-u-boot.dtsi b/arch/arm/dts/imx8mm-u-boot.dtsi
index 5020255fa0f..770282d2b98 100644
--- a/arch/arm/dts/imx8mm-u-boot.dtsi
+++ b/arch/arm/dts/imx8mm-u-boot.dtsi
@@ -15,8 +15,8 @@
};
{
- u-boot,dm-spl;
u-boot,dm-pre-reloc;
+ u-boot,dm-spl;
};
{
@@ -29,10 +29,10 @@
{
u-boot-spl-ddr {
+ align = <4>;
+ align-size = <4>;
filename = "u-boot-spl-ddr.bin";
pad-byte = <0xff>;
- align-size = <4>;
- align = <4>;
u-boot-spl {
align-end = <4>;
@@ -76,17 +76,17 @@
fit {
description = "Configuration to load ATF before U-Boot";
- #address-cells = <1>;
fit,external-offset = ;
fit,fdt-list = "of-list";
+ #address-cells = <1>;
images {
uboot {
- description = "U-Boot (64-bit)";
- type = "standalone";
arch = "arm64";
compression = "none";
+ description = "U-Boot (64-bit)";
load = ;
+ type = "standalone";
uboot_blob: blob-ext {
filename = "u-boot-nodtb.bin";
@@ -94,12 +94,12 @@
};
atf {
- description = "ARM Trusted Firmware";
- type = "firmware";
arch = "arm64";
compression = "none";
- load = <0x92>;
+ description = "ARM Trusted Firmware";
entry = <0x92>;
+ load = <0x92>;
+ type = "firmware";
atf_blob: blob-ext {
filename = "bl31.bin";
@@ -107,17 +107,17 @@
};
binman_fip: fip {
- description = "Trusted Firmware FIP";
- type = "firmware";
arch = "arm64";
compression = "none";
+ description = "Trusted Firmware FIP";
load = <0x4031>;
+ type = "firmware";
};
@fdt-SEQ {
+ compression = "none";
description = "NAME";
type = "flat_dt";
- compression = "none";
uboot_fdt_blob: blob-ext {
filename = "u-boot.dtb";
@@ -130,9 +130,9 @@
binman_configuration: @config-SEQ {
description = "NAME";
+ fdt = "fdt-SEQ";
firmware = "uboot";
loadables = "atf";
- fdt = "fdt-SEQ";
};
};
};
@@ -143,20 +143,20 @@
pad-byte = <0x00>;
spl: blob-ext@1 {
- offset = <0x0>;
filename = "spl.bin";
+ offset = <0x0>;
};
binman_uboot: blob-ext@2 {
- offset = <0x57c00>;
filename = "u-boot.itb";
+ offset = <0x57c00>;
};
};
};
{
- u-boot,dm-spl;
u-boot,dm-pre-reloc;
+ u-boot,dm-spl;
/delete-property/ assigned-clocks;
/delete-property/ assigned-clock-parents;
/delete-property/ assigned-clock-rates;
@@ -167,6 +167,6 @@
};
_24m
[PATCH v3 3/7] arm64: dts: imx8mm-cl-iot-gate-u-boot.dtsi: use common imx8mm-u-boot.dtsi
From: Marcel Ziswiler
Use common imx8mm-u-boot.dtsi.
Signed-off-by: Marcel Ziswiler
Reviewed-by: Peng Fan
---
(no changes since v2)
Changes in v2:
- New patch preparing cl-iot-gate.
.../dts/imx8mm-cl-iot-gate-optee-u-boot.dtsi | 37 +--
arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi | 37 +--
2 files changed, 4 insertions(+), 70 deletions(-)
diff --git a/arch/arm/dts/imx8mm-cl-iot-gate-optee-u-boot.dtsi
b/arch/arm/dts/imx8mm-cl-iot-gate-optee-u-boot.dtsi
index 67ce70d0bdf..bc8a138e6c0 100644
--- a/arch/arm/dts/imx8mm-cl-iot-gate-optee-u-boot.dtsi
+++ b/arch/arm/dts/imx8mm-cl-iot-gate-optee-u-boot.dtsi
@@ -3,6 +3,8 @@
* Copyright 2019 NXP
*/
+#include "imx8mm-u-boot.dtsi"
+
/ {
binman: binman {
multiple-images;
@@ -22,11 +24,6 @@
};
};
-&{/soc@0} {
- u-boot,dm-pre-reloc;
- u-boot,dm-spl;
-};
-
&{/soc@0/bus@3080/i2c@30a3/pmic@4b} {
u-boot,dm-spl;
};
@@ -35,19 +32,6 @@
u-boot,dm-spl;
};
- {
- u-boot,dm-spl;
- u-boot,dm-pre-reloc;
-};
-
- {
- u-boot,dm-spl;
-};
-
- {
- u-boot,dm-spl;
-};
-
{
u-boot-spl-ddr {
filename = "u-boot-spl-ddr.bin";
@@ -161,14 +145,6 @@
};
};
- {
- u-boot,dm-spl;
- u-boot,dm-pre-reloc;
- /delete-property/ assigned-clocks;
- /delete-property/ assigned-clock-parents;
- /delete-property/ assigned-clock-rates;
-};
-
{
phy-reset-gpios = < 22 GPIO_ACTIVE_LOW>;
};
@@ -201,15 +177,6 @@
u-boot,dm-spl;
};
- {
- u-boot,dm-spl;
-};
-
-_24m {
- u-boot,dm-spl;
- u-boot,dm-pre-reloc;
-};
-
_i2c2 {
u-boot,dm-spl;
};
diff --git a/arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi
b/arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi
index fe45a35d751..cf3cc191d5a 100644
--- a/arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi
+++ b/arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi
@@ -3,6 +3,8 @@
* Copyright 2019 NXP
*/
+#include "imx8mm-u-boot.dtsi"
+
/ {
binman: binman {
multiple-images;
@@ -22,11 +24,6 @@
};
};
-&{/soc@0} {
- u-boot,dm-pre-reloc;
- u-boot,dm-spl;
-};
-
&{/soc@0/bus@3080/i2c@30a3/pmic@4b} {
u-boot,dm-spl;
};
@@ -35,19 +32,6 @@
u-boot,dm-spl;
};
- {
- u-boot,dm-spl;
- u-boot,dm-pre-reloc;
-};
-
- {
- u-boot,dm-spl;
-};
-
- {
- u-boot,dm-spl;
-};
-
{
u-boot-spl-ddr {
filename = "u-boot-spl-ddr.bin";
@@ -149,14 +133,6 @@
};
};
- {
- u-boot,dm-spl;
- u-boot,dm-pre-reloc;
- /delete-property/ assigned-clocks;
- /delete-property/ assigned-clock-parents;
- /delete-property/ assigned-clock-rates;
-};
-
{
phy-reset-gpios = < 22 GPIO_ACTIVE_LOW>;
};
@@ -189,15 +165,6 @@
u-boot,dm-spl;
};
- {
- u-boot,dm-spl;
-};
-
-_24m {
- u-boot,dm-spl;
- u-boot,dm-pre-reloc;
-};
-
_i2c2 {
u-boot,dm-spl;
};
--
2.26.2
[PATCH v3 2/7] arm64: dts: imx8mm-cl-iot-gate-u-boot.dtsi: alphabetically re-order
From: Marcel Ziswiler
Alphabetically re-order nodes and properties.
Signed-off-by: Marcel Ziswiler
Reviewed-by: Peng Fan
---
(no changes since v2)
Changes in v2:
- New patch preparing cl-iot-gate.
.../dts/imx8mm-cl-iot-gate-optee-u-boot.dtsi | 202 +-
arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi | 202 +-
2 files changed, 202 insertions(+), 202 deletions(-)
diff --git a/arch/arm/dts/imx8mm-cl-iot-gate-optee-u-boot.dtsi
b/arch/arm/dts/imx8mm-cl-iot-gate-optee-u-boot.dtsi
index 12065935e49..67ce70d0bdf 100644
--- a/arch/arm/dts/imx8mm-cl-iot-gate-optee-u-boot.dtsi
+++ b/arch/arm/dts/imx8mm-cl-iot-gate-optee-u-boot.dtsi
@@ -8,18 +8,18 @@
multiple-images;
};
- wdt-reboot {
- compatible = "wdt-reboot";
- wdt = <>;
- u-boot,dm-spl;
- };
-
firmware {
optee {
compatible = "linaro,optee-tz";
method = "smc";
};
};
+
+ wdt-reboot {
+ compatible = "wdt-reboot";
+ u-boot,dm-spl;
+ wdt = <>;
+ };
};
&{/soc@0} {
@@ -27,17 +27,12 @@
u-boot,dm-spl;
};
- {
+&{/soc@0/bus@3080/i2c@30a3/pmic@4b} {
u-boot,dm-spl;
- u-boot,dm-pre-reloc;
- /delete-property/ assigned-clocks;
- /delete-property/ assigned-clock-parents;
- /delete-property/ assigned-clock-rates;
};
-_24m {
+&{/soc@0/bus@3080/i2c@30a3/pmic@4b/regulators} {
u-boot,dm-spl;
- u-boot,dm-pre-reloc;
};
{
@@ -53,94 +48,6 @@
u-boot,dm-spl;
};
- {
- u-boot,dm-spl;
-};
-
-_uart3 {
- u-boot,dm-spl;
-};
-
-_usdhc2_gpio {
- u-boot,dm-spl;
-};
-
-_usdhc2 {
- u-boot,dm-spl;
-};
-
-_usdhc3 {
- 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;
-};
-
-&{/soc@0/bus@3080/i2c@30a3/pmic@4b} {
- u-boot,dm-spl;
-};
-
-&{/soc@0/bus@3080/i2c@30a3/pmic@4b/regulators} {
- u-boot,dm-spl;
-};
-
-_i2c2 {
- u-boot,dm-spl;
-};
-
-_pmic {
- u-boot,dm-spl;
-};
-
- {
- phy-reset-gpios = < 22 GPIO_ACTIVE_LOW>;
-};
-
- {
- u-boot,dm-spl;
-};
-
{
u-boot-spl-ddr {
filename = "u-boot-spl-ddr.bin";
@@ -253,3 +160,96 @@
};
};
};
+
+ {
+ u-boot,dm-spl;
+ u-boot,dm-pre-reloc;
+ /delete-property/ assigned-clocks;
+ /delete-property/ assigned-clock-parents;
+ /delete-property/ assigned-clock-rates;
+};
+
+ {
+ phy-reset-gpios = < 22 GPIO_ACTIVE_LOW>;
+};
+
+ {
+ 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;
+};
+
+_24m {
+ u-boot,dm-spl;
+ u-boot,dm-pre-reloc;
+};
+
+_i2c2 {
+ u-boot,dm-spl;
+};
+
+_pmic {
+ u-boot,dm-spl;
+};
+
+_uart3 {
+ u-boot,dm-spl;
+};
+
+_usdhc2 {
+ u-boot,dm-spl;
+};
+
+_usdhc2_gpio {
+ u-boot,dm-spl;
+};
+
+_usdhc3 {
+ 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/imx8mm-cl-iot-gate-u-boot.dtsi
b/arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi
index 00927c15744..fe45a35d751 100644
--- a/arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi
+++ b/arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi
@@ -8,18 +8,18 @@
multiple-images;
};
- wdt-reboot {
- compatible = "wdt-reboot";
- wdt = <>;
- u-boot,dm-spl;
- };
-
firmware {
optee {
compatible = "linaro,optee-tz";
method = "smc";
};
};
+
+ wdt-reboot {
+ compatible = "wdt-reboot";
+ u-boot,dm-spl;
+ wdt = <>;
+ };
};
&{/soc@0} {
@@ -27,17 +27,12 @@
u-boot,dm-spl;
};
- {
+&{/soc@0/bus@3080/i2c@30a3/pmic@4b} {
u-boot,dm-spl;
- u-boot,dm-pre-reloc;
- /delete-property/ assigned-clocks;
- /delete-property/ assigned-clock-parents;
- /delete-property/ assigned-clock-rates;
};
-_24m {
+&{/soc@0/bus@3080/i2c@30a3/pmic@4b/regulators} {
u-boot,dm-spl;
- u-boot,dm-pre-reloc;
};
{
@@ -53,94 +48,6 @@
u-boot,dm-spl;
};
- {
- u-boot,dm-spl;
-};
-
-_uart3 {
- u-boot,dm-spl;
-};
-
[PATCH v3 0/7] arm64: dts: imx8mm: use common binman configuration and further clean-up
From: Marcel Ziswiler With the move to using binman to generate SPL aka u-boot-spl-ddr.bin and U-Boot proper aka u-boot.itb every board now covers such configuration in its own U-Boot specific device tree include. Move the comon part of that configuration to the common imx8mm-u-boot.dtsi include file. The initial patch fixes an issue with intermediate binary naming for the imx8mm-cl-iot-gate. And subsequent patches further clean up that dtsi. This series is based on my refresh of Adam's imx8mm_beacon switch to binman patch [1], my refresh of Michael's sl28 patches [2] and Tim's switching imx8mm_venice to using binman to pack images [3]. [1] https://marc.info/?l=u-boot=163493902915471 [2] https://marc.info/?l=u-boot=163494122816224 [3] https://marc.info/?l=u-boot=163355140309636 Changes in v3: - Integrated imx8mm_beacon as well. - Re-based on top of imx/master. Changes in v2: - New patch preparing cl-iot-gate. - New patch preparing cl-iot-gate. - Morph common binman dtsi into regular common u-boot dtsi as discussed on mailing list. - Re-based. - Rather than doing that clean-up to the separate binman dtsi now do it to the common u-boot dtsi one. - Rather than doing that clean-up to the separate binman dtsi now do it to the common u-boot dtsi one. - Rather than doing that clean-up to the separate binman dtsi now do it to the common u-boot dtsi one. Changes in v1: - This was suggested by Simon on my earlier patch set upon which we decided to first break this up into a common binman dtsi and then subsequently do such further improvements. Marcel Ziswiler (7): imx8mm-cl-iot-gate: fix imximage intermediate binary naming arm64: dts: imx8mm-cl-iot-gate-u-boot.dtsi: alphabetically re-order arm64: dts: imx8mm-cl-iot-gate-u-boot.dtsi: use common imx8mm-u-boot.dtsi arm64: dts: imx8mm: use common binman configuration arm64: dts: imx8mm-u-boot.dtsi: alphabetically re-order properties arm64: dts: imx8mm-u-boot.dtsi: explicitly add spl filename arm64: dts: imx8mm-u-boot.dtsi: improve odd blob-ext naming arch/arm/dts/imx8mm-beacon-kit-u-boot.dtsi| 122 -- .../dts/imx8mm-cl-iot-gate-optee-u-boot.dtsi | 209 -- arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi | 188 +++- arch/arm/dts/imx8mm-evk-u-boot.dtsi | 123 --- arch/arm/dts/imx8mm-u-boot.dtsi | 149 - arch/arm/dts/imx8mm-venice-u-boot.dtsi| 119 -- arch/arm/dts/imx8mm-verdin-u-boot.dtsi| 122 +- .../imximage-8mm-lpddr4.cfg | 2 +- 8 files changed, 212 insertions(+), 822 deletions(-) -- 2.26.2
[PATCH v3 1/7] imx8mm-cl-iot-gate: fix imximage intermediate binary naming
From: Marcel Ziswiler This fixes the following build time issue: ... BINMAN all binman: Error 1 running 'mkimage -d ./mkimage.spl.mkimage -n spl/u-boot-spl.cfgout -T imx8mimage -e 0x7e1000 ./mkimage-out.spl.mkimage': mkimage.flash.mkimage: Can't open: No such file or directory make: *** [Makefile:1094: all] Error 1 Signed-off-by: Marcel Ziswiler Reviewed-by: Peng Fan --- (no changes since v1) board/compulab/imx8mm-cl-iot-gate/imximage-8mm-lpddr4.cfg | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/board/compulab/imx8mm-cl-iot-gate/imximage-8mm-lpddr4.cfg b/board/compulab/imx8mm-cl-iot-gate/imximage-8mm-lpddr4.cfg index b89092a5590..4071219fbf4 100644 --- a/board/compulab/imx8mm-cl-iot-gate/imximage-8mm-lpddr4.cfg +++ b/board/compulab/imx8mm-cl-iot-gate/imximage-8mm-lpddr4.cfg @@ -6,4 +6,4 @@ #define __ASSEMBLY__ BOOT_FROM sd -LOADER mkimage.flash.mkimage 0x7E1000 +LOADER u-boot-spl-ddr.bin 0x7e1000 -- 2.26.2
Re: [PATCH v4 0/5] board: sl28: target refresh
Hi Michael Sorry, I did not want to upset anybody. I probably should have asked first before doing this. On Sat, 2021-10-23 at 00:52 +0200, Michael Walle wrote: > Hi Marcel, > > Am 2021-10-23 00:19, schrieb Marcel Ziswiler: > > From: Marcel Ziswiler > > > > > > Note that this re-base is only compile tested. > > Care to explain what this is? Why are you taking my patchset > and make a new version of it and rebasing it on the wrong > tree? You might have noticed that Stefano has a hard time applying some patch sets due to continuing conflicts. Therefore in trying to further the binman clean-up [1] were I am just about to post a new version as well, I took the liberty to re-fresh all the patches my series bases on which have not seen any care for more than a month. I re-based them on top of Stefano's u-boot-imx/master branch which I am very certain is exactly the tree stuff needs to be re-based to, not? > Did I miss something? Not sure. If you still feel my work is of no help to the community I am more than happy to abandon any of it. [1] https://marc.info/?l=u-boot=163372696806292 > -michael Cheers Marcel
[PATCH] patman: Add "postfix" support to patch subjects
In some communities, it may be necessary to append something after PATCH
in the subject line. For example, the Linux networking subsystem
expects [1] patch subject prefixes like [RFC PATCH net-next 0/99]. This
adds support for such "postfix"s to patman. Although entirely cosmetic,
it is still nice to have.
[1]
https://www.kernel.org/doc/html/latest/networking/netdev-FAQ.html#how-do-i-indicate-which-tree-net-vs-net-next-my-patch-should-be-in
Signed-off-by: Sean Anderson
---
tools/patman/README | 5 +
tools/patman/func_test.py| 6 --
tools/patman/patchstream.py | 2 ++
tools/patman/series.py | 9 +++--
tools/patman/test/test01.txt | 1 +
5 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/tools/patman/README b/tools/patman/README
index 53f55ce95d..e3466e6085 100644
--- a/tools/patman/README
+++ b/tools/patman/README
@@ -188,6 +188,11 @@ Series-prefix: prefix
well. If your format.subjectprefix is set to InternalProject, then
the patch shows like: [InternalProject][RFC/RESEND PATCH]
+Series-postfix: postfix
+ Sets the subject "postfix". Normally empty, but can be the name of a
+ tree such as net or net-next if that needs to be specified. The patch
+ subject is like [PATCH net] or [PATCH net-next].
+
Series-name: name
Sets the name of the series. You don't need to have a name, and
patman does not yet use it, but it is convenient to put the branch
diff --git a/tools/patman/func_test.py b/tools/patman/func_test.py
index 2493e527f5..9f4e03e882 100644
--- a/tools/patman/func_test.py
+++ b/tools/patman/func_test.py
@@ -122,6 +122,7 @@ class TestFunctional(unittest.TestCase):
Series-to: u-boot
Series-prefix: RFC
+Series-postfix: some-branch
Series-cc: Stefan Brüns
Cover-letter-cc: Lord Mëlchett
Series-version: 3
@@ -176,7 +177,7 @@ class TestFunctional(unittest.TestCase):
- each patch has the correct subject
- dry-run information prints out correctly
- unicode is handled correctly
-- Series-to, Series-cc, Series-prefix, Cover-letter
+- Series-to, Series-cc, Series-prefix, Series-postfix, Cover-letter
- Cover-letter-cc, Series-version, Series-changes, Series-notes
- Commit-notes
"""
@@ -235,6 +236,7 @@ class TestFunctional(unittest.TestCase):
self.assertEqual('Cc:%s' % stefan, next(lines))
self.assertEqual('Version: 3', next(lines))
self.assertEqual('Prefix:\t RFC', next(lines))
+self.assertEqual('Postfix:\t some-branch', next(lines))
self.assertEqual('Cover: 4 lines', next(lines))
self.assertEqual(' Cc: %s' % self.fred, next(lines))
self.assertEqual(' Cc: %s' % self.leb,
@@ -285,7 +287,7 @@ Simon Glass (2):
'''
lines = open(cover_fname, encoding='utf-8').read().splitlines()
self.assertEqual(
-'Subject: [RFC PATCH v3 0/2] test: A test patch series',
+'Subject: [RFC PATCH some-branch v3 0/2] test: A test patch
series',
lines[3])
self.assertEqual(expected.splitlines(), lines[7:])
diff --git a/tools/patman/patchstream.py b/tools/patman/patchstream.py
index 2439fb18e4..1da9d53b65 100644
--- a/tools/patman/patchstream.py
+++ b/tools/patman/patchstream.py
@@ -596,6 +596,8 @@ class PatchStream:
# These seem like they would be nice to include.
if 'prefix' in self.series:
parts.append(self.series['prefix'])
+if 'postfix' in self.series:
+parts.append(self.serties['postfix'])
if 'version' in self.series:
parts.append("v%s" % self.series['version'])
diff --git a/tools/patman/series.py b/tools/patman/series.py
index 8ae218d3a4..da734d92cf 100644
--- a/tools/patman/series.py
+++ b/tools/patman/series.py
@@ -16,7 +16,7 @@ from patman import tools
# Series-xxx tags that we understand
valid_series = ['to', 'cc', 'version', 'changes', 'prefix', 'notes', 'name',
-'cover_cc', 'process_log', 'links', 'patchwork_url']
+'cover_cc', 'process_log', 'links', 'patchwork_url', 'postfix']
class Series(dict):
"""Holds information about a patch series, including all tags.
@@ -133,6 +133,7 @@ class Series(dict):
print('Cc:\t ', item)
print('Version: ', self.get('version'))
print('Prefix:\t ', self.get('prefix'))
+print('Postfix:\t ', self.get('postfix'))
if self.cover:
print('Cover: %d lines' % len(self.cover))
cover_cc = gitutil.BuildEmailList(self.get('cover_cc', ''))
@@ -322,4 +323,8 @@ class Series(dict):
prefix = ''
if self.get('prefix'):
prefix = '%s ' % self['prefix']
-return '%s%sPATCH%s' % (git_prefix, prefix, version)
+
+postfix = ''
+if self.get('postfix'):
+
Re: [PATCH v4 0/5] board: sl28: target refresh
Hi Marcel, Am 2021-10-23 00:19, schrieb Marcel Ziswiler: From: Marcel Ziswiler Note that this re-base is only compile tested. Care to explain what this is? Why are you taking my patchset and make a new version of it and rebasing it on the wrong tree? Did I miss something? -michael
Re: [PATCH] dfu: dfu_sf: Read the SPI flash in 16 MiB chunks
On 9/14/21 11:31 AM, Lukasz Majewski wrote:
On Tue, 14 Sep 2021 05:26:51 +0200
Marek Vasut wrote:
Not all SPI flashes and controllers can do continuous transfer longer
than 16 MiB, so perform the DFU read in 16 MiB chunks.
Signed-off-by: Marek Vasut
Cc: Lukasz Majewski
---
drivers/dfu/dfu_sf.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/dfu/dfu_sf.c b/drivers/dfu/dfu_sf.c
index 7e64ab772f0..b72493ced86 100644
--- a/drivers/dfu/dfu_sf.c
+++ b/drivers/dfu/dfu_sf.c
@@ -24,8 +24,18 @@ static int dfu_get_medium_size_sf(struct
dfu_entity *dfu, u64 *size) static int dfu_read_medium_sf(struct
dfu_entity *dfu, u64 offset, void *buf, long *len)
{
- return spi_flash_read(dfu->data.sf.dev, dfu->data.sf.start +
offset,
- *len, buf);
+ long seglen = *len;
+ int ret;
+
+ if (seglen > (16 << 20))
+ seglen = (16 << 20);
+
+ ret = spi_flash_read(dfu->data.sf.dev, dfu->data.sf.start +
offset,
+ seglen, buf);
+ if (!ret)
+ *len = seglen;
+
+ return ret;
}
static u64 find_sector(struct dfu_entity *dfu, u64 start, u64 offset)
Reviewed-by: Lukasz Majewski
Is there going to be a PR with this or shall Tom pick it directly, since
it is just one patch ?
Re: [PATCH v2] mtd: spi-nor-ids: Reinstate Micron MT25QL02G
On 10/8/21 2:49 PM, Jagan Teki wrote:
On Tue, Oct 5, 2021 at 2:29 PM Marek Vasut wrote:
This ID disappeared in 5b66fdb29dc ("mtd: spi: Remove unused files"),
add the ID back, since the chip is used on devices supported by U-Boot.
Fixes: 5b66fdb29dc ("mtd: spi: Remove unused files")
Signed-off-by: Marek Vasut
Cc: Horatiu Vultur
Cc: Jagan Teki
Cc: Simon Goldschmidt
Cc: Stefan Roese
Cc: Vignesh R
---
V2: Enable 4B opcodes which are supported by this chip
---
Applied to u-boot-spi/master
It seems u-boot-spi/master was last updated on August 5th and this patch
still isn't in u-boot/master either. Any news ?
[PATCH v4 1/5] board: sl28: enable EFI_SET_TIME support
From: Michael Walle Allow EFI to actually set the time before ExitBootServices(). Signed-off-by: Michael Walle Signed-off-by: Marcel Ziswiler --- Changes in v4: - Re-based on top of imx/master. Changes in v3: - none Changes in v2: - none configs/kontron_sl28_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/kontron_sl28_defconfig b/configs/kontron_sl28_defconfig index 4e25dafaaff..e066fe87771 100644 --- a/configs/kontron_sl28_defconfig +++ b/configs/kontron_sl28_defconfig @@ -94,3 +94,4 @@ CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_OF_LIBFDT_ASSUME_MASK=0x0 CONFIG_OF_LIBFDT_OVERLAY=y +CONFIG_EFI_SET_TIME=y -- 2.26.2
[PATCH v4 0/5] board: sl28: target refresh
From: Marcel Ziswiler Note that this re-base is only compile tested. Changes in v4: - Re-based on top of imx/master. Changes in v3: - none - use CONFIG_EFI_CAPSULE_FIRMWARE_FIT instead of CONFIG_EFI_CAPSULE_FIRMWARE_RAW Changes in v2: - none - new patch Frieder Schrempf (1): doc: board: kontron: sl28: Reduce section levels and change title Michael Walle (4): board: sl28: enable EFI_SET_TIME support board: sl28: generate FIT update image board: sl28: enable EFI UpdateCapsule support board: sl28: add update image documentation .../dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi | 35 ++- configs/kontron_sl28_defconfig| 7 +++ doc/board/kontron/sl28.rst| 45 --- include/configs/kontron_sl28.h| 2 + 4 files changed, 72 insertions(+), 17 deletions(-) -- 2.26.2
[PATCH v4 3/5] board: sl28: enable EFI UpdateCapsule support
From: Michael Walle
Enable support for update over EFI UpdateCapsule mechanism. This board
doesn't support setting EFI variables after ExitBootservices().
Therefore, we are also enabling EFI_IGNORE_OSINDICATIONS.
Signed-off-by: Michael Walle
Signed-off-by: Marcel Ziswiler
---
Changes in v4:
- Re-based on top of imx/master.
Changes in v3:
- use CONFIG_EFI_CAPSULE_FIRMWARE_FIT instead of
CONFIG_EFI_CAPSULE_FIRMWARE_RAW
Changes in v2:
- new patch
configs/kontron_sl28_defconfig | 6 ++
include/configs/kontron_sl28.h | 2 ++
2 files changed, 8 insertions(+)
diff --git a/configs/kontron_sl28_defconfig b/configs/kontron_sl28_defconfig
index e066fe87771..accd1b04006 100644
--- a/configs/kontron_sl28_defconfig
+++ b/configs/kontron_sl28_defconfig
@@ -64,6 +64,8 @@ CONFIG_FSL_CAAM=y
CONFIG_SYS_FSL_DDR3=y
CONFIG_DDR_ECC=y
CONFIG_ECC_INIT_VIA_DDRCONTROLLER=y
+CONFIG_DFU_MMC=y
+CONFIG_DFU_SF=y
CONFIG_I2C_SET_DEFAULT_BUS_NUM=y
CONFIG_I2C_MUX=y
CONFIG_MMC_HS400_SUPPORT=y
@@ -95,3 +97,7 @@ CONFIG_USB_XHCI_DWC3=y
CONFIG_OF_LIBFDT_ASSUME_MASK=0x0
CONFIG_OF_LIBFDT_OVERLAY=y
CONFIG_EFI_SET_TIME=y
+CONFIG_EFI_RUNTIME_UPDATE_CAPSULE=y
+CONFIG_EFI_CAPSULE_ON_DISK=y
+CONFIG_EFI_IGNORE_OSINDICATIONS=y
+CONFIG_EFI_CAPSULE_FIRMWARE_FIT=y
diff --git a/include/configs/kontron_sl28.h b/include/configs/kontron_sl28.h
index 6769592101d..4152851ba41 100644
--- a/include/configs/kontron_sl28.h
+++ b/include/configs/kontron_sl28.h
@@ -88,6 +88,8 @@
"envload=env import -d -b ${env_addr}\0" \
"install_rcw=source 2020\0" \
"fdtfile=freescale/fsl-ls1028a-kontron-sl28.dtb\0" \
+ "dfu_alt_info=sf 0:0=u-boot-bin raw 0x21 0x1d;" \
+ "u-boot-env raw 0x3e 0x2\0" \
ENV_MEM_LAYOUT_SETTINGS \
BOOTENV
--
2.26.2
[PATCH v4 4/5] doc: board: kontron: sl28: Reduce section levels and change title
From: Frieder Schrempf In order to add other Kontron boards to the docs alongside the existing sl28 board, we need to reduce the levels of the sections and change the title. Cc: Fabio Estevam Signed-off-by: Frieder Schrempf Acked-by: Michael Walle Signed-off-by: Marcel Ziswiler --- >From v3 of Michael: Frieder, Fabio, I took the liberty and added this patch to this series, because the next patch depends on it. It wasn't picked up yet in the imx queue. In fact, Frieders patches should not depend on this one, although the documentation will be incorrectly formatted, so it should be fine if this patch will go through the qoriq queue. Changes in v4: - Re-based on top of imx/master. Changes in v3: - none Changes in v2: - new patch doc/board/kontron/sl28.rst | 30 +++--- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/doc/board/kontron/sl28.rst b/doc/board/kontron/sl28.rst index e458fbc607c..07431986d8f 100644 --- a/doc/board/kontron/sl28.rst +++ b/doc/board/kontron/sl28.rst @@ -1,17 +1,17 @@ .. SPDX-License-Identifier: GPL-2.0+ -Summary -=== +Kontron SMARC-sAL28 +=== The Kontron SMARC-sAL28 board is a TSN-enabled dual-core ARM A72 processor module with an on-chip 6-port TSN switch and a 3D GPU. Quickstart -== +-- Compile U-Boot --- +^^ Configure and compile the binary:: @@ -21,7 +21,7 @@ Configure and compile the binary:: Copy u-boot.rom to a TFTP server. Install the bootloader on the board +^^^ Please note, this bootloader doesn't support the builtin watchdog (yet), therefore you have to disable it, see below. Otherwise you'll end up in @@ -36,7 +36,7 @@ disabled the builtin watchdog you might have to manually enter failsafe mode by asserting the ``FORCE_RECOV#`` line during board reset. Disable the builtin watchdog - + - boot into the failsafe bootloader, either by asserting the ``FORCE_RECOV#`` line or if you still have the original bootloader @@ -53,7 +53,7 @@ Disable the builtin watchdog Useful I2C tricks -= +- The board has a board management controller which is not supported in u-boot (yet). But you can use the i2c command to access it. @@ -68,7 +68,7 @@ u-boot (yet). But you can use the i2c command to access it. Non-volatile Board Configuration Bits -= +- The board has 16 configuration bits which are stored in the CPLD and are non-volatile. These can be changed by the `sl28 nvm` command. @@ -98,21 +98,21 @@ Please note, that if the board is in failsafe mode, the bits will have the factory defaults, ie. all bits are off. Power-On Inhibit - + If this is set, the board doesn't automatically turn on when power is applied. Instead, the user has to either toggle the ``PWR_BTN#`` line or use any other wake-up source such as RTC alarm or Wake-on-LAN. eMMC Boot -- +^ If this is set, the RCW will be fetched from the on-board eMMC at offset 1MiB. For further details, have a look at the `Reset Configuration Word Documentation`_. Watchdog - + By default, the CPLD watchdog is enabled in failsafe mode. Using bits 2 and 3, the user can change its mode or disable it altogether. @@ -127,21 +127,21 @@ Bit 2 Bit 3 Description = = === Clock Generator Select --- +^^ The board is prepared to supply different SerDes clock speeds. But for now, only setting 0 is supported, otherwise the CPU will hang because the PLL will not lock. Clock Output Disable And Keep Devices In Reset --- +^^ To safe power, the user might disable different devices and clock output of the board. It is not supported to disable the "CPU SerDes clock #2" for now, otherwise the CPU will hang because the PLL will not lock. Automatic reset of the onboard PHYs +^^^ By default, there is no hardware reset of the onboard PHY. This is because for Wake-on-LAN, some registers have to retain their values. If you don't @@ -151,7 +151,7 @@ power-on reset. Further documentation -= +- - `Vendor Documentation`_ - `Reset Configuration Word Documentation`_ -- 2.26.2
[PATCH v4 5/5] board: sl28: add update image documentation
From: Michael Walle Document the update image and how to use the EFI UpdateCapsule. Signed-off-by: Michael Walle Signed-off-by: Marcel Ziswiler --- Changes in v4: - Re-based on top of imx/master. Changes in v3: - none Changes in v2: - new patch doc/board/kontron/sl28.rst | 15 +++ 1 file changed, 15 insertions(+) diff --git a/doc/board/kontron/sl28.rst b/doc/board/kontron/sl28.rst index 07431986d8f..c7b18bed10c 100644 --- a/doc/board/kontron/sl28.rst +++ b/doc/board/kontron/sl28.rst @@ -52,6 +52,21 @@ Disable the builtin watchdog - power-cycle the board +Update image + + +After the build finished, there will be an update image called +u-boot.update. This can either be used in the DFU mode (which isn't +supported yet) or encapsulated in an EFI UpdateCapsule. + +To build the capsule use the following command + + $ tools/mkeficapsule -f u-boot.update -i 1 UpdateUboot + +Afterward you can copy this file to your ESP into the /EFI/UpdateCapsule/ +folder. On the next EFI boot this will automatically update your +bootloader. + Useful I2C tricks - -- 2.26.2
[PATCH v4 2/5] board: sl28: generate FIT update image
From: Michael Walle
Generate a FIT update image during build. The image will be called
"u-boot.update" and can be used to build an EFI UpdateCapsule or during
DFU mode. Although, the latter isn't supported because there is no USB
OTG driver yet.
Signed-off-by: Michael Walle
Signed-off-by: Marcel Ziswiler
---
Changes in v4:
- Re-based on top of imx/master.
Changes in v3:
- none
Changes in v2:
- new patch
.../dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi | 35 +--
1 file changed, 33 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi
b/arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi
index b3861ed98cf..a501cece698 100644
--- a/arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi
@@ -15,6 +15,12 @@
};
binman: binman {
+ multiple-images;
+ };
+};
+
+ {
+ u_boot_rom: u-boot-rom {
filename = "u-boot.rom";
pad-byte = <0xff>;
@@ -133,6 +139,31 @@
};
};
+ {
+ u-boot-update {
+ filename = "u-boot.update";
+
+ fit {
+ description = "FIT update image";
+
+ images {
+ u-boot-bin {
+ description = "U-Boot";
+ type = "firmware";
+ os = "u-boot";
+ arch = "arm";
+ compression = "none";
+ load = <0>; /* unused */
+
+ blob {
+ filename = "u-boot.rom";
+ };
+ };
+ };
+ };
+ };
+};
+
#ifdef CONFIG_SL28_ENABLE_SER0_CONSOLE
/ {
chosen {
@@ -142,7 +173,7 @@
#endif
#ifdef CONFIG_SL28_SPL_LOADS_ATF_BL31
- {
+_boot_rom {
fit {
images {
bl31 {
@@ -191,7 +222,7 @@
#endif
#ifdef CONFIG_SL28_SPL_LOADS_OPTEE_BL32
- {
+_boot_rom {
fit {
images {
bl32 {
--
2.26.2
[PATCH v2] imx8mm_beacon: Switch to binman for generating image
From: Adam Ford
To eliminate a warning when using custom imx tools for generating
a binary, use binman to generate flash.bin.
Signed-off-by: Adam Ford
Signed-off-by: Marcel Ziswiler
---
Note that this re-base is only compile tested.
Changes in v2:
- Re-based on top of imx/master.
arch/arm/dts/imx8mm-beacon-kit-u-boot.dtsi | 122
arch/arm/mach-imx/imx8m/Kconfig | 1 +
board/beacon/imx8mm/Kconfig | 2 +-
board/beacon/imx8mm/README | 6 +-
board/beacon/imx8mm/imximage-8mm-lpddr4.cfg | 9 ++
configs/imx8mm_beacon_defconfig | 2 +-
6 files changed, 137 insertions(+), 5 deletions(-)
create mode 100644 board/beacon/imx8mm/imximage-8mm-lpddr4.cfg
diff --git a/arch/arm/dts/imx8mm-beacon-kit-u-boot.dtsi
b/arch/arm/dts/imx8mm-beacon-kit-u-boot.dtsi
index 73ddfdade6a..3c034a85e35 100644
--- a/arch/arm/dts/imx8mm-beacon-kit-u-boot.dtsi
+++ b/arch/arm/dts/imx8mm-beacon-kit-u-boot.dtsi
@@ -6,6 +6,10 @@
#include "imx8mm-u-boot.dtsi"
/ {
+ binman: binman {
+ multiple-images;
+ };
+
wdt-reboot {
compatible = "wdt-reboot";
wdt = <>;
@@ -100,3 +104,121 @@
{
u-boot,dm-spl;
};
+
+ {
+u-boot-spl-ddr {
+ filename = "u-boot-spl-ddr.bin";
+ pad-byte = <0xff>;
+ align-size = <4>;
+ align = <4>;
+
+ u-boot-spl {
+ align-end = <4>;
+ };
+
+ blob_1: blob-ext@1 {
+ filename = "lpddr4_pmu_train_1d_imem.bin";
+ size = <0x8000>;
+ };
+
+ blob_2: blob-ext@2 {
+ filename = "lpddr4_pmu_train_1d_dmem.bin";
+ size = <0x4000>;
+ };
+
+ blob_3: blob-ext@3 {
+ filename = "lpddr4_pmu_train_2d_imem.bin";
+ size = <0x8000>;
+ };
+
+ blob_4: blob-ext@4 {
+ filename = "lpddr4_pmu_train_2d_dmem.bin";
+ size = <0x4000>;
+ };
+ };
+
+ spl {
+ filename = "spl.bin";
+
+ mkimage {
+ args = "-n spl/u-boot-spl.cfgout -T imx8mimage -e
0x7e1000";
+
+ blob {
+ filename = "u-boot-spl-ddr.bin";
+ };
+ };
+ };
+
+ itb {
+ filename = "u-boot.itb";
+
+ fit {
+ description = "Configuration to load ATF before U-Boot";
+ #address-cells = <1>;
+ fit,external-offset = ;
+
+ images {
+ uboot {
+ description = "U-Boot (64-bit)";
+ type = "standalone";
+ arch = "arm64";
+ compression = "none";
+ load = ;
+
+ uboot_blob: blob-ext {
+ filename = "u-boot-nodtb.bin";
+ };
+ };
+
+ atf {
+ description = "ARM Trusted Firmware";
+ type = "firmware";
+ arch = "arm64";
+ compression = "none";
+ load = <0x92>;
+ entry = <0x92>;
+
+ atf_blob: blob-ext {
+ filename = "bl31.bin";
+ };
+ };
+
+ fdt {
+ description = "NAME";
+ type = "flat_dt";
+ compression = "none";
+
+ uboot_fdt_blob: blob-ext {
+ filename = "u-boot.dtb";
+ };
+ };
+ };
+
+ configurations {
+ default = "conf";
+
+ conf {
+ description = "NAME";
+ firmware = "uboot";
+ loadables = "atf";
+ fdt = "fdt";
+ };
+ };
+ };
+ };
+
+ imx-boot {
+ filename = "flash.bin";
+
Re: Question: LTO and failing objcopy in "u-boot-initial-env" target
On Fri, Oct 22, 2021 at 2:26 PM Marek Behún wrote:
>
> On Fri, 22 Oct 2021 14:19:16 -0500
> Adam Ford wrote:
>
> > I am not sure it's the right solution, but it appears to work for me
> > on a board that uses LTO. I didn't try it with a board that doesn't
> > use LTO.
>
> Need to be tested with GCC as well as Clang.
Agreed.
I turned off LTO, and got an error, so I updated the diff to:
diff --git a/Makefile b/Makefile
index 5194e4dc78..386180e935 100644
--- a/Makefile
+++ b/Makefile
@@ -2303,7 +2303,7 @@ endif
$(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modpost
quiet_cmd_genenv = GENENV $@
-cmd_genenv = $(OBJCOPY) --dump-section .rodata.default_environment=$@
env/common.o; \
+cmd_genenv = $(OBJCOPY) --dump-section `${OBJDUMP} env/common.o -t
|grep -m1 default_environment |awk '{print $$4}'`=$@ env/common.o; \
sed --in-place -e 's/\x00/\x0A/g' $@
u-boot-initial-env: u-boot.bin
It now appears to build without error with LTO enabled and disabled.
>
> Marek
Re: [PATCH v4 1/4] tools: Separate image types which depend on OpenSSL
On 2021-10-22, Andre Przywara wrote: > On Fri, 22 Oct 2021 09:47:35 -0700 > Vagrant Cascadian wrote: >> On 2021-10-22, Tom Rini wrote: >> > On Fri, Oct 22, 2021 at 04:56:09PM +0100, Andre Przywara wrote: >> >> On Fri, 22 Oct 2021 11:09:27 -0400 >> >> Tom Rini wrote: >> >> >> > On Fri, Oct 22, 2021 at 04:59:22PM +0200, Marek Behún wrote: >> >> > > On Fri, 22 Oct 2021 12:09:19 +0200 >> >> > > Heinrich Schuchardt wrote: >> >> > > >> >> > > > On 10/21/21 15:00, Marek Behún wrote: >> >> > > > > BTW, wouldn't it be enough to simply imply TOOLS_LIBCRYPTO for >> >> > > > > mvebu >> >> > > > > platform in Kconfig? >> >> > > > > >> >> > > > >> >> > > > We should only use 'imply' for suggested settings and never for >> >> > > > hard >> >> > > > requirements. TOOLS_LIBCRYPTO already defaults to 'Y'. So implying >> >> > > > it >> >> > > > for mvebu would be redundant. >> >> > > > >> >> > > > In an OS distribution we only want to ship a single version of >> >> > > > mkimage. >> >> > > > So it is good to elimate symbol CONFIG_MXS. >> >> > > > >> >> > > > How mkimage is built should not depend on CONFIG_TOOLS_LIBCRYPTO. >> >> > > > >> >> > > > Tom wrote regarding this aspect in >> >> > > > https://lists.denx.de/pipermail/u-boot/2021-September/460251.html: >> >> > > > >> >> > > > "if we're building a generically useful tool, we don't want another >> >> > > > symbol for it." >> >> > > >> >> > > OK, so mkimage and dumpimage should be always generic and always >> >> > > support all platforms, that makes sense, since the tools can be >> >> > > installed as a distribution package. >> >> > > >> >> > > But I still think it should be possible to cripple these tools if the >> >> > > developer wants to disable libcrypto due to embedded environment. >> >> >> >> Well, I don't think this is the real question here, is it? >> >> I think the tools part is clear: distros want to build just mkimage, >> >> supporting as many platforms as possible, and might need to avoid OpenSSL. >> >> This should be covered by TOOLS_LIBCRYPTO=[yn] and "make >> >> tools-only_defconfg && make tools", and Samuel's patch actually fixes the >> >> build (at least somewhat, I still get link errors). >> > >> > The problem is, are distros doing a tools-only build, for tools, or are >> > they doing it per board? Like, hey, ugh, OpenEmbedded uses >> > sandbox_defconfig and cross_tools as the targets. That's not quite what >> > I was hoping to see. So I want to know everyone else is doing, rather >> > than we hope they're doing. >> >> Thanks for bringing this to my attention! >> >> In Debian, the u-boot-tools package is built using tools-only, and for >> each of the board-specific targets, it still ends up building the >> relevent tools, but we throw them away and do not ship them in any >> packages. >> >> With 2021.10, the board-specific builds made it harder to avoid openssl >> with the corresponding tools, and I reluctantly added a dependency on >> openssl... (which is technically permitted in Debian, having declared >> openssl as a system library to avoid the GPL incompatibilities, but >> ... meh.) > > But this is purely a *build-time* dependency only, right? The resulting > images do not have any openssl code in them, they were just *created* > (signed) using that code. > I don't think this a legal issue? The various .h includes are all that I saw, and I *think* all in the tools/ directory, but yeah, if this is really the case that no openssl code ends up in the board-specific binaries, that simplifies things considerably. > The problems are about *shipping* openssl code, which you only do for > u-boot-tools - where it now can be disabled. Probably won't disable it for u-boot-tools in Debian (reluctantly riding on the system library exception), but the tools builds that are part of the build process would be nice to be able to disable. >> I also have been doing some packaging of u-boot for GNU Guix, where I >> suspect the stance wouldn't be as willing to accept such a compromise... >> >> So... I would *love* an option to be able to build a board-only config >> without any of the tools; > > Why is this a problem (see above)? Who is building board builds? It's > either the maintainer when creating the binary package, or a curious user, > right? And they can surely *use* OpenSSL during build time - if it's > needed by the board. Sure, if there is no actual openssl code embedded in the resulting binary with GPLv2 code, it shouldn't be a problem... It's a mess of an issue to tease out exactly what codepaths trigger and do not trigger the compatibility issues between openssl and GPL... Depending on openssl in a project with GPLv2-only code does seem at risk to introduce license compatibility issues without sufficient and constant review and dilligence, even if it is technically ok how it is done right now... live well, vagrant signature.asc Description: PGP signature
Re: [PATCH] imx8mn_beacon: Fix booting hang and switch to binman
On Wed, Sep 29, 2021 at 8:26 AM Adam Ford wrote:
>
> On Thu, Sep 23, 2021 at 3:03 PM Adam Ford wrote:
> >
> > On Tue, Sep 14, 2021 at 9:49 PM Peng Fan (OSS) wrote:
> > >
> > >
> > >
> > > On 2021/9/11 4:19, Adam Ford wrote:
> > > > Somewhere along the line, the board stopped being able to boot.
> > > > Rather than just fixing the issue, let's fix the issue and migrate
> > > > to binman to eliminate a warning when using custom imx tools for
> > > > generating the binary.
> > > >
> >
> > Any chance this can make it into 2021.10? it's currently broken, and
> > this seems to fix the problem. i didn't bisect to see where the issue
> > broke, or i would have added a fixes tag.
>
> Stefano or Tom? could someone comment and/or merge? the board is
> currently not booting, and this fixes the issue
It's been over a month, and we missed the 2021.10 release. Is there
something stopping this from being applied?
adam
> >
> > adam
> > > > Signed-off-by: Adam Ford
> > > >
> > > > diff --git a/arch/arm/dts/imx8mn-beacon-kit-u-boot.dtsi
> > > > b/arch/arm/dts/imx8mn-beacon-kit-u-boot.dtsi
> > > > index bbc64a2819..69fd69c8d0 100644
> > > > --- a/arch/arm/dts/imx8mn-beacon-kit-u-boot.dtsi
> > > > +++ b/arch/arm/dts/imx8mn-beacon-kit-u-boot.dtsi
> > > > @@ -4,6 +4,10 @@
> > > >*/
> > > >
> > > > / {
> > > > + binman: binman {
> > > > + multiple-images;
> > > > + };
> > > > +
> > > > wdt-reboot {
> > > > compatible = "wdt-reboot";
> > > > wdt = <>;
> > > > @@ -40,6 +44,9 @@
> > > >{
> > > > u-boot,dm-spl;
> > > > u-boot,dm-pre-reloc;
> > > > + /delete-property/ assigned-clocks;
> > > > + /delete-property/ assigned-clock-parents;
> > > > + /delete-property/ assigned-clock-rates;
> > > > };
> > > >
> > > >{
> > > > @@ -99,6 +106,10 @@
> > > > u-boot,off-on-delay-us = <2>;
> > > > };
> > > >
> > > > + {
> > > > + u-boot,dm-spl;
> > > > +};
> > > > +
> > > >{
> > > > u-boot,dm-spl;
> > > > sd-uhs-sdr104;
> > > > @@ -120,3 +131,122 @@
> > > >{
> > > > u-boot,dm-spl;
> > > > };
> > > > +
> > > > + {
> > > > + u-boot-spl-ddr {
> > > > + filename = "u-boot-spl-ddr.bin";
> > > > + pad-byte = <0xff>;
> > > > + align-size = <4>;
> > > > + align = <4>;
> > > > +
> > > > + u-boot-spl {
> > > > + align-end = <4>;
> > > > + };
> > > > +
> > > > + blob_1: blob-ext@1 {
> > > > + filename = "lpddr4_pmu_train_1d_imem.bin";
> > > > + size = <0x8000>;
> > > > + };
> > > > +
> > > > + blob_2: blob-ext@2 {
> > > > + filename = "lpddr4_pmu_train_1d_dmem.bin";
> > > > + size = <0x4000>;
> > > > + };
> > > > +
> > > > + blob_3: blob-ext@3 {
> > > > + filename = "lpddr4_pmu_train_2d_imem.bin";
> > > > + size = <0x8000>;
> > > > + };
> > > > +
> > > > + blob_4: blob-ext@4 {
> > > > + filename = "lpddr4_pmu_train_2d_dmem.bin";
> > > > + size = <0x4000>;
> > > > + };
> > > > + };
> > > > +
> > > > +
> > > > + spl {
> > > > + filename = "spl.bin";
> > > > +
> > > > + mkimage {
> > > > + args = "-n spl/u-boot-spl.cfgout -T imx8mimage -e
> > > > 0x912000";
> > > > +
> > > > + blob {
> > > > + filename = "u-boot-spl-ddr.bin";
> > > > + };
> > > > + };
> > > > + };
> > > > +
> > > > + itb {
> > > > + filename = "u-boot.itb";
> > > > +
> > > > + fit {
> > > > + description = "Configuration to load ATF before
> > > > U-Boot";
> > > > + #address-cells = <1>;
> > > > + fit,external-offset =
> > > > ;
> > > > +
> > > > + images {
> > > > + uboot {
> > > > + description = "U-Boot (64-bit)";
> > > > + type = "standalone";
> > > > + arch = "arm64";
> > > > + compression = "none";
> > > > + load = ;
> > > > +
> > > > + uboot_blob: blob-ext {
> > > > + filename =
> > > > "u-boot-nodtb.bin";
> > > > + };
> > > > + };
> > > > +
> > > > + atf {
> > > > + description = "ARM Trusted
> > > > Firmware";
> > > > + type = "firmware";
> > > > + arch = "arm64";
> >
Re: Question: LTO and failing objcopy in "u-boot-initial-env" target
On Fri, 22 Oct 2021 14:19:16 -0500 Adam Ford wrote: > I am not sure it's the right solution, but it appears to work for me > on a board that uses LTO. I didn't try it with a board that doesn't > use LTO. Need to be tested with GCC as well as Clang. Marek
Re: Question: LTO and failing objcopy in "u-boot-initial-env" target
On Fri, 22 Oct 2021 17:16:18 +0200 Patrick DELAUNAY wrote: > Hi, > > > I made tests with LTO option activated on stm32mp15 boards but if have a > issue > > with the U-Boot target "u-boot-initial-env" (this command used by YOCTO) > > > $> make u-boot-initial-env > > ... > > GENENV u-boot-initial-env > arm-none-linux-gnueabihf-objcopy: env/common.o: can't dump section > '.rodata.default_environment' - it does not exist: file format not > recognized > sed: can't read u-boot-initial-env: No such file or directory > make[1]: *** [/local/home/frq07632/views/u-boot/Makefile:2315: > u-boot-initial-env] Error 2 > make[1]: Leaving directory > '/local/home/frq07632/views/build/stm32mp15_defconfig' > make: *** [Makefile:177: sub-make] Error 2 > > > But I reproduced it with sandbox: > > $> make sandbox_defconfig > > $> make all > > $> make u-boot-initial-env > > > > LTO u-boot > OBJCOPY u-boot-nodtb.bin > COPY u-boot.bin > GENENV u-boot-initial-env > objcopy: env/common.o: can't dump section '.rodata.default_environment' > - it does not exist: file format not recognized > sed: can't read u-boot-initial-env: No such file or directory > make: *** [Makefile:2315: u-boot-initial-env] Error 2 > > > > Do you already know this issue for other board which activate the LTO > feature ? > > I don't see any remarks about this issue on mailing list. > > Today I am known how to solve this issue. > > > PS: The same command is executed in "scripts/get_default_envs.sh" Seems that that script isn't executed in code integration, otherwise I would have noticed this.
Re: Question: LTO and failing objcopy in "u-boot-initial-env" target
On Fri, Oct 22, 2021 at 10:16 AM Patrick DELAUNAY
wrote:
>
> Hi,
>
>
> I made tests with LTO option activated on stm32mp15 boards but if have a
> issue
>
> with the U-Boot target "u-boot-initial-env" (this command used by YOCTO)
>
>
> $> make u-boot-initial-env
>
> ...
>
> GENENV u-boot-initial-env
> arm-none-linux-gnueabihf-objcopy: env/common.o: can't dump section
> '.rodata.default_environment' - it does not exist: file format not
> recognized
> sed: can't read u-boot-initial-env: No such file or directory
> make[1]: *** [/local/home/frq07632/views/u-boot/Makefile:2315:
> u-boot-initial-env] Error 2
> make[1]: Leaving directory
> '/local/home/frq07632/views/build/stm32mp15_defconfig'
> make: *** [Makefile:177: sub-make] Error 2
>
>
> But I reproduced it with sandbox:
>
> $> make sandbox_defconfig
>
> $> make all
>
> $> make u-boot-initial-env
>
>
>
>LTO u-boot
>OBJCOPY u-boot-nodtb.bin
>COPYu-boot.bin
>GENENV u-boot-initial-env
> objcopy: env/common.o: can't dump section '.rodata.default_environment'
> - it does not exist: file format not recognized
> sed: can't read u-boot-initial-env: No such file or directory
> make: *** [Makefile:2315: u-boot-initial-env] Error 2
>
>
>
> Do you already know this issue for other board which activate the LTO
> feature ?
>
> I don't see any remarks about this issue on mailing list.
>
> Today I am known how to solve this issue.
I ran this:
arm-linux-gnueabihf-objdump env/common.o -t |grep default_environment
|awk '{print $4}'
to generate the name of the section:
.gnu.lto_default_environment.188.408aacacdb8e4907
I modified the Makefile to search for default_environment, then use
output of that as a parameter to $OBJCOPY, and that appears to work.
=
diff --git a/Makefile b/Makefile
index 5194e4dc78..a80cf94ba1 100644
--- a/Makefile
+++ b/Makefile
@@ -2303,7 +2303,7 @@ endif
$(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modpost
quiet_cmd_genenv = GENENV $@
-cmd_genenv = $(OBJCOPY) --dump-section .rodata.default_environment=$@
env/common.o; \
+cmd_genenv = $(OBJCOPY) --dump-section `${OBJDUMP} env/common.o -t
|grep default_environment |awk '{print $$4}'`=$@ env/common.o; \
sed --in-place -e 's/\x00/\x0A/g' $@
u-boot-initial-env: u-boot.bin
=
...
make -f ./scripts/Makefile.build obj=arch/arm/dts dtbs
test -e arch/arm/dts/logicpd-torpedo-37xx-devkit.dtb || ( \
echo >&2; \
echo >&2 "Device Tree Source
(arch/arm/dts/logicpd-torpedo-37xx-devkit.dtb) is not correctly
specified."; \
echo >&2 "Please define 'CONFIG_DEFAULT_DEVICE_TREE'"; \
echo >&2 "or build with 'DEVICE_TREE=' argument"; \
echo >&2; \
/bin/false)
cat u-boot-nodtb.bin dts/dt.dtb > u-boot-dtb.bin
cp u-boot-dtb.bin u-boot.bin
arm-linux-gnueabihf-objcopy --dump-section
`arm-linux-gnueabihf-objdump env/common.o -t |grep default_environment
|awk '{print $4}'`=u-boot-initial-env env/common.o; sed --in-place -e
's/\x00/\x0A/g' u-boot-initial-env
$ ls -l u-boot-initial-env
-rw-rw-r-- 1 aford aford 1202 Oct 22 14:16 u-boot-initial-env
I am not sure it's the right solution, but it appears to work for me
on a board that uses LTO. I didn't try it with a board that doesn't
use LTO.
adam
>
>
> PS: The same command is executed in "scripts/get_default_envs.sh"
>
>
> Regards
>
> Patrick
>
>
>
> I am ussing gcc 10.2
>
> gcc version 10.2.1 20201103 (GNU Toolchain for the A-profile
> Architecture 10.2-2020.11 (arm-10.16))
>
>
> And the name of the section change with LTO: .gnu.lto_default_environment.*
>
> for exmaple:
>
>
> $> arm-none-linux-gnueabihf-objdump -x -g -S common.o
>
> common.o: file format elf32-littlearm
> common.o
> architecture: armv7, flags 0x0011:
> HAS_RELOC, HAS_SYMS
> start address 0x
> private flags = 500: [Version5 EABI]
>
> Sections:
> Idx Name Size VMA LMA File off Algn
>0 .text 0034 2**0
>CONTENTS, ALLOC, LOAD, READONLY, CODE
>1 .data 0034 2**0
>CONTENTS, ALLOC, LOAD, DATA
>2 .bss 0034 2**0
>ALLOC
>3 .gnu.debuglto_.debug_info 10a5 0034 2**0
>CONTENTS, RELOC, READONLY, EXCLUDE
>4 .gnu.debuglto_.debug_abbrev 02a1 10d9 2**0
>CONTENTS, READONLY, EXCLUDE
>5 .gnu.debuglto_.debug_line 0214 137a 2**0
>CONTENTS, READONLY, EXCLUDE
>6 .gnu.debuglto_.debug_str 12e3 158e 2**0
>CONTENTS, READONLY, EXCLUDE
>7 .gnu.lto_.profile.69d69ac49136740e 000b
> 2871 2**0
>CONTENTS, READONLY, EXCLUDE
>8 .gnu.lto_.icf.69d69ac49136740e 007b
> 287c 2**0
>CONTENTS, READONLY, EXCLUDE
>9
[PATCH] gpio: stm32: create include file for driver private data
The stm32 gpio driver private data are not needed in arch include files,
they are not used by code except for stm32 gpio and pincontrol drivers,
using the same IP; the defines for this IP is moved in a new file
"stm32_gpio_priv.h" in driver/gpio.
This patch avoids to have duplicated file gpio.h for each SOC
in MPU directory mach-stm32mp and in each MCU directory arch-stm32*
and allows to remove CONFIG_GPIO_EXTRA_HEADER for all STM32.
Signed-off-by: Patrick Delaunay
---
arch/arm/Kconfig | 2 -
arch/arm/include/asm/arch-stm32f4/gpio.h | 15
arch/arm/include/asm/arch-stm32f7/gpio.h | 12 ---
arch/arm/include/asm/arch-stm32h7/gpio.h | 12 ---
arch/arm/mach-stm32mp/include/mach/gpio.h | 87 ---
board/st/stm32f746-disco/stm32f746-disco.c| 1 -
drivers/gpio/stm32_gpio.c | 3 +-
.../gpio.h => drivers/gpio/stm32_gpio_priv.h | 6 +-
drivers/pinctrl/pinctrl_stm32.c | 3 +-
drivers/video/dw_mipi_dsi.c | 1 -
drivers/video/stm32/stm32_dsi.c | 1 -
drivers/video/stm32/stm32_ltdc.c | 1 -
12 files changed, 7 insertions(+), 137 deletions(-)
delete mode 100644 arch/arm/include/asm/arch-stm32f4/gpio.h
delete mode 100644 arch/arm/include/asm/arch-stm32f7/gpio.h
delete mode 100644 arch/arm/include/asm/arch-stm32h7/gpio.h
delete mode 100644 arch/arm/mach-stm32mp/include/mach/gpio.h
rename arch/arm/include/asm/arch-stm32/gpio.h =>
drivers/gpio/stm32_gpio_priv.h (94%)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 504abca0b7..0f33f9aa9a 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1789,7 +1789,6 @@ config ARCH_STM32
select CPU_V7M
select DM
select DM_SERIAL
- select GPIO_EXTRA_HEADER
imply CMD_DM
config ARCH_STI
@@ -1815,7 +1814,6 @@ config ARCH_STM32MP
select DM_GPIO
select DM_RESET
select DM_SERIAL
- select GPIO_EXTRA_HEADER
select MISC
select OF_CONTROL
select OF_LIBFDT
diff --git a/arch/arm/include/asm/arch-stm32f4/gpio.h
b/arch/arm/include/asm/arch-stm32f4/gpio.h
deleted file mode 100644
index 490f686a85..00
--- a/arch/arm/include/asm/arch-stm32f4/gpio.h
+++ /dev/null
@@ -1,15 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
-/*
- * (C) Copyright 2011
- * Yuri Tikhonov, Emcraft Systems, y...@emcraft.com
- *
- * (C) Copyright 2015
- * Kamil Lulko,
- */
-
-#ifndef _STM32_GPIO_H_
-#define _STM32_GPIO_H_
-
-#include
-
-#endif /* _STM32_GPIO_H_ */
diff --git a/arch/arm/include/asm/arch-stm32f7/gpio.h
b/arch/arm/include/asm/arch-stm32f7/gpio.h
deleted file mode 100644
index 21f4e0fd27..00
--- a/arch/arm/include/asm/arch-stm32f7/gpio.h
+++ /dev/null
@@ -1,12 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
-/*
- * Copyright (C) 2016, STMicroelectronics - All Rights Reserved
- * Author(s): Vikas Manocha, for STMicroelectronics.
- */
-
-#ifndef _STM32_GPIO_H_
-#define _STM32_GPIO_H_
-
-#include
-
-#endif /* _STM32_GPIO_H_ */
diff --git a/arch/arm/include/asm/arch-stm32h7/gpio.h
b/arch/arm/include/asm/arch-stm32h7/gpio.h
deleted file mode 100644
index 4f57f175ff..00
--- a/arch/arm/include/asm/arch-stm32h7/gpio.h
+++ /dev/null
@@ -1,12 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
-/*
- * Copyright (C) 2017, STMicroelectronics - All Rights Reserved
- * Author(s): Patrice Chotard, for
STMicroelectronics.
- */
-
-#ifndef _STM32_GPIO_H_
-#define _STM32_GPIO_H_
-
-#include
-
-#endif /* _STM32_GPIO_H_ */
diff --git a/arch/arm/mach-stm32mp/include/mach/gpio.h
b/arch/arm/mach-stm32mp/include/mach/gpio.h
deleted file mode 100644
index 7a0f293519..00
--- a/arch/arm/mach-stm32mp/include/mach/gpio.h
+++ /dev/null
@@ -1,87 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
-/*
- * (C) Copyright 2016
- * Vikas Manocha,
- */
-
-#ifndef _STM32_GPIO_H_
-#define _STM32_GPIO_H_
-#include
-
-enum stm32_gpio_mode {
- STM32_GPIO_MODE_IN = 0,
- STM32_GPIO_MODE_OUT,
- STM32_GPIO_MODE_AF,
- STM32_GPIO_MODE_AN
-};
-
-enum stm32_gpio_otype {
- STM32_GPIO_OTYPE_PP = 0,
- STM32_GPIO_OTYPE_OD
-};
-
-enum stm32_gpio_speed {
- STM32_GPIO_SPEED_2M = 0,
- STM32_GPIO_SPEED_25M,
- STM32_GPIO_SPEED_50M,
- STM32_GPIO_SPEED_100M
-};
-
-enum stm32_gpio_pupd {
- STM32_GPIO_PUPD_NO = 0,
- STM32_GPIO_PUPD_UP,
- STM32_GPIO_PUPD_DOWN
-};
-
-enum stm32_gpio_af {
- STM32_GPIO_AF0 = 0,
- STM32_GPIO_AF1,
- STM32_GPIO_AF2,
- STM32_GPIO_AF3,
- STM32_GPIO_AF4,
- STM32_GPIO_AF5,
- STM32_GPIO_AF6,
- STM32_GPIO_AF7,
- STM32_GPIO_AF8,
- STM32_GPIO_AF9,
- STM32_GPIO_AF10,
- STM32_GPIO_AF11,
- STM32_GPIO_AF12,
- STM32_GPIO_AF13,
- STM32_GPIO_AF14,
- STM32_GPIO_AF15
-};
-
-struct stm32_gpio_dsc {
- u8 port;
- u8 pin;
-};
-
-struct stm32_gpio_ctl {
- enum
[PATCH] socfpga: enable EFI partition support for de0-nano-soc
This fixes boot problems with distributions that use EFI boot like opensuse. Signed-off-by: Frank Kunz --- configs/socfpga_de0_nano_soc_defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configs/socfpga_de0_nano_soc_defconfig b/configs/socfpga_de0_nano_soc_defconfig index 17c160dd2a..3068f5615a 100644 --- a/configs/socfpga_de0_nano_soc_defconfig +++ b/configs/socfpga_de0_nano_soc_defconfig @@ -35,7 +35,7 @@ CONFIG_MTDIDS_DEFAULT="nor0=ff705000.spi.0" CONFIG_MTDPARTS_DEFAULT="mtdparts=ff705000.spi.0:1m(u-boot),256k(env1),256k(env2),14848k(boot),16m(rootfs),-@1536k(UBI)" CONFIG_CMD_UBI=y # CONFIG_ISO_PARTITION is not set -# CONFIG_EFI_PARTITION is not set +# CONFIG_SPL_EFI_PARTITION is not set CONFIG_ENV_IS_IN_MMC=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_VERSION_VARIABLE=y -- 2.33.1
Re: [PATCH v6 2/2] board: kontron: pitx-imx8m: Add Kontron pitx-imx8m board support
Hi Simon, Am Fr., 22. Okt. 2021 um 18:07 Uhr schrieb Simon Glass : > > Hi Heiko, > > On Fri, 22 Oct 2021 at 07:24, Heiko Thiery wrote: > > > > Hi, > > > > Am Fr., 22. Okt. 2021 um 14:37 Uhr schrieb Stefano Babic : > > > > > > Hi Heiko, > > > > > > On 22.10.21 10:19, Heiko Thiery wrote: > > > > Hi Stefano, Hi Simon, > > > > > > > > Am Do., 21. Okt. 2021 um 15:57 Uhr schrieb Heiko Thiery > > > > : > > > >> > > > >> Hi Stefano, Hi Simon, > > > >> > > > >> > > > >> Am Do., 21. Okt. 2021 um 15:29 Uhr schrieb Stefano Babic > > > >> : > > > >>> > > > >>> On 21.10.21 15:17, Heiko Thiery wrote: > > > Hi Stefano, > > > > > > > > > Am Do., 21. Okt. 2021 um 13:31 Uhr schrieb Stefano Babic > > > : > > > > > > > > Hi Heiko, > > > > > > > > On 14.10.21 20:08, Heiko Thiery wrote: > > > >> The Kontron pitx-imx8m is an NXP i.MX8MQ based board in the pITX > > > >> form factor. > > > >> > > > > > > > > There is still something using binman that does not work with CI. > > > > Without CI, we load all firmware including signed_hdmi_imx8m.bin. > > > > > > > > But on CI, file is not loaded, but instead of warnings, build for > > > > this > > > > board fails with : > > > > > > > > +Image 'main-section' is missing external blobs and is > > > > non-functional: > > > > blob-ext@1 blob-ext@2 blob-ext@3 blob-ext@4 > > > > +binman: Error 1 running 'mkimage -d ./mkimage.spl.mkimage -n > > > > spl/u-boot-spl.cfgout -T imx8mimage -e 0x7e1000 > > > > ./mkimage-out.spl.mkimage': signed_hdmi_imx8m.bin: Can't open: No > > > > such > > > > file or directory > > > > + > > > > > > > > Could you take a look ? > > > > > > Sure. Could you point me to the right CI configuration? > > > > > > >>> > > > >>> Configuration is in .gitlab-ci.yml. For thsi board, buildman is called > > > >>> as part of aarch64 target, that is > > > >>> > > > >>> buildman -o /tmp -P -E -W arm -x aarch64 > > > >>> > > > I need to understand how the required imx-firmware files are copied > > > to > > > the u-boot dir. This seems to work already for e. g. the imx8mm > > > boards. These require the lpdd* train fw files. > > > >> > > > >> Here we seem to hit an issue with the CI. blobs (lpddr*) are required > > > >> for the imx8mm boards. Binman reports the missing files only as a > > > >> warning and buildman does not care about that: > > > >> > > > >> +WARNING 'mkimage.flash.mkimage' not found, resulting binary is > > > >> not-functional > > > >> > > > >> > > > >> With the imx8mq boards switching to binman we also need an additional > > > >> fw part (signed_hdmi_imx8m.bin). But other than the lpddr firmware as > > > >> blob the signed_hmdi'_imx8m.bin is passed to mkimage and mkimage exits > > > >> with an error. Thats leads to the error: > > > >> > > > >> binman: Error 1 running 'mkimage -d ./mkimage.spl.mkimage -n > > > >> spl/u-boot-spl.cfgout -T imx8mimage -e 0x7e1000 > > > >> ./mkimage-out.spl.mkimage': signed_hdmi_imx8m.bin: Can't open: No such > > > >> file or directory > > > >> > > > >> > > > >> Currently I do not have an idea how to handle that. Anyone else? > > If I understand correctly: > > 1.You don't have these blobs in the tree so don't want to fail a build > in CI, which is why binman's blob-ext is used Correct, for the imx8mq e.g. the signed_hdmi_imx8m.bin is required that comes from NXP and has to be copied to the u-boot build dir. > 2. You sometimes need to ensure that they do exist For the build the "signed_hdmi_imx8m.bin" is required to successfully build. > Should we add a cmdline flag to binman to require all external blobs? I do not understand that. What should happen if this flag is present? > Could we drop the blobs and add code to generate them, or put the date > in a C struct? No, this is not possible because they are delivered by NXP from the firmware-imx package and has to be copied from there. > > > > > > > > I thought about it a little and did a quick hack. What do you think > > > > about dummy files being generated for buildman? > > > > > > I had quite the same idea... > > > > > > > I had buildman > > > > generate the blobs needed by binman. So at least the build runs > > > > through successfully. > > > > > > But it should be checked if files are present - I guess there are people > > > relying on buildman to produce the functional bootloader, and a dummy > > > file cannot overwrite the right one if present. > > > > Sure. As said ,this was only a quick hack to see if it could work. > > Another thing is if there should be a config for each board that says > > what files have to be created. > > > > > > I don't know yet how to integrate this sensibly > > > > into buildman or if this is useful for the maintainers at all. But > > > > this would get rid of the warnings and errors that come from binman. > > > > > > > > > > > > diff --git
Re: [PATCH v4 1/4] tools: Separate image types which depend on OpenSSL
On Fri, 22 Oct 2021 09:47:35 -0700 Vagrant Cascadian wrote: Hi, > On 2021-10-22, Tom Rini wrote: > > On Fri, Oct 22, 2021 at 04:56:09PM +0100, Andre Przywara wrote: > >> On Fri, 22 Oct 2021 11:09:27 -0400 > >> Tom Rini wrote: > > >> > On Fri, Oct 22, 2021 at 04:59:22PM +0200, Marek Behún wrote: > >> > > On Fri, 22 Oct 2021 12:09:19 +0200 > >> > > Heinrich Schuchardt wrote: > >> > > > >> > > > On 10/21/21 15:00, Marek Behún wrote: > >> > > > > BTW, wouldn't it be enough to simply imply TOOLS_LIBCRYPTO for > >> > > > > mvebu > >> > > > > platform in Kconfig? > >> > > > > > >> > > > > >> > > > We should only use 'imply' for suggested settings and never for hard > >> > > > requirements. TOOLS_LIBCRYPTO already defaults to 'Y'. So implying > >> > > > it > >> > > > for mvebu would be redundant. > >> > > > > >> > > > In an OS distribution we only want to ship a single version of > >> > > > mkimage. > >> > > > So it is good to elimate symbol CONFIG_MXS. > >> > > > > >> > > > How mkimage is built should not depend on CONFIG_TOOLS_LIBCRYPTO. > >> > > > > >> > > > Tom wrote regarding this aspect in > >> > > > https://lists.denx.de/pipermail/u-boot/2021-September/460251.html: > >> > > > > >> > > > "if we're building a generically useful tool, we don't want another > >> > > > symbol for it." > >> > > > >> > > OK, so mkimage and dumpimage should be always generic and always > >> > > support all platforms, that makes sense, since the tools can be > >> > > installed as a distribution package. > >> > > > >> > > But I still think it should be possible to cripple these tools if the > >> > > developer wants to disable libcrypto due to embedded environment. > >> > >> Well, I don't think this is the real question here, is it? > >> I think the tools part is clear: distros want to build just mkimage, > >> supporting as many platforms as possible, and might need to avoid OpenSSL. > >> This should be covered by TOOLS_LIBCRYPTO=[yn] and "make > >> tools-only_defconfg && make tools", and Samuel's patch actually fixes the > >> build (at least somewhat, I still get link errors). > > > > The problem is, are distros doing a tools-only build, for tools, or are > > they doing it per board? Like, hey, ugh, OpenEmbedded uses > > sandbox_defconfig and cross_tools as the targets. That's not quite what > > I was hoping to see. So I want to know everyone else is doing, rather > > than we hope they're doing. > > Thanks for bringing this to my attention! > > In Debian, the u-boot-tools package is built using tools-only, and for > each of the board-specific targets, it still ends up building the > relevent tools, but we throw them away and do not ship them in any > packages. > > With 2021.10, the board-specific builds made it harder to avoid openssl > with the corresponding tools, and I reluctantly added a dependency on > openssl... (which is technically permitted in Debian, having declared > openssl as a system library to avoid the GPL incompatibilities, but > ... meh.) But this is purely a *build-time* dependency only, right? The resulting images do not have any openssl code in them, they were just *created* (signed) using that code. I don't think this a legal issue? The problems are about *shipping* openssl code, which you only do for u-boot-tools - where it now can be disabled. > I also have been doing some packaging of u-boot for GNU Guix, where I > suspect the stance wouldn't be as willing to accept such a compromise... > > So... I would *love* an option to be able to build a board-only config > without any of the tools; Why is this a problem (see above)? Who is building board builds? It's either the maintainer when creating the binary package, or a curious user, right? And they can surely *use* OpenSSL during build time - if it's needed by the board. Cheers, Andre > do some boards use board-specific tools as > part of their build processes? > > > live well, > vagrant
Re: [PATCH 6/6] scripts: remove CONFIG_IS_ENABLED in config_whitelist.txt
Hi Simon On 10/14/21 5:09 PM, Simon Glass wrote: Hi Patrick, On Mon, 4 Oct 2021 at 04:00, Patrick Delaunay wrote: Redefine the macro CONFIG_IS_ENABLED is not allowed, so this entry can be removed in whitelist file. Signed-off-by: Patrick Delaunay --- scripts/config_whitelist.txt | 1 - 1 file changed, 1 deletion(-) diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt index b3ebd20c57..41a0952c97 100644 --- a/scripts/config_whitelist.txt +++ b/scripts/config_whitelist.txt @@ -649,7 +649,6 @@ CONFIG_IRAM_SIZE CONFIG_IRAM_STACK CONFIG_IRAM_TOP CONFIG_IRDA_BASE -CONFIG_IS_ENABLED CONFIG_JFFS2_DEV CONFIG_JFFS2_LZO CONFIG_JFFS2_NAND -- 2.25.1 For this to work you need to actually remove it from the source tree (which we can't), otherwise you get: Error: You must add new CONFIG options using Kconfig The following new ad-hoc CONFIG options were detected: CONFIG_IS_ENABLED I don't think this is worth it though, so I suggest dropping this patch. Regards, Simon Yes ! sorry CONFIG_IS_ENABLED is present in u-boot.cfg, as CONFIG_VAL even if it is strange for these macro defined in "linux/kconfig.h" but agree to drop this tentative. Do you think I can remove the CONFIG_IS_ENABLED and CONFIG_VAL in u-boot.cfg when the file is generated ? Patrick
Re: [PATCH v4 1/4] tools: Separate image types which depend on OpenSSL
On Friday 22 October 2021 09:47:35 Vagrant Cascadian wrote: > do some boards use board-specific tools as part of their build processes? Lot of boards are using mkimage for generating final U-Boot binary. Prior U-Boot 2021.10 all 32-bit mvebu boards used own specific version of mkimage to generate final U-Boot binary. mkimage had own compile time options (defined in board include header files) which generated unique ./tools/mkimage binary, specific for just one board. Since U-Boot 2021.10 now all 32-bit mvebu boards are using one common mkimage binary. So you can even do defconfig for some x86 board, build mkimage binary and then you can use this mkimage binary also for building final mvebu (arm) U-Boot binary. Side effect of this change was hard dependency on openssl, but we are discussing how to solve and remove that hard dependency. I do not know if there are any processors, SoCs or boards which require board-specific version of some tool (e.g. mkimage) in U-Boot 2021.10.
Re: [PATCH v4 1/4] tools: Separate image types which depend on OpenSSL
On 2021-10-22, Tom Rini wrote: > On Fri, Oct 22, 2021 at 04:56:09PM +0100, Andre Przywara wrote: >> On Fri, 22 Oct 2021 11:09:27 -0400 >> Tom Rini wrote: >> > On Fri, Oct 22, 2021 at 04:59:22PM +0200, Marek Behún wrote: >> > > On Fri, 22 Oct 2021 12:09:19 +0200 >> > > Heinrich Schuchardt wrote: >> > > >> > > > On 10/21/21 15:00, Marek Behún wrote: >> > > > > BTW, wouldn't it be enough to simply imply TOOLS_LIBCRYPTO for mvebu >> > > > > platform in Kconfig? >> > > > > >> > > > >> > > > We should only use 'imply' for suggested settings and never for hard >> > > > requirements. TOOLS_LIBCRYPTO already defaults to 'Y'. So implying it >> > > > for mvebu would be redundant. >> > > > >> > > > In an OS distribution we only want to ship a single version of >> > > > mkimage. >> > > > So it is good to elimate symbol CONFIG_MXS. >> > > > >> > > > How mkimage is built should not depend on CONFIG_TOOLS_LIBCRYPTO. >> > > > >> > > > Tom wrote regarding this aspect in >> > > > https://lists.denx.de/pipermail/u-boot/2021-September/460251.html: >> > > > >> > > > "if we're building a generically useful tool, we don't want another >> > > > symbol for it." >> > > >> > > OK, so mkimage and dumpimage should be always generic and always >> > > support all platforms, that makes sense, since the tools can be >> > > installed as a distribution package. >> > > >> > > But I still think it should be possible to cripple these tools if the >> > > developer wants to disable libcrypto due to embedded environment. >> >> Well, I don't think this is the real question here, is it? >> I think the tools part is clear: distros want to build just mkimage, >> supporting as many platforms as possible, and might need to avoid OpenSSL. >> This should be covered by TOOLS_LIBCRYPTO=[yn] and "make >> tools-only_defconfg && make tools", and Samuel's patch actually fixes the >> build (at least somewhat, I still get link errors). > > The problem is, are distros doing a tools-only build, for tools, or are > they doing it per board? Like, hey, ugh, OpenEmbedded uses > sandbox_defconfig and cross_tools as the targets. That's not quite what > I was hoping to see. So I want to know everyone else is doing, rather > than we hope they're doing. Thanks for bringing this to my attention! In Debian, the u-boot-tools package is built using tools-only, and for each of the board-specific targets, it still ends up building the relevent tools, but we throw them away and do not ship them in any packages. With 2021.10, the board-specific builds made it harder to avoid openssl with the corresponding tools, and I reluctantly added a dependency on openssl... (which is technically permitted in Debian, having declared openssl as a system library to avoid the GPL incompatibilities, but ... meh.) I also have been doing some packaging of u-boot for GNU Guix, where I suspect the stance wouldn't be as willing to accept such a compromise... So... I would *love* an option to be able to build a board-only config without any of the tools; do some boards use board-specific tools as part of their build processes? live well, vagrant signature.asc Description: PGP signature
Re: [PATCH v4 1/4] tools: Separate image types which depend on OpenSSL
On Fri, Oct 22, 2021 at 04:56:09PM +0100, Andre Przywara wrote: > On Fri, 22 Oct 2021 11:09:27 -0400 > Tom Rini wrote: > > Hi, > > > On Fri, Oct 22, 2021 at 04:59:22PM +0200, Marek Behún wrote: > > > On Fri, 22 Oct 2021 12:09:19 +0200 > > > Heinrich Schuchardt wrote: > > > > > > > On 10/21/21 15:00, Marek Behún wrote: > > > > > BTW, wouldn't it be enough to simply imply TOOLS_LIBCRYPTO for mvebu > > > > > platform in Kconfig? > > > > > > > > > > > > > We should only use 'imply' for suggested settings and never for hard > > > > requirements. TOOLS_LIBCRYPTO already defaults to 'Y'. So implying it > > > > for mvebu would be redundant. > > > > > > > > In an OS distribution we only want to ship a single version of mkimage. > > > > So it is good to elimate symbol CONFIG_MXS. > > > > > > > > How mkimage is built should not depend on CONFIG_TOOLS_LIBCRYPTO. > > > > > > > > Tom wrote regarding this aspect in > > > > https://lists.denx.de/pipermail/u-boot/2021-September/460251.html: > > > > > > > > "if we're building a generically useful tool, we don't want another > > > > symbol for it." > > > > > > OK, so mkimage and dumpimage should be always generic and always > > > support all platforms, that makes sense, since the tools can be > > > installed as a distribution package. > > > > > > But I still think it should be possible to cripple these tools if the > > > developer wants to disable libcrypto due to embedded environment. > > Well, I don't think this is the real question here, is it? > I think the tools part is clear: distros want to build just mkimage, > supporting as many platforms as possible, and might need to avoid OpenSSL. > This should be covered by TOOLS_LIBCRYPTO=[yn] and "make > tools-only_defconfg && make tools", and Samuel's patch actually fixes the > build (at least somewhat, I still get link errors). The problem is, are distros doing a tools-only build, for tools, or are they doing it per board? Like, hey, ugh, OpenEmbedded uses sandbox_defconfig and cross_tools as the targets. That's not quite what I was hoping to see. So I want to know everyone else is doing, rather than we hope they're doing. -- Tom signature.asc Description: PGP signature
Re: [PATCH 06/14] env: nvram: Cosmetic fix in env_nvram_init()
On Fri, 22 Oct 2021 at 07:47, Marek Behún wrote: > > From: Marek Behún > > Use spaces consistently in assignments instead of tabs. > > Signed-off-by: Marek Behún > --- > env/nvram.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > Reviewed-by: Simon Glass
Re: [PATCH 02/14] env: sf: Use ENV_VALID enum names instead of literals
On Fri, 22 Oct 2021 at 07:47, Marek Behún wrote: > > From: Marek Behún > > The function env_sf_init_addr() assigns number literals (1) instead of > ENV_VALID to gd->env_valid. Fix this. > > Signed-off-by: Marek Behún > --- > env/sf.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > Reviewed-by: Simon Glass
Re: [PATCH 05/14] env: nvram: Let generic env_init() assign default environment
On Fri, 22 Oct 2021 at 07:47, Marek Behún wrote: > > From: Marek Behún > > env_nvram_init() assigns default environment if ENV_INVALID, but this is > done in the generic env_init() function, which calls this initializer, > so drop it from here. > > Signed-off-by: Marek Behún > --- > env/nvram.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > Reviewed-by: Simon Glass
Re: [PATCH 03/14] env: sf: Put ENV_INVALID into gd->env_valid on CRC failure
On Fri, 22 Oct 2021 at 07:47, Marek Behún wrote: > > From: Marek Behún > > env_sf_init_addr() says the environment is valid even if it is assigning > default environment due to CRC failure. Change this to ENV_INVALID and > let the generic env_init() function, which calls this initializer, > assign the default environment. > > Signed-off-by: Marek Behún > --- > env/sf.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) Reviewed-by: Simon Glass
Re: [PATCH 07/14] env: nowhere: Let generic env_init() assign default environment
On Fri, 22 Oct 2021 at 07:47, Marek Behún wrote: > > From: Marek Behún > > env_nowhere_init() assigns default environment if ENV_INVALID, but this > is done in the generic env_init() function, which calls this > initializer, so drop it from here. > > Signed-off-by: Marek Behún > --- > env/nowhere.c | 1 - > 1 file changed, 1 deletion(-) > Reviewed-by: Simon Glass
Re: [PATCH 14/14] env: Use static_assert() to check if default_environment is too large
On Fri, 22 Oct 2021 at 07:48, Marek Behún wrote: > > From: Marek Behún > > Check sizeof(default_environment) against ENV_SIZE in a static_assert() > instead of runtime. > Only check if !USE_HOSTCC (for in fw_env tool ENV_SIZE expands to a > variable, and cannot be checked statically) nad > !DEFAULT_ENV_INSTANCE_EMBEDDED, for in that case the default_environment > variable is not set. > > Signed-off-by: Marek Behún > --- > env/common.c | 5 - > include/env_default.h | 6 ++ > 2 files changed, 6 insertions(+), 5 deletions(-) Reviewed-by: Simon Glass
Re: [PATCH 09/14] env: flash: Let generic env_init() assign default environment
On Fri, 22 Oct 2021 at 07:47, Marek Behún wrote: > > From: Marek Behún > > env_flash_init() (both implementations) assigns default environment if > ENV_INVALID, but this is done in the generic env_init() function, which > calls this initializer, so drop it from here. > > Signed-off-by: Marek Behún > --- > env/flash.c | 3 --- > 1 file changed, 3 deletions(-) > Reviewed-by: Simon Glass
Re: [PATCH 13/14] env: Always use char for default_environment
On Fri, 22 Oct 2021 at 07:47, Marek Behún wrote: > > From: Marek Behún > > Sometimes we use uchar and sometimes char for the default environment > array. By always using char, we can get rid of some explicit casts. > > Signed-off-by: Marek Behún > --- > board/Marvell/mvebu_armada-37xx/board.c | 2 +- > env/common.c| 6 +++--- > include/env_default.h | 4 ++-- > include/env_internal.h | 4 ++-- > 4 files changed, 8 insertions(+), 8 deletions(-) Reviewed-by: Simon Glass
Re: [PATCH 12/14] board: freescale: various boards: Let env subsystem set gd->env_addr
On Fri, 22 Oct 2021 at 07:47, Marek Behún wrote: > > From: Marek Behún > > Various freescale boards set gd->env_addr to default_environment in > board_init(), conditional on CONFIG_ENV_IS_NOWHERE, but this is > redundant, since it is done by env_init() before board_init() is called. > > Let the env subsystem handle this. > > Signed-off-by: Marek Behún > Cc: Ramon Fried > Cc: Priyanka Jain > Cc: Mian Yousaf Kaukab > --- > board/freescale/ls1012afrdm/ls1012afrdm.c | 4 > board/freescale/ls1012aqds/ls1012aqds.c | 4 > board/freescale/ls1012ardb/ls1012ardb.c | 4 > board/freescale/ls1028a/ls1028a.c | 4 > board/freescale/ls1088a/ls1088a.c | 4 > board/freescale/ls2080aqds/ls2080aqds.c | 3 --- > board/freescale/ls2080ardb/ls2080ardb.c | 3 --- > board/freescale/lx2160a/lx2160a.c | 3 --- > 8 files changed, 29 deletions(-) Reviewed-by: Simon Glass
Re: [PATCH 11/14] board: synquacer: developerbox: Don't set gd->env_addr to default_environment
On Fri, 22 Oct 2021 at 07:47, Marek Behún wrote: > > From: Marek Behún > > This board sets gd->env_addr to default_environment in board_init(), but > the board has environment in SPI flash according to defconfig. Let the > env API handle environment automatically. > > Signed-off-by: Marek Behún > Cc: Masami Hiramatsu > --- > board/socionext/developerbox/developerbox.c | 2 -- > 1 file changed, 2 deletions(-) Reviewed-by: Simon Glass
Re: [PATCH 10/14] env: flash: Cosmetic fix
On Fri, 22 Oct 2021 at 07:47, Marek Behún wrote: > > From: Marek Behún > > Change tab to space in env_flash_init(). > > Signed-off-by: Marek Behún > --- > env/flash.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Reviewed-by: Simon Glass Feel free to do these code-style all in one patch in the future.
Re: [PATCH 04/14] env: nand: Put ENV_INVALID into gd->env_valid if default environment
On Fri, 22 Oct 2021 at 07:47, Marek Behún wrote: > > From: Marek Behún > > env_nand_init() says the environment is valid even if it is assigning > default environment due to not being able to access nand pre-reloaction > (determined by macro values). Change this to ENV_INVALID and let the > generic env_init() function, which calls this initializer, assign the > default environment. > > Signed-off-by: Marek Behún > --- > env/nand.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > Reviewed-by: Simon Glass
Re: [PATCH 08/14] env: nowhere: Cosmetic fix
On Fri, 22 Oct 2021 at 07:47, Marek Behún wrote: > > From: Marek Behún > > Use spaces instead of tabs in assignments, since there are no lines to > align assignment values to. > > Signed-off-by: Marek Behún > --- > env/nowhere.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Reviewed-by: Simon Glass
Re: [PATCH 01/14] env: sf: Cosmetic fix in env_sf_init_addr()
On Fri, 22 Oct 2021 at 07:47, Marek Behún wrote: > > From: Marek Behún > > In the if clause we use tabs and in the else clause spaces. Let's use > spaces in the if clause too. > > Signed-off-by: Marek Behún > --- > env/sf.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Reviewed-by: Simon Glass
Re: [PATCH v6 2/2] board: kontron: pitx-imx8m: Add Kontron pitx-imx8m board support
Hi Heiko,
On Fri, 22 Oct 2021 at 07:24, Heiko Thiery wrote:
>
> Hi,
>
> Am Fr., 22. Okt. 2021 um 14:37 Uhr schrieb Stefano Babic :
> >
> > Hi Heiko,
> >
> > On 22.10.21 10:19, Heiko Thiery wrote:
> > > Hi Stefano, Hi Simon,
> > >
> > > Am Do., 21. Okt. 2021 um 15:57 Uhr schrieb Heiko Thiery
> > > :
> > >>
> > >> Hi Stefano, Hi Simon,
> > >>
> > >>
> > >> Am Do., 21. Okt. 2021 um 15:29 Uhr schrieb Stefano Babic
> > >> :
> > >>>
> > >>> On 21.10.21 15:17, Heiko Thiery wrote:
> > Hi Stefano,
> >
> >
> > Am Do., 21. Okt. 2021 um 13:31 Uhr schrieb Stefano Babic
> > :
> > >
> > > Hi Heiko,
> > >
> > > On 14.10.21 20:08, Heiko Thiery wrote:
> > >> The Kontron pitx-imx8m is an NXP i.MX8MQ based board in the pITX
> > >> form factor.
> > >>
> > >
> > > There is still something using binman that does not work with CI.
> > > Without CI, we load all firmware including signed_hdmi_imx8m.bin.
> > >
> > > But on CI, file is not loaded, but instead of warnings, build for this
> > > board fails with :
> > >
> > > +Image 'main-section' is missing external blobs and is non-functional:
> > > blob-ext@1 blob-ext@2 blob-ext@3 blob-ext@4
> > > +binman: Error 1 running 'mkimage -d ./mkimage.spl.mkimage -n
> > > spl/u-boot-spl.cfgout -T imx8mimage -e 0x7e1000
> > > ./mkimage-out.spl.mkimage': signed_hdmi_imx8m.bin: Can't open: No such
> > > file or directory
> > > +
> > >
> > > Could you take a look ?
> >
> > Sure. Could you point me to the right CI configuration?
> >
> > >>>
> > >>> Configuration is in .gitlab-ci.yml. For thsi board, buildman is called
> > >>> as part of aarch64 target, that is
> > >>>
> > >>> buildman -o /tmp -P -E -W arm -x aarch64
> > >>>
> > I need to understand how the required imx-firmware files are copied to
> > the u-boot dir. This seems to work already for e. g. the imx8mm
> > boards. These require the lpdd* train fw files.
> > >>
> > >> Here we seem to hit an issue with the CI. blobs (lpddr*) are required
> > >> for the imx8mm boards. Binman reports the missing files only as a
> > >> warning and buildman does not care about that:
> > >>
> > >> +WARNING 'mkimage.flash.mkimage' not found, resulting binary is
> > >> not-functional
> > >>
> > >>
> > >> With the imx8mq boards switching to binman we also need an additional
> > >> fw part (signed_hdmi_imx8m.bin). But other than the lpddr firmware as
> > >> blob the signed_hmdi'_imx8m.bin is passed to mkimage and mkimage exits
> > >> with an error. Thats leads to the error:
> > >>
> > >> binman: Error 1 running 'mkimage -d ./mkimage.spl.mkimage -n
> > >> spl/u-boot-spl.cfgout -T imx8mimage -e 0x7e1000
> > >> ./mkimage-out.spl.mkimage': signed_hdmi_imx8m.bin: Can't open: No such
> > >> file or directory
> > >>
> > >>
> > >> Currently I do not have an idea how to handle that. Anyone else?
If I understand correctly:
1.You don't have these blobs in the tree so don't want to fail a build
in CI, which is why binman's blob-ext is used
2. You sometimes need to ensure that they do exist
Should we add a cmdline flag to binman to require all external blobs?
Could we drop the blobs and add code to generate them, or put the date
in a C struct?
> > >
> > > I thought about it a little and did a quick hack. What do you think
> > > about dummy files being generated for buildman?
> >
> > I had quite the same idea...
> >
> > > I had buildman
> > > generate the blobs needed by binman. So at least the build runs
> > > through successfully.
> >
> > But it should be checked if files are present - I guess there are people
> > relying on buildman to produce the functional bootloader, and a dummy
> > file cannot overwrite the right one if present.
>
> Sure. As said ,this was only a quick hack to see if it could work.
> Another thing is if there should be a config for each board that says
> what files have to be created.
>
> > > I don't know yet how to integrate this sensibly
> > > into buildman or if this is useful for the maintainers at all. But
> > > this would get rid of the warnings and errors that come from binman.
> > >
> > >
> > > diff --git a/tools/buildman/board.py b/tools/buildman/board.py
> > > index 447aaabea8..cf270c8b72 100644
> > > --- a/tools/buildman/board.py
> > > +++ b/tools/buildman/board.py
> > > @@ -96,6 +96,28 @@ class Board:
> > > self.vendor, self.soc, self.options]
> > > self.build_it = False
> > >
> > > +def create_dummy_files(self, work_dir):
> > > +import configparser
> > > +import os
> > > +
> > > +settings = configparser.SafeConfigParser()
> > > +config_fname = '%s/.buildman/' % os.getenv('HOME')
> > > +if os.path.exists(config_fname):
> > > +settings.read(config_fname)
> > > +
> > > +if self.target == "kontron_pitx_imx8m":
> > > +
> > > +dummy_files = ['bl31.bin',
Re: [PATCH v4 1/4] tools: Separate image types which depend on OpenSSL
On Fri, 22 Oct 2021 11:09:27 -0400 Tom Rini wrote: Hi, > On Fri, Oct 22, 2021 at 04:59:22PM +0200, Marek Behún wrote: > > On Fri, 22 Oct 2021 12:09:19 +0200 > > Heinrich Schuchardt wrote: > > > > > On 10/21/21 15:00, Marek Behún wrote: > > > > BTW, wouldn't it be enough to simply imply TOOLS_LIBCRYPTO for mvebu > > > > platform in Kconfig? > > > > > > > > > > We should only use 'imply' for suggested settings and never for hard > > > requirements. TOOLS_LIBCRYPTO already defaults to 'Y'. So implying it > > > for mvebu would be redundant. > > > > > > In an OS distribution we only want to ship a single version of mkimage. > > > So it is good to elimate symbol CONFIG_MXS. > > > > > > How mkimage is built should not depend on CONFIG_TOOLS_LIBCRYPTO. > > > > > > Tom wrote regarding this aspect in > > > https://lists.denx.de/pipermail/u-boot/2021-September/460251.html: > > > > > > "if we're building a generically useful tool, we don't want another > > > symbol for it." > > > > OK, so mkimage and dumpimage should be always generic and always > > support all platforms, that makes sense, since the tools can be > > installed as a distribution package. > > > > But I still think it should be possible to cripple these tools if the > > developer wants to disable libcrypto due to embedded environment. Well, I don't think this is the real question here, is it? I think the tools part is clear: distros want to build just mkimage, supporting as many platforms as possible, and might need to avoid OpenSSL. This should be covered by TOOLS_LIBCRYPTO=[yn] and "make tools-only_defconfg && make tools", and Samuel's patch actually fixes the build (at least somewhat, I still get link errors). The question at hand is whether *board* builds should be able to *force* TOOLS_LIBCRYPTO, aka "select" this symbol. This was somewhat denied by Alex, on the grounds of the top comment in tools/Makefile: # Host tools can be used across multiple targets, or different configurations # of the same target. Thus, host tools must be able to handle any combination # of target configurations. To prevent having different variations of the same # tool, the tool build options may not depend on target configuration. I read this as: "a tool like mkimage should not use #ifdef CONFIG_PLATFORM_FEATURE", but I don't see why a defconfig should not be able to select TOOLS_LIBCRYPTO, if that's needed to package the firmware. Do I get this correctly? If that's the case, then I think we should actually stick more with the solution in v2, or maybe split that patch, so v4 plus Pali's separate patch to select/depend on LIBCRYPTO for boards using kwbimage. Does that make sense? Cheers, Andre > > This is probably the time to reach out to some of the distro folks to > see how they would like to see things handled for "build the tools we > need to package for the user" and also "build the binary for the > platform". >
[PATCH] cmd: pxe_utils: sysboot: add label override support
This will allow consumers to choose a pxe label at runtime instead of
having to prompt the user. One good use-case for this, is choosing
whether or not to apply a dtbo depending on the hardware configuration.
e.g: for TI's AM335x EVM, it would be convenient to apply a particular
dtbo only when the J9 jumper is on PRUSS mode. To achieve this, the
pxe menu should have 2 labels, one with the dtbo and the other without,
then the "pxe_label_override" env variable should point to the label with
the dtbo at runtime only when the jumper is on PRUSS mode.
This change can be used for different use-cases and bring more
flexibilty to consumers who use sysboot/pxe_utils.
if "pxe_label_override" is set but does not exist in the pxe menu,
the code should fallback to the default label if given, and no failure
is returned but rather a warning message.
Signed-off-by: Amjad Ouled-Ameur
---
cmd/pxe_utils.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/cmd/pxe_utils.c b/cmd/pxe_utils.c
index 067c24e5ff4b..b1009f9c7547 100644
--- a/cmd/pxe_utils.c
+++ b/cmd/pxe_utils.c
@@ -1354,9 +1354,11 @@ static struct menu *pxe_menu_to_menu(struct pxe_menu
*cfg)
struct pxe_label *label;
struct list_head *pos;
struct menu *m;
+ char *label_override;
int err;
int i = 1;
char *default_num = NULL;
+ char *override_num = NULL;
/*
* Create a menu and add items for all the labels.
@@ -1367,6 +1369,8 @@ static struct menu *pxe_menu_to_menu(struct pxe_menu *cfg)
if (!m)
return NULL;
+ label_override = env_get("pxe_label_override");
+
list_for_each(pos, >labels) {
label = list_entry(pos, struct pxe_label, list);
@@ -1375,11 +1379,22 @@ static struct menu *pxe_menu_to_menu(struct pxe_menu
*cfg)
menu_destroy(m);
return NULL;
}
+ if (label_override &&
+ (strcmp(label->name, label_override) == 0))
+ override_num = label->num;
if (cfg->default_label &&
(strcmp(label->name, cfg->default_label) == 0))
default_num = label->num;
}
+ if (label_override) {
+ if (override_num)
+ default_num = override_num;
+ else
+ printf("Missing override pxe label: %s\n",
+ label_override);
+ }
+
/*
* After we've created items for each label in the menu, set the
* menu's default label if one was specified.
--
2.25.1
Question: LTO and failing objcopy in "u-boot-initial-env" target
Hi, I made tests with LTO option activated on stm32mp15 boards but if have a issue with the U-Boot target "u-boot-initial-env" (this command used by YOCTO) $> make u-boot-initial-env ... GENENV u-boot-initial-env arm-none-linux-gnueabihf-objcopy: env/common.o: can't dump section '.rodata.default_environment' - it does not exist: file format not recognized sed: can't read u-boot-initial-env: No such file or directory make[1]: *** [/local/home/frq07632/views/u-boot/Makefile:2315: u-boot-initial-env] Error 2 make[1]: Leaving directory '/local/home/frq07632/views/build/stm32mp15_defconfig' make: *** [Makefile:177: sub-make] Error 2 But I reproduced it with sandbox: $> make sandbox_defconfig $> make all $> make u-boot-initial-env LTO u-boot OBJCOPY u-boot-nodtb.bin COPY u-boot.bin GENENV u-boot-initial-env objcopy: env/common.o: can't dump section '.rodata.default_environment' - it does not exist: file format not recognized sed: can't read u-boot-initial-env: No such file or directory make: *** [Makefile:2315: u-boot-initial-env] Error 2 Do you already know this issue for other board which activate the LTO feature ? I don't see any remarks about this issue on mailing list. Today I am known how to solve this issue. PS: The same command is executed in "scripts/get_default_envs.sh" Regards Patrick I am ussing gcc 10.2 gcc version 10.2.1 20201103 (GNU Toolchain for the A-profile Architecture 10.2-2020.11 (arm-10.16)) And the name of the section change with LTO: .gnu.lto_default_environment.* for exmaple: $> arm-none-linux-gnueabihf-objdump -x -g -S common.o common.o: file format elf32-littlearm common.o architecture: armv7, flags 0x0011: HAS_RELOC, HAS_SYMS start address 0x private flags = 500: [Version5 EABI] Sections: Idx Name Size VMA LMA File off Algn 0 .text 0034 2**0 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .data 0034 2**0 CONTENTS, ALLOC, LOAD, DATA 2 .bss 0034 2**0 ALLOC 3 .gnu.debuglto_.debug_info 10a5 0034 2**0 CONTENTS, RELOC, READONLY, EXCLUDE 4 .gnu.debuglto_.debug_abbrev 02a1 10d9 2**0 CONTENTS, READONLY, EXCLUDE 5 .gnu.debuglto_.debug_line 0214 137a 2**0 CONTENTS, READONLY, EXCLUDE 6 .gnu.debuglto_.debug_str 12e3 158e 2**0 CONTENTS, READONLY, EXCLUDE 7 .gnu.lto_.profile.69d69ac49136740e 000b 2871 2**0 CONTENTS, READONLY, EXCLUDE 8 .gnu.lto_.icf.69d69ac49136740e 007b 287c 2**0 CONTENTS, READONLY, EXCLUDE 9 .gnu.lto_.ipa_sra.69d69ac49136740e 008c 28f7 2**0 CONTENTS, READONLY, EXCLUDE 10 .gnu.lto_.inline.69d69ac49136740e 02bc 2983 2**0 CONTENTS, READONLY, EXCLUDE 11 .gnu.lto_.jmpfuncs.69d69ac49136740e 031c 2c3f 2**0 CONTENTS, READONLY, EXCLUDE 12 .gnu.lto_.pureconst.69d69ac49136740e 002f 2f5b 2**0 CONTENTS, READONLY, EXCLUDE 13 .gnu.lto_.lto.69d69ac49136740e 0008 2f8a 2**0 CONTENTS, READONLY, EXCLUDE 14 .gnu.lto_default_environment.154.69d69ac49136740e 0507 2f92 2**0 CONTENTS, READONLY, EXCLUDE 15 .gnu.lto_env_htab.155.69d69ac49136740e 0062 3499 2**0 CONTENTS, READONLY, EXCLUDE 16 .gnu.lto_env_get_yesno.156.69d69ac49136740e 0244 34fb 2**0 CONTENTS, READONLY, EXCLUDE 17 .gnu.lto_env_get_default.157.69d69ac49136740e 03dc 373f 2**0 CONTENTS, READONLY, EXCLUDE 18 .gnu.lto_env_set_default.158.69d69ac49136740e 04bf 3b1b 2**0 CONTENTS, READONLY, EXCLUDE 19 .gnu.lto_env_set_default_vars.159.69d69ac49136740e 01c1 3fda 2**0 CONTENTS, READONLY, EXCLUDE 20 .gnu.lto_env_import.160.69d69ac49136740e 0582 419b 2**0 CONTENTS, READONLY, EXCLUDE 21 .gnu.lto_env_check_redund.162.69d69ac49136740e 088a 471d 2**0 CONTENTS, READONLY, EXCLUDE 22 .gnu.lto_env_import_redund.163.69d69ac49136740e 0461 4fa7 2**0 CONTENTS, READONLY, EXCLUDE 23 .gnu.lto_env_export.164.69d69ac49136740e 03a0 5408 2**0
Re: [PATCH v3 1/2] lib: uuid: use RNG device if present
Hi
On 12/18/20 10:28 AM, matthias@kernel.org wrote:
From: Matthias Brugger
When calculating a random UUID we use a weak seed.
Use a RNG device if present to increase entropy.
Signed-off-by: Matthias Brugger
---
Changes in v3:
- use IS_ENABLED instead of #if
- use 4 byte for entropy
Changes in v2:
- fix dm_rng_read() parameters
- add missing include
lib/uuid.c | 21 ++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/lib/uuid.c b/lib/uuid.c
index e62d5ca264..23af2b4800 100644
--- a/lib/uuid.c
+++ b/lib/uuid.c
@@ -15,6 +15,8 @@
#include
#include
#include
+#include
+#include
/*
* UUID - Universally Unique IDentifier - 128 bits unique number.
@@ -249,9 +251,22 @@ void gen_rand_uuid(unsigned char *uuid_bin)
{
u32 ptr[4];
struct uuid *uuid = (struct uuid *)ptr;
- int i;
-
- srand(get_ticks() + rand());
+ int i, ret;
+ struct udevice *devp;
+ u32 randv = 0;
+
+ if (IS_ENABLED(CONFIG_DM_RNG)) {
+ ret = uclass_get_device(UCLASS_RNG, 0, );
+ if (ret) {
For information, as this patch already merged
here we need to test if ret == 0:
+ if (!ret) {
I push a patch to correct this test:
"lib: uuid: fix the test on RNG device presence"
http://patchwork.ozlabs.org/project/uboot/patch/20211022170544.1.Ib218a8a747f99cab44c3fac6af649f17f003b2e2@changeid/
+ ret = dm_rng_read(devp, , sizeof(randv));
+ if (ret < 0)
+ randv = 0;
+ }
+ }
+ if (randv)
+ srand(randv);
+ else
+ srand(get_ticks() + rand());
/* Set all fields randomly */
for (i = 0; i < 4; i++)
Regards
Patrick
Re: [PATCH v4 1/4] tools: Separate image types which depend on OpenSSL
On Fri, Oct 22, 2021 at 04:59:22PM +0200, Marek Behún wrote: > On Fri, 22 Oct 2021 12:09:19 +0200 > Heinrich Schuchardt wrote: > > > On 10/21/21 15:00, Marek Behún wrote: > > > BTW, wouldn't it be enough to simply imply TOOLS_LIBCRYPTO for mvebu > > > platform in Kconfig? > > > > > > > We should only use 'imply' for suggested settings and never for hard > > requirements. TOOLS_LIBCRYPTO already defaults to 'Y'. So implying it > > for mvebu would be redundant. > > > > In an OS distribution we only want to ship a single version of mkimage. > > So it is good to elimate symbol CONFIG_MXS. > > > > How mkimage is built should not depend on CONFIG_TOOLS_LIBCRYPTO. > > > > Tom wrote regarding this aspect in > > https://lists.denx.de/pipermail/u-boot/2021-September/460251.html: > > > > "if we're building a generically useful tool, we don't want another > > symbol for it." > > OK, so mkimage and dumpimage should be always generic and always > support all platforms, that makes sense, since the tools can be > installed as a distribution package. > > But I still think it should be possible to cripple these tools if the > developer wants to disable libcrypto due to embedded environment. This is probably the time to reach out to some of the distro folks to see how they would like to see things handled for "build the tools we need to package for the user" and also "build the binary for the platform". -- Tom signature.asc Description: PGP signature
[PATCH] lib: uuid: fix the test on RNG device presence
Correct the test on RNG device presence,when ret is equal to 0,
before to call dm_rng_read function.
Without this patch the RNG device is not used when present (when ret == 0)
or a data abort occurs in dm_rng_read when CONFIG_DM_RNG is activated but
the RNG device is not present in device tree (ret != 0 and devp = NULL).
Fixes: 92fdad28cfdf ("lib: uuid: use RNG device if present")
CC: Matthias Brugger
CC: Torsten Duwe
Signed-off-by: Patrick Delaunay
---
lib/uuid.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/uuid.c b/lib/uuid.c
index 67267c66a3..e4703dce2b 100644
--- a/lib/uuid.c
+++ b/lib/uuid.c
@@ -257,7 +257,7 @@ void gen_rand_uuid(unsigned char *uuid_bin)
if (IS_ENABLED(CONFIG_DM_RNG)) {
ret = uclass_get_device(UCLASS_RNG, 0, );
- if (ret) {
+ if (!ret) {
ret = dm_rng_read(devp, , sizeof(randv));
if (ret < 0)
randv = 0;
--
2.25.1
Re: [PATCH v4 1/4] tools: Separate image types which depend on OpenSSL
On Fri, 22 Oct 2021 12:09:19 +0200 Heinrich Schuchardt wrote: > On 10/21/21 15:00, Marek Behún wrote: > > BTW, wouldn't it be enough to simply imply TOOLS_LIBCRYPTO for mvebu > > platform in Kconfig? > > > > We should only use 'imply' for suggested settings and never for hard > requirements. TOOLS_LIBCRYPTO already defaults to 'Y'. So implying it > for mvebu would be redundant. > > In an OS distribution we only want to ship a single version of mkimage. > So it is good to elimate symbol CONFIG_MXS. > > How mkimage is built should not depend on CONFIG_TOOLS_LIBCRYPTO. > > Tom wrote regarding this aspect in > https://lists.denx.de/pipermail/u-boot/2021-September/460251.html: > > "if we're building a generically useful tool, we don't want another > symbol for it." OK, so mkimage and dumpimage should be always generic and always support all platforms, that makes sense, since the tools can be installed as a distribution package. But I still think it should be possible to cripple these tools if the developer wants to disable libcrypto due to embedded environment. Marek
Re: [PATCH v9 3/7] env: Allow U-Boot scripts to be placed in a .env file
On Fri, Oct 22, 2021 at 10:06:55AM +0200, Wolfgang Denk wrote: > Dear Simon, > > In message > you > wrote: > > > > > > i.e. > > > > var+=value > > > > appends value to var, while > > > > var\+=value > > > > sets variable with name "var+" > > > > My first preference is to disallow + at the end of an end var. Perhaps > > we can start printing a warning if people do it, for a few releases. > > This might seem to be a harmless change, but it is actually a > fundamental one. And it breaks backward compatiility. And all this > without need, as a list of alternatives have been suggested. > > > My distance second preference is what Marek has here, using a > > backslash to escape the + character. > > Actually this has the same problem, as the backslash is also a legal > character in a variable name: > > => setenv foo\\+ bar > => printenv foo\\+ > foo\+=bar > > > Yes, it was probably not a good idea not to restrict the allowed > character set when I implemented this stuff 21 years ago, but then > code size was critical - we had U-Boot running from 128 kB EPROM > (you remember these huge chips which were erased under UV light?). > > The fact is, '=' and NUL are the only characters that cannot be used > in a variable name. > > > > As for =+ ...while I can see how people might parse it (we are setting > > the var equal to what it has with an appending string) I think it is a > > terrible idea as it is just not what people expect. > > What do people expect? This is a totally new feature, so people will > use what they find in the documentation and in example code. > > > Also, putting the > > + after the = places (similarly unlikely) restrictions on the > > expression. > > There is a fundamental difference here. > > For the '+=' case, there is no way to escape the '+', as all > commonly used escapes are valid characters in the variable name, > too. > > With '=+', the '=' defines where the variable name ends, and from > here you can define your own rules as where the value part begins - > this is just a matter how you implement your parser. > > > The current format is basically the same as 'print'. So if I can't > > have the first preference, we could ensure that it prints a \ in the > > case that the var ends with + > > But '\' is a legal character in the variable name, too. Anything but > '=' and NUL is a legal char. And this makes escaping impossible: > > => setenv \'foo\\-\' foobar > => printenv \'foo\\-\' > 'foo\-'=foobar > > > > Also, I think that it would be better if spaces and tabs were allowed > > > to indent the .env file, i.e. > > > > > > var_a = 3 > > > var_bcd = 7 > > > > > > should set "var_a" to "3", "var_bcd" to "7". > > > > > > If special character are needed in either name or value, they could be > > > escaped and/or quoted. > > > > They are allowed in the value but are reduced to a single space in the > > front. We need this for multi-line strings (but I'm a bit worried > > about it). > > You mean this automatically insert a newline between parts? ugh... > I didn't realize this. Did I miss it in the documentation? > > > We could update it to skip any leading space after the = I think. > > So what if you need a leading space? > > > > I don't like spaces before the = though. It doesn't match the 'print' > > output (which has no space) and it is confusing: > > env print also does not add any spaces after the '='. > > > I think we need strict rules so it is easy for people to get exactly > > the env they want. > > Strict rules, proper documentation, and a set of examples. And sanity and restrictions introduced to our environment variables. The amount of "fun" things that were allowed by disallowing only NUL and = from names, and also allowing us to stay crazy tiny are just not relevant to where we are now. -- Tom signature.asc Description: PGP signature
Re: [PATCH v9 3/7] env: Allow U-Boot scripts to be placed in a .env file
On Fri, Oct 22, 2021 at 10:08:05AM +0200, Wolfgang Denk wrote: > Dear Tom, > > In message <20211021160311.GC3577824@bill-the-cat> you wrote: > > > > How bad does it make the parser look if we allow trailing + in variable > > names, by escaping them? It's seemingly the substantive objection at > > this point. > > Any escape character is also a legal name character. I am struggling to have a non-meme reaction to this. Perhaps the best step is just earlier on in the series note that variable names need to fit within the broadly and commonly used set of characters and assorted funny business you can do historically needs to be migrated. -- Tom signature.asc Description: PGP signature
Re: [PATCH v10 3/9] env: Allow U-Boot scripts to be placed in a .env file
On Fri, Oct 22, 2021 at 10:29:26AM +0200, Wolfgang Denk wrote: > Dear Simon, > > In message > <20211021210847.v10.3.Ie78bfbfca0d01d9cba501e127f446ec48e1f7afe@changeid> you > wrote: > > At present U-Boot environment variables, and thus scripts, are defined > > by CONFIG_EXTRA_ENV_SETTINGS. It is painful to add large amounts of text > > to this file and dealing with quoting and newlines is harder than it > > should be. It would be better if we could just type the script into a > > text file and have it included by U-Boot. > > > > Add a feature that brings in a .env file associated with the board > > config, if present. To use it, create a file in a board/ > > directory, typically called .env and controlled by the > > CONFIG_ENV_SOURCE_FILE option. > > > > The environment variables should be of the form "var=value". Values can > > extend to multiple lines. See the README under 'Environment Variables:' > > for more information and an example. > > The README does not contain this information as it has been moved > into doc/usage/environment.rst > > I think the documentation is lacking a hint that multiline > definitions will always be separated by spaces. > > > Also support += to allow variables to be appended to. This is needed when > > using the preprocessor. > > I cannot see what the preprocessor has to do with this feature. It > would be useful in any case, even without the preporcessor. > > > The documentation reads: > > "Variables can contain `+` characters but in the unlikely > event that you want to have a variable name ending in plus, put a backslash > before the `+` so that the script knows you are not adding to an existing > variable but assigning to a new one:: > > maximum\+=value > " > > However, '\' is also a legal character in a variable name (and > doubled backslashes or apostrophes etc. are legal, too), so > above line should actually set the environment variable "maximum\+" > to "value". I feel I should preface this with "I am cranky". Now I see that I can indeed do: => setenv foo\\bar baz => printenv foo\\bar foo\bar=baz on a system today. To what value, I know not. I can see how you write some fancy state machine set of scripts where you end up with "foo+bar+" needing to be set because you do a bunch of probing of things at run time and concatenate and ... there, we've got a variable that ends in + (and fwiw, sh says baz+ is a bad variable name, bash gets kinda funny with it). I don't see the value in allowing "\" in a variable name, nor can I make bash nor sh handle that. We can just disallow "\" in variable names. -- Tom signature.asc Description: PGP signature
[PATCH 8/8] pci: pci_mvebu: Fix comment about driver class name
This is a pci driver, not an eth driver.
Signed-off-by: Pali Rohár
Reviewed-by: Marek Behún
---
drivers/pci/pci_mvebu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/pci_mvebu.c b/drivers/pci/pci_mvebu.c
index b0c673d8c472..ed151a05a4bf 100644
--- a/drivers/pci/pci_mvebu.c
+++ b/drivers/pci/pci_mvebu.c
@@ -633,7 +633,7 @@ static int mvebu_pcie_bind(struct udevice *parent)
struct udevice *dev;
ofnode subnode;
- /* Lookup eth driver */
+ /* Lookup pci driver */
drv = lists_uclass_lookup(UCLASS_PCI);
if (!drv) {
puts("Cannot find PCI driver\n");
--
2.20.1
[PATCH 5/8] pci: pci_mvebu: Fix place of link up detection
PCI Bridge is always accessible also when link is down. So move detection
of link up from mvebu_pcie_of_to_plat() function to mvebu_pcie_valid_addr()
function which is used when accessing PCI config space.
Signed-off-by: Pali Rohár
Reviewed-by: Marek Behún
---
drivers/pci/pci_mvebu.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/pci/pci_mvebu.c b/drivers/pci/pci_mvebu.c
index 4b8e56f22dfa..40b8a57bbe1e 100644
--- a/drivers/pci/pci_mvebu.c
+++ b/drivers/pci/pci_mvebu.c
@@ -138,6 +138,10 @@ static bool mvebu_pcie_valid_addr(struct mvebu_pcie *pcie,
if (busno == pcie->first_busno && (dev != 0 || func != 0))
return false;
+ /* Access to other buses is possible when link is up */
+ if (busno != pcie->first_busno && !mvebu_pcie_link_up(pcie))
+ return false;
+
/* On secondary bus can be only one PCIe device */
if (busno == pcie->sec_busno && dev != 0)
return false;
@@ -369,9 +373,6 @@ static int mvebu_pcie_probe(struct udevice *dev)
struct pci_controller *hose = dev_get_uclass_priv(ctlr);
u32 reg;
- debug("%s: PCIe %d.%d - up, base %08x\n", __func__,
- pcie->port, pcie->lane, (u32)pcie->base);
-
/*
* Change Class Code of PCI Bridge device to PCI Bridge (0x600400)
* because default value is Memory controller (0x508000) which
@@ -603,13 +604,6 @@ static int mvebu_pcie_of_to_plat(struct udevice *dev)
if (ret < 0)
goto err;
- /* Check link and skip ports that have no link */
- if (!mvebu_pcie_link_up(pcie)) {
- debug("%s: %s - down\n", __func__, pcie->name);
- ret = -ENODEV;
- goto err;
- }
-
return 0;
err:
--
2.20.1
[PATCH 3/8] pci: pci_mvebu: Properly configure and use PCI Bridge (PCIe Root Port)
The mysterious "Memory controller" PCI device which is present in PCI
config space is improperly configured and crippled PCI Bridge which acts
as PCIe Root Port for endpoint PCIe card.
This PCI Bridge reports in PCI config space incorrect Class Code (Memory
Controller) and incorrect Header Type (Type 0). It looks like HW bug in
mvebu PCIe controller but apparently it can be changed via mvebu registers
to correct values.
The worst thing is that this PCI Bridge is crippled and its PCI config
registers in range 0x10-0x34 alias access to internal mvebu registers which
have different functionality as PCI Bridge registers. Moreover,
configuration of PCI primary and secondary bus numbers (registers 0x18
and 0x19) is done via totally different mvebu registers via totally strange
method and cannot be done via PCI Bridge config space.
Due to above fact about PCI config range 0x10-0x34, allocate a private
cfgcache[] buffer in the driver, to which PCI config access requests to
the 0x10-0x34 space will be redirected in mvebu_pcie_read_config() and
mvebu_pcie_write_config() functions. Function mvebu_pcie_write_config()
will also catch writes to PCI_PRIMARY_BUS (0x18) and PCI_SECONDARY_BUS
(0x19) registers and set PCI Bridge primary and secondary bus numbers via
mvebu's own method.
Also, Expansion ROM Base Address register (0x38) is available, but at
different offset 0x30. So recalculate register offset before accessing PCI
config space.
After these steps U-Boot sees working PCI Bridge and CONFIG_PCI_PNP code
can finally start enumerating all PCIe devices correctly, even with more
complicated PCI topology. So update also mvebu_pcie_valid_addr() function
to reflect state of the real device topology.
Each PCIe port is de-facto isolated and every PCI Bridge which is part of
PCIe Root Complex is also isolated, so put them on separate PCI buses as
(local) device 0.
U-Boot already supports enumerating separate PCI buses, real (HW) bus
number can be retrieved by "PCI_BUS(bdf) - dev_seq(bus)" code, so update
config read/write functions to properly handle more complicated tree
topologies (e.g. when a PCIe switch with multiple PCI buses is connected
to the PCIe port).
Local bus number and local device number on mvebu are used for determining
which config request type is used (Type 0 vs Type 1). On normal non-broken
PCIe hardware it is done by primary and secondary bus numbers. So correctly
translate settings between these numbers to ensure that correct config
requests are sent over the PCIe bus.
As bus numbers are correctly re-configured, it does not make sense to print
some initial bogus configuration during probe, so remove this debug code.
Signed-off-by: Pali Rohár
Reviewed-by: Marek Behún
---
drivers/pci/pci_mvebu.c | 199 +---
1 file changed, 164 insertions(+), 35 deletions(-)
diff --git a/drivers/pci/pci_mvebu.c b/drivers/pci/pci_mvebu.c
index 3991086e0d29..244dcc8fb050 100644
--- a/drivers/pci/pci_mvebu.c
+++ b/drivers/pci/pci_mvebu.c
@@ -36,6 +36,7 @@ DECLARE_GLOBAL_DATA_PTR;
#define PCIE_DEV_REV_OFF 0x0008
#define PCIE_BAR_LO_OFF(n)(0x0010 + ((n) << 3))
#define PCIE_BAR_HI_OFF(n)(0x0014 + ((n) << 3))
+#define PCIE_EXP_ROM_BAR_OFF 0x0030
#define PCIE_CAPAB_OFF 0x0060
#define PCIE_CTRL_STAT_OFF 0x0068
#define PCIE_HEADER_LOG_4_OFF 0x0128
@@ -52,9 +53,9 @@ DECLARE_GLOBAL_DATA_PTR;
#define PCIE_CONF_BUS(b) (((b) & 0xff) << 16)
#define PCIE_CONF_DEV(d) (((d) & 0x1f) << 11)
#define PCIE_CONF_FUNC(f) (((f) & 0x7) << 8)
-#define PCIE_CONF_ADDR(dev, reg) \
- (PCIE_CONF_BUS(PCI_BUS(dev)) | PCIE_CONF_DEV(PCI_DEV(dev))| \
-PCIE_CONF_FUNC(PCI_FUNC(dev)) | PCIE_CONF_REG(reg) | \
+#define PCIE_CONF_ADDR(b, d, f, reg) \
+ (PCIE_CONF_BUS(b) | PCIE_CONF_DEV(d)| \
+PCIE_CONF_FUNC(f) | PCIE_CONF_REG(reg) | \
PCIE_CONF_ADDR_EN)
#define PCIE_CONF_DATA_OFF 0x18fc
#define PCIE_MASK_OFF 0x1910
@@ -80,12 +81,13 @@ struct mvebu_pcie {
int devfn;
u32 lane_mask;
int first_busno;
- int local_dev;
+ int sec_busno;
char name[16];
unsigned int mem_target;
unsigned int mem_attr;
unsigned int io_target;
unsigned int io_attr;
+ u32 cfgcache[0x34 - 0x10];
};
/*
@@ -145,23 +147,18 @@ static inline struct mvebu_pcie *hose_to_pcie(struct
pci_controller *hose)
return container_of(hose, struct mvebu_pcie, hose);
}
-static int mvebu_pcie_valid_addr(struct mvebu_pcie *pcie, pci_dev_t bdf)
+static bool mvebu_pcie_valid_addr(struct mvebu_pcie *pcie,
+ int busno, int dev, int func)
{
- /*
-* There are two devices visible on local bus:
-* * on slot configured by function mvebu_pcie_set_local_dev_nr()
-* (by default this register is set to 0)
[PATCH 7/8] pci: pci_mvebu: Setup PCI controller to Root Complex mode
Root Complex should be the default mode, let's set it explicitly. Signed-off-by: Pali Rohár Reviewed-by: Marek Behún --- drivers/pci/pci_mvebu.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/pci/pci_mvebu.c b/drivers/pci/pci_mvebu.c index e43fa12d3819..b0c673d8c472 100644 --- a/drivers/pci/pci_mvebu.c +++ b/drivers/pci/pci_mvebu.c @@ -62,6 +62,7 @@ DECLARE_GLOBAL_DATA_PTR; #define PCIE_MASK_ENABLE_INTS (0xf << 24) #define PCIE_CTRL_OFF 0x1a00 #define PCIE_CTRL_X1_MODE BIT(0) +#define PCIE_CTRL_RC_MODE BIT(1) #define PCIE_STAT_OFF 0x1a04 #define PCIE_STAT_BUS (0xff << 8) #define PCIE_STAT_DEV (0x1f << 16) @@ -373,6 +374,11 @@ static int mvebu_pcie_probe(struct udevice *dev) struct pci_controller *hose = dev_get_uclass_priv(ctlr); u32 reg; + /* Setup PCIe controller to Root Complex mode */ + reg = readl(pcie->base + PCIE_CTRL_OFF); + reg |= PCIE_CTRL_RC_MODE; + writel(reg, pcie->base + PCIE_CTRL_OFF); + /* * Change Class Code of PCI Bridge device to PCI Bridge (0x600400) * because default value is Memory controller (0x508000) which -- 2.20.1
[PATCH 6/8] pci: pci_mvebu: Do not automatically enable bus mastering on PCI Bridge
Now that PCI Bridge is working, U-Boot's CONFIG_PCI_PNP code automatically enables memory access and bus mastering when it is needed. So do not prematurely enable memory access and bus mastering. Signed-off-by: Pali Rohár Reviewed-by: Marek Behún --- drivers/pci/pci_mvebu.c | 8 1 file changed, 8 deletions(-) diff --git a/drivers/pci/pci_mvebu.c b/drivers/pci/pci_mvebu.c index 40b8a57bbe1e..e43fa12d3819 100644 --- a/drivers/pci/pci_mvebu.c +++ b/drivers/pci/pci_mvebu.c @@ -451,14 +451,6 @@ static int mvebu_pcie_probe(struct udevice *dev) /* Setup windows and configure host bridge */ mvebu_pcie_setup_wins(pcie); - /* Master + slave enable. */ - reg = readl(pcie->base + PCIE_CMD_OFF); - reg |= PCI_COMMAND_MEMORY; - reg |= PCI_COMMAND_IO; - reg |= PCI_COMMAND_MASTER; - reg |= BIT(10); /* disable interrupts */ - writel(reg, pcie->base + PCIE_CMD_OFF); - /* PCI memory space */ pci_set_region(hose->regions + 0, pcie->mem.start, pcie->mem.start, PCIE_MEM_SIZE, PCI_REGION_MEM); -- 2.20.1
[PATCH 0/8] pci: pci_mvebu: Fix access to config space and PCIe Root Port
This patch series fixes access to config space and fixes issues with the mysterious "Memory controller" PCI device (which is PCIe Root Port). Tested on Armada 385 Turris Omnia device which has 3 mPCIe slots. PCIe Root Port device is available for each slot on separate bus and has PCI Bridge class code as required by PCIe base specifications. => pci 0 Scanning PCI devices on bus 0 BusDevFun VendorId DeviceId Device Class Sub-Class _ 00.00.00 0x11ab 0x6820 Bridge device 0x04 => pci 1 Scanning PCI devices on bus 1 BusDevFun VendorId DeviceId Device Class Sub-Class _ 01.00.00 0x168c 0x003c Network controller 0x80 => pci 2 Scanning PCI devices on bus 2 BusDevFun VendorId DeviceId Device Class Sub-Class _ 02.00.00 0x11ab 0x6820 Bridge device 0x04 => pci 3 Scanning PCI devices on bus 3 BusDevFun VendorId DeviceId Device Class Sub-Class _ 03.00.00 0x168c 0x003c Network controller 0x80 => pci 4 Scanning PCI devices on bus 4 BusDevFun VendorId DeviceId Device Class Sub-Class _ 04.00.00 0x11ab 0x6820 Bridge device 0x04 => pci 5 Scanning PCI devices on bus 5 BusDevFun VendorId DeviceId Device Class Sub-Class _ 05.00.00 0x168c 0x002e Network controller 0x80 => pci 6 No such bus => U-Boot command "pci display.b 0.0.0 0 200" will display config space of the first PCIe Root Port device with the Type 1 PCI header as required by PCIe base specification. => pci display.b 0.0.0 0 200 : ab 11 20 68 07 00 10 00 04 00 04 06 00 00 01 00 0010: 00 00 00 00 00 00 00 00 00 01 01 00 01 f1 00 00 0020: 00 c0 20 c0 01 10 01 00 00 00 00 00 00 00 00 00 0030: 10 f1 0f f1 40 00 00 00 00 00 00 00 00 01 00 00 0040: 01 50 03 06 00 00 00 00 00 00 00 00 00 00 00 00 0050: 05 60 80 00 00 00 00 00 00 00 00 00 00 00 00 00 0060: 10 00 42 00 80 80 00 00 00 20 00 00 12 ac 07 00 0070: 00 00 11 10 00 00 00 00 00 00 40 00 00 00 00 00 0080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0090: 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0100: 01 00 01 00 00 00 00 00 00 00 00 00 10 00 06 00 0110: 00 00 00 00 00 20 00 00 00 00 00 00 01 00 00 4a 0120: 04 00 00 01 00 01 08 01 02 80 00 00 00 00 00 00 0130: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0140: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0150: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0160: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0170: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0190: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Pali Rohár (8): pci: pci_mvebu: Fix write_config() with PCI_SIZE_8 or PCI_SIZE_16 pci: pci_mvebu: Fix read_config() with PCI_SIZE_8 or PCI_SIZE_16 pci: pci_mvebu: Properly configure and use PCI Bridge (PCIe Root Port) pci: pci_mvebu: Remove unused functions pci: pci_mvebu: Fix place of link up detection pci: pci_mvebu: Do not automatically enable bus mastering on PCI Bridge pci: pci_mvebu: Setup PCI controller to Root Complex mode pci: pci_mvebu: Fix comment about driver class name drivers/pci/pci_mvebu.c | 275 +--- 1 file changed, 202 insertions(+), 73 deletions(-) -- 2.20.1
[PATCH 4/8] pci: pci_mvebu: Remove unused functions
Functions mvebu_pcie_get_local_bus_nr() and mvebu_pcie_get_local_dev_nr()
are not used, so remove them.
Signed-off-by: Pali Rohár
Reviewed-by: Marek Behún
---
drivers/pci/pci_mvebu.c | 16
1 file changed, 16 deletions(-)
diff --git a/drivers/pci/pci_mvebu.c b/drivers/pci/pci_mvebu.c
index 244dcc8fb050..4b8e56f22dfa 100644
--- a/drivers/pci/pci_mvebu.c
+++ b/drivers/pci/pci_mvebu.c
@@ -126,22 +126,6 @@ static void mvebu_pcie_set_local_dev_nr(struct mvebu_pcie
*pcie, int devno)
writel(stat, pcie->base + PCIE_STAT_OFF);
}
-static int mvebu_pcie_get_local_bus_nr(struct mvebu_pcie *pcie)
-{
- u32 stat;
-
- stat = readl(pcie->base + PCIE_STAT_OFF);
- return (stat & PCIE_STAT_BUS) >> 8;
-}
-
-static int mvebu_pcie_get_local_dev_nr(struct mvebu_pcie *pcie)
-{
- u32 stat;
-
- stat = readl(pcie->base + PCIE_STAT_OFF);
- return (stat & PCIE_STAT_DEV) >> 16;
-}
-
static inline struct mvebu_pcie *hose_to_pcie(struct pci_controller *hose)
{
return container_of(hose, struct mvebu_pcie, hose);
--
2.20.1
[PATCH 2/8] pci: pci_mvebu: Fix read_config() with PCI_SIZE_8 or PCI_SIZE_16
When reading 8 or 16 bits from config space, use appropriate readb() or
readw() calls. This ensures that PCIe controller does not read more bits
from endpoint card as asked by read_config() function.
Technically there should not be an issue with reading data from config
space which are not later used as there are no clear-by-read registers.
But it is better to use correct read operation based on requested size.
Signed-off-by: Pali Rohár
Reviewed-by: Marek Behún
---
drivers/pci/pci_mvebu.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/pci_mvebu.c b/drivers/pci/pci_mvebu.c
index 8175511514ab..3991086e0d29 100644
--- a/drivers/pci/pci_mvebu.c
+++ b/drivers/pci/pci_mvebu.c
@@ -184,9 +184,22 @@ static int mvebu_pcie_read_config(const struct udevice
*bus, pci_dev_t bdf,
writel(PCIE_CONF_ADDR(bdf, offset), pcie->base + PCIE_CONF_ADDR_OFF);
/* read data */
- data = readl(pcie->base + PCIE_CONF_DATA_OFF);
+ switch (size) {
+ case PCI_SIZE_8:
+ data = readb(pcie->base + PCIE_CONF_DATA_OFF + (offset & 3));
+ break;
+ case PCI_SIZE_16:
+ data = readw(pcie->base + PCIE_CONF_DATA_OFF + (offset & 2));
+ break;
+ case PCI_SIZE_32:
+ data = readl(pcie->base + PCIE_CONF_DATA_OFF);
+ break;
+ default:
+ return -EINVAL;
+ }
+
debug("(addr,size,val)=(0x%04x, %d, 0x%08x)\n", offset, size, data);
- *valuep = pci_conv_32_to_size(data, offset, size);
+ *valuep = data;
return 0;
}
--
2.20.1
[PATCH 1/8] pci: pci_mvebu: Fix write_config() with PCI_SIZE_8 or PCI_SIZE_16
Current implementation of write_config() is broken for PCI_SIZE_8 or
PCI_SIZE_16 as it always uses writel(), which means that write operation
is always 32-bit, so upper 24 bits for PCI_SIZE_8 and upper 16 bits for
PCI_SIZE_16 are cleared.
Fix this by using writeb() and writew(), respectively.
Signed-off-by: Pali Rohár
Reviewed-by: Marek Behún
---
drivers/pci/pci_mvebu.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/pci_mvebu.c b/drivers/pci/pci_mvebu.c
index 0c1d7cd770f1..8175511514ab 100644
--- a/drivers/pci/pci_mvebu.c
+++ b/drivers/pci/pci_mvebu.c
@@ -211,8 +211,19 @@ static int mvebu_pcie_write_config(struct udevice *bus,
pci_dev_t bdf,
writel(PCIE_CONF_ADDR(bdf, offset), pcie->base + PCIE_CONF_ADDR_OFF);
/* write data */
- data = pci_conv_size_to_32(0, value, offset, size);
- writel(data, pcie->base + PCIE_CONF_DATA_OFF);
+ switch (size) {
+ case PCI_SIZE_8:
+ writeb(value, pcie->base + PCIE_CONF_DATA_OFF + (offset & 3));
+ break;
+ case PCI_SIZE_16:
+ writew(value, pcie->base + PCIE_CONF_DATA_OFF + (offset & 2));
+ break;
+ case PCI_SIZE_32:
+ writel(value, pcie->base + PCIE_CONF_DATA_OFF);
+ break;
+ default:
+ return -EINVAL;
+ }
return 0;
}
--
2.20.1
Re: [PATCH v9 3/7] env: Allow U-Boot scripts to be placed in a .env file
Hello Wolfgang, On Fri, 22 Oct 2021 10:06:55 +0200 Wolfgang Denk wrote: > For the '+=' case, there is no way to escape the '+', as all > commonly used escapes are valid characters in the variable name, > too. We can define that backslash is to be also escaped if it is to be used as variable name: weird_var\\\+=abcd I still think it is far more intuitive than =+. Anyway, IMO '+' as the last character in varname is a extreme corner case; I think that no one sane actually uses it. But even if they did, Simon's patches do not break it. Simon's patches only disallow it in board environment definition during compilation. I think it is a completely reasonable thing to diallow board maintainers (i.e. only U-Boot developers, not users) from using such construction. Marek
[PATCH 14/14] env: Use static_assert() to check if default_environment is too large
From: Marek Behún
Check sizeof(default_environment) against ENV_SIZE in a static_assert()
instead of runtime.
Only check if !USE_HOSTCC (for in fw_env tool ENV_SIZE expands to a
variable, and cannot be checked statically) nad
!DEFAULT_ENV_INSTANCE_EMBEDDED, for in that case the default_environment
variable is not set.
Signed-off-by: Marek Behún
---
env/common.c | 5 -
include/env_default.h | 6 ++
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/env/common.c b/env/common.c
index 664d2e688e..99729ca002 100644
--- a/env/common.c
+++ b/env/common.c
@@ -247,11 +247,6 @@ char *env_get_default(const char *name)
void env_set_default(const char *s, int flags)
{
- if (sizeof(default_environment) > ENV_SIZE) {
- puts("*** Error - default environment is too large\n\n");
- return;
- }
-
if (s) {
if ((flags & H_INTERACTIVE) == 0) {
printf("*** Warning - %s, "
diff --git a/include/env_default.h b/include/env_default.h
index a6724719ec..23430dc70d 100644
--- a/include/env_default.h
+++ b/include/env_default.h
@@ -121,3 +121,9 @@ const char default_environment[] = {
}
#endif
};
+
+#if !defined(USE_HOSTCC) && !defined(DEFAULT_ENV_INSTANCE_EMBEDDED)
+#include
+static_assert(sizeof(default_environment) <= ENV_SIZE,
+ "Default environment is too large");
+#endif
--
2.32.0
[PATCH 13/14] env: Always use char for default_environment
From: Marek Behún
Sometimes we use uchar and sometimes char for the default environment
array. By always using char, we can get rid of some explicit casts.
Signed-off-by: Marek Behún
---
board/Marvell/mvebu_armada-37xx/board.c | 2 +-
env/common.c| 6 +++---
include/env_default.h | 4 ++--
include/env_internal.h | 4 ++--
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/board/Marvell/mvebu_armada-37xx/board.c
b/board/Marvell/mvebu_armada-37xx/board.c
index 2de9c2ac17..d7b6ecafbf 100644
--- a/board/Marvell/mvebu_armada-37xx/board.c
+++ b/board/Marvell/mvebu_armada-37xx/board.c
@@ -87,7 +87,7 @@ int board_init(void)
#ifdef CONFIG_BOARD_LATE_INIT
int board_late_init(void)
{
- char *ptr = (char *)_environment[0];
+ char *ptr = _environment[0];
struct udevice *dev;
struct mmc *mmc_dev;
bool ddr4, emmc;
diff --git a/env/common.c b/env/common.c
index db213b7748..664d2e688e 100644
--- a/env/common.c
+++ b/env/common.c
@@ -162,7 +162,7 @@ int env_get_f(const char *name, char *buf, unsigned len)
name_len = strlen(name);
if (gd->env_valid == ENV_INVALID)
- env = (const char *)default_environment;
+ env = default_environment;
else
env = (const char *)gd->env_addr;
@@ -264,7 +264,7 @@ void env_set_default(const char *s, int flags)
}
flags |= H_DEFAULT;
- if (himport_r(_htab, (char *)default_environment,
+ if (himport_r(_htab, default_environment,
sizeof(default_environment), '\0', flags, 0,
0, NULL) == 0)
pr_err("## Error: Environment import failed: errno = %d\n",
@@ -283,7 +283,7 @@ int env_set_default_vars(int nvars, char * const vars[],
int flags)
* (and use \0 as a separator)
*/
flags |= H_NOCLEAR | H_DEFAULT;
- return himport_r(_htab, (const char *)default_environment,
+ return himport_r(_htab, default_environment,
sizeof(default_environment), '\0',
flags, 0, nvars, vars);
}
diff --git a/include/env_default.h b/include/env_default.h
index 66e203eb6e..a6724719ec 100644
--- a/include/env_default.h
+++ b/include/env_default.h
@@ -20,9 +20,9 @@ env_t embedded_environment __UBOOT_ENV_SECTION__(environment)
= {
#elif defined(DEFAULT_ENV_INSTANCE_STATIC)
static char default_environment[] = {
#elif defined(DEFAULT_ENV_IS_RW)
-uchar default_environment[] = {
+char default_environment[] = {
#else
-const uchar default_environment[] = {
+const char default_environment[] = {
#endif
#ifndef CONFIG_USE_DEFAULT_ENV_FILE
#ifdef CONFIG_ENV_CALLBACK_LIST_DEFAULT
diff --git a/include/env_internal.h b/include/env_internal.h
index b7bddcb00d..f74927cd64 100644
--- a/include/env_internal.h
+++ b/include/env_internal.h
@@ -112,9 +112,9 @@ extern env_t embedded_environment;
#endif /* ENV_IS_EMBEDDED */
#ifdef DEFAULT_ENV_IS_RW
-extern unsigned char default_environment[];
+extern char default_environment[];
#else
-extern const unsigned char default_environment[];
+extern const char default_environment[];
#endif
#ifndef DO_DEPS_ONLY
--
2.32.0
[PATCH 12/14] board: freescale: various boards: Let env subsystem set gd->env_addr
From: Marek Behún
Various freescale boards set gd->env_addr to default_environment in
board_init(), conditional on CONFIG_ENV_IS_NOWHERE, but this is
redundant, since it is done by env_init() before board_init() is called.
Let the env subsystem handle this.
Signed-off-by: Marek Behún
Cc: Ramon Fried
Cc: Priyanka Jain
Cc: Mian Yousaf Kaukab
---
board/freescale/ls1012afrdm/ls1012afrdm.c | 4
board/freescale/ls1012aqds/ls1012aqds.c | 4
board/freescale/ls1012ardb/ls1012ardb.c | 4
board/freescale/ls1028a/ls1028a.c | 4
board/freescale/ls1088a/ls1088a.c | 4
board/freescale/ls2080aqds/ls2080aqds.c | 3 ---
board/freescale/ls2080ardb/ls2080ardb.c | 3 ---
board/freescale/lx2160a/lx2160a.c | 3 ---
8 files changed, 29 deletions(-)
diff --git a/board/freescale/ls1012afrdm/ls1012afrdm.c
b/board/freescale/ls1012afrdm/ls1012afrdm.c
index 6473ee0572..5dd19cfcd9 100644
--- a/board/freescale/ls1012afrdm/ls1012afrdm.c
+++ b/board/freescale/ls1012afrdm/ls1012afrdm.c
@@ -172,10 +172,6 @@ int board_init(void)
if (current_el() == 3)
out_le32(>ctrl_ord, CCI400_CTRLORD_EN_BARRIER);
-#ifdef CONFIG_ENV_IS_NOWHERE
- gd->env_addr = (ulong)_environment[0];
-#endif
-
#ifdef CONFIG_FSL_CAAM
sec_init();
#endif
diff --git a/board/freescale/ls1012aqds/ls1012aqds.c
b/board/freescale/ls1012aqds/ls1012aqds.c
index 6e21040601..68578e81a5 100644
--- a/board/freescale/ls1012aqds/ls1012aqds.c
+++ b/board/freescale/ls1012aqds/ls1012aqds.c
@@ -150,10 +150,6 @@ int board_init(void)
erratum_a010315();
#endif
-#ifdef CONFIG_ENV_IS_NOWHERE
- gd->env_addr = (ulong)_environment[0];
-#endif
-
#ifdef CONFIG_FSL_CAAM
sec_init();
#endif
diff --git a/board/freescale/ls1012ardb/ls1012ardb.c
b/board/freescale/ls1012ardb/ls1012ardb.c
index 62e8af48cf..064fb4d39f 100644
--- a/board/freescale/ls1012ardb/ls1012ardb.c
+++ b/board/freescale/ls1012ardb/ls1012ardb.c
@@ -173,10 +173,6 @@ int board_init(void)
erratum_a010315();
#endif
-#ifdef CONFIG_ENV_IS_NOWHERE
- gd->env_addr = (ulong)_environment[0];
-#endif
-
#ifdef CONFIG_FSL_CAAM
sec_init();
#endif
diff --git a/board/freescale/ls1028a/ls1028a.c
b/board/freescale/ls1028a/ls1028a.c
index 461c571b36..486a544d35 100644
--- a/board/freescale/ls1028a/ls1028a.c
+++ b/board/freescale/ls1028a/ls1028a.c
@@ -73,10 +73,6 @@ u32 get_lpuart_clk(void)
int board_init(void)
{
-#ifdef CONFIG_ENV_IS_NOWHERE
- gd->env_addr = (ulong)_environment[0];
-#endif
-
#ifdef CONFIG_FSL_CAAM
sec_init();
#endif
diff --git a/board/freescale/ls1088a/ls1088a.c
b/board/freescale/ls1088a/ls1088a.c
index 2f422634d5..7046fbaeb5 100644
--- a/board/freescale/ls1088a/ls1088a.c
+++ b/board/freescale/ls1088a/ls1088a.c
@@ -810,10 +810,6 @@ int board_init(void)
select_i2c_ch_pca9547(I2C_MUX_CH_DEFAULT, 0);
board_retimer_init();
-#ifdef CONFIG_ENV_IS_NOWHERE
- gd->env_addr = (ulong)_environment[0];
-#endif
-
#if defined(CONFIG_TARGET_LS1088ARDB) && defined(CONFIG_FSL_MC_ENET)
/* invert AQR105 IRQ pins polarity */
out_le32(irq_ccsr + IRQCR_OFFSET / 4, AQR105_IRQ_MASK);
diff --git a/board/freescale/ls2080aqds/ls2080aqds.c
b/board/freescale/ls2080aqds/ls2080aqds.c
index 62658c4702..2f0139edef 100644
--- a/board/freescale/ls2080aqds/ls2080aqds.c
+++ b/board/freescale/ls2080aqds/ls2080aqds.c
@@ -211,9 +211,6 @@ int board_init(void)
FSL_QIXIS_BRDCFG9_QSPI);
#endif
-#ifdef CONFIG_ENV_IS_NOWHERE
- gd->env_addr = (ulong)_environment[0];
-#endif
select_i2c_ch_pca9547(I2C_MUX_CH_DEFAULT, 0);
#ifdef CONFIG_RTC_ENABLE_32KHZ_OUTPUT
diff --git a/board/freescale/ls2080ardb/ls2080ardb.c
b/board/freescale/ls2080ardb/ls2080ardb.c
index 58b852383e..bf660a8e65 100644
--- a/board/freescale/ls2080ardb/ls2080ardb.c
+++ b/board/freescale/ls2080ardb/ls2080ardb.c
@@ -281,9 +281,6 @@ int board_init(void)
init_final_memctl_regs();
-#ifdef CONFIG_ENV_IS_NOWHERE
- gd->env_addr = (ulong)_environment[0];
-#endif
select_i2c_ch_pca9547(I2C_MUX_CH_DEFAULT, 0);
#ifdef CONFIG_FSL_QIXIS
diff --git a/board/freescale/lx2160a/lx2160a.c
b/board/freescale/lx2160a/lx2160a.c
index e61289d228..bd5abb677a 100644
--- a/board/freescale/lx2160a/lx2160a.c
+++ b/board/freescale/lx2160a/lx2160a.c
@@ -588,9 +588,6 @@ int board_init(void)
#if defined(CONFIG_FSL_MC_ENET) && defined(CONFIG_TARGET_LX2160ARDB)
u32 __iomem *irq_ccsr = (u32 __iomem *)ISC_BASE;
#endif
-#ifdef CONFIG_ENV_IS_NOWHERE
- gd->env_addr = (ulong)_environment[0];
-#endif
select_i2c_ch_pca9547(I2C_MUX_CH_DEFAULT, 0);
--
2.32.0
[PATCH 11/14] board: synquacer: developerbox: Don't set gd->env_addr to default_environment
From: Marek Behún
This board sets gd->env_addr to default_environment in board_init(), but
the board has environment in SPI flash according to defconfig. Let the
env API handle environment automatically.
Signed-off-by: Marek Behún
Cc: Masami Hiramatsu
---
board/socionext/developerbox/developerbox.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/board/socionext/developerbox/developerbox.c
b/board/socionext/developerbox/developerbox.c
index 9552bfcdc3..31b1349514 100644
--- a/board/socionext/developerbox/developerbox.c
+++ b/board/socionext/developerbox/developerbox.c
@@ -82,8 +82,6 @@ int board_init(void)
{
gd->bd->bi_boot_params = CONFIG_SYS_LOAD_ADDR + LOAD_OFFSET;
- gd->env_addr = (ulong)_environment[0];
-
synquacer_setup_scbm_smmu();
return 0;
--
2.32.0
[PATCH 10/14] env: flash: Cosmetic fix
From: Marek Behún Change tab to space in env_flash_init(). Signed-off-by: Marek Behún --- env/flash.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/env/flash.c b/env/flash.c index 77d4c030a5..b928880502 100644 --- a/env/flash.c +++ b/env/flash.c @@ -229,7 +229,7 @@ static int env_flash_init(void) return 0; } - gd->env_valid = ENV_INVALID; + gd->env_valid = ENV_INVALID; return 0; } #endif -- 2.32.0
[PATCH 08/14] env: nowhere: Cosmetic fix
From: Marek Behún
Use spaces instead of tabs in assignments, since there are no lines to
align assignment values to.
Signed-off-by: Marek Behún
---
env/nowhere.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/env/nowhere.c b/env/nowhere.c
index dc93b6f2e4..9ebc357dbd 100644
--- a/env/nowhere.c
+++ b/env/nowhere.c
@@ -22,7 +22,7 @@ DECLARE_GLOBAL_DATA_PTR;
*/
static int env_nowhere_init(void)
{
- gd->env_valid = ENV_INVALID;
+ gd->env_valid = ENV_INVALID;
return 0;
}
@@ -37,7 +37,7 @@ static int env_nowhere_load(void)
if (!IS_ENABLED(CONFIG_SPL_BUILD))
env_set_default(NULL, 0);
- gd->env_valid = ENV_INVALID;
+ gd->env_valid = ENV_INVALID;
return 0;
}
--
2.32.0
[PATCH 07/14] env: nowhere: Let generic env_init() assign default environment
From: Marek Behún
env_nowhere_init() assigns default environment if ENV_INVALID, but this
is done in the generic env_init() function, which calls this
initializer, so drop it from here.
Signed-off-by: Marek Behún
---
env/nowhere.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/env/nowhere.c b/env/nowhere.c
index 1fcf503453..dc93b6f2e4 100644
--- a/env/nowhere.c
+++ b/env/nowhere.c
@@ -22,7 +22,6 @@ DECLARE_GLOBAL_DATA_PTR;
*/
static int env_nowhere_init(void)
{
- gd->env_addr= (ulong)_environment[0];
gd->env_valid = ENV_INVALID;
return 0;
--
2.32.0
[PATCH 06/14] env: nvram: Cosmetic fix in env_nvram_init()
From: Marek Behún
Use spaces consistently in assignments instead of tabs.
Signed-off-by: Marek Behún
---
env/nvram.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/env/nvram.c b/env/nvram.c
index 297573c4ed..fb265235af 100644
--- a/env/nvram.c
+++ b/env/nvram.c
@@ -87,10 +87,10 @@ static int env_nvram_init(void)
nvram_read(data, CONFIG_ENV_ADDR + sizeof(ulong), ENV_SIZE);
if (crc32(0, data, ENV_SIZE) == crc) {
- gd->env_addr= (ulong)CONFIG_ENV_ADDR + sizeof(long);
+ gd->env_addr = (ulong)CONFIG_ENV_ADDR + sizeof(long);
#else
if (crc32(0, env_ptr->data, ENV_SIZE) == env_ptr->crc) {
- gd->env_addr= (ulong)_ptr->data;
+ gd->env_addr = (ulong)_ptr->data;
#endif
gd->env_valid = ENV_VALID;
} else {
--
2.32.0
[PATCH 09/14] env: flash: Let generic env_init() assign default environment
From: Marek Behún
env_flash_init() (both implementations) assigns default environment if
ENV_INVALID, but this is done in the generic env_init() function, which
calls this initializer, so drop it from here.
Signed-off-by: Marek Behún
---
env/flash.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/env/flash.c b/env/flash.c
index ebee9069e4..77d4c030a5 100644
--- a/env/flash.c
+++ b/env/flash.c
@@ -77,7 +77,6 @@ static int env_flash_init(void)
uchar flag1 = flash_addr->flags;
uchar flag2 = flash_addr_new->flags;
- ulong addr_default = (ulong)_environment[0];
ulong addr1 = (ulong)&(flash_addr->data);
ulong addr2 = (ulong)&(flash_addr_new->data);
@@ -92,7 +91,6 @@ static int env_flash_init(void)
gd->env_addr= addr2;
gd->env_valid = ENV_VALID;
} else if (!crc1_ok && !crc2_ok) {
- gd->env_addr= addr_default;
gd->env_valid = ENV_INVALID;
} else if (flag1 == ENV_REDUND_ACTIVE &&
flag2 == ENV_REDUND_OBSOLETE) {
@@ -231,7 +229,6 @@ static int env_flash_init(void)
return 0;
}
- gd->env_addr= (ulong)_environment[0];
gd->env_valid = ENV_INVALID;
return 0;
}
--
2.32.0
[PATCH 05/14] env: nvram: Let generic env_init() assign default environment
From: Marek Behún
env_nvram_init() assigns default environment if ENV_INVALID, but this is
done in the generic env_init() function, which calls this initializer,
so drop it from here.
Signed-off-by: Marek Behún
---
env/nvram.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/env/nvram.c b/env/nvram.c
index 261b31edfb..297573c4ed 100644
--- a/env/nvram.c
+++ b/env/nvram.c
@@ -94,8 +94,7 @@ static int env_nvram_init(void)
#endif
gd->env_valid = ENV_VALID;
} else {
- gd->env_addr= (ulong)_environment[0];
- gd->env_valid = ENV_INVALID;
+ gd->env_valid = ENV_INVALID;
}
return 0;
--
2.32.0
[PATCH 04/14] env: nand: Put ENV_INVALID into gd->env_valid if default environment
From: Marek Behún env_nand_init() says the environment is valid even if it is assigning default environment due to not being able to access nand pre-reloaction (determined by macro values). Change this to ENV_INVALID and let the generic env_init() function, which calls this initializer, assign the default environment. Signed-off-by: Marek Behún --- env/nand.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/env/nand.c b/env/nand.c index be82e97d69..21aa367d5b 100644 --- a/env/nand.c +++ b/env/nand.c @@ -107,8 +107,7 @@ static int env_nand_init(void) gd->env_addr = (ulong)env_ptr->data; #else /* ENV_IS_EMBEDDED || CONFIG_NAND_ENV_DST */ - gd->env_addr= (ulong)_environment[0]; - gd->env_valid = ENV_VALID; + gd->env_valid = ENV_INVALID; #endif /* ENV_IS_EMBEDDED || CONFIG_NAND_ENV_DST */ return 0; -- 2.32.0
[PATCH 03/14] env: sf: Put ENV_INVALID into gd->env_valid on CRC failure
From: Marek Behún
env_sf_init_addr() says the environment is valid even if it is assigning
default environment due to CRC failure. Change this to ENV_INVALID and
let the generic env_init() function, which calls this initializer,
assign the default environment.
Signed-off-by: Marek Behún
---
env/sf.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/env/sf.c b/env/sf.c
index c251d076d7..6a4bb756f0 100644
--- a/env/sf.c
+++ b/env/sf.c
@@ -341,8 +341,7 @@ static int env_sf_init_addr(void)
gd->env_addr = (ulong)&(env_ptr->data);
gd->env_valid = ENV_VALID;
} else {
- gd->env_addr = (ulong)_environment[0];
- gd->env_valid = ENV_VALID;
+ gd->env_valid = ENV_INVALID;
}
return 0;
--
2.32.0
[PATCH 01/14] env: sf: Cosmetic fix in env_sf_init_addr()
From: Marek Behún
In the if clause we use tabs and in the else clause spaces. Let's use
spaces in the if clause too.
Signed-off-by: Marek Behún
---
env/sf.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/env/sf.c b/env/sf.c
index e4b7ca9e04..4096e18387 100644
--- a/env/sf.c
+++ b/env/sf.c
@@ -338,8 +338,8 @@ static int env_sf_init_addr(void)
env_t *env_ptr = (env_t *)env_sf_get_env_addr();
if (crc32(0, env_ptr->data, ENV_SIZE) == env_ptr->crc) {
- gd->env_addr= (ulong)&(env_ptr->data);
- gd->env_valid = 1;
+ gd->env_addr = (ulong)&(env_ptr->data);
+ gd->env_valid = 1;
} else {
gd->env_addr = (ulong)_environment[0];
gd->env_valid = 1;
--
2.32.0
[PATCH 00/14] Some more env fixes
From: Marek Behún Hello Tom, Simon and others, here are some various fixes for env. More are to follow after this, the code is horrible and I want to implement something there. Marek Behún (14): env: sf: Cosmetic fix in env_sf_init_addr() env: sf: Use ENV_VALID enum names instead of literals env: sf: Put ENV_INVALID into gd->env_valid on CRC failure env: nand: Put ENV_INVALID into gd->env_valid if default environment env: nvram: Let generic env_init() assign default environment env: nvram: Cosmetic fix in env_nvram_init() env: nowhere: Let generic env_init() assign default environment env: nowhere: Cosmetic fix env: flash: Let generic env_init() assign default environment env: flash: Cosmetic fix board: synquacer: developerbox: Don't set gd->env_addr to default_environment board: freescale: various boards: Let env subsystem set gd->env_addr env: Always use char for default_environment env: Use static_assert() to check if default_environment is too large board/Marvell/mvebu_armada-37xx/board.c | 2 +- board/freescale/ls1012afrdm/ls1012afrdm.c | 4 board/freescale/ls1012aqds/ls1012aqds.c | 4 board/freescale/ls1012ardb/ls1012ardb.c | 4 board/freescale/ls1028a/ls1028a.c | 4 board/freescale/ls1088a/ls1088a.c | 4 board/freescale/ls2080aqds/ls2080aqds.c | 3 --- board/freescale/ls2080ardb/ls2080ardb.c | 3 --- board/freescale/lx2160a/lx2160a.c | 3 --- board/socionext/developerbox/developerbox.c | 2 -- env/common.c| 11 +++ env/flash.c | 5 + env/nand.c | 3 +-- env/nowhere.c | 5 ++--- env/nvram.c | 7 +++ env/sf.c| 7 +++ include/env_default.h | 10 -- include/env_internal.h | 4 ++-- 18 files changed, 24 insertions(+), 61 deletions(-) -- 2.32.0
[PATCH 02/14] env: sf: Use ENV_VALID enum names instead of literals
From: Marek Behún
The function env_sf_init_addr() assigns number literals (1) instead of
ENV_VALID to gd->env_valid. Fix this.
Signed-off-by: Marek Behún
---
env/sf.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/env/sf.c b/env/sf.c
index 4096e18387..c251d076d7 100644
--- a/env/sf.c
+++ b/env/sf.c
@@ -339,10 +339,10 @@ static int env_sf_init_addr(void)
if (crc32(0, env_ptr->data, ENV_SIZE) == env_ptr->crc) {
gd->env_addr = (ulong)&(env_ptr->data);
- gd->env_valid = 1;
+ gd->env_valid = ENV_VALID;
} else {
gd->env_addr = (ulong)_environment[0];
- gd->env_valid = 1;
+ gd->env_valid = ENV_VALID;
}
return 0;
--
2.32.0
Re: [PATCH v6 2/2] board: kontron: pitx-imx8m: Add Kontron pitx-imx8m board support
Hi,
Am Fr., 22. Okt. 2021 um 14:37 Uhr schrieb Stefano Babic :
>
> Hi Heiko,
>
> On 22.10.21 10:19, Heiko Thiery wrote:
> > Hi Stefano, Hi Simon,
> >
> > Am Do., 21. Okt. 2021 um 15:57 Uhr schrieb Heiko Thiery
> > :
> >>
> >> Hi Stefano, Hi Simon,
> >>
> >>
> >> Am Do., 21. Okt. 2021 um 15:29 Uhr schrieb Stefano Babic :
> >>>
> >>> On 21.10.21 15:17, Heiko Thiery wrote:
> Hi Stefano,
>
>
> Am Do., 21. Okt. 2021 um 13:31 Uhr schrieb Stefano Babic
> :
> >
> > Hi Heiko,
> >
> > On 14.10.21 20:08, Heiko Thiery wrote:
> >> The Kontron pitx-imx8m is an NXP i.MX8MQ based board in the pITX
> >> form factor.
> >>
> >
> > There is still something using binman that does not work with CI.
> > Without CI, we load all firmware including signed_hdmi_imx8m.bin.
> >
> > But on CI, file is not loaded, but instead of warnings, build for this
> > board fails with :
> >
> > +Image 'main-section' is missing external blobs and is non-functional:
> > blob-ext@1 blob-ext@2 blob-ext@3 blob-ext@4
> > +binman: Error 1 running 'mkimage -d ./mkimage.spl.mkimage -n
> > spl/u-boot-spl.cfgout -T imx8mimage -e 0x7e1000
> > ./mkimage-out.spl.mkimage': signed_hdmi_imx8m.bin: Can't open: No such
> > file or directory
> > +
> >
> > Could you take a look ?
>
> Sure. Could you point me to the right CI configuration?
>
> >>>
> >>> Configuration is in .gitlab-ci.yml. For thsi board, buildman is called
> >>> as part of aarch64 target, that is
> >>>
> >>> buildman -o /tmp -P -E -W arm -x aarch64
> >>>
> I need to understand how the required imx-firmware files are copied to
> the u-boot dir. This seems to work already for e. g. the imx8mm
> boards. These require the lpdd* train fw files.
> >>
> >> Here we seem to hit an issue with the CI. blobs (lpddr*) are required
> >> for the imx8mm boards. Binman reports the missing files only as a
> >> warning and buildman does not care about that:
> >>
> >> +WARNING 'mkimage.flash.mkimage' not found, resulting binary is
> >> not-functional
> >>
> >>
> >> With the imx8mq boards switching to binman we also need an additional
> >> fw part (signed_hdmi_imx8m.bin). But other than the lpddr firmware as
> >> blob the signed_hmdi'_imx8m.bin is passed to mkimage and mkimage exits
> >> with an error. Thats leads to the error:
> >>
> >> binman: Error 1 running 'mkimage -d ./mkimage.spl.mkimage -n
> >> spl/u-boot-spl.cfgout -T imx8mimage -e 0x7e1000
> >> ./mkimage-out.spl.mkimage': signed_hdmi_imx8m.bin: Can't open: No such
> >> file or directory
> >>
> >>
> >> Currently I do not have an idea how to handle that. Anyone else?
> >
> > I thought about it a little and did a quick hack. What do you think
> > about dummy files being generated for buildman?
>
> I had quite the same idea...
>
> > I had buildman
> > generate the blobs needed by binman. So at least the build runs
> > through successfully.
>
> But it should be checked if files are present - I guess there are people
> relying on buildman to produce the functional bootloader, and a dummy
> file cannot overwrite the right one if present.
Sure. As said ,this was only a quick hack to see if it could work.
Another thing is if there should be a config for each board that says
what files have to be created.
> > I don't know yet how to integrate this sensibly
> > into buildman or if this is useful for the maintainers at all. But
> > this would get rid of the warnings and errors that come from binman.
> >
> >
> > diff --git a/tools/buildman/board.py b/tools/buildman/board.py
> > index 447aaabea8..cf270c8b72 100644
> > --- a/tools/buildman/board.py
> > +++ b/tools/buildman/board.py
> > @@ -96,6 +96,28 @@ class Board:
> > self.vendor, self.soc, self.options]
> > self.build_it = False
> >
> > +def create_dummy_files(self, work_dir):
> > +import configparser
> > +import os
> > +
> > +settings = configparser.SafeConfigParser()
> > +config_fname = '%s/.buildman/' % os.getenv('HOME')
> > +if os.path.exists(config_fname):
> > +settings.read(config_fname)
> > +
> > +if self.target == "kontron_pitx_imx8m":
> > +
> > +dummy_files = ['bl31.bin',
> > + 'signed_hdmi_imx8m.bin',
> > + 'lpddr4_pmu_train_1d_imem.bin',
> > + 'lpddr4_pmu_train_1d_dmem.bin',
> > + 'lpddr4_pmu_train_2d_imem.bin',
> > + 'lpddr4_pmu_train_2d_dmem.bin'
> > + ]
> > +for dummy_file in dummy_files:
> > +dummy = os.path.join(work_dir, 'build', dummy_file)
> > +with open(dummy, "wb") as out:
> > +out.truncate(1024)
> >
> > class Boards:
> > """Manage a list of boards."""
> > diff --git
[PATCH v1 3/5] i2c: Add Microchip PolarFire SoC I2C driver
Add I2C driver code for the Microchip PolarFire SoC. This driver supports I2C data transfer and probe for I2C slave addresses. Signed-off-by: Padmarao Begari --- drivers/i2c/Kconfig | 6 + drivers/i2c/Makefile| 1 + drivers/i2c/i2c-microchip.c | 482 3 files changed, 489 insertions(+) create mode 100644 drivers/i2c/i2c-microchip.c diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig index 7c447a8aa0..5482a4a470 100644 --- a/drivers/i2c/Kconfig +++ b/drivers/i2c/Kconfig @@ -250,6 +250,12 @@ config SYS_I2C_MESON internal buffer holding up to 8 bytes for transfers and supports both 7-bit and 10-bit addresses. +config SYS_I2C_MICROCHIP + bool "Microchip I2C driver" + help + Add support for the Microchip I2C driver. This is operating on + standard mode up to 100 kbits/s and fast mode up to 400 kbits/s. + config SYS_I2C_MXC bool "NXP MXC I2C driver" help diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile index fca6b157f8..9d41f379bb 100644 --- a/drivers/i2c/Makefile +++ b/drivers/i2c/Makefile @@ -28,6 +28,7 @@ obj-$(CONFIG_SYS_I2C_IPROC) += iproc_i2c.o obj-$(CONFIG_SYS_I2C_KONA) += kona_i2c.o obj-$(CONFIG_SYS_I2C_LPC32XX) += lpc32xx_i2c.o obj-$(CONFIG_SYS_I2C_MESON) += meson_i2c.o +obj-$(CONFIG_SYS_I2C_MICROCHIP) += i2c-microchip.o obj-$(CONFIG_SYS_I2C_MV) += mv_i2c.o obj-$(CONFIG_SYS_I2C_MVTWSI) += mvtwsi.o obj-$(CONFIG_SYS_I2C_MXC) += mxc_i2c.o diff --git a/drivers/i2c/i2c-microchip.c b/drivers/i2c/i2c-microchip.c new file mode 100644 index 00..12f65d0af7 --- /dev/null +++ b/drivers/i2c/i2c-microchip.c @@ -0,0 +1,482 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Microchip I2C controller driver + * + * Copyright (C) 2021 Microchip Technology Inc. + * Padmarao Begari + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#defineMICROCHIP_I2C_TIMEOUT (1000 * 60) + +#define MPFS_I2C_CTRL (0x00) +#defineCTRL_CR0(0x00) +#defineCTRL_CR1(0x01) +#defineCTRL_AA BIT(2) +#defineCTRL_SI BIT(3) +#defineCTRL_STOBIT(4) +#defineCTRL_STABIT(5) +#defineCTRL_ENS1 BIT(6) +#defineCTRL_CR2(0x07) +#define MPFS_I2C_STATUS (0x04) +#defineSTATUS_BUS_ERROR (0x00) +#defineSTATUS_M_START_SENT (0x08) +#defineSTATUS_M_REPEATED_START_SENT(0x10) +#defineSTATUS_M_SLAW_ACK (0x18) +#defineSTATUS_M_SLAW_NACK (0x20) +#defineSTATUS_M_TX_DATA_ACK(0x28) +#defineSTATUS_M_TX_DATA_NACK (0x30) +#defineSTATUS_M_ARB_LOST (0x38) +#defineSTATUS_M_SLAR_ACK (0x40) +#defineSTATUS_M_SLAR_NACK (0x48) +#defineSTATUS_M_RX_DATA_ACKED (0x50) +#defineSTATUS_M_RX_DATA_NACKED (0x58) +#defineSTATUS_S_SLAW_ACKED (0x60) +#defineSTATUS_S_ARB_LOST_SLAW_ACKED(0x68) +#defineSTATUS_S_GENERAL_CALL_ACKED (0x70) +#defineSTATUS_S_ARB_LOST_GENERAL_CALL_ACKED(0x78) +#defineSTATUS_S_RX_DATA_ACKED (0x80) +#defineSTATUS_S_RX_DATA_NACKED (0x88) +#defineSTATUS_S_GENERAL_CALL_RX_DATA_ACKED (0x90) +#defineSTATUS_S_GENERAL_CALL_RX_DATA_NACKED(0x98) +#defineSTATUS_S_RX_STOP (0xA0) +#defineSTATUS_S_SLAR_ACKED (0xA8) +#defineSTATUS_S_ARB_LOST_SLAR_ACKED(0xB0) +#defineSTATUS_S_TX_DATA_ACK(0xb8) +#defineSTATUS_S_TX_DATA_NACK (0xC0) +#defineSTATUS_LAST_DATA_ACK(0xC8) +#defineSTATUS_M_SMB_MASTER_RESET (0xD0) +#defineSTATUS_S_SCL_LOW_TIMEOUT(0xD8) +#defineSTATUS_NO_STATE_INFO(0xF8) +#define MPFS_I2C_DATA (0x08) +#define MPFS_I2C_SLAVE0_ADDR (0x0c) +#define MPFS_I2C_SMBUS (0x10) +#define MPFS_I2C_FREQ (0x14)
[PATCH v1 1/5] riscv: dts: Split Microchip device tree
The device tree split into .dtsi and .dts files, common
device node for eMMC/SD, enable I2C1, UART1 for console
instead of UART0, enable the DDR 2GB memory and in
that 288MB memory is reserved for fabric buffer.
Signed-off-by: Padmarao Begari
---
arch/riscv/dts/microchip-mpfs-icicle-kit.dts | 518
arch/riscv/dts/microchip-mpfs.dtsi| 571 ++
.../microchip-mpfs-plic.h | 195 ++
.../interrupt-controller/riscv-hart.h | 18 +
4 files changed, 913 insertions(+), 389 deletions(-)
create mode 100644 arch/riscv/dts/microchip-mpfs.dtsi
create mode 100644
include/dt-bindings/interrupt-controller/microchip-mpfs-plic.h
create mode 100644 include/dt-bindings/interrupt-controller/riscv-hart.h
diff --git a/arch/riscv/dts/microchip-mpfs-icicle-kit.dts
b/arch/riscv/dts/microchip-mpfs-icicle-kit.dts
index 89c4cf5fb2..287ef3d23b 100644
--- a/arch/riscv/dts/microchip-mpfs-icicle-kit.dts
+++ b/arch/riscv/dts/microchip-mpfs-icicle-kit.dts
@@ -1,417 +1,157 @@
-// SPDX-License-Identifier: (GPL-2.0 OR MIT)
-/* Copyright (c) 2020 Microchip Technology Inc */
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2021 Microchip Technology Inc.
+ * Padmarao Begari
+ */
/dts-v1/;
-#include "dt-bindings/clock/microchip-mpfs-clock.h"
+
+#include "microchip-mpfs.dtsi"
/* Clock frequency (in Hz) of the rtcclk */
#define RTCCLK_FREQ100
/ {
- #address-cells = <2>;
- #size-cells = <2>;
- model = "Microchip MPFS Icicle Kit";
- compatible = "microchip,mpfs-icicle-kit";
+ model = "Microchip PolarFire-SoC Icicle Kit";
+ compatible = "microchip,mpfs-icicle-kit", "microchip,mpfs";
aliases {
- serial0 =
- ethernet0 =
+ serial1 =
+ ethernet0 =
};
chosen {
- stdout-path = "serial0";
+ stdout-path = "serial1";
};
- cpucomplex: cpus {
- #address-cells = <1>;
- #size-cells = <0>;
+ cpus {
timebase-frequency = ;
- cpu0: cpu@0 {
- clocks = < CLK_CPU>;
- compatible = "sifive,e51", "sifive,rocket0", "riscv";
- device_type = "cpu";
- i-cache-block-size = <64>;
- i-cache-sets = <128>;
- i-cache-size = <16384>;
- reg = <0>;
- riscv,isa = "rv64imac";
- status = "disabled";
- operating-points = <
- /* kHz uV */
- 60 110
- 30 95
- 15 75
- >;
- cpu0intc: interrupt-controller {
- #interrupt-cells = <1>;
- compatible = "riscv,cpu-intc";
- interrupt-controller;
- };
- };
- cpu1: cpu@1 {
- clocks = < CLK_CPU>;
- compatible = "sifive,u54-mc", "sifive,rocket0", "riscv";
- d-cache-block-size = <64>;
- d-cache-sets = <64>;
- d-cache-size = <32768>;
- d-tlb-sets = <1>;
- d-tlb-size = <32>;
- device_type = "cpu";
- i-cache-block-size = <64>;
- i-cache-sets = <64>;
- i-cache-size = <32768>;
- i-tlb-sets = <1>;
- i-tlb-size = <32>;
- mmu-type = "riscv,sv39";
- reg = <1>;
- riscv,isa = "rv64imafdc";
- tlb-split;
- status = "okay";
- operating-points = <
- /* kHz uV */
- 60 110
- 30 95
- 15 75
- >;
- cpu1intc: interrupt-controller {
- #interrupt-cells = <1>;
- compatible = "riscv,cpu-intc";
- interrupt-controller;
- };
- };
- cpu2: cpu@2 {
- clocks = < CLK_CPU>;
- compatible = "sifive,u54-mc", "sifive,rocket0", "riscv";
- d-cache-block-size = <64>;
- d-cache-sets = <64>;
- d-cache-size = <32768>;
- d-tlb-sets = <1>;
- d-tlb-size = <32>;
- device_type = "cpu";
-
[PATCH v1 4/5] net: macb: Compatible as per device tree
Update compatible as per Microchip PolarFire SoC ethernet
device node.
Signed-off-by: Padmarao Begari
---
drivers/net/macb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/macb.c b/drivers/net/macb.c
index 8c6461e717..1b867bd5c2 100644
--- a/drivers/net/macb.c
+++ b/drivers/net/macb.c
@@ -1502,7 +1502,7 @@ static const struct udevice_id macb_eth_ids[] = {
{ .compatible = "cdns,zynq-gem" },
{ .compatible = "sifive,fu540-c000-gem",
.data = (ulong)_config },
- { .compatible = "microchip,mpfs-mss-gem",
+ { .compatible = "microchip,mpfs-gem",
.data = (ulong)_config },
{ }
};
--
2.25.1
[PATCH v1 2/5] riscv: Update Microchip MPFS Icicle Kit support
This patch updates Microchip MPFS Icicle Kit support. For now,
add Microchip I2C driver, set environment variables for
mac addesses and default build for SBI_V02.
Signed-off-by: Padmarao Begari
---
board/microchip/mpfs_icicle/Kconfig | 5 +
board/microchip/mpfs_icicle/mpfs_icicle.c | 17 -
configs/microchip_mpfs_icicle_defconfig | 1 -
3 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/board/microchip/mpfs_icicle/Kconfig
b/board/microchip/mpfs_icicle/Kconfig
index 4678462378..092e411215 100644
--- a/board/microchip/mpfs_icicle/Kconfig
+++ b/board/microchip/mpfs_icicle/Kconfig
@@ -45,5 +45,10 @@ config BOARD_SPECIFIC_OPTIONS # dummy
imply MMC_WRITE
imply MMC_SDHCI
imply MMC_SDHCI_CADENCE
+ imply MMC_SDHCI_ADMA
+ imply MMC_HS200_SUPPORT
+ imply CMD_I2C
+ imply DM_I2C
+ imply SYS_I2C_MICROCHIP
endif
diff --git a/board/microchip/mpfs_icicle/mpfs_icicle.c
b/board/microchip/mpfs_icicle/mpfs_icicle.c
index afef719dff..e74c9fb03c 100644
--- a/board/microchip/mpfs_icicle/mpfs_icicle.c
+++ b/board/microchip/mpfs_icicle/mpfs_icicle.c
@@ -119,7 +119,22 @@ int board_late_init(void)
if (icicle_mac_addr[idx] == ':')
icicle_mac_addr[idx] = ' ';
}
- env_set("icicle_mac_addr", icicle_mac_addr);
+ env_set("icicle_mac_addr0", icicle_mac_addr);
+
+ mac_addr[5] = device_serial_number[0] + 1;
+
+ icicle_mac_addr[0] = '[';
+
+ sprintf(_mac_addr[1], "%pM", mac_addr);
+
+ icicle_mac_addr[18] = ']';
+ icicle_mac_addr[19] = '\0';
+
+ for (idx = 0; idx < 20; idx++) {
+ if (icicle_mac_addr[idx] == ':')
+ icicle_mac_addr[idx] = ' ';
+ }
+ env_set("icicle_mac_addr1", icicle_mac_addr);
return 0;
}
diff --git a/configs/microchip_mpfs_icicle_defconfig
b/configs/microchip_mpfs_icicle_defconfig
index 90ae76cc12..b3c7e6db8f 100644
--- a/configs/microchip_mpfs_icicle_defconfig
+++ b/configs/microchip_mpfs_icicle_defconfig
@@ -6,7 +6,6 @@ CONFIG_DEFAULT_DEVICE_TREE="microchip-mpfs-icicle-kit"
CONFIG_TARGET_MICROCHIP_ICICLE=y
CONFIG_ARCH_RV64I=y
CONFIG_RISCV_SMODE=y
-CONFIG_SBI_V01=y
CONFIG_DISTRO_DEFAULTS=y
CONFIG_SYS_LOAD_ADDR=0x8020
CONFIG_FIT=y
--
2.25.1
[PATCH v1 5/5] doc: board: Update Microchip MPFS Icicle Kit doc
UART1 uses for U-BOOT and Linux console instead of UART0 and UART0 is reserved for Hart Software Services(HSS). Signed-off-by: Padmarao Begari --- doc/board/microchip/mpfs_icicle.rst | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/doc/board/microchip/mpfs_icicle.rst b/doc/board/microchip/mpfs_icicle.rst index c71c2f3cab..d7af542c0e 100644 --- a/doc/board/microchip/mpfs_icicle.rst +++ b/doc/board/microchip/mpfs_icicle.rst @@ -18,8 +18,9 @@ The support for following drivers are already enabled: 1. NS16550 UART Driver. 2. Microchip Clock Driver. -3. Cadence MACB ethernet driver for networking support. -4. Cadence MMC Driver for eMMC/SD support. +3. Microchip I2C Driver. +4. Cadence MACB ethernet driver for networking support. +5. Cadence MMC Driver for eMMC/SD support. Booting from eMMC using HSS --- @@ -214,7 +215,8 @@ GPT partition. Booting ~~~ -You should see the U-Boot prompt on UART0. +You should see the U-Boot prompt on UART1. +(Note: UART0 is reserved for HSS) Sample boot log from MPFS Icicle Kit @@ -451,7 +453,8 @@ copied payload and Linux image. sudo dd if= of=/dev/sdX2 bs=512 -You should see the U-Boot prompt on UART0. +You should see the U-Boot prompt on UART1. +(Note: UART0 is reserved for HSS) GUID type ~ -- 2.25.1
