Re: [U-Boot] [U-boot] question about pl310.h / armv7.h

[Matt Sealey]

I would agree with the idea moving pl310 functionality into
pl310-specific files - armv7 doesn't dictate use of pl310 (or an
external cache controller of any nature) at least for about half the
possible cores you could go find. Those that need/configure for an
external L2 controller may not even really use pl310 (Marvell for
example?) even if they're compatible with v7 in nature, so it makes no
sense to just lump all the prototypes into a generic header.

Obviously it depends on what those functions are and if they're
actually implemented elsewhere... in which case they should be moved
to the pl310 support so they're not compiled in or needlessly
cluttering up other source files.

-- Matt

On Mon, Aug 19, 2013 at 3:04 AM,  tiger...@viatech.com.cn wrote:
 Hi, experts:

 There are 4 functions definition in arch/arm/include/asm/pl310.h .

 But not implemented in cache-pl310.c file.



 And the implemented functions in cache-pl310.c file are defined in
 arch/arm/include/asm/armv7.h .



 So, maybe pl310.h should be deleted?

 Or function declarations are moved from armv7.h to pl310.h ?



 Best wishes,


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

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

Re: [U-Boot] [PATCH 04/12] imx: mx51_efikamx/sb: Convert to iomux-v3

[Matt Sealey]

I mean Signed-off-by since I'm the maintainer on the file you changed
and I put the iomux-v3 support in the tree in the first place so I'm
in the delivery path of the patch ;)

Sure, I tested it, otherwise I wouldn't be totally fine with it. But
this is code I have to look after in the future... so I'm signing off
on it.

On Fri, May 3, 2013 at 11:01 AM, Benoît Thébaudeau
benoit.thebaud...@advansee.com wrote:
 On Friday, May 3, 2013 5:58:24 PM, Matt Sealey wrote:
 I had a patch queued which did exactly this, but I am fine with
 someone else doing it ;)

 Tested works exactly the same.

 Signed-off-by: Matt Sealey m...@genesi-usa.com

 You probably mean Tested-by.

 Best regards,
 Benoît



-- 
Matt Sealey m...@genesi-usa.com
Product Development Analyst, Genesi USA, Inc.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 04/12] imx: mx51_efikamx/sb: Convert to iomux-v3

[Matt Sealey]

I had a patch queued which did exactly this, but I am fine with
someone else doing it ;)

Tested works exactly the same.

Signed-off-by: Matt Sealey m...@genesi-usa.com

On Thu, May 2, 2013 at 3:52 PM, Benoît Thébaudeau
benoit.thebaud...@advansee.com wrote:
 There is no change of behavior, except for older silicon revisions for which
 support is removed.

 Signed-off-by: Benoît Thébaudeau benoit.thebaud...@advansee.com
 ---
  board/genesi/mx51_efikamx/efikamx-usb.c |  122 
 +--
  1 file changed, 69 insertions(+), 53 deletions(-)

 diff --git a/board/genesi/mx51_efikamx/efikamx-usb.c 
 b/board/genesi/mx51_efikamx/efikamx-usb.c
 index cf020c3..cabad70 100644
 --- a/board/genesi/mx51_efikamx/efikamx-usb.c
 +++ b/board/genesi/mx51_efikamx/efikamx-usb.c
 @@ -26,8 +26,7 @@
  #include usb.h
  #include asm/io.h
  #include asm/arch/imx-regs.h
 -#include asm/arch/mx5x_pins.h
 -#include asm/arch/iomux.h
 +#include asm/arch/iomux-mx51.h
  #include asm/gpio.h
  #include usb/ehci-fsl.h
  #include usb/ulpi.h
 @@ -35,40 +34,57 @@

  #include ../../../drivers/usb/host/ehci.h

 -/* USB pin configuration */
 -#define USB_PAD_CONFIG (PAD_CTL_PKE_ENABLE | PAD_CTL_SRE_FAST | \
 -   PAD_CTL_DRV_HIGH | PAD_CTL_100K_PU | \
 -   PAD_CTL_HYS_ENABLE | PAD_CTL_PUE_PULL)
 -
  /*
   * Configure the USB H1 and USB H2 IOMUX
   */
  void setup_iomux_usb(void)
  {
 -   setup_iomux_usb_h1();
 -
 -   if (machine_is_efikasb())
 -   setup_iomux_usb_h2();
 -
 -   /* USB PHY reset */
 -   mxc_request_iomux(MX51_PIN_EIM_D27, IOMUX_CONFIG_ALT1);
 -   mxc_iomux_set_pad(MX51_PIN_EIM_D27, PAD_CTL_PKE_ENABLE |
 -   PAD_CTL_SRE_FAST | PAD_CTL_DRV_HIGH);
 -
 -   /* USB HUB reset */
 -   mxc_request_iomux(MX51_PIN_GPIO1_5, IOMUX_CONFIG_ALT0);
 -   mxc_iomux_set_pad(MX51_PIN_GPIO1_5, PAD_CTL_PKE_ENABLE |
 -   PAD_CTL_SRE_FAST | PAD_CTL_DRV_HIGH);
 -
 -   /* WIFI EN (act low) */
 -   mxc_request_iomux(MX51_PIN_EIM_A22, IOMUX_CONFIG_GPIO);
 -   mxc_iomux_set_pad(MX51_PIN_EIM_A22, 0);
 -   /* WIFI RESET */
 -   mxc_request_iomux(MX51_PIN_EIM_A16, IOMUX_CONFIG_GPIO);
 -   mxc_iomux_set_pad(MX51_PIN_EIM_A16, 0);
 -   /* BT EN (act low) */
 -   mxc_request_iomux(MX51_PIN_EIM_A17, IOMUX_CONFIG_GPIO);
 -   mxc_iomux_set_pad(MX51_PIN_EIM_A17, 0);
 +   static const iomux_v3_cfg_t usb_h1_pads[] = {
 +   MX51_PAD_USBH1_CLK__USBH1_CLK,
 +   MX51_PAD_USBH1_DIR__USBH1_DIR,
 +   MX51_PAD_USBH1_STP__USBH1_STP,
 +   MX51_PAD_USBH1_NXT__USBH1_NXT,
 +   MX51_PAD_USBH1_DATA0__USBH1_DATA0,
 +   MX51_PAD_USBH1_DATA1__USBH1_DATA1,
 +   MX51_PAD_USBH1_DATA2__USBH1_DATA2,
 +   MX51_PAD_USBH1_DATA3__USBH1_DATA3,
 +   MX51_PAD_USBH1_DATA4__USBH1_DATA4,
 +   MX51_PAD_USBH1_DATA5__USBH1_DATA5,
 +   MX51_PAD_USBH1_DATA6__USBH1_DATA6,
 +   MX51_PAD_USBH1_DATA7__USBH1_DATA7,
 +   };
 +
 +   static const iomux_v3_cfg_t usb_pads[] = {
 +   MX51_PAD_EIM_D27__GPIO2_9, /* USB PHY reset */
 +   MX51_PAD_GPIO1_5__GPIO1_5, /* USB HUB reset */
 +   NEW_PAD_CTRL(MX51_PAD_EIM_A22__GPIO2_16, 0), /* WIFI /EN */
 +   NEW_PAD_CTRL(MX51_PAD_EIM_A16__GPIO2_10, 0), /* WIFI RESET */
 +   NEW_PAD_CTRL(MX51_PAD_EIM_A17__GPIO2_11, 0), /* BT /EN */
 +   };
 +
 +   imx_iomux_v3_setup_multiple_pads(usb_h1_pads, 
 ARRAY_SIZE(usb_h1_pads));
 +
 +   if (machine_is_efikasb()) {
 +   static const iomux_v3_cfg_t usb_h2_pads[] = {
 +   MX51_PAD_EIM_A24__USBH2_CLK,
 +   MX51_PAD_EIM_A25__USBH2_DIR,
 +   MX51_PAD_EIM_A26__USBH2_STP,
 +   MX51_PAD_EIM_A27__USBH2_NXT,
 +   MX51_PAD_EIM_D16__USBH2_DATA0,
 +   MX51_PAD_EIM_D17__USBH2_DATA1,
 +   MX51_PAD_EIM_D18__USBH2_DATA2,
 +   MX51_PAD_EIM_D19__USBH2_DATA3,
 +   MX51_PAD_EIM_D20__USBH2_DATA4,
 +   MX51_PAD_EIM_D21__USBH2_DATA5,
 +   MX51_PAD_EIM_D22__USBH2_DATA6,
 +   MX51_PAD_EIM_D23__USBH2_DATA7,
 +   };
 +
 +   imx_iomux_v3_setup_multiple_pads(usb_h2_pads,
 +ARRAY_SIZE(usb_h2_pads));
 +   }
 +
 +   imx_iomux_v3_setup_multiple_pads(usb_pads, ARRAY_SIZE(usb_pads));
  }

  /*
 @@ -77,18 +93,18 @@ void setup_iomux_usb(void)
  static void efika_usb_enable_devices(void)
  {
 /* Enable Bluetooth */
 -   gpio_direction_output(IOMUX_TO_GPIO(MX51_PIN_EIM_A17), 0);
 +   gpio_direction_output(IMX_GPIO_NR(2, 11), 0);
 udelay(1);
 -   gpio_set_value(IOMUX_TO_GPIO(MX51_PIN_EIM_A17), 1);
 +   gpio_set_value

Re: [U-Boot] [PATCH] Add U_BOOT_TIMESTAMP definition

[Matt Sealey]

Hi Wolfgang,

On Sat, Mar 9, 2013 at 1:09 AM, Wolfgang Denk w...@denx.de wrote:
 Dear Matt,

 In message 1345733053-5023-1-git-send-email-m...@genesi-usa.com you wrote:
 This gives us a string like 20120822150855 which encodes the build time.

 This allows automated version checking and flashing of U-Boot to be 
 performed,
 for example, in boot.scr files (or scripting in general).

 I just noticed that this was never applied.  Sorry...

No problem.

  Makefile |1 +
  1 file changed, 1 insertion(+)

 diff --git a/Makefile b/Makefile
 index 1df4c1d..c042206 100644
 --- a/Makefile
 +++ b/Makefile
 @@ -664,6 +664,7 @@ $(TIMESTAMP_FILE):
   @mkdir -p $(dir $(TIMESTAMP_FILE))
   @LC_ALL=C date +'#define U_BOOT_DATE %b %d %C%y'  $@.tmp
   @LC_ALL=C date +'#define U_BOOT_TIME %T'  $@.tmp
 + @LC_ALL=C date +'#define U_BOOT_TIMESTAMP %Y%m%d%H%M%S'  
 $@.tmp
   @cmp -s $@ $@.tmp  rm -f $@.tmp || mv -f $@.tmp $@

 But then - you only add a new #define to the build environment,
 without any users of it, i. e. dead code.

 Did you intend to post any code that would use this (in this case these
 patches should be merged into one, or at least into a series), or can
 we simply drop this patch?

I did intend to submit a patch; what I wanted to do was gain some
comments about it before I made
our Efika MX configuration use it, and then it moved itself to development hell.

I will submit this as a series shortly (with the configuration update)
if this patch has been dropped
already, alternatively I will just submit the configuration update and
remark that it requires this patch.

Is that okay?

-- 
Matt Sealey m...@genesi-usa.com
Product Development Analyst, Genesi USA, Inc.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 13/13] mxc nand: Add support for i.MX5

[Matt Sealey]

Hi Benoit,

Just a FYI the Efika MX products use PATA devices (Sandisk pSSD-P2 or
similar) so it's not a good test. We do have an MX53 board with NAND on the
NFC - but we're sticking with Freescale's BSP U-Boot for the time being on
that particular product. If I can schedule some time for it I will test it.

Matt Sealey m...@genesi-usa.com
Product Development Analyst, Genesi USA, Inc.


On Sat, Nov 17, 2012 at 12:37 PM, Fabio Estevam feste...@gmail.com wrote:

 On Fri, Nov 16, 2012 at 6:15 PM, Benoît Thébaudeau
 benoit.thebaud...@advansee.com wrote:

  It's hard to find the schematics of all the i.MX5 boards supported by
 mainline
  U-Boot. According to the links below, at least the Genesi EFIKA MX
 Smartbook and
  the Freescale MX53 ARD boards have embedded NAND. Matt, Fabio, is it
 possible to
  find the schematics of these boards somewhere?

 Yes, will send you offline.

 Regards,

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

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

Re: [U-Boot] [PATCH] MX5: efikamx: substitutes GPIO_NUMBER with IMX_GPIO_NR

[Matt Sealey]

That's odd, I thought I fixed that.

+#define EFIKAMX_USB_HUB_RESET  IMX_GPIO_NR(1, 5)
+#define EFIKAMX_USB_PHY_RESET  IMX_GPIO_NR(2, 9)

I copied the above two lines from my patch to the ML.. what happened here? :(

-- 
Matt Sealey m...@genesi-usa.com
Product Development Analyst, Genesi USA, Inc.


On Tue, Aug 28, 2012 at 8:10 AM, Stefano Babic sba...@denx.de wrote:
 The macro to get the gpio number id was renamed to
 IMX_GPIO_NR as in kernel. Fix the wrong name in efika.

 Signed-off-by: Stefano Babic sba...@denx.de
 CC: Matt Sealey m...@genesi-usa.com
 ---
  board/genesi/mx51_efikamx/efikamx.c |   48 
 +--
  1 file changed, 24 insertions(+), 24 deletions(-)

 diff --git a/board/genesi/mx51_efikamx/efikamx.c 
 b/board/genesi/mx51_efikamx/efikamx.c
 index 18ab8d9..3968040 100644
 --- a/board/genesi/mx51_efikamx/efikamx.c
 +++ b/board/genesi/mx51_efikamx/efikamx.c
 @@ -81,14 +81,14 @@ static u32 get_mx_rev(void)
  */

 /* set to 1 in order to get correct value on board rev 1.1 */
 -   gpio_direction_output(GPIO_NUMBER(3, 16), 1);
 -   gpio_direction_input(GPIO_NUMBER(3, 11));
 -   gpio_direction_input(GPIO_NUMBER(3, 16));
 -   gpio_direction_input(GPIO_NUMBER(3, 17));
 +   gpio_direction_output(IMX_GPIO_NR(3, 16), 1);
 +   gpio_direction_input(IMX_GPIO_NR(3, 11));
 +   gpio_direction_input(IMX_GPIO_NR(3, 16));
 +   gpio_direction_input(IMX_GPIO_NR(3, 17));

 -   rev |= (!!gpio_get_value(GPIO_NUMBER(3, 16)))  0;
 -   rev |= (!!gpio_get_value(GPIO_NUMBER(3, 17)))  1;
 -   rev |= (!!gpio_get_value(GPIO_NUMBER(3, 11)))  2;
 +   rev |= (!!gpio_get_value(IMX_GPIO_NR(3, 16)))  0;
 +   rev |= (!!gpio_get_value(IMX_GPIO_NR(3, 17)))  1;
 +   rev |= (!!gpio_get_value(IMX_GPIO_NR(3, 11)))  2;

 return (~rev  0x7) + 1;
  }
 @@ -104,11 +104,11 @@ static inline u32 get_sb_rev(void)

 imx_iomux_v3_setup_multiple_pads(efikasb_revision_pads,
 ARRAY_SIZE(efikasb_revision_pads));
 -   gpio_direction_input(GPIO_NUMBER(2, 28));
 -   gpio_direction_input(GPIO_NUMBER(2, 29));
 +   gpio_direction_input(IMX_GPIO_NR(2, 28));
 +   gpio_direction_input(IMX_GPIO_NR(2, 29));

 -   rev |= (!!gpio_get_value(GPIO_NUMBER(2, 28)))  0;
 -   rev |= (!!gpio_get_value(GPIO_NUMBER(2, 29)))  1;
 +   rev |= (!!gpio_get_value(IMX_GPIO_NR(2, 28)))  0;
 +   rev |= (!!gpio_get_value(IMX_GPIO_NR(2, 29)))  1;

 return rev;
  }
 @@ -159,9 +159,9 @@ static iomux_v3_cfg_t efikamx_spi_pads[] = {
 MX51_PAD_GPIO1_6__GPIO1_6,
  };

 -#define EFIKAMX_SPI_SS0GPIO_NUMBER(4, 24)
 -#define EFIKAMX_SPI_SS1GPIO_NUMBER(4, 25)
 -#define EFIKAMX_PMIC_IRQ   GPIO_NUMBER(1, 6)
 +#define EFIKAMX_SPI_SS0IMX_GPIO_NR(4, 24)
 +#define EFIKAMX_SPI_SS1IMX_GPIO_NR(4, 25)
 +#define EFIKAMX_PMIC_IRQ   IMX_GPIO_NR(1, 6)

  /*
   * PMIC configuration
 @@ -282,15 +282,15 @@ static iomux_v3_cfg_t efikamx_sdhc1_pads[] = {
 MX51_PAD_GPIO1_1__SD1_WP,
  };

 -#define EFIKAMX_SDHC1_WP   GPIO_NUMBER(1, 1)
 +#define EFIKAMX_SDHC1_WP   IMX_GPIO_NR(1, 1)

  static iomux_v3_cfg_t efikamx_sdhc1_cd_pads[] = {
 MX51_PAD_GPIO1_0__SD1_CD,
 MX51_PAD_EIM_CS2__SD1_CD,
  };

 -#define EFIKAMX_SDHC1_CD   GPIO_NUMBER(1, 0)
 -#define EFIKASB_SDHC1_CD   GPIO_NUMBER(2, 27)
 +#define EFIKAMX_SDHC1_CD   IMX_GPIO_NR(1, 0)
 +#define EFIKASB_SDHC1_CD   IMX_GPIO_NR(2, 27)

  static iomux_v3_cfg_t efikasb_sdhc2_pads[] = {
 MX51_PAD_SD2_CMD__SD2_CMD,
 @@ -303,8 +303,8 @@ static iomux_v3_cfg_t efikasb_sdhc2_pads[] = {
 MX51_PAD_GPIO1_8__SD2_CD,
  };

 -#define EFIKASB_SDHC2_CD   GPIO_NUMBER(1, 8)
 -#define EFIKASB_SDHC2_WP   GPIO_NUMBER(1, 7)
 +#define EFIKASB_SDHC2_CD   IMX_GPIO_NR(1, 8)
 +#define EFIKASB_SDHC2_WP   IMX_GPIO_NR(1, 7)

  static inline uint32_t efikamx_mmc_getcd(u32 base)
  {
 @@ -415,17 +415,17 @@ static inline void setup_iomux_usb(void) { }
   * Smarttop LED pad config is done in the DCD
   *
   */
 -#define EFIKAMX_LED_BLUE   GPIO_NUMBER(3, 13)
 -#define EFIKAMX_LED_GREEN  GPIO_NUMBER(3, 14)
 -#define EFIKAMX_LED_REDGPIO_NUMBER(3, 15)
 +#define EFIKAMX_LED_BLUE   IMX_GPIO_NR(3, 13)
 +#define EFIKAMX_LED_GREEN  IMX_GPIO_NR(3, 14)
 +#define EFIKAMX_LED_REDIMX_GPIO_NR(3, 15)

  static iomux_v3_cfg_t efikasb_led_pads[] = {
 MX51_PAD_GPIO1_3__GPIO1_3,
 MX51_PAD_EIM_CS0__GPIO2_25,
  };

 -#define EFIKASB_CAPSLOCK_LED   GPIO_NUMBER(2, 25)
 -#define EFIKASB_MESSAGE_LEDGPIO_NUMBER(1, 3) /* Note: active low */
 +#define EFIKASB_CAPSLOCK_LED   IMX_GPIO_NR(2, 25)
 +#define EFIKASB_MESSAGE_LEDIMX_GPIO_NR(1, 3) /* Note: active low */

  /*
   * Board initialization
 --
 1.7.9.5

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

[U-Boot] [PATCH v2] efikamx: update to Efika MX Smarttop and Smartbook boards

[Matt Sealey]

This is a rework of a previously submitted patchset and bundles the
main board support and USB support into a single commit.

It requires the patch mx5: add iomux-mx51.h include

* Use iomux-mx51.h include to simplify board configuration.
* Simplify LED support (remove efikamx_toggle_led, change lit LEDs).
* Simplify MMC support for CD and WP pin differences.
* Fix broken CPU voltage setting - comment said 1.1V but the code set to
  1.2V. It should never have been set to 1.2V even on i.MX51 TO2 and
  all available Linux kernels would drop the voltage to 1.1V anyway and
  work reliably. This should lower power consumption during the boot
  process.
* Function renames for readability.
* Some board identification string changes to match actual product names.
* Passes checkpatch (v2)

Signed-off-by: Matt Sealey m...@genesi-usa.com
Cc: Stefano Babic sba...@denx.de
---
 board/genesi/mx51_efikamx/efikamx.c |  604 +--
 1 file changed, 229 insertions(+), 375 deletions(-)

diff --git a/board/genesi/mx51_efikamx/efikamx.c 
b/board/genesi/mx51_efikamx/efikamx.c
index 12371c9..18ab8d9 100644
--- a/board/genesi/mx51_efikamx/efikamx.c
+++ b/board/genesi/mx51_efikamx/efikamx.c
@@ -1,7 +1,7 @@
 /*
+ * Copyright (C) 2009 Freescale Semiconductor, Inc.
  * Copyright (C) 2010 Marek Vasut marek.va...@gmail.com
- *
- * (C) Copyright 2009 Freescale Semiconductor, Inc.
+ * Copyright (C) 2009-2012 Genesi USA, Inc.
  *
  * See file CREDITS for list of people who contributed to this
  * project.
@@ -24,9 +24,7 @@
 
 #include common.h
 #include asm/io.h
-#include asm/arch/imx-regs.h
-#include asm/arch/mx5x_pins.h
-#include asm/arch/iomux.h
+#include asm/arch/iomux-mx51.h
 #include asm/gpio.h
 #include asm/errno.h
 #include asm/arch/sys_proto.h
@@ -48,16 +46,12 @@ DECLARE_GLOBAL_DATA_PTR;
 #endif
 
 /*
- * Shared variables / local defines
+ * Board revisions
+ *
+ * Note that we get these revisions here for convenience, but we only set
+ * up for the production model Smarttop (1.3) and Smartbook (2.0).
+ *
  */
-/* LED */
-#defineEFIKAMX_LED_BLUE0x1
-#defineEFIKAMX_LED_GREEN   0x2
-#defineEFIKAMX_LED_RED 0x4
-
-void efikamx_toggle_led(uint32_t mask);
-
-/* Board revisions */
 #defineEFIKAMX_BOARD_REV_110x1
 #defineEFIKAMX_BOARD_REV_120x2
 #defineEFIKAMX_BOARD_REV_130x3
@@ -69,66 +63,67 @@ void efikamx_toggle_led(uint32_t mask);
 /*
  * Board identification
  */
