Re: [U-Boot] [PATCH] net: e1000: support 'write_hwaddr' in DM

2018-10-10 Thread Joe Hershberger
On Thu, Oct 11, 2018 at 12:43 AM Hannes Schmelzer
 wrote:
>
> This commit ports the existing (non-DM) function for writing the MAC-
> address into the shadow ram (and flash) for DM.
>
> Signed-off-by: Hannes Schmelzer 

Acked-by: Joe Hershberger 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] net/phy: Add phy-id for IN112525_S03

2018-10-10 Thread Joe Hershberger
On Wed, Oct 10, 2018 at 11:47 PM Priyanka Jain  wrote:
>
> Signed-off-by: Priyanka Jain 

Acked-by: Joe Hershberger 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH] x86/bootm: fix compressed image boot

2018-10-10 Thread Hannes Schmelzer
If we're booting some u-boot module with compressed payload, we have to
use the pointer where the image really has been loaded (unzipped) to
instead the pointer to the payload of the u-boot module.

Signed-off-by: Hannes Schmelzer 
---

 arch/x86/lib/bootm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/lib/bootm.c b/arch/x86/lib/bootm.c
index 54c22fe..4102bcb 100644
--- a/arch/x86/lib/bootm.c
+++ b/arch/x86/lib/bootm.c
@@ -94,8 +94,8 @@ static int boot_prep_linux(bootm_headers_t *images)
len = os_len;
} else {
/* otherwise get image data */
-   data = (void *)image_get_data(hdr);
-   len = image_get_data_size(hdr);
+   data = (void *)images->os.load;
+   len = 0;
}
is_zimage = 1;
 #if defined(CONFIG_FIT)
-- 
2.7.4


___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH] x86/bootm: fix error handling in boot_prep_linux(...)

2018-10-10 Thread Hannes Schmelzer
Once we get a zero pointer from load_zimage(...) we must bunch out
instead of continue boot.

Signed-off-by: Hannes Schmelzer 
---

 arch/x86/lib/bootm.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/x86/lib/bootm.c b/arch/x86/lib/bootm.c
index 54c22fe..832b1f9 100644
--- a/arch/x86/lib/bootm.c
+++ b/arch/x86/lib/bootm.c
@@ -116,6 +116,10 @@ static int boot_prep_linux(bootm_headers_t *images)
char *base_ptr;
 
base_ptr = (char *)load_zimage(data, len, _address);
+   if (!base_ptr) {
+   puts("## Kernel loading failed ...\n");
+   goto error;
+   }
images->os.load = load_address;
cmd_line_dest = base_ptr + COMMAND_LINE_OFFSET;
images->ep = (ulong)base_ptr;
-- 
2.7.4


___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] i2c: Fix pca953x endianess issue, commit daa75b34828d45b7c1d63009188d45f4a32d06ba

2018-10-10 Thread Heiko Schocher

Hello Joakim,

Am 10.10.2018 um 19:34 schrieb Joakim Tjernlund:

This commit broke our pca953x usage(on ppc).

I wonder why gpio pins here has an endian, its not a number.
If there must be an endian connected with this, should it not
be a cpu_to_be16 instead, which will retain compatibility ?


Hmm.. good question, I think you are right. May dirk can do a test?
I have no pca953x with 16bit for doing a test.

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH] net: e1000: support 'write_hwaddr' in DM

2018-10-10 Thread Hannes Schmelzer
This commit ports the existing (non-DM) function for writing the MAC-
address into the shadow ram (and flash) for DM.

Signed-off-by: Hannes Schmelzer 
---

 drivers/net/e1000.c | 89 +
 1 file changed, 48 insertions(+), 41 deletions(-)

diff --git a/drivers/net/e1000.c b/drivers/net/e1000.c
index a34f697..939e23e 100644
--- a/drivers/net/e1000.c
+++ b/drivers/net/e1000.c
@@ -862,7 +862,6 @@ e1000_read_eeprom(struct e1000_hw *hw, uint16_t offset,
return E1000_SUCCESS;
 }
 
-#ifndef CONFIG_DM_ETH
 /**
  *  e1000_write_eeprom_srwr - Write to Shadow Ram using EEWR
  *  @hw: pointer to the HW structure
@@ -1028,7 +1027,6 @@ static int32_t e1000_update_eeprom_checksum_i210(struct 
e1000_hw *hw)
 out:
return ret_val;
 }
-#endif
 
 /**
  * Verifies that the EEPROM has a valid checksum
@@ -5649,45 +5647,6 @@ e1000_poll(struct eth_device *nic)
return len ? 1 : 0;
 }
 
-static int e1000_write_hwaddr(struct eth_device *dev)
-{
-#ifndef CONFIG_E1000_NO_NVM
-   unsigned char *mac = dev->enetaddr;
-   unsigned char current_mac[6];
-   struct e1000_hw *hw = dev->priv;
-   uint16_t data[3];
-   int ret_val, i;
-
-   DEBUGOUT("%s: mac=%pM\n", __func__, mac);
-
-   memset(current_mac, 0, 6);
-
-   /* Read from EEPROM, not from registers, to make sure
-* the address is persistently configured
-*/
-   ret_val = e1000_read_mac_addr_from_eeprom(hw, current_mac);
-   DEBUGOUT("%s: current mac=%pM\n", __func__, current_mac);
-
-   /* Only write to EEPROM if the given address is different or
-* reading the current address failed
-*/
-   if (!ret_val && memcmp(current_mac, mac, 6) == 0)
-   return 0;
-
-   for (i = 0; i < 3; ++i)
-   data[i] = mac[i * 2 + 1] << 8 | mac[i * 2];
-
-   ret_val = e1000_write_eeprom_srwr(hw, 0x0, 3, data);
-
-   if (!ret_val)
-   ret_val = e1000_update_eeprom_checksum_i210(hw);
-
-   return ret_val;
-#else
-   return 0;
-#endif
-}
-
 /**
 PROBE - Look for an adapter, this routine's visible to the outside
 You should omit the last argument struct pci_device * for a non-PCI NIC
@@ -5756,6 +5715,53 @@ struct e1000_hw *e1000_find_card(unsigned int cardnum)
 }
 #endif /* !CONFIG_DM_ETH */
 
+#ifndef CONFIG_DM_ETH
+static int e1000_write_hwaddr(struct eth_device *dev)
+#else
+static int e1000_write_hwaddr(struct udevice *dev)
+#endif
+{
+#ifndef CONFIG_E1000_NO_NVM
+#ifndef CONFIG_DM_ETH
+   unsigned char *mac = dev->enetaddr;
+   struct e1000_hw *hw = dev->priv;
+#else
+   struct eth_pdata *plat = dev_get_platdata(dev);
+   unsigned char *mac = plat->enetaddr;
+   struct e1000_hw *hw = dev_get_priv(dev);
+#endif
+   unsigned char current_mac[6];
+   u16 data[3];
+   int ret_val, i;
+
+   DEBUGOUT("%s: mac=%pM\n", __func__, mac);
+
+   memset(current_mac, 0, 6);
+
+   /* Read from EEPROM, not from registers, to make sure
+* the address is persistently configured
+*/
+   ret_val = e1000_read_mac_addr_from_eeprom(hw, current_mac);
+   DEBUGOUT("%s: current mac=%pM\n", __func__, current_mac);
+
+   /* Only write to EEPROM if the given address is different or
+* reading the current address failed
+*/
+   if (!ret_val && memcmp(current_mac, mac, 6) == 0)
+   return 0;
+
+   for (i = 0; i < 3; ++i)
+   data[i] = mac[i * 2 + 1] << 8 | mac[i * 2];
+
+   ret_val = e1000_write_eeprom_srwr(hw, 0x0, 3, data);
+   if (!ret_val)
+   ret_val = e1000_update_eeprom_checksum_i210(hw);
+   return ret_val;
+#else  /* CONFIG_E1000_NO_NVM */
+   return 0;
+#endif
+}
+
 #ifdef CONFIG_CMD_E1000
 static int do_e1000(cmd_tbl_t *cmdtp, int flag,
int argc, char * const argv[])
@@ -5914,6 +5920,7 @@ static const struct eth_ops e1000_eth_ops = {
.recv   = e1000_eth_recv,
.stop   = e1000_eth_stop,
.free_pkt = e1000_free_pkt,
+   .write_hwaddr = e1000_write_hwaddr,
 };
 
 static const struct udevice_id e1000_eth_ids[] = {
-- 
2.7.4


___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] net/phy: Add phy-id for IN112525_S03

2018-10-10 Thread Priyanka Jain


>-Original Message-
>From: Joe Hershberger 
>Sent: Thursday, October 11, 2018 10:55 AM
>To: Priyanka Jain 
>Cc: u-boot ; York Sun ; Joseph
>Hershberger 
>Subject: Re: [U-Boot] [PATCH] net/phy: Add phy-id for IN112525_S03
>
>On Wed, Oct 10, 2018 at 11:47 PM Priyanka Jain 
>wrote:
>>
>> Signed-off-by: Priyanka Jain 
>> ---
>>  include/phy.h | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/include/phy.h b/include/phy.h index 52bf997..ef5ca7e
>> 100644
>> --- a/include/phy.h
>> +++ b/include/phy.h
>> @@ -315,5 +315,6 @@ static inline bool phy_interface_is_sgmii(struct
>> phy_device *phydev)
>>  /* PHY UIDs for various PHYs that are referenced in external code */
>> #define PHY_UID_CS4340  0x13e51002  #define PHY_UID_TN2020
>0x00a19410
>> +#define PHY_UID_IN112525_S03   0x02107440
>
>Why define it and not use it anywhere?
>
I am working on lx2160ardb board patch which will use this.
>>
>>  #endif
>> --
>> 1.9.1
>>
>> ___
>> U-Boot mailing list
>> U-Boot@lists.denx.de
>> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis
>> ts.denx.de%2Flistinfo%2Fu-
>bootdata=02%7C01%7Cpriyanka.jain%40nxp.
>>
>com%7C2879387b37434dc54c4708d62f39ed63%7C686ea1d3bc2b4c6fa92cd99
>c5c301
>>
>635%7C0%7C0%7C636748323185939241sdata=LqCQNw1MYMUSzVhn
>Oj4H2deBPiQ
>> iFfrdiTXWCoRQj4c%3Dreserved=0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH] i2c: fix: Add support for the Arm's Versatile Express I2C controller

2018-10-10 Thread Heiko Schocher
accidentially while fixing merge errors for patch:
https://lists.denx.de/pipermail/u-boot/2018-September/342278.html

missed to add files:

MAINTAINERS
drivers/i2c/Kconfig
drivers/i2c/Makefile

add them with this patch.

Signed-off-by: Heiko Schocher 
---

 MAINTAINERS  | 1 +
 drivers/i2c/Kconfig  | 7 +++
 drivers/i2c/Makefile | 1 +
 3 files changed, 9 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index ace7d9a4b6..cc71a8f6be 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -453,6 +453,7 @@ M:  Liviu Dudau 
 S: Supported
 T: git git://github.com/ARM-software/u-boot.git
 F: drivers/video/mali_dp.c
+F: drivers/i2c/i2c-versatile.c
 
 MICROBLAZE
 M: Michal Simek 
diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig
index ae3b501555..1ef22e6bcd 100644
--- a/drivers/i2c/Kconfig
+++ b/drivers/i2c/Kconfig
@@ -416,6 +416,13 @@ config SYS_I2C_UNIPHIER_F
  Support for UniPhier FIFO-builtin I2C controller driver.
  This I2C controller is used on PH1-Pro4 or newer UniPhier SoCs.
 
+config SYS_I2C_VERSATILE
+   bool "Arm Ltd Versatile I2C bus driver"
+   depends on DM_I2C && (TARGET_VEXPRESS_CA15_TC2 || 
TARGET_VEXPRESS64_JUNO)
+   help
+ Add support for the Arm Ltd Versatile Express I2C driver. The I2C host
+ controller is present in the development boards manufactured by Arm 
Ltd.
+
 config SYS_I2C_MVTWSI
bool "Marvell I2C driver"
depends on DM_I2C
diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile
index f2cbe78c53..d3637bcd8d 100644
--- a/drivers/i2c/Makefile
+++ b/drivers/i2c/Makefile
@@ -36,6 +36,7 @@ obj-$(CONFIG_SYS_I2C_STM32F7) += stm32f7_i2c.o
 obj-$(CONFIG_SYS_I2C_TEGRA) += tegra_i2c.o
 obj-$(CONFIG_SYS_I2C_UNIPHIER) += i2c-uniphier.o
 obj-$(CONFIG_SYS_I2C_UNIPHIER_F) += i2c-uniphier-f.o
+obj-$(CONFIG_SYS_I2C_VERSATILE) += i2c-versatile.o
 obj-$(CONFIG_SYS_I2C_ZYNQ) += zynq_i2c.o
 obj-$(CONFIG_TEGRA186_BPMP_I2C) += tegra186_bpmp_i2c.o
 
-- 
2.14.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] net/phy: Add phy-id for IN112525_S03

2018-10-10 Thread Joe Hershberger
On Wed, Oct 10, 2018 at 11:47 PM Priyanka Jain  wrote:
>
> Signed-off-by: Priyanka Jain 
> ---
>  include/phy.h | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/include/phy.h b/include/phy.h
> index 52bf997..ef5ca7e 100644
> --- a/include/phy.h
> +++ b/include/phy.h
> @@ -315,5 +315,6 @@ static inline bool phy_interface_is_sgmii(struct 
> phy_device *phydev)
>  /* PHY UIDs for various PHYs that are referenced in external code */
>  #define PHY_UID_CS4340  0x13e51002
>  #define PHY_UID_TN2020 0x00a19410
> +#define PHY_UID_IN112525_S03   0x02107440

Why define it and not use it anywhere?

>
>  #endif
> --
> 1.9.1
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH] board/freescale/vid: Add vdd table for NXP LX2160A SoC

2018-10-10 Thread Priyanka Jain
Signed-off-by: Priyanka Jain 
---
 board/freescale/common/vid.c | 37 +
 1 file changed, 37 insertions(+)

diff --git a/board/freescale/common/vid.c b/board/freescale/common/vid.c
index eb5cf88..8d90135 100644
--- a/board/freescale/common/vid.c
+++ b/board/freescale/common/vid.c
@@ -379,6 +379,42 @@ int adjust_vdd(ulong vdd_override)
int ret, i2caddress;
unsigned long vdd_string_override;
char *vdd_string;
+#ifdef CONFIG_ARCH_LX2160A
+   static const u16 vdd[32] = {
+   8250,
+   7875,
+   7750,
+   0,  /* reserved */
+   0,  /* reserved */
+   0,  /* reserved */
+   0,  /* reserved */
+   0,  /* reserved */
+   0,  /* reserved */
+   0,  /* reserved */
+   0,  /* reserved */
+   0,  /* reserved */
+   0,  /* reserved */
+   0,  /* reserved */
+   0,  /* reserved */
+   0,  /* reserved */
+   8000,
+   8125,
+   8250,
+   0,  /* reserved */
+   8500,
+   0,  /* reserved */
+   0,  /* reserved */
+   0,  /* reserved */
+   0,  /* reserved */
+   0,  /* reserved */
+   0,  /* reserved */
+   0,  /* reserved */
+   0,  /* reserved */
+   0,  /* reserved */
+   0,  /* reserved */
+   0,  /* reserved */
+   };
+#else
 #ifdef CONFIG_ARCH_LS1088A
static const uint16_t vdd[32] = {
10250,
@@ -451,6 +487,7 @@ int adjust_vdd(ulong vdd_override)
0,  /* reserved */
};
 #endif
+#endif
struct vdd_drive {
u8 vid;
unsigned voltage;
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 01/27] dm: core: Allow uclass to set up a device's child after it is probed

2018-10-10 Thread Bin Meng
Hi Simon,

On Thu, Sep 27, 2018 at 9:42 PM Simon Glass  wrote:
>
> Hi Bin,
>
> On 23 September 2018 at 06:41, Bin Meng  wrote:
> > Some buses need to set up their child devices after they are probed.
> > Support a common child_post_probe() method for the uclass.
> >
> > With this change, the two APIs uclass_pre_probe_device() and
> > uclass_post_probe_device() become symmetric.
> >
> > Signed-off-by: Bin Meng 
> > ---
> >
> >  drivers/core/uclass.c | 13 -
> >  include/dm/uclass.h   |  4 +++-
> >  2 files changed, 15 insertions(+), 2 deletions(-)
>
> Another option, perhaps not quite as elegant, is for the driver to
> call into the uclass in its probe() method. We need to balance
> elegance with the cost of adding a new field to the uclass which is
> rarely used. What do you think?
>

Yes, we can use driver's probe() method to achieve the same goal, but
that seems a little bit duplicated effort for every driver. Also I
believe we should make uclass_pre_probe_device() and
uclass_post_probe_device() symmetric.

> Also, this does need some sort of use in sandbox, so can you update
> the test driver to use it?
>

Yes, will add in v2.

Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH] board/freescale/vid: Add correction for ltc3882 read error.

2018-10-10 Thread Priyanka Jain
Voltage regulator LTC3882 device has 0.5% voltage read error.
So for NXP SoC devices this generally equates to 2mV

Update set_voltage_to_LTC for below:
1.Add coorection of upto 2mV in voltage comparison
  to take care of voltage read error of voltage regulator
2.Add loop max count kept as 100 to avoid infinte loop.

Signed-off-by: Priyanka Jain 
---
 board/freescale/common/vid.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/board/freescale/common/vid.c b/board/freescale/common/vid.c
index eb5cf88..db158cb 100644
--- a/board/freescale/common/vid.c
+++ b/board/freescale/common/vid.c
@@ -318,6 +318,7 @@ static int set_voltage_to_IR(int i2caddress, int vdd)
 static int set_voltage_to_LTC(int i2caddress, int vdd)
 {
int ret, vdd_last, vdd_target = vdd;
+   int count = 100, temp = 0;
 
/* Scale up to the LTC resolution is 1/4096V */
vdd = (vdd * 4096) / 1000;
@@ -343,7 +344,9 @@ static int set_voltage_to_LTC(int i2caddress, int vdd)
printf("VID: Couldn't read sensor abort VID adjust\n");
return -1;
}
-   } while (vdd_last != vdd_target);
+   count--;
+   temp = vdd_last - vdd_target;
+   } while ((abs(temp) > 2)  && (count > 0));
 
return vdd_last;
 }
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v3 3/8] dm: util: Add a livetree equivalent API of dm_fdt_pre_reloc()

2018-10-10 Thread Bin Meng
This adds a new API dm_ofnode_pre_reloc(), a livetree equivalent
API of dm_fdt_pre_reloc().

Signed-off-by: Bin Meng 
Reviewed-by: Simon Glass 
---

Changes in v3: None
Changes in v2: None

 drivers/core/util.c | 25 +
 include/dm/util.h   | 27 ++-
 2 files changed, 51 insertions(+), 1 deletion(-)

diff --git a/drivers/core/util.c b/drivers/core/util.c
index 451d476..27a6848 100644
--- a/drivers/core/util.c
+++ b/drivers/core/util.c
@@ -4,6 +4,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -53,3 +54,27 @@ bool dm_fdt_pre_reloc(const void *blob, int offset)
 
return false;
 }
+
+bool dm_ofnode_pre_reloc(ofnode node)
+{
+   if (ofnode_read_bool(node, "u-boot,dm-pre-reloc"))
+   return true;
+
+#ifdef CONFIG_TPL_BUILD
+   if (ofnode_read_bool(node, "u-boot,dm-tpl"))
+   return true;
+#elif defined(CONFIG_SPL_BUILD)
+   if (ofnode_read_bool(node, "u-boot,dm-spl"))
+   return true;
+#else
+   /*
+* In regular builds individual spl and tpl handling both
+* count as handled pre-relocation for later second init.
+*/
+   if (ofnode_read_bool(node, "u-boot,dm-spl") ||
+   ofnode_read_bool(node, "u-boot,dm-tpl"))
+   return true;
+#endif
+
+   return false;
+}
diff --git a/include/dm/util.h b/include/dm/util.h
index 898822e..9ff6531 100644
--- a/include/dm/util.h
+++ b/include/dm/util.h
@@ -55,7 +55,7 @@ static inline void dm_dump_devres(void)
  * There are 3 settings currently in use
  * -
  * - u-boot,dm-pre-reloc: legacy and indicates any of TPL or SPL
- *   Existing platforms only use it to indicate nodes needee in
+ *   Existing platforms only use it to indicate nodes needed in
  *   SPL. Should probably be replaced by u-boot,dm-spl for
  *   existing platforms.
  * @blob: devicetree
@@ -65,4 +65,29 @@ static inline void dm_dump_devres(void)
  */
 bool dm_fdt_pre_reloc(const void *blob, int offset);
 
+/**
+ * Check if an of node should be or was bound before relocation.
+ *
+ * Devicetree nodes can be marked as needed to be bound
+ * in the loader stages via special devicetree properties.
+ *
+ * Before relocation this function can be used to check if nodes
+ * are required in either SPL or TPL stages.
+ *
+ * After relocation and jumping into the real U-Boot binary
+ * it is possible to determine if a node was bound in one of
+ * SPL/TPL stages.
+ *
+ * There are 3 settings currently in use
+ * -
+ * - u-boot,dm-pre-reloc: legacy and indicates any of TPL or SPL
+ *   Existing platforms only use it to indicate nodes needed in
+ *   SPL. Should probably be replaced by u-boot,dm-spl for
+ *   existing platforms.
+ * @node: of node
+ *
+ * Returns true if node is needed in SPL/TL, false otherwise.
+ */
+bool dm_ofnode_pre_reloc(ofnode node);
+
 #endif
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v3 4/8] dm: core: Respect drivers with the DM_FLAG_PRE_RELOC flag in lists_bind_fdt()

2018-10-10 Thread Bin Meng
Currently the comments of several APIs (eg: dm_init_and_scan()) say:

@pre_reloc_only: If true, bind only drivers with the DM_FLAG_PRE_RELOC
flag. If false bind all drivers.

The 'Pre-Relocation Support' chapter in doc/driver-model/README.txt
documents the same that both device tree properties and driver flag
are supported.

However the implementation only checks these special device tree
properties without checking the driver flag at all. This updates
lists_bind_fdt() to consider both scenarios.

Signed-off-by: Bin Meng 
Reviewed-by: Simon Glass 

---

Changes in v3: None
Changes in v2:
- rebase on u-boot/master, and fix one build error

 drivers/core/device.c  |  2 +-
 drivers/core/lists.c   |  9 -
 drivers/core/root.c| 12 
 drivers/serial/serial-uclass.c |  2 +-
 drivers/timer/timer-uclass.c   |  2 +-
 include/dm/lists.h |  5 -
 6 files changed, 19 insertions(+), 13 deletions(-)

diff --git a/drivers/core/device.c b/drivers/core/device.c
index feed43c..1451689 100644
--- a/drivers/core/device.c
+++ b/drivers/core/device.c
@@ -815,5 +815,5 @@ int dev_enable_by_path(const char *path)
if (ret)
return ret;
 
-   return lists_bind_fdt(parent, node, NULL);
+   return lists_bind_fdt(parent, node, NULL, false);
 }
diff --git a/drivers/core/lists.c b/drivers/core/lists.c
index a167726..a1f8284 100644
--- a/drivers/core/lists.c
+++ b/drivers/core/lists.c
@@ -122,7 +122,8 @@ static int driver_check_compatible(const struct udevice_id 
*of_match,
return -ENOENT;
 }
 
