Re: [U-Boot] [RESEND PATCH 5/6] usb: host: Add ehci-vf USB driver for ARM Vybrid SoC's

[maitysanchayan]

Hello,

On 15-04-01 21:15:21, Marek Vasut wrote:
> On Wednesday, April 01, 2015 at 11:54:22 AM, Sanchayan Maity wrote:
> 
> The commit message is missing, please fix in v2.
> 
> > Signed-off-by: Sanchayan Maity 
> 
> [...]
> 
> > +#define USB_NC_REG_OFFSET  0x0800
> > +#define USBCx_CTRL_OFFSET  0x
> > +#define USBCx_PHY_CTRL_OFFSET  0x0018
> 
> Please define the register offsets using the regular struct {} method,
> see for example struct mxs_usbphy_regs and it's usage in ehci-mxs.c .

I had a query here, just to be sure and avoid rework. The vybrid defines 
would be similar to mxs. I assume I can add them to the regs-common.h 
file along with a note that the VF610 also has the same _set, _clr, 
_tog register? Or perhaps it would be more appropriate to have the file 
have generic names which mxs, vf and imx can all leverage? Though for 
now this would require reworking all the three drivers.

The USB phy definitions part is ok, as they would go in the arch 
specific folder.

Thoughts?

> 
> > +#define USBPHY_CTRL
> > 0x0030
> > +#define USBPHY_CTRL_SET0x0034
> > +#define USBPHY_CTRL_CLR0x0038
> > +#define USBPHY_CTRL_TOG0x003c
> > +
> > +#define USBPHY_PWD 0x
> > +#define USBPHY_TX  0x0010
> > +#define USBPHY_RX  0x0020
> > +#define USBPHY_DEBUG   0x0050
> > +#define USBPHY_CTRL_SFTRST 0x8000
> > +#define USBPHY_CTRL_CLKGATE0x4000
> > +#define USBPHY_CTRL_ENUTMILEVEL3   0x8000
> > +#define USBPHY_CTRL_ENUTMILEVEL2   0x4000
> > +#define USBPHY_CTRL_OTG_ID 0x0800
> > +
> > +#define ANADIG_PLL_CTRL_BYPASS 0x0001
> > +#define ANADIG_PLL_CTRL_ENABLE 0x2000
> > +#define ANADIG_PLL_CTRL_POWER  0x1000
> > +#define ANADIG_PLL_CTRL_EN_USB_CLKS0x0040
> > +
> > +#define UCTRL_OVER_CUR_POL (1 << 8) /* OTG Polarity of Overcurrent */
> > +#define UCTRL_OVER_CUR_DIS (1 << 7) /* Disable OTG Overcurrent Detection
> > */ +
> > +/* USBCMD */
> > +#define UCMD_RUN_STOP  (1 << 0) /* controller run/stop */
> > +#define UCMD_RESET (1 << 1) /* controller reset */
> 
> This looks very much like the USB PHY used on MX28 , can you double-check this
> please ?

MX28 IP also seems similar to the Vybrid USB IP except for a few 
registers and the non core registers. Perhaps to be expected as they all 
have a common chipidea IP core, though having a different version 
thereof.

> 
> Best regards,
> Marek Vasut

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

[U-Boot] [PATCH] QE/DeepSleep: add QE deepsleep support for arm

[Zhao Qiang]

Muram will power off during deepsleep, and the microcode of qe
in muram will be lost, it should be reload when resume.

Signed-off-by: Zhao Qiang 
---
 board/freescale/common/arm_sleep.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/board/freescale/common/arm_sleep.c 
b/board/freescale/common/arm_sleep.c
index 8edf878..c06b862 100644
--- a/board/freescale/common/arm_sleep.c
+++ b/board/freescale/common/arm_sleep.c
@@ -19,6 +19,9 @@
 #endif
 
 #include "sleep.h"
+#ifdef CONFIG_U_QE
+#include "../../../drivers/qe/qe.h"
+#endif
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -72,6 +75,9 @@ static void dp_resume_prepare(void)
board_sleep_prepare();
armv7_init_nonsec();
cleanup_before_linux();
+#ifdef CONFIG_U_QE
+   u_qe_resume();
+#endif
 }
 
 int fsl_dp_resume(void)
-- 
2.1.0.27.g96db324

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

Re: [U-Boot] [PATCH v3 0/3] i2c: sunxi: Support every i2c controller on each supported platform

[Paul Kocialkowski]

Le dimanche 05 avril 2015 à 22:59 +0200, Paul Kocialkowski a écrit :
> Hi Hans,
> 
> Le dimanche 05 avril 2015 à 10:44 +0200, Hans de Goede a écrit :
> > Hi,
 
[snip]

> > Thanks for your work on this, may I request one more change ? For sunxi I 
> > would
> > like to also see a CONFIG_I2C0_ENABLE, the reason for this is that on sun6i 
> > / sun8i
> > we do not really use i2c0 as we use p2wi resp. rsb to talk to the axp pmic 
> > there.
> > 
> > This way we will not end up messing with the muxing of the PH14/15 (sun6i) 
> > resp.
> > PH2/3 (sun8i) which may be used in some other fashion.
> > 
> > This also means making a small change to the first patch to also make 
> > registering
> > of twsi0 #ifdef CONFIG_I2C_MVTWSI_BASE0 .
> > 
> > Can you please make the default for CONFIG_I2C0_ENABLE y on sun4i / sun5i / 
> > sun7i and n
> > on others?
> 
> Ack that, it makes sense to me.

Implementing this leads to build errors:
drivers/i2c/mvtwsi.c:319:13: attention : ‘twsi_i2c_init’ defined but not
used [-Wunused-function]
drivers/i2c/mvtwsi.c:362:12: attention : ‘twsi_i2c_probe’ defined but
not used [-Wunused-function]
drivers/i2c/mvtwsi.c:388:12: attention : ‘twsi_i2c_read’ defined but not
used [-Wunused-function]
drivers/i2c/mvtwsi.c:424:12: attention : ‘twsi_i2c_write’ defined but
not used [-Wunused-function]

Ways to get rid of those include:
* not building the driver at all when no controller 0 base is defined,
which involves moving moving SYS_I2C_MVTWSI to Kconfig and selecting it
when at least one i2c controller is selected in the sunxi Kconfig
* having twsi0 enabled on all sunxi devices, as it was before

What do you prefer?

> > Also I'm not entirely convinced that patch 3/3 is a good idea, on the 
> > olimex boards
> > which have a i2c eeprom enabling the attached i2c controller makes sense, 
> > but on the
> > other boards the i2c pins are really just gpio pins, any daughter board can 
> > be connected
> > including one which uses them differently. I believe that in the defconfig 
> > the i2c
> > controllers should thus be left off. It is after all a default config, 
> > users with
> > a daughter board which they want to use in u-boot can easily change the 
> > config after
> > running make foo_defconfig.
> 
> I think the right bargain here would be to enable i2c lines that already
> have something useful for U-Boot attached (e.g. not an accelerometer
> sensor). I concur to your point otherwise.


signature.asc
Description: This is a digitally signed message part
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] u-boot summit / miniconf this year?

[Hans de Goede]

Hi,

I'm thinking about going to ELCE, assuming I will not have some schedule 
conflict,
one of the reasons is that I would like to attend the u-boot summit / miniconf
again this year. Which raises the question will it be held at ELCE again ?

Regards,

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

Re: [U-Boot] printf("%d") breaks u-boot 2015.01+

[Pavel Machek]

On Mon 2015-04-06 23:02:48, Marek Vasut wrote:
> On Monday, April 06, 2015 at 09:23:23 PM, Pavel Machek wrote:
> > On Mon 2015-04-06 20:48:45, Marek Vasut wrote:
> > > On Monday, April 06, 2015 at 08:14:44 PM, Pavel Machek wrote:
> > > > On Mon 2015-04-06 16:59:55, Marek Vasut wrote:
> > > > > On Monday, April 06, 2015 at 04:40:09 PM, Pavel Machek wrote:
> > > > > > Hi!
> > > > > > 
> > > > > > In u-boot 2015.04-rc, as soon as execution hits printf("%d"), it
> > > > > > hangs. (Usually, that's after "DRAM: " message).
> > > > > 
> > > > > printf("%d") expects an argument, so could it be that it touches
> > > > > random piece of memory and thus hangs?
> > > > 
> > > > It had an argument, sorry for confusion. I was actually doing this:
> > > > the test with %s works, the one with %d kills it.
> > > > 
> > > > I suspect too small stack...?
> > > 
> > > Does this happen in the SPL ? You can check the stack placement and
> > > utilization with BDI to verigy your hypothesis.
> > 
> > No, this is u-boot proper, and I'm chainloading it (see first mail) --
> > so unsupported configuration.
> > 
> > I'm preparing to flash the u-boot into the NOR, that should tell us if
> > it is chainloading problem or not.
> 
> OK, since this email was in-reply-to SPL patch series, I got confused.
> Is it in any way related to this patchset then or not ?

No, it is not related to SPL series. Sorry for confusion.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] printf("%d") breaks u-boot 2015.01+

[Pavel Machek]

Hi!

> >In u-boot 2015.04-rc, as soon as execution hits printf("%d"), it
> >hangs. (Usually, that's after "DRAM: " message).
> >
> >Now, I have to admit I'm chainloading u-boot from
> >
> >U-Boot 2013.01.01 (Mar 25 2015 - 15:57:21)
> >
> >tftp 0x0140 .../u-boot.bin
> >Waiting for PHY auto negotiation to complete.. done
> >ENET Speed is 100 Mbps - FULL duplex connection
> >Using mii0 device
> >TFTP from server 10.0.0.6; our IP address is 10.0.0.99
> >...
> >  Bytes transferred = 325004 (4f58c hex)
> ># go 0x0140
> >
> >...but that worked well for 2014.10, (and is nearly mandatory in my
> >config).
> >
> >I'm using cross-compiler from eldk-5.6, but eldk-5.4 crosscompiler
> >produces same behaviour, and both seem to work for 2014.10.
> >
> >Any ideas?
> 
> Do you have caches on?
> Try to disable "dcache off" before "go ..." ...

I tried, and did not get any change. I also tried to flash 2015.04-rc4
directly into NOR to be loaded from SPL (not chainloaded), and it
fails the same way.

> maybe this helps? I just stepped into same problem on an am335x,
> but had not yet time to look deeper in it ...

I did not try the cleanup_before_linux(), but "dcache off" should have
same effect, right?

Thanks and best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 3/8] sandbox: Add support for bootz

[Sjoerd Simons]

On Mon, 2015-04-06 at 15:40 -0600, Stephen Warren wrote:
> On 04/06/2015 03:02 PM, Sjoerd Simons wrote:
> > Add dummy bootz_setup implementation allowing the u-boot sandbox to
> > run bootz. This recognizes both ARM and x86 zImages to validate a
> > valid zImage was loaded.
> 
> > diff --git a/arch/sandbox/lib/bootm.c b/arch/sandbox/lib/bootm.c
> 
> > +int bootz_setup(ulong image, ulong *start, ulong *end)
> 
> > +   *start = 0xdead;
> > +   *end = 0xbeef;
> > +   return 0;
> 
> Isn't that going to cause the rest of bootz to access or jump to some 
> bogus address and crash?

A very good question. I hadn't actually double-checked what these values
are used for as things just worked and i got distracted by fixing other
bits & pieces. 

Looking through the code, these values are only used to add an LMB
region directly after the kernel entry load address. As the sandbox
architecture doesn't define either arch_lmb_reserve nor
board_lmb_reserve these bogus values don't cause any issues (as they
don't seem to make the generic lmb code blow-up thatis), but it's
definitely not pretty.

I'll fix up that patch a bit to make those values more meaningful later
this.