-u32 get_efikamx_rev(void)
+static u32 get_mx_rev(void)
 {
u32 rev = 0;
/*
 * Retrieve board ID:
-*  rev1.1: 1,1,1
-*  rev1.2: 1,1,0
-*  rev1.3: 1,0,1
-*  rev1.4: 1,0,0
+*
+*  gpio: 16 17 11
+*  ==
+*  r1.1:  1+ 1  1
+*  r1.2:  1  1  0
+*  r1.3:  1  0  1
+*  r1.4:  1  0  0
+*
+* + note: r1.1 does not strap this pin properly so it needs to
+* be hacked or ignored.
 */
-   mxc_request_iomux(MX51_PIN_NANDF_CS0, IOMUX_CONFIG_GPIO);
-   /* set to 1 in order to get correct value on board rev1.1 */
-   gpio_direction_output(IOMUX_TO_GPIO(MX51_PIN_NANDF_CS0), 1);
 
-   mxc_request_iomux(MX51_PIN_NANDF_CS0, IOMUX_CONFIG_GPIO);
-   mxc_iomux_set_pad(MX51_PIN_NANDF_CS0, PAD_CTL_100K_PU);
-   gpio_direction_input(IOMUX_TO_GPIO(MX51_PIN_NANDF_CS0));
-   rev |= (!!gpio_get_value(IOMUX_TO_GPIO(MX51_PIN_NANDF_CS0)))  0;
+   /* set to 1 in order to get correct value on board rev 1.1 */
+   gpio_direction_output(GPIO_NUMBER(3, 16), 1);
+   gpio_direction_input(GPIO_NUMBER(3, 11));
+   gpio_direction_input(GPIO_NUMBER(3, 16));
+   gpio_direction_input(GPIO_NUMBER(3, 17));
 
-   mxc_request_iomux(MX51_PIN_NANDF_CS1, IOMUX_CONFIG_GPIO);
-   mxc_iomux_set_pad(MX51_PIN_NANDF_CS1, PAD_CTL_100K_PU);
-   gpio_direction_input(IOMUX_TO_GPIO(MX51_PIN_NANDF_CS1));
-   rev |= (!!gpio_get_value(IOMUX_TO_GPIO(MX51_PIN_NANDF_CS1)))  1;
-
-   mxc_request_iomux(MX51_PIN_NANDF_RB3, IOMUX_CONFIG_GPIO);
-   mxc_iomux_set_pad(MX51_PIN_NANDF_RB3, PAD_CTL_100K_PU);
-   gpio_direction_input(IOMUX_TO_GPIO(MX51_PIN_NANDF_RB3));
-   rev |= (!!gpio_get_value(IOMUX_TO_GPIO(MX51_PIN_NANDF_RB3)))  2;
+   rev |= (!!gpio_get_value(GPIO_NUMBER(3, 16)))  0;
+   rev |= (!!gpio_get_value(GPIO_NUMBER(3, 17)))  1;
+   rev |= (!!gpio_get_value(GPIO_NUMBER(3, 11)))  2;
 
return (~rev  0x7) + 1;
 }
 
-inline u32 get_efikasb_rev(void)
+static iomux_v3_cfg_t efikasb_revision_pads[] = {
+   MX51_PAD_EIM_CS3__GPIO2_28,
+   MX51_PAD_EIM_CS4__GPIO2_29,
+};
+
+static inline u32 get_sb_rev(void)
 {
u32 rev = 0;
 
-   mxc_request_iomux(MX51_PIN_EIM_CS3, IOMUX_CONFIG_GPIO);
-   mxc_iomux_set_pad(MX51_PIN_EIM_CS3, PAD_CTL_100K_PU);
-   gpio_direction_input(IOMUX_TO_GPIO(MX51_PIN_EIM_CS3));
-   rev

Re: [U-Boot] [PATCH] efikamx: sync Smartbook DDR settings in DCD with those found in Genesi's production U-Boot

[Matt Sealey]

Oops. I picked the wrong commit id out of my local tree and there's a subtle 
mistake here.. It won't break anything but its not the one I wanted to submit. 
I'll respond this one..

-- 
Matt Sealey m...@genesi-usa.com
Product Development Analyst, Genesi USA, Inc.

On Aug 23, 2012, at 3:27 PM, Matt Sealey m...@genesi-usa.com wrote:

 We have no idea where the DCD was derived from for Smartbook support, but they
 differ from the Smarttop settings, MX51EVK settings and certainly don't
 correspond to any shipped or development version of U-Boot that Genesi has 
 ever
 had on any Smartbook.
 
 So, copy the calibrated, verified settings from the U-Boot as shipped with 
 every
 Smartbook since retail production. Remove those few settings that just set the
 POR defaults which have already been confirmed for the previous Smarttop DCD
 change.
 
 One of the lines is specific to i.MX51 TO3 designs and therefore TO2 
 Smartbooks
 will possibly not work so reliably with this new DCD; that said, TO2 
 Smartbooks
 basically don't exist at retail and the number of units in the world is less
 than 5 (3 of which are at the Genesi office or owned by Genesi employees).
 
 Many hours of memory testing confirms the new settings are stable.
 
 Signed-off-by: Matt Sealey m...@genesi-usa.com
 Cc: Stefano Babic sba...@denx.de
 Cc: Marek Vasut ma...@denx.de
 ---
 board/genesi/mx51_efikamx/imximage_sb.cfg |   46 +
 1 file changed, 20 insertions(+), 26 deletions(-)
 
 diff --git a/board/genesi/mx51_efikamx/imximage_sb.cfg 
 b/board/genesi/mx51_efikamx/imximage_sb.cfg
 index 878146f..57ccad0 100644
 --- a/board/genesi/mx51_efikamx/imximage_sb.cfg
 +++ b/board/genesi/mx51_efikamx/imximage_sb.cfg
 @@ -1,5 +1,7 @@
 #
 +# Copyright (C) 2009 Pegatron Corporation
 # Copyright (C) 2010 Marek Vasut marek.va...@gmail.com
 +# Copyright (C) 2009-2012 Genesi USA, Inc.
 #
 # BASED ON: imx51evk
 #
 @@ -43,30 +45,22 @@ BOOT_FROMspi
 #Address  absolute address of the register
 #value  value to be stored in the register
 
 -# Setting IOMUXC
 -DATA 4 0x73fa88a0 0x200
 -DATA 4 0x73fa850c 0x20c3
 -DATA 4 0x73fa8510 0x20c3
 -DATA 4 0x73fa883c 0x2
 -DATA 4 0x73fa8848 0x2
 -DATA 4 0x73fa84b8 0xe7
 -DATA 4 0x73fa84bc 0x45
 -DATA 4 0x73fa84c0 0x45
 -DATA 4 0x73fa84c4 0x45
 -DATA 4 0x73fa84c8 0x45
 -DATA 4 0x73fa8820 0x0
 -DATA 4 0x73fa84a4 0x5
 -DATA 4 0x73fa84a8 0x5
 -DATA 4 0x73fa84ac 0xe3
 -DATA 4 0x73fa84b0 0xe3
 -DATA 4 0x73fa84b4 0xe3
 -DATA 4 0x73fa84cc 0xe3
 -DATA 4 0x73fa84d0 0xe2
 -
 -DATA 4 0x73fa882c 0x4
 -DATA 4 0x73fa88a4 0x4
 -DATA 4 0x73fa88ac 0x4
 -DATA 4 0x73fa88b8 0x4
 +# DDR bus IOMUX PAD settings
 +DATA 4 0x73fa88a0 0x200# GRP_INMODE1
 +DATA 4 0x73fa850c 0x20c5# SDODT1
 +DATA 4 0x73fa8510 0x20c5# SDODT0
 +DATA 4 0x73fa8848 0x4# DDR_A1
 +DATA 4 0x73fa84b8 0xe7# DRAM_SDCLK
 +DATA 4 0x73fa84bc 0x45# DRAM_SDQS0
 +DATA 4 0x73fa84c0 0x45# DRAM_SDQS1
 +DATA 4 0x73fa84c4 0x45# DRAM_SDQS2
 +DATA 4 0x73fa84c8 0x45# DRAM_SDQS3
 +DATA 4 0x73fa8820 0x0# DDRPKS
 +DATA 4 0x73fa84ac 0xe5# SDWE
 +DATA 4 0x73fa84b0 0xe5# SDCKE0
 +DATA 4 0x73fa84b4 0xe5# SDCKE1
 +DATA 4 0x73fa84cc 0xe5# DRAM_CS0
 +DATA 4 0x73fa84d0 0xe4# DRAM_CS1
 
 # Setting DDR for micron
 # 13 Rows, 10 Cols, 32 bit, SREF=4 Micron Model
 @@ -108,7 +102,7 @@ DATA 4 0x83fd9014 0x8014
 DATA 4 0x83fd9014 0x8014
 DATA 4 0x83fd9014 0x0632801c
 DATA 4 0x83fd9014 0x0380801d
 -DATA 4 0x83fd9014 0x0040801d
 +DATA 4 0x83fd9014 0x0042801d
 DATA 4 0x83fd9014 0x8004
 
 # Write to CTL0
 @@ -116,7 +110,7 @@ DATA 4 0x83fd9000 0xb2a2
 # Write to CTL1
 DATA 4 0x83fd9008 0xb2a2
 # ESDMISC
 -DATA 4 0x83fd9010 0xcaaaf6d0
 +DATA 4 0x83fd9010 0x000ad6d0
 #ESDCTL_ESDCDLYGD
 DATA 4 0x83fd9034 0x9000
 DATA 4 0x83fd9014 0x
 -- 
 1.7.9.5
 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2] efikamx: sync Smartbook DDR settings in DCD with those found in Genesi's production U-Boot

[Matt Sealey]

We have no idea where the DCD was derived from for Smartbook support, but they
differ from the Smarttop settings, MX51EVK settings and certainly don't
correspond to any shipped or development version of U-Boot that Genesi has ever
had on any Smartbook.

So, copy the calibrated, verified settings from the U-Boot as shipped with every
Smartbook since retail production. Remove those few settings that just set the
POR defaults which have already been confirmed for the previous Smarttop DCD
change.

One of the lines is specific to i.MX51 TO3 designs and therefore TO2 Smartbooks
will possibly not work so reliably with this new DCD; that said, TO2 Smartbooks
basically don't exist at retail and the number of units in the world is less
than 5 (3 of which are at the Genesi office or owned by Genesi employees).

Many hours of memory testing confirms the new settings are stable.

Patch v2:
 * picked the correct commit from our development tree, correcting tuned DDR 
ODF setting
   (which was correct anyway)

Signed-off-by: Matt Sealey m...@genesi-usa.com
Cc: Stefano Babic sba...@denx.de
Cc: Marek Vasut ma...@denx.de
---
 board/genesi/mx51_efikamx/imximage_sb.cfg |   44 +
 1 file changed, 19 insertions(+), 25 deletions(-)

diff --git a/board/genesi/mx51_efikamx/imximage_sb.cfg 
b/board/genesi/mx51_efikamx/imximage_sb.cfg
index 878146f..26d259f 100644
--- a/board/genesi/mx51_efikamx/imximage_sb.cfg
+++ b/board/genesi/mx51_efikamx/imximage_sb.cfg
@@ -1,5 +1,7 @@
 #
+# Copyright (C) 2009 Pegatron Corporation
 # Copyright (C) 2010 Marek Vasut marek.va...@gmail.com
+# Copyright (C) 2009-2012 Genesi USA, Inc.
 #
 # BASED ON: imx51evk
 #
@@ -43,30 +45,22 @@ BOOT_FROM   spi
 #  Address   absolute address of the register
 #  value value to be stored in the register
 
-# Setting IOMUXC
-DATA 4 0x73fa88a0 0x200
-DATA 4 0x73fa850c 0x20c3
-DATA 4 0x73fa8510 0x20c3
-DATA 4 0x73fa883c 0x2
-DATA 4 0x73fa8848 0x2
-DATA 4 0x73fa84b8 0xe7
-DATA 4 0x73fa84bc 0x45
-DATA 4 0x73fa84c0 0x45
-DATA 4 0x73fa84c4 0x45
-DATA 4 0x73fa84c8 0x45
-DATA 4 0x73fa8820 0x0
-DATA 4 0x73fa84a4 0x5
-DATA 4 0x73fa84a8 0x5
-DATA 4 0x73fa84ac 0xe3
-DATA 4 0x73fa84b0 0xe3
-DATA 4 0x73fa84b4 0xe3
-DATA 4 0x73fa84cc 0xe3
-DATA 4 0x73fa84d0 0xe2
-
-DATA 4 0x73fa882c 0x4
-DATA 4 0x73fa88a4 0x4
-DATA 4 0x73fa88ac 0x4
-DATA 4 0x73fa88b8 0x4
+# DDR bus IOMUX PAD settings
+DATA 4 0x73fa88a0 0x200# GRP_INMODE1
+DATA 4 0x73fa850c 0x20c5   # SDODT1
+DATA 4 0x73fa8510 0x20c5   # SDODT0
+DATA 4 0x73fa8848 0x4  # DDR_A1
+DATA 4 0x73fa84b8 0xe7 # DRAM_SDCLK
+DATA 4 0x73fa84bc 0x45 # DRAM_SDQS0
+DATA 4 0x73fa84c0 0x45 # DRAM_SDQS1
+DATA 4 0x73fa84c4 0x45 # DRAM_SDQS2
+DATA 4 0x73fa84c8 0x45 # DRAM_SDQS3
+DATA 4 0x73fa8820 0x0  # DDRPKS
+DATA 4 0x73fa84ac 0xe5 # SDWE
+DATA 4 0x73fa84b0 0xe5 # SDCKE0
+DATA 4 0x73fa84b4 0xe5 # SDCKE1
+DATA 4 0x73fa84cc 0xe5 # DRAM_CS0
+DATA 4 0x73fa84d0 0xe4 # DRAM_CS1
 
 # Setting DDR for micron
 # 13 Rows, 10 Cols, 32 bit, SREF=4 Micron Model
@@ -108,7 +102,7 @@ DATA 4 0x83fd9014 0x8014
 DATA 4 0x83fd9014 0x8014
 DATA 4 0x83fd9014 0x0632801c
 DATA 4 0x83fd9014 0x0380801d
-DATA 4 0x83fd9014 0x0040801d
+DATA 4 0x83fd9014 0x0042801d
 DATA 4 0x83fd9014 0x8004
 
 # Write to CTL0
-- 
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] efikamx: sync Smartbook DDR settings in DCD with those found in Genesi's production U-Boot

[Matt Sealey]

Done. Sorry for the inconvenience.

-- 
Matt Sealey m...@genesi-usa.com
Product Development Analyst, Genesi USA, Inc.


On Fri, Aug 24, 2012 at 8:32 AM, Stefano Babic sba...@denx.de wrote:
 On 24/08/2012 15:16, Matt Sealey wrote:

 Oops. I picked the wrong commit id out of my local tree and there's a
 subtle mistake here.. It won't break anything but its not the one I
 wanted to submit. I'll respond this one..



 Do not worry - I mark this pacth as read to be merged in my queue, but
 it is not yet merged. I discharge it, send to the ML the right one.

 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] efikamx: sync Smartbook DDR settings in DCD with those found in Genesi's production U-Boot

[Matt Sealey]

On Fri, Aug 24, 2012 at 12:08 PM, Marek Vasut marek.va...@gmail.com wrote:
 Dear Matt Sealey,

 Done. Sorry for the inconvenience.

 Please stop posting.
 Please submit the patch in reply to the original one.
 Please read http://www.denx.de/wiki/U-Boot/Patches

I read it, I am still getting used to this abominable system.

We can't all be the epitome of perfection as you obviously are.

-- 
Matt Sealey m...@genesi-usa.com
Product Development Analyst, Genesi USA, Inc.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] Add U_BOOT_TIMESTAMP definition

[Matt Sealey]

This gives us a string like 20120822150855 which encodes the build time.

This allows automated version checking and flashing of U-Boot to be performed,
for example, in boot.scr files (or scripting in general).

Signed-off-by: Matt Sealey m...@genesi-usa.com
Cc: Stefano Babic sba...@denx.de
Cc: Marek Vasut ma...@denx.de
---
 Makefile |1 +
 1 file changed, 1 insertion(+)

diff --git a/Makefile b/Makefile
index 1df4c1d..c042206 100644
--- a/Makefile
+++ b/Makefile
@@ -664,6 +664,7 @@ $(TIMESTAMP_FILE):
@mkdir -p $(dir $(TIMESTAMP_FILE))
@LC_ALL=C date +'#define U_BOOT_DATE %b %d %C%y'  $@.tmp
@LC_ALL=C date +'#define U_BOOT_TIME %T'  $@.tmp
+   @LC_ALL=C date +'#define U_BOOT_TIMESTAMP %Y%m%d%H%M%S'  
$@.tmp
@cmp -s $@ $@.tmp  rm -f $@.tmp || mv -f $@.tmp $@
 
 easylogo env gdb:
-- 
1.7.9.5

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

[U-Boot] [PATCH 1/2] efikamx: refine USB support

[Matt Sealey]

Because of the way USB pad settings are handled it doesn't make sense to
be able to build the Efika MX board support without CONFIG_CMD_USB turned
on. So, we change the build to always compile in USB support.

We do not need to check for CONFIG_CMD_USB like we do with CONFIG_MXC_SPI
since the USB subsystem will error out of the compile for us.

Additionally, the following behaviors have changed;

* Smartbook preboot should not set input and output to USB keyboard as
  there is no display support
* board_eth_init is implemented such that it does not cause U-Boot to
  report an explicit failure (CPU Net Initialization Failed).

Since Ethernet is implemented via USB (fixed on Smarttop, pluggable on
Smartbook, and handled by usb start) - the warning that is left
(No ethernet found) is perfectly reasonable at the point it is printed
since the USB system hasn't been started and nothing has been probed yet.

Signed-off-by: Matt Sealey m...@genesi-usa.com
Cc: Stefano Babic sba...@denx.de
Cc: Marek Vasut ma...@denx.de
---
 board/genesi/mx51_efikamx/Makefile  |6 +-
 board/genesi/mx51_efikamx/efikamx-usb.c |   12 
 board/genesi/mx51_efikamx/efikamx.c |3 ---
 3 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/board/genesi/mx51_efikamx/Makefile 
b/board/genesi/mx51_efikamx/Makefile
index bd2174f..f95356f 100644
--- a/board/genesi/mx51_efikamx/Makefile
+++ b/board/genesi/mx51_efikamx/Makefile
@@ -27,11 +27,7 @@ include $(TOPDIR)/config.mk
 
 LIB= $(obj)lib$(BOARD).o
 
-COBJS  := efikamx.o
-
-ifdef  CONFIG_CMD_USB
-COBJS  += efikamx-usb.o
-endif
+COBJS  := efikamx.o efikamx-usb.o
 
 SRCS   := $(COBJS:.o=.c)
 OBJS   := $(addprefix $(obj),$(COBJS))
diff --git a/board/genesi/mx51_efikamx/efikamx-usb.c 
b/board/genesi/mx51_efikamx/efikamx-usb.c
index abd358a..ae6d1be 100644
--- a/board/genesi/mx51_efikamx/efikamx-usb.c
+++ b/board/genesi/mx51_efikamx/efikamx-usb.c
@@ -201,3 +201,15 @@ void board_ehci_hcd_postinit(struct usb_ehci *ehci, int 
port)
   IMX_GPIO_NR(2, 20));
}
 }
+
+/*
+ * Ethernet on the Smarttop is on the USB bus. Rather than give an error about
+ * CPU Net Initialization Failed, just pass this test since no other settings
+ * are required. Smartbook doesn't have built-in Ethernet but we will let it
+ * pass anyway considering someone may have plugged in a USB stick and all
+ * they need to do is run usb start.
+ */
+int board_eth_init(bd_t *bis)
+{
+   return 0;
+}
diff --git a/board/genesi/mx51_efikamx/efikamx.c 
b/board/genesi/mx51_efikamx/efikamx.c
index b9064fb..d9c499d 100644
--- a/board/genesi/mx51_efikamx/efikamx.c
+++ b/board/genesi/mx51_efikamx/efikamx.c
@@ -484,9 +484,6 @@ int board_late_init(void)
imx_iomux_v3_setup_multiple_pads(efikamx_pata_pads, 
ARRAY_SIZE(efikamx_pata_pads));
efikamx_usb_setup_pads();
 
-   if (machine_is_efikasb())
-   setenv(preboot, usb reset ; setenv stdin usbkbd\0);
-
return 0;
 }
 
-- 
1.7.9.5

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

[U-Boot] [PATCH 2/2] efikamx: update and clean up configuration

[Matt Sealey]

Rewrite and refine the configuration for the Efika MX to support the
board features effectively.

In summary:

* Reorder configuration so it is more readable
* Bring the configuration up to a production-compatible boot process
  by implementing scanning of bootable partitions on MMC and ATA
  media, and the environment required to support this.
* Refine configuration settings to save space and disable arguably
  unused features like gzip support (not required for booting).
* Add CONFIG_EFI_PARTITION, CONFIG_OF_FDT and CONFIG_CMD_BOOTZ support.
* Refine memtest ranges
* Remove SPI flash environment saving since modifying the environment
  can stop boot, and in any case can be modified or supplemented from
  any supported boot media via the boot.scr script or through the
  serial console each boot.
* USB default to port 0 which is the Smarttop USBDR port (Ethernet)
* Make CONFIG_CMD_NET 'depend' on CONFIG_CMD_USB (CONFIG_CMD_USB is not
  currently optional, though, but it makes more sense this way)
* Remove CONFIG_PREBOOT and CONFIG_USB_KEYBOARD

Requires the patch Add U_BOOT_TIMESTAMP definition.

Signed-off-by: Matt Sealey m...@genesi-usa.com
Cc: Marek Vasut ma...@denx.de
Cc: Stefano Babic sba...@denx.de
---
 include/configs/mx51_efikamx.h |  486 
 1 file changed, 291 insertions(+), 195 deletions(-)

diff --git a/include/configs/mx51_efikamx.h b/include/configs/mx51_efikamx.h
index 143b0f0..449f61b 100644
--- a/include/configs/mx51_efikamx.h
+++ b/include/configs/mx51_efikamx.h
@@ -1,9 +1,11 @@
 /*
  * Copyright (C) 2007, Guennadi Liakhovetski l...@denx.de
+ * Copyright (C) 2009 Freescale Semiconductor, Inc.
+ * Copyright (C) 2009 Pegatron Corporation
+ * Copyright (C) 2009-2012, Genesi USA, Inc.
  *
- * (C) Copyright 2009 Freescale Semiconductor, Inc.
- *
- * Configuration settings for the MX51EVK Board
+ * Configuration settings for the Genesi Efika MX Smarttop  Smartbook
+ * based on MX51EVK settings
  *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License as
@@ -25,250 +27,344 @@
 #define __CONFIG_H
 
 #include config_cmd_default.h
+#include timestamp.h
 
 /*
- * High Level Board Configuration Options
+ * U-Boot on the Efika MX is limited in some ways to a 256KiB binary (assuming
+ * we stick with the config in the legacy kernels which gives U-Boot a 256KiB
+ * MTD partition). With a lot of boot device support and full system 
configuration
+ * we manage to break this limit with some toolchains or miscellaneous 
settings,
+ * so we do some damage limitation by making sure the build is as fine-tuned as
+ * possible.
+ *
+ * We don't support compressing scripts, kernels, ramdisks or device trees
+ * because Linux will decompress itself at runtime, ramdisks stay compressed,
+ * scripts and device trees have minimal space saving anyway. Therefore we
+ * don't need zlib, gzip etc.
+ *
+ * We also don't really care about NetBSD or RTEMS, PCMCIA or weirder load
+ * methods right now which saves a little more space.
  */