-int lists_bind_fdt(struct udevice *parent, ofnode node, struct udevice **devp)
+int lists_bind_fdt(struct udevice *parent, ofnode node, struct udevice **devp,
+  bool pre_reloc_only)
 {
struct driver *driver = ll_entry_start(struct driver, driver);
const int n_ents = ll_entry_count(struct driver, driver);
@@ -171,6 +172,12 @@ int lists_bind_fdt(struct udevice *parent, ofnode node, 
struct udevice **devp)
if (entry == driver + n_ents)
continue;
 
+   if (pre_reloc_only) {
+   if (!dm_ofnode_pre_reloc(node) &&
+   !(entry->flags & DM_FLAG_PRE_RELOC))
+   return 0;
+   }
+
pr_debug("   - found match at '%s'\n", entry->name);
ret = device_bind_with_driver_data(parent, entry, name,
   id->data, node, );
diff --git a/drivers/core/root.c b/drivers/core/root.c
index b54bf5b..cd6a5a0 100644
--- a/drivers/core/root.c
+++ b/drivers/core/root.c
@@ -222,14 +222,12 @@ static int dm_scan_fdt_live(struct udevice *parent,
int ret = 0, err;
 
for (np = node_parent->child; np; np = np->sibling) {
-   if (pre_reloc_only &&
-   !of_find_property(np, "u-boot,dm-pre-reloc", NULL))
-   continue;
if (!of_device_is_available(np)) {
pr_debug("   - ignoring disabled device\n");
continue;
}
-   err = lists_bind_fdt(parent, np_to_ofnode(np), NULL);
+   err = lists_bind_fdt(parent, np_to_ofnode(np), NULL,
+pre_reloc_only);
if (err && !ret) {
ret = err;
debug("%s: ret=%d\n", np->name, ret);
@@ -282,14 +280,12 @@ static int dm_scan_fdt_node(struct udevice *parent, const 
void *blob,
continue;
}
 
-   if (pre_reloc_only &&
-   !dm_fdt_pre_reloc(blob, offset))
-   continue;
if (!fdtdec_get_is_enabled(blob, offset)) {
pr_debug("   - ignoring disabled device\n");
continue;
}
-   err = lists_bind_fdt(parent, offset_to_ofnode(offset), NULL);
+   err = lists_bind_fdt(parent, offset_to_ofnode(offset), NULL,
+pre_reloc_only);
if (err && !ret) {
ret = err;
debug("%s: ret=%d\n", node_name, ret);
diff --git a/drivers/serial/serial-uclass.c b/drivers/serial/serial-uclass.c
index ffdcae0..cc11474 100644
--- a/drivers/serial/serial-uclass.c
+++ b/drivers/serial/serial-uclass.c
@@ -61,7 +61,7 @@ static int serial_check_stdout(const void *blob, struct 
udevice **devp)
 * anyway.
 */
if (node > 0 && !lists_bind_fdt(gd->dm_root, offset_to_ofnode(node),
-   devp)) {
+   devp, false)) {
if (!device_probe(*devp))
return 0;
}
diff --git a/drivers/timer/timer-uclass.c b/drivers/timer/timer-uclass.c
index fe73f71..12ee6eb 100644
--- a/drivers/timer/timer-uclass.c
+++ 

[U-Boot] [PATCH v3 7/8] test: dm: core: Add a test case for driver marked with DM_FLAG_PRE_RELOC flag

2018-10-10 Thread Bin Meng
Now that we fixed the pre-relocation driver binding for driver marked
with DM_FLAG_PRE_RELOC flag, add a test case to cover that scenario.

Signed-off-by: Bin Meng 
Reviewed-by: Simon Glass 
---

Changes in v3: None
Changes in v2: None

 arch/sandbox/dts/test.dts |  4 
 test/dm/bus.c |  2 +-
 test/dm/test-fdt.c| 29 ++---
 3 files changed, 31 insertions(+), 4 deletions(-)

diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index ad94901..2097ec4 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -146,6 +146,10 @@
compatible = "denx,u-boot-fdt-test";
};
 
+   h-test {
+   compatible = "denx,u-boot-fdt-test1";
+   };
+
clocks {
clk_fixed: clk-fixed {
compatible = "fixed-clock";
diff --git a/test/dm/bus.c b/test/dm/bus.c
index e9a4028..c41bcf7 100644
--- a/test/dm/bus.c
+++ b/test/dm/bus.c
@@ -104,7 +104,7 @@ UCLASS_DRIVER(testbus) = {
 /* Test that we can probe for children */
 static int dm_test_bus_children(struct unit_test_state *uts)
 {
-   int num_devices = 7;
+   int num_devices = 8;
struct udevice *bus;
struct uclass *uc;
 
diff --git a/test/dm/test-fdt.c b/test/dm/test-fdt.c
index 79b1f1d..3da384f 100644
--- a/test/dm/test-fdt.c
+++ b/test/dm/test-fdt.c
@@ -84,6 +84,25 @@ U_BOOT_DRIVER(testfdt_drv) = {
.platdata_auto_alloc_size = sizeof(struct dm_test_pdata),
 };
 
+static const struct udevice_id testfdt1_ids[] = {
+   {
+   .compatible = "denx,u-boot-fdt-test1",
+   .data = DM_TEST_TYPE_FIRST },
+   { }
+};
+
+U_BOOT_DRIVER(testfdt1_drv) = {
+   .name   = "testfdt1_drv",
+   .of_match   = testfdt1_ids,
+   .id = UCLASS_TEST_FDT,
+   .ofdata_to_platdata = testfdt_ofdata_to_platdata,
+   .probe  = testfdt_drv_probe,
+   .ops= _ops,
+   .priv_auto_alloc_size = sizeof(struct dm_test_priv),
+   .platdata_auto_alloc_size = sizeof(struct dm_test_pdata),
+   .flags = DM_FLAG_PRE_RELOC,
+};
+
 /* From here is the testfdt uclass code */
 int testfdt_ping(struct udevice *dev, int pingval, int *pingret)
 {
@@ -168,7 +187,7 @@ int dm_check_devices(struct unit_test_state *uts, int 
num_devices)
 /* Test that FDT-based binding works correctly */
 static int dm_test_fdt(struct unit_test_state *uts)
 {
-   const int num_devices = 7;
+   const int num_devices = 8;
struct udevice *dev;
struct uclass *uc;
int ret;
@@ -208,8 +227,12 @@ static int dm_test_fdt_pre_reloc(struct unit_test_state 
*uts)
ret = uclass_get(UCLASS_TEST_FDT, );
ut_assert(!ret);
 
-   /* These is only one pre-reloc device */
-   ut_asserteq(1, list_count_items(>dev_head));
+   /*
+* These are 2 pre-reloc devices:
+* one with "u-boot,dm-pre-reloc" property (a-test node), and the other
+* one whose driver marked with DM_FLAG_PRE_RELOC flag (h-test node).
+*/
+   ut_asserteq(2, list_count_items(>dev_head));
 
return 0;
 }
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v3 8/8] timer: Sort Kconfig driver entries

2018-10-10 Thread Bin Meng
This is currently out of order. Sort it.

Signed-off-by: Bin Meng 
Reviewed-by: Simon Glass 

---

Changes in v3:
- rebase on u-boot/master so that patch [4/8] can be applied cleanly

Changes in v2: None

 drivers/timer/Kconfig | 110 +-
 1 file changed, 55 insertions(+), 55 deletions(-)

diff --git a/drivers/timer/Kconfig b/drivers/timer/Kconfig
index a7d600b..8c0f356 100644
--- a/drivers/timer/Kconfig
+++ b/drivers/timer/Kconfig
@@ -37,6 +37,12 @@ config TIMER_EARLY
  use an early timer. These functions must be supported by your timer
  driver: timer_early_get_count() and timer_early_get_rate().
 
+config AG101P_TIMER
+   bool "AG101P timer support"
+   depends on TIMER && NDS32
+   help
+ Select this to enable a timer for AG01P devices.
+
 config ALTERA_TIMER
bool "Altera timer support"
depends on TIMER
@@ -44,6 +50,34 @@ config ALTERA_TIMER
  Select this to enable a timer for Altera devices. Please find
  details on the "Embedded Peripherals IP User Guide" of Altera.
 
+config ARC_TIMER
+   bool "ARC timer support"
+   depends on TIMER && ARC && CLK
+   help
+ Select this to enable built-in ARC timers.
+ ARC cores may have up to 2 built-in timers: timer0 and timer1,
+ usually at least one of them exists. Either of them is supported
+ in U-Boot.
+
+config AST_TIMER
+   bool "Aspeed ast2400/ast2500 timer support"
+   depends on TIMER
+   default y if ARCH_ASPEED
+   help
+ Select this to enable timer for Aspeed ast2400/ast2500 devices.
+ This is a simple sys timer driver, it is compatible with lib/time.c,
+ but does not support any interrupts. Even though SoC has 8 hardware
+ counters, they are all treated as a single device by this driver.
+ This is mostly because they all share several registers which
+ makes it difficult to completely separate them.
+
+config ATCPIT100_TIMER
+   bool "ATCPIT100 timer support"
+   depends on TIMER
+   help
+ Select this to enable a ATCPIT100 timer which will be embedded
+ in AE3XX, AE250 boards.
+
 config ATMEL_PIT_TIMER
bool "Atmel periodic interval timer support"
depends on TIMER
@@ -66,18 +100,12 @@ config DESIGNWARE_APB_TIMER
  Enables support for the Designware APB Timer driver. This timer is
  present on Altera SoCFPGA SoCs.
 
-config SANDBOX_TIMER
-   bool "Sandbox timer support"
-   depends on SANDBOX && TIMER
-   help
- Select this to enable an emulated timer for sandbox. It gets
- time from host os.
-
-config X86_TSC_TIMER
-   bool "x86 Time-Stamp Counter (TSC) timer support"
-   depends on TIMER && X86
+config MPC83XX_TIMER
+   bool "MPC83xx timer support"
+   depends on TIMER
help
- Select this to enable Time-Stamp Counter (TSC) timer for x86.
+ Select this to enable support for the timer found on
+ devices based on the MPC83xx family of SoCs.
 
 config OMAP_TIMER
bool "Omap timer support"
@@ -85,17 +113,19 @@ config OMAP_TIMER
help
  Select this to enable an timer for Omap devices.
 
-config AST_TIMER
-   bool "Aspeed ast2400/ast2500 timer support"
+config ROCKCHIP_TIMER
+   bool "Rockchip timer support"
depends on TIMER
-   default y if ARCH_ASPEED
help
- Select this to enable timer for Aspeed ast2400/ast2500 devices.
- This is a simple sys timer driver, it is compatible with lib/time.c,
- but does not support any interrupts. Even though SoC has 8 hardware
- counters, they are all treated as a single device by this driver.
- This is mostly because they all share several registers which
- makes it difficult to completely separate them.
+ Select this to enable support for the timer found on
+ Rockchip devices.
+
+config SANDBOX_TIMER
+   bool "Sandbox timer support"
+   depends on SANDBOX && TIMER
+   help
+ Select this to enable an emulated timer for sandbox. It gets
+ time from host os.
 
 config STI_TIMER
bool "STi timer support"
@@ -104,47 +134,17 @@ config STI_TIMER
help
  Select this to enable a timer for STi devices.
 
-config ARC_TIMER
-   bool "ARC timer support"
-   depends on TIMER && ARC && CLK
-   help
- Select this to enable built-in ARC timers.
- ARC cores may have up to 2 built-in timers: timer0 and timer1,
- usually at least one of them exists. Either of them is supported
- in U-Boot.
-
-config AG101P_TIMER
-   bool "AG101P timer support"
-   depends on TIMER && NDS32
-   help
- Select this to enable a timer for AG01P devices.
-
-config ATCPIT100_TIMER
-   bool "ATCPIT100 timer support"
-   depends on TIMER
-   help
- Select this to enable 

[U-Boot] [PATCH v3 5/8] dm: Correct pre_reloc_only parameter description in several APIs' comments

2018-10-10 Thread Bin Meng
The pre_reloc_only parameter description currently only mentions
drivers with the DM_FLAG_PRE_RELOC flag, but does not mention the
special device tree properties. Correct them.

Signed-off-by: Bin Meng 
Reviewed-by: Simon Glass 
---

Changes in v3: None
Changes in v2: None

 include/dm/device-internal.h |  4 ++--
 include/dm/lists.h   |  4 ++--
 include/dm/root.h| 17 +
 3 files changed, 13 insertions(+), 12 deletions(-)

diff --git a/include/dm/device-internal.h b/include/dm/device-internal.h
index 02ac4c7..ee2b24a 100644
--- a/include/dm/device-internal.h
+++ b/include/dm/device-internal.h
@@ -74,8 +74,8 @@ int device_bind_with_driver_data(struct udevice *parent,
  * tree.
  *
  * @parent: Pointer to device's parent
- * @pre_reloc_only: If true, bind the driver only if its DM_INIT_F flag is set.
- * If false bind the driver always.
+ * @pre_reloc_only: If true, bind the driver only if its DM_FLAG_PRE_RELOC flag
+ * is set. If false bind the driver always.
  * @info: Name and platdata for this device
  * @devp: if non-NULL, returns a pointer to the bound device
  * @return 0 if OK, -ve on error
diff --git a/include/dm/lists.h b/include/dm/lists.h
index 59094d7..810e244 100644
--- a/include/dm/lists.h
+++ b/include/dm/lists.h
@@ -39,8 +39,8 @@ struct uclass_driver *lists_uclass_lookup(enum uclass_id id);
  * each one. The devices will have @parent as their parent.
  *
  * @parent: parent device (root)
- * @early_only: If true, bind only drivers with the DM_INIT_F flag. If false
- * bind all drivers.
+ * @pre_reloc_only: If true, bind only drivers with the DM_FLAG_PRE_RELOC flag.
+ * If false bind all drivers.
  */
 int lists_bind_drivers(struct udevice *parent, bool pre_reloc_only);
 
diff --git a/include/dm/root.h b/include/dm/root.h
index 2b9c6da..c8d629b 100644
--- a/include/dm/root.h
+++ b/include/dm/root.h
@@ -48,8 +48,8 @@ int dm_scan_platdata(bool pre_reloc_only);
  * the top-level subnodes are examined.
  *
  * @blob: Pointer to device tree blob
- * @pre_reloc_only: If true, bind only drivers with the DM_FLAG_PRE_RELOC
- * flag. If false bind all drivers.
+ * @pre_reloc_only: If true, bind only nodes with special devicetree 
properties,
+ * or drivers with the DM_FLAG_PRE_RELOC flag. If false bind all drivers.
  * @return 0 if OK, -ve on error
  */
 int dm_scan_fdt(const void *blob, bool pre_reloc_only);
@@ -62,8 +62,8 @@ int dm_scan_fdt(const void *blob, bool pre_reloc_only);
  * of "clocks" node.
  *
  * @blob: Pointer to device tree blob
- * @pre_reloc_only: If true, bind only drivers with the DM_FLAG_PRE_RELOC
- * flag. If false bind all drivers.
+ * @pre_reloc_only: If true, bind only nodes with special devicetree 
properties,
+ * or drivers with the DM_FLAG_PRE_RELOC flag. If false bind all drivers.
  * @return 0 if OK, -ve on error
  */
 int dm_extended_scan_fdt(const void *blob, bool pre_reloc_only);
@@ -76,8 +76,9 @@ int dm_extended_scan_fdt(const void *blob, bool 
pre_reloc_only);
  * programmaticaly. They should do this by calling device_bind() on each
  * device.
  *
- * @pre_reloc_only: If true, bind only drivers with the DM_FLAG_PRE_RELOC
- * flag. If false bind all drivers.
+ * @pre_reloc_only: If true, bind only nodes with special devicetree 
properties,
+ * or drivers with the DM_FLAG_PRE_RELOC flag. If false bind all drivers.
+ * @return 0 if OK, -ve on error
  */
 int dm_scan_other(bool pre_reloc_only);
 
@@ -88,8 +89,8 @@ int dm_scan_other(bool pre_reloc_only);
  * then scans and binds available devices from platform data and the FDT.
  * This calls dm_init() to set up Driver Model structures.
  *
- * @pre_reloc_only: If true, bind only drivers with the DM_FLAG_PRE_RELOC
- * flag. If false bind all drivers.
+ * @pre_reloc_only: If true, bind only nodes with special devicetree 
properties,
+ * or drivers with the DM_FLAG_PRE_RELOC flag. If false bind all drivers.
  * @return 0 if OK, -ve on error
  */
 int dm_init_and_scan(bool pre_reloc_only);
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v3 6/8] dm: core: Mirror the chosen node parse logic in the livetree scanning

2018-10-10 Thread Bin Meng
Commit f2006808f099: ("dm: core: parse chosen node") added a logic
to parse the chosen node during dm_scan_fdt_node(), but unfortunately
it missed adding the same logic in dm_scan_fdt_live(). This mirrors
the logic in the livetree version.

The weird thing is that commit f2006808f099 did update the test case
to test such logic, but even if I reset to that commit, the test case
still fails, and I have no idea how it could pass.

With this fix, the following 2 test cases now pass:

Test: dm_test_bus_children: bus.c
test/dm/bus.c:112, dm_test_bus_children(): num_devices ==
list_count_items(>dev_head): Expected 7, got 6

Test: dm_test_fdt: test-fdt.c
test/dm/test-fdt.c:184, dm_test_fdt(): num_devices ==
list_count_items(>dev_head): Expected 7, got 6

Fixes: f2006808f099 ("dm: core: parse chosen node")
Signed-off-by: Bin Meng 
Reviewed-by: Simon Glass 
---

Changes in v3: None
Changes in v2: None

 drivers/core/root.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/core/root.c b/drivers/core/root.c
index cd6a5a0..4ce55f9 100644
--- a/drivers/core/root.c
+++ b/drivers/core/root.c
@@ -222,6 +222,16 @@ static int dm_scan_fdt_live(struct udevice *parent,
int ret = 0, err;
 
for (np = node_parent->child; np; np = np->sibling) {
+   /* "chosen" node isn't a device itself but may contain some: */
+   if (!strcmp(np->name, "chosen")) {
+   pr_debug("parsing subnodes of \"chosen\"\n");
+
+   err = dm_scan_fdt_live(parent, np, pre_reloc_only);
+   if (err && !ret)
+   ret = err;
+   continue;
+   }
+
if (!of_device_is_available(np)) {
pr_debug("   - ignoring disabled device\n");
continue;
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v3 1/8] dm: cpu: Fix print_cpuinfo() output

2018-10-10 Thread Bin Meng
It was observed that current output of print_cpuinfo() on QEMU
x86 targets does not have an ending '\n', neither have a leading
'CPU:' any more. However it used to have these before.

It turns out commit c0434407b595 introduced a unified DM version
of print_cpuinfo() that exposed such issue on QEMU x86.

Fixes: c0434407b595 ("board_f: Use static print_cpuinfo if CONFIG_CPU is 
active")
Signed-off-by: Bin Meng 
Reviewed-by: Simon Glass 
---

Changes in v3: None
Changes in v2: None

 common/board_f.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/common/board_f.c b/common/board_f.c
index 213d044..96503ff 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -187,7 +187,7 @@ static int print_cpuinfo(void)
return ret;
}
 
-   printf("%s", desc);
+   printf("CPU:   %s\n", desc);
 
return 0;
 }
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v3 2/8] cpu: mpc83xx: Remove unnecessary characters in the description string

2018-10-10 Thread Bin Meng
The description string should not contain unnecessary characters,
like the ending '\n' or the leading 'CPU:'.

Signed-off-by: Bin Meng 
Reviewed-by: Simon Glass 
---

Changes in v3: None
Changes in v2: None

 drivers/cpu/mpc83xx_cpu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/cpu/mpc83xx_cpu.c b/drivers/cpu/mpc83xx_cpu.c
index 31717af..7bc86bf 100644
--- a/drivers/cpu/mpc83xx_cpu.c
+++ b/drivers/cpu/mpc83xx_cpu.c
@@ -262,7 +262,7 @@ static int mpc83xx_cpu_get_desc(struct udevice *dev, char 
*buf, int size)
determine_cpu_data(dev);
 
snprintf(buf, size,
-"CPU:   %s, MPC%s%s%s, Rev: %d.%d at %s MHz, CSB: %s MHz\n",
+"%s, MPC%s%s%s, Rev: %d.%d at %s MHz, CSB: %s MHz",
 e300_names[priv->e300_type],
 cpu_type_names[priv->type],
 priv->is_e_processor ? "E" : "",
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v3 0/8] dm: Various fixes in dm core/cpu/timer

2018-10-10 Thread Bin Meng
This fixed several issues identified in dm core/cpu/timer codes.

The issues were found during RISC-V cpu/timer driver development
for QEMU RISC-V port.

This series is available at u-boot-x86/dm-fixes for testing.

Changes in v3:
- rebase on u-boot/master so that patch [4/8] can be applied cleanly

Changes in v2:
- rebase on u-boot/master, and fix one build error

Bin Meng (8):
  dm: cpu: Fix print_cpuinfo() output
  cpu: mpc83xx: Remove unnecessary characters in the description string
  dm: util: Add a livetree equivalent API of dm_fdt_pre_reloc()
  dm: core: Respect drivers with the DM_FLAG_PRE_RELOC flag in
lists_bind_fdt()
  dm: Correct pre_reloc_only parameter description in several APIs'
comments
  dm: core: Mirror the chosen node parse logic in the livetree scanning
  test: dm: core: Add a test case for driver marked with
DM_FLAG_PRE_RELOC flag
  timer: Sort Kconfig driver entries

 arch/sandbox/dts/test.dts  |   4 ++
 common/board_f.c   |   2 +-
 drivers/core/device.c  |   2 +-
 drivers/core/lists.c   |   9 +++-
 drivers/core/root.c|  20 +---
 drivers/core/util.c|  25 ++
 drivers/cpu/mpc83xx_cpu.c  |   2 +-
 drivers/serial/serial-uclass.c |   2 +-
 drivers/timer/Kconfig  | 110 -
 drivers/timer/timer-uclass.c   |   2 +-
 include/dm/device-internal.h   |   4 +-
 include/dm/lists.h |   9 ++--
 include/dm/root.h  |  17 ---
 include/dm/util.h  |  27 +-
 test/dm/bus.c  |   2 +-
 test/dm/test-fdt.c |  29 +--
 16 files changed, 180 insertions(+), 86 deletions(-)

-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH] net/phy: Add phy-id for IN112525_S03

2018-10-10 Thread Priyanka Jain
Signed-off-by: Priyanka Jain 
---
 include/phy.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/phy.h b/include/phy.h
index 52bf997..ef5ca7e 100644
--- a/include/phy.h
+++ b/include/phy.h
@@ -315,5 +315,6 @@ static inline bool phy_interface_is_sgmii(struct phy_device 
*phydev)
 /* PHY UIDs for various PHYs that are referenced in external code */
 #define PHY_UID_CS4340  0x13e51002
 #define PHY_UID_TN2020 0x00a19410
+#define PHY_UID_IN112525_S03   0x02107440
 
 #endif
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 1/1] cmd: add el command

2018-10-10 Thread Heinrich Schuchardt
The 'el' command displays the current exception level of the processor
on the aarch64 architecture.

This information is needed to analyze problems in the EFI subsystem.

Signed-off-by: Heinrich Schuchardt 
---
 cmd/Kconfig  |  7 +++
 cmd/Makefile |  1 +
 cmd/el.c | 25 +
 3 files changed, 33 insertions(+)
 create mode 100644 cmd/el.c

diff --git a/cmd/Kconfig b/cmd/Kconfig
index 7ed3c9c3b3..cfad07432e 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -1373,6 +1373,13 @@ config CMD_DISPLAY
  displayed on a simple board-specific display. Implement
  display_putc() to use it.
 
+config CMD_EL
+   bool "el - display processor exception level"
+   depends on ARM64
+   help
+ Enable the 'el' command which displays the exception level of the
+ processor.
+
 config CMD_LED
bool "led"
default y if LED
diff --git a/cmd/Makefile b/cmd/Makefile
index d9cdaf6064..63e3afd56b 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -47,6 +47,7 @@ endif
 obj-$(CONFIG_CMD_DISPLAY) += display.o
 obj-$(CONFIG_CMD_DTIMG) += dtimg.o
 obj-$(CONFIG_CMD_ECHO) += echo.o
+obj-$(CONFIG_CMD_EL) += el.o
 obj-$(CONFIG_ENV_IS_IN_EEPROM) += eeprom.o
 obj-$(CONFIG_CMD_EEPROM) += eeprom.o
 obj-$(CONFIG_EFI_STUB) += efi.o
diff --git a/cmd/el.c b/cmd/el.c
new file mode 100644
index 00..57081c36f2
--- /dev/null
+++ b/cmd/el.c
@@ -0,0 +1,25 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * The 'el' command prints the current exception level
+ *
+ * Copyright (c) 2018, Heinrich Schuchardt 
+ */
+#include 
+#include 
+#include 
+
+static int do_el(cmd_tbl_t *cmdtp, int flag, int argc,
+char * const argv[])
+{
+   printf("processor exception level: EL%d\n", current_el());
+   return CMD_RET_SUCCESS;
+}
+
+#ifdef CONFIG_SYS_LONGHELP
+static char el_help_text[] = "";
+#endif
+
+U_BOOT_CMD_COMPLETE
+   (el, 2, 0, do_el,
+"display processor exception level",
+el_help_text, NULL);
-- 
2.19.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 1/1] efi_loader: PSCI reset and shutdown for EL1

2018-10-10 Thread Heinrich Schuchardt
When starting an aarch64 system under QEMU it runs in EL1/EL0. So we have
to use HVC for PSCI calls.

Without the patch resetting Linux started with bootefi under
qemu-system-aarch64 results in a crash.

Signed-off-by: Heinrich Schuchardt 
---
 arch/arm/cpu/armv8/fwcall.c | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/arch/arm/cpu/armv8/fwcall.c b/arch/arm/cpu/armv8/fwcall.c
index 0ba3dad8cc..f1b6e60bae 100644
--- a/arch/arm/cpu/armv8/fwcall.c
+++ b/arch/arm/cpu/armv8/fwcall.c
@@ -78,12 +78,10 @@ void __efi_runtime smc_call(struct pt_regs *args)
 }
 
 /*
- * For now, all systems we support run at least in EL2 and thus
- * trigger PSCI calls to EL3 using SMC. If anyone ever wants to
- * use PSCI on U-Boot running below a hypervisor, please detect
- * this and set the flag accordingly.
+ * This flag controls if SMC or HVC is used to call PSCI services. If U-Boot 
has
+ * been called by a hypervisor (e.g. QEMU), it has to be set to false.
  */
-static const __efi_runtime_data bool use_smc_for_psci = true;
+static __efi_runtime_data bool use_smc_for_psci = true;
 
 void __noreturn __efi_runtime psci_system_reset(void)
 {
@@ -138,6 +136,12 @@ void reset_misc(void)
 }
 
 #ifdef CONFIG_EFI_LOADER
+efi_status_t efi_reset_system_init(void)
+{
+   use_smc_for_psci = (current_el() >= 2);
+   return EFI_SUCCESS;
+}
+
 void __efi_runtime EFIAPI efi_reset_system(
enum efi_reset_type reset_type,
efi_status_t reset_status,
-- 
2.19.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 4/4] test: Add test for PCI device without compat string and with DT node

2018-10-10 Thread Bin Meng
On Thu, Oct 11, 2018 at 3:29 AM Marek Vasut  wrote:
>
> Add test which checks if a PCI device described in DT with an
> entry and reg = <...> property, but without compatible string
> results in a valid U-Boot PCI udevice with the udevice.node
> populated with reference to this DT node. Also check if the
> other PCI device without a DT node does not contain any bogus
> udevice.node.
>
> Signed-off-by: Marek Vasut 
> Cc: Simon Glass 
> Cc: Tom Rini 
> ---
>  test/dm/pci.c | 5 +
>  1 file changed, 5 insertions(+)
>

Reviewed-by: Bin Meng 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 2/4] pci: Update documentation to make 'compatible' string optional

2018-10-10 Thread Bin Meng
Hi Marek,

On Thu, Oct 11, 2018 at 3:28 AM Marek Vasut  wrote:
>
> Reword the documentation to make it clear the compatible string is now
> optional, yet still matching on it takes precedence over PCI IDs and
> PCI classes.
>
> Signed-off-by: Marek Vasut 
> Cc: Simon Glass 
> Cc: Tom Rini 
> ---
>  doc/driver-model/pci-info.txt | 14 +-
>  1 file changed, 9 insertions(+), 5 deletions(-)
>

Reviewed-by: Bin Meng 

I think I provided my RB tag to previous version, and if there is no
changes, I would appreciate it the RB tag was added in the new version
to save some time.

> diff --git a/doc/driver-model/pci-info.txt b/doc/driver-model/pci-info.txt
> index e1701d1fbc..14364c5c75 100644
> --- a/doc/driver-model/pci-info.txt
> +++ b/doc/driver-model/pci-info.txt
> @@ -34,11 +34,15 @@ under that bus.
>  Note that this is all done on a lazy basis, as needed, so until something is
>  touched on PCI (eg: a call to pci_find_devices()) it will not be probed.
>
> -PCI devices can appear in the flattened device tree. If they do this serves 
> to
> -specify the driver to use for the device. In this case they will be bound at
> -first. Each PCI device node must have a compatible string list as well as a
> - property, as defined by the IEEE Std 1275-1994 PCI bus binding document
> -v2.1. Note we must describe PCI devices with the same bus hierarchy as the
> +PCI devices can appear in the flattened device tree. If they do, their node
> +often contains extra information which cannot be derived from the PCI IDs or
> +PCI class of the device. Each PCI device node must have a  property, as
> +defined by the IEEE Std 1275-1994 PCI bus binding document v2.1. Compatible
> +string list is optional and generally not needed, since PCI is discoverable
> +bus, albeit there are justified exceptions. If the compatible string is
> +present, matching on it takes precedence over PCI IDs and PCI classes.
> +
> +Note we must describe PCI devices with the same bus hierarchy as the
>  hardware, otherwise driver model cannot detect the correct parent/children
>  relationship during PCI bus enumeration thus PCI devices won't be bound to
>  their drivers accordingly. A working example like below:
> --

Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 3/4] test: Add PCI device entry without compat string and with DT node

2018-10-10 Thread Bin Meng
On Thu, Oct 11, 2018 at 3:28 AM Marek Vasut  wrote:
>
> Add PCI entry without compatible string and with a DT node only with
> reg = <...> property into the DT. This is needed for the tests to
> verify whether such a setup creates an U-Boot PCI device with the
> DT node associated with it in udevice.node.
>
> Signed-off-by: Marek Vasut 
> Cc: Simon Glass 
> Cc: Tom Rini 
> ---
>  arch/sandbox/dts/test.dts | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>

Reviewed-by: Bin Meng 

nits: I believe this can be squashed to patch [4/4] to make it a
complete test case update.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 1/4] pci: Support parsing PCI controller DT subnodes

2018-10-10 Thread Bin Meng
On Thu, Oct 11, 2018 at 3:27 AM Marek Vasut  wrote:
>
> The PCI controller can have DT subnodes describing extra properties
> of particular PCI devices, ie. a PHY attached to an EHCI controller
> on a PCI bus. This patch parses those DT subnodes and assigns a node
> to the PCI device instance, so that the driver can extract details
> from that node and ie. configure the PHY using the PHY subsystem.
>
> Signed-off-by: Marek Vasut 
> Cc: Simon Glass 
> Cc: Tom Rini 
> ---
> V2: Use ofnode_read_pci_addr() instead of ofnode_get_addr_size()
> ---
>  drivers/pci/pci-uclass.c | 32 +---
>  1 file changed, 29 insertions(+), 3 deletions(-)
>

Reviewed-by: Bin Meng 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v2 18/19] drivers: core: nullify gd->dm_root after dm_uninit()

2018-10-10 Thread Simon Glass
On 5 October 2018 at 10:45, Jean-Jacques Hiblot  wrote:
> To reset the DM after a new dtb is loaded, we need to call dm_uninit()
> and then dm_init(). This fails however because gd->dm_root is not nullified
> by dm_uninit().
> Fixing it by setting gd->dm_root in dm_uninit().
>
> Signed-off-by: Jean-Jacques Hiblot 
> ---
>
> Changes in v2: None
>
>  drivers/core/root.c | 1 +
>  1 file changed, 1 insertion(+)

Reviewed-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] image-fdt: reserve lmb for fdt