> Aside from that, this series looks plausible, so,
> Acked-by: Stephen Warren 
> 
> (I read through patch 6 most thoroughly, briefly skimmed patch 7, and 
> read the others fairly quickly, so take that as an ack primarily on 
> patch 6 although I didn't see anything obviously wrong elsewhere).

Thanks for the review!

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

Re: [U-Boot] printf("%d") breaks u-boot 2015.01+

[Heiko Schocher]

Hello Pavel,

Am 07.04.2015 09:56, schrieb Pavel Machek:

Hi!


In u-boot 2015.04-rc, as soon as execution hits printf("%d"), it
hangs. (Usually, that's after "DRAM: " message).

Now, I have to admit I'm chainloading u-boot from

U-Boot 2013.01.01 (Mar 25 2015 - 15:57:21)

tftp 0x0140 .../u-boot.bin
Waiting for PHY auto negotiation to complete.. done
ENET Speed is 100 Mbps - FULL duplex connection
Using mii0 device
TFTP from server 10.0.0.6; our IP address is 10.0.0.99
...
  Bytes transferred = 325004 (4f58c hex)
# go 0x0140

...but that worked well for 2014.10, (and is nearly mandatory in my
config).

I'm using cross-compiler from eldk-5.6, but eldk-5.4 crosscompiler
produces same behaviour, and both seem to work for 2014.10.

Any ideas?


Do you have caches on?
Try to disable "dcache off" before "go ..." ...


I tried, and did not get any change. I also tried to flash 2015.04-rc4
directly into NOR to be loaded from SPL (not chainloaded), and it
fails the same way.


Ok.


maybe this helps? I just stepped into same problem on an am335x,
but had not yet time to look deeper in it ...


I did not try the cleanup_before_linux(), but "dcache off" should have
same effect, right?


Hmm.. not exactly... cleanup_before_linux() does also disable the mmu.

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
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 v3 0/3] i2c: sunxi: Support every i2c controller on each supported platform

[Hans de Goede]

Hi,

On 07-04-15 09:51, Paul Kocialkowski wrote:

Le dimanche 05 avril 2015 à 22:59 +0200, Paul Kocialkowski a écrit :

Hi Hans,

Le dimanche 05 avril 2015 à 10:44 +0200, Hans de Goede a écrit :

Hi,


[snip]


Thanks for your work on this, may I request one more change ? For sunxi I would
like to also see a CONFIG_I2C0_ENABLE, the reason for this is that on sun6i / 
sun8i
we do not really use i2c0 as we use p2wi resp. rsb to talk to the axp pmic 
there.

This way we will not end up messing with the muxing of the PH14/15 (sun6i) resp.
PH2/3 (sun8i) which may be used in some other fashion.

This also means making a small change to the first patch to also make 
registering
of twsi0 #ifdef CONFIG_I2C_MVTWSI_BASE0 .

Can you please make the default for CONFIG_I2C0_ENABLE y on sun4i / sun5i / 
sun7i and n
on others?


Ack that, it makes sense to me.


Implementing this leads to build errors:
drivers/i2c/mvtwsi.c:319:13: attention : ‘twsi_i2c_init’ defined but not
used [-Wunused-function]
drivers/i2c/mvtwsi.c:362:12: attention : ‘twsi_i2c_probe’ defined but
not used [-Wunused-function]
drivers/i2c/mvtwsi.c:388:12: attention : ‘twsi_i2c_read’ defined but not
used [-Wunused-function]
drivers/i2c/mvtwsi.c:424:12: attention : ‘twsi_i2c_write’ defined but
not used [-Wunused-function]

Ways to get rid of those include:
* not building the driver at all when no controller 0 base is defined,
which involves moving moving SYS_I2C_MVTWSI to Kconfig and selecting it
when at least one i2c controller is selected in the sunxi Kconfig
* having twsi0 enabled on all sunxi devices, as it was before

What do you prefer?


I would prefer for the driver to not be build at all then, thank you for
working on this.

Regards,

Hans





Also I'm not entirely convinced that patch 3/3 is a good idea, on the olimex 
boards
which have a i2c eeprom enabling the attached i2c controller makes sense, but 
on the
other boards the i2c pins are really just gpio pins, any daughter board can be 
connected
including one which uses them differently. I believe that in the defconfig the 
i2c
controllers should thus be left off. It is after all a default config, users 
with
a daughter board which they want to use in u-boot can easily change the config 
after
running make foo_defconfig.


I think the right bargain here would be to enable i2c lines that already
have something useful for U-Boot attached (e.g. not an accelerometer
sensor). I concur to your point otherwise.

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

Re: [U-Boot] u-boot summit / miniconf this year?

[Stefano Babic]

Hi Hans,

On 07/04/2015 09:50, Hans de Goede wrote:
> Hi,
> 
> I'm thinking about going to ELCE, assuming I will not have some schedule
> conflict,
> one of the reasons is that I would like to attend the u-boot summit /
> miniconf
> again this year. Which raises the question will it be held at ELCE again ?

We at DENX are strongly convinced to go on with the U-Boot (mini)
summit. However, we are aware that U-Boot cannot be considered a
european project, and a lot of developers / maintainers are located
outside Europe.

We are thinking in these days if the next U-Boot summit should be held
at ELC in US, or better one year at ELCE and the following year at ELC.

ELC 2016 should be at the end of March (anybody knows location and date
for ELC 2016 ?). We plan to start next week an online survey on the ML
asking for the best location between ELCE in Dublin or, dropping the
event for 2015, at the beginning of next year at ELC. Your question is
just in time !

Best regards,
Stefano

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
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] net/phy: fixup for get_phy_id

[Shengzhou Liu]

commit 3c6928fd7b0f84 "net: phy: fix warnings with W=1" caused
some PHYs(e.g. CS4315/CS4340) not working. This patch fixes the
warning and make those special PHYs working as well.

Signed-off-by: Shengzhou Liu 
---
 drivers/net/phy/phy.c | 2 +-
 include/phy.h | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index df7e945..dd665ba 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -581,7 +581,7 @@ static struct phy_device *phy_device_create(struct mii_dev 
*bus, int addr,
  * Description: Reads the ID registers of the PHY at @addr on the
  *   @bus, stores it in @phy_id and returns zero on success.
  */
-static int get_phy_id(struct mii_dev *bus, int addr, int devad, u32 *phy_id)
+int __weak get_phy_id(struct mii_dev *bus, int addr, int devad, u32 *phy_id)
 {
int phy_reg;
 
diff --git a/include/phy.h b/include/phy.h
index d117fc1..2adfb44 100644
--- a/include/phy.h
+++ b/include/phy.h
@@ -241,6 +241,7 @@ int phy_teranetics_init(void);
 int phy_vitesse_init(void);
 
 int board_phy_config(struct phy_device *phydev);
+int get_phy_id(struct mii_dev *bus, int addr, int devad, u32 *phy_id);
 
 /* PHY UIDs for various PHYs that are referenced in external code */
 #define PHY_UID_CS4340  0x13e51002
-- 
2.1.0.27.g96db324

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

[U-Boot] Zynq board is boken

[Masahiro Yamada]

Hi Michal,
(cc Simon)

Bad new.


My Zedboard would not boot from MMC card with the U-Boot mainline.

U-Boot hangs after printing "reading system.dtb".
I think, other zynq board types, too.

I did git-bisect and the first bad commit is:

commit 326a682358c16afcf2c7a9617e9811e72a1f0929
Author: Masahiro Yamada 
Date:   Thu Mar 19 19:42:55 2015 +0900

malloc_f: enable SYS_MALLOC_F by default if DM is on



Uh, sorry. My commit.


The commit 36a6823 enables
CONFIG_SYS_MALLOC_F=y
CONFIG_SYS_MALLOC_F_LEN=0x400
to the .config file.

I suspect it changed how Zynq initializes malloc area in SPL.
I have not figured out how to fix it.

Any hint is appreciated.



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

[U-Boot] Question about license information

[Viitanen, Ingrid (Nokia - FI/Espoo)]

Hi,

Uboot contains several header files which specify copyright information, but no 
license information. For example:

2:  * U-Boot additions to enable a generic Exynos GPIO driver
3:  *
4:  * Copyright (c) 2014 Google, Inc

Could you confirm which license applies to these files? Can it be assumed that 
GPL v.2+ applies?
Files that seem to be missing license information include:

arch/arm/dts/exynos4210-pinctrl-uboot.dtsi
arch/arm/dts/exynos4x12-pinctrl-uboot.dtsi
arch/arm/dts/exynos5250-pinctrl-uboot.dtsi
arch/arm/dts/exynos54xx-pinctrl-uboot.dtsi
arch/arm/dts/s5pc100-pinctrl.dtsi
arch/arm/dts/s5pc110-pinctrl.dtsi
arch/arm/include/asm/arch-pxa/bitfield.h
arch/arm/include/asm/arch-s3c24x0/memory.h
arch/arm/include/asm/arch-sa1100/bitfield.h
arch/arm/include/asm/bitops.h
arch/arm/include/asm/ti-common/davinci_nand.h
arch/microblaze/include/asm/bitops.h
arch/mips/cpu/mips32/au1x00/au1x00_usb_ohci.h
arch/mips/include/asm/isadep.h
arch/nds32/include/asm/bitops.h
arch/nds32/include/asm/byteorder.h
arch/powerpc/cpu/mpc5xxx/firmware_sc_task_bestcomm.impl.S
arch/powerpc/cpu/mpc5xxx/loadtask.c
arch/powerpc/cpu/mpc5xxx/usb_ohci.h
arch/powerpc/cpu/mpc8260/commproc.c
arch/powerpc/cpu/mpc85xx/commproc.c
arch/powerpc/include/asm/e300.h
arch/powerpc/include/asm/immap_8260.h

[U-Boot] Copy to Flash... 9Flash not Erased

[Rudolf J Streif]

I am getting the "Flash not Erased" error when writing to NOR flash with cp.b. 
I checked all of the obvious such as file exceeding the erased area etc.

Below is the log including environment settings etc. You can see that about 
14k of data is written and then the error occurs for a reason unbeknownst to 
me. Any suggestions are appreciated.

Now, you may want to say "try a newer version of u-boot". However, that is not 
feasible due to other requirements. However, if there has been a known issue 
that has been fixed later, please let me know, what it is so that I can 
eventually backport it. I could not find it while searching the web and the 
mailing list posts.

Thank you,
Rudi


U-Boot 2011.121.4.4 (Apr 01 2015 - 13:30:37)

CPU0:  8572E, Version: 2.1, (0x80e80021)
Core:  E500, Version: 3.0, (0x80210030)
Clock Configuration:
   CPU0:1250 MHz, CPU1:1250 MHz, 
   CCB:500  MHz,
   DDR:333.330 MHz (666.660 MT/s data rate) (Asynchronous), LBC:62.500 MHz
L1:D-cache 32 kB enabled
   I-cache 32 kB enabled
Board: MyBoard
I2C:   ready
DRAM:  Detected UDIMM CT51264AC667.M16FC
Detected UDIMM CT51264AC667.M16FC
6 GiB left unmapped
8 GiB (DDR2, 64-bit, CL=5, ECC off)
Flash: 128 MiB
L2:1024 KB enabled
PORDEVSR[IO_SEL_SRDS] = e
NAND:  1536 MiB
PCIe1: disabled, devdisr: 0x36000108, sdc: 0
PCIe2: disabled, devdisr: 0x36000108, sdc: 0
PCIe3: disabled, devdisr: 0x36000108, sdc: 0
In:serial
Out:   serial
Err:   serial
Net:   eTSEC1, eTSEC2, eTSEC3, eTSEC4
Hit any key to stop autoboot:  0 
=> 


=> printenv
baudrate=115200
bootcmd=setenv bootargs root=/dev/mtdblock5 rw rootfstype=jffs2 
console=$consoledev,$baudrate $othbootargs; bootm $kernel_fladdr - $fdt_fladdr
bootdelay=5
bootfile=/export/boot/uImage
burnfdt=protect off $fdt_fladdr +$filesize; erase $fdt_fladdr +$filesize; cp.b 
$fdtaddr $fdt_fladdr $filesize; protect on $fdt_fladdr +$filesize
burnkernel=protect off $kernel_fladdr +$filesize; erase $kernel_fladdr 
+$filesize; 
cp.b $kernel_addr $kernel_fladdr $filesize; protect on $kernel_fladdr +$filesize
burnrootfs=nand device 0; nand erase.chip clean; nand write $rootfs_addr 0x0 
$filesize
consoledev=ttyS0
eth1addr=00:09:9C:03:80:45
eth2addr=00:09:9C:03:80:46
eth3addr=00:09:9C:03:80:47
ethact=eTSEC1
ethaddr=00:09:9C:03:80:44
fdt_addr=c0
fdt_fladdr=0xeff0
fdtaddr=c0
fdtfile=uImage-myboard_36b.dtb
gatewayip=10.0.0.1
getfdt=tftp $fdtaddr $user/$fdtfile
getkernel=tftp $kernel_addr $user/$kernelfile
getrootfs=tftp $rootfs_addr $user/$rootfsfile
hostname=myboard
hwconfig=fsl_ddr:ecc=off
ipaddr=192.168.100.50
kernel_addr=0x100
kernel_fladdr=0xef80
kernelfile=uImage-myboard.bin
loadall=run loadkernel ; run loadfdt ; run loadrootfs
loadfdt=run getfdt ; run burnfdt
loadkernel=run getkernel ; run burnkernel
loadrootfs=run getrootfs ; run burnrootfs
loads_echo=1
mtdids=nand0=config-flash-0
netdev=eth0
netmask=255.255.255.0
oldkernelfile=uImage-git-r1318-myboard-20130531192736.bin
oldrootfsfile=cssp-bams-myboard2-20140127153741.rootfs.jffs2
othbootargs=rio-scan.scan=1 riohdid=0 enforcing=0 selinux=0 loglevel=8
rootfs_addr=200
rootfsfile=core-image-selinux-myboard.jffs2
rootpath=/export/rootfs
serverip=192.168.100.196
stderr=serial
stdin=serial
stdout=serial
uboot=/export/u-boot/u-boot.bin
uboot_fladdr=0xeff8
user=streif-selinux

Environment size: 1856/8188 bytes

=> run getkernel
Speed: 1000, full duplex
Using eTSEC1 device
TFTP from server 192.168.100.196; our IP address is 192.168.100.50
Filename 'streif-selinux/uImage-myboard.bin'.
Load address: 0x100
Loading: #
 #
 #
 #
 #
done
Bytes transferred = 3821142 (3a4e56 hex)

=> protect off 0xef80 +0x3a4e56
Un-Protected 30 sectors

=> erase 0xef80 +0x3a4e56

.. done
Erased 30 sectors


=> flinfo
Bank # 1: CFI conformant flash (16 x 16)  Size: 128 MB in 1024 Sectors
  AMD Standard command set, Manufacturer ID: 0x89, Device ID: 0x227E2801
  Erase timeout: 4096 ms, write timeout: 2 ms
  Buffer write timeout: 5 ms, buffer size: 1024 bytes

  Sector Start Addresses:
  E800 E  E802 E  E804 E  E806 E  E808 E
  E80A E  E80C E  E80E E  E810 E  E812 E

  EF80 E  EF82 E  EF84 E  EF86 E  EF88 E
  EF8A E  EF8C E  EF8E E  EF90 E  EF92 E
  EF94 E  EF96 E  EF98 E  EF9A E  EF9C E
  EF9E E  EFA0 E  EFA2 E  EFA4 E  EFA6 E
  EFA8 E  EFAA E  EFAC E  EFAE E  EFB0 E
  EFB2 E  EFB4 E  EFB6 E  EFB8 E  EFBA E
  EFBC0

[U-Boot] u-boot 2015.04 on socfpga was Re: printf("%d") breaks u-boot 2015.01+

[Pavel Machek]

Hi!

> > In u-boot 2015.04-rc, as soon as execution hits printf("%d"), it
> > hangs. (Usually, that's after "DRAM: " message).

I tried on different board, and same hang. Does u-boot 2015.01+ work
for you on socfpga? Do I need some kind of special configuration?

Thanks, Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] u-boot summit / miniconf this year?

[Thomas Petazzoni]

Hello,

On Tue, 07 Apr 2015 12:45:23 +0200, Stefano Babic wrote:

> ELC 2016 should be at the end of March (anybody knows location and date
> for ELC 2016 ?). We plan to start next week an online survey on the ML

Location: San Diego.

Dates: around early April 2016. The exact dates were announced during
the final speech of Tim Bird at ELC 2015, but I don't remember the exact
dates.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] mtd: vf610_nfc: remove caching of page in buffer

[Stefan Agner]

On 2015-04-02 22:30, Bill Pringlemeir wrote:
> On  2 Apr 2015, ste...@agner.ch wrote:
> 
>> To improve performance we remember the current page in the buffer
>> and avoid reading it twice. This implicit page cache increases
>> complexity while does not increase performance in real world cases.
>> This patch removes that feature.
>> ---
>> As discussed in the other patchset...
>> http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/215802
> 
>> ...I did some performance measurements:
> 
>> Time to "Starting kernel ..."
>> - without bad block scan & with UBIFS fastmap: 2.02s
>> - with bad block scan & with UBIFS fastmap: 3.99s
>> - without bad block scan & without UBIFS fastmap: 4.42s
>> - with bad block scan & without UBIFS fastmap: 6.38s
> 
>> Without page cache (with this patch applied):
>> Time to "Starting kernel ..."
>> - without bad block scan & with UBIFS fastmap: 2.02s
>> - with bad block scan & with UBIFS fastmap: 4.01s
>> - without bad block scan & without UBIFS fastmap: 4.41s
>> - with bad block scan & without UBIFS fastmap: 6.39s
> 
> [snip]
> 
> I also measured 'write performance' with the mtd_speedtest (performing
> similar patch to the Linux driver) and I see no difference.  I think a
> write benchmark is more appropriate to test this functionality?  While
> at least it seems that neither read nor write is affected by the
> simplification.

On U-Boot, I just benchmarked the overall boot time since this is most
important for us. I plan to (re-)integrate the changes into the Linux
driver and check the performance again later this week.

Thanks for for the write test. So I can take this as a Ack?

I will send all the NFC changes in one patchset as v2 probably later
today.

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

Re: [U-Boot] Copy to Flash... 9Flash not Erased

[Dirk Eibach]

Hi Rudi,

this sounds oddly familiar. Which gcc version are you using? 4.8? gcc
4.8 is broken for powerpc u-boot.
For more background search for the "Relocation issue - need help!"
started by Wolfgang Denk on the mailing list.

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

Re: [U-Boot] Regarding patch: http://patchwork.ozlabs.org/patch/373593/

[Marek Vasut]

On Tuesday, April 07, 2015 at 08:18:03 AM, Ramneek Mehresh wrote:

[...]

> > Hi,
> > 
> > Is this similar hardware bug to the one which MX6 PCIe is suffering ? On
> > MX6, the bug is that you cannot reset the PCIe and PCIe PHY from
> > software, which means that if you start PCIe in U-Boot, you cannot
> > reliably use it in Linux. Furthermore, if you reset the MX6 via WDT, you
> > cannot start PCIe reliably in Linux even if PCIe is not used in U-Boot
> > at all.
> > 
> > Is this the same type of hardware screwup where the design team didn't
> > think reset was necessary?
> 
> I have raised request for this feature in up-coming socs, and they have
> agreed to provide phy shut-down in future revs. However, this support is
> not available in current revs for which the code is sent. What do you
> suggest we should do for current socs?

Hi,

I don't know, but doesn't leaving the USB running cause trouble to Linux?
I think you should at least document the reasoning why the USB stop is not
implemented for this broken hardware.

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 0/80] dm: Add USB support

