Re: [U-Boot] Some thoughts on SPL

2011-12-16 Thread jonsm...@gmail.com
The old lpc3130 port works the way you describe. The problem with it
is that it is on a three year old u-boot.
http://git.lpclinux.com/

It builds a single u-boot image and then slices the SPL piece off from
the front of it.

On Sat, Dec 17, 2011 at 12:38 AM, Simon Glass  wrote:
> Hi,
>
> On Fri, Dec 16, 2011 at 9:20 AM, jonsm...@gmail.com  
> wrote:
>> The CPU I'm working with, the LPC3130, is kind of an in-between CPU
>> for SPL. Instead of a tightly constrained RAM of 16KB or so I have
>> 96KB to work with.  96KB is enough room to support all of the various
>> boot modes (uart, nand, spi, USB, etc) but not enough room for the
>> full uboot command set. So I'm still stuck with the SPL model, but my
>> constraints are much less.
>>
>> One example of a conflict with SPL is NAND support. With SPL you hard
>> code in the NAND type. In my case I have enough room to do NAND type
>> detection. So this has me modifying the #ifdefs in the makefiles to
>> include the NAND detection code in my SPL loader.
>>
>> I'm wondering if SPL could be designed in a more generic manner.
>> Another model would be to use SPL as the base layer for all u-boot
>> builds. You would then start turning on features until full uboot
>> capability was reached. An example of this would be NAND support, the
>> default would be hard coded NAND for all u-boot builds, but turning on
>> NAND detection would increase the size of the build and disable the
>> hard coded support. Another default would be SPL chaining into the
>> next image, turning on the u-boot UI would again make the code larger
>> and disable auto-chaining.
>>
>> The concept is to remove SPL as a special class and turn it into the
>> base layer that everything builds on. Changing the model in this was
>> should make the config files easier to understand. Instead of having a
>> single file combining SPL and full u-boot you'd have two independent
>> ones. In my case I'd build one u-boot config that fits into 96K and
>> another full 250K one. Of course the two config files could each
>> include a common base config.
>>
>> Thoughts?
>
> That's one way to do it, and makes more and more sense as the amount
> of available SRAM increases. Of course some SOCs can even set up their
> SDRAM and read entire programs in, so there are no restrictions. But
> for those with limitations, it makes sense to me to make SPL more a
> cut down build of U-Boot than a special program that pulls in #ifdefed
> code from various places.
>
> Another approach is to just have one U-Boot, but keep everything you
> need to get started in the first 96KB.
>
> I have the beginnings of a patch which allows you to split U-Boot into
> two parts: an initial part which is loaded first, and another part
> which can be loaded later if needed.
>
> It works by telling the linker where to put the code and arranging
> that everything you need early is at the start of the image. During my
> recent forays into SPL I formed the view that it might be another way
> to implement the SPL functionality. It is controlled by a config file
> which specifies function symbols, object files or libraries to include
> in the initial region. It can also work from a run-time profile.
>
> There are problems though. It is normally pretty easy to work out (or
> profile) which code is executed, but it is harder to know which data
> is needed. SPL solves this by linking and the resulting link errors
> when you get it wrong are easy to spot. But I don't have a tool that
> checks that all the code and data you need is within a certain region.
> Static inline functions can be a pain since they appear repeated all
> over the text area. Relocation data needs to stored with the loaded
> section.
>
> In short this 'postload' feature is more complex, but more general.
> Might be useful one day.
>
> Regards,
> Simon
>
>>
>> --
>> Jon Smirl
>> jonsm...@gmail.com
>> ___
>> U-Boot mailing list
>> U-Boot@lists.denx.de
>> http://lists.denx.de/mailman/listinfo/u-boot



-- 
Jon Smirl
jonsm...@gmail.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] Some thoughts on SPL

2011-12-16 Thread Simon Glass
Hi,

On Fri, Dec 16, 2011 at 9:20 AM, jonsm...@gmail.com  wrote:
> The CPU I'm working with, the LPC3130, is kind of an in-between CPU
> for SPL. Instead of a tightly constrained RAM of 16KB or so I have
> 96KB to work with.  96KB is enough room to support all of the various
> boot modes (uart, nand, spi, USB, etc) but not enough room for the
> full uboot command set. So I'm still stuck with the SPL model, but my
> constraints are much less.
>
> One example of a conflict with SPL is NAND support. With SPL you hard
> code in the NAND type. In my case I have enough room to do NAND type
> detection. So this has me modifying the #ifdefs in the makefiles to
> include the NAND detection code in my SPL loader.
>
> I'm wondering if SPL could be designed in a more generic manner.
> Another model would be to use SPL as the base layer for all u-boot
> builds. You would then start turning on features until full uboot
> capability was reached. An example of this would be NAND support, the
> default would be hard coded NAND for all u-boot builds, but turning on
> NAND detection would increase the size of the build and disable the
> hard coded support. Another default would be SPL chaining into the
> next image, turning on the u-boot UI would again make the code larger
> and disable auto-chaining.
>
> The concept is to remove SPL as a special class and turn it into the
> base layer that everything builds on. Changing the model in this was
> should make the config files easier to understand. Instead of having a
> single file combining SPL and full u-boot you'd have two independent
> ones. In my case I'd build one u-boot config that fits into 96K and
> another full 250K one. Of course the two config files could each
> include a common base config.
>
> Thoughts?

That's one way to do it, and makes more and more sense as the amount
of available SRAM increases. Of course some SOCs can even set up their
SDRAM and read entire programs in, so there are no restrictions. But
for those with limitations, it makes sense to me to make SPL more a
cut down build of U-Boot than a special program that pulls in #ifdefed
code from various places.

Another approach is to just have one U-Boot, but keep everything you
need to get started in the first 96KB.

I have the beginnings of a patch which allows you to split U-Boot into
two parts: an initial part which is loaded first, and another part
which can be loaded later if needed.

It works by telling the linker where to put the code and arranging
that everything you need early is at the start of the image. During my
recent forays into SPL I formed the view that it might be another way
to implement the SPL functionality. It is controlled by a config file
which specifies function symbols, object files or libraries to include
in the initial region. It can also work from a run-time profile.

There are problems though. It is normally pretty easy to work out (or
profile) which code is executed, but it is harder to know which data
is needed. SPL solves this by linking and the resulting link errors
when you get it wrong are easy to spot. But I don't have a tool that
checks that all the code and data you need is within a certain region.
Static inline functions can be a pain since they appear repeated all
over the text area. Relocation data needs to stored with the loaded
section.

In short this 'postload' feature is more complex, but more general.
Might be useful one day.

Regards,
Simon

>
> --
> Jon Smirl
> jonsm...@gmail.com
> ___
> 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


[U-Boot] [PATCH] net: Fix arguments in tftpput command

2011-12-16 Thread Simon Glass
The switch to strict_strtoul() was not done correctly - this fixes
the compile error when CONFIG_CMD_TFTPPUT is active.

Signed-off-by: Simon Glass 
---
 common/cmd_net.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/common/cmd_net.c b/common/cmd_net.c
index f89a24b..be7cc01 100644
--- a/common/cmd_net.c
+++ b/common/cmd_net.c
@@ -221,8 +221,8 @@ static int netboot_common(enum proto_t proto, cmd_tbl_t 
*cmdtp, int argc,
 
 #ifdef CONFIG_CMD_TFTPPUT
case 4:
-   save_addr = strict_strtoul(argv[1], NULL, 16);
-   save_size = strict_strtoul(argv[2], NULL, 16);
+   strict_strtoul(argv[1], 16, &save_addr);
+   strict_strtoul(argv[2], 16, &save_size);
copy_filename(BootFile, argv[3], sizeof(BootFile));
break;
 #endif
-- 
1.7.3.1

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


Re: [U-Boot] [PATCH v5 3/3] mx28evk: Add initial support for MX28EVK board

2011-12-16 Thread Marek Vasut
> Hi Fabio,
> 
> On 12/16/2011 12:07 AM, Fabio Estevam wrote:
> > Tested boot via SD card and by loading a kernel via TFTP through
> > the FEC interface.
> 
> Have you any idea why this works from SD card but not by USB recovery
> using exactly same sb file?
> 
> By quick look it seems that control is not passed back to the ROM
> properly after SPL or ROM is unable to load/run U-Boot after SPL.

What do you mean? The SPL only inits the hardware and then lets the bootrom do 
whatever it wants again with the next file in u-boot.bd.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2 3/3] i.mx6q: arm2: Add the enet function support

2011-12-16 Thread Marek Vasut
> This enable the network function on the i.mx6q armadillo2
> board(arm2), thus we can use tftp to load image from network.
> 
> Cc: Stefano Babic 
> Signed-off-by: Jason Liu 
> Tested-by: Dirk Behme 
> 
> ---
> v2: use constant define and remove ETHPRIME config
> ---
>  board/freescale/mx6qarm2/mx6qarm2.c |   90
> +++ include/configs/mx6qarm2.h  | 
>  12 -
>  2 files changed, 100 insertions(+), 2 deletions(-)
> 
> diff --git a/board/freescale/mx6qarm2/mx6qarm2.c
> b/board/freescale/mx6qarm2/mx6qarm2.c index 89e0e76..9894245 100644
> --- a/board/freescale/mx6qarm2/mx6qarm2.c
> +++ b/board/freescale/mx6qarm2/mx6qarm2.c
> @@ -29,6 +29,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
> 
>  DECLARE_GLOBAL_DATA_PTR;
> 
> @@ -40,6 +42,10 @@ DECLARE_GLOBAL_DATA_PTR;
>   PAD_CTL_PUS_47K_UP  | PAD_CTL_SPEED_LOW |   \
>   PAD_CTL_DSE_80ohm   | PAD_CTL_SRE_FAST  | PAD_CTL_HYS)
> 
> +#define ENET_PAD_CTRL  (PAD_CTL_PKE | PAD_CTL_PUE |  \
> + PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED   | \
> + PAD_CTL_DSE_40ohm   | PAD_CTL_HYS)
> +
>  int dram_init(void)
>  {
>   gd->ram_size = get_ram_size((void *)PHYS_SDRAM, PHYS_SDRAM_SIZE);
> @@ -79,11 +85,35 @@ iomux_v3_cfg_t usdhc4_pads[] = {
>   MX6Q_PAD_SD4_DAT7__USDHC4_DAT7 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
>  };
> 
> +iomux_v3_cfg_t enet_pads[] = {
> + MX6Q_PAD_KEY_COL1__ENET_MDIO| MUX_PAD_CTRL(ENET_PAD_CTRL),
> + MX6Q_PAD_KEY_COL2__ENET_MDC | MUX_PAD_CTRL(ENET_PAD_CTRL),
> + MX6Q_PAD_RGMII_TXC__ENET_RGMII_TXC  | MUX_PAD_CTRL(ENET_PAD_CTRL),
> + MX6Q_PAD_RGMII_TD0__ENET_RGMII_TD0  | MUX_PAD_CTRL(ENET_PAD_CTRL),
> + MX6Q_PAD_RGMII_TD1__ENET_RGMII_TD1  | MUX_PAD_CTRL(ENET_PAD_CTRL),
> + MX6Q_PAD_RGMII_TD2__ENET_RGMII_TD2  | MUX_PAD_CTRL(ENET_PAD_CTRL),
> + MX6Q_PAD_RGMII_TD3__ENET_RGMII_TD3  | MUX_PAD_CTRL(ENET_PAD_CTRL),
> + MX6Q_PAD_RGMII_TX_CTL__RGMII_TX_CTL | MUX_PAD_CTRL(ENET_PAD_CTRL),
> + MX6Q_PAD_ENET_REF_CLK__ENET_TX_CLK  | MUX_PAD_CTRL(ENET_PAD_CTRL),
> + MX6Q_PAD_RGMII_RXC__ENET_RGMII_RXC  | MUX_PAD_CTRL(ENET_PAD_CTRL),
> + MX6Q_PAD_RGMII_RD0__ENET_RGMII_RD0  | MUX_PAD_CTRL(ENET_PAD_CTRL),
> + MX6Q_PAD_RGMII_RD1__ENET_RGMII_RD1  | MUX_PAD_CTRL(ENET_PAD_CTRL),
> + MX6Q_PAD_RGMII_RD2__ENET_RGMII_RD2  | MUX_PAD_CTRL(ENET_PAD_CTRL),
> + MX6Q_PAD_RGMII_RD3__ENET_RGMII_RD3  | MUX_PAD_CTRL(ENET_PAD_CTRL),
> + MX6Q_PAD_RGMII_RX_CTL__RGMII_RX_CTL | MUX_PAD_CTRL(ENET_PAD_CTRL),
> +};
> +
> +
>  static void setup_iomux_uart(void)
>  {
>   imx_iomux_v3_setup_multiple_pads(uart4_pads, ARRAY_SIZE(uart4_pads));
>  }
> 
> +static void setup_iomux_enet(void)
> +{
> + imx_iomux_v3_setup_multiple_pads(enet_pads, ARRAY_SIZE(enet_pads));
> +}
> +
>  #ifdef CONFIG_FSL_ESDHC
>  struct fsl_esdhc_cfg usdhc_cfg[2] = {
>   {USDHC3_BASE_ADDR, 1},
> @@ -132,9 +162,69 @@ int board_mmc_init(bd_t *bis)
>  }
>  #endif
> 
> +#define MII_MMD_ACCESS_CTRL_REG  0xd
> +#define MII_MMD_ACCESS_ADDR_DATA_REG 0xe
> +#define MII_DBG_PORT_REG 0x1d
> +#define MII_DBG_PORT2_REG0x1e
> +
> +int fecmxc_mii_postcall(int phy)
> +{
> + unsigned short val;
> +
> + /*
> +  * Due to the i.MX6Q Armadillo2 board HW design,there is
> +  * no 125Mhz clock input from SOC. In order to use RGMII,
> +  * We need enable AR8031 ouput a 125MHz clk from CLK_25M
> +  */
> + miiphy_write("FEC", phy, MII_MMD_ACCESS_CTRL_REG, 0x7);
> + miiphy_write("FEC", phy, MII_MMD_ACCESS_ADDR_DATA_REG, 0x8016);
> + miiphy_write("FEC", phy, MII_MMD_ACCESS_CTRL_REG, 0x4007);
> + miiphy_read("FEC", phy, MII_MMD_ACCESS_ADDR_DATA_REG, &val);
> + val &= 0xffe3;
> + val |= 0x18;

Magic.

> + miiphy_write("FEC", phy, MII_MMD_ACCESS_ADDR_DATA_REG, val);
> +
> + /* For the RGMII phy, we need enable tx clock delay */
> + miiphy_write("FEC", phy, MII_DBG_PORT_REG, 0x5);
> + miiphy_read("FEC", phy, MII_DBG_PORT2_REG, &val);
> + val |= 0x0100;
> + miiphy_write("FEC", phy, MII_DBG_PORT2_REG, val);
> +
> + miiphy_write("FEC", phy, MII_BMCR, 0xa100);
> +
> + return 0;
> +}
> +
> +int board_eth_init(bd_t *bis)
> +{
> + struct eth_device *dev;
> + int ret;
> +
> + ret = cpu_eth_init(bis);
> + if (ret) {
> + printf("FEC MXC: %s:failed\n", __func__);
> + return ret;
> + }
> +
> + dev = eth_get_dev_by_name("FEC");
> + if (!dev) {
> + printf("FEC MXC: Unable to get FEC device entry\n");
> + return -EINVAL;
> + }
> +
> + ret = fecmxc_register_mii_postcall(dev, fecmxc_mii_postcall);
> + if (ret) {
> + printf("FEC MXC: Unable to register FEC mii postcall\n");
> + return ret;
> + }
> +
> + return 0;
> +}
> +
>  int board_early_init_f(void)
>  {
>   setup_iomux_uart();
> + setup_iomux_enet();
> 
>   return 0;
>  }
> diff --git a/incl

Re: [U-Boot] [PATCH v5 3/3] mx28evk: Add initial support for MX28EVK board

2011-12-16 Thread Fabio Estevam
On Fri, Dec 16, 2011 at 12:55 PM, Veli-Pekka Peltola
 wrote:

> Have you any idea why this works from SD card but not by USB recovery using
> exactly same sb file?

Sorry, never tested this 'USB recovery' mode.

I can look at it after I finish the mx28evk patches.

Reagards,

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


Re: [U-Boot] [PATCH] add missing space

2011-12-16 Thread Mike Frysinger
On Friday 16 December 2011 18:43:18 Luka Perkov wrote:
> On Fri, Dec 16, 2011 at 10:59:03AM -0500, Mike Frysinger wrote:
> > On Friday 16 December 2011 07:13:47 Anatolij Gustschin wrote:
> > > On Fri, 16 Dec 2011 00:32:15 +0100 Luka Perkov wrote:
> > > > Cosmetic patch for first U-Boot line that gets printed.
> > > > 
> > > > --- a/include/version.h
> > > > +++ b/include/version.h
> > > > 
> > > >  #define U_BOOT_VERSION_STRING U_BOOT_VERSION " (" U_BOOT_DATE " - "
> > > >  \
> > > > 
> > > > -   U_BOOT_TIME ")" CONFIG_IDENT_STRING
> > > > +   U_BOOT_TIME ") " CONFIG_IDENT_STRING
> > > 
> > > This change is not needed I think. Most boards defining
> > > CONFIG_IDENT_STRING use either a string starting with new line or
> > > strings like " something". So this patch will deface version string.
> > > Your CONFIG_IDENT_STRING should be fixed instead.
> > 
> > +1
> > -mike
> 
> Ok, thanks for pointing this out. I guess that something like patch
> bellow is not acceptable?

no, because you're adding a useless space for everyone who doesn't define 
CONFIG_IDENT_STRING :)
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] ARMV7: Add support For Logic OMAP35x/DM37x modules

2011-12-16 Thread Tom Rini
On Fri, Dec 16, 2011 at 1:31 PM, Peter Barada  wrote:
> This patch adds basic support for OMAP35x/DM37x SOM LV/Torpedo
> reference boards. It assumes U-boot is loaded to SDRAM with the
> help of another small bootloader (x-load) running from SRAM.
>
> Signed-off-by: Peter Barada 
> Cc: Tom Rini 
> Cc: Igor Grinberg 
[snip]
> +#ifdef CONFIG_SMC911X
> +/* GPMC CS1 settings for Logic SOM LV/Torpedo LAN92xx Ethernet chip */
> +static const u32 gpmc_lan92xx_config[] = {
> +       0x1000,
> +       0x00080801,
> +       0x,
> +       0x08010801,
> +       0x00080a0a,
> +       0x03000280,
> +};

The correct form here is #define NET_LAN92XX_GPMC_CONFIGn 0x... in
board.h and then ref them here.

And feel free to wait a little before spinning v4 incase others have
comments.  Assuming it's just this (or some other trivial comments)
that change in v4 I'll put that v4 into u-boot-ti/next early next
week.  Thanks for turning around on the feedback quickly!

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


[U-Boot] [PATCH] MPC85xxCDS: Fix missing LCRR_DBYP bits for 66-133MHz LBC

2011-12-16 Thread Paul Gortmaker
These boards were meaning to deploy this value:

  #define LCRR_DBYP0x8000

but were missing a zero, and hence toggling a bit that
lands in an area marked as reserved in the 8548 reference
manual.

According to the documentation, LCRR_DBYP should be used as:

   PLL bypass. This bit should be set when using low bus
   clock frequencies if the PLL is unable to lock.  When in
   PLL bypass mode, incoming data is captured in the middle
   of the bus clock cycle.  It is recommended that PLL bypass
   mode be used at frequencies of 83 MHz or less.

So the impact would most likely be undefined behaviour for
LBC peripherals on boards that were running below 83MHz LBC.
Looking at the actual u-boot code, the missing DBYP bit was
meant to be deployed as follows:

  Between 66 and 133, the DLL is enabled with an
  override workaround.

In the future, we'll convert all boards to use the symbolic
DBYP constant to avoid these "count the zeros" problems, but
for now, just fix the impacted boards.

Signed-off-by: Paul Gortmaker 