2018-10-10 Thread Simon Glass
On 10 October 2018 at 00:28, Andy Yan  wrote:
> Hi Simon:
>
> Simon Glass  于2018年8月30日周四 上午8:42写道:
>>
>> On 7 August 2018 at 05:44, Andy Yan  wrote:
>> > Memory region for fdt should be reserved, or they
>> > may be allocated by other module via lmb_alloc.
>> > Then the fdt data will be destroy.
>> >
>> > We found a case on a board with 64MB DRAM like bellow:
>> >
>> > No ethernet found.
>> > Hit any key to stop autoboot:  0
>> > ANDROID: reboot reason: "recovery"
>> > FDT load addr 0x10f0 size 41 KiB
>> > Booting kernel at 0x2008000 with fdt at 2c8ac00...
>> >
>> > lmb_add base:0x58000 size:0x3fa8000
>> > lmb_add base:0x0 size:0x0
>> > lmb_reserve base:0x34ca2a0 size:0xb35d60
>> >   Booting Android Image at 0x02008000 ...
>> > Kernel load addr 0x02008800 size 3808 KiB
>> > RAM disk load addr 0x1100 size 9000 KiB
>> > *  fdt: cmdline image address = 0x02c8ac00
>> >   Checking for 'FDT'/'FDT Image' at 02c8ac00
>> > *  fdt: raw FDT blob
>> >Flattened Device Tree blob at 02c8ac00
>> >Booting using the fdt blob at 0x2c8ac00
>> >of_flat_tree at 0x02c8ac00 size 0x9d6d
>> >XIP Kernel Image ... OK
>> > do_bootm_states reserve: 0x2008800 -- 0x3b7c30
>> > lmb_reserve base:0x2008800 size:0x3b7c30
>> > no initrd_high
>> > env_get_bootm_size size:66748416(0x3fa8000) tmp:360448(0x58000)
>> > start:360448(0x58000)
>> >initrd_high = 0x03fa8000, copy_to_ram = 1
>> >Loading Ramdisk to 02c0, end 034c9d09 ... OK
>> > ERROR: image is not a fdt - must RESET the board to recover.
>> > FDT creation failed! hanging...### ERROR ### Please RESET the board ###
>> >
>> > Signed-off-by: Andy Yan 
>> > ---
>> >
>> >  common/image-fdt.c | 1 +
>> >  1 file changed, 1 insertion(+)
>>
>> Reviewed-by: Simon Glass 
>
>
> Please don't forget to take it, if it okay.

Tom, this is assigned to you, will you take it?

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v2 03/19] dm: device: Allow using uclass_find_device_by_seq() without OF_CONTROL

2018-10-10 Thread Simon Glass
On 5 October 2018 at 10:45, Jean-Jacques Hiblot  wrote:
> If OF_CONTROL is not enabled and DM_SEQ_ALIAS is enabled, we must
> assign an alias (requested sequence number) to devices that belongs to a
> class with the DM_UC_FLAG_SEQ_ALIAS flag. Otherwise
> uclass_find_device_by_seq() cannot be used to get/probe a device. In
> particular i2c_get_chip_for_busnum() cannot be used.
>
> Signed-off-by: Jean-Jacques Hiblot 
>
> ---
>
> Changes in v2:
> - don't use the DT to find the req_seq number if SPL_OF_PLATDATA is used.
>   Instead do it as if SPL_OF_CONTROL is not defined.
>
>  drivers/core/device.c| 10 ++
>  drivers/core/uclass.c| 24 
>  include/dm/uclass-internal.h | 13 +
>  3 files changed, 43 insertions(+), 4 deletions(-)

Reviewed-by: Simon Glass 

Using sequence numbers without OF_CONTROL is a tricky case. This looks
OK though.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v2 17/19] drivers: core: Add the option SPL_DM_DEVICE_REMOVE to the Kconfig

2018-10-10 Thread Simon Glass
On 5 October 2018 at 10:45, Jean-Jacques Hiblot  wrote:
> Signed-off-by: Jean-Jacques Hiblot 
> ---
>
> Changes in v2: None
>
>  drivers/core/Kconfig | 12 ++--
>  1 file changed, 10 insertions(+), 2 deletions(-)

Reviewed-by: Simon Glass 

But please always add a commit message:

- motivation for patch
- what the patch does
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v2 16/19] lib: fdtdec: Add function re-setup the fdt more effeciently

2018-10-10 Thread Simon Glass
Hi Jean-Jacques,

On 5 October 2018 at 10:45, Jean-Jacques Hiblot  wrote:
> In some cases it may be useful to be able to change the fdt we have been
> using and use another one instead. For example, the TI platforms uses an
> EEPROM to store board information and, based on the type of board,
> different dtbs are used by the SPL. When DM_I2C is used, a first dtb must
> be used before the I2C is initialized and only then the final dtb can be
> selected.
> To speed up the process and reduce memory usage, introduce a new function
> fdtdec_setup_best_match() that re-use the DTBs loaded in memory by
> fdtdec_setup() to select the best match.
>
> Signed-off-by: Jean-Jacques Hiblot 
> ---
>
> Changes in v2: None
>
>  include/asm-generic/global_data.h |  4 
>  include/fdtdec.h  | 17 +
>  lib/fdtdec.c  | 38 +-
>  3 files changed, 58 insertions(+), 1 deletion(-)
>
> diff --git a/include/asm-generic/global_data.h 
> b/include/asm-generic/global_data.h
> index c83fc01..49287fa 100644
> --- a/include/asm-generic/global_data.h
> +++ b/include/asm-generic/global_data.h
> @@ -77,6 +77,10 @@ typedef struct global_data {
>  #ifdef CONFIG_OF_LIVE
> struct device_node *of_root;
>  #endif
> +
> +#if CONFIG_IS_ENABLED(MULTI_DTB_FIT)
> +   const void *multi_dtb_fit;

comment please

> +#endif
> struct jt_funcs *jt;/* jump table */
> char env_buf[32];   /* buffer for env_get() before reloc. 
> */
>  #ifdef CONFIG_TRACE
> diff --git a/include/fdtdec.h b/include/fdtdec.h
> index 83be064..2cb3da2 100644
> --- a/include/fdtdec.h
> +++ b/include/fdtdec.h
> @@ -996,6 +996,23 @@ int fdtdec_setup_memory_banksize(void);
>   */
>  int fdtdec_setup(void);
>
> +#if CONFIG_IS_ENABLED(MULTI_DTB_FIT)
> +/**
> + * fdtdec_resetup()  - Set up the device tree ready for use again.

Please remove .

> + *
> + * The main difference with fdtdec_setup() is that it returns if the fdt has
> + * changed because a better match has been found.
> + * This is typically used for boards that rely on a DM driver to detect the
> + * board type.
> + *
> + * @param rescan Return a flag indicating that fdt has changed and rescaning 
> the
> + *   fdt is required.

This should be bool I think.

also 'rescanning'

Who actually calls this function and when is it permitted to call it?
I think then needs a bit more info in the comment.

Also I think you should mention it in the docs, perhaps README.fdt-control

Finally this calls either fdtdec_setup() or fdtdec_prepare() but I am
not not why it calls one or the other. Please add more docs/comments.

> + *
> + * @return 0 if OK, -ve on error
> + */
> +int fdtdec_resetup(int *rescan);
> +#endif
> +
>  /**
>   * Board-specific FDT initialization. Returns the address to a device tree 
> blob.
>   * Called when CONFIG_OF_BOARD is defined, or if CONFIG_OF_SEPARATE is 
> defined
> diff --git a/lib/fdtdec.c b/lib/fdtdec.c
> index 74196ce..3b80bd4 100644
> --- a/lib/fdtdec.c
> +++ b/lib/fdtdec.c
> @@ -1353,14 +1353,50 @@ int fdtdec_setup(void)
>  * If so, pick the most relevant
>  */
> fdt_blob = locate_dtb_in_fit(gd->fdt_blob);
> -   if (fdt_blob)
> +   if (fdt_blob) {
> +   gd->multi_dtb_fit = gd->fdt_blob;
> gd->fdt_blob = fdt_blob;
> +   }
> +
>  # endif
>  #endif
>
> return fdtdec_prepare_fdt();
>  }
>
> +#if CONFIG_IS_ENABLED(MULTI_DTB_FIT)
> +int fdtdec_resetup(int *rescan)
> +{
> +   void *fdt_blob;
> +
> +   /*
> +* If the current DTB is part of a compressed FIT image,
> +* try to locate the best match from the uncompressed
> +* FIT image stillpresent there. Save the time and space

is still present ? This doesn't make sense.

> +* required to uncompress it again.
> +*/
> +   if (gd->multi_dtb_fit) {
> +   fdt_blob = locate_dtb_in_fit(gd->multi_dtb_fit);
> +
> +   if (fdt_blob == gd->fdt_blob) {
> +   /*
> +* The best match did not change. no need to tear down
> +* the DM and rescan the fdt.
> +*/
> +   *rescan = 0;
> +   return 0;
> +   }
> +
> +   *rescan = 1;
> +   gd->fdt_blob = fdt_blob;
> +   return fdtdec_prepare_fdt();
> +   }
> +
> +   *rescan = 1;
> +   return fdtdec_setup();
> +}
> +#endif
> +
>  #ifdef CONFIG_NR_DRAM_BANKS
>  int fdtdec_decode_ram_size(const void *blob, const char *area, int board_id,
>phys_addr_t *basep, phys_size_t *sizep, bd_t *bd)
> --
> 2.7.4
>

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v2 08/19] dts: am43x: omap5: Add node for I2C in SPL

2018-10-10 Thread Simon Glass
On 5 October 2018 at 10:45, Jean-Jacques Hiblot  wrote:
> Signed-off-by: Jean-Jacques Hiblot 
> ---
>
> Changes in v2: None
>
>  arch/arm/dts/am437x-gp-evm-u-boot.dtsi | 4 
>  arch/arm/dts/omap5-u-boot.dtsi | 4 
>  2 files changed, 8 insertions(+)

Reviewed-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v2 02/19] dm: i2c: Add dm_i2c_probe_device() to test the presence of a chip

2018-10-10 Thread Simon Glass
Hi Jean-Jacques,

On 5 October 2018 at 10:45, Jean-Jacques Hiblot  wrote:
> In a non-DM environment, it is possible to test the presence of a chip
> using i2c_probe(chip_addr).
> dm_i2c_probe_device() brings the same functionality with a DM interface.
> The intent is to be able to test the presence of a chip for the device has
> been created with i2c_get_chip_for_busnum(bus_num, chip_addr, ...)
>
> Signed-off-by: Jean-Jacques Hiblot 
> ---
>
> Changes in v2: None
>
>  drivers/i2c/i2c-uclass.c |  8 
>  include/i2c.h| 13 +
>  2 files changed, 21 insertions(+)
>
> diff --git a/drivers/i2c/i2c-uclass.c b/drivers/i2c/i2c-uclass.c
> index c5a3c4e..ec88168 100644
> --- a/drivers/i2c/i2c-uclass.c
> +++ b/drivers/i2c/i2c-uclass.c
> @@ -378,6 +378,14 @@ int dm_i2c_probe(struct udevice *bus, uint chip_addr, 
> uint chip_flags,
> return ret;
>  }
>
> +int dm_i2c_probe_device(struct udevice *dev)
> +{
> +   struct udevice *bus = dev_get_parent(dev);
> +   struct dm_i2c_chip *chip = dev_get_parent_platdata(dev);
> +
> +   return i2c_probe_chip(bus, chip->chip_addr, chip->flags);
> +}

Why not just probe the device? That should have the same effect.

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v2 01/19] cmd: Kconfig: Do not include EEPROM if DM_I2C is used without DM_I2C_COMPAT

2018-10-10 Thread Simon Glass
On 5 October 2018 at 10:45, Jean-Jacques Hiblot  wrote:
> The implementation of the EEPROM commands does not support the DM I2C API.
> Prevent compilation breakage by not enabling it if the non-DM API is not
> available (if DM_I2C is used without DM_I2C_COMPAT)
>
> Signed-off-by: Jean-Jacques Hiblot 
>
> ---
>
> Changes in v2:
> - Add missing commit log to the commit disabling CMD_EEPROM when non-DM API
>   is not available
>
>  cmd/Kconfig | 1 +
>  1 file changed, 1 insertion(+)

Reviewed-by: Simon Glass 

Or perhaps we should convert or delete it?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v2 3/8] dm: util: Add a livetree equivalent API of dm_fdt_pre_reloc()

2018-10-10 Thread Bin Meng
Hi Simon,

On Thu, Oct 11, 2018 at 10:01 AM Simon Glass  wrote:
>
> On 7 October 2018 at 04:01, Bin Meng  wrote:
> > This adds a new API dm_ofnode_pre_reloc(), a livetree equivalent
> > API of dm_fdt_pre_reloc().
> >
> > Signed-off-by: Bin Meng 
> > ---
> >
> > Changes in v2: None
> >
> >  drivers/core/util.c | 25 +
> >  include/dm/util.h   | 27 ++-
> >  2 files changed, 51 insertions(+), 1 deletion(-)
>
> Reviewed-by: Simon Glass 
>
> I wonder if it is possible to delete the old code that doesn't support
> livetree? This implementation should support both.

Agreed. But there are two drivers (drivers/clk/at91/pmc.c and
drivers/clk/altera/clk-arria10.c) that calls dm_fdt_pre_reloc() at
this point. We can clean this up in the future.

Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v2 7/8] test: dm: core: Add a test case for driver marked with DM_FLAG_PRE_RELOC flag

2018-10-10 Thread Simon Glass
On 7 October 2018 at 04:01, Bin Meng  wrote:
> Now that we fixed the pre-relocation driver binding for driver marked
> with DM_FLAG_PRE_RELOC flag, add a test case to cover that scenario.
>
> Signed-off-by: Bin Meng 
> ---
>
> Changes in v2: None
>
>  arch/sandbox/dts/test.dts |  4 
>  test/dm/bus.c |  2 +-
>  test/dm/test-fdt.c| 29 ++---
>  3 files changed, 31 insertions(+), 4 deletions(-)

Reviewed-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v2 5/8] dm: Correct pre_reloc_only parameter description in several APIs' comments

2018-10-10 Thread Simon Glass
On 7 October 2018 at 04:01, Bin Meng  wrote:
> The pre_reloc_only parameter description currently only mentions
> drivers with the DM_FLAG_PRE_RELOC flag, but does not mention the
> special device tree properties. Correct them.
>
> Signed-off-by: Bin Meng 
> ---
>
> Changes in v2: None
>
>  include/dm/device-internal.h |  4 ++--
>  include/dm/lists.h   |  4 ++--
>  include/dm/root.h| 17 +
>  3 files changed, 13 insertions(+), 12 deletions(-)

Reviewed-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v2 8/8] timer: Sort Kconfig driver entries

2018-10-10 Thread Simon Glass
On 7 October 2018 at 04:01, Bin Meng  wrote:
> This is currently out of order. Sort it.
>
> Signed-off-by: Bin Meng 
>
> ---
>
> Changes in v2: None
>
>  drivers/timer/Kconfig | 110 
> +-
>  1 file changed, 55 insertions(+), 55 deletions(-)

Reviewed-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v2 6/8] dm: core: Mirror the chosen node parse logic in the livetree scanning

2018-10-10 Thread Simon Glass
On 7 October 2018 at 04:01, Bin Meng  wrote:
> Commit f2006808f099: ("dm: core: parse chosen node") added a logic
> to parse the chosen node during dm_scan_fdt_node(), but unfortunately
> it missed adding the same logic in dm_scan_fdt_live(). This mirrors
> the logic in the livetree version.
>
> The weird thing is that commit f2006808f099 did update the test case
> to test such logic, but I have no idea how the test case could pass.
>
> With this fix, the following 2 test cases now pass:
>
> Test: dm_test_bus_children: bus.c
> test/dm/bus.c:112, dm_test_bus_children(): num_devices ==
> list_count_items(>dev_head): Expected 7, got 6
>
> Test: dm_test_fdt: test-fdt.c
> test/dm/test-fdt.c:184, dm_test_fdt(): num_devices ==
> list_count_items(>dev_head): Expected 7, got 6
>
> Fixes: f2006808f099 ("dm: core: parse chosen node")
> Signed-off-by: Bin Meng 
> ---
>
> Changes in v2: None
>
>  drivers/core/root.c | 10 ++
>  1 file changed, 10 insertions(+)

I actually don't see that failure. Something odd is going on. Anyway
this looks right to me.

Reviewed-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v2 4/8] dm: core: Respect drivers with the DM_FLAG_PRE_RELOC flag in lists_bind_fdt()

2018-10-10 Thread Simon Glass
On 7 October 2018 at 04:01, Bin Meng  wrote:
> Currently the comments of several APIs (eg: dm_init_and_scan()) say:
>
> @pre_reloc_only: If true, bind only drivers with the DM_FLAG_PRE_RELOC
> flag. If false bind all drivers.
>
> The 'Pre-Relocation Support' chapter in doc/driver-model/README.txt
> documents the same that both device tree properties and driver flag
> are supported.
>
> However the implementation only checks these special device tree
> properties without checking the driver flag at all. This updates
> lists_bind_fdt() to consider both scenarios.
>
> Signed-off-by: Bin Meng 
>
> ---
>
> Changes in v2:
> - rebase on u-boot/master, and fix one build error
>
>  drivers/core/device.c  |  2 +-
>  drivers/core/lists.c   |  9 -
>  drivers/core/root.c| 12 
>  drivers/serial/serial-uclass.c |  2 +-
>  drivers/timer/timer-uclass.c   |  2 +-
>  include/dm/lists.h |  5 -
>  6 files changed, 19 insertions(+), 13 deletions(-)

Reviewed-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v2 2/8] cpu: mpc83xx: Remove unnecessary characters in the description string

2018-10-10 Thread Simon Glass
On 7 October 2018 at 04:01, Bin Meng  wrote:
> The description string should not contain unnecessary characters,
> like the ending '\n' or the leading 'CPU:'.
>
> Signed-off-by: Bin Meng 
> ---
>
> Changes in v2: None
>
>  drivers/cpu/mpc83xx_cpu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v2 1/8] dm: cpu: Fix print_cpuinfo() output

2018-10-10 Thread Simon Glass
On 7 October 2018 at 04:01, Bin Meng  wrote:
> It was observed that current output of print_cpuinfo() on QEMU
> x86 targets does not have an ending '\n', neither have a leading
> 'CPU:' any more. However it used to have these before.
>
> It turns out commit c0434407b595 introduced a unified DM version
> of print_cpuinfo() that exposed such issue on QEMU x86.
>
> Fixes: c0434407b595 ("board_f: Use static print_cpuinfo if CONFIG_CPU is 
> active")
> Signed-off-by: Bin Meng 
> ---
>
> Changes in v2: None
>
>  common/board_f.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v2 3/8] dm: util: Add a livetree equivalent API of dm_fdt_pre_reloc()

2018-10-10 Thread Simon Glass
On 7 October 2018 at 04:01, Bin Meng  wrote:
> This adds a new API dm_ofnode_pre_reloc(), a livetree equivalent
> API of dm_fdt_pre_reloc().
>
> Signed-off-by: Bin Meng 
> ---
>
> Changes in v2: None
>
>  drivers/core/util.c | 25 +
>  include/dm/util.h   | 27 ++-
>  2 files changed, 51 insertions(+), 1 deletion(-)

Reviewed-by: Simon Glass 

I wonder if it is possible to delete the old code that doesn't support
livetree? This implementation should support both.

- Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] 4 failures with 'ut dm'

2018-10-10 Thread Simon Glass
Hi Bin,

On 6 October 2018 at 10:32, Bin Meng  wrote:
> On Sat, Oct 6, 2018 at 9:14 PM Bin Meng  wrote:
>>
>> Hi Simon,
>>
>> With current u-boot/master, there are 4 failures with 'ut dm'. I was
>> wondering is this not covered by travis-ci?
>>
>> Test: dm_test_bus_children: bus.c
>> test/dm/bus.c:112, dm_test_bus_children(): num_devices ==
>> list_count_items(>dev_head): Expected 7, got 6
>>
>> Test: dm_test_fdt: test-fdt.c
>> test/dm/test-fdt.c:184, dm_test_fdt(): num_devices ==
>> list_count_items(>dev_head): Expected 7, got 6
>>
>
> The above 2 failures are fixed with the following patch:
> http://patchwork.ozlabs.org/patch/979952/
>
>> Test: dm_test_spmi_access: spmi.c
>> test/dm/spmi.c:55, dm_test_spmi_access(): 0 == device_get_child(bus,
>> 0, ): Expected 0, got -22
>>
>> Test: dm_test_spmi_access_peripheral: spmi.c
>> test/dm/spmi.c:82, dm_test_spmi_access_peripheral(): 0 ==
>> gpio_lookup_name("spmi1", , , ): Expected 0, got -22

Thanks for that. I have seen the last two errors at least, but with
dm/master I only see failures with test_gpt and test_unlink!

Hoping we can get everything perfect for this release.

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 4/4] WIP: travis: Add qemu-x86_64 target for test.py testing

2018-10-10 Thread Bin Meng
Hi Heinrich,

On Thu, Oct 11, 2018 at 9:48 AM Bin Meng  wrote:
>
> Add qemu-x86_64 to the list of targets we use for test.py runs.
>
> Signed-off-by: Bin Meng 
>
> ---
> testp.py testing is currently failing at 'bootefi selftest'.
>

Can you try this series for the 'bootefi selftest' testing?

BTW:  do you know how to call test.py on the local machine to do
testing on QEMU? The doc does not provide enough information ..

>  .travis.yml | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/.travis.yml b/.travis.yml
> index 2b759c9..9d0531f 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -408,6 +408,14 @@ matrix:
>BUILDMAN="^qemu-x86$"
>TOOLCHAIN="x86_64"
>BUILD_ROM="yes"
> +- name: "test/py qemu-x86_64"
> +  env:
> +- TEST_PY_BD="qemu-x86_64"
> +  TEST_PY_TEST_SPEC="not sleep"
> +  QEMU_TARGET="x86_64-softmmu"
> +  BUILDMAN="^qemu-x86_64$"
> +  TOOLCHAIN="x86_64"
> +  BUILD_ROM="yes"
>  - name: "test/py zynq_zc702"
>env:
>  - TEST_PY_BD="zynq_zc702"
> --

Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 3/4] x86: doc: Mention qemu-x86_64 support

2018-10-10 Thread Bin Meng
Currently only 32-bit U-Boot for QEMU x86 is documented. Mention
the 64-bit support.

Signed-off-by: Bin Meng 
---

 doc/README.x86 | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/doc/README.x86 b/doc/README.x86
index 8cc4672..ab48466 100644
--- a/doc/README.x86
+++ b/doc/README.x86
@@ -32,7 +32,7 @@ are supported:
- Link (Chromebook Pixel)
- Minnowboard MAX
- Samus (Chromebook Pixel 2015)
-   - QEMU x86
+   - QEMU x86 (32-bit & 64-bit)
 
 As for loading an OS, U-Boot supports directly booting a 32-bit or 64-bit
 Linux kernel as part of a FIT image. It also supports a compressed zImage.
@@ -376,7 +376,9 @@ QEMU x86 target instructions for bare mode:
 
 To build u-boot.rom for QEMU x86 targets, just simply run
 
-$ make qemu-x86_defconfig
+$ make qemu-x86_defconfig (for 32-bit)
+or
+$ make qemu-x86_64_defconfig (for 64-bit)
 $ make all
 
 Note this default configuration will build a U-Boot for the QEMU x86 i440FX
@@ -387,6 +389,8 @@ Device Tree Control  --->
...
(qemu-x86_q35) Default Device Tree for DT control
 
+To run 64-bit U-Boot, qemu-system-x86_64 should be used instead.
+
 Test with coreboot
 --
 For testing U-Boot as the coreboot payload, there are things that need be paid
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 4/4] WIP: travis: Add qemu-x86_64 target for test.py testing

2018-10-10 Thread Bin Meng
Add qemu-x86_64 to the list of targets we use for test.py runs.

Signed-off-by: Bin Meng 

---
testp.py testing is currently failing at 'bootefi selftest'.

 .travis.yml | 8 
 1 file changed, 8 insertions(+)

diff --git a/.travis.yml b/.travis.yml
index 2b759c9..9d0531f 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -408,6 +408,14 @@ matrix:
   BUILDMAN="^qemu-x86$"
   TOOLCHAIN="x86_64"
   BUILD_ROM="yes"
+- name: "test/py qemu-x86_64"
+  env:
+- TEST_PY_BD="qemu-x86_64"
+  TEST_PY_TEST_SPEC="not sleep"
+  QEMU_TARGET="x86_64-softmmu"
+  BUILDMAN="^qemu-x86_64$"
+  TOOLCHAIN="x86_64"
+  BUILD_ROM="yes"
 - name: "test/py zynq_zc702"
   env:
 - TEST_PY_BD="zynq_zc702"
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 1/4] x86: Specify -march=core2 to build 64-bit U-Boot proper

2018-10-10 Thread Bin Meng
With newer kernel.org GCC (7.3.0 or 8.1.0), the u-boot.rom image
built for qemu-x86_64 target does not boot. It keeps resetting
soon after the 32-bit SPL jumps to 64-bit proper. Debugging shows
that the reset happens inside env_callback_init().

0113dd85 :
 113dd85:   41 54   push   %r12
 113dd87:   55  push   %rbp
 113dd88:   31 c0   xor%eax,%eax
 113dd8a:   53  push   %rbx
 113dd8b:   0f 57 c0xorps  %xmm0,%xmm0

Executing "xorps %xmm0,%xmm0" causes CPU to immediately reset.
However older GCC like 5.4.0 (the one shipped by Ubuntu 16.04)
does not generate such instructions that utilizes SSE for this
function - env_callback_init() and U-Boot boots without any issue.
Explicitly specifying -march=core2 for newer GCC allows U-Boot
proper to boot again. Examine assembly codes of env_callback_init
and there is no SSE instruction in that function hence U-Boot
continues to boot.

core2 seems to be the oldest arch in GCC that supports 64-bit.
Like 32-bit U-Boot build we use -march=i386 which is the most
conservative cpu type so that the image can run on any x86
processor, let's do the same for the 64-bit U-Boot build.

Signed-off-by: Bin Meng 
---

 arch/x86/config.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/config.mk b/arch/x86/config.mk
index cc94071..576501e 100644
--- a/arch/x86/config.mk
+++ b/arch/x86/config.mk
@@ -23,7 +23,7 @@ endif
 ifeq ($(IS_32BIT),y)
 PLATFORM_CPPFLAGS += -march=i386 -m32
 else
-PLATFORM_CPPFLAGS += $(if $(CONFIG_SPL_BUILD),,-fpic) -fno-common -m64
+PLATFORM_CPPFLAGS += $(if $(CONFIG_SPL_BUILD),,-fpic) -fno-common -march=core2 
-m64
 endif
 
 PLATFORM_RELFLAGS += -fdata-sections -ffunction-sections -fvisibility=hidden
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 2/4] x86: Ensure no instruction sets of MMX/SSE are generated in 64-bit build

2018-10-10 Thread Bin Meng
With the '-march=core2' fix, it seems that we have some luck that
the 64-bit U-Boot boots again. However if we examine the disassembly
codes there are still SSE instructions elsewhere which means passing
cpu type to GCC is not enough to prevent it from generating these
instructions. A simple test case is doing a 'bootefi selftest' from
the U-Boot shell and it leads to a reset too.

The 'bootefi selftest' reset is even seen with the image created by
the relative older GCC 5.4.0, the one shipped by Ubuntu 16.04.

To make sure no MMX/SSE instruction sets are generated, tell GCC not
to do this. Note AVX is out of the question as CORE2 is old enough
to support AVX yet.

Signed-off-by: Bin Meng 
---

 arch/x86/config.mk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/config.mk b/arch/x86/config.mk
index 576501e..8151e47 100644
--- a/arch/x86/config.mk
+++ b/arch/x86/config.mk
@@ -24,6 +24,7 @@ ifeq ($(IS_32BIT),y)
 PLATFORM_CPPFLAGS += -march=i386 -m32
 else
 PLATFORM_CPPFLAGS += $(if $(CONFIG_SPL_BUILD),,-fpic) -fno-common -march=core2 
-m64
+PLATFORM_CPPFLAGS += -mno-mmx -mno-sse
 endif
 
 PLATFORM_RELFLAGS += -fdata-sections -ffunction-sections -fvisibility=hidden
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 1/1] test: overlay: add missing include

2018-10-10 Thread Simon Glass
On 10 October 2018 at 18:16, Heinrich Schuchardt  wrote:
>
> Compiling the overlay unit test fails with odroid-c2_defconfig showing
> errors like:
>
> test/overlay/cmd_ut_overlay.c:29:8:
> error: unknown type name ‘fdt32_t’
>
> Add the missing include.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  test/overlay/cmd_ut_overlay.c | 1 +
>  1 file changed, 1 insertion(+)

Reviewed-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 1/1] test: overlay: add missing include

2018-10-10 Thread Heinrich Schuchardt
Compiling the overlay unit test fails with odroid-c2_defconfig showing
errors like:

test/overlay/cmd_ut_overlay.c:29:8:
error: unknown type name ‘fdt32_t’

Add the missing include.

Signed-off-by: Heinrich Schuchardt 
---
 test/overlay/cmd_ut_overlay.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/test/overlay/cmd_ut_overlay.c b/test/overlay/cmd_ut_overlay.c
index f7ff93799f..3d34c8ab53 100644
--- a/test/overlay/cmd_ut_overlay.c
+++ b/test/overlay/cmd_ut_overlay.c
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
-- 
2.19.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH] bootcount: Make bootcount magic configurable

