Re: [U-Boot] [PATCH 1/1] Set VLD04 output to 2.8V in PMIC initialization.

[mind entropy]

On Tue, Jun 27, 2017 at 10:54 PM, Fabio Estevam  wrote:

> Hi Gautam,
>
> On Wed, Jun 21, 2017 at 1:18 PM, Gautam Bhat 
> wrote:
> > This change sets the VLDO4 settings output to 2.8V in PMIC
> > initialization so that the MIPI DSI and MIPI CSI input voltage
> > is 2.8V as per the schematics.
>
> As we do not have MIPI DSI / MIPI CSI support in U-Boot, it is
> preferable to let the kernel configure the regulator.
>
> You can do this is the device tree like this:
>
> diff --git a/arch/arm/boot/dts/imx7d-sdb.dts
> b/arch/arm/boot/dts/imx7d-sdb.dts
> index 54c4540..923aa755 100644
> --- a/arch/arm/boot/dts/imx7d-sdb.dts
> +++ b/arch/arm/boot/dts/imx7d-sdb.dts
> @@ -285,8 +285,8 @@
> };
>
> vgen6_reg: vldo4 {
> -   regulator-min-microvolt = <180>;
> -   regulator-max-microvolt = <330>;
> +   regulator-min-microvolt = <280>;
> +   regulator-max-microvolt = <280>;
> regulator-always-on;
> };
> };
>
> Regards,
>
> Fabio Estevam
>

​Hi Fabio,

The patch for the kernel was supposed to be next. Should I send the kernel
patch to mainline or some place else?

Coming to u-boot, the fact that even if there is no MIPI DSI/MIPI CSI
support the voltage would still be 3.3V in those rails. In my case I do not
attach the display after u-boot boots up. I keep the display attached and
sometimes I leave it in u-boot command line without going over to the
kernel. Since this is a development board this is often the case for many
developers and there may be chances of the display getting damaged.

Thanks,
Gautam.

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

Re: [U-Boot] [PATCH] net: fec_mxc: fix PHY initialization bug with CONFIG_DM_ETH

[Joe Hershberger]

On Tue, Jun 27, 2017 at 8:23 AM, Lothar Waßmann  
wrote:
> When CONFIG_DM_ETH is set, the FEC ethernet controller is reset after
> the PHY has been set up and initialzed. This breaks the communication
> with the PHY and results in an inoperable ethernet interface.
>
> Do the initialization with CONFIG_DM_ETH in the same order as with
> legacy ETH support to fix this.
>
> Signed-off-by: Lothar Waßmann 

Acked-by: Joe Hershberger 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 10/16] usb: xhci: Program 'route string' in the input slot context

[Bin Meng]

Hi Marek,

On Tue, Jun 27, 2017 at 5:31 PM, Marek Vasut  wrote:
> On 06/27/2017 07:23 AM, Stefan Roese wrote:
>> Hi Bin,
>>
>> On 27.06.2017 02:01, Bin Meng wrote:
>>> On Tue, Jun 27, 2017 at 2:07 AM, Marek Vasut  wrote:
 On 06/24/2017 03:57 AM, Bin Meng wrote:
> Hi Marek,
>
> On Sat, Jun 24, 2017 at 2:02 AM, Marek Vasut  wrote:
>> On 06/23/2017 11:54 AM, Bin Meng wrote:
>>> xHCI spec says: the values of the 'route string' field shall be
>>> initialized by the first 'Address Device' command issued to a
>>> device slot, and shall not be modified by any other command.
>>>
>>> So far U-Boot does not program this field, and it does not prevent
>>> SS device directly attached to root port, or HS device behind an HS
>>> hub, from working, due to the fact that 'route string' is used by
>>> the xHC to target SS packets. But in order to enumerate devices
>>> behind an SS hub, this field must be programmed.
>>>
>>> With this commit and along with previous commits, now SS & HS devices
>>> attached to a USB 3.0 hub can be enumerated by U-Boot.
>>>
>>> As usual, this new feature is only available when DM is on.
>>
>> Great, but I really dislike the ifdef pollution, so this needs to be
>> sorted out.
>
> The ifdef was needed due to it calls DM APIs or access DM udevice. I
> have no intention to add a new feature to the non-DM driver.

 But then this creates a massive disparity, it's like we're growing two
 USB stacks.

>>>
>>> Yep, unfortunately. But if we continue adding new features/fixes to
>>> the old non-DM stuff, I am not sure how this can encourage people to
>>> switch to DM.
>>
>> Correct. We definitely don't want to add new features to non-DM
>> drivers / IF, if this is non-trivial.
>
> Fine, but we also don't want to grow two distinct stacks with a boatload
> of ifdefs all over the place. That's a nightmare to maintain.
> I think I mentioned that already, but I'd be far more accepting to this
> solution if we could at least keep the added ifdefs to minimum and
> somehow keep them in one place instead of adding them all over the code.
>

OK, I will see if I can do some additional work to remove the #ifdefs
or limit them in a minimum way, even if that means I have to bring
(part of) this feature to the non-DM driver.

>>> Maybe I can check all boards that use xHCI to see if
>>> they are switched to DM?
>>
>> xHCI is still quite new in U-Boot, so I would expect that all
>> platforms using it, are using DM or at least not far away from using
>> it. Yes, please check all xHCI "users", if they use DM. Then we
>> know if and which users need some "persuasion" to switch over to
>> DM soon. ;)

[snip]

Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 00/12] tegra: nyan-big: Support chainloading and add documentation

[Thomas Hoff]

Thanks a bunch Simon (and everyone else who contributed)!

I followed the instructions and was able to get uboot to boot successfully.
:D

Now I just got to figure out how to get the kernel to boot in HYP mode.

Cheers,

Thomas





On Fri, Jun 9, 2017 at 5:27 AM, Simon Glass  wrote:

> Hi Stephen,
>
> On 7 June 2017 at 09:41, Stephen Warren  wrote:
> > On 06/07/2017 09:32 AM, Tom Warren wrote:
> >>
> >> Simon,
> >>
> >>> From: Simon Glass
> >
> > ...
> >>>
> >>> On 1 June 2017 at 07:52, Matthew Gorski  wrote:
> 
> 
>  On Wed, May 31, 2017 at 2:28 PM, Matthew Gorski
>   wrote:
> >
> > On Mon, May 22, 2017 at 7:17 AM, Simon Glass >
> wrote:
> >>
> >>
> >> Every now and then someone wants to chain-load U-Boot on a
> Chromebook.
> >> The procedure is not very complicated but there are some oddities.
> >>
> >> This series updates a few things with allow U-Boot to start on
> >> nyan-big in this way and adds documentation on how to do it. This
> >> provides a central place where the procedure on different devices
> can
> >> be documented.
> >
> > ...
> >
> > Thank You for this Simon!  Very much appreciated!  I am going to give
> > this a try later tonight and report back my personal results...
> >
> > ...
> >
>  Confirmed! Chain-loading working on my nyan_big.  I appreciate this
>  very much Simon and all who contributed.
> >>>
> >>>
> >>> I'd like to pull in this series. Are there any comments / reviews? If
> >>> affects both
> >>> tegra and rockchip.
> >>
> >> I'm fine with it - I assume you'll pull it in to one of your repos and
> >> post a PR to get it into mainstream U-Boot?
> >> I don't have the HW to test on (my nyan-big has been shelved), but trust
> >> in Matthew's testing, and that Stephen's U-Boot test scripts will catch
> any
> >> problems, so LGTM.
>
> Thanks for looking at this.
>
> >
> >
> > Yes, my testing should catch most issues with any patches, although there
> > are still some coverage holes:
> >
> > 1) I don't test cold boot; U-boot is always loaded over USB RCM which may
> > hide bugs specific to cold booting.
>
> I tested cold bold on Nyan, but I use USB RCM also so don't normally
> test cold boot.
>
> >
> > 2) I only test on a few HW platforms (beaver, dalmore, Jetson TK1,
> > p2371-, Jetson TX1)
>
> That's plenty :-)
>
> >
> > 3) Obviously I don't test the new features introduced by this patch;
> > chain-loading.
>
> It's OK I can rely on others for that so long as the changes are
> acceptable to the normal boot case.
>
> Regards,
> Simon
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PULL] Please pull u-boot-imx

[Tom Rini]

On Tue, Jun 27, 2017 at 09:53:35AM +0200, Stefano Babic wrote:

> Hi Tom,
> 
> this should be my last PR for the release. I checked which fixes should
> go into release and all other patches can wait. I am starting to merge
> pending patches into -next.
> 
> Most of commits are fixes (mx25, pciimx,..). Exception is pico-imx7d: I
> merged since a lot of time, and I convinced I have already sent a
> PR...sorry, for that.
> 
> For all imxers: let me know if I missed aome patches that *must* flow
> into 2017.07. IMHO all of the pending patches can wait and I merge now
> in -next.
> 
> The following changes since commit ccbbada0a59fead35495409d0c2c7bcb22a40278:
> 
>   Merge branch 'master' of git://git.denx.de/u-boot-mmc (2017-05-30
> 14:07:23 -0400)
> 
> are available in the git repository at:
> 
>   git://www.denx.de/git/u-boot-imx.git master
> 
> for you to fetch changes up to 65496a34835cb4c9547bd02dd15b018c333add9d:
> 
>   mx6: soc: Fix typo in temperature unit name (2017-06-27 09:06:09 +0200)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] Please pull u-boot-x86

[Tom Rini]

On Tue, Jun 27, 2017 at 04:34:52PM +0800, Bin Meng wrote:

> Hi Tom,
> 
> The following changes since commit 7df4ff2c2689a6d3c16eb0c3cce098fcac622b0c:
> 
>   Merge branch 'master' of git://git.denx.de/u-boot-rockchip
> (2017-06-23 11:02:21 -0400)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-x86.git
> 
> for you to fetch changes up to da2364cc14a0b34411c4a228ae687a23504afe04:
> 
>   Revert "x86: Convert MMC to driver model" (2017-06-27 16:31:30 +0800)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] Please pull from u-boot-i2c

[Tom Rini]

On Mon, Jun 26, 2017 at 10:34:49AM +0200, Heiko Schocher wrote:

> Hello Tom,
> 
> please pull from u-boot-i2c.git master
> 
> The following changes since commit 7df4ff2c2689a6d3c16eb0c3cce098fcac622b0c:
> 
>   Merge branch 'master' of git://git.denx.de/u-boot-rockchip (2017-06-23 
> 11:02:21 -0400)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-i2c.git master
> 
> for you to fetch changes up to 5e75ea15067ab8118a16f5b5f278ccae87819683:
> 
>   i2c_eeprom: add static to i2c_eeprom_std_ops/probe (2017-06-26 07:12:47 
> +0200)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [GIT PULL] u-boot-uniphier/master

[Tom Rini]

On Sun, Jun 25, 2017 at 07:15:57AM +0900, Masahiro Yamada wrote:

> Hi Tom,
> 
> Please pull some more UniPhier SoC updates:
> 
> - fix sparse warnings
> - sync DT with Linux
> - add new board support (LD11/LD20 global)
> 
> 
> The following changes since commit 431c66a3bad13e13c1d44ef4ec3638f95e72e11d:
> 
>   Merge git://www.denx.de/git/u-boot-marvell (2017-06-23 08:23:14 -0400)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-uniphier.git
> 
> for you to fetch changes up to 7bf378043f653d4edd0dc4a54a0a4c43fa8914c2:
> 
>   arm64: dts: uniphier: add support for LD20 Global board (2017-06-25
> 06:06:09 +0900)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH 1/1] Set VLD04 output to 2.8V in PMIC initialization.

[Fabio Estevam]

Hi Gautam,

On Wed, Jun 21, 2017 at 1:18 PM, Gautam Bhat  wrote:
> This change sets the VLDO4 settings output to 2.8V in PMIC
> initialization so that the MIPI DSI and MIPI CSI input voltage
> is 2.8V as per the schematics.

As we do not have MIPI DSI / MIPI CSI support in U-Boot, it is
preferable to let the kernel configure the regulator.

You can do this is the device tree like this:

diff --git a/arch/arm/boot/dts/imx7d-sdb.dts b/arch/arm/boot/dts/imx7d-sdb.dts
index 54c4540..923aa755 100644
--- a/arch/arm/boot/dts/imx7d-sdb.dts
+++ b/arch/arm/boot/dts/imx7d-sdb.dts
@@ -285,8 +285,8 @@
};

vgen6_reg: vldo4 {
-   regulator-min-microvolt = <180>;
-   regulator-max-microvolt = <330>;
+   regulator-min-microvolt = <280>;
+   regulator-max-microvolt = <280>;
regulator-always-on;
};
};

Regards,

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

Re: [U-Boot] [PATCH 1/1] Set VLD04 output to 2.8V in PMIC initialization.

[Otavio Salvador]

Hello Gautam,

On Wed, Jun 21, 2017 at 1:18 PM, Gautam Bhat  wrote:
> This change sets the VLDO4 settings output to 2.8V in PMIC
> initialization so that the MIPI DSI and MIPI CSI input voltage
> is 2.8V as per the schematics.
>
> Signed-off-by: Gautam Bhat 

Thanks for the patch; Fabio, could you take a look at this?


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

Re: [U-Boot] [RFC PATCH v2 3/3] net: ag7xxx: No longer ignore link status

[Marek Vasut]

