Re: [U-Boot] coreboot and u-boot integration x86: No tick base available

2014-06-02 Thread Martin Ertsås
On 06/01/14 18:42, Simon Glass wrote:
 Hi Martin,

 On 30 May 2014 04:33, Martin Ertsås marti...@gmail.com wrote:
 Hi.

 I'm trying to use u-boot as a payload to coreboot. Problem is that when
 coreboot starts u-boot, it fails with panic(No tick base available);

 When looking at the backtrace this gives a recursive error, as panic
 calls __udelay and get_ticks, which again panics. I heard this was
 because u-boot overwrote the memory location of coreboot, and that there
 have been some patches going around that fixes this issue, but have not
 made it upstream. As far as I can tell, chromebook v2 uses these patches
 to make their stuff boot. Can anyone point me in the right direction for
 those patches? I have tried finding them myself, but can't seem to find
 them.

 It probably means that Coreboot is not passing its timing data to
 U-Boot. You need to enable a timestamp option in Coreboot to do this.

 You could patch it to remove this panic and just use 0 in this case.

 Regards,
 Simon

Thanks. I'll look into the timestamp option. So using 0 as the tick
value should work?

- Martin

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


Re: [U-Boot] [PATCH] dfu: fix some issues with reads/uploads

2014-06-02 Thread Lukasz Majewski
Hi Stephen,

 On 05/30/2014 02:28 AM, Lukasz Majewski wrote:
 ...
  I've tested if raw u-boot can be downloaded and uploaded via DFU.
  The u-boot size is 1MiB precisely. 
  
  Corresponding dfu_alt_info entry: 
  u-boot raw 0x80 0x800; \
 ...
  2. Upload (raw):
  
  dfu-util -a0 -U u-boot-mmc.bin_target
  It exits immediately and I can only see the file size of 0.
  
  So obviously we have regression here. However, since I didn't
  covered this case in my tests I don't know when it was broken.
 
 Hmmm. I tested with that exact value of dfu_alt_info and got back an
 exactly 1MB file with either the dfu-util packaged in Ubuntu 12.10, or
 with the latest git tree of dfu-util.

Could you share the exact SHA1 of the dfu-util? Or is it the master
newest branch?

 Can you investigate why you're
 getting back a 0-length file? 

This is really strange. I will look into that.

 Perhaps there's some error condition, so
 dfu-util exits before any data is downloaded, or perhaps when
 dfu_get_medium_size_mmc() is called, either lba_size or lba_blk_size
 is 0 (neither should be...)
 

I will check this. Thanks for support.

 Thanks.



-- 
Best regards,

Lukasz Majewski

Samsung RD Institute Poland (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] tam3517: fix NAND detection

2014-06-02 Thread Gupta, Pekon
From: Jeroen Hofstee

commit a0a37183bd7 ARM: omap: merge GPMC initialization code for
all platform needs CONFIG_NOR, CONFIG_NAND or CONFIG_CMD_ONENAND
to be set to access flash. Add CONFIG_NAND for tam3517 derived
boards to prevent the following error: nand: error: Unable to
find NAND settings in GPMC Configuration - quitting

cc: Stefano Babic sba...@denx.de
Signed-off-by: Jeroen Hofstee jer...@myspectrum.nl
---
 include/configs/tam3517-common.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/tam3517-common.h 
b/include/configs/tam3517-common.h
index 3522c1a..bd117d5 100644
--- a/include/configs/tam3517-common.h
+++ b/include/configs/tam3517-common.h
@@ -185,6 +185,7 @@
 /* Configure the PISMO */
 #define PISMO1_NAND_SIZE  GPMC_SIZE_128M

+#define CONFIG_NAND

You should not add CONFIG_NAND directly to include/configs/...
instead this should come from board profiles defined in boards.cfg
refer am335x_evm or description given in header of boards.cfg


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


Re: [U-Boot] [PATCH] mmc: return meaningful error codes from mmc_select_hwpart

2014-06-02 Thread Pantelis Antoniou
Hi Stephen,

On May 23, 2014, at 9:47 PM, Stephen Warren wrote:

 From: Stephen Warren swar...@nvidia.com
 
 Rather than just returning -1 everywhere, try to return something
 meaningful from mmc_select_hwpart(). Note that most other MMC functions
 don't do this, including functions called from mmc_select_hwpart(), so
 I'm not sure how effective this will be. Still, it's one less place with
 hard-coded -1.
 
 Suggested-by: Pantelis Antoniou pa...@antoniou-consulting.com
 Signed-off-by: Stephen Warren swar...@nvidia.com
 ---
 drivers/mmc/mmc.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)
 
 diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
 index 8b53ead98f80..221a293797e9 100644
 --- a/drivers/mmc/mmc.c
 +++ b/drivers/mmc/mmc.c
 @@ -10,6 +10,7 @@
 #include config.h
 #include common.h
 #include command.h
 +#include errno.h
 #include mmc.h
 #include part.h
 #include malloc.h
 @@ -558,19 +559,19 @@ int mmc_select_hwpart(int dev_num, int hwpart)
   int ret;
 
   if (!mmc)
 - return -1;
 + return -ENODEV;
 
   if (mmc-part_num == hwpart)
   return 0;
 
   if (mmc-part_config == MMCPART_NOAVAILABLE) {
   printf(Card doesn't support part_switch\n);
 - return -1;
 + return -EMEDIUMTYPE;
   }
 
   ret = mmc_switch_part(dev_num, hwpart);
   if (ret)
 - return -1;
 + return ret;
 
   mmc-part_num = hwpart;
 
 -- 
 1.8.1.5
 

This does indeed look good.

Thanks

-- Pantelis

Acked-by: Pantelis Antoniou pa...@antoniou-consulting.com


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


Re: [U-Boot] [PATCH v3 1/3] dts: re-write dts/Makefile more simply with Kbuild

2014-06-02 Thread Michal Simek
On 06/01/2014 06:34 PM, Simon Glass wrote:
 Hi,
 
 On 27 May 2014 18:54, Masahiro Yamada yamad...@jp.panasonic.com wrote:
 Hi York,

 diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
 index b770e25..38b9c7d 100644
 --- a/arch/arm/lib/board.c
 +++ b/arch/arm/lib/board.c
 @@ -280,7 +280,7 @@ void board_init_f(ulong bootflag)
 gd-mon_len = _bss_end_ofs;
  #ifdef CONFIG_OF_EMBED
 /* Get a pointer to the FDT */
 -   gd-fdt_blob = _binary_dt_dtb_start;
 +   gd-fdt_blob = __dtb_db_begin;

 Is this a typo? I believe it should be __dtb_dt_begin. Did anyone see the
 compiling error?


 Yes, it's a typo.
 I had already posted a patch.
 http://patchwork.ozlabs.org/patch/342815/

 Even such a simple one has been waiting for more than one month
 in Patchwork queue.
 :-(

 For now, CONFIG_OF_EMBED is defined for MicroBlaze.
 I guess nobody saw the compile error.
 
 I suspect all boards that use CONFIG_OF_CONTROL also use generic board
 now. I expect that this file will be deleted at the end of the year.

No. Microblaze has no generic board support yet.
For zynq I have sent patches out but they will be merged in the next
merge window.

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP - KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform




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


Re: [U-Boot] [PATCH] mmc: add wrappers for MMC block_{read, write, erase}

2014-06-02 Thread Pantelis Antoniou
Hi Steve,

I wanted the discussion to settle a bit before I reply to this series.
On May 29, 2014, at 1:15 AM, Steve Rae wrote:

 Each wrapper function:
 - switches to the specified physical partition, then
 - performs the original function, and then
 - switches back to the original physical partition
 where the physical partition (aka HW partition) is
  0=User, 1=Boot1, 2=Boot2, etc.
 
 Signed-off-by: Steve Rae s...@broadcom.com
 ---

[snip]

 /**
  * Start device initialization and return immediately; it does not block on
  * polling OCR (operation condition register) status.  Then you should call
 -- 
 1.8.5
 

The thing IMO should be modeled in the same way that block devices work in
Linux.

TBH I'm not very fond of the way block devices/partitions and the block_ops
are intermixed in block_dev_t. This part of code could use some refactoring
to make it operate more like a regular linux block device (with each partition
being it's own block device), but I don't know if we have enough votes to change
it ATM.

I'm willing to pick up any MMC related patches to get something workable 
(Stephen's
approach is fine), but I also want to ask if there's any interest in fixing up 
the 
block dev mess.

Regards

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


Re: [U-Boot] [PATCH v2] Separate EBV Socrates board from Altera Cyclone 5 board and from Virtual Target

2014-06-02 Thread Chin Liang See
Hi guys,


On Fri, 2014-05-30 at 11:41 +0200, Detlev Zundel wrote:
 Hi Pavel,
 
  On Wed 2014-05-28 16:29:50, Wolfgang Denk wrote:
  In message 20140528124910.ga24...@amd.pavel.ucw.cz you wrote:
   
   There are no differences between EBV socrates and socfpga boards,
   currently.
  
  Well, for one thing, the board vendor and the board name differ...
 
  I meant from current code in u-boot point of view...
 
 But as we all agree, this may change quickly and for multiple boards.


Yup, some other board vendors are using different HW configuration. Some
of the difference are Altera dev kit have EEPROM and using Micrel PHY
for EMAC. I presume Socrates board should have their own board path such
as board/socrates/socfpga.


 
 AFAICT, one solution would be to put - in that column, and
 do git
 mv board/altera/ board/socfpga/.

Putting - in the vendor column just doesn't feel right.  
   
   That's what mx6 did, AFAICT.
  
  I think Detlev is right here.  We do have specific board vendors
  directories, and there are a number of reasons to keep this used
  (just to give one example: say a vendor wants to use a similar look
  and feel for the default environment settings etc. for all boards).
 
  If there is code which is identical for several (or all?) boards we
  should ask ourself if it really belongs into the board/ directory at
  all?
 
  That might be the case. It seems that current code in board/altera is
  SoC-specific, as it works on both Altera and EBV boards. 
 
 Then we are in agreement that it does not belong below board/ ;)


Within board/altera, there are 2 types of files as below:

1. HW configuration handoff files (such as pinmux_config, pll_config).
   Pinmux might be different as certain board might have different
routing (normally to optimize the board layout and shorter PCB trace
length).
   
2. Board specific code (socfpga_cyclone5.c)
   These functions include board_init, board_early_init, checkboard.
   I believe that the function print_cpuinfo and overwrite _console
should goto arch/arm/cpu/armv7/socfpga/misc.c.
   I will create the patch to change this later (as I already did this
at rocketboard.org).

 
 
   Actually.. there's nothing Altera specific in board/altera (it works
   on ebv just fine), so board/socfpga sounds like a better name. But I
   don't think such rename should be done lightly, so I still believe the
   patch as submitted is the best way to go.
  
  I think board/altera as such makes sense, with Altera being the vendor
  of that specific board.  However, if there is common code there, this
  code should be moved out of board/ .
 
  It seems there's currently 99.99% of SoC-specific code there.
 
  What would be the right place for that code?
 
 Depends on what exactly it implements.  Apart from that we can also take
 a look at where the code is in a Linux tree and take that as an
 example.  After all, we want people developing the Linux kernel to also
 feel at home in the U-Boot sources.
 
  arch/arm/cpu/armv7/socfpga/ ? But it is not really armv7-specific.
  drivers/misc ? Do we need to make a soc/ directory?
 
 We have arch/arm/imx-common for example, but I'm not so sure if this is
 a good approach.  Maybe there is not a _single_ correct place, but we
 have to distribute the files to multiple directories?
 
  And then... who does the move? It is not going to make merging between
  rocketboards.org and mainline even trickier than it already is :-(.
 
 This is a good question and we should certainly not answer it lightly.
 Usually we care only to a certain degree for non-mainline code, though.
 Blocking ourselves because of non-mainline code would allow external
 control which I think is not really helpful for the project.
 


As above, I can move some common function to
arch/arm/cpu/armv7/socfpga/misc.c.

Thanks
Chin Liang


 Cheers
   Detlev
   


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


Re: [U-Boot] [PATCH] tam3517: fix NAND detection

2014-06-02 Thread Stefano Babic
Hi Gupta,

On 02/06/2014 08:16, Gupta, Pekon wrote:
 From: Jeroen Hofstee

 commit a0a37183bd7 ARM: omap: merge GPMC initialization code for
 all platform needs CONFIG_NOR, CONFIG_NAND or CONFIG_CMD_ONENAND
 to be set to access flash. Add CONFIG_NAND for tam3517 derived
 boards to prevent the following error: nand: error: Unable to
 find NAND settings in GPMC Configuration - quitting

 cc: Stefano Babic sba...@denx.de
 Signed-off-by: Jeroen Hofstee jer...@myspectrum.nl
 ---
 include/configs/tam3517-common.h | 1 +
 1 file changed, 1 insertion(+)

 diff --git a/include/configs/tam3517-common.h 
 b/include/configs/tam3517-common.h
 index 3522c1a..bd117d5 100644
 --- a/include/configs/tam3517-common.h
 +++ b/include/configs/tam3517-common.h
 @@ -185,6 +185,7 @@
 /* Configure the PISMO */
 #define PISMO1_NAND_SIZE GPMC_SIZE_128M

 +#define CONFIG_NAND
 
 You should not add CONFIG_NAND directly to include/configs/...
 instead this should come from board profiles defined in boards.cfg
 refer am335x_evm or description given in header of boards.cfg
 

But TAM3517 is a SOM and it has always NAND. It is slightly different as
the am335x_evm. All boards using this SOM are then affected by this
problem, and fixing it in the SOM configuration file let us to make a
global fix for all boards, instead of adding CONFIG_NAND for each single
profile in boards.cfg.

Best 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


Re: [U-Boot] [PATCH v2] Separate EBV Socrates board from Altera Cyclone 5 board and from Virtual Target

2014-06-02 Thread Chin Liang See
Hi Pavel,

On Tue, 2014-05-27 at 15:12 +0200, ZY - pavel wrote:
 Altera Cyclone 5 board is very different board (big, rectangular,
 expensive) than EBV Socrates (small, circular, cheap) board. Different
 parts are used there, too, but same configuration of u-boot works on
 both. Nevertheless, printing wrong name confuses users. Virtual target
 is completely different, and board configured for it will not boot on
 physical targets.
 
 Therefore this splits the configuration so that u-boot knows they are
 different. So far it is only used for correcting the puts, but there
 may be other uses in future.
 
 Signed-off-by: Pavel Machek pa...@denx.de
 
 ---
 
 Diff from v1: separate virtual target, too, and make it apply to
 recent u-boot.
 
 diff --git a/board/altera/socfpga/socfpga_cyclone5.c 
 b/board/altera/socfpga/socfpga_cyclone5.c
 index a960eb6..33946b6 100644
 --- a/board/altera/socfpga/socfpga_cyclone5.c
 +++ b/board/altera/socfpga/socfpga_cyclone5.c
 @@ -28,7 +28,7 @@ int print_cpuinfo(void)
   */
  int checkboard(void)
  {
 - puts(BOARD : Altera SOCFPGA Cyclone5 Board\n);
 + puts(BOARD :  ALTERA_BOARD_NAME \n);
   return 0;
  }
  
 diff --git a/boards.cfg b/boards.cfg
 index 221b7f8..6eebbf5 100644
 --- a/boards.cfg
 +++ b/boards.cfg
 @@ -379,6 +379,8 @@ Active  arm armv7  rmobile renesas
  lager
  Active  arm armv7  s5pc1xx samsung goni  
   s5p_goni  - 
   
   Przemyslaw Marczak p.marc...@samsung.com
  Active  arm armv7  s5pc1xx samsung smdkc100  
   smdkc100  - 
   
   Minkyu Kang mk7.k...@samsung.com
  Active  arm armv7  socfpga altera  socfpga   
   socfpga_cyclone5  - 
   
   -
 +Active  arm armv7  socfpga altera  socfpga   
   socfpga_virtual  -  
   
  -
 +Active  arm armv7  socfpga altera  socfpga   
   socfpga_socrates  - 
   
   -
  Active  arm armv7  u8500   st-ericsson snowball  
   snowball  - 
   
   Mathieu Poirier mathieu.poir...@linaro.org
  Active  arm armv7  u8500   st-ericsson u8500 
   u8500_href- 
   
   -
  Active  arm armv7  vf610   freescale   vf610twr  
   vf610twr  
 vf610twr:IMX_CONFIG=board/freescale/vf610twr/imximage.cfg 
 Alison Wang 
 b18...@freescale.com
 diff --git a/include/configs/socfpga_common.h 
 b/include/configs/socfpga_common.h
 new file mode 100644
 index 000..4d90952
 --- /dev/null
 +++ b/include/configs/socfpga_common.h
 @@ -0,0 +1,240 @@
 +/*
 + *  Copyright (C) 2012 Altera Corporation www.altera.com
 + *
 + * SPDX-License-Identifier:  GPL-2.0+
 + */
 +#ifndef __CONFIG_COMMON_H
 +#define __CONFIG_COMMON_H
 +
 +#include asm/arch/socfpga_base_addrs.h
 +#include ../../board/altera/socfpga/pinmux_config.h
 +#include ../../board/altera/socfpga/pll_config.h
 +


I believe these should go to board specific header file such as
socfpga_cyclone5 and socfpga_socrates. These are HW configuration
handoff files and different from board to board.


 +/*
 + * Hardware drivers
 + */
 +
 +/*
 + * SDRAM Memory Map
 + */
 +/* We have 1 bank of DRAM */
 +#define CONFIG_NR_DRAM_BANKS 1
 +/* SDRAM Bank #1 */
 +#define CONFIG_SYS_SDRAM_BASE0x
 +/* SDRAM memory size */
 +#define PHYS_SDRAM_1_SIZE0x4000
 +


Just a quick comments. In newer version SPL at rocketboard.org, we won't
need to specify the size. It will be calculated based on HW registers.
We will change this together with SPL SDRAM patch.


 diff --git a/include/configs/socfpga_cyclone5.h 
 b/include/configs/socfpga_cyclone5.h
 index 517070c..d5d59d2 100644
 --- a/include/configs/socfpga_cyclone5.h
 +++ 

Re: [U-Boot] [PATCH] arm: Allow u-boot to run from offset base address

2014-06-02 Thread Albert ARIBAUD
Hi Darwin,

On Mon, 26 May 2014 09:11:35 -0700, Darwin Rambo dra...@broadcom.com
wrote:

 Hi Albert,
 
 The previous stage bootloader (which I had no control over) wanted it's 
 header to be aligned to a 512 byte MMC block boundary, presumably since 
 this allowed DMA operations without copy/shifting. At the same time, I 
 didn't want to hack a header into start.S because I didn't want to carry 
 another downstream patch. So I investigated if I could shift u-boot's 
 base address as a feature that would allow an aligned header to be used 
 without the start.S patch.
 
 I know that a custom header patch to start.S would work, and that a 
 header plus padding will also work. But I found out that you can align 
 the base on certain smaller offsets if you keep the relocation offset at 
 nice boundaries like 0x1000 and if the relocation offset is a multiple 
 of the maximum alignment requirements of the image.
 
 The original patch I submitted didn't handle an end condition properly, 
 was ARM64-specific (wasn't tested on other architectures), and because 
 the patch was NAK'd, I didn't bother to submit a v2 patch and consider 
 the idea to be dead. I'm happy to abandon the patch. I hope this helps.

Thanks.

If I understand correctly, your target has a requirement for storing
the image on a 512-byte boundary. But how does this affect the loading
of the image into RAM, where the requirement is only that the vectors
table be 32-bytes aligned? I mean, if you store the image in MMC at
offset 0x200 (thus satisfying the 512-byte boundary requirement) and
load it to, say, offset 0x10020 in RAM, how is it a problem for
your target?

If my example above inadequately represents the issue, then can you
please provide a similar but adequate example, a failure case scenario,
so that I can hve a correct understanding of the problem?

 Best regards,
 Darwin

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


Re: [U-Boot] please pull u-boot-samsung master

2014-06-02 Thread Albert ARIBAUD
Hi Minkyu,

On Sat, 31 May 2014 14:29:43 +0900, Minkyu Kang mk7.k...@samsung.com
wrote:

 Dear Albert,
 
 The following changes since commit 44cfc3a83f2a62963af2de8d983daf4c77e1db0c:
 
   Merge branch 'u-boot-tegra/master' into 'u-boot-arm/master' (2014-05-15 
 17:19:45 +0200)
 
 are available in the git repository at:
 
 
   http://git.denx.de/u-boot-samsung 
 
 for you to fetch changes up to 567802bbd6bf1c809d37fef9244fc8a692244e73:
 
   Exynos: Make sure ps_hold gets set in the SPL (2014-05-31 14:22:20 +0900)
 
 
 Aaron Durbin (3):
   exynos5: Enable tps65090 on exynos5-dt
   power: Explicitly select pmic device's bus
   exynos5: support tps65090 pmic
 
 Beomho Seo (3):
   arm: exynos: pinmux: add sdmmc4 gpio configratuion
   arm: exynos: clock: Remove exynos4x12_set_mmc_clk function
   board: trats2: Enable device tree on Trats2
 
 Doug Anderson (1):
   Exynos: Make sure ps_hold gets set in the SPL
 
 Jaehoon Chung (12):
   ARM: exynos: board: change the mmc/sd init sequence
   ARM: exynos: clock: modify the set_mmc_clk for exynos4
   ARM: dts: exynos: rename from EXYNOS5_DWMMC to EXYNOS_DWMMC
   mmc: exynos_dw_mmc: restore the property into host
   mmc: remove the unnecessary define and fix the wrong bit control
   mmc: support the DDR mode for eMMC
   mmc: dw_mmc: support the DDR mode
   ARM: dts: exnyos: enable dw-mmc controller
   mmc: exynos_dw_mmc: enable the DDR mode
   ARM: exynos4: enable the dwmmc configuration
   mmc: s5p_sdhci: add the s5p_sdhci_core_init function
   ARM: exynos5420: removed undefined gpio structure
 
 Mateusz Zalega (4):
   arm: goni: Update configuration for Goni target
   arm: goni: dfu: Add support for DFU to Goni target
   arm: goni: enable GPT command
   arm: goni: enable USB Mass Storage
 
 Piotr Wilczek (1):
   arm:board:exynos4: add CONFIG_SYS_GENERIC_BOARD
 
 Simon Glass (8):
   exynos: dts: Correct EC interrupt GPIO
   exynos: Drop old smdk5250.c file
   power: Rename CONFIG_PMIC_... to CONFIG_POWER_...
   power: Add PMIC_ prefix to CHARGER_EN/DISABLE
   exynos: Enable PSHOLD in SPL
   exynos: dts: Enable LCD for snow
   exynos: Enable the LCD backlight for snow
   initcall: Improve debugging support
 
 Tom Wai-Hong Tam (1):
   power: Add support for TPS65090 PMU chip.
 
  arch/arm/cpu/armv7/exynos/clock.c   |   45 +--
  arch/arm/cpu/armv7/exynos/lowlevel_init.c   |8 +-
  arch/arm/cpu/armv7/exynos/pinmux.c  |   35 ++-
  arch/arm/cpu/armv7/exynos/power.c   |6 +
  arch/arm/dts/exynos4.dtsi   |8 +
  arch/arm/dts/exynos4412-trats2.dts  |   12 +
  arch/arm/dts/exynos5.dtsi   |8 +-
  arch/arm/dts/exynos5250-snow.dts|   61 +++-
  arch/arm/include/asm/arch-exynos/clk.h  |5 +
  arch/arm/include/asm/arch-exynos/power.h|1 +
  board/samsung/common/board.c|   13 +-
  board/samsung/goni/goni.c   |8 +
  board/samsung/smdk5250/Makefile |4 -
  board/samsung/smdk5250/exynos5-dt.c |  238 ++-
  board/samsung/smdk5250/smdk5250.c   |  363 
 ---
  board/samsung/smdk5420/smdk5420.c   |3 -
  doc/device-tree-bindings/exynos/dwmmc.txt   |8 +-
  doc/device-tree-bindings/power/tps65090.txt |   17 ++
  doc/device-tree-bindings/regulator/tps65090.txt |  122 
  drivers/mmc/dw_mmc.c|   12 +-
  drivers/mmc/exynos_dw_mmc.c |  205 -
  drivers/mmc/mmc.c   |   16 +-
  drivers/mmc/s5p_sdhci.c |   42 ++-
  drivers/power/battery/bat_trats.c   |4 +-
  drivers/power/battery/bat_trats2.c  |2 +-
  drivers/power/mfd/pmic_max77693.c   |2 +-
  drivers/power/pmic/Makefile |1 +
  drivers/power/pmic/pmic_max8997.c   |2 +-
  drivers/power/pmic/pmic_tps65090.c  |  310 +++
  drivers/power/power_fsl.c   |6 +-
  drivers/power/power_i2c.c   |4 +
  include/configs/arndale.h   |4 +-
  include/configs/exynos4-dt.h|4 +
  include/configs/exynos5-dt.h|1 +
  include/configs/exynos5250-dt.h |2 +-
  include/configs/mx25pdk.h   |2 +-
  include/configs/mx35pdk.h   |2 +-
  include/configs/mx53evk.h   |2 +-
  include/configs/mx53loco.h  |2 +-
  include/configs/s5p_goni.h  |  113 ---
  include/configs/woodburn_common.h   |2 +-
  include/dwmmc.h

Re: [U-Boot] [PATCH] tam3517: fix NAND detection

2014-06-02 Thread Gupta, Pekon
From: Stefano Babic [mailto:sba...@denx.de]
[...]

 diff --git a/include/configs/tam3517-common.h 
 b/include/configs/tam3517-common.h
 index 3522c1a..bd117d5 100644
 --- a/include/configs/tam3517-common.h
 +++ b/include/configs/tam3517-common.h
 @@ -185,6 +185,7 @@
 /* Configure the PISMO */
 #define PISMO1_NAND_SIZEGPMC_SIZE_128M

 +#define CONFIG_NAND

 You should not add CONFIG_NAND directly to include/configs/...
 instead this should come from board profiles defined in boards.cfg
 refer am335x_evm or description given in header of boards.cfg


But TAM3517 is a SOM and it has always NAND. It is slightly different as
the am335x_evm. All boards using this SOM are then affected by this
problem, and fixing it in the SOM configuration file let us to make a
global fix for all boards, instead of adding CONFIG_NAND for each single
profile in boards.cfg.

Oh sorry, yes I forgot it’s a OMAP3 variant (same family).
So this can also be added to include/configs/ti_omap3_common.h
But as you are not re-using that config file, please proceed with above change.


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


[U-Boot] [Patman Bug Report] Patman breaks git-log during git-rebase

2014-06-02 Thread Masahiro Yamada
Hi Simon,

I found an odd behavior of Patman.

If I run Patman during git rebase -i,
Patman rewrites git-log, stripping all the Patman-tags.
(I lost some important tags such as Series-changes.)

I think git-log should be read-only during Patman operation.
I can't understand why Patman needs to directly edit git-log.
Is this a fixable problem?

Best Regards
Masahiro Yamada

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


Re: [U-Boot] [PATCH 9/9] arm: ls102xa: Add basic support for LS1021AQDS board

2014-06-02 Thread Huan Wang
Hi, Fabio,

On Fri, May 30, 2014 at 4:23 AM, Alison Wang b18...@freescale.com wrote:

 +#define CONFIG_EXTRA_ENV_SETTINGS  \
 +   ethaddr=00:e0:0c:bc:e5:60\0   \
 +   eth1addr=00:e0:0c:bc:e5:61\0  \
 +   eth2addr=00:e0:0c:bc:e5:62\0  \
 +   eth3addr=00:e0:0c:bc:e5:63\0  \
 +   ipaddr=192.168.1.100\0    \

You should not hardcode any ethaddr/ipaddr.

[Alison Wang] I will remove them in v2. Thanks.

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


Re: [U-Boot] [Patch v3 2/4] ARMv8/FSL_LSCH3: Add FSL_LSCH3 SoC

2014-06-02 Thread Mark Rutland
On Thu, May 29, 2014 at 06:37:36PM +0100, Rob Herring wrote:
 On Thu, May 29, 2014 at 10:19 AM, York Sun york...@freescale.com wrote:
  On 05/29/2014 06:19 AM, Rob Herring wrote:
  On Wed, May 28, 2014 at 6:46 PM, York Sun york...@freescale.com wrote:
 
  snip
 
  +static void set_pgtable_section(u64 *page_table, u64 index, u64 section,
  +   u8 memory_type)
  +{
  +   u64 value;
  +
  +   value = section | PMD_TYPE_SECT | PMD_SECT_AF;
  +   value |= PMD_ATTRINDX(memory_type);
  +   page_table[index] = value;
  +}
 
  This function looks like it should be common.
 
 
  There is a common version in arch/arm/cpu/armv8/cache_v8.c. This version has
  more flexibility. I am not sure which one will be used as common.
 
 Then add the flexibility to the common one.
 
 
  +   el = current_el();
 
  We really can't have u-boot running at random ELs in v8 for different
  platforms. It's a mess on v7. You should never be at EL3. u-boot could
  be defined to run at EL1, but then you need to be able to go back to
  EL2 to boot the kernel. So really u-boot should always run at EL2
  unless you are running in a VM, but that would be a different
  platform.
 
  I have to run u-boot at EL3. Otherwise I can't access Dickens. I vaguely
  remember other reasons. I will have to dig it out if needed.
 
 You may start in EL3, but then the early init code should drop to EL2.
 If you need EL3 later on for something PSCI does not address, then you
 are probably doing things wrong.
 
  + * flush_l3_cache
  + * Dickens L3 cache can be flushed by transitioning from FAM to SFONLY 
  power
  + * state, by writing to HP-F P-state request register.
 
  Other SOCs will have Dickens. Are these registers FSL specific? If
  not, this should be common.
 
  I don't think they are FSL specific. But I haven't found a proper place to 
  host
  it. Can you share what other SoCs have Dickens? If they are not supported 
  yet,
  we can keep the code here until we are clear then move it out.
 
 It is safe to say most if not all SOCs based on A53 and/or A57 will
 also be based on Dickens aka CCN-504.
 
  Also, I believe the proper way to flush Dickens is using the
  architected cache flushing method where you walk the levels out to
  level 3.
 
  False. L3 cache gets flushed with instruction DCCIVAC. So if we flush the 
  cache
  by range, it works OK. But it doesn't work with DCISW or DCCISW. If we flush
  cache by walking the levels, it doesn't work. We can only walk level 1 and 
  level 2.
 
 So the EL3 boot code should do any one-time invalidate all operations
 and u-boot in EL2 should only use range operations. There are
 limitations in the by way operations such as they are not SMP safe. If
 the by way operations are EL3 only, then that's probably a sign you
 are not doing things as intended. Or it could be an oversight and we
 need to figure out a common way to handle this across SOCs.

This is the only sane way of doing things.

The set/way operations can only be used for two things:

* One-off IMPLEMENTATION DEFINED cache initialisation (for power on).

* Emptying of a given CPU's architected cache levels (which is only
  necessary for power off).

In neither of these cases are the operations used to provide any sort of
visibility guarantee (i.e. they do not make uncached data visible to
CPUs, or cached data visible to other observers). In both of these cases
if you have PSCI this is hidden by the implementation.

It should be entirely possible to flush/clean the data/area you care
about by VA.

Given that this L3 cache and (IIRC the APM L3) can handle VA operations,
I would rather that U-boot and general purposes OSs assume that there is
such a cache present always, which is outside of our control and already
enabled. While this necessitates some cache flushing before turning the
MMU and caches on, it will otherwise be transparent.

This is what we exepect in Linux since c218bca74eea (arm64: Relax the
kernel cache requirements for boot). It makes a single image possible in
the presnce of system caches, and makes things consistent for KVM,
kexec, and chain-loading U-Boot.

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


[U-Boot] imx6 booting from NAND with bad block 0

2014-06-02 Thread Andy Ng
I have an imx6 solo system and currently I am using the SD card to
boot the u-boot.
I would like to make it boot from NAND, but my first Block in NAND is a bad one.
Do I need u-boot with NAND  SPL support?

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


Re: [U-Boot] [Patch v4 2/5] ARMv8: Adjust MMU setup

2014-06-02 Thread Mark Rutland
On Thu, May 29, 2014 at 09:49:05PM +0100, York Sun wrote:
 Make MMU functions reusable. Platform code can setup its own MMU tables.

What exactly does platform code need to setup its own tables for?

 Also fix a typo of TCR_EL3_IPS_BITS in cache_v8.c.
 
 Signed-off-by: York Sun york...@freescale.com
 CC: David Feng feng...@phytium.com.cn
 ---
 Change log:
  v4: new patch, splitted from v3 2/4
  Revise set_pgtable_section() to be reused by platform MMU code
  Add inline function set_ttbr_tcr_mair() to be used by this and platform 
 mmu code
 
  arch/arm/cpu/armv8/cache_v8.c|   49 
 --
  arch/arm/include/asm/armv8/mmu.h |   23 ++
  2 files changed, 43 insertions(+), 29 deletions(-)
 
 diff --git a/arch/arm/cpu/armv8/cache_v8.c b/arch/arm/cpu/armv8/cache_v8.c
 index a96ecda..67dbd46 100644
 --- a/arch/arm/cpu/armv8/cache_v8.c
 +++ b/arch/arm/cpu/armv8/cache_v8.c
 @@ -12,15 +12,14 @@
  DECLARE_GLOBAL_DATA_PTR;
  
  #ifndef CONFIG_SYS_DCACHE_OFF
 -
 -static void set_pgtable_section(u64 section, u64 memory_type)
 +void set_pgtable_section(u64 *page_table, u64 index, u64 section,
 +  u64 memory_type)
  {
 - u64 *page_table = (u64 *)gd-arch.tlb_addr;
   u64 value;
  
 - value = (section  SECTION_SHIFT) | PMD_TYPE_SECT | PMD_SECT_AF;
 + value = section | PMD_TYPE_SECT | PMD_SECT_AF;
   value |= PMD_ATTRINDX(memory_type);
 - page_table[section] = value;
 + page_table[index] = value;
  }
  
  /* to activate the MMU we need to set up virtual memory */
 @@ -28,10 +27,13 @@ static void mmu_setup(void)
  {
   int i, j, el;
   bd_t *bd = gd-bd;
 + u64 *page_table = (u64 *)gd-arch.tlb_addr;
  
   /* Setup an identity-mapping for all spaces */
 - for (i = 0; i  (PGTABLE_SIZE  3); i++)
 - set_pgtable_section(i, MT_DEVICE_NGNRNE);
 + for (i = 0; i  (PGTABLE_SIZE  3); i++) {
 + set_pgtable_section(page_table, i, i  SECTION_SHIFT,
 + MT_DEVICE_NGNRNE);
 + }
  
   /* Setup an identity-mapping for all RAM space */
   for (i = 0; i  CONFIG_NR_DRAM_BANKS; i++) {
 @@ -39,36 +41,25 @@ static void mmu_setup(void)
   ulong end = bd-bi_dram[i].start + bd-bi_dram[i].size;
   for (j = start  SECTION_SHIFT;
j  end  SECTION_SHIFT; j++) {
 - set_pgtable_section(j, MT_NORMAL);
 + set_pgtable_section(page_table, j, j  SECTION_SHIFT,
 + MT_NORMAL);
   }
   }
  
   /* load TTBR0 */
   el = current_el();
   if (el == 1) {
 - asm volatile(msr ttbr0_el1, %0
 -  : : r (gd-arch.tlb_addr) : memory);
 - asm volatile(msr tcr_el1, %0
 -  : : r (TCR_FLAGS | TCR_EL1_IPS_BITS)
 -  : memory);
 - asm volatile(msr mair_el1, %0
 -  : : r (MEMORY_ATTRIBUTES) : memory);
 + set_ttbr_tcr_mair(el, gd-arch.tlb_addr,
 +   TCR_FLAGS | TCR_EL1_IPS_BITS,
 +   MEMORY_ATTRIBUTES);
   } else if (el == 2) {
 - asm volatile(msr ttbr0_el2, %0
 -  : : r (gd-arch.tlb_addr) : memory);
 - asm volatile(msr tcr_el2, %0
 -  : : r (TCR_FLAGS | TCR_EL2_IPS_BITS)
 -  : memory);
 - asm volatile(msr mair_el2, %0
 -  : : r (MEMORY_ATTRIBUTES) : memory);
 + set_ttbr_tcr_mair(el, gd-arch.tlb_addr,
 +   TCR_FLAGS | TCR_EL2_IPS_BITS,
 +   MEMORY_ATTRIBUTES);
   } else {
 - asm volatile(msr ttbr0_el3, %0
 -  : : r (gd-arch.tlb_addr) : memory);
 - asm volatile(msr tcr_el3, %0
 -  : : r (TCR_FLAGS | TCR_EL2_IPS_BITS)
 -  : memory);
 - asm volatile(msr mair_el3, %0
 -  : : r (MEMORY_ATTRIBUTES) : memory);
 + set_ttbr_tcr_mair(el, gd-arch.tlb_addr,
 +   TCR_FLAGS | TCR_EL3_IPS_BITS,
 +   MEMORY_ATTRIBUTES);
   }
  
   /* enable the mmu */
 diff --git a/arch/arm/include/asm/armv8/mmu.h 
 b/arch/arm/include/asm/armv8/mmu.h
 index 1193e76..7de4ff9 100644
 --- a/arch/arm/include/asm/armv8/mmu.h
 +++ b/arch/arm/include/asm/armv8/mmu.h
 @@ -108,4 +108,27 @@
   TCR_IRGN_WBWA | \
   TCR_T0SZ(VA_BITS))
  
 +#ifndef __ASSEMBLY__
 +void set_pgtable_section(u64 *page_table, u64 index,
 +  u64 section, u64 memory_type);
 +static inline void set_ttbr_tcr_mair(int el, u64 table, u64 tcr, u64 attr)
 +{
 + asm volatile(dsb sy;isb);

Huh? This wasn't anywhere before. Is the 

[U-Boot] [PATCH v4 1/3] mtd: nand: omap_gpmc: use macro for register definitions

2014-06-02 Thread Pekon Gupta
GPMC can support simultaneous processing of 8 512Byte data chunks, in parallel

Signed-off-by: Pekon Gupta pe...@ti.com
---
 include/linux/mtd/omap_gpmc.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/include/linux/mtd/omap_gpmc.h b/include/linux/mtd/omap_gpmc.h
index 22f6573..d55fe32 100644
--- a/include/linux/mtd/omap_gpmc.h
+++ b/include/linux/mtd/omap_gpmc.h
@@ -11,6 +11,7 @@
 
 #define GPMC_BUF_EMPTY 0
 #define GPMC_BUF_FULL  1
+#define GPMC_MAX_SECTORS   8
 
 enum omap_ecc {
/* 1-bit  ECC calculation by Software, Error detection by Software */
@@ -75,7 +76,7 @@ struct gpmc {
u8 res7[12];/* 0x224 */
u32 testmomde_ctrl; /* 0x230 */
u8 res8[12];/* 0x234 */
-   struct bch_res_0_3 bch_result_0_3[2];   /* 0x240 */
+   struct bch_res_0_3 bch_result_0_3[GPMC_MAX_SECTORS]; /* 0x240,0x250, */
 };
 
 /* Used for board specific gpmc initialization */
-- 
1.8.5.1.163.gd7aced9

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


[U-Boot] [PATCH v4 0/3] mtd: nand: omap: add support for BCH16_ECC

2014-06-02 Thread Pekon Gupta
This patch series should be picked above
http://lists.denx.de/pipermail/u-boot/2014-April/177323.html

*changes v3 - v4*
[PATCH 1/3] (new patch)
[PATCH 2/3] fixed BCH16 implementation for omap_gpmc.c
[PATCH 3/3] (no change)
 include minor clean-up patch to use macro GPMC_MAX_SECTORS

*changes v2 - v3*
- dropped [PATCH] am33xx: elm: add support for BCH16_ECC - ELM driver updates
  re-using existing code in omap_elm.c
- rebased and refreshed above [1] and u-boot-2014.04
- Documentation updated in doc/nand.README


*changes v1 - v2*
- rebased for http://lists.denx.de/pipermail/u-boot/2013-September/162107.html
- minor code cleanup


*original v1*
This patch series add support of BCH16_ECC scheme.
As BCH16_ECC scheme generates 26bytes of ECC syndrome per 512B data,
hence this scheme is usable only for NAND devices having 4K or above
page-size, as their OOB/spare area has enough space to accomodate ECC.

This patch series is applicable over an above following series:
http://lists.denx.de/pipermail/u-boot/2013-September/161859.html


Pekon Gupta (3):
  mtd: nand: omap_gpmc: use macro for register definitions
  mtd: nand: omap: add support for BCH16_ECC - NAND driver updates
  am335x: update README for BCH16

 doc/README.nand   | 42 +++
 drivers/mtd/nand/omap_gpmc.c  | 79 ++-
 include/linux/mtd/omap_gpmc.h | 11 +-
 3 files changed, 130 insertions(+), 2 deletions(-)

-- 
1.8.5.1.163.gd7aced9

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


[U-Boot] [PATCH v4 3/3] am335x: update README for BCH16

2014-06-02 Thread Pekon Gupta
updates documentation with explanation on how to select ECC schemes.

Signed-off-by: Pekon Gupta pe...@ti.com
---
 doc/README.nand | 42 ++
 1 file changed, 42 insertions(+)

diff --git a/doc/README.nand b/doc/README.nand
index 2bc5b39..70cf768 100644
--- a/doc/README.nand
+++ b/doc/README.nand
@@ -249,6 +249,48 @@ Platform specific options
8-bit BCH code with
- ecc calculation using GPMC hardware engine,
- error detection using ELM hardware engine.
+   OMAP_ECC_BCH16_CODE_HW
+   16-bit BCH code with
+   - ecc calculation using GPMC hardware engine,
+   - error detection using ELM hardware engine.
+
+   How to select ECC scheme on OMAP and AMxx platforms ?
+   -
+   Though higher ECC schemes have more capability to detect and correct
+   bit-flips, but still selection of ECC scheme is dependent on following
+   - hardware engines present in SoC.
+   Some legacy OMAP SoC do not have ELM h/w engine thus such
+   SoC cannot support BCHx_HW ECC schemes.
+   - size of OOB/Spare region
+   With higher ECC schemes, more OOB/Spare area is required to
+   store ECC. So choice of ECC scheme is limited by NAND oobsize.
+
+   In general following expression can help:
+   NAND_OOBSIZE = 2 + (NAND_PAGESIZE / 512) * ECC_BYTES
+   where
+   NAND_OOBSIZE= number of bytes available in
+   OOB/spare area per NAND page.
+   NAND_PAGESIZE   = bytes in main-area of NAND page.
+   ECC_BYTES   = number of ECC bytes generated to
+   protect 512 bytes of data, which is:
+   3 for HAM1_xx ecc schemes
+   7 for BCH4_xx ecc schemes
+   14 for BCH8_xx ecc schemes
+   26 for BCH16_xx ecc schemes
+
+   example to check for BCH16 on 2K page NAND
+   NAND_PAGESIZE = 2048
+   NAND_OOBSIZE = 64
+   2 + (2048 / 512) * 26 = 106  NAND_OOBSIZE
+   Thus BCH16 cannot be supported on 2K page NAND.
+
+   However, for 4K pagesize NAND
+   NAND_PAGESIZE = 4096
+   NAND_OOBSIZE = 64
+   ECC_BYTES = 26
+   2 + (4096 / 512) * 26 = 210  NAND_OOBSIZE
+   Thus BCH16 can be supported on 4K page NAND.
+
 
 NOTE:
 =
-- 
1.8.5.1.163.gd7aced9

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


[U-Boot] [PATCH v4 2/3] mtd: nand: omap: add support for BCH16_ECC - NAND driver updates

2014-06-02 Thread Pekon Gupta
This patch add support for BCH16_ECC to omap_gpmc driver.

*need to BCH16 ECC scheme*
With newer SLC Flash technologies and MLC NAND, and large densities, pagesizes
Flash devices have become more suspectible to bit-flips. Thus stronger
ECC schemes are required for protecting the data.
But stronger ECC schemes have come with larger-sized ECC syndromes which require
more space in OOB/Spare. This puts constrains like;
(a) BCH16_ECC can correct 16 bit-flips per 512Bytes of data.
(b) BCH16_ECC generates 26-bytes of ECC syndrome / 512B.
Due to (b) this scheme can only be used with NAND devices which have enough
OOB to satisfy following equation:
OOBsize per page = 26 * (page-size / 512)

Signed-off-by: Pekon Gupta pe...@ti.com
---
 drivers/mtd/nand/omap_gpmc.c  | 79 ++-
 include/linux/mtd/omap_gpmc.h |  8 +
 2 files changed, 86 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/omap_gpmc.c b/drivers/mtd/nand/omap_gpmc.c
index cdfa6bc..1acf06b 100644
--- a/drivers/mtd/nand/omap_gpmc.c
+++ b/drivers/mtd/nand/omap_gpmc.c
@@ -224,6 +224,19 @@ static void omap_enable_hwecc(struct mtd_info *mtd, 
int32_t mode)
eccsize1 = 2;  /* non-ECC bits in nibbles per sector */
}
break;
+   case OMAP_ECC_BCH16_CODE_HW:
+   ecc_algo = 0x1;
+   bch_type = 0x2;
+   if (mode == NAND_ECC_WRITE) {
+   bch_wrapmode = 0x01;
+   eccsize0 = 0;  /* extra bits in nibbles per sector */
+   eccsize1 = 52; /* OOB bits in nibbles per sector */
+   } else {
+   bch_wrapmode = 0x01;
+   eccsize0 = 52; /* ECC bits in nibbles per sector */
+   eccsize1 = 0;  /* non-ECC bits in nibbles per sector */
+   }
+   break;
default:
return;
}
@@ -290,6 +303,29 @@ static int omap_calculate_ecc(struct mtd_info *mtd, const 
uint8_t *dat,
ptr--;
}
break;
+   case OMAP_ECC_BCH16_CODE_HW:
+   val = readl(gpmc_cfg-bch_result_4_6[0].bch_result_x[2]);
+   ecc_code[i++] = (val   8)  0xFF;
+   ecc_code[i++] = (val   0)  0xFF;
+   val = readl(gpmc_cfg-bch_result_4_6[0].bch_result_x[1]);
+   ecc_code[i++] = (val  24)  0xFF;
+   ecc_code[i++] = (val  16)  0xFF;
+   ecc_code[i++] = (val   8)  0xFF;
+   ecc_code[i++] = (val   0)  0xFF;
+   val = readl(gpmc_cfg-bch_result_4_6[0].bch_result_x[0]);
+   ecc_code[i++] = (val  24)  0xFF;
+   ecc_code[i++] = (val  16)  0xFF;
+   ecc_code[i++] = (val   8)  0xFF;
+   ecc_code[i++] = (val   0)  0xFF;
+   for (j = 3; j = 0; j--) {
+   val = readl(gpmc_cfg-bch_result_0_3[0].bch_result_x[j]
+   );
+   ecc_code[i++] = (val  24)  0xFF;
+   ecc_code[i++] = (val  16)  0xFF;
+   ecc_code[i++] = (val   8)  0xFF;
+   ecc_code[i++] = (val   0)  0xFF;
+   }
+   break;
default:
return -EINVAL;
}
@@ -308,6 +344,8 @@ static int omap_calculate_ecc(struct mtd_info *mtd, const 
uint8_t *dat,
case OMAP_ECC_BCH8_CODE_HW:
ecc_code[chip-ecc.bytes - 1] = 0x00;
break;
+   case OMAP_ECC_BCH16_CODE_HW:
+   break;
default:
return -EINVAL;
}
@@ -333,7 +371,7 @@ static int omap_correct_data_bch(struct mtd_info *mtd, 
uint8_t *dat,
struct omap_nand_info *info = chip-priv;
struct nand_ecc_ctrl *ecc = chip-ecc;
uint32_t error_count = 0, error_max;
-   uint32_t error_loc[8];
+   uint32_t error_loc[ELM_MAX_ERROR_COUNT];
enum bch_level bch_type;
uint32_t i, ecc_flag = 0;
uint8_t count, err = 0;
@@ -365,6 +403,10 @@ static int omap_correct_data_bch(struct mtd_info *mtd, 
uint8_t *dat,
bch_type = BCH_8_BIT;
omap_reverse_list(calc_ecc, ecc-bytes - 1);
break;
+   case OMAP_ECC_BCH16_CODE_HW:
+   bch_type = BCH_16_BIT;
+   omap_reverse_list(calc_ecc, ecc-bytes);
+   break;
default:
return -EINVAL;
}
@@ -381,6 +423,9 @@ static int omap_correct_data_bch(struct mtd_info *mtd, 
uint8_t *dat,
/* 14th byte in ECC is reserved to match ROM layout */
error_max = SECTOR_BYTES + (ecc-bytes - 1);
break;
+   case OMAP_ECC_BCH16_CODE_HW:
+   error_max = SECTOR_BYTES + ecc-bytes;
+   break;
default:
   

Re: [U-Boot] [PATCH 0/9] Remove MPC82xx, MPC8xx Orphan boards

2014-06-02 Thread Tom Rini
On Fri, May 30, 2014 at 05:44:55PM +0900, Masahiro Yamada wrote:

 
 The maintainers are no longer repsponding.
 
 These boards are so old that nobody would have
 motivation to maintain them.
 
 I built all the other boards.
 I confirmed there is no impact to the other boards.
 
 Apply Wolfgang's patch first:
 http://patchwork.ozlabs.org/patch/353935/
 
 to avoid a conflict of doc/README.scrapyard.
 
 
 
 Masahiro Yamada (9):
   powerpc: adder: remove orphan board
   powerpc: mpc8260ads: remove orphan board
   powerpc: zpc1900: remove orphan board
   powerpc: rattler: remove orphan board
   powerpc: ispan: remove orphan board
   powerpc: ep8248: remove orphan board
   powerpc: kvme080: remove orphan board
   powerpc: debris: remove orphan board
   powerpc: hiddendragon: remove orphan board
 
  README  |   8 -
  arch/powerpc/cpu/mpc8260/pci.c  |   2 -
  arch/powerpc/cpu/mpc8260/start.S|  13 -
  arch/powerpc/include/asm/processor.h|  12 -
  board/adder/Makefile|  11 -
  board/adder/adder.c | 108 -
  board/adder/u-boot.lds  |  79 
  board/ep8248/Makefile   |   8 -
  board/ep8248/ep8248.c   | 254 
  board/etin/debris/Makefile  |   8 -
  board/etin/debris/debris.c  | 174 
  board/etin/debris/flash.c   | 705 
 
  board/etin/debris/phantom.c | 301 --
  board/etin/kvme080/Makefile |   8 -
  board/etin/kvme080/kvme080.c| 184 -
  board/etin/kvme080/multiverse.c | 184 -
  board/etin/kvme080/multiverse.h | 173 
  board/freescale/mpc8260ads/Makefile |   8 -
  board/freescale/mpc8260ads/flash.c  | 476 -
  board/freescale/mpc8260ads/mpc8260ads.c | 544 
  board/hidden_dragon/Makefile|   8 -
  board/hidden_dragon/README  |  60 ---
  board/hidden_dragon/flash.c | 559 -
  board/hidden_dragon/hidden_dragon.c |  85 
  board/ispan/Makefile|  11 -
  board/ispan/ispan.c | 448 
  board/rattler/Makefile  |   8 -
  board/rattler/rattler.c | 215 --
  board/zpc1900/Makefile  |   8 -
  board/zpc1900/zpc1900.c | 288 -
  boards.cfg  |  27 --
  doc/README.scrapyard|   9 +
  include/common.h|   2 -
  include/configs/Adder.h | 193 -
  include/configs/HIDDEN_DRAGON.h | 371 -
  include/configs/ISPAN.h | 330 ---
  include/configs/MPC8260ADS.h| 549 -
  include/configs/Rattler.h   | 279 -
  include/configs/ZPC1900.h   | 261 
  include/configs/debris.h| 443 
  include/configs/ep8248.h| 253 
  include/configs/kvme080.h   | 251 
  include/mpc8260.h   |   4 -
  43 files changed, 9 insertions(+), 7913 deletions(-)
  delete mode 100644 board/adder/Makefile
  delete mode 100644 board/adder/adder.c
  delete mode 100644 board/adder/u-boot.lds
  delete mode 100644 board/ep8248/Makefile
  delete mode 100644 board/ep8248/ep8248.c
  delete mode 100644 board/etin/debris/Makefile
  delete mode 100644 board/etin/debris/debris.c
  delete mode 100644 board/etin/debris/flash.c
  delete mode 100644 board/etin/debris/phantom.c
  delete mode 100644 board/etin/kvme080/Makefile
  delete mode 100644 board/etin/kvme080/kvme080.c
  delete mode 100644 board/etin/kvme080/multiverse.c
  delete mode 100644 board/etin/kvme080/multiverse.h
  delete mode 100644 board/freescale/mpc8260ads/Makefile
  delete mode 100644 board/freescale/mpc8260ads/flash.c
  delete mode 100644 board/freescale/mpc8260ads/mpc8260ads.c
  delete mode 100644 board/hidden_dragon/Makefile
  delete mode 100644 board/hidden_dragon/README
  delete mode 100644 board/hidden_dragon/flash.c
  delete mode 100644 board/hidden_dragon/hidden_dragon.c
  delete mode 100644 board/ispan/Makefile
  delete mode 100644 board/ispan/ispan.c
  delete mode 100644 board/rattler/Makefile
  delete mode 100644 board/rattler/rattler.c
  delete mode 100644 board/zpc1900/Makefile
  delete mode 100644 board/zpc1900/zpc1900.c
  delete mode 100644 include/configs/Adder.h
  delete mode 100644 include/configs/HIDDEN_DRAGON.h
  delete mode 100644 include/configs/ISPAN.h
  delete mode 100644 include/configs/MPC8260ADS.h
  delete mode 100644 include/configs/Rattler.h
  delete mode 100644 include/configs/ZPC1900.h
  delete mode 100644 include/configs/debris.h
  delete mode 100644 include/configs/ep8248.h
  delete mode 100644 

Re: [U-Boot] [PATCH] PPC4xx: Remove quad100hd board

2014-06-02 Thread Tom Rini
On Thu, May 29, 2014 at 11:54:06AM +0200, Wolfgang Denk wrote:

 The quad100hd has been unmaintained and dead ever since it's been
 added some 6 years ago.  Remove it.
 
 Also update README.scrapyard and insert some commit IDs for removed
 boards.
 
 Signed-off-by: Wolfgang Denk w...@denx.de
 Cc: Stefan Roese s...@denx.de
 Cc: Gary Jennejohn gljennj...@googlemail.com

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [PATCH 2/4] Exynos5: Config: Place environment at the end of SPI Flash

2014-06-02 Thread Simon Glass
Hi Akshay,

On 30 May 2014 07:45, Akshay Saraswat aksha...@samsung.com wrote:
 Currently environment resides at the location where BL2 ends.
 This may hold good in case there is an empty space at this
 position. But what if this place already has a binary or is
 expected to have one. To avoid such scenarios it is better
 to save environment at the end of the flash.

 Signed-off-by Akshay Saraswat aksha...@samsung.com
 ---
  include/configs/exynos5-dt.h | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

 diff --git a/include/configs/exynos5-dt.h b/include/configs/exynos5-dt.h
 index 5a9b1b4..60b99a3 100644
 --- a/include/configs/exynos5-dt.h
 +++ b/include/configs/exynos5-dt.h
 @@ -207,7 +207,9 @@

  #define CONFIG_BL1_OFFSET  (CONFIG_RES_BLOCK_SIZE + CONFIG_SEC_FW_SIZE)
  #define CONFIG_BL2_OFFSET  (CONFIG_BL1_OFFSET + CONFIG_BL1_SIZE)
 -#define CONFIG_ENV_OFFSET  (CONFIG_BL2_OFFSET + CONFIG_BL2_SIZE)
 +
 +/* Store environment at the end of a 4 MB SPI flash */
 +#define CONFIG_ENV_OFFSET  (0x0040 - CONFIG_BL2_SIZE)

Could we add a define for the SPI flash size and make this line use it?


  /* U-boot copy size from boot Media to DRAM.*/
  #define BL2_START_OFFSET   (CONFIG_BL2_OFFSET/512)
 --
 1.7.12.4


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


Re: [U-Boot] [PATCH 3/4] Exynos5: Config: Increase SPL footprint for Exynos5420

2014-06-02 Thread Simon Glass
Hi Akshay,

On 30 May 2014 07:45, Akshay Saraswat aksha...@samsung.com wrote:
 Max footprint for SPL in both Exynos 5250 and 5420 is limited to 14 KB.
 For Exynos5250 we need to keep it 14 KB because BL1 supports only fixed
 size SPL downloading. But in case of Exynos5420 we need not restrict it
 to 14 KB. And also, the SPL size for Exynos5420 is expected to increase
 with the upcoming patches and the patches under review right now.

 Signed-off-by: Akshay Saraswat aksha...@samsung.com
 ---
  include/configs/exynos5-dt.h| 2 --
  include/configs/exynos5250-dt.h | 2 ++
  include/configs/exynos5420.h| 2 ++
  3 files changed, 4 insertions(+), 2 deletions(-)

 diff --git a/include/configs/exynos5-dt.h b/include/configs/exynos5-dt.h
 index 60b99a3..9900baf 100644
 --- a/include/configs/exynos5-dt.h
 +++ b/include/configs/exynos5-dt.h
 @@ -144,8 +144,6 @@

  /* specific .lds file */
  #define CONFIG_SPL_LDSCRIPTboard/samsung/common/exynos-uboot-spl.lds
 -#define CONFIG_SPL_MAX_FOOTPRINT   (14 * 1024)
 -

  /* Miscellaneous configurable options */
  #define CONFIG_SYS_LONGHELP/* undef to save memory */
 diff --git a/include/configs/exynos5250-dt.h b/include/configs/exynos5250-dt.h
 index b7ff472..9fff1af 100644
 --- a/include/configs/exynos5250-dt.h
 +++ b/include/configs/exynos5250-dt.h
 @@ -20,6 +20,8 @@
  #define MACH_TYPE_SMDK5250 3774
  #define CONFIG_MACH_TYPE   MACH_TYPE_SMDK5250

 +#define CONFIG_SPL_MAX_FOOTPRINT   (14 * 1024)
 +
  /* USB */
  #define CONFIG_CMD_USB
  #define CONFIG_USB_XHCI
 diff --git a/include/configs/exynos5420.h b/include/configs/exynos5420.h
 index 3a28bbc..fd25820 100644
 --- a/include/configs/exynos5420.h
 +++ b/include/configs/exynos5420.h
 @@ -25,6 +25,8 @@
  #endif
  #define CONFIG_IRAM_TOP0x02074000

 +#define CONFIG_SPL_MAX_FOOTPRINT   (32 * 1024)

Should this be 30? I think normally there is a 2KB space after it, so
we use either 14KB or 30KB.

 +
  #define CONFIG_DEVICE_TREE_LIST exynos5420-peach-pit exynos5420-smdk5420

  #define CONFIG_MAX_I2C_NUM 11
 --
 1.7.12.4


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


Re: [U-Boot] [PATCH 4/4] Exynos5: Config: Enable USB boot mode for all Exynos5 SoCs

2014-06-02 Thread Simon Glass
On 30 May 2014 07:45, Akshay Saraswat aksha...@samsung.com wrote:
 Right now USB booting is enabled for Exynos5250 only. Moving all the
 configs for USB boot mode from exynos5250-dt.h to exynos5-dt.h in order
 to enableUSB booting for all Exynos5 SoCs.

 Signed-off-by: Akshay Saraswat aksha...@samsung.com

Acked-by: Simon Glass s...@chromium.org
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 1/4] Exynos: SPI: Fix reading data from SPI flash

2014-06-02 Thread Simon Glass
Hi Akshay,

On 30 May 2014 07:45, Akshay Saraswat aksha...@samsung.com wrote:
 SPI recieve and transfer code in exynos_spi driver has a logical bug.
 We read data in a variable which can hold an integer. Then we assign
 this integer 32 bit value to another variable which has data type uchar.
 Latter represents a unit of our recieve buffer. Everytime when we write
 a value to our recieve buffer we step ahead by 4 units when actually we
 wrote to one unit. This results in the loss of 3 bytes out of every 4
 bytes recieved. This patch intends to fix this bug.

 Signed-off-by: Akshay Saraswat aksha...@samsung.com
 ---
  drivers/spi/exynos_spi.c | 3 +++
  1 file changed, 3 insertions(+)

 diff --git a/drivers/spi/exynos_spi.c b/drivers/spi/exynos_spi.c
 index 4d5def2..b9fd618 100644
 --- a/drivers/spi/exynos_spi.c
 +++ b/drivers/spi/exynos_spi.c
 @@ -302,6 +302,9 @@ static int spi_rx_tx(struct exynos_spi_slave *spi_slave, 
 int todo,
 }
 } else {
 if (rxp || stopping) {
 +   *(rxp + 3) = (temp  24);
 +   *(rxp + 2) = (temp  16);
 +   *(rxp + 1) = (temp  8);
 *rxp = temp;
 rxp += step;

Here step is either 1 (bytes) or 4 (words). So I think you are making
an assumption here. If you look up a bit you can see what it does for
txp (two cases for step being 1 or 4) and I think you should do the
same here.

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


Re: [U-Boot] [RFC PATCH 17/22] dm: Expand and improve the device lifecycle docs

2014-06-02 Thread Simon Glass
+U-Boot list again

Hi Jon,

On 30 May 2014 09:55, Jon Loeliger loeli...@gmail.com wrote:
  Why is the scan only on the top level?  My GPIO nodes are, for example,
  under an SOC node.

 Why? Do you have an SOC driver?

 Hi Simon,

 This gets to my earlier issue:  I want to use the *exact* same DTS file
 for both U-Boot and Linux.  We definitely shouldn't have to copy them
 into both the Kernel and U-Boot source repositories, and we shouldn't
 have to have two in-memory (or flash) DTB blobs either.

Here's something I wrote while fiddling with Beaglebone which may help.

First a note that may to help avoid confusion. U-Boot and Linux both
use device tree. They may use the same device tree source, but it is
seldom useful for them to use the exact same binary from the same
place. More typically, U-Boot has its device tree packaged wtih it,
and the kernel's device tree is packaged with the kernel. In
particular this is important with verified boot, since U-Boot's device
tree must be immutable. If it can be changed then the public keys can
be changed and verified boot is useless. An attacker can simply
generate a new key and put his public key into U-Boot so that
everything verifies. On the other hand the kernel's device tree
typically changes when the kernel changes, so it is useful to package
an updated device tree with the kernel binary. U-Boot supports the
latter with its flexible FIT format (Flat Image Tree).


Re the two source repositories, you can set up any sort of repo that
you like for your .dts files, but they are in the U-Boot and kernel
repos at present.



 And yes, all the GPIO nodes are under an SoC bus node.

 For example, here is the versatile express DTS from the kernel repository
 with the same device (pl061) I am needing:

 $ less versatile-pb.dts
 #include versatile-ab.dts

 / {
 model = ARM Versatile PB;
 compatible = arm,versatile-pb;

 amba {
 gpio2: gpio@101e6000 {
 compatible = arm,pl061, arm,primecell;
 reg = 0x101e6000 0x1000;
 interrupts = 8;
 gpio-controller;
 #gpio-cells = 2;
 interrupt-controller;
 #interrupt-cells = 2;
 };

 gpio3: gpio@101e7000 {
 compatible = arm,pl061, arm,primecell;
 reg = 0x101e7000 0x1000;
 interrupts = 9;
 gpio-controller;
 #gpio-cells = 2;
 interrupt-controller;
 #interrupt-cells = 2;
 };

 fpga {
 uart@9000 {
 compatible = arm,pl011, arm,primecell;
 reg = 0x9000 0x1000;
 interrupt-parent = sic;
 interrupts = 6;
 };
 sci@a000 {
 compatible = arm,primecell;
 reg = 0xa000 0x1000;
 interrupt-parent = sic;
 interrupts = 5;
 };
 mmc@b000 {
 compatible = arm,primecell;
 reg = 0xb000 0x1000;
 interrupts-extended = vic 23 sic 2;
 };
 };
 };
 };

 #include testcases.dtsi

 So yes,  I think we need more iterative structure in the DTS parsing for 
 U-Boot.

Here I expect you would have a driver for the amba bus, and then that
driver would do the scan. The devices should have the amba bus as
their parent.

One reason for this is that the bus may have its own access mechanism
which needs to be provided to devices in that bus (e.g. I2C, SPI, PCI,
SCSI, etc.)

I'm not saying we don't want to scan the tree more deeply, but until
we have a use case for it we should hold off.

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


Re: [U-Boot] [PATCH 0/9] Remove MPC82xx, MPC8xx Orphan boards

2014-06-02 Thread Wolfgang Denk
Dear Tom,

In message 20140602145948.GV5836@bill-the-cat you wrote:
 
powerpc: adder: remove orphan board
powerpc: mpc8260ads: remove orphan board
powerpc: zpc1900: remove orphan board
powerpc: rattler: remove orphan board
powerpc: ispan: remove orphan board
powerpc: ep8248: remove orphan board
powerpc: kvme080: remove orphan board
powerpc: debris: remove orphan board
powerpc: hiddendragon: remove orphan board
...
 Applied to u-boot/master, thanks!

I was about to send you a pull request for u-boot-mpc8xx and
u-boot-mpc82xx; ok - so I can save this effort - thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Life would be so much easier if we could  just  look  at  the  source
code.   -- Dave Olson
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] dfu: fix some issues with reads/uploads

2014-06-02 Thread Stephen Warren
On 06/02/2014 12:14 AM, Lukasz Majewski wrote:
 Hi Stephen,
 
 On 05/30/2014 02:28 AM, Lukasz Majewski wrote:
 ...
 I've tested if raw u-boot can be downloaded and uploaded via DFU.
 The u-boot size is 1MiB precisely. 

 Corresponding dfu_alt_info entry: 
 u-boot raw 0x80 0x800; \
 ...
 2. Upload (raw):

 dfu-util -a0 -U u-boot-mmc.bin_target
 It exits immediately and I can only see the file size of 0.

 So obviously we have regression here. However, since I didn't
 covered this case in my tests I don't know when it was broken.

 Hmmm. I tested with that exact value of dfu_alt_info and got back an
 exactly 1MB file with either the dfu-util packaged in Ubuntu 12.10, or
 with the latest git tree of dfu-util.
 
 Could you share the exact SHA1 of the dfu-util? Or is it the master
 newest branch?

Distro package:
dfu-util package 0.5-1 in Ubuntu 12.04.

In the git tree:
25c173e3fd0a dfu_prefix: Rewrite handling of prefix requirements
(which was origin/master when I fetched it a week or two ago)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] PPC4xx: Remove quad100hd board

2014-06-02 Thread Wolfgang Denk
Dear Tom,

In message 20140602145956.GW5836@bill-the-cat you wrote:
 
  The quad100hd has been unmaintained and dead ever since it's been
  added some 6 years ago.  Remove it.
...
 Applied to u-boot/master, thanks!

Umm... I have neither seen a pull request nor an ACK from Stefan.
Should we not wait for the custodians to pick this up?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Gods don't like people not doing much work. People  who  aren't  busy
all the time might start to _think_.  - Terry Pratchett, _Small Gods_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 1/3] cmd_mmc: add force_init parameter to init_mmc_device()

2014-06-02 Thread Stephen Warren
On 06/01/2014 10:59 PM, Jaehoon Chung wrote:
 Hi, Stephen.
 
 Your patch-set looks good to me.
 
 Acked-by: Jaehoon Chung jh80.ch...@samsung.com
 
 If card didn't insert, can we display the other log instead of the below log?
 
 #mmc rescan
 #mmc dev 1
 Card did not respond to voltage select!

Some SD slots have a card detect GPIO or similar, so it might be
possible to do that. Of course, not all slots have that, and I don't
know how to differentiate card not present from command timed out.
Is there a defined way to do that?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [Patch v4 2/5] ARMv8: Adjust MMU setup

2014-06-02 Thread York Sun
On 06/02/2014 04:34 AM, Mark Rutland wrote:
 On Thu, May 29, 2014 at 09:49:05PM +0100, York Sun wrote:
 Make MMU functions reusable. Platform code can setup its own MMU tables.
 
 What exactly does platform code need to setup its own tables for?

The general ARMv8 MMU table is not detail enough to control memory attribute
like cache for all addresses. We have devices mapping to addresses with
different requirement for cache control.

 
 Also fix a typo of TCR_EL3_IPS_BITS in cache_v8.c.

 Signed-off-by: York Sun york...@freescale.com
 CC: David Feng feng...@phytium.com.cn
 ---
 Change log:
  v4: new patch, splitted from v3 2/4
  Revise set_pgtable_section() to be reused by platform MMU code
  Add inline function set_ttbr_tcr_mair() to be used by this and platform 
 mmu code

  arch/arm/cpu/armv8/cache_v8.c|   49 
 --
  arch/arm/include/asm/armv8/mmu.h |   23 ++
  2 files changed, 43 insertions(+), 29 deletions(-)

 diff --git a/arch/arm/cpu/armv8/cache_v8.c b/arch/arm/cpu/armv8/cache_v8.c
 index a96ecda..67dbd46 100644
 --- a/arch/arm/cpu/armv8/cache_v8.c
 +++ b/arch/arm/cpu/armv8/cache_v8.c
 @@ -12,15 +12,14 @@
  DECLARE_GLOBAL_DATA_PTR;
  
  #ifndef CONFIG_SYS_DCACHE_OFF
 -
 -static void set_pgtable_section(u64 section, u64 memory_type)
 +void set_pgtable_section(u64 *page_table, u64 index, u64 section,
 + u64 memory_type)
  {
 -u64 *page_table = (u64 *)gd-arch.tlb_addr;
  u64 value;
  
 -value = (section  SECTION_SHIFT) | PMD_TYPE_SECT | PMD_SECT_AF;
 +value = section | PMD_TYPE_SECT | PMD_SECT_AF;
  value |= PMD_ATTRINDX(memory_type);
 -page_table[section] = value;
 +page_table[index] = value;
  }
  
  /* to activate the MMU we need to set up virtual memory */
 @@ -28,10 +27,13 @@ static void mmu_setup(void)
  {
  int i, j, el;
  bd_t *bd = gd-bd;
 +u64 *page_table = (u64 *)gd-arch.tlb_addr;
  
  /* Setup an identity-mapping for all spaces */
 -for (i = 0; i  (PGTABLE_SIZE  3); i++)
 -set_pgtable_section(i, MT_DEVICE_NGNRNE);
 +for (i = 0; i  (PGTABLE_SIZE  3); i++) {
 +set_pgtable_section(page_table, i, i  SECTION_SHIFT,
 +MT_DEVICE_NGNRNE);
 +}
  
  /* Setup an identity-mapping for all RAM space */
  for (i = 0; i  CONFIG_NR_DRAM_BANKS; i++) {
 @@ -39,36 +41,25 @@ static void mmu_setup(void)
  ulong end = bd-bi_dram[i].start + bd-bi_dram[i].size;
  for (j = start  SECTION_SHIFT;
   j  end  SECTION_SHIFT; j++) {
 -set_pgtable_section(j, MT_NORMAL);
 +set_pgtable_section(page_table, j, j  SECTION_SHIFT,
 +MT_NORMAL);
  }
  }
  
  /* load TTBR0 */
  el = current_el();
  if (el == 1) {
 -asm volatile(msr ttbr0_el1, %0
 - : : r (gd-arch.tlb_addr) : memory);
 -asm volatile(msr tcr_el1, %0
 - : : r (TCR_FLAGS | TCR_EL1_IPS_BITS)
 - : memory);
 -asm volatile(msr mair_el1, %0
 - : : r (MEMORY_ATTRIBUTES) : memory);
 +set_ttbr_tcr_mair(el, gd-arch.tlb_addr,
 +  TCR_FLAGS | TCR_EL1_IPS_BITS,
 +  MEMORY_ATTRIBUTES);
  } else if (el == 2) {
 -asm volatile(msr ttbr0_el2, %0
 - : : r (gd-arch.tlb_addr) : memory);
 -asm volatile(msr tcr_el2, %0
 - : : r (TCR_FLAGS | TCR_EL2_IPS_BITS)
 - : memory);
 -asm volatile(msr mair_el2, %0
 - : : r (MEMORY_ATTRIBUTES) : memory);
 +set_ttbr_tcr_mair(el, gd-arch.tlb_addr,
 +  TCR_FLAGS | TCR_EL2_IPS_BITS,
 +  MEMORY_ATTRIBUTES);
  } else {
 -asm volatile(msr ttbr0_el3, %0
 - : : r (gd-arch.tlb_addr) : memory);
 -asm volatile(msr tcr_el3, %0
 - : : r (TCR_FLAGS | TCR_EL2_IPS_BITS)
 - : memory);
 -asm volatile(msr mair_el3, %0
 - : : r (MEMORY_ATTRIBUTES) : memory);
 +set_ttbr_tcr_mair(el, gd-arch.tlb_addr,
 +  TCR_FLAGS | TCR_EL3_IPS_BITS,
 +  MEMORY_ATTRIBUTES);
  }
  
  /* enable the mmu */
 diff --git a/arch/arm/include/asm/armv8/mmu.h 
 b/arch/arm/include/asm/armv8/mmu.h
 index 1193e76..7de4ff9 100644
 --- a/arch/arm/include/asm/armv8/mmu.h
 +++ b/arch/arm/include/asm/armv8/mmu.h
 @@ -108,4 +108,27 @@
  TCR_IRGN_WBWA | \
  TCR_T0SZ(VA_BITS))
  
 +#ifndef __ASSEMBLY__
 +void set_pgtable_section(u64 *page_table, u64 index,
 + u64 section, u64 

Re: [U-Boot] [PATCH] mmc: add wrappers for MMC block_{read, write, erase}

2014-06-02 Thread Stephen Warren
On 06/02/2014 12:42 AM, Pantelis Antoniou wrote:
 Hi Steve,
 
 I wanted the discussion to settle a bit before I reply to this series.
 On May 29, 2014, at 1:15 AM, Steve Rae wrote:
 
 Each wrapper function:
 - switches to the specified physical partition, then
 - performs the original function, and then
 - switches back to the original physical partition
 where the physical partition (aka HW partition) is
  0=User, 1=Boot1, 2=Boot2, etc.

 Signed-off-by: Steve Rae s...@broadcom.com
 ---
 
 [snip]
 
 /**
  * Start device initialization and return immediately; it does not block on
  * polling OCR (operation condition register) status.  Then you should call
 -- 
 1.8.5

 
 The thing IMO should be modeled in the same way that block devices work in
 Linux.
 
 TBH I'm not very fond of the way block devices/partitions and the block_ops
 are intermixed in block_dev_t. This part of code could use some refactoring
 to make it operate more like a regular linux block device (with each partition
 being it's own block device), but I don't know if we have enough votes to 
 change
 it ATM.

Refactoring that would make sense to me. That way, any client code could
just pass the user's command-line (or whatever) parameters to some
lookup function, which could return something that accesses whatever the
user wants, without the code that accesses the data caring whether it's
a complete block device, a complete HW partition, or a SW partition
within one of those. Of course, I guess that's already the case, it's
just that the information is split across block_dev_desc_t and
disk_partition_t, when it doesn't really need to be.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [Patch v4 2/5] ARMv8: Adjust MMU setup

2014-06-02 Thread Mark Rutland
On Mon, Jun 02, 2014 at 05:06:13PM +0100, York Sun wrote:
 On 06/02/2014 04:34 AM, Mark Rutland wrote:
  On Thu, May 29, 2014 at 09:49:05PM +0100, York Sun wrote:
  Make MMU functions reusable. Platform code can setup its own MMU tables.
  
  What exactly does platform code need to setup its own tables for?
 
 The general ARMv8 MMU table is not detail enough to control memory attribute
 like cache for all addresses. We have devices mapping to addresses with
 different requirement for cache control.

And there are no APIs for creating device mappings rather than exporting
the raw pagetable accessors and hard-coding them differently in every
board file?

 
  
  Also fix a typo of TCR_EL3_IPS_BITS in cache_v8.c.
 
  Signed-off-by: York Sun york...@freescale.com
  CC: David Feng feng...@phytium.com.cn
  ---
  Change log:
   v4: new patch, splitted from v3 2/4
   Revise set_pgtable_section() to be reused by platform MMU code
   Add inline function set_ttbr_tcr_mair() to be used by this and 
  platform mmu code
 
   arch/arm/cpu/armv8/cache_v8.c|   49 
  --
   arch/arm/include/asm/armv8/mmu.h |   23 ++
   2 files changed, 43 insertions(+), 29 deletions(-)
 
  diff --git a/arch/arm/cpu/armv8/cache_v8.c b/arch/arm/cpu/armv8/cache_v8.c
  index a96ecda..67dbd46 100644
  --- a/arch/arm/cpu/armv8/cache_v8.c
  +++ b/arch/arm/cpu/armv8/cache_v8.c
  @@ -12,15 +12,14 @@
   DECLARE_GLOBAL_DATA_PTR;
   
   #ifndef CONFIG_SYS_DCACHE_OFF
  -
  -static void set_pgtable_section(u64 section, u64 memory_type)
  +void set_pgtable_section(u64 *page_table, u64 index, u64 section,
  +   u64 memory_type)
   {
  -  u64 *page_table = (u64 *)gd-arch.tlb_addr;
 u64 value;
   
  -  value = (section  SECTION_SHIFT) | PMD_TYPE_SECT | PMD_SECT_AF;
  +  value = section | PMD_TYPE_SECT | PMD_SECT_AF;
 value |= PMD_ATTRINDX(memory_type);
  -  page_table[section] = value;
  +  page_table[index] = value;
   }
   
   /* to activate the MMU we need to set up virtual memory */
  @@ -28,10 +27,13 @@ static void mmu_setup(void)
   {
 int i, j, el;
 bd_t *bd = gd-bd;
  +  u64 *page_table = (u64 *)gd-arch.tlb_addr;
   
 /* Setup an identity-mapping for all spaces */
  -  for (i = 0; i  (PGTABLE_SIZE  3); i++)
  -  set_pgtable_section(i, MT_DEVICE_NGNRNE);
  +  for (i = 0; i  (PGTABLE_SIZE  3); i++) {
  +  set_pgtable_section(page_table, i, i  SECTION_SHIFT,
  +  MT_DEVICE_NGNRNE);
  +  }
   
 /* Setup an identity-mapping for all RAM space */
 for (i = 0; i  CONFIG_NR_DRAM_BANKS; i++) {
  @@ -39,36 +41,25 @@ static void mmu_setup(void)
 ulong end = bd-bi_dram[i].start + bd-bi_dram[i].size;
 for (j = start  SECTION_SHIFT;
  j  end  SECTION_SHIFT; j++) {
  -  set_pgtable_section(j, MT_NORMAL);
  +  set_pgtable_section(page_table, j, j  SECTION_SHIFT,
  +  MT_NORMAL);
 }
 }
   
 /* load TTBR0 */
 el = current_el();
 if (el == 1) {
  -  asm volatile(msr ttbr0_el1, %0
  -   : : r (gd-arch.tlb_addr) : memory);
  -  asm volatile(msr tcr_el1, %0
  -   : : r (TCR_FLAGS | TCR_EL1_IPS_BITS)
  -   : memory);
  -  asm volatile(msr mair_el1, %0
  -   : : r (MEMORY_ATTRIBUTES) : memory);
  +  set_ttbr_tcr_mair(el, gd-arch.tlb_addr,
  +TCR_FLAGS | TCR_EL1_IPS_BITS,
  +MEMORY_ATTRIBUTES);
 } else if (el == 2) {
  -  asm volatile(msr ttbr0_el2, %0
  -   : : r (gd-arch.tlb_addr) : memory);
  -  asm volatile(msr tcr_el2, %0
  -   : : r (TCR_FLAGS | TCR_EL2_IPS_BITS)
  -   : memory);
  -  asm volatile(msr mair_el2, %0
  -   : : r (MEMORY_ATTRIBUTES) : memory);
  +  set_ttbr_tcr_mair(el, gd-arch.tlb_addr,
  +TCR_FLAGS | TCR_EL2_IPS_BITS,
  +MEMORY_ATTRIBUTES);
 } else {
  -  asm volatile(msr ttbr0_el3, %0
  -   : : r (gd-arch.tlb_addr) : memory);
  -  asm volatile(msr tcr_el3, %0
  -   : : r (TCR_FLAGS | TCR_EL2_IPS_BITS)
  -   : memory);
  -  asm volatile(msr mair_el3, %0
  -   : : r (MEMORY_ATTRIBUTES) : memory);
  +  set_ttbr_tcr_mair(el, gd-arch.tlb_addr,
  +TCR_FLAGS | TCR_EL3_IPS_BITS,
  +MEMORY_ATTRIBUTES);
 }
   
 /* enable the mmu */
  diff --git a/arch/arm/include/asm/armv8/mmu.h 
  b/arch/arm/include/asm/armv8/mmu.h
  index 1193e76..7de4ff9 100644
  --- a/arch/arm/include/asm/armv8/mmu.h
  +++ b/arch/arm/include/asm/armv8/mmu.h
  @@ -108,4 +108,27 @@
   

Re: [U-Boot] [PATCH] PPC4xx: Remove quad100hd board

2014-06-02 Thread Tom Rini
On Mon, Jun 02, 2014 at 05:52:56PM +0200, Wolfgang Denk wrote:
 Dear Tom,
 
 In message 20140602145956.GW5836@bill-the-cat you wrote:
  
   The quad100hd has been unmaintained and dead ever since it's been
   added some 6 years ago.  Remove it.
 ...
  Applied to u-boot/master, thanks!
 
 Umm... I have neither seen a pull request nor an ACK from Stefan.
 Should we not wait for the custodians to pick this up?

Given that Masahiro had his series depend on it and it seemed rather
unlikey to be rejected by Stefan, I grabbed it keep things rolling.

-- 
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] [RFC, PATCH v2 0/4] mtd, ubi, ubifs: resync with Linux-3.14

2014-06-02 Thread Jörg Krause
I tested the patches on our custom Freescale i.MX28 board. I used ubi part,
ubi create, and ubi write and it worked as expected. 



--
View this message in context: 
http://u-boot.10912.n7.nabble.com/RFC-PATCH-v2-0-4-mtd-ubi-ubifs-resync-with-Linux-3-14-tp180464p181246.html
Sent from the U-Boot mailing list archive at Nabble.com.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v3] Exynos: Make sure ps_hold gets set in the SPL

2014-06-02 Thread Simon Glass
Hi Minkyu,

On 30 May 2014 23:24, Minkyu Kang mk7.k...@samsung.com wrote:
 On 30/05/14 01:10, Akshay Saraswat wrote:
 From: Doug Anderson diand...@chromium.org

 Setting ps_hold ought to be one of the first things we do when we
 first boot up. If we wait until the main u-boot runs we won't set it
 in time and the PMIC may power us back off.

 Signed-off-by: Doug Anderson diand...@chromium.org
 Signed-off-by: Akshay Saraswat aksha...@samsung.com
 Acked-by: Simon Glass s...@chromium.org
 ---
 Changes since v2:
   - Removed function power_init and directly called set_ps_hold_strl.

 Changes since v1:
   - Added Acked-by.

  arch/arm/cpu/armv7/exynos/lowlevel_init.c | 6 +-
  arch/arm/cpu/armv7/exynos/power.c | 6 ++
  arch/arm/include/asm/arch-exynos/power.h  | 1 +
  3 files changed, 12 insertions(+), 1 deletion(-)


 applied to u-boot-samsung

Now that we have this patch we may be able to revert eb0dd99?

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


Re: [U-Boot] Standalone application on secondary cores

2014-06-02 Thread James Chargin

Dear Francesco Teodoro.

On 05/30/2014 01:35 PM, Francesco Teodoro wrote:

I'm using a SABRE SD board (from Freescale) based on i.MX6 and the u-boot 
version is the 2014.04 one. What I've been trying to do is to activate the 
secondary cores so that I would be able to use them. First of all I've imported 
the commands cpu status/release/reset, then I checked if they were working in 
this way:
U-boot  cpu 1 status (which gives as result: core1 disabled ...)
U-boot  cpu 1 release 0x1200 0
U-boot  cpu 1 status (which gives as result: core1 enabled ...)

Next step was to run a standalone application on secondary cores. First I 
checked the hello_world application, but it seems that the serial debug for 
secondary cores is not set (but I'm not sure). So I wrote an application to 
check if I could get changes in memory. This is the simple application (I just 
modified the hello_world one):



Please refer to 
http://www.denx.de/wiki/view/DULG/UBootStandalone#Section_5.12.4.


One of the first things done by the example stand alone application is 
to attempt to call back into U-Boot. This will not work correctly for 
cores other than 0.


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


Re: [U-Boot] imx6 booting from NAND with bad block 0

2014-06-02 Thread Tim Harvey
On Mon, Jun 2, 2014 at 4:03 AM, Andy Ng andreas2...@gmail.com wrote:
 I have an imx6 solo system and currently I am using the SD card to
 boot the u-boot.
 I would like to make it boot from NAND, but my first Block in NAND is a bad 
 one.
 Do I need u-boot with NAND  SPL support?

 Best regards
 Andy

Andy,

You only need NAND SPL support if the board you are booting uses an
SPL bootloader. The benefit of using SPL is really to allow mutliple
board configurations to be supported in a single bootloader (mostly by
configuring pinmux and SDRAM controller dynamically for IMX6DQ vs
IMX6SDL SoCs).

In general to 'boot' from NAND on IMX6 you need to use the kobs-ng
tool (source distributed with Freescales IMX BSP) to flash the
bootstream to the NAND in a way that is compatible with the internal
IMX BOOT ROM. Note that this also depends on eFUSE configuration
and/or board strappings specifing that the BOOT ROM should boot from
NAND. If all this is done, then having a bad block at the beginning is
not an issue, as the IMX BOOT ROM and kobs-ng allow for some
redundancy there.

What board are you working with and what bootloader tree?

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


Re: [U-Boot] [PATCH 1/2] usb: ci_udc: allow multiple buffer allocs per ep

2014-06-02 Thread Jörg Krause
Since this commit my Ethernet Gadget on a custom Freescale i.MX28 board is
broken. Using tftp to download files I get in almost all cases a timeout:

This is one case:



This is another one:



I reverted this commit from my master branch it works again as expected.




--
View this message in context: 
http://u-boot.10912.n7.nabble.com/PATCH-1-2-usb-ci-udc-allow-multiple-buffer-allocs-per-ep-tp179430p181250.html
Sent from the U-Boot mailing list archive at Nabble.com.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 1/2] usb: ci_udc: allow multiple buffer allocs per ep

2014-06-02 Thread Jörg Krause
Sorry, my previous post was not shown correctly. The raw text was missing. I
removed the annotation.

Since this commit my Ethernet Gadget on a custom Freescale i.MX28 board is
broken. Using tftp to download files I get in almost all cases a timeout:

This is one case:

Updating rootfs ...
using ci_udc, OUT ep- IN ep- STATUS ep-
MAC 00:19:b8:00:00:02
HOST MAC 00:19:b8:00:00:01
high speed config #1: 2 mA, Ethernet Gadget, using CDC Ethernet
USB network up!
Using usb_ether device
TFTP from server 10.0.0.1; our IP address is 10.0.0.2
Filename 'rootfs.ubifs'.
Load address: 0x40008000
Loading: ###timeout sending packets to usb ethernet

This is another one:

Updating Boot Firmware ...
using ci_udc, OUT ep- IN ep- STATUS ep-
MAC 00:19:b8:00:00:02
HOST MAC 00:19:b8:00:00:01
high speed config #1: 2 mA, Ethernet Gadget, using CDC Ethernet
ERROR: The remote end did not respond in time.
at drivers/usb/gadget/ether.c:2388/usb_eth_init()

I reverted this commit from my master branch it works again as expected.




--
View this message in context: 
http://u-boot.10912.n7.nabble.com/PATCH-1-2-usb-ci-udc-allow-multiple-buffer-allocs-per-ep-tp179430p181251.html
Sent from the U-Boot mailing list archive at Nabble.com.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH v4 00/10] mx6: SPL NAND support

2014-06-02 Thread Tim Harvey
This series adds some necessary framework for IMX6 SPL support. The series
includes support for NAND SPL and has been tested with MMC as well. I have
tested this on five differing Ventana baseboards with a variety of memory
(32bit 512MB, 32bit 1024MB, 64bit 1024MB) and CPU configurations (IMX6Q,
IMX6DL, IMX6S).

This is based on top of Mashahiro Yamada's patch that consolidates
arch/arm/include/asm/arch-*/spl.h [1]

v4:
 - removed unnecessary parens from a return
 - removed patch 1 as it has been merged upstream

v3:
 - re-ordered calls in board_init_f
 - replace imx_iomux_v3_setup_multiple_pads_array with additional intelligence
   in imx_iomux_v3_setup_multiple_pads
 - added ifdef's around cpu specific mmdc iocfg functions for code-reduction
   with single-variant board configs
 - added checks for IMX6D
 - added Freescale copyright to boot device support function
 - fixed typo s/IMX6SLD/IMX6SDL
 - encorporated cleanups in mxs_nand_spl.c per feedback

v2:
 - use compatible linker script instead of creating new one
 - remove structure passing data from SPL to u-boot
 - remove dependence on mtdpart, mtdcore, nand_util, nand_ecc, nand_base
   and nand_bbt to bring SPL down in size. This reduced codesize by about 32k
   where now mxs_spl_nand is about 12k total
 - adjust CONFIG_SPL_TEXT_BASE, CONFIG_SPL_STACK and CONFIG_SPL_MAX_SIZE
   to accomodate the IMX6SOLO/DUALLITE which have half the iRAM of the
   IMX6DUAL/IMX6QUAD
 - move boot dev detection into imx-common/spl.c
 - move macros for using pinmux array into iomux-v3.h
 - remove missing/unnecessary include
 - revert mtdparts change
 - use get_ram_size() to detect memory
 - add support for MX6SOLO and MX6DUAL
 - set CS0_END for 4GB so get_ram_size() works
 - updated DDR3 calibration values for ventana boards
 - fixed build issue - only compile spl if doing spl build
 - fixed line length issue in README
 - remove CONFIG_SPL* conditions and conditionally compile instead
 - removed prints for CPU type and DRAM size/width - uboot will print these l
 - removed unused gw_ventana_spl.cfg
 - use common read_eeprom function
 - added MMC support to SPL
 - added Masahiro Yamada's boot mode consolidation patch
   http://patchwork.ozlabs.org/patch/341817 and rebase on top of it

[1] http://patchwork.ozlabs.org/patch/341817/

Tim Harvey (10):
  spl: nand: add support for mxs nand
  mx6: add common SPL configuration
  mx6: add boot device support for SPL
  imx: add comments and remove unused struct fields
  mx6: add structs for mmdc and ddr iomux registers
  mx6: add mmdc configuration for MX6Q/MX6DL
  imx: iomux: add macros to setup iomux for multiple SoC types
  imx: ventana: split read_eeprom into standalone file
  imx: ventana: auto-configure for IMX6Q vs IMX6DL
  imx: ventana: switch to SPL

 arch/arm/cpu/armv7/mx6/Makefile |   1 +
 arch/arm/cpu/armv7/mx6/ddr.c| 490 +++
 arch/arm/imx-common/Makefile|   1 +
 arch/arm/imx-common/cpu.c   |  16 +-
 arch/arm/imx-common/iomux-v3.c  |  16 +-
 arch/arm/imx-common/spl.c   |  81 
 arch/arm/include/asm/arch-mx6/mx6-ddr.h | 231 +++
 arch/arm/include/asm/imx-common/iomux-v3.h  |  25 ++
 board/gateworks/gw_ventana/Makefile |   3 +-
 board/gateworks/gw_ventana/README   |  92 +++--
 board/gateworks/gw_ventana/eeprom.c |  89 +
 board/gateworks/gw_ventana/gw_ventana.c | 597 +++-
 board/gateworks/gw_ventana/gw_ventana.cfg   |  15 -
 board/gateworks/gw_ventana/gw_ventana_spl.c | 419 +++
 board/gateworks/gw_ventana/ventana_eeprom.h |  11 +
 boards.cfg  |   6 +-
 drivers/mtd/nand/Makefile   |   1 +
 drivers/mtd/nand/mxs_nand_spl.c | 231 +++
 include/configs/gw_ventana.h|  11 +
 include/configs/imx6_spl.h  |  71 
 20 files changed, 2065 insertions(+), 342 deletions(-)
 create mode 100644 arch/arm/cpu/armv7/mx6/ddr.c
 create mode 100644 arch/arm/imx-common/spl.c
 create mode 100644 board/gateworks/gw_ventana/eeprom.c
 create mode 100644 board/gateworks/gw_ventana/gw_ventana_spl.c
 create mode 100644 drivers/mtd/nand/mxs_nand_spl.c
 create mode 100644 include/configs/imx6_spl.h

-- 
1.8.3.2

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


[U-Boot] [PATCH v4 01/10] spl: nand: add support for mxs nand

2014-06-02 Thread Tim Harvey
This utilizes existing mxs_nand support layer to provide a method to load an
image off nand for SPL. The flash device will be detected in order to support
multiple flash devices instead of having layout hard coded at build time.

Cc: Stefan Roese s...@denx.de
Cc: Otavio Salvador ota...@ossystems.com.br
Cc: Andy Ng andreas2...@gmail.com
Cc: Eric Nelson eric.nel...@boundarydevices.com
Cc: Tapani Utriainen tap...@technexion.com
Cc: Tom Rini tr...@ti.com
Cc: Scott Wood scottw...@freescale.com

Signed-off-by: Tim Harvey thar...@gateworks.com
---
v4:
 - removed unnecessary parens from return

v3:
 - removed NAND_NCE and NAND_CTRL_CHANGE unused by mxc_nand.c
 - return specific error types on errors
 - remove register keyword - let compiler do optimizations

v2:
 - remove dependence on mtdpart, mtdcore, nand_util, nand_ecc, nand_base
   and nand_bbt to bring SPL down in size. This reduced codesize by about 32k
   where now mxs_spl_nand is about 12k total.

---
 drivers/mtd/nand/Makefile   |   1 +
 drivers/mtd/nand/mxs_nand_spl.c | 231 
 2 files changed, 232 insertions(+)
 create mode 100644 drivers/mtd/nand/mxs_nand_spl.c

diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index 4eb354d..bf1312a 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -68,5 +68,6 @@ else  # minimal SPL drivers
 obj-$(CONFIG_NAND_FSL_ELBC) += fsl_elbc_spl.o
 obj-$(CONFIG_NAND_FSL_IFC) += fsl_ifc_spl.o
 obj-$(CONFIG_NAND_MXC) += mxc_nand_spl.o
+obj-$(CONFIG_NAND_MXS) += mxs_nand_spl.o mxs_nand.o
 
 endif # drivers