2018-10-10 Thread Marek Vasut
Add new Kconfig option, SYS_BOOTCOUNT_MAGIC, to select the boot
counter magic word. This can be useful ie. in case the entire
boot counter register is not usable.

Signed-off-by: Marek Vasut 
Cc: Tom Rini 
---
 drivers/bootcount/Kconfig |  6 ++
 drivers/bootcount/bootcount.c |  8 
 drivers/bootcount/bootcount_at91.c| 11 ++-
 drivers/bootcount/bootcount_davinci.c |  4 ++--
 drivers/bootcount/bootcount_ram.c |  2 +-
 include/common.h  |  1 -
 6 files changed, 19 insertions(+), 13 deletions(-)

diff --git a/drivers/bootcount/Kconfig b/drivers/bootcount/Kconfig
index 9a0bd516d9..67033637c0 100644
--- a/drivers/bootcount/Kconfig
+++ b/drivers/bootcount/Kconfig
@@ -127,4 +127,10 @@ config SYS_BOOTCOUNT_ADDR
help
  Set the address used for reading and writing the boot counter.
 
+config SYS_BOOTCOUNT_MAGIC
+   hex "Magic value for the boot counter"
+   default 0xB001C041
+   help
+ Set the magic value used for the boot counter.
+
 endif
diff --git a/drivers/bootcount/bootcount.c b/drivers/bootcount/bootcount.c
index 646c563f8a..66c1284c5b 100644
--- a/drivers/bootcount/bootcount.c
+++ b/drivers/bootcount/bootcount.c
@@ -16,13 +16,13 @@ __weak void bootcount_store(ulong a)
uintptr_t flush_end;
 
 #if defined(CONFIG_SYS_BOOTCOUNT_SINGLEWORD)
-   raw_bootcount_store(reg, (BOOTCOUNT_MAGIC & 0x) | a);
+   raw_bootcount_store(reg, (CONFIG_SYS_BOOTCOUNT_MAGIC & 0x) | a);
 
flush_end = roundup(CONFIG_SYS_BOOTCOUNT_ADDR + 4,
CONFIG_SYS_CACHELINE_SIZE);
 #else
raw_bootcount_store(reg, a);
-   raw_bootcount_store(reg + 4, BOOTCOUNT_MAGIC);
+   raw_bootcount_store(reg + 4, CONFIG_SYS_BOOTCOUNT_MAGIC);
 
flush_end = roundup(CONFIG_SYS_BOOTCOUNT_ADDR + 8,
CONFIG_SYS_CACHELINE_SIZE);
@@ -37,12 +37,12 @@ __weak ulong bootcount_load(void)
 #if defined(CONFIG_SYS_BOOTCOUNT_SINGLEWORD)
u32 tmp = raw_bootcount_load(reg);
 
-   if ((tmp & 0x) != (BOOTCOUNT_MAGIC & 0x))
+   if ((tmp & 0x) != (CONFIG_SYS_BOOTCOUNT_MAGIC & 0x))
return 0;
else
return (tmp & 0x);
 #else
-   if (raw_bootcount_load(reg + 4) != BOOTCOUNT_MAGIC)
+   if (raw_bootcount_load(reg + 4) != CONFIG_SYS_BOOTCOUNT_MAGIC)
return 0;
else
return raw_bootcount_load(reg);
diff --git a/drivers/bootcount/bootcount_at91.c 
b/drivers/bootcount/bootcount_at91.c
index 3092ba56c0..c4ab5ceafa 100644
--- a/drivers/bootcount/bootcount_at91.c
+++ b/drivers/bootcount/bootcount_at91.c
@@ -6,15 +6,16 @@
 #include 
 
 /*
- * We combine the BOOTCOUNT_MAGIC and bootcount in one 32-bit register.
- * This is done so we need to use only one of the four GPBR registers.
+ * We combine the CONFIG_SYS_BOOTCOUNT_MAGIC and bootcount in one 32-bit
+ * register. This is done so we need to use only one of the four GPBR
+ * registers.
  */
 void bootcount_store(ulong a)
 {
at91_gpbr_t *gpbr = (at91_gpbr_t *) ATMEL_BASE_GPBR;
 
-   writel((BOOTCOUNT_MAGIC & 0x) | (a & 0x),
-   >reg[AT91_GPBR_INDEX_BOOTCOUNT]);
+   writel((CONFIG_SYS_BOOTCOUNT_MAGIC & 0x) | (a & 0x),
+  >reg[AT91_GPBR_INDEX_BOOTCOUNT]);
 }
 
 ulong bootcount_load(void)
@@ -22,7 +23,7 @@ ulong bootcount_load(void)
at91_gpbr_t *gpbr = (at91_gpbr_t *) ATMEL_BASE_GPBR;
 
ulong val = readl(>reg[AT91_GPBR_INDEX_BOOTCOUNT]);
-   if ((val & 0x) != (BOOTCOUNT_MAGIC & 0x))
+   if ((val & 0x) != (CONFIG_SYS_BOOTCOUNT_MAGIC & 0x))
return 0;
else
return val & 0x;
diff --git a/drivers/bootcount/bootcount_davinci.c 
b/drivers/bootcount/bootcount_davinci.c
index 7101ad9413..6326957d7b 100644
--- a/drivers/bootcount/bootcount_davinci.c
+++ b/drivers/bootcount/bootcount_davinci.c
@@ -24,7 +24,7 @@ void bootcount_store(ulong a)
writel(RTC_KICK0R_WE, >kick0r);
writel(RTC_KICK1R_WE, >kick1r);
raw_bootcount_store(>scratch2,
-   (BOOTCOUNT_MAGIC & 0x) | (a & 0x));
+   (CONFIG_SYS_BOOTCOUNT_MAGIC & 0x) | (a & 0x));
 }
 
 ulong bootcount_load(void)
@@ -34,7 +34,7 @@ ulong bootcount_load(void)
(struct davinci_rtc *)CONFIG_SYS_BOOTCOUNT_ADDR;
 
val = raw_bootcount_load(>scratch2);
-   if ((val & 0x) != (BOOTCOUNT_MAGIC & 0x))
+   if ((val & 0x) != (CONFIG_SYS_BOOTCOUNT_MAGIC & 0x))
return 0;
else
return val & 0x;
diff --git a/drivers/bootcount/bootcount_ram.c 
b/drivers/bootcount/bootcount_ram.c
index e514a57286..edef36724b 100644
--- a/drivers/bootcount/bootcount_ram.c
+++ b/drivers/bootcount/bootcount_ram.c
@@ -28,7 +28,7 @@ 

Re: [U-Boot] [PATCH v5] arm: socfpga: fix SPL booting from fpga OnChip RAM

2018-10-10 Thread Marek Vasut
On 10/10/2018 02:55 PM, Simon Goldschmidt wrote:
> This patch prevents disabling the FPGA bridges when
> SPL or U-Boot is executed from FPGA onchip RAM.
> 
> Signed-off-by: Simon Goldschmidt 
> ---
> 
> Changes in v5:
> - changed inline function 'socfpga_is_fpga_slaves_addr(addr)'
>   to 'socfpga_is_booting_from_fpga()'
> 
> Changes in v4:
> - use an inline function in misc.h to check for the address
>   range instead of a macro in base_addr_ac5.h
> 
> Changes in v3:
> - use __image_copy_start to check if we are executing from FPGA
> 
> Changes in v2:
> - use less ifdefs and more C code for address checks
>   (but this gives a checkpatch warning because of comparing two
>   upper case constants)
> - changed comments
> 
>  arch/arm/mach-socfpga/include/mach/base_addr_ac5.h |  1 +
>  arch/arm/mach-socfpga/include/mach/misc.h  |  9 +
>  arch/arm/mach-socfpga/misc_gen5.c  |  9 -
>  arch/arm/mach-socfpga/spl_gen5.c   | 10 +++---
>  4 files changed, 25 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/mach-socfpga/include/mach/base_addr_ac5.h 
> b/arch/arm/mach-socfpga/include/mach/base_addr_ac5.h
> index bb9e3faa29..2725e9fcc3 100644
> --- a/arch/arm/mach-socfpga/include/mach/base_addr_ac5.h
> +++ b/arch/arm/mach-socfpga/include/mach/base_addr_ac5.h
> @@ -6,6 +6,7 @@
>  #ifndef _SOCFPGA_BASE_ADDRS_H_
>  #define _SOCFPGA_BASE_ADDRS_H_
>  
> +#define SOCFPGA_FPGA_SLAVES_ADDRESS  0xc000
>  #define SOCFPGA_STM_ADDRESS  0xfc00
>  #define SOCFPGA_DAP_ADDRESS  0xff00
>  #define SOCFPGA_EMAC0_ADDRESS0xff70
> diff --git a/arch/arm/mach-socfpga/include/mach/misc.h 
> b/arch/arm/mach-socfpga/include/mach/misc.h
> index 4fc9570a04..26609927c8 100644
> --- a/arch/arm/mach-socfpga/include/mach/misc.h
> +++ b/arch/arm/mach-socfpga/include/mach/misc.h
> @@ -6,6 +6,8 @@
>  #ifndef _MISC_H_
>  #define _MISC_H_
>  
> +#include 
> +
>  void dwmac_deassert_reset(const unsigned int of_reset_id, const u32 phymode);
>  
>  struct bsel {
> @@ -23,6 +25,13 @@ static inline void socfpga_fpga_add(void) {}
>  
>  #ifdef CONFIG_TARGET_SOCFPGA_GEN5
>  void socfpga_sdram_remap_zero(void);
> +static inline bool socfpga_is_booting_from_fpga(void)
> +{
> + if ((__image_copy_start >= (char *)SOCFPGA_FPGA_SLAVES_ADDRESS) &&
> + (__image_copy_start < (char *)SOCFPGA_STM_ADDRESS))
> + return true;
> + return false;
> +}
>  #endif
>  
>  #ifdef CONFIG_TARGET_SOCFPGA_ARRIA10
> diff --git a/arch/arm/mach-socfpga/misc_gen5.c 
> b/arch/arm/mach-socfpga/misc_gen5.c
> index 429c3d6cd5..5fa40937c4 100644
> --- a/arch/arm/mach-socfpga/misc_gen5.c
> +++ b/arch/arm/mach-socfpga/misc_gen5.c
> @@ -177,6 +177,8 @@ static void socfpga_nic301_slave_ns(void)
>  
>  void socfpga_sdram_remap_zero(void)
>  {
> + u32 remap;
> +
>   socfpga_nic301_slave_ns();
>  
>   /*
> @@ -187,7 +189,12 @@ void socfpga_sdram_remap_zero(void)
>   setbits_le32(_regs->sacr, 0xfff);
>  
>   /* Configure the L2 controller to make SDRAM start at 0 */
> - writel(0x1, _regs->remap);   /* remap.mpuzero */
> + remap = 0x1; /* remap.mpuzero */
> + /* Keep fpga bridge enabled when running from FPGA onchip RAM */
> + if (socfpga_is_booting_from_fpga())
> + remap |= 0x8; /* remap.hps2fpga */
> + writel(remap, _regs->remap);
> +
>   writel(0x1, >pl310_addr_filter_start);
>  }
>  
> diff --git a/arch/arm/mach-socfpga/spl_gen5.c 
> b/arch/arm/mach-socfpga/spl_gen5.c
> index be318cc0d9..ccdc661d05 100644
> --- a/arch/arm/mach-socfpga/spl_gen5.c
> +++ b/arch/arm/mach-socfpga/spl_gen5.c
> @@ -92,8 +92,11 @@ void board_init_f(ulong dummy)
>  
>   /* Put everything into reset but L4WD0. */
>   socfpga_per_reset_all();
> - /* Put FPGA bridges into reset too. */
> - socfpga_bridges_reset(1);
> +
> + if (!socfpga_is_booting_from_fpga()) {
> + /* Put FPGA bridges into reset too. */
> + socfpga_bridges_reset(1);
> + }
>  
>   socfpga_per_reset(SOCFPGA_RESET(SDR), 0);
>   socfpga_per_reset(SOCFPGA_RESET(UART0), 0);
> @@ -163,5 +166,6 @@ void board_init_f(ulong dummy)
>   hang();
>   }
>  
> - socfpga_bridges_reset(1);
> + if (!socfpga_is_booting_from_fpga())
> + socfpga_bridges_reset(1);
>  }
> 
Applied, thanks !

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v2 3/4] arm: socfpga: stratix10: Add Stratix10 FPGA into FPGA device table

2018-10-10 Thread Marek Vasut
On 10/10/2018 07:30 AM, Ang, Chee Hong wrote:
> On Tue, 2018-10-09 at 14:48 +0200, Marek Vasut wrote:
>> On 10/09/2018 05:03 AM, Ang, Chee Hong wrote:
>>>
>>> On Mon, 2018-10-08 at 22:32 +0200, Marek Vasut wrote:

 On 10/08/2018 05:10 PM, Ang, Chee Hong wrote:
>
>
> On Mon, 2018-10-08 at 11:57 +0200, Marek Vasut wrote:
>>
>>
>> On 10/08/2018 11:48 AM, chee.hong@intel.com wrote:
>>>
>>>
>>>
>>> From: "Ang, Chee Hong" 
>>>
>>> Enable 'fpga' command in u-boot. User will be able to use
>>> the
>>> fpga
>>> command to program the FPGA on Stratix10 SoC.
>>>
>>> Signed-off-by: Ang, Chee Hong 
>>> ---
>>>  arch/arm/mach-socfpga/misc.c | 29
>>> +
>>>  arch/arm/mach-socfpga/misc_s10.c |  2 ++
>>>  drivers/fpga/altera.c|  6 ++
>>>  include/altera.h |  4 
>>>  4 files changed, 41 insertions(+)
>>>
>>> diff --git a/arch/arm/mach-socfpga/misc.c b/arch/arm/mach-
>>> socfpga/misc.c
>>> index a4f6d5c..7986b58 100644
>>> --- a/arch/arm/mach-socfpga/misc.c
>>> +++ b/arch/arm/mach-socfpga/misc.c
>>> @@ -88,6 +88,27 @@ int overwrite_console(void)
>>>  #endif
>>>  
>>>  #ifdef CONFIG_FPGA
>>> +#ifdef CONFIG_FPGA_STRATIX10
>>> +/*
>>> + * FPGA programming support for SoC FPGA Stratix 10
>>> + */
>>> +static Altera_desc altera_fpga[] = {
>>> +   {
>>> +   /* Family */
>>> +   Intel_FPGA_Stratix10,
>>> +   /* Interface type */
>>> +   secure_device_manager_mailbox,
>>> +   /* No limitation as additional data will
>>> be
>>> ignored */
>>> +   -1,
>>> +   /* No device function table */
>>> +   NULL,
>>> +   /* Base interface address specified in
>>> driver
>>> */
>>> +   NULL,
>>> +   /* No cookie implementation */
>>> +   0
>>> +   },
>>> +};
>>> +#else
>>>  /*
>>>   * FPGA programming support for SoC FPGA Cyclone V
>>>   */
>>> @@ -107,6 +128,7 @@ static Altera_desc altera_fpga[] = {
>>>     0
>>>     },
>>>  };
>>> +#endif
>>>  
>>>  /* add device descriptor to FPGA device table */
>>>  void socfpga_fpga_add(void)
>>> @@ -116,6 +138,13 @@ void socfpga_fpga_add(void)
>>>     for (i = 0; i < ARRAY_SIZE(altera_fpga); i++)
>>>     fpga_add(fpga_altera, _fpga[i]);
>>>  }
>>> +
>>> +#else
>>> +
>>> +__weak void socfpga_fpga_add(void)
>>> +{
>>> +}
>> Why is a __weak function defined only in else-statement ?
>>
>> It should be defined always, with a sane default
>> implementation.
> I will remove the empty function in #else-statement and define
> the
> default function like this :
>
> /* add device descriptor to FPGA device table */
> void socfpga_fpga_add(void)
> {
> #ifdef CONFIG_FPGA
>   int i;
>   fpga_init();
>   for (i = 0; i < ARRAY_SIZE(altera_fpga); i++)
>   fpga_add(fpga_altera, _fpga[i]);
> #endif
> }
>
> Is that OK?
 Can't you have __weak empty implementation of socfpga_fpga_add()
 and
 implement a version per platform ? Would that work and make sense
 ?
>>> socfpga_fpga_add() as shown above is a generic function for adding
>>> FPGA
>>> devices to FPGA driver which applies to all our platforms. This is
>>> the
>>> reason why it is defined in misc.c instead of
>>> misc_.c.
>>>
>>> It turned out we already have this defined in misc.h:
>>> #ifdef CONFIG_FPGA
>>> void socfpga_fpga_add(void);
>>> #else
>>> static inline void socfpga_fpga_add(void) {}
>>> #endif
>> Right, if you had one socfpga_fpga_add() per platform + generic empty
>> one, you could drop that whole thing ^.
> Yes. It's being addressed in v3 patch:
> https://lists.denx.de/pipermail/u-boot/2018-October/343561.html

So where did the function go in there ? I don't see any __weak anything.

 btw. the best solution would be to fix this proper and implement
 a
 DM/DT
 based probing of the FPGA, including a proper driver(s) in
 drivers/fpga/
 instead of putting all the crud into arch/arm/mach-socfpga ...
>> What do you think about this ^
>>
> I do agree DM/DT is the proper way to implement driver.
> But right now those FPGA drivers in drivers/fpga need to be at least
> call fpga_add() to add themselves into FPGA device table so that their
> callback functions can be invoked correctly when user issue 'fpga
> load', 'fpga info' at the command prompt.
> So in other words, all drivers in drivers/fpga rely on
> drivers/fpga/fpga.c (FPGA core driver) to work.

Well, that should be fixed so that they probe from DT, just like any
other driver. I'm not fond of adding stuff to 

Re: [U-Boot] [PATCH] debug uart: don't print before initialization

2018-10-10 Thread Simon Goldschmidt
On Wed, Oct 10, 2018 at 10:03 PM Simon Glass  wrote:
>
> Hi Simon,
>
> On 10 October 2018 at 07:28, Simon Goldschmidt
>  wrote:
> >
> > + Marek (as he commented on the original patch 
> > http://patchwork.ozlabs.org/patch/955765/)
> >
> > On 09.10.2018 07:06, Simon Goldschmidt wrote:
> >>
> >> On Tue, Oct 9, 2018 at 5:41 AM Simon Glass  wrote:
> >>>
> >>> Hi,
> >>>
> >>> On 7 October 2018 at 11:52, Simon Goldschmidt
> >>>  wrote:
> 
>  At least on socfpga gen5, _debug_uart_putc() can be called
>  before debug_uart_init(), which leaves us stuck in an
>  infinite loop in the ns16550 debug uart driver.
> >>>
> >>> Can you fix that? That is a bug.
> >>
> >> I already posted a patch for that but it was rejected:
> >> http://patchwork.ozlabs.org/patch/955765/
> >
> >
> > I'd have to add I still thing that that patch is good to fix this:
> > It checks that the baudrate divisor is set, which effectively is
> > an 'enable' bit for this hardware.
> >
> > There were comments about the style (we can talk about that)
> > and Marek rejected it because he wanted a generic solution.
> > But honestly, given your idea that some platforms init the debug
> > uart before setting up gd, I don't think I can find a solution for
> > this.
> >
> > So I'd really like to get my original patch applied (see above).
>
> Yes I think your patch is best - it is specific to the hardware which
> is the only way you can safely detect whether the UART is enabled.
>
> We cannot rely on state like global_data to tell if the debug UART is
> enabled. We could use a flag in the DATA section on some devices, but
> that is also pretty nasty and we've been trying to avoid adding such
> things and using global_data instead.
>
> So I am OK with the original patch.
>
> However before going further I'd like to understand your thoughts on
> this question: I feel that you are checking for something that should
> not happen - i.e. the debug UART must be inited before use, just like
> any other device. We don't in general put these sorts of checks into
> other drivers. Why is the debug UART different?

On this specific platform (socfpga cylcone5/gen5), the preloader calls
a function before initializing the debug uart that is also called later and
that should emit an error in one case. And if this is the case (which it
can be depending on the boot source), then the system will hang when
debug uart is enabled (loop forever in the debug uart output code).

Now you can say we can initialize the debug uart earlier on this platform,
but that doesn't really work as it could be that the above function enables
a bus that is required for the debug uart (on socfpga, I could well imagine
the debug being implemented in FPGA and the offending function
enables the FPGA bridge).

Then you could argue to remove the offending printf, but I feel that debug
uart should help in debugging, not prevent it by entering an infinite loop
when printf is called at the wrong time.

I just feel it's better to lose some printf messages at the start than adding
a hang that's not present without debug uart.

And as much as I'd love to solve this in a general way, the multitudes of
different startup code does not seem to leave an easy way to solve this
other than I did...?

Simon

>
> Regards,
> Simon
>
> >
> > Simon
> >
> >
> >>
> >> As patman automatically choses the CC addresses, you weren't
> >> on the CC list back then, since that patch covered different filfes.
> >>
> >>
> >> Simon
> >>
>  Since this prevents debugging startup problems instead
>  of helping, let's add a field to 'gd' that prevents
>  calling the _debug_uart_putc() until debug_uart_init()
>  has been called.
> 
>  Signed-off-by: Simon Goldschmidt 
>  ---
> 
>    include/asm-generic/global_data.h |  3 +++
>    include/debug_uart.h  | 19 ++-
>    2 files changed, 17 insertions(+), 5 deletions(-)
> 
>  diff --git a/include/asm-generic/global_data.h 
>  b/include/asm-generic/global_data.h
>  index c83fc01b76..9de7f48476 100644
>  --- a/include/asm-generic/global_data.h
>  +++ b/include/asm-generic/global_data.h
>  @@ -122,6 +122,9 @@ typedef struct global_data {
>   struct list_head log_head;  /* List of struct log_device */
>   int log_fmt;/* Mask containing log format 
>  info */
>    #endif
>  +#ifdef CONFIG_DEBUG_UART
>  +   int debug_uart_initialized; /* No print before 
>  debug_uart_init */
>  +#endif
> >>>
> >>> There is no requirement that gd be set up before the debug UART is
> >>> running. It certainly isn't on the few platforms I know about.
> >>>
> >>> Regards,
> >>> Simon
> >
> >
> >
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] debug uart: don't print before initialization

2018-10-10 Thread Simon Glass
Hi Simon,

On 10 October 2018 at 07:28, Simon Goldschmidt
 wrote:
>
> + Marek (as he commented on the original patch 
> http://patchwork.ozlabs.org/patch/955765/)
>
> On 09.10.2018 07:06, Simon Goldschmidt wrote:
>>
>> On Tue, Oct 9, 2018 at 5:41 AM Simon Glass  wrote:
>>>
>>> Hi,
>>>
>>> On 7 October 2018 at 11:52, Simon Goldschmidt
>>>  wrote:

 At least on socfpga gen5, _debug_uart_putc() can be called
 before debug_uart_init(), which leaves us stuck in an
 infinite loop in the ns16550 debug uart driver.
>>>
>>> Can you fix that? That is a bug.
>>
>> I already posted a patch for that but it was rejected:
>> http://patchwork.ozlabs.org/patch/955765/
>
>
> I'd have to add I still thing that that patch is good to fix this:
> It checks that the baudrate divisor is set, which effectively is
> an 'enable' bit for this hardware.
>
> There were comments about the style (we can talk about that)
> and Marek rejected it because he wanted a generic solution.
> But honestly, given your idea that some platforms init the debug
> uart before setting up gd, I don't think I can find a solution for
> this.
>
> So I'd really like to get my original patch applied (see above).

Yes I think your patch is best - it is specific to the hardware which
is the only way you can safely detect whether the UART is enabled.

We cannot rely on state like global_data to tell if the debug UART is
enabled. We could use a flag in the DATA section on some devices, but
that is also pretty nasty and we've been trying to avoid adding such
things and using global_data instead.

So I am OK with the original patch.

However before going further I'd like to understand your thoughts on
this question: I feel that you are checking for something that should
not happen - i.e. the debug UART must be inited before use, just like
any other device. We don't in general put these sorts of checks into
other drivers. Why is the debug UART different?

Regards,
Simon

>
> Simon
>
>
>>
>> As patman automatically choses the CC addresses, you weren't
>> on the CC list back then, since that patch covered different filfes.
>>
>>
>> Simon
>>
 Since this prevents debugging startup problems instead
 of helping, let's add a field to 'gd' that prevents
 calling the _debug_uart_putc() until debug_uart_init()
 has been called.

 Signed-off-by: Simon Goldschmidt 
 ---

   include/asm-generic/global_data.h |  3 +++
   include/debug_uart.h  | 19 ++-
   2 files changed, 17 insertions(+), 5 deletions(-)

 diff --git a/include/asm-generic/global_data.h 
 b/include/asm-generic/global_data.h
 index c83fc01b76..9de7f48476 100644
 --- a/include/asm-generic/global_data.h
 +++ b/include/asm-generic/global_data.h
 @@ -122,6 +122,9 @@ typedef struct global_data {
  struct list_head log_head;  /* List of struct log_device */
  int log_fmt;/* Mask containing log format 
 info */
   #endif
 +#ifdef CONFIG_DEBUG_UART
 +   int debug_uart_initialized; /* No print before debug_uart_init 
 */
 +#endif
>>>
>>> There is no requirement that gd be set up before the debug UART is
>>> running. It certainly isn't on the few platforms I know about.
>>>
>>> Regards,
>>> Simon
>
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 2/4] pci: Update documentation to make 'compatible' string optional

2018-10-10 Thread Marek Vasut
Reword the documentation to make it clear the compatible string is now
optional, yet still matching on it takes precedence over PCI IDs and
PCI classes.

Signed-off-by: Marek Vasut 
Cc: Simon Glass 
Cc: Tom Rini 
---
 doc/driver-model/pci-info.txt | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/doc/driver-model/pci-info.txt b/doc/driver-model/pci-info.txt
index e1701d1fbc..14364c5c75 100644
--- a/doc/driver-model/pci-info.txt
+++ b/doc/driver-model/pci-info.txt
@@ -34,11 +34,15 @@ under that bus.
 Note that this is all done on a lazy basis, as needed, so until something is
 touched on PCI (eg: a call to pci_find_devices()) it will not be probed.
 
-PCI devices can appear in the flattened device tree. If they do this serves to
-specify the driver to use for the device. In this case they will be bound at
-first. Each PCI device node must have a compatible string list as well as a
- property, as defined by the IEEE Std 1275-1994 PCI bus binding document
-v2.1. Note we must describe PCI devices with the same bus hierarchy as the
+PCI devices can appear in the flattened device tree. If they do, their node
+often contains extra information which cannot be derived from the PCI IDs or
+PCI class of the device. Each PCI device node must have a  property, as
+defined by the IEEE Std 1275-1994 PCI bus binding document v2.1. Compatible
+string list is optional and generally not needed, since PCI is discoverable
+bus, albeit there are justified exceptions. If the compatible string is
+present, matching on it takes precedence over PCI IDs and PCI classes.
+
+Note we must describe PCI devices with the same bus hierarchy as the
 hardware, otherwise driver model cannot detect the correct parent/children
 relationship during PCI bus enumeration thus PCI devices won't be bound to
 their drivers accordingly. A working example like below:
-- 
2.18.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 4/4] test: Add test for PCI device without compat string and with DT node

2018-10-10 Thread Marek Vasut
Add test which checks if a PCI device described in DT with an
entry and reg = <...> property, but without compatible string
results in a valid U-Boot PCI udevice with the udevice.node
populated with reference to this DT node. Also check if the
other PCI device without a DT node does not contain any bogus
udevice.node.

Signed-off-by: Marek Vasut 
Cc: Simon Glass 
Cc: Tom Rini 
---
 test/dm/pci.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/test/dm/pci.c b/test/dm/pci.c
index 869970072d..a1dedd84a7 100644
--- a/test/dm/pci.c
+++ b/test/dm/pci.c
@@ -119,8 +119,13 @@ static int dm_test_pci_drvdata(struct unit_test_state *uts)
 
ut_assertok(dm_pci_bus_find_bdf(PCI_BDF(1, 0x08, 0), ));
ut_asserteq(SWAP_CASE_DRV_DATA, swap->driver_data);
+   ut_assertok(dev_of_valid(swap));
ut_assertok(dm_pci_bus_find_bdf(PCI_BDF(1, 0x0c, 0), ));
ut_asserteq(SWAP_CASE_DRV_DATA, swap->driver_data);
+   ut_assertok(dev_of_valid(swap));
+   ut_assertok(dm_pci_bus_find_bdf(PCI_BDF(1, 0x10, 0), ));
+   ut_asserteq(SWAP_CASE_DRV_DATA, swap->driver_data);
+   ut_assertok(!dev_of_valid(swap));
 
return 0;
 }