[Marek Vasut]

On Tuesday, April 07, 2015 at 12:38:58 AM, Simon Glass wrote:
> Hi Marek,

Hi Simon,

> On 6 April 2015 at 07:13, Marek Vasut  wrote:
> > On Monday, April 06, 2015 at 01:38:13 AM, Simon Glass wrote:
> >> Hi Marek,
> > 
> > Hi Simon,
> > 
> >> On 26 March 2015 at 13:40, Marek Vasut  wrote:
> >> > On Wednesday, March 25, 2015 at 07:21:48 PM, Simon Glass wrote:
> >> >> This series adds driver model support to USB. The intent is to permit
> >> >> the various subsystems (OHCI, EHCI, XHCI) to co-exist and allow any
> >> >> number of USB ports of different types.
> >> >> 
> >> >> With the RFC series, only USB controllers had a real driver model
> >> >> device. USB devices (including the hub in the controller) were not
> >> >> modelled as driver model devices.
> >> >> 
> >> >> While this was expedient, and produced much fewer patches, it is not
> >> >> a long-term solution. Also, since then, driver model Ethernet
> >> >> support (which USB can use) has been merged to u-boot-dm/next. It
> >> >> seems better to bite the bullet and do a full conversion.
> >> > 
> >> > Whew.
> >> > 
> >> > Reviewed-by: Marek Vasut 
> >> 
> >> Thanks very much for working through these!
> >> 
> >> Unless there are other comments I plan to apply this to u-boot-dm/next
> >> in the next few days. I expect it will need some tweaking as boards
> >> are moved over too.
> > 
> > Please apply, I'm really looking forward to this.
> > 
> > Thank you very much for putting all the effort into this !
> 
> OK, I'll apply to u-boot-dm/next, do a bit more testing, and apply. It
> will be great to get this moved over.

Thank you!

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 4/4] mtd: vf610_nfc: support subpage write

[Bill Pringlemeir]

On  3 Apr 2015, ste...@agner.ch wrote:

> I will remove the page read on NAND_CMD_SEQIN, since we memcpy the
> full page anyway. I also just realized that the page read actually
> happens always and hence slows down even full page writes...

Yes, I remove this in Linux (4.0) and it corrupted things when writing.
I think your previous conclusion about we never use 'write caching' was
wrong.

This one is for writes,

case NAND_CMD_SEQIN: /* Pre-read for partial writes. */

This one is for reads,

case NAND_CMD_READ0:

The interface between 'nand_base' and the MTD driver is hard to
decipher.  Does Scott (or anyone) know if there is any documentation on
this?

Stefan is completely correct that if a full page is being written, then
the 'SEQIN' should not read a page.  However, I only see 'column' being
passed.  How is 'SEQIN' and 'PAGEPROG' to detect if a full page is being
written or not?

The other way to handle things would to be to investigate the
NFC_CFG[PAGE_CNT] and NFC_SECSZ to have the virtual pages support
sub-pages.  I think the OOB mapping would be non-standard in such cases.
The buffer management in the driver is most simple in it's current form.
The other versions that I found seemed to be buggy to me.  However, the
current driver doesn't use all of the NFC SRAM buffer space.

Btw, the READ_OOB is very nice for Linux as well.  It is a much faster
mount of UBI/UbiFs as well.

Fwiw,
Bill Pringlemeir.


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

Re: [U-Boot] [PATCH 1/2] mtd: vf610_nfc: mark page as dirty on block erase

[Bill Pringlemeir]

On  3 Apr 2015, scottw...@freescale.com wrote:

> On Fri, 2015-04-03 at 22:28 +0200, Stefan Agner wrote:

>> Why not? IMHO, there are valid reason to do it, since we save coping
>> data over the bus (we save copying page size - write len of bytes)...

> According to http://www.linux-mtd.infradead.org/doc/ubi.html#L_subpage
> the motivation for subpages is saving space, not time, and it's only
> used for headers (specifically because using subpages may be slower).
> So it may not make a huge performance difference either way, even if
> subpages are less efficient on this controller -- though it does have
> a complexity cost that is higher than with most controllers.  It looks
> like the space savings is around one page per block.

I think that Artem wrote this.  I don't believe the document is
completely correct; I think he meant that sub-pages is not architected
as a speed improvement.  For instance, UBI will read both a VID (volume
ID) and EB (erase block).  As the are combined into one, then if a
driver needs to read a full page (like it is the only thing it supports)
then it is simple to read a full page with a VID/EB sub-pages.
Certainly for mounts with out 'fastmap', this will result in much faster
scans and initial UBI/UbiFS mounts?

It also saves one page overhead per erase block.  So in all cases,
sub-pages will optimize flash usage.  Probably performance depends on
the MTD driver and CPU.

> It'd be good to benchmark up front to be sure you're happy with the
> speed/space/complexity tradeoff, though, since enabling/disabling
> subpage writes breaks UBI compatibility.

I think that if you format the UbiFs without sub-pages and then update
code to handle sub-pages, you are fine.  If you have flash/UBI formatted
with sub-pages and then you disable it in the code, the disk is no
longer mountable.

In any case the document has,

  If the NAND flash supports sub-pages, then what can be done is ECC
  codes can be calculated on per-sub-page basis, instead of per-NAND
  page basis. In this case it becomes possible to read and write
  sub-pages independently.

Probably if we want sub-pages with this controller and hw-ecc, we need
to use the virtual buffer features of the chip.  The controller needs an
entire current buffer in the SRAM to calculate the hw-ecc to write.  So
even if it writes less than a full page, the entire page must be read to
calculate the hw-ecc to be written.  I am pretty sure that all
controllers that support hw-ecc will need to do this.

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

Re: [U-Boot] Regarding patch: http://patchwork.ozlabs.org/patch/373593/

[Marek Vasut]

On Tuesday, April 07, 2015 at 04:05:31 PM, Ramneek Mehresh wrote:
> > -Original Message-
> > From: Marek Vasut [mailto:ma...@denx.de]
> > Sent: Tuesday, April 07, 2015 7:22 PM
> > To: Mehresh Ramneek-B31383
> > Cc: u-boot; s...@denx.de
> > Subject: Re: Regarding patch: http://patchwork.ozlabs.org/patch/373593/
> > 
> > On Tuesday, April 07, 2015 at 08:18:03 AM, Ramneek Mehresh wrote:
> > 
> > [...]
> > 
> > > > Hi,
> > > > 
> > > > Is this similar hardware bug to the one which MX6 PCIe is suffering
> > > > ? On MX6, the bug is that you cannot reset the PCIe and PCIe PHY
> > > > from software, which means that if you start PCIe in U-Boot, you
> > > > cannot reliably use it in Linux. Furthermore, if you reset the MX6
> > > > via WDT, you cannot start PCIe reliably in Linux even if PCIe is not
> > > > used in U-Boot at all.
> > > > 
> > > > Is this the same type of hardware screwup where the design team
> > > > didn't think reset was necessary?
> > > 
> > > I have raised request for this feature in up-coming socs, and they
> > > have agreed to provide phy shut-down in future revs. However, this
> > > support is not available in current revs for which the code is sent.
> > > What do you suggest we should do for current socs?
> > 
> > Hi,
> > 
> > I don't know, but doesn't leaving the USB running cause trouble to Linux?
> > I think you should at least document the reasoning why the USB stop is
> > not implemented for this broken hardware.
> 
> Hi Marek, it's not USB controller stop, it's Phy stop which is not
> supported. Controller stopping is supported.

OK, does it pose a problem for Linux ? If not, then please just document
it and let's stick with what there now.

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

Re: [U-Boot] Regarding patch: http://patchwork.ozlabs.org/patch/373593/

[Ramneek Mehresh]

> -Original Message-
> From: Marek Vasut [mailto:ma...@denx.de]
> Sent: Tuesday, April 07, 2015 7:22 PM
> To: Mehresh Ramneek-B31383
> Cc: u-boot; s...@denx.de
> Subject: Re: Regarding patch: http://patchwork.ozlabs.org/patch/373593/
> 
> On Tuesday, April 07, 2015 at 08:18:03 AM, Ramneek Mehresh wrote:
> 
> [...]
> 
> > > Hi,
> > >
> > > Is this similar hardware bug to the one which MX6 PCIe is suffering
> > > ? On MX6, the bug is that you cannot reset the PCIe and PCIe PHY
> > > from software, which means that if you start PCIe in U-Boot, you
> > > cannot reliably use it in Linux. Furthermore, if you reset the MX6
> > > via WDT, you cannot start PCIe reliably in Linux even if PCIe is not
> > > used in U-Boot at all.
> > >
> > > Is this the same type of hardware screwup where the design team
> > > didn't think reset was necessary?
> >
> > I have raised request for this feature in up-coming socs, and they
> > have agreed to provide phy shut-down in future revs. However, this
> > support is not available in current revs for which the code is sent.
> > What do you suggest we should do for current socs?
> 
> Hi,
> 
> I don't know, but doesn't leaving the USB running cause trouble to Linux?
> I think you should at least document the reasoning why the USB stop is not
> implemented for this broken hardware.
> 
Hi Marek, it's not USB controller stop, it's Phy stop which is not supported.
Controller stopping is supported. 

> 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/2] mtd: vf610_nfc: remove caching of page in buffer

[Bill Pringlemeir]

On  7 Apr 2015, ste...@agner.ch wrote:
> On 2015-04-02 22:30, Bill Pringlemeir wrote:
>> On  2 Apr 2015, ste...@agner.ch wrote:

>> [snip]

>> I also measured 'write performance' with the mtd_speedtest
>> (performing similar patch to the Linux driver) and I see no
>> difference.  I think a write benchmark is more appropriate to test
>> this functionality?  While at least it seems that neither read nor
>> write is affected by the simplification.

> On U-Boot, I just benchmarked the overall boot time since this is most
> important for us. I plan to (re-)integrate the changes into the Linux
> driver and check the performance again later this week.

> Thanks for for the write test. So I can take this as a Ack?

Of course, if you want it,

Acked-by: Bill Pringlemeir 

The OOB patch also significantly decreases UbiFS mounting time in Linux.
I load Linux itself via tftp/network and not using u-boot with nand.  I
guess I should try that.

> I will send all the NFC changes in one patchset as v2 probably later
> today.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCHv3 10/17] arm: socfpga: spl: Add s_init stub

[Dinh Nguyen]

On Fri, 3 Apr 2015, Marek Vasut wrote:

> On Tuesday, March 31, 2015 at 12:01:11 AM, dingu...@opensource.altera.com 
> wrote:
> > From: Dinh Nguyen 
> > 
> > Add a stub s_init function in the board file.
> 
> Why do you add this stub function ? The commit message should
> clarify why the patch is needed.
>

I get this error without this patch:

make: *** [spl/u-boot-spl] Error 2
arch/arm/cpu/armv7/built-in.o: In function `lowlevel_init':
/home/dinguyen/linux_dev/uboot-socfpga/arch/arm/cpu/armv7/lowlevel_init.S:57: 
undefined reference to `s_init'

I got the idea that I needed to add this function from this commit
"24a6bc010 arm: Reduce the scope of lowlevel_init()". 

Commit "e755d543 spl_atmel.c: Switch s_init to board_init_f" is alluding that
lowlevel_init is morphing into s_init(), so for now, a stub s_init is needed?

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

Re: [U-Boot] [PATCHv3 13/17] arm: socfpga: spl: add board_init_f to SPL

[Dinh Nguyen]

On Fri, 3 Apr 2015, Marek Vasut wrote:

> On Tuesday, March 31, 2015 at 11:07:57 PM, Pavel Machek wrote:
> > Hi!
> > 
> > On Mon 2015-03-30 17:01:14, dingu...@opensource.altera.com wrote:
> > > From: Dinh Nguyen 
> > > 
> > > Remap SDRAM to 0x0, and clear OCRAM's ECC in board_init_f().
> > > 
> > > Signed-off-by: Dinh Nguyen 
> > > Reviewed-by: Marek Vasut 
> > > ---
> > > v3: Move the code from s_init to board_init_f
> > > ---
> > > 
> > >  arch/arm/cpu/armv7/socfpga/spl.c | 30 ++
> > >  1 file changed, 30 insertions(+)
> > > 
> > > diff --git a/arch/arm/cpu/armv7/socfpga/spl.c
> > > b/arch/arm/cpu/armv7/socfpga/spl.c index a008eac..f2d3f79 100644
> > > --- a/arch/arm/cpu/armv7/socfpga/spl.c
> > > +++ b/arch/arm/cpu/armv7/socfpga/spl.c
> > > @@ -6,6 +6,7 @@
> > > 
> > >  #include 
> > >  #include 
> > > 
> > > +#include 
> > > 
> > >  #include 
> > >  #include 
> > >  #include 
> > > 
> > > @@ -19,6 +20,9 @@
> > > 
> > >  DECLARE_GLOBAL_DATA_PTR;
> > > 
> > > +static struct pl310_regs *const pl310 =
> > > + (struct pl310_regs *)CONFIG_SYS_PL310_BASE;
> > > +
> > > 
> > >  #define MAIN_VCO_BASE (  \
> > >  
> > >   (CONFIG_HPS_MAINPLLGRP_VCO_DENOM << \
> > >   
> > >   CLKMGR_MAINPLLGRP_VCO_DENOM_OFFSET) |   \
> > > 
> > > @@ -44,6 +48,32 @@ DECLARE_GLOBAL_DATA_PTR;
> > > 
> > >   CLKMGR_SDRPLLGRP_VCO_NUMER_OFFSET)  \
> > >   
> > >   )
> > > 
> > > +void board_init_f(ulong dummy)
> > > +{
> > > +#ifdef CONFIG_SPL_BUILD
> > 
> > I don't get it. File is called spl.c, still it has ifdefs for
> > CONFIG_SPL_BUILD?
> 
> Yeah, this shouldn't be here. In case spl.c would be compiled
> into regular u-boot build, this board_init_f symbol would colide
> with the board_init_f implemented by common/board_f.c
>

Will fix in V4.
 
> > > + struct socfpga_system_manager *sysmgr_regs =
> > > + (struct socfpga_system_manager *)SOCFPGA_SYSMGR_ADDRESS;
> > > + unsigned long reg;
> > > + /*
> > > +  * First C code to run. Clear fake OCRAM ECC first as SBE
> > > +  * and DBE might triggered during power on
> > > +  */
> > > + reg = readl(&sysmgr_regs->eccgrp_ocram);
> > > + if (reg & SYSMGR_ECC_OCRAM_SERR)
> > > + writel(SYSMGR_ECC_OCRAM_SERR | SYSMGR_ECC_OCRAM_EN,
> > > +&sysmgr_regs->eccgrp_ocram);
> > > + if (reg & SYSMGR_ECC_OCRAM_DERR)
> > > + writel(SYSMGR_ECC_OCRAM_DERR  | SYSMGR_ECC_OCRAM_EN,
> > > +&sysmgr_regs->eccgrp_ocram);
> > > +#endif  /* CONFIG_SPL_BUILD */
> > > +
> > > + memset(__bss_start, 0, __bss_end - __bss_start);
> > 
> > Add a comment below?
> > 
> > /* Remap SDRAM to 0x0 */
> > 

I'll add to V4.

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

Re: [U-Boot] Regarding patch: http://patchwork.ozlabs.org/patch/373593/

[Ramneek Mehresh]

> -Original Message-
> From: Marek Vasut [mailto:ma...@denx.de]
> Sent: Tuesday, April 07, 2015 7:44 PM
> To: Mehresh Ramneek-B31383
> Cc: u-boot; s...@denx.de
> Subject: Re: Regarding patch: http://patchwork.ozlabs.org/patch/373593/
> 
> On Tuesday, April 07, 2015 at 04:05:31 PM, Ramneek Mehresh wrote:
> > > -Original Message-
> > > From: Marek Vasut [mailto:ma...@denx.de]
> > > Sent: Tuesday, April 07, 2015 7:22 PM
> > > To: Mehresh Ramneek-B31383
> > > Cc: u-boot; s...@denx.de
> > > Subject: Re: Regarding patch:
> > > http://patchwork.ozlabs.org/patch/373593/
> > >
> > > On Tuesday, April 07, 2015 at 08:18:03 AM, Ramneek Mehresh wrote:
> > >
> > > [...]
> > >
> > > > > Hi,
> > > > >
> > > > > Is this similar hardware bug to the one which MX6 PCIe is
> > > > > suffering ? On MX6, the bug is that you cannot reset the PCIe
> > > > > and PCIe PHY from software, which means that if you start PCIe
> > > > > in U-Boot, you cannot reliably use it in Linux. Furthermore, if
> > > > > you reset the MX6 via WDT, you cannot start PCIe reliably in
> > > > > Linux even if PCIe is not used in U-Boot at all.
> > > > >
> > > > > Is this the same type of hardware screwup where the design team
> > > > > didn't think reset was necessary?
> > > >
> > > > I have raised request for this feature in up-coming socs, and they
> > > > have agreed to provide phy shut-down in future revs. However, this
> > > > support is not available in current revs for which the code is sent.
> > > > What do you suggest we should do for current socs?
> > >
> > > Hi,
> > >
> > > I don't know, but doesn't leaving the USB running cause trouble to Linux?
> > > I think you should at least document the reasoning why the USB stop
> > > is not implemented for this broken hardware.
> >
> > Hi Marek, it's not USB controller stop, it's Phy stop which is not
> > supported. Controller stopping is supported.
> 
> OK, does it pose a problem for Linux ? If not, then please just document it
> and let's stick with what there now.
> 
No, it won't create issue in Linux because Linux usb driver resets the 
controller
(which in turn resets the phy). Please suggest what's the best place to 
document this.
Shall I document this inside some u-boot doc file?

> 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] usb: hub: allow pgood_delay to be specified via env

[Tim Harvey]

On Mon, Apr 6, 2015 at 7:58 AM, Marek Vasut  wrote:
> On Monday, April 06, 2015 at 04:05:07 PM, Tim Harvey wrote:
>> Some USB devices break the spec and require longer warm-up times. Allow
>> the usb_pgood_delay env variable to override the calculated time.
>>
>> I have encountered this specficically with several different sized/branded
>> USB sticks with VID:PID 058f:6387 (Alcor Micro Corp. Transcend JetFlash)
>> where I need to set usb_pgood_delay to 2000ms to make them detectable.
>>
>> Signed-off-by: Tim Harvey 
>
> Hi!
>
> this looks like a good idea. I have a hint for improvement -- in case you
> get a timeout waiting for the device to be detected, maybe the error message
> should mention that you can try setting this env variable and try again ?
>
> Best regards,
> Marek Vasut

Marek,

I'm not sure what 'failed detect' would be appropriate though. In my
case I was dealing with storage devices so I think what you are
proposing is that on a 'usb start' if 0 storage devices are found
display a message such as:

No storage devices found - if a connected device is not being detected
try setting usb_pgood_delay env var to something above the 1000ms time
the USB spec allows

Sounds a bit verbose and I'm not clear if it should be limited to USB
storage devices or other supported devices (I'm betting its just the
storage ones that often break the spec).

Stephen, what do you think? You and I discussed adding such an env var
about a year ago.

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

Re: [U-Boot] Regarding patch: http://patchwork.ozlabs.org/patch/373593/

[Ramneek Mehresh]

> -Original Message-
> From: Mehresh Ramneek-B31383
> Sent: Tuesday, April 07, 2015 8:12 PM
> To: 'Marek Vasut'
> Cc: u-boot; s...@denx.de
> Subject: RE: Regarding patch: http://patchwork.ozlabs.org/patch/373593/
> 
> 
> 
> > -Original Message-
> > From: Marek Vasut [mailto:ma...@denx.de]
> > Sent: Tuesday, April 07, 2015 7:44 PM
> > To: Mehresh Ramneek-B31383
> > Cc: u-boot; s...@denx.de
> > Subject: Re: Regarding patch:
> > http://patchwork.ozlabs.org/patch/373593/
> >
> > On Tuesday, April 07, 2015 at 04:05:31 PM, Ramneek Mehresh wrote:
> > > > -Original Message-
> > > > From: Marek Vasut [mailto:ma...@denx.de]
> > > > Sent: Tuesday, April 07, 2015 7:22 PM
> > > > To: Mehresh Ramneek-B31383
> > > > Cc: u-boot; s...@denx.de
> > > > Subject: Re: Regarding patch:
> > > > http://patchwork.ozlabs.org/patch/373593/
> > > >
> > > > On Tuesday, April 07, 2015 at 08:18:03 AM, Ramneek Mehresh wrote:
> > > >
> > > > [...]
> > > >
> > > > > > Hi,
> > > > > >
> > > > > > Is this similar hardware bug to the one which MX6 PCIe is
> > > > > > suffering ? On MX6, the bug is that you cannot reset the PCIe
> > > > > > and PCIe PHY from software, which means that if you start PCIe
> > > > > > in U-Boot, you cannot reliably use it in Linux. Furthermore,
> > > > > > if you reset the MX6 via WDT, you cannot start PCIe reliably
> > > > > > in Linux even if PCIe is not used in U-Boot at all.
> > > > > >
> > > > > > Is this the same type of hardware screwup where the design
> > > > > > team didn't think reset was necessary?
> > > > >
> > > > > I have raised request for this feature in up-coming socs, and
> > > > > they have agreed to provide phy shut-down in future revs.
> > > > > However, this support is not available in current revs for which the
> code is sent.
> > > > > What do you suggest we should do for current socs?
> > > >
> > > > Hi,
> > > >
> > > > I don't know, but doesn't leaving the USB running cause trouble to
> Linux?
> > > > I think you should at least document the reasoning why the USB
> > > > stop is not implemented for this broken hardware.
> > >
> > > Hi Marek, it's not USB controller stop, it's Phy stop which is not
> > > supported. Controller stopping is supported.
> >
> > OK, does it pose a problem for Linux ? If not, then please just
> > document it and let's stick with what there now.
> >
> No, it won't create issue in Linux because Linux usb driver resets the
> controller (which in turn resets the phy). Please suggest what's the best
> place to document this.
> Shall I document this inside some u-boot doc file?
> 
I can document this inside xhci_stop() part of fsl driver. In addition,
this will also be documented in FSL USB driver documentation.
Please tell if this is ok.

> > 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/2] mtd: vf610_nfc: remove caching of page in buffer

[Stefan Agner]

On 2015-04-07 16:24, Bill Pringlemeir wrote:
> On  7 Apr 2015, ste...@agner.ch wrote:
>> On 2015-04-02 22:30, Bill Pringlemeir wrote:
>>> On  2 Apr 2015, ste...@agner.ch wrote:
> 
>>> [snip]
> 
>>> I also measured 'write performance' with the mtd_speedtest
>>> (performing similar patch to the Linux driver) and I see no
>>> difference.  I think a write benchmark is more appropriate to test
>>> this functionality?  While at least it seems that neither read nor
>>> write is affected by the simplification.
> 
>> On U-Boot, I just benchmarked the overall boot time since this is most
>> important for us. I plan to (re-)integrate the changes into the Linux
>> driver and check the performance again later this week.
> 
>> Thanks for for the write test. So I can take this as a Ack?
> 
> Of course, if you want it,
> 
> Acked-by: Bill Pringlemeir 

Thx


> The OOB patch also significantly decreases UbiFS mounting time in Linux.
> I load Linux itself via tftp/network and not using u-boot with nand.  I
> guess I should try that.

Is it UBIFS mounting time or is it bad block scanning? Afaik, it should
speed up the latter significantly, but I don't see why it should speed
up the former.

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

Re: [U-Boot] [PATCH v3 06/17] dm: regulator: add implementation of driver model regulator uclass

[Przemyslaw Marczak]

Hello Simon,

On 04/05/2015 08:30 PM, Simon Glass wrote:

Hi Przemyslaw,

On 3 April 2015 at 10:09, Przemyslaw Marczak  wrote:

Hello Simon,


On 03/29/2015 03:07 PM, Simon Glass wrote:


Hi Przemyslaw,

On 24 March 2015 at 14:30, Przemyslaw Marczak 
wrote:


[snip]




