Re: iMX8MM USB support?
Hi Tim, On 01.04.20 19:55, Tim Harvey wrote: > Peng, > > It looks like IMX8MM USB support hasn't made it upstream yet. Is this > something your working on? > > I'm interested in booting an IMX8MM via SDP. If I remember correctly, the main issue is that the ci_udc driver is missing DM support. See here: [1]. I have pulled some patches/hacks into our tree to make SDP work, at least without DM [2]. If someone could come up with a proper solution for upstream that would be great and I would be happy to review/test. [1] http://u-boot.10912.n7.nabble.com/DM-for-ci-udc-td368249.html#a370228 [2] https://git.kontron-electronics.de/linux/u-boot/-/commits/v2020.01-ktn Thanks, Frieder
Re: iMX8MM USB support?
Hi Tim, On 07.04.20 19:06, Tim Harvey wrote: > On Mon, Apr 6, 2020 at 2:43 AM Schrempf Frieder > wrote: >> >> Hi Tim, >> >> On 01.04.20 19:55, Tim Harvey wrote: >>> Peng, >>> >>> It looks like IMX8MM USB support hasn't made it upstream yet. Is this >>> something your working on? >>> >>> I'm interested in booting an IMX8MM via SDP. >> >> If I remember correctly, the main issue is that the ci_udc driver is >> missing DM support. See here: [1]. >> >> I have pulled some patches/hacks into our tree to make SDP work, at >> least without DM [2]. >> >> If someone could come up with a proper solution for upstream that would >> be great and I would be happy to review/test. >> >> [1] >> https://eur04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fu-boot.10912.n7.nabble.com%2FDM-for-ci-udc-td368249.html%23a370228&data=02%7C01%7Cfrieder.schrempf%40kontron.de%7Cb62b33f13a5546ece4d508d7db16044c%7C8c9d3c973fd941c8a2b1646f3942daf1%7C0%7C0%7C637218759927463384&sdata=cSQl5z%2FRjvX4IKPWs71wOUhcc3ivvrq%2BObr7EeFbwCU%3D&reserved=0 >> [2] >> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kontron-electronics.de%2Flinux%2Fu-boot%2F-%2Fcommits%2Fv2020.01-ktn&data=02%7C01%7Cfrieder.schrempf%40kontron.de%7Cb62b33f13a5546ece4d508d7db16044c%7C8c9d3c973fd941c8a2b1646f3942daf1%7C0%7C0%7C637218759927463384&sdata=pgoX%2Bh0E%2FiY49ebT16RD3y8hKuzO0NtmdKvrXHjBnuA%3D&reserved=0 >> > > Frieder, > > Thanks - this was very helpful! After applying the patches adding > IMX8MM USB I can boot the EVK SPL via SDP and get it to transition > over to providing a gadget at 0525:c4a4 but when I try to load > u-boot.img to that it fails with a header not found error: > > sudo ../imx_usb_loader/imx_usb u-boot.imx; sleep 2; sudo > ../imx_usb_loader/imx_usb u-boot.img > config file <../imx_usb_loader//imx_usb.conf> > ... > vid=0x1fc9 pid=0x0134 file_name=mx8mm_usb_work.conf > ... > config file <../imx_usb_loader//mx8mm_usb_work.conf> > parse ../imx_usb_loader//mx8mm_usb_work.conf > Trying to open device vid=0x1fc9 pid=0x0134 > Interface 0 claimed > HAB security state: development mode (0x56787856) > == work item > filename u-boot.imx > load_size 0 bytes > load_addr 0x > dcd 1 > clear_dcd 0 > plug 1 > jump_mode 3 > jump_addr 0x > == end work item > No DCD table > > loading binary file(u-boot.imx) to 007e0fc0, skip=0, fsize=37600 type=aa > > <<<226816, 226816 bytes>>> > succeeded (security 0x56787856, status 0x) > jumping to 0x007e0fc0 > config file <../imx_usb_loader//imx_usb.conf> > ... > config file <../imx_usb_loader//mx8mm_usb_sdp_spl.conf> > parse ../imx_usb_loader//mx8mm_usb_sdp_spl.conf > Trying to open device vid=0x0525 pid=0xc4a4 > Interface 0 claimed > HAB security state: development mode (0x56787856) > == work item > filename u-boot.img > load_size 0 bytes > load_addr 0x > dcd 1 > clear_dcd 0 > plug 1 > jump_mode 3 > jump_addr 0x > == end work item > header not found 8400:91000694, 4000 > do_download failed, err=-22 > HAB security state: development mode (0x56787856) > > Note I had to add a line to imx_usb.conf to map 0525:c4a4 to > mx8mm_usb_sdp_spl.conf: > diff --git a/imx_usb.conf b/imx_usb.conf > index c7c00f6..4d89230 100644 > --- a/imx_usb.conf > +++ b/imx_usb.conf > @@ -17,6 +17,7 @@ > 0x066f:0x37ff, linux_gadget.conf > 0x1b67:0x4fff, mx6_usb_sdp_spl.conf > 0x0525:0xb4a4, mx6_usb_sdp_spl.conf > +0x0525:0xc4a4, mx8mm_usb_sdp_spl.conf > 0x1fc9:0x012b, mx8mq_usb_work.conf > 0x1fc9:0x0134, mx8mm_usb_work.conf > 0x1fc9:0x013e, mx8mn_usb_work.conf > > Do you know what's missing from u-boot.img? In my case I'm loading a FIT image, so things are a bit different. Where are you loading the image to? I have the following line in mx8mm_usb_sdp_spl.conf to load my FIT image to DDR and jump to it: /path/to/image/u-boot.itb:load 0x4020, jump_direct 0x4020 Best Regards, Frieder
Re: [U-Boot] [PATCH v2 38/41] pmic: allow dump command for non contiguous register maps
On 23.10.19 20:21, Robert Beckett wrote:
> From: Martin Fuzzey
>
> Some PMICs (such as the DA9063) have non-contiguous register maps.
> Attempting to read the non implemented registers returns an error
> rather than a dummy value which causes 'pmic dump' to terminate
> prematurely.
>
> Fix this by allowing the PMIC driver to return -ENODATA for such
> registers, which will then be displayed as '--' by pmic dump.
>
> Use a single error code rather than any error code so that
> we can distinguish between a hardware failure reading the PMIC
> and a non implemented register known to the driver.
>
> Signed-off-by: Martin Fuzzey
> Signed-off-by: Robert Beckett
Reviewed-by: Frieder Schrempf
Tested-by: Frieder Schrempf
> ---
> cmd/pmic.c | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/cmd/pmic.c b/cmd/pmic.c
> index e46d813a70..2400bfb601 100644
> --- a/cmd/pmic.c
> +++ b/cmd/pmic.c
> @@ -95,7 +95,7 @@ static int do_dump(cmd_tbl_t *cmdtp, int flag, int argc,
> char * const argv[])
>
> for (reg = 0; reg < pmic_reg_count(dev); reg++) {
> ret = pmic_reg_read(dev, reg);
> - if (ret < 0) {
> + if (ret < 0 && ret != -ENODATA) {
> printf("Can't read register: %d\n", reg);
> return failure(ret);
> }
> @@ -103,7 +103,15 @@ static int do_dump(cmd_tbl_t *cmdtp, int flag, int argc,
> char * const argv[])
> if (!(reg % 16))
> printf("\n0x%02x: ", reg);
>
> - printf(fmt, ret);
> + if (ret == -ENODATA) {
> + int i;
> +
> + for (i = 0; i < priv->trans_len; i++)
> + puts("--");
> + puts(" ");
> + } else {
> + printf(fmt, ret);
> + }
> }
> printf("\n");
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 39/41] power: pmic: add driver for Dialog DA9063 PMIC
Hi Robert,
On 23.10.19 20:22, Robert Beckett wrote:
> From: Martin Fuzzey
>
> This adds the basic register access operations and child regulator
> binding (if a regulator driver exists).
>
> Robert Beckett: simplify accesses by using bottom bit of address as
> offset overflow. This avoids the need to track which page we are on.
>
> Signed-off-by: Martin Fuzzey
> Signed-off-by: Robert Beckett
> ---
> drivers/power/pmic/Kconfig | 7 +
> drivers/power/pmic/Makefile | 1 +
> drivers/power/pmic/da9063.c | 130 +++
> include/power/da9063_pmic.h | 308
> 4 files changed, 446 insertions(+)
> create mode 100644 drivers/power/pmic/da9063.c
> create mode 100644 include/power/da9063_pmic.h
>
> diff --git a/drivers/power/pmic/Kconfig b/drivers/power/pmic/Kconfig
> index 586772fdec..ea3977b4cb 100644
> --- a/drivers/power/pmic/Kconfig
> +++ b/drivers/power/pmic/Kconfig
> @@ -40,6 +40,13 @@ config PMIC_ACT8846
> functions. It uses an I2C interface and is designed for use with
> tablets and smartphones.
>
> +config DM_PMIC_DA9063
> + bool "Enable Driver Model for the Dialog DA9063 PMIC"
> + depends on DM_PMIC
> + help
> + This config enables implementation of driver-model pmic uclass
> features
> + for PMIC DA9063. The driver implements read/write operations.
> +
> config PMIC_AS3722
> bool "Enable support for the Austria Micro Systems (AMS) AS7322 PMIC"
> help
> diff --git a/drivers/power/pmic/Makefile b/drivers/power/pmic/Makefile
> index 888dbb2857..6d9de2efb1 100644
> --- a/drivers/power/pmic/Makefile
> +++ b/drivers/power/pmic/Makefile
> @@ -5,6 +5,7 @@
>
> obj-$(CONFIG_DM_PMIC) += pmic-uclass.o
> obj-$(CONFIG_DM_PMIC_FAN53555) += fan53555.o
> +obj-$(CONFIG_DM_PMIC_DA9063) += da9063.o
Can you please change this to "obj-$(CONFIG_$(SPL_)DM_PMIC_DA9063)" and
add an option CONFIG_SPL_DM_PMIC_DA9063 to Kconfig?
This will allow us to enable the driver for SPL and U-Boot proper
separately.
Thanks,
Frieder
> obj-$(CONFIG_DM_PMIC_MAX77686) += max77686.o
> obj-$(CONFIG_DM_PMIC_MAX8998) += max8998.o
> obj-$(CONFIG_DM_PMIC_MC34708) += mc34708.o
> diff --git a/drivers/power/pmic/da9063.c b/drivers/power/pmic/da9063.c
> new file mode 100644
> index 00..abda7a5a40
> --- /dev/null
> +++ b/drivers/power/pmic/da9063.c
> @@ -0,0 +1,130 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2018 Flowbird
> + * Martin Fuzzey
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +static const struct pmic_child_info pmic_children_info[] = {
> + { .prefix = "ldo", .driver = DA9063_LDO_DRIVER },
> + { .prefix = "b", .driver = DA9063_BUCK_DRIVER },
> + { },
> +};
> +
> +/*
> + * The register map is non contiguous and attempts to read in the holes fail.
> + * But "pmic dump" tries to dump the full register map.
> + * So define the holes here so we can fix that.
> + */
> +struct da9063_reg_hole {
> + u16 first;
> + u16 last;
> +};
> +
> +static const struct da9063_reg_hole da9063_reg_holes[] = {
> + DA9063_REG_HOLE_1,
> + DA9063_REG_HOLE_2,
> + DA9063_REG_HOLE_3,
> + /* These aren't readable. I can't see why from the datasheet but
> + * attempts to read fail and the kernel marks them unreadable too,
> + */
> + {DA9063_REG_OTP_COUNT, DA9063_REG_OTP_DATA},
> +};
> +
> +static int da9063_reg_count(struct udevice *dev)
> +{
> + return DA9063_NUM_OF_REGS;
> +}
> +
> +static bool da9063_reg_valid(uint reg)
> +{
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(da9063_reg_holes); i++) {
> + const struct da9063_reg_hole *hole = &da9063_reg_holes[i];
> +
> + if (reg >= hole->first && reg <= hole->last)
> + return false;
> + }
> +
> + return true;
> +}
> +
> +static int da9063_write(struct udevice *dev, uint reg, const uint8_t *buff,
> + int len)
> +{
> + if (dm_i2c_write(dev, reg, buff, len)) {
> + pr_err("write error to device: %p register: %#x!", dev, reg);
> + return -EIO;
> + }
> +
> + return 0;
> +}
> +
> +static int da9063_read(struct udevice *dev, uint reg, uint8_t *buff, int len)
> +{
> + if (!da9063_reg_valid(reg))
> + return -ENODATA;
> +
> + if (dm_i2c_read(dev, reg, buff, len)) {
> + pr_err("read error from device: %p register: %#x!", dev, reg);
> + return -EIO;
> + }
> +
> + return 0;
> +}
> +
> +static int da9063_bind(struct udevice *dev)
> +{
> + ofnode regulators_node;
> + int children;
> +
> + regulators_node = dev_read_subnode(dev, "regulators");
> + if (!ofnode_valid(regulators_node)) {
> + debug("%s: %s regulators subnode not found!", __func__,
> + dev->name);
> + return -ENXIO;
> + }
> +
> + debug("%s: '%s' - foun
Re: [U-Boot] [PATCH v2 40/41] power: regulator: add driver for Dialog DA9063 PMIC
Hi Robert,
On 23.10.19 20:22, Robert Beckett wrote:
> From: Martin Fuzzey
>
> Add a driver for the regulators in the the DA9063 PMIC.
>
> Robert Beckett: move regulator modes to header so board code can set
> modes. Correct mode mask used in ldo_set_mode.
>
> Signed-off-by: Martin Fuzzey
> Signed-off-by: Robert Beckett
> ---
> drivers/power/regulator/Kconfig | 10 +
> drivers/power/regulator/Makefile | 1 +
> drivers/power/regulator/da9063.c | 388 +++
> include/power/da9063_pmic.h | 12 +
> 4 files changed, 411 insertions(+)
> create mode 100644 drivers/power/regulator/da9063.c
>
> diff --git a/drivers/power/regulator/Kconfig b/drivers/power/regulator/Kconfig
> index 9aa00fad42..ab58e2eb56 100644
> --- a/drivers/power/regulator/Kconfig
> +++ b/drivers/power/regulator/Kconfig
> @@ -60,6 +60,16 @@ config SPL_DM_REGULATOR_BD71837
> This config enables implementation of driver-model regulator uclass
> features for regulators on ROHM BD71837 and BD71847 in SPL.
>
> +config DM_REGULATOR_DA9063
> + bool "Enable Driver Model for REGULATOR DA9063"
> + depends on DM_REGULATOR && DM_PMIC_DA9063
> + help
> + This config enables implementation of driver-model regulator uclass
> + features for REGULATOR DA9063.
> + The driver implements get/set api for value, enable and mode for all
> + regulators. It also implements the get/set api for current for the
> + buck regulators.
> +
> config DM_REGULATOR_PFUZE100
> bool "Enable Driver Model for REGULATOR PFUZE100"
> depends on DM_REGULATOR && DM_PMIC_PFUZE100
> diff --git a/drivers/power/regulator/Makefile
> b/drivers/power/regulator/Makefile
> index 6a3d4bbee4..b05a71562c 100644
> --- a/drivers/power/regulator/Makefile
> +++ b/drivers/power/regulator/Makefile
> @@ -7,6 +7,7 @@
> obj-$(CONFIG_$(SPL_)DM_REGULATOR) += regulator-uclass.o
> obj-$(CONFIG_REGULATOR_ACT8846) += act8846.o
> obj-$(CONFIG_REGULATOR_AS3722) += as3722_regulator.o
> +obj-$(CONFIG_DM_REGULATOR_DA9063) += da9063.o
Can you please change this to "obj-$(CONFIG_$(SPL_)DM_REGULATOR_DA9063)"
and add an option CONFIG_SPL_DM_REGULATOR_DA9063 to Kconfig?
This will allow us to enable the driver for SPL and U-Boot proper
separately.
Thanks,
Frieder
> obj-$(CONFIG_DM_REGULATOR_MAX77686) += max77686.o
> obj-$(CONFIG_$(SPL_)DM_PMIC_PFUZE100) += pfuze100.o
> obj-$(CONFIG_$(SPL_)DM_REGULATOR_BD71837) += bd71837.o
> diff --git a/drivers/power/regulator/da9063.c
> b/drivers/power/regulator/da9063.c
> new file mode 100644
> index 00..8990be113e
> --- /dev/null
> +++ b/drivers/power/regulator/da9063.c
> @@ -0,0 +1,388 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2018 Flowbird
> + * Martin Fuzzey
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define DA9063_BUCK_EN 0x01
> +#define DA9063_LDO_EN 0x01
> +#define DA9063_VBUCK_MASK0x7F
> +#define DA9063_BUCK_SL 0x80
> +#define DA9063_LDO_SL0x80
> +
> +#define DA9063_VLDO1_MASK0x3F
> +#define DA9063_VLDO2_MASK0x3F
> +#define DA9063_VLDO3_MASK0x7F
> +#define DA9063_VLDO4_MASK0x7F
> +#define DA9063_VLDO5_MASK0x3F
> +#define DA9063_VLDO6_MASK0x3F
> +#define DA9063_VLDO7_MASK0x3F
> +#define DA9063_VLDO8_MASK0x3F
> +#define DA9063_VLDO9_MASK0x3F
> +#define DA9063_VLDO10_MASK 0x3F
> +#define DA9063_VLDO11_MASK 0x3F
> +
> +#define DA9063_BUCK_MODE_MASK0xC0
> +#define DA9063_BUCK_MODE_MANUAL 0x00
> +#define DA9063_BUCK_MODE_SLEEP 0x40
> +#define DA9063_BUCK_MODE_SYNC 0x80
> +#define DA9063_BUCK_MODE_AUTO 0xC0
> +
> +#define DA9063_BIO_ILIM_MASK 0x0F
> +#define DA9063_BMEM_ILIM_MASK0xF0
> +#define DA9063_BPRO_ILIM_MASK0x0F
> +#define DA9063_BPERI_ILIM_MASK 0xF0
> +#define DA9063_BCORE1_ILIM_MASK 0x0F
> +#define DA9063_BCORE2_ILIM_MASK 0xF0
> +
> +struct da9063_reg_info {
> + uint min_uV;
> + uint step_uV;
> + uint max_uV;
> + uint min_uA;
> + uint step_uA;
> + uint max_uA;
> + uint en_reg;
> + uint vsel_reg;
> + uint mode_reg;
> + uint ilim_reg;
> + u8 en_mask;
> + u8 vsel_mask;
> + u8 ilim_mask;
> + const char *dt_node_name;
> + const int *current_limits;
> +};
> +
> +struct da9063_priv {
> + const struct da9063_reg_info *reg_info;
> +};
> +
> +static struct dm_regulator_mode da9063_ldo_modes[] = {
> + { .id = DA9063_LDOMODE_SLEEP,
> + .register_value = DA9063_LDO_SL, .name = "SLEEP" },
> + { .id = DA9063_LDOMODE_NORMAL,
> + .register_value = 0, .name = "NORMAL" },
> +};
> +
> +#define DA9063_LDO(regl_name, min_mV, step_mV, max_mV) \
> + .min_uV = (min_mV) * 1000, \
> + .step_uV = (step_mV) * 1000, \
> + .max_uV = (max_mV) * 1000, \
> + .en_reg = DA9063_REG_##regl_name##_CONT, \
> + .en_mask =
Re: [U-Boot] Pull request: u-boot-spi/master
Hi Jagan, On 28.10.19 01:46, Tom Rini wrote: > On Sun, Oct 27, 2019 at 05:20:22PM +0530, Jagan Teki wrote: >> Hi Tom, >> >> On Fri, Oct 25, 2019 at 11:19 PM Tom Rini wrote: >>> >>> On Fri, Oct 25, 2019 at 02:08:12PM +0530, Jagan Teki wrote: >>> Hi Tom, Please pull this PR. Summary: - SPL_SPI_FLASH_MTD (Frieder) - SPI NOR IDs' fixes, additions (Vignesh) - cs_info change (Bin) - Enable sunxi spi (Jagan) Travis-CI: https://travis-ci.org/openedev/u-boot-amarula/builds/602483415 Thanks, Jagan. The following changes since commit 17fd9915a4c639381804ed28274fa136ae3b0bee: Merge branch '2019-10-24-UFS-support' (2019-10-24 09:51:48 -0400) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-spi master for you to fetch changes up to 395ec7418695e5ce23f8b48c01a1dbffd2e52d3f: spi-nor-ids: Add support for Adesto AT25SL321 (2019-10-25 00:48:32 +0530) >>> >>> So, looking over the build output, I see the expected size increase in >>> sunxi due to new support. But I also see a lot of size increases in >>> rockchip and layerscape platforms (and possibly more, I stopped after >>> spotting two different SoCs), for example: >>> evb-px5: all +12139 data +176 rodata +2275 >>> spl/u-boot-spl:all +3529 spl/u-boot-spl:data +120 spl/u-boot-spl:rodata >>> +309 spl/u-boot-spl:text +3100 text +9688 >>> u-boot: add: 49/0, grow: 0/0 bytes: 9512/0 (9512) >>> function old new >>> delta >>> spi_nor_scan -2032 >>> +2032 >>> do_spi_flash -2008 >>> +2008 >>> spi_get_bus_and_cs - 436 >>> +436 >>> spi_mem_exec_op - 420 >>> +420 >>> static.spi_nor_wait_till_ready_with_timeout - >>> 300+300 >>> spi_nor_write- 300 >>> +300 >>> mtd_arg_off_size - 276 >>> +276 >>> spi_nor_erase- 232 >>> +232 >>> device_unbind- 232 >>> +232 >>> spi_nor_read_data- 220 >>> +220 >>> spi_nor_write_data - 212 >>> +212 >>> dm_spi_claim_bus - 196 >>> +196 >>> spi_mem_adjust_op_size - 160 >>> +160 >>> spi_mem_default_supports_op - 156 >>> +156 >>> spi_nor_read - 152 >>> +152 >>> spi_flash_probe_bus_cs - 152 >>> +152 >>> spi_set_speed_mode - 148 >>> +148 >>> spi_flash_std_erase - 136 >>> +136 >>> spi_flash_std_probe - 132 >>> +132 >>> mtd_arg_off - 124 >>> +124 >>> device_chld_unbind - 120 >>> +120 >>> _u_boot_list_2_driver_2_spi_flash_std- 120 >>> +120 >>> spi_nor_write_reg- 104 >>> +104 >>> spi_find_bus_and_cs - 104 >>> +104 >>> spi_nor_read_reg - 100 >>> +100 >>> spi_find_chip_select - 96 >>> +96 >>> static.spi_check_buswidth_req- 88 >>> +88 >>> str2off - 80 >>> +80 >>> bytes_per_second - 76 >>> +76 >>> spi_flash_std_write - 72 >>> +72 >>> spi_flash_std_read - 72 >>> +72 >>> spi_mem_supports_op - 56 >>> +56 >>> _u_boot_list_2_cmd_2_sf - 56 >>> +56 >>> dm_spi_xfer - 48 >>> +48 >>> read_sr - 44 >>> +44 >>> device_find_next_child - 40 >>> +40 >>> spi_flash_cmd_get_sw_write_prot - 36 >>>
Re: [U-Boot] Pull request: u-boot-spi/master
On 31.10.19 08:57, Jagan Teki wrote: > Hi Schrempf, > > On Thu, Oct 31, 2019 at 1:24 PM Schrempf Frieder > wrote: >> >> Hi Jagan, >> >> On 28.10.19 01:46, Tom Rini wrote: >>> On Sun, Oct 27, 2019 at 05:20:22PM +0530, Jagan Teki wrote: >>>> Hi Tom, >>>> >>>> On Fri, Oct 25, 2019 at 11:19 PM Tom Rini wrote: >>>>> >>>>> On Fri, Oct 25, 2019 at 02:08:12PM +0530, Jagan Teki wrote: >>>>> >>>>>> Hi Tom, >>>>>> >>>>>> Please pull this PR. >>>>>> >>>>>> Summary: >>>>>> - SPL_SPI_FLASH_MTD (Frieder) >>>>>> - SPI NOR IDs' fixes, additions (Vignesh) >>>>>> - cs_info change (Bin) >>>>>> - Enable sunxi spi (Jagan) >>>>>> >>>>>> Travis-CI: >>>>>> https://travis-ci.org/openedev/u-boot-amarula/builds/602483415 >>>>>> >>>>>> Thanks, >>>>>> Jagan. >>>>>> >>>>>> The following changes since commit >>>>>> 17fd9915a4c639381804ed28274fa136ae3b0bee: >>>>>> >>>>>> Merge branch '2019-10-24-UFS-support' (2019-10-24 09:51:48 -0400) >>>>>> >>>>>> are available in the Git repository at: >>>>>> >>>>>> https://gitlab.denx.de/u-boot/custodians/u-boot-spi master >>>>>> >>>>>> for you to fetch changes up to 395ec7418695e5ce23f8b48c01a1dbffd2e52d3f: >>>>>> >>>>>> spi-nor-ids: Add support for Adesto AT25SL321 (2019-10-25 00:48:32 >>>>>> +0530) >>>>>> >>>>> >>>>> So, looking over the build output, I see the expected size increase in >>>>> sunxi due to new support. But I also see a lot of size increases in >>>>> rockchip and layerscape platforms (and possibly more, I stopped after >>>>> spotting two different SoCs), for example: >>>>> evb-px5: all +12139 data +176 rodata +2275 >>>>> spl/u-boot-spl:all +3529 spl/u-boot-spl:data +120 spl/u-boot-spl:rodata >>>>> +309 spl/u-boot-spl:text +3100 text +9688 >>>>> u-boot: add: 49/0, grow: 0/0 bytes: 9512/0 (9512) >>>>>function old new >>>>> delta >>>>>spi_nor_scan -2032 >>>>> +2032 >>>>>do_spi_flash -2008 >>>>> +2008 >>>>>spi_get_bus_and_cs - 436 >>>>>+436 >>>>>spi_mem_exec_op - 420 >>>>>+420 >>>>>static.spi_nor_wait_till_ready_with_timeout - >>>>> 300+300 >>>>>spi_nor_write- 300 >>>>>+300 >>>>>mtd_arg_off_size - 276 >>>>>+276 >>>>>spi_nor_erase- 232 >>>>>+232 >>>>>device_unbind- 232 >>>>>+232 >>>>>spi_nor_read_data- 220 >>>>>+220 >>>>>spi_nor_write_data - 212 >>>>>+212 >>>>>dm_spi_claim_bus - 196 >>>>>+196 >>>>>spi_mem_adjust_op_size - 160 >>>>>+160 >>>>>spi_mem_default_supports_op - 156 >>>>>+156 >>>>>spi_nor_read - 152 >>>>>+152 >>>>>spi_flash_probe_bus_cs - 152 >>>>>+152 >>>>>spi_set_speed_mode - 148 >>>>>+148 >>>>>spi_flash_std_erase - 136 >>>>>
[U-Boot] Buildman Kconfig issue with consecutive builds
Hi, I'm having some trouble using buildman to test the impact of some Kconfig cleanup patches ([1]). The patches introduce a new CONFIG_SPL_* option and I try to find out which defconfigs need to be fixed, by comparing build sizes. Now when I added a patch to fix a defconfig I noticed that buildman wouldn't report the expected size changes and upon looking more closely I found that the added Kconfig options are still missing in u-boot-spl.cfg. The strange thing is, that when I try to build only the last commit then the Kconfig options are there, which is why I suspect a bug in buildman not handling Kconfig changes correctly with consecutive builds. Can anyone have a look what is wrong or how I can debug this issue? The issue can be reproduced with the branch at [1], running: buildman -b spi_flash_kconfig_cleanup_3 --step 0 xilinx_zynqmp_virt for a build where the added Kconfig options are missing in the resulting u-boot-spl.cfg. And: buildman -b spi_flash_kconfig_cleanup_3^..spi_flash_kconfig_cleanup_3 xilinx_zynqmp_virt for a build of only the last commit with expected output. Thanks, Frieder [1]: https://github.com/fschrempf/u-boot/commits/spi_flash_kconfig_cleanup_3 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Buildman Kconfig issue with consecutive builds
On 06.11.19 17:16, Frieder Schrempf wrote: > Hi, > > I'm having some trouble using buildman to test the impact of some > Kconfig cleanup patches ([1]). > > The patches introduce a new CONFIG_SPL_* option and I try to find out > which defconfigs need to be fixed, by comparing build sizes. > > Now when I added a patch to fix a defconfig I noticed that buildman > wouldn't report the expected size changes and upon looking more closely > I found that the added Kconfig options are still missing in u-boot-spl.cfg. > > The strange thing is, that when I try to build only the last commit then > the Kconfig options are there, which is why I suspect a bug in buildman > not handling Kconfig changes correctly with consecutive builds. > > Can anyone have a look what is wrong or how I can debug this issue? > > The issue can be reproduced with the branch at [1], running: > > buildman -b spi_flash_kconfig_cleanup_3 --step 0 xilinx_zynqmp_virt Forgot to mention that my master is set to 32d870a82203a16a6e05958e2a02287af4dd825a (which is not upstream) in this case. > > for a build where the added Kconfig options are missing in the resulting > u-boot-spl.cfg. > > And: > > buildman -b spi_flash_kconfig_cleanup_3^..spi_flash_kconfig_cleanup_3 > xilinx_zynqmp_virt > > for a build of only the last commit with expected output. > > Thanks, > Frieder > > [1]: > https://github.com/fschrempf/u-boot/commits/spi_flash_kconfig_cleanup_3 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Buildman Kconfig issue with consecutive builds
Hi Bin, On 07.11.19 13:41, Bin Meng wrote: > Hi Schrempf, > > On Thu, Nov 7, 2019 at 12:17 AM Schrempf Frieder > wrote: >> >> Hi, >> >> I'm having some trouble using buildman to test the impact of some >> Kconfig cleanup patches ([1]). >> >> The patches introduce a new CONFIG_SPL_* option and I try to find out >> which defconfigs need to be fixed, by comparing build sizes. >> >> Now when I added a patch to fix a defconfig I noticed that buildman >> wouldn't report the expected size changes and upon looking more closely >> I found that the added Kconfig options are still missing in u-boot-spl.cfg. >> >> The strange thing is, that when I try to build only the last commit then >> the Kconfig options are there, which is why I suspect a bug in buildman >> not handling Kconfig changes correctly with consecutive builds. >> >> Can anyone have a look what is wrong or how I can debug this issue? >> >> The issue can be reproduced with the branch at [1], running: >> >> buildman -b spi_flash_kconfig_cleanup_3 --step 0 xilinx_zynqmp_virt >> > > Could you please add "-C" to the buildman command line and have a try? Indeed forcing the reconfig between the build steps with '-C' fixes the issue. Is it a known problem, that buildman doesn't handle Kconfig changes correctly without '-C' in some cases? Thanks, Frieder > >> for a build where the added Kconfig options are missing in the resulting >> u-boot-spl.cfg. >> >> And: >> >> buildman -b spi_flash_kconfig_cleanup_3^..spi_flash_kconfig_cleanup_3 >> xilinx_zynqmp_virt >> >> for a build of only the last commit with expected output. >> >> Thanks, >> Frieder >> >> [1]: https://github.com/fschrempf/u-boot/commits/spi_flash_kconfig_cleanup_3 > > Regards, > Bin > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Buildman Kconfig issue with consecutive builds
On 07.11.19 15:02, Bin Meng wrote: > Hi Frieder, > > On Thu, Nov 7, 2019 at 9:28 PM Schrempf Frieder > wrote: >> >> Hi Bin, >> >> On 07.11.19 13:41, Bin Meng wrote: >>> Hi Schrempf, >>> >>> On Thu, Nov 7, 2019 at 12:17 AM Schrempf Frieder >>> wrote: >>>> >>>> Hi, >>>> >>>> I'm having some trouble using buildman to test the impact of some >>>> Kconfig cleanup patches ([1]). >>>> >>>> The patches introduce a new CONFIG_SPL_* option and I try to find out >>>> which defconfigs need to be fixed, by comparing build sizes. >>>> >>>> Now when I added a patch to fix a defconfig I noticed that buildman >>>> wouldn't report the expected size changes and upon looking more closely >>>> I found that the added Kconfig options are still missing in u-boot-spl.cfg. >>>> >>>> The strange thing is, that when I try to build only the last commit then >>>> the Kconfig options are there, which is why I suspect a bug in buildman >>>> not handling Kconfig changes correctly with consecutive builds. >>>> >>>> Can anyone have a look what is wrong or how I can debug this issue? >>>> >>>> The issue can be reproduced with the branch at [1], running: >>>> >>>> buildman -b spi_flash_kconfig_cleanup_3 --step 0 xilinx_zynqmp_virt >>>> >>> >>> Could you please add "-C" to the buildman command line and have a try? >> >> Indeed forcing the reconfig between the build steps with '-C' fixes the >> issue. >> >> Is it a known problem, that buildman doesn't handle Kconfig changes >> correctly without '-C' in some cases? > > AFAIK, this is an intended design of calling buildman w/o '-C' to save > some build time. Ok, if that's the case I will try to come up with a patch that adds a note to the README. This has cost me a few hours because I was thinking buildman does the right thing and Kconfig options are messed up somewhere. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Buildman Kconfig issue with consecutive builds
Hi Simon,
On 07.11.19 17:23, Simon Glass wrote:
> Hi Schrempf,
>
> On Thu, 7 Nov 2019 at 08:15, Schrempf Frieder
> wrote:
>>
>> On 07.11.19 15:02, Bin Meng wrote:
>>> Hi Frieder,
>>>
>>> On Thu, Nov 7, 2019 at 9:28 PM Schrempf Frieder
>>> wrote:
>>>>
>>>> Hi Bin,
>>>>
>>>> On 07.11.19 13:41, Bin Meng wrote:
>>>>> Hi Schrempf,
>>>>>
>>>>> On Thu, Nov 7, 2019 at 12:17 AM Schrempf Frieder
>>>>> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I'm having some trouble using buildman to test the impact of some
>>>>>> Kconfig cleanup patches ([1]).
>>>>>>
>>>>>> The patches introduce a new CONFIG_SPL_* option and I try to find out
>>>>>> which defconfigs need to be fixed, by comparing build sizes.
>>>>>>
>>>>>> Now when I added a patch to fix a defconfig I noticed that buildman
>>>>>> wouldn't report the expected size changes and upon looking more closely
>>>>>> I found that the added Kconfig options are still missing in
>>>>>> u-boot-spl.cfg.
>>>>>>
>>>>>> The strange thing is, that when I try to build only the last commit then
>>>>>> the Kconfig options are there, which is why I suspect a bug in buildman
>>>>>> not handling Kconfig changes correctly with consecutive builds.
>>>>>>
>>>>>> Can anyone have a look what is wrong or how I can debug this issue?
>>>>>>
>>>>>> The issue can be reproduced with the branch at [1], running:
>>>>>>
>>>>>> buildman -b spi_flash_kconfig_cleanup_3 --step 0 xilinx_zynqmp_virt
>>>>>>
>>>>>
>>>>> Could you please add "-C" to the buildman command line and have a try?
>>>>
>>>> Indeed forcing the reconfig between the build steps with '-C' fixes the
>>>> issue.
>>>>
>>>> Is it a known problem, that buildman doesn't handle Kconfig changes
>>>> correctly without '-C' in some cases?
>>>
>>> AFAIK, this is an intended design of calling buildman w/o '-C' to save
>>> some build time.
>>
>> Ok, if that's the case I will try to come up with a patch that adds a
>> note to the README. This has cost me a few hours because I was thinking
>> buildman does the right thing and Kconfig options are messed up somewhere.
>
> An incremental build means that it does not run 'make xxx_defconfig'
> on every commit. Doing it this way saves *a lot* of time for large
> builds and the main purpose of buildman is to validate that U-Boot
> builds.
>
> However it might be possible to have it both ways...the code fragment
> below compares the Kconfig files and configs/ directory against the
> data of the 'u-boot' output file, and could trigger a full rebuild if
> newer.
Ok, thanks for the explanation.
>
> If you have time (sounds like you do!), you could incorporate that
> into buildman.
It's kind of funny that you got the impression, that I have time ;)
Actually I do not have much time to work on U-Boot in general among all
the other things.
And now I went deep down into the rabbit hole from "I want to get some
boards upstreamed" to "I need to port a QSPI controller driver first" to
"the driver port affects existing CONFIG options that are a total mess
and need to be fixed" to "I need to run buildman on my cleanup patches"
to "buildman could need some tweaking".
So unless there will be a lot of rainy weekends, I probably won't start
working on optimizing buildman ;)
Regards,
Frieder
>
> files = ['%s/u-boot' % outdir]
>if os.path.exists(files[0]):
> if options.incremental:
>cmd = ['find', 'configs/', '-cnewer', files[0]]
>result = cros_build_lib.RunCommand(cmd, capture_output=True, **kwargs)
>if result.output:
> logging.warning('config/ dir has changed - dropping -i')
> options.incremental = False
>
> if options.incremental:
>cmd = ['find', '.', '-name', 'Kconfig', '-and', '-cnewer', files[0]]
>result = cros_build_lib.RunCommand(cmd, capture_output=True, **kwargs)
>if result.output:
> logging.warning('Kconfig file(s) changed - dropping -i')
> options.incremental = False
>
>
> The current logic is in RunJob() and do_config is the thing that
> causes a reconfig.
>
> Regards,
> Simon
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: iMX8MM USB support?
On 08.04.20 17:31, Tim Harvey wrote:
[...]
>>
>> In my case I'm loading a FIT image, so things are a bit different.
>> Where are you loading the image to?
>>
>> I have the following line in mx8mm_usb_sdp_spl.conf to load my FIT image
>> to DDR and jump to it:
>>
>> /path/to/image/u-boot.itb:load 0x4020, jump_direct 0x4020
>>
>
> Frieder,
>
> I was trying to load u-boot.img
>
> The SPL boots fine:
> U-Boot SPL 2020.01-00029-g5ad7797 (Apr 08 2020 - 08:16:53 -0700)
> read error from device: 9310b8 register: x!Normal Boot
> Trying to boot from USB SDP
> SDP: initialize...
> SDP: handle requests..
>
> But when I 'imx_usb u-boot.img' it complains there is no header on
> u-boot.img. I enabled FIT generation and attempted to 'imx_usb
> u-boot.itb' but imx_usb still complains about no header found.
>
> My mx8mm_usb_sdp_spl.conf loooks like this:
> mx8mm_spl_sdp
> #hid/bulk,[old_header,]max packet size, {ram start, ram size}(repeat
> valid ram areas)
> #In SPL, we typically load u-boot.img which has a U-boot header...
> hid,1024,0x91,0x4000,1G,0x0090,0x4
>
> #0x6 - 0x8400 = 0x57c00, +0x3000=5ac00 (FIT image)
> ../u-boot-imx6/u-boot.bin:load 0x4020
> ../u-boot-imx6/bl31-iMX8MM.bin:load 0x0092,jump 0x92
>
> What does your mx8mm_usb_sdp_spl.conf look like? I must admit I don't
> really understand how these are configured.
It looks just like yours except that I have a single instruction as
already stated above:
/path/to/image/u-boot.itb:load 0x4020, jump_direct 0x4020
and I'm loading the FIT image by running './imx_usb' without arguments.
As imx_usb_loader can't parse FIT image headers, I use 'jump_direct' to
jump to the raw image entry point and let SPL parse the FIT. I think in
that case imx_usb_loader shouldn't complain about a missing header.
Re: [PATCH] spl: Kconfig: de-dup SPL_DM_GPIO definition
On 17.04.20 17:42, Joel Johnson wrote: > Two nearly concurrent commits (d4d65e112 and bcee8d676) added a > SPL_DM_GPIO symbol. Resolve the duplication in favor of the version > in drivers/gpio/Kconfig. > > Signed-off-by: Joel Johnson Reviewed-by: Frieder Schrempf > > --- > > common/spl/Kconfig | 6 -- > 1 file changed, 6 deletions(-) > > diff --git a/common/spl/Kconfig b/common/spl/Kconfig > index 9d52b75cb4..ef5bf66696 100644 > --- a/common/spl/Kconfig > +++ b/common/spl/Kconfig > @@ -508,12 +508,6 @@ config SPL_DMA > the CPU moving the data. Enable this option to build the drivers > in drivers/dma as part of an SPL build. > > -config SPL_DM_GPIO > - bool "Support Driver Model GPIO drivers" > - depends on SPL_GPIO_SUPPORT && DM_GPIO > - help > - Enable support for Driver Model based GPIO drivers in SPL. > - > config SPL_DRIVERS_MISC_SUPPORT > bool "Support misc drivers" > help >
Re: [PATCH] imx: Fix imx8m FIT script issue
On 09.04.20 10:44, Ye Li wrote:
> The FIT config node has reversed ATF and u-boot: ATF is set to
> firmware but u-boot is set to loadable.
> This script can work previously because spl fit driver wrongly
> appends fdt to all loadable images. With the issue fixed, the u-boot
> in loadable does not have fdt appended and fails to work.
> So correct script by moving u-boot to firmware and ATF to loadable.
I know this has been applied and the change itself is probably correct.
But when I apply this to my 2020.01-based tree, TFA/U-Boot isn't loaded
anymore.
Please note, that I have disabled CONFIG_SPL_FIT_IMAGE_TINY, so
9d15d1d1c24f ("Revert "common: spl_fit: Default to IH_OS_U_BOOT if
FIT_IMAGE_TINY enabled"") won't help.
I haven't tested with master so far, so I'm not sure if I miss some
other patch or if there is an actual issue.
I just wondered why I switched the order in the first place in
fa99af41e0da ("imx: mkimage_fit_atf: Fix FIT image for correct boot order").
It would also have been nice if I would have been cc-ed for this patch
as I was the one introducing the "wrong" order in fa99af41e0da.
>
> Signed-off-by: Ye Li
> ---
> arch/arm/mach-imx/mkimage_fit_atf.sh | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-imx/mkimage_fit_atf.sh
> b/arch/arm/mach-imx/mkimage_fit_atf.sh
> index ad81d5e..dd1ca5a 100755
> --- a/arch/arm/mach-imx/mkimage_fit_atf.sh
> +++ b/arch/arm/mach-imx/mkimage_fit_atf.sh
> @@ -116,8 +116,8 @@ if [ -f $BL32 ]; then
> cat << __CONF_SECTION_EOF
> config@$cnt {
> description = "$(basename $dtname .dtb)";
> - firmware = "atf@1";
> - loadables = "uboot@1", "tee@1";
> + firmware = "uboot@1";
> + loadables = "atf@1", "tee@1";
> fdt = "fdt@$cnt";
> };
> __CONF_SECTION_EOF
> @@ -125,8 +125,8 @@ else
> cat << __CONF_SECTION1_EOF
> config@$cnt {
> description = "$(basename $dtname .dtb)";
> - firmware = "atf@1";
> - loadables = "uboot@1";
> + firmware = "uboot@1";
> + loadables = "atf@1";
> fdt = "fdt@$cnt";
> };
> __CONF_SECTION1_EOF
>
Re: [U-Boot] [PATCH 36/37] dm: pmic: add da9063 PMIC driver and regulators
Hi Robert,
On 15.10.19 17:53, Robert Beckett wrote:
> Add DM driver to support Dialog DA9063.
> Currently it support binding regulator children.
>
> Signed-off-by: Robert Beckett
I also have a board with DA9063 and was looking for support in U-Boot. I
found patches from Martin Fuzzey [1] and pulled them in almost as is and
found them to work just fine.
Unfortunately I didn't have time to resend them yet, but you can find
the rebased patches here: [2].
On a first glance your implementation looks different, so it seems you
didn't use Martin's patches. Though the resulting features probably will
be similar.
I only had a very quick look and one difference seems to be that your
regulator implementation supports the AUTO and SYNC mode, while Martin's
version supports AUTO, SYNC and SLEEP. There might be other differences.
What do you think? Which version would be better?
Also find a few comments below, though I didn't do a full review, yet.
Thanks,
Frieder
[1] https://patchwork.ozlabs.org/cover/979346/
[2] https://github.com/fschrempf/u-boot/commits/da9063
> ---
> drivers/power/pmic/Kconfig | 8 +
> drivers/power/pmic/Makefile | 1 +
> drivers/power/pmic/da9063.c | 270 ++
> drivers/power/regulator/Kconfig | 7 +
> drivers/power/regulator/Makefile | 1 +
> drivers/power/regulator/da9063.c | 320 +++
> include/power/da9063_pmic.h | 303 +
> 7 files changed, 910 insertions(+)
> create mode 100644 drivers/power/pmic/da9063.c
> create mode 100644 drivers/power/regulator/da9063.c
> create mode 100644 include/power/da9063_pmic.h
>
> diff --git a/drivers/power/pmic/Kconfig b/drivers/power/pmic/Kconfig
> index 586772fdec..6dd7b1bf76 100644
> --- a/drivers/power/pmic/Kconfig
> +++ b/drivers/power/pmic/Kconfig
> @@ -267,3 +267,11 @@ config SPL_PMIC_LP87565
> help
> The LP87565 is a PMIC containing a bunch of SMPS.
> This driver binds the pmic children in SPL.
> +
> +config DM_PMIC_DA9063
> + bool "Enable support for Dialog DA9063 PMIC"
> + depends on DM_PMIC && (DM_I2C || DM_SPI)
> + help
> + The DA9063 is a PMIC providing 6 BUCK converters and 11 LDO regulators.
> + It can be accessed via I2C or SPI.
> + This driver binds the pmic children.
> diff --git a/drivers/power/pmic/Makefile b/drivers/power/pmic/Makefile
> index 888dbb2857..9be9d5d9a0 100644
> --- a/drivers/power/pmic/Makefile
> +++ b/drivers/power/pmic/Makefile
> @@ -25,6 +25,7 @@ obj-$(CONFIG_$(SPL_)PMIC_PALMAS) += palmas.o
> obj-$(CONFIG_$(SPL_)PMIC_LP873X) += lp873x.o
> obj-$(CONFIG_$(SPL_)PMIC_LP87565) += lp87565.o
> obj-$(CONFIG_PMIC_STPMIC1) += stpmic1.o
> +obj-$(CONFIG_DM_PMIC_DA9063) += da9063.o
It would be good to be able to enable the driver for U-Boot proper and
SPL separately. So this should be CONFIG_$(SPL_)DM_PMIC_DA9063.
>
> obj-$(CONFIG_POWER_LTC3676) += pmic_ltc3676.o
> obj-$(CONFIG_POWER_MAX77696) += pmic_max77696.o
> diff --git a/drivers/power/pmic/da9063.c b/drivers/power/pmic/da9063.c
> new file mode 100644
> index 00..81a7803b09
> --- /dev/null
> +++ b/drivers/power/pmic/da9063.c
> @@ -0,0 +1,270 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * (C) Copyright 2019 Collabora
> + * (C) Copyright 2019 GE
> + */
> +
> +#define DEBUG 1
This should not be here.
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +static const struct pmic_child_info pmic_children_info[] = {
> + { .prefix = "bcore", .driver = DA9063_BUCK_DRIVER },
> + { .prefix = "bpro", .driver = DA9063_BUCK_DRIVER },
> + { .prefix = "bmem", .driver = DA9063_BUCK_DRIVER },
> + { .prefix = "bio", .driver = DA9063_BUCK_DRIVER },
> + { .prefix = "bperi", .driver = DA9063_BUCK_DRIVER },
> + { .prefix = "ldo", .driver = DA9063_LDO_DRIVER },
> + { },
> +};
> +
> +static int da9063_reg_count(struct udevice *dev)
> +{
> + return DA9063_NUM_OF_REGS;
> +}
> +
> +#if defined(CONFIG_DM_I2C)
> +static int da9063_i2c_read(struct udevice *dev, uint reg, uint8_t *buff,
> +int len)
> +{
> + int ret;
> +
> + /* only support single reg accesses */
> + if (len != 1)
> + return -EINVAL;
> +
> + ret = dm_i2c_read(dev, reg, buff, len);
> + if (ret) {
> + pr_err("%s: unable to read reg %#x: %d\n", __func__, reg, ret);
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static int da9063_i2c_write(struct udevice *dev, uint reg, const uint8_t
> *buff,
> + int len)
> +{
> + int ret;
> +
> + /* only support single reg accesses */
> + if (len != 1)
> + return -EINVAL;
> +
> + ret = dm_i2c_write(dev, reg, buff, len);
> + if (ret) {
> + pr_err("%s: unable to write reg %#x: %d\n", __func__, reg, ret);
> + return ret;
>
Re: [U-Boot] [PATCH 2/3] stm32mp1: configs: Add CONFIG_SPL_SPI_FLASH_MTD
Hi Jagan, On 16.10.19 18:34, Jagan Teki wrote: > On Sat, Sep 14, 2019 at 4:18 AM Schrempf Frieder > wrote: >> >> From: Frieder Schrempf >> >> As SPI_FLASH_MTD is used in SPL and U-Boot proper, we enable both, >> now that a separate option for SPL was introduced. >> >> Signed-off-by: Frieder Schrempf >> --- >> configs/stm32mp15_basic_defconfig | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/configs/stm32mp15_basic_defconfig >> b/configs/stm32mp15_basic_defconfig >> index 09785b5dc1..390319657f 100644 >> --- a/configs/stm32mp15_basic_defconfig >> +++ b/configs/stm32mp15_basic_defconfig >> @@ -7,10 +7,10 @@ CONFIG_TARGET_STM32MP1=y >> CONFIG_SPL_SPI_FLASH_SUPPORT=y >> CONFIG_SPL_SPI_SUPPORT=y >> # CONFIG_ARMV7_VIRT is not set >> +CONFIG_SPL_TEXT_BASE=0x2FFC2500 >> CONFIG_DISTRO_DEFAULTS=y >> CONFIG_FIT=y >> CONFIG_BOOTCOMMAND="run bootcmd_stm32mp" >> -CONFIG_SPL_TEXT_BASE=0x2FFC2500 > > Unrelated change wrt to commit message? Yes, this is unrelated, but that's what 'menuconfig' and 'savedefconfig' gave me as output. So I would think it's ok. If you don't think so, feel free to remove this change or let me know if I should remove it. Thanks, Frieder ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] stm32mp1: configs: Add CONFIG_SPL_SPI_FLASH_MTD
Hi Jagan, On 17.10.19 08:42, Frieder Schrempf wrote: > Hi Jagan, > > On 16.10.19 18:34, Jagan Teki wrote: >> On Sat, Sep 14, 2019 at 4:18 AM Schrempf Frieder >> wrote: >>> >>> From: Frieder Schrempf >>> >>> As SPI_FLASH_MTD is used in SPL and U-Boot proper, we enable both, >>> now that a separate option for SPL was introduced. >>> >>> Signed-off-by: Frieder Schrempf >>> --- >>> configs/stm32mp15_basic_defconfig | 3 ++- >>> 1 file changed, 2 insertions(+), 1 deletion(-) >>> >>> diff --git a/configs/stm32mp15_basic_defconfig >>> b/configs/stm32mp15_basic_defconfig >>> index 09785b5dc1..390319657f 100644 >>> --- a/configs/stm32mp15_basic_defconfig >>> +++ b/configs/stm32mp15_basic_defconfig >>> @@ -7,10 +7,10 @@ CONFIG_TARGET_STM32MP1=y >>> CONFIG_SPL_SPI_FLASH_SUPPORT=y >>> CONFIG_SPL_SPI_SUPPORT=y >>> # CONFIG_ARMV7_VIRT is not set >>> +CONFIG_SPL_TEXT_BASE=0x2FFC2500 >>> CONFIG_DISTRO_DEFAULTS=y >>> CONFIG_FIT=y >>> CONFIG_BOOTCOMMAND="run bootcmd_stm32mp" >>> -CONFIG_SPL_TEXT_BASE=0x2FFC2500 >> >> Unrelated change wrt to commit message? > > Yes, this is unrelated, but that's what 'menuconfig' and 'savedefconfig' > gave me as output. So I would think it's ok. If you don't think so, feel > free to remove this change or let me know if I should remove it. In patchwork all three patches of this series are marked with "Changes Requested". Can you please let me know what needs to be fixed? Thanks, Frieder ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5 1/5] spl: dm: disable SPI DM flash for non-DM SPL
Hi Lukasz, hi Xiaowei,
On 22.10.19 14:20, Lukasz Majewski wrote:
> Hi Xiaowei,
>
>> Hi Lukasz,
>>
>> My patches depends on your patches
>> https://patchwork.ozlabs.org/project/uboot/list/?series=129069, do
>> you have plan to update it? I saw that the status is "changes
>> required", any comments?
>
> There was some discussion regarding this work with Frieder (CC'ed),
> who has prepared similar patch set.
>
> Some portions of this series:
> spi: Split CONFIG_DM_SPI* to CONFIG_{SPL_TPL}DM_SPI*
>
> has been applied.
>
> However, I don't know if Frieder is going (or already has) to prepare
> new version of this patch set.
I have sent one part of the necessary changes: [1].
The latest version of the whole conversion can be found here: [2].
I need to test these changes with buildman before I send the remaining
parts. I hope I will find some time to do this in the next days.
Regards,
Frieder
[1] https://patchwork.ozlabs.org/patch/1162265/
[2] https://github.com/fschrempf/u-boot/commits/spi_flash_kconfig_cleanup
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: [PATCH 1/6] spi: fsl_qspi: Fix DDR mode setting for latest iMX platforms
Hi Stefan, On 22.10.19 15:18, Stefan Roese wrote: > Hi Frieder, > Hi Ashish, > Hi Ye Li, > Hi Fabio, > > On 18.09.19 09:42, Stefan Roese wrote: >> Hi Frieder, >> >> On 18.09.19 09:08, Schrempf Frieder wrote: >> >> >> >>>> One further update on this QSPI driver. This driver only works when >>>> loaded via "imx_usb" on the i.MX6ULL EVK. When programmed into QSPI >>>> and booted from QSPI this driver does not detect the SPI NOR >>>> flash: >>>> >>>> => sf probe >>>> unrecognized JEDEC id bytes: ff, ff, ff >>>> >>>> Do you have any idea what might explain this difference. I would have >>>> expected that when booting via QSPI it would be "easier" for the >>>> driver, as the BootROM already initializes the QSPI interface. Which >>>> is not the case in the boot via serial download (imx_usb) mode. Here >>>> everyhting (pinmux, clocks, etc) need to be configured. >>>> >>>> My feeling is that something is configured "incorrectly" by the >>>> BootROM in this case which is not re-configured as the QSPI driver >>>> needs it to be currently. >>>> >>>> Do you have any ideas on what might be the problem here? Is there >>>> something that I can do to help test this? Would it help if I would >>>> send the debug logging of the driver? >>> >>> I have a strong suspicion of what goes wrong in your case. We >>> experienced exactly the same issue recently on i.MX6ULL. For some >>> reasons (I guess differences in BootROM) this does not happen on >>> i.MX6UL. >>> >>> The problem is, that the BootROM sets the TDH bits in the QuadSPI_FLSHCR >>> register to '01' in case it uses the DDR mode. Afterwards when U-Boot or >>> Linux try to access the flash in SDR mode, they fail as the TDH bits are >>> still set. Resetting them to '00' solves the problem. >>> >>> Unfortunately the TDH bits are not documented in the manual of the >>> i.MX6UL/ULL, but they can be found in the manual of the i.MX7. >>> >>> For the QSPI driver, this means it needs a fix to set/reset the TDH bits >>> according to the mode that is used (DDR/SDR). >>> >>> For more details please also look here: >>> https://community.nxp.com/thread/507260 >> >> Perfect. With these bits set to 00 again, booting from QSPI now >> works on the EVK. Many thanks for this hint! :) > > I'm coming back to this issue, as we now have the new NXP patches > integrated into mainline. Including this one: > > 7949576664ac "spi: fsl_qspi: Fix DDR mode setting for latest iMX platforms" > > I've now re-tested current mainline on the i.MX6ULL Eval Kit and QSPI > does not work reliably. This is with CONFIG_SYS_FSL_QSPI_AHB enabled > and disabled. How is QSPI supposed to work on i.MX6ULL/ULZ? Is any > one of you running this current mainline driver successfully on one > any i-MX6ULL/ULZ based board? If yes, what is your configuration here? I don't have any experience with the current mainline SPI NOR driver. > > BTW: Using the "spi-mem" driver version from Ashish with the fix > suggested by Frieder to clear the DDR bit in TDH (reset to 00) still > works without any problems. There is some cleanup work that needs to be done (e.g. [1]). After that I will send an official patch for the spi-mem driver. Then Ashish and you can comment with your test results and change requests. I have also sent a fix for the TDH bit for the Linux driver [2]. This is also applicable to the new U-Boot driver. Regards, Frieder [1]: https://github.com/fschrempf/u-boot/commits/spi_flash_kconfig_cleanup [2]: https://patchwork.kernel.org/patch/11176905/ ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: [PATCH 1/6] spi: fsl_qspi: Fix DDR mode setting for latest iMX platforms
On 22.10.19 15:55, Frieder Schrempf wrote: > Hi Stefan, > > On 22.10.19 15:18, Stefan Roese wrote: >> Hi Frieder, >> Hi Ashish, >> Hi Ye Li, >> Hi Fabio, >> >> On 18.09.19 09:42, Stefan Roese wrote: >>> Hi Frieder, >>> >>> On 18.09.19 09:08, Schrempf Frieder wrote: >>> >>> >>> >>>>> One further update on this QSPI driver. This driver only works when >>>>> loaded via "imx_usb" on the i.MX6ULL EVK. When programmed into QSPI >>>>> and booted from QSPI this driver does not detect the SPI NOR >>>>> flash: >>>>> >>>>> => sf probe >>>>> unrecognized JEDEC id bytes: ff, ff, ff >>>>> >>>>> Do you have any idea what might explain this difference. I would have >>>>> expected that when booting via QSPI it would be "easier" for the >>>>> driver, as the BootROM already initializes the QSPI interface. Which >>>>> is not the case in the boot via serial download (imx_usb) mode. Here >>>>> everyhting (pinmux, clocks, etc) need to be configured. >>>>> >>>>> My feeling is that something is configured "incorrectly" by the >>>>> BootROM in this case which is not re-configured as the QSPI driver >>>>> needs it to be currently. >>>>> >>>>> Do you have any ideas on what might be the problem here? Is there >>>>> something that I can do to help test this? Would it help if I would >>>>> send the debug logging of the driver? >>>> >>>> I have a strong suspicion of what goes wrong in your case. We >>>> experienced exactly the same issue recently on i.MX6ULL. For some >>>> reasons (I guess differences in BootROM) this does not happen on >>>> i.MX6UL. >>>> >>>> The problem is, that the BootROM sets the TDH bits in the >>>> QuadSPI_FLSHCR >>>> register to '01' in case it uses the DDR mode. Afterwards when >>>> U-Boot or >>>> Linux try to access the flash in SDR mode, they fail as the TDH bits >>>> are >>>> still set. Resetting them to '00' solves the problem. >>>> >>>> Unfortunately the TDH bits are not documented in the manual of the >>>> i.MX6UL/ULL, but they can be found in the manual of the i.MX7. >>>> >>>> For the QSPI driver, this means it needs a fix to set/reset the TDH >>>> bits >>>> according to the mode that is used (DDR/SDR). >>>> >>>> For more details please also look here: >>>> https://community.nxp.com/thread/507260 >>> >>> Perfect. With these bits set to 00 again, booting from QSPI now >>> works on the EVK. Many thanks for this hint! :) >> >> I'm coming back to this issue, as we now have the new NXP patches >> integrated into mainline. Including this one: >> >> 7949576664ac "spi: fsl_qspi: Fix DDR mode setting for latest iMX >> platforms" > >> I've now re-tested current mainline on the i.MX6ULL Eval Kit and QSPI >> does not work reliably. This is with CONFIG_SYS_FSL_QSPI_AHB enabled >> and disabled. How is QSPI supposed to work on i.MX6ULL/ULZ? Is any >> one of you running this current mainline driver successfully on one >> any i-MX6ULL/ULZ based board? If yes, what is your configuration here? > > I don't have any experience with the current mainline SPI NOR driver. I had a look and the current mainline driver has 7949576664ac "spi: fsl_qspi: Fix DDR mode setting for latest iMX platforms", but it still does not reset the TDH bits during init, in case the BootROM has left them set, which is the case when booting from QSPI on i.MX6ULL. Initially for detection the driver does not use DDR, so TDH must be cleared. I have an older U-Boot 2017.03 that uses a backported version of the current mainline QSPI driver without DM. And it seems to work fine on i.MX6ULL with a 64MB SPI NOR, except for the issue described above. >> >> BTW: Using the "spi-mem" driver version from Ashish with the fix >> suggested by Frieder to clear the DDR bit in TDH (reset to 00) still >> works without any problems. > > There is some cleanup work that needs to be done (e.g. [1]). After that > I will send an official patch for the spi-mem driver. Then Ashish and > you can comment with your test results and change requests. > > I have also sent a fix for the TDH bit for the Linux driver [2]. This is > also applicable to the new U-Boot driver. > > Regards, > Frieder > > [1]: https://github.com/fschrempf/u-boot/commits/spi_flash_kconfig_cleanup > [2]: https://patchwork.kernel.org/patch/11176905/ ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] stm32mp1: configs: Add CONFIG_SPL_SPI_FLASH_MTD
Hi Jagan, On 22.10.19 20:10, Jagan Teki wrote: > On Tue, Oct 22, 2019 at 6:23 PM Schrempf Frieder > wrote: >> >> Hi Jagan, >> >> On 17.10.19 08:42, Frieder Schrempf wrote: >>> Hi Jagan, >>> >>> On 16.10.19 18:34, Jagan Teki wrote: >>>> On Sat, Sep 14, 2019 at 4:18 AM Schrempf Frieder >>>> wrote: >>>>> >>>>> From: Frieder Schrempf >>>>> >>>>> As SPI_FLASH_MTD is used in SPL and U-Boot proper, we enable both, >>>>> now that a separate option for SPL was introduced. >>>>> >>>>> Signed-off-by: Frieder Schrempf >>>>> --- >>>>>configs/stm32mp15_basic_defconfig | 3 ++- >>>>>1 file changed, 2 insertions(+), 1 deletion(-) >>>>> >>>>> diff --git a/configs/stm32mp15_basic_defconfig >>>>> b/configs/stm32mp15_basic_defconfig >>>>> index 09785b5dc1..390319657f 100644 >>>>> --- a/configs/stm32mp15_basic_defconfig >>>>> +++ b/configs/stm32mp15_basic_defconfig >>>>> @@ -7,10 +7,10 @@ CONFIG_TARGET_STM32MP1=y >>>>>CONFIG_SPL_SPI_FLASH_SUPPORT=y >>>>>CONFIG_SPL_SPI_SUPPORT=y >>>>># CONFIG_ARMV7_VIRT is not set >>>>> +CONFIG_SPL_TEXT_BASE=0x2FFC2500 >>>>>CONFIG_DISTRO_DEFAULTS=y >>>>>CONFIG_FIT=y >>>>>CONFIG_BOOTCOMMAND="run bootcmd_stm32mp" >>>>> -CONFIG_SPL_TEXT_BASE=0x2FFC2500 >>>> >>>> Unrelated change wrt to commit message? >>> >>> Yes, this is unrelated, but that's what 'menuconfig' and 'savedefconfig' >>> gave me as output. So I would think it's ok. If you don't think so, feel >>> free to remove this change or let me know if I should remove it. >> >> In patchwork all three patches of this series are marked with "Changes >> Requested". Can you please let me know what needs to be fixed? > > Thought you might drop that unrelated change and send next version, > but anyway I have changed and I have asked you to "let me know if I should remove it" above and you didn't do so. Therefore I assumed you do it yourself, or you apply it as is. > > Applied to u-boot-spi/master > Anyway, thanks a lot! Regards, Frieder ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] mtd: spi: Clean up usage of CONFIG_SPI_FLASH_MTD
Hi Jagan, On 22.10.19 20:16, Jagan Teki wrote: > On Sat, Sep 14, 2019 at 4:14 AM Schrempf Frieder > wrote: >> >> From: Frieder Schrempf >> >> Most boards currently use SPI_FLASH_MTD only in U-Boot proper, not in >> SPL. They often rely on hacks in the board header files to include >> this option conditionally. To be able to fix this, we previously >> introduced a separate option SPL_SPI_FLASH_MTD. >> >> Therefore we can now adjust the Makefile and change the code in >> sf_probe.c and sf_internal.h to use CONFIG_IS_ENABLED(SPI_FLASH_MTD). >> >> We also need to move all occurences of CONFIG_SPI_FLASH_MTD from the >> header files to the according defconfigs. The affected boards are >> socfpga, aristainetos, cm_fx6, display5, ventana, rcar-gen2, dh_imx6 >> and da850evm. >> >> We do this all in one patch to guarantee bisectibility. >> >> This change was tested with buildman to make sure it does not >> introduce any regressions by comparing the resulting binary sizes. >> >> Signed-off-by: Frieder Schrempf >> --- >> configs/aristainetos2_defconfig| 1 + >> configs/aristainetos2b_defconfig | 1 + >> configs/aristainetos_defconfig | 1 + >> configs/cm_fx6_defconfig | 1 + >> configs/display5_defconfig | 1 + >> configs/display5_factory_defconfig | 1 + >> configs/socfpga_arria5_defconfig | 1 + >> configs/socfpga_cyclone5_defconfig | 1 + >> configs/socfpga_dbm_soc1_defconfig | 1 + >> configs/socfpga_de0_nano_soc_defconfig | 1 + >> configs/socfpga_de10_nano_defconfig| 1 + >> configs/socfpga_is1_defconfig | 1 + >> configs/socfpga_mcvevk_defconfig | 1 + >> configs/socfpga_sockit_defconfig | 1 + >> configs/socfpga_socrates_defconfig | 1 + >> configs/socfpga_sr1500_defconfig | 1 + >> configs/socfpga_vining_fpga_defconfig | 1 + >> drivers/mtd/spi/Makefile | 2 +- >> drivers/mtd/spi/sf_internal.h | 2 +- >> drivers/mtd/spi/sf_probe.c | 6 +++--- >> include/configs/aristainetos-common.h | 1 - >> include/configs/cm_fx6.h | 7 --- >> include/configs/da850evm.h | 7 +-- >> include/configs/dh_imx6.h | 1 - >> include/configs/display5.h | 4 >> include/configs/gw_ventana.h | 10 +- >> include/configs/rcar-gen2-common.h | 4 +--- >> include/configs/socfpga_common.h | 4 >> 28 files changed, 25 insertions(+), 40 deletions(-) >> >> diff --git a/configs/aristainetos2_defconfig >> b/configs/aristainetos2_defconfig >> index 18ef5d2dce..0bfc117762 100644 >> --- a/configs/aristainetos2_defconfig >> +++ b/configs/aristainetos2_defconfig >> @@ -44,6 +44,7 @@ CONFIG_SF_DEFAULT_CS=1 >> CONFIG_SF_DEFAULT_MODE=0 >> CONFIG_SF_DEFAULT_SPEED=2000 >> CONFIG_SPI_FLASH_STMICRO=y >> +CONFIG_SPI_FLASH_MTD=y >> CONFIG_MTD_UBI_FASTMAP=y >> CONFIG_MTD_UBI_FASTMAP_AUTOCONVERT=1 >> CONFIG_PHYLIB=y >> diff --git a/configs/aristainetos2b_defconfig >> b/configs/aristainetos2b_defconfig >> index 1054c05d8c..e2da747a8f 100644 >> --- a/configs/aristainetos2b_defconfig >> +++ b/configs/aristainetos2b_defconfig >> @@ -42,6 +42,7 @@ CONFIG_SPI_FLASH=y >> CONFIG_SF_DEFAULT_MODE=0 >> CONFIG_SF_DEFAULT_SPEED=2000 >> CONFIG_SPI_FLASH_STMICRO=y >> +CONFIG_SPI_FLASH_MTD=y >> CONFIG_MTD_UBI_FASTMAP=y >> CONFIG_MTD_UBI_FASTMAP_AUTOCONVERT=1 >> CONFIG_PHYLIB=y >> diff --git a/configs/aristainetos_defconfig b/configs/aristainetos_defconfig >> index 4080a7b310..5caf95c22f 100644 >> --- a/configs/aristainetos_defconfig >> +++ b/configs/aristainetos_defconfig >> @@ -43,6 +43,7 @@ CONFIG_SF_DEFAULT_BUS=3 >> CONFIG_SF_DEFAULT_MODE=0 >> CONFIG_SF_DEFAULT_SPEED=2000 >> CONFIG_SPI_FLASH_STMICRO=y >> +CONFIG_SPI_FLASH_MTD=y >> CONFIG_MTD_UBI_FASTMAP=y >> CONFIG_MTD_UBI_FASTMAP_AUTOCONVERT=1 >> CONFIG_PHYLIB=y >> diff --git a/configs/cm_fx6_defconfig b/configs/cm_fx6_defconfig >> index fd0db4db5c..15be7db027 100644 >> --- a/configs/cm_fx6_defconfig >> +++ b/configs/cm_fx6_defconfig >> @@ -72,6 +72,7 @@ CONFIG_SPI_FLASH_SPANSION=y >> CONFIG_SPI_FLASH_STMICRO=y >> CONFIG_SPI_FLASH_SST=y >> CONFIG_SPI_FLASH_WINBOND=y >> +CONFIG_SPI_FLASH_MTD=y >> CONFIG_PHYLIB=y >> CONFIG_MII=y >> CONFIG_DM_PM
Re: [U-Boot] [PATCH 3/3] mtd: spi: Clean up usage of CONFIG_SPI_FLASH_MTD
On 23.10.19 09:09, Jagan Teki wrote: > On Wed, Oct 23, 2019 at 12:35 PM Schrempf Frieder > wrote: >> >> Hi Jagan, >> >> On 22.10.19 20:16, Jagan Teki wrote: >>> On Sat, Sep 14, 2019 at 4:14 AM Schrempf Frieder >>> wrote: >>>> >>>> From: Frieder Schrempf >>>> >>>> Most boards currently use SPI_FLASH_MTD only in U-Boot proper, not in >>>> SPL. They often rely on hacks in the board header files to include >>>> this option conditionally. To be able to fix this, we previously >>>> introduced a separate option SPL_SPI_FLASH_MTD. >>>> >>>> Therefore we can now adjust the Makefile and change the code in >>>> sf_probe.c and sf_internal.h to use CONFIG_IS_ENABLED(SPI_FLASH_MTD). >>>> >>>> We also need to move all occurences of CONFIG_SPI_FLASH_MTD from the >>>> header files to the according defconfigs. The affected boards are >>>> socfpga, aristainetos, cm_fx6, display5, ventana, rcar-gen2, dh_imx6 >>>> and da850evm. >>>> >>>> We do this all in one patch to guarantee bisectibility. >>>> >>>> This change was tested with buildman to make sure it does not >>>> introduce any regressions by comparing the resulting binary sizes. >>>> >>>> Signed-off-by: Frieder Schrempf >>>> --- >>>>configs/aristainetos2_defconfig| 1 + >>>>configs/aristainetos2b_defconfig | 1 + >>>>configs/aristainetos_defconfig | 1 + >>>>configs/cm_fx6_defconfig | 1 + >>>>configs/display5_defconfig | 1 + >>>>configs/display5_factory_defconfig | 1 + >>>>configs/socfpga_arria5_defconfig | 1 + >>>>configs/socfpga_cyclone5_defconfig | 1 + >>>>configs/socfpga_dbm_soc1_defconfig | 1 + >>>>configs/socfpga_de0_nano_soc_defconfig | 1 + >>>>configs/socfpga_de10_nano_defconfig| 1 + >>>>configs/socfpga_is1_defconfig | 1 + >>>>configs/socfpga_mcvevk_defconfig | 1 + >>>>configs/socfpga_sockit_defconfig | 1 + >>>>configs/socfpga_socrates_defconfig | 1 + >>>>configs/socfpga_sr1500_defconfig | 1 + >>>>configs/socfpga_vining_fpga_defconfig | 1 + >>>>drivers/mtd/spi/Makefile | 2 +- >>>>drivers/mtd/spi/sf_internal.h | 2 +- >>>>drivers/mtd/spi/sf_probe.c | 6 +++--- >>>>include/configs/aristainetos-common.h | 1 - >>>>include/configs/cm_fx6.h | 7 --- >>>>include/configs/da850evm.h | 7 +-- >>>>include/configs/dh_imx6.h | 1 - >>>>include/configs/display5.h | 4 >>>>include/configs/gw_ventana.h | 10 +- >>>>include/configs/rcar-gen2-common.h | 4 +--- >>>>include/configs/socfpga_common.h | 4 >>>>28 files changed, 25 insertions(+), 40 deletions(-) >>>> >>>> diff --git a/configs/aristainetos2_defconfig >>>> b/configs/aristainetos2_defconfig >>>> index 18ef5d2dce..0bfc117762 100644 >>>> --- a/configs/aristainetos2_defconfig >>>> +++ b/configs/aristainetos2_defconfig >>>> @@ -44,6 +44,7 @@ CONFIG_SF_DEFAULT_CS=1 >>>>CONFIG_SF_DEFAULT_MODE=0 >>>>CONFIG_SF_DEFAULT_SPEED=2000 >>>>CONFIG_SPI_FLASH_STMICRO=y >>>> +CONFIG_SPI_FLASH_MTD=y >>>>CONFIG_MTD_UBI_FASTMAP=y >>>>CONFIG_MTD_UBI_FASTMAP_AUTOCONVERT=1 >>>>CONFIG_PHYLIB=y >>>> diff --git a/configs/aristainetos2b_defconfig >>>> b/configs/aristainetos2b_defconfig >>>> index 1054c05d8c..e2da747a8f 100644 >>>> --- a/configs/aristainetos2b_defconfig >>>> +++ b/configs/aristainetos2b_defconfig >>>> @@ -42,6 +42,7 @@ CONFIG_SPI_FLASH=y >>>>CONFIG_SF_DEFAULT_MODE=0 >>>>CONFIG_SF_DEFAULT_SPEED=2000 >>>>CONFIG_SPI_FLASH_STMICRO=y >>>> +CONFIG_SPI_FLASH_MTD=y >>>>CONFIG_MTD_UBI_FASTMAP=y >>>>CONFIG_MTD_UBI_FASTMAP_AUTOCONVERT=1 >>>>CONFIG_PHYLIB=y >>>> diff --git a/configs/aristainetos_defconfig >>>> b/configs/aristainetos_defconfig >>>> index 4080a7b310..5caf95c22f 100644 >>>
[U-Boot] [PATCH v2] mtd: spi: Clean up usage of CONFIG_SPI_FLASH_MTD
From: Frieder Schrempf Most boards currently use SPI_FLASH_MTD only in U-Boot proper, not in SPL. They often rely on hacks in the board header files to include this option conditionally. To be able to fix this, we previously introduced a separate option SPL_SPI_FLASH_MTD. Therefore we can now adjust the Makefile and change the code in sf_probe.c and sf_internal.h to use CONFIG_IS_ENABLED(SPI_FLASH_MTD). We also need to move all occurences of CONFIG_SPI_FLASH_MTD from the header files to the according defconfigs. The affected boards are socfpga, aristainetos, cm_fx6, display5, ventana, rcar-gen2, dh_imx6 and da850evm. We do this all in one patch to guarantee bisectibility. This change was tested with buildman to make sure it does not introduce any regressions by comparing the resulting binary sizes. Signed-off-by: Frieder Schrempf --- Changes vor v2 == * Drop patches 1/3 and 2/3 as they have been applied to u-boot-spi/master * Rebase on current master (c83b1bb923421e95e499b22b010d2f9f463c1226) --- configs/aristainetos2_defconfig| 1 + configs/aristainetos2b_defconfig | 1 + configs/aristainetos_defconfig | 1 + configs/cm_fx6_defconfig | 1 + configs/socfpga_arria5_defconfig | 1 + configs/socfpga_cyclone5_defconfig | 1 + configs/socfpga_dbm_soc1_defconfig | 1 + configs/socfpga_de0_nano_soc_defconfig | 1 + configs/socfpga_de10_nano_defconfig| 1 + configs/socfpga_is1_defconfig | 1 + configs/socfpga_mcvevk_defconfig | 1 + configs/socfpga_sockit_defconfig | 1 + configs/socfpga_socrates_defconfig | 1 + configs/socfpga_sr1500_defconfig | 1 + configs/socfpga_vining_fpga_defconfig | 1 + drivers/mtd/spi/Makefile | 2 +- drivers/mtd/spi/sf_internal.h | 2 +- drivers/mtd/spi/sf_probe.c | 6 +++--- include/configs/aristainetos-common.h | 1 - include/configs/cm_fx6.h | 7 --- include/configs/da850evm.h | 7 +-- include/configs/dh_imx6.h | 1 - include/configs/display5.h | 1 - include/configs/gw_ventana.h | 10 +- include/configs/rcar-gen2-common.h | 4 +--- include/configs/socfpga_common.h | 4 26 files changed, 23 insertions(+), 37 deletions(-) diff --git a/configs/aristainetos2_defconfig b/configs/aristainetos2_defconfig index 18ef5d2dce..0bfc117762 100644 --- a/configs/aristainetos2_defconfig +++ b/configs/aristainetos2_defconfig @@ -44,6 +44,7 @@ CONFIG_SF_DEFAULT_CS=1 CONFIG_SF_DEFAULT_MODE=0 CONFIG_SF_DEFAULT_SPEED=2000 CONFIG_SPI_FLASH_STMICRO=y +CONFIG_SPI_FLASH_MTD=y CONFIG_MTD_UBI_FASTMAP=y CONFIG_MTD_UBI_FASTMAP_AUTOCONVERT=1 CONFIG_PHYLIB=y diff --git a/configs/aristainetos2b_defconfig b/configs/aristainetos2b_defconfig index 1054c05d8c..e2da747a8f 100644 --- a/configs/aristainetos2b_defconfig +++ b/configs/aristainetos2b_defconfig @@ -42,6 +42,7 @@ CONFIG_SPI_FLASH=y CONFIG_SF_DEFAULT_MODE=0 CONFIG_SF_DEFAULT_SPEED=2000 CONFIG_SPI_FLASH_STMICRO=y +CONFIG_SPI_FLASH_MTD=y CONFIG_MTD_UBI_FASTMAP=y CONFIG_MTD_UBI_FASTMAP_AUTOCONVERT=1 CONFIG_PHYLIB=y diff --git a/configs/aristainetos_defconfig b/configs/aristainetos_defconfig index 4080a7b310..5caf95c22f 100644 --- a/configs/aristainetos_defconfig +++ b/configs/aristainetos_defconfig @@ -43,6 +43,7 @@ CONFIG_SF_DEFAULT_BUS=3 CONFIG_SF_DEFAULT_MODE=0 CONFIG_SF_DEFAULT_SPEED=2000 CONFIG_SPI_FLASH_STMICRO=y +CONFIG_SPI_FLASH_MTD=y CONFIG_MTD_UBI_FASTMAP=y CONFIG_MTD_UBI_FASTMAP_AUTOCONVERT=1 CONFIG_PHYLIB=y diff --git a/configs/cm_fx6_defconfig b/configs/cm_fx6_defconfig index eed0558e24..fbaf79d1f0 100644 --- a/configs/cm_fx6_defconfig +++ b/configs/cm_fx6_defconfig @@ -72,6 +72,7 @@ CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y CONFIG_SPI_FLASH_SST=y CONFIG_SPI_FLASH_WINBOND=y +CONFIG_SPI_FLASH_MTD=y CONFIG_PHYLIB=y CONFIG_MII=y CONFIG_DM_PMIC=y diff --git a/configs/socfpga_arria5_defconfig b/configs/socfpga_arria5_defconfig index 93254677e7..51f559cda8 100644 --- a/configs/socfpga_arria5_defconfig +++ b/configs/socfpga_arria5_defconfig @@ -47,6 +47,7 @@ CONFIG_SPI_FLASH=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set +CONFIG_SPI_FLASH_MTD=y CONFIG_PHY_MICREL=y CONFIG_PHY_MICREL_KSZ90X1=y CONFIG_DM_ETH=y diff --git a/configs/socfpga_cyclone5_defconfig b/configs/socfpga_cyclone5_defconfig index 8e5b2e2f66..c648113029 100644 --- a/configs/socfpga_cyclone5_defconfig +++ b/configs/socfpga_cyclone5_defconfig @@ -48,6 +48,7 @@ CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set +CONFIG_SPI_FLASH_MTD=y CONFIG_PHY_MICREL=y CONFIG_PHY_MICREL_KSZ90X1=y CONFIG_DM_ETH=y diff --git a/configs/socfpga_dbm_soc1_defconfig b/configs/socfpga_dbm_soc1_defconfig index c73f3821e7..414f13147e 100644 --- a/configs/socfpga_dbm_soc1_
[U-Boot] [PATCH v3] mtd: spi: Clean up usage of CONFIG_SPI_FLASH_MTD
From: Frieder Schrempf Most boards currently use SPI_FLASH_MTD only in U-Boot proper, not in SPL. They often rely on hacks in the board header files to include this option conditionally. To be able to fix this, we previously introduced a separate option SPL_SPI_FLASH_MTD. Therefore we can now adjust the Makefile and change the code in sf_probe.c and sf_internal.h to use CONFIG_IS_ENABLED(SPI_FLASH_MTD). We also need to move all occurences of CONFIG_SPI_FLASH_MTD from the header files to the according defconfigs. The affected boards are socfpga, aristainetos, cm_fx6, display5, ventana, rcar-gen2, dh_imx6 and da850evm. We do this all in one patch to guarantee bisectibility. This change was tested with buildman to make sure it does not introduce any regressions by comparing the resulting binary sizes. Signed-off-by: Frieder Schrempf Reviewed-by: Stefan Roese Reviewed-by: Simon Goldschmidt Acked-by: Lukasz Majewski Reviewed-by: Heiko Schocher --- Changes vor v2 == * Add missing Reviewed-by and Acked-by tags --- configs/aristainetos2_defconfig| 1 + configs/aristainetos2b_defconfig | 1 + configs/aristainetos_defconfig | 1 + configs/cm_fx6_defconfig | 1 + configs/socfpga_arria5_defconfig | 1 + configs/socfpga_cyclone5_defconfig | 1 + configs/socfpga_dbm_soc1_defconfig | 1 + configs/socfpga_de0_nano_soc_defconfig | 1 + configs/socfpga_de10_nano_defconfig| 1 + configs/socfpga_is1_defconfig | 1 + configs/socfpga_mcvevk_defconfig | 1 + configs/socfpga_sockit_defconfig | 1 + configs/socfpga_socrates_defconfig | 1 + configs/socfpga_sr1500_defconfig | 1 + configs/socfpga_vining_fpga_defconfig | 1 + drivers/mtd/spi/Makefile | 2 +- drivers/mtd/spi/sf_internal.h | 2 +- drivers/mtd/spi/sf_probe.c | 6 +++--- include/configs/aristainetos-common.h | 1 - include/configs/cm_fx6.h | 7 --- include/configs/da850evm.h | 7 +-- include/configs/dh_imx6.h | 1 - include/configs/display5.h | 1 - include/configs/gw_ventana.h | 10 +- include/configs/rcar-gen2-common.h | 4 +--- include/configs/socfpga_common.h | 4 26 files changed, 23 insertions(+), 37 deletions(-) diff --git a/configs/aristainetos2_defconfig b/configs/aristainetos2_defconfig index 18ef5d2dce..0bfc117762 100644 --- a/configs/aristainetos2_defconfig +++ b/configs/aristainetos2_defconfig @@ -44,6 +44,7 @@ CONFIG_SF_DEFAULT_CS=1 CONFIG_SF_DEFAULT_MODE=0 CONFIG_SF_DEFAULT_SPEED=2000 CONFIG_SPI_FLASH_STMICRO=y +CONFIG_SPI_FLASH_MTD=y CONFIG_MTD_UBI_FASTMAP=y CONFIG_MTD_UBI_FASTMAP_AUTOCONVERT=1 CONFIG_PHYLIB=y diff --git a/configs/aristainetos2b_defconfig b/configs/aristainetos2b_defconfig index 1054c05d8c..e2da747a8f 100644 --- a/configs/aristainetos2b_defconfig +++ b/configs/aristainetos2b_defconfig @@ -42,6 +42,7 @@ CONFIG_SPI_FLASH=y CONFIG_SF_DEFAULT_MODE=0 CONFIG_SF_DEFAULT_SPEED=2000 CONFIG_SPI_FLASH_STMICRO=y +CONFIG_SPI_FLASH_MTD=y CONFIG_MTD_UBI_FASTMAP=y CONFIG_MTD_UBI_FASTMAP_AUTOCONVERT=1 CONFIG_PHYLIB=y diff --git a/configs/aristainetos_defconfig b/configs/aristainetos_defconfig index 4080a7b310..5caf95c22f 100644 --- a/configs/aristainetos_defconfig +++ b/configs/aristainetos_defconfig @@ -43,6 +43,7 @@ CONFIG_SF_DEFAULT_BUS=3 CONFIG_SF_DEFAULT_MODE=0 CONFIG_SF_DEFAULT_SPEED=2000 CONFIG_SPI_FLASH_STMICRO=y +CONFIG_SPI_FLASH_MTD=y CONFIG_MTD_UBI_FASTMAP=y CONFIG_MTD_UBI_FASTMAP_AUTOCONVERT=1 CONFIG_PHYLIB=y diff --git a/configs/cm_fx6_defconfig b/configs/cm_fx6_defconfig index eed0558e24..fbaf79d1f0 100644 --- a/configs/cm_fx6_defconfig +++ b/configs/cm_fx6_defconfig @@ -72,6 +72,7 @@ CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y CONFIG_SPI_FLASH_SST=y CONFIG_SPI_FLASH_WINBOND=y +CONFIG_SPI_FLASH_MTD=y CONFIG_PHYLIB=y CONFIG_MII=y CONFIG_DM_PMIC=y diff --git a/configs/socfpga_arria5_defconfig b/configs/socfpga_arria5_defconfig index 93254677e7..51f559cda8 100644 --- a/configs/socfpga_arria5_defconfig +++ b/configs/socfpga_arria5_defconfig @@ -47,6 +47,7 @@ CONFIG_SPI_FLASH=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set +CONFIG_SPI_FLASH_MTD=y CONFIG_PHY_MICREL=y CONFIG_PHY_MICREL_KSZ90X1=y CONFIG_DM_ETH=y diff --git a/configs/socfpga_cyclone5_defconfig b/configs/socfpga_cyclone5_defconfig index 8e5b2e2f66..c648113029 100644 --- a/configs/socfpga_cyclone5_defconfig +++ b/configs/socfpga_cyclone5_defconfig @@ -48,6 +48,7 @@ CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set +CONFIG_SPI_FLASH_MTD=y CONFIG_PHY_MICREL=y CONFIG_PHY_MICREL_KSZ90X1=y CONFIG_DM_ETH=y diff --git a/configs/socfpga_dbm_soc1_defconfig b/configs/socfpga_dbm_soc1_defconfig index c73f3821e7..414f13147e 100644 --- a/configs/so
Re: [U-Boot] [EXT] Re: [PATCH 1/6] spi: fsl_qspi: Fix DDR mode setting for latest iMX platforms
Hi Ashish, On 22.10.19 18:11, Ashish Kumar wrote: > > >> -Original Message- >> From: Stefan Roese >> Sent: Tuesday, October 22, 2019 9:12 PM >> To: Schrempf Frieder ; Ashish Kumar >> ; Ye Li ; >> ja...@amarulasolutions.com >> Cc: Fabio Estevam ; u-boot@lists.denx.de; dl- >> uboot-imx >> Subject: Re: [U-Boot] [EXT] Re: [PATCH 1/6] spi: fsl_qspi: Fix DDR mode >> setting for latest iMX platforms >> >> Caution: EXT Email >> >> Hi Frieder, >> >> On 22.10.19 15:55, Schrempf Frieder wrote: >>> Hi Stefan, >>> >>> On 22.10.19 15:18, Stefan Roese wrote: >>>> Hi Frieder, >>>> Hi Ashish, >>>> Hi Ye Li, >>>> Hi Fabio, >>>> >>>> On 18.09.19 09:42, Stefan Roese wrote: >>>>> Hi Frieder, >>>>> >>>>> On 18.09.19 09:08, Schrempf Frieder wrote: >>>>> >>>>> >>>>> >>>>>>> One further update on this QSPI driver. This driver only works >>>>>>> when loaded via "imx_usb" on the i.MX6ULL EVK. When programmed >>>>>>> into QSPI and booted from QSPI this driver does not detect the SPI >>>>>>> NOR >>>>>>> flash: >>>>>>> >>>>>>> => sf probe >>>>>>> unrecognized JEDEC id bytes: ff, ff, ff >>>>>>> >>>>>>> Do you have any idea what might explain this difference. I would >>>>>>> have expected that when booting via QSPI it would be "easier" for >>>>>>> the driver, as the BootROM already initializes the QSPI interface. >>>>>>> Which is not the case in the boot via serial download (imx_usb) >>>>>>> mode. Here everyhting (pinmux, clocks, etc) need to be configured. >>>>>>> >>>>>>> My feeling is that something is configured "incorrectly" by the >>>>>>> BootROM in this case which is not re-configured as the QSPI driver >>>>>>> needs it to be currently. >>>>>>> >>>>>>> Do you have any ideas on what might be the problem here? Is there >>>>>>> something that I can do to help test this? Would it help if I >>>>>>> would send the debug logging of the driver? >>>>>> >>>>>> I have a strong suspicion of what goes wrong in your case. We >>>>>> experienced exactly the same issue recently on i.MX6ULL. For some >>>>>> reasons (I guess differences in BootROM) this does not happen on >>>>>> i.MX6UL. >>>>>> >>>>>> The problem is, that the BootROM sets the TDH bits in the >>>>>> QuadSPI_FLSHCR register to '01' in case it uses the DDR mode. >>>>>> Afterwards when U-Boot or Linux try to access the flash in SDR >>>>>> mode, they fail as the TDH bits are still set. Resetting them to '00' >>>>>> solves >> the problem. >>>>>> >>>>>> Unfortunately the TDH bits are not documented in the manual of the >>>>>> i.MX6UL/ULL, but they can be found in the manual of the i.MX7. >>>>>> >>>>>> For the QSPI driver, this means it needs a fix to set/reset the TDH >>>>>> bits according to the mode that is used (DDR/SDR). >>>>>> >>>>>> For more details please also look here: >>>>>> >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fc >>>>>> >> ommunity.nxp.com%2Fthread%2F507260&data=02%7C01%7Cashish.ku >> mar% >>>>>> >> 40nxp.com%7Cc03ee11b869c47c9a7d308d757065561%7C686ea1d3bc2b4c6fa >> 92c >>>>>> >> d99c5c301635%7C0%7C0%7C637073557020848801&sdata=ZvRU8vVPq0ll >> gIF >>>>>> 56nVugHjTQhM0E1GJ8PPl6P46vrg%3D&reserved=0 >>>>> >>>>> Perfect. With these bits set to 00 again, booting from QSPI now >>>>> works on the EVK. Many thanks for this hint! :) >>>> >>>> I'm coming back to this issue, as we now have the new NXP patches >>>> integrated into mainline. Including this one: >>>> >>>> 7949576664ac "spi: fsl_qspi: Fix DDR mode setting for latest iMX >>>> platforms" > I've now re-tested current mainline on the i.MX6ULL Eval >>>> Kit and QSP
Re: [U-Boot] [PATCH V1 1/6] clk: imx8mm: add enet clk
On 22.10.19 05:29, Peng Fan wrote:
> Add enet ref/timer/PHY_REF/root clk which are required to make enet
> function well.
>
> Signed-off-by: Peng Fan
Reviewed-by: Frieder Schrempf
Tested-by: Frieder Schrempf
> ---
> drivers/clk/imx/clk-imx8mm.c | 27 +++
> 1 file changed, 27 insertions(+)
>
> diff --git a/drivers/clk/imx/clk-imx8mm.c b/drivers/clk/imx/clk-imx8mm.c
> index f4913e70ab..4911345fd9 100644
> --- a/drivers/clk/imx/clk-imx8mm.c
> +++ b/drivers/clk/imx/clk-imx8mm.c
> @@ -80,6 +80,17 @@ static const char *imx8mm_ahb_sels[] = {"osc_24m",
> "sys_pll1_133m", "sys_pll1_80
> static const char *imx8mm_enet_axi_sels[] = {"clock-osc-24m",
> "sys_pll1_266m", "sys_pll1_800m", "sys_pll2_250m",
>"sys_pll2_200m", "audio_pll1_out",
> "video_pll1_out", "sys_pll3_out", };
>
> +#ifndef CONFIG_SPL_BUILD
> +static const char *imx8mm_enet_ref_sels[] = {"clock-osc-24m",
> "sys_pll2_125m", "sys_pll2_50m", "sys_pll2_100m",
> + "sys_pll1_160m", "audio_pll1_out",
> "video_pll1_out", "clk_ext4", };
> +
> +static const char *imx8mm_enet_timer_sels[] = {"clock-osc-24m",
> "sys_pll2_100m", "audio_pll1_out", "clk_ext1", "clk_ext2",
> +"clk_ext3", "clk_ext4",
> "video_pll1_out", };
> +
> +static const char *imx8mm_enet_phy_sels[] = {"clock-osc-24m",
> "sys_pll2_50m", "sys_pll2_125m", "sys_pll2_200m",
> + "sys_pll2_500m", "video_pll1_out",
> "audio_pll2_out", };
> +#endif
> +
> static const char *imx8mm_nand_usdhc_sels[] = {"clock-osc-24m",
> "sys_pll1_266m", "sys_pll1_800m", "sys_pll2_200m",
> "sys_pll1_133m", "sys_pll3_out",
> "sys_pll2_250m", "audio_pll1_out", };
>
> @@ -363,6 +374,22 @@ static int imx8mm_clk_probe(struct udevice *dev)
> clk_dm(IMX8MM_CLK_USDHC3_ROOT,
> imx_clk_gate4("usdhc3_root_clk", "usdhc3", base + 0x45e0, 0));
>
> + /* clks not needed in SPL stage */
> +#ifndef CONFIG_SPL_BUILD
> + clk_dm(IMX8MM_CLK_ENET_REF,
> +imx8m_clk_composite("enet_ref", imx8mm_enet_ref_sels,
> +base + 0xa980));
> + clk_dm(IMX8MM_CLK_ENET_TIMER,
> +imx8m_clk_composite("enet_timer", imx8mm_enet_timer_sels,
> +base + 0xaa00));
> + clk_dm(IMX8MM_CLK_ENET_PHY_REF,
> +imx8m_clk_composite("enet_phy", imx8mm_enet_phy_sels,
> +base + 0xaa80));
> + clk_dm(IMX8MM_CLK_ENET1_ROOT,
> +imx_clk_gate4("enet1_root_clk", "enet_axi",
> +base + 0x40a0, 0));
> +#endif
> +
> #ifdef CONFIG_SPL_BUILD
> struct clk *clkp, *clkp1;
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH V1 2/6] clk: imx: imx8mm: add set_parent callback
On 22.10.19 05:29, Peng Fan wrote:
> Add set_parent callback, then assigned-clock-parents in dts could
> be work.
>
> Signed-off-by: Peng Fan
Reviewed-by: Frieder Schrempf
Tested-by: Frieder Schrempf
> ---
> drivers/clk/imx/clk-imx8mm.c | 19 +++
> 1 file changed, 19 insertions(+)
>
> diff --git a/drivers/clk/imx/clk-imx8mm.c b/drivers/clk/imx/clk-imx8mm.c
> index 4911345fd9..091b092bbb 100644
> --- a/drivers/clk/imx/clk-imx8mm.c
> +++ b/drivers/clk/imx/clk-imx8mm.c
> @@ -175,11 +175,30 @@ static int imx8mm_clk_enable(struct clk *clk)
> return __imx8mm_clk_enable(clk, 1);
> }
>
> +static int imx8mm_clk_set_parent(struct clk *clk, struct clk *parent)
> +{
> + struct clk *c, *cp;
> + int ret;
> +
> + debug("%s(#%lu), parent: %lu\n", __func__, clk->id, parent->id);
> +
> + ret = clk_get_by_id(clk->id, &c);
> + if (ret)
> + return ret;
> +
> + ret = clk_get_by_id(parent->id, &cp);
> + if (ret)
> + return ret;
> +
> + return clk_set_parent(c, cp);
> +}
> +
> static struct clk_ops imx8mm_clk_ops = {
> .set_rate = imx8mm_clk_set_rate,
> .get_rate = imx8mm_clk_get_rate,
> .enable = imx8mm_clk_enable,
> .disable = imx8mm_clk_disable,
> + .set_parent = imx8mm_clk_set_parent,
> };
>
> static int imx8mm_clk_probe(struct udevice *dev)
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH V1 4/6] net: Kconfig: FEC: Add dependency on i.MX8M
On 22.10.19 05:29, Peng Fan wrote: > Make FEC driver could be used by i.MX8M when CONFIG_FEC_MXC defined > in defconfig. > > Signed-off-by: Peng Fan Reviewed-by: Frieder Schrempf Tested-by: Frieder Schrempf > --- > drivers/net/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig > index 2ce3092db0..08cdd95727 100644 > --- a/drivers/net/Kconfig > +++ b/drivers/net/Kconfig > @@ -236,7 +236,7 @@ config FEC_MXC_MDIO_BASE > > config FEC_MXC > bool "FEC Ethernet controller" > - depends on MX28 || MX5 || MX6 || MX7 || IMX8 || VF610 > + depends on MX28 || MX5 || MX6 || MX7 || IMX8 || IMX8M || VF610 > help > This driver supports the 10/100 Fast Ethernet controller for > NXP i.MX processors. > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH V1 5/6] net: fec_mxc: support i.MX8M with CLK_CCF
On 22.10.19 05:30, Peng Fan wrote:
> Add more clks for fec_mxc according to Linux Kernel 5.4.0-rc1
> drivers/net/ethernet/freescale/fec_main.c.
>
> Since i.MX8MQ not support CLK_CCF, so add a check to restrict
> the code only effect when CONFIG_IMX8M and CONFIG_CLK_CCF both defined.
>
> Signed-off-by: Peng Fan
> ---
> drivers/net/fec_mxc.c | 74
> ---
> drivers/net/fec_mxc.h | 4 +++
> 2 files changed, 63 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
> index 080dbcf7db..9362aa0d05 100644
> --- a/drivers/net/fec_mxc.c
> +++ b/drivers/net/fec_mxc.c
> @@ -125,28 +125,29 @@ static int fec_mdio_read(struct ethernet_regs *eth,
> uint8_t phyaddr,
>
> static int fec_get_clk_rate(void *udev, int idx)
> {
> -#if IS_ENABLED(CONFIG_IMX8)
> struct fec_priv *fec;
> struct udevice *dev;
> int ret;
>
> - dev = udev;
> - if (!dev) {
> - ret = uclass_get_device(UCLASS_ETH, idx, &dev);
> - if (ret < 0) {
> - debug("Can't get FEC udev: %d\n", ret);
> - return ret;
> + if (IS_ENABLED(CONFIG_IMX8) ||
> + (IS_ENABLED(CONFIG_IMX8M) && IS_ENABLED(CONFIG_CLK_CCF))) {
Can't we just drop the IS_ENABLED(CONFIG_IMX8M)? Otherwise we always
need to touch this code when other SoCs will start using CCF.
Also can you use CONFIG_IS_ENABLED(CLK_CCF) instead of
IS_ENABLED(CONFIG_CLK_CCF), so we can detect the config options for SPL
and non-SPL separately?
> + dev = udev;
> + if (!dev) {
> + ret = uclass_get_device(UCLASS_ETH, idx, &dev);
> + if (ret < 0) {
> + debug("Can't get FEC udev: %d\n", ret);
> + return ret;
> + }
> }
> - }
>
> - fec = dev_get_priv(dev);
> - if (fec)
> - return fec->clk_rate;
> + fec = dev_get_priv(dev);
> + if (fec)
> + return fec->clk_rate;
>
> - return -EINVAL;
> -#else
> - return imx_get_fecclk();
> -#endif
> + return -EINVAL;
> + } else {
> + return imx_get_fecclk();
> + }
> }
>
> static void fec_mii_setspeed(struct ethernet_regs *eth)
> @@ -1335,6 +1336,49 @@ static int fecmxc_probe(struct udevice *dev)
> return ret;
> }
>
> + priv->clk_rate = clk_get_rate(&priv->ipg_clk);
> + } else if (IS_ENABLED(CONFIG_IMX8M) && IS_ENABLED(CONFIG_CLK_CCF)) {
Same questions here as above.
> + ret = clk_get_by_name(dev, "ipg", &priv->ipg_clk);
> + if (ret < 0) {
> + debug("Can't get FEC ipg clk: %d\n", ret);
> + return ret;
> + } else {
You can drop the else branches here and below as the code returns before
it will be evaluated.
> + ret = clk_enable(&priv->ipg_clk);
> + if(ret)
> + return ret;
> + }
> +
> + ret = clk_get_by_name(dev, "ipg", &priv->ahb_clk);
This should be "ahb", not "ipg".
> + if (ret < 0) {
> + debug("Can't get FEC ahb clk: %d\n", ret);
> + return ret;
> + } else {
> + ret = clk_enable(&priv->ahb_clk);
> + if (ret)
> + return ret;
> + }
> +
> + ret = clk_get_by_name(dev, "enet_out", &priv->clk_enet_out);
> + if (!ret) {
> + ret = clk_enable(&priv->clk_enet_out);
> + if (ret)
> + return ret;
> + }
> +
> + ret = clk_get_by_name(dev, "enet_clk_ref", &priv->clk_ref);
> + if (!ret) {
> + ret = clk_enable(&priv->clk_ref);
> + if (ret)
> + return ret;
> + }
> +
> + ret = clk_get_by_name(dev, "ptp", &priv->clk_ptp);
> + if (!ret) {
> + ret = clk_enable(&priv->clk_ptp);
> + if (ret)
> + return ret;
> + }
> +
> priv->clk_rate = clk_get_rate(&priv->ipg_clk);
> }
>
> diff --git a/drivers/net/fec_mxc.h b/drivers/net/fec_mxc.h
> index e5f2dd75c5..723b06a651 100644
> --- a/drivers/net/fec_mxc.h
> +++ b/drivers/net/fec_mxc.h
> @@ -264,6 +264,10 @@ struct fec_priv {
> u32 interface;
> #endif
> struct clk ipg_clk;
> + struct clk ahb_clk;
> + struct clk clk_enet_out;
> + struct clk clk_ref;
> + struct clk clk_ptp;
> u32 clk_rate;
> };
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] clk: imx: imx8mm: Fix the first root clock in imx8mm_ahb_sels[]
From: Frieder Schrempf
The 24MHz oscillator clock is referenced by "clock-osc-24m" and not
"osc_24m".
Signed-off-by: Frieder Schrempf
---
drivers/clk/imx/clk-imx8mm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/imx/clk-imx8mm.c b/drivers/clk/imx/clk-imx8mm.c
index 091b092bbb..a05dac7c7a 100644
--- a/drivers/clk/imx/clk-imx8mm.c
+++ b/drivers/clk/imx/clk-imx8mm.c
@@ -74,7 +74,7 @@ static const char *sys_pll3_bypass_sels[] = {"sys_pll3",
"sys_pll3_ref_sel", };
static const char *imx8mm_a53_sels[] = {"clock-osc-24m", "arm_pll_out",
"sys_pll2_500m", "sys_pll2_1000m",
"sys_pll1_800m", "sys_pll1_400m",
"audio_pll1_out", "sys_pll3_out", };
-static const char *imx8mm_ahb_sels[] = {"osc_24m", "sys_pll1_133m",
"sys_pll1_800m", "sys_pll1_400m",
+static const char *imx8mm_ahb_sels[] = {"clock-osc-24m", "sys_pll1_133m",
"sys_pll1_800m", "sys_pll1_400m",
"sys_pll2_125m", "sys_pll3_out",
"audio_pll1_out", "video_pll1_out", };
static const char *imx8mm_enet_axi_sels[] = {"clock-osc-24m", "sys_pll1_266m",
"sys_pll1_800m", "sys_pll2_250m",
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] clk: imx: imx8mm: Fix the first root clock in imx8mm_ahb_sels[]
On 23.10.19 18:36, Schrempf Frieder wrote:
> From: Frieder Schrempf
>
> The 24MHz oscillator clock is referenced by "clock-osc-24m" and not
> "osc_24m".
>
> Signed-off-by: Frieder Schrempf
Just for completeness:
Fixes: f62ec5c4bba2 ("clk: imx: add i.MX8MM clk driver")
> ---
> drivers/clk/imx/clk-imx8mm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/clk/imx/clk-imx8mm.c b/drivers/clk/imx/clk-imx8mm.c
> index 091b092bbb..a05dac7c7a 100644
> --- a/drivers/clk/imx/clk-imx8mm.c
> +++ b/drivers/clk/imx/clk-imx8mm.c
> @@ -74,7 +74,7 @@ static const char *sys_pll3_bypass_sels[] = {"sys_pll3",
> "sys_pll3_ref_sel", };
> static const char *imx8mm_a53_sels[] = {"clock-osc-24m", "arm_pll_out",
> "sys_pll2_500m", "sys_pll2_1000m",
> "sys_pll1_800m", "sys_pll1_400m",
> "audio_pll1_out", "sys_pll3_out", };
>
> -static const char *imx8mm_ahb_sels[] = {"osc_24m", "sys_pll1_133m",
> "sys_pll1_800m", "sys_pll1_400m",
> +static const char *imx8mm_ahb_sels[] = {"clock-osc-24m", "sys_pll1_133m",
> "sys_pll1_800m", "sys_pll1_400m",
> "sys_pll2_125m", "sys_pll3_out",
> "audio_pll1_out", "video_pll1_out", };
>
> static const char *imx8mm_enet_axi_sels[] = {"clock-osc-24m",
> "sys_pll1_266m", "sys_pll1_800m", "sys_pll2_250m",
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH V1 5/6] net: fec_mxc: support i.MX8M with CLK_CCF
On 24.10.19 03:09, Peng Fan wrote:
>> Subject: Re: [U-Boot] [PATCH V1 5/6] net: fec_mxc: support i.MX8M with
>> CLK_CCF
>>
>> On 22.10.19 05:30, Peng Fan wrote:
>>> Add more clks for fec_mxc according to Linux Kernel 5.4.0-rc1
>>> drivers/net/ethernet/freescale/fec_main.c.
>>>
>>> Since i.MX8MQ not support CLK_CCF, so add a check to restrict the code
>>> only effect when CONFIG_IMX8M and CONFIG_CLK_CCF both defined.
>>>
>>> Signed-off-by: Peng Fan
>>> ---
>>>drivers/net/fec_mxc.c | 74
>> ---
>>>drivers/net/fec_mxc.h | 4 +++
>>>2 files changed, 63 insertions(+), 15 deletions(-)
>>>
>>> diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c index
>>> 080dbcf7db..9362aa0d05 100644
>>> --- a/drivers/net/fec_mxc.c
>>> +++ b/drivers/net/fec_mxc.c
>>> @@ -125,28 +125,29 @@ static int fec_mdio_read(struct ethernet_regs
>>> *eth, uint8_t phyaddr,
>>>
>>>static int fec_get_clk_rate(void *udev, int idx)
>>>{
>>> -#if IS_ENABLED(CONFIG_IMX8)
>>> struct fec_priv *fec;
>>> struct udevice *dev;
>>> int ret;
>>>
>>> - dev = udev;
>>> - if (!dev) {
>>> - ret = uclass_get_device(UCLASS_ETH, idx, &dev);
>>> - if (ret < 0) {
>>> - debug("Can't get FEC udev: %d\n", ret);
>>> - return ret;
>>> + if (IS_ENABLED(CONFIG_IMX8) ||
>>> + (IS_ENABLED(CONFIG_IMX8M) &&
>> IS_ENABLED(CONFIG_CLK_CCF))) {
>>
>> Can't we just drop the IS_ENABLED(CONFIG_IMX8M)? Otherwise we always
>> need to touch this code when other SoCs will start using CCF.
>
> ok.
>
>>
>> Also can you use CONFIG_IS_ENABLED(CLK_CCF) instead of
>> IS_ENABLED(CONFIG_CLK_CCF), so we can detect the config options for SPL
>> and non-SPL separately?
>
> FEC will not be used in SPL stage, so I not use CONFIG_IS_ENABLED.
> But it does not hurt using IS_ENABLED, change in v2.
>
> Regards,
> Peng.
>
>>
>>> + dev = udev;
>>> + if (!dev) {
>>> + ret = uclass_get_device(UCLASS_ETH, idx, &dev);
>>> + if (ret < 0) {
>>> + debug("Can't get FEC udev: %d\n", ret);
>>> + return ret;
>>> + }
>>> }
>>> - }
>>>
>>> - fec = dev_get_priv(dev);
>>> - if (fec)
>>> - return fec->clk_rate;
>>> + fec = dev_get_priv(dev);
>>> + if (fec)
>>> + return fec->clk_rate;
>>>
>>> - return -EINVAL;
>>> -#else
>>> - return imx_get_fecclk();
>>> -#endif
>>> + return -EINVAL;
>>> + } else {
>>> + return imx_get_fecclk();
>>> + }
>>>}
>>>
>>>static void fec_mii_setspeed(struct ethernet_regs *eth) @@ -1335,6
>>> +1336,49 @@ static int fecmxc_probe(struct udevice *dev)
>>> return ret;
>>> }
>>>
>>> + priv->clk_rate = clk_get_rate(&priv->ipg_clk);
>>> + } else if (IS_ENABLED(CONFIG_IMX8M) &&
>> IS_ENABLED(CONFIG_CLK_CCF)) {
>>
>> Same questions here as above.
>>
>>> + ret = clk_get_by_name(dev, "ipg", &priv->ipg_clk);
>>> + if (ret < 0) {
>>> + debug("Can't get FEC ipg clk: %d\n", ret);
>>> + return ret;
>>> + } else {
>>
>> You can drop the else branches here and below as the code returns before it
>> will be evaluated.
I think you missed this comment for your v2.
>>
>>> + ret = clk_enable(&priv->ipg_clk);
>>> + if(ret)
>>> + return ret;
>>> + }
>>> +
>>> + ret = clk_get_by_name(dev, "ipg", &priv->ahb_clk);
>>
>> This should be "ahb", not "ipg".
And this one, too.
>>
>>> + if (ret < 0) {
>>> + debug("Can't get FEC ahb clk: %d\n", ret);
>>> + return ret;
>>> + } else {
>>> + ret = clk_enable(&priv->ahb_clk);
>>> + if (ret)
>>> + return ret;
>>> + }
>>> +
>>> + ret = clk_get_by_name(dev, "enet_out", &priv->clk_enet_out);
>>> + if (!ret) {
>>> + ret = clk_enable(&priv->clk_enet_out);
>>> + if (ret)
>>> + return ret;
>>> + }
>>> +
>>> + ret = clk_get_by_name(dev, "enet_clk_ref", &priv->clk_ref);
>>> + if (!ret) {
>>> + ret = clk_enable(&priv->clk_ref);
>>> + if (ret)
>>> + return ret;
>>> + }
>>> +
>>> + ret = clk_get_by_name(dev, "ptp", &priv->clk_ptp);
>>> + if (!ret) {
>>> + ret = clk_enable(&priv->clk_ptp);
>>> + if (ret)
>>> + return ret;
>>> + }
>>> +
>>> priv->clk_rate = clk_get_rate(&priv->ipg_clk);
>>> }
>>>
>>> diff --git a/drivers/net/fec_mxc.h b/drivers/net/fec_mxc.h index
>>> e5f2dd75c5..723b06a651 100644
>>> --- a/drivers
Re: [U-Boot] [PATCH V3 5/6] net: fec_mxc: support i.MX8M with CLK_CCF
On 24.10.19 11:33, Peng Fan wrote:
> Add more clks for fec_mxc according to Linux Kernel 5.4.0-rc1
> drivers/net/ethernet/freescale/fec_main.c.
>
> Since i.MX8MQ not support CLK_CCF, so add a check to restrict
> the code only effect when CONFIG_IMX8M and CONFIG_CLK_CCF both defined.
>
> Signed-off-by: Peng Fan
Reviewed-by: Frieder Schrempf
> ---
>
> V3:
> Drop unneeded else
> correct ipg->ahb
> Other patches keep V1
>
> V2:
> Use CONFIG_IS_ENABLED
>
> drivers/net/fec_mxc.c | 72
> ---
> drivers/net/fec_mxc.h | 4 +++
> 2 files changed, 61 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
> index 080dbcf7db..5bc31fd362 100644
> --- a/drivers/net/fec_mxc.c
> +++ b/drivers/net/fec_mxc.c
> @@ -125,28 +125,29 @@ static int fec_mdio_read(struct ethernet_regs *eth,
> uint8_t phyaddr,
>
> static int fec_get_clk_rate(void *udev, int idx)
> {
> -#if IS_ENABLED(CONFIG_IMX8)
> struct fec_priv *fec;
> struct udevice *dev;
> int ret;
>
> - dev = udev;
> - if (!dev) {
> - ret = uclass_get_device(UCLASS_ETH, idx, &dev);
> - if (ret < 0) {
> - debug("Can't get FEC udev: %d\n", ret);
> - return ret;
> + if (IS_ENABLED(CONFIG_IMX8) ||
> + CONFIG_IS_ENABLED(CLK_CCF)) {
> + dev = udev;
> + if (!dev) {
> + ret = uclass_get_device(UCLASS_ETH, idx, &dev);
> + if (ret < 0) {
> + debug("Can't get FEC udev: %d\n", ret);
> + return ret;
> + }
> }
> - }
>
> - fec = dev_get_priv(dev);
> - if (fec)
> - return fec->clk_rate;
> + fec = dev_get_priv(dev);
> + if (fec)
> + return fec->clk_rate;
>
> - return -EINVAL;
> -#else
> - return imx_get_fecclk();
> -#endif
> + return -EINVAL;
> + } else {
> + return imx_get_fecclk();
> + }
> }
>
> static void fec_mii_setspeed(struct ethernet_regs *eth)
> @@ -1335,6 +1336,47 @@ static int fecmxc_probe(struct udevice *dev)
> return ret;
> }
>
> + priv->clk_rate = clk_get_rate(&priv->ipg_clk);
> + } else if (CONFIG_IS_ENABLED(CLK_CCF)) {
> + ret = clk_get_by_name(dev, "ipg", &priv->ipg_clk);
> + if (ret < 0) {
> + debug("Can't get FEC ipg clk: %d\n", ret);
> + return ret;
> + }
> + ret = clk_enable(&priv->ipg_clk);
> + if(ret)
> + return ret;
> +
> + ret = clk_get_by_name(dev, "ahb", &priv->ahb_clk);
> + if (ret < 0) {
> + debug("Can't get FEC ahb clk: %d\n", ret);
> + return ret;
> + }
> + ret = clk_enable(&priv->ahb_clk);
> + if (ret)
> + return ret;
> +
> + ret = clk_get_by_name(dev, "enet_out", &priv->clk_enet_out);
> + if (!ret) {
> + ret = clk_enable(&priv->clk_enet_out);
> + if (ret)
> + return ret;
> + }
> +
> + ret = clk_get_by_name(dev, "enet_clk_ref", &priv->clk_ref);
> + if (!ret) {
> + ret = clk_enable(&priv->clk_ref);
> + if (ret)
> + return ret;
> + }
> +
> + ret = clk_get_by_name(dev, "ptp", &priv->clk_ptp);
> + if (!ret) {
> + ret = clk_enable(&priv->clk_ptp);
> + if (ret)
> + return ret;
> + }
> +
> priv->clk_rate = clk_get_rate(&priv->ipg_clk);
> }
>
> diff --git a/drivers/net/fec_mxc.h b/drivers/net/fec_mxc.h
> index e5f2dd75c5..723b06a651 100644
> --- a/drivers/net/fec_mxc.h
> +++ b/drivers/net/fec_mxc.h
> @@ -264,6 +264,10 @@ struct fec_priv {
> u32 interface;
> #endif
> struct clk ipg_clk;
> + struct clk ahb_clk;
> + struct clk clk_enet_out;
> + struct clk clk_ref;
> + struct clk clk_ptp;
> u32 clk_rate;
> };
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [PATCH 1/1] tools: imx8m_image: fix warning message
On 21.01.20 11:58, Sébastien Szymanski wrote:
> When a firmware file is missing the warning message doesn't indicate the
> firmware file name because '$tmp' var doesn't exist.
> Fix the warning message and while at it reduce the if/else statement.
>
> Signed-off-by: Sébastien Szymanski
Thanks for fixing my previous patch.
Fixes: 162c72c80445 ("tools: imx8m_image: Change source path for DDR
firmware to build dir")
Reviewed-by: Frieder Schrempf
> ---
> tools/imx8m_image.sh | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/tools/imx8m_image.sh b/tools/imx8m_image.sh
> index 4959f9c835..ba60104443 100755
> --- a/tools/imx8m_image.sh
> +++ b/tools/imx8m_image.sh
> @@ -14,10 +14,8 @@ for f in $blobs; do
> continue
> fi
>
> - if [ -f $f ]; then
> - continue
> - else
> - echo "WARNING '$tmp' not found, resulting binary is
> not-functional" >&2
> + if [ ! -f $f ]; then
> + echo "WARNING '$f' not found, resulting binary is
> not-functional" >&2
> exit 1
> fi
> done
>
Re: [PATCH v2 2/8] dt-bindings: pinctrl: imx8mm: add alternative uart muxings
Hi, On 26.01.20 04:55, Marcel Ziswiler wrote: > From: Max Krummenacher > > Add alternative UART muxing defines. > > Signed-off-by: Max Krummenacher Patch 1/8 and 2/8 in this series change the pin definitions for the i.MX8MM so that they deviate from the definitions in the Linux kernel. As Fabio already pointed out for v1, please instead of adding these changes, just sync with the definitions in linux-next [1], which should already contain these additions from what I can see. Thanks, Frieder [1]: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/freescale/imx8mm-pinfunc.h > > --- > > Changes in v2: > - Fixed some copy-paste errors. > > arch/arm/dts/imx8mm-pinfunc.h | 16 > 1 file changed, 16 insertions(+) > > diff --git a/arch/arm/dts/imx8mm-pinfunc.h b/arch/arm/dts/imx8mm-pinfunc.h > index 3e9955566a..e7fac56db3 100644 > --- a/arch/arm/dts/imx8mm-pinfunc.h > +++ b/arch/arm/dts/imx8mm-pinfunc.h > @@ -472,21 +472,37 @@ > #define MX8MM_IOMUXC_SAI3_RXC_SAI3_RX_BCLK > 0x1D0 0x438 0x000 0x0 0x0 > #define MX8MM_IOMUXC_SAI3_RXC_GPT1_CLK > 0x1D0 0x438 0x000 0x1 0x0 > #define MX8MM_IOMUXC_SAI3_RXC_SAI5_RX_BCLK > 0x1D0 0x438 0x4D0 0x2 0x2 > +#define MX8MM_IOMUXC_SAI3_RXC_UART2_DCE_CTS_B > 0x1D0 0x438 0x000 0x4 0x0 > +#define MX8MM_IOMUXC_SAI3_RXC_UART2_DCE_RTS_B > 0x1D0 0x438 0x4F8 0x4 0x2 > +#define MX8MM_IOMUXC_SAI3_RXC_UART2_DTE_CTS_B > 0x1D0 0x438 0x4F8 0x4 0x2 > +#define MX8MM_IOMUXC_SAI3_RXC_UART2_DTE_RTS_B > 0x1D0 0x438 0x000 0x4 0x0 > #define MX8MM_IOMUXC_SAI3_RXC_GPIO4_IO29 > 0x1D0 0x438 0x000 0x5 0x0 > #define MX8MM_IOMUXC_SAI3_RXC_TPSMP_HTRANS1 > 0x1D0 0x438 0x000 0x7 0x0 > #define MX8MM_IOMUXC_SAI3_RXD_SAI3_RX_DATA0 > 0x1D4 0x43C 0x000 0x0 0x0 > #define MX8MM_IOMUXC_SAI3_RXD_GPT1_COMPARE1 > 0x1D4 0x43C 0x000 0x1 0x0 > #define MX8MM_IOMUXC_SAI3_RXD_SAI5_RX_DATA0 > 0x1D4 0x43C 0x4D4 0x2 0x2 > +#define MX8MM_IOMUXC_SAI3_RXD_UART2_DCE_RTS_B > 0x1D4 0x43C 0x4F8 0x4 0x3 > +#define MX8MM_IOMUXC_SAI3_RXD_UART2_DCE_CTS_B > 0x1D4 0x43C 0x000 0x4 0x0 > +#define MX8MM_IOMUXC_SAI3_RXD_UART2_DTE_RTS_B > 0x1D4 0x43C 0x000 0x4 0x0 > +#define MX8MM_IOMUXC_SAI3_RXD_UART2_DTE_CTS_B > 0x1D4 0x43C 0x4F8 0x4 0x3 > #define MX8MM_IOMUXC_SAI3_RXD_GPIO4_IO30 > 0x1D4 0x43C 0x000 0x5 0x0 > #define MX8MM_IOMUXC_SAI3_RXD_TPSMP_HDATA0 > 0x1D4 0x43C 0x000 0x7 0x0 > #define MX8MM_IOMUXC_SAI3_TXFS_SAI3_TX_SYNC > 0x1D8 0x440 0x000 0x0 0x0 > #define MX8MM_IOMUXC_SAI3_TXFS_GPT1_CAPTURE2 > 0x1D8 0x440 0x000 0x1 0x0 > #define MX8MM_IOMUXC_SAI3_TXFS_SAI5_RX_DATA1 > 0x1D8 0x440 0x4D8 0x2 0x2 > +#define MX8MM_IOMUXC_SAI3_TXFS_UART2_DCE_RX > 0x1D8 0x440 0x000 0x4 0x0 > +#define MX8MM_IOMUXC_SAI3_TXFS_UART2_DCE_TX > 0x1D8 0x440 0x4FC 0x4 0x2 > +#define MX8MM_IOMUXC_SAI3_TXFS_UART2_DTE_RX > 0x1D8 0x440 0x4FC 0x4 0x2 > +#define MX8MM_IOMUXC_SAI3_TXFS_UART2_DTE_TX > 0x1D8 0x440 0x000 0x4 0x0 > #define MX8MM_IOMUXC_SAI3_TXFS_GPIO4_IO31 > 0x1D8 0x440 0x000 0x5 0x0 > #define MX8MM_IOMUXC_SAI3_TXFS_TPSMP_HDATA1 > 0x1D8 0x440 0x000 0x7 0x0 > #define MX8MM_IOMUXC_SAI3_TXC_SAI3_TX_BCLK > 0x1DC 0x444 0x000 0x0 0x0 > #define MX8MM_IOMUXC_SAI3_TXC_GPT1_COMPARE2 > 0x1DC 0x444 0x000 0x1 0x0 > #define MX8MM_IOMUXC_SAI3_TXC_SAI5_RX_DATA2 > 0x1DC 0x444 0x4DC 0x2 0x2 > +#define MX8MM_IOMUXC_SAI3_TXC_UART2_DCE_RX > 0x1DC 0x444 0x000 0x4 0x0 > +#define MX8MM_IOMUXC_SAI3_TXC_UART2_DCE_TX > 0x1DC 0x444 0x4FC 0x4 0x3 > +#define MX8MM_IOMUXC_SAI3_TXC_UART2_DTE_RX > 0x1DC 0x444 0x4FC 0x4 0x3 > +#define MX8MM_IOMUXC_SAI3_TXC_UART2_DTE_TX > 0x1DC 0x444 0x000 0x4 0x0 > #define MX8MM_IOMUXC_SAI3_TXC_GPIO5_IO0 > 0x1DC 0x444 0x000 0x5 0x0 > #define MX8MM_IOMUXC_SAI3_TXC_TPSMP_HDATA2 > 0x1DC 0x444 0x000 0x7 0x0 > #define MX8MM_IOMUXC_SAI3_TXD_SAI3_TX_DATA0
Re: [EXT] Re: [Patch v4 0/7] Transition of fsl qspi driver to spi-mem framework
Hi, On 27.01.20 10:20, Kuldeep Singh wrote: > Hi Jagan, > >> -Original Message- >> From: Jagan Teki >> Sent: Monday, January 27, 2020 12:50 PM >> To: Kuldeep Singh >> Cc: U-Boot-Denx ; Priyanka Jain >> ; Ashish Kumar ; Stefan >> Roese ; Schrempf Frieder ; >> Vignesh R >> Subject: [EXT] Re: [Patch v4 0/7] Transition of fsl qspi driver to spi-mem >> framework >> >> Caution: EXT Email >> >> Hi Kuldeep, >> >> On Mon, Jan 13, 2020 at 12:57 PM Kuldeep Singh >> wrote: >>> >>> This entire patch series migrate freescale qspi driver to spi-mem >>> framework. >>> >>> v4 version of series include removal of buildman failure on LS2080AQDS >>> build which was observed in cleanup patches. Also, more clear commit >>> message of patch 5. >>> >>> v3 version of series includes correction of copyright in qspi driver >>> and also move SPI_FLASH_SPANSION from header to defconfigs in same >> patch. >>> >>> v2 version of series includes changes in qspi driver to have 1k size >>> instead of complete flash size so as to make driver independent of >>> flash size. This also makes it align with linux version of driver. >>> Also added support for imx platforms to set TDH bits correctly. There >>> are other minor changes in commit messages. >>> >>> Dependency on patches[1][2]. These patches are required to resolve >>> booting crash observed in LS1012ARDB. One crash was related to pfe >>> driver as it was accessing flash memory directly and other was based on >> environment. >>> [1] >>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc >>> >> hwork.ozlabs.org%2Fpatch%2F1219462%2F&data=02%7C01%7Ckuldeep.s >> ingh >>> %40nxp.com%7C94b5e5528efc47df25ea08d7a2f94efd%7C686ea1d3bc2b4c6 >> fa92cd9 >>> >> 9c5c301635%7C0%7C0%7C637157063972042137&sdata=DZFAEmt0sA4c >> cCPmu%2F >>> cArl99B02G2KmiAUYou1RXXBI%3D&reserved=0 >>> [2] >>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc >>> >> hwork.ozlabs.org%2Fpatch%2F1208299%2F&data=02%7C01%7Ckuldeep.s >> ingh >>> %40nxp.com%7C94b5e5528efc47df25ea08d7a2f94efd%7C686ea1d3bc2b4c6 >> fa92cd9 >>> >> 9c5c301635%7C0%7C0%7C637157063972042137&sdata=3qr7QKERZgk8 >> V83QbYMM >>> Nb4xM4rUaqm2v3lZ5gzsGAQ%3D&reserved=0 >>> >>> Patch 1 adds new qspi driver incorporating spi-mem framework and also >>> removal of old driver which was based on spi-nor. The driver is a >>> ported version of linux qspi driver. Initial port was done by Frieder. >>> Now, no more direct memory access to spi-nor memory is possible i.e >>> accessing flash memory using absolute address is not possible. >>> >>> Patch 2 removes unused qspi config options. >>> >>> Patch 3 moves FSL_QSPI to defconfig instead of defining it in header files. >>> >>> Patch 4 removes unused num-cs property from imx platforms. >>> >>> Patch 5 enables SPI_FLASH_SPANSION in ls1012a defconfig as FSL_QSPI is >>> already enabled. >>> >>> Patch 6 enables SPI_FLASH_SPANSION in defconfigs of LS1046a boards >>> instead of defining in header files. >>> >>> Patch 7 updates the device-tree properties treewide for layerscape >>> boards by aligning with linux device-tree properties. >>> >>> Frieder Schrempf (1): >>>imx: imx6sx: Remove unused 'num-cs' property >>> >>> Kuldeep Singh (6): >>>spi: Transform the FSL QuadSPI driver to use the SPI MEM API >>>treewide: Remove unused FSL QSPI config options >>>configs: ls1043a: Move CONFIG_FSL_QSPI to defconfig >>>configs: ls1012a: Enable CONFIG_SPI_FLASH_SPANSION in defconfigs >>>configs: ls1046a: Move SPI_FLASH_SPANSION to defconfig >>>treewide: Update fsl qspi node dt properties as per spi-mem driver >> >> Seems like defconfig changes of these were depends on net changes isn't it? >> if >> yes, we need to wait for them to merge first. > > Actually, net change is required to resolve the booting crash on LS1012ARDB > with this driver. > This series can be applied even without net pfe patch. It could be applied without and as you sad it would break the boot for LS1012ARDB. Therefore no, I don't think we should apply patches that knowingly break things, just because changes elsewhere are not merged yet. So can the maintainers (Joe, Jagan, ...) please figure out how to get [1] merged so we don't block this patch any longer? Thanks, Frieder [1]: https://patchwork.ozlabs.org/patch/1222025/
Re: [PATCH v2 2/8] dt-bindings: pinctrl: imx8mm: add alternative uart muxings
On 28.01.20 13:38, Marcel Ziswiler wrote: > Hi Frieder > > On Mon, 2020-01-27 at 09:10 +, Schrempf Frieder wrote: >> Hi, >> >> On 26.01.20 04:55, Marcel Ziswiler wrote: >>> From: Max Krummenacher >>> >>> Add alternative UART muxing defines. >>> >>> Signed-off-by: Max Krummenacher >> >> Patch 1/8 and 2/8 in this series change the pin definitions for the >> i.MX8MM so that they deviate from the definitions in the Linux >> kernel. > > Yes, I agree. This is not the best approach. > >> As Fabio already pointed out for v1, please instead of adding these >> changes, just sync with the definitions in linux-next [1], which >> should >> already contain these additions from what I can see. > > We had a thorough look at this and while we first were in doubt this > being correct in linux-next we understand now that it just implements > whatever bad UART notation used in NXP's reference manual [2] (section > 16.2.2 External Signals e.g. anybody intimately familiar with UARTs > knows that a DTE vs. DCE TX pin would have different directions [2]). Yes the notation of the UART pins and signals for i.MX SoCs has always been questionable. > Anyway, I will adhere to Fabio and your guidance and just sync with > linux-next for a v3. Ok, thanks! > >> Thanks, >> Frieder > > Thanks! > > Cheers > > Marcel > >> [1]: >> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/freescale/imx8mm-pinfunc.h > > [2] https://www.nxp.com/webapp/Download?colCode=IMX8MMRM > [3] https://en.wikipedia.org/wiki/RS-232#Data_and_control_signals > >>> --- >>> >>> Changes in v2: >>> - Fixed some copy-paste errors. >>> >>>arch/arm/dts/imx8mm-pinfunc.h | 16 >>>1 file changed, 16 insertions(+) >>> >>> diff --git a/arch/arm/dts/imx8mm-pinfunc.h b/arch/arm/dts/imx8mm- >>> pinfunc.h >>> index 3e9955566a..e7fac56db3 100644 >>> --- a/arch/arm/dts/imx8mm-pinfunc.h >>> +++ b/arch/arm/dts/imx8mm-pinfunc.h >>> @@ -472,21 +472,37 @@ >>>#define >>> MX8MM_IOMUXC_SAI3_RXC_SAI3_RX_BCLK >>> 0x1D0 0x438 0x000 0x0 0x0 >>>#define >>> MX8MM_IOMUXC_SAI3_RXC_GPT1_CLK >>> 0x1D0 0x438 0x000 0x1 0x0 >>>#define >>> MX8MM_IOMUXC_SAI3_RXC_SAI5_RX_BCLK >>> 0x1D0 0x438 0x4D0 0x2 0x2 >>> +#define >>> MX8MM_IOMUXC_SAI3_RXC_UART2_DCE_CTS_B >>> 0x1D0 0x438 0x000 0x4 0x0 >>> +#define >>> MX8MM_IOMUXC_SAI3_RXC_UART2_DCE_RTS_B >>> 0x1D0 0x438 0x4F8 0x4 0x2 >>> +#define >>> MX8MM_IOMUXC_SAI3_RXC_UART2_DTE_CTS_B >>> 0x1D0 0x438 0x4F8 0x4 0x2 >>> +#define >>> MX8MM_IOMUXC_SAI3_RXC_UART2_DTE_RTS_B >>> 0x1D0 0x438 0x000 0x4 0x0 >>>#define >>> MX8MM_IOMUXC_SAI3_RXC_GPIO4_IO29 >>> 0x1D0 0x438 0x000 0x5 0x0 >>>#define >>> MX8MM_IOMUXC_SAI3_RXC_TPSMP_HTRANS1 >>> 0x1D0 0x438 0x000 0x7 0x0 >>>#define >>> MX8MM_IOMUXC_SAI3_RXD_SAI3_RX_DATA0 >>> 0x1D4 0x43C 0x000 0x0 0x0 >>>#define >>> MX8MM_IOMUXC_SAI3_RXD_GPT1_COMPARE1 >>> 0x1D4 0x43C 0x000 0x1 0x0 >>>#define >>> MX8MM_IOMUXC_SAI3_RXD_SAI5_RX_DATA0 >>> 0x1D4 0x43C 0x4D4 0x2 0x2 >>> +#define >>> MX8MM_IOMUXC_SAI3_RXD_UART2_DCE_RTS_B >>> 0x1D4 0x43C 0x4F8 0x4 0x3 >>> +#define >>> MX8MM_IOMUXC_SAI3_RXD_UART2_DCE_CTS_B >>> 0x1D4 0x43C 0x000 0x4 0x0 >>> +#define >>> MX8MM_IOMUXC_SAI3_RXD_UART2_DTE_RTS_B >>> 0x1D4 0x43C 0x000 0x4 0x0 >>> +#define >>> MX8MM_IOMUXC_SAI3_RXD_UART2_DTE_CTS_B >>> 0x1D4 0x43C 0x4F8 0x4 0x3 >>>#define >>> MX8MM_IOMUXC_SAI3_RXD_GPIO4_IO30 >>> 0x1D4 0x43C 0x000 0x5 0x0 >>>#define >>> MX8MM_IOMUXC_SAI3_RXD_TPSMP_HDATA0 >>> 0x1D4 0x43C 0x000 0x7 0x0 >>>#define >>> MX8MM_IOMUXC_SAI3_TXFS_SAI3_TX_SYNC >>> 0x1D8 0x440 0x000 0x0 0x0 >>>#define >>> MX8MM_IOMUXC_SAI3_TXFS_GPT1_CAPTURE2 >>> 0x1D8 0x440 0x000 0x1 0x0 >>>#define >>> MX8MM_IOMUXC_SAI3_TXFS_SAI5_RX_DATA1 >>> 0x1D8 0x440 0x4D8 0x2 0x2 >>> +#define >>> MX8MM_IOMUXC_SAI3_TXFS_UART2_DCE_RX >>> 0x1D8 0x440 0x000 0x4 0x0 >>> +#define >>> MX8MM_IOMUXC_SAI3_TXFS_UART2_DCE_TX >>> 0x1D8 0x440 0x4FC 0x4 0x2 >>> +#define >>> MX8MM_IOMUXC_SAI3_TX
[PATCH] imx8mm/mn: Add missing root clock entry for ARM core clock
From: Frieder Schrempf
The current implementation in arch/arm/mach-imx/cpu.c uses non-DM
code to retrieve the core clock frequency. As the root clock is not
listed we currently get:
CPU: Freescale i.MX8MMQ rev1.0 at 0 MHz
Fix this by adding the missing entry, which results in:
CPU: Freescale i.MX8MMQ rev1.0 at 1200 MHz
Signed-off-by: Frieder Schrempf
---
arch/arm/mach-imx/imx8m/clock_slice.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/mach-imx/imx8m/clock_slice.c
b/arch/arm/mach-imx/imx8m/clock_slice.c
index 31925ccaba..8b7a4dad65 100644
--- a/arch/arm/mach-imx/imx8m/clock_slice.c
+++ b/arch/arm/mach-imx/imx8m/clock_slice.c
@@ -477,6 +477,11 @@ static struct clk_root_map root_array[] = {
};
#elif defined(CONFIG_IMX8MM) || defined(CONFIG_IMX8MN)
static struct clk_root_map root_array[] = {
+ {ARM_A53_CLK_ROOT, CORE_CLOCK_SLICE, 0,
+{OSC_24M_CLK, ARM_PLL_CLK, SYSTEM_PLL2_500M_CLK,
+ SYSTEM_PLL2_1000M_CLK, SYSTEM_PLL1_800M_CLK,
+ SYSTEM_PLL1_400M_CLK, AUDIO_PLL1_CLK, SYSTEM_PLL3_CLK}
+ },
{NAND_USDHC_BUS_CLK_ROOT, BUS_CLOCK_SLICE, 2,
{OSC_24M_CLK, SYSTEM_PLL1_266M_CLK, SYSTEM_PLL1_800M_CLK,
SYSTEM_PLL2_200M_CLK, SYSTEM_PLL1_133M_CLK,
--
2.17.1
Re: [PATCH 1/2] menu: Make some parts of the menu available to other components
Hi Simon,
On 30.12.19 02:21, Simon Glass wrote:
> Hi Schrempf,
>
> On Tue, 10 Dec 2019 at 08:47, Schrempf Frieder
> wrote:
>>
>> From: Frieder Schrempf
>>
>> In order to iterate over the menu entries and match for a specific
>> name in the pxe boot, we need to properly export the needed structs
>> and functions.
>>
>> Signed-off-by: Frieder Schrempf
>> ---
>> common/menu.c | 31 +--
>> include/menu.h | 34 +-
>> 2 files changed, 34 insertions(+), 31 deletions(-)
>>
>> diff --git a/common/menu.c b/common/menu.c
>> index 7b66d199a9..82b03f17f7 100644
>> --- a/common/menu.c
>> +++ b/common/menu.c
>> @@ -12,36 +12,7 @@
>>
>> #include "menu.h"
>>
>> -/*
>> - * Internally, each item in a menu is represented by a struct menu_item.
>> - *
>> - * These items will be alloc'd and initialized by menu_item_add and
>> destroyed
>> - * by menu_item_destroy, and the consumer of the interface never sees that
>> - * this struct is used at all.
>> - */
>> -struct menu_item {
>> - char *key;
>> - void *data;
>> - struct list_head list;
>> -};
>>
>> -/*
>> - * The menu is composed of a list of items along with settings and callbacks
>> - * provided by the user. An incomplete definition of this struct is
>> available
>> - * in menu.h, but the full definition is here to prevent consumers from
>> - * relying on its contents.
>> - */
>> -struct menu {
>> - struct menu_item *default_item;
>> - int timeout;
>> - char *title;
>> - int prompt;
>> - void (*item_data_print)(void *);
>> - char *(*item_choice)(void *);
>> - void *item_choice_data;
>> - struct list_head items;
>> - int item_cnt;
>> -};
>>
>> /*
>>* An iterator function for menu items. callback will be called for each
>> item
>> @@ -51,7 +22,7 @@ struct menu {
>>* used for search type operations. It is also safe for callback to remove
>> the
>>* item from the list of items.
>>*/
>> -static inline void *menu_items_iter(struct menu *m,
>> +inline void *menu_items_iter(struct menu *m,
>> void *(*callback)(struct menu *, struct menu_item *, void
>> *),
>> void *extra)
>> {
>> diff --git a/include/menu.h b/include/menu.h
>> index 2d227c20bd..b3f8db87e4 100644
>> --- a/include/menu.h
>> +++ b/include/menu.h
>> @@ -6,8 +6,40 @@
>> #ifndef __MENU_H__
>> #define __MENU_H__
>>
>> -struct menu;
>> +/*
>> + * Internally, each item in a menu is represented by a struct menu_item.
>> + *
>> + * These items will be alloc'd and initialized by menu_item_add and
>> destroyed
>> + * by menu_item_destroy, and the consumer of the interface never sees that
>> + * this struct is used at all.
>> + */
>> +struct menu_item {
>> + char *key;
>> + void *data;
>> + struct list_head list;
>> +};
>> +
>> +/*
>> + * The menu is composed of a list of items along with settings and callbacks
>> + * provided by the user. An incomplete definition of this struct is
>> available
>> + * in menu.h, but the full definition is here to prevent consumers from
>> + * relying on its contents.
>
> This comment doesn't seem to be true anymore.
Right.
>
> Is it possible to add a function to get the info you need from the menu?
Unfortunately I didn't find a better solution, that doesn't expose the
menu structures. The problem is that menu and pxe are not separated
cleanly as the menu items contain references to struct pxe_label.
If I would add a function to iterate over the items to the menu code, I
would need to make struct pxe_label known to the menu code, which
doesn't seem nice, either.
Please let me know if you propose a different approach.
Thanks,
Frieder
>
>> + */
>> +struct menu {
>> + struct menu_item *default_item;
>> + int timeout;
>> + char *title;
>> + int prompt;
>> + void (*item_data_print)(void *);
>> + char *(*item_choice)(void *);
>> + void *item_choice_data;
>> + struct list_head items;
>> + int item_cnt;
>> +};
>>
>> +void *menu_items_iter(struct menu *m,
>> + void *(*callback)(struct menu *, struct menu_item *, void *),
>> + void *extra);
>> struct menu *menu_create(char *title, int timeout, int prompt,
>> void (*item_data_print)(void *),
>> char *(*item_choice)(void *),
>> --
>> 2.17.1
>
> Regards,
> Simon
>
Re: [PATCH 1/2] menu: Make some parts of the menu available to other components
On 05.02.20 14:44, Frieder Schrempf wrote:
> Hi Simon,
>
> On 30.12.19 02:21, Simon Glass wrote:
>> Hi Schrempf,
>>
>> On Tue, 10 Dec 2019 at 08:47, Schrempf Frieder
>> wrote:
>>>
>>> From: Frieder Schrempf
>>>
>>> In order to iterate over the menu entries and match for a specific
>>> name in the pxe boot, we need to properly export the needed structs
>>> and functions.
>>>
>>> Signed-off-by: Frieder Schrempf
>>> ---
>>> common/menu.c | 31 +--
>>> include/menu.h | 34 +-
>>> 2 files changed, 34 insertions(+), 31 deletions(-)
>>>
>>> diff --git a/common/menu.c b/common/menu.c
>>> index 7b66d199a9..82b03f17f7 100644
>>> --- a/common/menu.c
>>> +++ b/common/menu.c
>>> @@ -12,36 +12,7 @@
>>>
>>> #include "menu.h"
>>>
>>> -/*
>>> - * Internally, each item in a menu is represented by a struct
>>> menu_item.
>>> - *
>>> - * These items will be alloc'd and initialized by menu_item_add and
>>> destroyed
>>> - * by menu_item_destroy, and the consumer of the interface never
>>> sees that
>>> - * this struct is used at all.
>>> - */
>>> -struct menu_item {
>>> - char *key;
>>> - void *data;
>>> - struct list_head list;
>>> -};
>>>
>>> -/*
>>> - * The menu is composed of a list of items along with settings and
>>> callbacks
>>> - * provided by the user. An incomplete definition of this struct is
>>> available
>>> - * in menu.h, but the full definition is here to prevent consumers from
>>> - * relying on its contents.
>>> - */
>>> -struct menu {
>>> - struct menu_item *default_item;
>>> - int timeout;
>>> - char *title;
>>> - int prompt;
>>> - void (*item_data_print)(void *);
>>> - char *(*item_choice)(void *);
>>> - void *item_choice_data;
>>> - struct list_head items;
>>> - int item_cnt;
>>> -};
>>>
>>> /*
>>> * An iterator function for menu items. callback will be called for
>>> each item
>>> @@ -51,7 +22,7 @@ struct menu {
>>> * used for search type operations. It is also safe for callback to
>>> remove the
>>> * item from the list of items.
>>> */
>>> -static inline void *menu_items_iter(struct menu *m,
>>> +inline void *menu_items_iter(struct menu *m,
>>> void *(*callback)(struct menu *, struct menu_item *,
>>> void *),
>>> void *extra)
>>> {
>>> diff --git a/include/menu.h b/include/menu.h
>>> index 2d227c20bd..b3f8db87e4 100644
>>> --- a/include/menu.h
>>> +++ b/include/menu.h
>>> @@ -6,8 +6,40 @@
>>> #ifndef __MENU_H__
>>> #define __MENU_H__
>>>
>>> -struct menu;
>>> +/*
>>> + * Internally, each item in a menu is represented by a struct
>>> menu_item.
>>> + *
>>> + * These items will be alloc'd and initialized by menu_item_add and
>>> destroyed
>>> + * by menu_item_destroy, and the consumer of the interface never
>>> sees that
>>> + * this struct is used at all.
>>> + */
>>> +struct menu_item {
>>> + char *key;
>>> + void *data;
>>> + struct list_head list;
>>> +};
>>> +
>>> +/*
>>> + * The menu is composed of a list of items along with settings and
>>> callbacks
>>> + * provided by the user. An incomplete definition of this struct is
>>> available
>>> + * in menu.h, but the full definition is here to prevent consumers from
>>> + * relying on its contents.
>>
>> This comment doesn't seem to be true anymore.
>
> Right.
>
>>
>> Is it possible to add a function to get the info you need from the menu?
>
> Unfortunately I didn't find a better solution, that doesn't expose the
> menu structures. The problem is that menu and pxe are not separated
> cleanly as the menu items contain references to struct pxe_label.
Actually, on second thought, if I don't use the existing iterator
function in the menu code, I could keep all the menu code in menu.c and
expose just one additional function.
I'll send a v2 with this approach.
>
> If I would add a function to iterate over the items to the menu code, I
> would need to make struct pxe_label known to the menu code, which
> doesn't seem nice, either.
>
> Please let me know if you propose a different approach.
>
> Thanks,
> Frieder
>
>>
>>> + */
>>> +struct menu {
>>> + struct menu_item *default_item;
>>> + int timeout;
>>> + char *title;
>>> + int prompt;
>>> + void (*item_data_print)(void *);
>>> + char *(*item_choice)(void *);
>>> + void *item_choice_data;
>>> + struct list_head items;
>>> + int item_cnt;
>>> +};
>>>
>>> +void *menu_items_iter(struct menu *m,
>>> + void *(*callback)(struct menu *, struct menu_item *,
>>> void *),
>>> + void *extra);
>>> struct menu *menu_create(char *title, int timeout, int prompt,
>>> void (*item_data_print)(void *),
>>> char *(*item_choice)(void *),
>>> --
>>> 2.17.1
>>
>> Regards,
>> Simon
>>
[PATCH v2 2/2] pxe: Get default selection from board type if label matches
From: Frieder Schrempf
In order to auto-select an option from the pxe boot menu, that
matches the detected board, we check the board model string in the
devicetree and set the default menu selection, if it matches the
label of the menu entry and there is no default selection already
set.
This is useful in combination with SPL that loads a FIT image with
U-Boot and multiple DTBs. SPL can detect the board and choose the
matching configuration in the FIT by using
board_fit_config_name_match().
Signed-off-by: Frieder Schrempf
---
Changes in v2:
* Don't use internal structs of menu, but instead call
menu_set_default_by_item_data_match() that does the iteration work.
---
cmd/pxe_utils.c | 47 +++
1 file changed, 47 insertions(+)
diff --git a/cmd/pxe_utils.c b/cmd/pxe_utils.c
index 53af04d7dc..62a1ee310d 100644
--- a/cmd/pxe_utils.c
+++ b/cmd/pxe_utils.c
@@ -1220,6 +1220,46 @@ struct pxe_menu *parse_pxefile(cmd_tbl_t *cmdtp,
unsigned long menucfg)
return cfg;
}
+#ifdef CONFIG_OF_CONTROL
+int pxe_match_menu_label_with_str(void *data, void *str)
+{
+ struct pxe_label *label;
+
+ if (!data || !str)
+ return 0;
+
+ label = (struct pxe_label *)data;
+
+ if (strcmp(label->name, str) == 0)
+ return 1;
+
+ return 0;
+}
+
+int pxe_runtime_select_menu_default(struct menu *m)
+{
+ DECLARE_GLOBAL_DATA_PTR;
+ const char *model;
+ char *key;
+ int ret;
+
+ model = fdt_getprop(gd->fdt_blob, 0, "model", NULL);
+
+ if (!model)
+ return 0;
+
+ ret = menu_set_default_by_item_data_match(m,
+ pxe_match_menu_label_with_str, (void *)model, &key);
+ if (ret)
+ return ret;
+
+ printf("Menu entry %s fits detected board. " \
+ "Use as default selection...\n", key);
+
+ return 0;
+}
+#endif
+
/*
* Converts a pxe_menu struct into a menu struct for use with U-Boot's generic
* menu code.
@@ -1258,6 +1298,8 @@ static struct menu *pxe_menu_to_menu(struct pxe_menu *cfg)
/*
* After we've created items for each label in the menu, set the
* menu's default label if one was specified.
+* If OF_CONTROL is enabled and we don't have a default specified,
+* we try to use an entry that matches the board/model name as default.
*/
if (default_num) {
err = menu_default_set(m, default_num);
@@ -1269,6 +1311,11 @@ static struct menu *pxe_menu_to_menu(struct pxe_menu
*cfg)
printf("Missing default: %s\n", cfg->default_label);
}
+#ifdef CONFIG_OF_CONTROL
+ } else if (pxe_runtime_select_menu_default(m)) {
+ menu_destroy(m);
+ return NULL;
+#endif
}
return m;
--
2.17.1
[PATCH v2 1/2] menu: Add a function to set the default by matching the item data
From: Frieder Schrempf
In order to make it possible to auto select a default entry by
matching the data of the menu entries by an external matching
function, we add some helpers and expose the
menu_set_default_by_item_data_match() function.
Signed-off-by: Frieder Schrempf
---
Changes in v2:
* Keep the menu structs private and instead only expose one additional
function, that sets the default by calling an external matching
function on each entry.
* Change the title and commit message to reflect the changes.
---
common/menu.c | 40
include/menu.h | 3 +++
2 files changed, 43 insertions(+)
diff --git a/common/menu.c b/common/menu.c
index 7b66d199a9..3833b8a237 100644
--- a/common/menu.c
+++ b/common/menu.c
@@ -160,6 +160,46 @@ static inline struct menu_item *menu_item_by_key(struct
menu *m,
return menu_items_iter(m, menu_item_key_match, item_key);
}
+/*
+ * Find the first matching item, if any exists by calling a matching function
+ * on the items data field.
+ */
+static inline struct menu_item *menu_item_by_matching_fn(struct menu *m,
+ int match(void *, void *), void * extra)
+{
+ struct list_head *pos, *n;
+ struct menu_item *item;
+ int ret;
+
+ list_for_each_safe(pos, n, &m->items) {
+ item = list_entry(pos, struct menu_item, list);
+ if (item->key) {
+ ret = match(item->data, extra);
+ if (ret == 1)
+ return item;
+ }
+ }
+
+ return NULL;
+}
+
+/*
+ * Select the menus default entry based on matching the data field of the menu
+ * items by calling a matching function.
+ */
+int menu_set_default_by_item_data_match(struct menu *m,
+ int match(void *, void *), void *extra, char **key)
+{
+ struct menu_item *item = menu_item_by_matching_fn(m, match, extra);
+
+ if (!item)
+ return -ENOENT;
+
+ *key = item->key;
+ m->default_item = item;
+ return 0;
+}
+
/*
* Set *choice to point to the default item's data, if any default item was
* set, and returns 1. If no default item was set, returns -ENOENT.
diff --git a/include/menu.h b/include/menu.h
index 2d227c20bd..0a8b41a905 100644
--- a/include/menu.h
+++ b/include/menu.h
@@ -18,6 +18,9 @@ int menu_item_add(struct menu *m, char *item_key, void
*item_data);
int menu_destroy(struct menu *m);
void menu_display_statusline(struct menu *m);
int menu_default_choice(struct menu *m, void **choice);
+int menu_set_default_by_item_data_match(struct menu *m,
+ int match(void *, void *), void *extra,
+ char **key);
/**
* menu_show() Show a boot menu
--
2.17.1
[PATCH v3 2/2] pxe: Get default selection from board type if label matches
From: Frieder Schrempf
In order to auto-select an option from the pxe boot menu, that
matches the detected board, we check the board model string in the
devicetree and set the default menu selection, if it matches the
label of the menu entry and there is no default selection already
set.
This is useful in combination with SPL that loads a FIT image with
U-Boot and multiple DTBs. SPL can detect the board and choose the
matching configuration in the FIT by using
board_fit_config_name_match().
Signed-off-by: Frieder Schrempf
---
Changes in v3:
* Get rid of #ifdef by using IS_ENABLED() in else branch.
Changes in v2:
* Don't use internal structs of menu, but instead call
menu_set_default_by_item_data_match() that does the iteration work.
---
cmd/pxe_utils.c | 46 ++
1 file changed, 46 insertions(+)
diff --git a/cmd/pxe_utils.c b/cmd/pxe_utils.c
index 53af04d7dc..253df468af 100644
--- a/cmd/pxe_utils.c
+++ b/cmd/pxe_utils.c
@@ -1220,6 +1220,46 @@ struct pxe_menu *parse_pxefile(cmd_tbl_t *cmdtp,
unsigned long menucfg)
return cfg;
}
+#ifdef CONFIG_OF_CONTROL
+int pxe_match_menu_label_with_str(void *data, void *str)
+{
+ struct pxe_label *label;
+
+ if (!data || !str)
+ return 0;
+
+ label = (struct pxe_label *)data;
+
+ if (strcmp(label->name, str) == 0)
+ return 1;
+
+ return 0;
+}
+
+int pxe_runtime_select_menu_default(struct menu *m)
+{
+ DECLARE_GLOBAL_DATA_PTR;
+ const char *model;
+ char *key;
+ int ret;
+
+ model = fdt_getprop(gd->fdt_blob, 0, "model", NULL);
+
+ if (!model)
+ return 0;
+
+ ret = menu_set_default_by_item_data_match(m,
+ pxe_match_menu_label_with_str, (void *)model, &key);
+ if (ret)
+ return ret;
+
+ printf("Menu entry %s fits detected board. " \
+ "Use as default selection...\n", key);
+
+ return 0;
+}
+#endif
+
/*
* Converts a pxe_menu struct into a menu struct for use with U-Boot's generic
* menu code.
@@ -1258,6 +1298,8 @@ static struct menu *pxe_menu_to_menu(struct pxe_menu *cfg)
/*
* After we've created items for each label in the menu, set the
* menu's default label if one was specified.
+* If OF_CONTROL is enabled and we don't have a default specified,
+* we try to use an entry that matches the board/model name as default.
*/
if (default_num) {
err = menu_default_set(m, default_num);
@@ -1269,6 +1311,10 @@ static struct menu *pxe_menu_to_menu(struct pxe_menu
*cfg)
printf("Missing default: %s\n", cfg->default_label);
}
+ } else if (IS_ENABLED(CONFIG_OF_CONTROL) &&
+ pxe_runtime_select_menu_default(m)) {
+ menu_destroy(m);
+ return NULL;
}
return m;
--
2.17.1
[PATCH v3 1/2] menu: Add a function to set the default by matching the item data
From: Frieder Schrempf
In order to make it possible to auto select a default entry by
matching the data of the menu entries by an external matching
function, we add some helpers and expose the
menu_set_default_by_item_data_match() function.
Signed-off-by: Frieder Schrempf
---
Changes in v3:
* Add a full function comment to describe menu_set_default_by_item_data_match().
Changes in v2:
* Keep the menu structs private and instead only expose one additional
function, that sets the default by calling an external matching
function on each entry.
* Change the title and commit message to reflect the changes.
---
common/menu.c | 54 ++
include/menu.h | 3 +++
2 files changed, 57 insertions(+)
diff --git a/common/menu.c b/common/menu.c
index 7b66d199a9..6110b2396c 100644
--- a/common/menu.c
+++ b/common/menu.c
@@ -160,6 +160,60 @@ static inline struct menu_item *menu_item_by_key(struct
menu *m,
return menu_items_iter(m, menu_item_key_match, item_key);
}
+/*
+ * Find the first matching item, if any exists by calling a matching function
+ * on the items data field.
+ */
+static inline struct menu_item *menu_item_by_matching_fn(struct menu *m,
+ int match(void *, void *), void * extra)
+{
+ struct list_head *pos, *n;
+ struct menu_item *item;
+ int ret;
+
+ list_for_each_safe(pos, n, &m->items) {
+ item = list_entry(pos, struct menu_item, list);
+ if (item->key) {
+ ret = match(item->data, extra);
+ if (ret == 1)
+ return item;
+ }
+ }
+
+ return NULL;
+}
+
+/*
+ * menu_set_default_by_item_data_match() - sets a menu default option by
calling
+ * a matching function on each of the menu items data field.
+ *
+ * m - Points to a menu created by menu_create().
+ *
+ * match - Points to a function that is passed a pointer to the items data
field
+ * and a pointer to extra data to compare with. It should return 1 on a
+ * match.
+ *
+ * extra - Points to some data that is passed as a second parameter to the
+ * matching function.
+ *
+ * key - Points to a char array that will be set to hold the key of the matched
+ * menu item.
+ *
+ * Returns 0 if successful, or -ENOENT if no matching item was found.
+ */
+int menu_set_default_by_item_data_match(struct menu *m,
+ int match(void *, void *), void *extra, char **key)
+{
+ struct menu_item *item = menu_item_by_matching_fn(m, match, extra);
+
+ if (!item)
+ return -ENOENT;
+
+ *key = item->key;
+ m->default_item = item;
+ return 0;
+}
+
/*
* Set *choice to point to the default item's data, if any default item was
* set, and returns 1. If no default item was set, returns -ENOENT.
diff --git a/include/menu.h b/include/menu.h
index 2d227c20bd..0a8b41a905 100644
--- a/include/menu.h
+++ b/include/menu.h
@@ -18,6 +18,9 @@ int menu_item_add(struct menu *m, char *item_key, void
*item_data);
int menu_destroy(struct menu *m);
void menu_display_statusline(struct menu *m);
int menu_default_choice(struct menu *m, void **choice);
+int menu_set_default_by_item_data_match(struct menu *m,
+ int match(void *, void *), void *extra,
+ char **key);
/**
* menu_show() Show a boot menu
--
2.17.1
Re: [PATCH v3 2/2] pxe: Get default selection from board type if label matches
On 06.02.20 18:46, Simon Glass wrote:
> Hi Schrempf,
>
> On Thu, 6 Feb 2020 at 02:09, Schrempf Frieder
> wrote:
>>
>> From: Frieder Schrempf
>>
>> In order to auto-select an option from the pxe boot menu, that
>> matches the detected board, we check the board model string in the
>> devicetree and set the default menu selection, if it matches the
>> label of the menu entry and there is no default selection already
>> set.
>>
>> This is useful in combination with SPL that loads a FIT image with
>> U-Boot and multiple DTBs. SPL can detect the board and choose the
>> matching configuration in the FIT by using
>> board_fit_config_name_match().
>>
>> Signed-off-by: Frieder Schrempf
>> ---
>> Changes in v3:
>> * Get rid of #ifdef by using IS_ENABLED() in else branch.
>>
>> Changes in v2:
>> * Don't use internal structs of menu, but instead call
>>menu_set_default_by_item_data_match() that does the iteration work.
>> ---
>> cmd/pxe_utils.c | 46 ++
>> 1 file changed, 46 insertions(+)
>>
>> diff --git a/cmd/pxe_utils.c b/cmd/pxe_utils.c
>> index 53af04d7dc..253df468af 100644
>> --- a/cmd/pxe_utils.c
>> +++ b/cmd/pxe_utils.c
>> @@ -1220,6 +1220,46 @@ struct pxe_menu *parse_pxefile(cmd_tbl_t *cmdtp,
>> unsigned long menucfg)
>> return cfg;
>> }
>>
>> +#ifdef CONFIG_OF_CONTROL
>
> I think you need to remove this #ifdef, otherwise you'll get a build
> error on boards without OF_CONTROL enabled.
Right, I forgot about this.
>
>> +int pxe_match_menu_label_with_str(void *data, void *str)
>> +{
>> + struct pxe_label *label;
>> +
>> + if (!data || !str)
>> + return 0;
>> +
>> + label = (struct pxe_label *)data;
>> +
>> + if (strcmp(label->name, str) == 0)
>> + return 1;
>> +
>> + return 0;
>> +}
>> +
>> +int pxe_runtime_select_menu_default(struct menu *m)
>> +{
>> + DECLARE_GLOBAL_DATA_PTR;
>> + const char *model;
>> + char *key;
>> + int ret;
>> +
>> + model = fdt_getprop(gd->fdt_blob, 0, "model", NULL);
>> +
>> + if (!model)
>> + return 0;
>> +
>> + ret = menu_set_default_by_item_data_match(m,
>> + pxe_match_menu_label_with_str, (void *)model, &key);
>> + if (ret)
>> + return ret;
>> +
>> + printf("Menu entry %s fits detected board. " \
>> + "Use as default selection...\n", key);
>> +
>> + return 0;
>> +}
>> +#endif
>> +
>> /*
>>* Converts a pxe_menu struct into a menu struct for use with U-Boot's
>> generic
>>* menu code.
>> @@ -1258,6 +1298,8 @@ static struct menu *pxe_menu_to_menu(struct pxe_menu
>> *cfg)
>> /*
>> * After we've created items for each label in the menu, set the
>> * menu's default label if one was specified.
>> +* If OF_CONTROL is enabled and we don't have a default specified,
>> +* we try to use an entry that matches the board/model name as
>> default.
>> */
>> if (default_num) {
>> err = menu_default_set(m, default_num);
>> @@ -1269,6 +1311,10 @@ static struct menu *pxe_menu_to_menu(struct pxe_menu
>> *cfg)
>>
>> printf("Missing default: %s\n", cfg->default_label);
>> }
>> + } else if (IS_ENABLED(CONFIG_OF_CONTROL) &&
>> + pxe_runtime_select_menu_default(m)) {
>> + menu_destroy(m);
>> + return NULL;
>> }
>>
>> return m;
>> --
>> 2.17.1
>
> Regards,
> Simon
>
Re: [PATCH v3 1/2] menu: Add a function to set the default by matching the item data
On 06.02.20 18:46, Simon Glass wrote:
> Hi Schrempf,
>
> On Thu, 6 Feb 2020 at 02:09, Schrempf Frieder
> wrote:
>>
>> From: Frieder Schrempf
>>
>> In order to make it possible to auto select a default entry by
>> matching the data of the menu entries by an external matching
>> function, we add some helpers and expose the
>> menu_set_default_by_item_data_match() function.
>>
>> Signed-off-by: Frieder Schrempf
>> ---
>> Changes in v3:
>> * Add a full function comment to describe
>> menu_set_default_by_item_data_match().
>>
>> Changes in v2:
>> * Keep the menu structs private and instead only expose one additional
>>function, that sets the default by calling an external matching
>>function on each entry.
>> * Change the title and commit message to reflect the changes.
>> ---
>> common/menu.c | 54 ++
>> include/menu.h | 3 +++
>> 2 files changed, 57 insertions(+)
>>
>> diff --git a/common/menu.c b/common/menu.c
>> index 7b66d199a9..6110b2396c 100644
>> --- a/common/menu.c
>> +++ b/common/menu.c
>> @@ -160,6 +160,60 @@ static inline struct menu_item *menu_item_by_key(struct
>> menu *m,
>> return menu_items_iter(m, menu_item_key_match, item_key);
>> }
>>
>> +/*
>> + * Find the first matching item, if any exists by calling a matching
>> function
>> + * on the items data field.
>> + */
>> +static inline struct menu_item *menu_item_by_matching_fn(struct menu *m,
>> + int match(void *, void *), void * extra)
>> +{
>> + struct list_head *pos, *n;
>> + struct menu_item *item;
>> + int ret;
>> +
>> + list_for_each_safe(pos, n, &m->items) {
>> + item = list_entry(pos, struct menu_item, list);
>> + if (item->key) {
>> + ret = match(item->data, extra);
>> + if (ret == 1)
>> + return item;
>> + }
>> + }
>> +
>> + return NULL;
>> +}
>> +
>> +/*
>> + * menu_set_default_by_item_data_match() - sets a menu default option by
>> calling
>> + * a matching function on each of the menu items data field.
>> + *
>> + * m - Points to a menu created by menu_create().
>> + *
>> + * match - Points to a function that is passed a pointer to the items data
>> field
>> + * and a pointer to extra data to compare with. It should return 1
>> on a
>> + * match.
>> + *
>> + * extra - Points to some data that is passed as a second parameter to the
>> + * matching function.
>> + *
>> + * key - Points to a char array that will be set to hold the key of the
>> matched
>> + * menu item.
>> + *
>> + * Returns 0 if successful, or -ENOENT if no matching item was found.
>
> Can you please update this to the correct comment style - e.g. see
> cmd_process_error() in command.h for example. Also since this is an
> exported function the comment should go in the header file.
Sure. Thanks for pointing me to the correct style and for reviewing in
general!
>
> Regards,
> SImon
>
[PATCH v4 2/2] pxe: Get default selection from board type if label matches
From: Frieder Schrempf
In order to auto-select an option from the pxe boot menu, that
matches the detected board, we check the board model string in the
devicetree and set the default menu selection, if it matches the
label of the menu entry and there is no default selection already
set.
This is useful in combination with SPL that loads a FIT image with
U-Boot and multiple DTBs. SPL can detect the board and choose the
matching configuration in the FIT by using
board_fit_config_name_match().
Signed-off-by: Frieder Schrempf
---
Changes in v4:
* Remove #ifdef that would cause build failures in case of OF_CONTROL being
disabled.
Changes in v3:
* Get rid of #ifdef by using IS_ENABLED() in else branch.
Changes in v2:
* Don't use internal structs of menu, but instead call
---
cmd/pxe_utils.c | 44
1 file changed, 44 insertions(+)
diff --git a/cmd/pxe_utils.c b/cmd/pxe_utils.c
index 53af04d7dc..9a6c67c93a 100644
--- a/cmd/pxe_utils.c
+++ b/cmd/pxe_utils.c
@@ -1220,6 +1220,44 @@ struct pxe_menu *parse_pxefile(cmd_tbl_t *cmdtp,
unsigned long menucfg)
return cfg;
}
+int pxe_match_menu_label_with_str(void *data, void *str)
+{
+ struct pxe_label *label;
+
+ if (!data || !str)
+ return 0;
+
+ label = (struct pxe_label *)data;
+
+ if (strcmp(label->name, str) == 0)
+ return 1;
+
+ return 0;
+}
+
+int pxe_runtime_select_menu_default(struct menu *m)
+{
+ DECLARE_GLOBAL_DATA_PTR;
+ const char *model;
+ char *key;
+ int ret;
+
+ model = fdt_getprop(gd->fdt_blob, 0, "model", NULL);
+
+ if (!model)
+ return 0;
+
+ ret = menu_set_default_by_item_data_match(m,
+ pxe_match_menu_label_with_str, (void *)model, &key);
+ if (ret)
+ return ret;
+
+ printf("Menu entry %s fits detected board. " \
+ "Use as default selection...\n", key);
+
+ return 0;
+}
+
/*
* Converts a pxe_menu struct into a menu struct for use with U-Boot's generic
* menu code.
@@ -1258,6 +1296,8 @@ static struct menu *pxe_menu_to_menu(struct pxe_menu *cfg)
/*
* After we've created items for each label in the menu, set the
* menu's default label if one was specified.
+* If OF_CONTROL is enabled and we don't have a default specified,
+* we try to use an entry that matches the board/model name as default.
*/
if (default_num) {
err = menu_default_set(m, default_num);
@@ -1269,6 +1309,10 @@ static struct menu *pxe_menu_to_menu(struct pxe_menu
*cfg)
printf("Missing default: %s\n", cfg->default_label);
}
+ } else if (IS_ENABLED(CONFIG_OF_CONTROL) &&
+ pxe_runtime_select_menu_default(m)) {
+ menu_destroy(m);
+ return NULL;
}
return m;
--
2.17.1
[PATCH v4 1/2] menu: Add a function to set the default by matching the item data
From: Frieder Schrempf
In order to make it possible to auto select a default entry by
matching the data of the menu entries by an external matching
function, we add some helpers and expose the
menu_set_default_by_item_data_match() function.
Signed-off-by: Frieder Schrempf
---
Changes in v4:
* Use the proper style for the function description
* Move the comment for the function description to the header file
Changes in v3:
* Add a full function comment to describe menu_set_default_by_item_data_match().
Changes in v2:
* Keep the menu structs private and instead only expose one additional
function, that sets the default by calling an external matching
function on each entry.
* Change the title and commit message to reflect the changes.
---
common/menu.c | 40
include/menu.h | 19 +++
2 files changed, 59 insertions(+)
diff --git a/common/menu.c b/common/menu.c
index 7b66d199a9..e16a0a4a50 100644
--- a/common/menu.c
+++ b/common/menu.c
@@ -160,6 +160,46 @@ static inline struct menu_item *menu_item_by_key(struct
menu *m,
return menu_items_iter(m, menu_item_key_match, item_key);
}
+/*
+ * Find the first matching item, if any exists by calling a matching function
+ * on the items data field.
+ */
+static inline struct menu_item *menu_item_by_matching_fn(struct menu *m,
+ int match(void *, void *), void * extra)
+{
+ struct list_head *pos, *n;
+ struct menu_item *item;
+ int ret;
+
+ list_for_each_safe(pos, n, &m->items) {
+ item = list_entry(pos, struct menu_item, list);
+ if (item->key) {
+ ret = match(item->data, extra);
+ if (ret == 1)
+ return item;
+ }
+ }
+
+ return NULL;
+}
+
+/*
+ * Sets a menu default option by calling a matching function on each of the
+ * menu items data field.
+ */
+int menu_set_default_by_item_data_match(struct menu *m,
+ int match(void *, void *), void *extra, char **key)
+{
+ struct menu_item *item = menu_item_by_matching_fn(m, match, extra);
+
+ if (!item)
+ return -ENOENT;
+
+ *key = item->key;
+ m->default_item = item;
+ return 0;
+}
+
/*
* Set *choice to point to the default item's data, if any default item was
* set, and returns 1. If no default item was set, returns -ENOENT.
diff --git a/include/menu.h b/include/menu.h
index 2d227c20bd..96c9fcac03 100644
--- a/include/menu.h
+++ b/include/menu.h
@@ -19,6 +19,25 @@ int menu_destroy(struct menu *m);
void menu_display_statusline(struct menu *m);
int menu_default_choice(struct menu *m, void **choice);
+/**
+ * menu_set_default_by_item_data_match() - - sets a menu default option by
+ * calling a matching function on each of the menu items data field.
+ *
+ * @m: Points to a menu created by menu_create().
+ * @match: Points to a function that is passed a pointer to the items data
field
+ * and a pointer to extra data to compare with. It should return 1 on a
+ * match.
+ * @extra: Points to some data that is passed as a second parameter to the
+ * matching function.
+ * @key: Points to a char array that will be set to hold the key of the matched
+ * menu item.
+ * @return 0 if a matching item was found,
+ *-ENOENT if no matching item was found
+ */
+int menu_set_default_by_item_data_match(struct menu *m,
+ int match(void *, void *), void *extra,
+ char **key);
+
/**
* menu_show() Show a boot menu
*
--
2.17.1
Re: [PATCH v4 1/2] menu: Add a function to set the default by matching the item data
On 12.02.20 11:37, Schrempf Frieder wrote:
> From: Frieder Schrempf
>
> In order to make it possible to auto select a default entry by
> matching the data of the menu entries by an external matching
> function, we add some helpers and expose the
> menu_set_default_by_item_data_match() function.
>
> Signed-off-by: Frieder Schrempf
> ---
> Changes in v4:
> * Use the proper style for the function description
> * Move the comment for the function description to the header file
>
> Changes in v3:
> * Add a full function comment to describe
> menu_set_default_by_item_data_match().
>
> Changes in v2:
> * Keep the menu structs private and instead only expose one additional
>function, that sets the default by calling an external matching
>function on each entry.
> * Change the title and commit message to reflect the changes.
> ---
> common/menu.c | 40
> include/menu.h | 19 +++
> 2 files changed, 59 insertions(+)
>
> diff --git a/common/menu.c b/common/menu.c
> index 7b66d199a9..e16a0a4a50 100644
> --- a/common/menu.c
> +++ b/common/menu.c
> @@ -160,6 +160,46 @@ static inline struct menu_item *menu_item_by_key(struct
> menu *m,
> return menu_items_iter(m, menu_item_key_match, item_key);
> }
>
> +/*
> + * Find the first matching item, if any exists by calling a matching function
> + * on the items data field.
> + */
> +static inline struct menu_item *menu_item_by_matching_fn(struct menu *m,
> + int match(void *, void *), void * extra)
> +{
> + struct list_head *pos, *n;
> + struct menu_item *item;
> + int ret;
> +
> + list_for_each_safe(pos, n, &m->items) {
> + item = list_entry(pos, struct menu_item, list);
> + if (item->key) {
> + ret = match(item->data, extra);
> + if (ret == 1)
> + return item;
> + }
> + }
> +
> + return NULL;
> +}
> +
> +/*
> + * Sets a menu default option by calling a matching function on each of the
> + * menu items data field.
> + */
> +int menu_set_default_by_item_data_match(struct menu *m,
> + int match(void *, void *), void *extra, char **key)
> +{
> + struct menu_item *item = menu_item_by_matching_fn(m, match, extra);
> +
> + if (!item)
> + return -ENOENT;
> +
> + *key = item->key;
> + m->default_item = item;
> + return 0;
> +}
> +
> /*
>* Set *choice to point to the default item's data, if any default item was
>* set, and returns 1. If no default item was set, returns -ENOENT.
> diff --git a/include/menu.h b/include/menu.h
> index 2d227c20bd..96c9fcac03 100644
> --- a/include/menu.h
> +++ b/include/menu.h
> @@ -19,6 +19,25 @@ int menu_destroy(struct menu *m);
> void menu_display_statusline(struct menu *m);
> int menu_default_choice(struct menu *m, void **choice);
>
> +/**
> + * menu_set_default_by_item_data_match() - - sets a menu default option by
I just saw, that there's a superfluous hyphen here. Sorry, will fix it
if a new version is requested.
> + * calling a matching function on each of the menu items data field.
> + *
> + * @m: Points to a menu created by menu_create().
> + * @match: Points to a function that is passed a pointer to the items data
> field
> + * and a pointer to extra data to compare with. It should return 1
> on a
> + * match.
> + * @extra: Points to some data that is passed as a second parameter to the
> + * matching function.
> + * @key: Points to a char array that will be set to hold the key of the
> matched
> + * menu item.
> + * @return 0 if a matching item was found,
> + * -ENOENT if no matching item was found
> + */
> +int menu_set_default_by_item_data_match(struct menu *m,
> + int match(void *, void *), void *extra,
> + char **key);
> +
> /**
>* menu_show() Show a boot menu
>*
>
Re: [PATCH] net: pfe_eth: Use spi_flash_read API to access flash memory
On 11.12.19 12:53, Kuldeep Singh wrote:
> Current PFE firmware access spi-nor memory directly. New spi-mem
> framework does not support direct memory access. So, let's use
> spi_flash_read API to access memory instead of directly using it.
>
> Signed-off-by: Kuldeep Singh
> ---
> drivers/net/pfe_eth/pfe_firmware.c | 44 +-
> include/configs/ls1012a_common.h | 5 +++-
> 2 files changed, 47 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/pfe_eth/pfe_firmware.c
> b/drivers/net/pfe_eth/pfe_firmware.c
> index e4563f192b..61d1b96305 100644
> --- a/drivers/net/pfe_eth/pfe_firmware.c
> +++ b/drivers/net/pfe_eth/pfe_firmware.c
> @@ -12,13 +12,14 @@
>
> #include
> #include
> +#include
> #ifdef CONFIG_CHAIN_OF_TRUST
> #include
> #endif
>
> #define PFE_FIRMWARE_FIT_CNF_NAME "config@1"
>
> -static const void *pfe_fit_addr = (void *)CONFIG_SYS_LS_PFE_FW_ADDR;
> +static const void *pfe_fit_addr;
>
> /*
>* PFE elf firmware loader.
> @@ -159,6 +160,43 @@ static int pfe_fit_check(void)
> return ret;
> }
>
> +int pfe_spi_flash_init(void)
> +{
> + struct spi_flash *pfe_flash;
> + int ret = 0;
> + void *addr = malloc(CONFIG_SYS_QE_FMAN_FW_LENGTH);
> +
> +#ifdef CONFIG_DM_SPI_FLASH
> + struct udevice *new;
> +
> + /* speed and mode will be read from DT */
> + ret = spi_flash_probe_bus_cs(CONFIG_ENV_SPI_BUS,
> + CONFIG_ENV_SPI_CS, 0, 0, &new);
> +
> + pfe_flash = dev_get_uclass_priv(new);
> +#else
> + pfe_flash = spi_flash_probe(CONFIG_ENV_SPI_BUS,
> + CONFIG_ENV_SPI_CS,
> + CONFIG_ENV_SPI_MAX_HZ,
> + CONFIG_ENV_SPI_MODE);
> +#endif
> + if (!pfe_flash) {
> + printf("SF: probe for pfe ucode failed\n");
I think you should return some error code in this case. Currently ret
could still be 0 at this point.
> + } else {
> + ret = spi_flash_read(pfe_flash,
> + CONFIG_SYS_LS_PFE_FW_ADDR,
> + CONFIG_SYS_QE_FMAN_FW_LENGTH,
> + addr);
> + if (ret)
> + printf("SF: read for ucode failed\n");
> +
> + pfe_fit_addr = addr;
> + spi_flash_free(pfe_flash);
> + }
> +
> + return ret;
> +}
> +
> /*
>* PFE firmware initialization.
>* Loads different firmware files from FIT image.
> @@ -183,6 +221,10 @@ int pfe_firmware_init(void)
> int ret = 0;
> int fw_count;
>
> + ret = pfe_spi_flash_init();
> + if (ret)
> + goto err;
> +
> ret = pfe_fit_check();
> if (ret)
> goto err;
> diff --git a/include/configs/ls1012a_common.h
> b/include/configs/ls1012a_common.h
> index 2579e2fb37..cbc5bff21c 100644
> --- a/include/configs/ls1012a_common.h
> +++ b/include/configs/ls1012a_common.h
> @@ -36,9 +36,12 @@
> /* Size of malloc() pool */
> #define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + 128 * 1024)
>
> +/* PFE */
> +#define CONFIG_SYS_FMAN_FW_ADDR 0x400d
> +#define CONFIG_SYS_QE_FMAN_FW_LENGTH 0x1
> +
> /*SPI device */
> #if defined(CONFIG_QSPI_BOOT) || defined(CONFIG_TFABOOT)
> -#define CONFIG_SYS_FMAN_FW_ADDR 0x400d
> #define CONFIG_SPI_FLASH_SPANSION
> #define CONFIG_FSL_SPI_INTERFACE
> #define CONFIG_SF_DATAFLASH
>
Re: [PATCH] configs: ls1012ardb: Enable CONFIG_SYS_RELOC_GD_ENV_ADDR
On 12.12.19 10:16, Kuldeep Singh wrote:
> Enable the config for ls1012ardb as the entry got missed earlier.
>
> Fixes: 8d8ee47e03 ("env: Add CONFIG_SYS_RELOC_GD_ENV_ADDR symbol")
> Signed-off-by: Kuldeep Singh
As far as I know this should have been in v2020.01 as it fixes a
regression introduced in this release cycle. Unfortunately it seems like
it was missed.
> ---
> configs/ls1012ardb_qspi_SECURE_BOOT_defconfig | 1 +
> configs/ls1012ardb_qspi_defconfig | 1 +
> configs/ls1012ardb_tfa_SECURE_BOOT_defconfig | 1 +
> configs/ls1012ardb_tfa_defconfig | 1 +
> 4 files changed, 4 insertions(+)
>
> diff --git a/configs/ls1012ardb_qspi_SECURE_BOOT_defconfig
> b/configs/ls1012ardb_qspi_SECURE_BOOT_defconfig
> index 9989f7b..aa21720 100644
> --- a/configs/ls1012ardb_qspi_SECURE_BOOT_defconfig
> +++ b/configs/ls1012ardb_qspi_SECURE_BOOT_defconfig
> @@ -31,6 +31,7 @@ CONFIG_CMD_USB=y
> CONFIG_CMD_CACHE=y
> CONFIG_OF_CONTROL=y
> CONFIG_DEFAULT_DEVICE_TREE="fsl-ls1012a-rdb"
> +CONFIG_SYS_RELOC_GD_ENV_ADDR=y
> CONFIG_NET_RANDOM_ETHADDR=y
> CONFIG_DM=y
> CONFIG_SATA_CEVA=y
> diff --git a/configs/ls1012ardb_qspi_defconfig
> b/configs/ls1012ardb_qspi_defconfig
> index 80ca9bd..2c027f9 100644
> --- a/configs/ls1012ardb_qspi_defconfig
> +++ b/configs/ls1012ardb_qspi_defconfig
> @@ -33,6 +33,7 @@ CONFIG_OF_CONTROL=y
> CONFIG_DEFAULT_DEVICE_TREE="fsl-ls1012a-rdb"
> CONFIG_ENV_IS_IN_SPI_FLASH=y
> CONFIG_ENV_ADDR=0x4030
> +CONFIG_SYS_RELOC_GD_ENV_ADDR=y
> CONFIG_NET_RANDOM_ETHADDR=y
> CONFIG_DM=y
> CONFIG_SATA_CEVA=y
> diff --git a/configs/ls1012ardb_tfa_SECURE_BOOT_defconfig
> b/configs/ls1012ardb_tfa_SECURE_BOOT_defconfig
> index 8eb71fc..69ff76b 100644
> --- a/configs/ls1012ardb_tfa_SECURE_BOOT_defconfig
> +++ b/configs/ls1012ardb_tfa_SECURE_BOOT_defconfig
> @@ -31,6 +31,7 @@ CONFIG_CMD_USB=y
> CONFIG_CMD_CACHE=y
> CONFIG_OF_CONTROL=y
> CONFIG_DEFAULT_DEVICE_TREE="fsl-ls1012a-rdb"
> +CONFIG_SYS_RELOC_GD_ENV_ADDR=y
> CONFIG_NET_RANDOM_ETHADDR=y
> CONFIG_DM=y
> CONFIG_SATA_CEVA=y
> diff --git a/configs/ls1012ardb_tfa_defconfig
> b/configs/ls1012ardb_tfa_defconfig
> index 1cc358c..30dcd7d 100644
> --- a/configs/ls1012ardb_tfa_defconfig
> +++ b/configs/ls1012ardb_tfa_defconfig
> @@ -33,6 +33,7 @@ CONFIG_OF_CONTROL=y
> CONFIG_DEFAULT_DEVICE_TREE="fsl-ls1012a-rdb"
> CONFIG_ENV_IS_IN_SPI_FLASH=y
> CONFIG_ENV_ADDR=0x4050
> +CONFIG_SYS_RELOC_GD_ENV_ADDR=y
> CONFIG_NET_RANDOM_ETHADDR=y
> CONFIG_DM=y
> CONFIG_SATA_CEVA=y
>
Re: [Patch v3 1/7] spi: Transform the FSL QuadSPI driver to use the SPI MEM API
Hi Kuldeep, On 06.01.20 11:56, Kuldeep Singh wrote: > Hi Jagan and Vignesh, > > Could you please review this driver. Actually, I don't want to miss this > merge window. > Moreover, Frieder's suggestions are already incorporated and this version of > driver is almost identical to linux version apart from the changes already > mentioned in commit message. > You may also take a look at Linux driver[1] as well. As the v3 is close to my original version and the Linux version, I'm ok with it. I can't review my own patch but from my point of once the two dependencies are merged, this could be merged too. As for the other (cleanup) patches in this series, have you tested them with buildman to make sure the config changes are ok? Thanks, Frieder > > P.S: Jagan, I was not sure which email you use frequently. So, I tagged both > of them. > > Thanks > Kuldeep > > [1] https://elixir.bootlin.com/linux/latest/source/drivers/spi/spi-fsl-qspi.c > >> -Original Message- >> From: Kuldeep Singh >> Sent: Friday, December 20, 2019 3:31 PM >> To: u-boot@lists.denx.de >> Cc: Priyanka Jain ; frieder.schre...@kontron.de; >> ja...@amarulasolutions.com; Ashish Kumar ; >> Kuldeep Singh ; Ashish Kumar >> >> Subject: [Patch v3 1/7] spi: Transform the FSL QuadSPI driver to use the SPI >> MEM API >> >> To support the SPI MEM API, instead of modifying the existing U-Boot >> driver, this patch adds a port of the existing Linux driver. >> This also has the advantage that porting changes and fixes from Linux >> will be easier. >> Porting of driver left most of the functions unchanged while few of the >> changes are: >> -Remove lock(mutexes) and irq handler as uboot is a single core execution. >> -Remove invalid masterid as it was required for multicore execution. >> -Remove clock support as the changing spi speed is not supported in >> uboot and nor in linux. >> >> Currently tested on LS1088ARDB, LS1012ARDB, LS1046ARDB, LS1046AFRWY, >> LS1043AQDS, LS1021ATWR, LS2088ARDB. >> >> Signed-off-by: Frieder Schrempf >> Signed-off-by: Ashish Kumar >> Signed-off-by: Kuldeep Singh >> Reviewed-by: Stefan Roese >> Tested-by: Stefan Roese >> --- >> v3: >> -reword commit message. >> -rebase on top. >> v2: >> -Revert to 1k size. >> -Add support for setting TDH bits correctly. >> >> drivers/spi/fsl_qspi.c | 1572 +++- >> drivers/spi/fsl_qspi.h | 145 >> 2 files changed, 603 insertions(+), 1114 deletions(-) >> delete mode 100644 drivers/spi/fsl_qspi.h >> >> diff --git a/drivers/spi/fsl_qspi.c b/drivers/spi/fsl_qspi.c >> index 8e2a09df36..980633e850 100644 >> --- a/drivers/spi/fsl_qspi.c >> +++ b/drivers/spi/fsl_qspi.c >> @@ -1,1142 +1,776 @@ >> // SPDX-License-Identifier: GPL-2.0+ >> + >> /* >> - * Copyright 2013-2015 Freescale Semiconductor, Inc. >> + * Freescale QuadSPI driver. >> + * >> + * Copyright (C) 2013 Freescale Semiconductor, Inc. >> + * Copyright (C) 2018 Bootlin >> + * Copyright (C) 2018 exceet electronics GmbH >> + * Copyright (C) 2018 Kontron Electronics GmbH >> + * Copyright 2019-2020 NXP >> + * >> + * This driver is a ported version of Linux Freescale QSPI driver taken from >> + * v5.5-rc1 tag having following information. >>* >> - * Freescale Quad Serial Peripheral Interface (QSPI) driver >> + * Transition to SPI MEM interface: >> + * Authors: >> + * Boris Brezillon >> + * Frieder Schrempf >> + * Yogesh Gaur >> + * Suresh Gupta >> + * >> + * Based on the original fsl-quadspi.c spi-nor driver. >> + * Transition to spi-mem in spi-fsl-qspi.c >>*/ >> >> #include >> -#include >> -#include >> #include >> -#include >> -#include >> #include >> -#include >> -#include >> -#include >> -#include "fsl_qspi.h" >> +#include >> +#include >> +#include >> +#include >> >> DECLARE_GLOBAL_DATA_PTR; >> >> -#define OFFSET_BITS_MASKGENMASK(23, 0) >> - >> -#define FLASH_STATUS_WEL0x02 >> - >> -/* SEQID */ >> -#define SEQID_WREN 1 >> -#define SEQID_FAST_READ 2 >> -#define SEQID_RDSR 3 >> -#define SEQID_SE4 >> -#define SEQID_CHIP_ERASE5 >> -#define SEQID_PP6 >> -#define SEQID_RDID 7 >> -#define SEQID_BE_4K 8 >> -#ifdef CONFIG_SPI_FLASH_BAR >> -#define SEQID_BRRD 9 >> -#define SEQID_BRWR 10 >> -#define SEQID_RDEAR 11 >> -#define SEQID_WREAR 12 >> -#endif >> -#define SEQID_WRAR 13 >> -#define SEQID_RDAR 14 >> - >> -/* QSPI CMD */ >> -#define QSPI_CMD_PP 0x02/* Page program (up to 256 bytes) */ >> -#define QSPI_CMD_RDSR 0x05/* Read status register */ >> -#define QSPI_CMD_WREN 0x06/* Write enable */ >> -#define QSPI_CMD_FAST_READ 0x0b/* Read data bytes (high >> frequency) */ >> -#define QSPI_CMD_BE_4K 0x20/* 4K erase */ >> -#define QSPI_CMD_CHIP_ERASE 0xc7/* Erase whole flash chip */ >> -#define QSPI_CMD_SE 0xd8/* Sector eras
Re: [U-Boot] [PATCH v5 1/5] spl: dm: disable SPI DM flash for non-DM SPL
Hi Xiaowei,
On 24.12.19 04:01, Xiaowei Bao wrote:
>
>
>> -Original Message-
>> From: Xiaowei Bao
>> Sent: 2019年10月23日 11:26
>> To: Schrempf Frieder ; Lukasz Majewski
>> ; u-boot@lists.denx.de
>> Subject: RE: [U-Boot] [PATCH v5 1/5] spl: dm: disable SPI DM flash for
>> non-DM SPL
>>
>>
>>
>>> -Original Message-
>>> From: Schrempf Frieder
>>> Sent: 2019年10月22日 21:03
>>> To: Lukasz Majewski ; Xiaowei Bao
>>> ; u-boot@lists.denx.de
>>> Subject: Re: [U-Boot] [PATCH v5 1/5] spl: dm: disable SPI DM flash for
>>> non-DM SPL
>>>
>>> Hi Lukasz, hi Xiaowei,
>>>
>>> On 22.10.19 14:20, Lukasz Majewski wrote:
>>>> Hi Xiaowei,
>>>>
>>>>> Hi Lukasz,
>>>>>
>>>>> My patches depends on your patches
>>>>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fp
>>>>> at
>>>>>
>>>
>> chwork.ozlabs.org%2Fproject%2Fuboot%2Flist%2F%3Fseries%3D129069&am
>>> p;d
>>>>>
>>>
>> ata=02%7C01%7Cxiaowei.bao%40nxp.com%7Cd125df94364d44ecb97508d7
>>>
>> 56f03935%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6370734
>>>
>> 62083854046&sdata=H%2FbP2%2BlrtoktSegAIkwWImNoNJSGxN4wzTb
>>> wAe1oMk0%3D&reserved=0, do you have plan to update it? I saw that
>>> the status is "changes required", any comments?
>>>>
>>>> There was some discussion regarding this work with Frieder (CC'ed),
>>>> who has prepared similar patch set.
>>>>
>>>> Some portions of this series:
>>>> spi: Split CONFIG_DM_SPI* to CONFIG_{SPL_TPL}DM_SPI*
>>>>
>>>> has been applied.
>>>>
>>>> However, I don't know if Frieder is going (or already has) to
>>>> prepare new version of this patch set.
>>>
>>> I have sent one part of the necessary changes: [1].
>>> The latest version of the whole conversion can be found here: [2].
>>> I need to test these changes with buildman before I send the remaining
>> parts.
>>> I hope I will find some time to do this in the next days.
>>>
>>
>>
>> Thanks Lukasz and Schrempf, got it.
>
> Hi Frieder,
>
> Do you complete the test of changes, I have some patches depend on your
> patches,
> Thanks a lot.
Sorry, the CONFIG_SPI_FLASH_MTD is merged, but the other remaining
patches for CONFIG_DM_SPI_FLASH, etc. are not.
The last time I tried to get them ready I once again got caught in an
endless loop of fixing Kconfig issues and testing.
If you need some of the fixes, you could try adding them to your own
patchset and test and resend them.
Regards,
Frieder
>
> Best regards
> Xiaowei
>
>
>>
>>> Regards,
>>> Frieder
>>>
>>> [1]
>>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc
>>> h
>> work.ozlabs.org%2Fpatch%2F1162265%2F&data=02%7C01%7Cxiaowei.
>>>
>> bao%40nxp.com%7Cd125df94364d44ecb97508d756f03935%7C686ea1d3bc2
>>>
>> b4c6fa92cd99c5c301635%7C0%7C0%7C637073462083854046&sdata=
>>>
>> 80bOgepTBhXP%2FpDRMBAeNezJV4akrOoH04%2F8A%2BUjMOo%3D&
>>> reserved=0
>>> [2]
>>>
>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.
>>>
>> com%2Ffschrempf%2Fu-boot%2Fcommits%2Fspi_flash_kconfig_cleanup&am
>>>
>> p;data=02%7C01%7Cxiaowei.bao%40nxp.com%7Cd125df94364d44ecb97508
>>>
>> d756f03935%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63707
>>>
>> 3462083854046&sdata=f%2BZDhMDbg8Hx%2F3ISB1D10yI2OT0HpPTu6
>>> ZANAlGS5bU%3D&reserved=0
>>
>>
>>
>
Re: [Patch v2] net: pfe_eth: Use spi_flash_read API to access flash memory
On 08.01.20 05:50, Kuldeep Singh wrote:
> Current PFE firmware access spi-nor memory directly. New spi-mem
> framework does not support direct memory access. So, let's use
> spi_flash_read API to access memory instead of directly using it.
>
> Signed-off-by: Kuldeep Singh
> ---
> v2:
> Add return error code
> Some changes in displayed log
>
> drivers/net/pfe_eth/pfe_firmware.c | 45
> +-
> include/configs/ls1012a_common.h | 5 -
> 2 files changed, 48 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/pfe_eth/pfe_firmware.c
> b/drivers/net/pfe_eth/pfe_firmware.c
> index e4563f1..3aa9a08 100644
> --- a/drivers/net/pfe_eth/pfe_firmware.c
> +++ b/drivers/net/pfe_eth/pfe_firmware.c
> @@ -12,13 +12,14 @@
>
> #include
> #include
> +#include
> #ifdef CONFIG_CHAIN_OF_TRUST
> #include
> #endif
>
> #define PFE_FIRMWARE_FIT_CNF_NAME "config@1"
>
> -static const void *pfe_fit_addr = (void *)CONFIG_SYS_LS_PFE_FW_ADDR;
> +static const void *pfe_fit_addr;
>
> /*
>* PFE elf firmware loader.
> @@ -159,6 +160,44 @@ static int pfe_fit_check(void)
> return ret;
> }
>
> +int pfe_spi_flash_init(void)
> +{
> + struct spi_flash *pfe_flash;
> + int ret = 0;
> + void *addr = malloc(CONFIG_SYS_QE_FMAN_FW_LENGTH);
> +
> +#ifdef CONFIG_DM_SPI_FLASH
> + struct udevice *new;
> +
> + /* speed and mode will be read from DT */
> + ret = spi_flash_probe_bus_cs(CONFIG_ENV_SPI_BUS,
> + CONFIG_ENV_SPI_CS, 0, 0, &new);
> +
> + pfe_flash = dev_get_uclass_priv(new);
> +#else
> + pfe_flash = spi_flash_probe(CONFIG_ENV_SPI_BUS,
> + CONFIG_ENV_SPI_CS,
> + CONFIG_ENV_SPI_MAX_HZ,
> + CONFIG_ENV_SPI_MODE);
> +#endif
> + if (!pfe_flash) {
> + printf("SF: probe for pfe failed\n");
> + return ret;
No. For the non-DM case ret is still 0, so you will return 0, even if
spi_flash_probe() failed, which is not correct.
> + }
> +
> + ret = spi_flash_read(pfe_flash,
> + CONFIG_SYS_LS_PFE_FW_ADDR,
> + CONFIG_SYS_QE_FMAN_FW_LENGTH,
> + addr);
> + if (ret)
> + printf("SF: read for pfe failed\n");
> +
> + pfe_fit_addr = addr;
> + spi_flash_free(pfe_flash);
> +
> + return ret;
> +}
> +
> /*
>* PFE firmware initialization.
>* Loads different firmware files from FIT image.
> @@ -183,6 +222,10 @@ int pfe_firmware_init(void)
> int ret = 0;
> int fw_count;
>
> + ret = pfe_spi_flash_init();
> + if (ret)
> + goto err;
> +
> ret = pfe_fit_check();
> if (ret)
> goto err;
> diff --git a/include/configs/ls1012a_common.h
> b/include/configs/ls1012a_common.h
> index 2579e2f..cbc5bff 100644
> --- a/include/configs/ls1012a_common.h
> +++ b/include/configs/ls1012a_common.h
> @@ -36,9 +36,12 @@
> /* Size of malloc() pool */
> #define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + 128 * 1024)
>
> +/* PFE */
> +#define CONFIG_SYS_FMAN_FW_ADDR 0x400d
> +#define CONFIG_SYS_QE_FMAN_FW_LENGTH 0x1
> +
> /*SPI device */
> #if defined(CONFIG_QSPI_BOOT) || defined(CONFIG_TFABOOT)
> -#define CONFIG_SYS_FMAN_FW_ADDR 0x400d
> #define CONFIG_SPI_FLASH_SPANSION
> #define CONFIG_FSL_SPI_INTERFACE
> #define CONFIG_SF_DATAFLASH
>
Re: [Patch v3] net: pfe_eth: Use spi_flash_read API to access flash memory
On 08.01.20 10:08, Kuldeep Singh wrote:
> Current PFE firmware access spi-nor memory directly. New spi-mem
> framework does not support direct memory access. So, let's use
> spi_flash_read API to access memory instead of directly using it.
>
> Signed-off-by: Kuldeep Singh
> ---
> v3:
> -Replace ret with 0 if flash probe fails
> v2:
> -Add return error code
> -Some changes in displayed log
>
> drivers/net/pfe_eth/pfe_firmware.c | 45
> +-
> include/configs/ls1012a_common.h | 5 -
> 2 files changed, 48 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/pfe_eth/pfe_firmware.c
> b/drivers/net/pfe_eth/pfe_firmware.c
> index e4563f1..6145f4e 100644
> --- a/drivers/net/pfe_eth/pfe_firmware.c
> +++ b/drivers/net/pfe_eth/pfe_firmware.c
> @@ -12,13 +12,14 @@
>
> #include
> #include
> +#include
> #ifdef CONFIG_CHAIN_OF_TRUST
> #include
> #endif
>
> #define PFE_FIRMWARE_FIT_CNF_NAME "config@1"
>
> -static const void *pfe_fit_addr = (void *)CONFIG_SYS_LS_PFE_FW_ADDR;
> +static const void *pfe_fit_addr;
>
> /*
>* PFE elf firmware loader.
> @@ -159,6 +160,44 @@ static int pfe_fit_check(void)
> return ret;
> }
>
> +int pfe_spi_flash_init(void)
> +{
> + struct spi_flash *pfe_flash;
> + int ret = 0;
> + void *addr = malloc(CONFIG_SYS_QE_FMAN_FW_LENGTH);
> +
> +#ifdef CONFIG_DM_SPI_FLASH
> + struct udevice *new;
> +
> + /* speed and mode will be read from DT */
> + ret = spi_flash_probe_bus_cs(CONFIG_ENV_SPI_BUS,
> + CONFIG_ENV_SPI_CS, 0, 0, &new);
> +
> + pfe_flash = dev_get_uclass_priv(new);
> +#else
> + pfe_flash = spi_flash_probe(CONFIG_ENV_SPI_BUS,
> + CONFIG_ENV_SPI_CS,
> + CONFIG_ENV_SPI_MAX_HZ,
> + CONFIG_ENV_SPI_MODE);
> +#endif
> + if (!pfe_flash) {
> + printf("SF: probe for pfe failed\n");
> + return 0;
No again. It seems like you're not getting what I'm trying to tell you,
so it would be better to just ask back instead of posting new versions.
pfe_spi_flash_init() should return an error code in case the probe of
the SPI flash failed. An error code is a negative value like for example
-ENODEV to report that the device is not available to the calling function.
> + }
> +
> + ret = spi_flash_read(pfe_flash,
> + CONFIG_SYS_LS_PFE_FW_ADDR,
> + CONFIG_SYS_QE_FMAN_FW_LENGTH,
> + addr);
> + if (ret)
> + printf("SF: read for pfe failed\n");
> +
> + pfe_fit_addr = addr;
> + spi_flash_free(pfe_flash);
> +
> + return ret;
> +}
> +
> /*
>* PFE firmware initialization.
>* Loads different firmware files from FIT image.
> @@ -183,6 +222,10 @@ int pfe_firmware_init(void)
> int ret = 0;
> int fw_count;
>
> + ret = pfe_spi_flash_init();
> + if (ret)
> + goto err;
> +
> ret = pfe_fit_check();
> if (ret)
> goto err;
> diff --git a/include/configs/ls1012a_common.h
> b/include/configs/ls1012a_common.h
> index 2579e2f..cbc5bff 100644
> --- a/include/configs/ls1012a_common.h
> +++ b/include/configs/ls1012a_common.h
> @@ -36,9 +36,12 @@
> /* Size of malloc() pool */
> #define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + 128 * 1024)
>
> +/* PFE */
> +#define CONFIG_SYS_FMAN_FW_ADDR 0x400d
> +#define CONFIG_SYS_QE_FMAN_FW_LENGTH 0x1
> +
> /*SPI device */
> #if defined(CONFIG_QSPI_BOOT) || defined(CONFIG_TFABOOT)
> -#define CONFIG_SYS_FMAN_FW_ADDR 0x400d
> #define CONFIG_SPI_FLASH_SPANSION
> #define CONFIG_FSL_SPI_INTERFACE
> #define CONFIG_SF_DATAFLASH
>
Re: [EXT] Re: [Patch v3] net: pfe_eth: Use spi_flash_read API to access flash memory
On 10.01.20 11:58, Kuldeep Singh wrote:
> Hi Frieder,
>
>> -Original Message-----
>> From: Schrempf Frieder
>> Sent: Wednesday, January 8, 2020 2:52 PM
>> To: Kuldeep Singh ; u-boot@lists.denx.de
>> Cc: Joe Hershberger ; Thomas Hebb
>> ; Patrick Delaunay
>> Subject: [EXT] Re: [Patch v3] net: pfe_eth: Use spi_flash_read API to access
>> flash memory
>>
>> Caution: EXT Email
>>
>> On 08.01.20 10:08, Kuldeep Singh wrote:
>>> Current PFE firmware access spi-nor memory directly. New spi-mem
>>> framework does not support direct memory access. So, let's use
>>> spi_flash_read API to access memory instead of directly using it.
>>>
>>> Signed-off-by: Kuldeep Singh
>>> ---
>>> v3:
>>> -Replace ret with 0 if flash probe fails
>>> v2:
>>> -Add return error code
>>> -Some changes in displayed log
>>>
>>>drivers/net/pfe_eth/pfe_firmware.c | 45
>> +-
>>>include/configs/ls1012a_common.h | 5 -
>>>2 files changed, 48 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/net/pfe_eth/pfe_firmware.c
>>> b/drivers/net/pfe_eth/pfe_firmware.c
>>> index e4563f1..6145f4e 100644
>>> --- a/drivers/net/pfe_eth/pfe_firmware.c
>>> +++ b/drivers/net/pfe_eth/pfe_firmware.c
>>> @@ -12,13 +12,14 @@
>>>
>>>#include
>>>#include
>>> +#include
>>>#ifdef CONFIG_CHAIN_OF_TRUST
>>>#include
>>>#endif
>>>
>>>#define PFE_FIRMWARE_FIT_CNF_NAME "config@1"
>>>
>>> -static const void *pfe_fit_addr = (void *)CONFIG_SYS_LS_PFE_FW_ADDR;
>>> +static const void *pfe_fit_addr;
>>>
>>>/*
>>> * PFE elf firmware loader.
>>> @@ -159,6 +160,44 @@ static int pfe_fit_check(void)
>>>return ret;
>>>}
>>>
>>> +int pfe_spi_flash_init(void)
>>> +{
>>> + struct spi_flash *pfe_flash;
>>> + int ret = 0;
>>> + void *addr = malloc(CONFIG_SYS_QE_FMAN_FW_LENGTH);
>>> +
>>> +#ifdef CONFIG_DM_SPI_FLASH
>>> + struct udevice *new;
>>> +
>>> + /* speed and mode will be read from DT */
>>> + ret = spi_flash_probe_bus_cs(CONFIG_ENV_SPI_BUS,
>>> + CONFIG_ENV_SPI_CS, 0, 0, &new);
>>> +
>>> + pfe_flash = dev_get_uclass_priv(new); #else
>>> + pfe_flash = spi_flash_probe(CONFIG_ENV_SPI_BUS,
>>> + CONFIG_ENV_SPI_CS,
>>> + CONFIG_ENV_SPI_MAX_HZ,
>>> + CONFIG_ENV_SPI_MODE); #endif
>>> + if (!pfe_flash) {
>>> + printf("SF: probe for pfe failed\n");
>>> + return 0;
>>
>> No again. It seems like you're not getting what I'm trying to tell you, so it
>> would be better to just ask back instead of posting new versions.
>>
>> pfe_spi_flash_init() should return an error code in case the probe of the SPI
>> flash failed. An error code is a negative value like for example -ENODEV to
>> report that the device is not available to the calling function.
>
> Thanks Frieder for providing the info.
> I will return -ENODEV here instead of 0.
>
>>
>>> + }
>>> +
>>> + ret = spi_flash_read(pfe_flash,
>>> + CONFIG_SYS_LS_PFE_FW_ADDR,
>>> + CONFIG_SYS_QE_FMAN_FW_LENGTH,
>>> + addr);
>>> + if (ret)
>>> + printf("SF: read for pfe failed\n");
>
> I think -EIO should also be returned here as pfe functionality will fail if
> data is not read.
> Please confirm the same if error code is correct/required. I will update this
> in next version.
No, I don't think it's a good idea to return an error code here. You
already get an error code back from spi_flash_read() if it fails and you
pass this error to the caller at the end of the function, which should
be sufficient.
Also returning here would require to add a call to spi_flash_free() first.
>
> Thanks
> Kuldeep
>
>>> +
>>> + pfe_fit_addr = addr;
>>> + spi_flash_free(pfe_flash);
>>> +
>>> + return ret;
>>> +}
>>> +
>>>/*
>>> * PFE firmware initialization.
>>> * Loads different firmware fi
Re: [Patch v4] net: pfe_eth: Use spi_flash_read API to access flash memory
On 13.01.20 10:23, Kuldeep Singh wrote:
> Current PFE firmware access spi-nor memory directly. New spi-mem
> framework does not support direct memory access. So, let's use
> spi_flash_read API to access memory instead of directly using it.
>
> Signed-off-by: Kuldeep Singh
Reviewed-by: Frieder Schrempf
> ---
> v4:
> -Return -ENODEV if flash probe fails
> v3:
> -Replace ret with 0 if flash probe fails
> v2:
> -Add return error code
> -Changes in displayed error log
>
> drivers/net/pfe_eth/pfe_firmware.c | 45
> +-
> include/configs/ls1012a_common.h | 5 -
> 2 files changed, 48 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/pfe_eth/pfe_firmware.c
> b/drivers/net/pfe_eth/pfe_firmware.c
> index e4563f1..27ae8ae 100644
> --- a/drivers/net/pfe_eth/pfe_firmware.c
> +++ b/drivers/net/pfe_eth/pfe_firmware.c
> @@ -12,13 +12,14 @@
>
> #include
> #include
> +#include
> #ifdef CONFIG_CHAIN_OF_TRUST
> #include
> #endif
>
> #define PFE_FIRMWARE_FIT_CNF_NAME "config@1"
>
> -static const void *pfe_fit_addr = (void *)CONFIG_SYS_LS_PFE_FW_ADDR;
> +static const void *pfe_fit_addr;
>
> /*
>* PFE elf firmware loader.
> @@ -159,6 +160,44 @@ static int pfe_fit_check(void)
> return ret;
> }
>
> +int pfe_spi_flash_init(void)
> +{
> + struct spi_flash *pfe_flash;
> + int ret = 0;
> + void *addr = malloc(CONFIG_SYS_QE_FMAN_FW_LENGTH);
> +
> +#ifdef CONFIG_DM_SPI_FLASH
> + struct udevice *new;
> +
> + /* speed and mode will be read from DT */
> + ret = spi_flash_probe_bus_cs(CONFIG_ENV_SPI_BUS,
> + CONFIG_ENV_SPI_CS, 0, 0, &new);
> +
> + pfe_flash = dev_get_uclass_priv(new);
> +#else
> + pfe_flash = spi_flash_probe(CONFIG_ENV_SPI_BUS,
> + CONFIG_ENV_SPI_CS,
> + CONFIG_ENV_SPI_MAX_HZ,
> + CONFIG_ENV_SPI_MODE);
> +#endif
> + if (!pfe_flash) {
> + printf("SF: probe for pfe failed\n");
> + return -ENODEV;
> + }
> +
> + ret = spi_flash_read(pfe_flash,
> + CONFIG_SYS_LS_PFE_FW_ADDR,
> + CONFIG_SYS_QE_FMAN_FW_LENGTH,
> + addr);
> + if (ret)
> + printf("SF: read for pfe failed\n");
> +
> + pfe_fit_addr = addr;
> + spi_flash_free(pfe_flash);
> +
> + return ret;
> +}
> +
> /*
>* PFE firmware initialization.
>* Loads different firmware files from FIT image.
> @@ -183,6 +222,10 @@ int pfe_firmware_init(void)
> int ret = 0;
> int fw_count;
>
> + ret = pfe_spi_flash_init();
> + if (ret)
> + goto err;
> +
> ret = pfe_fit_check();
> if (ret)
> goto err;
> diff --git a/include/configs/ls1012a_common.h
> b/include/configs/ls1012a_common.h
> index 2579e2f..cbc5bff 100644
> --- a/include/configs/ls1012a_common.h
> +++ b/include/configs/ls1012a_common.h
> @@ -36,9 +36,12 @@
> /* Size of malloc() pool */
> #define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + 128 * 1024)
>
> +/* PFE */
> +#define CONFIG_SYS_FMAN_FW_ADDR 0x400d
> +#define CONFIG_SYS_QE_FMAN_FW_LENGTH 0x1
> +
> /*SPI device */
> #if defined(CONFIG_QSPI_BOOT) || defined(CONFIG_TFABOOT)
> -#define CONFIG_SYS_FMAN_FW_ADDR 0x400d
> #define CONFIG_SPI_FLASH_SPANSION
> #define CONFIG_FSL_SPI_INTERFACE
> #define CONFIG_SF_DATAFLASH
>
Re: [U-Boot] [PATCH] driver/spi: fsl_qspi: Remove non-DM stuff
Hi, On 07.09.18 06:19, Ashish Kumar wrote: > Convert fsl_qspi.c to complete DM mode. > > Signed-off-by: Ashish Kumar > Tested-by: Rajat Srivastava > Tested-by: Ye Li > --- > > Tested on LS1088ARDB(arm64). > Tested on LS1021ATWR(arm32) by Rajat > Tested on i.mx6 and i.mx7 by Ye Li > > Depends on patch series: > http://patchwork.ozlabs.org/patch/935858/ > http://patchwork.ozlabs.org/patch/935860/ This patch breaks the build if you enable CONFIG_SPL_SPI_SUPPORT. I guess that SPL does not use DM for SPI. How is the SPI support for SPL supposed to work? Will it use DM in the future? Thanks, Frieder ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 13/28] mtd: ensure MTD is compiled when ENV_IS_IN_FLASH is selected
On 05.12.18 15:32, Miquel Raynal wrote: > Hi Wolfgang, > > Wolfgang Denk wrote on Wed, 05 Dec 2018 13:06:10 +0100: > >> Dear Miquel, >> >> In message <20181204235714.11805-14-miquel.ray...@bootlin.com> you wrote: >>> MTD support must be enabled when the environment is in NOR. >> >> Naked-by: Wolfgang Denk >> >> Environment in NOR must not, I repeat: must not ever depend on MTD! >> >> For more than 19 years we have been using environment in NOR flash >> without the need for MTD support, which makes a lot of sense >> especially on smaller systems where resources are low and MTD is an >> expensive, but not really needed feature. >> >> It is not acceptable to create a dependency that costs so much. > > I took a rather small configuration: stm32f429-discovery_defconfig > which uses CONFIG_MTD_NOR_FLASH. Without CONFIG_MTD, u-boot.bin is > 209416 bytes. With CONFIG_MTD, u-boot.bin is 214540 bytes. This is an > additional 5124 bytes which represent about 2% of the entire size. > > I am talking about U-Boot only, there is a CONFIG_SPL_MTD_SUPPORT > option that must be enabled to compile MTD in the SPL so the change > I propose do not enlarge the SPL. > > Today, there are multiple boards having more than one type of MTD > device (eg. raw NAND and SPI-NOR). In this case you need to compile two > commands which interface only with the subsystem they have been written > for. We propose to kill this approach and instead use an 'mtd' command > which shares the same code for all MTD devices: less duplication, more > users, and in the end, a reduced size. And I am not event talking about > all the code that has been added over the years to "avoid using MTD" > which enlarges the binary as well. > > The current situation is unmaintainable. Any change in U-Boot under the > drivers/mtd/ directory results in hours of debugging to fix broken > dependencies and crappy configurations. It took me one week to port the > SPI-mem/SPI-NAND layers (which rely on MTD) and to have a working 'mtd' > command. It took me and Boris almost 4 weeks to fix the fallouts. Now, > either we keep U-Boot MTD subsystem maintainable and in sync as much as > possible with Linux to continue to benefit from > evolutions/drivers/fixes at the cost of a little overhead, or we > continue in the current path, with the results we know. I'm not really involved in U-Boot development, but watching the recent MTD changes and also from a user/board supplier point of view, I strongly support Miquèl's and Boris' approach. Moving towards a unified MTD layer to replace all the historic solutions is definitely the right thing to do. Miquèl already mentioned the reasons in detail and saving a few bytes of binary size in my opinion does not justify enough for going without all the advantages. Regards, Frieder ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Issue with USB mass storage (thumb drives)
Hello, I'm using U-Boot on a custom i.MX6 board and I'm having problems while reading (large) files from USB thumb drives. I wouldn't really mind if this only happened with some specific USB device, but the problem occurs with 3 out of 4 tested thumb drives while loading a 100M test file. The devices that work seem to be rather old ones. The same issue is also reported here: https://community.freescale.com/thread/377911 I can reproduce this behaviour with u-boot-imx v2014.04 and with mainline u-boot v2015.10 and v2016.01. Can someone tell me if this is a known issue? What could be the reason for this and how can I get this working? Thanks! U-Boot 2016.01 (Feb 02 2016 - 10:31:32 +0100) CPU: Freescale i.MX6SOLO rev1.3 at 792MHz CPU: Industrial temperature grade (-40C to 105C) at 31C Reset cause: POR Board: MX6EXCEET DRAM: 1 GiB NAND: 256 MiB MMC: FSL_SDHC: 0, FSL_SDHC: 1 SF: Detected EN25Q80 with page size 256 Bytes, erase size 4 KiB, total 1 MiB No panel detected: default to Hannstar-XGA Display: Hannstar-XGA (1024x768) In:serial Out: serial Err: serial Net: Found Micrel KS8051/KS8081 PHY FEC Hit any key to stop autoboot: 0 => usb start starting USB... USB0: Port not available. USB1: USB EHCI 1.00 scanning bus 1 for devices... 2 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found scanning usb for ethernet devices... 0 Ethernet Device(s) found => fatload usb 0 0x1800 test.file reading test.file EHCI timed out on TD - token=0xac008d80 EHCI timed out on TD - token=0x80008d80 EHCI timed out on TD - token=0x80008d80 EHCI timed out on TD - token=0x80008d80 EHCI timed out on TD - token=0x128d80 EHCI timed out on TD - token=0x80008d80 EHCI timed out on TD - token=0x80008d80 EHCI timed out on TD - token=0x80008d80 EHCI timed out on TD - token=0x801f8c80 EHCI timed out on TD - token=0x80008d80 EHCI timed out on TD - token=0x80008d80 EHCI timed out on TD - token=0x80008d80 EHCI timed out on TD - token=0x801f8c80 EHCI timed out on TD - token=0x80008d80 EHCI timed out on TD - token=0x80008d80 EHCI timed out on TD - token=0x80008d80 EHCI timed out on TD - token=0x801f8c80 EHCI timed out on TD - token=0x80008d80 EHCI timed out on TD - token=0x80008d80 EHCI timed out on TD - token=0x80008d80 EHCI timed out on TD - token=0x801f8c80 EHCI timed out on TD - token=0x80008d80 EHCI timed out on TD - token=0x80008d80 EHCI timed out on TD - token=0x80008d80 Error reading cluster ** Unable to read file test.file ** ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Issue with USB mass storage (thumb drives)
On 02.02.2016 17:39, Marek Vasut wrote: > On Tuesday, February 02, 2016 at 05:28:42 PM, Fabio Estevam wrote: >> Adding Marek in case he has any ideas. >> >> On Tue, Feb 2, 2016 at 8:35 AM, Schrempf Frieder >> >> wrote: >>> Hello, >>> >>> I'm using U-Boot on a custom i.MX6 board and I'm having problems while >>> reading (large) files from USB thumb drives. >>> I wouldn't really mind if this only happened with some specific USB >>> device, but the problem occurs with 3 out of 4 tested thumb drives while >>> loading a 100M test file. >>> The devices that work seem to be rather old ones. >>> >>> The same issue is also reported here: >>> https://community.freescale.com/thread/377911 >>> >>> I can reproduce this behaviour with u-boot-imx v2014.04 and with >>> mainline u-boot v2015.10 and v2016.01. >>> >>> Can someone tell me if this is a known issue? >>> What could be the reason for this and how can I get this working? >>> >>> Thanks! >>> >>> >>> U-Boot 2016.01 (Feb 02 2016 - 10:31:32 +0100) >>> >>> CPU: Freescale i.MX6SOLO rev1.3 at 792MHz >>> CPU: Industrial temperature grade (-40C to 105C) at 31C >>> Reset cause: POR >>> Board: MX6EXCEET >>> DRAM: 1 GiB >>> NAND: 256 MiB >>> MMC: FSL_SDHC: 0, FSL_SDHC: 1 >>> SF: Detected EN25Q80 with page size 256 Bytes, erase size 4 KiB, total 1 >>> MiB No panel detected: default to Hannstar-XGA >>> Display: Hannstar-XGA (1024x768) >>> In:serial >>> Out: serial >>> Err: serial >>> Net: Found Micrel KS8051/KS8081 PHY >>> FEC >>> Hit any key to stop autoboot: 0 >>> => usb start >>> starting USB... >>> USB0: Port not available. >>> USB1: USB EHCI 1.00 >>> scanning bus 1 for devices... 2 USB Device(s) found >>> >>> scanning usb for storage devices... 1 Storage Device(s) found >>> scanning usb for ethernet devices... 0 Ethernet Device(s) found >>> >>> => fatload usb 0 0x1800 test.file >>> reading test.file >>> EHCI timed out on TD - token=0xac008d80 >>> EHCI timed out on TD - token=0x80008d80 >>> EHCI timed out on TD - token=0x80008d80 >>> EHCI timed out on TD - token=0x80008d80 >>> EHCI timed out on TD - token=0x128d80 >>> EHCI timed out on TD - token=0x80008d80 >>> EHCI timed out on TD - token=0x80008d80 >>> EHCI timed out on TD - token=0x80008d80 >>> EHCI timed out on TD - token=0x801f8c80 >>> EHCI timed out on TD - token=0x80008d80 >>> EHCI timed out on TD - token=0x80008d80 >>> EHCI timed out on TD - token=0x80008d80 >>> EHCI timed out on TD - token=0x801f8c80 >>> EHCI timed out on TD - token=0x80008d80 >>> EHCI timed out on TD - token=0x80008d80 >>> EHCI timed out on TD - token=0x80008d80 >>> EHCI timed out on TD - token=0x801f8c80 >>> EHCI timed out on TD - token=0x80008d80 >>> EHCI timed out on TD - token=0x80008d80 >>> EHCI timed out on TD - token=0x80008d80 >>> EHCI timed out on TD - token=0x801f8c80 >>> EHCI timed out on TD - token=0x80008d80 >>> EHCI timed out on TD - token=0x80008d80 >>> EHCI timed out on TD - token=0x80008d80 >>> Error reading cluster >>> ** Unable to read file test.file ** > What happens if you do 'dcache off' and then read the file ? Unfortunately turning off dcache doesn't seem to change the behaviour. I'm still getting the same error messages. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Issue with USB mass storage (thumb drives)
On 03.02.2016 10:55, Fabio Estevam wrote: > On Wed, Feb 3, 2016 at 7:40 AM, Marek Vasut wrote: > >> In that case, debug time. >> >> Usual problems are bad routing of the tracks on the board , so try with USB >> 1.1 >> hub and if that works, that's your problem. > Another suggestion would be to try the 100MB transfer in Linux and see > if this works or not. > > That would help us to narrow down whether this is a hardware or > software problem. Thank you Marek and Fabio for your input! I tried the file transfer in Linux and this seems to work fine. Also we have been using this hardware for quite some time, also with USB mass storage and large files in Linux and I can't remember any problems. For these reasons I think that the hardware is ok. I added the DEBUG defines and here are the lines around one of the timeouts. With my very limited knowledge of how usb works, I can't read much from those messages: dev=4ffa58e0, pipe=c0008483, buffer=4f50a1a0, length=13, req= TOKEN=0x8d00 dev=4ffa58e0, pipe=c0010403, buffer=4f50a1c0, length=31, req= TOKEN=0x80008c01 dev=4ffa58e0, pipe=c0008483, buffer=1800, length=33553920, req= TOKEN=0x80009d00 dev=4ffa58e0, pipe=c0008483, buffer=4f50a180, length=13, req= TOKEN=0x8d00 dev=4ffa58e0, pipe=c0010403, buffer=4f50a1c0, length=31, req= TOKEN=0x8c01 dev=4ffa58e0, pipe=c0008483, buffer=19fffe00, length=33553920, req= EHCI timed out on TD - token=0xac008d80 dev=4, usbsts=0x40088, p[1]=0x18001205, p[2]=0x0 usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0 length 0x0 dev=4ffa58e0, pipe=8403, buffer=, length=0, req=4f50a100 req=255 (0xff), type=33 (0x21), value=0 (0x0), index=0 TOKEN=0x8d00 usb_control_msg: request: 0x1, requesttype: 0x2, value 0x0 index 0x81 length 0x0 dev=4ffa58e0, pipe=8403, buffer=, length=0, req=4f50a0c0 req=1 (0x1), type=2 (0x2), value=0 (0x0), index=129 TOKEN=0x8d00 usb_control_msg: request: 0x1, requesttype: 0x2, value 0x0 index 0x2 length 0x0 dev=4ffa58e0, pipe=8403, buffer=, length=0, req=4f50a0c0 req=1 (0x1), type=2 (0x2), value=0 (0x0), index=2 TOKEN=0x8d00 dev=4ffa58e0, pipe=c0010403, buffer=4f50a1c0, length=31, req= TOKEN=0x80008c01 dev=4ffa58e0, pipe=c0008483, buffer=4ffb6d40, length=18, req= TOKEN=0x80008d00 dev=4ffa58e0, pipe=c0008483, buffer=4f50a180, length=13, req= TOKEN=0x8d00 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Issue with USB mass storage (thumb drives)
On 03.02.2016 12:12, Marek Vasut wrote: > On Wednesday, February 03, 2016 at 11:15:00 AM, Schrempf Frieder wrote: >> On 03.02.2016 10:55, Fabio Estevam wrote: >>> On Wed, Feb 3, 2016 at 7:40 AM, Marek Vasut wrote: >>>> In that case, debug time. >>>> >>>> Usual problems are bad routing of the tracks on the board , so try with >>>> USB 1.1 hub and if that works, that's your problem. >>> Another suggestion would be to try the 100MB transfer in Linux and see >>> if this works or not. >>> >>> That would help us to narrow down whether this is a hardware or >>> software problem. >> Thank you Marek and Fabio for your input! >> >> I tried the file transfer in Linux and this seems to work fine. >> Also we have been using this hardware for quite some time, also with USB >> mass storage and large files in Linux and I can't remember any problems. >> For these reasons I think that the hardware is ok. >> >> I added the DEBUG defines and here are the lines around one of the >> timeouts. With my very limited knowledge of how usb works, I can't read >> much from those messages: > It'd help if you shared your patch and the whole output. That way we can > check if something goes wrong at the beginning. > > I wonder if we might be facing some misconfiguration of the USB PHY here ? > > I don't have a MX6Solo . Fabio, any chance you can try ? Here is the debug log for "usb reset": http://paste.ubuntu.com/14865306/ And here the log for the file transfer (different thumb drive and therefore different messages than posted before): http://paste.ubuntu.com/14865349/ The only changes to U-Boot I made is adding my board configuration (derived from Freescale SabreSD config). The only difference from the SabreSD config related to USB is, that I have set CONFIG_USB_MAX_CONTROLLER_COUNT to 2 instead of 1. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Issue with USB mass storage (thumb drives)
On 03.02.2016 17:40, Marek Vasut wrote: > On Wednesday, February 03, 2016 at 12:49:20 PM, Schrempf Frieder wrote: >> On 03.02.2016 12:12, Marek Vasut wrote: >>> On Wednesday, February 03, 2016 at 11:15:00 AM, Schrempf Frieder wrote: >>>> On 03.02.2016 10:55, Fabio Estevam wrote: >>>>> On Wed, Feb 3, 2016 at 7:40 AM, Marek Vasut wrote: >>>>>> In that case, debug time. >>>>>> >>>>>> Usual problems are bad routing of the tracks on the board , so try >>>>>> with USB 1.1 hub and if that works, that's your problem. >>>>> Another suggestion would be to try the 100MB transfer in Linux and see >>>>> if this works or not. >>>>> >>>>> That would help us to narrow down whether this is a hardware or >>>>> software problem. >>>> Thank you Marek and Fabio for your input! >>>> >>>> I tried the file transfer in Linux and this seems to work fine. >>>> Also we have been using this hardware for quite some time, also with USB >>>> mass storage and large files in Linux and I can't remember any problems. >>>> For these reasons I think that the hardware is ok. >>>> >>>> I added the DEBUG defines and here are the lines around one of the >>>> timeouts. With my very limited knowledge of how usb works, I can't read >>>> much from those messages: >>> It'd help if you shared your patch and the whole output. That way we can >>> check if something goes wrong at the beginning. >>> >>> I wonder if we might be facing some misconfiguration of the USB PHY here >>> ? >>> >>> I don't have a MX6Solo . Fabio, any chance you can try ? >> Here is the debug log for "usb reset": http://paste.ubuntu.com/14865306/ >> And here the log for the file transfer (different thumb drive and >> therefore different messages than posted before): >> http://paste.ubuntu.com/14865349/ >> >> The only changes to U-Boot I made is adding my board configuration >> (derived from Freescale SabreSD config). >> The only difference from the SabreSD config related to USB is, that I >> have set CONFIG_USB_MAX_CONTROLLER_COUNT to 2 instead of 1. > The detection seems fine, it even does what it's supposed to do. > > You have a USB hub somewhere in there, right ? Is it a powered one or not ? > > What I find weird in the later log is that the failure always happens when > the buffer is at 0x19fffe00 . I suppose you're loading to 0x1800 and you > have 0x2000 or 512MiB of RAM (?). Try loading to 0x800 and see if > that helps. If it does, then you might be overwriting some malloc area of > U-Boot or somesuch . We have two self-powered USB hubs on our board, but we also have boards without any hub and I can see the same issue on those. I tried loading to 0x800 and the strange thing is, that it even fails on those USB devices, that were previously working while loading to 0x1800. So reading fails on all USB devices I tried, when loading to 0x800 with a log like this: http://paste.ubuntu.com/14875686/ But when I load to 0x1800 I have 2 devices with 100% success rate: http://paste.ubuntu.com/14875795/ And 1 device with 100% failure rate: http://paste.ubuntu.com/14865349/ I even have 1GiB of RAM on this board. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Issue with USB mass storage (thumb drives)
On 03.02.2016 20:16, Sergei Temerkhanov wrote: > On Wed, Feb 3, 2016 at 8:40 AM, Marek Vasut wrote: >> On Wednesday, February 03, 2016 at 12:49:20 PM, Schrempf Frieder wrote: >>> On 03.02.2016 12:12, Marek Vasut wrote: >>>> On Wednesday, February 03, 2016 at 11:15:00 AM, Schrempf Frieder wrote: >>>>> On 03.02.2016 10:55, Fabio Estevam wrote: >>>>>> On Wed, Feb 3, 2016 at 7:40 AM, Marek Vasut wrote: >>>>>>> In that case, debug time. >>>>>>> >>>>>>> Usual problems are bad routing of the tracks on the board , so try >>>>>>> with USB 1.1 hub and if that works, that's your problem. >>>>>> Another suggestion would be to try the 100MB transfer in Linux and see >>>>>> if this works or not. >>>>>> >>>>>> That would help us to narrow down whether this is a hardware or >>>>>> software problem. > Another thing to try may be limiting the value of USB_MAX_XFER_BLK in > common/usb_storage.c This was a really helpful hint! Thank you Sergei! I just tried to limit USB_MAX_XFER_BLK to 1/8 of the original value (65535 -> 8191) and this time the transfer works without timeouts. As we have a customer who needs this working as soon as possible my question now is how to properly solve this. Should I generally limit USB_MAX_XFER_BLK in my u-boot to avoid these errors? Which value to choose? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Issue with USB mass storage (thumb drives)
On 04.02.2016 12:28, Marek Vasut wrote: > On Thursday, February 04, 2016 at 09:21:08 AM, Schrempf Frieder wrote: >> On 03.02.2016 20:16, Sergei Temerkhanov wrote: >>> On Wed, Feb 3, 2016 at 8:40 AM, Marek Vasut wrote: >>>> On Wednesday, February 03, 2016 at 12:49:20 PM, Schrempf Frieder wrote: >>>>> On 03.02.2016 12:12, Marek Vasut wrote: >>>>>> On Wednesday, February 03, 2016 at 11:15:00 AM, Schrempf Frieder wrote: >>>>>>> On 03.02.2016 10:55, Fabio Estevam wrote: >>>>>>>> On Wed, Feb 3, 2016 at 7:40 AM, Marek Vasut wrote: >>>>>>>>> In that case, debug time. >>>>>>>>> >>>>>>>>> Usual problems are bad routing of the tracks on the board , so try >>>>>>>>> with USB 1.1 hub and if that works, that's your problem. >>>>>>>> Another suggestion would be to try the 100MB transfer in Linux and >>>>>>>> see if this works or not. >>>>>>>> >>>>>>>> That would help us to narrow down whether this is a hardware or >>>>>>>> software problem. >>> Another thing to try may be limiting the value of USB_MAX_XFER_BLK in >>> common/usb_storage.c >> This was a really helpful hint! Thank you Sergei! >> >> I just tried to limit USB_MAX_XFER_BLK to 1/8 of the original value >> (65535 -> 8191) and this time the transfer works without timeouts. >> >> As we have a customer who needs this working as soon as possible my >> question now is how to properly solve this. >> Should I generally limit USB_MAX_XFER_BLK in my u-boot to avoid these >> errors? Which value to choose? > Nice! Can you share which sticks are those, ideally brand/type and USB IDs ? At the moment I have two sticks with the same chip around for which setting USB_MAX_XFER_BLK from 65535 to 32767 fixed the file transfer. Also one of our customers tested a few non-working sticks with this change and reported, that it fixed it for him. Here's a list of those devices, but I guess there are a lot more: 1. Silicon Motion, Inc. - Taiwan (formerly Feiya Technology Corp.) Flash Drive, VID: 0x090c, PID: 0x1000 2. Freecom Technologies, VID: 0x07ab, PID: 0xfcf1 3. Newron, VID: 0x8644, PID: 0x800e 4. GEMBIRD PhotoFrame PF-15-1, VID: 0x1908, PID: 0x1320 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Issue with USB mass storage (thumb drives)
On 18.02.2016 18:14, Fabio Estevam wrote: > On Thu, Feb 18, 2016 at 1:32 PM, Marek Vasut wrote: > >>> Also one of our customers tested a few non-working sticks with this >>> change and reported, that it fixed it for him. >>> Here's a list of those devices, but I guess there are a lot more: >>> >>> 1. Silicon Motion, Inc. - Taiwan (formerly Feiya Technology Corp.) Flash >>> Drive, VID: 0x090c, PID: 0x1000 >>> 2. Freecom Technologies, VID: 0x07ab, PID: 0xfcf1 >>> 3. Newron, VID: 0x8644, PID: 0x800e >>> 4. GEMBIRD PhotoFrame PF-15-1, VID: 0x1908, PID: 0x1320 >>> >> Maybe we need a quirk table then ? > It seems the list of affected devices is unknown. > > What would be the impact of changing USB_MAX_XFER_BLK from 65535 to 32767? > > Would this impact the USB transfer rate? Frieder, do you know? I don't really know. While testing I had the feeling, that the transfer is slightly slower, but I can't tell for sure. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Cannot boot mx6qsabred with 2019.07-rc2
Hi Shyam, On 31.05.19 11:10, Shyam Saini wrote: > Hi Schrempf, > > As of now imx usb loader does not process FIT images. > Have you added some patch or support on imx usb loader side ? No, I'm using imx_usb_loader only to load the FIT image to DRAM in SPL via SDP. The SPL is then processing the FIT image and loading U-Boot proper from the image. Regards, Frieder > > Thanks and regards, > Shyam > > On Mon, May 27, 2019 at 12:10 PM Schrempf Frieder > wrote: >> >> Hi Fabio, >> >> On 23.05.19 19:45, Fabio Estevam wrote: >>> Hi Schrempf, >>> >>> On Thu, May 23, 2019 at 2:26 PM Schrempf Frieder >>> wrote: >>> >>>> As luck would have it, I needed to load a FIT via SDP today, so I came >>>> up with a quick patch (see below). There are probably better ways to do >>>> this, but it works. >>> >>> Thanks for your patch! >>> >>> I would like to give it a try, but it does not apply against U-Boot >>> mainline. >>> >>> I manually applied it, but failed to build: >>> >>> cmd/usb_gadget_sdp.c: In function ‘do_sdp’: >>> cmd/usb_gadget_sdp.c:35:2: error: too few arguments to function ‘sdp_handle’ >>> sdp_handle(controller_index); >> >> Sorry, I just picked the patch from my messy working tree and it's based >> on 2019.04 and some other changes. >> >>> Could you please rebase it against U-Boot mainline and post it like a >>> formal patch? >> >> I need to do some rebasing and cleanup, but I'm definitely planning to >> send this as a patch for upstream. >> >> Thanks, >> Frieder >> ___ >> U-Boot mailing list >> U-Boot@lists.denx.de >> https://lists.denx.de/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/5] usb: gadget: f_sdp: Allow SPL to load and boot FIT via SDP
Hi Sjoerd,
On 03.06.19 21:00, Sjoerd Simons wrote:
> From: Frieder Schrempf
>
> Add support for loading u-boot FIT images over the USB SPD protocol in
> the SPL
I always get confused by this acronym too, but *SPD* is the Social
Democratic Party of Germany, currently in a deep crisis after the recent
election and after their leader resigned from all offices two days ago.
And *SDP* is the Serial Download Protocol ;)
>
> [Small fixes to build]
> Signed-off-by: Sjoerd Simons
Signed-off-by: Frieder Schrempf
Thanks a lot for preparing the patch and sending it!
Regards,
Frieder
> ---
>
> common/spl/spl_sdp.c | 11 --
> drivers/usb/gadget/f_sdp.c | 41 --
> include/sdp.h | 4 +++-
> 3 files changed, 47 insertions(+), 9 deletions(-)
>
> diff --git a/common/spl/spl_sdp.c b/common/spl/spl_sdp.c
> index 807256e908..dc57171966 100644
> --- a/common/spl/spl_sdp.c
> +++ b/common/spl/spl_sdp.c
> @@ -26,9 +26,16 @@ static int spl_sdp_load_image(struct spl_image_info
> *spl_image,
> }
>
> /* This command typically does not return but jumps to an image */
> - sdp_handle(controller_index);
> + sdp_handle(controller_index, spl_image);
> pr_err("SDP ended\n");
> + /*
> + * This command either loads a legacy image, jumps and never returns,
> + * or it loads a FIT image and returns it to be handled by the SPL
> + * code.
> + */
> + ret = sdp_handle(controller_index, spl_image);
> + debug("SDP ended\n");
>
> - return -EINVAL;
> + return ret;
> }
> SPL_LOAD_IMAGE_METHOD("USB SDP", 0, BOOT_DEVICE_BOARD, spl_sdp_load_image);
> diff --git a/drivers/usb/gadget/f_sdp.c b/drivers/usb/gadget/f_sdp.c
> index ae97ab2b49..2a23160d91 100644
> --- a/drivers/usb/gadget/f_sdp.c
> +++ b/drivers/usb/gadget/f_sdp.c
> @@ -638,7 +638,18 @@ static u32 sdp_jump_imxheader(void *address)
> return 0;
> }
>
> -static void sdp_handle_in_ep(void)
> +#ifdef CONFIG_SPL_LOAD_FIT
> +static ulong sdp_fit_read(struct spl_load_info *load, ulong sector,
> + ulong count, void *buf)
> +{
> + debug("%s: sector %lx, count %lx, buf %lx\n",
> + __func__, sector, count, (ulong)buf);
> + memcpy(buf, (void *)(load->dev + sector), count);
> + return count;
> +}
> +#endif
> +
> +static void sdp_handle_in_ep(struct spl_image_info *spl_image)
> {
> u8 *data = sdp_func->in_req->buf;
> u32 status;
> @@ -689,11 +700,26 @@ static void sdp_handle_in_ep(void)
>
> /* If imx header fails, try some U-Boot specific headers */
> if (status) {
> + image_header_t *header =
> + sdp_ptr(sdp_func->jmp_address);
> #ifdef CONFIG_SPL_BUILD
> +#ifdef CONFIG_SPL_LOAD_FIT
> + if (image_get_magic(header) == FDT_MAGIC) {
> + struct spl_load_info load;
> +
> + debug("Found FIT\n");
> + load.dev = header;
> + load.bl_len = 1;
> + load.read = sdp_fit_read;
> + spl_load_simple_fit(spl_image, &load, 0,
> + header);
> +
> + return;
> + }
> +#endif
> /* In SPL, allow jumps to U-Boot images */
> struct spl_image_info spl_image = {};
> - spl_parse_image_header(&spl_image,
> - (struct image_header *)sdp_func->jmp_address);
> + spl_parse_image_header(&spl_image, header);
> jump_to_image_no_args(&spl_image);
> #else
> /* In U-Boot, allow jumps to scripts */
> @@ -715,19 +741,22 @@ static void sdp_handle_in_ep(void)
> };
> }
>
> -void sdp_handle(int controller_index)
> +int sdp_handle(int controller_index, struct spl_image_info *spl_image)
> {
> printf("SDP: handle requests...\n");
> while (1) {
> if (ctrlc()) {
> puts("\rCTRL+C - Operation aborted.\n");
> - return;
> + return -EINVAL;
> }
>
> + if (spl_image->flags & SPL_FIT_FOUND)
> + return 0;
> +
> WATCHDOG_RESET();
> usb_gadget_handle_interrupts(controller_index);
>
> - sdp_handle_in_ep();
> + sdp_handle_in_ep(spl_image);
> }
> }
>
> diff --git a/include/sdp.h b/include/sdp.h
> index f6252d027f..f30e2bca19 100644
> --- a/include/sdp.h
> +++ b/include/sdp.h
> @@ -9,7 +9,9 @@
> #ifndef __SDP_H_
> #define __SDP_H_
>
> +#include
> +
> int sdp_init(int controller_index);
> -void sdp_handle(int controller_index);
> +int sdp_handle(int controller_index, struct spl_image_info *spl_image);
>
> #endif /
[U-Boot] i.MX8MM mapped register access causes crashes
Hi Peng, I'm still trying to get my i.MX8MM board running with mainline U-Boot. I'm using your patches and added some modifications, so I'm now able to run SPL and U-Boot proper. One problem I have is, that accessing some regions in the memory map for peripheral register access, U-Boot crashes or hangs. Example: => md 0x302d 302d: 0743 e031 C...1... 302d0010: 302d0020: 001012ec"Synchronous Abort" handler, esr 0x96000210 elr: 40251b84 lr : 40251ba0 (reloc) elr: bffa3b84 lr : bffa3ba0 x0 : bffb9000 x1 : 308800b4 x2 : bff6e9b4 x3 : 302d0028 x4 : x5 : bffb96a2 x6 : 0004 x7 : bbf3c330 x8 : bbf3c2f0 x9 : 000c x10: ffd8 x11: 0006 x12: 0001869f x13: 4238 x14: bbf3c59c x15: 0008 x16: b900 x17: ae80 x18: bbf41d70 x19: 0038 x20: 302d0020 x21: 302d0020 x22: bffb8e5f x23: 0008 x24: 0004 x25: 0004 x26: 0004 x27: bbf3c3b8 x28: 0002 x29: bbf3c330 Do you have any idea what might be wrong or how I could debug this issue? Thanks, Frieder ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] i.MX8MM mapped register access causes crashes
On 06.06.19 03:58, Peng Fan wrote: > >> Subject: Re: [U-Boot] i.MX8MM mapped register access causes crashes >> >> On Wed, Jun 5, 2019 at 10:52 PM Peng Fan wrote: >> >>> You need to pass an arg after `md 0x302d`. Default it will dump a >>> lot registers, might 40 registers. It surely will crash, because there >>> are only a few registers in GPT1 which is the address you are dumping. >> >> Other suggestion is to make sure that the clock for the peripheral you are >> trying to access is turned on. > > Dump `md 0x302d 1` will surely work, but dump `md 0x302d 100` > will surely crash. The clock already on. It is that GPT1 does not have 100 > registers, and trigger error when dumping non-existed registers. Thanks for your suggestions. I just used GPT1 as an example. As you can see GPT1 registers can be dumped, but at the start of GPT2 it crashes. I have the same problem for all kinds of other peripherals. For example I tried to enable I2C1, but the driver hangs in probe when it accesses an I2C1 register for the first time. I suspect that this is either, as Fabio said, caused by clocks that are turned off, or because of trustzone settings. I'm not loading any ATF at the moment, so I'm booting from SPL directly to U-Boot proper and I'm not sure if the trustzone settings restrict access to the peripherals in this case. Thanks, Frieder ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5 00/18] clk: Port Linux common clock framework [CCF] to U-boot (tag: v5.1.12)
Hi Lukasz, On 24.06.19 15:50, Lukasz Majewski wrote: > This patch series brings the files from Linux kernel (SHA1: 5752b50477da > Linux 5.1.12 to provide clocks support as it is used on the Linux kernel > with Common Clock Framework [CCF] setup. > > This series also fixes several problems with current clocks and provides > sandbox tests for functions added to clk-uclass.c file. > > CCF impact to U-Boot size: > -- > SPL U-Boot.img > Without CCF: 51 KiB 358 KiB > With CCF: 55 KiB 363 KiB > Size increase:1.3%7.2% The size increase numbers seem to be a bit off. It's 7.8% for SPL (which is quite a lot) and 1.4% for U-Boot proper from your size values. By the way: Thanks for the new version. I'm currently still experimenting with your v3 and Peng's patches for i.MX8MM on top of 2019.04. I hope I have time to rebase on master and v5 soon. Thanks, Frieder > > The SPL implementation is not yet optimized (no OF_PLATDATA, etc). > > Repository: > https://github.com/lmajewski/u-boot-dfu/commits/CCF-v5 > > Applicable on top of u-boot/master: > SHA1: 77f6e2dd0551d8a825bab391a1bd6b838874bcd4 > > Travis-CI: > https://travis-ci.org/lmajewski/u-boot-dfu/builds/549603356 > > > Changes in v6: > - Use dev->uclass_priv pointer to store pointer to clk > > Changes in v5: > - s/U-boot/U-Boot/g > - Update Linux version to 5.1.12 > - Add paragraph regarding sandbox CCF testing (common uclass code) > - Use long long to store rate value (to avoid int overflow and also return >errors correctly) > - Use u32 to avoid checkpatch warning > - s/U-boot/U-Boot/g > - Replace dev->driver_data with dev_get_clk_ptr() wrapper on uclass_priv > - Replace ulong with long long (to accommodate large freqs and return >errors) > - s/U-boot/U-Boot/g > - Check if the relevant code has changed between Linux tag v5.0-rc3 and >v5.1.12 (no changes - the version can be safely updated). > - Use imply CLK_IMX6Q in Kconfig for (SPL_)CCF > - Fix clk-fixed-factor implementation (kzalloc needed for correct Sandbox >operation) > - Fix gate2 implementation > - Use dev->uclass_priv instead of dev->driver_data to store back pointer >to the struct clk. > - Split and introduce earlier the clk-provider.h header file > > Changes in v4: > - New patch > - Port some more Linux code to facilitate imx8 code porting (most notably >flags) > - Explicitly use container_of() based macro to provide struct clk in various >places (e.g. gate2, mux, etc) >Following patches has been squashed: >http://patchwork.ozlabs.org/patch/1093141/ >http://patchwork.ozlabs.org/patch/1093142/ >http://patchwork.ozlabs.org/patch/1093146/ > > Changes in v3: > - New patch > - The rate information is now cached into struct clk field > - The clk_get_parent() is used to get pointer to the parent struct clk > - Replace -ENODEV with -ENOENT > - Use **clkp instead of **c > - Replace dev->driver_data with dev_get_clk_ptr() wrapper on uclas_priv > > Lukasz Majewski (18): >clk: doc: Add documentation entry for Common Clock Framework [CCF] > (i.MX) >dm: Fix documentation entry as there is no UCLASS_CLOCK uclass >clk: Remove clock ID check in .get_rate() of clk_fixed_* >clk: Extend struct clk to provide information regarding clock rate >clk: Extend struct clk to provide clock type agnostic flags >clk: Provide struct clk for fixed rate clock (clk_fixed_rate.c) >clk: Introduce clk-provider.h to store Common Clock Framework's > internals >dm: clk: Define clk_get_parent() for clk operations >dm: clk: Define clk_get_parent_rate() for clk operations >dm: clk: Define clk_get_by_id() for clk operations >clk: Port Linux common clock framework [CCF] for imx6q to U-boot (tag: > v5.1.12) >dm: clk: Extend clk_get_parent_rate() to support CLK_GET_RATE_NOCACHE > flag >dts: sandbox: Add 'osc' clock for Common Clock Framework [CCF] testing >clk: sandbox: Adjust clk-divider to emulate reading its value from HW >clk: sandbox: Adjust clk-mux.c to emulate reading divider value from > HW >clk: sandbox: Add sandbox test code for Common Clock Framework [CCF] >defconfig: sandbox: Enable SANDBOX_CLK_CCF to reuse generic CCF code >clk: Add MAINTAINERS entry for clocks (./drivers/clk/) > > MAINTAINERS| 7 ++ > arch/sandbox/dts/test.dts | 10 ++ > configs/sandbox_defconfig | 1 + > configs/sandbox_flattree_defconfig | 1 + > doc/imx/clk/ccf.txt| 101 > drivers/clk/Kconfig| 22 + > drivers/clk/Makefile | 3 + > drivers/clk/clk-divider.c | 155 +++ > drivers/clk/clk-fixed-factor.c | 80 > drivers/clk/clk-mux.c | 172 ++ > drivers/clk/clk-ucla
[U-Boot] [PATCH] spl: atf: Fix uninitialized pointer to bl31_image_info
From: Frieder Schrempf
The pointer to struct atf_image_info in
bl31_params_mem.bl31_params.bl31_image_info is not initialized before
being dereferenced. This can cause U-Boot to crash right before jumping
to the BL31 ATF binary.
Signed-off-by: Frieder Schrempf
Fixes: bcc1726a7bdd ("spl: add support to booting with ATF")
---
common/spl/spl_atf.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/common/spl/spl_atf.c b/common/spl/spl_atf.c
index cddab6a735..4715f9d371 100644
--- a/common/spl/spl_atf.c
+++ b/common/spl/spl_atf.c
@@ -45,6 +45,7 @@ static struct bl31_params *bl2_plat_get_bl31_params(uintptr_t
bl33_entry)
SET_PARAM_HEAD(bl2_to_bl31_params, ATF_PARAM_BL31, ATF_VERSION_1, 0);
/* Fill BL31 related information */
+ bl2_to_bl31_params->bl31_image_info = &bl31_params_mem.bl31_image_info;
SET_PARAM_HEAD(bl2_to_bl31_params->bl31_image_info,
ATF_PARAM_IMAGE_BINARY, ATF_VERSION_1, 0);
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] treewide: Replace CONFIG_DM_SPI_FLASH with CONFIG_IS_ENABLED(DM_SPI_FLASH)
On 20.02.19 12:20, Marek Vasut wrote: > On 2/20/19 12:18 PM, Schrempf Frieder wrote: >> On 19.02.19 06:07, Marek Vasut wrote: >>> Perform the replacement to allow platforms use non-DM SPI flash access >>> in SPL/TPL. This is thus far needed on platforms with size constraints. >>> >>> Signed-off-by: Marek Vasut >>> Cc: Jagan Teki >>> Cc: Vignesh R >> >> I stumbled upon this issue when trying to build a non-DM SPL for imx >> with SPI flash access. This fixes the build. >> >> Reviewed-by: Frieder Schrempf >> Tested-by: Frieder Schrempf > > This patch breaks x86 at least, so NAK. > It seems, that there's still no solution for this upstream. I tried to build Marek's patch with a fixup on current master [1], but still the build breaks for some configurations [2]. Can someone have a look, how to fix the failing boards? Thanks, Frieder [1] https://github.com/fschrempf/u-boot/commits/non_dm_spi_flash_in_spl [2] https://travis-ci.org/fschrempf/u-boot/builds/551244482 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] fsl_qspi: Improve QSPI driver to incorporate 4 byte commands
Hi, On 26.04.19 06:58, Vignesh Raghavendra wrote: > > > On 25/04/19 5:20 PM, Rajat Srivastava wrote: >> >> >>> -Original Message- >>> From: Vignesh Raghavendra >>> Sent: Wednesday, April 24, 2019 10:17 PM >>> To: Rajat Srivastava ; u-boot@lists.denx.de; >>> ja...@openedev.com >>> Cc: Ashish Kumar >>> Subject: [EXT] Re: [PATCH 2/2] fsl_qspi: Improve QSPI driver to incorporate >>> 4 >>> byte commands >>> >>> Caution: EXT Email >>> >>> On 24-Apr-19 6:10 PM, Rajat Srivastava wrote: Signed-off-by: Ashish Kumar Signed-off-by: Rajat Srivastava >>> >>> Commit message is missing. >> >> I'll add proper commit message in the next patch version. >> >>> But from $patch subject, I infer that $patch is >>> adding new feature and not actually fixing something broken? >> >> Earlier the framework was designed to work for only 3-byte opcodes but our >> controller supports flashes of size greater than 16 MB. As a workaround, >> FSL QSPI driver used to explicitly send 4-byte opcodes for 3-byte opcodes >> sent by >> framework to the flash. Also there used to exist a temporary patch for >> framework >> which never got accepted In upstream. >> Now the new framework supports 4-byte opcodes and FSL QSPI driver needs >> correction. I am not introducing any new feature. I am just fixing the driver >> to suit the current framework. >> > > With SPL_FLASH_BAR set fsl_qspi driver should never see 4 byte opcodes > and should work like it did before. I guess you are disabling SPI_FLASH_BAR? > > Please add all details to the commit message and I recommend you to move > the driver over to spi-mem as soon as possible. Else you would have to > keep handling new opcodes in your driver as and when spi-nor-core changes. > > Regards > Vignesh > >> Please let me know your feedback. >> >> Regards >> Rajat >> >>> If so, you should move the driver over to use spi-mem APIs instead of adding >>> more features and hard coding more flash specific commands in the driver. >>> This makes driver duplicate more of spi-nor core code. I discourage adding >>> new features w/o moving driver over to spi-mem. IMHO, converting the >>> driver would not be a huge effort. And I believe its already done in kernel. I started moving the driver to spi-mem, by porting the kernel driver over to U-Boot. I still have some Kconfig dependency problem for the LS2081 platform (CONFIG_SPI_MEM is not enabled implicitly), that needs to be solved, otherwise it should be more or less ready. For anyone who wants to check/test the current state, look here: [1] Regards, Frieder [1]: https://github.com/fschrempf/u-boot/commits/fsl_qspi_spimem_port ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: [PATCH 2/2] fsl_qspi: Improve QSPI driver to incorporate 4 byte commands
Hi Ashish, On 01.05.19 07:32, Ashish Kumar wrote: > > >> -Original Message- >> From: U-Boot On Behalf Of Schrempf Frieder >> Sent: Tuesday, April 30, 2019 1:14 PM >> To: Vignesh Raghavendra ; Rajat Srivastava >> ; u-boot@lists.denx.de; ja...@openedev.com >> Subject: [EXT] Re: [U-Boot] [PATCH 2/2] fsl_qspi: Improve QSPI driver to >> incorporate 4 byte commands >> >> Caution: EXT Email >> >> Hi, >> >> On 26.04.19 06:58, Vignesh Raghavendra wrote: >>> >>> >>> On 25/04/19 5:20 PM, Rajat Srivastava wrote: >>>> >>>> >>>>> -Original Message- >>>>> From: Vignesh Raghavendra >>>>> Sent: Wednesday, April 24, 2019 10:17 PM >>>>> To: Rajat Srivastava ; >>>>> u-boot@lists.denx.de; ja...@openedev.com >>>>> Cc: Ashish Kumar >>>>> Subject: [EXT] Re: [PATCH 2/2] fsl_qspi: Improve QSPI driver to >>>>> incorporate 4 byte commands >>>>> >>>>> Caution: EXT Email >>>>> >>>>> On 24-Apr-19 6:10 PM, Rajat Srivastava wrote: >>>>>> Signed-off-by: Ashish Kumar >>>>>> Signed-off-by: Rajat Srivastava >>>>> >>>>> Commit message is missing. >>>> >>>> I'll add proper commit message in the next patch version. >>>> >>>>> But from $patch subject, I infer that $patch is adding new feature >>>>> and not actually fixing something broken? >>>> >>>> Earlier the framework was designed to work for only 3-byte opcodes >>>> but our controller supports flashes of size greater than 16 MB. As a >>>> workaround, FSL QSPI driver used to explicitly send 4-byte opcodes >>>> for 3-byte opcodes sent by framework to the flash. Also there used to >>>> exist a temporary patch for framework which never got accepted In >> upstream. >>>> Now the new framework supports 4-byte opcodes and FSL QSPI driver >>>> needs correction. I am not introducing any new feature. I am just >>>> fixing the driver to suit the current framework. >>>> >>> >>> With SPL_FLASH_BAR set fsl_qspi driver should never see 4 byte opcodes >>> and should work like it did before. I guess you are disabling SPI_FLASH_BAR? >>> >>> Please add all details to the commit message and I recommend you to >>> move the driver over to spi-mem as soon as possible. Else you would >>> have to keep handling new opcodes in your driver as and when spi-nor-core >> changes. >>> >>> Regards >>> Vignesh >>> >>>> Please let me know your feedback. >>>> >>>> Regards >>>> Rajat >>>> >>>>> If so, you should move the driver over to use spi-mem APIs instead >>>>> of adding more features and hard coding more flash specific commands in >> the driver. >>>>> This makes driver duplicate more of spi-nor core code. I discourage >>>>> adding new features w/o moving driver over to spi-mem. IMHO, >>>>> converting the driver would not be a huge effort. And I believe its >>>>> already >> done in kernel. >> >> I started moving the driver to spi-mem, by porting the kernel driver over to >> U- >> Boot. I still have some Kconfig dependency problem for the >> LS2081 platform (CONFIG_SPI_MEM is not enabled implicitly), that needs to >> be solved, otherwise it should be more or less ready. > Hi Frieder, > > What is the change, it seems it is moving the driver from Linux as it is to > uboot ? Yes, it's moving the current Linux driver to U-Boot with some small compatibility changes and simplifications. > I am not sure how stable is the current Linux driver, since it is not yet > tested by FSL/NXP system test team. Last time I tested the current Linux > driver(QSPI) it was functional in only 1-1-1 mode. Moving to u-boot may not > be good idea at this point of time. The current mainline Linux driver is a SPI controller driver using the SPI MEM API and it replaced the old SPI NOR driver in Linux 5.1. If nothing went wrong in the upstreaming process, the driver should be just as good as the old one, while bringing all the advantages of the new SPI MEM interface. The driver does support 1-1-1 mode, just like all other modes supported by the QSPI controller. While upstreaming to the kernel, the driver was tested by Han Xu and Yogesh Gaur. > How do you plan to cater CONFIG_SPI_BAR change in uboot now. Some ol
Re: [U-Boot] [i.MX8MM+CCF 00/41] i.MX8MM + CCF
Hi Peng, I'm trying to add support for a board with i.MX8MM. First I applied Lukasz's CCF patches and your patches to U-Boot 2019.04 and tried to build imx8mm_evk config. But I'm getting build errors (see below). Are there any other patches needed? What things are still missing to get i.MX8MM running in U-Boot? Thanks, Frieder | aarch64-ktn-linux-ld.bfd: cmd/built-in.o: in function `do_fuse': | /home/frieder/repos/u-boot/cmd/fuse.c:68: undefined reference to `fuse_read' | aarch64-ktn-linux-ld.bfd: /home/frieder/repos/u-boot/cmd/fuse.c:86: undefined reference to `fuse_sense' | aarch64-ktn-linux-ld.bfd: /home/frieder/repos/u-boot/cmd/fuse.c:105: undefined reference to `fuse_prog' | aarch64-ktn-linux-ld.bfd: /home/frieder/repos/u-boot/cmd/fuse.c:119: undefined reference to `fuse_override' | aarch64-ktn-linux-ld.bfd: drivers/i2c/built-in.o: in function `mxc_i2c_probe': | /home/frieder/repos/u-boot/drivers/i2c/mxc_i2c.c:824: undefined reference to `enable_i2c_clk' | aarch64-ktn-linux-ld.bfd: /home/frieder/repos/u-boot/drivers/i2c/mxc_i2c.c:853: undefined reference to `enable_i2c_clk' On 30.04.19 12:17, Peng Fan wrote: > This patch set is based Lukasz V3 CCF patchset, > [PATCH v3 00/11] clk: Port Linux common clock framework [CCF] to U-boot (tag: > 5.0-rc3) > https://github.com/lmajewski/u-boot-dfu/commits/CCF-v3 > > Added a few fixes to Lukasz's v3 patchset. > Introduced clk-gate/composite > Added set rate support > Per my understanding, U-Boot CCF will not support mux reparent, and > support rate prograte setting to parent automatically. So new clk > feature added follow this rule. > > There are many warnings when importing linux ccf code, I did not > modify them all. > > The rest patches are for i.MX8MM, part of legacy clk code are still > kept, because we are hard to enable CCF at very early stage, we set > malloc space to DRAM when dram initialized in spl stage, so we have > limited SRAM for uclass dm and dm clk, so keep the DRAM PLL related > setting with legacy clk code which use small ram. > > The u-boot-spl.bin now is about 100KB without ddr firmware,usb stack and hab, > so really large.. > I am thinking what we could do to shrink the size, welcome any suggestions. > > Not expect this patchset could be merged, because of the CCF/clock code > change, but since the clock part blocks i.MX8MM upstream, just would like > to speed up the development with community and move on. > > Peng Fan (40): >clk: correct get clk_x pointer >clk: fixed-factor: fix get clk_fixed_factor >clk: introduce clk_dev_binded >clk: use clk_dev_binded >clk-provider: sync more clk flags from Linux Kernel >cmd: clk: print err value when clk_get_rate failed >clk: mux: add set parent support >clk: export mux/divider ops >clk: add clk-gate support >divider set rate supporrt >clk: fixed_rate: export clk_fixed_rate >clk: fixed_rate: add pre reloc flag >clk: imx: import clk heplers >clk: imx: gate2 add set rate >linux: compat: guard PAGE_SIZE >drivers: core: use strcmp when find device by name >ddr: imx8m: fix ddr firmware location when enable SPL OF >imx: add IMX8MQ kconfig entry >imx: add IMX8MM kconfig entry >imx: imx8mm: add clock bindings header >imx: add i.MX8MM cpu type >imx: spl: add spl_board_boot_device for i.MX8MM >imx8m: update imx-regs for i.MX8MM >imx: add get_cpu_rev support for i.MX8MM >imx8m: rename clock to clock_imx8mq >imx8m: restructure clock.h >imx8m: add clk support for i.MX8MM >imx8m: soc: probe clk before relocation >imx8m: add pin header for i.MX8MM >imx: add i.MX8MM PE property >imx8m: Fix MMU table issue for OPTEE memory >imx8m: set BYPASS ID SWAP to avoid AXI bus errors >imx8m: soc: enable SCTR clock before timer init >serial: Kconfig: make MXC_UART usable for MX7 and IMX8M >clk: imx: add Kconfig entry for i.MX8MM >clk: imx: add pll14xx driver >clk: add composite clk support >clk: imx: add i.MX8MM composite clk support >clk: imx: add i.MX8MM clk driver >imx: add i.MX8MM EVK board support > > Ye Li (1): >imx8m: Configure trustzone region 0 for non-secure access > > arch/arm/dts/Makefile |3 +- > arch/arm/dts/imx8mm-evk-u-boot.dtsi| 92 + > arch/arm/dts/imx8mm-evk.dts| 235 +++ > arch/arm/dts/imx8mm-pinfunc.h | 629 +++ > arch/arm/dts/imx8mm.dtsi | 733 > arch/arm/include/asm/arch-imx/cpu.h|6 + > arch/arm/include/asm/arch-imx8m/clock.h| 493 + > arch/arm/include/asm/arch-imx8m/clock_imx8mm.h | 387 > arch/arm/include/asm/arch-imx8m/clock_imx8mq.h | 424 + > arch/arm/include/asm/arch-imx8m/imx-regs.h | 75 +- > arch/arm/include/asm/arch-imx8m/imx8mm_pins.h | 691 +++ > arch/arm/include/asm/mach-imx/iomux
Re: [U-Boot] [i.MX8MM+CCF 00/41] i.MX8MM + CCF
On 06.05.19 09:57, Frieder Schrempf wrote: > Hi Peng, > > I'm trying to add support for a board with i.MX8MM. First I applied > Lukasz's CCF patches and your patches to U-Boot 2019.04 and tried to > build imx8mm_evk config. But I'm getting build errors (see below). The build works if I enable the OTP fuse driver and disable I2C support. In clock_imx8mm.c enable_i2c_clk() seems to be missing, or maybe the i2c driver needs to use the new clock framework now? > > Are there any other patches needed? > What things are still missing to get i.MX8MM running in U-Boot? It seems like this still needs a bit of work. I also see some CONFIG options defined in the headers, that should be moved to defconfig. > > Thanks, > Frieder > > | aarch64-ktn-linux-ld.bfd: cmd/built-in.o: in function `do_fuse': > | /home/frieder/repos/u-boot/cmd/fuse.c:68: undefined reference to > `fuse_read' > | aarch64-ktn-linux-ld.bfd: /home/frieder/repos/u-boot/cmd/fuse.c:86: > undefined reference to `fuse_sense' > | aarch64-ktn-linux-ld.bfd: /home/frieder/repos/u-boot/cmd/fuse.c:105: > undefined reference to `fuse_prog' > | aarch64-ktn-linux-ld.bfd: /home/frieder/repos/u-boot/cmd/fuse.c:119: > undefined reference to `fuse_override' > | aarch64-ktn-linux-ld.bfd: drivers/i2c/built-in.o: in function > `mxc_i2c_probe': > | /home/frieder/repos/u-boot/drivers/i2c/mxc_i2c.c:824: undefined > reference to `enable_i2c_clk' > | aarch64-ktn-linux-ld.bfd: > /home/frieder/repos/u-boot/drivers/i2c/mxc_i2c.c:853: undefined > reference to `enable_i2c_clk' > > > On 30.04.19 12:17, Peng Fan wrote: >> This patch set is based Lukasz V3 CCF patchset, >> [PATCH v3 00/11] clk: Port Linux common clock framework [CCF] to >> U-boot (tag: 5.0-rc3) >> https://github.com/lmajewski/u-boot-dfu/commits/CCF-v3 >> >> Added a few fixes to Lukasz's v3 patchset. >> Introduced clk-gate/composite >> Added set rate support >> Per my understanding, U-Boot CCF will not support mux reparent, and >> support rate prograte setting to parent automatically. So new clk >> feature added follow this rule. >> >> There are many warnings when importing linux ccf code, I did not >> modify them all. >> >> The rest patches are for i.MX8MM, part of legacy clk code are still >> kept, because we are hard to enable CCF at very early stage, we set >> malloc space to DRAM when dram initialized in spl stage, so we have >> limited SRAM for uclass dm and dm clk, so keep the DRAM PLL related >> setting with legacy clk code which use small ram. >> >> The u-boot-spl.bin now is about 100KB without ddr firmware,usb stack >> and hab, >> so really large.. >> I am thinking what we could do to shrink the size, welcome any >> suggestions. >> >> Not expect this patchset could be merged, because of the CCF/clock code >> change, but since the clock part blocks i.MX8MM upstream, just would like >> to speed up the development with community and move on. >> >> Peng Fan (40): >> clk: correct get clk_x pointer >> clk: fixed-factor: fix get clk_fixed_factor >> clk: introduce clk_dev_binded >> clk: use clk_dev_binded >> clk-provider: sync more clk flags from Linux Kernel >> cmd: clk: print err value when clk_get_rate failed >> clk: mux: add set parent support >> clk: export mux/divider ops >> clk: add clk-gate support >> divider set rate supporrt >> clk: fixed_rate: export clk_fixed_rate >> clk: fixed_rate: add pre reloc flag >> clk: imx: import clk heplers >> clk: imx: gate2 add set rate >> linux: compat: guard PAGE_SIZE >> drivers: core: use strcmp when find device by name >> ddr: imx8m: fix ddr firmware location when enable SPL OF >> imx: add IMX8MQ kconfig entry >> imx: add IMX8MM kconfig entry >> imx: imx8mm: add clock bindings header >> imx: add i.MX8MM cpu type >> imx: spl: add spl_board_boot_device for i.MX8MM >> imx8m: update imx-regs for i.MX8MM >> imx: add get_cpu_rev support for i.MX8MM >> imx8m: rename clock to clock_imx8mq >> imx8m: restructure clock.h >> imx8m: add clk support for i.MX8MM >> imx8m: soc: probe clk before relocation >> imx8m: add pin header for i.MX8MM >> imx: add i.MX8MM PE property >> imx8m: Fix MMU table issue for OPTEE memory >> imx8m: set BYPASS ID SWAP to avoid AXI bus errors >> imx8m: soc: enable SCTR clock before timer init >> serial: Kconfig: make MXC_UART usable for MX7 and IMX8M >> clk: imx: add Kconfig entry for i.MX8MM >> clk: imx: add pll14xx driver >> clk: add composite clk support >> clk: imx: add i.MX8MM composite clk support >> clk: imx: add i.MX8MM clk driver >> imx: add i.MX8MM EVK board support >> >> Ye Li (1): >> imx8m: Configure trustzone region 0 for non-secure access >> >> arch/arm/dts/Makefile | 3 +- >> arch/arm/dts/imx8mm-evk-u-boot.dtsi | 92 + >> arch/arm/dts/imx8mm-evk.dts | 235 +++ >> arch/arm/dts/imx8mm-pinfunc.h | 629
Re: [U-Boot] [RFC PATCH v2] MLK-12883 usb: limit USB_MAX_XFER_BLK to 256
On 10.04.19 08:25, Marcel Ziswiler wrote: > Hi Lukasz > > On April 10, 2019 7:11:11 AM GMT+02:00, Lukasz Majewski wrote: >> On Tue, 9 Apr 2019 17:14:26 -0400 >> Tom Rini wrote: >> >>> On Tue, Apr 09, 2019 at 05:20:45PM +0200, Marcel Ziswiler wrote: >>> From: Peng Fan For Some USB mass storage devices, such as: " - Kingston DataTraveler 2.0 001D7D06CF09B04199C7B3EA - Class: (from Interface) Mass Storage - PacketSize: 64 Configurations: 1 - Vendor: 0x0930 Product 0x6545 Version 1.16 " When `usb read 0x8000 0 0x2000`, we met "EHCI timed out on TD - token=0x80008d80". The devices does not support scsi VPD page, we are not able to get the maximum transfer length for READ(10)/WRITE(10). So we limit this to 256 blocks as READ(6). Signed-off-by: Peng Fan Acked-by: Marcel Ziswiler (cherry picked from commit >> df0052575b2bc9d66ae73584768e1a457ed5d914) --- This comes from NXP's downstream and has proven to tremendously improve the situation with those odd USB mass storage aka memory sticks. This is why I post it here asking whether or not this may be something benefiting more people. Any feedback and suggestions are welcome. Changes in v2: - Fixed spelling in comment as suggested by Igor. common/usb_storage.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/common/usb_storage.c b/common/usb_storage.c index 8c889bb1a6..4e284645f5 100644 --- a/common/usb_storage.c +++ b/common/usb_storage.c @@ -949,7 +949,11 @@ static void usb_stor_set_max_xfer_blk(struct usb_device *udev, * there is enough free heap space left, but the SCSI READ(10) and * WRITE(10) commands are limited to 65535 blocks. */ - blk = USHRT_MAX; + /* + * Some USB mass storage devices have issues, limiting this to 256 >> >> Could you name those devices? > > You mean all of them? The Kingston DataTraveler 2.0 is already mentioned in > the commit message. Only for reference I want to add a link to a discussion from some years ago, that also names some devices that one of our customers found that didn't work with USB_MAX_XFER_BLK = 65536, but only with lower values: [1]. There's also a post with some benchmarking to get an idea of the impact on transfer speed when lowering USB_MAX_XFER_BLK: [2]. Regards, Frieder [1] https://lists.denx.de/pipermail/u-boot/2016-February/245893.html [2] https://lists.denx.de/pipermail/u-boot/2016-February/246267.html > + * fixes this. + */ + blk = 256; #else blk = 20; #endif -- 2.20.1 >>> >>> Adding in Lukasz now that get_maintainers.pl shows this should be >>> Cc'd to him as well, thanks! >>> >> >> >> >> >> Best regards, >> >> Lukasz Majewski >> >> -- >> >> DENX Software Engineering GmbH, Managing Director: Wolfgang Denk >> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany >> Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: >> lu...@denx.de > > Cheers > > Marcel > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] UBIFS mount bug when mounting from multiple MTD partitions
Hi, I have a customer who has a NAND device with two MTD partitions and each of the partitions contains one UBI volume with a UBIFS filesystem. Now U-Boot can mount the UBIFS from the first partition just fine, but if the UBIFS from the second partition is mounted afterwards this fails in some cases. I can reproduce the error and tracked it down to uboot_ubifs_mount() in fs/ubifs/super.c. If this function is run for the second mount, the struct ubifs_fs_type is reused and it contains a list fs_supers, that still holds one entry for the first mount. I guess, that if the second mount would happen on a volume that is on the same MTD partition as the first volume, than this will work. The second entry is added to ubifs_fs_type.fs_supers. In my case however, the second entry being added to ubifs_fs_type.fs_supers is invalid and causes the mount error. Reinitializing the list in uboot_ubifs_mount() before each mount, solves the problem, but I guess that it will cause failures in other setups, where there are actually multiple volumes on one MTD device. So how can I solve this properly? Do we need one instance of struct ubifs_fs_type for each MTD device? I tested this on an old version (2017.03), but looking at the current code, it looks like the same problem applies to current mainline. Thanks for any help and suggestions! Frieder ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] UBIFS mount bug when mounting from multiple MTD partitions
Hi Heiko,
On 10.04.19 14:44, Heiko Schocher wrote:
> Hello Frieder,
>
> Am 10.04.2019 um 12:49 schrieb Schrempf Frieder:
>> Hi,
>>
>> I have a customer who has a NAND device with two MTD partitions and
>> each > of the partitions contains one UBI volume with a UBIFS filesystem.
>
> Bad idea ... why?
>
> You may loose lifetime of the board, as UBI cannot use PEBs between the
> 2 MTD partitions on the nand ... better you would have one big MTD
> Partition
> with n ubi volumes in it ...
>
> But ... okay... this must work also.
Yeah, I only recently learned about the disadvantages of this setup.
Maybe we can change it in the future, but for now they are using
separate partitions.
>
>> Now U-Boot can mount the UBIFS from the first partition just fine, but
>> if the UBIFS from the second partition is mounted afterwards this fails
>> in some cases.
>
> :-(
>
>> I can reproduce the error and tracked it down to uboot_ubifs_mount() in
>> fs/ubifs/super.c. If this function is run for the second mount, the
>> struct ubifs_fs_type is reused and it contains a list fs_supers, that
>> still holds one entry for the first mount.
>
> Sure?
>
> fs_supers in struct file_system_type seems used only in none
> U-Boot code...
Right, I had a closer look and fs_supers seems to be unused indeed, but
somehow it causes corruption in my case. When I apply 5a08cfee3967
(ubifs: remove useless code) the problem disappears.
Without this patch there still is hlist_add_head(&s->s_instances,
&type->fs_supers) and this line somehow seems to cause the error.
I applied this debug diff:
--- a/fs/ubifs/super.c
+++ b/fs/ubifs/super.c
@@ -2428,7 +2428,15 @@ retry:
#else
strncpy(s->s_id, type->name, sizeof(s->s_id));
#endif
+ printf("%s:%d: ubi_num: %d, vol_id: %d\n",
+ __func__, __LINE__,
+ ((struct ubifs_info *)s->s_fs_info)->vi.ubi_num,
+ ((struct ubifs_info *)s->s_fs_info)->vi.vol_id);
hlist_add_head(&s->s_instances, &type->fs_supers);
+ printf("%s:%d: ubi_num: %d, vol_id: %d\n",
+ __func__, __LINE__,
+ ((struct ubifs_info *)s->s_fs_info)->vi.ubi_num,
+ ((struct ubifs_info *)s->s_fs_info)->vi.vol_id);
#ifndef __UBOOT__
spin_unlock(&sb_lock);
get_filesystem(type);
And I'm getting this for the first mount:
sget:2431: ubi_num: 0, vol_id: 0
sget:2433: ubi_num: 0, vol_id: 0
And this for the second mount:
sget:2431: ubi_num: 0, vol_id: 0
sget:2433: ubi_num: -1678121552, vol_id: -1678120656
>> I guess, that if the second mount would happen on a volume that is on
>> the same MTD partition as the first volume, than this will work. The
>> second entry is added to ubifs_fs_type.fs_supers.
>
> I cannot see this from looking into code ... so hard to say, but
> I only looked into mainline code ...
Yeah, I was probably wrong with these first wild guesses...
>
>> In my case however, the second entry being added to
>> ubifs_fs_type.fs_supers is invalid and causes the mount error.
>>
>> Reinitializing the list in uboot_ubifs_mount() before each mount, solves
>> the problem, but I guess that it will cause failures in other setups,
>> where there are actually multiple volumes on one MTD device.
>>
>> So how can I solve this properly? Do we need one instance of struct
>> ubifs_fs_type for each MTD device?
>
> Hmm.. without digging into it, it is difficult to say...
>
>> I tested this on an old version (2017.03), but looking at the current
>> code, it looks like the same problem applies to current mainline.
>
> Is there any chance to try it with current mainline ?
The problem is a bit strange and this what I'm actually worried about.
It is persistent in a certain environment: U-Boot loaded from SPI NOR,
environment set to certain values, data written to UBIFS partition in
Linux and then power-cut.
If one of these conditions changes, the error usually disappears, for
example if I use the exact same setup, but load the Bootloader from MMC
or RAM. Or if no write access with power-cut happens.
So I wonder if there's some memory corruption somewhere else. Though,
the error happens always at the same place. Debug prints or other code
changes have no influence.
I really would like to understand what's going on so I can make sure
that 5a08cfee3967 actually solves the real issue or just hides it.
Thanks,
Frieder
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] UBIFS mount bug when mounting from multiple MTD partitions
On 10.04.19 15:59, Heiko Schocher wrote:
> Hello Frieder,
>
> Am 10.04.2019 um 15:31 schrieb Schrempf Frieder:
>> Hi Heiko,
>>
>> On 10.04.19 14:44, Heiko Schocher wrote:
>>> Hello Frieder,
>>>
>>> Am 10.04.2019 um 12:49 schrieb Schrempf Frieder:
>>>> Hi,
>>>>
>>>> I have a customer who has a NAND device with two MTD partitions and
>>>> each > of the partitions contains one UBI volume with a UBIFS
>>>> filesystem.
>>>
>>> Bad idea ... why?
>>>
>>> You may loose lifetime of the board, as UBI cannot use PEBs between the
>>> 2 MTD partitions on the nand ... better you would have one big MTD
>>> Partition
>>> with n ubi volumes in it ...
>>>
>>> But ... okay... this must work also.
>>
>> Yeah, I only recently learned about the disadvantages of this setup.
>> Maybe we can change it in the future, but for now they are using
>> separate partitions.
>
> Ok.
>
>>>> Now U-Boot can mount the UBIFS from the first partition just fine, but
>>>> if the UBIFS from the second partition is mounted afterwards this fails
>>>> in some cases.
>>>
>>> :-(
>>>
>>>> I can reproduce the error and tracked it down to uboot_ubifs_mount() in
>>>> fs/ubifs/super.c. If this function is run for the second mount, the
>>>> struct ubifs_fs_type is reused and it contains a list fs_supers, that
>>>> still holds one entry for the first mount.
>>>
>>> Sure?
>>>
>>> fs_supers in struct file_system_type seems used only in none
>>> U-Boot code...
>>
>> Right, I had a closer look and fs_supers seems to be unused indeed, but
>> somehow it causes corruption in my case. When I apply 5a08cfee3967
>> (ubifs: remove useless code) the problem disappears.
>
> Ah, 5a08cfee3967 is in mainline ... good ;-)
>
>> Without this patch there still is hlist_add_head(&s->s_instances,
>> &type->fs_supers) and this line somehow seems to cause the error.
>>
>> I applied this debug diff:
>>
>> --- a/fs/ubifs/super.c
>> +++ b/fs/ubifs/super.c
>> @@ -2428,7 +2428,15 @@ retry:
>> #else
>> strncpy(s->s_id, type->name, sizeof(s->s_id));
>> #endif
>> + printf("%s:%d: ubi_num: %d, vol_id: %d\n",
>> + __func__, __LINE__,
>> + ((struct ubifs_info *)s->s_fs_info)->vi.ubi_num,
>> + ((struct ubifs_info *)s->s_fs_info)->vi.vol_id);
>> hlist_add_head(&s->s_instances, &type->fs_supers);
>> + printf("%s:%d: ubi_num: %d, vol_id: %d\n",
>> + __func__, __LINE__,
>> + ((struct ubifs_info *)s->s_fs_info)->vi.ubi_num,
>> + ((struct ubifs_info *)s->s_fs_info)->vi.vol_id);
>> #ifndef __UBOOT__
>> spin_unlock(&sb_lock);
>> get_filesystem(type);
>>
>> And I'm getting this for the first mount:
>>
>> sget:2431: ubi_num: 0, vol_id: 0
>> sget:2433: ubi_num: 0, vol_id: 0
>>
>> And this for the second mount:
>>
>> sget:2431: ubi_num: 0, vol_id: 0
>> sget:2433: ubi_num: -1678121552, vol_id: -1678120656
>
> Hmm...
>
>>>> I guess, that if the second mount would happen on a volume that is on
>>>> the same MTD partition as the first volume, than this will work. The
>>>> second entry is added to ubifs_fs_type.fs_supers.
>>>
>>> I cannot see this from looking into code ... so hard to say, but
>>> I only looked into mainline code ...
>>
>> Yeah, I was probably wrong with these first wild guesses...
>
> ;-)
>
>>>> In my case however, the second entry being added to
>>>> ubifs_fs_type.fs_supers is invalid and causes the mount error.
>>>>
>>>> Reinitializing the list in uboot_ubifs_mount() before each mount,
>>>> solves
>>>> the problem, but I guess that it will cause failures in other setups,
>>>> where there are actually multiple volumes on one MTD device.
>>>>
>>>> So how can I solve this properly? Do we need one instance of struct
>>>> ubifs_fs_type for each MTD device?
>>>
>>> Hmm.. without digging into it, it is difficult to say...
>>>
>>>> I tested this on an old version (2017.03), but looking at the current
>>>> code, it looks like the same problem applies to current mainline.
>>>
>>> Is
Re: [U-Boot] DM for ci_udc
Hi Sven, On 06.05.19 12:12, Sven Schwermer wrote: > Hi, > > I’m running into linking issues when enabling CONFIG_DM_USB_GADGET with > CONFIG_CI_UDC because dm_usb_gadget_handle_interrupts is not available. That > made me look into what’s required to port ci_udc to driver model. I have a > few conceptual questions about this: > > 1. Some other USB gadget drivers (dwc3-generic, ti-musb) seem to create a > wrapper driver that binds either the gadget or the host-mode driver to the > USB device, depending on the configured mode. Is this the desired approach? > > 2. I’m working with a i.MX6 (7) device so the host-mode driver is ehci-mx6, > but I’ve seen that ci_udc is also used with other host-mode drivers. How > would a wrapper work in this case where there are multiple possible host-mode > drivers but one gadget driver? > > 3. Any tips and hints are welcome :) Did you make any progress with getting ci_udc to work with DM in SPL on i.MX? The reason I'm asking is, that I need the SDP feature and I also want to use DM for USB. Thanks, Frieder ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Cannot boot mx6qsabred with 2019.07-rc2
On 23.05.19 19:07, Jagan Teki wrote:
> On Thu, May 23, 2019 at 10:18 PM Fabio Estevam wrote:
>>
>> On Thu, May 23, 2019 at 1:11 PM Jagan Teki
>> wrote:
>>
>>> Don't know whether this is SPL size issue or not? can you try
>>> SPL_OF_PLATDATA and TINY* I can see the size reduced with 64512 bytes
>>> (one build issue on fdtdec_get_int undefined)
>>
>> Yes, it does not build with CONFIG_SPL_OF_PLATDATA:
>>
>> lib/built-in.o: In function `fdtdec_parse_phandle_with_args':
>> /home/fabio/u-boot/lib/fdtdec.c:788: undefined reference to `fdtdec_get_int'
>
> Couldn't dig much here, would be happy someone can find this?
>
>> drivers/built-in.o: In function `fsl_esdhc_probe':
>> /home/fabio/u-boot/drivers/mmc/fsl_esdhc.c:1480: undefined reference
>> to `fdtdec_get_int'
>> /home/fabio/u-boot/drivers/mmc/fsl_esdhc.c:1482: undefined reference
>> to `fdtdec_get_int'
>> /home/fabio/u-boot/drivers/mmc/fsl_esdhc.c:1485: undefined reference
>
> These we can fix, by supporting platdata support into driver.
>
>> to `fdtdec_get_int'
>> scripts/Makefile.spl:404: recipe for target 'spl/u-boot-spl' failed
>> make[1]: *** [spl/u-boot-spl] Error 1
>>
>> Thanks for the suggestions, but at this point I prefer to go with the
>> removal of CONFIG_SPL_DM.
>
> We have 45 days to release, I think we can make these fixes quite
> normally what do you think? fsl_esdhc.c build I can mark a patch in
> few days if required.
>
>>
>> For 2019.07 it would be really nice if we could fix these two issues:
>>
>> 1. Allow to load a FIT image via Serial Download Protocol
>>
>> 2. Detect the SPL size overflow in build-time
>
> 1) We are working on this, 2) can be done.
As luck would have it, I needed to load a FIT via SDP today, so I came
up with a quick patch (see below). There are probably better ways to do
this, but it works.
#
commit 408b9d26eea48e6f85dd087750629f7a4095c73d
Author: Frieder Schrempf
Date: Thu May 23 14:52:47 2019 +0200
Allow SPL to load and boot FIT via SDP
diff --git a/common/spl/spl_sdp.c b/common/spl/spl_sdp.c
index 807256e908..8f990a83a3 100644
--- a/common/spl/spl_sdp.c
+++ b/common/spl/spl_sdp.c
@@ -25,10 +25,13 @@ static int spl_sdp_load_image(struct spl_image_info
*spl_image,
return -ENODEV;
}
- /* This command typically does not return but jumps to an image */
- sdp_handle(controller_index);
- pr_err("SDP ended\n");
+ /*
+* This command either loads a legacy image, jumps and never returns,
+* or it loads a FIT image and returns it to be handled by the SPL code.
+*/
+ ret = sdp_handle(controller_index, spl_image);
+ debug("SDP ended\n");
- return -EINVAL;
+ return ret;
}
SPL_LOAD_IMAGE_METHOD("USB SDP", 0, BOOT_DEVICE_BOARD,
spl_sdp_load_image);
diff --git a/drivers/usb/gadget/f_sdp.c b/drivers/usb/gadget/f_sdp.c
index ae97ab2b49..5690060a2f 100644
--- a/drivers/usb/gadget/f_sdp.c
+++ b/drivers/usb/gadget/f_sdp.c
@@ -638,7 +638,18 @@ static u32 sdp_jump_imxheader(void *address)
return 0;
}
-static void sdp_handle_in_ep(void)
+#ifdef CONFIG_SPL_LOAD_FIT
+static ulong sdp_fit_read(struct spl_load_info *load, ulong sector,
+ ulong count, void *buf)
+{
+ debug("%s: sector %lx, count %lx, buf %lx\n",
+ __func__, sector, count, (ulong)buf);
+ memcpy(buf, (void *)(load->dev + sector), count);
+ return count;
+}
+#endif
+
+static void sdp_handle_in_ep(struct spl_image_info *spl_image)
{
u8 *data = sdp_func->in_req->buf;
u32 status;
@@ -689,11 +700,25 @@ static void sdp_handle_in_ep(void)
/* If imx header fails, try some U-Boot specific headers */
if (status) {
+ image_header_t *header =
+ (void *)(u64)sdp_func->jmp_address;
#ifdef CONFIG_SPL_BUILD
+#ifdef CONFIG_SPL_LOAD_FIT
+ if (image_get_magic(header) == FDT_MAGIC) {
+ struct spl_load_info load;
+
+ printf("Found FIT\n");
+ load.dev = (void *)(u64)sdp_func->jmp_address;
+ load.bl_len = 1;
+ load.read = sdp_fit_read;
+ spl_load_simple_fit(spl_image, &load, 0,
+ header);
+ return;
+ }
+#endif
/* In SPL, allow jumps to U-Boot images */
struct spl_image_info spl_image = {};
- spl_parse_image_header(&spl_image,
- (struct image_header *)sdp_func->jmp_address);
+ spl_parse_image_header(&spl_image, header);
jump_to_image_no_args(&spl_image);
#else
/* In U-Boot, allow jumps to scripts */
@@ -715,19 +740,
Re: [U-Boot] Cannot boot mx6qsabred with 2019.07-rc2
Hi Fabio, On 23.05.19 19:45, Fabio Estevam wrote: > Hi Schrempf, > > On Thu, May 23, 2019 at 2:26 PM Schrempf Frieder > wrote: > >> As luck would have it, I needed to load a FIT via SDP today, so I came >> up with a quick patch (see below). There are probably better ways to do >> this, but it works. > > Thanks for your patch! > > I would like to give it a try, but it does not apply against U-Boot mainline. > > I manually applied it, but failed to build: > > cmd/usb_gadget_sdp.c: In function ‘do_sdp’: > cmd/usb_gadget_sdp.c:35:2: error: too few arguments to function ‘sdp_handle’ >sdp_handle(controller_index); Sorry, I just picked the patch from my messy working tree and it's based on 2019.04 and some other changes. > Could you please rebase it against U-Boot mainline and post it like a > formal patch? I need to do some rebasing and cleanup, but I'm definitely planning to send this as a patch for upstream. Thanks, Frieder ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] fsl_qspi: Improve QSPI driver to incorporate 4 byte commands
Hi Jagan,
On 29.05.19 13:06, Jagan Teki wrote:
> On Fri, Apr 26, 2019 at 6:12 PM Rajat Srivastava
> wrote:
>>
>> Previously, the SPI framework supported only 3-byte opcodes
>> but the FSL QSPI controller used to deal with flashes that
>> work with 4-byte opcodes. As a workaround to resolve this,
>> for every 3-byte opcodes sent by framework FSL QSPI driver
>> used to explicitly send corresponding 4-byte opcodes.
>>
>> Now the framework has been updated to send 4-byte opcodes
>> and FSL QSPI driver needs correction. This change will be
>> applicable for the following defconfig where we disable
>> CONFIG_FLASH_BAR:
>> LS1088A, LS1046A, LS1043A, LS1012A, LS2088A defconfigs
>>
>> Signed-off-by: Ashish Kumar
>> Signed-off-by: Rajat Srivastava
>> ---
>> Changes in v2:
>> - Update commit message
>> - Reduce patchset to one patch
>> - This patch is no more applicable:
>> https://patchwork.ozlabs.org/patch/1090122/
>>
>> drivers/spi/fsl_qspi.c | 45 +-
>> 1 file changed, 31 insertions(+), 14 deletions(-)
>>
>> diff --git a/drivers/spi/fsl_qspi.c b/drivers/spi/fsl_qspi.c
>> index 1598c4f698..217005f525 100644
>> --- a/drivers/spi/fsl_qspi.c
>> +++ b/drivers/spi/fsl_qspi.c
>> @@ -26,7 +26,8 @@ DECLARE_GLOBAL_DATA_PTR;
>> #define TX_BUFFER_SIZE 0x40
>> #endif
>>
>> -#define OFFSET_BITS_MASK GENMASK(23, 0)
>> +#define OFFSET_BITS_MASK GENMASK(27, 0)
>> +#define OFFSET_BITS_MASK_24GENMASK(23, 0)
>>
>> #define FLASH_STATUS_WEL 0x02
>>
>> @@ -754,7 +755,8 @@ static void qspi_op_erase(struct fsl_qspi_priv *priv)
>> while (qspi_read32(priv->flags, ®s->sr) & QSPI_SR_BUSY_MASK)
>> ;
>>
>> - if (priv->cur_seqid == QSPI_CMD_SE) {
>> + if ((priv->cur_seqid == QSPI_CMD_SE_4B) ||
>> + (priv->cur_seqid == QSPI_CMD_SE)) {
>> qspi_write32(priv->flags, ®s->ipcr,
>> (SEQID_SE << QSPI_IPCR_SEQID_SHIFT) | 0);
>> } else if (priv->cur_seqid == QSPI_CMD_BE_4K) {
>> @@ -775,31 +777,44 @@ int qspi_xfer(struct fsl_qspi_priv *priv, unsigned int
>> bitlen,
>> u32 txbuf;
>>
>> WATCHDOG_RESET();
>> -
>> if (dout) {
>> if (flags & SPI_XFER_BEGIN) {
>> priv->cur_seqid = *(u8 *)dout;
>> - memcpy(&txbuf, dout, 4);
>> + if (FSL_QSPI_FLASH_SIZE > SZ_16M && bytes > 4)
>> + memcpy(&txbuf, dout + 1, 4);
>> + else
>> + memcpy(&txbuf, dout, 4);
>> }
>>
>> if (flags == SPI_XFER_END) {
>> priv->sf_addr = wr_sfaddr;
>> - qspi_op_write(priv, (u8 *)dout, bytes);
>> - return 0;
>> + if (priv->cur_seqid == QSPI_CMD_PP ||
>> + priv->cur_seqid == QSPI_CMD_PP_4B ||
>> + priv->cur_seqid == QSPI_CMD_WRAR) {
>> + qspi_op_write(priv, (u8 *)dout, bytes);
>> + return 0;
>> + }
>> }
>>
>> - if (priv->cur_seqid == QSPI_CMD_FAST_READ ||
>> - priv->cur_seqid == QSPI_CMD_RDAR) {
>> + if ((priv->cur_seqid == QSPI_CMD_FAST_READ) ||
>> + (priv->cur_seqid == QSPI_CMD_FAST_READ_4B)) {
>> priv->sf_addr = swab32(txbuf) & OFFSET_BITS_MASK;
>> + } else if (priv->cur_seqid == QSPI_CMD_RDAR) {
>
> I wonder why we still have flash specific stuff handling, we have
> spi-mem like Linux. can't we handle these via spi-mem?
Sure we can. I started working on porting the Linux driver to U-Boot
some weeks ago, but didn't have time to continue with this recently.
See this branch for the current state:
https://github.com/fschrempf/u-boot/commits/fsl_qspi_spimem_port.
Regards,
Frieder
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH V3 0/5] add i.MX8 container loading support
On 22.07.19 04:12, Peng Fan wrote: > V3: > Drops patch 1/5 from V2, add 8QM support, nothing else changed. > Stefano, > This patchset was pending in patchwork for more that one month, > please consider to apply. I'm not the one to judge here and I don't know the rules for U-Boot, but only because they have been pending for a long time, doesn't make the patches more suitable for upstream. Even more so, if no one has reviewed them yet. > > V2: > Drop cleanup Makefile since V1, that patch is not correct. > Rebased on master > > The V2 version: > https://patchwork.ozlabs.org/cover/1118413/ > > The V1 version: > https://patchwork.ozlabs.org/cover/1096334/ > > This patchset is to support i.MX8 container loading from SPL, > i.MX8 AHAB secure boot not support FIT image, so we need to > use container image. > > Currently still use a fixed offset for the 2nd container(u-boot.cnt), > future patches will drop this fixed offset and use dynamaic offset > according to the size of 1st container for spl. > Only MMC is supported now, future patches will also support SPI/NOR/NAND > following similar style as mmc part, if the mmc part is ok. > > Based on the comments in https://patchwork.ozlabs.org/patch/1096336/ > So I think we have agreed the approach, the only comments that > not addressed from Lukasz is add doc for the container format. So why didn't you add some docs? I support Lukasz's request for a proper documentation in some README file. I found it already hard enough to find information about the current boot process of the i.MX8 and if you need to add even more complexity, please add docs before this gets merged. > The detailed format could be found in RM > https://www.nxp.com/docs/en/reference-manual/IMX8DQXPRM.pdf > Chapter 5.9.4 High Level Container Format > > CI: https://travis-ci.org/MrVan/u-boot/builds/547161366 > > Peng Fan (5): >imx8: support parsing i.MX8 Container file >spl: mmc: support loading i.MX container format file >imx: add container target >imx8qxp_mek: switch to use container image >imx8qm_mek: switch to use container image > > Makefile| 8 ++ > arch/arm/include/asm/arch-imx8/image.h | 56 +++ > arch/arm/mach-imx/Makefile | 14 ++- > arch/arm/mach-imx/imx8/Kconfig | 13 +++ > arch/arm/mach-imx/imx8/Makefile | 4 + > arch/arm/mach-imx/imx8/parse-container.c| 120 > > board/freescale/imx8qm_mek/README | 4 +- > board/freescale/imx8qm_mek/uboot-container.cfg | 13 +++ > board/freescale/imx8qxp_mek/README | 4 +- > board/freescale/imx8qxp_mek/uboot-container.cfg | 13 +++ > common/spl/spl_mmc.c| 10 ++ > configs/imx8qm_mek_defconfig| 8 +- > configs/imx8qxp_mek_defconfig | 5 +- > include/spl.h | 12 +++ > 14 files changed, 270 insertions(+), 14 deletions(-) > create mode 100644 arch/arm/include/asm/arch-imx8/image.h > create mode 100644 arch/arm/mach-imx/imx8/parse-container.c > create mode 100644 board/freescale/imx8qm_mek/uboot-container.cfg > create mode 100644 board/freescale/imx8qxp_mek/uboot-container.cfg > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH V3 0/5] add i.MX8 container loading support
On 22.07.19 10:08, Peng Fan wrote: >> Subject: Re: [U-Boot] [PATCH V3 0/5] add i.MX8 container loading support >> >> On 22.07.19 04:12, Peng Fan wrote: >>> V3: >>>Drops patch 1/5 from V2, add 8QM support, nothing else changed. >>>Stefano, >>>This patchset was pending in patchwork for more that one month, >>>please consider to apply. >> >> I'm not the one to judge here and I don't know the rules for U-Boot, but only >> because they have been pending for a long time, doesn't make the patches >> more suitable for upstream. Even more so, if no one has reviewed them yet. > > Since it was there long time, I just thought no one has comments. > >> >>> >>> V2: >>>Drop cleanup Makefile since V1, that patch is not correct. >>>Rebased on master >>> >>> The V2 version: >>> >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch >> work.ozlabs.org%2Fcover%2F1118413%2F&data=02%7C01%7Cpeng.fan >> %40nxp.com%7C87ccfec5031249de3fde08d70e77fa9a%7C686ea1d3bc2b4c >> 6fa92cd99c5c301635%7C0%7C1%7C636993780782660409&sdata=xUcj >> AnqE2WHa2yPppBDx2Og8yv8McyWEaULsJOEzNmk%3D&reserved=0 >>> >>> The V1 version: >>> >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch >> work.ozlabs.org%2Fcover%2F1096334%2F&data=02%7C01%7Cpeng.fan >> %40nxp.com%7C87ccfec5031249de3fde08d70e77fa9a%7C686ea1d3bc2b4c >> 6fa92cd99c5c301635%7C0%7C1%7C636993780782660409&sdata=o4 >> Wbxso8J5HuHlvMvnuKsNK8rDFUSEtItv0Yh0ITeQg%3D&reserved=0 >>> >>> This patchset is to support i.MX8 container loading from SPL, >>> i.MX8 AHAB secure boot not support FIT image, so we need to >>> use container image. >>> >>> Currently still use a fixed offset for the 2nd container(u-boot.cnt), >>> future patches will drop this fixed offset and use dynamaic offset >>> according to the size of 1st container for spl. >>> Only MMC is supported now, future patches will also support >> SPI/NOR/NAND >>> following similar style as mmc part, if the mmc part is ok. >>> >>> Based on the comments in >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch >> work.ozlabs.org%2Fpatch%2F1096336%2F&data=02%7C01%7Cpeng.fan >> %40nxp.com%7C87ccfec5031249de3fde08d70e77fa9a%7C686ea1d3bc2b4c >> 6fa92cd99c5c301635%7C0%7C1%7C636993780782660409&sdata=8aH >> Hmlu%2FZ6g6h20k%2BxIOrPfk3kG4yzwTE93aRucQ%2FCY%3D&reserve >> d=0 >>> So I think we have agreed the approach, the only comments that >>> not addressed from Lukasz is add doc for the container format. >> >> So why didn't you add some docs? I support Lukasz's request for a proper >> documentation in some README file. I found it already hard enough to >> find information about the current boot process of the i.MX8 and if you >> need to add even more complexity, please add docs before this gets merged. > > Not sure you are working i.MX8 and i.MX8M both. Or just i.MX8M. > There is a README in the i.MX8QM/QXP board file shows the steps to build > images. > Or you wanna me to put the container format from Reference Manual > to U-Boot? For now I'm only working on i.MX8M. But if I ever would need to work on i.MX8, I would be glad to have a proper documentation of how the container format is used in U-Boot and what happens while booting. What happens in the different stages, which image is copied to what address and things like that. Thanks, Frieder > > Regards, > Peng. >> >>> The detailed format could be found in RM >>> >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. >> nxp.com%2Fdocs%2Fen%2Freference-manual%2FIMX8DQXPRM.pdf&da >> ta=02%7C01%7Cpeng.fan%40nxp.com%7C87ccfec5031249de3fde08d70e77f >> a9a%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C636993780782 >> 660409&sdata=PMOVoEX30qwR3XDPBThWFWTU7qqFaaC6SyykGweIi2 >> E%3D&reserved=0 >>> Chapter 5.9.4 High Level Container Format >>> >>> CI: >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftravis- >> ci.org%2FMrVan%2Fu-boot%2Fbuilds%2F547161366&data=02%7C01%7 >> Cpeng.fan%40nxp.com%7C87ccfec5031249de3fde08d70e77fa9a%7C686ea1 >> d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C636993780782660409&s >> data=oPp3%2FyB2kpHj4sxi5n1xWPnf21foJ%2FroU21UXskqijM%3D&res >> erved=0 >>> >>> Peng Fan (5): >>> imx8: support parsing i.MX8 Container file >>> spl: mmc: support loading i.MX container format file >>> imx: add container target >>> imx8qxp_mek: switch to use container image >>> imx8qm_mek: switch to use container image >>> >>>Makefile| 8 ++ >>>arch/arm/include/asm/arch-imx8/image.h | 56 >> +++ >>>arch/arm/mach-imx/Makefile | 14 ++- >>>arch/arm/mach-imx/imx8/Kconfig | 13 +++ >>>arch/arm/mach-imx/imx8/Makefile | 4 + >>>arch/arm/mach-imx/imx8/parse-container.c| 120 >> >>>board/freescale/imx8qm_mek/README | 4 +- >>>board/freescale/imx8qm_mek/uboot-container.cfg | 13 +++ >>>board
Re: [U-Boot] [PATCH 1/4] imx: add module fuse support
Hi Lukasz,
On 24.07.19 14:12, Peng Fan wrote:
> Hi Lukasz,
>
>> Subject: Re: [U-Boot] [PATCH 1/4] imx: add module fuse support
>>
>> Hi Peng,
>>
>>> Hi Lukasz,
>>>
Subject: Re: [U-Boot] [PATCH 1/4] imx: add module fuse support
Hi Peng,
> There are different parts from one SoC. Take i.MX6ULL for example,
> some part might not have ENET, some might have; some might not
> have USB, some might have. The information could be got from
> OCOTP, to make one image support the different parts, we need
> runtime disable linux kernel dts node and uboot driver probe if
> the corresponding module not exists in the part.
If I understand correctly the concept is interesting to make the
final binary smaller.
>>>
>>> No. This is to use one image to support multiple parts of a same kind
>>> SoC. So this patch will make the uboot image size larger.
>>>
>>> As described in commit log, some i.MX6UL parts not have enet, some
>>> have Enet,
>>
>> Is there any markings on the SoC? (like MX6ULXX) which indicates which
>> SoC has enet and which doesn't have one?
Yes, you can look in the datasheets. For i.MX6ULL ([1], [2]) for
example, there is a table in chapter 1.1, which describes the features
for the different types and the corresponding part numbers. And the part
numbers are printed on the chips.
Regards,
Frieder
[1] https://www.nxp.com/docs/en/data-sheet/IMX6ULLCEC.pdf
[2] https://www.nxp.com/docs/en/data-sheet/IMX6ULLIEC.pdf
>
> I do not have that marketing information. We just have the information
> that to use fuse to indicate whether the module is there.
>
> Regards,
> Peng.
>
>>
>>> so we need find a method to make the same image could work on the two
>>> parts, that is what this patch does.
>>
>> Ok. Thanks for explanation.
>>
>>>
>>> Thanks,
>>> Peng.
>>>
>
> Signed-off-by: Peng Fan
> ---
> arch/arm/include/asm/mach-imx/module_fuse.h | 127 +++
> arch/arm/include/asm/mach-imx/sys_proto.h | 1 +
> arch/arm/mach-imx/Kconfig | 7 +
> arch/arm/mach-imx/mx6/Makefile | 1 +
> arch/arm/mach-imx/mx6/module_fuse.c | 322
> 5 files changed, 458 insertions(+)
> create mode 100644
>> arch/arm/include/asm/mach-imx/module_fuse.h
> create mode 100644 arch/arm/mach-imx/mx6/module_fuse.c
>
> diff --git a/arch/arm/include/asm/mach-imx/module_fuse.h
> b/arch/arm/include/asm/mach-imx/module_fuse.h new file mode
>> 100644
> index 00..6b93f0402e
> --- /dev/null
> +++ b/arch/arm/include/asm/mach-imx/module_fuse.h
> @@ -0,0 +1,127 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Copyright 2019 NXP
> + */
> +
> +#ifndef __MODULE_FUSE_H__
> +#define __MODULE_FUSE_H__
> +
> +enum fuse_module_type {
> + MODULE_TSC,
> + MODULE_ADC1,
> + MODULE_ADC2,
> + MODULE_SIM1,
> + MODULE_SIM2,
> + MODULE_FLEXCAN1,
> + MODULE_FLEXCAN2,
> + MODULE_SPDIF,
> + MODULE_EIM,
> + MODULE_SD1,
> + MODULE_SD2,
> + MODULE_SD3,
> + MODULE_SD4,
> + MODULE_QSPI1,
> + MODULE_QSPI2,
> + MODULE_GPMI,
> + MODULE_APBHDMA,
> + MODULE_LCDIF,
> + MODULE_PXP,
> + MODULE_CSI,
> + MODULE_ENET1,
> + MODULE_ENET2,
> + MODULE_CAAM,
> + MODULE_USB_OTG1,
> + MODULE_USB_OTG2,
> + MODULE_SAI2,
> + MODULE_SAI3,
> + MODULE_BEE,
> + MODULE_UART1,
> + MODULE_UART2,
> + MODULE_UART3,
> + MODULE_UART4,
> + MODULE_UART5,
> + MODULE_UART6,
> + MODULE_UART7,
> + MODULE_UART8,
> + MODULE_PWM5,
> + MODULE_PWM6,
> + MODULE_PWM7,
> + MODULE_PWM8,
> + MODULE_ECSPI1,
> + MODULE_ECSPI2,
> + MODULE_ECSPI3,
> + MODULE_ECSPI4,
> + MODULE_ECSPI5,
> + MODULE_I2C1,
> + MODULE_I2C2,
> + MODULE_I2C3,
> + MODULE_I2C4,
> + MODULE_GPT1,
> + MODULE_GPT2,
> + MODULE_EPIT1,
> + MODULE_EPIT2,
> + MODULE_EPDC,
> + MODULE_ESAI,
> + MODULE_DCP,
> + MODULE_DCP_CRYPTO,
> +};
> +
> +struct fuse_entry_desc {
> + enum fuse_module_type module;
> + const char *node_path;
> + u32 fuse_word_offset;
> + u32 fuse_bit_offset;
> + u32 status;
> +};
> +
> +#if !IS_ENABLED(CONFIG_IMX_MODULE_FUSE)
> +static inline u32 check_module_fused(enum fuse_module_type
> module) {
> + return 0;
> +};
> +
> +static inline u32 esdhc_fused(u32 base_addr) {
> + return 0;
> +};
> +
> +static inline u32 ecspi_fused(u32 base_addr) {
> + return 0;
> +};
> +
> +static inline u32 uart_fused(u32 base_addr) {
> + return 0;
> +};
> +
> +static inline u32 usb_fused(u32 base_addr) {
> + return 0;
> +};
> +
> +static inline u32 qspi_fused(u32 base_addr) {
> + return 0;
> +};
> +
> +static inline u32 i2c_fu
Re: [U-Boot] [PATCH] i2c: mxc: add CONFIG_CLK support
Hi Peng,
On 06.08.19 12:09, Peng Fan wrote:
> When CONFIG_CLK enabled, use CLK UCLASS for clk related settings.
>
> Signed-off-by: Peng Fan
> ---
> arch/arm/include/asm/mach-imx/mxc_i2c.h | 6 ++
> drivers/i2c/mxc_i2c.c | 17 +
> 2 files changed, 23 insertions(+)
>
> diff --git a/arch/arm/include/asm/mach-imx/mxc_i2c.h
> b/arch/arm/include/asm/mach-imx/mxc_i2c.h
> index 8e1ea9af19..81fd981444 100644
> --- a/arch/arm/include/asm/mach-imx/mxc_i2c.h
> +++ b/arch/arm/include/asm/mach-imx/mxc_i2c.h
> @@ -6,6 +6,9 @@
> #define __ASM_ARCH_MXC_MXC_I2C_H__
> #include
> #include
> +#if CONFIG_IS_ENABLED(CLK)
> +#include
> +#endif
>
> struct i2c_pin_ctrl {
> iomux_v3_cfg_t i2c_mode;
> @@ -47,6 +50,9 @@ struct mxc_i2c_bus {
> ulong driver_data;
> int speed;
> struct i2c_pads_info *pads_info;
> +#if CONFIG_IS_ENABLED(CLK)
> + struct clk per_clk;
> +#endif
> #ifndef CONFIG_DM_I2C
> int (*idle_bus_fn)(void *p);
> void *idle_bus_data;
> diff --git a/drivers/i2c/mxc_i2c.c b/drivers/i2c/mxc_i2c.c
> index 23119cce65..2e157bca58 100644
> --- a/drivers/i2c/mxc_i2c.c
> +++ b/drivers/i2c/mxc_i2c.c
I already commented on a previous version of this patch and the
following change is still missing here:
@@ -149,7 +149,11 @@ static uint8_t i2c_imx_get_clk(struct mxc_i2c_bus
*i2c_bus, unsigned int rate)
#endif
/* Divider value calculation */
+#if CONFIG_IS_ENABLED(CLK)
+ i2c_clk_rate = clk_get_rate(&i2c_bus->per_clk);
+#else
i2c_clk_rate = mxc_get_clock(MXC_I2C_CLK);
+#endif
div = (i2c_clk_rate + rate - 1) / rate;
if (div < i2c_clk_div[0][0])
clk_div = 0;
Regards,
Frieder
> @@ -890,9 +890,22 @@ static int mxc_i2c_probe(struct udevice *bus)
> i2c_bus->bus = bus;
>
> /* Enable clk */
> +#if CONFIG_IS_ENABLED(CLK)
> + ret = clk_get_by_index(bus, 0, &i2c_bus->per_clk);
> + if (ret) {
> + printf("Failed to get i2c clk\n");
> + return ret;
> + }
> + ret = clk_enable(&i2c_bus->per_clk);
> + if (ret) {
> + printf("Failed to enable i2c clk\n");
> + return ret;
> + }
> +#else
> ret = enable_i2c_clk(1, bus->seq);
> if (ret < 0)
> return ret;
> +#endif
>
> /*
>* See Documentation/devicetree/bindings/i2c/i2c-imx.txt
> @@ -919,7 +932,11 @@ static int mxc_i2c_probe(struct udevice *bus)
> ret = i2c_idle_bus(i2c_bus);
> if (ret < 0) {
> /* Disable clk */
> +#if CONFIG_IS_ENABLED(CLK)
> + clk_disable(&i2c_bus->per_clk);
> +#else
> enable_i2c_clk(0, bus->seq);
> +#endif
> return ret;
> }
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 01/22] tools: imx8m_image: align spl bin image size
Hi Peng, On 09.08.19 06:14, Peng Fan wrote: > Align spl bin image size to 4 byte aligned, because we need > to pad ddr firmware in the end of spl bin. However when enable > SPL OF, the spl dtb will be padded to u-boot-nodtb.bin, then > u-boot-spl.bin size might not be 4 bytes aligned. > > ddr_load_train_firmware in drivers/ddr/imx/imx8m/helper.c use 4 bytes > aligned address to load ddr firmware, so we need make sure > u-boot-spl.bin is 4 bytes aligned, in this patch we use dd > to create a new file named u-boot-spl-pad.bin, then pad ddr firmware. > > If SPL OF not enabled, this patch not hurt, because `_end` already > is 4 bytes aligned. Can you please try to make full English sentences at least? Like "subject verb object": If SPL *is* not enabled, this patch *does* not hurt, ... Also your explanations are very difficult to understand for someone who will read the commit message. I would have used something like this: """ The loader for the DDR firmware in drivers/ddr/imx/imx8m/helper.c uses a 4-byte-aligned address to load the firmware. In cases where OF is enabled in SPL the dtb will be appended to the SPL binary and can result in a binary that is not aligned correctly. If OF is not enabled in SPL, `_end` is already aligned correctly, but this patch does not hurt. To ensure the correct alignment we use dd to create a temporary file u-boot-spl-pad.bin with the correct padding. """ > > Signed-off-by: Peng Fan With a better commit message: Reviewed-by: Frieder Schrempf Tested-by: Frieder Schrempf Thanks, Frieder > --- > tools/imx8m_image.sh | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/tools/imx8m_image.sh b/tools/imx8m_image.sh > index ec0881a128..08a6a48180 100755 > --- a/tools/imx8m_image.sh > +++ b/tools/imx8m_image.sh > @@ -35,8 +35,9 @@ if [ $post_process = 1 ]; then > objcopy -I binary -O binary --pad-to 0x8000 --gap-fill=0x0 > $srctree/lpddr4_pmu_train_2d_imem.bin lpddr4_pmu_train_2d_imem_pad.bin > cat lpddr4_pmu_train_1d_imem_pad.bin > lpddr4_pmu_train_1d_dmem_pad.bin > lpddr4_pmu_train_1d_fw.bin > cat lpddr4_pmu_train_2d_imem_pad.bin > $srctree/lpddr4_pmu_train_2d_dmem.bin > lpddr4_pmu_train_2d_fw.bin > - cat spl/u-boot-spl.bin lpddr4_pmu_train_1d_fw.bin > lpddr4_pmu_train_2d_fw.bin > spl/u-boot-spl-ddr.bin > - rm -f lpddr4_pmu_train_1d_fw.bin lpddr4_pmu_train_2d_fw.bin > lpddr4_pmu_train_1d_imem_pad.bin lpddr4_pmu_train_1d_dmem_pad.bin > lpddr4_pmu_train_2d_imem_pad.bin > + dd if=spl/u-boot-spl.bin of=spl/u-boot-spl-pad.bin bs=4 > conv=sync > + cat spl/u-boot-spl-pad.bin lpddr4_pmu_train_1d_fw.bin > lpddr4_pmu_train_2d_fw.bin > spl/u-boot-spl-ddr.bin > + rm -f lpddr4_pmu_train_1d_fw.bin lpddr4_pmu_train_2d_fw.bin > lpddr4_pmu_train_1d_imem_pad.bin lpddr4_pmu_train_1d_dmem_pad.bin > lpddr4_pmu_train_2d_imem_pad.bin spl/u-boot-spl-pad.bin > fi > fi > > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 02/22] ddr: imx8m: fix ddr firmware location when enable SPL OF
On 09.08.19 06:14, Peng Fan wrote:
> With SPL_OF_SPERATE, the device tree will be padded to
^ Do you mean CONFIG_SPL_OF_CONTROL?
> end of the u-boot-spl-nodtb.bin, however we also put
> the ddr firmware file to this location, so need to adapt
> the code with SPL OF and align to 16bytes to ease copy firmware.
^ I think this should be 4 bytes
>
> Signed-off-by: Peng Fan
I think this patch should be merged with the previous one (01/22),
because if one is applied without the other it would break things.
> ---
> drivers/ddr/imx/imx8m/helper.c | 12 +++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/ddr/imx/imx8m/helper.c b/drivers/ddr/imx/imx8m/helper.c
> index 61cd4f6db1..3e605353ea 100644
> --- a/drivers/ddr/imx/imx8m/helper.c
> +++ b/drivers/ddr/imx/imx8m/helper.c
> @@ -31,7 +31,17 @@ void ddr_load_train_firmware(enum fw_type type)
> unsigned long pr_to32, pr_from32;
> unsigned long fw_offset = type ? IMEM_2D_OFFSET : 0;
> unsigned long imem_start = (unsigned long)&_end + fw_offset;
> - unsigned long dmem_start = imem_start + IMEM_LEN;
> + unsigned long dmem_start;
> +
> +#ifdef CONFIG_SPL_OF_CONTROL
> + if (gd->fdt_blob && !fdt_check_header(gd->fdt_blob)) {
> + imem_start = roundup((unsigned long)&_end +
> + fdt_totalsize(gd->fdt_blob), 4) +
> + fw_offset;
> + }
> +#endif
> +
> + dmem_start = imem_start + IMEM_LEN;
>
> pr_from32 = imem_start;
> pr_to32 = DDR_TRAIN_CODE_BASE_ADDR + 4 * IMEM_OFFSET_ADDR;
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 03/22] imx8m: add image cfg for i.MX8MM lpddr4
On 09.08.19 06:14, Peng Fan wrote: > There is no HDMI on i.MX8MM, so we need to remove HDMI entry, then > we could not reuse imximage.cfg, so create a new one. > > Signed-off-by: Peng Fan > --- > arch/arm/mach-imx/imx8m/imximage-8mm-lpddr4.cfg | 16 > 1 file changed, 16 insertions(+) > create mode 100644 arch/arm/mach-imx/imx8m/imximage-8mm-lpddr4.cfg > > diff --git a/arch/arm/mach-imx/imx8m/imximage-8mm-lpddr4.cfg > b/arch/arm/mach-imx/imx8m/imximage-8mm-lpddr4.cfg > new file mode 100644 > index 00..1a2e43e671 > --- /dev/null > +++ b/arch/arm/mach-imx/imx8m/imximage-8mm-lpddr4.cfg > @@ -0,0 +1,16 @@ > +/* SPDX-License-Identifier: GPL-2.0+ */ > +/* > + * Copyright 2019 NXP > + */ > + > +#define __ASSEMBLY__ > + > +FIT > +BOOT_FROMsd > +LOADER spl/u-boot-spl-ddr.bin 0x7E1000 > +SECOND_LOADERu-boot.itb 0x4020 0x6 What's the reason behind putting the u-boot.itb inside the imx image? I think it would be better to have an imx image that contains only the SPL and can be put on MMC, flash or loaded via serial loader. The raw u-boot.itb can easily be put to the correct location in MMC, flash or RAM by itself, without being included in the imx image. My current implementation for my custom board uses a custom imximage.cfg with the SECOND_LOADER entry removed to achieve this. > + > +DDR_FW lpddr4_pmu_train_1d_imem.bin > +DDR_FW lpddr4_pmu_train_1d_dmem.bin > +DDR_FW lpddr4_pmu_train_2d_imem.bin > +DDR_FW lpddr4_pmu_train_2d_dmem.bin What's the reason for specifying the firmware files here? As far as I can see, the DDR_FW entries are not handled by imx8mimage.c in any way. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 02/22] ddr: imx8m: fix ddr firmware location when enable SPL OF
On 14.08.19 09:59, Peng Fan wrote:
> Hi,
>
>> Subject: Re: [PATCH 02/22] ddr: imx8m: fix ddr firmware location when enable
>> SPL OF
>>
>> On 09.08.19 06:14, Peng Fan wrote:
>>> With SPL_OF_SPERATE, the device tree will be padded to
>>
>> ^ Do you mean CONFIG_SPL_OF_CONTROL?
> Yes. Thanks.
>>
>>> end of the u-boot-spl-nodtb.bin, however we also put the ddr firmware
>>> file to this location, so need to adapt the code with SPL OF and align
>>> to 16bytes to ease copy firmware.
>>
>> ^ I think this should be 4 bytes
> Yes.
>
>>
>>>
>>> Signed-off-by: Peng Fan
>>
>> I think this patch should be merged with the previous one (01/22), because if
>> one is applied without the other it would break things.
>
> Currently only i.MX8MQ EVK is using the code, i.MX8MQ not enable SPL OF,
> so it will not break things.
Ok, so with the changes to the commit message above:
Reviewed-by: Frieder Schrempf
Tested-by: Frieder Schrempf
>
> Thanks,
> Peng.
>
>>
>>> ---
>>>drivers/ddr/imx/imx8m/helper.c | 12 +++-
>>>1 file changed, 11 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/ddr/imx/imx8m/helper.c
>>> b/drivers/ddr/imx/imx8m/helper.c index 61cd4f6db1..3e605353ea 100644
>>> --- a/drivers/ddr/imx/imx8m/helper.c
>>> +++ b/drivers/ddr/imx/imx8m/helper.c
>>> @@ -31,7 +31,17 @@ void ddr_load_train_firmware(enum fw_type type)
>>> unsigned long pr_to32, pr_from32;
>>> unsigned long fw_offset = type ? IMEM_2D_OFFSET : 0;
>>> unsigned long imem_start = (unsigned long)&_end + fw_offset;
>>> - unsigned long dmem_start = imem_start + IMEM_LEN;
>>> + unsigned long dmem_start;
>>> +
>>> +#ifdef CONFIG_SPL_OF_CONTROL
>>> + if (gd->fdt_blob && !fdt_check_header(gd->fdt_blob)) {
>>> + imem_start = roundup((unsigned long)&_end +
>>> +fdt_totalsize(gd->fdt_blob), 4) +
>>> + fw_offset;
>>> + }
>>> +#endif
>>> +
>>> + dmem_start = imem_start + IMEM_LEN;
>>>
>>> pr_from32 = imem_start;
>>> pr_to32 = DDR_TRAIN_CODE_BASE_ADDR + 4 *
>> IMEM_OFFSET_ADDR;
>>>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] i2c: mxc: add CONFIG_CLK support
On 13.08.19 10:05, Peng Fan wrote:
> Hi Frieder
>
>> Subject: [PATCH v2] i2c: mxc: add CONFIG_CLK support
>>
>> When CONFIG_CLK enabled, use CLK UCLASS for clk related settings.
>
> Are you fine with this patch?
Yes!
Reviewed-by: Frieder Schrempf
Tested-by: Frieder Schrempf
>
> Thanks,
> Peng.
>
>>
>> Signed-off-by: Peng Fan
>> ---
>>
>> V2:
>> use clk_get_rate when getting i2c per clk rate with CLK UCLASS
>>
>> arch/arm/include/asm/mach-imx/mxc_i2c.h | 6 ++
>> drivers/i2c/mxc_i2c.c | 22
>> ++
>> 2 files changed, 28 insertions(+)
>>
>> diff --git a/arch/arm/include/asm/mach-imx/mxc_i2c.h
>> b/arch/arm/include/asm/mach-imx/mxc_i2c.h
>> index 8e1ea9af19..81fd981444 100644
>> --- a/arch/arm/include/asm/mach-imx/mxc_i2c.h
>> +++ b/arch/arm/include/asm/mach-imx/mxc_i2c.h
>> @@ -6,6 +6,9 @@
>> #define __ASM_ARCH_MXC_MXC_I2C_H__
>> #include
>> #include
>> +#if CONFIG_IS_ENABLED(CLK)
>> +#include
>> +#endif
>>
>> struct i2c_pin_ctrl {
>> iomux_v3_cfg_t i2c_mode;
>> @@ -47,6 +50,9 @@ struct mxc_i2c_bus {
>> ulong driver_data;
>> int speed;
>> struct i2c_pads_info *pads_info;
>> +#if CONFIG_IS_ENABLED(CLK)
>> +struct clk per_clk;
>> +#endif
>> #ifndef CONFIG_DM_I2C
>> int (*idle_bus_fn)(void *p);
>> void *idle_bus_data;
>> diff --git a/drivers/i2c/mxc_i2c.c b/drivers/i2c/mxc_i2c.c index
>> 23119cce65..8d6b4650ff 100644
>> --- a/drivers/i2c/mxc_i2c.c
>> +++ b/drivers/i2c/mxc_i2c.c
>> @@ -149,7 +149,12 @@ static uint8_t i2c_imx_get_clk(struct mxc_i2c_bus
>> *i2c_bus, unsigned int rate) #endif
>>
>> /* Divider value calculation */
>> +#if CONFIG_IS_ENABLED(CLK)
>> +i2c_clk_rate = clk_get_rate(&i2c_bus->per_clk); #else
>> i2c_clk_rate = mxc_get_clock(MXC_I2C_CLK);
>> +#endif
>> +
>> div = (i2c_clk_rate + rate - 1) / rate;
>> if (div < i2c_clk_div[0][0])
>> clk_div = 0;
>> @@ -890,9 +895,22 @@ static int mxc_i2c_probe(struct udevice *bus)
>> i2c_bus->bus = bus;
>>
>> /* Enable clk */
>> +#if CONFIG_IS_ENABLED(CLK)
>> +ret = clk_get_by_index(bus, 0, &i2c_bus->per_clk);
>> +if (ret) {
>> +printf("Failed to get i2c clk\n");
>> +return ret;
>> +}
>> +ret = clk_enable(&i2c_bus->per_clk);
>> +if (ret) {
>> +printf("Failed to enable i2c clk\n");
>> +return ret;
>> +}
>> +#else
>> ret = enable_i2c_clk(1, bus->seq);
>> if (ret < 0)
>> return ret;
>> +#endif
>>
>> /*
>> * See Documentation/devicetree/bindings/i2c/i2c-imx.txt
>> @@ -919,7 +937,11 @@ static int mxc_i2c_probe(struct udevice *bus)
>> ret = i2c_idle_bus(i2c_bus);
>> if (ret < 0) {
>> /* Disable clk */
>> +#if CONFIG_IS_ENABLED(CLK)
>> +clk_disable(&i2c_bus->per_clk);
>> +#else
>> enable_i2c_clk(0, bus->seq);
>> +#endif
>> return ret;
>> }
>>
>> --
>> 2.16.4
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 20/22] arm: dts: import i.MX8MM dtsi
On 09.08.19 06:15, Peng Fan wrote:
> Import i.MX8MM dtsi from Linux Kernel,
> commit <0a8ad0ffa4d8> ("Merge tag 'for-linus-5.3-ofs1' of
> git://git.kernel.org/pub/scm/linux/kernel/git/hubcap/linux")
>
> Signed-off-by: Peng Fan
> ---
> arch/arm/dts/imx8mm.dtsi | 733
> +++
> 1 file changed, 733 insertions(+)
> create mode 100644 arch/arm/dts/imx8mm.dtsi
>
> diff --git a/arch/arm/dts/imx8mm.dtsi b/arch/arm/dts/imx8mm.dtsi
> new file mode 100644
> index 00..6b407a94c0
> --- /dev/null
> +++ b/arch/arm/dts/imx8mm.dtsi
[...]
> +
> + usdhc1: mmc@30b4 {
> + compatible = "fsl,imx8mm-usdhc",
> "fsl,imx7d-usdhc";
> + reg = <0x30b4 0x1>;
> + interrupts = ;
> + clocks = <&clk IMX8MM_CLK_DUMMY>,
> + <&clk IMX8MM_CLK_NAND_USDHC_BUS>,
> + <&clk IMX8MM_CLK_USDHC1_ROOT>;
> + clock-names = "ipg", "ahb", "per";
> + assigned-clocks = <&clk IMX8MM_CLK_USDHC1>;
> + assigned-clock-rates = <4>;
> + fsl,tuning-start-tap = <20>;
> + fsl,tuning-step= <2>;
> + bus-width = <4>;
> + status = "disabled";
> + };
> +
> + usdhc2: mmc@30b5 {
> + compatible = "fsl,imx8mm-usdhc",
> "fsl,imx7d-usdhc";
> + reg = <0x30b5 0x1>;
> + interrupts = ;
> + clocks = <&clk IMX8MM_CLK_DUMMY>,
> + <&clk IMX8MM_CLK_NAND_USDHC_BUS>,
> + <&clk IMX8MM_CLK_USDHC2_ROOT>;
> + clock-names = "ipg", "ahb", "per";
I know this has been copied from Linux, but I wonder why the
'assigned-clocks' and 'assigned-clock-rates' are missing here, while
they exist for usdhc1 and usdhc3.
The SD-card connected to usdhc2 on my board works without it, though.
> + fsl,tuning-start-tap = <20>;
> + fsl,tuning-step= <2>;
> + bus-width = <4>;
> + status = "disabled";
> + };
> +
> + usdhc3: mmc@30b6 {
> + compatible = "fsl,imx8mm-usdhc",
> "fsl,imx7d-usdhc";
> + reg = <0x30b6 0x1>;
> + interrupts = ;
> + clocks = <&clk IMX8MM_CLK_DUMMY>,
> + <&clk IMX8MM_CLK_NAND_USDHC_BUS>,
> + <&clk IMX8MM_CLK_USDHC3_ROOT>;
> + clock-names = "ipg", "ahb", "per";
> + assigned-clocks = <&clk IMX8MM_CLK_USDHC3_ROOT>;
> + assigned-clock-rates = <4>;
> + fsl,tuning-start-tap = <20>;
> + fsl,tuning-step= <2>;
> + bus-width = <4>;
> + status = "disabled";
> + };
[...]
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6] spi: fsl_qspi: Fix DDR mode setting for latest iMX platforms
Hi Ye, On 14.08.19 12:08, Ye Li wrote: > On latest iMX platforms like iMX7D/iMX6UL/iMX8MQ, the QSPI controller > is updated to have TDH field in FLSHCR register. According to reference > manual, this TDH must be set to 1 when DDR_EN is set. Otherwise, the TX > DDR delay logic won't be enabled. This is actually an issue I have experienced myself. But in our case this behavior only happened on i.MX6ULL not on i.MX6UL. Either the QSPI controller hardware or the BootROM code changed when moving from UL to ULL. For details see: [1]. > > Another issue in DDR mode is the MCR register will be overwritten in > every read/write/erase operation. This causes DDR_EN been cleared while > TDH=1, then no clk2x output for TX data shift and all operations will > fail. The best way to fix all of these things (also the ones in the other patches) would be to fix them in Linux and port the driver from Linux to U-Boot. Actually I've already done most of the porting [2], but didn't have the time to finish it recently. It probably needs some rebasing and testing. Could you port your fixes to the Linux driver and submit them to linux-mtd? Thanks Frieder [1] https://community.nxp.com/thread/507260 [2] https://github.com/fschrempf/u-boot/commits/fsl_qspi_spimem_port > > Signed-off-by: Ye Li > --- > drivers/spi/fsl_qspi.c | 30 -- > 1 file changed, 16 insertions(+), 14 deletions(-) > > diff --git a/drivers/spi/fsl_qspi.c b/drivers/spi/fsl_qspi.c > index 41abe19..8845986 100644 > --- a/drivers/spi/fsl_qspi.c > +++ b/drivers/spi/fsl_qspi.c > @@ -399,7 +399,7 @@ static inline void qspi_ahb_read(struct fsl_qspi_priv > *priv, u8 *rxbuf, int len) > > qspi_write32(priv->flags, ®s->mcr, >QSPI_MCR_CLR_RXF_MASK | QSPI_MCR_CLR_TXF_MASK | > - QSPI_MCR_RESERVED_MASK | QSPI_MCR_END_CFD_LE); > + mcr_reg); > > rx_addr = (void *)(uintptr_t)(priv->cur_amba_base + priv->sf_addr); > /* Read out the data directly from the AHB buffer. */ > @@ -429,6 +429,14 @@ static void qspi_enable_ddr_mode(struct fsl_qspi_priv > *priv) > reg |= BIT(29); > > qspi_write32(priv->flags, ®s->mcr, reg); > + > + /* Enable the TDH to 1 for some platforms like imx6ul, imx7d, etc > + * These two bits are reserved on other platforms > + */ > + reg = qspi_read32(priv->flags, ®s->flshcr); > + reg &= ~(BIT(17)); > + reg |= BIT(16); > + qspi_write32(priv->flags, ®s->flshcr, reg); > } > > /* > @@ -482,7 +490,7 @@ static void qspi_op_rdbank(struct fsl_qspi_priv *priv, u8 > *rxbuf, u32 len) > mcr_reg = qspi_read32(priv->flags, ®s->mcr); > qspi_write32(priv->flags, ®s->mcr, >QSPI_MCR_CLR_RXF_MASK | QSPI_MCR_CLR_TXF_MASK | > - QSPI_MCR_RESERVED_MASK | QSPI_MCR_END_CFD_LE); > + mcr_reg); > qspi_write32(priv->flags, ®s->rbct, QSPI_RBCT_RXBRD_USEIPS); > > qspi_write32(priv->flags, ®s->sfar, priv->cur_amba_base); > @@ -527,7 +535,7 @@ static void qspi_op_rdid(struct fsl_qspi_priv *priv, u32 > *rxbuf, u32 len) > mcr_reg = qspi_read32(priv->flags, ®s->mcr); > qspi_write32(priv->flags, ®s->mcr, >QSPI_MCR_CLR_RXF_MASK | QSPI_MCR_CLR_TXF_MASK | > - QSPI_MCR_RESERVED_MASK | QSPI_MCR_END_CFD_LE); > + mcr_reg); > qspi_write32(priv->flags, ®s->rbct, QSPI_RBCT_RXBRD_USEIPS); > > qspi_write32(priv->flags, ®s->sfar, priv->cur_amba_base); > @@ -573,7 +581,7 @@ static void qspi_op_read(struct fsl_qspi_priv *priv, u32 > *rxbuf, u32 len) > mcr_reg = qspi_read32(priv->flags, ®s->mcr); > qspi_write32(priv->flags, ®s->mcr, >QSPI_MCR_CLR_RXF_MASK | QSPI_MCR_CLR_TXF_MASK | > - QSPI_MCR_RESERVED_MASK | QSPI_MCR_END_CFD_LE); > + mcr_reg); > qspi_write32(priv->flags, ®s->rbct, QSPI_RBCT_RXBRD_USEIPS); > > to_or_from = priv->sf_addr + priv->cur_amba_base; > @@ -625,7 +633,7 @@ static void qspi_op_write(struct fsl_qspi_priv *priv, u8 > *txbuf, u32 len) > mcr_reg = qspi_read32(priv->flags, ®s->mcr); > qspi_write32(priv->flags, ®s->mcr, >QSPI_MCR_CLR_RXF_MASK | QSPI_MCR_CLR_TXF_MASK | > - QSPI_MCR_RESERVED_MASK | QSPI_MCR_END_CFD_LE); > + mcr_reg); > qspi_write32(priv->flags, ®s->rbct, QSPI_RBCT_RXBRD_USEIPS); > > status_reg = 0; > @@ -700,7 +708,7 @@ static void qspi_op_rdsr(struct fsl_qspi_priv *priv, void > *rxbuf, u32 len) > mcr_reg = qspi_read32(priv->flags, ®s->mcr); > qspi_write32(priv->flags, ®s->mcr, >QSPI_MCR_CLR_RXF_MASK | QSPI_MCR_CLR_TXF_MASK | > - QSPI_MCR_RESERVED_MASK | QSPI_MCR_END_CFD_LE); > + mcr_reg); > qspi_write32(priv->flags, ®s->rbct, QSPI_RBCT_RXBRD_USEIPS); > > qspi_write32(priv->flags, ®s->sfar, priv->cur_amba_bas
Re: [U-Boot] [EXT] Re: [PATCH 1/6] spi: fsl_qspi: Fix DDR mode setting for latest iMX platforms
Hi Ashish, On 14.08.19 14:02, Ashish Kumar wrote: > > >> -Original Message- >> From: U-Boot On Behalf Of Schrempf Frieder >> Sent: Wednesday, August 14, 2019 5:07 PM >> To: Ye Li ; ja...@amarulasolutions.com >> Cc: Fabio Estevam ; u-boot@lists.denx.de; dl- >> uboot-imx >> Subject: [EXT] Re: [U-Boot] [PATCH 1/6] spi: fsl_qspi: Fix DDR mode setting >> for >> latest iMX platforms >> >> Caution: EXT Email >> >> Hi Ye, >> >> On 14.08.19 12:08, Ye Li wrote: >>> On latest iMX platforms like iMX7D/iMX6UL/iMX8MQ, the QSPI controller >>> is updated to have TDH field in FLSHCR register. According to >>> reference manual, this TDH must be set to 1 when DDR_EN is set. >>> Otherwise, the TX DDR delay logic won't be enabled. >> >> This is actually an issue I have experienced myself. But in our case this >> behavior only happened on i.MX6ULL not on i.MX6UL. Either the QSPI >> controller hardware or the BootROM code changed when moving from UL to >> ULL. For details see: [1]. >> >>> >>> Another issue in DDR mode is the MCR register will be overwritten in >>> every read/write/erase operation. This causes DDR_EN been cleared >>> while TDH=1, then no clk2x output for TX data shift and all operations >>> will fail. >> >> The best way to fix all of these things (also the ones in the other >> patches) would be to fix them in Linux and port the driver from Linux to U- >> Boot. Actually I've already done most of the porting [2], > Hello Frieder, > > I had tested your porting and it was not functional on u-boot. > I found that only erase, read up to TX/RX buf size is working or something > like that. > Also ip and AHB mode cannot be used at time in code. Previously only IP mode > was used in u-boot, > Since endianness across different QSPI-IP(ls1012, ls1043, ls1021 big endian), > (ls1088,ls2088 little endian) is not consistent on various silicon's. I am > not sure if Yogesh who worked with you on Linux porting gave you this > information about endianness inconsistency. Ok, thanks for your feedback. The endianness for the different SoCs can be handled by the device data. > Please suggest way forward. How to correct this issue? > > Regards > Ashish > >> time to finish it recently. It probably needs some rebasing and testing. >> >> Could you port your fixes to the Linux driver and submit them to linux-mtd? >> >> Thanks >> Frieder >> >> [1] >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcomm >> unity.nxp.com%2Fthread%2F507260&data=02%7C01%7CAshish.Kumar >> %40nxp.com%7C8882d5662295468a45b008d720abd98c%7C686ea1d3bc2b4c >> 6fa92cd99c5c301635%7C0%7C0%7C637013794778063281&sdata=Za7LB >> 6RyXAHszPfiEMLDb%2FvVNSTQJwxHFtiapmNi3Co%3D&reserved=0 >> [2] >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub >> .com%2Ffschrempf%2Fu- >> boot%2Fcommits%2Ffsl_qspi_spimem_port&data=02%7C01%7CAshish. >> Kumar%40nxp.com%7C8882d5662295468a45b008d720abd98c%7C686ea1d3 >> bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637013794778063281&sdata >> =kYDjrs2a9DdL8QLFPORfHsMSWvgUxhSTgNC3WLziu7Y%3D&reserved=0 >> >>> >>> Signed-off-by: Ye Li >>> --- >>>drivers/spi/fsl_qspi.c | 30 -- >>>1 file changed, 16 insertions(+), 14 deletions(-) >>> >>> diff --git a/drivers/spi/fsl_qspi.c b/drivers/spi/fsl_qspi.c index >>> 41abe19..8845986 100644 >>> --- a/drivers/spi/fsl_qspi.c >>> +++ b/drivers/spi/fsl_qspi.c >>> @@ -399,7 +399,7 @@ static inline void qspi_ahb_read(struct >>> fsl_qspi_priv *priv, u8 *rxbuf, int len) >>> >>>qspi_write32(priv->flags, ®s->mcr, >>> QSPI_MCR_CLR_RXF_MASK | QSPI_MCR_CLR_TXF_MASK | >>> - QSPI_MCR_RESERVED_MASK | QSPI_MCR_END_CFD_LE); >>> + mcr_reg); >>> >>>rx_addr = (void *)(uintptr_t)(priv->cur_amba_base + priv->sf_addr); >>>/* Read out the data directly from the AHB buffer. */ @@ -429,6 >>> +429,14 @@ static void qspi_enable_ddr_mode(struct fsl_qspi_priv *priv) >>>reg |= BIT(29); >>> >>>qspi_write32(priv->flags, ®s->mcr, reg); >>> + >>> + /* Enable the TDH to 1 for some platforms like imx6ul, imx7d, etc >>> + * These two bits are reserved on other platforms >>> + */ >>> + reg = qspi_read32(priv->flags, ®s->flshcr); &
