[U-Boot] [PATCH 1/5] Licenses: introduce SPDX Unique Lincense Identifiers
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 ravic...@softwarefreedom.org | To: Wolfgang Denk w...@denx.de | 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 w...@denx.de --- 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
Re: [U-Boot] Separately compile Master boot loader
Waiting for a reply. On Tue, Jul 9, 2013 at 4:12 PM, Rajdeep Vaghasia rajdeep.vagha...@gmail.com 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
On Tue, Jul 9, 2013 at 9:59 PM, Stephen Warren swar...@wwwdotorg.orgwrote: 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 swar...@wwwdotorg.org 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
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
hi Tom, On Tue Jul 09, 2013 at 05:19:32PM -0400, Tom Rini wrote: snip 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
Hi Sughosh, On Wed, Jul 10, 2013 at 2:51 AM, Sughosh Ganu urwithsugh...@gmail.comwrote: hi Tom, On Tue Jul 09, 2013 at 05:19:32PM -0400, Tom Rini wrote: snip 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
Hi Tom,
On Tue, Jul 9, 2013 at 2:19 PM, Tom Rini tr...@ti.com 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 tr...@ti.com 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 tr...@ti.com 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 tr...@ti.com 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 s...@chromium.org
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']
I found that most of them have the same problem fixed by Andreas/Tom's
commit 2cb0e55, so I will prepare a patch for this.
Additionally, the vxworks arguments are incorrect (argc is one less than
expected). I will prepare a patch for this also.
Other than that, everything looks correct so far as I can tell, up to the
point where U-Boot actually jumps to the OS.
I will tidy up my tests and submit these also at
Re: [U-Boot] [PATCH v2 5/5] bootm: Add the missing PREP stage to bootz and correct image handling
[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
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
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
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
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
From: Matt Porter mpor...@ti.com
Add QSPI definitions and clock configuration support.
Signed-off-by: Matt Porter mpor...@ti.com
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
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, (124));
+#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
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
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 sourav.pod...@ti.com
---
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_SETUP0_NUM_D_BYTES_8_BITS
[U-Boot] [PATCH 3/7] dra7xx_evm: add SPL API, QSPI, and serial flash support
From: Matt Porter mpor...@ti.com
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 mpor...@ti.com
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
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
From: Matt Porter mpor...@ti.com
Adds a SPI master driver for the TI QSPI peripheral.
Signed-off-by: Matt Porter mpor...@ti.com
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
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 common.h
+#include asm/io.h
+#include asm/arch/omap.h
+#include malloc.h
+#include spi.h
+
+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
[U-Boot] [RFC/PATCH 4/7] drivers: mtd: spi: Modify read/write command for sfl256s flash.
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 sourav.pod...@ti.com
---
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
From: Ravikumar Kattekola r...@ti.com
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 r...@ti.com
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
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
[U-Boot] [PATCH 7/7] README: qspi usecase and testing documentation.
Contains documentation and testing details for qspi flash interface. Signed-off-by: Sourav Poddar sourav.pod...@ti.com --- 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
Hello Wolfgang,
Am 10.07.2013 13:15, schrieb Wolfgang Denk:
Dear Heiko,
In message51dd3d92.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
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 rajeshwar...@samsung.com Signed-off-by: Amar amarendra...@samsung.com --- 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
Hi Rajdeep, On Wed, 10 Jul 2013 15:04:12 +0530, Rajdeep Vaghasia rajdeep.vagha...@gmail.com 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.netwrote: Hi Rajdeep, On Tue, 9 Jul 2013 16:12:14 +0530, Rajdeep Vaghasia rajdeep.vagha...@gmail.com 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
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
Hi Sughosh, On Wed, 10 Jul 2013 15:35:10 +0530, Sughosh Ganu urwithsugh...@gmail.com 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)
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
Hello Andre, On Wed, Jul 10, 2013 at 2:54 AM, Andre Przywara andre.przyw...@linaro.orgwrote: 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 andre.przyw...@linaro.org --- 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 config.h +#include linux/linkage.h +#include asm/gic.h +#include asm/armv7.h + +.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 + mcr p15, 0, r1,
Re: [U-Boot] [PATCH v3 4/7] ARM: switch to non-secure state during bootm execution
Hello Andre,
On Wed, Jul 10, 2013 at 2:54 AM, Andre Przywara
andre.przyw...@linaro.orgwrote:
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 andre.przyw...@linaro.org
---
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 common.h
+#include asm/armv7.h
+#include asm/gic.h
+#include asm/io.h
+
+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
+}
+
+enum nonsec_virt_errors armv7_switch_nonsec(void)
+{
Re: [U-Boot] [RFC][PATCH] arm: Fix flush_dcache_range() on arm926
Hi Marek, On Wed, 10 Jul 2013 02:30:29 +0200, Marek Vasut ma...@denx.de 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, Rx, 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
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 s...@chromium.org
---
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
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 s...@chromium.org 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
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 tr...@ti.com 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
On Wed, Jul 10, 2013 at 6:25 AM, Sourav Poddar sourav.pod...@ti.com wrote:
From: Matt Porter mpor...@ti.com
Add QSPI definitions and clock configuration support.
OMAP54xx does not have QSPI. DRA7 has QSPI?
Signed-off-by: Matt Porter mpor...@ti.com
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
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, (124));
+#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
Hi Pardeep,
On 09/07/2013 23:58, Pardeep Kumar Singla wrote:
Signed-off-by: Pardeep Kumar Singla b45...@freescale.com
---
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 fsl_esdhc.h
#include miiphy.h
#include netdev.h
+#include asm/arch/crm_regs.h
+#include asm/arch/crm_regs.h
+#include ipu_pixfmt.h
+#include linux/fb.h
+#include asm/arch/mxc_hdmi.h
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
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 ma...@denx.de
Cc: Anatolij Gustschin ag...@denx.de
Cc: Fabio Estevam fabio.este...@freescale.com
Cc: Otavio Salvador ota...@ossystems.com.br
Cc: Stefano Babic sba...@denx.de
---
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 sba...@denx.de
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
From: Simon Glass s...@chromium.org
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 s...@chromium.org
[trini: Update slightly based on Simon's changes to also cover
CONFIG_TRACE/BOOTM_STATE_FAKE_OS_GO]
Signed-off-by: Tom Rini tr...@ti.com
---
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
Hi Albert, Hi Marek, On Wed, 10 Jul 2013 02:30:29 +0200, Marek Vasut ma...@denx.de 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, Rx, 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
On Wednesday 10 July 2013 04:55 PM, Sourav Poddar wrote:
From: Matt Porter mpor...@ti.com
Add QSPI definitions and clock configuration support.
Signed-off-by: Matt Porter mpor...@ti.com
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
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, (124));
+#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
-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 sourav.pod...@ti.com wrote: From: Matt Porter mpor...@ti.com 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
On Wednesday 10 July 2013 04:55 PM, Sourav Poddar wrote:
From: Matt Porter mpor...@ti.com
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 mpor...@ti.com
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
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
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
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 govindraj.r...@ti.com * 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 govindraj.r...@ti.com --- 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. snip -- -- 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
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 govindraj.r...@ti.com * 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 govindraj.r...@ti.com --- 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. snip -- -- 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
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 ji...@nvidia.com 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
On 07/10/2013 03:53 AM, Simon Glass wrote: On Tue, Jul 9, 2013 at 9:59 PM, Stephen Warren swar...@wwwdotorg.org mailto:swar...@wwwdotorg.org 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 swar...@wwwdotorg.org 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
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
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. snip 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
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
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
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 dmur...@ti.com
---
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 malloc.h
#include watchdog.h
#include linux/compiler.h
-
+#include asm/ehci-omap.h
#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
Add an interface to the palmas driver to enable the
LDO9 power supply for the USB hub IC.
Signed-off-by: Dan Murphy dmur...@ti.com
---
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
Change the board name for the sys info to
5432 uEVM
Signed-off-by: Dan Murphy dmur...@ti.com
---
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
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
Fix the linker error for missing ulpi_reset when ulpi is not defined
in the board config.
Signed-off-by: Dan Murphy dmur...@ti.com
---
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
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 dmur...@ti.com
---
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 palmas.h
#include asm/arch/sys_proto.h
#include asm/arch/mmc_host_def.h
+#include asm/gpio.h
#include mux_data.h
+#ifdef CONFIG_USB_EHCI
+#include usb.h
+#include asm/arch/ehci.h
+#include asm/ehci-omap.h
+#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
[U-Boot] [[PATCH v2 3/6] ARM: OMAP5: USB: Add OMAP5 common USB EHCI information
* Enable the OMAP5 EHCI host clocks
* Add OMAP5 EHCI register definitions
* Add OMAP5 ES2 host revision
Signed-off-by: Dan Murphy dmur...@ti.com
---
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 govindraj.r...@ti.com
+ *
+ * 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
[U-Boot] [[PATCH v3 2/2] gpio: omap5-uevm: Configure the tca6424 gpio expander
Configure the tca6424 gpio expander
This allows use of the debug and tri color LEDs.
Signed-off-by: Dan Murphy dmur...@ti.com
---
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 palmas.h
#include asm/arch/sys_proto.h
#include asm/arch/mmc_host_def.h
+#include tca642x.h
#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
Add the tca642x gpio expander driver
Datasheet:
http://www.ti.com/product/tca6424a
Signed-off-by: Dan Murphy dmur...@ti.com
---
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 dmur...@ti.com
+ *
+ * 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 common.h
+#include i2c.h
+#include tca642x.h
+
+/* 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
[U-Boot] [[PATCH v2 5/6] USB: ehci: Add a weak function for resetting devices
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 dmur...@ti.com
---
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
Hi Tom,
On Wed, Jul 10, 2013 at 6:25 AM, Tom Rini tr...@ti.com wrote:
From: Simon Glass s...@chromium.org
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 s...@chromium.org
[trini: Update slightly based on Simon's changes to also cover
CONFIG_TRACE/BOOTM_STATE_FAKE_OS_GO]
Signed-off-by: Tom Rini tr...@ti.com
---
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
Hi Minkyu,
On Wed, 10 Jul 2013 21:24:47 +0900, Minkyu Kang mk7.k...@samsung.com
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/arm/cpu/armv7/exynos}/clock_init.h
(100%)
create mode 100644
[U-Boot] pull request: u-boot-arm/master
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
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 dmur...@ti.com
---
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
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 dmur...@ti.com
---
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
From: Thierry Reding tred...@nvidia.com
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 tred...@nvidia.com
---
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
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 dmur...@ti.com
---
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 n...@ti.com
___
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
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 dmur...@ti.com
---
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 palmas.h
#include asm/arch/sys_proto.h
#include asm/arch/mmc_host_def.h
+#include tca642x.h
#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 CONSOLEDEVttyO2
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
[...]
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
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 dmur...@ti.com --- 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 govindraj.r...@ti.com + * + * 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_UHH_SYSCONFIG_NOIDLE | \ + OMAP_UHH_SYSCONFIG_NOSTDBY) + +#endif /* _EHCI_H
Re: [U-Boot] Separately compile Master boot loader
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 albert.u.b...@aribaud.netwrote: Hi Rajdeep, On Wed, 10 Jul 2013 15:04:12 +0530, Rajdeep Vaghasia rajdeep.vagha...@gmail.com 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.netwrote: Hi Rajdeep, On Tue, 9 Jul 2013 16:12:14 +0530, Rajdeep Vaghasia rajdeep.vagha...@gmail.com 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
Re: [U-Boot] twister: usb host support
Stefano, Jeroen, On Wed, 10 Jul 2013 18:04:04 +0200 Jeroen Hofstee jer...@myspectrum.nl 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