+
+   info->min_uV = fdtdec_get_int(gd->fdt_blob, offset,
+ "regulator-min-microvolt", -1);
+   if (info->min_uV < 0)
+   return -ENXIO;
+
+   info->max_uV = fdtdec_get_int(gd->fdt_blob, offset,
+ "regulator-max-microvolt", -1);
+   if (info->max_uV < 0)
+   return -ENXIO;
+
+   /* Optional constraints */
+   info->min_uA = fdtdec_get_int(gd->fdt_blob, offset,
+ "regulator-min-microamp", -1);
+   info->max_uA = fdtdec_get_int(gd->fdt_blob, offset,
+ "regulator-max-microamp", -1);
+   info->always_on = fdtdec_get_bool(gd->fdt_blob, offset,
+"regulator-always-on");
+   info->boot_on = fdtdec_get_bool(gd->fdt_blob, offset,
+"regulator-boot-on");
+
+   return 0;
+}
+
+int regulator_get(char *name, struct udevice **devp)
+{
+   struct dm_regulator_info *info;
+   struct udevice *dev;
+   int ret;
+
+   *devp = NULL;
+
+   for (ret = uclass_first_device(UCLASS_REGULATOR, &dev);
+dev;
+ret = uclass_next_device(&dev)) {



This will probe all devices. See my suggestion about creating
uclass_find_first_device()/uclass_find_next_device() in the next
patch.

As before, I think this could use a function like
uclass_get_device_by_name().



Yes, this is the same. But in this case, there is one more  issue, which is
the regulator device name.
Usually after bind -> the dev->name is the same as node name. This is good,
since it's natural that regulator IC, provides e.g "ldo1", or some other
device-output name.
But we would like check the "regulator-name" property. For this patch-set,
the name is fixed at device probe stage, when dev->ofdata_to_platdata() is
called, and the regulator constraints, the same as it's name goes to struct
dm_regulator_info.

I put the dm_regulator_info into uclass priv, because it it uclass-specific,
the same as struct dm_i2c_bus is specific for i2c buses.

But, the ucalss priv is allocated at device probe stage.

I can't use the .per_child_platdata_auto_alloc_size, since the parent is a
pmic, and its uclass type is different.

Actually I could, move the dm_regulator_info only to device platdata, but
then, the drivers should take care of this uclass-specific structure
allocation.
Is it acceptable?

But then, also ambiguous seem to be filling platdata (struct
dm_regulator_info) in uclass post_bind() method.

So then, maybe reasonable is:
- move dm_regulator_info from dev->uclass_priv to dev->platdata - is
allocated after device bind

- add .post_bind() method to regulator uclass, and get the "regulator-name"
in it - only

- fill all platdata constraints on call to dev->ofdata_to_platdata()

Then, I could avoid probing every device, when checking the regulator name.
But, still I can't use the uclass.c functions, since I'm checking the
regulator info at dev->platdata.

So I update the function as below:

+ uclass_foreach_dev(dev, uc) {
+   if (!dev->platdata)
+   continue;
+
+   info = dev->platdata;
+   if (!strcmp(name, info->name)) {
+   ret = device_probe(dev);
+   if (ret)
+  
+   *regulator = dev;
+   return ret;
+   }
+   }




The problem here is similar to I2C which uses per-child platdata
(specified by the uclass) for the bus address. This is different from
device platdata. I think you are suggesting that we should support
uclass platdata. In this case we would have for each device:

- device platform data
- parent platform data
- uclass platform data


Yes, but note, that the uclass type is the same for I2C bus and i2c 
chip. This is a different than for the PMIC, for which childs uclass 
type are usually different than for the parent.

In this case I can't use the field per-child-platdata.



The last one is not supported. I have through several times about
adding it. The alternative is to require each device to provide a
platform data struct at the start of its own platform data, which the
uclass can find and use. This is not really in the spirit of driver
model. But for now this is what I have done with USB (see
dm/usb-working). struct usb_platdata appears at the start of struct
exynos_ehci_platdata but is owned by the uclass.

If PMIC has use for uclass platform data, then perhaps that would be
enough users to warrant it. You could add a patch to do this (don't
forget to update tests) or you could do what I have done with USB and
we can tidy it up later.


T

Re: [U-Boot] [PATCH] usb: hub: allow pgood_delay to be specified via env

[Stephen Warren]

On 04/07/2015 08:52 AM, Tim Harvey wrote:

On Mon, Apr 6, 2015 at 7:58 AM, Marek Vasut  wrote:

On Monday, April 06, 2015 at 04:05:07 PM, Tim Harvey wrote:

Some USB devices break the spec and require longer warm-up times. Allow
the usb_pgood_delay env variable to override the calculated time.

I have encountered this specficically with several different sized/branded
USB sticks with VID:PID 058f:6387 (Alcor Micro Corp. Transcend JetFlash)
where I need to set usb_pgood_delay to 2000ms to make them detectable.

Signed-off-by: Tim Harvey 


Hi!

this looks like a good idea. I have a hint for improvement -- in case you
get a timeout waiting for the device to be detected, maybe the error message
should mention that you can try setting this env variable and try again ?

Best regards,
Marek Vasut


Marek,

I'm not sure what 'failed detect' would be appropriate though. In my
case I was dealing with storage devices so I think what you are
proposing is that on a 'usb start' if 0 storage devices are found
display a message such as:

No storage devices found - if a connected device is not being detected
try setting usb_pgood_delay env var to something above the 1000ms time
the USB spec allows


That seems like something better for the documentation that at run-time. 
There's no reason to believe that the user has any USB storage devices 
plugged in.



Sounds a bit verbose and I'm not clear if it should be limited to USB
storage devices or other supported devices (I'm betting its just the
storage ones that often break the spec).

Stephen, what do you think? You and I discussed adding such an env var
about a year ago.


If there is some kind of error that's actively detected, it may make 
sense to print some kind of message. However, if the symptoms are that 
devices simply don't appear on the bus and there's no reason to believe 
any are actually plugged in, that fells different.

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

Re: [U-Boot] [PATCH 1/2] mtd: vf610_nfc: mark page as dirty on block erase

[Scott Wood]

On Tue, 2015-04-07 at 10:06 -0400, Bill Pringlemeir wrote:
> On  3 Apr 2015, scottw...@freescale.com wrote:
> 
> > On Fri, 2015-04-03 at 22:28 +0200, Stefan Agner wrote:
> 
> >> Why not? IMHO, there are valid reason to do it, since we save coping
> >> data over the bus (we save copying page size - write len of bytes)...
> 
> > According to http://www.linux-mtd.infradead.org/doc/ubi.html#L_subpage
> > the motivation for subpages is saving space, not time, and it's only
> > used for headers (specifically because using subpages may be slower).
> > So it may not make a huge performance difference either way, even if
> > subpages are less efficient on this controller -- though it does have
> > a complexity cost that is higher than with most controllers.  It looks
> > like the space savings is around one page per block.
> 
> I think that Artem wrote this.  I don't believe the document is
> completely correct; I think he meant that sub-pages is not architected
> as a speed improvement.  For instance, UBI will read both a VID (volume
> ID) and EB (erase block).  As the are combined into one, then if a
> driver needs to read a full page (like it is the only thing it supports)
> then it is simple to read a full page with a VID/EB sub-pages.
> Certainly for mounts with out 'fastmap', this will result in much faster
> scans and initial UBI/UbiFS mounts?
> 
> It also saves one page overhead per erase block.  So in all cases,
> sub-pages will optimize flash usage.  Probably performance depends on
> the MTD driver and CPU.

Possibly.  Again, I recommend benchmarking before committing to it.

> > It'd be good to benchmark up front to be sure you're happy with the
> > speed/space/complexity tradeoff, though, since enabling/disabling
> > subpage writes breaks UBI compatibility.
> 
> I think that if you format the UbiFs without sub-pages and then update
> code to handle sub-pages, you are fine.  If you have flash/UBI formatted
> with sub-pages and then you disable it in the code, the disk is no
> longer mountable.

If that's the case, then that's even more reason to leave subpages
disabled until you're sure you want them.

> In any case the document has,
> 
>   If the NAND flash supports sub-pages, then what can be done is ECC
>   codes can be calculated on per-sub-page basis, instead of per-NAND
>   page basis. In this case it becomes possible to read and write
>   sub-pages independently.
> 
> Probably if we want sub-pages with this controller and hw-ecc, we need
> to use the virtual buffer features of the chip.  The controller needs an
> entire current buffer in the SRAM to calculate the hw-ecc to write.  So
> even if it writes less than a full page, the entire page must be read to
> calculate the hw-ecc to be written.

That limitation sounds similar to the Freescale NAND controllers that
I'm familiar with (eLBC and IFC).  For eLBC we do subpages by just
writing 0xff, because on that controller the ECC of all 0xff is all 0xff
so it doesn't disturb anything.  IFC has different ECC algorithms where
that isn't the case, so we disabled subpage write on IFC.

What is the virtual buffer feature?

> I am pretty sure that all controllers that support hw-ecc will need to do 
> this.

Not if they can handle doing ECC on a single subpage.

-Scott


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

Re: [U-Boot] [PATCH] usb: hub: allow pgood_delay to be specified via env

[Tim Harvey]

On Tue, Apr 7, 2015 at 8:34 AM, Stephen Warren  wrote:
> On 04/07/2015 08:52 AM, Tim Harvey wrote:
>>
>> On Mon, Apr 6, 2015 at 7:58 AM, Marek Vasut  wrote:
>>>
>>> On Monday, April 06, 2015 at 04:05:07 PM, Tim Harvey wrote:

 Some USB devices break the spec and require longer warm-up times. Allow
 the usb_pgood_delay env variable to override the calculated time.

 I have encountered this specficically with several different
 sized/branded
 USB sticks with VID:PID 058f:6387 (Alcor Micro Corp. Transcend JetFlash)
 where I need to set usb_pgood_delay to 2000ms to make them detectable.

 Signed-off-by: Tim Harvey 
>>>
>>>
>>> Hi!
>>>
>>> this looks like a good idea. I have a hint for improvement -- in case you
>>> get a timeout waiting for the device to be detected, maybe the error
>>> message
>>> should mention that you can try setting this env variable and try again ?
>>>
>>> Best regards,
>>> Marek Vasut
>>
>>
>> Marek,
>>
>> I'm not sure what 'failed detect' would be appropriate though. In my
>> case I was dealing with storage devices so I think what you are
>> proposing is that on a 'usb start' if 0 storage devices are found
>> display a message such as:
>>
>> No storage devices found - if a connected device is not being detected
>> try setting usb_pgood_delay env var to something above the 1000ms time
>> the USB spec allows
>
>
> That seems like something better for the documentation that at run-time.
> There's no reason to believe that the user has any USB storage devices
> plugged in.
>
>> Sounds a bit verbose and I'm not clear if it should be limited to USB
>> storage devices or other supported devices (I'm betting its just the
>> storage ones that often break the spec).
>>
>> Stephen, what do you think? You and I discussed adding such an env var
>> about a year ago.
>
>
> If there is some kind of error that's actively detected, it may make sense
> to print some kind of message. However, if the symptoms are that devices
> simply don't appear on the bus and there's no reason to believe any are
> actually plugged in, that fells different.

No error... just failure to detect storage device. I agree such a
message for people using 'usb start' for some other usb device is not
cool.

Let's leave it as-is then if there are no complaints.

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

Re: [U-Boot] Copy to Flash... 9Flash not Erased

[Rudolf Streif]

Hi Dirk,


this sounds oddly familiar. Which gcc version are you using? 4.8? gcc
> 4.8 is broken for powerpc u-boot.
>

Thanks for the pointer. I am using gcc 4.7.2.



> For more background search for the "Relocation issue - need help!"
> started by Wolfgang Denk on the mailing list.
>
> I will researching this. Oddly enough, I was able to reflash u-boot itself
many times without issues. However, when I am reflashing the Linux kernel I
am seeing this issue. The other odd thing is that the board I am working
with has two identical sections with the exact same setup of CPU, memory,
flash, etc. It works on one section but does not on the other. We also
tried a second board that shows the exact same behavior with the same
sections. Digging into it with the hardware folks.

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

Re: [U-Boot] [PATCH 4/4] mtd: vf610_nfc: support subpage write

[Scott Wood]

On Tue, 2015-04-07 at 09:48 -0400, Bill Pringlemeir wrote:
> On  3 Apr 2015, ste...@agner.ch wrote:
> 
> > I will remove the page read on NAND_CMD_SEQIN, since we memcpy the
> > full page anyway. I also just realized that the page read actually
> > happens always and hence slows down even full page writes...
> 
> Yes, I remove this in Linux (4.0) and it corrupted things when writing.
> I think your previous conclusion about we never use 'write caching' was
> wrong.
> 
> This one is for writes,
> 
>   case NAND_CMD_SEQIN: /* Pre-read for partial writes. */
> 
> This one is for reads,
> 
>   case NAND_CMD_READ0:
> 
> The interface between 'nand_base' and the MTD driver is hard to
> decipher.  Does Scott (or anyone) know if there is any documentation on
> this?

It's an awkward interface for drivers that expose a higher-level
programming model.  Basically you have to behave as if nand_base could
send commands directly to the chip.

> Stefan is completely correct that if a full page is being written, then
> the 'SEQIN' should not read a page.  However, I only see 'column' being
> passed.  How is 'SEQIN' and 'PAGEPROG' to detect if a full page is being
> written or not?

At SEQIN time, you can't.  You'll know based on how much data is written
into the buffer.  Or, you can skip this low-level interface and replace
nand_write_page (which is what I wish we'd done in the eLBC/IFC
drivers).

> The other way to handle things would to be to investigate the
> NFC_CFG[PAGE_CNT] and NFC_SECSZ to have the virtual pages support
> sub-pages.  I think the OOB mapping would be non-standard in such cases.

Wouldn't that mess up factory bad block markers?

-Scott


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

Re: [U-Boot] [PATCH] net/phy: fixup for get_phy_id

[Joe Hershberger]

Hi Shengzhou Liu,

On Tue, Apr 7, 2015 at 5:46 AM, Shengzhou Liu 
wrote:
>
> commit 3c6928fd7b0f84 "net: phy: fix warnings with W=1" caused
> some PHYs(e.g. CS4315/CS4340) not working. This patch fixes the
> warning and make those special PHYs working as well.
>
> Signed-off-by: Shengzhou Liu 

Applied to net/next, thanks!

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

Re: [U-Boot] [PATCH 1/2] mtd: vf610_nfc: remove caching of page in buffer

[Bill Pringlemeir]

On  7 Apr 2015, ste...@agner.ch wrote:

> On 2015-04-07 16:24, Bill Pringlemeir wrote:

>> The OOB patch also significantly decreases UbiFS mounting time in
>> Linux.  I load Linux itself via tftp/network and not using u-boot
>> with nand.  I guess I should try that.

> Is it UBIFS mounting time or is it bad block scanning? Afaik, it
> should speed up the latter significantly, but I don't see why it
> should speed up the former.

It is both,

* no changes.

[0.840632] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xca
[0.964838] 0x0104-0x1000 : "root"
.124s

base ubi0 mount is .833585s

* improved READ_OOB

[0.638869] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xca
[0.707994] 0x0104-0x1000 : "root"
.069s

base ubi0 mount 1/10s reduction. .738204s


This is for a 256MB device.  The Ubi mount/scan time is not completely
in-significant.

For instance, here is my last run with improved READ_OOB

   [ 0.942538] ubi0: attaching mtd3
   ...
   [ 1.680742] ubi0: background thread "ubi_bgt0d" started, PID 104

This is my 'base ubi0 mount' numbers.

The time is slightly different than what I recorded previously.  I
booted several times without 'READ_OOB' and the times were consistently
'.83xxS'.  It is possible that the initial BBT scan being quicker
altered something; so it is not UBI use of OOB.  I am not sure.  I just
noted that it was ??significantly?? different.

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

[U-Boot] [PATCH] cmd_mem.c: Update 'iteration_limit' to unsigned long

[Tom Rini]

With e37f1eb we now use strict_strtoul() in do_mem_mtest() and this
gives us a warning:
../include/vsprintf.h:38:5: note: expected 'long unsigned int *' but
argument is of type 'int *'

Signed-off-by: Tom Rini 
---
 common/cmd_mem.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/common/cmd_mem.c b/common/cmd_mem.c
index 20a875c..3f85c1a 100644
--- a/common/cmd_mem.c
+++ b/common/cmd_mem.c
@@ -999,7 +999,7 @@ static int do_mem_mtest(cmd_tbl_t *cmdtp, int flag, int 
argc,
 {
ulong start, end;
vu_long *buf, *dummy;
-   int iteration_limit = 0;
+   ulong iteration_limit = 0;
int ret;
ulong errs = 0; /* number of errors, or -1 if interrupted */
ulong pattern = 0;
-- 
1.7.9.5

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

Re: [U-Boot] Pull request: u-boot-spi/master

[Tom Rini]

On Tue, Mar 31, 2015 at 12:44:46PM +0530, Jagannadha Sutradharudu Teki wrote:

> Hi Tom,
> 
> Please pull this PR.
> 
> thanks!
> Jagan.
> 
> The following changes since commit 662e2acb46250881ec26bc8366fc9eb1856cb7c2:
> 
>   sunxi: UTOO_P66: Add missing MAINTAINERS entry (2015-03-29 14:56:48 +0200)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-spi.git master
> 
> for you to fetch changes up to 52091ad146d766cdc5ccd65430b2a4e5cb7aec32:
> 
>   spi: designware_spi: revisit FIFO size detection again (2015-03-30 01:42:49 
> +0530)
> 

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] env_sf: Fix recovery default

[Tom Rini]

On Tue, Mar 24, 2015 at 08:59:00AM +0100, Mario Schuknecht wrote:

> The u-boot environment is redundantly stored in a NOR flash on our boards.
> Redundant means that there are two places to store the environment. But only
> one of the two is active. I discovered that on one board the u-boot (env_sf)
> uses the environment from the second place and the Kernel (fw_printenv) uses
> the environment from the first place.
> To decide which is the active environment there is a byte inside the
> environment. 1 means active and 0 means obsolete. But on that board both
> environments had have a 1. This can happen if a power loss or reset occurs
> during writing the environment. In this situation the u-boot (env_sf)
> implementation uses the second environment as default. But the Kernel
> (fw_printenv) implementation uses the first environment as default.
> 
> This commit corrects the default in the u-boot env_sf implementation when a
> problem was detected. Now the recovery default is the same like in all other
> environment implementations. E.g. fw_printenv and env_flash. This ensures that
> u-boot and Kernel use the same environment.
> 
> Signed-off-by: Mario Schuknecht 

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] am33xx/ddr.c: Fix regression on DDR2 platforms

[Tom Rini]

On Thu, Apr 02, 2015 at 04:01:33PM -0400, Tom Rini wrote:

> Back in fc46bae a "clean up" was introduced that intended to reconcile
> some of the AM335x codepaths based on how AM43xx operates.
> Unfortunately this introduced a regression on the DDR2 platforms.  This
> was un-noticed on DDR3 (everything except for Beaglebone White) as we
> had already populated sdram_config correctly in sequence.  This change
> brings us back to the older behavior and is fine on all platforms.
> 
> Tested on Beaglebone White, Beaglebone Black and AM335x GP EVM
> 
> Reported-by: Matt Ranostay 
> Signed-off-by: Tom Rini 

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] ahci: Fix a wrong parameter pass

[Tom Rini]

On Tue, Mar 31, 2015 at 03:02:43PM +0800, tang yuantian wrote:

> From: Tang Yuantian 
> 
> In stead of user_buffer_size, transfer_size should be used to pass to
> ahci_device_data_io(). transfer_size is the length that we want the
> low level function to transfer each time.
> If we use user_buffer_size which is the totally data length as parameter,
> low level function will actually create many SGs to transfer as many data
> as possible each time. That will produce many redundant data transfer.
> 
> Signed-off-by: Tang Yuantian 
> Reviewed-by: Simon Glass 

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] cmd_mem: cleanups, catch bad usage

