Re: [U-Boot] [PATCH v3] dm: core: Enable optional use of fdt_translate_address()

[Bin Meng]

Hi Stefan,

On Thu, Dec 3, 2015 at 10:12 PM, Stefan Roese  wrote:
> Hi Bin,
>
>
> On 03.12.2015 14:34, Bin Meng wrote:
>>
>> Hi Stefan, Simon,
>>
>> On Mon, Oct 19, 2015 at 7:16 AM, Simon Glass  wrote:
>>>
>>> On 29 September 2015 at 23:00, Stefan Roese  wrote:

 The current "simple" address translation simple_bus_translate() is not
 working on some platforms (e.g. MVEBU). As here more complex "ranges"
 properties are used in many nodes (multiple tuples etc). This patch
 enables the optional use of the common fdt_translate_address() function
 which handles this translation correctly.

 Signed-off-by: Stefan Roese 
 Cc: Simon Glass 
 Cc: Bin Meng 
 Cc: Marek Vasut 
 Cc: Masahiro Yamada 
 Cc: Stephen Warren 
 Cc: Lukasz Majewski 
 ---
 v3:
 - Rebased on current U-Boot version
 - Added Stephen and Lukasz to Cc

 v2:
 - Rework code a bit as suggested by Simon. Also added some comments
to make the use of the code paths more clear.

   drivers/core/Kconfig  | 30 ++
   drivers/core/device.c | 20 
   2 files changed, 50 insertions(+)
>>>
>>>
>>> Applied to u-boot-dm, thanks!
>>
>>
>> When testing Simon's patch [1], I found PCI UART on Intel Crown Bay no
>> longer works. git bisect leads to this commit. Somehow I missed this
>> patch before although I see the commit message get me cc'ed but the
>> email did not bring to my attention.
>>
>> I see this patch introduced OF_TRANSLATE and by default set it to y.
>> This makes the code logic in dev_get_addr() go through
>> fdt_translate_address(), which breaks the things.
>
>
> I'm a bit surprised that using the common fdt_translate_address()
> function instead of the DM internal simple_bus_translate() causes
> problems on your platform. Are you sure that the ranges are
> described correctly in your dts? Is the dts a copy from the Linux
> original one? Ah, probably not, since we're talking about x86
> which has no DT support in Linux, right?
>

Is fdt_translate_address() able to handle PCI bus ranges property? PCI
has special ranges.

The arch/x86/dts/crownbay.dts has something like below:

 90 pci {
 91 #address-cells = <3>;
 92 #size-cells = <2>;
 93 compatible = "pci-x86";
 94 u-boot,dm-pre-reloc;
 95 ranges = <0x0200 0x0 0x4000 0x4000 0 0x8000
 96   0x4200 0x0 0xc000 0xc000 0 0x2000
 97   0x0100 0x0 0x2000 0x2000 0 0xe000>;
 98
 99 pcie@17,0 {
100 #address-cells = <3>;
101 #size-cells = <2>;
102 compatible = "pci-bridge";
103 u-boot,dm-pre-reloc;
104 reg = <0xb800 0x0 0x0 0x0 0x0>;

>> Should we set
>> OF_TRANSLATE to n by default? If set to y, this requires dts to have
>> complete ranges property everywhere.
>
>
> My understanding here is that x86 is a special case. As it doesn't
> use the full-blown dts sources from Linux. But most likely some
> "simple" ones, written exactly for U-Boot / DM.
>
> I would still prefer to have this OF_TRANSLATE set to y as default.
> As its needed for at least some platforms. But if we decide to
> set it to n, I can live with it as well.
>

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

Re: [U-Boot] [PATCH v3] dm: core: Enable optional use of fdt_translate_address()

[Stefan Roese]

Hi Bin,

On 04.12.2015 07:17, Bin Meng wrote:

Hi,

On Fri, Dec 4, 2015 at 1:31 PM, Bin Meng  wrote:

Hi Stefan,

On Thu, Dec 3, 2015 at 10:12 PM, Stefan Roese  wrote:

Hi Bin,


On 03.12.2015 14:34, Bin Meng wrote:


Hi Stefan, Simon,

On Mon, Oct 19, 2015 at 7:16 AM, Simon Glass  wrote:


On 29 September 2015 at 23:00, Stefan Roese  wrote:


The current "simple" address translation simple_bus_translate() is not
working on some platforms (e.g. MVEBU). As here more complex "ranges"
properties are used in many nodes (multiple tuples etc). This patch
enables the optional use of the common fdt_translate_address() function
which handles this translation correctly.

Signed-off-by: Stefan Roese 
Cc: Simon Glass 
Cc: Bin Meng 
Cc: Marek Vasut 
Cc: Masahiro Yamada 
Cc: Stephen Warren 
Cc: Lukasz Majewski 
---
v3:
- Rebased on current U-Boot version
- Added Stephen and Lukasz to Cc

v2:
- Rework code a bit as suggested by Simon. Also added some comments
to make the use of the code paths more clear.

   drivers/core/Kconfig  | 30 ++
   drivers/core/device.c | 20 
   2 files changed, 50 insertions(+)



Applied to u-boot-dm, thanks!



When testing Simon's patch [1], I found PCI UART on Intel Crown Bay no
longer works. git bisect leads to this commit. Somehow I missed this
patch before although I see the commit message get me cc'ed but the
email did not bring to my attention.

I see this patch introduced OF_TRANSLATE and by default set it to y.
This makes the code logic in dev_get_addr() go through
fdt_translate_address(), which breaks the things.



I'm a bit surprised that using the common fdt_translate_address()
function instead of the DM internal simple_bus_translate() causes
problems on your platform. Are you sure that the ranges are
described correctly in your dts? Is the dts a copy from the Linux
original one? Ah, probably not, since we're talking about x86
which has no DT support in Linux, right?



Is fdt_translate_address() able to handle PCI bus ranges property? PCI
has special ranges.

The arch/x86/dts/crownbay.dts has something like below:

  90 pci {
  91 #address-cells = <3>;
  92 #size-cells = <2>;
  93 compatible = "pci-x86";
  94 u-boot,dm-pre-reloc;
  95 ranges = <0x0200 0x0 0x4000 0x4000 0 0x8000
  96   0x4200 0x0 0xc000 0xc000 0 0x2000
  97   0x0100 0x0 0x2000 0x2000 0 0xe000>;
  98
  99 pcie@17,0 {
100 #address-cells = <3>;
101 #size-cells = <2>;
102 compatible = "pci-bridge";
103 u-boot,dm-pre-reloc;
104 reg = <0xb800 0x0 0x0 0x0 0x0>;


Should we set
OF_TRANSLATE to n by default? If set to y, this requires dts to have
complete ranges property everywhere.



My understanding here is that x86 is a special case. As it doesn't
use the full-blown dts sources from Linux. But most likely some
"simple" ones, written exactly for U-Boot / DM.

I would still prefer to have this OF_TRANSLATE set to y as default.
As its needed for at least some platforms. But if we decide to
set it to n, I can live with it as well.



Looks like the issue is:

dev_get_addr() return value is of type fdt_addr_t, and if no valid
address found returns FDT_ADDR_T_NONE. But FDT_ADDR_T_NONE is defined
as follows:

#ifdef CONFIG_PHYS_64BIT
#define FDT_ADDR_T_NONE (-1ULL)
#define fdt_addr_to_cpu(reg) be64_to_cpu(reg)
#define fdt_size_to_cpu(reg) be64_to_cpu(reg)
#else
#define FDT_ADDR_T_NONE (-1U)
#define fdt_addr_to_cpu(reg) be32_to_cpu(reg)
#define fdt_size_to_cpu(reg) be32_to_cpu(reg)
#endif

On x86, CONFIG_PHYS_64BIT is not defined, so FDT_ADDR_T_NONE becomes -1U.

In the ns16550 driver, the code logic is:

/* try Processor Local Bus device first */
addr = dev_get_addr(dev);
#ifdef CONFIG_PCI
 if (addr == FDT_ADDR_T_NONE) {
 /* then try pci device */

With OF_TRANSLATE set to y, dev_get_addr() returns OF_BAD_ADDR if no
valid address found, but OF_BAD_ADDR is defined as:

#define OF_BAD_ADDR ((u64)-1)

This creates a size mismatch as FDT_ADDR_T_NONE can be -1U or -1ULL
depending on CONFIG_PHYS_64BIT but OF_BAD_ADDR is always -1ULL.

The patch below fixes this issue:

diff --git a/common/fdt_support.c b/common/fdt_support.c
index f86365e..8930f34 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -16,6 +16,7 @@
  #include 
  #include 
  #include 
+#include 

  /**
   * fdt_getprop_u32_default_node - Return a node's property or a default
@@ -945,7 +946,7 @@ void fdt_del_node_and_alias(void *blob, const char *alias)

  /* Max address size we deal 

Re: [U-Boot] [PATCH] dm: core: Add platform specific bus translation function

[Stefan Roese]

Hi Simon,

On 03.12.2015 18:21, Simon Glass wrote:
> Hi Stefan,
> 
> On 3 December 2015 at 04:31, Stefan Roese  wrote:
>>
>> Hi Simon,
>>
>> On 02.12.2015 18:45, Simon Glass wrote:
>>> Hi Stefan,
>>>
>>> On 2 December 2015 at 10:43, Stefan Roese  wrote:
 Hi Simon,

 ( Last mail for tonight - a glass of quite nice red wine is
 waiting for me ... ;) )

>>>
>>> That's the only sad thing about me being so many hours behind. Still I
>>> can do the same thing with people in Asia I suppose :-)
>>
>> Right. I'm not sure about the wine quality in Asia though... ;)
>>

 On 02.12.2015 17:53, Simon Glass wrote:
>
> Hi Stefan,
>
> On 2 December 2015 at 09:00, Stefan Roese  wrote:
>>
>>
>> Hi Simon,
>>
>> On 02.12.2015 16:50, Simon Glass wrote:
>>
>> 
>>
> I think it would be better to make it depend on whether the bit is
> flipped, rather than whether you are in SPL or not.



 You simply can't detect if this "bit is flipped". You just have
 to know. This is a long lasting ugly thing on some Marvell
 patforms. Here the comment from armada-xp-gp.dts:
>>>
>>>
>>>
>>> Can you point me to the place in U-Boot where this bit is flipped?
>>> Something, somewhere has to make the change. So something has to know.
>>> Before it makes the change, the range works one way. Afterwards it
>>> works another way.
>>
>>
>>
>> Sure. I've mentioned this before. Its here:
>>
>> arch/arm/mach-mvebu/cpu.c:
>>
>> int arch_cpu_init(void)
>> {
>>...
>>
>>/* Linux expects the internal registers to be at 0xf100 */
>>writel(SOC_REGS_PHY_BASE, INTREG_BASE_ADDR_REG);
>>
>> This is the line that changes the register base address. And
>> to change it back you need to write to the new address, as the
>> address holding this base address is also moved. Quite ugly!
>>
>> So its really right at the start of U-Boot proper.
>
>
> OK I see. So really we can determine which way the address 'switch'
> it. It's just a case of making the change when we are ready, and
> keeping a record of that.


 Yes. But how is the "common code" in dev_get_addr() supposed to know
 which version of U-Boot we are running on? This boils down to some
 callback again, or not? Or even worse the ugly #ifdef.
>>>
>>> You would call a driver-model core function to select the ranges
>>> property to prefer. Then driver model will remember this setting and
>>> use it.
>>
>> Yes. This can be done. I've taken the time to implement such a
>> version. And attached a small patch in a hackish version, just as
>> an RFC. As you will see, I've added the "ranges-spl" property to
>> some of the DT nodes. And added the DM core functions to enable to
>> usage of a different, non-standard "ranges" property name.
>>
>> All this is not really "clean" and will definitely break non-DM
>> usage of fdt_support.c. Not sure where to go from here. I would
>> still prefer my first patch version, even though I know that
>> you don't like to add this hook / callback into the DM core code.
>>
>> Let me know what you think.
> 
> Actually that looks pretty good to me. I think the root uclass needs
> to grow a private struct, where you store the ranges name. It is
> slightly odd to have fdtdec calling back into DM, but I don't see a
> big problem with it. The two are strongly coupled anyway. You can put
> an #ifdef CONFIG_DM in fdtdec to solve your problem I suppose.

Its not only fdtdec.c but also fdt_support.c that needs this callback
into DM. And fdt_support.c is currently not coupled with DM at all.
Making this change generic, we really need to exchange all "ranges"
occurrences in the whole U-Boot source tree:

$ git grep "\"ranges\""
arch/powerpc/cpu/mpc85xx/portals.c: range = fdt_getprop_w(blob, 
off, "ranges", );
arch/powerpc/cpu/mpc85xx/portals.c: fdt_setprop_inplace(blob, off, 
"ranges", range, len);
arch/powerpc/cpu/ppc4xx/fdt.c:  rc = fdt_find_and_setprop(blob, ebc_path, 
"ranges", ranges,
arch/sparc/include/asm/prom.h:/* Element of the "ranges" vector */
board/ifm/o2dnt2/o2dnt2.c:  prop = fdt_get_property_w(blob, off, "ranges", 
);
board/ifm/o2dnt2/o2dnt2.c:  fdt_setprop(blob, off, "ranges", reg2, 
len);
board/intercontrol/digsy_mtc/digsy_mtc.c:   prop = fdt_get_property_w(blob, 
off, "ranges", );
board/intercontrol/digsy_mtc/digsy_mtc.c:   fdt_setprop(blob, off, 
"ranges", reg2, len);
board/pdm360ng/pdm360ng.c:  rc = fdt_find_and_setprop(blob, "/localbus", 
"ranges",
board/socrates/socrates.c:  rc = fdt_find_and_setprop(blob, "/localbus", 
"ranges",
common/fdt_support.c:   /* Normally, an absence of a "ranges" property means we 
are
common/fdt_support.c:* /ht nodes with no 

Re: [U-Boot] [PATCH v3 02/14] ARM: zynq: Remove CONFIG_API

[Michal Simek]

On 3.12.2015 17:09, Jagan Teki wrote:
> On 3 December 2015 at 20:17, Michal Simek  wrote:
>> CONFIG_API is causing compilation error when DM_ETH is enabled because
>> eth_get_dev() is not available.
> 
> Then how come, freebsd elf generate w/o CONFIG_API?

missing DM support there.

Thanks,
Michal

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

Re: [U-Boot] [linux-sunxi] [PATCH 1/2] sunxi: twi: enable clocks on sun7i

[Julian Calaby]

Hi Oliver,

On Fri, Dec 4, 2015 at 9:57 AM, Julian Calaby  wrote:
> Hi Oliver,
>
> On Fri, Dec 4, 2015 at 3:49 AM, Olliver Schinagl  wrote:
>> From: Olliver Schinagl 
>>
>> Commit 6c739c5d added code to enable i2c bus 4 and 5 on the sun7i SoC
>> but forgot to enable the clocks for these 2 i2c busses.
>>
>> This patch enables the clocks for i2c bus 4 and 5 on sun7i.
>>
>> Signed-off-by: Olliver Schinagl 
>> ---
>>  arch/arm/cpu/armv7/sunxi/clock_sun4i.c | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/arch/arm/cpu/armv7/sunxi/clock_sun4i.c 
>> b/arch/arm/cpu/armv7/sunxi/clock_sun4i.c
>> index 7c8eff9..ed910b1 100644
>> --- a/arch/arm/cpu/armv7/sunxi/clock_sun4i.c
>> +++ b/arch/arm/cpu/armv7/sunxi/clock_sun4i.c
>> @@ -67,7 +67,11 @@ int clock_twi_onoff(int port, int state)
>> struct sunxi_ccm_reg *const ccm =
>> (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
>>
>> +#ifdef CONFIG_MACH_SUN7I
>> +   if (port > 4)
>> +#else
>> if (port > 2)
>> +#endif
>
> Should the number here be a #define somewhere, or even a parameter for
> each version of this clock?

Wait, this is a u-boot patch, right? If so, ignore this and sorry for the noise.

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] imx: mx7dsabresd: Add QSPI support

[Jagan Teki]

On 4 December 2015 at 06:41, Peng Fan  wrote:
> Hi Jagan,
> On Thu, Dec 03, 2015 at 05:21:09PM +0530, Jagan Teki wrote:
>>On 30 November 2015 at 15:31, Stefano Babic  wrote:
>>> On 30/11/2015 10:45, Peng Fan wrote:
 Support qspi flashes for mx7dsabresd
 1. introduce pin mux settings
 2. enable qspi clock
 3. introduce related macro definitions

 Default QSPI is not enabled, since we need hardware rework to use QSPI,
 see SPF-28590, page 9:
 "
 QSPI signals are muxed with EPDC_D[7:0]
 When using QSPI: de-populate R388-R391, R396-R399
 populate R392-R395, R299, R300
 "

 After hardware rework, define CONFIG_FSL_QSPI in mx7dsabresd.h. qspi
 flashes can be deteced and read/erase/write. Log info:
 "
 => sf probe
 SF: Detected MX25L51235F with page size 256 Bytes, erase size 64 KiB, 
 total 64 MiB
 => sf read 0x8000 0 0x400
 device 0 whole chip
 SF: 67108864 bytes @ 0x0 Read: OK
 => sf erase 0 0x400
 SF: 67108864 bytes @ 0x0 Erased: OK
 => sf write 0x8000 0 0x400
 device 0 whole chip
 SF: 67108864 bytes @ 0x0 Written: OK
 "

 Signed-off-by: Peng Fan 
 Cc: Stefano Babic 
 Cc: Fabio Estevam 
 Cc: Adrian Alonso 
 ---
  board/freescale/mx7dsabresd/mx7dsabresd.c | 30 
 ++
  include/configs/mx7dsabresd.h | 15 +++
  2 files changed, 45 insertions(+)

 diff --git a/board/freescale/mx7dsabresd/mx7dsabresd.c 
 b/board/freescale/mx7dsabresd/mx7dsabresd.c
 index 6c863da..f8ae973 100644
 --- a/board/freescale/mx7dsabresd/mx7dsabresd.c
 +++ b/board/freescale/mx7dsabresd/mx7dsabresd.c
 @@ -44,6 +44,9 @@ DECLARE_GLOBAL_DATA_PTR;
  #define LCD_PAD_CTRL(PAD_CTL_HYS | PAD_CTL_PUS_PU100KOHM | \
   PAD_CTL_DSE_3P3V_49OHM)

 +#define QSPI_PAD_CTRL\
 + (PAD_CTL_DSE_3P3V_49OHM | PAD_CTL_PUE | PAD_CTL_PUS_PU47KOHM)
 +
  #ifdef CONFIG_SYS_I2C_MXC
  #define PC MUX_PAD_CTRL(I2C_PAD_CTRL)
  /* I2C1 for PMIC */
 @@ -455,6 +458,29 @@ int board_phy_config(struct phy_device *phydev)
  }
  #endif

 +#ifdef CONFIG_FSL_QSPI
 +static iomux_v3_cfg_t const quadspi_pads[] = {
 + MX7D_PAD_EPDC_DATA00__QSPI_A_DATA0 | MUX_PAD_CTRL(QSPI_PAD_CTRL),
 + MX7D_PAD_EPDC_DATA01__QSPI_A_DATA1 | MUX_PAD_CTRL(QSPI_PAD_CTRL),
 + MX7D_PAD_EPDC_DATA02__QSPI_A_DATA2 | MUX_PAD_CTRL(QSPI_PAD_CTRL),
 + MX7D_PAD_EPDC_DATA03__QSPI_A_DATA3 | MUX_PAD_CTRL(QSPI_PAD_CTRL),
 + MX7D_PAD_EPDC_DATA05__QSPI_A_SCLK  | MUX_PAD_CTRL(QSPI_PAD_CTRL),
 + MX7D_PAD_EPDC_DATA06__QSPI_A_SS0_B | MUX_PAD_CTRL(QSPI_PAD_CTRL),
 +};
 +
 +int board_qspi_init(void)
 +{
 + /* Set the iomux */
 + imx_iomux_v3_setup_multiple_pads(quadspi_pads,
 +  ARRAY_SIZE(quadspi_pads));
 +
 + /* Set the clock */
 + set_clk_qspi();
 +
 + return 0;
 +}
 +#endif
 +
  int board_early_init_f(void)
  {
   setup_iomux_uart();
 @@ -481,6 +507,10 @@ int board_init(void)
   setup_lcd();
  #endif

 +#ifdef CONFIG_FSL_QSPI
 + board_qspi_init();
 +#endif
>>
>>Can't we do this on drivers/spi/fsl_qspi.c ?
>
> Not for now. i.MX6/7 does not support to use device tree now, we do not have
> pinmux and clk info in driver code. In future, when pinmux and clk
> can be extracted using dtb, this code can be moved to fsl_qspi.c.
>
> Regards,
> Peng.
>
>>
 +
   return 0;
  }

 diff --git a/include/configs/mx7dsabresd.h b/include/configs/mx7dsabresd.h
 index cc98547..22e515c 100644
 --- a/include/configs/mx7dsabresd.h
 +++ b/include/configs/mx7dsabresd.h
 @@ -236,4 +236,19 @@
  #define CONFIG_VIDEO_BMP_LOGO
  #endif

 +#ifdef CONFIG_FSL_QSPI
 +#define CONFIG_CMD_SF
 +#define CONFIG_SPI_FLASH
 +#define CONFIG_SPI_FLASH_MACRONIX
 +#define CONFIG_SPI_FLASH_BAR
 +#define CONFIG_SF_DEFAULT_BUS0
 +#define CONFIG_SF_DEFAULT_CS 0
 +#define CONFIG_SF_DEFAULT_SPEED  4000
 +#define CONFIG_SF_DEFAULT_MODE   SPI_MODE_0
 +#define FSL_QSPI_FLASH_NUM   1
 +#define FSL_QSPI_FLASH_SIZE  SZ_64M
 +#define QSPI0_BASE_ADDR  QSPI1_IPS_BASE_ADDR
 +#define QSPI0_AMBA_BASE  QSPI0_ARB_BASE_ADDR
 +#endif
 +
  #endif   /* __CONFIG_H */

>>>
>>> Reviewed-by: Stefano Babic 

Reviewed-by: Jagan Teki 

thanks!
-- 
Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de

Re: [U-Boot] [PATCH] spi: ti_qspi: Use 4-byte opcode for mmap read

[Vignesh R]

On 12/03/2015 05:55 PM, Jagan Teki wrote:
> On Thursday 03 December 2015 05:51 PM, Vignesh R wrote:
>>
>>
>> On 12/03/2015 05:25 PM, Jagan Teki wrote:
>>> On 23 November 2015 at 17:43, Vignesh R  wrote:
 ti-qspi driver currently uses 3-byte addressing mode(and opcodes) for
 memory-mapped read. This restricts maximum addressable flash size to
 16MB.
 Enable the 4-byte addressing(and use 4-byte opcode) for memory-mapped
 read to allow access to addresses above 16MB.
>>>
>>> What about sf side, since we don't have 4-byte opcode support yet?
>>>
>>
>> Well, the sf is accessing >16MB address space using EXT_ADDR registers
>> via BAR support (for regular spi read/write). But, memory-mapped read
>> doesn't support using EXT_ADDR, hence 4-byte opcode needs to be used for
>> during mmap transfers to access >16MB.
> 
> So, there is no need to have 4-byte opcode support from sf side for
> memory-mapped reads - true?
> 

Yes, AFAIU, there is no programming required on the sf side to use
4-byte addressing opcode (I have tested this on Macronix MX66L51235F and
Spansion S25FL256S)

>>

 Signed-off-by: Ravi Babu 
 [vigne...@ti.com: Re-word commit description]
 Signed-off-by: Vignesh R 

 ---

 Tested on DRA74 EVM with Spansion flash and AM437X IDK EVM with
 Macronix
 flash.

   drivers/spi/ti_qspi.c | 6 +++---
   1 file changed, 3 insertions(+), 3 deletions(-)

 diff --git a/drivers/spi/ti_qspi.c b/drivers/spi/ti_qspi.c
 index 646dd899d3ec..0a032845866d 100644
 --- a/drivers/spi/ti_qspi.c
 +++ b/drivers/spi/ti_qspi.c
 @@ -48,14 +48,14 @@
   #define CORE_CTRL_IO0x4a002558

   #define QSPI_CMD_READ   (0x3 << 0)
 -#define QSPI_CMD_READ_QUAD  (0x6b << 0)
 +#define QSPI_CMD_READ_QUAD  (0x6c << 0)
   #define QSPI_CMD_READ_FAST  (0x0b << 0)
 -#define QSPI_SETUP0_NUM_A_BYTES (0x2 << 8)
 +#define QSPI_SETUP0_NUM_A_BYTES (0x3 << 8)
   #define QSPI_SETUP0_NUM_D_BYTES_NO_BITS (0x0 << 10)
   #define QSPI_SETUP0_NUM_D_BYTES_8_BITS  (0x1 << 10)
   #define QSPI_SETUP0_READ_NORMAL (0x0 << 12)
   #define QSPI_SETUP0_READ_QUAD   (0x3 << 12)
 -#define QSPI_CMD_WRITE  (0x2 << 16)
 +#define QSPI_CMD_WRITE  (0x12 << 16)
   #define QSPI_NUM_DUMMY_BITS (0x0 << 24)

   /* ti qspi register set */
 -- 
 2.6.3
> 
> thanks!
> -- 
> Jagan.

-- 
Regards
Vignesh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 12/14] net: gem: Move driver to DM

[Bin Meng]

On Thu, Dec 3, 2015 at 10:48 PM, Michal Simek  wrote:
> - Enable DM_ETH by default for Zynq and ZynqMP
> - Remove board_eth_init code
> - Change miiphy_read function to return value instead of error code
>   based on DM requirement
> - Do not enable EMIO DT support by default
>
> Signed-off-by: Michal Simek 
> ---
>
> Changes in v3:
> - Add remove function reported by Bin Meng
>
> Changes in v2:
> - Remove accidentially added mmc code
> - Sort dm.h header
> - add platdata_auto_alloc_size
> - Read iobase from pdata instead of via gev_get_addr
> - Check positive return value from fdtdec_lookup_phandles instead of -1
>

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

Re: [U-Boot] [PATCH v2 04/26] dm: pci: Use driver model PCI API in auto-config

[Bin Meng]

On Mon, Nov 30, 2015 at 4:17 AM, Simon Glass  wrote:
> At present we are using legacy functions even in the auto-configuration code
> used by driver model. Add a new pci_auto.c version which uses the correct
> API.
>
> Create a new pci_internal.h header to hold functions that are used within
> the PCI subsystem, but are not exported to other drivers.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2:
> - Add a new pci_internal.h header file for internal PCI functions
> - Drop unnecessary comment at the top of pci_auto.c
> - Fix the indentation of the 'bar' for() loop
>

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

[U-Boot] [PATCH 4/5][v3] armv8/ls1043ardb: SECURE BOOT target added for NOR

[Aneesh Bansal]

LS1043ARDB Secure Boot Target from NOR has been added.
- Configs defined to enable esbc_validate.
- ESBC Address in header is made 64 bit.
- SMMU is re-configured in Bypass mode.

Signed-off-by: Aneesh Bansal 
---
Changes in v3:
- Enabled CONFIG_SYS_NS16550=y, CONFIF_DM=y and other options
  similar to ls1043ardb_defconfig.
- fsl_secure_boot.h is included outside of ifdef in file
  include/configs/ls1043ardb.h

 arch/arm/include/asm/arch-fsl-layerscape/config.h  |  4 +--
 .../include/asm/arch-fsl-layerscape/immap_lsch2.h  |  2 +-
 arch/arm/include/asm/fsl_secure_boot.h |  6 +++-
 board/freescale/common/fsl_validate.c  | 35 +-
 board/freescale/ls1043ardb/MAINTAINERS |  5 
 board/freescale/ls1043ardb/ls1043ardb.c| 18 ++-
 common/cmd_blob.c  |  6 ++--
 configs/ls1043ardb_SECURE_BOOT_defconfig   |  9 ++
 include/configs/ls1043ardb.h   | 10 +++
 include/fsl_validate.h |  9 +-
 10 files changed, 81 insertions(+), 23 deletions(-)
 create mode 100644 configs/ls1043ardb_SECURE_BOOT_defconfig

diff --git a/arch/arm/include/asm/arch-fsl-layerscape/config.h 
b/arch/arm/include/asm/arch-fsl-layerscape/config.h
index b5a2d28..6f4773a 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/config.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/config.h
@@ -147,8 +147,8 @@
 #define CONFIG_SYS_FSL_PCIE_COMPAT "fsl,qoriq-pcie-v2.4"
 
 #define CONFIG_SYS_FSL_SFP_VER_3_2
-#define CONFIG_SYS_FSL_SNVS_LE
-#define CONFIG_SYS_FSL_SEC_LE
+#define CONFIG_SYS_FSL_SEC_MON_BE
+#define CONFIG_SYS_FSL_SEC_BE
 #define CONFIG_SYS_FSL_SFP_BE
 #define CONFIG_SYS_FSL_SRK_LE
 #define CONFIG_KEY_REVOCATION
diff --git a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h 
b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
index 83caa91..e7def3a 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
@@ -38,7 +38,7 @@
 #define CONFIG_SYS_PCIE3_ADDR  (CONFIG_SYS_IMMR + 0x260)
 #define CONFIG_SYS_FSL_SEC_ADDR(CONFIG_SYS_IMMR + 
0x70)
 #define CONFIG_SYS_FSL_JR0_ADDR(CONFIG_SYS_IMMR + 
0x71)
-#define CONFIG_SYS_SNVS_ADDR   (CONFIG_SYS_IMMR + 0xe9)
+#define CONFIG_SYS_SEC_MON_ADDR(CONFIG_SYS_IMMR + 
0xe9)
 #define CONFIG_SYS_SFP_ADDR(CONFIG_SYS_IMMR + 0xe80200)
 
 #define CONFIG_SYS_FSL_TIMER_ADDR  0x02b0
diff --git a/arch/arm/include/asm/fsl_secure_boot.h 
b/arch/arm/include/asm/fsl_secure_boot.h
index f2d4c3c..806302b 100644
--- a/arch/arm/include/asm/fsl_secure_boot.h
+++ b/arch/arm/include/asm/fsl_secure_boot.h
@@ -11,13 +11,17 @@
 #define CONFIG_CMD_ESBC_VALIDATE
 #define CONFIG_FSL_SEC_MON
 #define CONFIG_SHA_PROG_HW_ACCEL
-#define CONFIG_DM
 #define CONFIG_RSA
 #define CONFIG_RSA_FREESCALE_EXP
+
 #ifndef CONFIG_FSL_CAAM
 #define CONFIG_FSL_CAAM
 #endif
 
+#ifndef CONFIG_DM
+#define CONFIG_DM
+#endif
+
 #define CONFIG_KEY_REVOCATION
 #ifndef CONFIG_SYS_RAMBOOT
 /* The key used for verification of next level images
diff --git a/board/freescale/common/fsl_validate.c 
b/board/freescale/common/fsl_validate.c
index 73b6718..733aa48 100644
--- a/board/freescale/common/fsl_validate.c
+++ b/board/freescale/common/fsl_validate.c
@@ -15,9 +15,6 @@
 #include 
 #include 
 #include 
-#ifndef CONFIG_MPC85xx
-#include 
-#endif
 
 #define SHA256_BITS256
 #define SHA256_BYTES   (256/8)
@@ -99,7 +96,8 @@ int get_csf_base_addr(u32 *csf_addr, u32 *flash_base_addr)
struct ccsr_gur __iomem *gur = (void *)(CONFIG_SYS_FSL_GUTS_ADDR);
u32 csf_hdr_addr = in_be32(>scratchrw[0]);
 
-   if (memcmp((u8 *)csf_hdr_addr, barker_code, ESBC_BARKER_LEN))
+   if (memcmp((u8 *)(uintptr_t)csf_hdr_addr,
+  barker_code, ESBC_BARKER_LEN))
return -1;
 
*csf_addr = csf_hdr_addr;
@@ -117,7 +115,7 @@ static int get_ie_info_addr(u32 *ie_addr)
if (get_csf_base_addr(_addr, _base_addr))
return -1;
 
-   hdr = (struct fsl_secboot_img_hdr *)csf_addr;
+   hdr = (struct fsl_secboot_img_hdr *)(uintptr_t)csf_addr;
 
/* For SoC's with Trust Architecture v1 with corenet bus
 * the sg table field in CSF header has absolute address
@@ -130,7 +128,7 @@ static int get_ie_info_addr(u32 *ie_addr)
 (((u32)hdr->psgtable & ~(CONFIG_SYS_PBI_FLASH_BASE)) +
  flash_base_addr);
 #else
-   sg_tbl = (struct fsl_secboot_sg_table *)(csf_addr +
+   sg_tbl = (struct fsl_secboot_sg_table *)(uintptr_t)(csf_addr +
 (u32)hdr->psgtable);
 #endif
 
@@ -379,8 +377,8 @@ static int calc_img_key_hash(struct fsl_secboot_img_priv 
*img)
 #ifdef CONFIG_KEY_REVOCATION
if 

Re: [U-Boot] [PATCH v7 00/34] sf: MTD support

[Jagan Teki]

Hi Simon,

On 1 December 2015 at 04:47, Simon Glass  wrote:
> Hi Jagan,
>
> On 27 November 2015 at 02:21, Jagan Teki  wrote:
>> Hi Bin,
>>
>> On 27 November 2015 at 07:55, Bin Meng  wrote:
>>> Hi Jagan,
>>>
>>> On Fri, Nov 27, 2015 at 2:54 AM, Jagan Teki  wrote:
 Hi Simon,

 Some how I'm unclear about your comments in previous series probably I
 my misunderstanding or something. let me explain about my plan on
 spi-nor development.

 The entire spi-flash code is generic for all means there is no
 separate code for any platform or device. So I call it as spi-flash
 core. spi-flash core having functionaries like read_jedec, flash
 read/write/erase all these were calling from cmd_sf using dm and
 non-dm version, here I'm replacing this MTD since it is core interface
 it doesn't handle any specific device or uclass and mtd operations are
 being used directly without any dm except the probe.

 So spi-flash shouldn't need dm and the respective probe sf_probe will
 follow dm as it allocates spi_flash and by taking spi_slave{} setup
 spi-uclass. spi-flash operation are common and there is no different
 ops for different drivers or devices or something and mtd_ops are
 manged directly from cmd_sf like nand and spi-nor in Linux.

 And once core sits stable spi-flash will implemented as spi-nor core
 and the bellowed drivers becomes spi-nor drivers like spi-nor to spi
 driver interface and spi-nor controller drivers these are dm-driven
 it's having dm ops similar to spi-flash ops and spi-flash no where
 required.
>>>
>>> My understanding is that when we introduce a new driver feature, it
>>> should target driver model by default. This is to encourage boards to
>>> take advantage of driver model, and all these *new* features. This is
>>> what Simon asked for. As Simon mentioned, probably we should make the
>>> SPI flash DM conversion complete now instead of adding any new feature
>>> on top of it.
>>
>> I'm not introduced any new driver feature here, instead I re-used the
>> existing mtd core features and functionalities.
>>
>> The current code looks as below:
>> 
>> sf_probe.c:
>> 1) having both non-dm and dm spi-flash and calls to
>> 2) spi_flash_probe_slave for spi_flash detection and setting up hooks
>> (spi_flash ops)
>>
>> sf_ops.c:
>> 1) having all spi_flash ops definitions.
>>
>> These are the changes I did
>> a) Moved spi_flash probing like definition of  spi_flash_probe_slave
>> from sf_probe.c to sf_ops.c so sf_ops.c having all core spi-flash code
>> like flash detection, setting up hooks (spi_flash ops) and spi_flash
>> ops definitions.
>> b) from above point a) sf_probe.c having both dm and non-dm interface
>> with a common call to sf_ops.c for spi-flash core functionalities
>> using spi_flash_scan.
>> c) Replaced existing spi_flash_mtd_register (sf_mtd.c) registration
>> with generic mtd core using add_mtd_device in sf_probe.c for both dm
>> and non-dm interfaces.
>> d) In sf_ops.c Updated all mtd_info structure filling and replaced
>> spi_flash ops hooks with mtd_info hooks - where dm_spi_flash_ops got
>> dropped.
>> e) Called mtd core operations from spi_flash.h like
>> mtd_erase|write|read instead of direct calls to sf_ops.c with
>> spi_flash operation as they are not needed, so mtd core calls will in
>> turn call mtd hooks on spi-flash like nand, cfi and spi-nor in Linux.
>>
>> The code after these changes:
>> 
>> sf_probe.c:
>> 1) having both non-dm and dm spi-flash and calls to
>> 2) spi_flash_scan for spi-flash core functionalities and register with core 
>> mtd.
>>
>> sf_ops.c:
>> 1) core spi-flash operations => spi_flash detection + setting up hooks
>> (mtd ops) + having all mtd_info ops definitions.
>>
>> I couldn't understand what's wrong with this approach, because I have
>> not added any new feature instead I reused it existing MTD core. I
>> agree that the dm_spi_flash_ops are removed as mtd_info ops are used
>> instead and sf_probe.c is still with dm.
>>
>> Please let me know your inputs.
>
> Conceptually this seems problematic.
>
> SPI flash is a uclass and supports driver model. It has operations,
> etc. Your patches remove the operations in favour of calling MTD. But
> MTD does not support driver model. This is getting really messy.
>
> Before going any further we need to at least figure out the end goal.
>
> To repeat my question from the previous email:

Please continue your comments on separate on this thread
"[U-Boot] dm: Introduce SPI-NOR framework"

>
> Is it intended that SPI flash should be a driver for the MTD uclass?
> Others would be NAND and CFI. From what I can tell MTD has the same
> operations as SPI flash (erase, read, write) and adds a lot more.
>
> Or is SPI flash really a separate uclass from MTD, with SPI 

Re: [U-Boot] [PATCH] spi: ti_qspi: Use 4-byte opcode for mmap read

[Vignesh R]

On 12/03/2015 05:25 PM, Jagan Teki wrote:
> On 23 November 2015 at 17:43, Vignesh R  wrote:
>> ti-qspi driver currently uses 3-byte addressing mode(and opcodes) for
>> memory-mapped read. This restricts maximum addressable flash size to
>> 16MB.
>> Enable the 4-byte addressing(and use 4-byte opcode) for memory-mapped
>> read to allow access to addresses above 16MB.
> 
> What about sf side, since we don't have 4-byte opcode support yet?
> 

Well, the sf is accessing >16MB address space using EXT_ADDR registers
via BAR support (for regular spi read/write). But, memory-mapped read
doesn't support using EXT_ADDR, hence 4-byte opcode needs to be used for
during mmap transfers to access >16MB.

>>
>> Signed-off-by: Ravi Babu 
>> [vigne...@ti.com: Re-word commit description]
>> Signed-off-by: Vignesh R 
>>
>> ---
>>
>> Tested on DRA74 EVM with Spansion flash and AM437X IDK EVM with Macronix
>> flash.
>>
>>  drivers/spi/ti_qspi.c | 6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/spi/ti_qspi.c b/drivers/spi/ti_qspi.c
>> index 646dd899d3ec..0a032845866d 100644
>> --- a/drivers/spi/ti_qspi.c
>> +++ b/drivers/spi/ti_qspi.c
>> @@ -48,14 +48,14 @@
>>  #define CORE_CTRL_IO0x4a002558
>>
>>  #define QSPI_CMD_READ   (0x3 << 0)
>> -#define QSPI_CMD_READ_QUAD  (0x6b << 0)
>> +#define QSPI_CMD_READ_QUAD  (0x6c << 0)
>>  #define QSPI_CMD_READ_FAST  (0x0b << 0)
>> -#define QSPI_SETUP0_NUM_A_BYTES (0x2 << 8)
>> +#define QSPI_SETUP0_NUM_A_BYTES (0x3 << 8)
>>  #define QSPI_SETUP0_NUM_D_BYTES_NO_BITS (0x0 << 10)
>>  #define QSPI_SETUP0_NUM_D_BYTES_8_BITS  (0x1 << 10)
>>  #define QSPI_SETUP0_READ_NORMAL (0x0 << 12)
>>  #define QSPI_SETUP0_READ_QUAD   (0x3 << 12)
>> -#define QSPI_CMD_WRITE  (0x2 << 16)
>> +#define QSPI_CMD_WRITE  (0x12 << 16)
>>  #define QSPI_NUM_DUMMY_BITS (0x0 << 24)
>>
>>  /* ti qspi register set */
>> --
>> 2.6.3
>>
> 
> thanks!
> 

-- 
Regards
Vignesh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] dm: core: Distinguish between OF_TRANSLATE and SPL_OF_TRANSLATE

[Stefan Roese]

On 03.12.2015 12:12, Michal Simek wrote:

Kconfig description is the same for both. Extend SPL one to indicate
that this option is for SPL only.

Signed-off-by: Michal Simek 
---

  drivers/core/Kconfig | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/core/Kconfig b/drivers/core/Kconfig
index 15681df6d379..b68a26ffcea3 100644
--- a/drivers/core/Kconfig
+++ b/drivers/core/Kconfig
@@ -136,7 +136,7 @@ config OF_TRANSLATE
  smaller in size than fdt_translate_address().

  config SPL_OF_TRANSLATE
-   bool "Translate addresses using fdt_translate_address"
+   bool "Translate addresses using fdt_translate_address in SPL"
depends on SPL_DM && SPL_OF_CONTROL
default n
help


Yes, I've already sent a patch for this:

http://patchwork.ozlabs.org/patch/549077/

Thanks,
Stefan

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

Re: [U-Boot] [PATCH] dm: core: Add platform specific bus translation function

[Stefan Roese]

Hi Simon,

On 02.12.2015 18:45, Simon Glass wrote:
> Hi Stefan,
> 
> On 2 December 2015 at 10:43, Stefan Roese  wrote:
>> Hi Simon,
>>
>> ( Last mail for tonight - a glass of quite nice red wine is
>> waiting for me ... ;) )
>>
> 
> That's the only sad thing about me being so many hours behind. Still I
> can do the same thing with people in Asia I suppose :-)

Right. I'm not sure about the wine quality in Asia though... ;)
 
>>
>> On 02.12.2015 17:53, Simon Glass wrote:
>>>
>>> Hi Stefan,
>>>
>>> On 2 December 2015 at 09:00, Stefan Roese  wrote:


 Hi Simon,

 On 02.12.2015 16:50, Simon Glass wrote:

 

>>> I think it would be better to make it depend on whether the bit is
>>> flipped, rather than whether you are in SPL or not.
>>
>>
>>
>> You simply can't detect if this "bit is flipped". You just have
>> to know. This is a long lasting ugly thing on some Marvell
>> patforms. Here the comment from armada-xp-gp.dts:
>
>
>
> Can you point me to the place in U-Boot where this bit is flipped?
> Something, somewhere has to make the change. So something has to know.
> Before it makes the change, the range works one way. Afterwards it
> works another way.



 Sure. I've mentioned this before. Its here:

 arch/arm/mach-mvebu/cpu.c:

 int arch_cpu_init(void)
 {
   ...

   /* Linux expects the internal registers to be at 0xf100 */
   writel(SOC_REGS_PHY_BASE, INTREG_BASE_ADDR_REG);

 This is the line that changes the register base address. And
 to change it back you need to write to the new address, as the
 address holding this base address is also moved. Quite ugly!

 So its really right at the start of U-Boot proper.
>>>
>>>
>>> OK I see. So really we can determine which way the address 'switch'
>>> it. It's just a case of making the change when we are ready, and
>>> keeping a record of that.
>>
>>
>> Yes. But how is the "common code" in dev_get_addr() supposed to know
>> which version of U-Boot we are running on? This boils down to some
>> callback again, or not? Or even worse the ugly #ifdef.
> 
> You would call a driver-model core function to select the ranges
> property to prefer. Then driver model will remember this setting and
> use it.

Yes. This can be done. I've taken the time to implement such a
version. And attached a small patch in a hackish version, just as
an RFC. As you will see, I've added the "ranges-spl" property to
some of the DT nodes. And added the DM core functions to enable to
usage of a different, non-standard "ranges" property name.

All this is not really "clean" and will definitely break non-DM
usage of fdt_support.c. Not sure where to go from here. I would
still prefer my first patch version, even though I know that
you don't like to add this hook / callback into the DM core code.

Let me know what you think.

Thanks,
Stefan

>From ff81a6e4ced6f6b77047cae174546033d4098ee6 Mon Sep 17 00:00:00 2001
From: Stefan Roese 
Date: Thu, 3 Dec 2015 11:35:11 +0100
Subject: [PATCH] dm: Add option to configure a different, non-standard ranges
 property name

Signed-off-by: Stefan Roese 
---
 arch/arm/dts/armada-370-xp.dtsi |  1 +
 arch/arm/dts/armada-xp-gp.dts   |  3 +++
 arch/arm/mach-mvebu/spl.c   |  6 ++
 common/fdt_support.c|  8 +---
 drivers/core/root.c | 24 
 drivers/core/simple-bus.c   |  3 ++-
 include/dm/device.h |  4 
 7 files changed, 45 insertions(+), 4 deletions(-)

diff --git a/arch/arm/dts/armada-370-xp.dtsi b/arch/arm/dts/armada-370-xp.dtsi
index 0b2a78d..b74050b 100644
--- a/arch/arm/dts/armada-370-xp.dtsi
+++ b/arch/arm/dts/armada-370-xp.dtsi
@@ -141,6 +141,7 @@
 			#address-cells = <1>;
 			#size-cells = <1>;
 			ranges = <0 MBUS_ID(0xf0, 0x01) 0 0x10>;
+			ranges-spl = <0 MBUS_ID(0xf0, 0x01) 0 0x10>;
 			u-boot,dm-pre-reloc;
 
 			rtc@10300 {
diff --git a/arch/arm/dts/armada-xp-gp.dts b/arch/arm/dts/armada-xp-gp.dts
index 27799d1..e1202b4 100644
--- a/arch/arm/dts/armada-xp-gp.dts
+++ b/arch/arm/dts/armada-xp-gp.dts
@@ -99,6 +99,9 @@
 		ranges = ;
+		ranges-spl = ;
 
 		devbus-bootcs {
 			status = "okay";
diff --git a/arch/arm/mach-mvebu/spl.c b/arch/arm/mach-mvebu/spl.c
index 8edb2f3..81f4fff 100644
--- a/arch/arm/mach-mvebu/spl.c
+++ b/arch/arm/mach-mvebu/spl.c
@@ -5,6 +5,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -60,6 +61,9 @@ void board_init_f(ulong dummy)
 		hang();
 	}
 
+	/* Use special "ranges" name for SPL */
+	

Re: [U-Boot] [PATCH 7/7] dm: x86: spi: Convert ICH SPI driver to driver model PCI API

[Jagan Teki]

On 1 December 2015 at 09:41, Simon Glass  wrote:
> At present this SPI driver works by searching the PCI buses for its
> peripheral. It also uses the legacy PCI API.
>
> In addition the driver has code to determine the type of Intel PCH that is
> used (version 7 or version 9). Now that we have proper PCH drivers we can
> use those to obtain the information we need.
>
> While the device tree has a node for the SPI peripheral it is not in the
> right place. It should be on the PCI bus as a sub-peripheral of the LPC
> device.
>
> Update the device tree files to show the SPI controller within the PCH, so
> that PCI access works as expected.
>
> Signed-off-by: Simon Glass 
> ---

Reviewed-by: Jagan Teki 

thanks!
-- 
Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Please pull u-boot-sparc/master

[Francois Retief]

Hello Tom,

Please pull from u-boot-sparc master:

The following changes since commit be30dfbabbee12770221f434d2aa08627e712b97:

  iocon: Disable FIT_VERBOSE (2015-12-01 15:49:42 -0500)

are available in the git repository at:

  http://git.denx.de/u-boot-sparc.git master

for you to fetch changes up to 7a4fb11b85939b47738283c3a7ae7f461468e274:

  sparc: Remove non-generic board init files: board.c, time.c (2015-12-03 
13:15:50 +0200)


Daniel Hellstrom (6):
  sparc: Added function that checks if IRQ is on or off
  sparc: Serial baud rate register support multiple buses with different 
frequency
  sparc: leon3: Clear all unused GPTIMER registers.
  sparc: Removed USB stop from linux bootm, arch-independent bootm stop USB
  sparc: leon3: Added CPU count and frequency detection.
  sparc: leon3: Added busy wait function, made wait_ms() work when IRQ is 
disabled

Francois Retief (15):
  sparc: Move SYS_SPARC_NWINDOWS to Kconfig
  sparc: Remove version_string variable from start.S file
  sparc: leon3: Clear GD_FLAG_SERIAL_READY flag on AMBA failure
  sparc: leon3: Updated serial driver to use CONFIG_CONS_INDEX
  sparc: Fix whitespace in cpu/leon2/cpu_init.c
  sparc: Initial ground work for generic board initialization
  sparc: leon3: Move snoop detection from startup.S to arch_cpu_init()
  sparc: leon3: Move ambapp_bus_init() call to arch_cpu_init() function
  sparc: leon3: Updates for generic board initialization
  sparc: leon2: Updates for generic board initialization
  sparc: Update cpu_init.c to use generic timer infrastructure
  sparc: Update PROM initialization code for generic board
  sparc: Add CONFIG_DISPLAY_BOARDINFO variable to all LEON boards
  sparc: Use microseconds instead of ticks for timeout
  sparc: Remove non-generic board init files: board.c, time.c

 arch/Kconfig |   1 +
 arch/sparc/Kconfig   |   9 +
 arch/sparc/cpu/leon2/cpu.c   |  14 +-
 arch/sparc/cpu/leon2/cpu_init.c  |  94 +++--
 arch/sparc/cpu/leon2/interrupts.c|  14 --
 arch/sparc/cpu/leon2/prom.c  |   2 +
 arch/sparc/cpu/leon2/serial.c|   2 +-
 arch/sparc/cpu/leon2/start.S | 213 +++
 arch/sparc/cpu/leon3/ambapp.c|   2 +-
 arch/sparc/cpu/leon3/cpu.c   |  60 +-
 arch/sparc/cpu/leon3/cpu_init.c  | 175 ---
 arch/sparc/cpu/leon3/interrupts.c|  11 -
 arch/sparc/cpu/leon3/prom.c  |   2 +
 arch/sparc/cpu/leon3/serial.c|  23 +-
 arch/sparc/cpu/leon3/start.S | 303 +-
 arch/sparc/cpu/leon3/usb_uhci.c  |   7 +-
 arch/sparc/include/asm/config.h  |   8 +-
 arch/sparc/include/asm/global_data.h |   9 +-
 arch/sparc/include/asm/irq.h |   3 +
 arch/sparc/include/asm/leon3.h   |  13 ++
 arch/sparc/include/asm/u-boot.h  |  36 +---
 arch/sparc/lib/Makefile  |   4 +-
 arch/sparc/lib/board.c   | 398 ---
 arch/sparc/lib/bootm.c   |   8 -
 arch/sparc/lib/interrupts.c  |  42 +---
 arch/sparc/lib/time.c|  62 --
 common/board_f.c |  20 +-
 common/board_r.c |  10 +-
 drivers/net/greth.c  |   2 +-
 include/configs/gr_cpci_ax2000.h |   8 +-
 include/configs/gr_ep2s60.h  |   8 +-
 include/configs/gr_xc3s_1500.h   |   8 +-
 include/configs/grsim.h  |   8 +-
 include/configs/grsim_leon2.h|  12 +-
 34 files changed, 602 insertions(+), 989 deletions(-)
 delete mode 100644 arch/sparc/lib/board.c
 delete mode 100644 arch/sparc/lib/time.c
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] imx: mx7dsabresd: Add QSPI support

[Jagan Teki]

On 30 November 2015 at 15:31, Stefano Babic  wrote:
> On 30/11/2015 10:45, Peng Fan wrote:
>> Support qspi flashes for mx7dsabresd
>> 1. introduce pin mux settings
>> 2. enable qspi clock
>> 3. introduce related macro definitions
>>
>> Default QSPI is not enabled, since we need hardware rework to use QSPI,
>> see SPF-28590, page 9:
>> "
>> QSPI signals are muxed with EPDC_D[7:0]
>> When using QSPI: de-populate R388-R391, R396-R399
>> populate R392-R395, R299, R300
>> "
>>
>> After hardware rework, define CONFIG_FSL_QSPI in mx7dsabresd.h. qspi
>> flashes can be deteced and read/erase/write. Log info:
>> "
>> => sf probe
>> SF: Detected MX25L51235F with page size 256 Bytes, erase size 64 KiB, total 
>> 64 MiB
>> => sf read 0x8000 0 0x400
>> device 0 whole chip
>> SF: 67108864 bytes @ 0x0 Read: OK
>> => sf erase 0 0x400
>> SF: 67108864 bytes @ 0x0 Erased: OK
>> => sf write 0x8000 0 0x400
>> device 0 whole chip
>> SF: 67108864 bytes @ 0x0 Written: OK
>> "
>>
>> Signed-off-by: Peng Fan 
>> Cc: Stefano Babic 
>> Cc: Fabio Estevam 
>> Cc: Adrian Alonso 
>> ---
>>  board/freescale/mx7dsabresd/mx7dsabresd.c | 30 
>> ++
>>  include/configs/mx7dsabresd.h | 15 +++
>>  2 files changed, 45 insertions(+)
>>
>> diff --git a/board/freescale/mx7dsabresd/mx7dsabresd.c 
>> b/board/freescale/mx7dsabresd/mx7dsabresd.c
>> index 6c863da..f8ae973 100644
>> --- a/board/freescale/mx7dsabresd/mx7dsabresd.c
>> +++ b/board/freescale/mx7dsabresd/mx7dsabresd.c
>> @@ -44,6 +44,9 @@ DECLARE_GLOBAL_DATA_PTR;
>>  #define LCD_PAD_CTRL(PAD_CTL_HYS | PAD_CTL_PUS_PU100KOHM | \
>>   PAD_CTL_DSE_3P3V_49OHM)
>>
>> +#define QSPI_PAD_CTRL\
>> + (PAD_CTL_DSE_3P3V_49OHM | PAD_CTL_PUE | PAD_CTL_PUS_PU47KOHM)
>> +
>>  #ifdef CONFIG_SYS_I2C_MXC
>>  #define PC MUX_PAD_CTRL(I2C_PAD_CTRL)
>>  /* I2C1 for PMIC */
>> @@ -455,6 +458,29 @@ int board_phy_config(struct phy_device *phydev)
>>  }
>>  #endif
>>
>> +#ifdef CONFIG_FSL_QSPI
>> +static iomux_v3_cfg_t const quadspi_pads[] = {
>> + MX7D_PAD_EPDC_DATA00__QSPI_A_DATA0 | MUX_PAD_CTRL(QSPI_PAD_CTRL),
>> + MX7D_PAD_EPDC_DATA01__QSPI_A_DATA1 | MUX_PAD_CTRL(QSPI_PAD_CTRL),
>> + MX7D_PAD_EPDC_DATA02__QSPI_A_DATA2 | MUX_PAD_CTRL(QSPI_PAD_CTRL),
>> + MX7D_PAD_EPDC_DATA03__QSPI_A_DATA3 | MUX_PAD_CTRL(QSPI_PAD_CTRL),
>> + MX7D_PAD_EPDC_DATA05__QSPI_A_SCLK  | MUX_PAD_CTRL(QSPI_PAD_CTRL),
>> + MX7D_PAD_EPDC_DATA06__QSPI_A_SS0_B | MUX_PAD_CTRL(QSPI_PAD_CTRL),
>> +};
>> +
>> +int board_qspi_init(void)
>> +{
>> + /* Set the iomux */
>> + imx_iomux_v3_setup_multiple_pads(quadspi_pads,
>> +  ARRAY_SIZE(quadspi_pads));
>> +
>> + /* Set the clock */
>> + set_clk_qspi();
>> +
>> + return 0;
>> +}
>> +#endif
>> +
>>  int board_early_init_f(void)
>>  {
>>   setup_iomux_uart();
>> @@ -481,6 +507,10 @@ int board_init(void)
>>   setup_lcd();
>>  #endif
>>
>> +#ifdef CONFIG_FSL_QSPI
>> + board_qspi_init();
>> +#endif

Can't we do this on drivers/spi/fsl_qspi.c ?

>> +
>>   return 0;
>>  }
>>
>> diff --git a/include/configs/mx7dsabresd.h b/include/configs/mx7dsabresd.h
>> index cc98547..22e515c 100644
>> --- a/include/configs/mx7dsabresd.h
>> +++ b/include/configs/mx7dsabresd.h
>> @@ -236,4 +236,19 @@
>>  #define CONFIG_VIDEO_BMP_LOGO
>>  #endif
>>
>> +#ifdef CONFIG_FSL_QSPI
>> +#define CONFIG_CMD_SF
>> +#define CONFIG_SPI_FLASH
>> +#define CONFIG_SPI_FLASH_MACRONIX
>> +#define CONFIG_SPI_FLASH_BAR
>> +#define CONFIG_SF_DEFAULT_BUS0
>> +#define CONFIG_SF_DEFAULT_CS 0
>> +#define CONFIG_SF_DEFAULT_SPEED  4000
>> +#define CONFIG_SF_DEFAULT_MODE   SPI_MODE_0
>> +#define FSL_QSPI_FLASH_NUM   1
>> +#define FSL_QSPI_FLASH_SIZE  SZ_64M
>> +#define QSPI0_BASE_ADDR  QSPI1_IPS_BASE_ADDR
>> +#define QSPI0_AMBA_BASE  QSPI0_ARB_BASE_ADDR
>> +#endif
>> +
>>  #endif   /* __CONFIG_H */
>>
>
> Reviewed-by: Stefano Babic 
>

thanks!
-- 
Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] iocon: Disable FIT_VERBOSE

[Tom Rini]

On Thu, Dec 03, 2015 at 09:40:46AM +0100, Dirk Eibach wrote:
> Hi Tom,
> 
> 2015-12-01 21:50 GMT+01:00 Tom Rini :
> > In order to fit into image constraints again, remove this feature.
> >
> > Signed-off-by: Tom Rini 
> > ---
> >  configs/iocon_defconfig |1 +
> >  include/configs/iocon.h |2 --
> >  2 files changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/configs/iocon_defconfig b/configs/iocon_defconfig
> > index bc5e026..a6532d1 100644
> > --- a/configs/iocon_defconfig
> > +++ b/configs/iocon_defconfig
> > @@ -1,6 +1,7 @@
> >  CONFIG_PPC=y
> >  CONFIG_4xx=y
> >  CONFIG_TARGET_IOCON=y
> > +CONFIG_FIT=y
> >  CONFIG_AUTOBOOT_KEYED=y
> >  CONFIG_AUTOBOOT_STOP_STR=" "
> >  # CONFIG_CMD_ELF is not set
> > diff --git a/include/configs/iocon.h b/include/configs/iocon.h
> > index 385a644..8663c17 100644
> > --- a/include/configs/iocon.h
> > +++ b/include/configs/iocon.h
> > @@ -35,8 +35,6 @@
> >  #undef CONFIG_ZERO_BOOTDELAY_CHECK /* ignore keypress on bootdelay==0 
> > */
> >
> >  /* new uImage format support */
> > -#define CONFIG_FIT
> > -#define CONFIG_FIT_VERBOSE /* enable fit_format_{error,warning}() */
> >  #define CONFIG_FIT_DISABLE_SHA256
> >
> >  #define CONFIG_ENV_IS_IN_FLASH /* use FLASH for environment vars */
> > --
> > 1.7.9.5
> 
> NAK.
> CONFIG_FIT is an essential feature for this board.

FIT is enabled (and migrated to the config file), FIT_VERBOSE is
removed.

> It is unnerving to find our older PPC boards failing to compile
> because of size constraints after every new release. We are slowly
> running out of features to cut. Maybe we have a bloat problem here?
> I will have a look where we could squeeze out some bytes. I would hate
> to drop support for boards that are still in production :(

It's also, potentially, toolchain related.  I only saw this with I think
gcc 5.2.

> BTW is there a specific reason there was no CC to the board maintainer?

Only because I forgot, sorry!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: mvebu: Add SPI driver model support

[Jagan Teki]

On 27 November 2015 at 15:56, Stefan Roese  wrote:
> This patch enables the DM support for the SPI driver and the
> SPI NOR flash chips. Some MVEBU boards boot from SPI NOR, so
> adding the aliases and enabling CONFIG_DM_SEQ_ALIAS is needed
> here.
>
> Signed-off-by: Stefan Roese 
> Cc: Luka Perkov 
> Cc: Dirk Eibach 
> Cc: Simon Glass 
> ---

Reviewed-by: Jagan Teki 

thanks!
-- 
Jagan | openedev.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] dm: core: Distinguish between OF_TRANSLATE and SPL_OF_TRANSLATE

[Michal Simek]

Kconfig description is the same for both. Extend SPL one to indicate
that this option is for SPL only.

Signed-off-by: Michal Simek 
---

 drivers/core/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/core/Kconfig b/drivers/core/Kconfig
index 15681df6d379..b68a26ffcea3 100644
--- a/drivers/core/Kconfig
+++ b/drivers/core/Kconfig
@@ -136,7 +136,7 @@ config OF_TRANSLATE
  smaller in size than fdt_translate_address().
 
 config SPL_OF_TRANSLATE
-   bool "Translate addresses using fdt_translate_address"
+   bool "Translate addresses using fdt_translate_address in SPL"
depends on SPL_DM && SPL_OF_CONTROL
default n
help
-- 
1.9.1

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

Re: [U-Boot] [PATCH] spi: ti_qspi: Use 4-byte opcode for mmap read

[Jagan Teki]

On 23 November 2015 at 17:43, Vignesh R  wrote:
> ti-qspi driver currently uses 3-byte addressing mode(and opcodes) for
> memory-mapped read. This restricts maximum addressable flash size to
> 16MB.
> Enable the 4-byte addressing(and use 4-byte opcode) for memory-mapped
> read to allow access to addresses above 16MB.

What about sf side, since we don't have 4-byte opcode support yet?

>
> Signed-off-by: Ravi Babu 
> [vigne...@ti.com: Re-word commit description]
> Signed-off-by: Vignesh R 
>
> ---
>
> Tested on DRA74 EVM with Spansion flash and AM437X IDK EVM with Macronix
> flash.
>
>  drivers/spi/ti_qspi.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/spi/ti_qspi.c b/drivers/spi/ti_qspi.c
> index 646dd899d3ec..0a032845866d 100644
> --- a/drivers/spi/ti_qspi.c
> +++ b/drivers/spi/ti_qspi.c
> @@ -48,14 +48,14 @@
>  #define CORE_CTRL_IO0x4a002558
>
>  #define QSPI_CMD_READ   (0x3 << 0)
> -#define QSPI_CMD_READ_QUAD  (0x6b << 0)
> +#define QSPI_CMD_READ_QUAD  (0x6c << 0)
>  #define QSPI_CMD_READ_FAST  (0x0b << 0)
> -#define QSPI_SETUP0_NUM_A_BYTES (0x2 << 8)
> +#define QSPI_SETUP0_NUM_A_BYTES (0x3 << 8)
>  #define QSPI_SETUP0_NUM_D_BYTES_NO_BITS (0x0 << 10)
>  #define QSPI_SETUP0_NUM_D_BYTES_8_BITS  (0x1 << 10)
>  #define QSPI_SETUP0_READ_NORMAL (0x0 << 12)
>  #define QSPI_SETUP0_READ_QUAD   (0x3 << 12)
> -#define QSPI_CMD_WRITE  (0x2 << 16)
> +#define QSPI_CMD_WRITE  (0x12 << 16)
>  #define QSPI_NUM_DUMMY_BITS (0x0 << 24)
>
>  /* ti qspi register set */
> --
> 2.6.3
>

thanks!
-- 
Jagan | openedev.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] spi: ti_qspi: Use 4-byte opcode for mmap read

[Jagan Teki]

On Thursday 03 December 2015 05:51 PM, Vignesh R wrote:



On 12/03/2015 05:25 PM, Jagan Teki wrote:

On 23 November 2015 at 17:43, Vignesh R  wrote:

ti-qspi driver currently uses 3-byte addressing mode(and opcodes) for
memory-mapped read. This restricts maximum addressable flash size to
16MB.
Enable the 4-byte addressing(and use 4-byte opcode) for memory-mapped
read to allow access to addresses above 16MB.


What about sf side, since we don't have 4-byte opcode support yet?



Well, the sf is accessing >16MB address space using EXT_ADDR registers
via BAR support (for regular spi read/write). But, memory-mapped read
doesn't support using EXT_ADDR, hence 4-byte opcode needs to be used for
during mmap transfers to access >16MB.


So, there is no need to have 4-byte opcode support from sf side for 
memory-mapped reads - true?






Signed-off-by: Ravi Babu 
[vigne...@ti.com: Re-word commit description]
Signed-off-by: Vignesh R 

---

Tested on DRA74 EVM with Spansion flash and AM437X IDK EVM with Macronix
flash.

  drivers/spi/ti_qspi.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/spi/ti_qspi.c b/drivers/spi/ti_qspi.c
index 646dd899d3ec..0a032845866d 100644
--- a/drivers/spi/ti_qspi.c
+++ b/drivers/spi/ti_qspi.c
@@ -48,14 +48,14 @@
  #define CORE_CTRL_IO0x4a002558

  #define QSPI_CMD_READ   (0x3 << 0)
-#define QSPI_CMD_READ_QUAD  (0x6b << 0)
+#define QSPI_CMD_READ_QUAD  (0x6c << 0)
  #define QSPI_CMD_READ_FAST  (0x0b << 0)
-#define QSPI_SETUP0_NUM_A_BYTES (0x2 << 8)
+#define QSPI_SETUP0_NUM_A_BYTES (0x3 << 8)
  #define QSPI_SETUP0_NUM_D_BYTES_NO_BITS (0x0 << 10)
  #define QSPI_SETUP0_NUM_D_BYTES_8_BITS  (0x1 << 10)
  #define QSPI_SETUP0_READ_NORMAL (0x0 << 12)
  #define QSPI_SETUP0_READ_QUAD   (0x3 << 12)
-#define QSPI_CMD_WRITE  (0x2 << 16)
+#define QSPI_CMD_WRITE  (0x12 << 16)
  #define QSPI_NUM_DUMMY_BITS (0x0 << 24)

  /* ti qspi register set */
--
2.6.3


thanks!
--
Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 05/26] dm: pci: Add a driver-model version of pci_find_device()

[Bin Meng]

On Mon, Nov 30, 2015 at 4:17 AM, Simon Glass  wrote:
> Add a function which scans the driver model device information rather
> than scanning the PCI bus again.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v2: None
>

Tested-by: Bin Meng 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] x86: Clean up SPI flash drivers in defconfig

[Jagan Teki]

Hi Bin,

On 3 December 2015 at 10:14, Bin Meng  wrote:
> Hi Simon,
>
> On Thu, Dec 3, 2015 at 5:05 AM, Simon Glass  wrote:
>> +Jagan
>>
>> Hi Bin,
>>
>> On 1 December 2015 at 18:41, Bin Meng  wrote:
>>>
>>> Hi Simon,
>>>
>>> On Wed, Dec 2, 2015 at 12:32 AM, Simon Glass  wrote:
>>> > Hi Bin,
>>> >
>>> > On 28 November 2015 at 05:45, Bin Meng  wrote:
>>> >> Every board has one dedicated type of SPI flash, hence it is
>>> >> unnecessary to include multiple SPI flash drivers.
>>> >>
>>> >> For QEMU and coreboot (default build of coreboot is also QEMU),
>>> >> SPI flash is not supported. Remove those SPI flash drivers.
>>> >>
>>> >> Signed-off-by: Bin Meng 
>>> >> ---
>>> >>
>>> >>  configs/bayleybay_defconfig | 2 --
>>> >>  configs/chromebook_link_defconfig   | 2 --
>>> >>  configs/chromebox_panther_defconfig | 2 --
>>> >>  configs/coreboot-x86_defconfig  | 4 
>>> >>  configs/crownbay_defconfig  | 3 ---
>>> >>  configs/galileo_defconfig   | 2 --
>>> >>  configs/minnowmax_defconfig | 3 ---
>>> >>  configs/qemu-x86_defconfig  | 4 
>>> >>  8 files changed, 22 deletions(-)
>>> >
>>> > What is the benefit of this? I see it removes a few lines in a data
>>> > table. Does it matter?
>>>
>>> Maybe we should ask the other way around, why do we create so many
>>> flash driver Kconfig option? I believe the intention was footprint.
>>> Besides the footprint issue, having just one flash driver in each
>>> board makes it very clear instead of causing confusion. Looks other
>>> board defconfig files only select one.

Are you talking about flash vendor config or CONFIG_SPI_FLASH?

>>
>> They are a hangover from when we had a separate driver for each one.
>> Jagan put a lot of effort into removing all the semi-duplicated code.
>>
>> Maybe we should prune down these options?
>>
>
> But if we already spent a lot of effort into removing all the
> semi-duplicated code, we should not have converted those flash driver
> to Kconfig options before.
>
> See commit d5af92315bb48740f16bf8817f38e227d3076905 "sf: kconfig: add
> kconfig options for spi flashes"
>
> I suspect we may remove most of these SPI flash macros, but at least
> SST flash macro should be kept since right now it is mixed in the
> generic driver with a special byte program and word program which is
> incompatible with other vendors' flashes.

But there is some flash vendor specific code like quad enable bit,
locking ops and finally about spi_flash_params table.

>
>>>
>>> >
>>> > For all of these platforms we can use the dediprog em100 which I
>>> > typically set to use winbond as the manufacturer, regardless of which
>>> > chip is actually on the board.
>>> >
>>>
>>> I think that's because emulator can emulate flash from various vendors.
>>
>> Yes, and also for convenience.
>>
>>>
>>> > For U-Boot on coreboot, why is SPI flash not supported? It certainly
>>> > works with link.
>>>
>>> Yes, booting from coreboot does support SPI flash. However since we
>>> decided to use QEMU as the default build target for coreboot, and QEMU
>>> does not support SPI flash yet, these config options are removed. One
>>> can certainly adjust these Kconfig options via 'make menuconfig', eg:
>>> adding SD/MMC support which is not in coreboot's defconfig either.
>>
>> Well this breaks booting on link, since the SPI flash stops working.
>> I'm really not keen on having to specially select the SPI flash when
>> you want to use link.
>>
>
> Do you mean booting U-Boot on link from coreboot? Without SPI flash it
> should still boot. It looks to me your preference is to include all
> the available drivers into coreboot's defconfig, yes? If so, we may
> add some other drivers Kconfig in coreboot-x86_defconfig too, like
> SD/MMC drivers, all the available ethernet drivers even they only
> exist on some boards.

thanks!
-- 
Jagan | openedev.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sf: Remove #ifdef #endif in Makefile

[Bin Meng]

Hi Jagan,

On Thu, Dec 3, 2015 at 6:17 PM, Jagan Teki  wrote:
> Hi Bin,
>
> On 1 December 2015 at 15:37, Bin Meng  wrote:
>> The #ifdef #endif in drivers/mtd/spi/Makefile actually does nothing
>> but causes confusion. Remove it.
>>
>> Signed-off-by: Bin Meng 
>> ---
>>
>>  drivers/mtd/spi/Makefile | 2 --
>>  1 file changed, 2 deletions(-)
>>
>> diff --git a/drivers/mtd/spi/Makefile b/drivers/mtd/spi/Makefile
>> index cf4e7e1..6ca1b72 100644
>> --- a/drivers/mtd/spi/Makefile
>> +++ b/drivers/mtd/spi/Makefile
>> @@ -12,9 +12,7 @@ obj-$(CONFIG_SPL_SPI_LOAD)+= spi_spl_load.o
>>  obj-$(CONFIG_SPL_SPI_BOOT) += fsl_espi_spl.o
>>  endif
>>
>> -#ifndef CONFIG_DM_SPI
>>  obj-$(CONFIG_SPI_FLASH) += sf_probe.o
>> -#endif
>>  obj-$(CONFIG_CMD_SF) += sf.o
>>  obj-$(CONFIG_SPI_FLASH) += sf_ops.o sf_params.o
>>  obj-$(CONFIG_SPI_FLASH_DATAFLASH) += sf_dataflash.o
>
> Sent similar change on this [1] patch
>
> [1] https://patchwork.ozlabs.org/patch/549041/
>

Ah, yes! Thanks.

> thanks!
> --

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

Re: [U-Boot] [PATCH v7 06/34] sf: Fix Makefile

[Bin Meng]

On Thu, Nov 26, 2015 at 8:03 PM, Jagan Teki  wrote:
> This patch removes unneeded ifdef and fixed accordingly.
>
> Signed-off-by: Jagan Teki 
> ---
>  drivers/mtd/spi/Makefile | 6 +-
>  1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/drivers/mtd/spi/Makefile b/drivers/mtd/spi/Makefile
> index cf4e7e1..a24f761 100644
> --- a/drivers/mtd/spi/Makefile
> +++ b/drivers/mtd/spi/Makefile
> @@ -12,11 +12,7 @@ obj-$(CONFIG_SPL_SPI_LOAD)   += spi_spl_load.o
>  obj-$(CONFIG_SPL_SPI_BOOT) += fsl_espi_spl.o
>  endif
>
> -#ifndef CONFIG_DM_SPI
> -obj-$(CONFIG_SPI_FLASH) += sf_probe.o
> -#endif
> -obj-$(CONFIG_CMD_SF) += sf.o
> -obj-$(CONFIG_SPI_FLASH) += sf_ops.o sf_params.o
> +obj-$(CONFIG_SPI_FLASH) += sf_probe.o sf_ops.o sf_params.o sf.o
>  obj-$(CONFIG_SPI_FLASH_DATAFLASH) += sf_dataflash.o
>  obj-$(CONFIG_SPI_FLASH_MTD) += sf_mtd.o
>  obj-$(CONFIG_SPI_FLASH_SANDBOX) += sandbox.o
> --

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

Re: [U-Boot] [PATCH] iocon: Disable FIT_VERBOSE

[Dirk Eibach]

Hi Tom,

2015-12-01 21:50 GMT+01:00 Tom Rini :
> In order to fit into image constraints again, remove this feature.
>
> Signed-off-by: Tom Rini 
> ---
>  configs/iocon_defconfig |1 +
>  include/configs/iocon.h |2 --
>  2 files changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/configs/iocon_defconfig b/configs/iocon_defconfig
> index bc5e026..a6532d1 100644
> --- a/configs/iocon_defconfig
> +++ b/configs/iocon_defconfig
> @@ -1,6 +1,7 @@
>  CONFIG_PPC=y
>  CONFIG_4xx=y
>  CONFIG_TARGET_IOCON=y
> +CONFIG_FIT=y
>  CONFIG_AUTOBOOT_KEYED=y
>  CONFIG_AUTOBOOT_STOP_STR=" "
>  # CONFIG_CMD_ELF is not set
> diff --git a/include/configs/iocon.h b/include/configs/iocon.h
> index 385a644..8663c17 100644
> --- a/include/configs/iocon.h
> +++ b/include/configs/iocon.h
> @@ -35,8 +35,6 @@
>  #undef CONFIG_ZERO_BOOTDELAY_CHECK /* ignore keypress on bootdelay==0 */
>
>  /* new uImage format support */
> -#define CONFIG_FIT
> -#define CONFIG_FIT_VERBOSE /* enable fit_format_{error,warning}() */
>  #define CONFIG_FIT_DISABLE_SHA256
>
>  #define CONFIG_ENV_IS_IN_FLASH /* use FLASH for environment vars */
> --
> 1.7.9.5

NAK.
CONFIG_FIT is an essential feature for this board.
It is unnerving to find our older PPC boards failing to compile
because of size constraints after every new release. We are slowly
running out of features to cut. Maybe we have a bloat problem here?
I will have a look where we could squeeze out some bytes. I would hate
to drop support for boards that are still in production :(

BTW is there a specific reason there was no CC to the board maintainer?

Cheers
Dirk
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 1/3] spl: mmc: Fix compiler warning with CONFIG_DM_MMC

[Nikita Kiryanov]

On Wed, Dec 02, 2015 at 10:59:11AM -0700, Simon Glass wrote:
> Since commit 4188ba3 we get the following warning on rockchip boards:
> 
> common/spl/spl_mmc.c:31:24: warning: ‘mmc’ may be used uninitialized in this 
> function [-Wmaybe-uninitialized]
>   count = mmc->block_dev.block_read(0, sector, 1, header);
> ^
> common/spl/spl_mmc.c:251:14: note: ‘mmc’ was declared here
>   struct mmc *mmc;
> 
> Correct this by move the variable init earlier.

Acked-by: Nikita Kiryanov 

> 
> Signed-off-by: Simon Glass 
> Tested-by: Michal Simek 
> ---
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/1] fsl_qspi: Pet the watchdog while reading/writing

[Huan Wang]

Hi, York,

> On Wednesday 25 November 2015 02:20:53, Huan Wang wrote:
> > [Alison Wang] I didn't meet any issue when using sf commands to write
> > and read the serial flash.
> >
> > Hi, Alexander,
> >
> > Could you show me the detail commands and process when you meet
> such
> > issue? Then I can try to reproduce on my board.
> 
> Yep, here is the output:
> > U-Boot 2015.01-00671-g78773b9 (Nov 25 2015 - 10:28:50)
> >
> > CPU:   Freescale LayerScape LS1021E, Version: 2.0, (0x87081120)
> >
> > Clock Configuration:
> >CPU0(ARMV7):960  MHz,
> >Bus:288  MHz, DDR:800  MHz (1600 MT/s data rate), Reset
> > Configuration Word (RCW):
> >: 0608000a   
> >0010: 7000 08407922 4a00 21046000
> >0020:    0021ef00
> >0030: 20024800 0888f340   QSPI
> >Watchdog enabled
> > I2C:   ready
> > DRAM:  Initializing DDR
> > Detected UDIMM Fixed DDR on board
> > 512 MiB (DDR3, 16-bit, CL=11, ECC off) Using SERDES1 Protocol: 112
> > (0x70)
> > MMC:   FSL_SDHC: 0
> > SF: Detected S25FL512S_256K with page size 512 Bytes, erase size 256
> KiB,
> > In:serial
> > Out:   serial
> > Err:   serial
> > SF: Detected S25FL512S_256K with page size 512 Bytes, erase size 256
> > KiB, total 64 MiB SF: 262144 bytes @ 0x18 Read: OK Firmware
> > 'Microcode version 0.0.1 for LS1021a r1.0' for 1021 V1.0
> > QE: uploading microcode 'Microcode for LS1021a r1.0' version 0.0.1
> > SCSI:  Net:   eTSEC2 is in sgmii mode.
> > eTSEC1 [PRIME], eTSEC2
> > Hit any key to stop autoboot:  0
> > => sf read 0x8104 0x20 0x40
> >
> >
> > U-Boot 2015.01-00671-g78773b9 (Nov 25 2015 - 10:28:50)
> >
> > CPU:   Freescale LayerScape LS1021E, Version: 2.0, (0x87081120)
> >
> > Clock Configuration:
> >CPU0(ARMV7):960  MHz,
> >Bus:288  MHz, DDR:800  MHz (1600 MT/s data rate), Reset
> > Configuration Word (RCW):
> >: 0608000a   
> >0010: 7000 08407922 4a00 21046000
> >0020:    0021ef00
> >0030: 20024800 0888f340   QSPI
> >Watchdog enabled
> > I2C:   ready
> > DRAM:  Initializing DDR
> > Detected UDIMM Fixed DDR on board
> > [...]
> and so on...
> 
> The actual command which results in a watchdog reset is 'sf read
> 0x8104 0x20 0x40'. Please note that this uses an external
> watchdog which is enabled by default and resets after ~1.5s. The command
> itself takes about 2s (taken from my watch).
> 
[Alison Wang] I could not reproduce the issue. Maybe I don't have the
external watchdog which will reset after ~1.5s as Alexander mentioned.

U-Boot 2015.10-00273-g7ee52af (Dec 03 2015 - 17:32:24 +0800)

CPU:   Freescale LayerScape LS1021E, Version: 2.0, (0x87081120)
Clock Configuration:
   CPU0(ARMV7):1000 MHz,
   Bus:300  MHz, DDR:800  MHz (1600 MT/s data rate),
Reset Configuration Word (RCW):
   : 0608000a   
   0010: 3000 7900 40025a00 21046000
   0020:    2000
   0030: 20024800 881b7540  
Model: LS1021A TWR Board
Board: LS1021ATWR
I2C:   ready
DRAM:  1 GiB
Using SERDES1 Protocol: 48 (0x30)
MMC:   FSL_SDHC: 0
SF: Detected N25Q128 with page size 256 Bytes, erase size 64 KiB, total 16 MiB
EEPROM: NXID v1
PCIe1: Root Complex no link, regs @ 0x340
PCIe2: disabled
In:serial
Out:   serial
Err:   serial
SEC: RNG instantiated
SATA link 0 timeout.
AHCI 0001.0300 1 slots 1 ports ? Gbps 0x1 impl SATA mode
flags: 64bit ncq pm clo only pmp fbss pio slum part ccc
Found 0 device(s).
SCSI:  Net:   eTSEC1 is in sgmii mode.
eTSEC2 is in sgmii mode.
eTSEC1, eTSEC2, eTSEC3 [PRIME]
=> => sf probe
SF: Detected N25Q128 with page size 256 Bytes, erase size 64 KiB, total 16 MiB
=> sf read 0x8104 0x20 0x40
device 0 offset 0x20, size 0x40
SF: 4194304 bytes @ 0x20 Read: OK
=>


Best Regards,
Alison Wang
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sf: Remove #ifdef #endif in Makefile

[Jagan Teki]

Hi Bin,

On 1 December 2015 at 15:37, Bin Meng  wrote:
> The #ifdef #endif in drivers/mtd/spi/Makefile actually does nothing
> but causes confusion. Remove it.
>
> Signed-off-by: Bin Meng 
> ---
>
>  drivers/mtd/spi/Makefile | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/drivers/mtd/spi/Makefile b/drivers/mtd/spi/Makefile
> index cf4e7e1..6ca1b72 100644
> --- a/drivers/mtd/spi/Makefile
> +++ b/drivers/mtd/spi/Makefile
> @@ -12,9 +12,7 @@ obj-$(CONFIG_SPL_SPI_LOAD)+= spi_spl_load.o
>  obj-$(CONFIG_SPL_SPI_BOOT) += fsl_espi_spl.o
>  endif
>
> -#ifndef CONFIG_DM_SPI
>  obj-$(CONFIG_SPI_FLASH) += sf_probe.o
> -#endif
>  obj-$(CONFIG_CMD_SF) += sf.o
>  obj-$(CONFIG_SPI_FLASH) += sf_ops.o sf_params.o
>  obj-$(CONFIG_SPI_FLASH_DATAFLASH) += sf_dataflash.o

Sent similar change on this [1] patch

[1] https://patchwork.ozlabs.org/patch/549041/

thanks!
-- 
Jagan .
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] mmc: implement mmc power on write protect function

[Lin Huang]

set the mmc specific addresss and range as power on
write protection, and can't earse and write this range
if you enable it after mmc power on.

Signed-off-by: Lin Huang 
---
 drivers/mmc/mmc.c | 89 +++
 include/mmc.h | 10 ++-
 2 files changed, 98 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 2a58702..60ff5be 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -1819,6 +1819,95 @@ int mmc_initialize(bd_t *bis)
return 0;
 }
 
+int mmc_get_wp_status(struct mmc *mmc, lbaint_t addr, char *status)
+{
+   struct mmc_cmd cmd;
+   struct mmc_data data;
+   int err;
+
+   cmd.cmdidx = MMC_CMD_WRITE_PROT_TYPE;
+   cmd.resp_type = MMC_RSP_R1;
+   cmd.cmdarg = addr;
+
+   data.dest = status;
+   data.blocksize = 8;
+   data.blocks = 1;
+   data.flags = MMC_DATA_READ;
+
+   err = mmc_send_cmd(mmc, , );
+   if (err)
+   return err;
+   return err;
+}
+
+int mmc_usr_power_on_wp(struct mmc *mmc, lbaint_t addr, unsigned int size)
+{
+   int err;
+   unsigned int wp_group_size, wp_grp_num, i;
+   struct mmc_cmd cmd;
+   unsigned int timeout = 1000;
+
+   ALLOC_CACHE_ALIGN_BUFFER(u8, ext_csd, MMC_MAX_BLOCK_LEN);
+
+   size = size / MMC_MAX_BLOCK_LEN;
+
+   err = mmc_send_ext_csd(mmc, ext_csd);
+   if (err)
+   return err;
+
+   if ((ext_csd[EXT_CSD_USER_WP] & EXT_CSD_USER_PERM_WP_EN) ||
+   (ext_csd[EXT_CSD_USER_WP] & EXT_CSD_USER_PWR_WP_DIS)) {
+   printf("Power on protection is disabled\n");
+   return -1;
+   }
+
+   if (ext_csd[EXT_CSD_ERASE_GROUP_DEF])
+   wp_group_size = ext_csd[EXT_CSD_HC_WP_GRP_SIZE] *
+   ext_csd[EXT_CSD_HC_ERASE_GRP_SIZE] * 1024;
+   else {
+   int erase_gsz, erase_gmul, wp_grp_size;
+
+   erase_gsz = (mmc->csd[2] & 0x7c00) >> 10;
+   erase_gmul = (mmc->csd[2] & 0x03e0) >> 5;
+   wp_grp_size = (mmc->csd[2] & 0x001f);
+   wp_group_size = (erase_gsz + 1) * (erase_gmul + 1) *
+   (wp_grp_size + 1);
+   }
+
+   if (size < wp_group_size) {
+   printf("wrong size, fail to set power on wp\n");
+   return -1;
+   }
+
+   err = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL,
+EXT_CSD_USER_WP, EXT_CSD_USER_PWR_WP_EN);
+   if (err)
+   return err;
+
+   wp_grp_num = DIV_ROUND_UP(size, wp_group_size);
+   cmd.cmdidx = MMC_CMD_WRITE_PROT;
+   cmd.resp_type = MMC_RSP_R1b;
+
+   for (i = 0; i < wp_grp_num; i++) {
+   cmd.cmdarg = addr + i * wp_group_size;
+   err = mmc_send_cmd(mmc, , NULL);
+   if (err)
+   return err;
+
+   /* CMD28/CMD29 ON failure returns address out of range error */
+   if ((cmd.response[0] >> 31) & 0x01) {
+   printf("address for CMD28/29 out of range\n");
+   return -1;
+   }
+
+   err = mmc_send_status(mmc, timeout);
+   if (err)
+   return err;
+   }
+
+   return 0;
+}
+
 #ifdef CONFIG_SUPPORT_EMMC_BOOT
 /*
  * This function changes the size of boot partition and the size of rpmb
diff --git a/include/mmc.h b/include/mmc.h
index cda9a19..448d5a8 100644
--- a/include/mmc.h
+++ b/include/mmc.h
@@ -89,6 +89,8 @@
 #define MMC_CMD_SET_BLOCK_COUNT 23
 #define MMC_CMD_WRITE_SINGLE_BLOCK 24
 #define MMC_CMD_WRITE_MULTIPLE_BLOCK   25
+#define MMC_CMD_WRITE_PROT 28
+#define MMC_CMD_WRITE_PROT_TYPE31
 #define MMC_CMD_ERASE_GROUP_START  35
 #define MMC_CMD_ERASE_GROUP_END36
 #define MMC_CMD_ERASE  38
@@ -175,6 +177,7 @@
 #define EXT_CSD_WR_REL_PARAM   166 /* R */
 #define EXT_CSD_WR_REL_SET 167 /* R/W */
 #define EXT_CSD_RPMB_MULT  168 /* RO */
+#define EXT_CSD_USER_WP171
 #define EXT_CSD_ERASE_GROUP_DEF175 /* R/W */
 #define EXT_CSD_BOOT_BUS_WIDTH 177
 #define EXT_CSD_PART_CONF  179 /* R/W */
@@ -231,6 +234,10 @@
 #define EXT_CSD_WR_DATA_REL_USR(1 << 0)/* user data 
area WR_REL */
 #define EXT_CSD_WR_DATA_REL_GP(x)  (1 << ((x)+1))  /* GP part (x+1) WR_REL 
*/
 
+#define EXT_CSD_USER_PWR_WP_DIS(1 << 3) /* disable power-on 
write protect*/
+#define EXT_CSD_USER_PERM_WP_EN(1 << 2) /* enable permanent 
write protect */
+#define EXT_CSD_USER_PWR_WP_EN (1 << 0) /* enable power-on write 
protect */
+
 #define R1_ILLEGAL_COMMAND (1 << 22)
 #define R1_APP_CMD (1 << 5)
 
@@ -477,7 +484,8 @@ int cpu_mmc_init(bd_t *bis);
 int 

Re: [U-Boot] [PATCH v2 02/26] dm: pci: Add a dm_ prefix to pci_get_bdf()

[Bin Meng]

On Mon, Nov 30, 2015 at 4:17 AM, Simon Glass  wrote:
> Most driver model PCI functions have a dm_ prefix. At some point, when the
> old code is converted to driver model and the old functions are removed, we
> will drop that prefix.
>
> For consistency, we should use the dm_ prefix for all driver model
> functions. Update pci_get_bdf() accordingly.
>
> Signed-off-by: Simon Glass 
> ---
>

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

Re: [U-Boot] [PATCH v2 03/26] dm: pci: Add a dm_ prefix to pci_bus_find_bdf()

[Bin Meng]

On Mon, Nov 30, 2015 at 4:17 AM, Simon Glass  wrote:
> Most driver model PCI functions have a dm_ prefix. At some point, when the
> old code is converted to driver model and the old functions are removed, we
> will drop that prefix.
>
> For consistency, we should use the dm_ prefix for all driver model
> functions. Update pci_bus_find_bdf() accordingly.
>
> Signed-off-by: Simon Glass 
> ---
>

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

Re: [U-Boot] [PATCH v2 06/26] dm: pci: scsi: Use driver-model PCI API

[Bin Meng]

On Mon, Nov 30, 2015 at 4:17 AM, Simon Glass  wrote:
> Adjust the SCSI command to use driver model for its PCI interface.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2:
> - Use dm_pci_get_bdf()
>

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

Re: [U-Boot] [PATCH v2 07/26] dm: pci: Add a driver-model version of pci_find_class()

[Bin Meng]

On Mon, Nov 30, 2015 at 4:17 AM, Simon Glass  wrote:
> Add a function which scans the driver model device information rather
> than scanning the PCI bus again.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v2: None
>

Tested-by: Bin Meng 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] dm: Introduce SPI-NOR framework

[Jagan Teki]

Hi Simon,

I re-phrase all the question from previous thread and continue in this 
for more discussion on spi-nor development.


> Is it intended that SPI flash should be a driver for the MTD uclass?
> Others would be NAND and CFI. From what I can tell MTD has the same
> operations as SPI flash (erase, read, write) and adds a lot more.
>
> Or is SPI flash really a separate uclass from MTD, with SPI flash
> being at a higher level?

Based on my "sf: MTD support" series SPI flash is a separate uclass from 
MTD and it uses mtd_info operations.


>> cmd_sf
>> ===
>> MTD
>> ===
>> spi-nor or spi-flash
>> ===
>> "spi-nor to spi drivers" and spi-nor controller driver
>> ===
> Your diagram above suggests that MTD calls into SPI NOR or SPI flash,
> but when I look at (for exampe) spi_flash_erase(), it is calling
> mtd_erase(), suggesting that it is above MTD in the software stack,
> the opposite of your diagram above.
>

Will explain this clearly in below description.

> Conceptually this seems problematic.
>
> SPI flash is a uclass and supports driver model. It has operations,
> etc. Your patches remove the operations in favour of calling MTD. But
> MTD does not support driver model. This is getting really messy.
>

Will explain this clearly in below description.


Introducing SPI-NOR:


Some of the spi drivers or spi controllers at drivers/spi/*
not a real spi controllers, unlike normal spi controllers
those operates varienty of spi devices among spi-nor flash is
one of them but instead these were specially designed for
to operate spi-nor flash devices - these are spi-nor controllers.
example: drivers/spi/fsl_qspi.c

The problem with these were sitting at drivers/spi is entire
spi layer becomes spi-nor flash oriented which is absolutely
wrong indication where spi layer gets effected more with
flash operations - So this SPI-NOR will resolve this issue
by separating all spi-nor flash operations from spi layer
and by creating a generic layer called SPI-NOR core where it
deals with all SPI-NOR flash activities. The basic idea is
taken from Linux spi-nor framework.

SPI-NOR Block diagram:
*

=
cmd_sf.c
===
spi_flash.h
===
mtdcore.c
===
spi-nor.c

m25p80.c fsl_qspi.c
==   ===
spi-uclass   spi-nor hw
==   ===
spi_drivers
===
spi-bus hw
==

Note:
- spi-nor.c is a common core for m25p80.c which is a spi-nor to spi 
driver interface layer and for fsl_qspi.c which is a typical spi-nor

controller driver.
- Challenging task is about probe.

SPI-NOR Development plan:
*

a) Adding MTD core support:
   From command point of view the spi-flash is like a mtd device 
having erase/write/read ops with offset, addr and size, but from lower 
layers the spi-flash becomes either spi-nor or spi-nand so they have 
their own specific features like struct spi_nor {}.


   This is the reason for calling MTD from command layer and the lower 
layer as SPI_NOR uclass.


b) Drop spi_flash uclass:
   Since spi_flash is a generic term for serial flash devices among
   these spi-nor and spi-nand are the real device categories so add
   driver model to these categories.

I sent the series [1] for above a) and b)

c) Add spi-nor support (mean Adding SPI-NOR dm drivers) the next step.

Detailed SPI-NOR with examples:
**

include/spi_flash.h
---

struct spi_flash {
   struct spi_nor  *nor;
};

include/linux/mtd/spi-nor.h
---

struct spi_nor {
   struct udevice   *dev;
   struct mtd_info  *info;

   // spi-nor hooks
   int (*read_reg)(struct udevice *dev, u8 cmd, u8 *val, int len);
   int (*write_reg)(struct udevice *dev, u8 cmd, u8 *data, int len);

   int (*read_mmap)(struct udevice *dev, void *data, void *offset,
size_t len);
   int (*read)(struct udevice *dev, const u8 *opcode, size_t cmd_len,
void *data, size_t data_len);
   int (*write)(struct udevice *dev, const u8 *cmd, size_t cmd_len,
const void *data, size_t data_len);
};

drivers/mtd/spi-nor/spi-nor.c
-

static int spi_nor_erase(struct mtd_info *mtd, struct erase_info *instr)
{
// call to spi-nor erase nor->erase()
}

static int spi_nor_read(struct mtd_info *mtd, loff_t from, size_t len,
size_t *retlen, u_char *buf)
{
// call to spi-nor erase nor->read()
}

static int spi_nor_write(struct mtd_info *mtd, loff_t to, size_t len,
size_t *retlen, const u_char *buf)
{
// call to spi-nor erase nor->erase()
}

int spi_nor_scan(struct spi_nor *nor)
{
struct mtd_info *mtd = nor->mtd;

// read_jedec

// assign mtd hooks

// other spi-nor stuff

}

drivers/mtd/spi-nor/m25p80.c


struct m25p80 {
struct spi_slave *spi;
   

Re: [U-Boot] [linux-sunxi] [PATCH 1/2] sunxi: twi: enable clocks on sun7i

[Julian Calaby]

Hi Oliver,

On Fri, Dec 4, 2015 at 3:49 AM, Olliver Schinagl  wrote:
> From: Olliver Schinagl 
>
> Commit 6c739c5d added code to enable i2c bus 4 and 5 on the sun7i SoC
> but forgot to enable the clocks for these 2 i2c busses.
>
> This patch enables the clocks for i2c bus 4 and 5 on sun7i.
>
> Signed-off-by: Olliver Schinagl 
> ---
>  arch/arm/cpu/armv7/sunxi/clock_sun4i.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/cpu/armv7/sunxi/clock_sun4i.c 
> b/arch/arm/cpu/armv7/sunxi/clock_sun4i.c
> index 7c8eff9..ed910b1 100644
> --- a/arch/arm/cpu/armv7/sunxi/clock_sun4i.c
> +++ b/arch/arm/cpu/armv7/sunxi/clock_sun4i.c
> @@ -67,7 +67,11 @@ int clock_twi_onoff(int port, int state)
> struct sunxi_ccm_reg *const ccm =
> (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
>
> +#ifdef CONFIG_MACH_SUN7I
> +   if (port > 4)
> +#else
> if (port > 2)
> +#endif

Should the number here be a #define somewhere, or even a parameter for
each version of this clock?

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] net: fm: disables unused FM1-DTSEC1 MAC node in DTS

[shh.xie]

From: Shaohui Xie 

We don't disable unused FM1-DTSEC1 MAC node in FMAN v2 since its used
for MDIO, in FMAN v3, MDIO uses dedicated controller, so we can disable
the unused FM1-DTSEC1 MAC node to avoid it's being probed in kernel.

Signed-off-by: Shaohui Xie 
---
 drivers/net/fm/init.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/fm/init.c b/drivers/net/fm/init.c
index 3a1de59..7e312f1 100644
--- a/drivers/net/fm/init.c
+++ b/drivers/net/fm/init.c
@@ -242,8 +242,10 @@ int ft_fixup_port(void *blob, struct fm_eth_info *info, 
char *prop)
int off;
uint32_t ph;
phys_addr_t paddr = CONFIG_SYS_CCSRBAR_PHYS + info->compat_offset;
+#ifndef CONFIG_SYS_FMAN_V3
u64 dtsec1_addr = (u64)CONFIG_SYS_CCSRBAR_PHYS +
CONFIG_SYS_FSL_FM1_DTSEC1_OFFSET;
+#endif
 
off = fdt_node_offset_by_compat_reg(blob, prop, paddr);
if (off == -FDT_ERR_NOTFOUND)
@@ -295,8 +297,10 @@ int ft_fixup_port(void *blob, struct fm_eth_info *info, 
char *prop)
/* board code might have caused offset to change */
off = fdt_node_offset_by_compat_reg(blob, prop, paddr);
 
+#ifndef CONFIG_SYS_FMAN_V3
/* Don't disable FM1-DTSEC1 MAC as its used for MDIO */
if (paddr != dtsec1_addr)
+#endif
fdt_status_disabled(blob, off); /* disable the MAC node */
 
/* disable the fsl,dpa-ethernet node that points to the MAC */
-- 
2.1.0.27.g96db324

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

Re: [U-Boot] [PATCH v3] dm: core: Enable optional use of fdt_translate_address()

[Bin Meng]

Hi,

On Fri, Dec 4, 2015 at 1:31 PM, Bin Meng  wrote:
> Hi Stefan,
>
> On Thu, Dec 3, 2015 at 10:12 PM, Stefan Roese  wrote:
>> Hi Bin,
>>
>>
>> On 03.12.2015 14:34, Bin Meng wrote:
>>>
>>> Hi Stefan, Simon,
>>>
>>> On Mon, Oct 19, 2015 at 7:16 AM, Simon Glass  wrote:

 On 29 September 2015 at 23:00, Stefan Roese  wrote:
>
> The current "simple" address translation simple_bus_translate() is not
> working on some platforms (e.g. MVEBU). As here more complex "ranges"
> properties are used in many nodes (multiple tuples etc). This patch
> enables the optional use of the common fdt_translate_address() function
> which handles this translation correctly.
>
> Signed-off-by: Stefan Roese 
> Cc: Simon Glass 
> Cc: Bin Meng 
> Cc: Marek Vasut 
> Cc: Masahiro Yamada 
> Cc: Stephen Warren 
> Cc: Lukasz Majewski 
> ---
> v3:
> - Rebased on current U-Boot version
> - Added Stephen and Lukasz to Cc
>
> v2:
> - Rework code a bit as suggested by Simon. Also added some comments
>to make the use of the code paths more clear.
>
>   drivers/core/Kconfig  | 30 ++
>   drivers/core/device.c | 20 
>   2 files changed, 50 insertions(+)


 Applied to u-boot-dm, thanks!
>>>
>>>
>>> When testing Simon's patch [1], I found PCI UART on Intel Crown Bay no
>>> longer works. git bisect leads to this commit. Somehow I missed this
>>> patch before although I see the commit message get me cc'ed but the
>>> email did not bring to my attention.
>>>
>>> I see this patch introduced OF_TRANSLATE and by default set it to y.
>>> This makes the code logic in dev_get_addr() go through
>>> fdt_translate_address(), which breaks the things.
>>
>>
>> I'm a bit surprised that using the common fdt_translate_address()
>> function instead of the DM internal simple_bus_translate() causes
>> problems on your platform. Are you sure that the ranges are
>> described correctly in your dts? Is the dts a copy from the Linux
>> original one? Ah, probably not, since we're talking about x86
>> which has no DT support in Linux, right?
>>
>
> Is fdt_translate_address() able to handle PCI bus ranges property? PCI
> has special ranges.
>
> The arch/x86/dts/crownbay.dts has something like below:
>
>  90 pci {
>  91 #address-cells = <3>;
>  92 #size-cells = <2>;
>  93 compatible = "pci-x86";
>  94 u-boot,dm-pre-reloc;
>  95 ranges = <0x0200 0x0 0x4000 0x4000 0 
> 0x8000
>  96   0x4200 0x0 0xc000 0xc000 0 
> 0x2000
>  97   0x0100 0x0 0x2000 0x2000 0 0xe000>;
>  98
>  99 pcie@17,0 {
> 100 #address-cells = <3>;
> 101 #size-cells = <2>;
> 102 compatible = "pci-bridge";
> 103 u-boot,dm-pre-reloc;
> 104 reg = <0xb800 0x0 0x0 0x0 0x0>;
>
>>> Should we set
>>> OF_TRANSLATE to n by default? If set to y, this requires dts to have
>>> complete ranges property everywhere.
>>
>>
>> My understanding here is that x86 is a special case. As it doesn't
>> use the full-blown dts sources from Linux. But most likely some
>> "simple" ones, written exactly for U-Boot / DM.
>>
>> I would still prefer to have this OF_TRANSLATE set to y as default.
>> As its needed for at least some platforms. But if we decide to
>> set it to n, I can live with it as well.
>>

Looks like the issue is:

dev_get_addr() return value is of type fdt_addr_t, and if no valid
address found returns FDT_ADDR_T_NONE. But FDT_ADDR_T_NONE is defined
as follows:

#ifdef CONFIG_PHYS_64BIT
#define FDT_ADDR_T_NONE (-1ULL)
#define fdt_addr_to_cpu(reg) be64_to_cpu(reg)
#define fdt_size_to_cpu(reg) be64_to_cpu(reg)
#else
#define FDT_ADDR_T_NONE (-1U)
#define fdt_addr_to_cpu(reg) be32_to_cpu(reg)
#define fdt_size_to_cpu(reg) be32_to_cpu(reg)
#endif

On x86, CONFIG_PHYS_64BIT is not defined, so FDT_ADDR_T_NONE becomes -1U.

In the ns16550 driver, the code logic is:

/* try Processor Local Bus device first */
addr = dev_get_addr(dev);
#ifdef CONFIG_PCI
if (addr == FDT_ADDR_T_NONE) {
/* then try pci device */

With OF_TRANSLATE set to y, dev_get_addr() returns OF_BAD_ADDR if no
valid address found, but OF_BAD_ADDR is defined as:

#define OF_BAD_ADDR ((u64)-1)

This creates a size mismatch as FDT_ADDR_T_NONE can be -1U or -1ULL
depending on CONFIG_PHYS_64BIT but OF_BAD_ADDR is always -1ULL.

The patch below fixes this issue:

diff --git a/common/fdt_support.c b/common/fdt_support.c
index f86365e..8930f34 100644
--- a/common/fdt_support.c
+++ 

[U-Boot] [PATCH v4] common: board: Dont relocate FDT incase of CONFIG_OF_EMBED

[Michal Simek]

From: Siva Durga Prasad Paladugu 

Don't relocate fdt in case of CONFIG_OF EMBED as the fdt is
already embedded with u-boot image.
Update fdt_blob after relocation as the fdt will be copied
during u-boot relocation.

Signed-off-by: Siva Durga Prasad Paladugu 
Signed-off-by: Michal Simek 
Reviewed-by: Alexey Brodkin 
Reviewed-by: Bin Meng 
Tested-by: Bin Meng  (QEMU x86)
Tested-by: Thomas Chou  (Nios2)
Acked-by: Thomas Chou 
Acked-by: Simon Glass 
---

Changes in v4:
- board: Update fdt_blob after relocation. Updating it before
  relocation may cause issue with some devices if they try to use
  it before it actually relocated

Changes in v3:
- Remove maybe unused and move ifdefs to functions directly - reported
  by Simon

Changes in v2:
- Fix commit message reported by Alexey

 common/board_f.c | 4 
 common/board_r.c | 8 
 2 files changed, 12 insertions(+)

diff --git a/common/board_f.c b/common/board_f.c
index b035c90ff3b7..668a0478a45b 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -510,6 +510,7 @@ static int reserve_global_data(void)
 
 static int reserve_fdt(void)
 {
+#ifndef CONFIG_OF_EMBED
/*
 * If the device tree is sitting immediately above our image then we
 * must relocate it. If it is embedded in the data section, then it
@@ -523,6 +524,7 @@ static int reserve_fdt(void)
debug("Reserving %lu Bytes for FDT at: %08lx\n",
  gd->fdt_size, gd->start_addr_sp);
}
+#endif
 
return 0;
 }
@@ -660,12 +662,14 @@ static int setup_dram_config(void)
 
 static int reloc_fdt(void)
 {
+#ifndef CONFIG_OF_EMBED
if (gd->flags & GD_FLG_SKIP_RELOC)
return 0;
if (gd->new_fdt) {
memcpy(gd->new_fdt, gd->fdt_blob, gd->fdt_size);
gd->fdt_blob = gd->new_fdt;
}
+#endif
 
return 0;
 }
diff --git a/common/board_r.c b/common/board_r.c
index f7118e8fc486..8b6576c233f2 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -165,6 +165,14 @@ static int initr_reloc_global_data(void)
 */
gd->env_addr += gd->relocaddr - CONFIG_SYS_MONITOR_BASE;
 #endif
+#ifdef CONFIG_OF_EMBED
+   /*
+   * The fdt_blob needs to be moved to new relocation address
+   * incase of FDT blob is embedded with in image
+   */
+   gd->fdt_blob += gd->reloc_off;
+#endif
+
return 0;
 }
 
-- 
1.9.1

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

[U-Boot] [PATCH v3 08/14] net: gem: Check if priv->phydev is valid

[Michal Simek]

Check return value.

Signed-off-by: Michal Simek 
---

Changes in v3: None
Changes in v2: None

 drivers/net/zynq_gem.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/zynq_gem.c b/drivers/net/zynq_gem.c
index 86bb75905071..d5540ec2155c 100644
--- a/drivers/net/zynq_gem.c
+++ b/drivers/net/zynq_gem.c
@@ -329,6 +329,8 @@ static int zynq_phy_init(struct eth_device *dev)
 
priv->phydev = phy_connect(priv->bus, priv->phyaddr, dev,
   priv->interface);
+   if (!priv->phydev)
+   return -ENODEV;
 
priv->phydev->supported = supported | ADVERTISED_Pause |
  ADVERTISED_Asym_Pause;
-- 
1.9.1

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

[U-Boot] [PATCH v3 06/14] net: gem: Remove phydev variable

[Michal Simek]

Resort code to use priv->phydev variable directly.
It will simplify move to DM.

Signed-off-by: Michal Simek 
---

Changes in v3: None
Changes in v2: None

 drivers/net/zynq_gem.c | 23 ++-
 1 file changed, 10 insertions(+), 13 deletions(-)

diff --git a/drivers/net/zynq_gem.c b/drivers/net/zynq_gem.c
index 65ea5deb23c6..8f3fe9130066 100644
--- a/drivers/net/zynq_gem.c
+++ b/drivers/net/zynq_gem.c
@@ -315,7 +315,6 @@ static int zynq_gem_init(struct eth_device *dev, bd_t * bis)
u32 i;
int ret;
unsigned long clk_rate = 0;
-   struct phy_device *phydev;
struct zynq_gem_regs *regs = (struct zynq_gem_regs *)dev->iobase;
struct zynq_gem_priv *priv = dev->priv;
struct emac_bd *dummy_tx_bd = >tx_bd[TX_FREE_DESC];
@@ -394,23 +393,21 @@ static int zynq_gem_init(struct eth_device *dev, bd_t * 
bis)
return ret;
}
 
-   /* interface - look at tsec */
-   phydev = phy_connect(priv->bus, priv->phyaddr, dev,
-priv->interface);
+   priv->phydev = phy_connect(priv->bus, priv->phyaddr, dev,
+  priv->interface);
 
-   phydev->supported = supported | ADVERTISED_Pause |
-   ADVERTISED_Asym_Pause;
-   phydev->advertising = phydev->supported;
-   priv->phydev = phydev;
-   phy_config(phydev);
-   phy_startup(phydev);
+   priv->phydev->supported = supported | ADVERTISED_Pause |
+ ADVERTISED_Asym_Pause;
+   priv->phydev->advertising = priv->phydev->supported;
+   phy_config(priv->phydev);
+   phy_startup(priv->phydev);
 
-   if (!phydev->link) {
-   printf("%s: No link.\n", phydev->dev->name);
+   if (!priv->phydev->link) {
+   printf("%s: No link.\n", priv->phydev->dev->name);
return -1;
}
 
-   switch (phydev->speed) {
+   switch (priv->phydev->speed) {
case SPEED_1000:
writel(ZYNQ_GEM_NWCFG_INIT | ZYNQ_GEM_NWCFG_SPEED1000,
   >nwcfg);
-- 
1.9.1

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

[U-Boot] [PATCH v3 11/14] net: gem: Fix miiphy_read name

[Michal Simek]

Sync it with write function.

Signed-off-by: Michal Simek 
---

Changes in v3: None
Changes in v2: None

 drivers/net/zynq_gem.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/zynq_gem.c b/drivers/net/zynq_gem.c
index a569c77aeb60..4e93707c7ab1 100644
--- a/drivers/net/zynq_gem.c
+++ b/drivers/net/zynq_gem.c
@@ -569,7 +569,7 @@ static void zynq_gem_halt(struct eth_device *dev)
ZYNQ_GEM_NWCTRL_TXEN_MASK, 0);
 }
 
-static int zynq_gem_miiphyread(const char *devname, uchar addr,
+static int zynq_gem_miiphy_read(const char *devname, uchar addr,
uchar reg, ushort *val)
 {
struct eth_device *dev = eth_get_dev();
@@ -645,7 +645,7 @@ int zynq_gem_initialize(bd_t *bis, phys_addr_t base_addr,
 
eth_register(dev);
 
-   miiphy_register(dev->name, zynq_gem_miiphyread, zynq_gem_miiphy_write);
+   miiphy_register(dev->name, zynq_gem_miiphy_read, zynq_gem_miiphy_write);
priv->bus = miiphy_get_dev_by_name(dev->name);
 
ret = zynq_phy_init(dev);
-- 
1.9.1

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

[U-Boot] [PATCH v3 04/14] net: gem: Change mdio_wait prototype to pass regs

[Michal Simek]

Pass regs instead of dev because this will be chagned by
driver model.

Signed-off-by: Michal Simek 
---

Changes in v3: None
Changes in v2: None

 drivers/net/zynq_gem.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/net/zynq_gem.c b/drivers/net/zynq_gem.c
index 1a5a366c9444..7f801d5c4c03 100644
--- a/drivers/net/zynq_gem.c
+++ b/drivers/net/zynq_gem.c
@@ -172,9 +172,8 @@ struct zynq_gem_priv {
struct mii_dev *bus;
 };
 
-static inline int mdio_wait(struct eth_device *dev)
+static inline int mdio_wait(struct zynq_gem_regs *regs)
 {
-   struct zynq_gem_regs *regs = (struct zynq_gem_regs *)dev->iobase;
u32 timeout = 2;
 
/* Wait till MDIO interface is ready to accept a new transaction. */
@@ -198,7 +197,7 @@ static u32 phy_setup_op(struct eth_device *dev, u32 
phy_addr, u32 regnum,
u32 mgtcr;
struct zynq_gem_regs *regs = (struct zynq_gem_regs *)dev->iobase;
 
-   if (mdio_wait(dev))
+   if (mdio_wait(regs))
return 1;
 
/* Construct mgtcr mask for the operation */
@@ -209,7 +208,7 @@ static u32 phy_setup_op(struct eth_device *dev, u32 
phy_addr, u32 regnum,
/* Write mgtcr and wait for completion */
writel(mgtcr, >phymntnc);
 
-   if (mdio_wait(dev))
+   if (mdio_wait(regs))
return 1;
 
if (op == ZYNQ_GEM_PHYMNTNC_OP_R_MASK)
-- 
1.9.1

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

Re: [U-Boot] [PATCH] x86: Clean up SPI flash drivers in defconfig

[Bin Meng]

Hi Jagan,

On Thu, Dec 3, 2015 at 6:24 PM, Jagan Teki  wrote:
> Hi Bin,
>
> On 3 December 2015 at 10:14, Bin Meng  wrote:
>> Hi Simon,
>>
>> On Thu, Dec 3, 2015 at 5:05 AM, Simon Glass  wrote:
>>> +Jagan
>>>
>>> Hi Bin,
>>>
>>> On 1 December 2015 at 18:41, Bin Meng  wrote:

 Hi Simon,

 On Wed, Dec 2, 2015 at 12:32 AM, Simon Glass  wrote:
 > Hi Bin,
 >
 > On 28 November 2015 at 05:45, Bin Meng  wrote:
 >> Every board has one dedicated type of SPI flash, hence it is
 >> unnecessary to include multiple SPI flash drivers.
 >>
 >> For QEMU and coreboot (default build of coreboot is also QEMU),
 >> SPI flash is not supported. Remove those SPI flash drivers.
 >>
 >> Signed-off-by: Bin Meng 
 >> ---
 >>
 >>  configs/bayleybay_defconfig | 2 --
 >>  configs/chromebook_link_defconfig   | 2 --
 >>  configs/chromebox_panther_defconfig | 2 --
 >>  configs/coreboot-x86_defconfig  | 4 
 >>  configs/crownbay_defconfig  | 3 ---
 >>  configs/galileo_defconfig   | 2 --
 >>  configs/minnowmax_defconfig | 3 ---
 >>  configs/qemu-x86_defconfig  | 4 
 >>  8 files changed, 22 deletions(-)
 >
 > What is the benefit of this? I see it removes a few lines in a data
 > table. Does it matter?

 Maybe we should ask the other way around, why do we create so many
 flash driver Kconfig option? I believe the intention was footprint.
 Besides the footprint issue, having just one flash driver in each
 board makes it very clear instead of causing confusion. Looks other
 board defconfig files only select one.
>
> Are you talking about flash vendor config or CONFIG_SPI_FLASH?
>

Flash vendor config, as you see in this patch.

>>>
>>> They are a hangover from when we had a separate driver for each one.
>>> Jagan put a lot of effort into removing all the semi-duplicated code.
>>>
>>> Maybe we should prune down these options?
>>>
>>
>> But if we already spent a lot of effort into removing all the
>> semi-duplicated code, we should not have converted those flash driver
>> to Kconfig options before.
>>
>> See commit d5af92315bb48740f16bf8817f38e227d3076905 "sf: kconfig: add
>> kconfig options for spi flashes"
>>
>> I suspect we may remove most of these SPI flash macros, but at least
>> SST flash macro should be kept since right now it is mixed in the
>> generic driver with a special byte program and word program which is
>> incompatible with other vendors' flashes.
>
> But there is some flash vendor specific code like quad enable bit,
> locking ops and finally about spi_flash_params table.
>

I know. That's probably why adding all these SPI flash drivers don't
help at all because only one code path will take effect. And what I
did in this patch is to select one type of flash per board.

>>

 >
 > For all of these platforms we can use the dediprog em100 which I
 > typically set to use winbond as the manufacturer, regardless of which
 > chip is actually on the board.
 >

 I think that's because emulator can emulate flash from various vendors.
>>>
>>> Yes, and also for convenience.
>>>

 > For U-Boot on coreboot, why is SPI flash not supported? It certainly
 > works with link.

 Yes, booting from coreboot does support SPI flash. However since we
 decided to use QEMU as the default build target for coreboot, and QEMU
 does not support SPI flash yet, these config options are removed. One
 can certainly adjust these Kconfig options via 'make menuconfig', eg:
 adding SD/MMC support which is not in coreboot's defconfig either.
>>>
>>> Well this breaks booting on link, since the SPI flash stops working.
>>> I'm really not keen on having to specially select the SPI flash when
>>> you want to use link.
>>>
>>
>> Do you mean booting U-Boot on link from coreboot? Without SPI flash it
>> should still boot. It looks to me your preference is to include all
>> the available drivers into coreboot's defconfig, yes? If so, we may
>> add some other drivers Kconfig in coreboot-x86_defconfig too, like
>> SD/MMC drivers, all the available ethernet drivers even they only
>> exist on some boards.
>
> thanks!
> --

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

Re: [U-Boot] [PATCH v3] dm: core: Enable optional use of fdt_translate_address()

[Bin Meng]

Hi Stefan, Simon,

On Mon, Oct 19, 2015 at 7:16 AM, Simon Glass  wrote:
> On 29 September 2015 at 23:00, Stefan Roese  wrote:
>> The current "simple" address translation simple_bus_translate() is not
>> working on some platforms (e.g. MVEBU). As here more complex "ranges"
>> properties are used in many nodes (multiple tuples etc). This patch
>> enables the optional use of the common fdt_translate_address() function
>> which handles this translation correctly.
>>
>> Signed-off-by: Stefan Roese 
>> Cc: Simon Glass 
>> Cc: Bin Meng 
>> Cc: Marek Vasut 
>> Cc: Masahiro Yamada 
>> Cc: Stephen Warren 
>> Cc: Lukasz Majewski 
>> ---
>> v3:
>> - Rebased on current U-Boot version
>> - Added Stephen and Lukasz to Cc
>>
>> v2:
>> - Rework code a bit as suggested by Simon. Also added some comments
>>   to make the use of the code paths more clear.
>>
>>  drivers/core/Kconfig  | 30 ++
>>  drivers/core/device.c | 20 
>>  2 files changed, 50 insertions(+)
>
> Applied to u-boot-dm, thanks!

When testing Simon's patch [1], I found PCI UART on Intel Crown Bay no
longer works. git bisect leads to this commit. Somehow I missed this
patch before although I see the commit message get me cc'ed but the
email did not bring to my attention.

I see this patch introduced OF_TRANSLATE and by default set it to y.
This makes the code logic in dev_get_addr() go through
fdt_translate_address(), which breaks the things. Should we set
OF_TRANSLATE to n by default? If set to y, this requires dts to have
complete ranges property everywhere.

[1]: http://patchwork.ozlabs.org/patch/549799/

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

[U-Boot] [PATCH v3 14/14] net: gem: Move gem to Kconfig

[Michal Simek]

Signed-off-by: Michal Simek 
---

Changes in v3: None
Changes in v2: None

 configs/xilinx_zynqmp_ep_defconfig | 1 +
 configs/zynq_microzed_defconfig| 1 +
 configs/zynq_picozed_defconfig | 1 +
 configs/zynq_zc702_defconfig   | 1 +
 configs/zynq_zc706_defconfig   | 1 +
 configs/zynq_zc770_xm010_defconfig | 1 +
 configs/zynq_zc770_xm011_defconfig | 1 +
 configs/zynq_zc770_xm012_defconfig | 1 +
 configs/zynq_zc770_xm013_defconfig | 1 +
 configs/zynq_zed_defconfig | 1 +
 configs/zynq_zybo_defconfig| 1 +
 drivers/net/Kconfig| 6 ++
 include/configs/xilinx_zynqmp.h| 4 +---
 include/configs/xilinx_zynqmp_ep.h | 3 ---
 include/configs/zynq-common.h  | 3 +--
 include/configs/zynq_microzed.h| 3 ---
 include/configs/zynq_picozed.h | 3 ---
 include/configs/zynq_zc70x.h   | 3 ---
 include/configs/zynq_zc770.h   | 4 
 include/configs/zynq_zed.h | 3 ---
 include/configs/zynq_zybo.h| 3 ---
 21 files changed, 19 insertions(+), 27 deletions(-)

diff --git a/configs/xilinx_zynqmp_ep_defconfig 
b/configs/xilinx_zynqmp_ep_defconfig
index 79304c1fb121..22915f19bfbb 100644
--- a/configs/xilinx_zynqmp_ep_defconfig
+++ b/configs/xilinx_zynqmp_ep_defconfig
@@ -22,4 +22,5 @@ CONFIG_CMD_TIME=y
 CONFIG_CMD_TIMER=y
 CONFIG_OF_EMBED=y
 CONFIG_NET_RANDOM_ETHADDR=y
+CONFIG_ZYNQ_GEM=y
 # CONFIG_REGEX is not set
diff --git a/configs/zynq_microzed_defconfig b/configs/zynq_microzed_defconfig
index 0608d8a733cf..c68efc8f41af 100644
--- a/configs/zynq_microzed_defconfig
+++ b/configs/zynq_microzed_defconfig
@@ -16,4 +16,5 @@ CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_SPI_FLASH_WINBOND=y
 CONFIG_PHYLIB=y
+CONFIG_ZYNQ_GEM=y
 CONFIG_ZYNQ_QSPI=y
diff --git a/configs/zynq_picozed_defconfig b/configs/zynq_picozed_defconfig
index d6f0ce388832..62eb79f630e3 100644
--- a/configs/zynq_picozed_defconfig
+++ b/configs/zynq_picozed_defconfig
@@ -9,3 +9,4 @@ CONFIG_CMD_GPIO=y
 # CONFIG_CMD_SETEXPR is not set
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_PHYLIB=y
+CONFIG_ZYNQ_GEM=y
diff --git a/configs/zynq_zc702_defconfig b/configs/zynq_zc702_defconfig
index 8318b94ecbb2..dd588aff72db 100644
--- a/configs/zynq_zc702_defconfig
+++ b/configs/zynq_zc702_defconfig
@@ -15,4 +15,5 @@ CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_SPI_FLASH_WINBOND=y
 CONFIG_PHYLIB=y
+CONFIG_ZYNQ_GEM=y
 CONFIG_ZYNQ_QSPI=y
diff --git a/configs/zynq_zc706_defconfig b/configs/zynq_zc706_defconfig
index 533aff9a7531..2e525b42d42a 100644
--- a/configs/zynq_zc706_defconfig
+++ b/configs/zynq_zc706_defconfig
@@ -16,4 +16,5 @@ CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_SPI_FLASH_WINBOND=y
 CONFIG_PHYLIB=y
+CONFIG_ZYNQ_GEM=y
 CONFIG_ZYNQ_QSPI=y
diff --git a/configs/zynq_zc770_xm010_defconfig 
b/configs/zynq_zc770_xm010_defconfig
index 689d19e992da..6f2ad17985e1 100644
--- a/configs/zynq_zc770_xm010_defconfig
+++ b/configs/zynq_zc770_xm010_defconfig
@@ -18,5 +18,6 @@ CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_SPI_FLASH_SST=y
 CONFIG_SPI_FLASH_WINBOND=y
 CONFIG_PHYLIB=y
+CONFIG_ZYNQ_GEM=y
 CONFIG_ZYNQ_SPI=y
 CONFIG_ZYNQ_QSPI=y
diff --git a/configs/zynq_zc770_xm011_defconfig 
b/configs/zynq_zc770_xm011_defconfig
index c7125c304ab8..d20b3edf5cb3 100644
--- a/configs/zynq_zc770_xm011_defconfig
+++ b/configs/zynq_zc770_xm011_defconfig
@@ -13,3 +13,4 @@ CONFIG_CMD_GPIO=y
 # CONFIG_CMD_SETEXPR is not set
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_PHYLIB=y
+CONFIG_ZYNQ_GEM=y
diff --git a/configs/zynq_zc770_xm012_defconfig 
b/configs/zynq_zc770_xm012_defconfig
index a8f28da11767..4e963a45e2cf 100644
--- a/configs/zynq_zc770_xm012_defconfig
+++ b/configs/zynq_zc770_xm012_defconfig
@@ -11,3 +11,4 @@ CONFIG_CMD_GPIO=y
 # CONFIG_CMD_SETEXPR is not set
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_PHYLIB=y
+CONFIG_ZYNQ_GEM=y
diff --git a/configs/zynq_zc770_xm013_defconfig 
b/configs/zynq_zc770_xm013_defconfig
index 6b2fd8ca4ebb..f2d8f14f8784 100644
--- a/configs/zynq_zc770_xm013_defconfig
+++ b/configs/zynq_zc770_xm013_defconfig
@@ -13,3 +13,4 @@ CONFIG_CMD_GPIO=y
 # CONFIG_CMD_SETEXPR is not set
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_PHYLIB=y
+CONFIG_ZYNQ_GEM=y
diff --git a/configs/zynq_zed_defconfig b/configs/zynq_zed_defconfig
index 4076c30707b1..2e7c68d6a49e 100644
--- a/configs/zynq_zed_defconfig
+++ b/configs/zynq_zed_defconfig
@@ -16,4 +16,5 @@ CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_SPI_FLASH_WINBOND=y
 CONFIG_PHYLIB=y
+CONFIG_ZYNQ_GEM=y
 CONFIG_ZYNQ_QSPI=y
diff --git a/configs/zynq_zybo_defconfig b/configs/zynq_zybo_defconfig
index c51049e664b1..6f0bd0b79c5e 100644
--- a/configs/zynq_zybo_defconfig
+++ b/configs/zynq_zybo_defconfig
@@ -12,6 +12,7 @@ CONFIG_CMD_GPIO=y
 # CONFIG_CMD_SETEXPR is not set
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_PHYLIB=y
+CONFIG_ZYNQ_GEM=y
 CONFIG_DEBUG_UART=y
 CONFIG_DEBUG_UART_ZYNQ=y
 CONFIG_DEBUG_UART_BASE=0xe0001000
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index a03a95d0fbff..6905cc02e392 

[U-Boot] [PATCH v3 13/14] net: gem: Read information about interface from DT

[Michal Simek]

Do not set interface via configs. Read information from DT.

Signed-off-by: Michal Simek 
---

Changes in v3: None
Changes in v2: None

 drivers/net/zynq_gem.c | 20 
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/drivers/net/zynq_gem.c b/drivers/net/zynq_gem.c
index 9e8616e0530a..0ee909c97fdf 100644
--- a/drivers/net/zynq_gem.c
+++ b/drivers/net/zynq_gem.c
@@ -621,12 +621,6 @@ static int zynq_gem_probe(struct udevice *dev)
priv->bus->priv = priv;
strcpy(priv->bus->name, "gem");
 
-#ifndef CONFIG_ZYNQ_GEM_INTERFACE
-   priv->interface = PHY_INTERFACE_MODE_MII;
-#else
-   priv->interface = CONFIG_ZYNQ_GEM_INTERFACE;
-#endif
-
ret = mdio_register(priv->bus);
if (ret)
return ret;
@@ -660,6 +654,7 @@ static int zynq_gem_ofdata_to_platdata(struct udevice *dev)
struct eth_pdata *pdata = dev_get_platdata(dev);
struct zynq_gem_priv *priv = dev_get_priv(dev);
int offset = 0;
+   const char *phy_mode;
 
pdata->iobase = (phys_addr_t)dev_get_addr(dev);
priv->iobase = (struct zynq_gem_regs *)pdata->iobase;
@@ -671,8 +666,17 @@ static int zynq_gem_ofdata_to_platdata(struct udevice *dev)
if (offset > 0)
priv->phyaddr = fdtdec_get_int(gd->fdt_blob, offset, "reg", 0);
 
-   printf("ZYNQ GEM: %lx, phyaddr %d\n", (ulong)priv->iobase,
-  priv->phyaddr);
+   phy_mode = fdt_getprop(gd->fdt_blob, dev->of_offset, "phy-mode", NULL);
+   if (phy_mode)
+   pdata->phy_interface = phy_get_interface_by_name(phy_mode);
+   if (pdata->phy_interface == -1) {
+   debug("%s: Invalid PHY interface '%s'\n", __func__, phy_mode);
+   return -EINVAL;
+   }
+   priv->interface = pdata->phy_interface;
+
+   printf("ZYNQ GEM: %lx, phyaddr %d, interface %s\n", (ulong)priv->iobase,
+  priv->phyaddr, phy_string_for_interface(priv->interface));
 
return 0;
 }
-- 
1.9.1

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

Re: [U-Boot] [PATCH v3] dm: core: Enable optional use of fdt_translate_address()

[Stefan Roese]

Hi Bin,

On 03.12.2015 14:34, Bin Meng wrote:

Hi Stefan, Simon,

On Mon, Oct 19, 2015 at 7:16 AM, Simon Glass  wrote:

On 29 September 2015 at 23:00, Stefan Roese  wrote:

The current "simple" address translation simple_bus_translate() is not
working on some platforms (e.g. MVEBU). As here more complex "ranges"
properties are used in many nodes (multiple tuples etc). This patch
enables the optional use of the common fdt_translate_address() function
which handles this translation correctly.

Signed-off-by: Stefan Roese 
Cc: Simon Glass 
Cc: Bin Meng 
Cc: Marek Vasut 
Cc: Masahiro Yamada 
Cc: Stephen Warren 
Cc: Lukasz Majewski 
---
v3:
- Rebased on current U-Boot version
- Added Stephen and Lukasz to Cc

v2:
- Rework code a bit as suggested by Simon. Also added some comments
   to make the use of the code paths more clear.

  drivers/core/Kconfig  | 30 ++
  drivers/core/device.c | 20 
  2 files changed, 50 insertions(+)


Applied to u-boot-dm, thanks!


When testing Simon's patch [1], I found PCI UART on Intel Crown Bay no
longer works. git bisect leads to this commit. Somehow I missed this
patch before although I see the commit message get me cc'ed but the
email did not bring to my attention.

I see this patch introduced OF_TRANSLATE and by default set it to y.
This makes the code logic in dev_get_addr() go through
fdt_translate_address(), which breaks the things.


I'm a bit surprised that using the common fdt_translate_address()
function instead of the DM internal simple_bus_translate() causes
problems on your platform. Are you sure that the ranges are
described correctly in your dts? Is the dts a copy from the Linux
original one? Ah, probably not, since we're talking about x86
which has no DT support in Linux, right?


Should we set
OF_TRANSLATE to n by default? If set to y, this requires dts to have
complete ranges property everywhere.


My understanding here is that x86 is a special case. As it doesn't
use the full-blown dts sources from Linux. But most likely some
"simple" ones, written exactly for U-Boot / DM.

I would still prefer to have this OF_TRANSLATE set to y as default.
As its needed for at least some platforms. But if we decide to
set it to n, I can live with it as well.

Thanks,
Stefan

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

[U-Boot] [PATCH v3 02/14] ARM: zynq: Remove CONFIG_API

[Michal Simek]

CONFIG_API is causing compilation error when DM_ETH is enabled because
eth_get_dev() is not available.

Signed-off-by: Michal Simek 
---

Changes in v3: None
Changes in v2: None

 include/configs/zynq-common.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/include/configs/zynq-common.h b/include/configs/zynq-common.h
index a9e6bf046a97..5db501188b18 100644
--- a/include/configs/zynq-common.h
+++ b/include/configs/zynq-common.h
@@ -297,7 +297,6 @@
 
 /* Boot FreeBSD/vxWorks from an ELF image */
 #if defined(CONFIG_ZYNQ_BOOT_FREEBSD)
-# define CONFIG_API
 # define CONFIG_SYS_MMC_MAX_DEVICE 1
 #endif
 
-- 
1.9.1

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

[U-Boot] [PATCH v3 03/14] net: gem: Do not continue if phy is not found

[Michal Simek]

Add return value for phy detection algorithm to stop init function when
phy is not found.

Signed-off-by: Michal Simek 
---

Changes in v3: None
Changes in v2: None

 drivers/net/zynq_gem.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/net/zynq_gem.c b/drivers/net/zynq_gem.c
index 858093f0d7e2..1a5a366c9444 100644
--- a/drivers/net/zynq_gem.c
+++ b/drivers/net/zynq_gem.c
@@ -241,7 +241,7 @@ static u32 phywrite(struct eth_device *dev, u32 phy_addr, 
u32 regnum, u16 data)
ZYNQ_GEM_PHYMNTNC_OP_W_MASK, );
 }
 
-static void phy_detection(struct eth_device *dev)
+static int phy_detection(struct eth_device *dev)
 {
int i;
u16 phyreg;
@@ -254,7 +254,7 @@ static void phy_detection(struct eth_device *dev)
/* Found a valid PHY address */
debug("Default phy address %d is valid\n",
  priv->phyaddr);
-   return;
+   return 0;
} else {
debug("PHY address is not setup correctly %d\n",
  priv->phyaddr);
@@ -272,11 +272,12 @@ static void phy_detection(struct eth_device *dev)
/* Found a valid PHY address */
priv->phyaddr = i;
debug("Found valid phy address, %d\n", i);
-   return;
+   return 0;
}
}
}
printf("PHY is not detected\n");
+   return -1;
 }
 
 static int zynq_gem_setup_mac(struct eth_device *dev)
@@ -310,6 +311,7 @@ static int zynq_gem_setup_mac(struct eth_device *dev)
 static int zynq_gem_init(struct eth_device *dev, bd_t * bis)
 {
u32 i;
+   int ret;
unsigned long clk_rate = 0;
struct phy_device *phydev;
struct zynq_gem_regs *regs = (struct zynq_gem_regs *)dev->iobase;
@@ -384,7 +386,11 @@ static int zynq_gem_init(struct eth_device *dev, bd_t * 
bis)
priv->init++;
}
 
-   phy_detection(dev);
+   ret = phy_detection(dev);
+   if (ret) {
+   printf("GEM PHY init failed\n");
+   return ret;
+   }
 
/* interface - look at tsec */
phydev = phy_connect(priv->bus, priv->phyaddr, dev,
-- 
1.9.1

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

[U-Boot] [PATCH v3 01/14] ARM: zynq: Remove PHYLIB from config to defconfig

[Michal Simek]

Move PHYLIB from board config to defconfig

Signed-off-by: Michal Simek 
---

Changes in v3: None
Changes in v2: None

 configs/zynq_microzed_defconfig| 1 +
 configs/zynq_picozed_defconfig | 1 +
 configs/zynq_zc702_defconfig   | 1 +
 configs/zynq_zc706_defconfig   | 1 +
 configs/zynq_zc770_xm010_defconfig | 1 +
 configs/zynq_zc770_xm011_defconfig | 1 +
 configs/zynq_zc770_xm012_defconfig | 1 +
 configs/zynq_zc770_xm013_defconfig | 1 +
 configs/zynq_zed_defconfig | 1 +
 configs/zynq_zybo_defconfig| 1 +
 include/configs/zynq-common.h  | 1 -
 11 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/configs/zynq_microzed_defconfig b/configs/zynq_microzed_defconfig
index 3bf17cfc7ab7..0608d8a733cf 100644
--- a/configs/zynq_microzed_defconfig
+++ b/configs/zynq_microzed_defconfig
@@ -15,4 +15,5 @@ CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_SPI_FLASH_WINBOND=y
+CONFIG_PHYLIB=y
 CONFIG_ZYNQ_QSPI=y
diff --git a/configs/zynq_picozed_defconfig b/configs/zynq_picozed_defconfig
index 600ca8b2f347..d6f0ce388832 100644
--- a/configs/zynq_picozed_defconfig
+++ b/configs/zynq_picozed_defconfig
@@ -8,3 +8,4 @@ CONFIG_SPL=y
 CONFIG_CMD_GPIO=y
 # CONFIG_CMD_SETEXPR is not set
 CONFIG_NET_RANDOM_ETHADDR=y
+CONFIG_PHYLIB=y
diff --git a/configs/zynq_zc702_defconfig b/configs/zynq_zc702_defconfig
index e3c1e23638ff..8318b94ecbb2 100644
--- a/configs/zynq_zc702_defconfig
+++ b/configs/zynq_zc702_defconfig
@@ -14,4 +14,5 @@ CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_SPI_FLASH_WINBOND=y
+CONFIG_PHYLIB=y
 CONFIG_ZYNQ_QSPI=y
diff --git a/configs/zynq_zc706_defconfig b/configs/zynq_zc706_defconfig
index eaf15f2d700c..533aff9a7531 100644
--- a/configs/zynq_zc706_defconfig
+++ b/configs/zynq_zc706_defconfig
@@ -15,4 +15,5 @@ CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_SPI_FLASH_WINBOND=y
+CONFIG_PHYLIB=y
 CONFIG_ZYNQ_QSPI=y
diff --git a/configs/zynq_zc770_xm010_defconfig 
b/configs/zynq_zc770_xm010_defconfig
index 381ace8ace6f..689d19e992da 100644
--- a/configs/zynq_zc770_xm010_defconfig
+++ b/configs/zynq_zc770_xm010_defconfig
@@ -17,5 +17,6 @@ CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_SPI_FLASH_SST=y
 CONFIG_SPI_FLASH_WINBOND=y
+CONFIG_PHYLIB=y
 CONFIG_ZYNQ_SPI=y
 CONFIG_ZYNQ_QSPI=y
diff --git a/configs/zynq_zc770_xm011_defconfig 
b/configs/zynq_zc770_xm011_defconfig
index 49dd02554c88..c7125c304ab8 100644
--- a/configs/zynq_zc770_xm011_defconfig
+++ b/configs/zynq_zc770_xm011_defconfig
@@ -12,3 +12,4 @@ CONFIG_SYS_EXTRA_OPTIONS="ZC770_XM011"
 CONFIG_CMD_GPIO=y
 # CONFIG_CMD_SETEXPR is not set
 CONFIG_NET_RANDOM_ETHADDR=y
+CONFIG_PHYLIB=y
diff --git a/configs/zynq_zc770_xm012_defconfig 
b/configs/zynq_zc770_xm012_defconfig
index d50594371aaa..a8f28da11767 100644
--- a/configs/zynq_zc770_xm012_defconfig
+++ b/configs/zynq_zc770_xm012_defconfig
@@ -10,3 +10,4 @@ CONFIG_SYS_EXTRA_OPTIONS="ZC770_XM012"
 CONFIG_CMD_GPIO=y
 # CONFIG_CMD_SETEXPR is not set
 CONFIG_NET_RANDOM_ETHADDR=y
+CONFIG_PHYLIB=y
diff --git a/configs/zynq_zc770_xm013_defconfig 
b/configs/zynq_zc770_xm013_defconfig
index c2ae2ab2809d..6b2fd8ca4ebb 100644
--- a/configs/zynq_zc770_xm013_defconfig
+++ b/configs/zynq_zc770_xm013_defconfig
@@ -12,3 +12,4 @@ CONFIG_SYS_EXTRA_OPTIONS="ZC770_XM013"
 CONFIG_CMD_GPIO=y
 # CONFIG_CMD_SETEXPR is not set
 CONFIG_NET_RANDOM_ETHADDR=y
+CONFIG_PHYLIB=y
diff --git a/configs/zynq_zed_defconfig b/configs/zynq_zed_defconfig
index f603bb360106..4076c30707b1 100644
--- a/configs/zynq_zed_defconfig
+++ b/configs/zynq_zed_defconfig
@@ -15,4 +15,5 @@ CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_SPI_FLASH_WINBOND=y
+CONFIG_PHYLIB=y
 CONFIG_ZYNQ_QSPI=y
diff --git a/configs/zynq_zybo_defconfig b/configs/zynq_zybo_defconfig
index 1227b7a14c32..c51049e664b1 100644
--- a/configs/zynq_zybo_defconfig
+++ b/configs/zynq_zybo_defconfig
@@ -11,6 +11,7 @@ CONFIG_FIT_SIGNATURE=y
 CONFIG_CMD_GPIO=y
 # CONFIG_CMD_SETEXPR is not set
 CONFIG_NET_RANDOM_ETHADDR=y
+CONFIG_PHYLIB=y
 CONFIG_DEBUG_UART=y
 CONFIG_DEBUG_UART_ZYNQ=y
 CONFIG_DEBUG_UART_BASE=0xe0001000
diff --git a/include/configs/zynq-common.h b/include/configs/zynq-common.h
index fa83ac7b15d0..a9e6bf046a97 100644
--- a/include/configs/zynq-common.h
+++ b/include/configs/zynq-common.h
@@ -50,7 +50,6 @@
 # define CONFIG_ZYNQ_GEM
 # define CONFIG_MII
 # define CONFIG_SYS_FAULT_ECHO_LINK_DOWN
-# define CONFIG_PHYLIB
 # define CONFIG_PHY_MARVELL
 # define CONFIG_BOOTP_SERVERIP
 # define CONFIG_BOOTP_BOOTPATH
-- 
1.9.1

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

[U-Boot] [PATCH v3 05/14] net: gem: Change mii function not to use eth_device structure

[Michal Simek]

Next step to move driver to driver model. Do not use eth_device
structure. Use private structure instead.
Add iobase to private structure to store gem iobase.

Signed-off-by: Michal Simek 
---

Changes in v3: None
Changes in v2: None

 drivers/net/zynq_gem.c | 32 +++-
 1 file changed, 19 insertions(+), 13 deletions(-)

diff --git a/drivers/net/zynq_gem.c b/drivers/net/zynq_gem.c
index 7f801d5c4c03..65ea5deb23c6 100644
--- a/drivers/net/zynq_gem.c
+++ b/drivers/net/zynq_gem.c
@@ -167,6 +167,7 @@ struct zynq_gem_priv {
int phyaddr;
u32 emio;
int init;
+   struct zynq_gem_regs *iobase;
phy_interface_t interface;
struct phy_device *phydev;
struct mii_dev *bus;
@@ -191,11 +192,11 @@ static inline int mdio_wait(struct zynq_gem_regs *regs)
return 0;
 }
 
-static u32 phy_setup_op(struct eth_device *dev, u32 phy_addr, u32 regnum,
-   u32 op, u16 *data)
+static u32 phy_setup_op(struct zynq_gem_priv *priv, u32 phy_addr, u32 regnum,
+   u32 op, u16 *data)
 {
u32 mgtcr;
-   struct zynq_gem_regs *regs = (struct zynq_gem_regs *)dev->iobase;
+   struct zynq_gem_regs *regs = priv->iobase;
 
if (mdio_wait(regs))
return 1;
@@ -217,12 +218,13 @@ static u32 phy_setup_op(struct eth_device *dev, u32 
phy_addr, u32 regnum,
return 0;
 }
 
-static u32 phyread(struct eth_device *dev, u32 phy_addr, u32 regnum, u16 *val)
+static u32 phyread(struct zynq_gem_priv *priv, u32 phy_addr,
+  u32 regnum, u16 *val)
 {
u32 ret;
 
-   ret = phy_setup_op(dev, phy_addr, regnum,
-   ZYNQ_GEM_PHYMNTNC_OP_R_MASK, val);
+   ret = phy_setup_op(priv, phy_addr, regnum,
+  ZYNQ_GEM_PHYMNTNC_OP_R_MASK, val);
 
if (!ret)
debug("%s: phy_addr %d, regnum 0x%x, val 0x%x\n", __func__,
@@ -231,13 +233,14 @@ static u32 phyread(struct eth_device *dev, u32 phy_addr, 
u32 regnum, u16 *val)
return ret;
 }
 
-static u32 phywrite(struct eth_device *dev, u32 phy_addr, u32 regnum, u16 data)
+static u32 phywrite(struct zynq_gem_priv *priv, u32 phy_addr,
+   u32 regnum, u16 data)
 {
debug("%s: phy_addr %d, regnum 0x%x, data 0x%x\n", __func__, phy_addr,
  regnum, data);
 
-   return phy_setup_op(dev, phy_addr, regnum,
-   ZYNQ_GEM_PHYMNTNC_OP_W_MASK, );
+   return phy_setup_op(priv, phy_addr, regnum,
+   ZYNQ_GEM_PHYMNTNC_OP_W_MASK, );
 }
 
 static int phy_detection(struct eth_device *dev)
@@ -247,7 +250,7 @@ static int phy_detection(struct eth_device *dev)
struct zynq_gem_priv *priv = dev->priv;
 
if (priv->phyaddr != -1) {
-   phyread(dev, priv->phyaddr, PHY_DETECT_REG, );
+   phyread(priv, priv->phyaddr, PHY_DETECT_REG, );
if ((phyreg != 0x) &&
((phyreg & PHY_DETECT_MASK) == PHY_DETECT_MASK)) {
/* Found a valid PHY address */
@@ -265,7 +268,7 @@ static int phy_detection(struct eth_device *dev)
if (priv->phyaddr == -1) {
/* detect the PHY address */
for (i = 31; i >= 0; i--) {
-   phyread(dev, i, PHY_DETECT_REG, );
+   phyread(priv, i, PHY_DETECT_REG, );
if ((phyreg != 0x) &&
((phyreg & PHY_DETECT_MASK) == PHY_DETECT_MASK)) {
/* Found a valid PHY address */
@@ -561,9 +564,10 @@ static int zynq_gem_miiphyread(const char *devname, uchar 
addr,
uchar reg, ushort *val)
 {
struct eth_device *dev = eth_get_dev();
+   struct zynq_gem_priv *priv = dev->priv;
int ret;
 
-   ret = phyread(dev, addr, reg, val);
+   ret = phyread(priv, addr, reg, val);
debug("%s 0x%x, 0x%x, 0x%x\n", __func__, addr, reg, *val);
return ret;
 }
@@ -572,9 +576,10 @@ static int zynq_gem_miiphy_write(const char *devname, 
uchar addr,
uchar reg, ushort val)
 {
struct eth_device *dev = eth_get_dev();
+   struct zynq_gem_priv *priv = dev->priv;
 
debug("%s 0x%x, 0x%x, 0x%x\n", __func__, addr, reg, val);
-   return phywrite(dev, addr, reg, val);
+   return phywrite(priv, addr, reg, val);
 }
 
 int zynq_gem_initialize(bd_t *bis, phys_addr_t base_addr,
@@ -620,6 +625,7 @@ int zynq_gem_initialize(bd_t *bis, phys_addr_t base_addr,
sprintf(dev->name, "Gem.%lx", base_addr);
 
dev->iobase = base_addr;
+   priv->iobase = (struct zynq_gem_regs *)base_addr;
 
dev->init = zynq_gem_init;
dev->halt = zynq_gem_halt;
-- 
1.9.1

___
U-Boot mailing list

Re: [U-Boot] [PATCH] dm: core: Distinguish between OF_TRANSLATE and SPL_OF_TRANSLATE

[Michal Simek]

On 3.12.2015 12:22, Stefan Roese wrote:
> On 03.12.2015 12:12, Michal Simek wrote:
>> Kconfig description is the same for both. Extend SPL one to indicate
>> that this option is for SPL only.
>>
>> Signed-off-by: Michal Simek 
>> ---
>>
>>   drivers/core/Kconfig | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/core/Kconfig b/drivers/core/Kconfig
>> index 15681df6d379..b68a26ffcea3 100644
>> --- a/drivers/core/Kconfig
>> +++ b/drivers/core/Kconfig
>> @@ -136,7 +136,7 @@ config OF_TRANSLATE
>> smaller in size than fdt_translate_address().
>>
>>   config SPL_OF_TRANSLATE
>> -bool "Translate addresses using fdt_translate_address"
>> +bool "Translate addresses using fdt_translate_address in SPL"
>>   depends on SPL_DM && SPL_OF_CONTROL
>>   default n
>>   help
> 
> Yes, I've already sent a patch for this:
> 
> http://patchwork.ozlabs.org/patch/549077/

Great. Then ignore this one and feel free to add my
Acked-by: Michal Simek 

Thanks,
Michal

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

[U-Boot] [PATCH v3 10/14] net: gem: Remove zynq_gem_of_init()

[Michal Simek]

This function was used for OF init before DM.
Remove this function as the part of move to DM.

Signed-off-by: Michal Simek 
Reviewed-by: Simon Glass 
---

Changes in v3: None
Changes in v2: None

 drivers/net/zynq_gem.c | 42 --
 include/netdev.h   |  1 -
 2 files changed, 43 deletions(-)

diff --git a/drivers/net/zynq_gem.c b/drivers/net/zynq_gem.c
index 9ce1221e8d0f..a569c77aeb60 100644
--- a/drivers/net/zynq_gem.c
+++ b/drivers/net/zynq_gem.c
@@ -13,8 +13,6 @@
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
 #include 
 #include 
@@ -656,43 +654,3 @@ int zynq_gem_initialize(bd_t *bis, phys_addr_t base_addr,
 
return 1;
 }
-
-#if CONFIG_IS_ENABLED(OF_CONTROL)
-int zynq_gem_of_init(const void *blob)
-{
-   int offset = 0;
-   u32 ret = 0;
-   u32 reg, phy_reg;
-
-   debug("ZYNQ GEM: Initialization\n");
-
-   do {
-   offset = fdt_node_offset_by_compatible(blob, offset,
-   "xlnx,ps7-ethernet-1.00.a");
-   if (offset != -1) {
-   reg = fdtdec_get_addr(blob, offset, "reg");
-   if (reg != FDT_ADDR_T_NONE) {
-   offset = fdtdec_lookup_phandle(blob, offset,
-  "phy-handle");
-   if (offset != -1)
-   phy_reg = fdtdec_get_addr(blob, offset,
- "reg");
-   else
-   phy_reg = 0;
-
-   debug("ZYNQ GEM: addr %x, phyaddr %x\n",
- reg, phy_reg);
-
-   ret |= zynq_gem_initialize(NULL, reg,
-  phy_reg, 0);
-
-   } else {
-   debug("ZYNQ GEM: Can't get base address\n");
-   return -1;
-   }
-   }
-   } while (offset != -1);
-
-   return ret;
-}
-#endif
diff --git a/include/netdev.h b/include/netdev.h
index 28eab4640760..5c6ae5b5624e 100644
--- a/include/netdev.h
+++ b/include/netdev.h
@@ -87,7 +87,6 @@ int xilinx_emaclite_initialize(bd_t *bis, unsigned long 
base_addr,
int txpp, int rxpp);
 int xilinx_ll_temac_eth_init(bd_t *bis, unsigned long base_addr, int flags,
unsigned long ctrl_addr);
-int zynq_gem_of_init(const void *blob);
 int zynq_gem_initialize(bd_t *bis, phys_addr_t base_addr,
int phy_addr, u32 emio);
 /*
-- 
1.9.1

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

[U-Boot] [PATCH v3 07/14] net: gem: Extract phy init code

[Michal Simek]

Move phy init code out of zynq_gem_init. DM drivers are normally calling
this code from probe function.

Signed-off-by: Michal Simek 
---

Changes in v3: None
Changes in v2: None

 drivers/net/zynq_gem.c | 47 ++-
 1 file changed, 30 insertions(+), 17 deletions(-)

diff --git a/drivers/net/zynq_gem.c b/drivers/net/zynq_gem.c
index 8f3fe9130066..86bb75905071 100644
--- a/drivers/net/zynq_gem.c
+++ b/drivers/net/zynq_gem.c
@@ -310,15 +310,10 @@ static int zynq_gem_setup_mac(struct eth_device *dev)
return 0;
 }
 
-static int zynq_gem_init(struct eth_device *dev, bd_t * bis)
+static int zynq_phy_init(struct eth_device *dev)
 {
-   u32 i;
int ret;
-   unsigned long clk_rate = 0;
-   struct zynq_gem_regs *regs = (struct zynq_gem_regs *)dev->iobase;
struct zynq_gem_priv *priv = dev->priv;
-   struct emac_bd *dummy_tx_bd = >tx_bd[TX_FREE_DESC];
-   struct emac_bd *dummy_rx_bd = >tx_bd[TX_FREE_DESC + 2];
const u32 supported = SUPPORTED_10baseT_Half |
SUPPORTED_10baseT_Full |
SUPPORTED_100baseT_Half |
@@ -326,6 +321,33 @@ static int zynq_gem_init(struct eth_device *dev, bd_t * 
bis)
SUPPORTED_1000baseT_Half |
SUPPORTED_1000baseT_Full;
 
+   ret = phy_detection(dev);
+   if (ret) {
+   printf("GEM PHY init failed\n");
+   return ret;
+   }
+
+   priv->phydev = phy_connect(priv->bus, priv->phyaddr, dev,
+  priv->interface);
+
+   priv->phydev->supported = supported | ADVERTISED_Pause |
+ ADVERTISED_Asym_Pause;
+   priv->phydev->advertising = priv->phydev->supported;
+   phy_config(priv->phydev);
+
+   return 0;
+}
+
+static int zynq_gem_init(struct eth_device *dev, bd_t *bis)
+{
+   u32 i;
+   int ret;
+   unsigned long clk_rate = 0;
+   struct zynq_gem_regs *regs = (struct zynq_gem_regs *)dev->iobase;
+   struct zynq_gem_priv *priv = dev->priv;
+   struct emac_bd *dummy_tx_bd = >tx_bd[TX_FREE_DESC];
+   struct emac_bd *dummy_rx_bd = >tx_bd[TX_FREE_DESC + 2];
+
if (!priv->init) {
/* Disable all interrupts */
writel(0x, >idr);
@@ -387,19 +409,10 @@ static int zynq_gem_init(struct eth_device *dev, bd_t * 
bis)
priv->init++;
}
 
-   ret = phy_detection(dev);
-   if (ret) {
-   printf("GEM PHY init failed\n");
+   ret = zynq_phy_init(dev);
+   if (ret)
return ret;
-   }
-
-   priv->phydev = phy_connect(priv->bus, priv->phyaddr, dev,
-  priv->interface);
 
-   priv->phydev->supported = supported | ADVERTISED_Pause |
- ADVERTISED_Asym_Pause;
-   priv->phydev->advertising = priv->phydev->supported;
-   phy_config(priv->phydev);
phy_startup(priv->phydev);
 
if (!priv->phydev->link) {
-- 
1.9.1

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

[U-Boot] [PATCH v3 12/14] net: gem: Move driver to DM

[Michal Simek]

- Enable DM_ETH by default for Zynq and ZynqMP
- Remove board_eth_init code
- Change miiphy_read function to return value instead of error code
  based on DM requirement
- Do not enable EMIO DT support by default

Signed-off-by: Michal Simek 
---

Changes in v3:
- Add remove function reported by Bin Meng

Changes in v2:
- Remove accidentially added mmc code
- Sort dm.h header
- add platdata_auto_alloc_size
- Read iobase from pdata instead of via gev_get_addr
- Check positive return value from fdtdec_lookup_phandles instead of -1

 arch/arm/Kconfig  |   2 +
 board/xilinx/zynq/board.c |  13 ---
 board/xilinx/zynqmp/zynqmp.c  |  25 --
 drivers/net/zynq_gem.c| 179 ++
 include/configs/zynq-common.h |   6 --
 include/netdev.h  |   2 -
 6 files changed, 112 insertions(+), 115 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 6542c38304a5..f989ab521469 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -551,6 +551,7 @@ config ARCH_ZYNQ
select OF_CONTROL
select SPL_OF_CONTROL
select DM
+   select DM_ETH
select SPL_DM
select DM_SPI
select DM_SERIAL
@@ -562,6 +563,7 @@ config ARCH_ZYNQMP
select ARM64
select DM
select OF_CONTROL
+   select DM_ETH
select DM_SERIAL
 
 config TEGRA
diff --git a/board/xilinx/zynq/board.c b/board/xilinx/zynq/board.c
index 237f2c2a2bf6..572b1468bf51 100644
--- a/board/xilinx/zynq/board.c
+++ b/board/xilinx/zynq/board.c
@@ -119,19 +119,6 @@ int board_eth_init(bd_t *bis)
ret |= xilinx_emaclite_initialize(bis, XILINX_EMACLITE_BASEADDR,
txpp, rxpp);
 #endif
-
-#if defined(CONFIG_ZYNQ_GEM)
-# if defined(CONFIG_ZYNQ_GEM0)
-   ret |= zynq_gem_initialize(bis, ZYNQ_GEM_BASEADDR0,
-  CONFIG_ZYNQ_GEM_PHY_ADDR0,
-  CONFIG_ZYNQ_GEM_EMIO0);
-# endif
-# if defined(CONFIG_ZYNQ_GEM1)
-   ret |= zynq_gem_initialize(bis, ZYNQ_GEM_BASEADDR1,
-  CONFIG_ZYNQ_GEM_PHY_ADDR1,
-  CONFIG_ZYNQ_GEM_EMIO1);
-# endif
-#endif
return ret;
 }
 
diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c
index d105bb4de32f..51dc30f90d7e 100644
--- a/board/xilinx/zynqmp/zynqmp.c
+++ b/board/xilinx/zynqmp/zynqmp.c
@@ -65,31 +65,6 @@ void scsi_init(void)
 }
 #endif
 
-int board_eth_init(bd_t *bis)
-{
-   u32 ret = 0;
-
-#if defined(CONFIG_ZYNQ_GEM)
-# if defined(CONFIG_ZYNQ_GEM0)
-   ret |= zynq_gem_initialize(bis, ZYNQ_GEM_BASEADDR0,
-   CONFIG_ZYNQ_GEM_PHY_ADDR0, 0);
-# endif
-# if defined(CONFIG_ZYNQ_GEM1)
-   ret |= zynq_gem_initialize(bis, ZYNQ_GEM_BASEADDR1,
-   CONFIG_ZYNQ_GEM_PHY_ADDR1, 0);
-# endif
-# if defined(CONFIG_ZYNQ_GEM2)
-   ret |= zynq_gem_initialize(bis, ZYNQ_GEM_BASEADDR2,
-   CONFIG_ZYNQ_GEM_PHY_ADDR2, 0);
-# endif
-# if defined(CONFIG_ZYNQ_GEM3)
-   ret |= zynq_gem_initialize(bis, ZYNQ_GEM_BASEADDR3,
-   CONFIG_ZYNQ_GEM_PHY_ADDR3, 0);
-# endif
-#endif
-   return ret;
-}
-
 #ifdef CONFIG_CMD_MMC
 int board_mmc_init(bd_t *bd)
 {
diff --git a/drivers/net/zynq_gem.c b/drivers/net/zynq_gem.c
index 4e93707c7ab1..9e8616e0530a 100644
--- a/drivers/net/zynq_gem.c
+++ b/drivers/net/zynq_gem.c
@@ -10,6 +10,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -23,6 +24,8 @@
 #include 
 #include 
 
+DECLARE_GLOBAL_DATA_PTR;
+
 #if !defined(CONFIG_PHYLIB)
 # error XILINX_GEM_ETHERNET requires PHYLIB
 #endif
@@ -241,7 +244,7 @@ static u32 phywrite(struct zynq_gem_priv *priv, u32 
phy_addr,
ZYNQ_GEM_PHYMNTNC_OP_W_MASK, );
 }
 
-static int phy_detection(struct eth_device *dev)
+static int phy_detection(struct udevice *dev)
 {
int i;
u16 phyreg;
@@ -280,20 +283,22 @@ static int phy_detection(struct eth_device *dev)
return -1;
 }
 
-static int zynq_gem_setup_mac(struct eth_device *dev)
+static int zynq_gem_setup_mac(struct udevice *dev)
 {
u32 i, macaddrlow, macaddrhigh;
-   struct zynq_gem_regs *regs = (struct zynq_gem_regs *)dev->iobase;
+   struct eth_pdata *pdata = dev_get_platdata(dev);
+   struct zynq_gem_priv *priv = dev_get_priv(dev);
+   struct zynq_gem_regs *regs = priv->iobase;
 
/* Set the MAC bits [31:0] in BOT */
-   macaddrlow = dev->enetaddr[0];
-   macaddrlow |= dev->enetaddr[1] << 8;
-   macaddrlow |= dev->enetaddr[2] << 16;
-   macaddrlow |= dev->enetaddr[3] << 24;
+   macaddrlow = pdata->enetaddr[0];
+   macaddrlow |= pdata->enetaddr[1] << 8;
+   macaddrlow |= pdata->enetaddr[2] << 16;
+   macaddrlow |= pdata->enetaddr[3] << 24;
 
/* Set MAC bits [47:32] in TOP */
-  

Re: [U-Boot] [PATCH] distro_bootcmd: do not try to fetch unused bootfile for PXE

[Stephen Warren]

On 12/02/2015 04:15 PM, Stefan Brüns wrote:

pxe get derives the pxelinux config file name from the bootfile name,
but the bootfile itself is never used and might not even exist.
Disable bootfile autoload to avoid the delay.


I wasn't CC'd on this and only accidentally noticed it, since it just 
happened to be the first email in this list folder this morning. It's 
good to CC people based on ./scripts/get_maintainer.pl's output.



diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h



  #define BOOTENV_DEV_PXE(devtypeu, devtypel, instance) \
"bootcmd_pxe=" \
BOOTENV_RUN_USB_INIT \
-   "dhcp; " \
+   "env exists autoload && setenv autoload_save ${autoload}; " \
+   "setenv autoload no; dhcp; " \
+   "env exists autoload_save && setenv autoload ${autoload_save}; 
" \


I think that last line should be unconditional; the previous statement 
unconditionally sets autoload to no, so we want to unconditionally 
restore the previous value of autoload, irrespective of whether it was 
set or not.


I'd expect:

setenv autoload_save $autoload
setenv autoload no
dhcp
setenv autoload $autoload_save
setenv autoload_save

(or a cmdline option to "dhcp" to force it to only acquire an IP address 
would be nice too).

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

Re: [U-Boot] [PATCH v3] dm: core: Enable optional use of fdt_translate_address()

[Stephen Warren]

On 12/03/2015 07:12 AM, Stefan Roese wrote:

Hi Bin,

On 03.12.2015 14:34, Bin Meng wrote:

Hi Stefan, Simon,

On Mon, Oct 19, 2015 at 7:16 AM, Simon Glass  wrote:

On 29 September 2015 at 23:00, Stefan Roese  wrote:

The current "simple" address translation simple_bus_translate() is not
working on some platforms (e.g. MVEBU). As here more complex "ranges"
properties are used in many nodes (multiple tuples etc). This patch
enables the optional use of the common fdt_translate_address() function
which handles this translation correctly.

Signed-off-by: Stefan Roese 
Cc: Simon Glass 
Cc: Bin Meng 
Cc: Marek Vasut 
Cc: Masahiro Yamada 
Cc: Stephen Warren 
Cc: Lukasz Majewski 
---
v3:
- Rebased on current U-Boot version
- Added Stephen and Lukasz to Cc

v2:
- Rework code a bit as suggested by Simon. Also added some comments
   to make the use of the code paths more clear.

  drivers/core/Kconfig  | 30 ++
  drivers/core/device.c | 20 
  2 files changed, 50 insertions(+)


Applied to u-boot-dm, thanks!


When testing Simon's patch [1], I found PCI UART on Intel Crown Bay no
longer works. git bisect leads to this commit. Somehow I missed this
patch before although I see the commit message get me cc'ed but the
email did not bring to my attention.

I see this patch introduced OF_TRANSLATE and by default set it to y.
This makes the code logic in dev_get_addr() go through
fdt_translate_address(), which breaks the things.


I'm a bit surprised that using the common fdt_translate_address()
function instead of the DM internal simple_bus_translate() causes
problems on your platform. Are you sure that the ranges are
described correctly in your dts? Is the dts a copy from the Linux
original one? Ah, probably not, since we're talking about x86
which has no DT support in Linux, right?


Should we set
OF_TRANSLATE to n by default? If set to y, this requires dts to have
complete ranges property everywhere.


My understanding here is that x86 is a special case. As it doesn't
use the full-blown dts sources from Linux. But most likely some
"simple" ones, written exactly for U-Boot / DM.

I would still prefer to have this OF_TRANSLATE set to y as default.
As its needed for at least some platforms. But if we decide to
set it to n, I can live with it as well.


Is this the driver that uses U-Boot functions that were intended to 
parse a standard "reg" property to parse some property other than reg, 
with different semantics? Actually, I think I'm remembering an issue 
with SPI on some x86 device, but perhaps the problem here is something 
similar.

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

[U-Boot] [PATCH 1/2] sunxi: twi: enable clocks on sun7i

[Olliver Schinagl]

From: Olliver Schinagl 

Commit 6c739c5d added code to enable i2c bus 4 and 5 on the sun7i SoC
but forgot to enable the clocks for these 2 i2c busses.

This patch enables the clocks for i2c bus 4 and 5 on sun7i.

Signed-off-by: Olliver Schinagl 
---
 arch/arm/cpu/armv7/sunxi/clock_sun4i.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/cpu/armv7/sunxi/clock_sun4i.c 
b/arch/arm/cpu/armv7/sunxi/clock_sun4i.c
index 7c8eff9..ed910b1 100644
--- a/arch/arm/cpu/armv7/sunxi/clock_sun4i.c
+++ b/arch/arm/cpu/armv7/sunxi/clock_sun4i.c
@@ -67,7 +67,11 @@ int clock_twi_onoff(int port, int state)
struct sunxi_ccm_reg *const ccm =
(struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
 
+#ifdef CONFIG_MACH_SUN7I
+   if (port > 4)
+#else
if (port > 2)
+#endif
return -1;
 
/* set the apb clock gate for twi */
-- 
2.6.2

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

[U-Boot] [PATCH 2/2] spi: ti_qspi: Fix SPI_3WIRE checking using mode

[Jagan Teki]

SPI_3WIRE is spi mode not spi flags, so this patch fixed
the spi-3wire checking throgh mode instead of flags.

Cc: Mugunthan V N 
Cc: Simon Glass 
Signed-off-by: Jagan Teki 
---
 drivers/spi/ti_qspi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/spi/ti_qspi.c b/drivers/spi/ti_qspi.c
index 646dd89..5747ed1 100644
--- a/drivers/spi/ti_qspi.c
+++ b/drivers/spi/ti_qspi.c
@@ -293,7 +293,7 @@ int spi_xfer(struct spi_slave *slave, unsigned int bitlen, 
const void *dout,
qslave->cmd = 0;
qslave->cmd |= QSPI_WLEN(8);
qslave->cmd |= QSPI_EN_CS(slave->cs);
-   if (flags & SPI_3WIRE)
+   if (qslave->mode & SPI_3WIRE)
qslave->cmd |= QSPI_3_PIN;
qslave->cmd |= 0xfff;
 
-- 
1.9.1

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

Re: [U-Boot] [PATCH v7 08/34] sf: Use flash function pointers in dm_spi_flash_ops

[Jagan Teki]

Hi Simon,

On 26 November 2015 at 23:20, Simon Glass  wrote:
> Hi Jagan,
>
> On 26 November 2015 at 04:03, Jagan Teki  wrote:
>> flash operations are defined as static and reuse them
>> with function-pointers so call them with generic
>> function pounters instead of calling like normal functions.
>>
>> Signed-off-by: Jagan Teki 
>> ---
>>  drivers/mtd/spi/sf_ops.c   |  2 --
>>  drivers/mtd/spi/sf_probe.c | 15 +++
>>  include/spi_flash.h| 13 -
>>  3 files changed, 3 insertions(+), 27 deletions(-)
>>
>> diff --git a/drivers/mtd/spi/sf_ops.c b/drivers/mtd/spi/sf_ops.c
>> index 853759e..ab21f02 100644
>> --- a/drivers/mtd/spi/sf_ops.c
>> +++ b/drivers/mtd/spi/sf_ops.c
>> @@ -958,7 +958,6 @@ int spi_flash_scan(struct spi_slave *spi, struct 
>> spi_flash *flash)
>> flash->flags |= SNOR_F_SST_WR;
>>
>> /* Assign spi_flash ops */
>> -#ifndef CONFIG_DM_SPI_FLASH
>> flash->write = spi_flash_cmd_write_ops;
>>  #if defined(CONFIG_SPI_FLASH_SST)
>> if (flash->flags & SNOR_F_SST_WR) {
>> @@ -970,7 +969,6 @@ int spi_flash_scan(struct spi_slave *spi, struct 
>> spi_flash *flash)
>>  #endif
>> flash->erase = spi_flash_cmd_erase_ops;
>> flash->read = spi_flash_cmd_read_ops;
>> -#endif
>>
>> /* lock hooks are flash specific - assign them based on idcode0 */
>> switch (idcode[0]) {
>> diff --git a/drivers/mtd/spi/sf_probe.c b/drivers/mtd/spi/sf_probe.c
>> index e35b917..678b81c 100644
>> --- a/drivers/mtd/spi/sf_probe.c
>> +++ b/drivers/mtd/spi/sf_probe.c
>> @@ -120,7 +120,7 @@ static int spi_flash_std_read(struct udevice *dev, u32 
>> offset, size_t len,
>>  {
>> struct spi_flash *flash = dev_get_uclass_priv(dev);
>>
>> -   return spi_flash_cmd_read_ops(flash, offset, len, buf);
>> +   return flash->read(flash, offset, len, buf);
>>  }
>>
>>  int spi_flash_std_write(struct udevice *dev, u32 offset, size_t len,
>> @@ -128,23 +128,14 @@ int spi_flash_std_write(struct udevice *dev, u32 
>> offset, size_t len,
>>  {
>> struct spi_flash *flash = dev_get_uclass_priv(dev);
>>
>> -#if defined(CONFIG_SPI_FLASH_SST)
>> -   if (flash->flags & SNOR_F_SST_WR) {
>> -   if (flash->spi->op_mode_tx & SPI_OPM_TX_BP)
>> -   return sst_write_bp(flash, offset, len, buf);
>> -   else
>> -   return sst_write_wp(flash, offset, len, buf);
>> -   }
>> -#endif
>> -
>> -   return spi_flash_cmd_write_ops(flash, offset, len, buf);
>> +   return flash->write(flash, offset, len, buf);
>>  }
>>
>>  int spi_flash_std_erase(struct udevice *dev, u32 offset, size_t len)
>>  {
>> struct spi_flash *flash = dev_get_uclass_priv(dev);
>>
>> -   return spi_flash_cmd_erase_ops(flash, offset, len);
>> +   return flash->erase(flash, offset, len);
>>  }
>>
>>  int spi_flash_std_probe(struct udevice *dev)
>> diff --git a/include/spi_flash.h b/include/spi_flash.h
>> index f25b3e7..721b358 100644
>> --- a/include/spi_flash.h
>> +++ b/include/spi_flash.h
>> @@ -94,23 +94,10 @@ struct spi_flash {
>> int (*flash_lock)(struct spi_flash *flash, u32 ofs, size_t len);
>> int (*flash_unlock)(struct spi_flash *flash, u32 ofs, size_t len);
>> int (*flash_is_locked)(struct spi_flash *flash, u32 ofs, size_t len);
>> -#ifndef CONFIG_DM_SPI_FLASH
>> -   /*
>> -* These are not strictly needed for driver model, but keep them here
>> -* while the transition is in progress.
>> -*
>> -* Normally each driver would provide its own operations, but for
>> -* SPI flash most chips use the same algorithms. One approach is
>> -* to create a 'common' SPI flash device which knows how to talk
>> -* to most devices, and then allow other drivers to be used instead
>> -* if required, perhaps with a way of scanning through the list to
>> -* find the driver that matches the device.
>> -*/
>> int (*read)(struct spi_flash *flash, u32 offset, size_t len, void 
>> *buf);
>> int (*write)(struct spi_flash *flash, u32 offset, size_t len,
>> const void *buf);
>> int (*erase)(struct spi_flash *flash, u32 offset, size_t len);
>> -#endif
>
> No this should go the other way. The flash_...() methods introduced
> above should be removed with driver model.

The lock methods above flash_..() are common to both dm and non-dm
there is no separate lock ops for dm now.

>
> If we don't move things forward towards driver model for all platforms
> we are going to create a fork.
>
>>  };
>>
>>  struct dm_spi_flash_ops {
>> --

thanks!
-- 
Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 03/14] net: gem: Do not continue if phy is not found

[Jagan Teki]

On 3 December 2015 at 20:17, Michal Simek  wrote:
> Add return value for phy detection algorithm to stop init function when
> phy is not found.
>
> Signed-off-by: Michal Simek 
> ---

Reviewed-by: Jagan Teki 

thanks!
-- 
Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 11/14] net: gem: Fix miiphy_read name

[Jagan Teki]

On 3 December 2015 at 20:17, Michal Simek  wrote:
> Sync it with write function.
>
> Signed-off-by: Michal Simek 
> ---

Reviewed-by: Jagan Teki 

thanks!
-- 
Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v5] arm: Add sata support on Layerscape ARMv8 board

[York Sun]

On 12/01/2015 07:27 PM, yuantian.t...@freescale.com wrote:
> From: Tang Yuantian 
> 
> Freescale ARM-based Layerscape contains a SATA controller
> which comply with the serial ATA 3.0 specification and the
> AHCI 1.3 specification.
> This patch adds SATA feature on ls2080aqds, ls2080ardb and
> ls1043aqds boards.
> 
> Signed-off-by: Tang Yuantian 
> ---
> v5:
>   - re-organize the code
> v4:
>   - rebase to lastest git tree
>   - add another ARMv8 platform which is ls1043aqds
> v3:
>   - rename ls2085a to ls2080a
>   - rebase to the latest git tree
>   - replace the magic number with micro variable
> v2:
>   - rebase to the latest git tree
> 
>  arch/arm/cpu/armv8/fsl-layerscape/soc.c| 43 
> ++
>  .../include/asm/arch-fsl-layerscape/immap_lsch3.h  |  4 ++
>  arch/arm/include/asm/arch-fsl-layerscape/soc.h | 31 
>  include/configs/ls1043aqds.h   | 17 +
>  include/configs/ls2080aqds.h   | 18 +
>  include/configs/ls2080ardb.h   | 18 +
>  6 files changed, 131 insertions(+)
> 
> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/soc.c 
> b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> index 8896b70..574ffc4 100644
> --- a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> +++ b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> @@ -6,6 +6,8 @@
>  
>  #include 
>  #include 
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -120,7 +122,44 @@ void fsl_lsch3_early_init_f(void)
>   erratum_a009203();
>  }
>  

Yuantian,

Please help me understand below.

> +#ifdef CONFIG_SCSI_AHCI_PLAT
> +int sata_init(void)
> +{
> + struct ccsr_ahci __iomem *ccsr_ahci;
> +
> + ccsr_ahci  = (void *)CONFIG_SYS_SATA2;
> + out_le32(_ahci->ppcfg, AHCI_PORT_PHY_1_CFG);
> + out_le32(_ahci->ptc, AHCI_PORT_TRANS_CFG);

You didn't set pp2c or pp3c. Is it because the default values are OK or
something else?

> +
> + ccsr_ahci  = (void *)CONFIG_SYS_SATA1;
> + out_le32(_ahci->ppcfg, AHCI_PORT_PHY_1_CFG);
> + out_le32(_ahci->ptc, AHCI_PORT_TRANS_CFG);
> +
> + ahci_init((void __iomem *)CONFIG_SYS_SATA1);

You only call ahci_init() here but not above. Is SATA2 active?


> + scsi_scan(0);
> +
> + return 0;
> +}
> +#endif
> +
>  #elif defined(CONFIG_LS1043A)
> +#ifdef CONFIG_SCSI_AHCI_PLAT
> +int sata_init(void)
> +{
> + struct ccsr_ahci __iomem *ccsr_ahci = (void *)CONFIG_SYS_SATA;
> +
> + out_le32(_ahci->ppcfg, AHCI_PORT_PHY_1_CFG);
> + out_le32(_ahci->pp2c, AHCI_PORT_PHY_2_CFG);
> + out_le32(_ahci->pp3c, AHCI_PORT_PHY_3_CFG);
> + out_le32(_ahci->ptc, AHCI_PORT_TRANS_CFG);
> +
> + ahci_init((void __iomem *)CONFIG_SYS_SATA);
> + scsi_scan(0);
> +
> + return 0;
> +}
> +#endif
> +

York

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

[U-Boot] [PATCH 1/2] spi: Get spi-3wire from dts

[Jagan Teki]

spi-3wire is used when SI/SO signals shared so get
the same from dts node and assign to mode on slave
plat->mode.

Cc: Simon Glass 
Signed-off-by: Jagan Teki 
---
 drivers/spi/spi-uclass.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/spi/spi-uclass.c b/drivers/spi/spi-uclass.c
index 3c7d64a..e0f6b25 100644
--- a/drivers/spi/spi-uclass.c
+++ b/drivers/spi/spi-uclass.c
@@ -378,6 +378,8 @@ int spi_slave_ofdata_to_platdata(const void *blob, int node,
mode |= SPI_CPHA;
if (fdtdec_get_bool(blob, node, "spi-cs-high"))
mode |= SPI_CS_HIGH;
+   if (fdtdec_get_bool(blob, node, "spi-3wire"))
+   mode |= SPI_3WIRE;
if (fdtdec_get_bool(blob, node, "spi-half-duplex"))
mode |= SPI_PREAMBLE;
plat->mode = mode;
-- 
1.9.1

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

Re: [U-Boot] [PATCH v3 08/14] net: gem: Check if priv->phydev is valid

[Jagan Teki]

On 3 December 2015 at 20:17, Michal Simek  wrote:
> Check return value.
>
> Signed-off-by: Michal Simek 
> ---

Reviewed-by: Jagan Teki 

thanks!
-- 
Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 0/2] arm: sunxi: twi: enable clock for sun7i

[Olliver Schinagl]

From: Olliver Schinagl 

Paul enabled all I2C ports for sunxi but forgot the clock on twi 4 and 5 for 
sun7i.

And a small non code changing whitespace fix

Tested on Olimex Lime2

Olliver Schinagl (2):
  sunxi: twi: enable clocks on sun7i
  sun4i: clock: cleanup some whitespace errors

 arch/arm/cpu/armv7/sunxi/clock_sun4i.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

-- 
2.6.2

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

[U-Boot] [PATCH 2/2] sun4i: clock: cleanup some whitespace errors

[Olliver Schinagl]

From: Olliver Schinagl 

Add some spaces around operators.

Signed-off-by: Olliver Schinagl 
---
 arch/arm/cpu/armv7/sunxi/clock_sun4i.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/cpu/armv7/sunxi/clock_sun4i.c 
b/arch/arm/cpu/armv7/sunxi/clock_sun4i.c
index ed910b1..866b2d6 100644
--- a/arch/arm/cpu/armv7/sunxi/clock_sun4i.c
+++ b/arch/arm/cpu/armv7/sunxi/clock_sun4i.c
@@ -59,7 +59,7 @@ void clock_init_uart(void)
 
/* open the clock for uart */
setbits_le32(>apb1_gate,
-   CLK_GATE_OPEN << (APB1_GATE_UART_SHIFT+CONFIG_CONS_INDEX-1));
+   CLK_GATE_OPEN << (APB1_GATE_UART_SHIFT+CONFIG_CONS_INDEX - 1));
 }
 
 int clock_twi_onoff(int port, int state)
@@ -77,10 +77,10 @@ int clock_twi_onoff(int port, int state)
/* set the apb clock gate for twi */
if (state)
setbits_le32(>apb1_gate,
-CLK_GATE_OPEN << (APB1_GATE_TWI_SHIFT+port));
+CLK_GATE_OPEN << (APB1_GATE_TWI_SHIFT + port));
else
clrbits_le32(>apb1_gate,
-CLK_GATE_OPEN << (APB1_GATE_TWI_SHIFT+port));
+CLK_GATE_OPEN << (APB1_GATE_TWI_SHIFT + port));
 
return 0;
 }
-- 
2.6.2

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

Re: [U-Boot] [PATCH] dm: core: Add platform specific bus translation function

[Simon Glass]

Hi Stefan,

On 3 December 2015 at 04:31, Stefan Roese  wrote:
>
> Hi Simon,
>
> On 02.12.2015 18:45, Simon Glass wrote:
> > Hi Stefan,
> >
> > On 2 December 2015 at 10:43, Stefan Roese  wrote:
> >> Hi Simon,
> >>
> >> ( Last mail for tonight - a glass of quite nice red wine is
> >> waiting for me ... ;) )
> >>
> >
> > That's the only sad thing about me being so many hours behind. Still I
> > can do the same thing with people in Asia I suppose :-)
>
> Right. I'm not sure about the wine quality in Asia though... ;)
>
> >>
> >> On 02.12.2015 17:53, Simon Glass wrote:
> >>>
> >>> Hi Stefan,
> >>>
> >>> On 2 December 2015 at 09:00, Stefan Roese  wrote:
> 
> 
>  Hi Simon,
> 
>  On 02.12.2015 16:50, Simon Glass wrote:
> 
>  
> 
> >>> I think it would be better to make it depend on whether the bit is
> >>> flipped, rather than whether you are in SPL or not.
> >>
> >>
> >>
> >> You simply can't detect if this "bit is flipped". You just have
> >> to know. This is a long lasting ugly thing on some Marvell
> >> patforms. Here the comment from armada-xp-gp.dts:
> >
> >
> >
> > Can you point me to the place in U-Boot where this bit is flipped?
> > Something, somewhere has to make the change. So something has to know.
> > Before it makes the change, the range works one way. Afterwards it
> > works another way.
> 
> 
> 
>  Sure. I've mentioned this before. Its here:
> 
>  arch/arm/mach-mvebu/cpu.c:
> 
>  int arch_cpu_init(void)
>  {
>    ...
> 
>    /* Linux expects the internal registers to be at 0xf100 */
>    writel(SOC_REGS_PHY_BASE, INTREG_BASE_ADDR_REG);
> 
>  This is the line that changes the register base address. And
>  to change it back you need to write to the new address, as the
>  address holding this base address is also moved. Quite ugly!
> 
>  So its really right at the start of U-Boot proper.
> >>>
> >>>
> >>> OK I see. So really we can determine which way the address 'switch'
> >>> it. It's just a case of making the change when we are ready, and
> >>> keeping a record of that.
> >>
> >>
> >> Yes. But how is the "common code" in dev_get_addr() supposed to know
> >> which version of U-Boot we are running on? This boils down to some
> >> callback again, or not? Or even worse the ugly #ifdef.
> >
> > You would call a driver-model core function to select the ranges
> > property to prefer. Then driver model will remember this setting and
> > use it.
>
> Yes. This can be done. I've taken the time to implement such a
> version. And attached a small patch in a hackish version, just as
> an RFC. As you will see, I've added the "ranges-spl" property to
> some of the DT nodes. And added the DM core functions to enable to
> usage of a different, non-standard "ranges" property name.
>
> All this is not really "clean" and will definitely break non-DM
> usage of fdt_support.c. Not sure where to go from here. I would
> still prefer my first patch version, even though I know that
> you don't like to add this hook / callback into the DM core code.
>
> Let me know what you think.

Actually that looks pretty good to me. I think the root uclass needs
to grow a private struct, where you store the ranges name. It is
slightly odd to have fdtdec calling back into DM, but I don't see a
big problem with it. The two are strongly coupled anyway. You can put
an #ifdef CONFIG_DM in fdtdec to solve your problem I suppose.

What about the device tree mailing list. Should I send an email there?

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

Re: [U-Boot] [PATCH v3 10/16] drivers: mtd: spi: sf_probe: add compatible for spansion spi flash

[Jagan Teki]

Hi Mugunthan,

On 23 November 2015 at 18:42, Jagan Teki  wrote:
> On 23 November 2015 at 16:59, Mugunthan V N  wrote:
>> On Friday 20 November 2015 05:57 PM, Jagan Teki wrote:
>>> On 20 November 2015 at 11:31, Mugunthan V N  wrote:
 Jagan

 On Thursday 19 November 2015 03:40 PM, Jagan Teki wrote:
> On 19 November 2015 at 12:35, Mugunthan V N  wrote:
>> Add compatible for spansion 32MiB spi flash s25fl256s1.
>>
>> Signed-off-by: Mugunthan V N 
>> ---
>>  drivers/mtd/spi/sf_probe.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/mtd/spi/sf_probe.c b/drivers/mtd/spi/sf_probe.c
>> index bc05d30..ffbce59 100644
>> --- a/drivers/mtd/spi/sf_probe.c
>> +++ b/drivers/mtd/spi/sf_probe.c
>> @@ -515,6 +515,7 @@ static const struct dm_spi_flash_ops 
>> spi_flash_std_ops = {
>>
>>  static const struct udevice_id spi_flash_std_ids[] = {
>> { .compatible = "spi-flash" },
>> +   { .compatible = "s25fl256s1" },
>> { }
>
> Never compare with spi-flash vs s25fl256s1 here former is driver
> compatible string and later one is probed flash string name. we don't
> need to add them in compatible list, better to add it on dts node
> otherwise no issue the connected flash will detect while 'sf probe'
>

 I agree that spi flash will be probed even without addition of compatibles.

 If there is no matching compatible between the dtb and driver,  the dt
 properties like spi-max-frequency, spi clock phase/polarity and spi
 bus-width are not parsed from DT as the of_offset of the spi device will
 be '-1'. This check and dt parse is done in spi_child_post_bind() in
 spi-uclass driver.

 Since spi bus-width is not read from DT, by default spi transfers are
 done in one wire mode and read throughput drops to 5.3Mbps. With Quad
 mode read throughput is 16.6Mbps in DRA74x EVM.

>>>
>>> Why can't we try something like this [1] [2] I do agree with
>>> documentation missing, may be we add add that well.
>>>
>>> [1] arch/arm/dts/socfpga_cyclone5_sockit.dts
>>
>> This dts file is not in sync with kernel dts. There is no qspi support
>> in kernel. It is going to be really tough time to sync this dts between
>> kernel and u-boot ;)
>
> Since we are in starting point of adding dts files (unlike Linux)
> these dts files may not sync with Linux, we started adding these to
> make dm or related drivers need to work. Yes I agreed with your point
> and we really need to work on that as well.
>
>>
>>> [2] arch/arm/dts/zynqmp-ep108.dts
>>
>> I don't see compatible string "spi-flash" in zynqmp-ep108.dts
>
> Yes, cant you add "s25fl256s1" like n25q512a11 added in this dts.
>
>>
>> Adding spi-flash compatible will be tough as spi-flash works with the
>> existing compatibles and convincing spi maintainer (Mark Brown) for
>> adding a generic compatible will be difficult.
>
> This is what you pointed out - id_table.
>
> static struct spi_driver m25p80_driver = {
> .driver = {
> .name   = "m25p80",
> .of_match_table = m25p_of_table,
> },
> .id_table   = m25p_ids,
>

Comments?

>
>>
>> If you still insist to add spi-flash compatible to the dts file and *Tom
>> Rini* is also fine, I will re-spin the series with compatible changes to
>> the dts files.
>
> I'm saying like s25fl256s1 few of compatible strings were added
> already on existing dts files, probably we may proceed with the same
> for now. will trimming up later.

Any comments? proceed with above suggestion.

thanks!
-- 
Jagan | openedev.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 05/16] spi: Add support for dual and quad mode

[Jagan Teki]

On 19 November 2015 at 12:35, Mugunthan V N  wrote:
> spi bus can support dual and quad wire data transfers for tx and
> rx. So defining dual and quad modes for both tx and rx. Also add
> support to parse bus width used for spi tx and rx transfers.
>
> Signed-off-by: Mugunthan V N 
> Reviewed-by: Simon Glass 
> Reviewed-by: Tom Rini 
> ---
>  drivers/spi/spi-uclass.c | 33 +
>  include/spi.h|  4 
>  2 files changed, 37 insertions(+)
>
> diff --git a/drivers/spi/spi-uclass.c b/drivers/spi/spi-uclass.c
> index 58388ef..62d8da7 100644
> --- a/drivers/spi/spi-uclass.c
> +++ b/drivers/spi/spi-uclass.c
> @@ -349,6 +349,7 @@ int spi_slave_ofdata_to_platdata(const void *blob, int 
> node,
>  struct dm_spi_slave_platdata *plat)
>  {
> int mode = 0;
> +   int value;
>
> plat->cs = fdtdec_get_int(blob, node, "reg", -1);
> plat->max_hz = fdtdec_get_int(blob, node, "spi-max-frequency", 0);
> @@ -360,6 +361,38 @@ int spi_slave_ofdata_to_platdata(const void *blob, int 
> node,
> mode |= SPI_CS_HIGH;
> if (fdtdec_get_bool(blob, node, "spi-half-duplex"))
> mode |= SPI_PREAMBLE;
> +
> +   /* Device DUAL/QUAD mode */
> +   value = fdtdec_get_uint(blob, node, "spi-tx-bus-width", 1);
> +   switch (value) {
> +   case 1:
> +   break;
> +   case 2:
> +   mode |= SPI_TX_DUAL;
> +   break;
> +   case 4:
> +   mode |= SPI_TX_QUAD;
> +   break;
> +   default:
> +   error("spi-tx-bus-width %d not supported\n", value);
> +   break;
> +   }
> +
> +   value = fdtdec_get_uint(blob, node, "spi-rx-bus-width", 1);
> +   switch (value) {
> +   case 1:
> +   break;
> +   case 2:
> +   mode |= SPI_RX_DUAL;
> +   break;
> +   case 4:
> +   mode |= SPI_RX_QUAD;
> +   break;
> +   default:
> +   error("spi-rx-bus-width %d not supported\n", value);
> +   break;
> +   }
> +

I think these are similar to SPI TX/RX operation modes in spi.h and I
understand this is similar approach as with Linux but before this we
need to do many changes on u-boot as well.

> plat->mode = mode;
>
> return 0;
> diff --git a/include/spi.h b/include/spi.h
> index b4d2723..40dbb4d 100644
> --- a/include/spi.h
> +++ b/include/spi.h
> @@ -23,6 +23,10 @@
>  #defineSPI_LOOP0x20/* loopback mode */
>  #defineSPI_SLAVE   0x40/* slave mode */
>  #defineSPI_PREAMBLE0x80/* Skip preamble 
> bytes */
> +#defineSPI_TX_DUAL 0x100   /* transmit with 2 
> wires */
> +#defineSPI_TX_QUAD 0x200   /* transmit with 4 
> wires */
> +#defineSPI_RX_DUAL 0x400   /* receive with 2 
> wires */
> +#defineSPI_RX_QUAD 0x800   /* receive with 4 
> wires */
>
>  /* SPI transfer flags */
>  #define SPI_XFER_BEGIN 0x01/* Assert CS before transfer */
> --
> 2.6.2.280.g74301d6
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot



-- 
Jagan | openedev.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v3 09/14] net: gem: Enable MDIO bus earlier

[Michal Simek]

Enable access to MDIO before zynq_gem_init is called.
It enables read information about phy earlier.

Signed-off-by: Michal Simek 
---

Changes in v3: None
Changes in v2: None

 drivers/net/zynq_gem.c | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/net/zynq_gem.c b/drivers/net/zynq_gem.c
index d5540ec2155c..9ce1221e8d0f 100644
--- a/drivers/net/zynq_gem.c
+++ b/drivers/net/zynq_gem.c
@@ -314,6 +314,7 @@ static int zynq_phy_init(struct eth_device *dev)
 {
int ret;
struct zynq_gem_priv *priv = dev->priv;
+   struct zynq_gem_regs *regs = (struct zynq_gem_regs *)dev->iobase;
const u32 supported = SUPPORTED_10baseT_Half |
SUPPORTED_10baseT_Full |
SUPPORTED_100baseT_Half |
@@ -321,6 +322,9 @@ static int zynq_phy_init(struct eth_device *dev)
SUPPORTED_1000baseT_Half |
SUPPORTED_1000baseT_Full;
 
+   /* Enable only MDIO bus */
+   writel(ZYNQ_GEM_NWCTRL_MDEN_MASK, >nwctrl);
+
ret = phy_detection(dev);
if (ret) {
printf("GEM PHY init failed\n");
@@ -343,7 +347,6 @@ static int zynq_phy_init(struct eth_device *dev)
 static int zynq_gem_init(struct eth_device *dev, bd_t *bis)
 {
u32 i;
-   int ret;
unsigned long clk_rate = 0;
struct zynq_gem_regs *regs = (struct zynq_gem_regs *)dev->iobase;
struct zynq_gem_priv *priv = dev->priv;
@@ -411,10 +414,6 @@ static int zynq_gem_init(struct eth_device *dev, bd_t *bis)
priv->init++;
}
 
-   ret = zynq_phy_init(dev);
-   if (ret)
-   return ret;
-
phy_startup(priv->phydev);
 
if (!priv->phydev->link) {
@@ -597,6 +596,7 @@ static int zynq_gem_miiphy_write(const char *devname, uchar 
addr,
 int zynq_gem_initialize(bd_t *bis, phys_addr_t base_addr,
int phy_addr, u32 emio)
 {
+   int ret;
struct eth_device *dev;
struct zynq_gem_priv *priv;
void *bd_space;
@@ -650,6 +650,10 @@ int zynq_gem_initialize(bd_t *bis, phys_addr_t base_addr,
miiphy_register(dev->name, zynq_gem_miiphyread, zynq_gem_miiphy_write);
priv->bus = miiphy_get_dev_by_name(dev->name);
 
+   ret = zynq_phy_init(dev);
+   if (ret)
+   return ret;
+
return 1;
 }
 
-- 
1.9.1

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

Re: [U-Boot] [PATCH 1/1] fsl_qspi: Pet the watchdog while reading/writing

[Alexander Stein]

Hi,

On Thursday 03 December 2015 09:49:40, Huan Wang wrote:
> [Alison Wang] I could not reproduce the issue. Maybe I don't have the
> external watchdog which will reset after ~1.5s as Alexander mentioned.

Could you try to set the internal watchdog to 1s timeout? This should be more 
or less the same scenario.

Best regards,
Alexander
-- 
Dipl.-Inf. Alexander Stein
SYS TEC electronic GmbH
alexander.st...@systec-electronic.com

Legal and Commercial Address:
Am Windrad 2
08468 Heinsdorfergrund
Germany

Office: +49 (0) 3765 38600-0
Fax:+49 (0) 3765 38600-4100
 
Managing Directors:
Director Technology/CEO: Dipl.-Phys. Siegmar Schmidt;
Director Commercial Affairs/COO: Dipl. Ing. (FH) Armin von Collrepp
Commercial Registry:
Amtsgericht Chemnitz, HRB 28082; USt.-Id Nr. DE150534010

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

Re: [U-Boot] [PATCH v3 12/14] net: gem: Move driver to DM

[Jagan Teki]

On 3 December 2015 at 20:18, Michal Simek  wrote:
> - Enable DM_ETH by default for Zynq and ZynqMP
> - Remove board_eth_init code
> - Change miiphy_read function to return value instead of error code
>   based on DM requirement
> - Do not enable EMIO DT support by default
>
> Signed-off-by: Michal Simek 
> ---

Reviewed-by: Jagan Teki 

thanks!
-- 
Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: socfpga: Fix cache configuration

[Marek Vasut]

On Thursday, December 03, 2015 at 05:11:23 PM, Chin Liang See wrote:

[...]

> > I have another board where I cannot use UBI on QSPI NOR and reverting
> > this
> > patch magically fixes things.
> 
> I was testing this too as enabling the UBIFS on NOR and here are my
> output. Wonder how to simulate your errors as I can help to take a
> look?
> 
> 
> => icache
> Instruction Cache is ON
> => dcache
> Data (writethrough) Cache is ON
> => sf probe
> SF: Detected N25Q512 with page size 256 Bytes, erase size 4 KiB, total
> 64 MiB
> => mtdparts default
> => mtdparts
> 
> device nor0 , # parts = 4
> #: namesizeoffset  mask_flags
> 0: u-boot  0x0010  0x  0
> 1: uboot-env   0x0001  0x0010  0
> 2: rootfs  0x0100  0x0011  0
> 3: UBI 0x02ef  0x0111  0
> 
> active partition: nor0,0 - (u-boot) 0x0010 @ 0x
> 
> defaults:
> mtdids  : nor0=ff705000.spi
> mtdparts: mtdparts=ff705000.spi:1m(u-boot),64k(uboot-env),16m(rootfs),
> -(UBI)
> => sf erase u-boot 10
> SF: 1048576 bytes @ 0x0 Erased: OK
> => ubi part u-boot
> ubi0: attaching mtd1
> ubi0: scanning is finished
> ubi0: empty MTD device detected
> ubi0: attached mtd1 (name "mtd=0", size 1 MiB)
> ubi0: PEB size: 4096 bytes (4 KiB), LEB size: 3968 bytes
> ubi0: min./max. I/O unit sizes: 1/256, sub-page size 1
> ubi0: VID header offset: 64 (aligned 64), data offset: 128
> ubi0: good PEBs: 256, bad PEBs: 0, corrupted PEBs: 0
> ubi0: user volume: 0, internal volumes: 1, max. volumes count: 23
> ubi0: max/mean erase counter: 1/0, WL threshold: 4096, image sequence
> number: 0
> ubi0: available PEBs: 252, total reserved PEBs: 4, PEBs reserved for
> bad PEB handling: 0
> => ubi createvol testvol c
> Creating dynamic volume testvol of size 786432
> => ubi write 0 testvol 100
> 256 bytes written to volume testvol
> => ubi read 200 testvol 100
> Read 256 bytes from volume testvol to 200
> => cmp.b 0 200 100
> Total of 256 byte(s) were the same
> => ubifsmount testvol
> Error reading superblock on volume 'testvol' errno=-22!
> ubifsmount - mount UBIFS volume
> 
> Usage:
> ubifsmount 
> - mount 'volume-name' volume
> => ubifsmount ubi0:testvol
> Error reading superblock on volume 'ubi0:testvol' errno=-22!
> ubifsmount - mount UBIFS volume
> 
> Usage:
> ubifsmount 
> - mount 'volume-name' volume
> 
> 
> In the mean time, I was not able to get ubifsmount works. Appreciate
> for any quick advise? Else will look into the code tomorrow as my bed
> is calling me :)

I usually write ubinized image into the "rootfs" partition (sf erase and
then sf write) and then do 'ubi part rootfs' , which fails with error 22
unless I revert this patch. If I dump the SPI NOR area after writing the
data, I see that the last 2 bytes of some pages are corrupted.

I am using these parameters to generate my ~11MiB large ubinized image:
MKFS_UBIFS_OPTS="-m 1 -e 65408 -c 200"
UBINIZE_OPTS="-m 1 -p 64KiB -s 1"

Here is the content of my ubinize.cfg:
[rootfs]
mode=ubi
image=root.ubifs
vol_id=0
vol_type=dynamic
vol_name=rootfs
vol_flags=autoresize
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: socfpga: Fix cache configuration

[Chin Liang See]

On Thu, 2015-12-03 at 01:10 +0100, Marek Vasut wrote:
> On Thursday, November 12, 2015 at 03:33:42 AM, Chin Liang See wrote:
> > On Thu, 2015-11-12 at 01:53 +0100, Marek Vasut wrote:
> > > On Thursday, November 12, 2015 at 01:49:09 AM, Chin Liang See
> > > wrote:
> > > > Hi Marek,
> > > > 
> > > > On Mon, 2015-11-09 at 17:02 +0100, Marek Vasut wrote:
> > > > > On Monday, November 09, 2015 at 04:46:54 PM, Stefan Roese
> > > > > wrote:
> > > > > > Hi Marek,
> > > > > 
> > > > > Hi!
> > > > > 
> > > > > > On 09.11.2015 14:49, Marek Vasut wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > > > > > --- a/include/configs/socfpga_common.h
> > > > > > > > > > +++ b/include/configs/socfpga_common.h
> > > > > > > > > > @@ -73,7 +73,6 @@
> > > > > > > > > > 
> > > > > > > > > >/*
> > > > > > > > > >
> > > > > > > > > > * Cache
> > > > > > > > > > */
> > > > > > > > > > 
> > > > > > > > > > -#define CONFIG_SYS_ARM_CACHE_WRITEALLOC
> > > > > > > > > > 
> > > > > > > > > >#define CONFIG_SYS_CACHELINE_SIZE 32
> > > > > > > > > >#define CONFIG_SYS_L2_PL310
> > > > > > > > > >#define CONFIG_SYS_PL310_BASE
> SOCFPGA_MPUL2_ADDRESS
> > > > > > > > > 
> > > > > > > > > I hate to say it, but I am running into issues with
> > > > > > > > > this patch
> > > > > > > > > :-(
> > > > > > > > 
> > > > > > > > I'm sorry to hear this.
> > > > > > > > 
> > > > > > > > > I use a standard USB stick here and with this patch,
> > > > > > > > > I am
> > > > > > > > > getting the following failure (with enabled and
> > > > > > > > > disabled
> > > > > > > > > cache):
> > > > > > > > > 
> > > > > > > > > => usb reset
> > > > > > > > > resetting USB...
> > > > > > > > > USB0:   Core Release: 2.93a
> > > > > > > > > scanning bus 0 for devices... unable to get
> > > > > > > > > descriptor, error 0
> > > > > > > > > usb_new_device: Cannot read configuration, skipping
> > > > > > > > > device
> > > > > > > > > 058f:6387 1 USB Device(s) found
> > > > > > > > > 
> > > > > > > > >  scanning usb for storage devices... 0
> > > > > > > > > Storage
> > > > > > > > >  Device(s) found
> > > > > > > > > 
> > > > > > > > > => dcache off
> > > > > > > > > => usb reset
> > > > > > > > > resetting USB...
> > > > > > > > > USB0:   Core Release: 2.93a
> > > > > > > > > scanning bus 0 for devices... 2 USB Device(s) found
> > > > > > > > > 
> > > > > > > > >  scanning usb for storage devices... 1
> > > > > > > > > Storage
> > > > > > > > >  Device(s) found
> > > > > > > > > 
> > > > > > > > > If I revert this patch, my USB stick works as well.
> > > > > > > > > 
> > > > > > > > > I am also aware that Stefan mentions that without
> > > > > > > > > this patch,
> > > > > > > > > cache is not enabled at all. On the other hand, I
> > > > > > > > > cannot find
> > > > > > > > > any obviously faulty behavior in the dwc2 driver, it
> > > > > > > > > does
> > > > > > > > > flush_dcache_range()/invalidate_dcache_range() in the
> > > > > > > > > right
> > > > > > > > > places.
> > > > > > > > > 
> > > > > > > > > Any ideas please ?
> > > > > > > > 
> > > > > > > > Perhaps its a timing related issue? As the code is
> > > > > > > > executed
> > > > > > > > faster with cache enabled. Just an idea - perhaps there
> > > > > > > > is
> > > > > > > > still some ugly code that doesn't do proper timer based
> > > > > > > > loops /
> > > > > > > > delays.
> > > > > > > 
> > > > > > > I doubt that's not the case. If I disable cache just
> > > > > > > around the
> > > > > > > hcdma bit in the driver (disable before the
> > > > > > > flush_dcache_range()
> > > > > > > and enable after invalidate_dcache_range() in the
> > > > > > > driver), it
> > > > > > > still fails.
> > > > > > 
> > > > > > Did you check if this problem is perhaps also related to
> > > > > > Dinh's L2
> > > > > > cache patch:
> > > > > > 
> > > > > > 8d8e13e1 arm: socfpga: enable data/inst prefetch and shared
> > > > > > override in the L2
> > > > > > 
> > > > > > ?
> > > > > 
> > > > > Yes I did, but reverting this patch had no impact.
> > > > > 
> > > > > > I just noticed, that here the L2 cache gets disabled and is
> > > > > > not
> > > > > > enabled again in function v7_outer_cache_enable(). This
> > > > > > looks a
> > > > > > bit suspicious.
> > > > > > 
> > > > > > Dinh, did you perhaps miss to re-enable the L2 cache after
> > > > > > the
> > > > > > aux_ctrl register setup again?
> > > > > 
> > > > > I guess we should pester Dinh now :-)
> > > > 
> > > > I recompiled the latest source and it works for me.
> > > > Here is the printout message.
> > > > Wonder any modification against commit a55f28624e97e1e43ac?
> > > > 
> > > > 
> > > > U-Boot 2015.10-08073-ga55f286 (Nov 11 2015 - 23:19:06 +0800)
> > > > 
> > > > CPU:   Altera SoCFPGA Platform
> > > > FPGA:  Altera Cyclone V, SE/A6 or SX/C6 or ST/D6, version 0x0
> > > > BOOT:  SD/MMC External Transceiver (1.8V)
> > > > 
> > > >Watchdog enabled
> > > > 
> > > > I2C:   ready
> > > 

Re: [U-Boot] [PATCH v3 01/14] ARM: zynq: Remove PHYLIB from config to defconfig

[Jagan Teki]

On 3 December 2015 at 20:17, Michal Simek  wrote:
> Move PHYLIB from board config to defconfig
>
> Signed-off-by: Michal Simek 
> ---

Reviewed-by: Jagan Teki 

thanks!
-- 
Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 14/14] net: gem: Move gem to Kconfig

[Jagan Teki]

On 3 December 2015 at 20:18, Michal Simek  wrote:
> Signed-off-by: Michal Simek 
> ---

Reviewed-by: Jagan Teki 

>
> Changes in v3: None
> Changes in v2: None
>
>  configs/xilinx_zynqmp_ep_defconfig | 1 +
>  configs/zynq_microzed_defconfig| 1 +
>  configs/zynq_picozed_defconfig | 1 +
>  configs/zynq_zc702_defconfig   | 1 +
>  configs/zynq_zc706_defconfig   | 1 +
>  configs/zynq_zc770_xm010_defconfig | 1 +
>  configs/zynq_zc770_xm011_defconfig | 1 +
>  configs/zynq_zc770_xm012_defconfig | 1 +
>  configs/zynq_zc770_xm013_defconfig | 1 +
>  configs/zynq_zed_defconfig | 1 +
>  configs/zynq_zybo_defconfig| 1 +
>  drivers/net/Kconfig| 6 ++
>  include/configs/xilinx_zynqmp.h| 4 +---
>  include/configs/xilinx_zynqmp_ep.h | 3 ---
>  include/configs/zynq-common.h  | 3 +--
>  include/configs/zynq_microzed.h| 3 ---
>  include/configs/zynq_picozed.h | 3 ---
>  include/configs/zynq_zc70x.h   | 3 ---
>  include/configs/zynq_zc770.h   | 4 
>  include/configs/zynq_zed.h | 3 ---
>  include/configs/zynq_zybo.h| 3 ---
>  21 files changed, 19 insertions(+), 27 deletions(-)
>
> diff --git a/configs/xilinx_zynqmp_ep_defconfig 
> b/configs/xilinx_zynqmp_ep_defconfig
> index 79304c1fb121..22915f19bfbb 100644
> --- a/configs/xilinx_zynqmp_ep_defconfig
> +++ b/configs/xilinx_zynqmp_ep_defconfig
> @@ -22,4 +22,5 @@ CONFIG_CMD_TIME=y
>  CONFIG_CMD_TIMER=y
>  CONFIG_OF_EMBED=y
>  CONFIG_NET_RANDOM_ETHADDR=y
> +CONFIG_ZYNQ_GEM=y
>  # CONFIG_REGEX is not set
> diff --git a/configs/zynq_microzed_defconfig b/configs/zynq_microzed_defconfig
> index 0608d8a733cf..c68efc8f41af 100644
> --- a/configs/zynq_microzed_defconfig
> +++ b/configs/zynq_microzed_defconfig
> @@ -16,4 +16,5 @@ CONFIG_SPI_FLASH_SPANSION=y
>  CONFIG_SPI_FLASH_STMICRO=y
>  CONFIG_SPI_FLASH_WINBOND=y
>  CONFIG_PHYLIB=y
> +CONFIG_ZYNQ_GEM=y
>  CONFIG_ZYNQ_QSPI=y
> diff --git a/configs/zynq_picozed_defconfig b/configs/zynq_picozed_defconfig
> index d6f0ce388832..62eb79f630e3 100644
> --- a/configs/zynq_picozed_defconfig
> +++ b/configs/zynq_picozed_defconfig
> @@ -9,3 +9,4 @@ CONFIG_CMD_GPIO=y
>  # CONFIG_CMD_SETEXPR is not set
>  CONFIG_NET_RANDOM_ETHADDR=y
>  CONFIG_PHYLIB=y
> +CONFIG_ZYNQ_GEM=y
> diff --git a/configs/zynq_zc702_defconfig b/configs/zynq_zc702_defconfig
> index 8318b94ecbb2..dd588aff72db 100644
> --- a/configs/zynq_zc702_defconfig
> +++ b/configs/zynq_zc702_defconfig
> @@ -15,4 +15,5 @@ CONFIG_SPI_FLASH_SPANSION=y
>  CONFIG_SPI_FLASH_STMICRO=y
>  CONFIG_SPI_FLASH_WINBOND=y
>  CONFIG_PHYLIB=y
> +CONFIG_ZYNQ_GEM=y
>  CONFIG_ZYNQ_QSPI=y
> diff --git a/configs/zynq_zc706_defconfig b/configs/zynq_zc706_defconfig
> index 533aff9a7531..2e525b42d42a 100644
> --- a/configs/zynq_zc706_defconfig
> +++ b/configs/zynq_zc706_defconfig
> @@ -16,4 +16,5 @@ CONFIG_SPI_FLASH_SPANSION=y
>  CONFIG_SPI_FLASH_STMICRO=y
>  CONFIG_SPI_FLASH_WINBOND=y
>  CONFIG_PHYLIB=y
> +CONFIG_ZYNQ_GEM=y
>  CONFIG_ZYNQ_QSPI=y
> diff --git a/configs/zynq_zc770_xm010_defconfig 
> b/configs/zynq_zc770_xm010_defconfig
> index 689d19e992da..6f2ad17985e1 100644
> --- a/configs/zynq_zc770_xm010_defconfig
> +++ b/configs/zynq_zc770_xm010_defconfig
> @@ -18,5 +18,6 @@ CONFIG_SPI_FLASH_STMICRO=y
>  CONFIG_SPI_FLASH_SST=y
>  CONFIG_SPI_FLASH_WINBOND=y
>  CONFIG_PHYLIB=y
> +CONFIG_ZYNQ_GEM=y
>  CONFIG_ZYNQ_SPI=y
>  CONFIG_ZYNQ_QSPI=y
> diff --git a/configs/zynq_zc770_xm011_defconfig 
> b/configs/zynq_zc770_xm011_defconfig
> index c7125c304ab8..d20b3edf5cb3 100644
> --- a/configs/zynq_zc770_xm011_defconfig
> +++ b/configs/zynq_zc770_xm011_defconfig
> @@ -13,3 +13,4 @@ CONFIG_CMD_GPIO=y
>  # CONFIG_CMD_SETEXPR is not set
>  CONFIG_NET_RANDOM_ETHADDR=y
>  CONFIG_PHYLIB=y
> +CONFIG_ZYNQ_GEM=y
> diff --git a/configs/zynq_zc770_xm012_defconfig 
> b/configs/zynq_zc770_xm012_defconfig
> index a8f28da11767..4e963a45e2cf 100644
> --- a/configs/zynq_zc770_xm012_defconfig
> +++ b/configs/zynq_zc770_xm012_defconfig
> @@ -11,3 +11,4 @@ CONFIG_CMD_GPIO=y
>  # CONFIG_CMD_SETEXPR is not set
>  CONFIG_NET_RANDOM_ETHADDR=y
>  CONFIG_PHYLIB=y
> +CONFIG_ZYNQ_GEM=y
> diff --git a/configs/zynq_zc770_xm013_defconfig 
> b/configs/zynq_zc770_xm013_defconfig
> index 6b2fd8ca4ebb..f2d8f14f8784 100644
> --- a/configs/zynq_zc770_xm013_defconfig
> +++ b/configs/zynq_zc770_xm013_defconfig
> @@ -13,3 +13,4 @@ CONFIG_CMD_GPIO=y
>  # CONFIG_CMD_SETEXPR is not set
>  CONFIG_NET_RANDOM_ETHADDR=y
>  CONFIG_PHYLIB=y
> +CONFIG_ZYNQ_GEM=y
> diff --git a/configs/zynq_zed_defconfig b/configs/zynq_zed_defconfig
> index 4076c30707b1..2e7c68d6a49e 100644
> --- a/configs/zynq_zed_defconfig
> +++ b/configs/zynq_zed_defconfig
> @@ -16,4 +16,5 @@ CONFIG_SPI_FLASH_SPANSION=y
>  CONFIG_SPI_FLASH_STMICRO=y
>  CONFIG_SPI_FLASH_WINBOND=y
>  CONFIG_PHYLIB=y
> +CONFIG_ZYNQ_GEM=y
>  CONFIG_ZYNQ_QSPI=y
> diff --git a/configs/zynq_zybo_defconfig b/configs/zynq_zybo_defconfig
> index 

Re: [U-Boot] [PATCH 1/1] fsl_qspi: Pet the watchdog while reading/writing

[York Sun]

On 12/03/2015 01:49 AM, Wang Huan-B18965 wrote:



>>
>> The actual command which results in a watchdog reset is 'sf read
>> 0x8104 0x20 0x40'. Please note that this uses an external
>> watchdog which is enabled by default and resets after ~1.5s. The command
>> itself takes about 2s (taken from my watch).
>>
> [Alison Wang] I could not reproduce the issue. Maybe I don't have the
> external watchdog which will reset after ~1.5s as Alexander mentioned.
> 
> U-Boot 2015.10-00273-g7ee52af (Dec 03 2015 - 17:32:24 +0800)
> 
> CPU:   Freescale LayerScape LS1021E, Version: 2.0, (0x87081120)
> Clock Configuration:
>CPU0(ARMV7):1000 MHz,
>Bus:300  MHz, DDR:800  MHz (1600 MT/s data rate),
> Reset Configuration Word (RCW):
>: 0608000a   
>0010: 3000 7900 40025a00 21046000
>0020:    2000
>0030: 20024800 881b7540  
> Model: LS1021A TWR Board
> Board: LS1021ATWR
> I2C:   ready
> DRAM:  1 GiB
> Using SERDES1 Protocol: 48 (0x30)
> MMC:   FSL_SDHC: 0
> SF: Detected N25Q128 with page size 256 Bytes, erase size 64 KiB, total 16 MiB
> EEPROM: NXID v1
> PCIe1: Root Complex no link, regs @ 0x340
> PCIe2: disabled
> In:serial
> Out:   serial
> Err:   serial
> SEC: RNG instantiated
> SATA link 0 timeout.
> AHCI 0001.0300 1 slots 1 ports ? Gbps 0x1 impl SATA mode
> flags: 64bit ncq pm clo only pmp fbss pio slum part ccc
> Found 0 device(s).
> SCSI:  Net:   eTSEC1 is in sgmii mode.
> eTSEC2 is in sgmii mode.
> eTSEC1, eTSEC2, eTSEC3 [PRIME]
> => => sf probe
> SF: Detected N25Q128 with page size 256 Bytes, erase size 64 KiB, total 16 MiB
> => sf read 0x8104 0x20 0x40
> device 0 offset 0x20, size 0x40
> SF: 4194304 bytes @ 0x20 Read: OK
> =>

Alison and Alexander,

My concerns are

Is the watchdog triggered reasonably?
How long does it take to load the file?
Is SPI running at reasonable speed?
Is there other similar situations such as loading large file off NOR flash?


York

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

Re: [U-Boot] [PATCH v3 13/14] net: gem: Read information about interface from DT

[Jagan Teki]

On 3 December 2015 at 20:18, Michal Simek  wrote:
> Do not set interface via configs. Read information from DT.
>
> Signed-off-by: Michal Simek 
> ---

Reviewed-by: Jagan Teki 

thanks!
-- 
Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 02/14] ARM: zynq: Remove CONFIG_API

[Jagan Teki]

On 3 December 2015 at 20:17, Michal Simek  wrote:
> CONFIG_API is causing compilation error when DM_ETH is enabled because
> eth_get_dev() is not available.

Then how come, freebsd elf generate w/o CONFIG_API?

>
> Signed-off-by: Michal Simek 
> ---
>
> Changes in v3: None
> Changes in v2: None
>
>  include/configs/zynq-common.h | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/include/configs/zynq-common.h b/include/configs/zynq-common.h
> index a9e6bf046a97..5db501188b18 100644
> --- a/include/configs/zynq-common.h
> +++ b/include/configs/zynq-common.h
> @@ -297,7 +297,6 @@
>
>  /* Boot FreeBSD/vxWorks from an ELF image */
>  #if defined(CONFIG_ZYNQ_BOOT_FREEBSD)
> -# define CONFIG_API
>  # define CONFIG_SYS_MMC_MAX_DEVICE 1
>  #endif
>

thanks!
-- 
Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 10/14] net: gem: Remove zynq_gem_of_init()

[Jagan Teki]

On 3 December 2015 at 20:17, Michal Simek  wrote:
> This function was used for OF init before DM.
> Remove this function as the part of move to DM.
>
> Signed-off-by: Michal Simek 
> Reviewed-by: Simon Glass 
> ---

Reviewed-by: Jagan Teki 

thanks!
-- 
Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 12/14] net: gem: Move driver to DM

[Simon Glass]

Hi Joe,

On 3 December 2015 at 12:00, Joe Hershberger  wrote:
> Hi Simon,
>
> On Thu, Dec 3, 2015 at 12:57 PM, Simon Glass  wrote:
>>
>> On 3 December 2015 at 07:48, Michal Simek  wrote:
>> >
>> > - Enable DM_ETH by default for Zynq and ZynqMP
>> > - Remove board_eth_init code
>> > - Change miiphy_read function to return value instead of error code
>> >   based on DM requirement
>> > - Do not enable EMIO DT support by default
>> >
>> > Signed-off-by: Michal Simek 
>> > ---
>> >
>> > Changes in v3:
>> > - Add remove function reported by Bin Meng
>> >
>> > Changes in v2:
>> > - Remove accidentially added mmc code
>> > - Sort dm.h header
>> > - add platdata_auto_alloc_size
>> > - Read iobase from pdata instead of via gev_get_addr
>> > - Check positive return value from fdtdec_lookup_phandles instead of -1
>> >
>> >  arch/arm/Kconfig  |   2 +
>> >  board/xilinx/zynq/board.c |  13 ---
>> >  board/xilinx/zynqmp/zynqmp.c  |  25 --
>> >  drivers/net/zynq_gem.c| 179 
>> > ++
>> >  include/configs/zynq-common.h |   6 --
>> >  include/netdev.h  |   2 -
>> >  6 files changed, 112 insertions(+), 115 deletions(-)
>>
>> Reviewed-by: Simon Glass 
>>
>> We really need to get that PHY interface moved to DM!
>
> I made efforts in that direction months ago, but found that it is very
> messy to not first move all drivers to phylib, and then from phylib to
> DM. To support all 3 is just gross and unwieldy.

Sounds right. Rome wasn't built in a day.

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

Re: [U-Boot] [PATCH] iocon: Disable FIT_VERBOSE

[Dirk Eibach]

Hi Tom,

2015-12-03 13:19 GMT+01:00 Tom Rini :
> On Thu, Dec 03, 2015 at 09:40:46AM +0100, Dirk Eibach wrote:
>> Hi Tom,
>>
>> 2015-12-01 21:50 GMT+01:00 Tom Rini :
>> > In order to fit into image constraints again, remove this feature.
>> >
>> > Signed-off-by: Tom Rini 
>> > ---
>> >  configs/iocon_defconfig |1 +
>> >  include/configs/iocon.h |2 --
>> >  2 files changed, 1 insertion(+), 2 deletions(-)
>> >
>> > diff --git a/configs/iocon_defconfig b/configs/iocon_defconfig
>> > index bc5e026..a6532d1 100644
>> > --- a/configs/iocon_defconfig
>> > +++ b/configs/iocon_defconfig
>> > @@ -1,6 +1,7 @@
>> >  CONFIG_PPC=y
>> >  CONFIG_4xx=y
>> >  CONFIG_TARGET_IOCON=y
>> > +CONFIG_FIT=y
>> >  CONFIG_AUTOBOOT_KEYED=y
>> >  CONFIG_AUTOBOOT_STOP_STR=" "
>> >  # CONFIG_CMD_ELF is not set
>> > diff --git a/include/configs/iocon.h b/include/configs/iocon.h
>> > index 385a644..8663c17 100644
>> > --- a/include/configs/iocon.h
>> > +++ b/include/configs/iocon.h
>> > @@ -35,8 +35,6 @@
>> >  #undef CONFIG_ZERO_BOOTDELAY_CHECK /* ignore keypress on bootdelay==0 
>> > */
>> >
>> >  /* new uImage format support */
>> > -#define CONFIG_FIT
>> > -#define CONFIG_FIT_VERBOSE /* enable fit_format_{error,warning}() */
>> >  #define CONFIG_FIT_DISABLE_SHA256
>> >
>> >  #define CONFIG_ENV_IS_IN_FLASH /* use FLASH for environment vars */
>> > --
>> > 1.7.9.5
>>
>> NAK.
>> CONFIG_FIT is an essential feature for this board.
>
> FIT is enabled (and migrated to the config file), FIT_VERBOSE is
> removed.

Ooops. Sorry for the noise. So:
Reviewed-by:  Dirk Eibach 

Cheers
Dirk
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCHv4 3/9] arm: socfpga: arria10: add reset manager for Arria10

[Pavel Machek]

On Wed 2015-12-02 13:31:27, dingu...@opensource.altera.com wrote:
> From: Dinh Nguyen 
> 
> Add the defines for the reset manager and some basic reset functionality.
> 
> Signed-off-by: Dinh Nguyen 
> ---
> v4: rename mod_reset names to be used by both gen5 and a10
> v3: remove duplicate reset function
> use CONFIG_SOCFPGA_GEN5
> v2: integrate into a5/c5 reset manager
> ---
>  arch/arm/mach-socfpga/include/mach/reset_manager.h | 71 
> +-
>  arch/arm/mach-socfpga/reset_manager.c  | 36 ---
>  2 files changed, 97 insertions(+), 10 deletions(-)
> 
> diff --git a/arch/arm/mach-socfpga/include/mach/reset_manager.h 
> b/arch/arm/mach-socfpga/include/mach/reset_manager.h
> index e50fbd8..b34c7c6 100644
> --- a/arch/arm/mach-socfpga/include/mach/reset_manager.h
> +++ b/arch/arm/mach-socfpga/include/mach/reset_manager.h
> @@ -15,19 +15,56 @@ void socfpga_bridges_reset(int enable);
>  void socfpga_per_reset(u32 reset, int set);
>  void socfpga_per_reset_all(void);
>  
> +#if defined(CONFIG_TARGET_SOCFPGA_GEN5)
>  struct socfpga_reset_manager {
>   u32 status;
>   u32 ctrl;
>   u32 counts;
>   u32 padding1;
>   u32 mpu_mod_reset;
> - u32 per_mod_reset;
> - u32 per2_mod_reset;
> + u32 per0_mod_reset; /* per_mod_reset */
> + u32 per1_mod_reset; /* per2_mod_reset */
>   u32 brg_mod_reset;
> - u32 misc_mod_reset;
> + u32 sys_mod_reset; /* misc_mod_reset */

Umm. Those comments are really hard to understand. Add "in the
datasheet" at the end so that poor reader has chance to see what is
going on?

Thanks,
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 12/14] net: gem: Move driver to DM

[Simon Glass]

On 3 December 2015 at 07:48, Michal Simek  wrote:
>
> - Enable DM_ETH by default for Zynq and ZynqMP
> - Remove board_eth_init code
> - Change miiphy_read function to return value instead of error code
>   based on DM requirement
> - Do not enable EMIO DT support by default
>
> Signed-off-by: Michal Simek 
> ---
>
> Changes in v3:
> - Add remove function reported by Bin Meng
>
> Changes in v2:
> - Remove accidentially added mmc code
> - Sort dm.h header
> - add platdata_auto_alloc_size
> - Read iobase from pdata instead of via gev_get_addr
> - Check positive return value from fdtdec_lookup_phandles instead of -1
>
>  arch/arm/Kconfig  |   2 +
>  board/xilinx/zynq/board.c |  13 ---
>  board/xilinx/zynqmp/zynqmp.c  |  25 --
>  drivers/net/zynq_gem.c| 179 
> ++
>  include/configs/zynq-common.h |   6 --
>  include/netdev.h  |   2 -
>  6 files changed, 112 insertions(+), 115 deletions(-)

Reviewed-by: Simon Glass 

We really need to get that PHY interface moved to DM!

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

Re: [U-Boot] [PATCH 2/2] spi: ti_qspi: Fix SPI_3WIRE checking using mode

[Simon Glass]

On 3 December 2015 at 10:12, Jagan Teki  wrote:
> SPI_3WIRE is spi mode not spi flags, so this patch fixed
> the spi-3wire checking throgh mode instead of flags.
>
> Cc: Mugunthan V N 
> Cc: Simon Glass 
> Signed-off-by: Jagan Teki 
> ---
>  drivers/spi/ti_qspi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Acked-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] spi: Get spi-3wire from dts

[Simon Glass]

On 3 December 2015 at 10:12, Jagan Teki  wrote:
> spi-3wire is used when SI/SO signals shared so get
> the same from dts node and assign to mode on slave
> plat->mode.
>
> Cc: Simon Glass 
> Signed-off-by: Jagan Teki 
> ---
>  drivers/spi/spi-uclass.c | 2 ++
>  1 file changed, 2 insertions(+)

Acked-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 2/2] arm: socfpga: add define for bootinfo bsel bit shift

[dinguyen]

From: Dinh Nguyen 

On arria5/cyclone5 parts, the bsel bits are at shift 0, while for arria10,
the bsel bits are at shift 12. Add SYSMGR_BOOTINFO_BSEL_SHIFT define so that
the reading the bsel can generic.

Suggested-by: Marek Vasut 
Signed-off-by: Dinh Nguyen 
---
 arch/arm/mach-socfpga/include/mach/system_manager.h | 2 ++
 arch/arm/mach-socfpga/misc.c| 4 ++--
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-socfpga/include/mach/system_manager.h 
b/arch/arm/mach-socfpga/include/mach/system_manager.h
index e688c50..9ca889a 100644
--- a/arch/arm/mach-socfpga/include/mach/system_manager.h
+++ b/arch/arm/mach-socfpga/include/mach/system_manager.h
@@ -203,8 +203,10 @@ struct socfpga_system_manager {
 
 #if defined(CONFIG_TARGET_SOCFPGA_GEN5)
 #define SYSMGR_SDMMC_SMPLSEL_SHIFT 3
+#define SYSMGR_BOOTINFO_BSEL_SHIFT 0
 #else
 #define SYSMGR_SDMMC_SMPLSEL_SHIFT 4
+#define SYSMGR_BOOTINFO_BSEL_SHIFT 12
 #endif
 
 #define SYSMGR_SDMMC_DRVSEL_SHIFT  0
diff --git a/arch/arm/mach-socfpga/misc.c b/arch/arm/mach-socfpga/misc.c
index 78774d5..15c4c2a 100644
--- a/arch/arm/mach-socfpga/misc.c
+++ b/arch/arm/mach-socfpga/misc.c
@@ -215,12 +215,12 @@ static int socfpga_fpga_id(const bool print_id)
 #if defined(CONFIG_DISPLAY_CPUINFO)
 int print_cpuinfo(void)
 {
+   const u32 bsel = (readl(_regs->bootinfo) >>
+ SYSMGR_BOOTINFO_BSEL_SHIFT) & 0x7;
 #if defined(CONFIG_TARGET_SOCFPGA_GEN5)
-   const u32 bsel = readl(_regs->bootinfo) & 0x7;
puts("CPU:   Altera SoCFPGA Platform\n");
socfpga_fpga_id(1);
 #else
-   const u32 bsel = (readl(_regs->bootinfo) >> 12) & 0x7;
puts("CPU:   Altera SoCFPGA Arria 10\n");
 #endif
printf("BOOT:  %s\n", bsel_str[bsel].name);
-- 
2.6.2

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

[U-Boot] [PATCHv5 1/2] arm: socfpga: arria10: add reset manager for Arria10

[dinguyen]

From: Dinh Nguyen 

Add the defines for the reset manager and some basic reset functionality.

Signed-off-by: Dinh Nguyen 
---
v5: rename the mod_reest on A10 to match those in gen5
v4: rename mod_reset names to be used by both gen5 and a10
v3: remove duplicate reset function
use CONFIG_SOCFPGA_GEN5
v2: integrate into a5/c5 reset manager
---
 arch/arm/mach-socfpga/include/mach/reset_manager.h | 65 ++
 arch/arm/mach-socfpga/reset_manager.c  | 24 +++-
 2 files changed, 88 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-socfpga/include/mach/reset_manager.h 
b/arch/arm/mach-socfpga/include/mach/reset_manager.h
index e50fbd8..6ddba18 100644
--- a/arch/arm/mach-socfpga/include/mach/reset_manager.h
+++ b/arch/arm/mach-socfpga/include/mach/reset_manager.h
@@ -15,6 +15,7 @@ void socfpga_bridges_reset(int enable);
 void socfpga_per_reset(u32 reset, int set);
 void socfpga_per_reset_all(void);
 
+#if defined(CONFIG_TARGET_SOCFPGA_GEN5)
 struct socfpga_reset_manager {
u32 status;
u32 ctrl;
@@ -28,6 +29,42 @@ struct socfpga_reset_manager {
u32 padding2[12];
u32 tstscratch;
 };
+#else
+struct socfpga_reset_manager {
+   u32 stat;
+   u32 ramstat;
+   u32 miscstat;
+   u32 ctrl;
+   u32 hdsken;
+   u32 hdskreq;
+   u32 hdskack;
+   u32 counts;
+   u32 mpu_mod_reset;
+   u32 per_mod_reset;  /* stated as per0_mod_reset in A10 datasheet */
+   u32 per2_mod_reset; /* stated as per1_mod_reset in A10 datasheet */
+   u32 brg_mod_reset;
+   u32 misc_mod_reset; /* stated as sys_mod_reset in A10 datasheet */
+   u32 coldmodrst;
+   u32 nrstmodrst;
+   u32 dbgmodrst;
+   u32 mpuwarmmask;
+   u32 per0warmmask;
+   u32 per1warmmask;
+   u32 brgwarmmask;
+   u32 syswarmmask;
+   u32 nrstwarmmask;
+   u32 l3warmmask;
+   u32 tststa;
+   u32 tstscratch;
+   u32 hdsktimeout;
+   u32 hmcintr;
+   u32 hmcintren;
+   u32 hmcintrens;
+   u32 hmcintrenr;
+   u32 hmcgpout;
+   u32 hmcgpin;
+};
+#endif
 
 #if defined(CONFIG_SOCFPGA_VIRTUAL_TARGET)
 #define RSTMGR_CTRL_SWWARMRSTREQ_LSB 2
@@ -55,6 +92,7 @@ struct socfpga_reset_manager {
 #define RSTMGR_BANK(_reset)\
(((_reset) >> RSTMGR_BANK_OFFSET) & RSTMGR_BANK_MASK)
 
+#if defined(CONFIG_TARGET_SOCFPGA_GEN5)
 /*
  * SocFPGA Cyclone V/Arria V reset IDs, bank mapping is as follows:
  * 0 ... mpumodrst
@@ -74,6 +112,33 @@ struct socfpga_reset_manager {
 #define RSTMGR_SDMMC   RSTMGR_DEFINE(1, 22)
 #define RSTMGR_DMA RSTMGR_DEFINE(1, 28)
 #define RSTMGR_SDR RSTMGR_DEFINE(1, 29)
+#else
+/*
+ * SocFPGA Arria10 reset IDs, bank mapping is as follows:
+ * 0 ... mpumodrst
+ * 1 ... per0modrst
+ * 2 ... per1modrst
+ * 3 ... brgmodrst
+ * 4 ... sysmodrst
+ */
+#define RSTMGR_EMAC0   RSTMGR_DEFINE(1, 0)
+#define RSTMGR_EMAC1   RSTMGR_DEFINE(1, 1)
+#define RSTMGR_EMAC2   RSTMGR_DEFINE(1, 2)
+#define RSTMGR_L4WD0   RSTMGR_DEFINE(2, 0)
+#define RSTMGR_L4WD1   RSTMGR_DEFINE(2, 1)
+#define RSTMGR_L4SYSTIMER0 RSTMGR_DEFINE(2, 2)
+#define RSTMGR_L4SYSTIMER1 RSTMGR_DEFINE(2, 3)
+#define RSTMGR_SPTIMER0RSTMGR_DEFINE(2, 4)
+#define RSTMGR_SPTIMER1RSTMGR_DEFINE(2, 5)
+#define RSTMGR_UART0   RSTMGR_DEFINE(2, 16)
+#define RSTMGR_UART1   RSTMGR_DEFINE(2, 17)
+#define RSTMGR_SPIM0   RSTMGR_DEFINE(1, 17)
+#define RSTMGR_SPIM1   RSTMGR_DEFINE(1, 18)
+#define RSTMGR_QSPIRSTMGR_DEFINE(1, 6)
+#define RSTMGR_SDMMC   RSTMGR_DEFINE(1, 7)
+#define RSTMGR_DMA RSTMGR_DEFINE(1, 16)
+#define RSTMGR_DDRSCH  RSTMGR_DEFINE(3, 6)
+#endif
 
 /* Create a human-readable reference to SoCFPGA reset. */
 #define SOCFPGA_RESET(_name)   RSTMGR_##_name
diff --git a/arch/arm/mach-socfpga/reset_manager.c 
b/arch/arm/mach-socfpga/reset_manager.c
index b6beaa2..d0ff6c4 100644
--- a/arch/arm/mach-socfpga/reset_manager.c
+++ b/arch/arm/mach-socfpga/reset_manager.c
@@ -18,7 +18,9 @@ static const struct socfpga_reset_manager *reset_manager_base 
=
 static struct socfpga_system_manager *sysmgr_regs =
(struct socfpga_system_manager *)SOCFPGA_SYSMGR_ADDRESS;
 
-/* Assert or de-assert SoCFPGA reset manager reset. */
+/*
+ * Assert or de-assert SoCFPGA reset manager reset.
+ */
 void socfpga_per_reset(u32 reset, int set)
 {
const void *reg;
@@ -46,13 +48,29 @@ void socfpga_per_reset(u32 reset, int set)
  * Assert reset on every peripheral but L4WD0.
  * Watchdog must be kept intact to prevent glitches
  * and/or hangs.
+ * For the Arria10, we disable all the peripherals except L4 watchdog0,
+ * L4 Timer 0, and ECC.
  */
 

Re: [U-Boot] [PATCH 7/8] x86: fsp: Move VPD/UPD verification to update_fsp_configs()

[Simon Glass]

Hi Bin,

On 2 December 2015 at 22:22, Bin Meng  wrote:
> Hi Simon,
>
> On Thu, Dec 3, 2015 at 5:05 AM, Simon Glass  wrote:
>> Hi Bin,
>>
>> On 2 December 2015 at 01:59, Bin Meng  wrote:
>>> Since VPD/UPD may not exist on every FSP, move the codes that
>>> verifies VPD/UPD to chipset-specific update_fsp_configs().
>>> This also updates update_fsp_configs() signature to accpect
>>> FSP runtime buffer pointer as its second parameter.
>>>
>>> Signed-off-by: Bin Meng 
>>> ---
>>>
>>>  arch/x86/cpu/baytrail/fsp_configs.c| 24 +++-
>>>  arch/x86/cpu/queensbay/fsp_configs.c   | 26 +-
>>>  arch/x86/include/asm/fsp/fsp_support.h |  4 +++-
>>>  arch/x86/lib/fsp/fsp_support.c | 24 +---
>>>  4 files changed, 52 insertions(+), 26 deletions(-)
>>>
>>> diff --git a/arch/x86/cpu/baytrail/fsp_configs.c 
>>> b/arch/x86/cpu/baytrail/fsp_configs.c
>>> index 9810921..3a03392 100644
>>> --- a/arch/x86/cpu/baytrail/fsp_configs.c
>>> +++ b/arch/x86/cpu/baytrail/fsp_configs.c
>>> @@ -125,13 +125,35 @@ const struct pch_azalia_config azalia_config = {
>>>   * If the device tree does not specify an integer setting, use the default
>>>   * provided in Intel's Baytrail_FSP_Gold4.tgz release FSP/BayleyBayFsp.bsf 
>>> file.
>>>   */
>>> -void update_fsp_configs(struct fsp_config_data *config)
>>> +void update_fsp_configs(struct fsp_config_data *config,
>>> +   struct fspinit_rtbuf *rt_buf)
>>>  {
>>> +   struct fsp_header *fsp_hdr = config->fsp_hdr;
>>> +   struct vpd_region *fsp_vpd;
>>> struct upd_region *fsp_upd = >fsp_upd;
>>> struct memory_down_data *mem;
>>> const void *blob = gd->fdt_blob;
>>> int node;
>>>
>>> +   /* Initialize runtime buffer for fsp_init() */
>>> +   rt_buf->common.stack_top = config->stack_top - 32;
>>> +   rt_buf->common.boot_mode = config->boot_mode;
>>> +   rt_buf->common.upd_data = >fsp_upd;
>>> +
>>> +   /* Get VPD region start */
>>> +   fsp_vpd = (struct vpd_region *)(fsp_hdr->img_base +
>>> +   fsp_hdr->cfg_region_off);
>>> +
>>> +   /* Verify the VPD data region is valid */
>>> +   assert(fsp_vpd->sign == VPD_IMAGE_ID);
>>> +
>>> +   /* Copy default data from Flash */
>>> +   memcpy(fsp_upd, (void *)(fsp_hdr->img_base + fsp_vpd->upd_offset),
>>> +  sizeof(struct upd_region));
>>> +
>>> +   /* Verify the UPD data region is valid */
>>> +   assert(fsp_upd->terminator == UPD_TERMINATOR);
>>> +
>>
>> Maybe rather than duplicating this code, it can go in a common
>> function that is called for these two boards?
>>
>
> Yes, we can create a common function to do these, but that requires we
> create a Kconfig option something like CONFIG_FSP_USE_UPD or
> CONFIG_FSP_NO_UPD to wrap these codes in arch/x86/lib/fsp_support.c. I
> don't want to create a Kconfig option so chose to duplicate the codes.
> What do you think?

Well I dislike duplicated code more, so I think CONFIG_FSP_USE_UPD
might be best.

>
> [snip]
>
> Regards,
> Bin

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

Re: [U-Boot] Next for x86?

[Simon Glass]

Hi Bin,

On 2 December 2015 at 21:57, Bin Meng  wrote:
> Hi Simon,
>
> On Thu, Nov 26, 2015 at 12:52 AM, Simon Glass  wrote:
>> Hi Bin,
>>
>> On 19 November 2015 at 20:38, Bin Meng  wrote:
>>> Hi Simon,
>>>
>>> On Fri, Nov 20, 2015 at 11:09 AM, Simon Glass  wrote:
 Hi,

 I'm wondering what might come next for U-Boot x86 support.

 The PCI conversion to driver model is coming along nicely. The ACPI
 support is only partially there but it is a good start.
>>
>> I have another series of PCI patches in the works and hope to get
>> these out in a few weeks. The intent is to fully move x86 to use the
>> driver model API.
>>

 What else? More platforms? Other features? Better support for existing
 platforms?

>>>
>>> Two biggest feature gaps so far are complete ACPI support, and SMM
>>> support. ACPI is pretty much a must-have if we want power management
>>> feature in the OS. For SMM, I am not convinced that we have to do that
>>> in U-Boot, for example those BIOS guys invented USB legacy support
>>> (I/O port emulation of PS/2 keyboard) via SMM but today we have native
>>> USB support and we should not do such with SMM in U-Boot. One corner
>>> case is that some ACPI AML codes on some commercial BIOS trap the ACPI
>>> calls into SMM where SMM is a must-have. Unfortunately such
>>> limitations exist as there are still lots of unpublished chipset docs
>>> from various vendors who want to protect their IP (so-called).
>>>
>>> ACPI support seems to be a must if we want to support booting Windows,
>>> also we may need help from SeaBIOS (chain-loaded from U-Boot).
>>
>> Yes we should try to get that finished. It seems pretty close at least
>> on qemu and minnowboard max.
>>
>>>
>>> For other features, what I can think of now are:
>>> - New platform support which relies on FSP. With FSP it is quite easy
>>> to add a new platform support for Intel processors.
>>> - FSP spec 1.1 support, however Intel has not released any FSP package
>>> based on FSP spec 1.1. I believe their next gen Atom/Core processors'
>>> FSP will support FSP 1.1 (like Braswell, Skylake)
>>
>> Yes it seems like this will happen when we get the first board that supports 
>> it.
>>
>>> - TPM support, and Intel TXT/TXE
>>
>> There is LPC TPM support at present so perhaps that is a start.
>>
>>> - xHCI support on Intel chipset (looks the U-Boot xHCI driver is not
>>> working for Intel)
>>
>> Agreed, this shouldn't be too tricky as it is a standard.
>>
>>> - Audio support (maybe just providing audio codec's verb table in U-Boot)
>>
>> There is basic speaker support, and on a few ARM boards there is basic
>> audio support (playing a waveform, and code to generate a waveform).
>> This is pretty platform-specific as each codec is different. Do you
>> have a board with a built-in audio codec?
>>
>
> Looks Crown Bay and Bayley Bay boards have on-board audio codec. By
> supporting audio I mean to enable OS to have the audio functionality.
> I am not aware of U-Boot is able to play sound :)

OK I see. U-Boot does support for audio for x86, but only the beep
speaker at present. For ARM there are a few codecs though.

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

Re: [U-Boot] [PATCH 4/8] x86: fsp: Rename shared_data to fsp_config_data

[Simon Glass]

Hi Bin,

On 2 December 2015 at 22:18, Bin Meng  wrote:
> Hi Simon,
>
> On Thu, Dec 3, 2015 at 5:05 AM, Simon Glass  wrote:
>> Hi Bin,
>>
>> On 2 December 2015 at 01:59, Bin Meng  wrote:
>>> FSP has several config data like UPD, HDA verb table which can be
>>> overridden or provided by bootloader. Currently in U-Boot only UPD
>>> is handled via struct shared_data. To accommodate any platform, we
>>> rename shared_data to fsp_config_data and move the definition from
>>> common place fsp_support.h to platform-specific place fsp_configs.h.
>>>
>>> Signed-off-by: Bin Meng 
>>> ---
>>>
>>>  arch/x86/include/asm/arch-baytrail/fsp/fsp_configs.h  | 17 
>>> +
>>>  arch/x86/include/asm/arch-queensbay/fsp/fsp_configs.h | 17 
>>> +
>>>  arch/x86/include/asm/fsp/fsp_support.h|  8 +---
>>>  arch/x86/lib/fsp/fsp_support.c| 10 +-
>>>  4 files changed, 40 insertions(+), 12 deletions(-)
>>>  create mode 100644 arch/x86/include/asm/arch-baytrail/fsp/fsp_configs.h
>>>  create mode 100644 arch/x86/include/asm/arch-queensbay/fsp/fsp_configs.h
>>>
>>> diff --git a/arch/x86/include/asm/arch-baytrail/fsp/fsp_configs.h 
>>> b/arch/x86/include/asm/arch-baytrail/fsp/fsp_configs.h
>>> new file mode 100644
>>> index 000..2397553
>>> --- /dev/null
>>> +++ b/arch/x86/include/asm/arch-baytrail/fsp/fsp_configs.h
>>> @@ -0,0 +1,17 @@
>>> +/*
>>> + * Copyright (C) 2015, Bin Meng 
>>> + *
>>> + * SPDX-License-Identifier:Intel
>>> + */
>>> +
>>> +#ifndef __FSP_CONFIGS_H__
>>> +#define __FSP_CONFIGS_H__
>>
>> Does this justify its own header file? I suppose it does...we have too
>> many fsp header files and I never know which file contains a
>> particular struct definition.
>>
>>> +
>>> +struct fsp_config_data {
>>> +   struct fsp_header   *fsp_hdr;
>>> +   u32 stack_top;
>>> +   u32 boot_mode;
>>> +   struct upd_region   fsp_upd;
>>
>> These are common - should we have a common struct as the first member?
>>
>
> We certainly can create a common struct for the first 3 members
> (fsp_hdr, stack_top, boot_mode). Another way is to change
> fsp_update_configs() (in patch#7 of this series) signature to:
>
> void update_fsp_configs(struct fsp_config_data *config, struct
> fspinit_rtbuf *rt_buf, struct fsp_header *fsp_hdr, u32 stack_top, u32
> boot_mode);
>
> This way we avoid saving these 3 parameters into struct fsp_config_data.

That's a lot of parameters. I think a common struct seems better for
now. We may see a different approach when newer FSPs turn up.

>
>> I'm just struggling to understand the benefit of duplicating this
>> common thing into separate files.
>>
>
> [snip]
>
> Regards,
> Bin

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

Re: [U-Boot] [PATCH v2 12/14] net: gem: Move driver to DM

[Simon Glass]

Hi Michal,

On 2 December 2015 at 22:00, Bin Meng  wrote:
> Hi Michal,
>
> On Wed, Dec 2, 2015 at 9:51 PM, Michal Simek  wrote:
>> On 2.12.2015 14:16, Bin Meng wrote:
>>> Hi Michal,
>>>
>>> On Wed, Dec 2, 2015 at 7:36 PM, Michal Simek  
>>> wrote:
>>
>> ...
>>
 +
 +   offset = fdtdec_lookup_phandle(gd->fdt_blob, dev->of_offset,
 +  "phy-handle");
 +   if (offset > 0)
 +   priv->phyaddr = fdtdec_get_int(gd->fdt_blob, offset, 
 "reg", 0);
>>>
>>> I don't see where is this priv->phyaddr used in this driver?
>>
>> phy_detection function called from zynq_phy_init/
>>
>>>

 -   return 1;
 +   printf("ZYNQ GEM: %lx, phyaddr %d\n", (ulong)priv->iobase,
 +  priv->phyaddr);
 +
 +   return 0;
  }
 +
 +static const struct udevice_id zynq_gem_ids[] = {
 +   { .compatible = "cdns,zynqmp-gem" },
 +   { .compatible = "cdns,zynq-gem" },
 +   { .compatible = "cdns,gem" },
 +   { }
 +};
 +
 +U_BOOT_DRIVER(zynq_gem) = {
 +   .name   = "zynq_gem",
 +   .id = UCLASS_ETH,
 +   .of_match = zynq_gem_ids,
 +   .ofdata_to_platdata = zynq_gem_ofdata_to_platdata,
 +   .probe  = zynq_gem_probe,
>>>
>>> Please add .remove function, otherwise there will be memory leak when
>>> removing the device. See designware.c for example.
>>
>> No problem to do it. It will be almost c from that driver.
>> Do we have any way how to detect these leaks?
>
> None that I am aware of.
>
>>
>> I have never tried to remove devices. How to do it?
>>
>
> This can be tested by adding test codes to call device_remove(dev).

You could create a 'dm remove' command which operates on the full
device path, if you like. It think that would be useful for testing.

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

Re: [U-Boot] [PATCH 1/8] x86: fsp: Simplify fsp_continue()

[Simon Glass]

Hi Bin,

On 2 December 2015 at 22:11, Bin Meng  wrote:
> Hi Simon,
>
> On Thu, Dec 3, 2015 at 5:05 AM, Simon Glass  wrote:
>> Hi Bin,
>>
>> On 2 December 2015 at 01:58, Bin Meng  wrote:
>>> There is no need to pass shared_data to fsp_continue() so we can
>>> remove unnecessary codes that simplifies the function a lot.
>>
>> Is this because shared_data is effectively useful for a bootloader due
>> to the stack being changed?
>>
>
> The removed codes were originally from Queensbay FSP package. Looks
> Intel's intention was to help stack migration, but I doubt they ever
> worked. We don't support stack migration after fsp_init() hence these
> codes are never needed.

Eek. Nasty unimplemented specs!

Acked-by: Simon Glass 

>
>>>
>>> Signed-off-by: Bin Meng 
>>> ---
>>>
>>>  arch/x86/include/asm/fsp/fsp_support.h |  4 +---
>>>  arch/x86/lib/fsp/fsp_support.c | 29 ++---
>>>  2 files changed, 7 insertions(+), 26 deletions(-)
>>>
>>
>> [snip]
>>
>> Regards,
>> Simon
>
> Regards,
> Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] x86: Clean up SPI flash drivers in defconfig

[Simon Glass]

Hi,

On 3 December 2015 at 06:27, Bin Meng  wrote:
> Hi Jagan,
>
> On Thu, Dec 3, 2015 at 6:24 PM, Jagan Teki  wrote:
>> Hi Bin,
>>
>> On 3 December 2015 at 10:14, Bin Meng  wrote:
>>> Hi Simon,
>>>
>>> On Thu, Dec 3, 2015 at 5:05 AM, Simon Glass  wrote:
 +Jagan

 Hi Bin,

 On 1 December 2015 at 18:41, Bin Meng  wrote:
>
> Hi Simon,
>
> On Wed, Dec 2, 2015 at 12:32 AM, Simon Glass  wrote:
> > Hi Bin,
> >
> > On 28 November 2015 at 05:45, Bin Meng  wrote:
> >> Every board has one dedicated type of SPI flash, hence it is
> >> unnecessary to include multiple SPI flash drivers.
> >>
> >> For QEMU and coreboot (default build of coreboot is also QEMU),
> >> SPI flash is not supported. Remove those SPI flash drivers.
> >>
> >> Signed-off-by: Bin Meng 
> >> ---
> >>
> >>  configs/bayleybay_defconfig | 2 --
> >>  configs/chromebook_link_defconfig   | 2 --
> >>  configs/chromebox_panther_defconfig | 2 --
> >>  configs/coreboot-x86_defconfig  | 4 
> >>  configs/crownbay_defconfig  | 3 ---
> >>  configs/galileo_defconfig   | 2 --
> >>  configs/minnowmax_defconfig | 3 ---
> >>  configs/qemu-x86_defconfig  | 4 
> >>  8 files changed, 22 deletions(-)
> >
> > What is the benefit of this? I see it removes a few lines in a data
> > table. Does it matter?
>
> Maybe we should ask the other way around, why do we create so many
> flash driver Kconfig option? I believe the intention was footprint.
> Besides the footprint issue, having just one flash driver in each
> board makes it very clear instead of causing confusion. Looks other
> board defconfig files only select one.
>>
>> Are you talking about flash vendor config or CONFIG_SPI_FLASH?
>>
>
> Flash vendor config, as you see in this patch.
>

 They are a hangover from when we had a separate driver for each one.
 Jagan put a lot of effort into removing all the semi-duplicated code.

 Maybe we should prune down these options?

>>>
>>> But if we already spent a lot of effort into removing all the
>>> semi-duplicated code, we should not have converted those flash driver
>>> to Kconfig options before.
>>>
>>> See commit d5af92315bb48740f16bf8817f38e227d3076905 "sf: kconfig: add
>>> kconfig options for spi flashes"
>>>
>>> I suspect we may remove most of these SPI flash macros, but at least
>>> SST flash macro should be kept since right now it is mixed in the
>>> generic driver with a special byte program and word program which is
>>> incompatible with other vendors' flashes.
>>
>> But there is some flash vendor specific code like quad enable bit,
>> locking ops and finally about spi_flash_params table.
>>
>
> I know. That's probably why adding all these SPI flash drivers don't
> help at all because only one code path will take effect. And what I
> did in this patch is to select one type of flash per board.

So how about we group together 3-4 of the common ones, with no special
features, into a 'CONFIG_SPI_FLASH_GENERIC'?

>
>>>
>
> >
> > For all of these platforms we can use the dediprog em100 which I
> > typically set to use winbond as the manufacturer, regardless of which
> > chip is actually on the board.
> >
>
> I think that's because emulator can emulate flash from various vendors.

 Yes, and also for convenience.

>
> > For U-Boot on coreboot, why is SPI flash not supported? It certainly
> > works with link.
>
> Yes, booting from coreboot does support SPI flash. However since we
> decided to use QEMU as the default build target for coreboot, and QEMU
> does not support SPI flash yet, these config options are removed. One
> can certainly adjust these Kconfig options via 'make menuconfig', eg:
> adding SD/MMC support which is not in coreboot's defconfig either.

 Well this breaks booting on link, since the SPI flash stops working.
 I'm really not keen on having to specially select the SPI flash when
 you want to use link.

>>>
>>> Do you mean booting U-Boot on link from coreboot? Without SPI flash it
>>> should still boot. It looks to me your preference is to include all
>>> the available drivers into coreboot's defconfig, yes? If so, we may
>>> add some other drivers Kconfig in coreboot-x86_defconfig too, like
>>> SD/MMC drivers, all the available ethernet drivers even they only
>>> exist on some boards.
>>
>> thanks!
>> --
>
> Regards,
> Bin

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

Re: [U-Boot] [PATCH v5 1/8] dm: tegra: pci: Move CONFIG_PCI_TEGRA to Kconfig

[Stephen Warren]

On 11/19/2015 08:26 PM, Simon Glass wrote:

Move this option to Kconfig and fix up all users.


The version of this that got committed (as fde7e18938d8) contains merge 
markers in a four files.

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

[U-Boot] [PATCH] driver: net: fsl-mc: remove MC firmware version check

[Stuart Yoder]

The MC version numbers provide no meaningful information
about binary interface compatibility, so remove the
check which refuses to start the MC unless a specific
version is found.

Version checking is supposed to be done at the individual
object level, and individual drivers are responsible
for their own version checking.

Signed-off-by: Stuart Yoder 
---
 drivers/net/fsl-mc/mc.c | 13 -
 1 file changed, 13 deletions(-)

diff --git a/drivers/net/fsl-mc/mc.c b/drivers/net/fsl-mc/mc.c
index e1a02d1..bac4610 100644
--- a/drivers/net/fsl-mc/mc.c
+++ b/drivers/net/fsl-mc/mc.c
@@ -541,19 +541,6 @@ int mc_init(u64 mc_fw_addr, u64 mc_dpc_addr)
goto out;
}
 
-   if (MC_VER_MAJOR != mc_ver_info.major) {
-   printf("fsl-mc: ERROR: Firmware major version mismatch (found: 
%d, expected: %d)\n",
-  mc_ver_info.major, MC_VER_MAJOR);
-   printf("fsl-mc: Update the Management Complex firmware\n");
-
-   error = -ENODEV;
-   goto out;
-   }
-
-   if (MC_VER_MINOR != mc_ver_info.minor)
-   printf("fsl-mc: WARNING: Firmware minor version mismatch 
(found: %d, expected: %d)\n",
-  mc_ver_info.minor, MC_VER_MINOR);
-
printf("fsl-mc: Management Complex booted (version: %d.%d.%d, boot 
status: %#x)\n",
   mc_ver_info.major, mc_ver_info.minor, mc_ver_info.revision,
   reg_gsr & GSR_FS_MASK);
-- 
2.3.3

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

[U-Boot] [PATCH] mkimage : Fix generating multi and script images

[Philippe De Swert]

Seems 92a655c3 broke creating multi and script type images.
Since the file1:file2:file3 string does not get split up,
it fails on trying to open an non-existing file. 

mkimage -A arm -O linux -T multi -C none -d zImage:splash.bmp:device.dtb uimage
tools/mkimage: Can't open zImage:splash.bmp:device.dtb: No such file or 
directory

Since the sizes of the different parts seem to get added in the actual 
routine that handles multi and script type images, we can probably skip the 
bit of the code that causes the failure for that type of images.

Signed-off-by: Philippe De Swert 
---
 tools/mkimage.c | 31 ++-
 1 file changed, 18 insertions(+), 13 deletions(-)

diff --git a/tools/mkimage.c b/tools/mkimage.c
index 8af9d50..ae01cb1 100644
--- a/tools/mkimage.c
+++ b/tools/mkimage.c
@@ -311,21 +311,26 @@ NXTARG:   ;
exit (retval);
}
 
-   dfd = open(params.datafile, O_RDONLY | O_BINARY);
-   if (dfd < 0) {
-   fprintf(stderr, "%s: Can't open %s: %s\n",
-   params.cmdname, params.datafile, strerror(errno));
-   exit(EXIT_FAILURE);
-   }
+   if (!params.type == IH_TYPE_MULTI ||
+   !params.type == IH_TYPE_SCRIPT) {
+   dfd = open(params.datafile, O_RDONLY | O_BINARY);
+   if (dfd < 0) {
+   fprintf(stderr, "%s: Can't open %s: %s\n",
+   params.cmdname, params.datafile,
+   strerror(errno));
+   exit(EXIT_FAILURE);
+   }
 
-   if (fstat(dfd, ) < 0) {
-   fprintf(stderr, "%s: Can't stat %s: %s\n",
-   params.cmdname, params.datafile, strerror(errno));
-   exit(EXIT_FAILURE);
-   }
+   if (fstat(dfd, ) < 0) {
+   fprintf(stderr, "%s: Can't stat %s: %s\n",
+   params.cmdname, params.datafile,
+   strerror(errno));
+   exit(EXIT_FAILURE);
+   }
 
-   params.file_size = sbuf.st_size + tparams->header_size;
-   close(dfd);
+   params.file_size = sbuf.st_size + tparams->header_size;
+   close(dfd);
+   }
 
/*
 * In case there an header with a variable
-- 
2.1.4

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