diff --git a/board/freescale/mpc8541cds/mpc8541cds.c 
b/board/freescale/mpc8541cds/mpc8541cds.c
index d127137..532d32a 100644
--- a/board/freescale/mpc8541cds/mpc8541cds.c
+++ b/board/freescale/mpc8541cds/mpc8541cds.c
@@ -275,7 +275,7 @@ local_bus_init(void)
lbc->lcrr &= (~0x8000); /* DLL Enabled */
 
} else {
-   lbc->lcrr &= (~0x800);  /* DLL Enabled */
+   lbc->lcrr &= (~0x8000); /* DLL Enabled */
udelay(200);
 
/*
diff --git a/board/freescale/mpc8555cds/mpc8555cds.c 
b/board/freescale/mpc8555cds/mpc8555cds.c
index 48ede98..3361614 100644
--- a/board/freescale/mpc8555cds/mpc8555cds.c
+++ b/board/freescale/mpc8555cds/mpc8555cds.c
@@ -273,7 +273,7 @@ local_bus_init(void)
lbc->lcrr &= (~0x8000); /* DLL Enabled */
 
} else {
-   lbc->lcrr &= (~0x800);  /* DLL Enabled */
+   lbc->lcrr &= (~0x8000); /* DLL Enabled */
udelay(200);
 
/*
-- 
1.7.4.4

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


Re: [U-Boot] Please pull u-boot-ti/master (updated!)

2011-12-16 Thread Tom Rini
On Wed, Dec 14, 2011 at 9:06 AM, Tom Rini  wrote:
> On Tue, Dec 13, 2011 at 11:58 AM, Tom Rini  wrote:
>> The following changes since commit
>> 953209bf5ef0889a1baa02aa0ed5324f53ff8fda:  Wolfgang Grandegger (1):
>>     arm: add __aeabi_unwind_cpp_pr1() function to avoid linker
>> complaints
>> are available in the git repository at:
>>   git://git.denx.de/u-boot-ti.git master
>> Ilya Yanok (1):      arm926ejs: remove noop flush_dcache_all function
>>  arch/arm/cpu/arm926ejs/cache.c |    5 - 1 files changed, 0
>> insertions(+), 5 deletions(-)
>> This is a bugfix to the cache changes that were pushed before and
>> without them some boards get stuck in an infinite loop.
>
> This is now:
>
> The following changes since commit 953209bf5ef0889a1baa02aa0ed5324f53ff8fda:
>  Wolfgang Grandegger (1):
>        arm: add __aeabi_unwind_cpp_pr1() function to avoid linker complaints
>
> are available in the git repository at:
>
>  git://git.denx.de/u-boot-ti.git master
>
> Ilya Yanok (1):
>      arm926ejs: remove noop flush_dcache_all function
>
> Manfred Rudigier (1):
>      davinci: Fixed wrong timebase clock frequency.
>
>  arch/arm/cpu/arm926ejs/cache.c         |    5 -
>  arch/arm/cpu/arm926ejs/davinci/timer.c |    2 +-
>  2 files changed, 1 insertions(+), 6 deletions(-)
>
> The change from Manfred corrects get_tbclk() to return the right value
> (CONFIG_SYS_HZ_TIMER, basically) rather than CONFIG_SYS_HZ which is
> not at all the same.

And now:
The following changes since commit 953209bf5ef0889a1baa02aa0ed5324f53ff8fda:
  Wolfgang Grandegger (1):
arm: add __aeabi_unwind_cpp_pr1() function to avoid linker complaints

are available in the git repository at:

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

Chris Lalancette (1):
  omap4_panda: Initialize the USB phy

Ilya Yanok (1):
  arm926ejs: remove noop flush_dcache_all function

Manfred Rudigier (1):
  davinci: Fixed wrong timebase clock frequency.

 arch/arm/cpu/arm926ejs/cache.c   |5 --
 arch/arm/cpu/arm926ejs/davinci/timer.c   |2 +-
 arch/arm/include/asm/arch-omap4/clocks.h |   63 ++
 board/ti/panda/panda.c   |   59 
 4 files changed, 123 insertions(+), 6 deletions(-)

This adds Chris' patch for the USB clocks on Pandaboard.  While USB
continues to not be supported in U-Boot, without this patch we have a
regression in Linux wherein USB stops working.

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


Re: [U-Boot] [PATCH] Allow the "reset" command to be omitted with CONFIG_CMD_RESET

2011-12-16 Thread Mike Frysinger
On Friday 16 December 2011 15:42:26 Moffett, Kyle D wrote:
> On Dec 16, 2011, at 14:30, Mike Frysinger wrote:
> > On Friday 16 December 2011 13:49:15 Moffett, Kyle D wrote:
> >> On Dec 16, 2011, at 00:05, Mike Frysinger wrote:
> >>> On Thursday 15 December 2011 22:32:41 Kyle Moffett wrote:
>  This new #define is set in config_cmd_defaults.h (which is
>  automatically included on every board by "mkconfig"), but this allows
>  boards to elect to omit the "reset" command if necessary with "#undef
>  CONFIG_CMD_RESET".
> >>> 
> >>> would be a good time to split this into a dedicated common/cmd_reset.c,
> >>> we can also then fix cmd_boot.c to only build when CONFIG_CMD_GO is
> >>> enabled
> >> 
> >> The only references to CONFIG_CMD_GO are in config_cmd_defaults.h,
> >> README, and common/cmd_boot.c, there is nothing that ever turns it off,
> >> so perhaps the config symbol should just be removed?
> > 
> > i have some boards that turn it off
> 
> Ok,
> 
> I really don't see the point in moving these 5 lines to their own file,
> especially since they are in is already just 78 lines long:
>   U_BOOT_CMD(
>   reset, 1, 0,do_reset,
>   "Perform RESET of the CPU",
>   ""
>   );
> 
> If you really think that's what I should do, though, I'll go ahead and
> make that change.

i think so, that way we can change cmd_boot.o in the Makefile to depend on 
CONFIG_CMD_GO and drop the ifdef logic from cmd_boot.c
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v3] tools/setlocalversion: Update from the Linux Kernel

2011-12-16 Thread Mike Frysinger
Acked-by: Mike Frysinger 
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] Some thoughts on SPL

2011-12-16 Thread Scott Wood
On 12/16/2011 11:20 AM, jonsm...@gmail.com wrote:
> The CPU I'm working with, the LPC3130, is kind of an in-between CPU
> for SPL. Instead of a tightly constrained RAM of 16KB or so I have

16K?  Luxury! :-)

Many boards have only 4K, and IIRC some have only 2K.

> 96KB to work with.  96KB is enough room to support all of the various
> boot modes (uart, nand, spi, USB, etc) but not enough room for the
> full uboot command set. So I'm still stuck with the SPL model, but my
> constraints are much less.

All the SPL model is really supposed to be is makefile infrastructure
for building the two stages.  What code you pull in is configurable.

> One example of a conflict with SPL is NAND support. With SPL you hard
> code in the NAND type.

This is only required with nand_spl_simple.c.

You could provide an alternate SPL driver, or even pull in the standard
SPL stack if you want.  No need to hack up nand_spl_simple.c.

> I'm wondering if SPL could be designed in a more generic manner.
> Another model would be to use SPL as the base layer for all u-boot
> builds. You would then start turning on features until full uboot
> capability was reached.

A while back I suggested tracking a fully separate config for SPL, but
Wolfgang didn't like it.  Maybe a larger set of concrete use cases (and
what it looks like to deal with each one manually as would currently be
needed) would be convincing -- at the time it was just about having a
separate CONFIG_SYS_TEXT_BASE_SPL.

-Scott

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


[U-Boot] [PATCH] USB: move keyboard polling from EHCI driver into kbd driver

2011-12-16 Thread Allen Martin
This removes dependency on global variable "new" from EHCI driver with
CONFIG_SYS_USB_EVENT_POLL turned on and gets USB keyboard working with
EHCI driver again.

Signed-off-by: Allen Martin 
---
 common/usb_kbd.c|   18 +-
 drivers/usb/host/ehci-hcd.c |   30 --
 2 files changed, 17 insertions(+), 31 deletions(-)

diff --git a/common/usb_kbd.c b/common/usb_kbd.c
index 75107c9..e94bb7e 100644
--- a/common/usb_kbd.c
+++ b/common/usb_kbd.c
@@ -313,7 +313,23 @@ static int usb_kbd_irq(struct usb_device *dev)
 static inline void usb_kbd_poll_for_event(struct usb_device *dev)
 {
 #ifdefined(CONFIG_SYS_USB_EVENT_POLL)
-   usb_event_poll();
+   struct usb_interface *iface;
+   struct usb_endpoint_descriptor *ep;
+   struct usb_kbd_pdata *data;
+   int pipe;
+   int maxp;
+
+   /* Get the pointer to USB Keyboard device pointer */
+   data = dev->privptr;
+   iface = &dev->config.if_desc[0];
+   ep = &iface->ep_desc[0];
+   pipe = usb_rcvintpipe(dev, ep->bEndpointAddress);
+
+   /* Submit a interrupt transfer request */
+   maxp = usb_maxpacket(dev, pipe);
+   usb_submit_int_msg(dev, pipe, &data->new[0],
+   maxp > 8 ? 8 : maxp, ep->bInterval);
+
usb_kbd_irq_worker(dev);
 #elif  defined(CONFIG_SYS_USB_EVENT_POLL_VIA_CONTROL_EP)
struct usb_interface *iface;
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index db10316..94a5eed 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -26,10 +26,6 @@
 #include 
 #include 
 #include 
-#ifdef CONFIG_USB_KEYBOARD
-#include 
-extern unsigned char new[];
-#endif
 
 #include "ehci.h"
 
@@ -946,29 +942,3 @@ submit_int_msg(struct usb_device *dev, unsigned long pipe, 
void *buffer,
return ehci_submit_async(dev, pipe, buffer, length, NULL);
 }
 
-#ifdef CONFIG_SYS_USB_EVENT_POLL
-/*
- * This function polls for USB keyboard data.
- */
-void usb_event_poll()
-{
-   struct stdio_dev *dev;
-   struct usb_device *usb_kbd_dev;
-   struct usb_interface *iface;
-   struct usb_endpoint_descriptor *ep;
-   int pipe;
-   int maxp;
-
-   /* Get the pointer to USB Keyboard device pointer */
-   dev = stdio_get_by_name("usbkbd");
-   usb_kbd_dev = (struct usb_device *)dev->priv;
-   iface = &usb_kbd_dev->config.if_desc[0];
-   ep = &iface->ep_desc[0];
-   pipe = usb_rcvintpipe(usb_kbd_dev, ep->bEndpointAddress);
-
-   /* Submit a interrupt transfer request */
-   maxp = usb_maxpacket(usb_kbd_dev, pipe);
-   usb_submit_int_msg(usb_kbd_dev, pipe, &new[0],
-   maxp > 8 ? 8 : maxp, ep->bInterval);
-}
-#endif /* CONFIG_SYS_USB_EVENT_POLL */
-- 
1.7.5.4

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


[U-Boot] [PATCH v3] tools/setlocalversion: Update from the Linux Kernel

2011-12-16 Thread Kyle Moffett
Several bugfixes have occurred upstream since this script was imported
into U-Boot.  In particular, the script currently in U-Boot does not
describe commit f8bbb4dad0e9d91b7a51d6cc54dcf66d142f50fe correctly,
resulting in a version of "2011.09" instead of "2011.09-01460-gf8bbb4d".

With that commit checked out, the command "git name-rev --tags HEAD"
gives this result:
  HEAD tags/v2011.12-rc1~30^2

Then the "changes" regex does not match because of the trailing '^2':
  grep -E '^HEAD[[:space:]]+(.*~[0-9]*|undefined)$'

The new version of tools/setlocalversion in the kernel correctly handles
those situations by using different plumbing commands.

The version from the kernel is not directly usable as it does not append
the full GIT version that U-Boot expects unless the right config options
are set (CONFIG_LOCALVERSION_AUTO=y).  Other than a few minor changes
for Kconfig, the imported version is very similar to Linux v3.2-rc4.

Signed-off-by: Kyle Moffett 
Cc: Wolfgang Denk 
Cc: Mike Frysinger 

--
Changelog:
  v3:  Fix "localversion-*" file support and minimize kernel delta.
---
 tools/setlocalversion |  185 ++---
 1 files changed, 161 insertions(+), 24 deletions(-)

diff --git a/tools/setlocalversion b/tools/setlocalversion
index e11f54f..f551b4c 100755
--- a/tools/setlocalversion
+++ b/tools/setlocalversion
@@ -1,40 +1,177 @@
 #!/bin/sh
-# Print additional version information for non-release trees.
+#
+# This scripts adds local version information from the version
+# control systems git, mercurial (hg) and subversion (svn).
+#
+# It was originally copied from the Linux kernel v3.2.0-rc4 and modified
+# to support the U-Boot build-system.
+#
 
 usage() {
-   echo "Usage: $0 [srctree]" >&2
+   echo "Usage: $0 [--save-scmversion] [srctree]" >&2
exit 1
 }
 
-cd "${1:-.}" || usage
+scm_only=false
+srctree=.
+if test "$1" = "--save-scmversion"; then
+   scm_only=true
+   shift
+fi
+if test $# -gt 0; then
+   srctree=$1
+   shift
+fi
+if test $# -gt 0 -o ! -d "$srctree"; then
+   usage
+fi
+
+scm_version()
+{
+   local short
+   short=false
+
+   cd "$srctree"
+   if test -e .scmversion; then
+   cat .scmversion
+   return
+   fi
+   if test "$1" = "--short"; then
+   short=true
+   fi
+
+   # Check for git and a git repo.
+   if test -e .git && head=`git rev-parse --verify --short HEAD 
2>/dev/null`; then
+
+   # If we are at a tagged commit (like "v2.6.30-rc6"), we ignore
+   # it, because this version is defined in the top level Makefile.
+   if [ -z "`git describe --exact-match 2>/dev/null`" ]; then
+
+   # If only the short version is requested, don't bother
+   # running further git commands
+   if $short; then
+   echo "+"
+   return
+   fi
+   # If we are past a tagged commit (like
+   # "v2.6.30-rc5-302-g72357d5"), we pretty print it.
+   if atag="`git describe 2>/dev/null`"; then
+   echo "$atag" | awk -F- '{printf("-%05d-%s", 
$(NF-1),$(NF))}'
+
+   # If we don't have a tag at all we print -g{commitish}.
+   else
+   printf '%s%s' -g $head
+   fi
+   fi
+
+   # Is this git on svn?
+   if git config --get svn-remote.svn.url >/dev/null; then
+   printf -- '-svn%s' "`git svn find-rev $head`"
+   fi
+
+   # Update index only on r/w media
+   [ -w . ] && git update-index --refresh --unmerged > /dev/null
+
+   # Check for uncommitted changes
+   if git diff-index --name-only HEAD | grep -v "^scripts/package" 
\
+   | read dummy; then
+   printf '%s' -dirty
+   fi
 
-# Check for git and a git repo.
-if head=`git rev-parse --verify HEAD 2>/dev/null`; then
-   # Do we have an untagged version?
-   if git name-rev --tags HEAD | \
-  grep -E '^HEAD[[:space:]]+(.*~[0-9]*|undefined)$' > /dev/null; then
-   (git describe || git describe --tags || git describe --all 
--long) \
-   2>/dev/null | awk -F- '{printf("-%05d-%s", 
$(NF-1),$(NF))}'
+   # All done with git
+   return
fi
 
-   # Are there uncommitted changes?
-   git update-index --refresh --unmerged > /dev/null
-   if git diff-index --name-only HEAD | grep -v "^scripts/package" \
-   | read dummy; then
-   printf '%s' -dirty
+   # Check for mercurial and a mercurial repo.
+   if test -d .hg && hgid=`hg id 2>/dev/null`; then
+   # Do we have an tagged version?  If so, lat

[U-Boot] Pull request: u-boot-usb

2011-12-16 Thread Remy Bohmer
The following changes since commit 06e42c6e2ce269667daecd6229d0b7c813838203:

  Merge branch 'ag...@denx.de' of git://git.denx.de/u-boot-staging
(2011-12-12 14:51:16 +0100)

are available in the git repository at:

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

Igor Grinberg (4):
  USB: ULPI: switch argument type from u8 to unsigned
  USB: ULPI: clean a mixup of return types
  USB: ULPI: increase error case verbosity
  README: add documentation for CONFIG_USB_ULPI*

Lukasz Majewski (1):
  usb:gadget:s5p Enable the USB Gadget framework at Exynos4210
(C210 Universal)

Tom Rini (1):
  USB: Use (get|put)_unaligned for accessing wMaxPacketSize

 README   |8 +
 arch/arm/include/asm/arch-exynos/cpu.h   |1 +
 board/samsung/universal_c210/universal.c |   48 ++
 common/cmd_usb.c |3 +-
 common/usb.c |   27 -
 drivers/serial/usbtty.c  |   10 --
 drivers/usb/gadget/epautoconf.c  |8 +++--
 drivers/usb/gadget/s3c_udc_otg.c |   10 --
 drivers/usb/ulpi/ulpi-viewport.c |4 +-
 drivers/usb/ulpi/ulpi.c  |   30 +-
 include/configs/s5pc210_universal.h  |4 ++
 include/max8998_pmic.h   |1 +
 include/usb/ulpi.h   |8 ++--
 include/usbdescriptors.h |2 +-
 14 files changed, 122 insertions(+), 42 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] Allow the "reset" command to be omitted with CONFIG_CMD_RESET

2011-12-16 Thread Moffett, Kyle D
On Dec 16, 2011, at 14:30, Mike Frysinger wrote:
> On Friday 16 December 2011 13:49:15 Moffett, Kyle D wrote:
>> On Dec 16, 2011, at 00:05, Mike Frysinger wrote:
>>> On Thursday 15 December 2011 22:32:41 Kyle Moffett wrote:
 This new #define is set in config_cmd_defaults.h (which is automatically
 included on every board by "mkconfig"), but this allows boards to elect
 to omit the "reset" command if necessary with "#undef CONFIG_CMD_RESET".
>>> 
>>> would be a good time to split this into a dedicated common/cmd_reset.c,
>>> we can also then fix cmd_boot.c to only build when CONFIG_CMD_GO is
>>> enabled
>> 
>> The only references to CONFIG_CMD_GO are in config_cmd_defaults.h, README,
>> and common/cmd_boot.c, there is nothing that ever turns it off, so perhaps
>> the config symbol should just be removed?
> 
> i have some boards that turn it off

Ok,

I really don't see the point in moving these 5 lines to their own file,
especially since they are in is already just 78 lines long:
  U_BOOT_CMD(
  reset, 1, 0,do_reset,
  "Perform RESET of the CPU",
  ""
  );

If you really think that's what I should do, though, I'll go ahead and
make that change.

Cheers,
Kyle Moffett

--
Curious about my work on the Debian powerpcspe port?
I'm keeping a blog here: http://pureperl.blogspot.com/

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


Re: [U-Boot] [PATCH 1/2] NET: NE2000: Cleanup IO accessors

2011-12-16 Thread Marek Vasut
> On Friday 16 December 2011 13:13:33 Marek Vasut wrote:
> > On Friday 16 December 2011 12:33:53 Mike Frysinger wrote:
> > > rename ISA_OFFSET to CONFIG_NE2000_IO_OFFSET, then move the "2" to
> > > CONFIG_NE2000_IO_STRIDE, and move them both to the board config header.
> > > then you get one unified set:
> > > 
> > > #define DP_IN(_b_, _o_, _d_) \
> > > 
> > >   (_d_) = readw((void *)((_b_) + ((_o_) * CONFIG_NE2000_IO_STRIDE) + \
> > >   
> > >   CONFIG_NE2000_IO_OFFSET));
> > > 
> > > etc...
> > > 
> > > if you really wanted to clean up the driver, the DP_XXX funcs would get
> > > turned into C code as static inline helpers, and the base + register
> > > offset would get turned into a C struct.
> > 
> > Ok, so if you had two different piece of hardware that had different
> > NE2000_IO_OFFSET and STRIDE, running the same u-boot, how'd you handle it
> > ?
> 
> do you actually have this issue ?  there are plenty of theoretical
> situations like this which would break a significant number (majority?) of
> drivers in the tree.  so unless this is a real case, i'd ignore it for now
> and stick with what optimizes away to no overhead.

Sadly, I almost do. Not now of course, but eventually, I'll be there :-(

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


Re: [U-Boot] [PATCH 4/4] README: add documentation for CONFIG_USB_ULPI*

2011-12-16 Thread Remy Bohmer
Hi,

2011/12/16 Simon Glass :
> Hi Remy,
>
> On Fri, Dec 16, 2011 at 12:10 PM, Remy Bohmer  wrote:
>> Hi Igor,
>>
>>> Here the configs are documented.
>>> I admit, it is not that brilliant documentation...
>>
>> Are you planning to post an update of this patch? The rest of the
>> series I already pulled into the USB tree.
>
> From my point of view it is fine as is.

In that case i will pull it in. Thanks.

Kind regards,

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


Re: [U-Boot] [PATCH] ARMV7: Add support For Logic OMAP35x/DM37x modules

2011-12-16 Thread Peter Barada
On 12/16/2011 03:31 PM, Peter Barada wrote:
> This patch adds basic support for OMAP35x/DM37x SOM LV/Torpedo
> reference boards. It assumes U-boot is loaded to SDRAM with the
> help of another small bootloader (x-load) running from SRAM.
[snip]

My apologies, I forgot to change the subject to [PATCH V3], but as the
commentary indicates, it is V3.  I'm still getting used to git send-email...

-- 
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 v2 1/1] USB: Use (get|put)_unaligned for accessing wMaxPacketSize

2011-12-16 Thread Remy Bohmer
Hi All,

2011/12/15 Tom Rini :
> In 9792987721c7980453fe6447c3fa6593b44f8458 Stefan describes a usecase
> where the previous behavior of leaving wMaxPacketSize be unaligned
> caused fatal problems.  The initial fix for this problem was incomplete
> however as it showed another cases of non-aligned access that previously
> worked implicitly.  This switches to making sure that all access of
> wMaxPacketSize are done via (get|put)_unaligned.
>
> In order to maintain a level of readability to the code in some cases
> we now use a variable for the value of wMaxPacketSize and in others, a
> macro.
>
> Cc: Minkyu Kang 
> Cc: Remy Bohmer 
>
> OpenRISC:
> Tested-by: Stefan Kristiansson 
>
> Beagleboard xM, Pandaboard run-tested, s5p_goni build-tested.
> Signed-off-by: Tom Rini 
> ---
>  common/cmd_usb.c                 |    3 ++-
>  common/usb.c                     |   27 +++
>  drivers/serial/usbtty.c          |   10 ++
>  drivers/usb/gadget/epautoconf.c  |    8 +---
>  drivers/usb/gadget/s3c_udc_otg.c |   10 ++
>  include/usbdescriptors.h         |    2 +-
>  6 files changed, 39 insertions(+), 21 deletions(-)

This patch looks good to me, so I applied it to u-boot-usb.
Since it seems to fix a pending regression, I will push out a pull
request to Wolfgang quickly.

Thanks.

Kind regards,

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


[U-Boot] [PATCH] ARMV7: Add support For Logic OMAP35x/DM37x modules

2011-12-16 Thread Peter Barada
This patch adds basic support for OMAP35x/DM37x SOM LV/Torpedo
reference boards. It assumes U-boot is loaded to SDRAM with the
help of another small bootloader (x-load) running from SRAM.

Signed-off-by: Peter Barada 
Cc: Tom Rini 
Cc: Igor Grinberg 
---

Changes for V3:
Inline identify_board() into board_init()
Remove triple empty lines
Use sdelay() instead of naked delay loop
Use enable_gpmc_cs_config() to setup GPMC CS1 access to LAN92xx
Remove CONFIG_L2_OFF - holdover from previous work in u-boot-2011.06
where adding 270p 32bpp frambuffer support cause failure while
booting linux kernel.  Will address when I add video support
Reduce CONFIG_SYS_MAXARGS to 16

Changes for V2:
Rework logic_identify() into identify_board() - can't use checkboard()
   since its enabled by CONFIG_DISPLAY_BOARDINFO
Properly indent comments in set_muxconf_regs()
Move setup_net_chip() call from misc_init_r to board_eth_init()
Remove triple empty line spacing
Pass gpio_request(189) non-empty description
Remove board/logicpd/omap3som/config.mk
Remove clean/distclean from board/logicpd/omap3som/Makefile
Modify board_mmc_init() to be one line function
Modify include/configs/omap3_logic.h to use on/off #defines

 board/logicpd/omap3som/Makefile |   42 +++
 board/logicpd/omap3som/omap3logic.c |  523 +++
 board/logicpd/omap3som/omap3logic.h |   35 +++
 boards.cfg  |1 +
 include/configs/omap3_logic.h   |  351 +++
 5 files changed, 952 insertions(+), 0 deletions(-)
 create mode 100644 board/logicpd/omap3som/Makefile
 create mode 100644 board/logicpd/omap3som/omap3logic.c
 create mode 100644 board/logicpd/omap3som/omap3logic.h
 create mode 100644 include/configs/omap3_logic.h

