[U-Boot] [PATCH 1/5] Licenses: introduce SPDX Unique Lincense Identifiers

[Wolfgang Denk]

Like many other projects, U-Boot has a tradition of including big
blocks of License headers in all files.  This not only blows up the
source code with mostly redundant information, but also makes it very
difficult to generate License Clearing Reports.  An additional problem
is that even the same lincenses are referred to by a number of
slightly varying text blocks (full, abbreviated, different
indentation, line wrapping and/or white space, with obsolete address
information, ...) which makes automatic processing a nightmare.

To make this easier, such license headers in the source files will be
replaced with a single line reference to Unique Lincense Identifiers
as defined by the Linux Foundation's SPDX project [1].  For example,
in a source file the full "GPL v2.0 or later" header text will be
replaced by a single line:

SPDX-License-Identifier:GPL-2.0+

We use the SPDX Unique Lincense Identifiers here; these are available
at [2].

Note: From the legal point of view, this patch is supposed to be only
a change to the textual representation of the license information,
but in no way any change to the actual license terms. With this patch
applied, all files will still be licensed under the same terms they
were before.

Note 2: The apparent difference between the old "COPYING" and the new
"Licenses/gpl-2.0.txt" only results from switching to the upstream
version of the license which is differently formatted; there are not
any actual changes to the content.

Note 3: There are some recurring questions about linense issues, such
as:
- Is a "All Rights Reserved" clause a problem in GPL code?
- Are files without any license header a problem?
- Do we need license headers at all?

The following excerpt from an e-mail by Daniel B. Ravicher should help
with these:

| Message-ID: <4adf8caa.5030...@softwarefreedom.org>
| Date: Wed, 21 Oct 2009 18:35:22 -0400
| From: "Daniel B. Ravicher" 
| To: Wolfgang Denk 
| Subject: Re: GPL and license cleanup questions
|
| Mr. Denk,
|
| Wolfgang Denk wrote:
| > - There are a number of files which do not include any specific
| > license information at all. Is it correct to assume that these files
| > are automatically covered by the "GPL v2 or later" clause as
| > specified by the COPYING file in the top level directory of the
| > U-Boot source tree?
|
| That is a very fact specific analysis and could be different across the
| various files.  However, if the contributor could reasonably be expected
| to have known that the project was licensed GPLv2 or later at the time
| she made her contribution, then a reasonably implication is that she
| consented to her contributions being distributed under those terms.
|
| > - Do such files need any clean up, for example should we add GPL
| > headers to them, or is this not needed?
|
| If the project as a whole is licensed under clear terms, you need not
| identify those same terms in each file, although there is no harm in
| doing so.
|
| > - There are other files, which include both a GPL license header
| > _plus_ some copyright note with an "All Rights Reserved" clause. It
| > has been my understanding that this is a conflict, and me must ask
| > the copyright holders to remove such "All Rights Reserved" clauses.
| > But then, some people claim that "All Rights Reserved" is a no-op
| > nowadays. License checking tools (like OSLC) seem to indicate this is
| > a problem, but then we see quite a lot of "All rights reserved" in
| > BSD-licensed files in gcc and glibc. So what is the correct way to
| > deal with such files?
|
| It is not a conflict to grant a license and also reserve all rights, as
| implicit in that language is that you are reserving all "other" rights
| not granted in the license.  Thus, a file with "Licensed under GPL, All
| Rights Reserved" would mean that it is licensed under the GPL, but no
| other rights are given to copy, modify or redistribute it.
|
| Warm regards,
| --Dan
|
| Daniel B. Ravicher, Legal Director
| Software Freedom Law Center (SFLC) and Moglen Ravicher LLC
| 1995 Broadway, 17th Fl., New York, NY 10023
| (212) 461-1902 direct  (212) 580-0800 main  (212) 580-0898 fax
| ravic...@softwarefreedom.org   www.softwarefreedom.org

[1] http://spdx.org/
[2] http://spdx.org/licenses/

Signed-off-by: Wolfgang Denk 
---
 Licenses/README |  27 ++
 COPYING => Licenses/gpl-2.0.txt | 113 ++--
 MAKEALL |   2 +
 Makefile|  20 +--
 README  |  20 +--
 config.mk   |  21 +---
 mkconfig|   4 +-
 rules.mk|  21 +---
 8 files changed, 113 insertions(+), 115 deletions(-)
 create mode 100644 Licenses/README
 rename COPYING => Licenses/gpl-2.0.txt (81%)

diff --git a/Licenses/README b/Licenses/README
new file mode 100644
index 000..564f598
--- /dev/null
+++ b/Licenses/README
@@ -0,0 +1,27 @@
+
+

Re: [U-Boot] Separately compile Master boot loader

[Rajdeep Vaghasia]

Waiting for a reply.


On Tue, Jul 9, 2013 at 4:12 PM, Rajdeep Vaghasia  wrote:

> Hi
> I am working on one board with an arm11 based cpu, NOR flash and DDR2
> SDRAM.
> When I compile u-boot source code, I get u-boot.bin image generated.
> This image has primary(second stage) and secondary(third stage) bootloader
> combined.
>
> I have following queries:
> 1) The question that still eats me everyday is, How can I compile
> primary(Master) boot loader and secondary boot loader separately?
> 2) I want to Flash only initial 4kb of code (Master boot loader or second
> stage). The remaining code I want to keep at another partition in the
> Flash. How can I achieve this?
> 3) Is there any separate code available for Master boot loader, which
> copies the third stage bootloader to SDRAM and then transfers control to
> that third stage boot loader(u-boot)?
>
> I am unable to find a way to do this.
>
> Can anyone help me please?
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] cmd_bootm.c: Make bootz consume 'bootz' from argv, decrement argc

[Simon Glass]

On Tue, Jul 9, 2013 at 9:59 PM, Stephen Warren wrote:

> On 07/09/2013 01:34 PM, Tom Rini wrote:
> > Like 'bootm', 'bootz' needs to consume 'bootz' so that the rest of the
> > state functions will work.
>
> I found that the Raspberry Pi was randomly crashing with recent
> u-boot/master (bisect points at/near commit 35fc84f "Refactor the bootm
> command to reduce code duplication"; there is some slight variation in
> symptoms around there), or sometimes just spewing errors from bootz. I
> found the following commits on the mailing list:
>
> > e1ec5e0 cmd_bootm.c: Make bootz handle BOOTM_STATE_FINDOTHER itself
> > c83a89d cmd_bootm.c: Make bootz consume 'bootz' from argv, decrement argc
> > d18cab6 bootm: Add the missing PREP stage to bootz and correct image
> handling
> > 4766b32 bootm: Clean up bootz_setup() function
> > f65d734 bootm: Require boot function only if it is about to be used
> > bf6f341 bootm: Disable interrupts only when loading
> > a01d5e4 bootm: Handle errors consistently
>
> ... and the combination of all 7 of them (but not just Simon's 5
> patches) seems to solve this, so,
>
> Tested-by: Stephen Warren 
>
>
Thanks Stephen. Is this with an attached dtb or not? What 'bootz' command
line are you testing here? I just want to make sure we are covering all the
options

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

Re: [U-Boot] [RFC PATCH] arm: arm926ejs: flush cache before disable it

[Sughosh Ganu]

hi Albert,

On Tue Jul 09, 2013 at 10:28:13AM +0200, Albert ARIBAUD wrote:

> > > The arm926ej-s data cache does not have a single fixed policy, and
> > > does not have a bypass-on-write policy, only write-through and
> > > copy-back.
> > > 
> > > Other, more complex, policies may be defined, but at the MMU, not cache,
> > > level, and those are not constant for all arm926ej-s based SoCs; not
> > > even constant for a given SoC as they are configurable at run-time to
> > > fit the chosen system addressing map.
> > 
> > Can you please elucidate on these policies. Based on my reading of the
> > arm developers manual and the arm926ejs trm, the mmu makes a
> > particular region cacheable and/or write bufferable. I did not find
> > mention of any other  policies. Maybe pointers or links to the
> > documents would help.
> 
> You are correct re the other policies of the DDI0198E (ARM926EJ-S
> TRM) MMU -- page 3-11, bits 3-2 of the section descriptor. Note however
> that you may have to refer to your specific SoC's TRM or equivalent, as
> the SoC designer may have defined its own system-level cache and MMU
> architecture.
> 
> Note in any case that none of the policies mentioned in DDI0198E is
> described as read-allocate (let alone "read-allocate only" where writes
> would bypass the enabled cache); on the contrary, the only cache
> policies mentioned are write-through and write-back, both of which
> contradict cache bypass on write.

I was referring to the cache allocation policy mentioned in section
4.1 in the DDI0198E document -- this is also mentioned in table 12.1
in chapter 12 of the arm developers guide.

> > > (Besides, bypassing the cache for writes and not reads is of little
> > > interest for plain DDR caching.)
> > 
> > Again, afaik this is independent of the target interface that is being
> > cached(if i've missed something, can you please point me to the
> > document). Thanks.
> 
> Sorry, I don't understand this last comment of yours wrt my point on the
> (lack of) interest of bypassing cache for DDR caching.

What i meant to state was that i did not find any mention that the
cache real allocate policy did not apply for DDR caching.

-sughosh

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

Re: [U-Boot] [PATCH v2 5/5] bootm: Add the missing PREP stage to bootz and correct image handling

[Sughosh Ganu]

hi Tom,

On Tue Jul 09, 2013 at 05:19:32PM -0400, Tom Rini wrote:



> > Yes, I am not really comfortable with this. I will see if I can write some
> > sandbox tests for the other image types today and post my results. I guess
> > this bootm code has built up over a long time and it is hard to know all
> > the ways it is used.
> 
> Important, but I really want to see real-world booting in a case or two.
> Unfortunately I don't have any ARM boards that work out of the box with
> NetBSD.

I have netbsd running on hawkboard, but i do not boot it using the
bootm command, but use the go command instead. I will try to build a
netbsd image with the u-boot header and give it a try with bootm. Need
a day or two to check this out though.

-sughosh

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

Re: [U-Boot] [PATCH v2 5/5] bootm: Add the missing PREP stage to bootz and correct image handling

[Simon Glass]

Hi Sughosh,

On Wed, Jul 10, 2013 at 2:51 AM, Sughosh Ganu wrote:

> hi Tom,
>
> On Tue Jul 09, 2013 at 05:19:32PM -0400, Tom Rini wrote:
>
> 
>
> > > Yes, I am not really comfortable with this. I will see if I can write
> some
> > > sandbox tests for the other image types today and post my results. I
> guess
> > > this bootm code has built up over a long time and it is hard to know
> all
> > > the ways it is used.
> >
> > Important, but I really want to see real-world booting in a case or two.
> > Unfortunately I don't have any ARM boards that work out of the box with
> > NetBSD.
>
> I have netbsd running on hawkboard, but i do not boot it using the
> bootm command, but use the go command instead. I will try to build a
> netbsd image with the u-boot header and give it a try with bootm. Need
> a day or two to check this out though.
>

Thanks, much appreciated.

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

Re: [U-Boot] [PATCH v2 5/5] bootm: Add the missing PREP stage to bootz and correct image handling

[Simon Glass]

Hi Tom,


On Tue, Jul 9, 2013 at 2:19 PM, Tom Rini  wrote:

> On Tue, Jul 09, 2013 at 01:04:58PM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Tue, Jul 9, 2013 at 12:05 PM, Tom Rini  wrote:
> >
> > > On Tue, Jul 09, 2013 at 12:00:00PM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Tue, Jul 9, 2013 at 10:01 AM, Tom Rini  wrote:
> > > >
> > > > > On Mon, Jul 08, 2013 at 10:22:13AM -0400, Tom Rini wrote:
> > > > > > On Mon, Jul 08, 2013 at 09:17:10AM -0500, Robert Nelson wrote:
> > > > > >
> > > > > > > On Mon, Jul 8, 2013 at 9:13 AM, Tom Rini  wrote:
> > > > > > > > On Thu, Jul 04, 2013 at 01:26:11PM -0700, Simon Glass wrote:
> > > > > > > >> In the recent bootm refactor, the PREP stage was missing in
> the
> > > > > bootz
> > > > > > > >> command. This causes unpredictable behaviour.
> > > > > > > >>
> > > > > > > >> The use of a local variable means that the reset of
> cmd_bootm.c
> > > > > does not
> > > > > > > >> in fact use the same image structure, so remove this.
> > > > > > > >>
> > > > > > > >> Also manually set the OS type to Linux, since this is the
> only
> > > > > possibility
> > > > > > > >> at present, and we need to select the right boot function.
> > > > > > > >>
> > > > > > > >> Signed-off-by: Simon Glass 
> > > > > > > >
> > > > > > > > With the whole series applied, I still see a hang at:
> > > > > > > > Kernel image @ 0x8020 [ 0x00 - 0x3d44a0 ]
> > > > > > > >
> > > > > > > > Starting kernel ...
> > > > > > > >
> > > > > > > > Perhaps something to do with how my DDR is not at 0x0 ->
> 256MiB
> > > but
> > > > > > > > 0x8000 -> 256MiB ?
> > > > > > >
> > > > > > >
> > > > > > > Tom, which board is that?
> > > > > > >
> > > > > > > These 5 patches just on top of v2013.07-rc2, the panda (non es)
> > > (board
> > > > > > > file) works, but Wand (device tree) is still locking up for
> me...
> > > > > > >
> > > > > > > Panda (Board file boot)
> > > > > > >
> > > > > > > load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
> > > > > > > run mmcargs
> > > > > > > bootz ${loadaddr}
> > > > > >
> > > > > > Ah-ha!  It's an appended dtb vs not problem now.  I can boot my
> > > > > > beagelbone with with an appended dtb and bootz, but can't with
> > > separate.
> > > > >
> > > > > OK, the BOOTM_STATE_FINDOTHER state code isn't working since we
> don't
> > > > > have the rest of the header bits that the code checks for set.
>  I've
> > > > > taken a few stabs at reworking things, but it's not working yet.
> > >  Simon,
> > > > > do you have any ideas here?  I'm starting to wonder if we don't
> need to
> > > > > revert things afterall and sort this out post release.
> > > > >
> > > > >
> > > > Yes time is running short. I did post two reverts - I wonder if they
> are
> > > > effective for this problem?
> > > >
> > > > Is the appended dtb with bootz the only problem remaining as far as
> we
> > > > know? If so then perhaps we are close.
> > > >
> > > > I will see if I can get a Beaglebone today or failing that I should
> be
> > > able
> > > > to try bootz with appeneded dtb on another ARM board.
> > >
> > > I've got a fix locally now, and I'm working on cleaning it up further.
> > > The problem is that BOOTM_STATE_FINDOTHER would never work since we
> > > aren't the "right" image types, so passed ramdisk and/or dtb didn't
> > > work.  Another problem was that bootz was never consuming 'bootz', but
> > > this was OK before.  I'll post a patch shortly.
> >
> >
> > OK great, thanks for looking at this.  I wonder if we can collect a set
> of
> > different use cases for bootz as a basis for test cases?
>
> Well, what happens on sandbox when you try and boot a kernel? :)  bootz
> is any of:
> kernel, kernel+ramdisk, kernel+ramdisk+fdt, kernel+fdt.
>

The test currently checks that the kernel/ramdisk/fdt appear in the right
place, and that U-Boot reports that it is booting the kernel from the right
address. That actually should cover bugs where things don't end up in the
right place, or are corrupted. Of course there are limitations with
automated tests like this, but I still think it will make it easier for the
next person who takes on a clean-up in this area of U-Boot.


>
> > > My biggest worry right now is, what might show up broken next?  Anyone
> > > out there easily able to boot a netbsd kernel or something?
> >
> > Yes, I am not really comfortable with this. I will see if I can write
> some
> > sandbox tests for the other image types today and post my results. I
> guess
> > this bootm code has built up over a long time and it is hard to know all
> > the ways it is used.
>
> Important, but I really want to see real-world booting in a case or two.
> Unfortunately I don't have any ARM boards that work out of the box with
> NetBSD.
>

Yes, me too. But in the meantime I have tried to do what I can here - spent
many happy hours reviewing the code carefully and writing a 'sandbox' test
for the following OSes:

['netbsd', 'lynxos', 'rtems', 'ose', 'plan9', 'vxworks', 'qnx', 'integrity

Re: [U-Boot] [PATCH v2 5/5] bootm: Add the missing PREP stage to bootz and correct image handling

[Simon Glass]

[snip]

I will tidy up my tests and submit these also at some point. Coverage now
> includes FIT and legacy images, with bootm commands and subcommands. For
> the record there is still a lot of test code missing:
>

(sorry, sent the last email by mistake - here is a list that I compiled
when writing the original tests)

   - hash algorithms - invalid hash/contents should be detected
   - signature algorithms - invalid sig/contents should be detected
   - compression
   - checking that errors are detected like:
- image overwriting
- missing images
- invalid configurations
- incorrect os/arch/type fields
- empty data
- images too large/small
- invalid FDT (e.g. putting a random binary in instead)
   - default configuration selection
   - bootm command line parameters should have desired effect
   - run code coverage to make sure we are testing all the code
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] net, phy: wrong 1000BASE detection with a lan9303 switch

[Heiko Schocher]

Hello,

I have problems with a lan9303 switch on an am335x based board,
which does not support 1000FD/HD modes, but as it set BMSR_ERCAP
bit in BMSR and returns 0x for reads on the MII_STAT1000 and
MII_CTRL1000 registers, u-boot code detects SPEED_1000 in
drivers/net/phy/phy.c genphy_parse_link() ... which is wrong,
as this switch does not support 1000 modes ...

I found in ./common/miiphyutil.c miiphy_speed() the define
CONFIG_PHY_GIGE which it seems lacks in drivers/net/phy/phy.c
genphy_parse_link() ? Or is there another option?

bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] net, phy: wrong 1000BASE detection with a lan9303 switch

[Heiko Schocher]

Hello,

Am 10.07.2013 12:09, schrieb Heiko Schocher:

Hello,

I have problems with a lan9303 switch on an am335x based board,
which does not support 1000FD/HD modes, but as it set BMSR_ERCAP
bit in BMSR and returns 0x for reads on the MII_STAT1000 and
MII_CTRL1000 registers, u-boot code detects SPEED_1000 in
drivers/net/phy/phy.c genphy_parse_link() ... which is wrong,
as this switch does not support 1000 modes ...

I found in ./common/miiphyutil.c miiphy_speed() the define
CONFIG_PHY_GIGE which it seems lacks in drivers/net/phy/phy.c
genphy_parse_link() ? Or is there another option?


Just an update ... the switch does not support reads for the
registers 0x09 and 0x0a, but sets the BMSR_ERCAP bit in BMSR.

A phy_read on register  0x09 or 0x0a fails ... In my case
the drivers/net/cpsw.c returns -1 ... and code in
drivers/net/phy/phy.c:

int genphy_parse_link(struct phy_device *phydev)
{
int mii_reg = phy_read(phydev, MDIO_DEVAD_NONE, MII_BMSR);

/* We're using autonegotiation */
if (mii_reg & BMSR_ANEGCAPABLE) {
u32 lpa = 0;
u32 gblpa = 0;
u32 estatus = 0;

/* Check for gigabit capability */
if (mii_reg & BMSR_ERCAP) {
/* We want a list of states supported by
 * both PHYs in the link
 */
gblpa = phy_read(phydev, MDIO_DEVAD_NONE, MII_STAT1000);
gblpa &= phy_read(phydev,
MDIO_DEVAD_NONE, MII_CTRL1000) << 2;
}

[...]

does not check, if phy_read returns with an error ...

Would this be an acceptable patch for it:

diff --git a/drivers/net/cpsw.c b/drivers/net/cpsw.c
index 379b679..52c08ed 100644
--- a/drivers/net/cpsw.c
+++ b/drivers/net/cpsw.c
@@ -489,7 +489,7 @@ static inline void wait_for_idle(void)
 static int cpsw_mdio_read(struct mii_dev *bus, int phy_id,
int dev_addr, int phy_reg)
 {
-   unsigned short data;
+   int data;
u32 reg;

if (phy_reg & ~PHY_REG_MASK || phy_id & ~PHY_ID_MASK)
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index 7c0eaec..4522382 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -291,7 +291,7 @@ int genphy_parse_link(struct phy_device *phydev)
/* We're using autonegotiation */
if (mii_reg & BMSR_ANEGCAPABLE) {
u32 lpa = 0;
-   u32 gblpa = 0;
+   int gblpa = 0;
u32 estatus = 0;

/* Check for gigabit capability */
@@ -300,6 +300,10 @@ int genphy_parse_link(struct phy_device *phydev)
 * both PHYs in the link
 */
gblpa = phy_read(phydev, MDIO_DEVAD_NONE, MII_STAT1000);
+   if (gblpa < 0) {
+   printf ("Could not read MII_STAT1000. Ignoring 
gigabit capability\n");
+   gblpa = 0;
+   }
gblpa &= phy_read(phydev,
MDIO_DEVAD_NONE, MII_CTRL1000) << 2;
}
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] net, phy: wrong 1000BASE detection with a lan9303 switch

[Wolfgang Denk]

Dear Heiko,

In message <51dd3d92.8050...@denx.de> you wrote:
> 
> Would this be an acceptable patch for it:
...
> @@ -300,6 +300,10 @@ int genphy_parse_link(struct phy_device *phydev)
>   * both PHYs in the link
>   */
>  gblpa = phy_read(phydev, MDIO_DEVAD_NONE, 
> MII_STAT1000);
> +   if (gblpa < 0) {
> +   printf ("Could not read MII_STAT1000. 
> Ignoring gigabit capability\n");
> +   gblpa = 0;
> +   }
>  gblpa &= phy_read(phydev,
>  MDIO_DEVAD_NONE, MII_CTRL1000) << 2;

Well, this other phy_read() probably needs exactly the same error
handling - and I doubt if we should actually try riding the reg when
the first one failed already?

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
Without freedom of choice there is no creativity.
-- Kirk, "The return of the Archons", stardate 3157.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 0/7] qspi controller: Normal, quad and memory mapped read support

[Sourav Poddar]

This patch series add uboot ti qspi controller driver.

QSPI is a kind of spi module that allows single,
dual and quad read access to external spi devices. The module
has a memory mapped interface which provide direct interface
for accessing data form external spi devices.

SPI mode
---
SPI mode uses mtd spi framework for transfer and reception of data.
Can be used in:
1. Normal mode: use single pin for transfers
2. Dual Mode: use two pins for transfers.
3. Quad mode: use four pin for transfer

Memory mapped read mode
---
In this, SPI controller is configured using configuration port and then
controler is switched to memory mapped port for data read.

Series proposed suport for quad read as well as memory mapped read 
in spi mtd frameowrk as well as ti qpsi driver.

Matt Porter (3):
  omap5: add qspi support
  spi: add TI QSPI driver
  dra7xx_evm: add SPL API, QSPI, and serial flash support

Ravikumar Kattekola (1):
  drivers: mtd: qspi: Add quad read support

Sourav Poddar (3):
  drivers: mtd: spi: Modify read/write command for sfl256s flash.
  driver: spi: Add memory mapped read support
  README: qspi usecase and testing documentation.

 arch/arm/cpu/armv7/omap5/hw_data.c |7 +-
 arch/arm/cpu/armv7/omap5/prcm-regs.c   |1 +
 arch/arm/include/asm/arch-omap5/omap.h |3 +
 arch/arm/include/asm/arch-omap5/spl.h  |1 +
 arch/arm/include/asm/omap_common.h |1 +
 board/ti/dra7xx/mux_data.h |   10 +
 doc/README.ti_qspi_dra_test|   38 
 doc/README.ti_qspi_flash   |   47 +
 drivers/mtd/spi/spansion.c |1 +
 drivers/mtd/spi/spi_flash.c|  177 +-
 drivers/mtd/spi/spi_flash_internal.h   |2 +
 drivers/spi/Makefile   |1 +
 drivers/spi/ti_qspi.c  |  327 
 include/configs/dra7xx_evm.h   |   24 +++
 include/spi.h  |5 +
 15 files changed, 640 insertions(+), 5 deletions(-)
 create mode 100644 doc/README.ti_qspi_dra_test
 create mode 100644 doc/README.ti_qspi_flash
 create mode 100644 drivers/spi/ti_qspi.c

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

[U-Boot] [PATCH 1/7] omap5: add qspi support

[Sourav Poddar]

From: Matt Porter 

Add QSPI definitions and clock configuration support.

Signed-off-by: Matt Porter 
Signed-off-by: Sourav Poddar 
---
 arch/arm/cpu/armv7/omap5/hw_data.c |7 ++-
 arch/arm/cpu/armv7/omap5/prcm-regs.c   |1 +
 arch/arm/include/asm/arch-omap5/omap.h |3 +++
 arch/arm/include/asm/arch-omap5/spl.h  |1 +
 arch/arm/include/asm/omap_common.h |1 +
 5 files changed, 12 insertions(+), 1 deletions(-)

diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c 
b/arch/arm/cpu/armv7/omap5/hw_data.c
index 9374c6a..046ce44 100644
--- a/arch/arm/cpu/armv7/omap5/hw_data.c
+++ b/arch/arm/cpu/armv7/omap5/hw_data.c
@@ -186,7 +186,7 @@ static const struct dpll_params 
per_dpll_params_768mhz_es2[NUM_SYS_CLKS] = {
 
 static const struct dpll_params per_dpll_params_768mhz_dra7xx[NUM_SYS_CLKS] = {
{32, 0, 4, 1, 3, 4, 10, 2, -1, -1, -1, -1}, /* 12 MHz   */
-   {96, 4, 4, 1, 3, 4, 10, 2, -1, -1, -1, -1}, /* 20 MHz   */
+   {96, 4, 4, 1, 3, 4, 4, 2, -1, -1, -1, -1},  /* 20 MHz   */
{160, 6, 4, 1, 3, 4, 10, 2, -1, -1, -1, -1},/* 16.8 MHz */
{20, 0, 4, 1, 3, 4, 10, 2, -1, -1, -1, -1}, /* 19.2 MHz */
{192, 12, 4, 1, 3, 4, 10, 2, -1, -1, -1, -1},   /* 26 MHz   */
@@ -423,6 +423,7 @@ void enable_basic_clocks(void)
(*prcm)->cm_wkup_wdtimer2_clkctrl,
(*prcm)->cm_l4per_uart3_clkctrl,
(*prcm)->cm_l4per_i2c1_clkctrl,
+   (*prcm)->cm_l4per_qspi_clkctrl,
0
};
 
@@ -451,6 +452,10 @@ void enable_basic_clocks(void)
 clk_modules_explicit_en_essential,
 1);
 
+#ifdef CONFIG_TI_QSPI
+   setbits_le32((*prcm)->cm_l4per_qspi_clkctrl, (1<<24));
+#endif
+
/* Enable SCRM OPT clocks for PER and CORE dpll */
setbits_le32((*prcm)->cm_wkupaon_scrm_clkctrl,
OPTFCLKEN_SCRM_PER_MASK);
diff --git a/arch/arm/cpu/armv7/omap5/prcm-regs.c 
b/arch/arm/cpu/armv7/omap5/prcm-regs.c
index 331117c..debc56b 100644
--- a/arch/arm/cpu/armv7/omap5/prcm-regs.c
+++ b/arch/arm/cpu/armv7/omap5/prcm-regs.c
@@ -926,6 +926,7 @@ struct prcm_regs const dra7xx_prcm = {
.cm_l4per_gpio8_clkctrl = 0x4a009818,
.cm_l4per_mmcsd3_clkctrl= 0x4a009820,
.cm_l4per_mmcsd4_clkctrl= 0x4a009828,
+   .cm_l4per_qspi_clkctrl  = 0x4a009838,
.cm_l4per_uart1_clkctrl = 0x4a009840,
.cm_l4per_uart2_clkctrl = 0x4a009848,
.cm_l4per_uart3_clkctrl = 0x4a009850,
diff --git a/arch/arm/include/asm/arch-omap5/omap.h 
b/arch/arm/include/asm/arch-omap5/omap.h
index e7d79fc..d2c4930 100644
--- a/arch/arm/include/asm/arch-omap5/omap.h
+++ b/arch/arm/include/asm/arch-omap5/omap.h
@@ -67,6 +67,9 @@
 /* GPMC */
 #define OMAP54XX_GPMC_BASE 0x5000
 
+/* QSPI */
+#define QSPI_BASE  0x4B30
+
 /*
  * Hardware Register Details
  */
diff --git a/arch/arm/include/asm/arch-omap5/spl.h 
b/arch/arm/include/asm/arch-omap5/spl.h
index d4d353c..8905cb8 100644
--- a/arch/arm/include/asm/arch-omap5/spl.h
+++ b/arch/arm/include/asm/arch-omap5/spl.h
@@ -31,6 +31,7 @@
 #define BOOT_DEVICE_MMC15
 #define BOOT_DEVICE_MMC26
 #define BOOT_DEVICE_MMC2_2 7
+#define BOOT_DEVICE_SPI10
 
 #define MMC_BOOT_DEVICES_START BOOT_DEVICE_MMC1
 #define MMC_BOOT_DEVICES_END   BOOT_DEVICE_MMC2_2
diff --git a/arch/arm/include/asm/omap_common.h 
b/arch/arm/include/asm/omap_common.h
index fa28358..c8d4619 100644
--- a/arch/arm/include/asm/omap_common.h
+++ b/arch/arm/include/asm/omap_common.h
@@ -279,6 +279,7 @@ struct prcm_regs {
u32 cm_l4per_mmcsd4_clkctrl;
u32 cm_l4per_msprohg_clkctrl;
u32 cm_l4per_slimbus2_clkctrl;
+   u32 cm_l4per_qspi_clkctrl;
u32 cm_l4per_uart1_clkctrl;
u32 cm_l4per_uart2_clkctrl;
u32 cm_l4per_uart3_clkctrl;
-- 
1.7.1

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

[U-Boot] [PATCH 0/7] qspi controller: Normal, quad and memory mapped read support

[Sourav Poddar]

This patch series add uboot ti qspi controller driver.

QSPI is a kind of spi module that allows single,
dual and quad read access to external spi devices. The module
has a memory mapped interface which provide direct interface
for accessing data form external spi devices.

SPI mode
---
SPI mode uses mtd spi framework for transfer and reception of data.
Can be used in:
1. Normal mode: use single pin for transfers
2. Dual Mode: use two pins for transfers.
3. Quad mode: use four pin for transfer

Memory mapped read mode
---
In this, SPI controller is configured using configuration port and then
controler is switched to memory mapped port for data read.

Series proposed suport for quad read as well as memory mapped read 
in spi mtd frameowrk as well as ti qpsi driver.

Matt Porter (3):
  omap5: add qspi support
  spi: add TI QSPI driver
  dra7xx_evm: add SPL API, QSPI, and serial flash support

Ravikumar Kattekola (1):
  drivers: mtd: qspi: Add quad read support

Sourav Poddar (3):
  drivers: mtd: spi: Modify read/write command for sfl256s flash.
  driver: spi: Add memory mapped read support
  README: qspi usecase and testing documentation.

 arch/arm/cpu/armv7/omap5/hw_data.c |7 +-
 arch/arm/cpu/armv7/omap5/prcm-regs.c   |1 +
 arch/arm/include/asm/arch-omap5/omap.h |3 +
 arch/arm/include/asm/arch-omap5/spl.h  |1 +
 arch/arm/include/asm/omap_common.h |1 +
 board/ti/dra7xx/mux_data.h |   10 +
 doc/README.ti_qspi_dra_test|   38 
 doc/README.ti_qspi_flash   |   47 +
 drivers/mtd/spi/spansion.c |1 +
 drivers/mtd/spi/spi_flash.c|  177 +-
 drivers/mtd/spi/spi_flash_internal.h   |2 +
 drivers/spi/Makefile   |1 +
 drivers/spi/ti_qspi.c  |  327 
 include/configs/dra7xx_evm.h   |   24 +++
 include/spi.h  |5 +
 15 files changed, 640 insertions(+), 5 deletions(-)
 create mode 100644 doc/README.ti_qspi_dra_test
 create mode 100644 doc/README.ti_qspi_flash
 create mode 100644 drivers/spi/ti_qspi.c

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

[U-Boot] [RFC/PATCH 6/7] driver: spi: Add memory mapped read support

[Sourav Poddar]

Qspi controller has a memory mapped port which can be used for
data transfers. First controller need to be configured through
configuration port, then for data read switch the controller
to memory mapped and read from the predefined location.

Signed-off-by: Sourav Poddar 
---
 drivers/mtd/spi/spansion.c   |1 +
 drivers/mtd/spi/spi_flash.c  |   31 +--
 drivers/spi/ti_qspi.c|   85 +++---
 include/configs/dra7xx_evm.h |3 +-
 include/spi.h|3 +
 5 files changed, 104 insertions(+), 19 deletions(-)

diff --git a/drivers/mtd/spi/spansion.c b/drivers/mtd/spi/spansion.c
index bc558c4..7edc369 100644
--- a/drivers/mtd/spi/spansion.c
+++ b/drivers/mtd/spi/spansion.c
@@ -137,6 +137,7 @@ struct spi_flash *spi_flash_probe_spansion(struct spi_slave 
*spi, u8 *idcode)
flash->page_size = 256;
flash->sector_size = 256 * params->pages_per_sector;
flash->size = flash->sector_size * params->nr_sectors;
+flash->memory_map = spi->memory_map;
 
return flash;
 }
diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index f3094a2..1482a25 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -155,6 +155,18 @@ int spi_flash_read_common(struct spi_flash *flash, const 
u8 *cmd,
return ret;
 }
 
+void mem1cpy(void *dstAddr, void *srcAddr, size_t length)
+{
+   unsigned  i;
+   unsigned *DAddr = (unsigned *) (dstAddr);
+   unsigned *SAddr = (unsigned *) (srcAddr);
+   for (i = 0; i < length; i++)
+   {
+   *DAddr++ = *SAddr++;
+   }
+   return;
+}
+
 int spi_flash_cmd_read_fast(struct spi_flash *flash, u32 offset,
size_t len, void *data)
 {
@@ -164,8 +176,13 @@ int spi_flash_cmd_read_fast(struct spi_flash *flash, u32 
offset,
u8 cmd[4];
 
/* Handle memory-mapped SPI */
-   if (flash->memory_map)
-   memcpy(data, flash->memory_map + offset, len);
+   if (flash->memory_map) {
+   spi_xfer(flash->spi, 0, NULL, NULL, SPI_XFER_MEM_MAP);
+   memcpy(data, (void *)(flash->memory_map + offset), len);
+   *((unsigned *) flash->memory_map) += (len * 4);
+   spi_xfer(flash->spi, 0, NULL, NULL, SPI_XFER_MEM_MAP_END);
+   return 0;
+   }
 
 #ifdef CONFIG_TI_QSPI
page_size = flash->page_size;
@@ -214,9 +231,15 @@ int spi_flash_cmd_read_quad(struct spi_flash *flash, u32 
offset,
u8 cmd[5];
 
spi->quad_enable = 1;
+
/* Handle memory-mapped SPI */
-   if (flash->memory_map)
-   memcpy(data, flash->memory_map + offset, len);
+   if (flash->memory_map) {
+   spi_xfer(flash->spi, 0, NULL, NULL, SPI_XFER_MEM_MAP);
+   memcpy(data, (void *)(flash->memory_map + offset), len);
+   *((unsigned *) flash->memory_map) += (len * 4);
+   spi_xfer(flash->spi, 0, NULL, NULL, SPI_XFER_MEM_MAP_END);
+   return 0;
+   }
 
page_size = flash->page_size;
page_addr = offset / page_size;
diff --git a/drivers/spi/ti_qspi.c b/drivers/spi/ti_qspi.c
index 12bba11..d314b6e 100644
--- a/drivers/spi/ti_qspi.c
+++ b/drivers/spi/ti_qspi.c
@@ -23,8 +23,8 @@
 struct qspi_slave {
struct spi_slave slave;
unsigned int mode;
-   u32 cmd;
-   u32 dc;
+u32 cmd;
+u32 dc;
 };
 
 #define to_qspi_slave(s) container_of(s, struct qspi_slave, slave)
@@ -86,6 +86,24 @@ static struct qspi_regs *qspi = (struct qspi_regs 
*)QSPI_BASE;
 #define QSPI_WC_BUSY   (QSPI_WC | QSPI_BUSY)
 #define QSPI_XFER_DONE QSPI_WC
 
+#define MM_SWITCH  0x01
+#define MEM_CS  0x100
+#define MEM_CS_UNSELECT0xf0ff
+#define MMAP_START_ADDR 0x5c00
+#define CORE_CTRL_IO0x4a002558
+
+#defineQSPI_CMD_READ   (0x3 << 0)
+#defineQSPI_CMD_READ_QUAD  (0x6b << 0)
+#defineQSPI_CMD_READ_FAST  (0x0b << 0)
+
+#defineQSPI_SETUP0_NUM_A_BYTES (0x2 << 8)
+#defineQSPI_SETUP0_NUM_D_BYTES_NO_BITS (0x0 << 10)
+#defineQSPI_SETUP0_NUM_D_BYTES_8_BITS  (0x1 << 10)
+#defineQSPI_SETUP0_READ_NORMAL (0x0 << 12)
+#defineQSPI_SETUP0_READ_QUAD   (0x3 << 12)
+#defineQSPI_CMD_WRITE  (0x2 << 16)
+#define QSPI_NUM_DUMMY_BITS(0x0 << 24)
+
 int spi_cs_is_valid(unsigned int bus, unsigned int cs)
 {
return 1;
@@ -108,6 +126,24 @@ void spi_init(void)
/* nothing to do */
 }
 
+void spi_set_up_spi_register(struct spi_slave *slave)
+{
+   u32 memval = 0;
+
+   slave->memory_map = (void *)MMAP_START_ADDR;
+
+#ifdef CONFIG_SF_QUAD_RD
+   memval |= (QSPI_CMD_READ_QUAD | QSPI_SETUP0_NUM_A_BYTES |
+   QSPI

[U-Boot] [PATCH 3/7] dra7xx_evm: add SPL API, QSPI, and serial flash support

[Sourav Poddar]

From: Matt Porter 

Enables support for SPI SPL, QSPI and Spansion serial flash device
on the EVM. Configures pin muxes for QSPI mode.

Signed-off-by: Matt Porter 
Signed-off-by: Sourav Poddar 
---
 board/ti/dra7xx/mux_data.h   |   10 ++
 include/configs/dra7xx_evm.h |   22 ++
 2 files changed, 32 insertions(+), 0 deletions(-)

diff --git a/board/ti/dra7xx/mux_data.h b/board/ti/dra7xx/mux_data.h
index 338a241..2441c55 100644
--- a/board/ti/dra7xx/mux_data.h
+++ b/board/ti/dra7xx/mux_data.h
@@ -53,5 +53,15 @@ const struct pad_conf_entry core_padconf_array_essential[] = 
{
{UART1_RTSN, (IEN | PTU | PDIS | M3)},  /* UART1_RTSN */
{I2C1_SDA, (IEN | PTU | PDIS | M0)},/* I2C1_SDA */
{I2C1_SCL, (IEN | PTU | PDIS | M0)},/* I2C1_SCL */
+   {GPMC_A13, (IEN | PDIS | M1)},  /* QSPI1_RTCLK */
+   {GPMC_A14, (IEN | PDIS | M1)},  /* QSPI1_D[3] */
+   {GPMC_A15, (IEN | PDIS | M1)},  /* QSPI1_D[2] */
+   {GPMC_A16, (IEN | PDIS | M1)},  /* QSPI1_D[1] */
+   {GPMC_A17, (IEN | PDIS | M1)},  /* QSPI1_D[0] */
+   {GPMC_A18, (IEN | PDIS | M1)},  /* QSPI1_SCLK */
+   {GPMC_A3, (IEN | PDIS | M1)},   /* QSPI1_CS2 */
+   {GPMC_A4, (IEN | PDIS | M1)},   /* QSPI1_CS3 */
+   {GPMC_CS2, (IEN | PTU | PDIS | M1)},/* QSPI1_CS0 */
+   {GPMC_CS3, (IEN | PTU | PDIS | M1)},/* QSPI1_CS1*/
 };
 #endif /* _MUX_DATA_DRA7XX_H_ */
diff --git a/include/configs/dra7xx_evm.h b/include/configs/dra7xx_evm.h
index 6b37e1d..0583858 100644
--- a/include/configs/dra7xx_evm.h
+++ b/include/configs/dra7xx_evm.h
@@ -46,4 +46,26 @@
 #define NON_SECURE_SRAM_END0x4038  /* Not inclusive */
 
 #define CONFIG_SYS_OMAP_ABE_SYSCK
+#define CONFIG_SYS_DCACHE_OFF
+#define CONFIG_SYS_ICACHE_OFF
+
+#define EMIF1_EMIF2
+
+/* SPI */
+#define CONFIG_TI_QSPI
+#define CONFIG_SPI_FLASH
+#define CONFIG_SPI_FLASH_SPANSION
+#define CONFIG_CMD_SF
+#define CONFIG_CMD_SPI
+#define CONFIG_SF_DEFAULT_SPEED1200
+#define CONFIG_DEFAULT_SPI_MODESPI_MODE_3
+
+/* SPI SPL */
+#define CONFIG_SPL_SPI_SUPPORT
+#define CONFIG_SPL_SPI_LOAD
+#define CONFIG_SPL_SPI_FLASH_SUPPORT
+#define CONFIG_SPL_SPI_BUS 0
+#define CONFIG_SPL_SPI_CS  0
+#define CONFIG_SYS_SPI_U_BOOT_OFFS 0x2
+
 #endif /* __CONFIG_DRA7XX_EVM_H */
-- 
1.7.1

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

[U-Boot] [PATCH 2/7] spi: add TI QSPI driver

[Sourav Poddar]

From: Matt Porter 

Adds a SPI master driver for the TI QSPI peripheral.

Signed-off-by: Matt Porter 
Signed-off-by: Sourav Poddar 
---
 drivers/spi/Makefile  |1 +
 drivers/spi/ti_qspi.c |  262 +
 2 files changed, 263 insertions(+), 0 deletions(-)
 create mode 100644 drivers/spi/ti_qspi.c

diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index d08609e..f51033d 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -54,6 +54,7 @@ COBJS-$(CONFIG_FDT_SPI) += fdt_spi.o
 COBJS-$(CONFIG_TEGRA20_SFLASH) += tegra20_sflash.o
 COBJS-$(CONFIG_TEGRA20_SLINK) += tegra20_slink.o
 COBJS-$(CONFIG_TEGRA114_SPI) += tegra114_spi.o
+COBJS-$(CONFIG_TI_QSPI) += ti_qspi.o
 COBJS-$(CONFIG_XILINX_SPI) += xilinx_spi.o
 
 COBJS  := $(COBJS-y)
diff --git a/drivers/spi/ti_qspi.c b/drivers/spi/ti_qspi.c
new file mode 100644
index 000..1973b85
--- /dev/null
+++ b/drivers/spi/ti_qspi.c
@@ -0,0 +1,262 @@
+/*
+ * TI QSPI driver
+ *
+ * Copyright (C) 2013, Texas Instruments, Incorporated
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR /PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct qspi_slave {
+   struct spi_slave slave;
+   unsigned int mode;
+   u32 cmd;
+   u32 dc;
+};
+
+#define to_qspi_slave(s) container_of(s, struct qspi_slave, slave)
+
+struct qspi_regs {
+   u32 pid;
+   u32 pad0[3];
+   u32 sysconfig;
+   u32 pad1[3];
+   u32 intr_status_raw_set;
+   u32 intr_status_enabled_clear;
+   u32 intr_enable_set;
+   u32 intr_enable_clear;
+   u32 intc_eoi;
+   u32 pad2[3];
+   u32 spi_clock_cntrl;
+   u32 spi_dc;
+   u32 spi_cmd;
+   u32 spi_status;
+   u32 spi_data;
+   u32 spi_setup0;
+   u32 spi_setup1;
+   u32 spi_setup2;
+   u32 spi_setup3;
+   u32 spi_switch;
+   u32 spi_data1;
+   u32 spi_data2;
+   u32 spi_data3;
+};
+
+static struct qspi_regs *qspi = (struct qspi_regs *)QSPI_BASE;
+
+#define QSPI_TIMEOUT   200
+
+#define QSPI_FCLK  19200
+
+/* Clock Control */
+#define QSPI_CLK_EN(1 << 31)
+#define QSPI_CLK_DIV_MAX   0x
+
+/* Command */
+#define QSPI_EN_CS(n)  (n << 28)
+#define QSPI_WLEN(n)   ((n-1) << 19)
+#define QSPI_3_PIN (1 << 18)
+#define QSPI_RD_SNGL   (1 << 16)
+#define QSPI_WR_SNGL   (2 << 16)
+#define QSPI_INVAL (4 << 16)
+
+/* Device Control */
+#define QSPI_DD(m, n)  (m << (3 + n*8))
+#define QSPI_CKPHA(n)  (1 << (2 + n*8))
+#define QSPI_CSPOL(n)  (1 << (1 + n*8))
+#define QSPI_CKPOL(n)  (1 << (n*8))
+
+/* Status */
+#define QSPI_WC(1 << 1)
+#define QSPI_BUSY  (1 << 0)
+#define QSPI_WC_BUSY   (QSPI_WC | QSPI_BUSY)
+#define QSPI_XFER_DONE QSPI_WC
+
+int spi_cs_is_valid(unsigned int bus, unsigned int cs)
+{
+   return 1;
+}
+
+void spi_cs_activate(struct spi_slave *slave)
+{
+   /* CS handled in xfer */
+   return;
+}
+
+void spi_cs_deactivate(struct spi_slave *slave)
+{
+   /* CS handled in xfer */
+   return;
+}
+
+void spi_init(void)
+{
+   /* nothing to do */
+}
+
+void spi_set_speed(struct spi_slave *slave, uint hz)
+{
+   uint clk_div;
+
+   if (!hz)
+   clk_div = 0;
+   else
+   clk_div = (QSPI_FCLK / hz) - 1;
+
+   debug("%s: hz: %d, clock divider %d\n", __func__, hz, clk_div);
+
+   /* disable SCLK */
+   writel(readl(&qspi->spi_clock_cntrl) & ~QSPI_CLK_EN, 
&qspi->spi_clock_cntrl);
+
+   if (clk_div < 0) {
+   debug("%s: clock divider < 0, using /1 divider\n", __func__);
+   clk_div = 0;
+   }
+
+   if (clk_div > QSPI_CLK_DIV_MAX) {
+   debug("%s: clock divider >%d , using /%d divider\n",
+   __func__, QSPI_CLK_DIV_MAX, QSPI_CLK_DIV_MAX + 1);
+   clk_div = QSPI_CLK_DIV_MAX;
+   }
+
+   /* enable SCLK */
+   writel(QSPI_CLK_EN | clk_div, &qspi->spi_clock_cntrl);
+   debug("%s: spi_clock_cntrl %08x\n", __func__, 
readl(&qspi->spi_clock_cntrl));
+}
+
+struct spi_slave *spi_setup_slave(unsigned int bus, unsigned int cs,
+ unsigned int max_hz, unsigned int mode)
+{
+   struct qspi_slave *qslave;
+
+   qslave = spi_alloc_slav

[U-Boot] [RFC/PATCH 4/7] drivers: mtd: spi: Modify read/write command for sfl256s flash.

[Sourav Poddar]

Reading using the already supported read command is causing regression
even while reading 4k bytes, as a result doing a page by page read.

At the end of the write sequence, write enable latch should be disabled and
re enabled while doing the next page programming.

Looking for help from community on this patch.
I am using S25fl256s flash and already existing framework does not
work on my board. So, I have modified the read function to do page read.

IF i use the already existing framework, read happend till 4k boundary, after 
which everything is read as zero. Write happens for a single page, if I dont 
provide a write disable at the end of the write function. 

Signed-off-by: Sourav Poddar 
---
 drivers/mtd/spi/spi_flash.c |   41 -
 1 files changed, 40 insertions(+), 1 deletions(-)

diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 85a..e7f1188 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -117,6 +117,12 @@ int spi_flash_cmd_write_multi(struct spi_flash *flash, u32 
offset,
if (ret)
break;
 
+   ret = spi_flash_cmd_write_disable(flash);
+   if (ret < 0) {
+   printf("SF: disabling write failed\n");
+   break;
+   }
+
byte_addr += chunk_len;
if (byte_addr == page_size) {
page_addr++;
@@ -147,17 +153,50 @@ int spi_flash_read_common(struct spi_flash *flash, const 
u8 *cmd,
 int spi_flash_cmd_read_fast(struct spi_flash *flash, u32 offset,
size_t len, void *data)
 {
-   u8 cmd[5];
+   unsigned long page_addr, byte_addr, page_size;
+   size_t chunk_len, actual;
+   int ret = 0;
 
/* Handle memory-mapped SPI */
if (flash->memory_map)
memcpy(data, flash->memory_map + offset, len);
 
+#ifdef CONFIG_TI_QSPI
+u8 cmd[4];
+   page_size = flash->page_size;
+   page_addr = offset / page_size;
+   byte_addr = offset % page_size;
+
+   cmd[0] = CMD_READ_ARRAY_SLOW;
+   for (actual = 0; actual < len; actual += chunk_len) {
+   chunk_len = min(len - actual, page_size - byte_addr);
+
+   cmd[1] = page_addr >> 8;
+   cmd[2] = page_addr;
+   cmd[3] = byte_addr;
+
+   ret = spi_flash_read_common(flash, cmd, sizeof(cmd), data + 
actual, chunk_len);
+   if (ret < 0) {
+   debug("SF: read failed");
+   break;
+   }
+
+   byte_addr += chunk_len;
+   if (byte_addr == page_size) {
+   page_addr++;
+   byte_addr = 0;
+   }
+   }
+
+   return ret;
+#else
+u8 cmd[5];
cmd[0] = CMD_READ_ARRAY_FAST;
spi_flash_addr(offset, cmd);
cmd[4] = 0x00;
 
return spi_flash_read_common(flash, cmd, sizeof(cmd), data, len);
+#endif
 }
 
 int spi_flash_cmd_poll_bit(struct spi_flash *flash, unsigned long timeout,
-- 
1.7.1

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

[U-Boot] [RFC/PATCH 5/7] drivers: mtd: qspi: Add quad read support

[Sourav Poddar]

From: Ravikumar Kattekola 

Add Quad read mode (6 pin interface) support to spi flash
and ti qspi driver.

Quad mode (0x6bh on spansion) uses two extra pins (D2 and D3) for
data transfer apart from the usual D0 and D1 pins thus transfering
4 bits per cycle.

Signed-off-by: Ravikumar Kattekola 
Signed-off-by: Sourav Poddar 
---
 drivers/mtd/spi/spi_flash.c  |  110 +-
 drivers/mtd/spi/spi_flash_internal.h |2 +
 drivers/spi/ti_qspi.c|   18 --
 include/configs/dra7xx_evm.h |1 +
 include/spi.h|2 +
 5 files changed, 127 insertions(+), 6 deletions(-)

diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 5cc5669..f3094a2 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -42,7 +42,12 @@ static int spi_flash_read_write(struct spi_slave *spi,
debug("SF: Failed to send command (%zu bytes): %d\n",
cmd_len, ret);
} else if (data_len != 0) {
-   ret = spi_xfer(spi, data_len * 8, data_out, data_in, 
SPI_XFER_END);
+   if (spi->quad_enable)
+   flags = SPI_6WIRE;
+   else
+   flags = 0;
+
+   ret = spi_xfer(spi, data_len * 8, data_out, data_in, flags | 
SPI_XFER_END);
if (ret)
debug("SF: Failed to transfer %zu bytes of data: %d\n",
data_len, ret);
@@ -198,6 +203,51 @@ int spi_flash_cmd_read_fast(struct spi_flash *flash, u32 
offset,
 #endif
 }
 
+int spi_flash_cmd_read_quad(struct spi_flash *flash, u32 offset,
+   size_t len, void *data)
+{
+   struct spi_slave *spi = flash->spi;
+
+   unsigned long page_addr, byte_addr, page_size;
+   size_t chunk_len, actual;
+   int ret = 0;
+   u8 cmd[5];
+
+   spi->quad_enable = 1;
+   /* Handle memory-mapped SPI */
+   if (flash->memory_map)
+   memcpy(data, flash->memory_map + offset, len);
+
+   page_size = flash->page_size;
+   page_addr = offset / page_size;
+   byte_addr = offset % page_size;
+
+   cmd[0] = CMD_READ_ARRAY_QUAD;
+   for (actual = 0; actual < len; actual += chunk_len) {
+   chunk_len = min(len - actual, page_size - byte_addr);
+
+   cmd[1] = page_addr >> 8;
+   cmd[2] = page_addr;
+   cmd[3] = byte_addr;
+   cmd[4] = 0x0;
+
+   ret = spi_flash_read_common(flash, cmd, sizeof(cmd),
+   data + actual, chunk_len);
+   if (ret < 0) {
+   debug("SF: read failed");
+   break;
+   }
+
+   byte_addr += chunk_len;
+   if (byte_addr == page_size) {
+   page_addr++;
+   byte_addr = 0;
+   }
+   }
+
+   return ret;
+}
+
 int spi_flash_cmd_poll_bit(struct spi_flash *flash, unsigned long timeout,
   u8 cmd, u8 poll_bit)
 {
@@ -320,6 +370,56 @@ int spi_flash_cmd_write_status(struct spi_flash *flash, u8 
sr)
return 0;
 }
 
+int spi_flash_en_quad_mode(struct spi_flash *flash)
+{
+   u8 stat, con, cd;
+   u16 cr;
+   int ret;
+   cd = CMD_WRITE_STATUS;
+
+   ret = spi_flash_cmd_write_enable(flash);
+   if (ret < 0) {
+   debug("SF: enabling write failed\n");
+   goto out;
+   }
+   ret = spi_flash_cmd(flash->spi, CMD_READ_STATUS, &stat, 1);
+   ret = spi_flash_cmd(flash->spi, CMD_READ_CONFIG, &con, 1);
+   if (ret < 0) {
+   debug("%s: SF: read CR failed\n", __func__);
+   goto out;
+   }
+   /* Byte 1 - status reg, Byte 2 - config reg */
+   cr = ((con | 0x1 << 1) << 8) | (stat << 0);
+
+   ret = spi_flash_cmd_write(flash->spi, &cd, 1, &cr, 2);
+   if (ret) {
+   debug("SF: fail to write conf register\n");
+   goto out;
+   }
+
+   ret = spi_flash_cmd_wait_ready(flash, SPI_FLASH_PROG_TIMEOUT);
+   if (ret < 0) {
+   debug("SF: write conf register timed out\n");
+   goto out;
+   }
+
+   ret = spi_flash_cmd(flash->spi, CMD_READ_STATUS, &stat, 1);
+   ret = spi_flash_cmd(flash->spi, CMD_READ_CONFIG, &con, 1);
+   if (ret < 0) {
+   debug("%s: SF: read CR failed\n", __func__);
+   goto out;
+   }
+   debug("%s: *** CR = %x\n", __func__, con);
+
+   ret = spi_flash_cmd_write_disable(flash);
+   if (ret < 0) {
+   debug("SF: disabling write failed\n");
+   goto out;
+   }
+out:
+   return ret;
+}
+
 #ifdef CONFIG_OF_CONTROL
 int spi_flash_decode_fdt(const void *blob, struct spi_flash *flash)
 {
@@ -464,6 +564,10 @@ struct spi_flash *spi_flash_probe(unsigned int bus, 
unsigned int cs,
goto err_manuf

[U-Boot] [PATCH 7/7] README: qspi usecase and testing documentation.

[Sourav Poddar]

Contains documentation and testing details for qspi flash
interface.

Signed-off-by: Sourav Poddar 
---
 doc/README.ti_qspi_dra_test |   38 ++
 doc/README.ti_qspi_flash|   47 +++
 2 files changed, 85 insertions(+), 0 deletions(-)
 create mode 100644 doc/README.ti_qspi_dra_test
 create mode 100644 doc/README.ti_qspi_flash

diff --git a/doc/README.ti_qspi_dra_test b/doc/README.ti_qspi_dra_test
new file mode 100644
index 000..8910ff1
--- /dev/null
+++ b/doc/README.ti_qspi_dra_test
@@ -0,0 +1,38 @@
+-
+   Simple steps used to test the QSPI at U-Boot
+-
+
+For #1, build the patched U-Boot and load MLO/u-boot.img
+
+--
+Boot from another medium like MMC
+--
+
+DRA752 EVM # mmc dev 0
+DRA752 EVM # fatload mmc 0 0x8200 MLO
+DRA752 EVM # fatload mmc 0 0x8200 u-boot.img
+
+--
+Commands to erase/write u-boot/mlo to flash device
+--
+
+DRA752 EVM # sf probe 0
+[should detect the S25FL256S serial flash device]
+
+DRA752 EVM # sf erase 0 1
+DRA752 EVM # sf erase 1 1
+DRA752 EVM # sf erase 2 1
+DRA752 EVM # sf erase 3 1
+DRA752 EVM # sf erase 4 1
+DRA752 EVM # sf erase 5 1
+DRA752 EVM # sf erase 6 1
+
+DRA752 EVM # sf write 8200 0 1
+DRA752 EVM # sf write 8300 2 8
+
+For #2, set sysboot to QSPI-1 boot mode(SYSBOOT[5:0] = 100110) and power
+on. ROM should find the GP header at offset 0 and load/execute SPL. SPL
+then detects that ROM was in QSPI-1 mode (boot code 10) and attempts to
+find a U-Boot image header at offset 0x2 (set in the config file)
+and proceeds to load that image using the U-Boot image payload offset/size
+from the header. It will then start U-Boot.
diff --git a/doc/README.ti_qspi_flash b/doc/README.ti_qspi_flash
new file mode 100644
index 000..f6be13b
--- /dev/null
+++ b/doc/README.ti_qspi_flash
@@ -0,0 +1,47 @@
+QSPI U-boot support
+--
+
+Host processor is connected to serial flash device via qpsi
+interface. QSPI is a kind of spi module that allows single,
+dual and quad read access to external spi devices. The module
+has a memory mapped interface which provide direct interface
+for accessing data form external spi devices.
+
+The one QSPI in the device is primarily intended for fast booting
+from Quad SPI flash devices.
+
+Usecase1
+---
+
+MLO/u-boot.img will be flashed from SD/MMC to the flash device
+using serial flash erase and write commands. Then, switch settings
+will be changed to qspi boot. Then, the ROM code will read MLO
+from the predefined location in the flash, where it was flashed and
+execute it after storing it in SDRAM. Then, the MLO will read
+u-boot.img from flash and execute it from SDRAM.
+
+SPI mode
+---
+SPI mode uses mtd spi framework for transfer and reception of data.
+Can be used in:
+1. Normal mode: use single pin for transfers
+2. Dual Mode: use two pins for transfers.
+3. Quad mode: use four pin for transfer
+
+Memory mapped read mode
+---
+In this, SPI controller is configured using configuration port and then
+controler is switched to memory mapped port for data read.
+
+Driver
+--
+drivers/qspi/ti_qspi.c
+- Newly created file which is responsible for configuring the
+   qspi controller and also for providing the low level api which
+   is responsible for transferring the datas from host controller
+   to flash device and vice versa.
+
+Testing
+---
+A seperated file named README.dra_qspi_test has been created which gives all 
the
+details about the commands required to test qspi at u-boot level.
-- 
1.7.1

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

Re: [U-Boot] net, phy: wrong 1000BASE detection with a lan9303 switch

[Heiko Schocher]

Hello Wolfgang,

Am 10.07.2013 13:15, schrieb Wolfgang Denk:

Dear Heiko,

In message<51dd3d92.8050...@denx.de>  you wrote:


Would this be an acceptable patch for it:

...

@@ -300,6 +300,10 @@ int genphy_parse_link(struct phy_device *phydev)
   * both PHYs in the link
   */
  gblpa = phy_read(phydev, MDIO_DEVAD_NONE, 
MII_STAT1000);
+   if (gblpa<  0) {
+   printf ("Could not read MII_STAT1000. Ignoring 
gigabit capability\n");
+   gblpa = 0;
+   }
  gblpa&= phy_read(phydev,
  MDIO_DEVAD_NONE, MII_CTRL1000)<<  2;


Well, this other phy_read() probably needs exactly the same error
handling - and I doubt if we should actually try riding the reg when
the first one failed already?


Yes, you are right. The first question is, if such a patch is the
right way for fixing it, or if there is a better way ...

bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V2 1/1] EXYNOS: Resolve the i2c compilation error for

[Minkyu Kang]

On 10/07/13 14:12, amar_g wrote:
> This patch resolves the below mentioned compilation error of i2c driver 
> for non-FDT case
> 
> Compilation error:
> s3c24x0_i2c.c: In function 'board_i2c_init':
> s3c24x0_i2c.c:544:18: error: 'CONFIG_MAX_I2C_NUM' undeclared (first use
> in this function) s3c24x0_i2c.c:544:18: note: each undeclared
> identifier is reported only once for each function it appears in
> s3c24x0_i2c.c:545:3: warning: implicit declaration of function
> 
> Signed-off-by: Rajeshwari Shinde 
> Signed-off-by: Amar 
> ---
> Changes since V0:
>   1) Updated the below in response to review comments
>   a) Added the prefix 'EXYNOS' to title of the patch.
> 
> Changes since V1:
>   1) Updated the below in response to review comments
>   a) Limited info on "Compilation error" message for 5 lines.
>   b) Changed the spelling of 'mentiond' to 'mentioned'.
> 
>  board/samsung/smdk5250/smdk5250.c |   10 ++
>  drivers/i2c/s3c24x0_i2c.c |9 +
>  2 files changed, 11 insertions(+), 8 deletions(-)
> 

applied to u-boot-samsung.

Thanks,
Minkyu Kang.

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

Re: [U-Boot] Separately compile Master boot loader

[Albert ARIBAUD]

Hi Rajdeep,

On Wed, 10 Jul 2013 15:04:12 +0530, Rajdeep Vaghasia
 wrote:

> Waiting for a reply.

Well, maybe if you had not e-mailed your 8:32 AM answer to me but to
the list... :)

Here it is, with my comments.

> On Tue, Jul 9, 2013 at 5:31 PM, Albert ARIBAUD 
> wrote:
> 
> > Hi Rajdeep,
> >
> > On Tue, 9 Jul 2013 16:12:14 +0530, Rajdeep Vaghasia
> >  wrote:
> >
> > > Hi
> > > I am working on one board with an arm11 based cpu, NOR flash and DDR2
> > SDRAM.
> > > When I compile u-boot source code, I get u-boot.bin image generated.
> > > This image has primary(second stage) and secondary(third stage)
> > bootloader
> > > combined.
> > >
> > > I have following queries:
> > > 1) The question that still eats me everyday is, How can I compile
> > > primary(Master) boot loader and secondary boot loader separately?
> > > 2) I want to Flash only initial 4kb of code (Master boot loader or second
> > > stage). The remaining code I want to keep at another partition in the
> > > Flash. How can I achieve this?
> > > 3) Is there any separate code available for Master boot loader, which
> > > copies the third stage bootloader to SDRAM and then transfers control to
> > > that third stage boot loader(u-boot)?
> > >
> > > I am unable to find a way to do this.
> > >
> > > Can anyone help me please?
> >
> > Since you do not indicate exactly which target you're building, I'll
> > assume it is one with SPL (what you describe as master or second stage,
> > with third stage being u-boot itself).
> >
> > I don't know of a way to build SPL alone.
> >
> > As for building separate U-Boot and SPL, you'll find them in ELF format
> > in file ./u-boot and ./spl/u-boot-spl. You can then use
> > $(CROSS_COMPILE)objcopy to convert from ELF to .bin.
> >
> > Note that your target may need a specific format different from the
> > pure binary that objcopy can produce.
> >
> > Can you tell us more about your target?
> >
> > Amicalement,
> > --
> > Albert.
> >
> 
> Sorry, My target board is not with SPL.

Then your question does not make sense, since a target without SPL has
no "second" and "third" stage, only a single standalone U-Boot stage.

> According to my understanding, SPL is required when we want to use NAND or
> oneNAND flash. And even in that case, the image generated, is combined of
> u-boot.bin+nand_driver.

This is quite reductive and partly wrong. 

SPL is required when you cannot directly boot into U-boot, one of the
cases being when you boot from NAND as it usually only allows very small
binaries; but NAND is far from the only case where SPL is needed or
useful.

Also, as I said, the image generated in the SPL case is not "u-boot +
NAND driver", it is "complete SPL + complete U-Boot" (although you can
have them separate as I explained), and the "complete SPL" part is not
itself an "U-Boot plus NAND driver".

> I am using NOR flash.

Ok.

> Actually, I am building firmware upgrade procedure.
> For that I need 3 partitions for u-boot.
> One with master u-boot.
> Other two with u-boot-1 and u-boot-2. (One contains current working u-boot,
> whereas another is with upgraded u-boot code).
> For that I need one Master uboot which contains code that initializes the
> SDRAM, choses one of the 2 secondary u-boot with the help of an environment
> variable (Or fixed jump to the start address of u-boot-1 or u-boot-2) and
> then copies u-boot(Secondary boot loader) to SDRAM and executes it from
> there.

Ok, so "secondary" is a concept specific to your design. No wonder I
could not understand it properly until you explained.

> These steps of initializing SDRAM and copying of u-boot code there, are
> already implemented in u-boot code. I just want to separate it from the
> main source code and want to generate binary of that much code only.
> 
> Is there any way to achieve this?

Several; and then there is an infinity of other possible approaches,
depending, not on *what* you want to do, but on *why* you want to do
it. Can you give more details on why your firmware upgrade procedure
needs to boot two different U-Boots  ?

> or
> Is there any resource of information available which can help me to
> understand this?

The source code and the Denx website, at this point; once you explain
the goal you are trying to reach, people on the list might point you
to more specific resources.

> Rajdeep.

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

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

[Minkyu Kang]

Dear Albert,

The following changes since commit 7737c994609ffb50194d5ddb67467ae0fcd8f775:

  net2big_v2: initialize LEDs at startup (2013-06-20 14:01:23 +0530)

are available in the git repository at:

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

for you to fetch changes up to 1ae76d438b602fe8be1f0ef8b8ce47c89d371047:

  EXYNOS: Resolve the i2c compilation error (2013-07-10 14:20:26 +0900)


Ajay Kumar (1):
  video: exynos_fb: Add the missing #else clause

Amar (2):
  EXYNOS5: I2C: Add FDT and non-FDT support for I2C
  EXYNOS: Resolve the i2c compilation error

Axel Lin (2):
  gpio: s3c2440_gpio: Fix wrong writel arguments
  gpio: s5p_gpio: Call s5p_gpio_set_value() instead of open-code

Bernie Thompson (1):
  exynos: Adjust the starting MIF voltage to 1.05v

Minkyu Kang (1):
  arm: exynos: fix clock calculation

Rajeshwari Shinde (9):
  EXYNOS5: FDT: Add compatible strings for Serial
  EXYNOS5: FDT: Add serial device node values
  S5P: Serial: Add fdt support to driver
  CONFIG: EXYNOS5: Enable silent console
  SMDK5250: Remove reduntant code
  EXYNOS: Add API for power reset and exit wakeup
  EXYNOS: LDS file move to common
  EXYNOS4210: Configure GPIO for uart
  EXYNOS: Move files from board/samsung to arch/arm

Simon Glass (1):
  exynos: Enable mmc for snow

Łukasz Majewski (2):
  arm:trats: Increase malloc pool size (for DFU ext4 transfers)
  power:bat:trats: Break battery charging with ctrl+C

 arch/arm/cpu/armv7/exynos/Makefile |   17 +-
 arch/arm/cpu/armv7/exynos/clock.c  |   43 +-
 .../arm/cpu/armv7/exynos}/clock_init.h |0
 arch/arm/cpu/armv7/exynos/clock_init_exynos4.c |   95 +
 .../arm/cpu/armv7/exynos/clock_init_exynos5.c  |   56 +--
 arch/arm/cpu/armv7/exynos/common_setup.h   |   45 +++
 .../arm/cpu/armv7/exynos}/dmc_common.c |7 +-
 .../arm/cpu/armv7/exynos}/dmc_init_ddr3.c  |   27 +-
 arch/arm/cpu/armv7/exynos/dmc_init_exynos4.c   |  213 ++
 .../arm/cpu/armv7/exynos/exynos4_setup.h   |  397 +-
 .../arm/cpu/armv7/exynos/exynos5_setup.h   |   28 +-
 arch/arm/cpu/armv7/exynos/lowlevel_init.c  |   73 
 arch/arm/cpu/armv7/exynos/pinmux.c |   40 ++
 arch/arm/cpu/armv7/exynos/power.c  |   50 +++
 .../arm/cpu/armv7/exynos}/spl_boot.c   |   84 +++-
 arch/arm/dts/exynos5250.dtsi   |   27 ++
 arch/arm/include/asm/arch-exynos/cpu.h |   13 +-
 arch/arm/include/asm/arch-exynos/power.h   |   12 +
 arch/arm/include/asm/arch-exynos/spl.h |1 +
 .../exynos-uboot-spl.lds}  |0
 board/samsung/dts/exynos5250-smdk5250.dts  |2 +
 board/samsung/dts/exynos5250-snow.dts  |   26 ++
 board/samsung/origen/Makefile  |   11 +-
 board/samsung/origen/lowlevel_init.S   |  357 -
 board/samsung/origen/mem_setup.S   |  421 
 board/samsung/origen/mmc_boot.c|   58 ---
 board/samsung/origen/origen.c  |   46 +++
 board/samsung/smdk5250/Makefile|   14 +-
 board/samsung/smdk5250/smdk5250.c  |   12 +-
 board/samsung/smdkv310/Makefile|   10 +-
 board/samsung/smdkv310/lowlevel_init.S |  414 ---
 board/samsung/smdkv310/mem_setup.S |  365 -
 board/samsung/smdkv310/mmc_boot.c  |   60 ---
 board/samsung/smdkv310/smdkv310.c  |   46 +++
 drivers/gpio/s3c2440_gpio.c|6 +-
 drivers/gpio/s5p_gpio.c|9 +-
 drivers/i2c/s3c24x0_i2c.c  |3 +-
 drivers/power/battery/bat_trats.c  |   13 +-
 drivers/power/power_core.c |3 +-
 drivers/serial/serial_s5p.c|   78 
 drivers/video/exynos_fimd.c|3 +-
 include/configs/exynos5250-dt.h|   12 +-
 include/configs/origen.h   |9 +-
 include/configs/smdkv310.h |8 +-
 include/configs/trats.h|2 +-
 include/fdtdec.h   |1 +
 include/power/max77686_pmic.h  |2 +
 lib/fdtdec.c   |1 +
 48 files changed, 1194 insertions(+), 2026 deletions(-)
 rename {board/samsung/smdk5250 => arch/arm/cpu/armv7/exynos}/clock_init.h 
(100%)
 create mode 100644 arch/arm/cpu/armv7/exynos/clock_init_exynos4.c
 rename board/samsung/smdk5250/clock_init.c => 
arch/arm/cpu/armv7/exynos/clock_init_exynos5.c (94%)
 create mode 100644 arch/arm/cpu/armv7/exynos/common_setup.h

Re: [U-Boot] [RFC PATCH] arm: arm926ejs: flush cache before disable it

[Albert ARIBAUD]

Hi Sughosh,

On Wed, 10 Jul 2013 15:35:10 +0530, Sughosh Ganu
 wrote:

> hi Albert,
> 
> On Tue Jul 09, 2013 at 10:28:13AM +0200, Albert ARIBAUD wrote:
> 
> > > > The arm926ej-s data cache does not have a single fixed policy, and
> > > > does not have a bypass-on-write policy, only write-through and
> > > > copy-back.
> > > > 
> > > > Other, more complex, policies may be defined, but at the MMU, not cache,
> > > > level, and those are not constant for all arm926ej-s based SoCs; not
> > > > even constant for a given SoC as they are configurable at run-time to
> > > > fit the chosen system addressing map.
> > > 
> > > Can you please elucidate on these policies. Based on my reading of the
> > > arm developers manual and the arm926ejs trm, the mmu makes a
> > > particular region cacheable and/or write bufferable. I did not find
> > > mention of any other  policies. Maybe pointers or links to the
> > > documents would help.
> > 
> > You are correct re the other policies of the DDI0198E (ARM926EJ-S
> > TRM) MMU -- page 3-11, bits 3-2 of the section descriptor. Note however
> > that you may have to refer to your specific SoC's TRM or equivalent, as
> > the SoC designer may have defined its own system-level cache and MMU
> > architecture.
> > 
> > Note in any case that none of the policies mentioned in DDI0198E is
> > described as read-allocate (let alone "read-allocate only" where writes
> > would bypass the enabled cache); on the contrary, the only cache
> > policies mentioned are write-through and write-back, both of which
> > contradict cache bypass on write.
> 
> I was referring to the cache allocation policy mentioned in section
> 4.1 in the DDI0198E document -- this is also mentioned in table 12.1
> in chapter 12 of the arm developers guide.

Can you please quote the exact part of 4.1 which describes the cache
policy and then explain what you think it means exactly?

> -sughosh

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

Re: [U-Boot] Pull request: u-boot-video/master (updated)

[Tom Rini]

On Mon, Jul 08, 2013 at 09:19:08PM +0200, Anatolij Gustschin wrote:

> Hey Tom,
> 
> here is an updated pull request, please pull. Thanks!
> 
> Anatolij
> 
> The following changes since commit e6bf18dba2a21bebf2c421b1c2e188225f6485a1:
> 
>   Prepare v2013.07-rc2 (2013-06-28 18:03:51 -0400)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-video.git master
> 
> for you to fetch changes up to ff8fb56b6f7edafc1bcba8ef008b3f368cabe60d:
> 
>   video: consolidate splash screen alignment code (2013-07-08 20:21:24 +0200)
> 
> 
> Anatolij Gustschin (1):
>   video: consolidate splash screen alignment code
> 
> Piotr Wilczek (2):
>   drivers:video:s6e8ax0: change data_to_send array to static
>   lcd: align bmp header when uncopmressing image
> 
> Robert Winkler (3):
>   video: lcd: Add CONFIG_SPLASH_SCREEN_PREPARE support to CONFIG_VIDEO
>   video: lcd: Make splash_screen_prepare weak, remove config macro
>   omap: cm_t35: Fix cm_t35 for weak splash_screen_prepare
> 
> Stephen Warren (1):
>   lcd: remove unaligned access in lcd_dt_simplefb_configure_node()
> 
>  README |8 --
>  board/compulab/cm_t35/cm_t35.c |2 +-
>  common/Makefile|1 +
>  common/cmd_bmp.c   |   45 ++--
>  common/lcd.c   |   41 ++---
>  common/splash.c|   56 
> 
>  doc/README.splashprepare   |8 ++
>  drivers/video/cfb_console.c|   29 -
>  drivers/video/s6e8ax0.c|   26 +--
>  include/configs/cm_t35.h   |1 -
>  include/lcd.h  |4 +--
>  include/splash.h   |   36 ++
>  12 files changed, 161 insertions(+), 96 deletions(-)
>  create mode 100644 common/splash.c
>  create mode 100644 doc/README.splashprepare
>  create mode 100644 include/splash.h

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH v3 3/7] ARM: add assembly routine to switch to non-secure state

[Nikolay Nikolaev]

Hello Andre,


On Wed, Jul 10, 2013 at 2:54 AM, Andre Przywara
wrote:

> While actually switching to non-secure state is one thing, another
> part of this process is to make sure that we still have full access
> to the interrupt controller (GIC).
> The GIC is fully aware of secure vs. non-secure state, some
> registers are banked, others may be configured to be accessible from
> secure state only.
> To be as generic as possible, we get the GIC memory mapped address
> based on the PERIPHBASE value in the CBAR register. Since this
> register is not architecturally defined, we check the MIDR before to
> be from an A15 or A7.
> For CPUs not having the CBAR or boards with wrong information herein
> we allow providing the base address as a configuration variable.
>
> Now that we know the GIC address, we:
> a) allow private interrupts to be delivered to the core
>(GICD_IGROUPR0 = 0x)
> b) enable the CPU interface (GICC_CTLR[0] = 1)
> c) set the priority filter to allow non-secure interrupts
>(GICC_PMR = 0xFF)
>
> Also we allow access to all coprocessor interfaces from non-secure
> state by writing the appropriate bits in the NSACR register.
>
> The generic timer base frequency register is only accessible from
> secure state, so we have to program it now. Actually this should be
> done from primary firmware before, but some boards seems to omit
> this, so if needed we do this here with a board specific value.
> The Versatile Express board does not need this, so we remove the
> frequency from the configuration file here.
>
> After having switched to non-secure state, we also enable the
> non-secure GIC CPU interface, since this register is banked.
>
> Since we need to call this routine also directly from the smp_pen
> later (where we don't have any stack), we can only use caller saved
> registers r0-r3 and r12 to not mess with the compiler.
>
> Signed-off-by: Andre Przywara 
> ---
>  arch/arm/cpu/armv7/nonsec_virt.S| 85
> +
>  arch/arm/include/asm/armv7.h| 18 
>  arch/arm/include/asm/gic.h  | 17 
>  include/configs/vexpress_ca15_tc2.h |  2 -
>  4 files changed, 120 insertions(+), 2 deletions(-)
>  create mode 100644 arch/arm/include/asm/gic.h
>
> diff --git a/arch/arm/cpu/armv7/nonsec_virt.S
> b/arch/arm/cpu/armv7/nonsec_virt.S
> index 68a6b38..e9ee831 100644
> --- a/arch/arm/cpu/armv7/nonsec_virt.S
> +++ b/arch/arm/cpu/armv7/nonsec_virt.S
> @@ -23,6 +23,11 @@
>   */
>
>  #include 
> +#include 
> +#include 
> +#include 
> +
> +.arch_extension sec
>
>  /* the vector table for secure state */
>  _monitor_vectors:
> @@ -52,3 +57,83 @@ _secure_monitor:
>
> movspc, lr  @ return to non-secure SVC
>
> +/*
> + * Switch a core to non-secure state.
> + *
> + *  1. initialize the GIC per-core interface
> + *  2. allow coprocessor access in non-secure modes
> + *  3. switch the cpu mode (by calling "smc #0")
> + *
> + * Called from smp_pen by secondary cores and directly by the BSP.
> + * Do not assume that the stack is available and only use registers
> + * r0-r3 and r12.
> + *
> + * PERIPHBASE is used to get the GIC address. This could be 40 bits long,
> + * though, but we check this in C before calling this function.
> + */
> +ENTRY(_nonsec_init)
> +#ifdef CONFIG_ARM_GIC_BASE_ADDRESS
> +   ldr r2, =CONFIG_ARM_GIC_BASE_ADDRESS
> +#else
> +   mrc p15, 4, r2, c15, c0, 0  @ read CBAR
>
PERIPHBASE[39:32] is CBAR[7:0] which we ignore here - OK.
PERIPHBASE[31:15] is CBAR[31:15] - OK
The rest of the bits is UNK/SBZP - we should not rely they are 0s.

I'd suggest to mask r2 with 0x8000 here (figure out some name like
PERIPHBASE_MASK)


> +#endif
> +   add r3, r2, #GIC_DIST_OFFSET@ GIC dist i/f offset
> +   mvn r1, #0  @ all bits to 1
> +   str r1, [r3, #GICD_IGROUPRn]@ allow private interrupts
> +
> +   mrc p15, 0, r0, c0, c0, 0   @ read MIDR
> +   ldr r1, =MIDR_PRIMARY_PART_MASK
> +   and r0, r0, r1  @ mask out variant and
> revision
> +
> +   ldr r1, =MIDR_CORTEX_A7_R0P0 & MIDR_PRIMARY_PART_MASK
> +   cmp r0, r1  @ check for Cortex-A7
> +
> +   ldr r1, =MIDR_CORTEX_A15_R0P0 & MIDR_PRIMARY_PART_MASK
> +   cmpne   r0, r1  @ check for Cortex-A15
> +
> +   movne   r1, #GIC_CPU_OFFSET_A9  @ GIC CPU offset for A9
> +   moveq   r1, #GIC_CPU_OFFSET_A15 @ GIC CPU offset for A15/A7
> +   add r3, r2, r1  @ r3 = GIC CPU i/f addr
> +
> +   mov r1, #1  @ set GICC_CTLR[enable]
> +   str r1, [r3, #GICC_CTLR]@ and clear all other bits
> +   mov r1, #0xff
> +   str r1, [r3, #GICC_PMR] @ set priority mask
> register
> +
> +   movwr1, #0x3fff
> +   movtr1, #0x0006
> +

Re: [U-Boot] [PATCH v3 4/7] ARM: switch to non-secure state during bootm execution

[Nikolay Nikolaev]

Hello Andre,


On Wed, Jul 10, 2013 at 2:54 AM, Andre Przywara
wrote:

> To actually trigger the non-secure switch we just implemented, call
> the switching routine from within the bootm command implementation.
> This way we automatically enable this feature without further user
> intervention.
>
> The core specific part of the work is done in the assembly routine
> in nonsec_virt.S, introduced with the previous patch, but for the full
> glory we need to setup the GIC distributor interface once for the
> whole system, which is done in C here.
> The routine is placed in arch/arm/cpu/armv7 to allow easy access from
> other ARMv7 boards.
>
> We check the availability of the security extensions first.
>
> Since we need a safe way to access the GIC, we use the PERIPHBASE
> registers on Cortex-A15 and A7 CPUs and do some sanity checks.
> Board not implementing the CBAR can override this value via a
> configuration file variable.
>
> Then we actually do the GIC enablement:
> a) enable the GIC distributor, both for non-secure and secure state
>(GICD_CTLR[1:0] = 11b)
> b) allow all interrupts to be handled from non-secure state
>(GICD_IGROUPRn = 0x)
>
> The core specific GIC setup is then done in the assembly routine.
>
> The actual bootm trigger is pretty small: calling the routine and
> doing some error reporting.
>
> Signed-off-by: Andre Przywara 
> ---
>  arch/arm/cpu/armv7/Makefile  |   1 +
>  arch/arm/cpu/armv7/virt-v7.c | 117
> +++
>  arch/arm/include/asm/armv7.h |  10 
>  arch/arm/lib/bootm.c |  28 +++
>  4 files changed, 156 insertions(+)
>  create mode 100644 arch/arm/cpu/armv7/virt-v7.c
>
> diff --git a/arch/arm/cpu/armv7/Makefile b/arch/arm/cpu/armv7/Makefile
> index 5d75077..b59f59e 100644
> --- a/arch/arm/cpu/armv7/Makefile
> +++ b/arch/arm/cpu/armv7/Makefile
> @@ -38,6 +38,7 @@ endif
>
>  ifneq ($(CONFIG_ARMV7_NONSEC),)
>  SOBJS   += nonsec_virt.o
> +COBJS  += virt-v7.o
>  endif
>
>  SRCS   := $(START:.o=.S) $(COBJS:.o=.c)
> diff --git a/arch/arm/cpu/armv7/virt-v7.c b/arch/arm/cpu/armv7/virt-v7.c
> new file mode 100644
> index 000..54f9746
> --- /dev/null
> +++ b/arch/arm/cpu/armv7/virt-v7.c
> @@ -0,0 +1,117 @@
> +/*
> + * (C) Copyright 2013
> + * Andre Przywara, Linaro
> + *
> + * Routines to transition ARMv7 processors from secure into non-secure
> state
> + * needed to enable ARMv7 virtualization for current hypervisors
> + *
> + * See file CREDITS for list of people who contributed to this
> + * project.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
> + * MA 02111-1307 USA
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +static unsigned int read_id_pfr1(void)
> +{
> +   unsigned int reg;
> +
> +   asm("mrc p15, 0, %0, c0, c1, 1\n" : "=r"(reg));
> +   return reg;
> +}
> +
> +static int get_gicd_base_address(unsigned int *gicdaddr)
> +{
> +#ifdef CONFIG_ARM_GIC_BASE_ADDRESS
> +   *gicdaddr = CONFIG_ARM_GIC_BASE_ADDRESS + GIC_DIST_OFFSET;
> +   return 0;
> +#else
> +   unsigned midr;
> +   unsigned periphbase;
> +
> +   /* check whether we are an Cortex-A15 or A7.
> +* The actual HYP switch should work with all CPUs supporting
> +* the virtualization extension, but we need the GIC address,
> +* which we know only for sure for those two CPUs.
> +*/
> +   asm("mrc p15, 0, %0, c0, c0, 0\n" : "=r"(midr));
> +   switch (midr & MIDR_PRIMARY_PART_MASK) {
> +   case MIDR_CORTEX_A9_R0P1:
> +   case MIDR_CORTEX_A15_R0P0:
> +   case MIDR_CORTEX_A7_R0P0:
> +   break;
> +   default:
> +   return NONSEC_ERR_NO_GIC_ADDRESS;
> +   }
> +
> +   /* get the GIC base address from the CBAR register */
> +   asm("mrc p15, 4, %0, c15, c0, 0\n" : "=r" (periphbase));
> +
> +   /* the PERIPHBASE can be mapped above 4 GB (lower 8 bits used to
> +* encode this). Bail out here since we cannot access this without
> +* enabling paging.
> +*/
> +   if ((periphbase & 0xff) != 0)
> +   return NONSEC_ERR_GIC_ADDRESS_ABOVE_4GB;
> +
> +   *gicdaddr = periphbase + GIC_DIST_OFFSET;
>

The same as in _nonsec_init

periphbase &= PERIPHBASE_MASK; // 0x8000


> +
> +   return 0;
> +#endif

Re: [U-Boot] [RFC][PATCH] arm: Fix flush_dcache_range() on arm926

[Albert ARIBAUD]

Hi Marek,

On Wed, 10 Jul 2013 02:30:29 +0200, Marek Vasut  wrote:

> The flush_dcache_range() on arm926 did not work as expected on i.MX28.
> 
> This can be observed during the operation of the FEC ethernet driver
> where the driver did occasionally fail with timeout trying to transmit
> a frame. The FEC ethernet driver uses DMA for transmitting the frame in
> the following fashion:
> 
> 0) Set bits in DMA descriptor
> 1) Write DMA descriptor into aligned DRAM address
> 2) Flush D-Cache over the descriptor
> 3) Start DMA
> 4) Invalidate D-Cache over the descriptor
> 5) Test if certain bits in DMA descriptor are unset
> 
> Very not so often it happened that the bits in the DMA descriptor were
> still set even after hardware register -- which is not cached -- indicated
> otherwise.
> 
> Here I will theoreticise, Albert, can you please correct me if I'm wrong?
> 
> This leads me to believe the DMA descriptor was still in the cacheline
> after being flushed in step 2) and during the DMA gets evicted into DRAM
> therefore corrupting the result of readback in 5) . By reading the ARM926
> datasheet DDI0198E_arm926ejs_r0p5_trm.pdf page 50 table 2-17, it is not
> clear whether cacheline that is Valid+Clean will be invalidated in the
> D-Cache using the "mcr p15, 0, , c7, c14, 1" instruction or whether
> only Valid+Dirty lines are cleaned+invalidated. The other thing that is
> unclear to me is whether a cacheline that is Valid+Clear is written back
> into DRAM when it is evicted from cache.

The way I see table 2-17, the "if valid and dirty" condition only
applies to the "write" part of the description, not to the "marked not
valid" one; this reading makes the most sense and is the most consistent
with the cache functioning as a whole.

As for a valid and clean (rather than "clear", I assume) line being
written if evicted, I think it is not. Eviction is not flushing: the
line is kicked out, plain and brutal. And even if we're talking about
flushing, if the line is clean then it is coherent with the RAM area
it caches, and writing it back there is unneeded.

> Interestingly enough, running invalidate_dcache_range() after doing the
> flush_dcache_range() over the descriptor solved the problem and I see no
> occasional timeout anymore. This confirms my opinion that the descriptor
> might remain in the cache and be written back during the DMA operation.

Can you point me to the source code location(s) where the sequence
above is implemented?

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

Re: [U-Boot] [PATCH v2 1/5] bootm: Handle errors consistently

[Tom Rini]

On Thu, Jul 04, 2013 at 01:17:07PM -0700, Simon Glass wrote:

> A recent bootm fix left the error path incomplete. Reinstate this so that
> failures in bootm stages are handled properly.
> 
> Signed-off-by: Simon Glass 
> ---
> Changes in v2:
> - Correct checking in the no-error case
> 
>  common/cmd_bootm.c | 6 +-
>  1 file changed, 1 insertion(+), 5 deletions(-)
> 
> diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
> index 02a5013..652513a 100644
> --- a/common/cmd_bootm.c
> +++ b/common/cmd_bootm.c
> @@ -684,12 +684,8 @@ static int do_bootm_states(cmd_tbl_t *cmdtp, int flag, 
> int argc,
>   if (!ret && (states & BOOTM_STATE_OS_GO)) {
>   ret = boot_selected_os(argc, argv, BOOTM_STATE_OS_GO,
>   images, boot_fn);
> - if (ret)
> - goto err;
>   }
>  
> - return ret;
> -
>   /* Deal with any fallout */
>  err:
>   if (iflag)
> @@ -699,7 +695,7 @@ err:
>   bootstage_error(BOOTSTAGE_ID_DECOMP_UNIMPL);
>   else if (ret == BOOTM_ERR_RESET)
>   do_reset(cmdtp, flag, argc, argv);
> - else
> + else if (ret)
>   puts("subcommand not supported\n");
>  
>   return ret;

Looking this part over again, BOOTM_STATE_OS_GO handles its own prints
when returning 1, so we don't want to do the "subcommand not supported"
part here (the other case is a BOOTM_ERR_RESET).  But, trace does need
to be covered and isn't by the "subcommand not supported" print.  I'll
make a v3 of this shortly 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 v2 2/5] bootm: Disable interrupts only when loading

[Tom Rini]

On Thu, Jul 04, 2013 at 01:26:08PM -0700, Simon Glass wrote:

> With the move of the interrupt code to earlier in the sequence, we
> exposed a problem where the interrupts are disabled at each bootm
> stage. This is not correct - it should be done only once. Let's disable
> interrupts in the LOAD stage. Put the code in a function for clarity.
> 
> Also, bootz lost its interrupt code altogether, so reinstate it.
> 
> Signed-off-by: Simon Glass 

This and 3, 4 and 5 have been applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH 1/2] cmd_bootm.c: Make bootz consume 'bootz' from argv, decrement argc

[Tom Rini]

On Tue, Jul 09, 2013 at 03:34:56PM -0400, Tom Rini wrote:

> Like 'bootm', 'bootz' needs to consume 'bootz' so that the rest of the
> state functions will work.
> 
> Signed-off-by: Tom Rini 

This and 2/2 have now been applied to u-boot/master.

-- 
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/7] omap5: add qspi support

[Nishanth Menon]

On Wed, Jul 10, 2013 at 6:25 AM, Sourav Poddar  wrote:
> From: Matt Porter 
>
> Add QSPI definitions and clock configuration support.
>

OMAP54xx does not have QSPI. DRA7 has QSPI?

> Signed-off-by: Matt Porter 
> Signed-off-by: Sourav Poddar 
> ---
>  arch/arm/cpu/armv7/omap5/hw_data.c |7 ++-
>  arch/arm/cpu/armv7/omap5/prcm-regs.c   |1 +
>  arch/arm/include/asm/arch-omap5/omap.h |3 +++
>  arch/arm/include/asm/arch-omap5/spl.h  |1 +
>  arch/arm/include/asm/omap_common.h |1 +
>  5 files changed, 12 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c 
> b/arch/arm/cpu/armv7/omap5/hw_data.c
> index 9374c6a..046ce44 100644
> --- a/arch/arm/cpu/armv7/omap5/hw_data.c
> +++ b/arch/arm/cpu/armv7/omap5/hw_data.c
> @@ -186,7 +186,7 @@ static const struct dpll_params 
> per_dpll_params_768mhz_es2[NUM_SYS_CLKS] = {
>
>  static const struct dpll_params per_dpll_params_768mhz_dra7xx[NUM_SYS_CLKS] 
> = {
> {32, 0, 4, 1, 3, 4, 10, 2, -1, -1, -1, -1}, /* 12 MHz   */
> -   {96, 4, 4, 1, 3, 4, 10, 2, -1, -1, -1, -1}, /* 20 MHz   */
> +   {96, 4, 4, 1, 3, 4, 4, 2, -1, -1, -1, -1},  /* 20 MHz   */

is this a separate fix?

> {160, 6, 4, 1, 3, 4, 10, 2, -1, -1, -1, -1},/* 16.8 MHz */
> {20, 0, 4, 1, 3, 4, 10, 2, -1, -1, -1, -1}, /* 19.2 MHz */
> {192, 12, 4, 1, 3, 4, 10, 2, -1, -1, -1, -1},   /* 26 MHz   */
> @@ -423,6 +423,7 @@ void enable_basic_clocks(void)
> (*prcm)->cm_wkup_wdtimer2_clkctrl,
> (*prcm)->cm_l4per_uart3_clkctrl,
> (*prcm)->cm_l4per_i2c1_clkctrl,
> +   (*prcm)->cm_l4per_qspi_clkctrl,
> 0
> };
>
> @@ -451,6 +452,10 @@ void enable_basic_clocks(void)
>  clk_modules_explicit_en_essential,
>  1);
>
> +#ifdef CONFIG_TI_QSPI
> +   setbits_le32((*prcm)->cm_l4per_qspi_clkctrl, (1<<24));
> +#endif
> +
> /* Enable SCRM OPT clocks for PER and CORE dpll */
> setbits_le32((*prcm)->cm_wkupaon_scrm_clkctrl,
> OPTFCLKEN_SCRM_PER_MASK);
> diff --git a/arch/arm/cpu/armv7/omap5/prcm-regs.c 
> b/arch/arm/cpu/armv7/omap5/prcm-regs.c
> index 331117c..debc56b 100644
> --- a/arch/arm/cpu/armv7/omap5/prcm-regs.c
> +++ b/arch/arm/cpu/armv7/omap5/prcm-regs.c
> @@ -926,6 +926,7 @@ struct prcm_regs const dra7xx_prcm = {
> .cm_l4per_gpio8_clkctrl = 0x4a009818,
> .cm_l4per_mmcsd3_clkctrl= 0x4a009820,
> .cm_l4per_mmcsd4_clkctrl= 0x4a009828,
> +   .cm_l4per_qspi_clkctrl  = 0x4a009838,
> .cm_l4per_uart1_clkctrl = 0x4a009840,
> .cm_l4per_uart2_clkctrl = 0x4a009848,
> .cm_l4per_uart3_clkctrl = 0x4a009850,
> diff --git a/arch/arm/include/asm/arch-omap5/omap.h 
> b/arch/arm/include/asm/arch-omap5/omap.h
> index e7d79fc..d2c4930 100644
> --- a/arch/arm/include/asm/arch-omap5/omap.h
> +++ b/arch/arm/include/asm/arch-omap5/omap.h
> @@ -67,6 +67,9 @@
>  /* GPMC */
>  #define OMAP54XX_GPMC_BASE 0x5000
>
> +/* QSPI */
> +#define QSPI_BASE  0x4B30
> +
>  /*
>   * Hardware Register Details
>   */
> diff --git a/arch/arm/include/asm/arch-omap5/spl.h 
> b/arch/arm/include/asm/arch-omap5/spl.h
> index d4d353c..8905cb8 100644
> --- a/arch/arm/include/asm/arch-omap5/spl.h
> +++ b/arch/arm/include/asm/arch-omap5/spl.h
> @@ -31,6 +31,7 @@
>  #define BOOT_DEVICE_MMC15
>  #define BOOT_DEVICE_MMC26
>  #define BOOT_DEVICE_MMC2_2 7
> +#define BOOT_DEVICE_SPI10

why not 8?

>
>  #define MMC_BOOT_DEVICES_START BOOT_DEVICE_MMC1
>  #define MMC_BOOT_DEVICES_END   BOOT_DEVICE_MMC2_2
> diff --git a/arch/arm/include/asm/omap_common.h 
> b/arch/arm/include/asm/omap_common.h
> index fa28358..c8d4619 100644
> --- a/arch/arm/include/asm/omap_common.h
> +++ b/arch/arm/include/asm/omap_common.h
> @@ -279,6 +279,7 @@ struct prcm_regs {
> u32 cm_l4per_mmcsd4_clkctrl;
> u32 cm_l4per_msprohg_clkctrl;
> u32 cm_l4per_slimbus2_clkctrl;
> +   u32 cm_l4per_qspi_clkctrl;
> u32 cm_l4per_uart1_clkctrl;
> u32 cm_l4per_uart2_clkctrl;
> u32 cm_l4per_uart3_clkctrl;
> --
> 1.7.1
>
> ___
> 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]mx6qsabresd: Add splash screen support via HDMI

[Stefano Babic]

Hi Pardeep,

On 09/07/2013 23:58, Pardeep Kumar Singla wrote:
> Signed-off-by: Pardeep Kumar Singla 
> ---
>  board/freescale/mx6qsabresd/mx6qsabresd.c |   92 
> -
>  include/configs/mx6qsabre_common.h|3 +-
>  include/configs/mx6qsabresd.h |   13 
>  3 files changed, 106 insertions(+), 2 deletions(-)
> 

Your patch shares a lot of code with mx6qsabrelite. Can we factorize the
common code ?

> diff --git a/board/freescale/mx6qsabresd/mx6qsabresd.c 
> b/board/freescale/mx6qsabresd/mx6qsabresd.c
> index 2529826..301fd1b 100644
> --- a/board/freescale/mx6qsabresd/mx6qsabresd.c
> +++ b/board/freescale/mx6qsabresd/mx6qsabresd.c
> @@ -31,6 +31,11 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
>  
>  DECLARE_GLOBAL_DATA_PTR;
>  
> @@ -133,6 +138,80 @@ static void setup_iomux_uart(void)
>   imx_iomux_v3_setup_multiple_pads(uart1_pads, ARRAY_SIZE(uart1_pads));
>  }
>  
> +#if defined(CONFIG_VIDEO_IPUV3)
> +static void enable_hdmi(void)
> +{
> + struct hdmi_regs *hdmi  = (struct hdmi_regs *)HDMI_ARB_BASE_ADDR;
> + u8 reg;
> + reg = readb(&hdmi->phy_conf0);
> + reg |= HDMI_PHY_CONF0_PDZ_MASK;
> + writeb(reg, &hdmi->phy_conf0);
> + udelay(3000);
> + reg |= HDMI_PHY_CONF0_ENTMDS_MASK;
> + writeb(reg, &hdmi->phy_conf0);
> + udelay(3000);
> + reg |= HDMI_PHY_CONF0_GEN2_TXPWRON_MASK;
> + writeb(reg, &hdmi->phy_conf0);
> + writeb(HDMI_MC_PHYRSTZ_ASSERT, &hdmi->mc_phyrstz);
> +}
> +

For example, enable:hdmi is really identical to the same function of the
sabrelite.

> +static struct fb_videomode const hdmi = {
> + .name   = "HDMI",
> + .refresh= 60,
> + .xres   = 1024,
> + .yres   = 768,
> + .pixclock   = 15385,
> + .left_margin= 220,
> + .right_margin   = 40,
> + .upper_margin   = 21,
> + .lower_margin   = 7,
> + .hsync_len  = 60,
> + .vsync_len  = 10,
> + .sync   = FB_SYNC_EXT,
> + .vmode  = FB_VMODE_NONINTERLACED
> +};
> +
> +int board_video_skip(void)
> +{
> + int ret;
> + ret = ipuv3_fb_init(&hdmi, 0, IPU_PIX_FMT_RGB24);
> + if (ret)
> + printf("HDMI cannot be configured: %d\n", ret);
> + enable_hdmi();
> + return ret;
> +}
> +
> +static void setup_display(void)
> +{
> + struct mxc_ccm_reg *mxc_ccm = (struct mxc_ccm_reg *)CCM_BASE_ADDR;
> + struct hdmi_regs *hdmi  = (struct hdmi_regs *)HDMI_ARB_BASE_ADDR;
> + int reg;
> +
> + /* Turn on IPU clock */
> + reg = readl(&mxc_ccm->CCGR3);
> + reg |= MXC_CCM_CCGR3_IPU1_IPU_DI0_OFFSET;
> + writel(reg, &mxc_ccm->CCGR3);
> + /* Turn on HDMI PHY clock */
> + reg = readl(&mxc_ccm->CCGR2);
> + reg |=  MXC_CCM_CCGR2_HDMI_TX_IAHBCLK_MASK|
> +  MXC_CCM_CCGR2_HDMI_TX_ISFRCLK_MASK;
> + writel(reg, &mxc_ccm->CCGR2);
> + /* clear HDMI PHY reset */
> + writeb(HDMI_MC_PHYRSTZ_DEASSERT, &hdmi->mc_phyrstz);
> + reg = readl(&mxc_ccm->chsccdr);
> + reg &= ~(MXC_CCM_CHSCCDR_IPU1_DI0_PRE_CLK_SEL_MASK|
> +  MXC_CCM_CHSCCDR_IPU1_DI0_PODF_MASK|
> +  MXC_CCM_CHSCCDR_IPU1_DI0_CLK_SEL_MASK);
> + reg |= (CHSCCDR_CLK_SEL_LDB_DI0
> +  << MXC_CCM_CHSCCDR_IPU1_DI0_CLK_SEL_OFFSET)|
> +  (CHSCCDR_PODF_DIVIDE_BY_3
> +  << MXC_CCM_CHSCCDR_IPU1_DI0_PODF_OFFSET)
> +  | (CHSCCDR_IPU_PRE_CLK_540M_PFD
> +  << MXC_CCM_CHSCCDR_IPU1_DI0_PRE_CLK_SEL_OFFSET);
> + writel(reg, &mxc_ccm->chsccdr);
> +}
> +#endif /* CONFIG_VIDEO_IPUV3 */

setup_display has also some common parts with the same function for
sabrelite. Any way to factorize code ?

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] video: Allocate the MXSFB framebuffer aligned

[Stefano Babic]

On 10/07/2013 02:52, Marek Vasut wrote:
> Allocate the framebuffer aligned so it can be flushed
> and the flush_dcache_range() function won't complain.
> 
> Signed-off-by: Marek Vasut 
> Cc: Anatolij Gustschin 
> Cc: Fabio Estevam 
> Cc: Otavio Salvador 
> Cc: Stefano Babic 
> ---
>  drivers/video/mxsfb.c |3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/video/mxsfb.c b/drivers/video/mxsfb.c
> index a6d8ae9..35836e1 100644
> --- a/drivers/video/mxsfb.c
> +++ b/drivers/video/mxsfb.c
> @@ -202,7 +202,8 @@ void *video_hw_init(void)
>   panel.memSize = mode.xres * mode.yres * panel.gdfBytesPP;
>  
>   /* Allocate framebuffer */
> - fb = malloc(panel.memSize);
> + fb = memalign(ARCH_DMA_MINALIGN,
> +   roundup(panel.memSize, ARCH_DMA_MINALIGN));
>   if (!fb) {
>   printf("MXSFB: Error allocating framebuffer!\n");
>   return NULL;
> 

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

[U-Boot] [PATCH v3] bootm: Handle errors consistently

[Tom Rini]

From: Simon Glass 

A recent bootm fix left the error path incomplete. If CONFIG_TRACE is
set it may still not be a supported command, so cover that with the
unsupported subcommand print.  Once we handle BOOTM_STATE_OS_GO, we can
just move into the error handler itself, no need for a goto there.

Signed-off-by: Simon Glass 
[trini: Update slightly based on Simon's changes to also cover
CONFIG_TRACE/BOOTM_STATE_FAKE_OS_GO]
Signed-off-by: Tom Rini 
---
 common/cmd_bootm.c |   21 -
 1 file changed, 8 insertions(+), 13 deletions(-)

diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index a783cea..6caa0e9 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -705,13 +705,6 @@ static int do_bootm_states(cmd_tbl_t *cmdtp, int flag, int 
argc,
if (!ret && (states & BOOTM_STATE_OS_PREP))
ret = boot_fn(BOOTM_STATE_OS_PREP, argc, argv, images);
 
-   /* Check for unsupported subcommand. */
-   if (ret) {
-   puts("subcommand not supported\n");
-   return ret;
-   }
-
-
 #ifdef CONFIG_TRACE
/* Pretend to run the OS, then run a user command */
if (!ret && (states & BOOTM_STATE_OS_FAKE_GO)) {
@@ -723,15 +716,17 @@ static int do_bootm_states(cmd_tbl_t *cmdtp, int flag, 
int argc,
ret = run_command_list(cmd_list, -1, flag);
}
 #endif
+
+   /* Check for unsupported subcommand. */
+   if (ret) {
+   puts("subcommand not supported\n");
+   return ret;
+   }
+
/* Now run the OS! We hope this doesn't return */
-   if (!ret && (states & BOOTM_STATE_OS_GO)) {
+   if (!ret && (states & BOOTM_STATE_OS_GO))
ret = boot_selected_os(argc, argv, BOOTM_STATE_OS_GO,
images, boot_fn);
-   if (ret)
-   goto err;
-   }
-
-   return ret;
 
/* Deal with any fallout */
 err:
-- 
1.7.9.5

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

Re: [U-Boot] [RFC][PATCH] arm: Fix flush_dcache_range() on arm926

[Marek Vasut]

Hi Albert,

> Hi Marek,
> 
> On Wed, 10 Jul 2013 02:30:29 +0200, Marek Vasut  wrote:
> > The flush_dcache_range() on arm926 did not work as expected on i.MX28.
> > 
> > This can be observed during the operation of the FEC ethernet driver
> > where the driver did occasionally fail with timeout trying to transmit
> > a frame. The FEC ethernet driver uses DMA for transmitting the frame in
> > the following fashion:
> > 
> > 0) Set bits in DMA descriptor
> > 1) Write DMA descriptor into aligned DRAM address
> > 2) Flush D-Cache over the descriptor
> > 3) Start DMA
> > 4) Invalidate D-Cache over the descriptor
> > 5) Test if certain bits in DMA descriptor are unset
> > 
> > Very not so often it happened that the bits in the DMA descriptor were
> > still set even after hardware register -- which is not cached --
> > indicated otherwise.
> > 
> > Here I will theoreticise, Albert, can you please correct me if I'm wrong?
> > 
> > This leads me to believe the DMA descriptor was still in the cacheline
> > after being flushed in step 2) and during the DMA gets evicted into DRAM
> > therefore corrupting the result of readback in 5) . By reading the ARM926
> > datasheet DDI0198E_arm926ejs_r0p5_trm.pdf page 50 table 2-17, it is not
> > clear whether cacheline that is Valid+Clean will be invalidated in the
> > D-Cache using the "mcr p15, 0, , c7, c14, 1" instruction or whether
> > only Valid+Dirty lines are cleaned+invalidated. The other thing that is
> > unclear to me is whether a cacheline that is Valid+Clear is written back
> > into DRAM when it is evicted from cache.
> 
> The way I see table 2-17, the "if valid and dirty" condition only
> applies to the "write" part of the description, not to the "marked not
> valid" one; this reading makes the most sense and is the most consistent
> with the cache functioning as a whole.

So basically all Valid+Dirty get cleaned .
Nothing is done on Valid+Clean .
Finally, as they are now all Valid+Clean , they all get Invalidated .

This is how it'd make the most sense, but I'm afraid this is not what I observe.

> As for a valid and clean (rather than "clear", I assume) line being
> written if evicted, I think it is not. Eviction is not flushing: the
> line is kicked out, plain and brutal. And even if we're talking about
> flushing, if the line is clean then it is coherent with the RAM area
> it caches, and writing it back there is unneeded.

Yes, this _does_ make full sense to me.

> > Interestingly enough, running invalidate_dcache_range() after doing the
> > flush_dcache_range() over the descriptor solved the problem and I see no
> > occasional timeout anymore. This confirms my opinion that the descriptor
> > might remain in the cache and be written back during the DMA operation.
> 
> Can you point me to the source code location(s) where the sequence
> above is implemented?

See:

 738 flush_dcache_range(addr, addr + size);

in drivers/net/fec_mxc.c . If I put invalidate_dcache_range(addr, addr + size); 
, all seems to work well. Note it also happens with multiple compilers, Debian 
gcc 4.8.0, ELDK 5.2 and ELDK 5.3 .


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

Re: [U-Boot] [PATCH 1/7] omap5: add qspi support

[Lokesh Vutla]

On Wednesday 10 July 2013 04:55 PM, Sourav Poddar wrote:
> From: Matt Porter 
> 
> Add QSPI definitions and clock configuration support.
> 
> Signed-off-by: Matt Porter 
> Signed-off-by: Sourav Poddar 
> ---
>  arch/arm/cpu/armv7/omap5/hw_data.c |7 ++-
>  arch/arm/cpu/armv7/omap5/prcm-regs.c   |1 +
>  arch/arm/include/asm/arch-omap5/omap.h |3 +++
>  arch/arm/include/asm/arch-omap5/spl.h  |1 +
>  arch/arm/include/asm/omap_common.h |1 +
>  5 files changed, 12 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c 
> b/arch/arm/cpu/armv7/omap5/hw_data.c
> index 9374c6a..046ce44 100644
> --- a/arch/arm/cpu/armv7/omap5/hw_data.c
> +++ b/arch/arm/cpu/armv7/omap5/hw_data.c
> @@ -186,7 +186,7 @@ static const struct dpll_params 
> per_dpll_params_768mhz_es2[NUM_SYS_CLKS] = {
>  
>  static const struct dpll_params per_dpll_params_768mhz_dra7xx[NUM_SYS_CLKS] 
> = {
>   {32, 0, 4, 1, 3, 4, 10, 2, -1, -1, -1, -1}, /* 12 MHz   */
> - {96, 4, 4, 1, 3, 4, 10, 2, -1, -1, -1, -1}, /* 20 MHz   */
> + {96, 4, 4, 1, 3, 4, 4, 2, -1, -1, -1, -1},  /* 20 MHz   */
>   {160, 6, 4, 1, 3, 4, 10, 2, -1, -1, -1, -1},/* 16.8 MHz */
>   {20, 0, 4, 1, 3, 4, 10, 2, -1, -1, -1, -1}, /* 19.2 MHz */
>   {192, 12, 4, 1, 3, 4, 10, 2, -1, -1, -1, -1},   /* 26 MHz   */
> @@ -423,6 +423,7 @@ void enable_basic_clocks(void)
>   (*prcm)->cm_wkup_wdtimer2_clkctrl,
>   (*prcm)->cm_l4per_uart3_clkctrl,
>   (*prcm)->cm_l4per_i2c1_clkctrl,
> + (*prcm)->cm_l4per_qspi_clkctrl,
Keep this also under CONFIG_TI_QSPI because we should enable QSPI clocks
only if support is available.

Thanks,
Lokesh
>   0
>   };
>  
> @@ -451,6 +452,10 @@ void enable_basic_clocks(void)
>clk_modules_explicit_en_essential,
>1);
>  
> +#ifdef CONFIG_TI_QSPI
> + setbits_le32((*prcm)->cm_l4per_qspi_clkctrl, (1<<24));
> +#endif
> +
>   /* Enable SCRM OPT clocks for PER and CORE dpll */
>   setbits_le32((*prcm)->cm_wkupaon_scrm_clkctrl,
>   OPTFCLKEN_SCRM_PER_MASK);
> diff --git a/arch/arm/cpu/armv7/omap5/prcm-regs.c 
> b/arch/arm/cpu/armv7/omap5/prcm-regs.c
> index 331117c..debc56b 100644
> --- a/arch/arm/cpu/armv7/omap5/prcm-regs.c
> +++ b/arch/arm/cpu/armv7/omap5/prcm-regs.c
> @@ -926,6 +926,7 @@ struct prcm_regs const dra7xx_prcm = {
>   .cm_l4per_gpio8_clkctrl = 0x4a009818,
>   .cm_l4per_mmcsd3_clkctrl= 0x4a009820,
>   .cm_l4per_mmcsd4_clkctrl= 0x4a009828,
> + .cm_l4per_qspi_clkctrl  = 0x4a009838,
>   .cm_l4per_uart1_clkctrl = 0x4a009840,
>   .cm_l4per_uart2_clkctrl = 0x4a009848,
>   .cm_l4per_uart3_clkctrl = 0x4a009850,
> diff --git a/arch/arm/include/asm/arch-omap5/omap.h 
> b/arch/arm/include/asm/arch-omap5/omap.h
> index e7d79fc..d2c4930 100644
> --- a/arch/arm/include/asm/arch-omap5/omap.h
> +++ b/arch/arm/include/asm/arch-omap5/omap.h
> @@ -67,6 +67,9 @@
>  /* GPMC */
>  #define OMAP54XX_GPMC_BASE   0x5000
>  
> +/* QSPI */
> +#define QSPI_BASE0x4B30
> +
>  /*
>   * Hardware Register Details
>   */
> diff --git a/arch/arm/include/asm/arch-omap5/spl.h 
> b/arch/arm/include/asm/arch-omap5/spl.h
> index d4d353c..8905cb8 100644
> --- a/arch/arm/include/asm/arch-omap5/spl.h
> +++ b/arch/arm/include/asm/arch-omap5/spl.h
> @@ -31,6 +31,7 @@
>  #define BOOT_DEVICE_MMC15
>  #define BOOT_DEVICE_MMC26
>  #define BOOT_DEVICE_MMC2_2   7
> +#define BOOT_DEVICE_SPI  10
>  
>  #define MMC_BOOT_DEVICES_START   BOOT_DEVICE_MMC1
>  #define MMC_BOOT_DEVICES_END BOOT_DEVICE_MMC2_2
> diff --git a/arch/arm/include/asm/omap_common.h 
> b/arch/arm/include/asm/omap_common.h
> index fa28358..c8d4619 100644
> --- a/arch/arm/include/asm/omap_common.h
> +++ b/arch/arm/include/asm/omap_common.h
> @@ -279,6 +279,7 @@ struct prcm_regs {
>   u32 cm_l4per_mmcsd4_clkctrl;
>   u32 cm_l4per_msprohg_clkctrl;
>   u32 cm_l4per_slimbus2_clkctrl;
> + u32 cm_l4per_qspi_clkctrl;
>   u32 cm_l4per_uart1_clkctrl;
>   u32 cm_l4per_uart2_clkctrl;
>   u32 cm_l4per_uart3_clkctrl;
> 

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

Re: [U-Boot] [PATCH 1/7] omap5: add qspi support

[Tom Rini]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/10/2013 09:23 AM, Nishanth Menon wrote:
> On Wed, Jul 10, 2013 at 6:25 AM, Sourav Poddar 
>  wrote:
>> From: Matt Porter 

I think it's good form to update folks addresses, Matt is now
matt.por...@linaro.org

>> Add QSPI definitions and clock configuration support.
[snip]
>> diff --git a/arch/arm/include/asm/arch-omap5/spl.h 
>> b/arch/arm/include/asm/arch-omap5/spl.h index d4d353c..8905cb8 
>> 100644 --- a/arch/arm/include/asm/arch-omap5/spl.h +++ 
>> b/arch/arm/include/asm/arch-omap5/spl.h @@ -31,6 +31,7 @@
>> #define BOOT_DEVICE_MMC15 #define BOOT_DEVICE_MMC2
>> 6 #define BOOT_DEVICE_MMC2_2 7 +#define BOOT_DEVICE_SPI 10
> 
> why not 8?

This is the value ROM passes when we boot here.  What I would like to
know is, is this really "SPI" or QSPI_1 or QSPI_4 ?  I suspect it's
QSPI_1.  And yes, we want to be precise here because while DRA7
doesn't have McSPI AM437x will, along with QSPI.

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

iQIcBAEBAgAGBQJR3WURAAoJENk4IS6UOR1W9aQP/jEBoyQKtU7n+B6aAMY5b5U4
FF54lAfRvJZfUaRVDCLmLMF+87Obx6ctQ95SogkKbsNmc5TxbDy7dBfd7G3++5ZG
ivYQcEv9MKi/kGgJ0UZejc2J4e+QbQbymvnVqHG2mKJnMjRSdeuQG7UUGGIRQeA7
/VwR4cZuNqVrcejlglrBrwxr5PdA1f/cMCr1Dp4PhiHzxG+YYbiS4EVmnT+GNXmL
RfZuy2TzjAir7brn4Y6sQ2fcHu2qXIzO6U/a16ZawfwB8089Zj4FMvP20IugsIyU
drZhaJ3jY+leTCW1Wq5BZ1s2IJ7eaIqW4kbCSif9sPqxqM1lwJdqFJAdY8eGUWD/
c7cpJxkyLvleK0WFZDVraljIXoY7SMiTpnjYU5M+ASV43s+fFSl3f0VnZLuQtkkW
+nFQeF1FdRDUd32jFDOzCuEeJbiPpy3mJLn60ND1r56VPQweroVBE3AetavzYDA0
K40Q3o/vXBLPyl2IELLOK5hpESWVlXasgMUOsNSfqpxGblh9ea5sXZ/Nvk8hjdmm
ViVXk5lqNvmZzYzu0znRmLEg3ucuyYif0IOh/IOb97mAjR8KX0iCavw42RI5ympb
E6d4is/Ap3x67BMBiEquRVWYmXv78Mr0o6LEhgayxM9rrT38uJyaGgIXlszia0xE
QIqgV1U808hJVFMMnAK+
=EY5D
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/7] dra7xx_evm: add SPL API, QSPI, and serial flash support

[Lokesh Vutla]

On Wednesday 10 July 2013 04:55 PM, Sourav Poddar wrote:
> From: Matt Porter 
> 
> Enables support for SPI SPL, QSPI and Spansion serial flash device
> on the EVM. Configures pin muxes for QSPI mode.
> 
> Signed-off-by: Matt Porter 
> Signed-off-by: Sourav Poddar 
> ---
>  board/ti/dra7xx/mux_data.h   |   10 ++
>  include/configs/dra7xx_evm.h |   22 ++
>  2 files changed, 32 insertions(+), 0 deletions(-)
> 
> diff --git a/board/ti/dra7xx/mux_data.h b/board/ti/dra7xx/mux_data.h
> index 338a241..2441c55 100644
> --- a/board/ti/dra7xx/mux_data.h
> +++ b/board/ti/dra7xx/mux_data.h
> @@ -53,5 +53,15 @@ const struct pad_conf_entry core_padconf_array_essential[] 
> = {
>   {UART1_RTSN, (IEN | PTU | PDIS | M3)},  /* UART1_RTSN */
>   {I2C1_SDA, (IEN | PTU | PDIS | M0)},/* I2C1_SDA */
>   {I2C1_SCL, (IEN | PTU | PDIS | M0)},/* I2C1_SCL */
> + {GPMC_A13, (IEN | PDIS | M1)},  /* QSPI1_RTCLK */
> + {GPMC_A14, (IEN | PDIS | M1)},  /* QSPI1_D[3] */
> + {GPMC_A15, (IEN | PDIS | M1)},  /* QSPI1_D[2] */
> + {GPMC_A16, (IEN | PDIS | M1)},  /* QSPI1_D[1] */
> + {GPMC_A17, (IEN | PDIS | M1)},  /* QSPI1_D[0] */
> + {GPMC_A18, (IEN | PDIS | M1)},  /* QSPI1_SCLK */
> + {GPMC_A3, (IEN | PDIS | M1)},   /* QSPI1_CS2 */
> + {GPMC_A4, (IEN | PDIS | M1)},   /* QSPI1_CS3 */
> + {GPMC_CS2, (IEN | PTU | PDIS | M1)},/* QSPI1_CS0 */
> + {GPMC_CS3, (IEN | PTU | PDIS | M1)},/* QSPI1_CS1*/
>  };
>  #endif /* _MUX_DATA_DRA7XX_H_ */
> diff --git a/include/configs/dra7xx_evm.h b/include/configs/dra7xx_evm.h
> index 6b37e1d..0583858 100644
> --- a/include/configs/dra7xx_evm.h
> +++ b/include/configs/dra7xx_evm.h
> @@ -46,4 +46,26 @@
>  #define NON_SECURE_SRAM_END  0x4038  /* Not inclusive */
>  
>  #define CONFIG_SYS_OMAP_ABE_SYSCK
> +#define CONFIG_SYS_DCACHE_OFF
> +#define CONFIG_SYS_ICACHE_OFF
Is it necessary to Disable caches to use QSPI?
If not please drop these two defines.
> +
> +#define EMIF1_EMIF2
This one too..

Thanks,
Lokesh
> +
> +/* SPI */
> +#define CONFIG_TI_QSPI
> +#define CONFIG_SPI_FLASH
> +#define CONFIG_SPI_FLASH_SPANSION
> +#define CONFIG_CMD_SF
> +#define CONFIG_CMD_SPI
> +#define CONFIG_SF_DEFAULT_SPEED  1200
> +#define CONFIG_DEFAULT_SPI_MODE  SPI_MODE_3
> +
> +/* SPI SPL */
> +#define CONFIG_SPL_SPI_SUPPORT
> +#define CONFIG_SPL_SPI_LOAD
> +#define CONFIG_SPL_SPI_FLASH_SUPPORT
> +#define CONFIG_SPL_SPI_BUS   0
> +#define CONFIG_SPL_SPI_CS0
> +#define CONFIG_SYS_SPI_U_BOOT_OFFS   0x2
> +
>  #endif /* __CONFIG_DRA7XX_EVM_H */
> 

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

Re: [U-Boot] twister: usb host support

[Stefano Babic]

Hi Jeroen,


On 09/07/2013 21:46, Jeroen Hofstee wrote:
> Hello Stefano,
> 
> The twister always had a fragile usb support in u-boot
> in the past. Since some floating patches mentioned
> alternating success after usb hub resets, I had a look
> if these patches fixed the twister as well, they don't.
> 
> Some fiddling around [1] makes the usb work however,
> by not attempting to reset the USB hub with gpio_25.
> I cannot find any document mentioning gpio_25 though.
> Any reason for this usage?

That is right. There is no written documentation by Technexion about
this pin. I have added in CC Tapani, maybe he can tell us something more.
The GPIO is used internally on the TAM3517 SOM, and we have no
schematics about it. We have to guess about its usage.

The reason to have it is that the sources for the kernel provided by
Technexion (an ancient 2.6.32 Version) set this pin to reset the EHCI.
As I said, there is no further documentation and rather we can only make
some supposition. The usage in U-Boot then reflects the usage made by
Technexion.


> p.s.
> I found by sheer accidence that the usb is behaving
> completely normal (after the patch) on rev B1. It is
> broken on rev B without the patch and working buggy
> with it. On rev B1 + patch the USB to SATA converter
> is discovered as well, which I have never seen before.
> 

I can confirm issues with version B of the TAM3517-SOM. I am testing a
B1 SOM with a B twister. I do not know the details about changelog
between B and B1 version of the SOM, but I got both USB and Ethernet
problems with TAM3517-B. The same image runs without the same problems
on a B1.

There is also this pending patch by Michael:

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

It is applied to u-boot-ti, not yet to mainline.

I have tested current mainline with Mihael's patch applied, and the
recognition of the USB storage seens reliable to me. No case with "0
device found".


> 
> === [1] patch to disable the usb reset
> 
> The change to port_mode[1] is not needed, but since it is unused,
> MODE_UNUSED seems appropriate.

Agree - as we do not use it, we can simply disable.

> diff --git a/board/technexion/twister/twister.c
> b/board/technexion/twister/twister.c
> index a28c704..31cf6c0 100644
> --- a/board/technexion/twister/twister.c
> +++ b/board/technexion/twister/twister.c
> @@ -63,7 +63,7 @@ static const u32 gpmc_XR16L2751[] = {
>  #ifdef CONFIG_USB_EHCI
>  static struct omap_usbhs_board_data usbhs_bdata = {
>  .port_mode[0] = OMAP_EHCI_PORT_MODE_PHY,
> -.port_mode[1] = OMAP_EHCI_PORT_MODE_PHY,
> +.port_mode[1] = OMAP_USBHS_PORT_MODE_UNUSED,
>  .port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
>  };
> 
> @@ -92,9 +92,6 @@ int board_init(void)
>  enable_gpmc_cs_config(gpmc_XR16L2751, &gpmc_cfg->cs[3],
>  XR16L2751_UART2_BASE, GPMC_SIZE_16M);
> 
> -gpio_request(CONFIG_OMAP_EHCI_PHY1_RESET_GPIO, "USB_PHY1_RESET");
> -gpio_direction_output(CONFIG_OMAP_EHCI_PHY1_RESET_GPIO, 1);
> -

See my concerns above. Do not reset the hub in the kernel ?

Best regards,
Stefano

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

Re: [U-Boot] [PATCH] OMAP5: USB_EHCI: Enable ehci support for omap5

[Dan Murphy]

Lokesh
On 07/08/2013 10:21 PM, Lokesh Vutla wrote:
> Hi Dan,
> On Tuesday 09 July 2013 02:29 AM, Dan Murphy wrote:
>> From: "Govindraj.R" 
>>
>> * Enable all usb ehci related clocks.
>> * Add ehci support to omap5 board file and arch specific
>>   sysc reg mask values.
>> * Enable config options for usb support and ethernet support
>>
>> Signed-off-by: Govindraj.R 
>> ---
>>  arch/arm/cpu/armv7/omap5/clocks.c|   20 +++---
>>  arch/arm/include/asm/arch-omap5/clocks.h |6 
>>  arch/arm/include/asm/arch-omap5/ehci.h   |   44 
>> ++
>>  board/ti/omap5_evm/evm.c |   33 ++
>>  include/configs/omap5_evm5430.h  |   23 ++--
>>  5 files changed, 120 insertions(+), 6 deletions(-)
>>  create mode 100644 arch/arm/include/asm/arch-omap5/ehci.h
> Is this based on current mainline?
> Most of the above files changed are not preset in mainline.

Honestly I have no idea how this patch got posted.

I will remove this patch in v2.
> 


-- 
--
Dan Murphy

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

Re: [U-Boot] [PATCH] OMAP5: USB_EHCI: Enable ehci support for omap5

[Dan Murphy]

Lokesh
On 07/08/2013 10:21 PM, Lokesh Vutla wrote:
> Hi Dan,
> On Tuesday 09 July 2013 02:29 AM, Dan Murphy wrote:
>> From: "Govindraj.R" 
>>
>> * Enable all usb ehci related clocks.
>> * Add ehci support to omap5 board file and arch specific
>>   sysc reg mask values.
>> * Enable config options for usb support and ethernet support
>>
>> Signed-off-by: Govindraj.R 
>> ---
>>  arch/arm/cpu/armv7/omap5/clocks.c|   20 +++---
>>  arch/arm/include/asm/arch-omap5/clocks.h |6 
>>  arch/arm/include/asm/arch-omap5/ehci.h   |   44 
>> ++
>>  board/ti/omap5_evm/evm.c |   33 ++
>>  include/configs/omap5_evm5430.h  |   23 ++--
>>  5 files changed, 120 insertions(+), 6 deletions(-)
>>  create mode 100644 arch/arm/include/asm/arch-omap5/ehci.h
> Is this based on current mainline?
> Most of the above files changed are not preset in mainline.

Honestly I have no idea how this patch got posted.

I will remove this patch in v2.
> 


-- 
--
Dan Murphy

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

Re: [U-Boot] [PATCH v5 1/1] NET: Improve TFTP booting performance when CONFIG_USB_KEYBOARD

[Stephen Warren]

On 07/09/2013 09:48 PM, Jim Lin wrote:
> On Tue, 2013-07-09 at 06:17 +0800, Joe Hershberger wrote:
>> Hi Jim and Stephen,
>>
>> On Wed, Jul 3, 2013 at 11:01 PM, Jim Lin  wrote:
>>> TFTP booting is slow when a USB keyboard is installed and
>>> CONFIG_USB_KEYBOARD is defined.
>>> This fix is to change Ctrl-C polling to every second when NET transfer
>>> is running.

>>> diff --git a/net/net.c b/net/net.c
>>> index df94789..ec88b02 100644
>>> --- a/net/net.c
>>> +++ b/net/net.c
>>> @@ -322,6 +322,11 @@ int NetLoop(enum proto_t protocol)
>>>  {
>>> bd_t *bd = gd->bd;
>>> int ret = -1;
>>> +#ifdef CONFIG_USB_KEYBOARD
>>> +   unsigned long ctrlc_t_start;
>>> +   unsigned long ctrlc_t;
>>> +   int ctrlc_result;
>>> +#endif
>>>
>>> NetRestarted = 0;
>>> NetDevExists = 0;
>>> @@ -472,7 +477,24 @@ restart:
>>> /*
>>>  *  Abort if ctrl-c was pressed.
>>>  */
>>> +#ifdef CONFIG_USB_KEYBOARD
>>
>> It seems this is the result of the USB Keyboard behavior.  Why is it a
>> good idea to litter the TFTP code with this unrelated code?  It seems
> 
> So far this is the best place to resolve this issue.

I'm not convinced; the previous versions of the patch modified the USB
keyboard driver, which seems a much better place to put the bulk of the
code.

Now, it may be a good idea to have other code, such as the network loop,
set a flag to tell the USB keyboard code (or other code) when some more
performance-sensitive/real-time operation is going on with CTRL-C
polling active, so that the USB keyboard code knows when to rate-limit
its activity.

>> the very same check could be down inside of ctrlc() somewhere that is
>> at least console I/O related.  Besides, having it in a common place
>> will allow any operation that accesses the keyboard to benefit from
>> not hanging up on slow USB stuff.
>>
>> It also seems that it should depend on what the actual source of the
>> stdin is, not just if you compiled in CONFIG_USB_KEYBOARD support.
> 
> This issue only goes with USB keyboard installed and CONFIG_USB_KEYBOARD
> defined. Therefore compiled in CONFIG_USB_KEYBOARD support.
> Non-usb-keyboard doesn't have such issue.

Joe's point is that this new code should not be activated when "USB
keyboard support is compiled in", but rather when "USB keyboard support
is actively in use". The difference is that simply because
CONFIG_USB_KEYBOARD is set does not imply that the USB keyboard must be
used; the stdin environment variable need not always contain "usbkbd".
(In fact, removing that string from stdin is how I work around this
issue for now...)

>> Again, something that belongs in the console source.
>>
>>> +   /*
>>> +* Reduce ctrl-c checking to 1 second once
>>> +* to improve TFTP boot performance.
>>> +*/
>>> +   if (ctrlc_t_start > get_timer(0))
>>> +   ctrlc_t_start = get_timer(0);
>>> +   ctrlc_t = get_timer(0) - ctrlc_t_start;
>>
>> Why is it preferable to do the subtraction yourself instead of letting
>> get_timer() do it?  I.e. what compelled did you change this from v4?
> 
> As Wolfgang Denk said in another mail, 
> "An exception is "arch/arm/cpu/sa1100/timer.c" which does not respect
> the "base" argument at all, i. e. which is broken.".
> 
> So this v5 patch uses get_timer(0), like other code did in this file.

That's a bug in the sa1100 timer code. The sa1100 timer code should be
fixed; other code shouldn't have to work around it being broken.

>>> +   if (ctrlc_t > CONFIG_SYS_HZ) {
>>
>> Why is hard-coding it to 1 second a good idea?
>>  Is that really how unresponsive it has to be to not
>>  significantly impact TFTP boot time?
> 
> Do you want me to add a CONFIG setting to have this time adjustable?
> I was thinking "1 second" checking on Ctrl-C should be fine while TFT
> boot is running.

1s polling seems fine to me. If someone else wants something different,
presumably they can add a config option for it?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] cmd_bootm.c: Make bootz consume 'bootz' from argv, decrement argc

[Stephen Warren]

On 07/10/2013 03:53 AM, Simon Glass wrote:
> On Tue, Jul 9, 2013 at 9:59 PM, Stephen Warren  > wrote:
> 
> On 07/09/2013 01:34 PM, Tom Rini wrote:
> > Like 'bootm', 'bootz' needs to consume 'bootz' so that the rest of the
> > state functions will work.
> 
> I found that the Raspberry Pi was randomly crashing with recent
> u-boot/master (bisect points at/near commit 35fc84f "Refactor the bootm
> command to reduce code duplication"; there is some slight variation in
> symptoms around there), or sometimes just spewing errors from bootz. I
> found the following commits on the mailing list:
> 
> > e1ec5e0 cmd_bootm.c: Make bootz handle BOOTM_STATE_FINDOTHER itself
> > c83a89d cmd_bootm.c: Make bootz consume 'bootz' from argv,
> decrement argc
> > d18cab6 bootm: Add the missing PREP stage to bootz and correct
> image handling
> > 4766b32 bootm: Clean up bootz_setup() function
> > f65d734 bootm: Require boot function only if it is about to be used
> > bf6f341 bootm: Disable interrupts only when loading
> > a01d5e4 bootm: Handle errors consistently
> 
> ... and the combination of all 7 of them (but not just Simon's 5
> patches) seems to solve this, so,
> 
> Tested-by: Stephen Warren  
> Thanks Stephen. Is this with an attached dtb or not? What 'bootz'
> command line are you testing here? I just want to make sure we are
> covering all the options

This is a separate kernel and DTB; the command-line is roughly:

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

Re: [U-Boot] twister: usb host support

[Jeroen Hofstee]

Hello Stefano / Tapani,

On 07/10/2013 04:27 PM, Stefano Babic wrote:

On 09/07/2013 21:46, Jeroen Hofstee wrote:

I cannot find any document mentioning gpio_25 though.
Any reason for this usage?

That is right. There is no written documentation by Technexion about
this pin. I have added in CC Tapani, maybe he can tell us something more.
The GPIO is used internally on the TAM3517 SOM, and we have no
schematics about it. We have to guess about its usage.


Yes, and some clarification of the pin 35 would be
appreciated as well, since it is marked as ball X, I guess
it is controlled by hardware and the hub cannot be reset
from software, but that is just guessing...


The reason to have it is that the sources for the kernel provided by
Technexion (an ancient 2.6.32 Version) set this pin to reset the EHCI.
As I said, there is no further documentation and rather we can only make
some supposition. The usage in U-Boot then reflects the usage made by
Technexion.



Fyi my linux copy (3.7) with this gpio set as the phy_reset is also
unable to properly reset it and times out. The usb is working
though, also without a proper reset..


p.s.
I found by sheer accidence that the usb is behaving
completely normal (after the patch) on rev B1. It is
broken on rev B without the patch and working buggy
with it. On rev B1 + patch the USB to SATA converter
is discovered as well, which I have never seen before.


I can confirm issues with version B of the TAM3517-SOM. I am testing a
B1 SOM with a B twister. I do not know the details about changelog
between B and B1 version of the SOM, but I got both USB and Ethernet
problems with TAM3517-B. The same image runs without the same problems
on a B1.


ok, good to know.


There is also this pending patch by Michael:

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

It is applied to u-boot-ti, not yet to mainline.



on top of usb master this patch leads to:
USB0:ULPI: ulpi_reset: failed writing reset bit
ULPI:ulpi_reset: failed writing reset bit

It does always find the stick though and never the SATA converter.

without the gpio_25 reset, the second error goes away and
the SATA is back.



@@ -92,9 +92,6 @@ int board_init(void)
  enable_gpmc_cs_config(gpmc_XR16L2751, &gpmc_cfg->cs[3],
  XR16L2751_UART2_BASE, GPMC_SIZE_16M);

-gpio_request(CONFIG_OMAP_EHCI_PHY1_RESET_GPIO, "USB_PHY1_RESET");
-gpio_direction_output(CONFIG_OMAP_EHCI_PHY1_RESET_GPIO, 1);
-
See my concerns above. Do not reset the hub in the kernel ?


I don't get the last part, but feedback from Technexion is
needed first to remove all the guess, maybe etc. If it has a
valid function, not setting it's value might not be such a
good idea...

Regards,
Jeroen

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

Re: [U-Boot] [PATCH 0/7] USB: XHCI: Add xHCI host controller stack driver

[Dan Murphy]

Vivek
On 07/03/2013 06:15 AM, Vivek Gautam wrote:
> Dear Dan,
>
> Please suggest on how you are planning going ahead and merging the two
> versions of xHCI stack.
>


Sorry for the delay on the reply US holiday.

I need to dive into your code and see exactly what you were doing and how to 
meld the two code bases together.

If we could get the basic XHCI stack running from the kernel then at least the 
OMAP and Exynos can share the same code base like in the kernel.

Please go ahead and pick apart the xHCI patches that I sent in for RFC.

Dan
>> Now you can flame me to death.
>
>
>


-- 
--
Dan Murphy

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

Re: [U-Boot] [RFC PATCH] arm: arm926ejs: flush cache before disable it

[Sughosh Ganu]

hi Albert,

On Wed Jul 10, 2013 at 02:30:30PM +0200, Albert ARIBAUD wrote:

> > > You are correct re the other policies of the DDI0198E (ARM926EJ-S
> > > TRM) MMU -- page 3-11, bits 3-2 of the section descriptor. Note however
> > > that you may have to refer to your specific SoC's TRM or equivalent, as
> > > the SoC designer may have defined its own system-level cache and MMU
> > > architecture.
> > > 
> > > Note in any case that none of the policies mentioned in DDI0198E is
> > > described as read-allocate (let alone "read-allocate only" where writes
> > > would bypass the enabled cache); on the contrary, the only cache
> > > policies mentioned are write-through and write-back, both of which
> > > contradict cache bypass on write.
> > 
> > I was referring to the cache allocation policy mentioned in section
> > 4.1 in the DDI0198E document -- this is also mentioned in table 12.1
> > in chapter 12 of the arm developers guide.
> 
> Can you please quote the exact part of 4.1 which describes the cache
> policy and then explain what you think it means exactly?

I was referring to this particular point in section 4.1
"Allocate on read-miss is supported. The caches perform critical-word
first cache refilling."

Based on the cache line allocation policies described in section
12.3.3 in the arm developers guide, my interpretation of 'allocate on
read-miss' was as above.

-sughosh

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

[U-Boot] [PULL] u-boot-usb/master

[Marek Vasut]

The following changes since commit 225fd8c5d4556547896a5d32ee092a258f3df638:





  cmd_bootm.c: Make bootz handle BOOTM_STATE_FINDOTHER itself (2013-07-10 
09:15:15 -0400) 
  



are available in the git repository at: 





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

for you to fetch changes up to ecc8edbf6995558d8a47b43ac6645840c98a7b95:

  usb: pxa27x_udc: fix compiler warnings (2013-07-10 20:18:57 +0200)


Mike Dunn (1):
  usb: pxa27x_udc: fix compiler warnings

Łukasz Majewski (1):
  dfu: Update DFU's authorship history

 drivers/usb/gadget/f_dfu.c  |7 +++
 drivers/usb/gadget/pxa27x_udc.c |   14 +-
 2 files changed, 12 insertions(+), 9 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3] HACK: ehci-omap: do gpio toggle after port power is set

[Dan Murphy]

On 07/09/2013 04:59 AM, Roger Quadros wrote:
> On 07/08/2013 11:59 PM, Dan Murphy wrote:
>> Need to check why gpio toggling in ehci-omap is not
>> working and works only from ehci-hcd.
> do you mean HSIC detection is not working?
>
> GPIO toggling has to work from anywhere.
GPIO toggling does work.  I have confirmed that.
The issue seems to be that the Ethernet controller does not enumerate after the 
power power has been set.

It seems like the IC needs to be reset once the port power is set so it can 
enumerate.

The USB3530 on port 2 does not seem to have an issue.  Need to find out if this 
is a 9730 IC quirk.
>
>> Signed-off-by: Dan Murphy 
>> ---
>>  drivers/usb/host/ehci-hcd.c  |7 ++-
>>  drivers/usb/host/ehci-omap.c |2 +-
>>  2 files changed, 7 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
>> index 706cf0c..17d0c9c 100644
>> --- a/drivers/usb/host/ehci-hcd.c
>> +++ b/drivers/usb/host/ehci-hcd.c
>> @@ -29,7 +29,7 @@
>>  #include 
>>  #include 
>>  #include 
>> -
>> +#include 
>>  #include "ehci.h"
>>  
>>  #ifndef CONFIG_USB_MAX_CONTROLLER_COUNT
>> @@ -776,6 +776,11 @@ ehci_submit_root(struct usb_device *dev, unsigned long 
>> pipe, void *buffer,
>>  if (HCS_PPC(ehci_readl(&ctrl->hccr->cr_hcsparams))) {
>>  reg |= EHCI_PS_PP;
>>  ehci_writel(status_reg, reg);
>> +#ifdef CONFIG_USB_EHCI_OMAP
>> +omap_ehci_phy_reset(1, 1000);
>> +mdelay(10);
>> +omap_ehci_phy_reset(0, 1000);
>> +#endif
> Did you try to first keep the PHY in reset, start the EHCI controller
> and then release the reset?
Yes I have and thats what uBoot already does.  No dice there.
>
> At least this is what is done in the Linux kernel to get it to work.
>
>>  }
>>  break;
>>  case USB_PORT_FEAT_RESET:
>> diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
>> index 17f2214..68add44 100644
>> --- a/drivers/usb/host/ehci-omap.c
>> +++ b/drivers/usb/host/ehci-omap.c
>> @@ -109,7 +109,7 @@ int board_usb_init(void) __attribute__((weak, 
>> alias("__board_usb_init")));
>>  #if defined(CONFIG_OMAP_EHCI_PHY1_RESET_GPIO) || \
>>  defined(CONFIG_OMAP_EHCI_PHY2_RESET_GPIO)
>>  /* controls PHY(s) reset signal(s) */
>> -static inline void omap_ehci_phy_reset(int on, int delay)
>> +void omap_ehci_phy_reset(int on, int delay)
>>  {
>>  /*
>>   * Refer ISSUE1:
>>
> cheers,
> -roger


-- 
--
Dan Murphy

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

[U-Boot] [[PATCH v2 2/6] ARM: OMAP5: Power: Add USB LDO9 enable interface

[Dan Murphy]

Add an interface to the palmas driver to enable the
LDO9 power supply for the USB hub IC.

Signed-off-by: Dan Murphy 
---
 drivers/power/palmas.c |   34 ++
 include/palmas.h   |1 +
 2 files changed, 35 insertions(+)

diff --git a/drivers/power/palmas.c b/drivers/power/palmas.c
index 2d275a7..b800dd4 100644
--- a/drivers/power/palmas.c
+++ b/drivers/power/palmas.c
@@ -143,6 +143,40 @@ int twl603x_audio_power(u8 on)
 }
 #endif
 
+#ifdef CONFIG_PALMAS_USBPWR
+int palmas_usb_poweron_ldo(void)
+{
+   u8 val = 0;
+   int err;
+
+   /* TURN ON LDO's needed */
+   val = RSC_STAT_ON | RSC_MODE_SLEEP | RSC_MODE_ACTIVE;
+   err = palmas_i2c_write_u8(TWL603X_CHIP_P1, SYSEN2_CTRL, val);
+   if (err) {
+   printf("palmas: could not turn 3v3 %s: err = %d\n",
+  val ? "on" : "off", err);
+   return err;
+   }
+
+   /* set to 3.3V */
+   val = LDO9_BYPASS;
+   err = palmas_i2c_write_u8(TWL603X_CHIP_P1, LDOUSB_VOLTAGE, val);
+   if (err) {
+   printf("palmas: could not set 3v3 %s: err = %d\n",
+  val ? "on" : "off", err);
+   return err;
+   }
+
+   /* enable LDO USB */
+   err = palmas_i2c_write_u8(TWL603X_CHIP_P1, LDOUSB_CTRL, val);
+   if (err) {
+   printf("palmas: could not enable 3v3 %s: err = %d\n",
+  val ? "on" : "off", err);
+   return err;
+   }
+}
+#endif
+
 /*
  * Enable/disable back-up battery (or super cap) charging on TWL6035/37.
  * Please use defined BB_xxx values.
diff --git a/include/palmas.h b/include/palmas.h
index aff48b5..43887c2 100644
--- a/include/palmas.h
+++ b/include/palmas.h
@@ -130,5 +130,6 @@ int palmas_mmc1_poweron_ldo(void);
 int twl603x_mmc1_set_ldo9(u8 vsel);
 int twl603x_audio_power(u8 on);
 int twl603x_enable_bb_charge(u8 bb_fields);
+int palmas_usb_poweron_ldo(void);
 
 #endif /* PALMAS_H */
-- 
1.7.9.5

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

[U-Boot] [[PATCH v2 1/6] omap5: uevm: Change the board name to correct name

[Dan Murphy]

Change the board name for the sys info to
5432 uEVM

Signed-off-by: Dan Murphy 
---
 board/ti/omap5_uevm/evm.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/ti/omap5_uevm/evm.c b/board/ti/omap5_uevm/evm.c
index 90046e8..00bd72d 100644
--- a/board/ti/omap5_uevm/evm.c
+++ b/board/ti/omap5_uevm/evm.c
@@ -32,7 +32,7 @@
 DECLARE_GLOBAL_DATA_PTR;
 
 const struct omap_sysinfo sysinfo = {
-   "Board: OMAP5430 EVM\n"
+   "Board: OMAP5432 uEVM\n"
 };
 
 /**
-- 
1.7.9.5

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

[U-Boot] OMAP5 USB EHCI

[Dan Murphy]

The V2 patchset is based off the V1 patchset submitted below:
http://patchwork.ozlabs.org/patch/257607/
http://patchwork.ozlabs.org/patch/257606/
http://patchwork.ozlabs.org/patch/257604/

There was a request to break the patches out into logical incremental patches
which is what is done below.

All comments should have been addressed with v2 but I cannot give direct 1 to 1
history from V1 to V2 since the patchsets have been broken out.

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

[U-Boot] [[PATCH v2 4/6] ARM: OMAP: USB: Fix linker error when ULPI is not defined

[Dan Murphy]

Fix the linker error for missing ulpi_reset when ulpi is not defined
in the board config.

Signed-off-by: Dan Murphy 
---
 drivers/usb/host/ehci-omap.c |7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 17f2214..bd7191c 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -90,6 +90,7 @@ static void omap_usbhs_hsic_init(int port)
writel(reg, &usbtll->channel_conf + port);
 }
 
+#ifdef CONFIG_USB_ULPI
 static void omap_ehci_soft_phy_reset(int port)
 {
struct ulpi_viewport ulpi_vp;
@@ -99,6 +100,12 @@ static void omap_ehci_soft_phy_reset(int port)
 
ulpi_reset(&ulpi_vp);
 }
+#else
+static void omap_ehci_soft_phy_reset(int port)
+{
+   return;
+}
+#endif
 
 inline int __board_usb_init(void)
 {
-- 
1.7.9.5

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

[U-Boot] [[PATCH v2 6/6] ARM: OMAP5-uevm: Add USB ehci support for the uEVM

[Dan Murphy]

Add the USB ehci support for the OMAP5 uEVM.

Configure the uEVM mux data
Add the flags to build the appropriate modules
Add the usb call backs to initialize the EHCI controller

Signed-off-by: Dan Murphy 
---
 board/ti/omap5_uevm/evm.c  |   58 
 board/ti/omap5_uevm/mux_data.h |4 ++-
 include/configs/omap5_common.h |2 --
 include/configs/omap5_uevm.h   |   24 +
 4 files changed, 85 insertions(+), 3 deletions(-)

diff --git a/board/ti/omap5_uevm/evm.c b/board/ti/omap5_uevm/evm.c
index 00bd72d..6c6b320 100644
--- a/board/ti/omap5_uevm/evm.c
+++ b/board/ti/omap5_uevm/evm.c
@@ -26,9 +26,16 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "mux_data.h"
 
+#ifdef CONFIG_USB_EHCI
+#include 
+#include 
+#include 
+#endif
+
 DECLARE_GLOBAL_DATA_PTR;
 
 const struct omap_sysinfo sysinfo = {
@@ -103,3 +110,54 @@ int board_mmc_init(bd_t *bis)
return 0;
 }
 #endif
+
+#ifdef CONFIG_USB_EHCI
+static struct omap_usbhs_board_data usbhs_bdata = {
+   .port_mode[0] = OMAP_USBHS_PORT_MODE_UNUSED,
+   .port_mode[1] = OMAP_EHCI_PORT_MODE_HSIC,
+   .port_mode[2] = OMAP_EHCI_PORT_MODE_HSIC,
+};
+
+int ehci_hcd_init(int index, struct ehci_hccr **hccr, struct ehci_hcor **hcor)
+{
+   int ret;
+   int auxclk;
+
+#ifdef CONFIG_PALMAS_POWER
+#ifdef CONFIG_PALMAS_USBPWR
+   palmas_usb_poweron_ldo();
+#endif
+#endif
+
+   auxclk = readl((*prcm)->scrm_auxclk1);
+   /* Request auxilary clock */
+   auxclk |= AUXCLK_ENABLE_MASK;
+   writel(auxclk, (*prcm)->scrm_auxclk1);
+
+   ret = omap_ehci_hcd_init(&usbhs_bdata, hccr, hcor);
+   if (ret < 0) {
+   printf("Failed to initialize ehci\n");
+   return ret;
+   }
+
+   return 0;
+}
+
+int ehci_hcd_stop(void)
+{
+   int ret;
+
+   ret = omap_ehci_hcd_stop();
+   return ret;
+}
+
+void ehci_reset_attached_devices(int port)
+{
+   /* The LAN9730 needs to be reset after the port power has been set. */
+   if (port == 3) {
+   gpio_direction_output(CONFIG_OMAP_EHCI_PHY1_RESET_GPIO, 0);
+   udelay(10);
+   gpio_direction_output(CONFIG_OMAP_EHCI_PHY1_RESET_GPIO, 1);
+   }
+}
+#endif
diff --git a/board/ti/omap5_uevm/mux_data.h b/board/ti/omap5_uevm/mux_data.h
index a82795d..17de7f5 100644
--- a/board/ti/omap5_uevm/mux_data.h
+++ b/board/ti/omap5_uevm/mux_data.h
@@ -56,7 +56,8 @@ const struct pad_conf_entry core_padconf_array_essential[] = {
{USBD0_HS_DP, (IEN | M0)},  /*  USBD0_HS_DP */
{USBD0_HS_DM, (IEN | M0)},  /*  USBD0_HS_DM */
{USBD0_SS_RX, (IEN | M0)},  /*  USBD0_SS_RX */
-
+   {HSI2_ACWAKE, (PTU | M6)},/*  HSI2_ACWAKE */
+   {HSI2_CAFLAG, (PTU | M6)},/*  HSI2_CAFLAG */
 };
 
 const struct pad_conf_entry wkup_padconf_array_essential[] = {
@@ -64,6 +65,7 @@ const struct pad_conf_entry wkup_padconf_array_essential[] = {
{SR_PMIC_SCL, (PTU | IEN | M0)}, /* SR_PMIC_SCL */
{SR_PMIC_SDA, (PTU | IEN | M0)}, /* SR_PMIC_SDA */
{SYS_32K, (IEN | M0)}, /*  SYS_32K */
+   {FREF_CLK1_OUT, (PTD | IEN | M0)},/*  FREF_CLK1_OUT  */
 
 };
 
diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h
index b87ee42..32f053d 100644
--- a/include/configs/omap5_common.h
+++ b/include/configs/omap5_common.h
@@ -113,8 +113,6 @@
 #define CONFIG_CMD_MMC /* MMC support  */
 
 /* Disabled commands */
-#undef CONFIG_CMD_NET
-#undef CONFIG_CMD_NFS
 #undef CONFIG_CMD_FPGA /* FPGA configuration Support   */
 #undef CONFIG_CMD_IMLS /* List all found images*/
 
diff --git a/include/configs/omap5_uevm.h b/include/configs/omap5_uevm.h
index 46dacc2..b79ea59 100644
--- a/include/configs/omap5_uevm.h
+++ b/include/configs/omap5_uevm.h
@@ -53,6 +53,30 @@
 #define CONFIG_PARTITION_UUIDS
 #define CONFIG_CMD_PART
 
+/* USB UHH support options */
+#define CONFIG_CMD_USB
+#define CONFIG_USB_HOST
+#define CONFIG_USB_EHCI
+#define CONFIG_USB_EHCI_OMAP
+#define CONFIG_USB_STORAGE
+#define CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS 3
+#define CONFIG_EHCI_HCD_INIT_AFTER_RESET
+
+#define CONFIG_OMAP_EHCI_PHY1_RESET_GPIO 79
+#define CONFIG_OMAP_EHCI_PHY2_RESET_GPIO 80
+
+#define CONFIG_PALMAS_USBPWR
+
+/* Enabled commands */
+#define CONFIG_NET_MULTI
+#define CONFIG_CMD_DHCP/* DHCP Support */
+#define CONFIG_CMD_NET /* bootp, tftpboot, rarpboot*/
+#define CONFIG_CMD_NFS /* NFS support  */
+
+/* USB Networking options */
+#define CONFIG_USB_HOST_ETHER
+#define CONFIG_USB_ETHER_SMSC95XX
+
 #define CONFIG_SYS_PROMPT  "OMAP5432 uEVM # "
 
 #define CONSOLEDEV "ttyO2"
-- 
1.7.9.5

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

[U-Boot] [[PATCH v2 3/6] ARM: OMAP5: USB: Add OMAP5 common USB EHCI information

[Dan Murphy]

* Enable the OMAP5 EHCI host clocks
* Add OMAP5 EHCI register definitions
* Add OMAP5 ES2 host revision

Signed-off-by: Dan Murphy 
---
 arch/arm/cpu/armv7/omap5/hw_data.c  |   13 ++
 arch/arm/include/asm/arch-omap5/clock.h |6 +
 arch/arm/include/asm/arch-omap5/ehci.h  |   43 +++
 arch/arm/include/asm/ehci-omap.h|1 +
 drivers/usb/host/ehci-omap.c|2 +-
 5 files changed, 64 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/include/asm/arch-omap5/ehci.h

diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c 
b/arch/arm/cpu/armv7/omap5/hw_data.c
index 56cf1f8..055f058 100644
--- a/arch/arm/cpu/armv7/omap5/hw_data.c
+++ b/arch/arm/cpu/armv7/omap5/hw_data.c
@@ -412,6 +412,8 @@ void enable_basic_clocks(void)
(*prcm)->cm_l4per_gpio4_clkctrl,
(*prcm)->cm_l4per_gpio5_clkctrl,
(*prcm)->cm_l4per_gpio6_clkctrl,
+   (*prcm)->cm_clksel_usb_60mhz,
+   (*prcm)->cm_l3init_hsusbtll_clkctrl,
0
};
 
@@ -423,6 +425,7 @@ void enable_basic_clocks(void)
(*prcm)->cm_wkup_wdtimer2_clkctrl,
(*prcm)->cm_l4per_uart3_clkctrl,
(*prcm)->cm_l4per_i2c1_clkctrl,
+   (*prcm)->cm_l3init_hsusbhost_clkctrl,
0
};
 
@@ -446,6 +449,16 @@ void enable_basic_clocks(void)
setbits_le32((*prcm)->cm_wkup_gptimer1_clkctrl,
GPTIMER1_CLKCTRL_CLKSEL_MASK);
 
+#ifdef CONFIG_USB_EHCI
+   /* Enable port 2 and 3 clocks*/
+   setbits_le32((*prcm)->cm_l3init_hsusbhost_clkctrl,
+   USB_HOST_HS_CLKCTRL_MASK);
+
+   /* Enable all 3 usb host ports tll clocks*/
+   setbits_le32((*prcm)->cm_l3init_hsusbtll_clkctrl,
+   USB_TLL_HS_CLKCTRL_MASK);
+#endif
+
do_enable_clocks(clk_domains_essential,
 clk_modules_hw_auto_essential,
 clk_modules_explicit_en_essential,
diff --git a/arch/arm/include/asm/arch-omap5/clock.h 
b/arch/arm/include/asm/arch-omap5/clock.h
index 4d2765d..3a58337 100644
--- a/arch/arm/include/asm/arch-omap5/clock.h
+++ b/arch/arm/include/asm/arch-omap5/clock.h
@@ -165,6 +165,12 @@
 /* CM_L3INIT_USBPHY_CLKCTRL */
 #define USBPHY_CLKCTRL_OPTFCLKEN_PHY_48M_MASK  8
 
+/* CM_L3INIT_USB_HOST_HS_CLKCTRL */
+#define USB_HOST_HS_CLKCTRL_MASK   0x56C0
+
+/* CM_L3INIT_USB_TLL_HS_CLKCTRL */
+#define USB_TLL_HS_CLKCTRL_MASK0x700
+
 /* CM_MPU_MPU_CLKCTRL */
 #define MPU_CLKCTRL_CLKSEL_EMIF_DIV_MODE_SHIFT 24
 #define MPU_CLKCTRL_CLKSEL_EMIF_DIV_MODE_MASK  (3 << 24)
diff --git a/arch/arm/include/asm/arch-omap5/ehci.h 
b/arch/arm/include/asm/arch-omap5/ehci.h
new file mode 100644
index 000..3921e4a
--- /dev/null
+++ b/arch/arm/include/asm/arch-omap5/ehci.h
@@ -0,0 +1,43 @@
+/*
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com*
+ * Author: Govindraj R 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#ifndef _EHCI_H
+#define _EHCI_H
+
+#define OMAP_EHCI_BASE (OMAP54XX_L4_CORE_BASE + 
0x64C00)
+#define OMAP_UHH_BASE  (OMAP54XX_L4_CORE_BASE + 
0x64000)
+#define OMAP_USBTLL_BASE   (OMAP54XX_L4_CORE_BASE + 
0x62000)
+
+/* TLL Register Set */
+#define OMAP_USBTLL_SYSCONFIG_SIDLEMODE(1 << 3)
+#define OMAP_USBTLL_SYSCONFIG_ENAWAKEUP(1 << 2)
+#define OMAP_USBTLL_SYSCONFIG_SOFTRESET(1 << 1)
+#define OMAP_USBTLL_SYSCONFIG_CACTIVITY(1 << 8)
+#define OMAP_USBTLL_SYSSTATUS_RESETDONE1
+
+#define OMAP_UHH_SYSCONFIG_SOFTRESET   1
+#define OMAP_UHH_SYSSTATUS_EHCI_RESETDONE  (1 << 2)
+#define OMAP_UHH_SYSCONFIG_NOIDLE  (1 << 2)
+#define OMAP_UHH_SYSCONFIG_NOSTDBY (1 << 4)
+
+#define OMAP_UHH_SYSCONFIG_VAL (OMAP_UHH_SYSCONFIG_NOIDLE | \
+   OMAP_UHH_SYSCONFIG_NOSTDBY)
+
+#endif /* _EHCI_H */
diff --git a/arch/arm/include/asm/ehci-omap.h b/arch/arm/include/asm/ehci-omap.h
index 77e8170..0b09e9d 100644
--- a/arch/arm/include/asm/ehci-omap.h
+++ b/arch/arm/include/asm/ehci-omap.h
@@ -42,6 +42,7 @@ enum usbhs_omap_port_mode {
 /* Values of UHH_REVI

[U-Boot] [[PATCH v3 2/2] gpio: omap5-uevm: Configure the tca6424 gpio expander

[Dan Murphy]

Configure the tca6424 gpio expander
This allows use of the debug and tri color LEDs.

Signed-off-by: Dan Murphy 
---
 board/ti/omap5_uevm/evm.c  |   21 +
 board/ti/omap5_uevm/mux_data.h |2 ++
 include/configs/omap5_uevm.h   |5 +
 3 files changed, 28 insertions(+)

diff --git a/board/ti/omap5_uevm/evm.c b/board/ti/omap5_uevm/evm.c
index 90046e8..0e9a559 100644
--- a/board/ti/omap5_uevm/evm.c
+++ b/board/ti/omap5_uevm/evm.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "mux_data.h"
 
@@ -35,6 +36,24 @@ const struct omap_sysinfo sysinfo = {
"Board: OMAP5430 EVM\n"
 };
 
+/* @brief tca642x_init - Initial states for the GPIO expander
+ * input reg, output reg, polarity reg, configuration reg
+ */
+struct tca642x_bank_info tca642x_init[] = {
+   { .input_reg = 0x00,
+ .output_reg = 0x04,
+ .polarity_reg = 0x00,
+ .configuration_reg = 0x80 },
+   { .input_reg = 0x00,
+ .output_reg = 0x00,
+ .polarity_reg = 0x00,
+ .configuration_reg = 0xff },
+   { .input_reg = 0x00,
+ .output_reg = 0x00,
+ .polarity_reg = 0x00,
+ .configuration_reg = 0x40 },
+};
+
 /**
  * @brief board_init
  *
@@ -46,6 +65,8 @@ int board_init(void)
gd->bd->bi_arch_number = MACH_TYPE_OMAP5_SEVM;
gd->bd->bi_boot_params = (0x8000 + 0x100); /* boot param addr */
 
+   tca642x_set_inital_state(CONFIG_SYS_I2C_TCA642X_ADDR, tca642x_init);
+
return 0;
 }
 
diff --git a/board/ti/omap5_uevm/mux_data.h b/board/ti/omap5_uevm/mux_data.h
index a82795d..7e6415e 100644
--- a/board/ti/omap5_uevm/mux_data.h
+++ b/board/ti/omap5_uevm/mux_data.h
@@ -56,6 +56,8 @@ const struct pad_conf_entry core_padconf_array_essential[] = {
{USBD0_HS_DP, (IEN | M0)},  /*  USBD0_HS_DP */
{USBD0_HS_DM, (IEN | M0)},  /*  USBD0_HS_DM */
{USBD0_SS_RX, (IEN | M0)},  /*  USBD0_SS_RX */
+   {I2C5_SCL, (IEN | M0)}, /* I2C5_SCL */
+   {I2C5_SDA, (IEN | M0)}, /* I2C5_SDA */
 
 };
 
diff --git a/include/configs/omap5_uevm.h b/include/configs/omap5_uevm.h
index 46dacc2..bee1278 100644
--- a/include/configs/omap5_uevm.h
+++ b/include/configs/omap5_uevm.h
@@ -53,6 +53,11 @@
 #define CONFIG_PARTITION_UUIDS
 #define CONFIG_CMD_PART
 
+#define CONFIG_TCA642X
+#define CONFIG_CMD_TCA642X
+#define CONFIG_SYS_I2C_TCA642X_BUS_NUM 4
+#define CONFIG_SYS_I2C_TCA642X_ADDR 0x22
+
 #define CONFIG_SYS_PROMPT  "OMAP5432 uEVM # "
 
 #define CONSOLEDEV "ttyO2"
-- 
1.7.9.5

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

[U-Boot] [[PATCH v3 1/2] gpio: tca642x: Add the tca642x gpio expander driver

[Dan Murphy]

Add the tca642x gpio expander driver

Datasheet:
http://www.ti.com/product/tca6424a

Signed-off-by: Dan Murphy 
---
 drivers/gpio/Makefile  |1 +
 drivers/gpio/tca642x.c |  322 
 include/tca642x.h  |   66 ++
 3 files changed, 389 insertions(+)
 create mode 100644 drivers/gpio/tca642x.c
 create mode 100644 include/tca642x.h

diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index f77c1ec..7e74dfe 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -49,6 +49,7 @@ COBJS-$(CONFIG_BCM2835_GPIO)  += bcm2835_gpio.o
 COBJS-$(CONFIG_S3C2440_GPIO)   += s3c2440_gpio.o
 COBJS-$(CONFIG_XILINX_GPIO)+= xilinx_gpio.o
 COBJS-$(CONFIG_ADI_GPIO2)  += adi_gpio2.o
+COBJS-$(CONFIG_TCA642X)+= tca642x.o
 
 COBJS  := $(COBJS-y)
 SRCS   := $(COBJS:.o=.c)
diff --git a/drivers/gpio/tca642x.c b/drivers/gpio/tca642x.c
new file mode 100644
index 000..a0c7a8b
--- /dev/null
+++ b/drivers/gpio/tca642x.c
@@ -0,0 +1,322 @@
+/*
+ * Copyright 2013 Texas Instruments, Inc.
+ * Author: Dan Murphy 
+ *
+ * Derived work from the pca953x.c driver
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include 
+#include 
+#include 
+
+/* tca642x register address definitions */
+struct tca642x_bank_info tca642x_regs[] = {
+   { .input_reg = 0x00,
+ .output_reg = 0x04,
+ .polarity_reg = 0x08,
+ .configuration_reg = 0x0c },
+   { .input_reg = 0x01,
+ .output_reg = 0x05,
+ .polarity_reg = 0x09,
+ .configuration_reg = 0x0d },
+   { .input_reg = 0x02,
+ .output_reg = 0x06,
+ .polarity_reg = 0x0a,
+ .configuration_reg = 0x0e },
+};
+
+/*
+ * Modify masked bits in register
+ */
+static int tca642x_reg_write(uchar chip, uint8_t addr,
+   uint8_t reg_bit, uint8_t data)
+{
+   uint8_t valw;
+   int org_bus_num;
+   int ret;
+
+   org_bus_num = i2c_get_bus_num();
+   i2c_set_bus_num(CONFIG_SYS_I2C_TCA642X_BUS_NUM);
+
+   if (i2c_read(chip, addr, 1, (uint8_t *)&valw, 1)) {
+   printf("Could not read before writing\n");
+   ret = -1;
+   goto error;
+   }
+   valw &= ~reg_bit;
+   valw |= data;
+
+   ret = i2c_write(chip, addr, 1, (u8 *)&valw, 1);
+
+error:
+   i2c_set_bus_num(org_bus_num);
+   return ret;
+}
+
+static int tca642x_reg_read(uchar chip, uint8_t addr, uint8_t *data)
+{
+   uint8_t valw;
+   int org_bus_num;
+   int ret = 0;
+
+   org_bus_num = i2c_get_bus_num();
+   i2c_set_bus_num(CONFIG_SYS_I2C_TCA642X_BUS_NUM);
+   if (i2c_read(chip, addr, 1, (u8 *)&valw, 1)) {
+   ret = -1;
+   goto error;
+   }
+
+   *data = valw;
+
+error:
+   i2c_set_bus_num(org_bus_num);
+   return ret;
+}
+
+/*
+ * Set output value of IO pins in 'reg_bit' to corresponding value in 'data'
+ * 0 = low, 1 = high
+ */
+int tca642x_set_val(uchar chip, uint8_t gpio_bank, uint8_t reg_bit, uint8_t 
data)
+{
+   uint8_t out_reg = tca642x_regs[gpio_bank].output_reg;
+
+   return tca642x_reg_write(chip, out_reg, reg_bit, data);
+}
+
+/*
+ * Set read polarity of IO pins in 'reg_bit' to corresponding value in 'data'
+ * 0 = read pin value, 1 = read inverted pin value
+ */
+int tca642x_set_pol(uchar chip, uint8_t gpio_bank, uint8_t reg_bit, uint8_t 
data)
+{
+   uint8_t pol_reg = tca642x_regs[gpio_bank].polarity_reg;
+
+   return tca642x_reg_write(chip, pol_reg, reg_bit, data);
+}
+
+/*
+ * Set direction of IO pins in 'reg_bit' to corresponding value in 'data'
+ * 0 = output, 1 = input
+ */
+int tca642x_set_dir(uchar chip, uint8_t gpio_bank, uint8_t reg_bit, uint8_t 
data)
+{
+   uint8_t config_reg = tca642x_regs[gpio_bank].configuration_reg;
+
+   return tca642x_reg_write(chip, config_reg, reg_bit, data);
+}
+
+/*
+ * Read current logic level of all IO pins
+ */
+int tca642x_get_val(uchar chip, uint8_t gpio_bank)
+{
+   uint8_t val;
+   uint8_t in_reg = tca642x_regs[gpio_bank].input_reg;
+
+   if (tca642x_reg_read(chip, in_reg, &val) < 0)
+   return -1;
+
+   return (int)val;
+}
+
+/*
+ * Set the inital register states for the tca642x gpio expander
+ */
+int tca642x_set_inital_state(uchar chip, struct tca642x_bank

[U-Boot] [[PATCH v2 5/6] USB: ehci: Add a weak function for resetting devices

[Dan Murphy]

Add a __weak function that can be overridden to reset devices
attached to an ehci devices after the FEAT_POWER has been submitted

Signed-off-by: Dan Murphy 
---
 drivers/usb/host/ehci-hcd.c |7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 706cf0c..fdd3994 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -616,6 +616,11 @@ __weak uint32_t *ehci_get_portsc_register(struct ehci_hcor 
*hcor, int port)
return (uint32_t *)&hcor->or_portsc[port];
 }
 
+__weak void ehci_reset_attached_devices(int port)
+{
+   return;
+}
+
 int
 ehci_submit_root(struct usb_device *dev, unsigned long pipe, void *buffer,
 int length, struct devrequest *req)
@@ -777,6 +782,7 @@ ehci_submit_root(struct usb_device *dev, unsigned long 
pipe, void *buffer,
reg |= EHCI_PS_PP;
ehci_writel(status_reg, reg);
}
+   ehci_reset_attached_devices(port);
break;
case USB_PORT_FEAT_RESET:
if ((reg & (EHCI_PS_PE | EHCI_PS_CS)) == EHCI_PS_CS &&
@@ -794,6 +800,7 @@ ehci_submit_root(struct usb_device *dev, unsigned long 
pipe, void *buffer,
reg |= EHCI_PS_PR;
reg &= ~EHCI_PS_PE;
ehci_writel(status_reg, reg);
+
/*
 * caller must wait, then call GetPortStatus
 * usb 2.0 specification say 50 ms resets on
-- 
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 v3] bootm: Handle errors consistently

[Simon Glass]

Hi Tom,

On Wed, Jul 10, 2013 at 6:25 AM, Tom Rini  wrote:

> From: Simon Glass 
>
> A recent bootm fix left the error path incomplete. If CONFIG_TRACE is
> set it may still not be a supported command, so cover that with the
> unsupported subcommand print.  Once we handle BOOTM_STATE_OS_GO, we can
> just move into the error handler itself, no need for a goto there.
>
> Signed-off-by: Simon Glass 
> [trini: Update slightly based on Simon's changes to also cover
> CONFIG_TRACE/BOOTM_STATE_FAKE_OS_GO]
> Signed-off-by: Tom Rini 
> ---
>  common/cmd_bootm.c |   21 -
>  1 file changed, 8 insertions(+), 13 deletions(-)
>
> diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
> index a783cea..6caa0e9 100644
> --- a/common/cmd_bootm.c
> +++ b/common/cmd_bootm.c
> @@ -705,13 +705,6 @@ static int do_bootm_states(cmd_tbl_t *cmdtp, int
> flag, int argc,
> if (!ret && (states & BOOTM_STATE_OS_PREP))
> ret = boot_fn(BOOTM_STATE_OS_PREP, argc, argv, images);
>
> -   /* Check for unsupported subcommand. */
> -   if (ret) {
> -   puts("subcommand not supported\n");
> -   return ret;
> -   }
> -
> -
>  #ifdef CONFIG_TRACE
> /* Pretend to run the OS, then run a user command */
> if (!ret && (states & BOOTM_STATE_OS_FAKE_GO)) {
> @@ -723,15 +716,17 @@ static int do_bootm_states(cmd_tbl_t *cmdtp, int
> flag, int argc,
> ret = run_command_list(cmd_list, -1, flag);
> }
>  #endif
> +
> +   /* Check for unsupported subcommand. */
> +   if (ret) {
> +   puts("subcommand not supported\n");
> +   return ret;
> +   }
> +
> /* Now run the OS! We hope this doesn't return */
> -   if (!ret && (states & BOOTM_STATE_OS_GO)) {
> +   if (!ret && (states & BOOTM_STATE_OS_GO))
> ret = boot_selected_os(argc, argv, BOOTM_STATE_OS_GO,
> images, boot_fn);
> -   if (ret)
> -   goto err;
> -   }
> -
> -   return ret;
>
> /* Deal with any fallout */
>  err:
> --
> 1.7.9.5
>
>
Yes I missed your previous change which solved this problem. This patch
looks good to me, thanks.

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

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

[Albert ARIBAUD]

Hi Minkyu,

On Wed, 10 Jul 2013 21:24:47 +0900, Minkyu Kang 
wrote:

> Dear Albert,
> 
> The following changes since commit 7737c994609ffb50194d5ddb67467ae0fcd8f775:
> 
>   net2big_v2: initialize LEDs at startup (2013-06-20 14:01:23 +0530)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-samsung master
> 
> for you to fetch changes up to 1ae76d438b602fe8be1f0ef8b8ce47c89d371047:
> 
>   EXYNOS: Resolve the i2c compilation error (2013-07-10 14:20:26 +0900)
> 
> 
> Ajay Kumar (1):
>   video: exynos_fb: Add the missing #else clause
> 
> Amar (2):
>   EXYNOS5: I2C: Add FDT and non-FDT support for I2C
>   EXYNOS: Resolve the i2c compilation error
> 
> Axel Lin (2):
>   gpio: s3c2440_gpio: Fix wrong writel arguments
>   gpio: s5p_gpio: Call s5p_gpio_set_value() instead of open-code
> 
> Bernie Thompson (1):
>   exynos: Adjust the starting MIF voltage to 1.05v
> 
> Minkyu Kang (1):
>   arm: exynos: fix clock calculation
> 
> Rajeshwari Shinde (9):
>   EXYNOS5: FDT: Add compatible strings for Serial
>   EXYNOS5: FDT: Add serial device node values
>   S5P: Serial: Add fdt support to driver
>   CONFIG: EXYNOS5: Enable silent console
>   SMDK5250: Remove reduntant code
>   EXYNOS: Add API for power reset and exit wakeup
>   EXYNOS: LDS file move to common
>   EXYNOS4210: Configure GPIO for uart
>   EXYNOS: Move files from board/samsung to arch/arm
> 
> Simon Glass (1):
>   exynos: Enable mmc for snow
> 
> Łukasz Majewski (2):
>   arm:trats: Increase malloc pool size (for DFU ext4 transfers)
>   power:bat:trats: Break battery charging with ctrl+C
> 
>  arch/arm/cpu/armv7/exynos/Makefile |   17 +-
>  arch/arm/cpu/armv7/exynos/clock.c  |   43 +-
>  .../arm/cpu/armv7/exynos}/clock_init.h |0
>  arch/arm/cpu/armv7/exynos/clock_init_exynos4.c |   95 +
>  .../arm/cpu/armv7/exynos/clock_init_exynos5.c  |   56 +--
>  arch/arm/cpu/armv7/exynos/common_setup.h   |   45 +++
>  .../arm/cpu/armv7/exynos}/dmc_common.c |7 +-
>  .../arm/cpu/armv7/exynos}/dmc_init_ddr3.c  |   27 +-
>  arch/arm/cpu/armv7/exynos/dmc_init_exynos4.c   |  213 ++
>  .../arm/cpu/armv7/exynos/exynos4_setup.h   |  397 +-
>  .../arm/cpu/armv7/exynos/exynos5_setup.h   |   28 +-
>  arch/arm/cpu/armv7/exynos/lowlevel_init.c  |   73 
>  arch/arm/cpu/armv7/exynos/pinmux.c |   40 ++
>  arch/arm/cpu/armv7/exynos/power.c  |   50 +++
>  .../arm/cpu/armv7/exynos}/spl_boot.c   |   84 +++-
>  arch/arm/dts/exynos5250.dtsi   |   27 ++
>  arch/arm/include/asm/arch-exynos/cpu.h |   13 +-
>  arch/arm/include/asm/arch-exynos/power.h   |   12 +
>  arch/arm/include/asm/arch-exynos/spl.h |1 +
>  .../exynos-uboot-spl.lds}  |0
>  board/samsung/dts/exynos5250-smdk5250.dts  |2 +
>  board/samsung/dts/exynos5250-snow.dts  |   26 ++
>  board/samsung/origen/Makefile  |   11 +-
>  board/samsung/origen/lowlevel_init.S   |  357 -
>  board/samsung/origen/mem_setup.S   |  421 
> 
>  board/samsung/origen/mmc_boot.c|   58 ---
>  board/samsung/origen/origen.c  |   46 +++
>  board/samsung/smdk5250/Makefile|   14 +-
>  board/samsung/smdk5250/smdk5250.c  |   12 +-
>  board/samsung/smdkv310/Makefile|   10 +-
>  board/samsung/smdkv310/lowlevel_init.S |  414 ---
>  board/samsung/smdkv310/mem_setup.S |  365 -
>  board/samsung/smdkv310/mmc_boot.c  |   60 ---
>  board/samsung/smdkv310/smdkv310.c  |   46 +++
>  drivers/gpio/s3c2440_gpio.c|6 +-
>  drivers/gpio/s5p_gpio.c|9 +-
>  drivers/i2c/s3c24x0_i2c.c  |3 +-
>  drivers/power/battery/bat_trats.c  |   13 +-
>  drivers/power/power_core.c |3 +-
>  drivers/serial/serial_s5p.c|   78 
>  drivers/video/exynos_fimd.c|3 +-
>  include/configs/exynos5250-dt.h|   12 +-
>  include/configs/origen.h   |9 +-
>  include/configs/smdkv310.h |8 +-
>  include/configs/trats.h|2 +-
>  include/fdtdec.h   |1 +
>  include/power/max77686_pmic.h  |2 +
>  lib/fdtdec.c   |1 +
>  48 files changed, 1194 insertions(+), 2026 deletions(-)
>  rename {board/samsung/smdk5250 => arch

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

[Albert ARIBAUD]

Hello Tom,

The following changes since commit
fbf87b1823dd5ebc2a384711ea2c677543019ece:

  arm: optimize relocate_code routine (2013-06-21 23:05:50 +0200)

are available in the git repository at:

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

for you to fetch changes up to 630aacb0859c6e26b2b0311d8e245da5e5b8ac67:

  Merge branch 'u-boot-samsung/master' into
  'u-boot-arm/master' (2013-07-10 20:40:47 +0200)



Ajay Kumar (1):
  video: exynos_fb: Add the missing #else clause

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

Amar (2):
  EXYNOS5: I2C: Add FDT and non-FDT support for I2C
  EXYNOS: Resolve the i2c compilation error

Axel Lin (3):
  gpio: s3c2440_gpio: Fix wrong writel arguments
  gpio: s5p_gpio: Call s5p_gpio_set_value() instead of open-code
  ARM: OMAP: GPIO: Fix valid range and enable usage of all GPIOs on
OMAP5

Bernie Thompson (1):
  exynos: Adjust the starting MIF voltage to 1.05v

Dirk Behme (2):
  spi: mxc_spi: Fix pre and post divider calculation
  spi: mxc_spi: Update pre and post divider algorithm

Eric Nelson (1):
  dwc_ahsata: Allow use with dcache enabled

Fabio Estevam (8):
  README: mx28_common: Keep the text within 80 columns
  README: mx28_common: Do not hardcode the SSP port
  README: mx28_common: Fix structure of sentence
  README: mxs: Introduce README.mxs
  mx28evk: Move README file inside board directory
  m28evk: Move README file inside board directory
  MAINTAINERS: Add an entry to the mx6q wandboard variant
  video: mxsfb: Break the line in videomode message

Ilya Ledvich (1):
  am33xx: fix the ddr_cmdtctrl structure

Lokesh Vutla (1):
  ARM: OMAP4+: Fix MA detection during SDRAM_AUTO_DETECTION

Michael Trimarchi (1):
  usb: omap: ulpi: fix ulpi transceiver access

Mike Dunn (5):
  pxa: add support for palmtreo680 board
  pxa: palmtreo680 flash programming utility
  pxa: turn icache off in cpu_init_crit()
  pxa: use -mcpu=xscale compiler option
  pxa: fix memory coherency problem after relocation

Minkyu Kang (1):
  arm: exynos: fix clock calculation

Otavio Salvador (2):
  vf610twr: Add default environment in line with other Freescale
boards vf610twr: Remove SoC name from U-Boot prompt

Pierre Aubert (3):
  imx6: fix GPR2 wrong definition
  imx: Complete the pin definitions for the i.MX6DL / i.MX6Solo
  imx: Add support for the SabreSD shipped with i.MX6DL

Rajeshwari Shinde (9):
  EXYNOS5: FDT: Add compatible strings for Serial
  EXYNOS5: FDT: Add serial device node values
  S5P: Serial: Add fdt support to driver
  CONFIG: EXYNOS5: Enable silent console
  SMDK5250: Remove reduntant code
  EXYNOS: Add API for power reset and exit wakeup
  EXYNOS: LDS file move to common
  EXYNOS4210: Configure GPIO for uart
  EXYNOS: Move files from board/samsung to arch/arm

Robert Winkler (4):
  imx: nitrogen6x: Enabled data cache
  imx: nitrogen6x: Enable bootz
  imx: nitrogen6x: Enable raw initrd
  imx: nitrogen6x: Enable filesystem generic commands

Simon Glass (1):
  exynos: Enable mmc for snow

Tapani Utriainen (1):
  Add support for Wandboard Quad

trem (2):
  mx27: add function enable_caches
  mx27: add i2c clock

Łukasz Majewski (2):
  arm:trats: Increase malloc pool size (for DFU ext4 transfers)
  power:bat:trats: Break battery charging with ctrl+C

 CREDITS|4 +
 MAINTAINERS|7 +-
 arch/arm/cpu/arm926ejs/mx27/generic.c  |   10 +
 arch/arm/cpu/armv7/exynos/Makefile |   17 +-
 arch/arm/cpu/armv7/exynos/clock.c  |   43 +-
 .../arm/cpu/armv7/exynos}/clock_init.h |0
 arch/arm/cpu/armv7/exynos/clock_init_exynos4.c |   95 ++
 .../arm/cpu/armv7/exynos/clock_init_exynos5.c  |   56 +-
 arch/arm/cpu/armv7/exynos/common_setup.h   |   45 +
 .../arm/cpu/armv7/exynos}/dmc_common.c |7 +-
 .../arm/cpu/armv7/exynos}/dmc_init_ddr3.c  |   27 +-
 arch/arm/cpu/armv7/exynos/dmc_init_exynos4.c   |  213 +++
 .../arm/cpu/armv7/exynos/exynos4_setup.h   |  397 +++--
 .../arm/cpu/armv7/exynos/exynos5_setup.h   |   28 +-
 arch/arm/cpu/armv7/exynos/lowlevel_init.c  |   73 +
 arch/arm/cpu/armv7/exynos/pinmux.c |   40 +
 arch/arm/cpu/armv7/exynos/power.c  |   50 +
 .../arm/cpu/armv7/exynos}/spl_boot.c   |   84 +-
 arch/arm/cpu/armv7/omap-common/emif-common.c   |3 +
 arch/arm/cpu/armv7/omap5/hw_data.c |2 +
 arch/arm/cpu/armv7/omap5/hwinit.c  |4 +-
 arch/arm/cpu/pxa/config.mk |2 +-
 arch/arm/cpu/pxa/start.S   

Re: [U-Boot] [[PATCH v2 5/6] USB: ehci: Add a weak function for resetting devices

[Marek Vasut]

Dear Dan Murphy,

> Add a __weak function that can be overridden to reset devices
> attached to an ehci devices after the FEAT_POWER has been submitted
> 
> Signed-off-by: Dan Murphy 
> ---
>  drivers/usb/host/ehci-hcd.c |7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
> index 706cf0c..fdd3994 100644
> --- a/drivers/usb/host/ehci-hcd.c
> +++ b/drivers/usb/host/ehci-hcd.c
> @@ -616,6 +616,11 @@ __weak uint32_t *ehci_get_portsc_register(struct
> ehci_hcor *hcor, int port) return (uint32_t *)&hcor->or_portsc[port];
>  }
> 
> +__weak void ehci_reset_attached_devices(int port)
> +{
> + return;
> +}
> +

Can the reset not happen elsewhere?

>  int
>  ehci_submit_root(struct usb_device *dev, unsigned long pipe, void *buffer,
>int length, struct devrequest *req)
> @@ -777,6 +782,7 @@ ehci_submit_root(struct usb_device *dev, unsigned long
> pipe, void *buffer, reg |= EHCI_PS_PP;
>   ehci_writel(status_reg, reg);
>   }
> + ehci_reset_attached_devices(port);
>   break;
>   case USB_PORT_FEAT_RESET:
>   if ((reg & (EHCI_PS_PE | EHCI_PS_CS)) == EHCI_PS_CS &&
> @@ -794,6 +800,7 @@ ehci_submit_root(struct usb_device *dev, unsigned long
> pipe, void *buffer, reg |= EHCI_PS_PR;
>   reg &= ~EHCI_PS_PE;
>   ehci_writel(status_reg, reg);
> +

NAK

>   /*
>* caller must wait, then call GetPortStatus
>* usb 2.0 specification say 50 ms resets on

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

Re: [U-Boot] [[PATCH v2 5/6] USB: ehci: Add a weak function for resetting devices

[Dan Murphy]

On 07/10/2013 05:20 PM, Marek Vasut wrote:
> Dear Dan Murphy,
>
>> Add a __weak function that can be overridden to reset devices
>> attached to an ehci devices after the FEAT_POWER has been submitted
>>
>> Signed-off-by: Dan Murphy 
>> ---
>>  drivers/usb/host/ehci-hcd.c |7 +++
>>  1 file changed, 7 insertions(+)
>>
>> diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
>> index 706cf0c..fdd3994 100644
>> --- a/drivers/usb/host/ehci-hcd.c
>> +++ b/drivers/usb/host/ehci-hcd.c
>> @@ -616,6 +616,11 @@ __weak uint32_t *ehci_get_portsc_register(struct
>> ehci_hcor *hcor, int port) return (uint32_t *)&hcor->or_portsc[port];
>>  }
>>
>> +__weak void ehci_reset_attached_devices(int port)
>> +{
>> +return;
>> +}
>> +
> Can the reset not happen elsewhere?
I have tried to move this around and keep this out of this file completely but 
nothing else seems to work.

For port 2 where the USB3530 is we don't have the issue the 3530 enumerates 
properly.

I did not see any information in the data sheet eluding to a timing issue.
>
>>  int
>>  ehci_submit_root(struct usb_device *dev, unsigned long pipe, void *buffer,
>>   int length, struct devrequest *req)
>> @@ -777,6 +782,7 @@ ehci_submit_root(struct usb_device *dev, unsigned long
>> pipe, void *buffer, reg |= EHCI_PS_PP;
>>  ehci_writel(status_reg, reg);
>>  }
>> +ehci_reset_attached_devices(port);
>>  break;
>>  case USB_PORT_FEAT_RESET:
>>  if ((reg & (EHCI_PS_PE | EHCI_PS_CS)) == EHCI_PS_CS &&
>> @@ -794,6 +800,7 @@ ehci_submit_root(struct usb_device *dev, unsigned long
>> pipe, void *buffer, reg |= EHCI_PS_PR;
>>  reg &= ~EHCI_PS_PE;
>>  ehci_writel(status_reg, reg);
>> +
> NAK
DOH!
>
>>  /*
>>   * caller must wait, then call GetPortStatus
>>   * usb 2.0 specification say 50 ms resets on
> Best regards,
> Marek Vasut


-- 
--
Dan Murphy

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

[U-Boot] [PATCH] image: Don't relocate ramdisk to highmem

[Thierry Reding]

From: Thierry Reding 

The Linux kernel cannot unpack a ramdisk that's stored in high memory.
Unless the initrd_high environment variable is explicitly set, abide by
that restriction using the getenv_bootm_low() and getenv_bootm_mapsize()
helpers.

Signed-off-by: Thierry Reding 
---
 common/image.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/common/image.c b/common/image.c
index e91c89e..bc79b43 100644
--- a/common/image.c
+++ b/common/image.c
@@ -1090,8 +1090,8 @@ int boot_ramdisk_high(struct lmb *lmb, ulong rd_data, 
ulong rd_len,
if (initrd_high == ~0)
initrd_copy_to_ram = 0;
} else {
-   /* not set, no restrictions to load high */
-   initrd_high = ~0;
+   /* make sure to put ramdisk in low memory */
+   initrd_high = getenv_bootm_low() + getenv_bootm_mapsize();
}
 
 
-- 
1.8.1.5

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

Re: [U-Boot] [[PATCH v2 1/6] omap5: uevm: Change the board name to correct name

[Nishanth Menon]

On 07/10/2013 03:05 PM, Dan Murphy wrote:

Change the board name for the sys info to
5432 uEVM

Signed-off-by: Dan Murphy 
---
  board/ti/omap5_uevm/evm.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/ti/omap5_uevm/evm.c b/board/ti/omap5_uevm/evm.c
index 90046e8..00bd72d 100644
--- a/board/ti/omap5_uevm/evm.c
+++ b/board/ti/omap5_uevm/evm.c
@@ -32,7 +32,7 @@
  DECLARE_GLOBAL_DATA_PTR;

  const struct omap_sysinfo sysinfo = {
-   "Board: OMAP5430 EVM\n"
+   "Board: OMAP5432 uEVM\n"
  };

  /**


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

Re: [U-Boot] [[PATCH v3 2/2] gpio: omap5-uevm: Configure the tca6424 gpio expander

[Nishanth Menon]

On 07/10/2013 03:06 PM, Dan Murphy wrote:

Configure the tca6424 gpio expander
This allows use of the debug and tri color LEDs.

Signed-off-by: Dan Murphy 
---
  board/ti/omap5_uevm/evm.c  |   21 +
  board/ti/omap5_uevm/mux_data.h |2 ++
  include/configs/omap5_uevm.h   |5 +
  3 files changed, 28 insertions(+)

diff --git a/board/ti/omap5_uevm/evm.c b/board/ti/omap5_uevm/evm.c
index 90046e8..0e9a559 100644
--- a/board/ti/omap5_uevm/evm.c
+++ b/board/ti/omap5_uevm/evm.c
@@ -26,6 +26,7 @@
  #include 
  #include 
  #include 
+#include 

  #include "mux_data.h"

@@ -35,6 +36,24 @@ const struct omap_sysinfo sysinfo = {
"Board: OMAP5430 EVM\n"
  };

+/* @brief tca642x_init - Initial states for the GPIO expander

documentation style?
/*
 * @brief
?

+ * input reg, output reg, polarity reg, configuration reg
+ */
+struct tca642x_bank_info tca642x_init[] = {
+   { .input_reg = 0x00,
+ .output_reg = 0x04,
+ .polarity_reg = 0x00,
+ .configuration_reg = 0x80 },
+   { .input_reg = 0x00,
+ .output_reg = 0x00,
+ .polarity_reg = 0x00,
+ .configuration_reg = 0xff },
+   { .input_reg = 0x00,
+ .output_reg = 0x00,
+ .polarity_reg = 0x00,
+ .configuration_reg = 0x40 },
+};
+
  /**
   * @brief board_init
   *
@@ -46,6 +65,8 @@ int board_init(void)
gd->bd->bi_arch_number = MACH_TYPE_OMAP5_SEVM;
gd->bd->bi_boot_params = (0x8000 + 0x100); /* boot param addr */

+   tca642x_set_inital_state(CONFIG_SYS_I2C_TCA642X_ADDR, tca642x_init);
+
return 0;
  }

diff --git a/board/ti/omap5_uevm/mux_data.h b/board/ti/omap5_uevm/mux_data.h
index a82795d..7e6415e 100644
--- a/board/ti/omap5_uevm/mux_data.h
+++ b/board/ti/omap5_uevm/mux_data.h
@@ -56,6 +56,8 @@ const struct pad_conf_entry core_padconf_array_essential[] = {
{USBD0_HS_DP, (IEN | M0)},  /*  USBD0_HS_DP */
{USBD0_HS_DM, (IEN | M0)},  /*  USBD0_HS_DM */
{USBD0_SS_RX, (IEN | M0)},  /*  USBD0_SS_RX */
+   {I2C5_SCL, (IEN | M0)}, /* I2C5_SCL */
nit pick -> SCL (or i2c clk) is out put from master - always. IEN 
enables full duplex, but anyways.. just a nitpick :)



+   {I2C5_SDA, (IEN | M0)}, /* I2C5_SDA */

  };

diff --git a/include/configs/omap5_uevm.h b/include/configs/omap5_uevm.h
index 46dacc2..bee1278 100644
--- a/include/configs/omap5_uevm.h
+++ b/include/configs/omap5_uevm.h
@@ -53,6 +53,11 @@
  #define CONFIG_PARTITION_UUIDS
  #define CONFIG_CMD_PART

+#define CONFIG_TCA642X
+#define CONFIG_CMD_TCA642X
+#define CONFIG_SYS_I2C_TCA642X_BUS_NUM 4
+#define CONFIG_SYS_I2C_TCA642X_ADDR 0x22
+
  #define CONFIG_SYS_PROMPT "OMAP5432 uEVM # "

  #define CONSOLEDEV"ttyO2"



Else,
no further comments from me.
--
Regards,
Nishanth Menon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/7] dra7xx_evm: add SPL API, QSPI, and serial flash support

[Nishanth Menon]

[...]

diff --git a/board/ti/dra7xx/mux_data.h b/board/ti/dra7xx/mux_data.h
index 338a241..2441c55 100644
--- a/board/ti/dra7xx/mux_data.h
+++ b/board/ti/dra7xx/mux_data.h
@@ -53,5 +53,15 @@ const struct pad_conf_entry core_padconf_array_essential[] = 
{
{UART1_RTSN, (IEN | PTU | PDIS | M3)},  /* UART1_RTSN */
{I2C1_SDA, (IEN | PTU | PDIS | M0)},/* I2C1_SDA */
{I2C1_SCL, (IEN | PTU | PDIS | M0)},/* I2C1_SCL */
+   {GPMC_A13, (IEN | PDIS | M1)},  /* QSPI1_RTCLK */
+   {GPMC_A14, (IEN | PDIS | M1)},  /* QSPI1_D[3] */
+   {GPMC_A15, (IEN | PDIS | M1)},  /* QSPI1_D[2] */
+   {GPMC_A16, (IEN | PDIS | M1)},  /* QSPI1_D[1] */
+   {GPMC_A17, (IEN | PDIS | M1)},  /* QSPI1_D[0] */
+   {GPMC_A18, (IEN | PDIS | M1)},  /* QSPI1_SCLK */
+   {GPMC_A3, (IEN | PDIS | M1)},   /* QSPI1_CS2 */
+   {GPMC_A4, (IEN | PDIS | M1)},   /* QSPI1_CS3 */
+   {GPMC_CS2, (IEN | PTU | PDIS | M1)},/* QSPI1_CS0 */
+   {GPMC_CS3, (IEN | PTU | PDIS | M1)},/* QSPI1_CS1*/
Just a nitpick - Could someone audit this to ensure that only input/full 
duplex pins are set to IEN(Input Enable)?

Chip select (CS), SCLK, RTCLK dont seem to be candidates for input to DRA.

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

Re: [U-Boot] [[PATCH v2 3/6] ARM: OMAP5: USB: Add OMAP5 common USB EHCI information

[Lokesh Vutla]

On Thursday 11 July 2013 01:35 AM, Dan Murphy wrote:
> * Enable the OMAP5 EHCI host clocks
> * Add OMAP5 EHCI register definitions
> * Add OMAP5 ES2 host revision
> 
> Signed-off-by: Dan Murphy 
> ---
>  arch/arm/cpu/armv7/omap5/hw_data.c  |   13 ++
>  arch/arm/include/asm/arch-omap5/clock.h |6 +
>  arch/arm/include/asm/arch-omap5/ehci.h  |   43 
> +++
>  arch/arm/include/asm/ehci-omap.h|1 +
>  drivers/usb/host/ehci-omap.c|2 +-
>  5 files changed, 64 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/include/asm/arch-omap5/ehci.h
> 
> diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c 
> b/arch/arm/cpu/armv7/omap5/hw_data.c
> index 56cf1f8..055f058 100644
> --- a/arch/arm/cpu/armv7/omap5/hw_data.c
> +++ b/arch/arm/cpu/armv7/omap5/hw_data.c
> @@ -412,6 +412,8 @@ void enable_basic_clocks(void)
>   (*prcm)->cm_l4per_gpio4_clkctrl,
>   (*prcm)->cm_l4per_gpio5_clkctrl,
>   (*prcm)->cm_l4per_gpio6_clkctrl,
> + (*prcm)->cm_clksel_usb_60mhz,
> + (*prcm)->cm_l3init_hsusbtll_clkctrl,
guard this with CONFIG_USB_EHCI please or it ll
throw an error for DRA7xx boards.
>   0
>   };
>  
> @@ -423,6 +425,7 @@ void enable_basic_clocks(void)
>   (*prcm)->cm_wkup_wdtimer2_clkctrl,
>   (*prcm)->cm_l4per_uart3_clkctrl,
>   (*prcm)->cm_l4per_i2c1_clkctrl,
> + (*prcm)->cm_l3init_hsusbhost_clkctrl,
same here...

Thanks,
Lokesh
>   0
>   };
>  
> @@ -446,6 +449,16 @@ void enable_basic_clocks(void)
>   setbits_le32((*prcm)->cm_wkup_gptimer1_clkctrl,
>   GPTIMER1_CLKCTRL_CLKSEL_MASK);
>  
> +#ifdef CONFIG_USB_EHCI
> + /* Enable port 2 and 3 clocks*/
> + setbits_le32((*prcm)->cm_l3init_hsusbhost_clkctrl,
> + USB_HOST_HS_CLKCTRL_MASK);
> +
> + /* Enable all 3 usb host ports tll clocks*/
> + setbits_le32((*prcm)->cm_l3init_hsusbtll_clkctrl,
> + USB_TLL_HS_CLKCTRL_MASK);
> +#endif
> +
>   do_enable_clocks(clk_domains_essential,
>clk_modules_hw_auto_essential,
>clk_modules_explicit_en_essential,
> diff --git a/arch/arm/include/asm/arch-omap5/clock.h 
> b/arch/arm/include/asm/arch-omap5/clock.h
> index 4d2765d..3a58337 100644
> --- a/arch/arm/include/asm/arch-omap5/clock.h
> +++ b/arch/arm/include/asm/arch-omap5/clock.h
> @@ -165,6 +165,12 @@
>  /* CM_L3INIT_USBPHY_CLKCTRL */
>  #define USBPHY_CLKCTRL_OPTFCLKEN_PHY_48M_MASK8
>  
> +/* CM_L3INIT_USB_HOST_HS_CLKCTRL */
> +#define USB_HOST_HS_CLKCTRL_MASK 0x56C0
> +
> +/* CM_L3INIT_USB_TLL_HS_CLKCTRL */
> +#define USB_TLL_HS_CLKCTRL_MASK  0x700
> +
>  /* CM_MPU_MPU_CLKCTRL */
>  #define MPU_CLKCTRL_CLKSEL_EMIF_DIV_MODE_SHIFT   24
>  #define MPU_CLKCTRL_CLKSEL_EMIF_DIV_MODE_MASK(3 << 24)
> diff --git a/arch/arm/include/asm/arch-omap5/ehci.h 
> b/arch/arm/include/asm/arch-omap5/ehci.h
> new file mode 100644
> index 000..3921e4a
> --- /dev/null
> +++ b/arch/arm/include/asm/arch-omap5/ehci.h
> @@ -0,0 +1,43 @@
> +/*
> + * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com*
> + * Author: Govindraj R 
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
> + * MA 02111-1307 USA
> + */
> +
> +#ifndef _EHCI_H
> +#define _EHCI_H
> +
> +#define OMAP_EHCI_BASE   (OMAP54XX_L4_CORE_BASE 
> + 0x64C00)
> +#define OMAP_UHH_BASE(OMAP54XX_L4_CORE_BASE 
> + 0x64000)
> +#define OMAP_USBTLL_BASE (OMAP54XX_L4_CORE_BASE + 
> 0x62000)
> +
> +/* TLL Register Set */
> +#define OMAP_USBTLL_SYSCONFIG_SIDLEMODE  (1 << 3)
> +#define OMAP_USBTLL_SYSCONFIG_ENAWAKEUP  (1 << 2)
> +#define OMAP_USBTLL_SYSCONFIG_SOFTRESET  (1 << 1)
> +#define OMAP_USBTLL_SYSCONFIG_CACTIVITY  (1 << 8)
> +#define OMAP_USBTLL_SYSSTATUS_RESETDONE  1
> +
> +#define OMAP_UHH_SYSCONFIG_SOFTRESET 1
> +#define OMAP_UHH_SYSSTATUS_EHCI_RESETDONE(1 << 2)
> +#define OMAP_UHH_SYSCONFIG_NOIDLE(1 << 2)
> +#define OMAP_UHH_SYSCONFIG_NOSTDBY   (1 << 4)
> +
> +#define OMAP_UHH_SYSCONFIG_VAL   (OMAP_U

Re: [U-Boot] Separately compile Master boot loader

[Rajdeep Vaghasia]

Hi Albert,

I would like to explain you my exact idea.
For that, The Partition layout is:
1) Master u-boot
2) u-boot-1
3) u-boot-2
4) kernel
5) filesystem
6) data

Sometimes, When we may require to update with a new u-boot(to provide some
additional support), we have to overwrite the existing u-boot.
I don't want to overwrite the existing u-boot.
Instead, I want to keep a separate partition for new u-boot.

*Here is the whole procedure:*
I will maintain one environment variable(say "*safe_u-boot*"), which will
be used to point to the current 'working u-boot' partition(means, *u-boot-1*
).

I will develop one simple user space application.
Whenever a new u-boot is available, It will be first copied into the SDRAM
by this application.
Then, This application will check the environment variable "*new_u-boot*"
which will be pointing to second u-boot partition("u-boot-2") in flash.
And then, it will copy the new u-boot from SDRAM to *NOR flash* on the
partition pointed to by the "*new_u-boot*" environment variable, and then
mark one update flag(say, *u_boot_UPDATE*) as '*1*' and reboot the system.
This update flag is readable/writable by u-boot, kernel and user
application.

On reboot,
master u-boot(on every reboot or system power-up) will check this *
U_boot_UPDATE* flag  status.
If it is *set*, then Master u-boot will *first clear* that flag and then,
will load the u-boot from the partition pointed to by the "new_u-boot" env
variable.

case-1:
If the system is up successfully, the user space application will set the "*
safe_u-boot*" env variable to point the new partition(which was pointed to
by "*new_u-boot*") and set "*new_u-boot*" env variable to point to the
first u-boot partition(which was pointed to by "*safe_u-boot*"). (In short,
swapping of these environment variables). So, that on second time, when
system reboots, Master u-boot will see the *U_boot_UPDATE* flag *cleared*,
and will load the u-boot from the partition pointed to by "*safe_u-boot*",
which now contains the updated new u-boot.

case-2:
If the system fails and can not come up successfully with new u-boot, then
on *manual reboot*, Master u-boot will check the "*U_boot_UPDATE*" flag,
which will be in cleared state. (Because during update process, as soon as
Master U-boot reads this flag as set, it clears the flag). So, Master
U-boot will load the u-boot from the partition pointed to by the "*
safe_u-boot*" env variable(which is the working u-boot not updated
one.(say, u-boot-1)). As the swapping of these environment variables is
done by user application on successful update, this will not be the case
with this unsuccessful system up.

I hope everything is clear, now.
*So, in this overall implementation*,
I want to keep a little code of Master u-boot, which initializes SDRAM, and
copies secondary u-boot from flash to SDRAM. In addition to these, it keeps
track of two env variables.

Is there any separate source code available for this kind of Master U-boot?
*Or*
Can we compile the existing u-boot source code such that it will generate
only a small binary with these little functionalities?
*Or*
Can we compile the existing u-boot source code such that it will generate
both the binaries separately(master u-boot+secondary u-boot)?

Of course, even if Master u-boot is available, I will have to change that a
bit to implement those environment variable stuff in Master u-boot.

But this will be very helpful to me, if I get help from you.

I would like to remind again that, I want to implement this on *NOR Flash*.

Regards,
Rajdeep



On Wed, Jul 10, 2013 at 5:53 PM, Albert ARIBAUD
wrote:

> Hi Rajdeep,
>
> On Wed, 10 Jul 2013 15:04:12 +0530, Rajdeep Vaghasia
>  wrote:
>
> > Waiting for a reply.
>
> Well, maybe if you had not e-mailed your 8:32 AM answer to me but to
> the list... :)
>
> Here it is, with my comments.
>
> > On Tue, Jul 9, 2013 at 5:31 PM, Albert ARIBAUD <
> albert.u.b...@aribaud.net>wrote:
> >
> > > Hi Rajdeep,
> > >
> > > On Tue, 9 Jul 2013 16:12:14 +0530, Rajdeep Vaghasia
> > >  wrote:
> > >
> > > > Hi
> > > > I am working on one board with an arm11 based cpu, NOR flash and DDR2
> > > SDRAM.
> > > > When I compile u-boot source code, I get u-boot.bin image generated.
> > > > This image has primary(second stage) and secondary(third stage)
> > > bootloader
> > > > combined.
> > > >
> > > > I have following queries:
> > > > 1) The question that still eats me everyday is, How can I compile
> > > > primary(Master) boot loader and secondary boot loader separately?
> > > > 2) I want to Flash only initial 4kb of code (Master boot loader or
> second
> > > > stage). The remaining code I want to keep at another partition in the
> > > > Flash. How can I achieve this?
> > > > 3) Is there any separate code available for Master boot loader, which
> > > > copies the third stage bootloader to SDRAM and then transfers
> control to
> > > > that third stage boot loader(u-boot)?
> > > >
> > > > I am unable to find a way to do this.
> > > >
> > > > Can anyo

Re: [U-Boot] twister: usb host support

[Tapani]

Stefano, Jeroen,


On Wed, 10 Jul 2013 18:04:04 +0200
Jeroen Hofstee  wrote:

> Hello Stefano / Tapani,
> 
> On 07/10/2013 04:27 PM, Stefano Babic wrote:
> > On 09/07/2013 21:46, Jeroen Hofstee wrote:
> >> I cannot find any document mentioning gpio_25 though.
> >> Any reason for this usage?
> > That is right. There is no written documentation by Technexion about
> > this pin. I have added in CC Tapani, maybe he can tell us something more.
> > The GPIO is used internally on the TAM3517 SOM, and we have no
> > schematics about it. We have to guess about its usage.
> 
> Yes, and some clarification of the pin 35 would be
> appreciated as well, since it is marked as ball X, I guess
> it is controlled by hardware and the hub cannot be reset
> from software, but that is just guessing...
> 
> > The reason to have it is that the sources for the kernel provided by
> > Technexion (an ancient 2.6.32 Version) set this pin to reset the EHCI.
> > As I said, there is no further documentation and rather we can only make
> > some supposition. The usage in U-Boot then reflects the usage made by
> > Technexion.
> >
> 
> Fyi my linux copy (3.7) with this gpio set as the phy_reset is also
> unable to properly reset it and times out. The usb is working
> though, also without a proper reset..
> 
> >> p.s.
> >> I found by sheer accidence that the usb is behaving
> >> completely normal (after the patch) on rev B1. It is
> >> broken on rev B without the patch and working buggy
> >> with it. On rev B1 + patch the USB to SATA converter
> >> is discovered as well, which I have never seen before.
> >>
> > I can confirm issues with version B of the TAM3517-SOM. I am testing a
> > B1 SOM with a B twister. I do not know the details about changelog
> > between B and B1 version of the SOM, but I got both USB and Ethernet
> > problems with TAM3517-B. The same image runs without the same problems
> > on a B1.
> 
> ok, good to know.
> 
> > There is also this pending patch by Michael:
> >
> > http://patchwork.ozlabs.org/patch/250290/
> >
> > It is applied to u-boot-ti, not yet to mainline.
> >
> 
> on top of usb master this patch leads to:
> USB0:ULPI: ulpi_reset: failed writing reset bit
> ULPI:ulpi_reset: failed writing reset bit
> 
> It does always find the stick though and never the SATA converter.
> 
> without the gpio_25 reset, the second error goes away and
> the SATA is back.
> 
> >
> > @@ -92,9 +92,6 @@ int board_init(void)
> >   enable_gpmc_cs_config(gpmc_XR16L2751, &gpmc_cfg->cs[3],
> >   XR16L2751_UART2_BASE, GPMC_SIZE_16M);
> >
> > -gpio_request(CONFIG_OMAP_EHCI_PHY1_RESET_GPIO, "USB_PHY1_RESET");
> > -gpio_direction_output(CONFIG_OMAP_EHCI_PHY1_RESET_GPIO, 1);
> > -
> > See my concerns above. Do not reset the hub in the kernel ?
> 
> I don't get the last part, but feedback from Technexion is
> needed first to remove all the guess, maybe etc. If it has a
> valid function, not setting it's value might not be such a
> good idea...
>

GPIO_25 is indeed USB PHY reset. (Pull low to reset). 

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

Re: [U-Boot] [PATCH v2 5/5] bootm: Add the missing PREP stage to bootz and correct image handling

[Sughosh Ganu]

On Wed, Jul 10, 2013 at 3:21 PM, Sughosh Ganu wrote:

> hi Tom,
>
> On Tue Jul 09, 2013 at 05:19:32PM -0400, Tom Rini wrote:
>
> 
>
> > > Yes, I am not really comfortable with this. I will see if I can write
> some
> > > sandbox tests for the other image types today and post my results. I
> guess
> > > this bootm code has built up over a long time and it is hard to know
> all
> > > the ways it is used.
> >
> > Important, but I really want to see real-world booting in a case or two.
> > Unfortunately I don't have any ARM boards that work out of the box with
> > NetBSD.
>
> I have netbsd running on hawkboard, but i do not boot it using the
> bootm command, but use the go command instead. I will try to build a
> netbsd image with the u-boot header and give it a try with bootm. Need
> a day or two to check this out though.
>

Tried to boot netbsd with u-boot head 225fd8c5d45, and the boot fails. Was
able to boot netbsd with v2012.10 u-boot image. Btw, am i supposed to apply
any patch on top of the said commit.

hawkboard > bootm c300
## Booting kernel from Legacy Image at c300 ...
   Image Name:   Netbsd
   Image Type:   ARM NetBSD Kernel Image (uncompressed)
   Data Size:2329152 Bytes = 2.2 MiB
   Load Address: c020
   Entry Point:  c020
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK
subcommand not supported
hawkboard >

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

[U-Boot] [PATCH 0/4] Correct some remaining bootm problems

[Simon Glass]

The tortuous refactoring of bootm and fit_image_load() has thrown up
four more issues:

- Support for bootm (without arguments) on many OSes is broken since the
OS functions do not handle the PREP stage, which is now required
- In the case of loading a FIT image with a bootm-selected kernel
configuration, this is not used for ramdisk and fdt but must be manually
specified for each.
- The Elf image loader arguments are out by 1
- There is an extra OK message in the case of loading an uncompressed
kernel

This series corrects these problems. Verification was done using some
sandbox tests written for the occassion. These will be sent to the list
during the next merge window (or earlier if anyone wants to try them).

For the record the tests run are:

$ ./test/image/test-fit.py -u b/sandbox/u-boot
FIT Tests
=
Kernel load
Kernel + FDT load
Kernel + FDT + Ramdisk load
Kernel + FDT + Ramdisk load, Config 2

Tests passed
Caveat: this is only a sanity check - test coverage is poor
$ ./test/image/test-legacy.py -u b/sandbox/u-boot
Legacy Image Tests
==
Testing 22 image types
['netbsd', 'lynxos', 'rtems', 'ose', 'plan9', 'vxworks', 'qnx', 'integrity']
netbsd: False
netbsd: True
lynxos: False
lynxos: True
rtems: False
rtems: True
ose: False
ose: True
plan9: False
plan9: True
vxworks: False
vxworks: True
qnx: False
qnx: True
integrity: False
integrity: True

Tests passed
Caveat: this is only a sanity check - test coverage is poor


Simon Glass (4):
  bootm: Remove extra OK message
  blackfin: x86: bootm: Handle PREP stage of bootm
  bootm: Use selected configuration for ramdisk and fdt
  bootm: Correct the arguments for the ELF image loader

 arch/blackfin/lib/boot.c |  2 ++
 arch/x86/lib/bootm.c |  2 ++
 common/cmd_bootm.c   | 20 ++--
 common/cmd_elf.c |  6 +++---
 common/image-fdt.c   |  4 ++--
 common/image-fit.c   |  6 +-
 common/image.c   |  4 ++--
 include/image.h  |  7 ---
 8 files changed, 38 insertions(+), 13 deletions(-)

-- 
1.8.3

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

[U-Boot] [PATCH 4/4] bootm: Correct the arguments for the ELF image loader

[Simon Glass]

The arguments were out of place since commit 983c72f, since this file was
missed and not tested. Correct this.

Signed-off-by: Simon Glass 
---
 common/cmd_elf.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/common/cmd_elf.c b/common/cmd_elf.c
index ab9c7e3..f741f6b 100644
--- a/common/cmd_elf.c
+++ b/common/cmd_elf.c
@@ -156,16 +156,16 @@ int do_bootvx(cmd_tbl_t *cmdtp, int flag, int argc, char 
* const argv[])
 * If we don't know where the image is then we're done.
 */
 
-   if (argc < 2)
+   if (argc < 1)
addr = load_addr;
else
-   addr = simple_strtoul(argv[1], NULL, 16);
+   addr = simple_strtoul(argv[0], NULL, 16);
 
 #if defined(CONFIG_CMD_NET)
/*
 * Check to see if we need to tftp the image ourselves before starting
 */
-   if ((argc == 2) && (strcmp(argv[1], "tftp") == 0)) {
+   if ((argc == 1) && (strcmp(argv[0], "tftp") == 0)) {
if (NetLoop(TFTPGET) <= 0)
return 1;
printf("Automatic boot of VxWorks image at address 0x%08lx 
...\n",
-- 
1.8.3

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

[U-Boot] [PATCH 2/4] blackfin: x86: bootm: Handle PREP stage of bootm

[Simon Glass]

The OS function is now always called with the PREP stage. Adjust the
remaining bootm OS functions to deal with this correctly.

Signed-off-by: Simon Glass 
---
 arch/blackfin/lib/boot.c |  2 ++
 arch/x86/lib/bootm.c |  2 ++
 common/cmd_bootm.c   | 16 
 3 files changed, 20 insertions(+)

diff --git a/arch/blackfin/lib/boot.c b/arch/blackfin/lib/boot.c
index 768a882..5644d58 100644
--- a/arch/blackfin/lib/boot.c
+++ b/arch/blackfin/lib/boot.c
@@ -42,6 +42,8 @@ int do_bootm_linux(int flag, int argc, char * const argv[], 
bootm_headers_t *ima
int (*appl) (char *cmdline);
char*cmdline;
 
+   if (flag & BOOTM_STATE_OS_PREP)
+   return 0;
if ((flag != 0) && (flag != BOOTM_STATE_OS_GO))
return 1;
 
diff --git a/arch/x86/lib/bootm.c b/arch/x86/lib/bootm.c
index 0d3250c..b84e35a 100644
--- a/arch/x86/lib/bootm.c
+++ b/arch/x86/lib/bootm.c
@@ -48,6 +48,8 @@ int do_bootm_linux(int flag, int argc, char * const argv[],
size_t  len;
 #endif
 
+   if (flag & BOOTM_STATE_OS_PREP)
+   return 0;
if ((flag != 0) && (flag != BOOTM_STATE_OS_GO))
return 1;
 
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index 7a7c760..075e7dc 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -1473,6 +1473,8 @@ static int do_bootm_netbsd(int flag, int argc, char * 
const argv[],
char *consdev;
char *cmdline;
 
+   if (flag & BOOTM_STATE_OS_PREP)
+   return 0;
if ((flag != 0) && (flag != BOOTM_STATE_OS_GO))
return 1;
 
@@ -1552,6 +1554,8 @@ static int do_bootm_lynxkdi(int flag, int argc, char * 
const argv[],
 {
image_header_t *hdr = &images->legacy_hdr_os_copy;
 
+   if (flag & BOOTM_STATE_OS_PREP)
+   return 0;
if ((flag != 0) && (flag != BOOTM_STATE_OS_GO))
return 1;
 
@@ -1574,6 +1578,8 @@ static int do_bootm_rtems(int flag, int argc, char * 
const argv[],
 {
void (*entry_point)(bd_t *);
 
+   if (flag & BOOTM_STATE_OS_PREP)
+   return 0;
if ((flag != 0) && (flag != BOOTM_STATE_OS_GO))
return 1;
 
@@ -1607,6 +1613,8 @@ static int do_bootm_ose(int flag, int argc, char * const 
argv[],
 {
void (*entry_point)(void);
 
+   if (flag & BOOTM_STATE_OS_PREP)
+   return 0;
if ((flag != 0) && (flag != BOOTM_STATE_OS_GO))
return 1;
 
@@ -1641,6 +1649,8 @@ static int do_bootm_plan9(int flag, int argc, char * 
const argv[],
void (*entry_point)(void);
char *s;
 
+   if (flag & BOOTM_STATE_OS_PREP)
+   return 0;
if ((flag != 0) && (flag != BOOTM_STATE_OS_GO))
return 1;
 
@@ -1688,6 +1698,8 @@ static int do_bootm_vxworks(int flag, int argc, char * 
const argv[],
 {
char str[80];
 
+   if (flag & BOOTM_STATE_OS_PREP)
+   return 0;
if ((flag != 0) && (flag != BOOTM_STATE_OS_GO))
return 1;
 
@@ -1711,6 +1723,8 @@ static int do_bootm_qnxelf(int flag, int argc, char * 
const argv[],
char *local_args[2];
char str[16];
 
+   if (flag & BOOTM_STATE_OS_PREP)
+   return 0;
if ((flag != 0) && (flag != BOOTM_STATE_OS_GO))
return 1;
 
@@ -1736,6 +1750,8 @@ static int do_bootm_integrity(int flag, int argc, char * 
const argv[],
 {
void (*entry_point)(void);
 
+   if (flag & BOOTM_STATE_OS_PREP)
+   return 0;
if ((flag != 0) && (flag != BOOTM_STATE_OS_GO))
return 1;
 
-- 
1.8.3

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

[U-Boot] [PATCH 3/4] bootm: Use selected configuration for ramdisk and fdt

[Simon Glass]

If a specific configuraion is selected by the bootm command, e.g. with
'bootm 8400#recoveryconf' we must honour this for not just the kernel,
but also the ramdisk and FDT.

In the conversion to using a common fit_image_load() function for loading
images from FITs (commits a51ec63 and 53f375f) this feature was lost.
Reinstate it by passing the selected configuration back from
fit_image_load() to boot_get_kernel(), then use this configuration
(which is stored in images->fit_uname_cfg) in both boot_get_ramdisk()
and boot_get_fdt().

Signed-off-by: Simon Glass 
---
 common/cmd_bootm.c | 3 ++-
 common/image-fdt.c | 4 ++--
 common/image-fit.c | 6 +-
 common/image.c | 4 ++--
 include/image.h| 7 ---
 5 files changed, 15 insertions(+), 9 deletions(-)

diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index 075e7dc..c8bb33e 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -989,7 +989,7 @@ static const void *boot_get_kernel(cmd_tbl_t *cmdtp, int 
flag, int argc,
case IMAGE_FORMAT_FIT:
os_noffset = fit_image_load(images, FIT_KERNEL_PROP,
img_addr,
-   &fit_uname_kernel, fit_uname_config,
+   &fit_uname_kernel, &fit_uname_config,
IH_ARCH_DEFAULT, IH_TYPE_KERNEL,
BOOTSTAGE_ID_FIT_KERNEL_START,
FIT_LOAD_IGNORED, os_data, os_len);
@@ -998,6 +998,7 @@ static const void *boot_get_kernel(cmd_tbl_t *cmdtp, int 
flag, int argc,
 
images->fit_hdr_os = map_sysmem(img_addr, 0);
images->fit_uname_os = fit_uname_kernel;
+   images->fit_uname_cfg = fit_uname_config;
images->fit_noffset_os = os_noffset;
break;
 #endif
diff --git a/common/image-fdt.c b/common/image-fdt.c
index d99f444..203404a 100644
--- a/common/image-fdt.c
+++ b/common/image-fdt.c
@@ -243,7 +243,7 @@ int boot_get_fdt(int flag, int argc, char * const argv[], 
uint8_t arch,
ulong   load, load_end;
void*buf;
 #if defined(CONFIG_FIT)
-   const char  *fit_uname_config = NULL;
+   const char  *fit_uname_config = images->fit_uname_cfg;
const char  *fit_uname_fdt = NULL;
ulong   default_addr;
int fdt_noffset;
@@ -367,7 +367,7 @@ int boot_get_fdt(int flag, int argc, char * const argv[], 
uint8_t arch,
fdt_noffset = fit_image_load(images,
FIT_FDT_PROP,
fdt_addr, &fit_uname_fdt,
-   fit_uname_config,
+   &fit_uname_config,
arch, IH_TYPE_FLATDT,
BOOTSTAGE_ID_FIT_FDT_START,
FIT_LOAD_OPTIONAL, &load, &len);
diff --git a/common/image-fit.c b/common/image-fit.c
index b75e119..e28dd05 100644
--- a/common/image-fit.c
+++ b/common/image-fit.c
@@ -1478,12 +1478,13 @@ int fit_get_node_from_config(bootm_headers_t *images, 
const char *prop_name,
 }
 
 int fit_image_load(bootm_headers_t *images, const char *prop_name, ulong addr,
-  const char **fit_unamep, const char *fit_uname_config,
+  const char **fit_unamep, const char **fit_uname_configp,
   int arch, int image_type, int bootstage_id,
   enum fit_load_op load_op, ulong *datap, ulong *lenp)
 {
int cfg_noffset, noffset;
const char *fit_uname;
+   const char *fit_uname_config;
const void *fit;
const void *buf;
size_t size;
@@ -1493,6 +1494,7 @@ int fit_image_load(bootm_headers_t *images, const char 
*prop_name, ulong addr,
 
fit = map_sysmem(addr, 0);
fit_uname = fit_unamep ? *fit_unamep : NULL;
+   fit_uname_config = fit_uname_configp ? *fit_uname_configp : NULL;
printf("## Loading %s from FIT Image at %08lx ...\n", prop_name, addr);
 
bootstage_mark(bootstage_id + BOOTSTAGE_SUB_FORMAT);
@@ -1658,6 +1660,8 @@ int fit_image_load(bootm_headers_t *images, const char 
*prop_name, ulong addr,
*lenp = len;
if (fit_unamep)
*fit_unamep = (char *)fit_uname;
+   if (fit_uname_configp)
+   *fit_uname_configp = (char *)fit_uname_config;
 
return noffset;
 }
diff --git a/common/image.c b/common/image.c
index 1be384f..327006e 100644
--- a/common/image.c
+++ b/common/image.c
@@ -811,7 +811,7 @@ int boot_get_ramdisk(int argc, char * const argv[], 
bootm_headers_t *images,
char *end;
 #endif
 #if defined(CONFIG_FIT)
-   const char  *fit_uname_config = NULL;
+   const char  *fit_uname_config = images->fit_uname_cfg;
const char  *fit_uname_ramdisk = NULL;
ulong   default_addr;
int 

[U-Boot] [PATCH 1/4] bootm: Remove extra OK message

[Simon Glass]

This is not needed as we already print 'OK' later in all cases.

Signed-off-by: Simon Glass 
---
 common/cmd_bootm.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index a783cea..7a7c760 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -396,7 +396,6 @@ static int bootm_load_os(bootm_headers_t *images, unsigned 
long *load_end,
memmove_wd(load_buf, image_buf, image_len, CHUNKSZ);
}
*load_end = load + image_len;
-   puts("OK\n");
break;
 #ifdef CONFIG_GZIP
case IH_COMP_GZIP:
-- 
1.8.3

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

Re: [U-Boot] [PATCH 1/7] omap5: add qspi support

[Sourav Poddar]

On Wednesday 10 July 2013 06:53 PM, Nishanth Menon wrote:

On Wed, Jul 10, 2013 at 6:25 AM, Sourav Poddar  wrote:

From: Matt Porter

Add QSPI definitions and clock configuration support.


OMAP54xx does not have QSPI. DRA7 has QSPI?


Yes.

Signed-off-by: Matt Porter
Signed-off-by: Sourav Poddar
---
  arch/arm/cpu/armv7/omap5/hw_data.c |7 ++-
  arch/arm/cpu/armv7/omap5/prcm-regs.c   |1 +
  arch/arm/include/asm/arch-omap5/omap.h |3 +++
  arch/arm/include/asm/arch-omap5/spl.h  |1 +
  arch/arm/include/asm/omap_common.h |1 +
  5 files changed, 12 insertions(+), 1 deletions(-)

diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c 
b/arch/arm/cpu/armv7/omap5/hw_data.c
index 9374c6a..046ce44 100644
--- a/arch/arm/cpu/armv7/omap5/hw_data.c
+++ b/arch/arm/cpu/armv7/omap5/hw_data.c
@@ -186,7 +186,7 @@ static const struct dpll_params 
per_dpll_params_768mhz_es2[NUM_SYS_CLKS] = {

  static const struct dpll_params per_dpll_params_768mhz_dra7xx[NUM_SYS_CLKS] = 
{
 {32, 0, 4, 1, 3, 4, 10, 2, -1, -1, -1, -1}, /* 12 MHz   */
-   {96, 4, 4, 1, 3, 4, 10, 2, -1, -1, -1, -1}, /* 20 MHz   */
+   {96, 4, 4, 1, 3, 4, 4, 2, -1, -1, -1, -1},  /* 20 MHz   */

is this a separate fix?


Ahh..it can be send as a seperate fix actually. Will change.

 {160, 6, 4, 1, 3, 4, 10, 2, -1, -1, -1, -1},/* 16.8 MHz */
 {20, 0, 4, 1, 3, 4, 10, 2, -1, -1, -1, -1}, /* 19.2 MHz */
 {192, 12, 4, 1, 3, 4, 10, 2, -1, -1, -1, -1},   /* 26 MHz   */
@@ -423,6 +423,7 @@ void enable_basic_clocks(void)
 (*prcm)->cm_wkup_wdtimer2_clkctrl,
 (*prcm)->cm_l4per_uart3_clkctrl,
 (*prcm)->cm_l4per_i2c1_clkctrl,
+   (*prcm)->cm_l4per_qspi_clkctrl,
 0
 };

@@ -451,6 +452,10 @@ void enable_basic_clocks(void)
  clk_modules_explicit_en_essential,
  1);

+#ifdef CONFIG_TI_QSPI
+   setbits_le32((*prcm)->cm_l4per_qspi_clkctrl, (1<<24));
+#endif
+
 /* Enable SCRM OPT clocks for PER and CORE dpll */
 setbits_le32((*prcm)->cm_wkupaon_scrm_clkctrl,
 OPTFCLKEN_SCRM_PER_MASK);
diff --git a/arch/arm/cpu/armv7/omap5/prcm-regs.c 
b/arch/arm/cpu/armv7/omap5/prcm-regs.c
index 331117c..debc56b 100644
--- a/arch/arm/cpu/armv7/omap5/prcm-regs.c
+++ b/arch/arm/cpu/armv7/omap5/prcm-regs.c
@@ -926,6 +926,7 @@ struct prcm_regs const dra7xx_prcm = {
 .cm_l4per_gpio8_clkctrl = 0x4a009818,
 .cm_l4per_mmcsd3_clkctrl= 0x4a009820,
 .cm_l4per_mmcsd4_clkctrl= 0x4a009828,
+   .cm_l4per_qspi_clkctrl  = 0x4a009838,
 .cm_l4per_uart1_clkctrl = 0x4a009840,
 .cm_l4per_uart2_clkctrl = 0x4a009848,
 .cm_l4per_uart3_clkctrl = 0x4a009850,
diff --git a/arch/arm/include/asm/arch-omap5/omap.h 
b/arch/arm/include/asm/arch-omap5/omap.h
index e7d79fc..d2c4930 100644
--- a/arch/arm/include/asm/arch-omap5/omap.h
+++ b/arch/arm/include/asm/arch-omap5/omap.h
@@ -67,6 +67,9 @@
  /* GPMC */
  #define OMAP54XX_GPMC_BASE 0x5000

+/* QSPI */
+#define QSPI_BASE  0x4B30
+
  /*
   * Hardware Register Details
   */
diff --git a/arch/arm/include/asm/arch-omap5/spl.h 
b/arch/arm/include/asm/arch-omap5/spl.h
index d4d353c..8905cb8 100644
--- a/arch/arm/include/asm/arch-omap5/spl.h
+++ b/arch/arm/include/asm/arch-omap5/spl.h
@@ -31,6 +31,7 @@
  #define BOOT_DEVICE_MMC15
  #define BOOT_DEVICE_MMC26
  #define BOOT_DEVICE_MMC2_2 7
+#define BOOT_DEVICE_SPI10

why not 8?


  #define MMC_BOOT_DEVICES_START BOOT_DEVICE_MMC1
  #define MMC_BOOT_DEVICES_END   BOOT_DEVICE_MMC2_2
diff --git a/arch/arm/include/asm/omap_common.h 
b/arch/arm/include/asm/omap_common.h
index fa28358..c8d4619 100644
--- a/arch/arm/include/asm/omap_common.h
+++ b/arch/arm/include/asm/omap_common.h
@@ -279,6 +279,7 @@ struct prcm_regs {
 u32 cm_l4per_mmcsd4_clkctrl;
 u32 cm_l4per_msprohg_clkctrl;
 u32 cm_l4per_slimbus2_clkctrl;
+   u32 cm_l4per_qspi_clkctrl;
 u32 cm_l4per_uart1_clkctrl;
 u32 cm_l4per_uart2_clkctrl;
 u32 cm_l4per_uart3_clkctrl;
--
1.7.1

___
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 1/7] omap5: add qspi support

[Sourav Poddar]

On Wednesday 10 July 2013 07:10 PM, Lokesh Vutla wrote:

On Wednesday 10 July 2013 04:55 PM, Sourav Poddar wrote:

From: Matt Porter

Add QSPI definitions and clock configuration support.

Signed-off-by: Matt Porter
Signed-off-by: Sourav Poddar
---
  arch/arm/cpu/armv7/omap5/hw_data.c |7 ++-
  arch/arm/cpu/armv7/omap5/prcm-regs.c   |1 +
  arch/arm/include/asm/arch-omap5/omap.h |3 +++
  arch/arm/include/asm/arch-omap5/spl.h  |1 +
  arch/arm/include/asm/omap_common.h |1 +
  5 files changed, 12 insertions(+), 1 deletions(-)

diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c 
b/arch/arm/cpu/armv7/omap5/hw_data.c
index 9374c6a..046ce44 100644
--- a/arch/arm/cpu/armv7/omap5/hw_data.c
+++ b/arch/arm/cpu/armv7/omap5/hw_data.c
@@ -186,7 +186,7 @@ static const struct dpll_params 
per_dpll_params_768mhz_es2[NUM_SYS_CLKS] = {

  static const struct dpll_params per_dpll_params_768mhz_dra7xx[NUM_SYS_CLKS] = 
{
{32, 0, 4, 1, 3, 4, 10, 2, -1, -1, -1, -1}, /* 12 MHz   */
-   {96, 4, 4, 1, 3, 4, 10, 2, -1, -1, -1, -1}, /* 20 MHz   */
+   {96, 4, 4, 1, 3, 4, 4, 2, -1, -1, -1, -1},  /* 20 MHz   */
{160, 6, 4, 1, 3, 4, 10, 2, -1, -1, -1, -1},/* 16.8 MHz */
{20, 0, 4, 1, 3, 4, 10, 2, -1, -1, -1, -1}, /* 19.2 MHz */
{192, 12, 4, 1, 3, 4, 10, 2, -1, -1, -1, -1},   /* 26 MHz   */
@@ -423,6 +423,7 @@ void enable_basic_clocks(void)
(*prcm)->cm_wkup_wdtimer2_clkctrl,
(*prcm)->cm_l4per_uart3_clkctrl,
(*prcm)->cm_l4per_i2c1_clkctrl,
+   (*prcm)->cm_l4per_qspi_clkctrl,

Keep this also under CONFIG_TI_QSPI because we should enable QSPI clocks
only if support is available.


Ok.

Thanks,
Lokesh

0
};

@@ -451,6 +452,10 @@ void enable_basic_clocks(void)
 clk_modules_explicit_en_essential,
 1);

+#ifdef CONFIG_TI_QSPI
+   setbits_le32((*prcm)->cm_l4per_qspi_clkctrl, (1<<24));
+#endif
+
/* Enable SCRM OPT clocks for PER and CORE dpll */
setbits_le32((*prcm)->cm_wkupaon_scrm_clkctrl,
OPTFCLKEN_SCRM_PER_MASK);
diff --git a/arch/arm/cpu/armv7/omap5/prcm-regs.c 
b/arch/arm/cpu/armv7/omap5/prcm-regs.c
index 331117c..debc56b 100644
--- a/arch/arm/cpu/armv7/omap5/prcm-regs.c
+++ b/arch/arm/cpu/armv7/omap5/prcm-regs.c
@@ -926,6 +926,7 @@ struct prcm_regs const dra7xx_prcm = {
.cm_l4per_gpio8_clkctrl = 0x4a009818,
.cm_l4per_mmcsd3_clkctrl= 0x4a009820,
.cm_l4per_mmcsd4_clkctrl= 0x4a009828,
+   .cm_l4per_qspi_clkctrl  = 0x4a009838,
.cm_l4per_uart1_clkctrl = 0x4a009840,
.cm_l4per_uart2_clkctrl = 0x4a009848,
.cm_l4per_uart3_clkctrl = 0x4a009850,
diff --git a/arch/arm/include/asm/arch-omap5/omap.h 
b/arch/arm/include/asm/arch-omap5/omap.h
index e7d79fc..d2c4930 100644
--- a/arch/arm/include/asm/arch-omap5/omap.h
+++ b/arch/arm/include/asm/arch-omap5/omap.h
@@ -67,6 +67,9 @@
  /* GPMC */
  #define OMAP54XX_GPMC_BASE0x5000

+/* QSPI */
+#define QSPI_BASE  0x4B30
+
  /*
   * Hardware Register Details
   */
diff --git a/arch/arm/include/asm/arch-omap5/spl.h 
b/arch/arm/include/asm/arch-omap5/spl.h
index d4d353c..8905cb8 100644
--- a/arch/arm/include/asm/arch-omap5/spl.h
+++ b/arch/arm/include/asm/arch-omap5/spl.h
@@ -31,6 +31,7 @@
  #define BOOT_DEVICE_MMC15
  #define BOOT_DEVICE_MMC26
  #define BOOT_DEVICE_MMC2_27
+#define BOOT_DEVICE_SPI10

  #define MMC_BOOT_DEVICES_STARTBOOT_DEVICE_MMC1
  #define MMC_BOOT_DEVICES_END  BOOT_DEVICE_MMC2_2
diff --git a/arch/arm/include/asm/omap_common.h 
b/arch/arm/include/asm/omap_common.h
index fa28358..c8d4619 100644
--- a/arch/arm/include/asm/omap_common.h
+++ b/arch/arm/include/asm/omap_common.h
@@ -279,6 +279,7 @@ struct prcm_regs {
u32 cm_l4per_mmcsd4_clkctrl;
u32 cm_l4per_msprohg_clkctrl;
u32 cm_l4per_slimbus2_clkctrl;
+   u32 cm_l4per_qspi_clkctrl;
u32 cm_l4per_uart1_clkctrl;
u32 cm_l4per_uart2_clkctrl;
u32 cm_l4per_uart3_clkctrl;



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

Re: [U-Boot] [PATCH 1/7] omap5: add qspi support

[Sourav Poddar]

On Wednesday 10 July 2013 07:13 PM, Tom Rini wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/10/2013 09:23 AM, Nishanth Menon wrote:

On Wed, Jul 10, 2013 at 6:25 AM, Sourav Poddar
  wrote:

From: Matt Porter

I think it's good form to update folks addresses, Matt is now
matt.por...@linaro.org


Add QSPI definitions and clock configuration support.

[snip]

diff --git a/arch/arm/include/asm/arch-omap5/spl.h
b/arch/arm/include/asm/arch-omap5/spl.h index d4d353c..8905cb8
100644 --- a/arch/arm/include/asm/arch-omap5/spl.h +++
b/arch/arm/include/asm/arch-omap5/spl.h @@ -31,6 +31,7 @@
#define BOOT_DEVICE_MMC15 #define BOOT_DEVICE_MMC2
6 #define BOOT_DEVICE_MMC2_2 7 +#define BOOT_DEVICE_SPI 10

why not 8?

This is the value ROM passes when we boot here.  What I would like to
know is, is this really "SPI" or QSPI_1 or QSPI_4 ?  I suspect it's
QSPI_1.  And yes, we want to be precise here because while DRA7
doesn't have McSPI AM437x will, along with QSPI.


Yes, its QSPI1.
Will explicitl define it as QSPI91/4) in next version.
- -- 
Tom

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

iQIcBAEBAgAGBQJR3WURAAoJENk4IS6UOR1W9aQP/jEBoyQKtU7n+B6aAMY5b5U4
FF54lAfRvJZfUaRVDCLmLMF+87Obx6ctQ95SogkKbsNmc5TxbDy7dBfd7G3++5ZG
ivYQcEv9MKi/kGgJ0UZejc2J4e+QbQbymvnVqHG2mKJnMjRSdeuQG7UUGGIRQeA7
/VwR4cZuNqVrcejlglrBrwxr5PdA1f/cMCr1Dp4PhiHzxG+YYbiS4EVmnT+GNXmL
RfZuy2TzjAir7brn4Y6sQ2fcHu2qXIzO6U/a16ZawfwB8089Zj4FMvP20IugsIyU
drZhaJ3jY+leTCW1Wq5BZ1s2IJ7eaIqW4kbCSif9sPqxqM1lwJdqFJAdY8eGUWD/
c7cpJxkyLvleK0WFZDVraljIXoY7SMiTpnjYU5M+ASV43s+fFSl3f0VnZLuQtkkW
+nFQeF1FdRDUd32jFDOzCuEeJbiPpy3mJLn60ND1r56VPQweroVBE3AetavzYDA0
K40Q3o/vXBLPyl2IELLOK5hpESWVlXasgMUOsNSfqpxGblh9ea5sXZ/Nvk8hjdmm
ViVXk5lqNvmZzYzu0znRmLEg3ucuyYif0IOh/IOb97mAjR8KX0iCavw42RI5ympb
E6d4is/Ap3x67BMBiEquRVWYmXv78Mr0o6LEhgayxM9rrT38uJyaGgIXlszia0xE
QIqgV1U808hJVFMMnAK+
=EY5D
-END PGP SIGNATURE-


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

Re: [U-Boot] [PATCH V2] p1020rdb-pd: platform support

[Zhang Haijun-B42677]

Hi, scott

I had update this patch.
Did I need any other changes? 
If need let me know.

Thanks.

Regards
Haijun.


> -Original Message-
> From: Zhang Haijun-B42677
> Sent: Friday, June 28, 2013 10:47 AM
> To: Fleming Andy-AFLEMING
> Cc: u-boot@lists.denx.de; Zhang Haijun-B42677; Huang Changming-R66093;
> Wood Scott-B07421; sun york-R58495
> Subject: [PATCH V2] p1020rdb-pd: platform support
> 
> From: "Haijun.Zhang" 
> 
> Add new board p1020RDB-PD. P1020RDB-PD board was update from P1020RDB.
> DDR changed from DDR2 1G to DDR3 2G.
> NAND: 128 MiB
> Flash: 64 MiB
> 
> Also change P1020RDB to P1020RDB-PC to distinguish from P1020RDB board.
> 
> Signed-off-by: Jerry Huang 
> Signed-off-by: Haijun Zhang 
> CC: Scott Wood 
> CC: Sun Yusong-R58495 
> ---
> changes for V2:
>   - Add change log and update the config name for pc board
> 
>  board/freescale/p1_p2_rdb_pc/README |  1 +
> board/freescale/p1_p2_rdb_pc/ddr.c  |  4 +--
> board/freescale/p1_p2_rdb_pc/tlb.c  |  2 +-
>  boards.cfg  | 20 +--
>  include/configs/p1_p2_rdb_pc.h  | 50
> ++---
>  5 files changed, 63 insertions(+), 14 deletions(-)
> 
> diff --git a/board/freescale/p1_p2_rdb_pc/README
> b/board/freescale/p1_p2_rdb_pc/README
> index 4437731..f4cc43f 100644
> --- a/board/freescale/p1_p2_rdb_pc/README
> +++ b/board/freescale/p1_p2_rdb_pc/README
> @@ -3,6 +3,7 @@ Overview
>  P1_P2_RDB_PC represents a set of boards including
>  P1020MSBG-PC
>  P1020RDB-PC
> +P1020RDB-PD
>  P1020UTM-PC
>  P1021RDB-PC
>  P1024RDB
> diff --git a/board/freescale/p1_p2_rdb_pc/ddr.c
> b/board/freescale/p1_p2_rdb_pc/ddr.c
> index 9355536..c8fde72 100644
> --- a/board/freescale/p1_p2_rdb_pc/ddr.c
> +++ b/board/freescale/p1_p2_rdb_pc/ddr.c
> @@ -80,7 +80,7 @@ dimm_params_t ddr_raw_timing = {
>   .refresh_rate_ps = 780,
>   .tFAW_ps = 3,
>  };
> -#elif defined(CONFIG_P1020MBG)
> +#elif (defined(CONFIG_P1020MBG) || defined(CONFIG_P1020RDB_PD))
>  /* Micron MT41J512M8_187E */
>  dimm_params_t ddr_raw_timing = {
>   .n_ranks = 2,
> @@ -111,7 +111,7 @@ dimm_params_t ddr_raw_timing = {
>   .refresh_rate_ps = 780,
>   .tFAW_ps = 37500,
>  };
> -#elif defined(CONFIG_P1020RDB)
> +#elif defined(CONFIG_P1020RDB_PC)
>  /*
>   * Samsung K4B2G0846C-HCF8
>   * The following timing are for "downshift"
> diff --git a/board/freescale/p1_p2_rdb_pc/tlb.c
> b/board/freescale/p1_p2_rdb_pc/tlb.c
> index 3e4dffd..e19002f 100644
> --- a/board/freescale/p1_p2_rdb_pc/tlb.c
> +++ b/board/freescale/p1_p2_rdb_pc/tlb.c
> @@ -110,7 +110,7 @@ struct fsl_e_tlb_entry tlb_table[] = {
>   MAS3_SX|MAS3_SW|MAS3_SR, 0,
>   0, 8, BOOKE_PAGESZ_1G, 1),
> 
> -#ifdef CONFIG_P1020MBG
> +#if defined(CONFIG_P1020MBG) || defined(CONFIG_P1020RDB_PD)
>   /* 2G DDR on P1020MBG, map the second 1G */
>   SET_TLB_ENTRY(1, CONFIG_SYS_DDR_SDRAM_BASE + 0x4000,
>   CONFIG_SYS_DDR_SDRAM_BASE + 0x4000, diff --git
> a/boards.cfg b/boards.cfg index 35f38f3..8f50927 100644
> --- a/boards.cfg
> +++ b/boards.cfg
> @@ -758,16 +758,20 @@ P1020RDB_36BIT   powerpc mpc85xx
> p1_p2_rdb   freesca
>  P1020RDB_36BIT_SDCARDpowerpc mpc85xx p1_p2_rdb
> freescale  -   P1_P2_RDB:P1020RDB,36BIT,SDCARD
>  P1020RDB_36BIT_SPIFLASH  powerpc mpc85xx p1_p2_rdb
> freescale  -   P1_P2_RDB:P1020RDB,36BIT,SPIFLASH
>  P1020RDB_NANDpowerpc mpc85xx p1_p2_rdb
> freescale  -   P1_P2_RDB:P1020RDB,NAND
> -P1020RDB-PC  powerpc mpc85xx p1_p2_rdb_pc
> freescale  -   p1_p2_rdb_pc:P1020RDB
> -P1020RDB-PC_36BITpowerpc mpc85xx p1_p2_rdb_pc
> freescale  -   p1_p2_rdb_pc:P1020RDB,36BIT
> -P1020RDB-PC_36BIT_NAND   powerpc mpc85xx p1_p2_rdb_pc
> freescale  -   p1_p2_rdb_pc:P1020RDB,36BIT,NAND
> -P1020RDB-PC_36BIT_SDCARD powerpc mpc85xx p1_p2_rdb_pc
> freescale  -   p1_p2_rdb_pc:P1020RDB,36BIT,SDCARD
> -P1020RDB-PC_36BIT_SPIFLASH   powerpc mpc85xx p1_p2_rdb_pc
> freescale  -   p1_p2_rdb_pc:P1020RDB,36BIT,SPIFLASH
> -P1020RDB-PC_NAND powerpc mpc85xx p1_p2_rdb_pc
> freescale  -   p1_p2_rdb_pc:P1020RDB,NAND
> -P1020RDB-PC_SDCARD   powerpc mpc85xx p1_p2_rdb_pc
> freescale  -   p1_p2_rdb_pc:P1020RDB,SDCARD
> -P1020RDB-PC_SPIFLASH powerpc mpc85xx p1_p2_rdb_pc
> freescale  -   p1_p2_rdb_pc:P1020RDB,SPIFLASH
> +P1020RDB-PC  powerpc mpc85xx p1_p2_rdb_pc
> freescale  -   p1_p2_rdb_pc:P1020RDB_PC
> +P1020RDB-PC_36BITpowerpc mpc85xx p1_p2_rdb_pc
> freescale  -   p1_p2_rdb_pc:P1020RDB_PC,36BIT
> +P1020RDB-PC_36BIT_NAND   powerpc mpc85xx p1_p2_rdb_pc
> freescale  -   p1_

Re: [U-Boot] [PATCH 3/7] dra7xx_evm: add SPL API, QSPI, and serial flash support

[Sourav Poddar]

On Thursday 11 July 2013 05:28 AM, Nishanth Menon wrote:

[...]

diff --git a/board/ti/dra7xx/mux_data.h b/board/ti/dra7xx/mux_data.h
index 338a241..2441c55 100644
--- a/board/ti/dra7xx/mux_data.h
+++ b/board/ti/dra7xx/mux_data.h
@@ -53,5 +53,15 @@ const struct pad_conf_entry 
core_padconf_array_essential[] = {

  {UART1_RTSN, (IEN | PTU | PDIS | M3)},/* UART1_RTSN */
  {I2C1_SDA, (IEN | PTU | PDIS | M0)},/* I2C1_SDA */
  {I2C1_SCL, (IEN | PTU | PDIS | M0)},/* I2C1_SCL */
+{GPMC_A13, (IEN | PDIS | M1)},/* QSPI1_RTCLK */
+{GPMC_A14, (IEN | PDIS | M1)},  /* QSPI1_D[3] */
+{GPMC_A15, (IEN | PDIS | M1)},/* QSPI1_D[2] */
+{GPMC_A16, (IEN | PDIS | M1)},/* QSPI1_D[1] */
+{GPMC_A17, (IEN | PDIS | M1)},/* QSPI1_D[0] */
+{GPMC_A18, (IEN | PDIS | M1)},/* QSPI1_SCLK */
+{GPMC_A3, (IEN | PDIS | M1)},/* QSPI1_CS2 */
+{GPMC_A4, (IEN | PDIS | M1)},/* QSPI1_CS3 */
+{GPMC_CS2, (IEN | PTU | PDIS | M1)},/* QSPI1_CS0 */
+{GPMC_CS3, (IEN | PTU | PDIS | M1)},/* QSPI1_CS1*/
Just a nitpick - Could someone audit this to ensure that only 
input/full duplex pins are set to IEN(Input Enable)?
Chip select (CS), SCLK, RTCLK dont seem to be candidates for input to 
DRA.



Yes, SCLK is just an output and IEN should not be required.
RTCLK is an input to qspi to synchronise the data read, so probably I 
should keep IEN.
CS are also the outputs to slave, though I dont know why the dra data 
manual shows its type as IO.



---
Regards,
Nishanth Menon


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

Re: [U-Boot] [PATCH v2 5/5] bootm: Add the missing PREP stage to bootz and correct image handling

[Simon Glass]

Hi,
On Jul 10, 2013 11:04 PM, "Sughosh Ganu"  wrote:
>
> On Wed, Jul 10, 2013 at 3:21 PM, Sughosh Ganu wrote:
>
> > hi Tom,
> >
> > On Tue Jul 09, 2013 at 05:19:32PM -0400, Tom Rini wrote:
> >
> > 
> >
> > > > Yes, I am not really comfortable with this. I will see if I can
write
> > some
> > > > sandbox tests for the other image types today and post my results. I
> > guess
> > > > this bootm code has built up over a long time and it is hard to know
> > all
> > > > the ways it is used.
> > >
> > > Important, but I really want to see real-world booting in a case or
two.
> > > Unfortunately I don't have any ARM boards that work out of the box
with
> > > NetBSD.
> >
> > I have netbsd running on hawkboard, but i do not boot it using the
> > bootm command, but use the go command instead. I will try to build a
> > netbsd image with the u-boot header and give it a try with bootm. Need
> > a day or two to check this out though.
> >
>
> Tried to boot netbsd with u-boot head 225fd8c5d45, and the boot fails. Was
> able to boot netbsd with v2012.10 u-boot image. Btw, am i supposed to
apply
> any patch on top of the said commit.

Yes please see the four commits I sent earlier today.

Regards,
Simon

>
> hawkboard > bootm c300
> ## Booting kernel from Legacy Image at c300 ...
>Image Name:   Netbsd
>Image Type:   ARM NetBSD Kernel Image (uncompressed)
>Data Size:2329152 Bytes = 2.2 MiB
>Load Address: c020
>Entry Point:  c020
>Verifying Checksum ... OK
>Loading Kernel Image ... OK
> OK
> subcommand not supported
> hawkboard >
>
> -sughosh
>
> ___
> 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