[U-Boot] [PATCH v5] spi: ftssp010_spi: add Faraday SPI controller support

[Kuo-Jung Su]

From: Kuo-Jung Su 

The Faraday FTSSP010 is a multi-function controller
which supports I2S/SPI/SSP/AC97/SPDIF. However This
patch implements only the SPI mode.

NOTE:
The DMA and CS/Clock control logic has been altered
since hardware revision 1.19.0. So this patch
would first detects the revision id of the underlying
chip, and then switch to the corresponding software
control routines.

Signed-off-by: Kuo-Jung Su 
CC: Jagan Teki 
CC: Tom Rini 
---
Changes for v5:
   - Use SPDX-License-Identifier
   - Add SPI mode checking & setup
   - Coding Style cleanup

Changes for v4:
   - Coding Style cleanup.
   - Make it a separate patch, rather then a part of
 Faraday A36x patch series
   - Use macro constants for timeout control

Changes for v3:
   - Coding Style cleanup.
   - Drop macros for wirtel()/readl(), call them directly.
   - Always insert a blank line between declarations and code.
   - Replace all the infinite wait loop with a timeout.
   - Add '__iomem' to all the declaration of HW register pointers.

Changes for v2:
   - Coding Style cleanup.
   - Use readl(), writel(), clrsetbits_le32() to replace REG() macros.
   - Use structure based hardware registers to replace the macro constants.
   - Replace BIT() with BIT_MASK().

 drivers/spi/Makefile   |1 +
 drivers/spi/ftssp010_spi.c |  513 
 2 files changed, 514 insertions(+)
 create mode 100644 drivers/spi/ftssp010_spi.c

diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 27902fe..ccc8f2f 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -19,6 +19,7 @@ obj-$(CONFIG_CF_SPI) += cf_spi.o
 obj-$(CONFIG_CF_QSPI) += cf_qspi.o
 obj-$(CONFIG_DAVINCI_SPI) += davinci_spi.o
 obj-$(CONFIG_EXYNOS_SPI) += exynos_spi.o
+obj-$(CONFIG_FTSSP010_SPI) += ftssp010_spi.o
 obj-$(CONFIG_ICH_SPI) +=  ich.o
 obj-$(CONFIG_KIRKWOOD_SPI) += kirkwood_spi.o
 obj-$(CONFIG_MPC52XX_SPI) += mpc52xx_spi.o
diff --git a/drivers/spi/ftssp010_spi.c b/drivers/spi/ftssp010_spi.c
new file mode 100644
index 000..b9273a3
--- /dev/null
+++ b/drivers/spi/ftssp010_spi.c
@@ -0,0 +1,513 @@
+/*
+ * (C) Copyright 2013
+ * Faraday Technology Corporation. 
+ * Kuo-Jung Su 
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#ifndef CONFIG_FTSSP010_BASE_LIST
+#define CONFIG_FTSSP010_BASE_LIST   { CONFIG_FTSSP010_BASE }
+#endif
+
+#ifndef CONFIG_FTSSP010_GPIO_BASE
+#define CONFIG_FTSSP010_GPIO_BASE   0
+#endif
+
+#ifndef CONFIG_FTSSP010_GPIO_LIST
+#define CONFIG_FTSSP010_GPIO_LIST   { CONFIG_FTSSP010_GPIO_BASE }
+#endif
+
+#ifndef CONFIG_FTSSP010_CLOCK
+#define CONFIG_FTSSP010_CLOCK   clk_get_rate("SSP");
+#endif
+
+#ifndef CONFIG_FTSSP010_TIMEOUT
+#define CONFIG_FTSSP010_TIMEOUT 100
+#endif
+
+/* FTSSP010 chip registers */
+struct ftssp010_regs {
+   uint32_t cr[3];/* control register */
+   uint32_t sr;   /* status register */
+   uint32_t icr;  /* interrupt control register */
+   uint32_t isr;  /* interrupt status register */
+   uint32_t dr;   /* data register */
+   uint32_t rsvd[17];
+   uint32_t revr; /* revision register */
+   uint32_t fear; /* feature register */
+};
+
+/* Control Register 0  */
+#define CR0_FFMT_MASK   (7 << 12)
+#define CR0_FFMT_SSP(0 << 12)
+#define CR0_FFMT_SPI(1 << 12)
+#define CR0_FFMT_MICROWIRE  (2 << 12)
+#define CR0_FFMT_I2S(3 << 12)
+#define CR0_FFMT_AC97   (4 << 12)
+#define CR0_FLASH   (1 << 11)
+#define CR0_FSDIST(x)   (((x) & 0x03) << 8)
+#define CR0_LOOP(1 << 7)  /* loopback mode */
+#define CR0_LSB (1 << 6)  /* LSB */
+#define CR0_FSPO(1 << 5)  /* fs atcive low (I2S only) */
+#define CR0_FSJUSTIFY   (1 << 4)
+#define CR0_OPM_SLAVE   (0 << 2)
+#define CR0_OPM_MASTER  (3 << 2)
+#define CR0_OPM_I2S_MSST(3 << 2)  /* master stereo mode */
+#define CR0_OPM_I2S_MSMO(2 << 2)  /* master mono mode */
+#define CR0_OPM_I2S_SLST(1 << 2)  /* slave stereo mode */
+#define CR0_OPM_I2S_SLMO(0 << 2)  /* slave mono mode */
+#define CR0_SCLKPO  (1 << 1)  /* clock polarity */
+#define CR0_SCLKPH  (1 << 0)  /* clock phase */
+
+/* Control Register 1 */
+#define CR1_PDL(x)   (((x) & 0xff) << 24) /* padding length */
+#define CR1_SDL(x)   x) - 1) & 0x1f) << 16) /* data length */
+#define CR1_DIV(x)   (((x) - 1) & 0x) /* clock divider */
+
+/* Control Register 2 */
+#define CR2_CS(x)(((x) & 3) << 10) /* CS/FS select */
+#define CR2_FS   (1 << 9) /* CS/FS signal level */
+#define CR2_TXEN (1 << 8) /* tx enable */
+#define CR2_RXEN (1 << 7) /* rx enable */
+#define CR2_RESET(1 << 6) /* chip reset */
+#define CR2_TXFC (1 << 3) /* tx fifo Clear */
+#define CR2_RXFC (1 << 2) /* rx fifo Clear */
+#define CR2_TXDOE(1 << 1) /* tx data output enable */
+#define CR2_EN   (1 << 0) /* chip enable */
+
+/* Status Register */

Re: [U-Boot] patchwork does not pick my patch

[Masahiro Yamada]

Hello Jeremy


> >> But my patch would not appear on patchwork.
> >> (Maybe because there is no diff line.)
> > 
> > I think so too. There is some handling for renames without patch in
> > patchwork, but I think there is no handling for just file permission
> > changes. That should be fixed in patchwork then.
> 
> Yep, that's correct - there's no support for these permission changes at
> present. I'll add that!

Thanks!


BTW, I notice another issue of patchwork.

Patchwork sometimes picks up emails which should not be.

For example,
I post an email (not a patch format, but includes some diff lines)
to the ML:
http://u-boot.10912.n7.nabble.com/RFC-ARM-optimized-memcpy-memset-on-SPL-build-td159583.html

And it was shown up on patchwork against my will.
http://patchwork.ozlabs.org/patch/260004/

I appreciate if you would fix this also.


Best Regards
Masahiro Yamada

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

Re: [U-Boot] (no subject)

[Wolfgang Denk]

Dear Bojan,

In message  
you wrote:
>
> I found address of register HW_RTC_WATCHDOG_SET: 0x8005C054
> 
> I need write to that register value 0x054 ?

Please don't expect others doing the work for you.  Stefano already
pointed you to the right section of the manual, so please invest your
own time and efforts to read it and to figure out what needs to be
done.

If you can't figure out what needs to be done, you might consider
hiring an expert.

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
Real programmers can write assembly code in any language.   :-)
  - Larry Wall in  <8...@jpl-devvax.jpl.nasa.gov>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 2/2] ARM: at91: sama5d3: mmc: save enviroment as a fat file (uboot.env)

[Josh Wu]

This patch will save U-Boot environment as a file: uboot.env, in FAT partition
instead of saving it in raw sector of SD card.

Since saving environment in raw sector has risk of corrupting the SD card and
only can use very small size. Save as a FAT file has no above limitation.

Signed-off-by: Josh Wu 
---
 include/configs/sama5d3xek.h |   10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/include/configs/sama5d3xek.h b/include/configs/sama5d3xek.h
index 5a6f0fc..a77ab5f 100644
--- a/include/configs/sama5d3xek.h
+++ b/include/configs/sama5d3xek.h
@@ -196,9 +196,13 @@
"bootm 0x2200 - 0x2100"
 #elif CONFIG_SYS_USE_MMC
 /* bootstrap + u-boot + env in sd card */
-#define CONFIG_ENV_IS_IN_MMC
-#define CONFIG_ENV_OFFSET  0x2000
-#define CONFIG_ENV_SIZE0x1000
+#define CONFIG_ENV_IS_IN_FAT
+#define CONFIG_FAT_WRITE
+#define FAT_ENV_INTERFACE  "mmc"
+#define FAT_ENV_FILE   "uboot.env"
+#define FAT_ENV_DEVICE 0
+#define FAT_ENV_PART   1
+#define CONFIG_ENV_SIZE0x4000
 #define CONFIG_BOOTCOMMAND "fatload mmc 0:1 0x2100 dtb; " \
"fatload mmc 0:1 0x2200 uImage; " \
"bootm 0x2200 - 0x2100"
-- 
1.7.9.5

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

[U-Boot] [PATCH 1/2] ARM: at91: at91sam9x5: mmc: save environment as a FAT file (uboot.env)

[Josh Wu]

This patch will save U-Boot environment as a file: uboot.env, in FAT partition
instead of saving it in raw sector of SD card.

Since saving environment in raw sector has risk of corrupting the SD card and
only can use very small size. Save as a FAT file has no above limitation.

Signed-off-by: Josh Wu 
---
 include/configs/at91sam9x5ek.h |   12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/include/configs/at91sam9x5ek.h b/include/configs/at91sam9x5ek.h
index ea9a50e..2cd4fae 100644
--- a/include/configs/at91sam9x5ek.h
+++ b/include/configs/at91sam9x5ek.h
@@ -205,11 +205,13 @@
"bootm 0x2200"
 #else /* CONFIG_SYS_USE_MMC */
 /* bootstrap + u-boot + env + linux in mmc */
-#define CONFIG_ENV_IS_IN_MMC
-/* For FAT system, most cases it should be in the reserved sector */
-#define CONFIG_ENV_OFFSET  0x2000
-#define CONFIG_ENV_SIZE0x1000
-#define CONFIG_SYS_MMC_ENV_DEV 0
+#define CONFIG_ENV_IS_IN_FAT
+#define CONFIG_FAT_WRITE
+#define FAT_ENV_INTERFACE  "mmc"
+#define FAT_ENV_FILE   "uboot.env"
+#define FAT_ENV_DEVICE 0
+#define FAT_ENV_PART   1
+#define CONFIG_ENV_SIZE0x4000
 #endif
 
 #ifdef CONFIG_SYS_USE_MMC
-- 
1.7.9.5

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

[U-Boot] No single character output after update to latest u-boot on pandaboard

[Chao Xu]

Hi,

I'm trying to compile the latest u-boot for my Pandaboard Rev A2. The
SD card was originally loaded with a working version of 12.04
linaro-unbunt-developer image. Early printk is enabled in the original
image.

I followed this guide (http://elinux.org/Panda_How_to_MLO_%26_u-boot)
and here is what I did:
1. export ARCH=arm
2. export CROSS_COMPILE=arm-linux-gnueabi-
3. make omap4_panda_config
4.make
5. cp MLO u-boot.img /SDCARD/boot/

But when switching on my Panda, there is no output from the serial
port. And the heartbeat LED is always off. (When every thing works, it
is on when booting, and blinks after booting finished).

I don't have any former experience with u-boot. So please let me know
if there is any more info I should provide.

Any help would be much appreciated! Thank you!

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

Re: [U-Boot] [PULL] u-boot-atmel/master -> u-boot-arm/master

[Albert ARIBAUD]

Hi Andreas,

On Wed, 13 Nov 2013 22:24:59 +0100, Andreas Bießmann
 wrote:

> Dear Albert Aribaud,
> 
> please pull the following changes into u-boot-arm/master.
> 
> The following changes since commit 56eb3da43fab5990a4b7bc118b76c7cae2ceb140:
> 
>   arm, am335x: update for the siemens boards (2013-11-12 09:53:59 -0500)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-atmel.git master
> 
> for you to fetch changes up to 6182e9546aa602c97d55963e133c7e1a85ec:
> 
>   ARM: at91: sama5d3: add support for sama5d36 chip (2013-11-13 22:18:18 
> +0100)

Sorry for the delay -- on it right now.

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

Re: [U-Boot] [PATCH 0/9] ARMv7: add PSCI support to u-boot

[Anup Patel]

On 22 November 2013 07:24, Christoffer Dall  wrote:
> On 21 November 2013 07:04, Marc Zyngier  wrote:
>> Hi Rob,
>>
>> On 21/11/13 14:28, Rob Herring wrote:
>>> On Thu, Nov 21, 2013 at 2:59 AM, Marc Zyngier  wrote:
 PSCI is an ARM standard that provides a generic interface that
 supervisory software can use to manage power in the following
 situations:
 - Core idle management
 - CPU hotplug
 - big.LITTLE migration models
 - System shutdown and reset

 It basically allows the kernel to offload these tasks to the firmware,
 and rely on common kernel side code.

 More importantly, it gives a way to ensure that CPUs enter the kernel
 at the appropriate exception level (ie HYP mode, to allow the use of
 the virtualization extensions), even across events like CPUs being
 powered off/on or suspended.

 The main idea here is to reuse some of the existing u-boot code to
 create a separate blob that can live in SRAM (or a reserved page of
 memory), containing a secure monitor that will implement the PSCI
 operations. This code will still be alive when u-boot is long gone,
 hence the need for a piece of memory that will not be touched by the
 OS.
>>>
>>> Interesting. As a separate binary, I'm not sure this belongs or
>>> benefits from being in u-boot. I would like to see this as a more
>>> generic secure firmware loader or PSCI code be a part of u-boot code
>>> directly. With the latter, you could extend it beyond PSCI to things
>>> like env variable access (basically equivalent to UEFI runtime
>>> services). I'm not saying we should do that though.
>>
>> So I started this by having something that was actually part of u-boot,
>> and copying itself into SRAM, patching stuff as it went. The net result
>> was that I was reinventing a runtime linker. Needless to say, I gave up
>> quickly... ;-)
>>
>
> I'm curious; why did you need to reinvent a linker?  This was all just
> assembly right? Could you not write it as position independent code
> and just copy a blob of code and be done with it?

We really cannot assume that all power related programming sequence
for SOCs will simple and easy to fit in position independent code. I am
not saying it is impossible but it will not be easy to translate complex
C code to position independent assembly code.

An Independent binary of a secured firmware makes more sense here.
Also, if secured firmware is an independent binary then it need not be
open source.

--
Anup

>
> (I'm sure it's not that simple, but I'm curious to know why).
>
> -Christoffer
> ___
> kvmarm mailing list
> kvm...@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] patchwork does not pick my patch

[Jeremy Kerr]

Hi all,

> On 11/21/2013 12:14 PM, Masahiro Yamada wrote:
>> Hi.
>>
>> I posted a patch to change a file permission.
>> This:
>> http://lists.denx.de/pipermail/u-boot/2013-November/167573.html
>>
>> and again:
>> http://lists.denx.de/pipermail/u-boot/2013-November/167608.html
>>
>>
>> But my patch would not appear on patchwork.
>> (Maybe because there is no diff line.)
> 
> I think so too. There is some handling for renames without patch in
> patchwork, but I think there is no handling for just file permission
> changes. That should be fixed in patchwork then.

Yep, that's correct - there's no support for these permission changes at
present. I'll add that!

Cheers,


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