-- 
2.18.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 3/4] test: Add PCI device entry without compat string and with DT node

2018-10-10 Thread Marek Vasut
Add PCI entry without compatible string and with a DT node only with
reg = <...> property into the DT. This is needed for the tests to
verify whether such a setup creates an U-Boot PCI device with the
DT node associated with it in udevice.node.

Signed-off-by: Marek Vasut 
Cc: Simon Glass 
Cc: Tom Rini 
---
 arch/sandbox/dts/test.dts | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index ad94901fa1..0a6b86999d 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -363,7 +363,11 @@
ranges = <0x0200 0 0x3000 0x3000 0 0x2000
0x0100 0 0x4000 0x4000 0 0x2000>;
sandbox,dev-info = <0x08 0x00 0x1234 0x5678
-   0x0c 0x00 0x1234 0x5678>;
+   0x0c 0x00 0x1234 0x5678
+   0x10 0x00 0x1234 0x5678>;
+   pci@10,0 {
+   reg = <0x8000 0 0 0 0>;
+   };
};
 
pci2: pci-controller2 {
-- 
2.18.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 1/4] pci: Support parsing PCI controller DT subnodes

2018-10-10 Thread Marek Vasut
The PCI controller can have DT subnodes describing extra properties
of particular PCI devices, ie. a PHY attached to an EHCI controller
on a PCI bus. This patch parses those DT subnodes and assigns a node
to the PCI device instance, so that the driver can extract details
from that node and ie. configure the PHY using the PHY subsystem.

Signed-off-by: Marek Vasut 
Cc: Simon Glass 
Cc: Tom Rini 
---
V2: Use ofnode_read_pci_addr() instead of ofnode_get_addr_size()
---
 drivers/pci/pci-uclass.c | 32 +---
 1 file changed, 29 insertions(+), 3 deletions(-)

diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
index eb118f3496..da49c96ed5 100644
--- a/drivers/pci/pci-uclass.c
+++ b/drivers/pci/pci-uclass.c
@@ -90,6 +90,27 @@ int pci_get_ff(enum pci_size_t size)
}
 }
 
+static void pci_dev_find_ofnode(struct udevice *bus, phys_addr_t bdf,
+   ofnode *rnode)
+{
+   struct fdt_pci_addr addr;
+   ofnode node;
+   int ret;
+
+   dev_for_each_subnode(node, bus) {
+   ret = ofnode_read_pci_addr(node, FDT_PCI_SPACE_CONFIG, "reg",
+  );
+   if (ret)
+   continue;
+
+   if (PCI_MASK_BUS(addr.phys_hi) != PCI_MASK_BUS(bdf))
+   continue;
+
+   *rnode = node;
+   break;
+   }
+};
+
 int pci_bus_find_devfn(struct udevice *bus, pci_dev_t find_devfn,
   struct udevice **devp)
 {
@@ -641,6 +662,7 @@ static int pci_find_and_bind_driver(struct udevice *parent,
pci_dev_t bdf, struct udevice **devp)
 {
struct pci_driver_entry *start, *entry;
+   ofnode node = ofnode_null();
const char *drv;
int n_ents;
int ret;
@@ -651,6 +673,10 @@ static int pci_find_and_bind_driver(struct udevice *parent,
 
debug("%s: Searching for driver: vendor=%x, device=%x\n", __func__,
  find_id->vendor, find_id->device);
+
+   /* Determine optional OF node */
+   pci_dev_find_ofnode(parent, bdf, );
+
start = ll_entry_start(struct pci_driver_entry, pci_driver_entry);
n_ents = ll_entry_count(struct pci_driver_entry, pci_driver_entry);
for (entry = start; entry != start + n_ents; entry++) {
@@ -684,8 +710,8 @@ static int pci_find_and_bind_driver(struct udevice *parent,
 * find another driver. For now this doesn't seem
 * necesssary, so just bind the first match.
 */
-   ret = device_bind(parent, drv, drv->name, NULL, -1,
- );
+   ret = device_bind_ofnode(parent, drv, drv->name, NULL,
+node, );
if (ret)
goto error;
debug("%s: Match found: %s\n", __func__, drv->name);
@@ -712,7 +738,7 @@ static int pci_find_and_bind_driver(struct udevice *parent,
return -ENOMEM;
drv = bridge ? "pci_bridge_drv" : "pci_generic_drv";
 
-   ret = device_bind_driver(parent, drv, str, devp);
+   ret = device_bind_driver_to_node(parent, drv, str, node, devp);
if (ret) {
debug("%s: Failed to bind generic driver: %d\n", __func__, ret);
free(str);
-- 
2.18.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v3 2/6] driver: net: fsl-mc: remove unused strcture elements

2018-10-10 Thread Joe Hershberger
On Wed, Oct 10, 2018 at 12:11 AM Pankaj Bansal  wrote:
>
> Hi Joe,
>
> > -Original Message-
> > From: Joe Hershberger [mailto:joe.hershber...@ni.com]
> > Sent: Wednesday, October 10, 2018 9:29 AM
> > To: Pankaj Bansal 
> > Cc: Joseph Hershberger ; u-boot  > b...@lists.denx.de>
> > Subject: Re: [U-Boot] [PATCH v3 2/6] driver: net: fsl-mc: remove unused
> > strcture elements
> >
> > On Tue, Oct 9, 2018 at 9:59 PM Pankaj Bansal 
> > wrote:
> > >
> > > The phydev structure is present in both ldpaa_eth_priv and
> > > wriop_dpmac_info. the phydev in wriop_dpmac_info is not being used
> > >
> > > As the phydev is created based on phy_addr and bus members of
> > > wriop_dpmac_info, it is appropriate to keep phydev in
> > wriop_dpmac_info.
> > >
> > > Also phy_regs is not being used, therefore remove it
> > >
> > > Signed-off-by: Pankaj Bansal 
> > > Acked-by: Joe Hershberger 
> > > ---
> > >
> > > Notes:
> > > V3:
> > > - No change
> >
> > Please be sure you are running scripts/checkpatch.pl on your patches.
> > v2 had a number of issues I had to fix up. I'm pretty sure this was one of
> > them.
>
> I had run checkpatch script on all the versions of patches I sent.
> I use this command "./scripts/checkpatch.pl 0001-something.patch"
> This "no return at the end of function" issue was not reported by checkpatch 
> script.
>
> Can you please tell me which issues in V2 are you referring to?
> Because when I ran checkpatch.pl, it gave me no errors or warnings but 7 
> checks regarding alignment in board/freescale/ls2080aqds/eth.c.
> I did not do any changes for that because that code was not part of my patch 
> and I think that was done
> so that line doesn't exceed 80 characters.

This patch specifically had a complaint "CHECK: braces {} should be
used on all arms of this statement" that I fixed up.

This issue doesn't last long, since the code in question is fixed in
"driver: net: fsl-mc: Modify the dpmac link detection method", but we
prefer not to have patches that have issues. patman will tell you
about it.

I've applied v3 and it looks like "Freescale AArch64" is still warning
( https://travis-ci.org/jhershbe/u-boot/jobs/439762814 ) ...

-

   aarch64:  +   ls2080a_emu
+drivers/net/ldpaa_eth/ldpaa_eth.c: In function 'ldpaa_get_dpmac_state':
+drivers/net/ldpaa_eth/ldpaa_eth.c:408:6: error: unused variable 'err'
[-Werror=unused-variable]
+  int err;
+  ^~~
+drivers/net/ldpaa_eth/ldpaa_eth.c:407:6: error: unused variable
'phy_num' [-Werror=unused-variable]
+  int phy_num, phys_detected;
+  ^~~
+drivers/net/ldpaa_eth/ldpaa_eth.c:405:21: error: unused variable
'phydev' [-Werror=unused-variable]
+  struct phy_device *phydev = NULL;
+ ^~
+drivers/net/ldpaa_eth/ldpaa_eth.c: In function 'ldpaa_eth_stop':
+drivers/net/ldpaa_eth/ldpaa_eth.c:594:6: error: unused variable
'phy_num' [-Werror=unused-variable]
+  int phy_num;
+drivers/net/ldpaa_eth/ldpaa_eth.c:593:21: error: unused variable
'phydev' [-Werror=unused-variable]
+cc1: all warnings being treated as errors
+make[3]: *** [drivers/net/ldpaa_eth/ldpaa_eth.o] Error 1
+make[2]: *** [drivers/net/ldpaa_eth] Error 2
+make[1]: *** [drivers/net] Error 2
+make: *** [sub-make] Error 2

-

Both "driver: net: fsl-mc: Modify the dpmac link detection method" and
"driver: net: fsl-mc: Add support of multiple phys for dpmac"
introduce unused variable warnings on ls2080a_emu.

-Joe

>
> >
> > You would do yourself a favor to use tools/patman/patman.
>
> This is a good advice. I will use patman from now onwards to prepare and send 
> patches.
>
> >
> > > V2:
> > > - change (phydev && bus != NULL) to (phydev && bus)
> > > - after free phydev just pass NULL into wriop_set_phy_dev()
> > >
> > >  drivers/net/ldpaa_eth/ldpaa_eth.c   | 56 +++
> > >  drivers/net/ldpaa_eth/ldpaa_eth.h   |  1 -
> > >  drivers/net/ldpaa_eth/ldpaa_wriop.c |  2 +
> > >  include/fsl-mc/ldpaa_wriop.h|  1 -
> > >  4 files changed, 33 insertions(+), 27 deletions(-)
> > >
> > > diff --git a/drivers/net/ldpaa_eth/ldpaa_eth.c
> > > b/drivers/net/ldpaa_eth/ldpaa_eth.c
> > > index 82a684bea2..ca3459cc33 100644
> > > --- a/drivers/net/ldpaa_eth/ldpaa_eth.c
> > > +++ b/drivers/net/ldpaa_eth/ldpaa_eth.c
> > > @@ -35,7 +35,7 @@ static int init_phy(struct eth_device *dev)
> > > return -1;
> > > }
> > >
> > > -   priv->phydev = phydev;
> > > +   wriop_set_phy_dev(priv->dpmac_id, phydev);
> > >
> > > return phy_config(phydev);
> > >  }
> > > @@ -388,6 +388,7 @@ static int ldpaa_eth_open(struct eth_device
> > *net_dev, bd_t *bd)
> > > struct mii_dev *bus;
> > > phy_interface_t enet_if;
> > > struct dpni_queue d_queue;
> > > +   struct phy_device *phydev = NULL;
> > >
> > > if (net_dev->state == ETH_STATE_ACTIVE)
> > > return 0;
> > > @@ -408,38 +409,41 @@ static int ldpaa_eth_open(struct eth_device
> > *net_dev, bd_t *bd)
> > > 

[U-Boot] i2c: Fix pca953x endianess issue, commit daa75b34828d45b7c1d63009188d45f4a32d06ba

2018-10-10 Thread Joakim Tjernlund
This commit broke our pca953x usage(on ppc).

I wonder why gpio pins here has an endian, its not a number.
If there must be an endian connected with this, should it not
be a cpu_to_be16 instead, which will retain compatibility ?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] U-Boot SPL and LTO (armv7)

2018-10-10 Thread Adam Ford
I am wondering if anyone has done any tests using LTO in SPL?  For
those of us with limited resources, I noticed that we're creeping up
in size, especially when using DM in SPL.

I made a few attempts to enable -flto during compile, but the .S files
fail to assemble.  I found some references that indicating not to use
-flto when running the assembler, but we appear to be using CFLAGS for
assembly and I am not entirely sure how to apply -fno-lto to just the
assembly files.

I am focusing on ARMv7 right now, but if anyone has any suggestions or
have started something, on a different architecture, I'd like to
experiment a little.  I am not sure if the LTO will buy us much
anyway, but any little improvement during SPL would be appreciated.

thanks

adam
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH] sunxi: Imply fitImage support

2018-10-10 Thread Marek Vasut
Enable modern fitImage format on sunxi.

Signed-off-by: Marek Vasut 
Cc: Maxime Ripard 
Cc: Tom Rini 
---
 arch/arm/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 8a23c76db8..0f7829595a 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -834,6 +834,7 @@ config ARCH_SUNXI
imply CMD_UBI if NAND
imply DISTRO_DEFAULTS
imply FAT_WRITE
+   imply FIT
imply OF_LIBFDT_OVERLAY
imply PRE_CONSOLE_BUFFER
imply SPL_GPIO_SUPPORT
-- 
2.18.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 00/27] virtio: Introduce VirtIO driver support

2018-10-10 Thread Bin Meng
Hi Simon,

On Wed, Oct 10, 2018 at 12:20 AM Simon Glass  wrote:
>
> Hi Bin,
>
> On 4 October 2018 at 01:00, Bin Meng  wrote:
> > Hi Simon,
> >
> > On Tue, Oct 2, 2018 at 7:22 PM Simon Glass  wrote:
> >>
> >> Hi,
> >>
> >> On 27 September 2018 at 15:19, Tuomas Tynkkynen  
> >> wrote:
> >> > Hi Simon,
> >> >
> >> > On 09/27/2018 04:43 PM, Simon Glass wrote:
> >> > ...
> >> >>
> >> >>
> >> >> How does this all get tested? Could we have a simple sandbox driver?
> >> >>
> >> >
> >> > We can switch the Travis-CI jobs for the QEMU boards to use virtio-net
> >> > instead of the current network cards for the TFTP tests. I don't know
> >> > if there are pytest equivalents for block devices.
> >>
> >> We do actually have sandbox block devices and can add anything that is
> >> needed. While qemu is helpful, I much prefer tests that run with 'make
> >> tests'.
> >
> > I had a look at the testing on sandbox. It looks to me that we need
> > introduce a non-existent virtio transport sandbox emulator to support
> > this. I am not sure this is worth to do so. As Tuomas mentioned we can
> > setup travis-ci to test on qemu targets.
>
> I would like to have at least some basic testing of each uclass within
> U-Boot without relying on qemu, which after all is a much more
> complicated test. We have created simple sandbox drivers other
> uclasses and I don't see a good reason why virtio should be different?
> There are only 11 methods in the uclass so it should not be a huge
> amount of work to call each one. I certainly understand the burden of
> this, but I think it will pay off.
>

OK, will try to add a simple virtio sandbox driver to validate the API usage.

Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] debug uart: don't print before initialization

2018-10-10 Thread Simon Goldschmidt
+ Marek (as he commented on the original patch 
http://patchwork.ozlabs.org/patch/955765/)


On 09.10.2018 07:06, Simon Goldschmidt wrote:

On Tue, Oct 9, 2018 at 5:41 AM Simon Glass  wrote:

Hi,

On 7 October 2018 at 11:52, Simon Goldschmidt
 wrote:

At least on socfpga gen5, _debug_uart_putc() can be called
before debug_uart_init(), which leaves us stuck in an
infinite loop in the ns16550 debug uart driver.

Can you fix that? That is a bug.

I already posted a patch for that but it was rejected:
http://patchwork.ozlabs.org/patch/955765/


I'd have to add I still thing that that patch is good to fix this:
It checks that the baudrate divisor is set, which effectively is
an 'enable' bit for this hardware.

There were comments about the style (we can talk about that)
and Marek rejected it because he wanted a generic solution.
But honestly, given your idea that some platforms init the debug
uart before setting up gd, I don't think I can find a solution for
this.

So I'd really like to get my original patch applied (see above).

Simon



As patman automatically choses the CC addresses, you weren't
on the CC list back then, since that patch covered different filfes.


Simon


Since this prevents debugging startup problems instead
of helping, let's add a field to 'gd' that prevents
calling the _debug_uart_putc() until debug_uart_init()
has been called.

Signed-off-by: Simon Goldschmidt 
---

  include/asm-generic/global_data.h |  3 +++
  include/debug_uart.h  | 19 ++-
  2 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/include/asm-generic/global_data.h 
b/include/asm-generic/global_data.h
index c83fc01b76..9de7f48476 100644
--- a/include/asm-generic/global_data.h
+++ b/include/asm-generic/global_data.h
@@ -122,6 +122,9 @@ typedef struct global_data {
 struct list_head log_head;  /* List of struct log_device */
 int log_fmt;/* Mask containing log format info */
  #endif
+#ifdef CONFIG_DEBUG_UART
+   int debug_uart_initialized; /* No print before debug_uart_init */
+#endif

There is no requirement that gd be set up before the debug UART is
running. It certainly isn't on the few platforms I know about.

Regards,
Simon



___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH V3] mtd: uboot: Fix hanging during mtd list command

2018-10-10 Thread Miquel Raynal
Hi Jagan,

Jagan Teki  wrote on Wed, 10 Oct 2018
18:41:39 +0530:

> On Wed, Oct 10, 2018 at 6:39 PM Miquel Raynal  
> wrote:
> >
> > Hi Jagan,
> >
> > Jagan Teki  wrote on Wed, 10 Oct 2018
> > 11:32:02 +0530:
> >  
> > > On Tue, Oct 9, 2018 at 12:43 AM Adam Ford  wrote:  
> > > >
> > > > Some boards (like omap3_logic) hang when trying to access
> > > > address 0. This happens when executing the new 'mtd list' command.
> > > > This patch enhances the checks for conditions that would
> > > > preclude mtd_probe_devices() from operating.
> > > >
> > > > Fixes: 5db66b3aee6f ("cmd: mtd: add 'mtd' command")
> > > > Suggested-by: Boris Brezillon 
> > > > Signed-off-by: Adam Ford 
> > > > Reviewed-by: Boris Brezillon 
> > > > ---  
> > >
> > > Applied to u-boot-spi/master  
> >
> > Thanks for taking the patch but I wonder: shouldn't we apply this patch
> > sooner, ie. in the next -rc? Actually, it has barely nothing to do with
> > the SPI subsystem anyway.  
> 
> Yes, will send the PR soon.


Ok, no problem then. Thanks for carrying it.

Thanks,
Miquèl
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH V3] mtd: uboot: Fix hanging during mtd list command

2018-10-10 Thread Jagan Teki
On Wed, Oct 10, 2018 at 6:39 PM Miquel Raynal  wrote:
>
> Hi Jagan,
>
> Jagan Teki  wrote on Wed, 10 Oct 2018
> 11:32:02 +0530:
>
> > On Tue, Oct 9, 2018 at 12:43 AM Adam Ford  wrote:
> > >
> > > Some boards (like omap3_logic) hang when trying to access
> > > address 0. This happens when executing the new 'mtd list' command.
> > > This patch enhances the checks for conditions that would
> > > preclude mtd_probe_devices() from operating.
> > >
> > > Fixes: 5db66b3aee6f ("cmd: mtd: add 'mtd' command")
> > > Suggested-by: Boris Brezillon 
> > > Signed-off-by: Adam Ford 
> > > Reviewed-by: Boris Brezillon 
> > > ---
> >
> > Applied to u-boot-spi/master
>
> Thanks for taking the patch but I wonder: shouldn't we apply this patch
> sooner, ie. in the next -rc? Actually, it has barely nothing to do with
> the SPI subsystem anyway.

Yes, will send the PR soon.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH V3] mtd: uboot: Fix hanging during mtd list command

2018-10-10 Thread Miquel Raynal
Hi Jagan,

Jagan Teki  wrote on Wed, 10 Oct 2018
11:32:02 +0530:

> On Tue, Oct 9, 2018 at 12:43 AM Adam Ford  wrote:
> >
> > Some boards (like omap3_logic) hang when trying to access
> > address 0. This happens when executing the new 'mtd list' command.
> > This patch enhances the checks for conditions that would
> > preclude mtd_probe_devices() from operating.
> >
> > Fixes: 5db66b3aee6f ("cmd: mtd: add 'mtd' command")
> > Suggested-by: Boris Brezillon 
> > Signed-off-by: Adam Ford 
> > Reviewed-by: Boris Brezillon 
> > ---  
> 
> Applied to u-boot-spi/master

Thanks for taking the patch but I wonder: shouldn't we apply this patch
sooner, ie. in the next -rc? Actually, it has barely nothing to do with
the SPI subsystem anyway.


Thanks,
Miquèl
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v5] arm: socfpga: fix SPL booting from fpga OnChip RAM

2018-10-10 Thread Simon Goldschmidt
This patch prevents disabling the FPGA bridges when
SPL or U-Boot is executed from FPGA onchip RAM.

Signed-off-by: Simon Goldschmidt 
---

Changes in v5:
- changed inline function 'socfpga_is_fpga_slaves_addr(addr)'
  to 'socfpga_is_booting_from_fpga()'

Changes in v4:
- use an inline function in misc.h to check for the address
  range instead of a macro in base_addr_ac5.h

Changes in v3:
- use __image_copy_start to check if we are executing from FPGA

Changes in v2:
- use less ifdefs and more C code for address checks
  (but this gives a checkpatch warning because of comparing two
  upper case constants)
- changed comments

 arch/arm/mach-socfpga/include/mach/base_addr_ac5.h |  1 +
 arch/arm/mach-socfpga/include/mach/misc.h  |  9 +
 arch/arm/mach-socfpga/misc_gen5.c  |  9 -
 arch/arm/mach-socfpga/spl_gen5.c   | 10 +++---
 4 files changed, 25 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-socfpga/include/mach/base_addr_ac5.h 
b/arch/arm/mach-socfpga/include/mach/base_addr_ac5.h
index bb9e3faa29..2725e9fcc3 100644
--- a/arch/arm/mach-socfpga/include/mach/base_addr_ac5.h
+++ b/arch/arm/mach-socfpga/include/mach/base_addr_ac5.h
@@ -6,6 +6,7 @@
 #ifndef _SOCFPGA_BASE_ADDRS_H_
 #define _SOCFPGA_BASE_ADDRS_H_
 
+#define SOCFPGA_FPGA_SLAVES_ADDRESS0xc000
 #define SOCFPGA_STM_ADDRESS0xfc00
 #define SOCFPGA_DAP_ADDRESS0xff00
 #define SOCFPGA_EMAC0_ADDRESS  0xff70
diff --git a/arch/arm/mach-socfpga/include/mach/misc.h 
b/arch/arm/mach-socfpga/include/mach/misc.h
index 4fc9570a04..26609927c8 100644
--- a/arch/arm/mach-socfpga/include/mach/misc.h
+++ b/arch/arm/mach-socfpga/include/mach/misc.h
@@ -6,6 +6,8 @@
 #ifndef _MISC_H_
 #define _MISC_H_
 
+#include 
+
 void dwmac_deassert_reset(const unsigned int of_reset_id, const u32 phymode);
 
 struct bsel {
@@ -23,6 +25,13 @@ static inline void socfpga_fpga_add(void) {}
 
 #ifdef CONFIG_TARGET_SOCFPGA_GEN5
 void socfpga_sdram_remap_zero(void);
+static inline bool socfpga_is_booting_from_fpga(void)
+{
+   if ((__image_copy_start >= (char *)SOCFPGA_FPGA_SLAVES_ADDRESS) &&
+   (__image_copy_start < (char *)SOCFPGA_STM_ADDRESS))
+   return true;
+   return false;
+}
 #endif
 
 #ifdef CONFIG_TARGET_SOCFPGA_ARRIA10
diff --git a/arch/arm/mach-socfpga/misc_gen5.c 
b/arch/arm/mach-socfpga/misc_gen5.c
index 429c3d6cd5..5fa40937c4 100644
--- a/arch/arm/mach-socfpga/misc_gen5.c
+++ b/arch/arm/mach-socfpga/misc_gen5.c
@@ -177,6 +177,8 @@ static void socfpga_nic301_slave_ns(void)
 
 void socfpga_sdram_remap_zero(void)
 {
+   u32 remap;
+
socfpga_nic301_slave_ns();
 
/*
@@ -187,7 +189,12 @@ void socfpga_sdram_remap_zero(void)
setbits_le32(_regs->sacr, 0xfff);
 
/* Configure the L2 controller to make SDRAM start at 0 */
-   writel(0x1, _regs->remap);   /* remap.mpuzero */
+   remap = 0x1; /* remap.mpuzero */
+   /* Keep fpga bridge enabled when running from FPGA onchip RAM */
+   if (socfpga_is_booting_from_fpga())
+   remap |= 0x8; /* remap.hps2fpga */
+   writel(remap, _regs->remap);
+
writel(0x1, >pl310_addr_filter_start);
 }
 
diff --git a/arch/arm/mach-socfpga/spl_gen5.c b/arch/arm/mach-socfpga/spl_gen5.c
index be318cc0d9..ccdc661d05 100644
--- a/arch/arm/mach-socfpga/spl_gen5.c
+++ b/arch/arm/mach-socfpga/spl_gen5.c
@@ -92,8 +92,11 @@ void board_init_f(ulong dummy)
 
/* Put everything into reset but L4WD0. */
socfpga_per_reset_all();
-   /* Put FPGA bridges into reset too. */
-   socfpga_bridges_reset(1);
+
+   if (!socfpga_is_booting_from_fpga()) {
+   /* Put FPGA bridges into reset too. */
+   socfpga_bridges_reset(1);
+   }
 
socfpga_per_reset(SOCFPGA_RESET(SDR), 0);
socfpga_per_reset(SOCFPGA_RESET(UART0), 0);
@@ -163,5 +166,6 @@ void board_init_f(ulong dummy)
hang();
}
 
-   socfpga_bridges_reset(1);
+   if (!socfpga_is_booting_from_fpga())
+   socfpga_bridges_reset(1);
 }
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 2/3] spi: Add support for the Aspeed ast2500 SPI controllers

2018-10-10 Thread Cédric Le Goater
Hello Boris,

On 10/10/18 9:32 AM, Boris Brezillon wrote:
> Hi Cédric,
> 
> On Wed, 10 Oct 2018 11:46:56 +0530
> Jagan Teki  wrote:
> 
>> On Mon, Oct 8, 2018 at 11:32 AM Cédric Le Goater  wrote:
>>>
>>> On 10/4/18 5:57 PM, Jagan Teki wrote:  
 On Fri, Sep 28, 2018 at 5:20 PM Cédric Le Goater  wrote:  
>
> Hello Simon,
>
>
> The Aspeed AST2500 FMC controller can handle SPI flash and NOR flash 
> memory,
> and the Aspeed AST2500 SPI Flash Controllers only SPI. If there is some
> misunderstanding on this driver, it might come from the fact it is closer
> to a SPI-NOR driver like we have in Linux, than a generic SPI driver.
> The stm32 SPI driver is somewhat similar.
>
> Should we move it under drivers/mtd/spi/ maybe ?  

 Seems with new spi-mem in Linux flash memory driver rely on spi-mem
 instead of mtd/spi-nor. So I think you can handle this via new
 spi-mem. have you send any patches to Linux?  
>>>
>>> No, not yet. The patchset is sent  :
>>>
>>> https://patchwork.ozlabs.org/cover/933293/
>>>
>>> is not using spimem. I was not aware of that change in the spi-nor layer
>>> at the time. I will take a look.  
> 
> Indeed, if you have some time to convert the Linux aspeed driver to
> the spi-mem interface that would be appreciated.

Yes. That's the plan. I have a series on the way but I will see if I can
rework a v2 to use spi-mem. 

Same for the u-boot aspeed spi driver which needs a spi-mem refresh if 
I understand correctly. 

Thanks,

C.

 
>>
>> Yes, but for newly added drivers. added spi-mem guys, may be they can 
>> comment.
> 
> Jagan, what's the plan for the spi-nor layer in u-boot? I mean, spi-mem
> is just the controller side of things, but it requires spi-mem drivers
> to support specific SPI memories. We added the spi-nand driver, but
> AFAICT, the spi-nor driver does not exist yet. There's the spi-flash
> layer already, but IIUC you were trying to replace it by a spi-nor
> framework.
> 
> I see 2 options here:
> 
> 1/ copy the spi-nor framework from linux and adjust it to make it work
>in uboot
> 2/ create a spi-nor driver which interfaces directly with the spi-mem
>layer
> 
> I know I usually recommend going for #1, but it might be a bit
> different this time around since I'm trying to get rid of the
> spi_nor interface in Linux (the one that allows people to implement
> spi-nor controller drivers) in favor of a native spi-mem driver. So
> I think it's worth considering option #2.
> 

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v3 12/13] aspeed: Activate ethernet devices on the ast2500 Eval Board

2018-10-10 Thread Cédric Le Goater
Signed-off-by: Cédric Le Goater 
Reviewed-by: Simon Glass 
---
 arch/arm/dts/ast2500-evb.dts | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/arch/arm/dts/ast2500-evb.dts b/arch/arm/dts/ast2500-evb.dts