-/* An i.MX51 CPU */
-#define CONFIG_MX51
+#undef CONFIG_ZLIB
+#undef CONFIG_GZIP
+#undef CONFIG_BOOTM_NETBSD
+#undef CONFIG_BOOTM_RTEMS
+#undef CONFIG_CMD_SETGETDCR
+#undef CONFIG_CMD_PCMCIA
+#undef CONFIG_PCMCIA
+#undef CONFIG_CMD_LOADB
+#undef CONFIG_CMD_LOADS
+#undef CONFIG_CMD_LOADY
+#undef CONFIG_CMD_IMLS
 
-#definemachine_is_efikamx()(CONFIG_MACH_TYPE == 
MACH_TYPE_MX51_EFIKAMX)
-#definemachine_is_efikasb()(CONFIG_MACH_TYPE == 
MACH_TYPE_MX51_EFIKASB)
+/*
+ * We will need to undefine this to save even more space if we break the 256KiB
+ * limit.. but for now we just squeak in and it would be nicer to users if
+ * space was optimized elsewhere first.
+ */
+#define CONFIG_SYS_LONGHELP
 
-#include asm/arch/imx-regs.h
+/*
+ * We want to explicitly enable these in case they're not.
+ */
+#define CONFIG_CMD_DATE
+#define CONFIG_CMD_CACHE
+#define CONFIG_OF_LIBFDT
+#define CONFIG_CMD_BOOTZ
 
+#define CONFIG_MX51
 #define CONFIG_SYS_MX5_HCLK2400
 #define CONFIG_SYS_MX5_CLK32   32768
 #define CONFIG_DISPLAY_CPUINFO
 #define CONFIG_DISPLAY_BOARDINFO
 
-#define CONFIG_SYS_TEXT_BASE   0x9780
+#define machine_is_efikamx()   (CONFIG_MACH_TYPE == MACH_TYPE_MX51_EFIKAMX)
+#define machine_is_efikasb()   (CONFIG_MACH_TYPE == MACH_TYPE_MX51_EFIKASB)
+
+#include asm/arch/imx-regs.h
+#include asm/imx-common/gpio.h
+
+#define CONFIG_CMDLINE_TAG
+#define CONFIG_INITRD_TAG
+#define CONFIG_SETUP_MEMORY_TAGS
+#define CONFIG_REVISION_TAG
+
+#define CONFIG_MXC_GPIO
 
-#defineCONFIG_L2_OFF
-#defineCONFIG_SYS_ICACHE_OFF
-#defineCONFIG_SYS_DCACHE_OFF
+#define CONFIG_MXC_UART
+#define CONFIG_MXC_UART_BASE   UART1_BASE
+#define CONFIG_CONS_INDEX  1
+#define CONFIG_BAUDRATE115200
 
 /*
- * Bootloader Components Configuration
+ * Genesi do not support saving the U-Boot environment at runtime. If you

[U-Boot] [PATCH] efikamx: update MAINTAINERS for Genesi Efika MX systems

[Matt Sealey]

Update maintainer for efikamx and efikasb to myself.

Signed-off-by: Matt Sealey m...@genesi-usa.com
Cc: Stefano Babic sba...@denx.de
Cc: Marek Vasut ma...@denx.de
---
 MAINTAINERS |7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 1abaf2e..77e099d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -877,6 +877,11 @@ Michael Schwingen mich...@schwingen.org
actux4  xscale/ixp
dvlhost xscale/ixp
 
+Matt Sealey m...@genesi-usa.com
+
+   efikamx i.MX51
+   efikasb i.MX51
+
 Bo Shen voice.s...@atmel.com
at91sam9x5ekARM926EJS (AT91SAM9G15,G25,G35,X25,X35 SoC)
 
@@ -906,8 +911,6 @@ Marek Vasut marek.va...@gmail.com
zipitz2 xscale/pxa
m28evk  i.MX28
sc_sps_1i.MX28
-   efikamx i.MX51
-   efikasb i.MX51
 
 Hugo Villeneuve hugo.villene...@lyrtech.com
 
-- 
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] Add U_BOOT_TIMESTAMP definition

[Matt Sealey]

On Thu, Aug 23, 2012 at 9:49 AM, Stefano Babic sba...@denx.de wrote:
 On 23/08/2012 16:44, Matt Sealey wrote:
 This gives us a string like 20120822150855 which encodes the build time.

 This allows automated version checking and flashing of U-Boot to be 
 performed,
 for example, in boot.scr files (or scripting in general).

 Signed-off-by: Matt Sealey m...@genesi-usa.com
 Cc: Stefano Babic sba...@denx.de
 Cc: Marek Vasut ma...@denx.de
 ---

 Hi Matt,

  Makefile |1 +
  1 file changed, 1 insertion(+)

 diff --git a/Makefile b/Makefile
 index 1df4c1d..c042206 100644
 --- a/Makefile
 +++ b/Makefile
 @@ -664,6 +664,7 @@ $(TIMESTAMP_FILE):
   @mkdir -p $(dir $(TIMESTAMP_FILE))
   @LC_ALL=C date +'#define U_BOOT_DATE %b %d %C%y'  $@.tmp
   @LC_ALL=C date +'#define U_BOOT_TIME %T'  $@.tmp
 + @LC_ALL=C date +'#define U_BOOT_TIMESTAMP %Y%m%d%H%M%S'  
 $@.tmp
   @cmp -s $@ $@.tmp  rm -f $@.tmp || mv -f $@.tmp $@


 This is not related to iMX only. I set CC to Wolfgang.

Noted, totally my fault.

-- 
Matt Sealey m...@genesi-usa.com
Product Development Analyst, Genesi USA, Inc.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] efikamx: sync Smartbook DDR settings in DCD with those found in Genesi's production U-Boot

[Matt Sealey]

We have no idea where the DCD was derived from for Smartbook support, but they
differ from the Smarttop settings, MX51EVK settings and certainly don't
correspond to any shipped or development version of U-Boot that Genesi has ever
had on any Smartbook.

So, copy the calibrated, verified settings from the U-Boot as shipped with every
Smartbook since retail production. Remove those few settings that just set the
POR defaults which have already been confirmed for the previous Smarttop DCD
change.

One of the lines is specific to i.MX51 TO3 designs and therefore TO2 Smartbooks
will possibly not work so reliably with this new DCD; that said, TO2 Smartbooks
basically don't exist at retail and the number of units in the world is less
than 5 (3 of which are at the Genesi office or owned by Genesi employees).

Many hours of memory testing confirms the new settings are stable.

Signed-off-by: Matt Sealey m...@genesi-usa.com
Cc: Stefano Babic sba...@denx.de
Cc: Marek Vasut ma...@denx.de
---
 board/genesi/mx51_efikamx/imximage_sb.cfg |   46 +
 1 file changed, 20 insertions(+), 26 deletions(-)

diff --git a/board/genesi/mx51_efikamx/imximage_sb.cfg 
b/board/genesi/mx51_efikamx/imximage_sb.cfg
index 878146f..57ccad0 100644
--- a/board/genesi/mx51_efikamx/imximage_sb.cfg
+++ b/board/genesi/mx51_efikamx/imximage_sb.cfg
@@ -1,5 +1,7 @@
 #
+# Copyright (C) 2009 Pegatron Corporation
 # Copyright (C) 2010 Marek Vasut marek.va...@gmail.com
+# Copyright (C) 2009-2012 Genesi USA, Inc.
 #
 # BASED ON: imx51evk
 #
@@ -43,30 +45,22 @@ BOOT_FROM   spi
 #  Address   absolute address of the register
 #  value value to be stored in the register
 
-# Setting IOMUXC
-DATA 4 0x73fa88a0 0x200
-DATA 4 0x73fa850c 0x20c3
-DATA 4 0x73fa8510 0x20c3
-DATA 4 0x73fa883c 0x2
-DATA 4 0x73fa8848 0x2
-DATA 4 0x73fa84b8 0xe7
-DATA 4 0x73fa84bc 0x45
-DATA 4 0x73fa84c0 0x45
-DATA 4 0x73fa84c4 0x45
-DATA 4 0x73fa84c8 0x45
-DATA 4 0x73fa8820 0x0
-DATA 4 0x73fa84a4 0x5
-DATA 4 0x73fa84a8 0x5
-DATA 4 0x73fa84ac 0xe3
-DATA 4 0x73fa84b0 0xe3
-DATA 4 0x73fa84b4 0xe3
-DATA 4 0x73fa84cc 0xe3
-DATA 4 0x73fa84d0 0xe2
-
-DATA 4 0x73fa882c 0x4
-DATA 4 0x73fa88a4 0x4
-DATA 4 0x73fa88ac 0x4
-DATA 4 0x73fa88b8 0x4
+# DDR bus IOMUX PAD settings
+DATA 4 0x73fa88a0 0x200# GRP_INMODE1
+DATA 4 0x73fa850c 0x20c5   # SDODT1
+DATA 4 0x73fa8510 0x20c5   # SDODT0
+DATA 4 0x73fa8848 0x4  # DDR_A1
+DATA 4 0x73fa84b8 0xe7 # DRAM_SDCLK
+DATA 4 0x73fa84bc 0x45 # DRAM_SDQS0
+DATA 4 0x73fa84c0 0x45 # DRAM_SDQS1
+DATA 4 0x73fa84c4 0x45 # DRAM_SDQS2
+DATA 4 0x73fa84c8 0x45 # DRAM_SDQS3
+DATA 4 0x73fa8820 0x0  # DDRPKS
+DATA 4 0x73fa84ac 0xe5 # SDWE
+DATA 4 0x73fa84b0 0xe5 # SDCKE0
+DATA 4 0x73fa84b4 0xe5 # SDCKE1
+DATA 4 0x73fa84cc 0xe5 # DRAM_CS0
+DATA 4 0x73fa84d0 0xe4 # DRAM_CS1
 
 # Setting DDR for micron
 # 13 Rows, 10 Cols, 32 bit, SREF=4 Micron Model
@@ -108,7 +102,7 @@ DATA 4 0x83fd9014 0x8014
 DATA 4 0x83fd9014 0x8014
 DATA 4 0x83fd9014 0x0632801c
 DATA 4 0x83fd9014 0x0380801d
-DATA 4 0x83fd9014 0x0040801d
+DATA 4 0x83fd9014 0x0042801d
 DATA 4 0x83fd9014 0x8004
 
 # Write to CTL0
@@ -116,7 +110,7 @@ DATA 4 0x83fd9000 0xb2a2
 # Write to CTL1
 DATA 4 0x83fd9008 0xb2a2
 # ESDMISC
-DATA 4 0x83fd9010 0xcaaaf6d0
+DATA 4 0x83fd9010 0x000ad6d0
 #ESDCTL_ESDCDLYGD
 DATA 4 0x83fd9034 0x9000
 DATA 4 0x83fd9014 0x
-- 
1.7.9.5

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

[U-Boot] [PATCH v2] mx5: add iomux-mx51.h include

[Matt Sealey]

Allow usage of the imx-common/iomux-v3.h framework by including pad settings
for the i.MX51. The content of the file is taken from Linux kernel at
commit 5d23b39 plus the required changes to make it work in U-Boot.

The contained pad settings are the minimum required to make an Efika MX boot
and get all the currently-implemented peripherals working in U-Boot.

It is recommended that this file not be just a dumping ground for pins but
only contain the settings required for all the boards using it.

Changes for v2:
 * reference commit id from Linux kernel
 * additionally roll in the USB pads
 * removed GPIO_NUMBER define

Signed-off-by: Matt Sealey m...@genesi-usa.com
---
 arch/arm/include/asm/arch-mx5/iomux-mx51.h |  164 
 1 file changed, 164 insertions(+)
 create mode 100644 arch/arm/include/asm/arch-mx5/iomux-mx51.h

diff --git a/arch/arm/include/asm/arch-mx5/iomux-mx51.h 
b/arch/arm/include/asm/arch-mx5/iomux-mx51.h
new file mode 100644
index 000..4f37295
--- /dev/null
+++ b/arch/arm/include/asm/arch-mx5/iomux-mx51.h
@@ -0,0 +1,164 @@
+/*
+ * Copyright (C) 2009-2010 Amit Kucheria amit.kuche...@canonical.com
+ * Copyright (C) 2010 Freescale Semiconductor, Inc.
+ * Copyright (C) 2009-2012 Genesi USA, Inc.
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/*
+ * The vast majority of this file is taken from the Linux kernel at
+ * commit 5d23b39
+ */
+
+#ifndef __IOMUX_MX51_H__
+#define __IOMUX_MX51_H__
+
+#include asm/imx-common/iomux-v3.h
+
+#define PAD_CTL_DVS(1  13)
+#define PAD_CTL_INPUT_DDR  (1  9)
+#define PAD_CTL_HYS(1  8)
+
+#define PAD_CTL_PKE(1  7)
+#define PAD_CTL_PUE(1  6 | PAD_CTL_PKE)
+#define PAD_CTL_PUS_100K_DOWN  (0  4 | PAD_CTL_PUE)
+#define PAD_CTL_PUS_47K_UP (1  4 | PAD_CTL_PUE)
+#define PAD_CTL_PUS_100K_UP(2  4 | PAD_CTL_PUE)
+#define PAD_CTL_PUS_22K_UP (3  4 | PAD_CTL_PUE)
+
+#define PAD_CTL_ODE(1  3)
+
+#define PAD_CTL_DSE_LOW(0  1)
+#define PAD_CTL_DSE_MED(1  1)
+#define PAD_CTL_DSE_HIGH   (2  1)
+#define PAD_CTL_DSE_MAX(3  1)
+
+#define PAD_CTL_SRE_FAST   (1  0)
+#define PAD_CTL_SRE_SLOW   (0  0)
+
+/* Pad control groupings */
+#define MX51_UART_PAD_CTRL (PAD_CTL_PKE | PAD_CTL_PUE | PAD_CTL_DSE_HIGH | 
\
+   PAD_CTL_HYS | PAD_CTL_SRE_FAST)
+#define MX51_I2C_PAD_CTRL  (PAD_CTL_SRE_FAST | PAD_CTL_ODE | \
+   PAD_CTL_DSE_HIGH | PAD_CTL_PUS_100K_UP | \
+   PAD_CTL_HYS)
+#define MX51_ESDHC_PAD_CTRL(PAD_CTL_SRE_FAST | PAD_CTL_ODE | \
+   PAD_CTL_DSE_HIGH | PAD_CTL_PUS_100K_UP | \
+   PAD_CTL_HYS)
+#define MX51_USBH1_PAD_CTRL(PAD_CTL_PKE | PAD_CTL_SRE_FAST | \
+   PAD_CTL_DSE_HIGH | PAD_CTL_PUS_100K_UP | \
+   PAD_CTL_HYS | PAD_CTL_PUE)
+#define MX51_ECSPI_PAD_CTRL(PAD_CTL_PKE | PAD_CTL_HYS | \
+   PAD_CTL_DSE_HIGH | PAD_CTL_SRE_FAST)
+#define MX51_SDHCI_PAD_CTRL(PAD_CTL_PKE | PAD_CTL_DSE_HIGH | \
+   PAD_CTL_PUS_47K_UP | PAD_CTL_PUE | \
+   PAD_CTL_SRE_FAST | PAD_CTL_DVS)
+#define MX51_GPIO_PAD_CTRL (PAD_CTL_DSE_HIGH | PAD_CTL_PKE | 
PAD_CTL_SRE_FAST)
+
+#define __NA_ 0x000
+
+/*
+ * The naming convention for the pad modes is MX51_PAD_padname__padmode
+ * If padname or padmode refers to a GPIO, it is named GPIOunit_num
+ * See also iomux-v3.h
+ */
+
+/* PADMUX   
ALT INPSE PATH PADCTRL */
+enum {
+   MX51_PAD_EIM_D16__USBH2_DATA0   = IOMUX_PAD(0x3f0, 0x05c, 2, 
__NA_, 0, NO_PAD_CTRL),
+   MX51_PAD_EIM_D17__USBH2_DATA1   = IOMUX_PAD(0x3f4, 0x060, 2, 
__NA_, 0, NO_PAD_CTRL),
+   MX51_PAD_EIM_D18__USBH2_DATA2   = IOMUX_PAD(0x3f8, 0x064, 2, 
__NA_, 0, NO_PAD_CTRL),
+   MX51_PAD_EIM_D19__USBH2_DATA3   = IOMUX_PAD(0x3fc, 0x068, 2, 
__NA_, 0, NO_PAD_CTRL),
+   MX51_PAD_EIM_D20__USBH2_DATA4   = IOMUX_PAD(0x400, 0x06c, 2, 
__NA_, 0, NO_PAD_CTRL),
+   MX51_PAD_EIM_D21__USBH2_DATA5   = IOMUX_PAD(0x404, 0x070, 2, 
__NA_, 0, NO_PAD_CTRL),
+   MX51_PAD_EIM_D22__USBH2_DATA6   = IOMUX_PAD(0x408, 0x074, 2, 
__NA_, 0, NO_PAD_CTRL),
+   MX51_PAD_EIM_D23__USBH2_DATA7   = IOMUX_PAD(0x40c, 0x078, 2, 
__NA_, 0, NO_PAD_CTRL),
+   MX51_PAD_EIM_D27__GPIO2_9   = IOMUX_PAD(0x41c, 0x088, 1, 
__NA_, 0

[U-Boot] [PATCH v2 1/4] efikamx: move and rename Efika MX directories and config files to prepare for new boards

[Matt Sealey]

* Move Efika MX Smarttop and Smartbook boards into a genesi vendor directory
* Rename efikamx - mx51_efikamx since there is an mx53_efikamx and mx6_efikamx 
to come

Signed-off-by: Matt Sealey m...@genesi-usa.com
---
 board/{efikamx = genesi/mx51_efikamx}/Makefile|0
 .../{efikamx = genesi/mx51_efikamx}/efikamx-usb.c |2 +-
 board/{efikamx = genesi/mx51_efikamx}/efikamx.c   |0
 .../mx51_efikamx}/imximage_mx.cfg  |0
 .../mx51_efikamx}/imximage_sb.cfg  |0
 boards.cfg |4 ++--
 include/configs/{efikamx.h = mx51_efikamx.h}  |0
 7 files changed, 3 insertions(+), 3 deletions(-)
 rename board/{efikamx = genesi/mx51_efikamx}/Makefile (100%)
 rename board/{efikamx = genesi/mx51_efikamx}/efikamx-usb.c (99%)
 rename board/{efikamx = genesi/mx51_efikamx}/efikamx.c (100%)
 rename board/{efikamx = genesi/mx51_efikamx}/imximage_mx.cfg (100%)
 rename board/{efikamx = genesi/mx51_efikamx}/imximage_sb.cfg (100%)
 rename include/configs/{efikamx.h = mx51_efikamx.h} (100%)

diff --git a/board/efikamx/Makefile b/board/genesi/mx51_efikamx/Makefile
similarity index 100%
rename from board/efikamx/Makefile
rename to board/genesi/mx51_efikamx/Makefile
diff --git a/board/efikamx/efikamx-usb.c 
b/board/genesi/mx51_efikamx/efikamx-usb.c
similarity index 99%
rename from board/efikamx/efikamx-usb.c
rename to board/genesi/mx51_efikamx/efikamx-usb.c
index 618b39d..e9273d0 100644
--- a/board/efikamx/efikamx-usb.c
+++ b/board/genesi/mx51_efikamx/efikamx-usb.c
@@ -33,7 +33,7 @@
 #include usb/ulpi.h
 #include errno.h
 
-#include ../../drivers/usb/host/ehci.h
+#include ../../../drivers/usb/host/ehci.h
 
 /* USB pin configuration */
 #define USB_PAD_CONFIG (PAD_CTL_PKE_ENABLE | PAD_CTL_SRE_FAST | \
diff --git a/board/efikamx/efikamx.c b/board/genesi/mx51_efikamx/efikamx.c
similarity index 100%
rename from board/efikamx/efikamx.c
rename to board/genesi/mx51_efikamx/efikamx.c
diff --git a/board/efikamx/imximage_mx.cfg 
b/board/genesi/mx51_efikamx/imximage_mx.cfg
similarity index 100%
rename from board/efikamx/imximage_mx.cfg
rename to board/genesi/mx51_efikamx/imximage_mx.cfg
diff --git a/board/efikamx/imximage_sb.cfg 
b/board/genesi/mx51_efikamx/imximage_sb.cfg
similarity index 100%
rename from board/efikamx/imximage_sb.cfg
rename to board/genesi/mx51_efikamx/imximage_sb.cfg
diff --git a/boards.cfg b/boards.cfg
index edd750c..a9ec44b 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -215,8 +215,8 @@ integratorcp_cm946es arm arm946es
integrator  armltd
 ca9x4_ct_vxp arm armv7   vexpressarmltd
 am335x_evm   arm armv7   am335x  ti
 am33xx
 highbank arm armv7   highbank- 
 highbank
-efikamx  arm armv7   efikamx - 
 mx5
efikamx:MACH_TYPE=MACH_TYPE_MX51_EFIKAMX,IMX_CONFIG=board/efikamx/imximage_mx.cfg
-efikasb  arm armv7   efikamx - 
 mx5
efikamx:MACH_TYPE=MACH_TYPE_MX51_EFIKASB,IMX_CONFIG=board/efikamx/imximage_sb.cfg
+mx51_efikamx arm armv7   mx51_efikamx
genesi mx5
mx51_efikamx:MACH_TYPE=MACH_TYPE_MX51_EFIKAMX,IMX_CONFIG=board/genesi/mx51_efikamx/imximage_mx.cfg
+mx51_efikasb arm armv7   mx51_efikamx
genesi mx5
mx51_efikamx:MACH_TYPE=MACH_TYPE_MX51_EFIKASB,IMX_CONFIG=board/genesi/mx51_efikamx/imximage_sb.cfg
 mx51evk  arm armv7   mx51evk 
freescale  mx5
mx51evk:IMX_CONFIG=board/freescale/mx51evk/imximage.cfg
 mx53ard  arm armv7   mx53ard 
freescale  mx5
mx53ard:IMX_CONFIG=board/freescale/mx53ard/imximage_dd3.cfg
 mx53evk  arm armv7   mx53evk 
freescale  mx5
mx53evk:IMX_CONFIG=board/freescale/mx53evk/imximage.cfg
diff --git a/include/configs/efikamx.h b/include/configs/mx51_efikamx.h
similarity index 100%
rename from include/configs/efikamx.h
rename to include/configs/mx51_efikamx.h
-- 
1.7.9.5

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

[U-Boot] [PATCH 2/4] efikamx: remove drive strength function and roll its functionality into the DCD

[Matt Sealey]

Efika MX boards configure their DDR pad settings twice, one in the DCD generated
from imximage_*.cfg and again in init_drive_strength called before relocation.