On 06/27/2017 05:46 PM, Joe Hershberger wrote:
> On Tue, Jun 27, 2017 at 4:32 AM, Marek Vasut  wrote:
>> On 06/26/2017 09:40 PM, Joe Hershberger wrote:
>>> In the case of the WAN port, pay attention to the link status.
>>> In the case of LAN ports, stop reading the link status since we don't
>>> care.
>>>
>>> Signed-off-by: Joe Hershberger 
>>
>> Well, let's see how that works, ev. I'll have to bisect.
>> btw I hope all this is post-2017.07 material.
> 
> I'm not intending to apply any of these until you sign off it's functionality.

Hm, maybe Wills can help with that ... CCed

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

Re: [U-Boot] [RFC PATCH v2 3/3] net: ag7xxx: No longer ignore link status

[Joe Hershberger]

On Tue, Jun 27, 2017 at 4:32 AM, Marek Vasut  wrote:
> On 06/26/2017 09:40 PM, Joe Hershberger wrote:
>> In the case of the WAN port, pay attention to the link status.
>> In the case of LAN ports, stop reading the link status since we don't
>> care.
>>
>> Signed-off-by: Joe Hershberger 
>
> Well, let's see how that works, ev. I'll have to bisect.
> btw I hope all this is post-2017.07 material.

I'm not intending to apply any of these until you sign off it's functionality.

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

Re: [U-Boot] [PATCH 0/2] powerpc: remove 4xx support

[Stefan Roese]

Hi Heiko,

On 27.06.2017 16:49, Heiko Schocher wrote:

There was for long time no activity in the 4xx area.
We need to go further and convert to Kconfig, but it
turned out, nobody is interested anymore in 4xx,
so remove it.

While at it, found drivers/block/sil680.c is not used anymore,
so remove it here too.

Patch compiles clean on travis


Even though this makes me pretty sad, with all the effort that has been
put into this platform support (the first one next to PPC8xx at that
time btw), I see that no one is actually using this SoC in current
designs any more. And therefore no one wants to spend some time on
maintaining it. So lets remove it to make the way free for a more
clean U-Boot implementation... ;)

Acked-by: Stefan Roese 

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

[U-Boot] Porting issue

[Dan]

I'm trying to port u-boot from the freescale mx6ul_14x14_evk to a custom
board. Right now I'm just trying to setup the same build under the new
target name. I've followed a porting guide document and created a new board
directory, header file, and config file, but I'm getting the following
error when I try to make. Where can I start looking to figure out what's
causing this?


scripts/kconfig/conf  --silentoldconfig Kconfig
  CHK include/config.h
  CFG u-boot.cfg
In file included from include/config.h:6:0,
 from ./include/common.h:21:
include/configs/mx6ul_customboard_v1.h:11:31: fatal error:
asm/arch/imx-regs.h: No such file or directory
compilation terminated.
scripts/Makefile.autoconf:79: recipe for target 'u-boot.cfg' failed
make[1]: *** [u-boot.cfg] Error 1
make: *** No rule to make target 'include/config/auto.conf', needed by
'include/config/uboot.release'.  Stop.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 0/2] powerpc: remove 4xx support

[Michal Simek]

On 27.6.2017 16:49, Heiko Schocher wrote:
> There was for long time no activity in the 4xx area.
> We need to go further and convert to Kconfig, but it
> turned out, nobody is interested anymore in 4xx,
> so remove it.

Acked-by: Michal Simek 
for Xilinx part

Note: Ricardo wanted to have xilinx ppc there but not sure if he wants
to invest his time to do that conversion.

Thanks,
Michal
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v10 0/6] Add Intel Arria 10 SoC FPGA driver

[Dinh Nguyen]

On 06/07/2017 11:33 PM, tien.fong.c...@intel.com wrote:
> From: Tien Fong Chee 
> 
> This is the 10th version of patchset to adds support for Intel Arria 10 SoC 
> FPGA
> driver. This version mainly resolved comments from Marek in [v9].
> This series is working on top of u-boot-socfpga.git - 
> http://git.denx.de/u-boot-socfpga.git
> 
> [v9]: https://www.mail-archive.com/u-boot@lists.denx.de/msg252422.html
> 
> v9 -> v10 changes:
> -
> - Moved astro_mcf5373_defocnfig into patch 3(v10).
> - Keep fpga_manager intact by removing patch 6(v9) and patch 7(v9).
> 
> Patchset history
> 
> [v1]: https://www.mail-archive.com/u-boot@lists.denx.de/msg247788.html
> [v2]: https://www.mail-archive.com/u-boot@lists.denx.de/msg248541.html
> [v3]: https://www.mail-archive.com/u-boot@lists.denx.de/msg249160.html
> [v4]: https://www.mail-archive.com/u-boot@lists.denx.de/msg250149.html
> [v5]: https://www.mail-archive.com/u-boot@lists.denx.de/msg250517.html
> [v6]: https://www.mail-archive.com/u-boot@lists.denx.de/msg250687.html
> [v7]: https://www.mail-archive.com/u-boot@lists.denx.de/msg251213.html
> [v8]: https://www.mail-archive.com/u-boot@lists.denx.de/msg252196.html
> 

For the whole series, besides the few minor-nits, please add

Reviewed-by: Dinh Nguyen 

FYI: please add endorsement signatures that you have received on any
subsequent versions of the patch series. This lets people know that at
least somebody has reviewed you patch so that we don't have to hunt down
previous responses.

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

[U-Boot] [PATCH 0/2] powerpc: remove 4xx support

[Heiko Schocher]

There was for long time no activity in the 4xx area.
We need to go further and convert to Kconfig, but it
turned out, nobody is interested anymore in 4xx,
so remove it.

While at it, found drivers/block/sil680.c is not used anymore,
so remove it here too.

Patch compiles clean on travis


Heiko Schocher (2):
  drivers, block: remove sil680 driver
  powerpc: remove 4xx support

 README |7 -
 arch/powerpc/Kconfig   |6 -
 arch/powerpc/Makefile  |1 -
 arch/powerpc/cpu/ppc4xx/40x_spd_sdram.c|  444 ---
 arch/powerpc/cpu/ppc4xx/44x_spd_ddr.c  | 1224 
 arch/powerpc/cpu/ppc4xx/44x_spd_ddr2.c | 3155 
 arch/powerpc/cpu/ppc4xx/4xx_ibm_ddr2_autocalib.c   | 1227 
 arch/powerpc/cpu/ppc4xx/4xx_pci.c  |  863 --
 arch/powerpc/cpu/ppc4xx/4xx_pcie.c | 1280 
 arch/powerpc/cpu/ppc4xx/4xx_uart.c |  267 --
 arch/powerpc/cpu/ppc4xx/Kconfig|  179 --
 arch/powerpc/cpu/ppc4xx/Makefile   |   49 -
 arch/powerpc/cpu/ppc4xx/bedbug_405.c   |  308 --
 arch/powerpc/cpu/ppc4xx/cache.S|  188 --
 arch/powerpc/cpu/ppc4xx/cmd_chip_config.c  |  131 -
 arch/powerpc/cpu/ppc4xx/cmd_ecctest.c  |  262 --
 arch/powerpc/cpu/ppc4xx/config.mk  |   14 -
 arch/powerpc/cpu/ppc4xx/cpu.c  |  702 -
 arch/powerpc/cpu/ppc4xx/cpu_init.c |  541 
 arch/powerpc/cpu/ppc4xx/dcr.S  |  180 --
 arch/powerpc/cpu/ppc4xx/denali_data_eye.c  |  376 ---
 arch/powerpc/cpu/ppc4xx/denali_spd_ddr2.c  | 1235 
 arch/powerpc/cpu/ppc4xx/ecc.c  |  188 --
 arch/powerpc/cpu/ppc4xx/ecc.h  |   58 -
 arch/powerpc/cpu/ppc4xx/fdt.c  |  157 -
 arch/powerpc/cpu/ppc4xx/gpio.c |  244 --
 arch/powerpc/cpu/ppc4xx/interrupts.c   |  192 --
 arch/powerpc/cpu/ppc4xx/kgdb.S |   60 -
 arch/powerpc/cpu/ppc4xx/miiphy.c   |  343 ---
 arch/powerpc/cpu/ppc4xx/reginfo.c  |  358 ---
 arch/powerpc/cpu/ppc4xx/resetvec.S |   13 -
 arch/powerpc/cpu/ppc4xx/sdram.c|  458 ---
 arch/powerpc/cpu/ppc4xx/sdram.h|   60 -
 arch/powerpc/cpu/ppc4xx/speed.c| 1134 ---
 arch/powerpc/cpu/ppc4xx/spl_boot.c |   61 -
 arch/powerpc/cpu/ppc4xx/start.S| 1952 
 arch/powerpc/cpu/ppc4xx/tlb.c  |  336 ---
 arch/powerpc/cpu/ppc4xx/traps.c|  392 ---
 arch/powerpc/cpu/ppc4xx/u-boot-spl.lds |   61 -
 arch/powerpc/cpu/ppc4xx/u-boot.lds |  136 -
 arch/powerpc/cpu/ppc4xx/uic.c  |  163 -
 arch/powerpc/cpu/ppc4xx/usb.c  |   45 -
 arch/powerpc/cpu/ppc4xx/usb_ohci.c | 1521 --
 arch/powerpc/cpu/ppc4xx/usb_ohci.h |  405 ---
 arch/powerpc/cpu/ppc4xx/xilinx_irq.c   |   88 -
 arch/powerpc/dts/.gitignore|1 -
 arch/powerpc/dts/Makefile  |   17 -
 arch/powerpc/dts/arches.dts|  339 ---
 arch/powerpc/dts/canyonlands.dts   |  561 
 arch/powerpc/dts/glacier.dts   |  582 
 arch/powerpc/dts/xilinx-ppc405-generic.dts |   15 -
 arch/powerpc/dts/xilinx-ppc440-generic.dts |   15 -
 arch/powerpc/include/asm/4xx_pci.h |   62 -
 arch/powerpc/include/asm/4xx_pcie.h|  406 ---
 arch/powerpc/include/asm/config.h  |3 +-
 arch/powerpc/include/asm/global_data.h |3 -
 arch/powerpc/include/asm/interrupt.h   |   11 -
 arch/powerpc/include/asm/mmu.h |  209 --
 arch/powerpc/include/asm/ppc.h |6 +-
 arch/powerpc/include/asm/ppc405.h  |   57 -
 arch/powerpc/include/asm/ppc405ep.h|  239 --
 arch/powerpc/include/asm/ppc405ex.h|   82 -
 arch/powerpc/include/asm/ppc405ez.h|   89 -
 arch/powerpc/include/asm/ppc405gp.h|   95 -
 arch/powerpc/include/asm/ppc440.h  |  154 -
 arch/powerpc/include/asm/ppc440ep_gr.h |  231 --
 arch/powerpc/include/asm/ppc440epx_grx.h   |  453 ---
 arch/powerpc/include/asm/ppc440gp.h|   59 -
 arch/powerpc/include/asm/ppc440gx.h|   89 -
 arch/powerpc/include/asm/ppc440sp.h|   85 -
 arch/powerpc/include/asm/ppc440spe.h   |  101 -
 arch/powerpc/include/asm/ppc460ex_gt.h |  211 --
 arch/powerpc/include/asm/ppc460sx.h|   31 -
 

[U-Boot] wrong location of CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT in cpu-dt.c for armv8

[Chevalier, Bruno (EXT - BE/Antwerp)]

Hi,

We are doing some quick prototyping and noticing some issues.
Look at the latest changeset ( 
http://git.denx.de/?p=u-boot.git;a=commit;h=026f30ec3e846edb85b5df8265d8cad098184be6
 ) that changed arch/arm/cpu/armv8/cpu-dt.c 

We can find the diff here:
http://git.denx.de/?p=u-boot.git;a=blobdiff;f=arch/arm/cpu/armv8/cpu-dt.c;h=e3c8aa2e6131b9af7d51333152bb119ba837a3a4;hp=5156a15d110cbc2b10d65f7e3acd0bf2928b813c;hb=026f30ec3e846edb85b5df8265d8cad098184be6;hpb=d14428c729fb620da73234f5a8862066454de44c

For some reason
#ifdef CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT

Was moved to the line before the start of the definition of psci_update_dt(void 
*fdt).
Our prototyping board uses PSCI, but we currently do not make use of 
CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT.

From the changeset's commit message:
PSCI can be used on both multiple and single core socs. Current
implementation only allows PSCI to work on multiple core socs.
This patch removes this restriction so that PSCI can work on
single core socs as well.

Can somebody explain to me why the function definition of psci_update_dt is 
removed when CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT is not defined?

According to me, the only thing that should have been removed (based on the 
commit message) is #ifdef CONFIG_MP .


Kind regards,
Bruno Chevalier

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

[U-Boot] I found 'board/samsung/smdk2410' was removed after 2017.01 version, does it mean u-boot no longer support smdk2410?

[????]

I found the directory 'board/samsung/smdk2410' was removed after 2017.01 
version, does it mean u-boot no longer support smdk2410?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 1/2] drivers, block: remove sil680 driver

[Heiko Schocher]

driver is not used anymore, so remove it.

Signed-off-by: Heiko Schocher 
---

 drivers/block/Makefile   |  1 -
 drivers/block/sil680.c   | 89 
 scripts/config_whitelist.txt |  1 -
 3 files changed, 91 deletions(-)
 delete mode 100644 drivers/block/sil680.c