index 723941ac0bee..ebf44fd707f9 100644
--- a/arch/arm/dts/ast2500-evb.dts
+++ b/arch/arm/dts/ast2500-evb.dts
@@ -11,6 +11,11 @@
chosen {
stdout-path = 
};
+
+   aliases {
+   ethernet0 = 
+   ethernet1 = 
+   };
 };
 
  {
@@ -36,3 +41,21 @@
u-boot,dm-pre-reloc;
status = "okay";
 };
+
+ {
+   status = "okay";
+
+   phy-mode = "rgmii";
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_mac1link_default _mdio1_default>;
+};
+
+ {
+   status = "okay";
+
+   phy-mode = "rgmii";
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_mac2link_default _mdio2_default>;
+};
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v3 10/13] net: ftgmac100: Add support for the Aspeed SoC

2018-10-10 Thread Cédric Le Goater
The Faraday ftgmac100 MAC controllers as found on the Aspeed SoCs have
some slight differences in the HW interface (End-Of-Rx/Tx-Ring bits).

Signed-off-by: Cédric Le Goater 
Reviewed-by: Simon Glass 
---
 drivers/net/ftgmac100.c   | 31 +++
 configs/evb-ast2500_defconfig |  8 
 2 files changed, 35 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ftgmac100.c b/drivers/net/ftgmac100.c
index a5f2f01b7179..fb081769c9a4 100644
--- a/drivers/net/ftgmac100.c
+++ b/drivers/net/ftgmac100.c
@@ -42,6 +42,14 @@
  */
 #define MDC_CYCTHR 0x34
 
+/*
+ * ftgmac100 model variants
+ */
+enum ftgmac100_model {
+   FTGMAC100_MODEL_FARADAY,
+   FTGMAC100_MODEL_ASPEED,
+};
+
 /**
  * struct ftgmac100_data - private data for the FTGMAC100 driver
  *
@@ -56,6 +64,8 @@
  * @phy_mode: The mode of the PHY interface (rgmii, rmii, ...)
  * @max_speed: Maximum speed of Ethernet connection supported by MAC
  * @clks: The bulk of clocks assigned to the device in the DT
+ * @rxdes0_edorr_mask: The bit number identifying the end of the RX ring buffer
+ * @txdes0_edotr_mask: The bit number identifying the end of the TX ring buffer
  */
 struct ftgmac100_data {
struct ftgmac100 *iobase;
@@ -72,6 +82,10 @@ struct ftgmac100_data {
u32 max_speed;
 
struct clk_bulk clks;
+
+   /* End of RX/TX ring buffer bits. Depend on model */
+   u32 rxdes0_edorr_mask;
+   u32 txdes0_edotr_mask;
 };
 
 /*
@@ -290,7 +304,7 @@ static int ftgmac100_start(struct udevice *dev)
priv->txdes[i].txdes3 = 0;
priv->txdes[i].txdes0 = 0;
}
-   priv->txdes[PKTBUFSTX - 1].txdes0 = FTGMAC100_TXDES0_EDOTR;
+   priv->txdes[PKTBUFSTX - 1].txdes0 = priv->txdes0_edotr_mask;
 
start = (ulong)>txdes[0];
end = start + roundup(sizeof(priv->txdes), ARCH_DMA_MINALIGN);
@@ -300,7 +314,7 @@ static int ftgmac100_start(struct udevice *dev)
priv->rxdes[i].rxdes3 = (unsigned int)net_rx_packets[i];
priv->rxdes[i].rxdes0 = 0;
}
-   priv->rxdes[PKTBUFSRX - 1].rxdes0 = FTGMAC100_RXDES0_EDORR;
+   priv->rxdes[PKTBUFSRX - 1].rxdes0 = priv->rxdes0_edorr_mask;
 
start = (ulong)>rxdes[0];
end = start + roundup(sizeof(priv->rxdes), ARCH_DMA_MINALIGN);
@@ -440,7 +454,7 @@ static int ftgmac100_send(struct udevice *dev, void 
*packet, int length)
flush_dcache_range(data_start, data_end);
 
/* Only one segment on TXBUF */
-   curr_des->txdes0 &= FTGMAC100_TXDES0_EDOTR;
+   curr_des->txdes0 &= priv->txdes0_edotr_mask;
curr_des->txdes0 |= FTGMAC100_TXDES0_FTS |
FTGMAC100_TXDES0_LTS |
FTGMAC100_TXDES0_TXBUF_SIZE(length) |
@@ -500,6 +514,14 @@ static int ftgmac100_ofdata_to_platdata(struct udevice 
*dev)
 
pdata->max_speed = dev_read_u32_default(dev, "max-speed", 0);
 
+   if (dev_get_driver_data(dev) == FTGMAC100_MODEL_ASPEED) {
+   priv->rxdes0_edorr_mask = BIT(30);
+   priv->txdes0_edotr_mask = BIT(30);
+   } else {
+   priv->rxdes0_edorr_mask = BIT(15);
+   priv->txdes0_edotr_mask = BIT(15);
+   }
+
return clk_get_bulk(dev, >clks);
 }
 
@@ -559,7 +581,8 @@ static const struct eth_ops ftgmac100_ops = {
 };
 
 static const struct udevice_id ftgmac100_ids[] = {
-   { .compatible = "faraday,ftgmac100" },
+   { .compatible = "faraday,ftgmac100",  .data = FTGMAC100_MODEL_FARADAY },
+   { .compatible = "aspeed,ast2500-mac", .data = FTGMAC100_MODEL_ASPEED  },
{ }
 };
 
diff --git a/configs/evb-ast2500_defconfig b/configs/evb-ast2500_defconfig
index 88230f4a12db..32581f5ada54 100644
--- a/configs/evb-ast2500_defconfig
+++ b/configs/evb-ast2500_defconfig
@@ -25,3 +25,11 @@ CONFIG_SYS_NS16550=y
 CONFIG_SYSRESET=y
 CONFIG_TIMER=y
 CONFIG_WDT=y
+CONFIG_NETDEVICES=y
+CONFIG_PHY=y
+CONFIG_DM_ETH=y
+CONFIG_FTGMAC100=y
+CONFIG_PHY_REALTEK=y
+CONFIG_CMD_PING=y
+CONFIG_CMD_DHCP=y
+CONFIG_CMD_MII=y
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v3 11/13] aspeed: Update ast2500 SoC DTS file to Linux v4.17-rc6 level

2018-10-10 Thread Cédric Le Goater
This is a large update of the AST2500 SoC DTS file bringing it to the
level of commit 927c2fc2db19 :

Author:  Joel Stanley 
Date:Sat Jun 2 01:18:53 2018 -0700

 ARM: dts: aspeed: Fix hwrng register address

There are some differences on the compatibility property names. scu,
reset and clock drivers are also different.

Signed-off-by: Cédric Le Goater 
Reviewed-by: Joel Stanley 
Reviewed-by: Simon Glass 
---

 Changes since v2 :

 - removed a couple more unused clock properties

 arch/arm/dts/ast2500.dtsi | 1949 ++---
 1 file changed, 1153 insertions(+), 796 deletions(-)

diff --git a/arch/arm/dts/ast2500.dtsi b/arch/arm/dts/ast2500.dtsi
index 7e0ad3a41ac5..98359bf92425 100644
--- a/arch/arm/dts/ast2500.dtsi
+++ b/arch/arm/dts/ast2500.dtsi
@@ -11,6 +11,29 @@
#size-cells = <1>;
interrupt-parent = <>;
 
+   aliases {
+   i2c0 = 
+   i2c1 = 
+   i2c2 = 
+   i2c3 = 
+   i2c4 = 
+   i2c5 = 
+   i2c6 = 
+   i2c7 = 
+   i2c8 = 
+   i2c9 = 
+   i2c10 = 
+   i2c11 = 
+   i2c12 = 
+   i2c13 = 
+   serial0 = 
+   serial1 = 
+   serial2 = 
+   serial3 = 
+   serial4 = 
+   serial5 = 
+   };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
@@ -22,12 +45,80 @@
};
};
 
+   memory@8000 {
+   device_type = "memory";
+   reg = <0x8000 0>;
+   };
+
ahb {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges;
 
+   fmc: flash-controller@1e62 {
+   reg = < 0x1e62 0xc4
+   0x2000 0x1000 >;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "aspeed,ast2500-fmc";
+   status = "disabled";
+   interrupts = <19>;
+   flash@0 {
+   reg = < 0 >;
+   compatible = "jedec,spi-nor";
+   status = "disabled";
+   };
+   flash@1 {
+   reg = < 1 >;
+   compatible = "jedec,spi-nor";
+   status = "disabled";
+   };
+   flash@2 {
+   reg = < 2 >;
+   compatible = "jedec,spi-nor";
+   status = "disabled";
+   };
+   };
+
+   spi1: flash-controller@1e63 {
+   reg = < 0x1e63 0xc4
+   0x3000 0x0800 >;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "aspeed,ast2500-spi";
+   status = "disabled";
+   flash@0 {
+   reg = < 0 >;
+   compatible = "jedec,spi-nor";
+   status = "disabled";
+   };
+   flash@1 {
+   reg = < 1 >;
+   compatible = "jedec,spi-nor";
+   status = "disabled";
+   };
+   };
+
+   spi2: flash-controller@1e631000 {
+   reg = < 0x1e631000 0xc4
+   0x3800 0x0800 >;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "aspeed,ast2500-spi";
+   status = "disabled";
+   flash@0 {
+   reg = < 0 >;
+   compatible = "jedec,spi-nor";
+   status = "disabled";
+   };
+   flash@1 {
+   reg = < 1 >;
+   compatible = "jedec,spi-nor";
+   status = "disabled";
+   };
+   };
+
vic: interrupt-controller@1e6c0080 {
compatible = "aspeed,ast2400-vic";
interrupt-controller;
@@ -37,18 +128,38 @@
};
 
mac0: ethernet@1e66 {
-   compatible = "faraday,ftgmac100";
+   compatible = "aspeed,ast2500-mac", "faraday,ftgmac100";
reg = <0x1e66 0x180>;
interrupts = <2>;
-   

[U-Boot] [PATCH v3 04/13] net: ftgmac100: use setbits_le32() in the reset method

2018-10-10 Thread Cédric Le Goater
Signed-off-by: Cédric Le Goater 
---
 drivers/net/ftgmac100.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ftgmac100.c b/drivers/net/ftgmac100.c
index 67a7c73503c5..78cd9df62986 100644
--- a/drivers/net/ftgmac100.c
+++ b/drivers/net/ftgmac100.c
@@ -331,7 +331,7 @@ static void ftgmac100_reset(struct ftgmac100_data *priv)
 
debug("%s()\n", __func__);
 
-   writel(FTGMAC100_MACCR_SW_RST, >maccr);
+   setbits_le32(>maccr, FTGMAC100_MACCR_SW_RST);
 
while (readl(>maccr) & FTGMAC100_MACCR_SW_RST)
;
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v3 08/13] net: ftgmac100: add clock support

2018-10-10 Thread Cédric Le Goater
Signed-off-by: Cédric Le Goater 
---
 drivers/net/ftgmac100.c | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ftgmac100.c b/drivers/net/ftgmac100.c
index edf34c601c68..a5f2f01b7179 100644
--- a/drivers/net/ftgmac100.c
+++ b/drivers/net/ftgmac100.c
@@ -11,6 +11,7 @@
  * Copyright (C) 2018, IBM Corporation.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -54,6 +55,7 @@
  * @bus: The mdio bus
  * @phy_mode: The mode of the PHY interface (rgmii, rmii, ...)
  * @max_speed: Maximum speed of Ethernet connection supported by MAC
+ * @clks: The bulk of clocks assigned to the device in the DT
  */
 struct ftgmac100_data {
struct ftgmac100 *iobase;
@@ -68,6 +70,8 @@ struct ftgmac100_data {
struct mii_dev *bus;
u32 phy_mode;
u32 max_speed;
+
+   struct clk_bulk clks;
 };
 
 /*
@@ -481,6 +485,7 @@ static int ftgmac100_write_hwaddr(struct udevice *dev)
 static int ftgmac100_ofdata_to_platdata(struct udevice *dev)
 {
struct eth_pdata *pdata = dev_get_platdata(dev);
+   struct ftgmac100_data *priv = dev_get_priv(dev);
const char *phy_mode;
 
pdata->iobase = devfdt_get_addr(dev);
@@ -495,7 +500,7 @@ static int ftgmac100_ofdata_to_platdata(struct udevice *dev)
 
pdata->max_speed = dev_read_u32_default(dev, "max-speed", 0);
 
-   return 0;
+   return clk_get_bulk(dev, >clks);
 }
 
 static int ftgmac100_probe(struct udevice *dev)
@@ -509,6 +514,10 @@ static int ftgmac100_probe(struct udevice *dev)
priv->max_speed = pdata->max_speed;
priv->phy_addr = 0;
 
+   ret = clk_enable_bulk(>clks);
+   if (ret)
+   goto out;
+
ret = ftgmac100_mdio_init(priv, dev->seq);
if (ret) {
dev_err(dev, "Failed to initialize mdiobus: %d\n", ret);
@@ -522,6 +531,9 @@ static int ftgmac100_probe(struct udevice *dev)
}
 
 out:
+   if (ret)
+   clk_release_bulk(>clks);
+
return ret;
 }
 
@@ -532,6 +544,7 @@ static int ftgmac100_remove(struct udevice *dev)
free(priv->phydev);
mdio_unregister(priv->bus);
mdio_free(priv->bus);
+   clk_release_bulk(>clks);
 
return 0;
 }
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v3 07/13] net: ftgmac100: handle timeouts when transmitting

2018-10-10 Thread Cédric Le Goater
Signed-off-by: Cédric Le Goater 
---
 drivers/net/ftgmac100.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/drivers/net/ftgmac100.c b/drivers/net/ftgmac100.c
index b46187b567c6..edf34c601c68 100644
--- a/drivers/net/ftgmac100.c
+++ b/drivers/net/ftgmac100.c
@@ -28,6 +28,9 @@
 /* PKTBUFSTX/PKTBUFSRX must both be power of 2 */
 #define PKTBUFSTX  4   /* must be power of 2 */
 
+/* Timeout for transmit */
+#define FTGMAC100_TX_TIMEOUT_MS1000
+
 /* Timeout for a mdio read/write operation */
 #define FTGMAC100_MDIO_TIMEOUT_USEC1
 
@@ -412,6 +415,7 @@ static int ftgmac100_send(struct udevice *dev, void 
*packet, int length)
roundup(sizeof(*curr_des), ARCH_DMA_MINALIGN);
ulong data_start;
ulong data_end;
+   ulong start;
 
invalidate_dcache_range(des_start, des_end);
 
@@ -444,6 +448,20 @@ static int ftgmac100_send(struct udevice *dev, void 
*packet, int length)
/* Start transmit */
writel(1, >txpd);
 
+   /* Wait until packet is transmitted */
+   start = get_timer(0);
+   while (get_timer(start) < FTGMAC100_TX_TIMEOUT_MS) {
+   invalidate_dcache_range(des_start, des_end);
+   if (!(curr_des->txdes0 & FTGMAC100_TXDES0_TXDMA_OWN))
+   break;
+   udelay(10);
+   }
+
+   if (get_timer(start) >= FTGMAC100_TX_TIMEOUT_MS) {
+   dev_err(dev, "transmit timeout\n");
+   return -ETIMEDOUT;
+   }
+
debug("%s(): packet sent\n", __func__);
 
/* Move to next descriptor */
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v3 06/13] net: ftgmac100: convert the RX/TX descriptor arrays

2018-10-10 Thread Cédric Le Goater
Use simple arrays under the device priv structure to hold the RX and
TX descriptors and handle memory coherency by invalidating or flushing
the d-cache when required.

Signed-off-by: Cédric Le Goater 
---

 At this stage, the drive is functional.
 
 drivers/net/ftgmac100.c | 141 ++--
 1 file changed, 64 insertions(+), 77 deletions(-)

diff --git a/drivers/net/ftgmac100.c b/drivers/net/ftgmac100.c
index 1929e9510c26..b46187b567c6 100644
--- a/drivers/net/ftgmac100.c
+++ b/drivers/net/ftgmac100.c
@@ -13,19 +13,17 @@
 
 #include 
 #include 
-#include 
 #include 
 #include 
-#include 
 #include 
 
 #include "ftgmac100.h"
 
-#define ETH_ZLEN   60
-#define CFG_XBUF_SIZE  1536
+/* Min frame ethernet frame size without FCS */
+#define ETH_ZLEN   60
 
-/* RBSR - hw default init value is also 0x640 */
-#define RBSR_DEFAULT_VALUE 0x640
+/* Receive Buffer Size Register - HW default is 0x640 */
+#define FTGMAC100_RBSR_DEFAULT 0x640
 
 /* PKTBUFSTX/PKTBUFSRX must both be power of 2 */
 #define PKTBUFSTX  4   /* must be power of 2 */
@@ -57,10 +55,8 @@
 struct ftgmac100_data {
struct ftgmac100 *iobase;
 
-   ulong txdes_dma;
-   struct ftgmac100_txdes *txdes;
-   ulong rxdes_dma;
-   struct ftgmac100_rxdes *rxdes;
+   struct ftgmac100_txdes txdes[PKTBUFSTX];
+   struct ftgmac100_rxdes rxdes[PKTBUFSRX];
int tx_index;
int rx_index;
 
@@ -264,10 +260,8 @@ static int ftgmac100_start(struct udevice *dev)
struct ftgmac100_data *priv = dev_get_priv(dev);
struct ftgmac100 *ftgmac100 = priv->iobase;
struct phy_device *phydev = priv->phydev;
-   struct ftgmac100_txdes *txdes;
-   struct ftgmac100_rxdes *rxdes;
unsigned int maccr;
-   void *buf;
+   ulong start, end;
int ret;
int i;
 
@@ -275,26 +269,6 @@ static int ftgmac100_start(struct udevice *dev)
 
ftgmac100_reset(priv);
 
-   if (!priv->txdes) {
-   txdes = dma_alloc_coherent(
-   sizeof(*txdes) * PKTBUFSTX, >txdes_dma);
-   if (!txdes)
-   panic("ftgmac100: out of memory\n");
-   memset(txdes, 0, sizeof(*txdes) * PKTBUFSTX);
-   priv->txdes = txdes;
-   }
-   txdes = priv->txdes;
-
-   if (!priv->rxdes) {
-   rxdes = dma_alloc_coherent(
-   sizeof(*rxdes) * PKTBUFSRX, >rxdes_dma);
-   if (!rxdes)
-   panic("ftgmac100: out of memory\n");
-   memset(rxdes, 0, sizeof(*rxdes) * PKTBUFSRX);
-   priv->rxdes = rxdes;
-   }
-   rxdes = priv->rxdes;
-
/* set the ethernet address */
ftgmac100_set_mac(priv, plat->enetaddr);
 
@@ -305,42 +279,37 @@ static int ftgmac100_start(struct udevice *dev)
priv->tx_index = 0;
priv->rx_index = 0;
 
-   txdes[PKTBUFSTX - 1].txdes0 = FTGMAC100_TXDES0_EDOTR;
-   rxdes[PKTBUFSRX - 1].rxdes0 = FTGMAC100_RXDES0_EDORR;
-
for (i = 0; i < PKTBUFSTX; i++) {
-   /* TXBUF_BADR */
-   if (!txdes[i].txdes2) {
-   buf = memalign(ARCH_DMA_MINALIGN, CFG_XBUF_SIZE);
-   if (!buf)
-   panic("ftgmac100: out of memory\n");
-   txdes[i].txdes3 = virt_to_phys(buf);
-   txdes[i].txdes2 = (uint)buf;
-   }
-   txdes[i].txdes1 = 0;
+   priv->txdes[i].txdes3 = 0;
+   priv->txdes[i].txdes0 = 0;
}
+   priv->txdes[PKTBUFSTX - 1].txdes0 = FTGMAC100_TXDES0_EDOTR;
+
+   start = (ulong)>txdes[0];
+   end = start + roundup(sizeof(priv->txdes), ARCH_DMA_MINALIGN);
+   flush_dcache_range(start, end);
 
for (i = 0; i < PKTBUFSRX; i++) {
-   /* RXBUF_BADR */
-   if (!rxdes[i].rxdes2) {
-   buf = net_rx_packets[i];
-   rxdes[i].rxdes3 = virt_to_phys(buf);
-   rxdes[i].rxdes2 = (uint)buf;
-   }
-   rxdes[i].rxdes0 &= ~FTGMAC100_RXDES0_RXPKT_RDY;
+   priv->rxdes[i].rxdes3 = (unsigned int)net_rx_packets[i];
+   priv->rxdes[i].rxdes0 = 0;
}
+   priv->rxdes[PKTBUFSRX - 1].rxdes0 = FTGMAC100_RXDES0_EDORR;
+
+   start = (ulong)>rxdes[0];
+   end = start + roundup(sizeof(priv->rxdes), ARCH_DMA_MINALIGN);
+   flush_dcache_range(start, end);
 
/* transmit ring */
-   writel(priv->txdes_dma, >txr_badr);
+   writel((u32)priv->txdes, >txr_badr);
 
/* receive ring */
-   writel(priv->rxdes_dma, >rxr_badr);
+   writel((u32)priv->rxdes, >rxr_badr);
 
/* poll receive descriptor automatically */
writel(FTGMAC100_APTC_RXPOLL_CNT(1), >aptc);
 
/* config receive buffer size register */
-   writel(FTGMAC100_RBSR_SIZE(RBSR_DEFAULT_VALUE), 

[U-Boot] [PATCH v3 09/13] aspeed: ast2500: fix missing break in D2PLL clock enablement

2018-10-10 Thread Cédric Le Goater
Signed-off-by: Cédric Le Goater 
Reviewed-by: Joel Stanley 
Reviewed-by: Simon Glass 
---
 drivers/clk/aspeed/clk_ast2500.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/aspeed/clk_ast2500.c b/drivers/clk/aspeed/clk_ast2500.c
index 526470051c5d..2182320f607f 100644
--- a/drivers/clk/aspeed/clk_ast2500.c
+++ b/drivers/clk/aspeed/clk_ast2500.c
@@ -411,6 +411,7 @@ static int ast2500_clk_enable(struct clk *clk)
break;
case PLL_D2PLL:
ast2500_configure_d2pll(priv->scu, D2PLL_DEFAULT_RATE);
+   break;
default:
return -ENOENT;
}
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v3 13/13] aspeed: ast2500: fix D2-PLL clock setting in RGMII mode

2018-10-10 Thread Cédric Le Goater
The algorithm in the ast2500_calc_clock_config() routine suffers from
integer rounding and the requested rate does not get the appropriate
set of Numerator, Denumerator, Post Divider parameters.

This is the case for the D2-PLL clock used by the MAC controllers in
RGMII mode. The requested rated is 250MHz but a 251MHz is assigned.

The easiest way to fix this problem is to introduce an array of clock
settings defining the N, M, P parameters for well known frequencies
used by the Aspeed SoC.

Signed-off-by: Cédric Le Goater 
Reviewed-by: Simon Glass 
---
 drivers/clk/aspeed/clk_ast2500.c | 38 
 1 file changed, 38 insertions(+)

diff --git a/drivers/clk/aspeed/clk_ast2500.c b/drivers/clk/aspeed/clk_ast2500.c
index 2182320f607f..dbee13a18297 100644
--- a/drivers/clk/aspeed/clk_ast2500.c
+++ b/drivers/clk/aspeed/clk_ast2500.c
@@ -165,6 +165,35 @@ static ulong ast2500_clk_get_rate(struct clk *clk)
return rate;
 }
 
+struct ast2500_clock_config {
+   ulong input_rate;
+   ulong rate;
+   struct ast2500_div_config cfg;
+};
+
+static const struct ast2500_clock_config ast2500_clock_config_defaults[] = {
+   { 2400, 25000, { .num = 124, .denum = 1, .post_div = 5 } },
+};
+
+static bool ast2500_get_clock_config_default(ulong input_rate,
+ulong requested_rate,
+struct ast2500_div_config *cfg)
+{
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(ast2500_clock_config_defaults); i++) {
+   const struct ast2500_clock_config *default_cfg =
+   _clock_config_defaults[i];
+   if (default_cfg->input_rate == input_rate &&
+   default_cfg->rate == requested_rate) {
+   *cfg = default_cfg->cfg;
+   return true;
+   }
+   }
+
+   return false;
+}
+
 /*
  * @input_rate - the rate of input clock in Hz
  * @requested_rate - desired output rate in Hz
@@ -189,6 +218,12 @@ static ulong ast2500_calc_clock_config(ulong input_rate, 
ulong requested_rate,
ulong delta = rate_khz;
ulong new_rate_khz = 0;
 
+   /*
+* Look for a well known frequency first.
+*/
+   if (ast2500_get_clock_config_default(input_rate, requested_rate, cfg))
+   return requested_rate;
+
for (; it.denum <= max_vals.denum; ++it.denum) {
for (it.post_div = 0; it.post_div <= max_vals.post_div;
 ++it.post_div) {
@@ -318,6 +353,9 @@ static ulong ast2500_configure_d2pll(struct ast2500_scu 
*scu, ulong rate)
/*
 * The values and the meaning of the next three
 * parameters are undocumented. Taken from Aspeed SDK.
+*
+* TODO(c...@kaod.org): the SIP and SIC values depend on the
+* Numerator value
 */
const u32 d2_pll_ext_param = 0x2c;
const u32 d2_pll_sip = 0x11;
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v3 03/13] net: ftgmac100: convert to driver model

2018-10-10 Thread Cédric Le Goater
The driver is based on the previous one and the code is only adapted
to fit the driver model. The support for the Faraday ftgmac100
controller is the same with MAC and MDIO bus support for RGMII/RMII
modes.

Configuration is updated to enable compile again. At this stage, the
driver compiles but is not yet functional.

Signed-off-by: Cédric Le Goater 
---
 include/netdev.h|   1 -
 drivers/net/ftgmac100.c | 223 +++-
 drivers/net/Kconfig |  26 +
 3 files changed, 157 insertions(+), 93 deletions(-)

diff --git a/include/netdev.h b/include/netdev.h
index 55001625fb92..0a1a3a2d8da2 100644
--- a/include/netdev.h
+++ b/include/netdev.h
@@ -43,7 +43,6 @@ int ethoc_initialize(u8 dev_num, int base_addr);
 int fec_initialize (bd_t *bis);
 int fecmxc_initialize(bd_t *bis);
 int fecmxc_initialize_multi(bd_t *bis, int dev_id, int phy_id, uint32_t addr);
-int ftgmac100_initialize(bd_t *bits);
 int ftmac100_initialize(bd_t *bits);
 int ftmac110_initialize(bd_t *bits);
 void gt6426x_eth_initialize(bd_t *bis);
diff --git a/drivers/net/ftgmac100.c b/drivers/net/ftgmac100.c
index c996f5f4a167..67a7c73503c5 100644
--- a/drivers/net/ftgmac100.c
+++ b/drivers/net/ftgmac100.c
@@ -7,15 +7,16 @@
  *
  * (C) Copyright 2010 Andes Technology
  * Macpaul Lin 
+ *
+ * Copyright (C) 2018, IBM Corporation.
  */
 
-#include 
-#include 
+#include 
+#include 
 #include 
 #include 
-#include 
+#include 
 #include 
-#include 
 
 #include "ftgmac100.h"
 
@@ -28,7 +29,19 @@
 /* PKTBUFSTX/PKTBUFSRX must both be power of 2 */
 #define PKTBUFSTX  4   /* must be power of 2 */
 
+/**
+ * struct ftgmac100_data - private data for the FTGMAC100 driver
+ *
+ * @iobase: The base address of the hardware registers
+ * @txdes: The array of transmit descriptors
+ * @rxdes: The array of receive descriptors
+ * @tx_index: Transmit descriptor index in @txdes
+ * @rx_index: Receive descriptor index in @rxdes
+ * @phy_addr: The PHY interface address to use
+ */
 struct ftgmac100_data {
+   struct ftgmac100 *iobase;
+
ulong txdes_dma;
struct ftgmac100_txdes *txdes;
ulong rxdes_dma;
@@ -41,10 +54,10 @@ struct ftgmac100_data {
 /*
  * struct mii_bus functions
  */
-static int ftgmac100_mdiobus_read(struct eth_device *dev, int phy_addr,
-   int regnum)
+static int ftgmac100_mdiobus_read(struct ftgmac100_data *priv, int phy_addr,
+ int regnum)
 {
-   struct ftgmac100 *ftgmac100 = (struct ftgmac100 *)dev->iobase;
+   struct ftgmac100 *ftgmac100 = priv->iobase;
int phycr;
int i;
 
@@ -76,10 +89,10 @@ static int ftgmac100_mdiobus_read(struct eth_device *dev, 
int phy_addr,
return -1;
 }
 
-static int ftgmac100_mdiobus_write(struct eth_device *dev, int phy_addr,
-   int regnum, u16 value)
+static int ftgmac100_mdiobus_write(struct ftgmac100_data *priv, int phy_addr,
+  int regnum, u16 value)
 {
-   struct ftgmac100 *ftgmac100 = (struct ftgmac100 *)dev->iobase;
+   struct ftgmac100 *ftgmac100 = priv->iobase;
int phycr;
int data;
int i;
@@ -114,9 +127,10 @@ static int ftgmac100_mdiobus_write(struct eth_device *dev, 
int phy_addr,
return -1;
 }
 
-int ftgmac100_phy_read(struct eth_device *dev, int addr, int reg, u16 *value)
+int ftgmac100_phy_read(struct ftgmac100_data *priv, int addr, int reg,
+  u16 *value)
 {
-   *value = ftgmac100_mdiobus_read(dev , addr, reg);
+   *value = ftgmac100_mdiobus_read(priv, addr, reg);
 
if (*value == -1)
return -1;
@@ -124,31 +138,31 @@ int ftgmac100_phy_read(struct eth_device *dev, int addr, 
int reg, u16 *value)
return 0;
 }
 
-int  ftgmac100_phy_write(struct eth_device *dev, int addr, int reg, u16 value)
+int ftgmac100_phy_write(struct ftgmac100_data *priv, int addr, int reg,
+   u16 value)
 {
-   if (ftgmac100_mdiobus_write(dev, addr, reg, value) == -1)
+   if (ftgmac100_mdiobus_write(priv, addr, reg, value) == -1)
return -1;
 
return 0;
 }
 
-static int ftgmac100_phy_reset(struct eth_device *dev)
+static int ftgmac100_phy_reset(struct ftgmac100_data *priv, struct udevice 
*dev)
 {
-   struct ftgmac100_data *priv = dev->priv;
int i;
u16 status, adv;
 
adv = ADVERTISE_CSMA | ADVERTISE_ALL;
 
-   ftgmac100_phy_write(dev, priv->phy_addr, MII_ADVERTISE, adv);
+   ftgmac100_phy_write(priv, priv->phy_addr, MII_ADVERTISE, adv);
 
printf("%s: Starting autonegotiation...\n", dev->name);
 
-   ftgmac100_phy_write(dev, priv->phy_addr,
-   MII_BMCR, (BMCR_ANENABLE | BMCR_ANRESTART));
+   ftgmac100_phy_write(priv, priv->phy_addr,
+   MII_BMCR, (BMCR_ANENABLE | BMCR_ANRESTART));
 
for (i = 0; i < 10 / 100; i++) {
-   ftgmac100_phy_read(dev, priv->phy_addr, MII_BMSR, );
+   

[U-Boot] [PATCH v3 05/13] net: ftgmac100: add MDIO bus and phylib support

2018-10-10 Thread Cédric Le Goater
Implement the MDIO bus read/write functions using the readl_poll_timeout()
routine, initialize the bus and scan for the PHY. RGMII and RMII mode
are supported.

Signed-off-by: Cédric Le Goater 
---
 drivers/net/ftgmac100.c | 380 +---
 1 file changed, 159 insertions(+), 221 deletions(-)

diff --git a/drivers/net/ftgmac100.c b/drivers/net/ftgmac100.c
index 78cd9df62986..1929e9510c26 100644
--- a/drivers/net/ftgmac100.c
+++ b/drivers/net/ftgmac100.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "ftgmac100.h"
 
@@ -29,6 +30,16 @@
 /* PKTBUFSTX/PKTBUFSRX must both be power of 2 */
 #define PKTBUFSTX  4   /* must be power of 2 */
 
+/* Timeout for a mdio read/write operation */
+#define FTGMAC100_MDIO_TIMEOUT_USEC1
+
+/*
+ * MDC clock cycle threshold
+ *
+ * 20us * 100 = 2ms > (1 / 2.5Mhz) * 0x34
+ */
+#define MDC_CYCTHR 0x34
+
 /**
  * struct ftgmac100_data - private data for the FTGMAC100 driver
  *
@@ -38,6 +49,10 @@
  * @tx_index: Transmit descriptor index in @txdes
  * @rx_index: Receive descriptor index in @rxdes
  * @phy_addr: The PHY interface address to use
+ * @phydev: The PHY device backing the MAC
+ * @bus: The mdio bus
+ * @phy_mode: The mode of the PHY interface (rgmii, rmii, ...)
+ * @max_speed: Maximum speed of Ethernet connection supported by MAC
  */
 struct ftgmac100_data {
struct ftgmac100 *iobase;
@@ -48,234 +63,109 @@ struct ftgmac100_data {
struct ftgmac100_rxdes *rxdes;
int tx_index;
int rx_index;
-   int phy_addr;
+
+   u32 phy_addr;
+   struct phy_device *phydev;
+   struct mii_dev *bus;
+   u32 phy_mode;
+   u32 max_speed;
 };
 
 /*
  * struct mii_bus functions
  */
-static int ftgmac100_mdiobus_read(struct ftgmac100_data *priv, int phy_addr,
- int regnum)
+static int ftgmac100_mdio_read(struct mii_dev *bus, int phy_addr, int dev_addr,
+  int reg_addr)
 {
+   struct ftgmac100_data *priv = bus->priv;
struct ftgmac100 *ftgmac100 = priv->iobase;
int phycr;
-   int i;
-
-   phycr = readl(>phycr);
-
-   /* preserve MDC cycle threshold */
-   phycr &= FTGMAC100_PHYCR_MDC_CYCTHR_MASK;
-
-   phycr |= FTGMAC100_PHYCR_PHYAD(phy_addr)
- |  FTGMAC100_PHYCR_REGAD(regnum)
- |  FTGMAC100_PHYCR_MIIRD;
+   int data;
+   int ret;
 
+   phycr = FTGMAC100_PHYCR_MDC_CYCTHR(MDC_CYCTHR) |
+   FTGMAC100_PHYCR_PHYAD(phy_addr) |
+   FTGMAC100_PHYCR_REGAD(reg_addr) |
+   FTGMAC100_PHYCR_MIIRD;
writel(phycr, >phycr);
 
-   for (i = 0; i < 10; i++) {
-   phycr = readl(>phycr);
-
-   if ((phycr & FTGMAC100_PHYCR_MIIRD) == 0) {
-   int data;
-
-   data = readl(>phydata);
-   return FTGMAC100_PHYDATA_MIIRDATA(data);
-   }
-
-   mdelay(10);
+   ret = readl_poll_timeout(>phycr, phycr,
+!(phycr & FTGMAC100_PHYCR_MIIRD),
+FTGMAC100_MDIO_TIMEOUT_USEC);
+   if (ret) {
+   pr_err("%s: mdio read failed (phy:%d reg:%x)\n",
+  priv->phydev->dev->name, phy_addr, reg_addr);
+   return ret;
}
 
-   debug("mdio read timed out\n");
-   return -1;
+   data = readl(>phydata);
+
+   return FTGMAC100_PHYDATA_MIIRDATA(data);
 }
 
-static int ftgmac100_mdiobus_write(struct ftgmac100_data *priv, int phy_addr,
-  int regnum, u16 value)
+static int ftgmac100_mdio_write(struct mii_dev *bus, int phy_addr, int 
dev_addr,
+   int reg_addr, u16 value)
 {
+   struct ftgmac100_data *priv = bus->priv;
struct ftgmac100 *ftgmac100 = priv->iobase;
int phycr;
int data;
-   int i;
-
-   phycr = readl(>phycr);
-
-   /* preserve MDC cycle threshold */
-   phycr &= FTGMAC100_PHYCR_MDC_CYCTHR_MASK;
-
-   phycr |= FTGMAC100_PHYCR_PHYAD(phy_addr)
- |  FTGMAC100_PHYCR_REGAD(regnum)
- |  FTGMAC100_PHYCR_MIIWR;
+   int ret;
 
+   phycr = FTGMAC100_PHYCR_MDC_CYCTHR(MDC_CYCTHR) |
+   FTGMAC100_PHYCR_PHYAD(phy_addr) |
+   FTGMAC100_PHYCR_REGAD(reg_addr) |
+   FTGMAC100_PHYCR_MIIWR;
data = FTGMAC100_PHYDATA_MIIWDATA(value);
 
writel(data, >phydata);
writel(phycr, >phycr);
 
-   for (i = 0; i < 10; i++) {
-   phycr = readl(>phycr);
-
-   if ((phycr & FTGMAC100_PHYCR_MIIWR) == 0) {
-   debug("(phycr & FTGMAC100_PHYCR_MIIWR) == 0: " \
-   "phy_addr: %x\n", phy_addr);
-   return 0;
-   }
-
-   mdelay(1);
-   }
-
-   debug("mdio write timed out\n");
-   return -1;
-}

[U-Boot] [PATCH v3 02/13] net: ftgmac100: use the aligned() macro

2018-10-10 Thread Cédric Le Goater
Signed-off-by: Cédric Le Goater 
---
 drivers/net/ftgmac100.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ftgmac100.h b/drivers/net/ftgmac100.h
index 439b14d71e4b..9a789e4d5bee 100644
--- a/drivers/net/ftgmac100.h
+++ b/drivers/net/ftgmac100.h
@@ -182,7 +182,7 @@ struct ftgmac100_txdes {
unsigned inttxdes1;
unsigned inttxdes2; /* not used by HW */
unsigned inttxdes3; /* TXBUF_BADR */
-} __attribute__ ((aligned(16)));
+} __aligned(16);
 
 #define FTGMAC100_TXDES0_TXBUF_SIZE(x) ((x) & 0x3fff)
 #define FTGMAC100_TXDES0_EDOTR BIT(15)
@@ -208,7 +208,7 @@ struct ftgmac100_rxdes {
unsigned intrxdes1;
unsigned intrxdes2; /* not used by HW */
unsigned intrxdes3; /* RXBUF_BADR */
-} __attribute__ ((aligned(16)));
+} __aligned(16);
 
 #define FTGMAC100_RXDES0_VDBC(x)   ((x) & 0x3fff)
 #define FTGMAC100_RXDES0_EDORR BIT(15)
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v3 01/13] net: ftgmac100: use the BIT() macro

2018-10-10 Thread Cédric Le Goater
Signed-off-by: Cédric Le Goater 
---
 drivers/net/ftgmac100.h | 154 
 1 file changed, 77 insertions(+), 77 deletions(-)

diff --git a/drivers/net/ftgmac100.h b/drivers/net/ftgmac100.h
index ffbe1f3e3fa7..439b14d71e4b 100644
--- a/drivers/net/ftgmac100.h
+++ b/drivers/net/ftgmac100.h
@@ -70,48 +70,48 @@ struct ftgmac100 {
 /*
  * Interrupt status register & interrupt enable register
  */
-#define FTGMAC100_INT_RPKT_BUF (1 << 0)
-#define FTGMAC100_INT_RPKT_FIFO(1 << 1)
-#define FTGMAC100_INT_NO_RXBUF (1 << 2)
-#define FTGMAC100_INT_RPKT_LOST(1 << 3)
-#define FTGMAC100_INT_XPKT_ETH (1 << 4)
-#define FTGMAC100_INT_XPKT_FIFO(1 << 5)
-#define FTGMAC100_INT_NO_NPTXBUF   (1 << 6)
-#define FTGMAC100_INT_XPKT_LOST(1 << 7)
-#define FTGMAC100_INT_AHB_ERR  (1 << 8)
-#define FTGMAC100_INT_PHYSTS_CHG   (1 << 9)
-#define FTGMAC100_INT_NO_HPTXBUF   (1 << 10)
+#define FTGMAC100_INT_RPKT_BUF BIT(0)
+#define FTGMAC100_INT_RPKT_FIFOBIT(1)
+#define FTGMAC100_INT_NO_RXBUF BIT(2)
+#define FTGMAC100_INT_RPKT_LOSTBIT(3)
+#define FTGMAC100_INT_XPKT_ETH BIT(4)
+#define FTGMAC100_INT_XPKT_FIFOBIT(5)
+#define FTGMAC100_INT_NO_NPTXBUF   BIT(6)
+#define FTGMAC100_INT_XPKT_LOSTBIT(7)
+#define FTGMAC100_INT_AHB_ERR  BIT(8)
+#define FTGMAC100_INT_PHYSTS_CHG   BIT(9)
+#define FTGMAC100_INT_NO_HPTXBUF   BIT(10)
 
 /*
  * Interrupt timer control register
  */
 #define FTGMAC100_ITC_RXINT_CNT(x) (((x) & 0xf) << 0)
 #define FTGMAC100_ITC_RXINT_THR(x) (((x) & 0x7) << 4)
-#define FTGMAC100_ITC_RXINT_TIME_SEL   (1 << 7)
+#define FTGMAC100_ITC_RXINT_TIME_SEL   BIT(7)
 #define FTGMAC100_ITC_TXINT_CNT(x) (((x) & 0xf) << 8)
 #define FTGMAC100_ITC_TXINT_THR(x) (((x) & 0x7) << 12)
-#define FTGMAC100_ITC_TXINT_TIME_SEL   (1 << 15)
+#define FTGMAC100_ITC_TXINT_TIME_SEL   BIT(15)
 
 /*
  * Automatic polling timer control register
  */
 #define FTGMAC100_APTC_RXPOLL_CNT(x)   (((x) & 0xf) << 0)
-#define FTGMAC100_APTC_RXPOLL_TIME_SEL (1 << 4)
+#define FTGMAC100_APTC_RXPOLL_TIME_SEL BIT(4)
 #define FTGMAC100_APTC_TXPOLL_CNT(x)   (((x) & 0xf) << 8)
-#define FTGMAC100_APTC_TXPOLL_TIME_SEL (1 << 12)
+#define FTGMAC100_APTC_TXPOLL_TIME_SEL BIT(12)
 
 /*
  * DMA burst length and arbitration control register
  */
 #define FTGMAC100_DBLAC_RXFIFO_LTHR(x) (((x) & 0x7) << 0)
 #define FTGMAC100_DBLAC_RXFIFO_HTHR(x) (((x) & 0x7) << 3)
-#define FTGMAC100_DBLAC_RX_THR_EN  (1 << 6)
+#define FTGMAC100_DBLAC_RX_THR_EN  BIT(6)
 #define FTGMAC100_DBLAC_RXBURST_SIZE(x)(((x) & 0x3) << 8)
 #define FTGMAC100_DBLAC_TXBURST_SIZE(x)(((x) & 0x3) << 10)
 #define FTGMAC100_DBLAC_RXDES_SIZE(x)  (((x) & 0xf) << 12)
 #define FTGMAC100_DBLAC_TXDES_SIZE(x)  (((x) & 0xf) << 16)
 #define FTGMAC100_DBLAC_IFG_CNT(x) (((x) & 0x7) << 20)
-#define FTGMAC100_DBLAC_IFG_INC(1 << 23)
+#define FTGMAC100_DBLAC_IFG_INCBIT(23)
 
 /*
  * DMA FIFO status register
@@ -122,12 +122,12 @@ struct ftgmac100 {
 #define FTGMAC100_DMAFIFOS_TXDMA1_SM(dmafifos) (((dmafifos) >> 12) & 0xf)
 #define FTGMAC100_DMAFIFOS_TXDMA2_SM(dmafifos) (((dmafifos) >> 16) & 0x3)
 #define FTGMAC100_DMAFIFOS_TXDMA3_SM(dmafifos) (((dmafifos) >> 18) & 0xf)
-#define FTGMAC100_DMAFIFOS_RXFIFO_EMPTY(1 << 26)
-#define FTGMAC100_DMAFIFOS_TXFIFO_EMPTY(1 << 27)
-#define FTGMAC100_DMAFIFOS_RXDMA_GRANT (1 << 28)
-#define FTGMAC100_DMAFIFOS_TXDMA_GRANT (1 << 29)
-#define FTGMAC100_DMAFIFOS_RXDMA_REQ   (1 << 30)
-#define FTGMAC100_DMAFIFOS_TXDMA_REQ   (1 << 31)
+#define FTGMAC100_DMAFIFOS_RXFIFO_EMPTYBIT(26)
+#define FTGMAC100_DMAFIFOS_TXFIFO_EMPTYBIT(27)
+#define FTGMAC100_DMAFIFOS_RXDMA_GRANT BIT(28)
+#define FTGMAC100_DMAFIFOS_TXDMA_GRANT BIT(29)
+#define FTGMAC100_DMAFIFOS_RXDMA_REQ   BIT(30)
+#define FTGMAC100_DMAFIFOS_TXDMA_REQ   BIT(31)
 
 /*
  * Receive buffer size register
@@ -137,26 +137,26 @@ struct ftgmac100 {
 /*
  * MAC control register
  */
-#define FTGMAC100_MACCR_TXDMA_EN   (1 << 0)
-#define FTGMAC100_MACCR_RXDMA_EN   (1 << 1)
-#define FTGMAC100_MACCR_TXMAC_EN   (1 << 2)
-#define FTGMAC100_MACCR_RXMAC_EN   (1 << 3)
-#define FTGMAC100_MACCR_RM_VLAN(1 << 4)
-#define FTGMAC100_MACCR_HPTXR_EN   (1 << 5)
-#define FTGMAC100_MACCR_LOOP_EN(1 << 6)
-#define FTGMAC100_MACCR_ENRX_IN_HALFTX (1 << 7)
-#define FTGMAC100_MACCR_FULLDUP(1 << 8)
-#define FTGMAC100_MACCR_GIGA_MODE  (1 << 9)
-#define FTGMAC100_MACCR_CRC_APD(1 << 10)
-#define FTGMAC100_MACCR_RX_RUNT(1 << 12)
-#define FTGMAC100_MACCR_JUMBO_LF   (1 << 13)
-#define FTGMAC100_MACCR_RX_ALL (1 << 14)
-#define 

[U-Boot] [PATCH v3 00/13] Support for the Faraday ftgmac100 controller

2018-10-10 Thread Cédric Le Goater
Hello,

This series re-enables the Faraday ftgmac100 controller driver and its
Aspeed variant as as one can find on the OpenPOWER platforms. The
driver is largely reworked to support the driver model and also adds
the MDIO bus and phylib support. It was tested on the AST2500 evb.

Git tree available here:

  https://github.com/legoater/u-boot/commits/aspeed

Thanks,

C.

Changes since v2 :

  - split changes in multiple patches to preserve git history, but the
code has not changed since the reviewed v2 patchset.
  - included a couple more changes to sync the DTS file with Linux.

Changes since v1 :

 - improved comments in the code
 - changed the type of 'iobase' to 'struct ftgmac100 *' to remove the
   casts in other routines.
 - replaced the loop in the mdio methods by a call to readl_poll_timeout()
   and fixed the returned value.
 - added a flush cache on the arrays of TX and RX descriptors in
   ftgmac100_start()
 - fixed returned value of 
 - added a timer loop to catch transmit timeouts
 - introduced a clk_bulk
 - improved Kconfig description
 - introduced a udevice_id .data model
 - dropped is_aspeed bool
 - dropped MDIO interface setting for Aspeed SoC. The default is
   correct.
 - removed the clcoks which are now handled automatically in the
   ftgmac100 driver
 - introduced a fix for the D2-PLL clock setting

Cédric Le Goater (13):
  net: ftgmac100: use the BIT() macro
  net: ftgmac100: use the aligned() macro
  net: ftgmac100: convert to driver model
  net: ftgmac100: use setbits_le32() in the reset method
  net: ftgmac100: add MDIO bus and phylib support
  net: ftgmac100: convert the RX/TX descriptor arrays
  net: ftgmac100: handle timeouts when transmitting
  net: ftgmac100: add clock support
  aspeed: ast2500: fix missing break in D2PLL clock enablement
  net: ftgmac100: Add support for the Aspeed SoC
  aspeed: Update ast2500 SoC DTS file to Linux v4.17-rc6 level
  aspeed: Activate ethernet devices on the ast2500 Eval Board
  aspeed: ast2500: fix D2-PLL clock setting in RGMII mode

 drivers/net/ftgmac100.h  |  158 +--
 include/netdev.h |1 -
 drivers/clk/aspeed/clk_ast2500.c |   39 +
 drivers/net/ftgmac100.c  |  724 +--
 arch/arm/dts/ast2500-evb.dts |   23 +
 arch/arm/dts/ast2500.dtsi| 1949 ++
 configs/evb-ast2500_defconfig|8 +
 drivers/net/Kconfig  |   26 +
 8 files changed, 1699 insertions(+), 1229 deletions(-)

-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] driver/mtd: Add MICRON manufacturer id in spi framework

2018-10-10 Thread Yogesh Narayan Gaur
Hi Jagan,

> -Original Message-
> From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Ashish
> Kumar
> Sent: Wednesday, October 10, 2018 4:23 PM
> To: Jagan Teki 
> Cc: U-Boot-Denx ; Jagan Teki ;
> Rajat Srivastava ; Suresh Gupta
> 
> Subject: Re: [U-Boot] [PATCH] driver/mtd: Add MICRON manufacturer id in spi
> framework
> 
> > -Original Message-
> > From: Jagan Teki 
> > Sent: Wednesday, October 10, 2018 11:51 AM
> > To: Ashish Kumar 
> > Cc: U-Boot-Denx ; Jagan Teki
> > ; Rajat Srivastava ;
> > Suresh Gupta 
> > Subject: Re: [U-Boot] [PATCH] driver/mtd: Add MICRON manufacturer id
> > in spi framework
> >
> > On Tue, Sep 25, 2018 at 2:13 PM Ashish Kumar 
> > wrote:
> > >
> > > Signed-off-by: Suresh Gupta 
> > > Signed-off-by: Yogesh Gaur 
> > > Signed-off-by: Ashish Kumar 
> > > ---
> > >  drivers/mtd/spi/sf_internal.h | 1 +
> > >  drivers/mtd/spi/spi_flash.c   | 2 ++
> > >  2 files changed, 3 insertions(+)
> > >
> > > diff --git a/drivers/mtd/spi/sf_internal.h
> > > b/drivers/mtd/spi/sf_internal.h index 4f63cacc64..26f5c7c995 100644
> > > --- a/drivers/mtd/spi/sf_internal.h
> > > +++ b/drivers/mtd/spi/sf_internal.h
> > > @@ -32,6 +32,7 @@ enum spi_nor_option_flags {
> > >  /* CFI Manufacture ID's */
> > >  #define SPI_FLASH_CFI_MFR_SPANSION 0x01
> > >  #define SPI_FLASH_CFI_MFR_STMICRO  0x20
> > > +#define SPI_FLASH_CFI_MFR_MICRON   0x2C
> >
> > Why we need this? is it to support old micron chips?
> 
> NOR flash name MT35X_QLKA and MT25Q_** used on NXP board has
> manufacturer id as 0x2C, which are rather for newer flashes after the split of
> Micron from ST.
> 

Same is being discussed in Linux-mtd mailing list [1].
Public data sheet of MT35x flash can be checked at[2]

--
Regards
Yogesh Gaur.
[1] https://patchwork.ozlabs.org/patch/971439/
[2] https://www.micron.com/resource-details/0b74b806-bbf1-4c24-b07b-35e2799bb6ff

> Regards
> Ashish
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.de
> nx.de%2Flistinfo%2Fu-
> bootdata=02%7C01%7Cyogeshnarayan.gaur%40nxp.com%7Cd2c8d343b
> b8646a75c1b08d62e9eabc3%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7
> C0%7C636747656373729732sdata=58px6wLL96jaImJ6MGXC6rRHiXO3oe
> sj1EFfCrEmoGY%3Dreserved=0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v4] arm: socfpga: fix SPL booting from fpga OnChip RAM

2018-10-10 Thread Simon Goldschmidt
On Wed, Oct 10, 2018 at 12:50 PM Marek Vasut  wrote:
>
> On 10/10/2018 12:49 PM, Marek Vasut wrote:
> > On 10/10/2018 12:32 PM, Simon Goldschmidt wrote:
> >> On Wed, Oct 10, 2018 at 12:21 PM Marek Vasut  wrote:
> >>>
> >>> On 10/10/2018 06:26 AM, Simon Goldschmidt wrote:
>  This patch prevents disabling the FPGA bridges when
>  SPL or U-Boot is executed from FPGA onchip RAM.
> 
>  Signed-off-by: Simon Goldschmidt 
>  ---
> 
>  Changes in v4:
>  - use an inline function in misc.h to check for the address
>    range instead of a macro in base_addr_ac5.h
> 
>  Changes in v3:
>  - use __image_copy_start to check if we are executing from FPGA
> 
>  Changes in v2:
>  - use less ifdefs and more C code for address checks
>    (but this gives a checkpatch warning because of comparing two
>    upper case constants)
>  - changed comments
> 
>   arch/arm/mach-socfpga/include/mach/base_addr_ac5.h |  1 +
>   arch/arm/mach-socfpga/include/mach/misc.h  |  7 +++
>   arch/arm/mach-socfpga/misc_gen5.c  | 10 +-
>   arch/arm/mach-socfpga/spl_gen5.c   | 10 +++---
>   4 files changed, 24 insertions(+), 4 deletions(-)
> 
>  diff --git a/arch/arm/mach-socfpga/include/mach/base_addr_ac5.h 
>  b/arch/arm/mach-socfpga/include/mach/base_addr_ac5.h
>  index bb9e3faa29..2725e9fcc3 100644
>  --- a/arch/arm/mach-socfpga/include/mach/base_addr_ac5.h
>  +++ b/arch/arm/mach-socfpga/include/mach/base_addr_ac5.h
>  @@ -6,6 +6,7 @@
>   #ifndef _SOCFPGA_BASE_ADDRS_H_
>   #define _SOCFPGA_BASE_ADDRS_H_
> 
>  +#define SOCFPGA_FPGA_SLAVES_ADDRESS  0xc000
>   #define SOCFPGA_STM_ADDRESS  0xfc00
>   #define SOCFPGA_DAP_ADDRESS  0xff00
>   #define SOCFPGA_EMAC0_ADDRESS0xff70
>  diff --git a/arch/arm/mach-socfpga/include/mach/misc.h 
>  b/arch/arm/mach-socfpga/include/mach/misc.h
>  index 4fc9570a04..e78a86503e 100644
>  --- a/arch/arm/mach-socfpga/include/mach/misc.h
>  +++ b/arch/arm/mach-socfpga/include/mach/misc.h
>  @@ -23,6 +23,13 @@ static inline void socfpga_fpga_add(void) {}
> 
>   #ifdef CONFIG_TARGET_SOCFPGA_GEN5
>   void socfpga_sdram_remap_zero(void);
>  +static inline bool socfpga_is_fpga_slaves_addr(void *addr)
>  +{
> >>>
> >>> Is the inline needed ?
> >>
> >> If it's in this header, yes. As without the inline, you get this compiler
> >> warnings in files that include misc.h but don't call the function:
> >> warning: ‘socfpga_is_fpga_slaves_addr’ defined but not used 
> >> [-Wunused-function]
> >
> > Ah, got it.
> >
> >>> btw would it make sense to encode __image_copy_start here and just make
> >>> it a function like ie.
> >>>
> >>> static bool socfpga_is_booting_from_fpga(void) {} ?
> >>
> >> Sure. Do you want me to move it into misc_gen5.c r keep the inline?
> >
> > Nope, just this. Sorry for pestering you so much.

No problem. Thanks to patman, sending new versions is not really much work :-)

>
> And by just this I mean, just encode the __image_start_addr into the
> function and drop the argument, keep it where it is.

Yeah, got it.


Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] driver/mtd: Add MICRON manufacturer id in spi framework

2018-10-10 Thread Ashish Kumar
> -Original Message-
> From: Jagan Teki 
> Sent: Wednesday, October 10, 2018 11:51 AM
> To: Ashish Kumar 
> Cc: U-Boot-Denx ; Jagan Teki ;
> Rajat Srivastava ; Suresh Gupta
> 
> Subject: Re: [U-Boot] [PATCH] driver/mtd: Add MICRON manufacturer id in spi
> framework
> 
> On Tue, Sep 25, 2018 at 2:13 PM Ashish Kumar 
> wrote:
> >
> > Signed-off-by: Suresh Gupta 
> > Signed-off-by: Yogesh Gaur 
> > Signed-off-by: Ashish Kumar 
> > ---
> >  drivers/mtd/spi/sf_internal.h | 1 +
> >  drivers/mtd/spi/spi_flash.c   | 2 ++
> >  2 files changed, 3 insertions(+)
> >
> > diff --git a/drivers/mtd/spi/sf_internal.h
> > b/drivers/mtd/spi/sf_internal.h index 4f63cacc64..26f5c7c995 100644
> > --- a/drivers/mtd/spi/sf_internal.h
> > +++ b/drivers/mtd/spi/sf_internal.h
> > @@ -32,6 +32,7 @@ enum spi_nor_option_flags {
> >  /* CFI Manufacture ID's */
> >  #define SPI_FLASH_CFI_MFR_SPANSION 0x01
> >  #define SPI_FLASH_CFI_MFR_STMICRO  0x20
> > +#define SPI_FLASH_CFI_MFR_MICRON   0x2C
> 
> Why we need this? is it to support old micron chips?

NOR flash name MT35X_QLKA and MT25Q_** used on NXP board has manufacturer id as 
0x2C, which are rather for newer flashes after the split of Micron from ST.

Regards
Ashish 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v4] arm: socfpga: fix SPL booting from fpga OnChip RAM

2018-10-10 Thread Marek Vasut
On 10/10/2018 12:49 PM, Marek Vasut wrote:
> On 10/10/2018 12:32 PM, Simon Goldschmidt wrote:
>> On Wed, Oct 10, 2018 at 12:21 PM Marek Vasut  wrote:
>>>
>>> On 10/10/2018 06:26 AM, Simon Goldschmidt wrote:
 This patch prevents disabling the FPGA bridges when
 SPL or U-Boot is executed from FPGA onchip RAM.

 Signed-off-by: Simon Goldschmidt 
 ---

 Changes in v4:
 - use an inline function in misc.h to check for the address
   range instead of a macro in base_addr_ac5.h

 Changes in v3:
 - use __image_copy_start to check if we are executing from FPGA

 Changes in v2:
 - use less ifdefs and more C code for address checks
   (but this gives a checkpatch warning because of comparing two
   upper case constants)
 - changed comments

  arch/arm/mach-socfpga/include/mach/base_addr_ac5.h |  1 +
  arch/arm/mach-socfpga/include/mach/misc.h  |  7 +++
  arch/arm/mach-socfpga/misc_gen5.c  | 10 +-
  arch/arm/mach-socfpga/spl_gen5.c   | 10 +++---
  4 files changed, 24 insertions(+), 4 deletions(-)

 diff --git a/arch/arm/mach-socfpga/include/mach/base_addr_ac5.h 
 b/arch/arm/mach-socfpga/include/mach/base_addr_ac5.h
 index bb9e3faa29..2725e9fcc3 100644
 --- a/arch/arm/mach-socfpga/include/mach/base_addr_ac5.h
 +++ b/arch/arm/mach-socfpga/include/mach/base_addr_ac5.h
 @@ -6,6 +6,7 @@
  #ifndef _SOCFPGA_BASE_ADDRS_H_
  #define _SOCFPGA_BASE_ADDRS_H_

 +#define SOCFPGA_FPGA_SLAVES_ADDRESS  0xc000
  #define SOCFPGA_STM_ADDRESS  0xfc00
  #define SOCFPGA_DAP_ADDRESS  0xff00
  #define SOCFPGA_EMAC0_ADDRESS0xff70
 diff --git a/arch/arm/mach-socfpga/include/mach/misc.h 
 b/arch/arm/mach-socfpga/include/mach/misc.h
 index 4fc9570a04..e78a86503e 100644
 --- a/arch/arm/mach-socfpga/include/mach/misc.h
 +++ b/arch/arm/mach-socfpga/include/mach/misc.h
 @@ -23,6 +23,13 @@ static inline void socfpga_fpga_add(void) {}

  #ifdef CONFIG_TARGET_SOCFPGA_GEN5
  void socfpga_sdram_remap_zero(void);
 +static inline bool socfpga_is_fpga_slaves_addr(void *addr)
 +{
>>>
>>> Is the inline needed ?
>>
>> If it's in this header, yes. As without the inline, you get this compiler
>> warnings in files that include misc.h but don't call the function:
>> warning: ‘socfpga_is_fpga_slaves_addr’ defined but not used 
>> [-Wunused-function]
> 
> Ah, got it.
> 
>>> btw would it make sense to encode __image_copy_start here and just make
>>> it a function like ie.
>>>
>>> static bool socfpga_is_booting_from_fpga(void) {} ?
>>
>> Sure. Do you want me to move it into misc_gen5.c r keep the inline?
> 
> Nope, just this. Sorry for pestering you so much.

And by just this I mean, just encode the __image_start_addr into the
function and drop the argument, keep it where it is.

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v4] arm: socfpga: fix SPL booting from fpga OnChip RAM

2018-10-10 Thread Marek Vasut
On 10/10/2018 12:32 PM, Simon Goldschmidt wrote:
> On Wed, Oct 10, 2018 at 12:21 PM Marek Vasut  wrote:
>>
>> On 10/10/2018 06:26 AM, Simon Goldschmidt wrote:
>>> This patch prevents disabling the FPGA bridges when
>>> SPL or U-Boot is executed from FPGA onchip RAM.
>>>
>>> Signed-off-by: Simon Goldschmidt 
>>> ---
>>>
>>> Changes in v4:
>>> - use an inline function in misc.h to check for the address
>>>   range instead of a macro in base_addr_ac5.h
>>>
>>> Changes in v3:
>>> - use __image_copy_start to check if we are executing from FPGA
>>>
>>> Changes in v2:
>>> - use less ifdefs and more C code for address checks
>>>   (but this gives a checkpatch warning because of comparing two
>>>   upper case constants)
>>> - changed comments
>>>
>>>  arch/arm/mach-socfpga/include/mach/base_addr_ac5.h |  1 +
>>>  arch/arm/mach-socfpga/include/mach/misc.h  |  7 +++
>>>  arch/arm/mach-socfpga/misc_gen5.c  | 10 +-
>>>  arch/arm/mach-socfpga/spl_gen5.c   | 10 +++---
>>>  4 files changed, 24 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-socfpga/include/mach/base_addr_ac5.h 
>>> b/arch/arm/mach-socfpga/include/mach/base_addr_ac5.h
>>> index bb9e3faa29..2725e9fcc3 100644
>>> --- a/arch/arm/mach-socfpga/include/mach/base_addr_ac5.h
>>> +++ b/arch/arm/mach-socfpga/include/mach/base_addr_ac5.h
>>> @@ -6,6 +6,7 @@
>>>  #ifndef _SOCFPGA_BASE_ADDRS_H_
>>>  #define _SOCFPGA_BASE_ADDRS_H_
>>>
>>> +#define SOCFPGA_FPGA_SLAVES_ADDRESS  0xc000
>>>  #define SOCFPGA_STM_ADDRESS  0xfc00
>>>  #define SOCFPGA_DAP_ADDRESS  0xff00
>>>  #define SOCFPGA_EMAC0_ADDRESS0xff70
>>> diff --git a/arch/arm/mach-socfpga/include/mach/misc.h 
>>> b/arch/arm/mach-socfpga/include/mach/misc.h
>>> index 4fc9570a04..e78a86503e 100644
>>> --- a/arch/arm/mach-socfpga/include/mach/misc.h
>>> +++ b/arch/arm/mach-socfpga/include/mach/misc.h
>>> @@ -23,6 +23,13 @@ static inline void socfpga_fpga_add(void) {}
>>>
>>>  #ifdef CONFIG_TARGET_SOCFPGA_GEN5
>>>  void socfpga_sdram_remap_zero(void);
>>> +static inline bool socfpga_is_fpga_slaves_addr(void *addr)
>>> +{
>>
>> Is the inline needed ?
> 
> If it's in this header, yes. As without the inline, you get this compiler
> warnings in files that include misc.h but don't call the function:
> warning: ‘socfpga_is_fpga_slaves_addr’ defined but not used 
> [-Wunused-function]

Ah, got it.

>> btw would it make sense to encode __image_copy_start here and just make
>> it a function like ie.
>>
>> static bool socfpga_is_booting_from_fpga(void) {} ?
> 
> Sure. Do you want me to move it into misc_gen5.c r keep the inline?

Nope, just this. Sorry for pestering you so much.

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v2 01/11] m68k: add basic set of devicetrees

2018-10-10 Thread Angelo Dureghello
On Wed, Oct 10, 2018 at 11:19:26AM +0530, Jagan Teki wrote:
> On Wed, Oct 10, 2018 at 5:09 AM Angelo Dureghello  wrote:
> >
> > This patch adds a basic group of devicetrees, one for each
> > cpu family, including actually just uart and dspi devices,
> > since these are the drivers supporting devicetree (support
> > added in this patch-set).
> 
> I hope this is Linux DT sync? if yes better to mention the sync commit id.
>
There is no linux DT support for m68k, 
ColdFire uses the old style platform driver.
 
> Acked-by: Jagan Teki 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v4] arm: socfpga: fix SPL booting from fpga OnChip RAM

2018-10-10 Thread Simon Goldschmidt
On Wed, Oct 10, 2018 at 12:21 PM Marek Vasut  wrote:
>
> On 10/10/2018 06:26 AM, Simon Goldschmidt wrote:
> > This patch prevents disabling the FPGA bridges when
> > SPL or U-Boot is executed from FPGA onchip RAM.
> >
> > Signed-off-by: Simon Goldschmidt 
> > ---
> >
> > Changes in v4:
> > - use an inline function in misc.h to check for the address
> >   range instead of a macro in base_addr_ac5.h
> >
> > Changes in v3:
> > - use __image_copy_start to check if we are executing from FPGA
> >
> > Changes in v2:
> > - use less ifdefs and more C code for address checks
> >   (but this gives a checkpatch warning because of comparing two
> >   upper case constants)
> > - changed comments
> >
> >  arch/arm/mach-socfpga/include/mach/base_addr_ac5.h |  1 +
> >  arch/arm/mach-socfpga/include/mach/misc.h  |  7 +++
> >  arch/arm/mach-socfpga/misc_gen5.c  | 10 +-
> >  arch/arm/mach-socfpga/spl_gen5.c   | 10 +++---
> >  4 files changed, 24 insertions(+), 4 deletions(-)
> >
> > diff --git a/arch/arm/mach-socfpga/include/mach/base_addr_ac5.h 
> > b/arch/arm/mach-socfpga/include/mach/base_addr_ac5.h
> > index bb9e3faa29..2725e9fcc3 100644
> > --- a/arch/arm/mach-socfpga/include/mach/base_addr_ac5.h
> > +++ b/arch/arm/mach-socfpga/include/mach/base_addr_ac5.h
> > @@ -6,6 +6,7 @@
> >  #ifndef _SOCFPGA_BASE_ADDRS_H_
> >  #define _SOCFPGA_BASE_ADDRS_H_
> >
> > +#define SOCFPGA_FPGA_SLAVES_ADDRESS  0xc000
> >  #define SOCFPGA_STM_ADDRESS  0xfc00
> >  #define SOCFPGA_DAP_ADDRESS  0xff00
> >  #define SOCFPGA_EMAC0_ADDRESS0xff70
> > diff --git a/arch/arm/mach-socfpga/include/mach/misc.h 
> > b/arch/arm/mach-socfpga/include/mach/misc.h
> > index 4fc9570a04..e78a86503e 100644
> > --- a/arch/arm/mach-socfpga/include/mach/misc.h
> > +++ b/arch/arm/mach-socfpga/include/mach/misc.h
> > @@ -23,6 +23,13 @@ static inline void socfpga_fpga_add(void) {}
> >
> >  #ifdef CONFIG_TARGET_SOCFPGA_GEN5
> >  void socfpga_sdram_remap_zero(void);
> > +static inline bool socfpga_is_fpga_slaves_addr(void *addr)
> > +{
>
> Is the inline needed ?

If it's in this header, yes. As without the inline, you get this compiler
warnings in files that include misc.h but don't call the function:
warning: ‘socfpga_is_fpga_slaves_addr’ defined but not used [-Wunused-function]

> btw would it make sense to encode __image_copy_start here and just make
> it a function like ie.
>
> static bool socfpga_is_booting_from_fpga(void) {} ?

Sure. Do you want me to move it into misc_gen5.c r keep the inline?

Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v4] arm: socfpga: fix SPL booting from fpga OnChip RAM

2018-10-10 Thread Marek Vasut
On 10/10/2018 06:26 AM, Simon Goldschmidt wrote:
> This patch prevents disabling the FPGA bridges when
> SPL or U-Boot is executed from FPGA onchip RAM.
> 
> Signed-off-by: Simon Goldschmidt 
> ---
> 
> Changes in v4:
> - use an inline function in misc.h to check for the address
>   range instead of a macro in base_addr_ac5.h
> 
> Changes in v3:
> - use __image_copy_start to check if we are executing from FPGA
> 
> Changes in v2:
> - use less ifdefs and more C code for address checks
>   (but this gives a checkpatch warning because of comparing two
>   upper case constants)
> - changed comments
> 
>  arch/arm/mach-socfpga/include/mach/base_addr_ac5.h |  1 +
>  arch/arm/mach-socfpga/include/mach/misc.h  |  7 +++
>  arch/arm/mach-socfpga/misc_gen5.c  | 10 +-
>  arch/arm/mach-socfpga/spl_gen5.c   | 10 +++---
>  4 files changed, 24 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/mach-socfpga/include/mach/base_addr_ac5.h 
> b/arch/arm/mach-socfpga/include/mach/base_addr_ac5.h
> index bb9e3faa29..2725e9fcc3 100644
> --- a/arch/arm/mach-socfpga/include/mach/base_addr_ac5.h
> +++ b/arch/arm/mach-socfpga/include/mach/base_addr_ac5.h
> @@ -6,6 +6,7 @@
>  #ifndef _SOCFPGA_BASE_ADDRS_H_
>  #define _SOCFPGA_BASE_ADDRS_H_
>  
> +#define SOCFPGA_FPGA_SLAVES_ADDRESS  0xc000
>  #define SOCFPGA_STM_ADDRESS  0xfc00
>  #define SOCFPGA_DAP_ADDRESS  0xff00
>  #define SOCFPGA_EMAC0_ADDRESS0xff70
> diff --git a/arch/arm/mach-socfpga/include/mach/misc.h 
> b/arch/arm/mach-socfpga/include/mach/misc.h
> index 4fc9570a04..e78a86503e 100644
> --- a/arch/arm/mach-socfpga/include/mach/misc.h
> +++ b/arch/arm/mach-socfpga/include/mach/misc.h
> @@ -23,6 +23,13 @@ static inline void socfpga_fpga_add(void) {}
>  
>  #ifdef CONFIG_TARGET_SOCFPGA_GEN5
>  void socfpga_sdram_remap_zero(void);
> +static inline bool socfpga_is_fpga_slaves_addr(void *addr)
> +{

Is the inline needed ?

btw would it make sense to encode __image_copy_start here and just make
it a function like ie.

static bool socfpga_is_booting_from_fpga(void) {} ?

[...]

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v2 02/11] drivers: spi: cf_spi: add Kconfig option

2018-10-10 Thread Angelo Dureghello
On Wed, Oct 10, 2018 at 11:21:45AM +0530, Jagan Teki wrote:
> On Wed, Oct 10, 2018 at 11:14 AM Angelo Dureghello  wrote:
> >
> 
> Commit message?
>
Ok, will add it, v3 in short.
 
> > Signed-off-by: Angelo Dureghello 
> > ---
> > Changes for v2:
> > - new patch
> > ---
> >  drivers/spi/Kconfig | 18 --
> >  1 file changed, 12 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
> > index 196767a3f6..6340453870 100644
> > --- a/drivers/spi/Kconfig
> > +++ b/drivers/spi/Kconfig
> > @@ -87,6 +87,12 @@ config CADENCE_QSPI
> >   used to access the SPI NOR flash on platforms embedding this
> >   Cadence IP core.
> >
> > +config CF_SPI
> > +bool "ColdFire SPI driver"
> > +help
> > +  Enable the ColdFire SPI driver. This driver can be used on
> > +  some m68k SoCs.
> > +
> >  config DESIGNWARE_SPI
> > bool "Designware SPI driver"
> > help
> > @@ -259,18 +265,18 @@ config ZYNQMP_GQSPI
> >
> >  endif # if DM_SPI
> >
> > -config SOFT_SPI
> > -   bool "Soft SPI driver"
> > -   help
> > -Enable Soft SPI driver. This driver is to use GPIO simulate
> > -the SPI protocol.
> > -
> >  config CF_SPI
> > bool "ColdFire SPI driver"
> > help
> >   Enable the ColdFire SPI driver. This driver can be used on
> >   some m68k SoCs.
> >
> > +config SOFT_SPI
> > +   bool "Soft SPI driver"
> > +   help
> > +Enable Soft SPI driver. This driver is to use GPIO simulate
> > +the SPI protocol.
> > +
> 
> Why this move?

Kconfig must keep alphabetical order.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v2 03/11] drivers: spi: cf_spi: migrate to DM and DT

2018-10-10 Thread Angelo Dureghello
Hi Jagan,

On Wed, Oct 10, 2018 at 11:28:17AM +0530, Jagan Teki wrote:
> On Wed, Oct 10, 2018 at 5:10 AM Angelo Dureghello  wrote:
> >
> > Adding DM and DT support and removing old non-DM code.
> 
> Commit head can be: spi: cf_spi: Convert to driver model
>
Ok, as you prefer. Will do in v3.
 
> >
> > Signed-off-by: Angelo Dureghello 
> > ---
> > Changes for v2:
> > - removed non DM code part
> > - add default setup of CTAR registers
> > - add DT CTAR register setup support
> > ---
> >  drivers/spi/cf_spi.c| 510 +++-
> >  include/dm/platform_data/spi_coldfire.h |  29 ++
> >  2 files changed, 346 insertions(+), 193 deletions(-)
> >  create mode 100644 include/dm/platform_data/spi_coldfire.h
> >
> > diff --git a/drivers/spi/cf_spi.c b/drivers/spi/cf_spi.c
> > index 522631cbbf..55e2c9d7b7 100644
> > --- a/drivers/spi/cf_spi.c
> > +++ b/drivers/spi/cf_spi.c
> > @@ -6,16 +6,28 @@
> >   *
> >   * Copyright (C) 2004-2009 Freescale Semiconductor, Inc.
> >   * TsiChung Liew (tsi-chung.l...@freescale.com)
> > + *
> > + * Support for DM and DT, non-DM code removed.
> > + * Copyright (C) 2018 Angelo Dureghello 
> > + *
> > + * TODO: fsl_dspi.c should work as a driver for the DSPI module.
> 
> what is this for?
> 

cf_spi.c is here for historical reasons, but may probably 
be removed completely, since fsl_dspi.c is for the same
Freescale DSPI hardware module, with the minimal difference
of the FIFO size, that is raised to 16 words (from 4) in ColdFire.

If you look fsl_dspi.c you will find some CONFIG_M68K references
so this means someone already tried to use it for m68k, even if
actually still only cf_spi.c is used from the ColdFire family.

In linux i mainlined usage of fsl_dspi for ColdFire, so very likely
it is possible to use fsl_dspi and remove totally cf_spi also
in u-boot).
But this would need a further step to verify feasibility and to
test it carefully.

> >   */
> >
> >  #include 
> > +#include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >
> > -struct cf_spi_slave {
> > +struct coldfire_spi_priv {
> > +#ifndef CONFIG_DM_SPI
> > struct spi_slave slave;
> > +#endif
> 
> do you still maintain non-dm code? if yes can't we get rid of?
> 
Ack, will rmeove.

> > +   struct dspi *regs;
> > uint baudrate;
> > +   int mode;
> > int charbit;
> >  };
> >
> > @@ -38,14 +50,30 @@ DECLARE_GLOBAL_DATA_PTR;
> >  #define SPI_MODE_MOD   0x0020
> >  #define SPI_DBLRATE0x0010
> >
> > -static inline struct cf_spi_slave *to_cf_spi_slave(struct spi_slave *slave)
> > -{
> > -   return container_of(slave, struct cf_spi_slave, slave);
> > -}
> > +#define MCF_DSPI_MAX_CTAR_REGS 8
> > +
> > +/* Default values */
> > +#define MCF_DSPI_DEFAULT_SCK_FREQ  1000
> > +#define MCF_DSPI_DEFAULT_MAX_CS4
> > +#define MCF_DSPI_DEFAULT_MODE  0
> >
> > -static void cfspi_init(void)
> > +#define MCF_DSPI_DEFAULT_CTAR  (DSPI_CTAR_TRSZ(7) | \
> > +   DSPI_CTAR_PCSSCK_1CLK | \
> > +   DSPI_CTAR_PASC(0) | \
> > +   DSPI_CTAR_PDT(0) | \
> > +   DSPI_CTAR_CSSCK(0) | \
> > +   DSPI_CTAR_ASC(0) | \
> 
> [snip]
> 
> > -int spi_xfer(struct spi_slave *slave, unsigned int bitlen, const void 
> > *dout,
> > -void *din, unsigned long flags)
> > +static int coldfire_spi_probe(struct udevice *bus)
> >  {
> > -   return cfspi_xfer(slave, bitlen, dout, din, flags);
> > +   struct coldfire_spi_platdata *plat = dev_get_platdata(bus);
> > +   struct coldfire_spi_priv *cfspi = dev_get_priv(bus);
> > +   int i;
> > +
> > +   cfspi->regs = (struct dspi *)plat->regs_addr;
> > +
> > +   cfspi->baudrate = plat->speed_hz;
> > +   cfspi->mode = plat->mode;
> > +
> > +   for (i = 0; i < MCF_DSPI_MAX_CTAR_REGS; i++) {
> > +   unsigned int ctar = 0;
> > +
> > +   if (plat->ctar[i][0] == 0)
> > +   break;
> > +
> > +   ctar = DSPI_CTAR_TRSZ(plat->ctar[i][0]) |
> > +   DSPI_CTAR_PCSSCK(plat->ctar[i][1]) |
> > +   DSPI_CTAR_PASC(plat->ctar[i][2]) |
> > +   DSPI_CTAR_PDT(plat->ctar[i][3]) |
> > +   DSPI_CTAR_CSSCK(plat->ctar[i][4]) |
> > +   DSPI_CTAR_ASC(plat->ctar[i][5]) |
> > +   DSPI_CTAR_DT(plat->ctar[i][6]) |
> > +   DSPI_CTAR_BR(plat->ctar[i][7]);
> > +
> > +   writel(ctar, >regs->ctar[i]);
> > +   }
> > +
> > +   __spi_init(cfspi);
> > +
> > +   return 0;
> >  }
> > -#endif /* CONFIG_CMD_SPI */
> > +
> > +static int coldfire_dspi_ofdata_to_platdata(struct udevice *bus)
> 
> If you want to support platdata, it shouldn't available for DT so add
> ifdef 

Re: [U-Boot] [PATCH 4/5] arm: remove prototype for get_timer_masked

2018-10-10 Thread Linus Walleij
On Fri, Oct 5, 2018 at 11:34 AM Patrick Delaunay
 wrote:

> The interruption support had be removed for ARM architecture and
> the function get_timer_masked() is no more used except in some
> the timer.c files.
>
> This patch clean each timer.c which implement this function and
> remove the associated prototype in u-boot-arm.h
>
> For timer.c, I don't verify if the weak version of get_timer
> (in lib/time.c) can be used
>
> Signed-off-by: Patrick Delaunay 

Looks good to me.
Acked-by: Linus Walleij 

Yours,
Linus Walleij
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] arm: mx5: Add LDB clock config code

2018-10-10 Thread Marek Vasut
On 10/09/2018 10:27 PM, Stefano Babic wrote:
> Hi Marek,
> 
> On 04/10/2018 21:17, Marek Vasut wrote:
>> Add code to configure PLL4, from which the LDB clock are directly
>> derived.
>>
>> Signed-off-by: Marek Vasut 
>> Cc: Stefano Babic 
>> ---
>>  arch/arm/include/asm/arch-mx5/clock.h |  1 +
>>  arch/arm/mach-imx/mx5/clock.c | 21 +
>>  2 files changed, 22 insertions(+)
>>
>> diff --git a/arch/arm/include/asm/arch-mx5/clock.h 
>> b/arch/arm/include/asm/arch-mx5/clock.h
>> index 0ecbdeede5..6f5ca5888a 100644
>> --- a/arch/arm/include/asm/arch-mx5/clock.h
>> +++ b/arch/arm/include/asm/arch-mx5/clock.h
>> @@ -38,6 +38,7 @@ enum mxc_clock {
>>  MXC_NFC_CLK,
>>  MXC_PERIPH_CLK,
>>  MXC_I2C_CLK,
>> +MXC_LDB_CLK,
>>  };
>>  
>>  u32 imx_get_uartclk(void);
>> diff --git a/arch/arm/mach-imx/mx5/clock.c b/arch/arm/mach-imx/mx5/clock.c
>> index 427cb12415..dcefc4276a 100644
>> --- a/arch/arm/mach-imx/mx5/clock.c
>> +++ b/arch/arm/mach-imx/mx5/clock.c
>> @@ -838,6 +838,23 @@ static int config_ddr_clk(u32 emi_clk)
>>  return 0;
>>  }
>>  
>> +static int config_ldb_clk(u32 ref, u32 freq)
>> +{
>> +int ret = 0;
>> +struct pll_param pll_param;
>> +
>> +memset(_param, 0, sizeof(struct pll_param));
>> +
>> +ret = calc_pll_params(ref, freq, _param);
>> +if (ret != 0) {
>> +printf("Error:Can't find pll parameters: %d\n",
>> +ret);
>> +return ret;
>> +}
>> +
>> +return config_pll_clk(PLL4_CLOCK, _param);
> 
> This patch breaks the ts4800 board because this is not defined. Can you
> take a look please ?

V2 is out.

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH V2] arm: mx5: Add LDB clock config code

2018-10-10 Thread Marek Vasut
Add code to configure PLL4, from which the LDB clock are directly
derived.

Signed-off-by: Marek Vasut 
Cc: Stefano Babic 
---
V2: Enable config_ldb_clk() for MX53 only by adding ifdef
---
 arch/arm/include/asm/arch-mx5/clock.h |  1 +
 arch/arm/mach-imx/mx5/clock.c | 29 +++
 2 files changed, 30 insertions(+)

diff --git a/arch/arm/include/asm/arch-mx5/clock.h 
b/arch/arm/include/asm/arch-mx5/clock.h
index 0ecbdeede5..6f5ca5888a 100644
--- a/arch/arm/include/asm/arch-mx5/clock.h
+++ b/arch/arm/include/asm/arch-mx5/clock.h
@@ -38,6 +38,7 @@ enum mxc_clock {
MXC_NFC_CLK,
MXC_PERIPH_CLK,
MXC_I2C_CLK,
+   MXC_LDB_CLK,
 };
 
 u32 imx_get_uartclk(void);
diff --git a/arch/arm/mach-imx/mx5/clock.c b/arch/arm/mach-imx/mx5/clock.c
index 427cb12415..2fabdd2eae 100644
--- a/arch/arm/mach-imx/mx5/clock.c
+++ b/arch/arm/mach-imx/mx5/clock.c
@@ -838,6 +838,31 @@ static int config_ddr_clk(u32 emi_clk)
return 0;
 }
 
+#ifdef CONFIG_MX53
+static int config_ldb_clk(u32 ref, u32 freq)
+{
+   int ret = 0;
+   struct pll_param pll_param;
+
+   memset(_param, 0, sizeof(struct pll_param));
+
+   ret = calc_pll_params(ref, freq, _param);
+   if (ret != 0) {
+   printf("Error:Can't find pll parameters: %d\n",
+   ret);
+   return ret;
+   }
+
+   return config_pll_clk(PLL4_CLOCK, _param);
+}
+#else
+static int config_ldb_clk(u32 ref, u32 freq)
+{
+   /* Platform not supported */
+   return -EINVAL;
+}
+#endif
+
 /*
  * This function assumes the expected core clock has to be changed by
  * modifying the PLL. This is NOT true always but for most of the times,
@@ -879,6 +904,10 @@ int mxc_set_clock(u32 ref, u32 freq, enum mxc_clock clk)
if (config_nfc_clk(freq))
return -EINVAL;
break;
+   case MXC_LDB_CLK:
+   if (config_ldb_clk(ref, freq))
+   return -EINVAL;
+   break;
default:
printf("Warning:Unsupported or invalid clock type\n");
}
-- 
2.18.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


  1   2   >