Rather than doing this, roll the changes it makes into the DCD so DDR is set up
before a single line of code in U-Boot is run.

The settings are identical with this DCD block which is shorter (by 7 entries)
than the old one, and after the output of init_drive_strength since a lot of the
functionality in the existing DCD and init_drive_strength function was just
setting the POR defaults. This goes to explain some now-missing entries.

Several hundred rounds of mtest have been run to test the settings before and
after to confirm DDR is stable and no ill-effects have been found.

Signed-off-by: Matt Sealey m...@genesi-usa.com
---
 board/genesi/mx51_efikamx/efikamx.c   |   77 -
 board/genesi/mx51_efikamx/imximage_mx.cfg |   42 +++-
 2 files changed, 18 insertions(+), 101 deletions(-)

diff --git a/board/genesi/mx51_efikamx/efikamx.c 
b/board/genesi/mx51_efikamx/efikamx.c
index e88b2ed..12371c9 100644
--- a/board/genesi/mx51_efikamx/efikamx.c
+++ b/board/genesi/mx51_efikamx/efikamx.c
@@ -597,85 +597,8 @@ void efikamx_toggle_led(uint32_t mask)
 /*
  * Board initialization
  */
-static void init_drive_strength(void)
-{
-   mxc_iomux_set_pad(MX51_PIN_CTL_GRP_PKEDDR, PAD_CTL_DDR_INPUT_CMOS);
-   mxc_iomux_set_pad(MX51_PIN_CTL_GRP_PKEADDR, PAD_CTL_PKE_ENABLE);
-   mxc_iomux_set_pad(MX51_PIN_CTL_GRP_DDRAPKS, PAD_CTL_PUE_KEEPER);
-   mxc_iomux_set_pad(MX51_PIN_CTL_GRP_DDRAPUS, PAD_CTL_100K_PU);
-   mxc_iomux_set_pad(MX51_PIN_CTL_GRP_DDR_SR_A1, PAD_CTL_SRE_FAST);
-   mxc_iomux_set_pad(MX51_PIN_CTL_GRP_DDR_A0, PAD_CTL_DRV_HIGH);
-   mxc_iomux_set_pad(MX51_PIN_CTL_GRP_DDR_A1, PAD_CTL_DRV_HIGH);
-   mxc_iomux_set_pad(MX51_PIN_CTL_DRAM_RAS,
-   PAD_CTL_DRV_HIGH | PAD_CTL_SRE_FAST);
-   mxc_iomux_set_pad(MX51_PIN_CTL_DRAM_CAS,
-   PAD_CTL_DRV_HIGH | PAD_CTL_SRE_FAST);
-   mxc_iomux_set_pad(MX51_PIN_CTL_GRP_PKEDDR, PAD_CTL_PKE_ENABLE);
-   mxc_iomux_set_pad(MX51_PIN_CTL_GRP_DDRPKS, PAD_CTL_PUE_KEEPER);
-   mxc_iomux_set_pad(MX51_PIN_CTL_GRP_HYSDDR0, PAD_CTL_HYS_NONE);
-   mxc_iomux_set_pad(MX51_PIN_CTL_GRP_HYSDDR1, PAD_CTL_HYS_NONE);
-   mxc_iomux_set_pad(MX51_PIN_CTL_GRP_HYSDDR2, PAD_CTL_HYS_NONE);
-   mxc_iomux_set_pad(MX51_PIN_CTL_GRP_HYSDDR3, PAD_CTL_HYS_NONE);
-   mxc_iomux_set_pad(MX51_PIN_CTL_GRP_DDR_SR_B0, PAD_CTL_SRE_FAST);
-   mxc_iomux_set_pad(MX51_PIN_CTL_GRP_DDR_SR_B1, PAD_CTL_SRE_FAST);
-   mxc_iomux_set_pad(MX51_PIN_CTL_GRP_DDR_SR_B2, PAD_CTL_SRE_FAST);
-   mxc_iomux_set_pad(MX51_PIN_CTL_GRP_DDR_SR_B4, PAD_CTL_SRE_FAST);
-   mxc_iomux_set_pad(MX51_PIN_CTL_GRP_DDRPUS, PAD_CTL_100K_PU);
-   mxc_iomux_set_pad(MX51_PIN_CTL_GRP_INMODE1, PAD_CTL_DDR_INPUT_CMOS);
-   mxc_iomux_set_pad(MX51_PIN_CTL_GRP_DRAM_B0, PAD_CTL_DRV_MEDIUM);
-   mxc_iomux_set_pad(MX51_PIN_CTL_GRP_DRAM_B1, PAD_CTL_DRV_MEDIUM);
-   mxc_iomux_set_pad(MX51_PIN_CTL_GRP_DRAM_B2, PAD_CTL_DRV_MEDIUM);
-   mxc_iomux_set_pad(MX51_PIN_CTL_GRP_DRAM_B4, PAD_CTL_DRV_MEDIUM);
-
-   /* Setting pad options */
-   mxc_iomux_set_pad(MX51_PIN_CTL_DRAM_SDWE,
-   PAD_CTL_PKE_ENABLE | PAD_CTL_PUE_KEEPER |
-   PAD_CTL_DRV_HIGH | PAD_CTL_SRE_FAST);
-   mxc_iomux_set_pad(MX51_PIN_CTL_DRAM_SDCKE0,
-   PAD_CTL_PKE_ENABLE | PAD_CTL_PUE_KEEPER |
-   PAD_CTL_DRV_HIGH | PAD_CTL_SRE_FAST);
-   mxc_iomux_set_pad(MX51_PIN_CTL_DRAM_SDCKE1,
-   PAD_CTL_PKE_ENABLE | PAD_CTL_PUE_KEEPER |
-   PAD_CTL_DRV_HIGH | PAD_CTL_SRE_FAST);
-   mxc_iomux_set_pad(MX51_PIN_CTL_DRAM_SDCLK,
-   PAD_CTL_PKE_ENABLE | PAD_CTL_PUE_KEEPER |
-   PAD_CTL_DRV_HIGH | PAD_CTL_SRE_FAST);
-   mxc_iomux_set_pad(MX51_PIN_CTL_DRAM_SDQS0,
-   PAD_CTL_PKE_ENABLE | PAD_CTL_PUE_KEEPER |
-   PAD_CTL_DRV_HIGH | PAD_CTL_SRE_FAST);
-   mxc_iomux_set_pad(MX51_PIN_CTL_DRAM_SDQS1,
-   PAD_CTL_PKE_ENABLE | PAD_CTL_PUE_KEEPER |
-   PAD_CTL_DRV_HIGH | PAD_CTL_SRE_FAST);
-   mxc_iomux_set_pad(MX51_PIN_CTL_DRAM_SDQS2,
-   PAD_CTL_PKE_ENABLE | PAD_CTL_PUE_KEEPER |
-   PAD_CTL_DRV_HIGH | PAD_CTL_SRE_FAST);
-   mxc_iomux_set_pad(MX51_PIN_CTL_DRAM_SDQS3,
-   PAD_CTL_PKE_ENABLE | PAD_CTL_PUE_KEEPER |
-   PAD_CTL_DRV_HIGH | PAD_CTL_SRE_FAST);
-   mxc_iomux_set_pad(MX51_PIN_CTL_DRAM_CS0,
-   PAD_CTL_PKE_ENABLE | PAD_CTL_PUE_KEEPER |
-   PAD_CTL_DRV_HIGH | PAD_CTL_SRE_FAST);
-   mxc_iomux_set_pad(MX51_PIN_CTL_DRAM_CS1,
-   PAD_CTL_PKE_ENABLE | PAD_CTL_PUE_KEEPER |
-   PAD_CTL_DRV_HIGH | PAD_CTL_SRE_FAST);
-   mxc_iomux_set_pad(MX51_PIN_CTL_DRAM_DQM0,
-   PAD_CTL_PKE_ENABLE | PAD_CTL_PUE_KEEPER

[U-Boot] [PATCH 3/4] efikamx: configure Smarttop PCBID and LED pads in DCD for convenience

[Matt Sealey]

PCBID pads seem to need time to settle due to external pulldowns, otherwise
we are reading floating GPIO pins with implicit pad pullups and get the wrong
data. However we can't wait at the time we need them before relocation,
since timers are not available. The time taken to get from DCD to the code
requiring the pads set seems to be more than long enough (even with caches
enabled).

We have space in the DCD due to the DDR settings changes to configure all
the pad settings we need for this, plus the LED pad settings too which
reduces the amount of code required later on.

Signed-off-by: Matt Sealey m...@genesi-usa.com
---
 board/genesi/mx51_efikamx/imximage_mx.cfg |   10 ++
 1 file changed, 10 insertions(+)

diff --git a/board/genesi/mx51_efikamx/imximage_mx.cfg 
b/board/genesi/mx51_efikamx/imximage_mx.cfg
index ea6b271..38fa760 100644
--- a/board/genesi/mx51_efikamx/imximage_mx.cfg
+++ b/board/genesi/mx51_efikamx/imximage_mx.cfg
@@ -45,6 +45,16 @@ BOOT_FROMspi
 #  Address   absolute address of the register
 #  value value to be stored in the register
 
+# Essential GPIO settings to be done as early as possible
+# PCBIDn pad settings are all the defaults except #2 which needs HVE off
+DATA 4 0x73fa8134 0x3  # PCBID0 ALT3 GPIO 3_16
+DATA 4 0x73fa8130 0x3  # PCBID1 ALT3 GPIO 3_17
+DATA 4 0x73fa8128 0x3  # PCBID2 ALT3 GPIO 3_11
+DATA 4 0x73fa8504 0xe4 # PCBID2 PAD ~HVE
+DATA 4 0x73fa8198 0x3  # LED0 ALT3 GPIO 3_13
+DATA 4 0x73fa81c4 0x3  # LED1 ALT3 GPIO 3_14
+DATA 4 0x73fa81c8 0x3  # LED2 ALT3 GPIO 3_15
+
 # DDR bus IOMUX PAD settings
 DATA 4 0x73fa850c 0x20c5   # SDODT1
 DATA 4 0x73fa8510 0x20c5   # SDODT0
-- 
1.7.9.5

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

[U-Boot] [PATCH 4/4] efikamx: update to Efika MX Smarttop and Smartbook boards

[Matt Sealey]

This is a rework of a previously submitted patchset and bundles the
main board support and USB support into a single commit.

It requires the patch mx5: add iomux-mx51.h include

* Use iomux-mx51.h include to simplify board configuration.
* Simplify LED support (remove efikamx_toggle_led, change lit LEDs).
* Simplify MMC support for CD and WP pin differences.
* Fix broken CPU voltage setting - comment said 1.1V but the code set to
  1.2V. It should never have been set to 1.2V even on i.MX51 TO2 and
  all available Linux kernels would drop the voltage to 1.1V anyway and
  work reliably. This should lower power consumption during the boot
  process.
* Function renames for readability.
* Some board identification string changes to match actual product names.

Signed-off-by: Matt Sealey m...@genesi-usa.com
---
 board/genesi/mx51_efikamx/efikamx-usb.c |  159 
 board/genesi/mx51_efikamx/efikamx.c |  603 ---
 2 files changed, 298 insertions(+), 464 deletions(-)

diff --git a/board/genesi/mx51_efikamx/efikamx-usb.c 
b/board/genesi/mx51_efikamx/efikamx-usb.c
index e9273d0..abd358a 100644
--- a/board/genesi/mx51_efikamx/efikamx-usb.c
+++ b/board/genesi/mx51_efikamx/efikamx-usb.c
@@ -1,7 +1,7 @@
 /*
+ * Copyright (C) 2009 Freescale Semiconductor, Inc.
  * Copyright (C) 2010 Marek Vasut marek.va...@gmail.com
- *
- * (C) Copyright 2009 Freescale Semiconductor, Inc.
+ * Copyright (C) 2009-2012 Genesi USA, Inc.
  *
  * See file CREDITS for list of people who contributed to this
  * project.
@@ -25,9 +25,7 @@
 #include common.h
 #include usb.h
 #include asm/io.h
-#include asm/arch/imx-regs.h
-#include asm/arch/mx5x_pins.h
-#include asm/arch/iomux.h
+#include asm/arch/iomux-mx51.h
 #include asm/gpio.h
 #include usb/ehci-fsl.h
 #include usb/ulpi.h
@@ -35,103 +33,93 @@
 
 #include ../../../drivers/usb/host/ehci.h
 
-/* USB pin configuration */
-#define USB_PAD_CONFIG (PAD_CTL_PKE_ENABLE | PAD_CTL_SRE_FAST | \
-   PAD_CTL_DRV_HIGH | PAD_CTL_100K_PU | \
-   PAD_CTL_HYS_ENABLE | PAD_CTL_PUE_PULL)
-
-/*
- * Configure the USB H1 and USB H2 IOMUX
- */
-void setup_iomux_usb(void)
-{
-   setup_iomux_usb_h1();
-
-   if (machine_is_efikasb())
-   setup_iomux_usb_h2();
-
-   /* USB PHY reset */
-   mxc_request_iomux(MX51_PIN_EIM_D27, IOMUX_CONFIG_ALT1);
-   mxc_iomux_set_pad(MX51_PIN_EIM_D27, PAD_CTL_PKE_ENABLE |
-   PAD_CTL_SRE_FAST | PAD_CTL_DRV_HIGH);
-
-   /* USB HUB reset */
-   mxc_request_iomux(MX51_PIN_GPIO1_5, IOMUX_CONFIG_ALT0);
-   mxc_iomux_set_pad(MX51_PIN_GPIO1_5, PAD_CTL_PKE_ENABLE |
-   PAD_CTL_SRE_FAST | PAD_CTL_DRV_HIGH);
-
-   /* WIFI EN (act low) */
-   mxc_request_iomux(MX51_PIN_EIM_A22, IOMUX_CONFIG_GPIO);
-   mxc_iomux_set_pad(MX51_PIN_EIM_A22, 0);
-   /* WIFI RESET */
-   mxc_request_iomux(MX51_PIN_EIM_A16, IOMUX_CONFIG_GPIO);
-   mxc_iomux_set_pad(MX51_PIN_EIM_A16, 0);
-   /* BT EN (act low) */
-   mxc_request_iomux(MX51_PIN_EIM_A17, IOMUX_CONFIG_GPIO);
-   mxc_iomux_set_pad(MX51_PIN_EIM_A17, 0);
-}
-
-/*
- * Enable devices connected to USB BUSes
- */
-static void efika_usb_enable_devices(void)
+static iomux_v3_cfg_t efikamx_usbh1_pads[] = {
+   MX51_PAD_USBH1_CLK__USBH1_CLK,
+   MX51_PAD_USBH1_DIR__USBH1_DIR,
+   MX51_PAD_USBH1_STP__USBH1_STP,
+   MX51_PAD_USBH1_NXT__USBH1_NXT,
+   MX51_PAD_USBH1_DATA0__USBH1_DATA0,
+   MX51_PAD_USBH1_DATA1__USBH1_DATA1,
+   MX51_PAD_USBH1_DATA2__USBH1_DATA2,
+   MX51_PAD_USBH1_DATA3__USBH1_DATA3,
+   MX51_PAD_USBH1_DATA4__USBH1_DATA4,
+   MX51_PAD_USBH1_DATA5__USBH1_DATA5,
+   MX51_PAD_USBH1_DATA6__USBH1_DATA6,
+   MX51_PAD_USBH1_DATA7__USBH1_DATA7,
+};
+
+static iomux_v3_cfg_t efikasb_usbh2_pads[] = {
+   MX51_PAD_EIM_A24__USBH2_CLK,
+   MX51_PAD_EIM_A25__USBH2_DIR,
+   MX51_PAD_EIM_A26__USBH2_STP,
+   MX51_PAD_EIM_A27__USBH2_NXT,
+   MX51_PAD_EIM_D16__USBH2_DATA0,
+   MX51_PAD_EIM_D17__USBH2_DATA1,
+   MX51_PAD_EIM_D18__USBH2_DATA2,
+   MX51_PAD_EIM_D19__USBH2_DATA3,
+   MX51_PAD_EIM_D20__USBH2_DATA4,
+   MX51_PAD_EIM_D21__USBH2_DATA5,
+   MX51_PAD_EIM_D22__USBH2_DATA6,
+   MX51_PAD_EIM_D23__USBH2_DATA7,
+};
+
+static iomux_v3_cfg_t efikamx_usbctrl_pads[] = {
+   MX51_PAD_EIM_D27__GPIO2_9,
+   MX51_PAD_GPIO1_5__GPIO1_5,
+};
+
+#define EFIKAMX_USB_HUB_RESET  IMX_GPIO_NR(1, 5)
+#define EFIKAMX_USB_PHY_RESET  IMX_GPIO_NR(2, 9)
+
+void efikamx_usb_setup_pads(void)
 {
-   /* Enable Bluetooth */
-   gpio_direction_output(IOMUX_TO_GPIO(MX51_PIN_EIM_A17), 0);
-   udelay(1);
-   gpio_set_value(IOMUX_TO_GPIO(MX51_PIN_EIM_A17), 1);
+   imx_iomux_v3_setup_multiple_pads(efikamx_usbh1_pads, 
ARRAY_SIZE(efikamx_usbh1_pads));
 
-   /* Enable WiFi */
-   gpio_direction_output(IOMUX_TO_GPIO(MX51_PIN_EIM_A22), 1);
-   udelay(1

Re: [U-Boot] [PATCH 3/4] efikamx: update to Efika MX Smarttop and Smartbook boards

[Matt Sealey]

On Sat, Aug 18, 2012 at 5:26 PM, Marek Vasut ma...@denx.de wrote:
 Dear Matt Sealey,

 On Sat, Aug 18, 2012 at 10:50 AM, Stefano Babic sba...@denx.de wrote:
  On 17/08/2012 20:19, Matt Sealey wrote:
 
  Anyway, who will maintain the efikas in future ? Marek, do you hold it,
  or Matt will take this job ?

 I'll do it but I doubt I'm going to be around as much as Marek. What
 I'm a little fearful of is having patches try and hit the Efika stuff
 and me not having much time that day to review, they either stagnate
 or get accepted anyway breaking something.

 So your commercial QA has to arrive at the RC stage and fix it if needed ...
 every around 3-4 months.

That is in fact the plan.

If we can get TO2 support back in at that time, we will do it, but for
now it cannot just go in broken. We cannot test the mux code on these
boards if they don't boot...

 I think you need to understand that FOSS is a cooperative effort. It is not 
 any
 commercial crap which you roll out and throw away when it made enough money. 
 We
 will not stop hacking on mx51 only because it might break your platform, 
 that's
 not how it works.

The problem here is that we don't make any money from MX51 anymore;
there are no Efika MX systems to sell, stock is basically depleted. So
this work is an offshoot of some other code. If, on the other hand,
you want to cooperate and test it on TO2 and report your results and
tell us what is broken, that would be fine, but we can't expend time
and effort fixing something which represents barely a percentage point
of customers; if you don't have a TO2, then you can't help, and you
can't complain if you can't run it let alone test it.

 To put it into more commercial terms, we are not paid to support your
 platform, on the other hand, we already gave you the source code. So to 
 restore
 the balance, you help us keeping it working well by investing in QA. 
 Everyone's
 happy.

 Besides, if you want to deploy less potent version, you can always configure
 your u-boot in such way and deploy it to customer, noone can prevent you from
 that. But since there is support for certain additional hardware in upstream
 already, I'd object to remove it.

That is the way we're doing it, but we can't in good conscience deploy
a non-neutered version with such heavy cleanups that we cannot
guarantee booted in the first place let alone with our changes.
Modifying the IOMUX setup method did not fix booting, but we cannot
tell if it worked properly in the first place. Number of users of TO2
Efika MX boards r1.1 and r1.2 is so low, it's hard to imagine these
people giving a rat's ass about whether mainline works on it or not
(especially since there's no mainline Linux support for these boards
as it stands - even with the old U-Boot we shipped on the boards that
works, the kernel is less than reliable for various reasons).

 See how the mx28 stuff is being developed to see what I mean. Me, Fabio, 
 Otavio
 and many others are adjusting each others boards and it works very well.

I would like to see you justify again updating code that supports a
board that hasn't actually booted mainline U-Boot in several months,
if not years, with a code change that cannot be tested.

Once it's gone through testing and we work out for sure why U-Boot
simply does not run on a cpu-revision 51025 i.MX processor on the r1.1
and r1.2 boards in any version, before my changes or after, we will
patch back in confirmed and working support, but we shouldn't be told
we have to maintain broken code just so it sticks around. You have
git, you can see the changes made to remove the code (it's literally
all of 3 lines extra to add it back in, it is mainly the second SD
card slot definition and CD/WP pins). It is not like the information
is lost in time.

I just don't see the point in making sure we update every line of code
that exists, if that code simply never gets run, or never has the
opportunity to run due to other problems.

This is a dead product, we simply want to make sure that SOME mainline
support is both reliable and usable. The work directly influences the
design of new products and existing products which are not in
mainline; to get MX53 stuff in there or MX6 design stuff in there,
common IOMUX setup, common GPIO, other common things which are
otherwise awful to define and add to designs. If we evaluate the
software development will take too much time and money it may be cut
from the design. If the feature makes the board less user-friendly as
a result, it will definitely never make it into a prototype.

Right now, we're trying to lay a good foundation for MX53 and MX6
designs we currently sell. Supporting the MX51 models is purely laying
that good foundation to make sure that the effort we expend later on
actual shipping products can be tested across the entire line where
common code and configuration can and should exist. Unfortunately
i.MX51 TO2 designs exist in the world in some number, but fortunately
the number of people

Re: [U-Boot] [PATCH 2/4] efikamx: remove drive strength hack from early_init_f and move it to the DCD

[Matt Sealey]

On Sat, Aug 18, 2012 at 5:56 PM, stefano babic sba...@denx.de wrote:
 Am 19/08/2012 00:29, schrieb Marek Vasut:
 Dear Matt Sealey,

 On Sat, Aug 18, 2012 at 10:34 AM, Stefano Babic sba...@denx.de wrote:
 On 17/08/2012 20:19, Matt Sealey wrote:
 The i.MX Boot ROM lets us set up certain registers before U-Boot even
 gets executed. Rather than setting up DDR, putting U-Boot in place, and
 getting into pre-relocation init to set up DDR again, just do it once
 in the correct place. This also solves an issue where the Smarttop DDR
 pad settings were being applied on Smartbook.

 While we're at it, configure PCBID0,1,2 and the LED GPIO since we've
 still got room in the DCD to do so.

 Signed-off-by: Matt Sealey m...@genesi-usa.com
 ---

 Hi Matt,

 diff --git a/board/genesi/mx51_efikamx/imximage_mx.cfg
 b/board/genesi/mx51_efikamx/imximage_mx.cfg index 6fe0ff9..ac9aa9a
 100644
 --- a/board/genesi/mx51_efikamx/imximage_mx.cfg
 +++ b/board/genesi/mx51_efikamx/imximage_mx.cfg
 @@ -1,7 +1,7 @@

  #

 +# Copyright (C) 2009 Pegatron Corporation

 ^---

 Was this added for mistake ? I think you should add only yours.

 The drive strength settings came from Pegatron a long, long time ago
 (2009 :) and our old config and the function is copyrighted to them.
 Just because Marek took them out and recopyrighted the file I derived
 them from in this case doesn't mean they lost their copyright..

 This file was taken from mx51evk. It's written there. Please stop this 
 nonsense,
 it's troubling me.

 Then Pegatron has nothing to do with it. The original comes from
 Freescale, and the copyright was set.

Here is the pedigree of the code from initial table to current
implementation, as it stands;

* 2009, Pegatron wrote their U-Boot port for the board
* 2009, Pegatron gave us these drive strength settings based on some
very expensive and laborious testing and calibration of the DDR
implementation on the board. They did not update the settings in the
DCD table, they just implemented this function which persisted in
Marek's port to mainline
* 2010, Marek took the mx51evk example and added the OLD DCD table to
imximage.cfg and left the Pegatron drive strength code in there. Marek
removed the Pegatron copyright, and Genesi's copyright, and
Freescale's copyright but left the original code copyright he took
from U-Boot. You cannot just remove the copyright pedigree from the
chain just because you decided the source of the code was one guy
when you copy paste it from some other place
* 2012, we put the Pegatron copyrights back in, removed the drive
strength function from the board file, re-integrated it into the
imximage.cfg layout, and added our copyrights since we did the
expensive and laborious testing of the values and cross-referencing of
the manual.

The copyrights on every Efika MX file, since they were ALL ported from
the original Pegatron reference code should be;

Copyright (C) 2009 Freescale Semiconductor
Copyright (C) 2009 Pegatron Corporation
Copyright (C) 2009-2012 Genesi USA, Inc.
name of the guy who you copied the mx51evk board file or imximage.cfg from
your name here

And that's that. We are looking to go about restoring the pedigree, that's all.

If this was a $5000 dog, you would be concerned if you found out
someone had accidentally removed some history where it's grandmother
bred with a mongrel and invalidated it's pure-bred status. I can
assure you the money spent on coding this original code was more than
the cost of a dog and the copyright chain should persist whether you
think you wrote the code yourself or copied it from elsewhere in
U-Boot.

The MX51EVK board files may have been where whoever originally
committed them sourced it from, but this is not the true source of the
code contained in the drive strength function we removed, the data
contained in it, or the PCB ID table that's listed in the comments.
The MX51EVK DDR settings in imximage.cfg are not the same as the ones
in the old Efika MX file, so these have been ported from Pegatron's
old DCD data. The new drive strength settings are sourced from the
function and moved back into the DCD. All I did was verify they worked
and we were not redundantly setting up the same register twice or
pushing defaults information via the DCD to registers (since we only
have 60 entries, doing every DDR pad control plus the required PCB ID
setup overflows the maximum).

-- 
Matt Sealey m...@genesi-usa.com
Product Development Analyst, Genesi USA, Inc.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v4] MX: Set a common gpio.h for all i.MX

[Matt Sealey]

Works fine on the Efika MX :)

Tested-by: Matt Sealey m...@genesi-usa.com

-- 
Matt Sealey m...@genesi-usa.com
Product Development Analyst, Genesi USA, Inc.


On Mon, Aug 20, 2012 at 2:33 AM, Stefano Babic sba...@denx.de wrote:
 Each i.MX has its own gpio.h, defining the same structure.
 The internal GPIO controller has the same layout
 (at least for the register used by u-boot) and can be shared.

 Signed-off-by: Stefano Babic sba...@denx.de
 ---
 Changes in v2:
 - please ignore this version, it is broken

 Changes in v3:
 - call the macro IMX_GPIO_NR  as in kernel (Fabio Estevam)
 - change psr in gpio_psr (Benoit Thebaudeau)
 - drop MXC_GPIO_PORT_TO_NUM and use common macro (Benoit Thebaudeau)

 Changes in v4:
 - Add missing comment in commit message

  arch/arm/include/asm/arch-mx25/gpio.h |   17 +--
  arch/arm/include/asm/arch-mx31/gpio.h |7 +
  arch/arm/include/asm/arch-mx35/gpio.h |   12 +---
  arch/arm/include/asm/arch-mx5/gpio.h  |7 +
  arch/arm/include/asm/arch-mx6/gpio.h  |7 +
  arch/arm/include/asm/arch-mx6/imx-regs.h  |2 --
  arch/arm/include/asm/imx-common/gpio.h|   39 
 +
  board/freescale/mx6qsabrelite/mx6qsabrelite.c |   28 +-
  board/karo/tx25/tx25.c|   10 +++
  board/syteco/zmx25/zmx25.c|   26 -
  include/configs/mx6qsabrelite.h   |3 +-
  11 files changed, 78 insertions(+), 80 deletions(-)
  create mode 100644 arch/arm/include/asm/imx-common/gpio.h

 diff --git a/arch/arm/include/asm/arch-mx25/gpio.h 
 b/arch/arm/include/asm/arch-mx25/gpio.h
 index dc6edc7..61c0b0d 100644
 --- a/arch/arm/include/asm/arch-mx25/gpio.h
 +++ b/arch/arm/include/asm/arch-mx25/gpio.h
 @@ -25,21 +25,6 @@
  #ifndef __ASM_ARCH_MX25_GPIO_H
  #define __ASM_ARCH_MX25_GPIO_H

 -/* Converts a GPIO port number and the internal bit position
 - * to the GPIO number
 - */
 -#define MXC_GPIO_PORT_TO_NUM(port, bit) (((port - 1)  5) + (bit  0x1f))
 -
 -/* GPIO registers */
 -struct gpio_regs {
 -   u32 gpio_dr;/* data */
 -   u32 gpio_dir;   /* direction */
 -   u32 psr;/* pad satus */
 -   u32 icr1;   /* interrupt config 1 */
 -   u32 icr2;   /* interrupt config 2 */
 -   u32 imr;/* interrupt mask */
 -   u32 isr;/* interrupt status */
 -   u32 edge_sel;   /* edge select */
 -};
 +#include asm/imx-common/gpio.h

  #endif
 diff --git a/arch/arm/include/asm/arch-mx31/gpio.h 
 b/arch/arm/include/asm/arch-mx31/gpio.h
 index 95b73bf..55c0afa 100644
 --- a/arch/arm/include/asm/arch-mx31/gpio.h
 +++ b/arch/arm/include/asm/arch-mx31/gpio.h
 @@ -25,11 +25,6 @@
  #ifndef __ASM_ARCH_MX31_GPIO_H
  #define __ASM_ARCH_MX31_GPIO_H

 -/* GPIO Registers */
 -struct gpio_regs {
 -   u32 gpio_dr;
 -   u32 gpio_dir;
 -   u32 gpio_psr;
 -};
 +#include asm/imx-common/gpio.h

  #endif
 diff --git a/arch/arm/include/asm/arch-mx35/gpio.h 
 b/arch/arm/include/asm/arch-mx35/gpio.h
 index 7bcc3e8..1deb292 100644
 --- a/arch/arm/include/asm/arch-mx35/gpio.h
 +++ b/arch/arm/include/asm/arch-mx35/gpio.h
 @@ -25,16 +25,6 @@
  #ifndef __ASM_ARCH_MX35_GPIO_H
  #define __ASM_ARCH_MX35_GPIO_H

 -/* GPIO registers */
 -struct gpio_regs {
 -   u32 gpio_dr;/* data */
 -   u32 gpio_dir;   /* direction */
 -   u32 psr;/* pad satus */
 -   u32 icr1;   /* interrupt config 1 */
 -   u32 icr2;   /* interrupt config 2 */
 -   u32 imr;/* interrupt mask */
 -   u32 isr;/* interrupt status */
 -   u32 edge_sel;   /* edge select */
 -};
 +#include asm/imx-common/gpio.h

  #endif
 diff --git a/arch/arm/include/asm/arch-mx5/gpio.h 
 b/arch/arm/include/asm/arch-mx5/gpio.h
 index 1dc34e9..b1b1218 100644
 --- a/arch/arm/include/asm/arch-mx5/gpio.h
 +++ b/arch/arm/include/asm/arch-mx5/gpio.h
 @@ -25,11 +25,6 @@
  #ifndef __ASM_ARCH_MX5_GPIO_H
  #define __ASM_ARCH_MX5_GPIO_H

 -/* GPIO registers */
 -struct gpio_regs {
 -   u32 gpio_dr;
 -   u32 gpio_dir;
 -   u32 gpio_psr;
 -};
 +#include asm/imx-common/gpio.h

  #endif
 diff --git a/arch/arm/include/asm/arch-mx6/gpio.h 
 b/arch/arm/include/asm/arch-mx6/gpio.h
 index 20c4e57..24c10f8 100644
 --- a/arch/arm/include/asm/arch-mx6/gpio.h
 +++ b/arch/arm/include/asm/arch-mx6/gpio.h
 @@ -25,11 +25,6 @@
  #ifndef __ASM_ARCH_MX6_GPIO_H
  #define __ASM_ARCH_MX6_GPIO_H

 -/* GPIO registers */
 -struct gpio_regs {
 -   u32 gpio_dr;
 -   u32 gpio_dir;
 -   u32 gpio_psr;
 -};
 +#include asm/imx-common/gpio.h

  #endif /* __ASM_ARCH_MX6_GPIO_H */
 diff --git a/arch/arm/include/asm/arch-mx6/imx-regs.h 
 b/arch/arm/include/asm/arch-mx6/imx-regs.h
 index 5d77603..f3e58b5 100644
 --- a/arch/arm/include/asm/arch-mx6/imx-regs.h
 +++ b/arch/arm/include/asm/arch-mx6/imx-regs.h
 @@ -172,8 +172,6 @@
  #define IMX_IIM_BASE

[U-Boot] ROM_SI_REV on MX5

[Matt Sealey]

Can anyone tell me where this offset is in relation to, or what it's
actually meant to be?

Some parts of U-Boot read it out but I can't figure any part of the
docs that refers to this magic 0x48 offset or what it could be (or
what it should be when you read it out)?

-- 
Matt Sealey m...@genesi-usa.com
Product Development Analyst, Genesi USA, Inc.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] ROM_SI_REV on MX5

