[U-Boot] [PATCH v2 2/3] am335x-evm: add support for BeagleBone Black DT name

2013-02-12 Thread Koen Kooi
Signed-off-by: Koen Kooi 
---
 include/configs/am335x_evm.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
index 2190a7d..951422c 100644
--- a/include/configs/am335x_evm.h
+++ b/include/configs/am335x_evm.h
@@ -86,6 +86,8 @@
"findfdt="\
"if test $board_name = A335BONE; then " \
"setenv fdtfile am335x-bone.dtb; fi; " \
+   "if test $board_name = A335BNLT; then " \
+   "setenv fdtfile am335x-bonelt.dtb; fi; " \
"if test $board_name = A33515BB; then " \
"setenv fdtfile am335x-evm.dtb; fi; " \
"if test $board_name = A335X_SK; then " \
-- 
1.8.1.2

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


Re: [U-Boot] [PATCH v2] build: imx: Fix 'u-boot.imx' build without full OBJTREE reference

2013-02-12 Thread Otavio Salvador
On Tue, Feb 12, 2013 at 12:01 PM, Benoît Thébaudeau
 wrote:
> Dear Otavio, Marek,
>
> On Monday, February 11, 2013 5:55:17 PM, Marek Vasut wrote:
>> Dear Otavio Salvador,
>>
>> > When calling 'make u-boot.imx' the build were failing as it were
>> > expecting the full path for the file; this regression has been
>> > included by commit 71a988a (imximage.cfg: run files through C
>> > preprocessor).
>> >
>> > The direct references for u-boot.imx were replaced by $(obj) as
>> > config.mk handles the proper setting of it making it set to $(OBJTREE)
>> > when required.
>> >
>> > The build has been test using:
>> >
>> >  - ./MAKEALL -s mx5 -s mx6
>> >  - make u-boot.imx
>> >  - make O=/tmp/build
>>
>> BUILD_DIR=/tmp/xyz MAKEALL please.
>
> Once you're confident with this patch, do you mind if I integrate it as is in 
> my
> MXC NAND + SPL series in order to avoid merge conflicts (unless it is applied
> before)?

Alright; It did the test Marek has requested and it works fine. I
think this should go to imx/master as it fixes a regression.

-- 
Otavio Salvador O.S. Systems
E-mail: ota...@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854  http://projetos.ossystems.com.br
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [U-boot]-gdwarf option

2013-02-12 Thread Tom Rini
On Mon, Feb 11, 2013 at 01:43:32PM -0600, Scott Wood wrote:

> On 02/07/2013 02:01:05 AM, tiger...@viatech.com.cn wrote:
> >Hi, experts:
> >I have a JTAG debugger.
> >Its manual suggested user should add "-gdwarf-2" option in the arm gcc
> >compiler.
> >Because it could produce debugging information.
> >
> >But I searched the whole uboot source package, could not find
> >"-gdwarf-2" option in config.mk or other files.
> >
> >Why?
> 
> I think it's already the default with most toolchains.  Do you see
> any difference in the output when supplying that flag?

Indeed.  For most common values of gcc versions, using -g will pick the
"best" choice for debug information and this will be DWARF2 information
already.  There is no need to specify -gdwarf-2 (or similar).

-- 
Tom


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


Re: [U-Boot] [PATCH] Allow OMAP2 boards to setup GPMC chipselects.

2013-02-12 Thread Tom Rini
On Mon, Feb 11, 2013 at 04:29:03PM +, Mark Jackson wrote:

> Expose the enable_gpmc_cs_config() function so OMAP2 boards can register
> GPMC chipselects.
> 
> Signed-off-by: Mark Jackson 
> ---
>  arch/arm/include/asm/arch-am33xx/sys_proto.h |2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/arm/include/asm/arch-am33xx/sys_proto.h 
> b/arch/arm/include/asm/arch-am33xx/sys_proto.h
> index 588d8de..97ab60d 100644
> --- a/arch/arm/include/asm/arch-am33xx/sys_proto.h
> +++ b/arch/arm/include/asm/arch-am33xx/sys_proto.h
> @@ -35,5 +35,7 @@ void ddr_pll_config(unsigned int ddrpll_M);
>   void sdelay(unsigned long);
>  void gpmc_init(void);
> +void enable_gpmc_cs_config(const u32 *gpmc_config, struct gpmc_cs *cs, u32 
> base,
> + u32 size);
>  void omap_nand_switch_ecc(int);
>  #endif

Can you please correct the description?  You're exposing the function
for am33xx not omap2.  Otherwise fine with me, and I assume you need
this on a custom board (aside: the function already exists/is used in
arch/arm/cpu/armv7/am33xx/mem.c).  Are you planning to submit that
support as well?  Thanks!

-- 
Tom


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


Re: [U-Boot] [PATCH v5 1/3] Add README for the "Falcon" mode

2013-02-12 Thread Otavio Salvador
On Tue, Feb 12, 2013 at 6:38 AM, Stefano Babic  wrote:
> Simple howto to add support to a board
> for booting the kernel from SPL ("Falcon" mode).
>
> Signed-off-by: Stefano Babic 
> ---
> Changes in v5:
> - several fixes for the language, rephrasing some unclear parts (Vikram 
> Narayanan)
>
> Changes in v4:
> - fix capitalization, styling, in spl help (Andreas Biessmann)
> - move CONFIG_SPL_OS_BOOT before function in doc (Andreas Biessmann)
>
> Changes in v3:
> - parameter initrd_addr was removed in V2 (Andreas Biessmann)
> - added patch to fix help usage for spl export (Andreas Biessmann)
> - Added empty lines (Otavio Salvador)
> - add a more exhaustive description explaining that
>   spl export does not save into media (Lukasz Majewski).
>
> Changes in v2:
> - spelling, language fixes (Andreas Biessman)
> - rewrite some unclear sentences
> - drop CONFIG_SPL_OS_BOOT_KEY
> - make example with twister more exhaustive
>
>  doc/README.falcon |  169 
> +
>  1 file changed, 169 insertions(+)
>  create mode 100644 doc/README.falcon
>
> diff --git a/doc/README.falcon b/doc/README.falcon
> new file mode 100644
> index 000..72fe04a
> --- /dev/null
> +++ b/doc/README.falcon
> @@ -0,0 +1,169 @@
> +U-Boot Falcon Mode
> +
> +
> +Introduction
> +
> +
> +This document provides an overview of how to add support for Falcon Mode
> +to a board.
> +Falcon Mode is introduced to speed up the booting process, allowing
> +to boot a Linux kernel (or whatever image) without a full blown U-Boot.

Add a newline after board or move Falcon Mode to same phrase.

> +Falcon Mode relies on the SPL framework. In fact, to make booting faster,
> +U-Boot is split into two parts: the SPL (Secondary Program Loader) and U-Boot
> +image. In most implementations, SPL is used to start U-Boot when booting from
> +a mass storage, such as NAND or SD-Card. SPL has now support for other media,
> +and can generally be seen as a way to start an image performing the minimum
> +required initialization. SPL mainly initializes the RAM controller, and then
> +copies U-Boot image into the memory.

New line.

> The Falcon Mode extends this way
> +allowing to start the Linux kernel directly from SPL. A new command is added
> +to U-Boot to prepare the parameters that SPL must pass to the kernel, using
> +ATAGS or Device Tree.
> +
> +In usual U-Boot systems, these parameters are generated each time before

"In usual U-Boot systems"

Together with previous phrase and might be clear as: "In normal mode, these ..."

> +loading the kernel, passing to Linux the address in memory where
> +the parameters can be read.
> +With Falcon Mode, this snapshot can be saved into persistent storage and SPL 
> is
> +informed to load it before running the kernel.
> +
> +To boot the kernel, these steps under a Falcon-aware U-Boot are required:
> +
> +1. Boot the board into U-Boot.
> +Use the "spl export" command to generate the kernel parameters area or the 
> DT.
> +U-Boot runs as when it boots the kernel, but stops before passing the control
> +to the kernel.
> +
> +2. Save the prepared snapshot into persistent media.
> +The address where to save it must be configured into board configuration
> +file (CONFIG_CMD_SPL_NAND_OFS for NAND).
> +
> +3. Boot the board into Falcon Mode. SPL will load the kernel and copy
> +the parameters which are saved in the persistent area area to the required 
> address.
> +
> +It is required to implement a custom mechanism to select if SPL loads U-Boot
> +or another image.
> +
> +The value of a GPIO is a simple way to operate the selection, as well as
> +reading a character from the SPL console if CONFIG_SPL_CONSOLE is set.
> +
> +Falcon Mode is generally activated by setting CONFIG_SPL_OS_BOOT. This tells
> +SPL that U-Boot is not the only available image that SPL is able to start.
> +
> +Configuration
> +
> +CONFIG_CMD_SPL Enable the "spl export" command.
> +   The command "spl export" is then available in U-Boot
> +   mode
> +CONFIG_SYS_SPL_ARGS_ADDR   Address in RAM where the parameters must be
> +   copied by SPL.
> +   In most cases, it is  + 0x100
> +
> +CONFIG_SYS_NAND_SPL_KERNEL_OFFSOffset in NAND where the kernel is 
> stored
> +
> +CONFIG_CMD_SPL_NAND_OFSOffset in NAND where the parameters area was 
> saved.
> +
> +CONFIG_CMD_SPL_WRITE_SIZE  Size of the parameters area to be copied
> +
> +CONFIG_SPL_OS_BOOT Activate Falcon Mode.
> +
> +Function that a board must implement
> +
> +
> +void spl_board_prepare_for_linux(void) : optional
> +   Called from SPL before starting the kernel
> +
> +spl_start_uboot() : required
> +   Returns "0" if SPL starts the kernel, "1" if U-Boot
> +   must be started.
> +
> +
> +Using spl command
> +--

Re: [U-Boot] [PATCH 0/5] Add support for using an UBI volume for environment

2013-02-12 Thread Tom Rini
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/11/2013 09:37 PM, Scott Wood wrote:
> On 02/08/2013 02:07:21 PM, Joe Hershberger wrote:
>> NAND is not good at handling absolute addresses to sectors for 
>> storing particular data.  The current implementation of the NAND 
>> env support works around this in several ways such as storing a 
>> pointer to the sector in the OOB of the first sector (interferes 
>> with some CRC) or supporting a range of sectors (which unless it 
>> is huge is not guaranteed to be safe).  None of these options 
>> address wear-leveling concerns or bad block handling.
>> 
>> Accessing the u-boot env from UBI eliminates these concerns. 
>> However, it does require some of the basic settings for finding 
>> the UBI env to be in the default u-boot env.
> 
> The downside is this moves us further away from having an 
> environment available before relocation (e.g. loaded by SPL),
> which is important not just for serial config but also hwconfig,
> which can affect how RAM is set up among other things.
> 
> Maybe the "OOB of first sector" approach could be changed to be 
> more like how bad block tables are allocated, with a special
> marker in the env block's own OOB that we scan for.

There's pluses and minuses to "throw more stuff in UBI".  So long as
it doesn't break the ability to have env pre-relocation (and it
shouldn't, we already support env in a file), is there a problem here?

Or just hoping to encourage other robust methods?

I think somewhere there's a wishlist for UBI in SPL (for Falcon mode),
for example..

- -- 
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRGmf4AAoJENk4IS6UOR1W4IUP/0bcsyrI+ufUPf99ME/bkQq0
NhCP3/DH/CxtXrTzsl4mkPOv/C0ziMmQiGpz58k63ITqSPJL/pAZgVqmy1DwhIB/
u/y2F3IYZTwllw06OykesKd8GlP4+oiQokYDAHywfOzw/SyUI3t4jZCGTR2BOvbt
TWw6XL8Rm7sGi3nWRhFlQt4AfRvdidlzcOFppjrQsf7wS39Ho6ALRs0kSh/pVy7h
MoQcICC/+vRc/qDXV6QKlQ3EHK3+3+/3HKUQiKbsw+hrPJua6Ur8+6PpLS96Qc8F
r7+hnOHS+pPVuoIzOfRBn8+R3LDccPskirFGlT0uHXMpph/nQBohLXFMt0CMe9/9
8CwXyMSckpZdPM+2EeGURqQdJZ/fBL+WJEmke6BUnLdOdw8Ks2PuIGQWonlrsLkq
Q7ZHyqN2RtC9veGadRvKhR8GOZP7bQPLMiIWpThNQQTaSUKKYoUFjlxgcaiLAsoC
grO2S0AIBTQx3D0Vzfrka1shttYBd5vqs85bRt/EZAi5YDMeeSTkc3D/wiZST3bP
q8GNyM6p7QNXMnM0hNgQRZIhw5iStaMohh517h84JN69RkQ4TwRUt8HdJPXnPPHq
F1+gmWLKeJRSSza9uIWsUlU4VTE1vVLo7H3hIq1EigERLdg3Z3g9WirkPuSMYEjX
XuvGODaEQ4wqM6yH1XFQ
=rkT9
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v5 8/8] nand: mxc: Switch NAND SPL to generic SPL

2013-02-12 Thread Stefano Babic
On 12/02/2013 14:45, Benoît Thébaudeau wrote:
> Hi Stefano,
> 

>>
>> I'm also considering to factorize relocate_code to crt0.S. There's not really
>> a
>> good reason for it to be depending on each ARM processor. Any opinion?
> 
> FYI, I will post soon a v6 with a lot of cleanup.

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


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

2013-02-12 Thread Albert ARIBAUD
Hello Tom,

The following changes since commit
3a9d879f6f64585b819af728b53be0a05037fe0d:

  Prepare v2013.01 (2013-01-15 14:47:42 -0700)

are available in the git repository at:

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

for you to fetch changes up to fd8e1c3866578d87ed14a04a59faae341fd415df:

  arm: fix CONFIG_DELAY_ENVIRONMENT to act like it claims in the README
  (2013-02-11 10:35:26 -0700)


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

Allen Martin (13):
  tegra: remove IRDA pinmux synonym
  tegra: fdt: remove clocks nodes
  tegra: fdt: sort dts files
  tegra: fdt: add apbdma node
  fdt: fix dts preprocessor options
  tegra: fdt: add back missing host1x node
  tegra20: fdt: add SPI SFLASH node
  tegra: spi: add fdt support to tegra SPI SFLASH driver
  tegra30: add SBC1 to periph id mapping table
  tegra30: fdt: add SPI SLINK nodes
  tegra: add addresses of SPI SLINK controllers
  tegra: add SPI SLINK driver
  tegra: cardhu: config: enable SPI

Fabio Estevam (4):
  woodburn: Set Write Protection GPIO as input
  mx6qsabre_common: Let mmc partition be board specific
  tools: imximage: Let .name field be more generic
  mxs: Use __weak annotation to simplify code

Javier Martinez Canillas (4):
  OMAP3: use a single board file for IGEP devices
  OMAP3: igep00x0: add boot status GPIO LED
  omap4: allow the use of a plain text env file instead boot scripts
  OMAP3: igep00x0: fix a build warning on IGEP boards

Jeff Lance (1):
  Add DDR3 support for AM335x-EVM (Version 1.5A)

Knut Wohlrab (1):
  mx6qsabreauto: enable USB host interface

Lars Poeschel (3):
  am33xx: add a pulldown macro to pinmux config
  pcm051: Add support for Phytec phyCORE-AM335x
  am335x: display msg when reading MAC from efuse

Lucas Stach (1):
  arm: fix CONFIG_DELAY_ENVIRONMENT to act like it claims in the
README

Marc Dietrich (3):
  tegra: display: add board pinmux
  tegra: enable LCD on PAZ00
  tegra: remove custom TEGRA_DEVICE_SETTINGS for board files

Marek Vasut (14):
  mxs: mmc: Drop unused members from struct mxsmmc_priv
  mxs: ssp: Pull out the SSP bus to regs conversion
  mx23: Add POWER and CLKCTRL register definitions
  mx23: ssp: Fix ssp-regs.h for MX23
  mmc: Limit the number of used SSP ports on MX23
  mxs: Add function to ungate the power block on MX23
  mxs: Linux uses ttyAMA0 as DUART
  mxs: Add MX23 olinuxino board support
  mxs: Boost the memory power supply
  mxs: dma: Fix APBH DMA driver for MX23
  mxs: ssp: Add SSP registers map for MX23
  mxs: mmc: Allow overriding default card detect implementation
  mxs: mmc: Fix the MMC driver for MX23
  mxs: mmc: mx23_olinuxino: Add MMC support

Otavio Salvador (14):
  mxs: clock: Use 'mxs' prefix for methods
  mx23: Add register base addresses
  mx23: Add iomux-mx23.h
  mx23: Add support on print_cpuinfo()
  mx23: Add boot mode description
  mx23: SPL: Add boot mode support
  mx23: SPL: Initialize DDR at 133MHz
  mx23: config: Enable building of u-boot.sb binary
  mx23: config: Enable mxsboot tool for i.MX23 based boards
  mxs: Fix the memory init for MX23
  mxs: Add MX23 quirks into the clock code
  mxs: mmc: Fix MMC reset on iMX23
  mx23_olinuxino: Add default environment
  mx23evk: Add initial board support

Rob Herring (2):
  ARM: add wfi assembly macro
  ARM: highbank: use wfi macro instead of inline asm

Stephen Warren (2):
  tegra: rename FUNCMUX_UART2_UARTB
  tegra: don't hard-code LCD into default TEGRA_DEVICE_SETTINGS

Tetsuyuki Kobayashi (2):
  arm: rmobile: kzm9g: Adjust SDRAM setting
  arm: rmobile: kzm9g: Adjust ETM trace clock

Thierry Reding (3):
  video: tegra: Update line length to match resolution
  tegra: Enable LCD on Medcom-Wide
  tegra: Enable LCD on TEC