[Tom Rini]

On Wed, Apr 01, 2015 at 01:50:41PM +0200, Pavel Machek wrote:

> Currently, memtest will silently accept bad data. Perform error
> checking on user intput.
> 
> Signed-off-by: Pavel Machek 
> 
> diff --git a/common/cmd_mem.c b/common/cmd_mem.c
> index bfca59e..e6623b0 100644

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] kbuild: include config.mk when auto.conf is not older than .config

[Tom Rini]

On Fri, Apr 03, 2015 at 12:30:25PM +0900, Masahiro Yamada wrote:

> Since the Kconfig conversion, config.mk has been included only when
> include/config/auto.conf is newer than the .config file.
> 
> It causes build error if both files have the same time-stamps.
> It is actually possible because EXT* file systems have a 1s time-stamp
> resolution.
> 
> The config.mk should be included when include/config/auto.conf is
> *not older* than the .config file.
> 
> Signed-off-by: Masahiro Yamada 
> Reported-by: Tom Rini 
> Reported-by: York Sun 
> Reported-by: Stephen Warren 
> Reported-by: Matthew Gerlach 
> Tested-by: Stephen Warren 

Great job finally root causing this Stephen and then fixing it Masahiro!

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] fix makefiles to respect DTC setting

[Tom Rini]

On Mon, Apr 06, 2015 at 03:46:44PM +0200, Pavel Machek wrote:

> Top-level Makefile has option to select dtc binary, but it is ignored
> due to bug in Makefile.lib. Fix it.
> 
> Signed-off-by: Pavel Machek 
> 
> diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
> index 13af604..8731fc6 100644

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] [U-Boot, v3] MAKEALL: fix get_target_arch() to adjust to '-' in Status field

[Tom Rini]

On Mon, Apr 06, 2015 at 11:12:28AM +0900, Masahiro Yamada wrote:

> Since the Kconfig conversion, boards.cfg scanned by MAKEALL is
> generated by tools/genboardscfg.py.  Every board is supposed to have
> its own MAINTAINERS that contains maintainer and status information,
> but, in fact, MAINTAINERS is missing from some boards.
> 
> For such boards, the first field, Status, is filled with '-'.
> It causes a problem for "set" command, which ignores '-' in its
> arguments.  Consequently, get_target_arch() returns a wrong field
> and MAKEALL fails to get a correct toolchain.
> 
> Signed-off-by: Masahiro Yamada 

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] mtd: vf610_nfc: mark page as dirty on block erase

[Bill Pringlemeir]

On  7 Apr 2015, scottw...@freescale.com wrote:
> On Tue, 2015-04-07 at 10:06 -0400, Bill Pringlemeir wrote:

>> In any case the document has,

>> If the NAND flash supports sub-pages, then what can be done is ECC
>> codes can be calculated on per-sub-page basis, instead of per-NAND
>> page basis. In this case it becomes possible to read and write
>> sub-pages independently.

>> Probably if we want sub-pages with this controller and hw-ecc, we
>> need to use the virtual buffer features of the chip.  The controller
>> needs an entire current buffer in the SRAM to calculate the hw-ecc to
>> write.  So even if it writes less than a full page, the entire page
>> must be read to calculate the hw-ecc to be written.

> That limitation sounds similar to the Freescale NAND controllers that
> I'm familiar with (eLBC and IFC).  For eLBC we do subpages by just
> writing 0xff, because on that controller the ECC of all 0xff is all
> 0xff so it doesn't disturb anything.  IFC has different ECC algorithms
> where that isn't the case, so we disabled subpage write on IFC.

> What is the virtual buffer feature?

>> I am pretty sure that all controllers that support hw-ecc will need
>> to do this.

> Not if they can handle doing ECC on a single subpage.

[from another thread, but the same subject].

>> The other way to handle things would to be to investigate the
>> NFC_CFG[PAGE_CNT] and NFC_SECSZ to have the virtual pages support
>> sub-pages.  I think the OOB mapping would be non-standard in such
>> cases.

> Wouldn't that mess up factory bad block markers?

All the stuff above is related (afaik).

  > What is the virtual buffer feature?

It splits programming of a flash page into separate buffers.  The
BCH-HW-ECC is then applied separately to each 'virtual-page' with
reduced strength.  Section "31.4.6 Organization of the Data in the NAND
Flash" of the Vybrid Software RM has details.

 > Wouldn't that mess up factory bad block markers?

I am unsure; certainly they can be read but they might be a data portion
of the fourth sub-page depending on the ECC strength selected.  There is
also a 'NFC_SWAP' register to switch the position of one 16bit index
(move OOB-BBT 16bit from data to OOB).  I think this can be used.  By
non-standard, I meant not fitting the current drivers idea of OOB
layout.

However, it seems like your comment that the ECC must be different
per-subpage (and what Artem said in the sub-pages documentation) makes
'virtual buffers' the most promising path for this driver and sub-page
support with hw-ecc.  As the bit strength is reduced, the amount of
corrections/error detection also seems reduced.  I think the math would
make this the same for everyone?

Your question about factory BBT is a good point.  Using the 'virtual
buffers' feature will complicate the driver code by quite a bit at least
from what I could think of and what I see in the MTD tree where I
believe similar features are used.

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

Re: [U-Boot] [PATCH] cmd_mem.c: Update 'iteration_limit' to unsigned long

[Tom Rini]

On Tue, Apr 07, 2015 at 01:57:50PM -0400, Tom Rini wrote:

> With e37f1eb we now use strict_strtoul() in do_mem_mtest() and this
> gives us a warning:
> ../include/vsprintf.h:38:5: note: expected 'long unsigned int *' but
> argument is of type 'int *'
> 
> Signed-off-by: Tom Rini 

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 v2 01/80] linker_lists: Add a function to access a linker list entry

[Simon Glass]

On 25 March 2015 at 12:21, Simon Glass  wrote:
> Once declared, you cannot access a linker_list entry since you do not have
> a symbol name for it. Add llsym() macro to provide this. This avoids
> searching for the symbol at run-time based on name.
>
> An example usage is to declare a driver with U_BOOT_DRIVER(), then obtain
> a pointer to that driver later.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  include/linker_lists.h | 10 ++
>  1 file changed, 10 insertions(+)

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

Re: [U-Boot] [PATCH v2] dm: spi: Convert Freescale QSPI driver to driver model

[Simon Glass]

On 6 April 2015 at 16:47, Simon Glass  wrote:
> On 1 April 2015 at 01:19, Peng Fan  wrote:
>> Hi Haikun,
>>
>>
>> On 4/1/2015 11:10 AM, Haikun Wang wrote:
>>>
>>> Move the Freescale QSPI driver over to driver model.
>>>
>>> Signed-off-by: Haikun Wang 
>>> Signed-off-by: Peng Fan 
>>> ---
>>>
>>> Changes in v2:
>>> - Fix build fail on mx6sxsabresd_spl issue
>>> - Add configure regmap endian in NO-DM model
>>>
>>> Changes in v1: None.
>>>
> [snip]
>
>>
>> Testey-by: Peng Fan 
>
> Acked-by: Simon Glass 

Corrected the Tested-by tag.

Applied to u-boot-dm/next, thanks!

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

Re: [U-Boot] [PATCH v2] dm: eth: Provide a way for drivers to manage packet buffers

[Simon Glass]