[Matt Sealey]

On Mon, Aug 20, 2012 at 5:20 PM, Benoît Thébaudeau
benoit.thebaud...@advansee.com wrote:
 Hi Matt,

 Can anyone tell me where this offset is in relation to, or what it's
 actually meant to be?

 Some parts of U-Boot read it out but I can't figure any part of the
 docs that refers to this magic 0x48 offset or what it could be (or
 what it should be when you read it out)?

 See Figure 9-1. Internal ROM and RAM Memory Map in the i.MX51 RM. This is 
 the
 only reference to it that I find in the RM. All the details probably come from
 FSL's code. I think that it's close to IIM.SREV, if not the same. It's 
 supposed
 to be a ROM version, but it's used like a silicon/tapeout revision.

We've got several boards that seem to randomly change ROM_SI_REV
contents on random boots (one of them went from rev2.5 to rev2.0 to
rev3.0 and back again), and looking at the details on a TO3..
IIM.SILICON_REV reports 0x10 for the revision of a TO3, so that's an
identifier for that I think, otherwise it's 0x00. For silicon revision
2.0, 2.5 I can't confirm this data at location 0x48 of the memory map
though. For TO3 the copyright string for the i.MX boot ROM has
basically gone (it's not random data at 0x though, it's
exactly the same every time..)

Looking at the GPIO registers I can't even confirm that the directions
we're setting in U-Boot are correct, although U-Boot is doing what we
consider to be the right thing.. the board revisions come out fine
from PCBID.

-- 
Matt Sealey m...@genesi-usa.com
Product Development Analyst, Genesi USA, Inc.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] MX: Set a common gpio.h for all i.MX

[Matt Sealey]

On Sat, Aug 18, 2012 at 2:25 PM, Benoît Thébaudeau
benoit.thebaud...@advansee.com wrote:
 Hi Stefano,

 This is a bit off topic, but shouldn't the iomux-v3 stuff be moved to a common
 location for all these i.MXs too? As to the header file, it's already done, 
 but
 the C file is under arch/arm/cpu/armv7/imx-common/ while it is absolutely not
 armv7-specific.

True, I'd advocate that.

-- 
Matt Sealey m...@genesi-usa.com
Product Development Analyst, Genesi USA, Inc.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/4] efikamx: update to Efika MX Smarttop and Smartbook boards

[Matt Sealey]

On Sat, Aug 18, 2012 at 10:50 AM, Stefano Babic sba...@denx.de wrote:
 On 17/08/2012 20:19, Matt Sealey wrote:

 Anyway, who will maintain the efikas in future ? Marek, do you hold it,
 or Matt will take this job ?

I'll do it but I doubt I'm going to be around as much as Marek. What
I'm a little fearful of is having patches try and hit the Efika stuff
and me not having much time that day to review, they either stagnate
or get accepted anyway breaking something. I can't test every patch
everyone sends, we just want to be sure it's hit a certain level of
quality and solve some of the issues we hacked around at the Freescale
BSP level are in mainline as we simply can't use the BSP version
anymore (doesn't support bootz or device trees...)

 In last case I would like to see a patch for the MAINTAINER file.

I'll submit it when I feel like we're actually being forced to
maintain it. I am of two minds; I will be the responsible party if
needs be, but that means Efika MX stuff is going to be commercially
driven by our needs (i.e. runs our boot scripts, supports the board
the way we dictate (no video, no usb keyboards..), no changes to
support developers if they are simply being too needy), and if it
doesn't suit us in terms of breaking something or changing behaviour
wildly, we'll NACK the crap out of it. If that's acceptable, sure...
Marek says U-Boot doesn't follow this development model, but that
would put Denx out of business.

-- 
Matt Sealey m...@genesi-usa.com
Product Development Analyst, Genesi USA, Inc.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/4] efikamx: remove drive strength hack from early_init_f and move it to the DCD

[Matt Sealey]

On Sat, Aug 18, 2012 at 10:34 AM, Stefano Babic sba...@denx.de wrote:
 On 17/08/2012 20:19, Matt Sealey wrote:
 The i.MX Boot ROM lets us set up certain registers before U-Boot even gets
 executed. Rather than setting up DDR, putting U-Boot in place, and getting
 into pre-relocation init to set up DDR again, just do it once in the correct
 place. This also solves an issue where the Smarttop DDR pad settings were
 being applied on Smartbook.

 While we're at it, configure PCBID0,1,2 and the LED GPIO since we've still
 got room in the DCD to do so.

 Signed-off-by: Matt Sealey m...@genesi-usa.com
 ---

 Hi Matt,

 diff --git a/board/genesi/mx51_efikamx/imximage_mx.cfg 
 b/board/genesi/mx51_efikamx/imximage_mx.cfg
 index 6fe0ff9..ac9aa9a 100644
 --- a/board/genesi/mx51_efikamx/imximage_mx.cfg
 +++ b/board/genesi/mx51_efikamx/imximage_mx.cfg
 @@ -1,7 +1,7 @@
  #
 +# Copyright (C) 2009 Pegatron Corporation
 ^---

 Was this added for mistake ? I think you should add only yours.

The drive strength settings came from Pegatron a long, long time ago
(2009 :) and our old config and the function is copyrighted to them.
Just because Marek took them out and recopyrighted the file I derived
them from in this case doesn't mean they lost their copyright..

 I join Marek, it is quite difficult to review it and understand which
 was changed. It looks like a new file..

It's just because I moved the comments to the end of the line, so it's
blocking it up.

Sometimes it's nicer if it's

-this line
+that line
-this line
+that line

.. but that's not how git does it when the change is more than a few
characters and multiple lines changed.. I can submit it differently
but I can't change the way it's producing the diff.

-- 
Matt Sealey m...@genesi-usa.com
Product Development Analyst, Genesi USA, Inc.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] mx5: add iomux-mx51.h include

[Matt Sealey]

On Sat, Aug 18, 2012 at 10:18 AM, Stefano Babic sba...@denx.de wrote:
 On 17/08/2012 20:16, Matt Sealey wrote:
 Essentially now we can share code with the MX6 boards, reducing redundant
 pin definitions across boards and lengthy configuration of external pads
 on the i.MX51.

 Signed-off-by: Matt Sealey m...@genesi-usa.com
 ---

 Hi Matt,


  arch/arm/include/asm/arch-mx5/iomux-mx51.h |  144 
 
  1 file changed, 144 insertions(+)
  create mode 100644 arch/arm/include/asm/arch-mx5/iomux-mx51.h


 As far as I can see iomux-mx51.h is coming from the linux kernel. Then
 please add in the commit message information about which version of the
 kernel you borrow this code, better add the kernel commit-id. This
 allows to have a track where the code is coming from.

I will, for now it's the top of Linus' tree, but this code is going to
get removed from the Linux kernel soon, so I understand, we need to
figure out where it will last forever (probably linux-stable@3.5) so
we can always reference it.

 I do like we add a second identical defeine why we discover an issue in
 another part of code. I know for experience that code introduced this
 the goal to fix it later will never be fixed. So let's see if we can jut
 do the right thing.

 I do not think imx-common/iomux-v3.h is the right place. What has the
 pinmux with gpio to do? This is also wrongit is GPIO related, it
 should go into gpio.h.

That's true. I did not want to mess the patchset up with boards I
cannot test though, and I don't like committing code I didn't test
(mx3 gpio etc.) even if the docs say as much as it's identical. I see
you already fixed that though.

I'll rebase on Monday and submit something new... see below, though..

 +
 +#endif /* __IOMUX_MX51_H__ */


 Ok, good, this is the same as in kernel.

Right. This all came from a discussion with Troy and Eric at
BoundaryDevices about i2c multi-bus support, they sent us a file with
MX6 support and a hack for MX5 support to go with it; it didn't work
and I figured it'd be a good thing to complete. Troy suggested not
copying the Linux file verbatim (after all, why include camera bus
pinmux when U-Boot won't support a camera bus?) and just include the
pins we wanted. So, this is what I did, but right now I'm going to
find a nice stable commit and tree where this file exists (the one I
copy pasted the pins out of..).

I just noticed that the imx-common/iomux-v3.h is out of date re the
latest kernel too (some bits have moved as MX6 needs extra space to
store some setting) so I'll patch that in as well.

I think we need to make a small discussion point here (new thread?)
about what needs to be done and what has been done, since if this
isn't a tree and just patches on a mailing list or in a patchwork it's
infuriatingly hard to track what is going on and who patched what and
what to base against. I may have to wait until something like your
gpio.h changes hit the u-boot-imx tree..

-- 
Matt Sealey m...@genesi-usa.com
Product Development Analyst, Genesi USA, Inc.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] mx5: add iomux-mx51.h include

[Matt Sealey]

On Sat, Aug 18, 2012 at 4:46 PM, Benoît Thébaudeau
benoit.thebaud...@advansee.com wrote:
 Hi Matt,

   create mode 100644 arch/arm/include/asm/arch-mx5/iomux-mx51.h
 
 
  As far as I can see iomux-mx51.h is coming from the linux kernel.
  Then
  please add in the commit message information about which version of
  the
  kernel you borrow this code, better add the kernel commit-id. This
  allows to have a track where the code is coming from.

 I will, for now it's the top of Linus' tree, but this code is going
 to
 get removed from the Linux kernel soon,

 Good to know. Where did you get that information from? As of now, it is still 
 in
 linux-next and in Sascha's tree, which means that it will probably be in linux
 3.7 too. Is it because of the move to DT that would in the end set up pads 
 from
 DT file info?

By 3.7 (most) or 3.8 (maybe all) a lot of boards will be device tree
only. iomux stuff in board files has been replaced with pinctrl in
device trees..

Shawn will know his schedule better than me (CCd)

-- 
Matt Sealey m...@genesi-usa.com
Product Development Analyst, Genesi USA, Inc.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 1/2] spi: fix mxc_spi_slave structure allocation to clear memory

[Matt Sealey]

Use calloc() instead of malloc() to allocate the mxc_spi_slave structure.
Clearing the memory is necessary since most of the time this gets done
super early in boot, but on warm reboots, and when SPI probing is done
long after the init stages it could actually pick up previously used memory,
and things like the chipselect polarity and other data end up being filled
with trash data if not explicitly set by the board files.

This solves a semi-random, almost unreproducable error whereby SPI devices
act very, very strangly on boot. Tested on Efika MX over several years..

Signed-off-by: Matt Sealey m...@genesi-usa.com
---
 drivers/spi/mxc_spi.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/spi/mxc_spi.c b/drivers/spi/mxc_spi.c
