Re: [U-Boot] u-boot/master slight regression with trats

2012-10-01 Thread Lukasz Majewski
Hi Tom,

> On Mon, Oct 01, 2012 at 12:25:34PM +0200, Lukasz Majewski wrote:
> > Hi all,
> > 
> > > 
> > > > 
> > > > On Sat, 29 Sep 2012 17:17:48 +0200
> > > > Albert ARIBAUD  wrote:
> > > > 
> > > > > Hi all,
> > > > > 
> > > > > On Sat, 29 Sep 2012 12:32:36 +0200, Albert ARIBAUD
> > > > >  wrote:
> > > > > 
> > > > > > Hello,
> > > > > > 
> > > > > > While merging u-boot-arm/master and u-boot/master I have
> > > > > > noticed one slight regression apparently coming from u-boot:
> > > > > > 
> > > > > > $ cat LOG/trats.ERR 
> > > > > > cmd_fat.c: In function ???do_fat_fswrite???:
> > > > > > cmd_fat.c:178:8: warning: unused variable
> > > > > > ???ep??? [-Wunused-variable]
> > > > > > 
> > > > > > ep should have disappeared along with the code which used
> > > > > > it, but somehow resurfaced (I suspect it did in a merge).
> > > > > > 
> > > > > > This warning is not seen in u-boot-arm.
> > > > > > 
> > > > > > Amicalement,
> > > > > 
> > > > > Seems Heungjun Kim  is now a dead
> > > > > address.
> > > > > 
> > > > > Anatolij, I see you've sent out a patch. Does it mean you
> > > > > would act as a maintainer for trats? 
> > > > > Otherwise the board should be made orphan.
> > > 
> > > Dear all, I was on a holidays :-). 
> > > 
> > > I can test if Trats is working. I posses one, so there is no
> > > problem with that :-).
> > > 
> > > I will fix Trats ASAP.
> > 
> > I've just tested TRATS with the newest origin/master 
> > (SHA1: 4668a086bb0a769b741e3a4ffab85f1c41c7cdb8 )
> > 
> > It builds without errors/warinigs
> > 
> > > 
> > > > 
> > > > I do not have a trats board, so I can't do tests and act as a
> > > > maintainer for it. Lukasz (on Cc) recently submitted some
> > > > patches for trats, maybe he knows who could become new
> > > > maintainer for trats board?
> 
> Ah, but would you be willing to take the MAINTAINER spot for the
> board? Thanks!
> 

I can serve as a maintainer for the board - I posses one and I
actively develop and test code for it. No problem with that.

-- 
Best regards,

Lukasz Majewski

Samsung Poland R&D Center | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 3/3] tegra: enable CONFIG_CMD_PARTUUID

2012-10-01 Thread Simon Glass
On Thu, Aug 16, 2012 at 4:15 PM, Stephen Warren  wrote:
> From: Stephen Warren 
>
> This is extremely likely to be used from the boot.scr that Tegra's default
> bootcmd locates and executes.
>
> Signed-off-by: Stephen Warren 

Acked-by: Simon Glass 

> ---
>  include/configs/tegra20-common-post.h |5 +
>  include/configs/tegra20-common.h  |1 +
>  2 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/include/configs/tegra20-common-post.h 
> b/include/configs/tegra20-common-post.h
> index 42f270f..b7bbc0c 100644
> --- a/include/configs/tegra20-common-post.h
> +++ b/include/configs/tegra20-common-post.h
> @@ -209,6 +209,11 @@
>  #undef CONFIG_CMD_USB
>  #endif
>
> +/* remove partuuid command support */
> +#ifdef CONFIG_CMD_PARTUUID
> +#undef CONFIG_CMD_PARTUUID
> +#endif
> +
>  #endif /* CONFIG_SPL_BUILD */
>
>  #endif /* __TEGRA20_COMMON_POST_H */
> diff --git a/include/configs/tegra20-common.h 
> b/include/configs/tegra20-common.h
> index c9e8b6b..c76eea4 100644
> --- a/include/configs/tegra20-common.h
> +++ b/include/configs/tegra20-common.h
> @@ -113,6 +113,7 @@
>
>  /* include default commands */
>  #include 
> +#define CONFIG_CMD_PARTUUID
>
>  /* remove unused commands */
>  #undef CONFIG_CMD_FLASH/* flinfo, erase, protect */
> --
> 1.7.0.4
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] Is there file size limiation of tftp

2012-10-01 Thread Simon Glass
Hi,

On Sun, Aug 12, 2012 at 8:41 AM, Jerry Van Baren  wrote:
> On 08/11/2012 09:21 PM, J.Hwan Kim wrote:
>> Hi, everyone
>>
>> Is there any limit of file size for tftpboot?
>> I have a problem downloading the file of which file size is 65MB.
>> The procedure stops in the middle of downloading.
>>
>> Thanks in advnace.
>>
>> Best Regards,
>> J.Hwan Kim
>>
>> -
>>
>> # tftp 0xc000 192.168.100.10:system.img
>> smc911x: detected LAN9221 controller
>> smc911x: phy initialized
>> smc911x: MAC c3ea1460M (00405c260a5b)
>> TFTP from server 192.168.100.10; our IP address is 192.168.100.50
>> Filename 'system.img'.
>> Load address: 0xc000
>
> Probably what Mike said.  Note that 64MB is 0x4000 and your load
> address is 0xC000... add the two together and you get 0x1__
> which is a very suspicious number.
>
> Having said that, there are two places where TFTP implementations have
> problems.  The block number is a 16 bit unsigned integer.
>
> The easier (and less often problematic) one is where the block number
> goes from 0x7FFF to 0x8000.  If an implementation erroneously treats the
> block number as a *signed* integer, it will screw that up.
>
> The second size limit stumbling block is when the block number hits
> 0x, what is the next block number?  Some implementations just give
> up and limit the maximum file size to 64K-1 blocks[1].  If your block
> size is the default 512, that makes the maximum file size 32MB.  If your
> block size is 4K, it will make the maximum file size 256MB.

Yes. If it helps, I found a limit of about 95MB, which is something
like (the maximum tftp packet payload on Ethernet of about 1450) *
65535 or similar, caused by a buggy tftp server. When I switched to
tftpd-hpa my problems went away.

>
> RFC1350[2] is silent on the issue, probably because the authors never
> considered using TFTP with files bigger than 32MB.  TFTP does use block
> number 0 in a special way to ACK the write request and says "block
> numbers are consecutive and begin with one."  The simpler and more
> intuitive interpretation of 0x + 1 is to wrap to 0x.  The less
> intuitive one that honors 0 being special is to wrap to 0x0001.
>
> U-Boot wraps to 0, see net/tftp.c function update_block_number().  Your
> TFTP server needs to do the same.
>
> Best regards,
> gvb

Regards,
Simon


>
> Ref:
> [1] 
> [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] [PATCH 3/8 V2] EXYNOS: Add clock for SPI.

2012-10-01 Thread Simon Glass
Hi,

On Tue, Jul 31, 2012 at 4:00 AM, Rajeshwari Shinde
 wrote:
> This patch adds api to calculate and set the clock for SPI channels
>
> Signed-off-by: Simon Glass 
> Signed-off-by: Rajeshwari Shinde 

I believe this should also have a sign-off from
jamesmil...@chromium.org, since he wrote much of the code.

Regards,
Simon

> ---
> Changes in V2:
> - None
>  arch/arm/cpu/armv7/exynos/clock.c  |  122 
> 
>  arch/arm/include/asm/arch-exynos/clk.h |4 +-
>  2 files changed, 125 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/cpu/armv7/exynos/clock.c 
> b/arch/arm/cpu/armv7/exynos/clock.c
> index de3db8e..ea5c305 100644
> --- a/arch/arm/cpu/armv7/exynos/clock.c
> +++ b/arch/arm/cpu/armv7/exynos/clock.c
> @@ -628,6 +628,122 @@ static unsigned long exynos5_get_i2c_clk(void)
> return aclk_66;
>  }
>
> +/**
> + * Linearly searches for the most accurate main and fine stage clock scalars
> + * (divisors) for a specified target frequency and scalar bit sizes by 
> checking
> + * all multiples of main_scalar_bits values. Will always return scalars up 
> to or
> + * slower than target.
> + *
> + * @param main_scalar_bits Number of main scalar bits, must be > 0 and < 
> 32
> + * @param fine_scalar_bits Number of fine scalar bits, must be > 0 and < 
> 32
> + * @param input_freq   Clock frequency to be scaled in Hz
> + * @param target_freq  Desired clock frequency in Hz
> + * @param best_fine_scalar Pointer to store the fine stage divisor
> + *
> + * @return best_main_scalarMain scalar for desired frequency or -1 if 
> none
> + * found
> + */
> +static int clock_calc_best_scalar(unsigned int main_scaler_bits,
> +   unsigned int fine_scalar_bits, unsigned int input_rate,
> +   unsigned int target_rate, unsigned int *best_fine_scalar)
> +{
> +   int i;
> +   int best_main_scalar = -1;
> +   unsigned int best_error = target_rate;
> +   const unsigned int cap = (1 << fine_scalar_bits) - 1;
> +   const unsigned int loops = 1 << main_scaler_bits;
> +
> +   debug("Input Rate is %u, Target is %u, Cap is %u\n", input_rate,
> +   target_rate, cap);
> +
> +   assert(best_fine_scalar != NULL);
> +   assert(main_scaler_bits <= fine_scalar_bits);
> +
> +   *best_fine_scalar = 1;
> +
> +   if (input_rate == 0 || target_rate == 0)
> +   return -1;
> +
> +   if (target_rate >= input_rate)
> +   return 1;
> +
> +   for (i = 1; i <= loops; i++) {
> +   const unsigned int effective_div = max(min(input_rate / i /
> +   target_rate, cap), 1);
> +   const unsigned int effective_rate = input_rate / i /
> +   effective_div;
> +   const int error = target_rate - effective_rate;
> +
> +   debug("%d|effdiv:%u, effrate:%u, error:%d\n", i, 
> effective_div,
> +   effective_rate, error);
> +
> +   if (error >= 0 && error <= best_error) {
> +   best_error = error;
> +   best_main_scalar = i;
> +   *best_fine_scalar = effective_div;
> +   }
> +   }
> +
> +   return best_main_scalar;
> +}
> +
> +static int exynos5_spi_set_clock_rate(enum periph_id periph_id,
> +   unsigned int rate)
> +{
> +   struct exynos5_clock *clk =
> +   (struct exynos5_clock *)samsung_get_base_clock();
> +   int main;
> +   unsigned int fine;
> +   unsigned shift, pre_shift;
> +   unsigned mask = 0xff;
> +   u32 *reg;
> +
> +   main = clock_calc_best_scalar(4, 8, 4, rate, &fine);
> +   if (main < 0) {
> +   debug("%s: Cannot set clock rate for periph %d",
> +   __func__, periph_id);
> +   return -1;
> +   }
> +   main = main - 1;
> +   fine = fine - 1;
> +
> +   switch (periph_id) {
> +   case PERIPH_ID_SPI0:
> +   reg = &clk->div_peric1;
> +   shift = 0;
> +   pre_shift = 8;
> +   break;
> +   case PERIPH_ID_SPI1:
> +   reg = &clk->div_peric1;
> +   shift = 16;
> +   pre_shift = 24;
> +   break;
> +   case PERIPH_ID_SPI2:
> +   reg = &clk->div_peric2;
> +   shift = 0;
> +   pre_shift = 8;
> +   break;
> +   case PERIPH_ID_SPI3:
> +   reg = &clk->sclk_div_isp;
> +   shift = 0;
> +   pre_shift = 4;
> +   break;
> +   case PERIPH_ID_SPI4:
> +   reg = &clk->sclk_div_isp;
> +   shift = 12;
> +   pre_shift = 16;
> +   break;
> +   default:
> +   debug("%s: Unsupported peripheral ID %d\n", __func__,
> +  

Re: [U-Boot] v2012.10-rc2 is now released

2012-10-01 Thread Albert ARIBAUD
Hi Tom,

On Mon, 1 Oct 2012 09:59:18 -0700, Tom Rini  wrote:

> Hey all,
> 
> I've tagged and pushed v2012.10-rc2.  It's a little later than I had
> intended, but I think we're still largely on track for -rc3.  That said,
> lets push -rc3 back to next monday and give a little more time between
> Albert's u-boot-arm PR being merged and the tag.  Speaking of, that's
> what I expect for the big changes to be between now and then:
> 
> - Albert said he plans to have a PR ready by Thursday, that needs to go
>   in.

I am also expecting a Marvell pull request to come before thursday.
Prafulla?

> - It also NEEDS to have a resolution, for this release, for the
>   ARMv7/unaligned access/gcc 4.7 (and linaro 4.6) thing.

For 2012.07 there was a -mno-unaligned-access option added to all of
armv7 in a last-minute attempt to get the release working while a
solution was found, and after that no one seemed bothered enough to
handle things.

For 2012.10 we still don't have a solution but we have a root cause and
the long term solution is to get the compiler fixed, which implies
doing a patch -- I've got this effort started. Meanwhile, I see no point
in redoing for 2012.10 was was done for 2012.07, seeing how it ended up.
Therefore I will add -mno-unaligned-access only to the files which
require it. I'll send a patch later today for this.

> - Other pull requests of either fixes or things posted by the original
>   merge window closure that hadn't been picked up yet AND are obviously
>   correct or important bug fixes.  Otherwise we can hold them off for
>   the next branches.

> As a reminder, the next branch is open and I haven't seen any pull
> requests for that yet, aside from Marek on some of the pre-reqs for DM
> work.

I have see Tom's tegra pull. for my next. Priority for me right now is
the release.

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


Re: [U-Boot] [PATCH 0/4] Some patman fixes

2012-10-01 Thread Simon Glass
Hi,

On Tue, Aug 7, 2012 at 2:46 AM, Ilya Yanok
 wrote:
> Patman is the great tool but I've found it nearly unusable for me.
> First of all I need to work with multiple signoffs in commits,
> then I'd like to use multiline changelog entries and I accostomed
> to putting changelog enties to the bottom of the commit.
>

I do wonder whether there should at least be options to sort/uniq
entries and use the 'one line' format. I try to keep the changelog to
a single line for each thing I change, and the merging that happens in
the cover letter is useful, I think.

Regards,
Simon

> These patches fix changelog processing and disables additional
> signoff and changelog processing.
>
>
> Ilya Yanok (4):
>   patman: fix end of changes detection
>   patman: don't pick changes while processing patches
>   patman: don't mess with changelog
>   patman: don't mess with signoffs
>
>  tools/patman/patchstream.py |   22 ++
>  tools/patman/series.py  |5 ++---
>  2 files changed, 12 insertions(+), 15 deletions(-)
>
> --
> 1.7.9.5
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH V4 2/4] ARM: arm1176: enable instruction cache in arch_cpu_init()

2012-10-01 Thread Simon Glass
On Sun, Aug 5, 2012 at 7:07 PM, Stephen Warren  wrote:
> Note that this affects all users of the ARM1176 CPU that enable
> CONFIG_ARCH_CPU_INIT, not just the BCM2835 SoC, potentially such as
> tnetv107x.
>
> Cc: Cyril Chemparathy 
> Signed-off-by: Stephen Warren 

Acked-by: Simon Glass 

> ---
> v4: No change
> v3: No change, re-ordered patch
> v2: No change
> ---
>  arch/arm/cpu/arm1176/cpu.c |7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/arch/arm/cpu/arm1176/cpu.c b/arch/arm/cpu/arm1176/cpu.c
> index c0fd114..532a90b 100644
> --- a/arch/arm/cpu/arm1176/cpu.c
> +++ b/arch/arm/cpu/arm1176/cpu.c
> @@ -65,3 +65,10 @@ static void cache_flush (void)
> /* mem barrier to sync things */
> asm ("mcr p15, 0, %0, c7, c10, 4": :"r" (0));
>  }
> +
> +int arch_cpu_init(void)
> +{
> +   icache_enable();
> +
> +   return 0;
> +}
> --
> 1.7.9.5
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 8/8 V2] EXYNOS5: Enable SPI booting.

2012-10-01 Thread Simon Glass
Hi,

On Tue, Jul 31, 2012 at 4:01 AM, Rajeshwari Shinde
 wrote:
> This patch enables SPI Booting for EXYNOS5
>
> Signed-off-by: Rajeshwari Shinde 
> ---
> Changes in V2:
> - None.
>  board/samsung/smdk5250/Makefile   |2 +-
>  board/samsung/smdk5250/{mmc_boot.c => spl_boot.c} |   31 +++-
>  include/configs/smdk5250.h|5 +++
>  3 files changed, 35 insertions(+), 3 deletions(-)
>  rename board/samsung/smdk5250/{mmc_boot.c => spl_boot.c} (66%)
>
> diff --git a/board/samsung/smdk5250/Makefile b/board/samsung/smdk5250/Makefile
> index 1474fa8..47c6a5a 100644
> --- a/board/samsung/smdk5250/Makefile
> +++ b/board/samsung/smdk5250/Makefile
> @@ -36,7 +36,7 @@ COBJS += smdk5250.o
>  endif
>
>  ifdef CONFIG_SPL_BUILD
> -COBJS  += mmc_boot.o
> +COBJS  += spl_boot.o
>  endif
>
>  SRCS   := $(SOBJS:.o=.S) $(COBJS:.o=.c)
> diff --git a/board/samsung/smdk5250/mmc_boot.c 
> b/board/samsung/smdk5250/spl_boot.c
> similarity index 66%
> rename from board/samsung/smdk5250/mmc_boot.c
> rename to board/samsung/smdk5250/spl_boot.c
> index 449a919..d8f3c1e 100644
> --- a/board/samsung/smdk5250/mmc_boot.c
> +++ b/board/samsung/smdk5250/spl_boot.c
> @@ -23,6 +23,16 @@
>  #include
>  #include
>
> +enum boot_mode {
> +   BOOT_MODE_MMC = 4,
> +   BOOT_MODE_SERIAL = 20,
> +   /* Boot based on Operating Mode pin settings */
> +   BOOT_MODE_OM = 32,
> +   BOOT_MODE_USB,  /* Boot using USB download */
> +};
> +
> +   typedef u32 (*spi_copy_func_t)(u32 offset, u32 nblock, u32 dst);
> +
>  /*
>  * Copy U-boot from mmc to RAM:
>  * COPY_BL2_FNPTR_ADDR: Address in iRAM, which Contains
> @@ -30,9 +40,26 @@
>  */
>  void copy_uboot_to_ram(void)
>  {
> -   u32 (*copy_bl2)(u32, u32, u32) = (void *) *(u32 *)COPY_BL2_FNPTR_ADDR;
> +   spi_copy_func_t spi_copy;
> +   enum boot_mode bootmode;
> +   u32 (*copy_bl2)(u32, u32, u32);
> +
> +   bootmode = readl(EXYNOS5_POWER_BASE) & OM_STAT;
>
> -   copy_bl2(BL2_START_OFFSET, BL2_SIZE_BLOC_COUNT, CONFIG_SYS_TEXT_BASE);
> +   switch (bootmode) {
> +   case BOOT_MODE_SERIAL:
> +   spi_copy = *(spi_copy_func_t *)EXYNOS_COPY_SPI_FNPTR_ADDR;
> +   spi_copy(SPI_FLASH_UBOOT_POS, CONFIG_BL2_SIZE,
> +   CONFIG_SYS_TEXT_BASE);
> +   break;
> +   case BOOT_MODE_MMC:
> +   copy_bl2 = (void *) *(u32 *)COPY_BL2_FNPTR_ADDR;
> +   copy_bl2(BL2_START_OFFSET, BL2_SIZE_BLOC_COUNT,
> +   CONFIG_SYS_TEXT_BASE);
> +   break;
> +   default:
> +   break;
> +   }
>  }
>
>  void board_init_f(unsigned long bootflag)
> diff --git a/include/configs/smdk5250.h b/include/configs/smdk5250.h
> index 29b7ac6..4b9093c 100644
> --- a/include/configs/smdk5250.h
> +++ b/include/configs/smdk5250.h
> @@ -192,6 +192,11 @@
>  /* U-boot copy size from boot Media to DRAM.*/
>  #define BL2_START_OFFSET   (CONFIG_BL2_OFFSET/512)
>  #define BL2_SIZE_BLOC_COUNT(CONFIG_BL2_SIZE/512)
> +
> +#define OM_STAT(0x1f << 1)
> +#define EXYNOS_COPY_SPI_FNPTR_ADDR 0x02020058

Would these two be better in exynos5.h or similar? They don't seem
like a board feature?

> +#define SPI_FLASH_UBOOT_POS(CONFIG_SEC_FW_SIZE + CONFIG_BL1_SIZE)
> +
>  #define CONFIG_DOS_PARTITION
>
>  #define CONFIG_IRAM_STACK  0x0205
> --
> 1.7.4.4
>

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


Re: [U-Boot] [PATCH 7/8 V2] EXYNOS5: Enable SPI

2012-10-01 Thread Simon Glass
On Tue, Jul 31, 2012 at 4:01 AM, Rajeshwari Shinde
 wrote:
> This patch enables SPI driver for EXYNOS5.
>
> Signed-off-by: Rajeshwari Shinde 

Acked-by: Simon Glass 

> ---
> Changes in V2:
> - None.
>  board/samsung/smdk5250/smdk5250.c |3 +++
>  include/configs/smdk5250.h|   23 ++-
>  2 files changed, 25 insertions(+), 1 deletions(-)
>
> diff --git a/board/samsung/smdk5250/smdk5250.c 
> b/board/samsung/smdk5250/smdk5250.c
> index a5816e4..2848c10 100644
> --- a/board/samsung/smdk5250/smdk5250.c
> +++ b/board/samsung/smdk5250/smdk5250.c
> @@ -63,6 +63,9 @@ static int smc9115_pre_init(void)
>  int board_init(void)
>  {
> gd->bd->bi_boot_params = (PHYS_SDRAM_1 + 0x100UL);
> +#ifdef CONFIG_EXYNOS_SPI
> +   spi_init();
> +#endif
> return 0;
>  }
>
> diff --git a/include/configs/smdk5250.h b/include/configs/smdk5250.h
> index 27dab76..29b7ac6 100644
> --- a/include/configs/smdk5250.h
> +++ b/include/configs/smdk5250.h
> @@ -167,7 +167,7 @@
>  #undef CONFIG_CMD_IMLS
>  #define CONFIG_IDENT_STRING" for SMDK5250"
>
> -#define CONFIG_ENV_IS_IN_MMC
> +/*#define CONFIG_ENV_IS_IN_MMC*/
>  #define CONFIG_SYS_MMC_ENV_DEV 0
>
>  #define CONFIG_SECURE_BL1_ONLY
> @@ -216,6 +216,27 @@
>  #define CONFIG_ENV_SROM_BANK   1
>  #endif /*CONFIG_CMD_NET*/
>
> +/* SPI */
> +#define CONFIG_ENV_IS_IN_SPI_FLASH
> +#define CONFIG_SPI_FLASH
> +
> +#ifdef CONFIG_SPI_FLASH
> +#define CONFIG_EXYNOS_SPI
> +#define CONFIG_CMD_SF
> +#define CONFIG_CMD_SPI
> +#define CONFIG_SPI_FLASH_WINBOND
> +#define CONFIG_SF_DEFAULT_MODE SPI_MODE_0
> +#define CONFIG_SF_DEFAULT_SPEED5000
> +#define EXYNOS5_SPI_NUM_CONTROLLERS5
> +#endif
> +
> +#ifdef CONFIG_ENV_IS_IN_SPI_FLASH
> +#define CONFIG_ENV_SPI_MODESPI_MODE_0
> +#define CONFIG_ENV_SECT_SIZE   CONFIG_ENV_SIZE
> +#define CONFIG_ENV_SPI_BUS 1
> +#define CONFIG_ENV_SPI_MAX_HZ  5000
> +#endif
> +
>  /* Enable devicetree support */
>  #define CONFIG_OF_LIBFDT
>
> --
> 1.7.4.4
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 6/8] SPI: Add SPI Driver for EXYNOS.

2012-10-01 Thread Simon Glass
Hi,

On Tue, Jul 31, 2012 at 3:42 AM, Rajeshwari Shinde
 wrote:
> This patch adds SPI driver for EXYNOS.
>
> Signed-off-by: Simon Glass 
> Signed-off-by: Padmavathi Venna 
> Signed-off-by: Gabe Black 
> Signed-off-by: Rajeshwari Shinde 
> ---
>  arch/arm/include/asm/arch-exynos/spi.h |   78 ++
>  drivers/spi/Makefile   |1 +
>  drivers/spi/exynos_spi.c   |  400 
> 
>  3 files changed, 479 insertions(+), 0 deletions(-)
>  create mode 100644 arch/arm/include/asm/arch-exynos/spi.h
>  create mode 100644 drivers/spi/exynos_spi.c
>
> diff --git a/arch/arm/include/asm/arch-exynos/spi.h 
> b/arch/arm/include/asm/arch-exynos/spi.h
> new file mode 100644
> index 000..7cab1e9
> --- /dev/null
> +++ b/arch/arm/include/asm/arch-exynos/spi.h
> @@ -0,0 +1,78 @@
> +/*
> + * (C) Copyright 2012 SAMSUNG Electronics
> + * Padmavathi Venna 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
> + */
> +
> +#ifndef __ASM_ARCH_EXYNOS_COMMON_SPI_H_
> +#define __ASM_ARCH_EXYNOS_COMMON_SPI_H_
> +
> +#ifndef __ASSEMBLY__
> +
> +/* SPI peripheral register map; padded to 64KB */
> +struct exynos_spi {
> +   unsigned intch_cfg; /* 0x00 */
> +   unsigned char   reserved0[4];
> +   unsigned intmode_cfg;   /* 0x08 */
> +   unsigned intcs_reg; /* 0x0c */
> +   unsigned char   reserved1[4];
> +   unsigned intspi_sts;/* 0x14 */
> +   unsigned inttx_data;/* 0x18 */
> +   unsigned intrx_data;/* 0x1c */
> +   unsigned intpkt_cnt;/* 0x20 */
> +   unsigned char   reserved2[4];
> +   unsigned char   reserved3[4];
> +   unsigned intfb_clk; /* 0x2c */
> +   unsigned char   padding[0xffd0];
> +};
> +
> +#define EXYNOS_SPI_MAX_FREQ5000
> +
> +#define SPI_TIMEOUT_MS 10
> +
> +/* SPI_CHCFG */
> +#define SPI_CH_HS_EN   (1 << 6)
> +#define SPI_CH_RST (1 << 5)
> +#define SPI_SLAVE_MODE (1 << 4)
> +#define SPI_CH_CPOL_L  (1 << 3)
> +#define SPI_CH_CPHA_B  (1 << 2)
> +#define SPI_RX_CH_ON   (1 << 1)
> +#define SPI_TX_CH_ON   (1 << 0)
> +
> +/* SPI_MODECFG */
> +#define SPI_MODE_CH_WIDTH_WORD (0x2 << 29)
> +#define SPI_MODE_BUS_WIDTH_WORD(0x2 << 17)
> +
> +/* SPI_CSREG */
> +#define SPI_SLAVE_SIG_INACT(1 << 0)
> +
> +/* SPI_STS */
> +#define SPI_ST_TX_DONE (1 << 25)
> +#define SPI_FIFO_LVL_MASK  0x1ff
> +#define SPI_TX_LVL_OFFSET  6
> +#define SPI_RX_LVL_OFFSET  15
> +
> +/* Feedback Delay */
> +#define SPI_CLK_BYPASS (0 << 0)
> +#define SPI_FB_DELAY_90(1 << 0)
> +#define SPI_FB_DELAY_180   (2 << 0)
> +#define SPI_FB_DELAY_270   (3 << 0)
> +
> +/* Packet Count */
> +#define SPI_PACKET_CNT_EN  (1 << 16)
> +
> +#endif /* __ASSEMBLY__ */
> +#endif
> diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
> index c20f1f2..f15adf0 100644
> --- a/drivers/spi/Makefile
> +++ b/drivers/spi/Makefile
> @@ -33,6 +33,7 @@ COBJS-$(CONFIG_ATMEL_SPI) += atmel_spi.o
>  COBJS-$(CONFIG_BFIN_SPI) += bfin_spi.o
>  COBJS-$(CONFIG_CF_SPI) += cf_spi.o
>  COBJS-$(CONFIG_DAVINCI_SPI) += davinci_spi.o
> +COBJS-$(CONFIG_EXYNOS_SPI) += exynos_spi.o
>  COBJS-$(CONFIG_KIRKWOOD_SPI) += kirkwood_spi.o
>  COBJS-$(CONFIG_MPC52XX_SPI) += mpc52xx_spi.o
>  COBJS-$(CONFIG_MPC8XXX_SPI) += mpc8xxx_spi.o
> diff --git a/drivers/spi/exynos_spi.c b/drivers/spi/exynos_spi.c
> new file mode 100644
> index 000..73fb447
> --- /dev/null
> +++ b/drivers/spi/exynos_spi.c
> @@ -0,0 +1,400 @@
> +/*
> + * (C) Copyright 2012 SAMSUNG Electronics
> + * Padmavathi Venna 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Publi

Re: [U-Boot] [PATCH 4/8 V2] EXYNOS5: Add base address for SPI.

2012-10-01 Thread Simon Glass
On Tue, Jul 31, 2012 at 4:00 AM, Rajeshwari Shinde
 wrote:
> Signed-off-by: Rajeshwari Shinde 

Acked-by: Simon Glass 
> ---
> Changes in V2:
> - None
>  arch/arm/include/asm/arch-exynos/cpu.h |6 ++
>  1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/include/asm/arch-exynos/cpu.h 
> b/arch/arm/include/asm/arch-exynos/cpu.h
> index 0e6ea87..89c2dd3 100644
> --- a/arch/arm/include/asm/arch-exynos/cpu.h
> +++ b/arch/arm/include/asm/arch-exynos/cpu.h
> @@ -51,11 +51,13 @@
>  #define EXYNOS4_UART_BASE  0x1380
>  #define EXYNOS4_I2C_BASE   0x1386
>  #define EXYNOS4_ADC_BASE   0x1391
> +#define EXYNOS4_SPI_BASE   0x1392
>  #define EXYNOS4_PWMTIMER_BASE  0x139D
>  #define EXYNOS4_MODEM_BASE 0x13A0
>  #define EXYNOS4_USBPHY_CONTROL 0x10020704
>
>  #define EXYNOS4_GPIO_PART4_BASEDEVICE_NOT_AVAILABLE
> +#define EXYNOS4_SPI_ISP_BASE   DEVICE_NOT_AVAILABLE
>
>  /* EXYNOS5 */
>  #define EXYNOS5_I2C_SPACING0x1
> @@ -80,7 +82,9 @@
>  #define EXYNOS5_SROMC_BASE 0x1225
>  #define EXYNOS5_UART_BASE  0x12C0
>  #define EXYNOS5_I2C_BASE   0x12C6
> +#define EXYNOS5_SPI_BASE   0x12D2
>  #define EXYNOS5_PWMTIMER_BASE  0x12DD
> +#define EXYNOS5_SPI_ISP_BASE   0x131A
>  #define EXYNOS5_GPIO_PART2_BASE0x1340
>  #define EXYNOS5_FIMD_BASE  0x1440
>
> @@ -170,6 +174,8 @@ SAMSUNG_BASE(usb_ehci, USB_HOST_EHCI_BASE)
>  SAMSUNG_BASE(usb_otg, USBOTG_BASE)
>  SAMSUNG_BASE(watchdog, WATCHDOG_BASE)
>  SAMSUNG_BASE(power, POWER_BASE)
> +SAMSUNG_BASE(spi, SPI_BASE)
> +SAMSUNG_BASE(spi_isp, SPI_ISP_BASE)
>  #endif
>
>  #endif /* _EXYNOS4_CPU_H */
> --
> 1.7.4.4
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 2/8 V2] SPI: Add W25Q32 to Winbond SPI flash table

2012-10-01 Thread Simon Glass
+MikeF

On Tue, Jul 31, 2012 at 4:00 AM, Rajeshwari Shinde
 wrote:
> SMDK EVT1  has a different Winbond part added its part details
> to the SPI flash table.
>
> Signed-off-by: Abhilash Kesavan 
> Signed-off-by: Rajeshwari Shinde 

Acked-by: Simon Glass 

> ---
> Changes in V2:
> - Corrected the commit message.
>  drivers/mtd/spi/winbond.c |8 
>  1 files changed, 8 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/mtd/spi/winbond.c b/drivers/mtd/spi/winbond.c
> index c20faa2..b345efc 100644
> --- a/drivers/mtd/spi/winbond.c
> +++ b/drivers/mtd/spi/winbond.c
> @@ -107,6 +107,14 @@ static const struct winbond_spi_flash_params 
> winbond_spi_flash_table[] = {
> .nr_blocks  = 256,
> .name   = "W25Q128",
> },
> +   {
> +   .id = 0x5014,
> +   .l2_page_size   = 8,
> +   .pages_per_sector   = 16,
> +   .sectors_per_block  = 16,
> +   .nr_blocks  = 128,
> +   .name   = "W25Q80",
> +   },
>  };
>
>  static int winbond_erase(struct spi_flash *flash, u32 offset, size_t len)
> --
> 1.7.4.4
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 1/8 V2] EXYNOS5: Add pinmux support for SPI

2012-10-01 Thread Simon Glass
Hi,

I haven't seen any more comments on this series, nor has it been
applied so far as I can see. Any word?

On Tue, Jul 31, 2012 at 4:00 AM, Rajeshwari Shinde
 wrote:
> This patch adds pinmux support for SPI channels
>
> Signed-off-by: Rajeshwari Shinde 

Acked-by: Simon Glass 

> ---
> Changes in V2:
> - None.
>  arch/arm/cpu/armv7/exynos/pinmux.c|   51 
> -
>  arch/arm/include/asm/arch-exynos/periph.h |5 +++
>  arch/arm/include/asm/arch-exynos/pinmux.h |3 ++
>  3 files changed, 58 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/cpu/armv7/exynos/pinmux.c 
> b/arch/arm/cpu/armv7/exynos/pinmux.c
> index 7776add..13f75e0 100644
> --- a/arch/arm/cpu/armv7/exynos/pinmux.c
> +++ b/arch/arm/cpu/armv7/exynos/pinmux.c
> @@ -230,6 +230,49 @@ static void exynos5_i2c_config(int peripheral, int flags)
> }
>  }
>
> +void exynos5_spi_config(int peripheral)
> +{
> +   int cfg = 0, pin = 0, i;
> +   struct s5p_gpio_bank *bank = NULL;
> +   struct exynos5_gpio_part1 *gpio1 =
> +   (struct exynos5_gpio_part1 *) samsung_get_base_gpio_part1();
> +   struct exynos5_gpio_part2 *gpio2 =
> +   (struct exynos5_gpio_part2 *) samsung_get_base_gpio_part2();
> +
> +   switch (peripheral) {
> +   case PERIPH_ID_SPI0:
> +   bank = &gpio1->a2;
> +   cfg = GPIO_FUNC(0x2);
> +   pin = 0;
> +   break;
> +   case PERIPH_ID_SPI1:
> +   bank = &gpio1->a2;
> +   cfg = GPIO_FUNC(0x2);
> +   pin = 4;
> +   break;
> +   case PERIPH_ID_SPI2:
> +   bank = &gpio1->b1;
> +   cfg = GPIO_FUNC(0x5);
> +   pin = 1;
> +   break;
> +   case PERIPH_ID_SPI3:
> +   bank = &gpio2->f1;
> +   cfg = GPIO_FUNC(0x2);
> +   pin = 0;
> +   break;
> +   case PERIPH_ID_SPI4:
> +   for (i = 2; i < 4; i++)
> +   s5p_gpio_cfg_pin(&gpio2->f0, i, GPIO_FUNC(0x4));
> +   for (i = 4; i < 6; i++)
> +   s5p_gpio_cfg_pin(&gpio2->e0, i, GPIO_FUNC(0x4));
> +   break;
> +   }
> +   if (peripheral != PERIPH_ID_SPI4) {
> +   for (i = pin; i < pin + 4; i++)
> +   s5p_gpio_cfg_pin(bank, i, cfg);
> +   }
> +}
> +
>  static int exynos5_pinmux_config(int peripheral, int flags)
>  {
> switch (peripheral) {
> @@ -257,11 +300,17 @@ static int exynos5_pinmux_config(int peripheral, int 
> flags)
> case PERIPH_ID_I2C7:
> exynos5_i2c_config(peripheral, flags);
> break;
> +   case PERIPH_ID_SPI0:
> +   case PERIPH_ID_SPI1:
> +   case PERIPH_ID_SPI2:
> +   case PERIPH_ID_SPI3:
> +   case PERIPH_ID_SPI4:
> +   exynos5_spi_config(peripheral);
> +   break;
> default:
> debug("%s: invalid peripheral %d", __func__, peripheral);
> return -1;
> }
> -

I think U-Boot likes to keep a blank line before the 'return' at the
end of a function.

> return 0;
>  }
>
> diff --git a/arch/arm/include/asm/arch-exynos/periph.h 
> b/arch/arm/include/asm/arch-exynos/periph.h
> index b861d7d..dafc3f3 100644
> --- a/arch/arm/include/asm/arch-exynos/periph.h
> +++ b/arch/arm/include/asm/arch-exynos/periph.h
> @@ -43,6 +43,11 @@ enum periph_id {
> PERIPH_ID_SDMMC2,
> PERIPH_ID_SDMMC3,
> PERIPH_ID_SROMC,
> +   PERIPH_ID_SPI0,
> +   PERIPH_ID_SPI1,
> +   PERIPH_ID_SPI2,
> +   PERIPH_ID_SPI3,
> +   PERIPH_ID_SPI4,
> PERIPH_ID_UART0,
> PERIPH_ID_UART1,
> PERIPH_ID_UART2,
> diff --git a/arch/arm/include/asm/arch-exynos/pinmux.h 
> b/arch/arm/include/asm/arch-exynos/pinmux.h
> index 10ea736..57c80be 100644
> --- a/arch/arm/include/asm/arch-exynos/pinmux.h
> +++ b/arch/arm/include/asm/arch-exynos/pinmux.h
> @@ -36,6 +36,9 @@ enum {
> /* Flags for eMMC */
> PINMUX_FLAG_8BIT_MODE   = 1 << 0,   /* SDMMC 8-bit mode */
>
> +   /* Flag for SPI */
> +   PINMUX_FLAG_SLAVE_MODE  = 1 << 0,   /* Slave mode */
> +
> /* Flags for SROM controller */
> PINMUX_FLAG_BANK= 3 << 0,   /* bank number (0-3) */
> PINMUX_FLAG_16BIT   = 1 << 2,   /* 16-bit width */
> --
> 1.7.4.4
>

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


Re: [U-Boot] [PATCH v2 1/2] tegra: clean up board include hell

2012-10-01 Thread Simon Glass
On Sat, Sep 29, 2012 at 1:02 PM, Lucas Stach  wrote:
> The prototypes used in board files were all scattered out, which lead to
> code duplication between SPL and normal U-Boot and some prototypes not 
> actually
> being used. Consolidate this in a common board header.
>
> Signed-off-by: Lucas Stach 
> ---
> v2: remove wrong paragraph about how to move ahead in the commit message
> ---
>  arch/arm/cpu/arm720t/tegra-common/board.h | 25 -
>  arch/arm/cpu/arm720t/tegra-common/spl.c   |  2 +-
>  arch/arm/cpu/tegra-common/board.c |  1 +
>  arch/arm/include/asm/arch-tegra/board.h   | 19 +++-
>  board/nvidia/common/board.c   |  1 -
>  board/nvidia/common/board.h   | 37 
> ---
>  board/nvidia/common/uart-spi-switch.c |  2 +-
>  7 Dateien geändert, 21 Zeilen hinzugefügt(+), 66 Zeilen entfernt(-)
>  delete mode 100644 arch/arm/cpu/arm720t/tegra-common/board.h
>  delete mode 100644 board/nvidia/common/board.h

Acked-by: Simon Glass 

>
> diff --git a/arch/arm/cpu/arm720t/tegra-common/board.h 
> b/arch/arm/cpu/arm720t/tegra-common/board.h
> deleted file mode 100644
> index 260767d..000
> --- a/arch/arm/cpu/arm720t/tegra-common/board.h
> +++ /dev/null
> @@ -1,25 +0,0 @@
> -/*
> - * (C) Copyright 2010-2011
> - * NVIDIA Corporation 
> - *
> - * See file CREDITS for list of people who contributed to this
> - * project.
> - *
> - * This program is free software; you can redistribute it and/or
> - * modify it under the terms of the GNU General Public License as
> - * published by the Free Software Foundation; either version 2 of
> - * the License, or (at your option) any later version.
> - *
> - * This program is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> - * GNU General Public License for more details.
> - *
> - * You should have received a copy of the GNU General Public License
> - * along with this program; if not, write to the Free Software
> - * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
> - * MA 02111-1307 USA
> - */
> -
> -void board_init_uart_f(void);
> -void gpio_early_init_uart(void);
> diff --git a/arch/arm/cpu/arm720t/tegra-common/spl.c 
> b/arch/arm/cpu/arm720t/tegra-common/spl.c
> index dfe36b9..0d37ce8 100644
> --- a/arch/arm/cpu/arm720t/tegra-common/spl.c
> +++ b/arch/arm/cpu/arm720t/tegra-common/spl.c
> @@ -33,13 +33,13 @@
>  #include 
>  #include 
>  #include 
> -#include "board.h"
>  #include "cpu.h"
>
>  #include 
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/arch/arm/cpu/tegra-common/board.c 
> b/arch/arm/cpu/tegra-common/board.c
> index ff90a52..b2e10c6 100644
> --- a/arch/arm/cpu/tegra-common/board.c
> +++ b/arch/arm/cpu/tegra-common/board.c
> @@ -26,6 +26,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/arch/arm/include/asm/arch-tegra/board.h 
> b/arch/arm/include/asm/arch-tegra/board.h
> index a90d36c..7e56df7 100644
> --- a/arch/arm/include/asm/arch-tegra/board.h
> +++ b/arch/arm/include/asm/arch-tegra/board.h
> @@ -24,7 +24,24 @@
>  #ifndef _TEGRA_BOARD_H_
>  #define _TEGRA_BOARD_H_
>
> -/* Setup UARTs for the board according to the selected config */
> +/* Set up pinmux to make UART usable */
> +void gpio_config_uart(void);  /* CONFIG_SPI_UART_SWITCH */
> +void gpio_early_init_uart(void);  /*!CONFIG_SPI_UART_SWITCH */
> +
> +/* Set up early UART output */
>  void board_init_uart_f(void);
>
> +/* Set up any early GPIOs the board might need for proper operation */
> +void gpio_early_init(void);  /* overrideable GPIO config*/
> +
> +/*
> + * Hooks to allow boards to set up the pinmux for a specific function.
> + * Has to be implemented in the board files as we don't yet support pinmux
> + * setup from FTD. If a board file does not implement one of those functions
> + * an empty stub function will be called.
> + */
> +
> +void pin_mux_usb(void);  /* overrideable USB pinmux setup   */
> +void pin_mux_spi(void);  /* overrideable SPI pinmux setup   */
> +
>  #endif
> diff --git a/board/nvidia/common/board.c b/board/nvidia/common/board.c
> index bd194bc..dc301e7 100644
> --- a/board/nvidia/common/board.c
> +++ b/board/nvidia/common/board.c
> @@ -39,7 +39,6 @@
>  #include 
>  #include 
>  #include 
> -#include "board.h"
>  #include "emc.h"
>
>  DECLARE_GLOBAL_DATA_PTR;
> diff --git a/board/nvidia/common/board.h b/board/nvidia/common/board.h
> deleted file mode 100644
> index dada4c4..000
> --- a/board/nvidia/common/board.h
> +++ /dev/null
> @@ -1,37 +0,0 @@
> -/*
> - *  (C) Copyright 2010,2011
> - *  NVIDIA Corporation 
> - *
> - * See file CREDITS for list of people who contributed to this
> - * project.
> - *
> - * This program is free software; you can redistribute it and/or
> - * modify it under the terms of

Re: [U-Boot] [PATCH] mx6qsabreauto: Add Ethernet support

2012-10-01 Thread Fabio Estevam
Hi Stefano,

On Tue, Sep 25, 2012 at 3:43 PM, Fabio Estevam
 wrote:
> mx6qsabreauto has a AR8031 Gigabit PHY.
>
> Add support for it.
>
> Signed-off-by: Fabio Estevam 

Any comments on this one. please?

Regards,

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


[U-Boot] Please pull u-boot-ti/master

2012-10-01 Thread Tom Rini
Hello,

The following changes since commit 1c27059a2f7158a9c9a8778535b030935d75179d:

  Merge remote-tracking branch 'u-boot/master' (2012-09-30 23:49:17 +0200)

are available in the git repository at:


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

for you to fetch changes up to 3c2e616f4b20e6e23d8268e99beec91b95ce9e70:

  omap4_panda: remove CONFIG_PANDA, not used (2012-10-01 10:10:33 -0700)


Andreas Bie??mann (1):
  devkit8000: add rootwait to mmcboot option

Bastian Ruppert (6):
  davinci: ea20: reorganisation LCD startup
  davinci: ea20: the console is always set to the serial line
  video: cfb_console: logo can be positioned via the splashpos variable
  video: cfb_console: add function to plot the logo area black
  da850/omap-l138: davinci_emac: Suppress auto negotiation if needed
  davinci: ea20: add some configs and default environmet variables

Ilya Yanok (4):
  net/bootp: add VCI support for BOOTP also
  OMAP: spl: call timer_init() from SPL
  am335x_evm: enable networking in SPL
  OMAP: networking support for SPL

Joel A Fernandes (1):
  am33xx: Fix fetching of mmc1 bootmode from bootrom for AM33XX

Koen Kooi (1):
  am335x-evm config: decrease bootdelay to 1s and mount rootfs RO

Peter Meerwald (1):
  omap4_panda: remove CONFIG_PANDA, not used

 arch/arm/cpu/armv7/omap-common/lowlevel_init.S |5 +-
 arch/arm/include/asm/arch-am33xx/spl.h |2 +
 board/davinci/ea20/ea20.c  |   32 --
 board/ti/beagle/beagle.c   |2 +-
 common/Makefile|4 +
 common/cmd_nvedit.c|8 ++
 common/env_common.c|7 +-
 common/spl/Makefile|1 +
 common/spl/spl.c   |   11 ++
 common/spl/spl_net.c   |   52 +
 drivers/net/davinci_emac.c |3 +-
 drivers/video/cfb_console.c|  140 +++-
 include/bootstage.h|6 +-
 include/config_uncmd_spl.h |   44 
 include/configs/am335x_evm.h   |9 +-
 include/configs/devkit8000.h   |1 +
 include/configs/ea20.h |  108 +++---
 include/configs/omap4_panda.h  |1 -
 include/spl.h  |3 +
 lib/Makefile   |9 +-
 lib/hashtable.c|2 +
 mkconfig   |1 +
 net/bootp.c|   27 -
 spl/Makefile   |3 +
 24 files changed, 384 insertions(+), 97 deletions(-)
 create mode 100644 common/spl/spl_net.c
 create mode 100644 include/config_uncmd_spl.h

While we are late in the series, these changes have been around for a
long while now and the primary delay in merging them has been to wait
for the rest of my SPL series to hit, make its way up and let me merge
that with these changes.

-- 
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] help with archos g9 "port"

2012-10-01 Thread SxDx
> From: "SxDx" 
> Dear U-Boot hackers,
> 
> I am trying to let U-Boot work with my archos g9
> (omap4430 based-tablet).

Just for the record. Applying the patch found at:
http://forum.xda-developers.com/showpost.php?p=30011253
against the linaro tree lets me load a linux kernel uImage
and run it (I stopped tracing things after the decompression
of the kernel, but things seem fine so far).
Issue solved (for u-boot; now I'll see what's going on
in the kernel...).
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 70/72 V2] serial: Remove CONFIG_SERIAL_MULTI from remaining sources

2012-10-01 Thread Marek Vasut
Remove the parts depending either on disabled CONFIG_SERIAL_MULTI
or ifdefs around CONFIG_SERIAL_MULTI parts since CONFIG_SERIAL_MULTI
is now enabled by default.

Signed-off-by: Marek Vasut 
Cc: Marek Vasut 
Cc: Tom Rini 
Cc: Anatolij Gustschin 
Cc: Stefan Roese 
---
 arch/arm/lib/board.c |2 --
 arch/blackfin/lib/board.c|2 --
 arch/m68k/lib/board.c|2 --
 arch/microblaze/lib/board.c  |2 --
 arch/nds32/lib/board.c   |2 --
 arch/powerpc/lib/board.c |2 --
 arch/sandbox/lib/board.c |2 --
 arch/x86/lib/board.c |2 --
 common/cmd_nvedit.c  |2 --
 common/fdt_support.c |6 ++
 common/iomux.c   |2 --
 common/stdio.c   |2 --
 include/common.h |   12 
 include/serial.h |2 +-
 post/board/pdm360ng/coproc_com.c |3 ---
 15 files changed, 3 insertions(+), 42 deletions(-)

V2: Fix compiler warning about unused fdt_fill_multisername

diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
index 109a1ac..0b47ab3 100644
--- a/arch/arm/lib/board.c
+++ b/arch/arm/lib/board.c
@@ -492,9 +492,7 @@ void board_init_r(gd_t *id, ulong dest_addr)
 #ifdef CONFIG_CLOCKS
set_cpu_clk_info(); /* Setup clock information */
 #endif
-#ifdef CONFIG_SERIAL_MULTI
serial_initialize();
-#endif
 
debug("Now running in RAM - U-Boot at: %08lx\n", dest_addr);
 
diff --git a/arch/blackfin/lib/board.c b/arch/blackfin/lib/board.c
index c380d27..0b31f37 100644
--- a/arch/blackfin/lib/board.c
+++ b/arch/blackfin/lib/board.c
@@ -284,9 +284,7 @@ void board_init_f(ulong bootflag)
init_baudrate();
serial_early_puts("Serial init\n");
serial_init();
-#ifdef CONFIG_SERIAL_MULTI
serial_initialize();
-#endif
serial_early_puts("Console init flash\n");
console_init_f();
serial_early_puts("End of early debugging\n");
diff --git a/arch/m68k/lib/board.c b/arch/m68k/lib/board.c
index 2add630..67c9a13 100644
--- a/arch/m68k/lib/board.c
+++ b/arch/m68k/lib/board.c
@@ -401,9 +401,7 @@ void board_init_r (gd_t *id, ulong dest_addr)
 
gd->flags |= GD_FLG_RELOC;  /* tell others: relocation done */
 
-#ifdef CONFIG_SERIAL_MULTI
serial_initialize();
-#endif
 
debug ("Now running in RAM - U-Boot at: %08lx\n", dest_addr);
 
diff --git a/arch/microblaze/lib/board.c b/arch/microblaze/lib/board.c
index 674b573..efd63cd 100644
--- a/arch/microblaze/lib/board.c
+++ b/arch/microblaze/lib/board.c
@@ -108,9 +108,7 @@ void board_init_f(ulong not_used)
 */
mem_malloc_init (CONFIG_SYS_MALLOC_BASE, CONFIG_SYS_MALLOC_LEN);
 
-#ifdef CONFIG_SERIAL_MULTI
serial_initialize();
-#endif
 
for (init_fnc_ptr = init_sequence; *init_fnc_ptr; ++init_fnc_ptr) {
WATCHDOG_RESET ();
diff --git a/arch/nds32/lib/board.c b/arch/nds32/lib/board.c
index 17d3ee0..89900fe 100644
--- a/arch/nds32/lib/board.c
+++ b/arch/nds32/lib/board.c
@@ -324,9 +324,7 @@ void board_init_r(gd_t *id, ulong dest_addr)
(ulong)(&__u_boot_cmd_end - &__u_boot_cmd_start));
 #endif /* defined(CONFIG_NEEDS_MANUAL_RELOC) */
 
-#ifdef CONFIG_SERIAL_MULTI
serial_initialize();
-#endif
 
debug("Now running in RAM - U-Boot at: %08lx\n", dest_addr);
 
diff --git a/arch/powerpc/lib/board.c b/arch/powerpc/lib/board.c
index 07feaf5..b860141 100644
--- a/arch/powerpc/lib/board.c
+++ b/arch/powerpc/lib/board.c
@@ -672,9 +672,7 @@ void board_init_r(gd_t *id, ulong dest_addr)
gd->env_addr += dest_addr - CONFIG_SYS_MONITOR_BASE;
 #endif
 
-#ifdef CONFIG_SERIAL_MULTI
serial_initialize();
-#endif
 
debug("Now running in RAM - U-Boot at: %08lx\n", dest_addr);
 
diff --git a/arch/sandbox/lib/board.c b/arch/sandbox/lib/board.c
index c173bf9..83858c1 100644
--- a/arch/sandbox/lib/board.c
+++ b/arch/sandbox/lib/board.c
@@ -220,9 +220,7 @@ void board_init_r(gd_t *id, ulong dest_addr)
 
gd->flags |= GD_FLG_RELOC;  /* tell others: relocation done */
 
-#ifdef CONFIG_SERIAL_MULTI
serial_initialize();
-#endif
 
 #ifdef CONFIG_POST
post_output_backlog();
diff --git a/arch/x86/lib/board.c b/arch/x86/lib/board.c
index 90cf7fc..e5caf13 100644
--- a/arch/x86/lib/board.c
+++ b/arch/x86/lib/board.c
@@ -150,9 +150,7 @@ init_fnc_t *init_sequence_r[] = {
timer_init,
display_banner,
display_dram_config,
-#ifdef CONFIG_SERIAL_MULTI
serial_initialize_r,
-#endif
 #ifndef CONFIG_SYS_NO_FLASH
flash_init_r,
 #endif
diff --git a/common/cmd_nvedit.c b/common/cmd_nvedit.c
index 3474bc6..1d67f20 100644
--- a/common/cmd_nvedit.c
+++ b/common/cmd_nvedit.c
@@ -237,10 +237,8 @@ int env_check_apply(const char *name, const char *oldval,
if (console_assign(console, newval) < 0)
return 1;
 
-#ifdef CONFIG_SERIAL_MULTI
if (serial_assign(newval

[U-Boot] [PATCH 25/72 V2] serial: powerpc: Implement CONFIG_SERIAL_MULTI into mpc8260 serial drivers

2012-10-01 Thread Marek Vasut
Implement support for CONFIG_SERIAL_MULTI into both SCC and SMC mpc8260
serial drivers. These drivers were so far only usable directly, but this
patch also adds support for the multi method. This allows using more than
one serial driver alongside the mpc8260 drivers. Also, add a weak
implementation of default_serial_console() returning this driver.

Signed-off-by: Marek Vasut 
Cc: Marek Vasut 
Cc: Tom Rini 
Cc: Anatolij Gustschin 
Cc: Stefan Roese 
---
 arch/powerpc/cpu/mpc8260/serial_scc.c |   71 -
 arch/powerpc/cpu/mpc8260/serial_smc.c |   71 -
 common/serial.c   |4 ++
 3 files changed, 124 insertions(+), 22 deletions(-)

V2: Fix driver name too long problem

diff --git a/arch/powerpc/cpu/mpc8260/serial_scc.c 
b/arch/powerpc/cpu/mpc8260/serial_scc.c
index 4ab6a28..7bfd420 100644
--- a/arch/powerpc/cpu/mpc8260/serial_scc.c
+++ b/arch/powerpc/cpu/mpc8260/serial_scc.c
@@ -31,6 +31,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -82,7 +84,7 @@ DECLARE_GLOBAL_DATA_PTR;
 
 #endif
 
-int serial_init (void)
+static int mpc8260_scc_serial_init(void)
 {
volatile immap_t *im = (immap_t *)CONFIG_SYS_IMMR;
volatile scc_t *sp;
@@ -180,8 +182,7 @@ int serial_init (void)
return (0);
 }
 
-void
-serial_setbrg (void)
+static void mpc8260_scc_serial_setbrg(void)
 {
 #if defined(CONFIG_CONS_USE_EXTC)
m8260_cpm_extcbrg(SCC_INDEX, gd->baudrate,
@@ -191,8 +192,7 @@ serial_setbrg (void)
 #endif
 }
 
-void
-serial_putc(const char c)
+static void mpc8260_scc_serial_putc(const char c)
 {
volatile scc_uart_t *up;
volatile cbd_t  *tbdf;
@@ -217,16 +217,14 @@ serial_putc(const char c)
tbdf->cbd_sc |= BD_SC_READY;
 }
 
-void
-serial_puts (const char *s)
+static void mpc8260_scc_serial_puts(const char *s)
 {
while (*s) {
serial_putc (*s++);
}
 }
 
-int
-serial_getc(void)
+static int mpc8260_scc_serial_getc(void)
 {
volatile cbd_t  *rbdf;
volatile scc_uart_t *up;
@@ -250,8 +248,7 @@ serial_getc(void)
return (c);
 }
 
-int
-serial_tstc()
+static int mpc8260_scc_serial_tstc(void)
 {
volatile cbd_t  *rbdf;
volatile scc_uart_t *up;
@@ -264,6 +261,58 @@ serial_tstc()
return ((rbdf->cbd_sc & BD_SC_EMPTY) == 0);
 }
 
+#ifdef CONFIG_SERIAL_MULTI
+static struct serial_device mpc8260_scc_serial_drv = {
+   .name   = "mpc8260_scc_uart",
+   .start  = mpc8260_scc_serial_init,
+   .stop   = NULL,
+   .setbrg = mpc8260_scc_serial_setbrg,
+   .putc   = mpc8260_scc_serial_putc,
+   .puts   = mpc8260_scc_serial_puts,
+   .getc   = mpc8260_scc_serial_getc,
+   .tstc   = mpc8260_scc_serial_tstc,
+};
+
+void mpc8260_scc_serial_initialize(void)
+{
+   serial_register(&mpc8260_scc_serial_drv);
+}
+
+__weak struct serial_device *default_serial_console(void)
+{
+   return &mpc8260_scc_serial_drv;
+}
+#else
+int serial_init(void)
+{
+   return mpc8260_scc_serial_init();
+}
+
+void serial_setbrg(void)
+{
+   mpc8260_scc_serial_setbrg();
+}
+
+void serial_putc(const char c)
+{
+   mpc8260_scc_serial_putc(c);
+}
+
+void serial_puts(const char *s)
+{
+   mpc8260_scc_serial_puts(s);
+}
+
+int serial_getc(void)
+{
+   return mpc8260_scc_serial_getc();
+}
+
+int serial_tstc(void)
+{
+   return mpc8260_scc_serial_tstc();
+}
+#endif
 #endif /* CONFIG_CONS_ON_SCC */
 
 #if defined(CONFIG_KGDB_ON_SCC)
diff --git a/arch/powerpc/cpu/mpc8260/serial_smc.c 
b/arch/powerpc/cpu/mpc8260/serial_smc.c
index 7b6eaba..0f3b834 100644
--- a/arch/powerpc/cpu/mpc8260/serial_smc.c
+++ b/arch/powerpc/cpu/mpc8260/serial_smc.c
@@ -33,6 +33,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -91,7 +93,7 @@ static unsigned char brg_map[] = {
3,  /* BRG1 for SCC4 */
 };
 
-int serial_init (void)
+static int mpc8260_smc_serial_init(void)
 {
volatile immap_t *im = (immap_t *)CONFIG_SYS_IMMR;
volatile smc_t *sp;
@@ -183,8 +185,7 @@ int serial_init (void)
return (0);
 }
 
-void
-serial_setbrg (void)
+static void mpc8260_smc_serial_setbrg(void)
 {
 #if defined(CONFIG_CONS_USE_EXTC)
m8260_cpm_extcbrg(brg_map[SMC_INDEX], gd->baudrate,
@@ -194,8 +195,7 @@ serial_setbrg (void)
 #endif
 }
 
-void
-serial_putc(const char c)
+static void mpc8260_smc_serial_putc(const char c)
 {
volatile smc_uart_t *up;
volatile immap_t*im = (immap_t *)CONFIG_SYS_IMMR;
@@ -216,16 +216,14 @@ serial_putc(const char c)
rtx->txbd.cbd_sc |= BD_SC_READY;
 }
 
-void
-serial_puts (const char *s)
+static void mpc8260_smc_serial_puts(const char *s)
 {
while (*s) {
serial_putc (*s++);
}
 }
 
-int
-serial_getc(void)
+static int mpc8260_smc_serial_getc(void)
 {
volatile smc_uart_t *up;
volatile immap_t   

Re: [U-Boot] v2012.10-rc2 is now released

2012-10-01 Thread Tom Rini
On Mon, Oct 01, 2012 at 11:53:39PM +0200, Michael Walle wrote:
> Hi Tom,
> 
> Am Montag 01 Oktober 2012, 18:59:18 schrieb Tom Rini:
> > - Other pull requests of either fixes or things posted by the original
> >   merge window closure that hadn't been picked up yet AND are obviously
> >   correct or important bug fixes.  Otherwise we can hold them off for
> >   the next branches.
> 
> Did you see this?
> 
> http://patchwork.ozlabs.org/patch/188165/
> 
> I don't know if the tag (for-rc) i used was right. In case you already saw 
> this, i'm excusing for the noise ;)

I have this flagged locally if Albert and Prafulla don't pick it up in
time.

-- 
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] v2012.10-rc2 is now released

2012-10-01 Thread Michael Walle
Hi Tom,

Am Montag 01 Oktober 2012, 18:59:18 schrieb Tom Rini:
> - Other pull requests of either fixes or things posted by the original
>   merge window closure that hadn't been picked up yet AND are obviously
>   correct or important bug fixes.  Otherwise we can hold them off for
>   the next branches.

Did you see this?

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

I don't know if the tag (for-rc) i used was right. In case you already saw 
this, i'm excusing for the noise ;)

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


[U-Boot] [PATCH] SPL: Remove setting GD_FLG_RELOC in preloader_console_init()

2012-10-01 Thread Tom Rini
We have not strictly speaking relocated at this point, do not claim that
we have.  This is not required for output.

Signed-off-by: Tom Rini 
---
 common/spl/spl.c |1 -
 1 file changed, 1 deletion(-)

diff --git a/common/spl/spl.c b/common/spl/spl.c
index c640f87..3a19a63 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -222,7 +222,6 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
 void preloader_console_init(void)
 {
gd->bd = &bdata;
-   gd->flags |= GD_FLG_RELOC;
gd->baudrate = CONFIG_BAUDRATE;
 
serial_init();  /* serial communications setup */
-- 
1.7.9.5

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


Re: [U-Boot] [PATCH] TQM8xx: adjust linker script to grown code size

2012-10-01 Thread Marek Vasut
Dear Wolfgang Denk,

> Dear Marek Vasut,
> 
> In message <201209271520.33571.ma...@denx.de> you wrote:
> > Dear Wolfgang Denk,
> > 
> > > Some of the previous changes caused the code to grow, which causes
> > > errors like
> > > 
> > > u-boot.lds:76 cannot move location counter backwards (from 4000828c to
> > > 40008000)
> > > 
> > > when building with some older tool chains (like ELDK 4.2).
> > > Adjust the linker script to make fit again.
> > 
> > [...]
> > 
> > I ain't no expert, but didn't this happen on TQM85xx ?
> 
> No.
> 
> TQM85xx is a different issue (here the image size has grown, which
> would require to change the whole memory map). I'll rather remove
> these boards.

But these are important powerpc boards, no ?

> Best regards,
> 
> Wolfgang Denk

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


Re: [U-Boot] [PATCH] TQM8xx: adjust linker script to grown code size

2012-10-01 Thread Wolfgang Denk
Dear Marek Vasut,

In message <201209271520.33571.ma...@denx.de> you wrote:
> Dear Wolfgang Denk,
> 
> > Some of the previous changes caused the code to grow, which causes
> > errors like
> > 
> > u-boot.lds:76 cannot move location counter backwards (from 4000828c to
> > 40008000)
> > 
> > when building with some older tool chains (like ELDK 4.2).
> > Adjust the linker script to make fit again.
> [...]
> 
> I ain't no expert, but didn't this happen on TQM85xx ?

No.

TQM85xx is a different issue (here the image size has grown, which
would require to change the whole memory map). I'll rather remove
these boards.

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
PROGRAM - n.  A magic spell cast over a computer  allowing it to turn
one's input into error messages.
v. tr. - To engage in a pastime similar to banging one's head against
a wall, but with fewer opportunities for reward.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] pull request for u-boot-tegra/next into ARM next

2012-10-01 Thread Tom Warren
Albert,

Please pull u-boot-tegra/next into ARM next as per the discussion
currently on-going with Lucas Stach on the list. Thanks!

./MAKEALL -s tegra20 runs OK, and checkpatch.pl is clean except for 1
bogus warning about a macro needing parens.

The following changes since commit 1c27059a2f7158a9c9a8778535b030935d75179d:
  Albert ARIBAUD (1):
Merge remote-tracking branch 'u-boot/master'

are available in the git repository at:

  git://git.denx.de/u-boot-tegra next

Lucas Stach (6):
  tegra20: complete periph_id enum
  tegra20: add clock_set_pllout function
  tegra20: rework UART GPIO handling
  tegra: add funcmux entry for NAND attached to KBC
  tegra: clean up board include hell
  tegra: nand: add board pinmux

Stephen Warren (1):
  tegra: enable CONFIG_CMD_PART

Thierry Reding (2):
  tegra: Update Avionic Design vendor prefix
  tegra: Rename Medcom to Medcom-Wide

Tom Warren (2):
  Tegra20: Move some code files to common directories for upcoming
Tegra30 patches.
  Tegra20: Move some include files to arch-tegra for sharing with Tegra30

 MAINTAINERS|2 +-
 Makefile   |2 +
 arch/arm/cpu/arm720t/tegra-common/Makefile |   47 +++
 .../cpu/arm720t/{tegra20 => tegra-common}/cpu.h|0
 .../cpu/arm720t/{tegra20 => tegra-common}/spl.c|   18 +-
 arch/arm/cpu/arm720t/tegra20/Makefile  |1 -
 arch/arm/cpu/arm720t/tegra20/cpu.c |   12 +-
 arch/arm/cpu/armv7/tegra-common/Makefile   |   48 +++
 .../armv7/{tegra20 => tegra-common}/cmd_enterrcm.c |4 +-
 arch/arm/cpu/armv7/tegra20/Makefile|1 -
 arch/arm/cpu/armv7/tegra20/usb.c   |8 +-
 arch/arm/cpu/tegra-common/Makefile |   48 +++
 .../{tegra20-common/ap20.c => tegra-common/ap.c}   |   12 +-
 .../cpu/{tegra20-common => tegra-common}/board.c   |9 +-
 .../lowlevel_init.S|0
 .../{tegra20-common => tegra-common}/sys_info.c|0
 .../cpu/{tegra20-common => tegra-common}/timer.c   |4 +-
 arch/arm/cpu/tegra20-common/Makefile   |3 +-
 arch/arm/cpu/tegra20-common/clock.c|   47 +++-
 arch/arm/cpu/tegra20-common/emc.c  |4 +-
 arch/arm/cpu/tegra20-common/funcmux.c  |   19 +-
 arch/arm/cpu/tegra20-common/pinmux.c   |4 +-
 arch/arm/cpu/tegra20-common/pmu.c  |8 +-
 arch/arm/cpu/tegra20-common/warmboot.c |   18 +-
 arch/arm/cpu/tegra20-common/warmboot_avp.c |   14 +-
 .../asm/{arch-tegra20/ap20.h => arch-tegra/ap.h}   |0
 arch/arm/include/asm/arch-tegra/board.h|   48 +++
 .../asm/{arch-tegra20 => arch-tegra}/clk_rst.h |   11 +-
 arch/arm/include/asm/arch-tegra/clock.h|  265 +
 .../asm/{arch-tegra20 => arch-tegra}/fuse.h|0
 .../arm/include/asm/arch-tegra/gpio.h  |   27 +-
 .../include/asm/{arch-tegra20 => arch-tegra}/mmc.h |0
 .../include/asm/{arch-tegra20 => arch-tegra}/pmc.h |0
 .../include/asm/{arch-tegra20 => arch-tegra}/scu.h |0
 .../asm/{arch-tegra20 => arch-tegra}/sys_proto.h   |0
 .../{arch-tegra20/tegra20.h => arch-tegra/tegra.h} |   14 +-
 .../asm/{arch-tegra20 => arch-tegra}/tegra_i2c.h   |4 +-
 .../asm/{arch-tegra20 => arch-tegra}/tegra_mmc.h   |0
 .../asm/{arch-tegra20 => arch-tegra}/tegra_spi.h   |0
 .../asm/{arch-tegra20 => arch-tegra}/timer.h   |0
 .../asm/{arch-tegra20 => arch-tegra}/uart.h|0
 .../asm/{arch-tegra20 => arch-tegra}/warmboot.h|0
 arch/arm/include/asm/arch-tegra20/board.h  |   30 --
 arch/arm/include/asm/arch-tegra20/clock-tables.h   |  196 ++
 arch/arm/include/asm/arch-tegra20/clock.h  |  388 +---
 arch/arm/include/asm/arch-tegra20/funcmux.h|1 +
 arch/arm/include/asm/arch-tegra20/gpio.h   |   22 +-
 .../board.h => include/asm/arch-tegra20/tegra.h}   |   17 +-
 board/avionic-design/common/tamonten.c |   20 +-
 ...{tegra20-medcom.dts => tegra20-medcom-wide.dts} |2 +-
 board/avionic-design/dts/tegra20-plutux.dts|2 +-
 board/avionic-design/dts/tegra20-tec.dts   |2 +-
 .../{medcom => medcom-wide}/Makefile   |0
 board/compal/paz00/paz00.c |   11 +-
 board/compulab/trimslice/trimslice.c   |   13 +-
 board/nvidia/common/board.c|   42 ++-
 board/nvidia/common/emc.c  |8 +-
 board/nvidia/common/uart-spi-switch.c  |6 +-
 board/nvidia/harmony/harmony.c |   11 +-
 board/nvidia/seaboard/seaboard.c   |6 +-
 board/nvidia/whistler/whistler.c   |   13 +-
 boards.cfg |2 +-
 drivers/gpio/tegra_gpio.c 

Re: [U-Boot] [PATCH v2 1/2] tegra: clean up board include hell

2012-10-01 Thread Tom Warren
Lucas,

On Mon, Oct 1, 2012 at 10:23 AM, Lucas Stach  wrote:
> Hi Tom,
>
> Am Montag, den 01.10.2012, 10:12 -0700 schrieb Tom Warren:
>> Lucas, Stephen, et al.
>>
>> On Mon, Oct 1, 2012 at 9:39 AM, Tom Warren  wrote:
>> > Lucas,
>> >
>> > On Mon, Oct 1, 2012 at 9:24 AM, Stephen Warren  
>> > wrote:
>> >> On 09/29/2012 02:02 PM, Lucas Stach wrote:
>> >>> The prototypes used in board files were all scattered out, which lead to
>> >>> code duplication between SPL and normal U-Boot and some prototypes not 
>> >>> actually
>> >>> being used. Consolidate this in a common board header.
>> >>
>> >> Seems reasonable enough to me. This series or anything similar that's
>> >> also OK with Tom is:
>> >> Acked-by: Stephen Warren 
>> >>
>> >
>> > I don't think this hurts anything. I'll see if it applies cleanly to
>> > u-boot-tegra/next and let you know.
>> >
>> > Tom
>>
>> I've applied Lucas' include file cleanup patches, and done a .MAKEALL
>> -s tegra20 and a checkpatch run w/o error, so I've pushed a new
>> u-boot-tegra/next to denx.de.
>>
>> Here are the latest commits in that repo since Albert's last ARM update:
>>
>> 0edfb9c tegra: nand: add board pinmux
>> a05feff tegra: clean up board include hell
>> 9c53038 tegra: add funcmux entry for NAND attached to KBC
>> 08eb412 tegra20: rework UART GPIO handling
>> 55da8d1 tegra20: add clock_set_pllout function
>> 20e825f tegra20: complete periph_id enum
>> b1ae54d tegra: enable CONFIG_CMD_PART
>> 0e1b95c Tegra20: Move some include files to arch-tegra for sharing with 
>> Tegra30
>> bfba961 Tegra20: Move some code files to common directories for upcoming 
>> Tegra30
>> 4910a5c tegra: Rename Medcom to Medcom-Wide
>> 81637cd tegra: Update Avionic Design vendor prefix
>>
>> This is what I'm going to base my imminent T30 patches on. Hope to
>> have something for review in a day or two.
>>
> Can you do a P-R to Albert to include this in the u-boot-arm/next tree?
>
> The reason I'm prodding is that we need the following two patches to
> propagate to the u-boot-usb/next tree, to make the the USB driver move
> feasible.
> 0e1b95c Tegra20: Move some include files to arch-tegra for sharing with 
> Tegra30
> bfba961 Tegra20: Move some code files to common directories for upcoming 
> Tegra30
>
> As the u-boot/next tree is already open for merging I think the best way
> to achieve this is to let it trickle upstream, so that Marek can just
> base his next tree on an updated version of u-boot/next. There is no
> reason to to wait for the Tegra 3 work to land, except if you plan to
> rework the two mentioned commits along the way.
>
> Thanks,
> Lucas
>

I usually issue pull requests for u-boot-tegra/master to ARM master.
I'll do one for u-boot-tegra/next to ARM next and see what Albert
says.

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


Re: [U-Boot] [PATCH v3] mx25: Clean up lowlevel_init

2012-10-01 Thread Benoît Thébaudeau
Hi Stefano,

On Sunday, September 30, 2012 3:47:12 PM, Benoît Thébaudeau wrote:
> Hi Stefano,
> 
> On Sunday, September 30, 2012 3:04:14 PM, Stefano Babic wrote:
> > On 20/08/2012 21:00, Benoît Thébaudeau wrote:
> > > Clean up mx25 lowlevel_init:
> > >  - Add comments.
> > >  - Do not use write32 repeatedly with the same value in order not
> > >  to increase
> > >code size.
> > >  - Make register values configurable.
> > >  - Use macro parameters with default values instead of literal
> > >  constants.
> > >  - Use defined macros instead of duplicating code.
> > > 
> > > Signed-off-by: Benoît Thébaudeau 
> > > Cc: Stefano Babic 
> > > Cc: John Rigby 
> > > Cc: Matthias Weisser 
> > > ---
> > 
> > Hi Benoît,
> > 
> > > Changes for v2:
> > >  - Use macro arguments with default values instead of #define's.
> > > Changes for v3:
> > >  - Fix comment for default MAX MPR value.
> > > 
> > >  .../arch/arm/include/asm/arch-mx25/macro.h |   87
> > >  +++-
> > >  .../board/karo/tx25/lowlevel_init.S|   34
> > >  +---
> > >  2 files changed, 68 insertions(+), 53 deletions(-)
> > > 
> > > diff --git
> > > u-boot-4d3c95f.orig/arch/arm/include/asm/arch-mx25/macro.h
> > > u-boot-4d3c95f/arch/arm/include/asm/arch-mx25/macro.h
> > > index 3b694da..56cae36 100644
> > > --- u-boot-4d3c95f.orig/arch/arm/include/asm/arch-mx25/macro.h
> > > +++ u-boot-4d3c95f/arch/arm/include/asm/arch-mx25/macro.h
> > > @@ -32,32 +32,75 @@
> > >  
> > >  #include 
> > >  #include 
> > > +#include 
> > >  
> > > -.macro init_aips
> > > - write32 IMX_AIPS1_BASE + AIPS_MPR_0_7, 0x
> > > - write32 IMX_AIPS1_BASE + AIPS_MPR_8_15, 0x
> > > - write32 IMX_AIPS2_BASE + AIPS_MPR_0_7, 0x
> > > - write32 IMX_AIPS2_BASE + AIPS_MPR_8_15, 0x
> > > +/*
> > > + * AIPS setup - Only setup MPROTx registers.
> > > + * The PACR default values are good.
> > > + *
> > > + * Default argument values:
> > > + *  - MPR: Set all MPROTx to be non-bufferable, trusted for R/W,
> > > not forced to
> > > + *user-mode.
> > > + */
> > > +.macro init_aips mpr=0x
> > > + ldr r0, =IMX_AIPS1_BASE
> > > + ldr r1, =\mpr
> > > + str r1, [r0, #AIPS_MPR_0_7]
> > > + str r1, [r0, #AIPS_MPR_8_15]
> > > + ldr r2, =IMX_AIPS2_BASE
> > > + str r1, [r2, #AIPS_MPR_0_7]
> > > + str r1, [r2, #AIPS_MPR_8_15]
> > >  .endm
> > >  
> > > -.macro init_max
> > > - write32 IMX_MAX_BASE + MAX_MPR0, 0x43210
> > > - write32 IMX_MAX_BASE + MAX_MPR1, 0x43210
> > > - write32 IMX_MAX_BASE + MAX_MPR2, 0x43210
> > > - write32 IMX_MAX_BASE + MAX_MPR3, 0x43210
> > > - write32 IMX_MAX_BASE + MAX_MPR4, 0x43210
> > > -
> > > - write32 IMX_MAX_BASE + MAX_SGPCR0, 0x10
> > > - write32 IMX_MAX_BASE + MAX_SGPCR1, 0x10
> > > - write32 IMX_MAX_BASE + MAX_SGPCR2, 0x10
> > > - write32 IMX_MAX_BASE + MAX_SGPCR3, 0x10
> > > - write32 IMX_MAX_BASE + MAX_SGPCR4, 0x10
> > > +/*
> > > + * MAX (Multi-Layer AHB Crossbar Switch) setup
> > > + *
> > > + * Default argument values:
> > > + *  - MPR: priority is IAHB > DAHB > USBOTG > RTIC > eSDHC2/SDMA
> > > + *  - SGPCR: always park on last master
> > > + *  - MGPCR: restore default values
> > > + */
> > > +.macro init_max mpr=0x00043210, sgpcr=0x0010,
> > > mgpcr=0x
> > > + ldr r0, =IMX_MAX_BASE
> > > + ldr r1, =\mpr
> > > + str r1, [r0, #MAX_MPR0] /* for S0 */
> > > + str r1, [r0, #MAX_MPR1] /* for S1 */
> > > + str r1, [r0, #MAX_MPR2] /* for S2 */
> > > + str r1, [r0, #MAX_MPR3] /* for S3 */
> > > + str r1, [r0, #MAX_MPR4] /* for S4 */
> > > + ldr r1, =\sgpcr
> > > + str r1, [r0, #MAX_SGPCR0]   /* for S0 */
> > > + str r1, [r0, #MAX_SGPCR1]   /* for S1 */
> > > + str r1, [r0, #MAX_SGPCR2]   /* for S2 */
> > > + str r1, [r0, #MAX_SGPCR3]   /* for S3 */
> > > + str r1, [r0, #MAX_SGPCR4]   /* for S4 */
> > > + ldr r1, =\mgpcr
> > > + str r1, [r0, #MAX_MGPCR0]   /* for M0 */
> > > + str r1, [r0, #MAX_MGPCR1]   /* for M1 */
> > > + str r1, [r0, #MAX_MGPCR2]   /* for M2 */
> > > + str r1, [r0, #MAX_MGPCR3]   /* for M3 */
> > > + str r1, [r0, #MAX_MGPCR4]   /* for M4 */
> > > +.endm
> > >  
> > > - write32 IMX_MAX_BASE + MAX_MGPCR0, 0x0
> > > - write32 IMX_MAX_BASE + MAX_MGPCR1, 0x0
> > > - write32 IMX_MAX_BASE + MAX_MGPCR2, 0x0
> > > - write32 IMX_MAX_BASE + MAX_MGPCR3, 0x0
> > > - write32 IMX_MAX_BASE + MAX_MGPCR4, 0x0
> > > +/*
> > > + * M3IF setup
> > > + *
> > > + * Default argument values:
> > > + *  - CTL:
> > > + * MRRP[0] = LCDC on priority list (1 << 0)  = 
> > > 0x0001
> > > + * MRRP[1] = MAX1 not on priority list (0 << 1)  = 
> > > 0x
> > > + * MRRP[2] = MAX0 not on priority list (0 << 2)  = 
> > > 0x
> > > + * MRRP[3] = USBH not on priority list (0 << 3)  = 
> > > 0x
> > > + * MRRP[4] = SDMA not on priority list (0 << 4)  = 
> > > 0x
> > >

Re: [U-Boot] Has anyone gotten the mmc commands to work on the NOVSOMTMi.MX6Q-SL-1-D, on the NOVPEK board by Novtech?

2012-10-01 Thread Fabio Estevam
On Mon, Oct 1, 2012 at 4:12 PM, Greg Topmiller  wrote:
> Yes, it seems to be working but let me do some more testing.  I want to make 
> sure it boots to Linux properly with mmc, Ethernet, and usb.  I would need to 
> create a new board name as well.  How about mx6qnovpek?

Yes, it looks good.

Regards,

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


Re: [U-Boot] Has anyone gotten the mmc commands to work on the NOVSOMTMi.MX6Q-SL-1-D, on the NOVPEK board by Novtech?

2012-10-01 Thread Fabio Estevam
On Mon, Oct 1, 2012 at 4:03 PM, Greg Topmiller  wrote:
> Thanks for the hint.  I didn't have the pad settings for sdhc1 and sdhc2.  I 
> still had some other problems but they were config differences in the 
> include/configs/mx6qarm2.h file.

Is it working now? Would you care to add support for this board in
mainline U-boot?

Regards,

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


[U-Boot] [PATCH v2] mxc: Fix SDHC multi-instance clock

2012-10-01 Thread Benoît Thébaudeau
On mxc, each SDHC instance has a dedicated clock, so gd->sdhc_clk is not
suitable for the multi-instance use case (initialization made directly with
fsl_esdhc_initialize()).

This patch fixes this issue by adding a configuration field for the SDHC input
clock frequency.

Signed-off-by: Benoît Thébaudeau 
Cc: Stefano Babic 
Cc: Eric Bénard 
Cc: Otavio Salvador 
Cc: Fabio Estevam 
Cc: Jason Liu 
Cc: Matt Sealey 
Cc: Andy Fleming 
---
This patch should be applied after (series of series...):
http://patchwork.ozlabs.org/patch/187467/
http://patchwork.ozlabs.org/patch/187468/
http://patchwork.ozlabs.org/patch/187475/

This patch supersedes http://patchwork.ozlabs.org/patch/187476/ .

Changes for v2:
 - Since this patch will go to /next, extend the original patch with the mxc
   boards newly added to this branch: mx6qsabreauto and mx6qsabresd.

 .../board/esg/ima3-mx53/ima3-mx53.c|1 +
 .../board/freescale/mx35pdk/mx35pdk.c  |2 ++
 .../board/freescale/mx51evk/mx51evk.c  |4 
 .../board/freescale/mx53ard/mx53ard.c  |4 
 .../board/freescale/mx53evk/mx53evk.c  |4 
 .../board/freescale/mx53loco/mx53loco.c|3 +++
 .../board/freescale/mx53smd/mx53smd.c  |3 +++
 .../board/freescale/mx6qarm2/mx6qarm2.c|4 
 .../board/freescale/mx6qsabreauto/mx6qsabreauto.c  |1 +
 .../board/freescale/mx6qsabrelite/mx6qsabrelite.c  |3 +++
 .../board/freescale/mx6qsabresd/mx6qsabresd.c  |1 +
 .../board/genesi/mx51_efikamx/efikamx.c|4 
 .../board/ttcontrol/vision2/vision2.c  |2 ++
 .../drivers/mmc/fsl_esdhc.c|5 +++--
 .../include/fsl_esdhc.h|1 +
 15 files changed, 40 insertions(+), 2 deletions(-)

diff --git u-boot-imx-next-5cddb49.orig/board/esg/ima3-mx53/ima3-mx53.c 
u-boot-imx-next-5cddb49/board/esg/ima3-mx53/ima3-mx53.c
index e947330..41d6bb6 100644
--- u-boot-imx-next-5cddb49.orig/board/esg/ima3-mx53/ima3-mx53.c
+++ u-boot-imx-next-5cddb49/board/esg/ima3-mx53/ima3-mx53.c
@@ -217,6 +217,7 @@ int board_mmc_init(bd_t *bis)
PAD_CTL_HYS_ENABLE | PAD_CTL_DRV_HIGH | PAD_CTL_PUE_PULL |
PAD_CTL_PKE_ENABLE | PAD_CTL_HYS_ENABLE | PAD_CTL_47K_PU);
 
+   esdhc_cfg.sdhc_clk = mxc_get_clock(MXC_ESDHC_CLK);
return fsl_esdhc_initialize(bis, &esdhc_cfg);
 }
 #endif
diff --git u-boot-imx-next-5cddb49.orig/board/freescale/mx35pdk/mx35pdk.c 
u-boot-imx-next-5cddb49/board/freescale/mx35pdk/mx35pdk.c
index 7cb6b30..a12531f 100644
--- u-boot-imx-next-5cddb49.orig/board/freescale/mx35pdk/mx35pdk.c
+++ u-boot-imx-next-5cddb49/board/freescale/mx35pdk/mx35pdk.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -292,6 +293,7 @@ int board_mmc_init(bd_t *bis)
mxc_request_iomux(MX35_PIN_SD1_DATA2, MUX_CONFIG_FUNC);
mxc_request_iomux(MX35_PIN_SD1_DATA3, MUX_CONFIG_FUNC);
 
+   esdhc_cfg.sdhc_clk = mxc_get_clock(MXC_ESDHC1_CLK);
return fsl_esdhc_initialize(bis, &esdhc_cfg);
 }
 
diff --git u-boot-imx-next-5cddb49.orig/board/freescale/mx51evk/mx51evk.c 
u-boot-imx-next-5cddb49/board/freescale/mx51evk/mx51evk.c
index a94701c..3412952 100644
--- u-boot-imx-next-5cddb49.orig/board/freescale/mx51evk/mx51evk.c
+++ u-boot-imx-next-5cddb49/board/freescale/mx51evk/mx51evk.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -358,6 +359,9 @@ int board_mmc_init(bd_t *bis)
u32 index;
s32 status = 0;
 
+   esdhc_cfg[0].sdhc_clk = mxc_get_clock(MXC_ESDHC_CLK);
+   esdhc_cfg[1].sdhc_clk = mxc_get_clock(MXC_ESDHC2_CLK);
+
for (index = 0; index < CONFIG_SYS_FSL_ESDHC_NUM;
index++) {
switch (index) {
diff --git u-boot-imx-next-5cddb49.orig/board/freescale/mx53ard/mx53ard.c 
u-boot-imx-next-5cddb49/board/freescale/mx53ard/mx53ard.c
index 08c7795..2fc8570 100644
--- u-boot-imx-next-5cddb49.orig/board/freescale/mx53ard/mx53ard.c
+++ u-boot-imx-next-5cddb49/board/freescale/mx53ard/mx53ard.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -106,6 +107,9 @@ int board_mmc_init(bd_t *bis)
u32 index;
s32 status = 0;
 
+   esdhc_cfg[0].sdhc_clk = mxc_get_clock(MXC_ESDHC_CLK);
+   esdhc_cfg[1].sdhc_clk = mxc_get_clock(MXC_ESDHC2_CLK);
+
for (index = 0; index < CONFIG_SYS_FSL_ESDHC_NUM; index++) {
switch (index) {
case 0:
diff --git u-boot-imx-next-5cddb49.orig/board/freescale/mx53evk/mx53evk.c 
u-boot-imx-next-5cddb49/board/freescale/mx53evk/mx53evk.c
index b11a94c..bb4621d 100644
--- u-boot-imx-next-5cddb49.orig/board/freescale/mx53evk/mx53evk.c
+++ u-boot-imx-next-5cddb49/board/freescale/mx53evk/mx53evk.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 

Re: [U-Boot] [PATCH 4/6] [v2] powerpc/85xx: Add P5040 processor support

2012-10-01 Thread Kim Phillips
On Mon, 1 Oct 2012 09:06:41 -0500
Timur Tabi  wrote:

> Add support for the Freescale P5040 SOC, which is similar to the P5020.
> Features of the P5040 are:
> 
> Four P5040 single-threaded e5500 cores built
> Up to 2.4 GHz with 64-bit ISA support
> Three levels of instruction: user, supervisor, hypervisor
> CoreNet platform cache (CPC)
> 2.0 MB configures as dual 1 MB blocks hierarchical interconnect fabric
> Two 64-bit DDR3/3L SDRAM memory controllers with ECC and interleaving
> support Up to 1600MT/s
> Memory pre-fetch engine
> DPAA incorporating acceleration for the following functions
> Packet parsing, classification, and distribution (FMAN)
> Queue management for scheduling, packet sequencing and
> congestion management (QMAN)
> Hardware buffer management for buffer allocation and
> de-allocation (BMAN)
> Cryptography acceleration (SEC 5.2) at up to 40 Gbps SerDes
> 20 lanes at up to 5 Gbps
> Supports SGMII, XAUI, PCIe rev1.1/2.0, SATA Ethernet interfaces
> Two 10 Gbps Ethernet MACs
> Ten 1 Gbps Ethernet MACs
> High-speed peripheral interfaces
> Two PCI Express 2.0/3.0 controllers
> Additional peripheral interfaces
> Two serial ATA (SATA 2.0) controllers
> Two high-speed USB 2.0 controllers with integrated PHY
> Enhanced secure digital host controller (SD/MMC/eMMC)
> Enhanced serial peripheral interface (eSPI)
> Two I2C controllers
> Four UARTs
> Integrated flash controller supporting NAND and NOR flash
> DMA
> Dual four channel
> Support for hardware virtualization and partitioning enforcement
> Extra privileged level for hypervisor support
> QorIQ Trust Architecture 1.1
> Secure boot, secure debug, tamper detection, volatile key storage

same comment as I made before - make this marketing text relevant to
u-boot, e.g., list what devices this patch supports.

> +struct liodn_id_table sec_liodn_tbl[] = {
> + SET_SEC_JR_LIODN_ENTRY(0, 129, 130),
> + SET_SEC_JR_LIODN_ENTRY(1, 131, 132),
> + SET_SEC_JR_LIODN_ENTRY(2, 133, 134),
> + SET_SEC_JR_LIODN_ENTRY(3, 135, 136),
> + SET_SEC_RTIC_LIODN_ENTRY(a, 154),
> + SET_SEC_RTIC_LIODN_ENTRY(b, 155),
> + SET_SEC_RTIC_LIODN_ENTRY(c, 156),
> + SET_SEC_RTIC_LIODN_ENTRY(d, 157),
> + SET_SEC_DECO_LIODN_ENTRY(0, 97, 98),
> + SET_SEC_DECO_LIODN_ENTRY(1, 99, 100),
> +};

NACK - the SEC in the p5040 has four DECOs, not two.

Kim

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


Re: [U-Boot] [PATCH 2/2] spi: Add SPI flash test

2012-10-01 Thread Tom Rini
On Fri, Sep 28, 2012 at 05:28:01PM -0700, Simon Glass wrote:

> It is useful to have a basic SPI flash test, which tests that the SPI chip,
> the SPI bus and the driver are behaving.
> 
> This test erases part of the flash, writes data and reads it back as a
> sanity check that all is well.
> 
> Use CONFIG_SF_TEST to enable it.
> 
> Signed-off-by: Simon Glass 
> ---
>  README  |5 ++
>  common/cmd_sf.c |  160 
> +++
>  2 files changed, 165 insertions(+), 0 deletions(-)
> 
> diff --git a/README b/README
> index 5793b0a..8f601ae 100644
> --- a/README
> +++ b/README
> @@ -2309,6 +2309,11 @@ The following options need to be configured:
>   CONFIG_SF_DEFAULT_MODE  (see include/spi.h)
>   CONFIG_SF_DEFAULT_SPEED in Hz
>  
> + CONFIG_CMD_SF_TEST
> +
> + Define this option to include a destructive SPI flash
> + test ('sf test').
> +

Lets make this note as well that it is of course a destructive test.

[snip]
> +static int do_spi_flash_test(void)
> +{
> + /* TODO(s...@chromium.org): Support cmdline parameters for these */

Lets just add that now? :)  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 v2 1/2] tegra: clean up board include hell

2012-10-01 Thread Lucas Stach
Hi Tom,

Am Montag, den 01.10.2012, 10:12 -0700 schrieb Tom Warren:
> Lucas, Stephen, et al.
> 
> On Mon, Oct 1, 2012 at 9:39 AM, Tom Warren  wrote:
> > Lucas,
> >
> > On Mon, Oct 1, 2012 at 9:24 AM, Stephen Warren  
> > wrote:
> >> On 09/29/2012 02:02 PM, Lucas Stach wrote:
> >>> The prototypes used in board files were all scattered out, which lead to
> >>> code duplication between SPL and normal U-Boot and some prototypes not 
> >>> actually
> >>> being used. Consolidate this in a common board header.
> >>
> >> Seems reasonable enough to me. This series or anything similar that's
> >> also OK with Tom is:
> >> Acked-by: Stephen Warren 
> >>
> >
> > I don't think this hurts anything. I'll see if it applies cleanly to
> > u-boot-tegra/next and let you know.
> >
> > Tom
> 
> I've applied Lucas' include file cleanup patches, and done a .MAKEALL
> -s tegra20 and a checkpatch run w/o error, so I've pushed a new
> u-boot-tegra/next to denx.de.
> 
> Here are the latest commits in that repo since Albert's last ARM update:
> 
> 0edfb9c tegra: nand: add board pinmux
> a05feff tegra: clean up board include hell
> 9c53038 tegra: add funcmux entry for NAND attached to KBC
> 08eb412 tegra20: rework UART GPIO handling
> 55da8d1 tegra20: add clock_set_pllout function
> 20e825f tegra20: complete periph_id enum
> b1ae54d tegra: enable CONFIG_CMD_PART
> 0e1b95c Tegra20: Move some include files to arch-tegra for sharing with 
> Tegra30
> bfba961 Tegra20: Move some code files to common directories for upcoming 
> Tegra30
> 4910a5c tegra: Rename Medcom to Medcom-Wide
> 81637cd tegra: Update Avionic Design vendor prefix
> 
> This is what I'm going to base my imminent T30 patches on. Hope to
> have something for review in a day or two.
> 
Can you do a P-R to Albert to include this in the u-boot-arm/next tree?

The reason I'm prodding is that we need the following two patches to
propagate to the u-boot-usb/next tree, to make the the USB driver move
feasible.
0e1b95c Tegra20: Move some include files to arch-tegra for sharing with Tegra30
bfba961 Tegra20: Move some code files to common directories for upcoming Tegra30

As the u-boot/next tree is already open for merging I think the best way
to achieve this is to let it trickle upstream, so that Marek can just
base his next tree on an updated version of u-boot/next. There is no
reason to to wait for the Tegra 3 work to land, except if you plan to
rework the two mentioned commits along the way.

Thanks,
Lucas

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


Re: [U-Boot] [PATCH 0/4] Keyboard input improvements

2012-10-01 Thread Tom Rini
On Thu, Sep 27, 2012 at 06:18:39PM -0700, Simon Glass wrote:

> This is a small series of patches to improve keyboard input for matrix
> keyboards:
> 
> - Fix an fdt decoding bug which breaks seaboard
> - Permit key repeat/delay to be altered after init
> - Allow key ghosting filter to be enabled/disabled
> - Add a bit more debugging
> 
> Since this series mostly affects tegra I suggest that it goes through
> the tegra tree.
> 
> 
> Simon Glass (4):
>   input: Correct key_matrix fdt decoding
>   input: Separate out keyboard repeat/delay from init
>   input: Allow key ghosting filter to be disabled
>   input: Add debugging for key matrix key codes
> 
>  drivers/input/input.c  |   13 +
>  drivers/input/key_matrix.c |   22 --
>  drivers/input/tegra-kbc.c  |7 ---
>  include/input.h|   14 ++
>  include/key_matrix.h   |5 -
>  5 files changed, 43 insertions(+), 18 deletions(-)

Things look fine to me and if you want I'd be OK with this going into
u-boot/next, assuming it applies there cleanly.

-- 
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] Has anyone gotten the mmc commands to work on the NOVSOMTMi.MX6Q-SL-1-D, on the NOVPEK board by Novtech?

2012-10-01 Thread Fabio Estevam
On Mon, Oct 1, 2012 at 2:10 PM, Greg Topmiller  wrote:
> Hi Fabio,
>
> To clarify, Novtech's NOVPEK board used the mx6qarm2 board type for in the 
> Freescale u-boot which is not the correct board type.
>
> Novtech's NOVPEK board has sdhc1 connected up, not sdhc3 or sdhc4.  Do you 
> know of any power or clocking requirements specific to sdhc1 on the mx6?
>

I would suggest you to double check the iomux settings for sdhc1 on this board.

Also, if you post the changes you did for adding support for the
Novpek board it is easier for us to review and maybe come up with some
ideas.

Regards,

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


Re: [U-Boot] [PATCH v2 1/2] tegra: clean up board include hell

2012-10-01 Thread Tom Warren
Lucas, Stephen, et al.

On Mon, Oct 1, 2012 at 9:39 AM, Tom Warren  wrote:
> Lucas,
>
> On Mon, Oct 1, 2012 at 9:24 AM, Stephen Warren  wrote:
>> On 09/29/2012 02:02 PM, Lucas Stach wrote:
>>> The prototypes used in board files were all scattered out, which lead to
>>> code duplication between SPL and normal U-Boot and some prototypes not 
>>> actually
>>> being used. Consolidate this in a common board header.
>>
>> Seems reasonable enough to me. This series or anything similar that's
>> also OK with Tom is:
>> Acked-by: Stephen Warren 
>>
>
> I don't think this hurts anything. I'll see if it applies cleanly to
> u-boot-tegra/next and let you know.
>
> Tom

I've applied Lucas' include file cleanup patches, and done a .MAKEALL
-s tegra20 and a checkpatch run w/o error, so I've pushed a new
u-boot-tegra/next to denx.de.

Here are the latest commits in that repo since Albert's last ARM update:

0edfb9c tegra: nand: add board pinmux
a05feff tegra: clean up board include hell
9c53038 tegra: add funcmux entry for NAND attached to KBC
08eb412 tegra20: rework UART GPIO handling
55da8d1 tegra20: add clock_set_pllout function
20e825f tegra20: complete periph_id enum
b1ae54d tegra: enable CONFIG_CMD_PART
0e1b95c Tegra20: Move some include files to arch-tegra for sharing with Tegra30
bfba961 Tegra20: Move some code files to common directories for upcoming Tegra30
4910a5c tegra: Rename Medcom to Medcom-Wide
81637cd tegra: Update Avionic Design vendor prefix

This is what I'm going to base my imminent T30 patches on. Hope to
have something for review in a day or two.

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


Re: [U-Boot] Custodians, Maintainers and old platforms

2012-10-01 Thread Tom Rini
On Sun, Sep 30, 2012 at 05:50:42AM +0300, Stefan Kristiansson wrote:
> On Fri, Sep 21, 2012 at 05:28:18PM -0700, Tom Rini wrote:
> > Hey all,
> > 
> > (I had attempted to bcc this to all listed maintainer, but that upset
> > Google greatly.  I'll send this out manually instead later).
> > 
> > I'd like to put this out here for custodians and maintainers to
> > consider, especially in light of the device model work that's not just
> > coming but has already started being posted.
> > 
> > One of the keys to the success of U-Boot has been the number of
> > platforms that are supported.  But part of supporting platforms is
> > needing people to volunteer to maintain them long term and help with
> > testing changes and so forth.  So first of all, I've just tagged
> > v2012.10-rc1.  Please give this at least a basic test on whatever
> > platforms you're able to.
> > 
> > Second, with this, my next branch is now open and I'd like to start it
> > by asking that platforms that people wish to abandon be removed.  With
> > the device model, lots of code will need adjusting and while it's
> > mechanical in ways, it still needs to be run-time tested.  And it's
> > changes that someone must do.  I know others have suggested adding or
> > better publicizing our to-remove file.  But one of the advantages of git
> > is that it's easy to bring platforms back, should someone later wish to
> > bring it back.  But this also requires the removal to be done cleanly.
> > 
> > All of that said, I would like to stress that if you maintain a platform
> > and you wish to help with the testing and perhaps even the conversion
> > effort, no matter the age of the platform it would be welcome and
> > appreciated.
> > 
> > And finally, if everyone really wants to go another direction with old
> > platforms, I'm open to discussion of course.  I just want to miminize
> > work done on platforms that aren't active and we don't know if they will
> > come back.
> > 
> 
> This made me realise that there are two old OpenRISC patches floating
> around that hasn't been applied to mainline.
> 
> http://patchwork.ozlabs.org/patch/142511/
> http://patchwork.ozlabs.org/patch/142510/

Queued this up in patchwork, 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 6/7] lcd: Implement RLE8 bitmap decoding

2012-10-01 Thread Che-liang Chiou
Acked-by: Che-Liang Chiou 

On Fri, Sep 28, 2012 at 6:11 PM, Simon Glass  wrote:
> From: Tom Wai-Hong Tam 
>
> Add support for drawing compressed RLE8 bitmaps.
>
> Reference: http://www.digicamsoft.com/bmp/bmp.html
>
> Signed-off-by: Che-Liang Chiou 
> Signed-off-by: Tom Wai-Hong Tam 
> Signed-off-by: Simon Glass 
> ---
>  README   |5 ++
>  common/lcd.c |  144 
> ++
>  2 files changed, 149 insertions(+), 0 deletions(-)
>
> diff --git a/README b/README
> index 5793b0a..40899d9 100644
> --- a/README
> +++ b/README
> @@ -1440,6 +1440,11 @@ The following options need to be configured:
> Normally display is black on white background; define
> CONFIG_SYS_WHITE_ON_BLACK to get it inverted.
>
> +   CONFIG_LCD_BMP_RLE8
> +
> +   Support drawing of RLE8-compressed bitmaps on the LCD.
> +
> +
>  - Splash Screen Support: CONFIG_SPLASH_SCREEN
>
> If this option is set, the environment is checked for
> diff --git a/common/lcd.c b/common/lcd.c
> index 004a6be..68df6d0 100644
> --- a/common/lcd.c
> +++ b/common/lcd.c
> @@ -642,6 +642,136 @@ static void splash_align_axis(int *axis, unsigned long 
> panel_size,
>  }
>  #endif
>
> +
> +#ifdef CONFIG_LCD_BMP_RLE8
> +
> +#define BMP_RLE8_ESCAPE0
> +#define BMP_RLE8_EOL   0
> +#define BMP_RLE8_EOBMP 1
> +#define BMP_RLE8_DELTA 2
> +
> +static void draw_unencoded_bitmap(ushort **fbp, uchar *bmap, ushort *cmap,
> + int cnt)
> +{
> +   while (cnt > 0) {
> +   *(*fbp)++ = cmap[*bmap++];
> +   cnt--;
> +   }
> +}
> +
> +static void draw_encoded_bitmap(ushort **fbp, ushort c, int cnt)
> +{
> +   ushort *fb = *fbp;
> +   int cnt_8copy = cnt >> 3;
> +   cnt -= cnt_8copy << 3;
> +   while (cnt_8copy > 0) {
> +   *fb++ = c;
> +   *fb++ = c;
> +   *fb++ = c;
> +   *fb++ = c;
> +   *fb++ = c;
> +   *fb++ = c;
> +   *fb++ = c;
> +   *fb++ = c;
> +   cnt_8copy--;
> +   }
> +   while (cnt > 0) {
> +   *fb++ = c;
> +   cnt--;
> +   }
> +   (*fbp) = fb;
> +}
> +
> +/* Do not call this function directly, must be called from
> + * lcd_display_bitmap.
> + */
> +static void lcd_display_rle8_bitmap(bmp_image_t *bmp, ushort *cmap, uchar 
> *fb,
> +   int x_off, int y_off)
> +{
> +   uchar *bmap;
> +   ulong width, height;
> +   ulong cnt, runlen;
> +   int x, y;
> +   int decode = 1;
> +
> +   width = le32_to_cpu(bmp->header.width);
> +   height = le32_to_cpu(bmp->header.height);
> +   bmap = (uchar *)bmp + le32_to_cpu(bmp->header.data_offset);
> +
> +   x = 0;
> +   y = height - 1;
> +
> +   while (decode) {
> +   if (bmap[0] == BMP_RLE8_ESCAPE) {
> +   switch (bmap[1]) {
> +   case BMP_RLE8_EOL:
> +   /* end of line */
> +   bmap += 2;
> +   x = 0;
> +   y--;
> +   /* 16bpix, 2-byte per pixel, width should *2 
> */
> +   fb -= (width * 2 + lcd_line_length);
> +   break;
> +   case BMP_RLE8_EOBMP:
> +   /* end of bitmap */
> +   decode = 0;
> +   break;
> +   case BMP_RLE8_DELTA:
> +   /* delta run */
> +   x += bmap[2];
> +   y -= bmap[3];
> +   /* 16bpix, 2-byte per pixel, x should *2 */
> +   fb = (uchar *) (lcd_base + (y + y_off - 1)
> +   * lcd_line_length + (x + x_off) * 2);
> +   bmap += 4;
> +   break;
> +   default:
> +   /* unencoded run */
> +   runlen = bmap[1];
> +   bmap += 2;
> +   if (y < height) {
> +   if (x < width) {
> +   if (x + runlen > width)
> +   cnt = width - x;
> +   else
> +   cnt = runlen;
> +   draw_unencoded_bitmap(
> +   (ushort **)&fb,
> +   bmap, cmap, cnt);
> +   }
> 

[U-Boot] v2012.10-rc2 is now released

2012-10-01 Thread Tom Rini
Hey all,

I've tagged and pushed v2012.10-rc2.  It's a little later than I had
intended, but I think we're still largely on track for -rc3.  That said,
lets push -rc3 back to next monday and give a little more time between
Albert's u-boot-arm PR being merged and the tag.  Speaking of, that's
what I expect for the big changes to be between now and then:

- Albert said he plans to have a PR ready by Thursday, that needs to go
  in.
- It also NEEDS to have a resolution, for this release, for the
  ARMv7/unaligned access/gcc 4.7 (and linaro 4.6) thing.
- Other pull requests of either fixes or things posted by the original
  merge window closure that hadn't been picked up yet AND are obviously
  correct or important bug fixes.  Otherwise we can hold them off for
  the next branches.

As a reminder, the next branch is open and I haven't seen any pull
requests for that yet, aside from Marek on some of the pre-reqs for DM
work.

-- 
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 v2] tegra: add Colibri T20 board support

2012-10-01 Thread Stephen Warren
On 10/01/2012 10:48 AM, Lucas Stach wrote:
> Am Montag, den 01.10.2012, 10:33 -0600 schrieb Stephen Warren:
>> On 09/29/2012 02:03 PM, Lucas Stach wrote:
>>> This adds board support for the Toradex Colibri T20 module.
>>>
>>> Working functions:
>>> - SD card boot
>>> - USB boot
>>> - Network
>>> - NAND environment
>>
>>> diff --git a/board/toradex/colibri_t20/Makefile 
>>> b/board/toradex/colibri_t20/Makefile
>> ...
>>> +#
>>> \ No newline at end of file
>>
>> I assume that's a mistake.
>>
> Another one...
> 
>>> diff --git a/board/toradex/colibri_t20/colibri_t20.c 
>>> b/board/toradex/colibri_t20/colibri_t20.c
>>
>>> +#ifdef CONFIG_USB_EHCI_TEGRA
>>> +void pin_mux_usb(void)
>>> +{
>>> +   /* USB 1 aka Tegra USB port 3 */
>>> +   pinmux_tristate_disable(PINGRP_SPIG);
>>
>> I don't think that's muxing USB itself, but rather muxing perhaps the
>> VBUS GPIO?
>>
> That's right. I'll do a comment to make this more obvious.
> 
>>> +#ifdef CONFIG_TEGRA_MMC
>>> +int board_mmc_init(bd_t *bd)
>>> +{
>>> +   funcmux_select(PERIPH_ID_SDMMC4, FUNCMUX_SDMMC4_ATB_GMA_4_BIT);
>>> +   pinmux_tristate_disable(PINGRP_GMB);
>>
>> It might be useful to comment the tristate call like other boards, e.g.:
>>
>> /* For power GPIO PI6 */
>> pinmux_tristate_disable(PINGRP_ATA);
>>
>> so it's obvious why the call isn't done inside funcmux_select().
>>
>>> diff --git a/board/toradex/dts/tegra20-colibri_t20.dts 
>>> b/board/toradex/dts/tegra20-colibri_t20.dts
>>
>>> +   usb@c5008000 {
>>> +   nvidia,vbus-gpio = <&gpio 178 1>; /* PW2 low-active */
>>> +   };
>>
>> As an FYI, although the GPIO bindings do specify that the last cell
>> there is for GPIO flags, I'm not sure that we should rely on it. Not all
>> GPIO bindings actually have the ability to specify flags there, so if a
>> given board's GPIO is provided by some device whose GPIO binding doesn't
>> allow for flags, then it won't be possible to specify an active-low
>> GPIO, and this won't work.
>>
>> The kernel certainly doesn't actually do anything with the flags
>> argument in the EHCI driver, IIRC.
>>
>> Either we should forcibly change all GPIO bindings in the kernel to
>> require that they allow flags to be specified (probably very hard), or
>> remove the flags from the Tegra GPIO binding, and use a separate
>> property such as nvidia,vbus-gpio-active-low for this purpose.
>> Certainly, the latter form of approach has been taken in other places
>> (such as fixed regulator IIRC).
>
> You mentioned that your plan is to bring over the regulator thing from
> the kernel to u-boot. So IMHO the correct approach would be to just use
> a fixed regulator for VBUS, where we already have the active-low
> property in the binding.

Yes, that's true.

> So can we just let this sit as it is now, and agree to remove the GPIO
> active-low flag from the Tegra GPIO binding and every use of it as soon
> as we have proper regulators in u-boot?

Hmmm. I guess. I wonder how likely it is that anyone is going to get
around to cleaning up U-Boot's DT usage to match the kernel's though. At
least I can file a bug for this once the kernel is update though, so
hopefully it will happen. I do wish that U-Boot would start using
generally agreed upon bindings rather than going its own way first and
then having to be cleaned up though, although admittedly that comment
doesn't directly apply to this case.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 65/72] serial: ns16550: Rename serial.c to serial_ns16550.c

2012-10-01 Thread Tom Rini
On Sat, Sep 29, 2012 at 11:52:58PM +0200, Marek Vasut wrote:

> This serial driver had wrong name of the source file for some time
> now. The name of the driver was serial.c instead of any more logical
> and fitting name. Thus, rename the driver source file to serial_ns16550.c
> and be done with it.
> 
> Signed-off-by: Marek Vasut 
> Cc: Marek Vasut 
> Cc: Tom Rini 
> Cc: Anatolij Gustschin 
> Cc: Stefan Roese 
> Cc: Mike Frysinger 
> Cc: Michal Simek 

After checking with Marek on IRC, this is a pure rename and he just
forgot -M -C when posting the series.  So while Michal's comments about
better formatting, etc, are true, it's beyond the scope of this "just do
a rename" patch.

-- 
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 65/72] serial: ns16550: Rename serial.c to serial_ns16550.c

2012-10-01 Thread Marek Vasut
Dear Michal Simek,

[...]
> 
> Would it be better just use this structure?
> 
> #ifdef CONFIG_SYS_NS16550_COM1
> [0] = (NS16550_t)CONFIG_SYS_NS16550_COM1,
> #endif
[...]

> 
> You are using two coding styles in this file.
> One has function return value on one line and then function name
> and the second function return value on one line with function name.
> Will be good to unify it to look the same in the whole file.

Yes, wholeheartedly agree! But (!) I don't want to clean up this file in this 
patchset.

> Thanks,
> Michal

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


Re: [U-Boot] [PATCH v2] tegra: add Colibri T20 board support

2012-10-01 Thread Lucas Stach
Am Montag, den 01.10.2012, 10:33 -0600 schrieb Stephen Warren:
> On 09/29/2012 02:03 PM, Lucas Stach wrote:
> > This adds board support for the Toradex Colibri T20 module.
> > 
> > Working functions:
> > - SD card boot
> > - USB boot
> > - Network
> > - NAND environment
> 
> > diff --git a/board/toradex/colibri_t20/Makefile 
> > b/board/toradex/colibri_t20/Makefile
> ...
> > +#
> > \ No newline at end of file
> 
> I assume that's a mistake.
> 
Another one...

> > diff --git a/board/toradex/colibri_t20/colibri_t20.c 
> > b/board/toradex/colibri_t20/colibri_t20.c
> 
> > +#ifdef CONFIG_USB_EHCI_TEGRA
> > +void pin_mux_usb(void)
> > +{
> > +   /* USB 1 aka Tegra USB port 3 */
> > +   pinmux_tristate_disable(PINGRP_SPIG);
> 
> I don't think that's muxing USB itself, but rather muxing perhaps the
> VBUS GPIO?
> 
That's right. I'll do a comment to make this more obvious.

> > +#ifdef CONFIG_TEGRA_MMC
> > +int board_mmc_init(bd_t *bd)
> > +{
> > +   funcmux_select(PERIPH_ID_SDMMC4, FUNCMUX_SDMMC4_ATB_GMA_4_BIT);
> > +   pinmux_tristate_disable(PINGRP_GMB);
> 
> It might be useful to comment the tristate call like other boards, e.g.:
> 
> /* For power GPIO PI6 */
> pinmux_tristate_disable(PINGRP_ATA);
> 
> so it's obvious why the call isn't done inside funcmux_select().
> 
> > diff --git a/board/toradex/dts/tegra20-colibri_t20.dts 
> > b/board/toradex/dts/tegra20-colibri_t20.dts
> 
> > +   usb@c5008000 {
> > +   nvidia,vbus-gpio = <&gpio 178 1>; /* PW2 low-active */
> > +   };
> 
> As an FYI, although the GPIO bindings do specify that the last cell
> there is for GPIO flags, I'm not sure that we should rely on it. Not all
> GPIO bindings actually have the ability to specify flags there, so if a
> given board's GPIO is provided by some device whose GPIO binding doesn't
> allow for flags, then it won't be possible to specify an active-low
> GPIO, and this won't work.
> 
> The kernel certainly doesn't actually do anything with the flags
> argument in the EHCI driver, IIRC.
> 
> Either we should forcibly change all GPIO bindings in the kernel to
> require that they allow flags to be specified (probably very hard), or
> remove the flags from the Tegra GPIO binding, and use a separate
> property such as nvidia,vbus-gpio-active-low for this purpose.
> Certainly, the latter form of approach has been taken in other places
> (such as fixed regulator IIRC).
> 
You mentioned that your plan is to bring over the regulator thing from
the kernel to u-boot. So IMHO the correct approach would be to just use
a fixed regulator for VBUS, where we already have the active-low
property in the binding.

So can we just let this sit as it is now, and agree to remove the GPIO
active-low flag from the Tegra GPIO binding and every use of it as soon
as we have proper regulators in u-boot?

Thanks for the review,
Lucas


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


Re: [U-Boot] [PATCH v2 1/2] tegra: clean up board include hell

2012-10-01 Thread Tom Warren
Lucas,

On Mon, Oct 1, 2012 at 9:24 AM, Stephen Warren  wrote:
> On 09/29/2012 02:02 PM, Lucas Stach wrote:
>> The prototypes used in board files were all scattered out, which lead to
>> code duplication between SPL and normal U-Boot and some prototypes not 
>> actually
>> being used. Consolidate this in a common board header.
>
> Seems reasonable enough to me. This series or anything similar that's
> also OK with Tom is:
> Acked-by: Stephen Warren 
>

I don't think this hurts anything. I'll see if it applies cleanly to
u-boot-tegra/next and let you know.

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


Re: [U-Boot] Tegra USB driver movement

2012-10-01 Thread Tom Warren
Lucas,

On Sun, Sep 30, 2012 at 11:50 PM, Lucas Stach  wrote:
> Also CC'ing Albert
>
> Am Montag, den 01.10.2012, 04:17 +0200 schrieb Marek Vasut:
>> Dear Lucas Stach,
>>
>> > Hi all,
>> >
>> > now that everything involving Colibri T20 is in pretty good shape I'm
>> > moving on to some code cleanups to the U-Boot Tegra codebase.
>> >
>> > One of the big things on my list is the move of the Tegra USB driver
>> > implementation to the correct location in drivers/usb/host. In
>> > anticipation of this move all USB related changes for the next merge
>> > window have already gone through the u-boot-usb tree to minimize
>> > conflicts.
>>
>> I think I'll push them into -next once builds are done.
>>
>> > Now with the mass renaming of Tegra header files for the Tegra 3
>> > clearing we have another situation which makes the move harder to do
>> > without breaking the build of either the u-boot-usb or u-boot-tegra
>> > tree. However we can easily solve that with some proper coordination.
>> >
>> > So the  plan is a follows:
>> > The mass renaming of the Tegra header files did not generate any back
>> > push from developers involved in Tegra. So if Tom is confident that this
>> > change is good to go, I would like him to do a pull request to
>> > u-boot-arm as soon as possible.
I've been working on getting T30 upstreamed almost full-time, and I
haven't done much work on u-boot-tegra/next.

Let me take a look at your patches and see how they line up w/my T30
work, and I'll get back to you soon.

Tom

>> > On IRC Albert already expressed his plan
>> > to do another pull request to u-boot master by Thursday latest. If we
>> > could get in the mass rename into this pull request it would be really
>> > great, as it would allow to sync the u-boot-usb tree with the current
>> > Tegra work in the next week. Once this is done we can easily move the
>> > Tegra USB driver without breaking anything.
>> >
>> > Would this be ok with everyone?
>>
>> Sorry, all the usb changes go to -next.
>>
> Right all things that we are talking about here are going into the
> respective next trees. Sorry for the confusion. The plan still holds,
> except I'm not sure if Albert is also going to do a P-R for
> u-boot-arm/next, so CC'ing him to let him know that we might also need
> some help from his side.
>
>> > Thanks,
>> > Lucas
>>
>> Best regards,
>> Marek Vasut
>>
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] Has anyone gotten the mmc commands to work on the NOVSOMTMi.MX6Q-SL-1-D, on the NOVPEK board by Novtech?

2012-10-01 Thread Fabio Estevam
On Mon, Oct 1, 2012 at 11:13 AM, Greg Topmiller  wrote:
> I am using release 2012.07 of u-boot with board type freescale/mx6qarm2.  The 
> mx6qarm2 is what is used as the board type in the freescale u-boot delivered 
> with the board.  We want to use the main line u-boot 2012.07.  To get it 
> working I had to change the serial port and it boots ok.  I also noticed 
> sdhc1 and sdhc2 were not being initialized with fsl_esdhc_initialize.  I 
> tried to initialize them but it hangs on "mmc rescan".  I turned on

sdhc1 and sdhc2 are not available on mx6qarm2. Only sdhc3 and sdhc4
you can use on this board.

Regards,

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


Re: [U-Boot] [PATCH v2] tegra: add Colibri T20 board support

2012-10-01 Thread Stephen Warren
On 09/29/2012 02:03 PM, Lucas Stach wrote:
> This adds board support for the Toradex Colibri T20 module.
> 
> Working functions:
> - SD card boot
> - USB boot
> - Network
> - NAND environment

> diff --git a/board/toradex/colibri_t20/Makefile 
> b/board/toradex/colibri_t20/Makefile
...
> +#
> \ No newline at end of file

I assume that's a mistake.

> diff --git a/board/toradex/colibri_t20/colibri_t20.c 
> b/board/toradex/colibri_t20/colibri_t20.c

> +#ifdef CONFIG_USB_EHCI_TEGRA
> +void pin_mux_usb(void)
> +{
> + /* USB 1 aka Tegra USB port 3 */
> + pinmux_tristate_disable(PINGRP_SPIG);

I don't think that's muxing USB itself, but rather muxing perhaps the
VBUS GPIO?

> +#ifdef CONFIG_TEGRA_MMC
> +int board_mmc_init(bd_t *bd)
> +{
> + funcmux_select(PERIPH_ID_SDMMC4, FUNCMUX_SDMMC4_ATB_GMA_4_BIT);
> + pinmux_tristate_disable(PINGRP_GMB);

It might be useful to comment the tristate call like other boards, e.g.:

/* For power GPIO PI6 */
pinmux_tristate_disable(PINGRP_ATA);

so it's obvious why the call isn't done inside funcmux_select().

> diff --git a/board/toradex/dts/tegra20-colibri_t20.dts 
> b/board/toradex/dts/tegra20-colibri_t20.dts

> + usb@c5008000 {
> + nvidia,vbus-gpio = <&gpio 178 1>; /* PW2 low-active */
> + };

As an FYI, although the GPIO bindings do specify that the last cell
there is for GPIO flags, I'm not sure that we should rely on it. Not all
GPIO bindings actually have the ability to specify flags there, so if a
given board's GPIO is provided by some device whose GPIO binding doesn't
allow for flags, then it won't be possible to specify an active-low
GPIO, and this won't work.

The kernel certainly doesn't actually do anything with the flags
argument in the EHCI driver, IIRC.

Either we should forcibly change all GPIO bindings in the kernel to
require that they allow flags to be specified (probably very hard), or
remove the flags from the Tegra GPIO binding, and use a separate
property such as nvidia,vbus-gpio-active-low for this purpose.
Certainly, the latter form of approach has been taken in other places
(such as fixed regulator IIRC).
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2 1/2] tegra: clean up board include hell

2012-10-01 Thread Stephen Warren
On 09/29/2012 02:02 PM, Lucas Stach wrote:
> The prototypes used in board files were all scattered out, which lead to
> code duplication between SPL and normal U-Boot and some prototypes not 
> actually
> being used. Consolidate this in a common board header.

Seems reasonable enough to me. This series or anything similar that's
also OK with Tom is:
Acked-by: Stephen Warren 

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


[U-Boot] [PATCH] AP1000: Inline local 'get_device'

2012-10-01 Thread Tom Rini
The AP1000 defines a 'get_device' function to determine what board
revision we are on.  Inline that checking as it conflicts with the
get_device() in  and is only used once.

Signed-off-by: Tom Rini 
---
 board/amirix/ap1000/ap1000.c |   11 +++
 board/amirix/ap1000/ap1000.h |1 -
 2 files changed, 3 insertions(+), 9 deletions(-)

diff --git a/board/amirix/ap1000/ap1000.c b/board/amirix/ap1000/ap1000.c
index 64de04c..dbcb34b 100644
--- a/board/amirix/ap1000/ap1000.c
+++ b/board/amirix/ap1000/ap1000.c
@@ -43,11 +43,13 @@ int checkboard (void)
/* After a loadace command, the SystemAce control register is left in a 
wonky state. */
/* this code did not work in board_pre_init */
unsigned char *p = (unsigned char *) AP1000_SYSACE_REGBASE;
+   unsigned int *revision_reg_ptr = (unsigned int *) AP1xx_FPGA_REV_ADDR;
+   unsigned int device = (*revision_reg_ptr & AP1xx_TARGET_MASK);
 
p[SYSACE_CTRLREG0] = 0x0;
 
/* add platform and device to banner */
-   switch (get_device ()) {
+   switch (device) {
case AP1xx_AP107_TARGET:
puts (AP1xx_AP107_TARGET_STR);
break;
@@ -160,13 +162,6 @@ unsigned int get_platform (void)
return (*revision_reg_ptr & AP1xx_PLATFORM_MASK);
 }
 
-unsigned int get_device (void)
-{
-   unsigned int *revision_reg_ptr = (unsigned int *) AP1xx_FPGA_REV_ADDR;
-
-   return (*revision_reg_ptr & AP1xx_TARGET_MASK);
-}
-
 #if 0  /* loadace is not working; it appears to be a 
hardware issue with the system ace. */
 /*
This function loads FPGA configurations from the SystemACE CompactFlash
diff --git a/board/amirix/ap1000/ap1000.h b/board/amirix/ap1000/ap1000.h
index 118c4d1..d294816 100644
--- a/board/amirix/ap1000/ap1000.h
+++ b/board/amirix/ap1000/ap1000.h
@@ -164,7 +164,6 @@
 void set_eat_machine_checks(int a_flag);
 int get_eat_machine_checks(void);
 unsigned int get_platform(void);
-unsigned int get_device(void);
 void* memcpyb(void * dest,const void *src,size_t count);
 int process_bootflag(ulong bootflag);
 void user_led_on(void);
-- 
1.7.9.5

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


[U-Boot] [PATCH v3] README: Add handy kermit primer

2012-10-01 Thread Karl O. Pinc

Signed-off-by: Karl O. Pinc 
---
 README |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)

*
On 09/02/2012 10:47:45 AM, Wolfgang Denk wrote:

> In message <1344017124-5749-1-git-send-email-...@meme.com> you wrote:
> > Add doc/README.kermit.
> > 
> > Mention in README.

> doc/README.kermit.
> 
> Instead of adding a new file, place the URL to the wiki page here.

Ok.  Done.

> > --- /dev/null
> > +++ b/doc/README.kermit
> > @@ -0,0 +1,52 @@
> > +Copied from the U-Boot wiki,
> > +http://www.denx.de/wiki/view/DULG/SystemSetup#Section_4.3.
> > +on 2012-08-03.
> 
> This makes no sense to me.  Copying the text just means we have to
> maintain the same information in two places, which never works.

My thought was that no matter _what_ you do you have to maintain
the same information in two places -- the wiki url is subject
to change and any files in the source distribution will have
to be updated as the url changes.  Since we have to periodically
bring the source distribution in line with the wiki anyway,
may as well copy the relvent text as well.  It's hardly
any more work to keep up to date and at least the person
with the source will always have something, presumably
more useful that an outdated url, at hand.  The wiki
text will change more rapidly than the url; my thought
was that the current text will remain useful regardless
and if the url is referenced there's always the option
of getting something more current.


diff --git a/README b/README
index af76b0c..754e75a 100644
--- a/README
+++ b/README
@@ -4688,7 +4688,10 @@ Over time, many people have reported problems when 
trying to use the
 consider minicom to be broken, and recommend not to use it. Under
 Unix, I recommend to use C-Kermit for general purpose use (and
 especially for kermit binary protocol download ("loadb" command), and
-use "cu" for S-Record download ("loads" command).
+use "cu" for S-Record download ("loads" command).  See 
+http://www.denx.de/wiki/view/DULG/SystemSetup#Section_4.3.
+for help with kermit.
+
 
 Nevertheless, if you absolutely want to use it try adding this
 configuration to your "File transfer protocols" section:
-- 
1.7.2.5

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


[U-Boot] [PATCH] configs: Fix usage of mmc rescan

2012-10-01 Thread Andrew Bradford
Fix usage of 'mmc rescan' by many configs.  Proper use is
'mmc dev ${mmcdev}; mmc rescan' to set the mmc device and then rescan
the device.  'mmc rescan' itself does not take any arguments.

Signed-off-by: Andrew Bradford 
---
 include/configs/am335x_evm.h|2 +-
 include/configs/am3517_crane.h  |2 +-
 include/configs/am3517_evm.h|2 +-
 include/configs/cm_t35.h|2 +-
 include/configs/devkit8000.h|2 +-
 include/configs/igep00x0.h  |2 +-
 include/configs/mx28evk.h   |2 +-
 include/configs/mx51evk.h   |2 +-
 include/configs/mx53ard.h   |2 +-
 include/configs/mx53evk.h   |2 +-
 include/configs/mx53loco.h  |2 +-
 include/configs/mx53smd.h   |2 +-
 include/configs/mx6qarm2.h  |2 +-
 include/configs/mx6qsabrelite.h |2 +-
 include/configs/omap3_beagle.h  |2 +-
 include/configs/omap3_evm.h |2 +-
 include/configs/omap3_logic.h   |2 +-
 include/configs/omap3_overo.h   |2 +-
 include/configs/omap3_zoom1.h   |2 +-
 include/configs/omap4_common.h  |2 +-
 include/configs/omap5_evm.h |2 +-
 include/configs/tricorder.h |2 +-
 22 files changed, 22 insertions(+), 22 deletions(-)

diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
index 263a5ad..6bda1cf 100644
--- a/include/configs/am335x_evm.h
+++ b/include/configs/am335x_evm.h
@@ -81,7 +81,7 @@
"bootm ${loadaddr}\0" \
 
 #define CONFIG_BOOTCOMMAND \
-   "if mmc rescan ${mmcdev}; then " \
+   "mmc dev ${mmcdev}; if mmc rescan; then " \
"echo SD/MMC found on device ${mmcdev};" \
"if run loadbootenv; then " \
"echo Loaded environment from ${bootenv};" \
diff --git a/include/configs/am3517_crane.h b/include/configs/am3517_crane.h
index 8ddeff4..20a3df5 100644
--- a/include/configs/am3517_crane.h
+++ b/include/configs/am3517_crane.h
@@ -209,7 +209,7 @@
"bootm ${loadaddr}\0" \
 
 #define CONFIG_BOOTCOMMAND \
-   "if mmc rescan ${mmcdev}; then " \
+   "mmc dev ${mmcdev}; if mmc rescan; then " \
"if run loadbootscript; then " \
"run bootscript; " \
"else " \
diff --git a/include/configs/am3517_evm.h b/include/configs/am3517_evm.h
index 6980811..ce71d13 100644
--- a/include/configs/am3517_evm.h
+++ b/include/configs/am3517_evm.h
@@ -206,7 +206,7 @@
"bootm ${loadaddr}\0" \
 
 #define CONFIG_BOOTCOMMAND \
-   "if mmc rescan ${mmcdev}; then " \
+   "mmc dev ${mmcdev}; if mmc rescan; then " \
"if run loadbootscript; then " \
"run bootscript; " \
"else " \
diff --git a/include/configs/cm_t35.h b/include/configs/cm_t35.h
index 46c556d..6f355c7 100644
--- a/include/configs/cm_t35.h
+++ b/include/configs/cm_t35.h
@@ -231,7 +231,7 @@
"bootm ${loadaddr}\0" \
 
 #define CONFIG_BOOTCOMMAND \
-   "if mmc rescan ${mmcdev}; then " \
+   "mmc dev ${mmcdev}; if mmc rescan; then " \
"if run loadbootscript; then " \
"run bootscript; " \
"else " \
diff --git a/include/configs/devkit8000.h b/include/configs/devkit8000.h
index 2d2ee5f..7faa868 100644
--- a/include/configs/devkit8000.h
+++ b/include/configs/devkit8000.h
@@ -232,7 +232,7 @@
"dhcp ${loadaddr}; " \
"run netargs; " \
"bootm ${loadaddr}\0" \
-   "autoboot=if mmc rescan ${mmcdev}; then " \
+   "autoboot=mmc dev ${mmcdev}; if mmc rescan; then " \
"if run loadbootscript; then " \
"run bootscript; " \
"else " \
diff --git a/include/configs/igep00x0.h b/include/configs/igep00x0.h
index b1071e8..c81ab76 100644
--- a/include/configs/igep00x0.h
+++ b/include/configs/igep00x0.h
@@ -180,7 +180,7 @@
"bootm ${loadaddr}\0" \
 
 #define CONFIG_BOOTCOMMAND \
-   "if mmc rescan ${mmcdev}; then " \
+   "mmc dev ${mmcdev}; if mmc rescan; then " \
"echo SD/MMC found on device ${mmcdev};" \
"if run loadbootenv; then " \
"run importbootenv;" \
diff --git a/include/configs/mx28evk.h b/include/configs/mx28evk.h
index dffb744..385ee71 100644
--- a/include/configs/mx28evk.h
+++ b/include/configs/mx28evk.h
@@ -312,7 +312,7 @@
"dhcp ${uimage}; bootm\0"
 
 #define CONFIG_BOOTCOMMAND \
-   "if mmc rescan ${mmcdev}; then " \
+   "mmc dev ${mmcdev}; if mmc rescan; then " \
"if run loadbootscript; then " \
"run bootscript; " \
"else " \
diff --git a/include/configs/mx51evk.h b/include/configs/mx51evk.h
index ba4a4a6..8f960dd 100644
--- a/include/configs/mx51evk.h
+++ b/include/configs/mx51evk.h
@@ -183,7 +183,7 @@
"dhcp ${uimage}; bootm\0" \
 
 #define CONFIG_BOOTCOMMAND \
-   "if mm

Re: [U-Boot] [PATCH 40/71] serial: arm: Implement CONFIG_SERIAL_MULTI into altera serial driver

2012-10-01 Thread Marek Vasut
Dear Thomas Chou,

> On 09/17/2012 07:21 AM, Marek Vasut wrote:
> > Implement support for CONFIG_SERIAL_MULTI into altera serial driver.
> > This driver was so far only usable directly, but this patch also adds
> > support for the multi method. This allows using more than one serial
> > driver alongside the altera driver. Also, add a weak implementation
> > of default_serial_console() returning this driver.
> > 
> > Signed-off-by: Marek Vasut 
> > Cc: Marek Vasut 
> > Cc: Tom Rini 
> > Cc: Scott McNutt 
> > ---
> > 
> >   common/serial.c  |2 +
> >   drivers/serial/altera_uart.c |   83
> >   -- 2 files changed, 73
> >   insertions(+), 12 deletions(-)
> 
> Dear Marek,
> 
> Please include the following headers.
[...]
Fixed both, V2 out

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


[U-Boot] [PATCH 40/72 V2] serial: arm: Implement CONFIG_SERIAL_MULTI into altera serial driver

2012-10-01 Thread Marek Vasut
Implement support for CONFIG_SERIAL_MULTI into altera serial driver.
This driver was so far only usable directly, but this patch also adds
support for the multi method. This allows using more than one serial
driver alongside the altera driver. Also, add a weak implementation
of default_serial_console() returning this driver.

Signed-off-by: Marek Vasut 
Cc: Marek Vasut 
Cc: Tom Rini 
Cc: Scott McNutt 
---
 common/serial.c  |2 +
 drivers/serial/altera_uart.c |   85 --
 2 files changed, 75 insertions(+), 12 deletions(-)

V2: Add includes (serial.h and linux/compiler.h)

diff --git a/common/serial.c b/common/serial.c
index 24879ec..e6566da 100644
--- a/common/serial.c
+++ b/common/serial.c
@@ -70,6 +70,7 @@ serial_initfunc(ml2_serial_initialize);
 serial_initfunc(sconsole_serial_initialize);
 serial_initfunc(p3mx_serial_initialize);
 serial_initfunc(altera_jtag_serial_initialize);
+serial_initfunc(altera_serial_initialize);
 
 void serial_register(struct serial_device *dev)
 {
@@ -118,6 +119,7 @@ void serial_initialize(void)
sconsole_serial_initialize();
p3mx_serial_initialize();
altera_jtag_serial_initialize();
+   altera_serial_initialize();
 
serial_assign(default_serial_console()->name);
 }
diff --git a/drivers/serial/altera_uart.c b/drivers/serial/altera_uart.c
index 045f119..1d0dd69 100644
--- a/drivers/serial/altera_uart.c
+++ b/drivers/serial/altera_uart.c
@@ -26,6 +26,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -37,27 +39,33 @@ static nios_uart_t *uart = (nios_uart_t *) 
CONFIG_SYS_NIOS_CONSOLE;
 
 #if defined(CONFIG_SYS_NIOS_FIXEDBAUD)
 
-/* Everything's already setup for fixed-baud PTF
+/*
+ * Everything's already setup for fixed-baud PTF
  * assignment
  */
-void serial_setbrg (void){ return; }
-int serial_init (void) { return (0);}
+static void altera_serial_setbrg(void)
+{
+}
+
+static int altera_serial_init(void)
+{
+   return 0;
+}
 
 #else
 
-void serial_setbrg (void)
+static void altera_serial_setbrg(void)
 {
unsigned div;
 
div = (CONFIG_SYS_CLK_FREQ/gd->baudrate)-1;
writel (div, &uart->divisor);
-   return;
 }
 
-int serial_init (void)
+static int altera_serial_init(void)
 {
-   serial_setbrg ();
-   return (0);
+   serial_setbrg();
+   return 0;
 }
 
 #endif /* CONFIG_SYS_NIOS_FIXEDBAUD */
@@ -65,7 +73,7 @@ int serial_init (void)
 /*---
  * UART CONSOLE
  *-*/
-void serial_putc (char c)
+static void altera_serial_putc(char c)
 {
if (c == '\n')
serial_putc ('\r');
@@ -74,21 +82,74 @@ void serial_putc (char c)
writel ((unsigned char)c, &uart->txdata);
 }
 
-void serial_puts (const char *s)
+static void altera_serial_puts(const char *s)
 {
while (*s != 0) {
serial_putc (*s++);
}
 }
 
-int serial_tstc (void)
+static int altera_serial_tstc(void)
 {
return (readl (&uart->status) & NIOS_UART_RRDY);
 }
 
-int serial_getc (void)
+static int altera_serial_getc(void)
 {
while (serial_tstc () == 0)
WATCHDOG_RESET ();
return (readl (&uart->rxdata) & 0x00ff );
 }
+
+#ifdef CONFIG_SERIAL_MULTI
+static struct serial_device altera_serial_drv = {
+   .name   = "altera_serial",
+   .start  = altera_serial_init,
+   .stop   = NULL,
+   .setbrg = altera_serial_setbrg,
+   .putc   = altera_serial_putc,
+   .puts   = altera_serial_puts,
+   .getc   = altera_serial_getc,
+   .tstc   = altera_serial_tstc,
+};
+
+void altera_serial_initialize(void)
+{
+   serial_register(&altera_serial_drv);
+}
+
+__weak struct serial_device *default_serial_console(void)
+{
+   return &altera_serial_drv;
+}
+#else
+int serial_init(void)
+{
+   return altera_serial_init();
+}
+
+void serial_setbrg(void)
+{
+   altera_serial_setbrg();
+}
+
+void serial_putc(const char c)
+{
+   altera_serial_putc(c);
+}
+
+void serial_puts(const char *s)
+{
+   altera_serial_puts(s);
+}
+
+int serial_getc(void)
+{
+   return altera_serial_getc();
+}
+
+int serial_tstc(void)
+{
+   return altera_serial_tstc();
+}
+#endif
-- 
1.7.10.4

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


[U-Boot] [PATCH 39/72 V2] serial: arm: Implement CONFIG_SERIAL_MULTI into altera_jtag serial driver

2012-10-01 Thread Marek Vasut
Implement support for CONFIG_SERIAL_MULTI into altera_jtag serial driver.
This driver was so far only usable directly, but this patch also adds
support for the multi method. This allows using more than one serial
driver alongside the altera_jtag driver. Also, add a weak implementation
of default_serial_console() returning this driver.

Signed-off-by: Marek Vasut 
Cc: Marek Vasut 
Cc: Tom Rini 
Cc: Thomas Chou 
---
 common/serial.c   |2 +
 drivers/serial/altera_jtag_uart.c |   73 ++---
 2 files changed, 69 insertions(+), 6 deletions(-)

V2: Add includes (serial.h and linux/compiler.h)
Fix name too long error

diff --git a/common/serial.c b/common/serial.c
index 2d6ba05..24879ec 100644
--- a/common/serial.c
+++ b/common/serial.c
@@ -69,6 +69,7 @@ serial_initfunc(evb64260_serial_initialize);
 serial_initfunc(ml2_serial_initialize);
 serial_initfunc(sconsole_serial_initialize);
 serial_initfunc(p3mx_serial_initialize);
+serial_initfunc(altera_jtag_serial_initialize);
 
 void serial_register(struct serial_device *dev)
 {
@@ -116,6 +117,7 @@ void serial_initialize(void)
ml2_serial_initialize();
sconsole_serial_initialize();
p3mx_serial_initialize();
+   altera_jtag_serial_initialize();
 
serial_assign(default_serial_console()->name);
 }
diff --git a/drivers/serial/altera_jtag_uart.c 
b/drivers/serial/altera_jtag_uart.c
index 2980e4d..8cb4606 100644
--- a/drivers/serial/altera_jtag_uart.c
+++ b/drivers/serial/altera_jtag_uart.c
@@ -25,6 +25,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -33,10 +35,16 @@ DECLARE_GLOBAL_DATA_PTR;
  *-*/
 static nios_jtag_t *jtag = (nios_jtag_t *)CONFIG_SYS_NIOS_CONSOLE;
 
-void serial_setbrg( void ){ return; }
-int serial_init( void ) { return(0);}
+static void altera_jtag_serial_setbrg(void)
+{
+}
+
+static int altera_jtag_serial_init(void)
+{
+   return 0;
+}
 
-void serial_putc (char c)
+static void altera_jtag_serial_putc(char c)
 {
while (1) {
unsigned st = readl(&jtag->control);
@@ -51,18 +59,18 @@ void serial_putc (char c)
writel ((unsigned char)c, &jtag->data);
 }
 
-void serial_puts (const char *s)
+static void altera_jtag_serial_puts(const char *s)
 {
while (*s != 0)
serial_putc (*s++);
 }
 
-int serial_tstc (void)
+static int altera_jtag_serial_tstc(void)
 {
return ( readl (&jtag->control) & NIOS_JTAG_RRDY);
 }
 
-int serial_getc (void)
+static int altera_jtag_serial_getc(void)
 {
int c;
unsigned val;
@@ -76,3 +84,56 @@ int serial_getc (void)
c = val & 0x0ff;
return (c);
 }
+
+#ifdef CONFIG_SERIAL_MULTI
+static struct serial_device altera_jtag_serial_drv = {
+   .name   = "altera_jtag_uart",
+   .start  = altera_jtag_serial_init,
+   .stop   = NULL,
+   .setbrg = altera_jtag_serial_setbrg,
+   .putc   = altera_jtag_serial_putc,
+   .puts   = altera_jtag_serial_puts,
+   .getc   = altera_jtag_serial_getc,
+   .tstc   = altera_jtag_serial_tstc,
+};
+
+void altera_jtag_serial_initialize(void)
+{
+   serial_register(&altera_jtag_serial_drv);
+}
+
+__weak struct serial_device *default_serial_console(void)
+{
+   return &altera_jtag_serial_drv;
+}
+#else
+int serial_init(void)
+{
+   return altera_jtag_serial_init();
+}
+
+void serial_setbrg(void)
+{
+   altera_jtag_serial_setbrg();
+}
+
+void serial_putc(const char c)
+{
+   altera_jtag_serial_putc(c);
+}
+
+void serial_puts(const char *s)
+{
+   altera_jtag_serial_puts(s);
+}
+
+int serial_getc(void)
+{
+   return altera_jtag_serial_getc();
+}
+
+int serial_tstc(void)
+{
+   return altera_jtag_serial_tstc();
+}
+#endif
-- 
1.7.10.4

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


Re: [U-Boot] [PATCH 39/71] serial: arm: Implement CONFIG_SERIAL_MULTI into altera_jtag serial driver

2012-10-01 Thread Marek Vasut
Dear Thomas Chou,

> On 09/17/2012 07:21 AM, Marek Vasut wrote:
> > Implement support for CONFIG_SERIAL_MULTI into altera_jtag serial driver.
> > This driver was so far only usable directly, but this patch also adds
> > support for the multi method. This allows using more than one serial
> > driver alongside the altera_jtag driver. Also, add a weak implementation
> > of default_serial_console() returning this driver.
> > 
> > Signed-off-by: Marek Vasut 
> > Cc: Marek Vasut 
> > Cc: Tom Rini 
> > Cc: Thomas Chou 
> > ---
> > 
> >   common/serial.c   |2 ++
> >   drivers/serial/altera_jtag_uart.c |   71
> >   + 2 files changed, 67
> >   insertions(+), 6 deletions(-)
> 
> Dear Marek,
> 
> Please include the following headers.
> 
> --- a/drivers/serial/altera_jtag_uart.c
> +++ b/drivers/serial/altera_jtag_uart.c
> @@ -25,6 +25,8 @@
>   #include 
>   #include 
>   #include 
> +#include 
> +#include 


Are you seeing any issues without them?

>   DECLARE_GLOBAL_DATA_PTR;
> 
> And the .name string is too long. >16
> 
> static struct serial_device altera_jtag_serial_drv = {
>   .name   = "altera_jtag_serial",
> 
> Otherwise,
> Acked-by: Thomas Chou 
> 
> Best regards,
> Thomas Chou
[...]
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] Custodians, Maintainers and old platforms

2012-10-01 Thread Marek Vasut
Dear R, Sricharan,

> Hi Marek Vasut,
> 
> On Sun, Sep 30, 2012 at 6:48 PM, Marek Vasut  wrote:
> > Dear R, Sricharan,
> > 
> >> Hi Marek Vasut,
> >> 
> >> >> > One of the keys to the success of U-Boot has been the number of
> >> >> > platforms that are supported.  But part of supporting platforms is
> >> >> > needing people to volunteer to maintain them long term and help
> >> >> > with testing changes and so forth.  So first of all, I've just
> >> >> > tagged v2012.10-rc1.  Please give this at least a basic test on
> >> >> > whatever platforms you're able to.
> >> >> > 
> >> >>   Having been testing on OMAP5 and OMAP4 sdp. Will also test on
> >> >>   others. Is there any branch where the basic DM driver support
> >> >>   patches are pushed
> >> >> 
> >> >> to start with ?
> >> > 
> >> > u-boot-testing.git ... soon
> >>  
> >>  Thanks, will watch out.
> > 
> > It's there ... branch dm-serial-1 , you can check dm-stringify and
> > dm-lgarray
> 
>  So should these 3 branches be merged to start?
> Thanks, will start with this for OMAP drivers.

They're separate, feel free to play

> Thanks,
>  Sricharan

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


Re: [U-Boot] [u-boot-release] [RFC PATCH 17/17] ns16550: wait for TENT before initializing

2012-10-01 Thread Timur Tabi
Scott Wood wrote:
> This prevents output problems (including a loss of synchronization
> observed on p2020 that persisted for quite a while) if SPL has output
> still on its way out.  I'm not sure why this is only now beginning to
> happen, though.

The subject line says "TENT", but the macro says "TEMT".

Also, it would be nice to see a description of this bit somewhere.

> 
> Signed-off-by: Scott Wood 
> ---
>  drivers/serial/ns16550.c |3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
> index 0c23955..66201b6 100644
> --- a/drivers/serial/ns16550.c
> +++ b/drivers/serial/ns16550.c
> @@ -36,6 +36,9 @@
>  
>  void NS16550_init(NS16550_t com_port, int baud_divisor)
>  {
> + while (!(serial_in(&com_port->lsr) & UART_LSR_TEMT))
> + ;
> +
>   serial_out(CONFIG_SYS_NS16550_IER, &com_port->ier);
>  #if (defined(CONFIG_OMAP) && !defined(CONFIG_OMAP3_ZOOM2)) || \
>   defined(CONFIG_AM33XX)


-- 
Timur Tabi
Linux kernel developer at Freescale

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


[U-Boot] Has anyone gotten the mmc commands to work on the NOVSOMTMi.MX6Q-SL-1-D, on the NOVPEK board by Novtech?

2012-10-01 Thread Greg Topmiller
I am using release 2012.07 of u-boot with board type freescale/mx6qarm2.  The 
mx6qarm2 is what is used as the board type in the freescale u-boot delivered 
with the board.  We want to use the main line u-boot 2012.07.  To get it 
working I had to change the serial port and it boots ok.  I also noticed sdhc1 
and sdhc2 were not being initialized with fsl_esdhc_initialize.  I tried to 
initialize them but it hangs on "mmc rescan".  I turned on CONFIG_MMC_TRACE and 
get the following.

MX6QARM2 U-Boot > mmc rescan
board_mmc_getcd called for FSL_SDHC
MMC: mmc_set_bus_width
MMC: mmc_set_clock
MMC: mmc_go_idle
CMD_SEND:0
ARG  0x
FLAG 0
MMC_RSP_NONE
MMC: mmc_send_if_cond
CMD_SEND:8
ARG  0x01AA
FLAG 0

FYI, below is some debug output when sdhc1 and sdhc2 are not initialized and 
doing an mmc rescan.
MX6QARM2 U-Boot > mmc rescan
board_mmc_getcd called for FSL_SDHC
MMC: mmc_set_bus_width
MMC: mmc_set_clock
MMC: mmc_go_idle
CMD_SEND:0
ARG  0x
FLAG 0
MMC_RSP_NONE
MMC: mmc_send_if_cond
CMD_SEND:8
ARG  0x01AA
FLAG 0
MMC_RSP_R1,5,6,7 0x4FD77E14
MMC: sd_send_op_cond
CMD_SEND:55
ARG  0x
FLAG 0
MMC_RSP_R1,5,6,7 0x0002
MMC: sd_send_op_cond err -19
CMD_SEND:0
ARG  0x
FLAG 0
MMC_RSP_NONE
CMD_SEND:1
ARG  0x
FLAG 0
MMC_RSP_R3,4 0x0002
Card did not respond to voltage select!

Any help is much appreciated.

Thanks,

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


Re: [U-Boot] Custodians, Maintainers and old platforms

2012-10-01 Thread R, Sricharan
Hi Marek Vasut,

On Sun, Sep 30, 2012 at 6:48 PM, Marek Vasut  wrote:
> Dear R, Sricharan,
>
>> Hi Marek Vasut,
>>
>> >> > One of the keys to the success of U-Boot has been the number of
>> >> > platforms that are supported.  But part of supporting platforms is
>> >> > needing people to volunteer to maintain them long term and help with
>> >> > testing changes and so forth.  So first of all, I've just tagged
>> >> > v2012.10-rc1.  Please give this at least a basic test on whatever
>> >> > platforms you're able to.
>> >> >
>> >>   Having been testing on OMAP5 and OMAP4 sdp. Will also test on others.
>> >>   Is there any branch where the basic DM driver support patches are
>> >>   pushed
>> >>
>> >> to start with ?
>> >
>> > u-boot-testing.git ... soon
>>
>>  Thanks, will watch out.
>
> It's there ... branch dm-serial-1 , you can check dm-stringify and dm-lgarray
>
 So should these 3 branches be merged to start?
Thanks, will start with this for OMAP drivers.

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


Re: [U-Boot] u-boot/master slight regression with trats

2012-10-01 Thread Tom Rini
On Mon, Oct 01, 2012 at 12:25:34PM +0200, Lukasz Majewski wrote:
> Hi all,
> 
> > 
> > > 
> > > On Sat, 29 Sep 2012 17:17:48 +0200
> > > Albert ARIBAUD  wrote:
> > > 
> > > > Hi all,
> > > > 
> > > > On Sat, 29 Sep 2012 12:32:36 +0200, Albert ARIBAUD
> > > >  wrote:
> > > > 
> > > > > Hello,
> > > > > 
> > > > > While merging u-boot-arm/master and u-boot/master I have noticed
> > > > > one slight regression apparently coming from u-boot:
> > > > > 
> > > > > $ cat LOG/trats.ERR 
> > > > > cmd_fat.c: In function ???do_fat_fswrite???:
> > > > > cmd_fat.c:178:8: warning: unused variable
> > > > > ???ep??? [-Wunused-variable]
> > > > > 
> > > > > ep should have disappeared along with the code which used it,
> > > > > but somehow resurfaced (I suspect it did in a merge).
> > > > > 
> > > > > This warning is not seen in u-boot-arm.
> > > > > 
> > > > > Amicalement,
> > > > 
> > > > Seems Heungjun Kim  is now a dead
> > > > address.
> > > > 
> > > > Anatolij, I see you've sent out a patch. Does it mean you would
> > > > act as a maintainer for trats? 
> > > > Otherwise the board should be made orphan.
> > 
> > Dear all, I was on a holidays :-). 
> > 
> > I can test if Trats is working. I posses one, so there is no problem
> > with that :-).
> > 
> > I will fix Trats ASAP.
> 
> I've just tested TRATS with the newest origin/master 
> (SHA1: 4668a086bb0a769b741e3a4ffab85f1c41c7cdb8 )
> 
> It builds without errors/warinigs
> 
> > 
> > > 
> > > I do not have a trats board, so I can't do tests and act as a
> > > maintainer for it. Lukasz (on Cc) recently submitted some patches
> > > for trats, maybe he knows who could become new maintainer for trats
> > > board?

Ah, but would you be willing to take the MAINTAINER spot for the board?
Thanks!

-- 
Tom


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


[U-Boot] [PATCH 3/6] powerpc/85xx: move SRIO configuration out of corenet_ds.h

2012-10-01 Thread Timur Tabi
The P5040 does not have SRIO, so don't put the SRIO definitions in
corenet_ds.h.  They belong in the board-specific header files.

Signed-off-by: Timur Tabi 
---
 include/configs/P3041DS.h|4 
 include/configs/P4080DS.h|4 
 include/configs/P5020DS.h|4 
 include/configs/corenet_ds.h |4 
 4 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/include/configs/P3041DS.h b/include/configs/P3041DS.h
index 98e7a42..cf184e7 100644
--- a/include/configs/P3041DS.h
+++ b/include/configs/P3041DS.h
@@ -36,6 +36,10 @@
 #define CONFIG_PCIE4
 #define CONFIG_SYS_DPAA_RMAN
 
+#define CONFIG_SYS_SRIO
+#define CONFIG_SRIO1   /* SRIO port 1 */
+#define CONFIG_SRIO2   /* SRIO port 2 */
+
 #define CONFIG_ICS307_REFCLK_HZ2500  /* ICS307 ref clk 
freq */
 
 #include "corenet_ds.h"
diff --git a/include/configs/P4080DS.h b/include/configs/P4080DS.h
index d6f2f5c..53979dd 100644
--- a/include/configs/P4080DS.h
+++ b/include/configs/P4080DS.h
@@ -33,6 +33,10 @@
 #define CONFIG_MMC
 #define CONFIG_PCIE3
 
+#define CONFIG_SYS_SRIO
+#define CONFIG_SRIO1   /* SRIO port 1 */
+#define CONFIG_SRIO2   /* SRIO port 2 */
+
 #define CONFIG_ICS307_REFCLK_HZ3000  /* ICS307 ref clk 
freq */
 
 #include "corenet_ds.h"
diff --git a/include/configs/P5020DS.h b/include/configs/P5020DS.h
index 8625f76..7018d7a 100644
--- a/include/configs/P5020DS.h
+++ b/include/configs/P5020DS.h
@@ -37,6 +37,10 @@
 #define CONFIG_SYS_FSL_RAID_ENGINE
 #define CONFIG_SYS_DPAA_RMAN
 
+#define CONFIG_SYS_SRIO
+#define CONFIG_SRIO1   /* SRIO port 1 */
+#define CONFIG_SRIO2   /* SRIO port 2 */
+
 #define CONFIG_ICS307_REFCLK_HZ2500  /* ICS307 ref clk 
freq */
 
 #include "corenet_ds.h"
diff --git a/include/configs/corenet_ds.h b/include/configs/corenet_ds.h
index f4f9bd1..0f59fb2 100644
--- a/include/configs/corenet_ds.h
+++ b/include/configs/corenet_ds.h
@@ -76,10 +76,6 @@
 #define CONFIG_FSL_PCI_INIT/* Use common FSL init code */
 #define CONFIG_SYS_PCI_64BIT   /* enable 64-bit PCI resources */
 
-#define CONFIG_SYS_SRIO
-#define CONFIG_SRIO1   /* SRIO port 1 */
-#define CONFIG_SRIO2   /* SRIO port 2 */
-
 #define CONFIG_FSL_LAW /* Use common FSL init code */
 
 #define CONFIG_ENV_OVERWRITE
-- 
1.7.3.4


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


[U-Boot] [PATCH 6/6] [v2] powerpc/85xx: add support for the Freescale P5040DS Superhydra reference board

2012-10-01 Thread Timur Tabi
The P5040DS reference board (a.k.a "Superhydra") is an enhanced version of
P3041DS/P5020DS ("Hydra") reference board.

Signed-off-by: Timur Tabi 
Signed-off-by: Shaohui Xie 
---
 board/freescale/common/Makefile |2 +
 board/freescale/common/ngpixis.h|2 +-
 board/freescale/corenet_ds/Makefile |2 +
 board/freescale/corenet_ds/corenet_ds.c |   22 +-
 board/freescale/corenet_ds/eth_superhydra.c |  722 +++
 board/freescale/corenet_ds/p5040ds_ddr.c|   18 +
 boards.cfg  |1 +
 drivers/net/fm/Makefile |1 +
 drivers/net/fm/p5040.c  |  113 +
 include/configs/P5040DS.h   |   40 ++
 10 files changed, 916 insertions(+), 7 deletions(-)
 create mode 100644 board/freescale/corenet_ds/eth_superhydra.c
 create mode 100644 board/freescale/corenet_ds/p5040ds_ddr.c
 create mode 100644 drivers/net/fm/p5040.c
 create mode 100644 include/configs/P5040DS.h

diff --git a/board/freescale/common/Makefile b/board/freescale/common/Makefile
index 54cb098..dd93b32 100644
--- a/board/freescale/common/Makefile
+++ b/board/freescale/common/Makefile
@@ -53,12 +53,14 @@ COBJS-$(CONFIG_P2020DS) += ics307_clk.o
 COBJS-$(CONFIG_P3041DS)+= ics307_clk.o
 COBJS-$(CONFIG_P4080DS)+= ics307_clk.o
 COBJS-$(CONFIG_P5020DS)+= ics307_clk.o
+COBJS-$(CONFIG_P5040DS)+= ics307_clk.o
 
 # deal with common files for P-series corenet based devices
 SUBLIB-$(CONFIG_P2041RDB)  += p_corenet/libp_corenet.o
 SUBLIB-$(CONFIG_P3041DS)   += p_corenet/libp_corenet.o
 SUBLIB-$(CONFIG_P4080DS)   += p_corenet/libp_corenet.o
 SUBLIB-$(CONFIG_P5020DS)   += p_corenet/libp_corenet.o
+SUBLIB-$(CONFIG_P5040DS)   += p_corenet/libp_corenet.o
 
 SRCS   := $(SOBJS:.o=.S) $(COBJS-y:.o=.c)
 OBJS   := $(addprefix $(obj),$(COBJS-y))
diff --git a/board/freescale/common/ngpixis.h b/board/freescale/common/ngpixis.h
index 1d4483d..a239ee3 100644
--- a/board/freescale/common/ngpixis.h
+++ b/board/freescale/common/ngpixis.h
@@ -45,7 +45,7 @@ typedef struct ngpixis {
struct {
u8 sw;
u8 en;
-   } s[8];
+   } s[9]; /* s[0]..s[7] is SW1..SW8, and s[8] is SW11 */
 } __attribute__ ((packed)) ngpixis_t;
 
 /* Pointer to the PIXIS register set */
diff --git a/board/freescale/corenet_ds/Makefile 
b/board/freescale/corenet_ds/Makefile
index 1fdf8b7..d79193a 100644
--- a/board/freescale/corenet_ds/Makefile
+++ b/board/freescale/corenet_ds/Makefile
@@ -31,9 +31,11 @@ COBJS-y  += ddr.o
 COBJS-$(CONFIG_P3041DS)+= eth_hydra.o
 COBJS-$(CONFIG_P4080DS)+= eth_p4080.o
 COBJS-$(CONFIG_P5020DS)+= eth_hydra.o
+COBJS-$(CONFIG_P5040DS)+= eth_superhydra.o
 COBJS-$(CONFIG_P3041DS)+= p3041ds_ddr.o
 COBJS-$(CONFIG_P4080DS)+= p4080ds_ddr.o
 COBJS-$(CONFIG_P5020DS)+= p5020ds_ddr.o
+COBJS-$(CONFIG_P5040DS)+= p5040ds_ddr.o
 
 SRCS   := $(SOBJS:.o=.S) $(COBJS-y:.o=.c)
 OBJS   := $(addprefix $(obj),$(COBJS-y))
diff --git a/board/freescale/corenet_ds/corenet_ds.c 
b/board/freescale/corenet_ds/corenet_ds.c
index a33c936..21428e3 100644
--- a/board/freescale/corenet_ds/corenet_ds.c
+++ b/board/freescale/corenet_ds/corenet_ds.c
@@ -45,6 +45,7 @@ int checkboard (void)
struct cpu_type *cpu = gd->cpu;
ccsr_gur_t *gur = (void *)CONFIG_SYS_MPC85xx_GUTS_ADDR;
unsigned int i;
+   static const char * const freq[] = {"100", "125", "156.25", "212.5" };
 
printf("Board: %sDS, ", cpu->name);
printf("Sys ID: 0x%02x, Sys Ver: 0x%02x, FPGA Ver: 0x%02x, ",
@@ -83,20 +84,28 @@ int checkboard (void)
 * don't match.
 */
puts("SERDES Reference Clocks: ");
-#if defined(CONFIG_P3041DS) || defined(CONFIG_P5020DS)
+#if defined(CONFIG_P3041DS) || defined(CONFIG_P5020DS) \
+   || defined(CONFIG_P5040DS)
sw = in_8(&PIXIS_SW(5));
for (i = 0; i < 3; i++) {
-   static const char *freq[] = {"100", "125", "156.25", "212.5" };
unsigned int clock = (sw >> (6 - (2 * i))) & 3;
 
printf("Bank%u=%sMhz ", i+1, freq[clock]);
}
+#ifdef CONFIG_P5040DS
+   /* On P5040DS, SW11[7:8] determines the Bank 4 frequency */
+   sw = in_8(&PIXIS_SW(9));
+   printf("Bank4=%sMhz ", freq[sw & 3]);
+#endif
puts("\n");
 #else
sw = in_8(&PIXIS_SW(3));
-   printf("Bank1=%uMHz ", (sw & 0x40) ? 125 : 100);
-   printf("Bank2=%sMHz ", (sw & 0x20) ? "156.25" : "125");
-   printf("Bank3=%sMHz\n", (sw & 0x10) ? "156.25" : "125");
+   /* SW3[2]: 0 = 100 Mhz, 1 = 125 MHz */
+   /* SW3[3]: 0 = 125 Mhz, 1 = 156.25 MHz */
+   /* SW3[4]: 0 = 125 Mhz, 1 = 156.25 MHz */
+   printf("Bank1=%sMHz ", freq[!!(sw & 0x40)]);
+   printf("Bank2=%sMHz ", freq[1 + !!(sw & 0x20)]);
+   printf("Bank3=%sMHz\n", freq[1 + !!(sw & 0x1

[U-Boot] [PATCH 2/6] powerpc/85xx: introduce SET_PCI_LIODN_BASE, for setting PCI LIODNs

2012-10-01 Thread Timur Tabi
From: Laurentiu Tudor 

The liodn for the new PCIE controller included in P5040DS is no longer set
through a register in the guts register block but with one in the PCIE
register block itself.  Update the PCIE CCSR structure to add the new liodn
register and add a new dedicated SET_PCI_LIODN_BASE macro that puts
the liodn in the correct register.

Signed-off-by: Laurentiu Tudor 
Signed-off-by: Timur Tabi 
---
 arch/powerpc/include/asm/fsl_liodn.h  |5 +
 arch/powerpc/include/asm/immap_85xx.h |4 +++-
 2 files changed, 8 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/include/asm/fsl_liodn.h 
b/arch/powerpc/include/asm/fsl_liodn.h
index a9973b8..a37983e 100644
--- a/arch/powerpc/include/asm/fsl_liodn.h
+++ b/arch/powerpc/include/asm/fsl_liodn.h
@@ -94,6 +94,11 @@ extern void fdt_fixup_liodn(void *blob);
SET_GUTS_LIODN(compat, liodn, pex##pciNum##liodnr,\
CONFIG_SYS_MPC85xx_PCIE##pciNum##_OFFSET)
 
+#define SET_PCI_LIODN_BASE(compat, pciNum, liodn) \
+   SET_LIODN_ENTRY_1(compat, liodn,\
+   offsetof(ccsr_pcix_t, liodn_base) + 
CONFIG_SYS_MPC85xx_PCIE##pciNum##_OFFSET,\
+   CONFIG_SYS_MPC85xx_PCIE##pciNum##_OFFSET)
+
 /* reg nodes for DMA start @ 0x300 */
 #define SET_DMA_LIODN(dmaNum, liodn) \
SET_GUTS_LIODN("fsl,eloplus-dma", liodn, dma##dmaNum##liodnr,\
diff --git a/arch/powerpc/include/asm/immap_85xx.h 
b/arch/powerpc/include/asm/immap_85xx.h
index 7de33a7..6c11178 100644
--- a/arch/powerpc/include/asm/immap_85xx.h
+++ b/arch/powerpc/include/asm/immap_85xx.h
@@ -296,7 +296,9 @@ typedef struct ccsr_pcix {
u32 cfg_addr;   /* PCIX Configuration Addr */
u32 cfg_data;   /* PCIX Configuration Data */
u32 int_ack;/* PCIX IRQ Acknowledge */
-   u8  res1[3060];
+   u8  res000c[52];
+   u32 liodn_base; /* PCIX LIODN base register */
+   u8  res0044[3004];
u32 potar0; /* PCIX Outbound Transaction Addr 0 */
u32 potear0;/* PCIX Outbound Translation Extended Addr 0 */
u32 powbar0;/* PCIX Outbound Window Base Addr 0 */
-- 
1.7.3.4


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


[U-Boot] [PATCH 4/6] [v2] powerpc/85xx: Add P5040 processor support

2012-10-01 Thread Timur Tabi
Add support for the Freescale P5040 SOC, which is similar to the P5020.
Features of the P5040 are:

Four P5040 single-threaded e5500 cores built
Up to 2.4 GHz with 64-bit ISA support
Three levels of instruction: user, supervisor, hypervisor
CoreNet platform cache (CPC)
2.0 MB configures as dual 1 MB blocks hierarchical interconnect fabric
Two 64-bit DDR3/3L SDRAM memory controllers with ECC and interleaving
support Up to 1600MT/s
Memory pre-fetch engine
DPAA incorporating acceleration for the following functions
Packet parsing, classification, and distribution (FMAN)
Queue management for scheduling, packet sequencing and
congestion management (QMAN)
Hardware buffer management for buffer allocation and
de-allocation (BMAN)
Cryptography acceleration (SEC 5.2) at up to 40 Gbps SerDes
20 lanes at up to 5 Gbps
Supports SGMII, XAUI, PCIe rev1.1/2.0, SATA Ethernet interfaces
Two 10 Gbps Ethernet MACs
Ten 1 Gbps Ethernet MACs
High-speed peripheral interfaces
Two PCI Express 2.0/3.0 controllers
Additional peripheral interfaces
Two serial ATA (SATA 2.0) controllers
Two high-speed USB 2.0 controllers with integrated PHY
Enhanced secure digital host controller (SD/MMC/eMMC)
Enhanced serial peripheral interface (eSPI)
Two I2C controllers
Four UARTs
Integrated flash controller supporting NAND and NOR flash
DMA
Dual four channel
Support for hardware virtualization and partitioning enforcement
Extra privileged level for hypervisor support
QorIQ Trust Architecture 1.1
Secure boot, secure debug, tamper detection, volatile key storage

Signed-off-by: Timur Tabi 
---

The LIODNs for the SEC's DECOs are apparently wrong, but the correct
values are not available.  They will be fixed later.

 arch/powerpc/cpu/mpc85xx/Makefile |3 +
 arch/powerpc/cpu/mpc85xx/fsl_corenet_serdes.c |   70 +
 arch/powerpc/cpu/mpc85xx/fsl_corenet_serdes.h |5 +
 arch/powerpc/cpu/mpc85xx/p5040_ids.c  |  131 +
 arch/powerpc/cpu/mpc85xx/p5040_serdes.c   |  117 ++
 arch/powerpc/cpu/mpc85xx/speed.c  |2 +
 arch/powerpc/cpu/mpc8xxx/cpu.c|2 +
 arch/powerpc/include/asm/config_mpc85xx.h |   28 +
 arch/powerpc/include/asm/immap_85xx.h |   15 +++
 arch/powerpc/include/asm/processor.h  |2 +
 10 files changed, 375 insertions(+), 0 deletions(-)
 create mode 100644 arch/powerpc/cpu/mpc85xx/p5040_ids.c
 create mode 100644 arch/powerpc/cpu/mpc85xx/p5040_serdes.c

diff --git a/arch/powerpc/cpu/mpc85xx/Makefile 
b/arch/powerpc/cpu/mpc85xx/Makefile
index 33e93c8..aad50f3 100644
--- a/arch/powerpc/cpu/mpc85xx/Makefile
+++ b/arch/powerpc/cpu/mpc85xx/Makefile
@@ -66,6 +66,7 @@ COBJS-$(CONFIG_PPC_P2041) += ddr-gen3.o
 COBJS-$(CONFIG_PPC_P3041)  += ddr-gen3.o
 COBJS-$(CONFIG_PPC_P4080)  += ddr-gen3.o
 COBJS-$(CONFIG_PPC_P5020)  += ddr-gen3.o
+COBJS-$(CONFIG_PPC_P5040)  += ddr-gen3.o
 COBJS-$(CONFIG_BSC9131)+= ddr-gen3.o
 
 COBJS-$(CONFIG_CPM2)   += ether_fcc.o
@@ -80,6 +81,7 @@ COBJS-$(CONFIG_PPC_P2041) += p2041_ids.o
 COBJS-$(CONFIG_PPC_P3041) += p3041_ids.o
 COBJS-$(CONFIG_PPC_P4080) += p4080_ids.o
 COBJS-$(CONFIG_PPC_P5020) += p5020_ids.o
+COBJS-$(CONFIG_PPC_P5040) += p5040_ids.o
 
 COBJS-$(CONFIG_QE) += qe_io.o
 COBJS-$(CONFIG_CPM2)   += serial_scc.o
@@ -110,6 +112,7 @@ COBJS-$(CONFIG_PPC_P2041) += p2041_serdes.o
 COBJS-$(CONFIG_PPC_P3041) += p3041_serdes.o
 COBJS-$(CONFIG_PPC_P4080) += p4080_serdes.o
 COBJS-$(CONFIG_PPC_P5020) += p5020_serdes.o
+COBJS-$(CONFIG_PPC_P5040) += p5040_serdes.o
 
 COBJS  = $(COBJS-y)
 COBJS  += cpu.o
diff --git a/arch/powerpc/cpu/mpc85xx/fsl_corenet_serdes.c 
b/arch/powerpc/cpu/mpc85xx/fsl_corenet_serdes.c
index 2a68060..e6b1b1b 100644
--- a/arch/powerpc/cpu/mpc85xx/fsl_corenet_serdes.c
+++ b/arch/powerpc/cpu/mpc85xx/fsl_corenet_serdes.c
@@ -92,10 +92,17 @@ static const struct {
{ 17, 163, FSL_SRDS_BANK_2 },
{ 18, 164, FSL_SRDS_BANK_2 },
{ 19, 165, FSL_SRDS_BANK_2 },
+#ifdef CONFIG_PPC_P4080
{ 20, 170, FSL_SRDS_BANK_3 },
{ 21, 171, FSL_SRDS_BANK_3 },
{ 22, 172, FSL_SRDS_BANK_3 },
{ 23, 173, FSL_SRDS_BANK_3 },
+#else
+   { 20, 166, FSL_SRDS_BANK_3 },
+   { 21, 167, FSL_SRDS_BANK_3 },
+   { 22, 168, FSL_SRDS_BANK_3 },
+   { 23, 169, FSL_SRDS_BANK_3 },
+#endif
 };
 
 int serdes_get_lane_idx(int lane)
@@ -493,6 +500,9 @@ void fsl_serdes_init(void)
ccsr_gur_t *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
int cfg;
serdes_corenet_t *srds_regs;
+#ifdef CONFIG_PPC_P5040
+   serdes_corenet_t *srds2_regs;
+#endif
int lane, bank, idx;
int have_bank[SRDS_MAX_BANK] = {};
 #ifdef CONFIG_SYS_P4080_ERRATUM_SERDES8
@@ -574,6 +584,34 @@ void fsl_serdes_init(void)
}
}
 
+#ifdef CONFIG_PPC_P5040
+   /*
+* Lanes on bank 4 o

[U-Boot] [PATCH 5/6] powerpc/p5040ds: add per pci endpoint liodn offset list

2012-10-01 Thread Timur Tabi
From: Laurentiu Tudor 

Add a new device tree property named "fsl,liodn-offset-list"
holding a list of per pci endpoint permitted liodn offsets.
This property is useful in virtualization scenarios
that implement per pci endpoint partitioning.
The final liodn of a partitioned pci endpoint is
calculated by the hardware, by adding these offsets
to pci controller's base liodn, stored in the
"fsl,liodn" property of its node.
The liodn offsets are interleaved to get better cache
utilization. As an example, given 3 pci controllers,
the following liodns are generated for the pci endpoints:
pci0: 193 256 259 262 265 268 271 274 277
pci1: 194 257 260 263 266 269 272 275 278
pci2: 195 258 261 264 267 270 273 276 279

Signed-off-by: Laurentiu Tudor 
---
 arch/powerpc/cpu/mpc85xx/liodn.c |   52 ++
 1 files changed, 52 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/cpu/mpc85xx/liodn.c b/arch/powerpc/cpu/mpc85xx/liodn.c
index 11881c9..97d6904 100644
--- a/arch/powerpc/cpu/mpc85xx/liodn.c
+++ b/arch/powerpc/cpu/mpc85xx/liodn.c
@@ -248,6 +248,56 @@ static void fdt_fixup_srio_liodn(void *blob, struct 
srio_liodn_id_table *tbl)
}
 }
 
+#define CONFIG_SYS_MAX_PCI_EPS 8
+#define CONFIG_SYS_PCI_EP_LIODN_START  256
+
+static void fdt_fixup_pci_liodn_offsets(void *fdt, const char *compat)
+{
+   int off, pci_idx = 0, pci_cnt = 0, i, rc;
+   const uint32_t *base_liodn;
+   uint32_t liodn_offs[CONFIG_SYS_MAX_PCI_EPS + 1] = { 0 };
+
+   /*
+* Count the number of pci nodes.
+* It's needed later when the interleaved liodn offsets are generated.
+*/
+   off = fdt_node_offset_by_compatible(fdt, -1, compat);
+   while (off != -FDT_ERR_NOTFOUND) {
+   pci_cnt++;
+   off = fdt_node_offset_by_compatible(fdt, off, compat);
+   }
+
+   for (off = fdt_node_offset_by_compatible(fdt, -1, compat);
+off != -FDT_ERR_NOTFOUND;
+off = fdt_node_offset_by_compatible(fdt, off, compat)) {
+   base_liodn = fdt_getprop(fdt, off, "fsl,liodn", &rc);
+   if (!base_liodn) {
+   char path[64];
+
+   if (fdt_get_path(fdt, off, path, sizeof(path)) < 0)
+   strcpy(path, "(unknown)");
+   printf("WARNING Could not get liodn of node %s: %s\n",
+  path, fdt_strerror(rc));
+   continue;
+   }
+   for (i = 0; i < CONFIG_SYS_MAX_PCI_EPS; i++)
+   liodn_offs[i + 1] = CONFIG_SYS_PCI_EP_LIODN_START +
+   i * pci_cnt + pci_idx - *base_liodn;
+   rc = fdt_setprop(fdt, off, "fsl,liodn-offset-list",
+liodn_offs, sizeof(liodn_offs));
+   if (rc) {
+   char path[64];
+
+   if (fdt_get_path(fdt, off, path, sizeof(path)) < 0)
+   strcpy(path, "(unknown)");
+   printf("WARNING Unable to set fsl,liodn-offset-list for 
"
+  "node %s: %s\n", path, fdt_strerror(rc));
+   continue;
+   }
+   pci_idx++;
+   }
+}
+
 static void fdt_fixup_liodn_tbl(void *blob, struct liodn_id_table *tbl, int sz)
 {
int i;
@@ -295,4 +345,6 @@ void fdt_fixup_liodn(void *blob)
 #ifdef CONFIG_SYS_DPAA_RMAN
fdt_fixup_liodn_tbl(blob, rman_liodn_tbl, rman_liodn_tbl_sz);
 #endif
+
+   fdt_fixup_pci_liodn_offsets(blob, "fsl,qoriq-pcie-v2.4");
 }
-- 
1.7.3.4


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


[U-Boot] [PATCH 1/6] powerpc/mpc85xx: fix Unicode characters in release.S

2012-10-01 Thread Timur Tabi
Commit 709389b6 unintentionally used the Unicode version of the
apostrophy.  Replace it with the normal ASCII version.

Signed-off-by: Timur Tabi 
---
 arch/powerpc/cpu/mpc85xx/release.S |   24 
 1 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/arch/powerpc/cpu/mpc85xx/release.S 
b/arch/powerpc/cpu/mpc85xx/release.S
index 22e73e0..8662ae4 100644
--- a/arch/powerpc/cpu/mpc85xx/release.S
+++ b/arch/powerpc/cpu/mpc85xx/release.S
@@ -159,20 +159,20 @@ __secondary_start_page:
 /*
  * PIR definition for E6500
  * 0-17 Reserved (logic 0s)
- * 8-19 CHIP_ID,2’b00  - SoC 1
+ * 8-19 CHIP_ID,2'b00  - SoC 1
  *  all others - reserved
- * 20-24 CLUSTER_ID 5’b0   - CCM 1
+ * 20-24 CLUSTER_ID 5'b0   - CCM 1
  *  all others - reserved
- * 25-26 CORE_CLUSTER_ID 2’b00 - cluster 1
- *   2’b01 - cluster 2
- *   2’b10 - cluster 3
- *   2’b11 - cluster 4
- * 27-28 CORE_ID 2’b00 - core 0
- *   2’b01 - core 1
- *   2’b10 - core 2
- *   2’b11 - core 3
- * 29-31 THREAD_ID   3’b000 - thread 0
- *   3’b001 - thread 1
+ * 25-26 CORE_CLUSTER_ID 2'b00 - cluster 1
+ *   2'b01 - cluster 2
+ *   2'b10 - cluster 3
+ *   2'b11 - cluster 4
+ * 27-28 CORE_ID 2'b00 - core 0
+ *   2'b01 - core 1
+ *   2'b10 - core 2
+ *   2'b11 - core 3
+ * 29-31 THREAD_ID   3'b000 - thread 0
+ *   3'b001 - thread 1
  */
rlwinm  r4,r0,29,25,31
 #elif  defined(CONFIG_E500MC)
-- 
1.7.3.4


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


Re: [U-Boot] [PATCH 40/71] serial: arm: Implement CONFIG_SERIAL_MULTI into altera serial driver

2012-10-01 Thread Thomas Chou

On 09/17/2012 07:21 AM, Marek Vasut wrote:

Implement support for CONFIG_SERIAL_MULTI into altera serial driver.
This driver was so far only usable directly, but this patch also adds
support for the multi method. This allows using more than one serial
driver alongside the altera driver. Also, add a weak implementation
of default_serial_console() returning this driver.

Signed-off-by: Marek Vasut 
Cc: Marek Vasut 
Cc: Tom Rini 
Cc: Scott McNutt 
---
  common/serial.c  |2 +
  drivers/serial/altera_uart.c |   83 --
  2 files changed, 73 insertions(+), 12 deletions(-)


Dear Marek,

Please include the following headers.

--- a/drivers/serial/altera_uart.c
+++ b/drivers/serial/altera_uart.c
@@ -26,6 +26,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 

 DECLARE_GLOBAL_DATA_PTR;


Otherwise,
Acked-by: Thomas Chou 

Best regards,
Thomas Chou






diff --git a/common/serial.c b/common/serial.c
index 24879ec..e6566da 100644
--- a/common/serial.c
+++ b/common/serial.c
@@ -70,6 +70,7 @@ serial_initfunc(ml2_serial_initialize);
  serial_initfunc(sconsole_serial_initialize);
  serial_initfunc(p3mx_serial_initialize);
  serial_initfunc(altera_jtag_serial_initialize);
+serial_initfunc(altera_serial_initialize);

  void serial_register(struct serial_device *dev)
  {
@@ -118,6 +119,7 @@ void serial_initialize(void)
sconsole_serial_initialize();
p3mx_serial_initialize();
altera_jtag_serial_initialize();
+   altera_serial_initialize();

serial_assign(default_serial_console()->name);
  }
diff --git a/drivers/serial/altera_uart.c b/drivers/serial/altera_uart.c
index 045f119..18b820b 100644
--- a/drivers/serial/altera_uart.c
+++ b/drivers/serial/altera_uart.c
@@ -37,27 +37,33 @@ static nios_uart_t *uart = (nios_uart_t *) 
CONFIG_SYS_NIOS_CONSOLE;

  #if defined(CONFIG_SYS_NIOS_FIXEDBAUD)

-/* Everything's already setup for fixed-baud PTF
+/*
+ * Everything's already setup for fixed-baud PTF
   * assignment
   */
-void serial_setbrg (void){ return; }
-int serial_init (void) { return (0);}
+static void altera_serial_setbrg(void)
+{
+}
+
+static int altera_serial_init(void)
+{
+   return 0;
+}

  #else

-void serial_setbrg (void)
+static void altera_serial_setbrg(void)
  {
unsigned div;

div = (CONFIG_SYS_CLK_FREQ/gd->baudrate)-1;
writel (div, &uart->divisor);
-   return;
  }

-int serial_init (void)
+static int altera_serial_init(void)
  {
-   serial_setbrg ();
-   return (0);
+   serial_setbrg();
+   return 0;
  }

  #endif /* CONFIG_SYS_NIOS_FIXEDBAUD */
@@ -65,7 +71,7 @@ int serial_init (void)
  /*---
   * UART CONSOLE
   *-*/
-void serial_putc (char c)
+static void altera_serial_putc(char c)
  {
if (c == '\n')
serial_putc ('\r');
@@ -74,21 +80,74 @@ void serial_putc (char c)
writel ((unsigned char)c, &uart->txdata);
  }

-void serial_puts (const char *s)
+static void altera_serial_puts(const char *s)
  {
while (*s != 0) {
serial_putc (*s++);
}
  }

-int serial_tstc (void)
+static int altera_serial_tstc(void)
  {
return (readl (&uart->status) & NIOS_UART_RRDY);
  }

-int serial_getc (void)
+static int altera_serial_getc(void)
  {
while (serial_tstc () == 0)
WATCHDOG_RESET ();
return (readl (&uart->rxdata) & 0x00ff );
  }
+
+#ifdef CONFIG_SERIAL_MULTI
+static struct serial_device altera_serial_drv = {
+   .name   = "altera_serial",
+   .start  = altera_serial_init,
+   .stop   = NULL,
+   .setbrg = altera_serial_setbrg,
+   .putc   = altera_serial_putc,
+   .puts   = altera_serial_puts,
+   .getc   = altera_serial_getc,
+   .tstc   = altera_serial_tstc,
+};
+
+void altera_serial_initialize(void)
+{
+   serial_register(&altera_serial_drv);
+}
+
+__weak struct serial_device *default_serial_console(void)
+{
+   return &altera_serial_drv;
+}
+#else
+int serial_init(void)
+{
+   return altera_serial_init();
+}
+
+void serial_setbrg(void)
+{
+   altera_serial_setbrg();
+}
+
+void serial_putc(const char c)
+{
+   altera_serial_putc(c);
+}
+
+void serial_puts(const char *s)
+{
+   altera_serial_puts(s);
+}
+
+int serial_getc(void)
+{
+   return altera_serial_getc();
+}
+
+int serial_tstc(void)
+{
+   return altera_serial_tstc();
+}
+#endif



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


Re: [U-Boot] [PATCH 39/71] serial: arm: Implement CONFIG_SERIAL_MULTI into altera_jtag serial driver

2012-10-01 Thread Thomas Chou

On 09/17/2012 07:21 AM, Marek Vasut wrote:

Implement support for CONFIG_SERIAL_MULTI into altera_jtag serial driver.
This driver was so far only usable directly, but this patch also adds
support for the multi method. This allows using more than one serial
driver alongside the altera_jtag driver. Also, add a weak implementation
of default_serial_console() returning this driver.

Signed-off-by: Marek Vasut 
Cc: Marek Vasut 
Cc: Tom Rini 
Cc: Thomas Chou 
---
  common/serial.c   |2 ++
  drivers/serial/altera_jtag_uart.c |   71 +
  2 files changed, 67 insertions(+), 6 deletions(-)



Dear Marek,

Please include the following headers.

--- a/drivers/serial/altera_jtag_uart.c
+++ b/drivers/serial/altera_jtag_uart.c
@@ -25,6 +25,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 

 DECLARE_GLOBAL_DATA_PTR;

And the .name string is too long. >16

static struct serial_device altera_jtag_serial_drv = {
.name   = "altera_jtag_serial",

Otherwise,
Acked-by: Thomas Chou 

Best regards,
Thomas Chou






diff --git a/common/serial.c b/common/serial.c
index 2d6ba05..24879ec 100644
--- a/common/serial.c
+++ b/common/serial.c
@@ -69,6 +69,7 @@ serial_initfunc(evb64260_serial_initialize);
  serial_initfunc(ml2_serial_initialize);
  serial_initfunc(sconsole_serial_initialize);
  serial_initfunc(p3mx_serial_initialize);
+serial_initfunc(altera_jtag_serial_initialize);

  void serial_register(struct serial_device *dev)
  {
@@ -116,6 +117,7 @@ void serial_initialize(void)
ml2_serial_initialize();
sconsole_serial_initialize();
p3mx_serial_initialize();
+   altera_jtag_serial_initialize();

serial_assign(default_serial_console()->name);
  }
diff --git a/drivers/serial/altera_jtag_uart.c 
b/drivers/serial/altera_jtag_uart.c
index 2980e4d..d3b6c1c 100644
--- a/drivers/serial/altera_jtag_uart.c
+++ b/drivers/serial/altera_jtag_uart.c
@@ -33,10 +33,16 @@ DECLARE_GLOBAL_DATA_PTR;
   *-*/
  static nios_jtag_t *jtag = (nios_jtag_t *)CONFIG_SYS_NIOS_CONSOLE;

-void serial_setbrg( void ){ return; }
-int serial_init( void ) { return(0);}
+static void altera_jtag_serial_setbrg(void)
+{
+}
+
+static int altera_jtag_serial_init(void)
+{
+   return 0;
+}

-void serial_putc (char c)
+static void altera_jtag_serial_putc(char c)
  {
while (1) {
unsigned st = readl(&jtag->control);
@@ -51,18 +57,18 @@ void serial_putc (char c)
writel ((unsigned char)c, &jtag->data);
  }

-void serial_puts (const char *s)
+static void altera_jtag_serial_puts(const char *s)
  {
while (*s != 0)
serial_putc (*s++);
  }

-int serial_tstc (void)
+static int altera_jtag_serial_tstc(void)
  {
return ( readl (&jtag->control) & NIOS_JTAG_RRDY);
  }

-int serial_getc (void)
+static int altera_jtag_serial_getc(void)
  {
int c;
unsigned val;
@@ -76,3 +82,56 @@ int serial_getc (void)
c = val & 0x0ff;
return (c);
  }
+
+#ifdef CONFIG_SERIAL_MULTI
+static struct serial_device altera_jtag_serial_drv = {
+   .name   = "altera_jtag_serial",
+   .start  = altera_jtag_serial_init,
+   .stop   = NULL,
+   .setbrg = altera_jtag_serial_setbrg,
+   .putc   = altera_jtag_serial_putc,
+   .puts   = altera_jtag_serial_puts,
+   .getc   = altera_jtag_serial_getc,
+   .tstc   = altera_jtag_serial_tstc,
+};
+
+void altera_jtag_serial_initialize(void)
+{
+   serial_register(&altera_jtag_serial_drv);
+}
+
+__weak struct serial_device *default_serial_console(void)
+{
+   return &altera_jtag_serial_drv;
+}
+#else
+int serial_init(void)
+{
+   return altera_jtag_serial_init();
+}
+
+void serial_setbrg(void)
+{
+   altera_jtag_serial_setbrg();
+}
+
+void serial_putc(const char c)
+{
+   altera_jtag_serial_putc(c);
+}
+
+void serial_puts(const char *s)
+{
+   altera_jtag_serial_puts(s);
+}
+
+int serial_getc(void)
+{
+   return altera_jtag_serial_getc();
+}
+
+int serial_tstc(void)
+{
+   return altera_jtag_serial_tstc();
+}
+#endif



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


Re: [U-Boot] include: fix mips64 build warning

2012-10-01 Thread Daniel Schwierzeck
Hi Zhi-zhou,

2012/9/29 Zhi-zhou Zhang :
> fix warnings when building mips64, we define CONFIG_MIPS64 in config file. 
> And this macro decides size_t.
> hashtable.c: In function 'hexport_r':
> hashtable.c:495:2: warning: format '%zu' expects argument of type 'size_t', 
> but argument 5 has type 'unsigned int' [-Wformat]
> hashtable.c:554:5: warning: format '%zu' expects argument of type 'size_t', 
> but argument 2 has type 'unsigned int' [-Wformat]
> hashtable.c:554:5: warning: format '%zu' expects argument of type 'size_t', 
> but argument 3 has type 'unsigned int' [-Wformat]
> hashtable.c: In function 'himport_r':
> hashtable.c:654:3: warning: format '%zu' expects argument of type 'size_t', 
> but argument 2 has type 'unsigned int' [-Wformat]
>
> Signed-off-by: Zhi-zhou Zhang 

thanks but I already fixed this in next branch of
git://git.denx.de/u-boot-mips.git.
I've replaced your check with "#if _MIPS_SZLONG != 64" (gcc built-in).
Linux MIPS does the same.

> ---
>  include/linux/types.h |1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/include/linux/types.h b/include/linux/types.h
> index 1b0b4a4..33ee095 100644
> --- a/include/linux/types.h
> +++ b/include/linux/types.h
> @@ -4,6 +4,7 @@
>  #ifdef __KERNEL__
>  #include 
>  #endif
> +#include 
>
>  #include 
>  #include 
> --
> 1.7.9.5
>

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


Re: [U-Boot] KernelDoc

2012-10-01 Thread Marek Vasut
Dear Wolfgang Denk,

> Dear Marek Vasut,
> 
> In message <201210011107.45164.ma...@denx.de> you wrote:
> > Agreed, not the whole file. But, can you check the rules I tried to
> > outline?
> 
> Is there a summary somewhere?  Something we could add to the wiki?

I sent this on friday:

So I've been hacking on it for a bit, see the first stab at [1]. As for the 
ruleset, I propose this addition for the Wiki [2]:

-->8--

U-Boot code documentation
=

U-Boot adopted the kernel-doc annotation style, this is the only exception from 
multi-line comment rule of Coding Style. While not mandatory, adding 
documentation is strongly advised. The Linux kernel kernel-doc document [3] 
appliest with no changes.

--8<--

[1] http://twilight.ponies.cz/kerneldoc/
[2] http://www.denx.de/wiki/U-Boot/CodingStyle
[3] 
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/kernel-
doc-nano-HOWTO.txt

> Best regards,
> 
> Wolfgang Denk

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


Re: [U-Boot] KernelDoc

2012-10-01 Thread Wolfgang Denk
Dear Marek Vasut,

In message <201210011107.45164.ma...@denx.de> you wrote:
> 
> Agreed, not the whole file. But, can you check the rules I tried to outline?

Is there a summary somewhere?  Something we could add to the wiki?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
No problem is insoluble.
-- Dr. Janet Wallace, "The Deadly Years", stardate 3479.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] u-boot/master slight regression with trats

2012-10-01 Thread Lukasz Majewski
Hi all,

> 
> > 
> > On Sat, 29 Sep 2012 17:17:48 +0200
> > Albert ARIBAUD  wrote:
> > 
> > > Hi all,
> > > 
> > > On Sat, 29 Sep 2012 12:32:36 +0200, Albert ARIBAUD
> > >  wrote:
> > > 
> > > > Hello,
> > > > 
> > > > While merging u-boot-arm/master and u-boot/master I have noticed
> > > > one slight regression apparently coming from u-boot:
> > > > 
> > > > $ cat LOG/trats.ERR 
> > > > cmd_fat.c: In function ‘do_fat_fswrite’:
> > > > cmd_fat.c:178:8: warning: unused variable
> > > > ‘ep’ [-Wunused-variable]
> > > > 
> > > > ep should have disappeared along with the code which used it,
> > > > but somehow resurfaced (I suspect it did in a merge).
> > > > 
> > > > This warning is not seen in u-boot-arm.
> > > > 
> > > > Amicalement,
> > > 
> > > Seems Heungjun Kim  is now a dead
> > > address.
> > > 
> > > Anatolij, I see you've sent out a patch. Does it mean you would
> > > act as a maintainer for trats? 
> > > Otherwise the board should be made orphan.
> 
> Dear all, I was on a holidays :-). 
> 
> I can test if Trats is working. I posses one, so there is no problem
> with that :-).
> 
> I will fix Trats ASAP.

I've just tested TRATS with the newest origin/master 
(SHA1: 4668a086bb0a769b741e3a4ffab85f1c41c7cdb8 )

It builds without errors/warinigs

> 
> > 
> > I do not have a trats board, so I can't do tests and act as a
> > maintainer for it. Lukasz (on Cc) recently submitted some patches
> > for trats, maybe he knows who could become new maintainer for trats
> > board?
> > 




-- 
Best regards,

Lukasz Majewski

Samsung Poland R&D Center | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] u-boot/master slight regression with trats

2012-10-01 Thread Anatolij Gustschin
Hi Lukasz,

On Mon, 01 Oct 2012 11:21:59 +0200
Lukasz Majewski  wrote:
...
> > > Seems Heungjun Kim  is now a dead address.
> > > 
> > > Anatolij, I see you've sent out a patch. Does it mean you would act
> > > as a maintainer for trats? 
> > > Otherwise the board should be made orphan.
> 
> Dear all, I was on a holidays :-). 
> 
> I can test if Trats is working. I posses one, so there is no problem
> with that :-).
> 
> I will fix Trats ASAP.

Please note that Tom applied a warning fix into 
git://git.denx.de/u-boot.git master

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


Re: [U-Boot] u-boot/master slight regression with trats

2012-10-01 Thread Lukasz Majewski
Hi all,

> 
> On Sat, 29 Sep 2012 17:17:48 +0200
> Albert ARIBAUD  wrote:
> 
> > Hi all,
> > 
> > On Sat, 29 Sep 2012 12:32:36 +0200, Albert ARIBAUD
> >  wrote:
> > 
> > > Hello,
> > > 
> > > While merging u-boot-arm/master and u-boot/master I have noticed
> > > one slight regression apparently coming from u-boot:
> > > 
> > > $ cat LOG/trats.ERR 
> > > cmd_fat.c: In function ‘do_fat_fswrite’:
> > > cmd_fat.c:178:8: warning: unused variable ‘ep’ [-Wunused-variable]
> > > 
> > > ep should have disappeared along with the code which used it, but
> > > somehow resurfaced (I suspect it did in a merge).
> > > 
> > > This warning is not seen in u-boot-arm.
> > > 
> > > Amicalement,
> > 
> > Seems Heungjun Kim  is now a dead address.
> > 
> > Anatolij, I see you've sent out a patch. Does it mean you would act
> > as a maintainer for trats? 
> > Otherwise the board should be made orphan.

Dear all, I was on a holidays :-). 

I can test if Trats is working. I posses one, so there is no problem
with that :-).

I will fix Trats ASAP.

> 
> I do not have a trats board, so I can't do tests and act as a
> maintainer for it. Lukasz (on Cc) recently submitted some patches for
> trats, maybe he knows who could become new maintainer for trats board?
> 




-- 
Best regards,

Lukasz Majewski

Samsung Poland R&D Center | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] KernelDoc

2012-10-01 Thread Marek Vasut
Dear Wolfgang Denk,

> Dear Marek Vasut,
> 
> In message <201209270138.12860.ma...@denx.de> you wrote:
> > > I think is kind of unfair to expect such efforts for some basicly
> > > unrelated changes.  If I were in such a situation, I'd feel tempted to
> > > throw the towel.
> > 
> > Why would you do so ... you change interface, you document it.
> 
> Having to document not only my change, but all the rest of the source
> file as well may mean I spend way more work on this doc task than on
> the actual fix.
> 
> And while I may well understand the area I meddled with, I may not
> easily understand the rest of the code, so this is twice hard and time
> consuming.

Agreed, not the whole file. But, can you check the rules I tried to outline?

> Best regards,
> 
> Wolfgang Denk

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


Re: [U-Boot] [PATCH] ARM: arm1176: Define arch_cpu_init() for s3c64xx

2012-10-01 Thread Marek Vasut
Dear Ashok Kumar Reddy,

> Hi Marek Vasut,
> 
> On 30-09-2012 18:51, Marek Vasut wrote:
> > Dear Ashok Kumar Reddy,
> > 
> >> Hi Marek Vasut , Hi Stephen Warren
> >> 
> >> Please provide comments for the below patch, as i forgot to add you in
> >> cc for below mail.
> > 
> > You CC wrong people, CCing Minkyu.
> > 
> > Anyway, this doesn't seem right, removing CONFIG_ICACHE_OFF from your
> > config file should have the same impact, right?
> 
> CONFIG_ICACHE_OFF is valid for only blackfin as per grep in u-boot code,
> the icache enable is done in arch_cpu_init() for arm1176

Ok, CCing Albert.

> >> Regards,
> >> Ashok
> >> 
> >> On 26-09-2012 23:59, Ashok Kumar Reddy wrote:
> >>>   From 0de61b9690c5f136ba5d3028be43877ea455d843 Mon Sep 17 00:00:00
> >>>   2001
> >>> 
> >>> From: Ashok Kumar Reddy 
> >>> Date: Wed, 26 Sep 2012 23:44:59 +0530
> >>> Subject: [PATCH] ARM: arm1176: Define arch_cpu_init() for s3c64xx
> >>> 
> >>> arch_cpu_init() is removed from cpu level to SOC level for arm1176
> >>> in commit 4ea6d6b,the same is done for s3c64xx
> >>> 
> >>> Signed-off-by: Ashok Kumar Reddy 
> >>> ---
> >>> 
> >>>arch/arm/cpu/arm1176/s3c64xx/Makefile |2 +-
> >>>arch/arm/cpu/arm1176/s3c64xx/init.c   |   26
> >>>++ 2 files changed, 27 insertions(+), 1
> >>>deletion(-)
> >>>create mode 100644 arch/arm/cpu/arm1176/s3c64xx/init.c
> >>> 
> >>> diff --git a/arch/arm/cpu/arm1176/s3c64xx/Makefile
> >>> b/arch/arm/cpu/arm1176/s3c64xx/Makefile index 0785b19..266a073 100644
> >>> --- a/arch/arm/cpu/arm1176/s3c64xx/Makefile
> >>> +++ b/arch/arm/cpu/arm1176/s3c64xx/Makefile
> >>> @@ -31,7 +31,7 @@ LIB = $(obj)lib$(SOC).o
> >>> 
> >>>SOBJS  = reset.o
> >>>
> >>>COBJS-$(CONFIG_S3C6400)+= cpu_init.o speed.o
> >>> 
> >>> -COBJS-y  += timer.o
> >>> +COBJS-y  += timer.o init.o
> >>> 
> >>>OBJS   := $(addprefix $(obj),$(SOBJS) $(COBJS-y))
> >>> 
> >>> diff --git a/arch/arm/cpu/arm1176/s3c64xx/init.c
> >>> b/arch/arm/cpu/arm1176/s3c64xx/init.c new file mode 100644
> >>> index 000..f113d8e
> >>> --- /dev/null
> >>> +++ b/arch/arm/cpu/arm1176/s3c64xx/init.c
> >>> @@ -0,0 +1,26 @@
> >>> +/*
> >>> + * (C) Copyright 2012 Ashok Kumar Reddy Kourla
> >>> + * ashokkourla2...@gmail.com
> >>> + *
> >>> + * See file CREDITS for list of people who contributed to this
> >>> + * project.
> >>> + *
> >>> + * This program is free software; you can redistribute it and/or
> >>> + * modify it under the terms of the GNU General Public License as
> >>> + * published by the Free Software Foundation; either version 2 of
> >>> + * the License, or (at your option) any later version.
> >>> + *
> >>> + * This program is distributed in the hope that it will be useful,
> >>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> >>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> >>> + * GNU General Public License for more details.
> >>> + */
> >>> +
> >>> +#include
> >>> +
> >>> +int arch_cpu_init(void)
> >>> +{
> >>> + icache_enable();
> >>> +
> >>> + return 0;
> >>> +}
> > 
> > Best regards,
> > Marek Vasut
> 
> Regards,
> Ashok

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


Re: [U-Boot] KernelDoc

2012-10-01 Thread Wolfgang Denk
Dear Marek Vasut,

In message <201209270138.12860.ma...@denx.de> you wrote:
> 
> > I think is kind of unfair to expect such efforts for some basicly
> > unrelated changes.  If I were in such a situation, I'd feel tempted to
> > throw the towel.
> 
> Why would you do so ... you change interface, you document it.

Having to document not only my change, but all the rest of the source
file as well may mean I spend way more work on this doc task than on
the actual fix.

And while I may well understand the area I meddled with, I may not
easily understand the rest of the code, so this is twice hard and time
consuming.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
The language provides a programmer with a set of conceptual tools; if
these are inadequate for the task, they will simply be  ignored.  For
example, seriously restricting the concept of a pointer simply forces
the  programmer  to use a vector plus integer arithmetic to implement
structures, pointer, etc. Good  design  and  the  absence  of  errors
cannot  be guaranteed by mere language features. - Bjarne Stroustrup,
"The C++ Programming Language"
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] Performance of the ARM's PL310 L2 cache.

2012-10-01 Thread Lukasz Majewski
Hi Marek,

> Dear Tom Rini,
> 
> > On Fri, Aug 17, 2012 at 05:49:53PM +0200, Lukasz Majewski wrote:
> > > Hi Aneesh,
> > > 
> > > I've enabled the L2 cache for Trats board. Please find results
> > > from performance tests.
> > > The test function as well as my way for enabling L2 are attached
> > > to this e-mail.
> > 
> > [snip]
> > 
> > > Have you had similar results with OMAP?
> > > Do you do more configuration when enabling the L2 at OMAP?
> > 
> > At least on some parts, it's similar here.  The normal sequence of
> > operations is loading a relatively small payload (kernel, maybe
> > device tree) from storage and then booting it (which turns off L2
> > anyways). This is why I was willing to disable DCACHE as a USB
> > workaround, the common use-case doesn't see a great deal of help
> > from dcache being on.
> 
> I saw some pretty significant perf. boost with L1, I was planning to
> check L2 on mx6q, but I'm not sure if it's worth it anymore.
> 
> Best regards,
> Marek Vasut

I can agree, that enabling L1 provides significant performance boost.
In our case, enabling L2 gives very little boost. Please try L2 on mx
and share the results.

-- 
Best regards,

Lukasz Majewski

Samsung Poland R&D Center | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [NEXT PATCH v1 2/7] NAND: added NAND type to nand_ids

2012-10-01 Thread Stefano Babic
On 11/09/2012 01:18, Scott Wood wrote:
> On 09/10/2012 07:09 AM, Stefano Babic wrote:
>> On 07/09/2012 20:56, Scott Wood wrote:
>>> What kind of chip is this?  Is the datasheet publicly available?
>>>
>>> These threads seem relevant:
>>> http://patchwork.ozlabs.org/patch/60042/
>>> http://old.nabble.com/-U-Boot--Add-new-NAND-flash-td29858370.html
>>
>> It is the same case,  as I can see, with the same chip.
>>
>>>

Hi Scott,

>>> Does the chip support ONFI?
>>
>> The chip supports ONFI, but it seems the i.MX driver does not. Quite as
>> described in http://patchwork.ozlabs.org/patch/60042/. READ-ID is always
>> sent with address 0, I do not know if we can convince the driver to send
>> the address.
> 
> How did Linux end up resolving this?

I could take a closer look. The issue is not solved on linux, too. In
fact, the MXC driver in current kernel supports ONFI, but it should work
for newer version of the controller - I think with MX5.

On MX35, the NFC controller is V1.1, exactly as on MX25, and I have the
same issue reported by Matthias that you pointed out in the past
threads: ONFI command does not work.

>  I think it'd be better to have the
> Micron decoding logic from that patch, than to introduce a special
> addition to the ID table for this one chip, which might not be correct
> for all chips with that ID byte.

Agree. I am trying to contact Micron to get some information about it. I
have tried to decode the bytes on basis of other Micron's NAND, but then
bit 6 in byte 4 says that the NAND is a 16 bit device, and that is
wrong. Exactly the same wrong value that Matthias found some times ago.

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