[PATCH] fs: relax ext4_write_file() dependency
ext4_write_file() depends on CONFIG_EXT4_WRITE. Allow build without
CONFIG_CMD_EXT4_WRITE.
Signed-off-by: Baruch Siach
---
fs/fs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/fs.c b/fs/fs.c
index bed1f7242f41..0c47943f3339 100644
--- a/fs/fs.c
+++ b/fs/fs.c
@@ -224,7 +224,7 @@ static struct fstype_info fstypes[] = {
.exists = ext4fs_exists,
.size = ext4fs_size,
.read = ext4_read_file,
-#ifdef CONFIG_CMD_EXT4_WRITE
+#ifdef CONFIG_EXT4_WRITE
.write = ext4_write_file,
.ln = ext4fs_create_link,
#else
--
2.43.0
[PATCH] net: fix NetConsole documentation reference
Fixes: d0253f7e5ca1 ("doc: move README.NetConsole to HTML documentation")
Signed-off-by: Baruch Siach
---
net/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/Kconfig b/net/Kconfig
index 4215889127c9..92a22ac1ea55 100644
--- a/net/Kconfig
+++ b/net/Kconfig
@@ -57,7 +57,7 @@ config NETCONSOLE
bool "NetConsole support"
help
Support the 'nc' input/output device for networked console.
- See README.NetConsole for details.
+ See doc/usage/netconsole.rst for details.
config IP_DEFRAG
bool "Support IP datagram reassembly"
--
2.43.0
[PATCH] net: designware: add DMA offset awareness
Older DesignWare Ethernet MAC versions that this driver supports can
only work with 32-bit DMA source/destination addresses. Some platforms
have no physical RAM at the lowest 4GB address space. For these
platforms the driver must translate DMA addresses to/from physical
memory addresses.
Call translation routines so that properly configured platforms can use
the DesignWare Ethernet MAC. For platforms using device-tree this
usually means adding dma-ranges property to the bus the device node is
in.
Signed-off-by: Baruch Siach
---
drivers/net/designware.c | 31 ---
drivers/net/designware.h | 1 +
2 files changed, 21 insertions(+), 11 deletions(-)
diff --git a/drivers/net/designware.c b/drivers/net/designware.c
index 20b86e74cecf..a174344b3ef5 100644
--- a/drivers/net/designware.c
+++ b/drivers/net/designware.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -232,8 +233,10 @@ static void tx_descs_init(struct dw_eth_dev *priv)
for (idx = 0; idx < CFG_TX_DESCR_NUM; idx++) {
desc_p = _table_p[idx];
- desc_p->dmamac_addr = (ulong)[idx * CFG_ETH_BUFSIZE];
- desc_p->dmamac_next = (ulong)_table_p[idx + 1];
+ desc_p->dmamac_addr = dev_phys_to_bus(priv->dev,
+ (ulong)[idx * CFG_ETH_BUFSIZE]);
+ desc_p->dmamac_next = dev_phys_to_bus(priv->dev,
+ (ulong)_table_p[idx + 1]);
#if defined(CONFIG_DW_ALTDESCRIPTOR)
desc_p->txrx_status &= ~(DESC_TXSTS_TXINT | DESC_TXSTS_TXLAST |
@@ -251,14 +254,15 @@ static void tx_descs_init(struct dw_eth_dev *priv)
}
/* Correcting the last pointer of the chain */
- desc_p->dmamac_next = (ulong)_table_p[0];
+ desc_p->dmamac_next = dev_phys_to_bus(priv->dev,
(ulong)_table_p[0]);
/* Flush all Tx buffer descriptors at once */
flush_dcache_range((ulong)priv->tx_mac_descrtable,
(ulong)priv->tx_mac_descrtable +
sizeof(priv->tx_mac_descrtable));
- writel((ulong)_table_p[0], _p->txdesclistaddr);
+ writel(dev_phys_to_bus(priv->dev, (ulong)_table_p[0]),
+ _p->txdesclistaddr);
priv->tx_currdescnum = 0;
}
@@ -280,8 +284,10 @@ static void rx_descs_init(struct dw_eth_dev *priv)
for (idx = 0; idx < CFG_RX_DESCR_NUM; idx++) {
desc_p = _table_p[idx];
- desc_p->dmamac_addr = (ulong)[idx * CFG_ETH_BUFSIZE];
- desc_p->dmamac_next = (ulong)_table_p[idx + 1];
+ desc_p->dmamac_addr = dev_phys_to_bus(priv->dev,
+ (ulong)[idx * CFG_ETH_BUFSIZE]);
+ desc_p->dmamac_next = dev_phys_to_bus(priv->dev,
+ (ulong)_table_p[idx + 1]);
desc_p->dmamac_cntl =
(MAC_MAX_FRAME_SZ & DESC_RXCTRL_SIZE1MASK) |
@@ -291,14 +297,15 @@ static void rx_descs_init(struct dw_eth_dev *priv)
}
/* Correcting the last pointer of the chain */
- desc_p->dmamac_next = (ulong)_table_p[0];
+ desc_p->dmamac_next = dev_phys_to_bus(priv->dev,
(ulong)_table_p[0]);
/* Flush all Rx buffer descriptors at once */
flush_dcache_range((ulong)priv->rx_mac_descrtable,
(ulong)priv->rx_mac_descrtable +
sizeof(priv->rx_mac_descrtable));
- writel((ulong)_table_p[0], _p->rxdesclistaddr);
+ writel(dev_phys_to_bus(priv->dev, (ulong)_table_p[0]),
+ _p->rxdesclistaddr);
priv->rx_currdescnum = 0;
}
@@ -448,7 +455,7 @@ static int _dw_eth_send(struct dw_eth_dev *priv, void
*packet, int length)
ulong desc_start = (ulong)desc_p;
ulong desc_end = desc_start +
roundup(sizeof(*desc_p), ARCH_DMA_MINALIGN);
- ulong data_start = desc_p->dmamac_addr;
+ ulong data_start = dev_bus_to_phys(priv->dev, desc_p->dmamac_addr);
ulong data_end = data_start + roundup(length, ARCH_DMA_MINALIGN);
/*
* Strictly we only need to invalidate the "txrx_status" field
@@ -515,7 +522,7 @@ static int _dw_eth_recv(struct dw_eth_dev *priv, uchar
**packetp)
ulong desc_start = (ulong)desc_p;
ulong desc_end = desc_start +
roundup(sizeof(*desc_p), ARCH_DMA_MINALIGN);
- ulong data_start = desc_p->dmamac_addr;
+ ulong data_start = dev_bus_to_phys(priv->dev, desc_p->dmamac_addr);
ulong data_end;
/* Invalidate entire buffer descriptor */
@@ -532,7 +539,8 @@ static int _dw_eth_recv(struct dw_eth_dev *priv, uchar
**packetp)
/* Invalidate received data */
data_end = data_start + roundup(length, A
[PATCH] cmd: fs: document where 'size' stores its result
Make it a little bit easier for the user to utilize the 'size' command. Signed-off-by: Baruch Siach --- cmd/fs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cmd/fs.c b/cmd/fs.c index 5ad11647c2d3..6044f73af5b4 100644 --- a/cmd/fs.c +++ b/cmd/fs.c @@ -20,7 +20,7 @@ U_BOOT_CMD( "determine a file's size", " \n" "- Find file 'filename' from 'dev' on 'interface'\n" - " and determine its size." + " determine its size, and store in the 'filesize' variable." ); static int do_load_wrapper(struct cmd_tbl *cmdtp, int flag, int argc, -- 2.39.2
Re: [PATCH 1/4] doc: signature: update algorithms support description
Hi Simon,
On Tue, May 02 2023, Simon Glass wrote:
> On Mon, 1 May 2023 at 22:47, Baruch Siach wrote:
>>
>> U-Boot supports more hash and verification algorithms these days.
>>
>> Signed-off-by: Baruch Siach
>> ---
>> doc/uImage.FIT/signature.txt | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> Reviewed-by: Simon Glass
Thanks.
> Would you be interested in moving this documentation to doc/develop in
> the rST format?
I hope to find some time to help with that.
baruch
--
~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
[PATCH] doc: devicetree: fix u-boot.bin filename typo
Signed-off-by: Baruch Siach --- doc/develop/devicetree/control.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/develop/devicetree/control.rst b/doc/develop/devicetree/control.rst index 0b3b32be1bb6..cbb65c9b177f 100644 --- a/doc/develop/devicetree/control.rst +++ b/doc/develop/devicetree/control.rst @@ -100,7 +100,7 @@ and development only and is not recommended for production devices. If CONFIG_OF_SEPARATE is defined, then it will be built and placed in a u-boot.dtb file alongside u-boot-nodtb.bin with the combined result placed -in u-boot.bin so you can still just flash u-boot,bin onto your board. If you are +in u-boot.bin so you can still just flash u-boot.bin onto your board. If you are using CONFIG_SPL_FRAMEWORK, then u-boot.img will be built to include the device tree binary. -- 2.39.2
[PATCH 4/4] doc: signature: trim the future work list
Since U-Boot supports more RSA/SHA variants, as well as ECDSA, remove these items from the TODO list. Signed-off-by: Baruch Siach --- doc/uImage.FIT/signature.txt | 2 -- 1 file changed, 2 deletions(-) diff --git a/doc/uImage.FIT/signature.txt b/doc/uImage.FIT/signature.txt index 240244b30e63..21eb3894aada 100644 --- a/doc/uImage.FIT/signature.txt +++ b/doc/uImage.FIT/signature.txt @@ -695,8 +695,6 @@ bootm. Possible Future Work -- Add support for other RSA/SHA variants, such as rsa4096,sha512. -- Other algorithms besides RSA - More sandbox tests for failure modes - Passwords for keys/certificates - Perhaps implement OAEP -- 2.39.2
[PATCH 1/4] doc: signature: update algorithms support description
U-Boot supports more hash and verification algorithms these days. Signed-off-by: Baruch Siach --- doc/uImage.FIT/signature.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/uImage.FIT/signature.txt b/doc/uImage.FIT/signature.txt index c71280b63bb6..bc123f512f7b 100644 --- a/doc/uImage.FIT/signature.txt +++ b/doc/uImage.FIT/signature.txt @@ -42,8 +42,8 @@ device. Algorithms -- In principle any suitable algorithm can be used to sign and verify a hash. -At present only one class of algorithms is supported: SHA1 hashing with RSA. -This works by hashing the image to produce a 20-byte hash. +U-Boot supports a few hashing and verification algorithms. See below for +details. While it is acceptable to bring in large cryptographic libraries such as openssl on the host side (e.g. mkimage), it is not desirable for U-Boot. -- 2.39.2
[PATCH 3/4] doc: signature: describe how to enable ECDSA
Signed-off-by: Baruch Siach --- doc/uImage.FIT/signature.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/doc/uImage.FIT/signature.txt b/doc/uImage.FIT/signature.txt index b6707417ff63..240244b30e63 100644 --- a/doc/uImage.FIT/signature.txt +++ b/doc/uImage.FIT/signature.txt @@ -439,6 +439,7 @@ be enabled: CONFIG_FIT_SIGNATURE - enable signing and verification in FITs CONFIG_RSA - enable RSA algorithm for signing +CONFIG_ECDSA - enable ECDSA algorithm for signing WARNING: When relying on signed FIT images with required signature check the legacy image format is default disabled by not defining -- 2.39.2
[PATCH 2/4] doc: signature: update algorithm addition description
U-Boot now uses the U_BOOT_CRYPTO_ALGO() macro. Signed-off-by: Baruch Siach --- doc/uImage.FIT/signature.txt | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/doc/uImage.FIT/signature.txt b/doc/uImage.FIT/signature.txt index bc123f512f7b..b6707417ff63 100644 --- a/doc/uImage.FIT/signature.txt +++ b/doc/uImage.FIT/signature.txt @@ -56,10 +56,10 @@ of data from the FDT and exponentiation mod n. Code size impact is a little under 5KB on Tegra Seaboard, for example. It is relatively straightforward to add new algorithms if required. If -another RSA variant is needed, then it can be added to the table in -image-sig.c. If another algorithm is needed (such as DSA) then it can be -placed alongside rsa.c, and its functions added to the table in image-sig.c -also. +another RSA variant is needed, then it can be added with the +U_BOOT_CRYPTO_ALGO() macro. If another algorithm is needed (such as DSA) then +it can be placed in a directory alongside lib/rsa/, and its functions added +using U_BOOT_CRYPTO_ALGO(). Creating an RSA key pair and certificate -- 2.39.2
[PATCH] cmd/fdt: fix conf node lookup failure check
fit_conf_get_node() returns negative value on error.
Signed-off-by: Baruch Siach
---
cmd/fdt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/cmd/fdt.c b/cmd/fdt.c
index aae3278526c4..2401ea8b44cb 100644
--- a/cmd/fdt.c
+++ b/cmd/fdt.c
@@ -733,7 +733,7 @@ static int do_fdt(struct cmd_tbl *cmdtp, int flag, int
argc, char *const argv[])
gd->fdt_blob = blob;
cfg_noffset = fit_conf_get_node(working_fdt, NULL);
- if (!cfg_noffset) {
+ if (cfg_noffset < 0) {
printf("Could not find configuration node: %s\n",
fdt_strerror(cfg_noffset));
return CMD_RET_FAILURE;
--
2.39.2
Re: [PATCH v5 36/44] imx: Use SATA instead of CMD_SATA
Hi Simon,
On Wed, Feb 22 2023, Simon Glass wrote:
> This causes a build failure on mx6cuboxi with split config, since CMD_SATA
> shows up as enabled in SPl (because there is no SPL_CMD_SATA).
>
> The condition is wrong anyway, so change it to use SATA instead.
>
> Signed-off-by: Simon Glass
This conflicts with
https://patchwork.ozlabs.org/project/uboot/patch/20230222013821.1144691-19-troykiskybound...@gmail.com/
baruch
> ---
>
> (no changes since v1)
>
> board/solidrun/mx6cuboxi/mx6cuboxi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/board/solidrun/mx6cuboxi/mx6cuboxi.c
> b/board/solidrun/mx6cuboxi/mx6cuboxi.c
> index 7c44379ec4a..cb14c2f30c9 100644
> --- a/board/solidrun/mx6cuboxi/mx6cuboxi.c
> +++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c
> @@ -275,7 +275,7 @@ int board_early_init_f(void)
> {
> setup_iomux_uart();
>
> -#ifdef CONFIG_CMD_SATA
> +#ifdef CONFIG_SATA
> setup_sata();
> #endif
> setup_fec();
--
~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
Re: [PATCH] cmd: return code when tlv_eeprom incorrectly called
Hi Heinrich,
On Fri, Jan 27 2023, Heinrich Schuchardt wrote:
> A command called with incorrect parameters should set $? to 1 (false).
> Instead of calling cmd_usage(cmdtp) and then returning 0 just return
> CMD_RET_FAILURE.
>
> Signed-off-by: Heinrich Schuchardt
Acked-by: Baruch Siach
Thanks,
baruch
> ---
> cmd/tlv_eeprom.c | 11 ---
> 1 file changed, 4 insertions(+), 7 deletions(-)
>
> diff --git a/cmd/tlv_eeprom.c b/cmd/tlv_eeprom.c
> index bf8d453dc5..4591ff336b 100644
> --- a/cmd/tlv_eeprom.c
> +++ b/cmd/tlv_eeprom.c
> @@ -479,17 +479,14 @@ int do_tlv_eeprom(struct cmd_tbl *cmdtp, int flag, int
> argc, char *const argv[])
> show_tlv_devices();
> break;
> default:
> - cmd_usage(cmdtp);
> - break;
> + return CMD_RET_USAGE;
> }
> return 0;
> }
>
> // The set command takes one or two args.
> - if (argc > 4) {
> - cmd_usage(cmdtp);
> - return 0;
> - }
> + if (argc > 4)
> + return CMD_RET_USAGE;
>
> // Set command. If the TLV exists in the EEPROM, delete it. Then if
> // data was supplied for this TLV add the TLV with the new contents at
> @@ -512,7 +509,7 @@ int do_tlv_eeprom(struct cmd_tbl *cmdtp, int flag, int
> argc, char *const argv[])
> current_dev = devnum;
> has_been_read = 0;
> } else {
> - cmd_usage(cmdtp);
> + return CMD_RET_USAGE;
> }
>
> return 0;
--
~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
[PATCH] mx6cuboxi: migrate to DM_SERIAL
Add the needed DT overrides to enable UART in SPL.
Cc: Fabio Estevam
Signed-off-by: Baruch Siach
---
...mx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi | 16
board/solidrun/mx6cuboxi/mx6cuboxi.c | 3 +++
configs/mx6cuboxi_defconfig | 2 +-
3 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi
b/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi
index 400b885e4370..e1cb9b3e89ec 100644
--- a/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi
+++ b/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi
@@ -15,6 +15,22 @@
};
};
+ {
+ u-boot,dm-pre-reloc;
+};
+
+ {
+ u-boot,dm-pre-reloc;
+};
+
+_microsom_uart1 {
+ u-boot,dm-pre-reloc;
+};
+
+ {
+ u-boot,dm-pre-reloc;
+};
+
{
u-boot,dm-pre-reloc;
};
diff --git a/board/solidrun/mx6cuboxi/mx6cuboxi.c
b/board/solidrun/mx6cuboxi/mx6cuboxi.c
index debf4f6a3b06..8e80ca6e17e0 100644
--- a/board/solidrun/mx6cuboxi/mx6cuboxi.c
+++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c
@@ -844,6 +844,9 @@ void board_init_f(ulong dummy)
/* setup GP timer */
timer_init();
+ /* Enable device tree and early DM support*/
+ spl_early_init();
+
/* UART clocks enabled and gd valid - init serial console */
preloader_console_init();
diff --git a/configs/mx6cuboxi_defconfig b/configs/mx6cuboxi_defconfig
index 9de5e77c75ad..4fa51a483bfb 100644
--- a/configs/mx6cuboxi_defconfig
+++ b/configs/mx6cuboxi_defconfig
@@ -46,7 +46,6 @@ CONFIG_OF_CONTROL=y
CONFIG_SPL_OF_CONTROL=y
CONFIG_OF_LIST="imx6dl-hummingboard2-emmc-som-v15
imx6q-hummingboard2-emmc-som-v15"
CONFIG_MULTI_DTB_FIT=y
-CONFIG_SPL_OF_PLATDATA=y
CONFIG_ENV_OVERWRITE=y
CONFIG_ENV_IS_IN_MMC=y
CONFIG_SYS_RELOC_GD_ENV_ADDR=y
@@ -68,6 +67,7 @@ CONFIG_PINCTRL=y
CONFIG_PINCTRL_IMX6=y
CONFIG_DM_REGULATOR=y
CONFIG_DM_REGULATOR_FIXED=y
+CONFIG_DM_SERIAL=y
CONFIG_MXC_UART=y
CONFIG_DM_THERMAL=y
CONFIG_IMX_THERMAL=y
--
2.35.1
Re: DM_SERIAL for i.MX6 Hummingboard/Cubox-i
Hi Fabio,
On Thu, Nov 03 2022, Fabio Estevam wrote:
> On Thu, Nov 3, 2022 at 11:28 AM Fabio Estevam wrote:
>> On Thu, Nov 3, 2022 at 11:15 AM Fabio Estevam wrote:
>>
>> > Please try using u-boot,dm-spl for all nodes instead.
>>
>> In addition to using u-boot,dm-spl, please try calling
>> spl_early_init() like done here:
>> https://source.denx.de/u-boot/u-boot/-/commit/7cf388fa6977136dd2384bd746d237efc306c829
>
> Interestingly, on a wandboard I did:
>
> diff --git a/configs/wandboard_defconfig b/configs/wandboard_defconfig
> index 70b4cf9ffaa3..33d9db56e1cb 100644
> --- a/configs/wandboard_defconfig
> +++ b/configs/wandboard_defconfig
> @@ -72,6 +72,7 @@ CONFIG_PINCTRL_IMX6=y
> CONFIG_DM_PMIC=y
> CONFIG_DM_PMIC_PFUZE100=y
> CONFIG_DM_SCSI=y
> +CONFIG_DM_SERIAL=y
> CONFIG_MXC_UART=y
> CONFIG_DM_THERMAL=y
> CONFIG_USB=y
>
> and it boots fine.
Without any u-boot,dm-pre-reloc or u-boot,dm-spl? I don't see any for
wandboard DT files in current master.
baruch
--
~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
Re: DM_SERIAL for i.MX6 Hummingboard/Cubox-i
Hi Fabio,
On Thu, Nov 03 2022, Fabio Estevam wrote:
> On Thu, Nov 3, 2022 at 11:15 AM Fabio Estevam wrote:
>
>> Please try using u-boot,dm-spl for all nodes instead.
>
> In addition to using u-boot,dm-spl, please try calling
> spl_early_init() like done here:
> https://source.denx.de/u-boot/u-boot/-/commit/7cf388fa6977136dd2384bd746d237efc306c829
That did the trick. Thanks.
A patch is forthcoming.
baruch
--
~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
Re: DM_SERIAL for i.MX6 Hummingboard/Cubox-i
Hi Fabio,
On Thu, Nov 03 2022, Fabio Estevam wrote:
> On Thu, Nov 3, 2022 at 9:29 AM Baruch Siach wrote:
>> I am trying to migrate the Hummingboard platform to DM_SERIAL. See below
>> what I got so far. Booting this on top of master (as of commit
>> 8bc87a4c5) shows nothing on the serial console. Next thing I plan to try
>> is toggle GPIOs in entry code to see how far the code proceeds.
>>
>> Any idea where to look before I go down that way?
>>
>> Thanks,
>> baruch
>>
>> diff --git a/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi
>> b/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi
>> index 400b885e4370..8507b818d4cf 100644
>> --- a/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi
>> +++ b/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi
>> @@ -15,6 +15,10 @@
>> };
>> };
>>
>> + {
>> + u-boot,dm-pre-reloc;
>> +};
>
> Here you also need to pass , _uart1, and
I tried this (see below) but no luck yet. The tbs2910 appears not to use
SPL. I might be missing an SPL driver.
Thanks for your help,
baruch
diff --git a/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi
b/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi
index 400b885e4370..e1cb9b3e89ec 100644
--- a/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi
+++ b/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi
@@ -15,6 +15,22 @@
};
};
+ {
+ u-boot,dm-pre-reloc;
+};
+
+ {
+ u-boot,dm-pre-reloc;
+};
+
+_microsom_uart1 {
+ u-boot,dm-pre-reloc;
+};
+
+ {
+ u-boot,dm-pre-reloc;
+};
+
{
u-boot,dm-pre-reloc;
};
diff --git a/configs/mx6cuboxi_defconfig b/configs/mx6cuboxi_defconfig
index 9de5e77c75ad..9d7b2764c969 100644
--- a/configs/mx6cuboxi_defconfig
+++ b/configs/mx6cuboxi_defconfig
@@ -46,7 +46,6 @@ CONFIG_OF_CONTROL=y
CONFIG_SPL_OF_CONTROL=y
CONFIG_OF_LIST="imx6dl-hummingboard2-emmc-som-v15
imx6q-hummingboard2-emmc-som-v15"
CONFIG_MULTI_DTB_FIT=y
-CONFIG_SPL_OF_PLATDATA=y
CONFIG_ENV_OVERWRITE=y
CONFIG_ENV_IS_IN_MMC=y
CONFIG_SYS_RELOC_GD_ENV_ADDR=y
@@ -65,9 +64,11 @@ CONFIG_FEC_MXC=y
CONFIG_RGMII=y
CONFIG_MII=y
CONFIG_PINCTRL=y
+CONFIG_SPL_PINCTRL=y
CONFIG_PINCTRL_IMX6=y
CONFIG_DM_REGULATOR=y
CONFIG_DM_REGULATOR_FIXED=y
+CONFIG_DM_SERIAL=y
CONFIG_MXC_UART=y
CONFIG_DM_THERMAL=y
CONFIG_IMX_THERMAL=y
> Please look at the following commit for reference:
>
> commit 8fbca1a8b9b02fbc40147401d9af764e07dc96af
> Author: Fabio Estevam
> Date: Tue Mar 15 17:47:05 2022 -0300
>
> tbs2910: Convert to DM_SERIAL
>
> Conversion to DM_SERIAL is mandatory.
>
> Select DM_SERIAL and add a imx6q-tbs2910-u-boot.dtsi file
> that describes the nodes that require dm-pre-reloc, which allows
> the DM model to configure the UART pinctrl early.
>
> Remove the now unneeded board UART initialization.
>
> Signed-off-by: Fabio Estevam
> Tested-by: Soeren Moch
--
~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
DM_SERIAL for i.MX6 Hummingboard/Cubox-i
Hi u-boot list,
I am trying to migrate the Hummingboard platform to DM_SERIAL. See below
what I got so far. Booting this on top of master (as of commit
8bc87a4c5) shows nothing on the serial console. Next thing I plan to try
is toggle GPIOs in entry code to see how far the code proceeds.
Any idea where to look before I go down that way?
Thanks,
baruch
diff --git a/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi
b/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi
index 400b885e4370..8507b818d4cf 100644
--- a/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi
+++ b/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi
@@ -15,6 +15,10 @@
};
};
+ {
+ u-boot,dm-pre-reloc;
+};
+
{
u-boot,dm-pre-reloc;
};
diff --git a/configs/mx6cuboxi_defconfig b/configs/mx6cuboxi_defconfig
index 9de5e77c75ad..a29e973eccce 100644
--- a/configs/mx6cuboxi_defconfig
+++ b/configs/mx6cuboxi_defconfig
@@ -46,7 +46,6 @@ CONFIG_OF_CONTROL=y
CONFIG_SPL_OF_CONTROL=y
CONFIG_OF_LIST="imx6dl-hummingboard2-emmc-som-v15
imx6q-hummingboard2-emmc-som-v15"
CONFIG_MULTI_DTB_FIT=y
-CONFIG_SPL_OF_PLATDATA=y
CONFIG_ENV_OVERWRITE=y
CONFIG_ENV_IS_IN_MMC=y
CONFIG_SYS_RELOC_GD_ENV_ADDR=y
@@ -68,6 +67,8 @@ CONFIG_PINCTRL=y
CONFIG_PINCTRL_IMX6=y
CONFIG_DM_REGULATOR=y
CONFIG_DM_REGULATOR_FIXED=y
+CONFIG_SPECIFY_CONSOLE_INDEX=y
+CONFIG_DM_SERIAL=y
CONFIG_MXC_UART=y
CONFIG_DM_THERMAL=y
CONFIG_IMX_THERMAL=y
--
~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
[PATCH] cmd: eeprom: don't truncate target address at 32-bit
On 64-bit platforms where int is 32-bit wide, the eeprom command
parse_numeric_param() routine truncates the memory address parameter to
the lower 32-bit. Make parse_numeric_param() return long to allow
read/write of addresses beyond the lower 4GB.
Signed-off-by: Baruch Siach
---
cmd/eeprom.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/cmd/eeprom.c b/cmd/eeprom.c
index cdd65af763b0..614263fd8edb 100644
--- a/cmd/eeprom.c
+++ b/cmd/eeprom.c
@@ -200,10 +200,10 @@ int eeprom_write(unsigned dev_addr, unsigned offset,
return ret;
}
-static int parse_numeric_param(char *str)
+static long parse_numeric_param(char *str)
{
char *endptr;
- int value = simple_strtol(str, , 16);
+ long value = simple_strtol(str, , 16);
return (*endptr != '\0') ? -1 : value;
}
--
2.35.1
Re: [PATCH] tlv_eeprom: Add missing CRC32 dependency
Hi Pali,
On Mon, May 30 2022, Pali Rohár wrote:
> tlv_eeprom uses crc32() function, so add dependency into Kconfig.
>
> Signed-off-by: Pali Rohár
Reviewed-by: Baruch Siach
Thanks,
baruch
> ---
> cmd/Kconfig | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/cmd/Kconfig b/cmd/Kconfig
> index 69c1814d24af..d513d808aa3d 100644
> --- a/cmd/Kconfig
> +++ b/cmd/Kconfig
> @@ -167,6 +167,7 @@ config CMD_REGINFO
> config CMD_TLV_EEPROM
> bool "tlv_eeprom"
> depends on I2C_EEPROM
> + select CRC32
> help
> Display and program the system EEPROM data block in ONIE Tlvinfo
> format. TLV stands for Type-Length-Value.
> @@ -175,6 +176,7 @@ config SPL_CMD_TLV_EEPROM
> bool "tlv_eeprom for SPL"
> depends on SPL_I2C_EEPROM
> select SPL_DRIVERS_MISC
> + select SPL_CRC32
> help
> Read system EEPROM data block in ONIE Tlvinfo format from SPL.
--
~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
Re: [PATCH] ARM: mvebu: x530: clearfog: Add ODT configuration
Hi Chris,
On Tue, Mar 01 2022, Chris Packham wrote:
> Commit 369e532691e0 ("ddr: marvell: a38x: allow board specific ODT
> configuration") added the odt_config member to struct
> mv_ddr_topology_map ahead of the clk_enable and ck_delay members. This
> means that any boards that configured either of clk_enable or ck_delay
> needed to have their board topology updated. This affects the x530 and
> clearfog boards. Other A38x boards don't touch any of the trailing
> members of mv_ddr_topology_map so don't need updating.
>
> Fixes: 369e532691e0 ("ddr: marvell: a38x: allow board specific ODT
> configuration")
> Signed-off-by: Chris Packham
Acked-by: Baruch Siach
Thanks,
baruch
> ---
>
> board/alliedtelesis/x530/x530.c| 1 +
> board/solidrun/clearfog/clearfog.c | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/board/alliedtelesis/x530/x530.c b/board/alliedtelesis/x530/x530.c
> index 8b31045a0743..c0ec2afa3011 100644
> --- a/board/alliedtelesis/x530/x530.c
> +++ b/board/alliedtelesis/x530/x530.c
> @@ -73,6 +73,7 @@ static struct mv_ddr_topology_map board_topology_map = {
> {0},/* timing parameters */
> { {0} },/* electrical configuration */
> {0},/* electrical parameters */
> + 0, /* ODT configuration */
> 0, /* Clock enable mask */
> 160 /* Clock delay */
> };
> diff --git a/board/solidrun/clearfog/clearfog.c
> b/board/solidrun/clearfog/clearfog.c
> index c920cf8d6b50..03adb591d826 100644
> --- a/board/solidrun/clearfog/clearfog.c
> +++ b/board/solidrun/clearfog/clearfog.c
> @@ -147,6 +147,7 @@ static struct mv_ddr_topology_map board_topology_map = {
> {0},/* timing parameters */
> { {0} },/* electrical configuration */
> {0,}, /* electrical parameters */
> + 0, /* ODT configuration */
> 0x3,/* clock enable mask */
> };
--
~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
Re: [PATCH 3/3] mmc: mmc_get_op_cond: Allow quiet detection of eMMC
Hi Pali,
On Wed, Jul 14 2021, Pali Rohár wrote:
> Add a new 'quiet' argument to mmc_get_op_cond() function which avoids
> printing error message when SD/eMMC card is not detected.
>
> Espressobin and mx6cuboxi boards use this function for detecting presence
> of eMMC and therefore it is expected and normal that eMMC does not have to
> be connected. So error message "Card did not respond to voltage select!"
> should be skipped in this case as it is not an error.
>
> Signed-off-by: Pali Rohár
> ---
> board/Marvell/mvebu_armada-37xx/board.c | 2 +-
Ordering this patch before #2 would make it smaller.
baruch
> board/solidrun/mx6cuboxi/mx6cuboxi.c| 2 +-
> drivers/mmc/mmc.c | 7 ---
> include/mmc.h | 3 ++-
> 4 files changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/board/Marvell/mvebu_armada-37xx/board.c
> b/board/Marvell/mvebu_armada-37xx/board.c
> index 6086996b8062..fdc873b1952f 100644
> --- a/board/Marvell/mvebu_armada-37xx/board.c
> +++ b/board/Marvell/mvebu_armada-37xx/board.c
> @@ -124,7 +124,7 @@ int board_late_init(void)
>
> /* eMMC is mmc dev num 1 */
> mmc_dev = find_mmc_device(1);
> - emmc = (mmc_dev && mmc_get_op_cond(mmc_dev) == 0);
> + emmc = (mmc_dev && mmc_get_op_cond(mmc_dev, true) == 0);
>
> /* if eMMC is not present then remove it from DM */
> if (!emmc && mmc_dev) {
> diff --git a/board/solidrun/mx6cuboxi/mx6cuboxi.c
> b/board/solidrun/mx6cuboxi/mx6cuboxi.c
> index 3eadc38f6fd4..6207bf8253ab 100644
> --- a/board/solidrun/mx6cuboxi/mx6cuboxi.c
> +++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c
> @@ -374,7 +374,7 @@ static bool has_emmc(void)
> mmc = find_mmc_device(2);
> if (!mmc)
> return 0;
> - return (mmc_get_op_cond(mmc) < 0) ? 0 : 1;
> + return (mmc_get_op_cond(mmc, true) < 0) ? 0 : 1;
> }
>
> int checkboard(void)
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index 1e83007286b2..8078a89f18cb 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -2766,7 +2766,7 @@ static int mmc_power_cycle(struct mmc *mmc)
> return mmc_power_on(mmc);
> }
>
> -int mmc_get_op_cond(struct mmc *mmc)
> +int mmc_get_op_cond(struct mmc *mmc, bool quiet)
> {
> bool uhs_en = supports_uhs(mmc->cfg->host_caps);
> int err;
> @@ -2842,7 +2842,8 @@ retry:
>
> if (err) {
> #if !defined(CONFIG_SPL_BUILD) || defined(CONFIG_SPL_LIBCOMMON_SUPPORT)
> - pr_err("Card did not respond to voltage select! :
> %d\n", err);
> + if (!quiet)
> + pr_err("Card did not respond to voltage select!
> : %d\n", err);
> #endif
> return -EOPNOTSUPP;
> }
> @@ -2882,7 +2883,7 @@ int mmc_start_init(struct mmc *mmc)
> return -ENOMEDIUM;
> }
>
> - err = mmc_get_op_cond(mmc);
> + err = mmc_get_op_cond(mmc, false);
>
> if (!err)
> mmc->init_in_progress = 1;
> diff --git a/include/mmc.h b/include/mmc.h
> index 6f943e78b740..0bf19de20e52 100644
> --- a/include/mmc.h
> +++ b/include/mmc.h
> @@ -900,9 +900,10 @@ int mmc_set_bkops_enable(struct mmc *mmc);
> * the presence of SD/eMMC when no card detect logic is available.
> *
> * @param mmcPointer to a MMC device struct
> + * @param quiet Be quiet, do not print error messages when card is not
> detected.
> * @return 0 on success, <0 on error.
> */
> -int mmc_get_op_cond(struct mmc *mmc);
> +int mmc_get_op_cond(struct mmc *mmc, bool quiet);
>
> /**
> * Start device initialization and return immediately; it does not block on
--
~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
Re: [PATCH u-boot-mvebu 00/31] kwboot / kwbimage improvements
Hi Marek, Pali,
On Thu, Jul 08 2021, Marek Behún wrote:
> Hi Stefan and others,
>
> this is a series of improvements to kwboot, kwbimage and mvebu.
>
> The main goal of this series is to correctly use BootROM's code
> for loading U-Boot from NOR / NAND: currently only SPL is read by
> BootROM and the main U-Boot is read by SPL. By using BootROM to also
> load main U-Boot we can reduce the size of SPL image, since it does
> not need to contain code for reading NOR / NAND.
>
> Before merging, this series should be tested on as many relevant
> boards as possible.
Is this series available for pull at a public git repo? If not, what
commit is this series based on?
What platforms have you tested?
baruch
> Marek Behún (2):
> tools: kwbimage: Add constant for SDIO bootfrom
> tools: kwbimage: Cosmetic fix - remove redundant space character
>
> Pali Rohár (29):
> tools: kwbimage: Fix compilation without CONFIG_SYS_U_BOOT_OFFS
> tools: kwbimage: Simplify aligning and calculating checksum
> tools: kwbimage: Align SPI and NAND images to 256 bytes
> tools: kwbimage: Fix generation of SATA, SDIO and PCIe images
> tools: kwbimage: Don't crash when binary file name does not contain
> '/'
> tools: kwbimage: Fix check for v0 extended header checksum
> tools: kwbimage: Validate extended headers of v1 images
> tools: kwbimage: Validate data checksum of v1 images
> tools: kwbimage: Print size of binary header in
> kwbimage_print_header()
> tools: kwboot: Fix wrong parameter passed to read()
> tools: kwboot: Fix restoring terminal
> tools: kwboot: Print trailing newline after terminal is terminated
> tools: kwboot: Cosmetic fix - add missing curly brackets
> tools: kwboot: Check for v1 header size
> tools: kwbimage: Use -a parameter (load address) for v1 images
> arm: mvebu: Fix return_to_bootrom()
> arm: mvebu: Mark return_to_bootrom() as a noreturn function
> arm: mvebu: Implement return_to_bootrom() via U-Boot's SPL framework
> arm: mvebu: Use U-Boot's SPL BootROM framework for booting from
> NAND/UART
> arm: mvebu: Always use BootROM for loading the rest of U-Boot's binary
> arm: mvebu: gdsys: Remove custom spl_board_init()
> arm: mvebu: Remove legacy U-Boot header from kwbimage v1 files
> tools: kwbimage: Remove v1 kwbimage SPL padding to
> CONFIG_SYS_U_BOOT_OFFS bytes
> arm: mvebu: Remove unused macro CONFIG_SYS_U_BOOT_OFFS
> tools: kwbimage: Add support for more BINARY headers
> tools: kwbimage: Don't parse PAYLOAD keyword
> tools: kwbimage: Add support for DATA command also for v1 images
> tools: kwbimage: Add support for a new DATA_DELAY command
> tools: kwbimage: Do not hide usage of secure header under
> CONFIG_ARMADA_38X
>
> Makefile | 2 +-
> arch/arm/mach-mvebu/Kconfig| 16 +-
> arch/arm/mach-mvebu/include/mach/cpu.h | 2 +-
> arch/arm/mach-mvebu/lowlevel_spl.S | 3 +-
> arch/arm/mach-mvebu/spl.c | 90 +--
> board/gdsys/a38x/Makefile | 2 +-
> board/gdsys/a38x/spl.c | 20 --
> include/configs/clearfog.h | 6 +-
> include/configs/controlcenterdc.h | 8 +-
> include/configs/db-88f6720.h | 3 -
> include/configs/db-88f6820-amc.h | 5 -
> include/configs/db-88f6820-gp.h| 6 -
> include/configs/db-mv784mp-gp.h| 3 -
> include/configs/ds414.h| 5 -
> include/configs/helios4.h | 6 +-
> include/configs/theadorable.h | 3 -
> include/configs/turris_omnia.h | 6 -
> include/configs/x530.h | 3 -
> scripts/config_whitelist.txt | 1 -
> tools/Makefile | 8 -
> tools/kwbimage.c | 339 +
> tools/kwbimage.h | 30 ++-
> tools/kwboot.c | 14 +-
> 23 files changed, 296 insertions(+), 285 deletions(-)
> delete mode 100644 board/gdsys/a38x/spl.c
--
~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
Re: [PATCH u-boot-mvebu 22/31] arm: mvebu: Always use BootROM for loading the rest of U-Boot's binary
Hi Marek, Pali,
On Thu, Jul 08 2021, Marek Behún wrote:
> From: Pali Rohár
>
> Now that proper load and execution addresses are set in v1 kwbimage, we
> can use BootROM to continue loading main U-Boot binary instead of
> U-Boot's SPL code.
>
> This also reduces the size of U-Boot's SPL image.
>
> The v1 kwbimage contains two separate executable parts: DDR training
> code (contains SPL) and bootloader (contains main U-Boot). BootROM first
> loads the first part, executes it and expects that the code returns back.
> Afterwards it loads the second part and executes it.
>
> The current SPL code (used for the first part) for non-UART/NAND boots
> never returns back to BootROM and loads main U-Boot from external storage
> itself, and it lets BootROM think that it is still executing the first
> part - DDR training code.
>
> With this change the SPL always returns execution back to BootROM and
> lets BootROM to load and execute U-Boot, like it was already done when
> booting from UART and NAND.
>
> Note that the config options CONFIG_SPL_SPI_FLASH_SUPPORT,
> CONFIG_SPL_SPI_LOAD and CONFIG_SPL_SPI_SUPPORT needs to be enabled as
> config option CONFIG_SYS_U_BOOT_OFFS (used by kwbimage) depends on it.
I think it's worth noting here that a subsequent commit will remove
both.
baruch
--
~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
Re: [PATCH u-boot-marvell] mmc: mv_sdhci: call mmc_of_parse()
Hi Marek,
On Tue, Feb 02 2021, Marek Behún wrote:
> This is needed to parse more capabilities such as `non-removable`.
>
> Commit da18c62b6e6a ("mmc: sdhci: Implement SDHCI card detect") caused
> a regression on Turris Omnia, because mv_sdhci driver did not fill out
> host_caps from device-tree.
I posted a similar patch earlier today:
https://patchwork.ozlabs.org/project/uboot/patch/7dcd24e8d0149618cf686c47cce6728a64dffe2b.1612248184.git.bar...@tkos.co.il/
> Signed-off-by: Marek Behún
> Fixes: da18c62b6e6a ("mmc: sdhci: Implement SDHCI card detect")
My patch is missing this tag, though.
baruch
> Cc: p...@kernel.org
> Cc: Baruch Siach
> Cc: Stefan Roese
> ---
> drivers/mmc/mv_sdhci.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/mmc/mv_sdhci.c b/drivers/mmc/mv_sdhci.c
> index 556dd38046..4dc4a0d2be 100644
> --- a/drivers/mmc/mv_sdhci.c
> +++ b/drivers/mmc/mv_sdhci.c
> @@ -118,6 +118,10 @@ static int mv_sdhci_probe(struct udevice *dev)
> host->mmc->dev = dev;
> host->mmc->priv = host;
>
> + ret = mmc_of_parse(dev, >cfg);
> + if (ret)
> + return ret;
> +
> ret = sdhci_setup_cfg(>cfg, host, 0, 0);
> if (ret)
> return ret;
--
~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
[PATCH] mmc: mv_sdhci: parse device-tree entry
Call mmc_of_parse() so that generic DT properties like 'non-removable' are taken into account. This fixes boot on Clearfog with eMMC on SOM that requires the non-removable property. Reported-by: Thorsten Spille Signed-off-by: Baruch Siach --- drivers/mmc/mv_sdhci.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/mmc/mv_sdhci.c b/drivers/mmc/mv_sdhci.c index 9b3dfa13e619..0a8987c1b5da 100644 --- a/drivers/mmc/mv_sdhci.c +++ b/drivers/mmc/mv_sdhci.c @@ -118,6 +118,10 @@ static int mv_sdhci_probe(struct udevice *dev) host->mmc->dev = dev; host->mmc->priv = host; + ret = mmc_of_parse(dev, >cfg); + if (ret) + return ret; + ret = sdhci_setup_cfg(>cfg, host, 0, 0); if (ret) return ret; -- 2.30.0
Re: [PATCH 2/4] ARM: mvebu: helios4 dts changes to enable SPI
Hi Dennis,
On Mon, Dec 07 2020, dgilm...@redhat.com wrote:
> From: Dennis Gilmore
>
> mirror seettings for the clearfog on the helios4 to get SPI working.
>
> Signed-off-by: Dennis Gilmore
> ---
> arch/arm/dts/armada-388-helios4-u-boot.dtsi | 22 ++
> arch/arm/dts/armada-388-helios4.dts | 46 -
> 2 files changed, 58 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm/dts/armada-388-helios4-u-boot.dtsi
> b/arch/arm/dts/armada-388-helios4-u-boot.dtsi
> index 0753889854..82513a1ce7 100644
> --- a/arch/arm/dts/armada-388-helios4-u-boot.dtsi
> +++ b/arch/arm/dts/armada-388-helios4-u-boot.dtsi
> @@ -1,13 +1,5 @@
> // SPDX-License-Identifier: GPL-2.0+
>
> -/ {
> - aliases {
> - i2c0 =
> - i2c1 =
> - spi1 =
> - };
> -};
> -
> {
> phy-reset-gpios = < 19 GPIO_ACTIVE_LOW>;
> };
> @@ -37,5 +29,17 @@
> };
>
> {
> - u-boot,dm-spl;
> + u-boot,dm-spl;
> +};
> +
> + {
> + u-boot,dm-spl;
> +
> + eeprom@52 {
> + u-boot,dm-spl;
> + };
> +
> + eeprom@53 {
> + u-boot,dm-spl;
> + };
> };
> diff --git a/arch/arm/dts/armada-388-helios4.dts
> b/arch/arm/dts/armada-388-helios4.dts
> index fb49df2a3b..e948b94090 100644
> --- a/arch/arm/dts/armada-388-helios4.dts
> +++ b/arch/arm/dts/armada-388-helios4.dts
> @@ -22,10 +22,14 @@
> };
>
> aliases {
> - /* So that mvebu u-boot can update the MAC addresses */
> + /* So that mvebu u-boot can update the MAC address */
> ethernet1 =
> + spi1 =
> + i2c0 =
> + i2c1 =
> };
>
> +
> chosen {
> stdout-path = "serial0:115200n8";
> };
> @@ -306,3 +310,43 @@
> };
> };
> };
> +
> + {
> + helios4_spi1_cs_pins: spi1-cs-pins {
> + marvell,pins = "mpp55";
> + marvell,function = "spi1";
> + };
> + mikro_pins: mikro-pins {
> + /* int: mpp22 rst: mpp29 */
> + marvell,pins = "mpp22", "mpp29";
> + marvell,function = "gpio";
> + };
> + mikro_spi_pins: mikro-spi-pins {
> + marvell,pins = "mpp43";
> + marvell,function = "spi1";
> + };
> + mikro_uart_pins: mikro-uart-pins {
> + marvell,pins = "mpp24", "mpp25";
> + marvell,function = "ua1";
> + };
> + rear_button_pins: rear-button-pins {
> + marvell,pins = "mpp34";
> + marvell,function = "gpio";
> + };
There is no MikroBUS header or rear button on the Helios4 carrier as far
as I can see.
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + /*
> + * Add SPI CS pins for helios4:
> + * CS0: W25Q32
> + * CS1:
> + * CS2: mikrobus
Ditto.
> + */
> + pinctrl-0 = <_pins _spi_pins>;
> + pinctrl-names = "default";
> + status = "okay";
> +};
baruch
--
~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
[PATCH 4/5] mtd: pxa3xx_nand: remove dead code
The kfree() call is unreachable, and is not needed. Remove this call and
the fail_disable_clk label.
Reviewed-by: Stefan Roese
Signed-off-by: Baruch Siach
---
drivers/mtd/nand/raw/pxa3xx_nand.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/mtd/nand/raw/pxa3xx_nand.c
b/drivers/mtd/nand/raw/pxa3xx_nand.c
index c9b7a4251b4e..8481c6e3bf91 100644
--- a/drivers/mtd/nand/raw/pxa3xx_nand.c
+++ b/drivers/mtd/nand/raw/pxa3xx_nand.c
@@ -1768,7 +1768,7 @@ static int alloc_nand_resource(struct pxa3xx_nand_info
*info)
struct pxa3xx_nand_host *host;
struct nand_chip *chip = NULL;
struct mtd_info *mtd;
- int ret, cs;
+ int cs;
pdata = info->pdata;
if (pdata->num_cs <= 0)
@@ -1804,19 +1804,13 @@ static int alloc_nand_resource(struct pxa3xx_nand_info
*info)
/* Allocate a buffer to allow flash detection */
info->buf_size = INIT_BUFFER_SIZE;
info->data_buff = kmalloc(info->buf_size, GFP_KERNEL);
- if (info->data_buff == NULL) {
- ret = -ENOMEM;
- goto fail_disable_clk;
- }
+ if (info->data_buff == NULL)
+ return -ENOMEM;
/* initialize all interrupts to be disabled */
disable_int(info, NDSR_MASK);
return 0;
-
- kfree(info->data_buff);
-fail_disable_clk:
- return ret;
}
static int pxa3xx_nand_probe_dt(struct udevice *dev, struct pxa3xx_nand_info
*info)
--
2.28.0
[PATCH 3/5] mtd: pxa3xx_nand: port to use driver model
From: Shmuel Hazan
Use the generic DT code to find the device compatible property for us.
This makes the driver look more like other current drivers. It also make
it easier to add support for other variants like Armada 8K in a future
commit.
Signed-off-by: Shmuel Hazan
Signed-off-by: Baruch Siach
---
drivers/mtd/nand/raw/Kconfig | 1 +
drivers/mtd/nand/raw/pxa3xx_nand.c | 116 +
2 files changed, 54 insertions(+), 63 deletions(-)
diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig
index cd7e598aa8a7..160b599b3464 100644
--- a/drivers/mtd/nand/raw/Kconfig
+++ b/drivers/mtd/nand/raw/Kconfig
@@ -195,6 +195,7 @@ endif
config NAND_PXA3XX
bool "Support for NAND on PXA3xx and Armada 370/XP/38x"
select SYS_NAND_SELF_INIT
+ select DM_MTD
imply CMD_NAND
help
This enables the driver for the NAND flash device found on
diff --git a/drivers/mtd/nand/raw/pxa3xx_nand.c
b/drivers/mtd/nand/raw/pxa3xx_nand.c
index 5fb3081c8390..c9b7a4251b4e 100644
--- a/drivers/mtd/nand/raw/pxa3xx_nand.c
+++ b/drivers/mtd/nand/raw/pxa3xx_nand.c
@@ -22,6 +22,8 @@
#include
#include
#include
+#include
+#include
#include "pxa3xx_nand.h"
@@ -417,6 +419,14 @@ static struct nand_ecclayout ecc_layout_8KB_bch8bit = {
/* convert nano-seconds to nand flash controller clock cycles */
#define ns2cycle(ns, clk) (int)((ns) * (clk / 100) / 1000)
+static const struct udevice_id pxa3xx_nand_dt_ids[] = {
+ {
+ .compatible = "marvell,mvebu-pxa3xx-nand",
+ .data = PXA3XX_NAND_VARIANT_ARMADA370,
+ },
+ {}
+};
+
static enum pxa3xx_nand_variant pxa3xx_nand_get_variant(void)
{
/* We only support the Armada 370/XP/38x for now */
@@ -1809,74 +1819,52 @@ fail_disable_clk:
return ret;
}
-static int pxa3xx_nand_probe_dt(struct pxa3xx_nand_info *info)
+static int pxa3xx_nand_probe_dt(struct udevice *dev, struct pxa3xx_nand_info
*info)
{
struct pxa3xx_nand_platform_data *pdata;
- const void *blob = gd->fdt_blob;
- int node = -1;
pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
if (!pdata)
return -ENOMEM;
- /* Get address decoding nodes from the FDT blob */
- do {
- node = fdt_node_offset_by_compatible(blob, node,
-
"marvell,mvebu-pxa3xx-nand");
- if (node < 0)
- break;
-
- /* Bypass disabeld nodes */
- if (!fdtdec_get_is_enabled(blob, node))
- continue;
-
- /* Get the first enabled NAND controler base address */
- info->mmio_base =
- (void __iomem *)fdtdec_get_addr_size_auto_noparent(
- blob, node, "reg", 0, NULL, true);
+ info->mmio_base = dev_read_addr_ptr(dev);
- pdata->num_cs = fdtdec_get_int(blob, node, "num-cs", 1);
- if (pdata->num_cs != 1) {
- pr_err("pxa3xx driver supports single CS only\n");
- break;
- }
-
- if (fdtdec_get_bool(blob, node, "nand-enable-arbiter"))
- pdata->enable_arbiter = 1;
-
- if (fdtdec_get_bool(blob, node, "nand-keep-config"))
- pdata->keep_config = 1;
+ pdata->num_cs = dev_read_u32_default(dev, "num-cs", 1);
+ if (pdata->num_cs != 1) {
+ pr_err("pxa3xx driver supports single CS only\n");
+ return -EINVAL;
+ }
- /*
-* ECC parameters.
-* If these are not set, they will be selected according
-* to the detected flash type.
-*/
- /* ECC strength */
- pdata->ecc_strength = fdtdec_get_int(blob, node,
-"nand-ecc-strength", 0);
+ if (dev_read_bool(dev, "nand-enable-arbiter"))
+ pdata->enable_arbiter = 1;
- /* ECC step size */
- pdata->ecc_step_size = fdtdec_get_int(blob, node,
- "nand-ecc-step-size", 0);
+ if (dev_read_bool(dev, "nand-keep-config"))
+ pdata->keep_config = 1;
- info->pdata = pdata;
+ /*
+* ECC parameters.
+* If these are not set, they will be selected according
+* to the detected flash type.
+*/
+ /* ECC strength */
+ pdata->ecc_strength = dev_read_u32_default(dev, "nand-ecc-strength", 0);
- /* Currently support only a single NAND controller */
-
[PATCH 0/5] mtd: pxa3xx_nand: add support for Armada 8k
This series adds NAND flash support to Aramda 8k systems. Patches make the
necessary changes to the pxa3xx_nand driver and DT files.
v3:
Address Stefan's comments on patch #3
Move hunks from patch #3 to #5 to fix bisectability
v2:
Rebase on current master. Fixes conflict with commit 661c98121d4 ("mtd: nand:
pxa3xx: Fix not calling dev_xxx with a device")
Baruch Siach (2):
arm: dts: armada-cp110-master: update nand-controller
mtd: pxa3xx_nand: remove dead code
Shmuel Hazan (3):
arm: dts: armada-cp110-slave: add missing cps_nand
mtd: pxa3xx_nand: port to use driver model
mtd: nand: pxa3xx: enable NAND controller if the SoC needs it
arch/arm/dts/armada-cp110-master.dtsi | 15 ++-
arch/arm/dts/armada-cp110-slave.dtsi | 16 +++
drivers/mtd/nand/raw/Kconfig | 2 +
drivers/mtd/nand/raw/pxa3xx_nand.c| 180 ++
4 files changed, 125 insertions(+), 88 deletions(-)
--
2.28.0
[PATCH 5/5] mtd: nand: pxa3xx: enable NAND controller if the SoC needs it
From: Shmuel Hazan
Based on Linux kernel commit fc256f5789cb ("mtd: nand: pxa3xx: enable
NAND controller if the SoC needs it"). This commit adds support for the
Armada 8040 nand controller.
The kernel commit says this:
Marvell recent SoCs like A7k/A8k do not boot with NAND flash
controller activated by default. Enabling the controller is a matter
of writing in a system controller register that may also be used for
other NAND related choices.
Reviewed-by: Stefan Roese
Signed-off-by: Shmuel Hazan
Signed-off-by: Baruch Siach
---
drivers/mtd/nand/raw/Kconfig | 1 +
drivers/mtd/nand/raw/pxa3xx_nand.c | 52 --
2 files changed, 43 insertions(+), 10 deletions(-)
diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig
index 160b599b3464..08df12a3daf9 100644
--- a/drivers/mtd/nand/raw/Kconfig
+++ b/drivers/mtd/nand/raw/Kconfig
@@ -196,6 +196,7 @@ config NAND_PXA3XX
bool "Support for NAND on PXA3xx and Armada 370/XP/38x"
select SYS_NAND_SELF_INIT
select DM_MTD
+ select SYSCON
imply CMD_NAND
help
This enables the driver for the NAND flash device found on
diff --git a/drivers/mtd/nand/raw/pxa3xx_nand.c
b/drivers/mtd/nand/raw/pxa3xx_nand.c
index 8481c6e3bf91..361a9e32935b 100644
--- a/drivers/mtd/nand/raw/pxa3xx_nand.c
+++ b/drivers/mtd/nand/raw/pxa3xx_nand.c
@@ -22,6 +22,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -119,6 +121,10 @@ DECLARE_GLOBAL_DATA_PTR;
#define EXT_CMD_TYPE_LAST_RW 1 /* Last naked read/write */
#define EXT_CMD_TYPE_MONO 0 /* Monolithic read/write */
+/* System control register and bit to enable NAND on some SoCs */
+#define GENCONF_SOC_DEVICE_MUX 0x208
+#define GENCONF_SOC_DEVICE_MUX_NFC_EN BIT(0)
+
/*
* This should be large enough to read 'ONFI' and 'JEDEC'.
* Let's use 7 bytes, which is the maximum ID count supported
@@ -159,6 +165,7 @@ enum {
enum pxa3xx_nand_variant {
PXA3XX_NAND_VARIANT_PXA,
PXA3XX_NAND_VARIANT_ARMADA370,
+ PXA3XX_NAND_VARIANT_ARMADA_8K,
};
struct pxa3xx_nand_host {
@@ -424,13 +431,16 @@ static const struct udevice_id pxa3xx_nand_dt_ids[] = {
.compatible = "marvell,mvebu-pxa3xx-nand",
.data = PXA3XX_NAND_VARIANT_ARMADA370,
},
+ {
+ .compatible = "marvell,armada-8k-nand-controller",
+ .data = PXA3XX_NAND_VARIANT_ARMADA_8K,
+ },
{}
};
-static enum pxa3xx_nand_variant pxa3xx_nand_get_variant(void)
+static enum pxa3xx_nand_variant pxa3xx_nand_get_variant(struct udevice *dev)
{
- /* We only support the Armada 370/XP/38x for now */
- return PXA3XX_NAND_VARIANT_ARMADA370;
+ return dev_get_driver_data(dev);
}
static void pxa3xx_nand_set_timing(struct pxa3xx_nand_host *host,
@@ -707,7 +717,8 @@ static irqreturn_t pxa3xx_nand_irq(struct pxa3xx_nand_info
*info)
info->retcode = ERR_UNCORERR;
if (status & NDSR_CORERR) {
info->retcode = ERR_CORERR;
- if (info->variant == PXA3XX_NAND_VARIANT_ARMADA370 &&
+ if ((info->variant == PXA3XX_NAND_VARIANT_ARMADA370 ||
+info->variant == PXA3XX_NAND_VARIANT_ARMADA_8K) &&
info->ecc_bch)
info->ecc_err_cnt = NDSR_ERR_CNT(status);
else
@@ -762,7 +773,8 @@ static irqreturn_t pxa3xx_nand_irq(struct pxa3xx_nand_info
*info)
nand_writel(info, NDCB0, info->ndcb2);
/* NDCB3 register is available in NFCv2 (Armada 370/XP SoC) */
- if (info->variant == PXA3XX_NAND_VARIANT_ARMADA370)
+ if (info->variant == PXA3XX_NAND_VARIANT_ARMADA370 ||
+ info->variant == PXA3XX_NAND_VARIANT_ARMADA_8K)
nand_writel(info, NDCB0, info->ndcb3);
}
@@ -1676,7 +1688,8 @@ static int pxa3xx_nand_scan(struct mtd_info *mtd)
}
/* Device detection must be done with ECC disabled */
- if (info->variant == PXA3XX_NAND_VARIANT_ARMADA370)
+ if (info->variant == PXA3XX_NAND_VARIANT_ARMADA370 ||
+ info->variant == PXA3XX_NAND_VARIANT_ARMADA_8K)
nand_writel(info, NDECCCTRL, 0x0);
if (nand_scan_ident(mtd, 1, NULL))
@@ -1726,7 +1739,8 @@ static int pxa3xx_nand_scan(struct mtd_info *mtd)
* (aka split) command handling,
*/
if (mtd->writesize > info->chunk_size) {
- if (info->variant == PXA3XX_NAND_VARIANT_ARMADA370) {
+ if (info->variant == PXA3XX_NAND_VARIANT_ARMADA370 ||
+ info->variant == PXA3XX_NAND_VARIANT_ARMADA_8K) {
chip->cmdfunc = nand_cmdfunc_extended;
} else {
[PATCH 1/5] arm: dts: armada-cp110-slave: add missing cps_nand
From: Shmuel Hazan
Align node properties to kernel dts node.
Keep U-Boot specific nand-enable-arbiter, and num-cs for compatibility
with the current driver.
Reviewed-by: Stefan Roese
Signed-off-by: Shmuel Hazan
Signed-off-by: Baruch Siach
---
arch/arm/dts/armada-cp110-slave.dtsi | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm/dts/armada-cp110-slave.dtsi
b/arch/arm/dts/armada-cp110-slave.dtsi
index b426a4eb6910..6cf217783709 100644
--- a/arch/arm/dts/armada-cp110-slave.dtsi
+++ b/arch/arm/dts/armada-cp110-slave.dtsi
@@ -267,6 +267,22 @@
utmi-port = ;
status = "disabled";
};
+
+ cps_nand: nand@72 {
+ compatible =
"marvell,armada-8k-nand-controller",
+ "marvell,armada370-nand-controller";
+ reg = <0x72 0x54>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = ;
+ clock-names = "core", "reg";
+ clocks = <_syscon0 1 2>,
+<_syscon0 1 17>;
+ marvell,system-controller = <_syscon0>;
+ nand-enable-arbiter;
+ num-cs = <1>;
+ status = "disabled";
+ };
};
cps_pcie0: pcie@f460 {
--
2.28.0
[PATCH 2/5] arm: dts: armada-cp110-master: update nand-controller
Align node properties to kernel dts node.
The change of compatible property does not affect any currently
supported board.
Keep U-Boot specific nand-enable-arbiter, and num-cs for compatibility
with the current driver.
Reviewed-by: Stefan Roese
Signed-off-by: Baruch Siach
---
arch/arm/dts/armada-cp110-master.dtsi | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/arch/arm/dts/armada-cp110-master.dtsi
b/arch/arm/dts/armada-cp110-master.dtsi
index cd5c974482e6..7d0d31da306d 100644
--- a/arch/arm/dts/armada-cp110-master.dtsi
+++ b/arch/arm/dts/armada-cp110-master.dtsi
@@ -285,15 +285,18 @@
};
cpm_nand: nand@72 {
- compatible = "marvell,mvebu-pxa3xx-nand";
- reg = <0x72 0x100>;
+ compatible =
"marvell,armada-8k-nand-controller",
+ "marvell,armada370-nand-controller";
+ reg = <0x72 0x54>;
#address-cells = <1>;
-
- clocks = <_syscon0 1 2>;
+ #size-cells = <0>;
+ interrupts = ;
+ clock-names = "core", "reg";
+ clocks = <_syscon0 1 2>,
+<_syscon0 1 17>;
+ marvell,system-controller = <_syscon0>;
nand-enable-arbiter;
num-cs = <1>;
- nand-ecc-strength = <4>;
- nand-ecc-step-size = <512>;
status = "disabled";
};
--
2.28.0
Re: [PATCH] imx: mx6cuboxi: Disable CONFIG_IMX_THERMAL
Hi Simon,
Adding Walter to Cc.
On Thu, Oct 29 2020, Simon Glass wrote:
> This feature is incompatble with of-platdata since it uses the
> U_BOOT_DEVICE() macro. With of-platdata the only devices permitted are
> those created by dtoc.
>
> Drop this option for now, until the driver can be corrected.
As I understand, of-platdata is only enabled in SPL. Is there a way to
limit imx_thermal drop to SPL? The thermal driver in not very useful in
SPL anyway, right?
Thanks,
baruch
> Signed-off-by: Simon Glass
> ---
>
> include/configs/mx6cuboxi.h | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/include/configs/mx6cuboxi.h b/include/configs/mx6cuboxi.h
> index cfab9a7fc02..55717c77ab3 100644
> --- a/include/configs/mx6cuboxi.h
> +++ b/include/configs/mx6cuboxi.h
> @@ -13,8 +13,6 @@
>
> #include "imx6_spl.h"
>
> -#define CONFIG_IMX_THERMAL
> -
> #define CONFIG_SYS_MALLOC_LEN(10 * SZ_1M)
>
> /* MMC Configs */
--
~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
[PATCH] imx8mp_evk: README instruction fixes
Use the full name of firmware self extracting file to make it run. Also, don't use sudo when not needed. Signed-off-by: Baruch Siach --- This time add the u-boot list to Cc. --- board/freescale/imx8mp_evk/README | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/board/freescale/imx8mp_evk/README b/board/freescale/imx8mp_evk/README index 7dd3a9352a57..0c65a894bb1a 100644 --- a/board/freescale/imx8mp_evk/README +++ b/board/freescale/imx8mp_evk/README @@ -13,17 +13,17 @@ Note: $(srctree) is the U-Boot source directory Get ATF from: https://source.codeaurora.org/external/imx/imx-atf branch: imx_5.4.3_2.0.0 $ make PLAT=imx8mp bl31 -$ sudo cp build/imx8mp/release/bl31.bin $(srctree) +$ cp build/imx8mp/release/bl31.bin $(srctree) Get the ddr firmware $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.7.bin $ chmod +x firmware-imx-8.7.bin -$ ./firmware-imx-8.7 -$ sudo cp firmware-imx-8.7/firmware/ddr/synopsys/lpddr4_pmu_train_1d_dmem_201904.bin $(srctree)/lpddr4_pmu_train_1d_dmem.bin -$ sudo cp firmware-imx-8.7/firmware/ddr/synopsys/lpddr4_pmu_train_1d_imem_201904.bin $(srctree)/lpddr4_pmu_train_1d_imem.bin -$ sudo cp firmware-imx-8.7/firmware/ddr/synopsys/lpddr4_pmu_train_2d_dmem_201904.bin $(srctree)/lpddr4_pmu_train_2d_dmem.bin -$ sudo cp firmware-imx-8.7/firmware/ddr/synopsys/lpddr4_pmu_train_2d_imem_201904.bin $(srctree)/lpddr4_pmu_train_2d_imem.bin +$ ./firmware-imx-8.7.bin +$ cp firmware-imx-8.7/firmware/ddr/synopsys/lpddr4_pmu_train_1d_dmem_201904.bin $(srctree)/lpddr4_pmu_train_1d_dmem.bin +$ cp firmware-imx-8.7/firmware/ddr/synopsys/lpddr4_pmu_train_1d_imem_201904.bin $(srctree)/lpddr4_pmu_train_1d_imem.bin +$ cp firmware-imx-8.7/firmware/ddr/synopsys/lpddr4_pmu_train_2d_dmem_201904.bin $(srctree)/lpddr4_pmu_train_2d_dmem.bin +$ cp firmware-imx-8.7/firmware/ddr/synopsys/lpddr4_pmu_train_2d_imem_201904.bin $(srctree)/lpddr4_pmu_train_2d_imem.bin Build U-Boot -- 2.28.0
Re: [PATCH v2 0/5] mtd: pxa3xx_nand: add support for Armada 8k
Hi Stefan,
On Tue, Oct 20 2020, Stefan Roese wrote:
> On 19.10.20 07:24, Baruch Siach wrote:
>> On Sun, Oct 18 2020, Chris Packham wrote:
>>> On Mon, Oct 19, 2020 at 1:59 AM Baruch Siach wrote:
>>>>
>>>> This series adds NAND flash support to Aramda 8k systems. Patches make the
>>>> necessary changes to the pxa3xx_nand driver and DT files.
>>>>
>>>> v2:
>>>>Rebase on current master. Fixes conflict with commit 661c98121d4 ("mtd:
>>>> nand:
>>>>pxa3xx: Fix not calling dev_xxx with a device")
>>>
>>> Is it worth looking at bringing in the newer marvell_nand driver from
>>> Linux? I suspect that it will be easier to keep in sync with changes
>>> for the Armada 8K. I have considered it in the past but it kind of
>>> fell off my radar.
>>
>> The kernel raw nand API has seen some significant changes recently. It
>> looks like the kernel marvell_nand driver relies on newer API. I'm not
>> sure how easy would be syncing the drivers to a degree that makes
>> porting of changes trivial. It would probably require many other changes
>> in generic U-Boot raw NAND code.
>
> I agree that without a re-sync with a more recent Linux MTD (NAND) core
> code, this task might prove complex and failure prone. And sync'ing the
> MTD core is also a pretty complex task which needs to be done very
> carefully, to not break any existing platforms. FWICT, nobody is working
> on it right now and we can't wait for this to happen and stall the
> development here. So from my point of view, I'm okay with updates to
> the current PXA NAND driver. Testing of these patches on other platforms
> would be very welcome though.
I should note that the same driver with these modifications was tested
successfully on Armada 385 systems with NAND flash and UBIFS.
Thanks,
baruch
>> Maybe Miquel can shed some light on that.
>>
>> Unfortunately, the U-Boot MAINTAINERS NAND FLASH entry is marked
>> "Orphaned (Since 2018-07)".
>
> Yes, this is unfortunate. Volunteers are always welcome. ;)
>
> Thanks,
> Stefan
>
>> baruch
>>
>>>> Baruch Siach (2):
>>>>arm: dts: armada-cp110-master: update nand-controller
>>>>mtd: pxa3xx_nand: remove dead code
>>>>
>>>> Shmuel Hazan (3):
>>>>arm: dts: armada-cp110-slave: add missing cps_nand
>>>>mtd: pxa3xx_nand: port to use driver model
>>>>mtd: nand: pxa3xx: enable NAND controller if the SoC needs it
>>>>
>>>> arch/arm/dts/armada-cp110-master.dtsi | 15 ++-
>>>> arch/arm/dts/armada-cp110-slave.dtsi | 16 +++
>>>> drivers/mtd/nand/raw/Kconfig | 2 +
>>>> drivers/mtd/nand/raw/pxa3xx_nand.c| 179 ++
>>>> 4 files changed, 124 insertions(+), 88 deletions(-)
--
~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
Re: [PATCH 0/3] phy: marvell: cp110: fix Armada 8k rev B0 boot hang
Hi Stefan,
On Tue, Oct 20 2020, Stefan Roese wrote:
> On 18.10.20 16:11, Baruch Siach wrote:
>> Boot of Armada 8040 rev B0 hangs when U-Boot attempts to initialize the PCIe
>> serdes. Adapt patches from downstream Marvell tree that move serdes
>> initialization to ATF.
>>
>> This series requires upstream ATF version 2.1 or newer.
>
> Is there a way to detect if an older ATF is installed and print
> an error message (warning) in this case?
I see no way to detect ATF version using smc_call().
Downstream Marvell ATF have the required code[1] in the 18.12.2
release[2], which is based on ATF 1.5. This is the last ATF version from
Marvell that was released on github.
[1]
https://github.com/MarvellEmbeddedProcessors/atf-marvell/commit/4db85ae088a5e2f51e9a5a671f531cb80a632067
[2]
https://github.com/MarvellEmbeddedProcessors/atf-marvell/commits/atf-v1.5-armada-18.12
baruch
--
~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
Re: [PATCH v2 0/5] mtd: pxa3xx_nand: add support for Armada 8k
Hi Chris,
On Sun, Oct 18 2020, Chris Packham wrote:
> On Mon, Oct 19, 2020 at 1:59 AM Baruch Siach wrote:
>>
>> This series adds NAND flash support to Aramda 8k systems. Patches make the
>> necessary changes to the pxa3xx_nand driver and DT files.
>>
>> v2:
>> Rebase on current master. Fixes conflict with commit 661c98121d4 ("mtd:
>> nand:
>> pxa3xx: Fix not calling dev_xxx with a device")
>
> Is it worth looking at bringing in the newer marvell_nand driver from
> Linux? I suspect that it will be easier to keep in sync with changes
> for the Armada 8K. I have considered it in the past but it kind of
> fell off my radar.
The kernel raw nand API has seen some significant changes recently. It
looks like the kernel marvell_nand driver relies on newer API. I'm not
sure how easy would be syncing the drivers to a degree that makes
porting of changes trivial. It would probably require many other changes
in generic U-Boot raw NAND code.
Maybe Miquel can shed some light on that.
Unfortunately, the U-Boot MAINTAINERS NAND FLASH entry is marked
"Orphaned (Since 2018-07)".
baruch
>> Baruch Siach (2):
>> arm: dts: armada-cp110-master: update nand-controller
>> mtd: pxa3xx_nand: remove dead code
>>
>> Shmuel Hazan (3):
>> arm: dts: armada-cp110-slave: add missing cps_nand
>> mtd: pxa3xx_nand: port to use driver model
>> mtd: nand: pxa3xx: enable NAND controller if the SoC needs it
>>
>> arch/arm/dts/armada-cp110-master.dtsi | 15 ++-
>> arch/arm/dts/armada-cp110-slave.dtsi | 16 +++
>> drivers/mtd/nand/raw/Kconfig | 2 +
>> drivers/mtd/nand/raw/pxa3xx_nand.c| 179 ++
>> 4 files changed, 124 insertions(+), 88 deletions(-)
>>
>> --
>> 2.28.0
>>
--
~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
[PATCH 2/3] phy: marvell: cp110: let the firmware configure comphy for PCIe
From: Grzegorz Jaszczyk
Replace the comphy initialization for PCIe with appropriate SMC call, so
the firmware will perform appropriate comphy initialization.
Signed-off-by: Grzegorz Jaszczyk
Signed-off-by: Ken Ma
Reviewed-by: Igal Liberman
Signed-off-by: Baruch Siach
---
drivers/phy/marvell/comphy_cp110.c | 451 +
1 file changed, 12 insertions(+), 439 deletions(-)
diff --git a/drivers/phy/marvell/comphy_cp110.c
b/drivers/phy/marvell/comphy_cp110.c
index 31baa0bb3700..5b6aaa62487b 100644
--- a/drivers/phy/marvell/comphy_cp110.c
+++ b/drivers/phy/marvell/comphy_cp110.c
@@ -31,6 +31,11 @@ DECLARE_GLOBAL_DATA_PTR;
#define COMPHY_FW_MODE_FORMAT(mode)((mode) << 12)
#define COMPHY_FW_FORMAT(mode, idx, speeds)\
(((mode) << 12) | ((idx) << 8) | ((speeds) << 2))
+
+#define COMPHY_FW_PCIE_FORMAT(pcie_width, clk_src, mode, speeds) \
+ (((pcie_width) << 18) | ((clk_src) << 17) | \
+COMPHY_FW_FORMAT(mode, 0, speeds))
+
#define COMPHY_SATA_MODE 0x1
#define COMPHY_SGMII_MODE 0x2 /* SGMII 1G */
#define COMPHY_HS_SGMII_MODE 0x3 /* SGMII 2.5G */
@@ -112,441 +117,6 @@ static u32 polling_with_timeout(void __iomem *addr, u32
val,
return 0;
}
-static int comphy_pcie_power_up(u32 lane, u32 pcie_width, bool clk_src,
- bool is_end_point, void __iomem *hpipe_base,
- void __iomem *comphy_base)
-{
- u32 mask, data, ret = 1;
- void __iomem *hpipe_addr = HPIPE_ADDR(hpipe_base, lane);
- void __iomem *comphy_addr = COMPHY_ADDR(comphy_base, lane);
- void __iomem *addr;
- u32 pcie_clk = 0; /* set input by default */
-
- debug_enter();
-
- /*
-* ToDo:
-* Add SAR (Sample-At-Reset) configuration for the PCIe clock
-* direction. SAR code is currently not ported from Marvell
-* U-Boot to mainline version.
-*
-* SerDes Lane 4/5 got the PCIe ref-clock #1,
-* and SerDes Lane 0 got PCIe ref-clock #0
-*/
- debug("PCIe clock = %x\n", pcie_clk);
- debug("PCIe RC= %d\n", !is_end_point);
- debug("PCIe width = %d\n", pcie_width);
-
- /* enable PCIe by4 and by2 */
- if (lane == 0) {
- if (pcie_width == 4) {
- reg_set(comphy_base + COMMON_PHY_SD_CTRL1,
- 0x1 << COMMON_PHY_SD_CTRL1_PCIE_X4_EN_OFFSET,
- COMMON_PHY_SD_CTRL1_PCIE_X4_EN_MASK);
- } else if (pcie_width == 2) {
- reg_set(comphy_base + COMMON_PHY_SD_CTRL1,
- 0x1 << COMMON_PHY_SD_CTRL1_PCIE_X2_EN_OFFSET,
- COMMON_PHY_SD_CTRL1_PCIE_X2_EN_MASK);
- }
- }
-
- /*
-* If PCIe clock is output and clock source from SerDes lane 5,
-* we need to configure the clock-source MUX.
-* By default, the clock source is from lane 4
-*/
- if (pcie_clk && clk_src && (lane == 5)) {
- reg_set((void __iomem *)DFX_DEV_GEN_CTRL12,
- 0x3 << DFX_DEV_GEN_PCIE_CLK_SRC_OFFSET,
- DFX_DEV_GEN_PCIE_CLK_SRC_MASK);
- }
-
- debug("stage: RFU configurations - hard reset comphy\n");
- /* RFU configurations - hard reset comphy */
- mask = COMMON_PHY_CFG1_PWR_UP_MASK;
- data = 0x1 << COMMON_PHY_CFG1_PWR_UP_OFFSET;
- mask |= COMMON_PHY_CFG1_PIPE_SELECT_MASK;
- data |= 0x1 << COMMON_PHY_CFG1_PIPE_SELECT_OFFSET;
- mask |= COMMON_PHY_CFG1_PWR_ON_RESET_MASK;
- data |= 0x0 << COMMON_PHY_CFG1_PWR_ON_RESET_OFFSET;
- mask |= COMMON_PHY_CFG1_CORE_RSTN_MASK;
- data |= 0x0 << COMMON_PHY_CFG1_CORE_RSTN_OFFSET;
- mask |= COMMON_PHY_PHY_MODE_MASK;
- data |= 0x0 << COMMON_PHY_PHY_MODE_OFFSET;
- reg_set(comphy_addr + COMMON_PHY_CFG1_REG, data, mask);
-
- /* release from hard reset */
- mask = COMMON_PHY_CFG1_PWR_ON_RESET_MASK;
- data = 0x1 << COMMON_PHY_CFG1_PWR_ON_RESET_OFFSET;
- mask |= COMMON_PHY_CFG1_CORE_RSTN_MASK;
- data |= 0x1 << COMMON_PHY_CFG1_CORE_RSTN_OFFSET;
- reg_set(comphy_addr + COMMON_PHY_CFG1_REG, data, mask);
-
- /* Wait 1ms - until band gap and ref clock ready */
- mdelay(1);
- /* Start comphy Configuration */
- debug("stage: Comphy configuration\n");
- /* Set PIPE soft reset */
- mask = HPIPE_RST_CLK_CTRL_PIPE_RST_MASK;
- data = 0x1 << HPIPE_RST_CLK_CTRL_PIPE_RST_OFFSET;
- /* Set PHY datapath width mode for V0 */
- mask |= HPIPE_RST_CLK_CTRL_FIXED_PCLK_MASK;
- data |= 0x1 << HPIPE_RST_CLK_CTRL_FIXED_PCLK_OFFSET;
-
[PATCH 0/3] phy: marvell: cp110: fix Armada 8k rev B0 boot hang
Boot of Armada 8040 rev B0 hangs when U-Boot attempts to initialize the PCIe serdes. Adapt patches from downstream Marvell tree that move serdes initialization to ATF. This series requires upstream ATF version 2.1 or newer. Grzegorz Jaszczyk (2): phy: marvell: cp110: let the firmware configure the comphy phy: marvell: cp110: let the firmware configure comphy for PCIe Igal Liberman (1): phy: marvell: cp110: update mode parameter for pcie power on calls drivers/phy/marvell/comphy_cp110.c | 1270 +++- 1 file changed, 104 insertions(+), 1166 deletions(-) -- 2.28.0
[PATCH 3/3] phy: marvell: cp110: update mode parameter for pcie power on calls
From: Igal Liberman It helps ATF to determine who called power on function (U-boot/Linux). The corresponding ATF code was added in this commit: mvebu: cp110: avoid pcie power on/off sequence when called from Linux https://github.com/ARM-software/arm-trusted-firmware/commit/55df84f974ea37abbb4f93f000f101f70cda5303 Signed-off-by: Igal Liberman Reviewed-by: Grzegorz Jaszczyk Signed-off-by: Baruch Siach --- drivers/phy/marvell/comphy_cp110.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/phy/marvell/comphy_cp110.c b/drivers/phy/marvell/comphy_cp110.c index 5b6aaa62487b..b0fcb13f1c9a 100644 --- a/drivers/phy/marvell/comphy_cp110.c +++ b/drivers/phy/marvell/comphy_cp110.c @@ -28,13 +28,16 @@ DECLARE_GLOBAL_DATA_PTR; #define MV_SIP_COMPHY_POWER_OFF0x8202 #define MV_SIP_COMPHY_PLL_LOCK 0x8203 +/* Used to distinguish between different possible callers (U-boot/Linux) */ +#define COMPHY_CALLER_UBOOT(0x1 << 21) + #define COMPHY_FW_MODE_FORMAT(mode)((mode) << 12) #define COMPHY_FW_FORMAT(mode, idx, speeds)\ (((mode) << 12) | ((idx) << 8) | ((speeds) << 2)) #define COMPHY_FW_PCIE_FORMAT(pcie_width, clk_src, mode, speeds) \ - (((pcie_width) << 18) | ((clk_src) << 17) | \ -COMPHY_FW_FORMAT(mode, 0, speeds)) + (COMPHY_CALLER_UBOOT | ((pcie_width) << 18) | \ + ((clk_src) << 17) | COMPHY_FW_FORMAT(mode, 0, speeds)) #define COMPHY_SATA_MODE 0x1 #define COMPHY_SGMII_MODE 0x2 /* SGMII 1G */ -- 2.28.0
[PATCH 1/3] phy: marvell: cp110: let the firmware configure the comphy
From: Grzegorz Jaszczyk
Replace all comphy initialization with appropriate smc calls. It will
result with triggering synchronous exception that is handled by Secure
Monitor code in EL3. Then the Secure Monitor code will dispatch each smc
call (by parsing the smc function identifier) and triggers appropriate
comphy initialization.
This patch reworks serdes handling for: SATA, SGMII, HS-SGMII and SFI
interfaces.
Signed-off-by: Grzegorz Jaszczyk
Reviewed-by: Igal Liberman
Signed-off-by: Baruch Siach
---
drivers/phy/marvell/comphy_cp110.c | 816 -
1 file changed, 89 insertions(+), 727 deletions(-)
diff --git a/drivers/phy/marvell/comphy_cp110.c
b/drivers/phy/marvell/comphy_cp110.c
index 15e80049def6..31baa0bb3700 100644
--- a/drivers/phy/marvell/comphy_cp110.c
+++ b/drivers/phy/marvell/comphy_cp110.c
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -22,6 +23,32 @@ DECLARE_GLOBAL_DATA_PTR;
#define HPIPE_ADDR(base, lane) (SD_ADDR(base, lane) + 0x800)
#define COMPHY_ADDR(base, lane)(base + 0x28 * lane)
+/* Firmware related definitions used for SMC calls */
+#define MV_SIP_COMPHY_POWER_ON 0x8201
+#define MV_SIP_COMPHY_POWER_OFF0x8202
+#define MV_SIP_COMPHY_PLL_LOCK 0x8203
+
+#define COMPHY_FW_MODE_FORMAT(mode)((mode) << 12)
+#define COMPHY_FW_FORMAT(mode, idx, speeds)\
+ (((mode) << 12) | ((idx) << 8) | ((speeds) << 2))
+#define COMPHY_SATA_MODE 0x1
+#define COMPHY_SGMII_MODE 0x2 /* SGMII 1G */
+#define COMPHY_HS_SGMII_MODE 0x3 /* SGMII 2.5G */
+#define COMPHY_USB3H_MODE 0x4
+#define COMPHY_USB3D_MODE 0x5
+#define COMPHY_PCIE_MODE 0x6
+#define COMPHY_RXAUI_MODE 0x7
+#define COMPHY_XFI_MODE0x8
+#define COMPHY_SFI_MODE0x9
+#define COMPHY_USB3_MODE 0xa
+#define COMPHY_AP_MODE 0xb
+
+/* Comphy unit index macro */
+#define COMPHY_UNIT_ID00
+#define COMPHY_UNIT_ID11
+#define COMPHY_UNIT_ID22
+#define COMPHY_UNIT_ID33
+
struct utmi_phy_data {
void __iomem *utmi_base_addr;
void __iomem *usb_cfg_addr;
@@ -642,15 +669,31 @@ static int comphy_usb3_power_up(u32 lane, void __iomem
*hpipe_base,
return ret;
}
+static int comphy_smc(u32 function_id, void __iomem *comphy_base_addr,
+ u32 lane, u32 mode)
+{
+ struct pt_regs pregs = {0};
+
+ pregs.regs[0] = function_id;
+ pregs.regs[1] = (unsigned long)comphy_base_addr;
+ pregs.regs[2] = lane;
+ pregs.regs[3] = mode;
+
+ smc_call();
+
+ /*
+* TODO: Firmware return 0 on success, temporary map it to u-boot
+* convention, but after all comphy will be reworked the convention in
+* u-boot should be change and this conversion removed
+*/
+ return pregs.regs[0] ? 0 : 1;
+}
+
static int comphy_sata_power_up(u32 lane, void __iomem *hpipe_base,
- void __iomem *comphy_base, int cp_index,
- u32 invert)
+ void __iomem *comphy_base_addr, int cp_index,
+ u32 type)
{
u32 mask, data, i, ret = 1;
- void __iomem *hpipe_addr = HPIPE_ADDR(hpipe_base, lane);
- void __iomem *sd_ip_addr = SD_ADDR(hpipe_base, lane);
- void __iomem *comphy_addr = COMPHY_ADDR(comphy_base, lane);
- void __iomem *addr;
void __iomem *sata_base = NULL;
int sata_node = -1; /* Set to -1 in order to read the first sata node */
@@ -703,255 +746,8 @@ static int comphy_sata_power_up(u32 lane, void __iomem
*hpipe_base,
data |= 0x0 << SATA3_CTRL_SATA_SSU_OFFSET;
reg_set(sata_base + SATA3_VENDOR_DATA, data, mask);
- debug("stage: RFU configurations - hard reset comphy\n");
- /* RFU configurations - hard reset comphy */
- mask = COMMON_PHY_CFG1_PWR_UP_MASK;
- data = 0x1 << COMMON_PHY_CFG1_PWR_UP_OFFSET;
- mask |= COMMON_PHY_CFG1_PIPE_SELECT_MASK;
- data |= 0x0 << COMMON_PHY_CFG1_PIPE_SELECT_OFFSET;
- mask |= COMMON_PHY_CFG1_PWR_ON_RESET_MASK;
- data |= 0x0 << COMMON_PHY_CFG1_PWR_ON_RESET_OFFSET;
- mask |= COMMON_PHY_CFG1_CORE_RSTN_MASK;
- data |= 0x0 << COMMON_PHY_CFG1_CORE_RSTN_OFFSET;
- reg_set(comphy_addr + COMMON_PHY_CFG1_REG, data, mask);
-
- /* Set select data width 40Bit - SATA mode only */
- reg_set(comphy_addr + COMMON_PHY_CFG6_REG,
- 0x1 << COMMON_PHY_CFG6_IF_40_SEL_OFFSET,
- COMMON_PHY_CFG6_IF_40_SEL_MASK);
-
- /* release from hard reset in SD external */
- mask = SD_EXTERNAL_CONFIG1_RESET_IN_MASK;
- data = 0x1 << SD_EXTERNAL_CONFIG1_RESET_IN_OFFS
[PATCH v2 0/5] mtd: pxa3xx_nand: add support for Armada 8k
This series adds NAND flash support to Aramda 8k systems. Patches make the
necessary changes to the pxa3xx_nand driver and DT files.
v2:
Rebase on current master. Fixes conflict with commit 661c98121d4 ("mtd: nand:
pxa3xx: Fix not calling dev_xxx with a device")
Baruch Siach (2):
arm: dts: armada-cp110-master: update nand-controller
mtd: pxa3xx_nand: remove dead code
Shmuel Hazan (3):
arm: dts: armada-cp110-slave: add missing cps_nand
mtd: pxa3xx_nand: port to use driver model
mtd: nand: pxa3xx: enable NAND controller if the SoC needs it
arch/arm/dts/armada-cp110-master.dtsi | 15 ++-
arch/arm/dts/armada-cp110-slave.dtsi | 16 +++
drivers/mtd/nand/raw/Kconfig | 2 +
drivers/mtd/nand/raw/pxa3xx_nand.c| 179 ++
4 files changed, 124 insertions(+), 88 deletions(-)
--
2.28.0
[PATCH v2 5/5] mtd: nand: pxa3xx: enable NAND controller if the SoC needs it
From: Shmuel Hazan
Based on Linux kernel commit fc256f5789cb ("mtd: nand: pxa3xx: enable
NAND controller if the SoC needs it"). This commit adds support for the
Armada 8040 nand controller.
The kernel commit says this:
Marvell recent SoCs like A7k/A8k do not boot with NAND flash
controller activated by default. Enabling the controller is a matter
of writing in a system controller register that may also be used for
other NAND related choices.
Signed-off-by: Shmuel Hazan
Signed-off-by: Baruch Siach
---
drivers/mtd/nand/raw/pxa3xx_nand.c | 50 --
1 file changed, 41 insertions(+), 9 deletions(-)
diff --git a/drivers/mtd/nand/raw/pxa3xx_nand.c
b/drivers/mtd/nand/raw/pxa3xx_nand.c
index 635794b1691a..beaa290f7480 100644
--- a/drivers/mtd/nand/raw/pxa3xx_nand.c
+++ b/drivers/mtd/nand/raw/pxa3xx_nand.c
@@ -22,6 +22,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -119,6 +121,10 @@ DECLARE_GLOBAL_DATA_PTR;
#define EXT_CMD_TYPE_LAST_RW 1 /* Last naked read/write */
#define EXT_CMD_TYPE_MONO 0 /* Monolithic read/write */
+/* System control register and bit to enable NAND on some SoCs */
+#define GENCONF_SOC_DEVICE_MUX 0x208
+#define GENCONF_SOC_DEVICE_MUX_NFC_EN BIT(0)
+
/*
* This should be large enough to read 'ONFI' and 'JEDEC'.
* Let's use 7 bytes, which is the maximum ID count supported
@@ -159,6 +165,7 @@ enum {
enum pxa3xx_nand_variant {
PXA3XX_NAND_VARIANT_PXA,
PXA3XX_NAND_VARIANT_ARMADA370,
+ PXA3XX_NAND_VARIANT_ARMADA_8K,
};
struct pxa3xx_nand_host {
@@ -424,13 +431,16 @@ static const struct udevice_id pxa3xx_nand_dt_ids[] = {
.compatible = "marvell,mvebu-pxa3xx-nand",
.data = PXA3XX_NAND_VARIANT_ARMADA370,
},
+ {
+ .compatible = "marvell,armada-8k-nand-controller",
+ .data = PXA3XX_NAND_VARIANT_ARMADA_8K,
+ },
{}
};
-static enum pxa3xx_nand_variant pxa3xx_nand_get_variant(void)
+static enum pxa3xx_nand_variant pxa3xx_nand_get_variant(struct udevice *dev)
{
- /* We only support the Armada 370/XP/38x for now */
- return PXA3XX_NAND_VARIANT_ARMADA370;
+ return dev_get_driver_data(dev);
}
static void pxa3xx_nand_set_timing(struct pxa3xx_nand_host *host,
@@ -707,7 +717,8 @@ static irqreturn_t pxa3xx_nand_irq(struct pxa3xx_nand_info
*info)
info->retcode = ERR_UNCORERR;
if (status & NDSR_CORERR) {
info->retcode = ERR_CORERR;
- if (info->variant == PXA3XX_NAND_VARIANT_ARMADA370 &&
+ if ((info->variant == PXA3XX_NAND_VARIANT_ARMADA370 ||
+info->variant == PXA3XX_NAND_VARIANT_ARMADA_8K) &&
info->ecc_bch)
info->ecc_err_cnt = NDSR_ERR_CNT(status);
else
@@ -762,7 +773,8 @@ static irqreturn_t pxa3xx_nand_irq(struct pxa3xx_nand_info
*info)
nand_writel(info, NDCB0, info->ndcb2);
/* NDCB3 register is available in NFCv2 (Armada 370/XP SoC) */
- if (info->variant == PXA3XX_NAND_VARIANT_ARMADA370)
+ if (info->variant == PXA3XX_NAND_VARIANT_ARMADA370 ||
+ info->variant == PXA3XX_NAND_VARIANT_ARMADA_8K)
nand_writel(info, NDCB0, info->ndcb3);
}
@@ -1676,7 +1688,8 @@ static int pxa3xx_nand_scan(struct mtd_info *mtd)
}
/* Device detection must be done with ECC disabled */
- if (info->variant == PXA3XX_NAND_VARIANT_ARMADA370)
+ if (info->variant == PXA3XX_NAND_VARIANT_ARMADA370 ||
+ info->variant == PXA3XX_NAND_VARIANT_ARMADA_8K)
nand_writel(info, NDECCCTRL, 0x0);
if (nand_scan_ident(mtd, 1, NULL))
@@ -1726,7 +1739,8 @@ static int pxa3xx_nand_scan(struct mtd_info *mtd)
* (aka split) command handling,
*/
if (mtd->writesize > info->chunk_size) {
- if (info->variant == PXA3XX_NAND_VARIANT_ARMADA370) {
+ if (info->variant == PXA3XX_NAND_VARIANT_ARMADA370 ||
+ info->variant == PXA3XX_NAND_VARIANT_ARMADA_8K) {
chip->cmdfunc = nand_cmdfunc_extended;
} else {
dev_err(mtd->dev,
@@ -1762,7 +1776,7 @@ static int pxa3xx_nand_scan(struct mtd_info *mtd)
return nand_scan_tail(mtd);
}
-static int alloc_nand_resource(struct pxa3xx_nand_info *info)
+static int alloc_nand_resource(struct udevice *dev, struct pxa3xx_nand_info
*info)
{
struct pxa3xx_nand_platform_data *pdata;
struct pxa3xx_nand_host *host;
@@ -1774,7 +1788,7 @@ static int alloc_nand_resource(struct pxa3xx_nand_info
*info)
if (pdata->num_cs <= 0)
return -ENODEV;
- info->varian
[PATCH v2 1/5] arm: dts: armada-cp110-slave: add missing cps_nand
From: Shmuel Hazan
Align node properties to kernel dts node.
Keep U-Boot specific nand-enable-arbiter, and num-cs for compatibility
with the current driver.
Signed-off-by: Shmuel Hazan
Signed-off-by: Baruch Siach
---
arch/arm/dts/armada-cp110-slave.dtsi | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm/dts/armada-cp110-slave.dtsi
b/arch/arm/dts/armada-cp110-slave.dtsi
index b426a4eb6910..6cf217783709 100644
--- a/arch/arm/dts/armada-cp110-slave.dtsi
+++ b/arch/arm/dts/armada-cp110-slave.dtsi
@@ -267,6 +267,22 @@
utmi-port = ;
status = "disabled";
};
+
+ cps_nand: nand@72 {
+ compatible =
"marvell,armada-8k-nand-controller",
+ "marvell,armada370-nand-controller";
+ reg = <0x72 0x54>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = ;
+ clock-names = "core", "reg";
+ clocks = <_syscon0 1 2>,
+<_syscon0 1 17>;
+ marvell,system-controller = <_syscon0>;
+ nand-enable-arbiter;
+ num-cs = <1>;
+ status = "disabled";
+ };
};
cps_pcie0: pcie@f460 {
--
2.28.0
[PATCH v2 4/5] mtd: pxa3xx_nand: remove dead code
The kfree() call is unreachable, and is not needed. Remove this call and
the fail_disable_clk label.
Signed-off-by: Baruch Siach
---
drivers/mtd/nand/raw/pxa3xx_nand.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/mtd/nand/raw/pxa3xx_nand.c
b/drivers/mtd/nand/raw/pxa3xx_nand.c
index 6f66db065357..635794b1691a 100644
--- a/drivers/mtd/nand/raw/pxa3xx_nand.c
+++ b/drivers/mtd/nand/raw/pxa3xx_nand.c
@@ -1768,7 +1768,7 @@ static int alloc_nand_resource(struct pxa3xx_nand_info
*info)
struct pxa3xx_nand_host *host;
struct nand_chip *chip = NULL;
struct mtd_info *mtd;
- int ret, cs;
+ int cs;
pdata = info->pdata;
if (pdata->num_cs <= 0)
@@ -1804,19 +1804,13 @@ static int alloc_nand_resource(struct pxa3xx_nand_info
*info)
/* Allocate a buffer to allow flash detection */
info->buf_size = INIT_BUFFER_SIZE;
info->data_buff = kmalloc(info->buf_size, GFP_KERNEL);
- if (info->data_buff == NULL) {
- ret = -ENOMEM;
- goto fail_disable_clk;
- }
+ if (info->data_buff == NULL)
+ return -ENOMEM;
/* initialize all interrupts to be disabled */
disable_int(info, NDSR_MASK);
return 0;
-
- kfree(info->data_buff);
-fail_disable_clk:
- return ret;
}
static int pxa3xx_nand_probe_dt(struct udevice *dev, struct pxa3xx_nand_info
*info)
--
2.28.0
[PATCH v2 3/5] mtd: pxa3xx_nand: port to use driver model
From: Shmuel Hazan
Signed-off-by: Shmuel Hazan
Signed-off-by: Baruch Siach
---
drivers/mtd/nand/raw/Kconfig | 2 +
drivers/mtd/nand/raw/pxa3xx_nand.c | 117 +
2 files changed, 55 insertions(+), 64 deletions(-)
diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig
index cd7e598aa8a7..08df12a3daf9 100644
--- a/drivers/mtd/nand/raw/Kconfig
+++ b/drivers/mtd/nand/raw/Kconfig
@@ -195,6 +195,8 @@ endif
config NAND_PXA3XX
bool "Support for NAND on PXA3xx and Armada 370/XP/38x"
select SYS_NAND_SELF_INIT
+ select DM_MTD
+ select SYSCON
imply CMD_NAND
help
This enables the driver for the NAND flash device found on
diff --git a/drivers/mtd/nand/raw/pxa3xx_nand.c
b/drivers/mtd/nand/raw/pxa3xx_nand.c
index 5fb3081c8390..6f66db065357 100644
--- a/drivers/mtd/nand/raw/pxa3xx_nand.c
+++ b/drivers/mtd/nand/raw/pxa3xx_nand.c
@@ -22,6 +22,8 @@
#include
#include
#include
+#include
+#include
#include "pxa3xx_nand.h"
@@ -417,6 +419,14 @@ static struct nand_ecclayout ecc_layout_8KB_bch8bit = {
/* convert nano-seconds to nand flash controller clock cycles */
#define ns2cycle(ns, clk) (int)((ns) * (clk / 100) / 1000)
+static const struct udevice_id pxa3xx_nand_dt_ids[] = {
+ {
+ .compatible = "marvell,mvebu-pxa3xx-nand",
+ .data = PXA3XX_NAND_VARIANT_ARMADA370,
+ },
+ {}
+};
+
static enum pxa3xx_nand_variant pxa3xx_nand_get_variant(void)
{
/* We only support the Armada 370/XP/38x for now */
@@ -1809,82 +1819,60 @@ fail_disable_clk:
return ret;
}
-static int pxa3xx_nand_probe_dt(struct pxa3xx_nand_info *info)
+static int pxa3xx_nand_probe_dt(struct udevice *dev, struct pxa3xx_nand_info
*info)
{
struct pxa3xx_nand_platform_data *pdata;
- const void *blob = gd->fdt_blob;
- int node = -1;
pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
if (!pdata)
return -ENOMEM;
- /* Get address decoding nodes from the FDT blob */
- do {
- node = fdt_node_offset_by_compatible(blob, node,
-
"marvell,mvebu-pxa3xx-nand");
- if (node < 0)
- break;
-
- /* Bypass disabeld nodes */
- if (!fdtdec_get_is_enabled(blob, node))
- continue;
-
- /* Get the first enabled NAND controler base address */
- info->mmio_base =
- (void __iomem *)fdtdec_get_addr_size_auto_noparent(
- blob, node, "reg", 0, NULL, true);
+ info->mmio_base = dev_read_addr_ptr(dev);
- pdata->num_cs = fdtdec_get_int(blob, node, "num-cs", 1);
- if (pdata->num_cs != 1) {
- pr_err("pxa3xx driver supports single CS only\n");
- break;
- }
-
- if (fdtdec_get_bool(blob, node, "nand-enable-arbiter"))
- pdata->enable_arbiter = 1;
+ pdata->num_cs = dev_read_u32_default(dev, "num-cs", 1);
+ if (pdata->num_cs != 1) {
+ pr_err("pxa3xx driver supports single CS only\n");
+ return -EINVAL;
+ }
- if (fdtdec_get_bool(blob, node, "nand-keep-config"))
- pdata->keep_config = 1;
+ if (dev_read_bool(dev, "nand-enable-arbiter"))
+ pdata->enable_arbiter = 1;
- /*
-* ECC parameters.
-* If these are not set, they will be selected according
-* to the detected flash type.
-*/
- /* ECC strength */
- pdata->ecc_strength = fdtdec_get_int(blob, node,
-"nand-ecc-strength", 0);
+ if (dev_read_bool(dev, "nand-keep-config"))
+ pdata->keep_config = 1;
- /* ECC step size */
- pdata->ecc_step_size = fdtdec_get_int(blob, node,
- "nand-ecc-step-size", 0);
-
- info->pdata = pdata;
+ /*
+* ECC parameters.
+* If these are not set, they will be selected according
+* to the detected flash type.
+*/
+ /* ECC strength */
+ pdata->ecc_strength = dev_read_u32_default(dev, "nand-ecc-strength", 0);
- /* Currently support only a single NAND controller */
- return 0;
+ /* ECC step size */
+ pdata->ecc_step_size = dev_read_u32_default(dev, "nand-ecc-step-size",
+ 0);
- } while (node >= 0
[PATCH v2 2/5] arm: dts: armada-cp110-master: update nand-controller
Align node properties to kernel dts node.
The change of compatible property does not affect any currently
supported board.
Keep U-Boot specific nand-enable-arbiter, and num-cs for compatibility
with the current driver.
Signed-off-by: Baruch Siach
---
arch/arm/dts/armada-cp110-master.dtsi | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/arch/arm/dts/armada-cp110-master.dtsi
b/arch/arm/dts/armada-cp110-master.dtsi
index cd5c974482e6..7d0d31da306d 100644
--- a/arch/arm/dts/armada-cp110-master.dtsi
+++ b/arch/arm/dts/armada-cp110-master.dtsi
@@ -285,15 +285,18 @@
};
cpm_nand: nand@72 {
- compatible = "marvell,mvebu-pxa3xx-nand";
- reg = <0x72 0x100>;
+ compatible =
"marvell,armada-8k-nand-controller",
+ "marvell,armada370-nand-controller";
+ reg = <0x72 0x54>;
#address-cells = <1>;
-
- clocks = <_syscon0 1 2>;
+ #size-cells = <0>;
+ interrupts = ;
+ clock-names = "core", "reg";
+ clocks = <_syscon0 1 2>,
+<_syscon0 1 17>;
+ marvell,system-controller = <_syscon0>;
nand-enable-arbiter;
num-cs = <1>;
- nand-ecc-strength = <4>;
- nand-ecc-step-size = <512>;
status = "disabled";
};
--
2.28.0
Re: [BUG] mx6cuboxi : broken MMC support
Hi Fabio,
On Sat, Oct 10 2020, Fabio Estevam wrote:
> On Sat, Oct 10, 2020 at 4:11 PM Baruch Siach wrote:
>
>> This might be the cause of the problem. The script listed above
>> hardcodes "mmc 0:1". Changing that to "mmc 1:1" might fix this issue.
>
> Wouldn't this break the HummingBoard variants? Or is this safe for all
> Cubox-i and HummingBoard?
The SD card is attached to the same MMC peripheral on both Cubox-i and
Hummingboard variants (usdhc2). As I understand, the move to DT probe
changed mmc devices enumeration for all variants that U-Boot mx6cuboxi
board code supports.
baruch
--
~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
Re: [BUG] mx6cuboxi : broken MMC support
Hi François
On Sat, Oct 10 2020, François Perrad wrote:
> With 2020.07 (or 2020.04 or 2020.10), something goes wrong on this board.
> I think it is related to
> https://gitlab.denx.de/u-boot/u-boot/-/commit/6c3fbf3e456c49c2f43c0c286106a0d4b099b67b
>
> 2020.01 works fine with mmc0 (mmc0 is current device)
> 2020.07 fails with mmc1
> both versions are built in the Builroot environment,
> and I use a Micro SD with the Cubox.
>
> Here, the working version 2020.01
>
> U-Boot SPL 2020.01 (Oct 09 2020 - 22:28:05 +0200)
> Trying to boot from MMC1
>
>
> U-Boot 2020.01 (Oct 09 2020 - 22:28:05 +0200)
>
> CPU: Freescale i.MX6SOLO rev1.3 996 MHz (running at 792 MHz)
> CPU: Commercial temperature grade (0C to 95C) at 30C
> Reset cause: POR
> Board: MX6 Cubox-i
> DRAM: 512 MiB
> MMC: FSL_SDHC: 0, FSL_SDHC: 1
> Loading Environment from MMC... *** Warning - bad CRC, using default
> environment
>
> No panel detected: default to HDMI
> Display: HDMI (1024x768)
> In:serial
> Out: serial
> Err: serial
> Net: FEC
> Hit any key to stop autoboot: 0
> switch to partitions #0, OK
> mmc0 is current device
> Scanning mmc 0:1...
> Found U-Boot script /boot/boot.scr
> 336 bytes read in 106 ms (2.9 KiB/s)
> ## Executing script at 1200
> 36612 bytes read in 121 ms (294.9 KiB/s)
> 8552176 bytes read in 652 ms (12.5 MiB/s)
> ## Flattened Device Tree blob at 1800
>Booting using the fdt blob at 0x1800
>Using Device Tree in place at 1800, end 1800bf03
>
> Starting kernel ...
The 'boot.scr' script here is board/solidrun/mx6cubox/boot.scr.txt from
the Buildroot repo:
setenv finduuid "part uuid mmc 0:1 uuid"
run finduuid
run findfdt
setenv bootargs "console=ttymxc0,115200 root=PARTUUID=${uuid} rootwait
rootfstype=ext4"
load mmc 0:1 ${fdt_addr} boot/${fdtfile}
load mmc 0:1 ${loadaddr} boot/zImage
bootz ${loadaddr} - ${fdt_addr}
Is that correct?
> Now, with the version 2020.07
>
> U-Boot SPL 2020.07 (Oct 06 2020 - 13:33:44 +0200)
> WDT: Not found!
> Trying to boot from MMC1
>
>
> U-Boot 2020.07 (Oct 06 2020 - 13:33:44 +0200)
>
> CPU: Freescale i.MX6SOLO rev1.3 996 MHz (running at 792 MHz)
> CPU: Commercial temperature grade (0C to 95C) at 36C
> Reset cause: POR
> Board: MX6 Cubox-i
> DRAM: 512 MiB
> MMC: FSL_SDHC: 1, FSL_SDHC: 2
> Loading Environment from MMC... *** Warning - bad CRC, using default
> environment
>
> No panel detected: default to HDMI
> Display: HDMI (1024x768)
> In:serial
> Out: serial
> Err: serial
> Net:
> Warning: ethernet@2188000 using MAC address from ROM
> eth0: ethernet@2188000
> Hit any key to stop autoboot: 0
> switch to partitions #0, OK
> mmc1 is current device
> Scanning mmc 1:1...
This might be the cause of the problem. The script listed above
hardcodes "mmc 0:1". Changing that to "mmc 1:1" might fix this issue.
baruch
> Found U-Boot script /boot/boot.scr
> 336 bytes read in 12 ms (27.3 KiB/s)
> ## Executing script at 1200
> SCRIPT FAILED: continuing...
> switch to partitions #0, OK
> mmc2(part 0) is current device
> ** No partition table - mmc 2 **
> No SATA device found!
> starting USB...
--
~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
[PATCH] i2c: mvtwsi: disable i2c slave also on Armada 8k
The hidden I2C slave is also present on the Armada 8k AP806. Testing shows that this I2C slave causes the same issues as Armada 38x. Disabling that I2C slave fixes all these issues. I2C blocks on the Armada 8k CP110 are not affected. Extend the I2C slave disable to Armada 8k as well. Cc: Stefan Roese Signed-off-by: Baruch Siach --- drivers/i2c/mvtwsi.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/i2c/mvtwsi.c b/drivers/i2c/mvtwsi.c index fdb8fd42e5c0..14c594d648ba 100644 --- a/drivers/i2c/mvtwsi.c +++ b/drivers/i2c/mvtwsi.c @@ -823,7 +823,8 @@ static int mvtwsi_i2c_bind(struct udevice *bus) struct mvtwsi_registers *twsi = dev_read_addr_ptr(bus); /* Disable the hidden slave in i2c0 of these platforms */ - if ((IS_ENABLED(CONFIG_ARMADA_38X) || IS_ENABLED(CONFIG_ARCH_KIRKWOOD)) + if ((IS_ENABLED(CONFIG_ARMADA_38X) || IS_ENABLED(CONFIG_ARCH_KIRKWOOD) + || IS_ENABLED(CONFIG_ARMADA_8K)) && bus->req_seq == 0) twsi_disable_i2c_slave(twsi); -- 2.28.0
[PATCH 5/5] mtd: nand: pxa3xx: enable NAND controller if the SoC needs it
From: Shmuel Hazan
Based on Linux kernel commit fc256f5789cb ("mtd: nand: pxa3xx: enable
NAND controller if the SoC needs it"). This commit adds support for the
Armada 8040 nand controller.
The kernel commit says this:
Marvell recent SoCs like A7k/A8k do not boot with NAND flash
controller activated by default. Enabling the controller is a matter
of writing in a system controller register that may also be used for
other NAND related choices.
Signed-off-by: Shmuel Hazan
Signed-off-by: Baruch Siach
---
drivers/mtd/nand/raw/pxa3xx_nand.c | 50 --
1 file changed, 41 insertions(+), 9 deletions(-)
diff --git a/drivers/mtd/nand/raw/pxa3xx_nand.c
b/drivers/mtd/nand/raw/pxa3xx_nand.c
index 54ba65fa8202..7506c5bb2884 100644
--- a/drivers/mtd/nand/raw/pxa3xx_nand.c
+++ b/drivers/mtd/nand/raw/pxa3xx_nand.c
@@ -22,6 +22,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -119,6 +121,10 @@ DECLARE_GLOBAL_DATA_PTR;
#define EXT_CMD_TYPE_LAST_RW 1 /* Last naked read/write */
#define EXT_CMD_TYPE_MONO 0 /* Monolithic read/write */
+/* System control register and bit to enable NAND on some SoCs */
+#define GENCONF_SOC_DEVICE_MUX 0x208
+#define GENCONF_SOC_DEVICE_MUX_NFC_EN BIT(0)
+
/*
* This should be large enough to read 'ONFI' and 'JEDEC'.
* Let's use 7 bytes, which is the maximum ID count supported
@@ -159,6 +165,7 @@ enum {
enum pxa3xx_nand_variant {
PXA3XX_NAND_VARIANT_PXA,
PXA3XX_NAND_VARIANT_ARMADA370,
+ PXA3XX_NAND_VARIANT_ARMADA_8K,
};
struct pxa3xx_nand_host {
@@ -424,13 +431,16 @@ static const struct udevice_id pxa3xx_nand_dt_ids[] = {
.compatible = "marvell,mvebu-pxa3xx-nand",
.data = PXA3XX_NAND_VARIANT_ARMADA370,
},
+ {
+ .compatible = "marvell,armada-8k-nand-controller",
+ .data = PXA3XX_NAND_VARIANT_ARMADA_8K,
+ },
{}
};
-static enum pxa3xx_nand_variant pxa3xx_nand_get_variant(void)
+static enum pxa3xx_nand_variant pxa3xx_nand_get_variant(struct udevice *dev)
{
- /* We only support the Armada 370/XP/38x for now */
- return PXA3XX_NAND_VARIANT_ARMADA370;
+ return dev_get_driver_data(dev);
}
static void pxa3xx_nand_set_timing(struct pxa3xx_nand_host *host,
@@ -707,7 +717,8 @@ static irqreturn_t pxa3xx_nand_irq(struct pxa3xx_nand_info
*info)
info->retcode = ERR_UNCORERR;
if (status & NDSR_CORERR) {
info->retcode = ERR_CORERR;
- if (info->variant == PXA3XX_NAND_VARIANT_ARMADA370 &&
+ if ((info->variant == PXA3XX_NAND_VARIANT_ARMADA370 ||
+info->variant == PXA3XX_NAND_VARIANT_ARMADA_8K) &&
info->ecc_bch)
info->ecc_err_cnt = NDSR_ERR_CNT(status);
else
@@ -762,7 +773,8 @@ static irqreturn_t pxa3xx_nand_irq(struct pxa3xx_nand_info
*info)
nand_writel(info, NDCB0, info->ndcb2);
/* NDCB3 register is available in NFCv2 (Armada 370/XP SoC) */
- if (info->variant == PXA3XX_NAND_VARIANT_ARMADA370)
+ if (info->variant == PXA3XX_NAND_VARIANT_ARMADA370 ||
+ info->variant == PXA3XX_NAND_VARIANT_ARMADA_8K)
nand_writel(info, NDCB0, info->ndcb3);
}
@@ -1677,7 +1689,8 @@ static int pxa3xx_nand_scan(struct mtd_info *mtd)
}
/* Device detection must be done with ECC disabled */
- if (info->variant == PXA3XX_NAND_VARIANT_ARMADA370)
+ if (info->variant == PXA3XX_NAND_VARIANT_ARMADA370 ||
+ info->variant == PXA3XX_NAND_VARIANT_ARMADA_8K)
nand_writel(info, NDECCCTRL, 0x0);
if (nand_scan_ident(mtd, 1, NULL))
@@ -1727,7 +1740,8 @@ static int pxa3xx_nand_scan(struct mtd_info *mtd)
* (aka split) command handling,
*/
if (mtd->writesize > info->chunk_size) {
- if (info->variant == PXA3XX_NAND_VARIANT_ARMADA370) {
+ if (info->variant == PXA3XX_NAND_VARIANT_ARMADA370 ||
+ info->variant == PXA3XX_NAND_VARIANT_ARMADA_8K) {
chip->cmdfunc = nand_cmdfunc_extended;
} else {
dev_err(>pdev->dev,
@@ -1763,7 +1777,7 @@ static int pxa3xx_nand_scan(struct mtd_info *mtd)
return nand_scan_tail(mtd);
}
-static int alloc_nand_resource(struct pxa3xx_nand_info *info)
+static int alloc_nand_resource(struct udevice *dev, struct pxa3xx_nand_info
*info)
{
struct pxa3xx_nand_platform_data *pdata;
struct pxa3xx_nand_host *host;
@@ -1775,7 +1789,7 @@ static int alloc_nand_resource(struct pxa3xx_nand_info
*info)
if (pdata->num_cs <= 0)
return -ENODEV;
- info->var
[PATCH 3/5] mtd: pxa3xx_nand: port to use driver model
From: Shmuel Hazan
Signed-off-by: Shmuel Hazan
Signed-off-by: Baruch Siach
---
drivers/mtd/nand/raw/Kconfig | 2 +
drivers/mtd/nand/raw/pxa3xx_nand.c | 114 +
2 files changed, 54 insertions(+), 62 deletions(-)
diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig
index 06b2ff972cad..bcfaa09ac720 100644
--- a/drivers/mtd/nand/raw/Kconfig
+++ b/drivers/mtd/nand/raw/Kconfig
@@ -195,6 +195,8 @@ endif
config NAND_PXA3XX
bool "Support for NAND on PXA3xx and Armada 370/XP/38x"
select SYS_NAND_SELF_INIT
+ select DM_MTD
+ select SYSCON
imply CMD_NAND
help
This enables the driver for the NAND flash device found on
diff --git a/drivers/mtd/nand/raw/pxa3xx_nand.c
b/drivers/mtd/nand/raw/pxa3xx_nand.c
index a30e82166b96..d455201b91a3 100644
--- a/drivers/mtd/nand/raw/pxa3xx_nand.c
+++ b/drivers/mtd/nand/raw/pxa3xx_nand.c
@@ -22,6 +22,8 @@
#include
#include
#include
+#include
+#include
#include "pxa3xx_nand.h"
@@ -417,6 +419,14 @@ static struct nand_ecclayout ecc_layout_8KB_bch8bit = {
/* convert nano-seconds to nand flash controller clock cycles */
#define ns2cycle(ns, clk) (int)((ns) * (clk / 100) / 1000)
+static const struct udevice_id pxa3xx_nand_dt_ids[] = {
+ {
+ .compatible = "marvell,mvebu-pxa3xx-nand",
+ .data = PXA3XX_NAND_VARIANT_ARMADA370,
+ },
+ {}
+};
+
static enum pxa3xx_nand_variant pxa3xx_nand_get_variant(void)
{
/* We only support the Armada 370/XP/38x for now */
@@ -1810,79 +1820,58 @@ fail_disable_clk:
return ret;
}
-static int pxa3xx_nand_probe_dt(struct pxa3xx_nand_info *info)
+static int pxa3xx_nand_probe_dt(struct udevice *dev, struct pxa3xx_nand_info
*info)
{
struct pxa3xx_nand_platform_data *pdata;
- const void *blob = gd->fdt_blob;
- int node = -1;
pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
if (!pdata)
return -ENOMEM;
- /* Get address decoding nodes from the FDT blob */
- do {
- node = fdt_node_offset_by_compatible(blob, node,
-
"marvell,mvebu-pxa3xx-nand");
- if (node < 0)
- break;
-
- /* Bypass disabeld nodes */
- if (!fdtdec_get_is_enabled(blob, node))
- continue;
-
- /* Get the first enabled NAND controler base address */
- info->mmio_base =
- (void __iomem *)fdtdec_get_addr_size_auto_noparent(
- blob, node, "reg", 0, NULL, true);
+ info->mmio_base = dev_read_addr_ptr(dev);
- pdata->num_cs = fdtdec_get_int(blob, node, "num-cs", 1);
- if (pdata->num_cs != 1) {
- pr_err("pxa3xx driver supports single CS only\n");
- break;
- }
-
- if (fdtdec_get_bool(blob, node, "nand-enable-arbiter"))
- pdata->enable_arbiter = 1;
+ pdata->num_cs = dev_read_u32_default(dev, "num-cs", 1);
+ if (pdata->num_cs != 1) {
+ pr_err("pxa3xx driver supports single CS only\n");
+ return -EINVAL;
+ }
- if (fdtdec_get_bool(blob, node, "nand-keep-config"))
- pdata->keep_config = 1;
+ if (dev_read_bool(dev, "nand-enable-arbiter"))
+ pdata->enable_arbiter = 1;
- /*
-* ECC parameters.
-* If these are not set, they will be selected according
-* to the detected flash type.
-*/
- /* ECC strength */
- pdata->ecc_strength = fdtdec_get_int(blob, node,
-"nand-ecc-strength", 0);
+ if (dev_read_bool(dev, "nand-keep-config"))
+ pdata->keep_config = 1;
- /* ECC step size */
- pdata->ecc_step_size = fdtdec_get_int(blob, node,
- "nand-ecc-step-size", 0);
-
- info->pdata = pdata;
+ /*
+* ECC parameters.
+* If these are not set, they will be selected according
+* to the detected flash type.
+*/
+ /* ECC strength */
+ pdata->ecc_strength = dev_read_u32_default(dev, "nand-ecc-strength", 0);
- /* Currently support only a single NAND controller */
- return 0;
+ /* ECC step size */
+ pdata->ecc_step_size = dev_read_u32_default(dev, "nand-ecc-step-size",
+ 0);
- } while (node >= 0);
+ i
[PATCH 4/5] mtd: pxa3xx_nand: remove dead code
The kfree() call is unreachable, and is not needed. Remove this call and
the fail_disable_clk label.
Signed-off-by: Baruch Siach
---
drivers/mtd/nand/raw/pxa3xx_nand.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/mtd/nand/raw/pxa3xx_nand.c
b/drivers/mtd/nand/raw/pxa3xx_nand.c
index d455201b91a3..54ba65fa8202 100644
--- a/drivers/mtd/nand/raw/pxa3xx_nand.c
+++ b/drivers/mtd/nand/raw/pxa3xx_nand.c
@@ -1769,7 +1769,7 @@ static int alloc_nand_resource(struct pxa3xx_nand_info
*info)
struct pxa3xx_nand_host *host;
struct nand_chip *chip = NULL;
struct mtd_info *mtd;
- int ret, cs;
+ int cs;
pdata = info->pdata;
if (pdata->num_cs <= 0)
@@ -1805,19 +1805,13 @@ static int alloc_nand_resource(struct pxa3xx_nand_info
*info)
/* Allocate a buffer to allow flash detection */
info->buf_size = INIT_BUFFER_SIZE;
info->data_buff = kmalloc(info->buf_size, GFP_KERNEL);
- if (info->data_buff == NULL) {
- ret = -ENOMEM;
- goto fail_disable_clk;
- }
+ if (info->data_buff == NULL)
+ return -ENOMEM;
/* initialize all interrupts to be disabled */
disable_int(info, NDSR_MASK);
return 0;
-
- kfree(info->data_buff);
-fail_disable_clk:
- return ret;
}
static int pxa3xx_nand_probe_dt(struct udevice *dev, struct pxa3xx_nand_info
*info)
--
2.28.0
[PATCH 1/5] arm: dts: armada-cp110-slave: add missing cps_nand
From: Shmuel Hazan
Align node properties to kernel dts node.
Keep U-Boot specific nand-enable-arbiter, and num-cs for compatibility
with the current driver.
Signed-off-by: Shmuel Hazan
Signed-off-by: Baruch Siach
---
arch/arm/dts/armada-cp110-slave.dtsi | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm/dts/armada-cp110-slave.dtsi
b/arch/arm/dts/armada-cp110-slave.dtsi
index b426a4eb6910..6cf217783709 100644
--- a/arch/arm/dts/armada-cp110-slave.dtsi
+++ b/arch/arm/dts/armada-cp110-slave.dtsi
@@ -267,6 +267,22 @@
utmi-port = ;
status = "disabled";
};
+
+ cps_nand: nand@72 {
+ compatible =
"marvell,armada-8k-nand-controller",
+ "marvell,armada370-nand-controller";
+ reg = <0x72 0x54>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = ;
+ clock-names = "core", "reg";
+ clocks = <_syscon0 1 2>,
+<_syscon0 1 17>;
+ marvell,system-controller = <_syscon0>;
+ nand-enable-arbiter;
+ num-cs = <1>;
+ status = "disabled";
+ };
};
cps_pcie0: pcie@f460 {
--
2.28.0
[PATCH 0/5] mtd: pxa3xx_nand: add support for Armada 8k
This series adds NAND flash support to Aramda 8k systems. Patches make the necessary changes to the pxa3xx_nand driver and DT files. Baruch Siach (2): arm: dts: armada-cp110-master: update nand-controller mtd: pxa3xx_nand: remove dead code Shmuel Hazan (3): arm: dts: armada-cp110-slave: add missing cps_nand mtd: pxa3xx_nand: port to use driver model mtd: nand: pxa3xx: enable NAND controller if the SoC needs it arch/arm/dts/armada-cp110-master.dtsi | 15 ++- arch/arm/dts/armada-cp110-slave.dtsi | 16 +++ drivers/mtd/nand/raw/Kconfig | 2 + drivers/mtd/nand/raw/pxa3xx_nand.c| 176 ++ 4 files changed, 123 insertions(+), 86 deletions(-) -- 2.28.0
[PATCH 2/5] arm: dts: armada-cp110-master: update nand-controller
Align node properties to kernel dts node.
The change of compatible property does not affect any currently
supported board.
Keep U-Boot specific nand-enable-arbiter, and num-cs for compatibility
with the current driver.
Signed-off-by: Baruch Siach
---
arch/arm/dts/armada-cp110-master.dtsi | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/arch/arm/dts/armada-cp110-master.dtsi
b/arch/arm/dts/armada-cp110-master.dtsi
index cd5c974482e6..7d0d31da306d 100644
--- a/arch/arm/dts/armada-cp110-master.dtsi
+++ b/arch/arm/dts/armada-cp110-master.dtsi
@@ -285,15 +285,18 @@
};
cpm_nand: nand@72 {
- compatible = "marvell,mvebu-pxa3xx-nand";
- reg = <0x72 0x100>;
+ compatible =
"marvell,armada-8k-nand-controller",
+ "marvell,armada370-nand-controller";
+ reg = <0x72 0x54>;
#address-cells = <1>;
-
- clocks = <_syscon0 1 2>;
+ #size-cells = <0>;
+ interrupts = ;
+ clock-names = "core", "reg";
+ clocks = <_syscon0 1 2>,
+<_syscon0 1 17>;
+ marvell,system-controller = <_syscon0>;
nand-enable-arbiter;
num-cs = <1>;
- nand-ecc-strength = <4>;
- nand-ecc-step-size = <512>;
status = "disabled";
};
--
2.28.0
[PATCH] ARM: mvebu: clearfog: don't override set fdtfile env
Only set the fdtfile environment variable when not already set.
Fixes: 867572f09ebe6 ("ARM: mvebu: clearfog: run-time selection of DT file")
Cc: Joel Johnson
Reported-by: Andre Heider
Signed-off-by: Baruch Siach
---
board/solidrun/clearfog/clearfog.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/board/solidrun/clearfog/clearfog.c
b/board/solidrun/clearfog/clearfog.c
index d5535ebebecd..92443d5177d9 100644
--- a/board/solidrun/clearfog/clearfog.c
+++ b/board/solidrun/clearfog/clearfog.c
@@ -240,6 +240,9 @@ int board_eth_init(struct bd_info *bis)
int board_late_init(void)
{
+ if (env_get("fdtfile"))
+ return 0;
+
cf_read_tlv_data();
if (sr_product_is(_tlv_data, "Clearfog Base"))
--
2.28.0
[PATCH] MAINTAINERS: update clk entry git tree
Signed-off-by: Baruch Siach --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index e35d5d4fcbf8..739bb1468350 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -609,7 +609,7 @@ F: drivers/mtd/jedec_flash.c CLOCK M: Lukasz Majewski S: Maintained -T: git git://git.denx.de/u-boot-dfu.git +T: git https://gitlab.denx.de/u-boot/custodians/u-boot-clk.git F: drivers/clk/ F: drivers/clk/imx/ -- 2.28.0
[PATCH] image: don't exceed gd->ram_top in bootm_size
When board_get_usable_ram_top() limits gd->ram_top, env_get_bootm_size()
must not exceed that limit. Otherwise, boot_relocate_fdt() might put fdt
out of the allowed RAM range.
The similar commit 8ce1f10cf2b1 ("ARM: bootm: take into account
gd->ram_top") exposed this bug.
This fixes boot on Armada 8040 based Clearfog GT-8K where ram_top is set
to 0x8000 (2GB), but bi_dram[0].size might be up to 0xc000
(3GB). Note the relocated fdt address (0xbfff4000) in the console output
listed below:
Found /extlinux/extlinux.conf
Retrieving file: /extlinux/extlinux.conf
62 bytes read in 21 ms (2 KiB/s)
1: linux
Retrieving file: /extlinux/Image
13740544 bytes read in 1266 ms (10.4 MiB/s)
Retrieving file: /extlinux/armada-8040-clearfog-gt-8k.dtb
33368 bytes read in 31 ms (1 MiB/s)
Booting using the fdt blob at 0x4f0
Loading Device Tree to bfff4000, end b257 ...
"Synchronous Abort" handler, esr 0x9645
elr: 0006e1cc lr : 00068fd8 (reloc)
elr: 7ffa91cc lr : 7ffa3fd8
x0 : x1 : bfffc258
x2 : x3 : 7da7
x4 : 04f08258 x5 : bfff4000
x6 : bfff4000 x7 : 000f
x8 : 7fb23bf8 x9 : 0008
x10: b257 x11: b257
x12: x13: f000
x14: bfff4000 x15: 0021
x16: 7ff7bc38 x17:
x18: 7fb2add0 x19: bfff4000
x20: 04f0 x21: b258
x22: 5882 x23: 0010
x24: 7ffe3c40 x25: 7fb23cb8
x26: c000 x27:
x28: 7fc3fd50 x29: 7fb23bd0
Code: 5461 aa0603e0 d65f03c0 38606882 (38206822)
Resetting CPU ...
Thanks to Patrice CHOTARD who directed me to the right way.
Signed-off-by: Baruch Siach
---
common/image.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/common/image.c b/common/image.c
index 9d7d5c17d122..da8bccd400dd 100644
--- a/common/image.c
+++ b/common/image.c
@@ -694,6 +694,9 @@ phys_size_t env_get_bootm_size(void)
size = gd->bd->bi_memsize;
#endif
+ if (start + size > gd->ram_top)
+ size = gd->ram_top - start;
+
s = env_get("bootm_low");
if (s)
tmp = (phys_size_t)simple_strtoull(s, NULL, 16);
--
2.28.0
Re: [PATCH] ARM: bootm: take into account gd->ram_top
Hi Patrick, all,
On Thu, Feb 13 2020, Patrick Delaunay wrote:
> From: Patrice Chotard
>
> If gd->ram_top has been tuned using board_get_usable_ram_top(),
> it must be taken into account when reserving arch lmb.
>
> Signed-off-by: Patrice Chotard
> Reviewed-by: Patrick DELAUNAY
> Signed-off-by: Patrick Delaunay
[snip]
> diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
> index a135bcfc7b..f4b5ca6de0 100644
> --- a/arch/arm/lib/bootm.c
> +++ b/arch/arm/lib/bootm.c
> @@ -75,6 +75,9 @@ void arch_lmb_reserve(struct lmb *lmb)
> gd->bd->bi_dram[bank].size - 1;
> if (sp > bank_end)
> continue;
> + if (bank_end > gd->ram_top)
> + bank_end = gd->ram_top - 1;
> +
This patch (now committed as 8ce1f10cf2b1) breaks kernel boot on Armada
8040 based Clearfog GT-8K with 16GB RAM. See below the console output of
v2020.10-rc2 with a few added prints.
The first memory bank (bi_dram[0]) goes from 0 to 3GB. The rest
(4GB-17GB) is on bi_dram[1] (see a8k_dram_init_banksize()). ram_top is
set to 2GB on
arch/arm/mach-mvebu/arm64-common.c:board_get_usable_ram_top().
Reverting commit 8ce1f10cf2b1 on top of v2020.10-rc2 fixes boot.
Any Idea?
Found /extlinux/extlinux.conf
Retrieving file: /extlinux/extlinux.conf
## Current stack ends at 0x7fb24300
arch_lmb_reserve: bank_end: bfff ram_top: 8000
62 bytes read in 21 ms (2 KiB/s)
1: linux
Retrieving file: /extlinux/Image
## Current stack ends at 0x7fb23960
arch_lmb_reserve: bank_end: bfff ram_top: 8000
13740544 bytes read in 1266 ms (10.4 MiB/s)
Retrieving file: /extlinux/armada-8040-clearfog-gt-8k.dtb
## Current stack ends at 0x7fb23960
arch_lmb_reserve: bank_end: bfff ram_top: 8000
33368 bytes read in 31 ms (1 MiB/s)
## Current stack ends at 0x7fb23cd0
arch_lmb_reserve: bank_end: bfff ram_top: 8000
## Flattened Device Tree blob at 04f0
Booting using the fdt blob at 0x4f0
Loading Device Tree to bfff4000, end b257 ...
"Synchronous Abort" handler, esr 0x9645
elr: 0006e1cc lr : 00068fd8 (reloc)
elr: 7ffa91cc lr : 7ffa3fd8
x0 : x1 : bfffc258
x2 : x3 : 7da7
x4 : 04f08258 x5 : bfff4000
x6 : bfff4000 x7 : 000f
x8 : 7fb23bf8 x9 : 0008
x10: b257 x11: b257
x12: x13: f000
x14: bfff4000 x15: 0021
x16: 7ff7bc38 x17:
x18: 7fb2add0 x19: bfff4000
x20: 04f0 x21: b258
x22: 5882 x23: 0010
x24: 7ffe3c40 x25: 7fb23cb8
x26: c000 x27:
x28: 7fc3fd50 x29: 7fb23bd0
Code: 5461 aa0603e0 d65f03c0 38606882 (38206822)
Resetting CPU ...
Thanks,
baruch
> lmb_reserve(lmb, sp, bank_end - sp + 1);
> break;
> }
--
~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
[PATCH] cmd: bootz: fix device-tree overlap test
The address of the kernel image is stored in images->ep. zi_start is the
offset of execution entry in the image, which is usually 0 for ARM
zImage.
Fixes boot error when ftd is stored near RAM address 0x0:
ERROR: FDT image overlaps OS image (OS=0x0..0x5fd608)
Fixes: fbde7589ce30 ("common: bootm: add checks to verify if ramdisk / fdtimage
overlaps OS image")
Cc: Tero Kristo
Signed-off-by: Baruch Siach
---
cmd/bootz.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/cmd/bootz.c b/cmd/bootz.c
index 1c8b0cf89f92..7556cd2752a8 100644
--- a/cmd/bootz.c
+++ b/cmd/bootz.c
@@ -54,7 +54,7 @@ static int bootz_start(struct cmd_tbl *cmdtp, int flag, int
argc,
* Handle the BOOTM_STATE_FINDOTHER state ourselves as we do not
* have a header that provide this informaiton.
*/
- if (bootm_find_images(flag, argc, argv, zi_start, zi_end - zi_start))
+ if (bootm_find_images(flag, argc, argv, images->ep, zi_end - zi_start))
return 1;
return 0;
--
2.27.0
Re: [PATCH v5 1/3] gpio-uclass.c: save the GPIOD flags also in the gpio descriptor
Hi Heiko,
On Fri, May 15 2020, Heiko Schocher wrote:
> save the GPIOD_ flags also in the gpio descriptor.
>
> Signed-off-by: Heiko Schocher
> Reviewed-by: Patrick Delaunay
> Reviewed-by: Simon Glass
This fixes SD card access on Hummingboard2. Current master uses the
wrong out polarity to control the SD card power regulator.
Tested-by: Baruch Siach
Should go to v2020.07 I believe.
One more comment below.
> @@ -614,10 +618,6 @@ int dm_gpio_set_dir_flags(struct gpio_desc *desc, ulong
> flags)
> flags |= desc->flags;
> ret = _dm_gpio_set_dir_flags(desc, flags);
>
> - /* update the descriptor flags */
> - if (ret)
> - desc->flags = flags;
> -
> return ret;
You can just do
return _dm_gpio_set_dir_flags(desc, flags);
here instead.
Thanks,
baruch
--
~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
Re: [PATCH 4/4] mx6cuboxi: Convert to DM_ETH
Hi Fabio,
Thanks for your debug and fix. Small nits below.
On Thu, Jun 18 2020, Fabio Estevam wrote:
> Migration to DM_ETH is mandatory, so convert mx6cuboxi to Ethernet
> Driver Model.
>
> This also brings the benefit of restoring Ethernet functionality.
>
> Reported-by: Tom Rini
> Signed-off-by: Fabio Estevam
> ---
> board/solidrun/mx6cuboxi/mx6cuboxi.c | 123 ---
> configs/mx6cuboxi_defconfig | 4 +
> include/configs/mx6cuboxi.h | 6 --
> 3 files changed, 21 insertions(+), 112 deletions(-)
>
> diff --git a/board/solidrun/mx6cuboxi/mx6cuboxi.c
> b/board/solidrun/mx6cuboxi/mx6cuboxi.c
> index 94707bccb2..225fea2cb2 100644
> --- a/board/solidrun/mx6cuboxi/mx6cuboxi.c
> +++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c
> @@ -17,7 +17,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> #include
> @@ -34,7 +33,6 @@
> #include
> #include
> #include
Do we still need this header?
> -#include
> #include
> #include
> #include
> @@ -237,110 +235,6 @@ int board_mmc_init(bd_t *bis)
> return 0;
> }
>
> -static iomux_v3_cfg_t const enet_pads[] = {
> - IOMUX_PADS(PAD_ENET_MDIO__ENET_MDIO | MUX_PAD_CTRL(ENET_PAD_CTRL)),
The definitions of these ENET_PAD_CTRL* macros can go away as well.
baruch
> - IOMUX_PADS(PAD_ENET_MDC__ENET_MDC | MUX_PAD_CTRL(ENET_PAD_CTRL)),
> - /* AR8035 reset */
> - IOMUX_PADS(PAD_KEY_ROW4__GPIO4_IO15 | MUX_PAD_CTRL(ENET_PAD_CTRL_PD)),
> - /* AR8035 interrupt */
> - IOMUX_PADS(PAD_DI0_PIN2__GPIO4_IO18 | MUX_PAD_CTRL(NO_PAD_CTRL)),
...
--
~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
Re: [PATCH 2/2] mv_ddr: ddr3: Update {min, max}_read_sample calculation
Hi Chris,
On Wed, May 27 2020, Chris Packham wrote:
> From: Chris Packham
>
> Measurements on actual hardware shown that the read ODT is early by 3
> clocks. Adjust the calculation to avoid this.
>
> Signed-off-by: Chris Packham
>
> [upstream https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell/pull/22]
> Signed-off-by: Chris Packham
Tested here on an Armada 385 based system. Running memtester for more
than an hour.
Tested-by: Baruch Siach
Thanks,
baruch
> ---
>
> drivers/ddr/marvell/a38x/ddr3_training_hw_algo.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/ddr/marvell/a38x/ddr3_training_hw_algo.c
> b/drivers/ddr/marvell/a38x/ddr3_training_hw_algo.c
> index ce9a47fc2ce0..58ffb205072e 100644
> --- a/drivers/ddr/marvell/a38x/ddr3_training_hw_algo.c
> +++ b/drivers/ddr/marvell/a38x/ddr3_training_hw_algo.c
> @@ -91,8 +91,8 @@ int ddr3_tip_write_additional_odt_setting(u32 dev_num, u32
> if_id)
> min_read_sample = read_sample[cs_num];
> }
>
> - min_read_sample = min_read_sample - 1;
> - max_read_sample = max_read_sample + 4 + (max_phase + 1) / 2 + 1;
> + min_read_sample = min_read_sample + 2;
> + max_read_sample = max_read_sample + 7 + (max_phase + 1) / 2 + 1;
> if (min_read_sample >= 0xf)
> min_read_sample = 0xf;
> if (max_read_sample >= 0x1f)
--
~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
[PATCH] net: move random_port() to dns
The random_port() routine is not used anywhere else. Make it local to
dns.c to reduce code clutter, and shrink generated code a little.
Signed-off-by: Baruch Siach
---
include/net.h | 3 ---
net/dns.c | 10 ++
net/net.c | 14 --
3 files changed, 10 insertions(+), 17 deletions(-)
diff --git a/include/net.h b/include/net.h
index 82500eeb30f7..a5030b395fb6 100644
--- a/include/net.h
+++ b/include/net.h
@@ -890,9 +890,6 @@ int is_serverip_in_cmd(void);
*/
int net_parse_bootfile(struct in_addr *ipaddr, char *filename, int max_len);
-/* get a random source port */
-unsigned int random_port(void);
-
/**
* update_tftp - Update firmware over TFTP (via DFU)
*
diff --git a/net/dns.c b/net/dns.c
index 67d761d7c0f5..dfcd0b85c875 100644
--- a/net/dns.c
+++ b/net/dns.c
@@ -35,6 +35,16 @@ char *net_dns_env_var; /* The envvar to store the
answer in */
static int dns_our_port;
+/*
+ * make port a little random (1024-17407)
+ * This keeps the math somewhat trivial to compute, and seems to work with
+ * all supported protocols/clients/servers
+ */
+static unsigned int random_port(void)
+{
+ return 1024 + (get_timer(0) % 0x4000);
+}
+
static void dns_send(void)
{
struct header *header;
diff --git a/net/net.c b/net/net.c
index a76e16b41654..0a42db0a19fb 100644
--- a/net/net.c
+++ b/net/net.c
@@ -1539,20 +1539,6 @@ int net_parse_bootfile(struct in_addr *ipaddr, char
*filename, int max_len)
return 1;
}
-#ifdefined(CONFIG_CMD_NFS) || \
- defined(CONFIG_CMD_SNTP)|| \
- defined(CONFIG_CMD_DNS)
-/*
- * make port a little random (1024-17407)
- * This keeps the math somewhat trivial to compute, and seems to work with
- * all supported protocols/clients/servers
- */
-unsigned int random_port(void)
-{
- return 1024 + (get_timer(0) % 0x4000);
-}
-#endif
-
void ip_to_string(struct in_addr x, char *s)
{
x.s_addr = ntohl(x.s_addr);
--
2.26.2
Re: [PATCH v2] misc: i2c_eeprom: implement different probe test eeprom offset
Hi Heiko,
On Thu, May 07 2020, Heiko Schocher wrote:
> Am 07.05.2020 um 10:53 schrieb Eugen Hristev:
>> Because of this commit :
>> 5ae84860b0 ("misc: i2c_eeprom: verify that the chip is functional at
>> probe()")
>> at probe time, each eeprom is tested for read at offset 0.
>>
>> The Atmel AT24MAC402 eeprom has different mapping. One i2c slave address is
>> used for the lower 0x80 bytes and another i2c slave address is used for the
>> upper 0x80 bytes. Because of this basically the i2c master sees 2 different
>> slaves. We need the upper bytes because we read the unique MAC address from
>> this EEPROM area.
>>
>> However this implies that our slave address will return error on reads
>> from address 0x0 to 0x80.
>>
>> To solve this, implemented an offset field inside platform data that is by
>> default 0 (as it is used now), but can be changed in the compatible table.
>>
>> The probe function will now read at this offset and use it, instead of
>> blindly
>> checking offset 0.
>>
>> This will fix the regression noticed on these EEPROMs since the commit
>> abovementioned that introduces the probe failed issue.
>>
>> Signed-off-by: Eugen Hristev
>> ---
>>
>> Please disregard patch
>> [PATCH] misc: i2c_eeprom: implement different probe test eeprom offset
>>
>> as that patch was mistakenly done on an older u-boot version.
>> This v2 patch applies correctly on u-boot/master
>>
>> Changes in v2:
>> - adapt to latest changes in driver. v1 was done on u-boot 2020.01
>> accidentaly.
>>
>> drivers/misc/i2c_eeprom.c | 8 +++-
>> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> Thanks for rebasing!
>
> I prefer to fix the issue instead reverting commit:
>
> 5ae84860b0 ("misc: i2c_eeprom: verify that the chip is functional at probe()")
>
> Reviewed-by: Heiko Schocher
>
> @Baruch, is this Ok for you?
According to the Linux driver there are more devices that need read
offset. 24cs32 and 24cs64 are affected. This patch does not fix the
regression for those devices.
Eugen, would it be possible for you to extend the fix to 24cs32/64 and
test on real hardware?
baruch
>> diff --git a/drivers/misc/i2c_eeprom.c b/drivers/misc/i2c_eeprom.c
>> index ef5f103c98..32a1b20856 100644
>> --- a/drivers/misc/i2c_eeprom.c
>> +++ b/drivers/misc/i2c_eeprom.c
>> @@ -17,6 +17,7 @@ struct i2c_eeprom_drv_data {
>> u32 pagesize; /* page size in bytes */
>> u32 addr_offset_mask; /* bits in addr used for offset overflow */
>> u32 offset_len; /* size in bytes of offset */
>> +u32 start_offset; /* valid start offset inside memory, by default 0 */
>> };
>> int i2c_eeprom_read(struct udevice *dev, int offset, uint8_t *buf, int
>> size)
>> @@ -147,7 +148,11 @@ static int i2c_eeprom_std_probe(struct udevice *dev)
>> i2c_set_chip_addr_offset_mask(dev, data->addr_offset_mask);
>> /* Verify that the chip is functional */
>> -ret = i2c_eeprom_read(dev, 0, _byte, 1);
>> +/*
>> + * Not all eeproms start from offset 0. Valid offset is available
>> + * in the platform data struct.
>> + */
>> +ret = i2c_eeprom_read(dev, data->start_offset, _byte, 1);
>> if (ret)
>> return -ENODEV;
>> @@ -215,6 +220,7 @@ static const struct i2c_eeprom_drv_data
>> atmel24mac402_data = {
>> .pagesize = 16,
>> .addr_offset_mask = 0,
>> .offset_len = 1,
>> +.start_offset = 0x80,
>> };
>> static const struct i2c_eeprom_drv_data atmel24c32_data = {
>>
--
~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
Re: [PATCH] misc: i2c_eeprom: implement different probe test eeprom offset
Hi Eugen,
On Wed, May 06 2020, Eugen Hristev wrote:
> Because of this commit :
> 5ae84860b0 ("misc: i2c_eeprom: verify that the chip is functional at probe()")
> at probe time, each eeprom is tested for read at offset 0.
>
> The Atmel AT24MAC402 eeprom has different mapping. One i2c slave address is
> used for the lower 0x80 bytes and another i2c slave address is used for the
> upper 0x80 bytes. Because of this basically the i2c master sees 2 different
> slaves. We need the upper bytes because we read the unique MAC address from
> this EEPROM area.
>
> However this implies that our slave address will return error on reads
> from address 0x0 to 0x80.
>
> To solve this, implemented a way to figure out from the compatible udevice_id
> 'data' field which offset we should attempt to read.
> Added the offset as one byte in the data field (byte number 3).
> Created two macros that will convert offset to 'data' field and back.
>
> The probe function will now read this offset and use it, instead of blindly
> checking offset 0.
>
> This will fix the regression noticed on these EEPROMs since the commit
> abovementioned that introduces the probe failed issue.
Judging from the Linux at24 driver that commit appears to break a number
of other eeprom chips. I suggest to just revert it.
baruch
>
> The offset field can for sure be updated later at a 2byte offset if needed
> by anyone.
>
> Signed-off-by: Eugen Hristev
> ---
> drivers/misc/i2c_eeprom.c | 18 --
> 1 file changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/misc/i2c_eeprom.c b/drivers/misc/i2c_eeprom.c
> index 3755dbf74b..79805cc46e 100644
> --- a/drivers/misc/i2c_eeprom.c
> +++ b/drivers/misc/i2c_eeprom.c
> @@ -11,6 +11,13 @@
> #include
> #include
>
> +/* These macros are used to encode/decode the starting EEPROM offset into the
> + * udevice_id structure's data field 3rd byte.
> + * Lower 2 bytes of the data field are used for pagewidth.
> + */
> +#define I2C_EEPROM_OFFSET_TO_DATA(v) ((v) << 16)
> +#define I2C_EEPROM_DATA_TO_OFFSET(v) ((v) >> 16)
> +
> int i2c_eeprom_read(struct udevice *dev, int offset, uint8_t *buf, int size)
> {
> const struct i2c_eeprom_ops *ops = device_get_ops(dev);
> @@ -85,11 +92,17 @@ static int i2c_eeprom_std_ofdata_to_platdata(struct
> udevice *dev)
>
> static int i2c_eeprom_std_probe(struct udevice *dev)
> {
> + u64 data = dev_get_driver_data(dev);
> u8 test_byte;
> int ret;
>
> /* Verify that the chip is functional */
> - ret = i2c_eeprom_read(dev, 0, _byte, 1);
> + /*
> + * Not all eeproms start from offset 0. Valid offset is encoded in
> + * upper bits of the data (byte 3).
> + */
> + ret = i2c_eeprom_read(dev, I2C_EEPROM_DATA_TO_OFFSET(data) & 0xFF,
> + _byte, 1);
> if (ret)
> return -ENODEV;
>
> @@ -105,7 +118,8 @@ static const struct udevice_id i2c_eeprom_std_ids[] = {
> { .compatible = "atmel,24c08", .data = 4 },
> { .compatible = "atmel,24c08a", .data = 4 },
> { .compatible = "atmel,24c16a", .data = 4 },
> - { .compatible = "atmel,24mac402", .data = 4 },
> + { .compatible = "atmel,24mac402",
> + .data = (4 | I2C_EEPROM_OFFSET_TO_DATA(0x80))},
> { .compatible = "atmel,24c32", .data = 5 },
> { .compatible = "atmel,24c64", .data = 5 },
> { .compatible = "atmel,24c128", .data = 6 },
--
~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
Re: [PATCH 0/4] Updates for ClearFog EEPROM
Hi Stefan,
On Wed, Apr 15 2020, Stefan Roese wrote:
> On 19.01.20 08:10, 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.
>>
>>
>> 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(-)
>
> Is it correct to assume, that this patchset is superseded by the
> Baruch's work? Can it be dropped?
Which work are you referring to?
The text quoted above specifically mentions dependency on my patch
series adding auto detection based on EEPROM data. So as I understand
these patches are still useful.
Joel, correct me if I am wrong.
baruch
--
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] mtd: nand: pxa3xx: fix raw read when last_chunk_size == 0
Commit 6293b0361d9 ("mtd: nand: pxa3xx: add raw read support") added the
local data_len variable in handle_data_pio() to track read size, but
forgot to update the condition of drain_fifo() call. That happens to
work when the layout last_chunk_size != 0. But when last_chunk_size ==
0, drain_fifo() is not called to read the last chunk, which leads to
"Wait timeout!!!" error. Fix this.
Fixes: 6293b0361d9 ("mtd: nand: pxa3xx: add raw read support")
Cc: Miquel Raynal
Signed-off-by: Baruch Siach
---
drivers/mtd/nand/raw/pxa3xx_nand.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/raw/pxa3xx_nand.c
b/drivers/mtd/nand/raw/pxa3xx_nand.c
index 03f210bdb0b3..7e3346dfcc2d 100644
--- a/drivers/mtd/nand/raw/pxa3xx_nand.c
+++ b/drivers/mtd/nand/raw/pxa3xx_nand.c
@@ -639,7 +639,7 @@ static void handle_data_pio(struct pxa3xx_nand_info *info)
DIV_ROUND_UP(info->step_spare_size, 4));
break;
case STATE_PIO_READING:
- if (info->step_chunk_size)
+ if (data_len)
drain_fifo(info,
info->data_buff + info->data_buff_pos,
DIV_ROUND_UP(data_len, 4));
--
2.25.1
Re: [RFC 0/7] mx6cuboxi: enable OF_PLATDATA with MMC support
Hi Walter,
On Mon, Mar 30 2020, Walter Lozano wrote:
> The SPL in iMX6 boards is restricted to 68 KB as this is the free available
> space in OCRAM for most revisions. In this context, adding OF_CONTROL and DM
> increases the SPL size which could make it difficult to add specific features
> required for custom scenarios.
>
> These patches aim to take advantage of OF_PLATADATA in order to reduce the SPL
> size in this scenario, by parsing DT data to generate platdata structures,
> and thus removing the overhead caused by DT and related libraries.
>
> This series is focused in MMC driver, which is used for boot in boards such as
> Cubox-i. Also, in order to support CD, the OF_PLATDATA support is also
> implemented on GPIO driver.
>
> To make possible to link the CD information found in platdata with a GPIO,
> a new API is suggested, to find/get a device based on its platdata. This
> new API was discussed in [1] but the lack of context made the discussion
> not to progress. With this series, the general idea should be clearer,
> so a better solution could be discussed.
>
> Finally, in order to make use of these new features, enable OF_PLATADATA for
> Cubox-i board, for which OF_CONTROL support is being discussed in [2].
What is the net SPL size reduction of OF_PLATDATA in the Cubox-i case?
Thanks,
baruch
> [1] https://patchwork.ozlabs.org/patch/1249198/
> [2] https://patchwork.ozlabs.org/project/uboot/list/?series=163738
>
> Walter Lozano (7):
> mmc: fsl_esdhc_imx: add OF_PLATDATA support
> mmc: fsl_esdhc_imx: add ofdata_to_platdata support
> dtoc: update dtb_platdata to support cd-gpio
> dm: uclass: add functions to get device by platdata
> gpio: mxc_gpio: add OF_PLATDATA support
> mmc: fsl_esdhc_imx: add CD support when OF_PLATDATA is enabled
> mx6cuboxi: enable OF_PLATDATA
>
> configs/mx6cuboxi_defconfig | 2 +
> drivers/core/device.c| 19 +++
> drivers/core/uclass.c| 34
> drivers/gpio/mxc_gpio.c | 27 -
> drivers/mmc/fsl_esdhc_imx.c | 105 ++-
> include/dm/device.h | 11
> include/dm/uclass-internal.h | 15 +
> include/dm/uclass.h | 15 +
> tools/dtoc/dtb_platdata.py | 9 ++-
> 9 files changed, 218 insertions(+), 19 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 -
Re: [PATCH v5 00/12] ClearFog Base static variant support
Hi Stefan,
On Mon, Mar 23 2020, Stefan Roese wrote:
> On 22.03.20 19:46, Joel Johnson wrote:
>> I just wanted to ping on this review
>> (http://patchwork.ozlabs.org/project/uboot/list/?series=155533) to see if it
>> had reached an agreeable state or if there were still lingering issues. I've
>> been using it without issue against RC releases.
>>
>> If the plan is to not include it in v2020.04 that's completely reasonable,
>> but I would request review and feedback on blocking issues, otherwise does
>> it have general agreement for merging in the next merge window?
>
> I won't pull this into v2020.04 as you might understand. I was hoping to
> get some reviews and testing from people with access to those boards.
>
> Baruch, could you please check again, if you agree with this approach?
> Or do you have some change request for this build-time vs run-time
> detection?
This series is the end result of discussions between Joel and me on the
list with a few iterations. I am fine with this result, and I think it
is good to go. I can't test these patches at the moment. Hope to do that
some time later.
Thanks,
baruch
>> On 2020-01-27 13:01, Joel Johnson wrote:
>>> 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
>>> v3 changes:
>>> - rebased against ClearFog runtime TLV EEPROM changes merged into
>>> mvebu/master
>>> v4
>>> - adjust static SerDes configuration at runtime instead of #ifdef
>>> v5
>>> - distinguish build-only config changes (SFP and PCIe/SATA) from
>>> runtime detectable config changes
>>> - retested SATA mode in PCIe slot with swap rx changes, confirmed
>>> working as presently patched. Only tested with ClearFog Base which
>>> only provides single channel, but Pro mechanism is parallel.
>>>
>>>
>>> Joel Johnson (12):
>>> arm: mvebu: fix SerDes table alignment
>>> arm: mvebu: solidrun: remove hardcoded DTS MAC address
>>> arm: mvebu: clearfog: use Pro name by default
>>> arm: mvebu: clearfog: initial ClearFog Base variant
>>> arm: mvebu: clearfog: Add option for 2.5 Gbps SFP
>>> arm: mvebu: clearfog: Add SATA mode flags
>>> arm: mvebu: clearfog: Unify DT selection paths
>>> arm: mvebu: clearfog: add SPI offsets
>>> arm: mvebu: enable working default boot support
>>> arm: mvebu: clearfog: move ENV params to Kconfig
>>> arm: mvebu: clearfog: don't always use SPL MMC
>>> arm: mvebu: clearfog: Use Pro DT by default
>>>
>>> .../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| 53 +---
>>> configs/clearfog_defconfig| 4 --
>>> include/configs/clearfog.h| 1 -
>>> 7 files changed, 124 insertions(+), 16 deletions(-)
>>> create mode 100644 board/solidrun/clearfog/Kconfig
>
>
> Viele Grüße,
> Stefan
--
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 -
Re: [PATCH v5 05/12] arm: mvebu: clearfog: Add option for 2.5 Gbps SFP
Hi Stefan,
On Mon, Mar 23 2020, Stefan Roese wrote:
> On 27.01.20 21:01, Joel Johnson wrote:
>> While newer Linux kernels provide autoconfiguration of SFP, provide
>> an option for setting in U-Boot Kconfig for use prior to booting.
>>
>> Signed-off-by: Joel Johnson
>>
>> ---
>>
>> v2 changes:
>>- fixed help indentation
>> v3 changes:
>>- none
>> v4 changes:
>>- adjust static SerDes configuration at runtime instead of #ifdef
>> v5 changes:
>>- make independent of runtime detection
>>
>> ---
>> board/solidrun/clearfog/Kconfig| 7 +++
>> board/solidrun/clearfog/clearfog.c | 5 +
>> 2 files changed, 12 insertions(+)
>>
>> diff --git a/board/solidrun/clearfog/Kconfig
>> b/board/solidrun/clearfog/Kconfig
>> index 936d5918f8..c910e17093 100644
>> --- a/board/solidrun/clearfog/Kconfig
>> +++ b/board/solidrun/clearfog/Kconfig
>> @@ -15,4 +15,11 @@ config TARGET_CLEARFOG_BASE
>>detection via additional EEPROM hardware. This option enables
>> selecting
>>the Base variant for older hardware revisions.
>> +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 c873d00905..064ce4e520 100644
>> --- a/board/solidrun/clearfog/clearfog.c
>> +++ b/board/solidrun/clearfog/clearfog.c
>> @@ -63,6 +63,11 @@ int hws_board_topology_load(struct serdes_map
>> **serdes_map_array, u8 *count)
>> {
>> cf_read_tlv_data();
>> + /* Apply build configuration options before runtime configuration */
>> +if (IS_ENABLED(CONFIG_CLEARFOG_SFP_25GB))
>> +board_serdes_map[5].serdes_speed = SERDES_SPEED_3_125_GBPS;
>
> Just checking: Your option is for 2.5 gbps and you configure here to
> 3.125 gpbs. Is this intended?
This is intended. Serdes encoding is 8b/10b. So for 2.5Gbps you need
serdes rate of 3.125Gbps. For 1Gbps we already set 1.25Gpbs serdes rate
(SERDES_SPEED_1_25_GBPS) in board_serdes_map[].
baruch
--
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 -
Re: [PATCH v2 2/4] mx6cuboxi: customize board_boot_order to access eMMC
Hi Walter,
On Mon, Mar 16, 2020 at 02:53:58PM -0300, Walter Lozano wrote:
> On 16/3/20 14:25, Baruch Siach wrote:
> > On Mon, Mar 16, 2020 at 02:05:57PM -0300, Walter Lozano wrote:
> > > On 16/3/20 13:28, Baruch Siach wrote:
> > > > On Thu, Mar 12, 2020 at 01:52:13PM -0300, Walter Lozano wrote:
> > > > > Thanks for sharing.
> > > > >
> > > > > On 12/3/20 02:02, Baruch Siach wrote:
> > > > > > Hi Walter,
> > > > > >
> > > > > > On Wed, Mar 11 2020, Walter Lozano wrote:
> > > > > > > In SPL legacy code only one MMC device is created, based on
> > > > > > > BOOT_CFG
> > > > > > > register, which can be either SD or eMMC. In this context
> > > > > > > board_boot_order return always MMC1 when configure to boot from
> > > > > > > SD/eMMC. After switching to DM both SD and eMMC devices are
> > > > > > > created
> > > > > > > based on the information available on DT, but as board_boot_order
> > > > > > > only returns MMC1 is not possible to boot from eMMC.
> > > > > > >
> > > > > > > This patch customizes board_boot_order taking into account
> > > > > > > BOOT_CFG
> > > > > > > register to point to correct MMC1 / MMC2 device. Additionally,
> > > > > > > handle
> > > > > > > IO mux for the desired boot device.
> > > > > > >
> > > > > > > Signed-off-by: Walter Lozano
> > > > > > > ---
> > > > > > > board/solidrun/mx6cuboxi/mx6cuboxi.c | 49
> > > > > > >
> > > > > > > 1 file changed, 49 insertions(+)
> > > > > > >
> > > > > > > diff --git a/board/solidrun/mx6cuboxi/mx6cuboxi.c
> > > > > > > b/board/solidrun/mx6cuboxi/mx6cuboxi.c
> > > > > > > index 6a96f9ecdb..9bf3645f72 100644
> > > > > > > --- a/board/solidrun/mx6cuboxi/mx6cuboxi.c
> > > > > > > +++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c
> > > > > > > @@ -435,6 +435,7 @@ int board_early_init_f(void)
> > > > > > > #ifdef CONFIG_CMD_SATA
> > > > > > > setup_sata();
> > > > > > > #endif
> > > > > > > +
> > > > > > This hunk should not be part of this commit.
> > > > > Thanks for pointing to this silly hunk. I will prepare a V3.
> > > > >
> > > > > > Looks good to me, otherwise.
> > > > > >
> > > > > > I can't test at the moment. Have you tested boot from both SD card
> > > > > > and eMMC?
> > > > > Most of the work was done booting from SD. In order to test booting
> > > > > from
> > > > > eMMC, as I have some specific eFUSE configs, I tweaked
> > > > > board_boot_order to
> > > > > force booting from eMMC.
> > > > But that does not cover SPL boot from eMMC, right?
> > > Basically I think this approach should cover the necessary steps. To be
> > > more
> > > clear about my tweak
> > >
> > > 1- BootROM loads SPL from SD
> > >
> > > 2- SPL is tweaked to load U-Boot from eMMC, and in this way test its
> > > support
> > > on SPL
> > This is not exactly the same as SPL boot from eMMC. For example, your
> > scenario
> > would work even without 'u-boot,dm-pre-reloc' property in the eMMC device
> > node.
>
> I agree, it is not exactly the same and I really appreciate the time you
> spent testing it. However I still don't understand your comments regarding
> 'u-boot,dm-pre-reloc', as without this property there wouldn't be a usdhc3
> node in the DTB for SPL. Could you please clarify?
You are right. Bad example.
> > > > Anyway I tested your patches here on real hardware with unfused SOM and
> > > > SD/eMMC boot select jumpers.
> > > Thank you much for taking the time to test these patches in you board. I
> > > really appreciate your help
> > >
> > > > Tested-by: Baruch Siach
> > > Thanks. I'll add the tag to the v3.
> > I think this series ready as is. No need to post v3 just for the test tag.
> > Patchwork collects patch tags automatically. See under the 'A/F/R/T' column
> > here:
> >
> >http://patchwork.ozlabs.org/project/uboot/list/?series=163738
>
> I see, thanks for clarifying the issue related to "Tested-by" tag. Sorry for
> asking but, is it not necessary to send a v3 to avoid the "silly hunk" you
> pointed me?
I forgot about that. Maybe Stefano can make this trivial change when applying.
I would not respin the series just for that.
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
Re: [PATCH v2 2/4] mx6cuboxi: customize board_boot_order to access eMMC
Hi Walter
On Mon, Mar 16, 2020 at 02:05:57PM -0300, Walter Lozano wrote:
> On 16/3/20 13:28, Baruch Siach wrote:
> > On Thu, Mar 12, 2020 at 01:52:13PM -0300, Walter Lozano wrote:
> > > Thanks for sharing.
> > >
> > > On 12/3/20 02:02, Baruch Siach wrote:
> > > > Hi Walter,
> > > >
> > > > On Wed, Mar 11 2020, Walter Lozano wrote:
> > > > > In SPL legacy code only one MMC device is created, based on BOOT_CFG
> > > > > register, which can be either SD or eMMC. In this context
> > > > > board_boot_order return always MMC1 when configure to boot from
> > > > > SD/eMMC. After switching to DM both SD and eMMC devices are created
> > > > > based on the information available on DT, but as board_boot_order
> > > > > only returns MMC1 is not possible to boot from eMMC.
> > > > >
> > > > > This patch customizes board_boot_order taking into account BOOT_CFG
> > > > > register to point to correct MMC1 / MMC2 device. Additionally, handle
> > > > > IO mux for the desired boot device.
> > > > >
> > > > > Signed-off-by: Walter Lozano
> > > > > ---
> > > > >board/solidrun/mx6cuboxi/mx6cuboxi.c | 49
> > > > >
> > > > >1 file changed, 49 insertions(+)
> > > > >
> > > > > diff --git a/board/solidrun/mx6cuboxi/mx6cuboxi.c
> > > > > b/board/solidrun/mx6cuboxi/mx6cuboxi.c
> > > > > index 6a96f9ecdb..9bf3645f72 100644
> > > > > --- a/board/solidrun/mx6cuboxi/mx6cuboxi.c
> > > > > +++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c
> > > > > @@ -435,6 +435,7 @@ int board_early_init_f(void)
> > > > >#ifdef CONFIG_CMD_SATA
> > > > > setup_sata();
> > > > >#endif
> > > > > +
> > > > This hunk should not be part of this commit.
> > > Thanks for pointing to this silly hunk. I will prepare a V3.
> > >
> > > > Looks good to me, otherwise.
> > > >
> > > > I can't test at the moment. Have you tested boot from both SD card and
> > > > eMMC?
> > > Most of the work was done booting from SD. In order to test booting from
> > > eMMC, as I have some specific eFUSE configs, I tweaked board_boot_order to
> > > force booting from eMMC.
> > But that does not cover SPL boot from eMMC, right?
>
> Basically I think this approach should cover the necessary steps. To be more
> clear about my tweak
>
> 1- BootROM loads SPL from SD
>
> 2- SPL is tweaked to load U-Boot from eMMC, and in this way test its support
> on SPL
This is not exactly the same as SPL boot from eMMC. For example, your scenario
would work even without 'u-boot,dm-pre-reloc' property in the eMMC device
node.
> > Anyway I tested your patches here on real hardware with unfused SOM and
> > SD/eMMC boot select jumpers.
>
> Thank you much for taking the time to test these patches in you board. I
> really appreciate your help
>
> > Tested-by: Baruch Siach
> Thanks. I'll add the tag to the v3.
I think this series ready as is. No need to post v3 just for the test tag.
Patchwork collects patch tags automatically. See under the 'A/F/R/T' column
here:
http://patchwork.ozlabs.org/project/uboot/list/?series=163738
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
Re: [PATCH v2 2/4] mx6cuboxi: customize board_boot_order to access eMMC
Hi Walter,
On Thu, Mar 12, 2020 at 01:52:13PM -0300, Walter Lozano wrote:
> Hi Baruch,
>
> Thanks for sharing.
>
> On 12/3/20 02:02, Baruch Siach wrote:
> > Hi Walter,
> >
> > On Wed, Mar 11 2020, Walter Lozano wrote:
> > > In SPL legacy code only one MMC device is created, based on BOOT_CFG
> > > register, which can be either SD or eMMC. In this context
> > > board_boot_order return always MMC1 when configure to boot from
> > > SD/eMMC. After switching to DM both SD and eMMC devices are created
> > > based on the information available on DT, but as board_boot_order
> > > only returns MMC1 is not possible to boot from eMMC.
> > >
> > > This patch customizes board_boot_order taking into account BOOT_CFG
> > > register to point to correct MMC1 / MMC2 device. Additionally, handle
> > > IO mux for the desired boot device.
> > >
> > > Signed-off-by: Walter Lozano
> > > ---
> > > board/solidrun/mx6cuboxi/mx6cuboxi.c | 49
> > > 1 file changed, 49 insertions(+)
> > >
> > > diff --git a/board/solidrun/mx6cuboxi/mx6cuboxi.c
> > > b/board/solidrun/mx6cuboxi/mx6cuboxi.c
> > > index 6a96f9ecdb..9bf3645f72 100644
> > > --- a/board/solidrun/mx6cuboxi/mx6cuboxi.c
> > > +++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c
> > > @@ -435,6 +435,7 @@ int board_early_init_f(void)
> > > #ifdef CONFIG_CMD_SATA
> > > setup_sata();
> > > #endif
> > > +
> > This hunk should not be part of this commit.
>
> Thanks for pointing to this silly hunk. I will prepare a V3.
>
> > Looks good to me, otherwise.
> >
> > I can't test at the moment. Have you tested boot from both SD card and eMMC?
>
> Most of the work was done booting from SD. In order to test booting from
> eMMC, as I have some specific eFUSE configs, I tweaked board_boot_order to
> force booting from eMMC.
But that does not cover SPL boot from eMMC, right?
Anyway I tested your patches here on real hardware with unfused SOM and
SD/eMMC boot select jumpers.
Tested-by: Baruch Siach
> Regarding booting from SD/eMMC, I also wonder if having a list of boot
> devices would be useful, like
>
> switch (boot_mode >> IMX6_BMODE_SHIFT) {
> case IMX6_BMODE_SD:
> case IMX6_BMODE_ESD:
> case IMX6_BMODE_MMC:
> case IMX6_BMODE_EMMC:
> SETUP_IOMUX_PADS(usdhc2_pads);
> SETUP_IOMUX_PADS(usdhc3_pads);
>
> /*
>* Upon reading BOOT_CFG register the following map is done:
>* Bit 11 and 12 of BOOT_CFG register can determine the current
>* mmc port
>* 0x1 SD2
>* 0x2 SD3
>*/
>
> reg &= 0x3; /* Only care about bottom 2 bits */
> switch (reg) {
> case 1:
> spl_boot_list[0] = BOOT_DEVICE_MMC1;
> spl_boot_list[1] = BOOT_DEVICE_MMC2;
> break;
> case 2:
> spl_boot_list[0] = BOOT_DEVICE_MMC2;
> spl_boot_list[1] = BOOT_DEVICE_MMC1;
> break;
> }
> break;
>
> What do you think?
This might cause surprising results when the U-Boot image on the SPL boot
device is damaged for some reason. This kind of fallback device (other than
USB boot) should not be enabled by default, in my opinion.
baruch
> > In the future, please keep i.MX maintainers (Stefano, Fabio) in Cc.
>
>
> Thanks for the advice. You are totally right.
>
> Regards,
>
> Walter
>
> > Thanks,
> > baruch
> >
> > > return 0;
> > > }
> > > @@ -624,6 +625,54 @@ int board_fit_config_name_match(const char *name)
> > > return strcmp(name, tmp_name);
> > > }
> > > +void board_boot_order(u32 *spl_boot_list)
> > > +{
> > > + struct src *psrc = (struct src *)SRC_BASE_ADDR;
> > > + unsigned int reg = readl(>sbmr1) >> 11;
> > > + u32 boot_mode = imx6_src_get_boot_mode() & IMX6_BMODE_MASK;
> > > + unsigned int bmode = readl(_base->sbmr2);
> > > +
> > > + /* If bmode is serial or USB phy is active, return serial */
> > > + if (((bmode >> 24) & 0x03) == 0x01 || is_usbotg_phy_active()) {
> > > + spl_boot_list[0] = BOOT_DEVICE_BOARD;
> > > + return;
> > > + }
> > > +
> > > + switch (boot_mode >&g
Re: [PATCH v2 2/4] mx6cuboxi: customize board_boot_order to access eMMC
Hi Walter,
On Wed, Mar 11 2020, Walter Lozano wrote:
> In SPL legacy code only one MMC device is created, based on BOOT_CFG
> register, which can be either SD or eMMC. In this context
> board_boot_order return always MMC1 when configure to boot from
> SD/eMMC. After switching to DM both SD and eMMC devices are created
> based on the information available on DT, but as board_boot_order
> only returns MMC1 is not possible to boot from eMMC.
>
> This patch customizes board_boot_order taking into account BOOT_CFG
> register to point to correct MMC1 / MMC2 device. Additionally, handle
> IO mux for the desired boot device.
>
> Signed-off-by: Walter Lozano
> ---
> board/solidrun/mx6cuboxi/mx6cuboxi.c | 49
> 1 file changed, 49 insertions(+)
>
> diff --git a/board/solidrun/mx6cuboxi/mx6cuboxi.c
> b/board/solidrun/mx6cuboxi/mx6cuboxi.c
> index 6a96f9ecdb..9bf3645f72 100644
> --- a/board/solidrun/mx6cuboxi/mx6cuboxi.c
> +++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c
> @@ -435,6 +435,7 @@ int board_early_init_f(void)
> #ifdef CONFIG_CMD_SATA
> setup_sata();
> #endif
> +
This hunk should not be part of this commit.
Looks good to me, otherwise.
I can't test at the moment. Have you tested boot from both SD card and eMMC?
In the future, please keep i.MX maintainers (Stefano, Fabio) in Cc.
Thanks,
baruch
> return 0;
> }
>
> @@ -624,6 +625,54 @@ int board_fit_config_name_match(const char *name)
> return strcmp(name, tmp_name);
> }
>
> +void board_boot_order(u32 *spl_boot_list)
> +{
> + struct src *psrc = (struct src *)SRC_BASE_ADDR;
> + unsigned int reg = readl(>sbmr1) >> 11;
> + u32 boot_mode = imx6_src_get_boot_mode() & IMX6_BMODE_MASK;
> + unsigned int bmode = readl(_base->sbmr2);
> +
> + /* If bmode is serial or USB phy is active, return serial */
> + if (((bmode >> 24) & 0x03) == 0x01 || is_usbotg_phy_active()) {
> + spl_boot_list[0] = BOOT_DEVICE_BOARD;
> + return;
> + }
> +
> + switch (boot_mode >> IMX6_BMODE_SHIFT) {
> + case IMX6_BMODE_SD:
> + case IMX6_BMODE_ESD:
> + case IMX6_BMODE_MMC:
> + case IMX6_BMODE_EMMC:
> + /*
> + * Upon reading BOOT_CFG register the following map is done:
> + * Bit 11 and 12 of BOOT_CFG register can determine the current
> + * mmc port
> + * 0x1 SD2
> + * 0x2 SD3
> + */
> +
> + reg &= 0x3; /* Only care about bottom 2 bits */
> + switch (reg) {
> + case 1:
> + SETUP_IOMUX_PADS(usdhc2_pads);
> + spl_boot_list[0] = BOOT_DEVICE_MMC1;
> + break;
> + case 2:
> + SETUP_IOMUX_PADS(usdhc3_pads);
> + spl_boot_list[0] = BOOT_DEVICE_MMC2;
> + break;
> + }
> + break;
> + default:
> + /* By default use USB downloader */
> + spl_boot_list[0] = BOOT_DEVICE_BOARD;
> + break;
> + }
> +
> + /* As a last resort, use serial downloader */
> + spl_boot_list[1] = BOOT_DEVICE_BOARD;
> +}
> +
> #ifdef CONFIG_SPL_BUILD
> #include
> static const struct mx6dq_iomux_ddr_regs mx6q_ddr_ioregs = {
--
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 -
Re: [PATCH 3/4] mx6cuboxi: customize board_boot_order to access eMMC
Hi Walter,
On Wed, Mar 04 2020, Walter Lozano wrote:
> In SPL legacy code only one MMC device is created, based on BOOT_CFG
> register, which can be either SD or eMMC. In this context
> board_boot_order return always MMC1 when configure to boot from
> SD/eMMC. After switching to DM both SD and eMMC devices are created
> based on the information available on DT, but as board_boot_order
> only returns MMC1 is not possible to boot from eMMC.
>
> This patch customizes board_boot_order taking into account BOOT_CFG
> register to point to correct MMC1 / MMC2 device.
>
> Signed-off-by: Walter Lozano
> ---
> board/solidrun/mx6cuboxi/mx6cuboxi.c | 49
> 1 file changed, 49 insertions(+)
>
> diff --git a/board/solidrun/mx6cuboxi/mx6cuboxi.c
> b/board/solidrun/mx6cuboxi/mx6cuboxi.c
> index 71c77ad2a2..3ce122e8b9 100644
> --- a/board/solidrun/mx6cuboxi/mx6cuboxi.c
> +++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c
> @@ -649,6 +649,55 @@ int board_fit_config_name_match(const char *name)
> return strcmp(name, tmp_name);
> }
>
> +void board_boot_order(u32 *spl_boot_list)
> +{
> + struct src *psrc = (struct src *)SRC_BASE_ADDR;
> + unsigned int reg = readl(>sbmr1) >> 11;
> + u32 boot_mode = imx6_src_get_boot_mode() & IMX6_BMODE_MASK;
> + unsigned int bmode = readl(_base->sbmr2);
This is duplication of the logicpd/imx6 board code. But..
> +
> + /* If bmode is serial or USB phy is active, return serial */
> + if (((bmode >> 24) & 0x03) == 0x01 || is_usbotg_phy_active()) {
> + spl_boot_list[0] = BOOT_DEVICE_BOARD;
> + return;
> + }
> +
> + switch (boot_mode >> IMX6_BMODE_SHIFT) {
> + case IMX6_BMODE_NAND_MIN ... IMX6_BMODE_NAND_MAX:
> + spl_boot_list[0] = BOOT_DEVICE_NAND;
> + break;
... we have no raw NAND device on Hummingboard.
> + case IMX6_BMODE_SD:
> + case IMX6_BMODE_ESD:
> + case IMX6_BMODE_MMC:
> + case IMX6_BMODE_EMMC:
> + /*
> + * Upon reading BOOT_CFG register the following map is done:
> + * Bit 11 and 12 of BOOT_CFG register can determine the current
> + * mmc port
> + * 0x1 SD2
> + * 0x2 SD3
> + */
> +
> + reg &= 0x3; /* Only care about bottom 2 bits */
> + switch (reg) {
> + case 1:
> + spl_boot_list[0] = BOOT_DEVICE_MMC1;
> + break;
> + case 2:
> + spl_boot_list[0] = BOOT_DEVICE_MMC2;
> + break;
This code is very similar to setup_iomux_mmc(). Maybe an opportunity to share
code between functions?
Thanks,
baruch
> + }
> + break;
> + default:
> + /* By default use USB downloader */
> + spl_boot_list[0] = BOOT_DEVICE_BOARD;
> + break;
> + }
> +
> + /* As a last resort, use serial downloader */
> + spl_boot_list[1] = BOOT_DEVICE_BOARD;
> +}
> +
> #ifdef CONFIG_SPL_BUILD
> #include
> static const struct mx6dq_iomux_ddr_regs mx6q_ddr_ioregs = {
--
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 -
Re: [PATCH 2/4] mx6cuboxi: enable MMC iomux on board_early_init_f
Hi Walter,
Thanks for your SPL_DM support work on this platform.
One comment inline below.
On Wed, Mar 04 2020, Walter Lozano wrote:
> MMC iomux is done on board_mmc_init which is valid when DM_MMC is not
> enabled. After enabling it, the iomux setup needs to be moved to a
> valid place.
>
> This patch moves the MMC iomux to board_early_init_f where other iomux
> is done.
>
> Signed-off-by: Walter Lozano
> ---
> board/solidrun/mx6cuboxi/mx6cuboxi.c | 25 +
> 1 file changed, 25 insertions(+)
>
> diff --git a/board/solidrun/mx6cuboxi/mx6cuboxi.c
> b/board/solidrun/mx6cuboxi/mx6cuboxi.c
> index 6a96f9ecdb..71c77ad2a2 100644
> --- a/board/solidrun/mx6cuboxi/mx6cuboxi.c
> +++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c
> @@ -179,6 +179,28 @@ int board_mmc_get_env_dev(int devno)
>
> #define USDHC2_CD_GPIO IMX_GPIO_NR(1, 4)
>
> +static int setup_iomux_mmc(void)
> +{
> + struct src *psrc = (struct src *)SRC_BASE_ADDR;
> + unsigned reg = readl(>sbmr1) >> 11;
This mostly duplicates the existing mmc_init_spl() routine. As I understand,
mmc_init_spl() becomes dead code once you enable CONFIG_SPL_DM in patch #4 of
this series. Can you remove mmc_init_spl() in a followup patch? Both
struct fsl_esdhc_cfg can also be removed, I believe.
baruch
> +
> + /*
> + * Upon reading BOOT_CFG register the following map is done:
> + * Bit 11 and 12 of BOOT_CFG register can determine the current
> + * mmc port
> + * 0x1 SD2
> + * 0x2 SD3
> + */
> + switch (reg & 0x3) {
> + case 0x1:
> + SETUP_IOMUX_PADS(usdhc2_pads);
> + case 0x2:
> + SETUP_IOMUX_PADS(usdhc3_pads);
> + }
> +
> + return 0;
> +}
> +
> int board_mmc_getcd(struct mmc *mmc)
> {
> struct fsl_esdhc_cfg *cfg = mmc->priv;
> @@ -432,9 +454,12 @@ int board_early_init_f(void)
> {
> setup_iomux_uart();
>
> + setup_iomux_mmc();
> +
> #ifdef CONFIG_CMD_SATA
> setup_sata();
> #endif
> +
> return 0;
> }
--
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 -
Re: [PATCH] arm: mvebu: update RTC values for PCIe memory wrappers
Hi Chris,
On Wed, Feb 26 2020, Chris Packham wrote:
> From: Chris Packham
>
> Update the RTC (Read Timing Control) values for PCIe memory wrappers
> following an ERRATA (ERRATA# TDB). This means the PCIe accesses will
> used slower memory Read Timing, to allow more efficient energy
> consumption, in order to lower the minimum VDD of the memory. Will lead
> to more robust memory when voltage drop occurs (VDDSEG)
Have you seen memory access reliability problems because of this issue?
> The code is based on changes from Marvell's U-Boot, specifically:
>
> https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/commit/20cd2704072512de176e048970f2883db901674b
> https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/commit/eb608a7c8dd0d42b87601a61b9c0cc5615ab94b2
> https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/commit/c4af19ae2bf08cf6e450e741ce4f04d402a5cb6b
> https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/commit/c4af19ae2bf08cf6e450e741ce4f04d402a5cb6b
The last link looks duplicated.
baruch
--
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 -
Re: [PATCH 1/2] board: solidrun lx2160a-cex7: new board
Hi Priyanka,
On Thu, Jan 23, 2020 at 11:42:56AM +0200, Baruch Siach wrote:
> On Thu, Jan 23, 2020 at 09:25:29AM +, Priyanka Jain wrote:
> > >-Original Message-
> > >From: Baruch Siach
> > >Sent: Wednesday, December 4, 2019 6:59 PM
> > >To: Priyanka Jain
> > >Cc: u-boot@lists.denx.de; Rabeeh Khoury ; Jon
> > >Nettleton ; Baruch Siach
> > >Subject: [PATCH 1/2] board: solidrun lx2160a-cex7: new board
> > >
> > >Add board level support code for the SolidRun LX2160A based COM-Express
> > >7 system.
> > >
> > >Signed-off-by: Baruch Siach
> > >---
> > This patch has below compilation warning. Kindly fix.
> >aarch64: + lx2160acex7_tfa
> > +board/solidrun/lx2160acex7/lx2160acex7.c: In function 'uart_get_clock':
> > +board/solidrun/lx2160acex7/lx2160acex7.c:50:18: error: implicit
> > declaration of function 'get_serial_clock'; did you mean 'uart_get_clock'?
> > [-Werror=implicit-function-declaration]
> > + serial0.clock = get_serial_clock();
> > + ^~~~
> > + uart_get_clock
> > +cc1: all warnings being treated as errors
> > +make[2]: *** [board/solidrun/lx2160acex7/lx2160acex7.o] Error 1
> > +make[1]: *** [board/solidrun/lx2160acex7] Error 2
> > +make: *** [sub-make] Error 2
>
> Thanks for your review.
>
> This build error is because of commit d96c26040e901 ("common: Move clock
> functions into a new file"). clock_legacy.h include in now missing. I'll
> rebase the patches on current master and post an update.
It turns out that adding clock_legacy.h is not enough. The board does not boot
current U-Boot master with nothing shown on the console. Do you have any idea
what LX2160A related code change might have caused that?
Thanks,
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
[PATCH] mx6cuboxi: don't disable fdt relocation
fdt_high value of 0x disables fdt relocation on boot. We don't need that for Cubox-i/Hummingboard. Rely on generic code to find the optimal fdt location at boot time. Signed-off-by: Baruch Siach --- include/configs/mx6cuboxi.h | 1 - 1 file changed, 1 deletion(-) diff --git a/include/configs/mx6cuboxi.h b/include/configs/mx6cuboxi.h index 6d47e28fc72b..a6690367f8c5 100644 --- a/include/configs/mx6cuboxi.h +++ b/include/configs/mx6cuboxi.h @@ -66,7 +66,6 @@ "ramdisk_addr_r=0x1300\0" \ "ramdiskaddr=0x1300\0" \ "initrd_high=0x\0" \ - "fdt_high=0x\0" \ "ip_dyn=yes\0" \ "console=" CONSOLE_DEV ",115200\0" \ "bootm_size=0x1000\0" \ -- 2.24.1
Re: [RFC] mx6cuboxi: Enable OF_CONTROL and DM in SPL
Hi Walter,
Thanks for the patch.
One comment below.
On Wed, Jan 29, 2020 at 10:58:07AM -0300, Walter Lozano wrote:
> Make an additional step to add full DM support to mx6cuboxi, including its
> support for SPL
>
> With this new configuration SPL image is 50 KB, higher than the
> 38 KB from the previous version, but it still under the 68 KB limit.
>
> Signed-off-by: Walter Lozano
> ---
> arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi | 4
> configs/mx6cuboxi_defconfig | 3 +++
> 2 files changed, 7 insertions(+)
>
> diff --git a/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi
> b/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi
> index d302b2e275..b1364a0bbf 100644
> --- a/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi
> +++ b/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi
> @@ -34,3 +34,7 @@
> {
> status = "disabled";
> };
> +
> + {
> + u-boot,dm-pre-reloc;
> +};
Have you tested boot from eMMC?
You would most likely need to add to SPL DT for that.
baruch
> diff --git a/configs/mx6cuboxi_defconfig b/configs/mx6cuboxi_defconfig
> index 23ce485f43..ae8d920260 100644
> --- a/configs/mx6cuboxi_defconfig
> +++ b/configs/mx6cuboxi_defconfig
> @@ -24,6 +24,7 @@ CONFIG_USE_PREBOOT=y
> CONFIG_PREBOOT="if hdmidet; then usb start; setenv stdin serial,usbkbd;
> setenv stdout serial,vga; setenv stderr serial,vga; else setenv stdin
> serial; setenv stdout serial; setenv stderr serial; fi;"
> CONFIG_BOUNCE_BUFFER=y
> CONFIG_BOARD_EARLY_INIT_F=y
> +CONFIG_SPL_SEPARATE_BSS=y
> CONFIG_SPL_FS_EXT4=y
> CONFIG_SPL_I2C_SUPPORT=y
> CONFIG_SPL_WATCHDOG_SUPPORT=y
> @@ -36,6 +37,7 @@ CONFIG_CMD_CACHE=y
> CONFIG_CMD_EXT4_WRITE=y
> # CONFIG_SPL_PARTITION_UUIDS is not set
> CONFIG_OF_CONTROL=y
> +CONFIG_SPL_OF_CONTROL=y
> CONFIG_DEFAULT_DEVICE_TREE="imx6dl-hummingboard2-emmc-som-v15"
> CONFIG_OF_LIST="imx6dl-hummingboard2-emmc-som-v15
> imx6q-hummingboard2-emmc-som-v15"
> CONFIG_MULTI_DTB_FIT=y
> @@ -44,6 +46,7 @@ CONFIG_SYS_RELOC_GD_ENV_ADDR=y
> CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
> CONFIG_NET_RANDOM_ETHADDR=y
> CONFIG_DM=y
> +CONFIG_SPL_DM=y
> CONFIG_DWC_AHSATA=y
> CONFIG_DM_GPIO=y
> CONFIG_DM_MMC=y
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
Re: [PATCH v5 12/12] arm: mvebu: clearfog: Use Pro DT by default
Hi Joel,
On Mon, Jan 27, 2020 at 01:01:56PM -0700, Joel Johnson wrote:
> Switch to explicitly using the Pro variant DT, which has been
> available since Linux 4.11.
>
> ---
>
> v4 changes:
> - new
> v5 changes:
> - none
>
> I separated out this change to the end of the series since it drew
> questioning on prior review. I'd still advocate for making the change,
> since especially with the additions of static variants and runtime
> detection, it becomes easier from within a booted kernel to identify the
> type and version of U-Boot image installed. Without making this change,
> it becomes less direct to determine an actual Pro vs. Base, vs old
> U-Boot image maybe supporting some hybrid variant configuration.
>
> Even in the Linux kernel adding of the Pro DTS, it is indicated that it
> was meant for backwards compatibility.
>
> Except for cases where checking is done directly against the product
> name from userspace, I don't see downsides even from a compatibility
> perspective for not making this change. In cases where checking *is*
> done from userspace, the broadening of the Clearfog product line would
> seem to mean that userspace checking should be flagged as needing to be
> udpated as well (or glob/regex matched as needed).
One downside I see is that boot of kernels older than 4.11 will fail. But
maybe since we already assume a newer kernel for armada-388-clearfog-base.dtb
we can do that for -pro as well.
By the way, does env_set() override the stored environment?
baruch
>
> Signed-off-by: Joel Johnson
> ---
> board/solidrun/clearfog/clearfog.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/board/solidrun/clearfog/clearfog.c
> b/board/solidrun/clearfog/clearfog.c
> index 4170fd4775..c31cfcb242 100644
> --- a/board/solidrun/clearfog/clearfog.c
> +++ b/board/solidrun/clearfog/clearfog.c
> @@ -238,7 +238,7 @@ int board_late_init(void)
> else if (IS_ENABLED(CONFIG_TARGET_CLEARFOG_BASE))
> env_set("fdtfile", "armada-388-clearfog-base.dtb");
> else
> - env_set("fdtfile", "armada-388-clearfog.dtb");
> + env_set("fdtfile", "armada-388-clearfog-pro.dtb");
>
> return 0;
> }
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
Re: [PATCH v5 06/12] arm: mvebu: clearfog: Add SATA mode flags
Hi Joel,
On Mon, Jan 27, 2020 at 01:01:50PM -0700, Joel Johnson wrote:
> 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
> v3 changes:
> - none
> v4 changes:
> - adjust static SerDes configuration at runtime instead of #ifdef
> - add setting of swap_rx for SATA (as yet untested on hardware)
> v5 changes:
> - make independent of runtime detection
>
> ---
> board/solidrun/clearfog/Kconfig| 17 +
> board/solidrun/clearfog/clearfog.c | 15 +++
> 2 files changed, 32 insertions(+)
>
> diff --git a/board/solidrun/clearfog/Kconfig b/board/solidrun/clearfog/Kconfig
> index c910e17093..44224d903d 100644
> --- a/board/solidrun/clearfog/Kconfig
> +++ b/board/solidrun/clearfog/Kconfig
> @@ -15,6 +15,23 @@ 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.
> +
> config CLEARFOG_SFP_25GB
> bool "Enable 2.5 Gbps mode for SFP"
> help
> diff --git a/board/solidrun/clearfog/clearfog.c
> b/board/solidrun/clearfog/clearfog.c
> index 064ce4e520..f650e2b40e 100644
> --- a/board/solidrun/clearfog/clearfog.c
> +++ b/board/solidrun/clearfog/clearfog.c
> @@ -67,6 +67,21 @@ int hws_board_topology_load(struct serdes_map
> **serdes_map_array, u8 *count)
> if (IS_ENABLED(CONFIG_CLEARFOG_SFP_25GB))
> board_serdes_map[5].serdes_speed = SERDES_SPEED_3_125_GBPS;
>
> + if (IS_ENABLED(CONFIG_CLEARFOG_CON2_SATA) &&
> + !IS_ENABLED(CONFIG_TARGET_CLEARFOG_BASE)) {
This second condition looks redundant. CONFIG_CLEARFOG_CON2_SATA already
depends on !CONFIG_TARGET_CLEARFOG_BASE at the Kconfig level above.
Looks good to me otherwise.
Have you had a chance to test mSATA?
> + board_serdes_map[4].serdes_type = SATA2;
> + board_serdes_map[4].serdes_speed = SERDES_SPEED_3_GBPS;
> + board_serdes_map[4].serdes_mode = SERDES_DEFAULT_MODE;
> + board_serdes_map[4].swap_rx = 1;
> + }
> +
> + if (IS_ENABLED(CONFIG_CLEARFOG_CON3_SATA)) {
> + board_serdes_map[2].serdes_type = SATA1;
> + board_serdes_map[2].serdes_speed = SERDES_SPEED_3_GBPS;
> + board_serdes_map[2].serdes_mode = SERDES_DEFAULT_MODE;
> + board_serdes_map[2].swap_rx = 1;
> + }
> +
> /* Apply runtime detection changes */
> if (sr_product_is(_tlv_data, "Clearfog GTR")) {
> board_serdes_map[0].serdes_type = PEX0;
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
Re: [PATCH v4 03/12] arm: mvebu: clearfog: use Pro name by default
Hi Joel,
On Mon, Jan 27 2020, Joel Johnson wrote:
> Make the board version printed indicate the Pro variant default.
> Also adjust static name casing to match what is expected for
> EEPROM product name to share string constants.
>
> ---
>
>
> Baruch - can you confirm expected/desired branding casing? The SolidRun
> website and prior to this commit uses "ClearFog", however the EEPROM
> checked values use "Clearfog", so I changed to match to be able to use
> the same string constant values for consistency.
I am fine with this change. The official name is "ClearFog", but you can
also find "Clearfog" in the documentation, for example:
https://developer.solid-run.com/knowledge-base/a388-debian/
baruch
> Signed-off-by: Joel Johnson
> ---
> board/solidrun/clearfog/clearfog.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/board/solidrun/clearfog/clearfog.c
> b/board/solidrun/clearfog/clearfog.c
> index e268ef55a2..9b31902c70 100644
> --- a/board/solidrun/clearfog/clearfog.c
> +++ b/board/solidrun/clearfog/clearfog.c
> @@ -170,7 +170,7 @@ int board_init(void)
>
> int checkboard(void)
> {
> - char *board = "ClearFog";
> + char *board = "Clearfog Pro";
>
> cf_read_tlv_data();
> if (strlen(cf_tlv_data.tlv_product_name[0]) > 0)
--
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 -
Re: [PATCH v4 06/12] arm: mvebu: clearfog: Add option for 2.5 Gbps SFP
Hi Joel,
On Mon, Jan 27 2020, Joel Johnson wrote:
> On 2020-01-26 22:29, Baruch Siach wrote:
>> On Mon, Jan 27 2020, Joel Johnson wrote:
>>> While newer Linux kernels provide autoconfiguration of SFP, provide
>>> an option for setting in U-Boot Kconfig for use prior to booting.
>>>
>>> Signed-off-by: Joel Johnson
>>>
>>> ---
>>>
>>> v2 changes:
>>> - fixed help indentation
>>> v3 changes:
>>> - none
>>> v4 changes:
>>> - adjust static SerDes configuration at runtime instead of #ifdef
>>>
>>> ---
>>> board/solidrun/clearfog/Kconfig| 7 +++
>>> board/solidrun/clearfog/clearfog.c | 3 +++
>>> 2 files changed, 10 insertions(+)
>>>
>>> diff --git a/board/solidrun/clearfog/Kconfig
>>> b/board/solidrun/clearfog/Kconfig
>>> index 936d5918f8..c910e17093 100644
>>> --- a/board/solidrun/clearfog/Kconfig
>>> +++ b/board/solidrun/clearfog/Kconfig
>>> @@ -15,4 +15,11 @@ config TARGET_CLEARFOG_BASE
>>> detection via additional EEPROM hardware. This option enables
>>> selecting
>>> the Base variant for older hardware revisions.
>>>
>>> +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 4019e37016..6c5b9a784f 100644
>>> --- a/board/solidrun/clearfog/clearfog.c
>>> +++ b/board/solidrun/clearfog/clearfog.c
>>> @@ -59,6 +59,9 @@ void config_static_serdes_map(void)
>>> board_serdes_map[4].serdes_speed = SERDES_SPEED_5_GBPS;
>>> board_serdes_map[4].serdes_mode = SERDES_DEFAULT_MODE;
>>> }
>>> +
>>> + if (IS_ENABLED(CONFIG_CLEARFOG_SFP_25GB))
>>> + board_serdes_map[5].serdes_speed = SERDES_SPEED_3_125_GBPS;
>>
>> config_static_serdes_map() is not called only when TLV EEPROM is
>> present. So CONFIG_CLEARFOG_SFP_25GB has no effect in that case. This
>> code should move to hws_board_topology_load() to avoid that.
>
> Yeah, that's what I was trying to ask with the question below embedded in
> patch 4.
>
> "Note that this approach *does not* currently provide any mechanism
> for EEPROM detected boards to have their SFP speed changed or switch
> between PCIE/SATA signalling. I'm assuming that will be done based on
> hardware detection, but confirmation/acceptance in review would be
> appreciated so it can be revisited if needed.
>
> After sending the series and thinking about it more, I didn't see any other
> mechanism by which the configuration would be changed. The question was really
> to confirm what I had inferred from code, namely that Pro/Base boards even
> with EEPROM would still have to have a U-Boot built with custom options in
> order to change the PCIe/SATA or SFP options. I would like to confirm with you
> that is desired and expected even in the cases of EEPROM supporting units. If
> that's the case, I'll rework the location of setting, along with updating the
> help text for those options. Pending your confirmation, I plan to get rid of
> the separate config_static_serdes_map function and fold it back in, with the
> SATA and SFP options coming before the board runtime detection configuration.
My thinking is that EEPROM TLV is only meant to describe the hardware as
manufactured, and never change. SATA (read mSATA) and SFP are user setup
that TLV can't cover. So I think that SATA and SFP build time selection
should apply regardless of TLV.
In theory it could have been even better to store SATA/SFP selection in
environment variables. But that is not currently possible, since serdes
configuration takes place at SPL phase where the environment is not
accessible.
baruch
--
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 -
Re: [PATCH v4 06/12] arm: mvebu: clearfog: Add option for 2.5 Gbps SFP
Hi Joel,
On Mon, Jan 27 2020, Joel Johnson wrote:
> While newer Linux kernels provide autoconfiguration of SFP, provide
> an option for setting in U-Boot Kconfig for use prior to booting.
>
> Signed-off-by: Joel Johnson
>
> ---
>
> v2 changes:
> - fixed help indentation
> v3 changes:
> - none
> v4 changes:
> - adjust static SerDes configuration at runtime instead of #ifdef
>
> ---
> board/solidrun/clearfog/Kconfig| 7 +++
> board/solidrun/clearfog/clearfog.c | 3 +++
> 2 files changed, 10 insertions(+)
>
> diff --git a/board/solidrun/clearfog/Kconfig b/board/solidrun/clearfog/Kconfig
> index 936d5918f8..c910e17093 100644
> --- a/board/solidrun/clearfog/Kconfig
> +++ b/board/solidrun/clearfog/Kconfig
> @@ -15,4 +15,11 @@ config TARGET_CLEARFOG_BASE
> detection via additional EEPROM hardware. This option enables
> selecting
> the Base variant for older hardware revisions.
>
> +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 4019e37016..6c5b9a784f 100644
> --- a/board/solidrun/clearfog/clearfog.c
> +++ b/board/solidrun/clearfog/clearfog.c
> @@ -59,6 +59,9 @@ void config_static_serdes_map(void)
> board_serdes_map[4].serdes_speed = SERDES_SPEED_5_GBPS;
> board_serdes_map[4].serdes_mode = SERDES_DEFAULT_MODE;
> }
> +
> + if (IS_ENABLED(CONFIG_CLEARFOG_SFP_25GB))
> + board_serdes_map[5].serdes_speed = SERDES_SPEED_3_125_GBPS;
config_static_serdes_map() is not called only when TLV EEPROM is
present. So CONFIG_CLEARFOG_SFP_25GB has no effect in that case. This
code should move to hws_board_topology_load() to avoid that.
baruch
> }
>
> int hws_board_topology_load(struct serdes_map **serdes_map_array, u8 *count)
--
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 -
Re: [PATCH 1/2] board: solidrun lx2160a-cex7: new board
Hi Priyanka,
On Thu, Jan 23, 2020 at 09:25:29AM +, Priyanka Jain wrote:
> >-Original Message-
> >From: Baruch Siach
> >Sent: Wednesday, December 4, 2019 6:59 PM
> >To: Priyanka Jain
> >Cc: u-boot@lists.denx.de; Rabeeh Khoury ; Jon
> >Nettleton ; Baruch Siach
> >Subject: [PATCH 1/2] board: solidrun lx2160a-cex7: new board
> >
> >Add board level support code for the SolidRun LX2160A based COM-Express
> >7 system.
> >
> >Signed-off-by: Baruch Siach
> >---
> This patch has below compilation warning. Kindly fix.
>aarch64: + lx2160acex7_tfa
> +board/solidrun/lx2160acex7/lx2160acex7.c: In function 'uart_get_clock':
> +board/solidrun/lx2160acex7/lx2160acex7.c:50:18: error: implicit declaration
> of function 'get_serial_clock'; did you mean 'uart_get_clock'?
> [-Werror=implicit-function-declaration]
> + serial0.clock = get_serial_clock();
> + ^~~~
> + uart_get_clock
> +cc1: all warnings being treated as errors
> +make[2]: *** [board/solidrun/lx2160acex7/lx2160acex7.o] Error 1
> +make[1]: *** [board/solidrun/lx2160acex7] Error 2
> +make: *** [sub-make] Error 2
Thanks for your review.
This build error is because of commit d96c26040e901 ("common: Move clock
functions into a new file"). clock_legacy.h include in now missing. I'll
rebase the patches on current master and post an update.
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
Re: [PATCH v3 03/10] arm: mvebu: clearfog: initial ClearFog Base variant
Hi Joel,
On Wed, Jan 22, 2020 at 07:28:51PM +, Joel Johnson wrote:
> On January 22, 2020 10:32:58 AM UTC, Baruch Siach wrote:
> >On Wed, Jan 22 2020, Joel Johnson wrote:
> >> On 2020-01-21 10:49, Baruch Siach wrote:
> >>> On Tue, Jan 21, 2020 at 10:32:17AM -0700, Joel Johnson wrote:
> >>>> 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
> >>>> v3 changes:
> >>>> - rebased on mvebu merged run-time TLV EEPROM detection series
> >>>> - minor update to help test regarding runtime detection failures
> >>>>
> >>>> ---
> >>>> 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..936d5918f8
> >>>> --- /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 disabled, is not available in hardware, or
> >otherwise
> >>>> fails.
> >>>> +
> >>>> + 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 e268ef55a2..e77b9465d4 100644
> >>>> --- a/board/solidrun/clearfog/clearfog.c
> >>>> +++ b/board/solidrun/clearfog/clearfog.c
> >>>> @@ -47,7 +47,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
> >>>
> >>> I'd prefer run-time test instead of '#ifdefs' that IMO make the code
> >harder
> >>> to
> >>> read. Something like this (build tested only):
> >>>
> >>> diff --git a/board/solidrun/clearfog/clearfog.c
> >>> b/board/solidrun/clearfog/clearfog.c
> >>> index e268ef55a2a0..202c60cb7841 100644
>
Re: [PATCH v3 05/10] arm: mvebu: clearfog: Add SATA mode flags
Hi Joel,
On Tue, Jan 21, 2020 at 10:32:19AM -0700, Joel Johnson wrote:
> 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
> v3 changes:
> - none
>
> ---
> 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 936d5918f8..4e189b13e0 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 086912e400..7046665d6c 100644
> --- a/board/solidrun/clearfog/clearfog.c
> +++ b/board/solidrun/clearfog/clearfog.c
> @@ -45,10 +45,16 @@ static void cf_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},
Have you tested mSATA with this patch?
My testing showed that swap_rx must be set for mSATA. See this pull request:
https://github.com/SolidRun/u-boot/pull/3
To make #ifdef less annoying I would prefer something like this instead (build
tested only):
diff --git a/board/solidrun/clearfog/clearfog.c
b/board/solidrun/clearfog/clearfog.c
index e268ef55a2a0..5bbb7906b681 100644
--- a/board/solidrun/clearfog/clearfog.c
+++ b/board/solidrun/clearfog/clearfog.c
@@ -29,6 +29,12 @@ DECLARE_GLOBAL_DATA_PTR;
#define BOARD_GPP_POL_LOW 0x0
#define BOARD_GPP_POL_MID 0x0
+#if defined (CONFIG_CLEARFOG_CON3_SATA)
+#define SERDES2_CONFIG {SATA1, SERDES_SPEED_3_GBPS, SERDES_DEFAULT_MODE, 1, 0}
+#else
+#define SERDES2_CONFIG {PEX1, SERDES_SPEED_5_GBPS, PEX_ROOT_COMPLEX_X1, 0, 0}
+#endif
+
static struct tlv_data cf_tlv_data;
static void cf_read_tlv_data(void)
@@ -45,7 +51,7 @@ static void cf_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},
- {PEX1, SERDES_SPEED_5_GBPS, PEX_ROOT_COMPLEX_X1, 0, 0},
+ SERDES2_CONFIG,
{USB3_HOST1, SERDES_SPEED_5_GBPS, SERDES_DEFAULT_MODE, 0, 0},
{PEX2, SERDES_SPEED_5_GBPS, PEX_ROOT_COMPLEX_X1, 0, 0},
{SGMII2, SERDES_SPEED_1_25_GBPS, SERDES_DEFAULT_MODE, 0, 0},
baruch
> +#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
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
Re: [PATCH v3 04/10] arm: mvebu: clearfog: Use Pro DT by default
Hi Joel,
On Tue, Jan 21, 2020 at 10:32:18AM -0700, Joel Johnson wrote:
> 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
> v2 changes
> - none
>
> 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 e77b9465d4..086912e400 100644
> --- a/board/solidrun/clearfog/clearfog.c
> +++ b/board/solidrun/clearfog/clearfog.c
> @@ -177,7 +177,7 @@ int checkboard(void)
> #if defined (CONFIG_TARGET_CLEARFOG_BASE)
> char *board = "ClearFog Base";
> #else
> - char *board = "ClearFog";
> + char *board = "ClearFog Pro";
> #endif
>
> cf_read_tlv_data();
> @@ -208,9 +208,11 @@ int board_late_init(void)
> env_set("fdtfile", "armada-385-clearfog-gtr-s4.dtb");
> else if (sr_product_is(_tlv_data, "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");
I'd prefer to keep the default here for backwards compatibility. The kernel
also keeps armada-388-clearfog.dtb. The -pro variant only updates the 'model'
and 'compatible' properties.
Unrelated to that here is another reason to avoid #ifdef. Syntax aware text
editor automatic indentation might fail to see that the second env_set() is in
the 'else' block. We can workaround that by adding braces around the block,
but it's not nice.
baruch
> #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
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
[PATCH v2] genboardscfg.py: drop python version comment
genboardscfg.py requires python 3.x since commit 3bc14098d8fb
("genboardscfg.py: Convert to Python 3").
Cc: Masahiro Yamada
Signed-off-by: Baruch Siach
---
v2: Remove the comment entirely (Masahiro Yamada)
---
tools/genboardscfg.py | 2 --
1 file changed, 2 deletions(-)
diff --git a/tools/genboardscfg.py b/tools/genboardscfg.py
index 24df13e5008d..4f6382bc7ca9 100755
--- a/tools/genboardscfg.py
+++ b/tools/genboardscfg.py
@@ -10,8 +10,6 @@ Converter from Kconfig and MAINTAINERS to a board database.
Run 'tools/genboardscfg.py' to create a board database.
Run 'tools/genboardscfg.py -h' for available options.
-
-Python 2.6 or later, but not Python 3.x is necessary to run this script.
"""
import errno
--
2.24.1
Re: [PATCH v3 03/10] arm: mvebu: clearfog: initial ClearFog Base variant
Hi Joel,
On Wed, Jan 22 2020, Joel Johnson wrote:
> On 2020-01-21 10:49, Baruch Siach wrote:
>> On Tue, Jan 21, 2020 at 10:32:17AM -0700, Joel Johnson wrote:
>>> 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
>>> v3 changes:
>>> - rebased on mvebu merged run-time TLV EEPROM detection series
>>> - minor update to help test regarding runtime detection failures
>>>
>>> ---
>>> 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..936d5918f8
>>> --- /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 disabled, is not available in hardware, or otherwise
>>> fails.
>>> +
>>> + 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 e268ef55a2..e77b9465d4 100644
>>> --- a/board/solidrun/clearfog/clearfog.c
>>> +++ b/board/solidrun/clearfog/clearfog.c
>>> @@ -47,7 +47,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
>>
>> I'd prefer run-time test instead of '#ifdefs' that IMO make the code harder
>> to
>> read. Something like this (build tested only):
>>
>> diff --git a/board/solidrun/clearfog/clearfog.c
>> b/board/solidrun/clearfog/clearfog.c
>> index e268ef55a2a0..202c60cb7841 100644
>> --- a/board/solidrun/clearfog/clearfog.c
>> +++ b/board/solidrun/clearfog/clearfog.c
>> @@ -55,7 +55,8 @@ int hws_board_topology_load(struct serdes_map
>> **serdes_map_array, u8 *count)
>> {
>> cf_read_tlv_data();
>>
>> -if (sr_product_is(_tlv_data, "Clearfog GTR")) {
>> +if (sr_product_is(_tlv_data, "Clearfog GTR") ||
>> +CONFIG_IS_ENABLED(TARGET_CLEARFOG_BASE)) {
>> board_serdes_map[0].serdes_type = PEX0;
>> board_serdes_map[0].serdes_speed = SERDES_SPEED_5_GBPS;
>> board_serdes_map[0].serdes_mode = PEX_ROOT_COMPLEX_X1;
>> @@ -172,6 +173,9 @@ int checkboard(void)
>> {
>> char *board = "ClearFog";
>>
>> +if (CONFIG_IS_ENABLED(TARGET_CLEARFOG_BASE))
>> +board = "ClearFog Base";
>> +
>> cf_read_tlv_data();
>> if (strlen(cf_tlv_data.tlv_pro
Re: [PATCH v3 03/10] arm: mvebu: clearfog: initial ClearFog Base variant
Hi Joel,
On Tue, Jan 21, 2020 at 10:32:17AM -0700, Joel Johnson wrote:
> 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
> v3 changes:
> - rebased on mvebu merged run-time TLV EEPROM detection series
> - minor update to help test regarding runtime detection failures
>
> ---
> 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..936d5918f8
> --- /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 disabled, is not available in hardware, or otherwise
> fails.
> +
> + 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 e268ef55a2..e77b9465d4 100644
> --- a/board/solidrun/clearfog/clearfog.c
> +++ b/board/solidrun/clearfog/clearfog.c
> @@ -47,7 +47,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
I'd prefer run-time test instead of '#ifdefs' that IMO make the code harder to
read. Something like this (build tested only):
diff --git a/board/solidrun/clearfog/clearfog.c
b/board/solidrun/clearfog/clearfog.c
index e268ef55a2a0..202c60cb7841 100644
--- a/board/solidrun/clearfog/clearfog.c
+++ b/board/solidrun/clearfog/clearfog.c
@@ -55,7 +55,8 @@ int hws_board_topology_load(struct serdes_map
**serdes_map_array, u8 *count)
{
cf_read_tlv_data();
- if (sr_product_is(_tlv_data, "Clearfog GTR")) {
+ if (sr_product_is(_tlv_data, "Clearfog GTR") ||
+ CONFIG_IS_ENABLED(TARGET_CLEARFOG_BASE)) {
board_serdes_map[0].serdes_type = PEX0;
board_serdes_map[0].serdes_speed = SERDES_SPEED_5_GBPS;
board_serdes_map[0].serdes_mode = PEX_ROOT_COMPLEX_X1;
@@ -172,6 +173,9 @@ int checkboard(void)
{
char *board = "ClearFog";
+ if (CONFIG_IS_ENABLED(TARGET_CLEARFOG_BASE))
+ board = "ClearFog Base";
+
cf_read_tlv_data();
if (strlen(cf_tlv_data.tlv_product_name[0]) > 0)
board = cf_tlv_data.tlv_product_name[0];
@@ -194,7 +198,8 @@ int board_late_init(void)
{
cf_read_tlv_data();
- if (sr_product_is(_tlv_data, "Clearfog Base"))
+ if (sr_product_is(_tlv_data, "Clearfog Base") ||
+ CONFIG_IS_ENABLED(TARGET_CLEARFOG_BASE))
env_set("fdtfile", "armada-388-clearfog-base.dtb");
else if (sr_product_is(_tlv_data, "Clearfog GTR S4"))
env_set("fdtfile", "armada-385-clearfog-gtr-s4.dtb");
What do you think?
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
Re: [PATCH] genboardscfg.py: fix python version dependency comment
Hi Masahiro Yamada,
On Wed, Jan 22, 2020 at 12:19:31AM +0900, Masahiro Yamada wrote:
> On Mon, Jan 20, 2020 at 9:08 PM Baruch Siach wrote:
> >
> > genboardscfg.py requires python 3.x since commit 3bc14098d8fb
> > ("genboardscfg.py: Convert to Python 3").
> >
> > Cc: Masahiro Yamada
> > Signed-off-by: Baruch Siach
> > ---
> > tools/genboardscfg.py | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/tools/genboardscfg.py b/tools/genboardscfg.py
> > index 24df13e5008d..0c3c8ff403d0 100755
> > --- a/tools/genboardscfg.py
> > +++ b/tools/genboardscfg.py
> > @@ -11,7 +11,7 @@ Run 'tools/genboardscfg.py' to create a board database.
> >
> > Run 'tools/genboardscfg.py -h' for available options.
> >
> > -Python 2.6 or later, but not Python 3.x is necessary to run this script.
> > +Python 3.x is necessary to run this script.
>
>
> An exact version number ("Python 3.0" if it works)
> would be more helpful.
>
> I do not know the number, though...
My neither. The shebang mentions python3 specifically, so I'm not sure this
comment is all that useful. How about we remove the python version comment
entirely?
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
[PATCH v3] cmd: add tlv_eeprom command
Add support for read/write of ONIE "Tlvinfo" EEPROM data format. TLV
stands for Type-Length-Value. The data format is described here:
https://opencomputeproject.github.io/onie/design-spec/hw_requirements.html#board-eeprom-information-format
Based on U-Boot patch from the Open Compute project:
https://github.com/opencomputeproject/onie/blob/ec87e872d46b9805565d2c6124b2f701ef1c07b1/patches/u-boot/common/feature-sys-eeprom-tlv-common.patch
Keep only I2C EEPROM support. Use the generic eeprom driver. Fix
checkpatch issues.
Add support for multiple EEPROM TLV stores on the same system. This is
useful in case of SOM and carrier that both provide ID and hardware
configuration information.
Add option to enable for SPL. This allows selection of RAM configuration
based on EEPROM stored board identification.
Signed-off-by: Baruch Siach
---
v3: Drop custom TRUE/FALSE macros
---
cmd/Kconfig | 14 +
cmd/Makefile |2 +
cmd/tlv_eeprom.c | 1105 ++
include/tlv_eeprom.h | 152 ++
4 files changed, 1273 insertions(+)
create mode 100644 cmd/tlv_eeprom.c
create mode 100644 include/tlv_eeprom.h
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 298feae24d3f..b094f15ee155 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -242,6 +242,20 @@ config CMD_REGINFO
help
Register dump
+config CMD_TLV_EEPROM
+ bool "tlv_eeprom"
+ depends on I2C_EEPROM
+ help
+ Display and program the system EEPROM data block in ONIE Tlvinfo
+ format. TLV stands for Type-Length-Value.
+
+config SPL_CMD_TLV_EEPROM
+ bool "tlv_eeprom for SPL"
+ depends on SPL_I2C_EEPROM
+ select SPL_DRIVERS_MISC_SUPPORT
+ help
+ Read system EEPROM data block in ONIE Tlvinfo format from SPL.
+
endmenu
menu "Boot commands"
diff --git a/cmd/Makefile b/cmd/Makefile
index ecf687d49f38..ddc1368c7aea 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -184,6 +184,8 @@ obj-$(CONFIG_X86) += x86/
obj-$(CONFIG_ARCH_MVEBU) += mvebu/
endif # !CONFIG_SPL_BUILD
+obj-$(CONFIG_$(SPL_)CMD_TLV_EEPROM) += tlv_eeprom.o
+
# core command
obj-y += nvedit.o
diff --git a/cmd/tlv_eeprom.c b/cmd/tlv_eeprom.c
new file mode 100644
index ..211ab2680f81
--- /dev/null
+++ b/cmd/tlv_eeprom.c
@@ -0,0 +1,1105 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * Copyright (C) 2013 Curt Brune
+ * Copyright (C) 2014 Srideep
+ * Copyright (C) 2013 Miles Tseng
+ * Copyright (C) 2014,2016 david_yang
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "tlv_eeprom.h"
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define MAX_TLV_DEVICES2
+
+/* File scope function prototypes */
+static bool is_checksum_valid(u8 *eeprom);
+static int read_eeprom(u8 *eeprom);
+static void show_eeprom(u8 *eeprom);
+static void decode_tlv(struct tlvinfo_tlv *tlv);
+static void update_crc(u8 *eeprom);
+static int prog_eeprom(u8 *eeprom);
+static bool tlvinfo_find_tlv(u8 *eeprom, u8 tcode, int *eeprom_index);
+static bool tlvinfo_delete_tlv(u8 *eeprom, u8 code);
+static bool tlvinfo_add_tlv(u8 *eeprom, int tcode, char *strval);
+static int set_mac(char *buf, const char *string);
+static int set_date(char *buf, const char *string);
+static int set_bytes(char *buf, const char *string, int *converted_accum);
+static void show_tlv_devices(void);
+
+/* Set to 1 if we've read EEPROM into memory */
+static int has_been_read;
+/* The EERPOM contents after being read into memory */
+static u8 eeprom[TLV_INFO_MAX_LEN];
+
+static struct udevice *tlv_devices[MAX_TLV_DEVICES];
+static unsigned int current_dev;
+
+#define to_header(p) ((struct tlvinfo_header *)p)
+#define to_entry(p) ((struct tlvinfo_tlv *)p)
+
+#define HDR_SIZE sizeof(struct tlvinfo_header)
+#define ENT_SIZE sizeof(struct tlvinfo_tlv)
+
+static inline bool is_digit(char c)
+{
+ return (c >= '0' && c <= '9');
+}
+
+/**
+ * is_valid_tlv
+ *
+ * Perform basic sanity checks on a TLV field. The TLV is pointed to
+ * by the parameter provided.
+ * 1. The type code is not reserved (0x00 or 0xFF)
+ */
+static inline bool is_valid_tlv(struct tlvinfo_tlv *tlv)
+{
+ return((tlv->type != 0x00) && (tlv->type != 0xFF));
+}
+
+/**
+ * is_hex
+ *
+ * Tests if character is an ASCII hex digit
+ */
+static inline u8 is_hex(char p)
+{
+ return (((p >= '0') && (p <= '9')) ||
+ ((p >= 'A') && (p <= 'F')) ||
+ ((p >= 'a') && (p <= 'f')));
+}
+
+/**
+ * is_checksum_valid
+ *
+ * Validate the checksum in the provided TlvInfo EEPROM data. First,
+ * verify that the TlvInfo header is valid, then make sure the last
+ * TLV is a CRC-32 TLV. Then calculate the CRC over the EEPROM data
+ * and compare it to the value store
Re: Please pull u-boot-marvell/master
Hi Stefan,
On Tue, Jan 21, 2020 at 02:19:19PM +0100, Stefan Roese wrote:
> Added Baruch to Cc
>
> On 21.01.20 14:11, Tom Rini wrote:
> > On Tue, Jan 21, 2020 at 02:03:57PM +0100, Stefan Roese wrote:
> > > Hi Tom,
> > >
> > > please pull the 2nd batch of MVEBU related patches in this merge
> > > window:
> > >
> > >
> > > - Clearfog: Add run-time board detection with TLV EEPROM support
> > >(Baruch)
> > >
> > >
> > > Here the Travis build, without any issues:
> > >
> > > https://travis-ci.org/stroese/u-boot/builds/639823471
> > >
> > > Thanks,
> > > Stefan
> > >
> > >
> > > The following changes since commit
> > > c7819d409ab7671991bf906482b7adcc21266f75:
> > >
> > >Merge branch '2020-01-17-reduce-size-of-common-h-even-more'
> > > (2020-01-20 12:23:33 -0500)
> > >
> > > are available in the Git repository at:
> > >
> > >g...@gitlab.denx.de:u-boot/custodians/u-boot-marvell.git
> > >
> > > for you to fetch changes up to 5bc0175286469c3fd63a7b17264bbcf99adfecc4:
> > >
> > >ARM: mvebu: clearfog: add Clearfog Base serdes configuration
> > > (2020-01-21 08:41:00 +0100)
> > >
> > >
> > > Baruch Siach (10):
> > >ddr: marvell: a38x: allow board specific clock out setup
> > >arm: mvebu: clearfog: enable both DDR clocks
> > >cmd: add tlv_eeprom command
> > >ARM: mvebu: clearfog: add EEPROM devices
> > >ARM: mvebu: clearfog: add support for EEPROM TLV info
> > >ARM: mvebu: clearfog: read basic TLV data
> > >ARM: mvebu: clearfog: print TLV stored product name
> > >ARM: mvebu: clearfog: run-time selection of DT file
> > >ARM: mvebu: clearfog: add Clearfog GTR support
> > >ARM: mvebu: clearfog: add Clearfog Base serdes configuration
> > >
> > > arch/arm/dts/armada-388-clearfog-u-boot.dtsi | 12 +
> > > arch/arm/dts/armada-388-clearfog.dts |6 +
> > > arch/arm/dts/armada-38x-solidrun-microsom.dtsi |8 +
> > > arch/arm/mach-mvebu/Kconfig|1 +
> > > board/solidrun/clearfog/clearfog.c | 72 +-
> > > board/solidrun/common/Makefile |5 +
> > > board/solidrun/common/tlv_data.c | 102 +++
> > > board/solidrun/common/tlv_data.h | 18 +
> > > cmd/Kconfig| 14 +
> > > cmd/Makefile |2 +
> > > cmd/tlv_eeprom.c | 1105
> > >
> > > configs/clearfog_defconfig |4 +
> > > drivers/ddr/marvell/a38x/ddr3_training.c | 10 +-
> > > drivers/ddr/marvell/a38x/ddr_topology_def.h|3 +
> > > include/tlv_eeprom.h | 164
> >
> > This header defines TRUE/FALSE and we don't need that, we have
> > true/false just fine for a long while now. Please fix, thanks.
>
> Baruch, could you please take a look?
No problem.
Would you like me to post the entire series again? Or maybe just add an
incremental patch, or a patch replacing the "cmd: add tlv_eeprom command"
commit?
Thanks,
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
Re: [PATCH 0/4] Updates for ClearFog EEPROM
Hi Joel,
On Sun, Jan 19 2020, Joel Johnson wrote:
> On 2020-01-19 01:41, Baruch Siach wrote:
>> On Sun, Jan 19 2020, Joel Johnson wrote:
>>> On 2020-01-19 00:22, Baruch Siach wrote:
>>>> 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?
>>
>> I hope to have TLV EEPROM ready for v2020.04.
>
> Hmm, I was hoping to have the static config for ClearFog Base merged in the
> current merge window, so just to be clear is that what you're targeting by
> v2020.04 as well?
Yes. Code merged in this merge windows will appear in the next release
which is v2020.04.
I have just posted the updated series with your fixes squashed in,
sometimes in a different form (like the non CMD_TLV_EEPROM build fix).
> With my recent rebasing, I believe I made the changes compatible between
> static and runtime configuration, but it's less important what order they're
> applied in - i.e. I can rebase again back on master and retain the
> alignment. Perhaps it would be possible to merge the static changes and then
> update the static config entries' help text with a subsequent merge of your
> runtime work?
I'm not sure what you mean hear.
baruch
--
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 v2 03/10] cmd: add tlv_eeprom command
Add support for read/write of ONIE "Tlvinfo" EEPROM data format. TLV
stands for Type-Length-Value. The data format is described here:
https://opencomputeproject.github.io/onie/design-spec/hw_requirements.html#board-eeprom-information-format
Based on U-Boot patch from the Open Compute project:
https://github.com/opencomputeproject/onie/blob/ec87e872d46b9805565d2c6124b2f701ef1c07b1/patches/u-boot/common/feature-sys-eeprom-tlv-common.patch
Keep only I2C EEPROM support. Use the generic eeprom driver. Fix
checkpatch issues.
Add support for multiple EEPROM TLV stores on the same system. This is
useful in case of SOM and carrier that both provide ID and hardware
configuration information.
Add option to enable for SPL. This allows selection of RAM configuration
based on EEPROM stored board identification.
Signed-off-by: Baruch Siach
---
cmd/Kconfig | 14 +
cmd/Makefile |2 +
cmd/tlv_eeprom.c | 1105 ++
include/tlv_eeprom.h | 164 +++
4 files changed, 1285 insertions(+)
create mode 100644 cmd/tlv_eeprom.c
create mode 100644 include/tlv_eeprom.h
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 298feae24d3f..b094f15ee155 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -242,6 +242,20 @@ config CMD_REGINFO
help
Register dump
+config CMD_TLV_EEPROM
+ bool "tlv_eeprom"
+ depends on I2C_EEPROM
+ help
+ Display and program the system EEPROM data block in ONIE Tlvinfo
+ format. TLV stands for Type-Length-Value.
+
+config SPL_CMD_TLV_EEPROM
+ bool "tlv_eeprom for SPL"
+ depends on SPL_I2C_EEPROM
+ select SPL_DRIVERS_MISC_SUPPORT
+ help
+ Read system EEPROM data block in ONIE Tlvinfo format from SPL.
+
endmenu
menu "Boot commands"
diff --git a/cmd/Makefile b/cmd/Makefile
index ecf687d49f38..ddc1368c7aea 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -184,6 +184,8 @@ obj-$(CONFIG_X86) += x86/
obj-$(CONFIG_ARCH_MVEBU) += mvebu/
endif # !CONFIG_SPL_BUILD
+obj-$(CONFIG_$(SPL_)CMD_TLV_EEPROM) += tlv_eeprom.o
+
# core command
obj-y += nvedit.o
diff --git a/cmd/tlv_eeprom.c b/cmd/tlv_eeprom.c
new file mode 100644
index ..71ce96ffc4ee
--- /dev/null
+++ b/cmd/tlv_eeprom.c
@@ -0,0 +1,1105 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * Copyright (C) 2013 Curt Brune
+ * Copyright (C) 2014 Srideep
+ * Copyright (C) 2013 Miles Tseng
+ * Copyright (C) 2014,2016 david_yang
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "tlv_eeprom.h"
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define MAX_TLV_DEVICES2
+
+/* File scope function prototypes */
+static bool is_checksum_valid(u8 *eeprom);
+static int read_eeprom(u8 *eeprom);
+static void show_eeprom(u8 *eeprom);
+static void decode_tlv(struct tlvinfo_tlv *tlv);
+static void update_crc(u8 *eeprom);
+static int prog_eeprom(u8 *eeprom);
+static bool tlvinfo_find_tlv(u8 *eeprom, u8 tcode, int *eeprom_index);
+static bool tlvinfo_delete_tlv(u8 *eeprom, u8 code);
+static bool tlvinfo_add_tlv(u8 *eeprom, int tcode, char *strval);
+static int set_mac(char *buf, const char *string);
+static int set_date(char *buf, const char *string);
+static int set_bytes(char *buf, const char *string, int *converted_accum);
+static void show_tlv_devices(void);
+
+/* Set to 1 if we've read EEPROM into memory */
+static int has_been_read;
+/* The EERPOM contents after being read into memory */
+static u8 eeprom[TLV_INFO_MAX_LEN];
+
+static struct udevice *tlv_devices[MAX_TLV_DEVICES];
+static unsigned int current_dev;
+
+#define to_header(p) ((struct tlvinfo_header *)p)
+#define to_entry(p) ((struct tlvinfo_tlv *)p)
+
+#define HDR_SIZE sizeof(struct tlvinfo_header)
+#define ENT_SIZE sizeof(struct tlvinfo_tlv)
+
+static inline bool is_digit(char c)
+{
+ return (c >= '0' && c <= '9');
+}
+
+/**
+ * is_valid_tlv
+ *
+ * Perform basic sanity checks on a TLV field. The TLV is pointed to
+ * by the parameter provided.
+ * 1. The type code is not reserved (0x00 or 0xFF)
+ */
+static inline bool is_valid_tlv(struct tlvinfo_tlv *tlv)
+{
+ return((tlv->type != 0x00) && (tlv->type != 0xFF));
+}
+
+/**
+ * is_hex
+ *
+ * Tests if character is an ASCII hex digit
+ */
+static inline u8 is_hex(char p)
+{
+ return (((p >= '0') && (p <= '9')) ||
+ ((p >= 'A') && (p <= 'F')) ||
+ ((p >= 'a') && (p <= 'f')));
+}
+
+/**
+ * is_checksum_valid
+ *
+ * Validate the checksum in the provided TlvInfo EEPROM data. First,
+ * verify that the TlvInfo header is valid, then make sure the last
+ * TLV is a CRC-32 TLV. Then calculate the CRC over the EEPROM data
+ * and compare it to the value stored in the EEPROM CRC-32 TLV.
+ */
+st