index 2e15318..d1dab18 100644
--- a/drivers/spi/mxc_spi.c
+++ b/drivers/spi/mxc_spi.c
@@ -408,7 +408,7 @@ struct spi_slave *spi_setup_slave(unsigned int bus, 
unsigned int cs,
if (bus = ARRAY_SIZE(spi_bases))
return NULL;
 
-   mxcs = malloc(sizeof(struct mxc_spi_slave));
+   mxcs = calloc(sizeof(struct mxc_spi_slave), 1);
if (!mxcs) {
puts(mxc_spi: SPI Slave not allocated !\n);
return NULL;
-- 
1.7.9.5

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

[U-Boot] [PATCH 2/2] spi: fix mxs_spi_slave structure allocation to clear memory

[Matt Sealey]

Use calloc() instead of malloc() to allocate the mxs_spi_slave structure.
Clearing the memory is necessary since most of the time this gets done
super early in boot, but on warm reboots, and when SPI probing is done
long after the init stages it could actually pick up previously used memory,
and things like the chipselect polarity and other data end up being filled
with trash data if not explicitly set by the board files.

This solves a semi-random, almost unreproducable error whereby SPI devices
act very, very strangly on boot.

Signed-off-by: Matt Sealey m...@genesi-usa.com
---
 drivers/spi/mxs_spi.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/spi/mxs_spi.c b/drivers/spi/mxs_spi.c
index a037c13..5fa7f2b 100644
--- a/drivers/spi/mxs_spi.c
+++ b/drivers/spi/mxs_spi.c
@@ -91,7 +91,7 @@ struct spi_slave *spi_setup_slave(unsigned int bus, unsigned 
int cs,
return NULL;
}
 
-   mxs_slave = malloc(sizeof(struct mxs_spi_slave));
+   mxs_slave = calloc(sizeof(struct mxs_spi_slave), 1);
if (!mxs_slave)
return NULL;
 
-- 
1.7.9.5

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

[U-Boot] [PATCH] mx5: add iomux-mx51.h include

[Matt Sealey]

Essentially now we can share code with the MX6 boards, reducing redundant
pin definitions across boards and lengthy configuration of external pads
on the i.MX51.

Signed-off-by: Matt Sealey m...@genesi-usa.com
---
 arch/arm/include/asm/arch-mx5/iomux-mx51.h |  144 
 1 file changed, 144 insertions(+)
 create mode 100644 arch/arm/include/asm/arch-mx5/iomux-mx51.h

diff --git a/arch/arm/include/asm/arch-mx5/iomux-mx51.h 
b/arch/arm/include/asm/arch-mx5/iomux-mx51.h
new file mode 100644
index 000..f944c13
--- /dev/null
+++ b/arch/arm/include/asm/arch-mx5/iomux-mx51.h
@@ -0,0 +1,144 @@
+/*
+ * Copyright (C) 2009-2010 Amit Kucheria amit.kuche...@canonical.com
+ * Copyright (C) 2010 Freescale Semiconductor, Inc.
+ * Copyright (C) 2009-2012 Genesi USA, Inc.
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#ifndef __IOMUX_MX51_H__
+#define __IOMUX_MX51_H__
+
+#include asm/imx-common/iomux-v3.h
+
+#define PAD_CTL_DVS(1  13)
+#define PAD_CTL_INPUT_DDR  (1  9)
+#define PAD_CTL_HYS(1  8)
+
+#define PAD_CTL_PKE(1  7)
+#define PAD_CTL_PUE(1  6 | PAD_CTL_PKE)
+#define PAD_CTL_PUS_100K_DOWN  (0  4 | PAD_CTL_PUE)
+#define PAD_CTL_PUS_47K_UP (1  4 | PAD_CTL_PUE)
+#define PAD_CTL_PUS_100K_UP(2  4 | PAD_CTL_PUE)
+#define PAD_CTL_PUS_22K_UP (3  4 | PAD_CTL_PUE)
+
+#define PAD_CTL_ODE(1  3)
+
+#define PAD_CTL_DSE_LOW(0  1)
+#define PAD_CTL_DSE_MED(1  1)
+#define PAD_CTL_DSE_HIGH   (2  1)
+#define PAD_CTL_DSE_MAX(3  1)
+
+#define PAD_CTL_SRE_FAST   (1  0)
+#define PAD_CTL_SRE_SLOW   (0  0)
+
+/* Pad control groupings */
+#define MX51_UART_PAD_CTRL (PAD_CTL_PKE | PAD_CTL_PUE | PAD_CTL_DSE_HIGH | 
\
+   PAD_CTL_HYS | PAD_CTL_SRE_FAST)
+#define MX51_I2C_PAD_CTRL  (PAD_CTL_SRE_FAST | PAD_CTL_ODE | \
+   PAD_CTL_DSE_HIGH | PAD_CTL_PUS_100K_UP | \
+   PAD_CTL_HYS)
+#define MX51_ESDHC_PAD_CTRL(PAD_CTL_SRE_FAST | PAD_CTL_ODE | \
+   PAD_CTL_DSE_HIGH | PAD_CTL_PUS_100K_UP | \
+   PAD_CTL_HYS)
+#define MX51_USBH1_PAD_CTRL(PAD_CTL_PKE | PAD_CTL_SRE_FAST | \
+   PAD_CTL_DSE_HIGH | PAD_CTL_PUS_100K_UP | \
+   PAD_CTL_HYS | PAD_CTL_PUE)
+#define MX51_ECSPI_PAD_CTRL(PAD_CTL_PKE | PAD_CTL_HYS | \
+   PAD_CTL_DSE_HIGH | PAD_CTL_SRE_FAST)
+#define MX51_SDHCI_PAD_CTRL(PAD_CTL_PKE | PAD_CTL_DSE_HIGH | \
+   PAD_CTL_PUS_47K_UP | PAD_CTL_PUE | \
+   PAD_CTL_SRE_FAST | PAD_CTL_DVS)
+#define MX51_GPIO_PAD_CTRL (PAD_CTL_DSE_HIGH | PAD_CTL_PKE | 
PAD_CTL_SRE_FAST)
+
+#define __NA_ 0x000
+
+/*
+ * this is in imx-regs.h for i.MX6 but it probably should be in
+ * imx-common/iomux-v3.h - however, since we're trying to be
+ * compatible with all the other boards using this include, and
+ * i.MX6 has this defined in arch-mx5/imx_regs.h we don't want
+ * to create a build breakage or even just a warning at this time.
+ *
+ * So, we can move it to imx-common/iomux-v3.h when this is all
+ * figured out, and all i.MX5+ boards use the common iomux-v3
+ * functionality, but until then it's needlessly duplicated here.
+ */
+#define GPIO_NUMBER(port, index)   port)-1)*32)+((index)31))
+
+/*
+ * The naming convention for the pad modes is MX51_PAD_padname__padmode
+ * If padname or padmode refers to a GPIO, it is named GPIOunit_num
+ * See also iomux-v3.h
+ */
+
+/* 
PADMUX   ALT INPSE PATH PADCTRL */
+enum {
+   MX51_PAD_EIM_CS0__GPIO2_25  = IOMUX_PAD(0x474, 
0x0e0, 1, __NA_, 0, MX51_GPIO_PAD_CTRL),
+   MX51_PAD_EIM_CS2__SD1_CD= IOMUX_PAD(0x47c, 
0x0e8, 1, __NA_, 0, MX51_ESDHC_PAD_CTRL),
+   MX51_PAD_EIM_CS3__GPIO2_28  = IOMUX_PAD(0x480, 
0x0ec, 1, __NA_, 0, MX51_GPIO_PAD_CTRL),
+   MX51_PAD_EIM_CS4__GPIO2_29  = IOMUX_PAD(0x484, 
0x0f0, 1, __NA_, 0, MX51_GPIO_PAD_CTRL),
+   MX51_PAD_NANDF_WE_B__PATA_DIOW  = IOMUX_PAD(0x4e4, 0x108, 1, 
__NA_, 0, NO_PAD_CTRL),
+   MX51_PAD_NANDF_RE_B__PATA_DIOR  = IOMUX_PAD(0x4e8, 0x10c, 1, 
__NA_, 0, NO_PAD_CTRL),
+   MX51_PAD_NANDF_ALE__PATA_BUFFER_EN  = IOMUX_PAD(0x4ec, 0x110, 1, 
__NA_, 0, NO_PAD_CTRL

[U-Boot] [PATCH 0/4] efikamx: update Efika MX support

[Matt Sealey]

This patchset relies on the previously submitted patch mx5: add iomux-mx51.h 
include

It may not boot reliably, completely at random, on Efika MX boards, without the 
previously submitted (series) spi: fix mxc_spi_slave structure allocation to 
clear memory

Matt Sealey (4):
  efikamx: move efikamx into a new directory in preparation for new
boards
  efikamx: remove drive strength hack from early_init_f and move it to
the DCD
  efikamx: update to Efika MX Smarttop and Smartbook boards
  efikamx: port USB setup to new iomux model

 arch/arm/include/asm/arch-mx5/iomux-mx51.h |   28 ++
 board/efikamx/Makefile |   49 --
 board/efikamx/efikamx-usb.c|  216 
 board/efikamx/efikamx.c|  735 
 board/efikamx/imximage_mx.cfg  |  122 -
 board/efikamx/imximage_sb.cfg  |  122 -
 board/genesi/mx51_efikamx/Makefile |   49 ++
 board/genesi/mx51_efikamx/efikamx-usb.c|  203 
 board/genesi/mx51_efikamx/efikamx.c|  507 +++
 board/genesi/mx51_efikamx/imximage_mx.cfg  |  113 +
 board/genesi/mx51_efikamx/imximage_sb.cfg  |  122 +
 boards.cfg |4 +-
 include/configs/efikamx.h  |  274 ---
 include/configs/mx51_efikamx.h |  274 +++
 14 files changed, 1298 insertions(+), 1520 deletions(-)
 delete mode 100644 board/efikamx/Makefile
 delete mode 100644 board/efikamx/efikamx-usb.c
 delete mode 100644 board/efikamx/efikamx.c
 delete mode 100644 board/efikamx/imximage_mx.cfg
 delete mode 100644 board/efikamx/imximage_sb.cfg
 create mode 100644 board/genesi/mx51_efikamx/Makefile
 create mode 100644 board/genesi/mx51_efikamx/efikamx-usb.c
 create mode 100644 board/genesi/mx51_efikamx/efikamx.c
 create mode 100644 board/genesi/mx51_efikamx/imximage_mx.cfg
 create mode 100644 board/genesi/mx51_efikamx/imximage_sb.cfg
 delete mode 100644 include/configs/efikamx.h
 create mode 100644 include/configs/mx51_efikamx.h

-- 
1.7.9.5

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

[U-Boot] [PATCH 2/4] efikamx: remove drive strength hack from early_init_f and move it to the DCD

[Matt Sealey]

The i.MX Boot ROM lets us set up certain registers before U-Boot even gets
executed. Rather than setting up DDR, putting U-Boot in place, and getting
into pre-relocation init to set up DDR again, just do it once in the correct
place. This also solves an issue where the Smarttop DDR pad settings were
being applied on Smartbook.

While we're at it, configure PCBID0,1,2 and the LED GPIO since we've still
got room in the DCD to do so.

Signed-off-by: Matt Sealey m...@genesi-usa.com
---
 board/genesi/mx51_efikamx/efikamx.c   |   77 -
 board/genesi/mx51_efikamx/imximage_mx.cfg |   89 +
 2 files changed, 40 insertions(+), 126 deletions(-)

diff --git a/board/genesi/mx51_efikamx/efikamx.c 
b/board/genesi/mx51_efikamx/efikamx.c
index e88b2ed..12371c9 100644
--- a/board/genesi/mx51_efikamx/efikamx.c
+++ b/board/genesi/mx51_efikamx/efikamx.c
@@ -597,85 +597,8 @@ void efikamx_toggle_led(uint32_t mask)
 /*
  * Board initialization
  */
-static void init_drive_strength(void)
-{
-   mxc_iomux_set_pad(MX51_PIN_CTL_GRP_PKEDDR, PAD_CTL_DDR_INPUT_CMOS);
-   mxc_iomux_set_pad(MX51_PIN_CTL_GRP_PKEADDR, PAD_CTL_PKE_ENABLE);
-   mxc_iomux_set_pad(MX51_PIN_CTL_GRP_DDRAPKS, PAD_CTL_PUE_KEEPER);
-   mxc_iomux_set_pad(MX51_PIN_CTL_GRP_DDRAPUS, PAD_CTL_100K_PU);
-   mxc_iomux_set_pad(MX51_PIN_CTL_GRP_DDR_SR_A1, PAD_CTL_SRE_FAST);
-   mxc_iomux_set_pad(MX51_PIN_CTL_GRP_DDR_A0, PAD_CTL_DRV_HIGH);
-   mxc_iomux_set_pad(MX51_PIN_CTL_GRP_DDR_A1, PAD_CTL_DRV_HIGH);
-   mxc_iomux_set_pad(MX51_PIN_CTL_DRAM_RAS,
-   PAD_CTL_DRV_HIGH | PAD_CTL_SRE_FAST);
-   mxc_iomux_set_pad(MX51_PIN_CTL_DRAM_CAS,
-   PAD_CTL_DRV_HIGH | PAD_CTL_SRE_FAST);
-   mxc_iomux_set_pad(MX51_PIN_CTL_GRP_PKEDDR, PAD_CTL_PKE_ENABLE);
-   mxc_iomux_set_pad(MX51_PIN_CTL_GRP_DDRPKS, PAD_CTL_PUE_KEEPER);
-   mxc_iomux_set_pad(MX51_PIN_CTL_GRP_HYSDDR0, PAD_CTL_HYS_NONE);
-   mxc_iomux_set_pad(MX51_PIN_CTL_GRP_HYSDDR1, PAD_CTL_HYS_NONE);
-   mxc_iomux_set_pad(MX51_PIN_CTL_GRP_HYSDDR2, PAD_CTL_HYS_NONE);
-   mxc_iomux_set_pad(MX51_PIN_CTL_GRP_HYSDDR3, PAD_CTL_HYS_NONE);
-   mxc_iomux_set_pad(MX51_PIN_CTL_GRP_DDR_SR_B0, PAD_CTL_SRE_FAST);
-   mxc_iomux_set_pad(MX51_PIN_CTL_GRP_DDR_SR_B1, PAD_CTL_SRE_FAST);
-   mxc_iomux_set_pad(MX51_PIN_CTL_GRP_DDR_SR_B2, PAD_CTL_SRE_FAST);
-   mxc_iomux_set_pad(MX51_PIN_CTL_GRP_DDR_SR_B4, PAD_CTL_SRE_FAST);
-   mxc_iomux_set_pad(MX51_PIN_CTL_GRP_DDRPUS, PAD_CTL_100K_PU);
-   mxc_iomux_set_pad(MX51_PIN_CTL_GRP_INMODE1, PAD_CTL_DDR_INPUT_CMOS);
-   mxc_iomux_set_pad(MX51_PIN_CTL_GRP_DRAM_B0, PAD_CTL_DRV_MEDIUM);
-   mxc_iomux_set_pad(MX51_PIN_CTL_GRP_DRAM_B1, PAD_CTL_DRV_MEDIUM);
-   mxc_iomux_set_pad(MX51_PIN_CTL_GRP_DRAM_B2, PAD_CTL_DRV_MEDIUM);
-   mxc_iomux_set_pad(MX51_PIN_CTL_GRP_DRAM_B4, PAD_CTL_DRV_MEDIUM);
-
-   /* Setting pad options */
-   mxc_iomux_set_pad(MX51_PIN_CTL_DRAM_SDWE,
-   PAD_CTL_PKE_ENABLE | PAD_CTL_PUE_KEEPER |
-   PAD_CTL_DRV_HIGH | PAD_CTL_SRE_FAST);
-   mxc_iomux_set_pad(MX51_PIN_CTL_DRAM_SDCKE0,
-   PAD_CTL_PKE_ENABLE | PAD_CTL_PUE_KEEPER |
-   PAD_CTL_DRV_HIGH | PAD_CTL_SRE_FAST);
-   mxc_iomux_set_pad(MX51_PIN_CTL_DRAM_SDCKE1,
-   PAD_CTL_PKE_ENABLE | PAD_CTL_PUE_KEEPER |
-   PAD_CTL_DRV_HIGH | PAD_CTL_SRE_FAST);
-   mxc_iomux_set_pad(MX51_PIN_CTL_DRAM_SDCLK,
-   PAD_CTL_PKE_ENABLE | PAD_CTL_PUE_KEEPER |
-   PAD_CTL_DRV_HIGH | PAD_CTL_SRE_FAST);
-   mxc_iomux_set_pad(MX51_PIN_CTL_DRAM_SDQS0,
-   PAD_CTL_PKE_ENABLE | PAD_CTL_PUE_KEEPER |
-   PAD_CTL_DRV_HIGH | PAD_CTL_SRE_FAST);
-   mxc_iomux_set_pad(MX51_PIN_CTL_DRAM_SDQS1,
-   PAD_CTL_PKE_ENABLE | PAD_CTL_PUE_KEEPER |
-   PAD_CTL_DRV_HIGH | PAD_CTL_SRE_FAST);
-   mxc_iomux_set_pad(MX51_PIN_CTL_DRAM_SDQS2,
-   PAD_CTL_PKE_ENABLE | PAD_CTL_PUE_KEEPER |
-   PAD_CTL_DRV_HIGH | PAD_CTL_SRE_FAST);
-   mxc_iomux_set_pad(MX51_PIN_CTL_DRAM_SDQS3,
-   PAD_CTL_PKE_ENABLE | PAD_CTL_PUE_KEEPER |
-   PAD_CTL_DRV_HIGH | PAD_CTL_SRE_FAST);
-   mxc_iomux_set_pad(MX51_PIN_CTL_DRAM_CS0,
-   PAD_CTL_PKE_ENABLE | PAD_CTL_PUE_KEEPER |
-   PAD_CTL_DRV_HIGH | PAD_CTL_SRE_FAST);
-   mxc_iomux_set_pad(MX51_PIN_CTL_DRAM_CS1,
-   PAD_CTL_PKE_ENABLE | PAD_CTL_PUE_KEEPER |
-   PAD_CTL_DRV_HIGH | PAD_CTL_SRE_FAST);
-   mxc_iomux_set_pad(MX51_PIN_CTL_DRAM_DQM0,
-   PAD_CTL_PKE_ENABLE | PAD_CTL_PUE_KEEPER |
-   PAD_CTL_DRV_HIGH | PAD_CTL_SRE_FAST);
-   mxc_iomux_set_pad(MX51_PIN_CTL_DRAM_DQM1,
-   PAD_CTL_PKE_ENABLE | PAD_CTL_PUE_KEEPER |
-   PAD_CTL_DRV_HIGH | PAD_CTL_SRE_FAST);
-   mxc_iomux_set_pad(MX51_PIN_CTL_DRAM_DQM2,
-   PAD_CTL_PKE_ENABLE | PAD_CTL_PUE_KEEPER

[U-Boot] [PATCH 3/4] efikamx: update to Efika MX Smarttop and Smartbook boards

[Matt Sealey]

Change summary:

* Use iomux-mx51.h include to simplify board configuration.
* Remove LED toggle function as it had no real users.
* Red LED is now on for pre-reloc, Blue LED for in U-Boot
* Function renames for readability.
* Some board identification string changes
* Reduce CPU core voltage to 1.1V (per TO3 spec)
* Implicitly remove support for TO2 boards

Signed-off-by: Matt Sealey m...@genesi-usa.com
---
 board/genesi/mx51_efikamx/efikamx.c |  611 +--
 1 file changed, 230 insertions(+), 381 deletions(-)

diff --git a/board/genesi/mx51_efikamx/efikamx.c 
b/board/genesi/mx51_efikamx/efikamx.c
index 12371c9..16e877f 100644
--- a/board/genesi/mx51_efikamx/efikamx.c
+++ b/board/genesi/mx51_efikamx/efikamx.c
@@ -1,7 +1,7 @@
 /*
+ * Copyright (C) 2009 Freescale Semiconductor, Inc.
  * Copyright (C) 2010 Marek Vasut marek.va...@gmail.com
- *
- * (C) Copyright 2009 Freescale Semiconductor, Inc.
+ * Copyright (C) 2009-2012 Genesi USA, Inc.
  *
  * See file CREDITS for list of people who contributed to this
  * project.
@@ -24,9 +24,7 @@
 
 #include common.h
 #include asm/io.h
-#include asm/arch/imx-regs.h
-#include asm/arch/mx5x_pins.h
-#include asm/arch/iomux.h
+#include asm/arch/iomux-mx51.h
 #include asm/gpio.h
 #include asm/errno.h
 #include asm/arch/sys_proto.h
@@ -48,16 +46,12 @@ DECLARE_GLOBAL_DATA_PTR;
 #endif
 
 /*
- * Shared variables / local defines
+ * Board revisions
+ *
+ * Note that we get these revisions here for convenience, but we only set
+ * up for the production model Smarttop (1.3) and Smartbook (2.0). 
+ *
  */
-/* LED */
-#defineEFIKAMX_LED_BLUE0x1
-#defineEFIKAMX_LED_GREEN   0x2
-#defineEFIKAMX_LED_RED 0x4
-
-void efikamx_toggle_led(uint32_t mask);
-
-/* Board revisions */
 #defineEFIKAMX_BOARD_REV_110x1
 #defineEFIKAMX_BOARD_REV_120x2
 #defineEFIKAMX_BOARD_REV_130x3
@@ -69,66 +63,67 @@ void efikamx_toggle_led(uint32_t mask);
 /*
  * Board identification
  */
-u32 get_efikamx_rev(void)
+static u32 get_mx_rev(void)
 {
u32 rev = 0;
/*
 * Retrieve board ID:
-*  rev1.1: 1,1,1
-*  rev1.2: 1,1,0
-*  rev1.3: 1,0,1
-*  rev1.4: 1,0,0
+*
+*  gpio: 16 17 11
+*  ==
+*  r1.1:  1+ 1  1
+*  r1.2:  1  1  0
+*  r1.3:  1  0  1
+*  r1.4:  1  0  0
+*
+* + note: r1.1 does not strap this pin properly so it needs to
+* be hacked or ignored.
 */
-   mxc_request_iomux(MX51_PIN_NANDF_CS0, IOMUX_CONFIG_GPIO);
-   /* set to 1 in order to get correct value on board rev1.1 */
-   gpio_direction_output(IOMUX_TO_GPIO(MX51_PIN_NANDF_CS0), 1);
+
+   /* set to 1 in order to get correct value on board rev 1.1 */
+   gpio_direction_output(GPIO_NUMBER(3, 16), 1);
+   gpio_direction_input(GPIO_NUMBER(3, 11));
+   gpio_direction_input(GPIO_NUMBER(3, 16));
+   gpio_direction_input(GPIO_NUMBER(3, 17));
 
-   mxc_request_iomux(MX51_PIN_NANDF_CS0, IOMUX_CONFIG_GPIO);
-   mxc_iomux_set_pad(MX51_PIN_NANDF_CS0, PAD_CTL_100K_PU);
-   gpio_direction_input(IOMUX_TO_GPIO(MX51_PIN_NANDF_CS0));
-   rev |= (!!gpio_get_value(IOMUX_TO_GPIO(MX51_PIN_NANDF_CS0)))  0;
-
-   mxc_request_iomux(MX51_PIN_NANDF_CS1, IOMUX_CONFIG_GPIO);
-   mxc_iomux_set_pad(MX51_PIN_NANDF_CS1, PAD_CTL_100K_PU);
-   gpio_direction_input(IOMUX_TO_GPIO(MX51_PIN_NANDF_CS1));
-   rev |= (!!gpio_get_value(IOMUX_TO_GPIO(MX51_PIN_NANDF_CS1)))  1;
-
-   mxc_request_iomux(MX51_PIN_NANDF_RB3, IOMUX_CONFIG_GPIO);
-   mxc_iomux_set_pad(MX51_PIN_NANDF_RB3, PAD_CTL_100K_PU);
-   gpio_direction_input(IOMUX_TO_GPIO(MX51_PIN_NANDF_RB3));
-   rev |= (!!gpio_get_value(IOMUX_TO_GPIO(MX51_PIN_NANDF_RB3)))  2;
+   rev |= (!!gpio_get_value(GPIO_NUMBER(3, 16)))  0;
+   rev |= (!!gpio_get_value(GPIO_NUMBER(3, 17)))  1;
+   rev |= (!!gpio_get_value(GPIO_NUMBER(3, 11)))  2;
 
return (~rev  0x7) + 1;
 }
 
-inline u32 get_efikasb_rev(void)
+static iomux_v3_cfg_t efikasb_revision_pads[] = {
+   MX51_PAD_EIM_CS3__GPIO2_28,
+   MX51_PAD_EIM_CS4__GPIO2_29,
+};
+
+static inline u32 get_sb_rev(void)
 {
u32 rev = 0;
 
-   mxc_request_iomux(MX51_PIN_EIM_CS3, IOMUX_CONFIG_GPIO);
-   mxc_iomux_set_pad(MX51_PIN_EIM_CS3, PAD_CTL_100K_PU);
-   gpio_direction_input(IOMUX_TO_GPIO(MX51_PIN_EIM_CS3));
-   rev |= (!!gpio_get_value(IOMUX_TO_GPIO(MX51_PIN_EIM_CS3)))  0;
-
-   mxc_request_iomux(MX51_PIN_EIM_CS4, IOMUX_CONFIG_GPIO);
-   mxc_iomux_set_pad(MX51_PIN_EIM_CS4, PAD_CTL_100K_PU);
-   gpio_direction_input(IOMUX_TO_GPIO(MX51_PIN_EIM_CS4));
-   rev |= (!!gpio_get_value(IOMUX_TO_GPIO(MX51_PIN_EIM_CS4)))  1;
+   imx_iomux_v3_setup_multiple_pads(efikasb_revision_pads, 
ARRAY_SIZE(efikasb_revision_pads));
+   gpio_direction_input(GPIO_NUMBER(2, 28

[U-Boot] [PATCH 4/4] efikamx: port USB setup to new iomux model

[Matt Sealey]

* Add required pin data to iomux-mx51.h
* Port old iomux model to new iomux-v3 model
* Remove some needless code
* Function renames for readability

Signed-off-by: Matt Sealey m...@genesi-usa.com
---
 arch/arm/include/asm/arch-mx5/iomux-mx51.h |   28 +
 board/genesi/mx51_efikamx/efikamx-usb.c|  159 +---
 board/genesi/mx51_efikamx/efikamx.c|6 +-
 3 files changed, 104 insertions(+), 89 deletions(-)

diff --git a/arch/arm/include/asm/arch-mx5/iomux-mx51.h 
b/arch/arm/include/asm/arch-mx5/iomux-mx51.h
index f944c13..0a99ae4 100644
--- a/arch/arm/include/asm/arch-mx5/iomux-mx51.h
+++ b/arch/arm/include/asm/arch-mx5/iomux-mx51.h
@@ -79,6 +79,20 @@
 
 /* 
PADMUX   ALT INPSE PATH PADCTRL */
 enum {
+   MX51_PAD_EIM_D16__USBH2_DATA0   = IOMUX_PAD(0x3f0, 0x05c, 2, 
__NA_, 0, NO_PAD_CTRL),
+   MX51_PAD_EIM_D17__USBH2_DATA1   = IOMUX_PAD(0x3f4, 0x060, 2, 
__NA_, 0, NO_PAD_CTRL),
+   MX51_PAD_EIM_D18__USBH2_DATA2   = IOMUX_PAD(0x3f8, 0x064, 2, 
__NA_, 0, NO_PAD_CTRL),
+   MX51_PAD_EIM_D19__USBH2_DATA3   = IOMUX_PAD(0x3fc, 0x068, 2, 
__NA_, 0, NO_PAD_CTRL),
+   MX51_PAD_EIM_D20__USBH2_DATA4   = IOMUX_PAD(0x400, 0x06c, 2, 
__NA_, 0, NO_PAD_CTRL),
+   MX51_PAD_EIM_D21__USBH2_DATA5   = IOMUX_PAD(0x404, 0x070, 2, 
__NA_, 0, NO_PAD_CTRL),
+   MX51_PAD_EIM_D22__USBH2_DATA6   = IOMUX_PAD(0x408, 0x074, 2, 
__NA_, 0, NO_PAD_CTRL),
+   MX51_PAD_EIM_D23__USBH2_DATA7   = IOMUX_PAD(0x40c, 0x078, 2, 
__NA_, 0, NO_PAD_CTRL),
+   MX51_PAD_EIM_D27__GPIO2_9   = IOMUX_PAD(0x41c, 
0x088, 1, __NA_, 0, MX51_GPIO_PAD_CTRL),
+   MX51_PAD_EIM_A24__USBH2_CLK = IOMUX_PAD(0x450, 
0x0bc, 2, __NA_, 0, NO_PAD_CTRL),
+   MX51_PAD_EIM_A25__USBH2_DIR = IOMUX_PAD(0x454, 
0x0c0, 2, __NA_, 0, NO_PAD_CTRL),
+   MX51_PAD_EIM_A26__GPIO2_20  = IOMUX_PAD(0x458, 
0x0c4, 1, __NA_, 0, MX51_GPIO_PAD_CTRL),
+   MX51_PAD_EIM_A26__USBH2_STP = IOMUX_PAD(0x458, 
0x0c4, 2, __NA_, 0, NO_PAD_CTRL),
+   MX51_PAD_EIM_A27__USBH2_NXT = IOMUX_PAD(0x45c, 
0x0c8, 2, __NA_, 0, NO_PAD_CTRL),
MX51_PAD_EIM_CS0__GPIO2_25  = IOMUX_PAD(0x474, 
0x0e0, 1, __NA_, 0, MX51_GPIO_PAD_CTRL),
MX51_PAD_EIM_CS2__SD1_CD= IOMUX_PAD(0x47c, 
0x0e8, 1, __NA_, 0, MX51_ESDHC_PAD_CTRL),
MX51_PAD_EIM_CS3__GPIO2_28  = IOMUX_PAD(0x480, 
0x0ec, 1, __NA_, 0, MX51_GPIO_PAD_CTRL),
@@ -121,6 +135,19 @@ enum {
MX51_PAD_UART1_TXD__UART1_TXD   = IOMUX_PAD(0x61c, 0x22c, 0, 
__NA_, 0, MX51_UART_PAD_CTRL),
MX51_PAD_UART1_RTS__UART1_RTS   = IOMUX_PAD(0x620, 0x230, 0, 
0x9e0, 0, MX51_UART_PAD_CTRL),
MX51_PAD_UART1_CTS__UART1_CTS   = IOMUX_PAD(0x624, 0x234, 0, 
__NA_, 0, MX51_UART_PAD_CTRL),
+   MX51_PAD_USBH1_CLK__USBH1_CLK   = IOMUX_PAD(0x678, 0x278, 0, 
__NA_, 0, MX51_USBH1_PAD_CTRL),
+   MX51_PAD_USBH1_DIR__USBH1_DIR   = IOMUX_PAD(0x67c, 0x27c, 0, 
__NA_, 0, MX51_USBH1_PAD_CTRL),
+   MX51_PAD_USBH1_STP__USBH1_STP   = IOMUX_PAD(0x680, 0x280, 0, 
__NA_, 0, MX51_USBH1_PAD_CTRL),
+   MX51_PAD_USBH1_STP__GPIO1_27= IOMUX_PAD(0x680, 0x280, 2, 
__NA_, 0, MX51_GPIO_PAD_CTRL),
+   MX51_PAD_USBH1_NXT__USBH1_NXT   = IOMUX_PAD(0x684, 0x284, 0, 
__NA_, 0, MX51_USBH1_PAD_CTRL),
+   MX51_PAD_USBH1_DATA0__USBH1_DATA0   = IOMUX_PAD(0x688, 0x288, 0, 
__NA_, 0, MX51_USBH1_PAD_CTRL),
+   MX51_PAD_USBH1_DATA1__USBH1_DATA1   = IOMUX_PAD(0x68c, 0x28c, 0, 
__NA_, 0, MX51_USBH1_PAD_CTRL),
+   MX51_PAD_USBH1_DATA2__USBH1_DATA2   = IOMUX_PAD(0x690, 0x290, 0, 
__NA_, 0, MX51_USBH1_PAD_CTRL),
+   MX51_PAD_USBH1_DATA3__USBH1_DATA3   = IOMUX_PAD(0x694, 0x294, 0, 
__NA_, 0, MX51_USBH1_PAD_CTRL),
+   MX51_PAD_USBH1_DATA4__USBH1_DATA4   = IOMUX_PAD(0x698, 0x298, 0, 
__NA_, 0, MX51_USBH1_PAD_CTRL),
+   MX51_PAD_USBH1_DATA5__USBH1_DATA5   = IOMUX_PAD(0x69c, 0x29c, 0, 
__NA_, 0, MX51_USBH1_PAD_CTRL),
+   MX51_PAD_USBH1_DATA6__USBH1_DATA6   = IOMUX_PAD(0x6a0, 0x2a0, 0, 
__NA_, 0, MX51_USBH1_PAD_CTRL),
+   MX51_PAD_USBH1_DATA7__USBH1_DATA7   = IOMUX_PAD(0x6a4, 0x2a4, 0, 
__NA_, 0, MX51_USBH1_PAD_CTRL),
MX51_PAD_SD1_CMD__SD1_CMD   = IOMUX_PAD(0x79c, 
0x394, 0x10, __NA_, 0, MX51_SDHCI_PAD_CTRL),
MX51_PAD_SD1_CLK__SD1_CLK   = IOMUX_PAD(0x7a0, 
0x398, 0x10, __NA_, 0, MX51_SDHCI_PAD_CTRL | PAD_CTL_HYS),
MX51_PAD_SD1_DATA0__SD1_DATA0   = IOMUX_PAD(0x7a4, 0x39c, 0x10, 
__NA_, 0, MX51_SDHCI_PAD_CTRL),
@@ -136,6 +163,7 @@ enum {
MX51_PAD_SD2_DATA2__SD2_DATA2   = IOMUX_PAD(0x7cc, 0x3c4, 0x10, 
__NA_, 0, MX51_SDHCI_PAD_CTRL

Re: [U-Boot] [PATCH 2/2] mx5: Use default pin initializers

[Matt Sealey]

On Thu, Aug 16, 2012 at 5:51 PM, Benoît Thébaudeau
benoit.thebaud...@advansee.com wrote:
 Dear Matt Sealey,

 On Thu, Aug 16, 2012 at 3:09 PM, Benoît Thébaudeau
 benoit.thebaud...@advansee.com wrote:

 To improve code quality... And because I have local boards that also needed 
 the
 same functions, so it avoided more duplications.

 For i.MX we have two iomux models and function sets available for
 doing identical stuff. Isn't that kind of wasteful?

 There's probably room for improvement on iomux, but we have to start cleanup
 with something. If you want, you can submit patches and rebase after mine.

Done, to a degree :)

 would avoid you to duplicate your patch code for all boards. These are two
 different topics, and my change comes logically first.

See patches. On Marex's recommendation I based against u-boot-imx
master rather than trying to fit it on top of your stuff. In the end,
I would prefer that boards specifically implement pad settings in
their own board files rather than assuming that some common function
in the driver will suit them; we have an MX6 board here that uses the
SD4 pads for UART2 for debug console. This is absolutely not common at
all to any other MX6 board, so it would have to do UART pad setup and
not use the generic function.

With pads defined as reasonable defaults, and NEW_PAD_CTRL available
to modify pads per-board this is a more flexible setup and exactly why
it was coded this way in Linux and why Freescale seemed to see fit to
backport it to U-Boot (and why it was accepted to mainline for MX6).
There's still some cleanup, all the other boards, and obviously MX53
needs to be added to make it more useful.

If we wish to continue with functions like mx51_uart1_setup() or so,
then that function can reference these values, but I think you will
find it more likely that someone in the future modifies it to take
reference to an iomux_v3_cfg_t array so they can configure their board
properly to something that doesn't meet your assumed defaults, or
defines the pad setup internally to their board and skips calling your
setup function. Then there would be no difference between calling
mx51_uart1_setup vs. imx_iomux_v3_setup_multiple_pads anyway..
reducing the need for it.

I kept the redefinition of the pads for UART etc, even though POR
defaults work fine, just to keep within your assumption that we
shouldn't trust POR defaults.. although I don't think that loading
code via JTAG and executing it (i.e. skipping the i.MX boot ROM) is a
very common process at all as it just flies in the face of what
Freescale intend to be the boot process for the chip, and in any case,
the defaults are part of the SoC logic (and are correct in the
documentation as far as I have checked), not some pre-U-Boot software
configuration. Given the dangers inherent in doing this anyway, I
don't think it would be fitting to make sure things are configured how
you want (and in any case, why would someone configure UART pads
differently to your expectations, and then let U-Boot reconfigure them
on boot?)

-- 
Matt Sealey m...@genesi-usa.com
Product Development Analyst, Genesi USA, Inc.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] mx5: add iomux-mx51.h include

[Matt Sealey]

On Fri, Aug 17, 2012 at 1:42 PM, Benoît Thébaudeau
benoit.thebaud...@advansee.com wrote:
 Dear Matt Sealey,

 These pad settings are broken. All the pins of each peripheral should not 
 always
 have the same pad settings. E.g., UART input pins should have their pull-up
 enabled in order to avoid spurious character input if these pins are left
 floating from time to time. The same applies to eCSPI.

I'm not going to comment on the quality of the pad settings, but since
MX51 arrived in any kernel these have been the pad settings for *all*
MX51, MX53, MX6 boards and in the case of MX6 are applied in U-Boot
right now for example on mx6qsabrelite if not the others too. These
settings are in device trees now, too.

If you want to correct years of reliable operation in U-Boot, go
ahead, and fix Linux while you're at it. I'm just porting the status
quo.

-- 
Matt Sealey m...@genesi-usa.com
Product Development Analyst, Genesi USA, Inc.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] mx5: Add default pin initializers

[Matt Sealey]

On Tue, Aug 14, 2012 at 10:46 AM, Benoît Thébaudeau
benoit.thebaud...@advansee.com wrote:
 Create default pin initialization functions for the default iomux function
 assignments of the main peripherals.

 Signed-off-by: Benoît Thébaudeau benoit.thebaud...@advansee.com
 Cc: Stefano Babic sba...@denx.de
 ---
  .../arch/arm/cpu/armv7/mx5/soc.c   |  139 
 
  .../arch/arm/include/asm/arch-mx5/sys_proto.h  |5 +
  2 files changed, 144 insertions(+)

 diff --git u-boot-4d3c95f.orig/arch/arm/cpu/armv7/mx5/soc.c 
 u-boot-4d3c95f/arch/arm/cpu/armv7/mx5/soc.c
 index 3f5a4f7..ee19b54 100644
 --- u-boot-4d3c95f.orig/arch/arm/cpu/armv7/mx5/soc.c
 +++ u-boot-4d3c95f/arch/arm/cpu/armv7/mx5/soc.c
 @@ -25,6 +25,8 @@

  #include common.h
  #include asm/arch/imx-regs.h
 +#include asm/arch/mx5x_pins.h
 +#include asm/arch/iomux.h
  #include asm/arch/clock.h
  #include asm/arch/sys_proto.h

 @@ -71,6 +73,143 @@ u32 get_cpu_rev(void)
 return system_rev;
  }

 +#ifdef CONFIG_MXC_UART
 +#if CONFIG_MXC_UART_BASE == UART1_BASE
 +#ifdef CONFIG_MX51
 +void mx51_uart1_init_pins(void)
 +{
 +   int in_pad, out_pad;
 +
 +   /* Set up pins for UART1. */
 +   mxc_request_iomux(MX51_PIN_UART1_RXD, IOMUX_CONFIG_ALT0);
 +   mxc_request_iomux(MX51_PIN_UART1_TXD, IOMUX_CONFIG_ALT0);
 +   mxc_request_iomux(MX51_PIN_UART1_RTS, IOMUX_CONFIG_ALT0);
 +   mxc_request_iomux(MX51_PIN_UART1_CTS, IOMUX_CONFIG_ALT0);
 +
 +   mxc_iomux_set_input(MX51_UART1_IPP_UART_RXD_MUX_SELECT_INPUT,
 +   INPUT_CTL_PATH0);
 +   mxc_iomux_set_input(MX51_UART1_IPP_UART_RTS_B_SELECT_INPUT,
 +   INPUT_CTL_PATH0);
 +
 +   in_pad = PAD_CTL_HYS_ENABLE | PAD_CTL_PKE_ENABLE | PAD_CTL_PUE_PULL |
 +   PAD_CTL_100K_PU | PAD_CTL_ODE_OPENDRAIN_NONE |
 +   PAD_CTL_DRV_HIGH | PAD_CTL_SRE_SLOW;
 +   out_pad = PAD_CTL_HYS_NONE | PAD_CTL_PKE_NONE |
 +   PAD_CTL_ODE_OPENDRAIN_NONE | PAD_CTL_DRV_HIGH |
 +   PAD_CTL_SRE_SLOW;

If we're nitpicking - none of the UART1_* pads on MX51 have valid ODE
bits, it's a reserved area. Even though you're setting it to 0 here,
including it in the pad settings is bad behavior.

-- 
Matt Sealey m...@genesi-usa.com
Product Development Analyst, Genesi USA, Inc.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/4] efikamx: update to Efika MX Smarttop and Smartbook boards

[Matt Sealey]

On Fri, Aug 17, 2012 at 2:29 PM, Benoît Thébaudeau
benoit.thebaud...@advansee.com wrote:
 Dear Matt Sealey,

 * Use iomux-mx51.h include to simplify board configuration.
 * Remove LED toggle function as it had no real users.
 * Red LED is now on for pre-reloc, Blue LED for in U-Boot
 * Function renames for readability.
 * Some board identification string changes
 * Reduce CPU core voltage to 1.1V (per TO3 spec)
 * Implicitly remove support for TO2 boards

 These are many unrelated changes that could be split.

Could be, but they're not going to be, the reasoning behind it being
that it increases work for us to test each individual patch works in
any particular order it may be committed to any tree, and increases
work for patch maintainers whereby there are too many inter-dependent
changes, extra fuzz, rebasing etc. which is just totally needless. In
essence this is a cleanup patch intended to get rid of some things
that made absolutely no sense but have persisted upstream for the
longest time. It also ports to iomux-mx51.h as previously sent since
that helps a lot on cleanup.

We tested every single part of this as a unit internally over 10
weeks, what's being sent to the list is the result. What isn't in the
patch (or more accurately, what got removed) was code that would make
more of a mess for very little functionality, code that was repeated
or overcomplicated for no good reason (led setup for example) or was
over-abstracted.

What went in to the process was the old code: functionality was tested
and verified against expectations. What you get from the new code:
almost exactly the same behavior (actually it works a little better as
some redundant things were removed).

The sign-off is not just me hitting -s on my git command line, it's
my explicit assurance that this is highly tested code that I am
willing to maintain and answer questions on. Marex has been asking me
to submit it for a long, long time and I refused because we were still
going through QA; that got finished, to a level I am happy with at
least (still a few weird things happening but they existed with the
old code too). However, QA got done, and the result is clear, and
splitting it up means going through QA again just to respin patches,
so I'm going to refuse on that basis alone. If we just consider it a
cleanup patch for the board and a reasonable example of the benefits
of the new iomux model code, does that make it easier to accept?

 Signed-off-by: Matt Sealey m...@genesi-usa.com

[snip]

 + MX51_PAD_CSPI1_SS1__GPIO4_25,
 + MX51_PAD_GPIO1_6__GPIO1_6,
 +};

 Why don't you merge all these pad settings to a single board pad array, with a
 single call to imx_iomux_v3_setup_multiple_pads()?

That has been done before (it was the way we did it in our ancient
Linux kernels, it was the way Freescale did it in their ancient Linux
kernels). We feel a huge board-specific array is hard to maintain and
ugly to read, and the few differences would end up in tiny, separate
arrays anyway. The U-Boot code was written that way in the first
place, it made a lot of sense to keep the status quo for now. My
preferred solution would be to split each part into a seperate source
file and call them from the board file (as efikamx-usb.c is done now,
but for MMC, ATA too) where such code would clean up the main board
file significantly, but I think that would be too big a change for a
lot of people. We can perform a more egregious cleanup later.

-- 
Matt Sealey m...@genesi-usa.com
Product Development Analyst, Genesi USA, Inc.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] mx5: add iomux-mx51.h include

[Matt Sealey]

On Fri, Aug 17, 2012 at 2:35 PM, Benoît Thébaudeau
benoit.thebaud...@advansee.com wrote:
 Dear Matt Sealey,

 If you want to correct years of reliable operation in U-Boot, go
 ahead, and fix Linux while you're at it. I'm just porting the status
 quo.

 I'm just saying that from experience. I've already seen issues related to that
 kind of things.

And I agree with you on the electrical aspect of it.

However our initial goal here is;

* port the code from Linux so it matches the implementation in U-Boot for i.MX6
* if we can get away with not changing the behavior or pad settings
(i.e. old config and iomux-mx51 config are identical), leave it that
way for now as this has a very long-lived legacy

It was important from our testing on Efika MX boards that if we used
the iomux-mx51 pad that it worked, and where possible it was NOT
different to the one in the old code. For UART the pad settings are
identical to the old board-file setup method (the same one you removed
in your patch). For ATA pads, there are differences, but those drive
strength changes were simply for extremely old boards that don't boot
with mainline U-Boot anymore. It would not make any difference to add
the NEW_PAD_CTRL() functionality to those pads and preserve the
settings but it doesn't make any sense to us.

So, in terms of just porting to the new framework, we got lucky in
that the broken UART pad settings are and have been broken and we
didn't write the code so we're throwing our hands in the air - not our
problem. That said, I will gladly write a patch to copy your UART and
SPI RX/TX setting differences into the new file (minus the redundant
ODE setting which has zero effect and is a waste of space), and test
that next week, and modify our Linux device tree to match, and test
that, before any other boards port to the new iomux-mx51 file or MX53
boards appear recreating the effect. For now, configuring UART the
same as it was configured before, the same as it was configured on
EVK, SabreLite etc. seems reasonable to me.

If we went through and tested every pad to the best of our ability
we'd be here for months cross-referencing the manual. I did spend
significant time checking this with JTAG with the board halted and
confirmed all the settings, which is why I nitpicked the re-setting of
those particular MUX_MODE, but if you are right (and you are) then
these pads need fixing anyway so changing them from their POR defaults
to more reliable settings is worthwhile.

So far I am confident that nothing is so different that it will cause
the end of the world or a burned board (or I'd have a stack of burned
boards on my desk with broken UART). We did notice that in moving to
the new iomux-mx51 file and porting the code, despite the exact same
pad settings, we get more reliable serial output (a... on serial
between reboots goes away, so yes, we noticed the effect you're
talking about, but it was only a minor inconvenience). I don't know if
this is due to more efficient pad setting code or not, but it's
certainly not reproducible for us at this moment.

-- 
Matt Sealey m...@genesi-usa.com
Product Development Analyst, Genesi USA, Inc.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] mx5: Add default pin initializers

[Matt Sealey]

On Fri, Aug 17, 2012 at 3:25 PM, Stefano Babic sba...@denx.de wrote:
 On 14/08/2012 17:46, Benoît Thébaudeau wrote:
 Create default pin initialization functions for the default iomux function
 assignments of the main peripherals.

 Signed-off-by: Benoît Thébaudeau benoit.thebaud...@advansee.com
 Cc: Stefano Babic sba...@denx.de
 ---

 I think that setting each pin with mxc_request_iomux() is not a great
 idea. Maybe another solution would be to provide a table with the pinmux
 for the whole SOC and a funtion to set all of them, as
 imx_iomux_v3_setup_multiple_pads. This is also similar to the current
 implementation in u-boot for other SOCs, for example TI.

Done and submitted for MX51 - and Efika MX is ported and through QA.
Can you review?

Benoit has some valid suggestions for changes, which can come later,
but for now moving to that for MX51 boards should be a net zero
difference for all implemented boards. I don't have space on my desk
to fire up my MX53 Quickstart or EVK to test those, but porting the
files for MX53 from Linux should not be a big deal and further
combining the 3 implementations differences (moving GPIO_NUMBER to
imx-common/iomux-v3.h instead of it being SoC-specific for example) is
something that would better be done once everything's in and working.

-- 
Matt Sealey m...@genesi-usa.com
Product Development Analyst, Genesi USA, Inc.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/4] efikamx: remove drive strength hack from early_init_f and move it to the DCD

[Matt Sealey]

On Fri, Aug 17, 2012 at 4:03 PM, Marek Vasut ma...@denx.de wrote:
 Dear Matt Sealey,

 The i.MX Boot ROM lets us set up certain registers before U-Boot even gets
 executed. Rather than setting up DDR, putting U-Boot in place, and getting
 into pre-relocation init to set up DDR again, just do it once in the
 correct place. This also solves an issue where the Smarttop DDR pad
 settings were being applied on Smartbook.

 While we're at it, configure PCBID0,1,2 and the LED GPIO since we've still
 got room in the DCD to do so.

 [...]

 diff --git a/board/genesi/mx51_efikamx/imximage_mx.cfg
 b/board/genesi/mx51_efikamx/imximage_mx.cfg index 6fe0ff9..ac9aa9a 100644
 --- a/board/genesi/mx51_efikamx/imximage_mx.cfg
 +++ b/board/genesi/mx51_efikamx/imximage_mx.cfg
 @@ -1,7 +1,7 @@
  #
 +# Copyright (C) 2009 Pegatron Corporation
  # Copyright (C) 2010 Marek Vasut marek.va...@gmail.com
 -#
 -# BASED ON: imx51evk

 Adding and removing these at will won't work I'm afraid.

 +# Copyright (C) 2009-2012 Genesi USA, Inc.
  #
  # (C) Copyright 2009
  # Stefano Babic DENX Software Engineering sba...@denx.de.
 @@ -43,48 +43,44 @@ BOOT_FROM spi
  #Address   absolute address of the register
  #value value to be stored in the register

 So what is the actual change in the file? You replaced it with different file,
 which makes it hard to review particular changes made.

Uhh no I edited each line manually and moved the comments to make it
more readable. The actual changes is I reviewed the drive strength set
function in efikamx.c and moved all the settings (minus any
erroneously set bits and reproduced settings) into the DATA lines
where necessary.

It's the same file but git doesn't do line-by-line diffs very well, it
just seems to batch things into sections. I agree though I broke the
copyright stuff, I got forced to use vim for about 10 minutes and I
may have been a little heavy-handed :)

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

Re: [U-Boot] [PATCH 3/4] efikamx: update to Efika MX Smarttop and Smartbook boards

[Matt Sealey]

On Fri, Aug 17, 2012 at 4:07 PM, Marek Vasut ma...@denx.de wrote:
 Dear Matt Sealey,

 Change summary:

 This patch does multiple unrelated changes, please split. You basically 
 outlined
 how this should be split.

 * Use iomux-mx51.h include to simplify board configuration.
 * Remove LED toggle function as it had no real users.
 * Red LED is now on for pre-reloc, Blue LED for in U-Boot
 * Function renames for readability.
 * Some board identification string changes
 * Reduce CPU core voltage to 1.1V (per TO3 spec)
 * Implicitly remove support for TO2 boards

 There are TO2 baords out there, debian people do have some. Please do not 
 remove
 this.

The code I checked out from git master a week ago doesn't boot for
precisely the same reason on TO2 r1.1 or r1.2 boards, so nothing
changed here in real life. The TO2 code can't pass QA so it's been
removed. Welcome to the wonderful world of commercial software
development.

-- 
Matt Sealey m...@genesi-usa.com
Product Development Analyst, Genesi USA, Inc.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/4] efikamx: move efikamx into a new directory in preparation for new boards

[Matt Sealey]

On Fri, Aug 17, 2012 at 4:01 PM, Marek Vasut ma...@denx.de wrote:
 Dear Matt Sealey,

 * Move Efika MX boards into genesi directory.
 * Rename it to mx51_efikamx since there's an mx53 version out there.

 Signed-off-by: Matt Sealey m...@genesi-usa.com
 [...]

 git format-patch -M -C will not generate such a huge patch. Please use that 
 and
 resent after Stefano reviews.

Waiting for review, then.

-- 
Matt Sealey m...@genesi-usa.com
Product Development Analyst, Genesi USA, Inc.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] mx5: Use default pin initializers

