Re: [U-Boot] [PATCH v3] mmc: add bkops-enable command

2016-11-28 Thread Tomas Melin
Hi Jaehoon,

On 11/28/2016 06:58 AM, Jaehoon Chung wrote:

> 
> Applied on u-boot-mmc.
> Before applied this patch from patchwork, i changed Author from your email to 
> your name, is it ok?
> 
Thanks! Yes that is perfectly ok.

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


Re: [U-Boot] [PATCH 1/6] net: dw: Add read_rom_hwaddr net_op hook

2016-11-28 Thread Olliver Schinagl

On 27-11-16 18:02, Simon Glass wrote:

Hi,

On 25 November 2016 at 08:38, Olliver Schinagl  wrote:

Add the read_rom_hwaddr net_op hook so that it can be called from boards
to read the mac from a ROM chip.

Signed-off-by: Olliver Schinagl 
---
  drivers/net/designware.c | 16 
  1 file changed, 16 insertions(+)

diff --git a/drivers/net/designware.c b/drivers/net/designware.c
index 9e6d726..3f2f67c 100644
--- a/drivers/net/designware.c
+++ b/drivers/net/designware.c
@@ -230,6 +230,21 @@ static int _dw_write_hwaddr(struct dw_eth_dev *priv, u8 
*mac_id)
 return 0;
  }

+__weak int dw_board_read_rom_hwaddr(unsigned char *enetaddr, int id)
+{
+   return -ENOSYS;
+}
+
+static int designware_eth_read_rom_hwaddr(struct udevice *dev)
+{
+   struct eth_pdata *pdata = dev_get_platdata(dev);
+
+   if (!dev)
+   return -ENOSYS;
+
+   return dw_board_read_rom_hwaddr(pdata->enetaddr, dev->seq);
+}
+
  static void dw_adjust_link(struct eth_mac_regs *mac_p,
struct phy_device *phydev)
  {
@@ -685,6 +700,7 @@ static const struct eth_ops designware_eth_ops = {
 .free_pkt   = designware_eth_free_pkt,
 .stop   = designware_eth_stop,
 .write_hwaddr   = designware_eth_write_hwaddr,
+   .read_rom_hwaddr= designware_eth_read_rom_hwaddr,
  };

  static int designware_eth_ofdata_to_platdata(struct udevice *dev)

You should not call board code from a driver. But since this is a
sunxi driver, why not move all the code that reads the serial number
into this file?

Hey Simon,

unless I missunderstand, this is how Joe suggested in a while ago, and 
how it has been implemented in a few other drivers. Can you elaborate a 
bit more?


Olliver


Regards,
Simon



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


Re: [U-Boot] [PATCH] net: zynq_gem: Return 0 on success, not -ENOSYS

2016-11-28 Thread Olliver Schinagl

On 28-11-16 08:22, Michal Simek wrote:

On 25.11.2016 16:41, Olliver Schinagl wrote:

The .read_rom_hwaddr net_ops hook does not check the return value, which
is why it was never caught that we are currently returning 0 if the
read_rom_hwaddr function return -ENOSYS and -ENOSYS otherwise.

In this case we can simplify this by just returning the result of the
function.

Signed-off-by: Olliver Schinagl 
---
  drivers/net/zynq_gem.c | 8 +++-
  1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/net/zynq_gem.c b/drivers/net/zynq_gem.c
index 8b7c1be..04a3fd4 100644
--- a/drivers/net/zynq_gem.c
+++ b/drivers/net/zynq_gem.c
@@ -593,14 +593,12 @@ __weak int zynq_board_read_rom_ethaddr(unsigned char 
*ethaddr)
  
  static int zynq_gem_read_rom_mac(struct udevice *dev)

  {
-   int retval;
struct eth_pdata *pdata = dev_get_platdata(dev);
  
-	retval = zynq_board_read_rom_ethaddr(pdata->enetaddr);

-   if (retval == -ENOSYS)
-   retval = 0;
+   if (!dev)
+   return -ENOSYS;
  
-	return retval;

+   return zynq_board_read_rom_ethaddr(pdata->enetaddr);
  }
  
  static int zynq_gem_miiphy_read(struct mii_dev *bus, int addr,



Not a problem with the patch above but I hope to get rid of this whole
function by using MAC reading from eeprom.
Yeah I agree, once the eeprom bit has matured, this could (in your case 
for your board) be dropped.


Also board specific functions should return error value when read is not
possible.
As an unwritten rule you mean? I think the intention is that 
*_board_read_rom_hwaddr returns 0 on success < 0 on error.


Acked-by: Michal Simek 

Thanks,
Michal



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


Re: [U-Boot] [PATCHv4] Retrieve MAC address from EEPROM

2016-11-28 Thread Olliver Schinagl

On 28-11-16 10:13, Igor Grinberg wrote:

Hi Olliver,

On 11/25/16 17:30, Olliver Schinagl wrote:

[...]


The current idea of the eeprom layout, is to skip the first 8 bytes, so that
other information can be stored there if needed, for example a header with some
magic to identify the EEPROM. Or equivalent purposes.

After those 8 bytes the MAC address follows the first macaddress. The macaddress
is appended by a CRC8 byte and then padded to make for nice 8 bytes. Following
the first macaddress one can store a second, or a third etc etc mac address.

The CRC8 is optional (via a define) but is strongly recommended to have. It
helps preventing user error and more importantly, checks if the bytes read are
actually a user inserted address. E.g. only writing 1 macaddress into the eeprom
but trying to consume 2.

While reading the above, I'm wondering, have you considered the eeprom layout
feature that we have in: common/eeprom/... ?
Last year, when starting this patch series, this did not really exist in 
so far (iirc).


The layout feature was actually designed for these tasks, but in a more generic
way then just Ethernet MAC address.
I did see it and I was quite excited. I think a follow up patch should 
switch over. I did not yet use the new eeprom layout thing as I am 
hoping for Maxime's patches to land first, where he makes the whole 
eeprom interfacing more generic.


What do you think?
I'll have to look at the eeprom layout feature a little more in depth, 
the one thing that was a little 'annoying' (from a short quick glance) 
was that the layout was jumping around a bit (eth0, eth1, something 
else, eth2, eth3). But yes, I was quite intrigued herein.


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


Re: [U-Boot] [PATCH 06/14] net: core: Using an ethernet address from ROM is not bad

2016-11-28 Thread Olliver Schinagl

On 28-11-16 08:59, Michal Simek wrote:

On 25.11.2016 16:30, Olliver Schinagl wrote:

Currently we print a warning if the MAC address is read from
ROM/Hardware. This should not be concidered a bad or erronous thing. A
MAC address should come either from the hardware (ROM) or may be
set/overriden in the environment. Neither is a warning or error case.

Worthy of a warning is the case where both are set, so the user is
atleast aware something special is happening.

Signed-off-by: Olliver Schinagl 
---
  net/eth-uclass.c | 2 --
  1 file changed, 2 deletions(-)

diff --git a/net/eth-uclass.c b/net/eth-uclass.c
index 9703bea..aca3f6d 100644
--- a/net/eth-uclass.c
+++ b/net/eth-uclass.c
@@ -510,8 +510,6 @@ static int eth_post_probe(struct udevice *dev)
memcpy(pdata->enetaddr, env_enetaddr, ARP_HLEN);
} else if (is_valid_ethaddr(pdata->enetaddr)) {
eth_setenv_enetaddr_by_index("eth", dev->seq, pdata->enetaddr);
-   printf("\nWarning: %s using MAC address from ROM\n",
-  dev->name);
} else if (is_zero_ethaddr(pdata->enetaddr)) {
  #ifdef CONFIG_NET_RANDOM_ETHADDR
net_random_ethaddr(pdata->enetaddr);


User should be aware if mac is read from ROM or something else.
Is there a way how to read it without this message to be generated?
I think what we need is a 'source' field here to be printed at the end. 
I do agree the user will want to know WHERE the address came from (and 
what it is). I do think the warning is misplaced here however. There's 
nothing to be warned against.


I'll look into adding the feature that prints the source at the end (as 
detailed as we can).


Thanks,
Michal



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


Re: [U-Boot] [PATCH v2] tools/env: fix environment alignment tests for block devices

2016-11-28 Thread Max Krummenacher
Hi

Any news on this?
The env utility is currently broken for block devices.
Alternatively we could also revert commit
183923d3e412500bdc597d1745e2fb6f7f679ec7.

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


[U-Boot] [RFC PATCH 0/3] spl: Add D-cache support

2016-11-28 Thread Lokesh Vutla
This series tries to add D-cache support in spl in order to reduce boot time
either in 2stage boot or Falcon Boot.

Lokesh Vutla (3):
  arch: arm: omap: Declare size of ddr very early
  spl: reorder the assignment of board info to global data
  spl: Add support for enabling dcache

 arch/arm/include/asm/cache.h|  1 +
 arch/arm/lib/cache-cp15.c   | 46 +
 arch/arm/mach-omap2/am33xx/board.c  |  4 
 arch/arm/mach-omap2/hwinit-common.c |  1 +
 arch/arm/mach-omap2/omap-cache.c| 15 
 common/spl/spl.c| 42 -
 6 files changed, 98 insertions(+), 11 deletions(-)

-- 
2.10.1

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


[U-Boot] [RFC PATCH 1/3] arch: arm: omap: Declare size of ddr very early

2016-11-28 Thread Lokesh Vutla
Declare the size of ddr very early in spl, so that this can be
used to enable cache.

Signed-off-by: Lokesh Vutla 
---
 arch/arm/mach-omap2/am33xx/board.c  | 4 
 arch/arm/mach-omap2/hwinit-common.c | 1 +
 2 files changed, 5 insertions(+)

diff --git a/arch/arm/mach-omap2/am33xx/board.c 
b/arch/arm/mach-omap2/am33xx/board.c
index 5ebeac0..7f445ae 100644
--- a/arch/arm/mach-omap2/am33xx/board.c
+++ b/arch/arm/mach-omap2/am33xx/board.c
@@ -303,6 +303,10 @@ void board_init_f(ulong dummy)
early_system_init();
board_early_init_f();
sdram_init();
+   /* dram_init must store complete ramsize in gd->ram_size */
+   gd->ram_size = get_ram_size(
+   (void *)CONFIG_SYS_SDRAM_BASE,
+   CONFIG_MAX_RAM_BANK_SIZE);
 }
 #endif
 
