Re: [U-Boot] [PATCH] mmc: Set the initial clock speed to 400KHz

[Jaehoon Chung]

On 05/25/2017 11:14 PM, Phil Edworthy wrote:
> Hi Jaehoon Chung,
> 
> On 25 May 2017 15:10 Jaehoon Chung wrote:
>> On 05/25/2017 11:02 PM, Phil Edworthy wrote:
>>> On 25 May 2017 14:50 Jaehoon Chung wrote:
 On 05/24/2017 10:54 PM, Phil Edworthy wrote:
> The code currently defaults to the slowest clock speed that can be
> achieved, which can be significantly lower than the SD spec.

 Is there any problem..As i know, it should be changed from 1 to min_clk.
>>> The only problem is that the initial SD clock can be very slow so it
>>> increases the time to start SD. Admittedly, it's a very small increase
>>> in time, but we should use the correct initial clock speed.
>>
>> Well..i didn't agree yet...
>>
>> If mmc_set_clock(mmc, 400K) and mmc->cfg->f_min is 300K?
>> Initial clock should be always 400K..but spec is mentioned "initial clock is
>> maximum 400K.."
>> It means the clock can be the value under 400K.
> I'm not sure I follow you.
> The spec means that all SD cards must support an initial clock speed of 
> 400KHz, right?

No..clock frequency range shall be 100KHz - 400KHz during initialization 
sequence.
Some targets should not work fine with 400KHz..So it needs to check f_min value.
otherwise, it needs to find the initial clock value like Linux kernel scheme.

> If so, then there is no harm in setting it to 400KHz.
> 
> Thanks
> Phil
> 
> Signed-off-by: Phil Edworthy 
> ---
>  drivers/mmc/mmc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index
> 72fc177..dff1be3 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -1676,7 +1676,7 @@ int mmc_start_init(struct mmc *mmc)  #endif
>   mmc->ddr_mode = 0;
>   mmc_set_bus_width(mmc, 1);
> - mmc_set_clock(mmc, 1);
> + mmc_set_clock(mmc, 40);
>
>   /* Reset the Card */
>   err = mmc_go_idle(mmc);
>
>>>
>>>
>>>
>>>
> 
> 
> 
> 

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

Re: [U-Boot] Please pull u-boot-fdt, take 2

[Simon Glass]

Hi Tom,

On 25 May 2017 at 11:42, Tom Rini  wrote:
> On Thu, May 25, 2017 at 11:27:10AM -0600, Simon Glass wrote:
>> Hi Tom,
>>
>> On 25 May 2017 at 05:19, Tom Rini  wrote:
>> >
>> > On Wed, May 24, 2017 at 06:15:25PM -0600, Simon Glass wrote:
>> >
>> > > Hi Tom,
>> > >
>> > > This incorporates the v2 patch for 'fdt: Build the new python libfdt
>> > > module' which should fix the problem with the original pull request.
>> > >
>> > >
>> > > The following changes since commit 
>> > > be62fbf376261ab3a4ed5db3bf54d5df9e216d9f:
>> > >
>> > >   Merge branch 'rmobile' of git://git.denx.de/u-boot-sh (2017-05-23
>> > > 16:22:03 -0400)
>> > >
>> > > are available in the git repository at:
>> > >
>> > >   git://git.denx.de/u-boot-fdt.git
>> > >
>> > > for you to fetch changes up to da9c601049eb7c993c7f6e33ae10af7a847a483d:
>> > >
>> > >   fdt: Drop fdt_select.py (2017-05-24 18:12:31 -0600)
>> >
>> > NAK.  travis-ci blows up quite badly:
>> > https://travis-ci.org/trini/u-boot/builds/235861889
>>
>> I'm not sure how to repeat this problem. When I try this:
>
> Your best bet is likely:
> https://docs.travis-ci.com/user/common-build-problems/#Troubleshooting-Locally-in-a-Docker-Image

Sadly still no luck. I installed this one:

travisci/ci-garnet:packer-1478744932

It includes python-dev but not swig, so should not be able to build
the module. As expected I get this error:

NO_SDL=1 ./tools/buildman/buildman -P sandbox_spl
boards.cfg is up to date. Nothing to do.
Building current source for 1 boards (1 thread, 8 jobs per thread)
   sandbox:  +   sandbox_spl
+Traceback (most recent call last):
+  File "", line 1, in 
+ImportError: No module named libfdt
+make[2]: *** [checkdtoc] Error 1
+make[1]: *** [spl/u-boot-spl] Error 2
+make: *** [sub-make] Error 2


If I install swig then all is well. I don't see the same error.

I'm also unsure how you get it to pass with some boards but not others...

There is obviously something odd going on. I also cannot understand
why in this one:

https://travis-ci.org/trini/u-boot/jobs/235861899#L769

I see it trying to compile libfdt_wrap.c. That should be handled by
setup.py - I just cannot figure out why it would try to compile it
itself:

  arm:  +  mx6sabresd_spl
+mv: cannot stat lib/libfdt/pylibfdt/libfdt.py: No such file or directory
+make[2]: *** [tools/_libfdt.so] Error 1
+make[1]: *** [tools] Error 2
+make: *** [sub-make] Error 2
  arm:  +  ls1021aqds_nor_lpuart
+x86_64-linux-gnu-gcc: error: lib/libfdt/pylibfdt/libfdt_wrap.c: No
such file or directory
+x86_64-linux-gnu-gcc: fatal error: no input files
+compilation terminated.
+error: command 'x86_64-linux-gnu-gcc' failed with exit status 4
+make[2]: *** [tools/_libfdt.so] Error 1
+make[1]: *** [tools] Error 2
+make: *** [sub-make] Error 2
  arm:  +  mx6slevk
+x86_64-linux-gnu-gcc: error: lib/libfdt/pylibfdt/libfdt_wrap.c: No
such file or directory
+x86_64-linux-gnu-gcc: fatal error: no input files
+compilation terminated.
+error: command 'x86_64-linux-gnu-gcc' failed with exit status 4
+make[2]: *** [tools/_libfdt.so] Error 1
+make[1]: *** [tools] Error 2
+make: *** [sub-make] Error 2
  5503 /58 mx6qsabreauto
boards.cfg is up to date. Nothing to do.
Summary of current source for 58 boards (2 threads, 1 job per thread)
  arm:  +  mx6sabresd_spl ls1021aqds_nor_lpuart mx6slevk
+mv: cannot stat lib/libfdt/pylibfdt/libfdt.py: No such file or directory


Are you able to run with V=1 to get the full make output? That might
help me narrow it down. Or, if you have a particular docket image,
please point me to it. There seems to be some init going on though
(e.g. /tmp/dtc).

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

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

[Chee, Tien Fong]

