[PATCH v2] dm: Fix OF_BAD_ADDR definition
When OF_LIVE flag is enabled on a 64 bits platform, there is an
issue when dev_read_addr() is called and need to perform an address
translation using __of_translate_address().
In case of error, __of_translate_address() return's value is OF_BAD_ADDR
(wich is defined in include/dm/of.h to ((u64)-1) = 0x).
The return value of dev_read_addr() is often compared to FDT_ADDR_T_NONE
which is defined as (-1U) = 0x.
In this case the comparison is always false.
To fix this issue, define FDT_ADDR_T_NONE to (ulong)(-1) in case of
AARCH64. Update accordingly related tests.
Signed-off-by: Patrice Chotard
---
Changes in v2:
- define FDT_ADDR_T_NONE as ((ulong)(-1)) and keep OF_BAD_ADDR unchanged
include/fdtdec.h | 5 -
test/dm/ofnode.c | 2 +-
test/dm/pci.c | 4 ++--
test/dm/test-fdt.c | 2 +-
4 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/include/fdtdec.h b/include/fdtdec.h
index 6c7ab887b2..e9e2916d6e 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -24,16 +24,19 @@
typedef phys_addr_t fdt_addr_t;
typedef phys_size_t fdt_size_t;
-#define FDT_ADDR_T_NONE (-1U)
#define FDT_SIZE_T_NONE (-1U)
#ifdef CONFIG_PHYS_64BIT
+#define FDT_ADDR_T_NONE ((ulong)(-1))
+
#define fdt_addr_to_cpu(reg) be64_to_cpu(reg)
#define fdt_size_to_cpu(reg) be64_to_cpu(reg)
#define cpu_to_fdt_addr(reg) cpu_to_be64(reg)
#define cpu_to_fdt_size(reg) cpu_to_be64(reg)
typedef fdt64_t fdt_val_t;
#else
+#define FDT_ADDR_T_NONE (-1U)
+
#define fdt_addr_to_cpu(reg) be32_to_cpu(reg)
#define fdt_size_to_cpu(reg) be32_to_cpu(reg)
#define cpu_to_fdt_addr(reg) cpu_to_be32(reg)
diff --git a/test/dm/ofnode.c b/test/dm/ofnode.c
index cea0746bb3..e6c925eba6 100644
--- a/test/dm/ofnode.c
+++ b/test/dm/ofnode.c
@@ -286,7 +286,7 @@ static int dm_test_ofnode_get_reg(struct unit_test_state
*uts)
ut_assert(ofnode_valid(node));
addr = ofnode_get_addr(node);
size = ofnode_get_size(node);
- ut_asserteq(FDT_ADDR_T_NONE, addr);
+ ut_asserteq_64(FDT_ADDR_T_NONE, addr);
ut_asserteq(FDT_SIZE_T_NONE, size);
node = ofnode_path("/translation-test@8000/noxlatebus@3,300/dev@42");
diff --git a/test/dm/pci.c b/test/dm/pci.c
index fa2e4a8559..00e4440a9d 100644
--- a/test/dm/pci.c
+++ b/test/dm/pci.c
@@ -331,10 +331,10 @@ static int dm_test_pci_addr_live(struct unit_test_state
*uts)
struct udevice *swap1f, *swap1;
ut_assertok(dm_pci_bus_find_bdf(PCI_BDF(0, 0x1f, 0), ));
- ut_asserteq(FDT_ADDR_T_NONE, dev_read_addr_pci(swap1f));
+ ut_asserteq_64(FDT_ADDR_T_NONE, dev_read_addr_pci(swap1f));
ut_assertok(dm_pci_bus_find_bdf(PCI_BDF(0, 0x1, 0), ));
- ut_asserteq(FDT_ADDR_T_NONE, dev_read_addr_pci(swap1));
+ ut_asserteq_64(FDT_ADDR_T_NONE, dev_read_addr_pci(swap1));
return 0;
}
diff --git a/test/dm/test-fdt.c b/test/dm/test-fdt.c
index 8866d4d959..e1de066226 100644
--- a/test/dm/test-fdt.c
+++ b/test/dm/test-fdt.c
@@ -768,7 +768,7 @@ static int dm_test_fdt_livetree_writing(struct
unit_test_state *uts)
/* Test setting generic properties */
/* Non-existent in DTB */
- ut_asserteq(FDT_ADDR_T_NONE, dev_read_addr(dev));
+ ut_asserteq_64(FDT_ADDR_T_NONE, dev_read_addr(dev));
/* reg = 0x42, size = 0x100 */
ut_assertok(ofnode_write_prop(node, "reg", 8,
"\x00\x00\x00\x42\x00\x00\x01\x00"));
--
2.17.1
Re: [PATCH] dm: Fix OF_BAD_ADDR definition
Hi Simon
On 12/24/21 2:17 PM, Simon Glass wrote:
> Hi Patrice,
>
> On Thu, 23 Dec 2021 at 09:09, Patrice Chotard
> wrote:
>>
>> When OF_LIVE flag is enabled on a 64 bits platform, there is an
>> issue when dev_read_addr() is called and need to perform an address
>> translation using __of_translate_address().
>>
>> In case of error, __of_translate_address() return value is OF_BAD_ADDR
>> (wich is defined in include/dm/of.h to ((u64)-1) = 0x).
>> The return value of dev_read_addr() is often compared to FDT_ADDR_T_NONE
>> which is defined as (-1U) = 0x.
>> In this case the comparison is always false.
>>
>> To fix this issue, define OF_BAD_ADDR to FDT_ADDR_T_NONE.
>>
>> Signed-off-by: Patrice Chotard
>> ---
>>
>> include/dm/of.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Would it be better to define FDT_ADDR_T_NONE as something like ((ulong)(-1)) ?
Agree, a v2 will be sent soon.
Thanks
Patrice
>>
>> diff --git a/include/dm/of.h b/include/dm/of.h
>> index 5cb6f44a6c..0208cc234a 100644
>> --- a/include/dm/of.h
>> +++ b/include/dm/of.h
>> @@ -95,7 +95,7 @@ static inline bool of_live_active(void)
>> return gd_of_root() != NULL;
>> }
>>
>> -#define OF_BAD_ADDR((u64)-1)
>> +#define OF_BAD_ADDRFDT_ADDR_T_NONE
>>
>> static inline const char *of_node_full_name(const struct device_node *np)
>> {
>> --
>> 2.17.1
>>
>
> Regards,
> Simon
>
RE: [EXT] Re: [PATCH v7 05/15] i.MX6: Enable Job ring driver model in U-Boot.
Hi
> -Original Message-
> From: Simon Glass
> Sent: Tuesday, December 28, 2021 2:03 PM
> To: Gaurav Jain
> Cc: U-Boot Mailing List ; Stefano Babic
> ; Fabio Estevam ; Peng Fan
> ; Priyanka Jain ; Ye Li
> ; Horia Geanta ; Ji Luo
> ; Franck Lenormand ; Silvano Di
> Ninno ; Sahil Malhotra ;
> Pankaj Gupta ; Varun Sethi ; dl-
> uboot-imx ; Shengzhou Liu ;
> Mingkai Hu ; Rajesh Bhagat ;
> Meenakshi Aggarwal ; Wasim Khan
> ; Alison Wang ; Pramod
> Kumar ; Andy Tang ;
> Adrian Alonso ; Vladimir Oltean
> Subject: [EXT] Re: [PATCH v7 05/15] i.MX6: Enable Job ring driver model in U-
> Boot.
>
> Caution: EXT Email
>
> Hi,
>
> On Tue, 7 Dec 2021 at 00:42, Gaurav Jain wrote:
> >
> > i.MX6,i.MX6SX,i.MX6UL - added support for JR driver model.
> >
> > removed sec_init() call, sec is initialized based on job ring
> > information processed from device tree.
> >
> > Signed-off-by: Gaurav Jain
> > Reviewed-by: Ye Li
> > ---
> > arch/arm/mach-imx/mx6/Kconfig | 15 +++
> > arch/arm/mach-imx/mx6/soc.c | 12
> > 2 files changed, 23 insertions(+), 4 deletions(-)
> >
>
> Tiny nit...we know this is U-Boot so you don't really need
Ok..
> > diff --git a/arch/arm/mach-imx/mx6/Kconfig
> > b/arch/arm/mach-imx/mx6/Kconfig index 62de942a32..8ccb3b6e35 100644
> > --- a/arch/arm/mach-imx/mx6/Kconfig
> > +++ b/arch/arm/mach-imx/mx6/Kconfig
> > @@ -354,6 +354,9 @@ config TARGET_MX6SABREAUTO
> > select DM_THERMAL
> > select SUPPORT_SPL
> > imply CMD_DM
> > + select FSL_CAAM
> > + select MISC
> > + select ARCH_MISC_INIT
> >
> > config TARGET_MX6SABRESD
> > bool "mx6sabresd"
> > @@ -364,6 +367,9 @@ config TARGET_MX6SABRESD
> > select DM_THERMAL
> > select SUPPORT_SPL
> > imply CMD_DM
> > + select FSL_CAAM
> > + select MISC
> > + select ARCH_MISC_INIT
> >
> > config TARGET_MX6SLEVK
> > bool "mx6slevk"
> > @@ -386,6 +392,9 @@ config TARGET_MX6SXSABRESD
> > select DM
> > select DM_THERMAL
> > select SUPPORT_SPL
> > + select FSL_CAAM
> > + select MISC
> > + select ARCH_MISC_INIT
> >
> > config TARGET_MX6SXSABREAUTO
> > bool "mx6sxsabreauto"
> > @@ -404,6 +413,9 @@ config TARGET_MX6UL_9X9_EVK
> > select DM_THERMAL
> > select SUPPORT_SPL
> > imply CMD_DM
> > + select FSL_CAAM
> > + select MISC
> > + select ARCH_MISC_INIT
> >
> > config TARGET_MX6UL_14X14_EVK
> > bool "mx6ul_14x14_evk"
> > @@ -413,6 +425,9 @@ config TARGET_MX6UL_14X14_EVK
> > select DM_THERMAL
> > select SUPPORT_SPL
> > imply CMD_DM
> > + select FSL_CAAM
> > + select MISC
> > + select ARCH_MISC_INIT
> >
> > config TARGET_MX6UL_ENGICAM
> > bool "Support Engicam GEAM6UL/Is.IoT"
> > diff --git a/arch/arm/mach-imx/mx6/soc.c b/arch/arm/mach-imx/mx6/soc.c
> > index aacfc854a2..fa6c3778bb 100644
> > --- a/arch/arm/mach-imx/mx6/soc.c
> > +++ b/arch/arm/mach-imx/mx6/soc.c
> > @@ -4,6 +4,7 @@
> > * Sascha Hauer, Pengutronix
> > *
> > * (C) Copyright 2009 Freescale Semiconductor, Inc.
> > + * Copyright 2021 NXP
> > */
> >
> > #include
> > @@ -23,7 +24,6 @@
> > #include
> > #include
> > #include
> > -#include
> > #include
> > #include
> >
> > @@ -734,9 +734,13 @@ static void setup_serial_number(void)
> >
> > int arch_misc_init(void)
> > {
> > -#ifdef CONFIG_FSL_CAAM
> > - sec_init();
> > -#endif
> > + struct udevice *dev;
> > + int ret;
> > +
> > + ret = uclass_get_device_by_driver(UCLASS_MISC,
> > + DM_DRIVER_GET(caam_jr), );
>
> You could use a board driver perhaps, to specify the phandle of the device you
> want to access. Or, if you used a separate uclass, you could just get the
> first
> device.
Probe is also called from this API which is satisfying driver requirement.
>
> > + if (ret)
> > + printf("Failed to initialize %s: %d\n", dev->name,
> > + ret);
>
> Shouldn't you return the error here?
It is done intentionally as we do not want to report error but to print the
fail log only.
Regards
Gaurav Jain
>
> > +
> > setup_serial_number();
> > return 0;
> > }
> > --
> > 2.17.1
> >
>
> Regards,
> Simon
Re: [PATCH] net: fsl_mdio: Fix busy flag polling register
On Sun, Jan 2, 2022 at 7:36 PM Markus Koch wrote:
>
> NXP's mEMAC reference manual, Chapter 6.5.5 "MDIO Ethernet Management
> Interface usage", specifies to poll the BSY (0) bit in the CFG (we call
> it CTL) register to wait until a transaction has finished, not bit 31 in
> the data register.
>
> In the Linux kernel, this has already been fixed in commit 26eee0210ad7
> ("net/fsl: fix a bug in xgmac_mdio").
>
> Signed-off-by: Markus Koch
> ---
>
> I only stumbled over this section of code while looking at something else, but
> I'm surprised this even works the way it is now. Maybe it's luck.
>
> Sadly I have not yet had the chance to test this change on actual hardware,
> and
> I'm not sure I will anytime soon, so I'm asking whether there's anyone who
> could compile and run my code to see whether MDIO transactions work as
> expected.
>
> Thanks!
> Markus
>
> drivers/net/fm/memac_phy.c | 2 +-
> include/fsl_memac.h| 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/fm/memac_phy.c b/drivers/net/fm/memac_phy.c
> index 72b500a6d1..0af6e83a8f 100644
> --- a/drivers/net/fm/memac_phy.c
> +++ b/drivers/net/fm/memac_phy.c
> @@ -64,7 +64,7 @@ static int memac_wait_until_done(struct
> memac_mdio_controller *regs)
> {
> unsigned int timeout = MAX_NUM_RETRIES;
>
> - while ((memac_in_32(>mdio_data) & MDIO_DATA_BSY) && timeout--)
> + while ((memac_in_32(>mdio_ctl) & MDIO_CTL_BSY) && timeout--)
> ;
>
> if (!timeout) {
> diff --git a/include/fsl_memac.h b/include/fsl_memac.h
> index d067f1511c..d973fc0a5e 100644
> --- a/include/fsl_memac.h
> +++ b/include/fsl_memac.h
> @@ -246,6 +246,7 @@ struct memac_mdio_controller {
> #define MDIO_STAT_HOLD_15_CLK (7 << 2)
> #define MDIO_STAT_NEG (1 << 23)
>
> +#define MDIO_CTL_BSY (1 << 0)
> #define MDIO_CTL_DEV_ADDR(x) (x & 0x1f)
> #define MDIO_CTL_PORT_ADDR(x) ((x & 0x1f) << 5)
> #define MDIO_CTL_PRE_DIS (1 << 10)
> @@ -254,7 +255,6 @@ struct memac_mdio_controller {
> #define MDIO_CTL_READ (1 << 15)
>
> #define MDIO_DATA(x) (x & 0x)
> -#define MDIO_DATA_BSY (1 << 31)
>
> struct fsl_enet_mac;
>
> --
> 2.34.1
>
Reviewed-by: Ramon Fried
Re: [PATCH V2] usb: ehci-mx6: Enable OTG detection on imx8mm and imx8mn
On Mon, Jan 3, 2022 at 2:32 PM Adam Ford wrote:
>
>
>
> On Mon, Jan 3, 2022 at 10:20 PM Tim Harvey wrote:
>>
>> On Thu, Dec 23, 2021 at 6:08 AM Adam Ford wrote:
>> >
>> > The imx8mm and imx8mn appear compatible with imx7d-usb
>> > flags in the OTG driver. If the dr_mode is defined as
>> > host or peripheral, the device appears to operate correctly,
>> > however the auto host/peripheral detection results in an error.
>> >
>> > The solution isn't just adding checks for imx8mm and imx8mn to
>> > the check for imx7, because the USB clock needs to be running
>> > to read from the USBNC_PHY_STATUS_OFFSET register or it will hang.
>> >
>> > The init_type in both priv and plat data are the same, so it doesn't
>> > make sense to configure the data in the plat data and copy the
>> > data to priv when priv can be configured directly. Instead, rename
>> > ehci_usb_of_to_plat to ehci_usb_dr_mode and call it from the
>> > probe functions after the clocks are enabled, but before the data
>> > is required.
>> >
>> > With that added, the additional checks for imx8mm and imx8mn will
>> > allow reading the register to automatically determine the state
>> > (host or device) of the OTG controller.
>> >
>> > Signed-off-by: Adam Ford
>> > ---
>> > V2: Rename ehci_usb_of_to_plat to ehci_usb_dr_mode and call it
>> > from the probe after the clocks are enabled, but before
>> > the data is needed.
>> >
>> > diff --git a/drivers/usb/host/ehci-mx6.c b/drivers/usb/host/ehci-mx6.c
>> > index 1bd6147c76..f2a34b7f06 100644
>> > --- a/drivers/usb/host/ehci-mx6.c
>> > +++ b/drivers/usb/host/ehci-mx6.c
>> > @@ -513,7 +513,7 @@ static const struct ehci_ops mx6_ehci_ops = {
>> >
>> > static int ehci_usb_phy_mode(struct udevice *dev)
>> > {
>> > - struct usb_plat *plat = dev_get_plat(dev);
>> > + struct ehci_mx6_priv_data *priv = dev_get_priv(dev);
>> > void *__iomem addr = dev_read_addr_ptr(dev);
>> > void *__iomem phy_ctrl, *__iomem phy_status;
>> > const void *blob = gd->fdt_blob;
>> > @@ -540,18 +540,18 @@ static int ehci_usb_phy_mode(struct udevice *dev)
>> > val = readl(phy_ctrl);
>> >
>> > if (val & USBPHY_CTRL_OTG_ID)
>> > - plat->init_type = USB_INIT_DEVICE;
>> > + priv->init_type = USB_INIT_DEVICE;
>> > else
>> > - plat->init_type = USB_INIT_HOST;
>> > - } else if (is_mx7()) {
>> > + priv->init_type = USB_INIT_HOST;
>> > + } else if (is_mx7() || is_imx8mm() || is_imx8mn()) {
>> > phy_status = (void __iomem *)(addr +
>> > USBNC_PHY_STATUS_OFFSET);
>> > val = readl(phy_status);
>> >
>> > if (val & USBNC_PHYSTATUS_ID_DIG)
>> > - plat->init_type = USB_INIT_DEVICE;
>> > + priv->init_type = USB_INIT_DEVICE;
>> > else
>> > - plat->init_type = USB_INIT_HOST;
>> > + priv->init_type = USB_INIT_HOST;
>> > } else {
>> > return -EINVAL;
>> > }
>> > @@ -559,19 +559,19 @@ static int ehci_usb_phy_mode(struct udevice *dev)
>> > return 0;
>> > }
>> >
>> > -static int ehci_usb_of_to_plat(struct udevice *dev)
>> > +static int ehci_usb_dr_mode(struct udevice *dev)
>> > {
>> > - struct usb_plat *plat = dev_get_plat(dev);
>> > + struct ehci_mx6_priv_data *priv = dev_get_priv(dev);
>> > enum usb_dr_mode dr_mode;
>> >
>> > dr_mode = usb_get_dr_mode(dev_ofnode(dev));
>> >
>> > switch (dr_mode) {
>> > case USB_DR_MODE_HOST:
>> > - plat->init_type = USB_INIT_HOST;
>> > + priv->init_type = USB_INIT_HOST;
>> > break;
>> > case USB_DR_MODE_PERIPHERAL:
>> > - plat->init_type = USB_INIT_DEVICE;
>> > + priv->init_type = USB_INIT_DEVICE;
>> > break;
>> > case USB_DR_MODE_OTG:
>> > case USB_DR_MODE_UNKNOWN:
>> > @@ -639,10 +639,8 @@ static int mx6_parse_dt_addrs(struct udevice *dev)
>> >
>> > static int ehci_usb_probe(struct udevice *dev)
>> > {
>> > - struct usb_plat *plat = dev_get_plat(dev);
>> > struct usb_ehci *ehci = dev_read_addr_ptr(dev);
>> > struct ehci_mx6_priv_data *priv = dev_get_priv(dev);
>> > - enum usb_init_type type = plat->init_type;
>> > struct ehci_hccr *hccr;
>> > struct ehci_hcor *hcor;
>> > int ret;
>> > @@ -660,8 +658,6 @@ static int ehci_usb_probe(struct udevice *dev)
>> > return ret;
>> >
>> > priv->ehci = ehci;
>> > - priv->init_type = type;
>> > - priv->phy_type = usb_get_phy_mode(dev_ofnode(dev));
>> >
>> > #if CONFIG_IS_ENABLED(CLK)
>> > ret = clk_get_by_index(dev, 0, >clk);
>> > @@ -677,6 +673,11 @@ static int ehci_usb_probe(struct udevice *dev)
>> >
Re: [PATCH v3 00/12] fsl_esdhc_imx: port several patches from fsl_esdhc
Dear Sean,
On 11/24/21 5:03 AM, Sean Anderson wrote:
> This series ports some of the patches from fsl_esdhc to fsl_esdhc_imx.
> Because these drivers share a common lineage, many of these patches
> apply with minor changes. For each one, I have noted the originating
> commit in the style of linux stable backports. Where I have had to
> modify patches, I have noted the changes I have made before my SoB.
>
> In fa33d20749 ("mmc: split fsl_esdhc driver for i.MX"), Yangbo says
>
>> For the two series processors, the eSDHCs are becoming more and more
>> different
>
> However, these drivers are still extremely similar; the differences
> between them are not major. NXP has not done a good job of porting
> patches which apply to both drivers. This causes the fsl_esdhc_imx
> driver to rot, as the fsl_esdhc gets more general fixes. For this
> reason, I think that the fsl_esdhc_imx driver should be removed unless
> NXP can commit to creating series like this which port patches which
> apply to both drivers.
Sorry for too late.
I had been tried to applied this series from patchwork, but i can't see [PATCH
v3 01/12].
Best Regards,
Jaehoon Chung
>
> Changes in v3:
> - Drop Kconfig BLK dependency
> - Fix build error caused by unconverted OF_PLATDATA code
> - Replace more #ifdefs by if
>
> Changes in v2:
> - Use a switch statement instead of ifs for max_bus_width
> - Only default to 8 bit width when max_bus_width is not set
>
> Sean Anderson (12):
> mmc: fsl_esdhc_imx: make BLK as hard requirement of DM_MMC
> mmc: fsl_esdhc_imx: remove redundant DM_MMC checking
> mmc: fsl_esdhc_imx: fix voltage validation
> mmc: fsl_esdhc_imx: clean up bus width configuration code
> mmc: fsl_esdhc_imx: drop redundant code for non-removable feature
> mmc: fsl_esdhc_imx: fix mmc->clock with actual clock
> mmc: fsl_esdhc_imx: simplify 64bit check for SDMA transfers
> mmc: fsl_esdhc_imx: use dma-mapping API
> mmc: fsl_esdhc_imx: simplify esdhc_setup_data()
> mmc: fsl_esdhc_imx: replace most #ifdefs by IS_ENABLED()
> mmc: fsl_esdhc_imx: Replace more #ifdefs by if
> mmc: fsl_esdhc_imx: set sysctl register for clock initialization
>
> drivers/mmc/fsl_esdhc_imx.c | 643 ++--
> include/fsl_esdhc_imx.h | 14 +-
> 2 files changed, 263 insertions(+), 394 deletions(-)
>
Re: [PATCH V2] usb: ehci-mx6: Enable OTG detection on imx8mm and imx8mn
On Mon, Jan 3, 2022 at 10:20 PM Tim Harvey wrote:
> On Thu, Dec 23, 2021 at 6:08 AM Adam Ford wrote:
> >
> > The imx8mm and imx8mn appear compatible with imx7d-usb
> > flags in the OTG driver. If the dr_mode is defined as
> > host or peripheral, the device appears to operate correctly,
> > however the auto host/peripheral detection results in an error.
> >
> > The solution isn't just adding checks for imx8mm and imx8mn to
> > the check for imx7, because the USB clock needs to be running
> > to read from the USBNC_PHY_STATUS_OFFSET register or it will hang.
> >
> > The init_type in both priv and plat data are the same, so it doesn't
> > make sense to configure the data in the plat data and copy the
> > data to priv when priv can be configured directly. Instead, rename
> > ehci_usb_of_to_plat to ehci_usb_dr_mode and call it from the
> > probe functions after the clocks are enabled, but before the data
> > is required.
> >
> > With that added, the additional checks for imx8mm and imx8mn will
> > allow reading the register to automatically determine the state
> > (host or device) of the OTG controller.
> >
> > Signed-off-by: Adam Ford
> > ---
> > V2: Rename ehci_usb_of_to_plat to ehci_usb_dr_mode and call it
> > from the probe after the clocks are enabled, but before
> > the data is needed.
> >
> > diff --git a/drivers/usb/host/ehci-mx6.c b/drivers/usb/host/ehci-mx6.c
> > index 1bd6147c76..f2a34b7f06 100644
> > --- a/drivers/usb/host/ehci-mx6.c
> > +++ b/drivers/usb/host/ehci-mx6.c
> > @@ -513,7 +513,7 @@ static const struct ehci_ops mx6_ehci_ops = {
> >
> > static int ehci_usb_phy_mode(struct udevice *dev)
> > {
> > - struct usb_plat *plat = dev_get_plat(dev);
> > + struct ehci_mx6_priv_data *priv = dev_get_priv(dev);
> > void *__iomem addr = dev_read_addr_ptr(dev);
> > void *__iomem phy_ctrl, *__iomem phy_status;
> > const void *blob = gd->fdt_blob;
> > @@ -540,18 +540,18 @@ static int ehci_usb_phy_mode(struct udevice *dev)
> > val = readl(phy_ctrl);
> >
> > if (val & USBPHY_CTRL_OTG_ID)
> > - plat->init_type = USB_INIT_DEVICE;
> > + priv->init_type = USB_INIT_DEVICE;
> > else
> > - plat->init_type = USB_INIT_HOST;
> > - } else if (is_mx7()) {
> > + priv->init_type = USB_INIT_HOST;
> > + } else if (is_mx7() || is_imx8mm() || is_imx8mn()) {
> > phy_status = (void __iomem *)(addr +
> > USBNC_PHY_STATUS_OFFSET);
> > val = readl(phy_status);
> >
> > if (val & USBNC_PHYSTATUS_ID_DIG)
> > - plat->init_type = USB_INIT_DEVICE;
> > + priv->init_type = USB_INIT_DEVICE;
> > else
> > - plat->init_type = USB_INIT_HOST;
> > + priv->init_type = USB_INIT_HOST;
> > } else {
> > return -EINVAL;
> > }
> > @@ -559,19 +559,19 @@ static int ehci_usb_phy_mode(struct udevice *dev)
> > return 0;
> > }
> >
> > -static int ehci_usb_of_to_plat(struct udevice *dev)
> > +static int ehci_usb_dr_mode(struct udevice *dev)
> > {
> > - struct usb_plat *plat = dev_get_plat(dev);
> > + struct ehci_mx6_priv_data *priv = dev_get_priv(dev);
> > enum usb_dr_mode dr_mode;
> >
> > dr_mode = usb_get_dr_mode(dev_ofnode(dev));
> >
> > switch (dr_mode) {
> > case USB_DR_MODE_HOST:
> > - plat->init_type = USB_INIT_HOST;
> > + priv->init_type = USB_INIT_HOST;
> > break;
> > case USB_DR_MODE_PERIPHERAL:
> > - plat->init_type = USB_INIT_DEVICE;
> > + priv->init_type = USB_INIT_DEVICE;
> > break;
> > case USB_DR_MODE_OTG:
> > case USB_DR_MODE_UNKNOWN:
> > @@ -639,10 +639,8 @@ static int mx6_parse_dt_addrs(struct udevice *dev)
> >
> > static int ehci_usb_probe(struct udevice *dev)
> > {
> > - struct usb_plat *plat = dev_get_plat(dev);
> > struct usb_ehci *ehci = dev_read_addr_ptr(dev);
> > struct ehci_mx6_priv_data *priv = dev_get_priv(dev);
> > - enum usb_init_type type = plat->init_type;
> > struct ehci_hccr *hccr;
> > struct ehci_hcor *hcor;
> > int ret;
> > @@ -660,8 +658,6 @@ static int ehci_usb_probe(struct udevice *dev)
> > return ret;
> >
> > priv->ehci = ehci;
> > - priv->init_type = type;
> > - priv->phy_type = usb_get_phy_mode(dev_ofnode(dev));
> >
> > #if CONFIG_IS_ENABLED(CLK)
> > ret = clk_get_by_index(dev, 0, >clk);
> > @@ -677,6 +673,11 @@ static int ehci_usb_probe(struct udevice *dev)
> > mdelay(1);
> > #endif
> >
> > + ret = ehci_usb_dr_mode(dev);
> > + if (ret)
> > + goto err_clk;
> > + priv->phy_type =
Re: [PATCH V2] usb: ehci-mx6: Enable OTG detection on imx8mm and imx8mn
On Thu, Dec 23, 2021 at 6:08 AM Adam Ford wrote:
>
> The imx8mm and imx8mn appear compatible with imx7d-usb
> flags in the OTG driver. If the dr_mode is defined as
> host or peripheral, the device appears to operate correctly,
> however the auto host/peripheral detection results in an error.
>
> The solution isn't just adding checks for imx8mm and imx8mn to
> the check for imx7, because the USB clock needs to be running
> to read from the USBNC_PHY_STATUS_OFFSET register or it will hang.
>
> The init_type in both priv and plat data are the same, so it doesn't
> make sense to configure the data in the plat data and copy the
> data to priv when priv can be configured directly. Instead, rename
> ehci_usb_of_to_plat to ehci_usb_dr_mode and call it from the
> probe functions after the clocks are enabled, but before the data
> is required.
>
> With that added, the additional checks for imx8mm and imx8mn will
> allow reading the register to automatically determine the state
> (host or device) of the OTG controller.
>
> Signed-off-by: Adam Ford
> ---
> V2: Rename ehci_usb_of_to_plat to ehci_usb_dr_mode and call it
> from the probe after the clocks are enabled, but before
> the data is needed.
>
> diff --git a/drivers/usb/host/ehci-mx6.c b/drivers/usb/host/ehci-mx6.c
> index 1bd6147c76..f2a34b7f06 100644
> --- a/drivers/usb/host/ehci-mx6.c
> +++ b/drivers/usb/host/ehci-mx6.c
> @@ -513,7 +513,7 @@ static const struct ehci_ops mx6_ehci_ops = {
>
> static int ehci_usb_phy_mode(struct udevice *dev)
> {
> - struct usb_plat *plat = dev_get_plat(dev);
> + struct ehci_mx6_priv_data *priv = dev_get_priv(dev);
> void *__iomem addr = dev_read_addr_ptr(dev);
> void *__iomem phy_ctrl, *__iomem phy_status;
> const void *blob = gd->fdt_blob;
> @@ -540,18 +540,18 @@ static int ehci_usb_phy_mode(struct udevice *dev)
> val = readl(phy_ctrl);
>
> if (val & USBPHY_CTRL_OTG_ID)
> - plat->init_type = USB_INIT_DEVICE;
> + priv->init_type = USB_INIT_DEVICE;
> else
> - plat->init_type = USB_INIT_HOST;
> - } else if (is_mx7()) {
> + priv->init_type = USB_INIT_HOST;
> + } else if (is_mx7() || is_imx8mm() || is_imx8mn()) {
> phy_status = (void __iomem *)(addr +
> USBNC_PHY_STATUS_OFFSET);
> val = readl(phy_status);
>
> if (val & USBNC_PHYSTATUS_ID_DIG)
> - plat->init_type = USB_INIT_DEVICE;
> + priv->init_type = USB_INIT_DEVICE;
> else
> - plat->init_type = USB_INIT_HOST;
> + priv->init_type = USB_INIT_HOST;
> } else {
> return -EINVAL;
> }
> @@ -559,19 +559,19 @@ static int ehci_usb_phy_mode(struct udevice *dev)
> return 0;
> }
>
> -static int ehci_usb_of_to_plat(struct udevice *dev)
> +static int ehci_usb_dr_mode(struct udevice *dev)
> {
> - struct usb_plat *plat = dev_get_plat(dev);
> + struct ehci_mx6_priv_data *priv = dev_get_priv(dev);
> enum usb_dr_mode dr_mode;
>
> dr_mode = usb_get_dr_mode(dev_ofnode(dev));
>
> switch (dr_mode) {
> case USB_DR_MODE_HOST:
> - plat->init_type = USB_INIT_HOST;
> + priv->init_type = USB_INIT_HOST;
> break;
> case USB_DR_MODE_PERIPHERAL:
> - plat->init_type = USB_INIT_DEVICE;
> + priv->init_type = USB_INIT_DEVICE;
> break;
> case USB_DR_MODE_OTG:
> case USB_DR_MODE_UNKNOWN:
> @@ -639,10 +639,8 @@ static int mx6_parse_dt_addrs(struct udevice *dev)
>
> static int ehci_usb_probe(struct udevice *dev)
> {
> - struct usb_plat *plat = dev_get_plat(dev);
> struct usb_ehci *ehci = dev_read_addr_ptr(dev);
> struct ehci_mx6_priv_data *priv = dev_get_priv(dev);
> - enum usb_init_type type = plat->init_type;
> struct ehci_hccr *hccr;
> struct ehci_hcor *hcor;
> int ret;
> @@ -660,8 +658,6 @@ static int ehci_usb_probe(struct udevice *dev)
> return ret;
>
> priv->ehci = ehci;
> - priv->init_type = type;
> - priv->phy_type = usb_get_phy_mode(dev_ofnode(dev));
>
> #if CONFIG_IS_ENABLED(CLK)
> ret = clk_get_by_index(dev, 0, >clk);
> @@ -677,6 +673,11 @@ static int ehci_usb_probe(struct udevice *dev)
> mdelay(1);
> #endif
>
> + ret = ehci_usb_dr_mode(dev);
> + if (ret)
> + goto err_clk;
> + priv->phy_type = usb_get_phy_mode(dev_ofnode(dev));
> +
> #if CONFIG_IS_ENABLED(DM_REGULATOR)
> ret = device_get_supply_regulator(dev, "vbus-supply",
> >vbus_supply);
> @@ -700,7 +701,7 @@ static int ehci_usb_probe(struct udevice *dev)
> #if
[PATCH] net: fsl_mdio: Fix busy flag polling register
NXP's mEMAC reference manual, Chapter 6.5.5 "MDIO Ethernet Management
Interface usage", specifies to poll the BSY (0) bit in the CFG (we call
it CTL) register to wait until a transaction has finished, not bit 31 in
the data register.
In the Linux kernel, this has already been fixed in commit 26eee0210ad7
("net/fsl: fix a bug in xgmac_mdio").
Signed-off-by: Markus Koch
---
I only stumbled over this section of code while looking at something else, but
I'm surprised this even works the way it is now. Maybe it's luck.
Sadly I have not yet had the chance to test this change on actual hardware, and
I'm not sure I will anytime soon, so I'm asking whether there's anyone who
could compile and run my code to see whether MDIO transactions work as expected.
Thanks!
Markus
drivers/net/fm/memac_phy.c | 2 +-
include/fsl_memac.h| 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/fm/memac_phy.c b/drivers/net/fm/memac_phy.c
index 72b500a6d1..0af6e83a8f 100644
--- a/drivers/net/fm/memac_phy.c
+++ b/drivers/net/fm/memac_phy.c
@@ -64,7 +64,7 @@ static int memac_wait_until_done(struct memac_mdio_controller
*regs)
{
unsigned int timeout = MAX_NUM_RETRIES;
- while ((memac_in_32(>mdio_data) & MDIO_DATA_BSY) && timeout--)
+ while ((memac_in_32(>mdio_ctl) & MDIO_CTL_BSY) && timeout--)
;
if (!timeout) {
diff --git a/include/fsl_memac.h b/include/fsl_memac.h
index d067f1511c..d973fc0a5e 100644
--- a/include/fsl_memac.h
+++ b/include/fsl_memac.h
@@ -246,6 +246,7 @@ struct memac_mdio_controller {
#define MDIO_STAT_HOLD_15_CLK (7 << 2)
#define MDIO_STAT_NEG (1 << 23)
+#define MDIO_CTL_BSY (1 << 0)
#define MDIO_CTL_DEV_ADDR(x) (x & 0x1f)
#define MDIO_CTL_PORT_ADDR(x) ((x & 0x1f) << 5)
#define MDIO_CTL_PRE_DIS (1 << 10)
@@ -254,7 +255,6 @@ struct memac_mdio_controller {
#define MDIO_CTL_READ (1 << 15)
#define MDIO_DATA(x) (x & 0x)
-#define MDIO_DATA_BSY (1 << 31)
struct fsl_enet_mac;
--
2.34.1
Re: [PATCH v2 0/2] imx8mn-smm-s2/pro: Add iMX8MN BSH SMM S2 boards
Gentle ping. Can we get this merged? On 11/23/21 14:42, Ariel D'Alessandro wrote: Changes in v2: * Properly added MAINTAINERS entry. * Fixed binman configuration. * Picked device tree from kernel. * Removed CONFIG_SPL_BUILD anti-pattern in board config. * Removed downstream stuff in bootargs. * Added board documentation. Ariel D'Alessandro (1): bsh: imx8mn-smm-s2/pro: Add iMX8MN BSH SMM S2 boards Michael Trimarchi (1): imx8m: add regs used by GPMI arch/arm/dts/Makefile | 2 + arch/arm/dts/imx8mn-bsh-smm-s2-common.dtsi| 423 .../dts/imx8mn-bsh-smm-s2-u-boot-common.dtsi | 225 + arch/arm/dts/imx8mn-bsh-smm-s2-u-boot.dtsi| 15 + arch/arm/dts/imx8mn-bsh-smm-s2.dts| 48 + arch/arm/dts/imx8mn-bsh-smm-s2pro-u-boot.dtsi | 15 + arch/arm/dts/imx8mn-bsh-smm-s2pro.dts | 80 ++ arch/arm/include/asm/arch-imx8m/imx-regs.h| 7 + arch/arm/mach-imx/imx8m/Kconfig | 15 + board/bsh/imx8mn_smm_s2/Kconfig | 38 + board/bsh/imx8mn_smm_s2/MAINTAINERS | 8 + board/bsh/imx8mn_smm_s2/Makefile | 13 + board/bsh/imx8mn_smm_s2/ddr3l_timing_256m.c | 941 ++ board/bsh/imx8mn_smm_s2/ddr3l_timing_512m.c | 941 ++ board/bsh/imx8mn_smm_s2/imx8mn_smm_s2.c | 23 + board/bsh/imx8mn_smm_s2/imximage-8mn-ddr3.cfg | 10 + board/bsh/imx8mn_smm_s2/spl.c | 93 ++ configs/imx8mn_bsh_smm_s2_defconfig | 92 ++ configs/imx8mn_bsh_smm_s2pro_defconfig| 89 ++ doc/board/bsh/imx8mn_bsh_smm_s2.rst | 62 ++ doc/board/bsh/index.rst | 9 + doc/board/index.rst | 1 + include/configs/imx8mn_bsh_smm_s2.h | 52 + include/configs/imx8mn_bsh_smm_s2_common.h| 62 ++ include/configs/imx8mn_bsh_smm_s2pro.h| 35 + 25 files changed, 3299 insertions(+) create mode 100644 arch/arm/dts/imx8mn-bsh-smm-s2-common.dtsi create mode 100644 arch/arm/dts/imx8mn-bsh-smm-s2-u-boot-common.dtsi create mode 100644 arch/arm/dts/imx8mn-bsh-smm-s2-u-boot.dtsi create mode 100644 arch/arm/dts/imx8mn-bsh-smm-s2.dts create mode 100644 arch/arm/dts/imx8mn-bsh-smm-s2pro-u-boot.dtsi create mode 100644 arch/arm/dts/imx8mn-bsh-smm-s2pro.dts create mode 100644 board/bsh/imx8mn_smm_s2/Kconfig create mode 100644 board/bsh/imx8mn_smm_s2/MAINTAINERS create mode 100644 board/bsh/imx8mn_smm_s2/Makefile create mode 100644 board/bsh/imx8mn_smm_s2/ddr3l_timing_256m.c create mode 100644 board/bsh/imx8mn_smm_s2/ddr3l_timing_512m.c create mode 100644 board/bsh/imx8mn_smm_s2/imx8mn_smm_s2.c create mode 100644 board/bsh/imx8mn_smm_s2/imximage-8mn-ddr3.cfg create mode 100644 board/bsh/imx8mn_smm_s2/spl.c create mode 100644 configs/imx8mn_bsh_smm_s2_defconfig create mode 100644 configs/imx8mn_bsh_smm_s2pro_defconfig create mode 100644 doc/board/bsh/imx8mn_bsh_smm_s2.rst create mode 100644 doc/board/bsh/index.rst create mode 100644 include/configs/imx8mn_bsh_smm_s2.h create mode 100644 include/configs/imx8mn_bsh_smm_s2_common.h create mode 100644 include/configs/imx8mn_bsh_smm_s2pro.h
Re: [PATCH v6 0/1] imx8mn_var_som: Add support for Variscite VAR-SOM-MX8M-NANO board
Gentle ping. Can we get this merged? On 11/23/21 13:33, Ariel D'Alessandro wrote: Changes in v6: * Fixed typo in documentation. * Removed downstream config option IMX8M_BOARD_INIT_DRAM. Changes in v5: * Fixed documentation. Changes in v4: * Added board documentation. * Cleaned up board config. Changes in v3: * Picked device tree from kernel. * Properly added MAINTAINERS entry. * Removed CONFIG_SPL_BUILD anti-pattern in board config. Changes in v2: * Reordered dt properties alphabetically. * Removed downstream stuff in bootargs. * Fixed binman configuration. * Several code styling fixes. Ariel D'Alessandro (1): imx8mn_var_som: Add support for Variscite VAR-SOM-MX8M-NANO board arch/arm/dts/Makefile | 1 + .../dts/imx8mn-var-som-symphony-u-boot.dtsi | 256 arch/arm/dts/imx8mn-var-som-symphony.dts | 240 arch/arm/dts/imx8mn-var-som.dtsi | 547 ++ arch/arm/mach-imx/imx8m/Kconfig | 8 + board/variscite/imx8mn_var_som/Kconfig| 17 + board/variscite/imx8mn_var_som/MAINTAINERS| 7 + board/variscite/imx8mn_var_som/Makefile | 12 + board/variscite/imx8mn_var_som/ddr4_timing.c | 528 + .../variscite/imx8mn_var_som/imx8mn_var_som.c | 30 + .../imx8mn_var_som/imximage-8mn-ddr4.cfg | 10 + board/variscite/imx8mn_var_som/spl.c | 93 +++ configs/imx8mn_var_som_defconfig | 98 doc/board/index.rst | 1 + doc/board/variscite/imx8mn_var_som.rst| 56 ++ doc/board/variscite/index.rst | 9 + include/configs/imx8mn_var_som.h | 90 +++ 17 files changed, 2003 insertions(+) create mode 100644 arch/arm/dts/imx8mn-var-som-symphony-u-boot.dtsi create mode 100644 arch/arm/dts/imx8mn-var-som-symphony.dts create mode 100644 arch/arm/dts/imx8mn-var-som.dtsi create mode 100644 board/variscite/imx8mn_var_som/Kconfig create mode 100644 board/variscite/imx8mn_var_som/MAINTAINERS create mode 100644 board/variscite/imx8mn_var_som/Makefile create mode 100644 board/variscite/imx8mn_var_som/ddr4_timing.c create mode 100644 board/variscite/imx8mn_var_som/imx8mn_var_som.c create mode 100644 board/variscite/imx8mn_var_som/imximage-8mn-ddr4.cfg create mode 100644 board/variscite/imx8mn_var_som/spl.c create mode 100644 configs/imx8mn_var_som_defconfig create mode 100644 doc/board/variscite/imx8mn_var_som.rst create mode 100644 doc/board/variscite/index.rst create mode 100644 include/configs/imx8mn_var_som.h
Re: [RFC PATCH 5/5] Convert CONFIG_AT91_EFLASH to Kconfig
Hi Simon,
On 12/28/21 9:32 AM, Simon Glass wrote:
On Tue, 14 Dec 2021 at 09:57, Patrick Delaunay
wrote:
This converts the following to Kconfig:
CONFIG_AT91_EFLASH
Signed-off-by: Patrick Delaunay
---
arch/arm/mach-at91/Kconfig | 8
configs/ethernut5_defconfig | 2 +-
include/configs/ethernut5.h | 1 -
scripts/config_whitelist.txt | 1 -
4 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
index 4448ca1592..5267a7d15d 100644
--- a/arch/arm/mach-at91/Kconfig
+++ b/arch/arm/mach-at91/Kconfig
@@ -302,6 +302,14 @@ config ATMEL_SFR
config SYS_SOC
default "at91"
+config AT91_EFLASH
+ bool "Support AT91 flash driver"
+ depends on AT91SAM9XE
+ select USE_SYS_MAX_FLASH_BANKS
+ help
+ Enable the driver for the enhanced embedded flash in the Atmel
+ AT91SAM9XE devices.
Reviewed-by: Simon Glass
Please describe what it actually means. Enhanced in what way?
I will dropped the "enhanced" word, copied for header
of arch/arm/mach-at91/arm926ejs/eflash.c
/*
* this driver supports the enhanced embedded flash in the Atmel
* AT91SAM9XE devices with the following geometry:
*
* AT91SAM9XE128: 1 plane of 8 regions of 32 pages (total 256 pages)
* AT91SAM9XE256: 1 plane of 16 regions of 32 pages (total 512 pages)
* AT91SAM9XE512: 1 plane of 32 regions of 32 pages (total 1024 pages)
* (the exact geometry is read from the flash at runtime, so any
* future devices should already be covered)
but not present in commit header
d88bebe16d81 ("AT91SAM9XE: add embedded flash support")
It is more clear
Regards,
Simon
Thanks
Patrick
Re: [PATCH] arm: dts: rk3399-puma: re-add vdd_log for uboot
Hi Quentin,
Am Montag, 3. Januar 2022, 13:26:09 CET schrieb Quentin Schulz:
> Hi Heiko,
>
> On 12/26/21 13:45, Heiko Stuebner wrote:
> > The rk3399-puma board needs a 950mV vdd_log to work stable.
> > This was already added in
> > commit 77012e79ffc3 ("rockchip: rk3399-puma: Set VDD_LOG to 950 mV")
> > but lost again with
> > commit 167efc2c7a46 ("arm64: dts: rk3399: Sync v5.7-rc1 from Linux")
> >
> > So to make puma stable again re-add the vdd_log pwm regulator.
> > As it is not part of the mainline Linux dts right now, add it
> > to the -u-boot dtsi for puma.
> >
> > Fixes: 167efc2c7a46 ("arm64: dts: rk3399: Sync v5.7-rc1 from Linux")
> > Signed-off-by: Heiko Stuebner
> > ---
> > arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi | 11 +++
> > 1 file changed, 11 insertions(+)
> >
> > diff --git a/arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi
> > b/arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi
> > index 29846c4b00..76eb51d2d7 100644
> > --- a/arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi
> > +++ b/arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi
> > @@ -49,6 +49,17 @@
> > regulator-min-microvolt = <180>;
> > regulator-max-microvolt = <180>;
> > };
> > +
> > + vdd_log: vdd-log {
> > + compatible = "pwm-regulator";
> > + pwms = < 0 25000 1>;
> > + regulator-name = "vdd_log";
> > + regulator-min-microvolt = <80>;
> > + regulator-max-microvolt = <140>;
> > + regulator-always-on;
> > + regulator-boot-on;
> > + regulator-init-microvolt = <95>;
> > + };
> > };
> >
> >{
>
> Is this a spurious patch by any chance?
yep, I realized that I was on 2021.01 still. Shortly after that the vdd_log was
re-added
by Christoph.
Heiko
>
> https://source.denx.de/u-boot/u-boot/-/commit/1621afc84f8a109cfdb98c9e370c355289e07870
>
> seems to have more or less the same content, sent (and merged) about a
> year ago by Christoph.
>
> Moreover, it seems to still be there in master:
> https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi#L52-L62
>
> Cheers,
> Quentin
>
[PATCH 2/2] udoo: neo: Do not print the Model information
By default the Model information from DT is printed:
CPU: Freescale i.MX6SX rev1.2 996 MHz (running at 792 MHz)
CPU: Extended Commercial temperature grade (-20C to 105C) at 63C
Reset cause: POR
Model: UDOO Neo Basic
Board: UDOO Neo FULL
I2C: ready
As the udoo basic DT is used, such output may be confusing.
Improve it by only printing the Board model instead, which is
read from the board identification GPIOs.
Signed-off-by: Fabio Estevam
---
This applies on top of Peter's series:
https://lore.kernel.org/all/20211221123249.455347-1-pbrobin...@gmail.com/T
board/udoo/neo/neo.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/board/udoo/neo/neo.c b/board/udoo/neo/neo.c
index 0c0d3f615d18..da6a0b4e9247 100644
--- a/board/udoo/neo/neo.c
+++ b/board/udoo/neo/neo.c
@@ -350,7 +350,8 @@ static char *board_string(int type)
return "UNDEFINED";
}
-int checkboard(void)
+/* Override the default implementation, DT model is not accurate */
+int show_board_info(void)
{
int *board_type = (int *)OCRAM_START;
--
2.25.1
[PATCH 1/2] udoo: neo: Fix the board model printing
Currently, the board model is not printed correctly:
Board: UDOO Neo UNDEFINED
Read the model type in SPL and store it the internal OCRAM, so that
U-Boot proper can retrieve it correctly.
Signed-off-by: Fabio Estevam
---
This applies on top of Peter's series:
https://lore.kernel.org/all/20211221123249.455347-1-pbrobin...@gmail.com/T/
board/udoo/neo/neo.c | 91
1 file changed, 50 insertions(+), 41 deletions(-)
diff --git a/board/udoo/neo/neo.c b/board/udoo/neo/neo.c
index 62f81fff6817..0c0d3f615d18 100644
--- a/board/udoo/neo/neo.c
+++ b/board/udoo/neo/neo.c
@@ -75,6 +75,8 @@ enum {
#define BOARD_DETECT_PAD_CFG (MUX_PAD_CTRL(BOARD_DETECT_PAD_CTRL) |\
MUX_MODE_SION)
+#define OCRAM_START0x8f8000
+
int dram_init(void)
{
gd->ram_size = imx_ddr_size();
@@ -235,13 +237,6 @@ static iomux_v3_cfg_t const phy_control_pads[] = {
MUX_PAD_CTRL(ENET_CLK_PAD_CTRL),
};
-static iomux_v3_cfg_t const board_recognition_pads[] = {
- /*Connected to R184*/
- MX6_PAD_NAND_READY_B__GPIO4_IO_13 | BOARD_DETECT_PAD_CFG,
- /*Connected to R185*/
- MX6_PAD_NAND_ALE__GPIO4_IO_0 | BOARD_DETECT_PAD_CFG,
-};
-
static iomux_v3_cfg_t const wdog_b_pad = {
MX6_PAD_GPIO1_IO13__GPIO1_IO_13 | MUX_PAD_CTRL(WDOG_PAD_CTRL),
};
@@ -308,34 +303,6 @@ int board_init(void)
return 0;
}
-static int get_board_value(void)
-{
- int r184, r185;
-
- imx_iomux_v3_setup_multiple_pads(board_recognition_pads,
-ARRAY_SIZE(board_recognition_pads));
-
- gpio_request(IMX_GPIO_NR(4, 13), "r184");
- gpio_request(IMX_GPIO_NR(4, 0), "r185");
- gpio_direction_input(IMX_GPIO_NR(4, 13));
- gpio_direction_input(IMX_GPIO_NR(4, 0));
-
- r184 = gpio_get_value(IMX_GPIO_NR(4, 13));
- r185 = gpio_get_value(IMX_GPIO_NR(4, 0));
-
- /*
-* Machine selection -
-* Machine r184,r185
-* -
-* Basic 00
-* Basic Ks 01
-* Full 10
-* Extended 11
-*/
-
- return (r184 << 1) + r185;
-}
-
int board_early_init_f(void)
{
setup_iomux_uart();
@@ -368,9 +335,9 @@ int board_mmc_init(struct bd_info *bis)
return fsl_esdhc_initialize(bis, _cfg[0]);
}
-static char *board_string(void)
+static char *board_string(int type)
{
- switch (get_board_value()) {
+ switch (type) {
case UDOO_NEO_TYPE_BASIC:
return "BASIC";
case UDOO_NEO_TYPE_BASIC_KS:
@@ -385,14 +352,18 @@ static char *board_string(void)
int checkboard(void)
{
- printf("Board: UDOO Neo %s\n", board_string());
+ int *board_type = (int *)OCRAM_START;
+
+ printf("Board: UDOO Neo %s\n", board_string(*board_type));
return 0;
}
int board_late_init(void)
{
+ int *board_type = (int *)OCRAM_START;
+
#ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
- env_set("board_name", board_string());
+ env_set("board_name", board_string(*board_type));
#endif
return 0;
@@ -403,6 +374,41 @@ int board_late_init(void)
#include
#include
+static const iomux_v3_cfg_t board_recognition_pads[] = {
+ /*Connected to R184*/
+ MX6_PAD_NAND_READY_B__GPIO4_IO_13 | BOARD_DETECT_PAD_CFG,
+ /*Connected to R185*/
+ MX6_PAD_NAND_ALE__GPIO4_IO_0 | BOARD_DETECT_PAD_CFG,
+};
+
+static int get_board_value(void)
+{
+ int r184, r185;
+
+ imx_iomux_v3_setup_multiple_pads(board_recognition_pads,
+ARRAY_SIZE(board_recognition_pads));
+
+ gpio_request(IMX_GPIO_NR(4, 13), "r184");
+ gpio_request(IMX_GPIO_NR(4, 0), "r185");
+ gpio_direction_input(IMX_GPIO_NR(4, 13));
+ gpio_direction_input(IMX_GPIO_NR(4, 0));
+
+ r184 = gpio_get_value(IMX_GPIO_NR(4, 13));
+ r185 = gpio_get_value(IMX_GPIO_NR(4, 0));
+
+ /*
+* Machine selection -
+* Machine r184,r185
+* -
+* Basic 00
+* Basic Ks 01
+* Full 10
+* Extended 11
+*/
+
+ return (r184 << 1) + r185;
+}
+
static const struct mx6sx_iomux_ddr_regs mx6_ddr_ioregs = {
.dram_dqm0 = 0x0028,
.dram_dqm1 = 0x0028,
@@ -498,7 +504,7 @@ static void ccgr_init(void)
static void spl_dram_init(void)
{
- int board = get_board_value();
+ int *board_type = (int *)OCRAM_START;
struct mx6_ddr_sysinfo sysinfo = {
.dsize = 1, /* width of data bus: 1 = 32 bits */
@@ -515,8 +521,11 @@ static void spl_dram_init(void)
.rst_to_cke = 0x23, /* 33 cycles, 500us (JEDEC default) */
};
+ *board_type = get_board_value();
+
Re: [PATCH v3 15/16] arm: dts: ls1028a-rdb: sync device tree with Linux
Am 2022-01-03 13:47, schrieb Vladimir Oltean:
Allow device trees to be reused between Linux and U-Boot.
The source for these device trees is linux-next as of commit
bd8a9cd624c6 ("arm64: dts: ls1028a-rdb: update copyright"), which was
chosen because some changes needed to be done to the Linux DTs too,
before they could be shared:
https://lore.kernel.org/linux-arm-kernel/20211202141528.2450169-5-vladimir.olt...@nxp.com/T/#m6f63c92e75fa79a01144b2c2c6dc4776e7971395
There are two more commits on the RDB device tree which haven't been
picked up yet, because they have dependencies on the SoC device tree:
dd3d936a1b17 ("arm64: dts: ls1028a: add ftm_alarm1 node to be used as
wakeup source")
b2e2d3e02fb6 ("arm64: dts: ls1028a-rdb: enable pwm0")
These will be picked up on the next resync.
Signed-off-by: Vladimir Oltean
Reviewed-by: Priyanka Jain
Reviewed-by: Michael Walle
Re: [PATCH v3 14/16] arm: dts: ls1028a-rdb: enable PCIe controllers from U-Boot dtsi
Am 2022-01-03 13:47, schrieb Vladimir Oltean:
Reuse the scheme implemented by the Kontron SL28 boards in commit
d08011d7f9b4 ("arm: dts: ls1028a: disable the PCIe controller by
default") and move the 'status = "okay"' lines for the PCIe controllers
inside a separate U-Boot dtsi for the LS1028A-RDB board. This way, the
existing Linux device tree can simply be dropped in.
Signed-off-by: Vladimir Oltean
Reviewed-by: Michael Walle
Re: [PATCH v3 09/16] rtc: pcf2127: remove U-Boot specific compatible string
Am 2022-01-03 13:47, schrieb Vladimir Oltean: Now that all in-tree boards have been converted to the compatible strings from Linux, delete the support for the ad-hoc "pcf2127-rtc" one. Cc: Simon Glass Signed-off-by: Vladimir Oltean Reviewed-by: Simon Glass Reviewed-by: Michael Walle
Re: [PATCH v3 08/16] arm: dts: lx2160a-rdb: use Linux compatible string for RTC
Am 2022-01-03 13:47, schrieb Vladimir Oltean: During the LS1028A-RDB sync with Linux device trees, it was observed that the same RTC is present on the two boards, and the wrong compatible string is used in both places. This change updates the RTC from the LX2160A-RDB to use the compatible string that was established in Linux. Signed-off-by: Vladimir Oltean Reviewed-by: Priyanka Jain Reviewed-by: Michael Walle
Re: [PATCH v3 07/16] arm: dts: ls1028a-rdb: use Linux compatible string for RTC
Am 2022-01-03 13:47, schrieb Vladimir Oltean: During this board's sync with Linux device trees, it was observed that it doesn't use the same compatible string for the RTC node as in U-Boot. This change makes the RTC compatible strings match, for a smoother sync. Signed-off-by: Vladimir Oltean Reviewed-by: Michael Walle
Re: [PATCH v3 06/16] arm: dts: ls1028a-qds: use Linux compatible string for RTC
Am 2022-01-03 13:47, schrieb Vladimir Oltean: The LS1028A-QDS board won't be synced with the Linux device trees right now, since those are currently still in progress (Ethernet is missing). However, while we're at converting the RDB, it can be observed that the same RTC is present on the two boards, and the wrong compatible string is used in both places. This change updates the RTC from the QDS to use the compatible string that was established in Linux. Signed-off-by: Vladimir Oltean Reviewed-by: Priyanka Jain Reviewed-by: Michael Walle
Re: [PATCH v3 05/16] arm: dts: lx2160a-qds: use Linux compatible string for RTC
Am 2022-01-03 13:47, schrieb Vladimir Oltean: During the LS1028A-RDB sync with Linux device trees, it was observed that the same RTC is present on the two boards, and the wrong compatible string is used in both places. This change updates the RTC from the LX2160A-QDS to use the compatible string that was established in Linux. Signed-off-by: Vladimir Oltean Reviewed-by: Priyanka Jain Reviewed-by: Michael Walle
Re: [PATCH v3 04/16] arm: dts: ls1088a-rdb: use Linux compatible string for RTC
Am 2022-01-03 13:47, schrieb Vladimir Oltean: During the LS1028A-RDB sync with Linux device trees, it was observed that the same RTC is present on the two boards, and the wrong compatible string is used in both places. This change updates the RTC from the LS1088A-RDB to use the compatible string that was established in Linux. Signed-off-by: Vladimir Oltean Reviewed-by: Priyanka Jain Reviewed-by: Michael Walle
Re: [PATCH v3 03/16] arm: dts: ls1088a-qds: use Linux compatible string for RTC
Am 2022-01-03 13:47, schrieb Vladimir Oltean: During the LS1028A-RDB sync with Linux device trees, it was observed that the same RTC is present on the two boards, and the wrong compatible string is used in both places. This change updates the RTC from the LS1088A-QDS to use the compatible string that was established in Linux. Signed-off-by: Vladimir Oltean Reviewed-by: Priyanka Jain Reviewed-by: Michael Walle
Re: [PATCH v3 02/16] rtc: pcf2127: sync with Linux compatible strings
Am 2022-01-03 13:47, schrieb Vladimir Oltean: Allow this driver to be used by boards which inherit their device trees from Linux. Compatibility is temporarily retained with the old compatible string which is U-Boot specific, and will be removed after a few changes. Cc: Simon Glass Signed-off-by: Vladimir Oltean Reviewed-by: Simon Glass Reviewed-by: Michael Walle
Re: [PATCH v3 01/16] i2c: muxes: pca954x: add PCA9847 variant
Am 2022-01-03 13:47, schrieb Vladimir Oltean: This seems to be very similar to the already existing PCA9547, save for the fact that it supports 0.8V and doesn't support 5V. In fact, it is so similar to the PCA9547 that the NXP LS1028A-RDB board has been driving this chip using a "nxp,pca9547" compatible string. Create a new compatible for the PCA9847 (which is the same as in Linux) and define the same operating parameters for it as for PCA9547. Cc: Heiko Schocher Signed-off-by: Vladimir Oltean Reviewed-by: Heiko Schocher Reviewed-by: Priyanka Jain Reviewed-by: Michael Walle
Re: [PATCH v2 1/1] fastboot: fb_getvar: Add getvar_logical_blocksize for NXP mfgtool
Hi Sean, On 2021-12-30 08:21, Sean Anderson wrote: On 12/29/21 8:35 AM, Angus Ainslie wrote: Hi Sean, On 2021-12-28 08:59, Sean Anderson wrote: Hi Angus, NXP's mfgtool queies the mmc blocksize and splits a sparse image into blocksize size pieces for the upload. It's still not clear to me why this is necessary. fastboot (for example) transfers in blocks of max-download-size. Using the actual block size seems like it would result in unnecessary overhead. The version of uuu that we are using requires the block-size for the sparse upload https://source.puri.sm/Librem5/mfgtools/-/blob/pureos/amber/libuuu/fastboot.cpp#L501 It looks like the upstream version will default to 4096 if the block-size is not provided https://github.com/NXPmicro/mfgtools/blob/5397913ad97db422c1d70f314dedff4cb7d976b9/libuuu/fastboot.cpp#L642 Instead of making assumptions about the block size wouldn't it be better to provide one if requested ? The block size is for the sparse image. This determines the granularity of the sections of the image. For example, if the block size is 1K, then all sizes will be multiples of 1K. So if you have a block with 1 byte of data and 1023 bytes of 0 then the whole block will be transferred instead of being replaced with a fill block. Thanks for the explanation on how it works. However, the sparse file block size size completely orthogonal to the block size of the device being written to. The only thing it affects is the efficiency of the sparse image. For example, I generate my sparse files with a block size of 1M, because it is a nice convenient number. Ok so the way the NXP's uuu uses the blocksize is not correct. However the tool is already out there in the wild. Can we add the block-size response to support that tool or will it be required that uuu needs to be upgraded to work with mainline u-boot ? Thanks Angus --Sean
[PATCH v3 16/16] arm: dts: ls1028a-qds: declare in-band autoneg for Ethernet ports
The commit in the Fixes: tag below broke traffic through switch ports
where the SERDES protocol requires in-band autoneg and this requirement
isn't described in the device tree: SGMII, QSGMII, USXGMII (with
2500Base-X, in-band autoneg isn't supported).
The LS1028A-QDS boards are not yet ready for syncing their device trees
with Linux, since Ethernet is missing there (but has been submitted):
https://lore.kernel.org/lkml/2022223457.10599-11-leoyang...@nxp.com/
When agreement is reached for the Ethernet support in Linux, there will
be a sync for these boards as well. For now, just enable in-band autoneg
to fix the breakage.
Fixes: e3789a726269 ("net: dsa: felix: configure the in-band autoneg property
based on OF node info")
Cc: Ramon Fried
Signed-off-by: Vladimir Oltean
Reviewed-by: Priyanka Jain
---
v1->v3: none
arch/arm/dts/fsl-ls1028a-qds-1xxx-sch-30842.dtsi | 1 +
arch/arm/dts/fsl-ls1028a-qds-8xxx-sch-24801.dtsi | 1 +
arch/arm/dts/fsl-ls1028a-qds--sch-24801-LBRW.dtsi | 4
arch/arm/dts/fsl-ls1028a-qds--sch-24801.dtsi | 4
arch/arm/dts/fsl-ls1028a-qds-x3xx-sch-30841-LBRW.dtsi | 4
arch/arm/dts/fsl-ls1028a-qds-x5xx-sch-28021-LBRW.dtsi | 4
6 files changed, 18 insertions(+)
diff --git a/arch/arm/dts/fsl-ls1028a-qds-1xxx-sch-30842.dtsi
b/arch/arm/dts/fsl-ls1028a-qds-1xxx-sch-30842.dtsi
index f4c557e69e6e..f208a02721e3 100644
--- a/arch/arm/dts/fsl-ls1028a-qds-1xxx-sch-30842.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-qds-1xxx-sch-30842.dtsi
@@ -15,6 +15,7 @@
_port0 {
status = "okay";
+ managed = "in-band-status";
phy-mode = "usxgmii";
phy-handle = <&{/soc/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@02}>;
};
diff --git a/arch/arm/dts/fsl-ls1028a-qds-8xxx-sch-24801.dtsi
b/arch/arm/dts/fsl-ls1028a-qds-8xxx-sch-24801.dtsi
index 7d197c31814a..0a0926473541 100644
--- a/arch/arm/dts/fsl-ls1028a-qds-8xxx-sch-24801.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-qds-8xxx-sch-24801.dtsi
@@ -14,6 +14,7 @@
_port0 {
status = "okay";
+ managed = "in-band-status";
phy-mode = "sgmii";
phy-handle = <&{/soc/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@1c}>;
};
diff --git a/arch/arm/dts/fsl-ls1028a-qds--sch-24801-LBRW.dtsi
b/arch/arm/dts/fsl-ls1028a-qds--sch-24801-LBRW.dtsi
index 992092ec7838..94b5e765aedb 100644
--- a/arch/arm/dts/fsl-ls1028a-qds--sch-24801-LBRW.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-qds--sch-24801-LBRW.dtsi
@@ -44,24 +44,28 @@
_felix_port0 {
status = "okay";
+ managed = "in-band-status";
phy-mode = "sgmii";
phy-handle = <&{/soc/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@1c}>;
};
_felix_port1 {
status = "okay";
+ managed = "in-band-status";
phy-mode = "sgmii";
phy-handle = <&{/soc/i2c@200/fpga@66/mux-mdio@54/mdio@50/phy@1c}>;
};
_felix_port2 {
status = "okay";
+ managed = "in-band-status";
phy-mode = "sgmii";
phy-handle = <&{/soc/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@1e}>;
};
_felix_port3 {
status = "okay";
+ managed = "in-band-status";
phy-mode = "sgmii";
phy-handle = <&{/soc/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@1f}>;
};
diff --git a/arch/arm/dts/fsl-ls1028a-qds--sch-24801.dtsi
b/arch/arm/dts/fsl-ls1028a-qds--sch-24801.dtsi
index a905d77a9a71..bd46adfd2928 100644
--- a/arch/arm/dts/fsl-ls1028a-qds--sch-24801.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-qds--sch-24801.dtsi
@@ -29,24 +29,28 @@
_felix_port0 {
status = "okay";
+ managed = "in-band-status";
phy-mode = "sgmii";
phy-handle = <&{/soc/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@1c}>;
};
_felix_port1 {
status = "okay";
+ managed = "in-band-status";
phy-mode = "sgmii";
phy-handle = <&{/soc/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@1d}>;
};
_felix_port2 {
status = "okay";
+ managed = "in-band-status";
phy-mode = "sgmii";
phy-handle = <&{/soc/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@1e}>;
};
_felix_port3 {
status = "okay";
+ managed = "in-band-status";
phy-mode = "sgmii";
phy-handle = <&{/soc/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@1f}>;
};
diff --git a/arch/arm/dts/fsl-ls1028a-qds-x3xx-sch-30841-LBRW.dtsi
b/arch/arm/dts/fsl-ls1028a-qds-x3xx-sch-30841-LBRW.dtsi
index 62e818f099ca..5909e7635a1a 100644
--- a/arch/arm/dts/fsl-ls1028a-qds-x3xx-sch-30841-LBRW.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-qds-x3xx-sch-30841-LBRW.dtsi
@@ -29,24 +29,28 @@
_felix_port0 {
status = "okay";
+ managed = "in-band-status";
phy-mode = "usxgmii";
phy-handle = <&{/soc/i2c@200/fpga@66/mux-mdio@54/mdio@50/phy@00}>;
};
_felix_port1 {
status = "okay";
+ managed = "in-band-status";
phy-mode = "usxgmii";
phy-handle = <&{/soc/i2c@200/fpga@66/mux-mdio@54/mdio@50/phy@01}>;
};
_felix_port2 {
[PATCH v3 15/16] arm: dts: ls1028a-rdb: sync device tree with Linux
Allow device trees to be reused between Linux and U-Boot.
The source for these device trees is linux-next as of commit
bd8a9cd624c6 ("arm64: dts: ls1028a-rdb: update copyright"), which was
chosen because some changes needed to be done to the Linux DTs too,
before they could be shared:
https://lore.kernel.org/linux-arm-kernel/20211202141528.2450169-5-vladimir.olt...@nxp.com/T/#m6f63c92e75fa79a01144b2c2c6dc4776e7971395
There are two more commits on the RDB device tree which haven't been
picked up yet, because they have dependencies on the SoC device tree:
dd3d936a1b17 ("arm64: dts: ls1028a: add ftm_alarm1 node to be used as wakeup
source")
b2e2d3e02fb6 ("arm64: dts: ls1028a-rdb: enable pwm0")
These will be picked up on the next resync.
Signed-off-by: Vladimir Oltean
Reviewed-by: Priyanka Jain
---
v1->v2: RTC compatible string change broken out into separate patch
v2->v3: update commit message to point out that the Linux dependency
patches were merged
arch/arm/dts/fsl-ls1028a-rdb.dts | 158 ---
1 file changed, 146 insertions(+), 12 deletions(-)
diff --git a/arch/arm/dts/fsl-ls1028a-rdb.dts b/arch/arm/dts/fsl-ls1028a-rdb.dts
index 5a35258fa97f..639f40740d56 100644
--- a/arch/arm/dts/fsl-ls1028a-rdb.dts
+++ b/arch/arm/dts/fsl-ls1028a-rdb.dts
@@ -1,19 +1,27 @@
-// SPDX-License-Identifier: GPL-2.0+ OR X11
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
/*
- * NXP ls1028ARDB device tree source
+ * Device Tree file for NXP LS1028A RDB Board.
*
- * Copyright 2019 NXP
+ * Copyright 2018-2021 NXP
+ *
+ * Harninder Rai
*
*/
/dts-v1/;
-
#include "fsl-ls1028a.dtsi"
/ {
- model = "NXP Layerscape 1028a RDB Board";
+ model = "LS1028A RDB Board";
compatible = "fsl,ls1028a-rdb", "fsl,ls1028a";
+
aliases {
+ crypto =
+ serial0 =
+ serial1 =
+ mmc0 =
+ mmc1 =
+ rtc1 = _alarm0;
spi0 =
ethernet0 = _port0;
ethernet1 = _port2;
@@ -22,6 +30,83 @@
ethernet4 = _felix_port2;
ethernet5 = _felix_port3;
};
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory@8000 {
+ device_type = "memory";
+ reg = <0x0 0x8000 0x1 0x000>;
+ };
+
+ sys_mclk: clock-mclk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <2500>;
+ };
+
+ reg_1p8v: regulator-1p8v {
+ compatible = "regulator-fixed";
+ regulator-name = "1P8V";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-always-on;
+ };
+
+ sb_3v3: regulator-sb3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "3v3_vbus";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ sound {
+ compatible = "simple-audio-card";
+ simple-audio-card,format = "i2s";
+ simple-audio-card,widgets =
+ "Microphone", "Microphone Jack",
+ "Headphone", "Headphone Jack",
+ "Speaker", "Speaker Ext",
+ "Line", "Line In Jack";
+ simple-audio-card,routing =
+ "MIC_IN", "Microphone Jack",
+ "Microphone Jack", "Mic Bias",
+ "LINE_IN", "Line In Jack",
+ "Headphone Jack", "HP_OUT",
+ "Speaker Ext", "LINE_OUT";
+
+ simple-audio-card,cpu {
+ sound-dai = <>;
+ frame-master;
+ bitclock-master;
+ };
+
+ simple-audio-card,codec {
+ sound-dai = <>;
+ frame-master;
+ bitclock-master;
+ system-clock-frequency = <2500>;
+ };
+ };
+};
+
+ {
+ status = "okay";
+
+ can-transceiver {
+ max-bitrate = <500>;
+ };
+};
+
+ {
+ status = "okay";
+
+ can-transceiver {
+ max-bitrate = <500>;
+ };
};
{
@@ -67,43 +152,83 @@
};
{
+ sd-uhs-sdr104;
+ sd-uhs-sdr50;
+ sd-uhs-sdr25;
+ sd-uhs-sdr12;
status = "okay";
};
{
- status = "okay";
mmc-hs200-1_8v;
+ mmc-hs400-1_8v;
+ bus-width = <8>;
+ status = "okay";
};
{
status = "okay";
mt35xu02g0: flash@0 {
+ compatible = "jedec,spi-nor";
#address-cells = <1>;
#size-cells = <1>;
- compatible =
[PATCH v3 13/16] arm: dts: ls1028a-rdb: disable I2C buses 1 through 7
There is no I2C peripheral on these buses on the reference design board,
and the Linux device tree does not enable them either.
Signed-off-by: Vladimir Oltean
Reviewed-by: Priyanka Jain
---
v1->v3: none
arch/arm/dts/fsl-ls1028a-rdb.dts | 28
1 file changed, 28 deletions(-)
diff --git a/arch/arm/dts/fsl-ls1028a-rdb.dts b/arch/arm/dts/fsl-ls1028a-rdb.dts
index c5b95e169f5c..10070eab6e61 100644
--- a/arch/arm/dts/fsl-ls1028a-rdb.dts
+++ b/arch/arm/dts/fsl-ls1028a-rdb.dts
@@ -112,34 +112,6 @@
};
};
- {
- status = "okay";
-};
-
- {
- status = "okay";
-};
-
- {
- status = "okay";
-};
-
- {
- status = "okay";
-};
-
- {
- status = "okay";
-};
-
- {
- status = "okay";
-};
-
- {
- status = "okay";
-};
-
_felix {
status = "okay";
};
--
2.25.1
[PATCH v3 12/16] arm: dts: ls1028a-rdb: disable DSPI nodes
There is no SPI peripheral on the LS1028A-RDB, therefore no reason to
enable these nodes in the U-Boot device tree (and Linux does not enable
them either).
Signed-off-by: Vladimir Oltean
Reviewed-by: Priyanka Jain
---
v1->v3: none
arch/arm/dts/fsl-ls1028a-rdb.dts | 12
1 file changed, 12 deletions(-)
diff --git a/arch/arm/dts/fsl-ls1028a-rdb.dts b/arch/arm/dts/fsl-ls1028a-rdb.dts
index b5e56b1c1f15..c5b95e169f5c 100644
--- a/arch/arm/dts/fsl-ls1028a-rdb.dts
+++ b/arch/arm/dts/fsl-ls1028a-rdb.dts
@@ -24,18 +24,6 @@
};
};
- {
- status = "okay";
-};
-
- {
- status = "okay";
-};
-
- {
- status = "okay";
-};
-
{
status = "okay";
};
--
2.25.1
[PATCH v3 14/16] arm: dts: ls1028a-rdb: enable PCIe controllers from U-Boot dtsi
Reuse the scheme implemented by the Kontron SL28 boards in commit
d08011d7f9b4 ("arm: dts: ls1028a: disable the PCIe controller by
default") and move the 'status = "okay"' lines for the PCIe controllers
inside a separate U-Boot dtsi for the LS1028A-RDB board. This way, the
existing Linux device tree can simply be dropped in.
Signed-off-by: Vladimir Oltean
---
v2->v3: stop including the -u-boot.dtsi by hand, it gets included
automatically
arch/arm/dts/fsl-ls1028a-rdb-u-boot.dtsi | 15 +++
arch/arm/dts/fsl-ls1028a-rdb.dts | 8
2 files changed, 15 insertions(+), 8 deletions(-)
create mode 100644 arch/arm/dts/fsl-ls1028a-rdb-u-boot.dtsi
diff --git a/arch/arm/dts/fsl-ls1028a-rdb-u-boot.dtsi
b/arch/arm/dts/fsl-ls1028a-rdb-u-boot.dtsi
new file mode 100644
index ..a72b57305dc3
--- /dev/null
+++ b/arch/arm/dts/fsl-ls1028a-rdb-u-boot.dtsi
@@ -0,0 +1,15 @@
+// SPDX-License-Identifier: GPL-2.0+
+/* Copyright 2021 NXP */
+
+/*
+ * u-boot will enable the device in the linux device tree in place. Because
+ * we are using the linux device tree, we have to enable the PCI controller
+ * ourselves.
+ */
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
diff --git a/arch/arm/dts/fsl-ls1028a-rdb.dts b/arch/arm/dts/fsl-ls1028a-rdb.dts
index 10070eab6e61..5a35258fa97f 100644
--- a/arch/arm/dts/fsl-ls1028a-rdb.dts
+++ b/arch/arm/dts/fsl-ls1028a-rdb.dts
@@ -153,14 +153,6 @@
status = "okay";
};
- {
- status = "okay";
-};
-
- {
- status = "okay";
-};
-
{
status = "okay";
};
--
2.25.1
[PATCH v3 10/16] arm: dts: ls1028a-rdb: sort nodes alphabetically
The nodes in the NXP LS1028A-RDB device tree are out of order, regroup
them alphabetically to have a simple delta when the Linux device tree is
brought in.
Signed-off-by: Vladimir Oltean
Reviewed-by: Priyanka Jain
---
v1->v3: none
arch/arm/dts/fsl-ls1028a-rdb.dts | 110 +++
1 file changed, 55 insertions(+), 55 deletions(-)
diff --git a/arch/arm/dts/fsl-ls1028a-rdb.dts b/arch/arm/dts/fsl-ls1028a-rdb.dts
index ddb01db73f8e..11bf7e5f627d 100644
--- a/arch/arm/dts/fsl-ls1028a-rdb.dts
+++ b/arch/arm/dts/fsl-ls1028a-rdb.dts
@@ -36,6 +36,48 @@
status = "okay";
};
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+_mdio_pf3 {
+ status = "okay";
+ rdb_phy0: phy@2 {
+ reg = <2>;
+ };
+
+ /* VSC8514 QSGMII PHY */
+ sw_phy0: phy@10 {
+ reg = <0x10>;
+ };
+
+ sw_phy1: phy@11 {
+ reg = <0x11>;
+ };
+
+ sw_phy2: phy@12 {
+ reg = <0x12>;
+ };
+
+ sw_phy3: phy@13 {
+ reg = <0x13>;
+ };
+};
+
+_port0 {
+ status = "okay";
+ phy-mode = "sgmii";
+ phy-handle = <_phy0>;
+};
+
+_port2 {
+ status = "okay";
+};
+
{
status = "okay";
};
@@ -110,44 +152,6 @@
status = "okay";
};
- {
- status = "okay";
-};
-
- {
- status = "okay";
-};
-
- {
- status = "okay";
-};
-
- {
- status = "okay";
-};
-
- {
- status = "okay";
-};
-
- {
- status = "okay";
-};
-
- {
- status = "okay";
-};
-
-_port0 {
- status = "okay";
- phy-mode = "sgmii";
- phy-handle = <_phy0>;
-};
-
-_port2 {
- status = "okay";
-};
-
_felix {
status = "okay";
};
@@ -185,26 +189,22 @@
status = "okay";
};
-_mdio_pf3 {
+ {
status = "okay";
- rdb_phy0: phy@2 {
- reg = <2>;
- };
+};
- /* VSC8514 QSGMII PHY */
- sw_phy0: phy@10 {
- reg = <0x10>;
- };
+ {
+ status = "okay";
+};
- sw_phy1: phy@11 {
- reg = <0x11>;
- };
+ {
+ status = "okay";
+};
- sw_phy2: phy@12 {
- reg = <0x12>;
- };
+ {
+ status = "okay";
+};
- sw_phy3: phy@13 {
- reg = <0x13>;
- };
+ {
+ status = "okay";
};
--
2.25.1
[PATCH v3 11/16] arm: dts: ls1028a-rdb: sync Ethernet device tree nodes with Linux
In a bit of a blunder, the blamed commit in the Fixes: tag below made
the mscc_felix switch driver look at the 'managed = "in-band-status"'
device tree property, forgetting that the U-Boot device tree had not
been updated to include that property, whereas the Linux one does.
The switch is therefore described in the device tree as not requiring
in-band autoneg, but the PHY driver for VSC8514 (drivers/net/phy/mscc.c)
still enables that feature. This results in a mismatch => no traffic.
This patch is a copy-paste of the Ethernet device tree nodes from Linux,
which resolves that issue. The device tree update also renames the
Ethernet PHY labels.
Fixes: e3789a726269 ("net: dsa: felix: configure the in-band autoneg property
based on OF node info")
Cc: Ramon Fried
Signed-off-by: Vladimir Oltean
Reviewed-by: Priyanka Jain
---
v1->v3: none
arch/arm/dts/fsl-ls1028a-rdb.dts | 32 ++--
1 file changed, 18 insertions(+), 14 deletions(-)
diff --git a/arch/arm/dts/fsl-ls1028a-rdb.dts b/arch/arm/dts/fsl-ls1028a-rdb.dts
index 11bf7e5f627d..b5e56b1c1f15 100644
--- a/arch/arm/dts/fsl-ls1028a-rdb.dts
+++ b/arch/arm/dts/fsl-ls1028a-rdb.dts
@@ -45,33 +45,33 @@
};
_mdio_pf3 {
- status = "okay";
- rdb_phy0: phy@2 {
- reg = <2>;
+ sgmii_phy0: ethernet-phy@2 {
+ reg = <0x2>;
};
- /* VSC8514 QSGMII PHY */
- sw_phy0: phy@10 {
+ /* VSC8514 QSGMII quad PHY */
+ qsgmii_phy0: ethernet-phy@10 {
reg = <0x10>;
};
- sw_phy1: phy@11 {
+ qsgmii_phy1: ethernet-phy@11 {
reg = <0x11>;
};
- sw_phy2: phy@12 {
+ qsgmii_phy2: ethernet-phy@12 {
reg = <0x12>;
};
- sw_phy3: phy@13 {
+ qsgmii_phy3: ethernet-phy@13 {
reg = <0x13>;
};
};
_port0 {
- status = "okay";
+ phy-handle = <_phy0>;
phy-mode = "sgmii";
- phy-handle = <_phy0>;
+ managed = "in-band-status";
+ status = "okay";
};
_port2 {
@@ -158,28 +158,32 @@
_felix_port0 {
label = "swp0";
- phy-handle = <_phy0>;
+ managed = "in-band-status";
+ phy-handle = <_phy0>;
phy-mode = "qsgmii";
status = "okay";
};
_felix_port1 {
label = "swp1";
- phy-handle = <_phy1>;
+ managed = "in-band-status";
+ phy-handle = <_phy1>;
phy-mode = "qsgmii";
status = "okay";
};
_felix_port2 {
label = "swp2";
- phy-handle = <_phy2>;
+ managed = "in-band-status";
+ phy-handle = <_phy2>;
phy-mode = "qsgmii";
status = "okay";
};
_felix_port3 {
label = "swp3";
- phy-handle = <_phy3>;
+ managed = "in-band-status";
+ phy-handle = <_phy3>;
phy-mode = "qsgmii";
status = "okay";
};
--
2.25.1
[PATCH v3 08/16] arm: dts: lx2160a-rdb: use Linux compatible string for RTC
During the LS1028A-RDB sync with Linux device trees, it was observed
that the same RTC is present on the two boards, and the wrong compatible
string is used in both places. This change updates the RTC from the
LX2160A-RDB to use the compatible string that was established in Linux.
Signed-off-by: Vladimir Oltean
Reviewed-by: Priyanka Jain
---
v1->v3: none
arch/arm/dts/fsl-lx2160a-rdb.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/dts/fsl-lx2160a-rdb.dts b/arch/arm/dts/fsl-lx2160a-rdb.dts
index 5fbdd907017c..8ca4afa7eaea 100644
--- a/arch/arm/dts/fsl-lx2160a-rdb.dts
+++ b/arch/arm/dts/fsl-lx2160a-rdb.dts
@@ -117,7 +117,7 @@
status = "okay";
rtc@51 {
- compatible = "pcf2127-rtc";
+ compatible = "nxp,pcf2129";
reg = <0x51>;
};
};
--
2.25.1
[PATCH v3 09/16] rtc: pcf2127: remove U-Boot specific compatible string
Now that all in-tree boards have been converted to the compatible
strings from Linux, delete the support for the ad-hoc "pcf2127-rtc" one.
Cc: Simon Glass
Signed-off-by: Vladimir Oltean
Reviewed-by: Simon Glass
---
v1->v3: none
drivers/rtc/pcf2127.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/rtc/pcf2127.c b/drivers/rtc/pcf2127.c
index 291ef0329a3e..2f3fafb4968f 100644
--- a/drivers/rtc/pcf2127.c
+++ b/drivers/rtc/pcf2127.c
@@ -120,7 +120,6 @@ static const struct rtc_ops pcf2127_rtc_ops = {
};
static const struct udevice_id pcf2127_rtc_ids[] = {
- { .compatible = "pcf2127-rtc" },
{ .compatible = "nxp,pcf2127" },
{ .compatible = "nxp,pcf2129" },
{ .compatible = "nxp,pca2129" },
--
2.25.1
[PATCH v3 07/16] arm: dts: ls1028a-rdb: use Linux compatible string for RTC
During this board's sync with Linux device trees, it was observed that
it doesn't use the same compatible string for the RTC node as in U-Boot.
This change makes the RTC compatible strings match, for a smoother sync.
Signed-off-by: Vladimir Oltean
---
v1->v2: patch is new
v2->v3: none
arch/arm/dts/fsl-ls1028a-rdb.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/dts/fsl-ls1028a-rdb.dts b/arch/arm/dts/fsl-ls1028a-rdb.dts
index 537ebbc697cb..ddb01db73f8e 100644
--- a/arch/arm/dts/fsl-ls1028a-rdb.dts
+++ b/arch/arm/dts/fsl-ls1028a-rdb.dts
@@ -75,7 +75,7 @@
reg = <0x3>;
rtc@51 {
- compatible = "pcf2127-rtc";
+ compatible = "nxp,pcf2129";
reg = <0x51>;
};
};
--
2.25.1
[PATCH v3 06/16] arm: dts: ls1028a-qds: use Linux compatible string for RTC
The LS1028A-QDS board won't be synced with the Linux device trees right
now, since those are currently still in progress (Ethernet is missing).
However, while we're at converting the RDB, it can be observed that the
same RTC is present on the two boards, and the wrong compatible string
is used in both places. This change updates the RTC from the QDS to use
the compatible string that was established in Linux.
Signed-off-by: Vladimir Oltean
Reviewed-by: Priyanka Jain
---
v1->v3: none
arch/arm/dts/fsl-ls1028a-qds.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/dts/fsl-ls1028a-qds.dtsi
b/arch/arm/dts/fsl-ls1028a-qds.dtsi
index 0da0a7bc5db8..3b063d0257de 100644
--- a/arch/arm/dts/fsl-ls1028a-qds.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-qds.dtsi
@@ -195,7 +195,7 @@
status = "okay";
rtc@51 {
- compatible = "pcf2127-rtc";
+ compatible = "nxp,pcf2129";
reg = <0x51>;
};
};
--
2.25.1
[PATCH v3 05/16] arm: dts: lx2160a-qds: use Linux compatible string for RTC
During the LS1028A-RDB sync with Linux device trees, it was observed
that the same RTC is present on the two boards, and the wrong compatible
string is used in both places. This change updates the RTC from the
LX2160A-QDS to use the compatible string that was established in Linux.
Signed-off-by: Vladimir Oltean
Reviewed-by: Priyanka Jain
---
v1->v3: none
arch/arm/dts/fsl-lx2160a-qds.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/dts/fsl-lx2160a-qds.dtsi
b/arch/arm/dts/fsl-lx2160a-qds.dtsi
index 288607c0347b..69e11cca2da1 100644
--- a/arch/arm/dts/fsl-lx2160a-qds.dtsi
+++ b/arch/arm/dts/fsl-lx2160a-qds.dtsi
@@ -250,7 +250,7 @@
reg = <0x3>;
rtc@51 {
- compatible = "pcf2127-rtc";
+ compatible = "nxp,pcf2129";
reg = <0x51>;
};
};
--
2.25.1
[PATCH v3 04/16] arm: dts: ls1088a-rdb: use Linux compatible string for RTC
During the LS1028A-RDB sync with Linux device trees, it was observed
that the same RTC is present on the two boards, and the wrong compatible
string is used in both places. This change updates the RTC from the
LS1088A-RDB to use the compatible string that was established in Linux.
Signed-off-by: Vladimir Oltean
Reviewed-by: Priyanka Jain
---
v1->v3: none
arch/arm/dts/fsl-ls1088a-rdb.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/dts/fsl-ls1088a-rdb.dts b/arch/arm/dts/fsl-ls1088a-rdb.dts
index de92bf22e203..5cdd59815234 100644
--- a/arch/arm/dts/fsl-ls1088a-rdb.dts
+++ b/arch/arm/dts/fsl-ls1088a-rdb.dts
@@ -135,7 +135,7 @@
reg = <0x3>;
rtc@51 {
- compatible = "pcf2127-rtc";
+ compatible = "nxp,pcf2129";
reg = <0x51>;
};
};
--
2.25.1
[PATCH v3 02/16] rtc: pcf2127: sync with Linux compatible strings
Allow this driver to be used by boards which inherit their device trees
from Linux. Compatibility is temporarily retained with the old
compatible string which is U-Boot specific, and will be removed after a
few changes.
Cc: Simon Glass
Signed-off-by: Vladimir Oltean
Reviewed-by: Simon Glass
---
v1->v3: none
drivers/rtc/pcf2127.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/rtc/pcf2127.c b/drivers/rtc/pcf2127.c
index 57f86401d371..291ef0329a3e 100644
--- a/drivers/rtc/pcf2127.c
+++ b/drivers/rtc/pcf2127.c
@@ -121,6 +121,9 @@ static const struct rtc_ops pcf2127_rtc_ops = {
static const struct udevice_id pcf2127_rtc_ids[] = {
{ .compatible = "pcf2127-rtc" },
+ { .compatible = "nxp,pcf2127" },
+ { .compatible = "nxp,pcf2129" },
+ { .compatible = "nxp,pca2129" },
{ }
};
--
2.25.1
[PATCH v3 00/16] Sync NXP LS1028A-RDB device trees between U-Boot and Linux
The changes were intended to be minimal, but unfortunately I discovered some other stuff as well: - we need to make some changes to the compatible strings of RTC devices and I2C muxes. This has ramifications to other NXP boards which were also updated. - I broke Ethernet on LS1028A boards through a patch that is currently in Ramon's tree. Therefore this patch set is a bit larger than would be otherwise expected. The Linux device tree changes have just been posted by me here and are currently in flight, but they are rather small so I don't expect too much pushback on them: https://lore.kernel.org/linux-arm-kernel/20211202141528.2450169-5-vladimir.olt...@nxp.com/T/#m6f63c92e75fa79a01144b2c2c6dc4776e7971395 I've also triggered an Azure CI build with these changes: https://github.com/u-boot/u-boot/pull/102 and it appears that 2 tests fail due to external causes: 1. https://dev.azure.com/u-boot/u-boot/_build/results?buildId=3283=logs=5fafc5b9-a417-5c75-4c48-15c7f941e4ee=5fafc5b9-a417-5c75-4c48-15c7f941e4ee=c864b9c4-48aa-5e04-3916-54070f85e156 2. https://dev.azure.com/u-boot/u-boot/_build/results?buildId=3283=logs=5fafc5b9-a417-5c75-4c48-15c7f941e4ee=c864b9c4-48aa-5e04-3916-54070f85e156=27 Unable to find image 'trini/u-boot-gitlab-ci-runner:focal-20211006-14Nov2021' locally docker: Error response from daemon: Head "https://registry-1.docker.io/v2/trini/u-boot-gitlab-ci-runner/manifests/focal-20211006-14Nov2021": received unexpected HTTP status: 502 Bad Gateway. The other tests seem to pass. Cc: Heiko Schocher Cc: Simon Glass Cc: Ramon Fried Vladimir Oltean (16): i2c: muxes: pca954x: add PCA9847 variant rtc: pcf2127: sync with Linux compatible strings arm: dts: ls1088a-qds: use Linux compatible string for RTC arm: dts: ls1088a-rdb: use Linux compatible string for RTC arm: dts: lx2160a-qds: use Linux compatible string for RTC arm: dts: ls1028a-qds: use Linux compatible string for RTC arm: dts: ls1028a-rdb: use Linux compatible string for RTC arm: dts: lx2160a-rdb: use Linux compatible string for RTC rtc: pcf2127: remove U-Boot specific compatible string arm: dts: ls1028a-rdb: sort nodes alphabetically arm: dts: ls1028a-rdb: sync Ethernet device tree nodes with Linux arm: dts: ls1028a-rdb: disable DSPI nodes arm: dts: ls1028a-rdb: disable I2C buses 1 through 7 arm: dts: ls1028a-rdb: enable PCIe controllers from U-Boot dtsi arm: dts: ls1028a-rdb: sync device tree with Linux arm: dts: ls1028a-qds: declare in-band autoneg for Ethernet ports .../dts/fsl-ls1028a-qds-1xxx-sch-30842.dtsi | 1 + .../dts/fsl-ls1028a-qds-8xxx-sch-24801.dtsi | 1 + .../fsl-ls1028a-qds--sch-24801-LBRW.dtsi | 4 + .../dts/fsl-ls1028a-qds--sch-24801.dtsi | 4 + .../fsl-ls1028a-qds-x3xx-sch-30841-LBRW.dtsi | 4 + .../fsl-ls1028a-qds-x5xx-sch-28021-LBRW.dtsi | 4 + arch/arm/dts/fsl-ls1028a-qds.dtsi | 2 +- arch/arm/dts/fsl-ls1028a-rdb-u-boot.dtsi | 15 + arch/arm/dts/fsl-ls1028a-rdb.dts | 294 -- arch/arm/dts/fsl-ls1088a-qds.dtsi | 2 +- arch/arm/dts/fsl-ls1088a-rdb.dts | 2 +- arch/arm/dts/fsl-lx2160a-qds.dtsi | 2 +- arch/arm/dts/fsl-lx2160a-rdb.dts | 2 +- drivers/i2c/muxes/pca954x.c | 9 +- drivers/rtc/pcf2127.c | 4 +- 15 files changed, 241 insertions(+), 109 deletions(-) create mode 100644 arch/arm/dts/fsl-ls1028a-rdb-u-boot.dtsi -- 2.25.1
[PATCH v3 03/16] arm: dts: ls1088a-qds: use Linux compatible string for RTC
During the LS1028A-RDB sync with Linux device trees, it was observed
that the same RTC is present on the two boards, and the wrong compatible
string is used in both places. This change updates the RTC from the
LS1088A-QDS to use the compatible string that was established in Linux.
Signed-off-by: Vladimir Oltean
Reviewed-by: Priyanka Jain
---
v1->v3: none
arch/arm/dts/fsl-ls1088a-qds.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/dts/fsl-ls1088a-qds.dtsi
b/arch/arm/dts/fsl-ls1088a-qds.dtsi
index a7d0edcf0aa9..21c50078c3a4 100644
--- a/arch/arm/dts/fsl-ls1088a-qds.dtsi
+++ b/arch/arm/dts/fsl-ls1088a-qds.dtsi
@@ -88,7 +88,7 @@
reg = <0x3>;
rtc@51 {
- compatible = "pcf2127-rtc";
+ compatible = "nxp,pcf2129";
reg = <0x51>;
};
};
--
2.25.1
[PATCH v3 01/16] i2c: muxes: pca954x: add PCA9847 variant
This seems to be very similar to the already existing PCA9547, save for
the fact that it supports 0.8V and doesn't support 5V. In fact, it is so
similar to the PCA9547 that the NXP LS1028A-RDB board has been driving
this chip using a "nxp,pca9547" compatible string.
Create a new compatible for the PCA9847 (which is the same as in Linux)
and define the same operating parameters for it as for PCA9547.
Cc: Heiko Schocher
Signed-off-by: Vladimir Oltean
Reviewed-by: Heiko Schocher
Reviewed-by: Priyanka Jain
---
v1->v3: none
drivers/i2c/muxes/pca954x.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/muxes/pca954x.c b/drivers/i2c/muxes/pca954x.c
index 55858cf653f2..0034dfbf6daf 100644
--- a/drivers/i2c/muxes/pca954x.c
+++ b/drivers/i2c/muxes/pca954x.c
@@ -23,7 +23,8 @@ enum pca_type {
PCA9546,
PCA9547,
PCA9548,
- PCA9646
+ PCA9646,
+ PCA9847,
};
struct chip_desc {
@@ -68,6 +69,11 @@ static const struct chip_desc chips[] = {
.muxtype = pca954x_isswi,
.width = 4,
},
+ [PCA9847] = {
+ .enable = 0x8,
+ .muxtype = pca954x_ismux,
+ .width = 8,
+ },
};
static int pca954x_deselect(struct udevice *mux, struct udevice *bus,
@@ -106,6 +112,7 @@ static const struct udevice_id pca954x_ids[] = {
{ .compatible = "nxp,pca9547", .data = PCA9547 },
{ .compatible = "nxp,pca9548", .data = PCA9548 },
{ .compatible = "nxp,pca9646", .data = PCA9646 },
+ { .compatible = "nxp,pca9847", .data = PCA9847 },
{ }
};
--
2.25.1
Re: [PATCH v3] efi_loader: Get rid of kaslr-seed if EFI_RNG_PROTOCOL is installed
> From: Ilias Apalodimas
> Date: Mon, 3 Jan 2022 14:07:37 +0200
>
> U-Boot, in some occasions, injects a 'kaslr-seed' property on the /chosen
> node. That would be problematic in case we want to measure the DTB we
> install in the config table, since it would change across reboots.
>
> The Linux kernel EFI-stub completely ignores it and only relies on
> EFI_RNG_PROTOCOL for it's own randomness needs (i.e the randomization
> of the physical placement of the kernel). In fact it (blindly) overwrites
> the existing seed if the protocol is installed. However it still uses it
> for randomizing it's virtual placement.
> So let's get rid of it in the presence of the RNG protocol.
>
> It's worth noting that TPMs also provide an RNG. So if we tweak our
> EFI_RNG_PROTOCOL slightly and install the protocol when a TPM device
> is present the 'kaslr-seed' property will always be removed, allowing
> us to reliably measure our DTB.
>
> Acked-by: Ard Biesheuvel
> Signed-off-by: Ilias Apalodimas
> ---
> changes since v2:
> - Mark proposed a better commit message description
> changes since v1:
> - Only removing the property if EFI_RNG_PROTOCOL is installed, since some
> OS'es rely on kaslr-seed
> - Only display an error message if the kaslr-seed entry was found but not
> removed
> cmd/bootefi.c | 2 ++
> include/efi_loader.h | 2 ++
> lib/efi_loader/efi_dt_fixup.c | 33 +
> 3 files changed, 37 insertions(+)
Reviewed-by: Mark Kettenis
> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> index d77d3b6e943d..57f13ce701ec 100644
> --- a/cmd/bootefi.c
> +++ b/cmd/bootefi.c
> @@ -310,6 +310,8 @@ efi_status_t efi_install_fdt(void *fdt)
> /* Create memory reservations as indicated by the device tree */
> efi_carve_out_dt_rsv(fdt);
>
> + efi_try_purge_kaslr_seed(fdt);
> +
> /* Install device tree as UEFI table */
> ret = efi_install_configuration_table(_guid_fdt, fdt);
> if (ret != EFI_SUCCESS) {
> diff --git a/include/efi_loader.h b/include/efi_loader.h
> index 9dd6c2033634..1fe003db69e0 100644
> --- a/include/efi_loader.h
> +++ b/include/efi_loader.h
> @@ -519,6 +519,8 @@ efi_status_t EFIAPI efi_convert_pointer(efi_uintn_t
> debug_disposition,
> void **address);
> /* Carve out DT reserved memory ranges */
> void efi_carve_out_dt_rsv(void *fdt);
> +/* Purge unused kaslr-seed */
> +void efi_try_purge_kaslr_seed(void *fdt);
> /* Called by bootefi to make console interface available */
> efi_status_t efi_console_register(void);
> /* Called by bootefi to make all disk storage accessible as EFI objects */
> diff --git a/lib/efi_loader/efi_dt_fixup.c b/lib/efi_loader/efi_dt_fixup.c
> index b6fe5d2e5a34..d3923e5dba1b 100644
> --- a/lib/efi_loader/efi_dt_fixup.c
> +++ b/lib/efi_loader/efi_dt_fixup.c
> @@ -8,6 +8,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -40,6 +41,38 @@ static void efi_reserve_memory(u64 addr, u64 size, bool
> nomap)
> addr, size);
> }
>
> +/**
> + * efi_try_purge_kaslr_seed() - Remove unused kaslr-seed
> + *
> + * Kernel's EFI STUB only relies on EFI_RNG_PROTOCOL for randomization
> + * and completely ignores the kaslr-seed for its own randomness needs
> + * (i.e the randomization of the physical placement of the kernel).
> + * Weed it out from the DTB we hand over, which would mess up our DTB
> + * TPM measurements as well.
> + *
> + * @fdt: Pointer to device tree
> + */
> +void efi_try_purge_kaslr_seed(void *fdt)
> +{
> + const efi_guid_t efi_guid_rng_protocol = EFI_RNG_PROTOCOL_GUID;
> + struct efi_handler *handler;
> + efi_status_t ret;
> + int nodeoff = 0;
> + int err = 0;
> +
> + ret = efi_search_protocol(efi_root, _guid_rng_protocol, );
> + if (ret != EFI_SUCCESS)
> + return;
> +
> + nodeoff = fdt_path_offset(fdt, "/chosen");
> + if (nodeoff < 0)
> + return;
> +
> + err = fdt_delprop(fdt, nodeoff, "kaslr-seed");
> + if (err < 0 && err != -FDT_ERR_NOTFOUND)
> + log_err("Error deleting kaslr-seed\n");
> +}
> +
> /**
> * efi_carve_out_dt_rsv() - Carve out DT reserved memory ranges
> *
> --
> 2.30.2
>
>
Re: [PATCH] arm: dts: rk3399-puma: re-add vdd_log for uboot
Hi Heiko,
On 12/26/21 13:45, Heiko Stuebner wrote:
The rk3399-puma board needs a 950mV vdd_log to work stable.
This was already added in
commit 77012e79ffc3 ("rockchip: rk3399-puma: Set VDD_LOG to 950 mV")
but lost again with
commit 167efc2c7a46 ("arm64: dts: rk3399: Sync v5.7-rc1 from Linux")
So to make puma stable again re-add the vdd_log pwm regulator.
As it is not part of the mainline Linux dts right now, add it
to the -u-boot dtsi for puma.
Fixes: 167efc2c7a46 ("arm64: dts: rk3399: Sync v5.7-rc1 from Linux")
Signed-off-by: Heiko Stuebner
---
arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi
b/arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi
index 29846c4b00..76eb51d2d7 100644
--- a/arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi
@@ -49,6 +49,17 @@
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
};
+
+ vdd_log: vdd-log {
+ compatible = "pwm-regulator";
+ pwms = < 0 25000 1>;
+ regulator-name = "vdd_log";
+ regulator-min-microvolt = <80>;
+ regulator-max-microvolt = <140>;
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-init-microvolt = <95>;
+ };
};
{
Is this a spurious patch by any chance?
https://source.denx.de/u-boot/u-boot/-/commit/1621afc84f8a109cfdb98c9e370c355289e07870
seems to have more or less the same content, sent (and merged) about a
year ago by Christoph.
Moreover, it seems to still be there in master:
https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi#L52-L62
Cheers,
Quentin
Re: [PATCH v2] rockchip: puma/lion: update MAINTAINERS file
On Mon, 3 Jan 2022 at 13:04, wrote: > > From: Quentin Schulz > > Philipp does not work at Theobroma Systems anymore so let's swap > Philipp's address with mine. > > Cc: Philipp Tomsich > Cc: Quentin Schulz > Signed-off-by: Quentin Schulz Reviewed-by: Philipp Tomsich
[PATCH v3] efi_loader: Get rid of kaslr-seed if EFI_RNG_PROTOCOL is installed
U-Boot, in some occasions, injects a 'kaslr-seed' property on the /chosen
node. That would be problematic in case we want to measure the DTB we
install in the config table, since it would change across reboots.
The Linux kernel EFI-stub completely ignores it and only relies on
EFI_RNG_PROTOCOL for it's own randomness needs (i.e the randomization
of the physical placement of the kernel). In fact it (blindly) overwrites
the existing seed if the protocol is installed. However it still uses it
for randomizing it's virtual placement.
So let's get rid of it in the presence of the RNG protocol.
It's worth noting that TPMs also provide an RNG. So if we tweak our
EFI_RNG_PROTOCOL slightly and install the protocol when a TPM device
is present the 'kaslr-seed' property will always be removed, allowing
us to reliably measure our DTB.
Acked-by: Ard Biesheuvel
Signed-off-by: Ilias Apalodimas
---
changes since v2:
- Mark proposed a better commit message description
changes since v1:
- Only removing the property if EFI_RNG_PROTOCOL is installed, since some
OS'es rely on kaslr-seed
- Only display an error message if the kaslr-seed entry was found but not
removed
cmd/bootefi.c | 2 ++
include/efi_loader.h | 2 ++
lib/efi_loader/efi_dt_fixup.c | 33 +
3 files changed, 37 insertions(+)
diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index d77d3b6e943d..57f13ce701ec 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -310,6 +310,8 @@ efi_status_t efi_install_fdt(void *fdt)
/* Create memory reservations as indicated by the device tree */
efi_carve_out_dt_rsv(fdt);
+ efi_try_purge_kaslr_seed(fdt);
+
/* Install device tree as UEFI table */
ret = efi_install_configuration_table(_guid_fdt, fdt);
if (ret != EFI_SUCCESS) {
diff --git a/include/efi_loader.h b/include/efi_loader.h
index 9dd6c2033634..1fe003db69e0 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -519,6 +519,8 @@ efi_status_t EFIAPI efi_convert_pointer(efi_uintn_t
debug_disposition,
void **address);
/* Carve out DT reserved memory ranges */
void efi_carve_out_dt_rsv(void *fdt);
+/* Purge unused kaslr-seed */
+void efi_try_purge_kaslr_seed(void *fdt);
/* Called by bootefi to make console interface available */
efi_status_t efi_console_register(void);
/* Called by bootefi to make all disk storage accessible as EFI objects */
diff --git a/lib/efi_loader/efi_dt_fixup.c b/lib/efi_loader/efi_dt_fixup.c
index b6fe5d2e5a34..d3923e5dba1b 100644
--- a/lib/efi_loader/efi_dt_fixup.c
+++ b/lib/efi_loader/efi_dt_fixup.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include
#include
@@ -40,6 +41,38 @@ static void efi_reserve_memory(u64 addr, u64 size, bool
nomap)
addr, size);
}
+/**
+ * efi_try_purge_kaslr_seed() - Remove unused kaslr-seed
+ *
+ * Kernel's EFI STUB only relies on EFI_RNG_PROTOCOL for randomization
+ * and completely ignores the kaslr-seed for its own randomness needs
+ * (i.e the randomization of the physical placement of the kernel).
+ * Weed it out from the DTB we hand over, which would mess up our DTB
+ * TPM measurements as well.
+ *
+ * @fdt: Pointer to device tree
+ */
+void efi_try_purge_kaslr_seed(void *fdt)
+{
+ const efi_guid_t efi_guid_rng_protocol = EFI_RNG_PROTOCOL_GUID;
+ struct efi_handler *handler;
+ efi_status_t ret;
+ int nodeoff = 0;
+ int err = 0;
+
+ ret = efi_search_protocol(efi_root, _guid_rng_protocol, );
+ if (ret != EFI_SUCCESS)
+ return;
+
+ nodeoff = fdt_path_offset(fdt, "/chosen");
+ if (nodeoff < 0)
+ return;
+
+ err = fdt_delprop(fdt, nodeoff, "kaslr-seed");
+ if (err < 0 && err != -FDT_ERR_NOTFOUND)
+ log_err("Error deleting kaslr-seed\n");
+}
+
/**
* efi_carve_out_dt_rsv() - Carve out DT reserved memory ranges
*
--
2.30.2
[PATCH v2] rockchip: puma/lion: update MAINTAINERS file
From: Quentin Schulz Philipp does not work at Theobroma Systems anymore so let's swap Philipp's address with mine. Cc: Philipp Tomsich Cc: Quentin Schulz Signed-off-by: Quentin Schulz --- v2: add commit log so that the commit can be merged @Philipp, I can update your mail address if you want to keep maintainership and be reachable. Let me know. board/theobroma-systems/lion_rk3368/MAINTAINERS | 2 +- board/theobroma-systems/puma_rk3399/MAINTAINERS | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/board/theobroma-systems/lion_rk3368/MAINTAINERS b/board/theobroma-systems/lion_rk3368/MAINTAINERS index 857f784d21..a5b4cb31b4 100644 --- a/board/theobroma-systems/lion_rk3368/MAINTAINERS +++ b/board/theobroma-systems/lion_rk3368/MAINTAINERS @@ -1,5 +1,5 @@ LION-RK3368 (RK3368-uQ7 system-on-module) -M: Philipp Tomsich +M: Quentin Schulz M: Klaus Goger S: Maintained F: board/theobroma-systems/lion_rk3368 diff --git a/board/theobroma-systems/puma_rk3399/MAINTAINERS b/board/theobroma-systems/puma_rk3399/MAINTAINERS index ccec09c386..1ec2dd72d6 100644 --- a/board/theobroma-systems/puma_rk3399/MAINTAINERS +++ b/board/theobroma-systems/puma_rk3399/MAINTAINERS @@ -1,5 +1,5 @@ PUMA-RK3399 -M: Philipp Tomsich +M: Quentin Schulz M: Klaus Goger S: Maintained F: board/theobroma-systems/puma_rk3399 -- 2.33.1
Re: [PATCH v2] imx: Enable ACTLR.SMP in SPL for i.MX6/7
Hi Sven, On Sun, Jan 2, 2022 at 4:38 PM Sven Schwermer wrote: > > Similar to what has been done before with c5437e5b for u-boot proper, we > enable the SMP bit for SPL as well. This is necessary when SDP booting > straight into Linux, i.e. falcon boot. When SDP boot mode is active, the > ROM code does not set this bit which makes the caches not work once > activated in Linux. > > On an i.MX6ULL (528MHz), this reduces a minimal kernel's boot time into > an initramfs shell from ~6.1s down to ~1.2s. > > Signed-off-by: Sven Schwermer > --- > > Changes in v2: > - Apply fix for i.MX7(ULP) as well > - Document quantitive improvement in boot time Thanks for the updated version. It looks good to me: Reviewed-by: Fabio Estevam
Re: [PATCH v2] riscv: cancel the limitation that NR_CPUS is less than or equal to 32
On Thu, Dec 30, 2021 at 01:55:15AM +0800, Xiang W wrote: > 在 2021-12-29星期三的 17:23 +0800，Leo Liang写道： > > Hi Xiang, > > On Wed, Dec 22, 2021 at 07:32:53AM +0800, Xiang W wrote: > > > Various specifications of riscv allow the number of hart to be > > > greater than 32. The limit of 32 is determined by > > > gd->arch.available_harts. We can eliminate this limitation through > > > bitmaps. Currently, the number of hart is limited to 4095, and 4095 > > > is the limit of the RISC-V Advanced Core Local Interruptor > > > Specification. > > > > > > Test on sifive unmatched. > > > > > > Signed-off-by: Xiang W > > > --- > > > Changes since v1: > > > > > > * When NR_CPUS is very large, the value of GD_AVAILABLE_HARTS will > > > overflow the immediate range of ld/lw. This patch fixes this > > > problem > > > > > > arch/riscv/Kconfig | 4 ++-- > > > arch/riscv/cpu/start.S | 21 - > > > arch/riscv/include/asm/global_data.h | 4 +++- > > > arch/riscv/lib/smp.c | 2 +- > > > 4 files changed, 22 insertions(+), 9 deletions(-) > > > > > > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S > > > index 76850ec9be..92f3b78f29 100644 > > > --- a/arch/riscv/cpu/start.S > > > +++ b/arch/riscv/cpu/start.S > > > @@ -166,11 +166,22 @@ wait_for_gd_init: > > > mv gp, s0 > > > > > > /* register available harts in the available_harts mask */ > > > - li t1, 1 > > > - sll t1, t1, tp > > > - LREGt2, GD_AVAILABLE_HARTS(gp) > > > - or t2, t2, t1 > > > - SREGt2, GD_AVAILABLE_HARTS(gp) > > > + li t1, GD_AVAILABLE_HARTS > > > + add t1, t1, gp > > > + LREGt1, 0(t1) > > > +#if defined(CONFIG_ARCH_RV64I) > > > + srlit2, tp, 6 > > > + sllit2, t2, 3 > > > +#elif defined(CONFIG_ARCH_RV32I) > > > + srlit2, tp, 5 > > > + sllit2, t2, 2 > > > +#endif > > > + add t1, t1, t2 > > > + LREGt2, 0(t1) > > > + li t3, 1 > > > + sll t3, t3, tp > > This seems incorrect. > > Shouldn't we have "$tp % sizeof(ulong)" instead of "$tp / > > sizeof(ulong)" ? > > Do you meening: "$tp % sizeof(ulong)" instead of "$tp" ? > > There is such a description in the riscv specification： > > SLL, SRL, and SRA perform logical left, logical right, and arithmetic > right shifts on the value in register rs1 by the shift amount held in > the lower 5 bits of register rs2. > > SLL, SRL, and SRA perform logical left, logical right, and arithmetic > right shifts on the value in register rs1 by the shift amount held in > register rs2. In RV64I, only the low 6 bits of rs2 are considered for > the shift amount. > > So we don’t need to perform the remainder operation. Got it! Thanks for the explanation. LGTM, Reviewed-by: Leo Yu-Chi Liang Best regards, Leo > > regards， > Xiang W > > > + or t2, t2, t3 > > > + SREGt2, 0(t1) > > > > > > amoswap.w.rl zero, zero, 0(t0) > > Best regards, > > Leo > >
Re: [RFC v2 05/20] mmc: call device_probe() after scanning
Dear AKASHI,
On 12/10/21 3:49 PM, AKASHI Takahiro wrote:
> Every time a mmc bus/port is scanned and a new device is detected,
> we want to call device_probe() as it will give us a chance to run
> additional post-processings for some purposes.
>
> In particular, support for creating partitions on a device will be added.
If add me and Peng as Cc when you sent the patches related with mmc, it's more
helpful to review.
Best Regards,
Jaehoon Chung
>
> Signed-off-by: AKASHI Takahiro
> ---
> drivers/mmc/mmc-uclass.c | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/mmc/mmc-uclass.c b/drivers/mmc/mmc-uclass.c
> index 3ee92d03ca23..6c907b65fde7 100644
> --- a/drivers/mmc/mmc-uclass.c
> +++ b/drivers/mmc/mmc-uclass.c
> @@ -418,6 +418,7 @@ int mmc_bind(struct udevice *dev, struct mmc *mmc, const
> struct mmc_config *cfg)
> bdesc->part_type = cfg->part_type;
> mmc->dev = dev;
> mmc->user_speed_mode = MMC_MODES_END;
> +
> return 0;
> }
>
> @@ -467,6 +468,18 @@ static int mmc_blk_probe(struct udevice *dev)
> return ret;
> }
>
> + ret = device_probe(dev);
> + if (ret) {
> + debug("Can't probe\n");
> +
> + if (IS_ENABLED(CONFIG_MMC_UHS_SUPPORT) ||
> + IS_ENABLED(CONFIG_MMC_HS200_SUPPORT) ||
> + IS_ENABLED(CONFIG_MMC_HS400_SUPPORT))
> + mmc_deinit(mmc);
> +
> + return ret;
> + }
> +
> return 0;
> }
>
>
Re: [PATCH v6 1/4] mtd: spi-nor: macronix: add support for Macronix Octal
Hi Jaime,
You made a typo on Jagan's address, you might need to resend.
The title does not look correct, maybe you miss a word after Octal. And
is it something Macronix specific? I believe this is generic and you
can drop "Macronix" (the second occurrence) from the title.
jaimeliao...@gmail.com wrote on Wed, 29 Dec 2021 13:56:17 +0800:
> Follow patch "f6adec1af4b2f5d3012480c6cdce7743b74a6156" for adding
When pointing to an upstream commit I think even in U-Boot the style
should be something like:
<12-digit hash> ("title of the commit")
which at least allows to know which commit we are talking about.
> Macronix flash in Octal DTR mode.
This first part of the commit log should be moved below.
>
> Enable Octal DTR mode with 20 dummy cycles to allow running at the
> maximum supported frequency.
>
> -https://www.mxic.com.tw/Lists/Datasheet/Attachments/7841/MX25LM51245G,%203V,%20512Mb,%20v1.1.pdf
>
> Signed-off-by: JaimeLiao
> ---
> drivers/mtd/spi/spi-nor-core.c | 83 ++
> include/linux/mtd/spi-nor.h| 12 -
> 2 files changed, 93 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
> index d5d905fa5a..0a6550984b 100644
> --- a/drivers/mtd/spi/spi-nor-core.c
> +++ b/drivers/mtd/spi/spi-nor-core.c
> @@ -3489,6 +3489,85 @@ static struct spi_nor_fixups mt35xu512aba_fixups = {
> };
> #endif /* CONFIG_SPI_FLASH_MT35XU */
>
> +#if CONFIG_IS_ENABLED(SPI_FLASH_MACRONIX)
> +/**
> + * spi_nor_macronix_octal_dtr_enable() - set DTR OPI Enable bit in
> Configuration Register 2.
This is very specific to Macronix I believe? Please just use a generic
description here.
> + * @nor: pointer to a 'struct spi_nor'
> + *
> + * Set the DTR OPI Enable (DOPI) bit in Configuration Register 2.
> + * Bit 2 of Configuration Register 2 is the DOPI bit for Macronix like OPI
> memories.
> + *
> + * Return: 0 on success, -errno otherwise.
> + */
> +static int spi_nor_macronix_octal_dtr_enable(struct spi_nor *nor)
> +{
> + struct spi_mem_op op;
> + int ret;
> + u8 buf;
> +
> + ret = write_enable(nor);
> + if (ret)
> + return ret;
> +
> + buf = SPINOR_REG_MXIC_DC_20;
> + op = (struct spi_mem_op)
> + SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_WR_CR2, 1),
> +SPI_MEM_OP_ADDR(4, SPINOR_REG_MXIC_CR2_DC, 1),
> +SPI_MEM_OP_NO_DUMMY,
> +SPI_MEM_OP_DATA_OUT(1, , 1));
> +
> + ret = spi_mem_exec_op(nor->spi, );
> + if (ret)
> + return ret;
> +
> + ret = spi_nor_wait_till_ready(nor);
> + if (ret)
> + return ret;
> +
> + nor->read_dummy = MXIC_MAX_DC;
> + ret = write_enable(nor);
> + if (ret)
> + return ret;
> +
> + buf = SPINOR_REG_MXIC_OPI_DTR_EN;
> + op = (struct spi_mem_op)
> + SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_WR_CR2, 1),
> +SPI_MEM_OP_ADDR(4, SPINOR_REG_MXIC_CR2_MODE, 1),
> +SPI_MEM_OP_NO_DUMMY,
> +SPI_MEM_OP_DATA_OUT(1, , 1));
> +
> + ret = spi_mem_exec_op(nor->spi, );
> + if (ret) {
> + dev_err(nor->dev, "Failed to enable octal DTR mode\n");
> + return ret;
> + }
> + nor->reg_proto = SNOR_PROTO_8_8_8_DTR;
> +
> + return 0;
> +}
> +
> +static void macronix_octal_default_init(struct spi_nor *nor)
> +{
> + nor->octal_dtr_enable = spi_nor_macronix_octal_dtr_enable;
> +}
> +
> +static void macronix_octal_post_sfdp_fixup(struct spi_nor *nor,
> + struct spi_nor_flash_parameter *params)
> +{
> + /*
> + * Adding SNOR_HWCAPS_PP_8_8_8_DTR in hwcaps.mask when
> + * SPI_NOR_OCTAL_DTR_READ flag exists.
> + */
> + if (params->hwcaps.mask & SNOR_HWCAPS_READ_8_8_8_DTR)
> + params->hwcaps.mask |= SNOR_HWCAPS_PP_8_8_8_DTR;
> +}
> +
> +static struct spi_nor_fixups macronix_octal_fixups = {
> + .default_init = macronix_octal_default_init,
> + .post_sfdp = macronix_octal_post_sfdp_fixup,
> +};
> +#endif /* CONFIG_SPI_FLASH_MACRONIX */
> +
> /** spi_nor_octal_dtr_enable() - enable Octal DTR I/O if needed
> * @nor: pointer to a 'struct spi_nor'
> *
> @@ -3655,6 +3734,10 @@ void spi_nor_set_fixups(struct spi_nor *nor)
> if (!strcmp(nor->info->name, "mt35xu512aba"))
> nor->fixups = _fixups;
> #endif
> +
> +#if CONFIG_IS_ENABLED(SPI_FLASH_MACRONIX)
> + nor->fixups = _octal_fixups;
> +#endif /* SPI_FLASH_MACRONIX */
> }
>
> int spi_nor_scan(struct spi_nor *nor)
> diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
> index 7ddc4ba2bf..8682368f2f 100644
> --- a/include/linux/mtd/spi-nor.h
> +++ b/include/linux/mtd/spi-nor.h
> @@ -116,8 +116,16 @@
> #define XSR_RDY BIT(7) /* Ready */
>
> /* Used for Macronix and Winbond flashes. */
> -#define SPINOR_OP_EN4B
RE: How should I set load_address for fdt in the .its file...
Hello all, For my question below, I later found I didn't load enough bytes for the FIT image (that's why it could find the configuration node). Now because our FPGA board has only 8MB fake RAM for now, I loaded FIT (about 5.7MB. containing kernel Image, fdt and initramfs.cpio.gz) to 0x8000_ (start of fake RAM ). I'm using 'boot from RAM' method(using CONFIG_SPL_RAM_DEVICE, CONFIG_SPL_OS_BOOT). The spl tried to copy the kernel to another location, so I skipped the kernel memcpy to use the kernel image as is inside the FIT image. And I made the fdt to be copied to a location above FIT image. Now I see 'Jumping to Linux' message. I have three questions here..(sorry for asking too many questions at once) 1. I wish linux could start with the kernel image inside FIT as is. But the start address of the kernel image is 0x80bc, a weird address, and I guess there was a certain requirement for the kernel image alignment (like 16KB?). So can this(using kernel image as in the FIT image, not aligned nicely to 4KB) work? 2. In my spl_image_info struct, the 'void *arg' value is set to NULL. How should I set the value? (I have already CONFIG_BOOT_ARGS=y and CONFIG_BOOTARGS has values for passing the console and earlycon, but I don't know how to fill the spl_image_info's arg value) 3. Another question is, in this method, can linux recognize the initramfs.cpio.gz file? (I guessed so because using qemu, it worked) Any comment will be appreciated. Happy new year! Chan Kim > -Original Message- > From: U-Boot On Behalf Of c...@etri.re.kr > Sent: Thursday, December 23, 2021 6:49 PM > To: 'U-Boot Mailing List' > Subject: How should I set load_address for fdt in the .its file... > > Hello all, > > I saw https://www.thegoodpenguin.co.uk/blog/u-boot-fit-image-overview/ and > used it to make .itb file (FIT image). > > (see the its sample right below the line saying : Let's try this out by > creating an image tree source file (.its): ) > > I was doing the experiment and found the load address of fdt was set wrong > and changed it to the next address after the linux kernel (but 8 byte > aligned). > > But the SPL program complains it can't find the 'configurations' node. So > I'm curious about how I should set the address. > > But I'm not sure how to set the 'load_address' and 'entry_address' for fdt. > Should I set it so that fdt is just placed some place above the linux > Image? > > And why doesn't initrd image node have those 'load_address' and > 'entry_address'? > > Thanks for reading. > > Chan Kim > > > > >