[Matt Sealey]

I'm gonna NACK this because most of these pin settings are actually
the POR defaults anyway (UART1 is
the example I can easily pick out).

.. unless someone's setting them up wrong between warn reboots, or
changing a UART into something else
later in boot.. which is unfathomable.. we don't need to even touch
the iomux controller to get a working UART
on MX51, Efika MX or anything.

Why bother touching them?

-- 
Matt Sealey m...@genesi-usa.com
Product Development Analyst, Genesi USA, Inc.


On Tue, Aug 14, 2012 at 10:47 AM, Benoît Thébaudeau
benoit.thebaud...@advansee.com wrote:
 Use the newly created mx5 default pin initialization functions in mx5 board
 files.

 Signed-off-by: Benoît Thébaudeau benoit.thebaud...@advansee.com
 Cc: Stefano Babic sba...@denx.de
 ---
  .../board/efikamx/efikamx.c|  133 
 ++--
  .../board/freescale/mx51evk/mx51evk.c  |  121 +-
  .../board/ttcontrol/vision2/vision2.c  |   72 +--
  3 files changed, 15 insertions(+), 311 deletions(-)

 diff --git u-boot-4d3c95f.orig/board/efikamx/efikamx.c 
 u-boot-4d3c95f/board/efikamx/efikamx.c
 index e88b2ed..6810433 100644
 --- u-boot-4d3c95f.orig/board/efikamx/efikamx.c
 +++ u-boot-4d3c95f/board/efikamx/efikamx.c
 @@ -143,38 +143,12 @@ int dram_init(void)
  }

  /*
 - * UART configuration
 - */
 -static void setup_iomux_uart(void)
 -{
 -   unsigned int pad = PAD_CTL_HYS_ENABLE | PAD_CTL_PKE_ENABLE |
 -   PAD_CTL_PUE_PULL | PAD_CTL_DRV_HIGH;
 -
 -   mxc_request_iomux(MX51_PIN_UART1_RXD, IOMUX_CONFIG_ALT0);
 -   mxc_iomux_set_pad(MX51_PIN_UART1_RXD, pad | PAD_CTL_SRE_FAST);
 -   mxc_request_iomux(MX51_PIN_UART1_TXD, IOMUX_CONFIG_ALT0);
 -   mxc_iomux_set_pad(MX51_PIN_UART1_TXD, pad | PAD_CTL_SRE_FAST);
 -   mxc_request_iomux(MX51_PIN_UART1_RTS, IOMUX_CONFIG_ALT0);
 -   mxc_iomux_set_pad(MX51_PIN_UART1_RTS, pad);
 -   mxc_request_iomux(MX51_PIN_UART1_CTS, IOMUX_CONFIG_ALT0);
 -   mxc_iomux_set_pad(MX51_PIN_UART1_CTS, pad);
 -}
 -
 -/*
   * SPI configuration
   */
  #ifdef CONFIG_MXC_SPI
  static void setup_iomux_spi(void)
  {
 -   /* 000: Select mux mode: ALT0 mux port: MOSI of instance: ecspi1 */
 -   mxc_request_iomux(MX51_PIN_CSPI1_MOSI, IOMUX_CONFIG_ALT0);
 -   mxc_iomux_set_pad(MX51_PIN_CSPI1_MOSI,
 -   PAD_CTL_HYS_ENABLE | PAD_CTL_DRV_HIGH | PAD_CTL_SRE_FAST);
 -
 -   /* 000: Select mux mode: ALT0 mux port: MISO of instance: ecspi1. */
 -   mxc_request_iomux(MX51_PIN_CSPI1_MISO, IOMUX_CONFIG_ALT0);
 -   mxc_iomux_set_pad(MX51_PIN_CSPI1_MISO,
 -   PAD_CTL_HYS_ENABLE | PAD_CTL_DRV_HIGH | PAD_CTL_SRE_FAST);
 +   mx51_ecspi1_init_pins();

 /* Configure SS0 as a GPIO */
 mxc_request_iomux(MX51_PIN_CSPI1_SS0, IOMUX_CONFIG_GPIO);
 @@ -183,16 +157,6 @@ static void setup_iomux_spi(void)
 /* Configure SS1 as a GPIO */
 mxc_request_iomux(MX51_PIN_CSPI1_SS1, IOMUX_CONFIG_GPIO);
 gpio_direction_output(IOMUX_TO_GPIO(MX51_PIN_CSPI1_SS1), 1);
 -
 -   /* 000: Select mux mode: ALT0 mux port: SS2 of instance: ecspi1. */
 -   mxc_request_iomux(MX51_PIN_CSPI1_RDY, IOMUX_CONFIG_ALT0);
 -   mxc_iomux_set_pad(MX51_PIN_CSPI1_RDY,
 -   PAD_CTL_HYS_ENABLE | PAD_CTL_PKE_ENABLE);
 -
 -   /* 000: Select mux mode: ALT0 mux port: SCLK of instance: ecspi1. */
 -   mxc_request_iomux(MX51_PIN_CSPI1_SCLK, IOMUX_CONFIG_ALT0);
 -   mxc_iomux_set_pad(MX51_PIN_CSPI1_SCLK,
 -   PAD_CTL_HYS_ENABLE | PAD_CTL_DRV_HIGH | PAD_CTL_SRE_FAST);
  }
  #else
  static inline void setup_iomux_spi(void) { }
 @@ -333,7 +297,12 @@ int board_mmc_init(bd_t *bis)
 int ret;
 uint32_t cd = efika_mmc_cd();

 -   /* SDHC1 is used on all revisions, setup control pins first */
 +   /* SDHC1 is used on all revisions */
 +
 +   /* SDHC1 IOMUX */
 +   mx51_esdhc1_init_pins();
 +
 +   /* SDHC1 Control lines IOMUX */
 mxc_request_iomux(cd,
 IOMUX_CONFIG_ALT0 | IOMUX_CONFIG_SION);
 mxc_iomux_set_pad(cd,
 @@ -354,65 +323,8 @@ int board_mmc_init(bd_t *bis)
 /* Internal SDHC1 IOMUX + SDHC2 IOMUX on old boards */
 if (machine_is_efikasb() || (machine_is_efikamx() 
 (get_efika_rev()  EFIKAMX_BOARD_REV_12))) {
 -   /* SDHC1 IOMUX */
 -   mxc_request_iomux(MX51_PIN_SD1_CMD,
 -   IOMUX_CONFIG_ALT0 | IOMUX_CONFIG_SION);
 -   mxc_iomux_set_pad(MX51_PIN_SD1_CMD,
 -   PAD_CTL_PUE_KEEPER | PAD_CTL_PKE_ENABLE |
 -   PAD_CTL_DRV_HIGH | PAD_CTL_47K_PU | PAD_CTL_SRE_FAST);
 -
 -   mxc_request_iomux(MX51_PIN_SD1_CLK,
 -   IOMUX_CONFIG_ALT0 | IOMUX_CONFIG_SION);
 -   mxc_iomux_set_pad(MX51_PIN_SD1_CLK,
 -   PAD_CTL_PUE_KEEPER | PAD_CTL_PKE_ENABLE |
 -   PAD_CTL_DRV_HIGH

Re: [U-Boot] [PATCH 2/2] mx5: Use default pin initializers

[Matt Sealey]

On Thu, Aug 16, 2012 at 3:09 PM, Benoît Thébaudeau
benoit.thebaud...@advansee.com wrote:
 Dear Matt Sealey,

 I'm gonna NACK this because most of these pin settings are actually
 the POR defaults anyway (UART1 is
 the example I can easily pick out).

 .. unless someone's setting them up wrong between warn reboots, or
 changing a UART into something else
 later in boot.. which is unfathomable.. we don't need to even touch
 the iomux controller to get a working UART
 on MX51, Efika MX or anything.

 Why bother touching them?

 I agree, but the purpose of this patch is not to add this code, only to move 
 it
 to a common place... Why didn't you NAK the addition of these boards because 
 of
 that?

Why bother changing it in the first place if it's already doing the
same thing? :)

I have a MAJOR nit that is going to ruin your day; this is from
mx51_uart1_init_pins, just one line:

 mxc_request_iomux(MX51_PIN_UART1_RXD, IOMUX_CONFIG_ALT0);

Why are you using the old mxc_request_iomux model, when MX6 and
Sabrelite for example uses the newer iomux_v3_configure_pad model?

Surely someone should be thinking of putting that into place for MX51
and MX53 first so these pin init things can be done on the newer one.
I already ported 2012.07 for Efika MX and have an include (Troy
Kisky's got a copy of it too, we sent it there hoping for a little
review but he doesn't have our board to test IIRC) and a working tree.

What's stopping us submitting this already? Churn. Also, we thought we
could get away with U-Boot doing the grunt work of configuring pins
where needed, and the Linux DT guys vetoed it in favor of needlessly
reconfiguring the pins U-Boot already set up by redefining them for
reconfiguration in the DT anyway - I would have hoped we could avoid
that, and as such our U-Boot tree internally does a LOT of iomux setup
that U-Boot doesn't even drive (audio clock enables, amplifier, i2c..)
on our board. I need to cut that down a little bit.

 This kind of code is present in all i.MX board files. If it is useful, it's
 better to have it merged rather than duplicated.

See above :)

For i.MX we have two iomux models and function sets available for
doing identical stuff. Isn't that kind of wasteful?

 If you NAK this, following your rationale, it means that you prefer to have
 useless duplicated code everywhere rather than in a single location.

I'd prefer to have useless code removed, rather than just moved.

 doesn't make any sense. Or are you suggesting to remove this code from all
 boards instead? Was there a good reason for this code to be there in the first
 place?

No, there was never a good reason for it. It's there because whoever
wrote the very, very original code in the first place (Pegatron)
didn't read the docs properly and just set everything up regardless of
whether it was already set up, then whoever put the Efika MX support
in mainline didn't read the docs either and just reformatted what was
there in our source release and/or read the schematics without fact
checking.

It's a hideous legacy being perpetuated here. I am fully in favor of
you leaving Efika MX out to languish in the deep dark recesses of
boards that might compile but are basically doing weird stuff, and
nobody uses anyway, until we work out the situation to actually
support the board 100% in the most efficient way possible.

I'll throw a patchset out to add the iomux-mx51.h file (with all the
pins Efika MX needs at least. I had a little chat with Troy at BD and
he suggested people should add pins per board where needed and not
just copy the entire set from the Linux code if possible) sometime end
of week or next week, and maybe we can revisit these patches. I've
been concentrating on the Linux side and didn't think this new driver
model/code cleanup nightmare would happen at the same time as the
Linux board removal/wholesale DT switch.

Marek; I realise it's just an opinion, which I feel as the maintainer
of this platform (not for U-Boot in terms of custodian status, but in
terms of who at Genesi has the responsibility to keep track of this
stuff) I should express and I feel it would be remiss of me if I did
not. Who's the custodian of the Efika MX stuff anyway? Does it just
default to Stefano, or is it you as the committer?

As for problems during reboots, well, unsupported configurations are
unsupported configurations. If your kernel muxes out DIFFERENT pins to
U-Boot, expect U-Boot to burn the board. As it stands, the old
linux-legacy kernels don't make too heavy a set of changes (maybe
just drive strength and hysteresis stuff that is totally pointless).
If you boot U-Boot from POR and then boot a DT linux kernel, it'll all
be exactly the same on every reboot. Boot an old kernel and it'll
still work. You can't be too careful here, and by that I mean, you
can't keep reconfiguring the chip just because you think there may be
the possibility of some idiot doing something wrong. This isn't
something that is burned into the chip