On Kha, 2017-05-25 at 11:18 +0200, Marek Vasut wrote:
> On 05/25/2017 10:53 AM, Chee, Tien Fong wrote:
> > 
> > On Rab, 2017-05-24 at 09:56 -0500, Dinh Nguyen wrote:
> > > 
> > > 
> > > On 05/23/2017 09:24 PM, tien.fong.c...@intel.com wrote:
> > > > 
> > > > 
> > > > From: Tien Fong Chee 
> > > > 
> > > > This is the 6th version of patchset to adds support for Intel
> > > > Arria
> > > > 10 SoC FPGA
> > > > driver. This version mainly resolved comments from Dinh in
> > > > [v5].
> > > > This series is working on top of u-boot-socfpga-next branch
> > > > http://git.denx.de/?p=u-boot/u-boot-socfpga.git;a=shortlog;h=re
> > > > fs/h
> > > > eads/next.
> > > > 
> > > > [v5]: https://www.mail-archive.com/u-boot@lists.denx.de/msg2505
> > > > 17.h
> > > > tml
> > > > 
> > > > v5 -> v6 changes:
> > > > -
> > > > - Created separate patch for enabling FPGA driver support.
> > > > 
> > > Please consider at least doing a compile test for this patch
> > > series?
> > > I'm
> > > now very skeptical that you've done any kind of testing on this
> > > patch
> > > series? :(
> > > 
> > > For 'make socfpga_cyclone5_defconfig:
> > > 
> > > arch/arm/mach-socfpga/built-in.o: In function
> > > `socfpga_bridges_reset':
> > > /home/dinguyen/linux_dev/u-boot/arch/arm/mach-
> > > socfpga/reset_manager_gen5.c:101:
> > > undefined reference to `fpgamgr_test_fpga_ready'
> > > arch/arm/mach-socfpga/built-in.o: In function
> > > `populate_sysmgr_fpgaintf_module':
> > > /home/dinguyen/linux_dev/u-boot/arch/arm/mach-
> > > socfpga/system_manager_gen5.c:48:
> > > undefined reference to `fpgamgr_test_fpga_ready'
> > > drivers/built-in.o: In function `sdram_mmr_init_full':
> > > /home/dinguyen/linux_dev/u-boot/drivers/ddr/altera/sdram.c:448:
> > > undefined reference to `fpgamgr_test_fpga_ready'
> > > scripts/Makefile.spl:334: recipe for target 'spl/u-boot-spl'
> > > failed
> > > make[1]: *** [spl/u-boot-spl] Error 1
> > > Makefile:1347: recipe for target 'spl/u-boot-spl' failed
> > > make: *** [spl/u-boot-spl] Error 2
> > > 
> > > For socfpga_arria10_defconfig:
> > > 
> > > arch/arm/mach-socfpga/built-in.o: In function `socfpga_fpga_add':
> > > /home/dinguyen/linux_dev/u-boot/arch/arm/mach-socfpga/misc.c:110:
> > > undefined reference to `fpga_init'
> > > /home/dinguyen/linux_dev/u-boot/arch/arm/mach-socfpga/misc.c:112:
> > > undefined reference to `fpga_add'
> > > scripts/Makefile.spl:334: recipe for target 'spl/u-boot-spl'
> > > failed
> > > make[1]: *** [spl/u-boot-spl] Error 1
> > > Makefile:1347: recipe for target 'spl/u-boot-spl' failed
> > > make: *** [spl/u-boot-spl] Error 2
> > > 
> > > 
> > > Dinh
> > I did the compilation on each patch, and testing the patch set on
> > all
> > arria10, cyclone5 and arria10 devkit.
> > 
> > I suspect something wrong with v6-0005-arm-socfpga-Move-FPGA-
> > manager-
> > driver-to-FPGA-driv.patch you applied. Could you help me check
> > again
> > and confirm all the patches waere applied properly?
> > 
> > In the meantime, i will clone the lastet from mainstream to confirm
> > again. This cloning need take a few hours to finish.
> Do you know git fetch origin ? That'll fetch only the new blobs, you
> don't need to fetch the whole repo again ...
> 
Yeah, i don't have u-boot.git, so i need to clone it. In the meantime,
i also run git fetch origin on u-boot-socfpga.git. Due to our company
tight security, both also need a few hours.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 10/38] samsung: mmc: Drop s3c_sdi driver

[Jaehoon Chung]

On 05/17/2017 11:22 PM, Simon Glass wrote:
> This is no-longer used in U-Boot. Drop it.
> 
> Signed-off-by: Simon Glass 

Reviewed-by: Jaehoon Chung 

> ---
> 
>  drivers/mmc/Makefile |   1 -
>  drivers/mmc/s3c_sdi.c| 323 
> ---
>  scripts/config_whitelist.txt |   1 -
>  3 files changed, 325 deletions(-)
>  delete mode 100644 drivers/mmc/s3c_sdi.c
> 
> diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
> index a078649899..2d781c38a6 100644
> --- a/drivers/mmc/Makefile
> +++ b/drivers/mmc/Makefile
> @@ -40,7 +40,6 @@ obj-$(CONFIG_MMC_MXS)   += mxsmmc.o
>  obj-$(CONFIG_MMC_PCI)+= pci_mmc.o
>  obj-$(CONFIG_PXA_MMC_GENERIC) += pxa_mmc_gen.o
>  obj-$(CONFIG_SUPPORT_EMMC_RPMB) += rpmb.o
> -obj-$(CONFIG_S3C_SDI) += s3c_sdi.o
>  obj-$(CONFIG_MMC_SANDBOX)+= sandbox_mmc.o
>  obj-$(CONFIG_SH_MMCIF) += sh_mmcif.o
>  obj-$(CONFIG_SH_SDHI) += sh_sdhi.o
> diff --git a/drivers/mmc/s3c_sdi.c b/drivers/mmc/s3c_sdi.c
> deleted file mode 100644
> index faf7b83a14..00
> --- a/drivers/mmc/s3c_sdi.c
> +++ /dev/null
> @@ -1,323 +0,0 @@
> -/*
> - * S3C24xx SD/MMC driver
> - *
> - * Based on OpenMoko S3C24xx driver by Harald Welte 
> - *
> - * Copyright (C) 2014 Marek Vasut 
> - *
> - * SPDX-License-Identifier:  GPL-2.0+
> - */
> -
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -
> -#define S3C2440_SDICON_SDRESET   (1 << 8)
> -#define S3C2410_SDICON_FIFORESET (1 << 1)
> -#define S3C2410_SDICON_CLOCKTYPE (1 << 0)
> -
> -#define S3C2410_SDICMDCON_LONGRSP(1 << 10)
> -#define S3C2410_SDICMDCON_WAITRSP(1 << 9)
> -#define S3C2410_SDICMDCON_CMDSTART   (1 << 8)
> -#define S3C2410_SDICMDCON_SENDERHOST (1 << 6)
> -#define S3C2410_SDICMDCON_INDEX  0x3f
> -
> -#define S3C2410_SDICMDSTAT_CRCFAIL   (1 << 12)
> -#define S3C2410_SDICMDSTAT_CMDSENT   (1 << 11)
> -#define S3C2410_SDICMDSTAT_CMDTIMEOUT(1 << 10)
> -#define S3C2410_SDICMDSTAT_RSPFIN(1 << 9)
> -
> -#define S3C2440_SDIDCON_DS_WORD  (2 << 22)
> -#define S3C2410_SDIDCON_TXAFTERRESP  (1 << 20)
> -#define S3C2410_SDIDCON_RXAFTERCMD   (1 << 19)
> -#define S3C2410_SDIDCON_BLOCKMODE(1 << 17)
> -#define S3C2410_SDIDCON_WIDEBUS  (1 << 16)
> -#define S3C2440_SDIDCON_DATSTART (1 << 14)
> -#define S3C2410_SDIDCON_XFER_RXSTART (2 << 12)
> -#define S3C2410_SDIDCON_XFER_TXSTART (3 << 12)
> -#define S3C2410_SDIDCON_BLKNUM   0x7ff
> -
> -#define S3C2410_SDIDSTA_FIFOFAIL (1 << 8)
> -#define S3C2410_SDIDSTA_CRCFAIL  (1 << 7)
> -#define S3C2410_SDIDSTA_RXCRCFAIL(1 << 6)
> -#define S3C2410_SDIDSTA_DATATIMEOUT  (1 << 5)
> -#define S3C2410_SDIDSTA_XFERFINISH   (1 << 4)
> -
> -#define S3C2410_SDIFSTA_TFHALF   (1 << 11)
> -#define S3C2410_SDIFSTA_COUNTMASK0x7f
> -
> -/*
> - * WARNING: We only support one SD IP block.
> - * NOTE: It's not likely there will ever exist an S3C24xx with two,
> - *   at least not in this universe all right.
> - */
> -static int wide_bus;
> -
> -static int
> -s3cmmc_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd, struct mmc_data *data)
> -{
> - struct s3c24x0_sdi *sdi_regs = s3c24x0_get_base_sdi();
> - uint32_t sdiccon, sdicsta, sdidcon, sdidsta, sdidat, sdifsta;
> - uint32_t sdicsta_wait_bit = S3C2410_SDICMDSTAT_CMDSENT;
> - unsigned int timeout = 10;
> - int ret = 0, xfer_len, data_offset = 0;
> - const uint32_t sdidsta_err_mask = S3C2410_SDIDSTA_FIFOFAIL |
> - S3C2410_SDIDSTA_CRCFAIL | S3C2410_SDIDSTA_RXCRCFAIL |
> - S3C2410_SDIDSTA_DATATIMEOUT;
> -
> -
> - writel(0x, _regs->sdicsta);
> - writel(0x, _regs->sdidsta);
> - writel(0x, _regs->sdifsta);
> -
> - /* Set up data transfer (if applicable). */
> - if (data) {
> - writel(data->blocksize, _regs->sdibsize);
> -
> - sdidcon = data->blocks & S3C2410_SDIDCON_BLKNUM;
> - sdidcon |= S3C2410_SDIDCON_BLOCKMODE;
> -#if defined(CONFIG_S3C2440)
> - sdidcon |= S3C2440_SDIDCON_DS_WORD | S3C2440_SDIDCON_DATSTART;
> -#endif
> - if (wide_bus)
> - sdidcon |= S3C2410_SDIDCON_WIDEBUS;
> -
> - if (data->flags & MMC_DATA_READ) {
> - sdidcon |= S3C2410_SDIDCON_RXAFTERCMD;
> - sdidcon |= S3C2410_SDIDCON_XFER_RXSTART;
> - } else {
> - sdidcon |= S3C2410_SDIDCON_TXAFTERRESP;
> - sdidcon |= S3C2410_SDIDCON_XFER_TXSTART;
> - }
> -
> - writel(sdidcon, _regs->sdidcon);
> - }
> -
> - /* Write CMD arg. */
> - writel(cmd->cmdarg, _regs->sdicarg);
> -
> - /* Write CMD index. */
> - sdiccon = cmd->cmdidx & S3C2410_SDICMDCON_INDEX;
> - sdiccon |= 

Re: [U-Boot] [PATCH] power: pmic: tps65218: Fix tps65218_voltage_update function

[Jaehoon Chung]

On 05/25/2017 10:52 PM, Keerthy wrote:
> 
> 
> On Thursday 25 May 2017 07:18 PM, Jaehoon Chung wrote:
>> On 05/24/2017 01:49 PM, Keerthy wrote:
>>> Currently while setting the vsel value for dcdc1 and dcdc2
>>> the driver is wrongly masking the entire 8 bits in the process
>>> clearing PFM (bit7) field as well. Hence describe an appropriate
>>> mask for vsel field and modify only those bits in the vsel
>>> mask.
>>>
>>> Source: http://www.ti.com/lit/ds/symlink/tps65218.pdf
>>>
>>> Signed-off-by: Keerthy 
>>> Fixes: 86db550b38 ("power: Add support for the TPS65218 PMIC")
>>
>> If delegate to me..i will pick this.
>>
>> Reviewed-by: Jaehoon Chung 
> 
> Thanks Jaehoon Chung.

Applied to u-boot-mmc. Thanks

Jaehoon Chung

> 
>>
>>> ---
>>>  drivers/power/pmic/pmic_tps65218.c | 2 +-
>>>  include/power/tps65218.h   | 2 ++
>>>  2 files changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/power/pmic/pmic_tps65218.c 
>>> b/drivers/power/pmic/pmic_tps65218.c
>>> index f32fa40..c5e768a 100644
>>> --- a/drivers/power/pmic/pmic_tps65218.c
>>> +++ b/drivers/power/pmic/pmic_tps65218.c
>>> @@ -101,7 +101,7 @@ int tps65218_voltage_update(uchar dc_cntrl_reg, uchar 
>>> volt_sel)
>>>  
>>> /* set voltage level */
>>> if (tps65218_reg_write(TPS65218_PROT_LEVEL_2, dc_cntrl_reg, volt_sel,
>>> -  TPS65218_MASK_ALL_BITS))
>>> +  TPS65218_DCDC_VSEL_MASK))
>>> return 1;
>>>  
>>> /* set GO bit to initiate voltage transition */
>>> diff --git a/include/power/tps65218.h b/include/power/tps65218.h
>>> index 4d68faa..e3538e2 100644
>>> --- a/include/power/tps65218.h
>>> +++ b/include/power/tps65218.h
>>> @@ -56,6 +56,8 @@ enum {
>>>  
>>>  #define TPS65218_MASK_ALL_BITS 0xFF
>>>  
>>> +#define TPS65218_DCDC_VSEL_MASK0x3F
>>> +
>>>  #define TPS65218_DCDC_VOLT_SEL_0950MV  0x0a
>>>  #define TPS65218_DCDC_VOLT_SEL_1100MV  0x19
>>>  #define TPS65218_DCDC_VOLT_SEL_1200MV  0x23
>>>
>>
> 
> 
> 

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

Re: [U-Boot] [PATCH] power: pmic: tps65218: Fix tps65218_voltage_update function

[Jaehoon Chung]

On 05/25/2017 11:34 PM, Tom Rini wrote:
> On Thu, May 25, 2017 at 10:48:55PM +0900, Jaehoon Chung wrote:
>> On 05/24/2017 01:49 PM, Keerthy wrote:
>>> Currently while setting the vsel value for dcdc1 and dcdc2
>>> the driver is wrongly masking the entire 8 bits in the process
>>> clearing PFM (bit7) field as well. Hence describe an appropriate
>>> mask for vsel field and modify only those bits in the vsel
>>> mask.
>>>
>>> Source: http://www.ti.com/lit/ds/symlink/tps65218.pdf
>>>
>>> Signed-off-by: Keerthy 
>>> Fixes: 86db550b38 ("power: Add support for the TPS65218 PMIC")
>>
>> If delegate to me..i will pick this.
> 
> Feel free (always!) to grab things in patchwork that are in your areas,
> thanks!

Thanks!

> 

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

Re: [U-Boot] [PATCH 10/22] mmc: refactor MMC startup to make it easier to support new modes

[Jaehoon Chung]

On 05/25/2017 11:40 PM, Jean-Jacques Hiblot wrote:
> Hi,
> 
> 
> On 25/05/2017 14:25, Jaehoon Chung wrote:
>> On 05/13/2017 03:16 AM, Jean-Jacques Hiblot wrote:
>>> The MMC startup process currently handles 4 modes. To make it easier to
>>> add support for more modes, let's make the process more generic and use a
>>> list of the modes to try.
>>> The major functional change is that when a mode fails we try the next one.
>>> Not all modes are tried, only those supported by the card and the host.
>>>
>>> Signed-off-by: Jean-Jacques Hiblot 
>>> ---
>>>   drivers/mmc/mmc.c | 238 
>>> +-
>>>   include/mmc.h |  15 +++-
>>>   2 files changed, 157 insertions(+), 96 deletions(-)
>>>
>>> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
>>> index f42a0fe..2931871 100644
>>> --- a/drivers/mmc/mmc.c
>>> +++ b/drivers/mmc/mmc.c
>>> @@ -200,6 +200,7 @@ static int mmc_select_mode(struct mmc *mmc, enum 
>>> bus_mode mode)
>>>   {
>>>   mmc->selected_mode = mode;
>>>   mmc->tran_speed = mmc_mode2freq(mmc, mode);
>>> +mmc->ddr_mode = mmc_is_mode_ddr(mode);
>>>   debug("selecting mode %s (freq : %d MHz)\n", mmc_mode_name(mode),
>>> mmc->tran_speed / 100);
>>>   return 0;
>>> @@ -602,11 +603,46 @@ int mmc_switch(struct mmc *mmc, u8 set, u8 index, u8 
>>> value)
>>> }
>>>   -static int mmc_change_freq(struct mmc *mmc)
>>> +static int mmc_set_card_speed(struct mmc *mmc, enum bus_mode mode)
>>>   {
>>> -ALLOC_CACHE_ALIGN_BUFFER(u8, ext_csd, MMC_MAX_BLOCK_LEN);
>>> -char cardtype;
>>>   int err;
>>> +int speed_bits;
>>> +ALLOC_CACHE_ALIGN_BUFFER(u8, test_csd, MMC_MAX_BLOCK_LEN);
>>> +
>>> +switch (mode) {
>>> +case MMC_HS:
>>> +case MMC_HS_52:
>>> +case MMC_DDR_52:
>>> +  speed_bits = EXT_CSD_TIMING_HS;
>>> +case MMC_LEGACY:
>>> +  speed_bits = EXT_CSD_TIMING_LEGACY;
>>> +  break;
>>> +default:
>>> +  return -EINVAL;
>>> +}
>>> +err = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_HS_TIMING,
>>> + speed_bits);
>>> +if (err)
>>> +return err;
>>> +
>>> +if ((mode == MMC_HS) || (mode == MMC_HS_52)) {
>>> +/* Now check to see that it worked */
>>> +err = mmc_send_ext_csd(mmc, test_csd);
>>> +if (err)
>>> +return err;
>>> +
>>> +/* No high-speed support */
>>> +if (!test_csd[EXT_CSD_HS_TIMING])
>>> +return -ENOTSUPP;
>>> +}
>>> +
>>> +return 0;
>>> +}
>>> +
>>> +static int mmc_get_capabilities(struct mmc *mmc)
>>> +{
>>> +u8 *ext_csd = mmc->ext_csd;
>>> +char cardtype;
>>> mmc->card_caps = MMC_MODE_1BIT;
>>>   @@ -617,38 +653,23 @@ static int mmc_change_freq(struct mmc *mmc)
>>>   if (mmc->version < MMC_VERSION_4)
>>>   return 0;
>>>   -mmc->card_caps |= MMC_MODE_4BIT | MMC_MODE_8BIT;
>>> -
>>> -err = mmc_send_ext_csd(mmc, ext_csd);
>>> +if (!ext_csd) {
>>> +error("No ext_csd found!\n"); /* this should enver happen */
>>> +return -ENOTSUPP;
>>> +}
>>>   -if (err)
>>> -return err;
>>> +mmc->card_caps |= MMC_MODE_4BIT | MMC_MODE_8BIT;
>>> cardtype = ext_csd[EXT_CSD_CARD_TYPE] & 0xf;
>>>   -err = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_HS_TIMING, 1);
>>> -
>>> -if (err)
>>> -return err;
>>> -
>>> -/* Now check to see that it worked */
>>> -err = mmc_send_ext_csd(mmc, ext_csd);
>>> -
>>> -if (err)
>>> -return err;
>>> -
>>> -/* No high-speed support */
>>> -if (!ext_csd[EXT_CSD_HS_TIMING])
>>> -return 0;
>>> -
>>>   /* High Speed is set, there are two types: 52MHz and 26MHz */
>>>   if (cardtype & EXT_CSD_CARD_TYPE_52) {
>>> -if (cardtype & EXT_CSD_CARD_TYPE_DDR_1_8V)
>>> +if (cardtype & EXT_CSD_CARD_TYPE_DDR_52)
>>>   mmc->card_caps |= MMC_MODE_DDR_52MHz;
>>> -mmc->card_caps |= MMC_MODE_HS_52MHz | MMC_MODE_HS;
>>> -} else {
>>> -mmc->card_caps |= MMC_MODE_HS;
>>> +mmc->card_caps |= MMC_MODE_HS_52MHz;
>>>   }
>>> +if (cardtype & EXT_CSD_CARD_TYPE_26)
>>> +mmc->card_caps |= MMC_MODE_HS;
>>> return 0;
>>>   }
>>> @@ -1320,33 +1341,58 @@ static int mmc_read_and_compare_ext_csd(struct mmc 
>>> *mmc)
>>>   }
>>> -static int mmc_select_bus_freq_width(struct mmc *mmc)
>>> +static const struct mode_width_tuning mmc_modes_by_pref[] = {
>>> +{
>>> +.mode = MMC_HS_200,
>>> +.widths = MMC_MODE_8BIT | MMC_MODE_4BIT,
>>> +},
>>> +{
>>> +.mode = MMC_DDR_52,
>>> +.widths = MMC_MODE_8BIT | MMC_MODE_4BIT,
>>> +},
>>> +{
>>> +.mode = MMC_HS_52,
>>> +.widths = MMC_MODE_8BIT | MMC_MODE_4BIT | MMC_MODE_1BIT,
>>> +},
>>> +{
>>> +.mode = MMC_HS,
>>> +.widths = MMC_MODE_8BIT | MMC_MODE_4BIT | MMC_MODE_1BIT,
>>> +},
>>> +{
>>> +

Re: [U-Boot] [PATCH] armv7m: Fix larger builds

[Vikas MANOCHA]

Hi Phil,

> -Original Message-
> From: Phil Edworthy [mailto:phil.edwor...@renesas.com]
> Sent: Thursday, May 25, 2017 6:58 AM
> To: Vikas MANOCHA ; Albert Aribaud 
> 
> Cc: Tom Rini ; Kamil Lulko ; 
> u-boot@lists.denx.de
> Subject: RE: [PATCH] armv7m: Fix larger builds
> 
> Hi Vikas,
> 
> On 25 May 2017 10:16 Phil Edworthy wrote:
> > > On 24 May 2017 18:32 Vikas MANOCHA wrote:
> > > Hi Phil,
> > >
> > > > On Wednesday, May 24, 2017 7:34 AM Phil Edworthy wrote:
> > > > The branch instruction only has an 11-bit relative target address, 
> > > > which is
> > > sometimes not enough.
> > > >
> > > > Signed-off-by: Phil Edworthy 
> > > > ---
> > > >  arch/arm/cpu/armv7m/start.S | 3 ++-
> > > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/arch/arm/cpu/armv7m/start.S
> > b/arch/arm/cpu/armv7m/start.S
> > > > index 49f2720..d79adb5 100644
> > > > --- a/arch/arm/cpu/armv7m/start.S
> > > > +++ b/arch/arm/cpu/armv7m/start.S
> > > > @@ -8,7 +8,8 @@
> > > >  .globl reset
> > > >  .type reset, %function
> > > >  reset:
> > > > -   b   _main
> > > > +   ldr r0, =_main
> > > > +   mov pc, r0
> > >
> > > How about using W(b) for wider range ?
> > Yes, that makes better sense!
> Hmm, if I use W(b) it complains with:
> arch/arm/cpu/armv7m/start.S:14:(.text+0x0): relocation truncated to fit: 
> R_ARM_THM_JUMP11 against symbol `_main' defined in
> .text section in arch/arm/lib/built-in.o

Seems like the generated branch instruction is still 16 bit, you can check the 
disassembly.  Which compiler & version you are using ? 
Are you getting the same issue with "b  _main" also. If no, compare the 
disassembly.

Cheers,
Vikas

> 
> Any ideas why?
> Phil
> 
> > Thanks
> > Phil
> >
> > > Cheers,
> > > Vikas
> > >
> > > >
> > > >  .globl c_runtime_cpu_setup
> > > >  c_runtime_cpu_setup:
> > > > --
> > > > 2.7.4

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

Re: [U-Boot] [PATCH 5/5] sun50i: h5: Add initial Orangepi Zero Plus 2 support

[André Przywara]

On 25/05/17 20:35, Jagan Teki wrote:
> From: Jagan Teki 
> 
> Orangepi Zero Plus 2 is an open-source single-board computer
> using the Allwinner h5 SOC.
> 
> H5 Orangepi Zero Plus 2 has
> - Quad-core Cortex-A53
> - 512MB DDR3
> - Debug TTL UART
> - HDMI
> - Wifi + BT
> - OTG+power supply

What about the eMMC? The link below says it features 8GB of it.
So you should have the appropriate DT node and the defconfig option to
allow booting from it.

> http://www.orangepi.org/OrangePiZeroPlus2/

But in general I think this is somewhat gated by the general H5 DT issue
I mentioned in the other mail.

Cheers,
Andre.

> 
> Boot from MMC:
> --
> U-Boot SPL 2017.05-00663-g51233ac-dirty (May 25 2017 - 16:18:41)
> DRAM: 512 MiB
> Trying to boot from MMC1
> NOTICE:  BL3-1: Running on H5 (1718) in SRAM A2 (@0x44000)
> NOTICE:  Configuring SPC Controller
> NOTICE:  BL3-1: v1.0(debug):aa75c8d
> NOTICE:  BL3-1: Built : 18:28:27, May 24 2017
> INFO:BL3-1: Initializing runtime services
> INFO:BL3-1: Preparing for EL3 exit to normal world
> INFO:BL3-1: Next image address: 0x4a00, SPSR: 0x3c9
> 
> U-Boot 2017.05-00663-g51233ac-dirty (May 25 2017 - 16:18:41 +) Allwinner 
> Technology
> 
> CPU:   Allwinner H5 (SUN50I)
> Model: OrangePi Zero Plus2
> DRAM:  512 MiB
> MMC:   SUNXI SD/MMC: 0
> *** Warning - bad CRC, using default environment
> 
> In:serial
> Out:   serial
> Err:   serial
> Net:   phy interface7
> eth0: ethernet@1c3
> starting USB...
> USB0:   USB EHCI 1.00
> USB1:   USB OHCI 1.0
> scanning bus 0 for devices... 1 USB Device(s) found
>scanning usb for storage devices... 0 Storage Device(s) found
> Hit any key to stop autoboot:  0
> 
> Signed-off-by: Jagan Teki 
> ---
>  arch/arm/dts/Makefile  |  3 +-
>  arch/arm/dts/sun50i-h5-orangepi-zero-plus2.dts | 93 
> ++
>  board/sunxi/MAINTAINERS|  5 ++
>  configs/orangepi_zero_plus2_defconfig  | 17 +
>  4 files changed, 117 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/dts/sun50i-h5-orangepi-zero-plus2.dts
>  create mode 100644 configs/orangepi_zero_plus2_defconfig
> 
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 54978cf..a59395b 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -316,7 +316,8 @@ dtb-$(CONFIG_MACH_SUN8I_V3S) += \
>   sun8i-v3s-licheepi-zero.dtb
>  dtb-$(CONFIG_MACH_SUN50I_H5) += \
>   sun50i-h5-orangepi-pc2.dtb \
> - sun50i-h5-orangepi-prime.dtb
> + sun50i-h5-orangepi-prime.dtb \
> + sun50i-h5-orangepi-zero-plus2.dtb
>  dtb-$(CONFIG_MACH_SUN50I) += \
>   sun50i-a64-orangepi-win.dtb \
>   sun50i-a64-pine64-plus.dtb \
> diff --git a/arch/arm/dts/sun50i-h5-orangepi-zero-plus2.dts 
> b/arch/arm/dts/sun50i-h5-orangepi-zero-plus2.dts
> new file mode 100644
> index 000..f17a7bb
> --- /dev/null
> +++ b/arch/arm/dts/sun50i-h5-orangepi-zero-plus2.dts
> @@ -0,0 +1,93 @@
> +/*
> + * Copyright (C) 2017 Jagan Teki 
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This library is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This library is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF 

Re: [U-Boot] [PATCH 2/5] arm64: dts: sun50i: Add sun50i-h5.dtsi

[André Przywara]

On 25/05/17 20:35, Jagan Teki wrote:
> From: Jagan Teki 
> 
> The Allwinner H5 SoC is pin-compatible to the H3 SoC,
> but uses Cortex-A53 cores instead.
> 
> So move the shared cpu based and peripherals nodes into
> sun50i-h5.dtsi so, that it can shared among the sun50i-h5
> board dts files.

That looks like another deviation from the Linux DTs, right?
Yesterdays I tried to update U-Boot with the Linux DTs, but this gets
nasty because of the entanglement with the H3 and the non-upstream
Ethernet support.
Following the new scheme we would need to have a ...-u-boot.dtsi with
the Ethernet nodes for *each* board, as some H3 boards use 100Mbit, some
have a Gbit PHY, so we can't use a single file to cover both.

Not sure if that means we use two .dtsi files and symbolic links or
whether we want to wait until we can have multiple, possibly shared
-u-boot.dtsi files to tackle this.

Cheers,
Andre.

> 
> Signed-off-by: Jagan Teki 
> ---
>  arch/arm/dts/sun50i-h5-orangepi-pc2.dts | 34 +-
>  arch/arm/dts/sun50i-h5.dtsi | 79 
> +
>  2 files changed, 80 insertions(+), 33 deletions(-)
>  create mode 100644 arch/arm/dts/sun50i-h5.dtsi
> 
> diff --git a/arch/arm/dts/sun50i-h5-orangepi-pc2.dts 
> b/arch/arm/dts/sun50i-h5-orangepi-pc2.dts
> index de60f78..81594e6 100644
> --- a/arch/arm/dts/sun50i-h5-orangepi-pc2.dts
> +++ b/arch/arm/dts/sun50i-h5-orangepi-pc2.dts
> @@ -42,40 +42,12 @@
>  
>  /dts-v1/;
>  
> -#include "sun8i-h3.dtsi"
> +#include "sun50i-h5.dtsi"
>  
>  / {
>   model = "OrangePi PC 2";
>   compatible = "xunlong,orangepi-pc-2", "allwinner,sun50i-h5";
>  
> - cpus {
> - cpu@0 {
> - compatible = "arm,cortex-a53", "arm,armv8";
> - enable-method = "psci";
> - };
> - cpu@1 {
> - compatible = "arm,cortex-a53", "arm,armv8";
> - enable-method = "psci";
> - };
> - cpu@2 {
> - compatible = "arm,cortex-a53", "arm,armv8";
> - enable-method = "psci";
> - };
> - cpu@3 {
> - compatible = "arm,cortex-a53", "arm,armv8";
> - enable-method = "psci";
> - };
> - };
> -
> - psci {
> - compatible = "arm,psci-0.2";
> - method = "smc";
> - };
> -
> - timer {
> - compatible = "arm,armv8-timer";
> - };
> -
>   chosen {
>   stdout-path = "serial0:115200n8";
>   };
> @@ -99,10 +71,6 @@
>   };
>  };
>  
> - {
> - compatible = "arm,gic-400";
> -};
> -
>   {
>   compatible = "allwinner,sun50i-h5-mmc",
>"allwinner,sun50i-a64-mmc",
> diff --git a/arch/arm/dts/sun50i-h5.dtsi b/arch/arm/dts/sun50i-h5.dtsi
> new file mode 100644
> index 000..df76a07
> --- /dev/null
> +++ b/arch/arm/dts/sun50i-h5.dtsi
> @@ -0,0 +1,79 @@
> +/*
> + * Copyright (c) 2016 ARM Ltd.
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This library is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This library is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + *  

Re: [U-Boot] [PATCH 1/5] sun50i: a64: Add initial Orangepi Win/WinPlus support

[André Przywara]

On 25/05/17 20:35, Jagan Teki wrote:
> From: Jagan Teki 
> 
> Orangepi Win/WinPlus is an open-source single-board computer
> using the Allwinner A64 SOC.
> 
> A64 Orangepi Win/WinPlus has
> - A64 Quad-core Cortex-A53 64bit
> - 1GB(Win)/2GB(Win Plus) DDR3 SDRAM
> - Debug TTL UART
> - Four USB 2.0
> - HDMI
> - LCD
> - Audio and MIC
> - Wifi + BT
> - IR receiver
> - 5V DC power supply
> 
> http://www.orangepi.org/OrangePiWin_WinPlus/

Do you have a link to some schematics?

> Boot from MMC:
> --
> U-Boot SPL 2017.05-00662-ga3f4c05-dirty (May 25 2017 - 13:32:53)
> DRAM: 1024 MiB
> Trying to boot from MMC1
> NOTICE:  BL3-1: Running on A64/H64 (1689) in SRAM A2 (@0x44000)
> NOTICE:  Configuring SPC Controller
> NOTICE:  BL3-1: v1.0(debug):aa75c8d
> NOTICE:  BL3-1: Built : 18:28:27, May 24 2017
> NOTICE:  Configuring AXP PMIC
> NOTICE:  PMIC: setup successful
> INFO:BL3-1: Initializing runtime services
> INFO:BL3-1: Preparing for EL3 exit to normal world
> INFO:BL3-1: Next image address: 0x4a00, SPSR: 0x3c9
> 
> U-Boot 2017.05-00662-ga3f4c05-dirty (May 25 2017 - 13:32:53 +) Allwinner 
> Technology
> 
> CPU:   Allwinner A64 (SUN50I)
> Model: OrangePi Win/Win Plus
> DRAM:  1 GiB
> MMC:   SUNXI SD/MMC: 0
> *** Warning - bad CRC, using default environment
> 
> In:serial
> Out:   serial
> Err:   serial
> Net:   No ethernet found.

Any reason you didn't enable this?
If you have applied my A64/Pine64 DT update (v3 is a single patch now),
you should copy the new sun50i-a64-pine64-plus-u-boot.dtsi to
sun50i-a64-orangepi-win-u-boot.dtsi, that should do the trick.
If the Ethernet uses another GPIO or AXP line to enable the PHY, let me
know.

> starting USB...
> USB0:   USB EHCI 1.00
> USB1:   USB OHCI 1.0
> scanning bus 0 for devices... 1 USB Device(s) found
>scanning usb for storage devices... 0 Storage Device(s) found
> Hit any key to stop autoboot:  0
> 
> Signed-off-by: Jagan Teki 
> ---
>  arch/arm/dts/Makefile|   1 +
>  arch/arm/dts/sun50i-a64-orangepi-win.dts | 102 
> +++

In general we might eventually want to wait what the discussion on the
Linux side ends up like, then copy this .dts file.

>  board/sunxi/MAINTAINERS  |   5 ++
>  configs/orangepi_win_defconfig   |  16 +
>  4 files changed, 124 insertions(+)
>  create mode 100644 arch/arm/dts/sun50i-a64-orangepi-win.dts
>  create mode 100644 configs/orangepi_win_defconfig
> 
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index a3bed3d..2251edf 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -317,6 +317,7 @@ dtb-$(CONFIG_MACH_SUN8I_V3S) += \
>  dtb-$(CONFIG_MACH_SUN50I_H5) += \
>   sun50i-h5-orangepi-pc2.dtb
>  dtb-$(CONFIG_MACH_SUN50I) += \
> + sun50i-a64-orangepi-win.dtb \
>   sun50i-a64-pine64-plus.dtb \
>   sun50i-a64-pine64.dtb
>  dtb-$(CONFIG_MACH_SUN9I) += \
> diff --git a/arch/arm/dts/sun50i-a64-orangepi-win.dts 
> b/arch/arm/dts/sun50i-a64-orangepi-win.dts
> new file mode 100644
> index 000..c1bfa88
> --- /dev/null
> +++ b/arch/arm/dts/sun50i-a64-orangepi-win.dts
> @@ -0,0 +1,102 @@
> +/*
> + * Copyright (C) 2017 Jagan Teki 
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This library is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This library is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR 

Re: [U-Boot] [PATCHv4 3/3] ARM64: poplar: hi3798cv200: u-boot support for Poplar 96Boards

[Tom Rini]

On Thu, May 25, 2017 at 03:21:04PM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On 25 May 2017 at 15:12, Tom Rini  wrote:
> > On Thu, May 25, 2017 at 10:58:20PM +0200, Jorge Ramirez wrote:
> >> On 05/25/2017 10:55 PM, Jorge Ramirez wrote:
> >> >On 05/25/2017 10:31 PM, Tom Rini wrote:
> >> >>On Thu, May 25, 2017 at 08:38:47PM +0200, Jorge Ramirez wrote:
> >> >>>On 05/18/2017 12:06 AM, Tom Rini wrote:
> >> >>>having platform data.
> >> >>No, I think we're going for overkill here by not doing
> >> >>serial_pl01x.c as
> >> >>platform data.  ns16550 does platform data for this already.  This
> >> >>sounds like the lowest overhead way to get the clock
> >> >>populated and not
> >> >>have some DT data that's not going to be accepted upstream.
> >> >>
> >> >u I am a bit lost at this point, could we recap please?
> >> Lets update the recap:
> >> - Please re-submit the dts file, now with whatever form is
> >> in v4.12-rc1,
> >>    saying as such in the commit (if it's just the commit message that
> >>    changes, that's fine and great).
> >> >>>The DTS file in v4.12-rc2 still does NOT contain the usb node.
> >> >>>
> >> >>>==> Should I then not use the DM on USB so I can avoid DTS changes?
> >> >>Well, you can either put it in the -u-boot.dtsi file for the board, and
> >> >>remove that later once it's upstream.
> >>
> >>
> >> yes I'll do that. thanks.
> >>
> >> >
> >> >>
> >> - Please update serial_pl01x.c to be able to get the clock
> >> via platform
> >>    data, update and test your board to confirm it works.
> >> >>>um, It gets tricky;
> >> >>>I can not use platform_data since I can not use SERIAL_DM because
> >> >>>the device tree does have a UART node which gets picked up.
> >> >>How about disabling the node in -u-boot.dtsi for the board and then you
> >> >>can use platform data,
> >> >
> >>
> >> I dont think that would because CONFIG_OF is enabled for USB; so the
> >> kernel dtsi that contains the uart node (without the clock!) will be
> >> picked by u-boot and the uart will not be initialized properly.
> >> I still think that the simplest solution is to let me merge with the
> >> kernel's device tree plus this u-boot.dtsi [1];
> >> then just get rid of the file when possible (and NEIHER the source
> >> code NOR the configs) would need to change
> >>
> >> [1] 
> >> https://github.com/ldts/poplar-u-boot/blob/upstream/arch/arm/dts/hi3798cv200-u-boot.dtsi
> >
> > Yes, sorry.  [1] needs to be updated to disable uart0 so that you can
> > use platform data, at least for now.  I do want to talk more with Rob
> > about the general problem this exposes.
> 
> Using platform data because we cannot put a clock frequency in the DT
> node seems unfortunate to me. With a little flexibility, DT can be
> made to work. But IMO the sort of pedantry makes great the enemy of
> good.

This, and the alias issue we talked about the other day (wrt mmc) do
highlight what I see as problems of the dts being too kernel-centric.
But I also really want to wait for Rob to chime in before we get too far
here.

-- 
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] [PATCHv4 3/3] ARM64: poplar: hi3798cv200: u-boot support for Poplar 96Boards

[Tom Rini]

On Thu, May 25, 2017 at 11:16:42PM +0200, Jorge Ramirez wrote:
> On 05/25/2017 11:12 PM, Tom Rini wrote:
> >On Thu, May 25, 2017 at 10:58:20PM +0200, Jorge Ramirez wrote:
> >>On 05/25/2017 10:55 PM, Jorge Ramirez wrote:
> >>>On 05/25/2017 10:31 PM, Tom Rini wrote:
> On Thu, May 25, 2017 at 08:38:47PM +0200, Jorge Ramirez wrote:
> >On 05/18/2017 12:06 AM, Tom Rini wrote:
> >having platform data.
> No, I think we're going for overkill here by not doing
> serial_pl01x.c as
> platform data.  ns16550 does platform data for this already.  This
> sounds like the lowest overhead way to get the clock
> populated and not
> have some DT data that's not going to be accepted upstream.
> 
> >>>u I am a bit lost at this point, could we recap please?
> >>Lets update the recap:
> >>- Please re-submit the dts file, now with whatever form is
> >>in v4.12-rc1,
> >>   saying as such in the commit (if it's just the commit message that
> >>   changes, that's fine and great).
> >The DTS file in v4.12-rc2 still does NOT contain the usb node.
> >
> >==> Should I then not use the DM on USB so I can avoid DTS changes?
> Well, you can either put it in the -u-boot.dtsi file for the board, and
> remove that later once it's upstream.
> >>
> >>yes I'll do that. thanks.
> >>
> >>- Please update serial_pl01x.c to be able to get the clock
> >>via platform
> >>   data, update and test your board to confirm it works.
> >um, It gets tricky;
> >I can not use platform_data since I can not use SERIAL_DM because
> >the device tree does have a UART node which gets picked up.
> How about disabling the node in -u-boot.dtsi for the board and then you
> can use platform data,
> >>I dont think that would because CONFIG_OF is enabled for USB; so the
> >>kernel dtsi that contains the uart node (without the clock!) will be
> >>picked by u-boot and the uart will not be initialized properly.
> >>I still think that the simplest solution is to let me merge with the
> >>kernel's device tree plus this u-boot.dtsi [1];
> >>then just get rid of the file when possible (and NEIHER the source
> >>code NOR the configs) would need to change
> >>
> >>[1] 
> >>https://github.com/ldts/poplar-u-boot/blob/upstream/arch/arm/dts/hi3798cv200-u-boot.dtsi
> >Yes, sorry.  [1] needs to be updated to disable uart0 so that you can
> >use platform data, at least for now.  I do want to talk more with Rob
> >about the general problem this exposes.
> 
> so you want me to
> 
> 1) keep the node in 
> https://github.com/ldts/poplar-u-boot/blob/upstream/arch/arm/dts/hi3798cv200-u-boot.dtsi

Well, a uart0 node, but no "clock" property as that just needs to go
away.

> 2) add status=disable
> 3) then add the platform_data
> 
> BUT for the pl011 driver to take the platform_data dont I also have
> to disable CONFIG_OF?
> 
> but  if I disable CONFIG_OF then I lose USB_DM

No, the status = "disable" on uart0 should remove it from the dtb, or at
least we should see it and go "Oh, no, we don't have uart0 via DT".

-- 
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] [PATCHv4 3/3] ARM64: poplar: hi3798cv200: u-boot support for Poplar 96Boards

[Simon Glass]

Hi Tom,

On 25 May 2017 at 15:12, Tom Rini  wrote:
> On Thu, May 25, 2017 at 10:58:20PM +0200, Jorge Ramirez wrote:
>> On 05/25/2017 10:55 PM, Jorge Ramirez wrote:
>> >On 05/25/2017 10:31 PM, Tom Rini wrote:
>> >>On Thu, May 25, 2017 at 08:38:47PM +0200, Jorge Ramirez wrote:
>> >>>On 05/18/2017 12:06 AM, Tom Rini wrote:
>> >>>having platform data.
>> >>No, I think we're going for overkill here by not doing
>> >>serial_pl01x.c as
>> >>platform data.  ns16550 does platform data for this already.  This
>> >>sounds like the lowest overhead way to get the clock
>> >>populated and not
>> >>have some DT data that's not going to be accepted upstream.
>> >>
>> >u I am a bit lost at this point, could we recap please?
>> Lets update the recap:
>> - Please re-submit the dts file, now with whatever form is
>> in v4.12-rc1,
>>    saying as such in the commit (if it's just the commit message that
>>    changes, that's fine and great).
>> >>>The DTS file in v4.12-rc2 still does NOT contain the usb node.
>> >>>
>> >>>==> Should I then not use the DM on USB so I can avoid DTS changes?
>> >>Well, you can either put it in the -u-boot.dtsi file for the board, and
>> >>remove that later once it's upstream.
>>
>>
>> yes I'll do that. thanks.
>>
>> >
>> >>
>> - Please update serial_pl01x.c to be able to get the clock
>> via platform
>>    data, update and test your board to confirm it works.
>> >>>um, It gets tricky;
>> >>>I can not use platform_data since I can not use SERIAL_DM because
>> >>>the device tree does have a UART node which gets picked up.
>> >>How about disabling the node in -u-boot.dtsi for the board and then you
>> >>can use platform data,
>> >
>>
>> I dont think that would because CONFIG_OF is enabled for USB; so the
>> kernel dtsi that contains the uart node (without the clock!) will be
>> picked by u-boot and the uart will not be initialized properly.
>> I still think that the simplest solution is to let me merge with the
>> kernel's device tree plus this u-boot.dtsi [1];
>> then just get rid of the file when possible (and NEIHER the source
>> code NOR the configs) would need to change
>>
>> [1] 
>> https://github.com/ldts/poplar-u-boot/blob/upstream/arch/arm/dts/hi3798cv200-u-boot.dtsi
>
> Yes, sorry.  [1] needs to be updated to disable uart0 so that you can
> use platform data, at least for now.  I do want to talk more with Rob
> about the general problem this exposes.

Using platform data because we cannot put a clock frequency in the DT
node seems unfortunate to me. With a little flexibility, DT can be
made to work. But IMO the sort of pedantry makes great the enemy of
good.

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

Re: [U-Boot] [PATCHv4 3/3] ARM64: poplar: hi3798cv200: u-boot support for Poplar 96Boards

[Jorge Ramirez]

On 05/25/2017 11:12 PM, Tom Rini wrote:

On Thu, May 25, 2017 at 10:58:20PM +0200, Jorge Ramirez wrote:

On 05/25/2017 10:55 PM, Jorge Ramirez wrote:

On 05/25/2017 10:31 PM, Tom Rini wrote:

On Thu, May 25, 2017 at 08:38:47PM +0200, Jorge Ramirez wrote:

On 05/18/2017 12:06 AM, Tom Rini wrote:

having platform data.

No, I think we're going for overkill here by not doing
serial_pl01x.c as
platform data.  ns16550 does platform data for this already.  This
sounds like the lowest overhead way to get the clock
populated and not
have some DT data that's not going to be accepted upstream.


u I am a bit lost at this point, could we recap please?

Lets update the recap:
- Please re-submit the dts file, now with whatever form is
in v4.12-rc1,
   saying as such in the commit (if it's just the commit message that
   changes, that's fine and great).

The DTS file in v4.12-rc2 still does NOT contain the usb node.

==> Should I then not use the DM on USB so I can avoid DTS changes?

Well, you can either put it in the -u-boot.dtsi file for the board, and
remove that later once it's upstream.


yes I'll do that. thanks.


- Please update serial_pl01x.c to be able to get the clock
via platform
   data, update and test your board to confirm it works.

um, It gets tricky;
I can not use platform_data since I can not use SERIAL_DM because
the device tree does have a UART node which gets picked up.

How about disabling the node in -u-boot.dtsi for the board and then you
can use platform data,

I dont think that would because CONFIG_OF is enabled for USB; so the
kernel dtsi that contains the uart node (without the clock!) will be
picked by u-boot and the uart will not be initialized properly.
I still think that the simplest solution is to let me merge with the
kernel's device tree plus this u-boot.dtsi [1];
then just get rid of the file when possible (and NEIHER the source
code NOR the configs) would need to change

[1] 
https://github.com/ldts/poplar-u-boot/blob/upstream/arch/arm/dts/hi3798cv200-u-boot.dtsi

Yes, sorry.  [1] needs to be updated to disable uart0 so that you can
use platform data, at least for now.  I do want to talk more with Rob
about the general problem this exposes.


so you want me to

1) keep the node in 
https://github.com/ldts/poplar-u-boot/blob/upstream/arch/arm/dts/hi3798cv200-u-boot.dtsi 


2) add status=disable
3) then add the platform_data

BUT for the pl011 driver to take the platform_data dont I also have to 
disable CONFIG_OF?


but  if I disable CONFIG_OF then I lose USB_DM

am I wrong?








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

Re: [U-Boot] [PATCHv4 3/3] ARM64: poplar: hi3798cv200: u-boot support for Poplar 96Boards

[Jorge Ramirez]

On 05/25/2017 10:55 PM, Jorge Ramirez wrote:

On 05/25/2017 10:31 PM, Tom Rini wrote:

On Thu, May 25, 2017 at 08:38:47PM +0200, Jorge Ramirez wrote:

On 05/18/2017 12:06 AM, Tom Rini wrote:

having platform data.
No, I think we're going for overkill here by not doing 
serial_pl01x.c as

platform data.  ns16550 does platform data for this already.  This
sounds like the lowest overhead way to get the clock populated 
and not

have some DT data that's not going to be accepted upstream.


u I am a bit lost at this point, could we recap please?

Lets update the recap:
- Please re-submit the dts file, now with whatever form is in 
v4.12-rc1,

   saying as such in the commit (if it's just the commit message that
   changes, that's fine and great).

The DTS file in v4.12-rc2 still does NOT contain the usb node.

==> Should I then not use the DM on USB so I can avoid DTS changes?

Well, you can either put it in the -u-boot.dtsi file for the board, and
remove that later once it's upstream. 



yes I'll do that. thanks.





- Please update serial_pl01x.c to be able to get the clock via 
platform

   data, update and test your board to confirm it works.

um, It gets tricky;
I can not use platform_data since I can not use SERIAL_DM because
the device tree does have a UART node which gets picked up.

How about disabling the node in -u-boot.dtsi for the board and then you
can use platform data,




I dont think that would because CONFIG_OF is enabled for USB; so the 
kernel dtsi that contains the uart node (without the clock!) will be 
picked by u-boot and the uart will not be initialized properly.
I still think that the simplest solution is to let me merge with the 
kernel's device tree plus this u-boot.dtsi [1];
then just get rid of the file when possible (and NEIHER the source code 
NOR the configs) would need to change


[1] 
https://github.com/ldts/poplar-u-boot/blob/upstream/arch/arm/dts/hi3798cv200-u-boot.dtsi 






I think...  But Rob, this loops us back around to
the first problem too, kind of.  Can we really just not make use of
clock-frequency and the kernel just not use it?





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

Re: [U-Boot] [PATCHv4 3/3] ARM64: poplar: hi3798cv200: u-boot support for Poplar 96Boards

[Jorge Ramirez]

On 05/25/2017 10:31 PM, Tom Rini wrote:

On Thu, May 25, 2017 at 08:38:47PM +0200, Jorge Ramirez wrote:

On 05/18/2017 12:06 AM, Tom Rini wrote:

having platform data.

No, I think we're going for overkill here by not doing serial_pl01x.c as
platform data.  ns16550 does platform data for this already.  This
sounds like the lowest overhead way to get the clock populated and not
have some DT data that's not going to be accepted upstream.


u I am a bit lost at this point, could we recap please?

Lets update the recap:
- Please re-submit the dts file, now with whatever form is in v4.12-rc1,
   saying as such in the commit (if it's just the commit message that
   changes, that's fine and great).

The DTS file in v4.12-rc2 still does NOT contain the usb node.

==> Should I then not use the DM on USB so I can avoid DTS changes?

Well, you can either put it in the -u-boot.dtsi file for the board, and
remove that later once it's upstream.


yes I'll do that. thanks.




- Please update serial_pl01x.c to be able to get the clock via platform
   data, update and test your board to confirm it works.

um, It gets tricky;
I can not use platform_data since I can not use SERIAL_DM because
the device tree does have a UART node which gets picked up.

How about disabling the node in -u-boot.dtsi for the board and then you
can use platform data,


I dont think that would because CONFIG_OF is enabled for USB
So the kernel dtsi (not the u-boot.dtsi) that contains the uart node 
(without the clock!) will be picked by uboot and the uart will not be 
initialized



I still think that the simplest solution is to let me merge with the 
kernel's device tree plus this u-boot.dtsi [1] and then just get rid of 
the file when possible (and the source code not the configs) would not 
need to change


https://github.com/ldts/poplar-u-boot/blob/upstream/arch/arm/dts/hi3798cv200-u-boot.dtsi 




I think...  But Rob, this loops us back around to
the first problem too, kind of.  Can we really just not make use of
clock-frequency and the kernel just not use it?



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

Re: [U-Boot] [PATCHv4 3/3] ARM64: poplar: hi3798cv200: u-boot support for Poplar 96Boards

[Tom Rini]

On Thu, May 25, 2017 at 08:38:47PM +0200, Jorge Ramirez wrote:
> On 05/18/2017 12:06 AM, Tom Rini wrote:
> having platform data.
> >>>No, I think we're going for overkill here by not doing serial_pl01x.c as
> >>>platform data.  ns16550 does platform data for this already.  This
> >>>sounds like the lowest overhead way to get the clock populated and not
> >>>have some DT data that's not going to be accepted upstream.
> >>>
> >>u I am a bit lost at this point, could we recap please?
> >Lets update the recap:
> >- Please re-submit the dts file, now with whatever form is in v4.12-rc1,
> >   saying as such in the commit (if it's just the commit message that
> >   changes, that's fine and great).
> 
> The DTS file in v4.12-rc2 still does NOT contain the usb node.
> 
> ==> Should I then not use the DM on USB so I can avoid DTS changes?

Well, you can either put it in the -u-boot.dtsi file for the board, and
remove that later once it's upstream.

> >- Please update serial_pl01x.c to be able to get the clock via platform
> >   data, update and test your board to confirm it works.
> 
> um, It gets tricky;
> I can not use platform_data since I can not use SERIAL_DM because
> the device tree does have a UART node which gets picked up.

How about disabling the node in -u-boot.dtsi for the board and then you
can use platform data, I think...  But Rob, this loops us back around to
the first problem too, kind of.  Can we really just not make use of
clock-frequency and the kernel just not use it?

-- 
Tom


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

[U-Boot] [PATCH 4/5] sun50i: h5: Add initial Orangepi Prime support

[Jagan Teki]

From: Jagan Teki 

Orangepi Prime is an open-source single-board computer
using the Allwinner h5 SOC.

H5 Orangepi Prime has
- Quad-core Cortex-A53
- 2GB DDR3
- Debug TTL UART
- 1000M/100M Ethernet RJ45
- Three USB 2.0
- HDMI
- Audio and MIC
- Wifi + BT
- IR receiver
- HDMI
- Wifi + BT

http://www.orangepi.org/OrangePiPrime/

Boot from MMC:
-
U-Boot SPL 2017.05-00662-ga3f4c05-dirty (May 25 2017 - 13:30:14)
DRAM: 2048 MiB
Trying to boot from MMC1
NOTICE:  BL3-1: Running on H5 (1718) in SRAM A2 (@0x44000)
NOTICE:  Configuring SPC Controller
NOTICE:  BL3-1: v1.0(debug):aa75c8d
NOTICE:  BL3-1: Built : 18:28:27, May 24 2017
INFO:BL3-1: Initializing runtime services
INFO:BL3-1: Preparing for EL3 exit to normal world
INFO:BL3-1: Next image address: 0x4a00, SPSR: 0x3c9

U-Boot 2017.05-00662-ga3f4c05-dirty (May 25 2017 - 13:30:14 +) Allwinner 
Technology

CPU:   Allwinner H5 (SUN50I)
Model: OrangePi Prime
DRAM:  2 GiB
MMC:   SUNXI SD/MMC: 0
*** Warning - bad CRC, using default environment

In:serial
Out:   serial
Err:   serial
Net:   phy interface7
eth0: ethernet@1c3
starting USB...
USB0:   USB EHCI 1.00
USB1:   USB OHCI 1.0
scanning bus 0 for devices... 1 USB Device(s) found
   scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  0

Signed-off-by: Jagan Teki 
---
 arch/arm/dts/Makefile |   3 +-
 arch/arm/dts/sun50i-h5-orangepi-prime.dts | 104 ++
 board/sunxi/MAINTAINERS   |   5 ++
 configs/orangepi_prime_defconfig  |  17 +
 4 files changed, 128 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/sun50i-h5-orangepi-prime.dts
 create mode 100644 configs/orangepi_prime_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 2251edf..54978cf 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -315,7 +315,8 @@ dtb-$(CONFIG_MACH_SUN8I_R40) += \
 dtb-$(CONFIG_MACH_SUN8I_V3S) += \
sun8i-v3s-licheepi-zero.dtb
 dtb-$(CONFIG_MACH_SUN50I_H5) += \
-   sun50i-h5-orangepi-pc2.dtb
+   sun50i-h5-orangepi-pc2.dtb \
+   sun50i-h5-orangepi-prime.dtb
 dtb-$(CONFIG_MACH_SUN50I) += \
sun50i-a64-orangepi-win.dtb \
sun50i-a64-pine64-plus.dtb \
diff --git a/arch/arm/dts/sun50i-h5-orangepi-prime.dts 
b/arch/arm/dts/sun50i-h5-orangepi-prime.dts
new file mode 100644
index 000..67eade7
--- /dev/null
+++ b/arch/arm/dts/sun50i-h5-orangepi-prime.dts
@@ -0,0 +1,104 @@
+/*
+ * Copyright (C) 2017 Jagan Teki 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "sun50i-h5.dtsi"
+
+#include 
+
+/ {
+   model = "OrangePi Prime";
+   compatible = "xunlong,orangepi-prime", "allwinner,sun50i-h5";
+
+   aliases {
+   serial0 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   memory {
+   reg = <0x4000 0x8000>;
+   };
+
+   soc 

[U-Boot] [PATCH 5/5] sun50i: h5: Add initial Orangepi Zero Plus 2 support

[Jagan Teki]

From: Jagan Teki 

Orangepi Zero Plus 2 is an open-source single-board computer
using the Allwinner h5 SOC.

H5 Orangepi Zero Plus 2 has
- Quad-core Cortex-A53
- 512MB DDR3
- Debug TTL UART
- HDMI
- Wifi + BT
- OTG+power supply

http://www.orangepi.org/OrangePiZeroPlus2/

Boot from MMC:
--
U-Boot SPL 2017.05-00663-g51233ac-dirty (May 25 2017 - 16:18:41)
DRAM: 512 MiB
Trying to boot from MMC1
NOTICE:  BL3-1: Running on H5 (1718) in SRAM A2 (@0x44000)
NOTICE:  Configuring SPC Controller
NOTICE:  BL3-1: v1.0(debug):aa75c8d
NOTICE:  BL3-1: Built : 18:28:27, May 24 2017
INFO:BL3-1: Initializing runtime services
INFO:BL3-1: Preparing for EL3 exit to normal world
INFO:BL3-1: Next image address: 0x4a00, SPSR: 0x3c9

U-Boot 2017.05-00663-g51233ac-dirty (May 25 2017 - 16:18:41 +) Allwinner 
Technology

CPU:   Allwinner H5 (SUN50I)
Model: OrangePi Zero Plus2
DRAM:  512 MiB
MMC:   SUNXI SD/MMC: 0
*** Warning - bad CRC, using default environment

In:serial
Out:   serial
Err:   serial
Net:   phy interface7
eth0: ethernet@1c3
starting USB...
USB0:   USB EHCI 1.00
USB1:   USB OHCI 1.0
scanning bus 0 for devices... 1 USB Device(s) found
   scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  0

Signed-off-by: Jagan Teki 
---
 arch/arm/dts/Makefile  |  3 +-
 arch/arm/dts/sun50i-h5-orangepi-zero-plus2.dts | 93 ++
 board/sunxi/MAINTAINERS|  5 ++
 configs/orangepi_zero_plus2_defconfig  | 17 +
 4 files changed, 117 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/sun50i-h5-orangepi-zero-plus2.dts
 create mode 100644 configs/orangepi_zero_plus2_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 54978cf..a59395b 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -316,7 +316,8 @@ dtb-$(CONFIG_MACH_SUN8I_V3S) += \
sun8i-v3s-licheepi-zero.dtb
 dtb-$(CONFIG_MACH_SUN50I_H5) += \
sun50i-h5-orangepi-pc2.dtb \
-   sun50i-h5-orangepi-prime.dtb
+   sun50i-h5-orangepi-prime.dtb \
+   sun50i-h5-orangepi-zero-plus2.dtb
 dtb-$(CONFIG_MACH_SUN50I) += \
sun50i-a64-orangepi-win.dtb \
sun50i-a64-pine64-plus.dtb \
diff --git a/arch/arm/dts/sun50i-h5-orangepi-zero-plus2.dts 
b/arch/arm/dts/sun50i-h5-orangepi-zero-plus2.dts
new file mode 100644
index 000..f17a7bb
--- /dev/null
+++ b/arch/arm/dts/sun50i-h5-orangepi-zero-plus2.dts
@@ -0,0 +1,93 @@
+/*
+ * Copyright (C) 2017 Jagan Teki 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "sun50i-h5.dtsi"
+
+#include 
+
+
+/ {
+   model = "OrangePi Zero Plus2";
+   compatible = "xunlong,orangepi-zero-plus2", "allwinner,sun50i-h5";
+
+   aliases {
+   serial0 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   memory {
+   reg = <0x4000 0x2000>;
+   };
+

[U-Boot] [PATCH 3/5] arm64: dts: sun50i: h5: orangepi-pc2: Use GPIO flag binding macro

[Jagan Teki]

From: Jagan Teki 

Instead of defining numerical value on GPIO flag
better to use existing binding macro.

Signed-off-by: Jagan Teki 
---
 arch/arm/dts/sun50i-h5-orangepi-pc2.dts | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/dts/sun50i-h5-orangepi-pc2.dts 
b/arch/arm/dts/sun50i-h5-orangepi-pc2.dts
index 81594e6..780d59a 100644
--- a/arch/arm/dts/sun50i-h5-orangepi-pc2.dts
+++ b/arch/arm/dts/sun50i-h5-orangepi-pc2.dts
@@ -44,6 +44,8 @@
 
 #include "sun50i-h5.dtsi"
 
+#include 
+
 / {
model = "OrangePi PC 2";
compatible = "xunlong,orangepi-pc-2", "allwinner,sun50i-h5";
@@ -79,7 +81,7 @@
pinctrl-0 = <_pins_a>, <_cd_pin>;
vmmc-supply = <_vcc3v3>;
bus-width = <4>;
-   cd-gpios = < 5 6 0>;
+   cd-gpios = < 5 6 GPIO_ACTIVE_HIGH>;
cd-inverted;
status = "okay";
 };
-- 
2.7.4

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

[U-Boot] [PATCH 2/5] arm64: dts: sun50i: Add sun50i-h5.dtsi

[Jagan Teki]

From: Jagan Teki 

The Allwinner H5 SoC is pin-compatible to the H3 SoC,
but uses Cortex-A53 cores instead.

So move the shared cpu based and peripherals nodes into
sun50i-h5.dtsi so, that it can shared among the sun50i-h5
board dts files.

Signed-off-by: Jagan Teki 
---
 arch/arm/dts/sun50i-h5-orangepi-pc2.dts | 34 +-
 arch/arm/dts/sun50i-h5.dtsi | 79 +
 2 files changed, 80 insertions(+), 33 deletions(-)
 create mode 100644 arch/arm/dts/sun50i-h5.dtsi

diff --git a/arch/arm/dts/sun50i-h5-orangepi-pc2.dts 
b/arch/arm/dts/sun50i-h5-orangepi-pc2.dts
index de60f78..81594e6 100644
--- a/arch/arm/dts/sun50i-h5-orangepi-pc2.dts
+++ b/arch/arm/dts/sun50i-h5-orangepi-pc2.dts
@@ -42,40 +42,12 @@
 
 /dts-v1/;
 
-#include "sun8i-h3.dtsi"
+#include "sun50i-h5.dtsi"
 
 / {
model = "OrangePi PC 2";
compatible = "xunlong,orangepi-pc-2", "allwinner,sun50i-h5";
 
-   cpus {
-   cpu@0 {
-   compatible = "arm,cortex-a53", "arm,armv8";
-   enable-method = "psci";
-   };
-   cpu@1 {
-   compatible = "arm,cortex-a53", "arm,armv8";
-   enable-method = "psci";
-   };
-   cpu@2 {
-   compatible = "arm,cortex-a53", "arm,armv8";
-   enable-method = "psci";
-   };
-   cpu@3 {
-   compatible = "arm,cortex-a53", "arm,armv8";
-   enable-method = "psci";
-   };
-   };
-
-   psci {
-   compatible = "arm,psci-0.2";
-   method = "smc";
-   };
-
-   timer {
-   compatible = "arm,armv8-timer";
-   };
-
chosen {
stdout-path = "serial0:115200n8";
};
@@ -99,10 +71,6 @@
};
 };
 
- {
-   compatible = "arm,gic-400";
-};
-
  {
compatible = "allwinner,sun50i-h5-mmc",
 "allwinner,sun50i-a64-mmc",
diff --git a/arch/arm/dts/sun50i-h5.dtsi b/arch/arm/dts/sun50i-h5.dtsi
new file mode 100644
index 000..df76a07
--- /dev/null
+++ b/arch/arm/dts/sun50i-h5.dtsi
@@ -0,0 +1,79 @@
+/*
+ * Copyright (c) 2016 ARM Ltd.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "sun8i-h3.dtsi"
+
+/ {
+   cpus {
+   cpu@0 {
+   compatible = "arm,cortex-a53", "arm,armv8";
+   enable-method = "psci";
+   };
+   cpu@1 {
+   compatible = "arm,cortex-a53", "arm,armv8";
+   enable-method = "psci";
+   };
+   cpu@2 {
+   compatible = "arm,cortex-a53", "arm,armv8";
+   enable-method = "psci";
+   };
+   cpu@3 {
+   compatible = "arm,cortex-a53", "arm,armv8";
+   enable-method = "psci";
+   };
+   };

[U-Boot] [PATCH 1/5] sun50i: a64: Add initial Orangepi Win/WinPlus support

[Jagan Teki]

From: Jagan Teki 

Orangepi Win/WinPlus is an open-source single-board computer
using the Allwinner A64 SOC.

A64 Orangepi Win/WinPlus has
- A64 Quad-core Cortex-A53 64bit
- 1GB(Win)/2GB(Win Plus) DDR3 SDRAM
- Debug TTL UART
- Four USB 2.0
- HDMI
- LCD
- Audio and MIC
- Wifi + BT
- IR receiver
- 5V DC power supply

http://www.orangepi.org/OrangePiWin_WinPlus/

Boot from MMC:
--
U-Boot SPL 2017.05-00662-ga3f4c05-dirty (May 25 2017 - 13:32:53)
DRAM: 1024 MiB
Trying to boot from MMC1
NOTICE:  BL3-1: Running on A64/H64 (1689) in SRAM A2 (@0x44000)
NOTICE:  Configuring SPC Controller
NOTICE:  BL3-1: v1.0(debug):aa75c8d
NOTICE:  BL3-1: Built : 18:28:27, May 24 2017
NOTICE:  Configuring AXP PMIC
NOTICE:  PMIC: setup successful
INFO:BL3-1: Initializing runtime services
INFO:BL3-1: Preparing for EL3 exit to normal world
INFO:BL3-1: Next image address: 0x4a00, SPSR: 0x3c9

U-Boot 2017.05-00662-ga3f4c05-dirty (May 25 2017 - 13:32:53 +) Allwinner 
Technology

CPU:   Allwinner A64 (SUN50I)
Model: OrangePi Win/Win Plus
DRAM:  1 GiB
MMC:   SUNXI SD/MMC: 0
*** Warning - bad CRC, using default environment

In:serial
Out:   serial
Err:   serial
Net:   No ethernet found.
starting USB...
USB0:   USB EHCI 1.00
USB1:   USB OHCI 1.0
scanning bus 0 for devices... 1 USB Device(s) found
   scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  0

Signed-off-by: Jagan Teki 
---
 arch/arm/dts/Makefile|   1 +
 arch/arm/dts/sun50i-a64-orangepi-win.dts | 102 +++
 board/sunxi/MAINTAINERS  |   5 ++
 configs/orangepi_win_defconfig   |  16 +
 4 files changed, 124 insertions(+)
 create mode 100644 arch/arm/dts/sun50i-a64-orangepi-win.dts
 create mode 100644 configs/orangepi_win_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index a3bed3d..2251edf 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -317,6 +317,7 @@ dtb-$(CONFIG_MACH_SUN8I_V3S) += \
 dtb-$(CONFIG_MACH_SUN50I_H5) += \
sun50i-h5-orangepi-pc2.dtb
 dtb-$(CONFIG_MACH_SUN50I) += \
+   sun50i-a64-orangepi-win.dtb \
sun50i-a64-pine64-plus.dtb \
sun50i-a64-pine64.dtb
 dtb-$(CONFIG_MACH_SUN9I) += \
diff --git a/arch/arm/dts/sun50i-a64-orangepi-win.dts 
b/arch/arm/dts/sun50i-a64-orangepi-win.dts
new file mode 100644
index 000..c1bfa88
--- /dev/null
+++ b/arch/arm/dts/sun50i-a64-orangepi-win.dts
@@ -0,0 +1,102 @@
+/*
+ * Copyright (C) 2017 Jagan Teki 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "sun50i-a64.dtsi"
+
+#include 
+
+/ {
+   model = "OrangePi Win/Win Plus";
+   compatible = "xunlong,orangepi-win", "allwinner,sun50i-a64";
+
+   aliases {
+   serial0 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   soc {
+   reg_vcc3v3: vcc3v3 {
+   compatible = 

[U-Boot] [PATCH 0/5] sun50i: a64/h5: Add orangepi boards

[Jagan Teki]

From: Jagan Teki 

This series add Allwinner Cortex A-53 boards from OrangePI.
- Orangepi Win/WinPlus
- Orangepi Prime
- Orangepi Zero Plus 2 

thanks!
Jagan.

Jagan Teki (5):
  sun50i: a64: Add initial Orangepi Win/WinPlus support
  arm64: dts: sun50i: Add sun50i-h5.dtsi
  arm64: dts: sun50i: h5: orangepi-pc2: Use GPIO flag binding macro
  sun50i: h5: Add initial Orangepi Prime support
  sun50i: h5: Add initial Orangepi Zero Plus 2 support

 arch/arm/dts/Makefile  |   5 +-
 arch/arm/dts/sun50i-a64-orangepi-win.dts   | 102 
 arch/arm/dts/sun50i-h5-orangepi-pc2.dts|  38 +
 arch/arm/dts/sun50i-h5-orangepi-prime.dts  | 104 +
 arch/arm/dts/sun50i-h5-orangepi-zero-plus2.dts |  93 ++
 arch/arm/dts/sun50i-h5.dtsi|  79 +++
 board/sunxi/MAINTAINERS|  15 
 configs/orangepi_prime_defconfig   |  17 
 configs/orangepi_win_defconfig |  16 
 configs/orangepi_zero_plus2_defconfig  |  17 
 10 files changed, 451 insertions(+), 35 deletions(-)
 create mode 100644 arch/arm/dts/sun50i-a64-orangepi-win.dts
 create mode 100644 arch/arm/dts/sun50i-h5-orangepi-prime.dts
 create mode 100644 arch/arm/dts/sun50i-h5-orangepi-zero-plus2.dts
 create mode 100644 arch/arm/dts/sun50i-h5.dtsi
 create mode 100644 configs/orangepi_prime_defconfig
 create mode 100644 configs/orangepi_win_defconfig
 create mode 100644 configs/orangepi_zero_plus2_defconfig

-- 
2.7.4

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

Re: [U-Boot] [PATCHv4 3/3] ARM64: poplar: hi3798cv200: u-boot support for Poplar 96Boards

[Jorge Ramirez]

On 05/18/2017 12:06 AM, Tom Rini wrote:

having platform data.

No, I think we're going for overkill here by not doing serial_pl01x.c as
platform data.  ns16550 does platform data for this already.  This
sounds like the lowest overhead way to get the clock populated and not
have some DT data that's not going to be accepted upstream.


u I am a bit lost at this point, could we recap please?

Lets update the recap:
- Please re-submit the dts file, now with whatever form is in v4.12-rc1,
   saying as such in the commit (if it's just the commit message that
   changes, that's fine and great).


The DTS file in v4.12-rc2 still does NOT contain the usb node.

==> Should I then not use the DM on USB so I can avoid DTS changes?



- Please update serial_pl01x.c to be able to get the clock via platform
   data, update and test your board to confirm it works.


um, It gets tricky;
I can not use platform_data since I can not use SERIAL_DM because the 
device tree does have a UART node which gets picked up.


I will have to disable DM_SERIAL and add some configs in 
include/configs/poplar.h


+#define CONFIG_PL011_SERIAL  1
+#define CONFIG_PL011_CLOCK   7500
+#define CONFIG_PL01x_PORTS   {(void *) 0xF8B0,}
+#define CONFIG_CONS_INDEX0

==> is this acceptable? if not, then what should I do?


- It'd be awesome if you do, but it won't block your series if you
   don't, update the rest of the platforms that had been using the
   "clock" platform to instead use the platform data method.

Thanks!


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

Re: [U-Boot] [PATCH] arm: Always keep the dtb section on objcopy

[Tom Rini]

On Thu, May 25, 2017 at 07:23:58PM +0300, Pantelis Antoniou wrote:

> The dtb blob section must always be present in the resulting image.
> Either if OF_EMBEDED is used or if unit tests include dtb blobs.
> 
> Signed-off-by: Pantelis Antoniou 

Reviewed-by: Tom Rini 

-- 
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 08/14] usb: dwc3: Add helper functions to enable snooping and burst settings

[york sun]

On 05/17/2017 07:01 AM, yinbo.zhu wrote:
> From: Rajat Srivastava 
> 
> Adds helper functions to enable snooping and outstanding burst beat
> settings.
> 
> Signed-off-by: Rajat Srivastava 
> Signed-off-by: Rajesh Bhagat 
> ---
>   drivers/usb/dwc3/core.c | 45 +
>   drivers/usb/dwc3/core.h |  7 +++
>   2 files changed, 52 insertions(+)
> 

Yinbo,

You were posting multiple times for the same patch. You got comment on 
the other thread http://patchwork.ozlabs.org/patch/762973/. Please split 
this set to separate the SoC errata patches (first 7).

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

Re: [U-Boot] Please pull u-boot-fdt, take 2

[Tom Rini]

On Thu, May 25, 2017 at 11:27:10AM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On 25 May 2017 at 05:19, Tom Rini  wrote:
> >
> > On Wed, May 24, 2017 at 06:15:25PM -0600, Simon Glass wrote:
> >
> > > Hi Tom,
> > >
> > > This incorporates the v2 patch for 'fdt: Build the new python libfdt
> > > module' which should fix the problem with the original pull request.
> > >
> > >
> > > The following changes since commit 
> > > be62fbf376261ab3a4ed5db3bf54d5df9e216d9f:
> > >
> > >   Merge branch 'rmobile' of git://git.denx.de/u-boot-sh (2017-05-23
> > > 16:22:03 -0400)
> > >
> > > are available in the git repository at:
> > >
> > >   git://git.denx.de/u-boot-fdt.git
> > >
> > > for you to fetch changes up to da9c601049eb7c993c7f6e33ae10af7a847a483d:
> > >
> > >   fdt: Drop fdt_select.py (2017-05-24 18:12:31 -0600)
> >
> > NAK.  travis-ci blows up quite badly:
> > https://travis-ci.org/trini/u-boot/builds/235861889
> 
> I'm not sure how to repeat this problem. When I try this:

Your best bet is likely:
https://docs.travis-ci.com/user/common-build-problems/#Troubleshooting-Locally-in-a-Docker-Image

-- 
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-fdt, take 2

[Simon Glass]

Hi Tom,

On 25 May 2017 at 05:19, Tom Rini  wrote:
>
> On Wed, May 24, 2017 at 06:15:25PM -0600, Simon Glass wrote:
>
> > Hi Tom,
> >
> > This incorporates the v2 patch for 'fdt: Build the new python libfdt
> > module' which should fix the problem with the original pull request.
> >
> >
> > The following changes since commit be62fbf376261ab3a4ed5db3bf54d5df9e216d9f:
> >
> >   Merge branch 'rmobile' of git://git.denx.de/u-boot-sh (2017-05-23
> > 16:22:03 -0400)
> >
> > are available in the git repository at:
> >
> >   git://git.denx.de/u-boot-fdt.git
> >
> > for you to fetch changes up to da9c601049eb7c993c7f6e33ae10af7a847a483d:
> >
> >   fdt: Drop fdt_select.py (2017-05-24 18:12:31 -0600)
>
> NAK.  travis-ci blows up quite badly:
> https://travis-ci.org/trini/u-boot/builds/235861889

I'm not sure how to repeat this problem. When I try this:

buildman -P boston32r2el

I don't see any errors.

This looks like what the test is running. Any ideas what I am missing?

I wonder if the environment is missing something, or has something
extra, with respect to python-dev, etc.?

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

Re: [U-Boot] [PATCH] Add support for Microchip LAN75xx and LAN78xx

[Joe Hershberger]

On Wed, May 10, 2017 at 10:25 AM,   wrote:
> From: Yuiko Oshino 
>>-Original Message-
>>From: Joe Hershberger [mailto:joe.hershber...@gmail.com]
>>Sent: Friday, May 5, 2017 4:59 PM
>>To: Yuiko Oshino - C18177
>>Cc: u-boot; Marek Vasut
>>Subject: Re: [U-Boot] [PATCH] Add support for Microchip LAN75xx and
>>LAN78xx
>>
>>Hi Yuiko,
>
> Hi Joe!
>
> [...]
>
>>> +static int lan75xx_phy_gig_workaround(struct usb_device *udev,
>>> + struct ueth_data *dev)
>>> +{
>>> +   int ret = 0;
>>> +
>>> +   /* Only internal phy */
>>> +   /* Set the phy in Gig loopback */
>>> +   lan7x_mdio_write(udev, dev->phy_id, MII_BMCR,
>>> +(BMCR_LOOPBACK | BMCR_SPEED1000));
>>> +
>>> +   /* Wait for the link up */
>>> +   ret = lan7x_mdio_wait_for_bit(udev, "BMSR_LSTATUS",
>>> + dev->phy_id, MII_BMSR, BMSR_LSTATUS,
>>> + true, PHY_CONNECT_TIMEOUT_MS);
>>> +   if (ret)
>>> +   return ret;
>>> +
>>> +   /* phy reset */
>>> +   ret = lan7x_pmt_phy_reset(udev, dev);
>>> +   return ret;
>>
>>Just return lan7x_pmt_phy_reset(udev, dev);
>
> Sure thing.
>
>>
>>> +}
>>> +
>>> +static int lan75xx_update_flowcontrol(struct usb_device *udev,
>>> + struct ueth_data *dev)
>>> +{
>>> +   uint32_t flow = 0, fct_flow = 0;
>>> +   int ret;
>>> +
>>> +   ret = lan7x_update_flowcontrol(udev, dev, , _flow);
>>> +   if (ret)
>>> +   return ret;
>>> +
>>> +   ret = lan7x_write_reg(udev, FLOW, flow);
>>
>>   if (ret)
>>  return ret;
>>
>>> +   ret = lan7x_write_reg(udev, LAN75XX_FCT_FLOW, fct_flow);
>>> +   return ret;
>>
>>Return directly
>
> OK.
>
> [...]
>
>>> +
>>> +static int lan75xx_set_multicast(struct usb_device *udev)
>>> +{
>>> +   int ret;
>>> +   u32 write_buf;
>>> +
>>> +   /* No multicast in u-boot */
>>
>>May want to... will enable IPv6 later.
>
> Yes, later.
>
>>
>>> +   write_buf = RFE_CTL_BCAST_EN | RFE_CTL_DA_PERFECT;
>>> +   ret = lan7x_write_reg(udev, LAN75XX_RFE_CTL, write_buf);
>>> +
>>> +   return ret;
>>> +}
>>> +
>>> +/* starts the TX path */
>>> +static void lan75xx_start_tx_path(struct usb_device *udev)
>>> +{
>>> +   u32 reg_val;
>>> +
>>> +   /* Enable Tx at MAC */
>>> +   reg_val = MAC_TX_TXEN;
>>
>>Why not just pass it into the function directly? Applies globally when
>>the assignment is a single mask.
>
> True. I will take care of them.
>
>>
>>> +   lan7x_write_reg(udev, MAC_TX, reg_val);
>>> +
>>> +   /* Enable Tx at SCSRs */
>>> +   reg_val = FCT_TX_CTL_EN;
>>> +   lan7x_write_reg(udev, LAN75XX_FCT_TX_CTL, reg_val);
>>> +}
>>> +
>
> [...]
>
>>> +static int lan75xx_eth_probe(struct udevice *dev)
>>> +{
>>> +   struct usb_device *udev = dev_get_parent_priv(dev);
>>> +   struct lan7x_private *priv = dev_get_priv(dev);
>>> +   struct ueth_data *ueth = >ueth;
>>> +   struct eth_pdata *pdata = dev_get_platdata(dev);
>>> +
>>> +   /* Do a reset in order to get the MAC address from HW */
>>> +   if (lan75xx_basic_reset(udev, ueth, priv))
>>> +   return 0;
>>> +
>>> +   /* Get the MAC address */
>>> +   /*
>>> +* We must set the eth->enetaddr from HW because the upper layer
>>> +* will force to use the environmental var (usbethaddr) or random if
>>> +* there is no valid MAC address in eth->enetaddr.
>>> +*/
>>> +   lan75xx_read_mac(pdata->enetaddr, udev);
>>> +   /* Do not return 0 for not finding MAC addr in HW */
>>> +
>>> +   return usb_ether_register(dev, ueth, RX_URB_SIZE);
>>> +}
>>
>>I agree that these can all be squashed to remove non-DM support and
>>move all of the common functions up into these DM functions.
>>
> I will try to clean them.
>
> [...]
>
>>> +/*
>>> + * Lan78xx infrastructure commands
>>> + */
>>> +static int lan78xx_read_raw_otp(struct usb_device *udev, u32 offset,
>>> +   u32 length, u8 *data)
>>> +{
>>> +   int i;
>>> +   int ret;
>>> +   u32 buf;
>>> +
>>> +   ret = lan7x_read_reg(udev, LAN78XX_OTP_PWR_DN, );
>>> +   if (ret)
>>> +   return ret;
>>> +
>>> +   if (buf & LAN78XX_OTP_PWR_DN_PWRDN_N) {
>>> +   /* clear it and wait to be cleared */
>>> +   ret = lan7x_write_reg(udev, LAN78XX_OTP_PWR_DN, 0);
>>
>>Either you don't care about the ret value, in which case why is there
>>one, or you are losing it by overwriting it on the next call. You
>>should probably be checking it after every assignment. Applies
>>globally.
>>
>
> True also. I will take care of them.
>
>>> +   ret = lan7x_wait_for_bit(udev,
>>"LAN78XX_OTP_PWR_DN_PWRDN_N",
>>> +LAN78XX_OTP_PWR_DN,
>>> +

[U-Boot] [PATCH] arm: Always keep the dtb section on objcopy

[Pantelis Antoniou]

The dtb blob section must always be present in the resulting image.
Either if OF_EMBEDED is used or if unit tests include dtb blobs.

Signed-off-by: Pantelis Antoniou 
---
 arch/arm/config.mk | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm/config.mk b/arch/arm/config.mk
index a5eebb9..1a9 100644
--- a/arch/arm/config.mk
+++ b/arch/arm/config.mk
@@ -142,9 +142,11 @@ OBJCOPYFLAGS += -j .text -j .secure_text -j .secure_data 
-j .rodata -j .hash \
-j .data -j .got -j .got.plt -j .u_boot_list -j .rel.dyn
 endif
 
-ifdef CONFIG_OF_EMBED
+# if a dtb section exists we always have to include it
+# there are only two cases where it is generated
+# 1) OF_EMBEDED is turned on
+# 2) unit tests include device tree blobs
 OBJCOPYFLAGS += -j .dtb.init.rodata
-endif
 
 ifdef CONFIG_EFI_LOADER
 OBJCOPYFLAGS += -j .efi_runtime -j .efi_runtime_rel
-- 
2.1.4

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

[U-Boot] [PATCH] malloc: Turn on DEBUG when enabling unit tests

[Pantelis Antoniou]

Unit tests require mallinfo which in turn requires DEBUG on
dlmalloc to be enabled.

The dependancy on CONFIG_SANDBOX is wrong.

Signed-off-by: Pantelis Antoniou 
---
 common/dlmalloc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/common/dlmalloc.c b/common/dlmalloc.c
index adc680e..fc1e8b3 100644
--- a/common/dlmalloc.c
+++ b/common/dlmalloc.c
@@ -1,6 +1,6 @@
 #include 
 
-#ifdef CONFIG_SANDBOX
+#if defined(CONFIG_UNIT_TEST)
 #define DEBUG
 #endif
 
-- 
2.1.4

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

Re: [U-Boot] [PATCHv4 3/3] ARM64: poplar: hi3798cv200: u-boot support for Poplar 96Boards

[Andreas Färber]

Am 08.05.2017 um 18:36 schrieb Jorge Ramirez-Ortiz:
> This port adds support for:
> 1) Serial
> 2) eMMC
> 3) USB
> 
> It has been tested with ARM TRUSTED FIRMWARE running u-boot as the
> BL33 executable [see board's README]
> 
> eMMC has been tested for reading and booting the loader[1] and linux
> kernels as well as saving the u-boot environment.
> 
> USB has been tested with ASIX networking adapter and SanDisk 7.4GB
> drive.
> 
> PSCI has been tested via the reset call.
> 
> The firwmare upgrade process has been tested via TFTP and USB FAT
> filesystem containing the fastboot.bin image in one of the partitions.
> 
> Signed-off-by: Jorge Ramirez-Ortiz 
> ---
>  arch/arm/Kconfig   |  12 ++
>  arch/arm/dts/hi3798cv200.dtsi  |   3 +
>  arch/arm/dts/poplar-uboot.dtsi |  24 +++
>  arch/arm/include/asm/arch-hi3798cv200/dwmmc.h  |  13 ++
>  .../arm/include/asm/arch-hi3798cv200/hi3798cv200.h |  50 +
>  board/hisilicon/poplar/Kconfig |  15 ++
>  board/hisilicon/poplar/MAINTAINERS |   6 +
>  board/hisilicon/poplar/Makefile|   7 +
>  board/hisilicon/poplar/README  | 232 
> +
>  board/hisilicon/poplar/poplar.c| 155 ++
>  configs/poplar_defconfig   |  26 +++
>  include/configs/poplar.h   |  86 
>  12 files changed, 629 insertions(+)
>  create mode 100644 arch/arm/dts/poplar-uboot.dtsi
>  create mode 100644 arch/arm/include/asm/arch-hi3798cv200/dwmmc.h
>  create mode 100644 arch/arm/include/asm/arch-hi3798cv200/hi3798cv200.h
>  create mode 100644 board/hisilicon/poplar/Kconfig
>  create mode 100644 board/hisilicon/poplar/MAINTAINERS
>  create mode 100644 board/hisilicon/poplar/Makefile
>  create mode 100644 board/hisilicon/poplar/README
>  create mode 100644 board/hisilicon/poplar/poplar.c
>  create mode 100644 configs/poplar_defconfig
>  create mode 100644 include/configs/poplar.h

Wende an: ARM64: poplar: hi3798cv200: u-boot support for Poplar 96Boards
.git/rebase-apply/patch:237: trailing whitespace.
DRAM DDR3/3L/4 SDRAM interface, maximum 32-bit data width 2 GB
.git/rebase-apply/patch:66: new blank line at EOF.
+
.git/rebase-apply/patch:96: new blank line at EOF.
+
.git/rebase-apply/patch:616: new blank line at EOF.
+
.git/rebase-apply/patch:648: new blank line at EOF.
+
warning: 5 Zeilen fügen Whitespace-Fehler hinzu.

Please address the whitespace warnings.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3] LS2080A: Adjust memory map for secure boot headers for NOR-boot

[york sun]

On 05/02/2017 05:16 AM, Udit Agarwal wrote:
> This patch adjusts memory map for secure boot headers on LS2080AQDS
> and LS2080ARDB platforms.
>
> Secure boot headers are placed on NOR flash at offset 0x0060.
>
> Signed-off-by: Udit Agarwal 
> ---
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.ozlabs.org%2Fpatch%2F756222%2F=01%7C01%7Cyork.sun%40nxp.com%7C4e232d5f8dc840678c6508d49154fc6e%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0=%2F24KZSQmFPgDKMXGn%2FFN1proLxz5jJb0PwBJUa4PbXc%3D=0
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.ozlabs.org%2Fpatch%2F756221%2F=01%7C01%7Cyork.sun%40nxp.com%7C4e232d5f8dc840678c6508d49154fc6e%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0=KYe3oxt56jKRG3FqIuB%2BVeR59cYj7TEJdHPt%2F1pZLfI%3D=0
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.ozlabs.org%2Fpatch%2F756250%2F=01%7C01%7Cyork.sun%40nxp.com%7C4e232d5f8dc840678c6508d49154fc6e%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0=4crHHfSCgpHTj3n%2BmyVhyb53ioD5WkQNue4c1wmaDnY%3D=0
>
>  board/freescale/ls2080aqds/README |  1 +
>  board/freescale/ls2080ardb/README |  1 +
>  include/configs/ls2080aqds.h  | 10 +-
>  include/configs/ls2080ardb.h  | 10 +-
>  4 files changed, 12 insertions(+), 10 deletions(-)
>

Applied to fsl-qoriq master, awaiting upstream. Thanks.

York

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

Re: [U-Boot] [PATCH v2 2/3] armv8: layerscape: Adjust memory mapping for Flash/SD card on LS1043A

[york sun]

On 05/15/2017 08:01 PM, Alison Wang wrote:
> This patch is to adjust the memory mapping for FLash/SD card on
> LS1043AQDS and LS1043ARDB, such as PPA firmware load address, FMAN
> firmware load address, QE firmware load address, U-Boot start address on
> serial flash and environment address.
>
> Signed-off-by: Alison Wang 
> ---
> Changes:
> - Update the comments.
>
>  arch/arm/cpu/armv8/fsl-layerscape/Kconfig |  8 
>  include/configs/ls1043a_common.h  | 12 ++--
>  include/configs/ls1043aqds.h  | 10 +-
>  include/configs/ls1043ardb.h  |  8 
>  4 files changed, 19 insertions(+), 19 deletions(-)

Reformatted commit message. Applied to fsl-qoriq master, awaiting 
upstream. Thanks.

York

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

Re: [U-Boot] [PATCH v3 3/3] armv8: layerscape: Adjust memory mapping for Flash/SD card on LS1046A

[york sun]

On 05/15/2017 08:01 PM, Alison Wang wrote:
> This patch is to adjust the memory mapping for FLash/SD card on
> LS1046AQDS and LS1046ARDB, such as FMAN firmware load address, U-Boot
> start address on serial flash and environment address.
>
> Signed-off-by: Alison Wang 
> ---
> Changes:
> - Update the comments and README.
>
>  board/freescale/ls1046ardb/README | 16 
>  include/configs/ls1046a_common.h  | 10 +-
>  include/configs/ls1046aqds.h  | 10 +-
>  include/configs/ls1046ardb.h  |  4 ++--
>  4 files changed, 20 insertions(+), 20 deletions(-)

Applied to fsl-qoriq master, awaiting upstream. Thanks.

York

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

Re: [U-Boot] [PATCH 1/2][v2] armv8: fsl-layerscape: Add NXP LS2081A, LS2041A SoC support

[york sun]

On 04/27/2017 02:38 AM, Priyanka Jain wrote:
> The QorIQ LS2081A SoC has eight 64-bit ARM v8 Cortex A-72 CPUs and
> is built on layerscape architecture.
>
> It is 40-pin derivative of LS2084A (non-AIOP personality of LS2088A).
> So feature-wise it is same as LS2084A.
>
> LS2081A has one more similar personality which
> has four CPUs: LS2041A
>
> Signed-off-by: Priyanka Jain 
> Signed-off-by: Santan Kumar 
> ---
>  Changes for v2: Uddated copyright

Reformatted commit message. Applied to fsl-qoriq master, awaiting 
upstream. Thanks.

York

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

Re: [U-Boot] [PATCH][v2] board: ls2080ardb, ls2080aqds: Adjust memory map for NOR-boot

[york sun]

On 04/28/2017 12:14 AM, Santan Kumar wrote:
> This patch adjusts memory map for images on LS2080ARDB,
> LS2080AQDS as per below memory map for NOR flash:
> Image Flash Offset
> RCW+PBI   0x
> Boot firmware (U-Boot)0x0010
> Boot firmware Environment 0x0030
> PPA firmware  0x0040
> PHY firmware  0x0098
> DPAA2 MC  0x00A0
> DPAA2 DPL 0x00D0
> DPAA2 DPC 0x00E0
> Kernel.itb0x0100
>
> Signed-off-by: Santan Kumar 
> Signed-off-by: Priyanka Jain 
> ---
> Changes for v2:
>  1. Rebase on the top of Priyanka's QSPI patch
>   
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.ozlabs.org%2Fpatch%2F756222%2F=01%7C01%7Cyork.sun%40nxp.com%7Cf48a7f1714bf492e3b7708d48e064619%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0=HiqkWpMouHRUJJGF%2BQ%2F27yQ2tkoaGGJkiGcfiJFHrxI%3D=0


Applied to fsl-qoriq master, awaiting upstream. Thanks.

York

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

Re: [U-Boot] [PATCH 2/2][v7] nxp/ls2080ardb: Add QSPI-boot support

[york sun]

On 04/27/2017 10:11 PM, Priyanka Jain wrote:
> QSPI-boot is verified on LS2088ARDB RevF board
> with LS2088A SoC.
> LS2088ARDB RevF Board has limitation that QIXIS
> can not be access, so QIXIS flag is kept disabled
>
> Signed-off-by: Priyanka Jain 
> Signed-off-by: Suresh Gupta 
> ---
> Changes for v7:
>   Updated NXP copyright
>   Removed CONFIG_SPI_FLASH_BAR
>
> Changes for v6:
>   Updated MAINTAINERS for ls2088ardb_qspi_defconfig
>
> Changes for v5: Renamed defconfig to ls2088ardb_qspi_defconfig
>  and incorporated other review comments
>
>  Changes for v4: Updated copyright
>  Changes for v3: Updated README
>
>  Changes for v2: Incorporated Sun York's comments
>Introduced another patch to update qixis related code
>

Fixed subject tag. Reformatted commit message. Applied to fsl-qoriq 
master, awaiting upstream. Thanks.

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

Re: [U-Boot] [PATCH 2/2][v2] board: ls2080ardb: Add LS2081ARDB board support

[york sun]

On 04/27/2017 02:38 AM, Priyanka Jain wrote:
> LS2081ARDB board is similar to LS2080ARDB board
> with few differences like
>  It hosts LS2081A SoC
>  Default boot source is QSPI-boot
>  It does not have IFC interface
>  RTC and QSPI flash device are different
>  It provides QIXIS access via I2C
>
> Signed-off-by: Priyanka Jain 
> Signed-off-by: Santan Kumar 
> ---
> Depends on
>   
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.ozlabs.org%2Fpatch%2F755824%2F=01%7C01%7Cyork.sun%40nxp.com%7C42e54d83e9c34ac471d708d48d51265b%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0=VNu6NPCk%2BaR5gllkg1ejWKQl7x986%2Fi%2Bo8wFtg2YzI8%3D=0
>   
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.ozlabs.org%2Fpatch%2F755823%2F=01%7C01%7Cyork.sun%40nxp.com%7C42e54d83e9c34ac471d708d48d51265b%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0=hnAbsz0jkoihjCPTJh1CwcOdDOVSgt88HVItq%2B7zEbw%3D=0
>   
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.ozlabs.org%2Fpatch%2F754576%2F=01%7C01%7Cyork.sun%40nxp.com%7C42e54d83e9c34ac471d708d48d51265b%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0=r3K9i5caRimJyIvX3kpV2miCiFVSFLDiPdhhaPwERPQ%3D=0
>
> Changes for v2: Rebased on top of Depends on patches

Minor adjustment to commit message. Applied to fsl-qoriq master, 
awaiting upstream. Thanks.

York

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

Re: [U-Boot] [PATCH v2 1/3] arm: ls1021a: Adjust memory mapping for Flash/SD card on LS1021AQDS/TWR

[york sun]

On 05/15/2017 08:01 PM, Alison Wang wrote:
> This patch is to adjust the memory mapping for FLash/SD card on LS1021AQDS
> and LS1021ATWR, such as U-Boot start address on serial Flash, QE firmware
> load address and environment address.
>
> Signed-off-by: Alison Wang 
> ---
> Changes:
> - None
>
>  include/configs/ls1021aqds.h | 10 +-
>  include/configs/ls1021atwr.h | 10 +-
>  2 files changed, 10 insertions(+), 10 deletions(-)

Reformatted commit message to wrap back at or before 70 characters. 
Applied to fsl-qoriq master, awaiting upstream. Thanks.

York

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

Re: [U-Boot] [PATCH 1/2][v7] board: freescale: ls2080ardb: Update QIXIS code

[york sun]

On 04/27/2017 10:11 PM, Priyanka Jain wrote:
> Update QIXIS related code to be executed
> only if CONFIG_FSL_QIXIS flag is enabled
>
> As per board documentation, default sysclk is 100MHz.
> In case QIXIS code is not enabled,
> update default sysclk value to 100MHz
>
> Signed-off-by: Priyanka Jain 
> ---
>  Changes for v4:
>   Added changes for default sysclk as 100MHz
>
>  board/freescale/ls2080ardb/ls2080ardb.c |   21 +
>  1 files changed, 17 insertions(+), 4 deletions(-)

Reformatted commit message. Applied to fsl-qoriq master, awaiting upstream.

York

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

Re: [U-Boot] [PATCH][v3] driver: net: fsl-mc: Update fsl_mc_ldpaa_exit() path

[york sun]

On 04/26/2017 09:44 PM, Yogesh Gaur wrote:
> Earlier when MC is loaded but DPL is not deployed results in FDT fix-up
> code execution hang.
> For this case now print message on console and returns success instead of
> return -ENODEV.
> This update allows to continue fdt fixup execution.
>
> Signed-off-by: Yogesh Gaur 
> Signed-off-by: Priyanka Jain 
> ---
> Changes for v3:
>  Incorporated York's review comments.
>
>  drivers/net/fsl-mc/mc.c | 20 +---
>  1 file changed, 13 insertions(+), 7 deletions(-)

Reformatted commit message. Applied to fsl-qoriq master, awaiting 
upstream. Thanks.

York

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

Re: [U-Boot] [PATCH] LS1012A: change the size of flash

[york sun]

On 05/23/2017 10:52 PM, Suresh Gupta wrote:
> 
> 
>> -Original Message-
>> From: york sun
>> Sent: Tuesday, May 23, 2017 9:50 PM
>> To: Suresh Gupta ; u-boot@lists.denx.de
>> Cc: ja...@openedev.com
>> Subject: Re: [PATCH] LS1012A: change the size of flash
>>
>> On 04/25/2017 02:20 AM, Suresh Gupta wrote:
>>> LS1012A has S25FS512S flash of 64M size
>>>
>>> Signed-off-by: Suresh Gupta 
>>> ---
>>>   include/configs/ls1012a_common.h | 2 +-
>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/include/configs/ls1012a_common.h
>>> b/include/configs/ls1012a_common.h
>>> index 0db926f..861cbc3 100644
>>> --- a/include/configs/ls1012a_common.h
>>> +++ b/include/configs/ls1012a_common.h
>>> @@ -56,7 +56,7 @@
>>>   #define QSPI0_AMBA_BASE   0x4000
>>>   #define CONFIG_SPI_FLASH_SPANSION
>>>
>>> -#define FSL_QSPI_FLASH_SIZE(1 << 24)
>>> +#define FSL_QSPI_FLASH_SIZESZ_64M
>>>   #define FSL_QSPI_FLASH_NUM2
>>>
>>>   /*
>>>
>>
>> Suresh,
>>
>> LS1012A doesn't have any flash built-in. Do you mean all boards supporting
>> LS1012A have the same flash chip with 64MB in size? Please clarify.
>>
>> York
> York,
> You are right, all boards has 64MB (S25FS512S) flash.
> Sorry for confusion.
> 

Changed subject to "armv8: ls1012a: fix the size of flash for multiple 
boards". Revise commit message to "LS1012AFRDM, LS1012ARDB, LS1012AQDS 
all have S25FS512S flash of 64MB size."

Applied to fsl-qoriq master, awaiting upstream. Thanks.

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

Re: [U-Boot] [PATCH 2/2] armv8: ls1043ardb: Make NET independent of FMan

[york sun]

On 04/25/2017 08:40 AM, York Sun wrote:
> This allows using PCIe NIC without enabling DPAA FMan.
>
> Signed-off-by: York Sun 
> CC: Mingkai Hu 
> ---
>  board/freescale/ls1043ardb/Makefile |  2 +-
>  include/configs/ls1043ardb.h| 13 -
>  2 files changed, 9 insertions(+), 6 deletions(-)

Applied to fsl-qoriq master, awaiting upstream.

York

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

Re: [U-Boot] [PATCH][v2] board: freescale: ls2080ardb: Enable SD interface for RevF board

[york sun]

On 04/24/2017 09:42 PM, Priyanka Jain wrote:
> LS2080ARDB/LS2088ARDB RevF board has smart voltage translator
> which needs to be programmed to enable high speed SD interface
> by setting GPIO4_10 output to zero
>
> Signed-off-by: Priyanka Jain 
> Signed-off-by: Santan Kumar 
> ---
> Changes for v2:
>  Added NXP copyright
>
>  .../include/asm/arch-fsl-layerscape/immap_lsch3.h  |4 
>  board/freescale/ls2080ardb/ls2080ardb.c|   18 ++
>  2 files changed, 22 insertions(+), 0 deletions(-)

Applied to fsl-qoriq master, awaiting upstream. Thanks.

York

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

Re: [U-Boot] [PATCH 1/2] armv8: ls1046ardb: Make NET independent of FMan

[york sun]

On 04/25/2017 08:40 AM, York Sun wrote:
> This allows using PCIe NIC without enabling DPAA FMan.
>
> Signed-off-by: York Sun 
> CC: Mingkai Hu 
> ---
>  board/freescale/ls1046ardb/Makefile |  2 +-
>  include/configs/ls1046ardb.h| 15 +--
>  2 files changed, 10 insertions(+), 7 deletions(-)

Applied to fsl-qoriq master, awaiting upstream.

York

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

Re: [U-Boot] [PATCH] config: remove CONFIG_SPI_FLASH_BAR from some platforms

[york sun]

On 04/25/2017 02:20 AM, Suresh Gupta wrote:
> ls1012ardb, ls1046ardb, ls2080ardb has S25FS512S
> flash which do not support Bank Address Register commands
>
> Signed-off-by: Suresh Gupta 
> ---
>  include/configs/ls1012a_common.h | 1 -
>  include/configs/ls1046ardb.h | 1 -
>  include/configs/ls2080ardb.h | 1 -
>  3 files changed, 3 deletions(-)

Changed subject tag to armv8: layerscape:.
Fixed grammar error in commit message.
Applied to fsl-qoriq master, awaiting upstream. Thanks.

York

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

Re: [U-Boot] [PATCH] armv8: ls1046a: enable PCI command tool

[york sun]

On 04/14/2017 02:03 AM, Zhiqiang Hou wrote:
> From: Hou Zhiqiang 
>
> Signed-off-by: Hou Zhiqiang 
> ---
>  include/configs/ls1046a_common.h | 10 ++
>  1 file changed, 10 insertions(+)
>

Applied to fsl-qoriq master, awaiting upstream. Thanks.

York

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

[U-Boot] Please pull fsl-qoriq master

[york sun]

Tom,

The following changes since commit 22f3368e71321db1e0e15dfbf54b052367890ec7:

   Merge branch 'master' of git://git.denx.de/u-boot-mips (2017-05-13 
16:45:35 -0400)

are available in the git repository at:

   git://git.denx.de/u-boot-fsl-qoriq.git

for you to fetch changes up to 7676074ac756ab9566d52544cc836f7b93f80b37:

   armv8: LS2080A: Adjust memory map for secure boot headers for 
NOR-boot (2017-05-23 09:59:14 -0700)


Alison Wang (3):
   arm: ls1021a: Adjust memory mapping for Flash/SD card on 
LS1021AQDS/TWR
   armv8: layerscape: Adjust memory mapping for Flash/SD card on LS1043A
   armv8: layerscape: Adjust memory mapping for Flash/SD card on LS1046A

Hou Zhiqiang (1):
   armv8: ls1046a: enable PCI command tool

Priyanka Jain (5):
   board: freescale: ls2080ardb: Enable SD interface for RevF board
   board: freescale: ls2080ardb: Update QIXIS code
   armv8: ls2080ardb: Add QSPI-boot support
   armv8: fsl-layerscape: Add NXP LS2081A, LS2041A SoC support
   armv8: ls2080ardb: Add LS2081ARDB board support

Santan Kumar (1):
   armv8: ls2080ardb, ls2080aqds: Adjust memory map for NOR-boot

Suresh Gupta (2):
   armv8: layperscape: remove CONFIG_SPI_FLASH_BAR from some platforms
   armv8: ls1012a: fix the size of flash for multiple boards

Udit Agarwal (1):
   armv8: LS2080A: Adjust memory map for secure boot headers for 
NOR-boot

Yogesh Gaur (1):
   driver: net: fsl-mc: Update fsl_mc_ldpaa_exit() path

York Sun (2):
   armv8: ls1046ardb: Make NET independent of FMan
   armv8: ls1043ardb: Make NET independent of FMan

  arch/arm/Kconfig   |  14 +++
  arch/arm/cpu/armv8/Kconfig |   1 +
  arch/arm/cpu/armv8/fsl-layerscape/Kconfig  |  11 ++-
  arch/arm/cpu/armv8/fsl-layerscape/cpu.c|   4 +-
  arch/arm/cpu/armv8/fsl-layerscape/doc/README.soc   |  11 +++
  arch/arm/dts/Makefile  |   4 +-
  arch/arm/dts/fsl-ls2081a-rdb.dts   |  59 
  arch/arm/dts/fsl-ls2088a-rdb-qspi.dts  |  59 
  arch/arm/include/asm/arch-fsl-layerscape/cpu.h |   3 +
  .../include/asm/arch-fsl-layerscape/immap_lsch3.h  |   4 +
  arch/arm/include/asm/arch-fsl-layerscape/soc.h |   3 +
  board/freescale/ls1043ardb/Makefile|   2 +-
  board/freescale/ls1046ardb/Makefile|   2 +-
  board/freescale/ls1046ardb/README  |  16 ++--
  board/freescale/ls2080aqds/README  |  13 +++
  board/freescale/ls2080ardb/Kconfig |  18 
  board/freescale/ls2080ardb/MAINTAINERS |  10 ++
  board/freescale/ls2080ardb/README  |  60 +++-
  board/freescale/ls2080ardb/ls2080ardb.c|  91 
+-
  configs/ls2081ardb_defconfig   |  46 +
  configs/ls2088ardb_qspi_defconfig  |  46 +
  drivers/net/fsl-mc/mc.c|  20 ++--
  drivers/pci/pcie_layerscape.c  |   7 +-
  drivers/pci/pcie_layerscape.h  |   3 +
  drivers/pci/pcie_layerscape_fixup.c|   7 +-
  drivers/usb/host/xhci-fsl.c|   3 +-
  include/configs/ls1012a_common.h   |   3 +-
  include/configs/ls1021aqds.h   |  10 +-
  include/configs/ls1021atwr.h   |  10 +-
  include/configs/ls1043a_common.h   |  12 +--
  include/configs/ls1043aqds.h   |  10 +-
  include/configs/ls1043ardb.h   |  21 +++--
  include/configs/ls1046a_common.h   |  20 +++-
  include/configs/ls1046aqds.h   |  10 +-
  include/configs/ls1046ardb.h   |  20 ++--
  include/configs/ls2080a_common.h   |  15 ++-
  include/configs/ls2080aqds.h   |  27 +++---
  include/configs/ls2080ardb.h   | 104 
++---
  38 files changed, 657 insertions(+), 122 deletions(-)
  create mode 100644 arch/arm/dts/fsl-ls2081a-rdb.dts
  create mode 100644 arch/arm/dts/fsl-ls2088a-rdb-qspi.dts
  create mode 100644 configs/ls2081ardb_defconfig
  create mode 100644 configs/ls2088ardb_qspi_defconfig

Thanks.

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

Re: [U-Boot] [PATCH 17/22] mmc: Add a execute_tuning() callback to the mmc operations.

[Jean-Jacques Hiblot]

On 25/05/2017 14:37, Jaehoon Chung wrote:

On 05/13/2017 03:16 AM, Jean-Jacques Hiblot wrote:

Tuning is a mandatory step in the initialization of SDR104 and HS200 modes.
This callback execute the tuning process.

Signed-off-by: Jean-Jacques Hiblot 
---
  drivers/mmc/mmc-uclass.c | 14 ++
  drivers/mmc/mmc.c|  5 +
  include/mmc.h| 12 
  3 files changed, 31 insertions(+)

diff --git a/drivers/mmc/mmc-uclass.c b/drivers/mmc/mmc-uclass.c
index e1f7995..b7433cf 100644
--- a/drivers/mmc/mmc-uclass.c
+++ b/drivers/mmc/mmc-uclass.c
@@ -93,6 +93,20 @@ int mmc_getcd(struct mmc *mmc)
  {
return dm_mmc_get_cd(mmc->dev);
  }
+
+int dm_mmc_execute_tuning(struct udevice *dev, uint opcode)
+{
+   struct dm_mmc_ops *ops = mmc_get_ops(dev);
+
+   if (!ops->execute_tuning)
+   return -ENOSYS;
+   return ops->execute_tuning(dev, opcode);
+}
+
+int mmc_execute_tuning(struct mmc *mmc, uint opcode)
+{
+   return dm_mmc_execute_tuning(mmc->dev, opcode);
+}
  #endif
  
  struct mmc *mmc_get_mmc_dev(struct udevice *dev)

diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 415484e..d7d1c91 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -219,6 +219,11 @@ int mmc_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd, 
struct mmc_data *data)
  
  	return ret;

  }
+
+int mmc_execute_tuning(struct mmc *mmc, uint opcode)
+{
+   return mmc->cfg->ops->execute_tuning(mmc, opcode);

Doesn't need to check about execute_tuing callback function?

Yes it should. However this has been removed for v2. Simon pointed out 
that new features should support only the driver model.

+}
  #endif
  
  int mmc_send_status(struct mmc *mmc, int timeout)

diff --git a/include/mmc.h b/include/mmc.h
index 097a685..dab68c5 100644
--- a/include/mmc.h
+++ b/include/mmc.h
@@ -375,6 +375,15 @@ struct dm_mmc_ops {
 * @return 0 if write-enabled, 1 if write-protected, -ve on error
 */
int (*get_wp)(struct udevice *dev);
+
+   /**
+* execute_tuning() - Start the tuning process
+*
+* @dev:Device to start the tuning
+* @opcode: Command opcode to send
+* @return 0 if OK, -ve on error
+*/
+   int (*execute_tuning)(struct udevice *dev, uint opcode);
  };
  
  #define mmc_get_ops(dev)((struct dm_mmc_ops *)(dev)->driver->ops)