diff --git a/drivers/mtd/nand/mxs_nand_spl.c b/drivers/mtd/nand/mxs_nand_spl.c
new file mode 100644
index 000..0e7c364
--- /dev/null
+++ b/drivers/mtd/nand/mxs_nand_spl.c
@@ -0,0 +1,231 @@
+/*
+ * Copyright (C) 2014 Gateworks Corporation
+ * Author: Tim Harvey thar...@gateworks.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+#include common.h
+#include nand.h
+#include malloc.h
+
+static nand_info_t mtd;
+static struct nand_chip nand_chip;
+
+static void mxs_nand_command(struct mtd_info *mtd, unsigned int command,
+int column, int page_addr)
+{
+   register struct nand_chip *chip = mtd-priv;
+   u32 timeo, time_start;
+
+   /* write out the command to the device */
+   chip-cmd_ctrl(mtd, command, NAND_CLE);
+
+   /* Serially input address */
+   if (column != -1) {
+   chip-cmd_ctrl(mtd, column, NAND_ALE);
+   chip-cmd_ctrl(mtd, column  8, NAND_ALE);
+   }
+   if (page_addr != -1) {
+   chip-cmd_ctrl(mtd, page_addr, NAND_ALE);
+   chip-cmd_ctrl(mtd, page_addr  8, NAND_ALE);
+   /* One more address cycle for devices  128MiB */
+   if (chip-chipsize  (128  20))
+   chip-cmd_ctrl(mtd, page_addr  16, NAND_ALE);
+   }
+   chip-cmd_ctrl(mtd, NAND_CMD_NONE, 0);
+
+   if (command == NAND_CMD_READ0) {
+   chip-cmd_ctrl(mtd, NAND_CMD_READSTART, NAND_CLE);
+   chip-cmd_ctrl(mtd, NAND_CMD_NONE, 0);
+   }
+
+   /* wait for nand ready */
+   ndelay(100);
+   timeo = (CONFIG_SYS_HZ * 20) / 1000;
+   time_start = get_timer(0);
+   while (get_timer(time_start)  timeo) {
+   if (chip-dev_ready(mtd))
+   break;
+   }
+}
+
+static int mxs_flash_ident(struct mtd_info *mtd)
+{
+   register struct nand_chip *chip = mtd-priv;
+   int i;
+   u8 mfg_id, dev_id;
+   u8 id_data[8];
+   struct nand_onfi_params *p = chip-onfi_params;
+
+   /* Reset the chip */
+   chip-cmdfunc(mtd, NAND_CMD_RESET, -1, -1);
+
+   /* Send the command for reading device ID */
+   chip-cmdfunc(mtd, NAND_CMD_READID, 0x00, -1);
+
+   /* Read manufacturer and device IDs */
+   mfg_id = chip-read_byte(mtd);
+   dev_id = chip-read_byte(mtd);
+
+   /* Try again to make sure */
+   chip-cmdfunc(mtd, NAND_CMD_READID, 0x00, -1);
+   for (i = 0; i  8; i++)
+   id_data[i] = chip-read_byte(mtd);
+   if (id_data[0] != mfg_id || id_data[1] != dev_id) {
+   printf(second ID read did not match);
+   return -1;
+   }
+   debug(0x%02x:0x%02x , mfg_id, dev_id);
+
+   /* read ONFI */
+   chip-onfi_version = 0;
+   chip-cmdfunc(mtd, NAND_CMD_READID, 0x20, -1);
+   if (chip-read_byte(mtd) != 'O' || chip-read_byte(mtd) != 'N' ||
+   chip-read_byte(mtd) != 'F' || chip-read_byte(mtd) != 'I') {
+   return -2;
+   }
+
+   /* we have ONFI, probe it */
+   chip-cmdfunc(mtd, NAND_CMD_PARAM, 0, -1);
+   chip-read_buf(mtd, (uint8_t *)p, sizeof(*p));
+   mtd-name = p-model;
+   mtd-writesize = le32_to_cpu(p-byte_per_page);
+   mtd-erasesize = le32_to_cpu(p-pages_per_block) * mtd-writesize;
+   mtd-oobsize = le16_to_cpu(p-spare_bytes_per_page);
+   chip-chipsize = le32_to_cpu(p-blocks_per_lun);
+

[U-Boot] [PATCH v4 05/10] mx6: add structs for mmdc and ddr iomux registers

2014-06-02 Thread Tim Harvey
Add memory-mapped structures for MMDC iomux and configuration. Note that whi
the MMDC configuration registers are common between the IMX6DQ
(IMX6DUAL/IMX6QUAD) and IMX6SDL (IMX6SOLO/IMX6DUALLITE) types the iomux
registers differ. This requires two sets of structures.

Add structures to describe DDR3 device information, system information
(memory layout, etc), and MMDC calibration registers that can be used to
configure the MMDC dynamically.

We define these structures for SPL builds instead of including mx6q-ddr.h an
mx6dl-ddr.h which use the same namespace and are only useful for imximage cf
files.

Cc: Stefan Roese s...@denx.de
Cc: Otavio Salvador ota...@ossystems.com.br
Cc: Andy Ng andreas2...@gmail.com
Cc: Eric Nelson eric.nel...@boundarydevices.com
Cc: Tapani Utriainen tap...@technexion.com
Cc: Tom Rini tr...@ti.com

Signed-off-by: Tim Harvey thar...@gateworks.com
Acked-by: Nikita Kiryanov nik...@compulab.co.il
---
v4:
 - added Nikita's Ack

v3:
 - moved portions into following patch

v2:
 - split out from original mmdc configuration patch
 - only define for SPL build
 - do not include mx6q-ddr.h and mx6dl-ddr.h for SPL build - these use the
   same namespace and are only useful for imximage cfg files

---
 arch/arm/include/asm/arch-mx6/mx6-ddr.h | 159 
 1 file changed, 159 insertions(+)

diff --git a/arch/arm/include/asm/arch-mx6/mx6-ddr.h 
b/arch/arm/include/asm/arch-mx6/mx6-ddr.h
index 43d377a..c2a31d2 100644
--- a/arch/arm/include/asm/arch-mx6/mx6-ddr.h
+++ b/arch/arm/include/asm/arch-mx6/mx6-ddr.h
@@ -6,6 +6,7 @@
 #ifndef __ASM_ARCH_MX6_DDR_H__
 #define __ASM_ARCH_MX6_DDR_H__
 
+#ifndef CONFIG_SPL_BUILD
 #ifdef CONFIG_MX6Q
 #include mx6q-ddr.h
 #else
@@ -15,6 +16,164 @@
 #error Please select cpu
 #endif /* CONFIG_MX6DL or CONFIG_MX6S */
 #endif /* CONFIG_MX6Q */
+#else
+
+/* MMDC P0/P1 Registers */
+struct mmdc_p_regs {
+   u32 mdctl;
+   u32 mdpdc;
+   u32 mdotc;
+   u32 mdcfg0;
+   u32 mdcfg1;
+   u32 mdcfg2;
+   u32 mdmisc;
+   u32 mdscr;
+   u32 mdref;
+   u32 res1[2];
+   u32 mdrwd;
+   u32 mdor;
+   u32 res2[3];
+   u32 mdasp;
+   u32 res3[240];
+   u32 mapsr;
+   u32 res4[254];
+   u32 mpzqhwctrl;
+   u32 res5[2];
+   u32 mpwldectrl0;
+   u32 mpwldectrl1;
+   u32 res6;
+   u32 mpodtctrl;
+   u32 mprddqby0dl;
+   u32 mprddqby1dl;
+   u32 mprddqby2dl;
+   u32 mprddqby3dl;
+   u32 res7[4];
+   u32 mpdgctrl0;
+   u32 mpdgctrl1;
+   u32 res8;
+   u32 mprddlctl;
+   u32 res9;
+   u32 mpwrdlctl;
+   u32 res10[25];
+   u32 mpmur0;
+};
+
+/*
+ * MMDC iomux registers (pinctl/padctl) - (different for IMX6DQ vs IMX6SDL)
+ */
+#define MX6DQ_IOM_DDR_BASE  0x020e0500
+struct mx6dq_iomux_ddr_regs {
+   u32 res1[3];
+   u32 dram_sdqs5;
+   u32 dram_dqm5;
+   u32 dram_dqm4;
+   u32 dram_sdqs4;
+   u32 dram_sdqs3;
+   u32 dram_dqm3;
+   u32 dram_sdqs2;
+   u32 dram_dqm2;
+   u32 res2[16];
+   u32 dram_cas;
+   u32 res3[2];
+   u32 dram_ras;
+   u32 dram_reset;
+   u32 res4[2];
+   u32 dram_sdclk_0;
+   u32 dram_sdba2;
+   u32 dram_sdcke0;
+   u32 dram_sdclk_1;
+   u32 dram_sdcke1;
+   u32 dram_sdodt0;
+   u32 dram_sdodt1;
+   u32 res5;
+   u32 dram_sdqs0;
+   u32 dram_dqm0;
+   u32 dram_sdqs1;
+   u32 dram_dqm1;
+   u32 dram_sdqs6;
+   u32 dram_dqm6;
+   u32 dram_sdqs7;
+   u32 dram_dqm7;
+};
+
+#define MX6DQ_IOM_GRP_BASE  0x020e0700
+struct mx6dq_iomux_grp_regs {
+   u32 res1[18];
+   u32 grp_b7ds;
+   u32 grp_addds;
+   u32 grp_ddrmode_ctl;
+   u32 res2;
+   u32 grp_ddrpke;
+   u32 res3[6];
+   u32 grp_ddrmode;
+   u32 res4[3];
+   u32 grp_b0ds;
+   u32 grp_b1ds;
+   u32 grp_ctlds;
+   u32 res5;
+   u32 grp_b2ds;
+   u32 grp_ddr_type;
+   u32 grp_b3ds;
+   u32 grp_b4ds;
+   u32 grp_b5ds;
+   u32 grp_b6ds;
+};
+
+#define MX6SDL_IOM_DDR_BASE 0x020e0400
+struct mx6sdl_iomux_ddr_regs {
+   u32 res1[25];
+   u32 dram_cas;
+   u32 res2[2];
+   u32 dram_dqm0;
+   u32 dram_dqm1;
+   u32 dram_dqm2;
+   u32 dram_dqm3;
+   u32 dram_dqm4;
+   u32 dram_dqm5;
+   u32 dram_dqm6;
+   u32 dram_dqm7;
+   u32 dram_ras;
+   u32 dram_reset;
+   u32 res3[2];
+   u32 dram_sdba2;
+   u32 dram_sdcke0;
+   u32 dram_sdcke1;
+   u32 dram_sdclk_0;
+   u32 dram_sdclk_1;
+   u32 dram_sdodt0;
+   u32 dram_sdodt1;
+   u32 dram_sdqs0;
+   u32 dram_sdqs1;
+   u32 dram_sdqs2;
+   u32 dram_sdqs3;
+   u32 dram_sdqs4;
+   u32 dram_sdqs5;
+   u32 dram_sdqs6;
+   u32 dram_sdqs7;
+};
+
+#define MX6SDL_IOM_GRP_BASE 0x020e0700
+struct mx6sdl_iomux_grp_regs {
+   u32 res1[18];
+   u32 grp_b7ds;
+   u32 grp_addds;
+   u32 

[U-Boot] [PATCH v4 02/10] mx6: add common SPL configuration

2014-06-02 Thread Tim Harvey
Add a common header which can hopefully be shared amon imx6 SPL users

Cc: Stefan Roese s...@denx.de
Cc: Otavio Salvador ota...@ossystems.com.br
Cc: Andy Ng andreas2...@gmail.com
Cc: Eric Nelson eric.nel...@boundarydevices.com
Cc: Tapani Utriainen tap...@technexion.com
Cc: Tom Rini tr...@ti.com

Signed-off-by: Tim Harvey thar...@gateworks.com
Acked-by: Stefano Babic sba...@denx.de
Acked-by: Nikita Kiryanov nik...@compulab.co.il
---
v4:
 - no changes

v3:
 - fixed typo s/IMX6SLD/IMX6SDL
 - add acks from Stefano and Nikita

v2:
- adjust CONFIG_SPL_TEXT_BASE, CONFIG_SPL_STACK and CONFIG_SPL_MAX_SIZE
  to accomodate the IMX6SOLO/DUALLITE which have half the iRAM of the
  IMX6DUAL/IMX6QUAD

---
 include/configs/imx6_spl.h | 71 ++
 1 file changed, 71 insertions(+)
 create mode 100644 include/configs/imx6_spl.h

diff --git a/include/configs/imx6_spl.h b/include/configs/imx6_spl.h
new file mode 100644
index 000..6fdc438
--- /dev/null
+++ b/include/configs/imx6_spl.h
@@ -0,0 +1,71 @@
+/*
+ * Copyright (C) 2014 Gateworks Corporation
+ * Author: Tim Harvey thar...@gateworks.com
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+#ifndef __IMX6_SPL_CONFIG_H
+#define __IMX6_SPL_CONFIG_H
+
+#ifdef CONFIG_SPL
+
+#define CONFIG_SPL_FRAMEWORK
+
+/*
+ * see Figure 8-3 in IMX6DQ/IMX6SDL Reference manuals:
+ *  - IMX6SDL OCRAM (IRAM) is from 0x00907000 to 0x0091
+ *  - IMX6DQ has 2x IRAM of IMX6SDL but we intend to support IMX6SDL as well
+ *  - BOOT ROM stack is at 0x0091FFB8
+ *  - if icache/dcache is enabled (eFuse/strapping controlled) then the
+ *IMX BOOT ROM will setup MMU table at 0x00918000, therefore we need to
+ *fit between 0x00907000 and 0x00918000.
+ *  - Additionally the BOOT ROM loads what they consider the firmware image
+ *which consists of a 4K header in front of us that contains the IVT, DCD
+ *and some padding thus 'our' max size is really 0x00908000 - 0x00918000
+ *or 64KB
+ */
+#define CONFIG_SPL_LDSCRIPTarch/arm/cpu/armv7/omap-common/u-boot-spl.lds
+#define CONFIG_SPL_TEXT_BASE   0x00908000
+#define CONFIG_SPL_MAX_SIZE(64 * 1024)
+#define CONFIG_SPL_START_S_PATHarch/arm/cpu/armv7
+#define CONFIG_SPL_STACK   0x0091FFB8
+#define CONFIG_SPL_LIBCOMMON_SUPPORT
+#define CONFIG_SPL_LIBGENERIC_SUPPORT
+#define CONFIG_SPL_SERIAL_SUPPORT
+#define CONFIG_SPL_I2C_SUPPORT
+#define CONFIG_SPL_GPIO_SUPPORT
+
+/* NAND support */
+#if defined(CONFIG_SPL_NAND_SUPPORT)
+#define CONFIG_SPL_NAND_MXS
+#define CONFIG_SPL_DMA_SUPPORT
+#endif
+
+/* MMC support */
+#if defined(CONFIG_SPL_MMC_SUPPORT)
+#define CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR138 /* offset 69KB */
+#define CONFIG_SYS_U_BOOT_MAX_SIZE_SECTORS 800 /* 400 KB */
+#define CONFIG_SYS_MMC_SD_FAT_BOOT_PARTITION   1
+#define CONFIG_SYS_MONITOR_LEN  (CONFIG_SYS_U_BOOT_MAX_SIZE_SECTORS/2*1024)
+#endif
+
+/* SATA support */
+#if defined(CONFIG_SPL_SATA_SUPPORT)
+#define CONFIG_SPL_SATA_BOOT_DEVICE0
+#define CONFIG_SYS_SATA_FAT_BOOT_PARTITION 1
+#endif
+
+/* Define the payload for FAT/EXT support */
+#if defined(CONFIG_SPL_FAT_SUPPORT) || defined(CONFIG_SPL_EXT_SUPPORT)
+#define CONFIG_SPL_FAT_LOAD_PAYLOAD_NAME  u-boot.img
+#define CONFIG_SPL_LIBDISK_SUPPORT
+#endif
+
+#define CONFIG_SPL_BSS_START_ADDR  0x1820
+#define CONFIG_SPL_BSS_MAX_SIZE0x10/* 1 MB */
+#define CONFIG_SYS_SPL_MALLOC_START0x1830
+#define CONFIG_SYS_SPL_MALLOC_SIZE 0x320   /* 50 MB */
+#define CONFIG_SYS_TEXT_BASE   0x1780
+#endif
+
+#endif
-- 
1.8.3.2

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


[U-Boot] [PATCH v4 04/10] imx: add comments and remove unused struct fields

2014-06-02 Thread Tim Harvey
Add comment block for the imx_ddr_size function and remove the extra unused
fields from struct esd_mmdc_regs which are also not common between IMX53 and
IMX6.

Cc: Stefan Roese s...@denx.de
Cc: Otavio Salvador ota...@ossystems.com.br
Cc: Andy Ng andreas2...@gmail.com
Cc: Eric Nelson eric.nel...@boundarydevices.com
Cc: Tapani Utriainen tap...@technexion.com
Cc: Tom Rini tr...@ti.com

Signed-off-by: Tim Harvey thar...@gateworks.com
Acked-by: Stefano Babic sba...@denx.de
Acked-by: Nikita Kiryanov nik...@compulab.co.il
---
v4:
 - added Nikita's Ack

v3:
 - fixed doxygen-style comment block
 - added Stefano's Ack

v2:
 - new patch in series

---
 arch/arm/imx-common/cpu.c | 16 +++-
 1 file changed, 7 insertions(+), 9 deletions(-)

diff --git a/arch/arm/imx-common/cpu.c b/arch/arm/imx-common/cpu.c
index a77c4de..5a09107 100644
--- a/arch/arm/imx-common/cpu.c
+++ b/arch/arm/imx-common/cpu.c
@@ -58,6 +58,7 @@ char *get_reset_cause(void)
 static const unsigned char col_lookup[] = {9, 10, 11, 8, 12, 9, 9, 9};
 static const unsigned char bank_lookup[] = {3, 2};
 
+/* these MMDC registers are common to the IMX53 and IMX6 */
 struct esd_mmdc_regs {
uint32_tctl;
uint32_tpdc;
@@ -66,15 +67,6 @@ struct esd_mmdc_regs {
uint32_tcfg1;
uint32_tcfg2;
uint32_tmisc;
-   uint32_tscr;
-   uint32_tref;
-   uint32_trsvd1;
-   uint32_trsvd2;
-   uint32_trwd;
-   uint32_tor;
-   uint32_tmrr;
-   uint32_tcfg3lp;
-   uint32_tmr4;
 };
 
 #define ESD_MMDC_CTL_GET_ROW(mdctl)((ctl  24)  7)
@@ -83,6 +75,12 @@ struct esd_mmdc_regs {
 #define ESD_MMDC_CTL_GET_CS1(mdctl)((ctl  30)  1)
 #define ESD_MMDC_MISC_GET_BANK(mdmisc) ((misc  5)  1)
 
+/*
+ * imx_ddr_size - return size in bytes of DRAM according MMDC config
+ * The MMDC MDCTL register holds the number of bits for row, col, and data
+ * width and the MMDC MDMISC register holds the number of banks. Combine
+ * all these bits to determine the meme size the MMDC has been configured for
+ */
 unsigned imx_ddr_size(void)
 {
struct esd_mmdc_regs *mem = (struct esd_mmdc_regs *)MEMCTL_BASE;
-- 
1.8.3.2

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


[U-Boot] [PATCH v4 03/10] mx6: add boot device support for SPL

2014-06-02 Thread Tim Harvey
Add a common spl.c file to support boot device functions needed for SPL
such as detecting the boot device.

Cc: Stefan Roese s...@denx.de
Cc: Otavio Salvador ota...@ossystems.com.br
Cc: Andy Ng andreas2...@gmail.com
Cc: Eric Nelson eric.nel...@boundarydevices.com
Cc: Tapani Utriainen tap...@technexion.com
Cc: Tom Rini tr...@ti.com

Signed-off-by: Tim Harvey thar...@gateworks.com
Acked-by: Nikita Kiryanov nik...@compulab.co.il
---
v4:
 - added Nikita's Ack

v3:
 - added Freescale copyright

v2:
 - re-base on top of Masahiro Yamada's consolidation patch:
   http://patchwork.ozlabs.org/patch/341817/
 - moved spl_boot_device() and get_boot_mode() into own common imx spl.c file
 - use mem-mapped structure for smbr reg access

---
 arch/arm/imx-common/Makefile |  1 +
 arch/arm/imx-common/spl.c| 81 
 2 files changed, 82 insertions(+)
 create mode 100644 arch/arm/imx-common/spl.c

diff --git a/arch/arm/imx-common/Makefile b/arch/arm/imx-common/Makefile
index 0e71395..d4799e7 100644
--- a/arch/arm/imx-common/Makefile
+++ b/arch/arm/imx-common/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_SYS_I2C_MXC) += i2c-mxv7.o
 endif
 ifeq ($(SOC),$(filter $(SOC),mx6 mxs))
 obj-y  += misc.o
+obj-$(CONFIG_SPL_BUILD)+= spl.o
 endif
 ifeq ($(SOC),$(filter $(SOC),mx6))
 obj-$(CONFIG_CMD_SATA) += sata.o
diff --git a/arch/arm/imx-common/spl.c b/arch/arm/imx-common/spl.c
new file mode 100644
index 000..9a02a64
--- /dev/null
+++ b/arch/arm/imx-common/spl.c
@@ -0,0 +1,81 @@
+/*
+ * Copyright (C) 2014 Gateworks Corporation
+ * Copyright (C) 2011-2012 Freescale Semiconductor, Inc.
+ *
+ * Author: Tim Harvey thar...@gateworks.com
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include common.h
+#include asm/io.h
+#include asm/arch/imx-regs.h
+#include asm/spl.h
+#include spl.h
+
+#if defined(CONFIG_MX6)
+/* determine boot device from SRC_SBMR1 register (BOOT_CFG[4:1]) */
+u32 spl_boot_device(void)
+{
+   struct src *psrc = (struct src *)SRC_BASE_ADDR;
+   unsigned reg = readl(psrc-sbmr1);
+
+   /* BOOT_CFG1[7:4] - see IMX6DQRM Table 8-8 */
+   switch ((reg  0x00FF)  4) {
+/* EIM: See 8.5.1, Table 8-9 */
+   case 0x0:
+   /* BOOT_CFG1[3]: NOR/OneNAND Selection */
+   if ((reg  0x0008)  3)
+   return BOOT_DEVICE_ONENAND;
+   else
+   return BOOT_DEVICE_NOR;
+   break;
+   /* SATA: See 8.5.4, Table 8-20 */
+   case 0x2:
+   return BOOT_DEVICE_SATA;
+   /* Serial ROM: See 8.5.5.1, Table 8-22 */
+   case 0x3:
+   /* BOOT_CFG4[2:0] */
+   switch ((reg  0x0700)  24) {
+   case 0x0 ... 0x4:
+   return BOOT_DEVICE_SPI;
+   case 0x5 ... 0x7:
+   return BOOT_DEVICE_I2C;
+   }
+   break;
+   /* SD/eSD: 8.5.3, Table 8-15  */
+   case 0x4:
+   case 0x5:
+   return BOOT_DEVICE_MMC1;
+   /* MMC/eMMC: 8.5.3 */
+   case 0x6:
+   case 0x7:
+   return BOOT_DEVICE_MMC1;
+   /* NAND Flash: 8.5.2 */
+   case 0x8 ... 0xf:
+   return BOOT_DEVICE_NAND;
+   }
+   return BOOT_DEVICE_NONE;
+}
+#endif
+
+#if defined(CONFIG_SPL_MMC_SUPPORT)
+/* called from spl_mmc to see type of boot mode for storage (RAW or FAT) */
+u32 spl_boot_mode(void)
+{
+   switch (spl_boot_device()) {
+   /* for MMC return either RAW or FAT mode */
+   case BOOT_DEVICE_MMC1:
+   case BOOT_DEVICE_MMC2:
+#ifdef CONFIG_SPL_FAT_SUPPORT
+   return MMCSD_MODE_FAT;
+#else
+   return MMCSD_MODE_RAW;
+#endif
+   break;
+   default:
+   puts(spl: ERROR:  unsupported device\n);
+   hang();
+   }
+}
+#endif
-- 
1.8.3.2

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


[U-Boot] [PATCH v4 07/10] imx: iomux: add macros to setup iomux for multiple SoC types

2014-06-02 Thread Tim Harvey
Allow imx_iomux_v3_setup_multiple_pads to take a multi-cpu pad_list
and add macros for declaring the pad_list that take into account the
SoC types supported using CONFIG_MX6QDL (supports both the MX6Q and MX6DL
iomux).

Cc: Stefan Roese s...@denx.de
Cc: Otavio Salvador ota...@ossystems.com.br
Cc: Andy Ng andreas2...@gmail.com
Cc: Eric Nelson eric.nel...@boundarydevices.com
Cc: Tapani Utriainen tap...@technexion.com
Cc: Tom Rini tr...@ti.com

Signed-off-by: Tim Harvey thar...@gateworks.com
---
v4:
 - no changes

v3:
 - remove commit msg 2nd paragrap about prior approaches
 - re-work to avoid needing to add a new function by making
   imx_iomux_v3_setup_multiple_pads more intelligent and adding macros
   that depend on SoC type support
v2:
 - moved macros for declaring and using structs for array variant
 - removed non-related whitespace cleanup

---
 arch/arm/imx-common/iomux-v3.c | 16 ++--
 arch/arm/include/asm/imx-common/iomux-v3.h | 25 +
 2 files changed, 39 insertions(+), 2 deletions(-)

diff --git a/arch/arm/imx-common/iomux-v3.c b/arch/arm/imx-common/iomux-v3.c
index 6e46ea8..306183a 100644
--- a/arch/arm/imx-common/iomux-v3.c
+++ b/arch/arm/imx-common/iomux-v3.c
@@ -11,6 +11,7 @@
 #include common.h
 #include asm/io.h
 #include asm/arch/imx-regs.h
+#include asm/arch/sys_proto.h
 #include asm/imx-common/iomux-v3.h
 
 static void *base = (void *)IOMUXC_BASE_ADDR;
@@ -54,12 +55,23 @@ void imx_iomux_v3_setup_pad(iomux_v3_cfg_t pad)
 #endif
 }
 
+/* configures a list of pads within declared with IOMUX_PADS macro */
 void imx_iomux_v3_setup_multiple_pads(iomux_v3_cfg_t const *pad_list,
  unsigned count)
 {
iomux_v3_cfg_t const *p = pad_list;
+   int stride;
int i;
 
-   for (i = 0; i  count; i++)
-   imx_iomux_v3_setup_pad(*p++);
+#if defined(CONFIG_MX6QDL)
+   stride = 2;
+   if (!is_cpu_type(MXC_CPU_MX6Q)  !is_cpu_type(MXC_CPU_MX6D))
+   p += 1;
+#else
+   stride = 1;
+#endif
+   for (i = 0; i  count; i++) {
+   imx_iomux_v3_setup_pad(*p);
+   p += stride;
+   }
 }
diff --git a/arch/arm/include/asm/imx-common/iomux-v3.h 
b/arch/arm/include/asm/imx-common/iomux-v3.h
index cca920b..dfe1ebf 100644
--- a/arch/arm/include/asm/imx-common/iomux-v3.h
+++ b/arch/arm/include/asm/imx-common/iomux-v3.h
@@ -175,4 +175,29 @@ void imx_iomux_v3_setup_pad(iomux_v3_cfg_t pad);
 void imx_iomux_v3_setup_multiple_pads(iomux_v3_cfg_t const *pad_list,
 unsigned count);
 
+/* macros for declaring and using pinmux array */
+#if defined(CONFIG_MX6QDL)
+#define IOMUX_PADS(x) (MX6Q_##x), (MX6DL_##x)
+#define SETUP_IOMUX_PAD(def)   \
+if (is_cpu_type(MXC_CPU_MX6Q)) {   \
+   imx_iomux_v3_setup_pad(MX6Q_##def); \
+} else {   \
+   imx_iomux_v3_setup_pad(MX6DL_##def);\
+}
+#define SETUP_IOMUX_PADS(x)\
+   imx_iomux_v3_setup_multiple_pads(x, ARRAY_SIZE(x)/2)
+#elif defined(CONFIG_MX6Q) || defined(CONFIG_MX6D)
+#define IOMUX_PADS(x) MX6Q_##x
+#define SETUP_IOMUX_PAD(def)   \
+   imx_iomux_v3_setup_pad(MX6Q_##def);
+#define SETUP_IOMUX_PADS(x)\
+   imx_iomux_v3_setup_multiple_pads(x, ARRAY_SIZE(x))
+#else
+#define IOMUX_PADS(x) MX6DL_##x
+#define SETUP_IOMUX_PAD(def)   \
+   imx_iomux_v3_setup_pad(MX6DL_##def);
+#define SETUP_IOMUX_PADS(x)\
+   imx_iomux_v3_setup_multiple_pads(x, ARRAY_SIZE(x))
+#endif
+
 #endif /* __MACH_IOMUX_V3_H__*/
-- 
1.8.3.2

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


[U-Boot] [PATCH v4 06/10] mx6: add mmdc configuration for MX6Q/MX6DL

2014-06-02 Thread Tim Harvey
- add function for configuring iomux based on board-specific regs
- add function for configuring mmdc based on board-specific and
  chip-specific data

Cc: Stefan Roese s...@denx.de
Cc: Otavio Salvador ota...@ossystems.com.br
Cc: Andy Ng andreas2...@gmail.com
Cc: Eric Nelson eric.nel...@boundarydevices.com
Cc: Tapani Utriainen tap...@technexion.com
Cc: Tom Rini tr...@ti.com

Signed-off-by: Tim Harvey thar...@gateworks.com
---
v4:
 - added delay following configure to allow ZQ calibration to complete
 - update MMDC configuration to match Freescale RM

v3:
 - added ifdef's around cpu specific iocfg functions for code-reduction with
   single-variant board configs
 - moved portions from previous patch here
 - added check for IMX6D

v2:
 - split out mmdc and iomux structs into separate patch

---
 arch/arm/cpu/armv7/mx6/Makefile |   1 +
 arch/arm/cpu/armv7/mx6/ddr.c| 490 
 arch/arm/include/asm/arch-mx6/mx6-ddr.h |  72 +
 3 files changed, 563 insertions(+)
 create mode 100644 arch/arm/cpu/armv7/mx6/ddr.c

diff --git a/arch/arm/cpu/armv7/mx6/Makefile b/arch/arm/cpu/armv7/mx6/Makefile
index d7285fc..6dc9f8e 100644
--- a/arch/arm/cpu/armv7/mx6/Makefile
+++ b/arch/arm/cpu/armv7/mx6/Makefile
@@ -8,4 +8,5 @@
 #
 
 obj-y  := soc.o clock.o
+obj-$(CONFIG_SPL_BUILD) += ddr.o
 obj-$(CONFIG_SECURE_BOOT)+= hab.o
diff --git a/arch/arm/cpu/armv7/mx6/ddr.c b/arch/arm/cpu/armv7/mx6/ddr.c
new file mode 100644
index 000..0434211
--- /dev/null
+++ b/arch/arm/cpu/armv7/mx6/ddr.c
@@ -0,0 +1,490 @@
+/*
+ * Copyright (C) 2014 Gateworks Corporation
+ * Author: Tim Harvey thar...@gateworks.com
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include common.h
+#include linux/types.h
+#include asm/arch/mx6-ddr.h
+#include asm/arch/sys_proto.h
+#include asm/io.h
+#include asm/types.h
+
+#if defined(CONFIG_MX6QDL) || defined(CONFIG_MX6Q) || defined(CONFIG_MX6D)
+/* Configure MX6DQ mmdc iomux */
+void mx6dq_dram_iocfg(unsigned width,
+ const struct mx6dq_iomux_ddr_regs *ddr,
+ const struct mx6dq_iomux_grp_regs *grp)
+{
+   volatile struct mx6dq_iomux_ddr_regs *mx6_ddr_iomux;
+   volatile struct mx6dq_iomux_grp_regs *mx6_grp_iomux;
+
+   mx6_ddr_iomux = (struct mx6dq_iomux_ddr_regs *)MX6DQ_IOM_DDR_BASE;
+   mx6_grp_iomux = (struct mx6dq_iomux_grp_regs *)MX6DQ_IOM_GRP_BASE;
+
+   /* DDR IO Type */
+   mx6_grp_iomux-grp_ddr_type = grp-grp_ddr_type;
+   mx6_grp_iomux-grp_ddrpke = grp-grp_ddrpke;
+
+   /* Clock */
+   mx6_ddr_iomux-dram_sdclk_0 = ddr-dram_sdclk_0;
+   mx6_ddr_iomux-dram_sdclk_1 = ddr-dram_sdclk_1;
+
+   /* Address */
+   mx6_ddr_iomux-dram_cas = ddr-dram_cas;
+   mx6_ddr_iomux-dram_ras = ddr-dram_ras;
+   mx6_grp_iomux-grp_addds = grp-grp_addds;
+
+   /* Control */
+   mx6_ddr_iomux-dram_reset = ddr-dram_reset;
+   mx6_ddr_iomux-dram_sdcke0 = ddr-dram_sdcke0;
+   mx6_ddr_iomux-dram_sdcke1 = ddr-dram_sdcke1;
+   mx6_ddr_iomux-dram_sdba2 = ddr-dram_sdba2;
+   mx6_ddr_iomux-dram_sdodt0 = ddr-dram_sdodt0;
+   mx6_ddr_iomux-dram_sdodt1 = ddr-dram_sdodt1;
+   mx6_grp_iomux-grp_ctlds = grp-grp_ctlds;
+
+   /* Data Strobes */
+   mx6_grp_iomux-grp_ddrmode_ctl = grp-grp_ddrmode_ctl;
+   mx6_ddr_iomux-dram_sdqs0 = ddr-dram_sdqs0;
+   mx6_ddr_iomux-dram_sdqs1 = ddr-dram_sdqs1;
+   if (width = 32) {
+   mx6_ddr_iomux-dram_sdqs2 = ddr-dram_sdqs2;
+   mx6_ddr_iomux-dram_sdqs3 = ddr-dram_sdqs3;
+   }
+   if (width = 64) {
+   mx6_ddr_iomux-dram_sdqs4 = ddr-dram_sdqs4;
+   mx6_ddr_iomux-dram_sdqs5 = ddr-dram_sdqs5;
+   mx6_ddr_iomux-dram_sdqs6 = ddr-dram_sdqs6;
+   mx6_ddr_iomux-dram_sdqs7 = ddr-dram_sdqs7;
+   }
+
+   /* Data */
+   mx6_grp_iomux-grp_ddrmode = grp-grp_ddrmode;
+   mx6_grp_iomux-grp_b0ds = grp-grp_b0ds;
+   mx6_grp_iomux-grp_b1ds = grp-grp_b1ds;
+   if (width = 32) {
+   mx6_grp_iomux-grp_b2ds = grp-grp_b2ds;
+   mx6_grp_iomux-grp_b3ds = grp-grp_b3ds;
+   }
+   if (width = 64) {
+   mx6_grp_iomux-grp_b4ds = grp-grp_b4ds;
+   mx6_grp_iomux-grp_b5ds = grp-grp_b5ds;
+   mx6_grp_iomux-grp_b6ds = grp-grp_b6ds;
+   mx6_grp_iomux-grp_b7ds = grp-grp_b7ds;
+   }
+   mx6_ddr_iomux-dram_dqm0 = ddr-dram_dqm0;
+   mx6_ddr_iomux-dram_dqm1 = ddr-dram_dqm1;
+   if (width = 32) {
+   mx6_ddr_iomux-dram_dqm2 = ddr-dram_dqm2;
+   mx6_ddr_iomux-dram_dqm3 = ddr-dram_dqm3;
+   }
+   if (width = 64) {
+   mx6_ddr_iomux-dram_dqm4 = ddr-dram_dqm4;
+   mx6_ddr_iomux-dram_dqm5 = ddr-dram_dqm5;
+   mx6_ddr_iomux-dram_dqm6 = ddr-dram_dqm6;
+   mx6_ddr_iomux-dram_dqm7 = ddr-dram_dqm7;
+   }
+}
+#endif
+
+#if defined(CONFIG_MX6QDL) || 

[U-Boot] [PATCH v4 09/10] imx: ventana: auto-configure for IMX6Q vs IMX6DL

2014-06-02 Thread Tim Harvey
use the new iomux function and a macros to create a multi-dimensional array
of iomux values without duplicating the defintions.

Cc: Stefan Roese s...@denx.de
Cc: Otavio Salvador ota...@ossystems.com.br
Cc: Andy Ng andreas2...@gmail.com
Cc: Eric Nelson eric.nel...@boundarydevices.com
Cc: Tapani Utriainen tap...@technexion.com
Cc: Tom Rini tr...@ti.com

Signed-off-by: Tim Harvey thar...@gateworks.com
---
v4:
 - no changes

v3:
 - replace use of imx_iomux_v3_setup_multiple_pads_array with
   imx_iomux_v3_setup_multiple_pads

v2:
 - use macros that have been moved to iomux-v3.h

---
 board/gateworks/gw_ventana/gw_ventana.c | 498 
 1 file changed, 312 insertions(+), 186 deletions(-)

diff --git a/board/gateworks/gw_ventana/gw_ventana.c 
b/board/gateworks/gw_ventana/gw_ventana.c
index a39374d..a33cb71 100644
--- a/board/gateworks/gw_ventana/gw_ventana.c
+++ b/board/gateworks/gw_ventana/gw_ventana.c
@@ -88,109 +88,149 @@ int board_type;
 
 /* UART1: Function varies per baseboard */
 iomux_v3_cfg_t const uart1_pads[] = {
-   MX6_PAD_SD3_DAT6__UART1_RX_DATA | MUX_PAD_CTRL(UART_PAD_CTRL),
-   MX6_PAD_SD3_DAT7__UART1_TX_DATA | MUX_PAD_CTRL(UART_PAD_CTRL),
+   IOMUX_PADS(PAD_SD3_DAT6__UART1_RX_DATA | MUX_PAD_CTRL(UART_PAD_CTRL)),
+   IOMUX_PADS(PAD_SD3_DAT7__UART1_TX_DATA | MUX_PAD_CTRL(UART_PAD_CTRL)),
 };
 
 /* UART2: Serial Console */
 iomux_v3_cfg_t const uart2_pads[] = {
-   MX6_PAD_SD4_DAT7__UART2_TX_DATA | MUX_PAD_CTRL(UART_PAD_CTRL),
-   MX6_PAD_SD4_DAT4__UART2_RX_DATA | MUX_PAD_CTRL(UART_PAD_CTRL),
+   IOMUX_PADS(PAD_SD4_DAT7__UART2_TX_DATA | MUX_PAD_CTRL(UART_PAD_CTRL)),
+   IOMUX_PADS(PAD_SD4_DAT4__UART2_RX_DATA | MUX_PAD_CTRL(UART_PAD_CTRL)),
 };
 
 #define PC MUX_PAD_CTRL(I2C_PAD_CTRL)
 
 /* I2C1: GSC */
-struct i2c_pads_info i2c_pad_info0 = {
+struct i2c_pads_info mx6q_i2c_pad_info0 = {
.scl = {
-   .i2c_mode = MX6_PAD_EIM_D21__I2C1_SCL | PC,
-   .gpio_mode = MX6_PAD_EIM_D21__GPIO3_IO21 | PC,
+   .i2c_mode = MX6Q_PAD_EIM_D21__I2C1_SCL | PC,
+   .gpio_mode = MX6Q_PAD_EIM_D21__GPIO3_IO21 | PC,
.gp = IMX_GPIO_NR(3, 21)
},
.sda = {
-   .i2c_mode = MX6_PAD_EIM_D28__I2C1_SDA | PC,
-   .gpio_mode = MX6_PAD_EIM_D28__GPIO3_IO28 | PC,
+   .i2c_mode = MX6Q_PAD_EIM_D28__I2C1_SDA | PC,
+   .gpio_mode = MX6Q_PAD_EIM_D28__GPIO3_IO28 | PC,
+   .gp = IMX_GPIO_NR(3, 28)
+   }
+};
+struct i2c_pads_info mx6dl_i2c_pad_info0 = {
+   .scl = {
+   .i2c_mode = MX6DL_PAD_EIM_D21__I2C1_SCL | PC,
+   .gpio_mode = MX6DL_PAD_EIM_D21__GPIO3_IO21 | PC,
+   .gp = IMX_GPIO_NR(3, 21)
+   },
+   .sda = {
+   .i2c_mode = MX6DL_PAD_EIM_D28__I2C1_SDA | PC,
+   .gpio_mode = MX6DL_PAD_EIM_D28__GPIO3_IO28 | PC,
.gp = IMX_GPIO_NR(3, 28)
}
 };
 
 /* I2C2: PMIC/PCIe Switch/PCIe Clock/Mezz */
-struct i2c_pads_info i2c_pad_info1 = {
+struct i2c_pads_info mx6q_i2c_pad_info1 = {
.scl = {
-   .i2c_mode = MX6_PAD_KEY_COL3__I2C2_SCL | PC,
-   .gpio_mode = MX6_PAD_KEY_COL3__GPIO4_IO12 | PC,
+   .i2c_mode = MX6Q_PAD_KEY_COL3__I2C2_SCL | PC,
+   .gpio_mode = MX6Q_PAD_KEY_COL3__GPIO4_IO12 | PC,
.gp = IMX_GPIO_NR(4, 12)
},
.sda = {
-   .i2c_mode = MX6_PAD_KEY_ROW3__I2C2_SDA | PC,
-   .gpio_mode = MX6_PAD_KEY_ROW3__GPIO4_IO13 | PC,
+   .i2c_mode = MX6Q_PAD_KEY_ROW3__I2C2_SDA | PC,
+   .gpio_mode = MX6Q_PAD_KEY_ROW3__GPIO4_IO13 | PC,
+   .gp = IMX_GPIO_NR(4, 13)
+   }
+};
+struct i2c_pads_info mx6dl_i2c_pad_info1 = {
+   .scl = {
+   .i2c_mode = MX6DL_PAD_KEY_COL3__I2C2_SCL | PC,
+   .gpio_mode = MX6DL_PAD_KEY_COL3__GPIO4_IO12 | PC,
+   .gp = IMX_GPIO_NR(4, 12)
+   },
+   .sda = {
+   .i2c_mode = MX6DL_PAD_KEY_ROW3__I2C2_SDA | PC,
+   .gpio_mode = MX6DL_PAD_KEY_ROW3__GPIO4_IO13 | PC,
.gp = IMX_GPIO_NR(4, 13)
}
 };
 
 /* I2C3: Misc/Expansion */
-struct i2c_pads_info i2c_pad_info2 = {
+struct i2c_pads_info mx6q_i2c_pad_info2 = {
+   .scl = {
+   .i2c_mode = MX6Q_PAD_GPIO_3__I2C3_SCL | PC,
+   .gpio_mode = MX6Q_PAD_GPIO_3__GPIO1_IO03 | PC,
+   .gp = IMX_GPIO_NR(1, 3)
+   },
+   .sda = {
+   .i2c_mode = MX6Q_PAD_GPIO_6__I2C3_SDA | PC,
+   .gpio_mode = MX6Q_PAD_GPIO_6__GPIO1_IO06 | PC,
+   .gp = IMX_GPIO_NR(1, 6)
+   }
+};
+struct i2c_pads_info mx6dl_i2c_pad_info2 = {
.scl = {
-   .i2c_mode = MX6_PAD_GPIO_3__I2C3_SCL | PC,
-   .gpio_mode = MX6_PAD_GPIO_3__GPIO1_IO03 | PC,
+   .i2c_mode = MX6DL_PAD_GPIO_3__I2C3_SCL | PC,
+   .gpio_mode = MX6DL_PAD_GPIO_3__GPIO1_IO03 | PC,

[U-Boot] [PATCH v4 10/10] imx: ventana: switch to SPL

2014-06-02 Thread Tim Harvey
Switch to an SPL image. The SPL for Ventana does the following:
 - setup i2c and read the factory programmed EEPROM to obtain DRAM config
   and model for board-specific calibration data
 - configure DRAM per CPU/size/layout/devices/calibration
 - load u-boot.img from NAND and jump to it

This allows for a single SPL+u-boot.img to replace the previous multiple boa
configurations.

Cc: Stefan Roese s...@denx.de
Cc: Otavio Salvador ota...@ossystems.com.br
Cc: Andy Ng andreas2...@gmail.com
Cc: Eric Nelson eric.nel...@boundarydevices.com
Cc: Tapani Utriainen tap...@technexion.com
Cc: Tom Rini tr...@ti.com

Signed-off-by: Tim Harvey thar...@gateworks.com
---
v4:
 - no changes

v3:
 - re-ordered calls in board_init_f

v2:
 - remove missing/unnecessary include
 - revert mtdparts change
 - use imx_ddr_size() which uses MMDC configuration to determine mem size
   explicitly
 - add support for MX6SOLO and MX6DUAL
 - set CS0_END for 4GB so get_ram_size() works
 - updated DDR3 calibration values for ventana boards
 - fixed build issue - only compile spl if doing spl build
 - fixed line length issue in README
 - remove CONFIG_SPL* conditions and conditionally compile instead
 - removed prints for CPU type and DRAM size/width - uboot will print these
   later
 - removed unused gw_ventana_spl.cfg
 - use common read_eeprom function
 - added MMC support to SPL

---
 board/gateworks/gw_ventana/Makefile |   1 +
 board/gateworks/gw_ventana/README   |  92 +++---
 board/gateworks/gw_ventana/gw_ventana.c |  10 +-
 board/gateworks/gw_ventana/gw_ventana.cfg   |  15 -
 board/gateworks/gw_ventana/gw_ventana_spl.c | 419 
 boards.cfg  |   6 +-
 include/configs/gw_ventana.h|  11 +
 7 files changed, 498 insertions(+), 56 deletions(-)
 create mode 100644 board/gateworks/gw_ventana/gw_ventana_spl.c

diff --git a/board/gateworks/gw_ventana/Makefile 
b/board/gateworks/gw_ventana/Makefile
index 03bd1fd..33a1788 100644
--- a/board/gateworks/gw_ventana/Makefile
+++ b/board/gateworks/gw_ventana/Makefile
@@ -7,4 +7,5 @@
 #
 
 obj-y  := gw_ventana.o gsc.o eeprom.o
+obj-$(CONFIG_SPL_BUILD) += gw_ventana_spl.o
 
diff --git a/board/gateworks/gw_ventana/README 
b/board/gateworks/gw_ventana/README
index 9e697d6..888657c 100644
--- a/board/gateworks/gw_ventana/README
+++ b/board/gateworks/gw_ventana/README
@@ -3,53 +3,81 @@ U-Boot for the Gateworks Ventana Product Family boards
 This file contains information for the port of U-Boot to the Gateworks
 Ventana Product family boards.
 
-1. Boot source, boot from NAND
+1. Secondary Program Loader (SPL)
+-
+
+The i.MX6 has a BOOT ROM PPL (Primary Program Loader) which supports loading
+an executable image from various boot devices.
+
+The Gateworks Ventana board config uses an SPL build configuration. This
+will build the following artifacts from u-boot source:
+ - SPL - Secondary Program Loader that the i.MX6 BOOT ROM (Primary Program
+ Loader) boots.  This detects CPU/DRAM configuration, configures
+ The DRAM controller, loads u-boot.img from the detected boot device,
+ and jumps to it.  As this is booted from the PPL, it has an IVT/DCD
+ table.
+ - u-boot.img - The main u-boot core which is u-boot.bin with a image header.
+
+
+2. Build
+
+
+To build U-Boot for the Gateworks Ventana product family:
+
+ make gwventana_config
+ make
+
+
+3. Boot source, boot from NAND
 --
 
 The i.MX6 BOOT ROM expects some structures that provide details of NAND layout
 and bad block information (referred to as 'bootstreams') which are replicated
-multiple times in NAND. The number of replications is configurable through
-board strapping options and eFUSE settings.  The Freescale 'kobs-ng'
-application from the Freescale LTIB BSP, which runs under Linux, must be used
-to program the bootstream in order to setup the replicated headers correctly.
+multiple times in NAND. The number of replications and their spacing (referred
+to as search stride) is configurable through board strapping options and/or
+eFUSE settings (BOOT_SEARCH_COUNT / Pages in block from BOOT_CFG2). In
+addition, the i.MX6 BOOT ROM Flash Configuration Block (FCB) supports two
+copies of a bootloader in flash in the case that a bad block has corrupted one.
+The Freescale 'kobs-ng' application from the Freescale LTIB BSP, which runs
+under Linux and operates on an MTD partition, must be used to program the
+bootstream in order to setup this flash structure correctly.
 
 The Gateworks Ventana boards with NAND flash have been factory programmed
 such that their eFUSE settings expect 2 copies of the boostream (this is
 specified by providing kobs-ng with the --search_exponent=1 argument). Once in
-Linux with MTD support for the NAND on /dev/mtd0 you can program the boostream
+Linux with MTD support for the NAND on /dev/mtd0 you can program the SPL
 with:
 
-kobs-ng init 

[U-Boot] [PATCH v4 08/10] imx: ventana: split read_eeprom into standalone file

2014-06-02 Thread Tim Harvey
Split the read_eeprom function out so that it can be shared (ie with SPL)

Cc: Stefan Roese s...@denx.de
Cc: Otavio Salvador ota...@ossystems.com.br
Cc: Andy Ng andreas2...@gmail.com
Cc: Eric Nelson eric.nel...@boundarydevices.com
Cc: Tapani Utriainen tap...@technexion.com
Cc: Tom Rini tr...@ti.com

Signed-off-by: Tim Harvey thar...@gateworks.com
---
v4:
 - no changes

v3:
 - no changes

v2:
 - new patch in series

---
 board/gateworks/gw_ventana/Makefile |  2 +-
 board/gateworks/gw_ventana/eeprom.c | 89 +
 board/gateworks/gw_ventana/gw_ventana.c | 89 +
 board/gateworks/gw_ventana/ventana_eeprom.h | 11 
 4 files changed, 102 insertions(+), 89 deletions(-)
 create mode 100644 board/gateworks/gw_ventana/eeprom.c

diff --git a/board/gateworks/gw_ventana/Makefile 
b/board/gateworks/gw_ventana/Makefile
index e8dab89..03bd1fd 100644
--- a/board/gateworks/gw_ventana/Makefile
+++ b/board/gateworks/gw_ventana/Makefile
@@ -6,5 +6,5 @@
 # SPDX-License-Identifier:  GPL-2.0+
 #
 
-obj-y  := gw_ventana.o gsc.o
+obj-y  := gw_ventana.o gsc.o eeprom.o
 
diff --git a/board/gateworks/gw_ventana/eeprom.c 
b/board/gateworks/gw_ventana/eeprom.c
new file mode 100644
index 000..e90186e
--- /dev/null
+++ b/board/gateworks/gw_ventana/eeprom.c
@@ -0,0 +1,89 @@
+/*
+ * Copyright (C) 2014 Gateworks Corporation
+ * Author: Tim Harvey thar...@gateworks.com
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include common.h
+#include i2c.h
+
+#include gsc.h
+#include ventana_eeprom.h
+
+/* read ventana EEPROM, check for validity, and return baseboard type */
+int
+read_eeprom(int bus, struct ventana_board_info *info)
+{
+   int i;
+   int chksum;
+   char baseboard;
+   int type;
+   unsigned char *buf = (unsigned char *)info;
+
+   memset(info, 0, sizeof(*info));
+
+   /*
+* On a board with a missing/depleted backup battery for GSC, the
+* board may be ready to probe the GSC before its firmware is
+* running.  We will wait here indefinately for the GSC/EEPROM.
+*/
+   while (1) {
+   if (0 == i2c_set_bus_num(bus) 
+   0 == i2c_probe(GSC_EEPROM_ADDR))
+   break;
+   mdelay(1);
+   }
+
+   /* read eeprom config section */
+   if (gsc_i2c_read(GSC_EEPROM_ADDR, 0x00, 1, buf, sizeof(*info))) {
+   puts(EEPROM: Failed to read EEPROM\n);
+   info-model[0] = 0;
+   return GW_UNKNOWN;
+   }
+
+   /* sanity checks */
+   if (info-model[0] != 'G' || info-model[1] != 'W') {
+   puts(EEPROM: Invalid Model in EEPROM\n);
+   info-model[0] = 0;
+   return GW_UNKNOWN;
+   }
+
+   /* validate checksum */
+   for (chksum = 0, i = 0; i  sizeof(*info)-2; i++)
+   chksum += buf[i];
+   if ((info-chksum[0] != chksum8) ||
+   (info-chksum[1] != (chksum0xff))) {
+   puts(EEPROM: Failed EEPROM checksum\n);
+   info-model[0] = 0;
+   return GW_UNKNOWN;
+   }
+
+   /* original GW5400-A prototype */
+   baseboard = info-model[3];
+   if (strncasecmp((const char *)info-model, GW5400-A, 8) == 0)
+   baseboard = '0';
+
+   switch (baseboard) {
+   case '0': /* original GW5400-A prototype */
+   type = GW54proto;
+   break;
+   case '1':
+   type = GW51xx;
+   break;
+   case '2':
+   type = GW52xx;
+   break;
+   case '3':
+   type = GW53xx;
+   break;
+   case '4':
+   type = GW54xx;
+   break;
+   default:
+   printf(EEPROM: Unknown model in EEPROM: %s\n, info-model);
+   type = GW_UNKNOWN;
+   break;
+   }
+   return type;
+}
diff --git a/board/gateworks/gw_ventana/gw_ventana.c 
b/board/gateworks/gw_ventana/gw_ventana.c
index 031367d..a39374d 100644
--- a/board/gateworks/gw_ventana/gw_ventana.c
+++ b/board/gateworks/gw_ventana/gw_ventana.c
@@ -84,15 +84,6 @@ DECLARE_GLOBAL_DATA_PTR;
  */
 static struct ventana_board_info ventana_info;
 
-enum {
-   GW54proto, /* original GW5400-A prototype */
-   GW51xx,
-   GW52xx,
-   GW53xx,
-   GW54xx,
-   GW_UNKNOWN,
-};
-
 int board_type;
 
 /* UART1: Function varies per baseboard */
@@ -499,84 +490,6 @@ static void setup_display(void)
 }
 #endif /* CONFIG_VIDEO_IPUV3 */
 
-/* read ventana EEPROM, check for validity, and return baseboard type */
-static int
-read_eeprom(void)
-{
-   int i;
-   int chksum;
-   char baseboard;
-   int type;
-   struct ventana_board_info *info = ventana_info;
-   unsigned char *buf = (unsigned char *)ventana_info;
-
-   memset(info, 0, sizeof(ventana_info));
-
-   /*
-* On a board with a missing/depleted backup battery for GSC, the
-* 

Re: [U-Boot] (no subject)

2014-06-02 Thread rajshekar_py

Hi! http://netreign.com/_redirect?wynymaq917558

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


Re: [U-Boot] [PATCH] arm: Allow u-boot to run from offset base address

2014-06-02 Thread Darwin Rambo



On 14-06-02 12:26 AM, Albert ARIBAUD wrote:

Hi Darwin,

On Mon, 26 May 2014 09:11:35 -0700, Darwin Rambo dra...@broadcom.com
wrote:


Hi Albert,

The previous stage bootloader (which I had no control over) wanted it's
header to be aligned to a 512 byte MMC block boundary, presumably since
this allowed DMA operations without copy/shifting. At the same time, I
didn't want to hack a header into start.S because I didn't want to carry
another downstream patch. So I investigated if I could shift u-boot's
base address as a feature that would allow an aligned header to be used
without the start.S patch.

I know that a custom header patch to start.S would work, and that a
header plus padding will also work. But I found out that you can align
the base on certain smaller offsets if you keep the relocation offset at
nice boundaries like 0x1000 and if the relocation offset is a multiple
of the maximum alignment requirements of the image.

The original patch I submitted didn't handle an end condition properly,
was ARM64-specific (wasn't tested on other architectures), and because
the patch was NAK'd, I didn't bother to submit a v2 patch and consider
the idea to be dead. I'm happy to abandon the patch. I hope this helps.


Thanks.

If I understand correctly, your target has a requirement for storing
the image on a 512-byte boundary. But how does this affect the loading
of the image into RAM, where the requirement is only that the vectors
table be 32-bytes aligned? I mean, if you store the image in MMC at
offset 0x200 (thus satisfying the 512-byte boundary requirement) and
load it to, say, offset 0x10020 in RAM, how is it a problem for
your target?

If my example above inadequately represents the issue, then can you
please provide a similar but adequate example, a failure case scenario,
so that I can hve a correct understanding of the problem?


Hi Albert,

The constraints I have that I can't change, are that
- the 32 byte header is postprocessed and prepended to the image after 
the build is complete

- the header is at a 512 byte alignment in MMC
- the header and image are copied to SDRAM to an alignment like 
0x8800. Thus the u-boot image is linked at and starts at 0x8820.

- the vectors need to be 0x800 aligned for armv8 (.align 11 directive)

So the failure case is that when the relocation happens, it relocates to 
a 0x1000 alignment, say something like 0xa000. The relocation offset 
is not a multiple of 0x1000 (0xa000 - 0x8820) and the relocation 
fails. Adjusting the relocation offset to a multiple of 0x1000 (by 
making the relocation address end in 0xN020) fixes the issues and 
allows u-boot to relocate and run from this address without failing. I 
hope this helps explain it a bit better.


Best regards,
Darwin




Best regards,
Darwin


Amicalement,


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


Re: [U-Boot] [RFC] Extend 'bootm' to support Linux kernel generated images

2014-06-02 Thread Simon Glass
Hi Tom,

On 24 May 2014 06:21, Tom Rini tr...@ti.com wrote:

 On Fri, May 23, 2014 at 03:57:34PM -1000, Simon Glass wrote:
  Hi Tom,
 
  On 21 May 2014 10:46, Tom Rini tr...@ti.com wrote:
   On Wed, May 21, 2014 at 10:10:50PM +0200, Wolfgang Denk wrote:
   Dear Tom Rini,
  
   In message 20140521195824.GE1752@bill-the-cat you wrote:
   
Something that Rob mentioned to me at ELC, and others have mentioned
before is that it would be nice if 'bootm' (which says boot
 application
image stored in memory in the help, even) would just work with
 zImage
or Image or whatever is spit directly out of the kernel.
  
   I don;t think this is a good idea.  application image is supposed to
   mean one of the U-Boot image formats, which means the old legacy
   image format (with the 64 byte header), or FIT images.  To boot a
   zImage file, we have the bootz command.
  
   Yes, it's historically meant something with an essentially (technically
   no, practically, yes) U-Boot centric header on it.  But that's not what
   the help text says.  And yes we have bootz for zImages and I added
 booti
   for Image images.  That resulted in You mean I have to type different
   things for arm and arm64? *sigh* when explaining this in person.
  
   I also think such a patch is pushing into the wrong direction.  We
   should rather try and improve the kernel support for FIT images.
  
   That's neither here nor there.  You can create and boot FIT images
   today, anywhere it's enabled (including arm64).  You can do the same
   with legacy images (which also resulted in sighs when I mentioned
 this).
   The kernel doesn't want any of this in the kernel tree.  Developers
 want
   to have as few steps between build my kernel and now I'm testing my
   kernel.  Adding in create / grab stub FIT file, run mkimage results
   in more unhappy developers.
 
  Unless I'm imagining it, some years ago I could type 'make fit_image'
  or similar for the kernel and get an image ready to boot. Did someone
  remove that feature from Linux and expect the number of steps needed
  to build a kernel to stay the same?

 It wasn't in mainline, I'm fairly certain.  Or maybe it was an arch/ppc
 thing that got dropped along the way.


I took at look and now think I just imagined it, or perhaps had some
patches applied.



  It surprises me the lengths to which people are going to try to
  shoehorn .dtbs, compression, multiple dtbs, multi-arch etc. into the
  kenel zImage format. The decompression header is ugly, plus it is
  slower than doing these things in U-Boot.

 Well, with arm64 the kernel is just getting out of the business, hence
 booti (or however we add Image support) and not do the zImage dance.


Does this mean a clean Image with no add-ons?

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


Re: [U-Boot] Some Driver Model Ponderings

2014-06-02 Thread Simon Glass
Hi Jon,

On 28 May 2014 09:22, Jon Loeliger loeli...@gmail.com wrote:

 Hi U-Booters,

 Over the past few days, I had an off-line conversation with Simon Glass
 on the topic of the Driver Model.  At his request, I've edited that
 conversation into this piece of email for the U-Boot List in the
 hopes that others in the community might also benefit.

 Already, some documentation patches have been offered as a result.

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


[snip]

Thanks very much for putting this together, much appreciated. If there
are still open questions (I maybe count two in your email) we could
discuss them in this thread.

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


Re: [U-Boot] [PATCH v3] Exynos: Make sure ps_hold gets set in the SPL

2014-06-02 Thread Minkyu Kang
On 03/06/14 06:18, Simon Glass wrote:
 Hi Minkyu,
 
 On 30 May 2014 23:24, Minkyu Kang mk7.k...@samsung.com wrote:
 On 30/05/14 01:10, Akshay Saraswat wrote:
 From: Doug Anderson diand...@chromium.org

 Setting ps_hold ought to be one of the first things we do when we
 first boot up. If we wait until the main u-boot runs we won't set it
 in time and the PMIC may power us back off.

 Signed-off-by: Doug Anderson diand...@chromium.org
 Signed-off-by: Akshay Saraswat aksha...@samsung.com
 Acked-by: Simon Glass s...@chromium.org
 ---
 Changes since v2:
   - Removed function power_init and directly called set_ps_hold_strl.

 Changes since v1:
   - Added Acked-by.

  arch/arm/cpu/armv7/exynos/lowlevel_init.c | 6 +-
  arch/arm/cpu/armv7/exynos/power.c | 6 ++
  arch/arm/include/asm/arch-exynos/power.h  | 1 +
  3 files changed, 12 insertions(+), 1 deletion(-)


 applied to u-boot-samsung
 
 Now that we have this patch we may be able to revert eb0dd99?
 

Indeed.
I will.

Thanks,
Minkyu Kang.

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


Re: [U-Boot] Driver Model and DTS Parsing

2014-06-02 Thread Simon Glass
Hi Jon,

On 30 May 2014 08:49, Jon Loeliger loeli...@gmail.com wrote:
 Folks,

 I'd like to discuss the new Driver Model's parsing of the DTS file
 for the purposes of instancing and binding devices as I was not
 able to get the existing code to work anything like I was expecting.

 The current code only finds and binds the top-level nodes of the
 DTS file.  This leads to a bind function one-level above where it
 should be for each of the actual device nodes and an extra parent
 node that is empty.  For example, the gpio_exynos_gpio_bind()
 function here:

 http://git.denx.de/?p=u-boot/u-boot-x86.git;a=blob;f=drivers/gpio/s5p_gpio.c;h=8100d50ed2da686353c593ed90693c441cf24b4f;hb=refs/heads/us-gpioc

 Looks like this:

 386 /**
 387  * We have a top-level GPIO device with no actual GPIOs. It has a child
 388  * device for each Exynos GPIO bank.
 389  */
 390 static int gpio_exynos_bind(struct device *parent)
 391 {
 392 struct exynos_gpio_platdata *plat = parent-platdata;
 393 struct s5p_gpio_bank *bank;
 394 const void *blob = gd-fdt_blob;
 395 int node;
 396
 397 /* If this is a child device, there is nothing to do here */
 398 if (plat)
 399 return 0;
 400
 401 bank = (struct s5p_gpio_bank *)fdtdec_get_addr(gd-fdt_blob,
 402
 parent-of_offset, reg);
 403 for (node = fdt_first_subnode(blob, parent-of_offset); node  0;
 404  node = fdt_next_subnode(blob, node)) {
 405 struct exynos_gpio_platdata *plat;
 406 struct device *dev;
 407 int ret;
 408
 409 plat = calloc(1, sizeof(*plat));
 410 if (!plat)
 411 return -ENOMEM;
 412 plat-bank = bank;
 413 plat-port_name = fdt_get_name(blob, node, NULL);
 414
 415 ret = device_bind(parent, parent-driver,
 416 plat-port_name, plat, -1, dev);
 417 if (ret)
 418 return ret;
 419 dev-of_offset = parent-of_offset;
 420 bank++;
 421 }
 422
 423 return 0;
 424 }

 Why is this function being called once at the parent node, which
 then iterates over each device, instantiates and binds it?  Why
 isn't this function instead called once for each individual device
 as matched from the DTS?  Where did the compatible matching
 and check take place in this implementation?

Driver model works by looking up compatible strings in the top-level
nodes and binding a driver for each one it finds.

The exynos pinctrl device tree binding does not have a compatible
string in each of its banks. In fact it just has a single compatible
string at the level above the banks. So there seems to be no
alternative but to iterate through the banks binding devices as we go.

The node looks something like this:

pinctrl@1341 {
compatible = samsung,exynos5420-pinctrl;
reg = 0x1341 0x011f;
interrupts = 0x 0x67706330 0x04a6;
gpc0 {
gpio-controller;
#gpio-cells = 0x0002;
interrupt-controller;
#interrupt-cells = 0x0002;
};
gpc1 {
gpio-controller;
#gpio-cells = 0x0002;
interrupt-controller;
#interrupt-cells = 0x0002;
};

So we get a bind call on the pinctrl node and then bind each of the banks.




 Instead, I think it should be a recursive structure essentially
 identical in structure to the Linux of_platform_populate() function.
 There should be a compatible matching step, and then the
 call to bind the specific instance.

 Am I missing something here?  Or is this code that just needs to
 be developed further still?

Certainly this could be done, and it's a small change but this code
doesn't exist yet. I deliberately left this out of the implementation
until we have I2C implemented, or something similar. Then it will be
clearer what is needed here.

My concern is partly that access to the device may be mediated through
the parent and thus not discoverable by the child. As an example, the
Chrome OS EC driver can attached to I2C, SPI or LPC. The connection
needs to be made at the parent level, which provides a
'communications' layer for the generic driver.

So in short I think we need to address these things and make the
decisions as we go. For the same reason I didn't implement driver
model for SPL or pre-relocation (although I have a series out for the
latter now).

A lot of things will be clearer to me when I2C is ported over.

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


Re: [U-Boot] coreboot and u-boot integration x86: No tick base available

2014-06-02 Thread Simon Glass
Hi Martin,

On 1 June 2014 23:59, Martin Ertsås marti...@gmail.com wrote:
 On 06/01/14 18:42, Simon Glass wrote:
 Hi Martin,

 On 30 May 2014 04:33, Martin Ertsås marti...@gmail.com wrote:
 Hi.

 I'm trying to use u-boot as a payload to coreboot. Problem is that when
 coreboot starts u-boot, it fails with panic(No tick base available);

 When looking at the backtrace this gives a recursive error, as panic
 calls __udelay and get_ticks, which again panics. I heard this was
 because u-boot overwrote the memory location of coreboot, and that there
 have been some patches going around that fixes this issue, but have not
 made it upstream. As far as I can tell, chromebook v2 uses these patches
 to make their stuff boot. Can anyone point me in the right direction for
 those patches? I have tried finding them myself, but can't seem to find
 them.

 It probably means that Coreboot is not passing its timing data to
 U-Boot. You need to enable a timestamp option in Coreboot to do this.

 You could patch it to remove this panic and just use 0 in this case.

 Regards,
 Simon

 Thanks. I'll look into the timestamp option. So using 0 as the tick
 value should work?

Yes, although you won't get boot timing from Coreboot then. One of the
engineers favoured a panic() to avoid accidentally dropping the
function from Coreboot's build. Perhaps it could be changed to be a
default in Coreboot? This is the second time the issue has come up in
U-Boot.

Also I'd be happy with printing a warning in this case if you want to
do a patch.

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


Re: [U-Boot] [RFC PATCH 03/22] dm: Make sure that the root device is probed

2014-06-02 Thread Simon Glass
Hi Marek,

On 1 June 2014 11:33, Marek Vasut ma...@denx.de wrote:
 On Saturday, May 24, 2014 at 11:21:02 PM, Simon Glass wrote:
 The root device should be probed just like any other device. The effect of
 this is to mark the device as activated, so that it can be removed (along
 with its children) if required.

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

  drivers/core/root.c | 3 +++
  test/dm/core.c  | 2 +-
  2 files changed, 4 insertions(+), 1 deletion(-)

 diff --git a/drivers/core/root.c b/drivers/core/root.c
 index 4427b81..9fff164 100644
 --- a/drivers/core/root.c
 +++ b/drivers/core/root.c
 @@ -48,6 +48,9 @@ int dm_init(void)
   ret = device_bind_by_name(NULL, root_info, DM_ROOT());

 Off-topic: This DM_ROOT() above looks a little suspicious, don't you think?

Yes. I wonder if it should not be written as a function?

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


Re: [U-Boot] [RFC 01/10] ARM: crt0.S: clear the global data

2014-06-02 Thread Simon Glass
Hi Jeroen,

On 31 May 2014 14:32, Jeroen Hofstee jer...@myspectrum.nl wrote:
 NOTE: smdk5420 snow smdkv310 apf27 arndale origen vpac270_ond_256 smdk5250
 don't have a memset available.

You should add a message explaining the motivation for the change.

Can you add a memset()?

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


Re: [U-Boot] [RFC 03/10] board_r: only assign gd when requested

2014-06-02 Thread Simon Glass
On 31 May 2014 14:32, Jeroen Hofstee jer...@myspectrum.nl wrote:
 When CONFIG_SYS_GENERIC_GLOBAL_DATA is not set the arch handles
 the assignment of gd. At least in case of ARM/Aarch64 this means
 board_init_r is alteady called with the new gd. Therefore only
 assign gd if CONFIG_SYS_GENERIC_GLOBAL_DATA is defined.

I think you might be missing a signoff (you might consider using
patman). Apart from that it looks good.

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

 ---
  common/board_r.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/common/board_r.c b/common/board_r.c
 index 602a239..18bbe26 100644
 --- a/common/board_r.c
 +++ b/common/board_r.c
 @@ -927,7 +927,7 @@ void board_init_r(gd_t *new_gd, ulong dest_addr)
 int i;
  #endif

 -#ifndef CONFIG_X86
 +#ifdef CONFIG_SYS_GENERIC_GLOBAL_DATA
 gd = new_gd;
  #endif

 --
 1.8.3.2

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


Re: [U-Boot] [RFC 04/10] ARM: do not set gd in generic board again

2014-06-02 Thread Simon Glass
On 31 May 2014 14:32, Jeroen Hofstee jer...@myspectrum.nl wrote:
 Since crt0.S / crt0_64.S already allocate gd and assing it there
 is no need to do it again board_f / board_r as it only wastes
 stack space.

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

 ---
  arch/arm/include/asm/config.h | 2 --
  1 file changed, 2 deletions(-)

 diff --git a/arch/arm/include/asm/config.h b/arch/arm/include/asm/config.h
 index 2a20a77..abf79e5 100644
 --- a/arch/arm/include/asm/config.h
 +++ b/arch/arm/include/asm/config.h
 @@ -7,8 +7,6 @@
  #ifndef _ASM_CONFIG_H_
  #define _ASM_CONFIG_H_

 -#define CONFIG_SYS_GENERIC_GLOBAL_DATA
 -
  #define CONFIG_LMB
  #define CONFIG_SYS_BOOT_RAMDISK_HIGH

 --
 1.8.3.2

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


Re: [U-Boot] [RFC 05/10] ARM: SPL: do not set gd again

2014-06-02 Thread Simon Glass
On 31 May 2014 14:32, Jeroen Hofstee jer...@myspectrum.nl wrote:
 ---
  arch/arm/lib/spl.c | 3 ---
  1 file changed, 3 deletions(-)

Needs commit message/signoff, but this seems to be throughout the
series. Apart from that:

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



 diff --git a/arch/arm/lib/spl.c b/arch/arm/lib/spl.c
 index dfcc596..75ab546 100644
 --- a/arch/arm/lib/spl.c
 +++ b/arch/arm/lib/spl.c
 @@ -28,9 +28,6 @@ void __weak board_init_f(ulong dummy)
 /* Clear the BSS. */
 memset(__bss_start, 0, __bss_end - __bss_start);

 -   /* Set global data pointer. */
 -   gd = gdata;
 -
 board_init_r(NULL, 0);
  }

 --
 1.8.3.2

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


Re: [U-Boot] smp_kick_all_cpus() function's role

2014-06-02 Thread TigerLiu
Hi, Marc:
In short, if you're setting GICD_SGIR[24] to 1, you're sending SGI0 to
all CPUs but yourself. This seems to match the name of the function,
doesn't it?
I described my understanding based on 2014.07-RC2 u-boot source code:
(For ARMv8 cores)
1. smp_kick_all_cpus() will send SGI0 to all other cores except BSP.
   These non-BSP cores handled this SGI0 in gic_wait_for_interrupt(), and then 
switched to EL2/EL1 .
   These code is implemented in lowlevel_init in arch/arm/cpu/armv8/start.S.
  Is my understanding right?
2. if runing with ATF(Arm Trusted Firmware) + Uboot.bin
   ATF has put non-BSP cores to WFI state.
   So, before jumping to u-boot's entrypoint, there is only a BSP .
   So, smp_kick_all_cpus() could wake up these non-BSP cores?

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


Re: [U-Boot] [RFC 07/10] ARM: make gd a function a function for clang

2014-06-02 Thread Simon Glass
Hi Jeroen,

On 31 May 2014 14:32, Jeroen Hofstee jer...@myspectrum.nl wrote:
 ---
  arch/arm/include/asm/global_data.h | 17 +
  1 file changed, 17 insertions(+)

 diff --git a/arch/arm/include/asm/global_data.h 
 b/arch/arm/include/asm/global_data.h
 index 63e4ad5..646d694 100644
 --- a/arch/arm/include/asm/global_data.h
 +++ b/arch/arm/include/asm/global_data.h
 @@ -44,10 +44,27 @@ struct arch_global_data {

  #include asm-generic/global_data.h

 +#ifdef __clang__
 +
 +#define DECLARE_GLOBAL_DATA_PTR
 +#define gd get_gd()
 +
 +static __inline volatile gd_t *get_gd(void)
 +{
 +   gd_t *gd_ptr;
 +
 +   __asm__ volatile(mov %0, r9\n : =r (gd_ptr));
 +
 +   return gd_ptr;
 +}
 +
 +#else
 +
  #ifdef CONFIG_ARM64
  #define DECLARE_GLOBAL_DATA_PTRregister volatile gd_t *gd 
 asm (x18)
  #else
  #define DECLARE_GLOBAL_DATA_PTRregister volatile gd_t *gd 
 asm (r9)
  #endif
 +#endif

  #endif /* __ASM_GBL_DATA_H */

Probably a good idea to copy Albert on these patches. What happens if
you compile ARM64 with Clang?

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


Re: [U-Boot] [Patman Bug Report] Patman breaks git-log during git-rebase

2014-06-02 Thread Simon Glass
Hi Masahiro,

On 2 June 2014 01:44, Masahiro Yamada yamad...@jp.panasonic.com wrote:
 Hi Simon,

 I found an odd behavior of Patman.

 If I run Patman during git rebase -i,
 Patman rewrites git-log, stripping all the Patman-tags.
 (I lost some important tags such as Series-changes.)

 I think git-log should be read-only during Patman operation.
 I can't understand why Patman needs to directly edit git-log.
 Is this a fixable problem?

Probably you shouldn't do that. For me patman normally complains that
it can't find patches to process, and stops.

Can you give me the repeat steps? I think I have seen this before but
I'm not sure how to make it.

Also, patman never edits commits. I wonder if patman is moving you to
the wrong commit somehow. Try 'git reflog' to find something to get
back to.

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


Re: [U-Boot] tftp command return value

2014-06-02 Thread Simon Glass
Hi,

On 1 June 2014 22:32, l3iggs . l3i...@live.com wrote:
 Hello,

 I'd like to test if a file  on my TFTP server exists. I would expect that 
 using 'if tftp filename.ext; then echo exists; else echo doesnt; fi' woudl 
 work here. However, It always shows that the file exists. I expect that 
 others want to do the same thing because grep -r if tftp include/configs/ 
 gives 15 hists.

 'test -e tftp filename.ext` does not work either.

 Does anyone have a solution for this?

Are you using hush? If so, does this patch help?

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

You could add some debugging but I would hope that do_tftpb() would
return 1 in the error case.

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


Re: [U-Boot] Command repeat

2014-06-02 Thread Simon Glass
Hi Thomas,

On 30 May 2014 11:55, Simon Glass s...@chromium.org wrote:
 Hi Tom,

 On 30 May 2014 11:51, Tom Rini tr...@ti.com wrote:
 On Wed, May 28, 2014 at 09:34:25PM +0200, thomas.bet...@rohde-schwarz.com 
 wrote:

 Hello all,

 I have noticed that command repeat doesn't work as it should.
 CONFIG_SYS_HUSH_PARSER is disabled in my config.

 Here is what happens: main_loop() expects run_command() to return -1 for
 failure, 0 or 1 for success (not repeatable or repeatable). However,
 run_command() actually returns 1 for failure, 0 for success. So if a
 command is successful, main_loop() always thinks that it is not repeatable
 ...

 I guess that instead of run_command(), main_loop() should call
 builtin_run_command(). Note that main_loop() calls run_command() only when
 CONFIG_SYS_HUSH_PARSER is not enabled, and in this case, run_command()
 just calls builtin_run_command() anyway -- except that it remaps the
 return code.

 This issue was introduced by the patches in 2012-03-06, and in particular,
 commit 5307153236caaf2304e578c148e00a4b65cb8604, Stop using
 builtin_run_command().

 There is one other location which relies on the -1/0/1 logic, viz.,
 bedbug_main_loop(). Perhaps we need some general function which is called
 by main_loop() and  bedbug_main_loop():

 int run_command_repeatable(const char *cmd, int flag)
 {
 #ifndef CONFIG_SYS_HUSH_PARSER
 return builtin_run_command(cmd, flag);
 #else
 if (parse_string_outer(cmd,
 FLAG_PARSE_SEMICOLON |
 FLAG_EXIT_FROM_LOOP))
 return -1;
 return 0;
 #endif
 }

 [Note: parse_string_outer() always returns 0 for success, 1 for failure.]

 Any thoughts on this? I am willing to prepare a patch, but I certainly
 don't mind if this is handled by somebody else who is deeper into u-boot
 than me.

 Thoughts on this Simon?  Thanks!

 Yes I saw it but haven't got to it yet.

 I noticed this oddness (command return value changing) when I did the
 'empty' hush command series recently, but I didn't realise it was a
 bug at the time.

 Thomas, a patch is welcome, but we really should add a test for this,
 to the command processing unit tests. I've been thinking about being
 able to 'inject' commands through a fake/test readline - that might be
 one approach. We should continue to expand the test coverage to avoid
 such regressions.

Are you planning to work on a patch?

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


Re: [U-Boot] [PATCH v2 08/11] buildman: adjust for Kconfig

2014-06-02 Thread Simon Glass
On 28 May 2014 07:05, Masahiro Yamada yamad...@jp.panasonic.com wrote:
 Use make board_defconfig instead of make board_config.

 FIXME!
 This fixup is bad because it still depends on boards.cfg
 to support options such as -a ARCH, -c CPU etc.
 We want to delete it when switching to Kconfig.

 We have to invent another method without using boards.cfg.

It seems good enough while we still have this file.

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

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

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


Re: [U-Boot] [PATCH v2 07/11] MAKEALL: adjust for Kconfig

2014-06-02 Thread Simon Glass
On 28 May 2014 07:05, Masahiro Yamada yamad...@jp.panasonic.com wrote:
 Use make board_defconfig instead of make board_config.

 FIXME!
 This fixup is bad because it still depends on boards.cfg
 to support options such as -a ARCH, -c CPU etc.
 We want to delete it when switching to Kconfig.

 We have to invent another method without using boards.cfg.

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

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

 ---

 Changes in v2: None

  MAKEALL | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

 diff --git a/MAKEALL b/MAKEALL
 index 020e65f..45b28f4 100755
 --- a/MAKEALL
 +++ b/MAKEALL
 @@ -506,9 +506,9 @@ get_target_location() {

 set ${line}

 -   CONFIG_NAME=${7%_config}
 +   CONFIG_NAME=${7%_defconfig}

 -   [ ${BOARD_NAME} ] || BOARD_NAME=${7%_config}
 +   [ ${BOARD_NAME} ] || BOARD_NAME=${7%_defconfig}

 if [ $# -gt 5 ]; then
 if [ $6 = - ] ; then
 @@ -645,7 +645,7 @@ build_target() {
 fi

 ${MAKE} distclean /dev/null
 -   ${MAKE} -s ${target}_config
 +   ${MAKE} -s ${target}_defconfig

 ${MAKE} ${JOBS} ${CHECK} all \
 ${LOG_DIR}/$target.MAKELOG 2 ${LOG_DIR}/$target.ERR
 --
 1.9.1

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


Re: [U-Boot] [PATCH 2/5] board_r: run scsi init() on ARM too

2014-06-02 Thread Simon Glass
Hi Ian,

On 31 May 2014 10:36, Ian Campbell i...@hellion.org.uk wrote:
 This has been disabled for ARM in initr_scsi since that function was
 introduced. However it works fine for me on Cubieboard and Cubietruck (with 
 the
 upcoming AHCI glue patch).

 I also tested on two random ARM platforms which seem to define 
 CONFIG_CMD_SCSI:
  - highbank worked fine (on midway hardware)
  - omap5_uevm built OK and I confirmed using objdump that things were as
expected (i.e. the default weak scsi_init nop was used).

 While there remove the mismatched comment from the #endif (omitting the 
 comment
 seems to be the prevailing style in this file) and add a missing return to
 initr_doc which I happened to spot while editing.

 Signed-off-by: Ian Campbell i...@hellion.org.uk
 Cc: Simon Glass s...@chromium.org

I see no build breakage for ARM boards with this patch.

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

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


[U-Boot] Building common/lib files in tools/

2014-06-02 Thread Simon Glass
Hi Masahiro,

I see that we have a few files in tools/ which #include their
counterpart .c files in common/ or lib/. The most noticeable example
is libfdt.

Is there a better way of doing this? Would it be possible to pick up
the files automatically and still put the output file in tools/?

The reason I ask is that I would like to add support for decompression
into a tool, but the thought of adding links to all the compression
library files leaves me with a bad taste in my mouth.

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


[U-Boot] [PATCH v3 0/14] Minor improvements to secure boot and enable on beaglebone

2014-06-02 Thread Simon Glass
This series fixes a few problems that have come up since the secure boot
series was merged:

- A recent commit broken the assumption that u-boot.bin ends at a known
address (thus making things appended to U-Boot inaccessible from the code).
This is fixed for Beaglebone and a few other boards. A new test is added to
the Makefile to ensure that it does not break again. All boards have been
tested to make sure the problem does not appear elsewhere.

- A way is needed to provide an externally-build device tree binary for
U-Boot. This allows signing to happen outside the U-Boot build system.

- The .img files generated by an OMAP build need to include the FDT if one
is appended.

- Adding signatures to an FDT can cause the FDT to run out of space. The
fix is to regenerate the FDT from scratch with different dtc parameters, so
pretty painful. Instead, we automatically expand the FDT.

The last commit enables verified boot on a Beaglebone Black with a special
configuration. Use 'am335x_boneblack_vboot' for this. This will soon disable
support for legacy images.

Changes in v3:
- Add new patch to ensure the hash section is inside the image for cm_t335
- Add new patch to ensure the hash section is inside the image for mx31ads
- Rebase to master and update commit message
- Fix typo in commit message
- Add new patch to improve error handling in fit_common
- Rebase to master
- Also enable LZO and timestamps, plus increase the maximum kernel size
- Use verified boot only on a new board - am335x_boneblack_vboot

Changes in v2:
- Add new patch to ensure the hash section is inside the image for am335x
- Add new patch to check u-boot.bin size against symbol table
- Update to cover all omap devices
- Adjust for kbuild changes
- Fix line over 80cols
- Move device tree files into arch/arm/dts

Simon Glass (14):
  ti: am335x: Fix the U-Boot binary output
  cm_t335: Fix the U-Boot binary output
  mx31ads: Fix the U-Boot binary output
  Check that u-boot.bin size looks correct
  am33xx/omap: Allow cache enable for all Sitara/OMAP
  hash: Export the function to show a hash
  fdt: Add DEV_TREE_BIN option to specify a device tree binary file
  fdt: Update functions which write to an FDT to return -ENOSPC
  Improve error handling in fit_common
  mkimage: Automatically make space in FDT when full
  arm: ti: Increase malloc size to 16MB for armv7 boards
  am33xx/omap: Enable CONFIG_OF_CONTROL
  am33xx/omap: Enable FIT support
  am33xx/omap: Add a new board to enable verified boot

 Makefile   |  16 +-
 arch/arm/cpu/armv7/am33xx/board.c  |   8 -
 arch/arm/cpu/armv7/omap-common/Makefile|   4 +
 arch/arm/cpu/armv7/omap-common/hwinit-common.c |  42 --
 arch/arm/cpu/armv7/omap-common/omap-cache.c|  56 +++
 arch/arm/cpu/armv7/omap3/board.c   |   8 -
 arch/arm/dts/Makefile  |   1 +
 arch/arm/dts/am335x-bone-common.dtsi   | 262 ++
 arch/arm/dts/am335x-boneblack.dts  |  17 +
 arch/arm/dts/am33xx.dtsi   | 649 +
 arch/arm/dts/dt-bindings/gpio/gpio.h   |  15 +
 arch/arm/dts/dt-bindings/pinctrl/am33xx.h  |  42 ++
 arch/arm/dts/dt-bindings/pinctrl/omap.h|  55 +++
 arch/arm/dts/tps65217.dtsi |  56 +++
 board/compulab/cm_t335/u-boot.lds  |   4 +-
 board/freescale/mx31ads/u-boot.lds |   4 +-
 board/ti/am335x/u-boot.lds |   3 +-
 boards.cfg |   1 +
 common/hash.c  |   7 +-
 common/image-fit.c |   4 +-
 doc/README.fdt-control |  16 +-
 dts/Makefile   |   4 +
 include/configs/am335x_evm.h   |  15 +
 include/configs/ti_armv7_common.h  |   2 +-
 include/hash.h |  15 +
 include/rsa.h  |   3 +-
 lib/rsa/rsa-sign.c |  28 +-
 tools/fit_check_sign.c |   4 +-
 tools/fit_common.c |  49 +-
 tools/fit_common.h |  15 +-
 tools/fit_image.c  | 112 +++--
 tools/fit_info.c   |   2 +-
 tools/image-host.c |  26 +-
 33 files changed, 1390 insertions(+), 155 deletions(-)
 create mode 100644 arch/arm/cpu/armv7/omap-common/omap-cache.c
 create mode 100644 arch/arm/dts/am335x-bone-common.dtsi
 create mode 100644 arch/arm/dts/am335x-boneblack.dts
 create mode 100644 arch/arm/dts/am33xx.dtsi
 create mode 100644 arch/arm/dts/dt-bindings/gpio/gpio.h
 create mode 100644 arch/arm/dts/dt-bindings/pinctrl/am33xx.h
 create mode 100644 arch/arm/dts/dt-bindings/pinctrl/omap.h
 create mode 100644 arch/arm/dts/tps65217.dtsi

-- 
1.9.1.423.g4596e3a

___
U-Boot mailing 

[U-Boot] [PATCH v3 01/14] ti: am335x: Fix the U-Boot binary output

2014-06-02 Thread Simon Glass
This should include the hash so that image_binary_size is really at the
end of the image, and not some 300 bytes earlier.

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

Changes in v3: None
Changes in v2:
- Add new patch to ensure the hash section is inside the image for am335x

 board/ti/am335x/u-boot.lds | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/board/ti/am335x/u-boot.lds b/board/ti/am335x/u-boot.lds
index 2c5a0f8..78f294a 100644
--- a/board/ti/am335x/u-boot.lds
+++ b/board/ti/am335x/u-boot.lds
@@ -78,6 +78,8 @@ SECTIONS
*(.__rel_dyn_end)
}
 
+   .hash : { *(.hash*) }
+
.end :
{
*(.__end)
@@ -118,7 +120,6 @@ SECTIONS
.dynbss : { *(.dynbss) }
.dynstr : { *(.dynstr*) }
.dynamic : { *(.dynamic*) }
-   .hash : { *(.hash*) }
.gnu.hash : { *(.gnu.hash) }
.plt : { *(.plt*) }
.interp : { *(.interp*) }
-- 
1.9.1.423.g4596e3a

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


[U-Boot] [PATCH v3 04/14] Check that u-boot.bin size looks correct

2014-06-02 Thread Simon Glass
Check that the image size matches the size we get from u-boot.bin. If it
doesn't, that generally means that some extra sections are being added to
u-boot.bin, meaning that it is not possible to access data appended to
the U-Boot binary. This is used for device tree, so needs to work.

This problem was introduced by commit b02bfc4. By adding a test we can
prevent a reccurence.

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

Changes in v3: None
Changes in v2:
- Add new patch to check u-boot.bin size against symbol table

 Makefile | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 1df3f70..ece622f 100644
--- a/Makefile
+++ b/Makefile
@@ -740,7 +740,7 @@ DO_STATIC_RELA =
 endif
 
 # Always append ALL so that arch config.mk's can add custom ones
-ALL-y += u-boot.srec u-boot.bin System.map
+ALL-y += u-boot.srec u-boot.bin System.map binary_size_check
 
 ALL-$(CONFIG_NAND_U_BOOT) += u-boot-nand.bin
 ALL-$(CONFIG_ONENAND_U_BOOT) += u-boot-onenand.bin
@@ -820,6 +820,18 @@ u-boot.hex u-boot.srec: u-boot FORCE
 
 OBJCOPYFLAGS_u-boot.bin := -O binary
 
+binary_size_check: u-boot.bin System.map FORCE
+   @file_size=`stat -c %s u-boot.bin` ; \
+   map_size=$(shell cat System.map | \
+   awk '/_image_copy_start/ {start = $$1} /_image_binary_end/ {end 
= $$1} END {if (start !=   end != ) print strtonum(0x end) - 
strtonum(0x start)}'); \
+   if [  != $$map_size ]; then \
+   if test $$map_size -ne $$file_size; then \
+   echo System.map shows a binary size of $$map_size 2 
; \
+   echo   but u-boot.bin shows $$file_size 2 ; \
+   exit 1; \
+   fi \
+   fi
+
 u-boot.bin: u-boot FORCE
$(call if_changed,objcopy)
$(call DO_STATIC_RELA,$,$@,$(CONFIG_SYS_TEXT_BASE))
-- 
1.9.1.423.g4596e3a

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


[U-Boot] [PATCH v3 13/14] am33xx/omap: Enable FIT support

2014-06-02 Thread Simon Glass
Enable booting a FIT containing a kernel/device tree.

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

Changes in v3:
- Also enable LZO and timestamps, plus increase the maximum kernel size

Changes in v2: None

 include/configs/am335x_evm.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
index 11e7771..edc5841 100644
--- a/include/configs/am335x_evm.h
+++ b/include/configs/am335x_evm.h
@@ -19,11 +19,16 @@
 #include configs/ti_am335x_common.h
 
 #ifndef CONFIG_SPL_BUILD
+# define CONFIG_FIT
+# define CONFIG_TIMESTAMP
+# define CONFIG_LZO
 # define CONFIG_OF_CONTROL
 # define CONFIG_OF_SEPARATE
 # define CONFIG_DEFAULT_DEVICE_TREE am335x-boneblack
 #endif
 
+#define CONFIG_SYS_BOOTM_LEN   (16  20)
+
 #define MACH_TYPE_TIAM335EVM   3589/* Until the next sync */
 #define CONFIG_MACH_TYPE   MACH_TYPE_TIAM335EVM
 #define CONFIG_BOARD_LATE_INIT
-- 
1.9.1.423.g4596e3a

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


[U-Boot] [PATCH v3 07/14] fdt: Add DEV_TREE_BIN option to specify a device tree binary file

2014-06-02 Thread Simon Glass
In some cases, an externally-built device tree binary is required to be
attached to U-Boot. An example is when using image signing, since in that
case the .dtb file must include the public keys.

Add a DEV_TREE_BIN option to the Makefile, and update the documentation.

Usage is something like:

make DEV_TREE_BIN=boot/am335x-boneblack-pubkey.dtb

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

Changes in v3: None
Changes in v2:
- Adjust for kbuild changes

 Makefile   |  2 +-
 doc/README.fdt-control | 16 ++--
 dts/Makefile   |  4 
 3 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/Makefile b/Makefile
index ece622f..92819bf 100644
--- a/Makefile
+++ b/Makefile
@@ -867,7 +867,7 @@ MKIMAGEFLAGS_u-boot.kwb = -n 
$(srctree)/$(CONFIG_SYS_KWD_CONFIG:%=%) \
 MKIMAGEFLAGS_u-boot.pbl = -n $(srctree)/$(CONFIG_SYS_FSL_PBL_RCW:%=%) \
-R $(srctree)/$(CONFIG_SYS_FSL_PBL_PBI:%=%) -T pblimage
 
-u-boot.img u-boot.kwb u-boot.pbl: u-boot.bin FORCE
+u-boot.img u-boot.kwb u-boot.pbl: u-boot$(if $(CONFIG_OF_SEPARATE),-dtb,).bin 
FORCE
$(call if_changed,mkimage)
 
 MKIMAGEFLAGS_u-boot-dtb.img = $(MKIMAGEFLAGS_u-boot.img)
diff --git a/doc/README.fdt-control b/doc/README.fdt-control
index 86bae68..8a4aa7a 100644
--- a/doc/README.fdt-control
+++ b/doc/README.fdt-control
@@ -122,7 +122,8 @@ This should include your CPU or SOC's device tree file, 
placed in
 arch/arch/dts, and then make any adjustments required.
 
 If CONFIG_OF_EMBED is defined, then it will be picked up and built into
-the U-Boot image (including u-boot.bin).
+the U-Boot image (including u-boot.bin). This is suitable for debugging
+and development only and is not recommended for production devices.
 
 If CONFIG_OF_SEPARATE is defined, then it will be built and placed in
 a u-boot.dtb file alongside u-boot.bin. A common approach is then to
@@ -130,7 +131,10 @@ join the two:
 
cat u-boot.bin u-boot.dtb image.bin
 
-and then flash image.bin onto your board.
+and then flash image.bin onto your board. Note that U-Boot creates
+u-boot-dtb.bin which does the above step for you also. If you are using
+CONFIG_SPL_FRAMEWORK, then u-boot.img will be built to include the device
+tree binary.
 
 If CONFIG_OF_HOSTFILE is defined, then it will be read from a file on
 startup. This is only useful for sandbox. Use the -d flag to U-Boot to
@@ -138,6 +142,14 @@ specify the file to read.
 
 You cannot use more than one of these options at the same time.
 
+To use a device tree file that you have compiled yourself, pass
+DEV_TREE_BIN=filename to 'make', as in:
+
+   make DEV_TREE_BIN=boot/am335x-boneblack-pubkey.dtb
+
+Then U-Boot will copy that file to u-boot.dtb, put it in the .img file
+if used, and u-boot-dtb.bin.
+
 If you wish to put the fdt at a different address in memory, you can
 define the fdtcontroladdr environment variable. This is the hex
 address of the fdt binary blob, and will override either of the options.
diff --git a/dts/Makefile b/dts/Makefile
index e59550c..8bb5212 100644
--- a/dts/Makefile
+++ b/dts/Makefile
@@ -12,7 +12,11 @@ ifeq ($(DEVICE_TREE),)
 DEVICE_TREE := unset
 endif
 
+ifneq ($(DEV_TREE_BIN),)
+DTB := $(DEV_TREE_BIN)
+else
 DTB := arch/$(ARCH)/dts/$(DEVICE_TREE).dtb
+endif
 
 quiet_cmd_copy = COPY$@
   cmd_copy = cp $ $@
-- 
1.9.1.423.g4596e3a

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


[U-Boot] [PATCH v3 05/14] am33xx/omap: Allow cache enable for all Sitara/OMAP

2014-06-02 Thread Simon Glass
Enable the cache for all devices, unless CONFIG_SYS_DCACHE_OFF is defined.
This speeds up the Beaglebone Black boot considerable.

(Tested only on Beaglebone Black with SD card boot)

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

Changes in v3: None
Changes in v2:
- Update to cover all omap devices

 arch/arm/cpu/armv7/am33xx/board.c  |  8 
 arch/arm/cpu/armv7/omap-common/Makefile|  4 ++
 arch/arm/cpu/armv7/omap-common/hwinit-common.c | 42 ---
 arch/arm/cpu/armv7/omap-common/omap-cache.c| 56 ++
 arch/arm/cpu/armv7/omap3/board.c   |  8 
 5 files changed, 60 insertions(+), 58 deletions(-)
 create mode 100644 arch/arm/cpu/armv7/omap-common/omap-cache.c

diff --git a/arch/arm/cpu/armv7/am33xx/board.c 
b/arch/arm/cpu/armv7/am33xx/board.c
index 28c16f8..9ae8c34 100644
--- a/arch/arm/cpu/armv7/am33xx/board.c
+++ b/arch/arm/cpu/armv7/am33xx/board.c
@@ -241,11 +241,3 @@ void s_init(void)
sdram_init();
 }
 #endif
-
-#ifndef CONFIG_SYS_DCACHE_OFF
-void enable_caches(void)
-{
-   /* Enable D-cache. I-cache is already enabled in start.S */
-   dcache_enable();
-}
-#endif /* !CONFIG_SYS_DCACHE_OFF */
diff --git a/arch/arm/cpu/armv7/omap-common/Makefile 
b/arch/arm/cpu/armv7/omap-common/Makefile
index 5f5132f..7695e16 100644
--- a/arch/arm/cpu/armv7/omap-common/Makefile
+++ b/arch/arm/cpu/armv7/omap-common/Makefile
@@ -22,6 +22,10 @@ obj-y+= pipe3-phy.o
 obj-$(CONFIG_SCSI_AHCI_PLAT) += sata.o
 endif
 
+ifeq ($(CONFIG_SYS_DCACHE_OFF),)
+obj-y  += omap-cache.o
+endif
+
 ifeq ($(CONFIG_OMAP34XX),)
 obj-y  += boot-common.o
 obj-y  += lowlevel_init.o
diff --git a/arch/arm/cpu/armv7/omap-common/hwinit-common.c 
b/arch/arm/cpu/armv7/omap-common/hwinit-common.c
index ba97d9e..5f50a19 100644
--- a/arch/arm/cpu/armv7/omap-common/hwinit-common.c
+++ b/arch/arm/cpu/armv7/omap-common/hwinit-common.c
@@ -18,13 +18,8 @@
 #include asm/emif.h
 #include asm/omap_common.h
 #include linux/compiler.h
-#include asm/cache.h
 #include asm/system.h
 
-#define ARMV7_DCACHE_WRITEBACK  0xe
-#defineARMV7_DOMAIN_CLIENT 1
-#define ARMV7_DOMAIN_MASK  (0x3  0)
-
 DECLARE_GLOBAL_DATA_PTR;
 
 void do_set_mux(u32 base, struct pad_conf_entry const *array, int size)
@@ -263,40 +258,3 @@ int print_cpuinfo(void)
return 0;
 }
 #endif
-
-#ifndef CONFIG_SYS_DCACHE_OFF
-void enable_caches(void)
-{
-   /* Enable D-cache. I-cache is already enabled in start.S */
-   dcache_enable();
-}
-
-void dram_bank_mmu_setup(int bank)
-{
-   bd_t *bd = gd-bd;
-   int i;
-
-   u32 start = bd-bi_dram[bank].start  20;
-   u32 size = bd-bi_dram[bank].size  20;
-   u32 end = start + size;
-
-   debug(%s: bank: %d\n, __func__, bank);
-   for (i = start; i  end; i++)
-   set_section_dcache(i, ARMV7_DCACHE_WRITEBACK);
-
-}
-
-void arm_init_domains(void)
-{
-   u32 reg;
-
-   reg = get_dacr();
-   /*
-   * Set DOMAIN to client access so that all permissions
-   * set in pagetables are validated by the mmu.
-   */
-   reg = ~ARMV7_DOMAIN_MASK;
-   reg |= ARMV7_DOMAIN_CLIENT;
-   set_dacr(reg);
-}
-#endif
diff --git a/arch/arm/cpu/armv7/omap-common/omap-cache.c 
b/arch/arm/cpu/armv7/omap-common/omap-cache.c
new file mode 100644
index 000..579bebf
--- /dev/null
+++ b/arch/arm/cpu/armv7/omap-common/omap-cache.c
@@ -0,0 +1,56 @@
+/*
+ *
+ * Common functions for OMAP4/5 based boards
+ *
+ * (C) Copyright 2010
+ * Texas Instruments, www.ti.com
+ *
+ * Author :
+ * Aneesh Vane...@ti.com
+ * Steve Sakoman   st...@sakoman.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include asm/cache.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define ARMV7_DCACHE_WRITEBACK  0xe
+#define ARMV7_DOMAIN_CLIENT1
+#define ARMV7_DOMAIN_MASK  (0x3  0)
+
+void enable_caches(void)
+{
+   /* Enable D-cache. I-cache is already enabled in start.S */
+   dcache_enable();
+}
+
+void dram_bank_mmu_setup(int bank)
+{
+   bd_t *bd = gd-bd;
+   int i;
+
+   u32 start = bd-bi_dram[bank].start  20;
+   u32 size = bd-bi_dram[bank].size  20;
+   u32 end = start + size;
+
+   debug(%s: bank: %d\n, __func__, bank);
+   for (i = start; i  end; i++)
+   set_section_dcache(i, ARMV7_DCACHE_WRITEBACK);
+}
+
+void arm_init_domains(void)
+{
+   u32 reg;
+
+   reg = get_dacr();
+   /*
+   * Set DOMAIN to client access so that all permissions
+   * set in pagetables are validated by the mmu.
+   */
+   reg = ~ARMV7_DOMAIN_MASK;
+   reg |= ARMV7_DOMAIN_CLIENT;
+   set_dacr(reg);
+}
diff --git a/arch/arm/cpu/armv7/omap3/board.c b/arch/arm/cpu/armv7/omap3/board.c
index 9bb1a1c..e252e7f 100644
--- a/arch/arm/cpu/armv7/omap3/board.c
+++ b/arch/arm/cpu/armv7/omap3/board.c
@@ -478,11 +478,3 @@ void omap3_outer_cache_disable(void)
omap3_update_aux_cr(0, 0x2);
 }
 #endif /* 

[U-Boot] [PATCH v3 06/14] hash: Export the function to show a hash

2014-06-02 Thread Simon Glass
This function is useful for displaying a hash value, so export it.

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

Changes in v3:
- Rebase to master and update commit message

Changes in v2: None

 common/hash.c  |  7 +++
 include/hash.h | 15 +++
 2 files changed, 18 insertions(+), 4 deletions(-)

diff --git a/common/hash.c b/common/hash.c
index 7627b84..41a4a28 100644
--- a/common/hash.c
+++ b/common/hash.c
@@ -311,8 +311,7 @@ int hash_lookup_algo(const char *algo_name, struct 
hash_algo **algop)
return -EPROTONOSUPPORT;
 }
 
-static void show_hash(struct hash_algo *algo, ulong addr, ulong len,
- u8 *output)
+void hash_show(struct hash_algo *algo, ulong addr, ulong len, u8 *output)
 {
int i;
 
@@ -392,7 +391,7 @@ int hash_command(const char *algo_name, int flags, 
cmd_tbl_t *cmdtp, int flag,
if (memcmp(output, vsum, algo-digest_size) != 0) {
int i;
 
-   show_hash(algo, addr, len, output);
+   hash_show(algo, addr, len, output);
printf( != );
for (i = 0; i  algo-digest_size; i++)
printf(%02x, vsum[i]);
@@ -400,7 +399,7 @@ int hash_command(const char *algo_name, int flags, 
cmd_tbl_t *cmdtp, int flag,
return 1;
}
} else {
-   show_hash(algo, addr, len, output);
+   hash_show(algo, addr, len, output);
printf(\n);
 
if (argc) {
diff --git a/include/hash.h b/include/hash.h
index dc21678..c6de20d 100644
--- a/include/hash.h
+++ b/include/hash.h
@@ -125,4 +125,19 @@ int hash_block(const char *algo_name, const void *data, 
unsigned int len,
  * @return 0 if ok, -EPROTONOSUPPORT for an unknown algorithm.
  */
 int hash_lookup_algo(const char *algo_name, struct hash_algo **algop);
+
+/**
+ * hash_show() - Print out a hash algorithm and value
+ *
+ * You will get a message like this (without a newline at the end):
+ *
+ * sha1 for 9eb3337c ... 9eb3338f == 
7942ef1df479fd3130f716eb9613d107dab7e257
+ *
+ * @algo:  Algorithm used for hash
+ * @addr:  Address of data that was hashed
+ * @len:   Length of data that was hashed
+ * @output:Hash value to display
+ */
+void hash_show(struct hash_algo *algo, ulong addr, ulong len, u8 *output);
+
 #endif
-- 
1.9.1.423.g4596e3a

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


[U-Boot] [PATCH v3 10/14] mkimage: Automatically make space in FDT when full

2014-06-02 Thread Simon Glass
When adding hashes or signatures, the target FDT may be full. Detect this
and automatically try again after making 1KB of space.

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

Changes in v3:
- Rebase to master

Changes in v2: None

 tools/fit_check_sign.c |   4 +-
 tools/fit_common.c |  25 ++-
 tools/fit_common.h |   5 ++-
 tools/fit_image.c  | 112 ++---
 tools/fit_info.c   |   2 +-
 tools/image-host.c |  26 
 6 files changed, 114 insertions(+), 60 deletions(-)

diff --git a/tools/fit_check_sign.c b/tools/fit_check_sign.c
index e6df610..c2aefae 100644
--- a/tools/fit_check_sign.c
+++ b/tools/fit_check_sign.c
@@ -61,10 +61,10 @@ int main(int argc, char **argv)
break;
}
 
-   ffd = mmap_fdt(cmdname, fdtfile, fit_blob, fsbuf, false);
+   ffd = mmap_fdt(cmdname, fdtfile, 0, fit_blob, fsbuf, false);
if (ffd  0)
return EXIT_FAILURE;
-   kfd = mmap_fdt(cmdname, keyfile, key_blob, ksbuf, false);
+   kfd = mmap_fdt(cmdname, keyfile, 0, key_blob, ksbuf, false);
if (ffd  0)
return EXIT_FAILURE;
 
diff --git a/tools/fit_common.c b/tools/fit_common.c
index 286f357..81ba698 100644
--- a/tools/fit_common.c
+++ b/tools/fit_common.c
@@ -38,8 +38,8 @@ int fit_check_image_types(uint8_t type)
return EXIT_FAILURE;
 }
 
-int mmap_fdt(const char *cmdname, const char *fname, void **blobp,
-struct stat *sbuf, bool delete_on_error)
+int mmap_fdt(const char *cmdname, const char *fname, size_t size_inc,
+void **blobp, struct stat *sbuf, bool delete_on_error)
 {
void *ptr;
int fd;
@@ -59,6 +59,15 @@ int mmap_fdt(const char *cmdname, const char *fname, void 
**blobp,
goto err;
}
 
+   if (size_inc) {
+   sbuf-st_size += size_inc;
+   if (ftruncate(fd, sbuf-st_size)) {
+   fprintf(stderr, %s: Can't expand %s: %s\n,
+   cmdname, fname, strerror(errno));
+   goto err;
+   }
+   }
+
errno = 0;
ptr = mmap(0, sbuf-st_size, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
if ((ptr == MAP_FAILED) || (errno != 0)) {
@@ -73,6 +82,18 @@ int mmap_fdt(const char *cmdname, const char *fname, void 
**blobp,
goto err;
}
 
+   /* expand if needed */
+   if (size_inc) {
+   int ret;
+
+   ret = fdt_open_into(ptr, ptr, sbuf-st_size);
+   if (ret) {
+   fprintf(stderr, %s: Cannot expand FDT: %s\n,
+   cmdname, fdt_strerror(ret));
+   goto err;
+   }
+   }
+
*blobp = ptr;
return fd;
 
diff --git a/tools/fit_common.h b/tools/fit_common.h
index adcee6d..b8d8438 100644
--- a/tools/fit_common.h
+++ b/tools/fit_common.h
@@ -21,12 +21,13 @@ int fit_check_image_types(uint8_t type);
  *
  * @cmdname:   Tool name (for displaying with error messages)
  * @fname: Filename containing FDT
+ * @size_inc:  Amount to increase size by (0 = leave it alone)
  * @blobp: Returns pointer to FDT blob
  * @sbuf:  File status information is stored here
  * @delete_on_error:   true to delete the file if we get an error
  * @return 0 if OK, -1 on error.
  */
-int mmap_fdt(const char *cmdname, const char *fname, void **blobp,
-struct stat *sbuf, bool delete_on_error);
+int mmap_fdt(const char *cmdname, const char *fname, size_t size_inc,
+void **blobp, struct stat *sbuf, bool delete_on_error);
 
 #endif /* _FIT_COMMON_H_ */
diff --git a/tools/fit_image.c b/tools/fit_image.c
index 484..3ececf9 100644
--- a/tools/fit_image.c
+++ b/tools/fit_image.c
@@ -22,6 +22,54 @@
 
 static image_header_t header;
 
+static int fit_add_file_data(struct image_tool_params *params, size_t size_inc,
+const char *tmpfile)
+{
+   int tfd, destfd = 0;
+   void *dest_blob = NULL;
+   off_t destfd_size = 0;
+   struct stat sbuf;
+   void *ptr;
+   int ret = 0;
+
+   tfd = mmap_fdt(params-cmdname, tmpfile, size_inc, ptr, sbuf, true);
+   if (tfd  0)
+   return -EIO;
+
+   if (params-keydest) {
+   struct stat dest_sbuf;
+
+   destfd = mmap_fdt(params-cmdname, params-keydest, size_inc,
+ dest_blob, dest_sbuf, false);
+   if (destfd  0) {
+   ret = -EIO;
+   goto err_keydest;
+   }
+   destfd_size = dest_sbuf.st_size;
+   }
+
+   /* for first image creation, add a timestamp at offset 0 i.e., root  */
+   if (params-datafile)
+   ret = fit_set_timestamp(ptr, 0, sbuf.st_mtime);
+
+   if (!ret) {
+   ret = fit_add_verification_data(params-keydir, dest_blob, ptr,
+   

[U-Boot] [PATCH v3 03/14] mx31ads: Fix the U-Boot binary output

2014-06-02 Thread Simon Glass
Correct the binary output so that image_binary_size is really at the
end of the image.

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

Changes in v3:
- Add new patch to ensure the hash section is inside the image for mx31ads

Changes in v2: None

 board/freescale/mx31ads/u-boot.lds | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/board/freescale/mx31ads/u-boot.lds 
b/board/freescale/mx31ads/u-boot.lds
index 61b83bf..8a4a8a2 100644
--- a/board/freescale/mx31ads/u-boot.lds
+++ b/board/freescale/mx31ads/u-boot.lds
@@ -70,6 +70,8 @@ SECTIONS
*(.__rel_dyn_end)
}
 
+   .hash : { *(.hash*) }
+
.end :
{
*(.__end)
@@ -100,7 +102,7 @@ SECTIONS
.dynbss : { *(.dynbss) }
.dynstr : { *(.dynstr*) }
.dynamic : { *(.dynamic*) }
-   .hash : { *(.hash*) }
+   .gnu.hash : { *(.gnu.hash) }
.plt : { *(.plt*) }
.interp : { *(.interp*) }
.gnu : { *(.gnu*) }
-- 
1.9.1.423.g4596e3a

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


[U-Boot] [PATCH v3 08/14] fdt: Update functions which write to an FDT to return -ENOSPC

2014-06-02 Thread Simon Glass
When writing values into an FDT it is possible that there will be
insufficient space. If the caller gets a useful error then it can
potentially deal with the situation.

Adjust these functions to return -ENOSPC when the FDT is full.

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

Changes in v3:
- Fix typo in commit message

Changes in v2:
- Fix line over 80cols

 common/image-fit.c |  4 ++--
 include/rsa.h  |  3 ++-
 lib/rsa/rsa-sign.c | 28 +++-
 3 files changed, 23 insertions(+), 12 deletions(-)

diff --git a/common/image-fit.c b/common/image-fit.c
index 77f32bc..732505a 100644
--- a/common/image-fit.c
+++ b/common/image-fit.c
@@ -833,7 +833,7 @@ static int fit_image_hash_get_ignore(const void *fit, int 
noffset, int *ignore)
  *
  * returns:
  * 0, on success
- * -1, on property read failure
+ * -ENOSPC if no space in device tree, -1 for other error
  */
 int fit_set_timestamp(void *fit, int noffset, time_t timestamp)
 {
@@ -847,7 +847,7 @@ int fit_set_timestamp(void *fit, int noffset, time_t 
timestamp)
printf(Can't set '%s' property for '%s' node (%s)\n,
   FIT_TIMESTAMP_PROP, fit_get_name(fit, noffset, NULL),
   fdt_strerror(ret));
-   return -1;
+   return ret == -FDT_ERR_NOSPACE ? -ENOSPC : -1;
}
 
return 0;
diff --git a/include/rsa.h b/include/rsa.h
index a5680ab..325751a 100644
--- a/include/rsa.h
+++ b/include/rsa.h
@@ -60,7 +60,8 @@ int rsa_sign(struct image_sign_info *info,
  *
  * @info:  Specifies key and FIT information
  * @keydest:   Destination FDT blob for public key data
- * @return: 0, on success, -ve on error
+ * @return: 0, on success, -ENOSPC if the keydest FDT blob ran out of space,
+   other -ve value on error
 */
 int rsa_add_verify_data(struct image_sign_info *info, void *keydest);
 #else
diff --git a/lib/rsa/rsa-sign.c b/lib/rsa/rsa-sign.c
index ca8c120..48f3197 100644
--- a/lib/rsa/rsa-sign.c
+++ b/lib/rsa/rsa-sign.c
@@ -429,20 +429,30 @@ int rsa_add_verify_data(struct image_sign_info *info, 
void *keydest)
 
ret = fdt_setprop_string(keydest, node, key-name-hint,
 info-keyname);
-   ret |= fdt_setprop_u32(keydest, node, rsa,num-bits, bits);
-   ret |= fdt_setprop_u32(keydest, node, rsa,n0-inverse, n0_inv);
-   ret |= fdt_add_bignum(keydest, node, rsa,modulus, modulus, bits);
-   ret |= fdt_add_bignum(keydest, node, rsa,r-squared, r_squared, bits);
-   ret |= fdt_setprop_string(keydest, node, FIT_ALGO_PROP,
- info-algo-name);
+   if (!ret)
+   ret = fdt_setprop_u32(keydest, node, rsa,num-bits, bits);
+   if (!ret)
+   ret = fdt_setprop_u32(keydest, node, rsa,n0-inverse, n0_inv);
+   if (!ret) {
+   ret = fdt_add_bignum(keydest, node, rsa,modulus, modulus,
+bits);
+   }
+   if (!ret) {
+   ret = fdt_add_bignum(keydest, node, rsa,r-squared, r_squared,
+bits);
+   }
+   if (!ret) {
+   ret = fdt_setprop_string(keydest, node, FIT_ALGO_PROP,
+info-algo-name);
+   }
if (info-require_keys) {
-   fdt_setprop_string(keydest, node, required,
-  info-require_keys);
+   ret = fdt_setprop_string(keydest, node, required,
+info-require_keys);
}
BN_free(modulus);
BN_free(r_squared);
if (ret)
-   return -EIO;
+   return ret == FDT_ERR_NOSPACE ? -ENOSPC : -EIO;
 
return 0;
 }
-- 
1.9.1.423.g4596e3a

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


[U-Boot] [PATCH v3 09/14] Improve error handling in fit_common

2014-06-02 Thread Simon Glass
Make the error handling common, and make sure the file is always closed
on error. Rename the parameter to be more description and add comments.

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

Changes in v3:
- Add new patch to improve error handling in fit_common

Changes in v2: None

 tools/fit_check_sign.c |  4 ++--
 tools/fit_common.c | 28 ++--
 tools/fit_common.h | 14 --
 tools/fit_info.c   |  2 +-
 4 files changed, 29 insertions(+), 19 deletions(-)

diff --git a/tools/fit_check_sign.c b/tools/fit_check_sign.c
index d6d9340..e6df610 100644
--- a/tools/fit_check_sign.c
+++ b/tools/fit_check_sign.c
@@ -61,10 +61,10 @@ int main(int argc, char **argv)
break;
}
 
-   ffd = mmap_fdt(cmdname, fdtfile, fit_blob, fsbuf, 0);
+   ffd = mmap_fdt(cmdname, fdtfile, fit_blob, fsbuf, false);
if (ffd  0)
return EXIT_FAILURE;
-   kfd = mmap_fdt(cmdname, keyfile, key_blob, ksbuf, 0);
+   kfd = mmap_fdt(cmdname, keyfile, key_blob, ksbuf, false);
if (ffd  0)
return EXIT_FAILURE;
 
diff --git a/tools/fit_common.c b/tools/fit_common.c
index ee1767b..286f357 100644
--- a/tools/fit_common.c
+++ b/tools/fit_common.c
@@ -38,8 +38,8 @@ int fit_check_image_types(uint8_t type)
return EXIT_FAILURE;
 }
 
-int mmap_fdt(char *cmdname, const char *fname, void **blobp,
-   struct stat *sbuf, int useunlink)
+int mmap_fdt(const char *cmdname, const char *fname, void **blobp,
+struct stat *sbuf, bool delete_on_error)
 {
void *ptr;
int fd;
@@ -50,17 +50,13 @@ int mmap_fdt(char *cmdname, const char *fname, void **blobp,
if (fd  0) {
fprintf(stderr, %s: Can't open %s: %s\n,
cmdname, fname, strerror(errno));
-   if (useunlink)
-   unlink(fname);
-   return -1;
+   goto err;
}
 
if (fstat(fd, sbuf)  0) {
fprintf(stderr, %s: Can't stat %s: %s\n,
cmdname, fname, strerror(errno));
-   if (useunlink)
-   unlink(fname);
-   return -1;
+   goto err;
}
 
errno = 0;
@@ -68,19 +64,23 @@ int mmap_fdt(char *cmdname, const char *fname, void **blobp,
if ((ptr == MAP_FAILED) || (errno != 0)) {
fprintf(stderr, %s: Can't read %s: %s\n,
cmdname, fname, strerror(errno));
-   if (useunlink)
-   unlink(fname);
-   return -1;
+   goto err;
}
 
/* check if ptr has a valid blob */
if (fdt_check_header(ptr)) {
fprintf(stderr, %s: Invalid FIT blob\n, cmdname);
-   if (useunlink)
-   unlink(fname);
-   return -1;
+   goto err;
}
 
*blobp = ptr;
return fd;
+
+err:
+   if (fd = 0)
+   close(fd);
+   if (delete_on_error)
+   unlink(fname);
+
+   return -1;
 }
diff --git a/tools/fit_common.h b/tools/fit_common.h
index adf4404..adcee6d 100644
--- a/tools/fit_common.h
+++ b/tools/fit_common.h
@@ -16,7 +16,17 @@ int fit_verify_header(unsigned char *ptr, int image_size,
 
 int fit_check_image_types(uint8_t type);
 
-int mmap_fdt(char *cmdname, const char *fname, void **blobp,
-   struct stat *sbuf, int useunlink);
+/**
+ * Map an FDT into memory, optionally increasing its size
+ *
+ * @cmdname:   Tool name (for displaying with error messages)
+ * @fname: Filename containing FDT
+ * @blobp: Returns pointer to FDT blob
+ * @sbuf:  File status information is stored here
+ * @delete_on_error:   true to delete the file if we get an error
+ * @return 0 if OK, -1 on error.
+ */
+int mmap_fdt(const char *cmdname, const char *fname, void **blobp,
+struct stat *sbuf, bool delete_on_error);
 
 #endif /* _FIT_COMMON_H_ */
diff --git a/tools/fit_info.c b/tools/fit_info.c
index 50f3c8e..9442ff1 100644
--- a/tools/fit_info.c
+++ b/tools/fit_info.c
@@ -68,7 +68,7 @@ int main(int argc, char **argv)
break;
}
 
-   ffd = mmap_fdt(cmdname, fdtfile, fit_blob, fsbuf, 0);
+   ffd = mmap_fdt(cmdname, fdtfile, fit_blob, fsbuf, false);
 
if (ffd  0) {
printf(Could not open %s\n, fdtfile);
-- 
1.9.1.423.g4596e3a

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


[U-Boot] [PATCH v3 02/14] cm_t335: Fix the U-Boot binary output

2014-06-02 Thread Simon Glass
Correct the binary output so that image_binary_size is really at the
end of the image.

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

Changes in v3:
- Add new patch to ensure the hash section is inside the image for cm_t335

Changes in v2: None

 board/compulab/cm_t335/u-boot.lds | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/board/compulab/cm_t335/u-boot.lds 
b/board/compulab/cm_t335/u-boot.lds
index c8ab716..6275836 100644
--- a/board/compulab/cm_t335/u-boot.lds
+++ b/board/compulab/cm_t335/u-boot.lds
@@ -62,6 +62,8 @@ SECTIONS
*(.__rel_dyn_end)
}
 
+   .hash : { *(.hash*) }
+
.end :
{
*(.__end)
@@ -99,8 +101,6 @@ SECTIONS
}
 
.dynsym _image_binary_end : { *(.dynsym) }
-   .hash : { *(.hash) }
-   .got.plt : { *(.got.plt) }
.dynbss : { *(.dynbss) }
.dynstr : { *(.dynstr*) }
.dynamic : { *(.dynamic*) }
-- 
1.9.1.423.g4596e3a

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


[U-Boot] [PATCH v3 14/14] am33xx/omap: Add a new board to enable verified boot

2014-06-02 Thread Simon Glass
Enable verified boot functionality for a new am335x_boneblack_vboot target.

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

Changes in v3:
- Use verified boot only on a new board - am335x_boneblack_vboot

Changes in v2: None

 boards.cfg   | 1 +
 include/configs/am335x_evm.h | 4 
 2 files changed, 5 insertions(+)

diff --git a/boards.cfg b/boards.cfg
index b8cfead..f255ba7 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -269,6 +269,7 @@ Active  arm armv7  am33xx  siemens  
   pxm2
 Active  arm armv7  am33xx  siemens rut 
rut   - 

Roger Meier r.me...@siemens.com
 Active  arm armv7  am33xx  silica  pengwyn 
pengwyn   - 

Lothar Felten lothar.fel...@gmail.com
 Active  arm armv7  am33xx  ti  am335x  
am335x_boneblack  
am335x_evm:SERIAL1,CONS_INDEX=1,EMMC_BOOT   
  Tom Rini tr...@ti.com
+Active  arm armv7  am33xx  ti  am335x  
am335x_boneblack_vboot
am335x_evm:SERIAL1,CONS_INDEX=1,EMMC_BOOT,ENABLE_VBOOT  
  Tom Rini tr...@ti.com
 Active  arm armv7  am33xx  ti  am335x  
am335x_evmam335x_evm:SERIAL1,CONS_INDEX=1,NAND  

Tom Rini tr...@ti.com
 Active  arm armv7  am33xx  ti  am335x  
am335x_evm_nor
am335x_evm:SERIAL1,CONS_INDEX=1,NAND,NOR
  Tom Rini tr...@ti.com
 Active  arm armv7  am33xx  ti  am335x  
am335x_evm_norboot
am335x_evm:SERIAL1,CONS_INDEX=1,NOR,NOR_BOOT
  Tom Rini tr...@ti.com
diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
index edc5841..5ae8c46 100644
--- a/include/configs/am335x_evm.h
+++ b/include/configs/am335x_evm.h
@@ -25,6 +25,10 @@
 # define CONFIG_OF_CONTROL
 # define CONFIG_OF_SEPARATE
 # define CONFIG_DEFAULT_DEVICE_TREE am335x-boneblack
+# ifdef CONFIG_ENABLE_VBOOT
+#  define CONFIG_FIT_SIGNATURE
+#  define CONFIG_RSA
+# endif
 #endif
 
 #define CONFIG_SYS_BOOTM_LEN   (16  20)
-- 
1.9.1.423.g4596e3a

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


[U-Boot] [PATCH v3 11/14] arm: ti: Increase malloc size to 16MB for armv7 boards

2014-06-02 Thread Simon Glass
The current size of 1MB is not enough use to use DFU. Increase it for
ARMv7 boards, all of which should have 32MB or more SDRAM.

With this change it is possible to do 'dfu mmc 0' on a Beaglebone Black.

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

Changes in v3: None
Changes in v2: None

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

diff --git a/include/configs/ti_armv7_common.h 
b/include/configs/ti_armv7_common.h
index 4854272..b2896ff 100644
--- a/include/configs/ti_armv7_common.h
+++ b/include/configs/ti_armv7_common.h
@@ -127,7 +127,7 @@
  * we are on so we do not need to rely on the command prompt.  We set a
  * console baudrate of 115200 and use the default baud rate table.
  */
-#define CONFIG_SYS_MALLOC_LEN  (1024  10)
+#define CONFIG_SYS_MALLOC_LEN  (16  20)
 #define CONFIG_SYS_HUSH_PARSER
 #define CONFIG_SYS_PROMPT  U-Boot# 
 #define CONFIG_SYS_CONSOLE_INFO_QUIET
-- 
1.9.1.423.g4596e3a

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


[U-Boot] [PATCH v3 12/14] am33xx/omap: Enable CONFIG_OF_CONTROL

2014-06-02 Thread Simon Glass
Add support for device tree control and add device tree files for the
beaglebone black initially.

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

Changes in v3: None
Changes in v2:
- Move device tree files into arch/arm/dts

 arch/arm/dts/Makefile |   1 +
 arch/arm/dts/am335x-bone-common.dtsi  | 262 
 arch/arm/dts/am335x-boneblack.dts |  17 +
 arch/arm/dts/am33xx.dtsi  | 649 ++
 arch/arm/dts/dt-bindings/gpio/gpio.h  |  15 +
 arch/arm/dts/dt-bindings/pinctrl/am33xx.h |  42 ++
 arch/arm/dts/dt-bindings/pinctrl/omap.h   |  55 +++
 arch/arm/dts/tps65217.dtsi|  56 +++
 include/configs/am335x_evm.h  |   6 +
 9 files changed, 1103 insertions(+)
 create mode 100644 arch/arm/dts/am335x-bone-common.dtsi
 create mode 100644 arch/arm/dts/am335x-boneblack.dts
 create mode 100644 arch/arm/dts/am33xx.dtsi
 create mode 100644 arch/arm/dts/dt-bindings/gpio/gpio.h
 create mode 100644 arch/arm/dts/dt-bindings/pinctrl/am33xx.h
 create mode 100644 arch/arm/dts/dt-bindings/pinctrl/omap.h
 create mode 100644 arch/arm/dts/tps65217.dtsi

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 5554615..61527a2 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -31,6 +31,7 @@ dtb-$(CONFIG_ZYNQ) += zynq-zc702.dtb \
zynq-zc770-xm010.dtb \
zynq-zc770-xm012.dtb \
zynq-zc770-xm013.dtb
+dtb-$(CONFIG_AM33XX) += am335x-boneblack.dtb
 
 targets += $(dtb-y)
 
diff --git a/arch/arm/dts/am335x-bone-common.dtsi 
b/arch/arm/dts/am335x-bone-common.dtsi
new file mode 100644
index 000..2f66ded
--- /dev/null
+++ b/arch/arm/dts/am335x-bone-common.dtsi
@@ -0,0 +1,262 @@
+/*
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/ {
+   model = TI AM335x BeagleBone;
+   compatible = ti,am335x-bone, ti,am33xx;
+
+   cpus {
+   cpu@0 {
+   cpu0-supply = dcdc2_reg;
+   };
+   };
+
+   memory {
+   device_type = memory;
+   reg = 0x8000 0x1000; /* 256 MB */
+   };
+
+   am33xx_pinmux: pinmux@44e10800 {
+   pinctrl-names = default;
+   pinctrl-0 = clkout2_pin;
+
+   user_leds_s0: user_leds_s0 {
+   pinctrl-single,pins = 
+   0x54 (PIN_OUTPUT_PULLDOWN | MUX_MODE7)  /* 
gpmc_a5.gpio1_21 */
+   0x58 (PIN_OUTPUT_PULLUP | MUX_MODE7)/* 
gpmc_a6.gpio1_22 */
+   0x5c (PIN_OUTPUT_PULLDOWN | MUX_MODE7)  /* 
gpmc_a7.gpio1_23 */
+   0x60 (PIN_OUTPUT_PULLUP | MUX_MODE7)/* 
gpmc_a8.gpio1_24 */
+   ;
+   };
+
+   i2c0_pins: pinmux_i2c0_pins {
+   pinctrl-single,pins = 
+   0x188 (PIN_INPUT_PULLUP | MUX_MODE0)/* 
i2c0_sda.i2c0_sda */
+   0x18c (PIN_INPUT_PULLUP | MUX_MODE0)/* 
i2c0_scl.i2c0_scl */
+   ;
+   };
+
+   uart0_pins: pinmux_uart0_pins {
+   pinctrl-single,pins = 
+   0x170 (PIN_INPUT_PULLUP | MUX_MODE0)/* 
uart0_rxd.uart0_rxd */
+   0x174 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* 
uart0_txd.uart0_txd */
+   ;
+   };
+
+   clkout2_pin: pinmux_clkout2_pin {
+   pinctrl-single,pins = 
+   0x1b4 (PIN_OUTPUT_PULLDOWN | MUX_MODE3) /* 
xdma_event_intr1.clkout2 */
+   ;
+   };
+
+   cpsw_default: cpsw_default {
+   pinctrl-single,pins = 
+   /* Slave 1 */
+   0x110 (PIN_INPUT_PULLUP | MUX_MODE0)/* 
mii1_rxerr.mii1_rxerr */
+   0x114 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* 
mii1_txen.mii1_txen */
+   0x118 (PIN_INPUT_PULLUP | MUX_MODE0)/* 
mii1_rxdv.mii1_rxdv */
+   0x11c (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* 
mii1_txd3.mii1_txd3 */
+   0x120 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* 
mii1_txd2.mii1_txd2 */
+   0x124 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* 
mii1_txd1.mii1_txd1 */
+   0x128 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* 
mii1_txd0.mii1_txd0 */
+   0x12c (PIN_INPUT_PULLUP | MUX_MODE0)/* 
mii1_txclk.mii1_txclk */
+   0x130 (PIN_INPUT_PULLUP | MUX_MODE0)/* 
mii1_rxclk.mii1_rxclk */
+   0x134 

[U-Boot] [PATCH 02/11] Reverse the meaning of the fit_config_verify() return code

2014-06-02 Thread Simon Glass
It is more common to have 0 mean OK, and -ve mean error. Change this
function to work the same way to avoid confusion.

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

 common/cmd_fdt.c   | 2 +-
 common/image-fit.c | 2 +-
 common/image-sig.c | 4 ++--
 tools/fit_check_sign.c | 3 +--
 4 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/common/cmd_fdt.c b/common/cmd_fdt.c
index a6744ed..f2ad2a3 100644
--- a/common/cmd_fdt.c
+++ b/common/cmd_fdt.c
@@ -612,7 +612,7 @@ static int do_fdt(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
}
 
ret = fit_config_verify(working_fdt, cfg_noffset);
-   if (ret == 1)
+   if (ret == 0)
return CMD_RET_SUCCESS;
else
return CMD_RET_FAILURE;
diff --git a/common/image-fit.c b/common/image-fit.c
index 732505a..40c7e27 100644
--- a/common/image-fit.c
+++ b/common/image-fit.c
@@ -1534,7 +1534,7 @@ int fit_image_load(bootm_headers_t *images, const char 
*prop_name, ulong addr,
images-fit_uname_cfg = fit_uname_config;
if (IMAGE_ENABLE_VERIFY  images-verify) {
puts(   Verifying Hash Integrity ... );
-   if (!fit_config_verify(fit, cfg_noffset)) {
+   if (fit_config_verify(fit, cfg_noffset)) {
puts(Bad Data Hash\n);
bootstage_error(bootstage_id +
BOOTSTAGE_SUB_HASH);
diff --git a/common/image-sig.c b/common/image-sig.c
index 72284eb..48788f9 100644
--- a/common/image-sig.c
+++ b/common/image-sig.c
@@ -467,6 +467,6 @@ int fit_config_verify_required_sigs(const void *fit, int 
conf_noffset,
 
 int fit_config_verify(const void *fit, int conf_noffset)
 {
-   return !fit_config_verify_required_sigs(fit, conf_noffset,
-   gd_fdt_blob());
+   return fit_config_verify_required_sigs(fit, conf_noffset,
+  gd_fdt_blob());
 }
diff --git a/tools/fit_check_sign.c b/tools/fit_check_sign.c
index e1198bc..768be2f 100644
--- a/tools/fit_check_sign.c
+++ b/tools/fit_check_sign.c
@@ -80,8 +80,7 @@ int main(int argc, char **argv)
 
image_set_host_blob(key_blob);
ret = fit_check_sign(fit_blob, key_blob);
-
-   if (ret)
+   if (!ret)
ret = EXIT_SUCCESS;
else
ret = EXIT_FAILURE;
-- 
1.9.1.423.g4596e3a

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


[U-Boot] [PATCH 08/11] Allow compiling common/bootm.c on with HOSTCC

2014-06-02 Thread Simon Glass
We want to use some of the functionality in this file, so make it
build on the host.

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

 common/bootm.c | 18 ++
 tools/Makefile |  1 +
 tools/bootm.c  |  1 +
 3 files changed, 16 insertions(+), 4 deletions(-)
 create mode 100644 tools/bootm.c

diff --git a/common/bootm.c b/common/bootm.c
index a19a9de..7613e49 100644
--- a/common/bootm.c
+++ b/common/bootm.c
@@ -5,10 +5,10 @@
  * SPDX-License-Identifier:GPL-2.0+
  */
 
+#ifndef USE_HOSTCC
 #include common.h
-#include bootm.h
+#include bootstage.h
 #include bzlib.h
-#include image.h
 #include fdt_support.h
 #include lmb.h
 #include malloc.h
@@ -17,12 +17,16 @@
 #include lzma/LzmaTypes.h
 #include lzma/LzmaDec.h
 #include lzma/LzmaTools.h
-
 #if defined(CONFIG_CMD_USB)
 #include usb.h
 #endif
+#else
+#include mkimage.h
+#endif
 
-DECLARE_GLOBAL_DATA_PTR;
+#include command.h
+#include bootm.h
+#include image.h
 
 #ifndef CONFIG_SYS_BOOTM_LEN
 /* use 8MByte as default max gunzip size */
@@ -31,6 +35,10 @@ DECLARE_GLOBAL_DATA_PTR;
 
 #define IH_INITRD_ARCH IH_ARCH_DEFAULT
 
+#ifndef USE_HOSTCC
+
+DECLARE_GLOBAL_DATA_PTR;
+
 static const void *boot_get_kernel(cmd_tbl_t *cmdtp, int flag, int argc,
   char * const argv[], bootm_headers_t *images,
   ulong *os_data, ulong *os_len);
@@ -801,3 +809,5 @@ static const void *boot_get_kernel(cmd_tbl_t *cmdtp, int 
flag, int argc,
 
return buf;
 }
+
+#endif /* ndef USE_HOSTCC */
diff --git a/tools/Makefile b/tools/Makefile
index 7610557..6348030 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -73,6 +73,7 @@ RSA_OBJS-$(CONFIG_FIT_SIGNATURE) := rsa-sign.o rsa-verify.o 
rsa-checksum.o
 dumpimage-mkimage-objs := aisimage.o \
atmelimage.o \
$(FIT_SIG_OBJS-y) \
+   bootm.o \
crc32.o \
default_image.o \
fdtdec.o \
diff --git a/tools/bootm.c b/tools/bootm.c
new file mode 100644
index 000..63d5eb8
--- /dev/null
+++ b/tools/bootm.c
@@ -0,0 +1 @@
+#include ../common/bootm.c
-- 
1.9.1.423.g4596e3a

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


[U-Boot] [PATCH 10/11] Enhance fit_check_sign to check all images

2014-06-02 Thread Simon Glass
At present this tool only checks the configuration signing. Have it also
look at each of the images in the configuration and confirm that they
verify.

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

 common/bootm.c | 71 ++
 common/image-fit.c |  3 ++-
 include/bootm.h|  2 ++
 include/image.h|  5 +++-
 tools/fit_check_sign.c |  7 +++--
 tools/image-host.c | 12 ++---
 6 files changed, 93 insertions(+), 7 deletions(-)

diff --git a/common/bootm.c b/common/bootm.c
index 0cfb7f8..a01b7b8 100644
--- a/common/bootm.c
+++ b/common/bootm.c
@@ -242,6 +242,7 @@ static int bootm_find_other(cmd_tbl_t *cmdtp, int flag, int 
argc,
 
return 0;
 }
+#endif /* USE_HOSTCC */
 
 /**
  * decomp_image() - decompress the operating system
@@ -351,6 +352,7 @@ static int decomp_image(int comp, ulong load, ulong 
image_start, int type,
return 0;
 }
 
+#ifndef USE_HOSTCC
 static int bootm_load_os(bootm_headers_t *images, unsigned long *load_end,
 int boot_progress)
 {
@@ -830,5 +832,74 @@ static const void *boot_get_kernel(cmd_tbl_t *cmdtp, int 
flag, int argc,
 
return buf;
 }
+#else /* USE_HOSTCC */
+
+void memmove_wd(void *to, void *from, size_t len, ulong chunksz)
+{
+   memmove(to, from, len);
+}
+
+static int bootm_host_load_image(const void *fit, int req_image_type)
+{
+   const char *fit_uname_config = NULL;
+   ulong data, len;
+   bootm_headers_t images;
+   int noffset;
+   ulong load_end;
+   uint8_t image_type;
+   uint8_t imape_comp;
+   void *load_buf;
+   int ret;
+
+   memset(images, '\0', sizeof(images));
+   images.verify = 1;
+   noffset = fit_image_load(images, (ulong)fit,
+   NULL, fit_uname_config,
+   IH_ARCH_DEFAULT, req_image_type, -1,
+   FIT_LOAD_IGNORED, data, len);
+   if (noffset  0)
+   return noffset;
+   if (fit_image_get_type(fit, noffset, image_type)) {
+   puts(Can't get image type!\n);
+   return -EINVAL;
+   }
+
+   if (fit_image_get_comp(fit, noffset, imape_comp)) {
+   puts(Can't get image compression!\n);
+   return -EINVAL;
+   }
+
+   /* Allow the image to expand by a factor of 4, should be safe */
+   load_buf = malloc((1  20) + len * 4);
+   ret = decomp_image(imape_comp, 0, data, image_type, load_buf,
+  (void *)data, len, load_end);
+   free(load_buf);
+   if (ret  ret != BOOTM_ERR_UNIMPLEMENTED)
+   return ret;
+
+   return 0;
+}
+
+int bootm_host_load_images(const void *fit, int cfg_noffset)
+{
+   static uint8_t image_types[] = {
+   IH_TYPE_KERNEL,
+   IH_TYPE_FLATDT,
+   IH_TYPE_RAMDISK,
+   };
+   int err = 0;
+   int i;
+
+   for (i = 0; i  ARRAY_SIZE(image_types); i++) {
+   int ret;
+
+   ret = bootm_host_load_image(fit, image_types[i]);
+   if (!err  ret  ret != -ENOENT)
+   err = ret;
+   }
+
+   /* Return the first error we found */
+   return err;
+}
 
 #endif /* ndef USE_HOSTCC */
diff --git a/common/image-fit.c b/common/image-fit.c
index 83fac9a..3311343 100644
--- a/common/image-fit.c
+++ b/common/image-fit.c
@@ -1591,12 +1591,13 @@ int fit_image_load(bootm_headers_t *images, ulong addr,
}
 
bootstage_mark(bootstage_id + BOOTSTAGE_SUB_CHECK_ARCH);
+#ifndef USE_HOSTCC
if (!fit_image_check_target_arch(fit, noffset)) {
puts(Unsupported Architecture\n);
bootstage_error(bootstage_id + BOOTSTAGE_SUB_CHECK_ARCH);
return -ENOEXEC;
}
-
+#endif
if (image_type == IH_TYPE_FLATDT 
!fit_image_check_comp(fit, noffset, IH_COMP_NONE)) {
puts(FDT image is compressed);
diff --git a/include/bootm.h b/include/bootm.h
index 0a3ec56..4a308d8 100644
--- a/include/bootm.h
+++ b/include/bootm.h
@@ -41,6 +41,8 @@ void lynxkdi_boot(image_header_t *hdr);
 
 boot_os_fn *bootm_os_get_boot_func(int os);
 
+int bootm_host_load_images(const void *fit, int cfg_noffset);
+
 int boot_selected_os(int argc, char * const argv[], int state,
 bootm_headers_t *images, boot_os_fn *boot_fn);
 
diff --git a/include/image.h b/include/image.h
index 142c647..7164a98 100644
--- a/include/image.h
+++ b/include/image.h
@@ -422,6 +422,7 @@ ulong genimg_get_image(ulong img_addr);
 
 int boot_get_ramdisk(int argc, char * const argv[], bootm_headers_t *images,
uint8_t arch, ulong *rd_start, ulong *rd_end);
+#endif
 
 /**
  * fit_image_load() - load an image from a FIT
@@ -451,12 +452,14 @@ int boot_get_ramdisk(int argc, char * const argv[], 
bootm_headers_t *images,
  * @param load_op  Decribes what to do with the load address
  * @param datapReturns address of loaded image
  * 

[U-Boot] [PATCH 0/11] Enhance fit_check_sign add beaglebone black vboot docs

2014-06-02 Thread Simon Glass
The fit_check_sign tool checks that the configuration is correct, but does
not check each image within that configuration. This series adds that
feature, at least for uncompressed images.

In order to arrange this, cmd_bootm.c is split up into three files, one for
the command processing, one for the OS booting and one for the general
bootm processing. Apart from reducing the size of an over-large C file, this
makes it easier to include what is needed for host compilation. As part of
this, Android boot is enabled for sandbox in case someone wants to write
a test for it.

Several people have had difficulty getting verified boot running on their
board with the instructions available. Following on from the previous series
which enabled verified boot on the Beaglebone Black, documentation is added
with a step-by-step guide on how to get this running.

This series sits on top of the tools fixes:

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

This series is available at u-boot-x86.git branch 'bone'.


Simon Glass (11):
  tools: Check arguments in fit_check_sign/fit_info
  Reverse the meaning of the fit_config_verify() return code
  bootm: Split out code from cmd_bootm.c
  image: Remove the fit_load_image() property parameter
  bootm: Support android boot on sandbox
  Fix small 'case' typo in image-fit.c
  Avoid including config.h in command.h
  Allow compiling common/bootm.c on with HOSTCC
  bootm: Move decompression code into its own function
  Enhance fit_check_sign to check all images
  Add documentation for verified boot on Beaglebone Black

 common/Makefile |2 +-
 common/bootm.c  |  905 
 common/bootm_os.c   |  480 +
 common/cmd_bootm.c  | 1337 +--
 common/cmd_fdt.c|2 +-
 common/image-fdt.c  |1 -
 common/image-fit.c  |   36 +-
 common/image-sig.c  |4 +-
 common/image.c  |2 +-
 doc/uImage.FIT/beaglebone_vboot.txt |  608 
 include/bootm.h |   57 ++
 include/command.h   |1 -
 include/configs/sandbox.h   |1 +
 include/image.h |   10 +-
 tools/Makefile  |1 +
 tools/bootm.c   |1 +
 tools/fit_check_sign.c  |   17 +-
 tools/fit_info.c|   12 +
 tools/image-host.c  |   12 +-
 19 files changed, 2140 insertions(+), 1349 deletions(-)
 create mode 100644 common/bootm.c
 create mode 100644 common/bootm_os.c
 create mode 100644 doc/uImage.FIT/beaglebone_vboot.txt
 create mode 100644 include/bootm.h
 create mode 100644 tools/bootm.c

-- 
1.9.1.423.g4596e3a

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


[U-Boot] [PATCH 05/11] bootm: Support android boot on sandbox

2014-06-02 Thread Simon Glass
A small change allows this to operate on sandbox.

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

 common/bootm.c| 2 +-
 include/configs/sandbox.h | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/common/bootm.c b/common/bootm.c
index 0b4fe7b..a19a9de 100644
--- a/common/bootm.c
+++ b/common/bootm.c
@@ -785,7 +785,7 @@ static const void *boot_get_kernel(cmd_tbl_t *cmdtp, int 
flag, int argc,
 #ifdef CONFIG_ANDROID_BOOT_IMAGE
case IMAGE_FORMAT_ANDROID:
printf(## Booting Android Image at 0x%08lx ...\n, img_addr);
-   if (android_image_get_kernel((void *)img_addr, images-verify,
+   if (android_image_get_kernel(buf, images-verify,
 os_data, os_len))
return NULL;
break;
diff --git a/include/configs/sandbox.h b/include/configs/sandbox.h
index 6bb2546..a145094 100644
--- a/include/configs/sandbox.h
+++ b/include/configs/sandbox.h
@@ -41,6 +41,7 @@
 #define CONFIG_RSA
 #define CONFIG_CMD_FDT
 #define CONFIG_DEFAULT_DEVICE_TREE sandbox
+#define CONFIG_ANDROID_BOOT_IMAGE
 
 #define CONFIG_FS_FAT
 #define CONFIG_FS_EXT4
-- 
1.9.1.423.g4596e3a

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


[U-Boot] [PATCH 09/11] bootm: Move decompression code into its own function

2014-06-02 Thread Simon Glass
This makes it possible to decompress an image without it being a kernel
and without intending to boot it (as it needed for host tools, for example).

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

 common/bootm.c | 75 +-
 1 file changed, 48 insertions(+), 27 deletions(-)

diff --git a/common/bootm.c b/common/bootm.c
index 7613e49..0cfb7f8 100644
--- a/common/bootm.c
+++ b/common/bootm.c
@@ -243,32 +243,29 @@ static int bootm_find_other(cmd_tbl_t *cmdtp, int flag, 
int argc,
return 0;
 }
 
-static int bootm_load_os(bootm_headers_t *images, unsigned long *load_end,
-int boot_progress)
+/**
+ * decomp_image() - decompress the operating system
+ *
+ * @comp:  Compression algorithm that is used (IH_COMP_...)
+ * @load:  Destination load address in U-Boot memory
+ * @image_start Image start address (where we are decompressing from)
+ * @type:  OS type (IH_OS_...)
+ * @load_bug:  Place to decompress to
+ * @image_buf: Address to decompress from
+ * @return 0 if OK, -ve on error (BOOTM_ERR_...)
+ */
+static int decomp_image(int comp, ulong load, ulong image_start, int type,
+   void *load_buf, void *image_buf, ulong image_len,
+   ulong *load_end)
 {
-   image_info_t os = images-os;
-   uint8_t comp = os.comp;
-   ulong load = os.load;
-   ulong blob_start = os.start;
-   ulong blob_end = os.end;
-   ulong image_start = os.image_start;
-   ulong image_len = os.image_len;
-   __maybe_unused uint unc_len = CONFIG_SYS_BOOTM_LEN;
-   int no_overlap = 0;
-   void *load_buf, *image_buf;
-#if defined(CONFIG_LZMA) || defined(CONFIG_LZO)
-   int ret;
-#endif /* defined(CONFIG_LZMA) || defined(CONFIG_LZO) */
-
-   const char *type_name = genimg_get_type_name(os.type);
+   const char *type_name = genimg_get_type_name(type);
+   __attribute__((unused)) uint unc_len = CONFIG_SYS_BOOTM_LEN;
 
-   load_buf = map_sysmem(load, unc_len);
-   image_buf = map_sysmem(image_start, image_len);
+   *load_end = load;
switch (comp) {
case IH_COMP_NONE:
if (load == image_start) {
printf(   XIP %s ... , type_name);
-   no_overlap = 1;
} else {
printf(   Loading %s ... , type_name);
memmove_wd(load_buf, image_buf, image_len, CHUNKSZ);
@@ -280,8 +277,6 @@ static int bootm_load_os(bootm_headers_t *images, unsigned 
long *load_end,
printf(   Uncompressing %s ... , type_name);
if (gunzip(load_buf, unc_len, image_buf, image_len) != 0) {
puts(GUNZIP: uncompress, out-of-mem or overwrite error 
- must RESET board to recover\n);
-   if (boot_progress)
-   bootstage_error(BOOTSTAGE_ID_DECOMP_IMAGE);
return BOOTM_ERR_RESET;
}
 
@@ -302,8 +297,6 @@ static int bootm_load_os(bootm_headers_t *images, unsigned 
long *load_end,
if (i != BZ_OK) {
printf(BUNZIP2: uncompress or overwrite error %d - 
must RESET board to recover\n,
   i);
-   if (boot_progress)
-   bootstage_error(BOOTSTAGE_ID_DECOMP_IMAGE);
return BOOTM_ERR_RESET;
}
 
@@ -313,6 +306,8 @@ static int bootm_load_os(bootm_headers_t *images, unsigned 
long *load_end,
 #ifdef CONFIG_LZMA
case IH_COMP_LZMA: {
SizeT lzma_len = unc_len;
+   int ret;
+
printf(   Uncompressing %s ... , type_name);
 
ret = lzmaBuffToBuffDecompress(load_buf, lzma_len,
@@ -331,6 +326,7 @@ static int bootm_load_os(bootm_headers_t *images, unsigned 
long *load_end,
 #ifdef CONFIG_LZO
case IH_COMP_LZO: {
size_t size = unc_len;
+   int ret;
 
printf(   Uncompressing %s ... , type_name);
 
@@ -338,8 +334,6 @@ static int bootm_load_os(bootm_headers_t *images, unsigned 
long *load_end,
if (ret != LZO_E_OK) {
printf(LZO: uncompress or overwrite error %d - must 
RESET board to recover\n,
   ret);
-   if (boot_progress)
-   bootstage_error(BOOTSTAGE_ID_DECOMP_IMAGE);
return BOOTM_ERR_RESET;
}
 
@@ -352,12 +346,39 @@ static int bootm_load_os(bootm_headers_t *images, 
unsigned long *load_end,
return BOOTM_ERR_UNIMPLEMENTED;
}
 
+   puts(OK\n);
+
+   return 0;
+}
+
+static int bootm_load_os(bootm_headers_t *images, unsigned long *load_end,
+int boot_progress)
+{
+   image_info_t os = images-os;
+   ulong load = os.load;
+   ulong blob_start = os.start;
+   

[U-Boot] [PATCH 11/11] Add documentation for verified boot on Beaglebone Black

2014-06-02 Thread Simon Glass
As an example of an end-to-end process for using verified boot in U-Boot,
add a detailed description of the steps to be used for a Beaglebone
Black.

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

 doc/uImage.FIT/beaglebone_vboot.txt | 608 
 1 file changed, 608 insertions(+)
 create mode 100644 doc/uImage.FIT/beaglebone_vboot.txt

diff --git a/doc/uImage.FIT/beaglebone_vboot.txt 
b/doc/uImage.FIT/beaglebone_vboot.txt
new file mode 100644
index 000..6a6d58d
--- /dev/null
+++ b/doc/uImage.FIT/beaglebone_vboot.txt
@@ -0,0 +1,608 @@
+Verified Boot on the Beaglebone Black
+=
+
+Introduction
+
+
+Before reading this, please read verified-boot.txt and signature.txt. These
+instructions are for mainline U-Boot from v2014.07 onwards.
+
+There is quite a bit of documentation in this directory describing how
+verified boot works in U-Boot. There is also a test which runs through the
+entire process of signing an image and running U-Boot (sandbox) to check it.
+However, it might be useful to also have an example on a real board.
+
+Beaglebone Black is a fairly common board so seems to be a reasonable choice
+for an example of how to enable verified boot using U-Boot.
+
+First a note that may to help avoid confusion. U-Boot and Linux both use
+device tree. They may use the same device tree source, but it is seldom useful
+for them to use the exact same binary from the same place. More typically,
+U-Boot has its device tree packaged wtih it, and the kernel's device tree is
+packaged with the kernel. In particular this is important with verified boot,
+since U-Boot's device tree must be immutable. If it can be changed then the
+public keys can be changed and verified boot is useless. An attacker can
+simply generate a new key and put his public key into U-Boot so that
+everything verifies. On the other hand the kernel's device tree typically
+changes when the kernel changes, so it is useful to package an updated device
+tree with the kernel binary. U-Boot supports the latter with its flexible FIT
+format (Flat Image Tree).
+
+
+Overview
+
+
+The steps are roughly as follows:
+
+1. Build U-Boot for the board, with the verified boot options enabled.
+
+2. Obtain a suitable Linux kernel
+
+3. Create a Image Tree Source file (ITS) file describing how you want the
+kernel to be packaged, compressed and signed.
+
+4. Create a key pair
+
+5. Sign the kernel
+
+6. Put the public key into U-Boot's image
+
+7. Put U-Boot and the kernel onto the board
+
+8. Try it
+
+
+Step 1: Build U-Boot
+
+
+a. Set up the environment variable to point to your toolchain. You will need
+this for U-Boot and also for the kernel if you build it. For example if you
+installed a Linaro version manually it might be something like:
+
+   export 
CROSS_COMPILE=/opt/linaro/gcc-linaro-arm-linux-gnueabihf-4.8-2013.08_linux/bin/arm-linux-gnueabihf-
+
+or if you just installed gcc-arm-linux-gnueabi then it might be
+
+   export CROSS_COMPILE=arm-linux-gnueabi-
+
+b. Configure and build U-Boot with verified boot enabled:
+
+   export ARCH=arm
+   export UBOOT=/path/to/u-boot
+   cd $UBOOT
+   # You can add -j10 if you have 10 CPUs to make it faster
+   make O=b/am335x_boneblack_vboot am335x_boneblack_vboot_config all
+   export UOUT=$UBOOT/b/am335x_boneblack_vboot
+
+c. You will now have a U-Boot image:
+
+   file b/am335x_boneblack_vboot/u-boot-dtb.img
+b/am335x_boneblack_vboot/u-boot-dtb.img: u-boot legacy uImage, U-Boot 
2014.07-rc2-00065-g2f69f8, Firmware/ARM, Firmware Image (Not compressed), 
395375 bytes, Sat May 31 16:19:04 2014, Load Address: 0x8080, Entry Point: 
0x, Header CRC: 0x0ABD6ACA, Data CRC: 0x36DEF7E4
+
+
+Step 2: Build Linux
+
+
+a. Find the kernel image ('Image') and device tree (.dtb) file you plan to
+use. In our case it is am335x-boneblack.dtb and it is built with the kernel.
+At the time of writing an SD Boot image can be obtained from here:
+
+   
http://www.elinux.org/Beagleboard:Updating_The_Software#Image_For_Booting_From_microSD
+
+You can write this to an SD card and then mount it to extract the kernel and
+device tree files.
+
+You can also build a kernel. Instructions for this are are here:
+
+   http://elinux.org/Building_BBB_Kernel
+
+or you can use your favourite search engine. Following these instructions
+produces a kernel Image and device tree files. For the record the steps were:
+
+   export KERNEL=/path/to/kernel
+   cd $KERNEL
+   git clone git://github.com/beagleboard/kernel.git .
+   git checkout v3.14
+   ./patch.sh
+   cp configs/beaglebone kernel/arch/arm/configs/beaglebone_defconfig
+   cd kernel
+   make beaglebone_defconfig
+   make uImage dtbs   # -j10 if you have 10 CPUs
+   export OKERNEL=$KERNEL/kernel/arch/arm/boot
+
+c. You now have the 'Image' and 'am335x-boneblack.dtb' files needed to boot.
+
+
+Step 3: Create the ITS
+--
+
+Set up a 

[U-Boot] [PATCH 01/11] tools: Check arguments in fit_check_sign/fit_info

2014-06-02 Thread Simon Glass
These tools crash if no arguments are provided. Add checks to avoid this.

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

 tools/fit_check_sign.c |  9 +
 tools/fit_info.c   | 12 
 2 files changed, 21 insertions(+)

diff --git a/tools/fit_check_sign.c b/tools/fit_check_sign.c
index af257cc..e1198bc 100644
--- a/tools/fit_check_sign.c
+++ b/tools/fit_check_sign.c
@@ -62,6 +62,15 @@ int main(int argc, char **argv)
break;
}
 
+   if (!fdtfile) {
+   fprintf(stderr, %s: Missing fdt file\n, *argv);
+   usage(*argv);
+   }
+   if (!keyfile) {
+   fprintf(stderr, %s: Missing key file\n, *argv);
+   usage(*argv);
+   }
+
ffd = mmap_fdt(cmdname, fdtfile, 0, fit_blob, fsbuf, false);
if (ffd  0)
return EXIT_FAILURE;
diff --git a/tools/fit_info.c b/tools/fit_info.c
index afbed7b..481ac6d 100644
--- a/tools/fit_info.c
+++ b/tools/fit_info.c
@@ -68,6 +68,18 @@ int main(int argc, char **argv)
break;
}
 
+   if (!fdtfile) {
+   fprintf(stderr, %s: Missing fdt file\n, *argv);
+   usage(*argv);
+   }
+   if (!nodename) {
+   fprintf(stderr, %s: Missing node name\n, *argv);
+   usage(*argv);
+   }
+   if (!propertyname) {
+   fprintf(stderr, %s: Missing property name\n, *argv);
+   usage(*argv);
+   }
ffd = mmap_fdt(cmdname, fdtfile, 0, fit_blob, fsbuf, false);
 
if (ffd  0) {
-- 
1.9.1.423.g4596e3a

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


[U-Boot] [PATCH 06/11] Fix small 'case' typo in image-fit.c

2014-06-02 Thread Simon Glass
This typo makes the comment confusing. Fix it.

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

 common/image-fit.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/common/image-fit.c b/common/image-fit.c
index c0d7b8c..83fac9a 100644
--- a/common/image-fit.c
+++ b/common/image-fit.c
@@ -1637,7 +1637,7 @@ int fit_image_load(bootm_headers_t *images, ulong addr,
 
/*
 * Work-around for eldk-4.2 which gives this warning if we try to
-* case in the unmap_sysmem() call:
+* cast in the unmap_sysmem() call:
 * warning: initialization discards qualifiers from pointer target type
 */
{
-- 
1.9.1.423.g4596e3a

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


[U-Boot] [PATCH 04/11] image: Remove the fit_load_image() property parameter

2014-06-02 Thread Simon Glass
This can be obtained by looking up the image type, so is redundant. It is
better to centralise this lookup to avoid errors.

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

 common/bootm.c |  3 +--
 common/image-fdt.c |  1 -
 common/image-fit.c | 29 -
 common/image.c |  2 +-
 include/image.h|  5 +++--
 5 files changed, 33 insertions(+), 7 deletions(-)

diff --git a/common/bootm.c b/common/bootm.c
index 40d0f3f..0b4fe7b 100644
--- a/common/bootm.c
+++ b/common/bootm.c
@@ -768,8 +768,7 @@ static const void *boot_get_kernel(cmd_tbl_t *cmdtp, int 
flag, int argc,
break;
 #if defined(CONFIG_FIT)
case IMAGE_FORMAT_FIT:
-   os_noffset = fit_image_load(images, FIT_KERNEL_PROP,
-   img_addr,
+   os_noffset = fit_image_load(images, img_addr,
fit_uname_kernel, fit_uname_config,
IH_ARCH_DEFAULT, IH_TYPE_KERNEL,
BOOTSTAGE_ID_FIT_KERNEL_START,
diff --git a/common/image-fdt.c b/common/image-fdt.c
index 5d64009..7ae9c5c 100644
--- a/common/image-fdt.c
+++ b/common/image-fdt.c
@@ -349,7 +349,6 @@ int boot_get_fdt(int flag, int argc, char * const argv[], 
uint8_t arch,
ulong load, len;
 
fdt_noffset = fit_image_load(images,
-   FIT_FDT_PROP,
fdt_addr, fit_uname_fdt,
fit_uname_config,
arch, IH_TYPE_FLATDT,
diff --git a/common/image-fit.c b/common/image-fit.c
index 40c7e27..c0d7b8c 100644
--- a/common/image-fit.c
+++ b/common/image-fit.c
@@ -1477,7 +1477,32 @@ int fit_get_node_from_config(bootm_headers_t *images, 
const char *prop_name,
return noffset;
 }
 
-int fit_image_load(bootm_headers_t *images, const char *prop_name, ulong addr,
+/**
+ * fit_get_image_type_property() - get property name for IH_TYPE_...
+ *
+ * @return the properly name where we expect to find the image in the
+ * config node
+ */
+static const char *fit_get_image_type_property(int type)
+{
+   /*
+* This is sort-of available in the uimage_type[] table in image.c
+* but we don't have access to the sohrt name, and fdt is different
+* anyway. So let's just keep it here.
+*/
+   switch (type) {
+   case IH_TYPE_FLATDT:
+   return FIT_FDT_PROP;
+   case IH_TYPE_KERNEL:
+   return FIT_KERNEL_PROP;
+   case IH_TYPE_RAMDISK:
+   return FIT_RAMDISK_PROP;
+   }
+
+   return unknown;
+}
+
+int fit_image_load(bootm_headers_t *images, ulong addr,
   const char **fit_unamep, const char **fit_uname_configp,
   int arch, int image_type, int bootstage_id,
   enum fit_load_op load_op, ulong *datap, ulong *lenp)
@@ -1490,11 +1515,13 @@ int fit_image_load(bootm_headers_t *images, const char 
*prop_name, ulong addr,
size_t size;
int type_ok, os_ok;
ulong load, data, len;
+   const char *prop_name;
int ret;
 
fit = map_sysmem(addr, 0);
fit_uname = fit_unamep ? *fit_unamep : NULL;
fit_uname_config = fit_uname_configp ? *fit_uname_configp : NULL;
+   prop_name = fit_get_image_type_property(image_type);
printf(## Loading %s from FIT Image at %08lx ...\n, prop_name, addr);
 
bootstage_mark(bootstage_id + BOOTSTAGE_SUB_FORMAT);
diff --git a/common/image.c b/common/image.c
index 26eb89a..598dfcd 100644
--- a/common/image.c
+++ b/common/image.c
@@ -892,7 +892,7 @@ int boot_get_ramdisk(int argc, char * const argv[], 
bootm_headers_t *images,
break;
 #if defined(CONFIG_FIT)
case IMAGE_FORMAT_FIT:
-   rd_noffset = fit_image_load(images, FIT_RAMDISK_PROP,
+   rd_noffset = fit_image_load(images,
rd_addr, fit_uname_ramdisk,
fit_uname_config, arch,
IH_TYPE_RAMDISK,
diff --git a/include/image.h b/include/image.h
index 41e56ab..142c647 100644
--- a/include/image.h
+++ b/include/image.h
@@ -431,8 +431,9 @@ int boot_get_ramdisk(int argc, char * const argv[], 
bootm_headers_t *images,
  * out progress messages, checking the type/arch/os and optionally copying it
  * to the right load address.
  *
+ * The property to look up is defined by image_type.
+ *
  * @param images   Boot images structure
- * @param prop_nameProperty name to look up (FIT_..._PROP)
  * @param addr Address of FIT in memory
  * @param fit_unamep   On entry this is the requested image name
  * (e.g. kernel@1) or NULL to use the default. On exit
@@ -451,7 +452,7 @@ int boot_get_ramdisk(int argc, char * const argv[], 
bootm_headers_t 

[U-Boot] [PATCH 07/11] Avoid including config.h in command.h

2014-06-02 Thread Simon Glass
This is not necessary and prevents using this header when building tools.

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

 include/command.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/include/command.h b/include/command.h
index d3f700f..6f06db1 100644
--- a/include/command.h
+++ b/include/command.h
@@ -11,7 +11,6 @@
 #ifndef __COMMAND_H
 #define __COMMAND_H
 
-#include config.h
 #include linker_lists.h
 
 #ifndef NULL
-- 
1.9.1.423.g4596e3a

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


  1   2   >