Re: [U-Boot] [PATCH] JFFS2: Fix undefined reference to `__aeabi_uldivmod' error

[Gupta, Pekon]

> From: u-boot-boun...@lists.denx.de [mailto:u-boot-
> Wolfgang,
> 
> good morning.
> 
> On Monday, October 28, 2013 04:07 AM, Wolfgang Denk wrote:
> > In message <1382865251-17302-1-git-send-email...@denx.de> I wrote:
> >> Building boards that have JFFS2 support enabled will fail when using
> >> U-Boot's builtin GCC library, for example like this:
> >>
> >> USE_PRIVATE_LIBGCC=yes ./MAKEALL omap3_evm
> >> ...
> >> fs/jffs2/libjffs2.o: In function `jffs2_1pass_build_lists':
> >> fs/jffs2/jffs2_1pass.c:1441: undefined reference to `__aeabi_uldivmod'
> >>
> >> This is caused by a u64 / u32 division in jffs2_1pass.c; the problem
> >> can be avoided by using do_div() instead of plain division.
> >>
> >> Signed-off-by: Wolfgang Denk 
> >> Reported-by: Chris Ruehl 
> >> Cc: Chris Ruehl 
> > I would like to withdraw this patch.
> >
> > It appears nobody has been running a MAKEALL with
> USE_PRIVATE_LIBGCC
> > enabled for a long, long time.  There are a number of other places
> > that show similar problems.  Instead of fixing these one by one, I
> > think we should rather bundle this.
> >
> > I'm working on a more complete patch (or patch series).
> >
> > Best regards,
> >
> > Wolfgang Denk
> >
> The test of your patch works with the linaro 2013.09 tool chain.
> 
> I had to add the missing header only
> #include  which is required for the build.
> 
> diff --git a/fs/jffs2/jffs2_1pass.c b/fs/jffs2/jffs2_1pass.c
> index c856983..e6b50de 100644
> --- a/fs/jffs2/jffs2_1pass.c
> +++ b/fs/jffs2/jffs2_1pass.c
> @@ -121,6 +121,7 @@
>   #include 
>   #include 
>   #include 
> +#include 
> 
>   #include "jffs2_private.h"
> 
> @@ -1438,7 +1439,7 @@ jffs2_1pass_build_lists(struct part_info * part)
>   {
>  struct b_lists *pL;
>  struct jffs2_unknown_node *node;
> -   u32 nr_sectors = part->size/part->sector_size;
> +   u32 nr_sectors = do_div(part->size,part->sector_size);
>  u32 i;
>  u32 counter4 = 0;
>  u32 counterF = 0;
> 

Thanks for fixing this..
Tested-by: Pekon Gupta 

Please merge this soon, so that ./MAKEALL is clean.

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

Re: [U-Boot] [PATCH 1/4] net/fman: Add support for 10GEC3 and 10GEC4

[Shengzhou Liu]

> -Original Message-
> From: York Sun [mailto:york...@freescale.com]
> Sent: Friday, November 22, 2013 1:51 AM
> To: Liu Shengzhou-B36685; u-boot@lists.denx.de
> Subject: Re: [PATCH 1/4] net/fman: Add support for 10GEC3 and 10GEC4
> 
> >  #ifdef CONFIG_SYS_FMAN_V3
> > -   if (fm_eth->type == FM_ETH_10G_E)
> > -   num += 8;
> > +   if (fm_eth->type == FM_ETH_10G_E) {
> > +   if (fm_eth->num >= 2)
> > +   num -= 2;
> > +   else
> > +   num += 8;
> > +   }
> 
> It would be nice if you can add some comments here.
> 
[Shengzhou] ok, will do.
> 
> > @@ -239,10 +245,14 @@ static void ft_fixup_port(void *blob, struct 
> > fm_eth_info
> *info, char *prop)
> >  * FM1_10GEC1 is enabled and  FM1_DTSEC9 is disabled, ensure that the
> >  * dual-role MAC is not disabled, ditto for other dual-role MACs.
> >  */
> 
> Revise this comment to match your change.
[Shengzhou] This comment doesn't need to revise, the comment takes FM1_10GEC1 
an example, 
then "ditto for other dual-role MACs", it still matches the change of this 
patch. Thanks.


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

Re: [U-Boot] [PATCH] phy: introduce structure fixed-link

[Shaohui Xie]

> -Original Message-
> From: York Sun [mailto:york...@freescale.com]
> Sent: Friday, November 22, 2013 2:03 AM
> To: shh@gmail.com; u-boot@lists.denx.de
> Cc: Xie Shaohui-B21989
> Subject: Re: [PATCH] phy: introduce structure fixed-link
> 
> On 11/14/2013 03:00 AM, shh@gmail.com wrote:
> > From: Shaohui Xie 
> >
> > fixed-link is used in kernel for PHY-less MAC, so introduce this
> > structure that U-boot can use it to fixup dtb dynamically.
> >
> > Signed-off-by: Shaohui Xie 
> > ---
> >  include/phy.h | 8 
> >  1 file changed, 8 insertions(+)
> >
> > diff --git a/include/phy.h b/include/phy.h index f0f522a..f86ffb9
> > 100644
> > --- a/include/phy.h
> > +++ b/include/phy.h
> > @@ -160,6 +160,14 @@ struct phy_device {
> > u32 flags;
> >  };
> >
> > +struct fixed_link {
> > +   int phy_id;
> > +   int duplex;
> > +   int link_speed;
> > +   int pause;
> > +   int asym_pause;
> > +};
> > +
> 
> How is this code used? Do you have other patches following?
> 

[S.H] Shengzhou has posted patches, link: 
http://patchwork.ozlabs.org/patch/291206/

It uses as below (quoted some codes):

+   switch (srds_s1) {
+   case 0x66: /* XFI interface */
+   case 0x6b:
+   case 0x6c:
+   case 0x6d:
+   case 0x71:
+   f_link.phy_id = port;
+   f_link.duplex = 1;
+   f_link.link_speed = 1;
+   f_link.pause = 0;
+   f_link.asym_pause = 0;
+   /* no PHY for XFI */
+   fdt_delprop(fdt, offset, "phy-handle");
+   fdt_setprop(fdt, offset, "fixed-link", &f_link,
+   sizeof(f_link));
+   break;
+   default:
+   break;
+   }


Best Regards, 
Shaohui Xie

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

Re: [U-Boot] [PATCH] mx6sabresd: Fix wrong colors in LVDS display

[Liu Ying]

Hi Fabio,


2013/11/9 Fabio Estevam 

> Currently HDMI splash screen is selected by default on mx6sabresd boards.
>
> As LVDS is also always enabled, this causes incorrect colors to be
> displayed in
> the LVDS panel due to the different pixel format in HDMI and LVDS.
>
> Fix this by selecting the LVDS panel as the default splash output and also
> by
> ensuring that LVDS is turned off when HDMI output is active.
>
> Signed-off-by: Fabio Estevam 
> ---
>  board/freescale/mx6sabresd/mx6sabresd.c | 30
> ++
>  1 file changed, 22 insertions(+), 8 deletions(-)
>
> diff --git a/board/freescale/mx6sabresd/mx6sabresd.c
> b/board/freescale/mx6sabresd/mx6sabresd.c
> index 9dbe605..ba1f289 100644
> --- a/board/freescale/mx6sabresd/mx6sabresd.c
> +++ b/board/freescale/mx6sabresd/mx6sabresd.c
> @@ -249,8 +249,21 @@ static int detect_hdmi(struct display_info_t const
> *dev)
> return readb(&hdmi->phy_stat0) & HDMI_DVI_STAT;
>  }
>
> +static void disable_lvds(struct display_info_t const *dev)
> +{
> +   struct iomuxc *iomux = (struct iomuxc *)IOMUXC_BASE_ADDR;
> +
> +   int reg = readl(&iomux->gpr[2]);
> +
> +   reg &= ~(IOMUXC_GPR2_LVDS_CH0_MODE_DISABLED  |
> + IOMUXC_GPR2_LVDS_CH1_MODE_ENABLED_DI0);
>

Should change the above logic to this to make sure both the LDB two
channels are disabled correctly:
reg &= ~(IOMUXC_GPR2_LVDS_CH0_MODE_MASK | IOMUXC_GPR2_LVDS_CH1_MODE_MASK);

Otherwise, Acked-by: Liu Ying 
>

Regards,
Liu Ying

+
> +   writel(reg, &iomux->gpr[2]);
> +}
> +
>  static void do_enable_hdmi(struct display_info_t const *dev)
>  {
> +   disable_lvds(dev);
> imx_enable_hdmi_phy();
>  }
>
> @@ -263,14 +276,15 @@ static void enable_lvds(struct display_info_t const
> *dev)
>IOMUXC_GPR2_DATA_WIDTH_CH1_24BIT;
> writel(reg, &iomux->gpr[2]);
>  }
> +
>  static struct display_info_t const displays[] = {{
> .bus= -1,
> .addr   = 0,
> -   .pixfmt = IPU_PIX_FMT_RGB24,
> -   .detect = detect_hdmi,
> -   .enable = do_enable_hdmi,
> +   .pixfmt = IPU_PIX_FMT_LVDS666,
> +   .detect = NULL,
> +   .enable = enable_lvds,
> .mode   = {
> -   .name   = "HDMI",
> +   .name   = "Hannstar-XGA",
> .refresh= 60,
> .xres   = 1024,
> .yres   = 768,
> @@ -286,11 +300,11 @@ static struct display_info_t const displays[] = {{
>  } }, {
> .bus= -1,
> .addr   = 0,
> -   .pixfmt = IPU_PIX_FMT_LVDS666,
> -   .detect = NULL,
> -   .enable = enable_lvds,
> +   .pixfmt = IPU_PIX_FMT_RGB24,
> +   .detect = detect_hdmi,
> +   .enable = do_enable_hdmi,
> .mode   = {
> -   .name   = "Hannstar-XGA",
> +   .name   = "HDMI",
> .refresh= 60,
> .xres   = 1024,
> .yres   = 768,
> --
> 1.8.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 0/9] ARMv7: add PSCI support to u-boot

[Christoffer Dall]

On 21 November 2013 07:04, Marc Zyngier  wrote:
> Hi Rob,
>
> On 21/11/13 14:28, Rob Herring wrote:
>> On Thu, Nov 21, 2013 at 2:59 AM, Marc Zyngier  wrote:
>>> PSCI is an ARM standard that provides a generic interface that
>>> supervisory software can use to manage power in the following
>>> situations:
>>> - Core idle management
>>> - CPU hotplug
>>> - big.LITTLE migration models
>>> - System shutdown and reset
>>>
>>> It basically allows the kernel to offload these tasks to the firmware,
>>> and rely on common kernel side code.
>>>
>>> More importantly, it gives a way to ensure that CPUs enter the kernel
>>> at the appropriate exception level (ie HYP mode, to allow the use of
>>> the virtualization extensions), even across events like CPUs being
>>> powered off/on or suspended.
>>>
>>> The main idea here is to reuse some of the existing u-boot code to
>>> create a separate blob that can live in SRAM (or a reserved page of
>>> memory), containing a secure monitor that will implement the PSCI
>>> operations. This code will still be alive when u-boot is long gone,
>>> hence the need for a piece of memory that will not be touched by the
>>> OS.
>>
>> Interesting. As a separate binary, I'm not sure this belongs or
>> benefits from being in u-boot. I would like to see this as a more
>> generic secure firmware loader or PSCI code be a part of u-boot code
>> directly. With the latter, you could extend it beyond PSCI to things
>> like env variable access (basically equivalent to UEFI runtime
>> services). I'm not saying we should do that though.
>
> So I started this by having something that was actually part of u-boot,
> and copying itself into SRAM, patching stuff as it went. The net result
> was that I was reinventing a runtime linker. Needless to say, I gave up
> quickly... ;-)
>

I'm curious; why did you need to reinvent a linker?  This was all just
assembly right? Could you not write it as position independent code
and just copy a blob of code and be done with it?

(I'm sure it's not that simple, but I'm curious to know why).

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

Re: [U-Boot] [PATCH 3/9] ARM: HYP/non-sec: add a barrier after setting SCR.NS==1

[Christoffer Dall]

On 21 November 2013 00:59, Marc Zyngier  wrote:
> A CP15 instruction execution can be reordered, requiring an
> isb to be sure it is executed in program order.
>
> Signed-off-by: Marc Zyngier 
> ---
>  arch/arm/cpu/armv7/nonsec_virt.S | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/cpu/armv7/nonsec_virt.S 
> b/arch/arm/cpu/armv7/nonsec_virt.S
> index 29987cd..648066f 100644
> --- a/arch/arm/cpu/armv7/nonsec_virt.S
> +++ b/arch/arm/cpu/armv7/nonsec_virt.S
> @@ -47,6 +47,7 @@ _secure_monitor:
>  #endif
>
> mcr p15, 0, r1, c1, c1, 0   @ write SCR (with NS bit set)
> +   isb
>
>  #ifdef CONFIG_ARMV7_VIRT
> mrceq   p15, 0, r0, c12, c0, 1  @ get MVBAR value
> --
> 1.8.2.3
>
Does this matter?  Are we not still in monitor mode and therefore
secure and the exception return below will surely be ordered by the
cpu after the mcr, right? or no?

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

Re: [U-Boot] Which u-boot tree to start for dra7xx_evm

[Tom Rini]

On Thu, Nov 21, 2013 at 04:14:56PM -0500, Richard Retanubun wrote:
> Hi Tom,
> 
> Sorry to keep bugging you today.
> 
> I was just informed by one of my colleagues that there are another ti uboot 
> git tree
> 
> So out of these three:
> [1] 
> http://git.omapzoom.org/?p=repo/u-boot.git;a=shortlog;h=refs/heads/p-ti-u-boot-2013.04
> [2] http://git.ti.com/ti-u-boot/ti-u-boot/commits/ti-u-boot-2013.10
> [3] denx's master
> 
> Which one should we use if we want to get as close to mainline
> with dra7xx_evm capable of booting from eMMC in RAW mode?
> 
> Our eval platform comes with sources from [1] and boots all the way to the 
> linux.
> The ones built from [2] or [3] are not booting into the linux in the uSD.
> 
> it errors out like this:
> 
> U-Boot 2013.10-00095-g996f0c4 (Nov 21 2013 - 19:53:47)
> 
> CPU  : DRA752 ES1.0
> Board: DRA7xx
> I2C:   ready
> DRAM:  1.5 GiB
> MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
> Using default environment
> 
> SATA link 0 timeout.
> AHCI 0001.0300 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
> flags: 64bit ncq stag pm led clo only pmp pio slum part ccc apst
> scanning bus for devices...
> Found 0 device(s).
> Net:not set. Validating first E-fuse MAC
> cpsw
> Hit any key to stop autoboot:  0
> mmc0 is current device
> SD/MMC found on device 0
> reading uEnv.txt
> ** Unable to read file uEnv.txt **
> ** File not found /boot/zImage **
> mmc1(part 0) is current device
> SD/MMC found on device 1
> ** Unrecognized filesystem type **
> ** No partition table - mmc 1 **
> 
> 
> If it is a matter of porting some patches, we are willing to help test and 
> mainline
> if it means we can get denx-master for dra7xx working.

So, from the log above I assume that's the ti-u-boot-2013.10 tree, as
that as SATA patches that will be merged into mainline soon.  From the
[1] tree, stop the boot process and printenv bootcmd, and copy that info
over (or see what their include/configs/dra7xx_evm.h says the bootcmd
is) as the error you show is just that the default location for the
kernel isn't correct with the Android rootfs you're using.  Mainline
also doesn't have CONFIG_EFI_PARTITION set which is why it can't read
the partition table.  That's an easy patch to make and post :)

-- 
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 1/9] ARM: HYP/non-sec: fix alignment requirements for vectors

[Andre Przywara]

On 11/21/2013 09:59 AM, Marc Zyngier wrote:

Make sure the vectors are aligned on a 32 byte boundary, not
the code that deals with it...


I think that patch was posted before, and I already acked it, but it 
didn't make it into some tree.

Albert, can you please take this?
Also a candidate for the stable tree.



Signed-off-by: Marc Zyngier 


Acked-by: Andre Przywara 

Regards,
Andre.


---
  arch/arm/cpu/armv7/nonsec_virt.S | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/cpu/armv7/nonsec_virt.S b/arch/arm/cpu/armv7/nonsec_virt.S
index 24b4c18..29987cd 100644
--- a/arch/arm/cpu/armv7/nonsec_virt.S
+++ b/arch/arm/cpu/armv7/nonsec_virt.S
@@ -14,6 +14,8 @@
  .arch_extension sec
  .arch_extension virt

+   .align  5   @ Minimal alignment for vectors
+
  /* the vector table for secure state and HYP mode */
  _monitor_vectors:
.word 0 /* reset */
@@ -32,7 +34,6 @@ _monitor_vectors:
   * to non-secure state.
   * We use only r0 and r1 here, due to constraints in the caller.
   */
-   .align  5
  _secure_monitor:
mrc p15, 0, r1, c1, c1, 0   @ read SCR
bic r1, r1, #0x4e   @ clear IRQ, FIQ, EA, nET bits



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

[U-Boot] [PATCH] ARM: fix the standalone programs

[Jeroen Hofstee]

The standalone programs do not use the api calls, but rely
directly on u-boot variable gd->jt for the jump table. Commit
fe1378a - "ARM: use r9 for gd" changed the register holding
the address of gd, but the assembly code in the standalone
examples was not updated accordingly. This broke the programs
on ARM relying on the jumptable in the v2013.10 release.
This patch unbricks them by using the correct register.

Cc: Michal Simek 
Cc: Albert ARIBAUD 
Signed-off-by: Jeroen Hofstee 
---
 examples/standalone/stubs.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/examples/standalone/stubs.c b/examples/standalone/stubs.c
index 8fb1765..5d2ab56 100644
--- a/examples/standalone/stubs.c
+++ b/examples/standalone/stubs.c
@@ -40,14 +40,14 @@ gd_t *global_data;
: : "i"(offsetof(gd_t, jt)), "i"(XF_ ## x * sizeof(void *)) : "r11");
 #elif defined(CONFIG_ARM)
 /*
- * r8 holds the pointer to the global_data, ip is a call-clobbered
+ * r9 holds the pointer to the global_data, ip is a call-clobbered
  * register
  */
 #define EXPORT_FUNC(x) \
asm volatile (  \
 "  .globl " #x "\n"\
 #x ":\n"   \
-"  ldr ip, [r8, %0]\n" \
+"  ldr ip, [r9, %0]\n" \
 "  ldr pc, [ip, %1]\n" \
: : "i"(offsetof(gd_t, jt)), "i"(XF_ ## x * sizeof(void *)) : "ip");
 #elif defined(CONFIG_MIPS)
-- 
1.8.3.2

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

Re: [U-Boot] dra7xx: booting from eMMC raw boot partition

[Rao, Shankar]

+Amar
Amar, can you help Richard with eMMC booting?

Thanks
Shankar


-Original Message-
From: Richard Retanubun [mailto:richardretanu...@ruggedcom.com] 
Sent: Wednesday, November 20, 2013 4:28 PM
To: Rao, Shankar; Shklyarman, Michael
Cc: SIFW-Richard Retanubun; u-boot@lists.denx.de
Subject: dra7xx: booting from eMMC raw boot partition

Hi Shankar and Michael,

I am using the ti dra7xx_evm platform, which comes with a Micron MTFC4GVMEA-4M 
IT device that has two 16MB boot partitions.
I want to load the MLO and uboot into the eMMC's boot partition and boot from 
it in eMMC automotive peripheral mode.

I am able to write the MLO into the beginning of /dev/mmcblk1boot0 or 
/dev/mmcblk1boot1 or /dev/mmcblk1 (using dd) I then used mmc-utils to make sure 
that CONFIG_PARTITION in the eMMC's extcsd is set to allow booting from boot1 
(with ACK).

However, the CPU does not print anything back on the console...

The only way I can get raw eMMC boot mode to work is if I put the MLO on 
/dev/mmcblk1 (which is the user data area).

by working, I mean that it prints something like this:

U-Boot SPL 2013.04-09402-gc831bca (Nov 19 2013 - 22:05:38)
DRA752 ES1.0
OMAP SD/MMC: 1
...

I have tried the MLO built from both sources from both uboot master from denx 
and p-ti-u-boot-2013.04 from omapzoom.

I think the SYSBOOT[5:0] settings are correct because it is able to boot the 
MLO from the eMMC's user data area.

Does the MLO for raw boot mode needs to be different that the MLO for raw user 
data area?
Is there an errata limitation with the dra7xx for booting MLO from eMMC boot 
partition?

Am I missing something obvious?

Thank you for everyone's time.
--
-- Richard Retanubun
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Which u-boot tree to start for dra7xx_evm

[Richard Retanubun]

Hi Tom,

Sorry to keep bugging you today.

I was just informed by one of my colleagues that there are another ti uboot git 
tree

So out of these three:
[1] 
http://git.omapzoom.org/?p=repo/u-boot.git;a=shortlog;h=refs/heads/p-ti-u-boot-2013.04
[2] http://git.ti.com/ti-u-boot/ti-u-boot/commits/ti-u-boot-2013.10
[3] denx's master

Which one should we use if we want to get as close to mainline
with dra7xx_evm capable of booting from eMMC in RAW mode?

Our eval platform comes with sources from [1] and boots all the way to the 
linux.
The ones built from [2] or [3] are not booting into the linux in the uSD.

it errors out like this:

U-Boot 2013.10-00095-g996f0c4 (Nov 21 2013 - 19:53:47)

CPU  : DRA752 ES1.0
Board: DRA7xx
I2C:   ready
DRAM:  1.5 GiB
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
Using default environment

SATA link 0 timeout.
AHCI 0001.0300 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
flags: 64bit ncq stag pm led clo only pmp pio slum part ccc apst
scanning bus for devices...
Found 0 device(s).
Net:not set. Validating first E-fuse MAC
cpsw
Hit any key to stop autoboot:  0
mmc0 is current device
SD/MMC found on device 0
reading uEnv.txt
** Unable to read file uEnv.txt **
** File not found /boot/zImage **
mmc1(part 0) is current device
SD/MMC found on device 1
** Unrecognized filesystem type **
** No partition table - mmc 1 **


If it is a matter of porting some patches, we are willing to help test and 
mainline
if it means we can get denx-master for dra7xx working.

Thanks for your time, Tom.
--
-- Richard Retanubun
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] FDT specification documents

[Scott Wood]

On Mon, 2013-11-04 at 10:50 +1300, Chris Packham wrote:
> Hi List,
> 
> I was looking at the u-boot wiki page on FDT[1] and found that a
> number of the links to specifications are dead. I assume because of
> the whole Oracle/Sun acquisition and bridge burning.
> 
> I've done a bit of searching but it would seem terms like "FDT spec"
> are a bit too generic to yield useful results.
> 
> Does anybody know where these documents can be found? Or does anyone
> have copies that could be hosted somewhere?

http://www.openfirmware.org/1275/home.html
https://www.power.org/documentation/epapr-version-1-1/
Documentation/devicetree/booting-without-of.txt in Linux

-Scott



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

Re: [U-Boot] [PATCH 1/5] mx6sabre{auto, sd}: Change FDT loading address to avoid overlaping

[Otavio Salvador]

On Thu, Nov 21, 2013 at 7:00 AM, Stefano Babic  wrote:
> Hi Otavio, Jason, Fabio,
>
> On 18/11/2013 20:39, Otavio Salvador wrote:
>
>>
>> What is the final decision on this? I have the same change for many
>> boards which are/will be supported by 3.10.
>>
>
> You're right, we need a decision. As far as I read, there is no
> explanation why this change is required. As Fabio points out, dtb is
> loaded before the kernel and this should avoid an overlap. It will be
> very nice if Jason could better explain the issue, because I admit I
> have not understood why it happens.
>
> Maybe is DTB loaded after the kernel on Freescale's U-Boot ?
>
> This is clearly a work-around for a bug in Freescale's kernel 3.10, as
> we have no problems with other kernels. I booted mainline kernel
> 3.11/3.12 on a i.MX6 without this issue.
>
> However, I could still merge the patch if we can at least have the
> following answers:
>
> - why is there the overlap if the kernel is loaded after DTB (Fabio's
> question) ?
> - add the explanation to the commit message (so V2 is required, this is
> also a Wolfgang's comment).
> - of course, the patch should generate a problem with other kernels. It
> should not be, but a couple of tested-by will be nice.
>
> As the patchset fixes the same issue, I would prefer if the patchset is
> squashed into a single patch because it fixes a single issue and we can
> have only one "extended" commit message with the whole explanation.

Ok; once we get Jason's feedback I rework the patch and send.

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] soft i2c behaviour on address not ed

[Eibach, Dirk]

While debugging an I2C problem I found in soft_i2c_read() and
soft_i2c_write():

if(write_byte(addr >> shift)) {
PRINTD("i2c_read, address not ed\n");
return(1);
}

and

if(write_byte(addr >> shift)) {
PRINTD("i2c_write, address not ed\n");
return(1);
}

This means that these functions are left without sending a STOP
condition to the bus and with SCL held low. Is that really intended?

Cheers
Dirk

Besuchen Sie unseren Blog auf
http://blog.gdsys.de

oder folgen Sie uns auf:
twitter: http://twitter.com/#!/gdsys
facebook: http://www.facebook.com/pages/Guntermann-Drunck-GmbH/318396891518396
Google+ : https://plus.google.com/100228872787564309232/ 
YouTube: http://www.youtube.com/user/GuntermannDrunck

Guntermann & Drunck GmbH Systementwicklung 
Dortmunder Str. 4a 
D-57234 Wilnsdorf - Germany 
Tel: +49 (0) 27 39 / 89 01 - 100  Fax: +49 (0) 27 39 / 89 01 - 120 
E-Mail: mailto:sa...@gdsys.de Web: http://www.gdsys.de

Geschaeftsfuehrer: 
Udo Guntermann - Martin Drunck - Reiner Ruelmann
HRB 2884, Amtsgericht Siegen - WEEE-Reg.-Nr. DE30763240
USt.-Id.-Nr. DE 126575222 - Steuer-Nr. 342 / 5835 / 1041

DQS-zertifiziert nach ISO 9001:2008





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

Re: [U-Boot] [PATCH V2 13/14] ARM: AM43xx: GP_EVM: Add support for DDR3

[Vaibhav Bedia]

On Thu, Nov 21, 2013 at 1:18 AM, Lokesh Vutla  wrote:
[...]

> -/*
> - * Get SDRAM type connected to EMIF.
> - * Assuming similar SDRAM parts are connected to both EMIF's
> - * which is typically the case. So it is sufficient to get
> - * SDRAM type from EMIF1.
> - */
> -u32 emif_sdram_type()
> -{
> -   struct emif_reg_struct *emif = (struct emif_reg_struct *)EMIF1_BASE;
> -
> -   return (readl(&emif->emif_sdram_config) &
> -   EMIF_REG_SDRAM_TYPE_MASK) >> EMIF_REG_SDRAM_TYPE_SHIFT;
> -}
> -
>  static inline u32 get_mr(u32 base, u32 cs, u32 mr_addr)
>  {
> u32 mr;
> diff --git a/arch/arm/include/asm/arch-am33xx/ddr_defs.h 
> b/arch/arm/include/asm/arch-am33xx/ddr_defs.h
> index c98ab7f..646e50f 100644
> --- a/arch/arm/include/asm/arch-am33xx/ddr_defs.h
> +++ b/arch/arm/include/asm/arch-am33xx/ddr_defs.h
> @@ -138,6 +138,14 @@
>  #define  LPDDR2_DATA2_IOCTRL_VALUE   0x2294
>  #define  LPDDR2_DATA3_IOCTRL_VALUE   0x2294
>
> +#define  DDR3_ADDRCTRL_WD0_IOCTRL_VALUE 0x
> +#define  DDR3_ADDRCTRL_WD1_IOCTRL_VALUE 0x
> +#define  DDR3_ADDRCTRL_IOCTRL_VALUE   0x84
> +#define  DDR3_DATA0_IOCTRL_VALUE   0x84
> +#define  DDR3_DATA1_IOCTRL_VALUE   0x84
> +#define  DDR3_DATA2_IOCTRL_VALUE   0x84
> +#define  DDR3_DATA3_IOCTRL_VALUE   0x84
> +
>  /**
>   * Configure DMM
>   */
> diff --git a/arch/arm/include/asm/emif.h b/arch/arm/include/asm/emif.h
> index ce6b229..b4a8c9f 100644
> --- a/arch/arm/include/asm/emif.h
> +++ b/arch/arm/include/asm/emif.h
> @@ -1151,6 +1151,20 @@ static inline u32 get_emif_rev(u32 base)
> >> EMIF_REG_MAJOR_REVISION_SHIFT;
>  }
>
> +/*
> + * Get SDRAM type connected to EMIF.
> + * Assuming similar SDRAM parts are connected to both EMIF's
> + * which is typically the case. So it is sufficient to get
> + * SDRAM type from EMIF1.
> + */
> +static inline u32 emif_sdram_type(void)
> +{
> +   struct emif_reg_struct *emif = (struct emif_reg_struct *)EMIF1_BASE;
> +
> +   return (readl(&emif->emif_sdram_config) &
> +   EMIF_REG_SDRAM_TYPE_MASK) >> EMIF_REG_SDRAM_TYPE_SHIFT;
> +}
> +

This change don't make any sense to me. How are the EMIF register bits
any indication
of what memory time is used especially for DDR2/3?

[...]
>
> +static void enable_vtt_regulator(void)
> +{
> +   u32 temp;
> +
> +   /* enable module */
> +   writel(0x0, AM33XX_GPIO0_BASE + OMAP_GPIO_CTRL);
> +
> +   /*enable output for GPIO0_22*/
> +   writel((1 << 22), AM33XX_GPIO0_BASE + OMAP_GPIO_SETDATAOUT);
> +   temp = readl(AM33XX_GPIO0_BASE + OMAP_GPIO_OE);
> +   temp = temp & ~(1 << 22);
> +   writel(temp, AM33XX_GPIO0_BASE + OMAP_GPIO_OE);
> +}
> +

No magic nos. please. I think you have a #def the pin used for VTT regulator
in the config file - makes it simpler for others who design their own board.

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

Re: [U-Boot] [PATCH V2 12/14] ARM: AM43xx: EPOS_EVM: Add support for LPDDR2

[Vaibhav Bedia]

On Thu, Nov 21, 2013 at 1:18 AM, Lokesh Vutla  wrote:
> AM4372 EPOS EVM has 1GB LPDDR2(Part no: MT42L256M32D2LG-25 WT:A)
> Adding LPDDR2 init sequence and register details for the same.
> Below is the brief description of LPDDR2 init sequence:
> -> Configure VTP
> -> Configure DDR IO settings
> -> Disable initialization and refreshes until EMIF registers are programmed.
> -> Program Timing registers
> -> Program PHY control and Temp alert and ZQ config registers.
> -> Enable initialization and refreshes and configure SDRAM CONFIG register
> -> Wait till initialization is complete and the configure MR registers.
>

This patch does too many things, some of which affects AM335x and needs to be
split up. I lost track of what you were doing as i scrolled down :\

> Signed-off-by: Lokesh Vutla 
> ---
>  arch/arm/cpu/armv7/am33xx/ddr.c|  147 
> +++-
>  arch/arm/cpu/armv7/am33xx/emif4.c  |   25 +++-
>  arch/arm/include/asm/arch-am33xx/clocks_am33xx.h   |3 +
>  arch/arm/include/asm/arch-am33xx/cpu.h |5 +
>  arch/arm/include/asm/arch-am33xx/ddr_defs.h|   33 -
>  arch/arm/include/asm/arch-am33xx/hardware_am43xx.h |1 +
>  arch/arm/include/asm/emif.h|   12 ++
>  board/isee/igep0033/board.c|   10 +-
>  board/phytec/pcm051/board.c|   12 +-
>  board/siemens/dxr2/board.c |   10 +-
>  board/siemens/pxm2/board.c |   10 +-
>  board/siemens/rut/board.c  |   10 +-
>  board/ti/am335x/board.c|   40 +-
>  board/ti/am43xx/board.c|   66 +
>  board/ti/ti814x/evm.c  |4 +-
>  board/ti/ti816x/evm.c  |   12 +-
>  16 files changed, 373 insertions(+), 27 deletions(-)
>
> diff --git a/arch/arm/cpu/armv7/am33xx/ddr.c b/arch/arm/cpu/armv7/am33xx/ddr.c
> index fa697c7..fbee51d 100644
> --- a/arch/arm/cpu/armv7/am33xx/ddr.c
> +++ b/arch/arm/cpu/armv7/am33xx/ddr.c
> @@ -36,6 +36,74 @@ static struct ddr_data_regs *ddr_data_reg[2] = {
>  static struct ddr_cmdtctrl *ioctrl_reg = {
> (struct ddr_cmdtctrl *)DDR_CONTROL_BASE_ADDR};
>
> +static inline u32 get_mr(int nr, u32 cs, u32 mr_addr)
> +{
> +   u32 mr;
> +
> +   mr_addr |= cs << EMIF_REG_CS_SHIFT;
> +   writel(mr_addr, &emif_reg[nr]->emif_lpddr2_mode_reg_cfg);
> +
> +   mr = readl(&emif_reg[nr]->emif_lpddr2_mode_reg_data);
> +   debug("get_mr: EMIF1 cs %d mr %08x val 0x%x\n", cs, mr_addr, mr);
> +   if (((mr & 0xff00) >>  8) == (mr & 0xff) &&
> +   ((mr & 0x00ff) >> 16) == (mr & 0xff) &&
> +   ((mr & 0xff00) >> 24) == (mr & 0xff))
> +   return mr & 0xff;
> +   else
> +   return mr;
> +}
> +
> +static inline void set_mr(int nr, u32 cs, u32 mr_addr, u32 mr_val)
> +{
> +   mr_addr |= cs << EMIF_REG_CS_SHIFT;
> +   writel(mr_addr, &emif_reg[nr]->emif_lpddr2_mode_reg_cfg);
> +   writel(mr_val, &emif_reg[nr]->emif_lpddr2_mode_reg_data);
> +}
> +
> +static void configure_mr(int nr, u32 cs)
> +{
> +   u32 mr_addr;
> +
> +   while (get_mr(nr, cs, LPDDR2_MR0) & LPDDR2_MR0_DAI_MASK)
> +   ;
> +   set_mr(nr, cs, LPDDR2_MR10, 0x56);
> +
> +   set_mr(nr, cs, LPDDR2_MR1, 0x43);
> +   set_mr(nr, cs, LPDDR2_MR2, 0x2);
> +
> +   mr_addr = LPDDR2_MR2 | EMIF_REG_REFRESH_EN_MASK;
> +   set_mr(nr, cs, mr_addr, 0x2);
> +}
> +
> +/*
> + * Configure EMIF4D5 registers and MR registers
> + */
> +void config_sdram_emif4d5(const struct emif_regs *regs, int nr)
> +{
> +   writel(0x0, &emif_reg[nr]->emif_pwr_mgmt_ctrl);
> +   writel(0x0, &emif_reg[nr]->emif_pwr_mgmt_ctrl_shdw);
> +   writel(0x1, &emif_reg[nr]->emif_iodft_tlgc);
> +   writel(regs->zq_config, &emif_reg[nr]->emif_zq_config);
> +
> +   writel(regs->temp_alert_config, 
> &emif_reg[nr]->emif_temp_alert_config);
> +   writel(regs->emif_rd_wr_lvl_rmp_win,
> +  &emif_reg[nr]->emif_rd_wr_lvl_rmp_win);
> +   writel(regs->emif_rd_wr_lvl_rmp_ctl,
> +  &emif_reg[nr]->emif_rd_wr_lvl_rmp_ctl);
> +   writel(regs->emif_rd_wr_lvl_ctl, &emif_reg[nr]->emif_rd_wr_lvl_ctl);
> +   writel(regs->emif_rd_wr_exec_thresh,
> +  &emif_reg[nr]->emif_rd_wr_exec_thresh);
> +
> +   clrbits_le32(&emif_reg[nr]->emif_sdram_ref_ctrl,
> +EMIF_REG_INITREF_DIS_MASK);
> +
> +   writel(regs->sdram_config, &emif_reg[nr]->emif_sdram_config);
> +   writel(regs->ref_ctrl, &emif_reg[nr]->emif_sdram_ref_ctrl);
> +
> +   configure_mr(nr, 0);
> +   configure_mr(nr, 1);
> +}
> +

Why can't this portion be shared with the other OMAPs? It looks to be
following a recommended sequence and i can't see why that would vary.

It's just too hard to review so many changes in a single patch so i'll stop
he

Re: [U-Boot] [PATCH v6 0/17] Driver model implementation, tests, demo and GPIO

[Simon Glass]

Hi,

On Thu, Nov 7, 2013 at 9:31 AM, Simon Glass  wrote:

>
> Note: If you are reviewing this code, but don't have a lot of time, please
> consider starting with the 'demo' driver (patch 'dm: Add a
> demonstration/example driver') since it clearly shows how devices and
> uclasses work. Much of this series consists of test code and plumbing, so
> is of less interest to driver authors.
>
>
I only have one small nit on this series (I will update this). Does that
mean everyone is happy for it to go in?

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

Re: [U-Boot] [PATCH V2] buildman: make board selector argument a regex

[Simon Glass]

Applied to u-boot-x86 branch buildpatman, thank you.



On Thu, Oct 10, 2013 at 10:46 AM, Simon Glass  wrote:

> On Thu, Oct 10, 2013 at 10:00 AM, Stephen Warren 
> wrote:
> > From: Stephen Warren 
> >
> > A common use-case is to build all boards for a particular SoC. This can
> > be achieved by:
> >
> > ./tools/buildman/buildman -b mainline_dev tegra20
> >
> > However, when the SoC is a member of a family of SoCs, and each SoC has
> > a different name, it would be even more useful to build all boards for
> > every SoC in that family. This currently isn't possible since buildman's
> > board selection command-line arguments are compared to board definitions
> > using pure string equality.
> >
> > To enable this, compare using a regex match instead. This matches
> > MAKEALL's handling of command-line arguments. This enables:
> >
> > (all Tegra)
> > ./tools/buildman/buildman -b mainline_dev tegra
> >
> > (all Tegra)
> > ./tools/buildman/buildman -b mainline_dev '^tegra.*$'
> >
> > (all Tegra20, Tegra30 boards, but not Tegra114)
> > ./tools/buildman/buildman -b mainline_dev 'tegra[23]'
> >
> > Signed-off-by: Stephen Warren 
>
> Nice README, thanks.
>
> Acked-by: Simon Glass 
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] patman: add Commit-notes tag and section

[Simon Glass]

Applied to u-boot-x86 branch buildpatman, thank you.

(I added a little note to the README to describe your excellent new feature)



On Tue, Nov 12, 2013 at 3:14 AM, Albert ARIBAUD
wrote:

> Sometimes a commit should have notes enclosed with it rather
> than withing the cover letter -- possibly even because there
> is no cover letter. Add a 'Commit-notes' tag, similar to the
> 'Series-notes' one; lines between this tag and the next END
> line are inserted in the patch right after the '---' commit
> delimiter.
>
> Signed-off-by: Albert ARIBAUD 
> ---
> Yes, I am writing this note through the very feature that
> this patch intends to add. If you can read it just below the
> commit delimiter line ('---') then the feature works.
>
> Well, at least, it works in this very case. :)
>
> Changes in v2:
> - changed tag name from 'Series-commit-notes' to 'Commit-notes'
>
>  tools/patman/README |  2 +-
>  tools/patman/commit.py  |  2 ++
>  tools/patman/patchstream.py | 43
> ---
>  3 files changed, 39 insertions(+), 8 deletions(-)
>
> diff --git a/tools/patman/README b/tools/patman/README
> index e6d3070..626dc86 100644
> --- a/tools/patman/README
> +++ b/tools/patman/README
> @@ -227,7 +227,7 @@ TEST=...
>  Change-Id:
>  Review URL:
>  Reviewed-on:
> -
> +Commit-: (except Commit-notes)
>
>  Exercise for the reader: Try adding some tags to one of your current
>  patch series and see how the patches turn out.
> diff --git a/tools/patman/commit.py b/tools/patman/commit.py
> index 900cfb3..89cce7f 100644
> --- a/tools/patman/commit.py
> +++ b/tools/patman/commit.py
> @@ -21,6 +21,7 @@ class Commit:
>  changes: Dict containing a list of changes (single line strings).
>  The dict is indexed by change version (an integer)
>  cc_list: List of people to aliases/emails to cc on this commit
> +notes: List of lines in the commit (not series) notes
>  """
>  def __init__(self, hash):
>  self.hash = hash
> @@ -28,6 +29,7 @@ class Commit:
>  self.tags = []
>  self.changes = {}
>  self.cc_list = []
> +self.notes = []
>
>  def AddChange(self, version, info):
>  """Add a new change line to the change list for a version.
> diff --git a/tools/patman/patchstream.py b/tools/patman/patchstream.py
> index c204523..684204c 100644
> --- a/tools/patman/patchstream.py
> +++ b/tools/patman/patchstream.py
> @@ -30,7 +30,10 @@ re_cover = re.compile('^Cover-letter:')
>  re_cover_cc = re.compile('^Cover-letter-cc: *(.*)')
>
>  # Patch series tag
> -re_series = re.compile('^Series-([a-z-]*): *(.*)')
> +re_series_tag = re.compile('^Series-([a-z-]*): *(.*)')
> +
> +# Commit series tag
> +re_commit_tag = re.compile('^Commit-([a-z-]*): *(.*)')
>
>  # Commit tags that we want to collect and keep
>  re_tag = re.compile('^(Tested-by|Acked-by|Reviewed-by|Cc): (.*)')
> @@ -90,6 +93,20 @@ class PatchStream:
>  if self.is_log:
>  self.series.AddTag(self.commit, line, name, value)
>
> +def AddToCommit(self, line, name, value):
> +"""Add a new Commit-xxx tag.
> +
> +When a Commit-xxx tag is detected, we come here to record it.
> +
> +Args:
> +line: Source line containing tag (useful for debug/error
> messages)
> +name: Tag name (part after 'Commit-')
> +value: Tag value (part after 'Commit-xxx: ')
> +"""
> +if name == 'notes':
> +self.in_section = 'commit-' + name
> +self.skip_blank = False
> +
>  def CloseCommit(self):
>  """Save the current commit into our commit list, and reset our
> state"""
>  if self.commit and self.is_log:
> @@ -138,7 +155,8 @@ class PatchStream:
>  line = line[4:]
>
>  # Handle state transition and skipping blank lines
> -series_match = re_series.match(line)
> +series_tag_match = re_series_tag.match(line)
> +commit_tag_match = re_commit_tag.match(line)
>  commit_match = re_commit.match(line) if self.is_log else None
>  cover_cc_match = re_cover_cc.match(line)
>  tag_match = None
> @@ -165,6 +183,9 @@ class PatchStream:
>  elif self.in_section == 'notes':
>  if self.is_log:
>  self.series.notes += self.section
> +elif self.in_section == 'commit-notes':
> +if self.is_log:
> +self.commit.notes += self.section
>  else:
>  self.warn.append("Unknown section '%s'" %
> self.in_section)
>  self.in_section = None
> @@ -178,7 +199,7 @@ class PatchStream:
>  self.commit.subject = line
>
>  # Detect the tags we want to remove, and skip blank lines
> -elif re_remove.match(line):
> +elif re_remove.match(line) and not commit_tag_match:
>  self.skip_blank = True
>
> 

Re: [U-Boot] [PATCH] buildman: fix README

[Simon Glass]

Applied to u-boot-x86 branch buildpatman, thank you.



On Tue, Nov 5, 2013 at 1:24 PM, Simon Glass  wrote:

> On Tue, Nov 5, 2013 at 3:37 AM, Andreas Bießmann
>  wrote:
> > This is a trivial fix for c'n'p error.
> >
> > Signed-off-by: Andreas Bießmann 
>
> Acked-by: Simon Glass 
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Please pull u-boot-x86.git

[Simon Glass]

The following changes since commit c2e5e802ecb7ab668ce9911b210ed68c804b349f:

  Merge branch 'master' of git://git.denx.de/u-boot-mips (2013-11-17
14:11:34 -0500)

are available in the git repository at:


  http://git.denx.de/u-boot-x86.git buildpatman

for you to fetch changes up to 8426d8b0899eb6a9845b3468662512a8da236241:

  buildman: make board selector argument a regex (2013-11-21 13:35:58 -0700)


Albert ARIBAUD (1):
  patman: add Commit-notes tag and section

Andreas Bießmann (1):
  buildman: fix README

Stephen Warren (1):
  buildman: make board selector argument a regex

 tools/buildman/README   | 16 +++-
 tools/buildman/board.py | 12 +++-
 tools/patman/README | 10 +-
 tools/patman/commit.py  |  2 ++
 tools/patman/patchstream.py | 43
---
 5 files changed, 69 insertions(+), 14 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V2 06/14] ARM: AM43XX: Add CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG support

[Vaibhav Bedia]

On Thu, Nov 21, 2013 at 1:18 AM, Lokesh Vutla  wrote:
[...]
> +#ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
> +   char safe_string[HDR_NAME_LEN + 1];
> +   struct am43xx_board_id header;
> +
> +   if (read_eeprom(&header) < 0)
> +   puts("Could not get board ID.\n");

Hmm... didn't the previous patch read the EEPROM?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V2 10/14] ARM: AM43xx: clocks: Update DPLL details for EPOS EVM

[Vaibhav Bedia]

On Thu, Nov 21, 2013 at 1:18 AM, Lokesh Vutla  wrote:
> Updating the Multiplier and Dividers values for all DPLLs for EPOS EVM.
> Following are the DPLL locking frequencies at OPP NOM:
> MPU locks at 600MHz
> Core locks at 1000MHz
> Per locks at 960MHz
> DDR locks at 266MHz
>

As mentioned earlier, this hardcoded frequency approach is really not
scalable when you have
more device variants coming in. Just look at the AM335x changes on how
this gets complicated.

> Signed-off-by: Lokesh Vutla 
> ---
>  arch/arm/cpu/armv7/am33xx/clock.c|   12 +++---
>  arch/arm/cpu/armv7/am33xx/clock_am33xx.c |   15 
>  arch/arm/cpu/armv7/am33xx/clock_am43xx.c |8 +--
>  arch/arm/include/asm/arch-am33xx/clock.h |7 +++---
>  board/ti/am43xx/board.c  |   38 
> +++---
>  board/ti/am43xx/board.h  |1 +
>  board/ti/am43xx/mux.c|5 
>  7 files changed, 69 insertions(+), 17 deletions(-)
>
> diff --git a/arch/arm/cpu/armv7/am33xx/clock.c 
> b/arch/arm/cpu/armv7/am33xx/clock.c
> index 8e5f3c6..0672798 100644
> --- a/arch/arm/cpu/armv7/am33xx/clock.c
> +++ b/arch/arm/cpu/armv7/am33xx/clock.c
> @@ -101,9 +101,15 @@ void do_setup_dpll(const struct dpll_regs *dpll_regs,
>  static void setup_dplls(void)
>  {
> const struct dpll_params *params;
> -   do_setup_dpll(&dpll_core_regs, &dpll_core);
> -   do_setup_dpll(&dpll_mpu_regs, &dpll_mpu);
> -   do_setup_dpll(&dpll_per_regs, &dpll_per);
> +
> +   params = get_dpll_core_params();
> +   do_setup_dpll(&dpll_core_regs, params);
> +
> +   params = get_dpll_mpu_params();
> +   do_setup_dpll(&dpll_mpu_regs, params);
> +
> +   params = get_dpll_per_params();
> +   do_setup_dpll(&dpll_per_regs, params);
> writel(0x300, &cmwkup->clkdcoldodpllper);
>
> params = get_dpll_ddr_params();
> diff --git a/arch/arm/cpu/armv7/am33xx/clock_am33xx.c 
> b/arch/arm/cpu/armv7/am33xx/clock_am33xx.c
> index fabe259..92142c8 100644
> --- a/arch/arm/cpu/armv7/am33xx/clock_am33xx.c
> +++ b/arch/arm/cpu/armv7/am33xx/clock_am33xx.c
> @@ -62,6 +62,21 @@ const struct dpll_params dpll_core = {
>  const struct dpll_params dpll_per = {
> 960, OSC-1, 5, -1, -1, -1, -1};
>
> +const struct dpll_params *get_dpll_mpu_params(void)
> +{
> +   return &dpll_mpu;
> +}
> +
> +const struct dpll_params *get_dpll_core_params(void)
> +{
> +   return &dpll_core;
> +}
> +
> +const struct dpll_params *get_dpll_per_params(void)
> +{
> +   return &dpll_per;
> +}
> +
>  void setup_clocks_for_console(void)
>  {
> clrsetbits_le32(&cmwkup->wkclkstctrl, CD_CLKCTRL_CLKTRCTRL_MASK,
> diff --git a/arch/arm/cpu/armv7/am33xx/clock_am43xx.c 
> b/arch/arm/cpu/armv7/am33xx/clock_am43xx.c
> index 22963b7..97c00b4 100644
> --- a/arch/arm/cpu/armv7/am33xx/clock_am43xx.c
> +++ b/arch/arm/cpu/armv7/am33xx/clock_am43xx.c
> @@ -48,15 +48,9 @@ const struct dpll_regs dpll_ddr_regs = {
> .cm_idlest_dpll = CM_WKUP + 0x5A4,
> .cm_clksel_dpll = CM_WKUP + 0x5AC,
> .cm_div_m2_dpll = CM_WKUP + 0x5B0,
> +   .cm_div_m4_dpll = CM_WKUP + 0x5B8,
>  };
>
> -const struct dpll_params dpll_mpu = {
> -   -1, -1, -1, -1, -1, -1, -1};
> -const struct dpll_params dpll_core = {
> -   -1, -1, -1, -1, -1, -1, -1};
> -const struct dpll_params dpll_per = {
> -   -1, -1, -1, -1, -1, -1, -1};
> -
>  void setup_clocks_for_console(void)
>  {
> /* Do not add any spl_debug prints in this function */
> diff --git a/arch/arm/include/asm/arch-am33xx/clock.h 
> b/arch/arm/include/asm/arch-am33xx/clock.h
> index 519249e..7637457 100644
> --- a/arch/arm/include/asm/arch-am33xx/clock.h
> +++ b/arch/arm/include/asm/arch-am33xx/clock.h
> @@ -98,13 +98,12 @@ extern const struct dpll_regs dpll_mpu_regs;
>  extern const struct dpll_regs dpll_core_regs;
>  extern const struct dpll_regs dpll_per_regs;
>  extern const struct dpll_regs dpll_ddr_regs;
> -extern const struct dpll_params dpll_mpu;
> -extern const struct dpll_params dpll_core;
> -extern const struct dpll_params dpll_per;
> -extern const struct dpll_params dpll_ddr;
>
>  extern struct cm_wkuppll *const cmwkup;
>
> +const struct dpll_params *get_dpll_mpu_params(void);
> +const struct dpll_params *get_dpll_core_params(void);
> +const struct dpll_params *get_dpll_per_params(void);
>  const struct dpll_params *get_dpll_ddr_params(void);
>  void do_setup_dpll(const struct dpll_regs *, const struct dpll_params *);
>  void prcm_init(void);
> diff --git a/board/ti/am43xx/board.c b/board/ti/am43xx/board.c
> index 723d0ca..2d1b8f9 100644
> --- a/board/ti/am43xx/board.c
> +++ b/board/ti/am43xx/board.c
> @@ -65,12 +65,44 @@ static int read_eeprom(struct am43xx_board_id *header)
>
>  #ifdef CONFIG_SPL_BUILD
>
> -const struct dpll_params dpll_ddr = {
> -   -1, -1, -1, -1, -1, -1, -1};
> +const struct dpll_params epos_evm_dpll_ddr = {
> + 

Re: [U-Boot] [PATCH V2 09/14] ARM: AM43xx: mux: Update mux data

[Vaibhav Bedia]

On Thu, Nov 21, 2013 at 1:18 AM, Lokesh Vutla  wrote:
> Updating the mux data for UART, adding data for i2c0 and mmc.
> And also updating pad_signals structure.
>
> Signed-off-by: Lokesh Vutla 
> ---
>  arch/arm/include/asm/arch-am33xx/mux_am43xx.h |   45 
> +
>  board/ti/am43xx/mux.c |   22 ++--
>  2 files changed, 65 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/include/asm/arch-am33xx/mux_am43xx.h 
> b/arch/arm/include/asm/arch-am33xx/mux_am43xx.h
> index 0206912..98fc2b5 100644
> --- a/arch/arm/include/asm/arch-am33xx/mux_am43xx.h
> +++ b/arch/arm/include/asm/arch-am33xx/mux_am43xx.h
> @@ -137,6 +137,51 @@ struct pad_signals {
> int mcasp0_fsr;
> int mcasp0_axr1;
> int mcasp0_ahclkx;
> +   int xdma_event_intr0;
> +   int xdma_event_intr1;
> +   int nresetin_out;
> +   int porz;
> +   int nnmi;
> +   int osc0_in;
> +   int osc0_out;
> +   int rsvd1;
> +   int tms;
> +   int tdi;
> +   int tdo;
> +   int tck;
> +   int ntrst;
> +   int emu0;
> +   int emu1;
> +   int osc1_in;
> +   int osc1_out;
> +   int pmic_power_en;
> +   int rtc_porz;
> +   int rsvd2;
> +   int ext_wakeup;
> +   int enz_kaldo_1p8v;
> +   int usb0_dm;
> +   int usb0_dp;
> +   int usb0_ce;
> +   int usb0_id;
> +   int usb0_vbus;
> +   int usb0_drvvbus;
> +   int usb1_dm;
> +   int usb1_dp;
> +   int usb1_ce;
> +   int usb1_id;
> +   int usb1_vbus;
> +   int usb1_drvvbus;
> +   int ddr_resetn;
> +   int ddr_csn0;
> +   int ddr_cke;
> +   int ddr_ck;
> +   int ddr_nck;
> +   int ddr_casn;
> +   int ddr_rasn;
> +   int ddr_wen;
> +   int ddr_ba0;
> +   int ddr_ba1;
> +   int ddr_ba2;
>  };

IIRC not all the pads over here have any IO control. Some are analog pins
and some like JTAG, PORz really shouldn't be meddled with if the h/w does
expose some configuration. Please revisit this change.

>
>  #endif /* _MUX_AM43XX_H_ */
> diff --git a/board/ti/am43xx/mux.c b/board/ti/am43xx/mux.c
> index 700e9a7..46bad01 100644
> --- a/board/ti/am43xx/mux.c
> +++ b/board/ti/am43xx/mux.c
> @@ -12,8 +12,24 @@
>  #include "board.h"
>
>  static struct module_pin_mux uart0_pin_mux[] = {
> -   {OFFSET(uart0_rxd), (MODE(0) | RXACTIVE)},  /* UART0_RXD */
> -   {OFFSET(uart0_txd), (MODE(0))}, /* UART0_TXD */
> +   {OFFSET(uart0_rxd), (MODE(0) | PULLUP_EN | RXACTIVE | SLEWCTRL)},
> +   {OFFSET(uart0_txd), (MODE(0) | PULLUDDIS | PULLUP_EN | SLEWCTRL)},
> +   {-1},

SLEWCTRL is typically not changed. You might want to double check this portion
with the h/w folks.

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

Re: [U-Boot] [PATCH V2 07/14] ARM: AM43xx: Select clk source for Timer2

[Vaibhav Bedia]

On Thu, Nov 21, 2013 at 1:18 AM, Lokesh Vutla  wrote:
> Selecting the Master osc clk as Timer2 clock source.
>
> Signed-off-by: Lokesh Vutla 
> ---
>  arch/arm/cpu/armv7/am33xx/clock_am43xx.c |4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/cpu/armv7/am33xx/clock_am43xx.c 
> b/arch/arm/cpu/armv7/am33xx/clock_am43xx.c
> index c4890f2..22963b7 100644
> --- a/arch/arm/cpu/armv7/am33xx/clock_am43xx.c
> +++ b/arch/arm/cpu/armv7/am33xx/clock_am43xx.c
> @@ -18,6 +18,7 @@
>
>  struct cm_perpll *const cmper = (struct cm_perpll *)CM_PER;
>  struct cm_wkuppll *const cmwkup = (struct cm_wkuppll *)CM_WKUP;
> +struct cm_dpll *const cmdpll = (struct cm_dpll *)CM_DPLL;
>
>  const struct dpll_regs dpll_mpu_regs = {
> .cm_clkmode_dpll= CM_WKUP + 0x560,
> @@ -107,4 +108,7 @@ void enable_basic_clocks(void)
> };
>
> do_enable_clocks(clk_domains, clk_modules_explicit_en, 1);
> +
> +   /* Select the Master osc clk as Timer2 clock source */
> +   writel(0x1, &cmdpll->clktimer2clk);

I really don't see a point of copying whatever AM335x does. You should
have a good reason for not using the other timers :P
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V2 05/14] ARM: AM43XX: board: add support for reading onboard EEPROM

[Vaibhav Bedia]

On Thu, Nov 21, 2013 at 1:18 AM, Lokesh Vutla  wrote:
[...]
>  #define NON_SECURE_SRAM_START  0x402F0400
>  #define NON_SECURE_SRAM_END0x4034
>  #define SRAM_SCRATCH_SPACE_ADDR0x4033C000
> +#define AM4372_BOARD_NAME_STARTSRAM_SCRATCH_SPACE_ADDR
> +#define AM4372_BOARD_NAME_END  SRAM_SCRATCH_SPACE_ADDR + 0xC

Why do you need to keep the struct address hardcoded like this?

[...]
> +static inline int board_is_eposevm(void)
> +{
> +   return !strncmp(am43xx_board_name, "AM43EPOS", HDR_NAME_LEN);
> +}
> +
> +static inline int board_is_gpevm(void)
> +{
> +   return !strncmp(am43xx_board_name, "AM43__GP", HDR_NAME_LEN);
> +}
> +

Looks like you got the EEPROM content updated ;)

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

Re: [U-Boot] [PATCH V2 01/14] ARM: AM43xx: Update the base addresses of modules

[Vaibhav Bedia]

Hi Lokesh,

On Thu, Nov 21, 2013 at 1:18 AM, Lokesh Vutla  wrote:
[...]
> +#define CM_DPLL0x44DF4200
> +#define CM_RTC 0x44df8500
>

nit: CM_RTC address should be in caps for the sake of consistency

>  #define PRM_RSTCTRL(PRCM_BASE + 0x4000)
>  #define PRM_RSTST  (PRM_RSTCTRL + 4)
> diff --git a/arch/arm/include/asm/arch-am33xx/hardware_ti814x.h 
> b/arch/arm/include/asm/arch-am33xx/hardware_ti814x.h
> index 4509a23..9080b6f 100644
> --- a/arch/arm/include/asm/arch-am33xx/hardware_ti814x.h
> +++ b/arch/arm/include/asm/arch-am33xx/hardware_ti814x.h
> @@ -27,6 +27,8 @@
>  #define PRCM_BASE  0x4818
>  #define CM_PER 0x44E0
>  #define CM_WKUP0x44E00400
> +#define CM_DPLL0x44E00500
> +#define CM_RTC 0x44E00800
>

Looking at these address i strongly suspect the CM_XXX ones are wrong
for the TI81xx
family. Does this really match with the TRM?

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

Re: [U-Boot] dra7xx: booting from eMMC raw boot partition

[Tom Rini]

On Wed, Nov 20, 2013 at 05:27:50PM -0500, Richard Retanubun wrote:

> Hi Shankar and Michael,
> 
> I am using the ti dra7xx_evm platform, which comes with a Micron
> MTFC4GVMEA-4M IT device that has two 16MB boot partitions.  I want to
> load the MLO and uboot into the eMMC's boot partition and boot from it
> in eMMC automotive peripheral mode.
> 
> I am able to write the MLO into the beginning of /dev/mmcblk1boot0 or
> /dev/mmcblk1boot1 or /dev/mmcblk1 (using dd) I then used mmc-utils to
> make sure that CONFIG_PARTITION in the eMMC's extcsd is set to allow
> booting from boot1 (with ACK).
> 
> However, the CPU does not print anything back on the console...
> 
> The only way I can get raw eMMC boot mode to work is if I put the MLO
> on /dev/mmcblk1 (which is the user data area).

Did you change the SYSBOOT pins to use automotive peripheral mode,
rather than user data?  If you did, you should see an error from MLO
saying that you came in from an unsupported boot device (since we don't
have the value of what ROM tells us for when we come in that way defined
in arch/arm/include/asm/arch-omap5/spl.h).  Or there is some other
problem.  Also note that U-Boot defaults to using these "boot"
partitions for storing the environment so you will need to change that
part of the config once you use these partitions for something else.

-- 
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] arm: tegra: Fix the CPU complex reset masks

[Stephen Warren]

On 11/20/2013 09:42 AM, Alban Bedel wrote:
> The CPU complex reset masks are not matching with the datasheet for
> the CLK_RST_CONTROLLER_RST_CPU_CMPLX_SET/CLR_0 registers. For both T20
> and T30 the register consist of groups of 4 bits, with one bit for
> each CPU core. On T20 the 2 high bits of each group are always stubbed
> as there is only 2 cores.

This looks correct to me. Given this problem, it's surprising that
reset_A9_cpu() was operating correctly, and that secondary CPUs were
coming out of reset OK later. What testing has this had (which SoCs and
boards)?

But still, it matches the TRM and kernel code, so,
Acked-by: Stephen Warren 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 0/8] SATA support for omap5_uevm and dra7_evm

[Enric Balletbo Serra]

Hi Roger,

2013/11/11 Roger Quadros :
> Hi,
>
> This series adds SATA support for OMAP5 uevm and DRA7 evm.
>
> Patches are also availabe at
>  g...@github.com:rogerq/u-boot.git   sata
>
> v3:
> - get rid of custom perror() macro, use printf
> - Fixed coding sytle issues
>
> v2:
> - Address review comments in the RFC series
> - Fix cache align error in the ahci driver
> - Added dra7 support
>
> cheers,
> -roger
>
> Roger Quadros (8):
>   ahci: Error out with message on malloc() failure
>   ahci: Fix cache align error messages
>   ARM: OMAP5: Add Pipe3 PHY driver
>   ARM: OMAP5: Add PRCM and Control information for SATA
>   ARM: OMAP5: Add SATA platform glue
>   ARM: omap5_uevm: Add SATA support
>   ARM: DRA7xx: Add PRCM and Control information for SATA
>   ARM: dra7_evm: Add SATA support
>
>  arch/arm/cpu/armv7/omap-common/Makefile|   5 +
>  arch/arm/cpu/armv7/omap-common/pipe3-phy.c | 231 
> +
>  arch/arm/cpu/armv7/omap-common/pipe3-phy.h |  36 +
>  arch/arm/cpu/armv7/omap-common/sata.c  |  75 ++
>  arch/arm/cpu/armv7/omap5/prcm-regs.c   |   7 +
>  arch/arm/include/asm/arch-omap5/clock.h|   3 +
>  arch/arm/include/asm/arch-omap5/omap.h |   3 +
>  arch/arm/include/asm/arch-omap5/sata.h |  48 ++
>  arch/arm/include/asm/omap_common.h |   2 +
>  board/ti/dra7xx/evm.c  |   7 +
>  board/ti/omap5_uevm/evm.c  |   7 +
>  drivers/block/ahci.c   |  18 ++-
>  include/configs/dra7xx_evm.h   |  11 ++
>  include/configs/omap5_uevm.h   |  10 ++
>  14 files changed, 457 insertions(+), 6 deletions(-)
>  create mode 100644 arch/arm/cpu/armv7/omap-common/pipe3-phy.c
>  create mode 100644 arch/arm/cpu/armv7/omap-common/pipe3-phy.h
>  create mode 100644 arch/arm/cpu/armv7/omap-common/sata.c
>  create mode 100644 arch/arm/include/asm/arch-omap5/sata.h
>
> --
> 1.8.3.2
>

I've tested the patches in my board and worked for me.

Note, but, although the patches apply cleanly in current master branch
the build is broken due this commit:

commit 4e1aa8437ae5baed2be79fff09aa70a293e61467
Author: Masahiro Yamada 
Date:   Thu Oct 17 17:34:48 2013 +0900

armv7: convert makefiles to Kbuild style


You should apply the following change in your patch number 3
(U-Boot-v3-3-8-ARM-OMAP5-Add-Pipe3-PHY-driver.patch)

diff --git a/arch/arm/cpu/armv7/omap-common/Makefile
b/arch/arm/cpu/armv7/omap-common/Makefile
index 679c1a1..59f5352 100644
--- a/arch/arm/cpu/armv7/omap-common/Makefile
+++ b/arch/arm/cpu/armv7/omap-common/Makefile
@@ -18,7 +18,7 @@ obj-y += abb.o
 endif

 ifneq ($(CONFIG_OMAP54XX),)
-COBJS  += pipe3-phy.o
+obj-y  += pipe3-phy.o
 obj-$(CONFIG_SCSI_AHCI_PLAT) += sata.o
 endif

And rebase the patch number 5
(U-Boot-v3-5-8-ARM-OMAP5-Add-SATA-platform-glue.patch) as after the
change doesn't apply.

Despite this:

Tested-by: Enric Balletbo i Serra 

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

Re: [U-Boot] [PATCH 0/9] ARMv7: add PSCI support to u-boot

[Rob Herring]

On Thu, Nov 21, 2013 at 2:59 AM, Marc Zyngier  wrote:
> PSCI is an ARM standard that provides a generic interface that
> supervisory software can use to manage power in the following
> situations:
> - Core idle management
> - CPU hotplug
> - big.LITTLE migration models
> - System shutdown and reset
>
> It basically allows the kernel to offload these tasks to the firmware,
> and rely on common kernel side code.
>
> More importantly, it gives a way to ensure that CPUs enter the kernel
> at the appropriate exception level (ie HYP mode, to allow the use of
> the virtualization extensions), even across events like CPUs being
> powered off/on or suspended.
>
> The main idea here is to reuse some of the existing u-boot code to
> create a separate blob that can live in SRAM (or a reserved page of
> memory), containing a secure monitor that will implement the PSCI
> operations. This code will still be alive when u-boot is long gone,
> hence the need for a piece of memory that will not be touched by the
> OS.

Interesting. As a separate binary, I'm not sure this belongs or
benefits from being in u-boot. I would like to see this as a more
generic secure firmware loader or PSCI code be a part of u-boot code
directly. With the latter, you could extend it beyond PSCI to things
like env variable access (basically equivalent to UEFI runtime
services). I'm not saying we should do that though.

BTW, you will need to mark this region reserved in the dtb if in system RAM.

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

Re: [U-Boot] [PATCH 1/4] mx51evk: Fix pmic_init() argument

[Stefano Babic]

On 20/11/2013 23:26, Fabio Estevam wrote:
> From: Fabio Estevam 
> 
> On mx51evk board the PMIC is connected via SPI interface, so it does not make
> sense to pass I2C_PMIC into the pmic_init() interface.
> 
> Pass the SPI bus number via CONFIG_FSL_PMIC_BUS option instead.
> 
> Signed-off-by: Fabio Estevam 
> ---
>  board/freescale/mx51evk/mx51evk.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/board/freescale/mx51evk/mx51evk.c 
> b/board/freescale/mx51evk/mx51evk.c
> index d01465e..9b43c84 100644
> --- a/board/freescale/mx51evk/mx51evk.c
> +++ b/board/freescale/mx51evk/mx51evk.c
> @@ -174,7 +174,7 @@ static void power_init(void)
>   struct pmic *p;
>   int ret;
>  
> - ret = pmic_init(I2C_PMIC);
> + ret = pmic_init(CONFIG_FSL_PMIC_BUS);
>   if (ret)
>   return;
>  
> 

Acked-by: Stefano Babic 

Best regards,
Stefano Babic

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

Re: [U-Boot] [PATCH v2] net: Add fixed phy driver

[Joe Hershberger]

Hi Christian / Andy,

On Mon, Sep 2, 2013 at 8:16 PM, Andy Fleming  wrote:
> On Mon, Sep 2, 2013 at 7:30 AM, Christian Gmeiner <
> christian.gmei...@gmail.com> wrote:
>
>> This patch is needed if the MAC is directly connected to a ethernet switch.
>> In my case the FEC MAC is connected to a Micrel KSZ8895. All I need to to
>> is configure my fixed phy/link like:
>>
>> #define IMX_FEC_BASEENET_BASE_ADDR
>> #define CONFIG_FEC_XCV_TYPE MII100
>> #define CONFIG_ETHPRIME "FEC"
>> #define CONFIG_FEC_MXC_PHYADDR  0x5
>> #define CONFIG_PHYLIB
>> #define CONFIG_PHY_FIXED
>> #define CONFIG_PHY_FIXED_SPEED  SPEED_100
>> #define CONFIG_PHY_FIXED_DUPLEX DUPLEX_FULL
>>
>> Signed-off-by: Christian Gmeiner 
>>
>
> This doesn't work very well if you ever have more than one switch, or need
> more than one fixed link for some other reason. It needs to be possible to
> instantiate the fixed PHY interface(s) at runtime, IMO.

Do you plan to implement this in a more flexible way?

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

Re: [U-Boot] dra7xx: booting from eMMC raw boot partition

[Tom Rini]

On Thu, Nov 21, 2013 at 01:20:08PM -0500, Richard Retanubun wrote:
> On 21/11/13 01:09 PM, Tom Rini wrote:
> >I've done RAW mode booting on my omap5_uevm as well as am335x-based
> >platforms, on SD card and eMMC.  But in the case of eMMC it's always the
> >user partitions.  I suspect the answer is that for automotive booting
> >you need silicon that supports that, much like the difference between HS
> >and GP devices.
> 
> Agreed. If by silicon you mean the CPU, then all the docs I've seen
> (the TRM for DRA7xx and SYSBOOT in automotive peripheral mode seem to
> indicate that the SoC is capable or Raw eMMC boot partition booting.

Well, I think it's a little more than that, perhaps depending on eFuse
stuff or similar as well.

> >I'm not sure what code in p-ti-u-boot-2013.04 hasn't
> >been merged to mainline but if you can give me some pointers I can go
> >and poke some folks.
> Thanks for the offer, poke gently :)
> 
> I think it is essentially all the code that touches /drivers/mmc/spl_mmc.c on 
> the ti tree here:
> 
> http://git.omapzoom.org/?p=repo/u-boot.git;a=history;f=drivers/mmc/spl_mmc.c;h=bd7e34bed35a1518d714232a8aedbc2e38d43632;hb=refs/heads/p-ti-u-boot-2013.04

Ah, OK, I see where the confusion comes from.  There are three things in
that tree, roughly, from reading the commits on that file:
1) Android Fastboot support
2) A custom version of "falcon mode"
3) Other odds and ends changes

Looking over the code there, one might think mainline doesn't support
eMMC booting or needs changes, because we always say "use mmc device 0".
That's fine however because SPL looks at if we came in (hardware
numbering now) from MMC1 or MMC2 and then only register that MMC device.
So we're always s/w wise mmc device 0.

There's a few patches floating around to add Fastboot support to
mainline, and I'd love to see one pushed all the way to mainline.

-- 
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] (no subject)

[Stefano Babic]

On 21/11/2013 15:01, Bojan Buić wrote:
> Which register I need set up for hard. watchdog ?
> 

Please read carefully Chapter 23 amn 23.8.6 in the User Manuaal, you
will find answer to all your question.

Best regards,
Stefano Babic

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

Re: [U-Boot] (no subject)

[Bojan Buić]

I found address of register HW_RTC_WATCHDOG_SET: 0x8005C054

I need write to that register value 0x054 ?

Bojan


2013/11/21 Bojan Buić 

> Sorry for many questions, but I work once with 8 bit ATmega 8
> microcontroler and nothing more :(
>
> In manual I found this :
>
> HW_RTC_WATCHDOG 0x050
> HW_RTC_WATCHDOG_SET 0x054
> HW_RTC_WATCHDOG_CLR 0x058
> HW_RTC_WATCHDOG_TOG 0x05C
>
>
> and now I do not know which register i need setup to enable watchdog ?
> 0x054? Which value i need write to that register ?
>
> Bojan
>
>
>
> 2013/11/21 Stefano Babic 
>
>> On 21/11/2013 15:01, Bojan Buić wrote:
>> > Which register I need set up for hard. watchdog ?
>> >
>>
>> Please read carefully Chapter 23 amn 23.8.6 in the User Manuaal, you
>> will find answer to all your question.
>>
>> Best regards,
>> Stefano Babic
>>
>> --
>> =
>> DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
>> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
>> Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
>> =
>>
>
>
>
> --
> Bojan Buić
>
>
>


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

Re: [U-Boot] [PATCH] imx: Explicitly pass the I2C bus number in pmic_init()

[Stefano Babic]

On 21/11/2013 00:17, Fabio Estevam wrote:
> From: Fabio Estevam 
> 
> The pmic_init() function has the I2C or SPI bus number that is connected to 
> the
> PMIC.
> 
> Instead of passing I2C_PMIC, explicitly pass the I2C bus number via I2C_x 
> definition.
> 
> The motivation for doing this is to avoid people just doing a copy and paste 
> of I2C_PMIC into their board file when another I2C bus is actually used to 
> interface to their PMIC.
> 
> This also makes more obvious which is the I2C bus connected to the PMIC, 
> without 
> having to search in the source code for the meaning of the 'I2C_PMIC' number.
> 
> Signed-off-by: Fabio Estevam 
> ---
>  board/freescale/mx25pdk/mx25pdk.c   | 2 +-
>  board/freescale/mx35pdk/mx35pdk.c   | 2 +-
>  board/freescale/mx53evk/mx53evk.c   | 2 +-
>  board/freescale/mx53loco/mx53loco.c | 2 +-
>  4 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/board/freescale/mx25pdk/mx25pdk.c 
> b/board/freescale/mx25pdk/mx25pdk.c
> index ebe3bcb..71a395c 100644
> --- a/board/freescale/mx25pdk/mx25pdk.c
> +++ b/board/freescale/mx25pdk/mx25pdk.c
> @@ -138,7 +138,7 @@ int board_late_init(void)
>  
>   mx25pdk_fec_init();
>  
> - ret = pmic_init(I2C_PMIC);
> + ret = pmic_init(I2C_0);
>   if (ret)
>   return ret;
>  
> diff --git a/board/freescale/mx35pdk/mx35pdk.c 
> b/board/freescale/mx35pdk/mx35pdk.c
> index 9fabef5..12467a9 100644
> --- a/board/freescale/mx35pdk/mx35pdk.c
> +++ b/board/freescale/mx35pdk/mx35pdk.c
> @@ -213,7 +213,7 @@ int board_late_init(void)
>   struct pmic *p;
>   int ret;
>  
> - ret = pmic_init(I2C_PMIC);
> + ret = pmic_init(I2C_0);
>   if (ret)
>   return ret;
>  
> diff --git a/board/freescale/mx53evk/mx53evk.c 
> b/board/freescale/mx53evk/mx53evk.c
> index 3b398b6..13519e2 100644
> --- a/board/freescale/mx53evk/mx53evk.c
> +++ b/board/freescale/mx53evk/mx53evk.c
> @@ -81,7 +81,7 @@ void power_init(void)
>   struct pmic *p;
>   int ret;
>  
> - ret = pmic_init(I2C_PMIC);
> + ret = pmic_init(I2C_0);
>   if (ret)
>   return;
>  
> diff --git a/board/freescale/mx53loco/mx53loco.c 
> b/board/freescale/mx53loco/mx53loco.c
> index ae7eca8..db0bf17 100644
> --- a/board/freescale/mx53loco/mx53loco.c
> +++ b/board/freescale/mx53loco/mx53loco.c
> @@ -258,7 +258,7 @@ static int power_init(void)
>   }
>  
>   if (!i2c_probe(CONFIG_SYS_FSL_PMIC_I2C_ADDR)) {
> - ret = pmic_init(I2C_PMIC);
> + ret = pmic_init(I2C_0);
>   if (ret)
>   return ret;
>  
> 

Acked-by: Stefano Babic 

Best regards,
Stefano Babic

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

Re: [U-Boot] [PATCH] configs: imx: Remove CONFIG_SYS_SPD_BUS_NUM option

[Stefano Babic]

On 20/11/2013 23:38, Fabio Estevam wrote:
> From: Fabio Estevam 
> 
> According to the README:
> 
> "- CONFIG_SYS_SPD_BUS_NUM
>   If SPD EEPROM is on an I2C bus other than the first
>   one, specify here. Note that the value must resolve
>   to something your driver can deal with."
> 
> There is no SPD EEPROM on the imx boards, so ged rid of this option.
> 
> Signed-off-by: Fabio Estevam 
> ---
>  include/configs/imx31_phycore.h | 1 -
>  include/configs/mx25pdk.h   | 1 -
>  include/configs/mx35pdk.h   | 1 -
>  include/configs/mx53ard.h   | 1 -
>  include/configs/mx53evk.h   | 1 -
>  include/configs/mx53loco.h  | 1 -
>  include/configs/mx53smd.h   | 1 -
>  7 files changed, 7 deletions(-)
> 
> diff --git a/include/configs/imx31_phycore.h b/include/configs/imx31_phycore.h
> index 7b55695..ffb67c2 100644
> --- a/include/configs/imx31_phycore.h
> +++ b/include/configs/imx31_phycore.h
> @@ -37,7 +37,6 @@
>  
>  #define CONFIG_SYS_I2C
>  #define CONFIG_SYS_I2C_MXC
> -#define CONFIG_SYS_SPD_BUS_NUM   1 /* I2C2 */
>  #define CONFIG_SYS_I2C_CLK_OFFSETI2C2_CLK_OFFSET
>  
>  #define CONFIG_MXC_UART
> diff --git a/include/configs/mx25pdk.h b/include/configs/mx25pdk.h
> index fb564b0..af6aafa 100644
> --- a/include/configs/mx25pdk.h
> +++ b/include/configs/mx25pdk.h
> @@ -115,7 +115,6 @@
>  #define CONFIG_CMD_I2C
>  #define CONFIG_SYS_I2C
>  #define CONFIG_SYS_I2C_MXC
> -#define CONFIG_SYS_SPD_BUS_NUM   0 /* I2C1 */
>  
>  /* RTC */
>  #define CONFIG_RTC_IMXDI
> diff --git a/include/configs/mx35pdk.h b/include/configs/mx35pdk.h
> index 4b4503c..0a46f4c 100644
> --- a/include/configs/mx35pdk.h
> +++ b/include/configs/mx35pdk.h
> @@ -42,7 +42,6 @@
>   */
>  #define CONFIG_SYS_I2C
>  #define CONFIG_SYS_I2C_MXC
> -#define CONFIG_SYS_SPD_BUS_NUM   0 /* I2C1 */
>  #define CONFIG_MXC_SPI
>  #define CONFIG_MXC_GPIO
>  
> diff --git a/include/configs/mx53ard.h b/include/configs/mx53ard.h
> index 60c40c8..797a637 100644
> --- a/include/configs/mx53ard.h
> +++ b/include/configs/mx53ard.h
> @@ -46,7 +46,6 @@
>  #define CONFIG_CMD_I2C
>  #define CONFIG_SYS_I2C
>  #define CONFIG_SYS_I2C_MXC
> -#define CONFIG_SYS_SPD_BUS_NUM   1 /* I2C2 */
>  
>  /* MMC Configs */
>  #define CONFIG_FSL_ESDHC
> diff --git a/include/configs/mx53evk.h b/include/configs/mx53evk.h
> index d0b5258..3f0d80a 100644
> --- a/include/configs/mx53evk.h
> +++ b/include/configs/mx53evk.h
> @@ -39,7 +39,6 @@
>  #define CONFIG_CMD_I2C
>  #define CONFIG_SYS_I2C
>  #define CONFIG_SYS_I2C_MXC
> -#define CONFIG_SYS_SPD_BUS_NUM   1 /* I2C2 */
>  
>  /* PMIC Configs */
>  #define CONFIG_POWER
> diff --git a/include/configs/mx53loco.h b/include/configs/mx53loco.h
> index 7b735ab..ae43ea3 100644
> --- a/include/configs/mx53loco.h
> +++ b/include/configs/mx53loco.h
> @@ -73,7 +73,6 @@
>  /* I2C Configs */
>  #define CONFIG_SYS_I2C
>  #define CONFIG_SYS_I2C_MXC
> -#define CONFIG_SYS_SPD_BUS_NUM   0 /* I2C1 */
>  
>  /* PMIC Controller */
>  #define CONFIG_POWER
> diff --git a/include/configs/mx53smd.h b/include/configs/mx53smd.h
> index c9618b4..a04e7c7 100644
> --- a/include/configs/mx53smd.h
> +++ b/include/configs/mx53smd.h
> @@ -36,7 +36,6 @@
>  #define CONFIG_CMD_I2C
>  #define CONFIG_SYS_I2C
>  #define CONFIG_SYS_I2C_MXC
> -#define CONFIG_SYS_SPD_BUS_NUM   1 /* I2C2 */
>  
>  /* MMC Configs */
>  #define CONFIG_FSL_ESDHC
> 

Acked-by: Stefano Babic 

Best regards,
Stefano Babic

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

Re: [U-Boot] (no subject)

[Bojan Buić]

Sorry for many questions, but I work once with 8 bit ATmega 8
microcontroler and nothing more :(

In manual I found this :

HW_RTC_WATCHDOG 0x050
HW_RTC_WATCHDOG_SET 0x054
HW_RTC_WATCHDOG_CLR 0x058
HW_RTC_WATCHDOG_TOG 0x05C


and now I do not know which register i need setup to enable watchdog ?
0x054? Which value i need write to that register ?

Bojan



2013/11/21 Stefano Babic 

> On 21/11/2013 15:01, Bojan Buić wrote:
> > Which register I need set up for hard. watchdog ?
> >
>
> Please read carefully Chapter 23 amn 23.8.6 in the User Manuaal, you
> will find answer to all your question.
>
> Best regards,
> Stefano Babic
>
> --
> =
> DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
> =
>



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

[U-Boot] [PATCH V4 1/2] driver:usb:s3c_udc: add support for Exynos4x12

[Piotr Wilczek]

This patch add new defines for usb phy for Exynos4x12.

Signed-off-by: Piotr Wilczek 
Signed-off-by: Kyungmin Park 
CC: Minkyu Kang 
---
Chnages for v4:
 - no changes

Chnages for v3:
 - removed unnecessary empty line

Changes for v2:
 - no changes
 
 drivers/usb/gadget/regs-otg.h|5 +
 drivers/usb/gadget/s3c_udc_otg.c |9 +++--
 2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/regs-otg.h b/drivers/usb/gadget/regs-otg.h
index 84bfcc5..ac5d112 100644
--- a/drivers/usb/gadget/regs-otg.h
+++ b/drivers/usb/gadget/regs-otg.h
@@ -226,6 +226,11 @@ struct s3c_usbotg_reg {
 #define CLK_SEL_12MHZ   (0x2 << 0)
 #define CLK_SEL_48MHZ   (0x0 << 0)
 
+#define EXYNOS4X12_ID_PULLUP0  (0x01 << 3)
+#define EXYNOS4X12_COMMON_ON_N0(0x01 << 4)
+#define EXYNOS4X12_CLK_SEL_12MHZ   (0x02 << 0)
+#define EXYNOS4X12_CLK_SEL_24MHZ   (0x05 << 0)
+
 /* Device Configuration Register DCFG */
 #define DEV_SPEED_HIGH_SPEED_20 (0x0 << 0)
 #define DEV_SPEED_FULL_SPEED_20 (0x1 << 0)
diff --git a/drivers/usb/gadget/s3c_udc_otg.c b/drivers/usb/gadget/s3c_udc_otg.c
index 7e20209..ba17a04 100644
--- a/drivers/usb/gadget/s3c_udc_otg.c
+++ b/drivers/usb/gadget/s3c_udc_otg.c
@@ -167,8 +167,13 @@ void otg_phy_init(struct s3c_udc *dev)
writel((readl(&phy->phypwr) &~(OTG_DISABLE_0 | ANALOG_PWRDOWN)
&~FORCE_SUSPEND_0), &phy->phypwr);
 
-   writel((readl(&phy->phyclk) &~(ID_PULLUP0 | COMMON_ON_N0)) |
-  CLK_SEL_24MHZ, &phy->phyclk); /* PLL 24Mhz */
+   if (s5p_cpu_id == 0x4412)
+   writel((readl(&phy->phyclk) & ~(EXYNOS4X12_ID_PULLUP0 |
+   EXYNOS4X12_COMMON_ON_N0)) | EXYNOS4X12_CLK_SEL_24MHZ,
+  &phy->phyclk); /* PLL 24Mhz */
+   else
+   writel((readl(&phy->phyclk) & ~(ID_PULLUP0 | COMMON_ON_N0)) |
+  CLK_SEL_24MHZ, &phy->phyclk); /* PLL 24Mhz */
 
writel((readl(&phy->rstcon) &~(LINK_SW_RST | PHYLNK_SW_RST))
   | PHY_SW_RST0, &phy->rstcon);
-- 
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] mii: dump: parameter choice

[Joe Hershberger]

Hi Stephan,

On Mon, Aug 12, 2013 at 6:05 AM, Stephan Bauroth  wrote:
> Hi all,
>
> since no one commented on my prior mail, i just took the liberty to write

I apologize about that.  I've been preoccupied with other work of late.

> a little patch that chooses regs 0-5 if none are specified for 'mii dump'.
> Also fixes some alignment issues, typos and introduces the 'Selector
> Field' to the register description of PHY regs 4 and 5. On top, 'mii dump'
> now prints the PHY address in front of a register dump.
>
> this is my first patch, if anything is wrong, plese tell me :)

The idea of your patch is good, but you need to follow the patch
submission rules.  Have a look at
http://www.denx.de/wiki/U-Boot/Patches and
http://www.denx.de/wiki/U-Boot/CodingStyle for the process and
expectations.

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

[U-Boot] [PATCH V4 2/2] trats2: enable ums support on Trats2

[Piotr Wilczek]

This patch adds support for USB and enables 'ums' command on Trats2 board.

Signed-off-by: Piotr Wilczek 
Signed-off-by: Kyungmin Park 
CC: Minkyu Kang 

Acked-by: Jaehoon Chung 
---
Changes for v4:
 - removed empty line
 - added check if muic is available
 - removed cable_connected

Changes for v3:
 - no changes

Changes for v2:
 - rebased on current USB tree
 - removed unnecessary pmic probing

 board/samsung/trats2/trats2.c |   92 +
 include/configs/trats2.h  |   18 
 2 files changed, 110 insertions(+)

diff --git a/board/samsung/trats2/trats2.c b/board/samsung/trats2/trats2.c
index d44d825..b932a60 100644
--- a/board/samsung/trats2/trats2.c
+++ b/board/samsung/trats2/trats2.c
@@ -25,6 +25,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -308,6 +311,95 @@ int board_mmc_init(bd_t *bis)
return err0 & err2;
 }
 
+#ifdef CONFIG_USB_GADGET
+static int s5pc210_phy_control(int on)
+{
+   int ret = 0;
+   unsigned int val;
+   struct pmic *p, *p_pmic, *p_muic;
+
+   p_pmic = pmic_get("MAX77686_PMIC");
+   if (!p_pmic)
+   return -ENODEV;
+
+   if (pmic_probe(p_pmic))
+   return -1;
+
+   p_muic = pmic_get("MAX77693_MUIC");
+   if (!p_muic)
+   return -ENODEV;
+
+   if (pmic_probe(p_muic))
+   return -1;
+
+   if (on) {
+   ret = max77686_set_ldo_mode(p_pmic, 12, OPMODE_ON);
+   if (ret)
+   return -1;
+
+   p = pmic_get("MAX77693_PMIC");
+   if (!p)
+   return -ENODEV;
+
+   if (pmic_probe(p))
+   return -1;
+
+   /* SAFEOUT */
+   ret = pmic_reg_read(p, MAX77693_SAFEOUT, &val);
+   if (ret)
+   return -1;
+
+   val |= MAX77693_ENSAFEOUT1;
+   ret = pmic_reg_write(p, MAX77693_SAFEOUT, val);
+   if (ret)
+   return -1;
+
+   /* PATH: USB */
+   ret = pmic_reg_write(p_muic, MAX77693_MUIC_CONTROL1,
+   MAX77693_MUIC_CTRL1_DN1DP2);
+
+   } else {
+   ret = max77686_set_ldo_mode(p_pmic, 12, OPMODE_LPM);
+   if (ret)
+   return -1;
+
+   /* PATH: UART */
+   ret = pmic_reg_write(p_muic, MAX77693_MUIC_CONTROL1,
+   MAX77693_MUIC_CTRL1_UT1UR2);
+   }
+
+   if (ret)
+   return -1;
+
+   return 0;
+}
+
+struct s3c_plat_otg_data s5pc210_otg_data = {
+   .phy_control= s5pc210_phy_control,
+   .regs_phy   = EXYNOS4X12_USBPHY_BASE,
+   .regs_otg   = EXYNOS4X12_USBOTG_BASE,
+   .usb_phy_ctrl   = EXYNOS4X12_USBPHY_CONTROL,
+   .usb_flags  = PHY0_SLEEP,
+};
+
+int board_usb_init(int index, enum usb_init_type init)
+{
+   debug("USB_udc_probe\n");
+   return s3c_udc_probe(&s5pc210_otg_data);
+}
+
+#ifdef CONFIG_USB_CABLE_CHECK
+int usb_cable_connected(void)
+{
+   struct pmic *muic = pmic_get("MAX77693_MUIC");
+   if (!muic)
+   return 0;
+
+   return !!muic->chrg->chrg_type(muic);
+}
+#endif
+#endif
+
 static int pmic_init_max77686(void)
 {
struct pmic *p = pmic_get("MAX77686_PMIC");
diff --git a/include/configs/trats2.h b/include/configs/trats2.h
index 0e93836..66b1c95 100644
--- a/include/configs/trats2.h
+++ b/include/configs/trats2.h
@@ -113,6 +113,16 @@
 #define CONFIG_CMD_EXT4
 #define CONFIG_CMD_EXT4_WRITE
 
+/* USB Composite download gadget - g_dnl */
+#define CONFIG_USBDOWNLOAD_GADGET
+#define CONFIG_DFU_FUNCTION
+#define CONFIG_DFU_MMC
+
+/* USB Samsung's IDs */
+#define CONFIG_G_DNL_VENDOR_NUM 0x04E8
+#define CONFIG_G_DNL_PRODUCT_NUM 0x6601
+#define CONFIG_G_DNL_MANUFACTURER "Samsung"
+
 /* To use the TFTPBOOT over USB, Please enable the CONFIG_CMD_NET */
 #undef CONFIG_CMD_NET
 
@@ -293,6 +303,11 @@
 #define CONFIG_POWER_MUIC_MAX77693
 #define CONFIG_POWER_FG_MAX77693
 #define CONFIG_POWER_BATTERY_TRATS2
+#define CONFIG_USB_GADGET
+#define CONFIG_USB_GADGET_S3C_UDC_OTG
+#define CONFIG_USB_GADGET_DUALSPEED
+#define CONFIG_USB_GADGET_VBUS_DRAW2
+#define CONFIG_USB_CABLE_CHECK
 
 /* LCD */
 #define CONFIG_EXYNOS_FB
@@ -305,6 +320,9 @@
 #define CONFIG_VIDEO_BMP_GZIP
 #define CONFIG_SYS_VIDEO_LOGO_MAX_SIZE ((500 * 250 * 4) + (1 << 12))
 
+#define CONFIG_CMD_USB_MASS_STORAGE
+#define CONFIG_USB_GADGET_MASS_STORAGE
+
 /* Pass open firmware flat tree */
 #define CONFIG_OF_LIBFDT1
 
-- 
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] pcm051: Support for revision 3

[Tom Rini]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/21/2013 05:05 AM, Lars Poeschel wrote:
> Am Dienstag, 19. November 2013, 15:08:27 schrieb Tom Rini:
>> On Tue, Nov 19, 2013 at 11:22:18AM +0100, Lars Poeschel wrote:
>>> From: Lars Poeschel 
>>> 
>>> Phytec sells revision or version 3 of pcm051. It is labeled
>>> 1358.3 on the board. The difference for u-boot is that is has
>>> other DDR3 RAM on it: 1 x MT41K256M16HA125E instead of 2 x
>>> MT41J256M8HX15E on revisions 1 and 2. Both configurations are
>>> 512 MiB. Configure your u-boot build with pcm051_rev3 for the
>>> new RAM and pcm051_rev1 for the old RAM configuration. Board
>>> revision 2 has to use pcm051_rev1 also.
>>> 
>>> Signed-off-by: Lars Poeschel 
>> 
>> Is there no run-time way to tell if we're on rev1/2/3?
> 
> Unfortunately I am not aware of a 100% bullet proof one. One way
> would be to read the AM3359 silicon ID. I have two boards here:
> rev1 and rev3. The phytec rev3 board has a newer silicon on it. I
> don't know about rev2's silicon ID. And I am not sure if the rev3
> silicon change directly corresponds to the DDR RAM change and if
> all rev3 boards have the new silicon. What I know for sure is that
> the RAM change was with rev3. Nevertheless phytec itself supplies a
> patched barebox as bootloader. And they have a compile time config
> option for different RAM configurations of the board. And they even
> seem to have more RAM configurations than the two I have seen yet.

OK, thanks.

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

iQIcBAEBAgAGBQJSjggcAAoJENk4IS6UOR1WOFcQAJmvkp5P2nkvSRhYAgqupGBL
EczfkW/hERfExMHjzas+UUGUcr7WJgX4lnFMZOou0hdTBilkjl4gI1xVQfuoUMQA
fw0Gya8R6dI8I9x7rtoFRM69+mbA2HXNei040aqlX7mmqK5BSUA85IFlTUf7//A8
zXsiUDNzze6V0+TvzM/IFdA9ma1aQnNDoiuMEjcwFKC5/d4wgC0Lntx6SfwlFiKD
BuddoIglkMHDJ1ZjAhGgrZU0Jt4LuctD+mHRdN4GRo9evO8sXpbDU95ZsEefbza0
eT0mvXXy/gUEg7LUnRmmAKgOstLmX4ttC+9PxMWpmdO4LX8b4zEGPfI3Ev39KTj1
GwiKlmNudhBHIcCgfoj9dYTgXdpgGgw5KVU1sms1Nn/uTEvAG9wVIeiibzzHLmh3
XgibqSjMD3FosqG+tnliELJKnh/yAqpYVAV7ldVpKXP2VeKAdSRHwffTgbkYUYhS
KI2G+JXvQjOYS176uTTRkwDwPOSwx8A7cs/fkbTkPyWkzlyzn6ZDemmcLnv48f6F
XD+HBtcFpfplAxg4kJ9bws97tKgtYYJK0eoC6C82eM/k8XFkb/lJ7FaLusU4KGtM
4njiBYktv8I3J/kh2fOe2r9ACJpyBJFm+ffFJlN+x1GInMHiJ9tYpDliA0+Pw5Jm
vjbvV/rGHT9Lo1o73FUY
=hMkr
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] dra7xx: booting from eMMC raw boot partition

[Richard Retanubun]

Hi Guys, thanks for the responses. my comments are below.

On 20/11/13 05:39 PM, Shankar Rao wrote:> On 11/20/2013 04:27 PM, Richard 
Retanubun wrote:
> Hi Richard,
> Are you trying to boot Android kernel or Linux kernel? Building u-boot
> with android config will give you access to fastboot which can help you
> partition the eMMC and boot out of it.

I am trying to boot Linux kernel. The plan is to put MLO and uboot in the 
eMMC's boot partition
and a GPT partitioned linux in the user data area.

I think there are some errata in the ROM bootcode about booting over QSPI1, I 
am concerned
that I am hitting another errata condition. Can you help me confirm this?

On 21/11/13 12:39 AM, Michael Pratt wrote:

Hi Richard,

On Wed, Nov 20, 2013 at 5:27 PM, Richard Retanubun
 wrote:

However, the CPU does not print anything back on the console...

The only way I can get raw eMMC boot mode to work is if I put the MLO on
/dev/mmcblk1 (which is the user data area).


I have not seen a reference manual for dra7xx, so this may not apply,
but it is worth noting that many SoCs that support booting from eMMC
do not actually use the boot mode, and simply boot directly from the
user data area.  The boot mode is described in the eMMC spec in a
section titled "Boot operation mode" (Section 7.3 in eMMC 4.4).
Basically, it provides a different initialization sequence that will
sequentially read out the partition selected in CONFIG_PARTITION.  If
the SoC is not utilizing this boot mode, it may unconditionally read
from the user data area.

Yep. These are the sequence I am trying to do (the "Alternate boot operation")




Does the MLO for raw boot mode needs to be different that the MLO for raw
user data area?


If both MLO and U-Boot are to be in the boot partition, booted using
eMMC boot mode, MLO will likely need to behave differently in order to
correctly read U-Boot.  Boot mode sequentially reads out the selected
partition, without using the standard commands, so MLO will need to
understand this and perform the appropriate clocking of the eMMC.  I
am unsure if there is currently support for that.

I am aware that the MLO will have to behave differently.
But I expect that at least the beginning (version printing) is common.
I am trying to use that as a quick-and-dirty test to confirm the SoC's
ability to boot over eMMC boot partition.

I am aware that there is no support in denx mainline.
In the ti omapzoom repo/u-boot there are code that looks hopeful.
(ref: /drivers/mmc/spl_mmc.c::spl_mmc_load_image_raw())

Once I can get the SoC to boot the MLO, I plan to use that
for the MLO to find and load uboot.



Hopefully this is helpful!
Michael Pratt


Thanks for both your time.

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

Re: [U-Boot] [PATCH 0/4] Wandboard support for Future Eletronics 7" WVGA LCD extension board

[Otavio Salvador]

On Thu, Nov 21, 2013 at 7:23 AM, Stefano Babic  wrote:
> Hi Otavio,
>
> On 22/10/2013 01:34, Otavio Salvador wrote:
>> This patchset adds support for the Future Eletronics 7" WVGA LCD
>> extension board and implements its auto-detection using i2c to check
>> for it's touch controller presence.
>>
>> The IOMUXC change is included here as it makes both SoC type MUX
>> settings in line to each other and took a while to figure out why it
>> worked with one and failed with another SoC.
>>
>>
>> Otavio Salvador (4):
>>   mx6: Remove PAD_CTL_DSE_120ohm from i.MX6DL's IPU1_DI0_PIN4 pin
>>   wandboard: add Future Eletronics 7" WVGA LCD extension board
>>   wandboard: Use '0' as bootdelay but interruptable
>>   wandboard: Pass 'quiet' bootparam by default
>>
>>  arch/arm/include/asm/arch-mx6/mx6dl_pins.h |   2 +-
>>  board/wandboard/wandboard.c| 238 
>> ++---
>>  include/configs/wandboard.h|  38 -
>>  3 files changed, 254 insertions(+), 24 deletions(-)
>
> I confess that I hoped that Simon's patches to extract the env from the
> board configuration file could be merged very soon into mainline, but
> they are not yet merged, and I am blocking some patches, mostly
> Otavio's. Again, there is also patches adding new feature as this one
> for the Future Electronics display, that contains also many additions to
> CONFIG_EXTRA_ENV_SETTINGS.
>
> I will apply the patch for Future's display - it is much more as only a
> change to default environment - but I am still confident that we can do
> in the right way once and I will let the other patches in my queue.
>
> Otavio, this regards your patches:
> http://patchwork.ozlabs.org/patch/285295/
> http://patchwork.ozlabs.org/patch/285296/
> http://patchwork.ozlabs.org/patch/285294/

I think all those should go; As I already said I will rework the
environments when Simon's changes are included but holding the
development due it is wrong in my point of view.

In fact I stopped sending patches as they are not applied for a
while... and this is unfortunate.

Anyway, not my call...

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Help needed: Boot signed RTOS

[Simon Glass]

Hi Christopher,

On Thu, Nov 21, 2013 at 4:04 AM, Christopher Preschern <
christopher.presch...@tugraz.at> wrote:

> Hi Simon,
>
> thanks for the quick answer.
>
>
> => bootm 0x4200
>>>## Loading kernel from FIT Image at 4200 ...
>>>   Using 'conf@1' configuration
>>>   Verifying Hash Integrity ... OK
>>>   Trying 'kernel@1' kernel subimage
>>> Description:  safeRTOS Kernel
>>> Type: Kernel Image (no loading done)
>>>
>>
>> This means Linux kernel. You probably need a new type
>>
>
> ok thanks - I guess that's a bit too big for me - I don't really have the
> expertise to make these changes.
>
> I had hoped that I just have the wrong configuration in the .its file and
> that it is already possible to boot my FIT-packed ELF file.
>

Well I suppose you can use the split version of the bootm command to do
this. Something like: 'bootm start ; bootm loados; bootm prep;
loadelf ...'


>
> thanks anyway.
>
>
> Best regards,
> Christopher
>
>
> --
>   --
> | Christopher Preschern
> | Institute for Technical Informatics - TU Graz
> | Tel: +43 (316) 873 - 6404
> | EMail: christopher.presch...@tugraz.at
>

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

Re: [U-Boot] standalone u-boot app - bootm issue was the part of: (Re: arm: U-Boot API - clang support broke ABI)

[Michal Simek]

On 11/20/2013 03:01 PM, Tom Rini wrote:
> On Wed, Nov 20, 2013 at 02:53:31PM +0100, Michal Simek wrote:
>> On 11/20/2013 02:49 PM, Tom Rini wrote:
>>> On Wed, Nov 20, 2013 at 08:59:43AM +0100, Michal Simek wrote:
 On 11/19/2013 09:07 PM, Tom Rini wrote:
> On Tue, Nov 19, 2013 at 10:09:44AM +0100, Michal Simek wrote:
>> Hi Albert,
>>
>> I have just bisect why on the latest kernel hello world example doesn't 
>> work
>> and I have end up in this patch too. After reverting hello world example
>> is working.
>>
>> Also I would like to know if we have still bootm support for standlone
>> http://www.denx.de/wiki/view/DULG/UBootStandalone#Section_5.12.3.
>> Because it is not working for me with error
>> "ERROR: booting os 'U-Boot' (17) is not supported"
>> and I can't see IH_OS_U_BOOT in boot_os table in cmd_bootm.c
>>
>> I have created image like this.
>> ./tools/mkimage -n "hello" -A arm -O u-boot -T standalone -C none -a 
>> c10 -d examples/standalone/hello_world.bin -v /tftpboot/hello.ub
>
> Let's get Albert on CC here, since, yeah, this is a problem...

 This is not just arm specific problem. I see the same problem on 
 Microblaze too.
 Was the support removed or just not tested and something broke it?
>>>
>>> Can you bisect down to where this breaks on microblaze?
>>
>> I even don't know if this has ever worked on Microblaze.
>> The best will be if we can get any input from Denx before someone
>> dive to it.
>> They should be aware when this was working and on which arch/board.
> 
> Well, if you jump back to v2013.01 you should be well before any of this
> happened.  If it works there, try releases up to the last to find the
> bisect range.  If 2013.01 fails then, OK, different problem.

ok. It happened between 2013.04 and 2013.07 by the patch from Simon below.
I have to run now that's why I can't look what exactly it is wrong.

Thanks,
Michal


35fc84fa1ff51e15ecd3e464dac87eb105ffed30 is the first bad commit
commit 35fc84fa1ff51e15ecd3e464dac87eb105ffed30
Author: Simon Glass 
Date:   Tue Jun 11 11:14:47 2013 -0700

Refactor the bootm command to reduce code duplication

At present the bootm code is mostly duplicated for the plain 'bootm'
command and its sub-command variant. This makes the code harder to
maintain and means that changes must be made to several places.

Introduce do_bootm_states() which performs selected portions of the bootm
work, so that both plain 'bootm' and 'bootm ' can use the
same code.

Additional duplication exists in bootz, so tidy that up as well. This
is not intended to change behaviour, apart from minor fixes where the
previously-duplicated code missed some chunks of code.

Signed-off-by: Simon Glass 

:04 04 d474a190a80c65a99484351c6021ba4f25904025 
27382e1ba0944a264044075e01fe99d83852c56e M  common
:04 04 48e1b21b4ad811a0aa718d52253fb264f31b9ffb 
82c78cb1928c5288cbbc651fa01b9588b3f26ac7 M  include


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




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

Re: [U-Boot] (no subject)

[Bojan Buić]

Which register I need set up for hard. watchdog ?

Bojan


2013/11/21 Stefano Babic 

> Hi Bojan,
>
> On 21/11/2013 09:09, Bojan Buić wrote:
> > I'm trying in board iMX233-OLinuXino-MICRO
> > (
> https://www.olimex.com/Products/OLinuXino/iMX233/iMX233-OLinuXino-MICRO/open-source-hardware
> )
> > setup hardware watchdogin the uboot.
> >
> > I checkout uboot code and recompile it(I found steps here :
> > http://www.jann.cc/2013/02/07/u_boot_for_the_imx233_olinuxino.html).
> >
> > I tried to call a function hw_watchdog_init from class: imx_watchdog.c
> > (
> http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/watchdog/imx_watchdog.c;h=d5993b4d26d6ba6018031cc5b31f7966d13a5ca8;hb=c2e5e802ecb7ab668ce9911b210ed68c804b349f
> )
> > in the code  .
> >
> > In this method, I uncomment line # define CONFIG_WATCHDOG_TIMEOUT_MSECS
> > 128000 and I expected that the system will be restarted after, 128
> > seconds, but did not.
> > I am sure that this method(hw_watchdog_init) is called because before
> > and after i write debug messages to console
>
> Wait...
>
> Checking the Makefile in the drivers/watchdog directory:
>
> ifneq (,$(filter $(SOC), mx31 mx35 mx5 mx6 vf610))
> obj-y += imx_watchdog.o
> endif
>
> That is: watchdog is supported for other i.MX families. It is not
> surprising if it is not working, I am surprised that hw_watchdog_init is
> called, because imx_watchdog should not be compiled.
>
> I have not checked inside MX23 manual, but if it is as in MX28 you have
> to enable the watchdog inside the RTC. It works in a different way as in
> other imx, and the current driver is not suitable for MX23. You have to
> add support for it.
>
> Best regards,
> Stefano Babic
>
> --
> =
> DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
> =
>



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

Re: [U-Boot] [PATCH] phy: introduce structure fixed-link

[York Sun]

On 11/14/2013 03:00 AM, shh@gmail.com wrote:
> From: Shaohui Xie 
> 
> fixed-link is used in kernel for PHY-less MAC, so introduce this
> structure that U-boot can use it to fixup dtb dynamically.
> 
> Signed-off-by: Shaohui Xie 
> ---
>  include/phy.h | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/include/phy.h b/include/phy.h
> index f0f522a..f86ffb9 100644
> --- a/include/phy.h
> +++ b/include/phy.h
> @@ -160,6 +160,14 @@ struct phy_device {
>   u32 flags;
>  };
>  
> +struct fixed_link {
> + int phy_id;
> + int duplex;
> + int link_speed;
> + int pause;
> + int asym_pause;
> +};
> +

How is this code used? Do you have other patches following?

York

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

Re: [U-Boot] [PATCH 1/4] net/fman: Add support for 10GEC3 and 10GEC4

[York Sun]

On 11/14/2013 03:31 AM, Shengzhou Liu wrote:
> There are more than two 10GEC in single FMAN in some SoCs(e.g. T2080).
> This patch adds support for 10GEC3 and 10GEC4.
> 
> Signed-off-by: Shengzhou Liu 
> ---
> Against master branch of upstream.
> 
>  arch/powerpc/include/asm/fsl_serdes.h |  2 ++
>  arch/powerpc/include/asm/immap_85xx.h |  2 ++
>  drivers/net/fm/eth.c  |  8 ++--
>  drivers/net/fm/fm.h   |  2 ++
>  drivers/net/fm/init.c | 18 ++
>  include/fm_eth.h  | 18 ++
>  6 files changed, 44 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/powerpc/include/asm/fsl_serdes.h 
> b/arch/powerpc/include/asm/fsl_serdes.h
> index cce892c..404ded4 100644
> --- a/arch/powerpc/include/asm/fsl_serdes.h
> +++ b/arch/powerpc/include/asm/fsl_serdes.h
> @@ -62,6 +62,8 @@ enum srds_prtcl {
>   QSGMII_FM1_B,   /* B indicates MACs 5,6,9,10 */
>   QSGMII_FM2_A,
>   QSGMII_FM2_B,
> + XFI_FM1_MAC1,
> + XFI_FM1_MAC2,
>   XFI_FM1_MAC9,
>   XFI_FM1_MAC10,
>   XFI_FM2_MAC9,
> diff --git a/arch/powerpc/include/asm/immap_85xx.h 
> b/arch/powerpc/include/asm/immap_85xx.h
> index 060e0d7..e47da1d 100644
> --- a/arch/powerpc/include/asm/immap_85xx.h
> +++ b/arch/powerpc/include/asm/immap_85xx.h
> @@ -1717,6 +1717,8 @@ typedef struct ccsr_gur {
>  #define FSL_CORENET_DEVDISR2_DTSEC1_10   0x0040
>  #define FSL_CORENET_DEVDISR2_10GEC1_10x0080
>  #define FSL_CORENET_DEVDISR2_10GEC1_20x0040
> +#define FSL_CORENET_DEVDISR2_10GEC1_30x8000
> +#define FSL_CORENET_DEVDISR2_10GEC1_40x4000
>  #define FSL_CORENET_DEVDISR2_DTSEC2_10x0008
>  #define FSL_CORENET_DEVDISR2_DTSEC2_20x0004
>  #define FSL_CORENET_DEVDISR2_DTSEC2_30x0002
> diff --git a/drivers/net/fm/eth.c b/drivers/net/fm/eth.c
> index cb099cd..e346cd2 100644
> --- a/drivers/net/fm/eth.c
> +++ b/drivers/net/fm/eth.c
> @@ -557,8 +557,12 @@ static int fm_eth_init_mac(struct fm_eth *fm_eth, struct 
> ccsr_fman *reg)
>   num = fm_eth->num;
>  
>  #ifdef CONFIG_SYS_FMAN_V3
> - if (fm_eth->type == FM_ETH_10G_E)
> - num += 8;
> + if (fm_eth->type == FM_ETH_10G_E) {
> + if (fm_eth->num >= 2)
> + num -= 2;
> + else
> + num += 8;
> + }

It would be nice if you can add some comments here.


>   base = ®->memac[num].fm_memac;
>   phyregs = ®->memac[num].fm_memac_mdio;
>  #else
> diff --git a/drivers/net/fm/fm.h b/drivers/net/fm/fm.h
> index 3ec49a4..43de114 100644
> --- a/drivers/net/fm/fm.h
> +++ b/drivers/net/fm/fm.h
> @@ -18,9 +18,11 @@
>  #define RX_PORT_1G_BASE  0x08
>  #define MAX_NUM_RX_PORT_1G   CONFIG_SYS_NUM_FM1_DTSEC
>  #define RX_PORT_10G_BASE 0x10
> +#define RX_PORT_10G_BASE20x08
>  #define TX_PORT_1G_BASE  0x28
>  #define MAX_NUM_TX_PORT_1G   CONFIG_SYS_NUM_FM1_DTSEC
>  #define TX_PORT_10G_BASE 0x30
> +#define TX_PORT_10G_BASE20x28
>  #define MIIM_TIMEOUT0x
>  
>  struct fm_muram {
> diff --git a/drivers/net/fm/init.c b/drivers/net/fm/init.c
> index 35edd7a..cd787f4 100644
> --- a/drivers/net/fm/init.c
> +++ b/drivers/net/fm/init.c
> @@ -64,6 +64,12 @@ struct fm_eth_info fm_info[] = {
>  #if (CONFIG_SYS_NUM_FM1_10GEC >= 2)
>   FM_TGEC_INFO_INITIALIZER(1, 2),
>  #endif
> +#if (CONFIG_SYS_NUM_FM1_10GEC >= 3)
> + FM_TGEC_INFO_INITIALIZER2(1, 3),
> +#endif
> +#if (CONFIG_SYS_NUM_FM1_10GEC >= 4)
> + FM_TGEC_INFO_INITIALIZER2(1, 4),
> +#endif
>  #if (CONFIG_SYS_NUM_FM2_10GEC >= 1)
>   FM_TGEC_INFO_INITIALIZER(2, 1),
>  #endif
> @@ -239,10 +245,14 @@ static void ft_fixup_port(void *blob, struct 
> fm_eth_info *info, char *prop)
>* FM1_10GEC1 is enabled and  FM1_DTSEC9 is disabled, ensure that the
>* dual-role MAC is not disabled, ditto for other dual-role MACs.
>*/

Revise this comment to match your change.


> - if (((info->port == FM1_DTSEC9) && (PORT_IS_ENABLED(FM1_10GEC1)))   
> ||
> - ((info->port == FM1_DTSEC10) && (PORT_IS_ENABLED(FM1_10GEC2)))  
> ||
> - ((info->port == FM1_10GEC1) && (PORT_IS_ENABLED(FM1_DTSEC9)))   
> ||
> - ((info->port == FM1_10GEC2) && (PORT_IS_ENABLED(FM1_DTSEC10)))
> + if (((info->port == FM1_DTSEC9) && (PORT_IS_ENABLED(FM1_10GEC1)))  ||
> + ((info->port == FM1_DTSEC10) && (PORT_IS_ENABLED(FM1_10GEC2))) ||
> + ((info->port == FM1_DTSEC1) && (PORT_IS_ENABLED(FM1_10GEC3)))  ||
> + ((info->port == FM1_DTSEC2) && (PORT_IS_ENABLED(FM1_10GEC4)))  ||
> + ((info->port == FM1_10GEC1) && (PORT_IS_ENABLED(FM1_DTSEC9)))  ||
> + ((info->port == FM1_10GEC2) && (PORT_IS_ENABLED(FM1_DTSEC10))) ||
> + ((info->port == FM1_10GEC3) && (PORT_IS_ENABLED(FM1_DTSEC1)))  ||
> + ((info->port == FM1_10GEC4) && (PORT_IS_ENABLED(FM1_DTSEC2)))

York


__

[U-Boot] tg3 (bcm570x) port available for uboot ?

[John Donnelly]

Hi,

I am starting to port a  older tg3 u-boot driver into the current Network
structure for a p4080 platform and I was wondering if one is already
available.


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

Re: [U-Boot] dra7xx: booting from eMMC raw boot partition

[Richard Retanubun]

On 21/11/13 11:49 AM, Tom Rini wrote:

On Wed, Nov 20, 2013 at 05:27:50PM -0500, Richard Retanubun wrote:

The only way I can get raw eMMC boot mode to work is if I put the MLO
on /dev/mmcblk1 (which is the user data area).


Did you change the SYSBOOT pins to use automotive peripheral mode,
rather than user data?  If you did, you should see an error from MLO
saying that you came in from an unsupported boot device (since we don't
have the value of what ROM tells us for when we come in that way defined
in arch/arm/include/asm/arch-omap5/spl.h).  Or there is some other
problem.

I did try both SYSBOOT for automotive peripheral mode..
I wished it did say something (even if it is an error message).
My problem is that it does not display anything at all.
So, I think I fall under the "some other problem" category. :)


Also note that U-Boot defaults to using these "boot"
partitions for storing the environment so you will need to change that
part of the config once you use these partitions for something else.


Thank you for the heads up. I'll watch out for this when I get to this phase.

Tom, since you're both the u-boot-arm maintainer and happens to work for TI,
do you know the e.t.a of mainlining the /drivers/mmc/spl_mmc.c and the related
code needed to boot from eMMC in raw mode into denx-master?

I rather stick with denx-master mainline if at all possible,
but right now the functionality only exist in p-ti-u-boot-2013.04, right?

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

Re: [U-Boot] dra7xx: booting from eMMC raw boot partition

[Tom Rini]

On Thu, Nov 21, 2013 at 12:57:10PM -0500, Richard Retanubun wrote:
> On 21/11/13 11:49 AM, Tom Rini wrote:
> >On Wed, Nov 20, 2013 at 05:27:50PM -0500, Richard Retanubun wrote:
> >>The only way I can get raw eMMC boot mode to work is if I put the MLO
> >>on /dev/mmcblk1 (which is the user data area).
> >
> >Did you change the SYSBOOT pins to use automotive peripheral mode,
> >rather than user data?  If you did, you should see an error from MLO
> >saying that you came in from an unsupported boot device (since we don't
> >have the value of what ROM tells us for when we come in that way defined
> >in arch/arm/include/asm/arch-omap5/spl.h).  Or there is some other
> >problem.
> I did try both SYSBOOT for automotive peripheral mode..
> I wished it did say something (even if it is an error message).
> My problem is that it does not display anything at all.
> So, I think I fall under the "some other problem" category. :)
> 
> >Also note that U-Boot defaults to using these "boot"
> >partitions for storing the environment so you will need to change that
> >part of the config once you use these partitions for something else.
> >
> Thank you for the heads up. I'll watch out for this when I get to this phase.
> 
> Tom, since you're both the u-boot-arm maintainer and happens to work for TI,
> do you know the e.t.a of mainlining the /drivers/mmc/spl_mmc.c and the related
> code needed to boot from eMMC in raw mode into denx-master?
> 
> I rather stick with denx-master mainline if at all possible,
> but right now the functionality only exist in p-ti-u-boot-2013.04, right?

I've done RAW mode booting on my omap5_uevm as well as am335x-based
platforms, on SD card and eMMC.  But in the case of eMMC it's always the
user partitions.  I suspect the answer is that for automotive booting
you need silicon that supports that, much like the difference between HS
and GP devices.  I'm not sure what code in p-ti-u-boot-2013.04 hasn't
been merged to mainline but if you can give me some pointers I can go
and poke some folks.

-- 
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 0/9] ARMv7: add PSCI support to u-boot

[Marc Zyngier]

Hi Rob,

On 21/11/13 14:28, Rob Herring wrote:
> On Thu, Nov 21, 2013 at 2:59 AM, Marc Zyngier  wrote:
>> PSCI is an ARM standard that provides a generic interface that
>> supervisory software can use to manage power in the following
>> situations:
>> - Core idle management
>> - CPU hotplug
>> - big.LITTLE migration models
>> - System shutdown and reset
>>
>> It basically allows the kernel to offload these tasks to the firmware,
>> and rely on common kernel side code.
>>
>> More importantly, it gives a way to ensure that CPUs enter the kernel
>> at the appropriate exception level (ie HYP mode, to allow the use of
>> the virtualization extensions), even across events like CPUs being
>> powered off/on or suspended.
>>
>> The main idea here is to reuse some of the existing u-boot code to
>> create a separate blob that can live in SRAM (or a reserved page of
>> memory), containing a secure monitor that will implement the PSCI
>> operations. This code will still be alive when u-boot is long gone,
>> hence the need for a piece of memory that will not be touched by the
>> OS.
> 
> Interesting. As a separate binary, I'm not sure this belongs or
> benefits from being in u-boot. I would like to see this as a more
> generic secure firmware loader or PSCI code be a part of u-boot code
> directly. With the latter, you could extend it beyond PSCI to things
> like env variable access (basically equivalent to UEFI runtime
> services). I'm not saying we should do that though.

So I started this by having something that was actually part of u-boot,
and copying itself into SRAM, patching stuff as it went. The net result
was that I was reinventing a runtime linker. Needless to say, I gave up
quickly... ;-)

What could be done would be for u-boot to be at least partially linked
to run from some other region. That would allow for the secure mode
services to be both part of u-boot, and stay resident.

That'd probably be a good thing to have a look at.

> BTW, you will need to mark this region reserved in the dtb if in system RAM.

Yes. Eventually, I'd like the psci mode to be entirely generated from
u-boot, as well as the eventual RAM reserved.

M.
-- 
Jazz is not dead. It just smells funny...

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

Re: [U-Boot] dra7xx: booting from eMMC raw boot partition

[Richard Retanubun]

On 21/11/13 01:09 PM, Tom Rini wrote:

I've done RAW mode booting on my omap5_uevm as well as am335x-based
platforms, on SD card and eMMC.  But in the case of eMMC it's always the
user partitions.  I suspect the answer is that for automotive booting
you need silicon that supports that, much like the difference between HS
and GP devices.


Agreed. If by silicon you mean the CPU, then all the docs I've seen
(the TRM for DRA7xx and SYSBOOT in automotive peripheral mode seem to indicate 
that
the SoC is capable or Raw eMMC boot partition booting.


I'm not sure what code in p-ti-u-boot-2013.04 hasn't
been merged to mainline but if you can give me some pointers I can go
and poke some folks.

Thanks for the offer, poke gently :)

I think it is essentially all the code that touches /drivers/mmc/spl_mmc.c on 
the ti tree here:

http://git.omapzoom.org/?p=repo/u-boot.git;a=history;f=drivers/mmc/spl_mmc.c;h=bd7e34bed35a1518d714232a8aedbc2e38d43632;hb=refs/heads/p-ti-u-boot-2013.04

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

Re: [U-Boot] patchwork does not pick my patch

[Andreas Bießmann]

Dear Masahiro Yamada,

+patchwork list

On 11/21/2013 12:14 PM, Masahiro Yamada wrote:
> Hi.
> 
> I posted a patch to change a file permission.
> This:
> http://lists.denx.de/pipermail/u-boot/2013-November/167573.html
> 
> and again:
> http://lists.denx.de/pipermail/u-boot/2013-November/167608.html
> 
> 
> But my patch would not appear on patchwork.
> (Maybe because there is no diff line.)

I think so too. There is some handling for renames without patch in
patchwork, but I think there is no handling for just file permission
changes. That should be fixed in patchwork then.

> What should I do?

File bug report at patchwork ML?

> Is it better to squash it to another patch?

Well to show it up in patchwork that could work. Since this change is
quite trivial I think it will also work if you just peak the relevant
custodian to pick this from the list.

Best regards

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

[U-Boot] patchwork does not pick my patch

[Masahiro Yamada]

Hi.

I posted a patch to change a file permission.
This:
http://lists.denx.de/pipermail/u-boot/2013-November/167573.html

and again:
http://lists.denx.de/pipermail/u-boot/2013-November/167608.html


But my patch would not appear on patchwork.
(Maybe because there is no diff line.)

What should I do?
Is it better to squash it to another patch?


Best Regard
Masahiro Yamada

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

Re: [U-Boot] Help needed: Boot signed RTOS

[Christopher Preschern]

Hi Simon,

thanks for the quick answer.


   => bootm 0x4200
   ## Loading kernel from FIT Image at 4200 ...
  Using 'conf@1' configuration
  Verifying Hash Integrity ... OK
  Trying 'kernel@1' kernel subimage
Description:  safeRTOS Kernel
Type: Kernel Image (no loading done)


This means Linux kernel. You probably need a new type


ok thanks - I guess that's a bit too big for me - I don't really have 
the expertise to make these changes.


I had hoped that I just have the wrong configuration in the .its file 
and that it is already possible to boot my FIT-packed ELF file.


thanks anyway.

Best regards,
Christopher


--
  --
| Christopher Preschern
| Institute for Technical Informatics - TU Graz
| Tel: +43 (316) 873 - 6404
| EMail: christopher.presch...@tugraz.at
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/9] ARM: HYP/non-sec: fix alignment requirements for vectors

[Marc Zyngier]

Hi Masahiro,

On 21/11/13 10:19, Masahiro Yamada wrote:
> Hello Marc
> 
>> +.align  5   @ Minimal alignment for vectors
>> +
>>  /* the vector table for secure state and HYP mode */
>>  _monitor_vectors:
>>  .word 0 /* reset */
>> @@ -32,7 +34,6 @@ _monitor_vectors:
>>   * to non-secure state.
>>   * We use only r0 and r1 here, due to constraints in the caller.
>>   */
>> -.align  5
>>  _secure_monitor:
>>  mrc p15, 0, r1, c1, c1, 0   @ read SCR
>>  bic r1, r1, #0x4e   @ clear IRQ, FIQ, EA, nET bits
> 
> Correct.
> 
> I had posted a patch to fix this problem.
> http://patchwork.ozlabs.org/patch/280915/
> But it have not been appiled yet.

How comes nobody cares about it? This is really a nasty one to track
down, as it completely depends on the surrounding objects.

/me puzzled.

M.
-- 
Jazz is not dead. It just smells funny...

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

Re: [U-Boot] [PATCH v3] mtd: move & update nand_ecclayout structure (plus board changes)

[Stefan Roese]

Hi Scott,

On 11/21/2013 06:27 AM, Scott Wood wrote:
> From: Prabhakar Kushwaha 
> 
> nand_ecclayout is present in mtd.h at Linux.
> Move this structure to mtd.h to comply with Linux.
> 
> Also, increase the ecc placement locations to 640 to suport device having
> writesize/oobsize of 8KB/640B. This means that the maximum oobsize has gone
> up to 640 bytes and consequently the maximum ecc placement locations have
> also gone up to 640.
> 
> Changes from Prabhabkar's version (squashed into one patch to preserve
> bisectability):
>  - Added _LARGE to MTD_MAX_*_ENTRIES
> 
>This makes the names match current Linux source, and resolves
>a conflict between
>http://patchwork.ozlabs.org/patch/280488/
>and
>http://patchwork.ozlabs.org/patch/284513/
> 
>The former was posted first and is closer to matching Linux, but
>unlike Linux it does not add _LARGE to the names.  The second adds
>_LARGE to one of the names, and depends on it in a subsequent patch
>(http://patchwork.ozlabs.org/patch/284512/).
> 
>  - Made max oobfree/eccpos configurable, and used this on tricorder,
>alpr, ASH405, T4160QDS, and T4240QDS (these boards failed to build
>for me without doing so, due to a size increase).
> 
>On tricorder SPL, this saves 2576 bytes (and makes the SPL build
>again) versus the new default of 640 eccpos and 32 oobfree, and
>saves 336 bytes versus the old default of 128 eccpos and 8 oobfree.
> 
> Signed-off-by: Prabhakar Kushwaha 
> CC: Vipin Kumar 
> [scottw...@freescale.com: changes as described above]
> Signed-off-by: Scott Wood 
> Cc: Thomas Weber 
> Cc: Matthias Fuchs 
> Cc: Stefan Roese 
> Cc: York Sun 
> Cc: Tom Rini 

I don't have any affected board to test this on (maintained by myself),
but this change looks reasonable. So:

Reviewed-by: Stefan Roese 

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

[U-Boot] [PATCH, RESEND] Blackfin: remove executable permission of AWK script

[Masahiro Yamada]

Signed-off-by: Masahiro Yamada 
---
 arch/blackfin/cpu/bootrom-asm-offsets.awk | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 mode change 100755 => 100644 arch/blackfin/cpu/bootrom-asm-offsets.awk

diff --git a/arch/blackfin/cpu/bootrom-asm-offsets.awk 
b/arch/blackfin/cpu/bootrom-asm-offsets.awk
old mode 100755
new mode 100644
-- 
1.8.3.2

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

Re: [U-Boot] [PATCH 1/9] ARM: HYP/non-sec: fix alignment requirements for vectors

[Masahiro Yamada]

Hello Marc

> + .align  5   @ Minimal alignment for vectors
> +
>  /* the vector table for secure state and HYP mode */
>  _monitor_vectors:
>   .word 0 /* reset */
> @@ -32,7 +34,6 @@ _monitor_vectors:
>   * to non-secure state.
>   * We use only r0 and r1 here, due to constraints in the caller.
>   */
> - .align  5
>  _secure_monitor:
>   mrc p15, 0, r1, c1, c1, 0   @ read SCR
>   bic r1, r1, #0x4e   @ clear IRQ, FIQ, EA, nET bits

Correct.

I had posted a patch to fix this problem.
http://patchwork.ozlabs.org/patch/280915/
But it have not been appiled yet.


Best Regards
Masahiro Yamada

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

Re: [U-Boot] [PATCH] pcm051: Support for revision 3

[Lars Poeschel]

Am Dienstag, 19. November 2013, 15:08:27 schrieb Tom Rini:
> On Tue, Nov 19, 2013 at 11:22:18AM +0100, Lars Poeschel wrote:
> > From: Lars Poeschel 
> > 
> > Phytec sells revision or version 3 of pcm051. It is labeled 1358.3 on
> > the board. The difference for u-boot is that is has other DDR3 RAM on it:
> > 1 x MT41K256M16HA125E instead of 2 x MT41J256M8HX15E on revisions 1 and
> > 2. Both configurations are 512 MiB.
> > Configure your u-boot build with pcm051_rev3 for the new RAM and
> > pcm051_rev1 for the old RAM configuration. Board revision 2 has to use
> > pcm051_rev1 also.
> > 
> > Signed-off-by: Lars Poeschel 
> 
> Is there no run-time way to tell if we're on rev1/2/3?

Unfortunately I am not aware of a 100% bullet proof one.
One way would be to read the AM3359 silicon ID. I have two boards here: rev1 
and rev3. The phytec rev3 board has a newer silicon on it. I don't know about 
rev2's silicon ID. And I am not sure if the rev3 silicon change directly 
corresponds to the DDR RAM change and if all rev3 boards have the new silicon. 
What I know for sure is that the RAM change was with rev3.
Nevertheless phytec itself supplies a patched barebox as bootloader. And they 
have a compile time config option for different RAM configurations of the 
board. 
And they even seem to have more RAM configurations than the two I have seen 
yet.

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

[U-Boot] [PATCH v2] MAKEALL: add -b (--board) option

[Masahiro Yamada]

Some board have multiple configurations.
For example, the board "m54455evb" has many configurations:
M54455EVB, M54455EVB_a66, M54455EVB_i66, M54455EVB_intel, ...

When we modify board-related files, we need to test
all configurations based on such a board.

In such a case, the new option -b is useful.

Signed-off-by: Masahiro Yamada 
---

Changes in v2:
  - fix a typo in log
s/usefull/useful/

 MAKEALL | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/MAKEALL b/MAKEALL
index 80cd4f8..a74f0fc 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -18,6 +18,7 @@ usage()
  -c CPU,--cpu CPU Build all boards with cpu CPU
  -v VENDOR, --vendor VENDOR   Build all boards with vendor VENDOR
  -s SOC,--soc SOC Build all boards with soc SOC
+ -b BOARD,  --board BOARD Build all boards with board name BOARD
  -l,--listList all targets to be built
  -m,--maintainers List all targets and maintainer email
  -M,--mails   List all targets and all affilated emails
@@ -59,8 +60,8 @@ usage()
exit ${ret}
 }
 
-SHORT_OPTS="ha:c:v:s:lmMCnr"
-LONG_OPTS="help,arch:,cpu:,vendor:,soc:,list,maintainers,mails,check,continue,rebuild-errors"
+SHORT_OPTS="ha:c:v:s:b:lmMCnr"
+LONG_OPTS="help,arch:,cpu:,vendor:,soc:,board:,list,maintainers,mails,check,continue,rebuild-errors"
 
 # Option processing based on util-linux-2.13/getopt-parse.bash
 
@@ -121,6 +122,17 @@ while true ; do
fi
SELECTED='y'
shift 2 ;;
+   -b|--board)
+   # echo "Option BOARD: argument \`$2'"
+   if [ "$opt_b" ] ; then
+   opt_b="${opt_b%)} || \$6 == \"$2\" || \$7 == \"$2\")"
+   else
+   # We need to check the 7th field too
+   # for boards whose 6th field is "-"
+   opt_b="(\$6 == \"$2\" || \$7 == \"$2\")"
+   fi
+   SELECTED='y'
+   shift 2 ;;
-C|--check)
CHECK='C=1'
shift ;;
@@ -158,6 +170,7 @@ FILTER="\$1 !~ /^#/"
 [ "$opt_c" ] && FILTER="${FILTER} && $opt_c"
 [ "$opt_s" ] && FILTER="${FILTER} && $opt_s"
 [ "$opt_v" ] && FILTER="${FILTER} && $opt_v"
+[ "$opt_b" ] && FILTER="${FILTER} && $opt_b"
 
 if [ "$SELECTED" ] ; then
SELECTED=$(awk '('"$FILTER"') { print $7 }' boards.cfg)
-- 
1.8.3.2

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

Re: [U-Boot] [PATCH] blackfin: soft-i2c: No need to define blackfin specific soft i2c operations.

[Masahiro Yamada]

Hello Sonic


About the subject of your patches

> blackfin: soft-i2c: No need to define blackfin specific soft i2c operations.

U-Boot wiki page [http://www.denx.de/wiki/U-Boot/Patches]
says like this:

 -Don't use periods to end the summary line
(e.g., don't do "Add support for X.")



Best Regards
Masahiro Yamada

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

Re: [U-Boot] [PATCH] Net: FEC: Fix huge memory leak

[Stefano Babic]

Hi Marek,

On 12/10/2013 20:36, Marek Vasut wrote:
> The fec_halt() never free'd both RX and TX DMA descriptors that
> were allocated in fec_init(), nor did it free the RX buffers.
> Rework the FEC driver so that these descriptors and buffers are
> allocated only once in fec_probe().
> 
> Signed-off-by: Marek Vasut 
> Cc: Fabio Estevam 
> Cc: Stefano Babic 
> ---

Applied to u-boot-imx, thanks.

Best regards,
Stefano Babic

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

Re: [U-Boot] [PATCH] arm: omap3: Enable clocks for peripherals only if they are used

[Igor Grinberg]

On 11/20/13 22:07, Michael Trimarchi wrote:
> Hi
> 
> On Wed, Nov 20, 2013 at 5:19 PM, Tom Rini  wrote:
>> On Tue, Nov 19, 2013 at 12:56:13PM +0100, Michael Trimarchi wrote:
>>> Hi
>>>
>>> On Tue, Nov 19, 2013 at 12:10 PM, Igor Grinberg  
>>> wrote:
 Hi Michael,

 On 11/19/13 10:59, Michael Trimarchi wrote:
> Hi Igor
>
> On Tue, Nov 19, 2013 at 9:49 AM, Michael Trimarchi
>  wrote:
>> Hi Igor
>>
>> On Tue, Nov 19, 2013 at 9:24 AM, Igor Grinberg  
>> wrote:
>>> Hi Michael,
>>>
>>> On 11/18/13 16:10, Michael Trimarchi wrote:
 Enable clocks for the peripherals only if they are used

 This is not exactly what the patch does, right?
 I would expect a better description of what you do in the patch
 and what are the consequences of this patch.
>>>
>>> It does the right. If you open the files you can find that clock
>>> are enabled if the peripheral is used.
>>>
 May be some of the consequences can be avoided?

>>>
>>> Yes, this is correct. Most of the consequences come if
>>> you use gpio bank and you don't active them
>>>

 Signed-off-by: Michael Trimarchi 
 ---
  arch/arm/cpu/armv7/omap3/clock.c| 2 --
  arch/arm/include/asm/arch-omap3/clock.h | 2 --
  2 files changed, 4 deletions(-)

 diff --git a/arch/arm/cpu/armv7/omap3/clock.c 
 b/arch/arm/cpu/armv7/omap3/clock.c
 index 14fc7e8..1bc27bd 100644
 --- a/arch/arm/cpu/armv7/omap3/clock.c
 +++ b/arch/arm/cpu/armv7/omap3/clock.c
 @@ -730,8 +730,6 @@ void per_clocks_enable(void)
   sr32(&prcm_base->fclken_cam, 0, 32, FCK_CAM_ON);
   sr32(&prcm_base->iclken_cam, 0, 32, ICK_CAM_ON);
   }
 - sr32(&prcm_base->fclken_per, 0, 32, FCK_PER_ON);
 - sr32(&prcm_base->iclken_per, 0, 32, ICK_PER_ON);
>>>
>>> Hmmm...
>>> Am I missing something or is this change breaks boards that
>>> currently rely on the peripheral clocks being enabled here?
>>>
>>
>> This change break boards that are not correctly configured.

 I don't agree on this one.
 This change breaks boards that are _correctly_ configured
 prior to the patch.
>>>
>>> If you think that if the boards are correct they should boot
>>
>> I think this is an extension of the CONFIG_SYS_ENABLE_PADS_ALL /
>> CONFIG_SYS_CLOCKS_ENABLE_ALL problem.  The long stated design of U-Boot
>> is we enable what we need.  The long stated design of the Linux Kernel,
> 
> Do you want me to re-submit with a better description?

I definitely do!!!
One of my biggest concerns is the lack of the description
for such patches.
It must be clear to anyone who looks at the log, what this patch does.
So, as for me, the patch itself is _fine_ (I also was always concerned
about enabling clocks, remember the OMAP3 USB submissions?), but
we must have a good description of what exactly may break after the
patch. So if its lack of CONFIG_* defines, it must be stated in the
commit message. If it is GPT clocks, WDOG clock, etc... - it must be
stated in the commit message and we also need to consider adding
CONFIG_* options for those that don't have such an option (e.g. GPT, WDOG).

> 
> Michael
> 
>> in general, is that it doesn't rely on the bootloader to have enabled
>> all of this.  And then various vendors (mine included) broke both rules
>> for a while when people weren't paying enough attention.  So yes, it's
>> likely that some boards will break because they assume the clock was
>> enabled for them.
>>
>> The question is, are there boards where it's reasonable to assume people
>> would upgrade U-Boot but not upgrade the kernel and see this problem?
>> That I don't know the answer to.

Well, yes there are customers who will upgrade U-Boot and
not touch the kernel.

>>
>> The second question is, are there problems with leaving the clock
>> enablement on?  I suspect there is, which is how this was run into in
>> the first place.

Unless, we can leave OMAP3 like it was, but be more strict regarding
newer SoCs.

>>
>> At some level the platforms people use today and their needs outweigh
>> the problems of the platforms people used to use, but still maybe could,
>> if they wanted to dust it off and plug it in, and it didn't just up and
>> die on them.
>>
>> --
>> Tom
> 

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

Re: [U-Boot] [PATCH 0/4] Wandboard support for Future Eletronics 7" WVGA LCD extension board

[Stefano Babic]

Hi Otavio,

On 22/10/2013 01:34, Otavio Salvador wrote:
> This patchset adds support for the Future Eletronics 7" WVGA LCD
> extension board and implements its auto-detection using i2c to check
> for it's touch controller presence.
> 
> The IOMUXC change is included here as it makes both SoC type MUX
> settings in line to each other and took a while to figure out why it
> worked with one and failed with another SoC.
> 
> 
> Otavio Salvador (4):
>   mx6: Remove PAD_CTL_DSE_120ohm from i.MX6DL's IPU1_DI0_PIN4 pin
>   wandboard: add Future Eletronics 7" WVGA LCD extension board
>   wandboard: Use '0' as bootdelay but interruptable
>   wandboard: Pass 'quiet' bootparam by default
> 
>  arch/arm/include/asm/arch-mx6/mx6dl_pins.h |   2 +-
>  board/wandboard/wandboard.c| 238 
> ++---
>  include/configs/wandboard.h|  38 -
>  3 files changed, 254 insertions(+), 24 deletions(-)

I confess that I hoped that Simon's patches to extract the env from the
board configuration file could be merged very soon into mainline, but
they are not yet merged, and I am blocking some patches, mostly
Otavio's. Again, there is also patches adding new feature as this one
for the Future Electronics display, that contains also many additions to
CONFIG_EXTRA_ENV_SETTINGS.

I will apply the patch for Future's display - it is much more as only a
change to default environment - but I am still confident that we can do
in the right way once and I will let the other patches in my queue.

Otavio, this regards your patches:
http://patchwork.ozlabs.org/patch/285295/
http://patchwork.ozlabs.org/patch/285296/
http://patchwork.ozlabs.org/patch/285294/

Best regards,
Stefano

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

Re: [U-Boot] (no subject)

[Bojan Buić]

Stefano you're right :),

I copy this method to main.c class and then call it, because when i call it
from extern class it did not work

Does someone know how write function which will start hard. watchdog on
mx23 controller ? I not very familiar with registry of this proc.

Thank you


2013/11/21 Stefano Babic 

> Hi Bojan,
>
> On 21/11/2013 09:09, Bojan Buić wrote:
> > I'm trying in board iMX233-OLinuXino-MICRO
> > (
> https://www.olimex.com/Products/OLinuXino/iMX233/iMX233-OLinuXino-MICRO/open-source-hardware
> )
> > setup hardware watchdogin the uboot.
> >
> > I checkout uboot code and recompile it(I found steps here :
> > http://www.jann.cc/2013/02/07/u_boot_for_the_imx233_olinuxino.html).
> >
> > I tried to call a function hw_watchdog_init from class: imx_watchdog.c
> > (
> http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/watchdog/imx_watchdog.c;h=d5993b4d26d6ba6018031cc5b31f7966d13a5ca8;hb=c2e5e802ecb7ab668ce9911b210ed68c804b349f
> )
> > in the code  .
> >
> > In this method, I uncomment line # define CONFIG_WATCHDOG_TIMEOUT_MSECS
> > 128000 and I expected that the system will be restarted after, 128
> > seconds, but did not.
> > I am sure that this method(hw_watchdog_init) is called because before
> > and after i write debug messages to console
>
> Wait...
>
> Checking the Makefile in the drivers/watchdog directory:
>
> ifneq (,$(filter $(SOC), mx31 mx35 mx5 mx6 vf610))
> obj-y += imx_watchdog.o
> endif
>
> That is: watchdog is supported for other i.MX families. It is not
> surprising if it is not working, I am surprised that hw_watchdog_init is
> called, because imx_watchdog should not be compiled.
>
> I have not checked inside MX23 manual, but if it is as in MX28 you have
> to enable the watchdog inside the RTC. It works in a different way as in
> other imx, and the current driver is not suitable for MX23. You have to
> add support for it.
>
> Best regards,
> Stefano Babic
>
> --
> =
> DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
> =
>



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

Re: [U-Boot] [[PATCH v2]pandaboard: 1/1] Modification of Elpida DDR2 RAM for Pandaboard-ES Rev B3

[jmgrimaud]

Hello,
I'm glad to see that solutions arrive to be able to boot on Pandaboard Rev
B3.
On top of this, does anybody could indicate me where I can find the u-boot
repository and how to build it for Pandaboard ?

To summarize, I made 3 tests:

clone git://git.denx.de/u-boot.git
checkout v2013.10 -b tmp
build with omap4_panda_config
>> when I flash MLO and u-boot.bin files in my sdcard, it does not boot at
>> all

clone https://android.googlesource.com/device/ti/panda/bootloader/uboot.git
no specific checkout
build with omap4_panda_config
>> when I flash MLO and u-boot.bin files in my sdcard, it does not boot at
>> all

follow instructions from omappedia, i.e. retrieve, patch and build u-boot
and xloader from git.omapzoom.org
(http://omappedia.org/wiki/4AI.1.7_OMAP4_Icecream_Sandwich_Panda_Notes).
>> when I flash xloader and bootloader files in my sdcard, it works very
>> well on PandaRevB2, but not on Rev B3. Unfortunately, I do not know how
>> to apply the changes described in this subject, as there is not the same
>> files.





--
View this message in context: 
http://u-boot.10912.n7.nabble.com/PATCH-pandaboard-0-1-Modification-of-Elpida-DDR2-RAM-for-Pandaboard-ES-Rev-B3-tp166135p168096.html
Sent from the U-Boot mailing list archive at Nabble.com.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 1/9] ARM: HYP/non-sec: fix alignment requirements for vectors

[Marc Zyngier]

Make sure the vectors are aligned on a 32 byte boundary, not
the code that deals with it...

Signed-off-by: Marc Zyngier 
---
 arch/arm/cpu/armv7/nonsec_virt.S | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/cpu/armv7/nonsec_virt.S b/arch/arm/cpu/armv7/nonsec_virt.S
index 24b4c18..29987cd 100644
--- a/arch/arm/cpu/armv7/nonsec_virt.S
+++ b/arch/arm/cpu/armv7/nonsec_virt.S
@@ -14,6 +14,8 @@
 .arch_extension sec
 .arch_extension virt
 
+   .align  5   @ Minimal alignment for vectors
+
 /* the vector table for secure state and HYP mode */
 _monitor_vectors:
.word 0 /* reset */
@@ -32,7 +34,6 @@ _monitor_vectors:
  * to non-secure state.
  * We use only r0 and r1 here, due to constraints in the caller.
  */
-   .align  5
 _secure_monitor:
mrc p15, 0, r1, c1, c1, 0   @ read SCR
bic r1, r1, #0x4e   @ clear IRQ, FIQ, EA, nET bits
-- 
1.8.2.3


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

[U-Boot] [PATCH 4/9] ARM: non-sec: reset CNTVOFF to zero

[Marc Zyngier]

Before switching to non-secure, make sure that CNTVOFF is set
to zero on all CPUs. Otherwise, kernel running in non-secure
without HYP enabled (hence using virtual timers) may observe
timers that are not synchronized, effectively seeing time
going backward...

Signed-off-by: Marc Zyngier 
---
 arch/arm/cpu/armv7/nonsec_virt.S | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/cpu/armv7/nonsec_virt.S b/arch/arm/cpu/armv7/nonsec_virt.S
index 648066f..bbacbce 100644
--- a/arch/arm/cpu/armv7/nonsec_virt.S
+++ b/arch/arm/cpu/armv7/nonsec_virt.S
@@ -53,7 +53,14 @@ _secure_monitor:
mrceq   p15, 0, r0, c12, c0, 1  @ get MVBAR value
mcreq   p15, 4, r0, c12, c0, 0  @ write HVBAR
 #endif
+   bne 1f
 
+   @ Reset CNTVOFF to 0 before leaving monitor mode
+   mrc p15, 0, r0, c0, c1, 1   @ read ID_PFR1
+   andsr0, r0, #CPUID_ARM_GENTIMER_MASK@ test arch timer bits
+   movne   r0, #0
+   mcrrne  p15, 4, r0, r0, c14 @ Reset CNTVOFF to zero
+1:
movspc, lr  @ return to non-secure SVC
 
 _hyp_trap:
-- 
1.8.2.3


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

[U-Boot] [PATCH 2/9] ARM: HYP/non-sec: move switch to non-sec to the last boot phase

[Marc Zyngier]

Having the switch to non-secure in the "prep" phase is causing
all kind of troubles, as that stage can be called multiple times.

Instead, move the switch to non-secure to the last possible phase,
when there is no turning back anymore.

Signed-off-by: Marc Zyngier 
---
 arch/arm/lib/bootm.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
index f476a89..f3da634 100644
--- a/arch/arm/lib/bootm.c
+++ b/arch/arm/lib/bootm.c
@@ -234,7 +234,6 @@ static void boot_prep_linux(bootm_headers_t *images)
printf("FDT and ATAGS support not compiled in - hanging\n");
hang();
}
-   do_nonsec_virt_switch();
 }
 
 /* Subcommand: GO */
@@ -264,8 +263,10 @@ static void boot_jump_linux(bootm_headers_t *images, int 
flag)
else
r2 = gd->bd->bi_boot_params;
 
-   if (!fake)
+   if (!fake) {
+   do_nonsec_virt_switch();
kernel_entry(0, machid, r2);
+   }
 }
 
 /* Main Entry point for arm bootm implementation
-- 
1.8.2.3


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

[U-Boot] [PATCH 9/9] sunxi: HYP/non-sec: configure CNTFRQ on all CPUs

[Marc Zyngier]

CNTFRQ needs to be properly configured on all CPUs. Otherwise,
virtual machines hoping to find valuable information on secondary
CPUs will be disapointed...

Signed-off-by: Marc Zyngier 
---
 include/configs/sun7i.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/sun7i.h b/include/configs/sun7i.h
index 1d6fd22..facbf92 100644
--- a/include/configs/sun7i.h
+++ b/include/configs/sun7i.h
@@ -43,6 +43,7 @@
 #define CONFIG_ARMV7_PSCI  1
 #define CONFIG_ARMV7_PSCI_NR_CPUS  2
 #define CONFIG_ARMV7_PSCI_BASE SUNXI_SRAM_A2_BASE
+#define CONFIG_SYS_CLK_FREQ2400
 
 /*
  * Include common sunxi configuration where most the settings are
-- 
1.8.2.3


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

[U-Boot] [PATCH 0/9] ARMv7: add PSCI support to u-boot

[Marc Zyngier]

PSCI is an ARM standard that provides a generic interface that
supervisory software can use to manage power in the following
situations:
- Core idle management
- CPU hotplug
- big.LITTLE migration models
- System shutdown and reset

It basically allows the kernel to offload these tasks to the firmware,
and rely on common kernel side code.

More importantly, it gives a way to ensure that CPUs enter the kernel
at the appropriate exception level (ie HYP mode, to allow the use of
the virtualization extensions), even across events like CPUs being
powered off/on or suspended.

The main idea here is to reuse some of the existing u-boot code to
create a separate blob that can live in SRAM (or a reserved page of
memory), containing a secure monitor that will implement the PSCI
operations. This code will still be alive when u-boot is long gone,
hence the need for a piece of memory that will not be touched by the
OS.

This patch series contains 3 parts:
- the first four patches are just bug fixes
- the next three contain the generic PSCI code and build infrastructure
- the last two implement the CPU_ON method of the Allwinner A20 (aka sun7i).

I realize the A20 u-boot code is not upstream yet (BTW is anyone
actively working on that?), but hopefully that should give a good idea
of how things are structured so far. The patches are against a merge
of u-boot mainline and the sunxi tree as of ten days ago.

As for using this code, it goes like this:
sun7i# ext2load mmc 0:1 0x4000 /boot/sunxi-psci.bin
908 bytes read in 18 ms (48.8 KiB/s)
sun7i# cp 0x4000 0x4000 0x1000
sun7i# ext2load mmc 0:1 40008000 /boot/zImage
3415087 bytes read in 184 ms (17.7 MiB/s)
sun7i# setenv bootargs console=ttyS0,115200 earlyprintk root=/dev/nfs 
nfsroot=10.1.203.35:/export/roots/bobby-brown,tcp,v3 rw ip=dhcp
sun7i# bootz 40008000

The kernel now boots in HYP mode, finds its secondary CPU without any
additional SMP code, and runs KVM out of the box. Hopefully, the
Xen/ARM guys can do the same fairly easily.

I'm wildly cross-posting this patch series, including to lists I'm not
subscribed to. Please keep me on Cc for any comment you may have.

Cheers,

M.

Marc Zyngier (9):
  ARM: HYP/non-sec: fix alignment requirements for vectors
  ARM: HYP/non-sec: move switch to non-sec to the last boot phase
  ARM: HYP/non-sec: add a barrier after setting SCR.NS==1
  ARM: non-sec: reset CNTVOFF to zero
  ARM: HYP/non-sec: add generic ARMv7 PSCI code
  ARM: HYP/non-sec: make pen code sections depend on !ARMV7_PSCI
  ARM: HYP/non-sec: add the option for a second-stage monitor
  sunxi: HYP/non-sec: add sun7i PSCI backend
  sunxi: HYP/non-sec: configure CNTFRQ on all CPUs

 Makefile |   5 ++
 arch/arm/cpu/armv7/Makefile  |   4 ++
 arch/arm/cpu/armv7/nonsec_virt.S |  21 +-
 arch/arm/cpu/armv7/psci.S| 109 
 arch/arm/cpu/armv7/sunxi/Makefile|   3 +
 arch/arm/cpu/armv7/sunxi/config.mk   |   6 +-
 arch/arm/cpu/armv7/sunxi/psci.S  | 119 +++
 arch/arm/cpu/armv7/sunxi/u-boot-psci.lds |  63 
 arch/arm/cpu/armv7/virt-v7.c |   2 +
 arch/arm/lib/bootm.c |   5 +-
 include/configs/sun7i.h  |   7 ++
 psci/Makefile|  67 +
 12 files changed, 406 insertions(+), 5 deletions(-)
 create mode 100644 arch/arm/cpu/armv7/psci.S
 create mode 100644 arch/arm/cpu/armv7/sunxi/psci.S
 create mode 100644 arch/arm/cpu/armv7/sunxi/u-boot-psci.lds
 create mode 100644 psci/Makefile

-- 
1.8.2.3


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

[U-Boot] [PATCH 3/9] ARM: HYP/non-sec: add a barrier after setting SCR.NS==1

[Marc Zyngier]

A CP15 instruction execution can be reordered, requiring an
isb to be sure it is executed in program order.

Signed-off-by: Marc Zyngier 
---
 arch/arm/cpu/armv7/nonsec_virt.S | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/cpu/armv7/nonsec_virt.S b/arch/arm/cpu/armv7/nonsec_virt.S
index 29987cd..648066f 100644
--- a/arch/arm/cpu/armv7/nonsec_virt.S
+++ b/arch/arm/cpu/armv7/nonsec_virt.S
@@ -47,6 +47,7 @@ _secure_monitor:
 #endif
 
mcr p15, 0, r1, c1, c1, 0   @ write SCR (with NS bit set)
+   isb
 
 #ifdef CONFIG_ARMV7_VIRT
mrceq   p15, 0, r0, c12, c0, 1  @ get MVBAR value
-- 
1.8.2.3


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

[U-Boot] [PATCH 8/9] sunxi: HYP/non-sec: add sun7i PSCI backend

[Marc Zyngier]

So far, only supporting the CPU_ON method.
Other functions can be added later.

Signed-off-by: Marc Zyngier 
---
 Makefile |   5 ++
 arch/arm/cpu/armv7/sunxi/Makefile|   3 +
 arch/arm/cpu/armv7/sunxi/config.mk   |   6 +-
 arch/arm/cpu/armv7/sunxi/psci.S  | 119 +++
 arch/arm/cpu/armv7/sunxi/u-boot-psci.lds |  63 
 include/configs/sun7i.h  |   6 ++
 6 files changed, 201 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/cpu/armv7/sunxi/psci.S
 create mode 100644 arch/arm/cpu/armv7/sunxi/u-boot-psci.lds

diff --git a/Makefile b/Makefile
index 629299c..640b94e 100644
--- a/Makefile
+++ b/Makefile
@@ -606,6 +606,11 @@ $(obj)tpl/u-boot-tpl.bin:  $(SUBDIR_TOOLS) depend
 $(obj)spl/sunxi-spl.bin:   $(SUBDIR_TOOLS) depend
$(MAKE) -C spl all
 
+# sunxi: PSCI binary blob
+$(obj)sunxi-psci.bin: depend
+   $(MAKE) -C psci all
+   $(OBJCOPY) $(OBJCFLAGS) -O binary psci/u-boot-psci $@
+
 updater:
$(MAKE) -C tools/updater all
 
diff --git a/arch/arm/cpu/armv7/sunxi/Makefile 
b/arch/arm/cpu/armv7/sunxi/Makefile
index 00efb65..dc4ca54 100644
--- a/arch/arm/cpu/armv7/sunxi/Makefile
+++ b/arch/arm/cpu/armv7/sunxi/Makefile
@@ -47,6 +47,9 @@ obj-y += cpu_info.o
 ifdef CONFIG_CMD_WATCHDOG
 obj-y  += cmd_watchdog.o
 endif
+ifdef CONFIG_PSCI_BUILD
+obj-y  += psci.o
+endif
 endif
 
 ifdef CONFIG_SPL_BUILD
diff --git a/arch/arm/cpu/armv7/sunxi/config.mk 
b/arch/arm/cpu/armv7/sunxi/config.mk
index 9ce48b4..83eb02b 100644
--- a/arch/arm/cpu/armv7/sunxi/config.mk
+++ b/arch/arm/cpu/armv7/sunxi/config.mk
@@ -2,7 +2,11 @@
 ifdef CONFIG_SPL
 ifndef CONFIG_SPL_BUILD
 ifndef CONFIG_SPL_FEL
-ALL-y = $(obj)u-boot-sunxi-with-spl.bin
+ALL-y = $(obj)u-boot-sunxi-with-spl.bin  $(obj)sunxi-psci.bin
 endif
 endif
 endif
+
+ifdef CONFIG_PSCI_BUILD
+SOC_PSCI = arch/arm/cpu/armv7/sunxi/psci.o
+endif
diff --git a/arch/arm/cpu/armv7/sunxi/psci.S b/arch/arm/cpu/armv7/sunxi/psci.S
new file mode 100644
index 000..f7db812
--- /dev/null
+++ b/arch/arm/cpu/armv7/sunxi/psci.S
@@ -0,0 +1,119 @@
+/*
+ * Copyright (C) 2013 - ARM Ltd
+ * Author: Marc Zyngier 
+ *
+ * Based on code by Carl van Schaik .
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 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, see .
+ */
+
+#include 
+#include 
+
+#defineTEN_MS  (10 * CONFIG_SYS_CLK_FREQ / 1000)
+
+   @ r1 = target CPU
+   @ r2 = target PC
+.globl psci_cpu_on
+psci_cpu_on:
+   adr r0, _target_pc
+   str r2, [r0]
+   dsb
+
+   movwr0, #(SUNXI_CPUCFG_BASE & 0x)
+   movtr0, #(SUNXI_CPUCFG_BASE >> 16)
+
+   @ CPU mask
+   and r1, r1, #3  @ only care about first cluster
+   mov r4, #1
+   lsl r4, r4, r1
+
+   adr r6, _sunxi_cpu_entry
+   str r6, [r0, #0x1a4] @ PRIVATE_REG (boot vector)
+
+   @ Assert reset on target CPU
+   mov r6, #0
+   lsl r5, r1, #6  @ 64 bytes per CPU
+   add r5, r5, #0x40   @ Offset from base
+   add r5, r5, r0  @ CPU control block
+   str r6, [r5]@ Reset CPU
+
+   @ l1 invalidate
+   ldr r6, [r0, #0x184]
+   bic r6, r6, r4
+   str r6, [r0, #0x184]
+
+   @ Lock CPU
+   ldr r6, [r0, #0x1e4]
+   bic r6, r6, r4
+   str r6, [r0, #0x1e4]
+
+   @ Release power clamp
+   movwr6, #0x1ff
+   movtr6, #0
+1: lsrsr6, r6, #1
+   str r6, [r0, #0x1b0]
+   bne 1b
+
+   @ Write CNTP_TVAL : 10ms @ 24MHz (24 cycles)
+   movwr1, #(TEN_MS & 0x)
+   movtr1, #(TEN_MS >> 16)
+   mcr p15, 0, r1, c14, c2, 0
+   isb
+   @ Enable physical timer, mask interrupt
+   mov r1, #3
+   mcr p15, 0, r1, c14, c2, 1
+   @ Poll physical timer until ISTATUS is on
+1: isb
+   mrc p15, 0, r1, c14, c2, 1
+   andsr1, r1, #4
+   bne 1b
+   @ Disable timer
+   mov r1, #0
+   mcr p15, 0, r1, c14, c2, 1
+   isb
+
+   @ Clear power gating
+   ldr r6, [r0, #0x1b4]
+   bic r6, r6, #1
+   str r6, [r0, #0x1b4]
+
+   @ Deassert reset on target CPU
+   mov r6, #3
+   str r6, [r5]
+
+   @ Unlock CPU
+   ldr r6, [r0, #0x1e4]
+   orr r6, r6, r4
+   str r6, [r0, #0x1e4]
+
+   mov r0, #0

[U-Boot] [PATCH 6/9] ARM: HYP/non-sec: make pen code sections depend on !ARMV7_PSCI

[Marc Zyngier]

PSCI doesn't need any pen-related code, as it interacts directly
with the power controller.

Make these sections depend on CONFIG_ARMV7_PSCI not being set.

Signed-off-by: Marc Zyngier 
---
 arch/arm/cpu/armv7/nonsec_virt.S | 2 ++
 arch/arm/cpu/armv7/virt-v7.c | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/arch/arm/cpu/armv7/nonsec_virt.S b/arch/arm/cpu/armv7/nonsec_virt.S
index bbacbce..c5a8347 100644
--- a/arch/arm/cpu/armv7/nonsec_virt.S
+++ b/arch/arm/cpu/armv7/nonsec_virt.S
@@ -68,6 +68,7 @@ _hyp_trap:
mov pc, lr  @ do no switch modes, but
@ return to caller
 
+#ifndef CONFIG_ARMV7_PSCI
 /*
  * Secondary CPUs start here and call the code for the core specific parts
  * of the non-secure and HYP mode transition. The GIC distributor specific
@@ -93,6 +94,7 @@ ENTRY(_smp_pen)
adr r0, _smp_pen@ do not use this address again
b   smp_waitloop@ wait for IPIs, board specific
 ENDPROC(_smp_pen)
+#endif
 
 /*
  * Switch a core to non-secure state.
diff --git a/arch/arm/cpu/armv7/virt-v7.c b/arch/arm/cpu/armv7/virt-v7.c
index 2cd604f..55f0bbf 100644
--- a/arch/arm/cpu/armv7/virt-v7.c
+++ b/arch/arm/cpu/armv7/virt-v7.c
@@ -147,8 +147,10 @@ int armv7_switch_nonsec(void)
for (i = 1; i <= itlinesnr; i++)
writel((unsigned)-1, gic_dist_addr + GICD_IGROUPRn + 4 * i);
 
+#ifndef CONFIG_ARMV7_PSCI
smp_set_core_boot_addr((unsigned long)_smp_pen, -1);
smp_kick_all_cpus();
+#endif
 
/* call the non-sec switching code on this CPU also */
_nonsec_init();
-- 
1.8.2.3


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

[U-Boot] [PATCH 7/9] ARM: HYP/non-sec: add the option for a second-stage monitor

[Marc Zyngier]

Allow the switch to a second stage secure monitor just before
switching to non-secure.

This allows a resident piece of firmware to be active once the
kernel has been entered (the u-boot monitor is dead anyway,
its pages being reused).

Signed-off-by: Marc Zyngier 
---
 arch/arm/cpu/armv7/nonsec_virt.S | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/arm/cpu/armv7/nonsec_virt.S b/arch/arm/cpu/armv7/nonsec_virt.S
index c5a8347..f07e3f7 100644
--- a/arch/arm/cpu/armv7/nonsec_virt.S
+++ b/arch/arm/cpu/armv7/nonsec_virt.S
@@ -35,6 +35,12 @@ _monitor_vectors:
  * We use only r0 and r1 here, due to constraints in the caller.
  */
 _secure_monitor:
+#ifdef CONFIG_ARMV7_PSCI_BASE
+   ldr r1, =CONFIG_ARMV7_PSCI_BASE @ Switch to the next monitor
+   mcr p15, 0, r1, c12, c0, 1
+   isb
+#endif
+   
mrc p15, 0, r1, c1, c1, 0   @ read SCR
bic r1, r1, #0x4e   @ clear IRQ, FIQ, EA, nET bits
orr r1, r1, #0x31   @ enable NS, AW, FW bits
@@ -50,7 +56,7 @@ _secure_monitor:
isb
 
 #ifdef CONFIG_ARMV7_VIRT
-   mrceq   p15, 0, r0, c12, c0, 1  @ get MVBAR value
+   adreq   r0, _monitor_vectors
mcreq   p15, 4, r0, c12, c0, 0  @ write HVBAR
 #endif
bne 1f
-- 
1.8.2.3


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

[U-Boot] [PATCH 5/9] ARM: HYP/non-sec: add generic ARMv7 PSCI code

[Marc Zyngier]

Implement core support for PSCI. As this is generic code, it doesn't
implement anything really useful (all the functions are returning
Not Implemented).

Signed-off-by: Marc Zyngier 
---
 arch/arm/cpu/armv7/Makefile |   4 ++
 arch/arm/cpu/armv7/psci.S   | 109 
 psci/Makefile   |  67 +++
 3 files changed, 180 insertions(+)
 create mode 100644 arch/arm/cpu/armv7/psci.S
 create mode 100644 psci/Makefile

diff --git a/arch/arm/cpu/armv7/Makefile b/arch/arm/cpu/armv7/Makefile
index 8fac06c..24b6cb9 100644
--- a/arch/arm/cpu/armv7/Makefile
+++ b/arch/arm/cpu/armv7/Makefile
@@ -23,6 +23,10 @@ obj-y+= nonsec_virt.o
 obj-y  += virt-v7.o
 endif
 
+ifneq ($(CONFIG_PSCI_BUILD),)
+obj-y  += psci.o
+endif
+
 obj-$(CONFIG_OMAP_COMMON) += omap-common/
 obj-$(CONFIG_TEGRA) += tegra-common/
 
diff --git a/arch/arm/cpu/armv7/psci.S b/arch/arm/cpu/armv7/psci.S
new file mode 100644
index 000..3cfb147
--- /dev/null
+++ b/arch/arm/cpu/armv7/psci.S
@@ -0,0 +1,109 @@
+/*
+ * Copyright (C) 2013 - ARM Ltd
+ * Author: Marc Zyngier 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 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, see .
+ */
+
+#include 
+#include 
+
+   .arch_extension sec
+
+   .globl  _start  @ Keep linker happy...
+_start:
+   .align  5
+_psci_vectors:
+   adr pc, .   @ reset
+   adr pc, .   @ undef
+   adr pc, _smc_psci   @ smc
+   adr pc, .   @ pabort
+   adr pc, .   @ dabort
+   adr pc, .   @ hyp
+   adr pc, .   @ irq
+   adr pc, .   @ fiq
+
+ENTRY(psci_cpu_suspend)
+ENTRY(psci_cpu_off)
+ENTRY(psci_cpu_on)
+ENTRY(psci_migrate)
+   mvn r0, #0  @ Return -1 (Not Implemented)
+   mov pc, lr
+ENDPROC(psci_migrate)
+ENDPROC(psci_cpu_on)
+ENDPROC(psci_cpu_off)
+ENDPROC(psci_cpu_suspend)
+.weak psci_cpu_suspend
+.weak psci_cpu_off
+.weak psci_cpu_on
+.weak psci_migrate
+
+_psci_table:
+   .word   0x95c1
+   .word   psci_cpu_suspend
+   .word   0x95c10001
+   .word   psci_cpu_off
+   .word   0x95c10002
+   .word   psci_cpu_on
+   .word   0x95c10003
+   .word   psci_migrate
+   .word   0
+   .word   0
+
+_secure_stacks:@ Enough to save 16 registers per CPU
+   .skip   16*4*CONFIG_ARMV7_PSCI_NR_CPUS
+_secure_stack_base:
+
+_smc_psci:
+   @ Switch to secure mode
+   mrc p15, 0, sp, c1, c1, 0
+   bic sp, sp, #1
+   mcr p15, 0, sp, c1, c1, 0
+
+   adr sp, _secure_stack_base
+   mcr p15, 0, r0, c13, c0, 4  @ use TPIDRPRW as a tmp reg
+   mcr p15, 0, r1, c13, c0, 3  @ use TPIDRURO as a tmp reg
+   mrc p15, 0, r0, c0, c0, 5   @ MPIDR
+   and r1, r0, #3  @ cpu number in cluster
+   lsr r0, r0, #8
+   and r0, r0, #3  @ cluster number
+   mul r1, r1, r0  @ absolute cpu nr
+   sbc sp, sp, r1, lsl #6  @ sp = sp_base - 64*cpunr
+
+   mrc p15, 0, r0, c13, c0, 4  @ restore r0
+   mrc p15, 0, r1, c13, c0, 3  @ restore r1
+
+   push{r4-r12,lr}
+
+   adr r4, _psci_table
+1: ldr r5, [r4]@ Load PSCI function ID
+   ldr r6, [r4, #4]@ Load target PC
+   cmp r5, #0  @ If reach the end, bail out
+   mvneq   r0, #0  @ Return -1 (Not Implemented)
+   beq 2f
+   cmp r0, r5  @ If not matching, try next entry
+   addne   r4, r4, #8
+   bne 1b
+   cmp r6, #0  @ Not implemented
+   mvneq   r0, #0
+   beq 2f
+
+   blx r6  @ Execute PSCI function
+
+2: pop {r4-r12, lr}
+
+   @ Back to non-secure
+   mrc p15, 0, sp, c1, c1, 0
+   orr sp, sp, #1
+   mcr p15, 0, sp, c1, c1, 0
+   movspc, lr  @ Return to the kernel
diff --git a/psci/Makefile b/psci/Makefile
new file mode 100644
index 000..7cc8b29
--- /dev/null
+++ b/psci/Makefile
@@ -0,0 +1,67 @@
+#
+# (C) Copyright 2000-2011
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# (C) Copyright 2011
+# Daniel Schwierzeck, daniel.schwierz...@googlemail.com.
+#
+# (C) Copyright 2011
+# Texas Instruments Incorporated - http://www.ti.com/
+# Aneesh V 
+#
+# (C) Copyright 2013 ARM Ltd
+# Marc Zyngier 
+#
+# SPDX-License-Identifier: GPL-

Re: [U-Boot] [PATCH V3 1/2] driver:usb:s3c_udc: add support for Exynos4x12

[Minkyu Kang]

On 21/11/13 17:40, Piotr Wilczek wrote:
> Dear Minkyu Kang,
> 
>> -Original Message-
>> From: Minkyu Kang [mailto:mk7.k...@samsung.com]
>> Sent: Thursday, November 21, 2013 9:10 AM
>> To: Piotr Wilczek
>> Cc: u-boot@lists.denx.de; Kyungmin Park
>> Subject: Re: [PATCH V3 1/2] driver:usb:s3c_udc: add support for
>> Exynos4x12
>>
>> Dear Piotr,
>>
>> On 08/11/13 00:00, Piotr Wilczek wrote:
>>> This patch add new defines for usb phy for Exynos4x12.
>>>
>>> Signed-off-by: Piotr Wilczek 
>>> Signed-off-by: Kyungmin Park 
>>> CC: Minkyu Kang 
>>> ---
>>>
>>> Chnages for v3:
>>>  - removed unnecessary empty line
>>>
>>> Changes for v2:
>>>  - no changes
>>>
>>>  drivers/usb/gadget/regs-otg.h|5 +
>>>  drivers/usb/gadget/s3c_udc_otg.c |9 +++--
>>>  2 files changed, 12 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/usb/gadget/regs-otg.h
>>> b/drivers/usb/gadget/regs-otg.h index 84bfcc5..ac5d112 100644
>>> --- a/drivers/usb/gadget/regs-otg.h
>>> +++ b/drivers/usb/gadget/regs-otg.h
>>> @@ -226,6 +226,11 @@ struct s3c_usbotg_reg {
>>>  #define CLK_SEL_12MHZ   (0x2 << 0)
>>>  #define CLK_SEL_48MHZ   (0x0 << 0)
>>>
>>> +#define EXYNOS4X12_ID_PULLUP0  (0x01 << 3)
>>> +#define EXYNOS4X12_COMMON_ON_N0(0x01 << 4)
>>> +#define EXYNOS4X12_CLK_SEL_12MHZ   (0x02 << 0)
>>> +#define EXYNOS4X12_CLK_SEL_24MHZ   (0x05 << 0)
>>> +
>>>  /* Device Configuration Register DCFG */
>>>  #define DEV_SPEED_HIGH_SPEED_20 (0x0 << 0)
>>>  #define DEV_SPEED_FULL_SPEED_20 (0x1 << 0)
>>> diff --git a/drivers/usb/gadget/s3c_udc_otg.c
>>> b/drivers/usb/gadget/s3c_udc_otg.c
>>> index 7e20209..ba17a04 100644
>>> --- a/drivers/usb/gadget/s3c_udc_otg.c
>>> +++ b/drivers/usb/gadget/s3c_udc_otg.c
>>> @@ -167,8 +167,13 @@ void otg_phy_init(struct s3c_udc *dev)
>>> writel((readl(&phy->phypwr) &~(OTG_DISABLE_0 |
>> ANALOG_PWRDOWN)
>>> &~FORCE_SUSPEND_0), &phy->phypwr);
>>>
>>> -   writel((readl(&phy->phyclk) &~(ID_PULLUP0 | COMMON_ON_N0)) |
>>> -  CLK_SEL_24MHZ, &phy->phyclk); /* PLL 24Mhz */
>>> +   if (s5p_cpu_id == 0x4412)
>>
>> proid_is_exynos4412()
> Ok but, proid_is_exynos4412() is not available for s5pc1**, ex the Goni
> board.

Right..
just keep going.
I'll fix it later.

> 
>>
>>> +   writel((readl(&phy->phyclk) & ~(EXYNOS4X12_ID_PULLUP0 |
>>> +   EXYNOS4X12_COMMON_ON_N0)) |
> EXYNOS4X12_CLK_SEL_24MHZ,
>>> +  &phy->phyclk); /* PLL 24Mhz */
>>> +   else
>>> +   writel((readl(&phy->phyclk) & ~(ID_PULLUP0 | COMMON_ON_N0))
>> |
>>> +  CLK_SEL_24MHZ, &phy->phyclk); /* PLL 24Mhz */
>>>
>>> writel((readl(&phy->rstcon) &~(LINK_SW_RST | PHYLNK_SW_RST))
>>>| PHY_SW_RST0, &phy->rstcon);
>>>
>>
>> Thanks,
>> Minkyu Kang.
> 
> Best regards
> Piotr Wilczek
> 
> 
> 
> 

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

Re: [U-Boot] [PATCH 1/5] mx6sabre{auto, sd}: Change FDT loading address to avoid overlaping

[Stefano Babic]

Hi Otavio, Jason, Fabio,

On 18/11/2013 20:39, Otavio Salvador wrote:

> 
> What is the final decision on this? I have the same change for many
> boards which are/will be supported by 3.10.
> 

You're right, we need a decision. As far as I read, there is no
explanation why this change is required. As Fabio points out, dtb is
loaded before the kernel and this should avoid an overlap. It will be
very nice if Jason could better explain the issue, because I admit I
have not understood why it happens.

Maybe is DTB loaded after the kernel on Freescale's U-Boot ?

This is clearly a work-around for a bug in Freescale's kernel 3.10, as
we have no problems with other kernels. I booted mainline kernel
3.11/3.12 on a i.MX6 without this issue.

However, I could still merge the patch if we can at least have the
following answers:

- why is there the overlap if the kernel is loaded after DTB (Fabio's
question) ?
- add the explanation to the commit message (so V2 is required, this is
also a Wolfgang's comment).
- of course, the patch should generate a problem with other kernels. It
should not be, but a couple of tested-by will be nice.

As the patchset fixes the same issue, I would prefer if the patchset is
squashed into a single patch because it fixes a single issue and we can
have only one "extended" commit message with the whole explanation.

Best regards,
Stefano Babic

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

Re: [U-Boot] (no subject)

[Bojan Buić]

I'm trying in board iMX233-OLinuXino-MICRO (
https://www.olimex.com/Products/OLinuXino/iMX233/iMX233-OLinuXino-MICRO/open-source-hardware
) setup hardware watchdog in the uboot.

I checkout uboot code and recompile it(I found steps here :
http://www.jann.cc/2013/02/07/u_boot_for_the_imx233_olinuxino.html).

I tried to call a function hw_watchdog_init from class: imx_watchdog.c (
http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/watchdog/imx_watchdog.c;h=d5993b4d26d6ba6018031cc5b31f7966d13a5ca8;hb=c2e5e802ecb7ab668ce9911b210ed68c804b349f
) in the code  .

In this method, I uncomment line # define CONFIG_WATCHDOG_TIMEOUT_MSECS
128000 and I expected that the system will be restarted after, 128 seconds, but
did not.
I am sure that this method(hw_watchdog_init) is called because before and
after i write debug messages to console

I tested like this:

1. recompile code with calling method hw_watchdog_init
3. upload this file to my SD card with dd command
3. start linux
4. waiting for 128 seconds and I was expecting that the system will
berestart but
did not.

What to do?

WDOG1_BASE_ADDR -> what is the value of this variable ?

Thank you



2013/11/21 Troy Kisky 

> On 11/20/2013 3:48 PM, Bojan Buić wrote:
>
>>
>> Hello,
>>
>>
>> I found Your commit in u-boot repository(git://git.denx.de/u-boot.git <
>> http://git.denx.de/u-boot.git>).
>>
>>
>> Can You help me , how can enable hardware watchdog in U-Boot ?
>>
>> I found imx_watchdog.c class but when I call hw_watcdog_init nothing
>> happened
>>
>> Can You help me ?
>>
>> Thank youBojan Buić
>>
>>
>>  What did you expect to happen? Tell me how you are testing it? Also,
> please CC the list.
> u-boot@lists.denx.de
>
> Troy
>
>


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

Re: [U-Boot] [PATCH V3 2/2] trats2: enable ums support on Trats2

[Piotr Wilczek]

Dear Minkyu Kang,

> -Original Message-
> From: Minkyu Kang [mailto:mk7.k...@samsung.com]
> Sent: Thursday, November 21, 2013 9:24 AM
> To: Piotr Wilczek
> Cc: u-boot@lists.denx.de; Kyungmin Park
> Subject: Re: [PATCH V3 2/2] trats2: enable ums support on Trats2
> 
> Dear Piotr Wilczek,
> 
> On 08/11/13 00:00, Piotr Wilczek wrote:
> > This patch adds support for USB and enables 'ums' command on Trats2
> board.
> >
> > Signed-off-by: Piotr Wilczek 
> > Signed-off-by: Kyungmin Park 
> > CC: Minkyu Kang 
> >
> > Acked-by: Jaehoon Chung 
> > ---
> > This patch depends on the lated u-boot-usb/master.
> >
> > Changes for v3:
> >  - no changes
> >
> > Changes for v2:
> >  - rebased on current USB tree
> >  - removed unnecessary pmic probing
> >
> >  board/samsung/trats2/trats2.c |   92
> +
> >  include/configs/trats2.h  |   18 
> >  2 files changed, 110 insertions(+)
> >
> > diff --git a/board/samsung/trats2/trats2.c
> > b/board/samsung/trats2/trats2.c index d44d825..41a7310 100644
> > --- a/board/samsung/trats2/trats2.c
> > +++ b/board/samsung/trats2/trats2.c
> > @@ -25,6 +25,9 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> > +#include 
> > +#include 
> >
> >  DECLARE_GLOBAL_DATA_PTR;
> >
> > @@ -308,6 +311,95 @@ int board_mmc_init(bd_t *bis)
> > return err0 & err2;
> >  }
> >
> > +#ifdef CONFIG_USB_GADGET
> > +static int s5pc210_phy_control(int on) {
> > +   int ret = 0;
> > +   unsigned int val;
> > +   struct pmic *p, *p_pmic, *p_muic;
> > +
> > +   p_pmic = pmic_get("MAX77686_PMIC");
> > +   if (!p_pmic)
> > +   return -ENODEV;
> > +
> > +   if (pmic_probe(p_pmic))
> > +   return -1;
> > +
> > +   p_muic = pmic_get("MAX77693_MUIC");
> > +   if (!p_muic)
> > +   return -ENODEV;
> > +
> > +   if (pmic_probe(p_muic))
> > +   return -1;
> > +
> > +   if (on) {
> > +   ret = max77686_set_ldo_mode(p_pmic, 12, OPMODE_ON);
> > +   if (ret)
> > +   return -1;
> > +
> > +   p = pmic_get("MAX77693_PMIC");
> > +   if (!p)
> > +   return -ENODEV;
> > +
> > +   if (pmic_probe(p))
> > +   return -1;
> > +
> > +   /* SAFEOUT */
> > +   ret = pmic_reg_read(p, MAX77693_SAFEOUT, &val);
> > +   if (ret)
> > +   return -1;
> > +
> > +   val |= MAX77693_ENSAFEOUT1;
> > +   ret = pmic_reg_write(p, MAX77693_SAFEOUT, val);
> > +   if (ret)
> > +   return -1;
> > +
> > +   /* PATH: USB */
> > +   ret = pmic_reg_write(p_muic, MAX77693_MUIC_CONTROL1,
> > +   MAX77693_MUIC_CTRL1_DN1DP2);
> > +
> > +   } else {
> > +   ret = max77686_set_ldo_mode(p_pmic, 12, OPMODE_LPM);
> > +   if (ret)
> > +   return -1;
> > +
> > +   /* PATH: UART */
> > +   ret = pmic_reg_write(p_muic, MAX77693_MUIC_CONTROL1,
> > +   MAX77693_MUIC_CTRL1_UT1UR2);
> > +   }
> > +
> > +   if (ret)
> > +   return -1;
> > +
> 
> please remove blank line.
Ok

> 
> > +
> > +   return 0;
> > +}
> > +
> > +struct s3c_plat_otg_data s5pc210_otg_data = {
> > +   .phy_control= s5pc210_phy_control,
> > +   .regs_phy   = EXYNOS4X12_USBPHY_BASE,
> > +   .regs_otg   = EXYNOS4X12_USBOTG_BASE,
> > +   .usb_phy_ctrl   = EXYNOS4X12_USBPHY_CONTROL,
> > +   .usb_flags  = PHY0_SLEEP,
> > +};
> > +
> > +int board_usb_init(int index, enum usb_init_type init) {
> > +   debug("USB_udc_probe\n");
> > +   return s3c_udc_probe(&s5pc210_otg_data); }
> > +
> > +#ifdef CONFIG_USB_CABLE_CHECK
> > +int usb_cable_connected(void)
> > +{
> > +   struct pmic *muic = pmic_get("MAX77693_MUIC");
> > +   int cable_connected = muic->chrg->chrg_type(muic);
> 
> Please check that muic is available.
Ok

> 
> > +
> > +   return !!cable_connected;
> 
> I think, cable_connected is unnecessary.
> 
> return !!muic->chrg->chrg_type(muic);
> 
Ok

> > +}
> > +#endif
> > +#endif
> > +
> >  static int pmic_init_max77686(void)
> >  {
> > struct pmic *p = pmic_get("MAX77686_PMIC"); diff --git
> > a/include/configs/trats2.h b/include/configs/trats2.h index
> > 0e93836..66b1c95 100644
> > --- a/include/configs/trats2.h
> > +++ b/include/configs/trats2.h
> > @@ -113,6 +113,16 @@
> >  #define CONFIG_CMD_EXT4
> >  #define CONFIG_CMD_EXT4_WRITE
> >
> > +/* USB Composite download gadget - g_dnl */ #define
> > +CONFIG_USBDOWNLOAD_GADGET #define CONFIG_DFU_FUNCTION #define
> > +CONFIG_DFU_MMC
> > +
> > +/* USB Samsung's IDs */
> > +#define CONFIG_G_DNL_VENDOR_NUM 0x04E8 #define
> > +CONFIG_G_DNL_PRODUCT_NUM 0x6601 #define CONFIG_G_DNL_MANUFACTURER
> > +"Samsung"
> > +
> >  /* To use the TFTPBOOT over USB, Please enable the CONFIG_CMD_NET */
> > #undef CONFIG_CMD_NET
> >
> > @@ -293,6 +303,11 @@
> >  #define CONFIG_POWER_MUIC_MAX77693
> >  #define CONFIG_POWER_FG_MAX77693
> >  #define CONFIG_POWER_BATTERY_TRATS2
> > +#define CONFIG_USB_G

Re: [U-Boot] [PATCH V3 1/2] driver:usb:s3c_udc: add support for Exynos4x12

[Piotr Wilczek]

Dear Minkyu Kang,

> -Original Message-
> From: Minkyu Kang [mailto:mk7.k...@samsung.com]
> Sent: Thursday, November 21, 2013 9:10 AM
> To: Piotr Wilczek
> Cc: u-boot@lists.denx.de; Kyungmin Park
> Subject: Re: [PATCH V3 1/2] driver:usb:s3c_udc: add support for
> Exynos4x12
> 
> Dear Piotr,
> 
> On 08/11/13 00:00, Piotr Wilczek wrote:
> > This patch add new defines for usb phy for Exynos4x12.
> >
> > Signed-off-by: Piotr Wilczek 
> > Signed-off-by: Kyungmin Park 
> > CC: Minkyu Kang 
> > ---
> >
> > Chnages for v3:
> >  - removed unnecessary empty line
> >
> > Changes for v2:
> >  - no changes
> >
> >  drivers/usb/gadget/regs-otg.h|5 +
> >  drivers/usb/gadget/s3c_udc_otg.c |9 +++--
> >  2 files changed, 12 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/usb/gadget/regs-otg.h
> > b/drivers/usb/gadget/regs-otg.h index 84bfcc5..ac5d112 100644
> > --- a/drivers/usb/gadget/regs-otg.h
> > +++ b/drivers/usb/gadget/regs-otg.h
> > @@ -226,6 +226,11 @@ struct s3c_usbotg_reg {
> >  #define CLK_SEL_12MHZ   (0x2 << 0)
> >  #define CLK_SEL_48MHZ   (0x0 << 0)
> >
> > +#define EXYNOS4X12_ID_PULLUP0  (0x01 << 3)
> > +#define EXYNOS4X12_COMMON_ON_N0(0x01 << 4)
> > +#define EXYNOS4X12_CLK_SEL_12MHZ   (0x02 << 0)
> > +#define EXYNOS4X12_CLK_SEL_24MHZ   (0x05 << 0)
> > +
> >  /* Device Configuration Register DCFG */
> >  #define DEV_SPEED_HIGH_SPEED_20 (0x0 << 0)
> >  #define DEV_SPEED_FULL_SPEED_20 (0x1 << 0)
> > diff --git a/drivers/usb/gadget/s3c_udc_otg.c
> > b/drivers/usb/gadget/s3c_udc_otg.c
> > index 7e20209..ba17a04 100644
> > --- a/drivers/usb/gadget/s3c_udc_otg.c
> > +++ b/drivers/usb/gadget/s3c_udc_otg.c
> > @@ -167,8 +167,13 @@ void otg_phy_init(struct s3c_udc *dev)
> > writel((readl(&phy->phypwr) &~(OTG_DISABLE_0 |
> ANALOG_PWRDOWN)
> > &~FORCE_SUSPEND_0), &phy->phypwr);
> >
> > -   writel((readl(&phy->phyclk) &~(ID_PULLUP0 | COMMON_ON_N0)) |
> > -  CLK_SEL_24MHZ, &phy->phyclk); /* PLL 24Mhz */
> > +   if (s5p_cpu_id == 0x4412)
> 
> proid_is_exynos4412()
Ok but, proid_is_exynos4412() is not available for s5pc1**, ex the Goni
board.

> 
> > +   writel((readl(&phy->phyclk) & ~(EXYNOS4X12_ID_PULLUP0 |
> > +   EXYNOS4X12_COMMON_ON_N0)) |
EXYNOS4X12_CLK_SEL_24MHZ,
> > +  &phy->phyclk); /* PLL 24Mhz */
> > +   else
> > +   writel((readl(&phy->phyclk) & ~(ID_PULLUP0 | COMMON_ON_N0))
> |
> > +  CLK_SEL_24MHZ, &phy->phyclk); /* PLL 24Mhz */
> >
> > writel((readl(&phy->rstcon) &~(LINK_SW_RST | PHYLNK_SW_RST))
> >| PHY_SW_RST0, &phy->rstcon);
> >
> 
> Thanks,
> Minkyu Kang.

Best regards
Piotr Wilczek



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

Re: [U-Boot] (no subject)

[Stefano Babic]

Hi Bojan,

On 21/11/2013 09:09, Bojan Buić wrote:
> I'm trying in board iMX233-OLinuXino-MICRO
> (https://www.olimex.com/Products/OLinuXino/iMX233/iMX233-OLinuXino-MICRO/open-source-hardware)
> setup hardware watchdogin the uboot.
> 
> I checkout uboot code and recompile it(I found steps here :
> http://www.jann.cc/2013/02/07/u_boot_for_the_imx233_olinuxino.html).
> 
> I tried to call a function hw_watchdog_init from class: imx_watchdog.c
> (http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/watchdog/imx_watchdog.c;h=d5993b4d26d6ba6018031cc5b31f7966d13a5ca8;hb=c2e5e802ecb7ab668ce9911b210ed68c804b349f)
> in the code  .
> 
> In this method, I uncomment line # define CONFIG_WATCHDOG_TIMEOUT_MSECS
> 128000 and I expected that the system will be restarted after, 128
> seconds, but did not.
> I am sure that this method(hw_watchdog_init) is called because before
> and after i write debug messages to console

Wait...

Checking the Makefile in the drivers/watchdog directory:

ifneq (,$(filter $(SOC), mx31 mx35 mx5 mx6 vf610))
obj-y += imx_watchdog.o
endif

That is: watchdog is supported for other i.MX families. It is not
surprising if it is not working, I am surprised that hw_watchdog_init is
called, because imx_watchdog should not be compiled.

I have not checked inside MX23 manual, but if it is as in MX28 you have
to enable the watchdog inside the RTC. It works in a different way as in
other imx, and the current driver is not suitable for MX23. You have to
add support for it.

Best regards,
Stefano Babic

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

Re: [U-Boot] [PATCH V3 2/2] trats2: enable ums support on Trats2

[Minkyu Kang]

Dear Piotr Wilczek,

On 08/11/13 00:00, Piotr Wilczek wrote:
> This patch adds support for USB and enables 'ums' command on Trats2 board.
> 
> Signed-off-by: Piotr Wilczek 
> Signed-off-by: Kyungmin Park 
> CC: Minkyu Kang 
> 
> Acked-by: Jaehoon Chung 
> ---
> This patch depends on the lated u-boot-usb/master.
> 
> Changes for v3:
>  - no changes
> 
> Changes for v2:
>  - rebased on current USB tree
>  - removed unnecessary pmic probing
> 
>  board/samsung/trats2/trats2.c |   92 
> +
>  include/configs/trats2.h  |   18 
>  2 files changed, 110 insertions(+)
> 
> diff --git a/board/samsung/trats2/trats2.c b/board/samsung/trats2/trats2.c
> index d44d825..41a7310 100644
> --- a/board/samsung/trats2/trats2.c
> +++ b/board/samsung/trats2/trats2.c
> @@ -25,6 +25,9 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
> +#include 
>  
>  DECLARE_GLOBAL_DATA_PTR;
>  
> @@ -308,6 +311,95 @@ int board_mmc_init(bd_t *bis)
>   return err0 & err2;
>  }
>  
> +#ifdef CONFIG_USB_GADGET
> +static int s5pc210_phy_control(int on)
> +{
> + int ret = 0;
> + unsigned int val;
> + struct pmic *p, *p_pmic, *p_muic;
> +
> + p_pmic = pmic_get("MAX77686_PMIC");
> + if (!p_pmic)
> + return -ENODEV;
> +
> + if (pmic_probe(p_pmic))
> + return -1;
> +
> + p_muic = pmic_get("MAX77693_MUIC");
> + if (!p_muic)
> + return -ENODEV;
> +
> + if (pmic_probe(p_muic))
> + return -1;
> +
> + if (on) {
> + ret = max77686_set_ldo_mode(p_pmic, 12, OPMODE_ON);
> + if (ret)
> + return -1;
> +
> + p = pmic_get("MAX77693_PMIC");
> + if (!p)
> + return -ENODEV;
> +
> + if (pmic_probe(p))
> + return -1;
> +
> + /* SAFEOUT */
> + ret = pmic_reg_read(p, MAX77693_SAFEOUT, &val);
> + if (ret)
> + return -1;
> +
> + val |= MAX77693_ENSAFEOUT1;
> + ret = pmic_reg_write(p, MAX77693_SAFEOUT, val);
> + if (ret)
> + return -1;
> +
> + /* PATH: USB */
> + ret = pmic_reg_write(p_muic, MAX77693_MUIC_CONTROL1,
> + MAX77693_MUIC_CTRL1_DN1DP2);
> +
> + } else {
> + ret = max77686_set_ldo_mode(p_pmic, 12, OPMODE_LPM);
> + if (ret)
> + return -1;
> +
> + /* PATH: UART */
> + ret = pmic_reg_write(p_muic, MAX77693_MUIC_CONTROL1,
> + MAX77693_MUIC_CTRL1_UT1UR2);
> + }
> +
> + if (ret)
> + return -1;
> +

please remove blank line.

> +
> + return 0;
> +}
> +
> +struct s3c_plat_otg_data s5pc210_otg_data = {
> + .phy_control= s5pc210_phy_control,
> + .regs_phy   = EXYNOS4X12_USBPHY_BASE,
> + .regs_otg   = EXYNOS4X12_USBOTG_BASE,
> + .usb_phy_ctrl   = EXYNOS4X12_USBPHY_CONTROL,
> + .usb_flags  = PHY0_SLEEP,
> +};
> +
> +int board_usb_init(int index, enum usb_init_type init)
> +{
> + debug("USB_udc_probe\n");
> + return s3c_udc_probe(&s5pc210_otg_data);
> +}
> +
> +#ifdef CONFIG_USB_CABLE_CHECK
> +int usb_cable_connected(void)
> +{
> + struct pmic *muic = pmic_get("MAX77693_MUIC");
> + int cable_connected = muic->chrg->chrg_type(muic);

Please check that muic is available.

> +
> + return !!cable_connected;

I think, cable_connected is unnecessary.

return !!muic->chrg->chrg_type(muic);

> +}
> +#endif
> +#endif
> +
>  static int pmic_init_max77686(void)
>  {
>   struct pmic *p = pmic_get("MAX77686_PMIC");
> diff --git a/include/configs/trats2.h b/include/configs/trats2.h
> index 0e93836..66b1c95 100644
> --- a/include/configs/trats2.h
> +++ b/include/configs/trats2.h
> @@ -113,6 +113,16 @@
>  #define CONFIG_CMD_EXT4
>  #define CONFIG_CMD_EXT4_WRITE
>  
> +/* USB Composite download gadget - g_dnl */
> +#define CONFIG_USBDOWNLOAD_GADGET
> +#define CONFIG_DFU_FUNCTION
> +#define CONFIG_DFU_MMC
> +
> +/* USB Samsung's IDs */
> +#define CONFIG_G_DNL_VENDOR_NUM 0x04E8
> +#define CONFIG_G_DNL_PRODUCT_NUM 0x6601
> +#define CONFIG_G_DNL_MANUFACTURER "Samsung"
> +
>  /* To use the TFTPBOOT over USB, Please enable the CONFIG_CMD_NET */
>  #undef CONFIG_CMD_NET
>  
> @@ -293,6 +303,11 @@
>  #define CONFIG_POWER_MUIC_MAX77693
>  #define CONFIG_POWER_FG_MAX77693
>  #define CONFIG_POWER_BATTERY_TRATS2
> +#define CONFIG_USB_GADGET
> +#define CONFIG_USB_GADGET_S3C_UDC_OTG
> +#define CONFIG_USB_GADGET_DUALSPEED
> +#define CONFIG_USB_GADGET_VBUS_DRAW  2
> +#define CONFIG_USB_CABLE_CHECK
>  
>  /* LCD */
>  #define CONFIG_EXYNOS_FB
> @@ -305,6 +320,9 @@
>  #define CONFIG_VIDEO_BMP_GZIP
>  #define CONFIG_SYS_VIDEO_LOGO_MAX_SIZE ((500 * 250 * 4) + (1 << 12))
>  
> +#define CONFIG_CMD_USB_MASS_STORAGE
> +#define CONFIG_USB_GADGET_MASS_STORAGE
> +
>  /* Pass open firmware flat tree */
>  #define CONFIG_O

Re: [U-Boot] Many Blackfin boards are broken

[Masahiro Yamada]

Hello Sonic

Thanks for your patches.

And a discussion is going on to fix another error:
http://u-boot.10912.n7.nabble.com/PATCH-cmd-test-fix-a-compile-error-on-Blackfin-td167941.html

But it looks like there are still various errors and warnings
on Blackfin boards.


I pick up some of them I noticed:

(1)
For many boards
arch/blackfin/include/asm/serial1.h:238: warning: implicit declaration
of function ‘BUG’

(2)
For many boards

initcode.c: In function ‘serial_init’:
initcode.c:150: warning: unused variable ‘uart_base’
initcode.c: In function ‘initcode’:
initcode.c:743: warning: ‘sdivB’ is used uninitialized in this function
initcode.c:1004: note: ‘sdivB’ was declared here
initcode.c:743: warning: ‘divB’ is used uninitialized in this function
initcode.c:1004: note: ‘divB’ was declared here
initcode.c:744: warning: ‘vcoB’ is used uninitialized in this function
initcode.c:1004: note: ‘vcoB’ was declared here


(3)
For bf609-ezkit board

bf609-ezkit.c:26: error: ‘P_A3’ undeclared (first use in this function)
bf609-ezkit.c:26: error: (Each undeclared identifier is reported only once
bf609-ezkit.c:26: error: for each function it appears in.)
bf609-ezkit.c:28: error: ‘P_NORCK’ undeclared (first use in this function)
bf609-ezkit.c:41: error: ‘P_RMII0’ undeclared (first use in this function)
bf609-ezkit.c:41: error: invalid initializer
bf609-ezkit.c:43: error: ‘EMAC0_MACCFG’ undeclared (first use in this function)
bf609-ezkit.c:46: error: ‘P_RMII1’ undeclared (first use in this function)
bf609-ezkit.c:46: error: invalid initializer
bf609-ezkit.c:48: error: ‘EMAC1_MACCFG’ undeclared (first use in this function)


(4)
For some boards such as tcm-bf537, link error

bfin-elf-ld: u-boot section `.bss' will not fit in region `ram'
bfin-elf-ld: region `ram' overflowed by 8084 bytes



So, what I'd like you to do is to compile all Blackfin boards
and fix errors and warnings you find.
(Or send emals to board maintainers for the errors
you are not responsible for)



Best Regards
Masahiro Yamada

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

Re: [U-Boot] [PATCH] spi: Add support SH Quad SPI driver

[Nobuhiro Iwamatsu]

Hi, Jagannadha.

Do you have any comment about this patch?
If no problem, could you pickup your repository?

Best regards,
  Nobuhiro

2013/10/9 Nobuhiro Iwamatsu :
> This patch adds a driver for Renesas SoC's Quad SPI bus.
> This supports with 8 bits per transfer to use with SPI flash.
>
> Signed-off-by: Kouei Abe 
> Signed-off-by: Nobuhiro Iwamatsu 
> Signed-off-by: Jagannadha Sutradharudu Teki 
> ---
> Changes for v5:
>   - Add print abort when call ctrlc().
>   - Move source code in spi_xfer() which should be processed by
> spi_cs_activate().
>   - Move source code in spi_xfer() which should be processed by
> spi_cs_deactivate().
>   - Remove sh_qspi_xfer, move to spi_xfer().
> Changes for v4:
>   - Added tabs
>   - Added comments
>   - Added sh_qspi_init()
> Changes for v3:
>   - Change Queued to Quad.
>   - Remove path of file from file header.
>   - Use read* and write* directly instead of sh_qspi_write* sh_qspi_read*.
>   - Change driver format.
> Changes for v2:
>   - "SH QSPI" to "SH QSPI (Queued SPI)".
>   - Remove magic number.
>
>  drivers/spi/Makefile  |   1 +
>  drivers/spi/sh_qspi.c | 244 
> ++
>  2 files changed, 245 insertions(+)
>  create mode 100644 drivers/spi/sh_qspi.c
>
> diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
> index 91d24ce..c44f851 100644
> --- a/drivers/spi/Makefile
> +++ b/drivers/spi/Makefile
> @@ -33,6 +33,7 @@ COBJS-$(CONFIG_OC_TINY_SPI) += oc_tiny_spi.o
>  COBJS-$(CONFIG_OMAP3_SPI) += omap3_spi.o
>  COBJS-$(CONFIG_SOFT_SPI) += soft_spi.o
>  COBJS-$(CONFIG_SH_SPI) += sh_spi.o
> +COBJS-$(CONFIG_SH_QSPI) += sh_qspi.o
>  COBJS-$(CONFIG_FSL_ESPI) += fsl_espi.o
>  COBJS-$(CONFIG_FDT_SPI) += fdt_spi.o
>  COBJS-$(CONFIG_TEGRA20_SFLASH) += tegra20_sflash.o
> diff --git a/drivers/spi/sh_qspi.c b/drivers/spi/sh_qspi.c
> new file mode 100644
> index 000..8f53552
> --- /dev/null
> +++ b/drivers/spi/sh_qspi.c
> @@ -0,0 +1,244 @@
> +/*
> + * SH QSPI (Quad SPI) driver
> + *
> + * Copyright (C) 2013 Renesas Electronics Corporation
> + * Copyright (C) 2013 Nobuhiro Iwamatsu 
> + *
> + * SPDX-License-Identifier:GPL-2.0
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* SH QSPI register bit masks _ */
> +#define SPCR_MSTR  0x08
> +#define SPCR_SPE   0x40
> +#define SPSR_SPRFF 0x80
> +#define SPSR_SPTEF 0x20
> +#define SPPCR_IO3FV0x04
> +#define SPPCR_IO2FV0x02
> +#define SPPCR_IO1FV0x01
> +#define SPBDCR_RXBC0   (1 << 0)
> +#define SPCMD_SCKDEN   (1 << 15)
> +#define SPCMD_SLNDEN   (1 << 14)
> +#define SPCMD_SPNDEN   (1 << 13)
> +#define SPCMD_SSLKP(1 << 7)
> +#define SPCMD_BRDV0(1 << 2)
> +#define SPCMD_INIT1SPCMD_SCKDEN | SPCMD_SLNDEN | \
> +   SPCMD_SPNDEN | SPCMD_SSLKP | \
> +   SPCMD_BRDV0
> +#define SPCMD_INIT2SPCMD_SPNDEN | SPCMD_SSLKP | \
> +   SPCMD_BRDV0
> +#define SPBFCR_TXRST   (1 << 7)
> +#define SPBFCR_RXRST   (1 << 6)
> +
> +/* SH QSPI register set */
> +struct sh_qspi_regs {
> +   unsigned char spcr;
> +   unsigned char sslp;
> +   unsigned char sppcr;
> +   unsigned char spsr;
> +   unsigned long spdr;
> +   unsigned char spscr;
> +   unsigned char spssr;
> +   unsigned char spbr;
> +   unsigned char spdcr;
> +   unsigned char spckd;
> +   unsigned char sslnd;
> +   unsigned char spnd;
> +   unsigned char dummy0;
> +   unsigned short spcmd0;
> +   unsigned short spcmd1;
> +   unsigned short spcmd2;
> +   unsigned short spcmd3;
> +   unsigned char spbfcr;
> +   unsigned char dummy1;
> +   unsigned short spbdcr;
> +   unsigned long spbmul0;
> +   unsigned long spbmul1;
> +   unsigned long spbmul2;
> +   unsigned long spbmul3;
> +};
> +
> +struct sh_qspi_slave {
> +   struct spi_slaveslave;
> +   struct sh_qspi_regs *regs;
> +};
> +
> +static inline struct sh_qspi_slave *to_sh_qspi(struct spi_slave *slave)
> +{
> +   return container_of(slave, struct sh_qspi_slave, slave);
> +}
> +
> +static void sh_qspi_init(struct sh_qspi_slave *ss)
> +{
> +   /* QSPI initialize */
> +   writeb(SPCR_MSTR, &ss->regs->spcr);
> +   writeb(0x00, &ss->regs->sslp);
> +   writeb(SPPCR_IO3FV|SPPCR_IO2FV, &ss->regs->sppcr);
> +
> +   /* Set bit rate. See 58.3.8 Quad Serial Peripheral Interface */
> +   writeb(0x01, &ss->regs->spbr);
> +
> +   writeb(0x00, &ss->regs->spdcr);
> +   writeb(0x00, &ss->regs->spckd);
> +   writeb(0x00, &ss->regs->sslnd);
> +   writeb(0x00, &ss->regs->spnd);
> +   writew(SPCMD_INIT1, &ss->regs->spcmd0);
> +   writew(SPCMD_INIT2, &ss->regs->spcmd0);
> +   writeb(SPBFCR_TXRST|SPBFCR_RXRST, &ss->regs->spbfcr);
> +   writeb(0x00, &ss->regs->spbfcr);
> +   writeb(0x00, &ss->regs->spscr);
> +   writeb(SPCR_SPE|SPCR_MSTR, &ss->regs->spcr);
> +}
> +
> +int spi_cs_is_valid(unsigned int bus, unsigned in

Re: [U-Boot] [PATCH V3 1/2] driver:usb:s3c_udc: add support for Exynos4x12

[Minkyu Kang]

Dear Piotr,

On 08/11/13 00:00, Piotr Wilczek wrote:
> This patch add new defines for usb phy for Exynos4x12.
> 
> Signed-off-by: Piotr Wilczek 
> Signed-off-by: Kyungmin Park 
> CC: Minkyu Kang 
> ---
> 
> Chnages for v3:
>  - removed unnecessary empty line
> 
> Changes for v2:
>  - no changes
> 
>  drivers/usb/gadget/regs-otg.h|5 +
>  drivers/usb/gadget/s3c_udc_otg.c |9 +++--
>  2 files changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/usb/gadget/regs-otg.h b/drivers/usb/gadget/regs-otg.h
> index 84bfcc5..ac5d112 100644
> --- a/drivers/usb/gadget/regs-otg.h
> +++ b/drivers/usb/gadget/regs-otg.h
> @@ -226,6 +226,11 @@ struct s3c_usbotg_reg {
>  #define CLK_SEL_12MHZ   (0x2 << 0)
>  #define CLK_SEL_48MHZ   (0x0 << 0)
>  
> +#define EXYNOS4X12_ID_PULLUP0(0x01 << 3)
> +#define EXYNOS4X12_COMMON_ON_N0  (0x01 << 4)
> +#define EXYNOS4X12_CLK_SEL_12MHZ (0x02 << 0)
> +#define EXYNOS4X12_CLK_SEL_24MHZ (0x05 << 0)
> +
>  /* Device Configuration Register DCFG */
>  #define DEV_SPEED_HIGH_SPEED_20 (0x0 << 0)
>  #define DEV_SPEED_FULL_SPEED_20 (0x1 << 0)
> diff --git a/drivers/usb/gadget/s3c_udc_otg.c 
> b/drivers/usb/gadget/s3c_udc_otg.c
> index 7e20209..ba17a04 100644
> --- a/drivers/usb/gadget/s3c_udc_otg.c
> +++ b/drivers/usb/gadget/s3c_udc_otg.c
> @@ -167,8 +167,13 @@ void otg_phy_init(struct s3c_udc *dev)
>   writel((readl(&phy->phypwr) &~(OTG_DISABLE_0 | ANALOG_PWRDOWN)
>   &~FORCE_SUSPEND_0), &phy->phypwr);
>  
> - writel((readl(&phy->phyclk) &~(ID_PULLUP0 | COMMON_ON_N0)) |
> -CLK_SEL_24MHZ, &phy->phyclk); /* PLL 24Mhz */
> + if (s5p_cpu_id == 0x4412)

proid_is_exynos4412()

> + writel((readl(&phy->phyclk) & ~(EXYNOS4X12_ID_PULLUP0 |
> + EXYNOS4X12_COMMON_ON_N0)) | EXYNOS4X12_CLK_SEL_24MHZ,
> +&phy->phyclk); /* PLL 24Mhz */
> + else
> + writel((readl(&phy->phyclk) & ~(ID_PULLUP0 | COMMON_ON_N0)) |
> +CLK_SEL_24MHZ, &phy->phyclk); /* PLL 24Mhz */
>  
>   writel((readl(&phy->rstcon) &~(LINK_SW_RST | PHYLNK_SW_RST))
>  | PHY_SW_RST0, &phy->rstcon);
> 

Thanks,
Minkyu Kang.

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

[U-Boot] [PATCH 1/3 v5] arm: rmobile: Move lowlevel_init.o to taget of each CPU

[Nobuhiro Iwamatsu]

From: Nobuhiro Iwamatsu 

Signed-off-by: Nobuhiro Iwamatsu 
---
 v5: add this patch.

 arch/arm/cpu/armv7/rmobile/Makefile | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/arch/arm/cpu/armv7/rmobile/Makefile 
b/arch/arm/cpu/armv7/rmobile/Makefile
index 5e296c4..d6ae11e 100644
--- a/arch/arm/cpu/armv7/rmobile/Makefile
+++ b/arch/arm/cpu/armv7/rmobile/Makefile
@@ -5,14 +5,11 @@
 # SPDX-License-Identifier: GPL-2.0+
 #
 
-obj-y = lowlevel_init.o
-obj-y += cpu_info.o
+obj-y = cpu_info.o
 obj-y += emac.o
 
 obj-$(CONFIG_DISPLAY_BOARDINFO) += board.o
 obj-$(CONFIG_GLOBAL_TIMER) += timer.o
-obj-$(CONFIG_R8A7740) += cpu_info-r8a7740.o
-obj-$(CONFIG_R8A7740) += pfc-r8a7740.o
-obj-$(CONFIG_SH73A0) += cpu_info-sh73a0.o
-obj-$(CONFIG_SH73A0) += pfc-sh73a0.o
+obj-$(CONFIG_R8A7740) += lowlevel_init.o cpu_info-r8a7740.o pfc-r8a7740.o
+obj-$(CONFIG_SH73A0) += lowlevel_init.o cpu_info-sh73a0.o pfc-sh73a0.o
 obj-$(CONFIG_TMU_TIMER) += ../../../../sh/lib/time.o
-- 
1.8.4.3

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