diff --git a/board/logicpd/omap3som/Makefile b/board/logicpd/omap3som/Makefile
new file mode 100644
index 000..75e237b
--- /dev/null
+++ b/board/logicpd/omap3som/Makefile
@@ -0,0 +1,42 @@
+#
+# (C) Copyright 2000, 2001, 2002
+# 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
+
+LIB= $(obj)lib$(BOARD).o
+
+COBJS-y:= omap3logic.o
+
+COBJS  := $(sort $(COBJS-y))
+SRCS   := $(COBJS:.o=.c)
+OBJS   := $(addprefix $(obj),$(COBJS))
+
+$(LIB):$(obj).depend $(OBJS)
+   $(call cmd_link_o_target, $(OBJS))
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
diff --git a/board/logicpd/omap3som/omap3logic.c 
b/board/logicpd/omap3som/omap3logic.c
new file mode 100644
index 000..eb051db
--- /dev/null
+++ b/board/logicpd/omap3som/omap3logic.c
@@ -0,0 +1,523 @@
+/*
+ * (C) Copyright 2011
+ * Logic Product Development 
+ *
+ * Author :
+ * Peter Barada 
+ *
+ * Derived from Beagle Board and 3430 SDP code by
+ * Richard Woodruff 
+ * Syed Mohammed Khasim 
+ *
+ * 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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "omap3logic.h"
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/* two dimensional array of strucures containining board name and Linux
+ * machine IDs; row it selected based on CPU column is slected based
+ * on hsusb0_data5 pin having a pulldown resistor

Re: [U-Boot] [PATCH 4/4] README: add documentation for CONFIG_USB_ULPI*

2011-12-16 Thread Simon Glass
Hi Remy,

On Fri, Dec 16, 2011 at 12:10 PM, Remy Bohmer  wrote:
> Hi Igor,
>
> 2011/12/15 Igor Grinberg :
> Where does it say that only this one is supported in the code?

 You mean comments or the code?
>>>
>>> Well the filename seems generic and not specific to that chip. Are
>>> viewports something that other chips can support?
>>
>> Let me clarify:
>> 1) It is not the chip it is the controller (IP block) inside the SoC.
>> 2) viewport is just the register name inside the SoC that provides
>>   and interface of the controller to access the ULPI PHY.
>>
>> I think every SoC that uses that controller has the viewport setup
>> this way, but I might be wrong (and that's why the viewport is
>> separated from the generic ULPI spec implementation).
>>
>> Regarding the name... yeah it could be renamed, but it follows Linux
>> naming currently and it is the first one submitted,
>> so IMO it can be named that generically.
>>
>>>
>>> COBJS-$(CONFIG_USB_ULPI)              += ulpi.o
>>> COBJS-$(CONFIG_USB_ULPI_VIEWPORT)     += ulpi-viewport.o
>>>
>>> It would be good if you could mention the two new CONFIG options in the 
>>> README.
>>
>> I did, see below...
>>
>>>

> What is specific to that device?

 The viewport bits? It is not a part of the ULPI spec.
 Other vendors do not have to comply with those.
 For example PXA310 has those bits placed and named in some other way...
>>>
>>> OK I didn't realise that.
>>
>> I think same stand for OMAP, but I'm not sure.
>> OMAP still does arbitrary register writes for accessing ULPI.
>>
>>>
>> +               To enable the ULPI layer support, define CONFIG_USB_ULPI 
>> and
>> +               CONFIG_USB_ULPI_VIEWPORT in your board configuration 
>> file.
>>
>> Here the configs are documented.
>> I admit, it is not that brilliant documentation...
>
> Are you planning to post an update of this patch? The rest of the
> series I already pulled into the USB tree.

>From my point of view it is fine as is.

Regards,
Simon

>
> Kind regards,
>
> Remy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v3 3/3] usb:gadget:s5p Enable the USB Gadget framework at Exynos4210 (C210 Universal)

2011-12-16 Thread Remy Bohmer
Hi,

2011/12/15 Lukasz Majewski :
> This commit enables support for USB Gadgets on the Exynos4210 (C210 Universal)
> reference target.
>
> Signed-off-by: Lukasz Majewski 
> Signed-off-by: Kyungmin Park 
> Cc: Minkyu Kang 
> CC: Remy Bohmer 
> ---
> Changes for v2:
>        - Rename the S5PC210_Universal to Exynos4210
> Changes for v3:
>        - status check removed
>        - SAFEOUT1 LDO enabled for USB operation
>        - Reorder of USB LDOs

Applied to u-boot-usb. Thanks.

Kind regards,

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


Re: [U-Boot] [PATCH 4/4] README: add documentation for CONFIG_USB_ULPI*

2011-12-16 Thread Remy Bohmer
Hi Igor,

2011/12/15 Igor Grinberg :
 Where does it say that only this one is supported in the code?
>>>
>>> You mean comments or the code?
>>
>> Well the filename seems generic and not specific to that chip. Are
>> viewports something that other chips can support?
>
> Let me clarify:
> 1) It is not the chip it is the controller (IP block) inside the SoC.
> 2) viewport is just the register name inside the SoC that provides
>   and interface of the controller to access the ULPI PHY.
>
> I think every SoC that uses that controller has the viewport setup
> this way, but I might be wrong (and that's why the viewport is
> separated from the generic ULPI spec implementation).
>
> Regarding the name... yeah it could be renamed, but it follows Linux
> naming currently and it is the first one submitted,
> so IMO it can be named that generically.
>
>>
>> COBJS-$(CONFIG_USB_ULPI)              += ulpi.o
>> COBJS-$(CONFIG_USB_ULPI_VIEWPORT)     += ulpi-viewport.o
>>
>> It would be good if you could mention the two new CONFIG options in the 
>> README.
>
> I did, see below...
>
>>
>>>
 What is specific to that device?
>>>
>>> The viewport bits? It is not a part of the ULPI spec.
>>> Other vendors do not have to comply with those.
>>> For example PXA310 has those bits placed and named in some other way...
>>
>> OK I didn't realise that.
>
> I think same stand for OMAP, but I'm not sure.
> OMAP still does arbitrary register writes for accessing ULPI.
>
>>
> +               To enable the ULPI layer support, define CONFIG_USB_ULPI 
> and
> +               CONFIG_USB_ULPI_VIEWPORT in your board configuration file.
>
> Here the configs are documented.
> I admit, it is not that brilliant documentation...

Are you planning to post an update of this patch? The rest of the
series I already pulled into the USB tree.

Kind regards,

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


Re: [U-Boot] [PATCH 3/4] USB: ULPI: increase error case verbosity

2011-12-16 Thread Remy Bohmer
Hi,

2011/12/12 Igor Grinberg :
> Add the argument value to the error message.
>
> Signed-off-by: Igor Grinberg 
> ---
>  drivers/usb/ulpi/ulpi.c |   12 ++--
>  1 files changed, 6 insertions(+), 6 deletions(-)

Applied to -u-boot-usb. Thanks.

Kind regards,

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


Re: [U-Boot] [PATCH] FAT: fix complie error when enabling FAT write

2011-12-16 Thread Wolfgang Denk
Dear Donggeun Kim,

In message <1323851092-821-1-git-send-email-dg77@samsung.com> you wrote:
> By removing variable of 'part_size' in fs/fat.c,
> compile error occurs when enabling FAT write feature.
> The variable should be declared only when CONFIG_FAT_WRITE is defined.
> This patch removes compile error when FAT write is enabled and
> compile warning when FAT write is disabled.
> 
> Signed-off-by: Donggeun Kim 
> Signed-off-by: Kyungmin Park 
> ---
>  fs/fat/fat.c |7 +++
>  1 files changed, 7 insertions(+), 0 deletions(-)

Please squash this into the patch that adds the fatwrite feature.

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
Einstein argued that there must be simplified explanations of nature,
because God is not capricious or arbitrary. No  such  faith  comforts
the software engineer. - Fred Brooks, Jr.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 2/4] USB: ULPI: clean a mixup of return types

2011-12-16 Thread Remy Bohmer
Hi,

2011/12/12 Igor Grinberg :
> Clean a mixup between u32 and int as a return type
> for functions returning error values.
> Use int as it is native (and widely used) return type.
>
> Signed-off-by: Igor Grinberg 
> ---
>  drivers/usb/ulpi/ulpi-viewport.c |    4 ++--
>  drivers/usb/ulpi/ulpi.c          |    8 
>  include/usb/ulpi.h               |    2 +-
>  3 files changed, 7 insertions(+), 7 deletions(-)

Applied to u-boot-usb. Thanks.

Kind regards,

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


Re: [U-Boot] [PATCH v2 1/4] USB: ULPI: switch argument type from u8 to unsigned

2011-12-16 Thread Remy Bohmer
Hi,

2011/12/16 Simon Glass :
> On Tue, Dec 13, 2011 at 10:16 PM, Igor Grinberg  
> wrote:
>> There is no benefit in using u8, so switch to unsigned to reduce the
>> binary image size (by 20 bytes).
>>
>> Signed-off-by: Igor Grinberg 
>> Acked-by: Simon Glass 
>
> Looks good thanks
>
>> ---
>> v2:     no functional changes - fix typos in the commit message
>>        and add Simon's ack.
>>
>>  drivers/usb/ulpi/ulpi.c |   10 +-
>>  include/usb/ulpi.h      |    6 +++---
>>  2 files changed, 8 insertions(+), 8 deletions(-)

Applied to u-boot-usb.

Thanks.

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


Re: [U-Boot] [PATCH 1/2] NET: NE2000: Cleanup IO accessors

2011-12-16 Thread Mike Frysinger
On Friday 16 December 2011 13:13:33 Marek Vasut wrote:
> On Friday 16 December 2011 12:33:53 Mike Frysinger wrote:
> > rename ISA_OFFSET to CONFIG_NE2000_IO_OFFSET, then move the "2" to
> > CONFIG_NE2000_IO_STRIDE, and move them both to the board config header.
> > then you get one unified set:
> > 
> > #define DP_IN(_b_, _o_, _d_) \
> > (_d_) = readw((void *)((_b_) + ((_o_) * CONFIG_NE2000_IO_STRIDE) + \
> > CONFIG_NE2000_IO_OFFSET));
> > etc...
> > 
> > if you really wanted to clean up the driver, the DP_XXX funcs would get
> > turned into C code as static inline helpers, and the base + register
> > offset would get turned into a C struct.
> 
> Ok, so if you had two different piece of hardware that had different
> NE2000_IO_OFFSET and STRIDE, running the same u-boot, how'd you handle it ?

do you actually have this issue ?  there are plenty of theoretical situations 
like this which would break a significant number (majority?) of drivers in the 
tree.  so unless this is a real case, i'd ignore it for now and stick with 
what optimizes away to no overhead.
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] Allow the "reset" command to be omitted with CONFIG_CMD_RESET

2011-12-16 Thread Mike Frysinger
On Friday 16 December 2011 13:49:15 Moffett, Kyle D wrote:
> On Dec 16, 2011, at 00:05, Mike Frysinger wrote:
> > On Thursday 15 December 2011 22:32:41 Kyle Moffett wrote:
> >> This new #define is set in config_cmd_defaults.h (which is automatically
> >> included on every board by "mkconfig"), but this allows boards to elect
> >> to omit the "reset" command if necessary with "#undef CONFIG_CMD_RESET".
> > 
> > NAK: doesn't seem to address the feedback i posted last time ...
> 
> Hmm, I thought I addressed these:
> >> --- a/include/config_cmd_defaults.h
> >> +++ b/include/config_cmd_defaults.h
> > 
> > updating these files is not sufficient and will break boards.  drop the
> > hunks to these files and update include/config_defaults.h instead.
> 
> The "mkconfig" program automatically includes both config_defaults.h and
> config_cmd_defaults.h, so this is sufficient to not break boards.

ah, you're right.  sorry about that.  i was thinking of "config_cmd_default.h" 
which is not the same as "config_cmd_defaults.h" ;).

> > would be a good time to split this into a dedicated common/cmd_reset.c,
> > we can also then fix cmd_boot.c to only build when CONFIG_CMD_GO is
> > enabled
> 
> The only references to CONFIG_CMD_GO are in config_cmd_defaults.h, README,
> and common/cmd_boot.c, there is nothing that ever turns it off, so perhaps
> the config symbol should just be removed?

i have some boards that turn it off
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] Allow the "reset" command to be omitted with CONFIG_CMD_RESET

2011-12-16 Thread Moffett, Kyle D
On Dec 16, 2011, at 00:05, Mike Frysinger wrote:
> On Thursday 15 December 2011 22:32:41 Kyle Moffett wrote:
>> This new #define is set in config_cmd_defaults.h (which is automatically
>> included on every board by "mkconfig"), but this allows boards to elect
>> to omit the "reset" command if necessary with "#undef CONFIG_CMD_RESET".
> 
> NAK: doesn't seem to address the feedback i posted last time ...

Hmm, I thought I addressed these:

>> --- a/include/config_cmd_defaults.h
>> +++ b/include/config_cmd_defaults.h
> 
> updating these files is not sufficient and will break boards.  drop the hunks 
> to 
> these files and update include/config_defaults.h instead.

The "mkconfig" program automatically includes both config_defaults.h and
config_cmd_defaults.h, so this is sufficient to not break boards.  This
is exactly how CONFIG_CMD_GO works.  Since it's always on, there's no need
to add it to config_cmd_all.h either (which is why I removed that hunk).

> would be a good time to split this into a dedicated common/cmd_reset.c,
> we can also then fix cmd_boot.c to only build when CONFIG_CMD_GO is enabled

The only references to CONFIG_CMD_GO are in config_cmd_defaults.h, README,
and common/cmd_boot.c, there is nothing that ever turns it off, so perhaps
the config symbol should just be removed?

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


Re: [U-Boot] [PATCH 1/2] NET: NE2000: Cleanup IO accessors

2011-12-16 Thread Marek Vasut
> On Monday 12 December 2011 05:17:49 Marek Vasut wrote:
> > > On Sunday 11 December 2011 08:42:07 Marek Vasut wrote:
> > > > > On Saturday 10 December 2011 20:09:30 Marek Vasut wrote:
> > > > > > Introduce ne2k_register_io(in, out), which allows user to supply
> > > > > > two functions. One for reading data from the card, the other for
> > > > > > writing data to the card. Then introduce drivers' private data,
> > > > > > which carry pointers to these functions and are passed throughout
> > > > > > the driver.
> > > > > 
> > > > > where are the users of this new API ?  as it stands, i just see
> > > > > bloat. every register access is now an indirect function call ?
> > > > > what's the point
> > > > 
> > > > Go to ... drivers/net/ax88796.h ... and check how it's done now. It's
> > > > just wrong. Now for .03 release I have pxa3xx support ready which
> > > > uses just this chip and adding more sh^Htuff to that fill would be
> > > > even worse bloat.
> > > 
> > > i agree, that code is terrible.  however, those code paths can be
> > > trivially merged without the proposed bloat yours brings in.
> > 
> > So what's your suggested awesome clean solution?
> 
> there's no need to get snarky

Well sometimes it's hard to digest the style of your comments ;-)
> 
> rename ISA_OFFSET to CONFIG_NE2000_IO_OFFSET, then move the "2" to
> CONFIG_NE2000_IO_STRIDE, and move them both to the board config header.
> then you get one unified set:
> 
> #define DP_IN(_b_, _o_, _d_) \
>   (_d_) = readw((void *)((_b_) + ((_o_) * CONFIG_NE2000_IO_STRIDE) + \
>   CONFIG_NE2000_IO_OFFSET));
> etc...
> 
> if you really wanted to clean up the driver, the DP_XXX funcs would get
> turned into C code as static inline helpers, and the base + register
> offset would get turned into a C struct.

Ok, so if you had two different piece of hardware that had different 
NE2000_IO_OFFSET and STRIDE, running the same u-boot, how'd you handle it ?

> 
> > > further, that code base
> > > isn't even used by the ne2000 driver.
> > 
> > What are you talking about, did you even bother to look?
> 
> might want to cut the attitude.  it's really not adding anything.

Agreed
> 
> of course i looked and i saw ne2000.h defining DP_OUT/etc...  but i missed
> the ugly ifdef logic with CONFIG_DRIVER_AX88796L in ne2000_base.c.

That needs handling in a separate patch.
> 
> > > so again, the question stands: what exactly do you need to do different
> > > ? looks to me like the DP_* macros should get punted in favor of io.h
> > > accessors, and the register offsets rewritten into C structs.
> > 
> > Sure, but not every hardware accesses the registers the same way.
> 
> which is why we have asm/io.h in the first place.
> 
> on a semi-related note, these vu_{short,char,etc...} types need to get
> culled from the code base.  they're volatile markings in disguise ...

Agreed

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


Re: [U-Boot] [PATCH v3] MIPS: fix endianess handling

2011-12-16 Thread Mike Frysinger
On Sunday 11 December 2011 11:53:11 Daniel Schwierzeck wrote:
> --- a/README
> +++ b/README
> @@ -374,6 +374,12 @@ The following options need to be configured:
>   Defines the string to utilize when trying to match PCIe device
>   tree nodes for the given platform.
> 
> +- Generic CPU options:
> + CONFIG_SYS_BIG_ENDIAN, CONFIG_SYS_LITTLE_ENDIAN
> +
> + Defines the endianess of the CPU. Implementation of those
> + values is arch specific.

might be useful to describe what these do.  something like:
Adds options to explicitly add compiler flags that select the desired 
endianness.  Otherwise, the endian will be whatever the toolchain defaults to.

> --- a/arch/mips/cpu/mips32/config.mk
> +++ b/arch/mips/cpu/mips32/config.mk
> 
> +ifdef CONFIG_SYS_LITTLE_ENDIAN
> +ENDIANNESS := -EL
> +endif
> +
> +ifdef CONFIG_SYS_BIG_ENDIAN
> +ENDIANNESS := -EB
> +endif

the GNU linker should treat -EL/-EB the same for all targets.  so we should be 
able to add to the common .mk files in the top level:
LDFLAGS-$(CONFIG_SYS_LITTLE_ENDIAN) += -EL
LDFLAGS-$(CONFIG_SYS_BIG_ENDIAN) += -EB
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] fsl_esdhc.c bug

2011-12-16 Thread Ira W. Snyder
On Fri, Dec 16, 2011 at 09:53:20AM -0500, Jim Lentz wrote:
> On 12/16/2011 09:51 AM, Fabio Estevam wrote:
> > Hi Jim,
> >
> > On Fri, Dec 16, 2011 at 11:48 AM, Jim Lentz  wrote:
> >> All,
> >>
> >> There is a bug rendering SDCard support useless on Freescale esdhc
> >> controller.
> > Which Freescale processor do you use?
> >
> > Please describe in details the problem you see, how to reproduce it,
> > the U-boot version
> > that you use, etc.
> >
> > Regards,
> >
> > Fabio Estevam
> Freescale P2020. Latest U-boot version.
> 
> Easiest way to see it is typing mmcinfo at the U-boot cli. It will hang.
> 
> By default, PIO mode is selected when CONFIG_P2020 is defined. Legacy 
> P2020 silicon revisions require PIO mode.
> 
> The esdhc_pio_read_write function has a bad reg pointer.
> 

Hi Jim,

I tested this on my P2020, and PIO mode fails as you describe. Your fix
works. I've attached a patch which is suitable for inclusion into
U-Boot. Feel free to submit your own patch to supercede this one. It is
a bug you found, you should get credit for it! :)

It looks like the patch which introduced this code (77c1458d1 "ppc/85xx:
PIO Support for FSL eSDHC Controller Driver") was carried out of tree
for a while. While it was out of tree, another commit happened
(c67bee146 "fsl_esdhc: add support for mx51 processor") which changed
how the mmc->priv variable is used.


>From 91d7e1788b639602e62249f8db53412d913f4d35 Mon Sep 17 00:00:00 2001
From: Ira W. Snyder 
Date: Fri, 16 Dec 2011 09:48:19 -0800
Subject: [PATCH] fsl_esdhc: fix PIO mode transfers

The pointer to the registers used to control the Freescale MMC
controller is not initialized correctly when using PIO mode. This is
fixed by initializing the pointer identically to all other usage in the
driver.

Examining the commit history shows that this was broken at introduction
due to a code change in upstream U-Boot to support the mx51 processor
family.

Reported-by: Jim Lentz 
Signed-off-by: Ira W. Snyder 
---

Tested on the P2020COME board with PIO explicitly enabled via:
#define CONFIG_SYS_FSL_ESDHC_USE_PIO

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

diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
index ec953f0..b56ddc65 100644
--- a/drivers/mmc/fsl_esdhc.c
+++ b/drivers/mmc/fsl_esdhc.c
@@ -113,7 +113,8 @@ uint esdhc_xfertyp(struct mmc_cmd *cmd, struct mmc_data 
*data)
 static void
 esdhc_pio_read_write(struct mmc *mmc, struct mmc_data *data)
 {
-   struct fsl_esdhc *regs = mmc->priv;
+   struct fsl_esdhc_cfg *cfg = mmc->priv;
+   struct fsl_esdhc *regs = (struct fsl_esdhc *)cfg->esdhc_base;
uint blocks;
char *buffer;
uint databuf;
-- 
1.7.3.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2] tools/setlocalversion: Update from the Linux Kernel

2011-12-16 Thread Moffett, Kyle D
On Dec 16, 2011, at 11:07, Mike Frysinger wrote:
> On Thursday 15 December 2011 21:13:55 Kyle Moffett wrote:
>> The version from the kernel is not directly usable as it has code for
>> supporting CONFIG_LOCALVERSION from Kconfig, but the version that was
>> imported is very similar to the one in Linux v3.2-rc4.
> 
> NAK: this breaks localversion-* support

Ah, I missed that somehow.  I'd read through the U-Boot version and did
not remember seeing that part so I assumed it wasn't necessary.


> ignoring that, i'm not sure you really need to delete the CONFIG_xxx 
> handling.  
> under u-boot, they'd expand to like "" which would end at the same code.  by 
> keeping as much code as possible in common, it should make future updates 
> easier.

Ok, I will respin, retest, and resubmit as you suggest.

Cheers,
Kyle Moffett

--
Curious about my work on the Debian powerpcspe port?
I'm keeping a blog here: http://pureperl.blogspot.com/

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


Re: [U-Boot] [PATCH 1/2] NET: NE2000: Cleanup IO accessors

2011-12-16 Thread Mike Frysinger
On Monday 12 December 2011 05:17:49 Marek Vasut wrote:
> > On Sunday 11 December 2011 08:42:07 Marek Vasut wrote:
> > > > On Saturday 10 December 2011 20:09:30 Marek Vasut wrote:
> > > > > Introduce ne2k_register_io(in, out), which allows user to supply
> > > > > two functions. One for reading data from the card, the other for
> > > > > writing data to the card. Then introduce drivers' private data,
> > > > > which carry pointers to these functions and are passed throughout
> > > > > the driver.
> > > > 
> > > > where are the users of this new API ?  as it stands, i just see
> > > > bloat. every register access is now an indirect function call ? 
> > > > what's the point
> > > 
> > > Go to ... drivers/net/ax88796.h ... and check how it's done now. It's
> > > just wrong. Now for .03 release I have pxa3xx support ready which uses
> > > just this chip and adding more sh^Htuff to that fill would be even
> > > worse bloat.
> > 
> > i agree, that code is terrible.  however, those code paths can be
> > trivially merged without the proposed bloat yours brings in.
> 
> So what's your suggested awesome clean solution?

there's no need to get snarky

rename ISA_OFFSET to CONFIG_NE2000_IO_OFFSET, then move the "2" to 
CONFIG_NE2000_IO_STRIDE, and move them both to the board config header.
then you get one unified set:

#define DP_IN(_b_, _o_, _d_) \
(_d_) = readw((void *)((_b_) + ((_o_) * CONFIG_NE2000_IO_STRIDE) + \
CONFIG_NE2000_IO_OFFSET));
etc...

if you really wanted to clean up the driver, the DP_XXX funcs would get turned 
into C code as static inline helpers, and the base + register offset would get 
turned into a C struct.

> > further, that code base
> > isn't even used by the ne2000 driver.
> 
> What are you talking about, did you even bother to look?

might want to cut the attitude.  it's really not adding anything.

of course i looked and i saw ne2000.h defining DP_OUT/etc...  but i missed the 
ugly ifdef logic with CONFIG_DRIVER_AX88796L in ne2000_base.c.

> > so again, the question stands: what exactly do you need to do different ?
> > looks to me like the DP_* macros should get punted in favor of io.h
> > accessors, and the register offsets rewritten into C structs.
> 
> Sure, but not every hardware accesses the registers the same way.

which is why we have asm/io.h in the first place.

on a semi-related note, these vu_{short,char,etc...} types need to get culled 
from the code base.  they're volatile markings in disguise ...
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v1 2/2] tpm: Add i2c TPM driver

2011-12-16 Thread Mike Frysinger
On Wednesday 14 December 2011 03:48:24 Che-Liang Chiou wrote:
> --- /dev/null
> +++ b/drivers/tpm/tpm.c
>
> +int tis_sendrecv(const uint8_t *sendbuf, size_t send_size, uint8_t
> *recvbuf, +   size_t *recv_len)
> +{
> + error("%s: invalid send_size %zx\n", __func__, send_size);

using __func__ with error() makes no sense as error() already includes that

> --- /dev/null
> +++ b/drivers/tpm/tpm_private.h

this should probably include linux/types.h and linux/compiler.h since it uses 
__be32 and __packed

> --- /dev/null
> +++ b/drivers/tpm/tpm_tis_i2c.c
>
> + if (burstcnt > (len-1-count))
> + burstcnt = len-1-count;

add some spaces around those "-"
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] Some thoughts on SPL

2011-12-16 Thread jonsm...@gmail.com
The CPU I'm working with, the LPC3130, is kind of an in-between CPU
for SPL. Instead of a tightly constrained RAM of 16KB or so I have
96KB to work with.  96KB is enough room to support all of the various
boot modes (uart, nand, spi, USB, etc) but not enough room for the
full uboot command set. So I'm still stuck with the SPL model, but my
constraints are much less.

One example of a conflict with SPL is NAND support. With SPL you hard
code in the NAND type. In my case I have enough room to do NAND type
detection. So this has me modifying the #ifdefs in the makefiles to
include the NAND detection code in my SPL loader.

I'm wondering if SPL could be designed in a more generic manner.
Another model would be to use SPL as the base layer for all u-boot
builds. You would then start turning on features until full uboot
capability was reached. An example of this would be NAND support, the
default would be hard coded NAND for all u-boot builds, but turning on
NAND detection would increase the size of the build and disable the
hard coded support. Another default would be SPL chaining into the
next image, turning on the u-boot UI would again make the code larger
and disable auto-chaining.

The concept is to remove SPL as a special class and turn it into the
base layer that everything builds on. Changing the model in this was
should make the config files easier to understand. Instead of having a
single file combining SPL and full u-boot you'd have two independent
ones. In my case I'd build one u-boot config that fits into 96K and
another full 250K one. Of course the two config files could each
include a common base config.

Thoughts?

-- 
Jon Smirl
jonsm...@gmail.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [STATUS] v2011.12-rc1 is out - release date Dec 23

2011-12-16 Thread Mike Frysinger
On Tuesday 13 December 2011 20:56:47 Macpaul Lin wrote:
> 2011/12/12 Wolfgang Denk
> > Hi everybody,
> > 
> > after long struggeling we finally have a -rc1.
> > 
> > Please help testing, so we can fix the remaining issues before the
> > release, which I decided to shift to December 23.
> 
> I have some patches depends on linkage.h issue.
> http://patchwork.ozlabs.org/patch/128640/
> 
> Would you please help testing on blackfin and see if there is any problem?
> 
> Testing for NDS32 architecture for 2011.12-rc1 is done.

the linkage changes were posted after the merge window, so i wasn't going to 
submit them for inclusion until the next one
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 00/18 V2] CHECKPATCH: fpgadata.c cleanup

2011-12-16 Thread Mike Frysinger
On Friday 16 December 2011 04:54:42 Marek Vasut wrote:
> The reason is to make it all checkpatch clean.

also, it's questionable whether this goal even makes sense.  but i've said 
this many times in the past, and people don't seem to care.  they've got their 
useless blinders on.
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] arm, da850: Question about gpio control

2011-12-16 Thread Gabriele Filosofi
Hi all,

In board/davinci/da8xxevm/da850.c

#ifdef CONFIG_USE_NOR
/* Set the GPIO direction as output */
clrbits_be32((u32 *)GPIO_BANK0_REG_DIR_ADDR, (0x01 << 11));

/* Set the output as low */
val = readl(GPIO_BANK0_REG_SET_ADDR);
val |= (0x01 << 11);
writel(val, GPIO_BANK0_REG_CLR_ADDR);
#endif


It works, however is it the right way to put a gpio low ?
Why do we need to read the SET register, change its content, and write the CLR 
register ?


A second question is also related to GPIO control from within board_init.
I can toggle GP2[6] high or low using the code above, but I cannot do the same 
for GP2[12]. Why ?


After having done the following, the pin 25 of J30 still remain to logic level 
1 !

int mycode(void)
{
const struct pinmux_config gpio_pins[] = {
   { pinmux(5), 8, 3 },
};

u32 val;

/* PinMux for GPIO */
if (davinci_configure_pin_mux(gpio_pins, ARRAY_SIZE(gpio_pins)) 
!= 0)
   return 1;

/* Set the GPIO direction as output */
clrbits_be32((u32 *)GPIO_BANK2_REG_DIR_ADDR, (0x01 << 12));

/* Set the output as low */
val = readl(GPIO_BANK2_REG_CLR_ADDR);
val |= (0x01 << 12);
writel(val, GPIO_BANK2_REG_CLR_ADDR);

return 0;
}

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


Re: [U-Boot] [PATCH 00/18 V2] CHECKPATCH: fpgadata.c cleanup

2011-12-16 Thread Mike Frysinger
On Friday 16 December 2011 04:54:42 Marek Vasut wrote:
> > On Thursday 15 December 2011 08:26:41 Marek Vasut wrote:
> > > First of the CHECKPATCH series of patches with per-file checkpatch
> > > fixes.
> > > 
> > > This series fixes all files fpgadata.c, which contains PPC FPGA
> > > firmwares. There are no functional changes, only CHECKPATCH fixes.
> > 
> > i don't really see any point in touching the fpgadata.c files.  they're
> > clearly generated files and not meant to be read at all let alone
> > modified after the fact ...
> > 
> > of course, i'd wonder what created these in the first place, and apply
> > any style tastes to that tool and then regenerate the result ...
> 
> Well when the person updates these, he will hit a problem and fix his tool.

no he won't.  these files get clobbered and committed, not inline merged.
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] cmd_fat: add FAT write command

2011-12-16 Thread Mike Frysinger
On Wednesday 14 December 2011 03:25:39 Donggeun Kim wrote:
> +int do_fat_fswrite(cmd_tbl_t *cmdtp, int flag, int argc, char * const

static
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH V11 11/13] TI: SPL: make SPL available for other SOCs as TI

2011-12-16 Thread Tom Rini
On Fri, Dec 16, 2011 at 9:18 AM, Stefano Babic  wrote:
> On 16/12/2011 16:59, Tom Rini wrote:
>> On Fri, Dec 16, 2011 at 8:37 AM, Stefano Babic  wrote:
>>> The SPL is developped first for TI-OMAPx. The patch
>>> move OMAP specific function into OMAP directory.
>>
>> I wonder if we should fold this into the mv'ing patch as well.
>
> I can squash the two patches, but I thought the review is easier as I
> did. The previous patch shows clearly that the patch was only moved, and
> the changes in Makefile makes possible to build the boards making the
> patch bisectable. This patch then

Yeah, I guess that works too then, nevermind.

>> [snip]
>>> diff --git a/include/spl.h b/include/spl.h
>>> +/* Boot type */
>>> +#define        MMCSD_MODE_UNDEFINED    0
>>
>> Not your bad spacing of course, but please fix.
>
> Thanks to have found, I will fix it.
>
>>
>>> +/* NAND SPL functions */
>>> +void spl_nand_load_image(void);
>>> +void spl_arch_nand_init(void);
>>> +
>>> +/* MMC SPL functions */
>>> +void spl_mmc_load_image(void);
>>
>> These should be covered by #ifdef CONFIG_SPL_(NAND||MMC)_SUPPORT
>
> Do we need in the header file for the prototypes ? We have never done,
> and it should be not necessary.

I would swear there's other examples like this (and someone brought
this to my attention when i first posted spl_board_init internally).

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


Re: [U-Boot] [PATCH 1/2] ext4fs ls load support

2011-12-16 Thread Mike Frysinger
On Thursday 15 December 2011 12:39:28 uma.shan...@samsung.com wrote:
> From: Uma Shankar 

NAK: please add some sort of description here.  you must document all the 
places you're copying code from for example, and retain all the appropriate 
copyrights.  as it stands, this patch is a mess from that perspective.

>  Makefile  |2 +-
>  common/Makefile   |1 +
>  common/cmd_ext2.c |1 +
>  common/cmd_ext4.c |  253 ++
>  fs/Makefile   |1 +
>  fs/ext2/dev.c |1 +
>  fs/ext2/ext2fs.c  |  340 +++---
>  fs/ext4/Makefile  |   51 +
>  fs/ext4/ext4_common.c |  573
> fs/ext4/ext4_common.h |   44 
>  fs/ext4/ext4fs.c  |  215 ++
>  include/ext2fs.h  |   16 +-
>  include/ext4fs.h  |  116 ++
>  include/ext_common.h  |  199 +

when moving code around, you should use the -M/-C flags so git can better 
describe what you did

> --- /dev/null
> +++ b/common/cmd_ext4.c
>
> +int do_ext4_load(cmd_tbl_t *cmdtp, int flag, int argc, char *const argv[])

static

> +{
> + char *filename = NULL;

const

> + switch (argc) {
> + case 3:
> + addr_str = getenv("loadaddr");
> + if (addr_str != NULL)
> + strict_strtoul(addr_str, 16, &addr);
> + else
> + addr = CONFIG_SYS_LOAD_ADDR;
> +
> + filename = getenv("bootfile");
> + count = 0;
> + break;
> + case 4:
> + strict_strtoul(argv[3], 16, &addr);
> + filename = getenv("bootfile");
> + count = 0;
> + break;
> + case 5:
> + strict_strtoul(argv[3], 16, &addr);
> + filename = argv[4];
> + count = 0;
> + break;
> + case 6:
> + strict_strtoul(argv[3], 16, &addr);
> + filename = argv[4];
> + strict_strtoul(argv[5], 16, &count);
> + break;
> +
> + default:
> + return cmd_usage(cmdtp);
> + }

there's duplicated code here.  simpler to write it as:
count = 0;
filename = getenv("bootfile");
addr_str = getenv("loadaddr");
switch (argc) {
case 6:
strict_strtoul(argv[5], 16, &count);
case 5:
filename = argv[4];
case 4:
addr_str = argv[3];
case 3:
break;
default:
return cmd_usage(cmdtp);
}
if (addr_str)
strict_strtoul(addr_str, 16, &addr);
else
addr = CONFIG_SYS_LOAD_ADDR;


> + (int)strict_strtoul(++ep, 16, &part);

that cast doesn't make sense

> + if (strncmp((char *)info.type, BOOT_PART_TYPE,
> + sizeof(info.type)) != 0) {

i don't see how this could possibly work.  info.type is "unsigned char", so 
casting that single byte into an address and then reading a single byte !?

> + printf("** Invalid partition type \"%.32s\""
> +" (expect \"" BOOT_PART_TYPE "\")\n", info.type);

use %s instead of embeddeding a constant string

> +int do_ext4_ls(cmd_tbl_t *cmdtp, int flag, int argc, char *const argv[])

static

> +{
> + char *filename = "/";

const

> + (int)strict_strtoul(++ep, 16, &part);

useless cast

> --- /dev/null
> +++ b/fs/ext4/Makefile
>
> +LIB  = $(obj)libext4fs.o
> +
> +AOBJS=
> +COBJS-$(CONFIG_CMD_EXT4) := ext4fs.o ext4_common.o
> +
> +SRCS := $(AOBJS:.o=.S) $(COBJS-y:.o=.c)
> +OBJS := $(addprefix $(obj),$(AOBJS) $(COBJS-y))
> +
> +
> +all: $(LIB) $(AOBJS)

drop the dead $(AOBJS) logic

> --- /dev/null
> +++ b/fs/ext4/ext4_common.c
>
> +#ifndef offsetof
> +#define offsetof(TYPE, MEMBER) ((size_t) &((TYPE *)0)->MEMBER)
> +#endif

NAK: the linux/ headers already provide this

> +void *xmalloc(size_t size)
> +{
> + void *ptr = malloc(size);
> + if (ptr == NULL && size != 0)
> + printf("bb_msg_memory_exhausted\n");
> + return ptr;
> +}

NAK: this is useless, and clearly you're copying code from busybox.  you 
*must* document that.

> +void *xzalloc(size_t size)
> +{
> + void *ptr = xmalloc(size);
> + memset(ptr, 0, size);
> + return ptr;
> +}

NAK: this doesn't fail (so the "x" doesn't make sense), and the zalloc() 
aspect should be in a common header written as:
#define zalloc(size) calloc(1, size)

> +int ext4fs_mount(unsigned part_length)
> +{
> ...
> +#ifdef DEBUG
> + printf("EXT2 rev %d, inode_size %d\n",
> +__le32_to_cpu(data->sblock.revision_level), fs->inodesz);
> +#endif

use debug()

> --- /dev/null
> +++ b/fs/ext4/ext4fs.c
>
> +/*
> + *  ext4load - based on code from GRUB2  fs/ext2.c
> +*/

you must retain copyright from the source files in the new files

> +int init_fs(block_dev_desc_t *dev_desc)
> +{
> ...
> + fs = (struct ext_filesystem *)x

Re: [U-Boot] [PATCH v2] ARMV7: Add support For Logic OMAP35x/DM37x modules

2011-12-16 Thread Tom Rini
On Thu, Dec 15, 2011 at 11:09 PM, Peter Barada  wrote:
> On 12/15/2011 01:30 PM, Tom Rini wrote:
>> On Thu, Dec 15, 2011 at 10:15 AM, Peter Barada  
>> wrote:
>>> This patch adds basic support for OMAP35x/DM37x SOM LV/Torpedo
>>> reference boards. It assumes U-boot is loaded to SDRAM with the
>>> help of another small bootloader (x-load) running from SRAM.
>> #if 0'd code isn't allowed for merging so I assume this is an RFC :)
> My bad - sent the wrong patch.  I'll update and send again.
>>> +               /* Let it soak for a bit */
>>> +               for (i = 0; i < 0x100; ++i)
>>> +                       asm("nop");
>> Can we just use a sdelay(...) here?  And in the whole function you
>> haven't addressed Igor's comment (unless it's incoming and I just
>> haven't gotten the email yet) about this just being checkboard().
> Done - "sdelay(0x100)" instead of the delay loop.

Great, thanks.

> As for the function, in arch/arm/cpu/armv7/omap3/board.c there's already
> a checkboard() function that is called early (before relocation) that
> prints out the banner.  I tried to make that a weak alias and override
> it in my board file, but when its called, gd->bd is not setup so that
> code aborts when it tries to set gd->bd->bi_arch_number.  I then tried
> storing the value in a global and then set gd->bd->bi_arch_number in
> board_init(), but between the call to checkboard() and board_init() the
> BSS section is zeroed.  If I stored/load the computed bi_arch_number
> into a non-zero static value it works, but I feel that is really fragile.
>
> Remember that identify_board() not only prints a banner but also
> determines one of four machine IDs passed to the linux kernel to
> identify which of the variants its running on.
[snip]
> So the big question before I submit V3 of this patch is whether to
> include overriding OMAP3's checkboard() function or to use
> identify_board() as is to compute bi_arch_number...  I can do it either
> way, but don't want to waste anyone's time (with the wrong method).

OK, after re-reading (and mentally applying the changes you said
you've got) the patches, along with Igor's comments on v1, just inline
your identify logic to board_init()


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


Re: [U-Boot] [PATCH v2 1/3] i.mx: i.mx6q: Add the enet clock function

2011-12-16 Thread Stefano Babic
On 16/12/2011 16:17, Jason Liu wrote:
> Cc: Stefano Babic 
> Signed-off-by: Jason Liu 
> Acked-by: Stefano Babic 
> 
> ---
> v2: Add Stefano's ack

Jason,

if you prefer it is not required to send a new version with only the
ACK. Patchworks has already applied my ACK to the previous patch.

Howerver, nothing against if it is better for you to repost the whole
patchset.

Stefano

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


Re: [U-Boot] [PATCH V11 11/13] TI: SPL: make SPL available for other SOCs as TI

2011-12-16 Thread Stefano Babic
On 16/12/2011 16:59, Tom Rini wrote:
> On Fri, Dec 16, 2011 at 8:37 AM, Stefano Babic  wrote:
>> The SPL is developped first for TI-OMAPx. The patch
>> move OMAP specific function into OMAP directory.
> 
> I wonder if we should fold this into the mv'ing patch as well.

I can squash the two patches, but I thought the review is easier as I
did. The previous patch shows clearly that the patch was only moved, and
the changes in Makefile makes possible to build the boards making the
patch bisectable. This patch then

> 
> [snip]
>> diff --git a/include/spl.h b/include/spl.h
>> +/* Boot type */
>> +#defineMMCSD_MODE_UNDEFINED0
> 
> Not your bad spacing of course, but please fix.

Thanks to have found, I will fix it.

> 
>> +/* NAND SPL functions */
>> +void spl_nand_load_image(void);
>> +void spl_arch_nand_init(void);
>> +
>> +/* MMC SPL functions */
>> +void spl_mmc_load_image(void);
> 
> These should be covered by #ifdef CONFIG_SPL_(NAND||MMC)_SUPPORT

Do we need in the header file for the prototypes ? We have never done,
and it should be not necessary.

Stefano

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


Re: [U-Boot] [PATCH V11 13/13] OMAP3: twister: add support to boot Linux from SPL

2011-12-16 Thread Stefano Babic
On 16/12/2011 17:01, Tom Rini wrote:
> On Fri, Dec 16, 2011 at 8:37 AM, Stefano Babic  wrote:
>> Signed-off-by: Stefano Babic 
>> CC: Tom Rini 
>> CC: Wolfgang Denk 
>> CC: Simon Schwarz 
> [snip]
>> +#ifdef CONFIG_SPL_BUILD
>> +#undef CONFIG_HARD_I2C
>> +#endif
> 
> If we switch the I2C test to CONFIG_SPL_I2C_SUPPORT this part here can
> go away, yes?

Right, I will fix in this way.

Stefano

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


Re: [U-Boot] [PATCH V11 10/13] OMAP3: move SPL files to be used by other architectures.

2011-12-16 Thread Stefano Babic
On 16/12/2011 16:55, Tom Rini wrote:
> On Fri, Dec 16, 2011 at 8:37 AM, Stefano Babic  wrote:
>> The SPL used on OMAPx can be reused by other SOCs from different
>> architectures. Move common files into common/ directory.
> 
> Thanks for tackling this.  My immediate concern however is that this
> breaks building nand_spl/ boards, but is that really a good concern
> still?

I think the way we have to do is to accept boards implementing the new
SPL framework, and put nand_spl in obsolescence. If a board is broken,
it must be fixed porting it to the new SPL.

Stefano

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


Re: [U-Boot] [PATCH 2/2] ext4fs write support

2011-12-16 Thread Mike Frysinger
this needs to be behind a CONFIG_EXT4_WRITE or something similar.  most people 
want to read their fs's, not write them.
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2] tools/setlocalversion: Update from the Linux Kernel

2011-12-16 Thread Mike Frysinger
On Thursday 15 December 2011 21:13:55 Kyle Moffett wrote:
> The version from the kernel is not directly usable as it has code for
> supporting CONFIG_LOCALVERSION from Kconfig, but the version that was
> imported is very similar to the one in Linux v3.2-rc4.

NAK: this breaks localversion-* support

ignoring that, i'm not sure you really need to delete the CONFIG_xxx handling.  
under u-boot, they'd expand to like "" which would end at the same code.  by 
keeping as much code as possible in common, it should make future updates 
easier.

the only place i see where you need to deviate from the kernel code is:
if test -e include/config/auto.conf; then
. include/config/auto.conf
else
echo "Error: kernelrelease not valid - run 'make prepare' to update it"
exit 1
fi

so that part i would write as:
# Disabled for u-boot
#if test -e include/config/auto.conf; then
#   . include/config/auto.conf
#else
#   echo "Error: kernelrelease not valid - run 'make prepare' to update it"
#   exit 1
#fi
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] SPL Linux Boot

2011-12-16 Thread Stefano Babic
On 16/12/2011 16:45, Tom Rini wrote:
> On Fri, Dec 16, 2011 at 8:37 AM, Stefano Babic  wrote:
>> Hi,
>>
>> this is a new submission of the Simon's work to add a way to
>> boot Linux directly from the SPL. From the last patchset series,
>> the main changes introduced by me are the following:
>>
>> - compile the cache functions in SPL to make cleanup_before_linux()
>>  available.
>> - do not call I"C function on boards where I2C is not available
>> - fix a bug from last version (fallback to U-Boot)
>> - move all related SPL stuff to common/ and fix omap related
>>  functions.
>>
>> Tested on the twister board (patches for this board in u-boot-ti, next)
>>
>> Note: to test it is also required Simon's patch:
>>
>>arm: Add Prep subcommand support to bootm
>>
>> http://patchwork.ozlabs.org/patch/129753/
> 
> I'm going to mark this series as RFC in patchwork as I see you did
> +#ifneq... in some Makefiles and I know you know better :)  That said,
> can you confirm MAKEALL -s omap3 -s omap4 -s omap5 works?

I'll do, I have not yet tested and I built OMAP3. I have seen a couple
of other things due to the moved stuff that I should fix.

>  omap4/5 has
> smaller size requirements than omap3(ish) stuff and I don't have 100%
> faith in linker magic to make sure the cache stuff added to SPL in
> arch/arm/lib/ isn't going to bloat up the omap4/5 stuff slightly.

Ok, understood, I'll check it - if the added code is too much, I will
introduce a new CONFIG_SPL_SUPPORT_CACHE to make build optional.

Stefano

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


Re: [U-Boot] [PATCH V11 13/13] OMAP3: twister: add support to boot Linux from SPL

2011-12-16 Thread Tom Rini
On Fri, Dec 16, 2011 at 8:37 AM, Stefano Babic  wrote:
> Signed-off-by: Stefano Babic 
> CC: Tom Rini 
> CC: Wolfgang Denk 
> CC: Simon Schwarz 
[snip]
> +#ifdef CONFIG_SPL_BUILD
> +#undef CONFIG_HARD_I2C
> +#endif

If we switch the I2C test to CONFIG_SPL_I2C_SUPPORT this part here can
go away, yes?

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


Re: [U-Boot] [PATCH V11 11/13] TI: SPL: make SPL available for other SOCs as TI

2011-12-16 Thread Tom Rini
On Fri, Dec 16, 2011 at 8:37 AM, Stefano Babic  wrote:
> The SPL is developped first for TI-OMAPx. The patch
> move OMAP specific function into OMAP directory.

I wonder if we should fold this into the mv'ing patch as well.

[snip]
> diff --git a/include/spl.h b/include/spl.h
> +/* Boot type */
> +#define        MMCSD_MODE_UNDEFINED    0

Not your bad spacing of course, but please fix.

> +/* NAND SPL functions */
> +void spl_nand_load_image(void);
> +void spl_arch_nand_init(void);
> +
> +/* MMC SPL functions */
> +void spl_mmc_load_image(void);

These should be covered by #ifdef CONFIG_SPL_(NAND||MMC)_SUPPORT

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


Re: [U-Boot] [PATCH] add missing space

2011-12-16 Thread Mike Frysinger
On Friday 16 December 2011 07:13:47 Anatolij Gustschin wrote:
> On Fri, 16 Dec 2011 00:32:15 +0100 Luka Perkov wrote:
> > Cosmetic patch for first U-Boot line that gets printed.
> > 
> > --- a/include/version.h
> > +++ b/include/version.h
> > 
> >  #define U_BOOT_VERSION_STRING U_BOOT_VERSION " (" U_BOOT_DATE " - " \
> > -   U_BOOT_TIME ")" CONFIG_IDENT_STRING
> > +   U_BOOT_TIME ") " CONFIG_IDENT_STRING
> 
> This change is not needed I think. Most boards defining
> CONFIG_IDENT_STRING use either a string starting with new line or
> strings like " something". So this patch will deface version string.
> Your CONFIG_IDENT_STRING should be fixed instead.

+1
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH V11 10/13] OMAP3: move SPL files to be used by other architectures.

2011-12-16 Thread Tom Rini
On Fri, Dec 16, 2011 at 8:37 AM, Stefano Babic  wrote:
> The SPL used on OMAPx can be reused by other SOCs from different
> architectures. Move common files into common/ directory.

Thanks for tackling this.  My immediate concern however is that this
breaks building nand_spl/ boards, but is that really a good concern
still?

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


Re: [U-Boot] [PATCH V11 09/13] OMAP3: SPL: do not call I2C init if no I2C is set.

2011-12-16 Thread Tom Rini
On Fri, Dec 16, 2011 at 8:37 AM, Stefano Babic  wrote:
> Call i2c initialization in spl_board_init only if I2C
> is configured for the board.
>
> Signed-off-by: Stefano Babic 
> CC: Tom Rini 
> CC: Wolfgang Denk 
> CC: Simon Schwarz 
> ---
>  arch/arm/cpu/armv7/omap3/board.c |    2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/cpu/armv7/omap3/board.c 
> b/arch/arm/cpu/armv7/omap3/board.c
> index 1f33c63..889d650 100644
> --- a/arch/arm/cpu/armv7/omap3/board.c
> +++ b/arch/arm/cpu/armv7/omap3/board.c
> @@ -92,7 +92,9 @@ u32 omap_boot_device(void)
>
>  void spl_board_init(void)
>  {
> +#ifdef CONFIG_HARD_I2C

This should be CONFIG_HARD_I2C || CONFIG_SOFT_I2C.  Or perhaps since
we're in SPL, CONFIG_SPL_I2C_SUPPORT ?

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


Re: [U-Boot] [PATCH V11 08/13] Add cache functions to SPL for armv7

2011-12-16 Thread Tom Rini
On Fri, Dec 16, 2011 at 8:37 AM, Stefano Babic  wrote:
> Signed-off-by: Stefano Babic 
> CC: Tom Rini 
> CC: Wolfgang Denk 
> CC: Simon Schwarz 

As I said in my reply to the intro email..

> -ifndef CONFIG_SPL_BUILD
> +#ifndef CONFIG_SPL_BUILD

Is why I assume this is an RFC :)

This patch is fine, assuming omap4/5 are still within size limits.

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


Re: [U-Boot] SPL Linux Boot

2011-12-16 Thread Tom Rini
On Fri, Dec 16, 2011 at 8:37 AM, Stefano Babic  wrote:
> Hi,
>
> this is a new submission of the Simon's work to add a way to
> boot Linux directly from the SPL. From the last patchset series,
> the main changes introduced by me are the following:
>
> - compile the cache functions in SPL to make cleanup_before_linux()
>  available.
> - do not call I"C function on boards where I2C is not available
> - fix a bug from last version (fallback to U-Boot)
> - move all related SPL stuff to common/ and fix omap related
>  functions.
>
> Tested on the twister board (patches for this board in u-boot-ti, next)
>
> Note: to test it is also required Simon's patch:
>
>        arm: Add Prep subcommand support to bootm
>
> http://patchwork.ozlabs.org/patch/129753/

I'm going to mark this series as RFC in patchwork as I see you did
+#ifneq... in some Makefiles and I know you know better :)  That said,
can you confirm MAKEALL -s omap3 -s omap4 -s omap5 works?  omap4/5 has
smaller size requirements than omap3(ish) stuff and I don't have 100%
faith in linker magic to make sure the cache stuff added to SPL in
arch/arm/lib/ isn't going to bloat up the omap4/5 stuff slightly.

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


[U-Boot] [PATCH V11 11/13] TI: SPL: make SPL available for other SOCs as TI

2011-12-16 Thread Stefano Babic
The SPL is developped first for TI-OMAPx. The patch
move OMAP specific function into OMAP directory.

Signed-off-by: Stefano Babic 
CC: Tom Rini 
CC: Wolfgang Denk 
CC: Simon Schwarz 
---
 arch/arm/cpu/armv7/omap-common/Makefile   |2 +
 arch/arm/cpu/armv7/omap-common/spl_omap.c |   71 +
 arch/arm/cpu/armv7/omap3/board.c  |4 ++
 arch/arm/include/asm/omap_common.h|   34 --
 common/spl.c  |1 +
 common/spl_mmc.c  |   21 ++---
 common/spl_nand.c |   14 +-
 include/spl.h |   68 +++
 8 files changed, 153 insertions(+), 62 deletions(-)
 create mode 100644 arch/arm/cpu/armv7/omap-common/spl_omap.c
 create mode 100644 include/spl.h

diff --git a/arch/arm/cpu/armv7/omap-common/Makefile 
b/arch/arm/cpu/armv7/omap-common/Makefile
index e65e992..6fb544c 100644
--- a/arch/arm/cpu/armv7/omap-common/Makefile
+++ b/arch/arm/cpu/armv7/omap-common/Makefile
@@ -44,6 +44,8 @@ ifndef CONFIG_SPL_BUILD
 ifneq ($(CONFIG_OMAP44XX)$(CONFIG_OMAP54XX),)
 COBJS  += mem-common.o
 endif
+else
+COBJS  += spl_omap.o
 endif
 
 SRCS   := $(SOBJS:.o=.S) $(COBJS:.o=.c)
diff --git a/arch/arm/cpu/armv7/omap-common/spl_omap.c 
b/arch/arm/cpu/armv7/omap-common/spl_omap.c
new file mode 100644
index 000..692d8c2
--- /dev/null
+++ b/arch/arm/cpu/armv7/omap-common/spl_omap.c
@@ -0,0 +1,71 @@
+/*
+ * (C) Copyright 2010
+ * Texas Instruments, 
+ *
+ * Aneesh V 
+ *
+ * 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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#ifdef CONFIG_GENERIC_MMC
+int board_mmc_init(bd_t *bis)
+{
+   switch (omap_boot_device()) {
+   case BOOT_DEVICE_MMC1:
+   omap_mmc_init(0);
+   break;
+   case BOOT_DEVICE_MMC2:
+   omap_mmc_init(1);
+   break;
+   }
+   return 0;
+}
+#endif
+
+#ifdef CONFIG_SPL_NAND_SUPPORT
+void spl_arch_nand_init(void)
+{
+   switch (omap_boot_mode()) {
+   case NAND_MODE_HW_ECC:
+   debug("spl: nand - using hw ecc\n");
+   gpmc_init();
+   nand_init();
+   break;
+   default:
+   puts("spl: ERROR: This bootmode is not implemented - hanging");
+   hang();
+   }
+}
+#endif
+
+u32 spl_boot_mode(void)
+{
+   return omap_boot_mode();
+}
diff --git a/arch/arm/cpu/armv7/omap3/board.c b/arch/arm/cpu/armv7/omap3/board.c
index 889d650..f06d614 100644
--- a/arch/arm/cpu/armv7/omap3/board.c
+++ b/arch/arm/cpu/armv7/omap3/board.c
@@ -42,6 +42,10 @@
 #include 
 #include 
 
+#ifdef CONFIG_SPL_BUILD
+#include 
+#endif
+
 /* Declarations */
 extern omap3_sysinfo sysinfo;
 static void omap3_setup_aux_cr(void);
diff --git a/arch/arm/include/asm/omap_common.h 
b/arch/arm/include/asm/omap_common.h
index 8a7d1e5..e46e612 100644
--- a/arch/arm/include/asm/omap_common.h
+++ b/arch/arm/include/asm/omap_common.h
@@ -64,43 +64,9 @@ void preloader_console_init(void);
 #define BOOT_DEVICE_XIPWAIT7
 #endif
 
-/* Boot type */
-#defineMMCSD_MODE_UNDEFINED0
-#define MMCSD_MODE_RAW 1
-#define MMCSD_MODE_FAT 2
-#define NAND_MODE_HW_ECC   3
-
-struct spl_image_info {
-   const char *name;
-   u8 os;
-   u32 load_addr;
-   u32 entry_point;
-   u32 size;
-};
-
-extern struct spl_image_info spl_image;
-
-extern u32* boot_params_ptr;
 u32 omap_boot_device(void);
 u32 omap_boot_mode(void);
 
-/* SPL common function s*/
-void spl_parse_image_header(const struct image_header *header);
-void omap_rev_string(char *omap_rev_string);
-int spl_uboot_key(void);
-void spl_board_prepare_for_linux(void);
-int spl_start_uboot(void);
-
-/* NAND SPL functions */
-void spl_nand_load_image(void);
-
-/* MMC SPL functions */
-void spl_mmc_load_image(void);
-
-#ifdef CONFIG_SPL_BOARD_INIT
-void spl_board_init(void);
-#endif
-
 /*
  * silicon revisions.
  * Moving this to common, so that most of code can be moved to common,
diff --git a/common/spl.c b/common/spl.c
index 1671a03..5fdf3fb 100644
--- a/common/spl.c
+++ b/common/spl

[U-Boot] [PATCH V11 13/13] OMAP3: twister: add support to boot Linux from SPL

2011-12-16 Thread Stefano Babic
Signed-off-by: Stefano Babic 
CC: Tom Rini 
CC: Wolfgang Denk 
CC: Simon Schwarz 
---
 board/technexion/twister/twister.c |   23 +++
 include/configs/twister.h  |   16 
 2 files changed, 39 insertions(+), 0 deletions(-)

diff --git a/board/technexion/twister/twister.c 
b/board/technexion/twister/twister.c
index 950e76c..fc88301 100644
--- a/board/technexion/twister/twister.c
+++ b/board/technexion/twister/twister.c
@@ -114,3 +114,26 @@ int board_mmc_init(bd_t *bis)
return omap_mmc_init(0);
 }
 #endif
+
+#ifdef CONFIG_SPL_OS_BOOT
+/*
+ * Do board specific preperation before SPL
+ * Linux boot
+ */
+void spl_board_prepare_for_linux(void)
+{
+   /* init cs for extern lan */
+   enable_gpmc_cs_config(gpmc_smc911, &gpmc_cfg->cs[5],
+   CONFIG_SMC911X_BASE, GPMC_SIZE_16M);
+}
+int spl_start_uboot(void)
+{
+   int val = 0;
+   if (!gpio_request(CONFIG_SPL_OS_BOOT_KEY, "U-Boot key")) {
+   gpio_direction_input(CONFIG_SPL_OS_BOOT_KEY);
+   val = gpio_get_value(CONFIG_SPL_OS_BOOT_KEY);
+   gpio_free(CONFIG_SPL_OS_BOOT_KEY);
+   }
+   return !val;
+}
+#endif
diff --git a/include/configs/twister.h b/include/configs/twister.h
index 64a886d..68ad31e 100644
--- a/include/configs/twister.h
+++ b/include/configs/twister.h
@@ -51,4 +51,20 @@
 #defineCONFIG_EXTRA_ENV_SETTINGS   CONFIG_TAM3517_SETTINGS \
"bootcmd=run nandboot\0"
 
+/* SPL OS boot options */
+#define CONFIG_CMD_SPL
+#define CONFIG_CMD_SPL_WRITE_SIZE  0x400 /* 1024 byte */
+#define CONFIG_SYS_NAND_SPL_KERNEL_OFFS0x0020
+#define CONFIG_CMD_SPL_NAND_OFS(CONFIG_SYS_NAND_SPL_KERNEL_OFFS+\
+   0x60)
+#define CONFIG_SPL_OS_BOOT
+#define CONFIG_SPL_OS_BOOT_KEY 7
+
+#define CONFIG_SYS_SPL_ARGS_ADDR   (PHYS_SDRAM_1 + 0x100)
+#define CONFIG_SPL_BOARD_INIT
+
+#ifdef CONFIG_SPL_BUILD
+#undef CONFIG_HARD_I2C
+#endif
+
 #endif /* __CONFIG_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 V11 12/13] SPL: call cleanup_before_linux() before booting Linux

2011-12-16 Thread Stefano Babic
Signed-off-by: Stefano Babic 
CC: Tom Rini 
CC: Wolfgang Denk 
CC: Simon Schwarz 
---
 common/spl.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/common/spl.c b/common/spl.c
index 5fdf3fb..cf5395e 100644
--- a/common/spl.c
+++ b/common/spl.c
@@ -125,7 +125,7 @@ __noreturn void jump_to_image_linux(void *arg)
__attribute__ ((noreturn));
image_entry_arg_t image_entry =
(image_entry_arg_t) spl_image.entry_point;
-   /* cleanup_before_linux(); */ /*write SPL function for that*/
+   cleanup_before_linux();
image_entry(0, CONFIG_MACH_TYPE, arg);
 }
 #endif
-- 
1.7.5.4

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


[U-Boot] [PATCH V11 10/13] OMAP3: move SPL files to be used by other architectures.

2011-12-16 Thread Stefano Babic
The SPL used on OMAPx can be reused by other SOCs from different
architectures. Move common files into common/ directory.

Signed-off-by: Stefano Babic 
CC: Tom Rini 
CC: Wolfgang Denk 
CC: Simon Schwarz 
---
 arch/arm/cpu/armv7/omap-common/Makefile|   10 --
 common/Makefile|4 
 {arch/arm/cpu/armv7/omap-common => common}/spl.c   |0
 .../arm/cpu/armv7/omap-common => common}/spl_mmc.c |0
 .../cpu/armv7/omap-common => common}/spl_nand.c|0
 5 files changed, 4 insertions(+), 10 deletions(-)
 rename {arch/arm/cpu/armv7/omap-common => common}/spl.c (100%)
 rename {arch/arm/cpu/armv7/omap-common => common}/spl_mmc.c (100%)
 rename {arch/arm/cpu/armv7/omap-common => common}/spl_nand.c (100%)