@@ -385,12 +394,14 @@ int dm_mmc_set_ios(struct udevice *dev);
  int dm_mmc_set_vdd(struct udevice *dev, bool enable);
  int dm_mmc_get_cd(struct udevice *dev);
  int dm_mmc_get_wp(struct udevice *dev);
+int dm_mmc_execute_tuning(struct udevice *dev, uint opcode);
  
  /* Transition functions for compatibility */

  int mmc_set_ios(struct mmc *mmc);
  int mmc_set_vdd(struct mmc *mmc, bool enable);
  int mmc_getcd(struct mmc *mmc);
  int mmc_getwp(struct mmc *mmc);
+int mmc_execute_tuning(struct mmc *mmc, uint opcode);
  
  #else

  struct mmc_ops {
@@ -401,6 +412,7 @@ struct mmc_ops {
int (*set_vdd)(struct mmc *mmc, bool enable);
int (*getcd)(struct mmc *mmc);
int (*getwp)(struct mmc *mmc);
+   int (*execute_tuning)(struct mmc *mmc, uint opcode);
  };
  #endif
  





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

Re: [U-Boot] [PATCH 14/22] mmc: add power cyle support in mmc core

[Jean-Jacques Hiblot]

On 25/05/2017 14:35, Jaehoon Chung wrote:

On 05/13/2017 03:16 AM, Jean-Jacques Hiblot wrote:

mmc/sd specification requires vdd to be disabled for 1 ms
and then enabled again during power cycle. Add a
function in mmc core to perform power cycle and set
the io signal to it's initial state.

Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Jean-Jacques Hiblot 
---
  drivers/mmc/mmc.c | 50 +-
  1 file changed, 41 insertions(+), 9 deletions(-)

diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index d40a22b..032260b 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -30,6 +30,7 @@ static const unsigned int sd_au_size[] = {
SZ_16M / 512,   (SZ_16M + SZ_8M) / 512, SZ_32M / 512,   SZ_64M / 512,
  };
  static int mmc_set_signal_voltage(struct mmc *mmc, uint signal_voltage);
+static void mmc_power_cycle(struct mmc *mmc);
  
  #if CONFIG_IS_ENABLED(MMC_TINY)

  static struct mmc mmc_static;
@@ -1915,6 +1916,45 @@ static int mmc_power_init(struct mmc *mmc)
return 0;
  }
  
+static void mmc_set_initial_state(struct mmc *mmc)

+{
+   int err;
+
+   /* First try to set 3.3V. If it fails set to 1.8V */
+   err = mmc_set_signal_voltage(mmc, MMC_SIGNAL_VOLTAGE_330);
+   if (err != 0)
+   err = mmc_set_signal_voltage(mmc, MMC_SIGNAL_VOLTAGE_180);
+   if (err != 0)
+   printf("failed to set signal voltage\n");
+
+   mmc_set_bus_width(mmc, 1);
+   mmc_set_clock(mmc, 1);
+   mmc_select_mode(mmc, MMC_LEGACY);
+}
+
+static void mmc_power_up(struct mmc *mmc)
+{
+   mmc_set_initial_state(mmc);
+   mmc_set_vdd(mmc, true);

mmc_set_vdd has the return value..but there are no usage anywhere..
if this is correct, mmc_set_vdd can be *void* type.

OK. i'll change it in v2.



+   udelay(1);
+}
+
+static void mmc_power_off(struct mmc *mmc)
+{
+   mmc_set_vdd(mmc, false);
+}
+
+static void mmc_power_cycle(struct mmc *mmc)
+{
+   mmc_power_off(mmc);
+   /*
+* SD spec recommends at least 1ms of delay. Let's wait for 2ms
+* to be on the safer side.
+*/

Could you put the SD spec version and about which part...?
I didn't find the 2ms so..i want to see the spec about 2ms.
I need to figure this out. I forgot to mention it, but all this code is 
based on the work of Kishon Vijay Abraham who did the hs200 support for 
the ti u-boot tree.


Kishon,

can you point to the relevant part of the spec ?



+   udelay(2000);
+   mmc_power_up(mmc);
+}
+
  int mmc_start_init(struct mmc *mmc)
  {
bool no_card;
@@ -1952,16 +1992,8 @@ int mmc_start_init(struct mmc *mmc)
return err;
  #endif
mmc->ddr_mode = 0;
-   mmc_set_vdd(mmc, true);
-   /* First try to set 3.3V. If it fails set to 1.8V */
-   err = mmc_set_signal_voltage(mmc, MMC_SIGNAL_VOLTAGE_330);
-   if (err != 0)
-   err = mmc_set_signal_voltage(mmc, MMC_SIGNAL_VOLTAGE_180);
-   if (err != 0)
-   printf("failed to set signal voltage\n");
  
-	mmc_set_bus_width(mmc, 1);

-   mmc_set_clock(mmc, 1);
+   mmc_power_cycle(mmc);
  
  	/* Reset the Card */

err = mmc_go_idle(mmc);





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

Re: [U-Boot] [PATCH 00/22] mmc: Add support for HS200 and UHS modes

[Jean-Jacques Hiblot]

On 25/05/2017 09:41, Jaehoon Chung wrote:

Hi,

On 05/24/2017 12:24 AM, Jean-Jacques Hiblot wrote:

Hi,


On 18/05/2017 06:27, Jaehoon Chung wrote:

Hi,

On 05/13/2017 03:16 AM, Jean-Jacques Hiblot wrote:

This series brings support for HS200 and UHS modes to the mmc core.
It has been tested with the hsmmc driver on several platforms (DRA7,
AM57x, AM437x, beaglebone black). Some modifications are required in
the host driver to take advantage of this (voltage switching, tuning).
The changes to the host driver will be posted a another series as this
one is already long enough.

The series starts with a small refactoring of th sd/mmc startup. The first 4 
commits
are mostly moving code around with little or no functionnal change.

Then the notion of "mode" is introduced. Until now, this information wasn't
kept in struct mmc. Only the clock and a flag for ddr was kept. Later the mode
information will be used to select the clock frequency, the ddr flag and the
tuning procedure. It will be also be check against the host capabilities.

Then comes the big refactoring job in:
"mmc: refactor MMC startup to make it easier to support new modes" and
"mmc: refactor SD startup to make it easier to support new modes"
Since the number of modes is increasing, it makes sense to try them in a more
organized way. those commits use a list of supported modes and iterate through
them to find the best working one. It also allows to switch more easilly from
one mode to another (switching from HS200 to DDR52 to access boot partitions 
for example)

Then there are a couple of new callback added to:
- enable/disable Vdd
- check if the card is busy (used during UHS voltage switching)
- select the IO voltage

Then Power cycle is added. Without power cycle, if a UHS card fails to 
enumerate in
UHS mode, it can't fall back to high speed mode and card enumeration will fail.

And finally the last commits add the support for HS200 and UHS.
I haven't been able to test the UHS SDR104 mode by lack of compatible sdcard.

After testing my targets, some boards don't work fine..So i'm checking this 
problem..

Jaehoon,

what kind of issues are you running into and on what platforms ?
So far, besides the items brought-up by the reviews, there are 2 issues that 
are in the pipe for the next version:
  * signal voltage selection is not done for the MMCs only for SDs.
  * I noticed a timing constraint in voltage selection for SDs that can be a 
problem when trying a UHS mode with some SDs (seen only with Sandisk Ultra  
64Gb micro SD class I) :  the voltage must be switched quickly after the cmd 
SWITCH_UHS18V has been sent, making debug messages in that context a problem. 
With this SD I've been able to check that SDR104 is working.

How about making the "testing-hs200-uhs" branch for this? It needs to test 
more..

Sure. It seems a good idea.

I guess my target doesn't do the voltage change..i'm doing for ufs driver on 
u-boot in my local..
So i didn't see fully..today i have a free time..So i'm doing full review other 
thing..and about pending patches.

Thanks for waiting me.. :)

Best Regards,
Jaehoon Chung


Jean-Jacques

With this in place and the required changes in the HSMMC (including DAM), we 
observe significant
improvements in the performances on a DRA7 evm:
eMMC HS200: 130 MB/s
eMMC DDR52: 80 MB/s
sd   SDR50: 80 MB/s

cheers,

Jean-Jacques


Jean-Jacques Hiblot (18):
mmc: split mmc_startup()
mmc: move the MMC startup for version above v4.0 in a separate
  function
mmc: make ext_csd part of struct mmc
mmc: add a function to read and test the ext csd (mmc >= 4)
mmc: introduces mmc modes.
mmc: Add a fonction to dump the mmc capabilities
mmc: use mmc modes to select the correct bus speed
cmd: mmc: display the mode name and current bus speed in the mmc info
mmc: refactor SD startup to make it easier to support new modes
mmc: refactor MMC startup to make it easier to support new modes
mmc: make mmc_set_ios() return status
mmc: add power cyle support in mmc core
mmc: add a new mmc parameter to disable mmc clock
mmc: Add a execute_tuning() callback to the mmc operations.
mmc: add HS200 support in MMC core
mmc: Add a new callback function to check if the card is busy
mmc: Add support for UHS modes
mmc: Change mode when switching to a boot partition

Kishon Vijay Abraham I (3):
mmc: Enable signal voltage to be selected from mmc core
mmc: Add a new callback function to enable/disable vdd
mmc: disable the mmc clock during power off

Vignesh R (1):
mmc: Retry some MMC cmds on failure

   cmd/mmc.c|3 +-
   drivers/mmc/fsl_esdhc.c  |2 +-
   drivers/mmc/mmc-uclass.c |   42 ++
   drivers/mmc/mmc.c| 1220 
+-
   include/mmc.h|  138 +-
   5 files changed, 1058 insertions(+), 347 deletions(-)









___
U-Boot mailing list

Re: [U-Boot] [PATCH] board: ti: am571-idx: Add vcores support

[Tom Rini]

On Thu, May 25, 2017 at 03:37:34PM +0530, Keerthy wrote:

> Update vcores for am571-idk board.
> 
> Reported-by: Steve Kipisz 
> Signed-off-by: Keerthy 
> Signed-off-by: Lokesh Vutla 

Reviewed-by: Tom Rini 

-- 
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 10/22] mmc: refactor MMC startup to make it easier to support new modes

[Jean-Jacques Hiblot]

Hi,


On 25/05/2017 14:25, Jaehoon Chung wrote:

On 05/13/2017 03:16 AM, Jean-Jacques Hiblot wrote:

The MMC startup process currently handles 4 modes. To make it easier to
add support for more modes, let's make the process more generic and use a
list of the modes to try.
The major functional change is that when a mode fails we try the next one.
Not all modes are tried, only those supported by the card and the host.

Signed-off-by: Jean-Jacques Hiblot 
---
  drivers/mmc/mmc.c | 238 +-
  include/mmc.h |  15 +++-
  2 files changed, 157 insertions(+), 96 deletions(-)

diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index f42a0fe..2931871 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -200,6 +200,7 @@ static int mmc_select_mode(struct mmc *mmc, enum bus_mode 
mode)
  {
mmc->selected_mode = mode;
mmc->tran_speed = mmc_mode2freq(mmc, mode);
+   mmc->ddr_mode = mmc_is_mode_ddr(mode);
debug("selecting mode %s (freq : %d MHz)\n", mmc_mode_name(mode),
  mmc->tran_speed / 100);
return 0;
@@ -602,11 +603,46 @@ int mmc_switch(struct mmc *mmc, u8 set, u8 index, u8 
value)
  
  }
  
-static int mmc_change_freq(struct mmc *mmc)

+static int mmc_set_card_speed(struct mmc *mmc, enum bus_mode mode)
  {
-   ALLOC_CACHE_ALIGN_BUFFER(u8, ext_csd, MMC_MAX_BLOCK_LEN);
-   char cardtype;
int err;
+   int speed_bits;
+   ALLOC_CACHE_ALIGN_BUFFER(u8, test_csd, MMC_MAX_BLOCK_LEN);
+
+   switch (mode) {
+   case MMC_HS:
+   case MMC_HS_52:
+   case MMC_DDR_52:
+ speed_bits = EXT_CSD_TIMING_HS;
+   case MMC_LEGACY:
+ speed_bits = EXT_CSD_TIMING_LEGACY;
+ break;
+   default:
+ return -EINVAL;
+   }
+   err = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_HS_TIMING,
+speed_bits);
+   if (err)
+   return err;
+
+   if ((mode == MMC_HS) || (mode == MMC_HS_52)) {
+   /* Now check to see that it worked */
+   err = mmc_send_ext_csd(mmc, test_csd);
+   if (err)
+   return err;
+
+   /* No high-speed support */
+   if (!test_csd[EXT_CSD_HS_TIMING])
+   return -ENOTSUPP;
+   }
+
+   return 0;
+}
+
+static int mmc_get_capabilities(struct mmc *mmc)
+{
+   u8 *ext_csd = mmc->ext_csd;
+   char cardtype;
  
  	mmc->card_caps = MMC_MODE_1BIT;
  
@@ -617,38 +653,23 @@ static int mmc_change_freq(struct mmc *mmc)

if (mmc->version < MMC_VERSION_4)
return 0;
  
-	mmc->card_caps |= MMC_MODE_4BIT | MMC_MODE_8BIT;

-
-   err = mmc_send_ext_csd(mmc, ext_csd);
+   if (!ext_csd) {
+   error("No ext_csd found!\n"); /* this should enver happen */
+   return -ENOTSUPP;
+   }
  
-	if (err)

-   return err;
+   mmc->card_caps |= MMC_MODE_4BIT | MMC_MODE_8BIT;
  
  	cardtype = ext_csd[EXT_CSD_CARD_TYPE] & 0xf;
  
-	err = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_HS_TIMING, 1);

-
-   if (err)
-   return err;
-
-   /* Now check to see that it worked */
-   err = mmc_send_ext_csd(mmc, ext_csd);
-
-   if (err)
-   return err;
-
-   /* No high-speed support */
-   if (!ext_csd[EXT_CSD_HS_TIMING])
-   return 0;
-
/* High Speed is set, there are two types: 52MHz and 26MHz */
if (cardtype & EXT_CSD_CARD_TYPE_52) {
-   if (cardtype & EXT_CSD_CARD_TYPE_DDR_1_8V)
+   if (cardtype & EXT_CSD_CARD_TYPE_DDR_52)
mmc->card_caps |= MMC_MODE_DDR_52MHz;
-   mmc->card_caps |= MMC_MODE_HS_52MHz | MMC_MODE_HS;
-   } else {
-   mmc->card_caps |= MMC_MODE_HS;
+   mmc->card_caps |= MMC_MODE_HS_52MHz;
}
+   if (cardtype & EXT_CSD_CARD_TYPE_26)
+   mmc->card_caps |= MMC_MODE_HS;
  
  	return 0;

  }
@@ -1320,33 +1341,58 @@ static int mmc_read_and_compare_ext_csd(struct mmc *mmc)
  }
  
  
-static int mmc_select_bus_freq_width(struct mmc *mmc)

+static const struct mode_width_tuning mmc_modes_by_pref[] = {
+   {
+   .mode = MMC_HS_200,
+   .widths = MMC_MODE_8BIT | MMC_MODE_4BIT,
+   },
+   {
+   .mode = MMC_DDR_52,
+   .widths = MMC_MODE_8BIT | MMC_MODE_4BIT,
+   },
+   {
+   .mode = MMC_HS_52,
+   .widths = MMC_MODE_8BIT | MMC_MODE_4BIT | MMC_MODE_1BIT,
+   },
+   {
+   .mode = MMC_HS,
+   .widths = MMC_MODE_8BIT | MMC_MODE_4BIT | MMC_MODE_1BIT,
+   },
+   {
+   .mode = MMC_LEGACY,
+   .widths = MMC_MODE_8BIT | MMC_MODE_4BIT | MMC_MODE_1BIT,
+   }
+};
+#define for_each_mmc_mode_by_pref(caps, mwt) \
+   for (mwt = mmc_modes_by_pref;\
+   mwt < 

Re: [U-Boot] [PATCH] power: pmic: tps65218: Fix tps65218_voltage_update function

[Tom Rini]

On Thu, May 25, 2017 at 10:48:55PM +0900, Jaehoon Chung wrote:
> On 05/24/2017 01:49 PM, Keerthy wrote:
> > Currently while setting the vsel value for dcdc1 and dcdc2
> > the driver is wrongly masking the entire 8 bits in the process
> > clearing PFM (bit7) field as well. Hence describe an appropriate
> > mask for vsel field and modify only those bits in the vsel
> > mask.
> > 
> > Source: http://www.ti.com/lit/ds/symlink/tps65218.pdf
> > 
> > Signed-off-by: Keerthy 
> > Fixes: 86db550b38 ("power: Add support for the TPS65218 PMIC")
> 
> If delegate to me..i will pick this.

Feel free (always!) to grab things in patchwork that are in your areas,
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] mmc: Set the initial clock speed to 400KHz

[Phil Edworthy]

Hi Jaehoon Chung,

On 25 May 2017 15:10 Jaehoon Chung wrote:
> On 05/25/2017 11:02 PM, Phil Edworthy wrote:
> > On 25 May 2017 14:50 Jaehoon Chung wrote:
> >> On 05/24/2017 10:54 PM, Phil Edworthy wrote:
> >>> The code currently defaults to the slowest clock speed that can be
> >>> achieved, which can be significantly lower than the SD spec.
> >>
> >> Is there any problem..As i know, it should be changed from 1 to min_clk.
> > The only problem is that the initial SD clock can be very slow so it
> > increases the time to start SD. Admittedly, it's a very small increase
> > in time, but we should use the correct initial clock speed.
> 
> Well..i didn't agree yet...
> 
> If mmc_set_clock(mmc, 400K) and mmc->cfg->f_min is 300K?
> Initial clock should be always 400K..but spec is mentioned "initial clock is
> maximum 400K.."
> It means the clock can be the value under 400K.
I'm not sure I follow you.
The spec means that all SD cards must support an initial clock speed of 400KHz, 
right?
If so, then there is no harm in setting it to 400KHz.

Thanks
Phil

> >>> Signed-off-by: Phil Edworthy 
> >>> ---
> >>>  drivers/mmc/mmc.c | 2 +-
> >>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index
> >>> 72fc177..dff1be3 100644
> >>> --- a/drivers/mmc/mmc.c
> >>> +++ b/drivers/mmc/mmc.c
> >>> @@ -1676,7 +1676,7 @@ int mmc_start_init(struct mmc *mmc)  #endif
> >>>   mmc->ddr_mode = 0;
> >>>   mmc_set_bus_width(mmc, 1);
> >>> - mmc_set_clock(mmc, 1);
> >>> + mmc_set_clock(mmc, 40);
> >>>
> >>>   /* Reset the Card */
> >>>   err = mmc_go_idle(mmc);
> >>>
> >
> >
> >
> >

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

Re: [U-Boot] [PATCH] mmc: Set the initial clock speed to 400KHz

[Jaehoon Chung]

On 05/25/2017 11:02 PM, Phil Edworthy wrote:
> Hi Jaehoon Chung,
> 
> On 25 May 2017 14:50 Jaehoon Chung wrote:
>> Hi,
>>
>> On 05/24/2017 10:54 PM, Phil Edworthy wrote:
>>> The code currently defaults to the slowest clock speed that can be
>>> achieved, which can be significantly lower than the SD spec.
>>
>> Is there any problem..As i know, it should be changed from 1 to min_clk.
> The only problem is that the initial SD clock can be very slow so it increases
> the time to start SD. Admittedly, it's a very small increase in time, but we
> should use the correct initial clock speed.

Well..i didn't agree yet...

If mmc_set_clock(mmc, 400K) and mmc->cfg->f_min is 300K?
Initial clock should be always 400K..but spec is mentioned "initial clock is 
maximum 400K.."
It means the clock can be the value under 400K.

> 
> Thanks
> Phil
> 
>>>
>>> Signed-off-by: Phil Edworthy 
>>> ---
>>>  drivers/mmc/mmc.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index
>>> 72fc177..dff1be3 100644
>>> --- a/drivers/mmc/mmc.c
>>> +++ b/drivers/mmc/mmc.c
>>> @@ -1676,7 +1676,7 @@ int mmc_start_init(struct mmc *mmc)  #endif
>>> mmc->ddr_mode = 0;
>>> mmc_set_bus_width(mmc, 1);
>>> -   mmc_set_clock(mmc, 1);
>>> +   mmc_set_clock(mmc, 40);
>>>
>>> /* Reset the Card */
>>> err = mmc_go_idle(mmc);
>>>
> 
> 
> 
> 

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

Re: [U-Boot] [PATCH] nds32: mmc: Support ftsdc010 DM.

[Jaehoon Chung]

Hi,

On 05/24/2017 10:47 AM, Andes wrote:
> From: rick 
> 
> Support Andestech ftsdc010 SD/MMC device tree flow
> on AG101P/AE3XX platforms.
> Verification : boot linux kernel from sd card

Split the patch...

> 
> NDS32 # mmc rescan
> NDS32 # fatls mmc 0:1
> 13938796   boomimage-310y-ag101p.bin
> 
> 1 file(s)
> 
> NDS32 # fatload mmc 0:1 0x60 boomimage-310y-ag101p.bin
> reading boomimage-310y-ag101p.bin
> 13938796 bytes read in 17358 ms (784.2 KiB/s)
> NDS32 # bootm 0x60
>Image Name:
>Created:  2017-05-23   1:58:24 UTC
>Image Type:   NDS32 Linux Kernel Image (uncompressed)
>Data Size:13938732 Bytes = 13.3 MiB
>Load Address: c000
>Entry Point:  c000
>Verifying Checksum ... OK
>Loading Kernel Image ... OK
> Linux version 3.10.102-20420-g301b0f6 (rick@app09) (gcc version 4.9.3
> (2016-07-06_nds32le-linux-glibc-v3_experimental) )#798
> PREEMPT Tue May 23 09:57:59 CST 2017
> CPU: NDS32 N13, AndesCore ID(wb), CPU_VER 0x0d0c003f(id 13, rev 12, cfg 63)
>   ...
>   ...
> Signed-off-by: rick 
> ---
>  arch/nds32/dts/ae3xx.dts|8 ++
>  arch/nds32/dts/ag101p.dts   |8 ++
>  board/AndesTech/adp-ae3xx/adp-ae3xx.c   |4 +-
>  board/AndesTech/adp-ag101p/adp-ag101p.c |7 +-
>  configs/adp-ae3xx_defconfig |5 ++
>  configs/adp-ag101p_defconfig|5 ++
>  drivers/mmc/Kconfig |   12 +++
>  drivers/mmc/Makefile|1 +
>  drivers/mmc/ftsdc010_mci.c  |  140 
> ---
>  drivers/mmc/ftsdc010_mci.h  |   54 
>  drivers/mmc/nds32_mmc.c |  139 ++
>  include/configs/adp-ae3xx.h |1 -
>  include/configs/adp-ag101p.h|1 -
>  13 files changed, 344 insertions(+), 41 deletions(-)
>  create mode 100644 drivers/mmc/ftsdc010_mci.h
>  create mode 100644 drivers/mmc/nds32_mmc.c
> 
> diff --git a/arch/nds32/dts/ae3xx.dts b/arch/nds32/dts/ae3xx.dts
> index 4221e4b..781eabc 100644
> --- a/arch/nds32/dts/ae3xx.dts
> +++ b/arch/nds32/dts/ae3xx.dts
> @@ -62,6 +62,14 @@
>   interrupts = <25 4>;
>   };
>  
> + mmc0: mmc@f0e0 {
> + compatible = "andestech,atsdc010";
> + clock-freq-min-max = <40 1>;
> + fifo-depth = <0x10>;
> + reg = <0xf0e0 0x1000>;
> + interrupts = <17 4>;
> + };
> +
>   nor@0,0 {
>   compatible = "cfi-flash";
>   reg = <0x8800 0x1000>;
> diff --git a/arch/nds32/dts/ag101p.dts b/arch/nds32/dts/ag101p.dts
> index 99cde2f..dd2bf8f 100644
> --- a/arch/nds32/dts/ag101p.dts
> +++ b/arch/nds32/dts/ag101p.dts
> @@ -60,4 +60,12 @@
>   reg = <0x9090 0x1000>;
>   interrupts = <25 4>;
>   };
> +
> + mmc0: mmc@98e0 {
> + compatible = "andestech,atsdc010";
> + clock-freq-min-max = <40 3000>;
> + fifo-depth = <0x10>;
> + reg = <0x98e0 0x1000>;
> + interrupts = <5 4>;
> + };
>  };
> diff --git a/board/AndesTech/adp-ae3xx/adp-ae3xx.c 
> b/board/AndesTech/adp-ae3xx/adp-ae3xx.c
> index 98ed4d9..3903427 100644
> --- a/board/AndesTech/adp-ae3xx/adp-ae3xx.c
> +++ b/board/AndesTech/adp-ae3xx/adp-ae3xx.c
> @@ -77,10 +77,8 @@ ulong board_flash_get_legacy(ulong base, int banknum, 
> flash_info_t *info)
>  
>  int board_mmc_init(bd_t *bis)
>  {
> -#ifndef CONFIG_DM_MMC
> -#ifdef CONFIG_FTSDC010
> +#if defined(CONFIG_FTSDC010) && !defined(CONFIG_DM_MMC)
>   ftsdc010_mmc_init(0);
>  #endif
> -#endif
>   return 0;
>  }
> diff --git a/board/AndesTech/adp-ag101p/adp-ag101p.c 
> b/board/AndesTech/adp-ag101p/adp-ag101p.c
> index a462941..826ba14 100644
> --- a/board/AndesTech/adp-ag101p/adp-ag101p.c
> +++ b/board/AndesTech/adp-ag101p/adp-ag101p.c
> @@ -20,7 +20,6 @@ DECLARE_GLOBAL_DATA_PTR;
>  /*
>   * Miscellaneous platform dependent initializations
>   */
> -
>  int board_init(void)
>  {
>   /*
> @@ -30,7 +29,6 @@ int board_init(void)
>   printf("Board: %s\n" , CONFIG_SYS_BOARD);
>   gd->bd->bi_arch_number = MACH_TYPE_ADPAG101P;
>   gd->bd->bi_boot_params = PHYS_SDRAM_0 + 0x400;
> -
>   return 0;
>  }
>  
> @@ -39,11 +37,8 @@ int dram_init(void)
>   unsigned long sdram_base = PHYS_SDRAM_0;
>   unsigned long expected_size = PHYS_SDRAM_0_SIZE + PHYS_SDRAM_1_SIZE;
>   unsigned long actual_size;
> -
>   actual_size = get_ram_size((void *)sdram_base, expected_size);
> -
>   gd->ram_size = actual_size;
> -
>   if (expected_size != actual_size) {
>   printf("Warning: Only %lu of %lu MiB SDRAM is working\n",
>   actual_size >> 20, expected_size >> 20);
> @@ -83,7 +78,7 @@ ulong board_flash_get_legacy(ulong base, int banknum, 
> flash_info_t *info)
>  
>  int 

Re: [U-Boot] [PATCH] mmc: Set the initial clock speed to 400KHz

[Phil Edworthy]

Hi Jaehoon Chung,

On 25 May 2017 14:50 Jaehoon Chung wrote:
> Hi,
> 
> On 05/24/2017 10:54 PM, Phil Edworthy wrote:
> > The code currently defaults to the slowest clock speed that can be
> > achieved, which can be significantly lower than the SD spec.
> 
> Is there any problem..As i know, it should be changed from 1 to min_clk.
The only problem is that the initial SD clock can be very slow so it increases
the time to start SD. Admittedly, it's a very small increase in time, but we
should use the correct initial clock speed.

Thanks
Phil

> >
> > Signed-off-by: Phil Edworthy 
> > ---
> >  drivers/mmc/mmc.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index
> > 72fc177..dff1be3 100644
> > --- a/drivers/mmc/mmc.c
> > +++ b/drivers/mmc/mmc.c
> > @@ -1676,7 +1676,7 @@ int mmc_start_init(struct mmc *mmc)  #endif
> > mmc->ddr_mode = 0;
> > mmc_set_bus_width(mmc, 1);
> > -   mmc_set_clock(mmc, 1);
> > +   mmc_set_clock(mmc, 40);
> >
> > /* Reset the Card */
> > err = mmc_go_idle(mmc);
> >

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

Re: [U-Boot] [PATCH] mmc: sdhci-cadence: set timing mode register depending on frequency

[Jaehoon Chung]

On 05/25/2017 01:14 AM, Masahiro Yamada wrote:
> 2017-05-19 21:24 GMT+09:00 Masahiro Yamada :
>> The MMC framework in U-Boot does not support a systematic API for
>> timing switch like mmc_set_timing() in Linux.
>>
>> U-Boot just provides a hook to change the clock frequency via
>> mmc_set_clock().  It is up to drivers if additional register
>> settings are needed.
>>
>> This driver needs to set a correct timing mode into a register when
>> it migrates to a different speed mode.  Only increasing clock frequency
>> could result in setup/hold timing violation.
>>
>> The timing mode should be decided by checking MMC_TIMING_* like
>> drivers/mmc/host/sdhci-cadence.c in Linux, but "timing" is not
>> supported by U-Boot for now.  Just use mmc->clock to decide the
>> timing mode.
>>
>> Signed-off-by: Masahiro Yamada 
> 
> I see lots of improvements for MMC core.
> 
> Looks like it is better to rebase my work
> after they are merged.
> 
> 
> I marked this patch Superseded.

Oh..thanks for marking..Sorry for late.

Best Regards,
Jaehoon Chung

> 
> 
> 
> 

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

Re: [U-Boot] [PATCH] armv7m: Fix larger builds

[Phil Edworthy]

Hi Vikas,

On 25 May 2017 10:16 Phil Edworthy wrote:
> > On 24 May 2017 18:32 Vikas MANOCHA wrote:
> > Hi Phil,
> >
> > > On Wednesday, May 24, 2017 7:34 AM Phil Edworthy wrote:
> > > The branch instruction only has an 11-bit relative target address, which 
> > > is
> > sometimes not enough.
> > >
> > > Signed-off-by: Phil Edworthy 
> > > ---
> > >  arch/arm/cpu/armv7m/start.S | 3 ++-
> > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/arch/arm/cpu/armv7m/start.S
> b/arch/arm/cpu/armv7m/start.S
> > > index 49f2720..d79adb5 100644
> > > --- a/arch/arm/cpu/armv7m/start.S
> > > +++ b/arch/arm/cpu/armv7m/start.S
> > > @@ -8,7 +8,8 @@
> > >  .globl   reset
> > >  .type reset, %function
> > >  reset:
> > > - b   _main
> > > + ldr r0, =_main
> > > + mov pc, r0
> >
> > How about using W(b) for wider range ?
> Yes, that makes better sense!
Hmm, if I use W(b) it complains with:
arch/arm/cpu/armv7m/start.S:14:(.text+0x0): relocation truncated to fit: 
R_ARM_THM_JUMP11 against symbol `_main' defined in .text section in 
arch/arm/lib/built-in.o

Any ideas why?
Phil

> Thanks
> Phil
> 
> > Cheers,
> > Vikas
> >
> > >
> > >  .globl   c_runtime_cpu_setup
> > >  c_runtime_cpu_setup:
> > > --
> > > 2.7.4

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

Re: [U-Boot] mmc: meson: increase max block number per request

[Jaehoon Chung]

On 04/14/2017 05:10 PM, Heiner Kallweit wrote:
> Number of blocks is a 9 bit field where 0 stands for a unlimited
> number of blocks. Therefore the max number of blocks which can
> be set is 511.
> 
> Signed-off-by: Heiner Kallweit 

Applied to u-boot-mmc. Thanks! Sorry for late.

Best Regards,
Jaehoon Chung

> ---
>  drivers/mmc/meson_gx_mmc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/mmc/meson_gx_mmc.c b/drivers/mmc/meson_gx_mmc.c
> index 8e28ab7..2dda1b7 100644
> --- a/drivers/mmc/meson_gx_mmc.c
> +++ b/drivers/mmc/meson_gx_mmc.c
> @@ -244,7 +244,7 @@ static int meson_mmc_probe(struct udevice *dev)
>   MMC_MODE_HS_52MHz | MMC_MODE_HS;
>   cfg->f_min = DIV_ROUND_UP(SD_EMMC_CLKSRC_24M, CLK_MAX_DIV);
>   cfg->f_max = 1; /* 100 MHz */
> - cfg->b_max = 256; /* max 256 blocks */
> + cfg->b_max = 511; /* max 512 - 1 blocks */
>   cfg->name = dev->name;
>  
>   mmc->priv = pdata;
> 

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

Re: [U-Boot] [PATCH] power: pmic: tps65218: Fix tps65218_voltage_update function

[Keerthy]

On Thursday 25 May 2017 07:18 PM, Jaehoon Chung wrote:
> On 05/24/2017 01:49 PM, Keerthy wrote:
>> Currently while setting the vsel value for dcdc1 and dcdc2
>> the driver is wrongly masking the entire 8 bits in the process
>> clearing PFM (bit7) field as well. Hence describe an appropriate
>> mask for vsel field and modify only those bits in the vsel
>> mask.
>>
>> Source: http://www.ti.com/lit/ds/symlink/tps65218.pdf
>>
>> Signed-off-by: Keerthy 
>> Fixes: 86db550b38 ("power: Add support for the TPS65218 PMIC")
> 
> If delegate to me..i will pick this.
> 
> Reviewed-by: Jaehoon Chung 

Thanks Jaehoon Chung.

> 
>> ---
>>  drivers/power/pmic/pmic_tps65218.c | 2 +-
>>  include/power/tps65218.h   | 2 ++
>>  2 files changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/power/pmic/pmic_tps65218.c 
>> b/drivers/power/pmic/pmic_tps65218.c
>> index f32fa40..c5e768a 100644
>> --- a/drivers/power/pmic/pmic_tps65218.c
>> +++ b/drivers/power/pmic/pmic_tps65218.c
>> @@ -101,7 +101,7 @@ int tps65218_voltage_update(uchar dc_cntrl_reg, uchar 
>> volt_sel)
>>  
>>  /* set voltage level */
>>  if (tps65218_reg_write(TPS65218_PROT_LEVEL_2, dc_cntrl_reg, volt_sel,
>> -   TPS65218_MASK_ALL_BITS))
>> +   TPS65218_DCDC_VSEL_MASK))
>>  return 1;
>>  
>>  /* set GO bit to initiate voltage transition */
>> diff --git a/include/power/tps65218.h b/include/power/tps65218.h
>> index 4d68faa..e3538e2 100644
>> --- a/include/power/tps65218.h
>> +++ b/include/power/tps65218.h
>> @@ -56,6 +56,8 @@ enum {
>>  
>>  #define TPS65218_MASK_ALL_BITS  0xFF
>>  
>> +#define TPS65218_DCDC_VSEL_MASK 0x3F
>> +
>>  #define TPS65218_DCDC_VOLT_SEL_0950MV   0x0a
>>  #define TPS65218_DCDC_VOLT_SEL_1100MV   0x19
>>  #define TPS65218_DCDC_VOLT_SEL_1200MV   0x23
>>
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v4 2/2] doc: document u-boot, mmc-env-offset and u-boot, mmc-env-offset-redund

[Jaehoon Chung]

On 05/16/2017 07:16 AM, Philipp Tomsich wrote:
> Adding documentation on the new config properties:
>'u-boot,mmc-env-offset' - overrides CONFIG_ENV_OFFSET
>'u-boot,mmc-env-offset-redundant'
>- overrides CONFIG_ENV_OFFSET_REDUND
> 
> Signed-off-by: Philipp Tomsich 

Reviewed-by: Jaehoon Chung 

> 
> ---
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2:
> - added documentation in config.txt
> 
>  doc/device-tree-bindings/config.txt | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/doc/device-tree-bindings/config.txt 
> b/doc/device-tree-bindings/config.txt
> index d4bc1df..fe0e04a 100644
> --- a/doc/device-tree-bindings/config.txt
> +++ b/doc/device-tree-bindings/config.txt
> @@ -21,6 +21,18 @@ u-boot,efi-partition-entries-offset
>  
>   This setting will override any values configured via Kconfig.
>  
> +u-boot,mmc-env-offset
> +u-boot,mmc-env-offset-redundant
> + If present, the values of the 'u-boot,mmc-env-offset' and/or
> + of the u-boot,mmc-env-offset-redundant' properties overrides
> + CONFIG_ENV_OFFSET and CONFIG_ENV_OFFSET_REDUND, respectively,
> + for SD/MMC devices.
> +
> + Values are interpreted as the offset from the start of the
> + device, specified in bytes.  It is assumed that the setting
> + will point at the beginning of a LBA and values that are not
> + LBA-aligned will be rounded up to the next LBA address.
> +
>  u-boot,spl-payload-offset
>   If present (and SPL is controlled by the device-tree), this allows
>   to override the CONFIG_SYS_SPI_U_BOOT_OFFS setting using a value
> 

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

Re: [U-Boot] [PATCH v4 1/2] env_mmc: configure environment offsets via device tree

[Jaehoon Chung]

Hi Philipp,

On 05/16/2017 07:16 AM, Philipp Tomsich wrote:
> This introduces the ability to override the environment offets from the
> device tree by setting the following nodes in '/config':
>   'u-boot,mmc-env-offset' - overrides CONFIG_ENV_OFFSET
>   'u-boot,mmc-env-offset-redundant'
>   - overrides CONFIG_ENV_OFFSET_REDUND
> 
> To keep with the previous logic, the CONFIG_* defines still need to
> be available and the statically defined values become the defaults,
> when the corresponding properties are not set in the device-tree.
> 
> Signed-off-by: Philipp Tomsich 
> Acked-by: Simon Glass 

I'm doing check this patches..after building,,if there is no problem, i will 
pick.

Thanks!

Best Regards,
Jaehoon Chung

> ---
> 
> Changes in v4:
> - change the test for OF_CONTROL to use CONFIG_IS_ENABLED to pick up
>   the differece between SPL_OF_CONTROL and OF_CONTROL
> 
> Changes in v3:
> - changes the config-check to depend on CONFIG_OF_CONTROL to detect
>   if 'fdtdec_get_config_int' is available
> 
> Changes in v2: None
> 
>  common/env_mmc.c | 31 +++
>  1 file changed, 27 insertions(+), 4 deletions(-)
> 
> diff --git a/common/env_mmc.c b/common/env_mmc.c
> index a5d14d4..45d95a1 100644
> --- a/common/env_mmc.c
> +++ b/common/env_mmc.c
> @@ -10,6 +10,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -36,15 +37,37 @@ DECLARE_GLOBAL_DATA_PTR;
>  #define CONFIG_ENV_OFFSET 0
>  #endif
>  
> -__weak int mmc_get_env_addr(struct mmc *mmc, int copy, u32 *env_addr)
> +#if CONFIG_IS_ENABLED(OF_CONTROL)
> +static inline s64 mmc_offset(int copy)
>  {
> - s64 offset;
> + const char *propname = "u-boot,mmc-env-offset";
> + s64 defvalue = CONFIG_ENV_OFFSET;
>  
> - offset = CONFIG_ENV_OFFSET;
> -#ifdef CONFIG_ENV_OFFSET_REDUND
> +#if defined(CONFIG_ENV_OFFSET_REDUND)
> + if (copy) {
> + propname = "u-boot,mmc-env-offset-redundant";
> + defvalue = CONFIG_ENV_OFFSET_REDUND;
> + }
> +#endif
> +
> + return fdtdec_get_config_int(gd->fdt_blob, propname, defvalue);
> +}
> +#else
> +static inline s64 mmc_offset(int copy)
> +{
> + s64 offset = CONFIG_ENV_OFFSET;
> +
> +#if defined(CONFIG_ENV_OFFSET_REDUND)
>   if (copy)
>   offset = CONFIG_ENV_OFFSET_REDUND;
>  #endif
> + return offset;
> +}
> +#endif
> +
> +__weak int mmc_get_env_addr(struct mmc *mmc, int copy, u32 *env_addr)
> +{
> + s64 offset = mmc_offset(copy);
>  
>   if (offset < 0)
>   offset += mmc->capacity;
> 

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

Re: [U-Boot] [PATCH] mmc: Set the initial clock speed to 400KHz

[Jaehoon Chung]

Hi,

On 05/24/2017 10:54 PM, Phil Edworthy wrote:
> The code currently defaults to the slowest clock speed that can be
> achieved, which can be significantly lower than the SD spec.

Is there any problem..As i know, it should be changed from 1 to min_clk.

> 
> Signed-off-by: Phil Edworthy 
> ---
>  drivers/mmc/mmc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index 72fc177..dff1be3 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -1676,7 +1676,7 @@ int mmc_start_init(struct mmc *mmc)
>  #endif
>   mmc->ddr_mode = 0;
>   mmc_set_bus_width(mmc, 1);
> - mmc_set_clock(mmc, 1);
> + mmc_set_clock(mmc, 40);
>  
>   /* Reset the Card */
>   err = mmc_go_idle(mmc);
> 

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

Re: [U-Boot] [PATCH] power: pmic: tps65218: Fix tps65218_voltage_update function

[Jaehoon Chung]

On 05/24/2017 01:49 PM, Keerthy wrote:
> Currently while setting the vsel value for dcdc1 and dcdc2
> the driver is wrongly masking the entire 8 bits in the process
> clearing PFM (bit7) field as well. Hence describe an appropriate
> mask for vsel field and modify only those bits in the vsel
> mask.
> 
> Source: http://www.ti.com/lit/ds/symlink/tps65218.pdf
> 
> Signed-off-by: Keerthy 
> Fixes: 86db550b38 ("power: Add support for the TPS65218 PMIC")

If delegate to me..i will pick this.

Reviewed-by: Jaehoon Chung 

> ---
>  drivers/power/pmic/pmic_tps65218.c | 2 +-
>  include/power/tps65218.h   | 2 ++
>  2 files changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/power/pmic/pmic_tps65218.c 
> b/drivers/power/pmic/pmic_tps65218.c
> index f32fa40..c5e768a 100644
> --- a/drivers/power/pmic/pmic_tps65218.c
> +++ b/drivers/power/pmic/pmic_tps65218.c
> @@ -101,7 +101,7 @@ int tps65218_voltage_update(uchar dc_cntrl_reg, uchar 
> volt_sel)
>  
>   /* set voltage level */
>   if (tps65218_reg_write(TPS65218_PROT_LEVEL_2, dc_cntrl_reg, volt_sel,
> -TPS65218_MASK_ALL_BITS))
> +TPS65218_DCDC_VSEL_MASK))
>   return 1;
>  
>   /* set GO bit to initiate voltage transition */
> diff --git a/include/power/tps65218.h b/include/power/tps65218.h
> index 4d68faa..e3538e2 100644
> --- a/include/power/tps65218.h
> +++ b/include/power/tps65218.h
> @@ -56,6 +56,8 @@ enum {
>  
>  #define TPS65218_MASK_ALL_BITS   0xFF
>  
> +#define TPS65218_DCDC_VSEL_MASK  0x3F
> +
>  #define TPS65218_DCDC_VOLT_SEL_0950MV0x0a
>  #define TPS65218_DCDC_VOLT_SEL_1100MV0x19
>  #define TPS65218_DCDC_VOLT_SEL_1200MV0x23
> 

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

Re: [U-Boot] [PATCH 5/5] mmc: sh_sdhi: Add SDHI support

[Jaehoon Chung]

On 05/13/2017 10:51 PM, Marek Vasut wrote:
> From: Kouei Abe 
> 
> R-Car Gen3 series have four SD card interfaces (SDHI0 to SDHI3),
> two of which can also be used as MMC interfaces (SDHI2 and SDHI3).
> This adds High-speed mode SD clock frequency between 25MHz and 50MHz,
> 8bit/4bit bus width, high capacity and low voltage device support.
> 
> Signed-off-by: Kouei Abe 
> Cc: Hiroyuki Yokoyama 
> Cc: Nobuhiro Iwamatsu 
> Cc: Jaehoon Chung 

Reviewed-by: Jaehoon Chung 

> ---
>  drivers/mmc/sh_sdhi.c | 14 ++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/drivers/mmc/sh_sdhi.c b/drivers/mmc/sh_sdhi.c
> index c64beb6e2a..d181b63905 100644
> --- a/drivers/mmc/sh_sdhi.c
> +++ b/drivers/mmc/sh_sdhi.c
> @@ -698,6 +698,19 @@ static const struct mmc_ops sh_sdhi_ops = {
>   .init   = sh_sdhi_initialize,
>  };
>  
> +#ifdef CONFIG_RCAR_GEN3
> +static struct mmc_config sh_sdhi_cfg = {
> + .name   = DRIVER_NAME,
> + .ops= _sdhi_ops,
> + .f_min  = CLKDEV_INIT,
> + .f_max  = CLKDEV_HS_DATA,
> + .voltages   = MMC_VDD_165_195 | MMC_VDD_32_33 | MMC_VDD_33_34,
> + .host_caps  = MMC_MODE_4BIT | MMC_MODE_8BIT | MMC_MODE_HS |
> +   MMC_MODE_HS_52MHz,
> + .part_type  = PART_TYPE_DOS,
> + .b_max  = CONFIG_SYS_MMC_MAX_BLK_COUNT,
> +};
> +#else
>  static struct mmc_config sh_sdhi_cfg = {
>   .name   = DRIVER_NAME,
>   .ops= _sdhi_ops,
> @@ -708,6 +721,7 @@ static struct mmc_config sh_sdhi_cfg = {
>   .part_type  = PART_TYPE_DOS,
>   .b_max  = CONFIG_SYS_MMC_MAX_BLK_COUNT,
>  };
> +#endif
>  
>  int sh_sdhi_init(unsigned long addr, int ch, unsigned long quirks)
>  {
> 

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

Re: [U-Boot] [PATCH 4/5] mmc: sh_sdhi: Add MMC version 5.0 support

[Jaehoon Chung]

On 05/13/2017 10:51 PM, Marek Vasut wrote:
> From: Kouei Abe 
> 
> Renesas SDHI SD/MMC driver did not support MMC version 5.0 devices.
> This adds MMC version 5.0 device support.
> 
> Signed-off-by: Kouei Abe 
> Signed-off-by: Hiroyuki Yokoyama 
> Signed-off-by: Marek Vasut 
> Cc: Hiroyuki Yokoyama 
> Cc: Nobuhiro Iwamatsu 
> Cc: Jaehoon Chung 
> ---
>  arch/arm/mach-rmobile/include/mach/sh_sdhi.h |  7 ++-
>  drivers/mmc/sh_sdhi.c| 24 +++-
>  2 files changed, 25 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm/mach-rmobile/include/mach/sh_sdhi.h 
> b/arch/arm/mach-rmobile/include/mach/sh_sdhi.h
> index a5ea45b707..1fb0648b12 100644
> --- a/arch/arm/mach-rmobile/include/mach/sh_sdhi.h
> +++ b/arch/arm/mach-rmobile/include/mach/sh_sdhi.h
> @@ -50,8 +50,10 @@
>  /* SDHI CMD VALUE */
>  #define CMD_MASK 0x
>  #define SDHI_APP 0x0040
> +#define SDHI_MMC_SEND_OP_COND0x0701
>  #define SDHI_SD_APP_SEND_SCR 0x0073
>  #define SDHI_SD_SWITCH   0x1C06
> +#define SDHI_MMC_SEND_EXT_CSD0x1C08
>  
>  /* SDHI_PORTSEL */
>  #define USE_1PORT(1 << 8) /* 1 port */
> @@ -120,7 +122,10 @@
>  #define CLK_ENABLE   (1 << 8)
>  
>  /* SDHI_OPTION */
> -#define OPT_BUS_WIDTH_1  (1 << 15)   /* bus width = 
> 1 bit */
> +#define OPT_BUS_WIDTH_M  (5 << 13)   /* 101b 
> (15-13bit) */

What is WIDTH_M?

> +#define OPT_BUS_WIDTH_1  (4 << 13)   /* bus width = 
> 1 bit */
> +#define OPT_BUS_WIDTH_4  (0 << 13)   /* bus width = 
> 4 bit */
> +#define OPT_BUS_WIDTH_8  (1 << 13)   /* bus width = 
> 8 bit */
>  
>  /* SDHI_ERR_STS1 */
>  #define ERR_STS1_CRC_ERROR   ((1 << 11) | (1 << 10) | (1 << 9) | \
> diff --git a/drivers/mmc/sh_sdhi.c b/drivers/mmc/sh_sdhi.c
> index d1dd0f0fc3..c64beb6e2a 100644
> --- a/drivers/mmc/sh_sdhi.c
> +++ b/drivers/mmc/sh_sdhi.c
> @@ -489,6 +489,13 @@ static unsigned short sh_sdhi_set_cmd(struct 
> sh_sdhi_host *host,
>   else /* SD_SWITCH */
>   opc = SDHI_SD_SWITCH;
>   break;
> + case MMC_CMD_SEND_OP_COND:
> + opc = SDHI_MMC_SEND_OP_COND;
> + break;
> + case MMC_CMD_SEND_EXT_CSD:
> + if (data)
> + opc = SDHI_MMC_SEND_EXT_CSD;
> + break;
>   default:
>   break;
>   }
> @@ -513,6 +520,7 @@ static unsigned short sh_sdhi_data_trans(struct 
> sh_sdhi_host *host,
>   case MMC_CMD_READ_SINGLE_BLOCK:
>   case SDHI_SD_APP_SEND_SCR:
>   case SDHI_SD_SWITCH: /* SD_SWITCH */
> + case SDHI_MMC_SEND_EXT_CSD:
>   ret = sh_sdhi_single_read(host, data);
>   break;
>   default:
> @@ -648,12 +656,18 @@ static int sh_sdhi_set_ios(struct mmc *mmc)
>   if (ret)
>   return -EINVAL;
>  
> - if (mmc->bus_width == 4)
> - sh_sdhi_writew(host, SDHI_OPTION, ~OPT_BUS_WIDTH_1 &
> -sh_sdhi_readw(host, SDHI_OPTION));
> + if (mmc->bus_width == 8)
> + sh_sdhi_writew(host, SDHI_OPTION,
> +OPT_BUS_WIDTH_8 | (~OPT_BUS_WIDTH_M &
> +sh_sdhi_readw(host, SDHI_OPTION)));
> + else if (mmc->bus_width == 4)
> + sh_sdhi_writew(host, SDHI_OPTION,
> +OPT_BUS_WIDTH_4 | (~OPT_BUS_WIDTH_M &
> +sh_sdhi_readw(host, SDHI_OPTION)));
>   else
> - sh_sdhi_writew(host, SDHI_OPTION, OPT_BUS_WIDTH_1 |
> -sh_sdhi_readw(host, SDHI_OPTION));
> + sh_sdhi_writew(host, SDHI_OPTION,
> +OPT_BUS_WIDTH_1 | (~OPT_BUS_WIDTH_M &
> +sh_sdhi_readw(host, SDHI_OPTION)));
>  
>   debug("clock = %d, buswidth = %d\n", mmc->clock, mmc->bus_width);
>  
> 

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

Re: [U-Boot] [PATCH 3/5] mmc: sh_sdhi: Add 64-bit access to sd_buf support

[Jaehoon Chung]

On 05/13/2017 10:51 PM, Marek Vasut wrote:
> From: Kouei Abe 
> 
> Renesas SDHI SD/MMC driver has 16-bit width bus access to SD_BUF.
> This adds 64-bit width bus access to SD_BUF.
> 
> Signed-off-by: Kouei Abe 
> Cc: Hiroyuki Yokoyama 
> Cc: Nobuhiro Iwamatsu 
> Cc: Jaehoon Chung 

Reviewed-by: Jaehoon Chung 

> ---
>  arch/arm/mach-rmobile/include/mach/sh_sdhi.h |  8 +++--
>  drivers/mmc/sh_sdhi.c| 53 
> ++--
>  2 files changed, 48 insertions(+), 13 deletions(-)
> 
> diff --git a/arch/arm/mach-rmobile/include/mach/sh_sdhi.h 
> b/arch/arm/mach-rmobile/include/mach/sh_sdhi.h
> index 057bf3f8bb..a5ea45b707 100644
> --- a/arch/arm/mach-rmobile/include/mach/sh_sdhi.h
> +++ b/arch/arm/mach-rmobile/include/mach/sh_sdhi.h
> @@ -1,9 +1,9 @@
>  /*
>   * drivers/mmc/sh-sdhi.h
>   *
> - * SD/MMC driver for Reneas rmobile ARM SoCs
> + * SD/MMC driver for Renesas rmobile ARM SoCs
>   *
> - * Copyright (C) 2013-2014 Renesas Electronics Corporation
> + * Copyright (C) 2013-2017 Renesas Electronics Corporation
>   * Copyright (C) 2008-2009 Renesas Solutions Corp.
>   *
>   * SPDX-License-Identifier:  GPL-2.0
> @@ -162,7 +162,9 @@
>  #define  CLKDEV_INIT 40  /* 100 - 400 
> KHz */
>  
>  /* For quirk */
> -#define SH_SDHI_QUIRK_16BIT_BUF  (1)
> +#define SH_SDHI_QUIRK_16BIT_BUF  BIT(0)
> +#define SH_SDHI_QUIRK_64BIT_BUF  BIT(1)
> +
>  int sh_sdhi_init(unsigned long addr, int ch, unsigned long quirks);
>  
>  #endif /* _SH_SDHI_H */
> diff --git a/drivers/mmc/sh_sdhi.c b/drivers/mmc/sh_sdhi.c
> index 7f0b4c2603..d1dd0f0fc3 100644
> --- a/drivers/mmc/sh_sdhi.c
> +++ b/drivers/mmc/sh_sdhi.c
> @@ -3,7 +3,7 @@
>   *
>   * SD/MMC driver for Renesas rmobile ARM SoCs.
>   *
> - * Copyright (C) 2011,2013-2014 Renesas Electronics Corporation
> + * Copyright (C) 2011,2013-2017 Renesas Electronics Corporation
>   * Copyright (C) 2014 Nobuhiro Iwamatsu 
>   * Copyright (C) 2008-2009 Renesas Solutions Corp.
>   *
> @@ -29,6 +29,17 @@ struct sh_sdhi_host {
>   unsigned char sd_error;
>   unsigned char detect_waiting;
>  };
> +
> +static inline void sh_sdhi_writeq(struct sh_sdhi_host *host, int reg, u64 
> val)
> +{
> + writeq(val, host->addr + (reg << host->bus_shift));
> +}
> +
> +static inline u64 sh_sdhi_readq(struct sh_sdhi_host *host, int reg)
> +{
> + return readq(host->addr + (reg << host->bus_shift));
> +}
> +
>  static inline void sh_sdhi_writew(struct sh_sdhi_host *host, int reg, u16 
> val)
>  {
>   writew(val, host->addr + (reg << host->bus_shift));
> @@ -261,6 +272,7 @@ static int sh_sdhi_single_read(struct sh_sdhi_host *host, 
> struct mmc_data *data)
>   long time;
>   unsigned short blocksize, i;
>   unsigned short *p = (unsigned short *)data->dest;
> + u64 *q = (u64 *)data->dest;
>  
>   if ((unsigned long)p & 0x0001) {
>   debug(DRIVER_NAME": %s: The data pointer is unaligned.",
> @@ -281,8 +293,12 @@ static int sh_sdhi_single_read(struct sh_sdhi_host 
> *host, struct mmc_data *data)
>  
>   host->wait_int = 0;
>   blocksize = sh_sdhi_readw(host, SDHI_SIZE);
> - for (i = 0; i < blocksize / 2; i++)
> - *p++ = sh_sdhi_readw(host, SDHI_BUF0);
> + if (host->quirks & SH_SDHI_QUIRK_64BIT_BUF)
> + for (i = 0; i < blocksize / 8; i++)
> + *q++ = sh_sdhi_readq(host, SDHI_BUF0);
> + else
> + for (i = 0; i < blocksize / 2; i++)
> + *p++ = sh_sdhi_readw(host, SDHI_BUF0);
>  
>   time = sh_sdhi_wait_interrupt_flag(host);
>   if (time == 0 || host->sd_error != 0)
> @@ -297,6 +313,7 @@ static int sh_sdhi_multi_read(struct sh_sdhi_host *host, 
> struct mmc_data *data)
>   long time;
>   unsigned short blocksize, i, sec;
>   unsigned short *p = (unsigned short *)data->dest;
> + u64 *q = (u64 *)data->dest;
>  
>   if ((unsigned long)p & 0x0001) {
>   debug(DRIVER_NAME": %s: The data pointer is unaligned.",
> @@ -319,8 +336,12 @@ static int sh_sdhi_multi_read(struct sh_sdhi_host *host, 
> struct mmc_data *data)
>  
>   host->wait_int = 0;
>   blocksize = sh_sdhi_readw(host, SDHI_SIZE);
> - for (i = 0; i < blocksize / 2; i++)
> - *p++ = sh_sdhi_readw(host, SDHI_BUF0);
> + if (host->quirks & SH_SDHI_QUIRK_64BIT_BUF)
> + for (i = 0; i < blocksize / 8; i++)
> + *q++ = sh_sdhi_readq(host, SDHI_BUF0);
> + else
> + for (i = 0; i < blocksize / 2; i++)
> + *p++ = sh_sdhi_readw(host, SDHI_BUF0);
>   }
>  
>   return 0;
> @@ -332,6 +353,7 @@ static int 

Re: [U-Boot] [PATCH 2/5] mmc: sh_sdhi: Set SD_INFOx interrupt mask before command starting

[Jaehoon Chung]

On 05/13/2017 10:51 PM, Marek Vasut wrote:
> From: Kouei Abe 
> 
> When setting interrupt mask after command starting, an unintended
> interrupt status sometimes occurs.
> 
> Signed-off-by: Kouei Abe 
> Signed-off-by: Hiroyuki Yokoyama 
> Cc: Hiroyuki Yokoyama 
> Cc: Nobuhiro Iwamatsu 
> Cc: Jaehoon Chung 

Reviewed-by: Jaehoon Chung 

> ---
>  drivers/mmc/sh_sdhi.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/mmc/sh_sdhi.c b/drivers/mmc/sh_sdhi.c
> index 25224e2e1d..7f0b4c2603 100644
> --- a/drivers/mmc/sh_sdhi.c
> +++ b/drivers/mmc/sh_sdhi.c
> @@ -546,8 +546,6 @@ static int sh_sdhi_start_cmd(struct sh_sdhi_host *host,
>   break;
>   }
>  
> - sh_sdhi_writew(host, SDHI_CMD, (unsigned short)(opc & CMD_MASK));
> -
>   host->wait_int = 0;
>   sh_sdhi_writew(host, SDHI_INFO1_MASK,
>  ~INFO1M_RESP_END & sh_sdhi_readw(host, SDHI_INFO1_MASK));
> @@ -557,6 +555,8 @@ static int sh_sdhi_start_cmd(struct sh_sdhi_host *host,
>  INFO2M_RESP_TIMEOUT | INFO2M_ILA) &
>  sh_sdhi_readw(host, SDHI_INFO2_MASK));
>  
> + sh_sdhi_writew(host, SDHI_CMD, (unsigned short)(opc & CMD_MASK));
> +
>   time = sh_sdhi_wait_interrupt_flag(host);
>   if (!time)
>   return sh_sdhi_error_manage(host);
> 

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

Re: [U-Boot] [PATCH 1/5] mmc: sh_sdhi: Fix Kconfig entry

[Jaehoon Chung]

On 05/13/2017 10:51 PM, Marek Vasut wrote:
> The Kconfig entry depends on RMOBILE, but this was renamed
> to ARCH_RMOBILE in commit 1cc95f6e1b38 (ARM: Rmobile: Rename
> CONFIG_RMOBILE to CONFIG_ARCH_RMOBILE) . Fix this omission.
> 
> Signed-off-by: Marek Vasut 
> Cc: Hiroyuki Yokoyama 
> Cc: Nobuhiro Iwamatsu 
> Cc: Jaehoon Chung 

Reviewed-by: Jaehoon Chung 

> ---
>  drivers/mmc/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
> index 6ac26dd137..b2d70a37bd 100644
> --- a/drivers/mmc/Kconfig
> +++ b/drivers/mmc/Kconfig
> @@ -159,7 +159,7 @@ config MMC_OMAP36XX_PINS
>  
>  config SH_SDHI
>   bool "SuperH/Renesas ARM SoCs on-chip SDHI host controller support"
> - depends on RMOBILE
> + depends on ARCH_RMOBILE
>   help
> Support for the on-chip SDHI host controller on SuperH/Renesas ARM 
> SoCs platform
>  
> 

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

Re: [U-Boot] [PATCH 2/2] regulator: pfuze100: unsigned compared against 0

[Jaehoon Chung]

On 05/11/2017 11:35 AM, Peng Fan wrote:
> Fix unsigned compared against 0.

Reviewed-by: Jaehoon Chung 

> 
> Signed-off-by: Peng Fan 
> Cc: Jaehoon Chung 
> ---
>  drivers/power/regulator/pfuze100.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/power/regulator/pfuze100.c 
> b/drivers/power/regulator/pfuze100.c
> index 88b1b72..02f3894 100644
> --- a/drivers/power/regulator/pfuze100.c
> +++ b/drivers/power/regulator/pfuze100.c
> @@ -314,7 +314,7 @@ static int pfuze100_regulator_probe(struct udevice *dev)
>  
>  static int pfuze100_regulator_mode(struct udevice *dev, int op, int *opmode)
>  {
> - unsigned char val;
> + int val;
>   struct pfuze100_regulator_platdata *plat = dev_get_platdata(dev);
>   struct pfuze100_regulator_desc *desc = plat->desc;
>  
> @@ -384,7 +384,7 @@ static int pfuze100_regulator_mode(struct udevice *dev, 
> int op, int *opmode)
>  
>  static int pfuze100_regulator_enable(struct udevice *dev, int op, bool 
> *enable)
>  {
> - unsigned char val;
> + int val;
>   int ret, on_off;
>   struct dm_regulator_uclass_platdata *uc_pdata =
>   dev_get_uclass_platdata(dev);
> @@ -448,7 +448,7 @@ static int pfuze100_regulator_enable(struct udevice *dev, 
> int op, bool *enable)
>  static int pfuze100_regulator_val(struct udevice *dev, int op, int *uV)
>  {
>   int i;
> - unsigned char val;
> + int val;
>   struct pfuze100_regulator_platdata *plat = dev_get_platdata(dev);
>   struct pfuze100_regulator_desc *desc = plat->desc;
>   struct dm_regulator_uclass_platdata *uc_pdata =
> 

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

Re: [U-Boot] [PATCH 1/2] regulator: pfuze100: add SPDX License

[Jaehoon Chung]

On 05/11/2017 11:35 AM, Peng Fan wrote:
> Add SPDX license
> 
> Signed-off-by: Peng Fan 
> Cc: Jaehoon Chung 

Reviewed-by: Jaehoon Chung 

> ---
>  drivers/power/regulator/pfuze100.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/power/regulator/pfuze100.c 
> b/drivers/power/regulator/pfuze100.c
> index 4702161..88b1b72 100644
> --- a/drivers/power/regulator/pfuze100.c
> +++ b/drivers/power/regulator/pfuze100.c
> @@ -1,3 +1,11 @@
> +/*
> + * Copyright 2017 NXP
> + *
> + * Peng Fan 
> + *
> + * SPDX-License-Identifier:  GPL-2.0+
> + */
> +
>  #include 
>  #include 
>  #include 
> 

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

Re: [U-Boot] [PATCH V3 3/4] imx: warp: use vs18_enable

[Jaehoon Chung]

On 05/11/2017 11:28 AM, Peng Fan wrote:
> Use vs18_enable, and drop CONFIG_SYS_FSL_ESDHC_FORCE_VSELECT.
> 
> Signed-off-by: Peng Fan 
> Cc: Otavio Salvador 
> Cc: Stefano Babic 
> Cc: Jaehoon Chung 
> ---
> 
> V3: none
> V2: none
> 
>  board/warp/warp.c  | 2 +-
>  include/configs/warp.h | 1 -
>  2 files changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/board/warp/warp.c b/board/warp/warp.c
> index 0bc0a6a..b1b528a 100644
> --- a/board/warp/warp.c
> +++ b/board/warp/warp.c
> @@ -62,7 +62,7 @@ static void setup_iomux_uart(void)
>  }
>  
>  static struct fsl_esdhc_cfg usdhc_cfg[1] = {
> - {USDHC2_BASE_ADDR},
> + {USDHC2_BASE_ADDR, 0, 0, 0, 1},
>  };
>  
>  int board_mmc_getcd(struct mmc *mmc)
> diff --git a/include/configs/warp.h b/include/configs/warp.h
> index 5274b27..387a079 100644
> --- a/include/configs/warp.h
> +++ b/include/configs/warp.h
> @@ -23,7 +23,6 @@
>  
>  /* MMC Configs */
>  #define CONFIG_SYS_FSL_ESDHC_ADDRUSDHC2_BASE_ADDR
> -#define CONFIG_SYS_FSL_ESDHC_FORCE_VSELECT

This change can be moved to [PATCH 4/4].

>  #define CONFIG_SYS_FSL_ESDHC_HAS_DDR_MODE
>  #define CONFIG_SUPPORT_EMMC_BOOT
>  
> 

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

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

[Dinh Nguyen]

On 05/25/2017 03:53 AM, Chee, Tien Fong wrote:
> On Rab, 2017-05-24 at 09:56 -0500, Dinh Nguyen wrote:
>>
>> On 05/23/2017 09:24 PM, tien.fong.c...@intel.com wrote:
>>>
>>> From: Tien Fong Chee 
>>>
>>> This is the 6th version of patchset to adds support for Intel Arria
>>> 10 SoC FPGA
>>> driver. This version mainly resolved comments from Dinh in [v5].
>>> This series is working on top of u-boot-socfpga-next branch
>>> http://git.denx.de/?p=u-boot/u-boot-socfpga.git;a=shortlog;h=refs/h
>>> eads/next.
>>>
>>> [v5]: https://www.mail-archive.com/u-boot@lists.denx.de/msg250517.h
>>> tml
>>>
>>> v5 -> v6 changes:
>>> -
>>> - Created separate patch for enabling FPGA driver support.
>>>
>> Please consider at least doing a compile test for this patch series?
>> I'm
>> now very skeptical that you've done any kind of testing on this patch
>> series? :(
>>
>> For 'make socfpga_cyclone5_defconfig:
>>
>> arch/arm/mach-socfpga/built-in.o: In function
>> `socfpga_bridges_reset':
>> /home/dinguyen/linux_dev/u-boot/arch/arm/mach-
>> socfpga/reset_manager_gen5.c:101:
>> undefined reference to `fpgamgr_test_fpga_ready'
>> arch/arm/mach-socfpga/built-in.o: In function
>> `populate_sysmgr_fpgaintf_module':
>> /home/dinguyen/linux_dev/u-boot/arch/arm/mach-
>> socfpga/system_manager_gen5.c:48:
>> undefined reference to `fpgamgr_test_fpga_ready'
>> drivers/built-in.o: In function `sdram_mmr_init_full':
>> /home/dinguyen/linux_dev/u-boot/drivers/ddr/altera/sdram.c:448:
>> undefined reference to `fpgamgr_test_fpga_ready'
>> scripts/Makefile.spl:334: recipe for target 'spl/u-boot-spl' failed
>> make[1]: *** [spl/u-boot-spl] Error 1
>> Makefile:1347: recipe for target 'spl/u-boot-spl' failed
>> make: *** [spl/u-boot-spl] Error 2
>>
>> For socfpga_arria10_defconfig:
>>
>> arch/arm/mach-socfpga/built-in.o: In function `socfpga_fpga_add':
>> /home/dinguyen/linux_dev/u-boot/arch/arm/mach-socfpga/misc.c:110:
>> undefined reference to `fpga_init'
>> /home/dinguyen/linux_dev/u-boot/arch/arm/mach-socfpga/misc.c:112:
>> undefined reference to `fpga_add'
>> scripts/Makefile.spl:334: recipe for target 'spl/u-boot-spl' failed
>> make[1]: *** [spl/u-boot-spl] Error 1
>> Makefile:1347: recipe for target 'spl/u-boot-spl' failed
>> make: *** [spl/u-boot-spl] Error 2
>>
>>
>> Dinh
> 
> I did the compilation on each patch, and testing the patch set on all
> arria10, cyclone5 and arria10 devkit.
> 
> I suspect something wrong with v6-0005-arm-socfpga-Move-FPGA-manager-
> driver-to-FPGA-driv.patch you applied. Could you help me check again
> and confirm all the patches waere applied properly?
> 

Yes, I've applied all of your patches correctly. The only diff between
this series and the last is:

$ git diff tien_fong_fpga_a10_v5
diff --git a/drivers/Makefile b/drivers/Makefile
index b4a2230..4a4b237 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -47,7 +47,6 @@ obj-$(CONFIG_OMAP_USB_PHY) += usb/phy/
 obj-$(CONFIG_SPL_SATA_SUPPORT) += block/
 obj-$(CONFIG_SPL_USB_HOST_SUPPORT) += block/
 obj-$(CONFIG_SPL_MMC_SUPPORT) += block/
-obj-$(CONFIG_FPGA) += fpga/
 endif

 ifdef CONFIG_TPL_BUILD
diff --git a/include/configs/socfpga_common.h
b/include/configs/socfpga_common.h
index 913b9f1..9edcd2d 100644
--- a/include/configs/socfpga_common.h
+++ b/include/configs/socfpga_common.h
@@ -109,6 +109,7 @@
 #define CONFIG_FPGA
 #define CONFIG_FPGA_ALTERA
 #define CONFIG_FPGA_SOCFPGA
+#define CONFIG_SPL_FPGA_SUPPORT
 #define CONFIG_FPGA_COUNT  1
 #endif

So the patch for using CONFIG_SPL_FPGA_SUPPORT is causing this build
error. Please investigate.

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

Re: [U-Boot] [PATCH V3 2/4] dm: mmc: fsl_esdhc: handle vqmmc supply

[Jaehoon Chung]

On 05/11/2017 11:28 AM, Peng Fan wrote:
> Handle vqmmc supply. Some boards have a fixed I/O voltage
> at 1.8V for emmc, so the usdhc also needs to be configured
> as 1.8V by setting VSELECT bit. The vs18_enable is the one
> that used to checking whether setting VSELECT or not in
> the driver. So if vqmmc supply is 1.8V, set vs18_enable,
> the driver will set VSELECT.
> 
> Signed-off-by: Peng Fan 
> Cc: Jaehoon Chung 
> Cc: York Sun 
> Cc: Stefano Babic 

Reviewed-by: Jaehoon Chung 

> ---
> 
> V3: add regulator enable
> V2: include header file, fix dev_dbg
> 
>  drivers/mmc/fsl_esdhc.c | 25 +
>  1 file changed, 25 insertions(+)
> 
> diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
> index bddfe24..20f0b40 100644
> --- a/drivers/mmc/fsl_esdhc.c
> +++ b/drivers/mmc/fsl_esdhc.c
> @@ -16,6 +16,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -968,6 +969,7 @@ static int fsl_esdhc_probe(struct udevice *dev)
>   struct fsl_esdhc_priv *priv = dev_get_priv(dev);
>   const void *fdt = gd->fdt_blob;
>   int node = dev_of_offset(dev);
> + struct udevice *vqmmc_dev;
>   fdt_addr_t addr;
>   unsigned int val;
>   int ret;
> @@ -1005,6 +1007,29 @@ static int fsl_esdhc_probe(struct udevice *dev)
>   if (ret)
>   priv->wp_enable = 0;
>  #endif
> +
> + priv->vs18_enable = 0;
> +
> +#ifdef CONFIG_DM_REGULATOR
> + /*
> +  * If emmc I/O has a fixed voltage at 1.8V, this must be provided,
> +  * otherwise, emmc will work abnormally.
> +  */
> + ret = device_get_supply_regulator(dev, "vqmmc-supply", _dev);
> + if (ret) {
> + dev_dbg(dev, "no vqmmc-supply\n");
> + } else {
> + ret = regulator_set_enable(vqmmc_dev, true);
> + if (ret) {
> + dev_err(dev, "fail to enable vqmmc-supply\n");
> + return ret;
> + }
> +
> + if (regulator_get_value(vqmmc_dev) == 180)
> + priv->vs18_enable = 1;
> + }
> +#endif
> +
>   /*
>* TODO:
>* Because lack of clk driver, if SDHC clk is not enabled,
> 

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

Re: [U-Boot] [PATCH V3 1/4] mmc: fsl_esdhc: introduce vs18_enable for 1.8V fix I/O

[Jaehoon Chung]

On 05/11/2017 11:28 AM, Peng Fan wrote:
> When using eMMC with 1.8V I/O, the VSELECT bit need to be set in
> the USDHC controller when init.
> 
> This patch adds a parameter "vs18_enable" in fsl_esdhc_cfg
> structure and priv data, so each controller can have different
> settings.
> 
> We could not use CONFIG_SYS_FSL_ESDHC_FORCE_VSELECT, it has problem
> that it will apply to all USDHC controllers and it only set the 1.8V
> at init phase. So if user does not select to the eMMC device,
> the voltage on the I/O pins are not correct.
> 
> Signed-off-by: Peng Fan 
> Cc: Jaehoon Chung 
> Cc: York Sun 
> Cc: Stefano Babic 
> ---
> 
> V3: none
> V2: none
> 
>  drivers/mmc/fsl_esdhc.c | 9 +
>  include/fsl_esdhc.h | 1 +
>  2 files changed, 10 insertions(+)
> 
> diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
> index f3c6358..bddfe24 100644
> --- a/drivers/mmc/fsl_esdhc.c
> +++ b/drivers/mmc/fsl_esdhc.c
> @@ -92,6 +92,7 @@ struct fsl_esdhc {
>   * @dev: pointer for the device
>   * @non_removable: 0: removable; 1: non-removable
>   * @wp_enable: 1: enable checking wp; 0: no check
> + * @vs18_enable: 1: use 1.8V voltage; 0: use 3.3V
>   * @cd_gpio: gpio for card detection
>   * @wp_gpio: gpio for write protection
>   */
> @@ -104,6 +105,7 @@ struct fsl_esdhc_priv {
>   struct udevice *dev;
>   int non_removable;
>   int wp_enable;
> + int vs18_enable;
>  #ifdef CONFIG_DM_GPIO
>   struct gpio_desc cd_gpio;
>   struct gpio_desc wp_gpio;
> @@ -673,6 +675,9 @@ static int esdhc_init(struct mmc *mmc)
>   esdhc_setbits32(>vendorspec, ESDHC_VENDORSPEC_VSELECT);
>  #endif
>  
> + if (priv->vs18_enable)
> + esdhc_setbits32(>vendorspec, ESDHC_VENDORSPEC_VSELECT);
> +
>   return 0;
>  }
>  
> @@ -733,6 +738,7 @@ static int fsl_esdhc_cfg_to_priv(struct fsl_esdhc_cfg 
> *cfg,
>   priv->bus_width = cfg->max_bus_width;
>   priv->sdhc_clk = cfg->sdhc_clk;
>   priv->wp_enable  = cfg->wp_enable;
> + priv->vs18_enable  = cfg->vs18_enable;

cfg->vs18_enable is u8, but priv->vs18_enable is int..

>  
>   return 0;
>  };
> @@ -759,6 +765,9 @@ static int fsl_esdhc_init(struct fsl_esdhc_priv *priv)
>   VENDORSPEC_HCKEN | VENDORSPEC_IPGEN | VENDORSPEC_CKEN);
>  #endif
>  
> + if (priv->vs18_enable)
> + esdhc_setbits32(>vendorspec, ESDHC_VENDORSPEC_VSELECT);
> +
>   writel(SDHCI_IRQ_EN_BITS, >irqstaten);
>   memset(>cfg, 0, sizeof(priv->cfg));
>  
> diff --git a/include/fsl_esdhc.h b/include/fsl_esdhc.h
> index e15d3ae..7a5d653 100644
> --- a/include/fsl_esdhc.h
> +++ b/include/fsl_esdhc.h
> @@ -178,6 +178,7 @@ struct fsl_esdhc_cfg {
>   u32 sdhc_clk;
>   u8  max_bus_width;
>   u8  wp_enable;
> + u8  vs18_enable; /* Use 1.8V if set to 1 */
>   struct mmc_config cfg;
>  };
>  
> 

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

Re: [U-Boot] [PATCH 7/8] drivers/power/regulator/max77686.c: Fix comparisons of unsigned expressions

[Jaehoon Chung]

On 05/11/2017 04:20 AM, Tom Rini wrote:
> Inside of
> max77686_buck_volt2hex/max77686_buck_hex2volt/max77686_ldo_volt2hex we
> check that the value we calculate is >= 0 however we declare 'hex' as
> unsigned int making these always true.  Mark these as 'int' instead.  We
> also move hex_max to int as they are constants that are 0x3f/0xff.
> Given that the above functions are marked as returning an int, make the
> variables we assign their return value to also be int to be able to
> catch the error condition now.  Reported by clang-3.8.
> 
> Cc: Jaehoon Chung 
> Signed-off-by: Tom Rini 

Applied to u-boot-mmc for pmic. Thanks.

> ---
>  drivers/power/regulator/max77686.c | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/power/regulator/max77686.c 
> b/drivers/power/regulator/max77686.c
> index 7479af734ade..5e5815f39789 100644
> --- a/drivers/power/regulator/max77686.c
> +++ b/drivers/power/regulator/max77686.c
> @@ -71,8 +71,8 @@ static const char max77686_buck_out[] = {
>  
>  static int max77686_buck_volt2hex(int buck, int uV)
>  {
> - unsigned int hex = 0;
> - unsigned int hex_max = 0;
> + int hex = 0;
> + int hex_max = 0;
>  
>   switch (buck) {
>   case 2:
> @@ -105,7 +105,7 @@ static int max77686_buck_volt2hex(int buck, int uV)
>  static int max77686_buck_hex2volt(int buck, int hex)
>  {
>   unsigned uV = 0;
> - unsigned int hex_max = 0;
> + int hex_max = 0;
>  
>   if (hex < 0)
>   goto bad_hex;
> @@ -140,7 +140,7 @@ bad_hex:
>  
>  static int max77686_ldo_volt2hex(int ldo, int uV)
>  {
> - unsigned int hex = 0;
> + int hex = 0;
>  
>   switch (ldo) {
>   case 1:
> @@ -319,9 +319,9 @@ static int max77686_ldo_modes(int ldo, struct 
> dm_regulator_mode **modesp,
>  
>  static int max77686_ldo_val(struct udevice *dev, int op, int *uV)
>  {
> - unsigned int hex, adr;
> + unsigned int adr;
>   unsigned char val;
> - int ldo, ret;
> + int hex, ldo, ret;
>  
>   if (op == PMIC_OP_GET)
>   *uV = 0;
> @@ -360,9 +360,9 @@ static int max77686_ldo_val(struct udevice *dev, int op, 
> int *uV)
>  
>  static int max77686_buck_val(struct udevice *dev, int op, int *uV)
>  {
> - unsigned int hex, mask, adr;
> + unsigned int mask, adr;
>   unsigned char val;
> - int buck, ret;
> + int hex, buck, ret;
>  
>   buck = dev->driver_data;
>   if (buck < 1 || buck > MAX77686_BUCK_NUM) {
> 

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

Re: [U-Boot] [PATCH 6/8] mmc: Change 'part_config' to be a u8 not char.

[Jaehoon Chung]

Hi Tom,

On 05/11/2017 04:20 AM, Tom Rini wrote:
> In some places we check if part_config is set to MMCPART_NOAVAILABLE
> (0xff).  With part_config being a char this is always false.  We should
> be using a u8 to store this value instead, after a quick consultation
> with the Linux Kernel.  Reported by clang-3.8.
> 
> Cc: Jaehoon Chung 
> Signed-off-by: Tom Rini 

Applied to u-boot-mmc. Thanks!

> ---
>  include/mmc.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/mmc.h b/include/mmc.h
> index fad12d608cef..00576fa3d0a3 100644
> --- a/include/mmc.h
> +++ b/include/mmc.h
> @@ -430,7 +430,7 @@ struct mmc {
>   u8 part_support;
>   u8 part_attr;
>   u8 wr_rel_set;
> - char part_config;
> + u8 part_config;
>   uint tran_speed;
>   uint read_bl_len;
>   uint write_bl_len;
> 

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

Re: [U-Boot] [PATCH 01/33] mmc: select the available type from host_caps and card_caps

[Jaehoon Chung]

Hi Ziyuan,

On 05/25/2017 05:12 PM, Ziyuan wrote:
> hi Jaehoon,
> 
> On 05/16/2017 09:55 AM, Jaehoon Chung wrote:
>> Hi Ziyuan,
>>
>> On 05/16/2017 10:15 AM, Ziyuan wrote:
>>> hi Simon & Jaehoon,
>>>
>>> On 05/16/2017 08:18 AM, Simon Glass wrote:
 Hi Ziyuan,

 On 15 May 2017 at 00:06, Ziyuan Xu  wrote:
> The original implementation select HS timing by default, add available
> type selection for higher speed mode compatibility, such as hs200,
> hs400, hs400es.
>
> By the way, we assume that card run at 1.8V or 1.2V I/O when its timing
> is ddr52/hs200/hs400(es).
>
> Signed-off-by: Ziyuan Xu 
> ---
>
>drivers/mmc/mmc.c | 59 
> ++-
>include/mmc.h | 16 +++
>2 files changed, 74 insertions(+), 1 deletion(-)
>
 Is there a cover letter for this series, please?
>>> This patchset is used for hs200/hs400/ddr52 mode of eMMC device, and fixes 
>>> some bug for dw_mmc & sdhci controller.
>>> It's only valid in U-Boot stage, we still use 'High Speed' in SPL.
>>>
>>> I tested it on evb-rk3288 board(eMMC 4.5) and evb-rk3388 board(eMMC 5.0).
 I just reviewed an MMC series at add higher speed support. I'm not
 sure but I suspect these overlap.
>>> Ha, I just reviewed Vignesh's patches, it focuses on uhs mode of sd card. 
>>> It looks to me.
>>> But some details are not the same as mine. Anyway, what do you think?
>> I didn't review both yet..After checking, i will share my opinion. how about?
> 
> *ping*...
> Did you test this patchset on Samsung platform? As far as I know, Samsung 
> SoCs also make use of dw_mmc and sdhci controllers.

some details are not the same as yours..but some points are duplicated.
DWMMC and  sdhci controller side are not duplicated..

As i am feeling..your patches are based on Linux kernel code..right?

> 
>>
 Regards,
 Simon



>>>
>>>
>>>
>>>
>>
>>
>>
> 
> 
> 
> 
> 

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

Re: [U-Boot] [PATCH 06/33] mmc: add card_busy to query card status

[Jaehoon Chung]

On 05/15/2017 03:07 PM, Ziyuan Xu wrote:
> Card devices get into busy status since host request speed mode
> switch, if host controller is able to query whether the device is busy,
> try it instead of sending cmd13.

This patch is similar to one of Jean-Jacques's patches.

> 
> Signed-off-by: Ziyuan Xu 
> ---
> 
>  drivers/mmc/mmc-uclass.c | 16 
>  drivers/mmc/mmc.c| 13 +
>  include/mmc.h| 11 +++
>  3 files changed, 40 insertions(+)
> 
> diff --git a/drivers/mmc/mmc-uclass.c b/drivers/mmc/mmc-uclass.c
> index 9c07871..a300a6d 100644
> --- a/drivers/mmc/mmc-uclass.c
> +++ b/drivers/mmc/mmc-uclass.c
> @@ -38,6 +38,22 @@ int mmc_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd, 
> struct mmc_data *data)
>   return dm_mmc_send_cmd(mmc->dev, cmd, data);
>  }
>  
> +bool mmc_card_busy(struct mmc *mmc)
> +{
> + struct dm_mmc_ops *ops = mmc_get_ops(mmc->dev);
> +
> + if (!ops->card_busy)
> + return -ENOSYS;

return is ENOSYS but this function is return bool type..fix it.

> + return ops->card_busy(mmc->dev);
> +}
> +
> +bool mmc_can_card_busy(struct mmc *mmc)
> +{
> + struct dm_mmc_ops *ops = mmc_get_ops(mmc->dev);
> +
> + return !!ops->card_busy;
> +}
> +
>  int dm_mmc_set_ios(struct udevice *dev)
>  {
>   struct dm_mmc_ops *ops = mmc_get_ops(dev);
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index 0b30172..13d8f04 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -1156,6 +1156,19 @@ static void mmc_set_ios(struct mmc *mmc)
>   if (mmc->cfg->ops->set_ios)
>   mmc->cfg->ops->set_ios(mmc);
>  }
> +
> +static bool mmc_card_busy(struct mmc *mmc)
> +{
> + if (!mmc->cfg->ops->card_busy)
> + return -ENOSYS;
> +
> + return mmc->cfg->ops->card_busy(mmc);

ditto.

> +}
> +
> +static bool mmc_can_card_busy(struct mmc *)
> +{
> + return !!mmc->cfg->ops->card_busy;
> +}
>  #endif
>  
>  void mmc_set_clock(struct mmc *mmc, uint clock)
> diff --git a/include/mmc.h b/include/mmc.h
> index 060c1f8..9bed935 100644
> --- a/include/mmc.h
> +++ b/include/mmc.h
> @@ -357,6 +357,14 @@ struct dm_mmc_ops {
>   struct mmc_data *data);
>  
>   /**
> +  * card_busy() - Query the card device status
> +  *
> +  * @dev:Device to update
> +  * @return true if card device is busy
> +  */
> + bool (*card_busy)(struct udevice *dev);
> +
> + /**
>* set_ios() - Set the I/O speed/width for an MMC device
>*
>* @dev:Device to update
> @@ -390,12 +398,15 @@ int dm_mmc_get_cd(struct udevice *dev);
>  int dm_mmc_get_wp(struct udevice *dev);
>  
>  /* Transition functions for compatibility */
> +bool mmc_card_busy(struct mmc *mmc);
> +bool mmc_can_card_busy(struct mmc *mmc);
>  int mmc_set_ios(struct mmc *mmc);
>  int mmc_getcd(struct mmc *mmc);
>  int mmc_getwp(struct mmc *mmc);
>  
>  #else
>  struct mmc_ops {
> + bool (*card_busy)(struct mmc *mmc);
>   int (*send_cmd)(struct mmc *mmc,
>   struct mmc_cmd *cmd, struct mmc_data *data);
>   int (*set_ios)(struct mmc *mmc);
> 

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

Re: [U-Boot] [PATCH 21/22] mmc: Change mode when switching to a boot partition

[Jaehoon Chung]

On 05/13/2017 03:16 AM, Jean-Jacques Hiblot wrote:
> Boot partitions do not support HS200. Changing to a lower performance mode
> is required to access them.
> mmc_select_mode_and_width() and sd_select_mode_and_width() are modified to
> make it easier to call them outside of the initialization context.

This patch should be important to support the HS200 mode on u-boot..
So i need to test this..more detail..

> 
> Signed-off-by: Jean-Jacques Hiblot 
> ---
>  drivers/mmc/mmc.c | 66 
> +--
>  include/mmc.h |  1 +
>  2 files changed, 50 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index 074d286..c7dda64 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -32,6 +32,7 @@ static const unsigned int sd_au_size[] = {
>  static int mmc_set_signal_voltage(struct mmc *mmc, uint signal_voltage);
>  static void mmc_power_cycle(struct mmc *mmc);
>  static int mmc_card_busy(struct mmc *mmc);
> +static int mmc_select_mode_and_width(struct mmc *mmc, uint card_caps);
>  
>  #if CONFIG_IS_ENABLED(MMC_TINY)
>  static struct mmc mmc_static;
> @@ -788,10 +789,38 @@ static int mmc_set_capacity(struct mmc *mmc, int 
> part_num)
>   return 0;
>  }
>  
> +static int mmc_boot_part_access_chk(struct mmc *mmc, unsigned int part_num)
> +{
> + int forbiden = 0;

forbiden? typo?

> + bool change = false;
> +
> + if (part_num & PART_ACCESS_MASK)
> + forbiden = MMC_CAP(MMC_HS_200);
> +
> + if (MMC_CAP(mmc->selected_mode) & forbiden) {
> + debug("selected mode (%s) is forbiden for part %d\n",
> +   mmc_mode_name(mmc->selected_mode), part_num);
> + change = true;
> + } else if (mmc->selected_mode != mmc->best_mode) {
> + debug("selected mode is not optimal\n");
> + change = true;
> + }
> +
> + if (change)
> + return mmc_select_mode_and_width(mmc,
> +  mmc->card_caps & ~forbiden);
> +
> + return 0;
> +}
> +
>  int mmc_switch_part(struct mmc *mmc, unsigned int part_num)
>  {
>   int ret;
>  
> + ret = mmc_boot_part_access_chk(mmc, part_num);
> + if (ret)
> + return ret;
> +
>   ret = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_PART_CONF,
>(mmc->part_config & ~PART_ACCESS_MASK)
>| (part_num & PART_ACCESS_MASK));
> @@ -1438,7 +1467,7 @@ static const struct mode_width_tuning 
> sd_modes_by_pref[] = {
>mwt++) \
>   if (caps & MMC_CAP(mwt->mode))
>  
> -static int sd_select_mode_and_width(struct mmc *mmc)
> +static int sd_select_mode_and_width(struct mmc *mmc, uint card_caps)
>  {
>   int err;
>   uint widths[] = {MMC_MODE_4BIT, MMC_MODE_1BIT};
> @@ -1447,11 +1476,8 @@ static int sd_select_mode_and_width(struct mmc *mmc)
>   uint caps;
>  
>  
> - err = sd_get_capabilities(mmc);
> - if (err)
> - return err;
>   /* Restrict card's capabilities by what the host can do */
> - caps = mmc->card_caps & (mmc->cfg->host_caps | MMC_MODE_1BIT);
> + caps = card_caps & (mmc->cfg->host_caps | MMC_MODE_1BIT);
>  
>   if (!uhs_en)
>   caps &= ~UHS_CAPS;
> @@ -1582,18 +1608,14 @@ static const struct ext_csd_bus_width {
>   ecbv++) \
>   if ((ddr == ecbv->is_ddr) && (caps & ecbv->cap))
>  
> -static int mmc_select_mode_and_width(struct mmc *mmc)
> +static int mmc_select_mode_and_width(struct mmc *mmc, uint card_caps)
>  {
>   int err;
>   const struct mode_width_tuning *mwt;
>   const struct ext_csd_bus_width *ecbw;
>  
> - err = mmc_get_capabilities(mmc);
> - if (err)
> - return err;
> -
>   /* Restrict card's capabilities by what the host can do */
> - mmc->card_caps &= (mmc->cfg->host_caps | MMC_MODE_1BIT);
> + card_caps &= (mmc->cfg->host_caps | MMC_MODE_1BIT);
>  
>   /* Only version 4 of MMC supports wider bus widths */
>   if (mmc->version < MMC_VERSION_4)
> @@ -1605,8 +1627,10 @@ static int mmc_select_mode_and_width(struct mmc *mmc)
>   return -ENOTSUPP;
>   }
>  
> - for_each_mmc_mode_by_pref(mmc->card_caps, mwt) {
> - for_each_supported_width(mmc->card_caps & mwt->widths,
> + mmc_set_clock(mmc, mmc->legacy_speed, false);
> +
> + for_each_mmc_mode_by_pref(card_caps, mwt) {
> + for_each_supported_width(card_caps & mwt->widths,
>mmc_is_mode_ddr(mwt->mode), ecbw) {
>   debug("trying mode %s width %d (at %d MHz)\n",
> mmc_mode_name(mwt->mode),
> @@ -1999,14 +2023,22 @@ static int mmc_startup(struct mmc *mmc)
>   if (err)
>   return err;
>  
> - if (IS_SD(mmc))
> - err = sd_select_mode_and_width(mmc);
> - else
> - err = mmc_select_mode_and_width(mmc);
> 

Re: [U-Boot] [PATCH 20/22] mmc: Add support for UHS modes

[Jaehoon Chung]

On 05/13/2017 03:16 AM, Jean-Jacques Hiblot wrote:
> Add UHS modes to the list of supported modes, get the UHS capabilites of
> the SDcard and implement the procedure to switch the voltage (UHS modes
> use 1v8 IO lines)
> During the voltage switch procedure, DAT0 is used by the card to signal
> when it's ready. The optional card_busy() callback can be used to get this
> information from the host driver.
> 
> Signed-off-by: Jean-Jacques Hiblot 
> ---
>  drivers/mmc/mmc.c | 169 
> +++---
>  include/mmc.h |  27 -
>  2 files changed, 188 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index f6509f1..074d286 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -31,6 +31,7 @@ static const unsigned int sd_au_size[] = {
>  };
>  static int mmc_set_signal_voltage(struct mmc *mmc, uint signal_voltage);
>  static void mmc_power_cycle(struct mmc *mmc);
> +static int mmc_card_busy(struct mmc *mmc);
>  
>  #if CONFIG_IS_ENABLED(MMC_TINY)
>  static struct mmc mmc_static;
> @@ -403,7 +404,68 @@ static int mmc_go_idle(struct mmc *mmc)
>   return 0;
>  }
>  
> -static int sd_send_op_cond(struct mmc *mmc)
> +static int mmc_switch_voltage(struct mmc *mmc, int signal_voltage)
> +{
> + struct mmc_cmd cmd;
> + int err = 0;
> +
> + /*
> +  * Send CMD11 only if the request is to switch the card to
> +  * 1.8V signalling.
> +  */
> + if (signal_voltage == MMC_SIGNAL_VOLTAGE_330)
> + return mmc_set_signal_voltage(mmc, signal_voltage);
> +
> + cmd.cmdidx = SD_CMD_SWITCH_UHS18V;
> + cmd.cmdarg = 0;
> + cmd.resp_type = MMC_RSP_R1;
> +
> + err = mmc_send_cmd(mmc, , NULL);
> + if (err)
> + goto fail;

goto fail..then it's changed the error number..just return err.

> +
> + if (!mmc_host_is_spi(host) && (cmd.response[0] & MMC_STATUS_ERROR))
> + goto fail;
> +
> + /*
> +  * The card should drive cmd and dat[0:3] low immediately
> +  * after the response of cmd11, but wait 1 ms to be sure
> +  */
> + udelay(1000);
> + if (mmc_card_busy(mmc))
> + goto fail;

If Card is busy..it's not -EIO..it may be -EBUSY.

> +
> + /*
> +  * During a signal voltage level switch, the clock must be gated
> +  * for 5 ms according to the SD spec
> +  */
> + mmc_set_clock(mmc, mmc->clock, true);
> +
> + err = mmc_set_signal_voltage(mmc, signal_voltage);
> + if (err)
> + goto fail;

ditto..return err.

> +
> + /* Keep clock gated for at least 10 ms, though spec only says 5 ms */
> + udelay(1);
> + mmc_set_clock(mmc, mmc->clock, false);
> +
> + /* Wait for at least 1 ms according to spec */
> + udelay(1000);
> +
> + /*
> +  * Failure to switch is indicated by the card holding
> +  * dat[0:3] low
> +  */
> + if (mmc_card_busy(mmc))
> + goto fail;

ditto -EBUSY.

> +
> + return 0;
> +
> +fail:
> + return -EIO;
> +}
> +
> +static int sd_send_op_cond(struct mmc *mmc, bool uhs_en)
>  {
>   int timeout = 1000;
>   int err;
> @@ -435,6 +497,9 @@ static int sd_send_op_cond(struct mmc *mmc)
>   if (mmc->version == SD_VERSION_2)
>   cmd.cmdarg |= OCR_HCS;
>  
> + if (uhs_en)
> + cmd.cmdarg |= OCR_S18R;
> +
>   err = mmc_send_cmd(mmc, , NULL);
>  
>   if (err)
> @@ -465,6 +530,13 @@ static int sd_send_op_cond(struct mmc *mmc)
>  
>   mmc->ocr = cmd.response[0];
>  
> + if (!(mmc_host_is_spi(mmc)) && (cmd.response[0] & 0x4100)
> + == 0x4100) {
> + err = mmc_switch_voltage(mmc, MMC_SIGNAL_VOLTAGE_180);
> + if (err)
> + return err;
> + }
> +
>   mmc->high_capacity = ((mmc->ocr & OCR_HCS) == OCR_HCS);
>   mmc->rca = 0;
>  
> @@ -977,6 +1049,7 @@ static int sd_get_capabilities(struct mmc *mmc)
>   ALLOC_CACHE_ALIGN_BUFFER(uint, switch_status, 16);
>   struct mmc_data data;
>   int timeout;
> + u32 sd3_bus_mode;
>  
>   mmc->card_caps = MMC_MODE_1BIT;
>  
> @@ -1058,6 +1131,22 @@ retry_scr:
>   if (__be32_to_cpu(switch_status[3]) & SD_HIGHSPEED_SUPPORTED)
>   mmc->card_caps |= MMC_CAP(SD_HS);
>  
> + /* Version before 3.0 don't support UHS modes */
> + if (mmc->version < SD_VERSION_3)
> + return 0;
> +
> + sd3_bus_mode = __be32_to_cpu(switch_status[3]) >> 16 & 0x1f;
> + if (sd3_bus_mode & SD_MODE_UHS_SDR104)
> + mmc->card_caps |= MMC_CAP(UHS_SDR104);
> + if (sd3_bus_mode & SD_MODE_UHS_SDR50)
> + mmc->card_caps |= MMC_CAP(UHS_SDR50);
> + if (sd3_bus_mode & SD_MODE_UHS_SDR25)
> + mmc->card_caps |= MMC_CAP(UHS_SDR25);
> + if (sd3_bus_mode & SD_MODE_UHS_SDR12)
> + mmc->card_caps |= MMC_CAP(UHS_SDR12);
> + if (sd3_bus_mode & 

Re: [U-Boot] [PATCH 18/22] mmc: add HS200 support in MMC core

[Jaehoon Chung]

On 05/13/2017 03:16 AM, Jean-Jacques Hiblot wrote:
> Add HS200 to the list of supported modes and introduce tuning in the MMC
> startup process.
> 
> Signed-off-by: Kishon Vijay Abraham I 
> Signed-off-by: Jean-Jacques Hiblot 
> ---
>  drivers/mmc/mmc.c | 22 --
>  include/mmc.h | 17 +
>  2 files changed, 37 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index d7d1c91..2b710fe 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -621,6 +621,10 @@ static int mmc_set_card_speed(struct mmc *mmc, enum 
> bus_mode mode)
>   case MMC_HS_52:
>   case MMC_DDR_52:
> speed_bits = EXT_CSD_TIMING_HS;
> +   break;
> + case MMC_HS_200:
> +   speed_bits = EXT_CSD_TIMING_HS200;
> +   break;
>   case MMC_LEGACY:
> speed_bits = EXT_CSD_TIMING_LEGACY;
> break;
> @@ -667,9 +671,12 @@ static int mmc_get_capabilities(struct mmc *mmc)
>  
>   mmc->card_caps |= MMC_MODE_4BIT | MMC_MODE_8BIT;
>  
> - cardtype = ext_csd[EXT_CSD_CARD_TYPE] & 0xf;
> + cardtype = ext_csd[EXT_CSD_CARD_TYPE] & 0x3f;
>  
> - /* High Speed is set, there are two types: 52MHz and 26MHz */
> + if (cardtype & (EXT_CSD_CARD_TYPE_HS200_1_2V |
> + EXT_CSD_CARD_TYPE_HS200_1_8V)) {
> + mmc->card_caps |= MMC_MODE_HS200;
> + }
>   if (cardtype & EXT_CSD_CARD_TYPE_52) {
>   if (cardtype & EXT_CSD_CARD_TYPE_DDR_52)
>   mmc->card_caps |= MMC_MODE_DDR_52MHz;
> @@ -1263,6 +1270,7 @@ void mmc_dump_capabilities(const char *text, uint caps)
>  struct mode_width_tuning {
>   enum bus_mode mode;
>   uint widths;
> + uint tuning;
>  };
>  
>  static int mmc_set_signal_voltage(struct mmc *mmc, uint signal_voltage)
> @@ -1373,6 +1381,7 @@ static const struct mode_width_tuning 
> mmc_modes_by_pref[] = {
>   {
>   .mode = MMC_HS_200,
>   .widths = MMC_MODE_8BIT | MMC_MODE_4BIT,
> + .tuning = MMC_SEND_TUNING_BLOCK_HS200
>   },
>   {
>   .mode = MMC_DDR_52,
> @@ -1473,6 +1482,15 @@ static int mmc_select_mode_and_width(struct mmc *mmc)
>   mmc_select_mode(mmc, mwt->mode);
>   mmc_set_clock(mmc, mmc->tran_speed, false);
>  
> + /* execute tuning if needed */
> + if (mwt->tuning) {
> + err = mmc_execute_tuning(mmc, mwt->tuning);
> + if (err) {
> + debug("tuning failed\n");
> + goto error;
> + }
> + }
> +
>   /* do a transfer to check the configuration */
>   err = mmc_read_and_compare_ext_csd(mmc);
>   if (!err)
> diff --git a/include/mmc.h b/include/mmc.h
> index dab68c5..b4ffa6a 100644
> --- a/include/mmc.h
> +++ b/include/mmc.h
> @@ -56,6 +56,7 @@
>  #define MMC_MODE_HS  (MMC_CAP(MMC_HS) | MMC_CAP(SD_HS))
>  #define MMC_MODE_HS_52MHzMMC_CAP(MMC_HS_52)
>  #define MMC_MODE_DDR_52MHz   MMC_CAP(MMC_DDR_52)
> +#define MMC_MODE_HS200   MMC_CAP(MMC_HS_200)
>  
>  #define MMC_MODE_8BIT(1 << 30)
>  #define MMC_MODE_4BIT(1 << 29)
> @@ -86,6 +87,7 @@
>  #define MMC_CMD_SET_BLOCKLEN 16
>  #define MMC_CMD_READ_SINGLE_BLOCK17
>  #define MMC_CMD_READ_MULTIPLE_BLOCK  18
> +#define MMC_SEND_TUNING_BLOCK_HS200  21

To maintain the consistency..use the prefix as "MMC_CMD_*", plz.

>  #define MMC_CMD_SET_BLOCK_COUNT 23
>  #define MMC_CMD_WRITE_SINGLE_BLOCK   24
>  #define MMC_CMD_WRITE_MULTIPLE_BLOCK 25
> @@ -113,6 +115,13 @@
>  #define SD_CMD_APP_SEND_OP_COND  41
>  #define SD_CMD_APP_SEND_SCR  51
>  
> +static inline bool mmc_is_tuning_cmd(uint cmdidx)
> +{
> + if (cmdidx == MMC_SEND_TUNING_BLOCK_HS200)
> + return true;
> + return false;

return (cmdidx == MMC_SEND_TUNING_BLOCK_HS200? ...);

> +}
> +
>  /* SCR definitions in different words */
>  #define SD_HIGHSPEED_BUSY0x0002
>  #define SD_HIGHSPEED_SUPPORTED   0x0002
> @@ -210,6 +219,12 @@
>  #define EXT_CSD_CARD_TYPE_DDR_52 (EXT_CSD_CARD_TYPE_DDR_1_8V \
>   | EXT_CSD_CARD_TYPE_DDR_1_2V)
>  
> +#define EXT_CSD_CARD_TYPE_HS200_1_8V (1<<4)  /* Card can run at 200MHz */
> +#define EXT_CSD_CARD_TYPE_HS200_1_2V (1<<5)  /* Card can run at 200MHz */

Use the BIT().

> + /* SDR mode @1.2V I/O */
> +#define EXT_CSD_CARD_TYPE_HS200  (EXT_CSD_CARD_TYPE_HS200_1_8V | 
> \
> +  EXT_CSD_CARD_TYPE_HS200_1_2V)
> +
>  #define EXT_CSD_BUS_WIDTH_1  0   /* Card is in 1 bit mode */
>  #define EXT_CSD_BUS_WIDTH_4  1  

Re: [U-Boot] [PATCH 17/22] mmc: Add a execute_tuning() callback to the mmc operations.

[Jaehoon Chung]

On 05/13/2017 03:16 AM, Jean-Jacques Hiblot wrote:
> Tuning is a mandatory step in the initialization of SDR104 and HS200 modes.
> This callback execute the tuning process.
> 
> Signed-off-by: Jean-Jacques Hiblot 
> ---
>  drivers/mmc/mmc-uclass.c | 14 ++
>  drivers/mmc/mmc.c|  5 +
>  include/mmc.h| 12 
>  3 files changed, 31 insertions(+)
> 
> diff --git a/drivers/mmc/mmc-uclass.c b/drivers/mmc/mmc-uclass.c
> index e1f7995..b7433cf 100644
> --- a/drivers/mmc/mmc-uclass.c
> +++ b/drivers/mmc/mmc-uclass.c
> @@ -93,6 +93,20 @@ int mmc_getcd(struct mmc *mmc)
>  {
>   return dm_mmc_get_cd(mmc->dev);
>  }
> +
> +int dm_mmc_execute_tuning(struct udevice *dev, uint opcode)
> +{
> + struct dm_mmc_ops *ops = mmc_get_ops(dev);
> +
> + if (!ops->execute_tuning)
> + return -ENOSYS;
> + return ops->execute_tuning(dev, opcode);
> +}
> +
> +int mmc_execute_tuning(struct mmc *mmc, uint opcode)
> +{
> + return dm_mmc_execute_tuning(mmc->dev, opcode);
> +}
>  #endif
>  
>  struct mmc *mmc_get_mmc_dev(struct udevice *dev)
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index 415484e..d7d1c91 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -219,6 +219,11 @@ int mmc_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd, 
> struct mmc_data *data)
>  
>   return ret;
>  }
> +
> +int mmc_execute_tuning(struct mmc *mmc, uint opcode)
> +{
> + return mmc->cfg->ops->execute_tuning(mmc, opcode);

Doesn't need to check about execute_tuing callback function?

> +}
>  #endif
>  
>  int mmc_send_status(struct mmc *mmc, int timeout)
> diff --git a/include/mmc.h b/include/mmc.h
> index 097a685..dab68c5 100644
> --- a/include/mmc.h
> +++ b/include/mmc.h
> @@ -375,6 +375,15 @@ struct dm_mmc_ops {
>* @return 0 if write-enabled, 1 if write-protected, -ve on error
>*/
>   int (*get_wp)(struct udevice *dev);
> +
> + /**
> +  * execute_tuning() - Start the tuning process
> +  *
> +  * @dev:Device to start the tuning
> +  * @opcode: Command opcode to send
> +  * @return 0 if OK, -ve on error
> +  */
> + int (*execute_tuning)(struct udevice *dev, uint opcode);
>  };
>  
>  #define mmc_get_ops(dev)((struct dm_mmc_ops *)(dev)->driver->ops)
> @@ -385,12 +394,14 @@ int dm_mmc_set_ios(struct udevice *dev);
>  int dm_mmc_set_vdd(struct udevice *dev, bool enable);
>  int dm_mmc_get_cd(struct udevice *dev);
>  int dm_mmc_get_wp(struct udevice *dev);
> +int dm_mmc_execute_tuning(struct udevice *dev, uint opcode);
>  
>  /* Transition functions for compatibility */
>  int mmc_set_ios(struct mmc *mmc);
>  int mmc_set_vdd(struct mmc *mmc, bool enable);
>  int mmc_getcd(struct mmc *mmc);
>  int mmc_getwp(struct mmc *mmc);
> +int mmc_execute_tuning(struct mmc *mmc, uint opcode);
>  
>  #else
>  struct mmc_ops {
> @@ -401,6 +412,7 @@ struct mmc_ops {
>   int (*set_vdd)(struct mmc *mmc, bool enable);
>   int (*getcd)(struct mmc *mmc);
>   int (*getwp)(struct mmc *mmc);
> + int (*execute_tuning)(struct mmc *mmc, uint opcode);
>  };
>  #endif
>  
> 

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

Re: [U-Boot] [PATCH 14/22] mmc: add power cyle support in mmc core

[Jaehoon Chung]

On 05/13/2017 03:16 AM, Jean-Jacques Hiblot wrote:
> mmc/sd specification requires vdd to be disabled for 1 ms
> and then enabled again during power cycle. Add a
> function in mmc core to perform power cycle and set
> the io signal to it's initial state.
> 
> Signed-off-by: Kishon Vijay Abraham I 
> Signed-off-by: Jean-Jacques Hiblot 
> ---
>  drivers/mmc/mmc.c | 50 +-
>  1 file changed, 41 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index d40a22b..032260b 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -30,6 +30,7 @@ static const unsigned int sd_au_size[] = {
>   SZ_16M / 512,   (SZ_16M + SZ_8M) / 512, SZ_32M / 512,   SZ_64M / 512,
>  };
>  static int mmc_set_signal_voltage(struct mmc *mmc, uint signal_voltage);
> +static void mmc_power_cycle(struct mmc *mmc);
>  
>  #if CONFIG_IS_ENABLED(MMC_TINY)
>  static struct mmc mmc_static;
> @@ -1915,6 +1916,45 @@ static int mmc_power_init(struct mmc *mmc)
>   return 0;
>  }
>  
> +static void mmc_set_initial_state(struct mmc *mmc)
> +{
> + int err;
> +
> + /* First try to set 3.3V. If it fails set to 1.8V */
> + err = mmc_set_signal_voltage(mmc, MMC_SIGNAL_VOLTAGE_330);
> + if (err != 0)
> + err = mmc_set_signal_voltage(mmc, MMC_SIGNAL_VOLTAGE_180);
> + if (err != 0)
> + printf("failed to set signal voltage\n");
> +
> + mmc_set_bus_width(mmc, 1);
> + mmc_set_clock(mmc, 1);
> + mmc_select_mode(mmc, MMC_LEGACY);
> +}
> +
> +static void mmc_power_up(struct mmc *mmc)
> +{
> + mmc_set_initial_state(mmc);
> + mmc_set_vdd(mmc, true);

mmc_set_vdd has the return value..but there are no usage anywhere..
if this is correct, mmc_set_vdd can be *void* type.

> + udelay(1);
> +}
> +
> +static void mmc_power_off(struct mmc *mmc)
> +{
> + mmc_set_vdd(mmc, false);
> +}
> +
> +static void mmc_power_cycle(struct mmc *mmc)
> +{
> + mmc_power_off(mmc);
> + /*
> +  * SD spec recommends at least 1ms of delay. Let's wait for 2ms
> +  * to be on the safer side.
> +  */

Could you put the SD spec version and about which part...?
I didn't find the 2ms so..i want to see the spec about 2ms.

> + udelay(2000);
> + mmc_power_up(mmc);
> +}
> +
>  int mmc_start_init(struct mmc *mmc)
>  {
>   bool no_card;
> @@ -1952,16 +1992,8 @@ int mmc_start_init(struct mmc *mmc)
>   return err;
>  #endif
>   mmc->ddr_mode = 0;
> - mmc_set_vdd(mmc, true);
> - /* First try to set 3.3V. If it fails set to 1.8V */
> - err = mmc_set_signal_voltage(mmc, MMC_SIGNAL_VOLTAGE_330);
> - if (err != 0)
> - err = mmc_set_signal_voltage(mmc, MMC_SIGNAL_VOLTAGE_180);
> - if (err != 0)
> - printf("failed to set signal voltage\n");
>  
> - mmc_set_bus_width(mmc, 1);
> - mmc_set_clock(mmc, 1);
> + mmc_power_cycle(mmc);
>  
>   /* Reset the Card */
>   err = mmc_go_idle(mmc);
> 

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

Re: [U-Boot] [PATCH 10/22] mmc: refactor MMC startup to make it easier to support new modes

[Jaehoon Chung]

On 05/13/2017 03:16 AM, Jean-Jacques Hiblot wrote:
> The MMC startup process currently handles 4 modes. To make it easier to
> add support for more modes, let's make the process more generic and use a
> list of the modes to try.
> The major functional change is that when a mode fails we try the next one.
> Not all modes are tried, only those supported by the card and the host.
> 
> Signed-off-by: Jean-Jacques Hiblot 
> ---
>  drivers/mmc/mmc.c | 238 
> +-
>  include/mmc.h |  15 +++-
>  2 files changed, 157 insertions(+), 96 deletions(-)
> 
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index f42a0fe..2931871 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -200,6 +200,7 @@ static int mmc_select_mode(struct mmc *mmc, enum bus_mode 
> mode)
>  {
>   mmc->selected_mode = mode;
>   mmc->tran_speed = mmc_mode2freq(mmc, mode);
> + mmc->ddr_mode = mmc_is_mode_ddr(mode);
>   debug("selecting mode %s (freq : %d MHz)\n", mmc_mode_name(mode),
> mmc->tran_speed / 100);
>   return 0;
> @@ -602,11 +603,46 @@ int mmc_switch(struct mmc *mmc, u8 set, u8 index, u8 
> value)
>  
>  }
>  
> -static int mmc_change_freq(struct mmc *mmc)
> +static int mmc_set_card_speed(struct mmc *mmc, enum bus_mode mode)
>  {
> - ALLOC_CACHE_ALIGN_BUFFER(u8, ext_csd, MMC_MAX_BLOCK_LEN);
> - char cardtype;
>   int err;
> + int speed_bits;
> + ALLOC_CACHE_ALIGN_BUFFER(u8, test_csd, MMC_MAX_BLOCK_LEN);
> +
> + switch (mode) {
> + case MMC_HS:
> + case MMC_HS_52:
> + case MMC_DDR_52:
> +   speed_bits = EXT_CSD_TIMING_HS;
> + case MMC_LEGACY:
> +   speed_bits = EXT_CSD_TIMING_LEGACY;
> +   break;
> + default:
> +   return -EINVAL;
> + }
> + err = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_HS_TIMING,
> +  speed_bits);
> + if (err)
> + return err;
> +
> + if ((mode == MMC_HS) || (mode == MMC_HS_52)) {
> + /* Now check to see that it worked */
> + err = mmc_send_ext_csd(mmc, test_csd);
> + if (err)
> + return err;
> +
> + /* No high-speed support */
> + if (!test_csd[EXT_CSD_HS_TIMING])
> + return -ENOTSUPP;
> + }
> +
> + return 0;
> +}
> +
> +static int mmc_get_capabilities(struct mmc *mmc)
> +{
> + u8 *ext_csd = mmc->ext_csd;
> + char cardtype;
>  
>   mmc->card_caps = MMC_MODE_1BIT;
>  
> @@ -617,38 +653,23 @@ static int mmc_change_freq(struct mmc *mmc)
>   if (mmc->version < MMC_VERSION_4)
>   return 0;
>  
> - mmc->card_caps |= MMC_MODE_4BIT | MMC_MODE_8BIT;
> -
> - err = mmc_send_ext_csd(mmc, ext_csd);
> + if (!ext_csd) {
> + error("No ext_csd found!\n"); /* this should enver happen */
> + return -ENOTSUPP;
> + }
>  
> - if (err)
> - return err;
> + mmc->card_caps |= MMC_MODE_4BIT | MMC_MODE_8BIT;
>  
>   cardtype = ext_csd[EXT_CSD_CARD_TYPE] & 0xf;
>  
> - err = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_HS_TIMING, 1);
> -
> - if (err)
> - return err;
> -
> - /* Now check to see that it worked */
> - err = mmc_send_ext_csd(mmc, ext_csd);
> -
> - if (err)
> - return err;
> -
> - /* No high-speed support */
> - if (!ext_csd[EXT_CSD_HS_TIMING])
> - return 0;
> -
>   /* High Speed is set, there are two types: 52MHz and 26MHz */
>   if (cardtype & EXT_CSD_CARD_TYPE_52) {
> - if (cardtype & EXT_CSD_CARD_TYPE_DDR_1_8V)
> + if (cardtype & EXT_CSD_CARD_TYPE_DDR_52)
>   mmc->card_caps |= MMC_MODE_DDR_52MHz;
> - mmc->card_caps |= MMC_MODE_HS_52MHz | MMC_MODE_HS;
> - } else {
> - mmc->card_caps |= MMC_MODE_HS;
> + mmc->card_caps |= MMC_MODE_HS_52MHz;
>   }
> + if (cardtype & EXT_CSD_CARD_TYPE_26)
> + mmc->card_caps |= MMC_MODE_HS;
>  
>   return 0;
>  }
> @@ -1320,33 +1341,58 @@ static int mmc_read_and_compare_ext_csd(struct mmc 
> *mmc)
>  }
>  
>  
> -static int mmc_select_bus_freq_width(struct mmc *mmc)
> +static const struct mode_width_tuning mmc_modes_by_pref[] = {
> + {
> + .mode = MMC_HS_200,
> + .widths = MMC_MODE_8BIT | MMC_MODE_4BIT,
> + },
> + {
> + .mode = MMC_DDR_52,
> + .widths = MMC_MODE_8BIT | MMC_MODE_4BIT,
> + },
> + {
> + .mode = MMC_HS_52,
> + .widths = MMC_MODE_8BIT | MMC_MODE_4BIT | MMC_MODE_1BIT,
> + },
> + {
> + .mode = MMC_HS,
> + .widths = MMC_MODE_8BIT | MMC_MODE_4BIT | MMC_MODE_1BIT,
> + },
> + {
> + .mode = MMC_LEGACY,
> + .widths = MMC_MODE_8BIT | MMC_MODE_4BIT | MMC_MODE_1BIT,
> + }
> +};
> +#define 

Re: [U-Boot] Please pull u-boot-fdt, take 2

[Tom Rini]

On Wed, May 24, 2017 at 06:15:25PM -0600, Simon Glass wrote:

> Hi Tom,
> 
> This incorporates the v2 patch for 'fdt: Build the new python libfdt
> module' which should fix the problem with the original pull request.
> 
> 
> The following changes since commit be62fbf376261ab3a4ed5db3bf54d5df9e216d9f:
> 
>   Merge branch 'rmobile' of git://git.denx.de/u-boot-sh (2017-05-23
> 16:22:03 -0400)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-fdt.git
> 
> for you to fetch changes up to da9c601049eb7c993c7f6e33ae10af7a847a483d:
> 
>   fdt: Drop fdt_select.py (2017-05-24 18:12:31 -0600)

NAK.  travis-ci blows up quite badly:
https://travis-ci.org/trini/u-boot/builds/235861889

-- 
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 01/33] mmc: select the available type from host_caps and card_caps

[Jaehoon Chung]

On 05/25/2017 05:12 PM, Ziyuan wrote:
> hi Jaehoon,
> 
> On 05/16/2017 09:55 AM, Jaehoon Chung wrote:
>> Hi Ziyuan,
>>
>> On 05/16/2017 10:15 AM, Ziyuan wrote:
>>> hi Simon & Jaehoon,
>>>
>>> On 05/16/2017 08:18 AM, Simon Glass wrote:
 Hi Ziyuan,

 On 15 May 2017 at 00:06, Ziyuan Xu  wrote:
> The original implementation select HS timing by default, add available
> type selection for higher speed mode compatibility, such as hs200,
> hs400, hs400es.
>
> By the way, we assume that card run at 1.8V or 1.2V I/O when its timing
> is ddr52/hs200/hs400(es).
>
> Signed-off-by: Ziyuan Xu 
> ---
>
>drivers/mmc/mmc.c | 59 
> ++-
>include/mmc.h | 16 +++
>2 files changed, 74 insertions(+), 1 deletion(-)
>
 Is there a cover letter for this series, please?
>>> This patchset is used for hs200/hs400/ddr52 mode of eMMC device, and fixes 
>>> some bug for dw_mmc & sdhci controller.
>>> It's only valid in U-Boot stage, we still use 'High Speed' in SPL.
>>>
>>> I tested it on evb-rk3288 board(eMMC 4.5) and evb-rk3388 board(eMMC 5.0).
 I just reviewed an MMC series at add higher speed support. I'm not
 sure but I suspect these overlap.
>>> Ha, I just reviewed Vignesh's patches, it focuses on uhs mode of sd card. 
>>> It looks to me.
>>> But some details are not the same as mine. Anyway, what do you think?
>> I didn't review both yet..After checking, i will share my opinion. how about?
> 
> *ping*...
> Did you test this patchset on Samsung platform? As far as I know, Samsung 
> SoCs also make use of dw_mmc and sdhci controllers.

Sorry for late..Sure I will test this..Thanks for kindly ping.

Best Regards,
Jaehoon Chung

> 
>>
 Regards,
 Simon



>>>
>>>
>>>
>>>
>>
>>
>>
> 
> 
> 
> 
> 

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

[U-Boot] [PATCH] board: ti: am571-idx: Add vcores support

[Keerthy]

Update vcores for am571-idk board.

Reported-by: Steve Kipisz 
Signed-off-by: Keerthy 
Signed-off-by: Lokesh Vutla 
---
 board/ti/am57xx/board.c | 50 +
 1 file changed, 50 insertions(+)

diff --git a/board/ti/am57xx/board.c b/board/ti/am57xx/board.c
index 3be697a..6d9ee20 100644
--- a/board/ti/am57xx/board.c
+++ b/board/ti/am57xx/board.c
@@ -343,6 +343,54 @@ struct vcores_data am572x_idk_volts = {
.iva.abb_tx_done_mask   = OMAP_ABB_IVA_TXDONE_MASK,
 };
 
+struct vcores_data am571x_idk_volts = {
+   .mpu.value[OPP_NOM] = VDD_MPU_DRA7_NOM,
+   .mpu.efuse.reg[OPP_NOM] = STD_FUSE_OPP_VMIN_MPU_NOM,
+   .mpu.efuse.reg_bits = DRA752_EFUSE_REGBITS,
+   .mpu.addr   = TPS659038_REG_ADDR_SMPS12,
+   .mpu.pmic   = ,
+   .mpu.abb_tx_done_mask = OMAP_ABB_MPU_TXDONE_MASK,
+
+   .eve.value[OPP_NOM] = VDD_EVE_DRA7_NOM,
+   .eve.value[OPP_OD]  = VDD_EVE_DRA7_OD,
+   .eve.value[OPP_HIGH]= VDD_EVE_DRA7_HIGH,
+   .eve.efuse.reg[OPP_NOM] = STD_FUSE_OPP_VMIN_DSPEVE_NOM,
+   .eve.efuse.reg[OPP_OD]  = STD_FUSE_OPP_VMIN_DSPEVE_OD,
+   .eve.efuse.reg[OPP_HIGH]= STD_FUSE_OPP_VMIN_DSPEVE_HIGH,
+   .eve.efuse.reg_bits = DRA752_EFUSE_REGBITS,
+   .eve.addr   = TPS659038_REG_ADDR_SMPS45,
+   .eve.pmic   = ,
+   .eve.abb_tx_done_mask   = OMAP_ABB_EVE_TXDONE_MASK,
+
+   .gpu.value[OPP_NOM] = VDD_GPU_DRA7_NOM,
+   .gpu.value[OPP_OD]  = VDD_GPU_DRA7_OD,
+   .gpu.value[OPP_HIGH]= VDD_GPU_DRA7_HIGH,
+   .gpu.efuse.reg[OPP_NOM] = STD_FUSE_OPP_VMIN_GPU_NOM,
+   .gpu.efuse.reg[OPP_OD]  = STD_FUSE_OPP_VMIN_GPU_OD,
+   .gpu.efuse.reg[OPP_HIGH]= STD_FUSE_OPP_VMIN_GPU_HIGH,
+   .gpu.efuse.reg_bits = DRA752_EFUSE_REGBITS,
+   .gpu.addr   = TPS659038_REG_ADDR_SMPS6,
+   .gpu.pmic   = ,
+   .gpu.abb_tx_done_mask   = OMAP_ABB_GPU_TXDONE_MASK,
+
+   .core.value[OPP_NOM]= VDD_CORE_DRA7_NOM,
+   .core.efuse.reg[OPP_NOM]= STD_FUSE_OPP_VMIN_CORE_NOM,
+   .core.efuse.reg_bits= DRA752_EFUSE_REGBITS,
+   .core.addr  = TPS659038_REG_ADDR_SMPS7,
+   .core.pmic  = ,
+
+   .iva.value[OPP_NOM] = VDD_IVA_DRA7_NOM,
+   .iva.value[OPP_OD]  = VDD_IVA_DRA7_OD,
+   .iva.value[OPP_HIGH]= VDD_IVA_DRA7_HIGH,
+   .iva.efuse.reg[OPP_NOM] = STD_FUSE_OPP_VMIN_IVA_NOM,
+   .iva.efuse.reg[OPP_OD]  = STD_FUSE_OPP_VMIN_IVA_OD,
+   .iva.efuse.reg[OPP_HIGH]= STD_FUSE_OPP_VMIN_IVA_HIGH,
+   .iva.efuse.reg_bits = DRA752_EFUSE_REGBITS,
+   .iva.addr   = TPS659038_REG_ADDR_SMPS45,
+   .iva.pmic   = ,
+   .iva.abb_tx_done_mask   = OMAP_ABB_IVA_TXDONE_MASK,
+};
+
 int get_voltrail_opp(int rail_offset)
 {
int opp;
@@ -452,6 +500,8 @@ void vcores_init(void)
 {
if (board_is_am572x_idk())
*omap_vcores = _idk_volts;
+   else if (board_is_am571x_idk())
+   *omap_vcores = _idk_volts;
else
*omap_vcores = _x15_volts;
 }
-- 
1.9.1

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

[U-Boot] [PATCH] power: pmic: tps65218: Fix tps65218_voltage_update function

[Keerthy]

Currently while setting the vsel value for dcdc1 and dcdc2
the driver is wrongly masking the entire 8 bits in the process
clearing PFM (bit7) field as well. Hence describe an appropriate
mask for vsel field and modify only those bits in the vsel
mask.

Source: http://www.ti.com/lit/ds/symlink/tps65218.pdf

Signed-off-by: Keerthy 
Fixes: 86db550b38 ("power: Add support for the TPS65218 PMIC")
---
 drivers/power/pmic/pmic_tps65218.c | 2 +-
 include/power/tps65218.h   | 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/power/pmic/pmic_tps65218.c 
b/drivers/power/pmic/pmic_tps65218.c
index f32fa40..c5e768a 100644
--- a/drivers/power/pmic/pmic_tps65218.c
+++ b/drivers/power/pmic/pmic_tps65218.c
@@ -101,7 +101,7 @@ int tps65218_voltage_update(uchar dc_cntrl_reg, uchar 
volt_sel)
 
/* set voltage level */
if (tps65218_reg_write(TPS65218_PROT_LEVEL_2, dc_cntrl_reg, volt_sel,
-  TPS65218_MASK_ALL_BITS))
+  TPS65218_DCDC_VSEL_MASK))
return 1;
 
/* set GO bit to initiate voltage transition */
diff --git a/include/power/tps65218.h b/include/power/tps65218.h
index 4d68faa..e3538e2 100644
--- a/include/power/tps65218.h
+++ b/include/power/tps65218.h
@@ -56,6 +56,8 @@ enum {
 
 #define TPS65218_MASK_ALL_BITS 0xFF
 
+#define TPS65218_DCDC_VSEL_MASK0x3F
+
 #define TPS65218_DCDC_VOLT_SEL_0950MV  0x0a
 #define TPS65218_DCDC_VOLT_SEL_1100MV  0x19
 #define TPS65218_DCDC_VOLT_SEL_1200MV  0x23
-- 
1.9.1

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

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

[Marek Vasut]

On 05/25/2017 10:53 AM, Chee, Tien Fong wrote:
> On Rab, 2017-05-24 at 09:56 -0500, Dinh Nguyen wrote:
>>
>> On 05/23/2017 09:24 PM, tien.fong.c...@intel.com wrote:
>>>
>>> From: Tien Fong Chee 
>>>
>>> This is the 6th version of patchset to adds support for Intel Arria
>>> 10 SoC FPGA
>>> driver. This version mainly resolved comments from Dinh in [v5].
>>> This series is working on top of u-boot-socfpga-next branch
>>> http://git.denx.de/?p=u-boot/u-boot-socfpga.git;a=shortlog;h=refs/h
>>> eads/next.
>>>
>>> [v5]: https://www.mail-archive.com/u-boot@lists.denx.de/msg250517.h
>>> tml
>>>
>>> v5 -> v6 changes:
>>> -
>>> - Created separate patch for enabling FPGA driver support.
>>>
>> Please consider at least doing a compile test for this patch series?
>> I'm
>> now very skeptical that you've done any kind of testing on this patch
>> series? :(
>>
>> For 'make socfpga_cyclone5_defconfig:
>>
>> arch/arm/mach-socfpga/built-in.o: In function
>> `socfpga_bridges_reset':
>> /home/dinguyen/linux_dev/u-boot/arch/arm/mach-
>> socfpga/reset_manager_gen5.c:101:
>> undefined reference to `fpgamgr_test_fpga_ready'
>> arch/arm/mach-socfpga/built-in.o: In function
>> `populate_sysmgr_fpgaintf_module':
>> /home/dinguyen/linux_dev/u-boot/arch/arm/mach-
>> socfpga/system_manager_gen5.c:48:
>> undefined reference to `fpgamgr_test_fpga_ready'
>> drivers/built-in.o: In function `sdram_mmr_init_full':
>> /home/dinguyen/linux_dev/u-boot/drivers/ddr/altera/sdram.c:448:
>> undefined reference to `fpgamgr_test_fpga_ready'
>> scripts/Makefile.spl:334: recipe for target 'spl/u-boot-spl' failed
>> make[1]: *** [spl/u-boot-spl] Error 1
>> Makefile:1347: recipe for target 'spl/u-boot-spl' failed
>> make: *** [spl/u-boot-spl] Error 2
>>
>> For socfpga_arria10_defconfig:
>>
>> arch/arm/mach-socfpga/built-in.o: In function `socfpga_fpga_add':
>> /home/dinguyen/linux_dev/u-boot/arch/arm/mach-socfpga/misc.c:110:
>> undefined reference to `fpga_init'
>> /home/dinguyen/linux_dev/u-boot/arch/arm/mach-socfpga/misc.c:112:
>> undefined reference to `fpga_add'
>> scripts/Makefile.spl:334: recipe for target 'spl/u-boot-spl' failed
>> make[1]: *** [spl/u-boot-spl] Error 1
>> Makefile:1347: recipe for target 'spl/u-boot-spl' failed
>> make: *** [spl/u-boot-spl] Error 2
>>
>>
>> Dinh
> 
> I did the compilation on each patch, and testing the patch set on all
> arria10, cyclone5 and arria10 devkit.
> 
> I suspect something wrong with v6-0005-arm-socfpga-Move-FPGA-manager-
> driver-to-FPGA-driv.patch you applied. Could you help me check again
> and confirm all the patches waere applied properly?
> 
> In the meantime, i will clone the lastet from mainstream to confirm
> again. This cloning need take a few hours to finish.

Do you know git fetch origin ? That'll fetch only the new blobs, you
don't need to fetch the whole repo again ...

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

Re: [U-Boot] [PATCH] armv7m: Fix larger builds

[Phil Edworthy]

Hi Vikas,

> On 24 May 2017 18:32 Vikas MANOCHA wrote:
> Hi Phil,
> 
> > On Wednesday, May 24, 2017 7:34 AM Phil Edworthy wrote:
> > The branch instruction only has an 11-bit relative target address, which is
> sometimes not enough.
> >
> > Signed-off-by: Phil Edworthy 
> > ---
> >  arch/arm/cpu/armv7m/start.S | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/cpu/armv7m/start.S b/arch/arm/cpu/armv7m/start.S
> > index 49f2720..d79adb5 100644
> > --- a/arch/arm/cpu/armv7m/start.S
> > +++ b/arch/arm/cpu/armv7m/start.S
> > @@ -8,7 +8,8 @@
> >  .globl reset
> >  .type reset, %function
> >  reset:
> > -   b   _main
> > +   ldr r0, =_main
> > +   mov pc, r0
> 
> How about using W(b) for wider range ?
Yes, that makes better sense!

Thanks
Phil
 
> Cheers,
> Vikas
> 
> >
> >  .globl c_runtime_cpu_setup
> >  c_runtime_cpu_setup:
> > --
> > 2.7.4

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

Re: [U-Boot] i.Mx6q u-boot stuck

[Anatolij Gustschin]

On Wed, 24 May 2017 18:29:50 +0200
Fausto Sessego fausto.sess...@infomob.it wrote:
...
> The Kernel doesn't start.
> 
> U-Boot 2016.07 (May 24 2017 - 17:11:18 +0200)
> 
> CPU:   Freescale i.MX6Q rev1.2 at 792MHz
> CPU:   Industrial temperature grade (-40C to 105C) at 20C
> Reset cause: POR
> Board: i.MX6Q TIBIDABO
> Support: http://www.infomob.it/
> I2C:   ready
> DRAM:  gd->ram_size: 2147483648
> DRAM test not implemented!
> 2 GiB
> MMC:   FSL_SDHC: 0, FSL_SDHC: 1
> *** Warning - bad CRC, using default environment

you didn't save the environment, so the default environment is
used.

> In:serial
> Out:   serial
> Err:   serial
> Net:   FEC [PRIME]
> Error: FEC address not set.
> 
> Hit any key to stop autoboot:  0
> reading imx6q-tibidabo.dtb
> 29640 bytes read in 22 ms (1.3 MiB/s)
> reading uImage
> 6621928 bytes read in 324 ms (19.5 MiB/s)
> ## Booting kernel from Legacy Image at 1200 ...
>Image Name:   Linux-4.1.38
>Image Type:   ARM Linux Kernel Image (uncompressed)
>Data Size:6621864 Bytes = 6.3 MiB
>Load Address: 10008000
>Entry Point:  10008000
>Verifying Checksum ... OK
>Loading Kernel Image ... OK
> 
> Starting kernel ...

Please check 'bootargs' environment variable (print bootargs).
It should contain "console=ttymxc0,115200" among other values.
Probably this is not set in the default environment and is missing.
Ensure that you are passing the correct console string for your
board in bootargs. I'm not sure if ttymxc0 is correct, please
test it first.

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

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

[Chee, Tien Fong]

On Rab, 2017-05-24 at 09:56 -0500, Dinh Nguyen wrote:
> 
> On 05/23/2017 09:24 PM, tien.fong.c...@intel.com wrote:
> > 
> > From: Tien Fong Chee 
> > 
> > This is the 6th version of patchset to adds support for Intel Arria
> > 10 SoC FPGA
> > driver. This version mainly resolved comments from Dinh in [v5].
> > This series is working on top of u-boot-socfpga-next branch
> > http://git.denx.de/?p=u-boot/u-boot-socfpga.git;a=shortlog;h=refs/h
> > eads/next.
> > 
> > [v5]: https://www.mail-archive.com/u-boot@lists.denx.de/msg250517.h
> > tml
> > 
> > v5 -> v6 changes:
> > -
> > - Created separate patch for enabling FPGA driver support.
> > 
> Please consider at least doing a compile test for this patch series?
> I'm
> now very skeptical that you've done any kind of testing on this patch
> series? :(
> 
> For 'make socfpga_cyclone5_defconfig:
> 
> arch/arm/mach-socfpga/built-in.o: In function
> `socfpga_bridges_reset':
> /home/dinguyen/linux_dev/u-boot/arch/arm/mach-
> socfpga/reset_manager_gen5.c:101:
> undefined reference to `fpgamgr_test_fpga_ready'
> arch/arm/mach-socfpga/built-in.o: In function
> `populate_sysmgr_fpgaintf_module':
> /home/dinguyen/linux_dev/u-boot/arch/arm/mach-
> socfpga/system_manager_gen5.c:48:
> undefined reference to `fpgamgr_test_fpga_ready'
> drivers/built-in.o: In function `sdram_mmr_init_full':
> /home/dinguyen/linux_dev/u-boot/drivers/ddr/altera/sdram.c:448:
> undefined reference to `fpgamgr_test_fpga_ready'
> scripts/Makefile.spl:334: recipe for target 'spl/u-boot-spl' failed
> make[1]: *** [spl/u-boot-spl] Error 1
> Makefile:1347: recipe for target 'spl/u-boot-spl' failed
> make: *** [spl/u-boot-spl] Error 2
> 
> For socfpga_arria10_defconfig:
> 
> arch/arm/mach-socfpga/built-in.o: In function `socfpga_fpga_add':
> /home/dinguyen/linux_dev/u-boot/arch/arm/mach-socfpga/misc.c:110:
> undefined reference to `fpga_init'
> /home/dinguyen/linux_dev/u-boot/arch/arm/mach-socfpga/misc.c:112:
> undefined reference to `fpga_add'
> scripts/Makefile.spl:334: recipe for target 'spl/u-boot-spl' failed
> make[1]: *** [spl/u-boot-spl] Error 1
> Makefile:1347: recipe for target 'spl/u-boot-spl' failed
> make: *** [spl/u-boot-spl] Error 2
> 
> 
> Dinh

I did the compilation on each patch, and testing the patch set on all
arria10, cyclone5 and arria10 devkit.

I suspect something wrong with v6-0005-arm-socfpga-Move-FPGA-manager-
driver-to-FPGA-driv.patch you applied. Could you help me check again
and confirm all the patches waere applied properly?

In the meantime, i will clone the lastet from mainstream to confirm
again. This cloning need take a few hours to finish.

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

[U-Boot] [PATCH V7 4/4] rockchip: rk3288: enable rockusb support on rk3288 based device

[Eddie Cai]

this patch enable rockusb support on rk3288 based device.

Signed-off-by: Eddie Cai 
Reviewed-by: Simon Glass 

Changes in v7:
-use imply in the Kconfig to enable rockusb

Changes in v6:
-enable rockusb in defconfig

Changes in v5:
-none

Changes in v4:
-move to rk3288_common.h

Changes in v3:
-move to defconfig

---
 arch/arm/mach-rockchip/Kconfig| 2 ++
 configs/evb-rk3288_defconfig  | 9 +
 configs/fennec-rk3288_defconfig   | 6 ++
 configs/firefly-rk3288_defconfig  | 6 ++
 configs/miqi-rk3288_defconfig | 6 ++
 configs/popmetal-rk3288_defconfig | 6 ++
 configs/tinker-rk3288_defconfig   | 6 ++
 include/configs/rk3288_common.h   | 7 ---
 8 files changed, 41 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
index 2b752ad..8a87812 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -32,6 +32,8 @@ config ROCKCHIP_RK3288
select CPU_V7
select SUPPORT_SPL
select SPL
+   imply USB_FUNCTION_ROCKUSB
+   imply CMD_ROCKUSB
help
  The Rockchip RK3288 is a ARM-based SoC with a quad-core Cortex-A17
  including NEON and GPU, 1MB L2 cache, Mali-T7 graphics, two
diff --git a/configs/evb-rk3288_defconfig b/configs/evb-rk3288_defconfig
index 227150d..cf66e09 100644
--- a/configs/evb-rk3288_defconfig
+++ b/configs/evb-rk3288_defconfig
@@ -17,6 +17,7 @@ CONFIG_CMD_MMC=y
 CONFIG_CMD_SF=y
 CONFIG_CMD_SPI=y
 CONFIG_CMD_I2C=y
+CONFIG_CMD_USB=y
 CONFIG_CMD_GPIO=y
 # CONFIG_CMD_SETEXPR is not set
 CONFIG_CMD_CACHE=y
@@ -61,6 +62,14 @@ CONFIG_DEBUG_UART_CLOCK=2400
 CONFIG_DEBUG_UART_SHIFT=2
 CONFIG_SYS_NS16550=y
 CONFIG_SYSRESET=y
+CONFIG_USB=y
+CONFIG_USB_STORAGE=y
 CONFIG_USE_TINY_PRINTF=y
 CONFIG_CMD_DHRYSTONE=y
 CONFIG_ERRNO_STR=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_GADGET_DOWNLOAD=y
+CONFIG_USB_GADGET_VBUS_DRAW=0
+CONFIG_G_DNL_MANUFACTURER="Rockchip"
+CONFIG_G_DNL_VENDOR_NUM=0x2207
+CONFIG_G_DNL_PRODUCT_NUM=0x320a
diff --git a/configs/fennec-rk3288_defconfig b/configs/fennec-rk3288_defconfig
index befba18..eb33d00 100644
--- a/configs/fennec-rk3288_defconfig
+++ b/configs/fennec-rk3288_defconfig
@@ -66,3 +66,9 @@ CONFIG_USB_STORAGE=y
 CONFIG_USE_TINY_PRINTF=y
 CONFIG_CMD_DHRYSTONE=y
 CONFIG_ERRNO_STR=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_GADGET_DOWNLOAD=y
+CONFIG_USB_GADGET_VBUS_DRAW=0
+CONFIG_G_DNL_MANUFACTURER="Rockchip"
+CONFIG_G_DNL_VENDOR_NUM=0x2207
+CONFIG_G_DNL_PRODUCT_NUM=0x320a
diff --git a/configs/firefly-rk3288_defconfig b/configs/firefly-rk3288_defconfig
index f2872a6..1f4ca32 100644
--- a/configs/firefly-rk3288_defconfig
+++ b/configs/firefly-rk3288_defconfig
@@ -73,3 +73,9 @@ CONFIG_CONSOLE_SCROLL_LINES=10
 CONFIG_USE_TINY_PRINTF=y
 CONFIG_CMD_DHRYSTONE=y
 CONFIG_ERRNO_STR=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_GADGET_DOWNLOAD=y
+CONFIG_USB_GADGET_VBUS_DRAW=0
+CONFIG_G_DNL_MANUFACTURER="Rockchip"
+CONFIG_G_DNL_VENDOR_NUM=0x2207
+CONFIG_G_DNL_PRODUCT_NUM=0x320a
diff --git a/configs/miqi-rk3288_defconfig b/configs/miqi-rk3288_defconfig
index d93bd97..b8b6fd5 100644
--- a/configs/miqi-rk3288_defconfig
+++ b/configs/miqi-rk3288_defconfig
@@ -70,3 +70,9 @@ CONFIG_CONSOLE_SCROLL_LINES=10
 CONFIG_USE_TINY_PRINTF=y
 CONFIG_CMD_DHRYSTONE=y
 CONFIG_ERRNO_STR=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_GADGET_DOWNLOAD=y
+CONFIG_USB_GADGET_VBUS_DRAW=0
+CONFIG_G_DNL_MANUFACTURER="Rockchip"
+CONFIG_G_DNL_VENDOR_NUM=0x2207
+CONFIG_G_DNL_PRODUCT_NUM=0x320a
diff --git a/configs/popmetal-rk3288_defconfig 
b/configs/popmetal-rk3288_defconfig
index 748cda4..1181a20 100644
--- a/configs/popmetal-rk3288_defconfig
+++ b/configs/popmetal-rk3288_defconfig
@@ -66,3 +66,9 @@ CONFIG_USB_STORAGE=y
 CONFIG_USE_TINY_PRINTF=y
 CONFIG_CMD_DHRYSTONE=y
 CONFIG_ERRNO_STR=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_GADGET_DOWNLOAD=y
+CONFIG_USB_GADGET_VBUS_DRAW=0
+CONFIG_G_DNL_MANUFACTURER="Rockchip"
+CONFIG_G_DNL_VENDOR_NUM=0x2207
+CONFIG_G_DNL_PRODUCT_NUM=0x320a
diff --git a/configs/tinker-rk3288_defconfig b/configs/tinker-rk3288_defconfig
index ada5950..f863df8 100644
--- a/configs/tinker-rk3288_defconfig
+++ b/configs/tinker-rk3288_defconfig
@@ -66,3 +66,9 @@ CONFIG_USB_STORAGE=y
 CONFIG_USE_TINY_PRINTF=y
 CONFIG_CMD_DHRYSTONE=y
 CONFIG_ERRNO_STR=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_GADGET_DOWNLOAD=y
+CONFIG_USB_GADGET_VBUS_DRAW=0
+CONFIG_G_DNL_MANUFACTURER="Rockchip"
+CONFIG_G_DNL_VENDOR_NUM=0x2207
+CONFIG_G_DNL_PRODUCT_NUM=0x320a
diff --git a/include/configs/rk3288_common.h b/include/configs/rk3288_common.h
index e7a8f72..421ba60 100644
--- a/include/configs/rk3288_common.h
+++ b/include/configs/rk3288_common.h
@@ -58,11 +58,9 @@
 
 #ifndef CONFIG_SPL_BUILD
 /* usb otg */
-#define CONFIG_USB_GADGET
 #define CONFIG_USB_GADGET_DUALSPEED
 #define CONFIG_USB_GADGET_DWC2_OTG
 #define CONFIG_ROCKCHIP_USB2_PHY
-#define CONFIG_USB_GADGET_VBUS_DRAW0
 
 /* fastboot  */
 #define CONFIG_CMD_FASTBOOT
@@ -76,11 +74,6 @@
 #define 

[U-Boot] [PATCH V7 3/4] rockchip:usb: add a simple readme for rockusb

[Eddie Cai]

add a simple readme to introduce rockusb and tell people how to use it

Signed-off-by: Eddie Cai 
Reviewed-by: Simon Glass 

Changes in v7:
-none

Changes in v6:
-none

Changes in v5:
-none

Changes in v4:
-add some blank line to make it look better

Changes in v3:
-fix checkpatch error

---
 doc/README.rockusb | 51 +++
 1 file changed, 51 insertions(+)
 create mode 100644 doc/README.rockusb

diff --git a/doc/README.rockusb b/doc/README.rockusb
new file mode 100644
index 000..5405dc4
--- /dev/null
+++ b/doc/README.rockusb
@@ -0,0 +1,51 @@
+Rockusb (Rockchip USB protocol)
+=
+
+Overview
+
+
+Rockusb protocol is widely used by Rockchip SoC based devices. It can
+read/write info, image to/from devices. This document briefly describes how to
+use Rockusb for upgrading firmware (e.g. kernel, u-boot, rootfs, etc.).
+
+Tools
+
+There are many tools can support Rockusb protocol. rkdeveloptool
+(https://github.com/rockchip-linux/rkdeveloptool) is open source,
+It is maintained by Rockchip. People don't want to build from source
+can download from here
+(https://github.com/rockchip-linux/rkbin/blob/master/tools/rkdeveloptool)
+
+Usage
+
+The Usage of Rockusb command is:
+
+rockusb   
+
+e.g. rockusb 0 mmc 0
+
+On your U-Boot console, type this command to enter rockusb mode.
+On your host PC. use lsusb command. you should see a usb device
+using 0x2207 as its USB verdor id.
+
+for more detail about the rkdeveloptool. please read the usage.
+
+rkdeveloptool -h
+
+use rkdeveloptool wl command to write lba. BeginSec is the lba on device
+you want to write.
+
+sudo rkdeveloptool wl   
+
+to flash U-Boot image use below command. U-Boot binary is made by mkimage.
+see doc/README.rockchip for more detail about how to get U-Boot binary.
+
+sudo rkdeveloptool wl  64 
+
+There are plenty of Rockusb command. but wl(write lba) and
+rd(reboot) command. These two command can let people flash
+image to device.
+
+To do
+-
+* Fully support Rockusb protocol
-- 
1.9.1

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

[U-Boot] [PATCH V7 2/4] usb: rockchip: add rockusb command

[Eddie Cai]

this patch add rockusb command. the usage is
rockusb   
e.g. rockusb 0 mmc 0

Signed-off-by: Eddie Cai 
Reviewed-by: Simon Glass 

Changes in v7:
-none

Changes in v6:
-none

Changes in v5:
-none

Changes in v4:
-move USB_FUNCTION_ROCKUSB to drivers/usb/gadget/Kconfig
-modify the dependence

Changes in v3:
-fix comment from Simon and Lukasz
-fix checkpactch error

---
 cmd/Kconfig   |  9 
 cmd/Makefile  |  1 +
 cmd/rockusb.c | 74 +++
 3 files changed, 84 insertions(+)
 create mode 100644 cmd/rockusb.c

diff --git a/cmd/Kconfig b/cmd/Kconfig
index d9f7151..81e9bdf 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -518,6 +518,15 @@ config CMD_DFU
  Enables the command "dfu" which is used to have U-Boot create a DFU
  class device via USB.
 
+config CMD_ROCKUSB
+   bool "rockusb"
+   depends on USB_FUNCTION_ROCKUSB
+   help
+  Rockusb protocol is widely used by Rockchip SoC based devices. It can
+ read/write info, image to/from devices. This enable rockusb command
+ support to comunication with rockusb device. for more detail about
+ this command, please read doc/README.rockusb.
+
 config CMD_USB_MASS_STORAGE
bool "UMS usb mass storage"
help
diff --git a/cmd/Makefile b/cmd/Makefile
index e987868..65d998d 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -109,6 +109,7 @@ obj-$(CONFIG_CMD_READ) += read.o
 obj-$(CONFIG_CMD_REGINFO) += reginfo.o
 obj-$(CONFIG_CMD_REISER) += reiser.o
 obj-$(CONFIG_CMD_REMOTEPROC) += remoteproc.o
+obj-$(CONFIG_CMD_ROCKUSB) += rockusb.o
 obj-$(CONFIG_SANDBOX) += host.o
 obj-$(CONFIG_CMD_SATA) += sata.o
 obj-$(CONFIG_CMD_SF) += sf.o
diff --git a/cmd/rockusb.c b/cmd/rockusb.c
new file mode 100644
index 000..ae2baa6
--- /dev/null
+++ b/cmd/rockusb.c
@@ -0,0 +1,74 @@
+/*
+ * Copyright (C) 2017 Eddie Cai 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static int do_rockusb(cmd_tbl_t *cmdtp, int flag, int argc, char *const argv[])
+{
+   int controller_index, dev_index;
+   char *usb_controller;
+   char *devtype;
+   char *devnum;
+   int ret;
+
+   if (argc < 2)
+   return CMD_RET_USAGE;
+
+   usb_controller = argv[1];
+   controller_index = simple_strtoul(usb_controller, NULL, 0);
+
+   if (argc >= 4) {
+   devtype = argv[2];
+   devnum  = argv[3];
+   } else {
+   return CMD_RET_USAGE;
+   }
+   dev_index = simple_strtoul(devnum, NULL, 0);
+   rockusb_dev_init(devtype, dev_index);
+
+   ret = board_usb_init(controller_index, USB_INIT_DEVICE);
+   if (ret) {
+   error("USB init failed: %d", ret);
+   return CMD_RET_FAILURE;
+   }
+
+   g_dnl_clear_detach();
+   ret = g_dnl_register("usb_dnl_rockusb");
+   if (ret)
+   return CMD_RET_FAILURE;
+
+   if (!g_dnl_board_usb_cable_connected()) {
+   puts("\rUSB cable not detected, Command exit.\n");
+   ret = CMD_RET_FAILURE;
+   goto exit;
+   }
+
+   while (1) {
+   if (g_dnl_detach())
+   break;
+   if (ctrlc())
+   break;
+   usb_gadget_handle_interrupts(controller_index);
+   }
+   ret = CMD_RET_SUCCESS;
+
+exit:
+   g_dnl_unregister();
+   g_dnl_clear_detach();
+   board_usb_cleanup(controller_index, USB_INIT_DEVICE);
+
+   return ret;
+}
+
+U_BOOT_CMD(rockusb, 4, 1, do_rockusb,
+  "use the rockusb protocol",
+  "    e.g. rockusb 0 mmc 0\n"
+);
-- 
1.9.1

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