date:20120418

Re: [U-Boot] [PATCH] PowerPC: Change -fpic flag to -fPIC flag in the config.mk

2012-04-18 Thread Wolfgang Denk

Dear Chunhe Lan,

In message 1334719161-3500-1-git-send-email-chunhe@freescale.com you 
wrote:
 The -fPIC/-fpic flag belongs with -mrelocatable. The -fpic flag can
 limit the size of the GOT and produce smaller binaries, so it causes
 some GOT entries to be lost in the gcc 4.6 version. But -fPIC flag
 allows the maximum possible size of the GOT entries.
 
 However, currently -mrelocatable promotes -fpic flag to -fPIC flag.
 
 This reverts that portion of the
 commit 33ee4c92339ee386662c0ee2d221098c5cc8b07e.

As you state yourself, your modification has the negative impact of
increasing the image size.  What would be the benefits of it?

Are you trying to fix any specific problem? Which one?  I am not aware
of any related isses for any of the mainline PowerPC systems...

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
If ignorance is bliss, why aren't there more happy people?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] i.MX28: Shut down the LCD controller before reset

2012-04-18 Thread Wolfgang Denk

Dear Marek Vasut,

In message 1334673527-27361-1-git-send-email-ma...@denx.de you wrote:
 If the LCD controller is on before the CPU goes into reset, the traffic on 
 LCDIF
 data pins interferes with the BootROM's boot mode sampling. So shut the
 controller down.
 
 Signed-off-by: Marek Vasut ma...@denx.de
 Cc: Wolfgang Denk w...@denx.de
 Cc: Detlev Zundel d...@denx.de
 Cc: Stefano Babic sba...@denx.de
 Cc: Fabio Estevam feste...@gmail.com
 ---
  arch/arm/cpu/arm926ejs/mx28/mx28.c |9 -
  1 file changed, 8 insertions(+), 1 deletion(-)

Tested-by: Wolfgang Denk w...@denx.de
Acked-by: Wolfgang Denk w...@denx.de


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
If you believe that feeling bad or worrying long enough will change a
past or future event, then you are residing on another planet with  a
different reality system.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] PowerPC: Change -fpic flag to -fPIC flag in the config.mk

2012-04-18 Thread Wolfgang Denk

Dear Chunhe Lan,

In message 4f8e5f11.4020...@freescale.com you wrote:
 !DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN
 html
 head
   meta content=3Dtext/html;charset=3DUTF-8 http-equiv=3DContent-Type=

Message unreadable, ignored.  Please post plain text only.


Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
I have the simplest tastes.  I am always satisfied with the best.
   -- Oscar Wilde
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] mmc:fix Call mmc_init() when executing mmc_get_dev()

2012-04-18 Thread Lukasz Majewski

Hi, Minkyu

 Hi Lukasz,
 
 On 3 April 2012 23:24, Lukasz Majewski l.majew...@samsung.com wrote:
  This code adds call to mmc_init(), for partition related commands
  (e.g. fatls, fatinfo etc.).
 
  It is safe to call mmc_init() multiple times since mmc-has_init
  flag prevents from multiple initialization.
 
  The FAT related code calls get_dev high level method and then uses
  elements from mmc-block_dev, which is uninitialized until the
  mmc_init (and thereof mmc_startup) is called.
 
  This problem appears on boards, which don't use mmc as the default
  place for envs
 
  Signed-off-by: Lukasz Majewski l.majew...@samsung.com
  Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
  Cc: Andy Fleming aflem...@gmail.com
 
  ---
  Test HW:
  - GONI S5PC110
  - Universal C210 (Exynos4)
  ---
   drivers/mmc/mmc.c |    6 +-
   1 files changed, 5 insertions(+), 1 deletions(-)
 
  diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
  index 618960e..1fa90e7 100644
  --- a/drivers/mmc/mmc.c
  +++ b/drivers/mmc/mmc.c
  @@ -1305,8 +1305,12 @@ int mmc_register(struct mmc *mmc)
   block_dev_desc_t *mmc_get_dev(int dev)
   {
         struct mmc *mmc = find_mmc_device(dev);
  +       if (mmc) {
  +               mmc_init(mmc);
  +               return mmc-block_dev;
  +       }
 
  -       return mmc ? mmc-block_dev : NULL;
  +       return NULL;
   }
   #endif
 
 
 I think
 
   if (!mmc)
   return NULL;
 
   mmc_init(mmc);
   return mmc-block_dev;
 
 is better.
 How you think?

Yes, it seems also more readable for me.
But anyway Andy shall express his opinion.


-- 
Best regards,

Lukasz Majewski

Samsung Poland RD Center
Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: ea20: Change macro from BOARD_LATE_INIT to CONFIG_BOARD_LATE_INIT

2012-04-18 Thread Stefano Babic

On 18/04/2012 04:41, Nobuhiro Iwamatsu wrote:
 With almost all the architecture and board BOARD_LATE_INIT does not use.
 CONFIG_BOARD_LATE_INIT is used instead.
 This changed CONFIG_BOARD_LATE_INIT from BOARD_LATE_INIT.
 
 Signed-off-by: Nobuhiro Iwamatsu nobuhiro.iwamatsu...@renesas.com
 CC: Stefano Babic sba...@denx.de
 ---
  board/davinci/ea20/ea20.c |4 ++--
  include/configs/ea20.h|2 +-
  2 files changed, 3 insertions(+), 3 deletions(-)
 
 diff --git a/board/davinci/ea20/ea20.c b/board/davinci/ea20/ea20.c
 index 43632c2..7e00040 100644
 --- a/board/davinci/ea20/ea20.c
 +++ b/board/davinci/ea20/ea20.c
 @@ -272,7 +272,7 @@ int board_init(void)
   return 0;
  }
  
 -#ifdef BOARD_LATE_INIT
 +#ifdef CONFIG_BOARD_LATE_INIT
  
  int board_late_init(void)
  {
 @@ -287,7 +287,7 @@ int board_late_init(void)
  
   return 0;
  }
 -#endif /* BOARD_LATE_INIT */
 +#endif /* CONFIG_BOARD_LATE_INIT */
  
  #ifdef CONFIG_DRIVER_TI_EMAC
  
 diff --git a/include/configs/ea20.h b/include/configs/ea20.h
 index e059b30..2c44ddb 100644
 --- a/include/configs/ea20.h
 +++ b/include/configs/ea20.h
 @@ -31,7 +31,7 @@
  #define  CONFIG_SYS_USE_NAND
  #define CONFIG_DRIVER_TI_EMAC_USE_RMII
  #define CONFIG_BOARD_EARLY_INIT_F
 -#define BOARD_LATE_INIT
 +#define CONFIG_BOARD_LATE_INIT
  #define CONFIG_VIDEO
  #define CONFIG_PREBOOT
  

Acked-by: Stefano Babic sba...@denx.de

Thanks,
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

[U-Boot] [PATCH 0/8 v3] i.MX25: Miscellaneus fixes

2012-04-18 Thread Timo Ketola

These are the fixes I needed to do to get my board going.

Changes in v3:
- Dropped old patch number 8 imx: nand: Don't invent new...
- Changed the subject of patch 4
- Changed the BBT pattern offsets (patch 4); They are now zero
as in Linux

Changes in v2:
- Rebased to u-boot-imx next
- Patch 2: Fixed too long lines
- Patch 3: Try not to break Gbit ether
Changed configuration option putting gasket into RMII mode to CONFIG_RMII
  I'm not too sure how this should be done. CONFIG_MII is normally used for
  this but its original purpose was to enable MII *management* interface, I
  think...
- Patch 9: Add .imx target in the spirit of commit 303838


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

[U-Boot] [PATCH 1/9] i.MX25: esdhc: Add mxc_get_clock infrastructure

2012-04-18 Thread Timo Ketola

Defining CONFIG_FSL_ESDHC brings in a call to get_clocks, so let's implement 
get_clocks function. This is how it seems to be implemented elsewhere.

Signed-off-by: Timo Ketola t...@exertus.fi
---
 arch/arm/cpu/arm926ejs/mx25/generic.c  |   27 +++
 arch/arm/include/asm/arch-mx25/clock.h |   23 +++
 2 files changed, 50 insertions(+), 0 deletions(-)

diff --git a/arch/arm/cpu/arm926ejs/mx25/generic.c 
b/arch/arm/cpu/arm926ejs/mx25/generic.c
index 9cadb7c..8b07dae 100644
--- a/arch/arm/cpu/arm926ejs/mx25/generic.c
+++ b/arch/arm/cpu/arm926ejs/mx25/generic.c
@@ -28,10 +28,15 @@
 #include asm/io.h
 #include asm/arch/imx-regs.h
 #include asm/arch/imx25-pinmux.h
+#include asm/arch/clock.h
 #ifdef CONFIG_MXC_MMC
 #include asm/arch/mxcmmc.h
 #endif
 
+#ifdef CONFIG_FSL_ESDHC
+DECLARE_GLOBAL_DATA_PTR;
+#endif
+
 /*
  *  get the system pll clock in Hz
  *
@@ -105,6 +110,20 @@ ulong imx_get_perclk(int clk)
return lldiv(fref, div);
 }
 
+unsigned int mxc_get_clock(enum mxc_clock clk)
+{
+   if (clk = MXC_CLK_NUM)
+   return -1;
+   switch (clk) {
+   case MXC_ARM_CLK:
+   return imx_get_armclk();
+   case MXC_FEC_CLK:
+   return imx_get_ahbclk();
+   default:
+   return imx_get_perclk(clk);
+   }
+}
+
 u32 get_cpu_rev(void)
 {
u32 srev;
@@ -182,6 +201,14 @@ int cpu_eth_init(bd_t *bis)
 #endif
 }
 
+int get_clocks(void)
+{
+#ifdef CONFIG_FSL_ESDHC
+   gd-sdhc_clk = mxc_get_clock(MXC_ESDHC_CLK);
+#endif
+   return 0;
+}
+
 /*
  * Initializes on-chip MMC controllers.
  * to override, implement board_mmc_init()
diff --git a/arch/arm/include/asm/arch-mx25/clock.h 
b/arch/arm/include/asm/arch-mx25/clock.h
index c59f588..0f47eaf 100644
--- a/arch/arm/include/asm/arch-mx25/clock.h
+++ b/arch/arm/include/asm/arch-mx25/clock.h
@@ -26,11 +26,34 @@
 #ifndef __ASM_ARCH_CLOCK_H
 #define __ASM_ARCH_CLOCK_H
 
+enum mxc_clock {
+   MXC_CSI_CLK,
+   MXC_EPIT_CLK,
+   MXC_ESAI_CLK,
+   MXC_ESDHC1_CLK,
+   MXC_ESDHC2_CLK,
+   MXC_GPT_CLK,
+   MXC_I2C_CLK,
+   MXC_LCDC_CLK,
+   MXC_NFC_CLK,
+   MXC_OWIRE_CLK,
+   MXC_PWM_CLK,
+   MXC_SIM1_CLK,
+   MXC_SIM2_CLK,
+   MXC_SSI1_CLK,
+   MXC_SSI2_CLK,
+   MXC_UART_CLK,
+   MXC_ARM_CLK,
+   MXC_FEC_CLK,
+   MXC_CLK_NUM
+};
+
 ulong imx_get_perclk(int clk);
 ulong imx_get_ahbclk(void);
 
 #define imx_get_uartclk() imx_get_perclk(15)
 #define imx_get_fecclk() (imx_get_ahbclk()/2)
 
+unsigned int mxc_get_clock(enum mxc_clock clk);
 
 #endif /* __ASM_ARCH_CLOCK_H */
-- 
1.7.5.4

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

[U-Boot] [PATCH 2/9] i.MX25: This architecture has a GPIO4 too

2012-04-18 Thread Timo Ketola

Signed-off-by: Timo Ketola t...@exertus.fi
---
 drivers/gpio/mxc_gpio.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/gpio/mxc_gpio.c b/drivers/gpio/mxc_gpio.c
index df6..3e94ac3 100644
--- a/drivers/gpio/mxc_gpio.c
+++ b/drivers/gpio/mxc_gpio.c
@@ -40,7 +40,8 @@ static unsigned long gpio_ports[] = {
[0] = GPIO1_BASE_ADDR,
[1] = GPIO2_BASE_ADDR,
[2] = GPIO3_BASE_ADDR,
-#if defined(CONFIG_MX51) || defined(CONFIG_MX53) || defined(CONFIG_MX6Q)
+#if defined(CONFIG_MX25) || defined(CONFIG_MX51) || defined(CONFIG_MX53) || \
+   defined(CONFIG_MX6Q)
[3] = GPIO4_BASE_ADDR,
 #endif
 #if defined(CONFIG_MX53) || defined(CONFIG_MX6Q)
-- 
1.7.5.4

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

[U-Boot] [PATCH 3/9] imx: fec: Resolve speed before configuring gasket

2012-04-18 Thread Timo Ketola

Gasket needs a different configuration for 10BaseT than for higher speeds.

Signed-off-by: Timo Ketola t...@exertus.fi
---
 drivers/net/fec_mxc.c |   43 ---
 1 files changed, 24 insertions(+), 19 deletions(-)

diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
index 824a199..48a69d4 100644
--- a/drivers/net/fec_mxc.c
+++ b/drivers/net/fec_mxc.c
@@ -440,6 +440,22 @@ static int fec_open(struct eth_device *edev)
 */
writel(readl(fec-eth-ecntrl) | FEC_ECNTRL_ETHER_EN,
fec-eth-ecntrl);
+#ifdef CONFIG_PHYLIB
+   if (!fec-phydev)
+   fec_eth_phy_config(edev);
+   if (fec-phydev) {
+   /* Start up the PHY */
+   phy_startup(fec-phydev);
+   speed = fec-phydev-speed;
+   } else {
+   speed = _100BASET;
+   }
+#else
+   miiphy_wait_aneg(edev);
+   speed = miiphy_speed(edev-name, fec-phy_id);
+   miiphy_duplex(edev-name, fec-phy_id);
+#endif
+
 #if defined(CONFIG_MX25) || defined(CONFIG_MX53)
udelay(100);
/*
@@ -453,9 +469,14 @@ static int fec_open(struct eth_device *edev)
while (readw(fec-eth-miigsk_enr)  MIIGSK_ENR_READY)
udelay(2);
 
-#if !defined(CONFIG_MII)
-   /* configure gasket for RMII, 50 MHz, no loopback, and no echo */
-   writew(MIIGSK_CFGR_IF_MODE_RMII, fec-eth-miigsk_cfgr);
+#if defined(CONFIG_RMII)
+   if (speed != _10BASET)
+   /* configure gasket for RMII, 50MHz, no loopback, and no echo */
+   writew(MIIGSK_CFGR_IF_MODE_RMII, fec-eth-miigsk_cfgr);
+   else
+   /* configure gasket for RMII, 5MHz, no loopback, and no echo */
+   writew(MIIGSK_CFGR_IF_MODE_RMII | MIIGSK_CFGR_FRCONT,
+   fec-eth-miigsk_cfgr);
 #else
/* configure gasket for MII, no loopback, and no echo */
writew(MIIGSK_CFGR_IF_MODE_MII, fec-eth-miigsk_cfgr);
@@ -474,22 +495,6 @@ static int fec_open(struct eth_device *edev)
}
 #endif
 
-#ifdef CONFIG_PHYLIB
-   if (!fec-phydev)
-   fec_eth_phy_config(edev);
-   if (fec-phydev) {
-   /* Start up the PHY */
-   phy_startup(fec-phydev);
-   speed = fec-phydev-speed;
-   } else {
-   speed = _100BASET;
-   }
-#else
-   miiphy_wait_aneg(edev);
-   speed = miiphy_speed(edev-name, fec-phy_id);
-   miiphy_duplex(edev-name, fec-phy_id);
-#endif
-
 #ifdef FEC_QUIRK_ENET_MAC
{
u32 ecr = readl(fec-eth-ecntrl)  ~FEC_ECNTRL_SPEED;
-- 
1.7.5.4

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

[U-Boot] [PATCH 4/9] imx: nand: Support flash based BBT

2012-04-18 Thread Timo Ketola

Signed-off-by: Timo Ketola t...@exertus.fi
---
 drivers/mtd/nand/mxc_nand.c |   35 +++
 1 files changed, 35 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/nand/mxc_nand.c b/drivers/mtd/nand/mxc_nand.c
index 35e89a0..d97e7c3 100644
--- a/drivers/mtd/nand/mxc_nand.c
+++ b/drivers/mtd/nand/mxc_nand.c
@@ -1302,12 +1302,47 @@ static void mxc_setup_config1(void)
 #define mxc_setup_config1()
 #endif
 
+#ifdef CONFIG_SYS_NAND_USE_FLASH_BBT
+
+static u8 bbt_pattern[] = {'B', 'b', 't', '0' };
+static u8 mirror_pattern[] = {'1', 't', 'b', 'B' };
+
+static struct nand_bbt_descr bbt_main_descr = {
+   .options = NAND_BBT_LASTBLOCK | NAND_BBT_CREATE | NAND_BBT_WRITE |
+  NAND_BBT_2BIT | NAND_BBT_VERSION | NAND_BBT_PERCHIP,
+   .offs = 0,
+   .len = 4,
+   .veroffs = 4,
+   .maxblocks = 4,
+   .pattern = bbt_pattern,
+};
+
+static struct nand_bbt_descr bbt_mirror_descr = {
+   .options = NAND_BBT_LASTBLOCK | NAND_BBT_CREATE | NAND_BBT_WRITE |
+  NAND_BBT_2BIT | NAND_BBT_VERSION | NAND_BBT_PERCHIP,
+   .offs = 0,
+   .len = 4,
+   .veroffs = 4,
+   .maxblocks = 4,
+   .pattern = mirror_pattern,
+};
+
+#endif
+
 int board_nand_init(struct nand_chip *this)
 {
struct mtd_info *mtd;
uint16_t tmp;
int err = 0;
 
+#ifdef CONFIG_SYS_NAND_USE_FLASH_BBT
+
+   this-options = NAND_USE_FLASH_BBT;
+   this-bbt_td = bbt_main_descr;
+   this-bbt_md = bbt_mirror_descr;
+
+#endif
+
/* structures must be linked */
mtd = host-mtd;
mtd-priv = this;
-- 
1.7.5.4

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

[U-Boot] [PATCH 5/9] i.MX25: This architecture has almost the same USB-controller as i.MX31

2012-04-18 Thread Timo Ketola

Signed-off-by: Timo Ketola t...@exertus.fi
---
 drivers/usb/host/ehci-mxc.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/usb/host/ehci-mxc.c b/drivers/usb/host/ehci-mxc.c
index 61dbccd..65f40a4 100644
--- a/drivers/usb/host/ehci-mxc.c
+++ b/drivers/usb/host/ehci-mxc.c
@@ -125,7 +125,7 @@ int ehci_hcd_init(void)
hcor = (struct ehci_hcor *)((uint32_t) hccr +
HC_LENGTH(ehci_readl(hccr-cr_capbase)));
setbits_le32(ehci-usbmode, CM_HOST);
-#ifdef CONFIG_MX31
+#if defined(CONFIG_MX31) || defined(CONFIG_MX25)
setbits_le32(ehci-control, USB_EN);
 
__raw_writel(CONFIG_MXC_USB_PORTSC, ehci-portsc);
-- 
1.7.5.4

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

[U-Boot] [PATCH 6/9] imx: usb: There is no such register

2012-04-18 Thread Timo Ketola

The reference manual of i.MX25 (nor i.MX31) does not define such register.
This seems to access read only UH2_CAPLENGTH register (if
CONFIG_MXC_USB_PORT is zero).

Signed-off-by: Timo Ketola t...@exertus.fi
---
 drivers/usb/host/ehci-mxc.c |2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/ehci-mxc.c b/drivers/usb/host/ehci-mxc.c
index 65f40a4..6f4df58 100644
--- a/drivers/usb/host/ehci-mxc.c
+++ b/drivers/usb/host/ehci-mxc.c
@@ -126,8 +126,6 @@ int ehci_hcd_init(void)
HC_LENGTH(ehci_readl(hccr-cr_capbase)));
setbits_le32(ehci-usbmode, CM_HOST);
 #if defined(CONFIG_MX31) || defined(CONFIG_MX25)
-   setbits_le32(ehci-control, USB_EN);
-
__raw_writel(CONFIG_MXC_USB_PORTSC, ehci-portsc);
 #endif
mxc_set_usbcontrol(CONFIG_MXC_USB_PORT, CONFIG_MXC_USB_FLAGS);
-- 
1.7.5.4

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

[U-Boot] [PATCH 7/9] imx: esdhc: Needed to use in imx-regs.h defined address

2012-04-18 Thread Timo Ketola

One might want to define CONFIG_SYS_FSL_ESDHC_ADDR with the macro already
define in imx-regs.h, e.g. with IMX_MMC_SDHC1_BASE. Then the header must be
included here.

Signed-off-by: Timo Ketola t...@exertus.fi
---
 drivers/mmc/fsl_esdhc.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
index a2f35e3..5ada747 100644
--- a/drivers/mmc/fsl_esdhc.c
+++ b/drivers/mmc/fsl_esdhc.c
@@ -36,6 +36,7 @@
 #include fsl_esdhc.h
 #include fdt_support.h
 #include asm/io.h
+#include asm/arch/imx-regs.h
 
 DECLARE_GLOBAL_DATA_PTR;
 
-- 
1.7.5.4

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

[U-Boot] [PATCH 8/9] imx: Add u-boot.imx as target for ARM9 i.MX SOCs

2012-04-18 Thread Timo Ketola

Signed-off-by: Timo Ketola t...@exertus.fi
---
 arch/arm/cpu/arm926ejs/config.mk |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/arch/arm/cpu/arm926ejs/config.mk b/arch/arm/cpu/arm926ejs/config.mk
index ffb2e6c..6a3a1bb 100644
--- a/arch/arm/cpu/arm926ejs/config.mk
+++ b/arch/arm/cpu/arm926ejs/config.mk
@@ -31,3 +31,9 @@ PLATFORM_CPPFLAGS += -march=armv5te
 # =
 PF_RELFLAGS_SLB_AT := $(call cc-option,-mshort-load-bytes,$(call 
cc-option,-malignment-traps,))
 PLATFORM_RELFLAGS += $(PF_RELFLAGS_SLB_AT)
+
+ifneq ($(CONFIG_IMX_CONFIG),)
+
+ALL-y  += $(obj)u-boot.imx
+
+endif
-- 
1.7.5.4

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

Re: [U-Boot] [PATCH 0/8 v3] i.MX25: Miscellaneus fixes

2012-04-18 Thread Timo Ketola


Hi,

Please, don't get confused about the subject lines which suggest that I sent 
nine patches. At the last second I dropped the last patch and decided to send 
it separately.


Stefano, did you get the [PATCH 0/8 v3]... message as a CC. I don't see you 
in CC list in the bounce I got myself and yet I have your address in 
.git/config *and* I see you in my following messages. I don't understand...


--

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

Re: [U-Boot] [PATCH 0/8 v3] i.MX25: Miscellaneus fixes

2012-04-18 Thread Stefano Babic

On 18/04/2012 09:57, Timo Ketola wrote:
 These are the fixes I needed to do to get my board going.
 

Hi Timo,

 Changes in v3:
 - Dropped old patch number 8 imx: nand: Don't invent new...
 - Changed the subject of patch 4
 - Changed the BBT pattern offsets (patch 4); They are now zero
 as in Linux

You must change the subject of the patch and introduce an enumeration.
Your patchset should start with [PATCH V3. This can easy automatically
done by git format-patch with --subject-prefix PATCH V3.

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 7/9] imx: esdhc: Needed to use in imx-regs.h defined address

2012-04-18 Thread Stefano Babic

On 18/04/2012 09:57, Timo Ketola wrote:
 One might want to define CONFIG_SYS_FSL_ESDHC_ADDR with the macro already
 define in imx-regs.h, e.g. with IMX_MMC_SDHC1_BASE. Then the header must be
 included here.
 
 Signed-off-by: Timo Ketola t...@exertus.fi
 ---
  drivers/mmc/fsl_esdhc.c |1 +
  1 files changed, 1 insertions(+), 0 deletions(-)
 
 diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
 index a2f35e3..5ada747 100644
 --- a/drivers/mmc/fsl_esdhc.c
 +++ b/drivers/mmc/fsl_esdhc.c
 @@ -36,6 +36,7 @@
  #include fsl_esdhc.h
  #include fdt_support.h
  #include asm/io.h
 +#include asm/arch/imx-regs.h
  

NAK. There is a good reason to avoid it. The fsl_esdhc driver is common
to both i.MX and PowerPc architecture, and of course PowerPC have not
imx-regs.h. And CONFIG_SYS_FSL_ESDHC_ADDR cannot be set by a macro in
imx-regs.h, because it is different on PowerPC.

By the way, why do you need it if you do not use that macro ?

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

[U-Boot] [PATCH 0/1] i.MX2: Support splash screen

2012-04-18 Thread Timo Ketola

I based this on the work here:

http://www.imxdev.org/wiki/index.php?title=I.MX25_PDK_U-boot_SplashScreen

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

[U-Boot] [PATCH] i.MX2: Support splash screen

2012-04-18 Thread Timo Ketola

Signed-off-by: Timo Ketola t...@exertus.fi
---
 arch/arm/include/asm/arch-mx25/imx-regs.h |   29 +
 drivers/video/Makefile|1 +
 drivers/video/mx2fb.c |   92 +
 include/lcd.h |   21 ++-
 include/mx2fb.h   |   39 
 5 files changed, 181 insertions(+), 1 deletions(-)
 create mode 100644 drivers/video/mx2fb.c
 create mode 100644 include/mx2fb.h

diff --git a/arch/arm/include/asm/arch-mx25/imx-regs.h 
b/arch/arm/include/asm/arch-mx25/imx-regs.h
index 7f9449b..af5b42e 100644
--- a/arch/arm/include/asm/arch-mx25/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx25/imx-regs.h
@@ -167,6 +167,35 @@ struct aips_regs {
u32 mpr_8_15;
 };
 
+struct lcdc_regs {
+   u32 lssar;
+   u32 lsr;
+   u32 lvpwr;
+   u32 lcpr;
+   u32 lcwhb;
+   u32 lccmr;
+   u32 lpcr;
+   u32 lhcr;
+   u32 lvcr;
+   u32 lpor;
+   u32 lscr;
+   u32 lpccr;
+   u32 ldcr;
+   u32 lrmcr;
+   u32 licr;
+   u32 lier;
+   u32 lisr;
+   u32 pad0[3];
+   u32 lgwsar;
+   u32 lgwsr;
+   u32 lgwvpwr;
+   u32 lgwpor;
+   u32 lgwpr;
+   u32 pad1[0x200 - 25];
+   u32 bglut[0x100];
+   u32 gwlut[0x100];
+};
+
 #endif
 
 /* AIPS 1 */
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 6252f6a..e047471 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -36,6 +36,7 @@ COBJS-$(CONFIG_VIDEO_CT69000) += ct69000.o videomodes.o
 COBJS-$(CONFIG_VIDEO_DA8XX) += da8xx-fb.o videomodes.o
 COBJS-$(CONFIG_VIDEO_MB862xx) += mb862xx.o videomodes.o
 COBJS-$(CONFIG_VIDEO_MB86R0xGDC) += mb86r0xgdc.o videomodes.o
+COBJS-$(CONFIG_VIDEO_MX2) += mx2fb.o
 COBJS-$(CONFIG_VIDEO_MX3) += mx3fb.o videomodes.o
 COBJS-$(CONFIG_VIDEO_MX5) += mxc_ipuv3_fb.o ipu_common.o ipu_disp.o
 COBJS-$(CONFIG_VIDEO_OMAP3) += omap3_dss.o videomodes.o
diff --git a/drivers/video/mx2fb.c b/drivers/video/mx2fb.c
new file mode 100644
index 000..9ee4a3e
--- /dev/null
+++ b/drivers/video/mx2fb.c
@@ -0,0 +1,92 @@
+#include common.h
+#include lcd.h
+#include mx2fb.h
+#include asm/arch/imx-regs.h
+#include asm/io.h
+#include asm/errno.h
+
+#if !defined(LCD_BPP) || LCD_BPP != LCD_COLOR16
+
+#error Only 16bpp is supported
+
+#endif
+
+DECLARE_GLOBAL_DATA_PTR;
+
+void *lcd_base;/* Start of framebuffer memory  */
+void *lcd_console_address; /* Start of console buffer  */
+
+int lcd_line_length;
+int lcd_color_fg;
+int lcd_color_bg;
+
+short console_col;
+short console_row;
+
+
+void lcd_initcolregs(void)
+{
+}
+
+void lcd_setcolreg(ushort regno, ushort red, ushort green, ushort blue)
+{
+}
+
+void lcd_enable(void)
+{
+}
+
+void lcd_disable(void)
+{
+}
+
+void lcd_panel_disable(void)
+{
+}
+
+void lcd_ctrl_init(void *lcdbase)
+{
+   u32 ccm_ipg_cg, pcr;
+   struct lcdc_regs *lcdc = (struct lcdc_regs *)IMX_LCDC_BASE;
+   struct ccm_regs *ccm = (struct ccm_regs *)IMX_CCM_BASE;
+
+   writel(gd-fb_base, lcdc-lssar);
+   writel(panel_info.vl_col  4  20 | panel_info.vl_row, lcdc-lsr);
+   writel(panel_info.vl_col / 2, lcdc-lvpwr);
+   if (panel_info.vl_bpix != 4)
+   printf(Unsupported color depth (%d), only 16bpp supported\n,
+   NBITS(panel_info.vl_bpix));
+   pcr = LCDC_LPCR | 5  25;
+
+   if (panel_info.vl_sync  FB_SYNC_CLK_LAT_FALL)
+   pcr |= 0x0020;
+   if (panel_info.vl_sync  FB_SYNC_DATA_INVERT)
+   pcr |= 0x0100;
+   if (panel_info.vl_sync  FB_SYNC_SHARP_MODE)
+   pcr |= 0x0040;
+   if (panel_info.vl_sync  FB_SYNC_OE_LOW_ACT)
+   pcr |= 0x0010;
+
+   pcr |= LCDC_LPCR_PCD;
+
+   writel(pcr, lcdc-lpcr);
+   writel((panel_info.vl_hsync - 1)  26 |
+   (panel_info.vl_right_margin - 1)  8 |
+   (panel_info.vl_left_margin - 3),
+   lcdc-lhcr);
+   writel(panel_info.vl_vsync  26 |
+   panel_info.vl_lower_margin  8 |
+   panel_info.vl_upper_margin,
+   lcdc-lvcr);
+   writel(LCDC_LSCR, lcdc-lscr);
+   writel(LCDC_LRMCR, lcdc-lrmcr);
+   writel(LCDC_LDCR, lcdc-ldcr);
+   writel(LCDC_LPCCR, lcdc-lpccr);
+
+   /* Off and on clock gating
+  FIXME: Why *off* and on; What side effects does it have? */
+   ccm_ipg_cg = readl(ccm-cgr1);
+
+   writel(ccm_ipg_cg  0xDFFF, ccm-cgr1);
+   writel(ccm_ipg_cg | 0x2000, ccm-cgr1);
+}
diff --git a/include/lcd.h b/include/lcd.h
index d95feeb..a5eeb53 100644
--- a/include/lcd.h
+++ b/include/lcd.h
@@ -183,6 +183,25 @@ typedef struct vidinfo {
u_long  mmio;   /* Memory mapped registers */
 } vidinfo_t;
 
+#elif defined(CONFIG_VIDEO_MX2)
+
+struct vidinfo {
+   ushort vl_row;  /* resolution in x

Re: [U-Boot] [PATCH 6/9] imx: usb: There is no such register

2012-04-18 Thread Stefano Babic

On 18/04/2012 09:57, Timo Ketola wrote:
 The reference manual of i.MX25 (nor i.MX31) does not define such register.
 This seems to access read only UH2_CAPLENGTH register (if
 CONFIG_MXC_USB_PORT is zero).
 
 Signed-off-by: Timo Ketola t...@exertus.fi

Hi Timo,

 ---
  drivers/usb/host/ehci-mxc.c |2 --
  1 files changed, 0 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/usb/host/ehci-mxc.c b/drivers/usb/host/ehci-mxc.c
 index 65f40a4..6f4df58 100644
 --- a/drivers/usb/host/ehci-mxc.c
 +++ b/drivers/usb/host/ehci-mxc.c
 @@ -126,8 +126,6 @@ int ehci_hcd_init(void)
   HC_LENGTH(ehci_readl(hccr-cr_capbase)));
   setbits_le32(ehci-usbmode, CM_HOST);
  #if defined(CONFIG_MX31) || defined(CONFIG_MX25)

As far as I can see, only MX31 and MX25 boards are using this file.
Other i.MX have its own initialization file. So #if defined(CONFIG_MX31)
|| defined(CONFIG_MX25) is always true.

However, where is this code ? In current u-boot I see only #if
defined(CONFIG_MX31) at this line. Is it your patch correct ?

 - setbits_le32(ehci-control, USB_EN);
 -

As far as I can see, it tries to overwrite a capability register, that
is for our luck read-only. Good catch !

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 7/9] imx: esdhc: Needed to use in imx-regs.h defined address

2012-04-18 Thread Timo Ketola


On 18.04.2012 11:43, Stefano Babic wrote:

On 18/04/2012 09:57, Timo Ketola wrote:

One might want to define CONFIG_SYS_FSL_ESDHC_ADDR with the macro already
define in imx-regs.h, e.g. with IMX_MMC_SDHC1_BASE. Then the header must be
included here.
...
diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
...
+#includeasm/arch/imx-regs.h


NAK. There is a good reason to avoid it. The fsl_esdhc driver is common
to both i.MX and PowerPc architecture, and of course PowerPC have not
imx-regs.h. And CONFIG_SYS_FSL_ESDHC_ADDR cannot be set by a macro in
imx-regs.h, because it is different on PowerPC.


Ok, I was afraid about something like that and tried first to include it in 
board configuration but that broke something else (at least arm926ejs didn't 
compile any more).



By the way, why do you need it if you do not use that macro ?


I use it in my board (support of which I'm preparing to send) configuration 
file and I think it is annoying to write a literal constant there which is 
already defined in imx-regs.h.


PPC seems to use a predefined macro from asm/immap_8xxx.h files. Where is that 
file included?


--

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

Re: [U-Boot] [PATCH] PowerPC: Change -fpic flag to -fPIC flag in the config.mk

2012-04-18 Thread Chunhe Lan




Wolfgang Denk wrote:

Dear Chunhe Lan,

In message 1334719161-3500-1-git-send-email-chunhe@freescale.com 
you wrote:

The -fPIC/-fpic flag belongs with -mrelocatable. The -fpic flag can
limit the size of the GOT and produce smaller binaries, so it causes
some GOT entries to be lost in the gcc 4.6 version. But -fPIC flag
allows the maximum possible size of the GOT entries.

However, currently -mrelocatable promotes -fpic flag to -fPIC flag.

This reverts that portion of the
commit 33ee4c92339ee386662c0ee2d221098c5cc8b07e.


As you state yourself, your modification has the negative impact of
increasing the image size. What would be the benefits of it?

Are you trying to fix any specific problem? Which one? I am not aware
of any related isses for any of the mainline PowerPC systems...
Yes, I have fixed the booting issue of nand u-boot of 
P1010/P1022/P1023/P2020 with this patch.


   When use gcc 4.5 version, produce the size of u-boot-nand.bin to be 
same with -fpic or -fPIC.

   The u-boot-nand.bin is OK.

   But when use gcc 4.6 version, produce the size of u-boot-nand.bin to 
be different with -fpic or -fPIC.
   The some GOT entries of u-boot-nand.bin are lost with -fpic(because 
limit the size),  so
u-boot-nand.bin hangs when booting. But use -fPIC, the 
u-boot-nand.bin is OK.


   And this patch reverts that portion of the commit 
33ee4c92339ee386662c0ee2d221098c5cc8b07e.
  
   Thanks,

   Chunhe


Best regards,

Wolfgang Denk



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

Re: [U-Boot] [PATCH 6/9] imx: usb: There is no such register

2012-04-18 Thread Timo Ketola


On 18.04.2012 12:05, Stefano Babic wrote:

As far as I can see, only MX31 and MX25 boards are using this file.
Other i.MX have its own initialization file. So #if defined(CONFIG_MX31)
|| defined(CONFIG_MX25) is always true.


So, would it be OK to remove this check altogether?


However, where is this code ? In current u-boot I see only #if
defined(CONFIG_MX31) at this line. Is it your patch correct ?


My previous patch 5 touched that one.


-   setbits_le32(ehci-control, USB_EN);
-


As far as I can see, it tries to overwrite a capability register, that
is for our luck read-only. Good catch !


Thanks.

--

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

Re: [U-Boot] [PATCH] PowerPC: Change -fpic flag to -fPIC flag in the config.mk

2012-04-18 Thread Wolfgang Denk

Dear Chunhe Lan,

In message 4f8e6e06.3060...@freescale.com you wrote:
 
  As you state yourself, your modification has the negative impact of
  increasing the image size. What would be the benefits of it?
 
  Are you trying to fix any specific problem? Which one? I am not aware
  of any related isses for any of the mainline PowerPC systems...
  Yes, I have fixed the booting issue of nand u-boot of 
 P1010/P1022/P1023/P2020 with this patch.

What exactly is the booting issue you mention here?  Are you
referring to any messages previously posted here?  Which?

 But when use gcc 4.6 version, produce the size of u-boot-nand.bin to 
 be different with -fpic or -fPIC.
 The some GOT entries of u-boot-nand.bin are lost with -fpic(because 
 limit the size),  so
  u-boot-nand.bin hangs when booting. But use -fPIC, the 
 u-boot-nand.bin is OK.

What do you mean GOT entries ... are lost?  Are there any error
messages?

If yes, what exactly are these?

If not, then this has to be considered a serious bug in either the
compiler and the linker, and it should be fixed there rather than
being papered over.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
I think it's a new feature. Don't tell anyone it was an accident. :-)
  -- Larry Wall on s/foo/bar/eieio in 10...@jpl-devvax.jpl.nasa.gov
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/9] i.MX25: esdhc: Add mxc_get_clock infrastructure

2012-04-18 Thread Wolfgang Denk

Dear Timo Ketola,

In message 1334735852-23415-2-git-send-email-t...@exertus.fi you wrote:
 Defining CONFIG_FSL_ESDHC brings in a call to get_clocks, so let's implement 
 get_clocks function. This is how it seems to be implemented elsewhere.
 
 Signed-off-by: Timo Ketola t...@exertus.fi
 ---
  arch/arm/cpu/arm926ejs/mx25/generic.c  |   27 +++
  arch/arm/include/asm/arch-mx25/clock.h |   23 +++
  2 files changed, 50 insertions(+), 0 deletions(-)
 
 diff --git a/arch/arm/cpu/arm926ejs/mx25/generic.c 
 b/arch/arm/cpu/arm926ejs/mx25/generic.c
...

I understand this is a (eventually modified ?) reposting of patches
you posted before.  in this case it is mandatory not only to mark this
in the Subject, but also to provide a detailled change log (below the
--- line); see
http://www.denx.de/wiki/view/U-Boot/Patches#Sending_updated_patch_versions


I'm not going to try to find out which review comments you have
included, and what you changed to do so; sorry, but I don;t have that
much time.

Please consider the whole patch series ignored.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
It is easier to port a shell than a shell script.  - Larry Wall
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/1] i.MX2: Support splash screen

2012-04-18 Thread Wolfgang Denk

Dear Timo Ketola,

In message 1334739261-7812-1-git-send-email-t...@exertus.fi you wrote:
 I based this on the work here:
 
 http://www.imxdev.org/wiki/index.php?title=I.MX25_PDK_U-boot_SplashScreen

This information belongs (with greater detail) into the commit
message.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
The day-to-day travails of the IBM programmer are so amusing to  most
of us who are fortunate enough never to have been one - like watching
Charlie Chaplin trying to cook a shoe.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] i.MX2: Support splash screen

2012-04-18 Thread Wolfgang Denk

Dear Timo Ketola,

In message 1334739261-7812-2-git-send-email-t...@exertus.fi you wrote:
 Signed-off-by: Timo Ketola t...@exertus.fi
 ---
  arch/arm/include/asm/arch-mx25/imx-regs.h |   29 +
  drivers/video/Makefile|1 +
  drivers/video/mx2fb.c |   92 
 +
  include/lcd.h |   21 ++-
  include/mx2fb.h   |   39 
  5 files changed, 181 insertions(+), 1 deletions(-)
  create mode 100644 drivers/video/mx2fb.c
  create mode 100644 include/mx2fb.h

NAK, because proper attribution is missing.  See
http://www.denx.de/wiki/view/U-Boot/Patches#Attributing_Code_Copyrights_Sign


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
The greatest warriors are the ones who fight for peace.
- Holly Near
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot-Users] How to pass MAC address to linux kernel?

2012-04-18 Thread Wolfgang Denk

Dear Jayakumar A,

Please restrict your line length to some 70 characters or so.  Thanks.

In message 3d423a5438408c4ea43da95d38f9989b7c9b6ed...@exchindmail.patni.com 
you wrote:

 I was going through the mail chain of passing  MAC address to Linux kernel
 ( http://www.mail-archive.com/u-boot-users@lists.sourceforge.net/msg09312.
 html)  and found you could be of great help in helping our issue.

This information is 4 years old and obsolete.

 We wish to set the ipaddress on the ARM-9 board retrieving from a particula
 r file and start the network services:

If you are talk about retrieve from a file you probably mean under
Linux?  That should be trivial to implement.

In U-Boot, we use the environment to store MAC addresses.

 We are using FreeScaleArm9 board and to statically set the system we have f
 lashed the kernel(linux-2.6.31) on NAND Flash with DHCP off.
 As per ltib settings it says: to have static ip-settings, either set the ip
 -address while configuring LTIB or change in the file /etc/rc.d/rc.conf.

This is all Linux stuff and off topic here.  Also, LTIB is Freesale's
code, so please ask Freescale support about it.

 If you could please share some information regarding the static -ip setting
 s and starting network serives it should be of great help.

It is totally unclear to me what you are actually asking 0 it seems
you confuse MAC and IP addresses at a pretty much fundamental level.
In any case, you appear to refer to Linux configuration, which is off
topic here.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Living on Earth may be expensive, but it includes an annual free trip
around the Sun.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] FW: I want to use Barebox

2012-04-18 Thread Wolfgang Denk

Dear Andy,

In message f9c551623d2cbb4c9488801d14f864c614e...@ex-mb1.corp.adtran.com you 
wrote:
 
   - How often a patches committed to the public repository
   - What is the patch review procedure - Has it changed recently? Why?
 do _you_ think it is a good procedure?
   - How many people are actively contributing - Is there are large enough
 core contribution team that you believe can support you going forward
   - What level of support can you expect from the community both now and in
 the future
   - Are there any clear policies (either explicit or implicit). For exampl 
  e,
 U-Boot has a policy of not introducing board-breaking changes unless
 there is a really good reason. Also, U-Boot questions patches that
 cause code/data size increases for arches/boards which do not benifit
 from a particular new feature

 Looking at the two choices side by side, these appear to be equal.  This

Actually this is an area where you can collect objective, unbiased
information from a number of data sources.  Each of them alone is
probably subject to error or misinterpretation, but together they give
a pretty clear picture.

1) Commit statistics; these are trivial to get from the respective
   git repositories using the git-dm tool by Jonathan Corbet (see
   http://repo.or.cz/w/git-dm.git). Here one should pay attention
   that up to and including U-Boot v1.2.0 (commit f4eb545, dated
   Sun Jan 7 00:13:11 2007) both trees share a common history, so
   let's look at this separately:

   Common history: commits 0b666f8..f4eb545

2154 csets from 38 developers
8 employers found
A total of 1919992 lines added, 279294 removed (delta 1640698)

   U-Boot history since: commits f4eb545..f5cdc11 (=v2012.04-rc2)

12648 csets from 647 developers
54 employers found
A total of 1632473 lines added, 1132225 removed (delta 500248)

   BareBox history since: commits f4eb545..6a0ab1d   (2012-04-14)

4346 csets from 72 developers
6 employers found
A total of 458345 lines added, 1404718 removed (delta -946373)

   It has to be pointed out that the inital phase of Barebox is
   probably a bit untypic as it consisted mainly of large removals of
   major parts of U-Boot code, so let's also have a look at a
   somewhat shorter period - we skip the period where BareBox was
   using SVN and start with the first git commit (bc1e507, 2007-07-05
   21:23:42). For U-Boot we chose a close date: commit f1152f8
   (2007-07-06 02:50:19)

   U-Boot history since: commits f1152f8..f5cdc11

12212 csets from 630 developers
52 employers found
A total of 1531006 lines added, 1099069 removed (delta 431937)

   Barebox history since: commits bc1e507..6a0ab1d

3657 csets from 72 developers
6 employers found
A total of 377290 lines added, 865712 removed (delta -488422)

   So in the last ~5 years (since 2007-07-05 = 1748 days) we get these numbers:

U-Boot  BareBox ratio
Commits 12212   36573.3
Developers  630 72  8.8
Employers   52  6   8.7
add per day 876 216 4.1
rm  per day 629 495 1.3
chg per day +247-279

   As you can see, U-Boot has a significantly bigger community
   (both in terms of developers and contributing companies).
   Development is faster, too.


2) Project statistics at ohloh.net:
   compare http://www.ohloh.net/p/u-boot
   versus  http://www.ohloh.net/p/barebox

   Note: this comparison is in favour of the BareBox project, as it
   includes all the common history up to and including commit
   f4eb545 (U-Boot release v1.2.0).


3) Mailing list statistics:
   compare http://lists.denx.de/pipermail/u-boot/
   versus  http://lists.infradead.org/pipermail/barebox/

   For the period of October 2009 (when the BareBox mailing list was
   started) until today we see:

   U-Boot:  total 57.3  MiB gzipped text = 1893 KiB/month
   Barebox: total  7.08 MiB gzipped text =  234 KiB/month

   Also,
   compare http://dir.gmane.org/gmane.comp.boot-loaders.u-boot
   versus  http://dir.gmane.org/gmane.comp.boot-loaders.barebox

   For U-Boot see also:
   http://gmane.org/details.php?group=gmane.comp.boot-loaders.u-boot
   [http://gmane.org/details.php?group=gmane.comp.boot-loaders.barebox
   does not give much information.]


 is one of those areas, however, that no one can be 100% sure about for
 the next 5-10 years.  Barebox may overtake U-Boot just like U-Boot did
 for RedBoot.  Or some other bootloader may take the center stage.  This
 is an unknown risk that has to be owned by the company that chooses to
 adopt any third party code.

This is true. Prediction is always difficult.  On the other hand,
U-Boot is a de-facto standard in the embedded industry; we currently
support 990 board configurations in mainline (not counting the many,
many out-of-tree vendor ports).  This

Re: [U-Boot] [PATCH] PowerPC: Change -fpic flag to -fPIC flag in the config.mk

2012-04-18 Thread Joakim Tjernlund




 Wolfgang Denk wrote:
  Dear Chunhe Lan,
 
  In message 1334719161-3500-1-git-send-email-chunhe@freescale.com
  you wrote:
  The -fPIC/-fpic flag belongs with -mrelocatable. The -fpic flag can
  limit the size of the GOT and produce smaller binaries, so it causes
  some GOT entries to be lost in the gcc 4.6 version. But -fPIC flag
  allows the maximum possible size of the GOT entries.
 
  However, currently -mrelocatable promotes -fpic flag to -fPIC flag.

Not in newer gcc's. I added this to gcc some time ago and I think
it got into gcc 4.6.

 
  This reverts that portion of the
  commit 33ee4c92339ee386662c0ee2d221098c5cc8b07e.
 
  As you state yourself, your modification has the negative impact of
  increasing the image size. What would be the benefits of it?
 
  Are you trying to fix any specific problem? Which one? I am not aware
  of any related isses for any of the mainline PowerPC systems...
  Yes, I have fixed the booting issue of nand u-boot of
 P1010/P1022/P1023/P2020 with this patch.

 When use gcc 4.5 version, produce the size of u-boot-nand.bin to be
 same with -fpic or -fPIC.
 The u-boot-nand.bin is OK.

 But when use gcc 4.6 version, produce the size of u-boot-nand.bin to
 be different with -fpic or -fPIC.
 The some GOT entries of u-boot-nand.bin are lost with -fpic(because
 limit the size),  so
  u-boot-nand.bin hangs when booting. But use -fPIC, the
 u-boot-nand.bin is OK.

Your linker file is buggy I think. I found u-boot-nand_spl.lds, is that the one?
Check out that files reloc part:
.reloc : {
_GOT2_TABLE_ = .;
KEEP(*(.got2))
_FIXUP_TABLE_ = .;
KEEP(*(.fixup))
}
__got2_entries = (_FIXUP_TABLE_ - _GOT2_TABLE_)  2;
__fixup_entries = (. - _FIXUP_TABLE_)  2;

Compare that with(from u-boot.lds):
 .reloc   :
  {
_GOT2_TABLE_ = .;
KEEP(*(.got2))
KEEP(*(.got))
PROVIDE(_GLOBAL_OFFSET_TABLE_ = . + 4);
_FIXUP_TABLE_ = .;
KEEP(*(.fixup))
  }
  __got2_entries = ((_GLOBAL_OFFSET_TABLE_ - _GOT2_TABLE_)  2) - 1;
  __fixup_entries = (. - _FIXUP_TABLE_)  2;

You may have to look at start.S for nand too

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

Re: [U-Boot] [PATCH 7/9] imx: esdhc: Needed to use in imx-regs.h defined address

2012-04-18 Thread Stefano Babic

On 18/04/2012 11:11, Timo Ketola wrote:

 
 Ok, I was afraid about something like that and tried first to include it
 in board configuration but that broke something else (at least arm926ejs
 didn't compile any more).
 
 By the way, why do you need it if you do not use that macro ?
 
 I use it in my board (support of which I'm preparing to send)
 configuration file and I think it is annoying to write a literal
 constant there which is already defined in imx-regs.h.

fsl_esdhc.c includes config.h. If your board configuration file includes
imx-regs.h, as most i.MX boards do, the file is automatically included,
I suppose.

 
 PPC seems to use a predefined macro from asm/immap_8xxx.h files. Where
 is that file included?

It is a different way. The board configuration file includes the
register description file, so for example immap_86xx.h, immap_85xx.h, or
imx-regs.h, and defines CONFIG_SYS_FSL_ESDHC_ADDR using its own specific
macro, if any, for example:

#define CONFIG_SYS_FSL_ESDHC_ADDR   CONFIG_SYS_MPC85xx_ESDHC_ADDR

Why is it not enough for you to set in your board configuration file:

#define CONFIG_SYS_FSL_ESDHC_ADDR   IMX_MMC_SDHC1_BASE

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 6/9] imx: usb: There is no such register

2012-04-18 Thread Stefano Babic

On 18/04/2012 11:15, Timo Ketola wrote:
 On 18.04.2012 12:05, Stefano Babic wrote:
 As far as I can see, only MX31 and MX25 boards are using this file.
 Other i.MX have its own initialization file. So #if defined(CONFIG_MX31)
 || defined(CONFIG_MX25) is always true.
 
 So, would it be OK to remove this check altogether?

Yes, I think so - if the file is compiled only by i.MX25 or i.MX31
boards, it makes no sense.

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] FW: I want to use Barebox

2012-04-18 Thread Dirk Behme


Dear Wolfgang,

On 18.04.2012 11:52, Wolfgang Denk wrote:
...

   U-Boot history since: commits f4eb545..f5cdc11 (=v2012.04-rc2)


Totally off-topic in this thread, but:

Oh, indeed, looking into git we have a v2012.04-rc2 :)

Have I missed the release mail?

Best regards

Dirk

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

Re: [U-Boot] [PATCH 1/9] i.MX25: esdhc: Add mxc_get_clock infrastructure

2012-04-18 Thread Timo Ketola


On 18.04.2012 12:23, Wolfgang Denk wrote:

Dear Timo Ketola,

In message1334735852-23415-2-git-send-email-t...@exertus.fi  you wrote:

Defining CONFIG_FSL_ESDHC brings in a call to get_clocks, so let's
implement get_clocks function. This is how it seems to be implemented
elsewhere. ...

...

I understand this is a (eventually modified ?) reposting of patches you
posted before.


Yes


in this case it is mandatory not only to mark this in the Subject,


Ok, how to do that I learned just now.


but also to provide a detailled change log (below the --- line); see
http://www.denx.de/wiki/view/U-Boot/Patches#Sending_updated_patch_versions


I tried to provide that in the 0/x message but do you mean that I should 
provide it separately for every single patch? I see that your reference asks 
just that.


I was in impression that 'git send-email' (alone) would do the right thing but
it doesn't give me opportunity to edit actual patch messages, only the cover
letter. And I saw many examples of people putting the log in the cover letter.
So how do people do that? 'git format-patch' then manually edit patch files,
then send them with 'git send-email'?


I'm not going to try to find out which review comments you have included,
and what you changed to do so; sorry, but I don;t have that much time.


So do I have to reference review comments somehow?


Please consider the whole patch series ignored.


Ok

--

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

Re: [U-Boot] [PATCH] i.MX6: Add ANATOP regulator init

2012-04-18 Thread Dirk Behme


On 13.04.2012 10:00, Dirk Behme wrote:

Init the core regulator voltage to 1.2V. This is required for the correct
functioning of the GPU and when the ARM LDO is set to 1.225V. This is a
workaround to fix some memory clock jitter.

Note: This should be but can't be done in the DCD. The bootloader
  prevents access to the ANATOP registers.

Signed-off-by: Dirk Behme dirk.be...@de.bosch.com
CC: Jason Chen b02...@freescale.com
CC: Jason Liu r64...@freescale.com
CC: Ranjani Vaidyanathan ra5...@freescale.com
CC: Stefano Babic sba...@denx.de
CC: Fabio Estevam feste...@gmail.com
---
 arch/arm/cpu/armv7/mx6/soc.c |   16 
 1 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/arch/arm/cpu/armv7/mx6/soc.c b/arch/arm/cpu/armv7/mx6/soc.c
index 543b2cc..957ea34 100644
--- a/arch/arm/cpu/armv7/mx6/soc.c
+++ b/arch/arm/cpu/armv7/mx6/soc.c
@@ -77,10 +77,26 @@ void init_aips(void)
writel(0x, aips2-opacr4);
 }
 
+static void init_anatop_reg(void)

+{
+   struct anatop_regs *anatop = (struct anatop_regs *)ANATOP_BASE_ADDR;
+   int reg = readl(anatop-reg_core);
+
+   /*
+* Increase the VDDSOC to 1.2V
+* Mask out the REG_CORE[22:18] bits (REG2_TRIG)
+* and set them to 1.2V (0.7V + 0x14 * 0.025V)
+*/
+   reg = (reg  ~(0x1F  18)) | (0x14  18);
+   writel(reg, anatop-reg_core);
+}
+
 int arch_cpu_init(void)
 {
init_aips();
 
+	init_anatop_reg();

+
return 0;
 }
 #endif


Any comments on this?

Many thanks

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

Re: [U-Boot] [PATCH] i.MX2: Support splash screen

2012-04-18 Thread Stefano Babic

On 18/04/2012 10:54, Timo Ketola wrote:
 Signed-off-by: Timo Ketola t...@exertus.fi
 ---
  arch/arm/include/asm/arch-mx25/imx-regs.h |   29 +
  drivers/video/Makefile|1 +
  drivers/video/mx2fb.c |   92 
 +
  include/lcd.h |   21 ++-
  include/mx2fb.h   |   39 
  5 files changed, 181 insertions(+), 1 deletions(-)
  create mode 100644 drivers/video/mx2fb.c
  create mode 100644 include/mx2fb.h

Hi Timo,

I forward your patch to Anatolji. He is the video maintainer.

 
 diff --git a/arch/arm/include/asm/arch-mx25/imx-regs.h 
 b/arch/arm/include/asm/arch-mx25/imx-regs.h
 index 7f9449b..af5b42e 100644
 --- a/arch/arm/include/asm/arch-mx25/imx-regs.h
 +++ b/arch/arm/include/asm/arch-mx25/imx-regs.h
 @@ -167,6 +167,35 @@ struct aips_regs {
   u32 mpr_8_15;
  };
  
 +struct lcdc_regs {
 + u32 lssar;
 + u32 lsr;
 + u32 lvpwr;
 + u32 lcpr;
 + u32 lcwhb;
 + u32 lccmr;
 + u32 lpcr;
 + u32 lhcr;
 + u32 lvcr;
 + u32 lpor;
 + u32 lscr;
 + u32 lpccr;
 + u32 ldcr;
 + u32 lrmcr;
 + u32 licr;
 + u32 lier;
 + u32 lisr;
 + u32 pad0[3];
 + u32 lgwsar;
 + u32 lgwsr;
 + u32 lgwvpwr;
 + u32 lgwpor;
 + u32 lgwpr;
 + u32 pad1[0x200 - 25];
 + u32 bglut[0x100];
 + u32 gwlut[0x100];
 +};
 +
  #endif
  
  /* AIPS 1 */
 diff --git a/drivers/video/Makefile b/drivers/video/Makefile
 index 6252f6a..e047471 100644
 --- a/drivers/video/Makefile
 +++ b/drivers/video/Makefile
 @@ -36,6 +36,7 @@ COBJS-$(CONFIG_VIDEO_CT69000) += ct69000.o videomodes.o
  COBJS-$(CONFIG_VIDEO_DA8XX) += da8xx-fb.o videomodes.o
  COBJS-$(CONFIG_VIDEO_MB862xx) += mb862xx.o videomodes.o
  COBJS-$(CONFIG_VIDEO_MB86R0xGDC) += mb86r0xgdc.o videomodes.o
 +COBJS-$(CONFIG_VIDEO_MX2) += mx2fb.o
  COBJS-$(CONFIG_VIDEO_MX3) += mx3fb.o videomodes.o
  COBJS-$(CONFIG_VIDEO_MX5) += mxc_ipuv3_fb.o ipu_common.o ipu_disp.o
  COBJS-$(CONFIG_VIDEO_OMAP3) += omap3_dss.o videomodes.o
 diff --git a/drivers/video/mx2fb.c b/drivers/video/mx2fb.c
 new file mode 100644
 index 000..9ee4a3e


IMHO it is better if you use the video API instead of the old LCD
interface, that means using CONFIG_VIDEO. You have then to implement a
video_hw_init() function for your initialisation. I think there are
advantages doing that, and recently some drivers moved to this API, for
example the driver for i.MX3 (mx3fb.c).

  
 diff --git a/include/mx2fb.h b/include/mx2fb.h
 new file mode 100644
 index 000..1f16a61
 --- /dev/null
 +++ b/include/mx2fb.h
 @@ -0,0 +1,39 @@
 +/*
 + * Copyright 2004-2009 Freescale Semiconductor, Inc. All Rights Reserved.
 + */
 +
 +/*
 + * 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 header is not correct, I think - it does not set explicitely under
which license version is published this code, only where it is possible
to get a GPLv2 or later. Please substitute this header with a full
explained license header, as you can see generally in u-boot files.

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] mmc: Fix warning if CONFIG_MMC_TRACE is enabled

2012-04-18 Thread Dirk Behme


On 31.03.2012 20:35, Marek Vasut wrote:

Dear Dirk Behme,


Fix the warning

mmc.c: In function 'mmc_send_cmd':
mmc.c:87: warning: assignment from incompatible pointer type

in case CONFIG_MMC_TRACE is enabled.

Signed-off-by: Dirk Behme dirk.be...@de.bosch.com
CC: Andy Fleming aflem...@freescale.com
---


Acked-by: Marek Vasut ma...@denx.de

 Acked-by: Simon Glass s...@chromium.org



 drivers/mmc/mmc.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 21665ec..881b5c0 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -84,7 +84,7 @@ int mmc_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd,
struct mmc_data *data) for (i = 0; i  4; i++) {
int j;
printf(\t\t\t\t\t%03d - , i*4);
-   ptr = cmd-response[i];
+   ptr = (u8 *)cmd-response[i];
ptr += 3;
for (j = 0; j  4; j++)
printf(%02X , *ptr--);


Who could help to still get this into 2012.04?

Many thanks,

Dirk

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

Re: [U-Boot] [PATCH 7/9] imx: esdhc: Needed to use in imx-regs.h defined address

2012-04-18 Thread Timo Ketola


On 18.04.2012 13:30, Stefano Babic wrote:

On 18/04/2012 11:11, Timo Ketola wrote:



Ok, I was afraid about something like that and tried first to include it
in board configuration but that broke something else (at least arm926ejs
didn't compile any more).


By the way, why do you need it if you do not use that macro ?


I use it in my board (support of which I'm preparing to send)
configuration file and I think it is annoying to write a literal
constant there which is already defined in imx-regs.h.


fsl_esdhc.c includes config.h. If your board configuration file includes
imx-regs.h, as most i.MX boards do, the file is automatically included,
I suppose.


I tried that but then:

.../u-boot-imx/build-exe4026/include/asm/arch/imx-regs.h:43:2: error: expected 
specifier-qualifier-list before ‘u32’


when compiling

arch/arm/cpu/arm926ejs/cpu.o





PPC seems to use a predefined macro from asm/immap_8xxx.h files. Where
is that file included?


It is a different way. The board configuration file includes the
register description file, so for example immap_86xx.h, immap_85xx.h,


Where? I don't see an example. But I see them included in common.h. Should 
there be also imx-regs? Seems to work if I do so.



or
imx-regs.h, and defines CONFIG_SYS_FSL_ESDHC_ADDR using its own specific
macro, if any, for example:

#define CONFIG_SYS_FSL_ESDHC_ADDR   CONFIG_SYS_MPC85xx_ESDHC_ADDR

Why is it not enough for you to set in your board configuration file:

#define CONFIG_SYS_FSL_ESDHC_ADDR   IMX_MMC_SDHC1_BASE


I tried also exactly that, but then:

fsl_esdhc.c:544:20: error: ‘IMX_MMC_SDHC1_BASE’ undeclared (first use in this 
function)


fsl_esdhc.c seems not to see imx-regs.h file.

Then I tried to include imx-regs.h in fsl_esdhc.c and 'MAKEALL -a arm' was 
happy.

Maybe the right fix is to include imx-regs in common.h? What would be the right 
expression for #ifdef?


--

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

Re: [U-Boot] [PATCH] i.MX6: Add ANATOP regulator init

2012-04-18 Thread Jason Liu

2012/4/13 Dirk Behme dirk.be...@de.bosch.com:
 Init the core regulator voltage to 1.2V. This is required for the correct
 functioning of the GPU and when the ARM LDO is set to 1.225V. This is a
 workaround to fix some memory clock jitter.

 Note: This should be but can't be done in the DCD. The bootloader
      prevents access to the ANATOP registers.

 Signed-off-by: Dirk Behme dirk.be...@de.bosch.com
 CC: Jason Chen b02...@freescale.com
 CC: Jason Liu r64...@freescale.com
 CC: Ranjani Vaidyanathan ra5...@freescale.com
 CC: Stefano Babic sba...@denx.de
 CC: Fabio Estevam feste...@gmail.com
 ---
  arch/arm/cpu/armv7/mx6/soc.c |   16 
  1 files changed, 16 insertions(+), 0 deletions(-)

 diff --git a/arch/arm/cpu/armv7/mx6/soc.c b/arch/arm/cpu/armv7/mx6/soc.c
 index 543b2cc..957ea34 100644
 --- a/arch/arm/cpu/armv7/mx6/soc.c
 +++ b/arch/arm/cpu/armv7/mx6/soc.c
 @@ -77,10 +77,26 @@ void init_aips(void)
        writel(0x, aips2-opacr4);
  }

 +static void init_anatop_reg(void)
 +{
 +       struct anatop_regs *anatop = (struct anatop_regs *)ANATOP_BASE_ADDR;
 +       int reg = readl(anatop-reg_core);
 +
 +       /*
 +        * Increase the VDDSOC to 1.2V
 +        * Mask out the REG_CORE[22:18] bits (REG2_TRIG)
 +        * and set them to 1.2V (0.7V + 0x14 * 0.025V)
 +        */
 +       reg = (reg  ~(0x1F  18)) | (0x14  18);
 +       writel(reg, anatop-reg_core);
 +}
 +
  int arch_cpu_init(void)
  {
        init_aips();

 +       init_anatop_reg();
 +
        return 0;
  }
  #endif

Acked-by:Jason Liu r64...@freescale.com

 --
 1.7.0.4

 ___
 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] mmc: Fix warning if CONFIG_MMC_TRACE is enabled

2012-04-18 Thread Marek Vasut

Dear Dirk Behme,

 On 31.03.2012 20:35, Marek Vasut wrote:
  Dear Dirk Behme,
  
  Fix the warning
  
  mmc.c: In function 'mmc_send_cmd':
  mmc.c:87: warning: assignment from incompatible pointer type
  
  in case CONFIG_MMC_TRACE is enabled.
  
  Signed-off-by: Dirk Behme dirk.be...@de.bosch.com
  CC: Andy Fleming aflem...@freescale.com

I'd be glad to see it in ... Andy?

  ---
  
  Acked-by: Marek Vasut ma...@denx.de
  
   Acked-by: Simon Glass s...@chromium.org
   
   drivers/mmc/mmc.c |2 +-
   1 files changed, 1 insertions(+), 1 deletions(-)
  
  diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
  index 21665ec..881b5c0 100644
  --- a/drivers/mmc/mmc.c
  +++ b/drivers/mmc/mmc.c
  @@ -84,7 +84,7 @@ int mmc_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd,
  struct mmc_data *data) for (i = 0; i  4; i++) {
  
 int j;
 printf(\t\t\t\t\t%03d - , i*4);
  
  -  ptr = cmd-response[i];
  +  ptr = (u8 *)cmd-response[i];
  
 ptr += 3;
 for (j = 0; j  4; j++)
 
 printf(%02X , *ptr--);
 
 Who could help to still get this into 2012.04?
 
 Many thanks,
 
 Dirk

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

Re: [U-Boot] FW: I want to use Barebox

2012-04-18 Thread Wolfgang Denk

Dear Dirk Behme,

In message 4f8e999f.8060...@de.bosch.com you wrote:

 Oh, indeed, looking into git we have a v2012.04-rc2 :)
 
 Have I missed the release mail?

No - I did not manage to send one yet. [Don't have much to write,
either.]

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
There are always alternatives.
-- Spock, The Galileo Seven, stardate 2822.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [RFC] Preventing overriding of serverip when set in environment by user

2012-04-18 Thread Maupin, Chase

All,

I recently was trying out a Linksys WRT54G2 V1 router and encountered a strange 
behaviour where the dhcp server on the router was overriding the serverip 
setting I had in my u-boot environment.  The behaviour looked like:

1. Boot by board and set my serverip using setenv serverip 192.168.1.101
2. printenv shows my serverip as 192.168.1.101
3. Do a dhcp command.  In the output I noticed the server it was trying to 
transfer my file from was 192.168.1.1 which is the router.
4. cancel the dhcp and do a printenv
5. serverip is not set to 192.168.1.1 in my environment

So the net effect was that the dhcp server in this router was providing 
information in its response packet that was overriding the setting I had 
programmed.  I dug into the u-boot code a little and found two ways to work 
around this.

The first was to set CONFIG_BOOTP_SERVERIP in my board config file.  I 
discarded this because this would seem to make me always ignore the serverip 
setting from the DHCP server, and it seemed likely that there were cases where 
you would want this.

The second was to check if the serverip was already set in the environment and 
if so then not override that value with the one in the response from the DHCP 
server.  The below patch snippet does this (NOTE: I based this on my 2011.09 
tree but it is close to the master branch in this function except for the use 
of __maybe_unused).

net/bootp.c |   10 +-
 1 files changed, 9 insertions(+), 1 deletions(-)

diff --git a/net/bootp.c b/net/bootp.c
index a003c42..186a7ac 100644
--- a/net/bootp.c
+++ b/net/bootp.c
@@ -106,11 +106,19 @@ static int BootpCheckPkt(uchar *pkt, unsigned dest, 
unsigned src, unsigned len)
 static void BootpCopyNetParams(Bootp_t *bp)
 {
IPaddr_t tmp_ip;
+   IPaddr_t tmp_serverip;
 
NetCopyIP(NetOurIP, bp-bp_yiaddr);
 #if !defined(CONFIG_BOOTP_SERVERIP)
NetCopyIP(tmp_ip, bp-bp_siaddr);
-   if (tmp_ip != 0)
+
+   /* Check if the serverip variable is set.  If so then do not set
+  NetServerIP which will result in overwriting the serverip variable
+  in the environment.
+*/
+   tmp_serverip = getenv_IPaddr(serverip);
+
+   if (!tmp_serverip  (tmp_ip != 0))
NetCopyIP(NetServerIP, bp-bp_siaddr);
memcpy (NetServerEther, ((Ethernet_t *)NetRxPacket)-et_src, 6);
 #endif
-- 
1.7.0.4

I tested the above patch with the same linksys router and in the case where I 
had done a setenv serverip xxx.xxx.xxx.xxx it was not overridden by the DHCP 
server settings.  If I had not set serverip then it was set to the DHCP server 
setting.

Is this the proper way to fix this issue and the right location to make the 
change?  The overall goal was to make sure that if I specified a particular 
serverip that I wanted to use, then the DHCP server should not be changing that.

Sincerely,
Chase Maupin

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

Re: [U-Boot] [PATCH 7/9] imx: esdhc: Needed to use in imx-regs.h defined address

2012-04-18 Thread Stefano Babic

On 18/04/2012 13:05, Timo Ketola wrote:


 fsl_esdhc.c includes config.h. If your board configuration file includes
 imx-regs.h, as most i.MX boards do, the file is automatically included,
 I suppose.
 
 I tried that but then:
 
 .../u-boot-imx/build-exe4026/include/asm/arch/imx-regs.h:43:2: error:
 expected specifier-qualifier-list before ‘u32’
 
 when compiling
 
 arch/arm/cpu/arm926ejs/cpu.o

Well, I have not said that there cannot be other issues. At first glance
you must include asm/types.h, in cpu.c or in imx-regs.h.

 PPC seems to use a predefined macro from asm/immap_8xxx.h files. Where
 is that file included?

 It is a different way. The board configuration file includes the
 register description file, so for example immap_86xx.h, immap_85xx.h,
 
 Where? I don't see an example.

For PPC86xx I can see at least:

arch/powerpc/cpu/mpc86xx/mpc8641_serdes.c:#include asm/immap_86xx.h
arch/powerpc/cpu/mpc86xx/mpc8610_serdes.c:#include asm/immap_86xx.h
board/freescale/mpc8610hpcd/mpc8610hpcd.c:#include asm/immap_86xx.h
board/freescale/mpc8641hpcn/mpc8641hpcn.c:#include asm/immap_86xx.h

 But I see them included in common.h.
 Should there be also imx-regs? Seems to work if I do so.

No, this is wrong.

 
 or
 imx-regs.h, and defines CONFIG_SYS_FSL_ESDHC_ADDR using its own specific
 macro, if any, for example:

 #define CONFIG_SYS_FSL_ESDHC_ADDR   CONFIG_SYS_MPC85xx_ESDHC_ADDR

 Why is it not enough for you to set in your board configuration file:

 #define CONFIG_SYS_FSL_ESDHC_ADDR   IMX_MMC_SDHC1_BASE
 
 I tried also exactly that, but then:
 
 fsl_esdhc.c:544:20: error: ‘IMX_MMC_SDHC1_BASE’ undeclared (first use in
 this function)

...then imx-regs.h was not included...

 
 fsl_esdhc.c seems not to see imx-regs.h file.
 
 Then I tried to include imx-regs.h in fsl_esdhc.c and 'MAKEALL -a arm'
 was happy.
 
 Maybe the right fix is to include imx-regs in common.h?

No. common.h, as the name suggests, is for all architectures, not only
for i.MX. We cannot fix i:MX and break other boards.

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

[U-Boot] [PATCH v4 0/3] usb:gadget:composite: Support for composite gadget framework

2012-04-18 Thread Lukasz Majewski

This patch set provides support for composite gadget framework.
Files from Linux kernel (2.6.36) - namely composite.{c|h} have been
ported to u-boot.

Code supporting this framework has been added to gadget.h and Samsung's
UDC driver as well.

---
Changes for v2:
- Squash the kernel files with u-boot compatibility layer.
- Removal of dead/kernel specific code.
- Comments corrected according to u-boot coding style.
- Two separate patches regarding gadget.h file squashed together.
Changes for v3:
- Remove unlikely function call
- Code indentation fixup
Changes for v4:
- Move variables definition to function beginning
- CaMeL case declaration fixed

Lukasz Majewski (3):
  usb:gadget:composite USB composite gadget support
  usb:gadget:composite: Support for composite at gadget.h
  usb:udc:samsung Add functions for storing private gadget data in UDC
driver

 drivers/usb/gadget/composite.c   | 1082 ++
 drivers/usb/gadget/s3c_udc_otg.c |   12 +
 include/linux/usb/composite.h|  350 
 include/linux/usb/gadget.h   |6 +
 include/usb/lin_gadget_compat.h  |   24 +-
 5 files changed, 1472 insertions(+), 2 deletions(-)
 create mode 100644 drivers/usb/gadget/composite.c
 create mode 100644 include/linux/usb/composite.h

-- 
1.7.2.3

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

[U-Boot] [PATCH v4 3/3] usb:udc:samsung Add functions for storing private gadget data in UDC driver

2012-04-18 Thread Lukasz Majewski

This commit adds support for storing private data to Samsung's UDC
driver. This data is afterward used by usb gadget.

Signed-off-by: Lukasz Majewski l.majew...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Cc: Marek Vasut ma...@denx.de
---
 drivers/usb/gadget/s3c_udc_otg.c |   12 
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/drivers/usb/gadget/s3c_udc_otg.c b/drivers/usb/gadget/s3c_udc_otg.c
index f7f7b54..925d2f2 100644
--- a/drivers/usb/gadget/s3c_udc_otg.c
+++ b/drivers/usb/gadget/s3c_udc_otg.c
@@ -133,6 +133,18 @@ static void nuke(struct s3c_ep *ep, int status);
 static int s3c_udc_set_halt(struct usb_ep *_ep, int value);
 static void s3c_udc_set_nak(struct s3c_ep *ep);
 
+void set_udc_gadget_private_data(void *p)
+{
+   DEBUG_SETUP(%s: the_controller: 0x%p, p: 0x%p\n, __func__,
+  the_controller, p);
+   the_controller-gadget.dev.device_data = p;
+}
+
+void *get_udc_gadget_private_data(struct usb_gadget *gadget)
+{
+   return gadget-dev.device_data;
+}
+
 static struct usb_ep_ops s3c_ep_ops = {
.enable = s3c_ep_enable,
.disable = s3c_ep_disable,
-- 
1.7.2.3

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

[U-Boot] [PATCH v4 1/3] usb:gadget:composite USB composite gadget support

2012-04-18 Thread Lukasz Majewski

USB Composite gadget implementation for u-boot. It builds on top
of USB UDC drivers.

This commit is based on following files from Linux Kernel v2.6.36:

./include/linux/usb/composite.h
./drivers/usb/gadget/composite.c

SHA1: d187abb9a83e6c6b6e9f2ca17962bdeafb4bc903

Signed-off-by: Lukasz Majewski l.majew...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Cc: Marek Vasut ma...@denx.de

---
 drivers/usb/gadget/composite.c  | 1082 +++
 include/linux/usb/composite.h   |  350 +
 include/usb/lin_gadget_compat.h |   24 +-
 3 files changed, 1454 insertions(+), 2 deletions(-)
 create mode 100644 drivers/usb/gadget/composite.c
 create mode 100644 include/linux/usb/composite.h

diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
new file mode 100644
index 000..905077d
--- /dev/null
+++ b/drivers/usb/gadget/composite.c
@@ -0,0 +1,1082 @@
+/*
+ * composite.c - infrastructure for Composite USB Gadgets
+ *
+ * Copyright (C) 2006-2008 David Brownell
+ * U-boot porting: Lukasz Majewski l.majew...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+#undef DEBUG
+
+#include linux/bitops.h
+#include linux/usb/composite.h
+
+#define USB_BUFSIZ 4096
+
+static struct usb_composite_driver *composite;
+
+/**
+ * usb_add_function() - add a function to a configuration
+ * @config: the configuration
+ * @function: the function being added
+ * Context: single threaded during gadget setup
+ *
+ * After initialization, each configuration must have one or more
+ * functions added to it.  Adding a function involves calling its @bind()
+ * method to allocate resources such as interface and string identifiers
+ * and endpoints.
+ *
+ * This function returns the value of the function's bind(), which is
+ * zero for success else a negative errno value.
+ */
+int usb_add_function(struct usb_configuration *config,
+   struct usb_function *function)
+{
+   int value = -EINVAL;
+
+   debug(adding '%s'/%p to config '%s'/%p\n,
+   function-name, function,
+   config-label, config);
+
+   if (!function-set_alt || !function-disable)
+   goto done;
+
+   function-config = config;
+   list_add_tail(function-list, config-functions);
+
+   if (function-bind) {
+   value = function-bind(config, function);
+   if (value  0) {
+   list_del(function-list);
+   function-config = NULL;
+   }
+   } else
+   value = 0;
+
+   if (!config-fullspeed  function-descriptors)
+   config-fullspeed = 1;
+   if (!config-highspeed  function-hs_descriptors)
+   config-highspeed = 1;
+
+done:
+   if (value)
+   debug(adding '%s'/%p -- %d\n,
+   function-name, function, value);
+   return value;
+}
+
+/**
+ * usb_function_deactivate - prevent function and gadget enumeration
+ * @function: the function that isn't yet ready to respond
+ *
+ * Blocks response of the gadget driver to host enumeration by
+ * preventing the data line pullup from being activated.  This is
+ * normally called during @bind() processing to change from the
+ * initial ready to respond state, or when a required resource
+ * becomes available.
+ *
+ * For example, drivers that serve as a passthrough to a userspace
+ * daemon can block enumeration unless that daemon (such as an OBEX,
+ * MTP, or print server) is ready to handle host requests.
+ *
+ * Not all systems support software control of their USB peripheral
+ * data pullups.
+ *
+ * Returns zero on success, else negative errno.
+ */
+int usb_function_deactivate(struct usb_function *function)
+{
+   struct usb_composite_dev*cdev = function-config-cdev;
+   int status = 0;
+
+   if (cdev-deactivations == 0)
+   status = usb_gadget_disconnect(cdev-gadget);
+   if (status == 0)
+   cdev-deactivations++;
+
+   return status;
+}
+
+/**
+ * usb_function_activate - allow function and gadget enumeration
+ * @function: function on which usb_function_activate() was called
+ *
+ * Reverses effect of usb_function_deactivate().  If no more

[U-Boot] [PATCH v4 2/3] usb:gadget:composite: Support for composite at gadget.h

2012-04-18 Thread Lukasz Majewski

Add device data pointer to the USB gadget's device struct.
Wrapper for extracting usb_gadget from Linux's usb device

Signed-off-by: Lukasz Majewski l.majew...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Cc: Marek Vasut ma...@denx.de

---
 include/linux/usb/gadget.h |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index 275cb5f..eba865e 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -411,6 +411,7 @@ struct usb_gadget_ops {
 
 struct device {
void*driver_data;   /* data private to the driver */
+   void*device_data;   /* data private to the device */
 };
 
 /**
@@ -481,6 +482,11 @@ static inline void *get_gadget_data(struct usb_gadget 
*gadget)
return gadget-dev.driver_data;
 }
 
+static inline struct usb_gadget *dev_to_usb_gadget(struct device *dev)
+{
+   return container_of(dev, struct usb_gadget, dev);
+}
+
 /* iterates the non-control endpoints; 'tmp' is a struct usb_ep pointer */
 #define gadget_for_each_ep(tmp, gadget) \
list_for_each_entry(tmp, (gadget)-ep_list, ep_list)
-- 
1.7.2.3

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

Re: [U-Boot] [RFC] Preventing overriding of serverip when set in environment by user

2012-04-18 Thread Wolfgang Denk

Dear Maupin, Chase,

In message 7d46e86ec0a8354091174257b2fed10138dd6...@dlee12.ent.ti.com you 
wrote:
 
 I recently was trying out a Linksys WRT54G2 V1 router and

Thi sis out-of-tree code, so we cannot help much - we hav eno idea
which modifications they made to the code.

 So the net effect was that the dhcp server in this router was
 providing information in its response packet that was overriding the
 setting I had programmed. I dug into the u-boot code a little and

This is normal, and intended.  If you run DHCP, the information
returned from the server is put in the respective environment
variables.  That's how it works.

Note however, that of course this will not change the persistent copy
of the environment - to do that, you would have to run saveenv.

 The first was to set CONFIG_BOOTP_SERVERIP in my board config file.
 I discarded this because this would seem to make me always ignore the
 serverip setting from the DHCP server, and it seemed likely that
 there were cases where you would want this.

I don;t understand your description here, but indeed, putting
CONFIG_BOOTP_SERVERIP in the config file almost never makes sense, and
it is definitly not acceptable for mainline.

 The second was to check if the serverip was already set in the
 environment and if so then not override that value with the one in
 the response from the DHCP server. The below patch snippet does this

This is not what is supposed to happen.  You are breaking regular
functionality this way.

 Is this the proper way to fix this issue and the right location to
 make the change? The overall goal was to make sure that if I
 specified a particular serverip that I wanted to use, then the DHCP
 server should not be changing that.

No, this is not an acceptable patch.

What exactly _are_ you trying to fix?  What is wrong with using the
DHCP server supplied address?  If it is incorrect, you should fix your
DHCP server configuration.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
You may call me by my name, Wirth, or by my value, Worth.
- Nicklaus Wirth
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC] Preventing overriding of serverip when set in environment by user

2012-04-18 Thread Peter Barada

On 04/18/2012 11:28 AM, Wolfgang Denk wrote:

 Is this the proper way to fix this issue and the right location to
 make the change? The overall goal was to make sure that if I
 specified a particular serverip that I wanted to use, then the DHCP
 server should not be changing that.
 No, this is not an acceptable patch.

 What exactly _are_ you trying to fix?  What is wrong with using the
 DHCP server supplied address?  If it is incorrect, you should fix your
 DHCP server configuration.
I have the same type of problem.

In my case our company controls the DHCP server that hands out addresses
for the network, but I want to use a *local* TFTP server (the one on my
development machine).  I can't modify the DHCP server so if I use dhcp
to get and address u-boot also overwrites serverip.  At home my FiOS
router has a DHCP server (that I can't modify since its closed and is
needed to provide addresses to my TV set top box) that provides
addresses for my network, and has the same problem...

Would an option to dhcp (i.e. one that tells it to *only* modify ipaddr)
suffice? Or would it be better to provide an entirely a new command that
optionally updates the variables in the environment be better? Then
users have the option of using dhcp as is, or for environments like
mine (and apparently Chase) can just get an IP address and go from there...

-- 
Peter Barada
peter.bar...@logicpd.com

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

Re: [U-Boot] [PATCH] PowerPC: Change -fpic flag to -fPIC flag in the config.mk

2012-04-18 Thread Scott Wood

On 04/17/2012 09:44 PM, Chunhe Lan wrote:
 The -fPIC/-fpic flag belongs with -mrelocatable. The -fpic flag can
 limit the size of the GOT and produce smaller binaries, so it causes
 some GOT entries to be lost in the gcc 4.6 version. But -fPIC flag
 allows the maximum possible size of the GOT entries.
 
 However, currently -mrelocatable promotes -fpic flag to -fPIC flag.
 
 This reverts that portion of the
 commit 33ee4c92339ee386662c0ee2d221098c5cc8b07e.
 
 Signed-off-by: Chunhe Lan chunhe@freescale.com

Please provide a better description, not something partially copied from
the commit message that you're partially reverting.  If -mrelocatable
promotes -fpic to -fPIC how does this change have any effect?  One has
to go back to the commit message of 33ee4c to see that this was a bug
that was fixed in GCC 4.6, so it's no longer currently doing that.

What is the limit for -fpic?  Do we get errors if we overflow, or does
the toolchain silently generate a bad image (sounds like a bug if the
latter)?  What target are you seeing problems with?

Also, when (partially) reverting a patch, please include at least the
subject line of the patch in addition to the SHA-1, and CC the author of
the patch.

-Scott

 ---
  arch/powerpc/config.mk |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
 
 diff --git a/arch/powerpc/config.mk b/arch/powerpc/config.mk
 index a307154..7c14ff6 100644
 --- a/arch/powerpc/config.mk
 +++ b/arch/powerpc/config.mk
 @@ -25,7 +25,7 @@ CROSS_COMPILE ?= ppc_8xx-
  
  CONFIG_STANDALONE_LOAD_ADDR ?= 0x4
  LDFLAGS_FINAL += --gc-sections
 -PLATFORM_RELFLAGS += -fpic -mrelocatable -ffunction-sections -fdata-sections
 +PLATFORM_RELFLAGS += -fPIC -mrelocatable -ffunction-sections -fdata-sections
  PLATFORM_CPPFLAGS += -DCONFIG_PPC -D__powerpc__
  PLATFORM_LDFLAGS  += -n
  


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

Re: [U-Boot] [PATCH 7/9] imx: esdhc: Needed to use in imx-regs.h defined address

2012-04-18 Thread Timo Ketola


On 18.04.2012 18:05, Stefano Babic wrote:

On 18/04/2012 13:05, Timo Ketola wrote:

Stefano Babic wrote:

Timo Ketola wrote:

PPC seems to use a predefined macro from asm/immap_8xxx.h files. Where
is that file included?


It is a different way. The board configuration file includes the
register description file, so for example immap_86xx.h, immap_85xx.h,


Where? I don't see an example.


For PPC86xx I can see at least:

arch/powerpc/cpu/mpc86xx/mpc8641_serdes.c:#includeasm/immap_86xx.h
arch/powerpc/cpu/mpc86xx/mpc8610_serdes.c:#includeasm/immap_86xx.h
board/freescale/mpc8610hpcd/mpc8610hpcd.c:#includeasm/immap_86xx.h
board/freescale/mpc8641hpcn/mpc8641hpcn.c:#includeasm/immap_86xx.h


Yes, I saw those but when you said that board configuration file includes 
those, I thought that you meant the header files in include/configs.



But I see them included in common.h.
Should there be also imx-regs? Seems to work if I do so.


No, this is wrong.

...

Then I tried to include imx-regs.h in fsl_esdhc.c and 'MAKEALL -a arm'
was happy.

Maybe the right fix is to include imx-regs in common.h?


No. common.h, as the name suggests, is for all architectures, not only
for i.MX. We cannot fix i:MX and break other boards.


But why PPC register description files are included there then? For example 
line 87:


#ifdef CONFIG_MPC86xx
#include mpc86xx.h
#include asm/immap_86xx.h
#endif

Is that deprecated?

And how would adding imx file with the same logic break other boards? I mean, 
putting there:


#if defined(CONFIG_MX25) || defined(CONFIG_MX31) || ...
#include asm/arch/imx-regs.h
#endif

But if the board configuration file in include/configs is the correct place to 
include it, I shall then find the obstacle on that approach...


--

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

Re: [U-Boot] [PATCH 4/9] imx: nand: Support flash based BBT

2012-04-18 Thread Scott Wood

On 04/18/2012 02:57 AM, Timo Ketola wrote:
 +#ifdef CONFIG_SYS_NAND_USE_FLASH_BBT
 +
 + this-options = NAND_USE_FLASH_BBT;
 + this-bbt_td = bbt_main_descr;
 + this-bbt_md = bbt_mirror_descr;
 +
 +#endif

Remove those blank lines, and use |= for options like is done with
NAND_BUSWIDTH_16.

-Scott

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

Re: [U-Boot] [PATCH 7/9] imx: esdhc: Needed to use in imx-regs.h defined address

2012-04-18 Thread Timo Ketola


On 18.04.2012 19:27, Timo Ketola wrote:

But if the board configuration file in include/configs is the correct place to
include it, I shall then find the obstacle on that approach...


Ok, including  asm/arch/imx-regs.h in board configuration file *and* 
asm/types.h in  asm/arch/imx-regs.h file seems to make build happy. This would 
be the right fix then?


--

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

[U-Boot] [PATCH 0/1] tegra2: move tegra2 SoC code to arch/arm/cpu/tegra2-common

2012-04-18 Thread Allen Martin

This is part of an upcoming patch set to move all armv4t code out of
tegra2 u-boot and put it into an SPL, but I wanted to get some early
feedback on this patch.  This moves most of the tegra2 SoC code from
arch/arm/cpu/armv7 to a new directory arch/arm/cpu/tegra2-common.
This code will be shared between the armv7 and armv4t builds of
tegra2.

-Allen
nvpublic

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

[U-Boot] fatls/fatload for NAND (partition)

2012-04-18 Thread peterlu


Has anyone tried/incorporated the use of the FAT tools to access NAND
storage?  I know one can use fatls on usb and mmc (which are boot
devices), but it seems natural that one should be able to use the FAT tools
on NAND as well, perhaps through some pseudo-device (that maps to some NAND
partition(s)).  This would allow Linux to set up some mtd partition(s) as
vfat and U-boot to get to the same partition(s) as well.

Thanks for any input.

PL

-- 
View this message in context: 
http://old.nabble.com/fatls-fatload-for-NAND-%28partition%29-tp33709724p33709724.html
Sent from the Uboot - Users mailing list archive at Nabble.com.

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

Re: [U-Boot] fatls/fatload for NAND (partition)

2012-04-18 Thread Scott Wood

On 04/18/2012 01:22 PM, peterlu wrote:
 
 Has anyone tried/incorporated the use of the FAT tools to access NAND
 storage?  I know one can use fatls on usb and mmc (which are boot
 devices), but it seems natural that one should be able to use the FAT tools
 on NAND as well, perhaps through some pseudo-device (that maps to some NAND
 partition(s)).  This would allow Linux to set up some mtd partition(s) as
 vfat and U-boot to get to the same partition(s) as well.

You would need a flash translation layer in between the FAT filesystem
and raw NAND.

Any reason not to use ubifs instead?

-Scott

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

Re: [U-Boot] [RFC] Preventing overriding of serverip when set in environment by user

2012-04-18 Thread Chase Maupin

 -Original Message-
 From: Wolfgang Denk [mailto:w...@denx.de]
 Sent: Wednesday, April 18, 2012 10:28 AM
 To: Maupin, Chase
 Cc: u-boot@lists.denx.de; Rini, Tom
 Subject: Re: [U-Boot] [RFC] Preventing overriding of serverip when
 set in environment by user

 Dear Maupin, Chase,

 In message
 7d46e86ec0a8354091174257b2fed10138dd6...@dlee12.ent.ti.com you
 wrote:

  I recently was trying out a Linksys WRT54G2 V1 router and

 Thi sis out-of-tree code, so we cannot help much - we hav eno idea
 which modifications they made to the code.

  So the net effect was that the dhcp server in this router was
  providing information in its response packet that was overriding
 the
  setting I had programmed. I dug into the u-boot code a little and

 This is normal, and intended.  If you run DHCP, the information
 returned from the server is put in the respective environment
 variables.  That's how it works.

 Note however, that of course this will not change the persistent
 copy
 of the environment - to do that, you would have to run saveenv.

  The first was to set CONFIG_BOOTP_SERVERIP in my board config
 file.
  I discarded this because this would seem to make me always ignore
 the
  serverip setting from the DHCP server, and it seemed likely that
  there were cases where you would want this.

 I don;t understand your description here, but indeed, putting
 CONFIG_BOOTP_SERVERIP in the config file almost never makes sense,
 and
 it is definitly not acceptable for mainline.

  The second was to check if the serverip was already set in the
  environment and if so then not override that value with the one
 in
  the response from the DHCP server. The below patch snippet does
 this

 This is not what is supposed to happen.  You are breaking regular
 functionality this way.

  Is this the proper way to fix this issue and the right location
 to
  make the change? The overall goal was to make sure that if I
  specified a particular serverip that I wanted to use, then the
 DHCP
  server should not be changing that.

 No, this is not an acceptable patch.

 What exactly _are_ you trying to fix?  What is wrong with using the
 DHCP server supplied address?  If it is incorrect, you should fix
 your
 DHCP server configuration.

I can see your point.  Why treat serverip any different than the ipaddr 
returned from the DHCP server?  I guess this can be worked around by resetting 
serverip between the dhcp command and the tftp command (using autoload off).  
Or I can take the approach I am currently using which is to put the linksys 
router away and buy a cheap trendnet router that doesn't do this :)

 Best regards,

 Wolfgang Denk

 --
 DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev
 Zundel
 HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell,
 Germany
 Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email:
 w...@denx.de
 You may call me by my name, Wirth, or by my value, Worth.
 - Nicklaus Wirth

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

Re: [U-Boot] [RFC] Preventing overriding of serverip when set in environment by user

2012-04-18 Thread Wolfgang Denk

Dear Peter Barada,

In message 4f8ee1e1.1060...@logicpd.com you wrote:

  What exactly _are_ you trying to fix?  What is wrong with using the
  DHCP server supplied address?  If it is incorrect, you should fix your
  DHCP server configuration.
 I have the same type of problem.
 
 In my case our company controls the DHCP server that hands out addresses
 for the network, but I want to use a *local* TFTP server (the one on my
 development machine).  I can't modify the DHCP server so if I use dhcp
 to get and address u-boot also overwrites serverip.  At home my FiOS

If you know the DHCP server provides an address you don;t want to use,
and if you know the address that you want to use, then why don't you
just use it?

Something like:

= setenv tftpserverip 192.168.12.34
= setenv autoload no
= dhcp
= setenv ipaddr ${tftpserverip}
= tftp ...

?

 Would an option to dhcp (i.e. one that tells it to *only* modify ipaddr)
 suffice? Or would it be better to provide an entirely a new command that
 optionally updates the variables in the environment be better? Then
 users have the option of using dhcp as is, or for environments like
 mine (and apparently Chase) can just get an IP address and go from there...

Why make it complicated when a few simple commands are sufficient?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Where would we be without rhetorical questions?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC] Preventing overriding of serverip when set in environment by user

2012-04-18 Thread Wolfgang Denk

Dear Chase,

In message 7d46e86ec0a8354091174257b2fed10138dd6...@dlee12.ent.ti.com you 
wrote:

 Sorry, I didn't mean I was talking about the code on the router.  I meant I 
 was using the router as my DHCP server for my Linux host and my development 
 board.

Cab you please restrict your line length to some 70 characters or so?
Thanks.

Well, when it's your box, then why don't you configure the DHCP
server correctly?

 First, thanks for your response. What I am trying to fix is that I
 have a development board that is connected to my Linux host using a
 Linksys WRT54G2 router. That particular router is returning a setting
 in DHCP that points to the Linksys router itself as the server. In
 this case I want my serverip to point to my Linux host which is
 running a TFTP server.

As mentioned, all you have to do is to configure your DHCP server
correctly.  It is perfectly normal to use different servers for DHCP
and TFTP.  All you have to do is to configure the next-server
parameter in DHCP to point to the TFTP server

 Other routers such as a Trendnet WRLS-N300 do not exhibit this
 problem so this seems to be an issue with the DHCP response on the
 Linksys router. ...

This is a configuration option for the DHCP server.

 ... However, thinking about this my reasoning was that if
 a user were to take the time to set a value for serverip in their
 u-boot environment then the network router should not override that

Who says it was the user who set this variable? It could as well be
the result from a previous call to DHCP which returned different
results (for example, because there is a pool of DHCP servers).

 setting. I think of this as who should be the authority in the
 system. If the user has specified a setting shouldn't that have more
 authority than the default setup of the DHCP server, since the user
 should be more knowledgeable about their particular configuration?

There is a pretty clear definition here: trhe documentation says that
the DHCP command may set a certain number of (documented!) environment
variables.  If you think you want to ignore any of these settings,
then just make sure to set these to the values you like after running
the DHCP command, thus ignoring the DHCP settings.

This can be done with 2 lines of trivial scripting and does not
require any code changes (see my previous message).

 As for fixing the DHCP server configuration I see two cases where
 this can be an issue:
 
 1. In the case of this Linksys router I found no option allowing me
 to change the DHCP server configuration other than to change what
 range of addresses it provides. So this would lead to needing to

Are you absolutely sure that the Linksys router does not support the
next-server parameter in it's configuration?

 modify the router firmware. 2. What about an environment with a
 shared DHCP server, where often times you may want the default value
 of the DHCP server for 95% of your use cases, but a particular user
 may want to override this setting.

Then just ognore the resuylts returnd by the DHCP server.  It is all
at your hands.  Nobody forces you to use the address returned by the
DHCP call for your TFTP downloads.

 The goal of this patch was to enable user's to override the DHCP
 server setting by taking a pro-active action of defining serverip. In

But this is wrong, as you cannot know how the nvironment variable got
set, and if it actually contains a usable value.  DHCP is _supposed_
to overwrite this variable with a valid setting.  Ofcourse, it is up
to you if you use these results, or if you ignore them.

 server could provide a value if it was configured this way. Again, it
 is all back to who should have ultimate authority in the system. But,

It is the user who has this authority.  Which is exactly why I will
not accept this patch - it would implement some policy which you think
fits for your purposes - but it does not fit in general.

 I can also understand your position in that if I asked the DHCP
 server for information I should honor the information it gives me,
 and if the DHCP server is giving bad information then fix the server
 (which may not always be possible/practical). It would always be
 possible to work around this by turning autoload off and then
 changing the bootcmd to do:
 
 dhcp; setenv serverip xxx.xxx.xxx.xxx; tftp
 
 Would that be our recommendation?

Yes, indeed.  If you want to ignore the server reply, then please do
this explicitly.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Let the programmers be many and the managers few -- then all will  be
productive.   -- Geoffrey James, The Tao of Programming
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

2012-04-18 Thread Wolfgang Denk

Dear Albert ARIBAUD,

In message 4f8d762c.5020...@aribaud.net you wrote:
 Hi Wolfgang,
 
 The following changes since commit f5cdc11775c4b7fdbf52a6dd2f463d329804ab11:
 
Prepare v2012.04-rc2; minor Coding Style cleanup (2012-04-16 23:13:51 
 +0200)
 
 are available in the git repository at:
git://git.denx.de/u-boot-arm master
 
 Dirk Behme (1):
i.MX6: arm2: Add AXI cache and Qos setting
 
   board/freescale/mx6qarm2/imximage.cfg |6 ++
   1 files changed, 6 insertions(+), 0 deletions(-)

Applied, thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
No problem is so formidable that you can't walk away from it.
- C. Schulz
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Pull request: u-boot-sh

2012-04-18 Thread Wolfgang Denk

Dear Nobuhiro Iwamatsu,

In message CABMQnVJA1-hgR44Cdi9=wq33ftp26tdyaipunmpcg4fdcqs...@mail.gmail.com 
you wrote:
 Dear Wolfgang Denk,
 
 Please pull some fixes for v2012.04.
 
 The following changes since commit f5cdc11775c4b7fdbf52a6dd2f463d329804ab11=
 :
 
  Prepare v2012.04-rc2; minor Coding Style cleanup (2012-04-16 23:13:51 +020=
 0)
 
 are available in the git repository at:
 
  git://git.denx.de/u-boot-sh.git master
 
 for you to fetch changes up to 77fe6e773af762676f4f30f646caa160e39a0bcc:
 
  sh: ecovec: Change macro from BOARD_LATE_INIT to
 CONFIG_BOARD_LATE_INIT (2012-04-18 11:16:46 +0900)
 
 
 Nobuhiro Iwamatsu (1):
  sh: ecovec: Change macro from BOARD_LATE_INIT to CONFIG_BOARD_LATE_INI=
 T
 
 Phil Edworthy (1):
  sh: Fix rsk7264 pin setup for on-board ethernet
 
  board/renesas/rsk7264/lowlevel_init.S |2 +-
  include/configs/ecovec.h  |2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)

Applied, thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
A modem is a baudy house.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] powerpc/85xx: Add USB device-tree fixup for various platforms

2012-04-18 Thread Andy Fleming

On Mon, Mar 26, 2012 at 9:15 AM, Ramneek Mehresh
ramneek.mehr...@freescale.com wrote:
 Add USB device-tree fixup for following platforms:
 MPC8536DS, P1022DS, P1023RDS, P2020COME, P2020DS, P2041RDB, P3060QDS

 Signed-off-by: Ramneek Mehresh ramneek.mehr...@freescale.com
 ---
 diff --git a/board/freescale/p2020come/p2020come.c 
 b/board/freescale/p2020come/p2020come.c
 index 8cf7bee..ce78016 100644
 --- a/board/freescale/p2020come/p2020come.c
 +++ b/board/freescale/p2020come/p2020come.c
 @@ -1,5 +1,5 @@
  /*
 - * Copyright 2009 Freescale Semiconductor, Inc.
 + * Copyright 2009,2012 Freescale Semiconductor, Inc.
  *
  * See file CREDITS for list of people who contributed to this
  * project.
 @@ -282,6 +282,10 @@ void ft_board_setup(void *blob, bd_t *bd)

        fdt_fixup_memory(blob, (u64)base, (u64)size);

 +#ifdef CONFIG_HAS_FSL_DR_USB
 +       fdt_fixup_dr_usb(blob, bd);
 +#endif
 +
        fdt_fixup_dr_usb(blob, bd);


Umm I don't think this is right. :)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [STATUS] v2012.04-rc2 and -rc3 are out

2012-04-18 Thread Wolfgang Denk

Hi everybody,

sorry, I forgot to announce the 2012.04-rc2 pre-release two days ago,
so I will atleast announce that we have

v2012.04-rc3

now.

Please help testing, so we can fix the remaining issues before the
release, which I still want to push out April 21, 2012.

Thanks to all who helped.


Please make sure that all your important bug fixes have been included!


I will also start a next branch now, so if you have anything
pending there, please feel free to send pull requests for next !

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
There is a time in the tides of men, Which, taken at its flood, leads
on to success. On the other hand, don't count on it.   - T. K. Lawson
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PULL] u-boot-staging/ma...@denx.de :: FOR u-boot/-next

2012-04-18 Thread Wolfgang Denk

Dear Marek Vasut,

In message 201204060455.17359.ma...@denx.de you wrote:
 The following changes since commit c008b6f6dd6b8965e9a7654ffbce75bb9ff7a3b5:
 
   Prepare v2012.04-rc1 (2012-03-31 00:13:05 +0200)
 
 are available in the git repository at:
 
   git://git.denx.de/u-boot-staging.git ma...@denx.de
 
 for you to fetch changes up to c98167f1df33c6273355050fc0dbbdb73aec51ea:
 
   MIPS: start.S: refactor reset and exception vector setup (2012-03-31 
 22:51:57 
 +0200)
 
 
 Daniel Schwierzeck (6):
   MIPS: board.c: fix init of flash data in bd_info
   MIPS: add register definition for EBase register
   MIPS: make cache operation mode configurable in dcache_enable()
   MIPS: add header file for generic GPIO API
   MIPS: extend cache initialization for recent MIPS CPU cores
   MIPS: start.S: refactor reset and exception vector setup
 
  README   |5 +
  arch/mips/cpu/mips32/cache.S |   16 +++-
  arch/mips/cpu/mips32/start.S |  204 
 ++
  arch/mips/include/asm/gpio.h |   13 +++
  arch/mips/include/asm/mipsregs.h |   20 
  arch/mips/lib/board.c|8 +-
  6 files changed, 112 insertions(+), 154 deletions(-)
  create mode 100644 arch/mips/include/asm/gpio.h

Applied to next, thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
What if is a trademark of Hewlett Packard, so stop using it in your
sentences without permission, or risk being sued.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] fix IDE_BUS(dev) macro

2012-04-18 Thread David Purdy

On Tue, Apr 17, 2012 at 2:06 PM, Luka Perkov ub...@lukaperkov.net wrote:
 IDE_BUS assumes that each bus has two devices and thus returns the first
 bus even when the second one should be probed.

 Signed-off-by: Simon Baatz gmbno...@gmail.com
 Tested-by: Luka Perkov ub...@lukaperkov.net
 ---

 Simon discovered this while adding support for new board IB NAS6210.

 More info can be found here:

 http://lists.denx.de/pipermail/u-boot/2012-April/122525.html

 When this is commited I will do a coding style cleanup. There are tabs
 after few #define parts in include/ide.h.

  include/ide.h |    2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/include/ide.h b/include/ide.h
 index 8ecc9dd..385e909 100644
 --- a/include/ide.h
 +++ b/include/ide.h
 @@ -24,7 +24,7 @@
  #ifndef        _IDE_H

Simon, Luka, Prafulla, etal,

I've tested this out on the Seagate GoFlex Net (Kirkwood) device,
which also has dual SATA ports, and it resolved the long-standing (and
irritating) bug/unwanted-feature that required us to boot from _only_
the right side port.

I would guess that other Kirkwood dual-SATA-port boxes would be
happier because of this, as well.

Nice catch, Simon.

regards,

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

[U-Boot] nboot won't boot my uImage

2012-04-18 Thread Bishop, Mark

I can download my kernel uImage and flash it into NAND and then 'boot'
and it works.

bfin tftp 0x100 10.100.42.29:uImage.3
bfin nand erase 0x8 0x80
bfin nand write 0x100 0x8 0x80

Going to verify the image:
bfin nand read 0x200 0x8 $(filesize)
bfin iminfo 0x200

## Checking Image at 0200 ...
   Legacy image found
   Image Name:   bf548-0.2-3.0.8-ADI-2011R1-dirty
   Created:  2012-04-15  23:30:18 UTC
   Image Type:   Blackfin Linux Kernel Image (gzip compressed)
   Data Size:5218920 Bytes = 5 MiB
   Load Address: 1000
   Entry Point:  0026de3c
   Verifying Checksum ... OK
bfin

And then I can boot:
bfin boot
Loading from nand0, offset 0x80
** Unknown image type
## Booting kernel from Legacy Image at 0100 ...
   Image Name:   bf548-0.2-3.0.8-ADI-2011R1-dirty
..

And if I do a soft reset I can still boot, every time.
But when I cycle the power I get this:
.
Hit any key to stop autoboot:  0

Loading from nand0, offset 0x80
** Unknown image type
Wrong Image Format for bootm command
ERROR: can't get kernel image!
bfin

my boot command is: nandboot=nboot 0x200 0 0x80;run
nandargs;bootm

Any ideas?  This used to work :) without failure until I updated uboot
from an older version to something a bit more recent.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] nboot won't boot my uImage

2012-04-18 Thread Bishop, Mark

 -Original Message-
 From: u-boot-boun...@lists.denx.de [mailto:u-boot-
 boun...@lists.denx.de] On Behalf Of Bishop, Mark
 Sent: Wednesday, April 18, 2012 5:28 PM
 To: u-boot@lists.denx.de
 Subject: [U-Boot] nboot won't boot my uImage

 I can download my kernel uImage and flash it into NAND and then 'boot'
 and it works.

deleted a stupid email

*sigh*  Fat fingered an extra 0 in the address and the reason why it
boots at all is because the tftp download address and the bootm address
are the same.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] tegra2: move tegra2 SoC code to arch/arm/cpu/tegra2-common

2012-04-18 Thread Allen Martin

In preparation for splitting out the armv4t code from tegra2, move the
tegra2 SoC code to arch/arm/cpu/tegra2-common.  This code will be
compiled armv4t for the arm7tdmi and armv7 for the cortex A9.

Signed-off-by: Allen Martin amar...@nvidia.com
---
Resending this with git format-patch -M to make it more readable
and removing cover letter

This is part of an upcoming patch set to move all armv4t code out of
tegra2 u-boot and put it into an SPL, but I wanted to get some early
feedback on this patch.  This moves most of the tegra2 SoC code from
arch/arm/cpu/armv7 to a new directory arch/arm/cpu/tegra2-common.
This code will be shared between the armv7 and armv4t builds of
tegra2.

 Makefile   |3 +
 arch/arm/cpu/armv7/tegra2/Makefile |   12 +
 arch/arm/cpu/tegra2-common/Makefile|   56 
 .../arm/cpu/{armv7/tegra2 = tegra2-common}/ap20.c |0
 .../arm/cpu/{armv7/tegra2 = tegra2-common}/ap20.h |0
 .../cpu/{armv7/tegra2 = tegra2-common}/board.c|0
 .../cpu/{armv7/tegra2 = tegra2-common}/clock.c|0
 .../cpu/{armv7/tegra2 = tegra2-common}/funcmux.c  |0
 .../tegra2 = tegra2-common}/lowlevel_init.S   |0
 .../cpu/{armv7/tegra2 = tegra2-common}/pinmux.c   |0
 .../cpu/{armv7/tegra2 = tegra2-common}/sys_info.c |0
 .../cpu/{armv7/tegra2 = tegra2-common}/timer.c|0
 spl/Makefile   |4 ++
 13 files changed, 65 insertions(+), 10 deletions(-)
 create mode 100644 arch/arm/cpu/tegra2-common/Makefile
 rename arch/arm/cpu/{armv7/tegra2 = tegra2-common}/ap20.c (100%)
 rename arch/arm/cpu/{armv7/tegra2 = tegra2-common}/ap20.h (100%)
 rename arch/arm/cpu/{armv7/tegra2 = tegra2-common}/board.c (100%)
 rename arch/arm/cpu/{armv7/tegra2 = tegra2-common}/clock.c (100%)
 rename arch/arm/cpu/{armv7/tegra2 = tegra2-common}/funcmux.c (100%)
 rename arch/arm/cpu/{armv7/tegra2 = tegra2-common}/lowlevel_init.S (100%)
 rename arch/arm/cpu/{armv7/tegra2 = tegra2-common}/pinmux.c (100%)
 rename arch/arm/cpu/{armv7/tegra2 = tegra2-common}/sys_info.c (100%)
 rename arch/arm/cpu/{armv7/tegra2 = tegra2-common}/timer.c (100%)

diff --git a/Makefile b/Makefile
index 4ddf8d6..6639de0 100644
--- a/Makefile
+++ b/Makefile
@@ -319,6 +319,9 @@ endif
 ifeq ($(SOC),exynos)
 LIBS += $(CPUDIR)/s5p-common/libs5p-common.o
 endif
+ifeq ($(SOC),tegra2)
+LIBS += $(OBJTREE)/arch/$(ARCH)/cpu/$(SOC)-common/lib$(SOC)-common.o
+endif
 
 LIBS := $(addprefix $(obj),$(sort $(LIBS)))
 .PHONY : $(LIBS)
diff --git a/arch/arm/cpu/armv7/tegra2/Makefile 
b/arch/arm/cpu/armv7/tegra2/Makefile
index e9ac6c9..34452c4 100644
--- a/arch/arm/cpu/armv7/tegra2/Makefile
+++ b/arch/arm/cpu/armv7/tegra2/Makefile
@@ -22,23 +22,15 @@
 # Foundation, Inc., 59 Temple Place, Suite 330, Boston,
 # MA 02111-1307 USA
 #
-
-# The AVP is ARMv4T architecture so we must use special compiler
-# flags for any startup files it might use.
-CFLAGS_arch/arm/cpu/armv7/tegra2/ap20.o += -march=armv4t
-CFLAGS_arch/arm/cpu/armv7/tegra2/clock.o += -march=armv4t
-
 include $(TOPDIR)/config.mk
 
 LIB=  $(obj)lib$(SOC).o
 
-SOBJS  := lowlevel_init.o
-COBJS-y:= ap20.o board.o clock.o funcmux.o pinmux.o sys_info.o timer.o
 COBJS-$(CONFIG_USB_EHCI_TEGRA) += usb.o
 
 COBJS  := $(COBJS-y)
-SRCS   := $(SOBJS:.o=.S) $(COBJS:.o=.c)
-OBJS   := $(addprefix $(obj),$(COBJS) $(SOBJS))
+SRCS   := $(COBJS:.o=.c)
+OBJS   := $(addprefix $(obj),$(COBJS))
 
 all:$(obj).depend $(LIB)
 
diff --git a/arch/arm/cpu/tegra2-common/Makefile 
b/arch/arm/cpu/tegra2-common/Makefile
new file mode 100644
index 000..8de59cf
--- /dev/null
+++ b/arch/arm/cpu/tegra2-common/Makefile
@@ -0,0 +1,56 @@
+#
+# (C) Copyright 2010,2011 Nvidia Corporation.
+#
+# (C) Copyright 2000-2008
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+# The AVP is ARMv4T architecture so we must use special compiler
+# flags for any startup files it might use.
+CFLAGS_arch/arm/cpu/tegra2-common/ap20.o += -march=armv4t
+CFLAGS_arch/arm/cpu/tegra2-common/clock.o += -march=armv4t
+
+LIB= $(obj)lib$(SOC)-common.o
+
+SOBJS += lowlevel_init.o
+COBJS-y

Re: [U-Boot] [PATCH] powerpc/usb: fix bug of CPU halt when missing USB PHY clock

2012-04-18 Thread Andy Fleming

Pinging you on this, again. Also, I've now moved the patch to Marek's
queue, instead of mine.

On Sun, Feb 26, 2012 at 8:44 PM, Liu Shengzhou-B36685
b36...@freescale.com wrote:

 -Original Message-
 From: Marek Vasut [mailto:ma...@denx.de]
 Sent: Monday, February 27, 2012 7:13 AM
 To: u-boot@lists.denx.de
 Cc: Liu Shengzhou-B36685
 Subject: Re: [U-Boot] [PATCH] powerpc/usb: fix bug of CPU halt when
 missing USB PHY clock

  when missing USB PHY clock and issuing usb start at u-boot prompt,
  writing to or_portsc register will cause CPU halt. We should check
  USBGP[PHY_CLK_VALID] bit at the first time in ehci_hcd_init() to
 avoid
  CPU hang in this case.
 
  Signed-off-by: Shengzhou Liu shengzhou@freescale.com
  ---
   drivers/usb/host/ehci-fsl.c |   22 +++---
   1 files changed, 19 insertions(+), 3 deletions(-)
 
 Hi,

 what's the status of this patch/patchset?

 Thanks
 M

 Currently we found that usb CTRL_PHY_CLK_VALID bit breaks on P1022 platform, 
 which not contains this bit.
  - P1023/P3041/P5020 etc, have this bit
  - P3060/4080/PSC913x do have this bit, but not mentioned in RM.
  - P1022(perhaps and other) has no this bit
 I'm waiting for the response from FSL silicon team to confirm whether there 
 is other platform
 not including this bit or not, so this patch maybe have to be pending until I 
 get confirmation.

 Thanks,
 Shengzhou


 ___
 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] powerpc/usb: fix bug of CPU halt when missing USB PHY clock

2012-04-18 Thread Marek Vasut

Dear Andy Fleming,

 Pinging you on this, again. Also, I've now moved the patch to Marek's
 queue, instead of mine.

Thanks! Did the FSL silicon team respond already?

 
 On Sun, Feb 26, 2012 at 8:44 PM, Liu Shengzhou-B36685
 
 b36...@freescale.com wrote:
  -Original Message-
  From: Marek Vasut [mailto:ma...@denx.de]
  Sent: Monday, February 27, 2012 7:13 AM
  To: u-boot@lists.denx.de
  Cc: Liu Shengzhou-B36685
  Subject: Re: [U-Boot] [PATCH] powerpc/usb: fix bug of CPU halt when
  missing USB PHY clock
  
   when missing USB PHY clock and issuing usb start at u-boot prompt,
   writing to or_portsc register will cause CPU halt. We should check
   USBGP[PHY_CLK_VALID] bit at the first time in ehci_hcd_init() to
  
  avoid
  
   CPU hang in this case.
   
   Signed-off-by: Shengzhou Liu shengzhou@freescale.com
   ---
drivers/usb/host/ehci-fsl.c |   22 +++---
1 files changed, 19 insertions(+), 3 deletions(-)
  
  Hi,
  
  what's the status of this patch/patchset?
  
  Thanks
  M
  
  Currently we found that usb CTRL_PHY_CLK_VALID bit breaks on P1022
  platform, which not contains this bit. - P1023/P3041/P5020 etc, have
  this bit
   - P3060/4080/PSC913x do have this bit, but not mentioned in RM.
   - P1022(perhaps and other) has no this bit
  I'm waiting for the response from FSL silicon team to confirm whether
  there is other platform not including this bit or not, so this patch
  maybe have to be pending until I get confirmation.
  
  Thanks,
  Shengzhou
  
  
  ___
  U-Boot mailing list
  U-Boot@lists.denx.de
  http://lists.denx.de/mailman/listinfo/u-boot

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

[U-Boot] usb showed wrong device count

2012-04-18 Thread Bob Liu

Hi folks,

After patch: usb: Add support for multiple-LUN mass storage devices
The usb device count isn't correct.

bfin usb start
(Re)start USB...
USB:   scanning bus for devices... 1 USB Device(s) found
   scanning bus for storage devices... max USB Storage Device
reached: 5 stopping
5 Storage Device(s) found
bfin

It used to be:
bfin usb start
(Re)start USB...
USB:   scanning bus for devices... 1 USB Device(s) found
   scanning bus for storage devices... 1 USB Device(s) found
bfin

Any idea? thanks.

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

Re: [U-Boot] [STATUS] v2012.04-rc2 and -rc3 are out

2012-04-18 Thread Dirk Behme


On 18.04.2012 23:10, Wolfgang Denk wrote:

Hi everybody,

sorry, I forgot to announce the 2012.04-rc2 pre-release two days ago,
so I will atleast announce that we have

v2012.04-rc3

now.


Thanks :)


Please help testing, so we can fix the remaining issues before the
release, which I still want to push out April 21, 2012.

Thanks to all who helped.


Please make sure that all your important bug fixes have been included!


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

Thanks

Dirk

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

[U-Boot] [PATCH][v2]powerpc/85xx: Add USB device-tree fixup for various platforms

2012-04-18 Thread Ramneek Mehresh

Add USB device-tree fixup for following platforms:
MPC8536DS, P1022DS, P1023RDS, P2020COME, P2020DS, P2041RDB, P3060QDS

Signed-off-by: Ramneek Mehresh ramneek.mehr...@freescale.com
---
Changes for v2:
- removed extra call to fdt_fixup_dr_usb()
  outside CONFIG_HAS_FSL_DR_USB macro for
  p2020come 

 board/freescale/mpc8536ds/mpc8536ds.c |7 ++-
 board/freescale/p1022ds/p1022ds.c |6 +-
 board/freescale/p1023rds/p1023rds.c   |6 +-
 board/freescale/p2020come/p2020come.c |4 +++-
 board/freescale/p2020ds/p2020ds.c |6 +-
 board/freescale/p2041rdb/p2041rdb.c   |6 +-
 board/freescale/p3060qds/p3060qds.c   |6 +-
 include/configs/MPC8536DS.h   |5 -
 include/configs/P1022DS.h |5 -
 include/configs/P1023RDS.h|5 -
 include/configs/P2020COME.h   |6 --
 include/configs/P2020DS.h |5 -
 include/configs/P2041RDB.h|8 +++-
 include/configs/corenet_ds.h  |8 ++--
 14 files changed, 67 insertions(+), 16 deletions(-)

diff --git a/board/freescale/mpc8536ds/mpc8536ds.c 
b/board/freescale/mpc8536ds/mpc8536ds.c
index c9f85c8..fb20192 100644
--- a/board/freescale/mpc8536ds/mpc8536ds.c
+++ b/board/freescale/mpc8536ds/mpc8536ds.c
@@ -1,5 +1,5 @@
 /*
- * Copyright 2008-2010, 2011 Freescale Semiconductor, Inc.
+ * Copyright 2008-2012 Freescale Semiconductor, Inc.
  *
  * See file CREDITS for list of people who contributed to this
  * project.
@@ -295,5 +295,10 @@ void ft_board_setup(void *blob, bd_t *bd)
 #ifdef CONFIG_FSL_SGMII_RISER
fsl_sgmii_riser_fdt_fixup(blob);
 #endif
+
+#ifdef CONFIG_HAS_FSL_MPH_USB
+   fdt_fixup_dr_usb(blob, bd);
+#endif
+
 }
 #endif
diff --git a/board/freescale/p1022ds/p1022ds.c 
b/board/freescale/p1022ds/p1022ds.c
index 456d9b0..f9ba1f8 100644
--- a/board/freescale/p1022ds/p1022ds.c
+++ b/board/freescale/p1022ds/p1022ds.c
@@ -1,5 +1,5 @@
 /*
- * Copyright 2010-2011 Freescale Semiconductor, Inc.
+ * Copyright 2010-2012 Freescale Semiconductor, Inc.
  * Authors: Srikanth Srinivasan srikanth.sriniva...@freescale.com
  *  Timur Tabi ti...@freescale.com
  *
@@ -341,6 +341,10 @@ void ft_board_setup(void *blob, bd_t *bd)
 
fdt_fixup_memory(blob, (u64)base, (u64)size);
 
+#ifdef CONFIG_HAS_FSL_DR_USB
+   fdt_fixup_dr_usb(blob, bd);
+#endif
+
FT_FSL_PCI_SETUP;
 
 #ifdef CONFIG_FSL_SGMII_RISER
diff --git a/board/freescale/p1023rds/p1023rds.c 
b/board/freescale/p1023rds/p1023rds.c
index 546819c..2f87583 100644
--- a/board/freescale/p1023rds/p1023rds.c
+++ b/board/freescale/p1023rds/p1023rds.c
@@ -1,5 +1,5 @@
 /*
- * Copyright 2010-2011 Freescale Semiconductor, Inc.
+ * Copyright 2010-2012 Freescale Semiconductor, Inc.
  *
  * Authors:  Roy Zang tie-fei.z...@freescale.com
  *   Chunhe Lan b25...@freescale.com
@@ -197,6 +197,10 @@ void ft_board_setup(void *blob, bd_t *bd)
 
fdt_fixup_memory(blob, (u64)base, (u64)size);
 
+#ifdef CONFIG_HAS_FSL_DR_USB
+   fdt_fixup_dr_usb(blob, bd);
+#endif
+
fdt_fixup_fman_ethernet(blob);
 }
 #endif
diff --git a/board/freescale/p2020come/p2020come.c 
b/board/freescale/p2020come/p2020come.c
index 8cf7bee..ba4ef87 100644
--- a/board/freescale/p2020come/p2020come.c
+++ b/board/freescale/p2020come/p2020come.c
@@ -1,5 +1,5 @@
 /*
- * Copyright 2009 Freescale Semiconductor, Inc.
+ * Copyright 2009,2012 Freescale Semiconductor, Inc.
  *
  * See file CREDITS for list of people who contributed to this
  * project.
@@ -282,6 +282,8 @@ void ft_board_setup(void *blob, bd_t *bd)
 
fdt_fixup_memory(blob, (u64)base, (u64)size);
 
+#ifdef CONFIG_HAS_FSL_DR_USB
fdt_fixup_dr_usb(blob, bd);
+#endif
 }
 #endif
diff --git a/board/freescale/p2020ds/p2020ds.c 
b/board/freescale/p2020ds/p2020ds.c
index d3af6cf..d9465f9 100644
--- a/board/freescale/p2020ds/p2020ds.c
+++ b/board/freescale/p2020ds/p2020ds.c
@@ -1,5 +1,5 @@
 /*
- * Copyright 2007-2011 Freescale Semiconductor, Inc.
+ * Copyright 2007-2012 Freescale Semiconductor, Inc.
  *
  * See file CREDITS for list of people who contributed to this
  * project.
@@ -261,6 +261,10 @@ void ft_board_setup(void *blob, bd_t *bd)
 
fdt_fixup_memory(blob, (u64)base, (u64)size);
 
+#ifdef CONFIG_HAS_FSL_DR_USB
+   fdt_fixup_dr_usb(blob, bd);
+#endif
+
FT_FSL_PCI_SETUP;
 
 #ifdef CONFIG_FSL_SGMII_RISER
diff --git a/board/freescale/p2041rdb/p2041rdb.c 
b/board/freescale/p2041rdb/p2041rdb.c
index 1f6a34b..51c4310 100644
--- a/board/freescale/p2041rdb/p2041rdb.c
+++ b/board/freescale/p2041rdb/p2041rdb.c
@@ -1,5 +1,5 @@
 /*
- * Copyright 2011 Freescale Semiconductor, Inc.
+ * Copyright 2011,2012 Freescale Semiconductor, Inc.
  *
  * See file CREDITS for list of people who contributed to this
  * project.
@@ -215,6 +215,10 @@ void ft_board_setup(void *blob, bd_t *bd)
 
fdt_fixup_memory(blob, (u64)base, (u64)size);
 
+#if defined(CONFIG_HAS_FSL_DR_USB) ||

73 matches

Mail list logo