diff --git a/arch/arm/cpu/armv7/omap-common/Makefile 
b/arch/arm/cpu/armv7/omap-common/Makefile
index a684611..e65e992 100644
--- a/arch/arm/cpu/armv7/omap-common/Makefile
+++ b/arch/arm/cpu/armv7/omap-common/Makefile
@@ -40,16 +40,6 @@ COBJS+= emif-common.o
 SOBJS  += lowlevel_init.o
 endif
 
-ifdef CONFIG_SPL_BUILD
-COBJS  += spl.o
-ifdef CONFIG_SPL_NAND_SUPPORT
-COBJS  += spl_nand.o
-endif
-ifdef CONFIG_SPL_MMC_SUPPORT
-COBJS  += spl_mmc.o
-endif
-endif
-
 ifndef CONFIG_SPL_BUILD
 ifneq ($(CONFIG_OMAP44XX)$(CONFIG_OMAP54XX),)
 COBJS  += mem-common.o
diff --git a/common/Makefile b/common/Makefile
index 91f3f2e..41b67ca 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -186,6 +186,10 @@ COBJS-$(CONFIG_MENU) += menu.o
 COBJS-$(CONFIG_MODEM_SUPPORT) += modem.o
 COBJS-$(CONFIG_UPDATE_TFTP) += update.o
 COBJS-$(CONFIG_USB_KEYBOARD) += usb_kbd.o
+else
+COBJS-y += spl.o
+COBJS-$(CONFIG_SPL_NAND_SUPPORT) += spl_nand.o
+COBJS-$(CONFIG_SPL_MMC_SUPPORT) += spl_mmc.o
 endif
 
 COBJS-y += console.o
diff --git a/arch/arm/cpu/armv7/omap-common/spl.c b/common/spl.c
similarity index 100%
rename from arch/arm/cpu/armv7/omap-common/spl.c
rename to common/spl.c
diff --git a/arch/arm/cpu/armv7/omap-common/spl_mmc.c b/common/spl_mmc.c
similarity index 100%
rename from arch/arm/cpu/armv7/omap-common/spl_mmc.c
rename to common/spl_mmc.c
diff --git a/arch/arm/cpu/armv7/omap-common/spl_nand.c b/common/spl_nand.c
similarity index 100%
rename from arch/arm/cpu/armv7/omap-common/spl_nand.c
rename to common/spl_nand.c
-- 
1.7.5.4

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


[U-Boot] [PATCH V11 09/13] OMAP3: SPL: do not call I2C init if no I2C is set.

2011-12-16 Thread Stefano Babic
Call i2c initialization in spl_board_init only if I2C
is configured for the board.

Signed-off-by: Stefano Babic 
CC: Tom Rini 
CC: Wolfgang Denk 
CC: Simon Schwarz 
---
 arch/arm/cpu/armv7/omap3/board.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/arm/cpu/armv7/omap3/board.c b/arch/arm/cpu/armv7/omap3/board.c
index 1f33c63..889d650 100644
--- a/arch/arm/cpu/armv7/omap3/board.c
+++ b/arch/arm/cpu/armv7/omap3/board.c
@@ -92,7 +92,9 @@ u32 omap_boot_device(void)
 
 void spl_board_init(void)
 {
+#ifdef CONFIG_HARD_I2C
i2c_init(CONFIG_SYS_I2C_SPEED, CONFIG_SYS_I2C_SLAVE);
+#endif
 }
 #endif /* CONFIG_SPL_BUILD */
 
-- 
1.7.5.4

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


[U-Boot] [PATCH V11 08/13] Add cache functions to SPL for armv7

2011-12-16 Thread Stefano Babic
Signed-off-by: Stefano Babic 
CC: Tom Rini 
CC: Wolfgang Denk 
CC: Simon Schwarz 
---
 arch/arm/cpu/armv7/Makefile |4 ++--
 arch/arm/cpu/armv7/cpu.c|2 ++
 arch/arm/lib/Makefile   |5 +++--
 3 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/arch/arm/cpu/armv7/Makefile b/arch/arm/cpu/armv7/Makefile
index f97fa3d..69f1910 100644
--- a/arch/arm/cpu/armv7/Makefile
+++ b/arch/arm/cpu/armv7/Makefile
@@ -27,9 +27,9 @@ LIB   = $(obj)lib$(CPU).o
 
 START  := start.o
 
-ifndef CONFIG_SPL_BUILD
+#ifndef CONFIG_SPL_BUILD
 COBJS  += cache_v7.o
-endif
+#endif
 
 COBJS  += cpu.o
 COBJS  += syslib.o
diff --git a/arch/arm/cpu/armv7/cpu.c b/arch/arm/cpu/armv7/cpu.c
index 662c496..c6fa8ef 100644
--- a/arch/arm/cpu/armv7/cpu.c
+++ b/arch/arm/cpu/armv7/cpu.c
@@ -52,7 +52,9 @@ int cleanup_before_linux(void)
 *
 * we turn off caches etc ...
 */
+#ifndef CONFIG_SPL_BUILD
disable_interrupts();
+#endif
 
/*
 * Turn off I-cache and invalidate it
diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index 300c8fa..39a9550 100644
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile
@@ -39,8 +39,6 @@ GLCOBJS   += div0.o
 
 COBJS-y+= board.o
 COBJS-y+= bootm.o
-COBJS-y+= cache.o
-COBJS-y+= cache-cp15.o
 COBJS-$(CONFIG_SYS_L2_PL310) += cache-pl310.o
 COBJS-y+= interrupts.o
 COBJS-y+= reset.o
@@ -48,6 +46,9 @@ SOBJS-$(CONFIG_USE_ARCH_MEMSET) += memset.o
 SOBJS-$(CONFIG_USE_ARCH_MEMCPY) += memcpy.o
 endif
 
+COBJS-y+= cache.o
+COBJS-y+= cache-cp15.o
+
 SRCS   := $(GLSOBJS:.o=.S) $(GLCOBJS:.o=.c) \
   $(SOBJS-y:.o=.S) $(COBJS-y:.o=.c)
 OBJS   := $(addprefix $(obj),$(SOBJS-y) $(COBJS-y))
-- 
1.7.5.4

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


[U-Boot] [PATCH V11 07/13] devkit8000: Implement and activate direct OS boot

2011-12-16 Thread Stefano Babic
From: Simon Schwarz 

- Implements spl_start_uboot() for devkit8000
- Add configs to activate direct OS boot from SPL

Signed-off-by: Simon Schwarz 
CC: Tom Rini 
CC: Stefano Babic 
CC: Wolfgang Denk 
---

V10 changes:
sliced from the implementation
added an implementation of spl_start_uboot for devkit8000

 board/timll/devkit8000/devkit8000.c |   18 ++
 include/configs/devkit8000.h|7 +--
 2 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/board/timll/devkit8000/devkit8000.c 
b/board/timll/devkit8000/devkit8000.c
index 05de3c1..6ca4fe2 100644
--- a/board/timll/devkit8000/devkit8000.c
+++ b/board/timll/devkit8000/devkit8000.c
@@ -41,6 +41,7 @@
 #include 
 #include 
 #include "devkit8000.h"
+#include 
 #ifdef CONFIG_DRIVER_DM9000
 #include 
 #include 
@@ -160,6 +161,23 @@ void spl_board_prepare_for_linux(void)
gpmc_dm9000_config();
 }
 
+/*
+ * devkit8000 specific implementation of spl_start_uboot()
+ *
+ * RETURN
+ * 0 if the button is not pressed
+ * 1 if the button is pressed
+ */
+int spl_start_uboot(void)
+{
+   int val = 0;
+   if (!gpio_request(CONFIG_SPL_OS_BOOT_KEY, "U-Boot key")) {
+   gpio_direction_input(CONFIG_SPL_OS_BOOT_KEY);
+   val = gpio_get_value(CONFIG_SPL_OS_BOOT_KEY);
+   gpio_free(CONFIG_SPL_OS_BOOT_KEY);
+   }
+   return !val;
+}
 #endif
 
 /*
diff --git a/include/configs/devkit8000.h b/include/configs/devkit8000.h
index e323877..eb7c376 100644
--- a/include/configs/devkit8000.h
+++ b/include/configs/devkit8000.h
@@ -35,7 +35,7 @@
 #define CONFIG_OMAP1   /* in a TI OMAP core */
 #define CONFIG_OMAP34XX1   /* which is a 34XX */
 #define CONFIG_OMAP3_DEVKIT80001   /* working with DevKit8000 */
-
+#define CONFIG_MACH_TYPE   MACH_TYPE_DEVKIT8000
 /*
  * 1MB into the SDRAM to allow for SPL's bss at the beginning of SDRAM
  * 64 bytes before this address should be set aside for u-boot.img's
@@ -327,7 +327,7 @@
 #define CONFIG_SPL_MAX_SIZE0xB400  /* 45 K */
 #define CONFIG_SPL_STACK   LOW_LEVEL_SRAM_STACK
 
-#define CONFIG_SPL_BSS_START_ADDR  0x8000 /*CONFIG_SYS_SDRAM_BASE*/
+#define CONFIG_SPL_BSS_START_ADDR   0x8500 /* leave space for 
bootargs*/
 #define CONFIG_SPL_BSS_MAX_SIZE0x8
 
 /* NAND boot config */
@@ -352,6 +352,9 @@
 #define CONFIG_SYS_SPL_MALLOC_SIZE 0x10/* 1 MB */
 
 /* SPL OS boot options */
+#define CONFIG_SPL_OS_BOOT
+#define CONFIG_SPL_OS_BOOT_KEY 26
+
 #define CONFIG_CMD_SPL
 #define CONFIG_CMD_SPL_WRITE_SIZE   0x400 /* 1024 byte */
 #define CONFIG_CMD_SPL_NAND_OFS (CONFIG_SYS_NAND_SPL_KERNEL_OFFS+\
-- 
1.7.5.4

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


[U-Boot] [PATCH V11 06/13] omap/spl: change output of spl_parse_image_header

2011-12-16 Thread Stefano Babic
From: Simon Schwarz 

This only outputs "Assuming u-boot.bin..." if debug is active.

Signed-off-by: Simon Schwarz 
CC: Tom Rini 
CC: Stefano Babic 
CC: Wolfgang Denk 
---

V11: no changes

 arch/arm/cpu/armv7/omap-common/spl.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/cpu/armv7/omap-common/spl.c 
b/arch/arm/cpu/armv7/omap-common/spl.c
index 955a83b..1671a03 100644
--- a/arch/arm/cpu/armv7/omap-common/spl.c
+++ b/arch/arm/cpu/armv7/omap-common/spl.c
@@ -101,7 +101,7 @@ void spl_parse_image_header(const struct image_header 
*header)
/* Signature not found - assume u-boot.bin */
printf("mkimage signature not found - ih_magic = %x\n",
header->ih_magic);
-   puts("Assuming u-boot.bin ..\n");
+   debug("Assuming u-boot.bin ..\n");
/* Let's assume U-Boot will not be more than 200 KB */
spl_image.size = 200 * 1024;
spl_image.entry_point = CONFIG_SYS_TEXT_BASE;
-- 
1.7.5.4

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


[U-Boot] [PATCH V11 05/13] omap-common/spl: Add linux boot to SPL

2011-12-16 Thread Stefano Babic
From: Simon Schwarz 

This adds Linux booting to the SPL

This depends on CONFIG_MACH_TYPE patch by Igor Grinberg
(http://article.gmane.org/gmane.comp.boot-loaders.u-boot/105809)

Related CONFIGs:
CONFIG_SPL_OS_BOOT
Activates/Deactivates the OS booting feature
CONFIG_SPL_OS_BOOT_KEY
defines the IO-pin number u-boot switch - if pressed u-boot is
booted
CONFIG_SYS_NAND_SPL_KERNEL_OFFS
Offset in NAND of direct boot kernel image to use in SPL
CONFIG_SYS_SPL_ARGS_ADDR
Address where the kernel boot arguments are expected - this is
normaly RAM-begin + 0x100

Signed-off-by: Simon Schwarz 
Signed-off-by: Stefano Babic 
CC: Tom Rini 
CC: Wolfgang Denk 
---
V2 changes:
nothing

V3 changes:
nothing

V4 changes:
CHG Using CONFIG_MACH_TYPE now.
DEL CONFIG_SYS_SPL_MACHID
CHG Use CONFIG_MACH_TYPE for machine id config - This makes the patch
depending on the patch linked above

V5 changes:
FIX compile errors for OMAP4
REBASE u-boot-ti adapted new general gpio interface

V6 changes:
nothing

V7 changes:
FIX multiline comment style
(http://article.gmane.org/gmane.comp.boot-loaders.u-boot/113501)

V8 changes:
REBASE on u-boot

V9 changes:
nothing

V10 changes:
CHG used short form to mark not returning function
DEL devkit8000 config changes from this patch
CHG spl_uboot_key renamed to spl_start_uboot and defined weak to be
implemented board specific
CHG If the Linux image for the direct OS boot is not found the SPL tries
to load a u-boot image
CHG %X in %p in debug message

V11 changes:
U-Boot was always started instead of Linux

 arch/arm/cpu/armv7/omap-common/spl.c  |   49 +-
 arch/arm/cpu/armv7/omap-common/spl_nand.c |   53 
 arch/arm/include/asm/omap_common.h|1 +
 3 files changed, 78 insertions(+), 25 deletions(-)

diff --git a/arch/arm/cpu/armv7/omap-common/spl.c 
b/arch/arm/cpu/armv7/omap-common/spl.c
index 9c35a09..955a83b 100644
--- a/arch/arm/cpu/armv7/omap-common/spl.c
+++ b/arch/arm/cpu/armv7/omap-common/spl.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -64,6 +65,25 @@ void board_init_f(ulong dummy)
relocate_code(CONFIG_SPL_STACK, &gdata, CONFIG_SPL_TEXT_BASE);
 }
 
+/*
+ * Default function to determine if u-boot or the OS should
+ * be started. This implementation always returns 1.
+ *
+ * Please implement your own board specific funcion to do this.
+ *
+ * RETURN
+ * 0 to not start u-boot
+ * positive if u-boot should start
+ */
+#ifdef CONFIG_SPL_OS_BOOT
+__weak int spl_start_uboot(void)
+{
+   printf("SPL: Please implement spl_start_uboot() for your board\n");
+   printf("SPL: Direct Linux boot not active!\n");
+   return 1;
+}
+#endif
+
 void spl_parse_image_header(const struct image_header *header)
 {
u32 header_size = sizeof(struct image_header);
@@ -91,7 +111,25 @@ void spl_parse_image_header(const struct image_header 
*header)
}
 }
 
-static void jump_to_image_no_args(void)
+/*
+ * This function jumps to an image with argument. Normally an FDT or ATAGS
+ * image.
+ * arg: Pointer to paramter image in RAM
+ */
+#ifdef CONFIG_SPL_OS_BOOT
+__noreturn void jump_to_image_linux(void *arg)
+{
+   debug("Entering kernel arg pointer: 0x%p\n", arg);
+   typedef void (*image_entry_arg_t)(int, int, void *)
+   __attribute__ ((noreturn));
+   image_entry_arg_t image_entry =
+   (image_entry_arg_t) spl_image.entry_point;
+   /* cleanup_before_linux(); */ /*write SPL function for that*/
+   image_entry(0, CONFIG_MACH_TYPE, arg);
+}
+#endif
+
+void jump_to_image_no_args(void)
 {
typedef void (*image_entry_noargs_t)(u32 *)__attribute__ ((noreturn));
image_entry_noargs_t image_entry =
@@ -105,8 +143,8 @@ static void jump_to_image_no_args(void)
u32 boot_params_ptr_addr = (u32)&boot_params_ptr;
image_entry((u32 *)boot_params_ptr_addr);
 }
-
 void jump_to_image_no_args(void) __attribute__ ((noreturn));
+
 void board_init_r(gd_t *id, ulong dummy)
 {
u32 boot_device;
@@ -146,6 +184,13 @@ void board_init_r(gd_t *id, ulong dummy)
debug("Jumping to U-Boot\n");
jump_to_image_no_args();
break;
+#ifdef CONFIG_SPL_OS_BOOT
+   case IH_OS_LINUX:
+   debug("Jumping to Linux\n");
+   spl_board_prepare_for_linux();
+   jump_to_image_linux((void *)CONFIG_SYS_SPL_ARGS_ADDR);
+   break;
+#endif
default:
puts("Unsupported OS image.. Jumping nevertheless..\n");
jump_to_image_no_args();
diff --git a/arch/arm/cpu/armv7/omap-common/spl_nand.c 
b/arch/arm/cpu/armv7/omap-common/spl_nand.c
index 2a66214..1295e88 100644
--- a/arch/arm/cpu/armv7/omap-common/spl_nand.c
+++ b/arch/arm/cpu/armv7/omap-common/spl_nand.c
@@ -29,7 +29,6 @@
 #include 
 #include 
 
-
 void spl_nand_load_image(void)
 {
str

[U-Boot] [PATCH V11 01/13] Add cmd_spl command

2011-12-16 Thread Stefano Babic
From: Simon Schwarz 

This adds a spl command to the u-boot.

Related config:
CONFIG_CMD_CPL
activate/deactivate the command
CONFIG_CMD_SPL_NAND_OFS
Offset in NAND to use

Signed-off-by: Simon Schwarz 
CC: Tom Rini 
CC: Stefano Babic 
CC: Wolfgang Denk 
---
V2 changes:
CHG corrected bootm call. Now bootm is called with five parameters including
Address of FDT in RAM. This fixes the hang on savebp fdt call.
ADD debug output of the actual bootm parameter call
CHG help message

V3 changes:
FIX added missing brackets

V4 changes:
CHG Corrected argument number in comments
CHG added check for CONFIG_OF_LIBFDT
CHG squashed the README to this commit
DEL define description from commit message - unused in this patch
CHG renamed to spl now with subcommand export, very different now
ADD New call style with subcommands.
CHG added printf where the image is located
CHG Patched README to reflect changes
CHG parameter count
CHG usage message

V5 changes:
nothing

V6 changes:
nothing

V7 changes:
FIX multiline comment style, cosmetic changes
(http://article.gmane.org/gmane.comp.boot-loaders.u-boot/113499)
REBASE on u-boot

V8 changes:
nothing

V9 changes:
nothing

V10 changes:
CHG list is now terminated by NULL not \0
ADD static modifiers to most of cmd_spl.c functions
DEL board changes
ADD include protection to cmd_spl.h
DEL not used enum image_tyep
CHG some cosmetic
CHG images extern moved from cmd_spl.h to image.h

V11 changes:
nothing

 common/Makefile |1 +
 common/cmd_spl.c|  229 +++
 doc/README.commands.spl |   31 +++
 include/cmd_spl.h   |   30 ++
 include/image.h |2 +
 5 files changed, 293 insertions(+), 0 deletions(-)
 create mode 100644 common/cmd_spl.c
 create mode 100644 doc/README.commands.spl
 create mode 100644 include/cmd_spl.h

diff --git a/common/Makefile b/common/Makefile
index 1be7236..91f3f2e 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -165,6 +165,7 @@ COBJS-$(CONFIG_USB_STORAGE) += usb_storage.o
 endif
 COBJS-$(CONFIG_CMD_XIMG) += cmd_ximg.o
 COBJS-$(CONFIG_YAFFS2) += cmd_yaffs2.o
+COBJS-$(CONFIG_CMD_SPL) += cmd_spl.o
 
 # others
 ifdef CONFIG_DDR_SPD
diff --git a/common/cmd_spl.c b/common/cmd_spl.c
new file mode 100644
index 000..deab8e9
--- /dev/null
+++ b/common/cmd_spl.c
@@ -0,0 +1,229 @@
+/*
+ * Copyright (C) 2011
+ * Corscience GmbH & Co. KG - Simon Schwarz 
+ *
+ * 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 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/* Calls bootm with the parameters given */
+static int call_bootm(int argc, char * const argv[], char *subcommand[])
+{
+   char *bootm_argv[5];
+   char command[] = "do_bootm";
+
+   int i = 0;
+   int ret = 0;
+
+   /* create paramter array */
+   bootm_argv[0] = command;
+   switch (argc) {
+   case 3:
+   bootm_argv[4] = argv[2]; /* fdt addr */
+   case 2:
+   bootm_argv[3] = argv[1]; /* initrd addr */
+   case 1:
+   bootm_argv[2] = argv[0]; /* kernel addr */
+   }
+
+
+   /*
+* - do the work -
+* exec subcommands of do_bootm to init the images
+* data structure
+*/
+   while (subcommand[i] != NULL) {
+   bootm_argv[1] = subcommand[i];
+   debug("args: %s, %s, %s, %s, %s, %d\n", bootm_argv[0],
+   bootm_argv[1], bootm_argv[2], bootm_argv[3],
+   bootm_argv[4], argc);
+   ret = do_bootm(find_cmd("do_bootm"), 0, argc+2,
+   bootm_argv);
+   debug("Subcommand retcode: %d\n", ret);
+   i++;
+   }
+
+   if (ret) {
+   printf("ERROR prep subcommand failed!\n");
+   return -1;
+   }
+
+   return 0;
+}
+
+/* assemble the bootm paramteres for fdt creation */
+static int spl_export_fdt(int argc, char * const argv[])
+{
+#ifdef CONFIG_OF_LIBFDT
+   /* Create subcommand string */
+   char *subcommand[] = {
+   "start",
+   "loados",
+#ifdef CONFIG_SYS_BOOT_RAMDISK_HIGH
+   "ramdisk",
+#endif
+   "fdt",
+   "cmdline",
+   "bdt",
+   "prep",

[U-Boot] [PATCH V11 04/13] devkit8000/spl: init GPMC for dm9000 in SPL

2011-12-16 Thread Stefano Babic
From: Simon Schwarz 

Linux crashes if the GPMC isn't configured for the dm9000.

Signed-off-by: Simon Schwarz 
CC: Tom Rini 
CC: Stefano Babic 
CC: Wolfgang Denk 
---
V2 changes:
nothing

V3 changes:
nothing

V4 changes:
noting

V5 changes:
nothing

V6 changes:
nothing

V7 changes:
FIX multiline comment style
(http://article.gmane.org/gmane.comp.boot-loaders.u-boot/113500)

V8 changes:
REBASE on u-boot

V9 changes:
nothing

V10 changes:
use enable_gpmc_cs_config to config the GPMC for dm9000

 arch/arm/include/asm/omap_common.h  |2 +
 board/timll/devkit8000/devkit8000.c |   39 +++---
 2 files changed, 33 insertions(+), 8 deletions(-)

diff --git a/arch/arm/include/asm/omap_common.h 
b/arch/arm/include/asm/omap_common.h
index 1ec651b..62200e5 100644
--- a/arch/arm/include/asm/omap_common.h
+++ b/arch/arm/include/asm/omap_common.h
@@ -87,6 +87,8 @@ u32 omap_boot_mode(void);
 /* SPL common function s*/
 void spl_parse_image_header(const struct image_header *header);
 void omap_rev_string(char *omap_rev_string);
+int spl_uboot_key(void);
+void spl_board_prepare_for_linux(void);
 
 /* NAND SPL functions */
 void spl_nand_load_image(void);
diff --git a/board/timll/devkit8000/devkit8000.c 
b/board/timll/devkit8000/devkit8000.c
index b06aab6..05de3c1 100644
--- a/board/timll/devkit8000/devkit8000.c
+++ b/board/timll/devkit8000/devkit8000.c
@@ -63,6 +63,24 @@ int board_init(void)
return 0;
 }
 
+static u32 gpmc_net_config[GPMC_MAX_REG] = {
+   NET_GPMC_CONFIG1,
+   NET_GPMC_CONFIG2,
+   NET_GPMC_CONFIG3,
+   NET_GPMC_CONFIG4,
+   NET_GPMC_CONFIG5,
+   NET_GPMC_CONFIG6,
+   NET_GPMC_CONFIG7,
+};
+
+
+/* Configure GPMC registers for DM9000 */
+static void gpmc_dm9000_config(void)
+{
+   enable_gpmc_cs_config(gpmc_net_config, &gpmc_cfg->cs[6],
+   CONFIG_DM9000_BASE, GPMC_SIZE_16M);
+}
+
 /*
  * Routine: misc_init_r
  * Description: Configure board specific parts
@@ -81,14 +99,7 @@ int misc_init_r(void)
 #endif
 
 #ifdef CONFIG_DRIVER_DM9000
-   /* Configure GPMC registers for DM9000 */
-   writel(NET_GPMC_CONFIG1, &gpmc_cfg->cs[6].config1);
-   writel(NET_GPMC_CONFIG2, &gpmc_cfg->cs[6].config2);
-   writel(NET_GPMC_CONFIG3, &gpmc_cfg->cs[6].config3);
-   writel(NET_GPMC_CONFIG4, &gpmc_cfg->cs[6].config4);
-   writel(NET_GPMC_CONFIG5, &gpmc_cfg->cs[6].config5);
-   writel(NET_GPMC_CONFIG6, &gpmc_cfg->cs[6].config6);
-   writel(NET_GPMC_CONFIG7, &gpmc_cfg->cs[6].config7);
+   gpmc_dm9000_config();
 
/* Use OMAP DIE_ID as MAC address */
if (!eth_getenv_enetaddr("ethaddr", enetaddr)) {
@@ -139,6 +150,18 @@ int board_eth_init(bd_t *bis)
 }
 #endif
 
+#ifdef CONFIG_SPL_OS_BOOT
+/*
+ * Do board specific preperation before SPL
+ * Linux boot
+ */
+void spl_board_prepare_for_linux(void)
+{
+   gpmc_dm9000_config();
+}
+
+#endif
+
 /*
  * Routine: get_board_mem_timings
  * Description: If we use SPL then there is no x-loader nor config header
-- 
1.7.5.4

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


[U-Boot] [PATCH V11 03/13] omap-common: Add NAND SPL linux booting

2011-12-16 Thread Stefano Babic
From: Simon Schwarz 

This implements booting of Linux from NAND in SPL

Related config parameters:
CONFIG_SYS_NAND_SPL_KERNEL_OFFS
Offset in NAND of direct boot kernel image to use in SPL
CONFIG_SYS_SPL_ARGS_ADDR
Address where the kernel boot arguments are expected - this is
normally RAM-start + 0x100 (on ARM)

Signed-off-by: Simon Schwarz 
CC: Tom Rini 
CC: Stefano Babic 
CC: Wolfgang Denk 
---
V2 changes:
nothing

V3 changes:
nothing

V4 changes:
ADD define description to commit message
CHG renaming some defines - renaming SAVEBP SPL

V5 changes:
nothing

V6 changes:
nothing

V7 changes:
nothing

V8 changes:
FIX multiline comment style
REBASE on u-boot

V9 changes:
nothing

V10 changes:
ADD unused __attribute__ to src and dst because they provoked a warning
if SPL os boot was not active

V11 changes:
nothing
 arch/arm/cpu/armv7/omap-common/spl_nand.c |   66 ++---
 1 files changed, 50 insertions(+), 16 deletions(-)

diff --git a/arch/arm/cpu/armv7/omap-common/spl_nand.c 
b/arch/arm/cpu/armv7/omap-common/spl_nand.c
index 38d06b1..2a66214 100644
--- a/arch/arm/cpu/armv7/omap-common/spl_nand.c
+++ b/arch/arm/cpu/armv7/omap-common/spl_nand.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -32,6 +33,9 @@
 void spl_nand_load_image(void)
 {
struct image_header *header;
+   int *src __attribute__((unused));
+   int *dst __attribute__((unused));
+
switch (omap_boot_mode()) {
case NAND_MODE_HW_ECC:
debug("spl: nand - using hw ecc\n");
@@ -45,26 +49,56 @@ void spl_nand_load_image(void)
 
/*use CONFIG_SYS_TEXT_BASE as temporary storage area */
header = (struct image_header *)(CONFIG_SYS_TEXT_BASE);
+#ifdef CONFIG_SPL_OS_BOOT
+   if (!spl_uboot_key()) {
+   /*
+* load parameter image
+* load to temp position since nand_spl_load_image reads
+* a whole block which is typically larger than
+* CONFIG_CMD_SAVEBP_WRITE_SIZE therefore may overwrite
+* following sections like BSS
+*/
+   nand_spl_load_image(CONFIG_CMD_SPL_NAND_OFS,
+   CONFIG_CMD_SPL_WRITE_SIZE,
+   (void *)CONFIG_SYS_TEXT_BASE);
+   /* copy to destintion */
+   for (dst = (int *)CONFIG_SYS_SPL_ARGS_ADDR,
+   src = (int *)CONFIG_SYS_TEXT_BASE;
+   src < (int *)(CONFIG_SYS_TEXT_BASE +
+   CONFIG_CMD_SPL_WRITE_SIZE);
+   src++, dst++) {
+   writel(readl(src), dst);
+   }
 
+   /* load linux */
+   nand_spl_load_image(CONFIG_SYS_NAND_SPL_KERNEL_OFFS,
+   CONFIG_SYS_NAND_PAGE_SIZE, (void *)header);
+   spl_parse_image_header(header);
+   nand_spl_load_image(CONFIG_SYS_NAND_SPL_KERNEL_OFFS,
+   spl_image.size, (void *)spl_image.load_addr);
+   } else
+#endif
+   {
 #ifdef CONFIG_NAND_ENV_DST
-   nand_spl_load_image(CONFIG_ENV_OFFSET,
-   CONFIG_SYS_NAND_PAGE_SIZE, (void *)header);
-   spl_parse_image_header(header);
-   nand_spl_load_image(CONFIG_ENV_OFFSET, spl_image.size,
-   (void *)image_load_addr);
+   nand_spl_load_image(CONFIG_ENV_OFFSET,
+   CONFIG_SYS_NAND_PAGE_SIZE, (void *)header);
+   spl_parse_image_header(header);
+   nand_spl_load_image(CONFIG_ENV_OFFSET, spl_image.size,
+   (void *)spl_image.load_addr);
 #ifdef CONFIG_ENV_OFFSET_REDUND
-   nand_spl_load_image(CONFIG_ENV_OFFSET_REDUND,
-   CONFIG_SYS_NAND_PAGE_SIZE, (void *)header);
-   spl_parse_image_header(header);
-   nand_spl_load_image(CONFIG_ENV_OFFSET_REDUND, spl_image.size,
-   (void *)image_load_addr);
+   nand_spl_load_image(CONFIG_ENV_OFFSET_REDUND,
+   CONFIG_SYS_NAND_PAGE_SIZE, (void *)header);
+   spl_parse_image_header(header);
+   nand_spl_load_image(CONFIG_ENV_OFFSET_REDUND, spl_image.size,
+   (void *)spl_image.load_addr);
 #endif
 #endif
-   /* Load u-boot */
-   nand_spl_load_image(CONFIG_SYS_NAND_U_BOOT_OFFS,
-   CONFIG_SYS_NAND_PAGE_SIZE, (void *)header);
-   spl_parse_image_header(header);
-   nand_spl_load_image(CONFIG_SYS_NAND_U_BOOT_OFFS,
-   spl_image.size, (void *)spl_image.load_addr);
+   /* Load u-boot */
+   nand_spl_load_image(CONFIG_SYS_NAND_U_BOOT_OFFS,
+   CONFIG_SYS_NAND_PAGE_SIZE, (void *)header);
+   spl_parse_image_header(header);
+   nand_spl_load_image(CONFIG_SYS_NAND_U_BOOT_OFFS,
+   spl_image.size, (void *)spl_image.load_ad

[U-Boot] [PATCH V11 02/13] devki8000: add config for spl command

2011-12-16 Thread Stefano Babic
From: Simon Schwarz 

This adds some configs for devkit8000 to use the new spl command

Signed-off-by: Simon Schwarz 
CC: Tom Rini 
CC: Stefano Babic 
CC: Wolfgang Denk 
---

V10 changes:
This is new in V10 was split from other patch

 include/configs/devkit8000.h |8 
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/include/configs/devkit8000.h b/include/configs/devkit8000.h
index 2b6a6ee..e323877 100644
--- a/include/configs/devkit8000.h
+++ b/include/configs/devkit8000.h
@@ -351,4 +351,12 @@
 #define CONFIG_SYS_SPL_MALLOC_START0x80208000
 #define CONFIG_SYS_SPL_MALLOC_SIZE 0x10/* 1 MB */
 
+/* SPL OS boot options */
+#define CONFIG_CMD_SPL
+#define CONFIG_CMD_SPL_WRITE_SIZE   0x400 /* 1024 byte */
+#define CONFIG_CMD_SPL_NAND_OFS (CONFIG_SYS_NAND_SPL_KERNEL_OFFS+\
+   0x40)
+#define CONFIG_SYS_NAND_SPL_KERNEL_OFFS 0x28
+#define CONFIG_SYS_SPL_ARGS_ADDR(PHYS_SDRAM_1 + 0x100)
+
 #endif /* __CONFIG_H */
-- 
1.7.5.4

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


[U-Boot] SPL Linux Boot

2011-12-16 Thread Stefano Babic
Hi,

this is a new submission of the Simon's work to add a way to
boot Linux directly from the SPL. From the last patchset series,
the main changes introduced by me are the following:

- compile the cache functions in SPL to make cleanup_before_linux()
  available.
- do not call I"C function on boards where I2C is not available
- fix a bug from last version (fallback to U-Boot)
- move all related SPL stuff to common/ and fix omap related
  functions.

Tested on the twister board (patches for this board in u-boot-ti, next)

Note: to test it is also required Simon's patch:

arm: Add Prep subcommand support to bootm

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


[PATCH V11  01/13] Add cmd_spl command
[PATCH V11  02/13] devki8000: add config for spl command
[PATCH V11  03/13] omap-common: Add NAND SPL linux booting
[PATCH V11  04/13] devkit8000/spl: init GPMC for dm9000 in SPL
[PATCH V11  05/13] omap-common/spl: Add linux boot to SPL
[PATCH V11  06/13] omap/spl: change output of spl_parse_image_header
[PATCH V11  07/13] devkit8000: Implement and activate direct OS boot
[PATCH V11  08/13] Add cache functions to SPL for armv7
[PATCH V11  09/13] OMAP3: SPL: do not call I2C init if no I2C is
[PATCH V11  10/13] OMAP3: move SPL files to be used by other
[PATCH V11  11/13] TI: SPL: make SPL available for other SOCs as TI
[PATCH V11  12/13] SPL: call cleanup_before_linux() before booting
[PATCH V11  13/13] OMAP3: twister: add support to boot Linux from
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH v2 3/3] i.mx6q: arm2: Add the enet function support

2011-12-16 Thread Jason Liu
This enable the network function on the i.mx6q armadillo2
board(arm2), thus we can use tftp to load image from network.

Cc: Stefano Babic 
Signed-off-by: Jason Liu 
Tested-by: Dirk Behme 

---
v2: use constant define and remove ETHPRIME config
---
 board/freescale/mx6qarm2/mx6qarm2.c |   90 +++
 include/configs/mx6qarm2.h  |   12 -
 2 files changed, 100 insertions(+), 2 deletions(-)

diff --git a/board/freescale/mx6qarm2/mx6qarm2.c 
b/board/freescale/mx6qarm2/mx6qarm2.c
index 89e0e76..9894245 100644
--- a/board/freescale/mx6qarm2/mx6qarm2.c
+++ b/board/freescale/mx6qarm2/mx6qarm2.c
@@ -29,6 +29,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -40,6 +42,10 @@ DECLARE_GLOBAL_DATA_PTR;
PAD_CTL_PUS_47K_UP  | PAD_CTL_SPEED_LOW |   \
PAD_CTL_DSE_80ohm   | PAD_CTL_SRE_FAST  | PAD_CTL_HYS)
 
+#define ENET_PAD_CTRL  (PAD_CTL_PKE | PAD_CTL_PUE |\
+   PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED   | \
+   PAD_CTL_DSE_40ohm   | PAD_CTL_HYS)
+
 int dram_init(void)
 {
gd->ram_size = get_ram_size((void *)PHYS_SDRAM, PHYS_SDRAM_SIZE);
@@ -79,11 +85,35 @@ iomux_v3_cfg_t usdhc4_pads[] = {
MX6Q_PAD_SD4_DAT7__USDHC4_DAT7 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
 };
 
+iomux_v3_cfg_t enet_pads[] = {
+   MX6Q_PAD_KEY_COL1__ENET_MDIO| MUX_PAD_CTRL(ENET_PAD_CTRL),
+   MX6Q_PAD_KEY_COL2__ENET_MDC | MUX_PAD_CTRL(ENET_PAD_CTRL),
+   MX6Q_PAD_RGMII_TXC__ENET_RGMII_TXC  | MUX_PAD_CTRL(ENET_PAD_CTRL),
+   MX6Q_PAD_RGMII_TD0__ENET_RGMII_TD0  | MUX_PAD_CTRL(ENET_PAD_CTRL),
+   MX6Q_PAD_RGMII_TD1__ENET_RGMII_TD1  | MUX_PAD_CTRL(ENET_PAD_CTRL),
+   MX6Q_PAD_RGMII_TD2__ENET_RGMII_TD2  | MUX_PAD_CTRL(ENET_PAD_CTRL),
+   MX6Q_PAD_RGMII_TD3__ENET_RGMII_TD3  | MUX_PAD_CTRL(ENET_PAD_CTRL),
+   MX6Q_PAD_RGMII_TX_CTL__RGMII_TX_CTL | MUX_PAD_CTRL(ENET_PAD_CTRL),
+   MX6Q_PAD_ENET_REF_CLK__ENET_TX_CLK  | MUX_PAD_CTRL(ENET_PAD_CTRL),
+   MX6Q_PAD_RGMII_RXC__ENET_RGMII_RXC  | MUX_PAD_CTRL(ENET_PAD_CTRL),
+   MX6Q_PAD_RGMII_RD0__ENET_RGMII_RD0  | MUX_PAD_CTRL(ENET_PAD_CTRL),
+   MX6Q_PAD_RGMII_RD1__ENET_RGMII_RD1  | MUX_PAD_CTRL(ENET_PAD_CTRL),
+   MX6Q_PAD_RGMII_RD2__ENET_RGMII_RD2  | MUX_PAD_CTRL(ENET_PAD_CTRL),
+   MX6Q_PAD_RGMII_RD3__ENET_RGMII_RD3  | MUX_PAD_CTRL(ENET_PAD_CTRL),
+   MX6Q_PAD_RGMII_RX_CTL__RGMII_RX_CTL | MUX_PAD_CTRL(ENET_PAD_CTRL),
+};
+
+
 static void setup_iomux_uart(void)
 {
imx_iomux_v3_setup_multiple_pads(uart4_pads, ARRAY_SIZE(uart4_pads));
 }
 
+static void setup_iomux_enet(void)
+{
+   imx_iomux_v3_setup_multiple_pads(enet_pads, ARRAY_SIZE(enet_pads));
+}
+
 #ifdef CONFIG_FSL_ESDHC
 struct fsl_esdhc_cfg usdhc_cfg[2] = {
{USDHC3_BASE_ADDR, 1},
@@ -132,9 +162,69 @@ int board_mmc_init(bd_t *bis)
 }
 #endif
 
+#define MII_MMD_ACCESS_CTRL_REG0xd
+#define MII_MMD_ACCESS_ADDR_DATA_REG   0xe
+#define MII_DBG_PORT_REG   0x1d
+#define MII_DBG_PORT2_REG  0x1e
+
+int fecmxc_mii_postcall(int phy)
+{
+   unsigned short val;
+
+   /*
+* Due to the i.MX6Q Armadillo2 board HW design,there is
+* no 125Mhz clock input from SOC. In order to use RGMII,
+* We need enable AR8031 ouput a 125MHz clk from CLK_25M
+*/
+   miiphy_write("FEC", phy, MII_MMD_ACCESS_CTRL_REG, 0x7);
+   miiphy_write("FEC", phy, MII_MMD_ACCESS_ADDR_DATA_REG, 0x8016);
+   miiphy_write("FEC", phy, MII_MMD_ACCESS_CTRL_REG, 0x4007);
+   miiphy_read("FEC", phy, MII_MMD_ACCESS_ADDR_DATA_REG, &val);
+   val &= 0xffe3;
+   val |= 0x18;
+   miiphy_write("FEC", phy, MII_MMD_ACCESS_ADDR_DATA_REG, val);
+
+   /* For the RGMII phy, we need enable tx clock delay */
+   miiphy_write("FEC", phy, MII_DBG_PORT_REG, 0x5);
+   miiphy_read("FEC", phy, MII_DBG_PORT2_REG, &val);
+   val |= 0x0100;
+   miiphy_write("FEC", phy, MII_DBG_PORT2_REG, val);
+
+   miiphy_write("FEC", phy, MII_BMCR, 0xa100);
+
+   return 0;
+}
+
+int board_eth_init(bd_t *bis)
+{
+   struct eth_device *dev;
+   int ret;
+
+   ret = cpu_eth_init(bis);
+   if (ret) {
+   printf("FEC MXC: %s:failed\n", __func__);
+   return ret;
+   }
+
+   dev = eth_get_dev_by_name("FEC");
+   if (!dev) {
+   printf("FEC MXC: Unable to get FEC device entry\n");
+   return -EINVAL;
+   }
+
+   ret = fecmxc_register_mii_postcall(dev, fecmxc_mii_postcall);
+   if (ret) {
+   printf("FEC MXC: Unable to register FEC mii postcall\n");
+   return ret;
+   }
+
+   return 0;
+}
+
 int board_early_init_f(void)
 {
setup_iomux_uart();
+   setup_iomux_enet();
 
return 0;
 }
diff --git a/include/configs/mx6qarm2.h b/include/configs/mx6qarm2.h
index a7b363d..124a7a6 100644
--- a/include/configs/mx6qarm2.h
+++ b/include/configs/mx6qarm2.h
@@ -

[U-Boot] [PATCH v2 2/3] fec: add the i.mx6q enet driver support

2011-12-16 Thread Jason Liu
Cc: Stefano Babic 
Signed-off-by: Jason Liu 
Acked-by: Stefano Babic 

---
v2: Add Stefano's ack
---
 drivers/net/fec_mxc.c |   10 ++
 drivers/net/fec_mxc.h |7 ++-
 2 files changed, 16 insertions(+), 1 deletions(-)

diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
index b05a4c0..3affda8 100644
--- a/drivers/net/fec_mxc.c
+++ b/drivers/net/fec_mxc.c
@@ -384,6 +384,14 @@ static int fec_open(struct eth_device *edev)
writel(1 << 2, &fec->eth->x_cntrl);
fec->rbd_index = 0;
 
+#if defined(CONFIG_MX6Q)
+   /* Enable ENET HW endian SWAP */
+   writel(readl(&fec->eth->ecntrl) | FEC_ECNTRL_DBSWAP,
+   &fec->eth->ecntrl);
+   /* Enable ENET store and forward mode */
+   writel(readl(&fec->eth->x_wmrk) | FEC_X_WMRK_STRFWD,
+   &fec->eth->x_wmrk);
+#endif
/*
 * Enable FEC-Lite controller
 */
@@ -485,6 +493,8 @@ static int fec_init(struct eth_device *dev, bd_t* bd)
rcntrl = PKTSIZE << FEC_RCNTRL_MAX_FL_SHIFT;
if (fec->xcv_type == SEVENWIRE)
rcntrl |= FEC_RCNTRL_FCE;
+   else if (fec->xcv_type == RGMII)
+   rcntrl |= FEC_RCNTRL_RGMII;
else if (fec->xcv_type == RMII)
rcntrl |= FEC_RCNTRL_RMII;
else/* MII mode */
diff --git a/drivers/net/fec_mxc.h b/drivers/net/fec_mxc.h
index 8b26645..39337bf 100644
--- a/drivers/net/fec_mxc.h
+++ b/drivers/net/fec_mxc.h
@@ -196,6 +196,7 @@ struct ethernet_regs {
 #define FEC_RCNTRL_PROM0x0008
 #define FEC_RCNTRL_BC_REJ  0x0010
 #define FEC_RCNTRL_FCE 0x0020
+#define FEC_RCNTRL_RGMII   0x0040
 #define FEC_RCNTRL_RMII0x0100
 
 #define FEC_TCNTRL_GTS 0x0001
@@ -206,6 +207,9 @@ struct ethernet_regs {
 
 #define FEC_ECNTRL_RESET   0x0001  /* reset the FEC */
 #define FEC_ECNTRL_ETHER_EN0x0002  /* enable the FEC */
+#define FEC_ECNTRL_DBSWAP  0x0100
+
+#define FEC_X_WMRK_STRFWD  0x0100
 
 #if defined(CONFIG_MX25) || defined(CONFIG_MX53)
 /* defines for MIIGSK */
@@ -261,7 +265,8 @@ enum xceiver_type {
SEVENWIRE,  /* 7-wire   */
MII10,  /* MII 10Mbps   */
MII100, /* MII 100Mbps  */
-   RMII/* RMII */
+   RMII,   /* RMII */
+   RGMII,  /* RGMII */
 };
 
 /**
-- 
1.7.4.1


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


[U-Boot] [PATCH v2 1/3] i.mx: i.mx6q: Add the enet clock function

2011-12-16 Thread Jason Liu
Cc: Stefano Babic 
Signed-off-by: Jason Liu 
Acked-by: Stefano Babic 

---
v2: Add Stefano's ack
---
 arch/arm/cpu/armv7/mx6/clock.c |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/arch/arm/cpu/armv7/mx6/clock.c b/arch/arm/cpu/armv7/mx6/clock.c
index b143535..fa3a124 100644
--- a/arch/arm/cpu/armv7/mx6/clock.c
+++ b/arch/arm/cpu/armv7/mx6/clock.c
@@ -285,6 +285,11 @@ u32 imx_get_uartclk(void)
return get_uart_clk();
 }
 
+u32 imx_get_fecclk(void)
+{
+   return decode_pll(PLL_ENET, CONFIG_SYS_MX6_HCLK);
+}
+
 unsigned int mxc_get_clock(enum mxc_clock clk)
 {
switch (clk) {
-- 
1.7.4.1


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


[U-Boot] [PATCH v2 0/3] i.mx6q: Add the ethernet function support

2011-12-16 Thread Jason Liu
This patch add the ethernet function support for i.mx6q/arm2 board.

The patch has been tested ok by: Dirk Behme 
on freescale i.mx6qarm2 board.

Jason Liu (3):
  i.mx: i.mx6q: Add the enet clock function
  fec: add the i.mx6q enet driver support
  i.mx6q: arm2: Add the enet function support

 arch/arm/cpu/armv7/mx6/clock.c  |5 ++
 board/freescale/mx6qarm2/mx6qarm2.c |   90 +++
 drivers/net/fec_mxc.c   |   10 
 drivers/net/fec_mxc.h   |7 ++-
 include/configs/mx6qarm2.h  |   12 -
 5 files changed, 121 insertions(+), 3 deletions(-)

-- 
1.7.4.1


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


Re: [U-Boot] fsl_esdhc.c bug

2011-12-16 Thread Jim Lentz

On 12/16/2011 09:51 AM, Fabio Estevam wrote:

Hi Jim,

On Fri, Dec 16, 2011 at 11:48 AM, Jim Lentz  wrote:

All,

There is a bug rendering SDCard support useless on Freescale esdhc
controller.

Which Freescale processor do you use?

Please describe in details the problem you see, how to reproduce it,
the U-boot version
that you use, etc.

Regards,

Fabio Estevam

Freescale P2020. Latest U-boot version.

Easiest way to see it is typing mmcinfo at the U-boot cli. It will hang.

By default, PIO mode is selected when CONFIG_P2020 is defined. Legacy 
P2020 silicon revisions require PIO mode.


The esdhc_pio_read_write function has a bad reg pointer.

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


Re: [U-Boot] [PATCH v5 3/3] mx28evk: Add initial support for MX28EVK board

2011-12-16 Thread Veli-Pekka Peltola

Hi Fabio,

On 12/16/2011 12:07 AM, Fabio Estevam wrote:

Tested boot via SD card and by loading a kernel via TFTP through
the FEC interface.


Have you any idea why this works from SD card but not by USB recovery 
using exactly same sb file?


By quick look it seems that control is not passed back to the ROM 
properly after SPL or ROM is unable to load/run U-Boot after SPL.


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


Re: [U-Boot] [PATCH 3/3] i.mx6q: arm2: Add the enet function support

2011-12-16 Thread Liu Hui-R64343
>-Original Message-
>From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de]
>On Behalf Of Stefano Babic
>Sent: Friday, December 16, 2011 7:30 PM
>To: Jason Liu
>Cc: u-boot@lists.denx.de
>Subject: Re: [U-Boot] [PATCH 3/3] i.mx6q: arm2: Add the enet function
>support
>
>On 13/12/2011 14:44, Jason Liu wrote:
>> This enable the network function on the i.mx6q armadillo2 board(arm2),
>> thus we can use tftp to load image from network.
>>
>> Cc: Stefano Babic 
>> Signed-off-by: Jason Liu 
>> Tested-by: Dirk Behme 
>> ---
>>  board/freescale/mx6qarm2/mx6qarm2.c |   90
>+++
>>  include/configs/mx6qarm2.h  |   13 -
>>  2 files changed, 101 insertions(+), 2 deletions(-)
>>
>
>Hi Jason,
>
>only a couple of minor issues.

Thanks for the review.

>
>> +
>>  #ifdef CONFIG_FSL_ESDHC
>>  struct fsl_esdhc_cfg usdhc_cfg[2] = {
>>  {USDHC3_BASE_ADDR, 1},
>> @@ -132,9 +162,69 @@ int board_mmc_init(bd_t *bis)  }  #endif
>>
>> +#define MII_MMD_ACCESS_CTRL_REG 0xd
>> +#define MII_MMD_ACCESS_ADDR_DATA_REG0xe
>> +#define MII_DBG_PORT_REG0x1d
>> +#define MII_DBG_PORT2_REG   0x1e
>> +
>> +int fecmxc_mii_postcall(int phy)
>> +{
>> +unsigned short val;
>> +
>> +/*
>> + * Due to the i.MX6Q Armadillo2 board HW design,there is
>> + * no 125Mhz clock input from SOC. In order to use RGMII,
>> + * We need enable AR8031 ouput a 125MHz clk from CLK_25M
>> + */
>> +miiphy_write("FEC", phy, MII_MMD_ACCESS_CTRL_REG, 0x7);
>> +miiphy_write("FEC", phy, MII_MMD_ACCESS_ADDR_DATA_REG,
>0x8016);
>> +miiphy_write("FEC", phy, MII_MMD_ACCESS_CTRL_REG, 0x4007);
>> +miiphy_read("FEC", phy, MII_MMD_ACCESS_ADDR_DATA_REG, &val);
>> +val &= 0xffe3;
>> +val |= 0x18;
>> +miiphy_write("FEC", phy, MII_MMD_ACCESS_ADDR_DATA_REG, val);
>> +
>> +/* For the RGMII phy, we need enable tx clock delay */
>> +miiphy_write("FEC", phy, 0x1d, 0x5);
>
>You define MII_DBG_PORT_REG, but then you do not use it.
>
>> +miiphy_read("FEC", phy, 0x1e, &val);
>
>The same here for MII_DBG_PORT2_REG. Can you also defines some
>constants for the value you are setting (tx clock delay, etc.).

Yeah,  thanks for it. I will use MII_DBG_PORT_REG and MII_DBG_PORT2_REG.

>
>> diff --git a/include/configs/mx6qarm2.h b/include/configs/mx6qarm2.h
>> index a7b363d..3a30679 100644
>> --- a/include/configs/mx6qarm2.h
>> +++ b/include/configs/mx6qarm2.h
>> @@ -56,6 +56,17 @@
>>  #define CONFIG_CMD_FAT
>>  #define CONFIG_DOS_PARTITION
>>
>> +#define CONFIG_CMD_PING
>> +#define CONFIG_CMD_DHCP
>> +#define CONFIG_CMD_MII
>> +#define CONFIG_CMD_NET
>> +#define CONFIG_FEC_MXC
>> +#define CONFIG_MII
>> +#define IMX_FEC_BASEENET_BASE_ADDR
>> +#define CONFIG_FEC_XCV_TYPE RGMII
>> +#define CONFIG_ETHPRIME "FEC"
>
>I have not thought this is needed. I see only one controller.

Yes, I think we can remove it.

Best regards,
Jason Liu

>
>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-0 Fax: +49-8142-66989-80  Email: off...@denx.de
>=
>
>___
>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] fsl_esdhc.c bug

2011-12-16 Thread Fabio Estevam
Hi Jim,

On Fri, Dec 16, 2011 at 11:48 AM, Jim Lentz  wrote:
> All,
>
> There is a bug rendering SDCard support useless on Freescale esdhc
> controller.

Which Freescale processor do you use?

Please describe in details the problem you see, how to reproduce it,
the U-boot version
that you use, etc.

Regards,

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


Re: [U-Boot] fsl_esdhc.c bug

2011-12-16 Thread Graeme Russ
Hi Jim

On Dec 17, 2011 1:11 AM, "Jim Lentz"  wrote:
>
> All,
>
> There is a bug rendering SDCard support useless on Freescale esdhc
controller.
>
> File drivers/mmc/fsl_esdhc.c, function esdhc_pio_read_write
>
> *change: *
>
> struct fsl_esdhc *regs = mmc->priv;
>
> *to:*
>
> struct fsl_esdhc_cfg *cfg = (struct fsl_esdhc_cfg *)mmc->priv;
> volatile struct fsl_esdhc *regs = (struct fsl_esdhc *)cfg->esdhc_base;

use of volatile is highly likely to be wrong

>
> How do I/we get this into the mainstream?

First read:

http://www.denx.de/wiki/U-Boot/CodingStyle

And:

http://www.denx.de/wiki/U-Boot/Patches

>
> I cloned the repository, and have it fixed. First time using git, and
trying to contribute to OpenSource too.

git format-patch and git send-email

Regards,

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


[U-Boot] fsl_esdhc.c bug

2011-12-16 Thread Jim Lentz

All,

There is a bug rendering SDCard support useless on Freescale esdhc 
controller.


File drivers/mmc/fsl_esdhc.c, function esdhc_pio_read_write

*change: *

struct fsl_esdhc *regs = mmc->priv;

*to:*

struct fsl_esdhc_cfg *cfg = (struct fsl_esdhc_cfg *)mmc->priv;
volatile struct fsl_esdhc *regs = (struct fsl_esdhc *)cfg->esdhc_base;

How do I/we get this into the mainstream?

I cloned the repository, and have it fixed. First time using git, and 
trying to contribute to OpenSource too.


Regards,

Jim



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


[U-Boot] arm, da850: Question about start point

2011-12-16 Thread Gabriele Filosofi
Hi all,

I'm new to this mailing-list and to u-boot.
I've to port the TI SDK_5.02 to a LogicPD_SOM_AM1808 -based application board.
The SDK_5.02 is based on PSP_03.21.00.04, whose u-boot was developed on git 
u-boot 2010.12

The question is

What's the better, to start from SDK's u-boot or from git u-boot 2010.12  ?

Thanks a lot,
Gabriele
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] add missing space

2011-12-16 Thread Anatolij Gustschin
Hi Luka,

On Fri, 16 Dec 2011 00:32:15 +0100
Luka Perkov  wrote:

> Cosmetic patch for first U-Boot line that gets printed.
> 
> Signed-off-by: Luka Perkov 
> ---
> diff --git a/include/version.h b/include/version.h
> index c908bd3..ac5a39a 100644
> --- a/include/version.h
> +++ b/include/version.h
> @@ -35,7 +35,7 @@
>  #endif
>  
>  #define U_BOOT_VERSION_STRING U_BOOT_VERSION " (" U_BOOT_DATE " - " \
> - U_BOOT_TIME ")" CONFIG_IDENT_STRING
> + U_BOOT_TIME ") " CONFIG_IDENT_STRING

This change is not needed I think. Most boards defining
CONFIG_IDENT_STRING use either a string starting with new line or
strings like " something". So this patch will deface version string.
Your CONFIG_IDENT_STRING should be fixed instead.

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


Re: [U-Boot] [PATCH 3/3] i.mx6q: arm2: Add the enet function support

2011-12-16 Thread Stefano Babic
On 13/12/2011 14:44, Jason Liu wrote:
> This enable the network function on the i.mx6q armadillo2
> board(arm2), thus we can use tftp to load image from network.
> 
> Cc: Stefano Babic 
> Signed-off-by: Jason Liu 
> Tested-by: Dirk Behme 
> ---
>  board/freescale/mx6qarm2/mx6qarm2.c |   90 
> +++
>  include/configs/mx6qarm2.h  |   13 -
>  2 files changed, 101 insertions(+), 2 deletions(-)
> 

Hi Jason,

only a couple of minor issues.

> +
>  #ifdef CONFIG_FSL_ESDHC
>  struct fsl_esdhc_cfg usdhc_cfg[2] = {
>   {USDHC3_BASE_ADDR, 1},
> @@ -132,9 +162,69 @@ int board_mmc_init(bd_t *bis)
>  }
>  #endif
>  
> +#define MII_MMD_ACCESS_CTRL_REG  0xd
> +#define MII_MMD_ACCESS_ADDR_DATA_REG 0xe
> +#define MII_DBG_PORT_REG 0x1d
> +#define MII_DBG_PORT2_REG0x1e
> +
> +int fecmxc_mii_postcall(int phy)
> +{
> + unsigned short val;
> +
> + /*
> +  * Due to the i.MX6Q Armadillo2 board HW design,there is
> +  * no 125Mhz clock input from SOC. In order to use RGMII,
> +  * We need enable AR8031 ouput a 125MHz clk from CLK_25M
> +  */
> + miiphy_write("FEC", phy, MII_MMD_ACCESS_CTRL_REG, 0x7);
> + miiphy_write("FEC", phy, MII_MMD_ACCESS_ADDR_DATA_REG, 0x8016);
> + miiphy_write("FEC", phy, MII_MMD_ACCESS_CTRL_REG, 0x4007);
> + miiphy_read("FEC", phy, MII_MMD_ACCESS_ADDR_DATA_REG, &val);
> + val &= 0xffe3;
> + val |= 0x18;
> + miiphy_write("FEC", phy, MII_MMD_ACCESS_ADDR_DATA_REG, val);
> +
> + /* For the RGMII phy, we need enable tx clock delay */
> + miiphy_write("FEC", phy, 0x1d, 0x5);

You define MII_DBG_PORT_REG, but then you do not use it.

> + miiphy_read("FEC", phy, 0x1e, &val);

The same here for MII_DBG_PORT2_REG. Can you also defines some constants
for the value you are setting (tx clock delay, etc.).

> diff --git a/include/configs/mx6qarm2.h b/include/configs/mx6qarm2.h
> index a7b363d..3a30679 100644
> --- a/include/configs/mx6qarm2.h
> +++ b/include/configs/mx6qarm2.h
> @@ -56,6 +56,17 @@
>  #define CONFIG_CMD_FAT
>  #define CONFIG_DOS_PARTITION
>  
> +#define CONFIG_CMD_PING
> +#define CONFIG_CMD_DHCP
> +#define CONFIG_CMD_MII
> +#define CONFIG_CMD_NET
> +#define  CONFIG_FEC_MXC
> +#define  CONFIG_MII
> +#define IMX_FEC_BASE ENET_BASE_ADDR
> +#define  CONFIG_FEC_XCV_TYPE RGMII
> +#define CONFIG_ETHPRIME  "FEC"

I have not thought this is needed. I see only one controller.

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-0 Fax: +49-8142-66989-80  Email: off...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 2/3] fec: add the i.mx6q enet driver support

2011-12-16 Thread Stefano Babic
On 13/12/2011 14:44, Jason Liu wrote:
> Cc: Stefano Babic 
> Signed-off-by: Jason Liu 
> ---
>  drivers/net/fec_mxc.c |   10 ++
>  drivers/net/fec_mxc.h |7 ++-
>  2 files changed, 16 insertions(+), 1 deletions(-)
> 

Acked-by : Stefano Babic 

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-0 Fax: +49-8142-66989-80  Email: off...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 1/3] i.mx: i.mx6q: Add the enet clock function

2011-12-16 Thread Stefano Babic
On 13/12/2011 14:44, Jason Liu wrote:
> Cc: Stefano Babic 
> Signed-off-by: Jason Liu 
> ---
>  arch/arm/cpu/armv7/mx6/clock.c |5 +
>  1 files changed, 5 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/cpu/armv7/mx6/clock.c b/arch/arm/cpu/armv7/mx6/clock.c
> index b143535..fa3a124 100644
> --- a/arch/arm/cpu/armv7/mx6/clock.c
> +++ b/arch/arm/cpu/armv7/mx6/clock.c
> @@ -285,6 +285,11 @@ u32 imx_get_uartclk(void)
>   return get_uart_clk();
>  }
>  
> +u32 imx_get_fecclk(void)
> +{
> + return decode_pll(PLL_ENET, CONFIG_SYS_MX6_HCLK);
> +}
> +
>  unsigned int mxc_get_clock(enum mxc_clock clk)
>  {
>   switch (clk) {

Acked-by: Stefano Babic 

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-0 Fax: +49-8142-66989-80  Email: off...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2 1/3] mx28: Let imx_get_mac_from_fuse be common for mx28

2011-12-16 Thread Marek Vasut
> On 16/12/2011 11:39, Marek Vasut wrote:
> >> Hi Marek,
> > 
> > Hi Stefano,
> > 
> > DISCLAIMER: I'm terribly tired today, had early class.
> 
> ok, I understand..;-)
> 
> > You disable fuses and use ethaddr. Why do we need them? We don't, but the
> > hardware is in the CPU and someone might use it so let's support it.
> 
> Exactly - see also othe IMX SOCs.
> 
> >> In a standard way, the environment must be adapted for each board to
> >> store the MAC address in the ethaddr variable. The reason to get the MAC
> >> directly from the hardware is that it is not required a specific initial
> >> setup for each board, and that simplifies the production and the
> >> delivery of the boards.
> > 
> > Sure, but the OCOTP capacity here is limited. But there was approach from
> > Fabio/me how to make the OCOTP good enough for two NICs even.
> 
> And this is nice.
> 
> > * The idea is to let user configure the top 2 bytes per-device (which is
> > the most likely case).
> 
> This is exactly what I meant.
> 
> > * Introduce mac_modify(int fec, char *mac) function, which will be called
> > from imx_get_mac_from_fuse()
> > * The function will adjust the MAC, for example by setting top two bytes
> > to preconfigured data, bottom four bytes from OCOTP and the last bit of
> > the MAC from "int fec", which is 0 for FEC0 and 1 for FEC1. This should
> > be sufficient for most people.
> 
> Exactly !
> 
> > * The function will be weak so it can be overridden to your hearts
> > content.
> 
> Right !
> 
> Stefano

And it was mostly Fabio's idea I'd say ;-)

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


Re: [U-Boot] [PATCH v2 1/3] mx28: Let imx_get_mac_from_fuse be common for mx28

2011-12-16 Thread Stefano Babic
On 16/12/2011 11:39, Marek Vasut wrote:

>>
>> Hi Marek,
> 
> Hi Stefano,
> 
> DISCLAIMER: I'm terribly tired today, had early class.

ok, I understand..;-)

> 
> You disable fuses and use ethaddr. Why do we need them? We don't, but the 
> hardware is in the CPU and someone might use it so let's support it.

Exactly - see also othe IMX SOCs.

>> In a standard way, the environment must be adapted for each board to
>> store the MAC address in the ethaddr variable. The reason to get the MAC
>> directly from the hardware is that it is not required a specific initial
>> setup for each board, and that simplifies the production and the
>> delivery of the boards.
> 
> Sure, but the OCOTP capacity here is limited. But there was approach from 
> Fabio/me how to make the OCOTP good enough for two NICs even.

And this is nice.

> * The idea is to let user configure the top 2 bytes per-device (which is the 
> most likely case).

This is exactly what I meant.

> * Introduce mac_modify(int fec, char *mac) function, which will be called 
> from 
> imx_get_mac_from_fuse()
> * The function will adjust the MAC, for example by setting top two bytes to 
> preconfigured data, bottom four bytes from OCOTP and the last bit of the MAC 
> from "int fec", which is 0 for FEC0 and 1 for FEC1. This should be sufficient 
> for most people.

Exactly !


> * The function will be weak so it can be overridden to your hearts content.

Right !

Stefano


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


Re: [U-Boot] [PATCH v2 1/3] mx28: Let imx_get_mac_from_fuse be common for mx28

2011-12-16 Thread Marek Vasut
> On 16/12/2011 10:53, Marek Vasut wrote:
> >> On 15/12/2011 18:22, Marek Vasut wrote:
>  Let imx_get_mac_from_fuse function be a common function, so that other
>  mx28 boards can reuse it.
>  
>  Signed-off-by: Fabio Estevam 
> 
> Hi Marek,

Hi Stefano,

DISCLAIMER: I'm terribly tired today, had early class.

> 
> >>> Be careful here. 0x00 0x04 prefix might not be correct for all cases!
> >> 
> >> But to be honest, it seems they are correct for the MX28EVK and not for
> >> the M28EVK. The M28EVK and the M28 module are delivered with their own
> >> MAC address that does not belong to the Freescale's range.
> >> 
> >> As far as I can see, the M28EVK starts with a Freescale's MAC, and then
> >> the DENX MAC address (Vendor ID C0:E5:4E) is set later to the correct
> >> value when Linux boots.
> > 
> > It's actually set even in uboot by ethaddr and eth1addr. This is the
> > default behaviour.
> 
> This means ethaddr overwrites the values read from fuses - why do we
> need the fuses ?

You disable fuses and use ethaddr. Why do we need them? We don't, but the 
hardware is in the CPU and someone might use it so let's support it.

> 
> >> I can understand this feature in the SOC as a way to set the LSBs of the
> >> MAC address, but leaving to the customer a way to set its own vendor id,
> >> if he bought it.
> >> 
> >> What about to add a weak function (board_set_mac_vendor, maybe ?) that
> >> can be called at this point to set the vendor id ? The default behavior
> >> should be to set the Freescale's vendor id.
> > 
> > ethaddr and eth1addr is insufficient?
> 
> In a standard way, the environment must be adapted for each board to
> store the MAC address in the ethaddr variable. The reason to get the MAC
> directly from the hardware is that it is not required a specific initial
> setup for each board, and that simplifies the production and the
> delivery of the boards.

Sure, but the OCOTP capacity here is limited. But there was approach from 
Fabio/me how to make the OCOTP good enough for two NICs even.

* The idea is to let user configure the top 2 bytes per-device (which is the 
most likely case).
* Introduce mac_modify(int fec, char *mac) function, which will be called from 
imx_get_mac_from_fuse()
* The function will adjust the MAC, for example by setting top two bytes to 
preconfigured data, bottom four bytes from OCOTP and the last bit of the MAC 
from "int fec", which is 0 for FEC0 and 1 for FEC1. This should be sufficient 
for most people.
* The function will be weak so it can be overridden to your hearts content.

> 
> If you rely on ethaddr, than we do not need imx_get_mac_from_fuse() at
> all, and the MAC can be set to zero, because in this case the ethaddr
> value is used - but we lose the feature.
> 
> The reason why imx_get_mac_from_fuse was introduce is to have an
> automatic mechanism to set up the MAC without any customization.
> 
> Best regards,
> Stefano Babic

Cheers!

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


Re: [U-Boot] [PATCH v2 1/3] mx28: Let imx_get_mac_from_fuse be common for mx28

2011-12-16 Thread Stefano Babic
On 16/12/2011 10:53, Marek Vasut wrote:
>> On 15/12/2011 18:22, Marek Vasut wrote:
 Let imx_get_mac_from_fuse function be a common function, so that other
 mx28 boards can reuse it.

 Signed-off-by: Fabio Estevam 
>>

Hi Marek,


>>> Be careful here. 0x00 0x04 prefix might not be correct for all cases!
>>
>> But to be honest, it seems they are correct for the MX28EVK and not for
>> the M28EVK. The M28EVK and the M28 module are delivered with their own
>> MAC address that does not belong to the Freescale's range.
>>
>> As far as I can see, the M28EVK starts with a Freescale's MAC, and then
>> the DENX MAC address (Vendor ID C0:E5:4E) is set later to the correct
>> value when Linux boots.
> 
> It's actually set even in uboot by ethaddr and eth1addr. This is the default 
> behaviour.

This means ethaddr overwrites the values read from fuses - why do we
need the fuses ?

> 
>>
>> I can understand this feature in the SOC as a way to set the LSBs of the
>> MAC address, but leaving to the customer a way to set its own vendor id,
>> if he bought it.
>>
>> What about to add a weak function (board_set_mac_vendor, maybe ?) that
>> can be called at this point to set the vendor id ? The default behavior
>> should be to set the Freescale's vendor id.
> 
> ethaddr and eth1addr is insufficient?

In a standard way, the environment must be adapted for each board to
store the MAC address in the ethaddr variable. The reason to get the MAC
directly from the hardware is that it is not required a specific initial
setup for each board, and that simplifies the production and the
delivery of the boards.

If you rely on ethaddr, than we do not need imx_get_mac_from_fuse() at
all, and the MAC can be set to zero, because in this case the ethaddr
value is used - but we lose the feature.

The reason why imx_get_mac_from_fuse was introduce is to have an
automatic mechanism to set up the MAC without any customization.

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-0 Fax: +49-8142-66989-80  Email: off...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 0/7] CHECKPATCH: Cleanup LCD logo files

2011-12-16 Thread Marek Vasut
> On Thursday 15 December 2011 08:45:48 Marek Vasut wrote:
> > This series fixes the logo files by aligning them to 8 bytes per line and
> > fixing subsequent CHECKPATCH issues.
> 
> same comment as fpgadata.c ... would make more sense to find/update the
> tool creating these files rather than hand modifying things that are
> clearly generated output and would get blown away by subsequent updates to
> the source material (i.e. image).
> -mike

See my previous mail

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


Re: [U-Boot] [PATCH 00/18 V2] CHECKPATCH: fpgadata.c cleanup

2011-12-16 Thread Marek Vasut
> On Thursday 15 December 2011 08:26:41 Marek Vasut wrote:
> > First of the CHECKPATCH series of patches with per-file checkpatch fixes.
> > 
> > This series fixes all files fpgadata.c, which contains PPC FPGA
> > firmwares. There are no functional changes, only CHECKPATCH fixes.
> 
> i don't really see any point in touching the fpgadata.c files.  they're
> clearly generated files and not meant to be read at all let alone modified
> after the fact ...
> 
> of course, i'd wonder what created these in the first place, and apply any
> style tastes to that tool and then regenerate the result ...
> -mike

Well when the person updates these, he will hit a problem and fix his tool. 
Though last update of these is 3 years ago (maybe four). Most of them date back 
to 2003 though.

The reason is to make it all checkpatch clean.

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


Re: [U-Boot] [PATCH v2 1/3] mx28: Let imx_get_mac_from_fuse be common for mx28

2011-12-16 Thread Marek Vasut
> On 15/12/2011 18:22, Marek Vasut wrote:
> >> Let imx_get_mac_from_fuse function be a common function, so that other
> >> mx28 boards can reuse it.
> >> 
> >> Signed-off-by: Fabio Estevam 
> 
> Hi Marek,

Hi Stefano,

> 
> >> +  writel(OCOTP_CTRL_RD_BANK_OPEN, &ocotp_regs->hw_ocotp_ctrl_set);
> >> +
> >> +  if (mx28_wait_mask_clr(&ocotp_regs->hw_ocotp_ctrl_reg,
> >> OCOTP_CTRL_BUSY, + MXS_OCOTP_MAX_TIMEOUT)) {
> >> +  puts("MXS FEC: Can't get MAC from OCOTP\n");
> >> +  return;
> >> +  }
> >> +
> >> +  data = readl(&ocotp_regs->hw_ocotp_cust0);
> >> +
> >> +  mac[0] = 0x00;
> >> +  mac[1] = 0x04;
> > 
> > Be careful here. 0x00 0x04 prefix might not be correct for all cases!
> 
> But to be honest, it seems they are correct for the MX28EVK and not for
> the M28EVK. The M28EVK and the M28 module are delivered with their own
> MAC address that does not belong to the Freescale's range.
> 
> As far as I can see, the M28EVK starts with a Freescale's MAC, and then
> the DENX MAC address (Vendor ID C0:E5:4E) is set later to the correct
> value when Linux boots.

It's actually set even in uboot by ethaddr and eth1addr. This is the default 
behaviour.

> 
> I can understand this feature in the SOC as a way to set the LSBs of the
> MAC address, but leaving to the customer a way to set its own vendor id,
> if he bought it.
> 
> What about to add a weak function (board_set_mac_vendor, maybe ?) that
> can be called at this point to set the vendor id ? The default behavior
> should be to set the Freescale's vendor id.

ethaddr and eth1addr is insufficient?

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


Re: [U-Boot] [PATCH v5 3/3] mx28evk: Add initial support for MX28EVK board

2011-12-16 Thread Marek Vasut
> Add initial support for Freescale MX28EVK board.
> 
> Tested boot via SD card and by loading a kernel via TFTP through
> the FEC interface.
> 
> Signed-off-by: Fabio Estevam 
> ---
> - For correct operation of saving environment variables into the SD card,
> the following patch is needed:
> http://lists.denx.de/pipermail/u-boot/2011-November/111448.html
> 
> Changes since v4:
> - No changes
> Changes since v3:
> - Fix Copyright in mx28evk.h
> - Call mx28_dram_init from dram_init
> Changes since v2:
> - Generate the patch again due to error in applying unrelated changes
> Changes since v1:
> - Read the MAC from fuses
> - Use tabs instead of space in u-boot.bd
> - Use puts instead of print
> - Factor out mac reading function
> - Factor out ddr size calculation function
> - Use GENERATED_GBL_DATA_SIZE
> - Protect CONFIG_ENV_IS_IN_MMC
>  MAINTAINERS   |1 +
>  board/freescale/mx28evk/Makefile  |   49 ++
>  board/freescale/mx28evk/iomux.c   |  138 +
>  board/freescale/mx28evk/mx28evk.c |  170
> +++ board/freescale/mx28evk/u-boot.bd |  
> 14 +++
>  boards.cfg|1 +
>  include/configs/mx28evk.h |  176
> + 7 files changed, 549 insertions(+),
> 0 deletions(-)
>  create mode 100644 board/freescale/mx28evk/Makefile
>  create mode 100644 board/freescale/mx28evk/iomux.c
>  create mode 100644 board/freescale/mx28evk/mx28evk.c
>  create mode 100644 board/freescale/mx28evk/u-boot.bd
>  create mode 100644 include/configs/mx28evk.h
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index a56ca10..72e1089 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -639,6 +639,7 @@ Kristoffer Ericson 
>  Fabio Estevam 
> 
>   mx25pdk i.MX25
> + mx28evk i.MX28
>   mx31pdk i.MX31
>   mx53ard i.MX53
>   mx53smd i.MX53
> diff --git a/board/freescale/mx28evk/Makefile
> b/board/freescale/mx28evk/Makefile new file mode 100644
> index 000..7459107
> --- /dev/null
> +++ b/board/freescale/mx28evk/Makefile
> @@ -0,0 +1,49 @@
> +#
> +# (C) Copyright 2000-2006
> +# 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
> +
> +LIB  = $(obj)lib$(BOARD).o
> +
> +ifndef   CONFIG_SPL_BUILD
> +COBJS:= mx28evk.o
> +else
> +COBJS:= iomux.o
> +endif
> +
> +SRCS := $(COBJS:.o=.c)
> +OBJS := $(addprefix $(obj),$(COBJS))
> +
> +$(LIB):  $(obj).depend $(OBJS)
> + $(call cmd_link_o_target, $(OBJS))
> +
> +all: $(ALL)
> +
> +#
> +
> +# defines $(obj).depend target
> +include $(SRCTREE)/rules.mk
> +
> +sinclude $(obj).depend
> +
> +#
> diff --git a/board/freescale/mx28evk/iomux.c
> b/board/freescale/mx28evk/iomux.c new file mode 100644
> index 000..904e3f3
> --- /dev/null
> +++ b/board/freescale/mx28evk/iomux.c
> @@ -0,0 +1,138 @@
> +/*
> + * Freescale MX28EVK IOMUX setup
> + *
> + * Copyright (C) 2011 Marek Vasut 
> + * on behalf of DENX Software Engineering GmbH
> + *
> + * 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.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define  MUX_CONFIG_SSP0 (MXS_PAD_3V3 | MXS_PAD_8MA | MXS_PAD_PULLUP)
> +#define  MUX_CONFIG_ENET (MXS_PAD_3V3 | MXS_PAD_8MA | MXS_PAD_PULLUP)
> +#define  MUX_CONFIG_EMI  (MXS_PAD_3V3 | MXS_PAD_12MA | MXS_PAD_NOPULL)
> +
> +const iomux_cfg_t 

Re: [U-Boot] [PATCH v5 1/3] mx28: Let imx_get_mac_from_fuse be common for mx28

2011-12-16 Thread Marek Vasut
> Let imx_get_mac_from_fuse function be a common function, so that other
> mx28 boards can reuse it.
> 
> Signed-off-by: Fabio Estevam 
> ---
> Changes since v4:
> - No changes
> Change since v3:
> - Add a note about the first two MAC addresses being from Freescale vendor.

What changes are in V5? Also, mark resubmissions with "RESEND" or "V3 RESEND" 
or 
something ... like "[PATCH V3 RESEND]" ... though you don't need to resend 
stuff 
here.

> 
>  arch/arm/cpu/arm926ejs/mx28/mx28.c |   41
>  arch/arm/include/asm/arch-mx28/sys_proto.h | 
>   2 +
>  board/denx/m28evk/m28evk.c |   35 ---
>  3 files changed, 43 insertions(+), 35 deletions(-)
> 
> diff --git a/arch/arm/cpu/arm926ejs/mx28/mx28.c
> b/arch/arm/cpu/arm926ejs/mx28/mx28.c index 088c019..d82bb01 100644
> --- a/arch/arm/cpu/arm926ejs/mx28/mx28.c
> +++ b/arch/arm/cpu/arm926ejs/mx28/mx28.c
> @@ -214,6 +214,47 @@ int cpu_eth_init(bd_t *bis)
>  }
>  #endif
> 
> +#ifdef   CONFIG_MX28_FEC_MAC_IN_OCOTP
> +
> +#define  MXS_OCOTP_MAX_TIMEOUT   100
> +void imx_get_mac_from_fuse(char *mac)
> +{
> + struct mx28_ocotp_regs *ocotp_regs =
> + (struct mx28_ocotp_regs *)MXS_OCOTP_BASE;
> + uint32_t data;
> +
> + memset(mac, 0, 6);
> +
> + writel(OCOTP_CTRL_RD_BANK_OPEN, &ocotp_regs->hw_ocotp_ctrl_set);
> +
> + if (mx28_wait_mask_clr(&ocotp_regs->hw_ocotp_ctrl_reg, OCOTP_CTRL_BUSY,
> + MXS_OCOTP_MAX_TIMEOUT)) {
> + puts("MXS FEC: Can't get MAC from OCOTP\n");
> + return;
> + }
> +
> + data = readl(&ocotp_regs->hw_ocotp_cust0);
> +

/* Freescale MAC vendor prefix: 00:04:xx:xx:xx:xx */ ... or something

It's shorter and it should be above the code.

> + mac[0] = 0x00;
> + mac[1] = 0x04;
> + /*
> +  * Note:
> +  *
> +  * These first two bytes are Freescale's vendor MAC prefix.
> +  *
> +  */
> + mac[2] = (data >> 24) & 0xff;
> + mac[3] = (data >> 16) & 0xff;
> + mac[4] = (data >> 8) & 0xff;
> + mac[5] = data & 0xff;
> +}
> +#else
> +void imx_get_mac_from_fuse(char *mac)
> +{
> + memset(mac, 0, 6);
> +}
> +#endif
> +
>  U_BOOT_CMD(
>   clocks, CONFIG_SYS_MAXARGS, 1, do_mx28_showclocks,
>   "display clocks",
> diff --git a/arch/arm/include/asm/arch-mx28/sys_proto.h
> b/arch/arm/include/asm/arch-mx28/sys_proto.h index be1f7db..cf5ab16 100644
> --- a/arch/arm/include/asm/arch-mx28/sys_proto.h
> +++ b/arch/arm/include/asm/arch-mx28/sys_proto.h
> @@ -35,4 +35,6 @@ void mx28_common_spl_init(const iomux_cfg_t *iomux_setup,
>   const unsigned int iomux_size);
>  #endif
> 
> +void imx_get_mac_from_fuse(char *mac);
> +
>  #endif   /* __MX28_H__ */
> diff --git a/board/denx/m28evk/m28evk.c b/board/denx/m28evk/m28evk.c
> index fcee046..005446a 100644
> --- a/board/denx/m28evk/m28evk.c
> +++ b/board/denx/m28evk/m28evk.c
> @@ -178,39 +178,4 @@ int board_eth_init(bd_t *bis)
>   return ret;
>  }
> 
> -#ifdef   CONFIG_M28_FEC_MAC_IN_OCOTP
> -
> -#define  MXS_OCOTP_MAX_TIMEOUT   100
> -void imx_get_mac_from_fuse(char *mac)
> -{
> - struct mx28_ocotp_regs *ocotp_regs =
> - (struct mx28_ocotp_regs *)MXS_OCOTP_BASE;
> - uint32_t data;
> -
> - memset(mac, 0, 6);
> -
> - writel(OCOTP_CTRL_RD_BANK_OPEN, &ocotp_regs->hw_ocotp_ctrl_set);
> -
> - if (mx28_wait_mask_clr(&ocotp_regs->hw_ocotp_ctrl_reg, OCOTP_CTRL_BUSY,
> - MXS_OCOTP_MAX_TIMEOUT)) {
> - printf("MXS FEC: Can't get MAC from OCOTP\n");
> - return;
> - }
> -
> - data = readl(&ocotp_regs->hw_ocotp_cust0);
> -
> - mac[0] = 0x00;
> - mac[1] = 0x04;
> - mac[2] = (data >> 24) & 0xff;
> - mac[3] = (data >> 16) & 0xff;
> - mac[4] = (data >> 8) & 0xff;
> - mac[5] = data & 0xff;
> -}
> -#else
> -void imx_get_mac_from_fuse(char *mac)
> -{
> - memset(mac, 0, 6);
> -}
> -#endif
> -
>  #endif

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


Re: [U-Boot] __mmc_get_env_addr() is not being called?

2011-12-16 Thread Stefano Babic
On 16/12/2011 10:33, Fabio Estevam wrote:

> 
> The weak function was introduced by this commit:
> http://git.denx.de/?p=u-boot.git;a=commitdiff;h=97039ab98c551c7860bc0977d684ef686159e0d7
> 
> which breaks non CONFIG_FSL_ESDHC users.

Ok, I see - the patch is more related to Freescale SOCs as to the MMC,
and it is sometimes unknown who whould pick it up.

Andy, not CONFIG_FSL_ESDHC means IMX users - if you do not complain, I
merge it into u-boot-imx.

Thanks,
Stefano

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


  1   2   >