diff --git a/drivers/block/Makefile b/drivers/block/Makefile
index 0645096..adea6c6 100644
--- a/drivers/block/Makefile
+++ b/drivers/block/Makefile
@@ -27,7 +27,6 @@ obj-$(CONFIG_SATA_DWC) += sata_dwc.o
 obj-$(CONFIG_SATA_MV) += sata_mv.o
 obj-$(CONFIG_SATA_SIL3114) += sata_sil3114.o
 obj-$(CONFIG_SATA_SIL) += sata_sil.o
-obj-$(CONFIG_IDE_SIL680) += sil680.o
 obj-$(CONFIG_SANDBOX) += sandbox.o sandbox_scsi.o sata_sandbox.o
 obj-$(CONFIG_SCSI_SYM53C8XX) += sym53c8xx.o
 obj-$(CONFIG_SYSTEMACE) += systemace.o
diff --git a/drivers/block/sil680.c b/drivers/block/sil680.c
deleted file mode 100644
index bca3397..000
--- a/drivers/block/sil680.c
+++ /dev/null
@@ -1,89 +0,0 @@
-/*
- * (C) Copyright 2007
- * Gary Jennejohn, DENX Software Engineering, ga...@denx.de.
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-/* sil680.c - ide support functions for the Sil0680A controller */
-
-/*
- * The following parameters must be defined in the configuration file
- * of the target board:
- *
- * #define CONFIG_IDE_SIL680
- *
- * #define CONFIG_PCI_PNP
- * NOTE it may also be necessary to define this if the default of 8 is
- * incorrect for the target board (e.g. the sequoia board requires 0).
- * #define CONFIG_SYS_PCI_CACHE_LINE_SIZE  0
- *
- * #define CONFIG_IDE
- * #undef  CONFIG_IDE_LED
- * #undef  CONFIG_IDE_RESET
- * #define CONFIG_IDE_PREINIT
- * #define CONFIG_SYS_IDE_MAXBUS   2 - modify to suit
- * #define CONFIG_SYS_IDE_MAXDEVICE(CONFIG_SYS_IDE_MAXBUS*2) - modify to 
suit
- * #define CONFIG_SYS_ATA_BASE_ADDR0
- * #define CONFIG_SYS_ATA_IDE0_OFFSET  0
- * #define CONFIG_SYS_ATA_IDE1_OFFSET  0
- * #define CONFIG_SYS_ATA_DATA_OFFSET  0
- * #define CONFIG_SYS_ATA_REG_OFFSET   0
- * #define CONFIG_SYS_ATA_ALT_OFFSET   0x0004
- *
- * The mapping for PCI IO-space.
- * NOTE this is the value for the sequoia board. Modify to suit.
- * #define CONFIG_SYS_PCI0_IO_SPACE   0xE800
- */
-
-#include 
-#include 
-#include 
-#include 
-
-extern ulong ide_bus_offset[CONFIG_SYS_IDE_MAXBUS];
-
-int ide_preinit (void)
-{
-   int status;
-   pci_dev_t devbusfn;
-   int l;
-
-   status = 1;
-   for (l = 0; l < CONFIG_SYS_IDE_MAXBUS; l++) {
-   ide_bus_offset[l] = -ATA_STATUS;
-   }
-   devbusfn = pci_find_device (0x1095, 0x0680, 0);
-   if (devbusfn != -1) {
-   status = 0;
-
-   pci_read_config_dword (devbusfn, PCI_BASE_ADDRESS_0,
-  (u32 *) _bus_offset[0]);
-   ide_bus_offset[0] &= 0xfff8;
-   ide_bus_offset[0] += CONFIG_SYS_PCI0_IO_SPACE;
-   pci_read_config_dword (devbusfn, PCI_BASE_ADDRESS_2,
-  (u32 *) _bus_offset[1]);
-   ide_bus_offset[1] &= 0xfff8;
-   ide_bus_offset[1] += CONFIG_SYS_PCI0_IO_SPACE;
-   /* init various things - taken from the Linux driver */
-   /* set PIO mode */
-   pci_write_config_byte(devbusfn, 0x80, 0x00);
-   pci_write_config_byte(devbusfn, 0x84, 0x00);
-   /* IDE0 */
-   pci_write_config_byte(devbusfn,  0xA1, 0x02);
-   pci_write_config_word(devbusfn,  0xA2, 0x328A);
-   pci_write_config_dword(devbusfn, 0xA4, 0x62DD62DD);
-   pci_write_config_dword(devbusfn, 0xA8, 0x43924392);
-   pci_write_config_dword(devbusfn, 0xAC, 0x40094009);
-   /* IDE1 */
-   pci_write_config_byte(devbusfn,  0xB1, 0x02);
-   pci_write_config_word(devbusfn,  0xB2, 0x328A);
-   pci_write_config_dword(devbusfn, 0xB4, 0x62DD62DD);
-   pci_write_config_dword(devbusfn, 0xB8, 0x43924392);
-   pci_write_config_dword(devbusfn, 0xBC, 0x40094009);
-   }
-   return (status);
-}
-
-void ide_set_reset (int flag) {
-   return;
-}
diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
index feb430f..c1f1293 100644
--- a/scripts/config_whitelist.txt
+++ b/scripts/config_whitelist.txt
@@ -1233,7 +1233,6 @@ CONFIG_IDE_PREINIT
 CONFIG_IDE_REG_CS
 CONFIG_IDE_RESET
 CONFIG_IDE_RESET_ROUTINE
-CONFIG_IDE_SIL680
 CONFIG_IDE_SWAP_IO
 CONFIG_IDS8313
 CONFIG_IDT8T49N222A
-- 
2.7.4

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

Re: [U-Boot] [PATCH] doc: restore doc/README.fsl-clk

[Heiko Schocher]

Hello Christophe,

Am 27.06.2017 um 16:00 schrieb Christophe Leroy:

doc/README.fsl-clk was removed in commit
5b8e76c35ec31 ("powerpc, 8xx: remove support for 8xx")
allthought CONFIG_SYS_FSL_CLK is defined in
arch/arm/cpu/armv8/fsl-layerscape/Kconfig and still in use
in the following configs:

./include/configs/mx53loco.h:21:#define CONFIG_SYS_FSL_CLK
./include/configs/m53evk.h:16:#define CONFIG_SYS_FSL_CLK
./include/configs/mx25pdk.h:17:#define CONFIG_SYS_FSL_CLK
./include/configs/usbarmory.h:14:#define CONFIG_SYS_FSL_CLK
./include/configs/ls1021aqds.h:14:#define CONFIG_SYS_FSL_CLK
./include/configs/mx53cx9020.h:22:#define CONFIG_SYS_FSL_CLK
./include/configs/colibri_vf.h:17:#define CONFIG_SYS_FSL_CLK
./include/configs/mx35pdk.h:21:#define CONFIG_SYS_FSL_CLK
./include/configs/woodburn_common.h:19:#define CONFIG_SYS_FSL_CLK
./include/configs/mx7_common.h:25:#define CONFIG_SYS_FSL_CLK
./include/configs/ls1021aiot.h:12:#define CONFIG_SYS_FSL_CLK
./include/configs/ls1021atwr.h:14:#define CONFIG_SYS_FSL_CLK
./include/configs/mx53ard.h:21:#define CONFIG_SYS_FSL_CLK
./include/configs/mx53smd.h:21:#define CONFIG_SYS_FSL_CLK
./include/configs/mx51evk.h:16:#define CONFIG_SYS_FSL_CLK
./include/configs/mx6_common.h:31:#define CONFIG_SYS_FSL_CLK
./include/configs/vf610twr.h:14:#define CONFIG_SYS_FSL_CLK
./include/configs/mx53evk.h:21:#define CONFIG_SYS_FSL_CLK

Signed-off-by: Christophe Leroy 
---
  doc/README.fsl-clk | 5 +
  1 file changed, 5 insertions(+)
  create mode 100644 doc/README.fsl-clk


Good catch! Thanks!

Reviewed-by: Heiko Schocher 

bye,
Heiko


diff --git a/doc/README.fsl-clk b/doc/README.fsl-clk
new file mode 100644
index 00..3a9927f079
--- /dev/null
+++ b/doc/README.fsl-clk
@@ -0,0 +1,5 @@
+Freescale system clock options
+
+   - CONFIG_SYS_FSL_CLK
+   Enable to call get_clocks() in board_init_f() for
+   non-PPC platforms.



--
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
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v10 3/6] arm: socfpga: Convert FPGA and FPGA_ALTERA configuration to Kconfig

[Dinh Nguyen]

On 06/07/2017 11:33 PM, tien.fong.c...@intel.com wrote:
> From: Tien Fong Chee 
> 
> This converts the following to Kconfig:
>CONFIG_FPGA
>CONFIG_FPGA_ALTERA
> 
> Signed-off-by: Tien Fong Chee 
> ---
>  configs/astro_mcf5373l_defconfig| 1 +
>  configs/theadorable_debug_defconfig | 1 +
>  configs/theadorable_defconfig   | 1 +
>  include/configs/astro_mcf5373l.h| 2 --
>  include/configs/theadorable.h   | 2 --
>  5 files changed, 3 insertions(+), 4 deletions(-)
> 

The commit header of this patch is wrong. This patch has nothing to do
with "arm: socfpga"

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

[U-Boot] [PATCH] doc: restore doc/README.fsl-clk

[Christophe Leroy]

doc/README.fsl-clk was removed in commit
5b8e76c35ec31 ("powerpc, 8xx: remove support for 8xx")
allthought CONFIG_SYS_FSL_CLK is defined in
arch/arm/cpu/armv8/fsl-layerscape/Kconfig and still in use
in the following configs:

./include/configs/mx53loco.h:21:#define CONFIG_SYS_FSL_CLK
./include/configs/m53evk.h:16:#define CONFIG_SYS_FSL_CLK
./include/configs/mx25pdk.h:17:#define CONFIG_SYS_FSL_CLK
./include/configs/usbarmory.h:14:#define CONFIG_SYS_FSL_CLK
./include/configs/ls1021aqds.h:14:#define CONFIG_SYS_FSL_CLK
./include/configs/mx53cx9020.h:22:#define CONFIG_SYS_FSL_CLK
./include/configs/colibri_vf.h:17:#define CONFIG_SYS_FSL_CLK
./include/configs/mx35pdk.h:21:#define CONFIG_SYS_FSL_CLK
./include/configs/woodburn_common.h:19:#define CONFIG_SYS_FSL_CLK
./include/configs/mx7_common.h:25:#define CONFIG_SYS_FSL_CLK
./include/configs/ls1021aiot.h:12:#define CONFIG_SYS_FSL_CLK
./include/configs/ls1021atwr.h:14:#define CONFIG_SYS_FSL_CLK
./include/configs/mx53ard.h:21:#define CONFIG_SYS_FSL_CLK
./include/configs/mx53smd.h:21:#define CONFIG_SYS_FSL_CLK
./include/configs/mx51evk.h:16:#define CONFIG_SYS_FSL_CLK
./include/configs/mx6_common.h:31:#define CONFIG_SYS_FSL_CLK
./include/configs/vf610twr.h:14:#define CONFIG_SYS_FSL_CLK
./include/configs/mx53evk.h:21:#define CONFIG_SYS_FSL_CLK

Signed-off-by: Christophe Leroy 
---
 doc/README.fsl-clk | 5 +
 1 file changed, 5 insertions(+)
 create mode 100644 doc/README.fsl-clk

diff --git a/doc/README.fsl-clk b/doc/README.fsl-clk
new file mode 100644
index 00..3a9927f079
--- /dev/null
+++ b/doc/README.fsl-clk
@@ -0,0 +1,5 @@
+Freescale system clock options
+
+   - CONFIG_SYS_FSL_CLK
+   Enable to call get_clocks() in board_init_f() for
+   non-PPC platforms.
-- 
2.12.0

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

[U-Boot] [PATCH] net: fec_mxc: fix PHY initialization bug with CONFIG_DM_ETH

[Lothar Waßmann]

When CONFIG_DM_ETH is set, the FEC ethernet controller is reset after
the PHY has been set up and initialzed. This breaks the communication
with the PHY and results in an inoperable ethernet interface.

Do the initialization with CONFIG_DM_ETH in the same order as with
legacy ETH support to fix this.

Signed-off-by: Lothar Waßmann 
---
 drivers/net/fec_mxc.c | 24 +---
 1 file changed, 13 insertions(+), 11 deletions(-)

diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
index 910879b..f61268c 100644
--- a/drivers/net/fec_mxc.c
+++ b/drivers/net/fec_mxc.c
@@ -1216,17 +1216,6 @@ static int fecmxc_probe(struct udevice *dev)
if (ret)
return ret;
 
-   bus = fec_get_miibus((uint32_t)priv->eth, dev_id);
-   if (!bus)
-   goto err_mii;
-
-   priv->bus = bus;
-   priv->xcv_type = CONFIG_FEC_XCV_TYPE;
-   priv->interface = pdata->phy_interface;
-   ret = fec_phy_init(priv, dev);
-   if (ret)
-   goto err_phy;
-
/* Reset chip. */
writel(readl(>eth->ecntrl) | FEC_ECNTRL_RESET,
   >eth->ecntrl);
@@ -1242,6 +1231,19 @@ static int fecmxc_probe(struct udevice *dev)
fec_reg_setup(priv);
priv->dev_id = (dev_id == -1) ? 0 : dev_id;
 
+   bus = fec_get_miibus(dev, dev_id);
+   if (!bus) {
+   ret = -ENOMEM;
+   goto err_mii;
+   }
+
+   priv->bus = bus;
+   priv->xcv_type = CONFIG_FEC_XCV_TYPE;
+   priv->interface = pdata->phy_interface;
+   ret = fec_phy_init(priv, dev);
+   if (ret)
+   goto err_phy;
+
return 0;
 
 err_timeout:
-- 
2.1.4

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

Re: [U-Boot] question regarding the odroidc2 board support

[Lukasz Majewski]

On Tue, 27 Jun 2017 13:58:46 +0200
daggs  wrote:

> Greetings Lukasz 
> 
> > Sent: Tuesday, June 27, 2017 at 10:57 AM
> > From: "Lukasz Majewski" 
> > To: daggs 
> > Cc: u-boot@lists.denx.de
> > Subject: Re: [U-Boot] question regarding the odroidc2 board support
> >
> > On Thu, 22 Jun 2017 19:55:21 +0200
> > daggs  wrote:
> > 
> > > Greetings,
> > > 
> > > I'm using buildroot to generate images for the odroid c2 boards
> > > and from what I see, it uses u-boot.bin to burn into the image.
> > > I'm not seeing any other uboot product that is used for booting
> > > (unless I'm mistaken). I'm reading the odroid c2 readme file and
> > > I see it instructs the use to burn a alternative u-boot.bin from
> > > the one that was created by the env. I wonder how it is possible
> > > to actually use newer uboot when in the end uboot recommends to
> > > replace u-boot.bin with pre existing one?
> > 
> > From the spec I do see that C2 has SD card and eMMC.
> > 
> > I can only share my experience with Odroid XU3/U3.
> > 
> > The boot process would (probably) require some signed blobs from
> > hardkernel (those binaries are corresponding to u-boot-spl.bin).
> > 
> > I can recommend looking to Hardkernel forum (they should have some
> > topics dedicated for this SoM), or look for tizen.org wiki:
> > 
> > https://wiki.tizen.org/Quick_guide_for_odroidxu3
> > 
> > I hope, that the boot flow is similar for XU3 and C2.
> > 
> > > 
> > > Thanks,
> > > 
> > > Dagg.
> > > ___
> > > U-Boot mailing list
> > > U-Boot@lists.denx.de
> > > https://lists.denx.de/listinfo/u-boot
> > 
> > 
> > 
> > 
> > Best regards,
> > 
> > Lukasz Majewski
> > 
> > --
> > 
> > DENX Software Engineering GmbH,  Managing Director: Wolfgang
> > Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell,
> > Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email:
> > w...@denx.de
> > 
> 
> indeed that is correct, the c2 has a singed binary.
> as said in my mail, I'm using buildroot to create my images, at the
> end buildroot takes the file u-boot.bin and burn it into the image at
> a specific location. the c2 readme explains how to extract the signed
> blob but I'd expect that it will overwrite part of the u-boot.bin
> file and no replace it. so I assume I'm missing a part. e.g.
> u-boot.bin isn't the only file needed from u-boot. am I correct?

I can only speak by having some experience with Odroid XU3.

XU3 had bl1.bin.hardkernel, which was signed (and this corresponds to
u-boot's SPL binary).

This bl1 called "normal" u-boot (u-boot.bin).

And afterwards u-boot was calling uImage + DTB.

There was also problem with the eMMC layout - you had to jump somewhere
else since the default "partition" for u-boot (512 KiB) was too small.

Also please pay a note if you need any TZW (trust zone) firmware for
your platform.

Have you found any info on hardkerne's wiki/forum?

> 
> Thanks.
> 
> Dagg.




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] arch: armv8: Remove the error when dcache is off

[Alexander Graf]

> Am 27.06.2017 um 13:52 schrieb Michal Simek :
> 
>> On 27.6.2017 13:46, Alexander Graf wrote:
>> 
>> 
>>> On 27.06.17 13:20, Michal Simek wrote:
>>> Hi,
>>> 
 On 27.6.2017 13:01, Alexander Graf wrote:
 I don't think that's going to work - at least not without compiler flag
 changes. By default, gcc will happily generate unaligned accesses. If
 you disable dcache, these will trap.
>>> 
>>> What's that compiler flags we should be using to avoid that?
>> 
>> It's a combination of
>> 
>>  -mstrict-align
>> 
>> plus crossing fingers with lots of praying plus making sure that every
>> code you call also follows -mstrict-align plus double-checking that you
>> don't break the kernel booting ABI:
>> 
>> 
>> http://elixir.free-electrons.com/linux/v4.12-rc7/source/Documentation/arm64/booting.txt
>> 
>> 
>> In the booti case, disabling dcache seems to be legitimate. In the
>> bootefi case however, it's not.
> 
> Non wants to boot the kernel. It is really about programming stuff.
> 
>> 
>> So you will also need to set CONFIG_EFI_LOADER to depend on
>> !CONFIG_SYS_DCACHE_OFF which means you will want to convert
>> CONFIG_SYS_DCACHE_OFF to Kconfig first :).
> 
> ok. I will let Siva to do it just wanted to refresh this topic.
> 
> 
>>> The reason for this change is to have really small u-boot which fits to
>>> OCM without DDR to be able to do initial programming.
>> 
>> Yup, makes sense. I'm just slightly scared by the idea :).
> 
> The same stuff we did on Zynq in past.
> I have never had enough time to look at that MMU mapping why it is so
> huge. Maybe reduce size of that tables or using different page size is
> better way to go.

If you configure your section boundaries on natural alignments (1GB IIRC), you 
should get away with quite few tables.

Alex


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

Re: [U-Boot] question regarding the odroidc2 board support

[daggs]

Greetings Lukasz 

> Sent: Tuesday, June 27, 2017 at 10:57 AM
> From: "Lukasz Majewski" 
> To: daggs 
> Cc: u-boot@lists.denx.de
> Subject: Re: [U-Boot] question regarding the odroidc2 board support
>
> On Thu, 22 Jun 2017 19:55:21 +0200
> daggs  wrote:
> 
> > Greetings,
> > 
> > I'm using buildroot to generate images for the odroid c2 boards and
> > from what I see, it uses u-boot.bin to burn into the image. I'm not
> > seeing any other uboot product that is used for booting (unless I'm
> > mistaken). I'm reading the odroid c2 readme file and I see it
> > instructs the use to burn a alternative u-boot.bin from the one that
> > was created by the env. I wonder how it is possible to actually use
> > newer uboot when in the end uboot recommends to replace u-boot.bin
> > with pre existing one?
> 
> From the spec I do see that C2 has SD card and eMMC.
> 
> I can only share my experience with Odroid XU3/U3.
> 
> The boot process would (probably) require some signed blobs from
> hardkernel (those binaries are corresponding to u-boot-spl.bin).
> 
> I can recommend looking to Hardkernel forum (they should have some
> topics dedicated for this SoM), or look for tizen.org wiki:
> 
> https://wiki.tizen.org/Quick_guide_for_odroidxu3
> 
> I hope, that the boot flow is similar for XU3 and C2.
> 
> > 
> > Thanks,
> > 
> > Dagg.
> > ___
> > U-Boot mailing list
> > U-Boot@lists.denx.de
> > https://lists.denx.de/listinfo/u-boot
> 
> 
> 
> 
> Best regards,
> 
> Lukasz Majewski
> 
> --
> 
> DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
> 

indeed that is correct, the c2 has a singed binary.
as said in my mail, I'm using buildroot to create my images, at the end 
buildroot takes the file u-boot.bin and burn it into the image at a specific 
location.
the c2 readme explains how to extract the signed blob but I'd expect that it 
will overwrite part of the u-boot.bin file and no replace it.
so I assume I'm missing a part. e.g. u-boot.bin isn't the only file needed from 
u-boot. am I correct?

Thanks.

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

Re: [U-Boot] [PATCH] arch: armv8: Remove the error when dcache is off

[Michal Simek]

On 27.6.2017 13:46, Alexander Graf wrote:
> 
> 
> On 27.06.17 13:20, Michal Simek wrote:
>> Hi,
>>
>> On 27.6.2017 13:01, Alexander Graf wrote:
>>> I don't think that's going to work - at least not without compiler flag
>>> changes. By default, gcc will happily generate unaligned accesses. If
>>> you disable dcache, these will trap.
>>
>> What's that compiler flags we should be using to avoid that?
> 
> It's a combination of
> 
>   -mstrict-align
> 
> plus crossing fingers with lots of praying plus making sure that every
> code you call also follows -mstrict-align plus double-checking that you
> don't break the kernel booting ABI:
> 
> 
> http://elixir.free-electrons.com/linux/v4.12-rc7/source/Documentation/arm64/booting.txt
> 
> 
> In the booti case, disabling dcache seems to be legitimate. In the
> bootefi case however, it's not.

Non wants to boot the kernel. It is really about programming stuff.

> 
> So you will also need to set CONFIG_EFI_LOADER to depend on
> !CONFIG_SYS_DCACHE_OFF which means you will want to convert
> CONFIG_SYS_DCACHE_OFF to Kconfig first :).

ok. I will let Siva to do it just wanted to refresh this topic.


>> The reason for this change is to have really small u-boot which fits to
>> OCM without DDR to be able to do initial programming.
> 
> Yup, makes sense. I'm just slightly scared by the idea :).

The same stuff we did on Zynq in past.
I have never had enough time to look at that MMU mapping why it is so
huge. Maybe reduce size of that tables or using different page size is
better way to go.

Thanks,
Michal


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

Re: [U-Boot] [PATCH] arch: armv8: Remove the error when dcache is off

[Alexander Graf]

On 27.06.17 13:20, Michal Simek wrote:

Hi,

On 27.6.2017 13:01, Alexander Graf wrote:

I don't think that's going to work - at least not without compiler flag
changes. By default, gcc will happily generate unaligned accesses. If
you disable dcache, these will trap.


What's that compiler flags we should be using to avoid that?


It's a combination of

  -mstrict-align

plus crossing fingers with lots of praying plus making sure that every 
code you call also follows -mstrict-align plus double-checking that you 
don't break the kernel booting ABI:



http://elixir.free-electrons.com/linux/v4.12-rc7/source/Documentation/arm64/booting.txt

In the booti case, disabling dcache seems to be legitimate. In the 
bootefi case however, it's not.


So you will also need to set CONFIG_EFI_LOADER to depend on 
!CONFIG_SYS_DCACHE_OFF which means you will want to convert 
CONFIG_SYS_DCACHE_OFF to Kconfig first :).



The reason for this change is to have really small u-boot which fits to
OCM without DDR to be able to do initial programming.


Yup, makes sense. I'm just slightly scared by the idea :).


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

Re: [U-Boot] [PATCH] arch: armv8: Remove the error when dcache is off

[Michal Simek]

Hi,

On 27.6.2017 13:01, Alexander Graf wrote:
> I don't think that's going to work - at least not without compiler flag
> changes. By default, gcc will happily generate unaligned accesses. If
> you disable dcache, these will trap.

What's that compiler flags we should be using to avoid that?

The reason for this change is to have really small u-boot which fits to
OCM without DDR to be able to do initial programming.

Thanks,
Michal
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] arch: armv8: Remove the error when dcache is off

[Alexander Graf]

I don't think that's going to work - at least not without compiler flag 
changes. By default, gcc will happily generate unaligned accesses. If 
you disable dcache, these will trap.


Alex

On 27.06.17 11:04, Michal Simek wrote:

Hi guys,

do you have any concern about this change?

Thanks,
Michal

On 22.6.2017 12:00, Siva Durga Prasad Paladugu wrote:

Remove the error which causes compilation failure when
dcache is off for builds otherthan SPL. There may be
cases where user wants to disable dcache completely
eventhough it is not SPL.

Signed-off-by: Siva Durga Prasad Paladugu 
---
  arch/arm/cpu/armv8/cache_v8.c | 9 -
  1 file changed, 9 deletions(-)

diff --git a/arch/arm/cpu/armv8/cache_v8.c b/arch/arm/cpu/armv8/cache_v8.c
index adc7e17..d11efcc 100644
--- a/arch/arm/cpu/armv8/cache_v8.c
+++ b/arch/arm/cpu/armv8/cache_v8.c
@@ -647,15 +647,6 @@ void mmu_change_region_attr(phys_addr_t addr, size_t siz, 
u64 attrs)
  
  #else	/* CONFIG_SYS_DCACHE_OFF */
  
-/*

- * For SPL builds, we may want to not have dcache enabled. Any real U-Boot
- * running however really wants to have dcache and the MMU active. Check that
- * everything is sane and give the developer a hint if it isn't.
- */
-#ifndef CONFIG_SPL_BUILD
-#error Please describe your MMU layout in CONFIG_SYS_MEM_MAP and enable dcache.
-#endif
-
  void invalidate_dcache_all(void)
  {
  }




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

Re: [U-Boot] [RFC PATCH v2 1/3] net: ag7xxx: Comment register names

[Marek Vasut]

On 06/26/2017 09:40 PM, Joe Hershberger wrote:
> The register constants don't use the exact names that are used in the
> TRM, so add comments that use the exact names so that it is clear what
> register is being referred to.
> 
> https://www.atheros-drivers.com/qualcomm-atheros-datasheets-for-AR9331.html
> 
> Signed-off-by: Joe Hershberger 

Acked-by: Marek Vasut 

> ---
> 
> Changes in v2:
> - New - Comments split into a separate change
> 
>  drivers/net/ag7xxx.c | 16 
>  1 file changed, 16 insertions(+)
> 
> diff --git a/drivers/net/ag7xxx.c b/drivers/net/ag7xxx.c
> index cf60d11..30771b9 100644
> --- a/drivers/net/ag7xxx.c
> +++ b/drivers/net/ag7xxx.c
> @@ -26,6 +26,7 @@ enum ag7xxx_model {
>   AG7XXX_MODEL_AG934X,
>  };
>  
> +/* MAC Configuration 1 */
>  #define AG7XXX_ETH_CFG1  0x00
>  #define AG7XXX_ETH_CFG1_SOFT_RST BIT(31)
>  #define AG7XXX_ETH_CFG1_RX_RST   BIT(19)
> @@ -34,6 +35,7 @@ enum ag7xxx_model {
>  #define AG7XXX_ETH_CFG1_RX_ENBIT(2)
>  #define AG7XXX_ETH_CFG1_TX_ENBIT(0)
>  
> +/* MAC Configuration 2 */
>  #define AG7XXX_ETH_CFG2  0x04
>  #define AG7XXX_ETH_CFG2_IF_1000  BIT(9)
>  #define AG7XXX_ETH_CFG2_IF_10_100BIT(8)
> @@ -43,26 +45,34 @@ enum ag7xxx_model {
>  #define AG7XXX_ETH_CFG2_PAD_CRC_EN   BIT(2)
>  #define AG7XXX_ETH_CFG2_FDX  BIT(0)
>  
> +/* MII Configuration */
>  #define AG7XXX_ETH_MII_MGMT_CFG  0x20
>  #define AG7XXX_ETH_MII_MGMT_CFG_RESETBIT(31)
>  
> +/* MII Command */
>  #define AG7XXX_ETH_MII_MGMT_CMD  0x24
>  #define AG7XXX_ETH_MII_MGMT_CMD_READ 0x1
>  
> +/* MII Address */
>  #define AG7XXX_ETH_MII_MGMT_ADDRESS  0x28
>  #define AG7XXX_ETH_MII_MGMT_ADDRESS_SHIFT8
>  
> +/* MII Control */
>  #define AG7XXX_ETH_MII_MGMT_CTRL 0x2c
>  
> +/* MII Status */
>  #define AG7XXX_ETH_MII_MGMT_STATUS   0x30
>  
> +/* MII Indicators */
>  #define AG7XXX_ETH_MII_MGMT_IND  0x34
>  #define AG7XXX_ETH_MII_MGMT_IND_INVALID  BIT(2)
>  #define AG7XXX_ETH_MII_MGMT_IND_BUSY BIT(0)
>  
> +/* STA Address 1 & 2 */
>  #define AG7XXX_ETH_ADDR1 0x40
>  #define AG7XXX_ETH_ADDR2 0x44
>  
> +/* ETH Configuration 0 - 5 */
>  #define AG7XXX_ETH_FIFO_CFG_00x48
>  #define AG7XXX_ETH_FIFO_CFG_10x4c
>  #define AG7XXX_ETH_FIFO_CFG_20x50
> @@ -70,18 +80,24 @@ enum ag7xxx_model {
>  #define AG7XXX_ETH_FIFO_CFG_40x58
>  #define AG7XXX_ETH_FIFO_CFG_50x5c
>  
> +/* DMA Transfer Control for Queue 0 */
>  #define AG7XXX_ETH_DMA_TX_CTRL   0x180
>  #define AG7XXX_ETH_DMA_TX_CTRL_TXE   BIT(0)
>  
> +/* Descriptor Address for Queue 0 Tx */
>  #define AG7XXX_ETH_DMA_TX_DESC   0x184
>  
> +/* DMA Tx Status */
>  #define AG7XXX_ETH_DMA_TX_STATUS 0x188
>  
> +/* Rx Control */
>  #define AG7XXX_ETH_DMA_RX_CTRL   0x18c
>  #define AG7XXX_ETH_DMA_RX_CTRL_RXE   BIT(0)
>  
> +/* Pointer to Rx Descriptor */
>  #define AG7XXX_ETH_DMA_RX_DESC   0x190
>  
> +/* Rx Status */
>  #define AG7XXX_ETH_DMA_RX_STATUS 0x194
>  
>  /* Custom register at 0x1807 */
> 


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

Re: [U-Boot] [RFC PATCH v2 3/3] net: ag7xxx: No longer ignore link status

[Marek Vasut]

On 06/26/2017 09:40 PM, Joe Hershberger wrote:
> In the case of the WAN port, pay attention to the link status.
> In the case of LAN ports, stop reading the link status since we don't
> care.
> 
> Signed-off-by: Joe Hershberger 

Well, let's see how that works, ev. I'll have to bisect.
btw I hope all this is post-2017.07 material.

> ---
> This is a pass at improving the code quality.
> This has not been tested in any way.
> 
> Changes in v2:
> - New - Split link status change into its own patch (so it can be dropped if 
> it affects behavior)
> 
>  drivers/net/ag7xxx.c | 18 ++
>  1 file changed, 10 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/net/ag7xxx.c b/drivers/net/ag7xxx.c
> index 00e6806..c8352d1 100644
> --- a/drivers/net/ag7xxx.c
> +++ b/drivers/net/ag7xxx.c
> @@ -100,6 +100,12 @@ enum ag7xxx_model {
>  /* Rx Status */
>  #define AG7XXX_ETH_DMA_RX_STATUS 0x194
>  
> +/* PHY Control Registers */
> +
> +/* PHY Specific Status Register */
> +#define AG7XXX_PHY_PSSR  0x11
> +#define AG7XXX_PHY_PSSR_LINK_UP  BIT(10)
> +
>  /* Custom register at 0x1807 */
>  #define AG7XXX_GMAC_ETH_CFG  0x00
>  #define AG7XXX_ETH_CFG_SW_PHY_ADDR_SWAP  BIT(8)
> @@ -758,10 +764,13 @@ static int ag933x_phy_setup_common(struct udevice *dev)
>   return ret;
>  
>   /* Read out link status */
> - ret = ag7xxx_mdio_read(priv->bus, phymax, 0, MII_MIPSCR);
> + ret = ag7xxx_mdio_read(priv->bus, phymax, 0, AG7XXX_PHY_PSSR);
>   if (ret < 0)
>   return ret;
>  
> + if (!(ret & AG7XXX_PHY_PSSR_LINK_UP))
> + return -ENOLINK;
> +
>   return 0;
>   }
>  
> @@ -778,13 +787,6 @@ static int ag933x_phy_setup_common(struct udevice *dev)
>   return ret;
>   }
>  
> - for (i = 0; i < phymax; i++) {
> - /* Read out link status */
> - ret = ag7xxx_mdio_read(priv->bus, i, 0, MII_MIPSCR);
> - if (ret < 0)
> - return ret;
> - }
> -
>   return 0;
>  }
>  
> 


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

Re: [U-Boot] [RFC PATCH v2 2/3] net: ag7xxx: Propagate errors on phy access

[Marek Vasut]

On 06/26/2017 09:40 PM, Joe Hershberger wrote:
> Don't wait forever.
> Pass errors back to the caller.
> 
> Signed-off-by: Joe Hershberger 

Acked-by: Marek Vasut 

> ---
> 
> Changes in v2:
> - Isolate error propagation changes
> 
>  drivers/net/ag7xxx.c | 29 -
>  1 file changed, 24 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/net/ag7xxx.c b/drivers/net/ag7xxx.c
> index 30771b9..00e6806 100644
> --- a/drivers/net/ag7xxx.c
> +++ b/drivers/net/ag7xxx.c
> @@ -285,18 +285,33 @@ static int ag7xxx_switch_reg_write(struct mii_dev *bus, 
> int reg, u32 val)
>   return 0;
>  }
>  
> -static u16 ag7xxx_mdio_rw(struct mii_dev *bus, int addr, int reg, u32 val)
> +static int ag7xxx_mdio_rw(struct mii_dev *bus, int addr, int reg, u32 val)
>  {
>   u32 data;
> + unsigned long start;
> + int ret;
> + /* No idea if this is long enough or too long */
> + int timeout_ms = 1000;
>  
>   /* Dummy read followed by PHY read/write command. */
> - ag7xxx_switch_reg_read(bus, 0x98, );
> + ret = ag7xxx_switch_reg_read(bus, 0x98, );
> + if (ret < 0)
> + return ret;
>   data = val | (reg << 16) | (addr << 21) | BIT(30) | BIT(31);
> - ag7xxx_switch_reg_write(bus, 0x98, data);
> + ret = ag7xxx_switch_reg_write(bus, 0x98, data);
> + if (ret < 0)
> + return ret;
> +
> + start = get_timer(0);
>  
>   /* Wait for operation to finish */
>   do {
> - ag7xxx_switch_reg_read(bus, 0x98, );
> + ret = ag7xxx_switch_reg_read(bus, 0x98, );
> + if (ret < 0)
> + return ret;
> +
> + if (get_timer(start) > timeout_ms)
> + return -ETIMEDOUT;
>   } while (data & BIT(31));
>  
>   return data & 0x;
> @@ -310,7 +325,11 @@ static int ag7xxx_mdio_read(struct mii_dev *bus, int 
> addr, int devad, int reg)
>  static int ag7xxx_mdio_write(struct mii_dev *bus, int addr, int devad, int 
> reg,
>u16 val)
>  {
> - ag7xxx_mdio_rw(bus, addr, reg, val);
> + int ret;
> +
> + ret = ag7xxx_mdio_rw(bus, addr, reg, val);
> + if (ret < 0)
> + return ret;
>   return 0;
>  }
>  
> 


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

Re: [U-Boot] [PATCH 10/16] usb: xhci: Program 'route string' in the input slot context

[Marek Vasut]

On 06/27/2017 07:23 AM, Stefan Roese wrote:
> Hi Bin,
> 
> On 27.06.2017 02:01, Bin Meng wrote:
>> On Tue, Jun 27, 2017 at 2:07 AM, Marek Vasut  wrote:
>>> On 06/24/2017 03:57 AM, Bin Meng wrote:
 Hi Marek,

 On Sat, Jun 24, 2017 at 2:02 AM, Marek Vasut  wrote:
> On 06/23/2017 11:54 AM, Bin Meng wrote:
>> xHCI spec says: the values of the 'route string' field shall be
>> initialized by the first 'Address Device' command issued to a
>> device slot, and shall not be modified by any other command.
>>
>> So far U-Boot does not program this field, and it does not prevent
>> SS device directly attached to root port, or HS device behind an HS
>> hub, from working, due to the fact that 'route string' is used by
>> the xHC to target SS packets. But in order to enumerate devices
>> behind an SS hub, this field must be programmed.
>>
>> With this commit and along with previous commits, now SS & HS devices
>> attached to a USB 3.0 hub can be enumerated by U-Boot.
>>
>> As usual, this new feature is only available when DM is on.
>
> Great, but I really dislike the ifdef pollution, so this needs to be
> sorted out.

 The ifdef was needed due to it calls DM APIs or access DM udevice. I
 have no intention to add a new feature to the non-DM driver.
>>>
>>> But then this creates a massive disparity, it's like we're growing two
>>> USB stacks.
>>>
>>
>> Yep, unfortunately. But if we continue adding new features/fixes to
>> the old non-DM stuff, I am not sure how this can encourage people to
>> switch to DM.
> 
> Correct. We definitely don't want to add new features to non-DM
> drivers / IF, if this is non-trivial.

Fine, but we also don't want to grow two distinct stacks with a boatload
of ifdefs all over the place. That's a nightmare to maintain.
I think I mentioned that already, but I'd be far more accepting to this
solution if we could at least keep the added ifdefs to minimum and
somehow keep them in one place instead of adding them all over the code.

>> Maybe I can check all boards that use xHCI to see if
>> they are switched to DM?
> 
> xHCI is still quite new in U-Boot, so I would expect that all
> platforms using it, are using DM or at least not far away from using
> it. Yes, please check all xHCI "users", if they use DM. Then we
> know if and which users need some "persuasion" to switch over to
> DM soon. ;)
> 
> Thanks,
> Stefan


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

Re: [U-Boot] [PATCH v2 06/13] drivers: usb: dwc3: add ti dwc3 peripheral driver with driver model support

[Lukasz Majewski]

On Tue, 27 Jun 2017 14:38:38 +0530
Vignesh R  wrote:

> 
> 
> On Thursday 22 June 2017 06:30 PM, Lukasz Majewski wrote:
> > On Thu, 22 Jun 2017 17:42:38 +0530
> > Vignesh R  wrote:
> > 
> >>
> >>
> >> On Wednesday 21 June 2017 01:39 PM, Lukasz Majewski wrote:
> >>> Hi Vignesh,
> >>>
>  Hi,
> 
>  On Tuesday 20 June 2017 07:14 PM, Lukasz Majewski wrote:
> > Hi Marek, Vignesh,
>  [...]
> >>>
> >>> All gadget drivers like ether.c or f_mass_storage.c call
> >>> usb_gadget_handle_interrupts() just passing the index of the
> >>> USB instance. This does not help at all in dm case. What we
> >>> would need is usb_gadget_handle_interrupts() to provide at
> >>> least the usb_gadget instance as parameter from which we
> >>> could derive controller specific structure using
> >>> container_of(). And then, we could call the SoC specific isr
> >>> callback. This would require modifying all gadget driver like
> >>> ether.c to call a different function instead of
> >>> usb_gadget_handle_interrupts() when DM_USB is used.
> >>
> >> This is something to consult with Lukasz then.
> >
> > And it seems that we are heading to adding "gadget"
> > infrastructure to DM.
> >
> 
>  Yes, U-Boot is moving to DM for good and this has cascading
>  effect. I was actually trying to enable DM_ETH on some TI
>  platforms which forced me to move USB_ETH to DM as well and
>  therefore seems like USB gadget framework needs tweaks to adapt
>  to DM...
> >>>
> >>> I've sketched following plan for gadget conversion:
> >>>
> >>> 1. Each u-boot command (dfu, ums, thor and in the future rockchip
> >>> I hope), which uses gadget goes through
> >>> g_dnl_{register|unregister}, so the idea is to add this driver
> >>> first to DM.
> >>>
> >>> 2. Afterwards, we could add functions as children of g_dnl.
> >>>
> >>> This would be easily modeled in Kconfig (to have g_dnl - gadget -
> >>> menu with submenu to chose the USB function - e.g. f_dfu*).
> >>>
> >>
> >> Wondering, if there is case where more than one functions may be
> >> used like f_dfu and f_mass_storage? 
> > 
> > The "composite" layer was supposed to provide that.
> > 
> >> Like a single defconfig may want to
> >> have both f_dfu and f_mass_storage enabled?
> > 
> > When we developed the g_dnl/f_* code we wanted to have support for
> > many functions.
> > 
> > However, finally, we only implemented the single function since
> > u-boot is a single thread SW (and we had some problems with
> > DFU/ODIN endpoints assignment, IIRC).
> > 
> > Theoretically it should be possible to have many functions enabled.
> > 
> 
> Ok.
> 
> >>
> >>> However, we also need to take care of several UDC (USB device
> >>> controller) drivers including also the "composite" usb layer.
> >>>
> >>> This would be tougher to do since there are many udc drivers - but
> >>> it should be possible to separate DM's UDC drivers and
> >>> g_dnl/function code. 
> >>>
> >>> Another problem is that some archs use gadgets (RNDIS?) without
> >>> g_dnl and composite - on top of UDC driver (like musb).
> >>>
> >>
> >> Yes, rndis does not use g_dnl. Both MUSB and DWC3 gadget seem to
> >> use UDC w/o g_dnl/composite. I guess, we will have to either
> >> support RNDIS directly with UDC or convert MUSB/DWC3 gadget
> >> interface as well as convert ether.c to g_dnl function.
> > 
> > I would opt for latter option (f_rndis*).
> > 
> 
> I agree...
> 
> >>
> >>> For example:
> >>>
> >>> board/ti/beagle/beagle.c -> board_eth_init()
> >>>   |
> >>>  \|/
> >>> drivers/usb/gadget/ether.c -> usb_eth_initialize()
> >>> [ether.c seems to partially support DM]
> >>>   |
> >>>  \|/
> >>> (also in the ether.c)
> >>>   _usb_eth_init() in which we loop on
> >>>   usb_gadget_handle_interrupts()
> >>>
> >>>
> >>> From what I see, the ether.c now supports DM and legacy code, so
> >>> some work has been already done for DM
> >>>
> >>
> >> Yeah, I think this was done as part of making MUSB DM conversion.
> >> RNDIS boot is one the boot mode for many TI platforms and is used
> >> quite often. 
> > 
> > Ok.
> > 
> >> Legacy code is what is largely in use, am335x has been
> >> recently moved to use DM based RNDIS(although I feel its not
> >> complete and working yet). I guess once UDC is moved DM, we can
> >> see how ether.c can be integrated with it.
> > 
> > And other UDCs should be moved as well (like dwc[23]).
> > 
> 
> yes, all UDCs needs to moved..
> BTW, what platform would you be starting these migration on?
> 
> 

I do have two available:

- Beagle Bone Blach

- Odroid XU3


Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
___

Re: [U-Boot] [PATCH v6 3/3] GPT: provide commands to selectively rename partitions

[Lothar Waßmann]

Hi,

On Tue, 27 Jun 2017 09:05:14 +0200 Lothar Waßmann wrote:
> Hi,
> 
> On Sun, 25 Jun 2017 14:54:56 -0700 Alison Chaiken wrote:
> > On Sun, Jun 18, 2017 at 4:03 AM, Wolfgang Denk  wrote:
> > 
> > > Dear Alison,
> > >
> > > In message 

Re: [U-Boot] [PATCH v2 06/13] drivers: usb: dwc3: add ti dwc3 peripheral driver with driver model support

[Vignesh R]

On Thursday 22 June 2017 06:30 PM, Lukasz Majewski wrote:
> On Thu, 22 Jun 2017 17:42:38 +0530
> Vignesh R  wrote:
> 
>>
>>
>> On Wednesday 21 June 2017 01:39 PM, Lukasz Majewski wrote:
>>> Hi Vignesh,
>>>
 Hi,

 On Tuesday 20 June 2017 07:14 PM, Lukasz Majewski wrote:
> Hi Marek, Vignesh,
 [...]
>>>
>>> All gadget drivers like ether.c or f_mass_storage.c call
>>> usb_gadget_handle_interrupts() just passing the index of the USB
>>> instance. This does not help at all in dm case. What we would
>>> need is usb_gadget_handle_interrupts() to provide at least the
>>> usb_gadget instance as parameter from which we could derive
>>> controller specific structure using container_of(). And then, we
>>> could call the SoC specific isr callback.
>>> This would require modifying all gadget driver like ether.c to
>>> call a different function instead of
>>> usb_gadget_handle_interrupts() when DM_USB is used.
>>
>> This is something to consult with Lukasz then.
>
> And it seems that we are heading to adding "gadget" infrastructure
> to DM.
>

 Yes, U-Boot is moving to DM for good and this has cascading effect.
 I was actually trying to enable DM_ETH on some TI platforms which
 forced me to move USB_ETH to DM as well and therefore seems like
 USB gadget framework needs tweaks to adapt to DM...
>>>
>>> I've sketched following plan for gadget conversion:
>>>
>>> 1. Each u-boot command (dfu, ums, thor and in the future rockchip I
>>> hope), which uses gadget goes through g_dnl_{register|unregister},
>>> so the idea is to add this driver first to DM.
>>>
>>> 2. Afterwards, we could add functions as children of g_dnl.
>>>
>>> This would be easily modeled in Kconfig (to have g_dnl - gadget -
>>> menu with submenu to chose the USB function - e.g. f_dfu*).
>>>
>>
>> Wondering, if there is case where more than one functions may be used
>> like f_dfu and f_mass_storage? 
> 
> The "composite" layer was supposed to provide that.
> 
>> Like a single defconfig may want to
>> have both f_dfu and f_mass_storage enabled?
> 
> When we developed the g_dnl/f_* code we wanted to have support for many
> functions.
> 
> However, finally, we only implemented the single function since u-boot
> is a single thread SW (and we had some problems with DFU/ODIN endpoints
> assignment, IIRC).
> 
> Theoretically it should be possible to have many functions enabled.
> 

Ok.

>>
>>> However, we also need to take care of several UDC (USB device
>>> controller) drivers including also the "composite" usb layer.
>>>
>>> This would be tougher to do since there are many udc drivers - but
>>> it should be possible to separate DM's UDC drivers and
>>> g_dnl/function code. 
>>>
>>> Another problem is that some archs use gadgets (RNDIS?) without
>>> g_dnl and composite - on top of UDC driver (like musb).
>>>
>>
>> Yes, rndis does not use g_dnl. Both MUSB and DWC3 gadget seem to use
>> UDC w/o g_dnl/composite. I guess, we will have to either support RNDIS
>> directly with UDC or convert MUSB/DWC3 gadget interface as well as
>> convert ether.c to g_dnl function.
> 
> I would opt for latter option (f_rndis*).
> 

I agree...

>>
>>> For example:
>>>
>>> board/ti/beagle/beagle.c -> board_eth_init()
>>> |
>>>\|/
>>> drivers/usb/gadget/ether.c -> usb_eth_initialize()
>>> [ether.c seems to partially support DM]
>>> |
>>>\|/
>>> (also in the ether.c)
>>> _usb_eth_init() in which we loop on
>>> usb_gadget_handle_interrupts()
>>>
>>>
>>> From what I see, the ether.c now supports DM and legacy code, so
>>> some work has been already done for DM
>>>
>>
>> Yeah, I think this was done as part of making MUSB DM conversion.
>> RNDIS boot is one the boot mode for many TI platforms and is used
>> quite often. 
> 
> Ok.
> 
>> Legacy code is what is largely in use, am335x has been
>> recently moved to use DM based RNDIS(although I feel its not complete
>> and working yet). I guess once UDC is moved DM, we can see how
>> ether.c can be integrated with it.
> 
> And other UDCs should be moved as well (like dwc[23]).
> 

yes, all UDCs needs to moved..
BTW, what platform would you be starting these migration on?


-- 
Regards
Vignesh
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] arch: armv8: Remove the error when dcache is off

[Michal Simek]

Hi guys,

do you have any concern about this change?

Thanks,
Michal

On 22.6.2017 12:00, Siva Durga Prasad Paladugu wrote:
> Remove the error which causes compilation failure when
> dcache is off for builds otherthan SPL. There may be
> cases where user wants to disable dcache completely
> eventhough it is not SPL.
> 
> Signed-off-by: Siva Durga Prasad Paladugu 
> ---
>  arch/arm/cpu/armv8/cache_v8.c | 9 -
>  1 file changed, 9 deletions(-)
> 
> diff --git a/arch/arm/cpu/armv8/cache_v8.c b/arch/arm/cpu/armv8/cache_v8.c
> index adc7e17..d11efcc 100644
> --- a/arch/arm/cpu/armv8/cache_v8.c
> +++ b/arch/arm/cpu/armv8/cache_v8.c
> @@ -647,15 +647,6 @@ void mmu_change_region_attr(phys_addr_t addr, size_t 
> siz, u64 attrs)
>  
>  #else/* CONFIG_SYS_DCACHE_OFF */
>  
> -/*
> - * For SPL builds, we may want to not have dcache enabled. Any real U-Boot
> - * running however really wants to have dcache and the MMU active. Check that
> - * everything is sane and give the developer a hint if it isn't.
> - */
> -#ifndef CONFIG_SPL_BUILD
> -#error Please describe your MMU layout in CONFIG_SYS_MEM_MAP and enable 
> dcache.
> -#endif
> -
>  void invalidate_dcache_all(void)
>  {
>  }
> 

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

Re: [U-Boot] [PATCH 10/16] usb: xhci: Program 'route string' in the input slot context

[Marek Vasut]

On 06/27/2017 10:27 AM, Bin Meng wrote:
> Hi Stefan,
> 
> On Tue, Jun 27, 2017 at 1:23 PM, Stefan Roese  wrote:
>> Hi Bin,
>>
>>
>> On 27.06.2017 02:01, Bin Meng wrote:
>>>
>>> On Tue, Jun 27, 2017 at 2:07 AM, Marek Vasut  wrote:

 On 06/24/2017 03:57 AM, Bin Meng wrote:
>
> Hi Marek,
>
> On Sat, Jun 24, 2017 at 2:02 AM, Marek Vasut  wrote:
>>
>> On 06/23/2017 11:54 AM, Bin Meng wrote:
>>>
>>> xHCI spec says: the values of the 'route string' field shall be
>>> initialized by the first 'Address Device' command issued to a
>>> device slot, and shall not be modified by any other command.
>>>
>>> So far U-Boot does not program this field, and it does not prevent
>>> SS device directly attached to root port, or HS device behind an HS
>>> hub, from working, due to the fact that 'route string' is used by
>>> the xHC to target SS packets. But in order to enumerate devices
>>> behind an SS hub, this field must be programmed.
>>>
>>> With this commit and along with previous commits, now SS & HS devices
>>> attached to a USB 3.0 hub can be enumerated by U-Boot.
>>>
>>> As usual, this new feature is only available when DM is on.
>>
>>
>> Great, but I really dislike the ifdef pollution, so this needs to be
>> sorted out.
>
>
> The ifdef was needed due to it calls DM APIs or access DM udevice. I
> have no intention to add a new feature to the non-DM driver.


 But then this creates a massive disparity, it's like we're growing two
 USB stacks.

>>>
>>> Yep, unfortunately. But if we continue adding new features/fixes to
>>> the old non-DM stuff, I am not sure how this can encourage people to
>>> switch to DM.
>>
>>
>> Correct. We definitely don't want to add new features to non-DM
>> drivers / IF, if this is non-trivial.
>>
>>> Maybe I can check all boards that use xHCI to see if
>>> they are switched to DM?
>>
>>
>> xHCI is still quite new in U-Boot, so I would expect that all
>> platforms using it, are using DM or at least not far away from using
>> it. Yes, please check all xHCI "users", if they use DM. Then we
>> know if and which users need some "persuasion" to switch over to
>> DM soon. ;)
> 
> I checked all boards that have CONFIG_USB_XHCI_HCD defined but without
> CONFIG_DM_USB. Here is the list.
> 
> configs/uniphier_v8_defconfig:36:CONFIG_USB_XHCI_HCD=y
> configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig:62:CONFIG_USB_XHCI_HCD=y
> configs/am57xx_evm_nodt_defconfig:53:CONFIG_USB_XHCI_HCD=y
> configs/evb-rk3328_defconfig:34:CONFIG_USB_XHCI_HCD=y
> configs/ls1021atwr_nor_lpuart_defconfig:43:CONFIG_USB_XHCI_HCD=y
> configs/uniphier_pxs2_ld6b_defconfig:44:CONFIG_USB_XHCI_HCD=y
> configs/ls1012ardb_qspi_SECURE_BOOT_defconfig:43:CONFIG_USB_XHCI_HCD=y
> configs/ls1021atwr_sdcard_ifc_SECURE_BOOT_defconfig:57:CONFIG_USB_XHCI_HCD=y
> configs/k2e_hs_evm_defconfig:34:CONFIG_USB_XHCI_HCD=y
> configs/ls1021aqds_sdcard_qspi_defconfig:61:CONFIG_USB_XHCI_HCD=y
> configs/am43xx_evm_ethboot_defconfig:48:CONFIG_USB_XHCI_HCD=y
> configs/xilinx_zynqmp_ep_defconfig:70:CONFIG_USB_XHCI_HCD=y
> configs/ls1021aqds_nand_defconfig:57:CONFIG_USB_XHCI_HCD=y
> configs/ls1021atwr_qspi_defconfig:50:CONFIG_USB_XHCI_HCD=y
> configs/k2g_evm_defconfig:45:CONFIG_USB_XHCI_HCD=y
> configs/am57xx_evm_defconfig:63:CONFIG_USB_XHCI_HCD=y
> configs/am43xx_hs_evm_defconfig:49:CONFIG_USB_XHCI_HCD=y
> configs/am43xx_evm_defconfig:39:CONFIG_USB_XHCI_HCD=y
> configs/ls1021atwr_nor_defconfig:42:CONFIG_USB_XHCI_HCD=y
> configs/firefly-rk3399_defconfig:59:CONFIG_USB_XHCI_HCD=y
> configs/puma-rk3399_defconfig:78:CONFIG_USB_XHCI_HCD=y
> configs/cl-som-am57x_defconfig:55:CONFIG_USB_XHCI_HCD=y
> configs/ls1021aqds_nor_SECURE_BOOT_defconfig:43:CONFIG_USB_XHCI_HCD=y
> configs/uniphier_pro4_defconfig:43:CONFIG_USB_XHCI_HCD=y
> configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig:61:CONFIG_USB_XHCI_HCD=y
> configs/xilinx_zynqmp_zcu102_defconfig:63:CONFIG_USB_XHCI_HCD=y
> configs/ls1021atwr_nor_SECURE_BOOT_defconfig:42:CONFIG_USB_XHCI_HCD=y
> configs/cm_t43_defconfig:67:CONFIG_USB_XHCI_HCD=y
> configs/k2g_hs_evm_defconfig:36:CONFIG_USB_XHCI_HCD=y
> configs/am43xx_evm_qspiboot_defconfig:45:CONFIG_USB_XHCI_HCD=y
> configs/ls1021aqds_qspi_defconfig:50:CONFIG_USB_XHCI_HCD=y
> configs/am57xx_hs_evm_defconfig:67:CONFIG_USB_XHCI_HCD=y
> configs/xilinx_zynqmp_zcu102_revB_defconfig:63:CONFIG_USB_XHCI_HCD=y
> configs/ls1021aqds_sdcard_ifc_defconfig:55:CONFIG_USB_XHCI_HCD=y
> configs/uniphier_ld20_defconfig:39:CONFIG_USB_XHCI_HCD=y
> configs/am43xx_evm_usbhost_boot_defconfig:61:CONFIG_USB_XHCI_HCD=y
> configs/ls1021atwr_sdcard_qspi_defconfig:61:CONFIG_USB_XHCI_HCD=y
> configs/evb-rk3399_defconfig:60:CONFIG_USB_XHCI_HCD=y
> configs/k2hk_evm_defconfig:43:CONFIG_USB_XHCI_HCD=y
> configs/k2hk_hs_evm_defconfig:34:CONFIG_USB_XHCI_HCD=y
> configs/k2e_evm_defconfig:43:CONFIG_USB_XHCI_HCD=y
> 

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

[Bin Meng]

Hi Tom,

The following changes since commit 7df4ff2c2689a6d3c16eb0c3cce098fcac622b0c:

  Merge branch 'master' of git://git.denx.de/u-boot-rockchip
(2017-06-23 11:02:21 -0400)

are available in the git repository at:

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

for you to fetch changes up to da2364cc14a0b34411c4a228ae687a23504afe04:

  Revert "x86: Convert MMC to driver model" (2017-06-27 16:31:30 +0800)


Bin Meng (1):
  Revert "x86: Convert MMC to driver model"

 arch/Kconfig   |  1 -
 arch/x86/cpu/baytrail/valleyview.c | 12 
 arch/x86/cpu/quark/quark.c | 10 ++
 arch/x86/cpu/queensbay/Makefile|  2 +-
 arch/x86/cpu/queensbay/topcliff.c  | 20 
 drivers/mmc/pci_mmc.c  | 86
++
 include/mmc.h  | 12 
 7 files changed, 81 insertions(+), 62 deletions(-)
 create mode 100644 arch/x86/cpu/queensbay/topcliff.c

Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] Revert "x86: Convert MMC to driver model"

[Bin Meng]

On Tue, Jun 27, 2017 at 11:25 AM, Simon Glass  wrote:
> On 26 June 2017 at 17:36, Bin Meng  wrote:
>> This reverts commit ddb3ac3c716f56cead695444e65a7ba7b0946555.
>>
>> With MMC converted to driver model, SCSI driver is broken due to
>> zero address access at (ops->read) in block_dread() function.
>>
>> The fix (SCSI driver converted to DM) is ready in u-boot-dm branch,
>> but it is too late for this relese to get that in.
>>
>> Signed-off-by: Bin Meng 
>> ---
>>
>> arch/Kconfig | 1 -
>> arch/x86/cpu/baytrail/valleyview.c | 12 ++
>> arch/x86/cpu/quark/quark.c | 10 +
>> arch/x86/cpu/queensbay/Makefile | 2 +-
>> arch/x86/cpu/queensbay/topcliff.c | 20 +
>> drivers/mmc/pci_mmc.c | 86 --
>> include/mmc.h | 12 ++
>> 7 files changed, 81 insertions(+), 62 deletions(-)
>> create mode 100644 arch/x86/cpu/queensbay/topcliff.c
>
> Reviewed-by: Simon Glass 

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 10/16] usb: xhci: Program 'route string' in the input slot context

[Bin Meng]

Hi Stefan,

On Tue, Jun 27, 2017 at 1:23 PM, Stefan Roese  wrote:
> Hi Bin,
>
>
> On 27.06.2017 02:01, Bin Meng wrote:
>>
>> On Tue, Jun 27, 2017 at 2:07 AM, Marek Vasut  wrote:
>>>
>>> On 06/24/2017 03:57 AM, Bin Meng wrote:

 Hi Marek,

 On Sat, Jun 24, 2017 at 2:02 AM, Marek Vasut  wrote:
>
> On 06/23/2017 11:54 AM, Bin Meng wrote:
>>
>> xHCI spec says: the values of the 'route string' field shall be
>> initialized by the first 'Address Device' command issued to a
>> device slot, and shall not be modified by any other command.
>>
>> So far U-Boot does not program this field, and it does not prevent
>> SS device directly attached to root port, or HS device behind an HS
>> hub, from working, due to the fact that 'route string' is used by
>> the xHC to target SS packets. But in order to enumerate devices
>> behind an SS hub, this field must be programmed.
>>
>> With this commit and along with previous commits, now SS & HS devices
>> attached to a USB 3.0 hub can be enumerated by U-Boot.
>>
>> As usual, this new feature is only available when DM is on.
>
>
> Great, but I really dislike the ifdef pollution, so this needs to be
> sorted out.


 The ifdef was needed due to it calls DM APIs or access DM udevice. I
 have no intention to add a new feature to the non-DM driver.
>>>
>>>
>>> But then this creates a massive disparity, it's like we're growing two
>>> USB stacks.
>>>
>>
>> Yep, unfortunately. But if we continue adding new features/fixes to
>> the old non-DM stuff, I am not sure how this can encourage people to
>> switch to DM.
>
>
> Correct. We definitely don't want to add new features to non-DM
> drivers / IF, if this is non-trivial.
>
>> Maybe I can check all boards that use xHCI to see if
>> they are switched to DM?
>
>
> xHCI is still quite new in U-Boot, so I would expect that all
> platforms using it, are using DM or at least not far away from using
> it. Yes, please check all xHCI "users", if they use DM. Then we
> know if and which users need some "persuasion" to switch over to
> DM soon. ;)

I checked all boards that have CONFIG_USB_XHCI_HCD defined but without
CONFIG_DM_USB. Here is the list.

configs/uniphier_v8_defconfig:36:CONFIG_USB_XHCI_HCD=y
configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig:62:CONFIG_USB_XHCI_HCD=y
configs/am57xx_evm_nodt_defconfig:53:CONFIG_USB_XHCI_HCD=y
configs/evb-rk3328_defconfig:34:CONFIG_USB_XHCI_HCD=y
configs/ls1021atwr_nor_lpuart_defconfig:43:CONFIG_USB_XHCI_HCD=y
configs/uniphier_pxs2_ld6b_defconfig:44:CONFIG_USB_XHCI_HCD=y
configs/ls1012ardb_qspi_SECURE_BOOT_defconfig:43:CONFIG_USB_XHCI_HCD=y
configs/ls1021atwr_sdcard_ifc_SECURE_BOOT_defconfig:57:CONFIG_USB_XHCI_HCD=y
configs/k2e_hs_evm_defconfig:34:CONFIG_USB_XHCI_HCD=y
configs/ls1021aqds_sdcard_qspi_defconfig:61:CONFIG_USB_XHCI_HCD=y
configs/am43xx_evm_ethboot_defconfig:48:CONFIG_USB_XHCI_HCD=y
configs/xilinx_zynqmp_ep_defconfig:70:CONFIG_USB_XHCI_HCD=y
configs/ls1021aqds_nand_defconfig:57:CONFIG_USB_XHCI_HCD=y
configs/ls1021atwr_qspi_defconfig:50:CONFIG_USB_XHCI_HCD=y
configs/k2g_evm_defconfig:45:CONFIG_USB_XHCI_HCD=y
configs/am57xx_evm_defconfig:63:CONFIG_USB_XHCI_HCD=y
configs/am43xx_hs_evm_defconfig:49:CONFIG_USB_XHCI_HCD=y
configs/am43xx_evm_defconfig:39:CONFIG_USB_XHCI_HCD=y
configs/ls1021atwr_nor_defconfig:42:CONFIG_USB_XHCI_HCD=y
configs/firefly-rk3399_defconfig:59:CONFIG_USB_XHCI_HCD=y
configs/puma-rk3399_defconfig:78:CONFIG_USB_XHCI_HCD=y
configs/cl-som-am57x_defconfig:55:CONFIG_USB_XHCI_HCD=y
configs/ls1021aqds_nor_SECURE_BOOT_defconfig:43:CONFIG_USB_XHCI_HCD=y
configs/uniphier_pro4_defconfig:43:CONFIG_USB_XHCI_HCD=y
configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig:61:CONFIG_USB_XHCI_HCD=y
configs/xilinx_zynqmp_zcu102_defconfig:63:CONFIG_USB_XHCI_HCD=y
configs/ls1021atwr_nor_SECURE_BOOT_defconfig:42:CONFIG_USB_XHCI_HCD=y
configs/cm_t43_defconfig:67:CONFIG_USB_XHCI_HCD=y
configs/k2g_hs_evm_defconfig:36:CONFIG_USB_XHCI_HCD=y
configs/am43xx_evm_qspiboot_defconfig:45:CONFIG_USB_XHCI_HCD=y
configs/ls1021aqds_qspi_defconfig:50:CONFIG_USB_XHCI_HCD=y
configs/am57xx_hs_evm_defconfig:67:CONFIG_USB_XHCI_HCD=y
configs/xilinx_zynqmp_zcu102_revB_defconfig:63:CONFIG_USB_XHCI_HCD=y
configs/ls1021aqds_sdcard_ifc_defconfig:55:CONFIG_USB_XHCI_HCD=y
configs/uniphier_ld20_defconfig:39:CONFIG_USB_XHCI_HCD=y
configs/am43xx_evm_usbhost_boot_defconfig:61:CONFIG_USB_XHCI_HCD=y
configs/ls1021atwr_sdcard_qspi_defconfig:61:CONFIG_USB_XHCI_HCD=y
configs/evb-rk3399_defconfig:60:CONFIG_USB_XHCI_HCD=y
configs/k2hk_evm_defconfig:43:CONFIG_USB_XHCI_HCD=y
configs/k2hk_hs_evm_defconfig:34:CONFIG_USB_XHCI_HCD=y
configs/k2e_evm_defconfig:43:CONFIG_USB_XHCI_HCD=y
configs/ls1021atwr_sdcard_ifc_defconfig:54:CONFIG_USB_XHCI_HCD=y
configs/k2l_evm_defconfig:43:CONFIG_USB_XHCI_HCD=y

So it looks we have lots of conversion work to be done by many board
maintainers. I am not sure how to 

[U-Boot] [PATCH 1/3] arm: omap: Detect boot mode very early

[Lokesh Vutla]

ROM stores the boot params information in a known location
and passes it to SPL. This information needs to be copied
very early during boot or else there is a chance of getting
corrupted by SPL. So move this boot device detection very early
during boot.

Signed-off-by: Lokesh Vutla 
---
 arch/arm/mach-omap2/am33xx/board.c  | 8 
 arch/arm/mach-omap2/boot-common.c   | 7 ---
 arch/arm/mach-omap2/hwinit-common.c | 8 
 3 files changed, 16 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-omap2/am33xx/board.c 
b/arch/arm/mach-omap2/am33xx/board.c
index 5f1bf9ce7c..db757d91fb 100644
--- a/arch/arm/mach-omap2/am33xx/board.c
+++ b/arch/arm/mach-omap2/am33xx/board.c
@@ -333,6 +333,14 @@ void early_system_init(void)
set_uart_mux_conf();
setup_early_clocks();
uart_soft_reset();
+#ifdef CONFIG_SPL_BUILD
+   /*
+* Save the boot parameters passed from romcode.
+* We cannot delay the saving further than this,
+* to prevent overwrites.
+*/
+   save_omap_boot_params();
+#endif
 #ifdef CONFIG_DEBUG_UART_OMAP
debug_uart_init();
 #endif
diff --git a/arch/arm/mach-omap2/boot-common.c 
b/arch/arm/mach-omap2/boot-common.c
index b77506df83..700e6c2f79 100644
--- a/arch/arm/mach-omap2/boot-common.c
+++ b/arch/arm/mach-omap2/boot-common.c
@@ -195,13 +195,6 @@ u32 spl_boot_mode(const u32 boot_device)
 
 void spl_board_init(void)
 {
-   /*
-* Save the boot parameters passed from romcode.
-* We cannot delay the saving further than this,
-* to prevent overwrites.
-*/
-   save_omap_boot_params();
-
/* Prepare console output */
preloader_console_init();
 
diff --git a/arch/arm/mach-omap2/hwinit-common.c 
b/arch/arm/mach-omap2/hwinit-common.c
index 7f6db3cf37..77368ee85f 100644
--- a/arch/arm/mach-omap2/hwinit-common.c
+++ b/arch/arm/mach-omap2/hwinit-common.c
@@ -158,6 +158,14 @@ void early_system_init(void)
do_io_settings();
 #endif
setup_early_clocks();
+#ifdef CONFIG_SPL_BUILD
+   /*
+* Save the boot parameters passed from romcode.
+* We cannot delay the saving further than this,
+* to prevent overwrites.
+*/
+   save_omap_boot_params();
+#endif
do_board_detect();
vcores_init();
 #ifdef CONFIG_DEBUG_UART_OMAP
-- 
2.13.0

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

[U-Boot] [PATCH 2/3] arm: omap4+: Enable spl_early_init()

[Lokesh Vutla]

Enable spl_early_init() so that spl can use
DT very early during boot.

Signed-off-by: Lokesh Vutla 
---
 arch/arm/mach-omap2/hwinit-common.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-omap2/hwinit-common.c 
b/arch/arm/mach-omap2/hwinit-common.c
index 77368ee85f..7324d522ee 100644
--- a/arch/arm/mach-omap2/hwinit-common.c
+++ b/arch/arm/mach-omap2/hwinit-common.c
@@ -165,6 +165,7 @@ void early_system_init(void)
 * to prevent overwrites.
 */
save_omap_boot_params();
+   spl_early_init();
 #endif
do_board_detect();
vcores_init();
-- 
2.13.0

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

[U-Boot] [PATCH 3/3] ARM: dts: OMAP5+: Enable gpio in SPL

[Lokesh Vutla]

gpio2 is used to detect lcd based on which pin mux is done in SPL.
gpio7 is used to enable vtt regulator. Enable these two gpio nodes
in SPL.

Signed-off-by: Lokesh Vutla 
---
 arch/arm/dts/omap5-u-boot.dtsi | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/dts/omap5-u-boot.dtsi b/arch/arm/dts/omap5-u-boot.dtsi
index 9f9b4d1683..17602909a6 100644
--- a/arch/arm/dts/omap5-u-boot.dtsi
+++ b/arch/arm/dts/omap5-u-boot.dtsi
@@ -52,3 +52,11 @@
u-boot,dm-spl;
};
 };
+
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
-- 
2.13.0

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

[U-Boot] [PATCH 0/3] arm: omap: Enable SPL_DM very early

[Lokesh Vutla]

This series enables SPL_DM very early so that i2c, gpio can be
used.

Lokesh Vutla (3):
  arm: omap: Detect boot mode very early
  arm: omap4+: Enable spl_early_init()
  ARM: dts: OMAP5+: Enable gpio in SPL

 arch/arm/dts/omap5-u-boot.dtsi  | 8 
 arch/arm/mach-omap2/am33xx/board.c  | 8 
 arch/arm/mach-omap2/boot-common.c   | 7 ---
 arch/arm/mach-omap2/hwinit-common.c | 9 +
 4 files changed, 25 insertions(+), 7 deletions(-)

-- 
2.13.0

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

Re: [U-Boot] question regarding the odroidc2 board support

[Lukasz Majewski]

On Thu, 22 Jun 2017 19:55:21 +0200
daggs  wrote:

> Greetings,
> 
> I'm using buildroot to generate images for the odroid c2 boards and
> from what I see, it uses u-boot.bin to burn into the image. I'm not
> seeing any other uboot product that is used for booting (unless I'm
> mistaken). I'm reading the odroid c2 readme file and I see it
> instructs the use to burn a alternative u-boot.bin from the one that
> was created by the env. I wonder how it is possible to actually use
> newer uboot when in the end uboot recommends to replace u-boot.bin
> with pre existing one?

From the spec I do see that C2 has SD card and eMMC.

I can only share my experience with Odroid XU3/U3.

The boot process would (probably) require some signed blobs from
hardkernel (those binaries are corresponding to u-boot-spl.bin).

I can recommend looking to Hardkernel forum (they should have some
topics dedicated for this SoM), or look for tizen.org wiki:

https://wiki.tizen.org/Quick_guide_for_odroidxu3

I hope, that the boot flow is similar for XU3 and C2.

> 
> Thanks,
> 
> Dagg.
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PULL] Please pull u-boot-imx

[Stefano Babic]

Hi Tom,

this should be my last PR for the release. I checked which fixes should
go into release and all other patches can wait. I am starting to merge
pending patches into -next.

Most of commits are fixes (mx25, pciimx,..). Exception is pico-imx7d: I
merged since a lot of time, and I convinced I have already sent a
PR...sorry, for that.

For all imxers: let me know if I missed aome patches that *must* flow
into 2017.07. IMHO all of the pending patches can wait and I merge now
in -next.

The following changes since commit ccbbada0a59fead35495409d0c2c7bcb22a40278:

  Merge branch 'master' of git://git.denx.de/u-boot-mmc (2017-05-30
14:07:23 -0400)

are available in the git repository at:

  git://www.denx.de/git/u-boot-imx.git master

for you to fetch changes up to 65496a34835cb4c9547bd02dd15b018c333add9d:

  mx6: soc: Fix typo in temperature unit name (2017-06-27 09:06:09 +0200)


Benoît Thébaudeau (4):
  mmc: fsl_esdhc: Allow all supported prescaler values
  mx25: Fix imx_get_perclk()
  mx25: Add function to set PER clocks
  mx25pdk: Set the eSDHC PER clock to 48 MHz

Fabio Estevam (5):
  mx7dsabresd: Increase CONFIG_ENV_OFFSET
  mx6sabresd: Rename target to mx6sabresd_defconfig
  mx6sabresd: Update the config file
  mx6sabresd: Update to SPL only mode
  mx6: soc: Fix typo in temperature unit name

Jagan Teki (9):
  mmc: fsl_esdhc: Move non DM_MMC code in #ifndef CONFIG_DM_MMC
  engicam: Move SPL mmc configs under CONFIG_SPL_BUILD
  icorem6: Recover missing nand defconfig
  drivers: net: Kconfig: Add PHY_MICREL_KSZ9021 entry
  engicam: Move PHY configs to defconfig
  icorem6: Remove unused FEC configs
  engicam: Set console env on board_late_init
  engicam: Add fdt_addr env value based on cpu_type
  engicam: Generate single config file

Lothar Waßmann (1):
  arm: mx6: remove unused config variable CONFIG_SPL_NAND_MXS

Peng Fan (2):
  regulator: pfuze100: add SPDX License
  regulator: pfuze100: unsigned compared against 0

Tim Harvey (1):
  drivers: pci: imx: add imx_pcie_remove function

Vanessa Maegima (1):
  pico-imx7d: Add initial support

 arch/arm/cpu/arm926ejs/mx25/generic.c  |  30 +-
 arch/arm/cpu/armv7/mx6/soc.c   |   2 +-
 arch/arm/cpu/armv7/mx7/Kconfig |   8 +++
 arch/arm/imx-common/cpu.c  |   3 +
 arch/arm/include/asm/arch-mx25/clock.h |   1 +
 board/engicam/common/board.c   |   5 ++
 board/engicam/geam6ul/Kconfig  |   2 +-
 board/engicam/icorem6/Kconfig  |   2 +-
 board/engicam/icorem6_rqs/Kconfig  |   2 +-
 board/engicam/isiotmx6ul/Kconfig   |   2 +-
 board/freescale/mx25pdk/mx25pdk.c  |   6 ++
 board/freescale/mx6sabresd/MAINTAINERS |   4 +-
 board/freescale/mx6sabresd/README  |  84
++--
 board/technexion/pico-imx7d/Kconfig|  15 +
 board/technexion/pico-imx7d/MAINTAINERS|   7 +++
 board/technexion/pico-imx7d/Makefile   |   6 ++
 board/technexion/pico-imx7d/README |  49

 board/technexion/pico-imx7d/imximage.cfg   |  98

 board/technexion/pico-imx7d/pico-imx7d.c   | 289
+++
 configs/imx6qdl_icore_mmc_defconfig|   2 +
 configs/imx6qdl_icore_nand_defconfig   |  47

 configs/imx6qdl_icore_rqs_mmc_defconfig|   3 +
 configs/imx6ul_geam_mmc_defconfig  |   2 +
 configs/imx6ul_geam_nand_defconfig |   2 +
 configs/imx6ul_isiot_emmc_defconfig|   2 +
 configs/imx6ul_isiot_mmc_defconfig |   2 +
 configs/imx6ul_isiot_nand_defconfig|   2 +
 configs/{mx6sabresd_spl_defconfig => mx6sabresd_defconfig} |   0
 configs/pico-imx7d_defconfig   |  35

 drivers/mmc/fsl_esdhc.c|  53
+-
 drivers/net/phy/Kconfig|   8 +++
 drivers/pci/pcie_imx.c |  38
+
 drivers/power/regulator/pfuze100.c |  14 -
 include/configs/{imx6qdl_icore.h => imx6-engicam.h}|  47
+++-
 include/configs/imx6_spl.h |   5 --
 include/configs/imx6qdl_icore_rqs.h| 147

Re: [U-Boot] drivers: pci: imx: add imx_pcie_remove function

[Stefano Babic]

On 26/06/2017 16:07, Soeren Moch wrote:
> 
> 
> On 12.05.2017 21:58, Tim Harvey wrote:
>> There is no dedicated reset signal wired up for the MX6QDL thus if the
>> bootloader enables the link we need some special handling to get the core
>> back into a state where it is safe to touch it for configuration.
>>
>> While there has been some special handling in the Linux kernel to do this,
>> it was removed in 4.11 thus we need to do it properly in the bootloader
>> and therefore without this if you enable PCI in the bootloader you will hang
>> while booting the 4.11 kernel.
>>
>> This puts the PCIe controller back into a safe state for the kernel driver
>> before launching the kernel.
>>
>> Signed-off-by: Tim Harvey 
>> Reviewed-by: Fabio Estevam 
>> Tested-by: Peter Senna Tschudin 
> 
> Tested-by: Soeren Moch 
> 
> 
> 
> Stefano,
> 
> can we get this fix merged for v2017.07!?

Yes - this is merged in u-boot-imx, I am checking now which pending
patches are bug fixes that can flow in, and I send later my PR to Tom.

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
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v6 3/3] GPT: provide commands to selectively rename partitions

[Lothar Waßmann]

Hi,

On Sun, 25 Jun 2017 14:54:56 -0700 Alison Chaiken wrote:
> On Sun, Jun 18, 2017 at 4:03 AM, Wolfgang Denk  wrote:
> 
> > Dear Alison,
> >
> > In message 

Re: [U-Boot] [PATCH] am335x_evm_usbspl_defconfig: Fix USB RNDIS boot

[Vignesh R]

Lokesh,

On Monday 10 April 2017 01:56 PM, Vignesh R wrote:
> It seems few config options are missing in the current
> am335x_evm_usbspl_defconfig causing USB RNDIS boot to fail on AM335x
> EVM. Fix this by adding required configs.
> 
> Signed-off-by: Vignesh R 
> ---

Could you ack this patch, its still relevant to get USB RNDIS to work.



>  configs/am335x_evm_usbspl_defconfig | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/configs/am335x_evm_usbspl_defconfig 
> b/configs/am335x_evm_usbspl_defconfig
> index a79470e88685..0a32d41eae67 100644
> --- a/configs/am335x_evm_usbspl_defconfig
> +++ b/configs/am335x_evm_usbspl_defconfig
> @@ -44,3 +44,7 @@ CONFIG_G_DNL_MANUFACTURER="Texas Instruments"
>  CONFIG_G_DNL_VENDOR_NUM=0x0451
>  CONFIG_G_DNL_PRODUCT_NUM=0xd022
>  CONFIG_OF_LIBFDT=y
> +CONFIG_SPL_ETH_SUPPORT=y
> +CONFIG_SPL_USB_GADGET_SUPPORT=y
> +CONFIG_SPL_USBETH_SUPPORT=y
> +CONFIG_SPL_NET_VCI_STRING="AM335x U-Boot SPL"
> 

-- 
Regards
Vignesh
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot