Re: [RESEND][Patch v4] net: pfe_eth: Use spi_flash_read API to access flash memory
On 28.05.20 08:12, 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
So this patch has been floating around for about half a year now with
almost no attention from the maintainers! Several pings have been sent
by the author without response.
In fact this patch was blocking 91afd36f3802 ("spi: Transform the FSL
QuadSPI driver to use the SPI MEM API") that has finally been merged,
ignoring the fact that it will break ls1012a without this being applied too.
I don't want to blame anyone, but I want to voice my disappointment and
raise attention that something is obviously wrong here.
> ---
> v4:
> -Rebase to top
> -Use complete firmware size
> -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 0493cfe..55e661c 100644
> --- a/drivers/net/pfe_eth/pfe_firmware.c
> +++ b/drivers/net/pfe_eth/pfe_firmware.c
> @@ -16,13 +16,14 @@
> #include
> #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.
> @@ -163,6 +164,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, );
> +
> + 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.
> @@ -187,6 +226,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 3bea9a9..06af8bf 100644
> --- a/include/configs/ls1012a_common.h
> +++ b/include/configs/ls1012a_common.h
> @@ -36,8 +36,11 @@
> /* Size of malloc() pool */
> #define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + 1024 * 1024)
>
> -/*SPI device */
> +/* PFE */
> #define CONFIG_SYS_FMAN_FW_ADDR 0x400d
> +#define CONFIG_SYS_QE_FMAN_FW_LENGTH 0x30
> +
> +/*SPI device */
> #define CONFIG_SYS_FSL_QSPI_BASE0x4000
>
> /* SATA */
>
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: [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: 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: 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%23a370228data=02%7C01%7Cfrieder.schrempf%40kontron.de%7Cb62b33f13a5546ece4d508d7db16044c%7C8c9d3c973fd941c8a2b1646f3942daf1%7C0%7C0%7C637218759927463384sdata=cSQl5z%2FRjvX4IKPWs71wOUhcc3ivvrq%2BObr7EeFbwCU%3Dreserved=0 >> [2] >> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kontron-electronics.de%2Flinux%2Fu-boot%2F-%2Fcommits%2Fv2020.01-ktndata=02%7C01%7Cfrieder.schrempf%40kontron.de%7Cb62b33f13a5546ece4d508d7db16044c%7C8c9d3c973fd941c8a2b1646f3942daf1%7C0%7C0%7C637218759927463384sdata=pgoX%2Bh0E%2FiY49ebT16RD3y8hKuzO0NtmdKvrXHjBnuA%3Dreserved=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: 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: [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, >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
>*
>
[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, >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
[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, );
+ 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
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, >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
>
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, );
>> + 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
>
[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, );
+ 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, >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
[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, >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 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, );
+ 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
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
>>
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
>
[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 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_TXFS_UA
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%2Fdata=02%7C01%7Ckuldeep.s >> ingh >>> %40nxp.com%7C94b5e5528efc47df25ea08d7a2f94efd%7C686ea1d3bc2b4c6 >> fa92cd9 >>> >> 9c5c301635%7C0%7C0%7C637157063972042137sdata=DZFAEmt0sA4c >> cCPmu%2F >>> cArl99B02G2KmiAUYou1RXXBI%3Dreserved=0 >>> [2] >>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc >>> >> hwork.ozlabs.org%2Fpatch%2F1208299%2Fdata=02%7C01%7Ckuldeep.s >> ingh >>> %40nxp.com%7C94b5e5528efc47df25ea08d7a2f94efd%7C686ea1d3bc2b4c6 >> fa92cd9 >>> >> 9c5c301635%7C0%7C0%7C637157063972042137sdata=3qr7QKERZgk8 >> V83QbYMM >>> Nb4xM4rUaqm2v3lZ5gzsGAQ%3Dreserved=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
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: [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 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, );
> +
> + 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: [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, );
>>> +
>>> + 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 files from FIT image.
>>&
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, );
> +
> + 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: [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, );
> +
> + 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: [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
>>> p;d
>>>>>
>>>
>> ata=02%7C01%7Cxiaowei.bao%40nxp.com%7Cd125df94364d44ecb97508d7
>>>
>> 56f03935%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6370734
>>>
>> 62083854046sdata=H%2FbP2%2BlrtoktSegAIkwWImNoNJSGxN4wzTb
>>> wAe1oMk0%3Dreserved=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%2Fdata=02%7C01%7Cxiaowei.
>>>
>> bao%40nxp.com%7Cd125df94364d44ecb97508d756f03935%7C686ea1d3bc2
>>>
>> b4c6fa92cd99c5c301635%7C0%7C0%7C637073462083854046sdata=
>>>
>> 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
>>>
>> p;data=02%7C01%7Cxiaowei.bao%40nxp.com%7Cd125df94364d44ecb97508
>>>
>> d756f03935%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63707
>>>
>> 3462083854046sdata=f%2BZDhMDbg8Hx%2F3ISB1D10yI2OT0HpPTu6
>>> ZANAlGS5bU%3Dreserved=0
>>
>>
>>
>
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
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] 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, );
> +
> + 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] imx8mq_evk: Update the required ATF branch
On 11.12.19 15:05, Fabio Estevam wrote: > Hi Peng, > > On Wed, Dec 11, 2019 at 11:00 AM Peng Fan wrote: > >> We might need to switch upstream ATF, or stick to NXP vendor release one? > > I don't have much background about the ATF upstream status on i.MX8 to > provide an opinion. > > Does upstream ATF allow booting a U-Boot and mainline kernel? > > This patch is the minimum change needed for booting mainline U-Boot. > If someone thinks that ATF upstream is a good choice, then feel free > to send a patch updating the README. Just for the record: I am using upstream ATF for my custom i.MX8MM board with mainline U-Boot and it just works fine. I didn't run into any issues so far and I'm still on ATF revision 3441952f61a6 and haven't updated for quite a while. > >> The version should already be in yocto release. I just use the new one when I >> upstream code. > > Please keep in mind that not everyone uses Yocto. > > How do we know what is the correct firmware version we need to use? >
Re: [PATCH] tools: imx8m_image: Change source path for DDR firmware to build dir
Hi Baruch,
On 11.12.19 11:49, Baruch Siach wrote:
> Hi Frieder Schrempf,
>
> On Wed, Dec 11 2019, Schrempf Frieder wrote:
>
>> From: Frieder Schrempf
>>
>> The DDR firmware binaries are not part of the U-Boot source code, so
>> we should look for them in the build directory, where they need to be
>> copied to before building U-Boot.
>>
>> The ATF binary is already fetched from the build directory, but the
>> README files for the i.MX8M EVKs claim that it needs to be copied to
>> the source directory (which is still true for in-tree builds, but not
>> in general). Therefore we also fix the READMEs to use the build
>> directory as the correct location for all additional binary files.
>>
>> Sined-off-by: Frieder Schrempf
>> ---
>> board/freescale/imx8mm_evk/README | 6 +++---
>> board/freescale/imx8mq_evk/README | 8
>> tools/imx8m_image.sh | 28 +++-
>> 3 files changed, 18 insertions(+), 24 deletions(-)
>>
>> diff --git a/board/freescale/imx8mm_evk/README
>> b/board/freescale/imx8mm_evk/README
>> index a885bc5c97..c908c0adc4 100644
>> --- a/board/freescale/imx8mm_evk/README
>> +++ b/board/freescale/imx8mm_evk/README
>> @@ -9,18 +9,18 @@ Quick Start
>>
>> Get and Build the ARM Trusted firmware
>> ==
>> -Note: srctree is U-Boot source directory
>> +Note: builddir is U-Boot build directory (source directory for in-tree
>> builds)
>> Get ATF from: https://source.codeaurora.org/external/imx/imx-atf
>> branch: imx_4.19.35_1.0.0
>> $ make PLAT=imx8mm bl31
>> -$ cp build/imx8mm/release/bl31.bin $(srctree)
>> +$ cp build/imx8mm/release/bl31.bin $(builddir)
>>
>> Get the ddr and hdmi firmware
>> =
>> $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.0.bin
>> $ chmod +x firmware-imx-8.0.bin
>> $ ./firmware-imx-8.0
>> -$ cp firmware-imx-7.9/firmware/ddr/synopsys/lpddr4*.bin $(srctree)
>> +$ cp firmware-imx-7.9/firmware/ddr/synopsys/lpddr4*.bin $(builddir)
>
> You might want to take the opportunity to fix the firmware directory
> name as well.
I will leave this to someone who knows more about this and once someone
has decided which version of the firmware should actually be used.
Personally I have used 7.8 (from Yocto Warrior release) and 8.1 (from
Yocto Zeus release) with my custom i.MX8MM board so far.
The discussion about this is currently also going on here:
https://lists.denx.de/pipermail/u-boot/2019-December/393638.html
Thanks,
Frieder
>
>>
>> Build U-Boot
>>
>> diff --git a/board/freescale/imx8mq_evk/README
>> b/board/freescale/imx8mq_evk/README
>> index c1d400bcf9..bbf69c60d8 100644
>> --- a/board/freescale/imx8mq_evk/README
>> +++ b/board/freescale/imx8mq_evk/README
>> @@ -9,19 +9,19 @@ Quick Start
>>
>> Get and Build the ARM Trusted firmware
>> ==
>> -Note: srctree is U-Boot source directory
>> +Note: builddir is U-Boot build directory (source directory for in-tree
>> builds)
>> Get ATF from: https://source.codeaurora.org/external/imx/imx-atf
>> branch: imx_4.14.62_1.0.0_beta
>> $ make PLAT=imx8mq bl31
>> -$ cp build/imx8mq/release/bl31.bin $(srctree)
>> +$ cp build/imx8mq/release/bl31.bin $(builddir)
>>
>> Get the ddr and hdmi firmware
>> =
>> $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-7.9.bin
>> $ chmod +x firmware-imx-7.9.bin
>> $ ./firmware-imx-7.9.bin
>> -$ cp firmware-imx-7.9/firmware/hdmi/cadence/signed_hdmi_imx8m.bin $(srctree)
>> -$ cp firmware-imx-7.9/firmware/ddr/synopsys/lpddr4*.bin $(srctree)
>> +$ cp firmware-imx-7.9/firmware/hdmi/cadence/signed_hdmi_imx8m.bin
>> $(builddir)
>> +$ cp firmware-imx-7.9/firmware/ddr/synopsys/lpddr4*.bin $(builddir)
>
> Same here.
>
> baruch
>
>> Build U-Boot
>>
>> diff --git a/tools/imx8m_image.sh b/tools/imx8m_image.sh
>> index 603ba6e8f4..4959f9c835 100755
>> --- a/tools/imx8m_image.sh
>> +++ b/tools/imx8m_image.sh
>> @@ -10,41 +10,35 @@ post_process=$2
>>
>> blobs=`awk '/^SIGNED_HDMI/ {print $2} /^LOADER/ {print $2}
>> /^SECOND_LOADER/ {print $2} /^DDR_FW/ {print $2}' $file`
>> for f in $blobs; do
>> -tmp=$srctree/$f
>> -
>> if [ $f = "spl/u-boot-spl-ddr.bin" ] || [ $f = "u-boot.itb" ]; then
>> continue
>> fi
&g
Re: [EXT] Re: [PATCH 0/8] Transition of fsl qspi driver to spi-mem framework
Hi Kuldeep, On 11.12.19 13:23, Kuldeep Singh wrote: > Hi Frieder, [...] >>> Patch 2 adds new qspi driver incorporating spi-mem framework which >>> is ported version of linux qspi driver. Initial port was done by >>> Frieder. >>> Now, no more direct access to spi-nor memory is possible. Few >>> changes were introduced to prevent uboot crash such as to add >>> complete flash size to SFA1AD, SFA2AD, SFB1AD, SFB2AD based on >>> chip select number instead of 1k. Immediate effect was observed on >>> pfe while using 1k size as it access spi-nor memory directly. >>> Using complete flash size resolves >> the crash but data read will not be valid. >> >> Can you provide more information about the problem/crash you >> experience and the platform you are working on? > > I observed crash on LS1012. Also, any access to flash direct memory > above 1k will crash without this change. As I already told Ashish in the conversation referenced in my last mail: I can't see any good reason why the direct memory access is something that we need or should support. We should always use the APIs provided by U-Boot to access the flash and that is mtd. > By adding this, crash will be resolved but data is invalid as > mentioned in patch-set. So what's the purpose of your changes at all, if they do not solve the problem you're trying to solve? >>> >>> I observed booting crash on all ls1012 platforms. Control does not reach >> even end of uboot prompt. >>> I dig in deeper, and found that "pfe (packet forwarding engine)" was using >> spi-nor memory directly. >>> With this change, booting crash was resolved. Now, at least other network >> interfaces can be used. >>> Without this changes, I have to disable pfe on adhoc basis so as to get >>> uboot >> prompt. >>> This is to make sure all intended qspi targets are booting. >> >> Ok, thanks for pointing out the PFE driver. I didn't know about such a >> peripheral. So this seems to be the actual problem here. >> >> I don't really understand, why Ashish didn't mention this when we were >> talking >> about this issue some weeks ago. >> >>> Why don't you just use sf/mtd to access the flash? >>> >>> Pfe framework have to bring in changes to access flash using sf in uboot. >> >> Yes and that's something that should be done first instead of hacking the >> QSPI >> controller driver. It shouldn't be too hard to modify the PFE driver so that >> it >> uses the serial flash API (spi_flash_read()) to access the SPI NOR. >> Can you try to come up with a patch for the PFE driver? > > I have sent out PFE driver patch upstream[1] and booting crash is now > resolved. Ok, good. > > Moreover, After using 1k size, I faced a random crash in environment which > was resolved after enabling SYS_RELOC_GD_ENV_ADDR in defconfig. > I am not sure why this needed when setting 1k size? Note that, same is not > required if I use my previous implementation. SYS_RELOC_GD_ENV_ADDR was only introduced very recently and it seems like it should be enabled for your boards (see [1]) when using something more recent than 8d8ee47e03ef. My guess would be that you're missing the "CONFIG_SYS_RELOC_GD_ENV_ADDR=y" because of some mistake while rebasing or merging . > > Now, I found a new bug while testing read functionality in LS1012A, LS1046A > on commit "4b19b89ca4a8". > I cannot access memory above 16MB. For example, when I try to access 16M, > data read is actually from 0x0 offset. > Could you please share your views on this behavior. This is usually a problem if the addressing mode for the SPI NOR is incorrect. When using 2-bytes addresses, only the first 16MiB of the flash can be accessed. For SPI NOR flashes with sizes bigger than 16MiB, 3-byte mode is mandatory to access areas above 16MiB. What's the manufacturer and type of the SPI flash you are using? Also please try to test on latest master with all the latest changes for MTD, etc. Thanks, Frieder [1] https://gitlab.denx.de/u-boot/u-boot/commit/8d8ee47e03ef23b0d0e842ea455a30bf0d2023b9 > > --Kuldeep >> >>> >>> Thanks >>> Kuldeep >>> > >> Are you referring to the same issue as Ashish in this discussion here >> [1]? > > Yes, I had a discussion with him. > >> There are two reasons why I'd like to avoid using the whole memory >> mapped area for AHB access. >> First, I'd like to keep the U-Boot driver as close as possible to >> the Linux driver. >> Second, the intention of the spi-mem layer is to abstract the flash >> layer and therefore this driver should work independently of flash >> type or size. > > Boot from QSPI-NAND will still not be possible. Code in bootROM is > only to access QSPI-NOR. It will not be possible to use SPI NAND directly from the BootROM, but you can just load the bootloader from a different device
Re: [U-Boot] [PATCH] net: eth-uclass: Remove warning about ROM MAC address
On 11.10.19 01:00, Soeren Moch wrote:
> Using a MAC address from ROM storage is the normal case for most
> ethernet hardware. Why should we warn about this?
>
> Signed-off-by: Soeren Moch
Some months ago I came up with the very same patch and I currently have
it in my local fork with the description "Reading the MAC address from
ROM is often a standard use case and should not produce a warning".
Therefore I'm supporting Soeren's and Fabio's point of view here and I'm
in favor of merging this patch or if preferred, change the printf() to
debug().
Reviewed-by: Frieder Schrempf
> ---
> Cc: Joe Hershberger
> Cc: u-boot@lists.denx.de
> ---
> net/eth-uclass.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/net/eth-uclass.c b/net/eth-uclass.c
> index 3bd98b01ad..8b29de37bb 100644
> --- a/net/eth-uclass.c
> +++ b/net/eth-uclass.c
> @@ -538,8 +538,6 @@ static int eth_post_probe(struct udevice *dev)
> memcpy(pdata->enetaddr, env_enetaddr, ARP_HLEN);
> } else if (is_valid_ethaddr(pdata->enetaddr)) {
> eth_env_set_enetaddr_by_index("eth", dev->seq, pdata->enetaddr);
> - printf("\nWarning: %s using MAC address from ROM\n",
> -dev->name);
> } else if (is_zero_ethaddr(pdata->enetaddr) ||
> !is_valid_ethaddr(pdata->enetaddr)) {
> #ifdef CONFIG_NET_RANDOM_ETHADDR
> --
> 2.17.1
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
>
[PATCH] tools: imx8m_image: Change source path for DDR firmware to build dir
From: Frieder Schrempf
The DDR firmware binaries are not part of the U-Boot source code, so
we should look for them in the build directory, where they need to be
copied to before building U-Boot.
The ATF binary is already fetched from the build directory, but the
README files for the i.MX8M EVKs claim that it needs to be copied to
the source directory (which is still true for in-tree builds, but not
in general). Therefore we also fix the READMEs to use the build
directory as the correct location for all additional binary files.
Sined-off-by: Frieder Schrempf
---
board/freescale/imx8mm_evk/README | 6 +++---
board/freescale/imx8mq_evk/README | 8
tools/imx8m_image.sh | 28 +++-
3 files changed, 18 insertions(+), 24 deletions(-)
diff --git a/board/freescale/imx8mm_evk/README
b/board/freescale/imx8mm_evk/README
index a885bc5c97..c908c0adc4 100644
--- a/board/freescale/imx8mm_evk/README
+++ b/board/freescale/imx8mm_evk/README
@@ -9,18 +9,18 @@ Quick Start
Get and Build the ARM Trusted firmware
==
-Note: srctree is U-Boot source directory
+Note: builddir is U-Boot build directory (source directory for in-tree builds)
Get ATF from: https://source.codeaurora.org/external/imx/imx-atf
branch: imx_4.19.35_1.0.0
$ make PLAT=imx8mm bl31
-$ cp build/imx8mm/release/bl31.bin $(srctree)
+$ cp build/imx8mm/release/bl31.bin $(builddir)
Get the ddr and hdmi firmware
=
$ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.0.bin
$ chmod +x firmware-imx-8.0.bin
$ ./firmware-imx-8.0
-$ cp firmware-imx-7.9/firmware/ddr/synopsys/lpddr4*.bin $(srctree)
+$ cp firmware-imx-7.9/firmware/ddr/synopsys/lpddr4*.bin $(builddir)
Build U-Boot
diff --git a/board/freescale/imx8mq_evk/README
b/board/freescale/imx8mq_evk/README
index c1d400bcf9..bbf69c60d8 100644
--- a/board/freescale/imx8mq_evk/README
+++ b/board/freescale/imx8mq_evk/README
@@ -9,19 +9,19 @@ Quick Start
Get and Build the ARM Trusted firmware
==
-Note: srctree is U-Boot source directory
+Note: builddir is U-Boot build directory (source directory for in-tree builds)
Get ATF from: https://source.codeaurora.org/external/imx/imx-atf
branch: imx_4.14.62_1.0.0_beta
$ make PLAT=imx8mq bl31
-$ cp build/imx8mq/release/bl31.bin $(srctree)
+$ cp build/imx8mq/release/bl31.bin $(builddir)
Get the ddr and hdmi firmware
=
$ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-7.9.bin
$ chmod +x firmware-imx-7.9.bin
$ ./firmware-imx-7.9.bin
-$ cp firmware-imx-7.9/firmware/hdmi/cadence/signed_hdmi_imx8m.bin $(srctree)
-$ cp firmware-imx-7.9/firmware/ddr/synopsys/lpddr4*.bin $(srctree)
+$ cp firmware-imx-7.9/firmware/hdmi/cadence/signed_hdmi_imx8m.bin $(builddir)
+$ cp firmware-imx-7.9/firmware/ddr/synopsys/lpddr4*.bin $(builddir)
Build U-Boot
diff --git a/tools/imx8m_image.sh b/tools/imx8m_image.sh
index 603ba6e8f4..4959f9c835 100755
--- a/tools/imx8m_image.sh
+++ b/tools/imx8m_image.sh
@@ -10,41 +10,35 @@ post_process=$2
blobs=`awk '/^SIGNED_HDMI/ {print $2} /^LOADER/ {print $2} /^SECOND_LOADER/
{print $2} /^DDR_FW/ {print $2}' $file`
for f in $blobs; do
- tmp=$srctree/$f
-
if [ $f = "spl/u-boot-spl-ddr.bin" ] || [ $f = "u-boot.itb" ]; then
continue
fi
if [ -f $f ]; then
continue
- fi
-
- if [ ! -f $tmp ]; then
+ else
echo "WARNING '$tmp' not found, resulting binary is
not-functional" >&2
exit 1
fi
-
- sed -in "s;$f;$tmp;" $file
done
if [ $post_process = 1 ]; then
- if [ -f $srctree/lpddr4_pmu_train_1d_imem.bin ]; then
- objcopy -I binary -O binary --pad-to 0x8000 --gap-fill=0x0
$srctree/lpddr4_pmu_train_1d_imem.bin lpddr4_pmu_train_1d_imem_pad.bin
- objcopy -I binary -O binary --pad-to 0x4000 --gap-fill=0x0
$srctree/lpddr4_pmu_train_1d_dmem.bin lpddr4_pmu_train_1d_dmem_pad.bin
- 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
+ if [ -f lpddr4_pmu_train_1d_imem.bin ]; then
+ objcopy -I binary -O binary --pad-to 0x8000 --gap-fill=0x0
lpddr4_pmu_train_1d_imem.bin lpddr4_pmu_train_1d_imem_pad.bin
+ objcopy -I binary -O binary --pad-to 0x4000 --gap-fill=0x0
lpddr4_pmu_train_1d_dmem.bin lpddr4_pmu_train_1d_dmem_pad.bin
+ objcopy -I binary -O binary --pad-to 0x8000 --gap-fill=0x0
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 lpddr4_pmu_train_2d_imem_pad.bin
[PATCH] ddr: imx8m: Return error values from LPDDR4 training
From: Frieder Schrempf
In cases when the same SPL should run on boards with i.MX8MM, that
differ in DDR configuration, it is necessary to try different
parameters and check if the training done by the firmware suceeds or
not.
Therefore we return the DDR training/initialization success to the
upper layer in order to be able to retry with different settings if
necessary.
Signed-off-by: Frieder Schrempf
---
arch/arm/include/asm/arch-imx8m/ddr.h | 6 +++---
drivers/ddr/imx/imx8m/ddr_init.c | 11 +--
drivers/ddr/imx/imx8m/ddrphy_train.c | 9 +++--
drivers/ddr/imx/imx8m/ddrphy_utils.c | 8
4 files changed, 23 insertions(+), 11 deletions(-)
diff --git a/arch/arm/include/asm/arch-imx8m/ddr.h
b/arch/arm/include/asm/arch-imx8m/ddr.h
index 53d46256d8..7a2a2d8edc 100644
--- a/arch/arm/include/asm/arch-imx8m/ddr.h
+++ b/arch/arm/include/asm/arch-imx8m/ddr.h
@@ -703,14 +703,14 @@ struct dram_timing_info {
extern struct dram_timing_info dram_timing;
void ddr_load_train_firmware(enum fw_type type);
-void ddr_init(struct dram_timing_info *timing_info);
-void ddr_cfg_phy(struct dram_timing_info *timing_info);
+int ddr_init(struct dram_timing_info *timing_info);
+int ddr_cfg_phy(struct dram_timing_info *timing_info);
void load_lpddr4_phy_pie(void);
void ddrphy_trained_csr_save(struct dram_cfg_param *param, unsigned int num);
void dram_config_save(struct dram_timing_info *info, unsigned long base);
/* utils function for ddr phy training */
-void wait_ddrphy_training_complete(void);
+int wait_ddrphy_training_complete(void);
void ddrphy_init_set_dfi_clk(unsigned int drate);
void ddrphy_init_read_msg_block(enum fw_type type);
diff --git a/drivers/ddr/imx/imx8m/ddr_init.c b/drivers/ddr/imx/imx8m/ddr_init.c
index d6e915c9b9..e927f0896d 100644
--- a/drivers/ddr/imx/imx8m/ddr_init.c
+++ b/drivers/ddr/imx/imx8m/ddr_init.c
@@ -20,9 +20,10 @@ void ddr_cfg_umctl2(struct dram_cfg_param *ddrc_cfg, int num)
}
}
-void ddr_init(struct dram_timing_info *dram_timing)
+int ddr_init(struct dram_timing_info *dram_timing)
{
unsigned int tmp, initial_drate, target_freq;
+ int ret;
printf("DDRINFO: start DRAM init\n");
@@ -98,7 +99,11 @@ void ddr_init(struct dram_timing_info *dram_timing)
* accessing relevant PUB registers
*/
debug("DDRINFO:ddrphy config start\n");
- ddr_cfg_phy(dram_timing);
+
+ ret = ddr_cfg_phy(dram_timing);
+ if (ret)
+ return ret;
+
debug("DDRINFO: ddrphy config done\n");
/*
@@ -165,4 +170,6 @@ void ddr_init(struct dram_timing_info *dram_timing)
/* save the dram timing config into memory */
dram_config_save(dram_timing, CONFIG_SAVED_DRAM_TIMING_BASE);
+
+ return 0;
}
diff --git a/drivers/ddr/imx/imx8m/ddrphy_train.c
b/drivers/ddr/imx/imx8m/ddrphy_train.c
index 18f7ed7fea..306af82504 100644
--- a/drivers/ddr/imx/imx8m/ddrphy_train.c
+++ b/drivers/ddr/imx/imx8m/ddrphy_train.c
@@ -8,13 +8,14 @@
#include
#include
-void ddr_cfg_phy(struct dram_timing_info *dram_timing)
+int ddr_cfg_phy(struct dram_timing_info *dram_timing)
{
struct dram_cfg_param *dram_cfg;
struct dram_fsp_msg *fsp_msg;
unsigned int num;
int i = 0;
int j = 0;
+ int ret;
/* initialize PHY configuration */
dram_cfg = dram_timing->ddrphy_cfg;
@@ -60,7 +61,9 @@ void ddr_cfg_phy(struct dram_timing_info *dram_timing)
dwc_ddrphy_apb_wr(0xd0099, 0x0);
/* Wait for the training firmware to complete */
- wait_ddrphy_training_complete();
+ ret = wait_ddrphy_training_complete();
+ if (ret)
+ return ret;
/* Halt the microcontroller. */
dwc_ddrphy_apb_wr(0xd0099, 0x1);
@@ -83,4 +86,6 @@ void ddr_cfg_phy(struct dram_timing_info *dram_timing)
/* save the ddr PHY trained CSR in memory for low power use */
ddrphy_trained_csr_save(ddrphy_trained_csr, ddrphy_trained_csr_num);
+
+ return 0;
}
diff --git a/drivers/ddr/imx/imx8m/ddrphy_utils.c
b/drivers/ddr/imx/imx8m/ddrphy_utils.c
index e60503309e..863fb43897 100644
--- a/drivers/ddr/imx/imx8m/ddrphy_utils.c
+++ b/drivers/ddr/imx/imx8m/ddrphy_utils.c
@@ -84,7 +84,7 @@ static inline void decode_streaming_message(void)
debug("\n");
}
-void wait_ddrphy_training_complete(void)
+int wait_ddrphy_training_complete(void)
{
unsigned int mail;
@@ -95,10 +95,10 @@ void wait_ddrphy_training_complete(void)
decode_streaming_message();
} else if (mail == 0x07) {
debug("Training PASS\n");
- break;
+ return 0;
} else if (mail == 0xff) {
- printf("Training FAILED\n");
- break;
+ debug("Training FAILED\n");
+
Re: [PATCH 2/2] pxe: Get default selection from board type if label matches
On 10.12.19 16:45, 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
I forgot to fix some compiler warnings in this code, so this is probably
more like a RFC until I send a fixed v2.
> ---
> cmd/pxe_utils.c | 62 +
> 1 file changed, 62 insertions(+)
>
> diff --git a/cmd/pxe_utils.c b/cmd/pxe_utils.c
> index a636346bb5..510957e68f 100644
> --- a/cmd/pxe_utils.c
> +++ b/cmd/pxe_utils.c
> @@ -1219,6 +1219,61 @@ struct pxe_menu *parse_pxefile(cmd_tbl_t *cmdtp,
> unsigned long menucfg)
> return cfg;
> }
>
> +#ifdef CONFIG_OF_CONTROL
> +/*
> + * Check if an item's name matches a provided string, pointed to by extra.
> + *
> + * This is called via menu_items_iter, so it returns a pointer to the item if
> + * the name matches, and returns NULL otherwise.
> + */
> +static inline void *pxe_item_name_match(struct menu *m, struct menu_item
> *item,
> + void *extra)
> +{
> + char *name = extra;
> + struct pxe_label *label;
> +
> + if (!name || !item->key)
> + return NULL;
> +
> + label = (struct pxe_label *)item->data;
> +
> + if (strcmp(label->name, name) == 0)
> + return item;
> +
> + return NULL;
> +}
> +
> +/*
> + * Find the first item with a name matching the given name, if any exists.
> + */
> +inline struct menu_item *menu_item_by_pxe_name(struct menu *m, char *name)
> +{
> + return menu_items_iter(m, pxe_item_name_match, name);
> +}
> +
> +int pxe_runtime_select_menu_default(struct menu *m)
> +{
> + DECLARE_GLOBAL_DATA_PTR;
> + struct menu_item *item = NULL;
> + const char *model;
> +
> + model = fdt_getprop(gd->fdt_blob, 0, "model", NULL);
> +
> + if (!model)
> + return 0;
> +
> + item = menu_item_by_pxe_name(m, model);
> +
> + if (item) {
> + printf("Menu entry %s fits detected board. " \
> +"Use as default selection...\n", item->key);
> + m->default_item = item;
> + }
> +
> + return 0;
> +}
> +#endif
> +
> /*
>* Converts a pxe_menu struct into a menu struct for use with U-Boot's
> generic
>* menu code.
> @@ -1257,6 +1312,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);
> @@ -1268,6 +1325,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;
>
[PATCH 1/2] menu: Make some parts of the menu available to other components
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.
+ */
+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
[PATCH 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
---
cmd/pxe_utils.c | 62 +
1 file changed, 62 insertions(+)
diff --git a/cmd/pxe_utils.c b/cmd/pxe_utils.c
index a636346bb5..510957e68f 100644
--- a/cmd/pxe_utils.c
+++ b/cmd/pxe_utils.c
@@ -1219,6 +1219,61 @@ struct pxe_menu *parse_pxefile(cmd_tbl_t *cmdtp,
unsigned long menucfg)
return cfg;
}
+#ifdef CONFIG_OF_CONTROL
+/*
+ * Check if an item's name matches a provided string, pointed to by extra.
+ *
+ * This is called via menu_items_iter, so it returns a pointer to the item if
+ * the name matches, and returns NULL otherwise.
+ */
+static inline void *pxe_item_name_match(struct menu *m, struct menu_item *item,
+ void *extra)
+{
+ char *name = extra;
+ struct pxe_label *label;
+
+ if (!name || !item->key)
+ return NULL;
+
+ label = (struct pxe_label *)item->data;
+
+ if (strcmp(label->name, name) == 0)
+ return item;
+
+ return NULL;
+}
+
+/*
+ * Find the first item with a name matching the given name, if any exists.
+ */
+inline struct menu_item *menu_item_by_pxe_name(struct menu *m, char *name)
+{
+ return menu_items_iter(m, pxe_item_name_match, name);
+}
+
+int pxe_runtime_select_menu_default(struct menu *m)
+{
+ DECLARE_GLOBAL_DATA_PTR;
+ struct menu_item *item = NULL;
+ const char *model;
+
+ model = fdt_getprop(gd->fdt_blob, 0, "model", NULL);
+
+ if (!model)
+ return 0;
+
+ item = menu_item_by_pxe_name(m, model);
+
+ if (item) {
+ printf("Menu entry %s fits detected board. " \
+ "Use as default selection...\n", item->key);
+ m->default_item = item;
+ }
+
+ return 0;
+}
+#endif
+
/*
* Converts a pxe_menu struct into a menu struct for use with U-Boot's generic
* menu code.
@@ -1257,6 +1312,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);
@@ -1268,6 +1325,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
Re: [EXT] Re: [PATCH 0/8] Transition of fsl qspi driver to spi-mem framework
On 03.12.19 11:56, Kuldeep Singh wrote: > Hi Frieder, > >> -Original Message----- >> From: Schrempf Frieder >> Sent: Tuesday, December 3, 2019 2:27 PM >> To: Kuldeep Singh ; u-boot@lists.denx.de >> Cc: Priyanka Jain ; ja...@amarulasolutions.com; >> s...@denx.de; Ashish Kumar ; Ye Li >> Subject: Re: [EXT] Re: [PATCH 0/8] Transition of fsl qspi driver to spi-mem >> framework >> >> Caution: EXT Email >> >> On 03.12.19 07:30, Kuldeep Singh wrote: >>> Hi Frieder, >>> >>>> -Original Message- >>>> From: Schrempf Frieder >>>> Sent: Monday, December 2, 2019 5:35 PM >>>> To: Kuldeep Singh ; u-boot@lists.denx.de >>>> Cc: Priyanka Jain ; >>>> ja...@amarulasolutions.com; s...@denx.de; Ashish Kumar >>>> >>>> Subject: [EXT] Re: [PATCH 0/8] Transition of fsl qspi driver to >>>> spi-mem framework >>>> >>>> Caution: EXT Email >>>> >>>> + Ashish >>>> >>>> Hi Kuldeep, >>>> >>>> On 29.11.19 06:54, Kuldeep Singh wrote: >>>>> This entire patch series migrate freescale qspi driver to spi-mem >> framework. >>>> >>>> First, thanks for working on this. I have this on my list for quite a >>>> long time, but struggled to find enough time to actually get it done. >>>> >>>>> >>>>> Patch 1 removes the old fsl qspi driver >>>> >>>> You shouldn't remove the old driver before the new one is in place, >>>> as this breaks the build in between the two patches. >>> >>> I first merged the patch1 and patch2 and found that the diff output was very >> much less readable. >>> That's why I split them into 2 patches so as to make new driver changes >> legible. >>> Please let me know how shall I proceed. Shall I merge the two patches? >> >> Yes, the merged patch will not be very good to read, but as far as I know >> there >> is no other option. We must not break the build to keep bisectability. > > Alright I will merge the two patches. > >> >>> >>>> >>>>> >>>>> Patch 2 adds new qspi driver incorporating spi-mem framework which >>>>> is ported version of linux qspi driver. Initial port was done by Frieder. >>>>> Now, no more direct access to spi-nor memory is possible. Few >>>>> changes were introduced to prevent uboot crash such as to add >>>>> complete flash size to SFA1AD, SFA2AD, SFB1AD, SFB2AD based on chip >>>>> select number instead of 1k. Immediate effect was observed on pfe >>>>> while using 1k size as it access spi-nor memory directly. Using >>>>> complete flash size resolves >>>> the crash but data read will not be valid. >>>> >>>> Can you provide more information about the problem/crash you >>>> experience and the platform you are working on? >>> >>> I observed crash on LS1012. Also, any access to flash direct memory above >> 1k will crash without this change. >> >> As I already told Ashish in the conversation referenced in my last mail: >> I can't see any good reason why the direct memory access is something that >> we need or should support. We should always use the APIs provided by U-Boot >> to access the flash and that is mtd. >> >>> By adding this, crash will be resolved but data is invalid as mentioned in >> patch-set. >> >> So what's the purpose of your changes at all, if they do not solve the >> problem >> you're trying to solve? > > I observed booting crash on all ls1012 platforms. Control does not reach even > end of uboot prompt. > I dig in deeper, and found that "pfe (packet forwarding engine)" was using > spi-nor memory directly. > With this change, booting crash was resolved. Now, at least other network > interfaces can be used. > Without this changes, I have to disable pfe on adhoc basis so as to get uboot > prompt. > This is to make sure all intended qspi targets are booting. Ok, thanks for pointing out the PFE driver. I didn't know about such a peripheral. So this seems to be the actual problem here. I don't really understand, why Ashish didn't mention this when we were talking about this issue some weeks ago. > >> Why don't you just use sf/mtd to access the flash? > > Pfe framework have to bring in changes to access flash using sf in uboot. Yes and that's something that should be done first instead of hacking the QSPI contro
Re: [U-Boot] [EXT] Re: [PATCH 0/8] Transition of fsl qspi driver to spi-mem framework
Hi Ashish, On 03.12.19 10:44, Frieder Schrempf wrote: > On 03.12.19 10:33, Ashish Kumar wrote: >> Hi Frieder, >> >>> -Original Message- >>> From: Schrempf Frieder >>> Sent: Tuesday, December 3, 2019 2:27 PM >>> To: Kuldeep Singh ; u-boot@lists.denx.de >>> Cc: Priyanka Jain ; ja...@amarulasolutions.com; >>> s...@denx.de; Ashish Kumar ; Ye Li >>> >>> Subject: Re: [EXT] Re: [PATCH 0/8] Transition of fsl qspi driver to >>> spi-mem >>> framework >>> >>> Caution: EXT Email >>> >>> On 03.12.19 07:30, Kuldeep Singh wrote: >>>> Hi Frieder, >>>> >>>>> -Original Message- >>>>> From: Schrempf Frieder >>>>> Sent: Monday, December 2, 2019 5:35 PM >>>>> To: Kuldeep Singh ; u-boot@lists.denx.de >>>>> Cc: Priyanka Jain ; >>>>> ja...@amarulasolutions.com; s...@denx.de; Ashish Kumar >>>>> >>>>> Subject: [EXT] Re: [PATCH 0/8] Transition of fsl qspi driver to >>>>> spi-mem framework >>>>> >>>>> Caution: EXT Email >>>>> >>>>> + Ashish >>>>> >>>>> Hi Kuldeep, >>>>> >>>>> On 29.11.19 06:54, Kuldeep Singh wrote: >>>>>> This entire patch series migrate freescale qspi driver to spi-mem >>> framework. >>>>> >>>>> First, thanks for working on this. I have this on my list for quite a >>>>> long time, but struggled to find enough time to actually get it done. >>>>> >>>>>> >>>>>> Patch 1 removes the old fsl qspi driver >>>>> >>>>> You shouldn't remove the old driver before the new one is in place, >>>>> as this breaks the build in between the two patches. >>>> >>>> I first merged the patch1 and patch2 and found that the diff output was >>> very much less readable. >>>> That's why I split them into 2 patches so as to make new driver changes >>> legible. >>>> Please let me know how shall I proceed. Shall I merge the two patches? >>> >>> Yes, the merged patch will not be very good to read, but as far as I >>> know >>> there is no other option. We must not break the build to keep >>> bisectability. >>> >>>> >>>>> >>>>>> >>>>>> Patch 2 adds new qspi driver incorporating spi-mem framework which >>>>>> is ported version of linux qspi driver. Initial port was done by >>>>>> Frieder. >>>>>> Now, no more direct access to spi-nor memory is possible. Few >>>>>> changes were introduced to prevent uboot crash such as to add >>>>>> complete flash size to SFA1AD, SFA2AD, SFB1AD, SFB2AD based on chip >>>>>> select number instead of 1k. Immediate effect was observed on pfe >>>>>> while using 1k size as it access spi-nor memory directly. Using >>>>>> complete flash size resolves >>>>> the crash but data read will not be valid. >>>>> >>>>> Can you provide more information about the problem/crash you >>>>> experience and the platform you are working on? >>>> >>>> I observed crash on LS1012. Also, any access to flash direct memory >>>> above >>> 1k will crash without this change. >>> >>> As I already told Ashish in the conversation referenced in my last mail: >>> I can't see any good reason why the direct memory access is something >>> that >>> we need or should support. We should always use the APIs provided by U- >>> Boot to access the flash and that is mtd. >>> >>>> By adding this, crash will be resolved but data is invalid as >>>> mentioned in >>> patch-set. >>> >>> So what's the purpose of your changes at all, if they do not solve >>> the problem >>> you're trying to solve? >>> Why don't you just use sf/mtd to access the flash? >>> >>>> >>>>> Are you referring to the same issue as Ashish in this discussion >>>>> here [1]? >>>> >>>> Yes, I had a discussion with him. >>>> >>>>> There are two reasons why I'd like to avoid using the whole memory >>>>> mapped area for AHB access. >>>>> First, I'd like to keep the U-Boot driver as close as possible to
Re: [U-Boot] [EXT] Re: [PATCH 0/8] Transition of fsl qspi driver to spi-mem framework
On 03.12.19 10:33, Ashish Kumar wrote: > Hi Frieder, > >> -Original Message----- >> From: Schrempf Frieder >> Sent: Tuesday, December 3, 2019 2:27 PM >> To: Kuldeep Singh ; u-boot@lists.denx.de >> Cc: Priyanka Jain ; ja...@amarulasolutions.com; >> s...@denx.de; Ashish Kumar ; Ye Li >> >> Subject: Re: [EXT] Re: [PATCH 0/8] Transition of fsl qspi driver to spi-mem >> framework >> >> Caution: EXT Email >> >> On 03.12.19 07:30, Kuldeep Singh wrote: >>> Hi Frieder, >>> >>>> -Original Message- >>>> From: Schrempf Frieder >>>> Sent: Monday, December 2, 2019 5:35 PM >>>> To: Kuldeep Singh ; u-boot@lists.denx.de >>>> Cc: Priyanka Jain ; >>>> ja...@amarulasolutions.com; s...@denx.de; Ashish Kumar >>>> >>>> Subject: [EXT] Re: [PATCH 0/8] Transition of fsl qspi driver to >>>> spi-mem framework >>>> >>>> Caution: EXT Email >>>> >>>> + Ashish >>>> >>>> Hi Kuldeep, >>>> >>>> On 29.11.19 06:54, Kuldeep Singh wrote: >>>>> This entire patch series migrate freescale qspi driver to spi-mem >> framework. >>>> >>>> First, thanks for working on this. I have this on my list for quite a >>>> long time, but struggled to find enough time to actually get it done. >>>> >>>>> >>>>> Patch 1 removes the old fsl qspi driver >>>> >>>> You shouldn't remove the old driver before the new one is in place, >>>> as this breaks the build in between the two patches. >>> >>> I first merged the patch1 and patch2 and found that the diff output was >> very much less readable. >>> That's why I split them into 2 patches so as to make new driver changes >> legible. >>> Please let me know how shall I proceed. Shall I merge the two patches? >> >> Yes, the merged patch will not be very good to read, but as far as I know >> there is no other option. We must not break the build to keep bisectability. >> >>> >>>> >>>>> >>>>> Patch 2 adds new qspi driver incorporating spi-mem framework which >>>>> is ported version of linux qspi driver. Initial port was done by Frieder. >>>>> Now, no more direct access to spi-nor memory is possible. Few >>>>> changes were introduced to prevent uboot crash such as to add >>>>> complete flash size to SFA1AD, SFA2AD, SFB1AD, SFB2AD based on chip >>>>> select number instead of 1k. Immediate effect was observed on pfe >>>>> while using 1k size as it access spi-nor memory directly. Using >>>>> complete flash size resolves >>>> the crash but data read will not be valid. >>>> >>>> Can you provide more information about the problem/crash you >>>> experience and the platform you are working on? >>> >>> I observed crash on LS1012. Also, any access to flash direct memory above >> 1k will crash without this change. >> >> As I already told Ashish in the conversation referenced in my last mail: >> I can't see any good reason why the direct memory access is something that >> we need or should support. We should always use the APIs provided by U- >> Boot to access the flash and that is mtd. >> >>> By adding this, crash will be resolved but data is invalid as mentioned in >> patch-set. >> >> So what's the purpose of your changes at all, if they do not solve the >> problem >> you're trying to solve? >> Why don't you just use sf/mtd to access the flash? >> >>> >>>> Are you referring to the same issue as Ashish in this discussion here [1]? >>> >>> Yes, I had a discussion with him. >>> >>>> There are two reasons why I'd like to avoid using the whole memory >>>> mapped area for AHB access. >>>> First, I'd like to keep the U-Boot driver as close as possible to the Linux >> driver. >>>> Second, the intention of the spi-mem layer is to abstract the flash >>>> layer and therefore this driver should work independently of flash type or >> size. >>> >>> Boot from QSPI-NAND will still not be possible. Code in bootROM is only to >> access QSPI-NOR. >> >> It will not be possible to use SPI NAND directly from the BootROM, but you >> can just load the bootloader from a different device like SPI NOR and then >> fetch the rest of the system (Kernel, rootfs, etc.)
Re: [U-Boot] [EXT] Re: [PATCH 0/8] Transition of fsl qspi driver to spi-mem framework
On 03.12.19 07:30, Kuldeep Singh wrote: > Hi Frieder, > >> -Original Message----- >> From: Schrempf Frieder >> Sent: Monday, December 2, 2019 5:35 PM >> To: Kuldeep Singh ; u-boot@lists.denx.de >> Cc: Priyanka Jain ; ja...@amarulasolutions.com; >> s...@denx.de; Ashish Kumar >> Subject: [EXT] Re: [PATCH 0/8] Transition of fsl qspi driver to spi-mem >> framework >> >> Caution: EXT Email >> >> + Ashish >> >> Hi Kuldeep, >> >> On 29.11.19 06:54, Kuldeep Singh wrote: >>> This entire patch series migrate freescale qspi driver to spi-mem framework. >> >> First, thanks for working on this. I have this on my list for quite a long >> time, but >> struggled to find enough time to actually get it done. >> >>> >>> Patch 1 removes the old fsl qspi driver >> >> You shouldn't remove the old driver before the new one is in place, as this >> breaks the build in between the two patches. > > I first merged the patch1 and patch2 and found that the diff output was very > much less readable. > That's why I split them into 2 patches so as to make new driver changes > legible. > Please let me know how shall I proceed. Shall I merge the two patches? Yes, the merged patch will not be very good to read, but as far as I know there is no other option. We must not break the build to keep bisectability. > >> >>> >>> Patch 2 adds new qspi driver incorporating spi-mem framework which is >>> ported version of linux qspi driver. Initial port was done by Frieder. >>> Now, no more direct access to spi-nor memory is possible. Few changes >>> were introduced to prevent uboot crash such as to add complete flash >>> size to SFA1AD, SFA2AD, SFB1AD, SFB2AD based on chip select number >>> instead of 1k. Immediate effect was observed on pfe while using 1k >>> size as it access spi-nor memory directly. Using complete flash size >>> resolves >> the crash but data read will not be valid. >> >> Can you provide more information about the problem/crash you experience >> and the platform you are working on? > > I observed crash on LS1012. Also, any access to flash direct memory above 1k > will crash without this change. As I already told Ashish in the conversation referenced in my last mail: I can't see any good reason why the direct memory access is something that we need or should support. We should always use the APIs provided by U-Boot to access the flash and that is mtd. > By adding this, crash will be resolved but data is invalid as mentioned in > patch-set. So what's the purpose of your changes at all, if they do not solve the problem you're trying to solve? Why don't you just use sf/mtd to access the flash? > >> Are you referring to the same issue as Ashish in this discussion here [1]? > > Yes, I had a discussion with him. > >> There are two reasons why I'd like to avoid using the whole memory mapped >> area for AHB access. >> First, I'd like to keep the U-Boot driver as close as possible to the Linux >> driver. >> Second, the intention of the spi-mem layer is to abstract the flash layer and >> therefore this driver should work independently of flash type or size. > > Boot from QSPI-NAND will still not be possible. Code in bootROM is only to > access QSPI-NOR. It will not be possible to use SPI NAND directly from the BootROM, but you can just load the bootloader from a different device like SPI NOR and then fetch the rest of the system (Kernel, rootfs, etc.) from a SPI NAND device. Actually that's exactly the use case, that led to the development of the SPI MEM layer and the migration of the QSPI driver. > >> With your version this wouldn't be the case if you connect a flash that is >> bigger than the >> memory map for example. > > I agree such use case can be valid for Linux but in case of Uboot, I believe > access to flash size greater than 256M will not be required. > If in case there is a requirement, there is another region in CCSR space to > map flash memories up to 4G. > Random crashes can be avoided by adding these changes. Please let us know > your views as well. We don't even need to consider these cases, if we would just stick to the SPI MEM API and use it as intended. Apart from some possible performance penalty (that shouldn't matter too much and could be resolved by implementing the direct mapping API as in Linux), I can't see the reason for not doing so. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/8] Transition of fsl qspi driver to spi-mem framework
+ Ashish Hi Kuldeep, On 29.11.19 06:54, Kuldeep Singh wrote: > This entire patch series migrate freescale qspi driver to spi-mem framework. First, thanks for working on this. I have this on my list for quite a long time, but struggled to find enough time to actually get it done. > > Patch 1 removes the old fsl qspi driver You shouldn't remove the old driver before the new one is in place, as this breaks the build in between the two patches. > > Patch 2 adds new qspi driver incorporating spi-mem framework which is ported > version of linux qspi driver. Initial port was done by Frieder. Now, no more > direct access to spi-nor memory is possible. Few changes were introduced to > prevent uboot crash such as to add complete flash size to SFA1AD, SFA2AD, > SFB1AD, SFB2AD based on chip select number instead of 1k. Immediate effect was > observed on pfe while using 1k size as it access spi-nor memory directly. > Using > complete flash size resolves the crash but data read will not be valid. Can you provide more information about the problem/crash you experience and the platform you are working on? Are you referring to the same issue as Ashish in this discussion here [1]? There are two reasons why I'd like to avoid using the whole memory mapped area for AHB access. First, I'd like to keep the U-Boot driver as close as possible to the Linux driver. Second, the intention of the spi-mem layer is to abstract the flash layer and therefore this driver should work independently of flash type or size. With your version this wouldn't be the case if you connect a flash that is bigger than the memory map for example. Thanks, Frieder [1]: https://lists.denx.de/pipermail/u-boot/2019-October/387788.html > > Patch 3 removes unused config options. > > Patch 4 moves FSL_QSPI config to defconfigs instead of defining in header > files. > SPI_FLASH_SPANSION is enabled while disabling SPI_FLASH_BAR. > > Patch 5 removes unused num-cs property for imx platforms > > Patch 6 enables SPI_FLASH_SPANSION for ls1012 boards. SPI_FLASH_BAR is no > longer > required and can be removed. > > Patch 7 move SPI_FLASH_SPANSION to defconfigs instead of header files. While > enabling SPI_FLASH_SPANSION config, also disable SPI_FLASH_BAR at the same > time. > > Patch 8 updates the device-tree properties treewide for layerscape boards by > aligning it with linux device-tree properties. > > Frieder Schrempf (1): >imx: imx6sx: Remove unused 'num-cs' property > > Kuldeep Singh (7): >spi: Remove old freescale qspi driver >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 SPI_FLASH_SPANSION in defconfig >configs: ls1046a: Move SPI_FLASH_SPANSION to defconfig >treewide: Update fsl qspi node dt properties as per spi-mem driver > > arch/arm/dts/fsl-ls1012a-frdm.dtsi|5 +- > arch/arm/dts/fsl-ls1012a-qds.dtsi |5 +- > arch/arm/dts/fsl-ls1012a-rdb.dtsi |5 +- > arch/arm/dts/fsl-ls1012a.dtsi |4 +- > arch/arm/dts/fsl-ls1043a-qds.dtsi |5 +- > arch/arm/dts/fsl-ls1043a.dtsi |6 +- > arch/arm/dts/fsl-ls1046a-frwy.dts |5 +- > arch/arm/dts/fsl-ls1046a-qds.dtsi |5 +- > arch/arm/dts/fsl-ls1046a-rdb.dts |5 +- > arch/arm/dts/fsl-ls1046a.dtsi |4 +- > arch/arm/dts/fsl-ls1088a-qds.dts |5 +- > arch/arm/dts/fsl-ls1088a-rdb.dts |5 +- > arch/arm/dts/fsl-ls1088a.dtsi |2 +- > arch/arm/dts/fsl-ls2080a-qds.dts |5 +- > arch/arm/dts/fsl-ls2080a.dtsi |4 +- > arch/arm/dts/fsl-ls2088a-rdb-qspi.dts |5 +- > arch/arm/dts/imx6sx-sabreauto-u-boot.dtsi |2 - > arch/arm/dts/imx6sx-sdb-u-boot.dtsi |2 - > arch/arm/dts/ls1021a-twr.dtsi |5 +- > arch/arm/dts/ls1021a.dtsi |6 +- > .../include/asm/arch-fsl-layerscape/config.h |1 - > arch/arm/include/asm/arch-ls102xa/config.h|1 - > configs/ls1012aqds_qspi_defconfig |2 +- > configs/ls1012aqds_tfa_defconfig |2 +- > configs/ls1012ardb_qspi_SECURE_BOOT_defconfig |2 +- > configs/ls1012ardb_qspi_defconfig |2 +- > configs/ls1012ardb_tfa_defconfig |2 +- > configs/ls1043aqds_qspi_defconfig |2 +- > configs/ls1043aqds_sdcard_qspi_defconfig |2 +- > configs/ls1043aqds_tfa_SECURE_BOOT_defconfig |2 + > configs/ls1043aqds_tfa_defconfig |2 +- > configs/ls1046aqds_qspi_defconfig |2 +- > configs/ls1046aqds_sdcard_qspi_defconfig |2 +- > configs/ls1046aqds_tfa_SECURE_BOOT_defconfig |1 + > configs/ls1046aqds_tfa_defconfig
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: [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 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 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
[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] 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 >>>>>+136 >>
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] [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] [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 = _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' - found
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 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, );
> - 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, );
> + 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(>ipg_clk);
> + } else if (CONFIG_IS_ENABLED(CLK_CCF)) {
> + ret = clk_get_by_name(dev, "ipg", >ipg_clk);
> + if (ret < 0) {
> + debug("Can't get FEC ipg clk: %d\n", ret);
> + return ret;
> + }
> + ret = clk_enable(>ipg_clk);
> + if(ret)
> + return ret;
> +
> + ret = clk_get_by_name(dev, "ahb", >ahb_clk);
> + if (ret < 0) {
> + debug("Can't get FEC ahb clk: %d\n", ret);
> + return ret;
> + }
> + ret = clk_enable(>ahb_clk);
> + if (ret)
> + return ret;
> +
> + ret = clk_get_by_name(dev, "enet_out", >clk_enet_out);
> + if (!ret) {
> + ret = clk_enable(>clk_enet_out);
> + if (ret)
> + return ret;
> + }
> +
> + ret = clk_get_by_name(dev, "enet_clk_ref", >clk_ref);
> + if (!ret) {
> + ret = clk_enable(>clk_ref);
> + if (ret)
> + return ret;
> + }
> +
> + ret = clk_get_by_name(dev, "ptp", >clk_ptp);
> + if (!ret) {
> + ret = clk_enable(>clk_ptp);
> + if (ret)
> + return ret;
> + }
> +
> priv->clk_rate = clk_get_rate(>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: [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, );
>>> - 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, );
>>> + 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(>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", >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(>ipg_clk);
>>> + if(ret)
>>> + return ret;
>>> + }
>>> +
>>> + ret = clk_get_by_name(dev, "ipg", >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(>ahb_clk);
>>> + if (ret)
>>> + return ret;
>>> + }
>>> +
>>> + ret = clk_get_by_name(dev, "enet_out", >clk_enet_out);
>>> + if (!ret) {
>>> + ret = clk_enable(>clk_enet_out);
>>> + if (ret)
>>> + return ret;
>>> + }
>>> +
>>> + ret = clk_get_by_name(dev, "enet_clk_ref", >clk_ref);
>>> + if (!ret) {
>>> + ret = clk_enable(>clk_ref);
>>> + if (ret)
>>> + return ret;
>>> + }
>>> +
>>> + ret = clk_get_by_name(dev, "ptp", >clk_ptp);
>>> + if (!ret) {
>>> + ret = clk_enable(>clk_ptp);
>>> + if (ret)
>>> + return ret;
>>> + }
>>> +
>>> priv->clk_rate = clk_get_rate(>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
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
[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 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, );
> - 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, );
> + 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(>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", >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(>ipg_clk);
> + if(ret)
> + return ret;
> + }
> +
> + ret = clk_get_by_name(dev, "ipg", >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(>ahb_clk);
> + if (ret)
> + return ret;
> + }
> +
> + ret = clk_get_by_name(dev, "enet_out", >clk_enet_out);
> + if (!ret) {
> + ret = clk_enable(>clk_enet_out);
> + if (ret)
> + return ret;
> + }
> +
> + ret = clk_get_by_name(dev, "enet_clk_ref", >clk_ref);
> + if (!ret) {
> + ret = clk_enable(>clk_ref);
> + if (ret)
> + return ret;
> + }
> +
> + ret = clk_get_by_name(dev, "ptp", >clk_ptp);
> + if (!ret) {
> + ret = clk_enable(>clk_ptp);
> + if (ret)
> + return ret;
> + }
> +
> priv->clk_rate = clk_get_rate(>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: [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 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, );
> + if (ret)
> + return ret;
> +
> + ret = clk_get_by_id(parent->id, );
> + 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 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] [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%2F507260data=02%7C01%7Cashish.ku >> mar% >>>>>> >> 40nxp.com%7Cc03ee11b869c47c9a7d308d757065561%7C686ea1d3bc2b4c6fa >> 92c >>>>>> >> d99c5c301635%7C0%7C0%7C637073557020848801sdata=ZvRU8vVPq0ll >> gIF >>>>>> 56nVugHjTQhM0E1GJ8PPl6P46vrg%3Dreserved=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 QSPI does not work reliably. This is with >
[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 ---
[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 ---
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 >>>
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 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] [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] [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] [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] [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 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 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 3/3] mtd: spi: Clean up usage of CONFIG_SPI_FLASH_MTD
On 14.09.19 00:44, 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 I don't know much about the U-Boot release cycle, so maybe these are stupid questions. Jagan, I saw that these 3 patches are assigned to you. When will you pick them? For the current release, or the next one? Do we still need an ack for patch 2/3 from the stm32mp maintainers? Thanks, Frieder ___ 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 18.09.19 06:51, Stefan Roese wrote:
> Hi Ashish,
>
> On 13.09.19 15:11, Stefan Roese wrote:
>> On 12.09.19 14:36, Stefan Roese wrote:
>>
>>
>>
The spi-mem version is still under debug, I could make it working
for ls1088rdb, ls1046rdb, but it is failing for
ls1012ardb and ls2088ardb and untested for i.mx and other Layerscape
silicon/boards . It is derived from work done by Frieder earlier.
This version can be found here:
https://github.com/erashish007/u-boot-spi-mem/tree/spi-mem-port
>>>
>>> Many thanks. I did some tests with this version and it seems to work
>>> fine in general on the i.MX6ULL EVK. My first tests show that reading
>>> and writing has no issues. So this is very promising. The only thing
>>> I noticed is, that when using SPI for environment via
>>> CONFIG_ENV_IS_IN_SPI_FLASH, the board hangs upon bootup while trying
>>> to read the env. Since you already added some debug print's to the
>>> env code, I suspect that you also did run into this problem.
>>>
>>> I'll try to help with this driver version. At least I can debug this
>>> env issue and can always do some test on my mx6ull platform for you
>>> once you have any updates here. Just let me know.
>>
>> Okay, this one with the env in SPI NOR is fixed. Its a problem with
>> your PR debug printf macro. Please change it this way:
>>
>> -#define PR(fmt, ...) \
>> - fprintf(stderr, "DEBUG: %s:%d:%s(): " fmt" \n", \
>> +#define PR(fmt, ...) \
>> + printf("DEBUG: %s:%d:%s(): " fmt" \n", \
>>
>> With this change, I can successfully boot with SPI NOR environment
>> on my board. I will do some further tests with your driver next
>> week and will get back to you with the results. Please keep me in
>> the loop, if you have updates on the driver.
>
> 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
Thanks,
Frieder
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] Ethernet on i.MX8MM with mainline U-Boot
Hi Peng, I tried to get Ethernet running on i.MX8MM with mainline U-Boot and your latest patches for SoC-support. I added the missing clocks, but something still seems to be wrong. It seems like the clock parents are not set correctly. If I run "dm tree", I see that the enet_axi is a child of clock-osc-24m, but I would expect it to be under sys_pll1_266m as specified in the devicetree. Do you have an idea what could be wrong or some working code to look at? Thanks for your help! Regards, Frieder ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/3] 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 --- 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_PMIC=y diff --git a/configs/display5_defconfig b/configs/display5_defconfig index 8609cd5a8c..5a4cc772be 100644 --- a/configs/display5_defconfig +++ b/configs/display5_defconfig @@ -75,6 +75,7 @@ CONFIG_SF_DEFAULT_MODE=0 CONFIG_SF_DEFAULT_SPEED=5000 CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y +CONFIG_SPI_FLASH_MTD=y CONFIG_PHYLIB=y CONFIG_PHY_MARVELL=y CONFIG_FEC_MXC=y diff --git a/configs/display5_factory_defconfig b/configs/display5_factory_defconfig index 70c64260d8..66c68e5ea9 100644 --- a/configs/display5_factory_defconfig +++ b/configs/display5_factory_defconfig @@ -74,6 +74,7 @@ CONFIG_SF_DEFAULT_MODE=0 CONFIG_SF_DEFAULT_SPEED=5000 CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y +CONFIG_SPI_FLASH_MTD=y CONFIG_PHYLIB=y CONFIG_FEC_MXC=y CONFIG_MII=y diff --git a/configs/socfpga_arria5_defconfig b/configs/socfpga_arria5_defconfig index 89e5ff8c71..30c2d19941 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 #
[U-Boot] [PATCH 2/3] stm32mp1: configs: Add CONFIG_SPL_SPI_FLASH_MTD
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 CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION=y CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION=3 CONFIG_SPL_I2C_SUPPORT=y @@ -90,6 +90,7 @@ CONFIG_SPI_FLASH_STMICRO=y CONFIG_SPI_FLASH_WINBOND=y # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set CONFIG_SPI_FLASH_MTD=y +CONFIG_SPL_SPI_FLASH_MTD=y CONFIG_DM_ETH=y CONFIG_DWC_ETH_QOS=y CONFIG_PHY=y -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/3] mtd: spi: Add a new option SPL_SPI_FLASH_MTD to Kconfig
From: Frieder Schrempf To allow SPI_FLASH_MTD being enabled separately in SPL we add a new option. The only user currently is the stm32mp15_basic board. Signed-off-by: Frieder Schrempf --- drivers/mtd/spi/Kconfig | 8 1 file changed, 8 insertions(+) diff --git a/drivers/mtd/spi/Kconfig b/drivers/mtd/spi/Kconfig index d3b007a731..f5cb7f6577 100644 --- a/drivers/mtd/spi/Kconfig +++ b/drivers/mtd/spi/Kconfig @@ -196,4 +196,12 @@ config SPI_FLASH_MTD If unsure, say N +config SPL_SPI_FLASH_MTD + bool "SPI flash MTD support for SPL" + depends on SPI_FLASH + help + Enable the MTD support for the SPI flash layer in SPL. + + If unsure, say N + endmenu # menu "SPI Flash Support" -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/3] spi: Split CONFIG_DM_SPI* to CONFIG_{SPL_TPL}DM_SPI*
On 12.09.19 11:03, Lukasz Majewski wrote:
> Hi Frieder,
>
>> Hi Lukasz,
>>
>> On 10.09.19 12:22, Lukasz Majewski wrote:
>>> Hi Frieder,
>>>
>>>> On Mon, 9 Sep 2019 11:11:50 +
>>>> Schrempf Frieder wrote:
>>>>
>>>>> Hi Lukasz,
>>>>>
>>>>> On 05.09.19 20:09, Tom Rini wrote:
>>>>>> On Thu, Sep 05, 2019 at 12:16:36AM +0200, Lukasz Majewski wrote:
>>>>>>
>>>>>>> This patch series introduces new SPL and TPL specific Kconfig
>>>>>>> entries for DM_SPI* options. Such change allows using the spi
>>>>>>> driver in SPL/TPL or U-Boot proper.
>>>>>>>
>>>>>>> First two patches - related to ls10{42}* NXP soc fix some issues
>>>>>>> with defining the DM_SPI* defines in .h file instead of
>>>>>>> Kconfig.
>>>>>>>
>>>>>>> This series doesn't introduce build breaks, but board
>>>>>>> maintainers are kindly asked to check if their boards still
>>>>>>> boots.
>>>>>>>
>>>>>>> Buildman setup for binary size regression checking:
>>>>>>>
>>>>>>> ./tools/buildman/buildman.py -b HEAD --count=4 ls1043
>>>>>>> --output-dir=../BUILD/ --force-build -CveE
>>>>>>> ./tools/buildman/buildman.py -b HEAD --count=4 ls1043
>>>>>>> --output-dir=../BUILD/ -Ssdel
>>>>>>
>>>>>> So you did fix the ls1043 problems but ls1046 is still a problem.
>>>>>>
>>>>>
>>>>> I was trying to clean up this config mess some weeks ago. I
>>>>> stumbled over the same issues (size deltas below) when I tested
>>>>> with buildman and finally gave up on it. This was my testing
>>>>> branch for reference: [1].
>>>>>
>>>>> Thanks for your work and I hope you/we can get this sorted out
>>>>> somehow...
>>>>
>>>> For now I've only posted the patch to introduce SPL_DM_SPI in
>>>> Kconig: https://patchwork.ozlabs.org/patch/1159655/
>>>
>>> However, I've looked on your patchset and IMHO this work could be
>>> divided (as doing it at once is not feasible).
>>>
>>> For example the CONFIG_SPI_FLASH_MTD could be converted to
>>> (SPL_TPL_)SPI_FLASH_MTD and then one could use
>>>
>>> #if CONFIG_IS_ENABLED(SPI_FLASH_MTD) in drivers/mtd/spi/sf_probe.c
>>> (as it is only used there).
>>>
>>> Then we could avoid situations where code is added as you remove it
>>> here [1]:
>>> https://github.com/fschrempf/u-boot/commit/b6489fb5928c2b41d7e4cb39933f078659b4f10e#diff-9d3e174d033b8b9c9d380a22a81600aaL136
>>>
>>> What I'm afraid though, is that split of SPI_FLASH_MTD will require
>>> adding unwillingly SPL_(TPL_)SPI_FLASH_MTD to all boards which
>>> already define it (and only drop ones, which use in .h file
>>> pattern as [1]).
>>
>> Yes, this looks like what I've tried to do separately in this branch
>> [1].
>>
>> The problem with some socfpga boards is, that they enable
>> CONFIG_SPI_FLASH_MTD in socfpga_common.h, without enabling
>> CONFIG_SPI_FLASH, which is probably wrong.
>
> It looks to me like the code in:
> https://github.com/fschrempf/u-boot/commit/059d67efa34da92aaf738758e596f436203c84c2#diff-9d3e174d033b8b9c9d380a22a81600aaL136
>
> is to prevent ALL socfpgas from compiling in FLASH MTD support to SPL,
> as it causes build breaks (as I do have such situation in one of my
> boards - it uses tiny SPI in SPL to read data from SPI-NOR, without the
> need to enable MTD there) .
>
> In other words those boards only use FLASH MTD driver in U-Boot proper.
> (and probably there shall not be any deltas in buildman build binaries
> [*])
Right.
>
>> So I tried to correct
>> this, but looking at it again, this should be done separately.
>>
>> So if I remove the added "CONFIG_SPI_FLASH=y" from my patches and
>> rebase, this should be ok.
>
> I think yes. I guess that ALL socfpgas shall have added
> CONFIG_SPI_FLASH_MTD=y to their _defconfigs
Right.
>
>
> It may also happen that boards, which define CONFIG_SPI_FLASH_MTD would
> require both CONFIG_SPI_FLASH_MTD and CONFIG_SPL_SPI_FLASH_MTD defined
> (if they don't use socfpga style .h code) to have the same
> binaries build.
Last time I looked such boards didn't exis
Re: [U-Boot] [PATCH v3 0/3] spi: Split CONFIG_DM_SPI* to CONFIG_{SPL_TPL}DM_SPI*
Hi Lukasz,
On 10.09.19 12:22, Lukasz Majewski wrote:
> Hi Frieder,
>
>> On Mon, 9 Sep 2019 11:11:50 +
>> Schrempf Frieder wrote:
>>
>>> Hi Lukasz,
>>>
>>> On 05.09.19 20:09, Tom Rini wrote:
>>>> On Thu, Sep 05, 2019 at 12:16:36AM +0200, Lukasz Majewski wrote:
>>>>
>>>>> This patch series introduces new SPL and TPL specific Kconfig
>>>>> entries for DM_SPI* options. Such change allows using the spi
>>>>> driver in SPL/TPL or U-Boot proper.
>>>>>
>>>>> First two patches - related to ls10{42}* NXP soc fix some issues
>>>>> with defining the DM_SPI* defines in .h file instead of
>>>>> Kconfig.
>>>>>
>>>>> This series doesn't introduce build breaks, but board maintainers
>>>>> are kindly asked to check if their boards still boots.
>>>>>
>>>>> Buildman setup for binary size regression checking:
>>>>>
>>>>> ./tools/buildman/buildman.py -b HEAD --count=4 ls1043
>>>>> --output-dir=../BUILD/ --force-build -CveE
>>>>> ./tools/buildman/buildman.py -b HEAD --count=4 ls1043
>>>>> --output-dir=../BUILD/ -Ssdel
>>>>
>>>> So you did fix the ls1043 problems but ls1046 is still a problem.
>>>>
>>>
>>> I was trying to clean up this config mess some weeks ago. I
>>> stumbled over the same issues (size deltas below) when I tested
>>> with buildman and finally gave up on it. This was my testing branch
>>> for reference: [1].
>>>
>>> Thanks for your work and I hope you/we can get this sorted out
>>> somehow...
>>
>> For now I've only posted the patch to introduce SPL_DM_SPI in Kconig:
>> https://patchwork.ozlabs.org/patch/1159655/
>
> However, I've looked on your patchset and IMHO this work could be
> divided (as doing it at once is not feasible).
>
> For example the CONFIG_SPI_FLASH_MTD could be converted to
> (SPL_TPL_)SPI_FLASH_MTD and then one could use
>
> #if CONFIG_IS_ENABLED(SPI_FLASH_MTD) in drivers/mtd/spi/sf_probe.c (as
> it is only used there).
>
> Then we could avoid situations where code is added as you remove it
> here [1]:
> https://github.com/fschrempf/u-boot/commit/b6489fb5928c2b41d7e4cb39933f078659b4f10e#diff-9d3e174d033b8b9c9d380a22a81600aaL136
>
> What I'm afraid though, is that split of SPI_FLASH_MTD will require
> adding unwillingly SPL_(TPL_)SPI_FLASH_MTD to all boards which already
> define it (and only drop ones, which use in .h file pattern as
> [1]).
Yes, this looks like what I've tried to do separately in this branch [1].
The problem with some socfpga boards is, that they enable
CONFIG_SPI_FLASH_MTD in socfpga_common.h, without enabling
CONFIG_SPI_FLASH, which is probably wrong. So I tried to correct this,
but looking at it again, this should be done separately.
So if I remove the added "CONFIG_SPI_FLASH=y" from my patches and
rebase, this should be ok.
For this set I have still one question: Should I split the patches as
currently done in [1]? This would mean after the first patch some boards
miss SPI_FLASH_MTD code and the subsequent board config patches correct
it afterwards. Or should I merge all the changes to a single patch, to
not break the boards in between.
Unfortunately I can't do it the other way round and apply the board
config changes first, as this breaks the build.
> Frieder, would you be able to work on this topic any time soon?
I can try to find some time this weekend and try to get [1] ready. But I
probably won't be able to spend serious amounts of time anytime soon on
the remaining tasks.
Thanks,
Frieder
[1]: https://github.com/fschrempf/u-boot/commits/spi_flash_mtd_cleanup
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/3] spi: Split CONFIG_DM_SPI* to CONFIG_{SPL_TPL}DM_SPI*
Hi Lukasz,
On 05.09.19 20:09, Tom Rini wrote:
> On Thu, Sep 05, 2019 at 12:16:36AM +0200, Lukasz Majewski wrote:
>> This patch series introduces new SPL and TPL specific Kconfig entries for
>> DM_SPI* options. Such change allows using the spi driver in SPL/TPL or
>> U-Boot proper.
>>
>> First two patches - related to ls10{42}* NXP soc fix some issues with
>> defining the DM_SPI* defines in .h file instead of Kconfig.
>>
>> This series doesn't introduce build breaks, but board maintainers are kindly
>> asked to check if their boards still boots.
>>
>> Buildman setup for binary size regression checking:
>>
>> ./tools/buildman/buildman.py -b HEAD --count=4 ls1043 --output-dir=../BUILD/
>> --force-build -CveE
>> ./tools/buildman/buildman.py -b HEAD --count=4 ls1043 --output-dir=../BUILD/
>> -Ssdel
>
> So you did fix the ls1043 problems but ls1046 is still a problem.
I was trying to clean up this config mess some weeks ago. I stumbled
over the same issues (size deltas below) when I tested with buildman and
finally gave up on it. This was my testing branch for reference: [1].
Thanks for your work and I hope you/we can get this sorted out somehow...
Regards,
Frieder
[1]: https://github.com/fschrempf/u-boot/commits/non_dm_spi_flash_in_spl
> There's also changes in (add 'B' to the buildman flags above for this
> info):
> x86: (for 26/26 boards) spl/u-boot-spl:all -31.6 spl/u-boot-spl:data
> -11.4 spl/u-boot-spl:rodata -6.3 spl/u-boot-spl:text -13.9
> qemu-x86_64: spl/u-boot-spl:all -821 spl/u-boot-spl:data
> -296 spl/u-boot-spl:rodata -164 spl/u-boot-spl:text -361
> spl-u-boot-spl: add: 0/-10, grow: 0/0 bytes: 0/-657 (-657)
> function old new
> delta
> spi_flash_post_bind 3 -
> -3
> dev_get_parent_priv 11 -
> -11
> spi_post_probe 35 -
> -35
> spi_child_post_bind 37 -
> -37
> spi_child_pre_probe 46 -
> -46
> _u_boot_list_2_driver_2_spi_generic_drv 68 -
> -68
> _u_boot_list_2_uclass_2_spi_nor 76 -
> -76
> _u_boot_list_2_uclass_2_spi_generic 76 -
> -76
> _u_boot_list_2_uclass_2_spi 76 -
> -76
> spi_slave_ofdata_to_platdata 229 -
> -229
> arm: (for 688/688 boards) all -19.6 bss -4.5 rodata -2.2
> spl/u-boot-spl:all -12.2 spl/u-boot-spl:bss -1.1 spl/u-boot-spl:data -1.9
> spl/u-boot-spl:rodata -2.0 spl/u-boot-spl:text -7.2 text -12.9
> uniphier_v7: bss -8 rodata +8
> opos6uldev : bss -8 rodata +8
> uniphier_ld4_sld8: bss -8 rodata +8
> da850evm : spl/u-boot-spl:all -614 spl/u-boot-spl:data
> -144 spl/u-boot-spl:rodata -150 spl/u-boot-spl:text -320
> spl-u-boot-spl: add: 2/-15, grow: 2/0 bytes: 112/-574 (-462)
> function old new
> delta
> spi_flash_probe 38 82
> +44
> spi_setup_slave - 42
> +42
> spl_spi_load_image 124 144
> +20
> spi_free_slave - 6
> +6
> spi_flash_std_remove 4 -
> -4
> spi_flash_post_bind 4 -
> -4
> spi_flash_cmd_get_sw_write_prot 8 -
> -8
> aeabi_uidivmod_from_thumb8 -
> -8
> spi_flash_std_get_sw_write_prot 18 -
> -18
> spi_flash_read_dm 20 -
> -20
> __aeabi_uidivmod24 -
> -24
> __aeabi_idivmod 24 -
> -24
> spi_flash_std_write 42 -
> -42
> spi_flash_std_read 42 -
> -42
> spi_flash_probe_bus_cs 56 -
> -56
> _u_boot_list_2_driver_2_spi_flash_std 68 -
> -68
> _u_boot_list_2_uclass_2_spi_nor 76 -
> -76
> spi_flash_std_probe 88 -
> -88
> spi_flash_std_erase 92 -
> -92
> da850evm_nand : spl/u-boot-spl:all -614
Re: [U-Boot] [EXT] Re: [PATCH 1/6] spi: fsl_qspi: Fix DDR mode setting for latest iMX platforms
Hi Ashish, On 27.08.19 11:56, Ashish Kumar wrote: > > >> -Original Message----- >> From: Schrempf Frieder >> Sent: Wednesday, August 14, 2019 5:41 PM >> To: Ashish Kumar ; Ye Li ; >> ja...@amarulasolutions.com >> Cc: Fabio Estevam ; u-boot@lists.denx.de; dl- >> uboot-imx >> Subject: Re: [EXT] Re: [U-Boot] [PATCH 1/6] spi: fsl_qspi: Fix DDR mode >> setting for latest iMX platforms >> >> Caution: EXT Email >> >> Sorry, I hit the "Send" button too early ;) >> >> On 14.08.19 14:07, Frieder Schrempf wrote: >>> 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. >> >> Does this work correctly in Linux, or does the Linux driver need fixes? >> >>> >>>> Please suggest way forward. How to correct this issue? >> >> The first thigh would be to make sure the Linux driver works for all >> platforms >> and then do the porting to U-Boot. I will be out of office for >> 10 days. After that I can try to work on this, but I need support and >> testing for >> other platforms. I only have i.MX6UL/ULL. > > Hi Frieder, > > I have found some break though after porting to 2019.10 and few modification > in driver code, I will update in a weeks' time. Please do not invest time on > this. > If I need some help I will update. Thanks for your work. Do you already have some news? Can you share your results? Thanks, Frieder ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Regressions in MTD / SPI FLASH
Hi Eugeniy, On 04.09.19 20:07, Eugeniy Paltsev wrote: > We faced with regressions caused by > commit c4e8862308d4 (mtd: spi: Switch to new SPI NOR framework) > This switch was performed by removing entire u-boot spi-flash > core implementation and copying it from another project. > However the switch is performed without proper testing and > investigations about fixes/improvements were made in u-boot > spi-flash core. This results in regressions. > > One of regression we faced with is related to SST26 flash series which > is used on HSDK board. The cause is that SST26 protection ops > implementation was dropped. The fix of this regression is send > as a patch in this series. > > However there are another regressions. I.E: we also faced with broken > SPI flash on another SNPS boards - AXS101 and AXS103. They use different > flash IC (n25q512ax3) and I didn't investigate the cause yet. > > I can also expect regressions among other u-boot users > and I believe that subsystem changes mustn't be done such harmful way. Actually such changes are only as much "harmful" as they are not tested on all of the hardware and this depends only on how many developers with specific boards step up to test these changes. As Vignesh already explained, syncing the framework from Linux to U-Boot was desperately needed and I'm very glad, that he did the work. Otherwise we would still be stuck with rather old and unmaintainable code, that would even cause more issues in the long term. Regards Frieder > > Eugeniy Paltsev (1): >MTD: SPI: revert removing SST26* flash IC protection ops > > drivers/mtd/spi/sf_internal.h | 1 + > drivers/mtd/spi/spi-nor-core.c | 181 + > drivers/mtd/spi/spi-nor-ids.c | 8 +- > include/linux/mtd/spi-nor.h| 4 + > 4 files changed, 190 insertions(+), 4 deletions(-) > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH V3 24/27] imx8m: soc: probe clock device in arch_cpu_init_dm
On 29.08.19 03:21, Peng Fan wrote:
> Hi Frieder,
>
>> Subject: Re: [PATCH V3 24/27] imx8m: soc: probe clock device in
>> arch_cpu_init_dm
>>
>> Hi Peng,
>>
>> On 27.08.19 08:25, Peng Fan wrote:
>>> Because we need to get cpu freq in print_cpuinfo at very early stage,
>>> so we need to make sure the ccm be probed.
>>>
>>> Signed-off-by: Peng Fan
>>> ---
>>>arch/arm/mach-imx/imx8m/soc.c | 17 +
>>>1 file changed, 17 insertions(+)
>>>
>>> diff --git a/arch/arm/mach-imx/imx8m/soc.c
>>> b/arch/arm/mach-imx/imx8m/soc.c index 3a54db4898..f904049120
>> 100644
>>> --- a/arch/arm/mach-imx/imx8m/soc.c
>>> +++ b/arch/arm/mach-imx/imx8m/soc.c
>>> @@ -14,6 +14,7 @@
>>>#include
>>>#include
>>>#include
>>> +#include
>>>#include
>>>#include
>>>#include
>>> @@ -228,6 +229,22 @@ static void imx_set_wdog_powerdown(bool
>> enable)
>>> writew(enable, >wmcr);
>>>}
>>>
>>> +int arch_cpu_init_dm(void)
>>> +{
>>> + struct udevice *dev;
>>> + int ret;
>>> +
>>> + ret = uclass_get_device_by_name(UCLASS_CLK,
>>> + "clock-controller@3038",
>>> + );
>>
>> I just upgraded my working tree to v2019.10-rc3 + your v3 MX8MM patches.
>> This somehow breaks things for me. The U-Boot proper hangs when calling
>> uclass_get_device_by_name(). Removing this call makes the boot work again.
>> Do you have any idea what could be wrong? Do I miss something?
>
> Please enlarge CONFIG_SYS_MALLOC_F_LEN to 0x1 and have a try.
That did the trick. Thanks a lot!
>
> Regards,
> Peng.
>
>>
>> Thanks,
>> Frieder
>>
>>> + if (ret < 0) {
>>> + printf("Failed to find clock node. Check device tree\n");
>>> + return ret;
>>> + }
>>> +
>>> + return 0;
>>> +}
>>> +
>>>int arch_cpu_init(void)
>>>{
>>> struct ocotp_regs *ocotp = (struct ocotp_regs
>> *)OCOTP_BASE_ADDR;
>>>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH V3 24/27] imx8m: soc: probe clock device in arch_cpu_init_dm
Hi Peng,
On 27.08.19 08:25, Peng Fan wrote:
> Because we need to get cpu freq in print_cpuinfo at very early stage,
> so we need to make sure the ccm be probed.
>
> Signed-off-by: Peng Fan
> ---
> arch/arm/mach-imx/imx8m/soc.c | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/arch/arm/mach-imx/imx8m/soc.c b/arch/arm/mach-imx/imx8m/soc.c
> index 3a54db4898..f904049120 100644
> --- a/arch/arm/mach-imx/imx8m/soc.c
> +++ b/arch/arm/mach-imx/imx8m/soc.c
> @@ -14,6 +14,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -228,6 +229,22 @@ static void imx_set_wdog_powerdown(bool enable)
> writew(enable, >wmcr);
> }
>
> +int arch_cpu_init_dm(void)
> +{
> + struct udevice *dev;
> + int ret;
> +
> + ret = uclass_get_device_by_name(UCLASS_CLK,
> + "clock-controller@3038",
> + );
I just upgraded my working tree to v2019.10-rc3 + your v3 MX8MM patches.
This somehow breaks things for me. The U-Boot proper hangs when calling
uclass_get_device_by_name(). Removing this call makes the boot work again.
Do you have any idea what could be wrong? Do I miss something?
Thanks,
Frieder
> + if (ret < 0) {
> + printf("Failed to find clock node. Check device tree\n");
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> int arch_cpu_init(void)
> {
> struct ocotp_regs *ocotp = (struct ocotp_regs *)OCOTP_BASE_ADDR;
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 22/22] imx: Add i.MX8MM EVK board support.
On 15.08.19 02:57, Peng Fan wrote:
>> Subject: Re: [PATCH 22/22] imx: Add i.MX8MM EVK board support.
>>
>> On 09.08.19 06:15, Peng Fan wrote:
>>> Add board and SoC dts
>>> Add ddr training code
>>> support SD/MMC/GPIO/PINCTRL/UART
>>>
>>> Signed-off-by: Peng Fan
>>> ---
>>>arch/arm/dts/Makefile |3 +-
>
> []
>>> +}
>>> +#endif
>>> +
>>> +int dram_init(void)
>>> +{
>>> + /* rom_pointer[1] contains the size of TEE occupies */
>>> + if (rom_pointer[1])
>>> + gd->ram_size = PHYS_SDRAM_SIZE - rom_pointer[1];
>>> + else
>>
>> The above case should be guarded with "#ifdef CONFIG_OPTEE", because if
>> OPTEE is not used, rom_pointer[1] does not always seem to be zero.
>
> If OPTEE is not used, ATF will leave those registers as zero, so it will be
> zero.
It wasn't working for me, but I can try again and check my ATF if it
really does. Maybe it would still be better to guard this check so we
don't depend on the ATF behavior.
>
>>
>>> + gd->ram_size = PHYS_SDRAM_SIZE;
>>> +
>>> + return 0;
>>> +}
>>> +
>
> [...]
>>> +CONFIG_SPL_LOAD_FIT=y
>>> +CONFIG_SPL_FIT_GENERATOR="arch/arm/mach-imx/mkimage_fit_atf.sh"
>>
>> For my custom i.MX8MM board I also use mkimage_fit_atf.sh, but I have done
>> three modifications and I'm wondering how you are using the unmodified
>> version.
>>
>> 1. It sets ATF_LOAD_ADDR="0x91", but in imx-atf the BL31_BASE for
>> i.MX8MM is set to 0x92. How to handle this mismatch for i.MX8M and
>> i.MX8MM?
>
> I have added README in patchset, need export ATF_LOAD_ADDR=0x92
This is not very convenient. It would be better if there is a default
value for each of i.MX8M and i.MX8MM.
>
>>
>> 2. For the 'images' section of the its file, I added 'os = "u-boot";' to the
>> 'uboot@1' section and "os = 'arm-trusted-firmware";' to the 'atf@1'
>> section. Without this SPL does not detect the binaries from the FIT image
>> correctly.
>
> Thanks for the fix.
Will you add a patch to fix this to your set?
>
>>
>> 3. In the 'config' section of the its file, I swapped the atf and uboot
>> entries, so
>> the atf binary is loaded as "firmware" and the u-boot binary as "loadable".
>> Together with the change above (2) this leads to SPL code using the correct
>> boot path as inteded by the code.
>
> Thanks for the fix.
Ditto?
>
>>
>>> +CONFIG_OF_BOARD_SETUP=y
>>> +CONFIG_OF_SYSTEM_SETUP=y
>>>
>> +CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/imx8m
>> /imximage-8mm-lpddr4.cfg"
>>> +CONFIG_DEFAULT_FDT_FILE="fsl-imx8mm-evk.dtb"
>>> +CONFIG_BOARD_LATE_INIT=y
>>> +CONFIG_BOARD_EARLY_INIT_F=y
>>> +CONFIG_SPL_TEXT_BASE=0x7E1000
>>> +CONFIG_SPL_BOARD_INIT=y
>>> +CONFIG_SPL_SEPARATE_BSS=y
>>> +CONFIG_SPL_I2C_SUPPORT=y
>>> +CONFIG_HUSH_PARSER=y
>>> +CONFIG_SYS_PROMPT="u-boot=> "
>>> +# CONFIG_CMD_EXPORTENV is not set
>>> +# CONFIG_CMD_IMPORTENV is not set
>>> +# CONFIG_CMD_CRC32 is not set
>>> +CONFIG_CMD_CLK=y
>>> +CONFIG_CMD_FUSE=y
>>> +CONFIG_CMD_GPIO=y
>>> +CONFIG_CMD_I2C=y
>>> +CONFIG_CMD_MMC=y
>>> +CONFIG_CMD_CACHE=y
>>> +CONFIG_CMD_REGULATOR=y
>>> +CONFIG_CMD_EXT2=y
>>> +CONFIG_CMD_EXT4=y
>>> +CONFIG_CMD_EXT4_WRITE=y
>>> +CONFIG_CMD_FAT=y
>>> +CONFIG_OF_CONTROL=y
>>> +CONFIG_SPL_OF_CONTROL=y
>>> +CONFIG_DEFAULT_DEVICE_TREE="imx8mm-evk"
>>> +CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
>>> +CONFIG_SPL_DM=y
>>> +CONFIG_SPL_CLK_COMPOSITE_CCF=y
>>> +CONFIG_CLK_COMPOSITE_CCF=y
>>> +CONFIG_SPL_CLK_IMX8MM=y
>>> +CONFIG_CLK_IMX8MM=y
>>> +CONFIG_DM_GPIO=y
>>> +CONFIG_MXC_GPIO=y
>>> +CONFIG_DM_I2C=y
>>> +CONFIG_SYS_I2C_MXC=y
>>> +CONFIG_SYS_I2C_MXC_I2C1=y
>>> +CONFIG_SYS_I2C_MXC_I2C2=y
>>> +CONFIG_SYS_I2C_MXC_I2C3=y
>>> +CONFIG_DM_MMC=y
>>> +CONFIG_SUPPORT_EMMC_BOOT=y
>>> +CONFIG_FSL_ESDHC_IMX=y
>>> +CONFIG_PHYLIB=y
>>> +CONFIG_DM_ETH=y
>>> +CONFIG_PINCTRL=y
>>> +CONFIG_SPL_PINCTRL=y
>>> +CONFIG_PINCTRL_IMX8M=y
>>> +CONFIG_DM_REGULATOR=y
>>> +CONFIG_DM_REGULATOR_FIXED=y
>>> +CONFIG_DM_REGULATOR_GPIO=y
>>> +CONFIG_MXC_UART=y
>>> +CONFIG_DM_THERMAL=y
>>> diff --git a/include/configs/imx8mm_evk.h
>>> b/include/configs/imx8mm_evk.h new file mode 100644 index
>>> 00..cc63c44782
>>> --- /dev/null
>>> +++ b/include/configs/imx8mm_evk.h
>>> @@ -0,0 +1,164 @@
>>> +/* SPDX-License-Identifier: GPL-2.0+ */
>>> +/*
>>> + * Copyright 2018 NXP
>>> + */
>>> +
>>> +#ifndef __IMX8MM_EVK_H
>>> +#define __IMX8MM_EVK_H
>>> +
>>> +#include
>>> +#include
>>> +
>>> +#ifdef CONFIG_SECURE_BOOT
>>> +#define CONFIG_CSF_SIZE0x2000 /* 8K region */
>>> +#endif
>>> +
>>> +#define CONFIG_SPL_MAX_SIZE(148 * 1024)
>>> +#define CONFIG_SYS_MONITOR_LEN SZ_512K
>>> +#define CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR
>>> +#define CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR0x300
>>> +#define CONFIG_SYS_MMCSD_FS_BOOT_PARTITION 1
>>> +#define CONFIG_SYS_UBOOT_BASE \
>>> + (QSPI0_AMBA_BASE +
>> CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR * 512)
>>> +
>>> +#ifdef CONFIG_SPL_BUILD
>>> +/*#define
Re: [U-Boot] [PATCH v2 00/26] i.MX8MM support
On 19.08.19 11:42, Peng Fan wrote:
> V2:
> Fixed comments from Lukasz and Frieder
This set has 26 patches, while the previous version had 22. You should
document all changes here, so one can easily figure out which patches
were added/removed/merged/split.
>
> V1:
> https://patchwork.ozlabs.org/cover/1144326/
> This is a splitted and updated patch from
> https://patchwork.ozlabs.org/cover/1128799/ which is to support both
> i.MX8MM and i.MX8MN.
>
> There is a README added, following that to test if you would like to.
>
> Peng Fan (25):
>tools: imx8m_image: align spl bin image size
>ddr: imx8m: fix ddr firmware location when enable SPL OF
>imx8m: add image cfg for i.MX8MM lpddr4
>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: imx-regs: drop unused register definitions
>imx8m: update imx-regs for i.MX8MM
>imx: add get_cpu_rev support for i.MX8MM
>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
>imx8m: restrict reset_cpu
>imx8m: rename clock to clock_imx8mq
>imx8m: restructure clock.h
>imx8m: add clk support for i.MX8MM
>imx: mmc_env: update runtime SD/MMC boot env device
>imx8m: soc: probe clock device in arch_cpu_init_dm
>arm: dts: import i.MX8MM dtsi
>arm: dts: add i.MX8MM pin func
>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| 491 +
> 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 | 291 +--
> arch/arm/include/asm/arch-imx8m/imx8mm_pins.h | 691 +++
> arch/arm/include/asm/mach-imx/iomux-v3.h |4 +
> arch/arm/include/asm/mach-imx/sys_proto.h |8 +
> arch/arm/mach-imx/cpu.c| 12 +
> arch/arm/mach-imx/imx8m/Kconfig| 17 +-
> arch/arm/mach-imx/imx8m/Makefile |4 +-
> arch/arm/mach-imx/imx8m/clock_imx8mm.c | 306 +++
> .../arm/mach-imx/imx8m/{clock.c => clock_imx8mq.c} |5 +-
> arch/arm/mach-imx/imx8m/clock_slice.c | 63 +
> arch/arm/mach-imx/imx8m/imximage-8mm-lpddr4.cfg| 16 +
> arch/arm/mach-imx/imx8m/soc.c | 129 +-
> arch/arm/mach-imx/mmc_env.c|3 +
> arch/arm/mach-imx/spl.c|8 +
> board/freescale/imx8mm_evk/Kconfig | 12 +
> board/freescale/imx8mm_evk/MAINTAINERS |6 +
> board/freescale/imx8mm_evk/Makefile| 12 +
> board/freescale/imx8mm_evk/imx8mm_evk.c| 45 +
> board/freescale/imx8mm_evk/lpddr4_timing.c | 1980
>
> board/freescale/imx8mm_evk/spl.c | 129 ++
> configs/imx8mm_evk_defconfig | 74 +
> drivers/ddr/imx/imx8m/helper.c | 12 +-
> include/configs/imx8mm_evk.h | 153 ++
> include/dt-bindings/clock/imx8mm-clock.h | 253 +++
> tools/imx8m_image.sh |5 +-
> 34 files changed, 6535 insertions(+), 703 deletions(-)
> create mode 100644 arch/arm/dts/imx8mm-evk-u-boot.dtsi
> create mode 100644 arch/arm/dts/imx8mm-evk.dts
> create mode 100644 arch/arm/dts/imx8mm-pinfunc.h
> create mode 100644 arch/arm/dts/imx8mm.dtsi
> create mode 100644 arch/arm/include/asm/arch-imx8m/clock_imx8mm.h
> create mode 100644 arch/arm/include/asm/arch-imx8m/clock_imx8mq.h
> create mode 100644 arch/arm/include/asm/arch-imx8m/imx8mm_pins.h
> create mode 100644 arch/arm/mach-imx/imx8m/clock_imx8mm.c
> rename arch/arm/mach-imx/imx8m/{clock.c => clock_imx8mq.c} (99%)
> create mode 100644 arch/arm/mach-imx/imx8m/imximage-8mm-lpddr4.cfg
> create mode 100644 board/freescale/imx8mm_evk/Kconfig
> create mode 100644 board/freescale/imx8mm_evk/MAINTAINERS
> create mode 100644 board/freescale/imx8mm_evk/Makefile
> create mode 100644 board/freescale/imx8mm_evk/imx8mm_evk.c
> create mode 100644 board/freescale/imx8mm_evk/lpddr4_timing.c
> create mode 100644
Re: [U-Boot] [PATCH 09/22] imx8m: update imx-regs for i.MX8MM
On 15.08.19 03:01, Peng Fan wrote:
>> Subject: Re: [PATCH 09/22] imx8m: update imx-regs for i.MX8MM
>>
>> On 09.08.19 06:15, Peng Fan wrote:
>>> i.MX8MM has similar architecture with i.MX8MQ, but it has totally
>>> different PLL design and some register layout change.
>>>
>>> Note: Some registers in this file are not updated because not used now.
>>
>> I think this is a bad idea. There seem to be many differences in the register
>> addresses between i.MX8M and i.MX8MM and you are leaving the values for
>> i.MX8M to be set also when i.MX8MM is used.
>>
>> This might not hurt now when those things are not used. But as soon as
>> someone (like me) uses some more peripherals, they will run into serious
>> problems because certain register base addresses are wrong.
>>
>> You should at least disable the unused macros for i.MX8MM, so we will get a
>> build error instead of using wrong address values without noticing. Or even
>> better go through the values and fix them for i.MX8MM.
>> Maybe it would be even cleaner to add a separate file for i.MX8MM if they
>> differ too much.
>
> The final goal should be to drop the regs file, since we are moving to use
> DM/OF.
Of course, but as long as the values in this file are potentially used
by some drivers, we should not be lazy and define invalid addresses for
i.MX8MM.
> Let me think about the issues you raised.
>
> Thanks,
> Peng.
>
>>
>>>
>>> Signed-off-by: Peng Fan
>>> ---
>>>arch/arm/include/asm/arch-imx8m/imx-regs.h | 75
>> --
>>>1 file changed, 71 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/arch/arm/include/asm/arch-imx8m/imx-regs.h
>> b/arch/arm/include/asm/arch-imx8m/imx-regs.h
>>> index 68666a535b..a5be2e85da 100644
>>> --- a/arch/arm/include/asm/arch-imx8m/imx-regs.h
>>> +++ b/arch/arm/include/asm/arch-imx8m/imx-regs.h
>>> @@ -10,8 +10,8 @@
>>>
>>>#include
>>>
>>> -#define ROM_VERSION_A0 0x800
>>> -#define ROM_VERSION_B0 0x83C
>>> +#define ROM_VERSION_A0 IS_ENABLED(CONFIG_IMX8MQ) ?
>> 0x800 : 0x800
>>> +#define ROM_VERSION_B0 IS_ENABLED(CONFIG_IMX8MQ) ?
>> 0x83C : 0x800
>>>
>>>#define M4_BOOTROM_BASE_ADDR 0x007E
>>>
>>> @@ -93,7 +93,11 @@
>>>#define SEMAPHOR_HS_BASE_ADDR0x30AC
>>>#define USDHC1_BASE_ADDR 0x30B4
>>>#define USDHC2_BASE_ADDR 0x30B5
>>> +#ifdef CONFIG_IMX8MM
>>> +#define USDHC3_BASE_ADDR 0x30B6
>>> +#else
>>>#define MIPI_CS2_BASE_ADDR 0x30B6
>>> +#endif
>>>#define MIPI_CSI_PHY2_BASE_ADDR 0x30B7
>>>#define CSI2_BASE_ADDR 0x30B8
>>>#define QSPI0_BASE_ADDR 0x30BB
>>> @@ -120,7 +124,8 @@
>>>#define USB1_PHY_BASE_ADDR 0x381F
>>>#define USB2_PHY_BASE_ADDR 0x382F
>>>
>>> -#define MXS_LCDIF_BASE LCDIF_BASE_ADDR
>>> +#define MXS_LCDIF_BASE is_enable(CONFIG_IMX8MQ) ? \
>>> + 0x3032 : 0x32e0
>>>
>>>#define SRC_IPS_BASE_ADDR0x3039
>>>#define SRC_DDRC_RCR_ADDR0x30391000
>>> @@ -149,6 +154,9 @@
>>>#define SRC_DDR1_RCR_CORE_RESET_N_MASK BIT(1)
>>>#define SRC_DDR1_RCR_PRESET_N_MASK BIT(0)
>>>
>>> +#define IOMUXC_GPR_GPR1_GPR_ENET1_TX_CLK_SEL_MASK 0x2000u
>>> +#define IOMUXC_GPR_GPR1_GPR_ENET1_TX_CLK_SEL_SHIFT 13
>>> +
>>>struct iomuxc_gpr_base_regs {
>>> u32 gpr[47];
>>>};
>>> @@ -205,6 +213,7 @@ struct fuse_bank1_regs {
>>> u32 rsvd3[3];
>>>};
>>>
>>> +#ifdef CONFIG_IMX8MQ
>>>struct anamix_pll {
>>> u32 audio_pll1_cfg0;
>>> u32 audio_pll1_cfg1;
>>> @@ -239,6 +248,60 @@ struct anamix_pll {
>>> u32 frac_pllout_div_cfg;
>>> u32 sscg_pllout_div_cfg;
>>>};
>>> +#else
>>> +struct anamix_pll {
>>> + u32 audio_pll1_gnrl_ctl;
>>> + u32 audio_pll1_fdiv_ctl0;
>>> + u32 audio_pll1_fdiv_ctl1;
>>> + u32 audio_pll1_sscg_ctl;
>>> + u32 audio_pll1_mnit_ctl;
>>> + u32 audio_pll2_gnrl_ctl;
>>> + u32 audio_pll2_fdiv_ctl0;
>>> + u32 audio_pll2_fdiv_ctl1;
>>> + u32 audio_pll2_sscg_ctl;
>>> + u32 audio_pll2_mnit_ctl;
>>> + u32 video_pll1_gnrl_ctl;
>>> + u32 video_pll1_fdiv_ctl0;
>>> + u32 video_pll1_fdiv_ctl1;
>>> + u32 video_pll1_sscg_ctl;
>>> + u32 video_pll1_mnit_ctl;
>>> + u32 reserved[5];
>>> + u32 dram_pll_gnrl_ctl;
>>> + u32 dram_pll_fdiv_ctl0;
>>> + u32 dram_pll_fdiv_ctl1;
>>> + u32 dram_pll_sscg_ctl;
>>> + u32 dram_pll_mnit_ctl;
>>> + u32 gpu_pll_gnrl_ctl;
>>> + u32 gpu_pll_div_ctl;
>>> + u32 gpu_pll_locked_ctl1;
>>> + u32 gpu_pll_mnit_ctl;
>>> + u32 vpu_pll_gnrl_ctl;
>>> + u32 vpu_pll_div_ctl;
>>> + u32 vpu_pll_locked_ctl1;
>>> + u32 vpu_pll_mnit_ctl;
>>> + u32 arm_pll_gnrl_ctl;
>>> + u32 arm_pll_div_ctl;
>>> + u32 arm_pll_locked_ctl1;
>>> + u32 arm_pll_mnit_ctl;
>>> + u32 sys_pll1_gnrl_ctl;
>>> + u32 sys_pll1_div_ctl;
>>> + u32 sys_pll1_locked_ctl1;
>>> + u32 reserved2[24];
>>> + u32 sys_pll1_mnit_ctl;
>>> + u32
Re: [U-Boot] [PATCH v2 01/26] tools: imx8m_image: align spl bin image size
On 19.08.19 11:42, Peng Fan wrote: > 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. > > Reviewed-by: Frieder Schrempf I think the " at " in my e-mail address should be "@" here and in all other patches/tags. > Tested-by: Frieder Schrempf > Signed-off-by: Peng Fan > --- > 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 v2 02/26] ddr: imx8m: fix ddr firmware location when enable SPL OF
On 19.08.19 11:42, Peng Fan wrote:
> With CONFIG_SPL_OF_CONTROL, the device tree will be padded to
> 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 4bytes to ease copy firmware.
Please add a space between "4" and "bytes".
>
> Reviewed-by: Frieder Schrempf
> Tested-by: Frieder Schrempf
> Signed-off-by: Peng Fan
> ---
> 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 00/22] i.MX8MM support
Hi Peng,
On 09.08.19 06:14, Peng Fan wrote:
> This is a splitted and updated patch from
> https://patchwork.ozlabs.org/cover/1128799/ which is to support both
> i.MX8MM and i.MX8MN.
I have sent you feedback for some of the patches. My own board is
working, but there are still a few things to fix. I will be out of
office for a few days and will continue to work on this afterwards.
For reference you can also look at my current working tree:
https://github.com/fschrempf/u-boot/commits/v2019.10-ktn-mx8mm.
Thanks,
Frieder
>
> This patchset only covers i.MX8MM and depends on the following patch
> to work,
> https://patchwork.ozlabs.org/cover/1144317/
> https://patchwork.ozlabs.org/patch/1142686/
> https://patchwork.ozlabs.org/patch/1142690/
> https://patchwork.ozlabs.org/patch/1142691/
> https://patchwork.ozlabs.org/patch/1143291/
> https://patchwork.ozlabs.org/patch/1143765/
>
> There is a README added, following that to test if you would like to.
>
> Peng Fan (21):
>tools: imx8m_image: align spl bin image size
>ddr: imx8m: fix ddr firmware location when enable SPL OF
>imx8m: add image cfg for i.MX8MM lpddr4
>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: 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
>imx8m: rename clock to clock_imx8mq
>imx8m: restructure clock.h
>imx8m: add clk support for i.MX8MM
>arm: dts: import i.MX8MM dtsi
>arm: dts: add i.MX8MM pin func
>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-v3.h |4 +
> arch/arm/include/asm/mach-imx/sys_proto.h |8 +
> arch/arm/mach-imx/cpu.c| 12 +
> arch/arm/mach-imx/imx8m/Kconfig| 17 +-
> arch/arm/mach-imx/imx8m/Makefile |4 +-
> arch/arm/mach-imx/imx8m/clock_imx8mm.c | 306 +++
> .../arm/mach-imx/imx8m/{clock.c => clock_imx8mq.c} |5 +-
> arch/arm/mach-imx/imx8m/clock_slice.c | 63 +
> arch/arm/mach-imx/imx8m/imximage-8mm-lpddr4.cfg| 16 +
> arch/arm/mach-imx/imx8m/soc.c | 91 +-
> arch/arm/mach-imx/spl.c|8 +
> board/freescale/imx8mm_evk/Kconfig | 12 +
> board/freescale/imx8mm_evk/MAINTAINERS |6 +
> board/freescale/imx8mm_evk/Makefile| 12 +
> board/freescale/imx8mm_evk/imx8mm_evk.c| 90 +
> board/freescale/imx8mm_evk/lpddr4_timing.c | 1980
>
> board/freescale/imx8mm_evk/spl.c | 102 +
> configs/imx8mm_evk_defconfig | 70 +
> drivers/ddr/imx/imx8m/helper.c | 12 +-
> include/configs/imx8mm_evk.h | 164 ++
> include/dt-bindings/clock/imx8mm-clock.h | 253 +++
> tools/imx8m_image.sh |5 +-
> 33 files changed, 6533 insertions(+), 475 deletions(-)
> create mode 100644 arch/arm/dts/imx8mm-evk-u-boot.dtsi
> create mode 100644 arch/arm/dts/imx8mm-evk.dts
> create mode 100644 arch/arm/dts/imx8mm-pinfunc.h
> create mode 100644 arch/arm/dts/imx8mm.dtsi
> create mode 100644 arch/arm/include/asm/arch-imx8m/clock_imx8mm.h
> create mode 100644 arch/arm/include/asm/arch-imx8m/clock_imx8mq.h
> create mode 100644 arch/arm/include/asm/arch-imx8m/imx8mm_pins.h
> create mode 100644 arch/arm/mach-imx/imx8m/clock_imx8mm.c
> rename arch/arm/mach-imx/imx8m/{clock.c => clock_imx8mq.c} (99%)
> create mode 100644 arch/arm/mach-imx/imx8m/imximage-8mm-lpddr4.cfg
> create mode 100644 board/freescale/imx8mm_evk/Kconfig
> create mode 100644 board/freescale/imx8mm_evk/MAINTAINERS
> create mode 100644
Re: [U-Boot] [PATCH 22/22] imx: Add i.MX8MM EVK board support.
On 09.08.19 06:15, Peng Fan wrote:
> Add board and SoC dts
> Add ddr training code
> support SD/MMC/GPIO/PINCTRL/UART
>
> Signed-off-by: Peng Fan
> ---
> arch/arm/dts/Makefile |3 +-
> arch/arm/dts/imx8mm-evk-u-boot.dtsi| 92 ++
> arch/arm/dts/imx8mm-evk.dts| 235
> arch/arm/mach-imx/imx8m/Kconfig|7 +
> board/freescale/imx8mm_evk/Kconfig | 12 +
> board/freescale/imx8mm_evk/MAINTAINERS |6 +
> board/freescale/imx8mm_evk/Makefile| 12 +
> board/freescale/imx8mm_evk/imx8mm_evk.c| 90 ++
> board/freescale/imx8mm_evk/lpddr4_timing.c | 1980
>
> board/freescale/imx8mm_evk/spl.c | 102 ++
> configs/imx8mm_evk_defconfig | 70 +
> include/configs/imx8mm_evk.h | 164 +++
> 12 files changed, 2772 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/dts/imx8mm-evk-u-boot.dtsi
> create mode 100644 arch/arm/dts/imx8mm-evk.dts
> create mode 100644 board/freescale/imx8mm_evk/Kconfig
> create mode 100644 board/freescale/imx8mm_evk/MAINTAINERS
> create mode 100644 board/freescale/imx8mm_evk/Makefile
> create mode 100644 board/freescale/imx8mm_evk/imx8mm_evk.c
> create mode 100644 board/freescale/imx8mm_evk/lpddr4_timing.c
> create mode 100644 board/freescale/imx8mm_evk/spl.c
> create mode 100644 configs/imx8mm_evk_defconfig
> create mode 100644 include/configs/imx8mm_evk.h
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index ad4d2357bb..f7b674873f 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -622,7 +622,8 @@ dtb-$(CONFIG_ARCH_IMX8) += \
> fsl-imx8qxp-colibri.dtb \
> fsl-imx8qxp-mek.dtb
>
> -dtb-$(CONFIG_ARCH_IMX8M) += fsl-imx8mq-evk.dtb
> +dtb-$(CONFIG_ARCH_IMX8M) += fsl-imx8mq-evk.dtb \
> + imx8mm-evk.dtb
>
> dtb-$(CONFIG_RCAR_GEN2) += \
> r8a7790-lager-u-boot.dtb \
> diff --git a/arch/arm/dts/imx8mm-evk-u-boot.dtsi
> b/arch/arm/dts/imx8mm-evk-u-boot.dtsi
> new file mode 100644
> index 00..1095d36e31
> --- /dev/null
> +++ b/arch/arm/dts/imx8mm-evk-u-boot.dtsi
> @@ -0,0 +1,92 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2019 NXP
> + */
> +
> +&{/soc} {
> + u-boot,dm-pre-reloc;
> + u-boot,dm-spl;
> +};
> +
> + {
> + u-boot,dm-spl;
> + u-boot,dm-pre-reloc;
> +};
> +
> +_24m {
> + u-boot,dm-spl;
> + u-boot,dm-pre-reloc;
> +};
> +
> + {
> + u-boot,dm-spl;
> + u-boot,dm-pre-reloc;
> +};
> +
> + {
> + u-boot,dm-spl;
> +};
> +
> + {
> + u-boot,dm-spl;
> +};
> +
> + {
> + u-boot,dm-spl;
> +};
> +
> +_reg_usdhc2_vmmc {
> + u-boot,dm-spl;
> +};
> +
> +_uart2 {
> + u-boot,dm-spl;
> +};
> +
> +_usdhc2_gpio {
> + u-boot,dm-spl;
> +};
> +
> +_usdhc2 {
> + u-boot,dm-spl;
> +};
> +
> +_usdhc3 {
> + u-boot,dm-spl;
> +};
> +
> + {
> + u-boot,dm-spl;
> +};
> +
> + {
> + u-boot,dm-spl;
> +};
> +
> + {
> + u-boot,dm-spl;
> +};
> +
> + {
> + u-boot,dm-spl;
> +};
> +
> + {
> + u-boot,dm-spl;
> +};
> +
> + {
> + u-boot,dm-spl;
> +};
> +
> + {
> + u-boot,dm-spl;
> +};
> +
> + {
> + u-boot,dm-spl;
> +};
> +
> + {
> + u-boot,dm-spl;
> +};
> diff --git a/arch/arm/dts/imx8mm-evk.dts b/arch/arm/dts/imx8mm-evk.dts
> new file mode 100644
> index 00..2d5d89475b
> --- /dev/null
> +++ b/arch/arm/dts/imx8mm-evk.dts
> @@ -0,0 +1,235 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright 2019 NXP
> + */
> +
> +/dts-v1/;
> +
> +#include "imx8mm.dtsi"
> +
> +/ {
> + model = "FSL i.MX8MM EVK board";
> + compatible = "fsl,imx8mm-evk", "fsl,imx8mm";
> +
> + chosen {
> + stdout-path =
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> + pinctrl-names = "default";
> + pinctrl-0 = <_gpio_led>;
> +
> + status {
> + label = "status";
> + gpios = < 16 GPIO_ACTIVE_HIGH>;
> + default-state = "on";
> + };
> + };
> +
> + reg_usdhc2_vmmc: regulator-usdhc2 {
> + compatible = "regulator-fixed";
> + pinctrl-names = "default";
> + pinctrl-0 = <_reg_usdhc2_vmmc>;
> + regulator-name = "VSD_3V3";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + gpio = < 19 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + };
> +};
> +
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_fec1>;
> + phy-mode = "rgmii-id";
> + phy-handle = <>;
> + fsl,magic-packet;
> + status = "okay";
> +
> + mdio {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ethphy0: ethernet-phy@0 {
> + compatible = "ethernet-phy-ieee802.3-c22";
> + reg = <0>;
> +
Re: [U-Boot] [PATCH 09/22] imx8m: update imx-regs for i.MX8MM
On 09.08.19 06:15, Peng Fan wrote:
> i.MX8MM has similar architecture with i.MX8MQ, but it has totally
> different PLL design and some register layout change.
>
> Note: Some registers in this file are not updated because not used now.
I think this is a bad idea. There seem to be many differences in the
register addresses between i.MX8M and i.MX8MM and you are leaving the
values for i.MX8M to be set also when i.MX8MM is used.
This might not hurt now when those things are not used. But as soon as
someone (like me) uses some more peripherals, they will run into serious
problems because certain register base addresses are wrong.
You should at least disable the unused macros for i.MX8MM, so we will
get a build error instead of using wrong address values without
noticing. Or even better go through the values and fix them for i.MX8MM.
Maybe it would be even cleaner to add a separate file for i.MX8MM if
they differ too much.
>
> Signed-off-by: Peng Fan
> ---
> arch/arm/include/asm/arch-imx8m/imx-regs.h | 75
> --
> 1 file changed, 71 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/include/asm/arch-imx8m/imx-regs.h
> b/arch/arm/include/asm/arch-imx8m/imx-regs.h
> index 68666a535b..a5be2e85da 100644
> --- a/arch/arm/include/asm/arch-imx8m/imx-regs.h
> +++ b/arch/arm/include/asm/arch-imx8m/imx-regs.h
> @@ -10,8 +10,8 @@
>
> #include
>
> -#define ROM_VERSION_A0 0x800
> -#define ROM_VERSION_B0 0x83C
> +#define ROM_VERSION_A0 IS_ENABLED(CONFIG_IMX8MQ) ? 0x800 :
> 0x800
> +#define ROM_VERSION_B0 IS_ENABLED(CONFIG_IMX8MQ) ? 0x83C :
> 0x800
>
> #define M4_BOOTROM_BASE_ADDR0x007E
>
> @@ -93,7 +93,11 @@
> #define SEMAPHOR_HS_BASE_ADDR 0x30AC
> #define USDHC1_BASE_ADDR0x30B4
> #define USDHC2_BASE_ADDR0x30B5
> +#ifdef CONFIG_IMX8MM
> +#define USDHC3_BASE_ADDR 0x30B6
> +#else
> #define MIPI_CS2_BASE_ADDR 0x30B6
> +#endif
> #define MIPI_CSI_PHY2_BASE_ADDR 0x30B7
> #define CSI2_BASE_ADDR 0x30B8
> #define QSPI0_BASE_ADDR 0x30BB
> @@ -120,7 +124,8 @@
> #define USB1_PHY_BASE_ADDR 0x381F
> #define USB2_PHY_BASE_ADDR 0x382F
>
> -#define MXS_LCDIF_BASE LCDIF_BASE_ADDR
> +#define MXS_LCDIF_BASE is_enable(CONFIG_IMX8MQ) ? \
> + 0x3032 : 0x32e0
>
> #define SRC_IPS_BASE_ADDR 0x3039
> #define SRC_DDRC_RCR_ADDR 0x30391000
> @@ -149,6 +154,9 @@
> #define SRC_DDR1_RCR_CORE_RESET_N_MASK BIT(1)
> #define SRC_DDR1_RCR_PRESET_N_MASK BIT(0)
>
> +#define IOMUXC_GPR_GPR1_GPR_ENET1_TX_CLK_SEL_MASK 0x2000u
> +#define IOMUXC_GPR_GPR1_GPR_ENET1_TX_CLK_SEL_SHIFT 13
> +
> struct iomuxc_gpr_base_regs {
> u32 gpr[47];
> };
> @@ -205,6 +213,7 @@ struct fuse_bank1_regs {
> u32 rsvd3[3];
> };
>
> +#ifdef CONFIG_IMX8MQ
> struct anamix_pll {
> u32 audio_pll1_cfg0;
> u32 audio_pll1_cfg1;
> @@ -239,6 +248,60 @@ struct anamix_pll {
> u32 frac_pllout_div_cfg;
> u32 sscg_pllout_div_cfg;
> };
> +#else
> +struct anamix_pll {
> + u32 audio_pll1_gnrl_ctl;
> + u32 audio_pll1_fdiv_ctl0;
> + u32 audio_pll1_fdiv_ctl1;
> + u32 audio_pll1_sscg_ctl;
> + u32 audio_pll1_mnit_ctl;
> + u32 audio_pll2_gnrl_ctl;
> + u32 audio_pll2_fdiv_ctl0;
> + u32 audio_pll2_fdiv_ctl1;
> + u32 audio_pll2_sscg_ctl;
> + u32 audio_pll2_mnit_ctl;
> + u32 video_pll1_gnrl_ctl;
> + u32 video_pll1_fdiv_ctl0;
> + u32 video_pll1_fdiv_ctl1;
> + u32 video_pll1_sscg_ctl;
> + u32 video_pll1_mnit_ctl;
> + u32 reserved[5];
> + u32 dram_pll_gnrl_ctl;
> + u32 dram_pll_fdiv_ctl0;
> + u32 dram_pll_fdiv_ctl1;
> + u32 dram_pll_sscg_ctl;
> + u32 dram_pll_mnit_ctl;
> + u32 gpu_pll_gnrl_ctl;
> + u32 gpu_pll_div_ctl;
> + u32 gpu_pll_locked_ctl1;
> + u32 gpu_pll_mnit_ctl;
> + u32 vpu_pll_gnrl_ctl;
> + u32 vpu_pll_div_ctl;
> + u32 vpu_pll_locked_ctl1;
> + u32 vpu_pll_mnit_ctl;
> + u32 arm_pll_gnrl_ctl;
> + u32 arm_pll_div_ctl;
> + u32 arm_pll_locked_ctl1;
> + u32 arm_pll_mnit_ctl;
> + u32 sys_pll1_gnrl_ctl;
> + u32 sys_pll1_div_ctl;
> + u32 sys_pll1_locked_ctl1;
> + u32 reserved2[24];
> + u32 sys_pll1_mnit_ctl;
> + u32 sys_pll2_gnrl_ctl;
> + u32 sys_pll2_div_ctl;
> + u32 sys_pll2_locked_ctl1;
> + u32 sys_pll2_mnit_ctl;
> + u32 sys_pll3_gnrl_ctl;
> + u32 sys_pll3_div_ctl;
> + u32 sys_pll3_locked_ctl1;
> + u32 sys_pll3_mnit_ctl;
> + u32 anamix_misc_ctl;
> + u32 anamix_clk_mnit_ctl;
> + u32 reserved3[437];
> + u32 digprog;
> +};
> +#endif
>
> struct fuse_bank9_regs {
> u32 mac_addr0;
> @@ -258,11 +321,13 @@ struct src {
> u32 usbophy2_rcr;
> u32 mipiphy_rcr;
> u32 pciephy_rcr;
> + /* Exits on i.MX8MQ */
Re: [U-Boot] [EXT] Re: [PATCH 1/6] spi: fsl_qspi: Fix DDR mode setting for latest iMX platforms
Sorry, I hit the "Send" button too early ;) On 14.08.19 14:07, Frieder Schrempf wrote: > 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. Does this work correctly in Linux, or does the Linux driver need fixes? > >> Please suggest way forward. How to correct this issue? The first thigh would be to make sure the Linux driver works for all platforms and then do the porting to U-Boot. I will be out of office for 10 days. After that I can try to work on this, but I need support and testing for other platforms. I only have i.MX6UL/ULL. Thanks, Frieder >> >> 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%2F507260data=02%7C01%7CAshish.Kumar >>> %40nxp.com%7C8882d5662295468a45b008d720abd98c%7C686ea1d3bc2b4c >>> 6fa92cd99c5c301635%7C0%7C0%7C637013794778063281sdata=Za7LB >>> 6RyXAHszPfiEMLDb%2FvVNSTQJwxHFtiapmNi3Co%3Dreserved=0 >>> [2] >>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub >>> .com%2Ffschrempf%2Fu- >>> boot%2Fcommits%2Ffsl_qspi_spimem_portdata=02%7C01%7CAshish. >>> Kumar%40nxp.com%7C8882d5662295468a45b008d720abd98c%7C686ea1d3 >>> bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637013794778063281sdata >>> =kYDjrs2a9DdL8QLFPORfHsMSWvgUxhSTgNC3WLziu7Y%3Dreserved=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, >mcr, >>>>
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%2F507260data=02%7C01%7CAshish.Kumar >> %40nxp.com%7C8882d5662295468a45b008d720abd98c%7C686ea1d3bc2b4c >> 6fa92cd99c5c301635%7C0%7C0%7C637013794778063281sdata=Za7LB >> 6RyXAHszPfiEMLDb%2FvVNSTQJwxHFtiapmNi3Co%3Dreserved=0 >> [2] >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub >> .com%2Ffschrempf%2Fu- >> boot%2Fcommits%2Ffsl_qspi_spimem_portdata=02%7C01%7CAshish. >> Kumar%40nxp.com%7C8882d5662295468a45b008d720abd98c%7C686ea1d3 >> bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637013794778063281sdata >> =kYDjrs2a9DdL8QLFPORfHsMSWvgUxhSTgNC3WLziu7Y%3Dreserved=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, >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, >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, >flshcr); >>> + reg &= ~(BIT(17)); &g
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, >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, >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, >flshcr); > + reg &= ~(BIT(17)); > + reg |= BIT(16); > + qspi_write32(priv->flags, >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, >mcr); > qspi_write32(priv->flags, >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, >rbct, QSPI_RBCT_RXBRD_USEIPS); > > qspi_write32(priv->flags, >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, >mcr); > qspi_write32(priv->flags, >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, >rbct, QSPI_RBCT_RXBRD_USEIPS); > > qspi_write32(priv->flags, >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, >mcr); > qspi_write32(priv->flags, >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, >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, >mcr); > qspi_write32(priv->flags, >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, >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, >mcr); > qspi_write32(priv->flags, >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, >rbct, QSPI_RBCT_RXBRD_USEIPS); > > qspi_write32(priv->flags, >sfar, priv->cur_amba_base); > @@ -737,7 +745,7 @@ static void qspi_op_erase(struct
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 = < IMX8MM_CLK_DUMMY>,
> + < IMX8MM_CLK_NAND_USDHC_BUS>,
> + < IMX8MM_CLK_USDHC1_ROOT>;
> + clock-names = "ipg", "ahb", "per";
> + assigned-clocks = < 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 = < IMX8MM_CLK_DUMMY>,
> + < IMX8MM_CLK_NAND_USDHC_BUS>,
> + < 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 = < IMX8MM_CLK_DUMMY>,
> + < IMX8MM_CLK_NAND_USDHC_BUS>,
> + < IMX8MM_CLK_USDHC3_ROOT>;
> + clock-names = "ipg", "ahb", "per";
> + assigned-clocks = < 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 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(_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, _bus->per_clk);
>> +if (ret) {
>> +printf("Failed to get i2c clk\n");
>> +return ret;
>> +}
>> +ret = clk_enable(_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(_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