[U-Boot] Testing report for i.MX51 using Linaro/Ubuntu gcc 4.6.3 (from Precise repositories), libgcc, etc.

[Matt Sealey]

Marek Vasut insists I report this to the list, so here goes;

Compiling a U-Boot for i.MX51 here (for the Efika MX) basically
doesn't operate well. Among other things, we got data aborts in
several places, most annoyingly sometime after boot_relocate_fdt. This
was using a 64-bit Ubuntu Precise Pangolin (12.04) installation, the
standard arm-linux-gnueabi-gcc-4.6 (4.6.3-1ubuntu5) compiler and
other toolchain components (no modifications made).

Using USE_PRIVATE_LIBGCC=yes solved the issues, as did changing to the
gcc 4.4.7 (4.4.7-1ubuntu2) and using either private libgcc or the one
provided by the toolchain.

This is not the first problem we've ever had with the Linaro gcc
toolchain, especially not with 4.6. So far, reverting to building
using gcc 4.4.7 has solved all the problems, and we're using
USE_PRIVATE_LIBGCC by default now anyway because I don't see the point
in using the one provided with the toolchain if it is such a huge
unknown and U-Boot provides a compatible feature anyway.

I'm not sure what anyone on the list is going to make of this or if it
influences some design decisions anywhere else in U-Boot, just that I
was nagged incessantly to report my findings - we all knew the
Linaro compiler generally sucks already, though, right?

-- 
Matt Sealey m...@genesi-usa.com
Product Development Analyst, Genesi USA, Inc.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] dtc/u-boot tool naming, ftdump, mkimage

[Matt Sealey]

I just noticed (was told by an affiliate) that the DTC compiler tools 
shares a tool name ftdump with the Freetype project. I was doing a 
lazy packaging effort to get a few tools around so we can all be running 
the same version and build some custom kernel RPMs, and this came up.

Wouldn't a better name be fdtdump, do you think? It's usually not a 
fun idea to conflict with tools already on the system. A user may run 
ftdump and get the Freetype tool because of a simple mistake in paths 
or so.

With regards to U-Boot proper, I would say the same is true of mkimage 
which conflicts with jigdo. In essence, while U-Boot is usually 
installed into a user's home directory (~/bin etc.) simple path mixups, 
going to root shell, using another box etc. means you may have multiple 
same-named tools on a system for various work, which do different things.

Is it possible that we could standardize on some tool naming here?

I'm going to rename in the package these tools to mkuimage (since this 
goes well with suse mkzimage) and fdtdump for my package anyway so no 
worries if nothing ever gets done.. but since the Fedora guys were 
packaging dtc up right now I thought I would mention this as the RPM I 
downloaded from FC10 the other day did not take note of this (and RPM 
warns that there is a conflict but happily overwrites the file anyway, 
thus trashing Freetype :)

(why am I packaging U-Boot tools like mkimage? We need them for 
post-install script on a kernel RPM..)

--
Matt Sealey
Genesi, Manager, Developer Relations
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] dtc/u-boot tool naming, ftdump, mkimage

[Matt Sealey]

Josh Boyer wrote:
 On Wed, Jan 14, 2009 at 11:57:42AM -0600, Matt Sealey wrote:
 I just noticed (was told by an affiliate) that the DTC compiler tools  
 shares a tool name ftdump with the Freetype project. I was doing a  
 lazy packaging effort to get a few tools around so we can all be running  
 the same version and build some custom kernel RPMs, and this came up.

 Wouldn't a better name be fdtdump, do you think? It's usually not a  
 fun idea to conflict with tools already on the system. A user may run  
 ftdump and get the Freetype tool because of a simple mistake in paths  
 or so.

 With regards to U-Boot proper, I would say the same is true of mkimage  
 which conflicts with jigdo. In essence, while U-Boot is usually  
 installed into a user's home directory (~/bin etc.) simple path mixups,  
 going to root shell, using another box etc. means you may have multiple  
 same-named tools on a system for various work, which do different things.

 Is it possible that we could standardize on some tool naming here?

 I'm going to rename in the package these tools to mkuimage (since this  
 goes well with suse mkzimage) and fdtdump for my package anyway so no  
 worries if nothing ever gets done.. but since the Fedora guys were  
 packaging dtc up right now I thought I would mention this as the RPM I  
 downloaded from FC10 the other day did not take note of this (and RPM  
 warns that there is a conflict but happily overwrites the file anyway,  
 thus trashing Freetype :)
 
 The Fedora package doesn't install ftdump.  Where did you get the package
 from?

Fedora website. I *did* modify it a tad because I actually use ftdump to 
verify the content of the device trees I'm booting :)

However if anyone ever did want it, and you put it in your RPM, you'd 
need to change the name. Sorry I wasn't so clear, but I think it would 
be good behaviour if U-Boot or DTC or any other app (I can probably 
come up with some decent examples) did not use rather generic tool names 
which walk all over other tool names potentially on a system :)

 (why am I packaging U-Boot tools like mkimage? We need them for  
 post-install script on a kernel RPM..)
 
 I tried to get it included in the kernel tarball.  It didn't get
 very far because Sam was too busy to really reply.

That would be nice but it would never help me. I have to run the SUSE 
kernel of the last release, which right now is 2.6.27.7 - any efforts to 
get it in that have happened in the previous 6 months would have been 
missed by the time SUSE standardized :(

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

Re: [U-Boot] dtc/u-boot tool naming, ftdump, mkimage

[Matt Sealey]

Josh Boyer wrote:

 David has said before that ftdump is sort of a pointless debugging tool.
 Or at least that is what the Debian bug report referrenced as the reason
 from removing it from the Debian dtc package.

As long as you have the original device tree source code to hand. I tend 
to find that the guy who sent me the device tree and kernel for me to 
test, has gone to bed and will not be back for 8 to 10 hours. Rather 
than hang around, on the event that I think it's a device tree problem I 
tend to ftdump to see what's going on.

It might have some use somewhere someday, but yeah.. I guess.. bringing 
it out from a build into a package is kind of a dumb idea.

 Maybe we should just remove it entirely if it's not really going to be
 maintained long-term.

Up to you.

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

Re: [U-Boot] Building tools without building firmware

[Matt Sealey]

Mike Frysinger wrote:
 On Tuesday 11 November 2008 15:15:09 Matt Sealey wrote:
 We have a need to build and package at the very least 'mkimage' for SuSE
 11.1 and since we have multiple board targets in mind (MPC8641D, MPC8610,
 MPC5121e) it does not make any sense to pick any in particular or build the
 entire u-boot.bin just for a few kilobytes we need to prep kernels and
 initrd images.

 Is it possible to simply build the tools/ directory (a make target that
 works would be great) without building a firmware from BLAH_config first?
 
 you can see the method we use in Gentoo here:
 http://sources.gentoo.org/dev-embedded/u-boot-tools/

Ouch.

 but i'd agree that i wish it were easier to just build the helper utilities.  
 and if they werent so tightly intertwined with the rest of the u-boot code 
 ... 
 atm you cant build mkimage on a non-Linux system due to the libfdt stuff.

Am I reading this right.. I'm using SUSE 11.0 here so I guess I do

touch include/config.h include/config.mk
make HOSTSTRIP=echo BIN_FILES=mkimage

And that'd do it? I'll have to check it out later..

-- 
Matt Sealey [EMAIL PROTECTED]
Genesi, Manager, Developer Relations
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Building tools without building firmware

[Matt Sealey]

We have a need to build and package at the very least 'mkimage' for SuSE 11.1
and since we have multiple board targets in mind (MPC8641D, MPC8610, MPC5121e)
it does not make any sense to pick any in particular or build the entire
u-boot.bin just for a few kilobytes we need to prep kernels and initrd
images.

Is it possible to simply build the tools/ directory (a make target that works
would be great) without building a firmware from BLAH_config first?

-- 
Matt Sealey [EMAIL PROTECTED]
Genesi, Manager, Developer Relations
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot