date:20140917

Hi Simon,

On 09/17/14 06:51, Simon Glass wrote:
 Now that some initcall functions return a useful error number, display it
 when something goes wrong.
 
 Signed-off-by: Simon Glass s...@chromium.org

This is a great addition! Thanks!
Acked-by: Igor Grinberg grinb...@compulab.co.il


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

[U-Boot] [PATCH] usb: gadget: fastboot: improve download progress bar

2014-09-17 Thread Bo Shen

When download is ongoing, if the actual size of one transfer
is not the same as BTYES_PER_DOT, which will cause the dot
won't print anymore. Then it will let the user thinking it
is stuck, actually it is transfering without dot printed.

So, improve the method to show the progress bar (print dot).

Signed-off-by: Bo Shen voice.s...@atmel.com
---

 drivers/usb/gadget/f_fastboot.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/f_fastboot.c b/drivers/usb/gadget/f_fastboot.c
index 7a1acb9..2f13bf0 100644
--- a/drivers/usb/gadget/f_fastboot.c
+++ b/drivers/usb/gadget/f_fastboot.c
@@ -51,6 +51,7 @@ static inline struct f_fastboot *func_to_fastboot(struct 
usb_function *f)
 static struct f_fastboot *fastboot_func;
 static unsigned int download_size;
 static unsigned int download_bytes;
+static unsigned int num_of_dot;
 
 static struct usb_endpoint_descriptor fs_ep_in = {
.bLength= USB_DT_ENDPOINT_SIZE,
@@ -414,9 +415,10 @@ static void rx_handler_dl_image(struct usb_ep *ep, struct 
usb_request *req)
req-length = ep-maxpacket;
}
 
-   if (download_bytes  !(download_bytes % BYTES_PER_DOT)) {
+   if (download_bytes  ((download_bytes / BYTES_PER_DOT)  num_of_dot)) {
+   num_of_dot = download_bytes / BYTES_PER_DOT;
putc('.');
-   if (!(download_bytes % (74 * BYTES_PER_DOT)))
+   if (!(num_of_dot % 74))
putc('\n');
}
req-actual = 0;
@@ -431,6 +433,7 @@ static void cb_download(struct usb_ep *ep, struct 
usb_request *req)
strsep(cmd, :);
download_size = simple_strtoul(cmd, NULL, 16);
download_bytes = 0;
+   num_of_dot = 0;
 
printf(Starting download of %d bytes\n, download_size);
 
-- 
2.1.0.24.g4109c28

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

[U-Boot] [PATCH 2/3] arm: goni: update SDRAM memory layout

According to changes in memory configuration in first stage bootloader,
we change PHYS_SDRAM_1 from 0x3000 to 0x2000. This change revealed
problem in memory handling at goni platform, so this patch fix this problem
by changing CONFIG_SYS_SDRAM_BASE to 0x4000.

So far SDRAM base was set to 0x3000 and total memory size was calulated
as sum of memory sizes in all banks. But at goni platform memory address
range is not continuous.

We have:
0x2000-0x24ff - 80 MiB
0x2500-0x3fff - gap
0x4000-0x4fff - 256 MiB
0x5000-0x57ff - 128 MiB

It caused problem - u-boot has seen memory area as continous, so it
could try to read/write to memory address in the gap range.

The solution would be to create algorithm of handling non-continous memory
area, but it's much simpler to omit the first memory range and gap between
0x2500-0x3fff, and set memory base to 0x4000. It decreases
total available memory size from 464 MiB to 384 MiB, but after all we
have still more than enough memory for each u-boot feature.

Signed-off-by: Robert Baldyga r.bald...@samsung.com
---
 board/samsung/goni/goni.c  | 3 +--
 include/configs/s5p_goni.h | 6 +++---
 2 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/board/samsung/goni/goni.c b/board/samsung/goni/goni.c
index eb0f9bf..9aceb2e 100644
--- a/board/samsung/goni/goni.c
+++ b/board/samsung/goni/goni.c
@@ -50,8 +50,7 @@ int power_init_board(void)
 
 int dram_init(void)
 {
-   gd-ram_size = PHYS_SDRAM_1_SIZE + PHYS_SDRAM_2_SIZE +
-   PHYS_SDRAM_3_SIZE;
+   gd-ram_size = PHYS_SDRAM_2_SIZE + PHYS_SDRAM_3_SIZE;
 
return 0;
 }
diff --git a/include/configs/s5p_goni.h b/include/configs/s5p_goni.h
index 82bd212..eab9288 100644
--- a/include/configs/s5p_goni.h
+++ b/include/configs/s5p_goni.h
@@ -29,10 +29,10 @@
 #define CONFIG_SYS_CLK_FREQ_C110   2400
 
 /* DRAM Base */
-#define CONFIG_SYS_SDRAM_BASE  0x3000
+#define CONFIG_SYS_SDRAM_BASE  0x4000
 
 /* Text Base */
-#define CONFIG_SYS_TEXT_BASE   0x3480
+#define CONFIG_SYS_TEXT_BASE   0x4180
 
 #define CONFIG_SETUP_MEMORY_TAGS
 #define CONFIG_CMDLINE_TAG
@@ -220,7 +220,7 @@
 
 /* Goni has 3 banks of DRAM, but swap the bank */
 #define CONFIG_NR_DRAM_BANKS   3
-#define PHYS_SDRAM_1   CONFIG_SYS_SDRAM_BASE   /* OneDRAM Bank #0 */
+#define PHYS_SDRAM_1   0x2000  /* OneDRAM Bank #0 */
 #define PHYS_SDRAM_1_SIZE  (80  20)  /* 80 MB in Bank #0 */
 #define PHYS_SDRAM_2   0x4000  /* mDDR DMC1 Bank #1 */
 #define PHYS_SDRAM_2_SIZE  (256  20) /* 256 MB in Bank #1 */
-- 
1.9.1

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

[U-Boot] [PATCH 0/3] Fixes and updates for goni platform

This patchset modifies goni platform configuration to make it working
with latest version of first stage bootloader. There were some memory
controller configuraion modifications, so we update SDRAM memory base,
memory banks and environmental variables to be correct with new memory
layout.

As described changes helped to reveal bug in memory handling at goni
platform, this patch series contains also fix for this bug - now we
avoid having gap in used memory area.

Detailed description of changes can be found in commit messages.

Best regards
Robert Baldyga

Robert Baldyga (3):
  arm: goni: make board generic
  arm: goni: update SDRAM memory layout
  arm: goni: update environmental variables

 board/samsung/goni/goni.c  |  3 +--
 include/configs/s5p_goni.h | 21 +++--
 2 files changed, 12 insertions(+), 12 deletions(-)

-- 
1.9.1

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

[U-Boot] [PATCH 1/3] arm: goni: make board generic

Define CONFIG_SYS_GENERIC_BOARD to make board generic.

Signed-off-by: Robert Baldyga r.bald...@samsung.com
---
 include/configs/s5p_goni.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/s5p_goni.h b/include/configs/s5p_goni.h
index a51215d..82bd212 100644
--- a/include/configs/s5p_goni.h
+++ b/include/configs/s5p_goni.h
@@ -23,6 +23,7 @@
 #define CONFIG_ARCH_CPU_INIT
 #define CONFIG_DISPLAY_CPUINFO
 #define CONFIG_DISPLAY_BOARDINFO
+#define CONFIG_SYS_GENERIC_BOARD
 
 /* input clock of PLL: has 24MHz input clock at S5PC110 */
 #define CONFIG_SYS_CLK_FREQ_C110   2400
-- 
1.9.1

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

[U-Boot] [PATCH 3/3] arm: goni: update environmental variables

According to changes in memory configuration in first stage bootloader,
memory in address range 0x3000-0x3500 is no longer available.
It has moved to 0x2000-0x2500 to make DRAM base for kernel
the same as in another platforms based on s5pv210 SoC.

Because this memory bank is not currently used by u-boot we have only
to change addresses used in default environmental variables to be sure
that operations like kernel loading will be done at correct address in
memory.

Signed-off-by: Robert Baldyga r.bald...@samsung.com
---
 include/configs/s5p_goni.h | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/include/configs/s5p_goni.h b/include/configs/s5p_goni.h
index eab9288..97891b0 100644
--- a/include/configs/s5p_goni.h
+++ b/include/configs/s5p_goni.h
@@ -149,7 +149,7 @@
CONFIG_COMMON_BOOT
 
 #define CONFIG_UPDATEB updateb=onenand erase 0x0 0x10; \
-onenand write 0x32008000 0x0 0x10\0
+onenand write 0x22008000 0x0 0x10\0
 
 #define CONFIG_MISC_COMMON
 #define CONFIG_MISC_INIT_R
@@ -162,13 +162,13 @@
CONFIG_UPDATEB \
updatek= \
onenand erase 0xc0 0x60; \
-   onenand write 0x31008000 0xc0 0x60\0 \
+   onenand write 0x21008000 0xc0 0x60\0 \
updateu= \
onenand erase 0x0156 0x1eaa; \
-   onenand write 0x3200 0x126 0x8C\0 \
+   onenand write 0x2200 0x126 0x8C\0 \
bootk= \
run loaduimage; \
-   bootm 0x30007FC0\0 \
+   bootm 0x20007FC0\0 \
flashboot= \
set bootargs root=/dev/mtdblock${bootblock}  \
rootfstype=${rootfstype} ${opts}  \
@@ -180,10 +180,10 @@
tftpboot= \
set bootargs root=ubi0!rootfs rootfstype=ubifs  \
${opts} ${lcdinfo}  CONFIG_COMMON_BOOT \
-   ; tftp 0x30007FC0 uImage; bootm 0x30007FC0\0 \
+   ; tftp 0x20007FC0 uImage; bootm 0x20007FC0\0 \
ramboot= \
set bootargs  CONFIG_RAMDISK_BOOT \
-   initrd=0x3300,8M ramdisk=8192\0 \
+   initrd=0x2300,8M ramdisk=8192\0 \
mmcboot= \
set bootargs root=/dev/mmcblk${mmcdev}p${mmcrootpart}  \
rootfstype=${rootfstype} ${opts} ${lcdinfo}  \
@@ -194,7 +194,7 @@
rootfstype=ext4\0 \
console= CONFIG_DEFAULT_CONSOLE \
meminfo=mem=80M mem=256M@0x4000 mem=128M@0x5000\0 \
-   loaduimage=ext4load mmc ${mmcdev}:${mmcbootpart} 0x30007FC0 uImage\0 \
+   loaduimage=ext4load mmc ${mmcdev}:${mmcbootpart} 0x20007FC0 uImage\0 \
mmcdev=0\0 \
mmcbootpart=2\0 \
mmcrootpart=5\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] imx: Fix warning by building vf610twr_nand

2014-09-17 Thread Stefano Babic

Hi Alison,

On 17/09/2014 08:03, Huan Wang wrote:
 Hi, Stefano,
 
   I agree with this patch. Thanks.
 

ok. This means I can add your Acked-by to the patch:

Acked-by: Alison Wang alison.w...@freescale.com

By the way, your registered e-mail into U-Boot tree
(board/freescale/vf610twr/MAINTAINERS) is b18...@freescale.com. If
this is not correct, please send a follow up patch updating your e-mail
address - Thanks !

Best regards,
Stefano Babic


-- 
=
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] OMAP4: Use generic 'load' command instead of 'fatload' for 'loadbootscript' and 'loadbootenv' as already done for 'loadimage' and 'loaduimage'.

2014-09-17 Thread Guillaume Gardet


Ping.

Le 05/09/2014 15:32, Guillaume GARDET a écrit :

This patch uses generic 'load' command instead of 'fatload' for 
'loadbootscript' and 'loadbootenv' as already done for 'loadimage' and 
'loaduimage' for OMAP4 boards.

This allows to use EXT partition instead of FAT, while keeping FAT 
compatibility.

Signed-off-by: Guillaume GARDET guillaume.gar...@free.fr
Cc: Tom Rini tr...@ti.com

---
  include/configs/ti_omap4_common.h | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/configs/ti_omap4_common.h 
b/include/configs/ti_omap4_common.h
index 8c7310c..b0f199e 100644
--- a/include/configs/ti_omap4_common.h
+++ b/include/configs/ti_omap4_common.h
@@ -101,10 +101,10 @@
vram=${vram}  \
root=${mmcroot}  \
rootfstype=${mmcrootfstype}\0 \
-   loadbootscript=fatload mmc ${mmcdev} ${loadaddr} boot.scr\0 \
+   loadbootscript=load mmc ${mmcdev} ${loadaddr} boot.scr\0 \
bootscript=echo Running bootscript from mmc${mmcdev} ...;  \
source ${loadaddr}\0 \
-   loadbootenv=fatload mmc ${mmcdev} ${loadaddr} uEnv.txt\0 \
+   loadbootenv=load mmc ${mmcdev} ${loadaddr} uEnv.txt\0 \
importbootenv=echo Importing environment from mmc${mmcdev} ...;  \
env import -t ${loadaddr} ${filesize}\0 \
loadimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}\0 \


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

Re: [U-Boot] [PATCH] am335x_evm: Add boot script support to am335x_evm

2014-09-17 Thread Guillaume Gardet


Ping.

Guillaume

Le 11/09/2014 09:23, Guillaume GARDET a écrit :

This patch adds boot script support to am335x_evm

Signed-off-by: Guillaume GARDET guillaume.gar...@free.fr
Cc: Tom Rini tr...@ti.com

---
  include/configs/am335x_evm.h | 29 ++---
  1 file changed, 18 insertions(+), 11 deletions(-)

diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
index df1a6fc..aef0ad3 100644
--- a/include/configs/am335x_evm.h
+++ b/include/configs/am335x_evm.h
@@ -115,6 +115,9 @@
nfsroot=${serverip}:${rootpath},${nfsopts} rw  \
ip=dhcp\0 \
bootenv=uEnv.txt\0 \
+   loadbootscript=load mmc ${mmcdev} ${loadaddr} boot.scr\0 \
+   bootscript=echo Running bootscript from mmc${mmcdev} ...;  \
+   source ${loadaddr}\0 \
loadbootenv=load mmc ${mmcdev} ${loadaddr} ${bootenv}\0 \
importbootenv=echo Importing environment from mmc ...;  \
env import -t -r $loadaddr $filesize\0 \
@@ -142,17 +145,21 @@
mmcboot=mmc dev ${mmcdev};  \
if mmc rescan; then  \
echo SD/MMC found on device ${mmcdev}; \
-   if run loadbootenv; then  \
-   echo Loaded environment from ${bootenv}; \
-   run importbootenv; \
-   fi; \
-   if test -n $uenvcmd; then  \
-   echo Running uenvcmd ...; \
-   run uenvcmd; \
-   fi; \
-   if run loadimage; then  \
-   run mmcloados; \
-   fi; \
+   if run loadbootscript; then  \
+   run bootscript; \
+   else  \
+   if run loadbootenv; then  \
+   echo Loaded environment from 
${bootenv}; \
+   run importbootenv; \
+   fi; \
+   if test -n $uenvcmd; then  \
+   echo Running uenvcmd ...; \
+   run uenvcmd; \
+   fi; \
+   if run loadimage; then  \
+   run mmcloados; \
+   fi; \
+   fi ; \
fi;\0 \
spiboot=echo Booting from spi ...;  \
run spiargs;  \


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

Re: [U-Boot] A minor question on a Driver Model function

Hi Igor,



On Mon, 15 Sep 2014 11:04:20 +0300
Igor Grinberg grinb...@compulab.co.il wrote:

 Hi,
 
 On 09/14/14 21:28, Simon Glass wrote:
  Hi Masahiro,
  
  On 12 September 2014 05:25, Masahiro Yamada yamad...@jp.panasonic.com 
  wrote:
  Hi Simon,
 
 
  I have a qustion about lists_driver_lookup_name() function.
 
 
 
  for (entry = drv; entry != drv + n_ents; entry++) {
  if (strncmp(name, entry-name, len))
  continue;
 
  /* Full match */
  if (len == strlen(entry-name))
  return entry;
  }
 
 
 
 
  Why is this not like follows?
 
 
 
 
  for (entry = drv; entry != drv + n_ents; entry++) {
  if (!strcmp(name, entry-name))
  return entry;
  }
 
 I would suggest still using strncmp as it is safer,
 but count also the '\0', so something like:

Why safer?

Could you give me more detailed explanation?



Best Regards
Masahiro Yamada

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

Re: [U-Boot] [PULL] Please pull u-boot-imx

2014-09-17 Thread Albert ARIBAUD

Hi Stefano,

On Tue, 16 Sep 2014 17:07:34 +0200, Stefano Babic sba...@denx.de
wrote:

 Hi Albert,
 
 On 16/09/2014 16:38, Albert ARIBAUD wrote:
  Hi Stefano,
  
  On Fri, 12 Sep 2014 16:03:15 +0200, Stefano Babic sba...@denx.de
  wrote:
  
  Hi Albert,
 
  please pull from u-boot-imx, thanks !
 
  The board cm_fx6 cannot be built due to a couple of missing patches that
  are already merged into u-boot-spi. Please ignore this issue, the board
  will be compiled clean at the next iteration after Jagan's tree will be
  merged by Tom.
 
  The following changes since commit 
  a6bc0195dba895fa0e9facc718d17eb098695685:
 
Merge branch 'u-boot-sunxi/master' into 'u-boot-arm/master'
  (2014-09-09 09:19:10 +0200)
 
  are available in the git repository at:
 
 
git://www.denx.de/git/u-boot-imx.git master
 
  for you to fetch changes up to 4c97f16911e229f6d5bbea5bee52449916e5fa92:
 
imx: mx6slevk: Change to use generic board (2014-09-11 11:04:26 +0200)
 
  
  Fabio Estevam (9):
net: fec_mxc: Adjust RX DMA alignment for mx6solox
net: fec_mxc: Poll FEC_TBD_READY after polling TDAR
tools: imximage: Fix the maximum DCD size for mx53/mx6
mx6dlsabresd: Use its own DCD table
mx6qsabreauto: Remove imx6q-sabreauto.dts
mx6: imx-regs: Provide a structure for GPC registers
pcie_imx: Add mx6solox support
mx6sxsabresd: Add PCI support
README.imximage: Fix the maximum DCD size
 
  Guillaume GARDET (1):
imx: nitrogen6x: Replace 'fatload' by 'load' command in env
  settings to be filesystem independent
 
  Nikita Kiryanov (16):
mx6: add clock enabling functions
compulab: eeprom: add support for defining eeprom i2c bus
  
  The commit above (52658fda7abc) breaks trimslice build (and later will
  break cm_fx6 when it is introduced by 0991866cf7, or possibly before
  that, at f66113c0ef) with the following errors :
  
 
 This is due to the fact that some patches were already merged by Jagan
 into u-boot-spi and not by me. In fact, I have cherry-picked the
 relevant patches from Jagan's tree:
 
 a7434e2efa6d514b449c51d57e7af79387761349
 [next d709570] spl: replace CONFIG_SPL_SPI_* with CONFIG_SF_DEFAULT_*
  Author: Nikita Kiryanov nik...@compulab.co.il
 
 fd2dd067fa4f0ea28e80071806850b058dd9555d
 [next 8cca248] spi: mxc: fix sf probe when using mxc_spi
  Author: Nikita Kiryanov nik...@compulab.co.il
  16 files changed, 79 insertions(+), 33 deletions(-)
 
 bdb070e9810017711cff5486eb09c387043be7c6
 [next 92c569e] mtd: spi: add support for M25PE16 and M25PX16
  Author: Nikita Kiryanov nik...@compulab.co.il
  1 file changed, 2 insertions(+)
 
 and then the board is built without any issue.
 ./MAKEALL cm_fx6
 boards.cfg is up to date. Nothing to do.
 Building cm_fx6 board...
text  data bss dec hex filename
  252164 26298  318528  596990   91bfe ./u-boot
   27088  2464 112   2966473e0 ./spl/u-boot-spl
 
 
 However, patches were already merged. The issue should be solved when
 u-boot-spi and u-boot-arm will be pulled by Tom. Or do you think we have
 to do something before ?

There is not much we can do now, so we'll have to make sure u-boot-arm
and u-boot-spi et merged into mainline properly.

The problem I see with this type of situation is that non-mainline
U-Boot trees (imx, arm, spi...) are supposed to be useable code ontheir
own right, and here, imx and arm trees become (slightly) unusable,
which prevents things like bisecting in case you end up on a non-
buildable commit.

The only solution I can think of -- and it does not solve all cases --
is to never pull in commits or merges from an unrelated tree (e.g., to
not pull from spi to arm tree), only from an upstream tree (e.g. pulling
from mainline to arm is ok, as is pulling from mainline or arm to imx),
and to avoid scattering a patch series over several trees, but rather,
apply it to a single tree, with Acks from other custodians and/or
maintainers involved.

 Best regards,
 Stefano

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

Re: [U-Boot] [PATCH] imx6: add Bachmann OT1200 board

2014-09-17 Thread Christian Gmeiner

Hi Stefano.

Thanks for you review. I will send a V2 after the other patches I have send got
reviewed too.


 On 09/09/2014 16:41, Christian Gmeiner wrote:
 This patch adds support for the OT1200 series of devices.

 Following components are used in u-boot:
 + ethernet
 + i2c
 + emmc
 + gpio

 It looks incomplete or wrong. I see you set up sata, too.

Good catch. For the initial board support I will remove sata support
and will add it with
later patches.



 The main difference between the different models of the OT1200
 series is how ethernet is connected (directly to a switch or
 to a normal phy).

 It would be nice to add a README in your board directory explaining the
 differences and something more about your boards.


That is doable :)


 Signed-off-by: Christian Gmeiner christian.gmei...@gmail.com
 ---
  arch/arm/Kconfig  |   4 +
  board/bachmann/ot1200/Kconfig |  23 
  board/bachmann/ot1200/MAINTAINERS |   6 +
  board/bachmann/ot1200/Makefile|   9 ++
  board/bachmann/ot1200/ot1200.c| 262 
 ++
  configs/ot1200_defconfig  |   3 +
  include/configs/ot1200.h  | 195 
  7 files changed, 502 insertions(+)
  create mode 100644 board/bachmann/ot1200/Kconfig
  create mode 100644 board/bachmann/ot1200/MAINTAINERS
  create mode 100644 board/bachmann/ot1200/Makefile
  create mode 100644 board/bachmann/ot1200/ot1200.c
  create mode 100644 configs/ot1200_defconfig
  create mode 100644 include/configs/ot1200.h

 diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
 index 22f0f09..c93dcb6 100644
 --- a/arch/arm/Kconfig
 +++ b/arch/arm/Kconfig
 @@ -412,6 +412,9 @@ config TARGET_HUMMINGBOARD
  config TARGET_TQMA6
   bool TQ Systems TQMa6 board

 +config TARGET_OT1200
 + bool Bachmann OT1200
 +
  config OMAP34XX
   bool OMAP34XX SoC

 @@ -564,6 +567,7 @@ source board/atmel/at91sam9rlek/Kconfig
  source board/atmel/at91sam9x5ek/Kconfig
  source board/atmel/sama5d3_xplained/Kconfig
  source board/atmel/sama5d3xek/Kconfig
 +source board/bachmann/ot1200/Kconfig
  source board/balloon3/Kconfig
  source board/barco/titanium/Kconfig
  source board/bluegiga/apx4devkit/Kconfig
 diff --git a/board/bachmann/ot1200/Kconfig b/board/bachmann/ot1200/Kconfig
 new file mode 100644
 index 000..55a825d
 --- /dev/null
 +++ b/board/bachmann/ot1200/Kconfig
 @@ -0,0 +1,23 @@
 +if TARGET_OT1200
 +
 +config SYS_CPU
 + string
 + default armv7
 +
 +config SYS_BOARD
 + string
 + default ot1200
 +
 +config SYS_VENDOR
 + string
 + default bachmann
 +
 +config SYS_SOC
 + string
 + default mx6
 +
 +config SYS_CONFIG_NAME
 + string
 + default ot1200
 +
 +endif
 diff --git a/board/bachmann/ot1200/MAINTAINERS 
 b/board/bachmann/ot1200/MAINTAINERS
 new file mode 100644
 index 000..ad75c24
 --- /dev/null
 +++ b/board/bachmann/ot1200/MAINTAINERS
 @@ -0,0 +1,6 @@
 +BACHMANN ELECTRONIC OT1200 BOARD
 +M:   Christian Gmeiner christian.gmei...@gmail.com
 +S:   Maintained
 +F:   board/bachmann/ot1200
 +F:   include/configs/ot1200.h
 +F:   configs/ot1200*_defconfig
 diff --git a/board/bachmann/ot1200/Makefile b/board/bachmann/ot1200/Makefile
 new file mode 100644
 index 000..1bd42e8
 --- /dev/null
 +++ b/board/bachmann/ot1200/Makefile
 @@ -0,0 +1,9 @@
 +#
 +# Copyright (C) 2012-2013, Guennadi Liakhovetski l...@denx.de
 +# (C) Copyright 2012-2013 Freescale Semiconductor, Inc.
 +# Copyright (C) 2013, Boundary Devices i...@boundarydevices.com
 +#
 +# SPDX-License-Identifier:   GPL-2.0+
 +#
 +
 +obj-y  := ot1200.o
 diff --git a/board/bachmann/ot1200/ot1200.c b/board/bachmann/ot1200/ot1200.c
 new file mode 100644
 index 000..1c04f45
 --- /dev/null
 +++ b/board/bachmann/ot1200/ot1200.c
 @@ -0,0 +1,262 @@
 +/*
 + * Copyright (C) 2010-2013 Freescale Semiconductor, Inc.
 + * Copyright (C) 2014, Bachmann electronic GmbH
 + *
 + * SPDX-License-Identifier:  GPL-2.0+
 + */
 +
 +#include common.h
 +#include asm/io.h
 +#include asm/arch/clock.h
 +#include asm/arch/imx-regs.h
 +#include asm/arch/iomux.h
 +#include malloc.h
 +#include asm/arch/mx6-pins.h
 +#include asm/imx-common/iomux-v3.h
 +#include asm/imx-common/mxc_i2c.h
 +#include asm/imx-common/sata.h
 +#include asm/imx-common/boot_mode.h
 +#include asm/arch/crm_regs.h
 +#include mmc.h
 +#include fsl_esdhc.h
 +#include netdev.h
 +#include i2c.h
 +#include pca953x.h
 +#include asm/gpio.h
 +#include phy.h
 +
 +DECLARE_GLOBAL_DATA_PTR;
 +
 +#define UART_PAD_CTRL  (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_PUS_47K_UP | \
 + PAD_CTL_SPEED_LOW | PAD_CTL_DSE_80ohm | \
 + PAD_CTL_SRE_FAST  | PAD_CTL_HYS)
 +
 +#define ENET_PAD_CTRL  (PAD_CTL_PUS_100K_UP |\
 + PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm | PAD_CTL_HYS)
 +
 +#define SPI_PAD_CTRL

Re: [U-Boot] [PATCH v2 07/11] dm: imx: Add error checking to setup_i2c()

Hi Simon,

On 09/17/14 06:51, Simon Glass wrote:
 Since this function can fail, check its return value.
 
 Signed-off-by: Simon Glass s...@chromium.org
 ---
 
 Changes in v2:
 - Add new patch to add error checking to setup_i2c()
 
  arch/arm/imx-common/i2c-mxv7.c| 24 -
  arch/arm/include/asm/imx-common/mxc_i2c.h |  4 ++--
  board/compulab/cm_fx6/cm_fx6.c| 35 
 +--
  3 files changed, 45 insertions(+), 18 deletions(-)
 
 diff --git a/arch/arm/imx-common/i2c-mxv7.c b/arch/arm/imx-common/i2c-mxv7.c
 index a580873..70cff5c 100644
 --- a/arch/arm/imx-common/i2c-mxv7.c
 +++ b/arch/arm/imx-common/i2c-mxv7.c
 @@ -69,15 +69,29 @@ static void * const i2c_bases[] = {
  };
  
  /* i2c_index can be from 0 - 2 */
 -void setup_i2c(unsigned i2c_index, int speed, int slave_addr,
 - struct i2c_pads_info *p)
 +int setup_i2c(unsigned i2c_index, int speed, int slave_addr,
 +   struct i2c_pads_info *p)
  {
 + int ret;
 +
   if (i2c_index = ARRAY_SIZE(i2c_bases))
 - return;
 + return -EINVAL;
   /* Enable i2c clock */
 - enable_i2c_clk(1, i2c_index);
 + ret = enable_i2c_clk(1, i2c_index);
 + if (ret)
 + goto err_clk;
 +
   /* Make sure bus is idle */
 - force_idle_bus(p);
 + ret = force_idle_bus(p);
 + if (ret)
 + goto err_idle;
 +
   bus_i2c_init(i2c_bases[i2c_index], speed, slave_addr,
   force_idle_bus, p);
 +
 + return 0;
 +
 +err_idle:
 +err_clk:
 + return ret;
  }
 diff --git a/arch/arm/include/asm/imx-common/mxc_i2c.h 
 b/arch/arm/include/asm/imx-common/mxc_i2c.h
 index 182c2f3..af86163 100644
 --- a/arch/arm/include/asm/imx-common/mxc_i2c.h
 +++ b/arch/arm/include/asm/imx-common/mxc_i2c.h
 @@ -52,8 +52,8 @@ struct i2c_pads_info {
   mx6q_##name : mx6s_##name
  #endif
  
 -void setup_i2c(unsigned i2c_index, int speed, int slave_addr,
 - struct i2c_pads_info *p);
 +int setup_i2c(unsigned i2c_index, int speed, int slave_addr,
 +   struct i2c_pads_info *p);
  void bus_i2c_init(void *base, int speed, int slave_addr,
   int (*idle_bus_fn)(void *p), void *p);
  int bus_i2c_read(void *base, uchar chip, uint addr, int alen, uchar *buf,
 diff --git a/board/compulab/cm_fx6/cm_fx6.c b/board/compulab/cm_fx6/cm_fx6.c
 index fdb8ebf..62c625a 100644
 --- a/board/compulab/cm_fx6/cm_fx6.c
 +++ b/board/compulab/cm_fx6/cm_fx6.c
 @@ -69,7 +69,7 @@ static iomux_v3_cfg_t const sata_pads[] = {
   IOMUX_PADS(PAD_EIM_BCLK__GPIO6_IO31   | MUX_PAD_CTRL(NO_PAD_CTRL)),
  };
  
 -static void cm_fx6_setup_issd(void)
 +static int cm_fx6_setup_issd(void)
  {
   SETUP_IOMUX_PADS(sata_pads);
   /* Make sure this gpio has logical 0 value */
 @@ -79,14 +79,18 @@ static void cm_fx6_setup_issd(void)
   cm_fx6_sata_power(0);
   mdelay(250);
   cm_fx6_sata_power(1);
 +
 + return 0;
  }
  
  #define CM_FX6_SATA_INIT_RETRIES 10
  int sata_initialize(void)
  {
 - int err, i;
 + int err, i, ret;
  
 - cm_fx6_setup_issd();
 + ret = cm_fx6_setup_issd();
 + if (ret)
 + return ret;

Hmm.. cm-fx6 may have iSSD not assembled and in this case
it has bypasses for a (m)SATA socket on the baseboard.
The socketed device of course is not controlled by those GPIOs.
Therefore, I think, it would be incorrect to fail the boot process
if there is a problem with an iSSD GPIO...
Instead a warning message will be enough. Something like:

ret = cm_fx6_setup_issd();
if (ret)
printf(Warning: iSSD setup failed!\n);

and then continue to the rest of SATA init.

   for (i = 0; i  CM_FX6_SATA_INIT_RETRIES; i++) {
   err = setup_sata();
   if (err) {
 @@ -141,14 +145,25 @@ I2C_PADS(i2c2_pads,
IMX_GPIO_NR(1, 6));
  
  
 -static void cm_fx6_setup_i2c(void)
 +static int cm_fx6_setup_i2c(void)
  {
 - setup_i2c(0, CONFIG_SYS_I2C_SPEED, 0x7f, I2C_PADS_INFO(i2c0_pads));
 - setup_i2c(1, CONFIG_SYS_I2C_SPEED, 0x7f, I2C_PADS_INFO(i2c1_pads));
 - setup_i2c(2, CONFIG_SYS_I2C_SPEED, 0x7f, I2C_PADS_INFO(i2c2_pads));
 + int ret;
 +
 + ret = setup_i2c(0, CONFIG_SYS_I2C_SPEED, 0x7f,
 + I2C_PADS_INFO(i2c0_pads));
 + if (!ret) {
 + ret = setup_i2c(1, CONFIG_SYS_I2C_SPEED, 0x7f,
 + I2C_PADS_INFO(i2c1_pads));
 + }
 + if (!ret) {
 + ret = setup_i2c(2, CONFIG_SYS_I2C_SPEED, 0x7f,
 + I2C_PADS_INFO(i2c2_pads));
 + }

Almost same here, the fact that one of the (or even all) i2c buses
fails to initialize, should not lead to hang()...
The decision if this is a critical error or not should be decided
by the board code.
In this case, this is not a critical error and if one of the buses
fails to initialize, the others should still try.
So, here also, a warning message would be appropriate instead of
abort.

 +

[U-Boot] [PATCH] powerpc/t104xrdb: Disable DTSEC1 and DTSEC2 on T1042RDB

2014-09-17 Thread Vijay Rai

As the board was basically designed for T1040RDB so there are 5 DTSEC ports,
DTSEC1 and DTSEC2 are connected to L2 switch and not usable in T1042 mode
only 3 ports DTSEC3 to DTSEC5 are usable

Signed-off-by: Vijay Rai vijay@freescale.com
Signed-off-by: Priyanka Jain priyanka.j...@freescale.com
---
 board/freescale/t104xrdb/eth.c |2 +-
 drivers/net/fm/t1040.c |   15 +++
 2 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/board/freescale/t104xrdb/eth.c b/board/freescale/t104xrdb/eth.c
index c8b6c67..f84ee2d 100644
--- a/board/freescale/t104xrdb/eth.c
+++ b/board/freescale/t104xrdb/eth.c
@@ -47,7 +47,7 @@ int board_eth_init(bd_t *bis)
case PHY_INTERFACE_MODE_SGMII:
/* T1042RDB doesn't supports SGMII on DTSEC1  DTSEC2 */
if ((FM1_DTSEC1 == i) || (FM1_DTSEC2 == i))
-   fm_info_set_phy_address(i, 0);
+   fm_disable_port(i);
/* T1042RDB only supports SGMII on DTSEC3 */
fm_info_set_phy_address(FM1_DTSEC3,
CONFIG_SYS_SGMII1_PHY_ADDR);
diff --git a/drivers/net/fm/t1040.c b/drivers/net/fm/t1040.c
index bcc871d..1e03662 100644
--- a/drivers/net/fm/t1040.c
+++ b/drivers/net/fm/t1040.c
@@ -10,6 +10,21 @@
 #include asm/immap_85xx.h
 #include asm/fsl_serdes.h
 
+u32 port_to_devdisr[] = {
+   [FM1_DTSEC1] = FSL_CORENET_DEVDISR2_DTSEC1_1,
+   [FM1_DTSEC2] = FSL_CORENET_DEVDISR2_DTSEC1_2,
+   [FM1_DTSEC3] = FSL_CORENET_DEVDISR2_DTSEC1_3,
+   [FM1_DTSEC4] = FSL_CORENET_DEVDISR2_DTSEC1_4,
+   [FM1_DTSEC5] = FSL_CORENET_DEVDISR2_DTSEC1_5,
+};
+
+void fman_disable_port(enum fm_port port)
+{
+   ccsr_gur_t *gur = (void __iomem *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
+
+   setbits_be32(gur-devdisr2, port_to_devdisr[port]);
+}
+
 phy_interface_t fman_port_enet_if(enum fm_port port)
 {
ccsr_gur_t *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
-- 
1.7.9.5

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

Re: [U-Boot] [PATCH v4 1/6] nand: denali: add Denali NAND driver for SPL

Hi Chin,


On Mon, 15 Sep 2014 01:39:07 -0500
Chin Liang See cl...@altera.com wrote:

 Hi Masahiro,
 
 On Fri, 2014-09-12 at 17:06 +0900, Masahiro Yamada wrote:
 
+/* nand_init() - initialize data to make nand usable by SPL */
+void nand_init(void)
+{
+   /* access to main area */
+   writel(0, denali_flash_reg + TRANSFER_SPARE_REG);
+
+   page_size = readl(denali_flash_reg + DEVICE_MAIN_AREA_SIZE);
+   oob_size = readl(denali_flash_reg + DEVICE_SPARE_AREA_SIZE);
+   pages_per_block = readl(denali_flash_reg + PAGES_PER_BLOCK);
   
   
   I believe this will work for ONFI NAND devices only.
   For non-ONFI, the value might not correct.
  
  
  I don't think so.
  It depends on the hardware; in my understanding
  Denali IP is capable of detecting MAIN_AREA_SIZE etc.
  for non-ONFI devices.  At least this is working with non-ONFI devices
  on some Panasonic boards.
  
  If it does not work for Altera SoCs (and if you are planning to use
  this driver), these three registers should be set in advance
  in an earlier board init.
  
 
 I recall one of my colleague was telling me that it doesn't work for one
 of non ONFI part where it read incorrect page size. Nevertheless, we can
 put comments so user which use this driver need to take note.

I have also heard of that.  I think it happens on some Hynix devices.

According to my colleague, for the device with
maf_id = 0xAD, device_id = 0xDA,
the Denali IP seems to set wrong parameters.

Either comments or fixup code like get_hynix_nand_para() in denali.c
will do.

BTW I've noticed only a few Hynix devices are supported by denali.c.
(only the device id = 0xD5 or 0xD7)

This is, anyway, a upstream limitation and we can send a follow up
patch if needed.




  
  
   
   
   Currently U-Boot has drivers/mtd/nand/nand_spl_simple.c which handling
   the SPL NAND image load. Wonder this driver will be integrated into
   nand_spl_simple.c once drivers/mtd/nand/denali.c is applied?
  
  I am not planning to do so because:
  
  [1] nand_spl_simple.c requires CONFIG_SYS_NAND_BLOCK_SIZE, 
  CONFIG_SYS_NAND_PAGE_SIZE,
  CONFIG_SYS_NAND_PAGE_COUNT; we need to specify the device attributes at 
  compilation,
  which the Denali IP is able to detect at run time.
  It is not acceptable for us because we need (want) the run time 
  configuration.
  
  [2] nand_spl_simple.c is so generic that it cannot use the hardware 
  acceleration of
  the Denali IP, that is, slower booting.
  
 
 Yup, you identified the nand_spl_simple.c constrain. This is why I
 patched this file at
 http://rocketboards.org/gitweb/?p=u-boot-socfpga.git;a=commit;h=461a61b8f03d3b690de1f4ff007cd23fb80018a5.
  But I didn't send this patch out as I am waiting the NAND driver patch 
 accepted.


After applying your patch, both [1] and [2] are still the constrain of 
nand_spl_simple.c


Best Regards
Masahiro Yamada

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

[U-Boot] [PATCH] powerpc/t104xrdb: Enable SPI flash Extend address support

2014-09-17 Thread Hou Zhiqiang

Enable the Extend address to support SPI flash more than 16MB.

Signed-off-by: Hou Zhiqiang b48...@freescale.com
---
Based on git://git.denx.de/u-boot.git.
Also can be applied to git://www.denx.de/git/u-boot-mpc85xx.git.
Tested on board T1040RDB.

 include/configs/T104xRDB.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/T104xRDB.h b/include/configs/T104xRDB.h
index 0ee0ff2..d4c6f58 100644
--- a/include/configs/T104xRDB.h
+++ b/include/configs/T104xRDB.h
@@ -503,6 +503,7 @@
 #define CONFIG_FSL_ESPI
 #define CONFIG_SPI_FLASH
 #define CONFIG_SPI_FLASH_STMICRO
+#define CONFIG_SPI_FLASH_BAR
 #define CONFIG_CMD_SF
 #define CONFIG_SF_DEFAULT_SPEED 1000
 #define CONFIG_SF_DEFAULT_MODE  0
-- 
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] usb: gadget: fastboot: improve download progress bar

On Wednesday, September 17, 2014 at 09:43:56 AM, Bo Shen wrote:

+CC Lukasz, this is his turf.

 When download is ongoing, if the actual size of one transfer
 is not the same as BTYES_PER_DOT, which will cause the dot
 won't print anymore. Then it will let the user thinking it
 is stuck, actually it is transfering without dot printed.
 
 So, improve the method to show the progress bar (print dot).
 
 Signed-off-by: Bo Shen voice.s...@atmel.com
 ---
 
  drivers/usb/gadget/f_fastboot.c | 7 +--
  1 file changed, 5 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/usb/gadget/f_fastboot.c
 b/drivers/usb/gadget/f_fastboot.c index 7a1acb9..2f13bf0 100644
 --- a/drivers/usb/gadget/f_fastboot.c
 +++ b/drivers/usb/gadget/f_fastboot.c
 @@ -51,6 +51,7 @@ static inline struct f_fastboot *func_to_fastboot(struct
 usb_function *f) static struct f_fastboot *fastboot_func;
  static unsigned int download_size;
  static unsigned int download_bytes;
 +static unsigned int num_of_dot;
 
  static struct usb_endpoint_descriptor fs_ep_in = {
   .bLength= USB_DT_ENDPOINT_SIZE,
 @@ -414,9 +415,10 @@ static void rx_handler_dl_image(struct usb_ep *ep,
 struct usb_request *req) req-length = ep-maxpacket;
   }
 
 - if (download_bytes  !(download_bytes % BYTES_PER_DOT)) {
 + if (download_bytes  ((download_bytes / BYTES_PER_DOT)  num_of_dot)) {
 + num_of_dot = download_bytes / BYTES_PER_DOT;
   putc('.');
 - if (!(download_bytes % (74 * BYTES_PER_DOT)))
 + if (!(num_of_dot % 74))
   putc('\n');
   }
   req-actual = 0;
 @@ -431,6 +433,7 @@ static void cb_download(struct usb_ep *ep, struct
 usb_request *req) strsep(cmd, :);
   download_size = simple_strtoul(cmd, NULL, 16);
   download_bytes = 0;
 + num_of_dot = 0;

Make it a 'download_total' and log the total amount of bytes transferred 
please, 
that way it can be re-used for other purposes in the future ; for example for 
printing how much data were already transferred ;-)

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

Re: [U-Boot] [PATCH] usb: gadget: fastboot: improve download progress bar

2014-09-17 Thread Bo Shen


Hi Marek,

On 09/17/2014 06:10 PM, Marek Vasut wrote:

On Wednesday, September 17, 2014 at 09:43:56 AM, Bo Shen wrote:

+CC Lukasz, this is his turf.


When download is ongoing, if the actual size of one transfer
is not the same as BTYES_PER_DOT, which will cause the dot
won't print anymore. Then it will let the user thinking it
is stuck, actually it is transfering without dot printed.

So, improve the method to show the progress bar (print dot).

Signed-off-by: Bo Shen voice.s...@atmel.com
---

  drivers/usb/gadget/f_fastboot.c | 7 +--
  1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/f_fastboot.c
b/drivers/usb/gadget/f_fastboot.c index 7a1acb9..2f13bf0 100644
--- a/drivers/usb/gadget/f_fastboot.c
+++ b/drivers/usb/gadget/f_fastboot.c
@@ -51,6 +51,7 @@ static inline struct f_fastboot *func_to_fastboot(struct
usb_function *f) static struct f_fastboot *fastboot_func;
  static unsigned int download_size;
  static unsigned int download_bytes;
+static unsigned int num_of_dot;

  static struct usb_endpoint_descriptor fs_ep_in = {
.bLength= USB_DT_ENDPOINT_SIZE,
@@ -414,9 +415,10 @@ static void rx_handler_dl_image(struct usb_ep *ep,
struct usb_request *req) req-length = ep-maxpacket;
}

-   if (download_bytes  !(download_bytes % BYTES_PER_DOT)) {
+   if (download_bytes  ((download_bytes / BYTES_PER_DOT)  num_of_dot)) {
+   num_of_dot = download_bytes / BYTES_PER_DOT;
putc('.');
-   if (!(download_bytes % (74 * BYTES_PER_DOT)))
+   if (!(num_of_dot % 74))
putc('\n');
}
req-actual = 0;
@@ -431,6 +433,7 @@ static void cb_download(struct usb_ep *ep, struct
usb_request *req) strsep(cmd, :);
download_size = simple_strtoul(cmd, NULL, 16);
download_bytes = 0;
+   num_of_dot = 0;


Make it a 'download_total' and log the total amount of bytes transferred please,
that way it can be re-used for other purposes in the future ; for example for
printing how much data were already transferred ;-)


The download_bytes record the total amount of bytes transferred.
And the download_bytes will print after finishing transfer.


Best regards,
Marek Vasut



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

[U-Boot] [PATCH] powerpc/mpc85xx: SECURE BOOT - Bypass PAMU in case of secure boot

2014-09-17 Thread Ruchika Gupta

By default, PAMU's (IOMMU) are enabled in case of secure boot.
Disable/bypass them , once the control reached the bootloader.

For non-secure boot, PAMU's are already bypassed in the default
SoC configuration

Signed-off-by: Ruchika Gupta ruchika.gu...@freescale.com
CC: York Sun york...@freescale.com
---
 arch/powerpc/cpu/mpc85xx/cpu_init.c   | 6 +-
 arch/powerpc/include/asm/immap_85xx.h | 1 +
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init.c 
b/arch/powerpc/cpu/mpc85xx/cpu_init.c
index 21c3194..15a7771 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu_init.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu_init.c
@@ -424,7 +424,7 @@ ulong cpu_init_f(void)
 {
ulong flag = 0;
extern void m8560_cpm_reset (void);
-#ifdef CONFIG_SYS_DCSRBAR_PHYS
+#if defined(CONFIG_SYS_DCSRBAR_PHYS) || defined(CONFIG_SECURE_BOOT)
ccsr_gur_t *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
 #endif
 #if defined(CONFIG_SECURE_BOOT)
@@ -456,6 +456,10 @@ ulong cpu_init_f(void)
 #if defined(CONFIG_SYS_CPC_REINIT_F)
disable_cpc_sram();
 #endif
+
+   /* Put PAMU in bypass mode */
+   out_be32(gur-pamubypenr, FSL_CORENET_PAMU_BYPASS);
+
 #endif
 
 #ifdef CONFIG_CPM2
diff --git a/arch/powerpc/include/asm/immap_85xx.h 
b/arch/powerpc/include/asm/immap_85xx.h
index 88c1e08..0264523 100644
--- a/arch/powerpc/include/asm/immap_85xx.h
+++ b/arch/powerpc/include/asm/immap_85xx.h
@@ -1912,6 +1912,7 @@ defined(CONFIG_PPC_T1020) || defined(CONFIG_PPC_T1022)
u8  res24[64];
u32 pblsr;  /* Preboot loader status */
u32 pamubypenr; /* PAMU bypass enable */
+#define FSL_CORENET_PAMU_BYPASS0x
u32 dmacr1; /* DMA control */
u8  res25[4];
u32 gensr1; /* General status */
-- 
1.8.1.4

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

[U-Boot] [PATCH] t104xrdb: Add Errata A_007662, A_008007 workaround in pbi.cfg

2014-09-17 Thread Priyanka Jain

-A_007662 states that for x1 link width, PCIe2 controller trains in
 Gen1 speed while configured for Gen2 speed.
 Workaround:Set the width to x1 and speed to Gen2 by writing to
 CCSR registers in PBI phase

-A_008007 states that PVR register may show random value.
 Workaround: Reset PVR register using DCSR space in PBI phase

Add PBI based software workaround for A_007662 and A_008007
in t104x_pbi.cfg. This is required for SPL-based bootloaders
like NAND-boot, SD-boot, SPI-boot

Signed-off-by: Priyanka Jain priyanka.j...@freescale.com
---
 board/freescale/t104xrdb/t104x_pbi.cfg |   10 ++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/board/freescale/t104xrdb/t104x_pbi.cfg 
b/board/freescale/t104xrdb/t104x_pbi.cfg
index 7b9e9b0..b83b9b7 100644
--- a/board/freescale/t104xrdb/t104x_pbi.cfg
+++ b/board/freescale/t104xrdb/t104x_pbi.cfg
@@ -1,4 +1,14 @@
 #PBI commands
+#Software Workaround for errata A-007662 to train PCIe2 controller in Gen2 
speed
+09250100 0400
+09250108 2000
+#Software Workaround for errata A-008007 to reset PVR register
+0910 000b
+0914 c000
+0918 81d00017
+89020400 a100
+091380c0 000f
+89020400 
 #Initialize CPC1
 0901 00200400
 09138000 
-- 
1.7.4.1


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

Re: [U-Boot] [PATCH 00/35][RFC] arm: socfpga: Usability fixes

On Wed, 2014-09-17 at 01:52 +0200, ma...@denx.de wrote:
 On Wednesday, September 17, 2014 at 12:29:54 AM, Dinh Nguyen wrote:
 
 [...]
 
   Yes, tracked it down to get_ram_size(). I forced gd-ram_size to 1GB and
   it works fine for me now. I'll try to spend some cycles to debug the
   problem.
   
   Hm, how much DRAM can the SoCFPGA chip drive in total ?
  
  All of our devkits have at least 1 GiB and I have heard there is a
  variant with 2GiB in the wild. Spec says up to 4 GiB.
 
 OK, I see. You cannot realistically map all those 4GiB into the 32-bit 
 address 
 space of an CortexA9, but on the other hand, all those bugs related to an CA9 
 with 4GiB of DRAM should be fixed due to my work on Novena ;-)

Yup, 4GB would not be possible. Within SocFPGA, by using HPS-FPGA
bridges, we can workaround by swapping memory chunk so ARM processor can
access entire 4GB. Interested to find out how you did it for Novena :)


 
   Well, consider a theoretical SoCFPGA board with 128MiB of DRAM attached
   to it, what happens if I try to write at address of the 129th MiB (which
   is past the DRAM) ? Will this generate an DABT for the ARM core or will
   some kind of DRAM mirroring or wraparound happen such that I would
   write to the content of 1st MiB of the DRAM ?
  
  We've encountered this issue downstream on a system with 1 GiB.
 
 OK, so a wraparound happens ?
 

It should be a wrap around. It is not working previously as incorrect
configuration for one of SDRAM parameters. The fix is under internal
review now. :)


   If I would get DABT, then there is a rather easy fix for that, see
   arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c and mxs_mem_get_size()
   function. The function places an assembly return instruction into the
   DABT handler entry position (offset 0x14 in ARM vector table IIRC) and
   then runs the get_dram_size() . The assembly instruction only returns
   from the DABT handler right past the code where the DABT happened. For
   the get_ram_size(), the read from the unpopulated DRAM space contains
   zeroes and the function doesn't even realize the DABT happened. But it
   considers the DRAM invalid and thus this works correctly. That's how it
   detects the amount of DRAM.
   
   You might want to consider something similar if that's how it behaves on
   SoCFPGA.
  
  This could be the issue. I think Chin Liang would know about this more
  than me at this point. So I hope he can solve this quickly.
 
 Sure, patch is welcome!
 

Hmmm... actually I can get it works well for my Altera dev kit. The
get_dram_size would take in the argument PHYS_SDRAM_1_SIZE. From here,
the function will ensure the memory specified can read and writable. If
its failing here, probably the SDRAM access might have issue. FYI,
PHYS_SDRAM_1_SIZE is 0x4000 for 1GB.


  Seems odd that the get_ram_size is working on your DENX board and not
  the devkit.
 
 I _think_ I might have hacked this part up and it's still in the cleanup 
 pipeline.
 

It works for me without hacks. I can read and write to the SDRAM memory
well (include 1MB region).

U-Boot 2014.10-rc2-00123-g461be2f-dirty (Sep 17 2014 - 04:28:52)

CPU:   Altera SoCFPGA Platform
BOARD: Altera SoCFPGA Cyclone5 Board
DRAM:  1 GiB
WARNING: Caches not enabled
Using default environment

In:serial
Out:   serial
Err:   serial
Net:   dwmac.ff702000
Error: dwmac.ff702000 address not set.

Warning: Your board does not use generic board. Please read
doc/README.generic-board and take action. Boards not
upgraded by the late 2014 may break or be removed.
Hit any key to stop autoboot:  0
Wrong Image Format for bootm command
ERROR: can't get kernel image!
SOCFPGA_CYCLONE5 # md 0
:    
0010:    
0020:    
0030:    
0040: 7f7b958a a30289de 6bfe35cb 2d3f494f..{..5.kOI?-
0050: d578 6f010bb3 ec671fe4 27131f7bxwwo..g.{..'
0060: 2f6ff6e4 bb97cecd 7fff9dda 6ffa1fcd..o/...o
0070: b7375b84 7159d3ae f07ac971 e99bbff6.[7...Yqq.z.
0080: d325d7fd d3b663b8 f377cfea f3675f72..%..cw.r_g.
0090: 3d1d4cd9 11a59b18 b795fffd 33ba95b8.L.=...3
00a0: 575bbfef 73eb794f 33536eee 104389cf..[WOy.s.nS3..C.
00b0: 7763a778 35ff5fd8 f33e57c1 f777fbcex.cw._.5.W...w.
00c0: f35b6f9b 5bf70fdb bb730de3 7d7b5f88.o[[..s.._{}
00d0: 5547a7f9 f33f07eb a395364c b35377e8..GU..?.L6...wS.
00e0: 77bf6597 27737ea2 af3577f5 5b34f7d9.e.w.~s'.w5...4[
00f0: 33eadbba fed7df87 3efbfaa8 83b9ef9c...3...
SOCFPGA_CYCLONE5 # mw 0 12345678 100
SOCFPGA_CYCLONE5 # md 0
: 12345678 12345678 12345678 12345678xV4.xV4.xV4.xV4.
0010: 12345678 12345678 12345678 12345678xV4.xV4.xV4.xV4.
0020: 12345678 12345678 12345678 12345678xV4.xV4.xV4.xV4.

Re: [U-Boot] [PATCH v2 2/3] tools: Import Kconfiglib (Superseded !!!)

On Wed, Sep 17, 2014 at 04:48:09AM +0200, Ulf Magnusson wrote:

 I personally mostly care about Kconfiglib being useful to people. I'm open
 to suggestions if the current license in any way gets in the way of that. :)
 
 (I'm not subscribed to the mailing list, so you might have to forward the
 reply there.)

Sorry, that was to Masahiro, to correct the tag we used.  The license on
the code currently is GPL compatible which is what we care about.
Thanks!

 
 /Ulf
 
 On Wed, Sep 17, 2014 at 2:48 AM, Tom Rini tr...@ti.com wrote:
 
  On Tue, Sep 16, 2014 at 11:41:43AM +0900, Masahiro Yamada wrote:
   Hi Tom,
  
  
   I think this series (v2) is under review now,
   but I have noticed my big mistake in terms of the license.
  
   In v2, I accidentally added GPL-2.0+ SPDX
   but it should have been ISC SPDX.
 
  Bah, please post a patch correcting things now and I'll grab it right
  away.
 
  --
  Tom
 

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


-- 
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] usb: gadget: fastboot: improve download progress bar

On Wednesday, September 17, 2014 at 12:28:57 PM, Bo Shen wrote:
 Hi Marek,
 
 On 09/17/2014 06:10 PM, Marek Vasut wrote:
  On Wednesday, September 17, 2014 at 09:43:56 AM, Bo Shen wrote:
  
  +CC Lukasz, this is his turf.
  
  When download is ongoing, if the actual size of one transfer
  is not the same as BTYES_PER_DOT, which will cause the dot
  won't print anymore. Then it will let the user thinking it
  is stuck, actually it is transfering without dot printed.
  
  So, improve the method to show the progress bar (print dot).
  
  Signed-off-by: Bo Shen voice.s...@atmel.com
  ---
  
drivers/usb/gadget/f_fastboot.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
  
  diff --git a/drivers/usb/gadget/f_fastboot.c
  b/drivers/usb/gadget/f_fastboot.c index 7a1acb9..2f13bf0 100644
  --- a/drivers/usb/gadget/f_fastboot.c
  +++ b/drivers/usb/gadget/f_fastboot.c
  @@ -51,6 +51,7 @@ static inline struct f_fastboot
  *func_to_fastboot(struct usb_function *f) static struct f_fastboot
  *fastboot_func;
  
static unsigned int download_size;
static unsigned int download_bytes;
  
  +static unsigned int num_of_dot;
  
static struct usb_endpoint_descriptor fs_ep_in = {

 .bLength= USB_DT_ENDPOINT_SIZE,
  
  @@ -414,9 +415,10 @@ static void rx_handler_dl_image(struct usb_ep *ep,
  struct usb_request *req) req-length = ep-maxpacket;
  
 }
  
  -  if (download_bytes  !(download_bytes % BYTES_PER_DOT)) {
  +  if (download_bytes  ((download_bytes / BYTES_PER_DOT)  num_of_dot))
  { +num_of_dot = download_bytes / BYTES_PER_DOT;
  
 putc('.');
  
  -  if (!(download_bytes % (74 * BYTES_PER_DOT)))
  +  if (!(num_of_dot % 74))
  
 putc('\n');
 
 }
 req-actual = 0;
  
  @@ -431,6 +433,7 @@ static void cb_download(struct usb_ep *ep, struct
  usb_request *req) strsep(cmd, :);
  
 download_size = simple_strtoul(cmd, NULL, 16);
 download_bytes = 0;
  
  +  num_of_dot = 0;
  
  Make it a 'download_total' and log the total amount of bytes transferred
  please, that way it can be re-used for other purposes in the future ;
  for example for printing how much data were already transferred ;-)
 
 The download_bytes record the total amount of bytes transferred.
 And the download_bytes will print after finishing transfer.

So why can this not be used to indicate the total progress ? Because the 
transfeer speed is variating too much ?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 00/35][RFC] arm: socfpga: Usability fixes

On Mon, 2014-09-15 at 13:05 +0200, ma...@denx.de wrote:
 This entire RFC series is the first stab at making SoCFPGA usable with
 mainline U-Boot again. There are still some bits missing, but in general,
 this allows me to use mainline U-Boot on my SoCFPGA systems. The big
 missing part is the SPL generation, which still needs a lot of additional
 work.
 
 This set contains patches for a few subsystems, bu the most part is the
 SoCFPGA chip support.
 
 Most of the patches should be in good shape already, so I wonder if the
 RFC tag is really necessary.
 
 Charles Manning (1):
   tools: socfpga: Add socfpga preloader signing to mkimage
 
 Marek Vasut (21):
   net: dwc: Fix cache alignment issues
   net: dwc: Make the cache handling less cryptic
   mmc: dw_mmc: Fix cache alignment issue
   arm: socfpga: Clean up base address file
   arm: socfpga: sysmgr: Clean up system manager
   arm: socfpga: clock: Implant order into bit definitions
   arm: socfpga: clock: Drop nonsense inlining from clock manager code
   arm: socfpga: clock: Add missing stubs into board file
   arm: socfpga: clock: Trim down code duplication
   arm: socfpga: timer: Pull the timer reload value from config file
   arm: socfpga: reset: Add EMAC reset functions
   arm: socfpga: board: Align checkboard() output
   arm: socfpga: reset: Add function to reset FPGA bridges
   arm: socfpga: sysmgr: Add FPGA bits into system manager
   arm: cache: Add support for write-allocate D-Cache
   arm: socfpga: cache: Define cacheline size
   arm: socfpga: cache: Enable D-Cache
   arm: socfpga: cache: Enable PL310 L2 cache
   arm: socfpga: scu: Add SCU register file
   arm: socfpga: nic301: Add NIC-301 GPV register file
   arm: socfpga: pl310: Map SDRAM to 0x0
 
 Pavel Machek (13):
   net: Remove unused CONFIG_DW_SEARCH_PHY from configs
   net: phy: Cleanup drivers/net/phy/micrel.c
   mmc: dw_mmc: cleanups
   arm: socfpga: Complete the list of base addresses
   arm: socfpga: Add watchdog disable for socfpga
   arm: socfpga: clock: Add code to read clock configuration
   arm: socfpga: mmc: Pick the clock from clock manager
   arm: socfpga: misc: Add proper ethernet initialization
   arm: socfpga: misc: Add SD controller init
   arm: socfpga: misc: Align print_cpuinfo() output
   arm: socfpga: board: Correctly set ATAG position
   arm: socfpga: fpga: Add SoCFPGA FPGA programming interface
   arm: socfpga: nic301: Add NIC-301 configuration code
 
  arch/arm/cpu/armv7/socfpga/Makefile|   3 +-
  arch/arm/cpu/armv7/socfpga/clock_manager.c | 218 -
  arch/arm/cpu/armv7/socfpga/fpga_manager.c  | 354 
 +
  arch/arm/cpu/armv7/socfpga/misc.c  | 144 -
  arch/arm/cpu/armv7/socfpga/reset_manager.c |  72 +
  arch/arm/cpu/armv7/socfpga/system_manager.c|  57 +++-
  arch/arm/cpu/armv7/socfpga/timer.c |   2 +
  arch/arm/include/asm/arch-socfpga/clock_manager.h  | 209 
  arch/arm/include/asm/arch-socfpga/fpga_manager.h   |  77 +
  arch/arm/include/asm/arch-socfpga/nic301.h | 195 
  arch/arm/include/asm/arch-socfpga/reset_manager.h  |   6 +
  arch/arm/include/asm/arch-socfpga/scu.h|  23 ++
  .../include/asm/arch-socfpga/socfpga_base_addrs.h  |  62 +++-
  arch/arm/include/asm/arch-socfpga/system_manager.h | 111 +--
  arch/arm/include/asm/system.h  |   1 +
  arch/arm/lib/cache-cp15.c  |   2 +
  board/altera/socfpga/pll_config.h  |   3 +
  board/altera/socfpga/socfpga_cyclone5.c|   7 +-
  common/image.c |   1 +
  drivers/fpga/altera.c  |  21 ++
  drivers/mmc/dw_mmc.c   |  26 +-
  drivers/mmc/socfpga_dw_mmc.c   |  15 +-
  drivers/net/designware.c   |  46 +--
  drivers/net/phy/micrel.c   |   7 +-
  include/altera.h   |   1 +
  include/configs/axs101.h   |   1 -
  include/configs/socfpga_cyclone5.h |   9 +-
  include/dwmmc.h|   2 +-
  include/image.h|   1 +
  tools/Makefile |   1 +
  tools/imagetool.c  |   2 +
  tools/imagetool.h  |   1 +
  tools/socfpgaimage.c   | 255 +++
  33 files changed, 1753 insertions(+), 182 deletions(-)
  create mode 100644 arch/arm/cpu/armv7/socfpga/fpga_manager.c
  create mode 100644 arch/arm/include/asm/arch-socfpga/fpga_manager.h
  create mode 100644 arch/arm/include/asm/arch-socfpga/nic301.h
  create mode 100644 arch/arm/include/asm/arch-socfpga/scu.h
  create mode 100644 tools/socfpgaimage.c
 
 Cc: Chin Liang See cl...@altera.com
 Cc: Dinh Nguyen dingu...@altera.com
 Cc:

Re: [U-Boot] [PATCH 00/35][RFC] arm: socfpga: Usability fixes

On Wednesday, September 17, 2014 at 01:29:15 PM, Chin Liang See wrote:
[...]
 A quick test from my side and result as below:
 
 1. SDRAM access is working where I can read and write to few spots. :)
 
 SOCFPGA_CYCLONE5 # md 0
 :    
 SOCFPGA_CYCLONE5 # mw 0 12345678 100
 SOCFPGA_CYCLONE5 # md 0
 : 12345678 12345678 12345678 12345678xV4.xV4.xV4.xV4.
 SOCFPGA_CYCLONE5 # md 10
 0010: eafd fbff4b3f fffe fdff33be?K...3..
 SOCFPGA_CYCLONE5 # mw 10 23456789 100
 SOCFPGA_CYCLONE5 # md 10
 0010: 23456789 23456789 23456789 23456789.gE#.gE#.gE#.gE#
 SOCFPGA_CYCLONE5 #

What does that mean?

 2. Ethernet seems not working for me.
 But I will look into this to find out any missing pieces.
 
 SOCFPGA_CYCLONE5 # setenv ethaddr 02:11:22:33:44:55
 SOCFPGA_CYCLONE5 # dhcp
 Speed: 1000, full duplex
 BOOTP broadcast 1
 BOOTP broadcast 2
 BOOTP broadcast 3
 BOOTP broadcast 4
 BOOTP broadcast 5
 BOOTP broadcast 6
 BOOTP broadcast 7
 BOOTP broadcast 8
 BOOTP broadcast 9
 BOOTP broadcast 10
 BOOTP broadcast 11
 BOOTP broadcast 12
 BOOTP broadcast 13
 BOOTP broadcast 14
 BOOTP broadcast 15
 BOOTP broadcast 16
 BOOTP broadcast 17
 
 Retry time exceeded; starting again

This is on the SoCDK, right ?

 3. MMC is not enabled in SocFPGA.
 I recall there is a patch from Pavel.
 I believe its pending for v2 due to some comments.

This should be in the tree in fact. Is CONFIG_CMD_MMC defined ?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] u-boot-socfpga repository

On Tue, 2014-09-16 at 11:56 +0200, ZY - pavel wrote:
 Hi!
 
   I'd be interested in maintaining u-boot-socfpga repository. So far, we 
   don't
   have a repo for this platform and there is a large flurry of patches 
   flying
   around without any kind of central point for them. I'd like to get your 
   formal
   consent for starting this and if you agree, I'd start sending PR to 
   Albert once
   the repo is in place.
  
  
  I maintain a linux git repo at
  git://git.rocketboards.org/linux-socfpga-next.git. It would be trivial
  for us to maintain a u-boot repo at the same location.
  
  a large flurry of patches flying around? Funny, that I have not been
  CCed on any of these patches.
  
  Chin-Liang, have you been?
 
 I'm sorry about that. I understood you are working on Linux, and only
 seen u-boot patches from Chin-Liang, so I cc-ed him..
 

Hi guys,

To move things forward, I would propose myself to act as the custodian
for the SOCFPGA repository after discussing with Dinh. I have been
active on U-Boot forum and hopefully build up some credibility :). At
same time, this will enforce someone from Altera (Dinh, Vince and
myself) to review and ack each submitted patch.  We would also able to
help to test and offer any troubleshooting assistant to the patch
submitter.

Hopefully would get a green light from everyone. We really appreciate
Marek's suggestion as the repo is a great idea to speed up the SOCFPGA
patch submission process. It will offload some of Albert's heavy load
too as currently we heavily rely for Albert to integrate SOCFPGA
patches. Due to that, to benefit everyone, we would like to have this
repo as soon as possible.

Thanks
Chin Liang



 Anyway, you can ignore those patches now, Marek actually transformed
 those patches into rather nice series ([PATCH 00/35][RFC] arm:
 socfpga: Usability fixes).
 
 Best regards, and sorry for the confusion,
   Pavel


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

Re: [U-Boot] [PATCH 00/35][RFC] arm: socfpga: Usability fixes

On Wed, 2014-09-17 at 13:52 +0200, ma...@denx.de wrote:
 On Wednesday, September 17, 2014 at 01:29:15 PM, Chin Liang See wrote:
 [...]
  A quick test from my side and result as below:
  
  1. SDRAM access is working where I can read and write to few spots. :)
  
  SOCFPGA_CYCLONE5 # md 0
  :    
  SOCFPGA_CYCLONE5 # mw 0 12345678 100
  SOCFPGA_CYCLONE5 # md 0
  : 12345678 12345678 12345678 12345678xV4.xV4.xV4.xV4.
  SOCFPGA_CYCLONE5 # md 10
  0010: eafd fbff4b3f fffe fdff33be?K...3..
  SOCFPGA_CYCLONE5 # mw 10 23456789 100
  SOCFPGA_CYCLONE5 # md 10
  0010: 23456789 23456789 23456789 23456789.gE#.gE#.gE#.gE#
  SOCFPGA_CYCLONE5 #
 
 What does that mean?

I recall Pavel was having issue when he is accessing 1MB of memory at 0.
I believe this is gone as this new patch works well for me.

 
  2. Ethernet seems not working for me.
  But I will look into this to find out any missing pieces.
  
  SOCFPGA_CYCLONE5 # setenv ethaddr 02:11:22:33:44:55
  SOCFPGA_CYCLONE5 # dhcp
  Speed: 1000, full duplex
  BOOTP broadcast 1
  BOOTP broadcast 2
  BOOTP broadcast 3
  BOOTP broadcast 4
  BOOTP broadcast 5
  BOOTP broadcast 6
  BOOTP broadcast 7
  BOOTP broadcast 8
  BOOTP broadcast 9
  BOOTP broadcast 10
  BOOTP broadcast 11
  BOOTP broadcast 12
  BOOTP broadcast 13
  BOOTP broadcast 14
  BOOTP broadcast 15
  BOOTP broadcast 16
  BOOTP broadcast 17
  
  Retry time exceeded; starting again
 
 This is on the SoCDK, right ?

Yup, Altera SoCDK.


 
  3. MMC is not enabled in SocFPGA.
  I recall there is a patch from Pavel.
  I believe its pending for v2 due to some comments.
 
 This should be in the tree in fact. Is CONFIG_CMD_MMC defined ?

I didn't see any MMC configuration at include/configs/socfpga_cyclone5
at mainline nor the new patch series. Wonder I might miss out any ACKed
patch?

Thanks
Chin Liang


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

Re: [U-Boot] [PATCH v4 1/6] nand: denali: add Denali NAND driver for SPL

Hi Masahiro,

On Wed, 2014-09-17 at 18:09 +0900, Masahiro Yamada wrote:
Hi Chin,

On Mon, 15 Sep 2014 01:39:07 -0500
Chin Liang See cl...@altera.com wrote:

Hi Masahiro,

On Fri, 2014-09-12 at 17:06 +0900, Masahiro Yamada wrote:

+/* nand_init() - initialize data to make nand usable by SPL */
+void nand_init(void)
+{
+ /* access to main area */
+ writel(0, denali_flash_reg + TRANSFER_SPARE_REG);
+
+ page_size = readl(denali_flash_reg + DEVICE_MAIN_AREA_SIZE);
+ oob_size = readl(denali_flash_reg + DEVICE_SPARE_AREA_SIZE);
+ pages_per_block = readl(denali_flash_reg + PAGES_PER_BLOCK);

I believe this will work for ONFI NAND devices only.
For non-ONFI, the value might not correct.

I don't think so.
It depends on the hardware; in my understanding
Denali IP is capable of detecting MAIN_AREA_SIZE etc.
for non-ONFI devices. At least this is working with non-ONFI devices
on some Panasonic boards.

If it does not work for Altera SoCs (and if you are planning to use
this driver), these three registers should be set in advance
in an earlier board init.

I recall one of my colleague was telling me that it doesn't work for one
of non ONFI part where it read incorrect page size. Nevertheless, we can
put comments so user which use this driver need to take note.

I have also heard of that. I think it happens on some Hynix devices.

According to my colleague, for the device with
maf_id = 0xAD, device_id = 0xDA,
the Denali IP seems to set wrong parameters.

Either comments or fixup code like get_hynix_nand_para() in denali.c
will do.

BTW I've noticed only a few Hynix devices are supported by denali.c.
(only the device id = 0xD5 or 0xD7)

This is, anyway, a upstream limitation and we can send a follow up
patch if needed.

Yup, that sound a good plan to enable this patch to move forward. We
just need to add some write-up to the commit message.

Currently U-Boot has drivers/mtd/nand/nand_spl_simple.c which handling
the SPL NAND image load. Wonder this driver will be integrated into
nand_spl_simple.c once drivers/mtd/nand/denali.c is applied?

I am not planning to do so because:

[1] nand_spl_simple.c requires CONFIG_SYS_NAND_BLOCK_SIZE,
CONFIG_SYS_NAND_PAGE_SIZE,
CONFIG_SYS_NAND_PAGE_COUNT; we need to specify the device attributes at
compilation,
which the Denali IP is able to detect at run time.
It is not acceptable for us because we need (want) the run time
configuration.

[2] nand_spl_simple.c is so generic that it cannot use the hardware
acceleration of
the Denali IP, that is, slower booting.

Yup, you identified the nand_spl_simple.c constrain. This is why I
patched this file at
http://rocketboards.org/gitweb/?p=u-boot-socfpga.git;a=commit;h=461a61b8f03d3b690de1f4ff007cd23fb80018a5.
But I didn't send this patch out as I am waiting the NAND driver patch
accepted.

After applying your patch, both [1] and [2] are still the constrain of
nand_spl_simple.c

For [1], yup. But the intention is to ensure it works for various
devices and NAND controllers. While for [2], the patch will take
advantage of the hardware based ECC calculation. But it will not take
advantage of the DMA as I believe DMA might not exist for certain NAND
controller.

With that, I don't have much concern to remain this file as this would
enable better performance as its specific for Denali. Probably Altera
should use this too if its accepted into mainline :)

Thanks
Chin Liang

Best Regards
Masahiro Yamada

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

Re: [U-Boot] [PATCH v2 08/11] dm: imx: Use gpio_request() to request GPIOs

Hi Simon,

On 09/17/14 06:51, Simon Glass wrote:
 GPIOs should be requested before use. Without this, driver model will not
 permit the GPIO to be used.
 
 Signed-off-by: Simon Glass s...@chromium.org
 ---
 
 Changes in v2:
 - Check return values of gpio_request()
 
  arch/arm/imx-common/i2c-mxv7.c | 24 
  board/compulab/cm_fx6/cm_fx6.c | 15 +++
  board/compulab/cm_fx6/common.c |  7 +++
  3 files changed, 46 insertions(+)
 
 diff --git a/arch/arm/imx-common/i2c-mxv7.c b/arch/arm/imx-common/i2c-mxv7.c
 index 70cff5c..aaf6936 100644
 --- a/arch/arm/imx-common/i2c-mxv7.c
 +++ b/arch/arm/imx-common/i2c-mxv7.c
 @@ -4,6 +4,7 @@
   * SPDX-License-Identifier:  GPL-2.0+
   */
  #include common.h
 +#include malloc.h
  #include asm/arch/clock.h
  #include asm/arch/imx-regs.h
  #include asm/errno.h
 @@ -72,10 +73,26 @@ static void * const i2c_bases[] = {
  int setup_i2c(unsigned i2c_index, int speed, int slave_addr,
 struct i2c_pads_info *p)
  {
 + char *name1, *name2;
   int ret;
  
   if (i2c_index = ARRAY_SIZE(i2c_bases))
   return -EINVAL;
 +
 + name1 = malloc(9);
 + name2 = malloc(9);
 + if (!name1 || !name2)
 + return -ENOMEM;
 + sprintf(name1, i2c_sda%d, i2c_index);
 + sprintf(name2, i2c_scl%d, i2c_index);
 + ret = gpio_request(p-sda.gp, name1);
 + if (ret)
 + goto err_req1;
 +
 + ret = gpio_request(p-scl.gp, name2);
 + if (ret)
 + goto err_req2;
 +
   /* Enable i2c clock */
   ret = enable_i2c_clk(1, i2c_index);
   if (ret)
 @@ -93,5 +110,12 @@ int setup_i2c(unsigned i2c_index, int speed, int 
 slave_addr,
  
  err_idle:
  err_clk:
 + gpio_free(p-scl.gp);
 +err_req2:
 + gpio_free(p-sda.gp);
 +err_req1:
 + free(name1);
 + free(name2);
 +
   return ret;
  }
 diff --git a/board/compulab/cm_fx6/cm_fx6.c b/board/compulab/cm_fx6/cm_fx6.c
 index 62c625a..10e31b6 100644
 --- a/board/compulab/cm_fx6/cm_fx6.c
 +++ b/board/compulab/cm_fx6/cm_fx6.c
 @@ -71,8 +71,21 @@ static iomux_v3_cfg_t const sata_pads[] = {
  
  static int cm_fx6_setup_issd(void)
  {
 + int ret;
 + int i;
 +
   SETUP_IOMUX_PADS(sata_pads);
 +
 + for (i = 0; i  ARRAY_SIZE(cm_fx6_issd_gpios); i++) {
 + ret = gpio_request(cm_fx6_issd_gpios[i], sata);
 + if (ret)
 + return ret;
 + }
 +
   /* Make sure this gpio has logical 0 value */
 + ret = gpio_request(CM_FX6_SATA_PWLOSS_INT, sata_pwloss_int);
 + if (ret)
 + return ret;
   gpio_direction_output(CM_FX6_SATA_PWLOSS_INT, 0);
   udelay(100);
  
 @@ -182,6 +195,7 @@ static int cm_fx6_usb_hub_reset(void)
   }
  
   SETUP_IOMUX_PAD(PAD_SD3_RST__GPIO7_IO08 | MUX_PAD_CTRL(NO_PAD_CTRL));
 + gpio_request(CM_FX6_USB_HUB_RST, usb_hub_rst);

This is confusing... This GPIO should be already requested
several lines above.

   gpio_direction_output(CM_FX6_USB_HUB_RST, 0);
   udelay(10);
   gpio_direction_output(CM_FX6_USB_HUB_RST, 1);
 @@ -339,6 +353,7 @@ int board_eth_init(bd_t *bis)
  
   SETUP_IOMUX_PADS(enet_pads);
   /* phy reset */
 + gpio_request(CM_FX6_ENET_NRST, enet_nrst);

Error check?
This one also should not fail the boot process, just abort the
Ethernet init.

   gpio_direction_output(CM_FX6_ENET_NRST, 0);
   udelay(500);
   gpio_set_value(CM_FX6_ENET_NRST, 1);
 diff --git a/board/compulab/cm_fx6/common.c b/board/compulab/cm_fx6/common.c
 index 1f39679..e4d7e2e 100644
 --- a/board/compulab/cm_fx6/common.c
 +++ b/board/compulab/cm_fx6/common.c
 @@ -79,6 +79,13 @@ void cm_fx6_set_ecspi_iomux(void)
  
  int board_spi_cs_gpio(unsigned bus, unsigned cs)
  {
 +#ifndef CONFIG_SPL_BUILD
 + int ret;
 +
 + ret = gpio_request(CM_FX6_ECSPI_BUS0_CS0, ecspi_bus0_cs0);
 + if (ret)
 + return ret;
 +#endif

Is there a reason for excluding this request from spl builds?
We do build with CONFIG_SPL_GPIO_SUPPORT and we don't have a
problem with spl size.
So, if there is no strong reason to exclude it from spl build,
I'd like to remove the #ifndef.

   return (bus == 0  cs == 0) ? (CM_FX6_ECSPI_BUS0_CS0) : -1;
  }
  #endif
 

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

Re: [U-Boot] [PATCH 00/35][RFC] arm: socfpga: Usability fixes

On Wednesday, September 17, 2014 at 02:00:42 PM, Chin Liang See wrote:
 On Wed, 2014-09-17 at 13:52 +0200, ma...@denx.de wrote:
  On Wednesday, September 17, 2014 at 01:29:15 PM, Chin Liang See wrote:
  [...]
  
   A quick test from my side and result as below:
   
   1. SDRAM access is working where I can read and write to few spots. :)
   
   SOCFPGA_CYCLONE5 # md 0
   :    
   SOCFPGA_CYCLONE5 # mw 0 12345678 100
   SOCFPGA_CYCLONE5 # md 0
   : 12345678 12345678 12345678 12345678xV4.xV4.xV4.xV4.
   SOCFPGA_CYCLONE5 # md 10
   0010: eafd fbff4b3f fffe fdff33be?K...3..
   SOCFPGA_CYCLONE5 # mw 10 23456789 100
   SOCFPGA_CYCLONE5 # md 10
   0010: 23456789 23456789 23456789 23456789.gE#.gE#.gE#.gE#
   SOCFPGA_CYCLONE5 #
  
  What does that mean?
 
 I recall Pavel was having issue when he is accessing 1MB of memory at 0.
 I believe this is gone as this new patch works well for me.

Yes, the NIC301 patches solve this. Pavel confirmed this yesterday.

   2. Ethernet seems not working for me.
   But I will look into this to find out any missing pieces.
   
   SOCFPGA_CYCLONE5 # setenv ethaddr 02:11:22:33:44:55
   SOCFPGA_CYCLONE5 # dhcp
   Speed: 1000, full duplex
   BOOTP broadcast 1
   BOOTP broadcast 2
   BOOTP broadcast 3
   BOOTP broadcast 4
   BOOTP broadcast 5
   BOOTP broadcast 6
   BOOTP broadcast 7
   BOOTP broadcast 8
   BOOTP broadcast 9
   BOOTP broadcast 10
   BOOTP broadcast 11
   BOOTP broadcast 12
   BOOTP broadcast 13
   BOOTP broadcast 14
   BOOTP broadcast 15
   BOOTP broadcast 16
   BOOTP broadcast 17
   
   Retry time exceeded; starting again
  
  This is on the SoCDK, right ?
 
 Yup, Altera SoCDK.

OK

   3. MMC is not enabled in SocFPGA.
   I recall there is a patch from Pavel.
   I believe its pending for v2 due to some comments.
  
  This should be in the tree in fact. Is CONFIG_CMD_MMC defined ?
 
 I didn't see any MMC configuration at include/configs/socfpga_cyclone5
 at mainline nor the new patch series. Wonder I might miss out any ACKed
 patch?

Oh I see. I have this enabled in the repository here, but I didn't submit that 
change since it needs more work. The code is there , added in the patch

arm: socfpga: misc: Add SD controller init

The change for the SoCFPGA config file is missing though.

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

Re: [U-Boot] [PATCH 00/35][RFC] arm: socfpga: Usability fixes

On Wednesday, September 17, 2014 at 01:07:29 PM, Chin Liang See wrote:
 On Wed, 2014-09-17 at 01:52 +0200, ma...@denx.de wrote:
  On Wednesday, September 17, 2014 at 12:29:54 AM, Dinh Nguyen wrote:
  
  [...]
  
Yes, tracked it down to get_ram_size(). I forced gd-ram_size to 1GB
and it works fine for me now. I'll try to spend some cycles to
debug the problem.

Hm, how much DRAM can the SoCFPGA chip drive in total ?
   
   All of our devkits have at least 1 GiB and I have heard there is a
   variant with 2GiB in the wild. Spec says up to 4 GiB.
  
  OK, I see. You cannot realistically map all those 4GiB into the 32-bit
  address space of an CortexA9, but on the other hand, all those bugs
  related to an CA9 with 4GiB of DRAM should be fixed due to my work on
  Novena ;-)
 
 Yup, 4GB would not be possible. Within SocFPGA, by using HPS-FPGA
 bridges, we can workaround by swapping memory chunk so ARM processor can
 access entire 4GB. Interested to find out how you did it for Novena :)

Aww, you know this kind of stuff is really so cool about these SoC+FPGA 
combo designs :)

As for the Novena, MX6 can only address 3.8 GiB, there is a bit of the DRAM 
which is not available .

Well, consider a theoretical SoCFPGA board with 128MiB of DRAM
attached to it, what happens if I try to write at address of the
129th MiB (which is past the DRAM) ? Will this generate an DABT for
the ARM core or will some kind of DRAM mirroring or wraparound
happen such that I would write to the content of 1st MiB of the DRAM
?
   
   We've encountered this issue downstream on a system with 1 GiB.
  
  OK, so a wraparound happens ?
 
 It should be a wrap around. It is not working previously as incorrect
 configuration for one of SDRAM parameters. The fix is under internal
 review now. :)

All right :)

If I would get DABT, then there is a rather easy fix for that, see
arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c and mxs_mem_get_size()
function. The function places an assembly return instruction into the
DABT handler entry position (offset 0x14 in ARM vector table IIRC)
and then runs the get_dram_size() . The assembly instruction only
returns from the DABT handler right past the code where the DABT
happened. For the get_ram_size(), the read from the unpopulated DRAM
space contains zeroes and the function doesn't even realize the DABT
happened. But it considers the DRAM invalid and thus this works
correctly. That's how it detects the amount of DRAM.

You might want to consider something similar if that's how it behaves
on SoCFPGA.
   
   This could be the issue. I think Chin Liang would know about this more
   than me at this point. So I hope he can solve this quickly.
  
  Sure, patch is welcome!
 
 Hmmm... actually I can get it works well for my Altera dev kit. The
 get_dram_size would take in the argument PHYS_SDRAM_1_SIZE. From here,
 the function will ensure the memory specified can read and writable. If
 its failing here, probably the SDRAM access might have issue. FYI,
 PHYS_SDRAM_1_SIZE is 0x4000 for 1GB.

Aw, fixed locally, thanks!

[...]

Pavel had some strange issue here, but these patches should address that. This 
one 'arm: socfpga: pl310: Map SDRAM to 0x0' is extremely important .
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 0/2] Abolish MIN, MAX, MIN3, MAX




Masahiro Yamada (2):
  cosmetic: replace MIN, MAX with min, max
  common.h: remove MIN, MAX, MIN3, MAX3 macros

 arch/arm/cpu/arm1176/tnetv107x/clock.c |  2 +-
 arch/arm/cpu/armv7/mx6/ddr.c   | 40 +-
 arch/x86/lib/physmem.c |  4 ++--
 board/freescale/common/ics307_clk.c|  2 +-
 drivers/dma/fsl_dma.c  |  2 +-
 drivers/i2c/ihs_i2c.c  |  4 ++--
 drivers/mmc/fsl_esdhc.c|  2 +-
 drivers/serial/usbtty.c|  4 ++--
 drivers/usb/gadget/designware_udc.c|  4 ++--
 drivers/usb/gadget/ep0.c   |  2 +-
 drivers/usb/gadget/mpc8xx_udc.c|  4 ++--
 drivers/usb/gadget/pxa27x_udc.c|  2 +-
 fs/zfs/zfs.c   |  6 ++---
 include/common.h   |  6 -
 14 files changed, 39 insertions(+), 45 deletions(-)

-- 
1.9.1

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

[U-Boot] [PATCH 1/2] cosmetic: replace MIN, MAX with min, max

The macro MIN, MAX is defined as the aliase of min, max,
respectively.

Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
---

 arch/arm/cpu/arm1176/tnetv107x/clock.c |  2 +-
 arch/arm/cpu/armv7/mx6/ddr.c   | 40 +-
 arch/x86/lib/physmem.c |  4 ++--
 board/freescale/common/ics307_clk.c|  2 +-
 drivers/dma/fsl_dma.c  |  2 +-
 drivers/i2c/ihs_i2c.c  |  4 ++--
 drivers/mmc/fsl_esdhc.c|  2 +-
 drivers/serial/usbtty.c|  4 ++--
 drivers/usb/gadget/designware_udc.c|  4 ++--
 drivers/usb/gadget/ep0.c   |  2 +-
 drivers/usb/gadget/mpc8xx_udc.c|  4 ++--
 drivers/usb/gadget/pxa27x_udc.c|  2 +-
 fs/zfs/zfs.c   |  6 ++---
 13 files changed, 39 insertions(+), 39 deletions(-)

diff --git a/arch/arm/cpu/arm1176/tnetv107x/clock.c 
b/arch/arm/cpu/arm1176/tnetv107x/clock.c
index 3708b6f..47c23bb 100644
--- a/arch/arm/cpu/arm1176/tnetv107x/clock.c
+++ b/arch/arm/cpu/arm1176/tnetv107x/clock.c
@@ -362,7 +362,7 @@ static void init_pll(const struct pll_init_data *data)
pllctl_reg_write(data-pll, ctl, tmp);
 
mult = data-pll_freq / fpll;
-   for (mult = MAX(mult, 1); mult = MAX_MULT; mult++) {
+   for (mult = max(mult, 1); mult = MAX_MULT; mult++) {
div = (fpll * mult) / data-pll_freq;
if (div  1 || div  MAX_DIV)
continue;
diff --git a/arch/arm/cpu/armv7/mx6/ddr.c b/arch/arm/cpu/armv7/mx6/ddr.c
index 1ab69f6..2bf3705 100644
--- a/arch/arm/cpu/armv7/mx6/ddr.c
+++ b/arch/arm/cpu/armv7/mx6/ddr.c
@@ -248,47 +248,47 @@ void mx6_dram_cfg(const struct mx6_ddr_sysinfo *i,
 
switch (m-mem_speed) {
case 800:
-   txp = DIV_ROUND_UP(MAX(3*clkper, 7500), clkper) - 1;
-   tcke = DIV_ROUND_UP(MAX(3*clkper, 7500), clkper) - 1;
+   txp = DIV_ROUND_UP(max(3*clkper, 7500), clkper) - 1;
+   tcke = DIV_ROUND_UP(max(3*clkper, 7500), clkper) - 1;
if (m-pagesz == 1) {
tfaw = DIV_ROUND_UP(4, clkper) - 1;
-   trrd = DIV_ROUND_UP(MAX(4*clkper, 1), clkper) - 1;
+   trrd = DIV_ROUND_UP(max(4*clkper, 1), clkper) - 1;
} else {
tfaw = DIV_ROUND_UP(5, clkper) - 1;
-   trrd = DIV_ROUND_UP(MAX(4*clkper, 1), clkper) - 1;
+   trrd = DIV_ROUND_UP(max(4*clkper, 1), clkper) - 1;
}
break;
case 1066:
-   txp = DIV_ROUND_UP(MAX(3*clkper, 7500), clkper) - 1;
-   tcke = DIV_ROUND_UP(MAX(3*clkper, 5625), clkper) - 1;
+   txp = DIV_ROUND_UP(max(3*clkper, 7500), clkper) - 1;
+   tcke = DIV_ROUND_UP(max(3*clkper, 5625), clkper) - 1;
if (m-pagesz == 1) {
tfaw = DIV_ROUND_UP(37500, clkper) - 1;
-   trrd = DIV_ROUND_UP(MAX(4*clkper, 7500), clkper) - 1;
+   trrd = DIV_ROUND_UP(max(4*clkper, 7500), clkper) - 1;
} else {
tfaw = DIV_ROUND_UP(5, clkper) - 1;
-   trrd = DIV_ROUND_UP(MAX(4*clkper, 1), clkper) - 1;
+   trrd = DIV_ROUND_UP(max(4*clkper, 1), clkper) - 1;
}
break;
case 1333:
-   txp = DIV_ROUND_UP(MAX(3*clkper, 6000), clkper) - 1;
-   tcke = DIV_ROUND_UP(MAX(3*clkper, 5625), clkper) - 1;
+   txp = DIV_ROUND_UP(max(3*clkper, 6000), clkper) - 1;
+   tcke = DIV_ROUND_UP(max(3*clkper, 5625), clkper) - 1;
if (m-pagesz == 1) {
tfaw = DIV_ROUND_UP(3, clkper) - 1;
-   trrd = DIV_ROUND_UP(MAX(4*clkper, 6000), clkper) - 1;
+   trrd = DIV_ROUND_UP(max(4*clkper, 6000), clkper) - 1;
} else {
tfaw = DIV_ROUND_UP(45000, clkper) - 1;
-   trrd = DIV_ROUND_UP(MAX(4*clkper, 7500), clkper) - 1;
+   trrd = DIV_ROUND_UP(max(4*clkper, 7500), clkper) - 1;
}
break;
case 1600:
-   txp = DIV_ROUND_UP(MAX(3*clkper, 6000), clkper) - 1;
-   tcke = DIV_ROUND_UP(MAX(3*clkper, 5000), clkper) - 1;
+   txp = DIV_ROUND_UP(max(3*clkper, 6000), clkper) - 1;
+   tcke = DIV_ROUND_UP(max(3*clkper, 5000), clkper) - 1;
if (m-pagesz == 1) {
tfaw = DIV_ROUND_UP(3, clkper) - 1;
-   trrd = DIV_ROUND_UP(MAX(4*clkper, 6000), clkper) - 1;
+   trrd = DIV_ROUND_UP(max(4*clkper, 6000), clkper) - 1;
} else {
tfaw = DIV_ROUND_UP(4, clkper) - 1;
-   trrd = DIV_ROUND_UP(MAX(4*clkper, 7500),

[U-Boot] [PATCH 2/2] common.h: remove MIN, MAX, MIN3, MAX3 macros

Now MIN, MAX, MIN3, MAX are not used.
Going forward, use min, max, min3, max3.

Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
---

 include/common.h | 6 --
 1 file changed, 6 deletions(-)

diff --git a/include/common.h b/include/common.h
index 97c04df..d5020c8 100644
--- a/include/common.h
+++ b/include/common.h
@@ -181,9 +181,6 @@ typedef void (interrupt_handler_t)(void *);
typeof(Y) __y = (Y);\
(__x  __y) ? __x : __y; })
 
-#define MIN(x, y)  min(x, y)
-#define MAX(x, y)  max(x, y)
-
 #define min3(X, Y, Z)  \
({ typeof(X) __x = (X); \
typeof(Y) __y = (Y);\
@@ -198,9 +195,6 @@ typedef void (interrupt_handler_t)(void *);
__x  __y ? (__x  __z ? __x : __z) :   \
(__y  __z ? __y : __z); })
 
-#define MIN3(x, y, z)  min3(x, y, z)
-#define MAX3(x, y, z)  max3(x, y, z)
-
 /*
  * Return the absolute value of a number.
  *
-- 
1.9.1

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

[U-Boot] [PATCH] compulab: eeprom: add default eeprom bus

2014-09-17 Thread Nikita Kiryanov

Add default eeprom bus setting.
This addresses the trimslice compile error that was introduced
with the addition of this setting.

Cc: Albert ARIBAUD albert.u.b...@aribaud.net
Cc: Igor Grinberg grinb...@compulab.co.il
Signed-off-by: Nikita Kiryanov nik...@compulab.co.il
---
 board/compulab/common/eeprom.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/board/compulab/common/eeprom.c b/board/compulab/common/eeprom.c
index 85442cd..2df3ada 100644
--- a/board/compulab/common/eeprom.c
+++ b/board/compulab/common/eeprom.c
@@ -15,6 +15,10 @@
 # define CONFIG_SYS_I2C_EEPROM_ADDR_LEN1
 #endif
 
+#ifndef CONFIG_SYS_I2C_EEPROM_BUS
+#define CONFIG_SYS_I2C_EEPROM_BUS  0
+#endif
+
 #define EEPROM_LAYOUT_VER_OFFSET   44
 #define BOARD_SERIAL_OFFSET20
 #define BOARD_SERIAL_OFFSET_LEGACY 8
-- 
1.9.1

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

Re: [U-Boot] [PATCH v2 09/11] dm: imx: gpio: Support driver model in MXC gpio driver

On 09/17/14 06:51, Simon Glass wrote:
 Add driver model support with this driver. In this case the platform data
 is in the driver. It would be better to put this into an SOC-specific file,
 but this is best attempted when more boards are moved over to use driver
 model.
 
 Signed-off-by: Simon Glass s...@chromium.org
 ---
 
 Changes in v2:
 - Change 'reserved' to 'requested'
 - Add an internal function to check if a GPIO is requested
 - Tidy up confusing code that creates names for gpio_request()
 
  drivers/gpio/mxc_gpio.c | 302 
 +++-
  1 file changed, 301 insertions(+), 1 deletion(-)
 
 diff --git a/drivers/gpio/mxc_gpio.c b/drivers/gpio/mxc_gpio.c
 index 6a572d5..9435d2f 100644
 --- a/drivers/gpio/mxc_gpio.c
 +++ b/drivers/gpio/mxc_gpio.c

[...]

 +static int mxc_gpio_get_state(struct udevice *dev, unsigned int offset,
 +   char *buf, int bufsize)
 +{
 + struct gpio_dev_priv *uc_priv = dev-uclass_priv;
 + struct mxc_bank_info *bank = dev_get_priv(dev);
 + const char *label;
 + bool is_output;
 + int size;
 +
 + label = bank-label[offset];
 + is_output = mxc_gpio_is_output(bank-regs, offset);
 + size = snprintf(buf, bufsize, %s%d: ,
 + uc_priv-bank_name ? uc_priv-bank_name : , offset);
 + buf += size;
 + bufsize -= size;
 + snprintf(buf, bufsize, %s: %d [%c]%s%s,
 +  is_output ? out :  in,
 +  is_output ?
 + mxc_gpio_bank_get_output_value(bank-regs, offset) :
 + mxc_gpio_bank_get_value(bank-regs, offset),
 +  *label ? 'x' : ' ',
 +  *label ?   : ,

This is a check if the gpio is requested, right?
I think the new function gpio_is_requested() can be of hand here
instead of open coding this.

 +  label);
 +
 + return 0;
 +}
 +

[...]

 +static int mxc_gpio_free(struct udevice *dev, unsigned offset)
 +{
 + struct mxc_bank_info *bank = dev_get_priv(dev);
 + int ret;
 +
 + ret = check_requested(dev, offset, __func__);
 + if (ret)
 + return ret;

In case of not requested gpio,
should we really print the error message and return -EPERM?
Or may be adopt free() behavior and just return silently?
Linux gpiolib gpio_free() uses WARN_ON(extra_checks) for
not requested cases, so it shouts only in DEBUG cases.

 + bank-label[offset][0] = '\0';
 +
 + return 0;
 +}
 +

[...]


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

Re: [U-Boot] [PATCH v2 11/11] dm: imx: Move cm_fx6 to use driver model for serial and GPIO


On 09/17/14 06:51, Simon Glass wrote:
 Now that serial and GPIO are available for iMX.6, move cm_fx6 over as an
 example.
 
 Signed-off-by: Simon Glass s...@chromium.org

Thanks for doing this.
Acked-by: Igor Grinberg grinb...@compulab.co.il

 ---
 
 Changes in v2:
 - Use the correct namespace for the platform data
 
  board/compulab/cm_fx6/cm_fx6.c | 10 ++
  include/configs/cm_fx6.h   | 11 +++
  2 files changed, 21 insertions(+)
 
 diff --git a/board/compulab/cm_fx6/cm_fx6.c b/board/compulab/cm_fx6/cm_fx6.c
 index 10e31b6..d79cd5f 100644
 --- a/board/compulab/cm_fx6/cm_fx6.c
 +++ b/board/compulab/cm_fx6/cm_fx6.c
 @@ -9,11 +9,13 @@
   */
  
  #include common.h
 +#include dm.h
  #include fsl_esdhc.h
  #include miiphy.h
  #include netdev.h
  #include fdt_support.h
  #include sata.h
 +#include serial_mxc.h
  #include asm/arch/crm_regs.h
  #include asm/arch/sys_proto.h
  #include asm/arch/iomux.h
 @@ -509,3 +511,11 @@ u32 get_board_rev(void)
   return cl_eeprom_get_board_rev();
  }
  
 +static struct mxc_serial_platdata cm_fx6_mxc_serial_plat = {
 + .reg = (struct mxc_uart *)UART4_BASE,
 +};
 +
 +U_BOOT_DEVICE(cm_fx6_serial) = {
 + .name   = serial_mxc,
 + .platdata = cm_fx6_mxc_serial_plat,
 +};
 diff --git a/include/configs/cm_fx6.h b/include/configs/cm_fx6.h
 index 10d02b4..1f55150 100644
 --- a/include/configs/cm_fx6.h
 +++ b/include/configs/cm_fx6.h
 @@ -21,6 +21,17 @@
  #define CONFIG_MACH_TYPE 4273
  #define CONFIG_SYS_HZ1000
  
 +#ifndef CONFIG_SPL_BUILD
 +#define CONFIG_DM
 +#define CONFIG_CMD_DM
 +
 +#define CONFIG_DM_GPIO
 +#define CONFIG_CMD_GPIO
 +
 +#define CONFIG_DM_SERIAL
 +#define CONFIG_SYS_MALLOC_F_LEN  (1  10)
 +#endif
 +
  /* Display information on boot */
  #define CONFIG_DISPLAY_CPUINFO
  #define CONFIG_DISPLAY_BOARDINFO
 

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

[U-Boot] Gigabit support in UBOOT

2014-09-17 Thread sreejugr

Hi,

I'm using an ARM 922 based board.
It has gigabit ethernet support only. 
U-Boot Version used : U-Boot 2009.03

Problem faced: Unable to ping from my board.

 The terminal ends up with showing the Hardware address only. It's NOT
showing if the IP address is alive or not. On debugging I found that it
hangs after calling the function NetSendUDPPacket(NetServerEther,
TftpServerIP, TftpServerPort, TftpOurPort, len); defind in /src/net/tftp.c

If tftpcommand is issued it shows like this in the terminal.

TFTP from server 10.176.18.85; our IP address is 10.176.18.86; sending
through gateway 10.176.18.1
Filename 'uImage_er922'.

Load address: 0x1150
Loading: *

Only the '*' is displayed. I was expecting 'E' or 'T' will be displayed. But
nothing is displayed in the terminal.

Also please note that I have connected my board to the PC directly and the
the 1000Mbps led lits up after negotiation.

Would like to know the reason for that.


Regards

Sreeju GR







--
View this message in context: 
http://u-boot.10912.n7.nabble.com/Gigabit-support-in-UBOOT-tp189603.html
Sent from the U-Boot mailing list archive at Nabble.com.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] A minor question on a Driver Model function

On 09/17/14 11:18, Masahiro Yamada wrote:
 Hi Igor,
 
 
 
 On Mon, 15 Sep 2014 11:04:20 +0300
 Igor Grinberg grinb...@compulab.co.il wrote:
 
 Hi,

 On 09/14/14 21:28, Simon Glass wrote:
 Hi Masahiro,

 On 12 September 2014 05:25, Masahiro Yamada yamad...@jp.panasonic.com 
 wrote:
 Hi Simon,


 I have a qustion about lists_driver_lookup_name() function.



 for (entry = drv; entry != drv + n_ents; entry++) {
 if (strncmp(name, entry-name, len))
 continue;

 /* Full match */
 if (len == strlen(entry-name))
 return entry;
 }




 Why is this not like follows?




 for (entry = drv; entry != drv + n_ents; entry++) {
 if (!strcmp(name, entry-name))
 return entry;
 }

 I would suggest still using strncmp as it is safer,
 but count also the '\0', so something like:
 
 Why safer?
 
 Could you give me more detailed explanation?

Well, I'm not an expert in s/w security, but I'll try to explain...

strcmp() walks the strings and never stops until it reaches '\0'
in either of strings.
In theory (or by mistake), you can supply strings that are not '\0'
terminated and strcmp() will continue running on addresses where
it is not supposed to.
This can lead to exceptions, crashes, etc..

Since this is a library code, I would expect it to be immune to
that kind of problem.

But, again, I'm not an expert in this area, so its only a suggestion.

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

Re: [U-Boot] [PATCH v2 07/11] dm: imx: Add error checking to setup_i2c()

Hi Igor,

On 17 September 2014 02:37, Igor Grinberg grinb...@compulab.co.il wrote:

 Hi Simon,

 On 09/17/14 06:51, Simon Glass wrote:
  Since this function can fail, check its return value.
 
  Signed-off-by: Simon Glass s...@chromium.org
  ---
 
  Changes in v2:
  - Add new patch to add error checking to setup_i2c()
 
   arch/arm/imx-common/i2c-mxv7.c| 24 -
   arch/arm/include/asm/imx-common/mxc_i2c.h |  4 ++--
   board/compulab/cm_fx6/cm_fx6.c| 35
 +--
   3 files changed, 45 insertions(+), 18 deletions(-)
 
  diff --git a/arch/arm/imx-common/i2c-mxv7.c
 b/arch/arm/imx-common/i2c-mxv7.c
  index a580873..70cff5c 100644
  --- a/arch/arm/imx-common/i2c-mxv7.c
  +++ b/arch/arm/imx-common/i2c-mxv7.c
  @@ -69,15 +69,29 @@ static void * const i2c_bases[] = {
   };
 
   /* i2c_index can be from 0 - 2 */
  -void setup_i2c(unsigned i2c_index, int speed, int slave_addr,
  - struct i2c_pads_info *p)
  +int setup_i2c(unsigned i2c_index, int speed, int slave_addr,
  +   struct i2c_pads_info *p)
   {
  + int ret;
  +
if (i2c_index = ARRAY_SIZE(i2c_bases))
  - return;
  + return -EINVAL;
/* Enable i2c clock */
  - enable_i2c_clk(1, i2c_index);
  + ret = enable_i2c_clk(1, i2c_index);
  + if (ret)
  + goto err_clk;
  +
/* Make sure bus is idle */
  - force_idle_bus(p);
  + ret = force_idle_bus(p);
  + if (ret)
  + goto err_idle;
  +
bus_i2c_init(i2c_bases[i2c_index], speed, slave_addr,
force_idle_bus, p);
  +
  + return 0;
  +
  +err_idle:
  +err_clk:
  + return ret;
   }
  diff --git a/arch/arm/include/asm/imx-common/mxc_i2c.h
 b/arch/arm/include/asm/imx-common/mxc_i2c.h
  index 182c2f3..af86163 100644
  --- a/arch/arm/include/asm/imx-common/mxc_i2c.h
  +++ b/arch/arm/include/asm/imx-common/mxc_i2c.h
  @@ -52,8 +52,8 @@ struct i2c_pads_info {
mx6q_##name : mx6s_##name
   #endif
 
  -void setup_i2c(unsigned i2c_index, int speed, int slave_addr,
  - struct i2c_pads_info *p);
  +int setup_i2c(unsigned i2c_index, int speed, int slave_addr,
  +   struct i2c_pads_info *p);
   void bus_i2c_init(void *base, int speed, int slave_addr,
int (*idle_bus_fn)(void *p), void *p);
   int bus_i2c_read(void *base, uchar chip, uint addr, int alen, uchar
 *buf,
  diff --git a/board/compulab/cm_fx6/cm_fx6.c
 b/board/compulab/cm_fx6/cm_fx6.c
  index fdb8ebf..62c625a 100644
  --- a/board/compulab/cm_fx6/cm_fx6.c
  +++ b/board/compulab/cm_fx6/cm_fx6.c
  @@ -69,7 +69,7 @@ static iomux_v3_cfg_t const sata_pads[] = {
IOMUX_PADS(PAD_EIM_BCLK__GPIO6_IO31   | MUX_PAD_CTRL(NO_PAD_CTRL)),
   };
 
  -static void cm_fx6_setup_issd(void)
  +static int cm_fx6_setup_issd(void)
   {
SETUP_IOMUX_PADS(sata_pads);
/* Make sure this gpio has logical 0 value */
  @@ -79,14 +79,18 @@ static void cm_fx6_setup_issd(void)
cm_fx6_sata_power(0);
mdelay(250);
cm_fx6_sata_power(1);
  +
  + return 0;
   }
 
   #define CM_FX6_SATA_INIT_RETRIES 10
   int sata_initialize(void)
   {
  - int err, i;
  + int err, i, ret;
 
  - cm_fx6_setup_issd();
  + ret = cm_fx6_setup_issd();
  + if (ret)
  + return ret;

 Hmm.. cm-fx6 may have iSSD not assembled and in this case
 it has bypasses for a (m)SATA socket on the baseboard.
 The socketed device of course is not controlled by those GPIOs.
 Therefore, I think, it would be incorrect to fail the boot process
 if there is a problem with an iSSD GPIO...
 Instead a warning message will be enough. Something like:

 ret = cm_fx6_setup_issd();
 if (ret)
 printf(Warning: iSSD setup failed!\n);


OK, my intent here was to add the missing gpio_request() calls so that
things would work with DM. I think I am being drawn into board error
policy! I'll give it another spin based on your comments.



 and then continue to the rest of SATA init.

for (i = 0; i  CM_FX6_SATA_INIT_RETRIES; i++) {
err = setup_sata();
if (err) {
  @@ -141,14 +145,25 @@ I2C_PADS(i2c2_pads,
 IMX_GPIO_NR(1, 6));
 
 
  -static void cm_fx6_setup_i2c(void)
  +static int cm_fx6_setup_i2c(void)
   {
  - setup_i2c(0, CONFIG_SYS_I2C_SPEED, 0x7f, I2C_PADS_INFO(i2c0_pads));
  - setup_i2c(1, CONFIG_SYS_I2C_SPEED, 0x7f, I2C_PADS_INFO(i2c1_pads));
  - setup_i2c(2, CONFIG_SYS_I2C_SPEED, 0x7f, I2C_PADS_INFO(i2c2_pads));
  + int ret;
  +
  + ret = setup_i2c(0, CONFIG_SYS_I2C_SPEED, 0x7f,
  + I2C_PADS_INFO(i2c0_pads));
  + if (!ret) {
  + ret = setup_i2c(1, CONFIG_SYS_I2C_SPEED, 0x7f,
  + I2C_PADS_INFO(i2c1_pads));
  + }
  + if (!ret) {
  + ret = setup_i2c(2, CONFIG_SYS_I2C_SPEED, 0x7f,
  + I2C_PADS_INFO(i2c2_pads));

Re: [U-Boot] [PATCH v2 08/11] dm: imx: Use gpio_request() to request GPIOs

Hi Igor,

On 17 September 2014 06:13, Igor Grinberg grinb...@compulab.co.il wrote:

 Hi Simon,

 On 09/17/14 06:51, Simon Glass wrote:
  GPIOs should be requested before use. Without this, driver model will not
  permit the GPIO to be used.
 
  Signed-off-by: Simon Glass s...@chromium.org
  ---
 
  Changes in v2:
  - Check return values of gpio_request()
 
   arch/arm/imx-common/i2c-mxv7.c | 24 
   board/compulab/cm_fx6/cm_fx6.c | 15 +++
   board/compulab/cm_fx6/common.c |  7 +++
   3 files changed, 46 insertions(+)
 
  diff --git a/arch/arm/imx-common/i2c-mxv7.c
 b/arch/arm/imx-common/i2c-mxv7.c
  index 70cff5c..aaf6936 100644
  --- a/arch/arm/imx-common/i2c-mxv7.c
  +++ b/arch/arm/imx-common/i2c-mxv7.c
  @@ -4,6 +4,7 @@
* SPDX-License-Identifier:  GPL-2.0+
*/
   #include common.h
  +#include malloc.h
   #include asm/arch/clock.h
   #include asm/arch/imx-regs.h
   #include asm/errno.h
  @@ -72,10 +73,26 @@ static void * const i2c_bases[] = {
   int setup_i2c(unsigned i2c_index, int speed, int slave_addr,
  struct i2c_pads_info *p)
   {
  + char *name1, *name2;
int ret;
 
if (i2c_index = ARRAY_SIZE(i2c_bases))
return -EINVAL;
  +
  + name1 = malloc(9);
  + name2 = malloc(9);
  + if (!name1 || !name2)
  + return -ENOMEM;
  + sprintf(name1, i2c_sda%d, i2c_index);
  + sprintf(name2, i2c_scl%d, i2c_index);
  + ret = gpio_request(p-sda.gp, name1);
  + if (ret)
  + goto err_req1;
  +
  + ret = gpio_request(p-scl.gp, name2);
  + if (ret)
  + goto err_req2;
  +
/* Enable i2c clock */
ret = enable_i2c_clk(1, i2c_index);
if (ret)
  @@ -93,5 +110,12 @@ int setup_i2c(unsigned i2c_index, int speed, int
 slave_addr,
 
   err_idle:
   err_clk:
  + gpio_free(p-scl.gp);
  +err_req2:
  + gpio_free(p-sda.gp);
  +err_req1:
  + free(name1);
  + free(name2);
  +
return ret;
   }
  diff --git a/board/compulab/cm_fx6/cm_fx6.c
 b/board/compulab/cm_fx6/cm_fx6.c
  index 62c625a..10e31b6 100644
  --- a/board/compulab/cm_fx6/cm_fx6.c
  +++ b/board/compulab/cm_fx6/cm_fx6.c
  @@ -71,8 +71,21 @@ static iomux_v3_cfg_t const sata_pads[] = {
 
   static int cm_fx6_setup_issd(void)
   {
  + int ret;
  + int i;
  +
SETUP_IOMUX_PADS(sata_pads);
  +
  + for (i = 0; i  ARRAY_SIZE(cm_fx6_issd_gpios); i++) {
  + ret = gpio_request(cm_fx6_issd_gpios[i], sata);
  + if (ret)
  + return ret;
  + }
  +
/* Make sure this gpio has logical 0 value */
  + ret = gpio_request(CM_FX6_SATA_PWLOSS_INT, sata_pwloss_int);
  + if (ret)
  + return ret;
gpio_direction_output(CM_FX6_SATA_PWLOSS_INT, 0);
udelay(100);
 
  @@ -182,6 +195,7 @@ static int cm_fx6_usb_hub_reset(void)
}
 
SETUP_IOMUX_PAD(PAD_SD3_RST__GPIO7_IO08 |
 MUX_PAD_CTRL(NO_PAD_CTRL));
  + gpio_request(CM_FX6_USB_HUB_RST, usb_hub_rst);

 This is confusing... This GPIO should be already requested
 several lines above.


OK


gpio_direction_output(CM_FX6_USB_HUB_RST, 0);
udelay(10);
gpio_direction_output(CM_FX6_USB_HUB_RST, 1);
  @@ -339,6 +353,7 @@ int board_eth_init(bd_t *bis)
 
SETUP_IOMUX_PADS(enet_pads);
/* phy reset */
  + gpio_request(CM_FX6_ENET_NRST, enet_nrst);

 Error check?
 This one also should not fail the boot process, just abort the
 Ethernet init.


OK



gpio_direction_output(CM_FX6_ENET_NRST, 0);
udelay(500);
gpio_set_value(CM_FX6_ENET_NRST, 1);
  diff --git a/board/compulab/cm_fx6/common.c
 b/board/compulab/cm_fx6/common.c
  index 1f39679..e4d7e2e 100644
  --- a/board/compulab/cm_fx6/common.c
  +++ b/board/compulab/cm_fx6/common.c
  @@ -79,6 +79,13 @@ void cm_fx6_set_ecspi_iomux(void)
 
   int board_spi_cs_gpio(unsigned bus, unsigned cs)
   {
  +#ifndef CONFIG_SPL_BUILD
  + int ret;
  +
  + ret = gpio_request(CM_FX6_ECSPI_BUS0_CS0, ecspi_bus0_cs0);
  + if (ret)
  + return ret;
  +#endif

 Is there a reason for excluding this request from spl builds?
 We do build with CONFIG_SPL_GPIO_SUPPORT and we don't have a
 problem with spl size.
 So, if there is no strong reason to exclude it from spl build,
 I'd like to remove the #ifndef.


It isn't supported by DM yet.



return (bus == 0  cs == 0) ? (CM_FX6_ECSPI_BUS0_CS0) : -1;
   }
   #endif
 

 --
 Regards,
 Igor.


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

Re: [U-Boot] [PATCH v2 09/11] dm: imx: gpio: Support driver model in MXC gpio driver

Hi Igor,

On 17 September 2014 07:00, Igor Grinberg grinb...@compulab.co.il wrote:

 On 09/17/14 06:51, Simon Glass wrote:
  Add driver model support with this driver. In this case the platform data
  is in the driver. It would be better to put this into an SOC-specific
 file,
  but this is best attempted when more boards are moved over to use driver
  model.
 
  Signed-off-by: Simon Glass s...@chromium.org
  ---
 
  Changes in v2:
  - Change 'reserved' to 'requested'
  - Add an internal function to check if a GPIO is requested
  - Tidy up confusing code that creates names for gpio_request()
 
   drivers/gpio/mxc_gpio.c | 302
 +++-
   1 file changed, 301 insertions(+), 1 deletion(-)
 
  diff --git a/drivers/gpio/mxc_gpio.c b/drivers/gpio/mxc_gpio.c
  index 6a572d5..9435d2f 100644
  --- a/drivers/gpio/mxc_gpio.c
  +++ b/drivers/gpio/mxc_gpio.c

 [...]

  +static int mxc_gpio_get_state(struct udevice *dev, unsigned int offset,
  +   char *buf, int bufsize)
  +{
  + struct gpio_dev_priv *uc_priv = dev-uclass_priv;
  + struct mxc_bank_info *bank = dev_get_priv(dev);
  + const char *label;
  + bool is_output;
  + int size;
  +
  + label = bank-label[offset];
  + is_output = mxc_gpio_is_output(bank-regs, offset);
  + size = snprintf(buf, bufsize, %s%d: ,
  + uc_priv-bank_name ? uc_priv-bank_name : ,
 offset);
  + buf += size;
  + bufsize -= size;
  + snprintf(buf, bufsize, %s: %d [%c]%s%s,
  +  is_output ? out :  in,
  +  is_output ?
  + mxc_gpio_bank_get_output_value(bank-regs, offset)
 :
  + mxc_gpio_bank_get_value(bank-regs, offset),
  +  *label ? 'x' : ' ',
  +  *label ?   : ,

 This is a check if the gpio is requested, right?
 I think the new function gpio_is_requested() can be of hand here
 instead of open coding this.


OK



  +  label);
  +
  + return 0;
  +}
  +

 [...]

  +static int mxc_gpio_free(struct udevice *dev, unsigned offset)
  +{
  + struct mxc_bank_info *bank = dev_get_priv(dev);
  + int ret;
  +
  + ret = check_requested(dev, offset, __func__);
  + if (ret)
  + return ret;

 In case of not requested gpio,
 should we really print the error message and return -EPERM?
 Or may be adopt free() behavior and just return silently?
 Linux gpiolib gpio_free() uses WARN_ON(extra_checks) for
 not requested cases, so it shouts only in DEBUG cases.


I'm not sure - I intend to push this up to the DM layer at some point. I
feel that keeping track of GPIO requested/free should be a common feature
of the uclass rather than implemented in each driver. But until we have
enough drivers to make it clear that this is acceptable, I'm leaving it as
it is.

So for at least now I think this is correct. We might consider bringing in
some sort of WARN system to U-Boot. The caller can ignore the return value
anyway.

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

Re: [U-Boot] [PATCH 00/35][RFC] arm: socfpga: Usability fixes

2014-09-17 Thread Wolfgang Denk

Dear Chin Liang See,

In message 1410952049.7769.11.ca...@clsee-virtualbox.altera.com you wrote:

 Hmmm... actually I can get it works well for my Altera dev kit. The
 get_dram_size would take in the argument PHYS_SDRAM_1_SIZE. From here,
 the function will ensure the memory specified can read and writable. If
 its failing here, probably the SDRAM access might have issue. FYI,
 PHYS_SDRAM_1_SIZE is 0x4000 for 1GB.

Normally, get_dram_size() would be called with a size argument that is
_larger_ (twice as big) as the biggest possible memory configuration
on the respective device.  Otherwise it can only detect smaller memory
sizes, but would fail to detect if a bigger memory device is
installed by accident.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Have you lived in this village all your life?No, not yet.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] compulab: eeprom: add default eeprom bus

On 09/17/14 15:59, Nikita Kiryanov wrote:
 Add default eeprom bus setting.
 This addresses the trimslice compile error that was introduced
 with the addition of this setting.
 
 Cc: Albert ARIBAUD albert.u.b...@aribaud.net
 Cc: Igor Grinberg grinb...@compulab.co.il
 Signed-off-by: Nikita Kiryanov nik...@compulab.co.il

Acked-by: Igor Grinberg grinb...@compulab.co.il

Albert, this should be a temporary fix to not break the trimslice support.
We intend to rework this while switching Kconfig for all boards.

Thanks!

 ---
  board/compulab/common/eeprom.c | 4 
  1 file changed, 4 insertions(+)
 
 diff --git a/board/compulab/common/eeprom.c b/board/compulab/common/eeprom.c
 index 85442cd..2df3ada 100644
 --- a/board/compulab/common/eeprom.c
 +++ b/board/compulab/common/eeprom.c
 @@ -15,6 +15,10 @@
  # define CONFIG_SYS_I2C_EEPROM_ADDR_LEN  1
  #endif
  
 +#ifndef CONFIG_SYS_I2C_EEPROM_BUS
 +#define CONFIG_SYS_I2C_EEPROM_BUS0
 +#endif
 +
  #define EEPROM_LAYOUT_VER_OFFSET 44
  #define BOARD_SERIAL_OFFSET  20
  #define BOARD_SERIAL_OFFSET_LEGACY   8
 

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

Re: [U-Boot] [PATCH v2 07/11] dm: imx: Add error checking to setup_i2c()

Hi Simon,

On 09/17/14 16:56, Simon Glass wrote:
 Hi Igor,
 
 On 17 September 2014 02:37, Igor Grinberg grinb...@compulab.co.il 
 mailto:grinb...@compulab.co.il wrote:
 
 Hi Simon,
 
 On 09/17/14 06:51, Simon Glass wrote:
  Since this function can fail, check its return value.
 
  Signed-off-by: Simon Glass s...@chromium.org 
 mailto:s...@chromium.org
  ---
 
  Changes in v2:
  - Add new patch to add error checking to setup_i2c()
 
   arch/arm/imx-common/i2c-mxv7.c| 24 -
   arch/arm/include/asm/imx-common/mxc_i2c.h |  4 ++--
   board/compulab/cm_fx6/cm_fx6.c| 35 
 +--
   3 files changed, 45 insertions(+), 18 deletions(-)
 
  diff --git a/arch/arm/imx-common/i2c-mxv7.c 
 b/arch/arm/imx-common/i2c-mxv7.c
  index a580873..70cff5c 100644
  --- a/arch/arm/imx-common/i2c-mxv7.c
  +++ b/arch/arm/imx-common/i2c-mxv7.c
  @@ -69,15 +69,29 @@ static void * const i2c_bases[] = {
   };
 
   /* i2c_index can be from 0 - 2 */
  -void setup_i2c(unsigned i2c_index, int speed, int slave_addr,
  - struct i2c_pads_info *p)
  +int setup_i2c(unsigned i2c_index, int speed, int slave_addr,
  +   struct i2c_pads_info *p)
   {
  + int ret;
  +
if (i2c_index = ARRAY_SIZE(i2c_bases))
  - return;
  + return -EINVAL;
/* Enable i2c clock */
  - enable_i2c_clk(1, i2c_index);
  + ret = enable_i2c_clk(1, i2c_index);
  + if (ret)
  + goto err_clk;
  +
/* Make sure bus is idle */
  - force_idle_bus(p);
  + ret = force_idle_bus(p);
  + if (ret)
  + goto err_idle;
  +
bus_i2c_init(i2c_bases[i2c_index], speed, slave_addr,
force_idle_bus, p);
  +
  + return 0;
  +
  +err_idle:
  +err_clk:
  + return ret;
   }
  diff --git a/arch/arm/include/asm/imx-common/mxc_i2c.h 
 b/arch/arm/include/asm/imx-common/mxc_i2c.h
  index 182c2f3..af86163 100644
  --- a/arch/arm/include/asm/imx-common/mxc_i2c.h
  +++ b/arch/arm/include/asm/imx-common/mxc_i2c.h
  @@ -52,8 +52,8 @@ struct i2c_pads_info {
mx6q_##name : mx6s_##name
   #endif
 
  -void setup_i2c(unsigned i2c_index, int speed, int slave_addr,
  - struct i2c_pads_info *p);
  +int setup_i2c(unsigned i2c_index, int speed, int slave_addr,
  +   struct i2c_pads_info *p);
   void bus_i2c_init(void *base, int speed, int slave_addr,
int (*idle_bus_fn)(void *p), void *p);
   int bus_i2c_read(void *base, uchar chip, uint addr, int alen, uchar 
 *buf,
  diff --git a/board/compulab/cm_fx6/cm_fx6.c 
 b/board/compulab/cm_fx6/cm_fx6.c
  index fdb8ebf..62c625a 100644
  --- a/board/compulab/cm_fx6/cm_fx6.c
  +++ b/board/compulab/cm_fx6/cm_fx6.c
  @@ -69,7 +69,7 @@ static iomux_v3_cfg_t const sata_pads[] = {
IOMUX_PADS(PAD_EIM_BCLK__GPIO6_IO31   | 
 MUX_PAD_CTRL(NO_PAD_CTRL)),
   };
 
  -static void cm_fx6_setup_issd(void)
  +static int cm_fx6_setup_issd(void)
   {
SETUP_IOMUX_PADS(sata_pads);
/* Make sure this gpio has logical 0 value */
  @@ -79,14 +79,18 @@ static void cm_fx6_setup_issd(void)
cm_fx6_sata_power(0);
mdelay(250);
cm_fx6_sata_power(1);
  +
  + return 0;
   }
 
   #define CM_FX6_SATA_INIT_RETRIES 10
   int sata_initialize(void)
   {
  - int err, i;
  + int err, i, ret;
 
  - cm_fx6_setup_issd();
  + ret = cm_fx6_setup_issd();
  + if (ret)
  + return ret;
 
 Hmm.. cm-fx6 may have iSSD not assembled and in this case
 it has bypasses for a (m)SATA socket on the baseboard.
 The socketed device of course is not controlled by those GPIOs.
 Therefore, I think, it would be incorrect to fail the boot process
 if there is a problem with an iSSD GPIO...
 Instead a warning message will be enough. Something like:
 
 ret = cm_fx6_setup_issd();
 if (ret)
 printf(Warning: iSSD setup failed!\n);
 
 
 OK, my intent here was to add the missing gpio_request() calls so that things 
 would work with DM. I think I am being drawn into board error policy! I'll 
 give it another spin based on your comments.

I understand. Thanks for going for another round.
If you feel like it gets too much board specific, we can send a follow up.

  
 
 
 and then continue to the rest of SATA init.
 
for (i = 0; i  CM_FX6_SATA_INIT_RETRIES; i++) {
err = setup_sata();
if (err) {
  @@ -141,14 +145,25 @@ I2C_PADS(i2c2_pads,
 IMX_GPIO_NR(1, 6));

Re: [U-Boot] [PATCH v2 08/11] dm: imx: Use gpio_request() to request GPIOs

On 09/17/14 17:00, Simon Glass wrote:
 Hi Igor,
 
 On 17 September 2014 06:13, Igor Grinberg grinb...@compulab.co.il 
 mailto:grinb...@compulab.co.il wrote:
 
 Hi Simon,
 
 On 09/17/14 06:51, Simon Glass wrote:
  GPIOs should be requested before use. Without this, driver model will 
 not
  permit the GPIO to be used.
 
  Signed-off-by: Simon Glass s...@chromium.org 
 mailto:s...@chromium.org
  ---
 
  Changes in v2:
  - Check return values of gpio_request()
 
   arch/arm/imx-common/i2c-mxv7.c | 24 
   board/compulab/cm_fx6/cm_fx6.c | 15 +++
   board/compulab/cm_fx6/common.c |  7 +++
   3 files changed, 46 insertions(+)
 

[...]

  diff --git a/board/compulab/cm_fx6/common.c 
 b/board/compulab/cm_fx6/common.c
  index 1f39679..e4d7e2e 100644
  --- a/board/compulab/cm_fx6/common.c
  +++ b/board/compulab/cm_fx6/common.c
  @@ -79,6 +79,13 @@ void cm_fx6_set_ecspi_iomux(void)
 
   int board_spi_cs_gpio(unsigned bus, unsigned cs)
   {
  +#ifndef CONFIG_SPL_BUILD
  + int ret;
  +
  + ret = gpio_request(CM_FX6_ECSPI_BUS0_CS0, ecspi_bus0_cs0);
  + if (ret)
  + return ret;
  +#endif
 
 Is there a reason for excluding this request from spl builds?
 We do build with CONFIG_SPL_GPIO_SUPPORT and we don't have a
 problem with spl size.
 So, if there is no strong reason to exclude it from spl build,
 I'd like to remove the #ifndef.
 
 
 It isn't supported by DM yet.

AFAICS, gpio_request() is available for SPL.
So in such case the non-DM version will be used and
I can't see any problem with this (unless it does not work for some reason).

  
 
 
return (bus == 0  cs == 0) ? (CM_FX6_ECSPI_BUS0_CS0) : -1;
   }
   #endif
 
 
 --
 Regards,
 Igor.
 
 
 Regards,
 Simon
 

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

Re: [U-Boot] [PATCH v2 09/11] dm: imx: gpio: Support driver model in MXC gpio driver

On 09/17/14 17:03, Simon Glass wrote:
 Hi Igor,
 
 On 17 September 2014 07:00, Igor Grinberg grinb...@compulab.co.il 
 mailto:grinb...@compulab.co.il wrote:
 
 On 09/17/14 06:51, Simon Glass wrote:
  Add driver model support with this driver. In this case the platform 
 data
  is in the driver. It would be better to put this into an SOC-specific 
 file,
  but this is best attempted when more boards are moved over to use driver
  model.
 
  Signed-off-by: Simon Glass s...@chromium.org 
 mailto:s...@chromium.org
  ---
 
  Changes in v2:
  - Change 'reserved' to 'requested'
  - Add an internal function to check if a GPIO is requested
  - Tidy up confusing code that creates names for gpio_request()
 
   drivers/gpio/mxc_gpio.c | 302 
 +++-
   1 file changed, 301 insertions(+), 1 deletion(-)
 
  diff --git a/drivers/gpio/mxc_gpio.c b/drivers/gpio/mxc_gpio.c
  index 6a572d5..9435d2f 100644
  --- a/drivers/gpio/mxc_gpio.c
  +++ b/drivers/gpio/mxc_gpio.c
 
 [...]

[...]

  +static int mxc_gpio_free(struct udevice *dev, unsigned offset)
  +{
  + struct mxc_bank_info *bank = dev_get_priv(dev);
  + int ret;
  +
  + ret = check_requested(dev, offset, __func__);
  + if (ret)
  + return ret;
 
 In case of not requested gpio,
 should we really print the error message and return -EPERM?
 Or may be adopt free() behavior and just return silently?
 Linux gpiolib gpio_free() uses WARN_ON(extra_checks) for
 not requested cases, so it shouts only in DEBUG cases.
 
 
 I'm not sure - I intend to push this up to the DM layer at some point.
 I feel that keeping track of GPIO requested/free should be a common
 feature of the uclass rather than implemented in each driver.

Agreed. I've got the same feeling while looking at this.

 But until we have enough drivers to make it clear that this is acceptable,
 I'm leaving it as it is.
 
 So for at least now I think this is correct. We might consider bringing
 in some sort of WARN system to U-Boot. The caller can ignore the return
 value anyway.

Ok.


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

Re: [U-Boot] [PATCH v2 08/11] dm: imx: Use gpio_request() to request GPIOs

Hi Igor,

On 17 September 2014 08:31, Igor Grinberg grinb...@compulab.co.il wrote:

 On 09/17/14 17:00, Simon Glass wrote:
  Hi Igor,
 
  On 17 September 2014 06:13, Igor Grinberg grinb...@compulab.co.il
 mailto:grinb...@compulab.co.il wrote:
 
  Hi Simon,
 
  On 09/17/14 06:51, Simon Glass wrote:
   GPIOs should be requested before use. Without this, driver model
 will not
   permit the GPIO to be used.
  
   Signed-off-by: Simon Glass s...@chromium.org mailto:
 s...@chromium.org
   ---
  
   Changes in v2:
   - Check return values of gpio_request()
  
arch/arm/imx-common/i2c-mxv7.c | 24 
board/compulab/cm_fx6/cm_fx6.c | 15 +++
board/compulab/cm_fx6/common.c |  7 +++
3 files changed, 46 insertions(+)
  

 [...]

   diff --git a/board/compulab/cm_fx6/common.c
 b/board/compulab/cm_fx6/common.c
   index 1f39679..e4d7e2e 100644
   --- a/board/compulab/cm_fx6/common.c
   +++ b/board/compulab/cm_fx6/common.c
   @@ -79,6 +79,13 @@ void cm_fx6_set_ecspi_iomux(void)
  
int board_spi_cs_gpio(unsigned bus, unsigned cs)
{
   +#ifndef CONFIG_SPL_BUILD
   + int ret;
   +
   + ret = gpio_request(CM_FX6_ECSPI_BUS0_CS0, ecspi_bus0_cs0);
   + if (ret)
   + return ret;
   +#endif
 
  Is there a reason for excluding this request from spl builds?
  We do build with CONFIG_SPL_GPIO_SUPPORT and we don't have a
  problem with spl size.
  So, if there is no strong reason to exclude it from spl build,
  I'd like to remove the #ifndef.
 
 
  It isn't supported by DM yet.

 AFAICS, gpio_request() is available for SPL.
 So in such case the non-DM version will be used and
 I can't see any problem with this (unless it does not work for some
 reason).


I suggest that if you wanted the gpio_request() in the non-DM case you
would already have added it?

I would prefer not to have an #ifdef CONFIG_DM_GPIO here also. Can we
revisit when DM supports SPL?

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

[U-Boot] [PATCH v3 0/11] dm: imx: Add driver model support for GPIO and serial on cm_fx6

This series adjusts the IMX serial and GPIO drivers to support driver model.
As an example of its use, the recently-added cm_fx6 board is converted over
to driver model.

Some minor driver model core changed are required to make this work and
these are included with this series.

Changes in v3:
- Add a check for the Ethernet gpio_request() also
- Add a comment for the CONFIG_SPL_BUILD #ifdef
- Just warn when one of the board init stages fails
- Use gpio_is_requested() in one more place

Changes in v2:
- Add an internal function to check if a GPIO is requested
- Add new patch to add error checking to setup_i2c()
- Add patch to display error number when an error occurs in initcall
- Change 'reserved' to 'requested'
- Check return values of gpio_request()
- Tidy up confusing code that creates names for gpio_request()
- Use the correct namespace for the platform data

Simon Glass (11):
  dm: linker_lists: Add a way to declare multiple objects
  dm: core: Allow a list of devices to be declared in one step
  dm: core: Allow device_bind() to used without CONFIG_OF_CONTROL
  initcall: Display error number when an error occurs
  dm: serial: Don't require device tree to configure a console
  dm: serial: Put common code into separate functions
  imx: Add error checking to setup_i2c()
  dm: imx: Use gpio_request() to request GPIOs
  dm: imx: gpio: Support driver model in MXC gpio driver
  dm: imx: serial: Support driver model in the MXC serial driver
  dm: imx: Move cm_fx6 to use driver model for serial and GPIO

 arch/arm/imx-common/i2c-mxv7.c|  48 -
 arch/arm/include/asm/imx-common/mxc_i2c.h |   4 +-
 board/compulab/cm_fx6/cm_fx6.c|  88 +++--
 board/compulab/cm_fx6/common.c|   8 +
 drivers/core/device.c |   7 +-
 drivers/gpio/mxc_gpio.c   | 304 +-
 drivers/serial/serial-uclass.c|  35 ++--
 drivers/serial/serial_mxc.c   | 170 ++---
 include/configs/cm_fx6.h  |  11 ++
 include/dm/platdata.h |   4 +
 include/linker_lists.h|  21 +++
 include/serial_mxc.h  |  14 ++
 lib/initcall.c|   8 +-
 13 files changed, 657 insertions(+), 65 deletions(-)
 create mode 100644 include/serial_mxc.h

-- 
2.1.0.rc2.206.gedb03e5

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

[U-Boot] [PATCH v3 03/11] dm: core: Allow device_bind() to used without CONFIG_OF_CONTROL

The sequence number support in driver model requires device tree control.
It should be skipped if CONFIG_OF_CONTROL is not defined, and should not
require functions from fdtdec.

Signed-off-by: Simon Glass s...@chromium.org
---

Changes in v3: None
Changes in v2: None

 drivers/core/device.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/core/device.c b/drivers/core/device.c
index 166b073..ef41a9b 100644
--- a/drivers/core/device.c
+++ b/drivers/core/device.c
@@ -106,13 +106,16 @@ int device_bind(struct udevice *parent, struct driver 
*drv, const char *name,
 * a 'requested' sequence, and will be resolved (and -seq updated)
 * when the device is probed.
 */
-   dev-req_seq = fdtdec_get_int(gd-fdt_blob, of_offset, reg, -1);
dev-seq = -1;
+#ifdef CONFIG_OF_CONTROL
+   dev-req_seq = fdtdec_get_int(gd-fdt_blob, of_offset, reg, -1);
if (uc-uc_drv-name  of_offset != -1) {
fdtdec_get_alias_seq(gd-fdt_blob, uc-uc_drv-name, of_offset,
 dev-req_seq);
}
-
+#else
+   dev-req_seq = -1;
+#endif
if (!dev-platdata  drv-platdata_auto_alloc_size)
dev-flags |= DM_FLAG_ALLOC_PDATA;
 
-- 
2.1.0.rc2.206.gedb03e5

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

[U-Boot] [PATCH v3 01/11] dm: linker_lists: Add a way to declare multiple objects

The existing ll_entry_declare() permits a single element of the list to
be added to a linker list. Sometimes we want to add several objects at
once. To avoid lots of messy declarations, add a macro to support this.

Signed-off-by: Simon Glass s...@chromium.org
---

Changes in v3: None
Changes in v2: None

 include/linker_lists.h | 21 +
 1 file changed, 21 insertions(+)

diff --git a/include/linker_lists.h b/include/linker_lists.h
index 557e627..32cc9fc 100644
--- a/include/linker_lists.h
+++ b/include/linker_lists.h
@@ -141,6 +141,27 @@
section(.u_boot_list_2_#_list_2_#_name)))
 
 /**
+ * ll_entry_declare_list() - Declare a list of link-generated array entries
+ * @_type: Data type of each entry
+ * @_name: Name of the entry
+ * @_list: name of the list. Should contain only characters allowed
+ * in a C variable name!
+ *
+ * This is like ll_entry_declare() but creates multiple entries. It should
+ * be assigned to an array.
+ *
+ * ll_entry_declare_list(struct my_sub_cmd, my_sub_cmd, cmd_sub, cmd.sub) = {
+ * { .x = 3, .y = 4 },
+ * { .x = 8, .y = 2 },
+ * { .x = 1, .y = 7 }
+ * };
+ */
+#define ll_entry_declare_list(_type, _name, _list) \
+   _type _u_boot_list_2_##_list##_2_##_name[] __aligned(4) \
+   __attribute__((unused,  \
+   section(.u_boot_list_2_#_list_2_#_name)))
+
+/**
  * We need a 0-byte-size type for iterator symbols, and the compiler
  * does not allow defining objects of C type 'void'. Using an empty
  * struct is allowed by the compiler, but causes gcc versions 4.4 and
-- 
2.1.0.rc2.206.gedb03e5

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

[U-Boot] [PATCH v3 02/11] dm: core: Allow a list of devices to be declared in one step

The U_BOOT_DEVICE macro allows the declaration of a single U-Boot device.
Add an equivalent macro to declare an array of devices, for convenience.

Signed-off-by: Simon Glass s...@chromium.org
---

Changes in v3: None
Changes in v2: None

 include/dm/platdata.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/include/dm/platdata.h b/include/dm/platdata.h
index 2bc8b14..9e47e51 100644
--- a/include/dm/platdata.h
+++ b/include/dm/platdata.h
@@ -25,4 +25,8 @@ struct driver_info {
 #define U_BOOT_DEVICE(__name)  \
ll_entry_declare(struct driver_info, __name, driver_info)
 
+/* Declare a list of devices. The argument is a driver_info[] array */
+#define U_BOOT_DEVICES(__name) \
+   ll_entry_declare_list(struct driver_info, __name, driver_info)
+
 #endif
-- 
2.1.0.rc2.206.gedb03e5

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

[U-Boot] [PATCH v3 04/11] initcall: Display error number when an error occurs

Now that some initcall functions return a useful error number, display it
when something goes wrong.

Signed-off-by: Simon Glass s...@chromium.org
Acked-by: Igor Grinberg grinb...@compulab.co.il
---

Changes in v3: None
Changes in v2:
- Add patch to display error number when an error occurs in initcall

 lib/initcall.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/lib/initcall.c b/lib/initcall.c
index 7597bad..39f4b3f 100644
--- a/lib/initcall.c
+++ b/lib/initcall.c
@@ -15,14 +15,16 @@ int initcall_run_list(const init_fnc_t init_sequence[])
 
for (init_fnc_ptr = init_sequence; *init_fnc_ptr; ++init_fnc_ptr) {
unsigned long reloc_ofs = 0;
+   int ret;
 
if (gd-flags  GD_FLG_RELOC)
reloc_ofs = gd-reloc_off;
debug(initcall: %p\n, (char *)*init_fnc_ptr - reloc_ofs);
-   if ((*init_fnc_ptr)()) {
-   printf(initcall sequence %p failed at call %p\n,
+   ret = (*init_fnc_ptr)();
+   if (ret) {
+   printf(initcall sequence %p failed at call %p 
(err=%d)\n,
   init_sequence,
-  (char *)*init_fnc_ptr - reloc_ofs);
+  (char *)*init_fnc_ptr - reloc_ofs, ret);
return -1;
}
}
-- 
2.1.0.rc2.206.gedb03e5

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

[U-Boot] [PATCH v3 08/11] dm: imx: Use gpio_request() to request GPIOs

GPIOs should be requested before use. Without this, driver model will not
permit the GPIO to be used.

Signed-off-by: Simon Glass s...@chromium.org
---

Changes in v3:
- Add a check for the Ethernet gpio_request() also
- Add a comment for the CONFIG_SPL_BUILD #ifdef
- Just warn when one of the board init stages fails

Changes in v2:
- Check return values of gpio_request()

 arch/arm/imx-common/i2c-mxv7.c | 24 
 board/compulab/cm_fx6/cm_fx6.c | 22 --
 board/compulab/cm_fx6/common.c |  8 
 3 files changed, 52 insertions(+), 2 deletions(-)

diff --git a/arch/arm/imx-common/i2c-mxv7.c b/arch/arm/imx-common/i2c-mxv7.c
index 70cff5c..aaf6936 100644
--- a/arch/arm/imx-common/i2c-mxv7.c
+++ b/arch/arm/imx-common/i2c-mxv7.c
@@ -4,6 +4,7 @@
  * SPDX-License-Identifier:GPL-2.0+
  */
 #include common.h
+#include malloc.h
 #include asm/arch/clock.h
 #include asm/arch/imx-regs.h
 #include asm/errno.h
@@ -72,10 +73,26 @@ static void * const i2c_bases[] = {
 int setup_i2c(unsigned i2c_index, int speed, int slave_addr,
  struct i2c_pads_info *p)
 {
+   char *name1, *name2;
int ret;
 
if (i2c_index = ARRAY_SIZE(i2c_bases))
return -EINVAL;
+
+   name1 = malloc(9);
+   name2 = malloc(9);
+   if (!name1 || !name2)
+   return -ENOMEM;
+   sprintf(name1, i2c_sda%d, i2c_index);
+   sprintf(name2, i2c_scl%d, i2c_index);
+   ret = gpio_request(p-sda.gp, name1);
+   if (ret)
+   goto err_req1;
+
+   ret = gpio_request(p-scl.gp, name2);
+   if (ret)
+   goto err_req2;
+
/* Enable i2c clock */
ret = enable_i2c_clk(1, i2c_index);
if (ret)
@@ -93,5 +110,12 @@ int setup_i2c(unsigned i2c_index, int speed, int slave_addr,
 
 err_idle:
 err_clk:
+   gpio_free(p-scl.gp);
+err_req2:
+   gpio_free(p-sda.gp);
+err_req1:
+   free(name1);
+   free(name2);
+
return ret;
 }
diff --git a/board/compulab/cm_fx6/cm_fx6.c b/board/compulab/cm_fx6/cm_fx6.c
index 10a568f..a089e82 100644
--- a/board/compulab/cm_fx6/cm_fx6.c
+++ b/board/compulab/cm_fx6/cm_fx6.c
@@ -71,8 +71,21 @@ static iomux_v3_cfg_t const sata_pads[] = {
 
 static int cm_fx6_setup_issd(void)
 {
+   int ret;
+   int i;
+
SETUP_IOMUX_PADS(sata_pads);
+
+   for (i = 0; i  ARRAY_SIZE(cm_fx6_issd_gpios); i++) {
+   ret = gpio_request(cm_fx6_issd_gpios[i], sata);
+   if (ret)
+   return ret;
+   }
+
/* Make sure this gpio has logical 0 value */
+   ret = gpio_request(CM_FX6_SATA_PWLOSS_INT, sata_pwloss_int);
+   if (ret)
+   return ret;
gpio_direction_output(CM_FX6_SATA_PWLOSS_INT, 0);
udelay(100);
 
@@ -350,12 +363,17 @@ static int handle_mac_address(void)
 
 int board_eth_init(bd_t *bis)
 {
-   int res = handle_mac_address();
-   if (res)
+   int err;
+
+   err = handle_mac_address();
+   if (err)
puts(No MAC address found\n);
 
SETUP_IOMUX_PADS(enet_pads);
/* phy reset */
+   err = gpio_request(CM_FX6_ENET_NRST, enet_nrst);
+   if (err)
+   printf(Etnernet NRST gpio request failed: %d\n, err);
gpio_direction_output(CM_FX6_ENET_NRST, 0);
udelay(500);
gpio_set_value(CM_FX6_ENET_NRST, 1);
diff --git a/board/compulab/cm_fx6/common.c b/board/compulab/cm_fx6/common.c
index 1f39679..20b758b 100644
--- a/board/compulab/cm_fx6/common.c
+++ b/board/compulab/cm_fx6/common.c
@@ -79,6 +79,14 @@ void cm_fx6_set_ecspi_iomux(void)
 
 int board_spi_cs_gpio(unsigned bus, unsigned cs)
 {
+   /* DM does not support SPL yet and this function is not implemented */
+#ifndef CONFIG_SPL_BUILD
+   int ret;
+
+   ret = gpio_request(CM_FX6_ECSPI_BUS0_CS0, ecspi_bus0_cs0);
+   if (ret)
+   return ret;
+#endif
return (bus == 0  cs == 0) ? (CM_FX6_ECSPI_BUS0_CS0) : -1;
 }
 #endif
-- 
2.1.0.rc2.206.gedb03e5

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

[U-Boot] [PATCH v3 07/11] imx: Add error checking to setup_i2c()

Since this function can fail, check its return value.

Signed-off-by: Simon Glass s...@chromium.org
---

Changes in v3:
- Just warn when one of the board init stages fails

Changes in v2:
- Add new patch to add error checking to setup_i2c()

 arch/arm/imx-common/i2c-mxv7.c| 24 ++---
 arch/arm/include/asm/imx-common/mxc_i2c.h |  4 +--
 board/compulab/cm_fx6/cm_fx6.c| 56 ++-
 3 files changed, 68 insertions(+), 16 deletions(-)

diff --git a/arch/arm/imx-common/i2c-mxv7.c b/arch/arm/imx-common/i2c-mxv7.c
index a580873..70cff5c 100644
--- a/arch/arm/imx-common/i2c-mxv7.c
+++ b/arch/arm/imx-common/i2c-mxv7.c
@@ -69,15 +69,29 @@ static void * const i2c_bases[] = {
 };
 
 /* i2c_index can be from 0 - 2 */
-void setup_i2c(unsigned i2c_index, int speed, int slave_addr,
-   struct i2c_pads_info *p)
+int setup_i2c(unsigned i2c_index, int speed, int slave_addr,
+ struct i2c_pads_info *p)
 {
+   int ret;
+
if (i2c_index = ARRAY_SIZE(i2c_bases))
-   return;
+   return -EINVAL;
/* Enable i2c clock */
-   enable_i2c_clk(1, i2c_index);
+   ret = enable_i2c_clk(1, i2c_index);
+   if (ret)
+   goto err_clk;
+
/* Make sure bus is idle */
-   force_idle_bus(p);
+   ret = force_idle_bus(p);
+   if (ret)
+   goto err_idle;
+
bus_i2c_init(i2c_bases[i2c_index], speed, slave_addr,
force_idle_bus, p);
+
+   return 0;
+
+err_idle:
+err_clk:
+   return ret;
 }
diff --git a/arch/arm/include/asm/imx-common/mxc_i2c.h 
b/arch/arm/include/asm/imx-common/mxc_i2c.h
index 182c2f3..af86163 100644
--- a/arch/arm/include/asm/imx-common/mxc_i2c.h
+++ b/arch/arm/include/asm/imx-common/mxc_i2c.h
@@ -52,8 +52,8 @@ struct i2c_pads_info {
mx6q_##name : mx6s_##name
 #endif
 
-void setup_i2c(unsigned i2c_index, int speed, int slave_addr,
-   struct i2c_pads_info *p);
+int setup_i2c(unsigned i2c_index, int speed, int slave_addr,
+ struct i2c_pads_info *p);
 void bus_i2c_init(void *base, int speed, int slave_addr,
int (*idle_bus_fn)(void *p), void *p);
 int bus_i2c_read(void *base, uchar chip, uint addr, int alen, uchar *buf,
diff --git a/board/compulab/cm_fx6/cm_fx6.c b/board/compulab/cm_fx6/cm_fx6.c
index fdb8ebf..10a568f 100644
--- a/board/compulab/cm_fx6/cm_fx6.c
+++ b/board/compulab/cm_fx6/cm_fx6.c
@@ -69,7 +69,7 @@ static iomux_v3_cfg_t const sata_pads[] = {
IOMUX_PADS(PAD_EIM_BCLK__GPIO6_IO31   | MUX_PAD_CTRL(NO_PAD_CTRL)),
 };
 
-static void cm_fx6_setup_issd(void)
+static int cm_fx6_setup_issd(void)
 {
SETUP_IOMUX_PADS(sata_pads);
/* Make sure this gpio has logical 0 value */
@@ -79,14 +79,24 @@ static void cm_fx6_setup_issd(void)
cm_fx6_sata_power(0);
mdelay(250);
cm_fx6_sata_power(1);
+
+   return 0;
 }
 
 #define CM_FX6_SATA_INIT_RETRIES   10
 int sata_initialize(void)
 {
-   int err, i;
+   int err, i, ret;
 
-   cm_fx6_setup_issd();
+   /*
+* cm-fx6 may have iSSD not assembled and in this case it has
+* bypasses for a (m)SATA socket on the baseboard. The socketed
+* device is not controlled by those GPIOs. So just print a warning
+* if the setup fails.
+*/
+   ret = cm_fx6_setup_issd();
+   if (ret)
+   printf(Warning: iSSD setup failed!\n);
for (i = 0; i  CM_FX6_SATA_INIT_RETRIES; i++) {
err = setup_sata();
if (err) {
@@ -141,14 +151,36 @@ I2C_PADS(i2c2_pads,
 IMX_GPIO_NR(1, 6));
 
 
-static void cm_fx6_setup_i2c(void)
+static int cm_fx6_setup_one_i2c(int busnum, struct i2c_pads_info *pads)
+{
+   int ret;
+
+   ret = setup_i2c(busnum, CONFIG_SYS_I2C_SPEED, 0x7f, pads);
+   if (ret)
+   printf(Warning: I2C%d setup failed: %d\n, busnum, ret);
+
+   return ret;
+}
+
+static int cm_fx6_setup_i2c(void)
 {
-   setup_i2c(0, CONFIG_SYS_I2C_SPEED, 0x7f, I2C_PADS_INFO(i2c0_pads));
-   setup_i2c(1, CONFIG_SYS_I2C_SPEED, 0x7f, I2C_PADS_INFO(i2c1_pads));
-   setup_i2c(2, CONFIG_SYS_I2C_SPEED, 0x7f, I2C_PADS_INFO(i2c2_pads));
+   int ret = 0, err;
+
+   /* i2cx_pads are wierd macro variables; we can't use an array */
+   err = cm_fx6_setup_one_i2c(0, I2C_PADS_INFO(i2c0_pads));
+   if (err)
+   ret = err;
+   err = cm_fx6_setup_one_i2c(1, I2C_PADS_INFO(i2c1_pads));
+   if (err)
+   ret = err;
+   err = cm_fx6_setup_one_i2c(2, I2C_PADS_INFO(i2c2_pads));
+   if (err)
+   ret = err;
+
+   return ret;
 }
 #else
-static void cm_fx6_setup_i2c(void) { }
+static int cm_fx6_setup_i2c(void) { return 0; }
 #endif
 
 #ifdef CONFIG_USB_EHCI_MX6
@@ -409,9 +441,15 @@ void ft_board_setup(void *blob, bd_t *bd)
 
 int board_init(void)
 {
+   int ret;
+
gd-bd-bi_boot_params =

[U-Boot] [PATCH v3 06/11] dm: serial: Put common code into separate functions

Avoid duplicating the code which deals with getc() and putc(). It is fairly
simple, but may expand later.

Signed-off-by: Simon Glass s...@chromium.org
---

Changes in v3: None
Changes in v2: None

 drivers/serial/serial-uclass.c | 32 +---
 1 file changed, 17 insertions(+), 15 deletions(-)

diff --git a/drivers/serial/serial-uclass.c b/drivers/serial/serial-uclass.c
index 1ac943f..e93c624 100644
--- a/drivers/serial/serial-uclass.c
+++ b/drivers/serial/serial-uclass.c
@@ -71,7 +71,7 @@ void serial_initialize(void)
serial_find_console_or_panic();
 }
 
-void serial_putc(char ch)
+static void serial_putc_dev(struct udevice *dev, char ch)
 {
struct dm_serial_ops *ops = serial_get_ops(cur_dev);
int err;
@@ -83,6 +83,11 @@ void serial_putc(char ch)
serial_putc('\r');
 }
 
+void serial_putc(char ch)
+{
+   serial_putc_dev(cur_dev, ch);
+}
+
 void serial_setbrg(void)
 {
struct dm_serial_ops *ops = serial_get_ops(cur_dev);
@@ -107,28 +112,32 @@ int serial_tstc(void)
return 1;
 }
 
-int serial_getc(void)
+static int serial_getc_dev(struct udevice *dev)
 {
-   struct dm_serial_ops *ops = serial_get_ops(cur_dev);
+   struct dm_serial_ops *ops = serial_get_ops(dev);
int err;
 
do {
-   err = ops-getc(cur_dev);
+   err = ops-getc(dev);
} while (err == -EAGAIN);
 
return err = 0 ? err : 0;
 }
 
+int serial_getc(void)
+{
+   return serial_getc_dev(cur_dev);
+}
+
 void serial_stdio_init(void)
 {
 }
 
-void serial_stub_putc(struct stdio_dev *sdev, const char ch)
+static void serial_stub_putc(struct stdio_dev *sdev, const char ch)
 {
struct udevice *dev = sdev-priv;
-   struct dm_serial_ops *ops = serial_get_ops(dev);
 
-   ops-putc(dev, ch);
+   serial_putc_dev(dev, ch);
 }
 
 void serial_stub_puts(struct stdio_dev *sdev, const char *str)
@@ -140,15 +149,8 @@ void serial_stub_puts(struct stdio_dev *sdev, const char 
*str)
 int serial_stub_getc(struct stdio_dev *sdev)
 {
struct udevice *dev = sdev-priv;
-   struct dm_serial_ops *ops = serial_get_ops(dev);
-
-   int err;
 
-   do {
-   err = ops-getc(dev);
-   } while (err == -EAGAIN);
-
-   return err = 0 ? err : 0;
+   return serial_getc_dev(dev);
 }
 
 int serial_stub_tstc(struct stdio_dev *sdev)
-- 
2.1.0.rc2.206.gedb03e5

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

[U-Boot] [PATCH v3 10/11] dm: imx: serial: Support driver model in the MXC serial driver

Add driver model support with this driver. Boards which use this driver
should define platform data in their board files.

Signed-off-by: Simon Glass s...@chromium.org
---

Changes in v3: None
Changes in v2: None

 drivers/serial/serial_mxc.c | 170 +---
 include/serial_mxc.h|  14 
 2 files changed, 159 insertions(+), 25 deletions(-)
 create mode 100644 include/serial_mxc.h

diff --git a/drivers/serial/serial_mxc.c b/drivers/serial/serial_mxc.c
index 313d560..9ce24f9 100644
--- a/drivers/serial/serial_mxc.c
+++ b/drivers/serial/serial_mxc.c
@@ -5,37 +5,15 @@
  */
 
 #include common.h
+#include dm.h
+#include errno.h
+#include serial_mxc.h
 #include watchdog.h
 #include asm/arch/imx-regs.h
 #include asm/arch/clock.h
 #include serial.h
 #include linux/compiler.h
 
-#define __REG(x) (*((volatile u32 *)(x)))
-
-#ifndef CONFIG_MXC_UART_BASE
-#error define CONFIG_MXC_UART_BASE to use the MXC UART driver
-#endif
-
-#define UART_PHYS  CONFIG_MXC_UART_BASE
-
-/* Register definitions */
-#define URXD  0x0  /* Receiver Register */
-#define UTXD  0x40 /* Transmitter Register */
-#define UCR1  0x80 /* Control Register 1 */
-#define UCR2  0x84 /* Control Register 2 */
-#define UCR3  0x88 /* Control Register 3 */
-#define UCR4  0x8c /* Control Register 4 */
-#define UFCR  0x90 /* FIFO Control Register */
-#define USR1  0x94 /* Status Register 1 */
-#define USR2  0x98 /* Status Register 2 */
-#define UESC  0x9c /* Escape Character Register */
-#define UTIM  0xa0 /* Escape Timer Register */
-#define UBIR  0xa4 /* BRM Incremental Register */
-#define UBMR  0xa8 /* BRM Modulator Register */
-#define UBRC  0xac /* Baud Rate Count Register */
-#define UTS   0xb4 /* UART Test Register (mx31) */
-
 /* UART Control Register Bit Fields.*/
 #define  URXD_CHARRDY(115)
 #define  URXD_ERR(114)
@@ -128,6 +106,33 @@
 #define  UTS_RXFULL (13)  /* RxFIFO full */
 #define  UTS_SOFTRST(10)  /* Software reset */
 
+#ifndef CONFIG_DM_SERIAL
+
+#ifndef CONFIG_MXC_UART_BASE
+#error define CONFIG_MXC_UART_BASE to use the MXC UART driver
+#endif
+
+#define UART_PHYS  CONFIG_MXC_UART_BASE
+
+#define __REG(x) (*((volatile u32 *)(x)))
+
+/* Register definitions */
+#define URXD  0x0  /* Receiver Register */
+#define UTXD  0x40 /* Transmitter Register */
+#define UCR1  0x80 /* Control Register 1 */
+#define UCR2  0x84 /* Control Register 2 */
+#define UCR3  0x88 /* Control Register 3 */
+#define UCR4  0x8c /* Control Register 4 */
+#define UFCR  0x90 /* FIFO Control Register */
+#define USR1  0x94 /* Status Register 1 */
+#define USR2  0x98 /* Status Register 2 */
+#define UESC  0x9c /* Escape Character Register */
+#define UTIM  0xa0 /* Escape Timer Register */
+#define UBIR  0xa4 /* BRM Incremental Register */
+#define UBMR  0xa8 /* BRM Modulator Register */
+#define UBRC  0xac /* Baud Rate Count Register */
+#define UTS   0xb4 /* UART Test Register (mx31) */
+
 DECLARE_GLOBAL_DATA_PTR;
 
 static void mxc_serial_setbrg(void)
@@ -222,3 +227,118 @@ __weak struct serial_device *default_serial_console(void)
 {
return mxc_serial_drv;
 }
+#endif
+
+#ifdef CONFIG_DM_SERIAL
+
+struct mxc_uart {
+   u32 rxd;
+   u32 spare0[15];
+
+   u32 txd;
+   u32 spare1[15];
+
+   u32 cr1;
+   u32 cr2;
+   u32 cr3;
+   u32 cr4;
+
+   u32 fcr;
+   u32 sr1;
+   u32 sr2;
+   u32 esc;
+
+   u32 tim;
+   u32 bir;
+   u32 bmr;
+   u32 brc;
+
+   u32 onems;
+   u32 ts;
+};
+
+int mxc_serial_setbrg(struct udevice *dev, int baudrate)
+{
+   struct mxc_serial_platdata *plat = dev-platdata;
+   struct mxc_uart *const uart = plat-reg;
+   u32 clk = imx_get_uartclk();
+
+   writel(4  7, uart-fcr); /* divide input clock by 2 */
+   writel(0xf, uart-bir);
+   writel(clk / (2 * baudrate), uart-bmr);
+
+   writel(UCR2_WS | UCR2_IRTS | UCR2_RXEN | UCR2_TXEN | UCR2_SRST,
+  uart-cr2);
+   writel(UCR1_UARTEN, uart-cr1);
+
+   return 0;
+}
+
+static int mxc_serial_probe(struct udevice *dev)
+{
+   struct mxc_serial_platdata *plat = dev-platdata;
+   struct mxc_uart *const uart = plat-reg;
+
+   writel(0, uart-cr1);
+   writel(0, uart-cr2);
+   while (!(readl(uart-cr2)  UCR2_SRST));
+   writel(0x704 | UCR3_ADNIMP, uart-cr3);
+   writel(0x8000, uart-cr4);
+   writel(0x2b, uart-esc);
+   writel(0, uart-tim);
+   writel(0, uart-ts);
+
+   return 0;
+}
+
+static int mxc_serial_getc(struct udevice *dev)
+{
+   struct mxc_serial_platdata *plat = dev-platdata;
+   struct mxc_uart *const uart = plat-reg;
+
+   if (readl(uart-ts)  UTS_RXEMPTY)
+   return -EAGAIN;
+
+   return readl(uart-rxd)  URXD_RX_DATA;
+}
+
+static int mxc_serial_putc(struct udevice *dev, const char ch)
+{
+   struct mxc_serial_platdata *plat = dev-platdata;
+   struct mxc_uart *const uart = plat-reg;
+
+   if (!(readl(uart-ts)

[U-Boot] [PATCH v3 05/11] dm: serial: Don't require device tree to configure a console

Allow serial_find_console_or_panic() to work without a device tree.

Signed-off-by: Simon Glass s...@chromium.org
---

Changes in v3: None
Changes in v2: None

 drivers/serial/serial-uclass.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/serial/serial-uclass.c b/drivers/serial/serial-uclass.c
index d04104e..1ac943f 100644
--- a/drivers/serial/serial-uclass.c
+++ b/drivers/serial/serial-uclass.c
@@ -25,6 +25,7 @@ struct udevice *cur_dev __attribute__ ((section(.data)));
 
 static void serial_find_console_or_panic(void)
 {
+#ifdef CONFIG_OF_CONTROL
int node;
 
/* Check for a chosen console */
@@ -44,7 +45,7 @@ static void serial_find_console_or_panic(void)
return;
cur_dev = NULL;
}
-
+#endif
/*
 * Failing that, get the device with sequence number 0, or in extremis
 * just the first serial device we can find. But we insist on having
-- 
2.1.0.rc2.206.gedb03e5

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

[U-Boot] [PATCH v3 11/11] dm: imx: Move cm_fx6 to use driver model for serial and GPIO

Now that serial and GPIO are available for iMX.6, move cm_fx6 over as an
example.

Acked-by: Igor Grinberg grinb...@compulab.co.il
Signed-off-by: Simon Glass s...@chromium.org
---

Changes in v3: None
Changes in v2:
- Use the correct namespace for the platform data

 board/compulab/cm_fx6/cm_fx6.c | 10 ++
 include/configs/cm_fx6.h   | 11 +++
 2 files changed, 21 insertions(+)

diff --git a/board/compulab/cm_fx6/cm_fx6.c b/board/compulab/cm_fx6/cm_fx6.c
index a089e82..3a8ebd5 100644
--- a/board/compulab/cm_fx6/cm_fx6.c
+++ b/board/compulab/cm_fx6/cm_fx6.c
@@ -9,11 +9,13 @@
  */
 
 #include common.h
+#include dm.h
 #include fsl_esdhc.h
 #include miiphy.h
 #include netdev.h
 #include fdt_support.h
 #include sata.h
+#include serial_mxc.h
 #include asm/arch/crm_regs.h
 #include asm/arch/sys_proto.h
 #include asm/arch/iomux.h
@@ -537,3 +539,11 @@ u32 get_board_rev(void)
return cl_eeprom_get_board_rev();
 }
 
+static struct mxc_serial_platdata cm_fx6_mxc_serial_plat = {
+   .reg = (struct mxc_uart *)UART4_BASE,
+};
+
+U_BOOT_DEVICE(cm_fx6_serial) = {
+   .name   = serial_mxc,
+   .platdata = cm_fx6_mxc_serial_plat,
+};
diff --git a/include/configs/cm_fx6.h b/include/configs/cm_fx6.h
index 10d02b4..1f55150 100644
--- a/include/configs/cm_fx6.h
+++ b/include/configs/cm_fx6.h
@@ -21,6 +21,17 @@
 #define CONFIG_MACH_TYPE   4273
 #define CONFIG_SYS_HZ  1000
 
+#ifndef CONFIG_SPL_BUILD
+#define CONFIG_DM
+#define CONFIG_CMD_DM
+
+#define CONFIG_DM_GPIO
+#define CONFIG_CMD_GPIO
+
+#define CONFIG_DM_SERIAL
+#define CONFIG_SYS_MALLOC_F_LEN(1  10)
+#endif
+
 /* Display information on boot */
 #define CONFIG_DISPLAY_CPUINFO
 #define CONFIG_DISPLAY_BOARDINFO
-- 
2.1.0.rc2.206.gedb03e5

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

[U-Boot] [PATCH v3 09/11] dm: imx: gpio: Support driver model in MXC gpio driver

Add driver model support with this driver. In this case the platform data
is in the driver. It would be better to put this into an SOC-specific file,
but this is best attempted when more boards are moved over to use driver
model.

Signed-off-by: Simon Glass s...@chromium.org
---

Changes in v3:
- Use gpio_is_requested() in one more place

Changes in v2:
- Add an internal function to check if a GPIO is requested
- Change 'reserved' to 'requested'
- Tidy up confusing code that creates names for gpio_request()

 drivers/gpio/mxc_gpio.c | 304 +++-
 1 file changed, 303 insertions(+), 1 deletion(-)

diff --git a/drivers/gpio/mxc_gpio.c b/drivers/gpio/mxc_gpio.c
index 6a572d5..3f7b7d2 100644
--- a/drivers/gpio/mxc_gpio.c
+++ b/drivers/gpio/mxc_gpio.c
@@ -8,16 +8,31 @@
  * SPDX-License-Identifier:GPL-2.0+
  */
 #include common.h
+#include errno.h
+#include dm.h
+#include malloc.h
 #include asm/arch/imx-regs.h
 #include asm/gpio.h
 #include asm/io.h
-#include errno.h
 
 enum mxc_gpio_direction {
MXC_GPIO_DIRECTION_IN,
MXC_GPIO_DIRECTION_OUT,
 };
 
+#define GPIO_NAME_SIZE 20
+#define GPIO_PER_BANK  32
+
+struct mxc_gpio_plat {
+   struct gpio_regs *regs;
+};
+
+struct mxc_bank_info {
+   char label[GPIO_PER_BANK][GPIO_NAME_SIZE];
+   struct gpio_regs *regs;
+};
+
+#ifndef CONFIG_DM_GPIO
 #define GPIO_TO_PORT(n)(n / 32)
 
 /* GPIO port description */
@@ -134,3 +149,290 @@ int gpio_direction_output(unsigned gpio, int value)
 
return mxc_gpio_direction(gpio, MXC_GPIO_DIRECTION_OUT);
 }
+#endif
+
+#ifdef CONFIG_DM_GPIO
+/**
+ * gpio_is_requested() - check if a GPIO has been requested
+ *
+ * @bank:  Bank to check
+ * @offset:GPIO offset within bank to check
+ * @return true if marked as requested, false if not
+ */
+static inline bool gpio_is_requested(struct mxc_bank_info *bank, int offset)
+{
+   return *bank-label[offset] != '\0';
+}
+
+static int mxc_gpio_is_output(struct gpio_regs *regs, int offset)
+{
+   u32 val;
+
+   val = readl(regs-gpio_dir);
+
+   return val  (1  offset) ? 1 : 0;
+}
+
+static void mxc_gpio_bank_direction(struct gpio_regs *regs, int offset,
+   enum mxc_gpio_direction direction)
+{
+   u32 l;
+
+   l = readl(regs-gpio_dir);
+
+   switch (direction) {
+   case MXC_GPIO_DIRECTION_OUT:
+   l |= 1  offset;
+   break;
+   case MXC_GPIO_DIRECTION_IN:
+   l = ~(1  offset);
+   }
+   writel(l, regs-gpio_dir);
+}
+
+static void mxc_gpio_bank_set_value(struct gpio_regs *regs, int offset,
+   int value)
+{
+   u32 l;
+
+   l = readl(regs-gpio_dr);
+   if (value)
+   l |= 1  offset;
+   else
+   l = ~(1  offset);
+   writel(l, regs-gpio_dr);
+}
+
+static int mxc_gpio_bank_get_value(struct gpio_regs *regs, int offset)
+{
+   return (readl(regs-gpio_psr)  offset)  0x01;
+}
+
+static int mxc_gpio_bank_get_output_value(struct gpio_regs *regs, int offset)
+{
+   return (readl(regs-gpio_dr)  offset)  0x01;
+}
+
+static int check_requested(struct udevice *dev, unsigned offset,
+  const char *func)
+{
+   struct mxc_bank_info *bank = dev_get_priv(dev);
+   struct gpio_dev_priv *uc_priv = dev-uclass_priv;
+
+   if (!gpio_is_requested(bank, offset)) {
+   printf(mxc_gpio: %s: error: gpio %s%d not requested\n,
+  func, uc_priv-bank_name, offset);
+   return -EPERM;
+   }
+
+   return 0;
+}
+
+/* set GPIO pin 'gpio' as an input */
+static int mxc_gpio_direction_input(struct udevice *dev, unsigned offset)
+{
+   struct mxc_bank_info *bank = dev_get_priv(dev);
+   int ret;
+
+   ret = check_requested(dev, offset, __func__);
+   if (ret)
+   return ret;
+
+   /* Configure GPIO direction as input. */
+   mxc_gpio_bank_direction(bank-regs, offset, MXC_GPIO_DIRECTION_IN);
+
+   return 0;
+}
+
+/* set GPIO pin 'gpio' as an output, with polarity 'value' */
+static int mxc_gpio_direction_output(struct udevice *dev, unsigned offset,
+  int value)
+{
+   struct mxc_bank_info *bank = dev_get_priv(dev);
+   int ret;
+
+   ret = check_requested(dev, offset, __func__);
+   if (ret)
+   return ret;
+
+   /* Configure GPIO output value. */
+   mxc_gpio_bank_set_value(bank-regs, offset, value);
+
+   /* Configure GPIO direction as output. */
+   mxc_gpio_bank_direction(bank-regs, offset, MXC_GPIO_DIRECTION_OUT);
+
+   return 0;
+}
+
+/* read GPIO IN value of pin 'gpio' */
+static int mxc_gpio_get_value(struct udevice *dev, unsigned offset)
+{
+   struct mxc_bank_info *bank = dev_get_priv(dev);
+   int ret;
+
+   ret = check_requested(dev, offset, __func__);
+   if (ret)
+

Re: [U-Boot] A minor question on a Driver Model function

2014-09-17 Thread Bill Pringlemeir


 On 12 September 2014 05:25, Masahiro Yamada yamad...@jp.panasonic.com wrote:

 I have a qustion about lists_driver_lookup_name() function.

 for (entry = drv; entry != drv + n_ents; entry++) {
 if (strncmp(name, entry-name, len))
 continue;

 /* Full match */
 if (len == strlen(entry-name))
 return entry;
 }

 On 09/14/14 21:28, Simon Glass wrote:

 I would suggest still using strncmp as it is safer,
 but count also the '\0', so something like:

On 17 Sep 2014, grinb...@compulab.co.il wrote:

 Why safer?

 Could you give me more detailed explanation?

 On 09/17/14 11:18, Masahiro Yamada wrote:

 Well, I'm not an expert in s/w security, but I'll try to explain...

[snip]

 But, again, I'm not an expert in this area, so its only a suggestion.

I thought it was fairly apparent that the current code supports passing
a string that is *NOT* null terminated.  This can be convenient if you
extract a sub-string from a command line and do not need to make a copy
that is NULL terminate or perform 'strtok()' type magic.

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

[U-Boot] Running updated U-boot.img/u-boot.bin from already loaded u-boot shell

2014-09-17 Thread harsha kiran

Hi !

I am unable to load a different u-boot.img/u-boot.bin which is located in a
different ext4 partition from the u-boot shell.
Here are my observations.

1) i compiled a U-boot.img with a print statement(THIS IS A NEW U_BOOT) in
(board_init) function in board.c file and placed it in the Boot partition of
SD
2) Compiled again removing the print statement and placed the u-boot.bin in
the Root partition of SD under BOOTHERE
3) Start the board and stoped it in the shell

U-Boot SPL 2014.07 (Aug 29 2014 - 15:16:50)
reading u-boot.img
reading u-boot.img


U-Boot 2014.07 (Sep 16 2014 - 17:51:00)

I2C:   ready
DRAM:  256 MiB
THIS IS A NEW U_BOOT
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
Using default environment

Net:   ethaddr not set. Validating first E-fuse MAC
cpsw
Hit any key to stop autoboot:  0
U-Boot#
U-Boot#
U-Boot#


4) Try to load the u-boot.bin from ext4 partition

U-Boot# ext4load mmc 0:2 0x8300 /BOOTHERE/u-boot.bin
303420 bytes read in 77 ms (3.8 MiB/s)
U-Boot# go 0x8300
## Starting application at 0x8300 ...


U-Boot 2014.07 (Sep 16 2014 - 17:51:00)

I2C:   ready
DRAM:  256 MiB
THIS IS A NEW U_BOOT
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
Using default environment

Net:   ethaddr not set. Validating first E-fuse MAC
cpsw
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc1(part 0) is current device
EMMC found on device 1
** Unrecognized filesystem type **

uenvcmd was not defined in uEnv.txt ...
halting ...

switch to partitions #0, OK
mmc0 is current device
SD CARD DEVICE found on device 0
reading uEnv.txt
** Unable to read file uEnv.txt **

uenvcmd was not defined in uEnv.txt ...
trying eMMC (uEnv.txt) ...

U-Boot#

I observe that it is running the previous u-boot.img but not the updated
u-boot.bin.
When i try to load the u-boot.img in the shell it resets the board and the
application does not run 


U-Boot#
U-Boot# ext4load mmc 0:2 0x8300 /BOOTHERE/u-boot.img
303484 bytes read in 82 ms (3.5 MiB/s)
U-Boot# go 0x8300
## Starting application at 0x8300 ... 
IT is stuck here.. and then board resets

I tried putting the u-boot.bin in the same fat partition with MLO and
u-boot.img and even with 
fatload mmc 0:1 0x8020 u-boot.bin
go 0x8020

It still runs the previously loaded u-boot.img.

Is there a way i can load an updated u-boot from a u-boot?

Thanks,
KJ




--
View this message in context: 
http://u-boot.10912.n7.nabble.com/Running-updated-U-boot-img-u-boot-bin-from-already-loaded-u-boot-shell-tp189648.html
Sent from the U-Boot mailing list archive at Nabble.com.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Reading a text file from another FAT partition

2014-09-17 Thread harsha kiran

Hi !
I am sorry i should have been more specific.
I am now able to load the file from a different partition and see in the
memory.

I do not see any commands in u-boot help to create a New file/ delete a file
/ Rename a file. Is there any support for these file operations from u-boot?

Thanks,
Harsha



--
View this message in context: 
http://u-boot.10912.n7.nabble.com/Reading-a-text-file-from-another-FAT-partition-tp189502p189649.html
Sent from the U-Boot mailing list archive at Nabble.com.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] ARM: tegra: add PCIe-related pins to the Jetson TK1 pinmux tables

2014-09-17 Thread Stephen Warren


On 08/22/2014 03:04 PM, Stephen Warren wrote:

From: Stephen Warren swar...@nvidia.com

This pinmux tables currently omit any configuration for PCIe clk_req,
wake, and rst pins, which in turn causes intermittent failures in
U-Boot's PCIe support. Import an updated version of the pinmux tables
which rectifies this.

Signed-off-by: Stephen Warren swar...@nvidia.com


Could this please make it into the imminent v2014.10 release?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] ARM: tegra: add PCIe-related pins to the Jetson TK1 pinmux tables

2014-09-17 Thread Tom Warren

I take a look today.

 -Original Message-
 From: Stephen Warren [mailto:swar...@wwwdotorg.org]
 Sent: Wednesday, September 17, 2014 9:17 AM
 To: Tom Warren
 Cc: u-boot@lists.denx.de; Simon Glass; Stephen Warren; Thierry Reding;
 Tom Rini
 Subject: Re: [U-Boot] [PATCH] ARM: tegra: add PCIe-related pins to the
 Jetson TK1 pinmux tables
 
 On 08/22/2014 03:04 PM, Stephen Warren wrote:
  From: Stephen Warren swar...@nvidia.com
 
  This pinmux tables currently omit any configuration for PCIe clk_req,
  wake, and rst pins, which in turn causes intermittent failures in
  U-Boot's PCIe support. Import an updated version of the pinmux tables
  which rectifies this.
 
  Signed-off-by: Stephen Warren swar...@nvidia.com
 
 Could this please make it into the imminent v2014.10 release?
--
nvpublic
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Running updated U-boot.img/u-boot.bin from already loaded u-boot shell

2014-09-17 Thread Wolfgang Denk

Dear harsha kiran,

In message 1410967834043-189648.p...@n7.nabble.com you wrote:
 
 I am unable to load a different u-boot.img/u-boot.bin which is located in a
 different ext4 partition from the u-boot shell.

This is to be expected.  U-Boot is supposed to start on a system
coming directly out of reset.  If you try to run it on a
pre-initialized system, a number of assumptions / requirements may not
be met, and it will not work - actual behaviour depends on the
hardware, but the general rule is that such a use is bound to fail.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
If there was anything that depressed him more than his own  cynicism,
it was that quite often it still wasn't as cynical as real life.
 - Terry Pratchett, _Guards! Guards!_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Reading a text file from another FAT partition

2014-09-17 Thread Wolfgang Denk

Dear harsha kiran,

In message 1410968526130-189649.p...@n7.nabble.com you wrote:

 I do not see any commands in u-boot help to create a New file/ delete a file
 / Rename a file. Is there any support for these file operations from u-boot?

No, there isn't.  U-Boot is a boot loader, not a full blown OS.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
The light at the end of the tunnel is usually a No Exit sign.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] OMAP4: Use generic 'load' command instead of 'fatload' for 'loadbootscript' and 'loadbootenv' as already done for 'loadimage' and 'loaduimage'.

On Wed, Sep 17, 2014 at 10:11:03AM +0200, Guillaume Gardet wrote:

 Ping.

Sorry, tracking down the boot regression sidetracked me from doing a
u-boot-ti pull request after getting things into master, I'll be picking
this (and your other patch, and a bunch of others) soon.

-- 
Tom


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

[U-Boot] [PATCH 0/3] Fixes for FreeBSD / clang

- Some minor adjustments to the new compiler.h from linux.
- Updated README for FreeBSD

Jeroen Hofstee (3):
  compiler_gcc: do not redefine __gnu_attributes
  README.clang: update FreeBSD instructions
  compiler.h: remove duplicated uninitialized_var

 doc/README.clang |  6 +++---
 include/compiler.h   |  3 ---
 include/linux/compiler-gcc.h | 10 ++
 3 files changed, 13 insertions(+), 6 deletions(-)

-- 
2.1.0

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

[U-Boot] [PATCH 2/3] README.clang: update FreeBSD instructions

The mentioned binutils port got removed while the patch was
pending. As Ian pointed out there is another port providing
the binutils for arm now. Update the instructions accordingly.

Cc: i...@freebsd.org
Cc: Tom Rini tr...@ti.com
Signed-off-by: Jeroen Hofstee jer...@myspectrum.nl
---
 doc/README.clang | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/doc/README.clang b/doc/README.clang
index 9ad689f..8c5bf12 100644
--- a/doc/README.clang
+++ b/doc/README.clang
@@ -34,14 +34,14 @@ make HOSTCC=clang CC=clang -target $TRIPLET -mllvm 
-arm-use-movt=0 -no-integrat
 FreeBSD 11 (Current):
 
 Since llvm 3.4 is currently in the base system, the integrated as is
-incapable of building U-Boot. Therefore gas from devel/arm-eabi-binutils
+incapable of building U-Boot. Therefore gas from devel/arm-gnueabi-binutils
 is used instead. It needs a symlinks to be picked up correctly though:
 
-ln -s /usr/local/bin/arm-eabi-as /usr/bin/arm-freebsd-eabi-as
+ln -s /usr/local/bin/arm-gnueabi-freebsd-as /usr/bin/arm-freebsd-eabi-as
 
 # The following commands compile U-Boot using the clang xdev toolchain.
 # NOTE: CROSS_COMPILE and target differ on purpose!
-export CROSS_COMPILE=arm-eabi-
+export CROSS_COMPILE=arm-gnueabi-freebsd-
 gmake CC=clang -target arm-freebsd-eabi --sysroot /usr/arm-freebsd 
-no-integrated-as -mllvm -arm-use-movt=0 rpi_b_defconfig
 gmake CC=clang -target arm-freebsd-eabi --sysroot /usr/arm-freebsd 
-no-integrated-as -mllvm -arm-use-movt=0 -j8
 
-- 
2.1.0

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

[U-Boot] [PATCH 1/3] compiler_gcc: do not redefine __gnu_attributes

commit fb8ffd7cfc68b3dc44e182356a207d784cb30b34 compiler*.h:
sync include/linux/compiler*.h with Linux 3.16 undid the changes
of 7ea50d52849fe8ffa5b5b74c979b60b1045d6fc9 compiler_gcc: do
not redefine __gnu_attributes. Add the checks back whether these
macro's are already defined (as it causes a lot of noise on e.g.
FreeBSD where these defines are already in cdefs.h)

As the original patch this checkpatch warning is ignored:
WARNING: Adding new packed members is to be done with care

Cc: Masahiro Yamada yamad...@jp.panasonic.com
Cc: Tom Rini tr...@ti.com
Signed-off-by: Jeroen Hofstee jer...@myspectrum.nl
---
 include/linux/compiler-gcc.h | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
index 02ae99e..e057bd2 100644
--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -64,8 +64,12 @@
 #endif
 
 #define __deprecated   __attribute__((deprecated))
+#ifndef __packed
 #define __packed   __attribute__((packed))
+#endif
+#ifndef __weak
 #define __weak __attribute__((weak))
+#endif
 
 /*
  * it doesn't make sense on ARM (currently the only user of __naked) to trace
@@ -91,8 +95,12 @@
  * would be.
  * [...]
  */
+#ifndef __pure
 #define __pure __attribute__((pure))
+#endif
+#ifndef __aligned
 #define __aligned(x)   __attribute__((aligned(x)))
+#endif
 #define __printf(a, b) __attribute__((format(printf, a, b)))
 #define __scanf(a, b)  __attribute__((format(scanf, a, b)))
 #define  noinline  __attribute__((noinline))
@@ -115,4 +123,6 @@
  */
 #define uninitialized_var(x) x = x
 
+#ifndef __always_inline
 #define __always_inlineinline __attribute__((always_inline))
+#endif
-- 
2.1.0

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

[U-Boot] [PATCH 3/3] compiler.h: remove duplicated uninitialized_var

Since clang has a different definition for uninitialized_var
it will complain that it is redefined in include/compiler.h.
Since these are already defined in linux/compiler.h just remove
this instance.

Cc: Masahiro Yamada yamad...@jp.panasonic.com
Cc: Tom Rini tr...@ti.com
Signed-off-by: Jeroen Hofstee jer...@myspectrum.nl

---
This is only used in ubifs related code and MAKEALL for
arm is fine (besides the 5 boards with build issues)
---
 include/compiler.h | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/include/compiler.h b/include/compiler.h
index 9afc11b..1451916 100644
--- a/include/compiler.h
+++ b/include/compiler.h
@@ -129,9 +129,6 @@ typedef unsigned long int uintptr_t;
 
 #endif /* USE_HOSTCC */
 
-/* compiler options */
-#define uninitialized_var(x)   x = x
-
 #define likely(x)  __builtin_expect(!!(x), 1)
 #define unlikely(x)__builtin_expect(!!(x), 0)
 
-- 
2.1.0

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

[U-Boot] Need help with u-boot problem with usb-keyboard / kvm switch

2014-09-17 Thread Hans de Goede

Hi Marek, et al,

I'm working on cleaning up Luc's hdmi out support patchset for
sunxi.

As part of this I want to also add support for usb keyboards,
so as to get a full console without needing to solder wires
to testpoints on some boards :)

So when I plug in the usb coming from my kvm I get this:

(Re)start USB...
USB0:   USB EHCI 1.00
scanning bus 0 for devices... EHCI timed out on TD - token=0x80008c80
3 USB Device(s) found
   scanning usb for storage devices... 0 Storage Device(s) found

And the usb keyboard does not work.

If I plug in a single usb-2 hub (no ohci support for sunxi in u-boot
yet), then things do work, but after a few minutes of inactivity the
usb code starts spamming the console with:

EHCI timed out on TD - token=0x80008c80
EHCI timed out on TD - token=0x80008c80
...

Could this be a problem with the phy settings (iow a sunxi specific
problem)?

When using the kvm on my pc, the tree structure looks like this:

/:  Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 4: Dev 4, If 0, Class=Mass Storage, Driver=usb-storage, 480M
|__ Port 2: Dev 3, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 3: Dev 11, If 0, Class=Human Interface Device, Driver=usbhid, 
1.5M
|__ Port 4: Dev 9, If 0, Class=Hub, Driver=hub/4p, 12M
|__ Port 1: Dev 10, If 0, Class=Human Interface Device, 
Driver=usbhid, 12M
|__ Port 1: Dev 10, If 1, Class=Human Interface Device, 
Driver=usbhid, 12M
|__ Port 1: Dev 10, If 2, Class=Human Interface Device, 
Driver=usbhid, 12M

Hmm, after a bit longer I also get these errors:

ERROR: v7_dcache_inval_range - start address is not aligned - 0xe59ff014

Could the problem be that the usb code is feeding unaligned buffers to the ehci
controller ?

Regards,

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

Re: [U-Boot] Need help with u-boot problem with usb-keyboard / kvm switch

2014-09-17 Thread Luc Verhaegen

On Wed, Sep 17, 2014 at 09:11:38PM +0200, Hans de Goede wrote:
 Hi Marek, et al,
 
 I'm working on cleaning up Luc's hdmi out support patchset for
 sunxi.

?

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

Re: [U-Boot] Need help with u-boot problem with usb-keyboard / kvm switch

2014-09-17 Thread Eric Nelson

Hi Hans,

On 09/17/2014 12:11 PM, Hans de Goede wrote:
 Hi Marek, et al,
 
 I'm working on cleaning up Luc's hdmi out support patchset for
 sunxi.
 
 As part of this I want to also add support for usb keyboards,
 so as to get a full console without needing to solder wires
 to testpoints on some boards :)
 
 So when I plug in the usb coming from my kvm I get this:
 
 (Re)start USB...
 USB0:   USB EHCI 1.00
 scanning bus 0 for devices... EHCI timed out on TD - token=0x80008c80
 3 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
 
 And the usb keyboard does not work.
 
 If I plug in a single usb-2 hub (no ohci support for sunxi in u-boot
 yet), then things do work, but after a few minutes of inactivity the
 usb code starts spamming the console with:
 
 EHCI timed out on TD - token=0x80008c80
 EHCI timed out on TD - token=0x80008c80
 ...
 
 Could this be a problem with the phy settings (iow a sunxi specific
 problem)?
 

Probably not.

We've seen the same thing on SABRE Lite and Nitrogen6X boards.

U-Boot  usb start ; setenv stdin serial,usbkbd
(Re)start USB...
USB0:   USB EHCI 1.00
scanning bus 0 for devices... 2 USB Device(s) found
USB1:   USB EHCI 1.00
scanning bus 1 for devices... EHCI timed out on TD - token=0x80008c80
EHCI timed out on TD - token=0x80008c80
EHCI timed out on TD - token=0x80008c80
6 USB Device(s) found
   scanning usb for storage devices... 1 Storage Device(s) found
   scanning usb for ethernet devices... 0 Ethernet Device(s) found
Timeout poll on interrupt endpoint
Failed to get keyboard state from device 1c4f:0002
U-Boot  usb tree
USB device tree:
  1  Hub (480 Mb/s, 0mA)
  |  u-boot EHCI Host Controller
  |
  +-2  Mass Storage (480 Mb/s, 100mA)
   Generic Mass Storage 4A3709D5

  3  Hub (480 Mb/s, 0mA)
  |  u-boot EHCI Host Controller
  |
  +-4  Hub (480 Mb/s, 2mA)
|
+-5  Human Interface (1.5 Mb/s, 100mA)
|Logitech USB Optical Mouse
|
+-6  Hub (480 Mb/s, 100mA)
| |   USB 2.0 Hub
| |
| +-7  Human Interface (1.5 Mb/s, 98mA)
|  USB USB Keykoard
|
+-8   (12 Mb/s, 100mA)

Oddly, the issue seems to be specific to **some** USB keyboards.

We have some (mostly older) USB keyboards that just work and
have had investigation on our to-do list for quite some
time now.

I was going to start with a question to the list:

Is anyone else using USB keyboard support?

USB mass storage seems to be pretty reliable. We have
folks using it as an alternate boot for emergency
situations.

Regards,


Eric

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

Re: [U-Boot] [PATCH] test: dfu: script: wrong md5sum on nand partitions

2014-09-17 Thread Scott Wood

On Mon, 2014-09-15 at 13:55 +0200, Lukasz Majewski wrote:
 Hi Heiko,
 
  Hello Lukasz,
  
  Am 15.09.2014 11:45, schrieb Lukasz Majewski:
   The legacy dat_file_size.img (e.g. dat_960.img) would be
   truncated if needed in the script.
  
   This is a quick solution.
  
  Yes ... I do not prefer this solution. Why not cutting the readden
  file to the length we transferred? 
 
 I think that the truncation of the received file is acceptable.
 If we were about to test partition write, then we could prepare images
 with the size equal to the partition size.

Keep in mind that the exact partition size can vary, even for the same
board, due to bad blocks.

-Scott


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

Re: [U-Boot] [PULL] Please pull u-boot-imx

2014-09-17 Thread Albert ARIBAUD

Hi Stefano,

On Fri, 12 Sep 2014 16:03:15 +0200, Stefano Babic sba...@denx.de
wrote:

 Hi Albert,
 
 please pull from u-boot-imx, thanks !
 
 The board cm_fx6 cannot be built due to a couple of missing patches that
 are already merged into u-boot-spi. Please ignore this issue, the board
 will be compiled clean at the next iteration after Jagan's tree will be
 merged by Tom.
 
 The following changes since commit a6bc0195dba895fa0e9facc718d17eb098695685:
 
   Merge branch 'u-boot-sunxi/master' into 'u-boot-arm/master'
 (2014-09-09 09:19:10 +0200)
 
 are available in the git repository at:
 
 
   git://www.denx.de/git/u-boot-imx.git master
 
 for you to fetch changes up to 4c97f16911e229f6d5bbea5bee52449916e5fa92:
 
   imx: mx6slevk: Change to use generic board (2014-09-11 11:04:26 +0200)
 
 
 Fabio Estevam (9):
   net: fec_mxc: Adjust RX DMA alignment for mx6solox
   net: fec_mxc: Poll FEC_TBD_READY after polling TDAR
   tools: imximage: Fix the maximum DCD size for mx53/mx6
   mx6dlsabresd: Use its own DCD table
   mx6qsabreauto: Remove imx6q-sabreauto.dts
   mx6: imx-regs: Provide a structure for GPC registers
   pcie_imx: Add mx6solox support
   mx6sxsabresd: Add PCI support
   README.imximage: Fix the maximum DCD size
 
 Guillaume GARDET (1):
   imx: nitrogen6x: Replace 'fatload' by 'load' command in env
 settings to be filesystem independent
 
 Nikita Kiryanov (16):
   mx6: add clock enabling functions
   compulab: eeprom: add support for defining eeprom i2c bus
   sata: dwc_ahsata: implement sata_port_status
   i2c: imx: add macros to setup pads for multiple SoC types
   arm: mx6: ddr: cleanup
   arm: mx6: ddr: do not write into reserved bit
   arm: mx6: ddr: configure MMDC for slow_pd
   arm: mx6: ddr: fix cs0_end calculation
   arm: mx6: add get_cpu_type()
   arm: mx6: add support for Compulab cm-fx6 CoM
   arm: mx6: cm_fx6: add nand support
   arm: mx6: cm_fx6: add ethernet support
   arm: mx6: cm_fx6: add usb support
   arm: mx6: cm_fx6: add i2c support
   arm: mx6: cm_fx6: use eeprom
   arm: mx6: cm_fx6: add sata support
 
 Nikolay Dimitrov (1):
   mx6: Fix ECSPI typo in soc_boot_modes
 
 Stefan Agner (2):
   arm: vf610: lpuart: fix status register handling
   arm: vf610: lpuart: disable FIFO on initializaton
 
 Stefano Babic (1):
   imx: Fix build of mx6sxsabresd
 
 Thierry Reding (1):
   imx: ventana: Avoid undefined behaviour
 
 Tim Harvey (6):
   imx: ventana: updated notes regarding NAND boot errata
   imx: ventana: base SPL MMDC calibration on width and size not board
   imx: ventana: add GW5520 support
   imx: ventana: added cputype env var
   pci: add support for board_pci_fixup_dev function
   imx: ventana: add pci fixup for PLX PEX860x switch GPIO
 
 Ye.Li (4):
   iMX6: Disable the L2 before chaning the PL310 latency
   imximage: Fix imximage IVT bug for EIM-NOR boot
   imx: mx6q/dlarm2: Change to use generic board
   imx: mx6slevk: Change to use generic board
 
  arch/arm/Kconfig|   4 +
  arch/arm/cpu/armv7/mx6/clock.c  | 107 +-
  arch/arm/cpu/armv7/mx6/ddr.c| 277 
  arch/arm/cpu/armv7/mx6/soc.c|  11 +-
  arch/arm/dts/Makefile   |   1 -
  arch/arm/dts/imx6q-sabreauto.dts|  13 -
  arch/arm/include/asm/arch-mx6/clock.h   |   5 +
  arch/arm/include/asm/arch-mx6/imx-regs.h|  13 +
  arch/arm/include/asm/arch-mx6/iomux.h   |   9 +
  arch/arm/include/asm/arch-mx6/sys_proto.h   |   5 +-
  arch/arm/include/asm/imx-common/mxc_i2c.h   |  33 ++
  board/compulab/cm_fx6/Kconfig   |  23 ++
  board/compulab/cm_fx6/MAINTAINERS   |   6 +
  board/compulab/cm_fx6/Makefile  |  12 +
  board/compulab/cm_fx6/cm_fx6.c  | 483
 
  board/compulab/cm_fx6/common.c  |  84 +
  board/compulab/cm_fx6/common.h  |  37 +++
  board/compulab/cm_fx6/imximage.cfg  |   8 +
  board/compulab/cm_fx6/spl.c | 366 +
  board/compulab/common/eeprom.c  |  13 +-
  board/freescale/mx6sabresd/mx6dlsabresd.cfg | 131 
  board/gateworks/gw_ventana/eeprom.c |   3 +
  board/gateworks/gw_ventana/gsc.c|   4 +
  board/gateworks/gw_ventana/gw_ventana.c | 118 ++-
  board/gateworks/gw_ventana/gw_ventana_spl.c | 189 ++-
  board/gateworks/gw_ventana/ventana_eeprom.h |   1 +
  configs/cm_fx6_defconfig|   4 +
  configs/mx6dlsabresd_defconfig  |   2 +-
  doc/README.imximage |   2 +-
  drivers/block/dwc_ahsata.c  |  17 +
  drivers/net/fec_mxc.c   |  42 ++-
  drivers/pci/pci.c   |   4 +

[U-Boot] Pull request: u-boot-arm/master

2014-09-17 Thread Albert ARIBAUD

Hi Tom,

The following changes since commit
a7f99bf139b3aaa0d5494693fd0395084355e41a:

  arm: Fix _start for CONFIG_SYS_DV_NOR_BOOT_CFG (2014-09-11 18:04:39
  +0200)

are available in the git repository at:

  git://git.denx.de/u-boot-arm master

for you to fetch changes up to c292adae170fa8c27dca75963bdb0a9afc640e57:

  Merge branch 'u-boot-imx/master' into 'u-boot-arm/master' (2014-09-17
  23:35:34 +0200)

NOTE: two boards are broken by this PR, trimslice and cm_fx6, due to
commits in the imx tree depending on some commits in the spi tree. Once
both this PR and the spi commits are in, both boards should build fine
again.



Albert ARIBAUD (1):
  Merge branch 'u-boot-imx/master' into 'u-boot-arm/master'

Fabio Estevam (9):
  net: fec_mxc: Adjust RX DMA alignment for mx6solox
  net: fec_mxc: Poll FEC_TBD_READY after polling TDAR
  tools: imximage: Fix the maximum DCD size for mx53/mx6
  mx6dlsabresd: Use its own DCD table
  mx6qsabreauto: Remove imx6q-sabreauto.dts
  mx6: imx-regs: Provide a structure for GPC registers
  pcie_imx: Add mx6solox support
  mx6sxsabresd: Add PCI support
  README.imximage: Fix the maximum DCD size

Guillaume GARDET (1):
  imx: nitrogen6x: Replace 'fatload' by 'load' command in env
settings to be filesystem independent

Nikita Kiryanov (16):
  mx6: add clock enabling functions
  compulab: eeprom: add support for defining eeprom i2c bus
  sata: dwc_ahsata: implement sata_port_status
  i2c: imx: add macros to setup pads for multiple SoC types
  arm: mx6: ddr: cleanup
  arm: mx6: ddr: do not write into reserved bit
  arm: mx6: ddr: configure MMDC for slow_pd
  arm: mx6: ddr: fix cs0_end calculation
  arm: mx6: add get_cpu_type()
  arm: mx6: add support for Compulab cm-fx6 CoM
  arm: mx6: cm_fx6: add nand support
  arm: mx6: cm_fx6: add ethernet support
  arm: mx6: cm_fx6: add usb support
  arm: mx6: cm_fx6: add i2c support
  arm: mx6: cm_fx6: use eeprom
  arm: mx6: cm_fx6: add sata support

Nikolay Dimitrov (1):
  mx6: Fix ECSPI typo in soc_boot_modes

Stefan Agner (2):
  arm: vf610: lpuart: fix status register handling
  arm: vf610: lpuart: disable FIFO on initializaton

Stefano Babic (1):
  imx: Fix build of mx6sxsabresd

Thierry Reding (1):
  imx: ventana: Avoid undefined behaviour

Tim Harvey (6):
  imx: ventana: updated notes regarding NAND boot errata
  imx: ventana: base SPL MMDC calibration on width and size not
board imx: ventana: add GW5520 support
  imx: ventana: added cputype env var
  pci: add support for board_pci_fixup_dev function
  imx: ventana: add pci fixup for PLX PEX860x switch GPIO

Ye.Li (4):
  iMX6: Disable the L2 before chaning the PL310 latency
  imximage: Fix imximage IVT bug for EIM-NOR boot
  imx: mx6q/dlarm2: Change to use generic board
  imx: mx6slevk: Change to use generic board

 arch/arm/Kconfig|   4 +
 arch/arm/cpu/armv7/mx6/clock.c  | 107 +-
 arch/arm/cpu/armv7/mx6/ddr.c| 277 
 arch/arm/cpu/armv7/mx6/soc.c|  11 +-
 arch/arm/dts/Makefile   |   1 -
 arch/arm/dts/imx6q-sabreauto.dts|  13 -
 arch/arm/include/asm/arch-mx6/clock.h   |   5 +
 arch/arm/include/asm/arch-mx6/imx-regs.h|  13 +
 arch/arm/include/asm/arch-mx6/iomux.h   |   9 +
 arch/arm/include/asm/arch-mx6/sys_proto.h   |   5 +-
 arch/arm/include/asm/imx-common/mxc_i2c.h   |  33 ++
 board/compulab/cm_fx6/Kconfig   |  23 ++
 board/compulab/cm_fx6/MAINTAINERS   |   6 +
 board/compulab/cm_fx6/Makefile  |  12 +
 board/compulab/cm_fx6/cm_fx6.c  | 483
 
 board/compulab/cm_fx6/common.c  |  84 +
 board/compulab/cm_fx6/common.h  |  37 +++
 board/compulab/cm_fx6/imximage.cfg  |   8 +
 board/compulab/cm_fx6/spl.c | 366
 + board/compulab/common/eeprom.c  |
 13 +- board/freescale/mx6sabresd/mx6dlsabresd.cfg | 131 
 board/gateworks/gw_ventana/eeprom.c |   3 +
 board/gateworks/gw_ventana/gsc.c|   4 +
 board/gateworks/gw_ventana/gw_ventana.c | 118 ++-
 board/gateworks/gw_ventana/gw_ventana_spl.c | 189 ++-
 board/gateworks/gw_ventana/ventana_eeprom.h |   1 +
 configs/cm_fx6_defconfig|   4 +
 configs/mx6dlsabresd_defconfig  |   2 +-
 doc/README.imximage |   2 +-
 drivers/block/dwc_ahsata.c  |  17 +
 drivers/net/fec_mxc.c   |  42 ++-
 drivers/pci/pci.c   |   4 +
 drivers/pci/pcie_imx.c  |  40 ++-
 drivers/serial/serial_lpuart.c  |  19 +-
 include/configs/cm_fx6.h| 290 +

Re: [U-Boot] [U-Boot, PATCH v3 2/2] fastboot: Flash command support

2014-09-17 Thread Dileep Katta

Thanks for the review comments. Working on the fix.

Regards,
Dileep

On 11 September 2014 13:42, Wolfgang Denk w...@denx.de wrote:

 Dear Dileep Katta,

 In message 1410417650-16522-2-git-send-email-dileep.ka...@linaro.org you 
 wrote:
  Flash command internally uses DFU, and Fastboot command initialization is 
  modified to add DFU and partition initialization
  Added oem format functionality for GPT table creation
  partitioning code is added as disk/part_fastboot.c for better usability
 
  Fastboot flash command code is enabled and being tested on BeagleBone Black.
  OMAP3 Beagle configuration is modified to fix the build errors, but this 
  configuration needs to be updated as per the flash functionality.

 Please fix the line length in the commit message.

 Also, checkpatch says:

 WARNING: do not add new typedefs
 #1073: FILE: include/usb/fastboot.h:98:
 +typedef struct fastboot_ptentry fastboot_ptentry;

  +int handle_flash(char *part_name, char *response, char *transfer_buffer)
  +{
  + int status = 0;
  + printf(download_bytes: 0x%x\n, download_bytes);
  + if (download_bytes) {
  + struct fastboot_ptentry *ptn;
  +
  + /* Next is the partition name */
  + ptn = fastboot_flash_find_ptn(part_name);
  +
  + if (ptn == 0) {
  + printf(Partition:[%s] does not exist\n, part_name);
  + sprintf(response, FAILpartition does not exist);
  + } else if ((download_bytes  ptn-length) 
  + !(ptn-flags  FASTBOOT_PTENTRY_FLAGS_WRITE_ENV)) {
  + printf(Image too large for the partition\n);
  + sprintf(response, FAILimage too large for 
  partition);
  + } else if (ptn-flags  FASTBOOT_PTENTRY_FLAGS_WRITE_ENV) {
  + /* Check if this is not really a flash write,
  +  * but instead a saveenv
  +  */
  + unsigned int i = 0;
  + /* Env file is expected with a NULL delimeter between
  +  * env variables So replace New line Feeds(0x0a) with
  +  * NULL (0x00)
  +  */

 Incorrect multiline comment style.  Please fix globally.

 Also this sequence of comment - declaration - comment is highly
 confusing.  What is the first comment (Check if..) actually related
 to?

  + for (i = 0; i  download_bytes; i++) {
  + if (transfer_buffer[i] == 0x0a)
  + transfer_buffer[i] = 0x00;
  + }
  + memset(env_ptr-data, 0, ENV_SIZE);
  + memcpy(env_ptr-data, transfer_buffer, 
  download_bytes);
  + do_env_save(NULL, 0, 1, NULL);
  + printf(saveenv to '%s' DONE!\n, ptn-name);

 I think it is a bad idea to split formatting / reformatting
 envrionment data alll over the place.  This should be done only once,
 in the environment handling code.  Also, I do not like you using
 do_env_save() here - this should remain a static function.  Why do't
 you simply use saveenv() here?

 Finally, the saveenv to '%s' DONE!\n is IMO too verbose.  No news is
 Good News - we usually do not report abot the success of operations,
 as this is what we expect.  We should only print error messages when
 such occur - which points out another problem of that code: there is
 no error checking nor handling there...


  +static void end_ptbl(struct ptable *ptbl)
  +{
  + struct efi_header *hdr = ptbl-header;
  + u32 n;
  +
  + n = crc32(0, 0, 0);

 What exactly is this good for?

  + n = crc32(n, (void *)ptbl-entry, sizeof(ptbl-entry));
  + hdr-entries_crc32 = n;
  +
  + n = crc32(0, 0, 0);

 What exactly is this good for?

  + n = crc32(0, (void *)ptbl-header, sizeof(ptbl-header));
  + hdr-crc32 = n;
  +}


  + for (n = 0; n  (128/4); n++) {
  + /* read partition */
  + source[0] = '\0';
  + dest[0] = '\0';
  + length[0] = '\0';

 You overwrite source, dest, and length by the sprintf()s just a few
 lines below.  So why are you doing this here?

  + mmc_read[2] = source;
  + mmc_read[3] = dest;
  + mmc_read[4] = length;
  +
  + sprintf(source, %p, entry);
  + sprintf(dest, 0x%x, 0x1+n);
  + sprintf(length, 0x%x, 1);


  +int board_mmc_fbtptn_init(void)
  +{
  + char *mmc_init[2] = {mmc, rescan,};
  + char dev[2];
  + char *mmc_dev[3] = {mmc, dev, NULL};
  +
  + mmc_dev[2] = dev;

 Why do you initialize mmc_dev[2] with another value just a line
 above?  Why don't you use the correct value right from the beginning?

  + if (do_mmcops(NULL, 0, 3, mmc_dev)) {
  + printf(MMC DEV: %d selection FAILED!\n, CONFIG_FB_MMCDEV);
  + return -1;

Re: [U-Boot] Pull request: u-boot-arm/master

On Wed, Sep 17, 2014 at 11:40:43PM +0200, Albert ARIBAUD wrote:

 Hi Tom,
 
 The following changes since commit
 a7f99bf139b3aaa0d5494693fd0395084355e41a:
 
   arm: Fix _start for CONFIG_SYS_DV_NOR_BOOT_CFG (2014-09-11 18:04:39
   +0200)
 
 are available in the git repository at:
 
   git://git.denx.de/u-boot-arm master
 
 for you to fetch changes up to c292adae170fa8c27dca75963bdb0a9afc640e57:
 
   Merge branch 'u-boot-imx/master' into 'u-boot-arm/master' (2014-09-17
   23:35:34 +0200)
 
 NOTE: two boards are broken by this PR, trimslice and cm_fx6, due to
 commits in the imx tree depending on some commits in the spi tree. Once
 both this PR and the spi commits are in, both boards should build fine
 again.
 
 
 
 Albert ARIBAUD (1):
   Merge branch 'u-boot-imx/master' into 'u-boot-arm/master'
 
 Fabio Estevam (9):
   net: fec_mxc: Adjust RX DMA alignment for mx6solox
   net: fec_mxc: Poll FEC_TBD_READY after polling TDAR
   tools: imximage: Fix the maximum DCD size for mx53/mx6
   mx6dlsabresd: Use its own DCD table
   mx6qsabreauto: Remove imx6q-sabreauto.dts
   mx6: imx-regs: Provide a structure for GPC registers
   pcie_imx: Add mx6solox support
   mx6sxsabresd: Add PCI support
   README.imximage: Fix the maximum DCD size
 
 Guillaume GARDET (1):
   imx: nitrogen6x: Replace 'fatload' by 'load' command in env
 settings to be filesystem independent
 
 Nikita Kiryanov (16):
   mx6: add clock enabling functions
   compulab: eeprom: add support for defining eeprom i2c bus
   sata: dwc_ahsata: implement sata_port_status
   i2c: imx: add macros to setup pads for multiple SoC types
   arm: mx6: ddr: cleanup
   arm: mx6: ddr: do not write into reserved bit
   arm: mx6: ddr: configure MMDC for slow_pd
   arm: mx6: ddr: fix cs0_end calculation
   arm: mx6: add get_cpu_type()
   arm: mx6: add support for Compulab cm-fx6 CoM
   arm: mx6: cm_fx6: add nand support
   arm: mx6: cm_fx6: add ethernet support
   arm: mx6: cm_fx6: add usb support
   arm: mx6: cm_fx6: add i2c support
   arm: mx6: cm_fx6: use eeprom
   arm: mx6: cm_fx6: add sata support
 
 Nikolay Dimitrov (1):
   mx6: Fix ECSPI typo in soc_boot_modes
 
 Stefan Agner (2):
   arm: vf610: lpuart: fix status register handling
   arm: vf610: lpuart: disable FIFO on initializaton
 
 Stefano Babic (1):
   imx: Fix build of mx6sxsabresd
 
 Thierry Reding (1):
   imx: ventana: Avoid undefined behaviour
 
 Tim Harvey (6):
   imx: ventana: updated notes regarding NAND boot errata
   imx: ventana: base SPL MMDC calibration on width and size not
 board imx: ventana: add GW5520 support
   imx: ventana: added cputype env var
   pci: add support for board_pci_fixup_dev function
   imx: ventana: add pci fixup for PLX PEX860x switch GPIO
 
 Ye.Li (4):
   iMX6: Disable the L2 before chaning the PL310 latency
   imximage: Fix imximage IVT bug for EIM-NOR boot
   imx: mx6q/dlarm2: Change to use generic board
   imx: mx6slevk: Change to use generic board
 
  arch/arm/Kconfig|   4 +
  arch/arm/cpu/armv7/mx6/clock.c  | 107 +-
  arch/arm/cpu/armv7/mx6/ddr.c| 277 
  arch/arm/cpu/armv7/mx6/soc.c|  11 +-
  arch/arm/dts/Makefile   |   1 -
  arch/arm/dts/imx6q-sabreauto.dts|  13 -
  arch/arm/include/asm/arch-mx6/clock.h   |   5 +
  arch/arm/include/asm/arch-mx6/imx-regs.h|  13 +
  arch/arm/include/asm/arch-mx6/iomux.h   |   9 +
  arch/arm/include/asm/arch-mx6/sys_proto.h   |   5 +-
  arch/arm/include/asm/imx-common/mxc_i2c.h   |  33 ++
  board/compulab/cm_fx6/Kconfig   |  23 ++
  board/compulab/cm_fx6/MAINTAINERS   |   6 +
  board/compulab/cm_fx6/Makefile  |  12 +
  board/compulab/cm_fx6/cm_fx6.c  | 483
  
  board/compulab/cm_fx6/common.c  |  84 +
  board/compulab/cm_fx6/common.h  |  37 +++
  board/compulab/cm_fx6/imximage.cfg  |   8 +
  board/compulab/cm_fx6/spl.c | 366
  + board/compulab/common/eeprom.c  |
  13 +- board/freescale/mx6sabresd/mx6dlsabresd.cfg | 131 
  board/gateworks/gw_ventana/eeprom.c |   3 +
  board/gateworks/gw_ventana/gsc.c|   4 +
  board/gateworks/gw_ventana/gw_ventana.c | 118 ++-
  board/gateworks/gw_ventana/gw_ventana_spl.c | 189 ++-
  board/gateworks/gw_ventana/ventana_eeprom.h |   1 +
  configs/cm_fx6_defconfig|   4 +
  configs/mx6dlsabresd_defconfig  |   2 +-
  doc/README.imximage |   2 +-
  drivers/block/dwc_ahsata.c  |  17 +
  drivers/net/fec_mxc.c   |  42 ++-
  drivers/pci/pci.c   |   4

Re: [U-Boot] [PATCH] kconfiglib: change SPDX-License-Identifier to ISC

On Wed, Sep 17, 2014 at 01:37:45PM +0900, Masahiro Yamada wrote:

 Commit f219e01311b2 (tools: Import Kconfiglib)
 added SPDX GPL-2.0+ to this library by mistake.
 It should be ISC.
 
 Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
 Cc: Ulf Magnusson ulfali...@gmail.com

Applied to u-boot/master, thanks!

-- 
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] usb: gadget: fastboot: improve download progress bar

2014-09-17 Thread Bo Shen


Hi Marek,

On 09/17/2014 07:16 PM, Marek Vasut wrote:

On Wednesday, September 17, 2014 at 12:28:57 PM, Bo Shen wrote:

Hi Marek,

On 09/17/2014 06:10 PM, Marek Vasut wrote:

On Wednesday, September 17, 2014 at 09:43:56 AM, Bo Shen wrote:

+CC Lukasz, this is his turf.


When download is ongoing, if the actual size of one transfer
is not the same as BTYES_PER_DOT, which will cause the dot
won't print anymore. Then it will let the user thinking it
is stuck, actually it is transfering without dot printed.

So, improve the method to show the progress bar (print dot).

Signed-off-by: Bo Shen voice.s...@atmel.com
---

   drivers/usb/gadget/f_fastboot.c | 7 +--
   1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/f_fastboot.c
b/drivers/usb/gadget/f_fastboot.c index 7a1acb9..2f13bf0 100644
--- a/drivers/usb/gadget/f_fastboot.c
+++ b/drivers/usb/gadget/f_fastboot.c
@@ -51,6 +51,7 @@ static inline struct f_fastboot
*func_to_fastboot(struct usb_function *f) static struct f_fastboot
*fastboot_func;

   static unsigned int download_size;
   static unsigned int download_bytes;

+static unsigned int num_of_dot;

   static struct usb_endpoint_descriptor fs_ep_in = {

.bLength= USB_DT_ENDPOINT_SIZE,

@@ -414,9 +415,10 @@ static void rx_handler_dl_image(struct usb_ep *ep,
struct usb_request *req) req-length = ep-maxpacket;

}

-   if (download_bytes  !(download_bytes % BYTES_PER_DOT)) {
+   if (download_bytes  ((download_bytes / BYTES_PER_DOT)  num_of_dot))
{ + num_of_dot = download_bytes / BYTES_PER_DOT;

putc('.');

-   if (!(download_bytes % (74 * BYTES_PER_DOT)))
+   if (!(num_of_dot % 74))

putc('\n');

}
req-actual = 0;

@@ -431,6 +433,7 @@ static void cb_download(struct usb_ep *ep, struct
usb_request *req) strsep(cmd, :);

download_size = simple_strtoul(cmd, NULL, 16);
download_bytes = 0;

+   num_of_dot = 0;


Make it a 'download_total' and log the total amount of bytes transferred
please, that way it can be re-used for other purposes in the future ;
for example for printing how much data were already transferred ;-)


The download_bytes record the total amount of bytes transferred.
And the download_bytes will print after finishing transfer.


So why can this not be used to indicate the total progress ? Because the
transfeer speed is variating too much ?


As I described in the commit message. If the transfer length is not 
exactly the same as the request length, then the old method

  download_bytes % BYTES_PER_DOT
won't be 0 anymore, so for the following transfer, it won't print dot 
anymore.


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

Re: [U-Boot] [PATCH 1/3] compiler_gcc: do not redefine __gnu_attributes

Jeroen,

 commit fb8ffd7cfc68b3dc44e182356a207d784cb30b34 compiler*.h:
 sync include/linux/compiler*.h with Linux 3.16 undid the changes
 of 7ea50d52849fe8ffa5b5b74c979b60b1045d6fc9 compiler_gcc: do
 not redefine __gnu_attributes. Add the checks back whether these
 macro's are already defined (as it causes a lot of noise on e.g.
 FreeBSD where these defines are already in cdefs.h)
 
 As the original patch this checkpatch warning is ignored:
 WARNING: Adding new packed members is to be done with care


Strange.

Which source files include cdefs.h?

For building u-boot images, sources should
only include headers in the u-boot source tree.
The standard system headers should not be used
except only a few files such as stdarg.h.

This is the same as Linux Kernel.


On the contrary, host programs are allowed to use
standard system headers such as stdio.h, stdlib.h etc,
where linux/compiler.h should not be included.


The root cause of warnings is _not_ that
__packed and __weak are always defined in compiler-gcc.h.


I believe the real problem is there are some source files include
both system headers and linux/compiler.h at the same time.



Best Regards
Masahiro Yamada

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

Re: [U-Boot] [PATCH 3/3] compiler.h: remove duplicated uninitialized_var

Jeroen,

 Since clang has a different definition for uninitialized_var
 it will complain that it is redefined in include/compiler.h.
 Since these are already defined in linux/compiler.h just remove
 this instance.

 Cc: Masahiro Yamada yamad...@jp.panasonic.com
 Cc: Tom Rini tr...@ti.com
 Signed-off-by: Jeroen Hofstee jer...@myspectrum.nl

I don't mind this patch but it has made me realize
another problem.

We have both include/compiler.h and include/linux/compiler.h.
Some sources use tha former and others use the latter.

I don't know how to use the right one in the right place.

Header file policy is one of the biggest problem in U-boot.

Everyone has added ugly work-arounds to solve his own problem
without correct views or judgement.

 diff --git a/include/compiler.h b/include/compiler.h
 index 9afc11b..1451916 100644
 --- a/include/compiler.h
 +++ b/include/compiler.h
 @@ -129,9 +129,6 @@ typedef unsigned long int uintptr_t;

  #endif /* USE_HOSTCC */

 -/* compiler options */
 -#define uninitialized_var(x) x = x
 -
  #define likely(x)__builtin_expect(!!(x), 1)
  #define unlikely(x)  __builtin_expect(!!(x), 0)

I am not sure if likely(x) and unlikely(x) should also
duplicated here.

Best Regards
Masahiro Yamada

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

[U-Boot] [PATCH v2 2/2] common.h: remove MIN, MAX, MIN3, MAX3 macros

Now MIN, MAX, MIN3, MAX are not used.
Going forward, use min, max, min3, max3.

Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
---

Changes in v2: None

 include/common.h | 6 --
 1 file changed, 6 deletions(-)

diff --git a/include/common.h b/include/common.h
index 97c04df..d5020c8 100644
--- a/include/common.h
+++ b/include/common.h
@@ -181,9 +181,6 @@ typedef void (interrupt_handler_t)(void *);
typeof(Y) __y = (Y);\
(__x  __y) ? __x : __y; })
 
-#define MIN(x, y)  min(x, y)
-#define MAX(x, y)  max(x, y)
-
 #define min3(X, Y, Z)  \
({ typeof(X) __x = (X); \
typeof(Y) __y = (Y);\
@@ -198,9 +195,6 @@ typedef void (interrupt_handler_t)(void *);
__x  __y ? (__x  __z ? __x : __z) :   \
(__y  __z ? __y : __z); })
 
-#define MIN3(x, y, z)  min3(x, y, z)
-#define MAX3(x, y, z)  max3(x, y, z)
-
 /*
  * Return the absolute value of a number.
  *
-- 
1.9.1

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

[U-Boot] [PATCH v2 0/2] Abolish MIN, MAX, MIN3, MAX



Changes in v2:
  - Rebase on commit 9170818a4e004

Masahiro Yamada (2):
  cosmetic: replace MIN, MAX with min, max
  common.h: remove MIN, MAX, MIN3, MAX3 macros

 arch/arm/cpu/arm1176/tnetv107x/clock.c |  2 +-
 arch/arm/cpu/armv7/mx6/ddr.c   | 40 +-
 arch/x86/lib/physmem.c |  4 ++--
 board/freescale/common/ics307_clk.c|  2 +-
 drivers/dma/fsl_dma.c  |  2 +-
 drivers/i2c/ihs_i2c.c  |  4 ++--
 drivers/mmc/fsl_esdhc.c|  2 +-
 drivers/serial/usbtty.c|  4 ++--
 drivers/usb/gadget/designware_udc.c|  4 ++--
 drivers/usb/gadget/ep0.c   |  2 +-
 drivers/usb/gadget/mpc8xx_udc.c|  4 ++--
 drivers/usb/gadget/pxa27x_udc.c|  2 +-
 fs/zfs/zfs.c   |  6 ++---
 include/common.h   |  6 -
 14 files changed, 39 insertions(+), 45 deletions(-)

-- 
1.9.1

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

[U-Boot] [PATCH v2 1/2] cosmetic: replace MIN, MAX with min, max

The macro MIN, MAX is defined as the aliase of min, max,
respectively.

Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
---

Changes in v2:
  - Rebase on commit 9170818a4e004

 arch/arm/cpu/arm1176/tnetv107x/clock.c |  2 +-
 arch/arm/cpu/armv7/mx6/ddr.c   | 40 +-
 arch/x86/lib/physmem.c |  4 ++--
 board/freescale/common/ics307_clk.c|  2 +-
 drivers/dma/fsl_dma.c  |  2 +-
 drivers/i2c/ihs_i2c.c  |  4 ++--
 drivers/mmc/fsl_esdhc.c|  2 +-
 drivers/serial/usbtty.c|  4 ++--
 drivers/usb/gadget/designware_udc.c|  4 ++--
 drivers/usb/gadget/ep0.c   |  2 +-
 drivers/usb/gadget/mpc8xx_udc.c|  4 ++--
 drivers/usb/gadget/pxa27x_udc.c|  2 +-
 fs/zfs/zfs.c   |  6 ++---
 13 files changed, 39 insertions(+), 39 deletions(-)

diff --git a/arch/arm/cpu/arm1176/tnetv107x/clock.c 
b/arch/arm/cpu/arm1176/tnetv107x/clock.c
index 3708b6f..47c23bb 100644
--- a/arch/arm/cpu/arm1176/tnetv107x/clock.c
+++ b/arch/arm/cpu/arm1176/tnetv107x/clock.c
@@ -362,7 +362,7 @@ static void init_pll(const struct pll_init_data *data)
pllctl_reg_write(data-pll, ctl, tmp);
 
mult = data-pll_freq / fpll;
-   for (mult = MAX(mult, 1); mult = MAX_MULT; mult++) {
+   for (mult = max(mult, 1); mult = MAX_MULT; mult++) {
div = (fpll * mult) / data-pll_freq;
if (div  1 || div  MAX_DIV)
continue;
diff --git a/arch/arm/cpu/armv7/mx6/ddr.c b/arch/arm/cpu/armv7/mx6/ddr.c
index 7b5c1e4..7a9b03a 100644
--- a/arch/arm/cpu/armv7/mx6/ddr.c
+++ b/arch/arm/cpu/armv7/mx6/ddr.c
@@ -247,47 +247,47 @@ void mx6_dram_cfg(const struct mx6_ddr_sysinfo *sysinfo,
 
switch (ddr3_cfg-mem_speed) {
case 800:
-   txp = DIV_ROUND_UP(MAX(3 * clkper, 7500), clkper) - 1;
-   tcke = DIV_ROUND_UP(MAX(3 * clkper, 7500), clkper) - 1;
+   txp = DIV_ROUND_UP(max(3 * clkper, 7500), clkper) - 1;
+   tcke = DIV_ROUND_UP(max(3 * clkper, 7500), clkper) - 1;
if (ddr3_cfg-pagesz == 1) {
tfaw = DIV_ROUND_UP(4, clkper) - 1;
-   trrd = DIV_ROUND_UP(MAX(4 * clkper, 1), clkper) - 1;
+   trrd = DIV_ROUND_UP(max(4 * clkper, 1), clkper) - 1;
} else {
tfaw = DIV_ROUND_UP(5, clkper) - 1;
-   trrd = DIV_ROUND_UP(MAX(4 * clkper, 1), clkper) - 1;
+   trrd = DIV_ROUND_UP(max(4 * clkper, 1), clkper) - 1;
}
break;
case 1066:
-   txp = DIV_ROUND_UP(MAX(3 * clkper, 7500), clkper) - 1;
-   tcke = DIV_ROUND_UP(MAX(3 * clkper, 5625), clkper) - 1;
+   txp = DIV_ROUND_UP(max(3 * clkper, 7500), clkper) - 1;
+   tcke = DIV_ROUND_UP(max(3 * clkper, 5625), clkper) - 1;
if (ddr3_cfg-pagesz == 1) {
tfaw = DIV_ROUND_UP(37500, clkper) - 1;
-   trrd = DIV_ROUND_UP(MAX(4 * clkper, 7500), clkper) - 1;
+   trrd = DIV_ROUND_UP(max(4 * clkper, 7500), clkper) - 1;
} else {
tfaw = DIV_ROUND_UP(5, clkper) - 1;
-   trrd = DIV_ROUND_UP(MAX(4 * clkper, 1), clkper) - 1;
+   trrd = DIV_ROUND_UP(max(4 * clkper, 1), clkper) - 1;
}
break;
case 1333:
-   txp = DIV_ROUND_UP(MAX(3 * clkper, 6000), clkper) - 1;
-   tcke = DIV_ROUND_UP(MAX(3 * clkper, 5625), clkper) - 1;
+   txp = DIV_ROUND_UP(max(3 * clkper, 6000), clkper) - 1;
+   tcke = DIV_ROUND_UP(max(3 * clkper, 5625), clkper) - 1;
if (ddr3_cfg-pagesz == 1) {
tfaw = DIV_ROUND_UP(3, clkper) - 1;
-   trrd = DIV_ROUND_UP(MAX(4 * clkper, 6000), clkper) - 1;
+   trrd = DIV_ROUND_UP(max(4 * clkper, 6000), clkper) - 1;
} else {
tfaw = DIV_ROUND_UP(45000, clkper) - 1;
-   trrd = DIV_ROUND_UP(MAX(4 * clkper, 7500), clkper) - 1;
+   trrd = DIV_ROUND_UP(max(4 * clkper, 7500), clkper) - 1;
}
break;
case 1600:
-   txp = DIV_ROUND_UP(MAX(3 * clkper, 6000), clkper) - 1;
-   tcke = DIV_ROUND_UP(MAX(3 * clkper, 5000), clkper) - 1;
+   txp = DIV_ROUND_UP(max(3 * clkper, 6000), clkper) - 1;
+   tcke = DIV_ROUND_UP(max(3 * clkper, 5000), clkper) - 1;
if (ddr3_cfg-pagesz == 1) {
tfaw = DIV_ROUND_UP(3, clkper) - 1;
-   trrd = DIV_ROUND_UP(MAX(4 * clkper, 6000), clkper) - 1;
+   trrd = DIV_ROUND_UP(max(4 * clkper, 6000), clkper) - 1;

Re: [U-Boot] [PATCH v2 2/2] doc: Use KBUILD_OUTPUT instead of BUILD_DIR


On Sun, 31 Aug 2014 21:20:31 +0530
Jagannadha Sutradharudu Teki jagannadh.t...@gmail.com wrote:

 From: Jagannadha Sutradharudu Teki jagannadh.t...@gmail.com
 
 Now saving output files in a separate directory through
 KBUILD_OUTPUT not with BUILD_DIR, so updated the documentation
 accordingly.
 
 Signed-off-by: Jagannadha Sutradharudu Teki jagannadh.t...@gmail.com
 ---
 Changes for v2:
   - none


I left comments in v1:

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



Best Regards
Masahiro Yamada

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

Re: [U-Boot] [linux-sunxi] Re: [PATCH 0/7] ARM: sunxi: Add basic support for Allwinner A31 (sun6i)

2014-09-17 Thread Siarhei Siamashka

On Tue, 09 Sep 2014 09:00:57 +0200
Hans de Goede hdego...@redhat.com wrote:

Hi,

On 09/08/2014 03:28 PM, Chen-Yu Tsai wrote:
Hi everyone,

This series add basic support for Allwinner's A31 SoC. The patches,
excluding the first one, were cherry-picked from u-boot-sunxi. Due to
the difference between u-boot mainline and u-boot-sunxi, some patches
were rearranged or squashed to better fit the current state of u-boot,
and not introduce any build breaks. It follows Ian's initial merge
method of sun7i support: introducing various components first, then
enabling them in the last commit. I tried to keep the commits separate,
thus retaining the original author and Signed-off-bys.

Patch 1 adds a wrapper around func(USB, usb, 0) in BOOT_TARGET_DEVICES
to deal with breakage when USB support is not enabled.

Patch 2 adds memory addresses for some hardware blocks new in sun6i.

Patch 3 adds support for the new PRCM (power reset and clock management)
block, which also contains PLL bias voltage control.

Patch 4 adds support for the clock module. This patch is a bunch of
different sun6i related patches on the clock code, from when sun6i
support was introduced to u-boot-sunxi, up to its current form.
This is done to avoid various conflicts and needlessly introducing
then removing macros.

Patch 5 adds mmc support on sun6i.

Patch 6 adds uart0 muxing on sun6i.

Patch 7 enables sun6i support and adds defconfig for the Colombus board.

Chen,

Many thanks for working on this!

Just a quick not for people celebrating too early, this is the *incomplete*
sun7i support from the linux-sunxi/u-boot-sunxi git repo. It is fine to
merge this upstream, but this does not include SPL support.

This allows replacing u-boot.bin on allwinnner sd-card images, which is
very useful. But it does not get us all the way to booting sun7i devices
we still need boot0 and boot1 binaries from allwinner for that (for now).

If I understand it correctly, one of the things that needs to be done
in SPL is the initialization of the DRAM controller. A few weeks ago
Oliver has updated the http://linux-sunxi.org/DRAM_Controller page
and added a link to the 'dram_sun6i.c' file from the rhombus-tech.net
u-boot repository:

http://git.rhombus-tech.net/?p=u-boot.git;a=blob;f=arch/arm/cpu/armv7/sunxi/dram_sun6i.c;hb=refs/heads/allwinner-sunxi-a31
Does this repository look like exactly the missing part of code?
Assuming that this code works, it provides a usable starting point
for us.

It looks like the Allwinner A31 DRAM controller registers are very
similar to what is used in RK3288 (I have not checked the details,
but if we are very lucky, it might be even a 100% perfect match):
https://chromium-review.googlesource.com/#/c/209419/
And thanks to the Rockchip developers (who are contributing this
DRAM controller support code to coreboot), now we have a lot of
named defines for the individual bitfields in the hardware
registers. So we can decode the magic constants used in the
Allwinner code. And thanks to Texas Instruments, we also have
some useful documentation, which also happens to be a reasonably
good match:
http://www.ti.com/lit/ug/spruhn7a/spruhn7a.pdf

In general, if we are on our own, then we just need to do all the
boring work again (similar to what we did with the Allwinner
A10/A13/A20 DRAM controller earlier). Starting with the creation of the
http://linux-sunxi.org/A31_DRAM_Controller_Register_Guide
wiki page and populating it with the information gathered from the
Allwinner and Rockchip source code and also from the TI Keystone2
documentation. Naturally, every bit of this information needs to
be verified on real Allwinner A31 hardware before we can make any
assumptions.

However Allwinner has promised to provide us with some better
documentation later this month:
https://www.mail-archive.com/linux-sunxi@googlegroups.com/msg06840.html
I don't know if they are going to include the documentation for the
DRAM controller in the first new documentation delivery. It surely
may be complicated, because Allwinner is obviously licensing the DRAM
controller IP from a third party and not designing it from scratch
(in a nice company with Rockchip and Texas Instruments). But Texas
Instruments somehow can provide the DRAM controller documentation
in free public access. So I would guess that it should be possible
for Allwinner too.

We still need proper Power-Down and Self-Refresh mode support for
Allwinner A10/A13/A20. And I had plans to do some investigation for
this stuff. But now this activity is temporarily suspended until
we see what kind of assistance Allwinner is going to provide to us
(A usable DRAM controller documentation? A contribution of DRAM
code for u-boot? Nothing?).

--
Best regards,
Siarhei Siamashka
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Email address of SPEAr custodian is not working