Tom Rini (1):
  am33xx: Drop gpio0_7_pin_mux from phytec pcm051

Tom Warren (19):
  Tegra30: Add arch-tegra30 include files
  Tegra30: Add AVP (arm720t) files
  Tegra30: Add CPU (armv7) files
  Tegra30: Add common CPU (shared) files
  Tegra30: Cardhu: Add DT files
  Tegra30: Add generic Tegra30 build support
  Tegra30: Add/enable Cardhu build (T30 reference board)
  Tegra30: clocks: Fix clock tables for I2C and other periphs
  Tegra30: fdt: Update DT files with I2C info for T30/Cardhu
  Tegra30: I2C: Enable I2C driver on Cardhu
  Tegra: T20: Remove unused 'SLOW' SoC ID and PLLX table entry
  Tegra: Move common clock code to arch/arm/cpu/tegra-common/clock.c
  Tegra114: Add arch-tegra114 include files
  Tegra114: Add AVP (arm720t) files
  Tegra114: Add CPU (armv7) files
  Tegra114: Add common CPU (shared) files
  Tegra114: Dalmore: Add DT files
  Tegra114: Add generi

Re: [U-Boot] [PATCH v2] build: imx: Fix 'u-boot.imx' build without full OBJTREE reference

2013-02-12 Thread Benoît Thébaudeau
Dear Otavio, Marek,

On Monday, February 11, 2013 5:55:17 PM, Marek Vasut wrote:
> Dear Otavio Salvador,
> 
> > When calling 'make u-boot.imx' the build were failing as it were
> > expecting the full path for the file; this regression has been
> > included by commit 71a988a (imximage.cfg: run files through C
> > preprocessor).
> > 
> > The direct references for u-boot.imx were replaced by $(obj) as
> > config.mk handles the proper setting of it making it set to $(OBJTREE)
> > when required.
> > 
> > The build has been test using:
> > 
> >  - ./MAKEALL -s mx5 -s mx6
> >  - make u-boot.imx
> >  - make O=/tmp/build
> 
> BUILD_DIR=/tmp/xyz MAKEALL please.

Once you're confident with this patch, do you mind if I integrate it as is in my
MXC NAND + SPL series in order to avoid merge conflicts (unless it is applied
before)?

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


Re: [U-Boot] Fwd: pull request for u-boot-tegra/master into ARM/master

2013-02-12 Thread Albert ARIBAUD
Hi Tom,

On Mon, 11 Feb 2013 14:20:00 -0700, Tom Warren
 wrote:

> Dropped the list from the PR. Sorry 'bout that.

Applied to u-boot-arm/master, thanks!

> -- Forwarded message --
> From: Tom Warren 
> Date: Mon, Feb 11, 2013 at 11:05 AM
> Subject: pull request for u-boot-tegra/master into ARM/master
> To: Albert ARIBAUD 
> Cc: Tom Warren , Stephen Warren
> , Simon Glass , Wolfgang Denk
> , Allen Martin , Lucas Stach
> 
> 
> 
> Albert,
> 
> Please pull u-boot-tegra/master into ARM/master. Thanks!
> 
> ./MAKEALL -a arm completed over the weekend w/o any new errors, and
> checkpatch is clean.
> 
> The following changes since commit 8978f860a64eecfa088c1088bc0c2002ec316362:
>   Tom Rini (1):
> am33xx: Drop gpio0_7_pin_mux from phytec pcm051
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-tegra master
> 
> Allen Martin (8):
>   tegra: fdt: add back missing host1x node
>   tegra20: fdt: add SPI SFLASH node
>   tegra: spi: add fdt support to tegra SPI SFLASH driver
>   tegra30: add SBC1 to periph id mapping table
>   tegra30: fdt: add SPI SLINK nodes
>   tegra: add addresses of SPI SLINK controllers
>   tegra: add SPI SLINK driver
>   tegra: cardhu: config: enable SPI
> 
> Lucas Stach (1):
>   arm: fix CONFIG_DELAY_ENVIRONMENT to act like it claims in the README
> 
> Stephen Warren (2):
>   tegra: rename FUNCMUX_UART2_UARTB
>   tegra: don't hard-code LCD into default TEGRA_DEVICE_SETTINGS
> 
> Tom Warren (9):
>   Tegra: T20: Remove unused 'SLOW' SoC ID and PLLX table entry
>   Tegra: Move common clock code to arch/arm/cpu/tegra-common/clock.c
>   Tegra114: Add arch-tegra114 include files
>   Tegra114: Add AVP (arm720t) files
>   Tegra114: Add CPU (armv7) files
>   Tegra114: Add common CPU (shared) files
>   Tegra114: Dalmore: Add DT files
>   Tegra114: Add generic Tegra114 build support
>   Tegra114: Add/enable Dalmore build (T114 reference board)
> 
>  arch/arm/cpu/arm720t/tegra-common/cpu.c   |   78 ++--
>  arch/arm/cpu/arm720t/tegra-common/cpu.h   |8 +-
>  arch/arm/cpu/arm720t/tegra114/Makefile|   42 ++
>  arch/arm/cpu/arm720t/tegra114/config.mk   |   19 +
>  arch/arm/cpu/arm720t/tegra114/cpu.c   |  297 +
>  arch/arm/cpu/armv7/tegra114/Makefile  |   40 ++
>  arch/arm/cpu/armv7/tegra114/config.mk |   19 +
>  arch/arm/cpu/tegra-common/Makefile|2 +-
>  arch/arm/cpu/tegra-common/ap.c|9 +-
>  arch/arm/cpu/tegra-common/board.c |   25 +-
>  arch/arm/cpu/tegra-common/clock.c |  560 
>  arch/arm/cpu/tegra114-common/Makefile |   41 ++
>  arch/arm/cpu/tegra114-common/clock.c  |  655 +++
>  arch/arm/cpu/tegra114-common/funcmux.c|   63 ++
>  arch/arm/cpu/tegra114-common/pinmux.c |  506 +++
>  arch/arm/cpu/tegra20-common/clock.c   |  605 +-
>  arch/arm/cpu/tegra20-common/funcmux.c |2 +-
>  arch/arm/cpu/tegra30-common/clock.c   |  712 
> -
>  arch/arm/dts/tegra114.dtsi|5 +
>  arch/arm/dts/tegra20.dtsi |   12 +
>  arch/arm/dts/tegra30.dtsi |   72 ++
>  arch/arm/include/asm/arch-tegra/clk_rst.h |   58 ++-
>  arch/arm/include/asm/arch-tegra/clock.h   |   59 ++-
>  arch/arm/include/asm/arch-tegra/gp_padctrl.h  |1 +
>  arch/arm/include/asm/arch-tegra/pmc.h |8 +
>  arch/arm/include/asm/arch-tegra/tegra.h   |9 +-
>  arch/arm/include/asm/arch-tegra/tegra_slink.h |   84 +++
>  arch/arm/include/asm/arch-tegra114/clock-tables.h |  402 
>  arch/arm/include/asm/arch-tegra114/clock.h|   28 +
>  arch/arm/include/asm/arch-tegra114/flow.h |   35 +
>  arch/arm/include/asm/arch-tegra114/funcmux.h  |   31 +
>  arch/arm/include/asm/arch-tegra114/gp_padctrl.h   |   59 ++
>  arch/arm/include/asm/arch-tegra114/gpio.h |   30 +
>  arch/arm/include/asm/arch-tegra114/hardware.h |   22 +
>  arch/arm/include/asm/arch-tegra114/pinmux.h   |  618 ++
>  arch/arm/include/asm/arch-tegra114/pmu.h  |   23 +
>  arch/arm/include/asm/arch-tegra114/spl.h  |   22 +
>  arch/arm/include/asm/arch-tegra114/tegra.h|   33 +
>  arch/arm/include/asm/arch-tegra20/clock-tables.h  |4 +
>  arch/arm/include/asm/arch-tegra20/clock.h |4 +
>  arch/arm/include/asm/arch-tegra20/funcmux.h   |2 +-
>  arch/arm/include/asm/arch-tegra20/tegra.h |2 +
>  arch/arm/include/asm/arch-tegra30/clock.h |4 +
>  arch/arm/include/asm/arch-tegra30/tegra.h |2 +
>  arch/arm/lib/board.c  |2 +-
>  board/compulab/dts/tegra20-trimslice.dts 

Re: [U-Boot] [PATCH v5 8/8] nand: mxc: Switch NAND SPL to generic SPL

2013-02-12 Thread Benoît Thébaudeau
Hi Stefano,

On Saturday, February 9, 2013 5:38:26 PM, Benoît Thébaudeau wrote:
> On Saturday, February 9, 2013 2:53:44 PM, Benoît Thébaudeau wrote:
> > On Saturday, February 9, 2013 12:47:25 AM, Benoît Thébaudeau wrote:
> > > On Friday, February 8, 2013 11:49:27 PM, Benoît Thébaudeau wrote:
> > > > Subject: [PATCH v5 8/8] nand: mxc: Switch NAND SPL to generic SPL
> > > > 
> > > > Signed-off-by: Benoît Thébaudeau 
> > > > ---
> > > > Changes in v5:
> > > >  - Remove spaces between function name and open parenthesis.
> > > >  - Fix mx31pdk and tx25 Makefile-s and SPL linker scripts.
> > > >  - Remove the useless definition of CONFIG_SPL_LDSCRIPT.
> > > >  - Fix the call to nand_boot().
> > > > 
> > > > Changes in v4:
> > > >  - New patch.
> > > > 
> > > > Changes in v3: None
> > > > Changes in v2: None
> > > 
> > > This is now supposed to be working and compile-tested.
> > > 
> > > Custodians, please review and advise.
> > > 
> > > Board maintainers, please test.
> > > 
> > > Tell me if I should split away some stuff.
> > > 
> > > Should doc/README.arm-relocation be updated, and how since tx25 no longer
> > > uses
> > > NAND SPL, which is also deprecated?
> > > 
> > > Note that mx31pdk and tx25 had been broken by commit
> > > e05e5de7fae5bec79617e113916dac6631251156. After this commit, for those
> > > boards,
> > > _main called board_init_f, which called relocate_code, which unexpectedly
> > > (for
> > > their users) returned to nowhere in ctr0.S instead of calling nand_boot.
> > > Also,
> > > crt0.S calls nand_boot if CONFIG_SPL_BUILD is not defined but
> > > CONFIG_NAND_SPL
> > > is, which is not normal for NAND SPL. Other NAND SPL boards may be broken
> > > too,
> > > but that's not too much of an issue since they are supposed to migrate to
> > > generic SPL.
> > 
> > I am also wondering if board_init_f should not be moved out of
> > mxc_nand_spl.c
> > to
> > either /lowlevel_init.S or /.c. That would make
> > mxc_nand_spl.c more generic if for some reason a board needs to do specific
> > things. Any opinion?
> > 
> > For the start.S files, since it's not possible to know from
> > CONFIG_SPL_BUILD
> > and
> > CONFIG_NAND_SPL if relocate_code is needed or not, I see the following
> > choices:
> > 1) Let it defined in all cases. It's quite small, so it won't hurt much.
> > 2) Create a specific SPL #define (e.g. CONFIG_SPL_RELOCATE_CODE) to define
> > it
> >for generic SPL only if needed.
> > 3) Just create a specific linker section for it so that it's automatically
> >garbage-collected if unneeded.
> > Any opinion?
> 
> I'm also considering to factorize relocate_code to crt0.S. There's not really
> a
> good reason for it to be depending on each ARM processor. Any opinion?

FYI, I will post soon a v6 with a lot of cleanup.

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


Re: [U-Boot] [PATCH v5 1/3] Add README for the "Falcon" mode

2013-02-12 Thread Andreas Bießmann
On 02/12/2013 01:52 PM, Stefan Roese wrote:
> On 12.02.2013 13:44, Andreas Bießmann wrote:
>>> 3. Use "fdt" commands to patch the DT blob:
>>> => fdt addr 180
>>> => fdt boardsetup
>>> => fdt chosen
>>>
>>> 4. Display patched DT blob (optional):
>>> => fdt print
>>>
>>> 5. Save fdt to NOR flash:
>>> => erase fc06 fc07
>>> => cp.b 180 fc06 1
>>> ...
>>>
>>> So all we need for DT based booting (compared to ATAG booting) is the
>>> "fdt" command.
>>
>> As I understand this guide there is no 'spl export' required for 'Falcon
>> Mode' with FDT, is that correct?
> 
> Correct. At least thats how it works on PowerPC. It should work that way
> on ARM as well. No need for any "spl export" commands here.

Well, Ok, this changes things a bit. The'spl export' command was
prepared for 'bootm with fdt' to gather the same information as in ATAGS
mode, honestly this was never tested cause Simon Schwarz worked with
ATAGS too. If this is not required to prepare the fdt blob it was a
misunderstanding from the very beginning of that command.
However the README should reflect that the 'spl export' with fdt is
untested and that ppc prepares the fdt blob with the fdt command instead.

Best regards

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


Re: [U-Boot] [PATCH v5 1/3] Add README for the "Falcon" mode

2013-02-12 Thread Stefano Babic
On 12/02/2013 13:44, Andreas Bießmann wrote:
> 
>> Stefano, perhaps you could integrate this into this README as well.
> 
> +1

Right, I will push V6 with changes you suggested and integrating
Stefan's part.

Regards,
Stefano Babic


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


Re: [U-Boot] [PATCH v3] mx6: Disable Power Down Bit of watchdog

2013-02-12 Thread Stefano Babic
On 07/02/2013 17:45, Fabio Estevam wrote:
> On a mx6qsabresd revision C board with rev1.2 mx6q, the system gets resetted 
> and it is not able to reach the Linux prompt.
> 
> Comparing the watchdog behaviour on a revB versus revC board:
> 
> - On a mx6qsabresd revB:
> 
> U-Boot > reset
> resetting ...
> 
> U-Boot 2013.01-10524-g432a3aa-dirty (Feb 07 2013 - 13:34:46)
> 
> CPU:   Freescale i.MX6Q rev1.1 at 792 MHz
> Reset cause: WDOG
> ...
> 
> - On a mx6qsabresd revC:
> 
> U-Boot > reset
> resetting ...
> 
> U-Boot 2013.01-10524-g432a3aa-dirty (Feb 07 2013 - 13:34:46)
> 
> CPU:   Freescale i.MX6Q rev1.1 at 792 MHz
> Reset cause: POR
> 
> So due to revC POR/watchdog circuitry whenever a watchdog occurs, it causes a 
> POR.
> 
> Clearing the PDE - Power Down Enable bit of WMCR registers fixes the problem 
> and
> is also safe for all mx6 boards.
> 
> Signed-off-by: Fabio Estevam 
> ---

Applied to u-boot-imx, thanks.

Best regards,
Stefano Babic


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


Re: [U-Boot] [PATCH 1/6] imx: mx6q DDR3 init: Fix tMRD

2013-02-12 Thread Stefano Babic
On 30/01/2013 22:19, Benoît Thébaudeau wrote:
> MMDC1_MDCFG1.tMRD should be set to max(tMRD, tMOD) for DDR3.
> 
> For all DDR3 speed bins:
>   tMRD(min) = 4 nCK
>   tMOD(min) = max(12 nCK, 15 ns)
> 
> Hence, MMDC1_MDCFG1.tMRD should be set to max(12 nCK, 15 ns), which is 12 nCK
> at 532 MHz, encoded as 0xB in the bit-field MMDC1_MDCFG1[8:5].
> 
> Signed-off-by: Benoît Thébaudeau 
> ---
>  board/freescale/imx/ddr/mx6q_4x_mt41j128.cfg |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/board/freescale/imx/ddr/mx6q_4x_mt41j128.cfg 
> b/board/freescale/imx/ddr/mx6q_4x_mt41j128.cfg
> index c86cd40..9ac8027 100644
> --- a/board/freescale/imx/ddr/mx6q_4x_mt41j128.cfg
> +++ b/board/freescale/imx/ddr/mx6q_4x_mt41j128.cfg
> @@ -110,7 +110,7 @@ DATA 4 0x021b0018 0x00081740
>  
>  DATA 4 0x021b001c 0x8000
>  DATA 4 0x021b000c 0x555A7975
> -DATA 4 0x021b0010 0xFF538E64
> +DATA 4 0x021b0010 0xFF538F64
>  DATA 4 0x021b0014 0x01FF00DB
>  DATA 4 0x021b002c 0x26D2
>  


Applied (whole series) to u-boot-imx, thanks.

Best regards,
Stefano Babic


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


Re: [U-Boot] [PATCH v5 1/3] Add README for the "Falcon" mode

2013-02-12 Thread Stefan Roese
On 12.02.2013 13:44, Andreas Bießmann wrote:
>> 3. Use "fdt" commands to patch the DT blob:
>> => fdt addr 180
>> => fdt boardsetup
>> => fdt chosen
>>
>> 4. Display patched DT blob (optional):
>> => fdt print
>>
>> 5. Save fdt to NOR flash:
>> => erase fc06 fc07
>> => cp.b 180 fc06 1
>> ...
>>
>> So all we need for DT based booting (compared to ATAG booting) is the
>> "fdt" command.
> 
> As I understand this guide there is no 'spl export' required for 'Falcon
> Mode' with FDT, is that correct?

Correct. At least thats how it works on PowerPC. It should work that way
on ARM as well. No need for any "spl export" commands here.

Thanks,
Stefan

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


Re: [U-Boot] [PATCH v3 2/3] Tegra114: fdt: Update DT files with I2C info for T114/Dalmore

2013-02-12 Thread Laxman Dewangan

On Friday 08 February 2013 11:34 PM, Stephen Warren wrote:

On 02/08/2013 10:25 AM, Tom Warren wrote:

T114, like T30, does not have a separate/different DVC (power I2C)
controller like T20 - all 5 I2C controllers are identical, but
I2C5 is used to designate the controller intended for power
control (PWR_I2C in the schematics). PWR_I2C is set to 400KHz.
diff --git a/board/nvidia/dts/tegra114-dalmore.dts 
b/board/nvidia/dts/tegra114-dalmore.dts
+   aliases {
+   };
+

There's no point adding an empty aliases node here. Feel free to fix
that up when you apply it rather than reposting if you want.

I'd like too see Laxman sign-off on the "*2" question he had earlier
before actually checking this in.

We do not require *2 as the i2c clock divider is DIVU16 type. There was 
bug in early code on kernel also which we fixed in dowstream long back. 
Possibly uboot have not fixed this yet.


---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v5 1/3] Add README for the "Falcon" mode

2013-02-12 Thread Andreas Bießmann
Dear Stefan Roese,

On 02/12/2013 01:09 PM, Stefan Roese wrote:
> On 12.02.2013 12:48, Andreas Bießmann wrote:



> 3. Use "fdt" commands to patch the DT blob:
> => fdt addr 180
> => fdt boardsetup
> => fdt chosen
> 
> 4. Display patched DT blob (optional):
> => fdt print
> 
> 5. Save fdt to NOR flash:
> => erase fc06 fc07
> => cp.b 180 fc06 1
> ...
> 
> So all we need for DT based booting (compared to ATAG booting) is the
> "fdt" command.

As I understand this guide there is no 'spl export' required for 'Falcon
Mode' with FDT, is that correct?

> Stefano, perhaps you could integrate this into this README as well.

+1

Best regards

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


Re: [U-Boot] [PATCH v3] mx6: Disable Power Down Bit of watchdog

2013-02-12 Thread Stefano Babic
On 07/02/2013 17:45, Fabio Estevam wrote:
> On a mx6qsabresd revision C board with rev1.2 mx6q, the system gets resetted 
> and it is not able to reach the Linux prompt.
> 
> Comparing the watchdog behaviour on a revB versus revC board:
> 
> - On a mx6qsabresd revB:
> 
> U-Boot > reset
> resetting ...
> 
> U-Boot 2013.01-10524-g432a3aa-dirty (Feb 07 2013 - 13:34:46)
> 
> CPU:   Freescale i.MX6Q rev1.1 at 792 MHz
> Reset cause: WDOG
> ...
> 
> - On a mx6qsabresd revC:
> 
> U-Boot > reset
> resetting ...
> 
> U-Boot 2013.01-10524-g432a3aa-dirty (Feb 07 2013 - 13:34:46)
> 
> CPU:   Freescale i.MX6Q rev1.1 at 792 MHz
> Reset cause: POR
> 
> So due to revC POR/watchdog circuitry whenever a watchdog occurs, it causes a 
> POR.
> 
> Clearing the PDE - Power Down Enable bit of WMCR registers fixes the problem 
> and
> is also safe for all mx6 boards.
> 
> Signed-off-by: Fabio Estevam 
> ---

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


Re: [U-Boot] [PATCH v5 1/3] Add README for the "Falcon" mode

2013-02-12 Thread Stefan Roese
On 12.02.2013 12:48, Andreas Bießmann wrote:



> The spl export command does not write to a storage media. The user is
> responsible to transfer the gathered information (assembled ATAGS list
> or prepared FDT) from temporary storage in RAM into persistant storage
> after each run of 'spl export'. Unfortunately the position of temporary
> storage can not be predicted nor provided at commandline, it depends
> highly on your system setup and your provided data (ATAGS or FDT).
> However at the end of an succesful 'spl export' run it will print the
> RAM address of temporary storage.
> Now the user have to save the generated BLOB from that printed address
> to the pre-defined address in persistent storage
> (CONFIG_CMD_SPL_NAND_OFS in case of NAND).
> The following example shows how to prepare the data for Falcon Mode on
> twister board with ATAGS BLOB.
> --->8---
> 
> Would be nice to have some FDT example too (in future).

I used FDT with SPL already on the a3m071 board. Please take a look at
the README (board/a3m071/README):

...
Preparing Linux image(s) for booting from SPL U-Boot:
-
To boot the Linux kernel from the SPL, the DT blob (fdt) needs to get
prepard/patched first. U-Boot usually inserts some dynamic values into
the DT binary (blob), e.g. autodetected memory size, MAC addresses,
clocks speeds etc. To generate this patched DT blob, you can use
the following command:

1. Load fdt blob to SDRAM:
=> tftp 180 a3m071/a3m071.dtb

2. Set bootargs as desired for Linux booting (e.g. flash_mtd):
=> run mtdargs addip2 addtty

3. Use "fdt" commands to patch the DT blob:
=> fdt addr 180
=> fdt boardsetup
=> fdt chosen

4. Display patched DT blob (optional):
=> fdt print

5. Save fdt to NOR flash:
=> erase fc06 fc07
=> cp.b 180 fc06 1
...

So all we need for DT based booting (compared to ATAG booting) is the
"fdt" command.

Stefano, perhaps you could integrate this into this README as well.

Thanks,
Stefan

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


Re: [U-Boot] [PATCH v5 1/3] Add README for the "Falcon" mode

2013-02-12 Thread Andreas Bießmann
Dear Stefano Babic,

On 02/12/2013 09:38 AM, Stefano Babic wrote:
> Simple howto to add support to a board
> for booting the kernel from SPL ("Falcon" mode).
> 
> Signed-off-by: Stefano Babic 
> ---
> Changes in v5:
> - several fixes for the language, rephrasing some unclear parts (Vikram 
> Narayanan)
> 
> Changes in v4:
> - fix capitalization, styling, in spl help (Andreas Biessmann)
> - move CONFIG_SPL_OS_BOOT before function in doc (Andreas Biessmann)
> 
> Changes in v3:
> - parameter initrd_addr was removed in V2 (Andreas Biessmann)
> - added patch to fix help usage for spl export (Andreas Biessmann)
> - Added empty lines (Otavio Salvador)
> - add a more exhaustive description explaining that
>   spl export does not save into media (Lukasz Majewski).
> 
> Changes in v2:
> - spelling, language fixes (Andreas Biessman)
> - rewrite some unclear sentences
> - drop CONFIG_SPL_OS_BOOT_KEY
> - make example with twister more exhaustive
> 
>  doc/README.falcon |  169 
> +
>  1 file changed, 169 insertions(+)
>  create mode 100644 doc/README.falcon
> 
> diff --git a/doc/README.falcon b/doc/README.falcon
> new file mode 100644
> index 000..72fe04a
> --- /dev/null
> +++ b/doc/README.falcon
> @@ -0,0 +1,169 @@
> +U-Boot Falcon Mode
> +
> +
> +Introduction
> +
> +
> +This document provides an overview of how to add support for Falcon Mode
> +to a board.
> +Falcon Mode is introduced to speed up the booting process, allowing
> +to boot a Linux kernel (or whatever image) without a full blown U-Boot.
> +
> +Falcon Mode relies on the SPL framework. In fact, to make booting faster,
> +U-Boot is split into two parts: the SPL (Secondary Program Loader) and U-Boot
> +image. In most implementations, SPL is used to start U-Boot when booting from
> +a mass storage, such as NAND or SD-Card. SPL has now support for other media,
> +and can generally be seen as a way to start an image performing the minimum
> +required initialization. SPL mainly initializes the RAM controller, and then
> +copies U-Boot image into the memory. The Falcon Mode extends this way
> +allowing to start the Linux kernel directly from SPL. A new command is added
> +to U-Boot to prepare the parameters that SPL must pass to the kernel, using
> +ATAGS or Device Tree.
> +
> +In usual U-Boot systems, these parameters are generated each time before
> +loading the kernel, passing to Linux the address in memory where
> +the parameters can be read.
> +With Falcon Mode, this snapshot can be saved into persistent storage and SPL 
> is
> +informed to load it before running the kernel.
> +
> +To boot the kernel, these steps under a Falcon-aware U-Boot are required:
> +
> +1. Boot the board into U-Boot.
> +Use the "spl export" command to generate the kernel parameters area or the 
> DT.
> +U-Boot runs as when it boots the kernel, but stops before passing the control
> +to the kernel.
> +
> +2. Save the prepared snapshot into persistent media.
> +The address where to save it must be configured into board configuration
> +file (CONFIG_CMD_SPL_NAND_OFS for NAND).
> +
> +3. Boot the board into Falcon Mode. SPL will load the kernel and copy
> +the parameters which are saved in the persistent area area to the required 
> address.

double 'area'

> +
> +It is required to implement a custom mechanism to select if SPL loads U-Boot
> +or another image.
> +
> +The value of a GPIO is a simple way to operate the selection, as well as
> +reading a character from the SPL console if CONFIG_SPL_CONSOLE is set.
> +
> +Falcon Mode is generally activated by setting CONFIG_SPL_OS_BOOT. This tells
> +SPL that U-Boot is not the only available image that SPL is able to start.
> +
> +Configuration
> +
> +CONFIG_CMD_SPL   Enable the "spl export" command.
> + The command "spl export" is then available in U-Boot
> + mode
> +CONFIG_SYS_SPL_ARGS_ADDR Address in RAM where the parameters must be
> + copied by SPL.
> + In most cases, it is  + 0x100
> +
> +CONFIG_SYS_NAND_SPL_KERNEL_OFFS  Offset in NAND where the kernel is 
> stored
> +
> +CONFIG_CMD_SPL_NAND_OFS  Offset in NAND where the parameters area was 
> saved.
> +
> +CONFIG_CMD_SPL_WRITE_SIZESize of the parameters area to be copied
> +
> +CONFIG_SPL_OS_BOOT   Activate Falcon Mode.
> +
> +Function that a board must implement
> +
> +
> +void spl_board_prepare_for_linux(void) : optional
> + Called from SPL before starting the kernel
> +
> +spl_start_uboot() : required
> + Returns "0" if SPL starts the kernel, "1" if U-Boot

minor complaint:

Returns "0" if SPL should start the kernel, ...

> + must be started.
> +
> +
> +Using spl command
> +-
> +
> +spl - SPL configuration
> +
> +Usage:
> +
> +spl export  [kernel_addr] [initrd_addr] [

[U-Boot] [PATCH V3 3/5] ARM: OMAP4/5: clocks: Add the required OPP settings as per the latest addendum

2013-02-12 Thread R Sricharan
Change OPP settings as per the latest 0.5 version of
addendum for OMAP5430 ES2.0. omap4/hw_data.c is touched
here to add dummy dividers.

While here correcting OPP_NOM mpu, core frequency for
OMAP4430 ES2.x

Note that OMAP5430 ES1.0 support is still kept alive and
would be removed in a cleanup later.

Signed-off-by: Lokesh Vutla 
Signed-off-by: R Sricharan 
Cc: Tom Rini 
Cc: Nishanth Menon 
---
 [v2] Addressed Tom Rini's  comments
 [v3] Addressed some of Nishanth's comments here.
  Essentially added missing OPP_HIGH/LOW settings
  for OMAP5 E2.0 and corrected the data as per the
  0.5 addendum. Also added comments for both OMAP4/5
  frequency tables. Rephrased the subject accordingly.

 arch/arm/cpu/armv7/omap-common/clocks-common.c |9 +-
 arch/arm/cpu/armv7/omap4/hw_data.c |  164 +
 arch/arm/cpu/armv7/omap5/hw_data.c |  235 ++--
 arch/arm/include/asm/arch-omap5/clocks.h   |   29 ++-
 arch/arm/include/asm/omap_common.h |6 +-
 5 files changed, 254 insertions(+), 189 deletions(-)

diff --git a/arch/arm/cpu/armv7/omap-common/clocks-common.c 
b/arch/arm/cpu/armv7/omap-common/clocks-common.c
index 88e5336..818a963 100644
--- a/arch/arm/cpu/armv7/omap-common/clocks-common.c
+++ b/arch/arm/cpu/armv7/omap-common/clocks-common.c
@@ -103,10 +103,14 @@ void setup_post_dividers(u32 const base, const struct 
dpll_params *params)
writel(params->m6_h13, &dpll_regs->cm_div_m6_h13_dpll);
if (params->m7_h14 >= 0)
writel(params->m7_h14, &dpll_regs->cm_div_m7_h14_dpll);
+   if (params->h21 >= 0)
+   writel(params->h21, &dpll_regs->cm_div_h21_dpll);
if (params->h22 >= 0)
writel(params->h22, &dpll_regs->cm_div_h22_dpll);
if (params->h23 >= 0)
writel(params->h23, &dpll_regs->cm_div_h23_dpll);
+   if (params->h24 >= 0)
+   writel(params->h24, &dpll_regs->cm_div_h24_dpll);
 }
 
 static inline void do_bypass_dpll(u32 const base)
@@ -319,11 +323,6 @@ void configure_mpu_dpll(void)
CM_CLKSEL_DCC_EN_MASK);
}
 
-   setbits_le32((*prcm)->cm_mpu_mpu_clkctrl,
-   MPU_CLKCTRL_CLKSEL_EMIF_DIV_MODE_MASK);
-   setbits_le32((*prcm)->cm_mpu_mpu_clkctrl,
-   MPU_CLKCTRL_CLKSEL_ABE_DIV_MODE_MASK);
-
params = get_mpu_dpll_params(*dplls_data);
 
do_setup_dpll((*prcm)->cm_clkmode_dpll_mpu, params, DPLL_LOCK, "mpu");
diff --git a/arch/arm/cpu/armv7/omap4/hw_data.c 
b/arch/arm/cpu/armv7/omap4/hw_data.c
index 892d016..8d31d6d 100644
--- a/arch/arm/cpu/armv7/omap4/hw_data.c
+++ b/arch/arm/cpu/armv7/omap4/hw_data.c
@@ -49,115 +49,127 @@ struct omap_sys_ctrl_regs const **ctrl =
  * Please use this tool for creating the table for any new frequency.
  */
 
-/* dpll locked at 1400 MHz MPU clk at 700 MHz(OPP100) - DCC OFF */
+/*
+ * dpll locked at 1400 MHz MPU clk at 700 MHz(OPP100) - DCC OFF
+ * OMAP4460 OPP_NOM frequency
+ */
 static const struct dpll_params mpu_dpll_params_1400mhz[NUM_SYS_CLKS] = {
-   {175, 2, 1, -1, -1, -1, -1, -1, -1, -1},/* 12 MHz   */
-   {700, 12, 1, -1, -1, -1, -1, -1, -1, -1},   /* 13 MHz   */
-   {125, 2, 1, -1, -1, -1, -1, -1, -1, -1},/* 16.8 MHz */
-   {401, 10, 1, -1, -1, -1, -1, -1, -1, -1},   /* 19.2 MHz */
-   {350, 12, 1, -1, -1, -1, -1, -1, -1, -1},   /* 26 MHz   */
-   {700, 26, 1, -1, -1, -1, -1, -1, -1, -1},   /* 27 MHz   */
-   {638, 34, 1, -1, -1, -1, -1, -1, -1, -1}/* 38.4 MHz */
+   {175, 2, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1},/* 12 MHz   */
+   {700, 12, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1},   /* 13 MHz   */
+   {125, 2, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1},/* 16.8 MHz */
+   {401, 10, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1},   /* 19.2 MHz */
+   {350, 12, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1},   /* 26 MHz   */
+   {700, 26, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1},   /* 27 MHz   */
+   {638, 34, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1}/* 38.4 MHz */
 };
 
-/* dpll locked at 1584 MHz - MPU clk at 792 MHz(OPP Turbo 4430) */
+/*
+ * dpll locked at 1600 MHz - MPU clk at 800 MHz(OPP Turbo 4430)
+ * OMAP4430 OPP_TURBO frequency
+ */
 static const struct dpll_params mpu_dpll_params_1600mhz[NUM_SYS_CLKS] = {
-   {200, 2, 1, -1, -1, -1, -1, -1, -1, -1},/* 12 MHz   */
-   {800, 12, 1, -1, -1, -1, -1, -1, -1, -1},   /* 13 MHz   */
-   {619, 12, 1, -1, -1, -1, -1, -1, -1, -1},   /* 16.8 MHz */
-   {125, 2, 1, -1, -1, -1, -1, -1, -1, -1},/* 19.2 MHz */
-   {400, 12, 1, -1, -1, -1, -1, -1, -1, -1},   /* 26 MHz   */
-   {800, 26, 1, -1, -1, -1, -1, -1, -1, -1},   /* 27 MHz   */
-   {125, 5, 1, -1, -1, -1, -1, -1, -1, -1} /* 38.4 MHz */
+   {200, 2, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1},/* 12 MHz   */
+   {800, 12, 1

[U-Boot] [PATCH V3 5/5] ARM: OMAP5: srcomp: enable slew rate compensation cells after powerup

2013-02-12 Thread R Sricharan
From: Lokesh Vutla 

After power-up SRCOMP cells are by-passed by default in OMAP5.
Software has to enable these SRCOMP sells.
For ES2: All 5 SRCOMP cells needs to be enabled.
For ES1: Only 4 SRCOMP cells in core power domain are enabled.
 The 1 in wkup domain is not enabled because smart i/os
 of wkup domain work with default compensation code.

Signed-off-by: R Sricharan 
Signed-off-by: Lokesh Vutla 
Reviewed-by: Tom Rini 
Cc: Tom Rini 
---
 [v2] Addressed Tom Rini's  comments
 [v3] No Change

 arch/arm/cpu/armv7/omap-common/hwinit-common.c |6 ++
 arch/arm/cpu/armv7/omap5/hwinit.c  |  116 
 arch/arm/cpu/armv7/omap5/prcm-regs.c   |5 +-
 arch/arm/include/asm/arch-omap5/clocks.h   |4 +
 arch/arm/include/asm/arch-omap5/omap.h |   19 
 arch/arm/include/asm/arch-omap5/sys_proto.h|1 +
 arch/arm/include/asm/omap_common.h |2 +
 7 files changed, 152 insertions(+), 1 deletion(-)

diff --git a/arch/arm/cpu/armv7/omap-common/hwinit-common.c 
b/arch/arm/cpu/armv7/omap-common/hwinit-common.c
index e5a5eb6..60af7eb 100644
--- a/arch/arm/cpu/armv7/omap-common/hwinit-common.c
+++ b/arch/arm/cpu/armv7/omap-common/hwinit-common.c
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -100,6 +101,10 @@ void spl_display_print(void)
 }
 #endif
 
+void __weak srcomp_enable(void)
+{
+}
+
 /*
  * Routine: s_init
  * Description: Does early system init of watchdog, muxing,  andclocks
@@ -126,6 +131,7 @@ void s_init(void)
watchdog_init();
set_mux_conf_regs();
 #ifdef CONFIG_SPL_BUILD
+   srcomp_enable();
setup_clocks_for_console();
 
gd = &gdata;
diff --git a/arch/arm/cpu/armv7/omap5/hwinit.c 
b/arch/arm/cpu/armv7/omap5/hwinit.c
index 8e66a96..f083198 100644
--- a/arch/arm/cpu/armv7/omap5/hwinit.c
+++ b/arch/arm/cpu/armv7/omap5/hwinit.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -182,6 +183,121 @@ void do_io_settings(void)
writel(EFUSE_3, (*ctrl)->control_efuse_3);
writel(EFUSE_4, (*ctrl)->control_efuse_4);
 }
+
+static const struct srcomp_params srcomp_parameters[NUM_SYS_CLKS] = {
+   {0x45, 0x1},/* 12 MHz   */
+   {-1, -1},   /* 13 MHz   */
+   {0x63, 0x2},/* 16.8 MHz */
+   {0x57, 0x2},/* 19.2 MHz */
+   {0x20, 0x1},/* 26 MHz   */
+   {-1, -1},   /* 27 MHz   */
+   {0x41, 0x3} /* 38.4 MHz */
+};
+
+void srcomp_enable(void)
+{
+   u32 srcomp_value, mul_factor, div_factor, clk_val, i;
+   u32 sysclk_ind  = get_sys_clk_index();
+   u32 omap_rev= omap_revision();
+
+   mul_factor = srcomp_parameters[sysclk_ind].multiply_factor;
+   div_factor = srcomp_parameters[sysclk_ind].divide_factor;
+
+   for (i = 0; i < 4; i++) {
+   srcomp_value = readl((*ctrl)->control_srcomp_north_side + i*4);
+   srcomp_value &=
+   ~(MULTIPLY_FACTOR_XS_MASK | DIVIDE_FACTOR_XS_MASK);
+   srcomp_value |= (mul_factor << MULTIPLY_FACTOR_XS_SHIFT) |
+   (div_factor << DIVIDE_FACTOR_XS_SHIFT);
+   writel(srcomp_value, (*ctrl)->control_srcomp_north_side + i*4);
+   }
+
+   if ((omap_rev == OMAP5430_ES1_0) || (omap_rev == OMAP5432_ES1_0)) {
+   clk_val = readl((*prcm)->cm_coreaon_io_srcomp_clkctrl);
+   clk_val |= OPTFCLKEN_SRCOMP_FCLK_MASK;
+   writel(clk_val, (*prcm)->cm_coreaon_io_srcomp_clkctrl);
+
+   for (i = 0; i < 4; i++) {
+   srcomp_value =
+   readl((*ctrl)->control_srcomp_north_side + i*4);
+   srcomp_value &= ~PWRDWN_XS_MASK;
+   writel(srcomp_value,
+  (*ctrl)->control_srcomp_north_side + i*4);
+
+   while (((readl((*ctrl)->control_srcomp_north_side + i*4)
+   & SRCODE_READ_XS_MASK) >>
+   SRCODE_READ_XS_SHIFT) == 0)
+   ;
+
+   srcomp_value =
+   readl((*ctrl)->control_srcomp_north_side + i*4);
+   srcomp_value &= ~OVERRIDE_XS_MASK;
+   writel(srcomp_value,
+  (*ctrl)->control_srcomp_north_side + i*4);
+   }
+   } else {
+   srcomp_value = readl((*ctrl)->control_srcomp_east_side_wkup);
+   srcomp_value &= ~(MULTIPLY_FACTOR_XS_MASK |
+ DIVIDE_FACTOR_XS_MASK);
+   srcomp_value |= (mul_factor << MULTIPLY_FACTOR_XS_SHIFT) |
+   (div_factor << DIVIDE_FACTOR_XS_SHIFT);
+   writel(srcomp_value, (*ctrl)->control_srcomp_east_side_wkup);
+
+   for (i = 0; i < 4; i++) {
+   srcomp_value =
+

[U-Boot] [PATCH V3 4/5] ARM: OMAP5: Add DDR changes required for OMAP543X ES2.0 SOCs

2013-02-12 Thread R Sricharan
From: Lokesh Vutla 

Add pre calculated timing settings of LPDDR2 and DDR3 memories
present in OMAP5430 and OMAP5432 ES2.0 versions.

Also adding the DDR pad io settings required for
OMAP543X SOCs here.

Signed-off-by: R Sricharan 
Signed-off-by: Lokesh Vutla 
Reviewed-by: Tom Rini 
Cc: Tom Rini 
---
 [v2] Addressed Tom Rini's  comments
 [v3] No Change

 arch/arm/cpu/armv7/omap5/hw_data.c |   14 ++
 arch/arm/cpu/armv7/omap5/sdram.c   |   75 +++-
 arch/arm/include/asm/arch-omap5/omap.h |6 +++
 arch/arm/include/asm/emif.h|1 +
 4 files changed, 94 insertions(+), 2 deletions(-)

diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c 
b/arch/arm/cpu/armv7/omap5/hw_data.c
index 6470ece..772fdfb 100644
--- a/arch/arm/cpu/armv7/omap5/hw_data.c
+++ b/arch/arm/cpu/armv7/omap5/hw_data.c
@@ -488,6 +488,16 @@ const struct ctrl_ioregs ioregs_omap5432_es1 = {
.ctrl_emif_sdram_config_ext = SDRAM_CONFIG_EXT_RD_LVL_11_SAMPLES,
 };
 
+const struct ctrl_ioregs ioregs_omap5432_es2 = {
+   .ctrl_ddrch = DDR_IO_I_40OHM_SR_FAST_WD_DQ_NO_PULL_DQS_NO_PULL_ES2,
+   .ctrl_lpddr2ch = 0x0,
+   .ctrl_ddr3ch = DDR_IO_I_40OHM_SR_SLOWEST_WD_DQ_NO_PULL_DQS_NO_PULL_ES2,
+   .ctrl_ddrio_0 = DDR_IO_0_VREF_CELLS_DDR3_VALUE_ES2,
+   .ctrl_ddrio_1 = DDR_IO_1_VREF_CELLS_DDR3_VALUE_ES2,
+   .ctrl_ddrio_2 = DDR_IO_2_VREF_CELLS_DDR3_VALUE_ES2,
+   .ctrl_emif_sdram_config_ext = SDRAM_CONFIG_EXT_RD_LVL_11_SAMPLES,
+};
+
 void hw_data_init(void)
 {
u32 omap_rev = omap_revision();
@@ -526,11 +536,15 @@ void get_ioregs(const struct ctrl_ioregs **regs)
 
switch (omap_rev) {
case OMAP5430_ES1_0:
+   case OMAP5430_ES2_0:
*regs = &ioregs_omap5430;
break;
case OMAP5432_ES1_0:
*regs = &ioregs_omap5432_es1;
break;
+   case OMAP5432_ES2_0:
+   *regs = &ioregs_omap5432_es2;
+   break;
 
default:
printf("\n INVALID OMAP REVISION ");
diff --git a/arch/arm/cpu/armv7/omap5/sdram.c b/arch/arm/cpu/armv7/omap5/sdram.c
index 687800f..2ef7fcd 100644
--- a/arch/arm/cpu/armv7/omap5/sdram.c
+++ b/arch/arm/cpu/armv7/omap5/sdram.c
@@ -67,6 +67,25 @@ const struct emif_regs emif_regs_532_mhz_2cs = {
.emif_ddr_ext_phy_ctrl_5= 0x04010040
 };
 
+const struct emif_regs emif_regs_532_mhz_2cs_es2 = {
+   .sdram_config_init  = 0x80800EBA,
+   .sdram_config   = 0x808022BA,
+   .ref_ctrl   = 0x081A,
+   .sdram_tim1 = 0x772F6873,
+   .sdram_tim2 = 0x304a129a,
+   .sdram_tim3 = 0x02f7e45f,
+   .read_idle_ctrl = 0x0005,
+   .zq_config  = 0x100b3215,
+   .temp_alert_config  = 0x08000a05,
+   .emif_ddr_phy_ctlr_1_init   = 0x0E30400d,
+   .emif_ddr_phy_ctlr_1= 0x0E30400d,
+   .emif_ddr_ext_phy_ctrl_1= 0x04020080,
+   .emif_ddr_ext_phy_ctrl_2= 0x28C518A3,
+   .emif_ddr_ext_phy_ctrl_3= 0x518A3146,
+   .emif_ddr_ext_phy_ctrl_4= 0x0014628C,
+   .emif_ddr_ext_phy_ctrl_5= 0xC330CC33,
+};
+
 const struct emif_regs emif_regs_266_mhz_2cs = {
.sdram_config_init  = 0x80800EBA,
.sdram_config   = 0x808022BA,
@@ -109,6 +128,29 @@ const struct emif_regs emif_regs_ddr3_532_mhz_1cs = {
.emif_rd_wr_exec_thresh = 0x0305
 };
 
+const struct emif_regs emif_regs_ddr3_532_mhz_1cs_es2 = {
+   .sdram_config_init  = 0x61851B32,
+   .sdram_config   = 0x61851B32,
+   .ref_ctrl   = 0x1035,
+   .sdram_tim1 = 0xCCCF36B3,
+   .sdram_tim2 = 0x308F7FDA,
+   .sdram_tim3 = 0x027F88A8,
+   .read_idle_ctrl = 0x0005,
+   .zq_config  = 0x1007190B,
+   .temp_alert_config  = 0x,
+   .emif_ddr_phy_ctlr_1_init   = 0x0030400A,
+   .emif_ddr_phy_ctlr_1= 0x0034400A,
+   .emif_ddr_ext_phy_ctrl_1= 0x04040100,
+   .emif_ddr_ext_phy_ctrl_2= 0x,
+   .emif_ddr_ext_phy_ctrl_3= 0x,
+   .emif_ddr_ext_phy_ctrl_4= 0x,
+   .emif_ddr_ext_phy_ctrl_5= 0x4350D435,
+   .emif_rd_wr_lvl_rmp_win = 0x,
+   .emif_rd_wr_lvl_rmp_ctl = 0x8000,
+   .emif_rd_wr_lvl_ctl = 0x,
+   .emif_rd_wr_exec_thresh = 0x4305
+};
+
 const struct dmm_lisa_map_regs lisa_map_4G_x_2_x_2 = {
.dmm_lisa_map_0 = 0x0,
.dmm_lisa_map_1 = 0x0,
@@ -125,8 +167,12 @@ static void emif_get_reg_dump_sdp(u32 emif_nr, const 
struct emif_regs **regs)
case OMAP5432_ES1_0:
*regs = &emif_regs_ddr3_532_mhz_1cs;
 

[U-Boot] [PATCH V3 2/5] ARM: OMAP5: clock: Add the prcm register changes required for ES2.0

2013-02-12 Thread R Sricharan
PRCM register addresses are changed from ES1.0 to ES2.0 due to
PER power domain getting moved to CORE power domain.

So adding the nessecary register changes for the same.

Signed-off-by: R Sricharan 
Reviewed-by: Tom Rini 
Cc: Tom Rini 
---
 [v2] Addressed Tom Rini's  comments
 [v3] No Change

 arch/arm/cpu/armv7/omap5/hw_data.c   |5 +
 arch/arm/cpu/armv7/omap5/prcm-regs.c |  283 ++
 arch/arm/include/asm/omap_common.h   |4 +
 3 files changed, 292 insertions(+)

diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c 
b/arch/arm/cpu/armv7/omap5/hw_data.c
index 6b039f5..e319dc5 100644
--- a/arch/arm/cpu/armv7/omap5/hw_data.c
+++ b/arch/arm/cpu/armv7/omap5/hw_data.c
@@ -451,6 +451,11 @@ void hw_data_init(void)
*omap_vcores = &omap5432_volts;
break;
 
+   case OMAP5430_ES2_0:
+   case OMAP5432_ES2_0:
+   *prcm = &omap5_es2_prcm;
+   break;
+
default:
printf("\n INVALID OMAP REVISION ");
}
diff --git a/arch/arm/cpu/armv7/omap5/prcm-regs.c 
b/arch/arm/cpu/armv7/omap5/prcm-regs.c
index 0f58b2f..58c9d50 100644
--- a/arch/arm/cpu/armv7/omap5/prcm-regs.c
+++ b/arch/arm/cpu/armv7/omap5/prcm-regs.c
@@ -378,3 +378,286 @@ struct omap_sys_ctrl_regs const omap5_ctrl = {
.control_efuse_12   = 0x4AE0CDF4,
.control_efuse_13   = 0x4AE0CDF8,
 };
+
+struct prcm_regs const omap5_es2_prcm = {
+   /* cm1.ckgen */
+   .cm_clksel_core = 0x4a004100,
+   .cm_clksel_abe = 0x4a004108,
+   .cm_dll_ctrl = 0x4a004110,
+   .cm_clkmode_dpll_core = 0x4a004120,
+   .cm_idlest_dpll_core = 0x4a004124,
+   .cm_autoidle_dpll_core = 0x4a004128,
+   .cm_clksel_dpll_core = 0x4a00412c,
+   .cm_div_m2_dpll_core = 0x4a004130,
+   .cm_div_m3_dpll_core = 0x4a004134,
+   .cm_div_h11_dpll_core = 0x4a004138,
+   .cm_div_h12_dpll_core = 0x4a00413c,
+   .cm_div_h13_dpll_core = 0x4a004140,
+   .cm_div_h14_dpll_core = 0x4a004144,
+   .cm_ssc_deltamstep_dpll_core = 0x4a004148,
+   .cm_ssc_modfreqdiv_dpll_core = 0x4a00414c,
+   .cm_div_h21_dpll_core = 0x4a004150,
+   .cm_div_h22_dpllcore = 0x4a004154,
+   .cm_div_h23_dpll_core = 0x4a004158,
+   .cm_div_h24_dpll_core = 0x4a00415c,
+   .cm_clkmode_dpll_mpu = 0x4a004160,
+   .cm_idlest_dpll_mpu = 0x4a004164,
+   .cm_autoidle_dpll_mpu = 0x4a004168,
+   .cm_clksel_dpll_mpu = 0x4a00416c,
+   .cm_div_m2_dpll_mpu = 0x4a004170,
+   .cm_ssc_deltamstep_dpll_mpu = 0x4a004188,
+   .cm_ssc_modfreqdiv_dpll_mpu = 0x4a00418c,
+   .cm_bypclk_dpll_mpu = 0x4a00419c,
+   .cm_clkmode_dpll_iva = 0x4a0041a0,
+   .cm_idlest_dpll_iva = 0x4a0041a4,
+   .cm_autoidle_dpll_iva = 0x4a0041a8,
+   .cm_clksel_dpll_iva = 0x4a0041ac,
+   .cm_div_h11_dpll_iva = 0x4a0041b8,
+   .cm_div_h12_dpll_iva = 0x4a0041bc,
+   .cm_ssc_deltamstep_dpll_iva = 0x4a0041c8,
+   .cm_ssc_modfreqdiv_dpll_iva = 0x4a0041cc,
+   .cm_bypclk_dpll_iva = 0x4a0041dc,
+   .cm_clkmode_dpll_abe = 0x4a0041e0,
+   .cm_idlest_dpll_abe = 0x4a0041e4,
+   .cm_autoidle_dpll_abe = 0x4a0041e8,
+   .cm_clksel_dpll_abe = 0x4a0041ec,
+   .cm_div_m2_dpll_abe = 0x4a0041f0,
+   .cm_div_m3_dpll_abe = 0x4a0041f4,
+   .cm_ssc_deltamstep_dpll_abe = 0x4a004208,
+   .cm_ssc_modfreqdiv_dpll_abe = 0x4a00420c,
+   .cm_clkmode_dpll_ddrphy = 0x4a004220,
+   .cm_idlest_dpll_ddrphy = 0x4a004224,
+   .cm_autoidle_dpll_ddrphy = 0x4a004228,
+   .cm_clksel_dpll_ddrphy = 0x4a00422c,
+   .cm_div_m2_dpll_ddrphy = 0x4a004230,
+   .cm_div_h11_dpll_ddrphy = 0x4a004238,
+   .cm_div_h12_dpll_ddrphy = 0x4a00423c,
+   .cm_div_h13_dpll_ddrphy = 0x4a004240,
+   .cm_ssc_deltamstep_dpll_ddrphy = 0x4a004248,
+   .cm_shadow_freq_config1 = 0x4a004260,
+   .cm_mpu_mpu_clkctrl = 0x4a004320,
+
+   /* cm1.dsp */
+   .cm_dsp_clkstctrl = 0x4a004400,
+   .cm_dsp_dsp_clkctrl = 0x4a004420,
+
+   /* cm1.abe */
+   .cm1_abe_clkstctrl = 0x4a004500,
+   .cm1_abe_l4abe_clkctrl = 0x4a004520,
+   .cm1_abe_aess_clkctrl = 0x4a004528,
+   .cm1_abe_pdm_clkctrl = 0x4a004530,
+   .cm1_abe_dmic_clkctrl = 0x4a004538,
+   .cm1_abe_mcasp_clkctrl = 0x4a004540,
+   .cm1_abe_mcbsp1_clkctrl = 0x4a004548,
+   .cm1_abe_mcbsp2_clkctrl = 0x4a004550,
+   .cm1_abe_mcbsp3_clkctrl = 0x4a004558,
+   .cm1_abe_slimbus_clkctrl = 0x4a004560,
+   .cm1_abe_timer5_clkctrl = 0x4a004568,
+   .cm1_abe_timer6_clkctrl = 0x4a004570,
+   .cm1_abe_timer7_clkctrl = 0x4a004578,
+   .cm1_abe_timer8_clkctrl = 0x4a004580,
+   .cm1_abe_wdt3_clkctrl = 0x4a004588,
+
+
+
+   /* cm2.ckgen */
+   .cm_clksel_mpu_m3_iss_root = 0x4a008100,
+   .cm_clksel_usb_60mhz = 0x4a008104,
+   .cm_scale_fclk = 0x4a008108,
+   .cm_core_dvfs_perf1 = 0x4a008110,
+   .cm_core_dvfs_perf2 = 0x4a008114,
+   .cm_core_dvfs_perf3 = 0x4a008118,
+ 

[U-Boot] [PATCH V3 1/5] ARM: OMAP5: Add silicon id support for ES2.0 revision.

2013-02-12 Thread R Sricharan
Adding the CPU detection suport for OMAP5430 and
OMAP5432 ES2.0 SOCs.

Signed-off-by: R Sricharan 
Cc: Tom Rini 
Cc: Nishanth Menon 
---
 [v2] Addressed Tom Rini's  comments
 [v3] Changed the patch to use CONTROL_ID_CODE first
  and then arm revision if nessecary.

 arch/arm/cpu/armv7/omap5/hwinit.c  |   27 ---
 arch/arm/include/asm/arch-omap5/omap.h |2 ++
 arch/arm/include/asm/armv7.h   |1 +
 arch/arm/include/asm/omap_common.h |2 ++
 4 files changed, 21 insertions(+), 11 deletions(-)

diff --git a/arch/arm/cpu/armv7/omap5/hwinit.c 
b/arch/arm/cpu/armv7/omap5/hwinit.c
index dfc0e44..8e66a96 100644
--- a/arch/arm/cpu/armv7/omap5/hwinit.c
+++ b/arch/arm/cpu/armv7/omap5/hwinit.c
@@ -204,17 +204,22 @@ void init_omap_revision(void)
 */
unsigned int rev = cortex_rev();
 
-   switch (rev) {
-   case MIDR_CORTEX_A15_R0P0:
-   switch (readl(CONTROL_ID_CODE)) {
-   case OMAP5430_CONTROL_ID_CODE_ES1_0:
-   *omap_si_rev = OMAP5430_ES1_0;
-   break;
-   case OMAP5432_CONTROL_ID_CODE_ES1_0:
-   default:
-   *omap_si_rev = OMAP5432_ES1_0;
-   break;
-   }
+   switch (readl(CONTROL_ID_CODE)) {
+   case OMAP5430_CONTROL_ID_CODE_ES1_0:
+   *omap_si_rev = OMAP5430_ES1_0;
+   if (rev == MIDR_CORTEX_A15_R2P2)
+   *omap_si_rev = OMAP5430_ES2_0;
+   break;
+   case OMAP5432_CONTROL_ID_CODE_ES1_0:
+   *omap_si_rev = OMAP5432_ES1_0;
+   if (rev == MIDR_CORTEX_A15_R2P2)
+   *omap_si_rev = OMAP5432_ES2_0;
+   break;
+   case OMAP5430_CONTROL_ID_CODE_ES2_0:
+   *omap_si_rev = OMAP5430_ES2_0;
+   break;
+   case OMAP5432_CONTROL_ID_CODE_ES2_0:
+   *omap_si_rev = OMAP5432_ES2_0;
break;
default:
*omap_si_rev = OMAP5430_SILICON_ID_INVALID;
diff --git a/arch/arm/include/asm/arch-omap5/omap.h 
b/arch/arm/include/asm/arch-omap5/omap.h
index 873ccd7..71935d8 100644
--- a/arch/arm/include/asm/arch-omap5/omap.h
+++ b/arch/arm/include/asm/arch-omap5/omap.h
@@ -57,7 +57,9 @@
 
 /* To be verified */
 #define OMAP5430_CONTROL_ID_CODE_ES1_0 0x0B94202F
+#define OMAP5430_CONTROL_ID_CODE_ES2_0  0x1B94202F
 #define OMAP5432_CONTROL_ID_CODE_ES1_0 0x0B99802F
+#define OMAP5432_CONTROL_ID_CODE_ES2_0  0x1B99802F
 
 /* STD_FUSE_PROD_ID_1 */
 #define STD_FUSE_PROD_ID_1 (CTRL_BASE + 0x218)
diff --git a/arch/arm/include/asm/armv7.h b/arch/arm/include/asm/armv7.h
index ad9a875..a73630b 100644
--- a/arch/arm/include/asm/armv7.h
+++ b/arch/arm/include/asm/armv7.h
@@ -33,6 +33,7 @@
 
 /* Cortex-A15 revisions */
 #define MIDR_CORTEX_A15_R0P0   0x410FC0F0
+#define MIDR_CORTEX_A15_R2P2   0x412FC0F2
 
 /* CCSIDR */
 #define CCSIDR_LINE_SIZE_OFFSET0
diff --git a/arch/arm/include/asm/omap_common.h 
b/arch/arm/include/asm/omap_common.h
index 2115687..4599167 100644
--- a/arch/arm/include/asm/omap_common.h
+++ b/arch/arm/include/asm/omap_common.h
@@ -542,4 +542,6 @@ static inline u32 omap_revision(void)
 #define OMAP5430_SILICON_ID_INVALID0
 #define OMAP5430_ES1_0 0x54300100
 #define OMAP5432_ES1_0 0x54320100
+#define OMAP5430_ES2_0  0x54300200
+#define OMAP5432_ES2_0  0x54320200
 #endif /* _OMAP_COMMON_H_ */
-- 
1.7.9.5

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


[U-Boot] [PATCH V3 0/5] ARM: OMAP5: Add support for OMAP543x ES2.0 Socs

2013-02-12 Thread R Sricharan
ES2.0 is the latest silicon revision for OMAP543X socs. The SOC
supports enhanced opps for MPU (up to 1.5GHz). This series essentially
adds the support for both 5430 and 5432 versions.

This is on top of the below U-Boot cleanup series.
 http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/152834

Both the cleanup and ES2.0 support series against mainline is available
here
 git://gitorious.org/u-boot-shared/u-boot.git omap5_es2

Lokesh Vutla (2):
  ARM: OMAP5: Add DDR changes required for OMAP543X ES2.0 SOCs
  ARM: OMAP5: srcomp: enable slew rate compensation cells after powerup

R Sricharan (3):
  ARM: OMAP5: Add silicon id support for ES2.0 revision.
  ARM: OMAP5: clock: Add the prcm register changes required for ES2.0
  ARM: OMAP5: clocks: Add OPP settings required for OMAP543X ES2.0 soc

 arch/arm/cpu/armv7/omap-common/clocks-common.c |9 +-
 arch/arm/cpu/armv7/omap-common/hwinit-common.c |6 +
 arch/arm/cpu/armv7/omap4/hw_data.c |  164 +++---
 arch/arm/cpu/armv7/omap5/hw_data.c |  254 +
 arch/arm/cpu/armv7/omap5/hwinit.c  |  143 +++-
 arch/arm/cpu/armv7/omap5/prcm-regs.c   |  286 
 arch/arm/cpu/armv7/omap5/sdram.c   |   75 ++-
 arch/arm/include/asm/arch-omap5/clocks.h   |   39 +++-
 arch/arm/include/asm/arch-omap5/omap.h |   27 +++
 arch/arm/include/asm/arch-omap5/sys_proto.h|1 +
 arch/arm/include/asm/armv7.h   |1 +
 arch/arm/include/asm/emif.h|1 +
 arch/arm/include/asm/omap_common.h |   14 +-
 13 files changed, 828 insertions(+), 192 deletions(-)

-- 
1.7.9.5

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


Re: [U-Boot] [PATCH v5 3/3] SPL: Change description for spl command

2013-02-12 Thread Andreas Bießmann
Dear Stefano Babic,

On 02/12/2013 09:38 AM, Stefano Babic wrote:
> Add a more descriptive text to the help of the spl
> command.
> 
> Signed-off-by: Stefano Babic 
> ---
> Changes in v5: None
> Changes in v4: None
> Changes in v3: None

That is not correct, there where changes since v3, this patch was
introduced in v2.

> Changes in v2: None

However, no complaints on the patch content.

Acked-by: Andreas Bießmann 

Best regards

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


Re: [U-Boot] [PATCH v2 1/2] Tegra: fdt: Add/enhance sdhci (mmc) nodes for all T20 DT files

2013-02-12 Thread Thierry Reding
On Tue, Feb 12, 2013 at 11:41:09AM +0100, Thierry Reding wrote:
> On Tue, Feb 12, 2013 at 07:51:55AM +0100, Thierry Reding wrote:
> > On Mon, Feb 11, 2013 at 12:21:59PM -0700, Tom Warren wrote:
> > > Thierry/Lucas,
> > > 
> > > On Mon, Feb 11, 2013 at 12:11 PM, Thierry Reding
> > >  wrote:
> > > > On Mon, Feb 11, 2013 at 10:56:33AM -0700, Tom Warren wrote:
> > > >> Lucas,
> > > >>
> > > >> On Mon, Feb 11, 2013 at 10:28 AM, Lucas Stach  wrote:
> > > >> > Hi Tom,
> > > >> >
> > > >> > Am Montag, den 11.02.2013, 10:17 -0700 schrieb Tom Warren:
> > > >> >> Linux dts files were used for those boards that didn't already
> > > >> >> have sdhci info populated. Tamonten has their own dtsi file with
> > > >> >> common sdhci nodes (sourced from Linux).
> > > >> >>
> > > >> >> Signed-off-by: Tom Warren 
> > > >> >> ---
> > > >> >> v2:
> > > >> >> - cleanup comments in dts files/match w/kernel files
> > > >> >> - add sdhci aliases in all dts files
> > > >> >> - use tegra20-tamonten.dtsi from the kernel for AD boards
> > > >> >>
> > > >> >>  arch/arm/dts/tegra20-tamonten.dtsi   |  489 
> > > >> >> ++
> > > >> >
> > > >> > I'm not sure if pushing the whole file in this patch is the right 
> > > >> > thing
> > > >> > to do.
> > > >>
> > > >> I didn't want to edit it since we seem to be moving towards using the
> > > >> Linux DTS files in toto in U-Boot (as per Stephen & Simon). Does it do
> > > >> any harm to have the whole thing here? Saves some work later. Thierry
> > > >> - what do you think?
> > > >
> > > > Given that it isn't used anywhere I don't think we really need it right
> > > > now. We can always add it later when we can make better use of it.
> > > 
> > > It actually is used (for SDMMC/sdhci) now, Thierry. That's why it's in
> > > this patchset.
> > 
> > Right, I hadn't looked at that patch yet.
> > 
> > > I had originally put the sdhci node for Avionic Design
> > > boards in their respective .dts files, but Stephen pointed out that
> > > the kernel had a tegra20-tamonten.dtsi file with common info, which
> > > included the sdhci node, and asked that I use it, instead, so we echo
> > > the kernel layout. So I pulled that file into my MMC DT patchset, and
> > > used it in all AD board builds (medcom/tec/plutux) - it's pulled in
> > > via an override of CONFIG_ARCH_DEVICE_TREE in the config files.
> > > 
> > > So the options seem to be:
> > > 
> > > a) Don't use the tamonton dtsi file, and put the sdhci nodes in the AD
> > > dts files, just like all other boards (this was my V1 approach).
> > > Vetoed by Stephen.
> > > b) Use tegra20-tamonten.dtsi as is, identical to the kernel file. If
> > > necessary, I can move it's inclusion to a separate patch, independent
> > > of the MMC DT patchset, as suggested by Lucas.
> > > c) Use tegra20-tamonten.dtsi, but just with the sdhci node (is this
> > > what you're suggesting, Thierry?). I'd still pull it in via a
> > > CONFIG_ARCH_DEVICE_TREE #define in the AD config files.
> > > 
> > > Let me know ASAP - I'd like to get V3 upstreamed soon so I can move on
> > > to work on the T30/T114 MMC patches.
> > 
> > I think option b) sounds fine given that we want to move to the same DTS
> > as the kernel eventually anyway. So for the Tamonten (and AD board)
> > pieces, consider this:
> > 
> > Acked-by: Thierry Reding 
> > 
> > I can't give you a Tested-by because I have a bunch of other things to
> > take care of and I probably won't get to testing this for a few days.
> 
> So it turned out that I need to touch U-Boot anyway, so I decided to
> give this a spin. I noticed that overriding CONFIG_ARCH_DEVICE_TREE from
> the board configuration file doesn't work currently. What happens is
> that the autoconf.mk (which is derived from the board configuration) is
> included before the CPU config.mk which sets CONFIG_ARCH_DEVICE_TREE to
> tegra20 (or tegra30, tegra114). I came up with the attached patch to set
> the variable if not set previously (by the board configuration file).
> 
> Feel free to squash that in your patch series if you deem it a proper
> solution. I can also provide a proper separate patch if you prefer.
> 
> Thierry

> diff --git a/arch/arm/cpu/armv7/tegra114/config.mk 
> b/arch/arm/cpu/armv7/tegra114/config.mk
> index cb1a19d..e7c22c0 100644
> --- a/arch/arm/cpu/armv7/tegra114/config.mk
> +++ b/arch/arm/cpu/armv7/tegra114/config.mk
> @@ -16,4 +16,4 @@
>  # You should have received a copy of the GNU General Public License
>  # along with this program.  If not, see .
>  #
> -CONFIG_ARCH_DEVICE_TREE := tegra114
> +CONFIG_ARCH_DEVICE_TREE ?= tegra114
> diff --git a/arch/arm/cpu/armv7/tegra20/config.mk 
> b/arch/arm/cpu/armv7/tegra20/config.mk
> index 6432e75..9042664 100644
> --- a/arch/arm/cpu/armv7/tegra20/config.mk
> +++ b/arch/arm/cpu/armv7/tegra20/config.mk
> @@ -23,4 +23,4 @@
>  # Foundation, Inc., 59 Temple Place, Suite 330, Boston,
>  # MA 02111-1307 USA
>  #
> -CONFIG_ARCH_DEVICE_TREE := tegra20

Re: [U-Boot] [PATCH v2 1/2] Tegra: fdt: Add/enhance sdhci (mmc) nodes for all T20 DT files

2013-02-12 Thread Thierry Reding
On Tue, Feb 12, 2013 at 07:51:55AM +0100, Thierry Reding wrote:
> On Mon, Feb 11, 2013 at 12:21:59PM -0700, Tom Warren wrote:
> > Thierry/Lucas,
> > 
> > On Mon, Feb 11, 2013 at 12:11 PM, Thierry Reding
> >  wrote:
> > > On Mon, Feb 11, 2013 at 10:56:33AM -0700, Tom Warren wrote:
> > >> Lucas,
> > >>
> > >> On Mon, Feb 11, 2013 at 10:28 AM, Lucas Stach  wrote:
> > >> > Hi Tom,
> > >> >
> > >> > Am Montag, den 11.02.2013, 10:17 -0700 schrieb Tom Warren:
> > >> >> Linux dts files were used for those boards that didn't already
> > >> >> have sdhci info populated. Tamonten has their own dtsi file with
> > >> >> common sdhci nodes (sourced from Linux).
> > >> >>
> > >> >> Signed-off-by: Tom Warren 
> > >> >> ---
> > >> >> v2:
> > >> >> - cleanup comments in dts files/match w/kernel files
> > >> >> - add sdhci aliases in all dts files
> > >> >> - use tegra20-tamonten.dtsi from the kernel for AD boards
> > >> >>
> > >> >>  arch/arm/dts/tegra20-tamonten.dtsi   |  489 
> > >> >> ++
> > >> >
> > >> > I'm not sure if pushing the whole file in this patch is the right thing
> > >> > to do.
> > >>
> > >> I didn't want to edit it since we seem to be moving towards using the
> > >> Linux DTS files in toto in U-Boot (as per Stephen & Simon). Does it do
> > >> any harm to have the whole thing here? Saves some work later. Thierry
> > >> - what do you think?
> > >
> > > Given that it isn't used anywhere I don't think we really need it right
> > > now. We can always add it later when we can make better use of it.
> > 
> > It actually is used (for SDMMC/sdhci) now, Thierry. That's why it's in
> > this patchset.
> 
> Right, I hadn't looked at that patch yet.
> 
> > I had originally put the sdhci node for Avionic Design
> > boards in their respective .dts files, but Stephen pointed out that
> > the kernel had a tegra20-tamonten.dtsi file with common info, which
> > included the sdhci node, and asked that I use it, instead, so we echo
> > the kernel layout. So I pulled that file into my MMC DT patchset, and
> > used it in all AD board builds (medcom/tec/plutux) - it's pulled in
> > via an override of CONFIG_ARCH_DEVICE_TREE in the config files.
> > 
> > So the options seem to be:
> > 
> > a) Don't use the tamonton dtsi file, and put the sdhci nodes in the AD
> > dts files, just like all other boards (this was my V1 approach).
> > Vetoed by Stephen.
> > b) Use tegra20-tamonten.dtsi as is, identical to the kernel file. If
> > necessary, I can move it's inclusion to a separate patch, independent
> > of the MMC DT patchset, as suggested by Lucas.
> > c) Use tegra20-tamonten.dtsi, but just with the sdhci node (is this
> > what you're suggesting, Thierry?). I'd still pull it in via a
> > CONFIG_ARCH_DEVICE_TREE #define in the AD config files.
> > 
> > Let me know ASAP - I'd like to get V3 upstreamed soon so I can move on
> > to work on the T30/T114 MMC patches.
> 
> I think option b) sounds fine given that we want to move to the same DTS
> as the kernel eventually anyway. So for the Tamonten (and AD board)
> pieces, consider this:
> 
>   Acked-by: Thierry Reding 
> 
> I can't give you a Tested-by because I have a bunch of other things to
> take care of and I probably won't get to testing this for a few days.

So it turned out that I need to touch U-Boot anyway, so I decided to
give this a spin. I noticed that overriding CONFIG_ARCH_DEVICE_TREE from
the board configuration file doesn't work currently. What happens is
that the autoconf.mk (which is derived from the board configuration) is
included before the CPU config.mk which sets CONFIG_ARCH_DEVICE_TREE to
tegra20 (or tegra30, tegra114). I came up with the attached patch to set
the variable if not set previously (by the board configuration file).

Feel free to squash that in your patch series if you deem it a proper
solution. I can also provide a proper separate patch if you prefer.

Thierry
diff --git a/arch/arm/cpu/armv7/tegra114/config.mk 
b/arch/arm/cpu/armv7/tegra114/config.mk
index cb1a19d..e7c22c0 100644
--- a/arch/arm/cpu/armv7/tegra114/config.mk
+++ b/arch/arm/cpu/armv7/tegra114/config.mk
@@ -16,4 +16,4 @@
 # You should have received a copy of the GNU General Public License
 # along with this program.  If not, see .
 #
-CONFIG_ARCH_DEVICE_TREE := tegra114
+CONFIG_ARCH_DEVICE_TREE ?= tegra114
diff --git a/arch/arm/cpu/armv7/tegra20/config.mk 
b/arch/arm/cpu/armv7/tegra20/config.mk
index 6432e75..9042664 100644
--- a/arch/arm/cpu/armv7/tegra20/config.mk
+++ b/arch/arm/cpu/armv7/tegra20/config.mk
@@ -23,4 +23,4 @@
 # Foundation, Inc., 59 Temple Place, Suite 330, Boston,
 # MA 02111-1307 USA
 #
-CONFIG_ARCH_DEVICE_TREE := tegra20
+CONFIG_ARCH_DEVICE_TREE ?= tegra20
diff --git a/arch/arm/cpu/armv7/tegra30/config.mk 
b/arch/arm/cpu/armv7/tegra30/config.mk
index 719ca81..0035bc5 100644
--- a/arch/arm/cpu/armv7/tegra30/config.mk
+++ b/arch/arm/cpu/armv7/tegra30/config.mk
@@ -16,4 +16,4 @@
 # You should have received a c

Re: [U-Boot] [PATCH] usb: ehci: exynos: Enable non-dt path

2013-02-12 Thread Vivek Gautam
Hi Minkyu,


On Tue, Feb 12, 2013 at 1:54 PM, Minkyu Kang  wrote:
> Dear Vivek,
>
> On 11/01/13 18:24, Vivek Gautam wrote:
>> Enabling the non-dt path for the driver so that
>> we don't get any build errors for non-dt configuration.
>>
>> Signed-off-by: Vivek Gautam 
>> ---
>>
>> Earlier we had moved to fdt support for ehci-exynos driver, but
>> missed out the non-dt path. Although this driver serves for exysno5
>> onward only but better to keep the non-dt path also available.
>>
>>  drivers/usb/host/ehci-exynos.c |   10 ++
>>  1 files changed, 10 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
>> index 3ca4c5c..6f0c6c3 100644
>> --- a/drivers/usb/host/ehci-exynos.c
>> +++ b/drivers/usb/host/ehci-exynos.c
>> @@ -153,7 +153,12 @@ int ehci_hcd_init(int index, struct ehci_hccr **hccr, 
>> struct ehci_hcor **hcor)
>>   return -ENOMEM;
>>   }
>>
>> +#ifdef CONFIG_OF_CONTROL
>>   exynos_usb_parse_dt(gd->fdt_blob, exynos);
>> +#else
>> + exynos->usb = (struct exynos_usb_phy *)samsung_get_base_usb_phy();
>> + exynos->hcd = samsung_get_base_usb_ehci();
>> +#endif
>>
>>   setup_usb_phy(exynos->usb);
>>
>> @@ -185,7 +190,12 @@ int ehci_hcd_stop(int index)
>>   return -ENOMEM;
>>   }
>>
>> +#ifdef CONFIG_OF_CONTROL
>>   exynos_usb_parse_dt(gd->fdt_blob, exynos);
>> +#else
>> + exynos->usb = (struct exynos_usb_phy *)samsung_get_base_usb_phy();
>> + exynos->hcd = samsung_get_base_usb_ehci();
>> +#endif
>>
>>   reset_usb_phy(exynos->usb);
>>
>>
>
> Patch looks good.
> But I've got compiler warnings and errors when I disabled CONFIG_OF_CONTROL.
>
> exynos_spi.c:391:12: warning: 'process_nodes' defined but not used 
> [-Wunused-function]
> ehci-exynos.c: In function 'ehci_hcd_init':
> ehci-exynos.c:160:14: warning: assignment makes pointer from integer without 
> a cast [enabled by default]
> ehci-exynos.c: In function 'ehci_hcd_stop':
> ehci-exynos.c:197:14: warning: assignment makes pointer from integer without 
> a cast [enabled by default]
> ehci-exynos.c: At top level:
> ehci-exynos.c:48:12: warning: 'exynos_usb_parse_dt' defined but not used 
> [-Wunused-function]
> /opt/eldk-5.2/armv7a/sysroots/i686-eldk-linux/usr/bin/armv7a-vfp-neon-linux-gnueabi/arm-linux-gnueabi-ld.bfd:/home/share/Work/u-boot-samsung/spl/u-boot-spl.lds:1:
>  ignoring invalid character `#' in expression
> /opt/eldk-5.2/armv7a/sysroots/i686-eldk-linux/usr/bin/armv7a-vfp-neon-linux-gnueabi/arm-linux-gnueabi-ld.bfd:/home/share/Work/u-boot-samsung/spl/u-boot-spl.lds:1:
>  syntax error
> make[1]: *** [/home/share/Work/u-boot-samsung/spl/u-boot-spl] Error 1
> make: *** [spl/u-boot-spl.bin] Error 2
> make: *** Waiting for unfinished jobs
> smdk5250.c: In function 'board_eth_init':
> smdk5250.c:152:6: warning: unused variable 'node' [-Wunused-variable]
>
> Could you please check this issue also?
>

Sure, will check this, and resolve the underlying issue.


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


[U-Boot] [PATCH v2 4/4] arm:trats: Use new ums command

2013-02-12 Thread Piotr Wilczek
From: Lukasz Majewski 

This patch enables new "ums" command on Trats board

Signed-off-by: Lukasz Majewski 
Signed-off-by: Piotr Wilczek 
Signed-off-by: Kyungmin Park 
CC: Minkyu Kang 
---
Changes in v2: None

 board/samsung/trats/trats.c |   63 +++
 include/configs/trats.h |5 
 2 files changed, 68 insertions(+)

diff --git a/board/samsung/trats/trats.c b/board/samsung/trats/trats.c
index 88d193d..9207646 100644
--- a/board/samsung/trats/trats.c
+++ b/board/samsung/trats/trats.c
@@ -42,6 +42,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "setup.h"
 
@@ -791,3 +792,65 @@ void init_panel_info(vidinfo_t *vid)
 
setenv("lcdinfo", "lcd=s6e8ax0");
 }
+
+#ifdef CONFIG_USB_GADGET_MASS_STORAGE
+static int ums_read_sector(struct ums_device *ums_dev,
+  ulong start, lbaint_t blkcnt, void *buf)
+{
+   if (ums_dev->mmc->block_dev.block_read(ums_dev->dev_num,
+   start + ums_dev->offset, blkcnt, buf) != blkcnt)
+   return -1;
+
+   return 0;
+}
+
+static int ums_write_sector(struct ums_device *ums_dev,
+   ulong start, lbaint_t blkcnt, const void *buf)
+{
+   if (ums_dev->mmc->block_dev.block_write(ums_dev->dev_num,
+   start + ums_dev->offset, blkcnt, buf) != blkcnt)
+   return -1;
+
+   return 0;
+}
+
+static void ums_get_capacity(struct ums_device *ums_dev,
+long long int *capacity)
+{
+   long long int tmp_capacity;
+
+   tmp_capacity = (long long int) ((ums_dev->offset + ums_dev->part_size)
+   * SECTOR_SIZE);
+   *capacity = ums_dev->mmc->capacity - tmp_capacity;
+}
+
+static struct ums_board_info ums_board = {
+   .read_sector = ums_read_sector,
+   .write_sector = ums_write_sector,
+   .get_capacity = ums_get_capacity,
+   .name = "TRATS UMS disk",
+   .ums_dev = {
+   .mmc = NULL,
+   .dev_num = 0,
+   .offset = 0,
+   .part_size = 0.
+   },
+};
+
+struct ums_board_info *board_ums_init(unsigned int dev_num, unsigned int 
offset,
+ unsigned int part_size)
+{
+   struct mmc *mmc;
+
+   mmc = find_mmc_device(dev_num);
+   if (!mmc)
+   return NULL;
+
+   ums_board.ums_dev.mmc = mmc;
+   ums_board.ums_dev.dev_num = dev_num;
+   ums_board.ums_dev.offset = offset;
+   ums_board.ums_dev.part_size = part_size;
+
+   return &ums_board;
+}
+#endif
diff --git a/include/configs/trats.h b/include/configs/trats.h
index 63745ac..31d8190 100644
--- a/include/configs/trats.h
+++ b/include/configs/trats.h
@@ -316,4 +316,9 @@
 #define CONFIG_VIDEO_BMP_GZIP
 #define CONFIG_SYS_VIDEO_LOGO_MAX_SIZE ((500 * 120 * 4) + (1 << 12))
 
+#define CONFIG_CMD_USB_MASS_STORAGE
+#if defined(CONFIG_CMD_USB_MASS_STORAGE)
+#define CONFIG_USB_GADGET_MASS_STORAGE
+#endif
+
 #endif /* __CONFIG_H */
-- 
1.7.9.5

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


[U-Boot] [PATCH v2 3/4] usb:gadget: USB Mass Storage Gadget support

2013-02-12 Thread Piotr Wilczek
From: Lukasz Majewski 

This patch adds the USB Mass Storage Gadget to u-boot
New command called "ums" is implemented to provide access
to on-device embedded persistent memory.

USB Mass Storage is supposed to work on top of the USB
Gadget framework

Signed-off-by: Lukasz Majewski 
Signed-off-by: Piotr Wilczek 
Signed-off-by: Kyungmin Park 
CC: Marek Vasut 
---
Changes in v2: None

 common/Makefile   |1 +
 common/cmd_usb_mass_storage.c |   86 +
 drivers/usb/gadget/g_dnl.c|6 +++
 include/usb_mass_storage.h|   55 ++
 4 files changed, 148 insertions(+)
 create mode 100644 common/cmd_usb_mass_storage.c
 create mode 100644 include/usb_mass_storage.h

diff --git a/common/Makefile b/common/Makefile
index 54fcc81..8ec95d2 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -174,6 +174,7 @@ COBJS-y += cmd_usb.o
 COBJS-y += usb.o usb_hub.o
 COBJS-$(CONFIG_USB_STORAGE) += usb_storage.o
 endif
+COBJS-$(CONFIG_CMD_USB_MASS_STORAGE) += cmd_usb_mass_storage.o
 COBJS-$(CONFIG_CMD_XIMG) += cmd_ximg.o
 COBJS-$(CONFIG_YAFFS2) += cmd_yaffs2.o
 COBJS-$(CONFIG_CMD_SPL) += cmd_spl.o
diff --git a/common/cmd_usb_mass_storage.c b/common/cmd_usb_mass_storage.c
new file mode 100644
index 000..87a5f2f
--- /dev/null
+++ b/common/cmd_usb_mass_storage.c
@@ -0,0 +1,86 @@
+/*
+ * Copyright (C) 2011 Samsung Electronics
+ * Lukasz Majewski 
+ *
+ * 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 
+
+int do_usb_mass_storage(cmd_tbl_t *cmdtp, int flag,
+  int argc, char * const argv[])
+{
+   char *ep;
+   unsigned int dev_num = 0, offset = 0, part_size = 0;
+   int rc;
+
+   struct ums_board_info *ums_info;
+   static char *s = "ums";
+
+   if (argc < 2) {
+   printf("usage: ums  - e.g. ums 0\n");
+   return 0;
+   }
+
+   dev_num = (int)simple_strtoul(argv[1], &ep, 16);
+
+   if (dev_num) {
+   puts("\nSet eMMC device to 0! - e.g. ums 0\n");
+   goto fail;
+   }
+
+   board_usb_init();
+   ums_info = board_ums_init(dev_num, offset, part_size);
+
+   if (!ums_info) {
+   printf("MMC: %d -> NOT available\n", dev_num);
+   goto fail;
+   }
+   rc = fsg_init(ums_info);
+   if (rc) {
+   printf("cmd ums: fsg_init failed\n");
+   goto fail;
+   }
+
+   g_dnl_register(s);
+
+   while (1) {
+   /* Handle control-c and timeouts */
+   if (ctrlc()) {
+   printf("The remote end did not respond in time.\n");
+   goto exit;
+   }
+   usb_gadget_handle_interrupts();
+   /* Check if USB cable has been detached */
+   if (fsg_main_thread(NULL) == EIO)
+   goto exit;
+   }
+exit:
+   g_dnl_unregister();
+   return 0;
+
+fail:
+   return -1;
+}
+
+U_BOOT_CMD(ums, CONFIG_SYS_MAXARGS, 1, do_usb_mass_storage,
+   "Use the UMS [User Mass Storage]",
+   "ums - User Mass Storage Gadget"
+);
diff --git a/drivers/usb/gadget/g_dnl.c b/drivers/usb/gadget/g_dnl.c
index a5a4c1f..cc3f344 100644
--- a/drivers/usb/gadget/g_dnl.c
+++ b/drivers/usb/gadget/g_dnl.c
@@ -31,6 +31,7 @@
 
 #include "gadget_chips.h"
 #include "composite.c"
+#include "f_mass_storage.c"
 
 /*
  * One needs to define the following:
@@ -104,6 +105,8 @@ static int g_dnl_do_config(struct usb_configuration *c)
printf("GADGET DRIVER: %s\n", s);
if (!strcmp(s, "usb_dnl_dfu"))
ret = dfu_add(c);
+   else if (!strcmp(s, "usb_dnl_ums"))
+   ret = fsg_add(c);
 
return ret;
 }
@@ -188,6 +191,9 @@ int g_dnl_register(const char *type)
if (!strcmp(type, "dfu")) {
strcpy(name, shortname);
strcat(name, type);
+   } else if (!strcmp(type, "ums")) {
+   strcpy(name, shortname);
+   strcat(name, type);
} else {
printf("%s: unknown command: %s\n", __func__, type);
return -EINVAL;
diff --git a/include/usb_mass_storage.h b/include/usb_mass_storage.h
new file mode 100644
index 000..ffc3a13
---

[U-Boot] [PATCH v2 1/4] usb:composite: USB Mass Storage - storage_common.c from Linux kernel

2013-02-12 Thread Piotr Wilczek
From: Lukasz Majewski 

The storage_common.c source file from v2.6.36 Linux kernel.

commit d26a6aa08b9f12b44fb1ee65625e7480d3d5bb81
Author: Michal Nazarewicz 
Date:   Mon Nov 9 14:15:23 2009 +0100

USB: g_mass_storage: code cleaned up and comments updated

Signed-off-by: Lukasz Majewski 
Signed-off-by: Andrzej Pietrasiewicz 
Signed-off-by: Kyungmin Park 
CC: Marek Vasut 
---
Changes in v2: None

 drivers/usb/gadget/storage_common.c |  653 +++
 1 file changed, 653 insertions(+)
 create mode 100644 drivers/usb/gadget/storage_common.c

diff --git a/drivers/usb/gadget/storage_common.c 
b/drivers/usb/gadget/storage_common.c
new file mode 100644
index 000..594dc10
--- /dev/null
+++ b/drivers/usb/gadget/storage_common.c
@@ -0,0 +1,653 @@
+/*
+ * storage_common.c -- Common definitions for mass storage functionality
+ *
+ * Copyright (C) 2003-2008 Alan Stern
+ * Copyeight (C) 2009 Samsung Electronics
+ * Author: Michal Nazarewicz (m.nazarew...@samsung.com)
+ *
+ * Ported to u-boot:
+ * Andrzej Pietrasiewicz 
+ *
+ * Code refactoring & cleanup:
+ * Łukasz Majewski 
+ *
+ * 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
+ */
+
+
+/*
+ * This file requires the following identifiers used in USB strings to
+ * be defined (each of type pointer to char):
+ *  - fsg_string_manufacturer -- name of the manufacturer
+ *  - fsg_string_product  -- name of the product
+ *  - fsg_string_serial   -- product's serial
+ *  - fsg_string_config   -- name of the configuration
+ *  - fsg_string_interface-- name of the interface
+ * The first four are only needed when FSG_DESCRIPTORS_DEVICE_STRINGS
+ * macro is defined prior to including this file.
+ */
+
+/*
+ * When FSG_NO_INTR_EP is defined fsg_fs_intr_in_desc and
+ * fsg_hs_intr_in_desc objects as well as
+ * FSG_FS_FUNCTION_PRE_EP_ENTRIES and FSG_HS_FUNCTION_PRE_EP_ENTRIES
+ * macros are not defined.
+ *
+ * When FSG_NO_DEVICE_STRINGS is defined FSG_STRING_MANUFACTURER,
+ * FSG_STRING_PRODUCT, FSG_STRING_SERIAL and FSG_STRING_CONFIG are not
+ * defined (as well as corresponding entries in string tables are
+ * missing) and FSG_STRING_INTERFACE has value of zero.
+ *
+ * When FSG_NO_OTG is defined fsg_otg_desc won't be defined.
+ */
+
+/*
+ * When FSG_BUFFHD_STATIC_BUFFER is defined when this file is included
+ * the fsg_buffhd structure's buf field will be an array of FSG_BUFLEN
+ * characters rather then a pointer to void.
+ */
+
+
+/* #include  */
+
+
+/*
+ * Thanks to NetChip Technologies for donating this product ID.
+ *
+ * DO NOT REUSE THESE IDs with any other driver!!  Ever!!
+ * Instead:  allocate your own, using normal USB-IF procedures.
+ */
+#define FSG_VENDOR_ID  0x0525  /* NetChip */
+#define FSG_PRODUCT_ID 0xa4a5  /* Linux-USB File-backed Storage Gadget */
+
+/*-*/
+
+#ifndef DEBUG
+#undef VERBOSE_DEBUG
+#undef DUMP_MSGS
+#endif /* !DEBUG */
+
+#ifdef VERBOSE_DEBUG
+#define VLDBG  LDBG
+#else
+#define VLDBG(lun, fmt, args...) do { } while (0)
+#endif /* VERBOSE_DEBUG */
+
+/*
+#define LDBG(lun, fmt, args...)   dev_dbg (&(lun)->dev, fmt, ## args)
+#define LERROR(lun, fmt, args...) dev_err (&(lun)->dev, fmt, ## args)
+#define LWARN(lun, fmt, args...)  dev_warn(&(lun)->dev, fmt, ## args)
+#define LINFO(lun, fmt, args...)  dev_info(&(lun)->dev, fmt, ## args)
+*/
+
+#define LDBG(lun, fmt, args...) do { } while (0)
+#define LERROR(lun, fmt, args...) do { } while (0)
+#define LWARN(lun, fmt, args...) do { } while (0)
+#define LINFO(lun, fmt, args...) do { } while (0)
+
+/*
+ * Keep those macros in sync with those in
+ * include/linux/usb/composite.h or else GCC will complain.  If they
+ * are identical (the same names of arguments, white spaces in the
+ * same places) GCC will allow redefinition otherwise (even if some
+ * white space is removed or added) warning will be issued.
+ *
+ * Those macros are needed here because File Storage Gadget does not
+ * include the composite.h header.  For composite gadgets those macros
+ * are redundant since composite.h is included any way.
+ *
+ * One could check whether those macros are already defined (which
+ * would indicate composite.h had been included) or not (which would
+ * indicate we were in FSG) but this is not done because a warning is
+ * 

[U-Boot] [PATCH v2 0/4] usb:gadget: USB Mass Storage Gadget

2013-02-12 Thread Piotr Wilczek
This patch series add support for the USB Mass Storage (UMS)
New "ums" command provide access to on-device persistent memory.

The storage_common.c and f_mass_storage.c source files are
ported from v2.6.36 Linux kernel

Changes in v2:
- removed commented code;

Lukasz Majewski (3):
  usb:composite: USB Mass Storage - storage_common.c from Linux kernel
  usb:gadget: USB Mass Storage Gadget support
  arm:trats: Use new ums command

Piotr Wilczek (1):
  usb:composite: USB Mass Storage - f_mass_storage.c from Linux kernel

 board/samsung/trats/trats.c |   63 +
 common/Makefile |1 +
 common/cmd_usb_mass_storage.c   |   86 ++
 drivers/usb/gadget/f_mass_storage.c | 2793 +++
 drivers/usb/gadget/g_dnl.c  |6 +
 drivers/usb/gadget/storage_common.c |  653 
 include/configs/trats.h |5 +
 include/usb_mass_storage.h  |   55 +
 8 files changed, 3662 insertions(+)
 create mode 100644 common/cmd_usb_mass_storage.c
 create mode 100644 drivers/usb/gadget/f_mass_storage.c
 create mode 100644 drivers/usb/gadget/storage_common.c
 create mode 100644 include/usb_mass_storage.h

-- 
1.7.9.5

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


[U-Boot] [PATCH 2/2 v4] tools: add support for Dove to kwboot

2013-02-12 Thread Luka Perkov
From: Sebastian Hesselbarth 

On Dove mvboot can also be used to boot an u-boot image into RAM.
In contrast to Kirkwood, Dove does not support the UART boot mode
sequence but requires the UART boot mode to be selected through
strap pins. The SolidRun CuBox has a push button to allow uart
boot mode but fails on the boot sequence sent by mvboot.

This patch adds another cmdline option to allow to send a boot
image without the boot sequence and adds support for Dove.

Signed-off-by: Sebastian Hesselbarth 
Signed-off-by: Daniel Stodden 
Signed-off-by: Luka Perkov 
Cc: Prafulla Wadaskar 
Cc: Rabeeh Khoury 
---

changes from v1 to v2:

 * update documentation

changes from v2 to v3:

 * none

changes from v3 to v4:

 * move to separate patch series 
 * fix wrong flag in the man page
 * document Dove support in the header of mvboot.c

 doc/mvboot.1   | 13 ++---
 tools/Makefile |  2 ++
 tools/mvboot.c | 27 ---
 3 files changed, 32 insertions(+), 10 deletions(-)

diff --git a/doc/mvboot.1 b/doc/mvboot.1
index 563d0e5..0978351 100644
--- a/doc/mvboot.1
+++ b/doc/mvboot.1
@@ -1,17 +1,18 @@
-.TH MVBOOT 1 "2012-05-19"
+.TH MVBOOT 1 "2013-02-12"
 
 .SH NAME
-mvboot \- Boot Marvell Kirkwood SoCs over a serial link.
+mvboot \- Boot Marvell Kirkwood/Dove SoCs over a serial link.
 .SH SYNOPSIS
 .B mvboot
 .RB [ "-b \fIimage\fP" ]
+.RB [ "-n" ]
 .RB [ "-p" ]
 .RB [ "-t" ]
 .RB [ "-B \fIbaudrate\fP" ]
 .RB \fITTY\fP
 .SH "DESCRIPTION"
 
-The \fBmkimage\fP program boots boards based on Marvell's Kirkwood
+The \fBmkimage\fP program boots boards based on Marvell's Kirkwood/Dove
 platform over their integrated UART. Boot image files will typically
 contain a second stage boot loader, such as U-Boot. The image file
 must conform to Marvell's BootROM firmware image format
@@ -68,6 +69,12 @@ If standard I/O streams connect to a console, this mode will 
terminate
 after receiving 'ctrl-\\' followed by 'c' from console input.
 
 .TP
+.BI "\-n"
+Disables the UART boot mode sequence for platforms that do not support
+it (e.g. Dove). Usually, the UART boot mode must be selected by pressing
+a push button on power-up.
+
+.TP
 .BI "\-B \fIbaudrate\fP"
 Adjust the baud rate on \fITTY\fP. Default rate is 115200.
 
diff --git a/tools/Makefile b/tools/Makefile
index adfb643..db4def5 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -72,6 +72,7 @@ BIN_FILES-$(CONFIG_SMDK5250) += mksmdk5250spl$(SFX)
 BIN_FILES-$(CONFIG_MX28) += mxsboot$(SFX)
 BIN_FILES-$(CONFIG_NETCONSOLE) += ncb$(SFX)
 BIN_FILES-$(CONFIG_SHA1_CHECK_UB_IMG) += ubsha1$(SFX)
+BIN_FILES-$(CONFIG_DOVE) += mvboot$(SFX)
 BIN_FILES-$(CONFIG_KIRKWOOD) += mvboot$(SFX)
 
 # Source files which exist outside the tools directory
@@ -103,6 +104,7 @@ OBJ_FILES-$(CONFIG_NETCONSOLE) += ncb.o
 NOPED_OBJ_FILES-y += os_support.o
 OBJ_FILES-$(CONFIG_SHA1_CHECK_UB_IMG) += ubsha1.o
 NOPED_OBJ_FILES-y += ublimage.o
+OBJ_FILES-$(CONFIG_DOVE) += mvboot.o
 OBJ_FILES-$(CONFIG_KIRKWOOD) += mvboot.o
 
 # Don't build by default
diff --git a/tools/mvboot.c b/tools/mvboot.c
index 94fb0dd..ea12f58 100644
--- a/tools/mvboot.c
+++ b/tools/mvboot.c
@@ -1,5 +1,5 @@
 /*
- * Boot a Marvell Kirkwood SoC, with Xmodem over UART0.
+ * Boot a Marvell Kirkwood and Dove SoCs, with Xmodem over UART0.
  *
  * (c) 2012 Daniel Stodden 
  *
@@ -37,6 +37,10 @@ static unsigned char mvboot_msg_boot[] = {
0xBB, 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77
 };
 
+static unsigned char mvboot_msg_none[] = {
+   0x00
+};
+
 #define MVBOOT_MSG_REQ_DELAY   10 /* ms */
 #define MVBOOT_MSG_RSP_TIMEO   50 /* ms */
 
@@ -268,17 +272,21 @@ mvboot_bootmsg(int tty, void *msg)
int rc;
char c;
 
-   mvboot_printv("Sending boot message. Please reboot the target...");
+   mvboot_printv(msg != mvboot_msg_none
+ ? "Sending boot message. Please reboot the target..."
+ : "Sensing target. Please reboot target into UART mode...");
 
do {
rc = tcflush(tty, TCIOFLUSH);
if (rc)
break;
 
-   rc = mvboot_tty_send(tty, msg, 8);
-   if (rc) {
-   usleep(MVBOOT_MSG_REQ_DELAY * 1000);
-   continue;
+   if (msg != mvboot_msg_none) {
+   rc = mvboot_tty_send(tty, msg, 8);
+   if (rc) {
+   usleep(MVBOOT_MSG_REQ_DELAY * 1000);
+   continue;
+   }
}
 
rc = mvboot_tty_recv(tty, &c, 1, MVBOOT_MSG_RSP_TIMEO);
@@ -607,6 +615,7 @@ mvboot_usage(FILE *stream, char *progname)
fprintf(stream, "  -b : boot \n");
fprintf(stream, "  -p: patch  to type 0x69 (uart boot)\n");
fprintf(stream, "\n");
+   fprintf(stream, "  -n: don't send boot message\n");
fprintf(stream, "  -t: mini terminal\n");
fprintf(stream, "\n");
fprintf(stream, "  -B : set baud rate\n");
@@

Re: [U-Boot] [PATCH 7/7 V3] EXYNOS5: Snow: Add a configuration file

2013-02-12 Thread Minkyu Kang
Dear Rajeshwari,

On 01/02/13 14:39, Rajeshwari Shinde wrote:
> This patch adds the configuration file for Snow Board and
> defines the same in boards.cfg.
> 
> Signed-off-by: Rajeshwari Shinde 
> ---
> Changes in V2:
>   - None.
> Changes in V3:
>   - Moved CONFIG_SOUND_MAX98095 to exynos5250-dt.h
>  boards.cfg  |1 +
>  include/configs/exynos5250-dt.h |1 +
>  include/configs/snow.h  |   33 +
>  3 files changed, 35 insertions(+), 0 deletions(-)
>  create mode 100644 include/configs/snow.h
> 
> diff --git a/boards.cfg b/boards.cfg
> index e4b0d44..f247b03 100644
> --- a/boards.cfg
> +++ b/boards.cfg
> @@ -283,6 +283,7 @@ s5p_goni arm armv7   goni 
>samsung
>  smdkc100 arm armv7   smdkc100
> samsungs5pc1xx
>  origenarm armv7   origen 
>  samsungexynos
>  s5pc210_universalarm armv7   universal_c210  
> samsungexynos
> +snow  arm armv7   smdk5250
> samsungexynos
>  smdk5250  arm armv7   smdk5250
> samsungexynos
>  smdkv310  arm armv7   smdkv310
> samsungexynos
>  tratsarm armv7   trats   
> samsungexynos
> diff --git a/include/configs/exynos5250-dt.h b/include/configs/exynos5250-dt.h
> index a01fb96..b1b24a9 100644
> --- a/include/configs/exynos5250-dt.h
> +++ b/include/configs/exynos5250-dt.h
> @@ -298,6 +298,7 @@
>  #define CONFIG_SOUND
>  #define CONFIG_I2S
>  #define CONFIG_SOUND_WM8994
> +#define CONFIG_SOUND_MAX98095

unrelated change.

>  #endif
>  
>  /* Enable devicetree support */
> diff --git a/include/configs/snow.h b/include/configs/snow.h
> new file mode 100644
> index 000..1dc491b
> --- /dev/null
> +++ b/include/configs/snow.h
> @@ -0,0 +1,33 @@
> +/*
> + * Copyright (C) 2013 Samsung Electronics
> + *
> + * Configuration settings for the SAMSUNG SMDK5250 board.
> + *
> + * 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
> + */
> +
> +#ifndef __CONFIG_SMDK_H
> +#define __CONFIG_SMDK_H
> +
> +#include 
> +
> +#undef CONFIG_DEFAULT_DEVICE_TREE
> +#define CONFIG_DEFAULT_DEVICE_TREE   exynos5250-snow
> +
> +#endif   /* __CONFIG_SMDK_H */
> 

Thanks.
Minkyu Kang.

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


Re: [U-Boot] [PATCH 6/7 V3] EXYNOS5: Add initial DTS file for Snow.

2013-02-12 Thread Minkyu Kang
Dear Rajeshwari,

On 01/02/13 14:39, Rajeshwari Shinde wrote:
> This patch adds the DTS file for Snow Board.
> 
> Signed-off-by: Rajeshwari Shinde 
> ---
> Changes in V2:
>   -None
> Changes in V3:
>   - None
>  board/samsung/dts/exynos5250-snow.dts |   69 
> +
>  1 files changed, 69 insertions(+), 0 deletions(-)
>  create mode 100644 board/samsung/dts/exynos5250-snow.dts
> 

I think, patch 6 and 7 should be separated with another patch.

Thanks,
Minkyu Kang.

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


[U-Boot] [PATCH 1/2] tools: rename kwboot to mvboot

2013-02-12 Thread Luka Perkov
kwboot tool is used to boot Marvell Kirkwood SoCs over the serial link. Before
adding support for other Marvell SoCs, such as Dove or Armada, this patch
renames the tool so it's name makes more sense in the future.

Signed-off-by: Luka Perkov 
CC: Prafulla Wadaskar 
CC: Sebastian Hesselbarth 
CC: Daniel Stodden 
---
 doc/kwboot.1 |  84 ---
 doc/mvboot.1 |  84 +++
 tools/.gitignore |   2 +-
 tools/Makefile   |   6 +-
 tools/kwboot.c   | 742 ---
 tools/mvboot.c   | 742 +++
 6 files changed, 830 insertions(+), 830 deletions(-)
 delete mode 100644 doc/kwboot.1
 create mode 100644 doc/mvboot.1
 delete mode 100644 tools/kwboot.c
 create mode 100644 tools/mvboot.c

diff --git a/doc/kwboot.1 b/doc/kwboot.1
deleted file mode 100644
index 25fe69a..000
--- a/doc/kwboot.1
+++ /dev/null
@@ -1,84 +0,0 @@
-.TH KWBOOT 1 "2012-05-19"
-
-.SH NAME
-kwboot \- Boot Marvell Kirkwood SoCs over a serial link.
-.SH SYNOPSIS
-.B kwboot
-.RB [ "-b \fIimage\fP" ]
-.RB [ "-p" ]
-.RB [ "-t" ]
-.RB [ "-B \fIbaudrate\fP" ]
-.RB \fITTY\fP
-.SH "DESCRIPTION"
-
-The \fBmkimage\fP program boots boards based on Marvell's Kirkwood
-platform over their integrated UART. Boot image files will typically
-contain a second stage boot loader, such as U-Boot. The image file
-must conform to Marvell's BootROM firmware image format
-(\fIkwbimage\fP), created using a tool such as \fBmkimage\fP.
-
-Following power-up or a system reset, system BootROM code polls the
-UART for a brief period of time, sensing a handshake message which
-initiates an image upload. This program sends this boot message until
-it receives a positive acknowledgement. The image is transfered using
-Xmodem.
-
-Additionally, this program implements a minimal terminal mode, which
-can be used either standalone, or entered immediately following boot
-image transfer completion. This is often useful to catch early boot
-messages, or to manually interrupt a default boot procedure performed
-by the second-stage loader.
-
-.SH "OPTIONS"
-
-.TP
-.BI "\-b \fIimage\fP"
-Handshake; then upload file \fIimage\fP over \fITTY\fP.
-
-Note that for the encapsulated boot code to be executed, \fIimage\fP
-must be of type "UART boot" (0x69). Boot images of different types,
-such as backup images of vendor firmware downloaded from flash memory
-(type 0x8B), will not work (or not as expected). See \fB-p\fP for a
-workaround.
-
-This mode writes handshake status and upload progress indication to
-stdout.
-
-.TP
-.BI "\-p"
-In combination with \fB-b\fP, patches the header in \fIimage\fP prior
-to upload, to "UART boot" type.
-
-This option attempts on-the-fly conversion of some none-UART image
-types, such as images which were originally formatted to be stored in
-flash memory.
-
-Conversion is performed in memory. The contents of \fIimage\fP will
-not be altered.
-
-.TP
-.BI "\-t"
-Run a terminal program, connecting standard input and output to
-.RB \fITTY\fP.
-
-If used in combination with \fB-b\fP, terminal mode is entered
-immediately following a successful image upload.
-
-If standard I/O streams connect to a console, this mode will terminate
-after receiving 'ctrl-\\' followed by 'c' from console input.
-
-.TP
-.BI "\-B \fIbaudrate\fP"
-Adjust the baud rate on \fITTY\fP. Default rate is 115200.
-
-.SH "SEE ALSO"
-.PP
-\fBmkimage\fP(1)
-
-.SH "AUTHORS"
-
-Daniel Stodden 
-.br
-Luka Perkov 
-.br
-David Purdy 
diff --git a/doc/mvboot.1 b/doc/mvboot.1
new file mode 100644
index 000..563d0e5
--- /dev/null
+++ b/doc/mvboot.1
@@ -0,0 +1,84 @@
+.TH MVBOOT 1 "2012-05-19"
+
+.SH NAME
+mvboot \- Boot Marvell Kirkwood SoCs over a serial link.
+.SH SYNOPSIS
+.B mvboot
+.RB [ "-b \fIimage\fP" ]
+.RB [ "-p" ]
+.RB [ "-t" ]
+.RB [ "-B \fIbaudrate\fP" ]
+.RB \fITTY\fP
+.SH "DESCRIPTION"
+
+The \fBmkimage\fP program boots boards based on Marvell's Kirkwood
+platform over their integrated UART. Boot image files will typically
+contain a second stage boot loader, such as U-Boot. The image file
+must conform to Marvell's BootROM firmware image format
+(\fIkwbimage\fP), created using a tool such as \fBmkimage\fP.
+
+Following power-up or a system reset, system BootROM code polls the
+UART for a brief period of time, sensing a handshake message which
+initiates an image upload. This program sends this boot message until
+it receives a positive acknowledgement. The image is transfered using
+Xmodem.
+
+Additionally, this program implements a minimal terminal mode, which
+can be used either standalone, or entered immediately following boot
+image transfer completion. This is often useful to catch early boot
+messages, or to manually interrupt a default boot procedure performed
+by the second-stage loader.
+
+.SH "OPTIONS"
+
+.TP
+.BI "\-b \fIimage\fP"
+Handshake; then upload file \fIimage\fP over \fITTY\fP.
+
+Note that for the encapsulated boot code to be executed, \fIimage\fP
+must be of type "UART

[U-Boot] [PATCH v5 1/3] Add README for the "Falcon" mode

2013-02-12 Thread Stefano Babic
Simple howto to add support to a board
for booting the kernel from SPL ("Falcon" mode).

Signed-off-by: Stefano Babic 
---
Changes in v5:
- several fixes for the language, rephrasing some unclear parts (Vikram 
Narayanan)

Changes in v4:
- fix capitalization, styling, in spl help (Andreas Biessmann)
- move CONFIG_SPL_OS_BOOT before function in doc (Andreas Biessmann)

Changes in v3:
- parameter initrd_addr was removed in V2 (Andreas Biessmann)
- added patch to fix help usage for spl export (Andreas Biessmann)
- Added empty lines (Otavio Salvador)
- add a more exhaustive description explaining that
  spl export does not save into media (Lukasz Majewski).

Changes in v2:
- spelling, language fixes (Andreas Biessman)
- rewrite some unclear sentences
- drop CONFIG_SPL_OS_BOOT_KEY
- make example with twister more exhaustive

 doc/README.falcon |  169 +
 1 file changed, 169 insertions(+)
 create mode 100644 doc/README.falcon

diff --git a/doc/README.falcon b/doc/README.falcon
new file mode 100644
index 000..72fe04a
--- /dev/null
+++ b/doc/README.falcon
@@ -0,0 +1,169 @@
+U-Boot Falcon Mode
+
+
+Introduction
+
+
+This document provides an overview of how to add support for Falcon Mode
+to a board.
+Falcon Mode is introduced to speed up the booting process, allowing
+to boot a Linux kernel (or whatever image) without a full blown U-Boot.
+
+Falcon Mode relies on the SPL framework. In fact, to make booting faster,
+U-Boot is split into two parts: the SPL (Secondary Program Loader) and U-Boot
+image. In most implementations, SPL is used to start U-Boot when booting from
+a mass storage, such as NAND or SD-Card. SPL has now support for other media,
+and can generally be seen as a way to start an image performing the minimum
+required initialization. SPL mainly initializes the RAM controller, and then
+copies U-Boot image into the memory. The Falcon Mode extends this way
+allowing to start the Linux kernel directly from SPL. A new command is added
+to U-Boot to prepare the parameters that SPL must pass to the kernel, using
+ATAGS or Device Tree.
+
+In usual U-Boot systems, these parameters are generated each time before
+loading the kernel, passing to Linux the address in memory where
+the parameters can be read.
+With Falcon Mode, this snapshot can be saved into persistent storage and SPL is
+informed to load it before running the kernel.
+
+To boot the kernel, these steps under a Falcon-aware U-Boot are required:
+
+1. Boot the board into U-Boot.
+Use the "spl export" command to generate the kernel parameters area or the DT.
+U-Boot runs as when it boots the kernel, but stops before passing the control
+to the kernel.
+
+2. Save the prepared snapshot into persistent media.
+The address where to save it must be configured into board configuration
+file (CONFIG_CMD_SPL_NAND_OFS for NAND).
+
+3. Boot the board into Falcon Mode. SPL will load the kernel and copy
+the parameters which are saved in the persistent area area to the required 
address.
+
+It is required to implement a custom mechanism to select if SPL loads U-Boot
+or another image.
+
+The value of a GPIO is a simple way to operate the selection, as well as
+reading a character from the SPL console if CONFIG_SPL_CONSOLE is set.
+
+Falcon Mode is generally activated by setting CONFIG_SPL_OS_BOOT. This tells
+SPL that U-Boot is not the only available image that SPL is able to start.
+
+Configuration
+
+CONFIG_CMD_SPL Enable the "spl export" command.
+   The command "spl export" is then available in U-Boot
+   mode
+CONFIG_SYS_SPL_ARGS_ADDR   Address in RAM where the parameters must be
+   copied by SPL.
+   In most cases, it is  + 0x100
+
+CONFIG_SYS_NAND_SPL_KERNEL_OFFSOffset in NAND where the kernel is 
stored
+
+CONFIG_CMD_SPL_NAND_OFSOffset in NAND where the parameters area was 
saved.
+
+CONFIG_CMD_SPL_WRITE_SIZE  Size of the parameters area to be copied
+
+CONFIG_SPL_OS_BOOT Activate Falcon Mode.
+
+Function that a board must implement
+
+
+void spl_board_prepare_for_linux(void) : optional
+   Called from SPL before starting the kernel
+
+spl_start_uboot() : required
+   Returns "0" if SPL starts the kernel, "1" if U-Boot
+   must be started.
+
+
+Using spl command
+-
+
+spl - SPL configuration
+
+Usage:
+
+spl export  [kernel_addr] [initrd_addr] [fdt_addr ]
+
+img: "atags" or "fdt"
+kernel_addr: kernel is loaded as part of the boot process, but it is not 
started.
+ This is the address where a kernel image is stored.
+initrd_addr: Address of initial ramdisk
+ can be set to "-" if fdt_addr without initrd img is used
+fdt_addr   : in case of fdt, the address of the device tree.
+

[U-Boot] [PATCH v5 3/3] SPL: Change description for spl command

2013-02-12 Thread Stefano Babic
Add a more descriptive text to the help of the spl
command.

Signed-off-by: Stefano Babic 
---
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 common/cmd_spl.c |   12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/common/cmd_spl.c b/common/cmd_spl.c
index e3c543b..94b0a17 100644
--- a/common/cmd_spl.c
+++ b/common/cmd_spl.c
@@ -184,7 +184,11 @@ static int do_spl(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
 
 U_BOOT_CMD(
spl, 6 , 1, do_spl, "SPL configuration",
-   "export  [kernel_addr] [initrd_addr] "
-   "[fdt_addr if  = fdt] - export a kernel parameter image\n"
-   "\t initrd_img can be set to \"-\" if fdt_addr without initrd img is"
-   "used");
+   "export  [kernel_addr] [initrd_addr] [fdt_addr]\n"
+   "\timg\t\t\"atags\" or \"fdt\"\n"
+   "\tkernel_addr\taddress where a kernel image is stored.\n"
+   "\t\t\tkernel is loaded as part of the boot process, but it is not 
started.\n"
+   "\tinitrd_addr\taddress of initial ramdisk\n"
+   "\t\t\tcan be set to \"-\" if fdt_addr without initrd_addr is used.\n"
+   "\tfdt_addr\tin case of fdt, the address of the device tree.\n"
+   );
-- 
1.7.9.5

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


[U-Boot] [PATCH v5 2/3] OMAP3: drop CONFIG_SPL_OS_BOOT_KEY and use local define

2013-02-12 Thread Stefano Babic
CONFIG_SPL_OS_BOOT_KEY is used only in board files. It is
not required to have a general CONFIG_ option. Rename it and
define it in board directory.

Signed-off-by: Stefano Babic 
---
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 board/technexion/twister/twister.c  |8 
 board/technexion/twister/twister.h  |2 ++
 board/timll/devkit8000/devkit8000.c |8 
 board/timll/devkit8000/devkit8000.h |3 +++
 include/configs/devkit8000.h|1 -
 include/configs/twister.h   |1 -
 6 files changed, 13 insertions(+), 10 deletions(-)

diff --git a/board/technexion/twister/twister.c 
b/board/technexion/twister/twister.c
index c9eea9b..fa0ace0 100644
--- a/board/technexion/twister/twister.c
+++ b/board/technexion/twister/twister.c
@@ -165,10 +165,10 @@ void spl_board_prepare_for_linux(void)
 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);
+   if (!gpio_request(SPL_OS_BOOT_KEY, "U-Boot key")) {
+   gpio_direction_input(SPL_OS_BOOT_KEY);
+   val = gpio_get_value(SPL_OS_BOOT_KEY);
+   gpio_free(SPL_OS_BOOT_KEY);
}
return val;
 }
diff --git a/board/technexion/twister/twister.h 
b/board/technexion/twister/twister.h
index a2051c0..cff479c 100644
--- a/board/technexion/twister/twister.h
+++ b/board/technexion/twister/twister.h
@@ -38,6 +38,8 @@ const omap3_sysinfo sysinfo = {
 #define XR16L2751_UART1_BASE   0x2100
 #define XR16L2751_UART2_BASE   0x2300
 
+/* GPIO used to select between U-Boot and kernel */
+#define SPL_OS_BOOT_KEY55
 
 /*
  * IEN  - Input Enable
diff --git a/board/timll/devkit8000/devkit8000.c 
b/board/timll/devkit8000/devkit8000.c
index 85685ee..b88d978 100644
--- a/board/timll/devkit8000/devkit8000.c
+++ b/board/timll/devkit8000/devkit8000.c
@@ -172,10 +172,10 @@ void spl_board_prepare_for_linux(void)
 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);
+   if (!gpio_request(SPL_OS_BOOT_KEY, "U-Boot key")) {
+   gpio_direction_input(SPL_OS_BOOT_KEY);
+   val = gpio_get_value(SPL_OS_BOOT_KEY);
+   gpio_free(SPL_OS_BOOT_KEY);
}
return !val;
 }
diff --git a/board/timll/devkit8000/devkit8000.h 
b/board/timll/devkit8000/devkit8000.h
index aa69e6c..c1965e2 100644
--- a/board/timll/devkit8000/devkit8000.h
+++ b/board/timll/devkit8000/devkit8000.h
@@ -32,6 +32,9 @@ const omap3_sysinfo sysinfo = {
"NAND",
 };
 
+/* GPIO used to select between U-Boot and kernel */
+#define SPL_OS_BOOT_KEY26
+
 /*
  * IEN  - Input Enable
  * IDIS - Input Disable
diff --git a/include/configs/devkit8000.h b/include/configs/devkit8000.h
index d926f74..788227d 100644
--- a/include/configs/devkit8000.h
+++ b/include/configs/devkit8000.h
@@ -354,7 +354,6 @@
 
 /* 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 */
diff --git a/include/configs/twister.h b/include/configs/twister.h
index a852481..4205a11 100644
--- a/include/configs/twister.h
+++ b/include/configs/twister.h
@@ -58,7 +58,6 @@
 #define CONFIG_CMD_SPL_NAND_OFS(CONFIG_SYS_NAND_SPL_KERNEL_OFFS+\
0x60)
 #define CONFIG_SPL_OS_BOOT
-#define CONFIG_SPL_OS_BOOT_KEY 55
 
 #define CONFIG_SYS_SPL_ARGS_ADDR   (PHYS_SDRAM_1 + 0x100)
 #define CONFIG_SPL_BOARD_INIT
-- 
1.7.9.5

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


Re: [U-Boot] [PATCH] usb: ehci: exynos: Enable non-dt path

2013-02-12 Thread Minkyu Kang
Dear Vivek,

On 11/01/13 18:24, Vivek Gautam wrote:
> Enabling the non-dt path for the driver so that
> we don't get any build errors for non-dt configuration.
> 
> Signed-off-by: Vivek Gautam 
> ---
> 
> Earlier we had moved to fdt support for ehci-exynos driver, but
> missed out the non-dt path. Although this driver serves for exysno5
> onward only but better to keep the non-dt path also available.
> 
>  drivers/usb/host/ehci-exynos.c |   10 ++
>  1 files changed, 10 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
> index 3ca4c5c..6f0c6c3 100644
> --- a/drivers/usb/host/ehci-exynos.c
> +++ b/drivers/usb/host/ehci-exynos.c
> @@ -153,7 +153,12 @@ int ehci_hcd_init(int index, struct ehci_hccr **hccr, 
> struct ehci_hcor **hcor)
>   return -ENOMEM;
>   }
>  
> +#ifdef CONFIG_OF_CONTROL
>   exynos_usb_parse_dt(gd->fdt_blob, exynos);
> +#else
> + exynos->usb = (struct exynos_usb_phy *)samsung_get_base_usb_phy();
> + exynos->hcd = samsung_get_base_usb_ehci();
> +#endif
>  
>   setup_usb_phy(exynos->usb);
>  
> @@ -185,7 +190,12 @@ int ehci_hcd_stop(int index)
>   return -ENOMEM;
>   }
>  
> +#ifdef CONFIG_OF_CONTROL
>   exynos_usb_parse_dt(gd->fdt_blob, exynos);
> +#else
> + exynos->usb = (struct exynos_usb_phy *)samsung_get_base_usb_phy();
> + exynos->hcd = samsung_get_base_usb_ehci();
> +#endif
>  
>   reset_usb_phy(exynos->usb);
>  
> 

Patch looks good.
But I've got compiler warnings and errors when I disabled CONFIG_OF_CONTROL.

exynos_spi.c:391:12: warning: 'process_nodes' defined but not used 
[-Wunused-function]
ehci-exynos.c: In function 'ehci_hcd_init':
ehci-exynos.c:160:14: warning: assignment makes pointer from integer without a 
cast [enabled by default]
ehci-exynos.c: In function 'ehci_hcd_stop':
ehci-exynos.c:197:14: warning: assignment makes pointer from integer without a 
cast [enabled by default]
ehci-exynos.c: At top level:
ehci-exynos.c:48:12: warning: 'exynos_usb_parse_dt' defined but not used 
[-Wunused-function]
/opt/eldk-5.2/armv7a/sysroots/i686-eldk-linux/usr/bin/armv7a-vfp-neon-linux-gnueabi/arm-linux-gnueabi-ld.bfd:/home/share/Work/u-boot-samsung/spl/u-boot-spl.lds:1:
 ignoring invalid character `#' in expression
/opt/eldk-5.2/armv7a/sysroots/i686-eldk-linux/usr/bin/armv7a-vfp-neon-linux-gnueabi/arm-linux-gnueabi-ld.bfd:/home/share/Work/u-boot-samsung/spl/u-boot-spl.lds:1:
 syntax error
make[1]: *** [/home/share/Work/u-boot-samsung/spl/u-boot-spl] Error 1
make: *** [spl/u-boot-spl.bin] Error 2
make: *** Waiting for unfinished jobs
smdk5250.c: In function 'board_eth_init':
smdk5250.c:152:6: warning: unused variable 'node' [-Wunused-variable]

Could you please check this issue also?

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


Re: [U-Boot] [PATCH] Add README for the "Falcon" mode

2013-02-12 Thread Stefano Babic
On 11/02/2013 22:12, Otavio Salvador wrote:
> On Mon, Nov 12, 2012 at 8:59 AM, Stefano Babic  wrote:
>> Simple howto to add support to a board
>> for booting the kernel from SPL ("Falcon" mode).
>>
>> Signed-off-by: Stefano Babic 
> 
> Could this be updated and resend? This is an interesting feature which
> lacks documentation currently.

Hi Otavio,

you are right, and thanks to point out that the documentation is not yet
merged. I will push a V5 as I promised with fixes for the last comments.

Regards,
Stefano


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


<    1   2