diff --git a/arch/arm/mach-omap2/hwinit-common.c 
b/arch/arm/mach-omap2/hwinit-common.c
index f317293..cac3274 100644
--- a/arch/arm/mach-omap2/hwinit-common.c
+++ b/arch/arm/mach-omap2/hwinit-common.c
@@ -171,6 +171,7 @@ void board_init_f(ulong dummy)
 #endif
/* For regular u-boot sdram_init() is called from dram_init() */
sdram_init();
+   gd->ram_size = omap_sdram_size();
 }
 #endif
 
-- 
2.10.1

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


[U-Boot] [RFC PATCH 3/3] spl: Add support for enabling dcache

2016-11-28 Thread Lokesh Vutla
Add support for enabling d-cache in SPL. The sequence in SPL tries to
replicate the sequence done in U-Boot except that MMU entries were added
for SRAM.

Signed-off-by: Lokesh Vutla 
---
 arch/arm/include/asm/cache.h |  1 +
 arch/arm/lib/cache-cp15.c| 46 +++-
 arch/arm/mach-omap2/omap-cache.c | 15 +
 common/spl/spl.c | 40 ++
 4 files changed, 92 insertions(+), 10 deletions(-)

diff --git a/arch/arm/include/asm/cache.h b/arch/arm/include/asm/cache.h
index 5400cbe..20f6aca 100644
--- a/arch/arm/include/asm/cache.h
+++ b/arch/arm/include/asm/cache.h
@@ -39,6 +39,7 @@ void arm_init_before_mmu(void);
 void arm_init_domains(void);
 void cpu_cache_initialization(void);
 void dram_bank_mmu_setup(int bank);
+void sram_bank_mmu_setup(phys_addr_t start, phys_addr_t size);
 
 #endif
 
diff --git a/arch/arm/lib/cache-cp15.c b/arch/arm/lib/cache-cp15.c
index e9bbcf5..76f95d6 100644
--- a/arch/arm/lib/cache-cp15.c
+++ b/arch/arm/lib/cache-cp15.c
@@ -94,16 +94,8 @@ void mmu_set_region_dcache_behaviour(phys_addr_t start, 
size_t size,
mmu_page_table_flush(startpt, stoppt);
 }
 
-__weak void dram_bank_mmu_setup(int bank)
+static void set_section_caches(int i)
 {
-   bd_t *bd = gd->bd;
-   int i;
-
-   debug("%s: bank: %d\n", __func__, bank);
-   for (i = bd->bi_dram[bank].start >> MMU_SECTION_SHIFT;
-i < (bd->bi_dram[bank].start >> MMU_SECTION_SHIFT) +
-(bd->bi_dram[bank].size >> MMU_SECTION_SHIFT);
-i++) {
 #if defined(CONFIG_SYS_ARM_CACHE_WRITETHROUGH)
set_section_dcache(i, DCACHE_WRITETHROUGH);
 #elif defined(CONFIG_SYS_ARM_CACHE_WRITEALLOC)
@@ -111,9 +103,33 @@ __weak void dram_bank_mmu_setup(int bank)
 #else
set_section_dcache(i, DCACHE_WRITEBACK);
 #endif
-   }
 }
 
+__weak void dram_bank_mmu_setup(int bank)
+{
+   bd_t *bd = gd->bd;
+   int i;
+
+   debug("%s: bank: %d\n", __func__, bank);
+   for (i = bd->bi_dram[bank].start >> MMU_SECTION_SHIFT;
+i < (bd->bi_dram[bank].start >> MMU_SECTION_SHIFT) +
+(bd->bi_dram[bank].size >> MMU_SECTION_SHIFT); i++)
+   set_section_caches(i);
+}
+
+#if defined(CONFIG_SPL_BUILD) && (defined(CONFIG_SPL_MAX_SIZE) || \
+ defined(CONFIG_SPL_MAX_FOOTPRINT))
+__weak void sram_bank_mmu_setup(phys_addr_t start, phys_addr_t size)
+{
+   int i;
+
+   for (i = start >> MMU_SECTION_SHIFT;
+i < (start >> MMU_SECTION_SHIFT) + (size >> MMU_SECTION_SHIFT);
+i++)
+   set_section_caches(i);
+}
+#endif
+
 /* to activate the MMU we need to set up virtual memory: use 1M areas */
 static inline void mmu_setup(void)
 {
@@ -129,6 +145,16 @@ static inline void mmu_setup(void)
dram_bank_mmu_setup(i);
}
 
+#if defined(CONFIG_SPL_BUILD)
+#if defined(CONFIG_SPL_MAX_SIZE)
+   sram_bank_mmu_setup(CONFIG_SPL_TEXT_BASE,
+   ALIGN(CONFIG_SPL_MAX_SIZE, MMU_SECTION_SIZE));
+#elif defined(CONFIG_SPL_MAX_FOOTPRINT)
+   sram_bank_mmu_setup(CONFIG_SPL_TEXT_BASE,
+   ALIGN(CONFIG_SPL_MAX_FOOTPRINT, MMU_SECTION_SIZE));
+#endif
+#endif
+
 #ifdef CONFIG_ARMV7_LPAE
/* Set up 4 PTE entries pointing to our 4 1GB page tables */
for (i = 0; i < 4; i++) {
diff --git a/arch/arm/mach-omap2/omap-cache.c b/arch/arm/mach-omap2/omap-cache.c
index b37163a..6019e0c 100644
--- a/arch/arm/mach-omap2/omap-cache.c
+++ b/arch/arm/mach-omap2/omap-cache.c
@@ -62,6 +62,21 @@ void dram_bank_mmu_setup(int bank)
set_section_dcache(i, ARMV7_DCACHE_POLICY);
 }
 
+#ifdef CONFIG_SPL_BUILD
+void sram_bank_mmu_setup(phys_addr_t start, phys_addr_t size)
+{
+   int i;
+   phys_addr_t end;
+
+   start = start >> MMU_SECTION_SHIFT;
+   size = size >> MMU_SECTION_SHIFT;
+   end = start + size;
+
+   for (i = start; i <= end; i++)
+   set_section_dcache(i, ARMV7_DCACHE_POLICY);
+}
+#endif
+
 void arm_init_domains(void)
 {
u32 reg;
diff --git a/common/spl/spl.c b/common/spl/spl.c
index 990b700..cdd2917 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -381,6 +381,34 @@ static int spl_load_image(struct spl_image_info 
*spl_image, u32 boot_device)
return -ENODEV;
 }
 
+#if !(defined(CONFIG_SYS_ICACHE_OFF) && defined(CONFIG_SYS_DCACHE_OFF)) && \
+   defined(CONFIG_ARM)
+static int reserve_mmu(void)
+{
+   phys_addr_t ram_top = 0;
+   /* reserve TLB table */
+   gd->arch.tlb_size = PGTABLE_SIZE;
+
+#ifdef CONFIG_SYS_SDRAM_BASE
+   ram_top = CONFIG_SYS_SDRAM_BASE;
+#endif
+   ram_top += get_effective_memsize();
+   gd->arch.tlb_addr = ram_top - gd->arch.tlb_size;
+   debug("TLB table from %08lx to %08lx\n", gd->arch.tlb_addr,
+ gd->arch.tlb_addr + gd->arch.tlb_size);
+   return 0;
+}

[U-Boot] [RFC PATCH 2/3] spl: reorder the assignment of board info to global data

2016-11-28 Thread Lokesh Vutla
Move the assignment of board info to global data a bit early which is safe,
so that ram details can be used to enable caches.

Signed-off-by: Lokesh Vutla 
---
 common/spl/spl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/common/spl/spl.c b/common/spl/spl.c
index bdb165a..990b700 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -394,6 +394,7 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
int i;
 
debug(">>spl:board_init_r()\n");
+   gd->bd = 
 
 #if defined(CONFIG_SYS_SPL_MALLOC_START)
mem_malloc_init(CONFIG_SYS_SPL_MALLOC_START,
@@ -461,7 +462,6 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
  */
 void preloader_console_init(void)
 {
-   gd->bd = 
gd->baudrate = CONFIG_BAUDRATE;
 
serial_init();  /* serial communications setup */
-- 
2.10.1

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


[U-Boot] [PATCH] arch/arm/lib/Makefile: Allow CONFIG_USE_ARCH_MEMSET/MEMCPY with SPL

2016-11-28 Thread Mike Looijmans
CONFIG_USE_ARCH_MEMSET/MEMCPY are inside a "SPL" check, which makes it
impossible to use CONFIG_USE_ARCH_MEMSET combined with a SPL that calls
memset. This patch moves that outside of the "if spl" block, allowing
the code to be used inside SPL.

One use case is that when using ECC on the Zynq platform, all the DDR
RAM must be written to before it's read, otherwise the system will cause
a bus error and hang. Without CONFIG_USE_ARCH_MEMSET it takes over 5
seconds to clear 256MB, enabling CONFIG_USE_ARCH_MEMSET reduces that time
to less than 3 seconds.

Signed-off-by: Mike Looijmans 
---
 arch/arm/lib/Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index 0051f76..eac6a5d 100644
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile
@@ -30,12 +30,12 @@ obj-$(CONFIG_CMD_BOOTI) += bootm.o
 obj-$(CONFIG_CMD_BOOTM) += bootm.o
 obj-$(CONFIG_CMD_BOOTZ) += bootm.o zimage.o
 obj-$(CONFIG_SYS_L2_PL310) += cache-pl310.o
-obj-$(CONFIG_USE_ARCH_MEMSET) += memset.o
-obj-$(CONFIG_USE_ARCH_MEMCPY) += memcpy.o
 else
 obj-$(CONFIG_SPL_FRAMEWORK) += spl.o
 obj-$(CONFIG_SPL_FRAMEWORK) += zimage.o
 endif
+obj-$(CONFIG_USE_ARCH_MEMSET) += memset.o
+obj-$(CONFIG_USE_ARCH_MEMCPY) += memcpy.o
 obj-$(CONFIG_SEMIHOSTING) += semihosting.o
 
 obj-y  += sections.o
-- 
1.9.1

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


Re: [U-Boot] [PATCH] cmd: usb: run 'usb start' when USB is stopped

2016-11-28 Thread Jaehoon Chung
On 11/28/2016 05:11 PM, Hans de Goede wrote:
> Hi,
> 
> On 28-11-16 07:54, Minkyu Kang wrote:
>> Hi Jaehoon,
>>
>> On 28/11/16 14:08, Jaehoon Chung wrote:
>>> Hi Marek,
>>>
>>> On 09/23/2016 01:15 PM, Simon Glass wrote:
 +Marek

 On 9 September 2016 at 04:20, Jaehoon Chung  wrote:
> If USB is stopped, just run 'usb start' instead of printing message.
> Then user didn't consider whether usb is started or stopped.
>>>
>>> Do you have any other opinion for this? :)
>>>
>>> Best Regards,
>>> Jaehoon Chung
>>>
>
> Signed-off-by: Jaehoon Chung 
> ---
>  cmd/usb.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/cmd/usb.c b/cmd/usb.c
> index 455127c..4970851 100644
> --- a/cmd/usb.c
> +++ b/cmd/usb.c
> @@ -651,8 +651,8 @@ static int do_usb(cmd_tbl_t *cmdtp, int flag, int 
> argc, char * const argv[])
> return 0;
> }
> if (!usb_started) {
> -   printf("USB is stopped. Please issue 'usb start' 
> first.\n");
> -   return 1;
> +   printf("USB is stopped. Running 'usb start' first.\n");
> +   do_usb_start();
> }
>>
>> It seems to ambiguous whether initialization was succeed or not.
> 
> Right at a minimum it should detect that do_usb_start succeeds. E.g.
> on an otg port without an otg -> usb-host cable plugged in it will not
> succeed.

Got it..Then discard this patch. Thanks for pointing out. 

Best Regards,
Jaehoon Chung

> 
> Regards,
> 
> Hans
> 
> 
> 

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


[U-Boot] [PATCH 4/4] env_sf: use DIV_ROUND_UP to calculate number of sectors to erase

2016-11-28 Thread Andreas Fenkart
simpler, needs less thinking when reading the code

Signed-off-by: Andreas Fenkart 
---
 common/env_sf.c | 18 +-
 1 file changed, 5 insertions(+), 13 deletions(-)

diff --git a/common/env_sf.c b/common/env_sf.c
index 8a3de63..0434bb8 100644
--- a/common/env_sf.c
+++ b/common/env_sf.c
@@ -79,7 +79,7 @@ int saveenv(void)
 {
env_t   env_new;
char*saved_buffer = NULL, flag = OBSOLETE_FLAG;
-   u32 saved_size, saved_offset, sector = 1;
+   u32 saved_size, saved_offset, sector;
int ret;
 
ret = setup_flash_device();
@@ -114,11 +114,7 @@ int saveenv(void)
goto done;
}
 
-   if (CONFIG_ENV_SIZE > CONFIG_ENV_SECT_SIZE) {
-   sector = CONFIG_ENV_SIZE / CONFIG_ENV_SECT_SIZE;
-   if (CONFIG_ENV_SIZE % CONFIG_ENV_SECT_SIZE)
-   sector++;
-   }
+   sector = DIV_ROUND_UP(CONFIG_ENV_SIZE, CONFIG_ENV_SECT_SIZE);
 
puts("Erasing SPI flash...");
ret = spi_flash_erase(env_flash, env_new_offset,
@@ -244,7 +240,7 @@ out:
 #else
 int saveenv(void)
 {
-   u32 saved_size, saved_offset, sector = 1;
+   u32 saved_size, saved_offset, sector;
char*saved_buffer = NULL;
int ret = 1;
env_t   env_new;
@@ -267,16 +263,12 @@ int saveenv(void)
goto done;
}
 
-   if (CONFIG_ENV_SIZE > CONFIG_ENV_SECT_SIZE) {
-   sector = CONFIG_ENV_SIZE / CONFIG_ENV_SECT_SIZE;
-   if (CONFIG_ENV_SIZE % CONFIG_ENV_SECT_SIZE)
-   sector++;
-   }
-
ret = env_export(_new);
if (ret)
goto done;
 
+   sector = DIV_ROUND_UP(CONFIG_ENV_SIZE, CONFIG_ENV_SECT_SIZE);
+
puts("Erasing SPI flash...");
ret = spi_flash_erase(env_flash, CONFIG_ENV_OFFSET,
sector * CONFIG_ENV_SECT_SIZE);
-- 
2.10.1

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


[U-Boot] [PATCH 2/4] enf_sf: reuse setup_flash_device instead of open coding it

2016-11-28 Thread Andreas Fenkart
setup_flash_device selects one of two code paths depending on the driver
model being used (=CONFIG_DM_SPI_FLASH). env_relocate_spec only used
the non driver-model code path. I'm unsure why, either none of the
platforms that need relocation use the driver model, or - worse - the
driver model is not yet usable when relocating.

Signed-off-by: Andreas Fenkart 
---
 common/env_sf.c | 14 +-
 1 file changed, 5 insertions(+), 9 deletions(-)

diff --git a/common/env_sf.c b/common/env_sf.c
index 5126762..ba9ac8a 100644
--- a/common/env_sf.c
+++ b/common/env_sf.c
@@ -175,12 +175,9 @@ void env_relocate_spec(void)
goto out;
}
 
-   env_flash = spi_flash_probe(CONFIG_ENV_SPI_BUS, CONFIG_ENV_SPI_CS,
-   CONFIG_ENV_SPI_MAX_HZ, CONFIG_ENV_SPI_MODE);
-   if (!env_flash) {
-   set_default_env("!spi_flash_probe() failed");
+   ret = setup_flash_device();
+   if (ret)
goto out;
-   }
 
ret = spi_flash_read(env_flash, CONFIG_ENV_OFFSET,
CONFIG_ENV_SIZE, tmp_env1);
@@ -315,10 +312,9 @@ void env_relocate_spec(void)
char *buf = NULL;
 
buf = (char *)memalign(ARCH_DMA_MINALIGN, CONFIG_ENV_SIZE);
-   env_flash = spi_flash_probe(CONFIG_ENV_SPI_BUS, CONFIG_ENV_SPI_CS,
-   CONFIG_ENV_SPI_MAX_HZ, CONFIG_ENV_SPI_MODE);
-   if (!env_flash) {
-   set_default_env("!spi_flash_probe() failed");
+
+   ret = setup_flash_device();
+   if (ret) {
if (buf)
free(buf);
return;
-- 
2.10.1

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


[U-Boot] [PATCH 1/4] env_sf: factor out prepare_flash_device

2016-11-28 Thread Andreas Fenkart
copy code found in single/double buffered code path

Signed-off-by: Andreas Fenkart 
---
 common/env_sf.c | 47 ++-
 1 file changed, 18 insertions(+), 29 deletions(-)

diff --git a/common/env_sf.c b/common/env_sf.c
index c53200f..5126762 100644
--- a/common/env_sf.c
+++ b/common/env_sf.c
@@ -45,13 +45,8 @@ char *env_name_spec = "SPI Flash";
 
 static struct spi_flash *env_flash;
 
-#if defined(CONFIG_ENV_OFFSET_REDUND)
-int saveenv(void)
+static int setup_flash_device(void)
 {
-   env_t   env_new;
-   char*saved_buffer = NULL, flag = OBSOLETE_FLAG;
-   u32 saved_size, saved_offset, sector = 1;
-   int ret;
 #ifdef CONFIG_DM_SPI_FLASH
struct udevice *new;
 
@@ -76,6 +71,20 @@ int saveenv(void)
}
}
 #endif
+   return 0;
+}
+
+#if defined(CONFIG_ENV_OFFSET_REDUND)
+int saveenv(void)
+{
+   env_t   env_new;
+   char*saved_buffer = NULL, flag = OBSOLETE_FLAG;
+   u32 saved_size, saved_offset, sector = 1;
+   int ret;
+
+   ret = setup_flash_device();
+   if (ret)
+   return ret;
 
ret = env_export(_new);
if (ret)
@@ -242,30 +251,10 @@ int saveenv(void)
char*saved_buffer = NULL;
int ret = 1;
env_t   env_new;
-#ifdef CONFIG_DM_SPI_FLASH
-   struct udevice *new;
-
-   /* speed and mode will be read from DT */
-   ret = spi_flash_probe_bus_cs(CONFIG_ENV_SPI_BUS, CONFIG_ENV_SPI_CS,
-0, 0, );
-   if (ret) {
-   set_default_env("!spi_flash_probe_bus_cs() failed");
-   return 1;
-   }
 
-   env_flash = dev_get_uclass_priv(new);
-#else
-
-   if (!env_flash) {
-   env_flash = spi_flash_probe(CONFIG_ENV_SPI_BUS,
-   CONFIG_ENV_SPI_CS,
-   CONFIG_ENV_SPI_MAX_HZ, CONFIG_ENV_SPI_MODE);
-   if (!env_flash) {
-   set_default_env("!spi_flash_probe() failed");
-   return 1;
-   }
-   }
-#endif
+   ret = setup_flash_device();
+   if (ret)
+   return ret;
 
/* Is the sector larger than the env (i.e. embedded) */
if (CONFIG_ENV_SECT_SIZE > CONFIG_ENV_SIZE) {
-- 
2.10.1

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


[U-Boot] [PATCH 3/4] env_sf: re-order error handling in single-buffer env_relocate_spec

2016-11-28 Thread Andreas Fenkart
this makes it easier comparable to the double-buffered version

Signed-off-by: Andreas Fenkart 
---
 common/env_sf.c | 20 +++-
 1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/common/env_sf.c b/common/env_sf.c
index ba9ac8a..8a3de63 100644
--- a/common/env_sf.c
+++ b/common/env_sf.c
@@ -312,29 +312,31 @@ void env_relocate_spec(void)
char *buf = NULL;
 
buf = (char *)memalign(ARCH_DMA_MINALIGN, CONFIG_ENV_SIZE);
-
-   ret = setup_flash_device();
-   if (ret) {
-   if (buf)
-   free(buf);
+   if (!buf) {
+   set_default_env("!malloc() failed");
return;
}
 
+   ret = setup_flash_device();
+   if (ret)
+   goto out;
+
ret = spi_flash_read(env_flash,
CONFIG_ENV_OFFSET, CONFIG_ENV_SIZE, buf);
if (ret) {
set_default_env("!spi_flash_read() failed");
-   goto out;
+   goto err_read;
}
 
ret = env_import(buf, 1);
if (ret)
gd->env_valid = 1;
-out:
+
+err_read:
spi_flash_free(env_flash);
-   if (buf)
-   free(buf);
env_flash = NULL;
+out:
+   free(buf);
 }
 #endif
 
-- 
2.10.1

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


[U-Boot] [PATCH 0/4] env_sf: minor cleanup

2016-11-28 Thread Andreas Fenkart
Andreas Fenkart (4):
  env_sf: factor out prepare_flash_device
  enf_sf: reuse setup_flash_device instead of open coding it
  env_sf: re-order error handling in single-buffer env_relocate_spec
  env_sf: use DIV_ROUND_UP to calculate number of sectors to erase

 common/env_sf.c | 91 ++---
 1 file changed, 35 insertions(+), 56 deletions(-)

-- 
2.10.1

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


Re: [U-Boot] [PATCH] ARM: dts: am437x-idk: Fix QSPI compatible string

2016-11-28 Thread Vignesh R


On Tuesday 22 November 2016 01:35 PM, Vignesh R wrote:
> 
> 
> On Monday 21 November 2016 11:33 PM, Jagan Teki wrote:
>> On Mon, Nov 21, 2016 at 10:07 AM, Vignesh R  wrote:
>>> Hi Jagan,
>>>
>>> On Thursday 13 October 2016 06:24 PM, Tom Rini wrote:
 On Thu, Oct 13, 2016 at 05:45:52PM +0530, Jagan Teki wrote:
> On Thu, Oct 13, 2016 at 3:53 PM, Vignesh R  wrote:
>> Unlike Linux kernel, U-Boot depends on "spi-flash" compatible to probe
>> m25p80 spi-nor devices. Hence, add "spi-flash" compatible string to
>> m25p80 node. Without this patch, flash device DT data is not parsed and
>> QSPI operates in unsupported mode leading to data corruption.
>>
>> Signed-off-by: Vignesh R 
>
> Applied to u-boot-spi/master

 ... I don't like that we need a non u-boot prefixed string here for the
 binding to work as that will lead to harder re-syncs later on the dt
 files.  Why aren't we matching on the existing part?  Thanks!

>>>
>>> I don't see this patch in u-boot master yet. If this patch was dropped
>>> due to Tom's comment above, then could you suggest how to address the issue?
>>
>> Some how missed this, but do you still unable to probe the flash w/o
>> "spi-flash"? I think there is a device_probe when !device_active(dev)
>> that will detect the flash chip. Please try once.
>>
> 
> Yes, the flash is detected. But the device is not bound due to missing
> "spi-flash" compatible and hence DT properties of flash node are not
> available to the driver. So, the QSPI controller tries to operate in
> mode 0 instead of mode 3 and default frequency instead of 48MHz as
> specified by spi-max-frequency property leading to failure of flashing
> operations.
> 

In case its not clear from above explanation, this patch is still
_needed_ in order for DT properties to be picked up. Without this QSPI
write operations fail on am437x. Can this patch be picked up for this rc?



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


Re: [U-Boot] [PATCH v2] spi: cadence_qspi_apb: Use 32 bit indirect write transaction when possible

2016-11-28 Thread Vignesh R


On Friday 25 November 2016 10:21 PM, Marek Vasut wrote:
> On 11/24/2016 06:35 AM, Vignesh R wrote:
>> According to Section 11.15.4.9.2 Indirect Write Controller of K2G SoC
>> TRM SPRUHY8D[1], the external master is only permitted to issue 32-bit
>> data interface writes until the last word of an indirect transfer
>> otherwise indirect writes is known to fails sometimes. So, make sure
>> that QSPI indirect writes are 32 bit sized except for the last write. If
>> the txbuf is unaligned then use bounce buffer to avoid data aborts.
>>
>> So, now that the driver uses bounce_buffer, enable CONFIG_BOUNCE_BUFFER
>> for all boards that use Cadence QSPI driver.
>>
>> [1]www.ti.com/lit/ug/spruhy8d/spruhy8d.pdf
>>
>> Signed-off-by: Vignesh R 
>> ---
> 
> Reviewed-by: Marek Vasut 
> 
> I'd like to have at least Dinh's/Chin's ack on this.
> 
> btw don't you need BB for READ as well ?
> 

I don't see any issue with READ due to non word size accesses ATM,
anyways I am working on patch to use BB for READ. Will post that separately.

Thanks for the review!

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


Re: [U-Boot] [PATCH v2] spi: cadence_qspi_apb: Use 32 bit indirect write transaction when possible

2016-11-28 Thread Vignesh R


On Friday 25 November 2016 11:18 PM, Jagan Teki wrote:
 >>> diff --git a/include/configs/k2g_evm.h b/include/configs/k2g_evm.h
 >>> index a14544526c71..1d603e0c002f 100644
 >>> --- a/include/configs/k2g_evm.h
 >>> +++ b/include/configs/k2g_evm.h
 >>> @@ -79,6 +79,7 @@
 >>>  #define CONFIG_CADENCE_QSPI
 >>>  #define CONFIG_CQSPI_REF_CLK 38400
 >>>  #define CONFIG_CQSPI_DECODER 0x0
 >>> +#define CONFIG_BOUNCE_BUFFER
>>> >>
>>> >> Better define this on Kconfig and add it on defconfig.
>> >
>> > Such change is unrelated to this patch and should be fixed in a
>> > separate/subsequent one.
> Agreed it should be a separate patch.

Yes, that should be separate series. There are a bunch of drivers and
couple of architectures using CONFIG_BOUNCE_BUFFER, hence the change is
not trivial.

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


Re: [U-Boot] [PATCH v2] tools/env: fix environment alignment tests for block devices

2016-11-28 Thread Andreas Fenkart

Hi Max,

LGTM, see one nit below, can fixed later

On 11/19/2016 01:58 PM, Max Krummenacher wrote:

commit 183923d3e412500bdc597d1745e2fb6f7f679ec7 enforces that the
environment must start at an erase block boundary.

For block devices the sample fw_env.config does not mandate a erase block size
for block devices. A missing setting defaults to the full env size.

Depending on the environment location the alignment check now errors out for
perfectly legal settings.

Fix this by defaulting to the standard blocksize of 0x200 for environments
stored in a block device.
That keeps the fw_env.config files for block devices working even with that
new check.

Signed-off-by: Max Krummenacher 

---

Changes in v2:
- move default value handling from parse_config(), get_config() to
   check_device_config(), so that !defined(CONFIG_FILE) is covered also.
- use DIV_ROUND_UP instead of doing this manually
- move the check after the setting of default values in check_device_config().
- use 0 as the marker for default values to be used.

  tools/env/fw_env.c | 60 ++
  1 file changed, 33 insertions(+), 27 deletions(-)

diff --git a/tools/env/fw_env.c b/tools/env/fw_env.c
index 3dc0d53..862a0b1 100644
--- a/tools/env/fw_env.c
+++ b/tools/env/fw_env.c
@@ -1291,18 +1291,6 @@ static int check_device_config(int dev)
struct stat st;
int fd, rc = 0;
  
-	if (DEVOFFSET(dev) % DEVESIZE(dev) != 0) {

-   fprintf(stderr, "Environment does not start on (erase) block 
boundary\n");
-   errno = EINVAL;
-   return -1;
-   }
-
-   if (ENVSIZE(dev) > ENVSECTORS(dev) * DEVESIZE(dev)) {
-   fprintf(stderr, "Environment does not fit into available 
sectors\n");
-   errno = EINVAL;
-   return -1;
-   }
-
fd = open(DEVNAME(dev), O_RDONLY);
if (fd < 0) {
fprintf(stderr,
@@ -1335,9 +1323,15 @@ static int check_device_config(int dev)
goto err;
}
DEVTYPE(dev) = mtdinfo.type;
+   if (DEVESIZE(dev) == 0)
+   /* Assume the erase size is the same as the env-size */
+   DEVESIZE(dev) = ENVSIZE(dev);
Since we already checked for character devices, we could use the 
mtdinfo.erasesize. I guess we can relay on mtdinfo on new kernels, and 
if not there is still the fallback to specify it in fw_env.config.



} else {
uint64_t size;
DEVTYPE(dev) = MTD_ABSENT;
+   if (DEVESIZE(dev) == 0)
+   /* Assume the erase size to be 512 bytes */
+   DEVESIZE(dev) = 0x200;
It doesn't even matter. In case of MTD_ABSENT, erasize is never used 
itself, only the tuple (DEVESIZE * ENVSECTORS) matters.


  
  		/*

 * Check for negative offsets, treat it as backwards offset
@@ -1359,6 +1353,22 @@ static int check_device_config(int dev)
}
}
  
+	if (ENVSECTORS(dev) == 0)

+   /* Assume enough sectors to cover the environment */
+   ENVSECTORS(dev) = DIV_ROUND_UP(ENVSIZE(dev), DEVESIZE(dev));
+
+   if (DEVOFFSET(dev) % DEVESIZE(dev) != 0) {
+   fprintf(stderr, "Environment does not start on (erase) block 
boundary\n");
+   errno = EINVAL;
+   return -1;
+   }
+
+   if (ENVSIZE(dev) > ENVSECTORS(dev) * DEVESIZE(dev)) {
+   fprintf(stderr, "Environment does not fit into available 
sectors\n");
+   errno = EINVAL;
+   return -1;
+   }
+
  err:
close(fd);
return rc;
@@ -1382,10 +1392,10 @@ static int parse_config(struct env_opts *opts)
DEVNAME (0) = DEVICE1_NAME;
DEVOFFSET (0) = DEVICE1_OFFSET;
ENVSIZE (0) = ENV1_SIZE;
-   /* Default values are: erase-size=env-size */
-   DEVESIZE (0) = ENVSIZE (0);
-   /* #sectors=env-size/erase-size (rounded up) */
-   ENVSECTORS (0) = (ENVSIZE(0) + DEVESIZE(0) - 1) / DEVESIZE(0);
+
+   /* Set defaults for DEVESIZE, ENVSECTORS later once we
+* know DEVTYPE
+*/
  #ifdef DEVICE1_ESIZE
DEVESIZE (0) = DEVICE1_ESIZE;
  #endif
@@ -1397,10 +1407,10 @@ static int parse_config(struct env_opts *opts)
DEVNAME (1) = DEVICE2_NAME;
DEVOFFSET (1) = DEVICE2_OFFSET;
ENVSIZE (1) = ENV2_SIZE;
-   /* Default values are: erase-size=env-size */
-   DEVESIZE (1) = ENVSIZE (1);
-   /* #sectors=env-size/erase-size (rounded up) */
-   ENVSECTORS (1) = (ENVSIZE(1) + DEVESIZE(1) - 1) / DEVESIZE(1);
+
+   /* Set defaults for DEVESIZE, ENVSECTORS later once we
+* know DEVTYPE
+*/
  #ifdef DEVICE2_ESIZE
DEVESIZE (1) = DEVICE2_ESIZE;
  #endif
@@ -1466,13 +1476,9 @@ static int get_config (char *fname)
  
  		DEVNAME(i) = devname;
  
-		if (rc < 4)

-   /* 

Re: [U-Boot] [PATCH] ARM: dts: am437x-idk: Fix QSPI compatible string

2016-11-28 Thread Jagan Teki
On Mon, Nov 28, 2016 at 3:04 PM, Vignesh R  wrote:
>
>
> On Tuesday 22 November 2016 01:35 PM, Vignesh R wrote:
>>
>>
>> On Monday 21 November 2016 11:33 PM, Jagan Teki wrote:
>>> On Mon, Nov 21, 2016 at 10:07 AM, Vignesh R  wrote:
 Hi Jagan,

 On Thursday 13 October 2016 06:24 PM, Tom Rini wrote:
> On Thu, Oct 13, 2016 at 05:45:52PM +0530, Jagan Teki wrote:
>> On Thu, Oct 13, 2016 at 3:53 PM, Vignesh R  wrote:
>>> Unlike Linux kernel, U-Boot depends on "spi-flash" compatible to probe
>>> m25p80 spi-nor devices. Hence, add "spi-flash" compatible string to
>>> m25p80 node. Without this patch, flash device DT data is not parsed and
>>> QSPI operates in unsupported mode leading to data corruption.
>>>
>>> Signed-off-by: Vignesh R 
>>
>> Applied to u-boot-spi/master
>
> ... I don't like that we need a non u-boot prefixed string here for the
> binding to work as that will lead to harder re-syncs later on the dt
> files.  Why aren't we matching on the existing part?  Thanks!
>

 I don't see this patch in u-boot master yet. If this patch was dropped
 due to Tom's comment above, then could you suggest how to address the 
 issue?
>>>
>>> Some how missed this, but do you still unable to probe the flash w/o
>>> "spi-flash"? I think there is a device_probe when !device_active(dev)
>>> that will detect the flash chip. Please try once.
>>>
>>
>> Yes, the flash is detected. But the device is not bound due to missing
>> "spi-flash" compatible and hence DT properties of flash node are not
>> available to the driver. So, the QSPI controller tries to operate in
>> mode 0 instead of mode 3 and default frequency instead of 48MHz as
>> specified by spi-max-frequency property leading to failure of flashing
>> operations.
>>
>
> In case its not clear from above explanation, this patch is still
> _needed_ in order for DT properties to be picked up. Without this QSPI
> write operations fail on am437x. Can this patch be picked up for this rc?

Will pick.

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 4/4] imx: mx6sxsabreauto: enable more dm drivers

2016-11-28 Thread Peng Fan
Enable MMC/I2C/GPIO/PMIC/REGULATOR/PCA953X DM drivers
for mx6sxsabreauto board. Drop non-DM code.

Note:
The i.MX DM drivers has such dependency.
  MXC GPIO -> MXC I2C -> PFUZE/REGULATOR
  MXC GPIO -> PCA953X
  MXC GPIO -> FSL_USDHC

So the drivers needs to be enabled all to avoid
compiling error.

The uboot dm tree log:
=> dm tree
 Class   Probed   Name
 
  root[ + ]root_driver
  thermal [   ]|-- imx_thermal
  simple_bus  [ + ]|-- soc
  simple_bus  [ + ]|   |-- aips-bus@0200
  simple_bus  [   ]|   |   |-- spba-bus@0200
  gpio[ + ]|   |   |-- gpio@0209c000
  gpio[ + ]|   |   |-- gpio@020a
  gpio[ + ]|   |   |-- gpio@020a4000
  gpio[ + ]|   |   |-- gpio@020a8000
  gpio[ + ]|   |   |-- gpio@020ac000
  gpio[ + ]|   |   |-- gpio@020b
  gpio[ + ]|   |   |-- gpio@020b4000
  simple_bus  [   ]|   |   |-- anatop@020c8000
  simple_bus  [   ]|   |   |-- snvs@020cc000
  pinctrl [ + ]|   |   `-- iomuxc@020e
  pinconfig   [ + ]|   |   `-- imx6x-sabreauto
  pinconfig   [ + ]|   |   |-- i2c2grp-1
  pinconfig   [ + ]|   |   |-- i2c3grp-2
  pinconfig   [   ]|   |   |-- uart1grp
  pinconfig   [ + ]|   |   |-- usdhc3grp
  pinconfig   [   ]|   |   |-- usdhc3grp-100mhz
  pinconfig   [   ]|   |   |-- usdhc3grp-200mhz
  pinconfig   [ + ]|   |   |-- usdhc4grp
  pinconfig   [ + ]|   |   `-- vccsd3grp
  simple_bus  [ + ]|   |-- aips-bus@0210
  mmc [ + ]|   |   |-- usdhc@02198000
  mmc [ + ]|   |   |-- usdhc@0219c000
  i2c [ + ]|   |   |-- i2c@021a4000
  i2c_generic [ + ]|   |   |   |-- generic_8
  i2c_generic [ + ]|   |   |   `-- generic_4e
  i2c [ + ]|   |   `-- i2c@021a8000
  gpio[ + ]|   |   |-- gpio@30
  gpio[ + ]|   |   `-- gpio@32
  simple_bus  [   ]|   `-- aips-bus@0220
  simple_bus  [   ]|   `-- spba-bus@0220
  simple_bus  [ + ]`-- regulators
  regulator   [ + ]`-- regulator@0

Signed-off-by: Peng Fan 
Cc: Stefano Babic 
---
 board/freescale/mx6sxsabreauto/mx6sxsabreauto.c | 258 +---
 configs/mx6sxsabreauto_defconfig|  13 ++
 include/configs/mx6sxsabreauto.h|   7 -
 3 files changed, 69 insertions(+), 209 deletions(-)

diff --git a/board/freescale/mx6sxsabreauto/mx6sxsabreauto.c 
b/board/freescale/mx6sxsabreauto/mx6sxsabreauto.c
index 44e6a7d..e7ab810 100644
--- a/board/freescale/mx6sxsabreauto/mx6sxsabreauto.c
+++ b/board/freescale/mx6sxsabreauto/mx6sxsabreauto.c
@@ -16,12 +16,9 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
 #include 
 #include 
@@ -37,15 +34,6 @@ DECLARE_GLOBAL_DATA_PTR;
PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED |   \
PAD_CTL_DSE_40ohm   | PAD_CTL_SRE_FAST  | PAD_CTL_HYS)
 
-#define USDHC_PAD_CTRL (PAD_CTL_PKE | PAD_CTL_PUE |\
-   PAD_CTL_PUS_22K_UP  | PAD_CTL_SPEED_LOW |   \
-   PAD_CTL_DSE_80ohm   | PAD_CTL_SRE_FAST  | PAD_CTL_HYS)
-
-#define I2C_PAD_CTRL(PAD_CTL_PKE | PAD_CTL_PUE |\
-   PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED |   \
-   PAD_CTL_DSE_40ohm | PAD_CTL_HYS |   \
-   PAD_CTL_ODE)
-
 #define ENET_PAD_CTRL  (PAD_CTL_PUS_100K_UP | PAD_CTL_PUE | \
PAD_CTL_SPEED_HIGH   |   \
PAD_CTL_DSE_48ohm   | PAD_CTL_SRE_FAST)
@@ -56,54 +44,11 @@ DECLARE_GLOBAL_DATA_PTR;
 #define ENET_RX_PAD_CTRL  (PAD_CTL_PKE | PAD_CTL_PUE |  \
PAD_CTL_SPEED_HIGH   | PAD_CTL_SRE_FAST)
 
-#define I2C_PMIC   1
-
 #define GPMI_PAD_CTRL0 (PAD_CTL_PKE | PAD_CTL_PUE | PAD_CTL_PUS_100K_UP)
 #define GPMI_PAD_CTRL1 (PAD_CTL_DSE_40ohm | PAD_CTL_SPEED_MED | \
PAD_CTL_SRE_FAST)
 #define GPMI_PAD_CTRL2 (GPMI_PAD_CTRL0 | GPMI_PAD_CTRL1)
 
-/*Define for building port exp gpio, pin starts from 0*/
-#define PORTEXP_IO_NR(chip, pin) \
-   ((chip << 5) + pin)
-
-/*Get the chip addr from a ioexp gpio*/
-#define PORTEXP_IO_TO_CHIP(gpio_nr) \
-   (gpio_nr >> 5)
-
-/*Get the pin number from a ioexp gpio*/
-#define PORTEXP_IO_TO_PIN(gpio_nr) \
-   (gpio_nr & 0x1f)
-
-#define CPU_PER_RST_B  PORTEXP_IO_NR(0x30, 4)
-#define STEER_ENET PORTEXP_IO_NR(0x32, 2)
-
-static int port_exp_direction_output(unsigned gpio, int value)
-{
-   int ret;
-
-   i2c_set_bus_num(2);
-   ret = i2c_probe(PORTEXP_IO_TO_CHIP(gpio));
-   if (ret)
-   return ret;
-
-   ret = pca953x_set_dir(PORTEXP_IO_TO_CHIP(gpio),
-   (1 << PORTEXP_IO_TO_PIN(gpio)),
-   (PCA953X_DIR_OUT << PORTEXP_IO_TO_PIN(gpio)));
-
-   if (ret)

Re: [U-Boot] [PATCH 06/14] net: core: Using an ethernet address from ROM is not bad

2016-11-28 Thread Olliver Schinagl


On November 28, 2016 12:06:37 PM CET, Michal Simek  
wrote:
>On 28.11.2016 11:48, Olliver Schinagl wrote:
>> On 28-11-16 08:59, Michal Simek wrote:
>>> On 25.11.2016 16:30, Olliver Schinagl wrote:
 Currently we print a warning if the MAC address is read from
 ROM/Hardware. This should not be concidered a bad or erronous
>thing. A
 MAC address should come either from the hardware (ROM) or may be
 set/overriden in the environment. Neither is a warning or error
>case.

 Worthy of a warning is the case where both are set, so the user is
 atleast aware something special is happening.

 Signed-off-by: Olliver Schinagl 
 ---
   net/eth-uclass.c | 2 --
   1 file changed, 2 deletions(-)

 diff --git a/net/eth-uclass.c b/net/eth-uclass.c
 index 9703bea..aca3f6d 100644
 --- a/net/eth-uclass.c
 +++ b/net/eth-uclass.c
 @@ -510,8 +510,6 @@ static int eth_post_probe(struct udevice *dev)
   memcpy(pdata->enetaddr, env_enetaddr, ARP_HLEN);
   } else if (is_valid_ethaddr(pdata->enetaddr)) {
   eth_setenv_enetaddr_by_index("eth", dev->seq,
 pdata->enetaddr);
 -printf("\nWarning: %s using MAC address from ROM\n",
 -   dev->name);
   } else if (is_zero_ethaddr(pdata->enetaddr)) {
   #ifdef CONFIG_NET_RANDOM_ETHADDR
   net_random_ethaddr(pdata->enetaddr);

>>> User should be aware if mac is read from ROM or something else.
>>> Is there a way how to read it without this message to be generated?
>> I think what we need is a 'source' field here to be printed at the
>end.
>> I do agree the user will want to know WHERE the address came from
>(and
>> what it is). I do think the warning is misplaced here however.
>There's
>> nothing to be warned against.
>> 
>> I'll look into adding the feature that prints the source at the end
>(as
>> detailed as we can).
>
>Maybe enough here to remove that Warning from print message.
Well a later patch in this series does print it per interface.

Hence why my suggestion to add the source/from.

Olliver

>
>Thanks,
>Michal

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 06/14] net: core: Using an ethernet address from ROM is not bad

2016-11-28 Thread Michal Simek
On 28.11.2016 12:08, Olliver Schinagl wrote:
> 
> 
> On November 28, 2016 12:06:37 PM CET, Michal Simek  
> wrote:
>> On 28.11.2016 11:48, Olliver Schinagl wrote:
>>> On 28-11-16 08:59, Michal Simek wrote:
 On 25.11.2016 16:30, Olliver Schinagl wrote:
> Currently we print a warning if the MAC address is read from
> ROM/Hardware. This should not be concidered a bad or erronous
>> thing. A
> MAC address should come either from the hardware (ROM) or may be
> set/overriden in the environment. Neither is a warning or error
>> case.
>
> Worthy of a warning is the case where both are set, so the user is
> atleast aware something special is happening.
>
> Signed-off-by: Olliver Schinagl 
> ---
>   net/eth-uclass.c | 2 --
>   1 file changed, 2 deletions(-)
>
> diff --git a/net/eth-uclass.c b/net/eth-uclass.c
> index 9703bea..aca3f6d 100644
> --- a/net/eth-uclass.c
> +++ b/net/eth-uclass.c
> @@ -510,8 +510,6 @@ static int eth_post_probe(struct udevice *dev)
>   memcpy(pdata->enetaddr, env_enetaddr, ARP_HLEN);
>   } else if (is_valid_ethaddr(pdata->enetaddr)) {
>   eth_setenv_enetaddr_by_index("eth", dev->seq,
> pdata->enetaddr);
> -printf("\nWarning: %s using MAC address from ROM\n",
> -   dev->name);
>   } else if (is_zero_ethaddr(pdata->enetaddr)) {
>   #ifdef CONFIG_NET_RANDOM_ETHADDR
>   net_random_ethaddr(pdata->enetaddr);
>
 User should be aware if mac is read from ROM or something else.
 Is there a way how to read it without this message to be generated?
>>> I think what we need is a 'source' field here to be printed at the
>> end.
>>> I do agree the user will want to know WHERE the address came from
>> (and
>>> what it is). I do think the warning is misplaced here however.
>> There's
>>> nothing to be warned against.
>>>
>>> I'll look into adding the feature that prints the source at the end
>> (as
>>> detailed as we can).
>>
>> Maybe enough here to remove that Warning from print message.
> Well a later patch in this series does print it per interface.
> 
> Hence why my suggestion to add the source/from.

Definitely nice prints and if you add source/from part I will be happy
with it.

Thanks,
Michal


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


<    1   2