[PATCH v2 07/10] arm: mvebu: clearfog: add SPI offsets
Add reasonable default SPI offsets and ENV size when configured to boot from SPI flash. Signed-off-by: Joel Johnson --- v2 changes: - none There was some reasonable concern raised about duplicating config entries within a board specific config file rather than making board specific configurations within defconfig. This seems to offer a more board localized mechanism to provide platform defaults for core values. As mentioned in the review, this usage seems to match the Kconfig documented intended usage. As noted at https://www.kernel.org/doc/html/latest/kbuild/kconfig-language.html: "Default values are not limited to the menu entry where they are defined. This means the default can be defined somewhere else or be overridden by an earlier definition." Given that there is some dependency variability with these values I prefer keeping them as Kconfig values, but defer to maintainers. Notably, for the ENV values in this and a later commit, I'm using a pattern already in used several other board configs. --- board/solidrun/clearfog/Kconfig | 12 1 file changed, 12 insertions(+) diff --git a/board/solidrun/clearfog/Kconfig b/board/solidrun/clearfog/Kconfig index 6231407589..f563c3c4fc 100644 --- a/board/solidrun/clearfog/Kconfig +++ b/board/solidrun/clearfog/Kconfig @@ -39,4 +39,16 @@ config CLEARFOG_SFP_25GB SGMII connection (requires a supporting SFP). By default, transfer speed of 1.25 Gbps is used, suitable for a more common 1 Gbps SFP module. +config ENV_SECT_SIZE + hex "Environment Sector-Size" + # Use SPI flash erase block size of 4 KiB + default 0x1000 if MVEBU_SPL_BOOT_DEVICE_SPI + # Use optimistic 64 KiB erase block, will vary between actual media + default 0x1 if MVEBU_SPL_BOOT_DEVICE_MMC + +config SYS_SPI_U_BOOT_OFFS + hex "address of u-boot payload in SPI flash" + default 0x2 + depends on MVEBU_SPL_BOOT_DEVICE_SPI + endmenu -- 2.20.1
[PATCH v2 10/10] arm: mvebu: clearfog: reduce MMC boot assumptions
Reduce those MMC booting assumptions from clearfog_defconfig which are already selected by dependent options via Kconfig. Signed-off-by: Joel Johnson --- v2 changes: - rebased on master to use Baruch's dynamic MMC/SD offset logic - update description, will revisit removal of CONFIG_MVEBU_SPL_BOOT_DEVICE_MMC in separate future path if a more viable option is identified --- arch/arm/mach-mvebu/Kconfig | 1 + configs/clearfog_defconfig | 2 -- 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig index 32191e7157..4b381a2936 100644 --- a/arch/arm/mach-mvebu/Kconfig +++ b/arch/arm/mach-mvebu/Kconfig @@ -249,6 +249,7 @@ config MVEBU_SPL_BOOT_DEVICE_MMC select SPL_DM_GPIO select SPL_DM_MMC select SPL_LIBDISK_SUPPORT + select SPL_MMC_SUPPORT config MVEBU_SPL_BOOT_DEVICE_SATA bool "SATA" diff --git a/configs/clearfog_defconfig b/configs/clearfog_defconfig index c5a036804e..06423e1678 100644 --- a/configs/clearfog_defconfig +++ b/configs/clearfog_defconfig @@ -9,7 +9,6 @@ CONFIG_SPL_LIBGENERIC_SUPPORT=y CONFIG_SYS_MALLOC_F_LEN=0x2000 CONFIG_TARGET_CLEARFOG=y CONFIG_MVEBU_SPL_BOOT_DEVICE_MMC=y -CONFIG_SPL_MMC_SUPPORT=y CONFIG_SPL_SERIAL_SUPPORT=y CONFIG_SPL_DRIVERS_MISC_SUPPORT=y CONFIG_NR_DRAM_BANKS=2 @@ -42,7 +41,6 @@ CONFIG_CMD_CACHE=y CONFIG_CMD_TIME=y # CONFIG_SPL_PARTITION_UUIDS is not set CONFIG_DEFAULT_DEVICE_TREE="armada-388-clearfog" -CONFIG_ENV_IS_IN_MMC=y CONFIG_NET_RANDOM_ETHADDR=y CONFIG_SPL_OF_TRANSLATE=y CONFIG_AHCI_MVEBU=y -- 2.20.1
[PATCH v2 06/10] arm: mvebu: clearfog: Add option for 2.5 Gbps SFP
Signed-off-by: Joel Johnson
---
v2 changes:
- fixed help indentation
---
board/solidrun/clearfog/Kconfig| 7 +++
board/solidrun/clearfog/clearfog.c | 4
2 files changed, 11 insertions(+)
diff --git a/board/solidrun/clearfog/Kconfig b/board/solidrun/clearfog/Kconfig
index a82f9867fe..6231407589 100644
--- a/board/solidrun/clearfog/Kconfig
+++ b/board/solidrun/clearfog/Kconfig
@@ -32,4 +32,11 @@ config CLEARFOG_CON2_SATA
modules, but the desired protocol must be configured at build
time since it affects the SerDes topology layout.
+config CLEARFOG_SFP_25GB
+ bool "Enable 2.5 Gbps mode for SFP"
+ help
+ Set the SFP module connection to support 2.5 Gbps transfer speed for
the
+ SGMII connection (requires a supporting SFP). By default, transfer
speed
+ of 1.25 Gbps is used, suitable for a more common 1 Gbps SFP module.
+
endmenu
diff --git a/board/solidrun/clearfog/clearfog.c
b/board/solidrun/clearfog/clearfog.c
index 291a9279b6..c9ef620f78 100644
--- a/board/solidrun/clearfog/clearfog.c
+++ b/board/solidrun/clearfog/clearfog.c
@@ -55,7 +55,11 @@ static struct serdes_map board_serdes_map[] = {
#else
{PEX2, SERDES_SPEED_5_GBPS, PEX_ROOT_COMPLEX_X1, 0, 0},
#endif
+#if defined (CONFIG_CLEARFOG_SFP_25GB)
+ {SGMII2, SERDES_SPEED_3_125_GBPS, SERDES_DEFAULT_MODE, 0, 0},
+#else
{SGMII2, SERDES_SPEED_1_25_GBPS, SERDES_DEFAULT_MODE, 0, 0},
+#endif
};
int hws_board_topology_load(struct serdes_map **serdes_map_array, u8 *count)
--
2.20.1
[PATCH v2 05/10] arm: mvebu: clearfog: Add SATA mode flags
The mPCIe slots on ClearFog Pro and ClearFog Base may be alternately
configured for SATA usage.
Signed-off-by: Joel Johnson
---
v2 changes:
- fixed help indentation
---
board/solidrun/clearfog/Kconfig| 17 +
board/solidrun/clearfog/clearfog.c | 6 ++
2 files changed, 23 insertions(+)
diff --git a/board/solidrun/clearfog/Kconfig b/board/solidrun/clearfog/Kconfig
index cee8f3bac1..a82f9867fe 100644
--- a/board/solidrun/clearfog/Kconfig
+++ b/board/solidrun/clearfog/Kconfig
@@ -15,4 +15,21 @@ config TARGET_CLEARFOG_BASE
detection via additional EEPROM hardware. This option enables
selecting
the Base variant for older hardware revisions.
+config CLEARFOG_CON3_SATA
+ bool "Use CON3 slot in SATA mode"
+ help
+ Use the CON3 port with SATA protocol instead of the default PCIe.
+ The ClearFog port allows usage of either mSATA or miniPCIe
+ modules, but the desired protocol must be configured at build
+ time since it affects the SerDes topology layout.
+
+config CLEARFOG_CON2_SATA
+ bool "Use CON2 slot in SATA mode"
+ depends on !TARGET_CLEARFOG_BASE
+ help
+ Use the CON2 port with SATA protocol instead of the default PCIe.
+ The ClearFog port allows usage of either mSATA or miniPCIe
+ modules, but the desired protocol must be configured at build
+ time since it affects the SerDes topology layout.
+
endmenu
diff --git a/board/solidrun/clearfog/clearfog.c
b/board/solidrun/clearfog/clearfog.c
index a3c5780730..291a9279b6 100644
--- a/board/solidrun/clearfog/clearfog.c
+++ b/board/solidrun/clearfog/clearfog.c
@@ -42,10 +42,16 @@ static void read_tlv_data(void);
static struct serdes_map board_serdes_map[] = {
{SATA0, SERDES_SPEED_3_GBPS, SERDES_DEFAULT_MODE, 0, 0},
{SGMII1, SERDES_SPEED_1_25_GBPS, SERDES_DEFAULT_MODE, 0, 0},
+#if defined (CONFIG_CLEARFOG_CON3_SATA)
+ {SATA1, SERDES_SPEED_3_GBPS, SERDES_DEFAULT_MODE, 0, 0},
+#else
{PEX1, SERDES_SPEED_5_GBPS, PEX_ROOT_COMPLEX_X1, 0, 0},
+#endif
{USB3_HOST1, SERDES_SPEED_5_GBPS, SERDES_DEFAULT_MODE, 0, 0},
#if defined (CONFIG_TARGET_CLEARFOG_BASE)
{USB3_HOST0, SERDES_SPEED_5_GBPS, SERDES_DEFAULT_MODE, 0, 0},
+#elif defined(CONFIG_CLEARFOG_CON2_SATA)
+ {SATA2, SERDES_SPEED_3_GBPS, SERDES_DEFAULT_MODE, 0, 0},
#else
{PEX2, SERDES_SPEED_5_GBPS, PEX_ROOT_COMPLEX_X1, 0, 0},
#endif
--
2.20.1
[PATCH v2 09/10] arm: mvebu: clearfog: move ENV params to Kconfig
Migrate the values for ENV_SIZE and ENV_OFFSET into board specific Kconfig defaults so they're more accessible for configuration. --- v2 changes: - none Signed-off-by: Joel Johnson --- board/solidrun/clearfog/Kconfig | 8 configs/clearfog_defconfig | 2 -- 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/board/solidrun/clearfog/Kconfig b/board/solidrun/clearfog/Kconfig index f563c3c4fc..6b08ad4615 100644 --- a/board/solidrun/clearfog/Kconfig +++ b/board/solidrun/clearfog/Kconfig @@ -39,6 +39,14 @@ config CLEARFOG_SFP_25GB SGMII connection (requires a supporting SFP). By default, transfer speed of 1.25 Gbps is used, suitable for a more common 1 Gbps SFP module. +config ENV_SIZE + hex "Environment Size" + default 0x1 + +config ENV_OFFSET + hex "Environment offset" + default 0xF + config ENV_SECT_SIZE hex "Environment Sector-Size" # Use SPI flash erase block size of 4 KiB diff --git a/configs/clearfog_defconfig b/configs/clearfog_defconfig index 24f0b557be..c5a036804e 100644 --- a/configs/clearfog_defconfig +++ b/configs/clearfog_defconfig @@ -11,8 +11,6 @@ CONFIG_TARGET_CLEARFOG=y CONFIG_MVEBU_SPL_BOOT_DEVICE_MMC=y CONFIG_SPL_MMC_SUPPORT=y CONFIG_SPL_SERIAL_SUPPORT=y -CONFIG_ENV_SIZE=0x1 -CONFIG_ENV_OFFSET=0xF CONFIG_SPL_DRIVERS_MISC_SUPPORT=y CONFIG_NR_DRAM_BANKS=2 CONFIG_SPL=y -- 2.20.1
[PATCH v2 01/10] arm: mvebu: fix SerDes table alignment
Tested on Solidrun ClearFog Base. Table alignment was:
| Lane # | Speed | Type |
| 0| 3 | SATA0 |
| 1| 0 | SGMII1 |
| 2| 3 | SATA1 |
| 3| 5 | USB3 HOST1 |
| 4| 5 | USB3 HOST0 |
| 5| 4 | SGMII2 |
After the change, it's correctly aligned as:
| Lane # | Speed | Type |
| 0| 3 | SATA0 |
| 1| 0 | SGMII1 |
| 2| 5 | PCIe1 |
| 3| 5 | USB3 HOST1 |
| 4| 5 | PCIe2 |
| 5| 0 | SGMII2 |
Signed-off-by: Joel Johnson
---
v2 changes
- none
---
arch/arm/mach-mvebu/serdes/a38x/high_speed_env_spec.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-mvebu/serdes/a38x/high_speed_env_spec.c
b/arch/arm/mach-mvebu/serdes/a38x/high_speed_env_spec.c
index 33e70569bc..66409a50c0 100644
--- a/arch/arm/mach-mvebu/serdes/a38x/high_speed_env_spec.c
+++ b/arch/arm/mach-mvebu/serdes/a38x/high_speed_env_spec.c
@@ -1366,16 +1366,16 @@ static void print_topology_details(const struct
serdes_map *serdes_map,
DEBUG_INIT_S("board SerDes lanes topology details:\n");
- DEBUG_INIT_S(" | Lane # | Speed | Type |\n");
+ DEBUG_INIT_S(" | Lane # | Speed | Type |\n");
DEBUG_INIT_S(" \n");
for (lane_num = 0; lane_num < count; lane_num++) {
if (serdes_map[lane_num].serdes_type == DEFAULT_SERDES)
continue;
DEBUG_INIT_S(" | ");
DEBUG_INIT_D(hws_get_physical_serdes_num(lane_num), 1);
- DEBUG_INIT_S("| ");
+ DEBUG_INIT_S("| ");
DEBUG_INIT_D(serdes_map[lane_num].serdes_speed, 2);
- DEBUG_INIT_S(" | ");
+ DEBUG_INIT_S(" | ");
DEBUG_INIT_S((char *)
serdes_type_to_string[serdes_map[lane_num].
serdes_type]);
--
2.20.1
[PATCH v2 08/10] arm: mvebu: enable working default boot support
With the move to driver model usage, ensure that the required driver support for SPI and MMC booting is available in SPL. Tested on SolidRun ClearFog devices. Signed-off-by: Joel Johnson --- v2 changes: - change "select" for ENV_IS_IN_X to "imply" to allow disabling the default env location and configuring a different one if desired - remove SPL_DM_GPIO from defconfig, only include if needed for MMC booting --- arch/arm/mach-mvebu/Kconfig | 10 ++ configs/clearfog_defconfig | 1 - 2 files changed, 10 insertions(+), 1 deletion(-) diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig index 161dee937f..32191e7157 100644 --- a/arch/arm/mach-mvebu/Kconfig +++ b/arch/arm/mach-mvebu/Kconfig @@ -235,9 +235,19 @@ choice config MVEBU_SPL_BOOT_DEVICE_SPI bool "SPI NOR flash" + imply ENV_IS_IN_SPI_FLASH + select SPL_DM_SPI + select SPL_MTD_SUPPORT + select SPL_SPI_FLASH_SUPPORT + select SPL_SPI_LOAD + select SPL_SPI_SUPPORT config MVEBU_SPL_BOOT_DEVICE_MMC bool "SDIO/MMC card" + imply ENV_IS_IN_MMC + # GPIO required for SD card presence detection line + select SPL_DM_GPIO + select SPL_DM_MMC select SPL_LIBDISK_SUPPORT config MVEBU_SPL_BOOT_DEVICE_SATA diff --git a/configs/clearfog_defconfig b/configs/clearfog_defconfig index e932f9c195..24f0b557be 100644 --- a/configs/clearfog_defconfig +++ b/configs/clearfog_defconfig @@ -28,7 +28,6 @@ CONFIG_SYS_CONSOLE_INFO_QUIET=y # CONFIG_DISPLAY_BOARDINFO is not set CONFIG_DISPLAY_BOARDINFO_LATE=y CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_DATA_PART_OFFSET=0x1 -CONFIG_SPL_DM_GPIO=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_CMD_SYS_EEPROM=y CONFIG_SPL_CMD_SYS_EEPROM=y -- 2.20.1
[PATCH v2 04/10] arm: mvebu: clearfog: Use Pro DT by default
Switch to explicitly using the Pro variant DT, which has been
available since Linux 4.11. Also unify the location of DT selection
in board_late_init instead of split between detection and static
configuration paths.
---
v2 changes
- newly added in V2 series based on run-time rebasing
Signed-off-by: Joel Johnson
---
board/solidrun/clearfog/clearfog.c | 6 --
include/configs/clearfog.h | 1 -
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/board/solidrun/clearfog/clearfog.c
b/board/solidrun/clearfog/clearfog.c
index b66f9f61cf..a3c5780730 100644
--- a/board/solidrun/clearfog/clearfog.c
+++ b/board/solidrun/clearfog/clearfog.c
@@ -269,7 +269,7 @@ int checkboard(void)
#if defined (CONFIG_TARGET_CLEARFOG_BASE)
char *board = "ClearFog Base";
#else
- char *board = "ClearFog";
+ char *board = "ClearFog Pro";
#endif
read_tlv_data();
@@ -300,9 +300,11 @@ int board_late_init(void)
env_set("fdtfile", "armada-385-clearfog-gtr-s4.dtb");
else if (sr_product_is("Clearfog GTR L8"))
env_set("fdtfile", "armada-385-clearfog-gtr-l8.dtb");
-#if defined (CONFIG_TARGET_CLEARFOG_BASE)
else
+#if defined (CONFIG_TARGET_CLEARFOG_BASE)
env_set("fdtfile", "armada-388-clearfog-base.dtb");
+#else
+env_set("fdtfile", "armada-388-clearfog-pro.dtb");
#endif
return 0;
diff --git a/include/configs/clearfog.h b/include/configs/clearfog.h
index 633187d86f..6ca0474461 100644
--- a/include/configs/clearfog.h
+++ b/include/configs/clearfog.h
@@ -134,7 +134,6 @@
#define CONFIG_EXTRA_ENV_SETTINGS \
RELOCATION_LIMITS_ENV_SETTINGS \
LOAD_ADDRESS_ENV_SETTINGS \
- "fdtfile=" CONFIG_DEFAULT_DEVICE_TREE ".dtb\0" \
"console=ttyS0,115200\0" \
BOOTENV
--
2.20.1
[PATCH v2 03/10] arm: mvebu: clearfog: initial ClearFog Base variant
Add a unique entry for ClearFog Base variant, reflected
in the board name and adjusted SerDes topology.
Signed-off-by: Joel Johnson
---
v2 changes:
- reworked based on Baruch's run-time TLV EEPROM detection series
---
arch/arm/mach-mvebu/Kconfig| 2 ++
board/solidrun/clearfog/Kconfig| 18 ++
board/solidrun/clearfog/clearfog.c | 12
3 files changed, 32 insertions(+)
create mode 100644 board/solidrun/clearfog/Kconfig
diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index bc5eaa5a76..161dee937f 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -280,4 +280,6 @@ config SECURED_MODE_CSK_INDEX
default 0
depends on SECURED_MODE_IMAGE
+source "board/solidrun/clearfog/Kconfig"
+
endif
diff --git a/board/solidrun/clearfog/Kconfig b/board/solidrun/clearfog/Kconfig
new file mode 100644
index 00..cee8f3bac1
--- /dev/null
+++ b/board/solidrun/clearfog/Kconfig
@@ -0,0 +1,18 @@
+menu "ClearFog configuration"
+ depends on TARGET_CLEARFOG
+
+config TARGET_CLEARFOG_BASE
+ bool "Use ClearFog Base static configuration"
+ help
+ Use the ClearFog Base as the static configuration instead of the
+ default which uses the ClearFog Pro.
+
+ Runtime board detection is always attempted and used if available. The
+ static configuration is used as a fallback in cases where runtime
+ detection is not available.
+
+ Only newer revisions of the ClearFog product line support runtime
+ detection via additional EEPROM hardware. This option enables
selecting
+ the Base variant for older hardware revisions.
+
+endmenu
diff --git a/board/solidrun/clearfog/clearfog.c
b/board/solidrun/clearfog/clearfog.c
index f407f744bf..b66f9f61cf 100644
--- a/board/solidrun/clearfog/clearfog.c
+++ b/board/solidrun/clearfog/clearfog.c
@@ -44,7 +44,11 @@ static struct serdes_map board_serdes_map[] = {
{SGMII1, SERDES_SPEED_1_25_GBPS, SERDES_DEFAULT_MODE, 0, 0},
{PEX1, SERDES_SPEED_5_GBPS, PEX_ROOT_COMPLEX_X1, 0, 0},
{USB3_HOST1, SERDES_SPEED_5_GBPS, SERDES_DEFAULT_MODE, 0, 0},
+#if defined (CONFIG_TARGET_CLEARFOG_BASE)
+ {USB3_HOST0, SERDES_SPEED_5_GBPS, SERDES_DEFAULT_MODE, 0, 0},
+#else
{PEX2, SERDES_SPEED_5_GBPS, PEX_ROOT_COMPLEX_X1, 0, 0},
+#endif
{SGMII2, SERDES_SPEED_1_25_GBPS, SERDES_DEFAULT_MODE, 0, 0},
};
@@ -262,7 +266,11 @@ int board_init(void)
int checkboard(void)
{
+#if defined (CONFIG_TARGET_CLEARFOG_BASE)
+ char *board = "ClearFog Base";
+#else
char *board = "ClearFog";
+#endif
read_tlv_data();
if (strlen(tlv_product_name[0]) > 0)
@@ -292,6 +300,10 @@ int board_late_init(void)
env_set("fdtfile", "armada-385-clearfog-gtr-s4.dtb");
else if (sr_product_is("Clearfog GTR L8"))
env_set("fdtfile", "armada-385-clearfog-gtr-l8.dtb");
+#if defined (CONFIG_TARGET_CLEARFOG_BASE)
+ else
+env_set("fdtfile", "armada-388-clearfog-base.dtb");
+#endif
return 0;
}
--
2.20.1
[PATCH v2 00/10] ClearFog Base static variant support
This patch series adds support for ClearFog Base static configuration, as well as updating and fixing the ClearFog support for MMC and SPI booting. V2 changes: - updated against, and dependent on, https://patchwork.ozlabs.org/cover/1200324 Joel Johnson (10): arm: mvebu: fix SerDes table alignment arm: mvebu: solidrun: remove hardcoded DTS MAC address arm: mvebu: clearfog: initial ClearFog Base variant arm: mvebu: clearfog: Use Pro DT by default arm: mvebu: clearfog: Add SATA mode flags arm: mvebu: clearfog: Add option for 2.5 Gbps SFP arm: mvebu: clearfog: add SPI offsets arm: mvebu: enable working default boot support arm: mvebu: clearfog: move ENV params to Kconfig arm: mvebu: clearfog: reduce MMC boot assumptions .../arm/dts/armada-38x-solidrun-microsom.dtsi | 1 - arch/arm/mach-mvebu/Kconfig | 13 .../serdes/a38x/high_speed_env_spec.c | 6 +- board/solidrun/clearfog/Kconfig | 62 +++ board/solidrun/clearfog/clearfog.c| 26 +++- configs/clearfog_defconfig| 5 -- include/configs/clearfog.h| 1 - 7 files changed, 103 insertions(+), 11 deletions(-) create mode 100644 board/solidrun/clearfog/Kconfig -- 2.20.1
[PATCH v2 02/10] arm: mvebu: solidrun: remove hardcoded DTS MAC address
Using a consistent hardcoded MAC address from the DTS file causes
issues when using multiple devices on the same network segment.
Instead rely on environment configuration or random generation.
Signed-off-by: Joel Johnson
---
v2 changes:
- none
---
arch/arm/dts/armada-38x-solidrun-microsom.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/dts/armada-38x-solidrun-microsom.dtsi
b/arch/arm/dts/armada-38x-solidrun-microsom.dtsi
index a322a28c21..9bbeafc53b 100644
--- a/arch/arm/dts/armada-38x-solidrun-microsom.dtsi
+++ b/arch/arm/dts/armada-38x-solidrun-microsom.dtsi
@@ -39,7 +39,6 @@
{
/* ethernet@7 */
- mac-address = [00 50 43 02 02 01];
pinctrl-0 = <_rgmii_pins>;
pinctrl-names = "default";
phy = <_dedicated>;
--
2.20.1
RE: [RFC PATCH] imx: imx8mm-evk/imx8mn-evk: enable sysreset driver for SPL
> Subject: Re: [RFC PATCH] imx: imx8mm-evk/imx8mn-evk: enable sysreset > driver for SPL > > On 1/17/20 3:33 AM, Peng Fan wrote: > > Hi Marek, > > Hi, > > >> Subject: Re: [RFC PATCH] imx: imx8mm-evk/imx8mn-evk: enable sysreset > >> driver for SPL > >> > >> On 1/16/20 3:21 AM, Peng Fan wrote: > >> > >> Hello Peng, > >> > Subject: [RFC PATCH] imx: imx8mm-evk/imx8mn-evk: enable sysreset > driver for SPL > > >>> > >>> NAK, this will not work on i.MX8MM/N. > >>> > >>> Currently sysreset psci is enabled, however psci will not work for > >>> SPL, because SPL boots before BL31. > >> > >> Thank you for the constructive feedback. > >> > >> So basically , what we need is a real sysreset driver for iMX8MM , > >> which can work with bare-bones hardware interface, that is, poking > >> some register, correct ? > > > > Yes. > > > >> > >> So, either you or Claudius needs to implement a driver in > >> drivers/sysreset, which will bind in SPL and if needed, do some > >> writel() into some registers to reset the board, correct ? > > > > Yes. > > > >> > >> Because, I believe we can both agree that dumping such ad-hoc code > >> which implements reset in board code is not the right way, esp. > >> nowadays with all the DM/DT stuff in. > > > > Alought we still have ocram space, but our SPL is huge now, 100KB+ > > How so ? > > How much does DM sysreset add to that ? currently I am a bit hesitated about DM SPL, but it let us not to maintain two drivers for one module. Just some complaining words:) I am fine to add DM sysreset currently. Not sure how much it will add after DM usb. Regards, Peng.
RE: [PATCH] arm: dts: i.mx8x: add #cooling-cells properties
> Subject: Re: [PATCH] arm: dts: i.mx8x: add #cooling-cells properties > > On Sat, Jan 18, 2020 at 12:12 PM Anatolij Gustschin wrote: > > > > Fix dtb building warnings: > > Warning (cooling_device_property): > /thermal-zones/cpu-thermal0/cooling-maps/map0: > > Missing property '#cooling-cells' in node /cpus/cpu@0 or bad phandle > > (referred from cooling-device[0]) > > > > Signed-off-by: Anatolij Gustschin > > --- > > arch/arm/dts/fsl-imx8-ca35.dtsi | 4 > > 1 file changed, 4 insertions(+) > > > > diff --git a/arch/arm/dts/fsl-imx8-ca35.dtsi > > b/arch/arm/dts/fsl-imx8-ca35.dtsi index 28bc32c8b7..9af8b1511c 100644 > > --- a/arch/arm/dts/fsl-imx8-ca35.dtsi > > +++ b/arch/arm/dts/fsl-imx8-ca35.dtsi > > @@ -18,6 +18,7 @@ > > reg = <0x0 0x0>; > > enable-method = "psci"; > > next-level-cache = <_L2>; > > + #cooling-cells = <2>; > > Yes, this matches arch/arm64/boot/dts/freescale/imx8qxp.dtsi upstream. > > Maybe we should sync with upstream at some point. I am still waiting Aisheng to finish the i.MX8QM and dts restructure, Aisheng did a big restructure. If import earlier, we have to import and adapt again. Thanks, Peng. > > Reviewed-by: Fabio Estevam
Re: Re: Apollo Lake GPIO driver with Coreboot/U-Boot
Hi Wolfgang, On Sat, 18 Jan 2020 at 00:56, Wolfgang Wallner wrote: > > Hello Simon, > > > -"Simon Glass" schrieb: - > > On Thu, 16 Jan 2020 at 02:55, Wolfgang Wallner > > wrote: > > > > > > Hello Simon, Bin, all, > > > > > > I have an Apollo Lake based device, where U-Boot is booted as a Coreboot > > > payload. I would like to utilize the Apollo Lake GPIO driver > > > (drivers/gpio/intel_gpio.c), but I struggle with the dependencies. > > > > > > For my use case, I face 2 obstacles: > > > > > > 1) Some required drivers are not built > > > > > > The Apollo Lake GPIO driver requires the P2SB and ITSS drivers, but > > > those > > > are located in arch/x86/cpu/apollolake. Drivers in this directory are > > > not > > > included in my build as it builds for Coreboot, not for Apollo Lake. > > > > > > 2) Some header files are not found > > > > > > The header files gpio.h and itss.h are located in > > > arch/x86/include/asm/arch-apollolake, but as I build for Coreboot the > > > symlink arch/x86/include/asm/arch points to arch-coreboot instead of > > > arch-apollolake, so those header files are not found. > > > > > > Does anyone have recommendations on how to solve those issues? > > > Would it be possible to move the drivers for P2SB and ITSS out of > > > arch/x86/cpu/apollolake to the generic drivers/ directory? > > > > I don't have any great ideas. At present we rely on the device tree to > > bind these drivers but I suppose we could add the PCI IDs and then the > > coreboot target could bind them. > > I have added the relevant entries in my device tree, the point is that the > required drivers are not even built, because they are located in the > Apollo Lake directory. This is why I asked wheter we could move them to the > generic drivers directory. (This could also make sense IMHO as they are not > specific for Apollo Lake, but could be used for mulitple generations of chips) Yes that sounds OK to me. > > Also the header files are not found during compilation, as the symlink for > "arch" points to "arch-coreboot" in my case, not to "arch-apollolake" where > the header files are located. > > At the moment I have modified the build system so taht the drivers are > compiled for my setup. This works, and the drivers are correctly bound > according to the device tree entries. But this is just a hack, not a proper > solution. > > > I did send a series to add checks to skip low-level init as needed > > when running from coreboot: > > > > http://patchwork.ozlabs.org/project/uboot/list/?series=149993 > > Thanks for pointing that out, I have missed it on the mailing list. > I will have a look at them. > > Btw, did you see my patches regarding fixes for Apollo Lake GPIO and SPI? > > GPIO: https://patchwork.ozlabs.org/patch/1220857/ > SPI:https://patchwork.ozlabs.org/patch/1222779/ Yes looks good. Will review. > > > You're welcome. I'm expecting to have full ACPI support around the end > > of the month. > > If I can help by testing I would be interested. > What is the current state? What is still missing? The current state as of early January is that the ACPI tables for Coral are complete with the possible exception of USB. It builds and boots Linux but there is a lot of cleaning up to do. I've created some rough commits - see u-boot-dm/acpi-working There are about 40 commits left to clean up. I still expect to have this done around the end of January. Regards, Simon
[RFC PATCH] Provide mechanism for build-time default env entries
This enables the building user to specify environment values to be
included in the static default_environment with an image. This is
useful to build multiple otherwise like configured images, varying
by environment unique entries.
---
I expected something like this to already be present, but couldn't
find such a mechanism. I also assumed that something similar may
have been proposed previously, but also couldn't find anything via
searching.
Signed-off-by: Joel Johnson
---
env/Kconfig | 19 +++
include/env_default.h | 3 +++
2 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/env/Kconfig b/env/Kconfig
index ed12609f6a..5049cb78be 100644
--- a/env/Kconfig
+++ b/env/Kconfig
@@ -556,14 +556,25 @@ config SYS_RELOC_GD_ENV_ADDR
Relocate the early env_addr pointer so we know it is not inside
the binary. Some systems need this and for the rest, it doesn't hurt.
+config USER_ENV_SETTINGS
+ string "User build-time additional environment entries"
+ help
+ This value is reserved for the building user to provide custom
+ environment entries to be added to the default environment. Care must
+ be taken to not break the environment, incompatible entries may cause
+ failure to compile, or failure of the target board to properly
+ initialize or boot. The format is key=value pairs, with entries
+ separated by C-style escaped null terminated values, such as:
+ "key1=valueA\0key2=valueB\0key3=valueC".
+
config USE_DEFAULT_ENV_FILE
bool "Create default environment from file"
help
Normally, the default environment is automatically generated
- based on the settings of various CONFIG_* options, as well
- as the CONFIG_EXTRA_ENV_SETTINGS. By selecting this option,
- you can instead define the entire default environment in an
- external file.
+ based on the settings of various CONFIG_* options, combined with
values
+ of board specific CONFIG_EXTRA_ENV_SETTINGS and user provided
+ CONFIG_USER_ENV_SETTINGS. By selecting this option, you can instead
+ define the entire default environment in an external file.
config DEFAULT_ENV_FILE
string "Path to default environment file"
diff --git a/include/env_default.h b/include/env_default.h
index 56a8bae39a..9396a34715 100644
--- a/include/env_default.h
+++ b/include/env_default.h
@@ -109,6 +109,9 @@ const uchar default_environment[] = {
#endif
#ifdef CONFIG_EXTRA_ENV_SETTINGS
CONFIG_EXTRA_ENV_SETTINGS
+#endif
+#ifdef CONFIG_USER_ENV_SETTINGS
+ CONFIG_USER_ENV_SETTINGS
#endif
"\0"
#else /* CONFIG_USE_DEFAULT_ENV_FILE */
--
2.20.1
Re: [PATCH 0/4] Updates for ClearFog EEPROM
On 2020-01-19 00:22, Baruch Siach wrote: Hi Joel, On Sun, Jan 19 2020, Joel Johnson wrote: This set of patches applies on top of https://patchwork.ozlabs.org/cover/1200324/, based on testing using the static configuration fallback updates in a related patch series. Thank you very much. I'm currently working on an updated series with some significant changes. These include rename of sys_eeprom to tlv_eeprom; move of TLV parse code to board/solidrun/common/; and support for TLV read in pre-relocation phase. I'll add your fixes where applicable. I hope to post v2 in the coming week. baruch Sounds good, thanks! I'm also getting ready to shoot out a V2 of my static ClearFog Base support which based on prior review I've rebased on your run-time config series. If it works for you, I'll go ahead and still send that out for review, modulo your further changes. Are you expecting the TLV/EEPROM change updates to be included in time for the current merge window? Joel
Re: [PATCH 0/4] Updates for ClearFog EEPROM
Hi Joel,
On Sun, Jan 19 2020, Joel Johnson wrote:
> This set of patches applies on top of
> https://patchwork.ozlabs.org/cover/1200324/,
> based on testing using the static configuration fallback updates in a
> related patch series.
Thank you very much.
I'm currently working on an updated series with some significant
changes. These include rename of sys_eeprom to tlv_eeprom; move of TLV
parse code to board/solidrun/common/; and support for TLV read in
pre-relocation phase. I'll add your fixes where applicable.
I hope to post v2 in the coming week.
baruch
> Joel Johnson (4):
> cmd: sys_eeprom: add missing implicit header
> cmd: sys_eeprom reflect I2C dependency in Kconfig
> arm: mvebu: clearfog: don't set SPL misc
> arm: mvebu: clearfog: fix compile w/o EEPROM
>
> board/solidrun/clearfog/clearfog.c | 26 +++---
> cmd/Kconfig| 1 +
> cmd/sys_eeprom.c | 1 +
> configs/clearfog_defconfig | 1 -
> 4 files changed, 17 insertions(+), 12 deletions(-)
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
[PATCH 4/4] arm: mvebu: clearfog: fix compile w/o EEPROM
Add conditional checks to ensure still builds without warnings when
the EEPROM runtime detection is disabled via config.
Signed-off-by: Joel Johnson
---
board/solidrun/clearfog/clearfog.c | 26 +++---
1 file changed, 15 insertions(+), 11 deletions(-)
diff --git a/board/solidrun/clearfog/clearfog.c
b/board/solidrun/clearfog/clearfog.c
index f407f744bf..031accaf64 100644
--- a/board/solidrun/clearfog/clearfog.c
+++ b/board/solidrun/clearfog/clearfog.c
@@ -87,6 +87,18 @@ static struct mv_ddr_topology_map board_topology_map = {
0x3,/* clock enable mask */
};
+static bool sr_product_is(const char *product)
+{
+ /* Allow prefix sub-string match */
+ if (strncmp(tlv_product_name[0], product, strlen(product)) == 0)
+ return true;
+ if (strncmp(tlv_product_name[1], product, strlen(product)) == 0)
+ return true;
+
+ return false;
+}
+
+#if defined (CONFIG_SPL_CMD_SYS_EEPROM)
static void store_product_name(tlvinfo_tlv_t *tlv_entry)
{
int len;
@@ -104,17 +116,6 @@ static void store_product_name(tlvinfo_tlv_t *tlv_entry)
memcpy(dest, tlv_entry->value, len);
}
-static bool sr_product_is(const char *product)
-{
- /* Allow prefix sub-string match */
- if (strncmp(tlv_product_name[0], product, strlen(product)) == 0)
- return true;
- if (strncmp(tlv_product_name[1], product, strlen(product)) == 0)
- return true;
-
- return false;
-}
-
static void parse_tlv_vendor_ext(tlvinfo_tlv_t *tlv_entry)
{
struct if_params *ifp = _topology_map.interface_params[0];
@@ -172,9 +173,11 @@ static void parse_tlv_data(uint8_t *eeprom,
tlvinfo_header_t *hdr,
tlv_offset += sizeof(tlvinfo_tlv_t) + entry->length;
}
}
+#endif
static void read_tlv_data(void)
{
+#if defined (CONFIG_SPL_CMD_SYS_EEPROM)
uint8_t eeprom_data[TLV_TOTAL_LEN_MAX];
tlvinfo_header_t *tlv_hdr;
tlvinfo_tlv_t *tlv_entry;
@@ -204,6 +207,7 @@ static void read_tlv_data(void)
board_serdes_map[4].serdes_speed = SERDES_SPEED_5_GBPS;
board_serdes_map[4].serdes_mode = SERDES_DEFAULT_MODE;
}
+#endif
}
struct mv_ddr_topology_map *mv_ddr_topology_map_get(void)
--
2.20.1
[PATCH 3/4] arm: mvebu: clearfog: don't set SPL misc
With SPL_DRIVERS_MISC_SUPPORT being depended on by SPL_CMD_SYS_EEPROM, there is no longer a need to set it separately. Signed-off-by: Joel Johnson --- configs/clearfog_defconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/configs/clearfog_defconfig b/configs/clearfog_defconfig index e932f9c195..9483bbc546 100644 --- a/configs/clearfog_defconfig +++ b/configs/clearfog_defconfig @@ -13,7 +13,6 @@ CONFIG_SPL_MMC_SUPPORT=y CONFIG_SPL_SERIAL_SUPPORT=y CONFIG_ENV_SIZE=0x1 CONFIG_ENV_OFFSET=0xF -CONFIG_SPL_DRIVERS_MISC_SUPPORT=y CONFIG_NR_DRAM_BANKS=2 CONFIG_SPL=y CONFIG_DEBUG_UART_BASE=0xd0012000 -- 2.20.1
[PATCH 2/4] cmd: sys_eeprom reflect I2C dependency in Kconfig
Given that {read,write}_sys_eeprom hardcode reading from I2C EEPROM
devices, make the config dependency reflect this fact.
This allows config to handle cases such as the following, which
previously failed to build.
CONFIG_SPL_DRIVERS_MISC_SUPPORT=n
CONFIG_CMD_SYS_EEPROM=y
CONFIG_SPL_CMD_SYS_EEPROM=y
CONFIG_I2C_EEPROM=y
CONFIG_SPL_I2C_EEPROM=y
Signed-off-by: Joel Johnson
---
cmd/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 1965245f90..e37c1c6f58 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -250,6 +250,7 @@ config CMD_SYS_EEPROM
config SPL_CMD_SYS_EEPROM
bool "sys_eeprom for SPL"
+ depends on SPL_DRIVERS_MISC_SUPPORT
depends on SPL_I2C_EEPROM
help
Read system EEPROM data block.
--
2.20.1
[PATCH 1/4] cmd: sys_eeprom: add missing implicit header
This addresses the following compiler warning: ../cmd/sys_eeprom.c: In function ‘is_checksum_valid’: ../cmd/sys_eeprom.c:96:13: warning: implicit declaration of function ‘crc32’ [-Wimplicit-function-declaration] calc_crc = crc32(0, (void *)eeprom, ^ Signed-off-by: Joel Johnson --- cmd/sys_eeprom.c | 1 + 1 file changed, 1 insertion(+) diff --git a/cmd/sys_eeprom.c b/cmd/sys_eeprom.c index 373673a526..9e9c1ae8ff 100644 --- a/cmd/sys_eeprom.c +++ b/cmd/sys_eeprom.c @@ -12,6 +12,7 @@ #include #include #include +#include #include "sys_eeprom.h" -- 2.20.1
[PATCH 0/4] Updates for ClearFog EEPROM
This set of patches applies on top of https://patchwork.ozlabs.org/cover/1200324/, based on testing using the static configuration fallback updates in a related patch series. Joel Johnson (4): cmd: sys_eeprom: add missing implicit header cmd: sys_eeprom reflect I2C dependency in Kconfig arm: mvebu: clearfog: don't set SPL misc arm: mvebu: clearfog: fix compile w/o EEPROM board/solidrun/clearfog/clearfog.c | 26 +++--- cmd/Kconfig| 1 + cmd/sys_eeprom.c | 1 + configs/clearfog_defconfig | 1 - 4 files changed, 17 insertions(+), 12 deletions(-) -- 2.20.1
Re: [PATCH v2 01/21] mips: add support to restore exception vector base before booting linux
On Fri, 2020-01-17 at 13:15 +0100, Daniel Schwierzeck wrote:
>
> Am 17.01.20 um 08:45 schrieb Weijie Gao:
> > In U-Boot the exception vector base will be moved to top of memory, to be
> > used to display register dump when exception occurs.
> >
> > But some old linux kernel does not honor the base set in CP0_EBASE. A
> > modified exception vector base will cause kernel crash.
> >
> > This patch adds an option to enable reset exception vector base to its
> > previous value, or a user configured value before booting linux kernel.
> >
> > Signed-off-by: Weijie Gao
> > ---
> > Changes since v1:
> > Moved core operations to trap_restore() in arch/mips/lib/traps.c.
> > Save previous ebase instead of using 0x8000 directly.
> > Add options to use customized ebase.
> > ---
> > arch/mips/Kconfig | 30 +
> > arch/mips/include/asm/u-boot-mips.h | 2 ++
> > arch/mips/lib/bootm.c | 3 +++
> > arch/mips/lib/traps.c | 19 ++
> > 4 files changed, 54 insertions(+)
> >
> > diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
> > index a3ae603044..5e20feeefb 100644
> > --- a/arch/mips/Kconfig
> > +++ b/arch/mips/Kconfig
> > @@ -287,6 +287,36 @@ config MIPS_RELOCATION_TABLE_SIZE
> >
> > If unsure, leave at the default value.
> >
> > +config RESTORE_EXCEPTION_VECTOR_BASE
> > + bool "Restore exception vector base before booting linux kernel"
> > + default n
> > + help
> > + In U-Boot the exception vector base will be moved to top of memory,
> > + to be used to display register dump when exception occurs.
> > + But some old linux kernel does not honor the base set in CP0_EBASE.
> > + A modified exception vector base will cause kernel crash.
> > +
> > + This option will restore the exception vector base to its previous
> > + value.
> > +
> > + If unsure, say N.
> > +
> > +config OVERRIDE_EXCEPTION_VECTOR_BASE
> > + bool "Override the exception vector base to be restored"
> > + depends on RESTORE_EXCEPTION_VECTOR_BASE
> > + default n
> > + help
> > + Enable this option if you want to use a different exception vector
> > + base rather than the previously saved one.
> > +
> > +config NEW_EXCEPTION_VECTOR_BASE
> > + hex "New exception vector base"
> > + depends on OVERRIDE_EXCEPTION_VECTOR_BASE
> > + range 0x8000 0xb000
> > + default 0x8000
> > + help
> > + The exception vector base to be restored before booting linux kernel
> > +
> > endmenu
> >
> > menu "OS boot interface"
> > diff --git a/arch/mips/include/asm/u-boot-mips.h
> > b/arch/mips/include/asm/u-boot-mips.h
> > index 88438b9576..8b37cc4029 100644
> > --- a/arch/mips/include/asm/u-boot-mips.h
> > +++ b/arch/mips/include/asm/u-boot-mips.h
> > @@ -9,4 +9,6 @@ void except_vec_ejtag_debug(void);
> >
> > int arch_misc_init(void);
> >
> > +void trap_restore(void);
> > +
> > #endif /* _U_BOOT_MIPS_H_ */
> > diff --git a/arch/mips/lib/bootm.c b/arch/mips/lib/bootm.c
> > index 8c0d7672f2..f1db6d23b8 100644
> > --- a/arch/mips/lib/bootm.c
> > +++ b/arch/mips/lib/bootm.c
> > @@ -294,6 +294,9 @@ static void boot_jump_linux(bootm_headers_t *images)
> > bootstage_report();
> > #endif
> >
> > + if (CONFIG_IS_ENABLED(RESTORE_EXCEPTION_VECTOR_BASE))
> > + trap_restore();
> > +
> > if (images->ft_len)
> > kernel(-2, (ulong)images->ft_addr, 0, 0);
> > else
> > diff --git a/arch/mips/lib/traps.c b/arch/mips/lib/traps.c
> > index 6fe8ebd16b..20f45fc4ed 100644
> > --- a/arch/mips/lib/traps.c
> > +++ b/arch/mips/lib/traps.c
> > @@ -19,6 +19,8 @@
> >
> > DECLARE_GLOBAL_DATA_PTR;
> >
> > +static unsigned long saved_ebase;
> > +
> > static void show_regs(const struct pt_regs *regs)
> > {
> > const int field = 2 * sizeof(unsigned long);
> > @@ -101,7 +103,24 @@ void trap_init(ulong reloc_addr)
> > set_handler(0x180, _vec3_generic, 0x80);
> > set_handler(0x280, _vec_ejtag_debug, 0x80);
> >
> > + saved_ebase = read_c0_ebase() & 0xf000;
> > +
> > write_c0_ebase(ebase);
> > clear_c0_status(ST0_BEV);
> > execution_hazard_barrier();
> > }
> > +
> > +void trap_restore(void)
> > +{
> > + set_c0_status(ST0_BEV);
> > + execution_hazard_barrier();
> > +
> > +#ifdef CONFIG_OVERRIDE_EXCEPTION_VECTOR_BASE
> > + write_c0_ebase(CONFIG_NEW_EXCEPTION_VECTOR_BASE & 0xf000);
> > +#else
> > + write_c0_ebase(saved_ebase);
> > +#endif
> > +
> > + clear_c0_status(ST0_BEV);
> > + execution_hazard_barrier();
> > +}
> >
>
> looks actually good now, thanks. But now I'm thinking that it should be
> enough to simply set ST0_BEV to use the CPU's default EBase. Restoring
> the original EBase and clearing ST0_BEV again seems redundant. How about
> this?
>
> void trap_restore(void)
> {
> set_c0_status(ST0_BEV);
> execution_hazard_barrier();
>
> #ifdef CONFIG_OVERRIDE_EXCEPTION_VECTOR_BASE
>
Re: [PATCH v2 19/21] mips: mtmips: add SPL support
On Fri, 2020-01-17 at 15:55 +0100, Stefan Roese wrote:
> Added Mauro to Cc
>
> On 17.01.20 08:46, Weijie Gao wrote:
> > This patch adds SPL support for mtmips platform. The lowlevel architecture
> > is split into SPL and the rest parts are built into a memory loadable
> > u-boot image. Optional SPL_DM and OF_CONTROL are also supported.
> >
> > The increment of size is very small (< 10 KiB) if SPL_DM and OF_CONTROL are
> > not enabled and the memory bootable u-boot (u-boot.img) is generated
> > automatically so there is not need to add a separate config for it.
> >
> > A lzma compressed payload (u-boot-lzma.img) is also generated and it will
> > be combined with u-boot-spl.bin to form the unified ROM bootable binary
> > u-boot-mtmips.bin.
> >
> > A spl loader is added to support uncompress the payload.
> >
> > Signed-off-by: Weijie Gao
> > ---
> > Changes since v1:
> >move spl loader into this patch.
> >add full pinmux for all three uarts.
> >add optional DM & DT support.
> > ---
> > Makefile| 9 ++
> > arch/mips/Kconfig | 3 +
> > arch/mips/dts/mt7628-u-boot.dtsi| 24
> > arch/mips/mach-mtmips/Kconfig | 24
> > arch/mips/mach-mtmips/Makefile | 1 +
> > arch/mips/mach-mtmips/include/mach/serial.h | 13 +++
> > arch/mips/mach-mtmips/include/mach/spl.h| 14 +++
> > arch/mips/mach-mtmips/mt7628/Makefile | 1 +
> > arch/mips/mach-mtmips/mt7628/serial.c | 34 ++
> > arch/mips/mach-mtmips/spl.c | 31 +
> > arch/mips/mach-mtmips/spl_load.c| 121
> > 11 files changed, 275 insertions(+)
> > create mode 100644 arch/mips/dts/mt7628-u-boot.dtsi
> > create mode 100644 arch/mips/mach-mtmips/include/mach/serial.h
> > create mode 100644 arch/mips/mach-mtmips/include/mach/spl.h
> > create mode 100644 arch/mips/mach-mtmips/mt7628/serial.c
> > create mode 100644 arch/mips/mach-mtmips/spl.c
> > create mode 100644 arch/mips/mach-mtmips/spl_load.c
> >
> > diff --git a/Makefile b/Makefile
> > index 8013cbd9f9..1e18a37913 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -895,6 +895,7 @@ ALL-$(CONFIG_OF_SEPARATE) += u-boot-dtb-tegra.bin
> > endif
> >
> > ALL-$(CONFIG_ARCH_MEDIATEK) += u-boot-mtk.bin
> > +ALL-$(CONFIG_ARCH_MTMIPS) += u-boot-mtmips.bin
> >
> > # Add optional build target if defined in board/cpu/soc headers
> > ifneq ($(CONFIG_BUILD_TARGET),)
> > @@ -1664,6 +1665,14 @@ u-boot-mtk.bin: u-boot.bin FORCE
> > $(call if_changed,mkimage)
> > endif
> >
> > +ifeq ($(CONFIG_SPL),y)
> > +u-boot-mtmips.bin: u-boot.dtb u-boot-lzma.img spl/u-boot-spl.bin FORCE
> > + $(call if_changed,binman)
> > +else
> > +u-boot-mtmips.bin: u-boot.bin FORCE
> > + $(call if_changed,copy)
> > +endif
> > +
> > ARCH_POSTLINK := $(wildcard $(srctree)/arch/$(ARCH)/Makefile.postlink)
> >
> > # Rule to link u-boot
> > diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
> > index 5f82caf8be..5f74f549b5 100644
> > --- a/arch/mips/Kconfig
> > +++ b/arch/mips/Kconfig
> > @@ -98,6 +98,9 @@ config ARCH_MTMIPS
> > select SUPPORTS_CPU_MIPS32_R2
> > select SUPPORTS_LITTLE_ENDIAN
> > select SYSRESET
> > + select SUPPORT_SPL
> > + select SPL_LZMA
> > + select BINMAN
> >
> > config ARCH_JZ47XX
> > bool "Support Ingenic JZ47xx"
> > diff --git a/arch/mips/dts/mt7628-u-boot.dtsi
> > b/arch/mips/dts/mt7628-u-boot.dtsi
> > new file mode 100644
> > index 00..213959105f
> > --- /dev/null
> > +++ b/arch/mips/dts/mt7628-u-boot.dtsi
> > @@ -0,0 +1,24 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2020 MediaTek Inc.
> > + *
> > + * Author: Weijie Gao
> > + */
> > +
> > +/ {
> > + binman {
> > + filename = "u-boot-mtmips.bin";
> > + pad-byte = <0xff>;
> > +
> > +#ifdef CONFIG_SPL
> > + u-boot-spl {
> > + };
> > +
> > + u-boot-lzma-img {
> > + };
> > +#else
> > + u-boot {
> > + };
> > +#endif
> > + };
> > +};
> > diff --git a/arch/mips/mach-mtmips/Kconfig b/arch/mips/mach-mtmips/Kconfig
> > index 3f25de8b85..9b42d5b581 100644
> > --- a/arch/mips/mach-mtmips/Kconfig
> > +++ b/arch/mips/mach-mtmips/Kconfig
> > @@ -20,8 +20,16 @@ config SYS_ICACHE_LINE_SIZE
> > default 32
> >
> > config SYS_TEXT_BASE
> > + default 0x9c00 if !SPL
> > + default 0x8020 if SPL
> > +
> > +config SPL_TEXT_BASE
> > default 0x9c00
> >
> > +config SPL_LOADER_SUPPORT
> > + bool
> > + default y
> > +
> > choice
> > prompt "MediaTek MIPS SoC select"
> >
> > @@ -34,6 +42,14 @@ config SOC_MT7628
> > select PINCTRL_MT7628
> > select MTK_SERIAL
> > select SYSRESET_RESETCTL
> > + select SPL_SEPARATE_BSS if SPL
> > + select SPL_INIT_STACK_WITHOUT_MALLOC_F if SPL
> > + select SPL_OF_CONTROL if SPL_DM
> > + select SPL_SIMPLE_BUS if
Re: [PATCH v2 13/21] dts: mtmips: add alternative pinmux node for uart2
On Fri, 2020-01-17 at 15:50 +0100, Stefan Roese wrote:
> Added Mauro to Cc
>
> On 17.01.20 08:46, Weijie Gao wrote:
> > This patch adds a new pinmux for UART2, which shares the pins with SPIS.
> >
> > Signed-off-by: Weijie Gao
> > ---
> > Changes since v1: newly added
> > ---
> > arch/mips/dts/mt7628a.dtsi | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/arch/mips/dts/mt7628a.dtsi b/arch/mips/dts/mt7628a.dtsi
> > index 744594c45a..f265cb6ad9 100644
> > --- a/arch/mips/dts/mt7628a.dtsi
> > +++ b/arch/mips/dts/mt7628a.dtsi
> > @@ -93,6 +93,11 @@
> > function = "uart2";
> > };
> >
> > + uart2_pwm_pins: uart2_pwm_pins {
> > + groups = "spis";
> > + function = "pwm_uart2";
> > + };
> > +
>
> Thanks. AFAIK, this will not be used by any of the currently supported
> boards. Is this correct?
Yes.
>
> Mauro is currently trying to port mainline U-Boot to the VoCore2 board
> which also uses UART2. I did not look to close, but might this pin mux
> option here be necessary for this VoCore2 board?
Yes. I added this because of your discussions about the pinmux.
I've tested this pinmux and it worked well. I believe it's necessary for
the VoCore2.
>
> Thanks,
> Stefan
Re: [PATCH v2 11/21] dts: mtmips: remove all unusable nodes and properties from mt7628s.dtsi
On Fri, 2020-01-17 at 15:42 +0100, Stefan Roese wrote:
> On 17.01.20 08:45, Weijie Gao wrote:
> > This patch removes all unused and unusable nodes and properties from
> > mt7628s.dtsi.
> >
> > Signed-off-by: Weijie Gao
> > ---
> > Changes since v1: splitted from another patch
>
> Please don't remove the unused parts. As mentioned before, we try to
> stay as close to the official DT files from the Linux tree as possible.
> Goal is to sync with Linux at some time. This is already done on other
> architectures / boards.
OK. I'll drop this one.
>
> Thanks,
> Stefan
>
> > ---
> > arch/mips/dts/mt7628a.dtsi | 68 --
> > 1 file changed, 68 deletions(-)
> >
> > diff --git a/arch/mips/dts/mt7628a.dtsi b/arch/mips/dts/mt7628a.dtsi
> > index cdc643fe37..3d7b839e6d 100644
> > --- a/arch/mips/dts/mt7628a.dtsi
> > +++ b/arch/mips/dts/mt7628a.dtsi
> > @@ -7,24 +7,6 @@
> > #size-cells = <1>;
> > compatible = "ralink,mt7628a-soc";
> >
> > - cpus {
> > - #address-cells = <1>;
> > - #size-cells = <0>;
> > -
> > - cpu@0 {
> > - compatible = "mti,mips24KEc";
> > - device_type = "cpu";
> > - reg = <0>;
> > - };
> > - };
> > -
> > - cpuintc: interrupt-controller {
> > - #address-cells = <0>;
> > - #interrupt-cells = <1>;
> > - interrupt-controller;
> > - compatible = "mti,cpu-interrupt-controller";
> > - };
> > -
> > clk48m: clk48m@0 {
> > compatible = "fixed-clock";
> >
> > @@ -41,11 +23,6 @@
> > #address-cells = <1>;
> > #size-cells = <1>;
> >
> > - sysc: system-controller@0 {
> > - compatible = "ralink,mt7620a-sysc", "syscon";
> > - reg = <0x0 0x100>;
> > - };
> > -
> > resetctl-reboot {
> > compatible = "resetctl-reboot";
> >
> > @@ -223,32 +200,6 @@
> >
> > resets = < MT7628_TIMER_RST>;
> > reset-names = "wdt";
> > -
> > - interrupt-parent = <>;
> > - interrupts = <24>;
> > - };
> > -
> > - intc: interrupt-controller@200 {
> > - compatible = "ralink,rt2880-intc";
> > - reg = <0x200 0x100>;
> > -
> > - interrupt-controller;
> > - #interrupt-cells = <1>;
> > -
> > - resets = < MT7628_INT_RST>;
> > - reset-names = "intc";
> > -
> > - interrupt-parent = <>;
> > - interrupts = <2>;
> > -
> > - ralink,intc-registers = <0x9c 0xa0
> > -0x6c 0xa4
> > -0x80 0x78>;
> > - };
> > -
> > - memory-controller@300 {
> > - compatible = "ralink,mt7620a-memc";
> > - reg = <0x300 0x100>;
> > };
> >
> > gpio@600 {
> > @@ -261,9 +212,6 @@
> > resets = < MT7628_PIO_RST>;
> > reset-names = "pio";
> >
> > - interrupt-parent = <>;
> > - interrupts = <6>;
> > -
> > gpio0: bank@0 {
> > reg = <0>;
> > compatible = "mtk,mt7621-gpio-bank";
> > @@ -311,9 +259,6 @@
> > resets = < MT7628_UART0_RST>;
> > reset-names = "uart0";
> >
> > - interrupt-parent = <>;
> > - interrupts = <20>;
> > -
> > reg-shift = <2>;
> > };
> >
> > @@ -329,9 +274,6 @@
> > resets = < MT7628_UART1_RST>;
> > reset-names = "uart1";
> >
> > - interrupt-parent = <>;
> > - interrupts = <21>;
> > -
> > reg-shift = <2>;
> > };
> >
> > @@ -347,9 +289,6 @@
> > resets = < MT7628_UART2_RST>;
> > reset-names = "uart2";
> >
> > - interrupt-parent = <>;
> > - interrupts = <22>;
> > -
> > reg-shift = <2>;
> > };
> > };
> > @@ -361,8 +300,6 @@
> >
> > resets = < MT7628_EPHY_RST>;
> > reset-names = "ephy";
> > -
> > - syscon = <>;
> > };
> >
> > usb_phy: usb-phy@1012 {
> > @@ -371,8 +308,6 @@
> >
> > #phy-cells = <0>;
> >
> > - ralink,sysctl = <>;
> > -
> > resets = < MT7628_UPHY_RST>;
> > reset-names = "phy";
> >
> > @@ -386,9 +321,6 @@
> >
> > phys = <_phy>;
> > phy-names = "usb";
> > -
> > - interrupt-parent = <>;
> > - interrupts = <18>;
> > };
> >
> > mmc: mmc@1013 {
> >
>
> Viele
Re: [PATCH v2 00/21] Refactor the architecture parts of mt7628
On Fri, 2020-01-17 at 15:40 +0100, Stefan Roese wrote: > Hi Weijie, > > I've added another of my mail addresses to cc (m...@roese.nl) as the > sending to the other 2 addresses does not seem to work. > > On 17.01.20 08:45, Weijie Gao wrote: > > This patch series are divided into two parts: > > > > The main part is to rewrite the whole architecture code of mt7628: > > 1. Lock parts of the d-cache for initial stack so the rest of the code can > > be reimplemented in C. > > 2. Memory controller & DDR initialization have been fully written to support > > detecting DDR size automatically. > > 3. DDR calibration has also been reimplemented with a clear logic. > > 4. Implemented a new sysreset driver to take advantage of the reset > > controller so we can drop the use of syscon-based sysreset to reduce > > size. > > > > The second part is to add SPL support for mt7628: > > 1. With SPL enabled we can build the ROM-bootable and RAM-bootable binary > > simultaneously, and we can drop RAM boot related configs and defconfig > > files. > > 2. Generate compressed u-boot.bin image for SPL to reduce size of final > > combined binary. > > 3. Enable DM support for SPL for a more flexible device probing. > > 4. Add a demo board (mt7628_rfb) aims at router application. > > > > Changes since v1: > > 1. Split 'mips: mtmips: rewrite lowlevel codes of mt7628' into multiple > > patches. > > 2. Dropped a patch which tried to use customized get_tbclk(). > > 3. Dropped a patch which tried to rename mt7628a.dtsi to mt7628.dtsi > > 4. Refactor the patch which restores exception vector base before booting > > linux. > > 5. Define a new option to enable u_boot_list in SPL. > > 6. Enable compressed spl payload for all boards. > > 7. Enable DM and DT support for linkit and gardena-smart-gateway. > > 8. Complete pinmux for all three UARTs for SPL. > > 9. Rewrite u_boot_lzma_img.py. > > > > Weijie Gao (21): > > It seems that patch 09/21 is missing on the list. Is it stuck in > moderation? Or is the patch numbering corrupt? > > Thanks, > Stefan It's missing on my list. I've resent it.
Re: [PATCH] arm: Enable VIDEO_BPP32 on pinebook.
Hi,
On Sat, Jan 18, 2020 at 03:15:15AM -0800, Vagrant Cascadian wrote:
> Video output on the pinebook LCD screen was broken by:
>
> commit 2cc393f32fd9 ("video: make BPP and ANSI configs optional").
>
> Enable VIDEO_BPP32 which was previously enabled by default when
> DM_VIDEO was set.
>
> Signed-off-by: Vagrant Cascadian
There's nothing really specific about the pinebook here, but it's
needed for pretty much all the boards using DM_VIDEO (on Allwinner at
least).
You should add a kconfig select / default instead
Maxime
[PATCH v2 09/21] mips: add a option to support not reserving malloc space on initial stack
The initial stack on some platforms is too small to hold a large malloc space. This patch adds a option to allow these platforms not reserving the malloc space on initial stack. These platforms should set the malloc base after DRAM is usable. Signed-off-by: Weijie Gao --- Changes since v1: newly added --- arch/mips/Kconfig | 18 ++ arch/mips/cpu/start.S | 6 -- 2 files changed, 22 insertions(+), 2 deletions(-) diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index bf30a56101..5f82caf8be 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -317,6 +317,24 @@ config NEW_EXCEPTION_VECTOR_BASE help The exception vector base to be restored before booting linux kernel +config INIT_STACK_WITHOUT_MALLOC_F + bool "Do not reserve malloc space on initial stack" + default n + help + Enable this option if you don't want to reserve malloc space on + initial stack. This is useful if the initial stack can't hold large + malloc space. Platform should set the malloc_base later when DRAM is + ready to use. + +config SPL_INIT_STACK_WITHOUT_MALLOC_F + bool "Do not reserve malloc space on initial stack in SPL" + default n + help + Enable this option if you don't want to reserve malloc space on + initial stack. This is useful if the initial stack can't hold large + malloc space. Platform should set the malloc_base later when DRAM is + ready to use. + endmenu menu "OS boot interface" diff --git a/arch/mips/cpu/start.S b/arch/mips/cpu/start.S index dd93df9e4a..6de9a2f362 100644 --- a/arch/mips/cpu/start.S +++ b/arch/mips/cpu/start.S @@ -59,7 +59,8 @@ sp, sp, GD_SIZE # reserve space for gd and sp, sp, t0 # force 16 byte alignment movek0, sp # save gd pointer -#if CONFIG_VAL(SYS_MALLOC_F_LEN) +#if CONFIG_VAL(SYS_MALLOC_F_LEN) && \ +!CONFIG_IS_ENABLED(INIT_STACK_WITHOUT_MALLOC_F) li t2, CONFIG_VAL(SYS_MALLOC_F_LEN) PTR_SUBU \ sp, sp, t2 # reserve space for early malloc @@ -75,7 +76,8 @@ blt t0, t1, 1b nop -#if CONFIG_VAL(SYS_MALLOC_F_LEN) +#if CONFIG_VAL(SYS_MALLOC_F_LEN) && \ +!CONFIG_IS_ENABLED(INIT_STACK_WITHOUT_MALLOC_F) PTR_S sp, GD_MALLOC_BASE(k0) # gd->malloc_base offset #endif .endm -- 2.17.1
Re: [PATCH] config_whitelist: Remove CONFIG_MX6UL_14X14_EVK_EMMC_REWORK
On Sat, Jan 18, 2020 at 04:52:15PM -0300, Fabio Estevam wrote:
> Since commit bcc70bc863af ("mx6ul_14x14_evk: Fix SPL boot hang") the symbol
> CONFIG_MX6UL_14X14_EVK_EMMC_REWORK is no longer used, so remove it from
> the white list too.
>
> Signed-off-by: Fabio Estevam
> ---
> scripts/config_whitelist.txt | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
> index cd154738a4..9e1b651446 100644
> --- a/scripts/config_whitelist.txt
> +++ b/scripts/config_whitelist.txt
> @@ -1167,7 +1167,6 @@ CONFIG_MX35_HCLK_FREQ
> CONFIG_MX6DL_LPDDR2
> CONFIG_MX6DQ_LPDDR2
> CONFIG_MX6SX_SABRESD_REVA
> -CONFIG_MX6UL_14X14_EVK_EMMC_REWORK
> CONFIG_MXC_EPDC
> CONFIG_MXC_GPT_HCLK
> CONFIG_MXC_MCI_REGS_BASE
This file is automatically generated, I'll resync it shortly. Thanks.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH] arm: Enable VIDEO_BPP32 on pinebook.
On Sat, Jan 18, 2020 at 12:03:02PM -0800, Vagrant Cascadian wrote:
> On 2020-01-18, Maxime Ripard wrote:
> > On Sat, Jan 18, 2020 at 03:15:15AM -0800, Vagrant Cascadian wrote:
> >> Video output on the pinebook LCD screen was broken by:
> >>
> >> commit 2cc393f32fd9 ("video: make BPP and ANSI configs optional").
> >>
> >> Enable VIDEO_BPP32 which was previously enabled by default when
> >> DM_VIDEO was set.
> >>
> >> Signed-off-by: Vagrant Cascadian
> >
> > There's nothing really specific about the pinebook here, but it's
> > needed for pretty much all the boards using DM_VIDEO (on Allwinner at
> > least).
> >
> > You should add a kconfig select / default instead
>
> That would basically revert 2cc393f32fd9, and I figured there was a
> reason for it...
>
> It wouldn't surprise me that other systems are affected, but I only
> notice this issue on the pinebook (most of the systems I use are
> headless), where it definitely needed to be fixed somehow.
>
> If there's a correct and more general fix, please propose it!
Well, looking at 2cc393f32fd9 there are a number of platforms that
enable more than one mode. But maybe we should always have at least one
mode?
--
Tom
signature.asc
Description: PGP signature
Re: u-boot 32-bit on Raspberry Pi 4
On 18/01/2020 04:18, Alexander von Gluck IV wrote:
> January 17, 2020 7:59 PM, "Jaehoon Chung" wrote:
>> On 1/18/20 10:53 AM, Jaehoon Chung wrote:
>>
>>> Hi
>>>
>>> On 1/18/20 9:22 AM, Alexander von Gluck IV wrote:
Has anyone successfully used u-boot on the Raspberry Pi 4 in 32-bit mode?
>>>
>>> I'm using 32-bit u-boot on RPI4 board with Tizen Platform.
>>> You can refer to tizen u-boot git. Also I modified some configurations.
>>>
>>> https://protect2.fireeye.com/url?k=d4848ff3-8957d64d-d48504bc-0cc47a31ba82-40c2c54dba31c6f3=https:
>>> /git.tizen.org/cgit/platform/kernel/u-boot/log/?h=tizen
>>>
>>> enable_uart=1
>>> uart_2ndstage=1
>
> uart_2ndstate=1 helped a lot :-)
>
> I have it figured out now.
>
> I wasn't aware of the change around Raspberry Pi's FDT's needing to
> be on the boot partition for start4.elf.
>
> All of our existing bootloader code depends on the FDT embedded
> into u-boot. (fdtcontroladdr, see below for our boot.scr)
>
> Does u-boot "pick-up" the FDT from the Pi foundation's start4.elf and place
> it at fdtcontroladdr?
>
>
> test -e mmc 0 uEnv.txt && fatload mmc 0 ${scriptaddr} uEnv.txt && env import
> -t ${scriptaddr} ${filesize} \
> fatload mmc 0 ${kernel_addr_r} haiku_loader.ub \
> fatload mmc 0 ${ramdisk_addr_r} haiku_floppyboot.ub \
> env exists dtb && fatload mmc 0 ${fdt_addr_r} ${dtb} && fdt
> addr ${fdt_addr_r} && bootm ${kernel_addr_r} ${ramdisk_addr_r} ${fdt_addr_r} \
> fdt addr ${fdtcontroladdr} && bootm ${kernel_addr_r}
> ${ramdisk_addr_r} ${fdtcontroladdr}"
>
>
> I thought the FDT embedded into u-boot was the "best way" to get it :-|
>
If you want to do that you are still free to do so by changing your config. The
idea is to get rid of the U-Boot DTS as the FW can provide us with one. In the
case of RPi4 it even helps us, as we don't have to deal with the different
versions with 1/2/4 GiB of RAM, as the FW updates the DTB as needed.
If you want to use an embedded device tree you are either bound to one RAM size
or you have to add code to detect the size and update that on the fly.
Feel free to send patches if that's something you are interested in.
Regards,
Matthias
Regards,
Matthias
Re: [PATCH v4 0/6] rsa: extend rsa_verify() for UEFI secure boot
On 11/21/19 1:11 AM, AKASHI Takahiro wrote: # This patch set is a prerequisite for UEFI secure boot. The current rsa_verify() requires five parameters for a RSA public key for efficiency while RSA, in theory, requires only two. In addition, those parameters are expected to come from FIT image. So this function won't fit very well when we want to use it for the purpose of implementing UEFI secure boot, in particular, image authentication as well as variable authentication, where the essential two parameters are set to be retrieved from one of X509 certificates in signature database. So, in this patch, additional three parameters will be calculated on the fly when rsa_verify() is called without fdt which should contain parameters above. This calculation heavily relies on "big-number (or multi-precision) library." Therefore some routines from BearSSL[1] under MIT license are imported in this implementation. See Patch#4. # Please let me know if this is not appropriate. Prerequisite: * public key parser in my "import x509/pkcs7 parser" patch[2] # Checkpatch will complain with lots of warnings/errors, but # I intentionally don't fix them for maximum maintainability. [1] https://bearssl.org/ [2] https://lists.denx.de/pipermail/u-boot/2019-November/390127.html Changes in v4 (Nov 21, 2019) * rebased to v2020.01-rc3 * change a function prototype of rsa_gen_key_prop() to return an error code (patch#4,#5) * re-order include files in alphabetical order (patch#6) * add some comments per Simon's review comments Changes in v3 (Nov 13, 2019) * remove RSA_VERIFY_WITH_PKEY, which is to be added in patch#2 (patch#1) * modify unit test Kconfg due to removal of test/lib/Kconfig (patch#6) Changes in v2 (Oct 29, 2019) * fix build errors at Travis CI * not include linux/kconfig.h (patch#1) * add a separate patch for adding CONFIG_RSA_VERIFY_WITH_PKEY (patch#2) * take a prerequisite patch from my "secure boot patch" (patch#3) * add a dependency on RSA_PUBLIC_KEY_PARSER (patch#4) * remove "inline" directives (patch#4) * add function descriptions, which mostly come from BearSSL's src/inner.h (patch#4) * improve Kconfig help text after Simon's comment (patch#5) * add function description of rsa_verify_with_pkey() (patch#5) * modify rsa_verify() to use "if (CONFIG_IS_ENABLED(...) " style rather than "#ifdef CONFIG_..." (patch#5) * add function tests (patch#6) Changes in v1 (Oct 9, 2019) * fix a build error on pine64-lts_defconfig (reported by Heinrich) by defining FIT_IMAGE_ENABLE_VERIFY flag and adding SPL_RSA_VERIFY config (patch#1) * remove FIT-specific code from image-sig.c and put them to new image-fit-sig.c to allow us to disable CONFIG_FIT_SIGNATURE (patch#1) * compile rsa-keyprop.c only if necessary (i.e. if CONFIG_RSA_VERIFY_WITH_PKEY) (patch#2) * add SPDX license identifier in rsa-keyprop.c (patch#2) * include instead of (patch#2) * use U-Boot's byteorder helper functions instead of BearSSL's (patch#2) I tried to test Takahiro's patches and have the following problem: When I add CONFIG_RSA=y, CONFIG_RSA_SOFTWARE_EXP=y to pine64-lts_defconfig SPL restarts again and again after "BL31: Preparing for EL3 exit to normal world ... SPSR = 0x3c9". CONFIG_SPL_RSA does not make a difference. See below So even without Takahiro's patches RSA is a complete failure on this board. Best regards Heinrich U-Boot SPL 2020.01-00620-g2d2f91a480 (Jan 18 2020 - 20:10:54 +) DRAM: 2048 MiB Trying to boot from MMC1 NOTICE: BL31: v2.2(debug):v2.2-351-g5d3ee0764 NOTICE: BL31: Built : 06:50:11, Jan 17 2020 NOTICE: BL31: Detected Allwinner A64/H64/R18 SoC (1689) NOTICE: BL31: Found U-Boot DTB at 0x408ef20, model: Pine64 LTS INFO:ARM GICv2 driver initialized INFO:Configuring SPC Controller INFO:PMIC: Probing AXP803 on RSB INFO:PMIC: dcdc1 voltage: 3.300V INFO:PMIC: dcdc5 voltage: 1.200V INFO:PMIC: dcdc6 voltage: 1.100V INFO:PMIC: dldo1 voltage: 3.300V INFO:PMIC: Enabling DC SW INFO:BL31: Platform setup done INFO:BL31: Initializing runtime services INFO:BL31: cortex_a53: CPU workaround for 843419 was applied INFO:BL31: cortex_a53: CPU workaround for 855873 was applied INFO:BL31: Preparing for EL3 exit to normal world INFO:Entry point address = 0x4a00 INFO:SPSR = 0x3c9 U-Boot SPL 2020.01-00620-g2d2f91a480 (Jan 18 2020 - 20:10:54 +) DRAM: 2048 MiB Trying to boot from MMC1 NOTICE: BL31: v2.2(debug):v2.2-351-g5d3ee0764 NOTICE: BL31: Built : 06:50:11, Jan 17 2020 NOTICE: BL31: Detected Allwinner A64/H64/R18 SoC (1689) NOTICE: BL31: Found U-Boot DTB at 0x408ef20, model: Pine64 LTS INFO:ARM GICv2 driver initialized INFO:Configuring SPC Controller INFO:PMIC: Probing AXP803 on RSB INFO:PMIC: dcdc1 voltage: 3.300V INFO:PMIC: dcdc5 voltage: 1.200V INFO:PMIC: dcdc6 voltage: 1.100V INFO:PMIC: dldo1 voltage: 3.300V INFO:PMIC: Enabling DC SW INFO:BL31: Platform setup done INFO:BL31: Initializing runtime
Re: [PATCH] arm: Enable VIDEO_BPP32 on pinebook.
On 2020-01-18, Maxime Ripard wrote:
> On Sat, Jan 18, 2020 at 03:15:15AM -0800, Vagrant Cascadian wrote:
>> Video output on the pinebook LCD screen was broken by:
>>
>> commit 2cc393f32fd9 ("video: make BPP and ANSI configs optional").
>>
>> Enable VIDEO_BPP32 which was previously enabled by default when
>> DM_VIDEO was set.
>>
>> Signed-off-by: Vagrant Cascadian
>
> There's nothing really specific about the pinebook here, but it's
> needed for pretty much all the boards using DM_VIDEO (on Allwinner at
> least).
>
> You should add a kconfig select / default instead
That would basically revert 2cc393f32fd9, and I figured there was a
reason for it...
It wouldn't surprise me that other systems are affected, but I only
notice this issue on the pinebook (most of the systems I use are
headless), where it definitely needed to be fixed somehow.
If there's a correct and more general fix, please propose it!
live well,
vagrant
[PATCH] config_whitelist: Remove CONFIG_MX6UL_14X14_EVK_EMMC_REWORK
Since commit bcc70bc863af ("mx6ul_14x14_evk: Fix SPL boot hang") the symbol
CONFIG_MX6UL_14X14_EVK_EMMC_REWORK is no longer used, so remove it from
the white list too.
Signed-off-by: Fabio Estevam
---
scripts/config_whitelist.txt | 1 -
1 file changed, 1 deletion(-)
diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
index cd154738a4..9e1b651446 100644
--- a/scripts/config_whitelist.txt
+++ b/scripts/config_whitelist.txt
@@ -1167,7 +1167,6 @@ CONFIG_MX35_HCLK_FREQ
CONFIG_MX6DL_LPDDR2
CONFIG_MX6DQ_LPDDR2
CONFIG_MX6SX_SABRESD_REVA
-CONFIG_MX6UL_14X14_EVK_EMMC_REWORK
CONFIG_MXC_EPDC
CONFIG_MXC_GPT_HCLK
CONFIG_MXC_MCI_REGS_BASE
--
2.17.1
Re: [PATCH] arm: dts: i.mx8x: add #cooling-cells properties
On Sat, Jan 18, 2020 at 12:12 PM Anatolij Gustschin wrote: > > Fix dtb building warnings: > Warning (cooling_device_property): > /thermal-zones/cpu-thermal0/cooling-maps/map0: > Missing property '#cooling-cells' in node /cpus/cpu@0 or bad phandle > (referred from cooling-device[0]) > > Signed-off-by: Anatolij Gustschin > --- > arch/arm/dts/fsl-imx8-ca35.dtsi | 4 > 1 file changed, 4 insertions(+) > > diff --git a/arch/arm/dts/fsl-imx8-ca35.dtsi b/arch/arm/dts/fsl-imx8-ca35.dtsi > index 28bc32c8b7..9af8b1511c 100644 > --- a/arch/arm/dts/fsl-imx8-ca35.dtsi > +++ b/arch/arm/dts/fsl-imx8-ca35.dtsi > @@ -18,6 +18,7 @@ > reg = <0x0 0x0>; > enable-method = "psci"; > next-level-cache = <_L2>; > + #cooling-cells = <2>; Yes, this matches arch/arm64/boot/dts/freescale/imx8qxp.dtsi upstream. Maybe we should sync with upstream at some point. Reviewed-by: Fabio Estevam
Re: Please pull u-boot-video
On Sat, Jan 18, 2020 at 05:19:46PM +0100, Anatolij Gustschin wrote: > Hi Tom, > > please pull a few fixes for v2020.04-rc1. > > gitlab CI: > https://gitlab.denx.de/u-boot/custodians/u-boot-video/pipelines/1914 > Travis-CI: https://travis-ci.org/vdsao/u-boot-video/builds/638817892 > > Thanks, > Anatolij > > The following changes since commit 2d2f91a480f6849a8548414003d36fa030d434f1: > > Merge branch '2020-01-17-improve-aes-support' (2020-01-17 13:23:32 -0500) > > are available in the Git repository at: > > https://gitlab.denx.de/u-boot/custodians/u-boot-video.git > tags/video-for-v2020.04 > > for you to fetch changes up to af850e5180e89804ad22cbbb6565dd55b3d0b52a: > > arm: Enable VIDEO_BPP32 on pinebook. (2020-01-18 14:15:00 +0100) > > > - fix Coverity CID 280902 issue in vid_console_color() > - fix vid_console_color() build warning > - fix video output on pinebook LCD > > > Anatolij Gustschin (1): > video: fix Coverity missing break issue > > Vagrant Cascadian (1): > arm: Enable VIDEO_BPP32 on pinebook. > > configs/pinebook_defconfig| 1 + > drivers/video/vidconsole-uclass.c | 20 > 2 files changed, 13 insertions(+), 8 deletions(-) But per Maxime's feedback, it's going to be all sunxi platforms that need the change and I expect we should step back and see who else also needs it enabled, or perhaps to switch things around, what are the cases for having it disabled and should it be default enabled? Thanks! -- Tom signature.asc Description: PGP signature
Please pull u-boot-video
Hi Tom, please pull a few fixes for v2020.04-rc1. gitlab CI: https://gitlab.denx.de/u-boot/custodians/u-boot-video/pipelines/1914 Travis-CI: https://travis-ci.org/vdsao/u-boot-video/builds/638817892 Thanks, Anatolij The following changes since commit 2d2f91a480f6849a8548414003d36fa030d434f1: Merge branch '2020-01-17-improve-aes-support' (2020-01-17 13:23:32 -0500) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-video.git tags/video-for-v2020.04 for you to fetch changes up to af850e5180e89804ad22cbbb6565dd55b3d0b52a: arm: Enable VIDEO_BPP32 on pinebook. (2020-01-18 14:15:00 +0100) - fix Coverity CID 280902 issue in vid_console_color() - fix vid_console_color() build warning - fix video output on pinebook LCD Anatolij Gustschin (1): video: fix Coverity missing break issue Vagrant Cascadian (1): arm: Enable VIDEO_BPP32 on pinebook. configs/pinebook_defconfig| 1 + drivers/video/vidconsole-uclass.c | 20 2 files changed, 13 insertions(+), 8 deletions(-)
Re: [PATCH] arm: dts: i.mx8x: add #cooling-cells properties
On 18/01/20 16:12, Anatolij Gustschin wrote:
> Fix dtb building warnings:
> Warning (cooling_device_property):
> /thermal-zones/cpu-thermal0/cooling-maps/map0:
> Missing property '#cooling-cells' in node /cpus/cpu@0 or bad phandle
> (referred from cooling-device[0])
>
Thanks for fixing this.
> Signed-off-by: Anatolij Gustschin
> ---
> arch/arm/dts/fsl-imx8-ca35.dtsi | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/dts/fsl-imx8-ca35.dtsi b/arch/arm/dts/fsl-imx8-ca35.dtsi
> index 28bc32c8b7..9af8b1511c 100644
> --- a/arch/arm/dts/fsl-imx8-ca35.dtsi
> +++ b/arch/arm/dts/fsl-imx8-ca35.dtsi
> @@ -18,6 +18,7 @@
> reg = <0x0 0x0>;
> enable-method = "psci";
> next-level-cache = <_L2>;
> + #cooling-cells = <2>;
> };
>
> A35_1: cpu@1 {
> @@ -26,6 +27,7 @@
> reg = <0x0 0x1>;
> enable-method = "psci";
> next-level-cache = <_L2>;
> + #cooling-cells = <2>;
> };
>
> A35_2: cpu@2 {
> @@ -34,6 +36,7 @@
> reg = <0x0 0x2>;
> enable-method = "psci";
> next-level-cache = <_L2>;
> + #cooling-cells = <2>;
> };
>
> A35_3: cpu@3 {
> @@ -42,6 +45,7 @@
> reg = <0x0 0x3>;
> enable-method = "psci";
> next-level-cache = <_L2>;
> + #cooling-cells = <2>;
> };
>
> A35_L2: l2-cache0 {
>
Reviewed-by: Stefano Babic
Best regards,
Stefano Babic
--
=
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
[PATCH] arm: dts: i.mx8x: add #cooling-cells properties
Fix dtb building warnings:
Warning (cooling_device_property):
/thermal-zones/cpu-thermal0/cooling-maps/map0:
Missing property '#cooling-cells' in node /cpus/cpu@0 or bad phandle (referred
from cooling-device[0])
Signed-off-by: Anatolij Gustschin
---
arch/arm/dts/fsl-imx8-ca35.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/dts/fsl-imx8-ca35.dtsi b/arch/arm/dts/fsl-imx8-ca35.dtsi
index 28bc32c8b7..9af8b1511c 100644
--- a/arch/arm/dts/fsl-imx8-ca35.dtsi
+++ b/arch/arm/dts/fsl-imx8-ca35.dtsi
@@ -18,6 +18,7 @@
reg = <0x0 0x0>;
enable-method = "psci";
next-level-cache = <_L2>;
+ #cooling-cells = <2>;
};
A35_1: cpu@1 {
@@ -26,6 +27,7 @@
reg = <0x0 0x1>;
enable-method = "psci";
next-level-cache = <_L2>;
+ #cooling-cells = <2>;
};
A35_2: cpu@2 {
@@ -34,6 +36,7 @@
reg = <0x0 0x2>;
enable-method = "psci";
next-level-cache = <_L2>;
+ #cooling-cells = <2>;
};
A35_3: cpu@3 {
@@ -42,6 +45,7 @@
reg = <0x0 0x3>;
enable-method = "psci";
next-level-cache = <_L2>;
+ #cooling-cells = <2>;
};
A35_L2: l2-cache0 {
--
2.17.1
Re: [PATCH] arm: Enable VIDEO_BPP32 on pinebook.
On Sat, 18 Jan 2020 03:15:15 -0800 Vagrant Cascadian vagr...@debian.org wrote: ... > configs/pinebook_defconfig | 1 + > 1 file changed, 1 insertion(+) Applied to u-boot-video/master, thanks! -- Anatolij
Re: [PATCH] video: fix Coverity missing break issue
On Mon, 6 Jan 2020 23:00:38 +0100 Anatolij Gustschin ag...@denx.de wrote: > Fix: > >>> CID 280902: Control flow issues (MISSING_BREAK) > >>> The case for value "VIDEO_BPP32" is not terminated > >>> by a 'break' statement. > > Reported-by: Tom Rini > Signed-off-by: Anatolij Gustschin > --- > drivers/video/vidconsole-uclass.c | 2 ++ > 1 file changed, 2 insertions(+) Applied to u-boot-video/master, thanks! -- Anatolij
[PATCH] arm: Enable VIDEO_BPP32 on pinebook.
Video output on the pinebook LCD screen was broken by:
commit 2cc393f32fd9 ("video: make BPP and ANSI configs optional").
Enable VIDEO_BPP32 which was previously enabled by default when
DM_VIDEO was set.
Signed-off-by: Vagrant Cascadian
---
configs/pinebook_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/configs/pinebook_defconfig b/configs/pinebook_defconfig
index 929434e25a..306a6bc6b9 100644
--- a/configs/pinebook_defconfig
+++ b/configs/pinebook_defconfig
@@ -22,3 +22,4 @@ CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE=y
# CONFIG_USB_GADGET is not set
CONFIG_VIDEO_BRIDGE=y
CONFIG_VIDEO_BRIDGE_ANALOGIX_ANX6345=y
+CONFIG_VIDEO_BPP32=y
--
2.20.1