On 5 April 2015 at 12:31, Simon Glass  wrote:
> Hi Joe,
>
> On 3 April 2015 at 19:09, Joe Hershberger  wrote:
>> Some drivers need a chance to manage their receive buffers after the
>> packet has been handled by the network stack. Add an operation that
>> will allow the driver to be called in that case.
>>
>> Reported-by: Simon Glass 
>> Signed-off-by: Joe Hershberger 
>> Acked-by: Simon Glass 
>> Tested-by: Simon Glass 
>> Tested-on: pcduino3
>> ---
>> This patch depends on dm/next
>>
>> Changes in v2:
>> -Call free_pkt() even when driver returns 0
>> -Add more comments about this new behavior
>>
>>  include/net.h | 8 +++-
>>  net/eth.c | 4 +++-
>>  2 files changed, 10 insertions(+), 2 deletions(-)
>>
>> diff --git a/include/net.h b/include/net.h
>> index e7f28d7..35602cd 100644
>> --- a/include/net.h
>> +++ b/include/net.h
>> @@ -97,7 +97,12 @@ struct eth_pdata {
>>   * send: Send the bytes passed in "packet" as a packet on the wire
>>   * recv: Check if the hardware received a packet. If so, set the pointer to 
>> the
>>   *  packet buffer in the packetp parameter. If not, return an error or 
>> 0 to
>> - *  indicate that the hardware receive FIFO is empty
>> + *  indicate that the hardware receive FIFO is empty. If 0 is returned, 
>> the
>> + *  network stack will not process the empty packet, but free_pkt() 
>> will be
>> + *  called if supplied
>> + * free_pkt: Give the driver an opportunity to manage its packet buffer 
>> memory
>> + *  when the network stack is finished processing it. This will 
>> only be
>> + *  called when no error was returned from recv - optional
>>   * stop: Stop the hardware from looking for packets - may be called even if
>>   *  state == PASSIVE
>>   * mcast: Join or leave a multicast group (for TFTP) - optional
>> @@ -113,6 +118,7 @@ struct eth_ops {
>> int (*start)(struct udevice *dev);
>> int (*send)(struct udevice *dev, void *packet, int length);
>> int (*recv)(struct udevice *dev, uchar **packetp);
>> +   int (*free_pkt)(struct udevice *dev, uchar *packet, int length);
>> void (*stop)(struct udevice *dev);
>>  #ifdef CONFIG_MCAST_TFTP
>> int (*mcast)(struct udevice *dev, const u8 *enetaddr, int join);
>> diff --git a/net/eth.c b/net/eth.c
>> index 13b7723..05411f1 100644
>> --- a/net/eth.c
>> +++ b/net/eth.c
>> @@ -344,7 +344,9 @@ int eth_rx(void)
>> ret = eth_get_ops(current)->recv(current, &packet);
>> if (ret > 0)
>> net_process_received_packet(packet, ret);
>> -   else
>> +   if (ret >= 0 && eth_get_ops(current)->free_pkt)
>> +   eth_get_ops(current)->free_pkt(current, packet, ret);
>> +   if (ret <= 0)
>> break;
>> }
>> if (ret == -EAGAIN)
>> --
>> 1.7.11.5
>>
>
> Looks good, I will pick this up for u-boot-dm/next.

Applied to u-boot-dm/next, thanks!

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

Re: [U-Boot] [PATCH v2 03/80] dm: test: bus: Use a local variable to simplify code

[Simon Glass]

On 25 March 2015 at 12:21, Simon Glass  wrote:
> Adjust this test to avoid repeating the same code too often.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  test/dm/bus.c | 16 ++--
>  1 file changed, 10 insertions(+), 6 deletions(-)

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

Re: [U-Boot] [PATCH v2 04/80] dm: exynos: snow: Move the keyboard to I2C

[Simon Glass]

Hi,

On 25 March 2015 at 12:21, Simon Glass  wrote:
> The snow keyboard on shipping devices is actually on I2C not SPI. Move the
> label to indicate this.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  arch/arm/dts/exynos5250-snow.dts | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

This patch is not needed now, so I'm dropping it. Commit  c9b53f8d
solved this problem.

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

Re: [U-Boot] [PATCH v2 02/80] sandbox: Fix comment for os_open()

[Simon Glass]

On 25 March 2015 at 12:21, Simon Glass  wrote:
> This has the wrong #define in the function comment. Fix it.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  include/os.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

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

Re: [U-Boot] [PATCH v2 06/80] dm: core: Convert driver_bind() to use const

[Simon Glass]

On 25 March 2015 at 12:21, Simon Glass  wrote:
> The driver is not modified by driver model, so update driver_bind() to
> recognise that.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  drivers/core/device-remove.c | 4 ++--
>  drivers/core/device.c| 7 ---
>  include/dm/device-internal.h | 2 +-
>  include/dm/device.h  | 2 +-
>  4 files changed, 8 insertions(+), 7 deletions(-)

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

Re: [U-Boot] [PATCH v2 05/80] dm: core: Support allocating driver-private data for DMA

[Simon Glass]

On 25 March 2015 at 12:21, Simon Glass  wrote:
> Some driver want to put DMA buffers in their private data. Add a flag
> to tell driver model to align driver-private data to a cache boundary so
> that DMA will work correctly in this case.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  drivers/core/device.c | 19 +--
>  include/dm/device.h   |  3 +++
>  2 files changed, 20 insertions(+), 2 deletions(-)

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

Re: [U-Boot] [PATCH v2 11/80] dm: usb: Add a uclass for USB controllers

[Simon Glass]

On 25 March 2015 at 12:21, Simon Glass  wrote:
> Add a uclass that can represent a USB controller. For now we do not create
> devices for things attached to the controller. This will be added later.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  drivers/usb/Kconfig   |  14 ++
>  drivers/usb/host/Makefile |   4 +
>  drivers/usb/host/usb-uclass.c | 392 
> ++
>  drivers/usb/musb-new/musb_uboot.c |   4 +-
>  include/dm/uclass-id.h|   1 +
>  include/usb.h | 285 ++-
>  6 files changed, 694 insertions(+), 6 deletions(-)
>  create mode 100644 drivers/usb/host/usb-uclass.c

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

Re: [U-Boot] [PATCH v2 07/80] dm: core: Rename driver data function to dev_get_driver_data()

[Simon Glass]

On 25 March 2015 at 12:21, Simon Glass  wrote:
> The existing get_get_of_data() function provides access to both the driver's
> compatible string and its driver data. However only the latter is actually
> useful. Update the interface to reflect this and fix up existing users.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  drivers/core/device.c |  4 ++--
>  drivers/core/lists.c  |  2 +-
>  drivers/i2c/s3c24x0_i2c.c |  2 +-
>  drivers/i2c/tegra_i2c.c   |  6 +++---
>  include/dm/device.h   | 16 +++-
>  5 files changed, 18 insertions(+), 12 deletions(-)

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

Re: [U-Boot] [PATCH v2 10/80] dm: gpio: Add an implementation for gpio_get_number()

[Simon Glass]

On 25 March 2015 at 12:21, Simon Glass  wrote:
> This has a prototype but no implementation. It returns the global GPIO number
> given a gpio_desc. It is useful for debugging in some cases.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  drivers/gpio/gpio-uclass.c | 12 
>  1 file changed, 12 insertions(+)

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

Re: [U-Boot] [PATCH v2 08/80] dm: core: Mark device as active before calling uclass probe() methods

[Simon Glass]

On 25 March 2015 at 12:21, Simon Glass  wrote:
> The uclass pre-probe functions may end up calling back into the device in
> some circumstances. This can fail if recursion takes place. Adjust the
> ordering so that we mark the device as active early, then retract this
> later if needed.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  drivers/core/device.c | 8 +---
>  test/dm/test-uclass.c | 3 ++-
>  2 files changed, 7 insertions(+), 4 deletions(-)

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

Re: [U-Boot] [PATCH v2 09/80] dm: core: Add device children and sibling functions

[Simon Glass]

On 25 March 2015 at 12:21, Simon Glass  wrote:
> Add some utility functions to check for children and for the last sibling in
> a device's parent.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  drivers/core/device.c | 28 
>  include/dm/device.h   | 30 ++
>  2 files changed, 58 insertions(+)

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

Re: [U-Boot] [PATCH v2 13/80] dm: usb: Adjust usb_alloc_new_device() to return an error

[Simon Glass]

On 25 March 2015 at 12:22, Simon Glass  wrote:
> This function returns NULL on error at present. Adjust it so that we can
> return a real error, as is needed with driver model. Also improve the
> error handling in its caller, usb_hub_port_connect_change(), and adjust
> the code order to prepare for driver model.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  common/usb.c | 17 -
>  common/usb_hub.c | 41 ++---
>  include/usb.h| 20 ++--
>  3 files changed, 52 insertions(+), 26 deletions(-)

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

Re: [U-Boot] [PATCH v2 17/80] dm: usb: Move descriptor setup code into its own function

[Simon Glass]

On 25 March 2015 at 12:22, Simon Glass  wrote:
> usb_new_device() is far too long and does far too much. As a first step, move
> the code that does initial setup and reads a descriptor into its own function
> called usb_setup_descriptor().
>
> For XHCI the init order is different - we set up the device but don't
> actually read the descriptor until after we set an address. Support this
> option as a parameter to usb_setup_descriptor().
>
> Avoid changing this torturous code more than necessary to make it easy to
> review.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  common/usb.c | 117 
> ++-
>  1 file changed, 67 insertions(+), 50 deletions(-)

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

Re: [U-Boot] [PATCH v2 14/80] dm: usb: Convert 'usb' command to support driver model

[Simon Glass]

On 25 March 2015 at 12:22, Simon Glass  wrote:
> Adjust this command to work with the new driver model uclass. It needs to
> iterate through multiple independent controllers to find hubs, and work
> through their children recursively in a different way. Otherwise the
> functionality is much the same.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  common/cmd_usb.c | 147 
> ++-
>  1 file changed, 145 insertions(+), 2 deletions(-)

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

Re: [U-Boot] [PATCH v2 20/80] dm: usb: Convert core usb.c file to support driver model

[Simon Glass]

On 25 March 2015 at 12:22, Simon Glass  wrote:
> Add the required #ifdefs and remove unwanted data structures so that the
> USB uclass will be able to use this file.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  common/usb.c | 31 +--
>  1 file changed, 25 insertions(+), 6 deletions(-)

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

Re: [U-Boot] [PATCH v2 19/80] dm: usb: Complete the splitting up of usb_new_device()

[Simon Glass]

On 25 March 2015 at 12:22, Simon Glass  wrote:
> This function now calls usb_setup_device() to set up the device and
> usb_hub_probe() to check if it is a hub. The XHCI special case is now a
> parameter to usb_setup_device(). The latter will be used by the USB uclass
> when it is added, since it does not rely on any CONFIGs or legacy data
> structures.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  common/usb.c | 114 
> +++
>  1 file changed, 68 insertions(+), 46 deletions(-)

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

Re: [U-Boot] [PATCH v2 18/80] dm: usb: Split out more code from usb_new_device()

[Simon Glass]

On 25 March 2015 at 12:22, Simon Glass  wrote:
> Move the code that sets up the device with a new address into its own
> function, usb_prepare_device().
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  common/usb.c | 72 
> +++-
>  1 file changed, 42 insertions(+), 30 deletions(-)

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

Re: [U-Boot] [PATCH v2 12/80] dm: usb: Adjust usb command to prepare for driver model

[Simon Glass]

On 25 March 2015 at 12:22, Simon Glass  wrote:
> Use 'udev' instead of 'dev' in a few places, reserving 'dev' for driver
> model's struct udevice. Also adjust the code in a few minor ways to make
> it easier to plumb in driver model.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  common/cmd_usb.c | 51 +--
>  1 file changed, 25 insertions(+), 26 deletions(-)

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

Re: [U-Boot] [PATCH v2 15/80] dm: usb: Drop the legacy USB init sequence

[Simon Glass]

On 26 March 2015 at 12:22, Marek Vasut  wrote:
> On Wednesday, March 25, 2015 at 07:22:03 PM, Simon Glass wrote:
>> This CONFIG is not used anywhere in U-Boot, so drop it.
>>
>> Signed-off-by: Simon Glass 
>
> Acked-by: Marek Vasut 

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

Re: [U-Boot] [PATCH v2 22/80] dm: usb: Add driver model support for hubs

[Simon Glass]

On 25 March 2015 at 12:22, Simon Glass  wrote:
> Adjust the existing hub code to support driver model, and add a USB driver
> for hubs.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  common/usb_hub.c   | 94 
> +++---
>  include/dm/uclass-id.h |  1 +
>  2 files changed, 91 insertions(+), 4 deletions(-)

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

Re: [U-Boot] [PATCH v2 23/80] dm: usb: Move USB storage definitions to usb_defs.h

[Simon Glass]

On 25 March 2015 at 12:22, Simon Glass  wrote:
> These are better off in a header file so they can be used by other code (e.g.
> the sandbox USB storage emulator).
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  common/usb_storage.c | 45 ++---
>  include/usb_defs.h   | 42 ++
>  2 files changed, 44 insertions(+), 43 deletions(-)

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

Re: [U-Boot] [PATCH v2 21/80] dm: usb: Split hub detection into its own function

[Simon Glass]

On 25 March 2015 at 12:22, Simon Glass  wrote:
> Split out the hub detection logic so it can be used by driver model. Also
> adjust the code to return errors correctly.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  common/usb_hub.c | 57 
> 
>  1 file changed, 41 insertions(+), 16 deletions(-)

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

Re: [U-Boot] [PATCH v2 24/80] dm: usb: Fix type problems in usb_stor_get_info()

[Simon Glass]

On 25 March 2015 at 12:22, Simon Glass  wrote:
> This function assumes that unsigned long is 32-bits wide, but it is not
> on 64-bit machines. Use the correct type, and add a few debug() lines also.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  common/usb_storage.c | 18 +++---
>  1 file changed, 11 insertions(+), 7 deletions(-)

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

Re: [U-Boot] [PATCH v2 25/80] dm: usb: Simply device finding code in usb_storage

[Simon Glass]

On 25 March 2015 at 12:22, Simon Glass  wrote:
> The for() loop is not needed since the value is immediately accessible.
> Use this instead to simplify the code.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  common/usb_storage.c | 30 +++---
>  1 file changed, 11 insertions(+), 19 deletions(-)

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

Re: [U-Boot] [PATCH v2 28/80] dm: usb: Convert usb_storage to driver model

[Simon Glass]

On 25 March 2015 at 12:22, Simon Glass  wrote:
> Add support for scanning USB storage devices with driver model. This mostly
> involves adding a USB device ID for storage devices.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  common/usb_storage.c | 51 +--
>  1 file changed, 49 insertions(+), 2 deletions(-)

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

Re: [U-Boot] [PATCH v2 29/80] dm: usb: Move all the EHCI weak functions together and declare them

[Simon Glass]

On 25 March 2015 at 12:22, Simon Glass  wrote:
> Put these at the top of the file so they are in one place. Also add function
> prototypes to the header file to avoid call site mismatches.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  drivers/usb/host/ehci-hcd.c | 22 +++---
>  drivers/usb/host/ehci.h |  6 ++
>  2 files changed, 17 insertions(+), 11 deletions(-)

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

Re: [U-Boot] [PATCH v2 27/80] dm: usb: Move storage device scanning into its own function

[Simon Glass]

On 25 March 2015 at 12:22, Simon Glass  wrote:
> The usb_stor_scan() function is quite long, so split out the code that scans
> each device into its own function. Also, rather than setting up the block
> device list once at the start, set it up as each device is scanned. This
> makes it possible to use this code from driver model.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  common/usb_storage.c | 97 
> 
>  1 file changed, 59 insertions(+), 38 deletions(-)

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

Re: [U-Boot] [PATCH v2 26/80] dm: usb: Adjust usb_storage to work with sandbox

[Simon Glass]

On 25 March 2015 at 12:22, Simon Glass  wrote:
> With a few tweaks we can compile this code with sandbox and enable testing
> of the USB storage layer.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  common/usb_storage.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)

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

Re: [U-Boot] [PATCH v2 30/80] dm: usb: Pass EHCI controller pointer to ehci_get_port_speed()

[Simon Glass]

On 25 March 2015 at 12:22, Simon Glass  wrote:
> Adjust this function so that it is passed an EHCI controller pointer so that
> implementations can look up their controller.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  drivers/usb/host/ehci-faraday.c | 5 +++--
>  drivers/usb/host/ehci-hcd.c | 4 ++--
>  drivers/usb/host/ehci-tegra.c   | 5 +++--
>  drivers/usb/host/ehci.h | 2 +-
>  4 files changed, 9 insertions(+), 7 deletions(-)

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

Re: [U-Boot] [PATCH v2 31/80] dm: usb: Allow ECHI to hold private data for the controller

[Simon Glass]

On 25 March 2015 at 12:22, Simon Glass  wrote:
> Add a private data pointer that clients of EHCI can use to access their
> private information. This establishes a link between struct ehci_ctrl and
> its associated controller data structure.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  drivers/usb/host/ehci-hcd.c | 10 ++
>  drivers/usb/host/ehci.h | 21 +
>  2 files changed, 31 insertions(+)

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

Re: [U-Boot] [PATCH v2 32/80] dm: usb: tegra: Store the controller type explicitly

[Simon Glass]

On 25 March 2015 at 12:22, Simon Glass  wrote:
> At present the tegra driver uses a separate pointer to know which controller
> type is in use. This works because only one controller type is used at a
> time.
>
> With driver model we want to make the controller state hermetic in the sense
> that it is not necessary to look elsewhere to know the controller type. This
> will permit a controller to implement the EHCI weak functions without
> reference to global data structures.
>
> To achieve this, define an enum for the controller type and store it with
> the information on each EHCI controller.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  drivers/usb/host/ehci-tegra.c | 30 --
>  1 file changed, 24 insertions(+), 6 deletions(-)

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

Re: [U-Boot] [PATCH v2 34/80] dm: usb: tegra: Drop use of global controller variable

[Simon Glass]

On 25 March 2015 at 12:22, Simon Glass  wrote:
> We don't need this anymore, so adjust the code to avoid using it.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  drivers/usb/host/ehci-tegra.c | 16 +---
>  1 file changed, 9 insertions(+), 7 deletions(-)

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

Re: [U-Boot] [PATCH v2 33/80] dm: usb: Pass EHCI controller pointer to ehci_powerup_fixup()

[Simon Glass]

On 25 March 2015 at 12:22, Simon Glass  wrote:
> Adjust this function so that it is passed an EHCI controller pointer so that
> implementations can look up their controller.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  board/genesi/mx51_efikamx/efikamx-usb.c | 3 ++-
>  drivers/usb/host/ehci-hcd.c | 5 +++--
>  drivers/usb/host/ehci-tegra.c   | 3 ++-
>  drivers/usb/host/ehci.h | 3 ++-
>  4 files changed, 9 insertions(+), 5 deletions(-)

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

Re: [U-Boot] [PATCH v2 35/80] dm: usb: Pass EHCI controller pointer to ehci_set_usbmode()

[Simon Glass]

On 25 March 2015 at 12:22, Simon Glass  wrote:
> Adjust this function so that it is passed an EHCI controller pointer so that
> implementations can look up their controller. This makes the weak functions
> use a consistent API.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  drivers/usb/host/ehci-faraday.c | 2 +-
>  drivers/usb/host/ehci-hcd.c | 6 +++---
>  drivers/usb/host/ehci-tegra.c   | 5 ++---
>  drivers/usb/host/ehci.h | 2 +-
>  4 files changed, 7 insertions(+), 8 deletions(-)

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

Re: [U-Boot] [PATCH v2 41/80] dm: usb: Add driver model support to EHCI

[Simon Glass]

On 25 March 2015 at 12:22, Simon Glass  wrote:
> Add a way for EHCI controller drivers to support driver model. Drivers can
> call ehci_register() to register themselves in their probe() methods.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  drivers/usb/host/ehci-hcd.c | 125 
> ++--
>  drivers/usb/host/ehci.h |   6 +++
>  2 files changed, 127 insertions(+), 4 deletions(-)

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

Re: [U-Boot] [PATCH v2 39/80] dm: usb: Drop the EHCI weak functions

[Simon Glass]

On 25 March 2015 at 12:22, Simon Glass  wrote:
> These are a pain with driver model because we might have different EHCI
> drivers which want to implement them differently. Now that they use
> consistent function signatures, we can in good conscience move them to
> a struct.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  board/genesi/mx51_efikamx/efikamx-usb.c |   5 +-
>  drivers/usb/host/ehci-faraday.c | 113 
> +++-
>  drivers/usb/host/ehci-hcd.c |  49 +++---
>  drivers/usb/host/ehci-mx5.c |  12 
>  drivers/usb/host/ehci-tegra.c   |  26 
>  drivers/usb/host/ehci.h |  27 +---
>  6 files changed, 136 insertions(+), 96 deletions(-)

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

Re: [U-Boot] [PATCH v2 36/80] dm: usb: Pass EHCI controller pointer to ehci_get_portsc_register()

[Simon Glass]

On 25 March 2015 at 12:22, Simon Glass  wrote:
> Adjust this function so that it is passed an EHCI controller pointer so that
> implementations can look up their controller. This makes the weak functions
> use a consistent API.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  drivers/usb/host/ehci-faraday.c | 4 ++--
>  drivers/usb/host/ehci-hcd.c | 6 +++---
>  drivers/usb/host/ehci.h | 2 +-
>  3 files changed, 6 insertions(+), 6 deletions(-)

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

Re: [U-Boot] [PATCH v2 42/80] dm: usb: Allow USB drivers to be declared and auto-probed

[Simon Glass]

On 25 March 2015 at 12:22, Simon Glass  wrote:
> USB devices in U-Boot are currently probed only after all devices have
> been enumerated. Each type of device is probed by custom code, e.g.:
>
> - USB storage
> - Keyboard
> - Ethernet
>
> With driver model this approach doesn't work very well. We could build
> a picture of the bus and then go back and add the devices later, but
> this means that the data structures are incomplete for quite a while.
> It also does not follow the model of being able to bind a device when we
> discover it.
>
> We would prefer to have devices automatically be bound as the device is
> enumerated. This allows us to attach drivers to particular USB classes
> or product/vendor IDs. This is the method used by Linux.
>
> Add the required #defines from Linux, a way of declaring a USB driver and
> the logic to locate the correct driver given the USB device's descriptors.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  drivers/usb/host/usb-uclass.c | 206 
> +-
>  include/usb.h | 107 ++
>  2 files changed, 311 insertions(+), 2 deletions(-)

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

Re: [U-Boot] [PATCH v2 38/80] dm: usb: Refactor EHCI init

[Simon Glass]

On 25 March 2015 at 12:22, Simon Glass  wrote:
> Move the bulk of the code in usb_lowlevel_init() into a separate function
> which will also be used by driver model. Keep the CONFIG options out of
> this function by providing a tweak flag for Faraday. We need to avoid using
> CONFIG options in driver model code where possible, since it makes it
> impossible to use multiple controllers in that code where they have
> different options.
>
> The CONFIG_EHCI_HCD_INIT_AFTER_RESET option is also kept out of the
> common init function. With driver model the controller will be able to
> perform this extra init itself after registering with the EHCI layer.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  drivers/usb/host/ehci-hcd.c | 117 
> +---
>  drivers/usb/host/ehci.h |   6 +++
>  2 files changed, 72 insertions(+), 51 deletions(-)

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

Re: [U-Boot] [PATCH v2 40/80] dm: usb: Change ehci_reset() to use a pointer

[Simon Glass]

On 25 March 2015 at 12:22, Simon Glass  wrote:
> The index cannot be used with driver model, and isn't needed anyway. Change
> the parameter to a pointer.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  drivers/usb/host/ehci-hcd.c | 17 -
>  1 file changed, 8 insertions(+), 9 deletions(-)

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

Re: [U-Boot] [PATCH v2 44/80] dm: usb: Allow setting up a USB controller as a device/gadget

[Simon Glass]

On 25 March 2015 at 12:22, Simon Glass  wrote:
> Some controllers support OTG (on-the-go) where they can operate as either
> host or device. The gadget layer in U-Boot supports this.
>
> While this layer does not interact with driver model, we can provide a
> function which sets up the controller in the correct way. This way the code
> at least builds (although it likely will not work).
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  drivers/usb/gadget/ci_udc.c   |  4 
>  drivers/usb/host/usb-uclass.c | 24 
>  2 files changed, 28 insertions(+)

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

Re: [U-Boot] [PATCH v2 45/80] dm: usb: Split out the keyboard probe into its own function

[Simon Glass]

On 25 March 2015 at 12:22, Simon Glass  wrote:
> Before adding driver model support, split out code from this over-long
> function.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  common/usb_kbd.c | 89 
> 
>  1 file changed, 51 insertions(+), 38 deletions(-)

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

Re: [U-Boot] [PATCH v2 43/80] dm: usb: Bind generic USB devices when there is no driver

[Simon Glass]

On 25 March 2015 at 12:22, Simon Glass  wrote:
> At present USB devices with no driver model driver cannot be seen in the
> device list, and we fail to set them up correctly. This means they cannot
> be used.
>
> While having real drivers that support driver model for all USB devices
> is the eventual goal, we are not there yet.
>
> As a stop-gap, add a generic USB driver which is bound when we do not have
> a real driver. This allows the device to be set up and shown on the bus.
> It also allows ad-hoc code (such as usb_ether) to find these devices and
> set them up.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  drivers/usb/host/usb-uclass.c | 18 +-
>  include/dm/uclass-id.h|  1 +
>  2 files changed, 18 insertions(+), 1 deletion(-)

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

Re: [U-Boot] [PATCH v2 46/80] dm: usb: Support driver model with USB keyboards

[Simon Glass]

On 25 March 2015 at 12:22, Simon Glass  wrote:
> Allow USB keyboards to work with driver model. The main difference is that
> we can have multiple buses (each with its own device numbering) and each
> bus must be scanned.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  common/usb_kbd.c | 34 +-
>  1 file changed, 33 insertions(+), 1 deletion(-)

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

Re: [U-Boot] [PATCH v2 16/80] dm: usb: Refactor port resets

[Simon Glass]

On 25 March 2015 at 12:22, Simon Glass  wrote:
> Move the port reset code into its own function. Rename usb_hub_reset() to
> indicate that is is now a legacy function.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  common/usb.c | 40 ++--
>  common/usb_hub.c |  4 ++--
>  include/usb.h| 18 +-
>  3 files changed, 45 insertions(+), 17 deletions(-)

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

Re: [U-Boot] [PATCH v2 37/80] dm: usb: ehci: Use a function to find the controller from struct udevice

[Simon Glass]

On 25 March 2015 at 12:22, Simon Glass  wrote:
> With driver model we want to remove the controller pointer in struct udevice
> and use driver model data structures instead. To prepare for this, move
> access to this field to a function which can provide a different
> implementation for driver model.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  drivers/usb/host/ehci-hcd.c | 54 
> +++--
>  1 file changed, 37 insertions(+), 17 deletions(-)

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

Re: [U-Boot] Regarding patch: http://patchwork.ozlabs.org/patch/373593/

[Marek Vasut]

On Tuesday, April 07, 2015 at 04:52:09 PM, Ramneek Mehresh wrote:
> > -Original Message-
> > From: Mehresh Ramneek-B31383
> > Sent: Tuesday, April 07, 2015 8:12 PM
> > To: 'Marek Vasut'
> > Cc: u-boot; s...@denx.de
> > Subject: RE: Regarding patch: http://patchwork.ozlabs.org/patch/373593/
> > 
> > > -Original Message-
> > > From: Marek Vasut [mailto:ma...@denx.de]
> > > Sent: Tuesday, April 07, 2015 7:44 PM
> > > To: Mehresh Ramneek-B31383
> > > Cc: u-boot; s...@denx.de
> > > Subject: Re: Regarding patch:
> > > http://patchwork.ozlabs.org/patch/373593/
> > > 
> > > On Tuesday, April 07, 2015 at 04:05:31 PM, Ramneek Mehresh wrote:
> > > > > -Original Message-
> > > > > From: Marek Vasut [mailto:ma...@denx.de]
> > > > > Sent: Tuesday, April 07, 2015 7:22 PM
> > > > > To: Mehresh Ramneek-B31383
> > > > > Cc: u-boot; s...@denx.de
> > > > > Subject: Re: Regarding patch:
> > > > > http://patchwork.ozlabs.org/patch/373593/
> > > > > 
> > > > > On Tuesday, April 07, 2015 at 08:18:03 AM, Ramneek Mehresh wrote:
> > > > > 
> > > > > [...]
> > > > > 
> > > > > > > Hi,
> > > > > > > 
> > > > > > > Is this similar hardware bug to the one which MX6 PCIe is
> > > > > > > suffering ? On MX6, the bug is that you cannot reset the PCIe
> > > > > > > and PCIe PHY from software, which means that if you start PCIe
> > > > > > > in U-Boot, you cannot reliably use it in Linux. Furthermore,
> > > > > > > if you reset the MX6 via WDT, you cannot start PCIe reliably
> > > > > > > in Linux even if PCIe is not used in U-Boot at all.
> > > > > > > 
> > > > > > > Is this the same type of hardware screwup where the design
> > > > > > > team didn't think reset was necessary?
> > > > > > 
> > > > > > I have raised request for this feature in up-coming socs, and
> > > > > > they have agreed to provide phy shut-down in future revs.
> > > > > > However, this support is not available in current revs for which
> > > > > > the
> > 
> > code is sent.
> > 
> > > > > > What do you suggest we should do for current socs?
> > > > > 
> > > > > Hi,
> > > > > 
> > > > > I don't know, but doesn't leaving the USB running cause trouble to
> > 
> > Linux?
> > 
> > > > > I think you should at least document the reasoning why the USB
> > > > > stop is not implemented for this broken hardware.
> > > > 
> > > > Hi Marek, it's not USB controller stop, it's Phy stop which is not
> > > > supported. Controller stopping is supported.
> > > 
> > > OK, does it pose a problem for Linux ? If not, then please just
> > > document it and let's stick with what there now.
> > 
> > No, it won't create issue in Linux because Linux usb driver resets the
> > controller (which in turn resets the phy). Please suggest what's the best
> > place to document this.
> > Shall I document this inside some u-boot doc file?
> 
> I can document this inside xhci_stop() part of fsl driver. In addition,
> this will also be documented in FSL USB driver documentation.
> Please tell if this is ok.

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

Re: [U-Boot] [PATCH] usb: hub: allow pgood_delay to be specified via env

[Marek Vasut]

On Tuesday, April 07, 2015 at 06:04:36 PM, Tim Harvey wrote:
[...]

> > If there is some kind of error that's actively detected, it may make
> > sense to print some kind of message. However, if the symptoms are that
> > devices simply don't appear on the bus and there's no reason to believe
> > any are actually plugged in, that fells different.
> 
> No error... just failure to detect storage device. I agree such a
> message for people using 'usb start' for some other usb device is not
> cool.
> 
> Let's leave it as-is then if there are no complaints.

Hi,

Is the device recognised on the bus and just not identified OR is the device
not even recognised on the bus ?

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