Re: [PATCH v3 2/2] serial: mxc: Speed-up character transmission
On Wed, 11 Jan 2023 at 00:55, Pali Rohár wrote:
>
> On Tuesday 10 January 2023 20:24:07 Loic Poulain wrote:
> > Instead of waiting for empty FIFO condition before writing a
> > character, wait for non-full FIFO condition.
> >
> > This helps in saving several tens of milliseconds during boot
> > (depending verbosity).
> >
> > Signed-off-by: Loic Poulain
> > Tested-by: Lothar Waßmann
> > ---
> > v2: fixing transfert abort & char corruption commit
> > v3: Reordering commits for good bisectability
> >
> > drivers/serial/serial_mxc.c | 8
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/serial/serial_mxc.c b/drivers/serial/serial_mxc.c
> > index 3c89781f2c..9899155c00 100644
> > --- a/drivers/serial/serial_mxc.c
> > +++ b/drivers/serial/serial_mxc.c
> > @@ -238,11 +238,11 @@ static void mxc_serial_putc(const char c)
> > if (c == '\n')
> > serial_putc('\r');
> >
> > - writel(c, _base->txd);
> > -
> > /* wait for transmitter to be ready */
> > - while (!(readl(_base->ts) & UTS_TXEMPTY))
> > + while (readl(_base->ts) & UTS_TXFULL)
> > schedule();
> > +
> > + writel(c, _base->txd);
> > }
> >
> > /* Test whether a character is in the RX buffer */
> > @@ -333,7 +333,7 @@ static int mxc_serial_putc(struct udevice *dev, const
> > char ch)
> > struct mxc_serial_plat *plat = dev_get_plat(dev);
> > struct mxc_uart *const uart = plat->reg;
> >
> > - if (!(readl(>ts) & UTS_TXEMPTY))
> > + if (readl(>ts) & UTS_TXFULL)
> > return -EAGAIN;
> >
> > writel(ch, >txd);
> > --
> > 2.34.1
> >
>
> Hello!
>
> In this driver there are two mxc_serial_putc() and two mxc_serial_getc()
> function. One for DM and one for non-DM version. It would be really nice
> to fix also second set of functions.
This commit changes both DM/non-DM putc() functions.
Regards,
Loic
Re: [PATCH v3 1/2] serial: mxc: Wait for TX completion before reset
On Wed, 11 Jan 2023 at 00:53, Pali Rohár wrote:
>
> On Tuesday 10 January 2023 20:24:06 Loic Poulain wrote:
> > The u-boot console may show some corrupted characters when
> > printing in board_init() due to reset of the UART (probe)
> > before the TX FIFO has been completely drained.
> >
> > To fix this issue, and in case UART is still running, we now
> > try to flush the FIFO before proceeding to UART reinitialization.
> > For this we're waiting for Transmitter Complete bit, indicating
> > that the FIFO and the shift register are empty.
> >
> > flushing has a 4ms timeout guard, which is normally more than
> > enough to consume the FIFO @ low baudrate (9600bps).
> >
> > Signed-off-by: Loic Poulain
> > Tested-by: Lothar Waßmann
>
> Hello! Last time when I looked at this driver I was in impression that
> also _mxc_serial_setbrg() function requires calling some flush function
> at the beginning. Could you please check if it is needed or not? I'm
> really not sure.
_mxc_serial_setbrg is usually called after init, which now includes that flush.
>
> > ---
> > v2: Add this commit to the series
> > v3: Fix typo & reordering commits for good bisectability
> >
> > drivers/serial/serial_mxc.c | 24 +++-
> > 1 file changed, 23 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/serial/serial_mxc.c b/drivers/serial/serial_mxc.c
> > index 82c0d84628..3c89781f2c 100644
> > --- a/drivers/serial/serial_mxc.c
> > +++ b/drivers/serial/serial_mxc.c
> > @@ -13,6 +13,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > /* UART Control Register Bit Fields.*/
> > #define URXD_CHARRDY (1<<15)
> > @@ -144,8 +145,22 @@ struct mxc_uart {
> > u32 ts;
> > };
> >
> > +static void _mxc_serial_flush(struct mxc_uart *base)
> > +{
> > + unsigned int timeout = 4000;
> > +
> > + if (!(readl(>cr1) & UCR1_UARTEN) ||
> > + !(readl(>cr2) & UCR2_TXEN))
> > + return;
> > +
> > + while (!(readl(>sr2) & USR2_TXDC) && --timeout)
> > + udelay(1);
> > +}
> > +
> > static void _mxc_serial_init(struct mxc_uart *base, int use_dte)
> > {
> > + _mxc_serial_flush(base);
> > +
> > writel(0, >cr1);
> > writel(0, >cr2);
> >
> > @@ -252,10 +267,17 @@ static int mxc_serial_init(void)
> > return 0;
> > }
> >
> > +static int mxc_serial_stop(void)
> > +{
> > + _mxc_serial_flush(mxc_base);
> > +
> > + return 0;
> > +}
> > +
> > static struct serial_device mxc_serial_drv = {
> > .name = "mxc_serial",
> > .start = mxc_serial_init,
> > - .stop = NULL,
> > + .stop = mxc_serial_stop,
> > .setbrg = mxc_serial_setbrg,
> > .putc = mxc_serial_putc,
> > .puts = default_serial_puts,
>
> Anyway, this code touches _only_ non-DM version of the driver. So same
> fix should be implemented also for DM version because non-DM is now
> legacy and will be removed in the future from U-Boot. Please look at the
> DM version too.
This code impacts both DM and non-DM, as _mxc_serial_init is a common version,
and was the main issue (several init() leading to corrupted char).
Regards,
Loic
Re: [PATCH v2 3/3] lmb: consider EFI memory map
On 1/11/23 01:15, Simon Glass wrote: Hi Heinrich, On Mon, 9 Jan 2023 at 13:53, Heinrich Schuchardt wrote: On 1/9/23 21:31, Simon Glass wrote: Hi Mark, On Mon, 9 Jan 2023 at 13:20, Mark Kettenis wrote: From: Simon Glass Date: Mon, 9 Jan 2023 13:11:01 -0700 Hi Heinrich, We need to fix how EFI does addresses. It seems to use them as pointers but store them as u64 ? That is similar to what you have been doing with physical addresses. They're defined to a 64-bit unsigned integer by the UEFI specification, so you can't change it. I don't mean changing the spec, just changing the internal U-Boot implementation, which is very confusing. This confusion is spreading out, too. Regards, Simon The real interesting thing is how memory should be managed in U-Boot: I would prefer to create a shared global memory management on 4KiB page level used both for EFI and the rest of U-Boot. Sounds good. What EFI adds to the requirements is that you need more than free (EfiConventionalMemory) and used memory. EFI knows 16 different types of memory usage (see enum efi_memory_type). That's a shame. How much of this is legacy and how much is useful? When loading a file (e.g. with the "load" command) this should lead to a memory reservation. You should not be able to load a second file into an overlapping memory area without releasing the allocated memory first. This would replace lmb which currently tries to recalculate available memory ab initio again and again. With managed memory we should be able to get rid of all those constants like $loadaddr, $fdt_addr_r, $kernel_addr_r, etc. and instead use a register of named loaded files. This is where standard boot comes in, since it knows what it has loaded and has pointers to it. I see a future where we don't use these commands when we want to save space. It can save 300KB from the U-Boot size. But this really has to come later, since there is so much churn already! For now, please don't add EFI allocation into lmb..that is just odd. It is not odd but necessary. Without it the Odroid C2 does not boot but crashes. Best regards Heinrich
Re: [PATCH] i2c: mxc_i2c: Use hex notation for the base address
Hello Fabio, On 03.01.23 20:03, Fabio Estevam wrote: > Printing the I2C controller base address in decimal notation > is not helpful. > > Change it to hex notation, which is the standard format found > in the Reference Manual and devicetree. > > Signed-off-by: Fabio Estevam > --- > drivers/i2c/mxc_i2c.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Heiko Schocher Thanks! bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de
Re: [PATCH v2 1/1] i2c:aspeed:support ast2600 i2c new register mode driver
Hello Ryan,
On 11.01.23 07:52, ryan_chen wrote:
> Add i2c new register mode driver to support AST2600 i2c
> new register mode. AST2600 i2c controller have legacy and
> new register mode. The new register mode have global register
> support 4 base clock for scl clock selection, and new clock
> divider mode.
>
> Signed-off-by: ryan_chen
> ---
> MAINTAINERS | 6 +
> drivers/i2c/Kconfig | 10 +
> drivers/i2c/Makefile | 1 +
> drivers/i2c/ast2600_i2c.c | 375 ++
> drivers/i2c/ast2600_i2c.h | 120
> 5 files changed, 512 insertions(+)
> create mode 100644 drivers/i2c/ast2600_i2c.c
> create mode 100644 drivers/i2c/ast2600_i2c.h
Nitpick, please add a change log, what have changes from v1 -> v2
as described here:
https://u-boot.readthedocs.io/en/latest/develop/sending_patches.html#sending-updated-patch-versions
You may want to use patman tool, see:
https://u-boot.readthedocs.io/en/latest/develop/patman.html
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 3fc4cd0f12..1cf54f0b4e 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -769,6 +769,12 @@ S: Maintained
> F: drivers/pci/pcie_phytium.c
> F: arch/arm/dts/phytium-durian.dts
>
> +ASPEED AST2600 I2C DRIVER
> +M: Ryan Chen
> +R: Aspeed BMC SW team
> +S: Maintained
> +F: drivers/i2c/ast2600_i2c.c
> +
> ASPEED FMC SPI DRIVER
> M: Chin-Ting Kuo
> M: Cédric Le Goater
> diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig
> index 08b6c7bdcc..77e2a1c4c0 100644
> --- a/drivers/i2c/Kconfig
> +++ b/drivers/i2c/Kconfig
> @@ -221,6 +221,16 @@ config SYS_I2C_DW
> controller is used in various SoCs, e.g. the ST SPEAr, Altera
> SoCFPGA, Synopsys ARC700 and some Intel x86 SoCs.
>
> +config SYS_I2C_AST2600
> +bool "AST2600 I2C Controller"
> +depends on DM_I2C && ARCH_ASPEED
> +help
> + Say yes here to select AST2600 I2C Host Controller. The driver
> + support AST2600 I2C new mode register. This I2C controller supports:
> + _Standard-mode (up to 100 kHz)
> + _Fast-mode (up to 400 kHz)
> + _Fast-mode Plus (up to 1 MHz)
Please use minus instead underline.
> +
> config SYS_I2C_ASPEED
> bool "Aspeed I2C Controller"
> depends on DM_I2C && ARCH_ASPEED
> diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile
> index 920aafb91c..89db2d8e37 100644
> --- a/drivers/i2c/Makefile
> +++ b/drivers/i2c/Makefile
> @@ -12,6 +12,7 @@ obj-$(CONFIG_$(SPL_)I2C_CROS_EC_LDO) += cros_ec_ldo.o
>
> obj-$(CONFIG_$(SPL_)SYS_I2C_LEGACY) += i2c_core.o
> obj-$(CONFIG_SYS_I2C_ASPEED) += ast_i2c.o
> +obj-$(CONFIG_SYS_I2C_AST2600) += ast2600_i2c.o
> obj-$(CONFIG_SYS_I2C_AT91) += at91_i2c.o
> obj-$(CONFIG_SYS_I2C_CADENCE) += i2c-cdns.o
> obj-$(CONFIG_SYS_I2C_CA) += i2c-cortina.o
> diff --git a/drivers/i2c/ast2600_i2c.c b/drivers/i2c/ast2600_i2c.c
> new file mode 100644
> index 00..0fad30b5a2
> --- /dev/null
> +++ b/drivers/i2c/ast2600_i2c.c
> @@ -0,0 +1,375 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright ASPEED Technology Inc.
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include "ast2600_i2c.h"
> +
> +/* Device private data */
> +struct ast2600_i2c_priv {
> + struct clk clk;
> + struct ast2600_i2c_regs *regs;
> + void __iomem *global;
> +};
> +
> +static int ast2600_i2c_read_data(struct ast2600_i2c_priv *priv, u8 chip_addr,
> + u8 *buffer, size_t len, bool send_stop)
> +{
> + int rx_cnt, ret = 0;
> + u32 cmd, isr;
> +
> + for (rx_cnt = 0; rx_cnt < len; rx_cnt++, buffer++) {
> + cmd = I2CM_PKT_EN | I2CM_PKT_ADDR(chip_addr) |
> + I2CM_RX_CMD;
> + if (!rx_cnt)
> + cmd |= I2CM_START_CMD;
> +
> + if ((len - 1) == rx_cnt)
> + cmd |= I2CM_RX_CMD_LAST;
> +
> + if (send_stop && ((len - 1) == rx_cnt))
> + cmd |= I2CM_STOP_CMD;
> +
> + writel(cmd, >regs->cmd_sts);
> +
> + ret = readl_poll_timeout(>regs->isr, isr,
> + isr & I2CM_PKT_DONE,
> + I2C_TIMEOUT_US);
> + if (ret)
> + return -ETIMEDOUT;
> +
> + *buffer =
> + I2CC_GET_RX_BUFF(readl(>regs->trx_buff));
> +
> + writel(I2CM_PKT_DONE, >regs->isr);
> +
> + if (isr & I2CM_TX_NAK)
> + return -EREMOTEIO;
> + }
> +
> + return 0;
> +}
> +
> +static int ast2600_i2c_write_data(struct ast2600_i2c_priv *priv, u8
> chip_addr,
> + u8 *buffer, size_t len, bool send_stop)
> +{
> + int tx_cnt, ret = 0;
> + u32 cmd, isr;
> +
> + if (!len) {
> + cmd = I2CM_PKT_EN | I2CM_PKT_ADDR(chip_addr) |
> +
[PATCH V2 6/6] nvmem: u-boot-env: post process "ethaddr" env variable
From: Rafał Miłecki
U-Boot environment variables are stored in ASCII format so "ethaddr"
requires parsing into binary to make it work with Ethernet interfaces.
This includes support for indexes to support #nvmem-cell-cells = <1>.
Signed-off-by: Rafał Miłecki
---
drivers/nvmem/layouts/Kconfig | 1 +
drivers/nvmem/layouts/u-boot-env.c | 25 +
2 files changed, 26 insertions(+)
diff --git a/drivers/nvmem/layouts/Kconfig b/drivers/nvmem/layouts/Kconfig
index 8a38c514943a..566b4f25630d 100644
--- a/drivers/nvmem/layouts/Kconfig
+++ b/drivers/nvmem/layouts/Kconfig
@@ -23,6 +23,7 @@ config NVMEM_LAYOUT_ONIE_TLV
config NVMEM_LAYOUT_U_BOOT_ENV
bool "U-Boot environment variables support"
select CRC32
+ select GENERIC_NET_UTILS
help
U-Boot stores its setup as environment variables. This driver adds
support for verifying & exporting such data. It also exposes variables
diff --git a/drivers/nvmem/layouts/u-boot-env.c
b/drivers/nvmem/layouts/u-boot-env.c
index 95c314553952..e99b853a44c4 100644
--- a/drivers/nvmem/layouts/u-boot-env.c
+++ b/drivers/nvmem/layouts/u-boot-env.c
@@ -4,6 +4,8 @@
*/
#include
+#include
+#include
#include
#include
#include
@@ -36,6 +38,27 @@ struct u_boot_env_image_broadcom {
uint8_t data[];
} __packed;
+static int u_boot_env_read_post_process_ethaddr(void *context, const char *id,
int index,
+ unsigned int offset, void
**data, size_t *bytes)
+{
+ u8 mac[ETH_ALEN];
+
+ if (*bytes != 3 * ETH_ALEN - 1)
+ return -EINVAL;
+
+ if (!mac_pton(*data, mac))
+ return -EINVAL;
+
+ if (index)
+ eth_addr_add(mac, index);
+
+ /* We need *smaller* buffer so don't bother to krealloc() */
+ ether_addr_copy(*data, mac);
+ *bytes = ETH_ALEN;
+
+ return 0;
+}
+
static int u_boot_env_parse_data(struct device *dev, struct nvmem_device
*nvmem, uint8_t *buf,
size_t data_offset, size_t data_len)
{
@@ -67,6 +90,8 @@ static int u_boot_env_parse_data(struct device *dev, struct
nvmem_device *nvmem,
info.offset = data_offset + value - data;
info.bytes = strlen(value);
info.np = of_get_child_by_name(np, info.name);
+ if (!strcmp(var, "ethaddr"))
+ info.read_post_process =
u_boot_env_read_post_process_ethaddr;
err = nvmem_add_one_cell(nvmem, );
if (err) {
--
2.34.1
[PATCH V2 4/6] nvmem: u-boot-env: convert to layout driver
From: Rafał Miłecki
U-Boot environment variables can be found on various NVMEM devices (not
just MTD) so convert this driver to a generic layout one.
This way - thanks to using NVMEM generic API - this driver can be reused
in other scenarios.
For backward DT compatibility we need to support the old compatible
brinding string for now. Luckily it's just a one line of code.
Signed-off-by: Rafał Miłecki
---
MAINTAINERS| 2 +-
drivers/mtd/mtdcore.c | 7 +-
drivers/nvmem/Kconfig | 14 +-
drivers/nvmem/Makefile | 2 -
drivers/nvmem/layouts/Kconfig | 10 ++
drivers/nvmem/layouts/Makefile | 1 +
drivers/nvmem/layouts/u-boot-env.c | 176 ++
drivers/nvmem/u-boot-env.c | 233 -
8 files changed, 199 insertions(+), 246 deletions(-)
create mode 100644 drivers/nvmem/layouts/u-boot-env.c
delete mode 100644 drivers/nvmem/u-boot-env.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 2e13ee875c77..ace29081c613 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -21137,7 +21137,7 @@ U-BOOT ENVIRONMENT VARIABLES
M: Rafał Miłecki
S: Maintained
F: Documentation/devicetree/bindings/nvmem/layouts/u-boot,env.yaml
-F: drivers/nvmem/u-boot-env.c
+F: drivers/nvmem/layouts/u-boot-env.c
UACCE ACCELERATOR FRAMEWORK
M: Zhangfei Gao
diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
index 0feacb9fbdac..621e0b87b781 100644
--- a/drivers/mtd/mtdcore.c
+++ b/drivers/mtd/mtdcore.c
@@ -518,6 +518,11 @@ static int mtd_nvmem_add(struct mtd_info *mtd)
{
struct device_node *node = mtd_get_of_node(mtd);
struct nvmem_config config = {};
+ bool use_dev_of_node = false;
+
+ if (of_device_is_compatible(node, "nvmem-cells") ||
+ (IS_ENABLED(CONFIG_NVMEM_U_BOOT_ENV) &&
of_device_is_compatible(node, "brcm,env")))
+ use_dev_of_node = true;
config.id = -1;
config.dev = >dev;
@@ -530,7 +535,7 @@ static int mtd_nvmem_add(struct mtd_info *mtd)
config.read_only = true;
config.root_only = true;
config.ignore_wp = true;
- config.no_of_node = !of_device_is_compatible(node, "nvmem-cells");
+ config.no_of_node = !use_dev_of_node;
config.priv = mtd;
mtd->nvmem = nvmem_register();
diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
index 0e10b5b094b9..980734ba8ddc 100644
--- a/drivers/nvmem/Kconfig
+++ b/drivers/nvmem/Kconfig
@@ -327,17 +327,13 @@ config NVMEM_SUNXI_SID
will be called nvmem_sunxi_sid.
config NVMEM_U_BOOT_ENV
- tristate "U-Boot environment variables support"
+ bool "U-Boot environment variables deprecated binding support"
depends on OF && MTD
- select CRC32
+ select NVMEM_LAYOUT_U_BOOT_ENV
help
- U-Boot stores its setup as environment variables. This driver adds
- support for verifying & exporting such data. It also exposes variables
- as NVMEM cells so they can be referenced by other drivers.
-
- Currently this drivers works only with env variables on top of MTD.
-
- If compiled as module it will be called nvmem_u-boot-env.
+ This option enables support for deprecated DT binding for U-Boot
+ environment variables. It was used by DT files before introducing
+ nvmem-layout node based syntax.
config NVMEM_UNIPHIER_EFUSE
tristate "UniPhier SoCs eFuse support"
diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
index 4cf87ef6c24d..3b827ce96f6d 100644
--- a/drivers/nvmem/Makefile
+++ b/drivers/nvmem/Makefile
@@ -66,8 +66,6 @@ obj-$(CONFIG_NVMEM_SUNPLUS_OCOTP) += nvmem_sunplus_ocotp.o
nvmem_sunplus_ocotp-y := sunplus-ocotp.o
obj-$(CONFIG_NVMEM_SUNXI_SID) += nvmem_sunxi_sid.o
nvmem_sunxi_sid-y := sunxi_sid.o
-obj-$(CONFIG_NVMEM_U_BOOT_ENV) += nvmem_u-boot-env.o
-nvmem_u-boot-env-y := u-boot-env.o
obj-$(CONFIG_NVMEM_UNIPHIER_EFUSE) += nvmem-uniphier-efuse.o
nvmem-uniphier-efuse-y := uniphier-efuse.o
obj-$(CONFIG_NVMEM_VF610_OCOTP)+= nvmem-vf610-ocotp.o
diff --git a/drivers/nvmem/layouts/Kconfig b/drivers/nvmem/layouts/Kconfig
index 9ad50474cb77..8a38c514943a 100644
--- a/drivers/nvmem/layouts/Kconfig
+++ b/drivers/nvmem/layouts/Kconfig
@@ -20,4 +20,14 @@ config NVMEM_LAYOUT_ONIE_TLV
If unsure, say N.
+config NVMEM_LAYOUT_U_BOOT_ENV
+ bool "U-Boot environment variables support"
+ select CRC32
+ help
+ U-Boot stores its setup as environment variables. This driver adds
+ support for verifying & exporting such data. It also exposes variables
+ as NVMEM cells so they can be referenced by other drivers.
+
+ If unsure, say N.
+
endmenu
diff --git a/drivers/nvmem/layouts/Makefile b/drivers/nvmem/layouts/Makefile
index 2974bd7d33ed..4940c9db0665
[PATCH V2 5/6] dt-bindings: nvmem: u-boot, env: add MAC's #nvmem-cell-cells
From: Rafał Miłecki
U-Boot's "ethaddr" environment variable is very often used to store
*base* MAC address. It's used as a base for calculating addresses for
multiple interfaces. It's done by adding proper values. Actual offsets
are picked by manufacturers and vary across devices.
Signed-off-by: Rafał Miłecki
---
.../devicetree/bindings/nvmem/layouts/u-boot,env.yaml | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/nvmem/layouts/u-boot,env.yaml
b/Documentation/devicetree/bindings/nvmem/layouts/u-boot,env.yaml
index fb273b174fe7..dbff702f2e5d 100644
--- a/Documentation/devicetree/bindings/nvmem/layouts/u-boot,env.yaml
+++ b/Documentation/devicetree/bindings/nvmem/layouts/u-boot,env.yaml
@@ -45,7 +45,11 @@ properties:
ethaddr:
type: object
-description: Ethernet interface's MAC address
+description: Ethernet interfaces base MAC address.
+properties:
+ "#nvmem-cell-cells":
+description: The first argument is a MAC address offset.
+const: 1
additionalProperties: false
@@ -69,6 +73,7 @@ examples:
compatible = "u-boot,env";
mac: ethaddr {
+#nvmem-cell-cells = <1>;
};
};
};
--
2.34.1
[PATCH V2 3/6] dt-bindings: nvmem: convert U-Boot env vars to NVMEM layout
From: Rafał Miłecki
U-Boot environment variables can be found of various underlaying storage
entities. This binding should be defined as a layout on top on NVMEM
device not a NVMEM device itself.
Signed-off-by: Rafał Miłecki
---
.../bindings/nvmem/layouts/nvmem-layout.yaml | 1 +
.../nvmem/{ => layouts}/u-boot,env.yaml | 29 ++-
MAINTAINERS | 2 +-
3 files changed, 17 insertions(+), 15 deletions(-)
rename Documentation/devicetree/bindings/nvmem/{ => layouts}/u-boot,env.yaml
(77%)
diff --git a/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml
b/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml
index 8512ee538c4c..8835b1781a9f 100644
--- a/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml
+++ b/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml
@@ -20,6 +20,7 @@ description: |
oneOf:
- $ref: kontron,sl28-vpd.yaml
- $ref: onie,tlv-layout.yaml
+ - $ref: u-boot,env.yaml
properties:
compatible: true
diff --git a/Documentation/devicetree/bindings/nvmem/u-boot,env.yaml
b/Documentation/devicetree/bindings/nvmem/layouts/u-boot,env.yaml
similarity index 77%
rename from Documentation/devicetree/bindings/nvmem/u-boot,env.yaml
rename to Documentation/devicetree/bindings/nvmem/layouts/u-boot,env.yaml
index cbc5c69fd405..fb273b174fe7 100644
--- a/Documentation/devicetree/bindings/nvmem/u-boot,env.yaml
+++ b/Documentation/devicetree/bindings/nvmem/layouts/u-boot,env.yaml
@@ -1,10 +1,10 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
-$id: http://devicetree.org/schemas/nvmem/u-boot,env.yaml#
+$id: http://devicetree.org/schemas/nvmem/layouts/u-boot,env.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: U-Boot environment variables
+title: NVMEM layout of U-Boot environment variables
description: |
U-Boot uses environment variables to store device parameters and
@@ -14,16 +14,11 @@ description: |
Data is stored using U-Boot specific formats (variant specific header and NUL
separated key-value pairs).
- Environment data can be stored on various storage entities, e.g.:
+ Environment data can be stored on NVMEM devices of various underlaying
storage
+ entities, e.g.:
1. Raw flash partition
2. UBI volume
- This binding allows marking storage device (as containing env data) and
- specifying used format.
-
- Right now only flash partition case is covered but it may be extended to e.g.
- UBI volumes in the future.
-
Variables can be defined as NVMEM device subnodes.
maintainers:
@@ -67,11 +62,14 @@ examples:
read-only;
};
-env: partition@4 {
-compatible = "u-boot,env";
+partition@4 {
reg = <0x4 0x1>;
-mac: ethaddr {
+nvmem-layout {
+compatible = "u-boot,env";
+
+mac: ethaddr {
+};
};
};
};
@@ -87,9 +85,12 @@ examples:
label = "u-boot";
partition-u-boot-env {
-compatible = "brcm,env";
-ethaddr {
+nvmem-layout {
+compatible = "brcm,env";
+
+ethaddr {
+};
};
};
};
diff --git a/MAINTAINERS b/MAINTAINERS
index 2a1368722c45..2e13ee875c77 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -21136,7 +21136,7 @@ F: drivers/media/pci/tw686x/
U-BOOT ENVIRONMENT VARIABLES
M: Rafał Miłecki
S: Maintained
-F: Documentation/devicetree/bindings/nvmem/u-boot,env.yaml
+F: Documentation/devicetree/bindings/nvmem/layouts/u-boot,env.yaml
F: drivers/nvmem/u-boot-env.c
UACCE ACCELERATOR FRAMEWORK
--
2.34.1
[PATCH V2 2/6] nvmem: core: allow .read_post_process() callbacks to adjust buffer
From: Rafał Miłecki
Sometimes reading NVMEM cell value involves some data reformatting. it
may require resizing available buffer. Support that.
It's required e.g. to provide properly formatted MAC address in case
it's stored in a non-binary format (e.g. using ASCII).
Signed-off-by: Rafał Miłecki
---
V2: Pass buffer pointer to allow krealloc() if needed
---
drivers/nvmem/core.c | 27 ---
drivers/nvmem/imx-ocotp.c| 8
drivers/nvmem/layouts/onie-tlv.c | 5 ++---
drivers/nvmem/layouts/sl28vpd.c | 10 +-
include/linux/nvmem-provider.h | 5 ++---
5 files changed, 29 insertions(+), 26 deletions(-)
diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index 32f7fb81375a..2c9e4ac8a772 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -1539,29 +1539,26 @@ static void nvmem_shift_read_buffer_in_place(struct
nvmem_cell_entry *cell, void
static int __nvmem_cell_read(struct nvmem_device *nvmem,
struct nvmem_cell_entry *cell,
-void *buf, size_t *len, const char *id, int index)
+void **buf, size_t *len, const char *id, int index)
{
int rc;
- rc = nvmem_reg_read(nvmem, cell->offset, buf, cell->bytes);
+ rc = nvmem_reg_read(nvmem, cell->offset, *buf, *len);
if (rc)
return rc;
/* shift bits in-place */
if (cell->bit_offset || cell->nbits)
- nvmem_shift_read_buffer_in_place(cell, buf);
+ nvmem_shift_read_buffer_in_place(cell, *buf);
if (cell->read_post_process) {
rc = cell->read_post_process(cell->priv, id, index,
-cell->offset, buf, cell->bytes);
+cell->offset, buf, len);
if (rc)
return rc;
}
- if (len)
- *len = cell->bytes;
-
return 0;
}
@@ -1578,22 +1575,26 @@ static int __nvmem_cell_read(struct nvmem_device *nvmem,
void *nvmem_cell_read(struct nvmem_cell *cell, size_t *len)
{
struct nvmem_device *nvmem = cell->entry->nvmem;
- u8 *buf;
+ size_t bytes = cell->entry->bytes;
+ void *buf;
int rc;
if (!nvmem)
return ERR_PTR(-EINVAL);
- buf = kzalloc(cell->entry->bytes, GFP_KERNEL);
+ buf = kzalloc(bytes, GFP_KERNEL);
if (!buf)
return ERR_PTR(-ENOMEM);
- rc = __nvmem_cell_read(nvmem, cell->entry, buf, len, cell->id,
cell->index);
+ rc = __nvmem_cell_read(nvmem, cell->entry, , , cell->id,
cell->index);
if (rc) {
kfree(buf);
return ERR_PTR(rc);
}
+ if (len)
+ *len = bytes;
+
return buf;
}
EXPORT_SYMBOL_GPL(nvmem_cell_read);
@@ -1905,11 +1906,15 @@ ssize_t nvmem_device_cell_read(struct nvmem_device
*nvmem,
if (!nvmem)
return -EINVAL;
+ /* Cells with read_post_process hook may realloc buffer we can't allow
here */
+ if (info->read_post_process)
+ return -EINVAL;
+
rc = nvmem_cell_info_to_nvmem_cell_entry_nodup(nvmem, info, );
if (rc)
return rc;
- rc = __nvmem_cell_read(nvmem, , buf, , NULL, 0);
+ rc = __nvmem_cell_read(nvmem, , , , NULL, 0);
if (rc)
return rc;
diff --git a/drivers/nvmem/imx-ocotp.c b/drivers/nvmem/imx-ocotp.c
index ac0edb6398f1..e17500bc0acc 100644
--- a/drivers/nvmem/imx-ocotp.c
+++ b/drivers/nvmem/imx-ocotp.c
@@ -223,15 +223,15 @@ static int imx_ocotp_read(void *context, unsigned int
offset,
}
static int imx_ocotp_cell_pp(void *context, const char *id, int index,
-unsigned int offset, void *data, size_t bytes)
+unsigned int offset, void **data, size_t *bytes)
{
- u8 *buf = data;
+ u8 *buf = *data;
int i;
/* Deal with some post processing of nvmem cell data */
if (id && !strcmp(id, "mac-address"))
- for (i = 0; i < bytes / 2; i++)
- swap(buf[i], buf[bytes - i - 1]);
+ for (i = 0; i < *bytes / 2; i++)
+ swap(buf[i], buf[*bytes - i - 1]);
return 0;
}
diff --git a/drivers/nvmem/layouts/onie-tlv.c b/drivers/nvmem/layouts/onie-tlv.c
index 767f39fff717..f26bcce2a44d 100644
--- a/drivers/nvmem/layouts/onie-tlv.c
+++ b/drivers/nvmem/layouts/onie-tlv.c
@@ -75,10 +75,9 @@ static const char *onie_tlv_cell_name(u8 type)
}
static int onie_tlv_mac_read_cb(void *priv, const char *id, int index,
- unsigned int offset, void *buf,
- size_t bytes)
+ unsigned int offset, void **buf, size_t *bytes)
{
- eth_addr_add(buf, index);
+ eth_addr_add(*buf, index);
return
[PATCH V2 1/6] nvmem: core: add nvmem_dev_size() helper
From: Rafał Miłecki
This is required by layouts that need to read whole NVMEM space. It
applies to NVMEM devices without hardcoded layout (like U-Boot
environment data block).
Signed-off-by: Rafał Miłecki
---
V2: Drop "const" from "const size_t"
---
drivers/nvmem/core.c | 13 +
include/linux/nvmem-consumer.h | 1 +
2 files changed, 14 insertions(+)
diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index d3be50ed2d0b..32f7fb81375a 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -2062,6 +2062,19 @@ void nvmem_del_cell_lookups(struct nvmem_cell_lookup
*entries, size_t nentries)
}
EXPORT_SYMBOL_GPL(nvmem_del_cell_lookups);
+/**
+ * nvmem_dev_size() - Get the size of a given nvmem device.
+ *
+ * @nvmem: nvmem device.
+ *
+ * Return: size of the nvmem device.
+ */
+size_t nvmem_dev_size(struct nvmem_device *nvmem)
+{
+ return nvmem->size;
+}
+EXPORT_SYMBOL_GPL(nvmem_dev_size);
+
/**
* nvmem_dev_name() - Get the name of a given nvmem device.
*
diff --git a/include/linux/nvmem-consumer.h b/include/linux/nvmem-consumer.h
index fa030d93b768..c3005ab6cc4f 100644
--- a/include/linux/nvmem-consumer.h
+++ b/include/linux/nvmem-consumer.h
@@ -78,6 +78,7 @@ ssize_t nvmem_device_cell_read(struct nvmem_device *nvmem,
int nvmem_device_cell_write(struct nvmem_device *nvmem,
struct nvmem_cell_info *info, void *buf);
+size_t nvmem_dev_size(struct nvmem_device *nvmem);
const char *nvmem_dev_name(struct nvmem_device *nvmem);
void nvmem_add_cell_lookups(struct nvmem_cell_lookup *entries,
--
2.34.1
[PATCH] net: zynq_gem: Add a 10ms delay in zynq_gem_init()
In our system using ZynqMP with an external SGMII PHY it's necessary to wait a short while after the configuration in zynq_gem_init() before the xfer starts. Otherwise the first packet(s) might get dropped, resulting in a delay at the start of the ethernet transfers. This patch adds a minimal delay of 10ms which fixes problems of dropped first packages. Signed-off-by: Stefan Roese Cc: Michal Simek Cc: Ramon Fried Cc: Sean Anderson --- drivers/net/zynq_gem.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/net/zynq_gem.c b/drivers/net/zynq_gem.c index 507b19b75975..26e468766871 100644 --- a/drivers/net/zynq_gem.c +++ b/drivers/net/zynq_gem.c @@ -522,6 +522,13 @@ static int zynq_gem_init(struct udevice *dev) return ret; } } + + /* +* Some additional minimal delay seems to be needed so that +* the first packet will be sent correctly +*/ + mdelay(10); + setbits_le32(>nwctrl, ZYNQ_GEM_NWCTRL_RXEN_MASK | ZYNQ_GEM_NWCTRL_TXEN_MASK); -- 2.39.0
Re: [PATCH] net: zynq_gem: Wait for SGMII PCS link in zynq_gem_init()
On 1/10/23 19:28, Sean Anderson wrote:
On 1/10/23 05:38, Stefan Roese wrote:
In our system using ZynqMP with an external SGMII PHY it's necessary
to wait for the PCS link and auto negotiation to finish before the xfer
starts. Otherwise the first packet(s) might get dropped, resulting in a
delay at the start of the ethernet transfers.
This patch adds the necessary code at the end of zynq_gem_init()
including a minimal delay of 10ms which fixes problems of dropped
first packages.
Signed-off-by: Stefan Roese
Cc: Michal Simek
Cc: T Karthik Reddy
Cc: Ramon Fried
---
drivers/net/zynq_gem.c | 32 +++-
1 file changed, 31 insertions(+), 1 deletion(-)
diff --git a/drivers/net/zynq_gem.c b/drivers/net/zynq_gem.c
index 507b19b75975..625b0303d6e2 100644
--- a/drivers/net/zynq_gem.c
+++ b/drivers/net/zynq_gem.c
@@ -125,6 +125,10 @@
*/
#define PHY_DETECT_MASK 0x1808
+/* PCS (SGMII) Link Status */
+#define ZYNQ_GEM_PCSSTATUS_LINKBIT(2)
+#define ZYNQ_GEM_PCSSTATUS_ANEG_COMPL BIT(5)
+
/* TX BD status masks */
#define ZYNQ_GEM_TXBUF_FRMLEN_MASK0x07ff
#define ZYNQ_GEM_TXBUF_EXHAUSTED 0x0800
@@ -164,7 +168,8 @@ struct zynq_gem_regs {
u32 stat[STAT_SIZE]; /* 0x100 - Octects transmitted Low reg */
u32 reserved9[20];
u32 pcscntrl;
- u32 rserved12[36];
+ u32 pcsstatus;
+ u32 rserved12[35];
u32 dcfg6; /* 0x294 Design config reg6 */
u32 reserved7[106];
u32 transmit_q1_ptr; /* 0x440 - Transmit priority queue 1 */
@@ -522,6 +527,31 @@ static int zynq_gem_init(struct udevice *dev)
return ret;
}
}
+
+ /* Wait for SGMII link */
+ if (priv->interface == PHY_INTERFACE_MODE_SGMII && priv->int_pcs) {
+ u32 pcsstatus;
+
+ if (priv->phydev->phy_id == PHY_FIXED_ID)
+ pcsstatus = ZYNQ_GEM_PCSSTATUS_LINK;
+ else
+ pcsstatus = ZYNQ_GEM_PCSSTATUS_LINK |
+ ZYNQ_GEM_PCSSTATUS_ANEG_COMPL;
Use BMSR_LSTATUS/BMSR_ANEGCOMPLETE.
The PHY link aneg is done in the PHY code already. But thanks for your
comment. I re-thought about this and testing shows, that only the 10ms
delay is really needed. Regardless of the aneg being in action while
running the network xfer or the link being fully established.
I'll post a new patch replacing this one shortly.
Thanks,
Stefan
+
+ ret = wait_for_bit_le32(>pcsstatus, pcsstatus,
+ true, 5000, true);
+ if (ret) {
+ dev_err(dev, "no PCS (SGMII) link detected\n");
This should be an info or lower, since this is normal behavior when there
is no link partner (e.g. when the cable is unplugged).
--Seam
+ return ret;
+ }
+
+ /*
+* Some additional minimal delay seems to be needed so that
+* the first packet will be sent correctly
+*/
+ mdelay(10);
+ }
+
setbits_le32(>nwctrl, ZYNQ_GEM_NWCTRL_RXEN_MASK |
ZYNQ_GEM_NWCTRL_TXEN_MASK);
Viele Grüße,
Stefan Roese
--
DENX Software Engineering GmbH, Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
[PATCH v2 1/1] i2c:aspeed:support ast2600 i2c new register mode driver
Add i2c new register mode driver to support AST2600 i2c
new register mode. AST2600 i2c controller have legacy and
new register mode. The new register mode have global register
support 4 base clock for scl clock selection, and new clock
divider mode.
Signed-off-by: ryan_chen
---
MAINTAINERS | 6 +
drivers/i2c/Kconfig | 10 +
drivers/i2c/Makefile | 1 +
drivers/i2c/ast2600_i2c.c | 375 ++
drivers/i2c/ast2600_i2c.h | 120
5 files changed, 512 insertions(+)
create mode 100644 drivers/i2c/ast2600_i2c.c
create mode 100644 drivers/i2c/ast2600_i2c.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 3fc4cd0f12..1cf54f0b4e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -769,6 +769,12 @@ S: Maintained
F: drivers/pci/pcie_phytium.c
F: arch/arm/dts/phytium-durian.dts
+ASPEED AST2600 I2C DRIVER
+M: Ryan Chen
+R: Aspeed BMC SW team
+S: Maintained
+F: drivers/i2c/ast2600_i2c.c
+
ASPEED FMC SPI DRIVER
M: Chin-Ting Kuo
M: Cédric Le Goater
diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig
index 08b6c7bdcc..77e2a1c4c0 100644
--- a/drivers/i2c/Kconfig
+++ b/drivers/i2c/Kconfig
@@ -221,6 +221,16 @@ config SYS_I2C_DW
controller is used in various SoCs, e.g. the ST SPEAr, Altera
SoCFPGA, Synopsys ARC700 and some Intel x86 SoCs.
+config SYS_I2C_AST2600
+bool "AST2600 I2C Controller"
+depends on DM_I2C && ARCH_ASPEED
+help
+ Say yes here to select AST2600 I2C Host Controller. The driver
+ support AST2600 I2C new mode register. This I2C controller supports:
+ _Standard-mode (up to 100 kHz)
+ _Fast-mode (up to 400 kHz)
+ _Fast-mode Plus (up to 1 MHz)
+
config SYS_I2C_ASPEED
bool "Aspeed I2C Controller"
depends on DM_I2C && ARCH_ASPEED
diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile
index 920aafb91c..89db2d8e37 100644
--- a/drivers/i2c/Makefile
+++ b/drivers/i2c/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_$(SPL_)I2C_CROS_EC_LDO) += cros_ec_ldo.o
obj-$(CONFIG_$(SPL_)SYS_I2C_LEGACY) += i2c_core.o
obj-$(CONFIG_SYS_I2C_ASPEED) += ast_i2c.o
+obj-$(CONFIG_SYS_I2C_AST2600) += ast2600_i2c.o
obj-$(CONFIG_SYS_I2C_AT91) += at91_i2c.o
obj-$(CONFIG_SYS_I2C_CADENCE) += i2c-cdns.o
obj-$(CONFIG_SYS_I2C_CA) += i2c-cortina.o
diff --git a/drivers/i2c/ast2600_i2c.c b/drivers/i2c/ast2600_i2c.c
new file mode 100644
index 00..0fad30b5a2
--- /dev/null
+++ b/drivers/i2c/ast2600_i2c.c
@@ -0,0 +1,375 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright ASPEED Technology Inc.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "ast2600_i2c.h"
+
+/* Device private data */
+struct ast2600_i2c_priv {
+ struct clk clk;
+ struct ast2600_i2c_regs *regs;
+ void __iomem *global;
+};
+
+static int ast2600_i2c_read_data(struct ast2600_i2c_priv *priv, u8 chip_addr,
+u8 *buffer, size_t len, bool send_stop)
+{
+ int rx_cnt, ret = 0;
+ u32 cmd, isr;
+
+ for (rx_cnt = 0; rx_cnt < len; rx_cnt++, buffer++) {
+ cmd = I2CM_PKT_EN | I2CM_PKT_ADDR(chip_addr) |
+ I2CM_RX_CMD;
+ if (!rx_cnt)
+ cmd |= I2CM_START_CMD;
+
+ if ((len - 1) == rx_cnt)
+ cmd |= I2CM_RX_CMD_LAST;
+
+ if (send_stop && ((len - 1) == rx_cnt))
+ cmd |= I2CM_STOP_CMD;
+
+ writel(cmd, >regs->cmd_sts);
+
+ ret = readl_poll_timeout(>regs->isr, isr,
+isr & I2CM_PKT_DONE,
+I2C_TIMEOUT_US);
+ if (ret)
+ return -ETIMEDOUT;
+
+ *buffer =
+ I2CC_GET_RX_BUFF(readl(>regs->trx_buff));
+
+ writel(I2CM_PKT_DONE, >regs->isr);
+
+ if (isr & I2CM_TX_NAK)
+ return -EREMOTEIO;
+ }
+
+ return 0;
+}
+
+static int ast2600_i2c_write_data(struct ast2600_i2c_priv *priv, u8 chip_addr,
+ u8 *buffer, size_t len, bool send_stop)
+{
+ int tx_cnt, ret = 0;
+ u32 cmd, isr;
+
+ if (!len) {
+ cmd = I2CM_PKT_EN | I2CM_PKT_ADDR(chip_addr) |
+ I2CM_START_CMD;
+ writel(cmd, >regs->cmd_sts);
+ ret = readl_poll_timeout(>regs->isr, isr,
+isr & I2CM_PKT_DONE,
+I2C_TIMEOUT_US);
+ if (ret)
+ return -ETIMEDOUT;
+
+ writel(I2CM_PKT_DONE, >regs->isr);
+
+ if (isr & I2CM_TX_NAK)
+ return -EREMOTEIO;
+ }
+
+ for (tx_cnt = 0; tx_cnt < len; tx_cnt++, buffer++) {
+ cmd = I2CM_PKT_EN | I2CM_PKT_ADDR(chip_addr);
+
[PATCH v2 0/1] Add ASPEED AST2600 I2C new controller driver
This series add AST2600 i2c new register set driver. The i2c new register set have new clock divider option for more flexiable generation. v2: add speed support desciption in Kconfig. modify include header ordering. separate include register define header. modify wording reserver to reserved. remove defined string AST2600. modify signle-line comment style. remove extra (). modify local regs for register ctrl. ryan_chen (1): i2c:aspeed:support ast2600 i2c new register mode driver MAINTAINERS | 6 + drivers/i2c/Kconfig | 10 + drivers/i2c/Makefile | 1 + drivers/i2c/ast2600_i2c.c | 375 ++ drivers/i2c/ast2600_i2c.h | 120 5 files changed, 512 insertions(+) create mode 100644 drivers/i2c/ast2600_i2c.c create mode 100644 drivers/i2c/ast2600_i2c.h -- 2.34.1
Re: [PATCH 1/6] nvmem: core: add nvmem_dev_size() helper
On 10.01.23 11:54, Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> This is required by layouts that need to read whole NVMEM space. It
> applies to NVMEM devices without hardcoded layout (like U-Boot
> environment data block).
>
> Signed-off-by: Rafał Miłecki
> ---
> drivers/nvmem/core.c | 13 +
> include/linux/nvmem-consumer.h | 1 +
> 2 files changed, 14 insertions(+)
>
> diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
> index 1f05f0a50d86..81743ae8793b 100644
> --- a/drivers/nvmem/core.c
> +++ b/drivers/nvmem/core.c
> @@ -2062,6 +2062,19 @@ void nvmem_del_cell_lookups(struct nvmem_cell_lookup
> *entries, size_t nentries)
> }
> EXPORT_SYMBOL_GPL(nvmem_del_cell_lookups);
>
> +/**
> + * nvmem_dev_size() - Get the size of a given nvmem device.
> + *
> + * @nvmem: nvmem device.
> + *
> + * Return: size of the nvmem device.
> + */
> +const size_t nvmem_dev_size(struct nvmem_device *nvmem)
The const here is quite unusual. You can make the parameter
a const struct nvmem_device though.
> +{
> + return nvmem->size;
> +}
> +EXPORT_SYMBOL_GPL(nvmem_dev_size);
> +
> /**
> * nvmem_dev_name() - Get the name of a given nvmem device.
> *
> diff --git a/include/linux/nvmem-consumer.h b/include/linux/nvmem-consumer.h
> index fa030d93b768..d88294ddf562 100644
> --- a/include/linux/nvmem-consumer.h
> +++ b/include/linux/nvmem-consumer.h
> @@ -78,6 +78,7 @@ ssize_t nvmem_device_cell_read(struct nvmem_device *nvmem,
> int nvmem_device_cell_write(struct nvmem_device *nvmem,
> struct nvmem_cell_info *info, void *buf);
>
> +const size_t nvmem_dev_size(struct nvmem_device *nvmem);
> const char *nvmem_dev_name(struct nvmem_device *nvmem);
>
> void nvmem_add_cell_lookups(struct nvmem_cell_lookup *entries,
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
[PATCH 1/1] i2c:aspeed:support ast2600 i2c new register mode driver
Add i2c new register mode driver to support AST2600 i2c
new register mode. AST2600 i2c controller have legacy and
new register mode. The new register mode have global register
support 4 base clock for scl clock selection, and new clock
divider mode.
Signed-off-by: ryan_chen
---
MAINTAINERS | 6 +
drivers/i2c/Kconfig | 10 +
drivers/i2c/Makefile | 1 +
drivers/i2c/ast2600_i2c.c | 375 ++
drivers/i2c/ast2600_i2c.h | 120
5 files changed, 512 insertions(+)
create mode 100644 drivers/i2c/ast2600_i2c.c
create mode 100644 drivers/i2c/ast2600_i2c.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 3fc4cd0f12..1cf54f0b4e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -769,6 +769,12 @@ S: Maintained
F: drivers/pci/pcie_phytium.c
F: arch/arm/dts/phytium-durian.dts
+ASPEED AST2600 I2C DRIVER
+M: Ryan Chen
+R: Aspeed BMC SW team
+S: Maintained
+F: drivers/i2c/ast2600_i2c.c
+
ASPEED FMC SPI DRIVER
M: Chin-Ting Kuo
M: Cédric Le Goater
diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig
index 08b6c7bdcc..77e2a1c4c0 100644
--- a/drivers/i2c/Kconfig
+++ b/drivers/i2c/Kconfig
@@ -221,6 +221,16 @@ config SYS_I2C_DW
controller is used in various SoCs, e.g. the ST SPEAr, Altera
SoCFPGA, Synopsys ARC700 and some Intel x86 SoCs.
+config SYS_I2C_AST2600
+bool "AST2600 I2C Controller"
+depends on DM_I2C && ARCH_ASPEED
+help
+ Say yes here to select AST2600 I2C Host Controller. The driver
+ support AST2600 I2C new mode register. This I2C controller supports:
+ _Standard-mode (up to 100 kHz)
+ _Fast-mode (up to 400 kHz)
+ _Fast-mode Plus (up to 1 MHz)
+
config SYS_I2C_ASPEED
bool "Aspeed I2C Controller"
depends on DM_I2C && ARCH_ASPEED
diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile
index 920aafb91c..89db2d8e37 100644
--- a/drivers/i2c/Makefile
+++ b/drivers/i2c/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_$(SPL_)I2C_CROS_EC_LDO) += cros_ec_ldo.o
obj-$(CONFIG_$(SPL_)SYS_I2C_LEGACY) += i2c_core.o
obj-$(CONFIG_SYS_I2C_ASPEED) += ast_i2c.o
+obj-$(CONFIG_SYS_I2C_AST2600) += ast2600_i2c.o
obj-$(CONFIG_SYS_I2C_AT91) += at91_i2c.o
obj-$(CONFIG_SYS_I2C_CADENCE) += i2c-cdns.o
obj-$(CONFIG_SYS_I2C_CA) += i2c-cortina.o
diff --git a/drivers/i2c/ast2600_i2c.c b/drivers/i2c/ast2600_i2c.c
new file mode 100644
index 00..0fad30b5a2
--- /dev/null
+++ b/drivers/i2c/ast2600_i2c.c
@@ -0,0 +1,375 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright ASPEED Technology Inc.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "ast2600_i2c.h"
+
+/* Device private data */
+struct ast2600_i2c_priv {
+ struct clk clk;
+ struct ast2600_i2c_regs *regs;
+ void __iomem *global;
+};
+
+static int ast2600_i2c_read_data(struct ast2600_i2c_priv *priv, u8 chip_addr,
+u8 *buffer, size_t len, bool send_stop)
+{
+ int rx_cnt, ret = 0;
+ u32 cmd, isr;
+
+ for (rx_cnt = 0; rx_cnt < len; rx_cnt++, buffer++) {
+ cmd = I2CM_PKT_EN | I2CM_PKT_ADDR(chip_addr) |
+ I2CM_RX_CMD;
+ if (!rx_cnt)
+ cmd |= I2CM_START_CMD;
+
+ if ((len - 1) == rx_cnt)
+ cmd |= I2CM_RX_CMD_LAST;
+
+ if (send_stop && ((len - 1) == rx_cnt))
+ cmd |= I2CM_STOP_CMD;
+
+ writel(cmd, >regs->cmd_sts);
+
+ ret = readl_poll_timeout(>regs->isr, isr,
+isr & I2CM_PKT_DONE,
+I2C_TIMEOUT_US);
+ if (ret)
+ return -ETIMEDOUT;
+
+ *buffer =
+ I2CC_GET_RX_BUFF(readl(>regs->trx_buff));
+
+ writel(I2CM_PKT_DONE, >regs->isr);
+
+ if (isr & I2CM_TX_NAK)
+ return -EREMOTEIO;
+ }
+
+ return 0;
+}
+
+static int ast2600_i2c_write_data(struct ast2600_i2c_priv *priv, u8 chip_addr,
+ u8 *buffer, size_t len, bool send_stop)
+{
+ int tx_cnt, ret = 0;
+ u32 cmd, isr;
+
+ if (!len) {
+ cmd = I2CM_PKT_EN | I2CM_PKT_ADDR(chip_addr) |
+ I2CM_START_CMD;
+ writel(cmd, >regs->cmd_sts);
+ ret = readl_poll_timeout(>regs->isr, isr,
+isr & I2CM_PKT_DONE,
+I2C_TIMEOUT_US);
+ if (ret)
+ return -ETIMEDOUT;
+
+ writel(I2CM_PKT_DONE, >regs->isr);
+
+ if (isr & I2CM_TX_NAK)
+ return -EREMOTEIO;
+ }
+
+ for (tx_cnt = 0; tx_cnt < len; tx_cnt++, buffer++) {
+ cmd = I2CM_PKT_EN | I2CM_PKT_ADDR(chip_addr);
+
[PATCHv2 0/1] Add ASPEED AST2600 I2C new controller driver
This series add AST2600 i2c new register set driver. The i2c new register set have new clock divider option for more flexiable generation. v2: add speed support desciption in Kconfig. modify include header ordering. separate include register define header. modify wording reserver to reserved. remove defined string AST2600. modify signle-line comment style. remove extra (). modify local regs for register ctrl. ryan_chen (1): i2c:aspeed:support ast2600 i2c new register mode driver MAINTAINERS | 6 + drivers/i2c/Kconfig | 10 + drivers/i2c/Makefile | 1 + drivers/i2c/ast2600_i2c.c | 375 ++ drivers/i2c/ast2600_i2c.h | 120 5 files changed, 512 insertions(+) create mode 100644 drivers/i2c/ast2600_i2c.c create mode 100644 drivers/i2c/ast2600_i2c.h -- 2.34.1
[PATCH 1/1] configs: remove SDL2 dependency in tools-only_defconfig
When building tools only there is no point in requiring the SDL2 library. Signed-off-by: Heinrich Schuchardt --- configs/tools-only_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/tools-only_defconfig b/configs/tools-only_defconfig index de99f3857c..8b6d85c3f0 100644 --- a/configs/tools-only_defconfig +++ b/configs/tools-only_defconfig @@ -3,6 +3,7 @@ CONFIG_SYS_MALLOC_LEN=0x200 CONFIG_ENV_SIZE=0x2000 CONFIG_DEFAULT_DEVICE_TREE="sandbox" CONFIG_SYS_LOAD_ADDR=0x0 +# CONFIG_SANDBOX_SDL is not set CONFIG_ANDROID_BOOT_IMAGE=y CONFIG_FIT=y CONFIG_TIMESTAMP=y -- 2.37.2
Re: u-boot: signature check for u-boot scripts
Hello Sean, Thanks for your answer! On 10.01.23 17:27, Sean Anderson wrote: > On 1/10/23 08:18, Heiko Schocher wrote: >> Hello Simon, [...] >> While writting this email ... in [3] the line >> >> require = "conf" >> >> poped into my eyes and in fit_image_verify_required_sigs() there is >> check: >> >> if (!required || strcmp(required, "image")) >> continue; >> >> and yes! changing in [3] >> >> -required = "conf"; >> +required = "image"; >> >> makes sourcing the signed script working (error in case of no >> signature or wrong signature)! ... but booting the signed fitimage >> now breaks ... so it seems, I cannot use configuration signing with >> images signing ? >> >> I tried to add two key nodes in signature node of u-boot dtb ... one with >> require = "conf" and one with require = "image" ... but no luck... >> >> Also adding a configurations section to scripts its file did not helped >> (which will not prevent the problem sourcing a not signed script) > > As you discovered, you must either have required = "image", in which case > > source : > > will be secure. Otherwise, you must use > > source \# > > Any other way is not secure. My "hack" checks a configuration signature in fitimage with script in it... so also "secure" ... BTW: why we need a env variable to enable checking in cmd/source.c? I would say, if verify fit images is enabled we always should check signature ... but this is another question... So I tried your suggestion: => tftp 10 script.bin.signed;setenv verify 1;source \#10 Speed: 1000, full duplex Using ethernet@24000 device TFTP from server 192.168.3.1; our IP address is 192.168.3.40 Filename 'script.bin.signed'. Load address: 0x10 Loading: # 233.4 KiB/s done Bytes transferred = 1679 (68f hex) ## Executing script at Wrong image format for "source" command => same for => source \#10:script-1 ## Executing script at Wrong image format for "source" command => Which is the error message from the switch in image_source_script() from cmd/source.c ... (check if fitimage "is okay"): => source 10 ## Executing script at 0010 sha256+ sha256,rsa2048:dev+ Hallo from script => source 10:script-1 ## Executing script at 0010 sha256+ sha256,rsa2048:dev+ Hallo from script => source 10:script-2 ## Executing script at 0010 Can't find 'script-2' FIT subimage => and changing hash in fitimages signature leads to: => mw 1001c0 0 1 => source 10:script-1 ## Executing script at 0010 sha256+ sha256,rsa2048:dev- Hallo from script => As I described ... problem "hash is detected, but script is executed", as public key in u-boots dtb has required = "conf"; (as it is used also for fitimage boot, where we use conf signing) May you have an example (u-boot.dtb, its and complete working command for a signed fitimage script)? The main problem is (I think) that we check for fitimages which are used for booting kernels, a "signed configuration" and in fitimage for scripts only "image" signatures ... and a combination of both is not possible (except I also sign the image nodes in kernel fitimage too ... which than leads in checking configuration signature and image signature on boot... but may a way to go (and disabling hash check) ? bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de
[PATCH] configs: Increase malloc size after relocation
Current default size of 0x10 is not capable of getting the FIT buffer during boot when transitioning to using binman generated boot images for certain K3 devices, so increase it to 0x40. Since A72 SPL is coming after relocation to DDR this should not be an issue for any K3 device, so make it default for all. Signed-off-by: Neha Malcom Francis --- common/spl/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/common/spl/Kconfig b/common/spl/Kconfig index a25d8fd2e0..d8c78ddb76 100644 --- a/common/spl/Kconfig +++ b/common/spl/Kconfig @@ -385,6 +385,7 @@ config SPL_STACK_R_ADDR config SPL_STACK_R_MALLOC_SIMPLE_LEN depends on SPL_STACK_R && SPL_SYS_MALLOC_SIMPLE hex "Size of malloc_simple heap after switching to DRAM SPL stack" + default 0x40 if ARCH_K3 default 0x10 help Specify the amount of the stack to use as memory pool for -- 2.34.1
Re: kwboot: UART booting with bin_hdr u-boot (Marvell Armada 385)
Hi Pali, On Mon, Jan 9, 2023 at 5:44 PM Tony Dinh wrote: > > On Mon, Jan 9, 2023 at 5:38 PM Pali Rohár wrote: > > > > On Monday 09 January 2023 17:35:24 Tony Dinh wrote: > > > Hi Pali, > > > > > > On Mon, Jan 9, 2023 at 5:02 PM Pali Rohár wrote: > > > > > > > > On Monday 09 January 2023 16:55:56 Tony Dinh wrote: > > > > > Hi Pali, > > > > > > > > > > On Wed, Jan 4, 2023 at 1:04 PM Tony Dinh wrote: > > > > > > > > > > > > Hello, > > > > > > > > > > > > On Wed, Jan 4, 2023 at 9:44 AM Pali Rohár wrote: > > > > > > > > > > > > > > On Wednesday 04 January 2023 23:41:05 Chris Packham wrote: > > > > > > > > On Wed, 4 Jan 2023, 8:52 PM Pali Rohár, wrote: > > > > > > > > > > > > > > > > > On Wednesday 04 January 2023 08:50:28 Pali Rohár wrote: > > > > > > > > > > Hello! > > > > > > > > > > > > > > > > > > > > On Tuesday 03 January 2023 17:55:41 Tony Dinh wrote: > > > > > > > > > > > Hi Pali, > > > > > > > > > > > > > > > > > > > > > > I'm building a new u-boot for the Thecus N2350 board > > > > > > > > > > > (Armada 385 > > > > > > > > > > > dual-core 1Ghz 1GB DDR4). The trouble with this board is > > > > > > > > > > > DDR4, which > > > > > > > > > > > is not currently supported in u-boot (also cc this to > > > > > > > > > > > Chris for > > > > > > > > > > > commenting about Marvell DDR4 training driver). > > > > > > > > > > > > > > > > > > > > Yes, ddr4 training code is not in u-boot yet. > > > > > > > > > > > > > > > > > > > > A38x u-boot ddr driver is in this directory: > > > > > > > > > > > > > > > > > > > https://source.denx.de/u-boot/u-boot/-/tree/master/drivers/ddr/marvell/a38x > > > > > > > > > > > > > > > > > > > > And it is copied from the original marvell driver by > > > > > > > > > > stripping non-a38x > > > > > > > > > > code and removal of the ddr4 code from the master branch: > > > > > > > > > > https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell > > > > > > > > > > > > > > > > > > > > So you can try to copy code again without stripping ddr4 > > > > > > > > > > parts > > > > > > > > > > (run git log drivers/ddr/marvell/a38x in u-boot) > > > > > > > > > > > > > > > > > > > > > > > > > > > https://source.denx.de/u-boot/u-boot/-/commit/107c3391b95bcc2ba09a876da4fa0c31b6c1e460 > > > > > > > > > > > > > > > > > > > And adjust u-boot board code for ddr4. > > > > > > > > > > > > > > > > > > > > I guess it could work but it would be needed to play with > > > > > > > > > > it. > > > > > > > > > > > > > > > > > > > > > > > > > Last time I looked the MarvellEmbeddedProcessors stuff was a > > > > > > > > long way > > > > > > > > behind what Marvell are releasing to customers. That was for > > > > > > > > the newer SoCs > > > > > > > > so maybe the A385 stuff is current. > > > > > > > > > > > > > > About half year ago, MarvellEmbeddedProcessors mv-ddr-marvell and > > > > > > > A3700-utils-marvell were up-to-date and same as the version > > > > > > > distributed > > > > > > > to the Marvell customers. I was cooperating with Marvell to > > > > > > > release all > > > > > > > patches from Marvell Extranet portal to github as opensource and > > > > > > > also to > > > > > > > incorporate github patches from community to their Extranet > > > > > > > version. > > > > > > > Also I was synchronizing u-boot drivers/ddr/marvell/a38x > > > > > > > directory with > > > > > > > MarvellEmbeddedProcessors version. I do not think that Marvell > > > > > > > released > > > > > > > something super new in these repositories in last half of year, > > > > > > > so I > > > > > > > think that the code on MarvellEmbeddedProcessors (for those two > > > > > > > repositories) is still up-to-date. > > > > > > > > > > > > Thanks all for commenting. As Pali has suggested, I will try copying > > > > > > the latest Marvell Github DDR drivers. > > > > > > > > > > I've tried to bring in the latest Marvell DDR drivers, but failed > > > > > miserably after many hours playing :) I used your DDR3 commit info as > > > > > a guide as how to strip out other parts, and only kept DDR3 and DDR4 > > > > > for a38x: > > > > > > > > > > https://source.denx.de/u-boot/u-boot/-/commit/107c3391b95bcc2ba09a876da4fa0c31b6c1e460 > > > > > > > > > > The current code has DDR4 interspersed in DDR3 with if-defs > > > > > CONFIG_DDR4. And there are some minor dependencies on ATF types, > > > > > quite difficult for me to get it to build cleanly. I guess I threw in > > > > > the towel for now :) If you ever find some free time, please give it a > > > > > shot. > > > > > > > > > > Thanks, > > > > > Tony > > > > > > > > Hello! And what is the issue? DDR training is failing? Or SPL does not > > > > boot? Or it do not compile? > > > > > > Each of the code files was compiled (after some includes adjustments). > > > But the build failed to link due to some errors such as > > > /usr/src/u-boot-master/drivers/ddr/marvell/a38x/mv_ddr_plat.c:558: > > > undefined reference to `mv_ddr_freq_get' > > > > > > It should have been seen by the linker (since
Re: [PATCH] SoC: sdm845: find and save KASLR to env variables
On Tue, Dec 27, 2022 at 7:47 PM Dzmitry Sankouski wrote:
>
> KASLR address is needed to boot fully functional Android.
> KASLR is set by primary bootloader, and since u-boot is used
> as a secondary bootloader(replacing kernel) on sdm845 platform,
> KASLR may be found by comparing memory chunks at relocaddr over
> supposed KASLR range.
By KASLR I presume you mean the random seed? KASLR is a technology
used in the kernel, but it's actually a random seed that's passed to
the kernel to generate the random layout.
> Signed-off-by: Dzmitry Sankouski
> ---
> arch/arm/mach-snapdragon/init_sdm845.c | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/arch/arm/mach-snapdragon/init_sdm845.c
> b/arch/arm/mach-snapdragon/init_sdm845.c
> index 5f53c21947..1f88502394 100644
> --- a/arch/arm/mach-snapdragon/init_sdm845.c
> +++ b/arch/arm/mach-snapdragon/init_sdm845.c
> @@ -78,5 +78,23 @@ __weak int misc_init_r(void)
> env_set("key_power", "0");
> }
>
> + /*
> +* search for kaslr address, set by primary bootloader by searching
> first
> +* 0x100 relocated bytes at u-boot's initial load address range
> +*/
> + uintptr_t start = gd->ram_base;
> + uintptr_t end = start + 0x80;
> + u8 *addr = (u8 *)start;
> + phys_addr_t *relocaddr = (phys_addr_t *)gd->relocaddr;
> + u32 block_size = 0x1000;
> +
> + while (memcmp(addr, relocaddr, 0x100) && (uintptr_t)addr < end)
> + addr += block_size;
> +
> + if ((uintptr_t)addr >= end)
> + printf("KASLR not found in range 0x%lx - 0x%lx", start, end);
> + else
> + env_set_addr("KASLR", addr);
> +
> return 0;
> }
> --
> 2.30.2
>
Re: [PATCH v2] ARM: omap3: evm: Name this directory omap3evm
On Fri, Jan 06, 2023 at 01:05:14PM -0600, Andrew Davis wrote: > Before this was named just evm, which doesn't match the naming > of the other TI board file directory and makes it look like a > common directory for evms. Name this omap3evm. > > Signed-off-by: Andrew Davis > Reviewed-by: Derald Woods Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 3/3] powerpc/mpc85xx: Unset CONFIG_SPL_TARGET="u-boot-with-spl.bin"
On Thu, Dec 29, 2022 at 02:39:21AM +0100, Pali Rohár wrote: > CONFIG_SPL_TARGET should specify additional SPL make target. But > u-boot-with-spl.bin is final U-Boot binary, not SPL binary in some custom > format. Moreover u-boot-with-spl.bin is already set in CONFIG_BUILD_TARGET, > so make will build it by default. > > Signed-off-by: Pali Rohár Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 2/3] powerpc/mpc85xx: Set default CONFIG_BUILD_TARGET
On Thu, Dec 29, 2022 at 02:39:20AM +0100, Pali Rohár wrote: > Final U-Boot binary for mpc85xx boards which use SPL and are not PBL-based > based is u-boot-with-spl.bin. PBL is not used only on boards with e500v1 > and e500v2 cores. Apparently CONFIG_E500 is set not only for e500 cores, > but also for all other mpc85xx cores e500mc, e5500 and e5600. So do not use > CONFIG_E500 and instead filter new cores with PBL based bootrom. > > Signed-off-by: Pali Rohár Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/3] arm: mvebu: Fix default CONFIG_BUILD_TARGET
On Thu, Dec 29, 2022 at 02:39:19AM +0100, Pali Rohár wrote: > u-boot-with-spl.kwb is built only for SPL enabled 32-bit armada boards. > u-boot.kwb is built for 32-bit armada and kirkwood boards but only for > non-SPL targets. > > So replace CONFIG_ARCH_MVEBU by CONFIG_ARMADA_32BIT (it implies > CONFIG_ARCH_MVEBU) for u-boot-with-spl.kwb. > > And add additional CONFIG_ARMADA_32BIT && !CONFIG_SPL for u-boot.kwb. > > Signed-off-by: Pali Rohár Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] SoC: sdm845: find and save KASLR to env variables
On Tue, Dec 27, 2022 at 10:47:09PM +0300, Dzmitry Sankouski wrote: > KASLR address is needed to boot fully functional Android. > KASLR is set by primary bootloader, and since u-boot is used > as a secondary bootloader(replacing kernel) on sdm845 platform, > KASLR may be found by comparing memory chunks at relocaddr over > supposed KASLR range. > > Signed-off-by: Dzmitry Sankouski > Reviewed-by: Ramon Fried Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] board: starqltechn: enable serial console
On Tue, Dec 27, 2022 at 10:47:08PM +0300, Dzmitry Sankouski wrote:
> It was temporary disabled due to problem with boot.
> Issue was fixed in
> commit f5ed6c9ccf3e ("uart: sdm845: Fix debug UART pinmux")
>
> Signed-off-by: Dzmitry Sankouski
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH 5/5] configs: am62a: use kernel fitImage when using secure bootflow
On Fri, Dec 23, 2022 at 07:15:25PM -0600, Bryan Brattlof wrote: > In order to maintain the chain of trust, each stage of the boot process > will first authenticate each binary it loads before continuing. To > extend this to the kernal and its dtbs we can package the kernal and > its dtbs into another fitImage for Uboot to authenticate and extend the > chain of trust all the way to the kernel. > > When 'boot_fit' is set, indicating we're using the secure bootflow, look > for and authenticate the kernel's fitImage. > > Signed-off-by: Judith Mendez > Signed-off-by: Bryan Brattlof Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 4/5] configs: am62a: convert bootcmd to distro_bootcmd
On Fri, Dec 23, 2022 at 07:15:24PM -0600, Bryan Brattlof wrote: > We're currently using CONFIG_BOOTCOMMAND to run custom boot scripts to > jump into linux. While this works, let's begin the transition to more > distribution friendly jumps to linux by enabling distro_bootcmd. > > Convert the custom bootcmd to a distro_bootcmd > > Signed-off-by: Judith Mendez > Signed-off-by: Bryan Brattlof Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 3/5] arm: mach-k3: copy bootindex to OCRAM for main domain SPL
On Fri, Dec 23, 2022 at 07:15:23PM -0600, Bryan Brattlof wrote: > Texas Instruments has begun enabling security settings on the SoCs it > produces to instruct ROM and TIFS to begin protecting the Security > Management Subsystem (SMS) from other binaries we load into the chip by > default. > > One way ROM and TIFS do this is by enabling firewalls to protect the > OCSRAM and HSM RAM regions they're using during bootup. > > The HSM RAM the wakeup SPL is in is firewalled by TIFS to protect > itself from the main domain applications. This means the 'bootindex' > value in HSM RAM, left by ROM to indicate if we're using the primary > or secondary boot-method, must be moved to OCSRAM (that TIFS has open > for us) before we make the jump to the main domain so the main domain's > bootloaders can keep access to this information. > > Signed-off-by: Bryan Brattlof Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 2/5] configs: am62a: move stack and heap to HSM RAM
On Fri, Dec 23, 2022 at 07:15:22PM -0600, Bryan Brattlof wrote: > Texas Instruments has begun enabling security setting on the SoCs they > produce to instruct ROM and TIFS to begin protecting the Security > Management Subsystem (SMS) from other binaries we load into the chip by > default. > > One way ROM does this is by enabling firewalls to protect the OCSRAM > region it's using during bootup. Only after TIFS has started (and had > time to disable the OCSRAM firewall region) will we have write access to > the region. > > This means we will need to move the stack & heap from OCSRAM to HSM RAM > and reduce the size of BSS and the SPL to allow it to fit properly. > > Signed-off-by: Bryan Brattlof Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/5] configs: restrict am62ax wakup SPL size
On Fri, Dec 23, 2022 at 07:15:21PM -0600, Bryan Brattlof wrote: > In its current form, the am62a's wakeup SPL is fairly small, however > this will not remain as more boot modes are eventually added. To protect > us from overflowing our ~256k of HSM SRAM, add limits and check during > the wakeup SPL build. > > Signed-off-by: Bryan Brattlof Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 2/2] configs: Enable distroboot on am625
On Tue, Dec 20, 2022 at 06:38:19PM +, Martyn Welch wrote: > TI boards use a custom (though faily common to TI boards) mechanism for > booting Linux. We would like to use the "distroboot" approach. > > Enable distroboot as a further option to use for booting on am625 should > the existing options fail. > > Signed-off-by: Martyn Welch Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/2] arm64:mach-k3 am625_init: Correct boot mode detection
On Tue, Dec 20, 2022 at 06:38:18PM +, Martyn Welch wrote: > The boot mode detection assumes that BOOT_DEVICE_MMC2 should always > result in MMCSD_MODE_FS, but MMCSD_MODE_RAW is also a valid option for > this port. > > The current logic also avoids looking at the bootmode pin strapping, > which should be the primary means of determining whether a device is > being booted in MMCSD_MODE_EMMCBOOT mode. > > Switch around the logic to check the boot mode to determine whether the > eMMC boot mode is expected or MMC/SD boot mode. From there we can look > at the boot mode config if in MMC/SD boot mode to determine whether to > attempt RAW or FS based booting. > > This change allows U-Boot to also be successfully booted from RAW > offsets in addition to from a filesystem. > > Signed-off-by: Martyn Welch Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 4/4] configs: am62x_evm_a53: Enable ethernet
On Tue, Dec 20, 2022 at 04:21:46PM +0100, Sjoerd Simons wrote: > Enable ethernet support for u-boot on am62x evm > > Signed-off-by: Sjoerd Simons Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 3/4] arm: dts: k3-am625-sk: Enable first ethernet port
On Tue, Dec 20, 2022 at 04:21:45PM +0100, Sjoerd Simons wrote: > The K3 am625 sk EVM has two ethernet ports; Enable the first one for > usage in u-boot. > > Signed-off-by: Sjoerd Simons Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 2/4] configs: am62x_evm_*: Run savedefconfig
On Tue, Dec 20, 2022 at 04:21:44PM +0100, Sjoerd Simons wrote: > Clean configuration for am62x_evm using savedefconfig > > Signed-off-by: Sjoerd Simons > Tested-by: Dhruva Gole Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 1/4] configs: am62x_evm_*: Correct SPI configuration option
On Tue, Dec 20, 2022 at 04:21:43PM +0100, Sjoerd Simons wrote: > In f422c4bec the configuration option to support s28hs512t SPI flashes > was changed from CONFIG_SPI_FLASH_S28HS512T to CONFIG_SPI_FLASH_S28HX_T > to support the wider family. Follow this change in the AM62x EVM > configurations. > > Signed-off-by: Sjoerd Simons > Reviewed-by: Dhruva Gole Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v1] pinctrl: nuvoton: add NPCM7xx/NPCM8xx reset type detect
On Tue, Dec 20, 2022 at 04:49:31PM +0800, Jim Liu wrote: > add reset type detect and persist setting. > > Signed-off-by: Jim Liu Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [RFC PATCH] disk: Don't loop over MAX_SEARCH_PARTITIONS in part_create_block_devices()
Hi,
Thank you for catching this issue.
On Tue, Jan 10, 2023 at 09:00:38AM +0100, Stefan Roese wrote:
> I've noticed that the first ext4 file loading from a MMC partition for
> ZynqMP takes quite some time (~ 1 second). Debugging showed, that the
> MMC driver reads the partition info 128 time (MAX_SEARCH_PARTITIONS)
> resulting in this boot delay. To fix this, let's just end creating the
> block drives in part_create_block_devices() when no more valid partition
> is found. This reduces the first file reading from ~0.9s to ~0.3s.
>
> Signed-off-by: Stefan Roese
> Cc: Simon Glass
> Cc: AKASHI Takahiro
> Cc: Heinrich Schuchardt
> ---
> Reasoning for RFC:
> I did not dig into the current disk / partition stuff too deeply, so I'm
> not 100% sure that this patch does not break anything.
I'm afraid that this fix won't work for all the partition types,
especially for those in which entries in a partition table can be sparsely
filled,
or in other words, valid partition numbers may not always be contiguous
even if they don't reach a maximum number.
I somehow confirmed this against a GPT partition by using gdisk.
-Takahiro Akashi
> ---
> disk/disk-uclass.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/disk/disk-uclass.c b/disk/disk-uclass.c
> index d32747e2242d..2999f7285b5a 100644
> --- a/disk/disk-uclass.c
> +++ b/disk/disk-uclass.c
> @@ -36,7 +36,7 @@ int part_create_block_devices(struct udevice *blk_dev)
> /* Add devices for each partition */
> for (count = 0, part = 1; part <= MAX_SEARCH_PARTITIONS; part++) {
> if (part_get_info(desc, part, ))
> - continue;
> + break;
> snprintf(devname, sizeof(devname), "%s:%d", blk_dev->name,
>part);
>
> --
> 2.39.0
>
Re: [PATCH 05/19] dm: ns16550: Change how we get UART_REG to be defined
On Tue, 10 Jan 2023 at 09:19, Tom Rini wrote: > > In the case of DM_SERIAL and not having CONFIG_SYS_NS16550_REG_SIZE > defined, we would set CONFIG_SYS_NS16550_REG_SIZE to -1 with a comment > that this isn't really needed. This implies that the reason we set > something here is so that we have UART_REG defined and so can use the > rest of the structures that are shared between all the users of > ns16650.h. In order to not #define a CONFIG variable here, instead move > that check over to the CONFIG_NS16550_DYNAMIC case (which is at the > conceptual level, similar to DM) to get UART_REG defined. > > Cc: Simon Glass > Signed-off-by: Tom Rini > --- > I'm making an assumption, in the end, as to what the DM case is doing. > This does work in my lab. > --- > include/ns16550.h | 11 ++- > 1 file changed, 2 insertions(+), 9 deletions(-)' Reviewed-by: Simon Glass Seems OK, although this patch brings back nightmares from last time I was in there. - Simon
Re: [PATCH v2 3/3] lmb: consider EFI memory map
Hi Heinrich, On Mon, 9 Jan 2023 at 13:53, Heinrich Schuchardt wrote: > > > > On 1/9/23 21:31, Simon Glass wrote: > > Hi Mark, > > > > On Mon, 9 Jan 2023 at 13:20, Mark Kettenis wrote: > >> > >>> From: Simon Glass > >>> Date: Mon, 9 Jan 2023 13:11:01 -0700 > >>> > >>> Hi Heinrich, > >>> > >>> > >>> We need to fix how EFI does addresses. It seems to use them as > >>> pointers but store them as u64 ? > > That is similar to what you have been doing with physical addresses. > > >> > >> They're defined to a 64-bit unsigned integer by the UEFI > >> specification, so you can't change it. > > > > I don't mean changing the spec, just changing the internal U-Boot > > implementation, which is very confusing. This confusion is spreading > > out, too. > > > > Regards, > > Simon > > The real interesting thing is how memory should be managed in U-Boot: > > I would prefer to create a shared global memory management on 4KiB page > level used both for EFI and the rest of U-Boot. Sounds good. > > What EFI adds to the requirements is that you need more than free > (EfiConventionalMemory) and used memory. EFI knows 16 different types of > memory usage (see enum efi_memory_type). That's a shame. How much of this is legacy and how much is useful? > > When loading a file (e.g. with the "load" command) this should lead to a > memory reservation. You should not be able to load a second file into an > overlapping memory area without releasing the allocated memory first. > > This would replace lmb which currently tries to recalculate available > memory ab initio again and again. > > With managed memory we should be able to get rid of all those constants > like $loadaddr, $fdt_addr_r, $kernel_addr_r, etc. and instead use a > register of named loaded files. This is where standard boot comes in, since it knows what it has loaded and has pointers to it. I see a future where we don't use these commands when we want to save space. It can save 300KB from the U-Boot size. But this really has to come later, since there is so much churn already! For now, please don't add EFI allocation into lmb..that is just odd. Regards, Simon
Re: [PATCH v2 4/5] tpm: sandbox: Update for needed TPM2 capabilities
On Mon, 9 Jan 2023 at 14:55, Eddie James wrote: > > The driver needs to support getting the PCRs in the capabilities > command. Fix various other things and support the max number > of PCRs for TPM2. > > Signed-off-by: Eddie James > --- > drivers/tpm/tpm2_tis_sandbox.c | 100 - > 1 file changed, 72 insertions(+), 28 deletions(-) Reviewed-by: Simon Glass
Re: [PATCH 18/19] global: Finish CONFIG -> CFG migration
On Tue, 10 Jan 2023 at 09:25, Tom Rini wrote: > > At this point, the remaining places where we have a symbol that is > defined as CONFIG_... are in fairly odd locations. While as much dead > code has been removed as possible, some of these locations are simply > less obvious at first. In other cases, this code is used, but was > defined in such a way as to have been missed by earlier checks. Perform > a rename of all such remaining symbols to be CFG_... rather than > CONFIG_... > > Signed-off-by: Tom Rini > --- > README| 24 +- > arch/arm/cpu/armv8/fsl-layerscape/cpu.c | 166 +- > .../arm/include/asm/arch-fsl-layerscape/cpu.h | 96 +++--- > .../include/asm/arch-rockchip/ddr_rk3288.h| 2 +- > .../include/asm/arch-rockchip/sdram_rk322x.h | 2 +- > arch/arm/include/asm/arch-sunxi/i2c.h | 2 +- > arch/arm/mach-omap2/fdt-common.c | 4 +- > arch/arm/mach-omap2/omap5/fdt.c | 8 +- > .../arm/mach-rmobile/include/mach/rcar-mstp.h | 96 +++--- > arch/arm/mach-rockchip/rk3036/sdram_rk3036.c | 2 +- > arch/arm/mach-tegra/tegra20/warmboot_avp.c| 2 +- > arch/arm/mach-tegra/tegra20/warmboot_avp.h| 4 +- > arch/m68k/cpu/mcf523x/interrupts.c| 8 +- > arch/m68k/cpu/mcf52x2/interrupts.c| 14 +- > arch/m68k/cpu/mcf530x/interrupts.c| 2 +- > arch/m68k/cpu/mcf532x/interrupts.c| 8 +- > arch/m68k/cpu/mcf5445x/interrupts.c | 8 +- > arch/m68k/include/asm/cache.h | 42 +-- > arch/m68k/include/asm/coldfire/intctrl.h | 8 +- > arch/m68k/include/asm/immap.h | 290 +- > arch/m68k/lib/cache.c | 28 +- > arch/m68k/lib/interrupts.c| 2 +- > arch/m68k/lib/time.c | 24 +- > arch/mips/mach-mtmips/mt7621/spl/start.S | 8 +- > arch/powerpc/cpu/mpc83xx/bats/bats.h | 128 > arch/powerpc/cpu/mpc83xx/cpu_init.c | 26 +- > arch/powerpc/cpu/mpc83xx/hid/hid.h| 12 +- > arch/powerpc/cpu/mpc83xx/hrcw/hrcw.h | 4 +- > arch/powerpc/cpu/mpc83xx/lblaw/lblaw.h| 32 +- > arch/powerpc/cpu/mpc83xx/spd_sdram.c | 6 +- > arch/powerpc/cpu/mpc83xx/spl_minimal.c| 10 +- > arch/powerpc/cpu/mpc83xx/start.S | 154 +- > arch/powerpc/cpu/mpc85xx/cpu_init.c | 56 ++-- > arch/powerpc/cpu/mpc85xx/fdt.c| 10 +- > arch/powerpc/cpu/mpc85xx/liodn.c | 6 +- > arch/powerpc/cpu/mpc8xxx/fsl_pamu.c | 16 +- > arch/powerpc/include/asm/fsl_pamu.h | 2 +- > arch/powerpc/include/asm/fsl_secure_boot.h| 8 +- > arch/powerpc/lib/bootm.c | 6 +- > arch/powerpc/lib/interrupts.c | 6 +- > arch/riscv/include/asm/encoding.h | 2 +- > arch/x86/include/asm/acpi/chromeos.asl| 4 +- > board/alliedtelesis/x530/x530.c | 6 +- > board/armltd/vexpress64/vexpress64.c | 2 +- > .../compulab/imx8mm-cl-iot-gate/eeprom_spl.c | 6 +- > board/davinci/da8xxevm/da850evm.c | 6 +- > board/davinci/da8xxevm/omapl138_lcdk.c| 4 +- > board/eets/pdu001/board.c | 4 +- > board/freescale/common/cadmus.c | 12 +- > board/freescale/common/fsl_chain_of_trust.c | 6 +- > board/freescale/common/pixis.c| 30 +- > board/freescale/ls1043aqds/eth.c | 4 +- > board/freescale/ls1043ardb/eth.c | 4 +- > board/freescale/ls1046afrwy/eth.c | 2 +- > board/freescale/ls1046aqds/eth.c | 2 +- > board/freescale/ls1046ardb/eth.c | 4 +- > board/freescale/p2041rdb/eth.c| 4 +- > board/freescale/t102xrdb/eth_t102xrdb.c | 4 +- > board/freescale/t104xrdb/eth.c| 2 +- > board/freescale/t208xqds/eth_t208xqds.c | 4 +- > board/freescale/t4rdb/eth.c | 4 +- > board/logicpd/omap3som/omap3logic.c | 4 +- > board/renesas/blanche/blanche.c | 2 +- > board/sysam/amcore/amcore.c | 2 +- > board/ti/evm/evm.c| 4 +- > cmd/ximg.c| 6 +- > common/command.c | 2 +- > doc/README.davinci| 2 +- > doc/README.fec_mxc| 2 +- > doc/develop/environment.rst | 2 +- > doc/usage/netconsole.rst | 2 +- > drivers/crypto/fsl/jr.c | 6 +- > drivers/crypto/fsl/jr.h | 2 +- > drivers/ddr/fsl/ctrl_regs.c | 10 +- > drivers/ddr/fsl/options.c | 6 +- > drivers/fpga/virtex2.c| 8 +- >
Re: [PATCH 19/19] CI: Make check for new defined CONFIG symbols even more robust
On Tue, 10 Jan 2023 at 09:23, Tom Rini wrote: > > Now that all remaining in-tree cases where we define or undef a CONFIG > symbol have been migrated to Kconfig or renamed to CFG we can make the > CI check more robust. We will exclude the doc, tools and arch/arm/dts > directories from this check as they are special cases. Further, we can > exclude the scripts/kconfig/lkc.h and include/linux/kconfig.h files as > the CONFIG values they define are special tooling cases and not real > symbols. > > In the case of docs, the only places that currently fail this test are > old documentation that should be rewritten so that we can remove this > special case. > > Signed-off-by: Tom Rini > --- > .azure-pipelines.yml | 3 ++- > .gitlab-ci.yml | 3 ++- > 2 files changed, 4 insertions(+), 2 deletions(-) > Reviewed-by: Simon Glass
Re: [PATCH v2 2/2] serial: mxc: Wait for TX completion before reset
Hi, On Tue, 10 Jan 2023 at 05:42, Loic Poulain wrote: > > The u-boot console may show some corrupted characters when > printing in board_init() due to reset of the UART (probe) > before the TX FIFO has been completely drained. > > To fix this issue, and in case UART is still running, we now > try to flush the FIFO before proceding to UART reinitialization. > For this we're waiting for Transmitter Complete bit, indicating > that the FIFO and the shift register are empty. > > flushing has a 4ms timeout guard, which is normally more than > enough to consume the FIFO @ low baudrate (9600bps). > > Signed-off-by: Loic Poulain > --- > v2: Add this commit to the series > > drivers/serial/serial_mxc.c | 24 +++- > 1 file changed, 23 insertions(+), 1 deletion(-) > Can you just use serial_flush()? It is generic and should work with any device. Regards, Simon
Re: dt-schema u-boot,config node
Hi Michal, On Tue, 10 Jan 2023 at 06:42, Michal Simek wrote: > > Hi, > > On 1/9/23 21:11, Simon Glass wrote: > > Hi Michal, > > > > On Mon, 9 Jan 2023 at 01:02, Michal Simek wrote: > >> > >> Hi Simon, > >> > >> We just got a request to setup bootscript address via DT that's why I am > >> trying > >> to refresh my mind how to do it. > >> I know that u-boot,config have been merged to via this pull request > >> https://github.com/devicetree-org/dt-schema/pull/62 > >> > >> I also grep all your branches in u-boot-dm tree but I can't see it to be > >> used > >> anywhere. What's the current state on it? > >> > >> I expect all of these options doc/device-tree-bindings/config.txt > >> should be converted to u-boot,config node. > > > > Yes that's right. It hasn't been done yet, but should be. > > ok. What's the expected flow? Should the new property discussed in this > mailing > list and then send pull request in dt-schema? Or that request should be going > directly via github pull request? I sent a post to the mailing list at devicet...@vger.kernel.org with a patch (cc U-Boot list), waited a week and then sent a PR. But I think we need to mirror these bindings in U-Boot. Regards, Simon
Re: [PATCH u-boot 2/2] Makefile: Build working u-boot-dtb.bin target also for mpc85xx
On Friday 06 January 2023 17:13:41 Simon Glass wrote: > Hi Pali, > > On Tue, 3 Jan 2023 at 10:05, Pali Rohár wrote: > > > > On Tuesday 03 January 2023 11:02:17 Simon Glass wrote: > > > > > > > 3. Add a common binman image for u-boot.bin (used by every board) > > > > > > > > > > > > It should be u-boot-dtb.bin (not u-boot.bin). At least this is the > > > > > > current file name. (See this my patch series again, which aligns > > > > > > this > > > > > > naming also for powerpc/mpc85xx). > > > > > > > > > > We changed this 6 years ago and I'm not keen on going back. > > > > > > > > > > ad1ecd2063d fdt: Build a U-Boot binary without device tree > > > > > > > > I just do not understand you because in that commit is exactly what I > > > > wrote. In file u-boot-dtb.bin is u-boot binary with DTB and in file > > > > u-boot-nodtb.bin is u-boot binary without DTB. > > > > > > > > So binman should take input files u-boot-nodtb.bin and DTB binary. And > > > > should produce output file u-boot-dtb.bin. Is there any issue with it? > > > > > > Actually u-boot-dtb.bin is a hangover from that commit, left in to > > > allow people to adjust. So I think we should remove creation of > > > u-boot-dtb.bin > > > > Ok, complete remove of u-boot-dtb.bin creation also works. > > OK good. > > > - Simon I would suggest to take patch 1/2 to have all mpc85xx boards standard output file u-boot.bin. And prevent to repeat issue that building of the final image with custom name was unintentionally turned off as a side effect of some change.
Re: [PATCH u-boot] powerpc/mpc85xx: socrates: Re-enable building u-boot-socrates.bin
On Monday 02 January 2023 09:29:10 Heiko Schocher wrote:
> Hello Pali
>
> On 01.01.23 07:57, Heiko Schocher wrote:
> > Hello Pali,
> >
> > On 31.12.22 16:37, Pali Rohár wrote:
> >> On Saturday 31 December 2022 16:31:57 Heiko Schocher wrote:
> >>> Hello Pali,
> >>>
> >>> On 31.12.22 14:36, Heiko Schocher wrote:
> Hello Pali,
>
> On 31.12.22 13:58, Pali Rohár wrote:
> > On Saturday 31 December 2022 10:36:07 Heiko Schocher wrote:
> >> Hello Pali,
> >>
> >> On 28.12.22 19:18, Pali Rohár wrote:
> >>> U-Boot build system builds final U-Boot binary for socrates board in
> >>> custom
> >>> file u-boot-socrates.bin (instead of standard u-boot.bin). Output
> >>> target
> >>> file u-boot-socrates.bin is generated by binman as defined in board
> >>> binman
> >>> config file arch/powerpc/dts/socrates-u-boot.dtsi.
> >>>
> >>> But binman was disabled in commit 5af42eafd7e1 ("Makefile: Reduce
> >>> usage of
> >>> custom mpc85xx u-boot.bin target") for all mpc85xx boards which do
> >>> not use
> >>> standard powerpc binman config file arch/powerpc/dts/u-boot.dtsi and
> >>> boards
> >>> which do not require binman at all.
> >>>
> >>> The only such mpc85xx board is socrates. So since that commit, U-Boot
> >>> does
> >>> not final binary for socrates board anymore.
> >>>
> >>> Fix this issue by re-enabling binman for socrates board. And build
> >>> process
> >>> starts again producing u-boot-socrates.bin binary.
> >>>
> >>> Note that build process for this socrates board always produce
> >>> u-boot.bin
> >>> binary which is broken and not usable for socrates board. Long term
> >>> solution should be to disable building broken binary u-boot.bin and
> >>> then
> >>> renaming u-boot-socrates.bin to u-boot.bin, or switching to use common
> >>> powerpc binman config file arch/powerpc/dts/socrates-u-boot.dtsi (if
> >>> it is
> >>> possible).
> >>>
> >>> Fixes: 5af42eafd7e1 ("Makefile: Reduce usage of custom mpc85xx
> >>> u-boot.bin target")
> >>> Signed-off-by: Pali Rohár
> >>> ---
> >>> Heiko Schocher: Could you test if u-boot is still working on this
> >>> board?
> >>>
> >>> Tom Rini: Cannot be this issue handled by CI? For example that CI
> >>> check
> >>> build process produce required output binaries?
> >>> ---
> >>> arch/powerpc/cpu/mpc85xx/Kconfig | 1 +
> >>> 1 file changed, 1 insertion(+)
> >>
> >> With this patch, u-boot-socrates.bin is build again, so yes...
> >>
> >> Tested-by: Heiko Schocher
> >>
> >> ... but current u-boot does not boot anymore on this board ... I have
> >> to
> >> dig into, obvious difference I see in hexdump is:
> >>
> >> old (2022.01) u-boot:
> >> """
> >> 1930 74 65 00 6f 66 66 73 65 74 00 73 74 64 6f 75 74
> >> |te.offset.stdout|
> >> 1940 2d 70 61 74 68 00 ff ff ff ff ff ff ff ff ff ff
> >> |-path...|
> >> 1950 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> ||
> >> *
> >> 0002 27 05 19 56 3c 60 e4 01 60 63 3f 10 38 63 fb f0
> >> |'..V<`..`c?.8c..|
> >> 00020010 3c 80 e4 01 60 84 40 00 38 00 00 00 38 84 ff fc
> >> |<...`.@.8...8...|
> >> 00020020 90 04 00 00 7c 04 18 40 40 82 ff f4 3c 80 e4 01
> >> ||..@@...<...|
> >>
> >> """
> >>
> >> New
> >> """
> >> 1930 74 65 00 6f 66 66 73 65 74 00 73 74 64 6f 75 74
> >> |te.offset.stdout|
> >> 1940 2d 70 61 74 68 00 ff ff ff ff ff ff ff ff ff ff
> >> |-path...|
> >> 1950 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> ||
> >> *
> >> 0002 3c 60 e4 01 60 63 3f 10 38 63 fb f0 3c 80 e4 01
> >> |<`..`c?.8c..<...|
> >> 00020010 60 84 40 00 38 00 00 00 38 84 ff fc 90 04 00 00
> >> |`.@.8...8...|
> >> 00020020 7c 04 18 40 40 82 ff f4 3c 80 e4 01 60 84 3f 20
> >> ||..@@...<...`.? |
> >>
> >> """
> >>
> >> So "U-Boot magic" is misssing ...
> >
> > It was removed in commit 2dcf776ebcf7 ("powerpc: mpc85xx: Drop _start
> > symbol").
> > Was it used for something?
>
> I think (hope) not!
>
> >> reset vector at end of image is for both the same:
> >>
> >> 000bfff0 ff ff ff ff ff ff ff ff ff ff ff ff 4b ff f0 04
> >> |K...|
> >> 000c
> >
> > 4b ff f0 04 is ppc branch instruction pos-0xffc, so to offset 0xbf000
> > in dumped file (not available in the output). I think this is correct.
>
> Yes, this is correct.
>
> >
> >> I have to dig deeper into it, to find out what have changed in the
> >> meantime,
> >> (Think I start a "git bisect") just find some more time for it...
> >
> > I think
Re: [PATCH v3 2/2] serial: mxc: Speed-up character transmission
On Tuesday 10 January 2023 20:24:07 Loic Poulain wrote:
> Instead of waiting for empty FIFO condition before writing a
> character, wait for non-full FIFO condition.
>
> This helps in saving several tens of milliseconds during boot
> (depending verbosity).
>
> Signed-off-by: Loic Poulain
> Tested-by: Lothar Waßmann
> ---
> v2: fixing transfert abort & char corruption commit
> v3: Reordering commits for good bisectability
>
> drivers/serial/serial_mxc.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/serial/serial_mxc.c b/drivers/serial/serial_mxc.c
> index 3c89781f2c..9899155c00 100644
> --- a/drivers/serial/serial_mxc.c
> +++ b/drivers/serial/serial_mxc.c
> @@ -238,11 +238,11 @@ static void mxc_serial_putc(const char c)
> if (c == '\n')
> serial_putc('\r');
>
> - writel(c, _base->txd);
> -
> /* wait for transmitter to be ready */
> - while (!(readl(_base->ts) & UTS_TXEMPTY))
> + while (readl(_base->ts) & UTS_TXFULL)
> schedule();
> +
> + writel(c, _base->txd);
> }
>
> /* Test whether a character is in the RX buffer */
> @@ -333,7 +333,7 @@ static int mxc_serial_putc(struct udevice *dev, const
> char ch)
> struct mxc_serial_plat *plat = dev_get_plat(dev);
> struct mxc_uart *const uart = plat->reg;
>
> - if (!(readl(>ts) & UTS_TXEMPTY))
> + if (readl(>ts) & UTS_TXFULL)
> return -EAGAIN;
>
> writel(ch, >txd);
> --
> 2.34.1
>
Hello!
In this driver there are two mxc_serial_putc() and two mxc_serial_getc()
function. One for DM and one for non-DM version. It would be really nice
to fix also second set of functions.
Re: [PATCH v3 1/2] serial: mxc: Wait for TX completion before reset
On Tuesday 10 January 2023 20:24:06 Loic Poulain wrote:
> The u-boot console may show some corrupted characters when
> printing in board_init() due to reset of the UART (probe)
> before the TX FIFO has been completely drained.
>
> To fix this issue, and in case UART is still running, we now
> try to flush the FIFO before proceeding to UART reinitialization.
> For this we're waiting for Transmitter Complete bit, indicating
> that the FIFO and the shift register are empty.
>
> flushing has a 4ms timeout guard, which is normally more than
> enough to consume the FIFO @ low baudrate (9600bps).
>
> Signed-off-by: Loic Poulain
> Tested-by: Lothar Waßmann
Hello! Last time when I looked at this driver I was in impression that
also _mxc_serial_setbrg() function requires calling some flush function
at the beginning. Could you please check if it is needed or not? I'm
really not sure.
> ---
> v2: Add this commit to the series
> v3: Fix typo & reordering commits for good bisectability
>
> drivers/serial/serial_mxc.c | 24 +++-
> 1 file changed, 23 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/serial/serial_mxc.c b/drivers/serial/serial_mxc.c
> index 82c0d84628..3c89781f2c 100644
> --- a/drivers/serial/serial_mxc.c
> +++ b/drivers/serial/serial_mxc.c
> @@ -13,6 +13,7 @@
> #include
> #include
> #include
> +#include
>
> /* UART Control Register Bit Fields.*/
> #define URXD_CHARRDY (1<<15)
> @@ -144,8 +145,22 @@ struct mxc_uart {
> u32 ts;
> };
>
> +static void _mxc_serial_flush(struct mxc_uart *base)
> +{
> + unsigned int timeout = 4000;
> +
> + if (!(readl(>cr1) & UCR1_UARTEN) ||
> + !(readl(>cr2) & UCR2_TXEN))
> + return;
> +
> + while (!(readl(>sr2) & USR2_TXDC) && --timeout)
> + udelay(1);
> +}
> +
> static void _mxc_serial_init(struct mxc_uart *base, int use_dte)
> {
> + _mxc_serial_flush(base);
> +
> writel(0, >cr1);
> writel(0, >cr2);
>
> @@ -252,10 +267,17 @@ static int mxc_serial_init(void)
> return 0;
> }
>
> +static int mxc_serial_stop(void)
> +{
> + _mxc_serial_flush(mxc_base);
> +
> + return 0;
> +}
> +
> static struct serial_device mxc_serial_drv = {
> .name = "mxc_serial",
> .start = mxc_serial_init,
> - .stop = NULL,
> + .stop = mxc_serial_stop,
> .setbrg = mxc_serial_setbrg,
> .putc = mxc_serial_putc,
> .puts = default_serial_puts,
Anyway, this code touches _only_ non-DM version of the driver. So same
fix should be implemented also for DM version because non-DM is now
legacy and will be removed in the future from U-Boot. Please look at the
DM version too.
> --
> 2.34.1
>
Re: kernel doesn't start on Odroid U2 unless setting initrd_high
On Wed, Jan 11, 2023 at 12:10:42AM +0100, Joost van Zwieten wrote:
>
>
> On Tue, Jan 10, 2023 at 18:08, Tom Rini wrote:
> > On Wed, Jan 11, 2023 at 12:01:46AM +0100, Joost van Zwieten wrote:
> > >
> > >
> > > On Tue, Jan 10, 2023 at 13:41, Tom Rini wrote:
> > > > On Tue, Jan 10, 2023 at 09:13:32AM +0100, Joost van Zwieten wrote:
> > > >
> > > > > Dear maintainers,
> > > > >
> > > > > As of commit 4963f63fe61f15329d77472a762b1d8bf754d24b U-Boot
> > > fails
> > > > > to start
> > > > > a kernel (with `bootz`) on my Odroid U2 unless I force
> > > > > `initrd_high`, e.g.
> > > > > to `0x5000`. With commit 4963f63f and `initrd_high`
> > > *unset* I
> > > > > get the
> > > > > following output:
> > > > >
> > > > > U-Boot 2020.10-rc2-00314-g4963f63fe6 (Jan 09 2023 - 23:59:31
> > > > > +0100)
> > > > >
> > > > > CPU: Exynos4412 @ 1 GHz
> > > > > Model: Odroid based on Exynos4412
> > > > > Type: u3
> > > > > DRAM: 2 GiB
> > > > > LDO20@VDDQ_EMMC_1.8V: set 180 uV; enabling
> > > > > LDO22@VDDQ_EMMC_2.8V: set 280 uV; enabling
> > > > > LDO21@TFLASH_2.8V: set 280 uV; enabling
> > > > > MMC: SAMSUNG SDHCI: 2, EXYNOS DWMMC: 0
> > > > > Loading Environment from MMC... *** Warning - bad CRC, using
> > > > > default
> > > > > environment
> > > > >
> > > > > In: serial
> > > > > Out: serial
> > > > > Err: serial
> > > > > Boot device: MMC(2)
> > > > > Net: No ethernet found.
> > > > > Hit any key to stop autoboot: 0
> > > > > Odroid # env set fk_kvers 5.10.0-20-armmp
> > > > > Odroid # load mmc ${mmcbootdev}:${mmcbootpart} ${fdt_addr_r}
> > > > > /boot/dtbs/${fk_kvers}/exynos4412-odroidu3.dtb
> > > > > 53440 bytes read in 50 ms (1 MiB/s)
> > > > > Odroid # load mmc ${mmcbootdev}:${mmcbootpart}
> > > ${kernel_addr_r}
> > > > > /boot/vmlinuz-${fk_kvers}
> > > > > 4973056 bytes read in 182 ms (26.1 MiB/s)
> > > > > Odroid # load mmc ${mmcbootdev}:${mmcbootpart}
> > > ${ramdisk_addr_r}
> > > > > /boot/initrd.img-${fk_kvers}
> > > > > 22231585 bytes read in 777 ms (27.3 MiB/s)
> > > > > Odroid # env set bootargs console=ttySAC1,115200n8
> > > > > Odroid # bootz ${kernel_addr_r}
> > > ${ramdisk_addr_r}:${filesize}
> > > > > ${fdt_addr_r}
> > > > > Kernel image @ 0x4100 [ 0x00 - 0x4be200 ]
> > > > > ## Flattened Device Tree blob at 4080
> > > > >Booting using the fdt blob at 0x4080
> > > > >Loading Ramdisk to b9947000, end bae7aa21 ... OK
> > > > >Loading Device Tree to b9936000, end b99460bf ... OK
> > > > >
> > > > > Starting kernel ...
> > > > >
> > > > > And that's all I ever see. Normally the initrd loads a module
> > > that
> > > > > causes an
> > > > > LED on the Odroid to blink, and this is not happening either,
> > > so
> > > > > I'm pretty
> > > > > confident the kernel doesn't start or at least crashes before
> > > > > producing
> > > > > output. If I set `initrd_high` to `0x5000` (or something
> > > in the
> > > > > neighborhood) the kernel starts just fine:
> > > > >
> > > > > U-Boot 2020.10-rc2-00314-g4963f63fe6 (Jan 09 2023 - 23:59:31
> > > > > +0100)
> > > > >
> > > > > CPU: Exynos4412 @ 1 GHz
> > > > > Model: Odroid based on Exynos4412
> > > > > Type: u3
> > > > > DRAM: 2 GiB
> > > > > LDO20@VDDQ_EMMC_1.8V: set 180 uV; enabling
> > > > > LDO22@VDDQ_EMMC_2.8V: set 280 uV; enabling
> > > > > LDO21@TFLASH_2.8V: set 280 uV; enabling
> > > > > MMC: SAMSUNG SDHCI: 2, EXYNOS DWMMC: 0
> > > > > Loading Environment from MMC... *** Warning - bad CRC, using
> > > > > default
> > > > > environment
> > > > >
> > > > > In: serial
> > > > > Out: serial
> > > > > Err: serial
> > > > > Boot device: MMC(2)
> > > > > Net: No ethernet found.
> > > > > Hit any key to stop autoboot: 0
> > > > > Odroid # env set fk_kvers 5.10.0-20-armmp
> > > > > Odroid # load mmc ${mmcbootdev}:${mmcbootpart} ${fdt_addr_r}
> > > > > /boot/dtbs/${fk_kvers}/exynos4412-odroidu3.dtb
> > > > > 53440 bytes read in 49 ms (1 MiB/s)
> > > > > Odroid # load mmc ${mmcbootdev}:${mmcbootpart}
> > > ${kernel_addr_r}
> > > > > /boot/vmlinuz-${fk_kvers}
> > > > > 4973056 bytes read in 181 ms (26.2 MiB/s)
> > > > > Odroid # load mmc ${mmcbootdev}:${mmcbootpart}
> > > ${ramdisk_addr_r}
> > > > > /boot/initrd.img-${fk_kvers}
> > > > > 22231585 bytes read in 777 ms (27.3 MiB/s)
> > > > > Odroid # env set bootargs console=ttySAC1,115200n8
> > > > > Odroid # env set initrd_high 0x5000
> > > > > Odroid # bootz ${kernel_addr_r}
> > > ${ramdisk_addr_r}:${filesize}
> > > > > ${fdt_addr_r}
> > > > > Kernel image @ 0x4100 [ 0x00 - 0x4be200 ]
> > > > > ## Flattened Device Tree blob at 4080
> > > > >Booting using the fdt blob at 0x4080
>
Re: kernel doesn't start on Odroid U2 unless setting initrd_high
On Tue, Jan 10, 2023 at 18:08, Tom Rini wrote:
On Wed, Jan 11, 2023 at 12:01:46AM +0100, Joost van Zwieten wrote:
On Tue, Jan 10, 2023 at 13:41, Tom Rini wrote:
> On Tue, Jan 10, 2023 at 09:13:32AM +0100, Joost van Zwieten wrote:
>
> > Dear maintainers,
> >
> > As of commit 4963f63fe61f15329d77472a762b1d8bf754d24b U-Boot
fails
> > to start
> > a kernel (with `bootz`) on my Odroid U2 unless I force
> > `initrd_high`, e.g.
> > to `0x5000`. With commit 4963f63f and `initrd_high`
*unset* I
> > get the
> > following output:
> >
> > U-Boot 2020.10-rc2-00314-g4963f63fe6 (Jan 09 2023 - 23:59:31
> > +0100)
> >
> > CPU: Exynos4412 @ 1 GHz
> > Model: Odroid based on Exynos4412
> > Type: u3
> > DRAM: 2 GiB
> > LDO20@VDDQ_EMMC_1.8V: set 180 uV; enabling
> > LDO22@VDDQ_EMMC_2.8V: set 280 uV; enabling
> > LDO21@TFLASH_2.8V: set 280 uV; enabling
> > MMC: SAMSUNG SDHCI: 2, EXYNOS DWMMC: 0
> > Loading Environment from MMC... *** Warning - bad CRC, using
> > default
> > environment
> >
> > In: serial
> > Out: serial
> > Err: serial
> > Boot device: MMC(2)
> > Net: No ethernet found.
> > Hit any key to stop autoboot: 0
> > Odroid # env set fk_kvers 5.10.0-20-armmp
> > Odroid # load mmc ${mmcbootdev}:${mmcbootpart} ${fdt_addr_r}
> > /boot/dtbs/${fk_kvers}/exynos4412-odroidu3.dtb
> > 53440 bytes read in 50 ms (1 MiB/s)
> > Odroid # load mmc ${mmcbootdev}:${mmcbootpart}
${kernel_addr_r}
> > /boot/vmlinuz-${fk_kvers}
> > 4973056 bytes read in 182 ms (26.1 MiB/s)
> > Odroid # load mmc ${mmcbootdev}:${mmcbootpart}
${ramdisk_addr_r}
> > /boot/initrd.img-${fk_kvers}
> > 22231585 bytes read in 777 ms (27.3 MiB/s)
> > Odroid # env set bootargs console=ttySAC1,115200n8
> > Odroid # bootz ${kernel_addr_r}
${ramdisk_addr_r}:${filesize}
> > ${fdt_addr_r}
> > Kernel image @ 0x4100 [ 0x00 - 0x4be200 ]
> > ## Flattened Device Tree blob at 4080
> >Booting using the fdt blob at 0x4080
> >Loading Ramdisk to b9947000, end bae7aa21 ... OK
> >Loading Device Tree to b9936000, end b99460bf ... OK
> >
> > Starting kernel ...
> >
> > And that's all I ever see. Normally the initrd loads a module
that
> > causes an
> > LED on the Odroid to blink, and this is not happening either,
so
> > I'm pretty
> > confident the kernel doesn't start or at least crashes before
> > producing
> > output. If I set `initrd_high` to `0x5000` (or something
in the
> > neighborhood) the kernel starts just fine:
> >
> > U-Boot 2020.10-rc2-00314-g4963f63fe6 (Jan 09 2023 - 23:59:31
> > +0100)
> >
> > CPU: Exynos4412 @ 1 GHz
> > Model: Odroid based on Exynos4412
> > Type: u3
> > DRAM: 2 GiB
> > LDO20@VDDQ_EMMC_1.8V: set 180 uV; enabling
> > LDO22@VDDQ_EMMC_2.8V: set 280 uV; enabling
> > LDO21@TFLASH_2.8V: set 280 uV; enabling
> > MMC: SAMSUNG SDHCI: 2, EXYNOS DWMMC: 0
> > Loading Environment from MMC... *** Warning - bad CRC, using
> > default
> > environment
> >
> > In: serial
> > Out: serial
> > Err: serial
> > Boot device: MMC(2)
> > Net: No ethernet found.
> > Hit any key to stop autoboot: 0
> > Odroid # env set fk_kvers 5.10.0-20-armmp
> > Odroid # load mmc ${mmcbootdev}:${mmcbootpart} ${fdt_addr_r}
> > /boot/dtbs/${fk_kvers}/exynos4412-odroidu3.dtb
> > 53440 bytes read in 49 ms (1 MiB/s)
> > Odroid # load mmc ${mmcbootdev}:${mmcbootpart}
${kernel_addr_r}
> > /boot/vmlinuz-${fk_kvers}
> > 4973056 bytes read in 181 ms (26.2 MiB/s)
> > Odroid # load mmc ${mmcbootdev}:${mmcbootpart}
${ramdisk_addr_r}
> > /boot/initrd.img-${fk_kvers}
> > 22231585 bytes read in 777 ms (27.3 MiB/s)
> > Odroid # env set bootargs console=ttySAC1,115200n8
> > Odroid # env set initrd_high 0x5000
> > Odroid # bootz ${kernel_addr_r}
${ramdisk_addr_r}:${filesize}
> > ${fdt_addr_r}
> > Kernel image @ 0x4100 [ 0x00 - 0x4be200 ]
> > ## Flattened Device Tree blob at 4080
> >Booting using the fdt blob at 0x4080
> >Loading Ramdisk to 4eacc000, end 4a21 ... OK
> >Loading Device Tree to bae6a000, end bae7a0bf ... OK
> >
> > Starting kernel ...
> >
> > [ 0.00] Booting Linux on physical CPU 0xa00
> >
> >
> > The difference between those two runs is the location where
U-Boot
> > loads the
> > initrd. The parent commit of 4963f63f boots fine without
setting
> > `initrd_high`:
> >
> > U-Boot 2020.10-rc2-00313-gdfaf6a5797 (Jan 10 2023 - 00:13:19
> > +0100)
> >
> > CPU: Exynos4412 @ 1 GHz
> > Model: Odroid based on Exynos4412
> > Type: u3
> > DRAM: 2 GiB
> > LDO20@VDDQ_EMMC_1.8V: set 180 uV; enabling
> > LDO22@VDDQ_EMMC_2.8V: set 280 uV; enabling
>
Re: kernel doesn't start on Odroid U2 unless setting initrd_high
On Tue, Jan 10, 2023 at 13:41, Tom Rini wrote:
On Tue, Jan 10, 2023 at 09:13:32AM +0100, Joost van Zwieten wrote:
Dear maintainers,
As of commit 4963f63fe61f15329d77472a762b1d8bf754d24b U-Boot fails
to start
a kernel (with `bootz`) on my Odroid U2 unless I force
`initrd_high`, e.g.
to `0x5000`. With commit 4963f63f and `initrd_high` *unset* I
get the
following output:
U-Boot 2020.10-rc2-00314-g4963f63fe6 (Jan 09 2023 - 23:59:31
+0100)
CPU: Exynos4412 @ 1 GHz
Model: Odroid based on Exynos4412
Type: u3
DRAM: 2 GiB
LDO20@VDDQ_EMMC_1.8V: set 180 uV; enabling
LDO22@VDDQ_EMMC_2.8V: set 280 uV; enabling
LDO21@TFLASH_2.8V: set 280 uV; enabling
MMC: SAMSUNG SDHCI: 2, EXYNOS DWMMC: 0
Loading Environment from MMC... *** Warning - bad CRC, using
default
environment
In: serial
Out: serial
Err: serial
Boot device: MMC(2)
Net: No ethernet found.
Hit any key to stop autoboot: 0
Odroid # env set fk_kvers 5.10.0-20-armmp
Odroid # load mmc ${mmcbootdev}:${mmcbootpart} ${fdt_addr_r}
/boot/dtbs/${fk_kvers}/exynos4412-odroidu3.dtb
53440 bytes read in 50 ms (1 MiB/s)
Odroid # load mmc ${mmcbootdev}:${mmcbootpart} ${kernel_addr_r}
/boot/vmlinuz-${fk_kvers}
4973056 bytes read in 182 ms (26.1 MiB/s)
Odroid # load mmc ${mmcbootdev}:${mmcbootpart} ${ramdisk_addr_r}
/boot/initrd.img-${fk_kvers}
22231585 bytes read in 777 ms (27.3 MiB/s)
Odroid # env set bootargs console=ttySAC1,115200n8
Odroid # bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize}
${fdt_addr_r}
Kernel image @ 0x4100 [ 0x00 - 0x4be200 ]
## Flattened Device Tree blob at 4080
Booting using the fdt blob at 0x4080
Loading Ramdisk to b9947000, end bae7aa21 ... OK
Loading Device Tree to b9936000, end b99460bf ... OK
Starting kernel ...
And that's all I ever see. Normally the initrd loads a module that
causes an
LED on the Odroid to blink, and this is not happening either, so
I'm pretty
confident the kernel doesn't start or at least crashes before
producing
output. If I set `initrd_high` to `0x5000` (or something in the
neighborhood) the kernel starts just fine:
U-Boot 2020.10-rc2-00314-g4963f63fe6 (Jan 09 2023 - 23:59:31
+0100)
CPU: Exynos4412 @ 1 GHz
Model: Odroid based on Exynos4412
Type: u3
DRAM: 2 GiB
LDO20@VDDQ_EMMC_1.8V: set 180 uV; enabling
LDO22@VDDQ_EMMC_2.8V: set 280 uV; enabling
LDO21@TFLASH_2.8V: set 280 uV; enabling
MMC: SAMSUNG SDHCI: 2, EXYNOS DWMMC: 0
Loading Environment from MMC... *** Warning - bad CRC, using
default
environment
In: serial
Out: serial
Err: serial
Boot device: MMC(2)
Net: No ethernet found.
Hit any key to stop autoboot: 0
Odroid # env set fk_kvers 5.10.0-20-armmp
Odroid # load mmc ${mmcbootdev}:${mmcbootpart} ${fdt_addr_r}
/boot/dtbs/${fk_kvers}/exynos4412-odroidu3.dtb
53440 bytes read in 49 ms (1 MiB/s)
Odroid # load mmc ${mmcbootdev}:${mmcbootpart} ${kernel_addr_r}
/boot/vmlinuz-${fk_kvers}
4973056 bytes read in 181 ms (26.2 MiB/s)
Odroid # load mmc ${mmcbootdev}:${mmcbootpart} ${ramdisk_addr_r}
/boot/initrd.img-${fk_kvers}
22231585 bytes read in 777 ms (27.3 MiB/s)
Odroid # env set bootargs console=ttySAC1,115200n8
Odroid # env set initrd_high 0x5000
Odroid # bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize}
${fdt_addr_r}
Kernel image @ 0x4100 [ 0x00 - 0x4be200 ]
## Flattened Device Tree blob at 4080
Booting using the fdt blob at 0x4080
Loading Ramdisk to 4eacc000, end 4a21 ... OK
Loading Device Tree to bae6a000, end bae7a0bf ... OK
Starting kernel ...
[ 0.00] Booting Linux on physical CPU 0xa00
The difference between those two runs is the location where U-Boot
loads the
initrd. The parent commit of 4963f63f boots fine without setting
`initrd_high`:
U-Boot 2020.10-rc2-00313-gdfaf6a5797 (Jan 10 2023 - 00:13:19
+0100)
CPU: Exynos4412 @ 1 GHz
Model: Odroid based on Exynos4412
Type: u3
DRAM: 2 GiB
LDO20@VDDQ_EMMC_1.8V: set 180 uV; enabling
LDO22@VDDQ_EMMC_2.8V: set 280 uV; enabling
LDO21@TFLASH_2.8V: set 280 uV; enabling
MMC: SAMSUNG SDHCI: 2, EXYNOS DWMMC: 0
Loading Environment from MMC... *** Warning - bad CRC, using
default
environment
In: serial
Out: serial
Err: serial
Boot device: MMC(2)
Net: No ethernet found.
Hit any key to stop autoboot: 0
Odroid # env set fk_kvers 5.10.0-20-armmp
Odroid # load mmc ${mmcbootdev}:${mmcbootpart} ${fdt_addr_r}
/boot/dtbs/${fk_kvers}/exynos4412-odroidu3.dtb
53440 bytes read in 49 ms (1 MiB/s)
Odroid # load mmc ${mmcbootdev}:${mmcbootpart} ${kernel_addr_r}
/boot/vmlinuz-${fk_kvers}
4973056 bytes read in 181 ms (26.2 MiB/s)
Odroid # load mmc ${mmcbootdev}:${mmcbootpart} ${ramdisk_addr_r}
Re: kernel doesn't start on Odroid U2 unless setting initrd_high
On Wed, Jan 11, 2023 at 12:01:46AM +0100, Joost van Zwieten wrote:
>
>
> On Tue, Jan 10, 2023 at 13:41, Tom Rini wrote:
> > On Tue, Jan 10, 2023 at 09:13:32AM +0100, Joost van Zwieten wrote:
> >
> > > Dear maintainers,
> > >
> > > As of commit 4963f63fe61f15329d77472a762b1d8bf754d24b U-Boot fails
> > > to start
> > > a kernel (with `bootz`) on my Odroid U2 unless I force
> > > `initrd_high`, e.g.
> > > to `0x5000`. With commit 4963f63f and `initrd_high` *unset* I
> > > get the
> > > following output:
> > >
> > > U-Boot 2020.10-rc2-00314-g4963f63fe6 (Jan 09 2023 - 23:59:31
> > > +0100)
> > >
> > > CPU: Exynos4412 @ 1 GHz
> > > Model: Odroid based on Exynos4412
> > > Type: u3
> > > DRAM: 2 GiB
> > > LDO20@VDDQ_EMMC_1.8V: set 180 uV; enabling
> > > LDO22@VDDQ_EMMC_2.8V: set 280 uV; enabling
> > > LDO21@TFLASH_2.8V: set 280 uV; enabling
> > > MMC: SAMSUNG SDHCI: 2, EXYNOS DWMMC: 0
> > > Loading Environment from MMC... *** Warning - bad CRC, using
> > > default
> > > environment
> > >
> > > In: serial
> > > Out: serial
> > > Err: serial
> > > Boot device: MMC(2)
> > > Net: No ethernet found.
> > > Hit any key to stop autoboot: 0
> > > Odroid # env set fk_kvers 5.10.0-20-armmp
> > > Odroid # load mmc ${mmcbootdev}:${mmcbootpart} ${fdt_addr_r}
> > > /boot/dtbs/${fk_kvers}/exynos4412-odroidu3.dtb
> > > 53440 bytes read in 50 ms (1 MiB/s)
> > > Odroid # load mmc ${mmcbootdev}:${mmcbootpart} ${kernel_addr_r}
> > > /boot/vmlinuz-${fk_kvers}
> > > 4973056 bytes read in 182 ms (26.1 MiB/s)
> > > Odroid # load mmc ${mmcbootdev}:${mmcbootpart} ${ramdisk_addr_r}
> > > /boot/initrd.img-${fk_kvers}
> > > 22231585 bytes read in 777 ms (27.3 MiB/s)
> > > Odroid # env set bootargs console=ttySAC1,115200n8
> > > Odroid # bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize}
> > > ${fdt_addr_r}
> > > Kernel image @ 0x4100 [ 0x00 - 0x4be200 ]
> > > ## Flattened Device Tree blob at 4080
> > >Booting using the fdt blob at 0x4080
> > >Loading Ramdisk to b9947000, end bae7aa21 ... OK
> > >Loading Device Tree to b9936000, end b99460bf ... OK
> > >
> > > Starting kernel ...
> > >
> > > And that's all I ever see. Normally the initrd loads a module that
> > > causes an
> > > LED on the Odroid to blink, and this is not happening either, so
> > > I'm pretty
> > > confident the kernel doesn't start or at least crashes before
> > > producing
> > > output. If I set `initrd_high` to `0x5000` (or something in the
> > > neighborhood) the kernel starts just fine:
> > >
> > > U-Boot 2020.10-rc2-00314-g4963f63fe6 (Jan 09 2023 - 23:59:31
> > > +0100)
> > >
> > > CPU: Exynos4412 @ 1 GHz
> > > Model: Odroid based on Exynos4412
> > > Type: u3
> > > DRAM: 2 GiB
> > > LDO20@VDDQ_EMMC_1.8V: set 180 uV; enabling
> > > LDO22@VDDQ_EMMC_2.8V: set 280 uV; enabling
> > > LDO21@TFLASH_2.8V: set 280 uV; enabling
> > > MMC: SAMSUNG SDHCI: 2, EXYNOS DWMMC: 0
> > > Loading Environment from MMC... *** Warning - bad CRC, using
> > > default
> > > environment
> > >
> > > In: serial
> > > Out: serial
> > > Err: serial
> > > Boot device: MMC(2)
> > > Net: No ethernet found.
> > > Hit any key to stop autoboot: 0
> > > Odroid # env set fk_kvers 5.10.0-20-armmp
> > > Odroid # load mmc ${mmcbootdev}:${mmcbootpart} ${fdt_addr_r}
> > > /boot/dtbs/${fk_kvers}/exynos4412-odroidu3.dtb
> > > 53440 bytes read in 49 ms (1 MiB/s)
> > > Odroid # load mmc ${mmcbootdev}:${mmcbootpart} ${kernel_addr_r}
> > > /boot/vmlinuz-${fk_kvers}
> > > 4973056 bytes read in 181 ms (26.2 MiB/s)
> > > Odroid # load mmc ${mmcbootdev}:${mmcbootpart} ${ramdisk_addr_r}
> > > /boot/initrd.img-${fk_kvers}
> > > 22231585 bytes read in 777 ms (27.3 MiB/s)
> > > Odroid # env set bootargs console=ttySAC1,115200n8
> > > Odroid # env set initrd_high 0x5000
> > > Odroid # bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize}
> > > ${fdt_addr_r}
> > > Kernel image @ 0x4100 [ 0x00 - 0x4be200 ]
> > > ## Flattened Device Tree blob at 4080
> > >Booting using the fdt blob at 0x4080
> > >Loading Ramdisk to 4eacc000, end 4a21 ... OK
> > >Loading Device Tree to bae6a000, end bae7a0bf ... OK
> > >
> > > Starting kernel ...
> > >
> > > [ 0.00] Booting Linux on physical CPU 0xa00
> > >
> > >
> > > The difference between those two runs is the location where U-Boot
> > > loads the
> > > initrd. The parent commit of 4963f63f boots fine without setting
> > > `initrd_high`:
> > >
> > > U-Boot 2020.10-rc2-00313-gdfaf6a5797 (Jan 10 2023 - 00:13:19
> > > +0100)
> > >
> > > CPU: Exynos4412 @ 1 GHz
> > > Model: Odroid based on Exynos4412
> > > Type: u3
> > > DRAM: 2 GiB
> > > LDO20@VDDQ_EMMC_1.8V: set 180 uV;
Re: [PATCH] doc: ti: Add switch setting for boot modes on AM62 SK
On 1/10/23 3:25 PM, Judith Mendez wrote: List some common boot modes and their corresponding switch settings for AM62 SK. Signed-off-by: Judith Mendez --- Acked-by: Andrew Davis doc/board/ti/am62x_sk.rst | 29 + 1 file changed, 29 insertions(+) diff --git a/doc/board/ti/am62x_sk.rst b/doc/board/ti/am62x_sk.rst index b1b7d99befb..40d58ea8bfa 100644 --- a/doc/board/ti/am62x_sk.rst +++ b/doc/board/ti/am62x_sk.rst @@ -229,3 +229,32 @@ Image formats: | | SPL DTB 1...N | | | +---+ | +---+ + +Switch Setting for Boot Mode + + +Boot Mode pins provide means to select the boot mode and options before the +device is powered up. After every POR, they are the main source to populate +the Boot Parameter Tables. + +The following table shows some common boot modes used on AM62 platform. More +details can be found in the Technical Reference Manual: +https://www.ti.com/lit/pdf/spruiv7 under the `Boot Mode Pins` section. + ++--+++ +|*Boot Mode* | *SW2* | *SW1* | ++--+++ +| Switch label | 12345678 | 12345678 | ++==+++ +| SD | 0100 | 1110 | ++--+++ +| OSPI | | 11001110 | ++--+++ +| EMMC | | 11010010 | ++--+++ +| UART | | 11011100 | ++--+++ +| USB DFU | | 11001010 | ++--+++ + +For SW2 and SW1, the switch state in the "ON" position = 1.
Re: [PATCH v2 5/5] test: Add sandbox TPM boot measurement
On 1/10/23 23:32, Heinrich Schuchardt wrote:
On 1/9/23 22:55, Eddie James wrote:
Use the sandbox TPM driver to measure some boot images in a unit
test case.
$ ./u-boot -T -c "ut measurement"
Running 1 measurement tests
Test: measure: measurement.c
Failures: 0
Signed-off-by: Eddie James
---
arch/sandbox/dts/test.dts | 12 +++
configs/sandbox_defconfig | 1 +
include/test/suites.h | 1 +
test/boot/Makefile | 1 +
test/boot/measurement.c | 66 +++
test/cmd_ut.c | 2 ++
6 files changed, 83 insertions(+)
create mode 100644 test/boot/measurement.c
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index dffe10adbf..ad90bf0541 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -66,6 +66,17 @@
osd0 = "/osd";
};
+ reserved-memory {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ event_log: tcg_event_log@d0e000 {
+ no-map;
Isn't no-map misplaced? Shouldn't it be a reserved-memory property?
The placement is correct. But I still wonder why we should have this
area as no-map.
If the memory region is not mapped, Linux can never access it as
described in
Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml.
Please, document all changes to the device-tree semantics via patches
for the Linux kernels documentation and provide a full example.
Best regards
Heinrich
Re: [PATCH v2 5/5] test: Add sandbox TPM boot measurement
On 1/9/23 22:55, Eddie James wrote:
Use the sandbox TPM driver to measure some boot images in a unit
test case.
$ ./u-boot -T -c "ut measurement"
Running 1 measurement tests
Test: measure: measurement.c
Failures: 0
Signed-off-by: Eddie James
---
arch/sandbox/dts/test.dts | 12 +++
configs/sandbox_defconfig | 1 +
include/test/suites.h | 1 +
test/boot/Makefile| 1 +
test/boot/measurement.c | 66 +++
test/cmd_ut.c | 2 ++
6 files changed, 83 insertions(+)
create mode 100644 test/boot/measurement.c
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index dffe10adbf..ad90bf0541 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -66,6 +66,17 @@
osd0 = "/osd";
};
+ reserved-memory {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ event_log: tcg_event_log@d0e000 {
+ no-map;
Isn't no-map misplaced? Shouldn't it be a reserved-memory property?
If the memory region is not mapped, Linux can never access it as
described in
Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml.
Please, document all changes to the device-tree semantics via patches
for the Linux kernels documentation and provide a full example.
Best regards
Heinrich
Re: [PATCH v2 5/5] test: Add sandbox TPM boot measurement
On 1/10/23 16:02, Heinrich Schuchardt wrote:
On 1/10/23 17:38, Eddie James wrote:
On 1/9/23 17:26, Heinrich Schuchardt wrote:
On 1/10/23 00:13, Heinrich Schuchardt wrote:
On 1/9/23 22:55, Eddie James wrote:
Use the sandbox TPM driver to measure some boot images in a unit
test case.
$ ./u-boot -T -c "ut measurement"
Running 1 measurement tests
Test: measure: measurement.c
Failures: 0
Signed-off-by: Eddie James
---
arch/sandbox/dts/test.dts | 12 +++
configs/sandbox_defconfig | 1 +
include/test/suites.h | 1 +
test/boot/Makefile | 1 +
test/boot/measurement.c | 66
+++
test/cmd_ut.c | 2 ++
6 files changed, 83 insertions(+)
create mode 100644 test/boot/measurement.c
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index dffe10adbf..ad90bf0541 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -66,6 +66,17 @@
osd0 = "/osd";
};
+ reserved-memory {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ event_log: tcg_event_log@d0e000 {
+ no-map;
+ reg = <0x00d0e000 0x2000>;
How should this work if you don't define linux,sml-base and
linux,sml-size?
I have sent a patch to the linux list for using a reserved memory
region, as I have also added in the u-boot TPM layer for the event log.
https://patchwork.kernel.org/project/linux-integrity/patch/20230103162010.381214-1-eaja...@linux.ibm.com/
Thank you for the clarification.
The kernel patch seems to need rework:
https://lore.kernel.org/all/202301040834.ysmhdmpw-...@intel.com/
Yes I'll address that.
Shouldn't the sandbox device-tree support these properties? This will
allow us to write a test application that the sandbox can run via
booti/bootz (depending on bitness) and bootm. This test application can
retrieve the event log and print it via Linux system calls.
OK, I can add it to the main sandbox device-tree as well then. It is
added to the sandbox test device-tree, used by the unit test case I added.
Thanks,
Eddie
Best regards
Heinrich
Re: [PATCH v2 0/5] tpm: Support boot measurements
On 1/10/23 22:42, Eddie James wrote: On 1/9/23 17:35, Heinrich Schuchardt wrote: On 1/9/23 22:55, Eddie James wrote: This series adds support for measuring the boot images more generically than the existing EFI support. Several EFI functions have been moved to the TPM layer. The series includes optional measurement from the bootm command. A new test case has been added for the bootm measurement to test the new path, and the sandbox TPM2 driver has been updated to support this use case. Changes since v1: - Refactor TPM layer functions to allow EFI system to use them, and remove duplicate EFI functions. - Add test case - Drop #ifdefs for bootm - Add devicetree measurement config option - Update sandbox TPM driver This looks like a useful feature to me. Some questions remain: How about the booti and bootz commands. Are they covered by the change? No, not yet. Please, add the measurements in common code for all boot commands (except bootefi). What are the consequences of your changes for UEFI FIT images (cf. CONFIG_BOOTM_EFI)? I suppose the image would be measured twice, but only if the user selected both of the relevant config options. We should have a test case for this. Best regards Heinrich
Re: [PATCH v2 5/5] test: Add sandbox TPM boot measurement
On 1/10/23 17:38, Eddie James wrote:
On 1/9/23 17:26, Heinrich Schuchardt wrote:
On 1/10/23 00:13, Heinrich Schuchardt wrote:
On 1/9/23 22:55, Eddie James wrote:
Use the sandbox TPM driver to measure some boot images in a unit
test case.
$ ./u-boot -T -c "ut measurement"
Running 1 measurement tests
Test: measure: measurement.c
Failures: 0
Signed-off-by: Eddie James
---
arch/sandbox/dts/test.dts | 12 +++
configs/sandbox_defconfig | 1 +
include/test/suites.h | 1 +
test/boot/Makefile | 1 +
test/boot/measurement.c | 66
+++
test/cmd_ut.c | 2 ++
6 files changed, 83 insertions(+)
create mode 100644 test/boot/measurement.c
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index dffe10adbf..ad90bf0541 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -66,6 +66,17 @@
osd0 = "/osd";
};
+ reserved-memory {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ event_log: tcg_event_log@d0e000 {
+ no-map;
+ reg = <0x00d0e000 0x2000>;
How should this work if you don't define linux,sml-base and
linux,sml-size?
I have sent a patch to the linux list for using a reserved memory
region, as I have also added in the u-boot TPM layer for the event log.
https://patchwork.kernel.org/project/linux-integrity/patch/20230103162010.381214-1-eaja...@linux.ibm.com/
Thank you for the clarification.
The kernel patch seems to need rework:
https://lore.kernel.org/all/202301040834.ysmhdmpw-...@intel.com/
Shouldn't the sandbox device-tree support these properties? This will
allow us to write a test application that the sandbox can run via
booti/bootz (depending on bitness) and bootm. This test application can
retrieve the event log and print it via Linux system calls.
Best regards
Heinrich
Re: [PATCH v2 0/5] tpm: Support boot measurements
On 1/9/23 17:35, Heinrich Schuchardt wrote: On 1/9/23 22:55, Eddie James wrote: This series adds support for measuring the boot images more generically than the existing EFI support. Several EFI functions have been moved to the TPM layer. The series includes optional measurement from the bootm command. A new test case has been added for the bootm measurement to test the new path, and the sandbox TPM2 driver has been updated to support this use case. Changes since v1: - Refactor TPM layer functions to allow EFI system to use them, and remove duplicate EFI functions. - Add test case - Drop #ifdefs for bootm - Add devicetree measurement config option - Update sandbox TPM driver This looks like a useful feature to me. Some questions remain: How about the booti and bootz commands. Are they covered by the change? No, not yet. What are the consequences of your changes for UEFI FIT images (cf. CONFIG_BOOTM_EFI)? I suppose the image would be measured twice, but only if the user selected both of the relevant config options. Eddie James (5): tpm: Fix spelling for tpmu_ha union tpm: Support boot measurements bootm: Support boot measurement tpm: sandbox: Update for needed TPM2 capabilities test: Add sandbox TPM boot measurement I am missing the documentation changes. These should describe which changes in the device-tree and in the configuration are needed to enable measurements. This should be in doc/usage/ Sure. Thanks, Eddie @Ilias: Could you contribute the UEFI part for the document, please. Best regards Heinrich arch/sandbox/dts/test.dts | 12 + boot/Kconfig | 23 ++ boot/bootm.c | 64 +++ cmd/bootm.c | 2 + configs/sandbox_defconfig | 1 + drivers/tpm/tpm2_tis_sandbox.c | 100 +++-- include/bootm.h | 2 + include/efi_tcg2.h | 44 -- include/image.h | 1 + include/test/suites.h | 1 + include/tpm-v2.h | 215 +- lib/efi_loader/efi_tcg2.c | 362 + lib/tpm-v2.c | 708 + test/boot/Makefile | 1 + test/boot/measurement.c | 66 +++ test/cmd_ut.c | 2 + 16 files changed, 1187 insertions(+), 417 deletions(-) create mode 100644 test/boot/measurement.c
Re: [PATCH v3 2/2] serial: mxc: Speed-up character transmission
On Tue, Jan 10, 2023 at 4:24 PM Loic Poulain wrote: > > Instead of waiting for empty FIFO condition before writing a > character, wait for non-full FIFO condition. > > This helps in saving several tens of milliseconds during boot > (depending verbosity). > > Signed-off-by: Loic Poulain > Tested-by: Lothar Waßmann > --- > v2: fixing transfert abort & char corruption commit > v3: Reordering commits for good bisectability Reviewed-by: Fabio Estevam Thanks
Re: [PATCH v3 1/2] serial: mxc: Wait for TX completion before reset
[Adding Johannes and Tim] On Tue, Jan 10, 2023 at 4:24 PM Loic Poulain wrote: > > The u-boot console may show some corrupted characters when > printing in board_init() due to reset of the UART (probe) > before the TX FIFO has been completely drained. > > To fix this issue, and in case UART is still running, we now > try to flush the FIFO before proceeding to UART reinitialization. > For this we're waiting for Transmitter Complete bit, indicating > that the FIFO and the shift register are empty. > > flushing has a 4ms timeout guard, which is normally more than > enough to consume the FIFO @ low baudrate (9600bps). > > Signed-off-by: Loic Poulain > Tested-by: Lothar Waßmann > --- > v2: Add this commit to the series > v3: Fix typo & reordering commits for good bisectability Reviewed-by: Fabio Estevam Thanks
Re: [PATCH v3] imx8mm-phg: Add board support
On Tue, Jan 10, 2023 at 05:18:08PM -0300, Fabio Estevam wrote: > Add the board support for the i.MX8MM Cloos PHG board. > > This board uses a imx8mm-tqma8mqml SoM from TQ-Group. > > imx8mm-phg.dts and imx8mm-tqma8mqml.dtsi are taken > directly from Linux 6.2-rc3. > > Signed-off-by: Fabio Estevam Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature
[PATCH v3] imx8mm-phg: Add board support
Add the board support for the i.MX8MM Cloos PHG board.
This board uses a imx8mm-tqma8mqml SoM from TQ-Group.
imx8mm-phg.dts and imx8mm-tqma8mqml.dtsi are taken
directly from Linux 6.2-rc3.
Signed-off-by: Fabio Estevam
---
Changes since v2:
- Convert to a text environment file (Tom).
arch/arm/dts/Makefile |1 +
arch/arm/dts/imx8mm-phg-u-boot.dtsi | 137 ++
arch/arm/dts/imx8mm-phg.dts | 266 +++
arch/arm/dts/imx8mm-tqma8mqml.dtsi| 341 +++
arch/arm/mach-imx/imx8m/Kconfig |8 +
board/cloos/imx8mm_phg/Kconfig| 15 +
board/cloos/imx8mm_phg/MAINTAINERS|6 +
board/cloos/imx8mm_phg/Makefile | 12 +
board/cloos/imx8mm_phg/imx8mm_phg.c | 50 +
board/cloos/imx8mm_phg/imx8mm_phg.env |9 +
.../cloos/imx8mm_phg/imximage-8mm-lpddr4.cfg |8 +
board/cloos/imx8mm_phg/lpddr4_timing.c| 1846 +
board/cloos/imx8mm_phg/spl.c | 147 ++
configs/imx8mm_phg_defconfig | 120 ++
doc/board/cloos/imx8mm_phg.rst| 55 +
doc/board/cloos/index.rst |9 +
doc/board/index.rst |1 +
include/configs/imx8mm_phg.h | 41 +
18 files changed, 3072 insertions(+)
create mode 100644 arch/arm/dts/imx8mm-phg-u-boot.dtsi
create mode 100644 arch/arm/dts/imx8mm-phg.dts
create mode 100644 arch/arm/dts/imx8mm-tqma8mqml.dtsi
create mode 100644 board/cloos/imx8mm_phg/Kconfig
create mode 100644 board/cloos/imx8mm_phg/MAINTAINERS
create mode 100644 board/cloos/imx8mm_phg/Makefile
create mode 100644 board/cloos/imx8mm_phg/imx8mm_phg.c
create mode 100644 board/cloos/imx8mm_phg/imx8mm_phg.env
create mode 100644 board/cloos/imx8mm_phg/imximage-8mm-lpddr4.cfg
create mode 100644 board/cloos/imx8mm_phg/lpddr4_timing.c
create mode 100644 board/cloos/imx8mm_phg/spl.c
create mode 100644 configs/imx8mm_phg_defconfig
create mode 100644 doc/board/cloos/imx8mm_phg.rst
create mode 100644 doc/board/cloos/index.rst
create mode 100644 include/configs/imx8mm_phg.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index b3baaf4829..560070f187 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -955,6 +955,7 @@ dtb-$(CONFIG_ARCH_IMX8M) += \
imx8mm-kontron-bl.dtb \
imx8mm-kontron-bl-osm-s.dtb \
imx8mm-mx8menlo.dtb \
+ imx8mm-phg.dtb \
imx8mm-venice.dtb \
imx8mm-venice-gw71xx-0x.dtb \
imx8mm-venice-gw72xx-0x.dtb \
diff --git a/arch/arm/dts/imx8mm-phg-u-boot.dtsi
b/arch/arm/dts/imx8mm-phg-u-boot.dtsi
new file mode 100644
index 00..3bf45ef4a6
--- /dev/null
+++ b/arch/arm/dts/imx8mm-phg-u-boot.dtsi
@@ -0,0 +1,137 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2019 NXP
+ */
+
+#include "imx8mm-u-boot.dtsi"
+
+/ {
+ wdt-reboot {
+ compatible = "wdt-reboot";
+ wdt = <>;
+ u-boot,dm-spl;
+ };
+
+ firmware {
+ optee {
+ compatible = "linaro,optee-tz";
+ method = "smc";
+ };
+ };
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+_usdhc2_vmmc {
+ u-boot,off-on-delay-us = <2>;
+};
+
+_reg_usdhc2_vmmc {
+ u-boot,dm-spl;
+};
+
+_uart2 {
+ u-boot,dm-spl;
+};
+
+_usdhc2_gpio {
+ u-boot,dm-spl;
+};
+
+_usdhc2 {
+ u-boot,dm-spl;
+};
+
+_usdhc3 {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+ sd-uhs-sdr104;
+ sd-uhs-ddr50;
+ assigned-clocks = < IMX8MM_CLK_USDHC2>;
+ assigned-clock-rates = <4>;
+ assigned-clock-parents = < IMX8MM_SYS_PLL1_400M>;
+};
+
+ {
+ u-boot,dm-spl;
+ mmc-hs400-1_8v;
+ mmc-hs400-enhanced-strobe;
+ /*
+* prevents voltage switch warn: driver will switch even at
+* fixed voltage
+*/
+ /delete-property/ vmmc-supply;
+ /delete-property/ vqmmc-supply;
+ assigned-clocks = < IMX8MM_CLK_USDHC3>;
+ assigned-clock-rates = <4>;
+ assigned-clock-parents = < IMX8MM_SYS_PLL1_400M>;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+&{/soc@0/bus@3080/i2c@30a2/pmic@25} {
+ u-boot,dm-spl;
+};
+
+&{/soc@0/bus@3080/i2c@30a2/pmic@25/regulators} {
+ u-boot,dm-spl;
+};
+
+_i2c1 {
+ u-boot,dm-spl;
+};
+
+_pmic {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
diff --git a/arch/arm/dts/imx8mm-phg.dts b/arch/arm/dts/imx8mm-phg.dts
new file mode 100644
index 00..e9447738b1
--- /dev/null
+++
Re: [PATCH 0/8] env: mmc: improvements and corrections
On Thu, 10 Nov 2022 11:48:57 +0100, Patrick Delaunay wrote: > Update in U-Boot env mmc backend with several cosmetic changes or > corrections and 2 new features: > > 1/ CONFIG_ENV_MMC_USE_DT = no more use CONFIG_ENV_OFFSET >in the mmc ENV backend when this config is activated. > >Requested by the STM32MP STMicroelectronics boards which activate >several ENV_IS_IN_XXX; the value of CONFIG_ENV_OFFSET is invalid for >SD-Card / eMMC boot; this offset should only used in SPIFlash backend >(sf.c) for SPI-NOR boot. > > [...] Applied to u-boot/master, thanks! -- Tom
[PATCH v3 2/2] serial: mxc: Speed-up character transmission
Instead of waiting for empty FIFO condition before writing a
character, wait for non-full FIFO condition.
This helps in saving several tens of milliseconds during boot
(depending verbosity).
Signed-off-by: Loic Poulain
Tested-by: Lothar Waßmann
---
v2: fixing transfert abort & char corruption commit
v3: Reordering commits for good bisectability
drivers/serial/serial_mxc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/serial/serial_mxc.c b/drivers/serial/serial_mxc.c
index 3c89781f2c..9899155c00 100644
--- a/drivers/serial/serial_mxc.c
+++ b/drivers/serial/serial_mxc.c
@@ -238,11 +238,11 @@ static void mxc_serial_putc(const char c)
if (c == '\n')
serial_putc('\r');
- writel(c, _base->txd);
-
/* wait for transmitter to be ready */
- while (!(readl(_base->ts) & UTS_TXEMPTY))
+ while (readl(_base->ts) & UTS_TXFULL)
schedule();
+
+ writel(c, _base->txd);
}
/* Test whether a character is in the RX buffer */
@@ -333,7 +333,7 @@ static int mxc_serial_putc(struct udevice *dev, const char
ch)
struct mxc_serial_plat *plat = dev_get_plat(dev);
struct mxc_uart *const uart = plat->reg;
- if (!(readl(>ts) & UTS_TXEMPTY))
+ if (readl(>ts) & UTS_TXFULL)
return -EAGAIN;
writel(ch, >txd);
--
2.34.1
[PATCH v3 1/2] serial: mxc: Wait for TX completion before reset
The u-boot console may show some corrupted characters when
printing in board_init() due to reset of the UART (probe)
before the TX FIFO has been completely drained.
To fix this issue, and in case UART is still running, we now
try to flush the FIFO before proceeding to UART reinitialization.
For this we're waiting for Transmitter Complete bit, indicating
that the FIFO and the shift register are empty.
flushing has a 4ms timeout guard, which is normally more than
enough to consume the FIFO @ low baudrate (9600bps).
Signed-off-by: Loic Poulain
Tested-by: Lothar Waßmann
---
v2: Add this commit to the series
v3: Fix typo & reordering commits for good bisectability
drivers/serial/serial_mxc.c | 24 +++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/drivers/serial/serial_mxc.c b/drivers/serial/serial_mxc.c
index 82c0d84628..3c89781f2c 100644
--- a/drivers/serial/serial_mxc.c
+++ b/drivers/serial/serial_mxc.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
/* UART Control Register Bit Fields.*/
#define URXD_CHARRDY (1<<15)
@@ -144,8 +145,22 @@ struct mxc_uart {
u32 ts;
};
+static void _mxc_serial_flush(struct mxc_uart *base)
+{
+ unsigned int timeout = 4000;
+
+ if (!(readl(>cr1) & UCR1_UARTEN) ||
+ !(readl(>cr2) & UCR2_TXEN))
+ return;
+
+ while (!(readl(>sr2) & USR2_TXDC) && --timeout)
+ udelay(1);
+}
+
static void _mxc_serial_init(struct mxc_uart *base, int use_dte)
{
+ _mxc_serial_flush(base);
+
writel(0, >cr1);
writel(0, >cr2);
@@ -252,10 +267,17 @@ static int mxc_serial_init(void)
return 0;
}
+static int mxc_serial_stop(void)
+{
+ _mxc_serial_flush(mxc_base);
+
+ return 0;
+}
+
static struct serial_device mxc_serial_drv = {
.name = "mxc_serial",
.start = mxc_serial_init,
- .stop = NULL,
+ .stop = mxc_serial_stop,
.setbrg = mxc_serial_setbrg,
.putc = mxc_serial_putc,
.puts = default_serial_puts,
--
2.34.1
[PATCH v2 2/2] serial: mxc: Wait for TX completion before reset
The u-boot console may show some corrupted characters when
printing in board_init() due to reset of the UART (probe)
before the TX FIFO has been completely drained.
To fix this issue, and in case UART is still running, we now
try to flush the FIFO before proceding to UART reinitialization.
For this we're waiting for Transmitter Complete bit, indicating
that the FIFO and the shift register are empty.
flushing has a 4ms timeout guard, which is normally more than
enough to consume the FIFO @ low baudrate (9600bps).
Signed-off-by: Loic Poulain
---
v2: Add this commit to the series
drivers/serial/serial_mxc.c | 24 +++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/drivers/serial/serial_mxc.c b/drivers/serial/serial_mxc.c
index f8c49865be..9899155c00 100644
--- a/drivers/serial/serial_mxc.c
+++ b/drivers/serial/serial_mxc.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
/* UART Control Register Bit Fields.*/
#define URXD_CHARRDY (1<<15)
@@ -144,8 +145,22 @@ struct mxc_uart {
u32 ts;
};
+static void _mxc_serial_flush(struct mxc_uart *base)
+{
+ unsigned int timeout = 4000;
+
+ if (!(readl(>cr1) & UCR1_UARTEN) ||
+ !(readl(>cr2) & UCR2_TXEN))
+ return;
+
+ while (!(readl(>sr2) & USR2_TXDC) && --timeout)
+ udelay(1);
+}
+
static void _mxc_serial_init(struct mxc_uart *base, int use_dte)
{
+ _mxc_serial_flush(base);
+
writel(0, >cr1);
writel(0, >cr2);
@@ -252,10 +267,17 @@ static int mxc_serial_init(void)
return 0;
}
+static int mxc_serial_stop(void)
+{
+ _mxc_serial_flush(mxc_base);
+
+ return 0;
+}
+
static struct serial_device mxc_serial_drv = {
.name = "mxc_serial",
.start = mxc_serial_init,
- .stop = NULL,
+ .stop = mxc_serial_stop,
.setbrg = mxc_serial_setbrg,
.putc = mxc_serial_putc,
.puts = default_serial_puts,
--
2.34.1
[PATCH v2 1/2] serial: mxc: Speed-up character transmission
Instead of waiting for empty FIFO condition before writing a
character, wait for non-full FIFO condition.
This helps in saving several tens of milliseconds during boot
(depending verbosity).
Signed-off-by: Loic Poulain
---
v2: Add 2/2 fixing transfert abort & char corruption
drivers/serial/serial_mxc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/serial/serial_mxc.c b/drivers/serial/serial_mxc.c
index 82c0d84628..f8c49865be 100644
--- a/drivers/serial/serial_mxc.c
+++ b/drivers/serial/serial_mxc.c
@@ -223,11 +223,11 @@ static void mxc_serial_putc(const char c)
if (c == '\n')
serial_putc('\r');
- writel(c, _base->txd);
-
/* wait for transmitter to be ready */
- while (!(readl(_base->ts) & UTS_TXEMPTY))
+ while (readl(_base->ts) & UTS_TXFULL)
schedule();
+
+ writel(c, _base->txd);
}
/* Test whether a character is in the RX buffer */
@@ -311,7 +311,7 @@ static int mxc_serial_putc(struct udevice *dev, const char
ch)
struct mxc_serial_plat *plat = dev_get_plat(dev);
struct mxc_uart *const uart = plat->reg;
- if (!(readl(>ts) & UTS_TXEMPTY))
+ if (readl(>ts) & UTS_TXFULL)
return -EAGAIN;
writel(ch, >txd);
--
2.34.1
Re: [PATCH v2 2/2] serial: mxc: Wait for TX completion before reset
On Tue, 10 Jan 2023 at 13:57, Fabio Estevam wrote: > > > For this we're waiting for Transmitter Complete bit, indicating > > that the FIFO and the shift register are empty. > > > > flushing has a 4ms timeout guard, which is normally more than > > enough to consume the FIFO @ low baudrate (9600bps). > > > > Signed-off-by: Loic Poulain > > --- > > v2: Add this commit to the series > > Should this patch come first in the series? > > In case someone is bisecting, the current patch 1/2 may cause serial > corruption, > which is fixed by 2/2. > > Can we avoid corruption by swapping the order of these patches? Indeed, sending a v3. Thanks, Loic
Re: kernel doesn't start on Odroid U2 unless setting initrd_high
On Tue, Jan 10, 2023 at 09:13:32AM +0100, Joost van Zwieten wrote:
> Dear maintainers,
>
> As of commit 4963f63fe61f15329d77472a762b1d8bf754d24b U-Boot fails to start
> a kernel (with `bootz`) on my Odroid U2 unless I force `initrd_high`, e.g.
> to `0x5000`. With commit 4963f63f and `initrd_high` *unset* I get the
> following output:
>
>U-Boot 2020.10-rc2-00314-g4963f63fe6 (Jan 09 2023 - 23:59:31 +0100)
>
>CPU: Exynos4412 @ 1 GHz
>Model: Odroid based on Exynos4412
>Type: u3
>DRAM: 2 GiB
>LDO20@VDDQ_EMMC_1.8V: set 180 uV; enabling
>LDO22@VDDQ_EMMC_2.8V: set 280 uV; enabling
>LDO21@TFLASH_2.8V: set 280 uV; enabling
>MMC: SAMSUNG SDHCI: 2, EXYNOS DWMMC: 0
>Loading Environment from MMC... *** Warning - bad CRC, using default
> environment
>
>In: serial
>Out: serial
>Err: serial
>Boot device: MMC(2)
>Net: No ethernet found.
>Hit any key to stop autoboot: 0
>Odroid # env set fk_kvers 5.10.0-20-armmp
>Odroid # load mmc ${mmcbootdev}:${mmcbootpart} ${fdt_addr_r}
> /boot/dtbs/${fk_kvers}/exynos4412-odroidu3.dtb
>53440 bytes read in 50 ms (1 MiB/s)
>Odroid # load mmc ${mmcbootdev}:${mmcbootpart} ${kernel_addr_r}
> /boot/vmlinuz-${fk_kvers}
>4973056 bytes read in 182 ms (26.1 MiB/s)
>Odroid # load mmc ${mmcbootdev}:${mmcbootpart} ${ramdisk_addr_r}
> /boot/initrd.img-${fk_kvers}
>22231585 bytes read in 777 ms (27.3 MiB/s)
>Odroid # env set bootargs console=ttySAC1,115200n8
>Odroid # bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize}
> ${fdt_addr_r}
>Kernel image @ 0x4100 [ 0x00 - 0x4be200 ]
>## Flattened Device Tree blob at 4080
> Booting using the fdt blob at 0x4080
> Loading Ramdisk to b9947000, end bae7aa21 ... OK
> Loading Device Tree to b9936000, end b99460bf ... OK
>
>Starting kernel ...
>
> And that's all I ever see. Normally the initrd loads a module that causes an
> LED on the Odroid to blink, and this is not happening either, so I'm pretty
> confident the kernel doesn't start or at least crashes before producing
> output. If I set `initrd_high` to `0x5000` (or something in the
> neighborhood) the kernel starts just fine:
>
>U-Boot 2020.10-rc2-00314-g4963f63fe6 (Jan 09 2023 - 23:59:31 +0100)
>
>CPU: Exynos4412 @ 1 GHz
>Model: Odroid based on Exynos4412
>Type: u3
>DRAM: 2 GiB
>LDO20@VDDQ_EMMC_1.8V: set 180 uV; enabling
>LDO22@VDDQ_EMMC_2.8V: set 280 uV; enabling
>LDO21@TFLASH_2.8V: set 280 uV; enabling
>MMC: SAMSUNG SDHCI: 2, EXYNOS DWMMC: 0
>Loading Environment from MMC... *** Warning - bad CRC, using default
> environment
>
>In: serial
>Out: serial
>Err: serial
>Boot device: MMC(2)
>Net: No ethernet found.
>Hit any key to stop autoboot: 0
>Odroid # env set fk_kvers 5.10.0-20-armmp
>Odroid # load mmc ${mmcbootdev}:${mmcbootpart} ${fdt_addr_r}
> /boot/dtbs/${fk_kvers}/exynos4412-odroidu3.dtb
>53440 bytes read in 49 ms (1 MiB/s)
>Odroid # load mmc ${mmcbootdev}:${mmcbootpart} ${kernel_addr_r}
> /boot/vmlinuz-${fk_kvers}
>4973056 bytes read in 181 ms (26.2 MiB/s)
>Odroid # load mmc ${mmcbootdev}:${mmcbootpart} ${ramdisk_addr_r}
> /boot/initrd.img-${fk_kvers}
>22231585 bytes read in 777 ms (27.3 MiB/s)
>Odroid # env set bootargs console=ttySAC1,115200n8
>Odroid # env set initrd_high 0x5000
>Odroid # bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize}
> ${fdt_addr_r}
>Kernel image @ 0x4100 [ 0x00 - 0x4be200 ]
>## Flattened Device Tree blob at 4080
> Booting using the fdt blob at 0x4080
> Loading Ramdisk to 4eacc000, end 4a21 ... OK
> Loading Device Tree to bae6a000, end bae7a0bf ... OK
>
>Starting kernel ...
>
>[ 0.00] Booting Linux on physical CPU 0xa00
>
>
> The difference between those two runs is the location where U-Boot loads the
> initrd. The parent commit of 4963f63f boots fine without setting
> `initrd_high`:
>
>U-Boot 2020.10-rc2-00313-gdfaf6a5797 (Jan 10 2023 - 00:13:19 +0100)
>
>CPU: Exynos4412 @ 1 GHz
>Model: Odroid based on Exynos4412
>Type: u3
>DRAM: 2 GiB
>LDO20@VDDQ_EMMC_1.8V: set 180 uV; enabling
>LDO22@VDDQ_EMMC_2.8V: set 280 uV; enabling
>LDO21@TFLASH_2.8V: set 280 uV; enabling
>MMC: SAMSUNG SDHCI: 2, EXYNOS DWMMC: 0
>Loading Environment from MMC... *** Warning - bad CRC, using default
> environment
>
>In: serial
>Out: serial
>Err: serial
>Boot device: MMC(2)
>Net: No ethernet found.
>Hit any key to stop autoboot: 0
>Odroid # env set fk_kvers 5.10.0-20-armmp
>Odroid # load mmc ${mmcbootdev}:${mmcbootpart} ${fdt_addr_r}
> /boot/dtbs/${fk_kvers}/exynos4412-odroidu3.dtb
>53440 bytes read in 49 ms (1 MiB/s)
>Odroid # load mmc ${mmcbootdev}:${mmcbootpart} ${kernel_addr_r}
> /boot/vmlinuz-${fk_kvers}
>4973056 bytes read in 181 ms (26.2 MiB/s)
>
Re: [PATCH] net: zynq_gem: Wait for SGMII PCS link in zynq_gem_init()
On 1/10/23 05:38, Stefan Roese wrote:
> In our system using ZynqMP with an external SGMII PHY it's necessary
> to wait for the PCS link and auto negotiation to finish before the xfer
> starts. Otherwise the first packet(s) might get dropped, resulting in a
> delay at the start of the ethernet transfers.
>
> This patch adds the necessary code at the end of zynq_gem_init()
> including a minimal delay of 10ms which fixes problems of dropped
> first packages.
>
> Signed-off-by: Stefan Roese
> Cc: Michal Simek
> Cc: T Karthik Reddy
> Cc: Ramon Fried
> ---
> drivers/net/zynq_gem.c | 32 +++-
> 1 file changed, 31 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/zynq_gem.c b/drivers/net/zynq_gem.c
> index 507b19b75975..625b0303d6e2 100644
> --- a/drivers/net/zynq_gem.c
> +++ b/drivers/net/zynq_gem.c
> @@ -125,6 +125,10 @@
> */
> #define PHY_DETECT_MASK 0x1808
>
> +/* PCS (SGMII) Link Status */
> +#define ZYNQ_GEM_PCSSTATUS_LINK BIT(2)
> +#define ZYNQ_GEM_PCSSTATUS_ANEG_COMPLBIT(5)
> +
> /* TX BD status masks */
> #define ZYNQ_GEM_TXBUF_FRMLEN_MASK 0x07ff
> #define ZYNQ_GEM_TXBUF_EXHAUSTED 0x0800
> @@ -164,7 +168,8 @@ struct zynq_gem_regs {
> u32 stat[STAT_SIZE]; /* 0x100 - Octects transmitted Low reg */
> u32 reserved9[20];
> u32 pcscntrl;
> - u32 rserved12[36];
> + u32 pcsstatus;
> + u32 rserved12[35];
> u32 dcfg6; /* 0x294 Design config reg6 */
> u32 reserved7[106];
> u32 transmit_q1_ptr; /* 0x440 - Transmit priority queue 1 */
> @@ -522,6 +527,31 @@ static int zynq_gem_init(struct udevice *dev)
> return ret;
> }
> }
> +
> + /* Wait for SGMII link */
> + if (priv->interface == PHY_INTERFACE_MODE_SGMII && priv->int_pcs) {
> + u32 pcsstatus;
> +
> + if (priv->phydev->phy_id == PHY_FIXED_ID)
> + pcsstatus = ZYNQ_GEM_PCSSTATUS_LINK;
> + else
> + pcsstatus = ZYNQ_GEM_PCSSTATUS_LINK |
> + ZYNQ_GEM_PCSSTATUS_ANEG_COMPL;
Use BMSR_LSTATUS/BMSR_ANEGCOMPLETE.
> +
> + ret = wait_for_bit_le32(>pcsstatus, pcsstatus,
> + true, 5000, true);
> + if (ret) {
> + dev_err(dev, "no PCS (SGMII) link detected\n");
This should be an info or lower, since this is normal behavior when there
is no link partner (e.g. when the cable is unplugged).
--Seam
> + return ret;
> + }
> +
> + /*
> + * Some additional minimal delay seems to be needed so that
> + * the first packet will be sent correctly
> + */
> + mdelay(10);
> + }
> +
> setbits_le32(>nwctrl, ZYNQ_GEM_NWCTRL_RXEN_MASK |
> ZYNQ_GEM_NWCTRL_TXEN_MASK);
>
[PATCH] firmware: ti_sci: fix typo in boot authentication message name
Fix AUTH_BOOT message identifier (s/IMIAGE/IMAGE)
Signed-off-by: Jorge Ramirez-Ortiz
Reviewed-by: Oleksandr Suvorov
Acked-by: Andrew Davis
---
drivers/firmware/ti_sci.c | 2 +-
drivers/firmware/ti_sci.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
index 727e090e8a..bd7379ae55 100644
--- a/drivers/firmware/ti_sci.c
+++ b/drivers/firmware/ti_sci.c
@@ -1935,7 +1935,7 @@ static int ti_sci_cmd_proc_auth_boot_image(const struct
ti_sci_handle *handle,
info = handle_to_ti_sci_info(handle);
- xfer = ti_sci_setup_one_xfer(info, TISCI_MSG_PROC_AUTH_BOOT_IMIAGE,
+ xfer = ti_sci_setup_one_xfer(info, TISCI_MSG_PROC_AUTH_BOOT_IMAGE,
TI_SCI_FLAG_REQ_ACK_ON_PROCESSED,
(u32 *), sizeof(req), sizeof(*resp));
if (IS_ERR(xfer)) {
diff --git a/drivers/firmware/ti_sci.h b/drivers/firmware/ti_sci.h
index e4a087c2ba..101210eb21 100644
--- a/drivers/firmware/ti_sci.h
+++ b/drivers/firmware/ti_sci.h
@@ -49,7 +49,7 @@
#define TISCI_MSG_PROC_HANDOVER0xc005
#define TISCI_MSG_SET_PROC_BOOT_CONFIG 0xc100
#define TISCI_MSG_SET_PROC_BOOT_CTRL 0xc101
-#define TISCI_MSG_PROC_AUTH_BOOT_IMIAGE0xc120
+#define TISCI_MSG_PROC_AUTH_BOOT_IMAGE 0xc120
#define TISCI_MSG_GET_PROC_BOOT_STATUS 0xc400
#define TISCI_MSG_WAIT_PROC_BOOT_STATUS0xc401
--
2.34.1
Re: [PATCH] firmware: ti_sci: fix typo in boot authentication message name
On 10/01/23, Andrew Davis wrote:
> On 1/10/23 6:30 AM, Jorge Ramirez-Ortiz wrote:
> > Fix AUTH_BOOT message identifier (s/IMIAGE/IMAGE)
> >
> > Signed-off-by: Jorge Ramirez-Ortiz
> > ---
>
> Looks like this typo got copy/pasted over to ATF also[0]..
> I'll add your reported-by and go fix it over there
> (unless you are wanting to do that).
no no, please do. I was just reading code for secure boot and this typo was
annoying me for some reason (go figure..)
thanks!
>
> Acked-by: Andrew Davis
>
> [0]
> https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/plat/ti/k3/common/drivers/ti_sci/ti_sci_protocol.h#n50
>
> > drivers/firmware/ti_sci.c | 2 +-
> > drivers/firmware/ti_sci.h | 2 +-
> > 2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
> > index 727e090e8a..bd7379ae55 100644
> > --- a/drivers/firmware/ti_sci.c
> > +++ b/drivers/firmware/ti_sci.c
> > @@ -1935,7 +1935,7 @@ static int ti_sci_cmd_proc_auth_boot_image(const
> > struct ti_sci_handle *handle,
> > info = handle_to_ti_sci_info(handle);
> > - xfer = ti_sci_setup_one_xfer(info, TISCI_MSG_PROC_AUTH_BOOT_IMIAGE,
> > + xfer = ti_sci_setup_one_xfer(info, TISCI_MSG_PROC_AUTH_BOOT_IMAGE,
> > TI_SCI_FLAG_REQ_ACK_ON_PROCESSED,
> > (u32 *), sizeof(req), sizeof(*resp));
> > if (IS_ERR(xfer)) {
> > diff --git a/drivers/firmware/ti_sci.h b/drivers/firmware/ti_sci.h
> > index e4a087c2ba..101210eb21 100644
> > --- a/drivers/firmware/ti_sci.h
> > +++ b/drivers/firmware/ti_sci.h
> > @@ -49,7 +49,7 @@
> > #define TISCI_MSG_PROC_HANDOVER 0xc005
> > #define TISCI_MSG_SET_PROC_BOOT_CONFIG0xc100
> > #define TISCI_MSG_SET_PROC_BOOT_CTRL 0xc101
> > -#define TISCI_MSG_PROC_AUTH_BOOT_IMIAGE0xc120
> > +#define TISCI_MSG_PROC_AUTH_BOOT_IMAGE 0xc120
> > #define TISCI_MSG_GET_PROC_BOOT_STATUS0xc400
> > #define TISCI_MSG_WAIT_PROC_BOOT_STATUS 0xc401
Re: [PATCH v2] usb: gadget: dwc2_udc_otg: implement pullup()
On 1/10/23 17:29, Mattijs Korpershoek wrote:
[...]
diff --git a/drivers/usb/gadget/dwc2_udc_otg.c
b/drivers/usb/gadget/dwc2_udc_otg.c
index 77988f78ab30..d0a9be49ad9c 100644
--- a/drivers/usb/gadget/dwc2_udc_otg.c
+++ b/drivers/usb/gadget/dwc2_udc_otg.c
@@ -236,6 +236,14 @@ static int udc_enable(struct dwc2_udc *dev)
return 0;
}
+static int dwc2_gadget_pullup(struct usb_gadget *g, int is_on)
+{
+ clrsetbits_le32(>dctl, SOFT_DISCONNECT,
+ (!is_on) << SOFT_DISCONNECT_BIT);
Use
is_on ? 0 : SOFT_DISCONNECT
and you get rid of SOFT_DISCONNECT_BIT macro and the extra parenthesis
around (!is_on) which are not needed.
Re: [PATCH 11/19] usb: musb: Rename CONFIG_USB_MUSB_TIMEOUT to MUSB_TIMEOUT
On 1/10/23 17:19, Tom Rini wrote: This variable has never been configured to another value at present, and was not converted to Kconfig. Opt instead to rename this to MUSB_TIMEOUT. Reviewed-by: Marek Vasut
Re: [PATCH] SoC: sdm845: find and save KASLR to env variables
On Tue, Dec 27, 2022 at 9:47 PM Dzmitry Sankouski wrote:
>
> KASLR address is needed to boot fully functional Android.
> KASLR is set by primary bootloader, and since u-boot is used
> as a secondary bootloader(replacing kernel) on sdm845 platform,
> KASLR may be found by comparing memory chunks at relocaddr over
> supposed KASLR range.
>
> Signed-off-by: Dzmitry Sankouski
> ---
> arch/arm/mach-snapdragon/init_sdm845.c | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/arch/arm/mach-snapdragon/init_sdm845.c
> b/arch/arm/mach-snapdragon/init_sdm845.c
> index 5f53c21947..1f88502394 100644
> --- a/arch/arm/mach-snapdragon/init_sdm845.c
> +++ b/arch/arm/mach-snapdragon/init_sdm845.c
> @@ -78,5 +78,23 @@ __weak int misc_init_r(void)
> env_set("key_power", "0");
> }
>
> + /*
> +* search for kaslr address, set by primary bootloader by searching
> first
> +* 0x100 relocated bytes at u-boot's initial load address range
> +*/
> + uintptr_t start = gd->ram_base;
> + uintptr_t end = start + 0x80;
> + u8 *addr = (u8 *)start;
> + phys_addr_t *relocaddr = (phys_addr_t *)gd->relocaddr;
> + u32 block_size = 0x1000;
> +
> + while (memcmp(addr, relocaddr, 0x100) && (uintptr_t)addr < end)
> + addr += block_size;
> +
> + if ((uintptr_t)addr >= end)
> + printf("KASLR not found in range 0x%lx - 0x%lx", start, end);
> + else
> + env_set_addr("KASLR", addr);
> +
> return 0;
> }
> --
> 2.30.2
>
Reviewed-by: Ramon Fried
Re: [PATCH 3/3] net: ftmac100: add mii read and write callbacks
On Wed, Dec 28, 2022 at 1:55 PM Sergei Antonov wrote:
>
> Register mii_bus with read and write callbacks tp allow the 'mii'
> command to work. Use a timeout of 10 ms to wait for the R/W
> operations to complete.
>
> Signed-off-by: Sergei Antonov
> ---
> drivers/net/ftmac100.c | 103 +
> drivers/net/ftmac100.h | 9
> 2 files changed, 112 insertions(+)
>
> diff --git a/drivers/net/ftmac100.c b/drivers/net/ftmac100.c
> index bb39e837bbe7..10395c94f9d1 100644
> --- a/drivers/net/ftmac100.c
> +++ b/drivers/net/ftmac100.c
> @@ -12,9 +12,13 @@
> #include
> #include
> #include
> +#include
> +#include
> +#include
> #include
> #include
> #include
> +#include
>
> #include "ftmac100.h"
> #ifdef CONFIG_DM_ETH
> @@ -23,12 +27,16 @@ DECLARE_GLOBAL_DATA_PTR;
> #endif
> #define ETH_ZLEN 60
>
> +/* Timeout for a mdio read/write operation */
> +#define FTMAC100_MDIO_TIMEOUT_USEC 1
> +
> struct ftmac100_data {
> struct ftmac100_txdes txdes[1];
> struct ftmac100_rxdes rxdes[PKTBUFSRX];
> int rx_index;
> const char *name;
> struct ftmac100 *ftmac100;
> + struct mii_dev *bus;
> };
>
> /*
> @@ -408,10 +416,104 @@ static int ftmac100_of_to_plat(struct udevice *dev)
> return 0;
> }
>
> +/*
> + * struct mii_bus functions
> + */
> +static int ftmac100_mdio_read(struct mii_dev *bus, int addr, int devad,
> + int reg)
> +{
> + struct ftmac100_data *priv = bus->priv;
> + struct ftmac100 *ftmac100 = priv->ftmac100;
> + int phycr = FTMAC100_PHYCR_PHYAD(addr) |
> + FTMAC100_PHYCR_REGAD(reg) |
> + FTMAC100_PHYCR_MIIRD;
> + int ret;
> +
> + writel(phycr, >phycr);
> +
> + ret = readl_poll_timeout(>phycr, phycr,
> +!(phycr & FTMAC100_PHYCR_MIIRD),
> +FTMAC100_MDIO_TIMEOUT_USEC);
> + if (ret)
> + pr_err("%s: mdio read failed (addr=0x%x reg=0x%x)\n",
> + bus->name, addr, reg);
> + else
> + ret = phycr & FTMAC100_PHYCR_MIIRDATA;
> +
> + return ret;
> +}
> +
> +static int ftmac100_mdio_write(struct mii_dev *bus, int addr, int devad,
> + int reg, u16 value)
> +{
> + struct ftmac100_data *priv = bus->priv;
> + struct ftmac100 *ftmac100 = priv->ftmac100;
> + int phycr = FTMAC100_PHYCR_PHYAD(addr) |
> + FTMAC100_PHYCR_REGAD(reg) |
> + FTMAC100_PHYCR_MIIWR;
> + int ret;
> +
> + writel(value, >phywdata);
> + writel(phycr, >phycr);
> +
> + ret = readl_poll_timeout(>phycr, phycr,
> +!(phycr & FTMAC100_PHYCR_MIIWR),
> +FTMAC100_MDIO_TIMEOUT_USEC);
> + if (ret)
> + pr_err("%s: mdio write failed (addr=0x%x reg=0x%x)\n",
> + bus->name, addr, reg);
> +
> + return ret;
> +}
> +
> +static int ftmac100_mdio_init(struct udevice *dev)
> +{
> + struct ftmac100_data *priv = dev_get_priv(dev);
> + struct mii_dev *bus;
> + int ret;
> +
> + bus = mdio_alloc();
> + if (!bus)
> + return -ENOMEM;
> +
> + bus->read = ftmac100_mdio_read;
> + bus->write = ftmac100_mdio_write;
> + bus->priv = priv;
> +
> + ret = mdio_register_seq(bus, dev_seq(dev));
> + if (ret) {
> + mdio_free(bus);
> + return ret;
> + }
> +
> + priv->bus = bus;
> +
> + return 0;
> +}
> +
> static int ftmac100_probe(struct udevice *dev)
> {
> struct ftmac100_data *priv = dev_get_priv(dev);
> priv->name = dev->name;
> + int ret = 0;
> +
> + ret = ftmac100_mdio_init(dev);
> + if (ret) {
> + dev_err(dev, "Failed to initialize mdiobus: %d\n", ret);
> + goto out;
> + }
> +
> +out:
> + return ret;
> +}
> +
> +static int ftmac100_remove(struct udevice *dev)
> +{
> + struct ftmac100_data *priv = dev_get_priv(dev);
> +
> + mdio_unregister(priv->bus);
> + mdio_free(priv->bus);
> +
> return 0;
> }
>
> @@ -440,6 +542,7 @@ U_BOOT_DRIVER(ftmac100) = {
> .bind = ftmac100_bind,
> .of_to_plat = ftmac100_of_to_plat,
> .probe = ftmac100_probe,
> + .remove = ftmac100_remove,
> .ops= _ops,
> .priv_auto = sizeof(struct ftmac100_data),
> .plat_auto = sizeof(struct eth_pdata),
> diff --git a/drivers/net/ftmac100.h b/drivers/net/ftmac100.h
> index 75a49f628a69..21d339f835bf 100644
> --- a/drivers/net/ftmac100.h
> +++ b/drivers/net/ftmac100.h
> @@ -92,6 +92,15 @@ struct ftmac100 {
> #define FTMAC100_MACCR_RX_MULTIPKT (1 << 16)
> #define FTMAC100_MACCR_RX_BROADPKT (1 << 17)
>
> +/*
> + * PHY control register
> + */
> +#define FTMAC100_PHYCR_MIIRDATA
Re: [PATCH v2] imx8mm-phg: Add board support
On Tue, Jan 10, 2023 at 01:45:31PM -0300, Fabio Estevam wrote: > Hi Tom, > > On Tue, Jan 10, 2023 at 1:33 PM Tom Rini wrote: > > > We're not yet to the point of nak'ing new boards over this, but if you > > look at something like board/kontron/sl-mx8mm/sl-mx8mm.env the above > > is trivially done that way instead. Is there something blocking doing > > that? > > Thanks for the suggestion. I will keep it in mind for future board > submissions. > > This particular board has been in use for several months and we don't > want to change the > environment at this time as this would require extra rework in the BSP layer. > > I plan to keep the current environment as is. You can use u-boot-initial-env to compare before/after and see it's unchanged :) -- Tom signature.asc Description: PGP signature
Re: [PATCH 2/3] net: ftmac100: simplify priv->iobase casting
On Wed, Dec 28, 2022 at 1:55 PM Sergei Antonov wrote:
>
> Replace 'phys_addr_t iobase' with 'struct ftmac100 *ftmac100'
> in order to cast once on assignment and remove casting in a
> number of other places.
>
> Signed-off-by: Sergei Antonov
> ---
> drivers/net/ftmac100.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/ftmac100.c b/drivers/net/ftmac100.c
> index b3da9479ea5e..bb39e837bbe7 100644
> --- a/drivers/net/ftmac100.c
> +++ b/drivers/net/ftmac100.c
> @@ -28,7 +28,7 @@ struct ftmac100_data {
> struct ftmac100_rxdes rxdes[PKTBUFSRX];
> int rx_index;
> const char *name;
> - phys_addr_t iobase;
> + struct ftmac100 *ftmac100;
> };
>
> /*
> @@ -36,7 +36,7 @@ struct ftmac100_data {
> */
> static void ftmac100_reset(struct ftmac100_data *priv)
> {
> - struct ftmac100 *ftmac100 = (struct ftmac100
> *)(uintptr_t)priv->iobase;
> + struct ftmac100 *ftmac100 = priv->ftmac100;
>
> debug ("%s()\n", __func__);
>
> @@ -57,7 +57,7 @@ static void ftmac100_reset(struct ftmac100_data *priv)
> static void ftmac100_set_mac(struct ftmac100_data *priv ,
> const unsigned char *mac)
> {
> - struct ftmac100 *ftmac100 = (struct ftmac100
> *)(uintptr_t)priv->iobase;
> + struct ftmac100 *ftmac100 = priv->ftmac100;
> unsigned int maddr = mac[0] << 8 | mac[1];
> unsigned int laddr = mac[2] << 24 | mac[3] << 16 | mac[4] << 8 |
> mac[5];
>
> @@ -72,7 +72,7 @@ static void ftmac100_set_mac(struct ftmac100_data *priv ,
> */
> static void _ftmac100_halt(struct ftmac100_data *priv)
> {
> - struct ftmac100 *ftmac100 = (struct ftmac100
> *)(uintptr_t)priv->iobase;
> + struct ftmac100 *ftmac100 = priv->ftmac100;
> debug ("%s()\n", __func__);
> writel (0, >maccr);
> }
> @@ -82,7 +82,7 @@ static void _ftmac100_halt(struct ftmac100_data *priv)
> */
> static int _ftmac100_init(struct ftmac100_data *priv, unsigned char
> enetaddr[6])
> {
> - struct ftmac100 *ftmac100 = (struct ftmac100
> *)(uintptr_t)priv->iobase;
> + struct ftmac100 *ftmac100 = priv->ftmac100;
> struct ftmac100_txdes *txdes = priv->txdes;
> struct ftmac100_rxdes *rxdes = priv->rxdes;
> unsigned int maccr;
> @@ -187,7 +187,7 @@ static int __ftmac100_recv(struct ftmac100_data *priv)
> */
> static int _ftmac100_send(struct ftmac100_data *priv, void *packet, int
> length)
> {
> - struct ftmac100 *ftmac100 = (struct ftmac100
> *)(uintptr_t)priv->iobase;
> + struct ftmac100 *ftmac100 = priv->ftmac100;
> struct ftmac100_txdes *curr_des = priv->txdes;
> ulong start;
>
> @@ -400,7 +400,7 @@ static int ftmac100_of_to_plat(struct udevice *dev)
> struct eth_pdata *pdata = dev_get_plat(dev);
> const char *mac;
> pdata->iobase = dev_read_addr(dev);
> - priv->iobase = pdata->iobase;
> + priv->ftmac100 = (struct ftmac100 *)pdata->iobase;
> mac = dtbmacaddr(0);
> if (mac)
> memcpy(pdata->enetaddr , mac , 6);
> --
> 2.34.1
>
Reviewed-by: Ramon Fried
Re: [PATCH 1/3] net: ftmac100: change driver name from nds32_mac to ftmac100
On Wed, Dec 28, 2022 at 1:55 PM Sergei Antonov wrote:
>
> So it will be named similarly to the related ftgmac100 driver.
> The old name 'nds32_mac' is not referred to anywhere in U-Boot.
>
> Signed-off-by: Sergei Antonov
> ---
> drivers/net/ftmac100.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ftmac100.c b/drivers/net/ftmac100.c
> index c30ace96bb13..b3da9479ea5e 100644
> --- a/drivers/net/ftmac100.c
> +++ b/drivers/net/ftmac100.c
> @@ -434,7 +434,7 @@ static const struct udevice_id ftmac100_ids[] = {
> };
>
> U_BOOT_DRIVER(ftmac100) = {
> - .name = "nds32_mac",
> + .name = "ftmac100",
> .id = UCLASS_ETH,
> .of_match = ftmac100_ids,
> .bind = ftmac100_bind,
> --
> 2.34.1
>
Reviewed-by: Ramon Fried
Re: [PATCH 13/19] net: phy: mv88e61xx: Finish migration of MV88E61XX_FIXED_PORTS
On Tue, Jan 10, 2023 at 6:23 PM Tom Rini wrote: > > Set the default for MV88E61XX_FIXED_PORTS to 0x0 in Kconfig, and move > the comment from code to the help to explain what this does. > > Signed-off-by: Tom Rini > --- > drivers/net/phy/Kconfig | 4 > drivers/net/phy/mv88e61xx.c | 8 > 2 files changed, 4 insertions(+), 8 deletions(-) > > diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig > index 580ac8e8fba2..5eaff053a09c 100644 > --- a/drivers/net/phy/Kconfig > +++ b/drivers/net/phy/Kconfig > @@ -62,6 +62,10 @@ config MV88E61XX_PHY_PORTS > > config MV88E61XX_FIXED_PORTS > hex "Bitmask of PHYless serdes Ports" > + default 0x0 > + help > + These are ports without PHYs that may be wired directly to other > + serdes interfaces > > endif # MV88E61XX_SWITCH > > diff --git a/drivers/net/phy/mv88e61xx.c b/drivers/net/phy/mv88e61xx.c > index 7eff37b24499..7ab60164c774 100644 > --- a/drivers/net/phy/mv88e61xx.c > +++ b/drivers/net/phy/mv88e61xx.c > @@ -167,14 +167,6 @@ > #error Define CONFIG_MV88E61XX_CPU_PORT to the port the CPU is attached to > #endif > > -/* > - * These are ports without PHYs that may be wired directly > - * to other serdes interfaces > - */ > -#ifndef CONFIG_MV88E61XX_FIXED_PORTS > -#define CONFIG_MV88E61XX_FIXED_PORTS 0 > -#endif > - > /* ID register values for different switch models */ > #define PORT_SWITCH_ID_60200x0200 > #define PORT_SWITCH_ID_60700x0700 > -- > 2.25.1 > Reviewed-by: Ramon Fried
Re: [PATCH] net: tftp: Fix for DATA ACK for block count out of order
On Thu, Jan 5, 2023 at 4:16 AM wrote:
>
> From: Sean Edmond
>
> In rfc7440, if an ACK is not received by the server or if the
> last data block in a window is dropped, the server will timeout and
> retransmit the window. In this case, the block count received will be
> less than the internal block count. In this case, the client
> should not ACK. ACK should only be sent if the received block
> count is greater than the expected block count.
>
> Signed-off-by: Sean Edmond
> ---
> net/tftp.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/net/tftp.c b/net/tftp.c
> index c780c33f37..51e062bddf 100644
> --- a/net/tftp.c
> +++ b/net/tftp.c
> @@ -592,6 +592,14 @@ static void tftp_handler(uchar *pkt, unsigned dest,
> struct in_addr sip,
> debug("Received unexpected block: %d, expected: %d\n",
> ntohs(*(__be16 *)pkt),
> (ushort)(tftp_cur_block + 1));
> + /*
> +* Only ACK if the block count received is greater
> than
> +* the expected block count, otherwise skip ACK.
> +* (required to properly handle the server
> retransmitting
> +* the window)
> +*/
> + if ((ushort)(tftp_cur_block + 1) -
> (short)(ntohs(*(__be16 *)pkt)) > 0)
> + break;
> /*
> * If one packet is dropped most likely
> * all other buffers in the window
> --
> 2.39.0
>
Reviewed-by: Ramon Fried
Re: [PATCH] drivers: net: fsl_ls_mdio: prevent a NULL pointer dereference
On Thu, Jan 5, 2023 at 5:09 PM Ioana Ciornei wrote: > > Prevent a NULL pointer dereference in the probe path by checking the > return valud of dev_read_addr_ptr() against NULL. > > Signed-off-by: Ioana Ciornei > --- > drivers/net/fsl_ls_mdio.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/net/fsl_ls_mdio.c b/drivers/net/fsl_ls_mdio.c > index f213e0dd8590..fce73937502d 100644 > --- a/drivers/net/fsl_ls_mdio.c > +++ b/drivers/net/fsl_ls_mdio.c > @@ -124,6 +124,9 @@ static int fsl_ls_mdio_probe(struct udevice *dev) > struct memac_mdio_controller *regs; > > priv->regs_base = dev_read_addr_ptr(dev); > + if (!priv->regs_base) > + return -ENODEV; > + > regs = (struct memac_mdio_controller *)(priv->regs_base); > > memac_setbits_32(>mdio_stat, > -- > 2.25.1 > Reviewed-by: Ramon Fried
Re: [PATCH 7/7] drivers: net: fsl-mc: do not use multiple blank lines
On Thu, Jan 5, 2023 at 5:03 PM Ioana Ciornei wrote:
>
> Remove the instances in which we have multiple blank lines.
>
> Signed-off-by: Ioana Ciornei
> ---
> drivers/net/fsl-mc/mc.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/net/fsl-mc/mc.c b/drivers/net/fsl-mc/mc.c
> index 531835fbd503..f78f070aec1c 100644
> --- a/drivers/net/fsl-mc/mc.c
> +++ b/drivers/net/fsl-mc/mc.c
> @@ -526,7 +526,6 @@ static int load_mc_dpc(u64 mc_ram_addr, size_t
> mc_ram_size, u64 mc_dpc_addr)
> return 0;
> }
>
> -
> static int mc_fixup_dpl(u64 dpl_addr)
> {
> void *blob = (void *)dpl_addr;
> @@ -698,7 +697,6 @@ static int wait_for_mc(bool booting_mc, u32
> *final_reg_gsr)
> printf("SUCCESS\n");
> }
>
> -
> *final_reg_gsr = reg_gsr;
> return 0;
> }
> --
> 2.25.1
>
Reviewed-by: Ramon Fried
Re: [PATCH 6/7] drivers: net: fsl-mc: align parameters to the open paranthesis
On Thu, Jan 5, 2023 at 5:03 PM Ioana Ciornei wrote:
>
> There were some cases in which the function parameters were not aligned
> to the open paranthesis. Fix those instances.
>
> Signed-off-by: Ioana Ciornei
> ---
> drivers/net/fsl-mc/mc.c | 12 +---
> 1 file changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/fsl-mc/mc.c b/drivers/net/fsl-mc/mc.c
> index 5ad47e3414b5..531835fbd503 100644
> --- a/drivers/net/fsl-mc/mc.c
> +++ b/drivers/net/fsl-mc/mc.c
> @@ -356,8 +356,7 @@ static int mc_fixup_dpc_mac_addr(void *blob, int dpmac_id,
> if (noff < 0) {
> err = fdt_increase_size(blob, 200);
> if (err) {
> - printf("fdt_increase_size: err=%s\n",
> - fdt_strerror(err));
> + printf("fdt_increase_size: err=%s\n",
> fdt_strerror(err));
> return err;
> }
>
> @@ -373,7 +372,7 @@ static int mc_fixup_dpc_mac_addr(void *blob, int dpmac_id,
> "link_type", link_type_mode);
> if (err) {
> printf("fdt_appendprop_string: err=%s\n",
> - fdt_strerror(err));
> + fdt_strerror(err));
> return err;
> }
> }
> @@ -1158,10 +1157,9 @@ static int dprc_init(void)
> cfg.icid = DPRC_GET_ICID_FROM_POOL;
> cfg.portal_id = DPRC_GET_PORTAL_ID_FROM_POOL;
> err = dprc_create_container(root_mc_io, MC_CMD_NO_FLAGS,
> - root_dprc_handle,
> - ,
> - _dprc_id,
> - _portal_offset);
> + root_dprc_handle, ,
> + _dprc_id,
> + _portal_offset);
> if (err < 0) {
> printf("dprc_create_container() failed: %d\n", err);
> goto err_create;
> --
> 2.25.1
>
Reviewed-by: Ramon Fried
Re: [PATCH 5/7] drivers: net: fsl-mc: remove explicit cast
On Thu, Jan 5, 2023 at 5:03 PM Ioana Ciornei wrote:
>
> Remove all the explicit casts from the void* returned by calloc.
> With this we also improve a bit the length of those lines and there is
> no need to split the assignment.
>
> Signed-off-by: Ioana Ciornei
> ---
> drivers/net/fsl-mc/mc.c | 13 +
> 1 file changed, 5 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/net/fsl-mc/mc.c b/drivers/net/fsl-mc/mc.c
> index 001c77ba8355..5ad47e3414b5 100644
> --- a/drivers/net/fsl-mc/mc.c
> +++ b/drivers/net/fsl-mc/mc.c
> @@ -812,7 +812,7 @@ int mc_init(u64 mc_fw_addr, u64 mc_dpc_addr)
> * Initialize the global default MC portal
> * And check that the MC firmware is responding portal commands:
> */
> - root_mc_io = (struct fsl_mc_io *)calloc(sizeof(struct fsl_mc_io), 1);
> + root_mc_io = calloc(sizeof(struct fsl_mc_io), 1);
> if (!root_mc_io) {
> printf(" No memory: calloc() failed\n");
> return -ENOMEM;
> @@ -979,8 +979,7 @@ static int dpio_init(void)
> int err = 0;
> uint16_t major_ver, minor_ver;
>
> - dflt_dpio = (struct fsl_dpio_obj *)calloc(
> - sizeof(struct fsl_dpio_obj), 1);
> + dflt_dpio = calloc(sizeof(struct fsl_dpio_obj), 1);
> if (!dflt_dpio) {
> printf("No memory: calloc() failed\n");
> err = -ENOMEM;
> @@ -1168,7 +1167,7 @@ static int dprc_init(void)
> goto err_create;
> }
>
> - dflt_mc_io = (struct fsl_mc_io *)calloc(sizeof(struct fsl_mc_io), 1);
> + dflt_mc_io = calloc(sizeof(struct fsl_mc_io), 1);
> if (!dflt_mc_io) {
> err = -ENOMEM;
> printf(" No memory: calloc() failed\n");
> @@ -1250,8 +1249,7 @@ static int dpbp_init(void)
> struct dpbp_cfg dpbp_cfg;
> uint16_t major_ver, minor_ver;
>
> - dflt_dpbp = (struct fsl_dpbp_obj *)calloc(
> - sizeof(struct fsl_dpbp_obj), 1);
> + dflt_dpbp = calloc(sizeof(struct fsl_dpbp_obj), 1);
> if (!dflt_dpbp) {
> printf("No memory: calloc() failed\n");
> err = -ENOMEM;
> @@ -1369,8 +1367,7 @@ static int dpni_init(void)
> struct dpni_cfg dpni_cfg;
> uint16_t major_ver, minor_ver;
>
> - dflt_dpni = (struct fsl_dpni_obj *)calloc(
> - sizeof(struct fsl_dpni_obj), 1);
> + dflt_dpni = calloc(sizeof(struct fsl_dpni_obj), 1);
> if (!dflt_dpni) {
> printf("No memory: calloc() failed\n");
> err = -ENOMEM;
> --
> 2.25.1
>
Reviewed-by: Ramon Fried
Re: [PATCH 4/7] drivers: net: fsl-mc: remove the initialisation of global variables
On Thu, Jan 5, 2023 at 5:03 PM Ioana Ciornei wrote: > > Some of the global variables were being initialised either to NULL or 0. > This is not needed, just remove the it. > > Signed-off-by: Ioana Ciornei > --- > drivers/net/fsl-mc/mc.c | 14 +++--- > 1 file changed, 7 insertions(+), 7 deletions(-) > > diff --git a/drivers/net/fsl-mc/mc.c b/drivers/net/fsl-mc/mc.c > index 440273a17562..001c77ba8355 100644 > --- a/drivers/net/fsl-mc/mc.c > +++ b/drivers/net/fsl-mc/mc.c > @@ -57,14 +57,14 @@ static int mc_dpl_applied = -1; > #ifdef CFG_SYS_LS_MC_DRAM_AIOP_IMG_OFFSET > static int mc_aiop_applied = -1; > #endif > -struct fsl_mc_io *root_mc_io = NULL; > -struct fsl_mc_io *dflt_mc_io = NULL; /* child container */ > -uint16_t root_dprc_handle = 0; > -uint16_t dflt_dprc_handle = 0; > +struct fsl_mc_io *root_mc_io; > +struct fsl_mc_io *dflt_mc_io; > +uint16_t root_dprc_handle; > +uint16_t dflt_dprc_handle; > int child_dprc_id; > -struct fsl_dpbp_obj *dflt_dpbp = NULL; > -struct fsl_dpio_obj *dflt_dpio = NULL; > -struct fsl_dpni_obj *dflt_dpni = NULL; > +struct fsl_dpbp_obj *dflt_dpbp; > +struct fsl_dpio_obj *dflt_dpio; > +struct fsl_dpni_obj *dflt_dpni; > static u64 mc_lazy_dpl_addr; > static u32 dpsparser_obj_id; > static u16 dpsparser_handle; > -- > 2.25.1 > I don't believe it's a bad habit to initialize static variables. it's true that they will be initialized to zero by default. But I don't find this patch helpful in any way for understanding or decluttering code.
Re: [PATCH 3/7] drivers: net: fsl-mc: do not prefix decimal values with 0x
On Thu, Jan 5, 2023 at 5:03 PM Ioana Ciornei wrote:
>
> The fsl-mc driver printed debug information which used the 0x prefix for
> decimal values. This only confuses anyone looking through the log.
> Because of this, just remove the prefix and use the "DPXY." notation
> which is the standard one for the DPAA2 objects.
>
> Signed-off-by: Ioana Ciornei
> ---
> drivers/net/fsl-mc/mc.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/fsl-mc/mc.c b/drivers/net/fsl-mc/mc.c
> index 180e57e42266..440273a17562 100644
> --- a/drivers/net/fsl-mc/mc.c
> +++ b/drivers/net/fsl-mc/mc.c
> @@ -1038,7 +1038,7 @@ static int dpio_init(void)
> }
>
> #ifdef DEBUG
> - printf("Init: DPIO id=0x%d\n", dflt_dpio->dpio_id);
> + printf("Init: DPIO.%d\n", dflt_dpio->dpio_id);
> #endif
> err = dpio_enable(dflt_mc_io, MC_CMD_NO_FLAGS,
> dflt_dpio->dpio_handle);
> if (err < 0) {
> @@ -1107,7 +1107,7 @@ static int dpio_exit(void)
> }
>
> #ifdef DEBUG
> - printf("Exit: DPIO id=0x%d\n", dflt_dpio->dpio_id);
> + printf("Exit: DPIO.%d\n", dflt_dpio->dpio_id);
> #endif
>
> if (dflt_dpio)
> @@ -1312,7 +1312,7 @@ static int dpbp_init(void)
> }
>
> #ifdef DEBUG
> - printf("Init: DPBP id=0x%x\n", dflt_dpbp->dpbp_attr.id);
> + printf("Init: DPBP.%d\n", dflt_dpbp->dpbp_attr.id);
> #endif
>
> err = dpbp_close(dflt_mc_io, MC_CMD_NO_FLAGS, dflt_dpbp->dpbp_handle);
> @@ -1351,7 +1351,7 @@ static int dpbp_exit(void)
> }
>
> #ifdef DEBUG
> - printf("Exit: DPBP id=0x%d\n", dflt_dpbp->dpbp_attr.id);
> + printf("Exit: DPBP.%d\n", dflt_dpbp->dpbp_attr.id);
> #endif
>
> if (dflt_dpbp)
> @@ -1422,7 +1422,7 @@ static int dpni_init(void)
> }
>
> #ifdef DEBUG
> - printf("Init: DPNI id=0x%d\n", dflt_dpni->dpni_id);
> + printf("Init: DPNI.%d\n", dflt_dpni->dpni_id);
> #endif
> err = dpni_close(dflt_mc_io, MC_CMD_NO_FLAGS, dflt_dpni->dpni_handle);
> if (err < 0) {
> @@ -1459,7 +1459,7 @@ static int dpni_exit(void)
> }
>
> #ifdef DEBUG
> - printf("Exit: DPNI id=0x%d\n", dflt_dpni->dpni_id);
> + printf("Exit: DPNI.%d\n", dflt_dpni->dpni_id);
> #endif
>
> if (dflt_dpni)
> --
> 2.25.1
>
Reviewed-by: Ramon Fried
Re: [PATCH 2/7] drivers: net: fsl-mc: remove an useless break statement
On Thu, Jan 5, 2023 at 5:03 PM Ioana Ciornei wrote:
>
> The break statement is just after a goto statement, thus it will not get
> executed. Just remove it.
>
> Signed-off-by: Ioana Ciornei
> ---
> drivers/net/fsl-mc/mc.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/net/fsl-mc/mc.c b/drivers/net/fsl-mc/mc.c
> index 66fcb48ebd55..180e57e42266 100644
> --- a/drivers/net/fsl-mc/mc.c
> +++ b/drivers/net/fsl-mc/mc.c
> @@ -1961,7 +1961,6 @@ static int do_fsl_mc(struct cmd_tbl *cmdtp, int flag,
> int argc,
> default:
> printf("Invalid option: %s\n", argv[1]);
> goto usage;
> - break;
> }
> return err;
> usage:
> --
> 2.25.1
>
It's possible that it's there only to silent dumb compiler who thinks
that break was forgotten.
Let's see if it introduces problems in the CI. meanwhile I'll approve.
Reviewed-by: Ramon Fried
Re: [PATCH 1/7] drivers: net: fsl-mc: remove useless assignment of variable
On Thu, Jan 5, 2023 at 5:03 PM Ioana Ciornei wrote:
>
> The cur_ptr variable is set to the start of the log buffer but then it's
> not used. Just remove the assignment altogether.
>
> Signed-off-by: Ioana Ciornei
> ---
> drivers/net/fsl-mc/mc.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/net/fsl-mc/mc.c b/drivers/net/fsl-mc/mc.c
> index 6b36860187ca..66fcb48ebd55 100644
> --- a/drivers/net/fsl-mc/mc.c
> +++ b/drivers/net/fsl-mc/mc.c
> @@ -1796,7 +1796,6 @@ static void mc_dump_log(void)
> if (size > bytes_end) {
> print_k_bytes(cur_ptr, _end);
>
> - cur_ptr = buf;
> size -= bytes_end;
> }
>
> --
> 2.25.1
>
Reviewed-by: Ramon Fried
Re: [PATCH v2 30/71] net: Add a function to run dhcp
On Sun, Jan 8, 2023 at 4:58 AM Simon Glass wrote:
>
> At present this must be done by executing the command. Also it involves
> fiddling with the environment to determine the correct autoload behaviour.
>
> Ideally it should be possible to run network operations without even
> having the command line present (CONFIG_CMDLINE).
>
> For now, add a function to handle DHCP, so it can be called from a bootdev
> more easily.
>
> Signed-off-by: Simon Glass
> ---
>
> (no changes since v1)
>
> cmd/net.c | 35 +++
> include/net.h | 15 +++
> 2 files changed, 50 insertions(+)
>
> diff --git a/cmd/net.c b/cmd/net.c
> index 0e9f200ca97..6b3774bfe7c 100644
> --- a/cmd/net.c
> +++ b/cmd/net.c
> @@ -4,6 +4,8 @@
> * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
> */
>
> +#define LOG_CATEGORY UCLASS_ETH
> +
> /*
> * Boot support
> */
> @@ -13,6 +15,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -120,6 +123,38 @@ U_BOOT_CMD(
> "boot image via network using DHCP/TFTP protocol",
> "[loadAddress] [[hostIPaddr:]bootfilename]"
> );
> +
> +int dhcp_run(ulong addr, const char *fname, bool autoload)
> +{
> + char *dhcp_argv[] = {"dhcp", NULL, (char *)fname, NULL};
> + struct cmd_tbl cmdtp = {}; /* dummy */
> + char file_addr[17];
> + int old_autoload;
> + int ret, result;
> +
> + log_debug("addr=%lx, fname=%s, autoload=%d\n", addr, fname, autoload);
> + old_autoload = env_get_yesno("autoload");
> + ret = env_set("autoload", autoload ? "y" : "n");
> + if (ret)
> + return log_msg_ret("en1", -EINVAL);
> +
> + if (autoload) {
> + sprintf(file_addr, "%lx", addr);
> + dhcp_argv[1] = file_addr;
> + }
> +
> + result = do_dhcp(, 0, !autoload ? 1 : fname ? 3 : 2, dhcp_argv);
> +
> + ret = env_set("autoload", old_autoload == -1 ? NULL :
> + old_autoload ? "y" : "n");
> + if (ret)
> + return log_msg_ret("en2", -EINVAL);
> +
> + if (result)
> + return log_msg_ret("res", -ENOENT);
> +
> + return 0;
> +}
> #endif
>
> #if defined(CONFIG_CMD_NFS)
> diff --git a/include/net.h b/include/net.h
> index 749f20fa967..c296d06c266 100644
> --- a/include/net.h
> +++ b/include/net.h
> @@ -65,6 +65,21 @@ struct in_addr {
> */
> int do_tftpb(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]);
>
> +/**
> + * dhcp_run() - Run DHCP on the current ethernet device
> + *
> + * This sets the autoload variable, then puts it back to similar to its
> original
> + * state (y, n or unset).
> + *
> + * @addr: Address to load the file into (0 if @autoload is false)
> + * @fname: Filename of file to load (NULL if @autoload is false or to use the
> + * default filename)
> + * @autoload: true to load the file, false to just get the network IP
> + * @return 0 if OK, -EINVAL if the environment failed, -ENOENT if ant file
> was
> + * not found
> + */
> +int dhcp_run(ulong addr, const char *fname, bool autoload);
> +
> /**
> * An incoming packet handler.
> * @param pktpointer to the application packet
> --
> 2.39.0.314.g84b9a713c41-goog
>
Reviewed-by: Ramon Fried
Re: [PATCH] net: ipv6: Fix IPv6 netmask parsing
On Mon, Jan 9, 2023 at 9:59 AM Vyacheslav V. Mitrofanov
wrote:
>
> On Fri, 2023-01-06 at 14:22 -0800, seanedm...@linux.microsoft.com
> wrote:
> > From: Sean Edmond
> >
> > It should be possible to specify a netmask when
> > setting a static IPv6 address. For example:
> > setenv ip6addr 2001:cafe:cafe:cafe::100/64
> >
> > The net_prefix_length and net_ip6 should be updated
> > properly.
> >
> > Signed-off-by: Sean Edmond
> > ---
> > net/net6.c | 9 ++---
> > 1 file changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/net/net6.c b/net/net6.c
> > index fdea078788..75577bcea1 100644
> > --- a/net/net6.c
> > +++ b/net/net6.c
> > @@ -47,10 +47,13 @@ static int on_ip6addr(const char *name, const
> > char *value, enum env_op op,
> > }
> >
> > mask = strchr(value, '/');
> > - len = strlen(value);
> >
> > - if (mask)
> > - net_prefix_length = simple_strtoul(value + len, NULL,
> > 10);
> > + if (mask) {
> > + net_prefix_length = simple_strtoul(mask + 1, NULL,
> > 10);
> > + len = mask - value;
> > + } else {
> > + len = strlen(value);
> > + }
> >
> > return string_to_ip6(value, len, _ip6);
> > }
> > --
> > 2.39.0
> I do agree with your changes.Thanks
>
> Reviewed-by: Viacheslav Mitrofanov
Reviewed-by: Ramon Fried
Re: [PATCH] firmware: ti_sci: fix typo in boot authentication message name
On 1/10/23 6:30 AM, Jorge Ramirez-Ortiz wrote:
Fix AUTH_BOOT message identifier (s/IMIAGE/IMAGE)
Signed-off-by: Jorge Ramirez-Ortiz
---
Looks like this typo got copy/pasted over to ATF also[0]..
I'll add your reported-by and go fix it over there
(unless you are wanting to do that).
Acked-by: Andrew Davis
[0]
https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/plat/ti/k3/common/drivers/ti_sci/ti_sci_protocol.h#n50
drivers/firmware/ti_sci.c | 2 +-
drivers/firmware/ti_sci.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
index 727e090e8a..bd7379ae55 100644
--- a/drivers/firmware/ti_sci.c
+++ b/drivers/firmware/ti_sci.c
@@ -1935,7 +1935,7 @@ static int ti_sci_cmd_proc_auth_boot_image(const struct
ti_sci_handle *handle,
info = handle_to_ti_sci_info(handle);
- xfer = ti_sci_setup_one_xfer(info, TISCI_MSG_PROC_AUTH_BOOT_IMIAGE,
+ xfer = ti_sci_setup_one_xfer(info, TISCI_MSG_PROC_AUTH_BOOT_IMAGE,
TI_SCI_FLAG_REQ_ACK_ON_PROCESSED,
(u32 *), sizeof(req), sizeof(*resp));
if (IS_ERR(xfer)) {
diff --git a/drivers/firmware/ti_sci.h b/drivers/firmware/ti_sci.h
index e4a087c2ba..101210eb21 100644
--- a/drivers/firmware/ti_sci.h
+++ b/drivers/firmware/ti_sci.h
@@ -49,7 +49,7 @@
#define TISCI_MSG_PROC_HANDOVER 0xc005
#define TISCI_MSG_SET_PROC_BOOT_CONFIG0xc100
#define TISCI_MSG_SET_PROC_BOOT_CTRL 0xc101
-#define TISCI_MSG_PROC_AUTH_BOOT_IMIAGE0xc120
+#define TISCI_MSG_PROC_AUTH_BOOT_IMAGE 0xc120
#define TISCI_MSG_GET_PROC_BOOT_STATUS0xc400
#define TISCI_MSG_WAIT_PROC_BOOT_STATUS 0xc401
Re: [PATCH 17/19] watchdog: Clean up defaults for imx_watchdog / ulp_wdog
On 1/10/23 17:19, Tom Rini wrote:
In imx_watchdog, clean up the comment to just note the range now, as we
do not need to set the default here as Kconfig does this for us. For
ulp_wdog, set the default value via Kconfig instead.
Cc: Stefan Roese
Cc: Stefano Babic
Cc: Peng Fan
Signed-off-by: Tom Rini
Reviewed-by: Stefan Roese
Thanks,
Stefan
---
drivers/watchdog/Kconfig| 1 +
drivers/watchdog/imx_watchdog.c | 7 +--
drivers/watchdog/ulp_wdog.c | 4
3 files changed, 2 insertions(+), 10 deletions(-)
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index f1b1cf63ca3a..b5ac8f7f50dc 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -30,6 +30,7 @@ config WATCHDOG_TIMEOUT_MSECS
default 128000 if ARCH_MX7 || ARCH_VF610
default 3 if ARCH_SOCFPGA
default 16000 if ARCH_SUNXI
+ default 5376 if ULP_WATCHDOG
default 6
help
Watchdog timeout in msec
diff --git a/drivers/watchdog/imx_watchdog.c b/drivers/watchdog/imx_watchdog.c
index 3586246fbfbc..894158b304a7 100644
--- a/drivers/watchdog/imx_watchdog.c
+++ b/drivers/watchdog/imx_watchdog.c
@@ -68,13 +68,8 @@ static void imx_watchdog_init(struct watchdog_regs *wdog,
bool ext_reset,
/*
* The timer watchdog can be set between
-* 0.5 and 128 Seconds. If not defined
-* in configuration file, sets 128 Seconds
+* 0.5 and 128 Seconds.
*/
-#ifndef CONFIG_WATCHDOG_TIMEOUT_MSECS
-#define CONFIG_WATCHDOG_TIMEOUT_MSECS 128000
-#endif
-
timeout = max_t(u64, timeout, TIMEOUT_MIN);
timeout = min_t(u64, timeout, TIMEOUT_MAX);
timeout = lldiv(timeout, 500) - 1;
diff --git a/drivers/watchdog/ulp_wdog.c b/drivers/watchdog/ulp_wdog.c
index e08105430485..c21aa3af55fa 100644
--- a/drivers/watchdog/ulp_wdog.c
+++ b/drivers/watchdog/ulp_wdog.c
@@ -25,10 +25,6 @@ struct ulp_wdt_priv {
u32 clk_rate;
};
-#ifndef CONFIG_WATCHDOG_TIMEOUT_MSECS
-#define CONFIG_WATCHDOG_TIMEOUT_MSECS 0x1500
-#endif
-
#define REFRESH_WORD0 0xA602 /* 1st refresh word */
#define REFRESH_WORD1 0xB480 /* 2nd refresh word */
Viele Grüße,
Stefan Roese
--
DENX Software Engineering GmbH, Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH v2] imx8mm-phg: Add board support
Hi Tom, On Tue, Jan 10, 2023 at 1:33 PM Tom Rini wrote: > We're not yet to the point of nak'ing new boards over this, but if you > look at something like board/kontron/sl-mx8mm/sl-mx8mm.env the above > is trivially done that way instead. Is there something blocking doing > that? Thanks for the suggestion. I will keep it in mind for future board submissions. This particular board has been in use for several months and we don't want to change the environment at this time as this would require extra rework in the BSP layer. I plan to keep the current environment as is. Thanks
