Re: [U-Boot] [PATCH] dm: gpio: handle GPIO_ACTIVE_LOW flag in DT

[Peng Fan]

Hi Eric,

On Fri, Mar 25, 2016 at 01:12:11PM -0700, Eric Nelson wrote:
>Device tree parsing of GPIO nodes is currently ignoring flags.
>
>Add support for GPIO_ACTIVE_LOW by checking for the presence
>of the flag and setting the desc->flags field to the driver
>model constant GPIOD_ACTIVE_LOW.

You may need to try this: https://patchwork.ozlabs.org/patch/597363/

Regards,
Peng.

>
>Signed-off-by: Eric Nelson 
>---
> drivers/gpio/gpio-uclass.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/gpio/gpio-uclass.c b/drivers/gpio/gpio-uclass.c
>index b58d4e6..6d30612 100644
>--- a/drivers/gpio/gpio-uclass.c
>+++ b/drivers/gpio/gpio-uclass.c
>@@ -6,6 +6,7 @@
> 
> #include 
> #include 
>+#include 
> #include 
> #include 
> #include 
>@@ -118,12 +119,16 @@ static int gpio_find_and_xlate(struct gpio_desc *desc,
> {
>   struct dm_gpio_ops *ops = gpio_get_ops(desc->dev);
> 
>+  desc->flags = 0;
>   /* Use the first argument as the offset by default */
>-  if (args->args_count > 0)
>+  if (args->args_count > 0) {
>   desc->offset = args->args[0];
>+  if ((args->args_count > 1) &&
>+  (args->args[1] & GPIO_ACTIVE_LOW))
>+  desc->flags = GPIOD_ACTIVE_LOW;
>+  }
>   else
>   desc->offset = -1;
>-  desc->flags = 0;
> 
>   return ops->xlate ? ops->xlate(desc->dev, desc, args) : 0;
> }
>-- 
>2.6.2
>
>___
>U-Boot mailing list
>U-Boot@lists.denx.de
>http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V2] fsl: esdhc: consolidate fsl_esdhc_cfg structure

[York Sun]

On 03/28/2016 09:44 PM, Peng Fan wrote:
> Hi York,
> 
> On Tue, Mar 29, 2016 at 01:35:09AM +, york sun wrote:
>> On 03/28/2016 06:23 PM, Peng Fan wrote:
>>> Hi York,
>>>
>>> On Tue, Mar 29, 2016 at 12:33:42AM +, york sun wrote:
 On 03/15/2016 03:14 AM, Peng Fan wrote:
> We can use phys_addr_to for esdhc_base to discard
> the #ifdef.
>
> Signed-off-by: Peng Fan 
> Cc: York Sun 
> Cc: Yangbo Lu 
> Cc: Eric Nelson 
> Cc: Fabio Estevam 
> Cc: Pantelis Antoniou 
> Cc: Tom Rini 
> ---
>
> V2:
>  Split this patch from the V1 patch set.
>
>  include/fsl_esdhc.h | 6 +-
>  1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/include/fsl_esdhc.h b/include/fsl_esdhc.h
> index 073048f..fa760a5 100644
> --- a/include/fsl_esdhc.h
> +++ b/include/fsl_esdhc.h
> @@ -168,11 +168,7 @@
>  #define ESDHC_VENDORSPEC_VSELECT 0x0002 /* Use 1.8V */
>  
>  struct fsl_esdhc_cfg {
> -#ifdef CONFIG_FSL_LAYERSCAPE
> - u64 esdhc_base;
> -#else
> - u32 esdhc_base;
> -#endif
> + phys_addr_t esdhc_base;
>   u32 sdhc_clk;
>   u8  max_bus_width;
>   struct mmc_config cfg;
>

 Peng,

 I thought this change is trivial and should be OK. But it turns out this 
 change
 brings comping warning to many PPC boards

 drivers/mmc/fsl_esdhc.c:184:27: warning: cast to pointer from integer of
 different size [-Wint-to-pointer-cast]
>>>
>>> You can apply https://patchwork.ozlabs.org/patch/601919/ and retest.
>>> I think the reason is that to PPC 64bit, "typedef unsigned long long 
>>> phys_addr_t"
>>> I think "esdhc_regs = (struct fsl_esdhc *)(unsigned long)(cfg->esdhc_base);"
>>> can fix it.
>>>
>>> Do I need to send a single V3 patch to fix the warning, or you apply the
>>> driver model V3 patch, if the driver model V3 can fix it?
>>>
>>
>> I am concerned about git bisect. It is not good to have a patch with 
>> compiling
>> warning. I prefer you fix it.
> 
> You can first apply https://patchwork.ozlabs.org/patch/601919/ V3 version
> for driver model patch. In this patch I have such code:
> "esdhc_regs = (struct fsl_esdhc *)(unsigned long)(cfg->esdhc_base);"
> If you think this line code is ok, then you can apply this current patch.
> If not, I think I may also fix this.
> 
> If this is ok for you, no need for me to send V3 :)
> 

Will try tomorrow.

York


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

Re: [U-Boot] [PATCH V2] fsl: esdhc: consolidate fsl_esdhc_cfg structure

[Peng Fan]

Hi York,

On Tue, Mar 29, 2016 at 01:35:09AM +, york sun wrote:
>On 03/28/2016 06:23 PM, Peng Fan wrote:
>> Hi York,
>> 
>> On Tue, Mar 29, 2016 at 12:33:42AM +, york sun wrote:
>>> On 03/15/2016 03:14 AM, Peng Fan wrote:
 We can use phys_addr_to for esdhc_base to discard
 the #ifdef.

 Signed-off-by: Peng Fan 
 Cc: York Sun 
 Cc: Yangbo Lu 
 Cc: Eric Nelson 
 Cc: Fabio Estevam 
 Cc: Pantelis Antoniou 
 Cc: Tom Rini 
 ---

 V2:
  Split this patch from the V1 patch set.

  include/fsl_esdhc.h | 6 +-
  1 file changed, 1 insertion(+), 5 deletions(-)

 diff --git a/include/fsl_esdhc.h b/include/fsl_esdhc.h
 index 073048f..fa760a5 100644
 --- a/include/fsl_esdhc.h
 +++ b/include/fsl_esdhc.h
 @@ -168,11 +168,7 @@
  #define ESDHC_VENDORSPEC_VSELECT 0x0002 /* Use 1.8V */
  
  struct fsl_esdhc_cfg {
 -#ifdef CONFIG_FSL_LAYERSCAPE
 -  u64 esdhc_base;
 -#else
 -  u32 esdhc_base;
 -#endif
 +  phys_addr_t esdhc_base;
u32 sdhc_clk;
u8  max_bus_width;
struct mmc_config cfg;

>>>
>>> Peng,
>>>
>>> I thought this change is trivial and should be OK. But it turns out this 
>>> change
>>> brings comping warning to many PPC boards
>>>
>>> drivers/mmc/fsl_esdhc.c:184:27: warning: cast to pointer from integer of
>>> different size [-Wint-to-pointer-cast]
>> 
>> You can apply https://patchwork.ozlabs.org/patch/601919/ and retest.
>> I think the reason is that to PPC 64bit, "typedef unsigned long long 
>> phys_addr_t"
>> I think "esdhc_regs = (struct fsl_esdhc *)(unsigned long)(cfg->esdhc_base);"
>> can fix it.
>> 
>> Do I need to send a single V3 patch to fix the warning, or you apply the
>> driver model V3 patch, if the driver model V3 can fix it?
>> 
>
>I am concerned about git bisect. It is not good to have a patch with compiling
>warning. I prefer you fix it.

You can first apply https://patchwork.ozlabs.org/patch/601919/ V3 version
for driver model patch. In this patch I have such code:
"esdhc_regs = (struct fsl_esdhc *)(unsigned long)(cfg->esdhc_base);"
If you think this line code is ok, then you can apply this current patch.
If not, I think I may also fix this.

If this is ok for you, no need for me to send V3 :)

Thanks,
Peng.

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

Re: [U-Boot] Newbie SPL question for socfpga_sockit

[George Broz]

On 20 March 2016 at 09:49, Marek Vasut  wrote:
> On 03/18/2016 10:22 PM, George Broz wrote:
>> On 18 March 2016 at 12:32, Marek Vasut  wrote:
>>> On 03/18/2016 07:59 PM, George Broz wrote:
 On 16 March 2016 at 18:35, Marek Vasut  wrote:
> On 03/16/2016 05:17 PM, George Broz wrote:
>> On 15 March 2016 at 18:29, George Broz  wrote:
>>
>>>
>>> Hello again -
>>>
>>> So under the assumption my SoCKit h/w was broken, I bought a new board.
>>> They are back ordered on SoCKit boards, so I got a DE0-Nano-SoC instead.
>>>
>>> I build the v2016.03 (release) version of u-boot-with-spl.sfp.
>>>
>>> I power-up the (brand new) board and get:
>>>
>>> U-Boot SPL 2016.03 (Mar 15 2016 - 14:52:42)
>>> drivers/ddr/altera/sequencer.c: Preparing to start memory calibration
>>> drivers/ddr/altera/sequencer.c: CALIBRATION FAILED
>>> drivers/ddr/altera/sequencer.c: Calibration complete
>>> SDRAM calibration failed.
>>> ### ERROR ### Please RESET the board ###
>>>
>>> U-Boot SPL 2016.03 (Mar 15 2016 - 14:52:42)
>>> drivers/ddr/altera/sequencer.c: Preparing to start memory calibration
>>> drivers/ddr/altera/sequencer.c: CALIBRATION FAILED
>>> drivers/ddr/altera/sequencer.c: Calibration complete
>>> SDRAM calibration failed.
>>> ### ERROR ### Please RESET the board ###
>>>
>>> U-Boot SPL 2016.03 (Mar 15 2016 - 14:52:42)
>>> drivers/ddr/altera/sequencer.c: Preparing to start memory calibration
>>> drivers/ddr/altera/sequencer.c: CALIBRATION PASSED
>>> drivers/ddr/altera/sequencer.c: Calibration complete
>>> Trying to boot from MMC
>>>
>>> U-Boot 2016.03 (Mar 15 2016 - 14:52:42 -0700)
>>>
>>> CPU:   Altera SoCFPGA Platform
>>> FPGA:  Altera Cyclone V, SE/A4 or SX/C4, version 0x0
>>> BOOT:  SD/MMC Internal Transceiver (3.0V)
>>>Watchdog enabled
>>> I2C:   ready
>>> DRAM:  1 GiB
>>> MMC:   dwmmc0@ff704000: 0
>>> In:serial
>>> Out:   serial
>>> Err:   serial
>>> Model: Terasic DE0-Nano(Atlas)
>>> Net:
>>> Error: ethernet@ff702000 address not set.
>>> No ethernet found.
>>> Hit any key to stop autoboot:  0
>>> =>
>>>
>>> And this is a good case... usually it doesn't succeed after the fourth 
>>> try
>>> and I have to cycle power 4 or 5 times before I get lucky.
>>>
>>> If I do get lucky and then try to see a USB storage device, then I get:
>>>
>>> =>
>>> => usb start
>>> starting USB...
>>> USB0:   Core Release: 2.93a
>>> dwc_otg_core_host_init: Timeout!
>>> dwc_otg_core_host_init: Timeout!
>>> dwc_otg_core_host_init: Timeout!
>>> dwc_otg_core_host_init: Timeout!
>>> dwc_otg_core_host_init: Timeout!
>>> dwc_otg_core_host_init: Timeout!
>>> dwc_otg_core_host_init: Timeout!
>>> dwc_otg_core_host_init: Timeout!
>>> dwc_otg_core_host_init: Timeout!
>>> dwc_otg_core_host_init: Timeout!
>>> dwc_otg_core_host_init: Timeout!
>>> dwc_otg_core_host_init: Timeout!
>>> dwc_otg_core_host_init: Timeout!
>>> dwc_otg_core_host_init: Timeout!
>>> dwc_otg_core_host_init: Timeout!
>>> scanning bus 0 for devices... 1 USB Device(s) found
>>> =>
>>>
>>> (Every time)
>>>
>>> The version of u-boot SPL that ships with the board:
>>> U-Boot SPL 2013.01.01 (Dec 29 2014 - 15:29:15)
>>>
>>> boots every time and has limited USB capability as
>>> it can see some USB sticks, but not others.
>>>
>>>
>>> Anyway - brand new board - same old symptoms.
>>>
>>> Is it perhaps a toolchain problem?? I'm using:
>>>
>>> Thread model: posix
>>> gcc version 4.9.3 20141031 (prerelease) (Linaro GCC 4.9-2014.11)
>>>
>>> COLLECT_GCC=arm-poky-linux-gnueabi-gcc
>>> COLLECT_LTO_WRAPPER=/opt/poky/1.7.1/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.3/lto-wrapper
>>> < snip >
>>>
>>> Any advice greatly appreciated.
>>>
>>>
>>> Regards,
>>> --George Broz
>>
>> Rebuilt using the Altera EDS15.0 toolchain:
>>
>>   arm-altera-eabi-gcc --version
>>   arm-altera-eabi-gcc (Sourcery CodeBench Lite 2014.11-13) 4.9.1
>>   Copyright (C) 2014 Free Software Foundation, Inc.
>>   This is free software; see the source for copying conditions.  There 
>> is NO
>>   warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR 
>> PURPOSE.
>>
>>
>> Get same result ... mostly failing calibration, non-working USB
>>
>> U-Boot SPL 2016.03 (Mar 16 2016 - 08:27:20)
>> drivers/ddr/altera/sequencer.c: Preparing to start memory calibration
>> drivers/ddr/altera/sequencer.c: CALIBRATION FAILED
>> drivers/ddr/altera/sequencer.c: Calibration complete
>> SDRAM calibration failed.
>> ### ERROR ### 

Re: [U-Boot] Newbie SPL question for socfpga_sockit

[George Broz]

On 20 March 2016 at 08:55, Dinh Nguyen  wrote:
>
>
> On 03/16/2016 08:35 PM, Marek Vasut wrote:
>>>
>>> Does this work for anybody else?
>>> Is it in anyone's experience that these (cheaper) Terasic
>>> eval boards are generally out of spec?
>>>
>>> Is there a way to relax the calibration parameters? the USB parameters?
>>>
>>> Would it help if I posted debug output?
>>
>> Sorry for the late reply, I am horribly overloaded now. I asked someone
>> in #u-boot who has the DE0-NANO-SOC board to test latest u-boot/master
>> on it and it apparently worked for him. I should get some more feedback
>> in the morning [ see http://pastebin.com/CM1QJGnh ] .
>>
>> Still, this is getting real creepy. You are the second person who is
>> complaining about misbehavior of terasic boards with mainline u-boot
>> and whatever I do, I cannot replicate this.
>>
>> I am at least CCing the Altera guys. Sorry I have no better suggestion
>> for you :(
>
> I don't have any problems with mainline U-Boot and SPL on my DE0-NANO-BOARD:
>
> U-Boot SPL 2016.03-00307-ge4fb863 (Mar 20 2016 - 10:37:13)
> drivers/ddr/altera/sequencer.c: Preparing to start memory calibration
> drivers/ddr/altera/sequencer.c: CALIBRATION PASSED
> drivers/ddr/altera/sequencer.c: Calibration complete
> Trying to boot from MMC
>
>
> U-Boot 2016.03-00307-ge4fb863 (Mar 20 2016 - 10:37:13 -0500)
>
> CPU:   Altera SoCFPGA Platform
> FPGA:  Altera Cyclone V, SE/A4 or SX/C4, version 0x0
> BOOT:  SD/MMC Internal Transceiver (3.0V)
>Watchdog enabled
> I2C:   ready
> DRAM:  1 GiB
> MMC:   dwmmc0@ff704000: 0
> In:serial
> Out:   serial
> Err:   serial
> Model: Terasic DE0-Nano(Atlas)
> Net:   eth0: ethernet@ff702000
> Hit any key to stop autoboot:  0
> =>
>
> Sorry, I know that doesn't help. So let's walk through my workflow. I am
> not using any Altera tools when I build.
>
> $make socfpga_de0_nano_soc_defconfig
> $make u-boot-with-spl.sfp
> $dd if=u-boot-with-spl.sfp of=/dev/sdb3
>
> My gcc is: arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.7.3-12ubuntu1) 4.7.3
>
> Has the board ever worked for you at all? Can you try this image:
>
> https://rocketboards.org/foswiki/view/Documentation/AtlasSoCSdCardImage
>
> Dinh
>
>

Hi All,

Was away...sorry... back again.

Dinh - my workflow is exactly as yours is above.

I've used several toolchains - always the same result.

The first de0_nano_soc board I bought has no problem booting from the
factory supplied image:

   SPL: U-Boot SPL 2013.01.01 (Dec 29 2014 - 15:29:15)
   Image: U-Boot 2013.01.01 (Dec 30 2014 - 12:07:34)

and it even works with some USB sticks.

But if I build a new SPL/image with workflow above using v2016.03

(git clone git://git.denx.de/u-boot.git u-boot/ or git clone
http://git.denx.de/u-boot.git u-boot/)

then I get the intermittent failing memory calibration and no USB
(dwc_otg_core_host_init: Timeout!...)

On my sockit board the memory calibration fails every time.



So I ordered and received a _second_ de0_nano_soc board.

The same SPL/image that was intermittently failing on the first board
works on the second board. I have not seen it fail after 20 reboots.

Unfortunately, USB behaves the same (dwc_otg_core_host_init: Timeout!...)

Not sure what that means... marginal boards from Terasic? Calibration
tests/parameters too stringent?

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

Re: [U-Boot] [PATCH V2] fsl: esdhc: consolidate fsl_esdhc_cfg structure

[york sun]

On 03/28/2016 06:23 PM, Peng Fan wrote:
> Hi York,
> 
> On Tue, Mar 29, 2016 at 12:33:42AM +, york sun wrote:
>> On 03/15/2016 03:14 AM, Peng Fan wrote:
>>> We can use phys_addr_to for esdhc_base to discard
>>> the #ifdef.
>>>
>>> Signed-off-by: Peng Fan 
>>> Cc: York Sun 
>>> Cc: Yangbo Lu 
>>> Cc: Eric Nelson 
>>> Cc: Fabio Estevam 
>>> Cc: Pantelis Antoniou 
>>> Cc: Tom Rini 
>>> ---
>>>
>>> V2:
>>>  Split this patch from the V1 patch set.
>>>
>>>  include/fsl_esdhc.h | 6 +-
>>>  1 file changed, 1 insertion(+), 5 deletions(-)
>>>
>>> diff --git a/include/fsl_esdhc.h b/include/fsl_esdhc.h
>>> index 073048f..fa760a5 100644
>>> --- a/include/fsl_esdhc.h
>>> +++ b/include/fsl_esdhc.h
>>> @@ -168,11 +168,7 @@
>>>  #define ESDHC_VENDORSPEC_VSELECT 0x0002 /* Use 1.8V */
>>>  
>>>  struct fsl_esdhc_cfg {
>>> -#ifdef CONFIG_FSL_LAYERSCAPE
>>> -   u64 esdhc_base;
>>> -#else
>>> -   u32 esdhc_base;
>>> -#endif
>>> +   phys_addr_t esdhc_base;
>>> u32 sdhc_clk;
>>> u8  max_bus_width;
>>> struct mmc_config cfg;
>>>
>>
>> Peng,
>>
>> I thought this change is trivial and should be OK. But it turns out this 
>> change
>> brings comping warning to many PPC boards
>>
>> drivers/mmc/fsl_esdhc.c:184:27: warning: cast to pointer from integer of
>> different size [-Wint-to-pointer-cast]
> 
> You can apply https://patchwork.ozlabs.org/patch/601919/ and retest.
> I think the reason is that to PPC 64bit, "typedef unsigned long long 
> phys_addr_t"
> I think "esdhc_regs = (struct fsl_esdhc *)(unsigned long)(cfg->esdhc_base);"
> can fix it.
> 
> Do I need to send a single V3 patch to fix the warning, or you apply the
> driver model V3 patch, if the driver model V3 can fix it?
> 

I am concerned about git bisect. It is not good to have a patch with compiling
warning. I prefer you fix it.

York


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

Re: [U-Boot] [PATCH] common: env: support sata device

[Peng Fan]

Hi Tom,

Thanks for reviewing.

On Mon, Mar 28, 2016 at 11:15:43AM -0400, Tom Rini wrote:
>On Mon, Mar 28, 2016 at 05:37:16PM +0800, Peng Fan wrote:
>
>> Introduce env support for sata device.
>> 1. Implement write_env/read_env/env_relocate_spec/saveenv/sata_get_env_dev
>> 2. If want to enable this feature, define CONFIG_ENV_IS_IN_SATA, and
>>define CONFIG_SYS_SATA_ENV_DEV or implement your own sata_get_ev_dev.
>[snip]
>> +/*
>> + * TODO: Support CONFIG_ENV_SIZE_REDUND CONFIG_ENV_OFFSET_REDUND
>> + */
>
>I'd like to see #error here as well, having been bit in the past in
>cases of "Oh, redund doesn't work?".

Will fix in V2.

>
>> +#if !defined(CONFIG_ENV_OFFSET) || !defined(CONFIG_ENV_SIZE)
>> +#error CONFIG_ENV_OFFSET or CONFIG_ENV_SIZE not defined
>> +#endif
>> +
>> +char *env_name_spec = "SATA";
>> +
>> +#ifdef ENV_IS_EMBEDDED
>> +env_t *env_ptr = (env_t *)([0]);
>
>So, you're not adding (and I'm not suggesting you do) SATA to the list
>of environment types where we support embedded env.  Please just remove
>these tests here and elsewhere.  Thanks!

Fix in V2.

>
>[snip]
>> +static inline int read_env(struct blk_desc *sata, unsigned long size,
>> +   unsigned long offset, const void *buffer)
>> +{
>> +uint blk_start, blk_cnt, n;
>> +
>> +blk_start = ALIGN(offset, sata->blksz) / sata->blksz;
>> +blk_cnt   = ALIGN(size, sata->blksz) / sata->blksz;
>> +
>> +n = sata->block_read(sata, blk_start, blk_cnt, (uchar *)buffer);
>
>Here and elsewhere, please update to use blk_dread, etc, from blk.h to
>help future proof this code, thanks!

Fix in V2.

Thanks,
Peng.
>
>-- 
>Tom


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

Re: [U-Boot] [PATCH V2] fsl: esdhc: consolidate fsl_esdhc_cfg structure

[Peng Fan]

Hi York,

On Tue, Mar 29, 2016 at 12:33:42AM +, york sun wrote:
>On 03/15/2016 03:14 AM, Peng Fan wrote:
>> We can use phys_addr_to for esdhc_base to discard
>> the #ifdef.
>> 
>> Signed-off-by: Peng Fan 
>> Cc: York Sun 
>> Cc: Yangbo Lu 
>> Cc: Eric Nelson 
>> Cc: Fabio Estevam 
>> Cc: Pantelis Antoniou 
>> Cc: Tom Rini 
>> ---
>> 
>> V2:
>>  Split this patch from the V1 patch set.
>> 
>>  include/fsl_esdhc.h | 6 +-
>>  1 file changed, 1 insertion(+), 5 deletions(-)
>> 
>> diff --git a/include/fsl_esdhc.h b/include/fsl_esdhc.h
>> index 073048f..fa760a5 100644
>> --- a/include/fsl_esdhc.h
>> +++ b/include/fsl_esdhc.h
>> @@ -168,11 +168,7 @@
>>  #define ESDHC_VENDORSPEC_VSELECT 0x0002 /* Use 1.8V */
>>  
>>  struct fsl_esdhc_cfg {
>> -#ifdef CONFIG_FSL_LAYERSCAPE
>> -u64 esdhc_base;
>> -#else
>> -u32 esdhc_base;
>> -#endif
>> +phys_addr_t esdhc_base;
>>  u32 sdhc_clk;
>>  u8  max_bus_width;
>>  struct mmc_config cfg;
>> 
>
>Peng,
>
>I thought this change is trivial and should be OK. But it turns out this change
>brings comping warning to many PPC boards
>
>drivers/mmc/fsl_esdhc.c:184:27: warning: cast to pointer from integer of
>different size [-Wint-to-pointer-cast]

You can apply https://patchwork.ozlabs.org/patch/601919/ and retest.
I think the reason is that to PPC 64bit, "typedef unsigned long long 
phys_addr_t"
I think "esdhc_regs = (struct fsl_esdhc *)(unsigned long)(cfg->esdhc_base);"
can fix it.

Do I need to send a single V3 patch to fix the warning, or you apply the
driver model V3 patch, if the driver model V3 can fix it?

Regards,
Peng.

>
>For assignment like this
>
>struct fsl_esdhc *regs = (struct fsl_esdhc *)cfg->esdhc_base;
>
>The phys_addr is not u32 for many targets.
>
>York
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2] armv8: LS2080A: Consolidate LS2080A and LS2085A

[York Sun]

LS2080A is the primary SoC, and LS2085A is a personality with AIOP
and DPAA DDR. The RDB and QDS boards support both personality. By
detecting the SVR at runtime, a single image per board can support
both SoCs. It gives users flexibility to swtich SoC without the need
to reprogram the board.

Signed-off-by: York Sun 
CC: Prabhakar Kushwaha 

---

Changes in v2:
Add checking for SVR before starting AIOP
Drop RFC from subject

 arch/arm/cpu/armv8/fsl-layerscape/Makefile |4 ---
 arch/arm/cpu/armv8/fsl-layerscape/cpu.c|9 ---
 .../arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c |6 -
 arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S   |2 +-
 arch/arm/cpu/armv8/fsl-layerscape/soc.c|   26 ++-
 arch/arm/cpu/armv8/fsl-layerscape/spl.c|4 +--
 arch/arm/include/asm/arch-fsl-layerscape/config.h  |9 ++-
 arch/arm/include/asm/arch-fsl-layerscape/cpu.h |2 +-
 .../include/asm/arch-fsl-layerscape/fsl_serdes.h   |2 +-
 arch/arm/include/asm/arch-fsl-layerscape/soc.h |3 +++
 board/freescale/ls2080a/ddr.c  |   27 +++-
 board/freescale/ls2080a/ls2080a.c  |2 +-
 board/freescale/ls2080aqds/MAINTAINERS |2 --
 board/freescale/ls2080aqds/ddr.c   |   27 +++-
 board/freescale/ls2080aqds/ls2080aqds.c|2 +-
 board/freescale/ls2080ardb/MAINTAINERS |2 --
 board/freescale/ls2080ardb/ddr.c   |   27 +++-
 board/freescale/ls2080ardb/ls2080ardb.c|2 +-
 configs/ls2085aqds_defconfig   |   19 --
 configs/ls2085aqds_nand_defconfig  |   14 --
 configs/ls2085ardb_defconfig   |   19 --
 configs/ls2085ardb_nand_defconfig  |   14 --
 drivers/net/fsl-mc/mc.c|4 +++
 drivers/net/ldpaa_eth/Makefile |1 -
 include/configs/ls2080a_common.h   |7 +
 include/configs/ls2080a_emu.h  |7 -
 include/configs/ls2080a_simu.h |7 -
 include/linux/usb/xhci-fsl.h   |2 +-
 28 files changed, 100 insertions(+), 152 deletions(-)
 delete mode 100644 configs/ls2085aqds_defconfig
 delete mode 100644 configs/ls2085aqds_nand_defconfig
 delete mode 100644 configs/ls2085ardb_defconfig
 delete mode 100644 configs/ls2085ardb_nand_defconfig

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Makefile 
b/arch/arm/cpu/armv8/fsl-layerscape/Makefile
index cce7405..5f86ef9 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/Makefile
+++ b/arch/arm/cpu/armv8/fsl-layerscape/Makefile
@@ -25,10 +25,6 @@ ifneq ($(CONFIG_LS2080A),)
 obj-$(CONFIG_SYS_HAS_SERDES) += ls2080a_serdes.o
 endif
 
-ifneq ($(CONFIG_LS2085A),)
-obj-$(CONFIG_SYS_HAS_SERDES) += ls2080a_serdes.o
-endif
-
 ifneq ($(CONFIG_LS1043A),)
 obj-$(CONFIG_SYS_HAS_SERDES) += ls1043a_serdes.o
 endif
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c 
b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
index 4b9e209..d939900 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
@@ -538,12 +538,12 @@ int print_cpuinfo(void)
struct sys_info sysinfo;
char buf[32];
unsigned int i, core;
-   u32 type, rcw;
+   u32 type, rcw, svr = gur_in32(>svr);
 
puts("SoC: ");
 
cpu_name(buf);
-   printf(" %s (0x%x)\n", buf, gur_in32(>svr));
+   printf(" %s (0x%x)\n", buf, svr);
memset((u8 *)buf, 0x00, ARRAY_SIZE(buf));
get_sys_info();
puts("Clock Configuration:");
@@ -564,7 +564,10 @@ int print_cpuinfo(void)
printf("  FMAN: %-4s MHz", strmhz(buf, sysinfo.freq_fman[0]));
 #endif
 #ifdef CONFIG_SYS_FSL_HAS_DP_DDR
-   printf(" DP-DDR:   %-4s MT/s", strmhz(buf, sysinfo.freq_ddrbus2));
+   if (soc_has_dp_ddr()) {
+   printf(" DP-DDR:   %-4s MT/s",
+  strmhz(buf, sysinfo.freq_ddrbus2));
+   }
 #endif
puts("\n");
 
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c 
b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c
index 81cf470..d580a43 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c
@@ -97,9 +97,13 @@ void get_sys_info(struct sys_info *sys_info)
FSL_CHASSIS3_RCWSR0_MEM_PLL_RAT_SHIFT) &
FSL_CHASSIS3_RCWSR0_MEM_PLL_RAT_MASK;
 #ifdef CONFIG_SYS_FSL_HAS_DP_DDR
-   sys_info->freq_ddrbus2 *= (gur_in32(>rcwsr[0]) >>
+   if (soc_has_dp_ddr()) {
+   sys_info->freq_ddrbus2 *= (gur_in32(>rcwsr[0]) >>
FSL_CHASSIS3_RCWSR0_MEM2_PLL_RAT_SHIFT) &
FSL_CHASSIS3_RCWSR0_MEM2_PLL_RAT_MASK;
+   } 

[U-Boot] [PATCH v2 0/1] Use LS2080A as the only SoC name

[York Sun]

Not long ago, a change was made in U-Boot to switch the primary SoC from
LS2085A to LS2080A. SoC name and board names were changed. It turns out
the same board support both SoCs with a socket. It is possible to swtich
SoC. In this case, using one unified image is more appropriate. If future
SoC can be hosted on the same boards, they should be added.

At this moment, the board name remains LS2080ARDB and LS2080AQDS. They
don't match the labels on the boards. Should this become a concern, we
can rename the boards in a separated patch.

Tested on LS2085ARDB with both personalities.

Changes in v2:
Add checking for SVR before starting AIOP
Drop RFC from subject

York Sun (1):
  armv8: LS2080A: Consolidate LS2080A and LS2085A

 arch/arm/cpu/armv8/fsl-layerscape/Makefile |4 ---
 arch/arm/cpu/armv8/fsl-layerscape/cpu.c|9 ---
 .../arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c |6 -
 arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S   |2 +-
 arch/arm/cpu/armv8/fsl-layerscape/soc.c|   26 ++-
 arch/arm/cpu/armv8/fsl-layerscape/spl.c|4 +--
 arch/arm/include/asm/arch-fsl-layerscape/config.h  |9 ++-
 arch/arm/include/asm/arch-fsl-layerscape/cpu.h |2 +-
 .../include/asm/arch-fsl-layerscape/fsl_serdes.h   |2 +-
 arch/arm/include/asm/arch-fsl-layerscape/soc.h |3 +++
 board/freescale/ls2080a/ddr.c  |   27 +++-
 board/freescale/ls2080a/ls2080a.c  |2 +-
 board/freescale/ls2080aqds/MAINTAINERS |2 --
 board/freescale/ls2080aqds/ddr.c   |   27 +++-
 board/freescale/ls2080aqds/ls2080aqds.c|2 +-
 board/freescale/ls2080ardb/MAINTAINERS |2 --
 board/freescale/ls2080ardb/ddr.c   |   27 +++-
 board/freescale/ls2080ardb/ls2080ardb.c|2 +-
 configs/ls2085aqds_defconfig   |   19 --
 configs/ls2085aqds_nand_defconfig  |   14 --
 configs/ls2085ardb_defconfig   |   19 --
 configs/ls2085ardb_nand_defconfig  |   14 --
 drivers/net/fsl-mc/mc.c|4 +++
 drivers/net/ldpaa_eth/Makefile |1 -
 include/configs/ls2080a_common.h   |7 +
 include/configs/ls2080a_emu.h  |7 -
 include/configs/ls2080a_simu.h |7 -
 include/linux/usb/xhci-fsl.h   |2 +-
 28 files changed, 100 insertions(+), 152 deletions(-)
 delete mode 100644 configs/ls2085aqds_defconfig
 delete mode 100644 configs/ls2085aqds_nand_defconfig
 delete mode 100644 configs/ls2085ardb_defconfig
 delete mode 100644 configs/ls2085ardb_nand_defconfig

-- 
1.7.9.5

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

Re: [U-Boot] [PATCH V2] fsl: esdhc: consolidate fsl_esdhc_cfg structure

[york sun]

On 03/15/2016 03:14 AM, Peng Fan wrote:
> We can use phys_addr_to for esdhc_base to discard
> the #ifdef.
> 
> Signed-off-by: Peng Fan 
> Cc: York Sun 
> Cc: Yangbo Lu 
> Cc: Eric Nelson 
> Cc: Fabio Estevam 
> Cc: Pantelis Antoniou 
> Cc: Tom Rini 
> ---
> 
> V2:
>  Split this patch from the V1 patch set.
> 
>  include/fsl_esdhc.h | 6 +-
>  1 file changed, 1 insertion(+), 5 deletions(-)
> 
> diff --git a/include/fsl_esdhc.h b/include/fsl_esdhc.h
> index 073048f..fa760a5 100644
> --- a/include/fsl_esdhc.h
> +++ b/include/fsl_esdhc.h
> @@ -168,11 +168,7 @@
>  #define ESDHC_VENDORSPEC_VSELECT 0x0002 /* Use 1.8V */
>  
>  struct fsl_esdhc_cfg {
> -#ifdef CONFIG_FSL_LAYERSCAPE
> - u64 esdhc_base;
> -#else
> - u32 esdhc_base;
> -#endif
> + phys_addr_t esdhc_base;
>   u32 sdhc_clk;
>   u8  max_bus_width;
>   struct mmc_config cfg;
> 

Peng,

I thought this change is trivial and should be OK. But it turns out this change
brings comping warning to many PPC boards

drivers/mmc/fsl_esdhc.c:184:27: warning: cast to pointer from integer of
different size [-Wint-to-pointer-cast]

For assignment like this

struct fsl_esdhc *regs = (struct fsl_esdhc *)cfg->esdhc_base;

The phys_addr is not u32 for many targets.

York

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

Re: [U-Boot] [PATCH V3] fsl: esdhc: support driver model

[Peng Fan]

Hi York,

On Mon, Mar 28, 2016 at 05:55:39PM +, york sun wrote:
>On 03/27/2016 08:02 AM, Peng Fan wrote:
>> Hi York,
>> 
>> Could you test this patch for PPC and layerscape platform? Since I
>> only test this on i.MX6 platform, I do not want to break PPC or else.
>> 
>> Thanks,
>> Peng.
>> 
>> On Fri, Mar 25, 2016 at 02:16:56PM +0800, Peng Fan wrote:
>>> Support Driver Model for fsl esdhc driver.
>>>
>>> 1. Introduce a new structure struct fsl_esdhc_priv
>>> 2. Refactor fsl_esdhc_initialize which is originally used by board code.
>>>   - Introduce fsl_esdhc_init to be common usage for DM and non-DM
>>>   - Introduce fsl_esdhc_cfg_to_priv to build the bridge for non-DM part.
>>>   - The original API for board code is still there, but we use
>>> 'fsl_esdhc_cfg_to_priv' and 'fsl_esdhc_init' to serve it.
>>> 3. All the functions are changed to use 'struct fsl_esdhc_priv', except
>>>   fsl_esdhc_initialize.
>>> 4. Since clk driver is not implemented, use mxc_get_clock to geth
>>>   the clk and fill 'priv->sdhc_clk'.
>>>
>>> Has been tested on i.MX6UL 14X14 EVK board:
>>> "
>>> =>dm tree
>>> 
>>> simple_bus  [ + ]|   `-- aips-bus@0210
>>>  mmc[ + ]|   |-- usdhc@0219
>>>  mmc[ + ]|   |-- usdhc@02194000
>>> 
>>> => mmc list
>>> FSL_SDHC: 0 (SD)
>>> FSL_SDHC: 1 (SD)
>>> "
>>>
>>> Signed-off-by: Peng Fan 
>>> Cc: York Sun 
>>> Cc: Yangbo Lu 
>>> Cc: Hector Palacios 
>>> Cc: Eric Nelson 
>>> Cc: Stefano Babic 
>>> Cc: Fabio Estevam 
>>> Cc: Pantelis Antoniou 
>>> Cc: Simon Glass 
>>> ---
>>>
>>> V3:
>>> Fix build error reported by York for PPC.
>>>
>>> V2:
>>> restructure the V1 patch.
>>> Introduce fsl_esdhc_priv structure.
>>> Introduce code to handle cd-gpios and non-removable.
>
>
>
>>> +
>>> +#ifdef CONFIG_DM_MMC
>>> +#include 
>>> +static int fsl_esdhc_probe(struct udevice *dev)
>>> +{
>>> +   struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
>>> +   struct fsl_esdhc_priv *priv = dev_get_priv(dev);
>>> +   const void *fdt = gd->fdt_blob;
>>> +   int node = dev->of_offset;
>>> +   fdt_addr_t addr;
>>> +   unsigned int val;
>>> +   int ret;
>>> +
>>> +   addr = dev_get_addr(dev);
>>> +   if (addr == FDT_ADDR_T_NONE)
>>> +   return -EINVAL;
>>> +
>>> +   priv->esdhc_regs = (struct fsl_esdhc *)addr;
>>> +   priv->dev = dev;
>>> +
>>> +   val = fdtdec_get_int(fdt, node, "bus-width", -1);
>>> +   if (val == 8)
>>> +   priv->bus_width = 8;
>>> +   else if (val == 4)
>>> +   priv->bus_width = 4;
>>> +   else
>>> +   priv->bus_width = 1;
>>> +
>>> +   if (fdt_get_property(fdt, node, "non-removable", NULL)) {
>>> +   priv->non_removable = 1;
>>> +} else {
>>> +   priv->non_removable = 0;
>>> +   gpio_request_by_name_nodev(fdt, node, "cd-gpios", 0,
>>> +  >cd_gpio, GPIOD_IS_IN);
>>> +   }
>>> +
>>> +   /*
>>> +* TODO:
>>> +* Because lack of clk driver, if SDHC clk is not enabled,
>>> +* need to enable it first before this driver is invoked.
>>> +*
>>> +* we use MXC_ESDHC_CLK to get clk freq.
>>> +* If one would like to make this function work,
>>> +* the aliases should be provided in dts as this:
>>> +*
>>> +*  aliases {
>>> +*  mmc0 = 
>>> +*  mmc1 = 
>>> +*  mmc2 = 
>>> +*  mmc3 = 
>>> +*  };
>>> +* Then if your board only supports mmc2 and mmc3, but we can
>>> +* correctly get the seq as 2 and 3, then let mxc_get_clock
>>> +* work as expected.
>>> +*/
>>> +   priv->sdhc_clk = mxc_get_clock(MXC_ESDHC_CLK + dev->seq);
>>> +   if (priv->sdhc_clk <= 0) {
>>> +   dev_err(dev, "Unable to get clk for %s\n", dev->name);
>>> +   return -EINVAL;
>>> +   }
>>> +
>>> +   ret = fsl_esdhc_init(priv);
>>> +   if (ret) {
>>> +   dev_err(dev, "fsl_esdhc_init failure\n");
>>> +   return ret;
>>> +   }
>>> +
>>> +   upriv->mmc = priv->mmc;
>>> +
>>> +   return 0;
>>> +}
>>> +
>>> +static const struct udevice_id fsl_esdhc_ids[] = {
>>> +   { .compatible = "fsl,imx6ul-usdhc", },
>>> +   { .compatible = "fsl,imx6sx-usdhc", },
>>> +   { .compatible = "fsl,imx6sl-usdhc", },
>>> +   { .compatible = "fsl,imx6q-usdhc", },
>>> +   { .compatible = "fsl,imx7d-usdhc", },
>>> +   { /* sentinel */ }
>>> +};
>>> +
>>> +U_BOOT_DRIVER(fsl_esdhc) = {
>>> +   .name   = "fsl-esdhc-mmc",
>>> +   .id = UCLASS_MMC,
>>> +   .of_match = fsl_esdhc_ids,
>>> +   .probe  = fsl_esdhc_probe,
>>> +   .priv_auto_alloc_size = sizeof(struct fsl_esdhc_priv),
>>> +};
>>> +#endif
>>> -- 
>>> 2.6.2
>>>
>> 
>
>Peng,
>
>You are not breaking PPC yet. The new function you added fsl_esdhc_probe() is
>gated by CONFIG_DM_MMC. This macro is not defined for any PPC platform.

Thanks for the test. If 

Re: [U-Boot] [PATCH RESEND] armv8: LSCH2 early and final mmu needs matching NS attribute

[york sun]

On 03/28/2016 02:16 PM, Ed Swarthout wrote:
> When switching between the early and final mmu tables, the stack will
> get corrupted if the Non-Secure attribute is different.  For ls1043a,
> this issue is currently masked because flush_dcache_all is called
> before the switch when CONFIG_SYS_DPAA_FMAN is defined.
> 
> Signed-off-by: Ed Swarthout 
> ---
> 
> Resend to fix diff format.
> 
> denx/master with CONFIG_SYS_DPAA_FMAN undefined:
> Fixes:
> 
> U-Boot 2016.03-00530-g1fee6de (Mar 28 2016 - 13:46:36 -0500)
> SoC:  LS1043E (0x87920010)
> ...
> Detected UDIMM 18ASF1G72AZ-2G1A1 
> 4 GiB (DDR4, 32-bit, CL=11, ECC on)
>DDR Chip-Select Interleaving Mode: CS0+CS1
> "Synchronous Abort" handler, esr 0x8a00
> ELR: deadbeefdeadbeef
> LR:  deadbeefdeadbeef
> x0 : 00ff440c0400 x1 : 00022518
> x2 : 0040 x3 : 003f
> x4 : 0004 x5 : 0001
> x6 : 0009 x7 : 0020
> x8 : 0015 x9 : 000c
> x10: 0401 x11: 0008ffe06000
> x12: 01ff x13: 4000
> x14: 0020 x15: 0001
> x16:  x17: 0002
> x18: ffdd8d78 x19: deadbeefdeadbeef
> x20: deadbeefdeadbeef x21: deadbeefdeadbeef
> x22: deadbeefdeadbeef x23: deadbeefdeadbeef
> x24: deadbeefdeadbeef x25: deadbeefdeadbeef
> x26: deadbeefdeadbeef x27: 
> x28: fff6ca90 x29: deadbeefdeadbeef
> 
> 
>  arch/arm/include/asm/arch-fsl-layerscape/cpu.h | 12 
>  1 file changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/include/asm/arch-fsl-layerscape/cpu.h 
> b/arch/arm/include/asm/arch-fsl-layerscape/cpu.h
> index 42ca7df..1f5842a 100644
> --- a/arch/arm/include/asm/arch-fsl-layerscape/cpu.h
> +++ b/arch/arm/include/asm/arch-fsl-layerscape/cpu.h
> @@ -159,9 +159,11 @@ static const struct sys_mmu_table early_mmu_table[] = {
>   { CONFIG_SYS_FSL_IFC_BASE, CONFIG_SYS_FSL_IFC_BASE,
> CONFIG_SYS_FSL_IFC_SIZE, MT_DEVICE_NGNRNE, PTE_BLOCK_NON_SHARE },
>   { CONFIG_SYS_FSL_DRAM_BASE1, CONFIG_SYS_FSL_DRAM_BASE1,
> -   CONFIG_SYS_FSL_DRAM_SIZE1, MT_NORMAL, PTE_BLOCK_OUTER_SHARE },
> +   CONFIG_SYS_FSL_DRAM_SIZE1, MT_NORMAL,
> +   PTE_BLOCK_OUTER_SHARE | PTE_BLOCK_NS },
>   { CONFIG_SYS_FSL_DRAM_BASE2, CONFIG_SYS_FSL_DRAM_BASE2,
> -   CONFIG_SYS_FSL_DRAM_SIZE2, MT_NORMAL, PTE_BLOCK_OUTER_SHARE },
> +   CONFIG_SYS_FSL_DRAM_SIZE2, MT_NORMAL,
> +   PTE_BLOCK_OUTER_SHARE | PTE_BLOCK_NS },
>  #endif
>  };
>  
> @@ -247,7 +249,8 @@ static const struct sys_mmu_table final_mmu_table[] = {
> CONFIG_SYS_FSL_QBMAN_SIZE, MT_DEVICE_NGNRNE,
> PTE_BLOCK_NON_SHARE | PTE_BLOCK_PXN | PTE_BLOCK_UXN },
>   { CONFIG_SYS_FSL_DRAM_BASE2, CONFIG_SYS_FSL_DRAM_BASE2,
> -   CONFIG_SYS_FSL_DRAM_SIZE2, MT_NORMAL, PTE_BLOCK_OUTER_SHARE },
> +   CONFIG_SYS_FSL_DRAM_SIZE2, MT_NORMAL,
> +   PTE_BLOCK_OUTER_SHARE | PTE_BLOCK_NS },
>   { CONFIG_SYS_PCIE1_PHYS_ADDR, CONFIG_SYS_PCIE1_PHYS_ADDR,
> CONFIG_SYS_PCIE1_PHYS_SIZE, MT_DEVICE_NGNRNE,
> PTE_BLOCK_NON_SHARE | PTE_BLOCK_PXN | PTE_BLOCK_UXN },
> @@ -258,7 +261,8 @@ static const struct sys_mmu_table final_mmu_table[] = {
> CONFIG_SYS_PCIE3_PHYS_SIZE, MT_DEVICE_NGNRNE,
> PTE_BLOCK_NON_SHARE | PTE_BLOCK_PXN | PTE_BLOCK_UXN },
>   { CONFIG_SYS_FSL_DRAM_BASE3, CONFIG_SYS_FSL_DRAM_BASE3,
> -   CONFIG_SYS_FSL_DRAM_SIZE3, MT_NORMAL, PTE_BLOCK_OUTER_SHARE },
> +   CONFIG_SYS_FSL_DRAM_SIZE3, MT_NORMAL,
> +   PTE_BLOCK_OUTER_SHARE | PTE_BLOCK_NS },
>  #endif
>  };
>  #endif
> 

Alison/Qianyu,

This change looks right to me. Please see if if flushing can be removed.

York


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

[U-Boot] [PATCH] buildman: allow more incremental building

[Stephen Warren]

From: Stephen Warren 

One use-case for buildman is to continually run it interactively after
each small step in a large refactoring operation. This gives more
immediate feedback than making a number of commits and then going back and
testing them. For this to work well, buildman needs to be extremely fast.
At present, a couple issues prevent it being as fast as it could be:

1) Each time buildman runs "make %_defconfig", it runs "make mrproper"
first. This throws away all previous build results, requiring a
from-scratch build. Optionally avoiding this would speed up the build, at
the cost of potentially causing or missing some build issues.

2) A build tree is created per thread rather than per board. When a thread
switches between building different boards, this often causes many files
to be rebuilt due to changing config options. Using a separate build tree
for each board would avoid this. This does put more strain on the system's
disk cache, but it is worth it on my system at least.

This commit adds two command-line options to implement the changes
described above; -I ("--incremental") turns of "make mrproper" and -P
("--per-board-out-dir") creats a build directory per board rather than per
thread.

Tested:

./tools/buildman/buildman.py tegra
./tools/buildman/buildman.py -I -P tegra
./tools/buildman/buildman.py -b tegra_dev tegra
./tools/buildman/buildman.py -b tegra_dev -I -P tegra

... each once after deleting the buildman result/work directory, and once
"incrementally" after a previous identical invocation.

Signed-off-by: Stephen Warren 
---
 tools/buildman/builder.py   | 10 --
 tools/buildman/builderthread.py | 24 
 tools/buildman/cmdline.py   |  4 
 tools/buildman/control.py   |  4 +++-
 4 files changed, 31 insertions(+), 11 deletions(-)

diff --git a/tools/buildman/builder.py b/tools/buildman/builder.py
index 141bf6469136..8ec355172901 100644
--- a/tools/buildman/builder.py
+++ b/tools/buildman/builder.py
@@ -205,7 +205,8 @@ class Builder:
 
 def __init__(self, toolchains, base_dir, git_dir, num_threads, num_jobs,
  gnu_make='make', checkout=True, show_unknown=True, step=1,
- no_subdirs=False, full_path=False, verbose_build=False):
+ no_subdirs=False, full_path=False, verbose_build=False,
+ incremental=False, per_board_out_dir=False):
 """Create a new Builder object
 
 Args:
@@ -224,6 +225,10 @@ class Builder:
 full_path: Return the full path in CROSS_COMPILE and don't set
 PATH
 verbose_build: Run build with V=1 and don't use 'make -s'
+incremental: Always perform incremental builds; don't run make
+mrproper when configuring
+per_board_out_dir: Build in a separate persistent directory per
+board rather than a thread-specific directory
 """
 self.toolchains = toolchains
 self.base_dir = base_dir
@@ -263,7 +268,8 @@ class Builder:
 self.queue = Queue.Queue()
 self.out_queue = Queue.Queue()
 for i in range(self.num_threads):
-t = builderthread.BuilderThread(self, i)
+t = builderthread.BuilderThread(self, i, incremental,
+per_board_out_dir)
 t.setDaemon(True)
 t.start()
 self.threads.append(t)
diff --git a/tools/buildman/builderthread.py b/tools/buildman/builderthread.py
index cf25bb8f1a7e..c512d3b521f7 100644
--- a/tools/buildman/builderthread.py
+++ b/tools/buildman/builderthread.py
@@ -80,11 +80,13 @@ class BuilderThread(threading.Thread):
 thread_num: Our thread number (0-n-1), used to decide on a
 temporary directory
 """
-def __init__(self, builder, thread_num):
+def __init__(self, builder, thread_num, incremental, per_board_out_dir):
 """Set up a new builder thread"""
 threading.Thread.__init__(self)
 self.builder = builder
 self.thread_num = thread_num
+self.incremental = incremental
+self.per_board_out_dir = per_board_out_dir
 
 def Make(self, commit, brd, stage, cwd, *args, **kwargs):
 """Run 'make' on a particular commit and board.
@@ -136,7 +138,11 @@ class BuilderThread(threading.Thread):
 if self.builder.in_tree:
 out_dir = work_dir
 else:
-out_dir = os.path.join(work_dir, 'build')
+if self.per_board_out_dir:
+out_rel_dir = os.path.join('..', brd.target)
+else:
+out_rel_dir = 'build'
+out_dir = os.path.join(work_dir, out_rel_dir)
 
 # Check if the job was already completed last time
 done_file = self.builder.GetDoneFile(commit_upto, brd.target)
@@ -197,12 +203,12 @@ class BuilderThread(threading.Thread):
 #
 # 

[U-Boot] [PATCH RESEND] armv8: LSCH2 early and final mmu needs matching NS attribute

[Ed Swarthout]

When switching between the early and final mmu tables, the stack will
get corrupted if the Non-Secure attribute is different.  For ls1043a,
this issue is currently masked because flush_dcache_all is called
before the switch when CONFIG_SYS_DPAA_FMAN is defined.

Signed-off-by: Ed Swarthout 
---

Resend to fix diff format.

denx/master with CONFIG_SYS_DPAA_FMAN undefined:
Fixes:

U-Boot 2016.03-00530-g1fee6de (Mar 28 2016 - 13:46:36 -0500)
SoC:  LS1043E (0x87920010)
...
Detected UDIMM 18ASF1G72AZ-2G1A1 
4 GiB (DDR4, 32-bit, CL=11, ECC on)
   DDR Chip-Select Interleaving Mode: CS0+CS1
"Synchronous Abort" handler, esr 0x8a00
ELR: deadbeefdeadbeef
LR:  deadbeefdeadbeef
x0 : 00ff440c0400 x1 : 00022518
x2 : 0040 x3 : 003f
x4 : 0004 x5 : 0001
x6 : 0009 x7 : 0020
x8 : 0015 x9 : 000c
x10: 0401 x11: 0008ffe06000
x12: 01ff x13: 4000
x14: 0020 x15: 0001
x16:  x17: 0002
x18: ffdd8d78 x19: deadbeefdeadbeef
x20: deadbeefdeadbeef x21: deadbeefdeadbeef
x22: deadbeefdeadbeef x23: deadbeefdeadbeef
x24: deadbeefdeadbeef x25: deadbeefdeadbeef
x26: deadbeefdeadbeef x27: 
x28: fff6ca90 x29: deadbeefdeadbeef


 arch/arm/include/asm/arch-fsl-layerscape/cpu.h | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/arch/arm/include/asm/arch-fsl-layerscape/cpu.h 
b/arch/arm/include/asm/arch-fsl-layerscape/cpu.h
index 42ca7df..1f5842a 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/cpu.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/cpu.h
@@ -159,9 +159,11 @@ static const struct sys_mmu_table early_mmu_table[] = {
{ CONFIG_SYS_FSL_IFC_BASE, CONFIG_SYS_FSL_IFC_BASE,
  CONFIG_SYS_FSL_IFC_SIZE, MT_DEVICE_NGNRNE, PTE_BLOCK_NON_SHARE },
{ CONFIG_SYS_FSL_DRAM_BASE1, CONFIG_SYS_FSL_DRAM_BASE1,
- CONFIG_SYS_FSL_DRAM_SIZE1, MT_NORMAL, PTE_BLOCK_OUTER_SHARE },
+ CONFIG_SYS_FSL_DRAM_SIZE1, MT_NORMAL,
+ PTE_BLOCK_OUTER_SHARE | PTE_BLOCK_NS },
{ CONFIG_SYS_FSL_DRAM_BASE2, CONFIG_SYS_FSL_DRAM_BASE2,
- CONFIG_SYS_FSL_DRAM_SIZE2, MT_NORMAL, PTE_BLOCK_OUTER_SHARE },
+ CONFIG_SYS_FSL_DRAM_SIZE2, MT_NORMAL,
+ PTE_BLOCK_OUTER_SHARE | PTE_BLOCK_NS },
 #endif
 };
 
@@ -247,7 +249,8 @@ static const struct sys_mmu_table final_mmu_table[] = {
  CONFIG_SYS_FSL_QBMAN_SIZE, MT_DEVICE_NGNRNE,
  PTE_BLOCK_NON_SHARE | PTE_BLOCK_PXN | PTE_BLOCK_UXN },
{ CONFIG_SYS_FSL_DRAM_BASE2, CONFIG_SYS_FSL_DRAM_BASE2,
- CONFIG_SYS_FSL_DRAM_SIZE2, MT_NORMAL, PTE_BLOCK_OUTER_SHARE },
+ CONFIG_SYS_FSL_DRAM_SIZE2, MT_NORMAL,
+ PTE_BLOCK_OUTER_SHARE | PTE_BLOCK_NS },
{ CONFIG_SYS_PCIE1_PHYS_ADDR, CONFIG_SYS_PCIE1_PHYS_ADDR,
  CONFIG_SYS_PCIE1_PHYS_SIZE, MT_DEVICE_NGNRNE,
  PTE_BLOCK_NON_SHARE | PTE_BLOCK_PXN | PTE_BLOCK_UXN },
@@ -258,7 +261,8 @@ static const struct sys_mmu_table final_mmu_table[] = {
  CONFIG_SYS_PCIE3_PHYS_SIZE, MT_DEVICE_NGNRNE,
  PTE_BLOCK_NON_SHARE | PTE_BLOCK_PXN | PTE_BLOCK_UXN },
{ CONFIG_SYS_FSL_DRAM_BASE3, CONFIG_SYS_FSL_DRAM_BASE3,
- CONFIG_SYS_FSL_DRAM_SIZE3, MT_NORMAL, PTE_BLOCK_OUTER_SHARE },
+ CONFIG_SYS_FSL_DRAM_SIZE3, MT_NORMAL,
+ PTE_BLOCK_OUTER_SHARE | PTE_BLOCK_NS },
 #endif
 };
 #endif
-- 
2.5.0

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

[U-Boot] [PATCH] armv8/LSCH2: early and final mmu needs matching NS attribute

[Ed Swarthout]

When switching between the early and final mmu tables, the stack will
get corrupted if the Non-Secure attribute is different.  For ls1043a,
this issue is currently masked because flush_dcache_all is called
before the switch when CONFIG_SYS_DPAA_FMAN is defined.

Signed-off-by: Ed Swarthout 
---

denx/master with CONFIG_SYS_DPAA_FMAN undefined:
Fixes:

U-Boot 2016.03-00530-g1fee6de (Mar 28 2016 - 13:46:36 -0500)
SoC:  LS1043E (0x87920010)
...
Detected UDIMM 18ASF1G72AZ-2G1A1 
4 GiB (DDR4, 32-bit, CL=11, ECC on)
   DDR Chip-Select Interleaving Mode: CS0+CS1
"Synchronous Abort" handler, esr 0x8a00
ELR: deadbeefdeadbeef
LR:  deadbeefdeadbeef
x0 : 00ff440c0400 x1 : 00022518
x2 : 0040 x3 : 003f
x4 : 0004 x5 : 0001
x6 : 0009 x7 : 0020
x8 : 0015 x9 : 000c
x10: 0401 x11: 0008ffe06000
x12: 01ff x13: 4000
x14: 0020 x15: 0001
x16:  x17: 0002
x18: ffdd8d78 x19: deadbeefdeadbeef
x20: deadbeefdeadbeef x21: deadbeefdeadbeef
x22: deadbeefdeadbeef x23: deadbeefdeadbeef
x24: deadbeefdeadbeef x25: deadbeefdeadbeef
x26: deadbeefdeadbeef x27: 
x28: fff6ca90 x29: deadbeefdeadbeef

 arch/arm/include/asm/arch-fsl-layerscape/cpu.h | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/arch/arm/include/asm/arch-fsl-layerscape/cpu.h 
b/arch/arm/include/asm/arch-fsl-layerscape/cpu.h
index 42ca7df..1f5842a 100644
*** a/arch/arm/include/asm/arch-fsl-layerscape/cpu.h
--- b/arch/arm/include/asm/arch-fsl-layerscape/cpu.h
***
*** 159,167 
{ CONFIG_SYS_FSL_IFC_BASE, CONFIG_SYS_FSL_IFC_BASE,
  CONFIG_SYS_FSL_IFC_SIZE, MT_DEVICE_NGNRNE, PTE_BLOCK_NON_SHARE },
{ CONFIG_SYS_FSL_DRAM_BASE1, CONFIG_SYS_FSL_DRAM_BASE1,
! CONFIG_SYS_FSL_DRAM_SIZE1, MT_NORMAL, PTE_BLOCK_OUTER_SHARE },
{ CONFIG_SYS_FSL_DRAM_BASE2, CONFIG_SYS_FSL_DRAM_BASE2,
! CONFIG_SYS_FSL_DRAM_SIZE2, MT_NORMAL, PTE_BLOCK_OUTER_SHARE },
  #endif
  };
  
--- 159,169 
{ CONFIG_SYS_FSL_IFC_BASE, CONFIG_SYS_FSL_IFC_BASE,
  CONFIG_SYS_FSL_IFC_SIZE, MT_DEVICE_NGNRNE, PTE_BLOCK_NON_SHARE },
{ CONFIG_SYS_FSL_DRAM_BASE1, CONFIG_SYS_FSL_DRAM_BASE1,
! CONFIG_SYS_FSL_DRAM_SIZE1, MT_NORMAL,
! PTE_BLOCK_OUTER_SHARE | PTE_BLOCK_NS },
{ CONFIG_SYS_FSL_DRAM_BASE2, CONFIG_SYS_FSL_DRAM_BASE2,
! CONFIG_SYS_FSL_DRAM_SIZE2, MT_NORMAL,
! PTE_BLOCK_OUTER_SHARE | PTE_BLOCK_NS },
  #endif
  };
  
***
*** 247,253 
  CONFIG_SYS_FSL_QBMAN_SIZE, MT_DEVICE_NGNRNE,
  PTE_BLOCK_NON_SHARE | PTE_BLOCK_PXN | PTE_BLOCK_UXN },
{ CONFIG_SYS_FSL_DRAM_BASE2, CONFIG_SYS_FSL_DRAM_BASE2,
! CONFIG_SYS_FSL_DRAM_SIZE2, MT_NORMAL, PTE_BLOCK_OUTER_SHARE },
{ CONFIG_SYS_PCIE1_PHYS_ADDR, CONFIG_SYS_PCIE1_PHYS_ADDR,
  CONFIG_SYS_PCIE1_PHYS_SIZE, MT_DEVICE_NGNRNE,
  PTE_BLOCK_NON_SHARE | PTE_BLOCK_PXN | PTE_BLOCK_UXN },
--- 249,256 
  CONFIG_SYS_FSL_QBMAN_SIZE, MT_DEVICE_NGNRNE,
  PTE_BLOCK_NON_SHARE | PTE_BLOCK_PXN | PTE_BLOCK_UXN },
{ CONFIG_SYS_FSL_DRAM_BASE2, CONFIG_SYS_FSL_DRAM_BASE2,
! CONFIG_SYS_FSL_DRAM_SIZE2, MT_NORMAL,
! PTE_BLOCK_OUTER_SHARE | PTE_BLOCK_NS },
{ CONFIG_SYS_PCIE1_PHYS_ADDR, CONFIG_SYS_PCIE1_PHYS_ADDR,
  CONFIG_SYS_PCIE1_PHYS_SIZE, MT_DEVICE_NGNRNE,
  PTE_BLOCK_NON_SHARE | PTE_BLOCK_PXN | PTE_BLOCK_UXN },
***
*** 258,264 
  CONFIG_SYS_PCIE3_PHYS_SIZE, MT_DEVICE_NGNRNE,
  PTE_BLOCK_NON_SHARE | PTE_BLOCK_PXN | PTE_BLOCK_UXN },
{ CONFIG_SYS_FSL_DRAM_BASE3, CONFIG_SYS_FSL_DRAM_BASE3,
! CONFIG_SYS_FSL_DRAM_SIZE3, MT_NORMAL, PTE_BLOCK_OUTER_SHARE },
  #endif
  };
  #endif
- - 
--- 261,268 
  CONFIG_SYS_PCIE3_PHYS_SIZE, MT_DEVICE_NGNRNE,
  PTE_BLOCK_NON_SHARE | PTE_BLOCK_PXN | PTE_BLOCK_UXN },
{ CONFIG_SYS_FSL_DRAM_BASE3, CONFIG_SYS_FSL_DRAM_BASE3,
! CONFIG_SYS_FSL_DRAM_SIZE3, MT_NORMAL,
! PTE_BLOCK_OUTER_SHARE | PTE_BLOCK_NS },
  #endif
  };
  #endif
2.5.0

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

[U-Boot] [RFC] SPL -> U-Boot Chain of Trust

[Andreas Dannenberg]

On Mon, Mar 28, 2016 at 03:32:40PM -0400, Tom Rini wrote:
> I'm interested in getting secure device support going, but it seems
> like we should need more than that, ie something to keep the chain of
> trust going.

Tom et al.,
I just saw your reply to Vitaly's email and I'm actually just looking
into something along the lines you brought up but I didn't want to
hijack that discussion so here's a new thread.

As for the chain of trust for ARMv7, my understanding is that when
using a combination of SPL and U-Boot there will always be a vendor-
specific initial boot (ROM) code that authenticates SPL, and then there
will need to be some code inserted into SPL that authenticates U-Boot
after it's loaded (for example by using some secure ROM API call and
such).

So I was looking into if there is already some generic framework for
this in U-Boot but didn't see anything obvious. One "easy" way would be
to add a simple call to an authentication routine to board_init_r
(u-boot/common/spl/spl.c) but let's say we add such a call for TI or
other vendor's stuff I suppose this would not scale very well.

But what about adding one generic call to a default authentication
function declared as __weak for spl_image that doesn't do anything, but
can be overwritten in vendor-specific files to provide means of
authenticating spl_image. Would this be a good approach?



Beyond that I was reviewing some of the awesome work from the Chromium
team and I think on ARMv7 after we get MLO to authenticate U-Boot
everything beyond that is already looking very solid and thorough (with
FIT, DTB/Kernel and initramfs authentication).


Thanks and Regards,

--
Andreas Dannenberg
Texas Instruments Inc

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

Re: [U-Boot] [PATCH] configs: ti_armv7_keystone2: make SYS_TEXT_BASE configurable at build time

[Tom Rini]

On Mon, Mar 28, 2016 at 03:15:59PM -0400, Vitaly Andrianov wrote:

> U-boot for general purpose KS2 devices is loaded to the beginning of the
> internal memory (0x0c00). Secure devices uses this memory and
> CONFIG_SYS_TEXT_BASE has to be different for those devices.
> 
> This commit make this configurable at build time by giving
> CONFIG_SYS_TEXT_BASE as a command line definition to make command.

I'm interested in getting secure device support going, but it seems like
we should need more than that, ie something to keep the chain of trust
going.  I also don't like that we're just overriding this in the command
line, especially as I expect we'll need other changes too once this gets
moving forward.  Thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH] board: ge: bx50v3: Update display setup

[Akshay Bhat]

Hi Stefano,

On Tue, Mar 15, 2016 at 2:10 PM, Akshay Bhat  
wrote:

Implements the below changes:
- Disable LVDS1 on B450v3/B650v3 boards since the final boards no longer
have connectors for the same. Only LVDS0 hardware connectors are present.
- Implement imx6 EB821 or ERR009219 errata for LVDS clock switch.
This patch was ported from Freescale 3.10.17_1.0.0_ga kernel to u-boot.
- Split the display setup into 2 different functions. One for B850v3 that
does a setup of LVDS and HDMI with clock source for LVDS/IPU_DI set to
video PLL. The other for B450v3/B650v3 that does a setup of LVDS only with
clock source for LVDS/IPU_DI set to USB PLL. This helps us generate
accurate pixel clock required for display connected to LVDS.

Signed-off-by: Akshay Bhat 
Cc: Stefano Babic 
---


Can this be applied if there are no review comments.

Thanks,
Akshay

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

[U-Boot] [PATCH] configs: ti_armv7_keystone2: make SYS_TEXT_BASE configurable at build time

[Vitaly Andrianov]

U-boot for general purpose KS2 devices is loaded to the beginning of the
internal memory (0x0c00). Secure devices uses this memory and
CONFIG_SYS_TEXT_BASE has to be different for those devices.

This commit make this configurable at build time by giving
CONFIG_SYS_TEXT_BASE as a command line definition to make command.

Signed-off-by: Vitaly Andrianov 
---
 include/configs/ti_armv7_keystone2.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/configs/ti_armv7_keystone2.h 
b/include/configs/ti_armv7_keystone2.h
index a7206f4..76b901bf 100644
--- a/include/configs/ti_armv7_keystone2.h
+++ b/include/configs/ti_armv7_keystone2.h
@@ -20,7 +20,9 @@
 /* SoC Configuration */
 #define CONFIG_ARCH_CPU_INIT
 #define CONFIG_SYS_ARCH_TIMER
+#ifndef CONFIG_SYS_TEXT_BASE
 #define CONFIG_SYS_TEXT_BASE   0x0c00
+#endif
 #define CONFIG_SPL_TARGET  "u-boot-spi.gph"
 #define CONFIG_SYS_DCACHE_OFF
 
-- 
1.9.1

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

[U-Boot] [PATCH] arm: spl: Align default board_init_f comment with code

[Andreas Dannenberg]

The default board_init_f() implementation performs a call to
board_init_r() as the last step of the sequence. Fix the comment
for this function to reflect the actual execution flow.

Signed-off-by: Andreas Dannenberg 
---
 arch/arm/lib/spl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/lib/spl.c b/arch/arm/lib/spl.c
index d737a5c..e428868 100644
--- a/arch/arm/lib/spl.c
+++ b/arch/arm/lib/spl.c
@@ -27,7 +27,7 @@ gd_t gdata __attribute__ ((section(".data")));
 /*
  * In the context of SPL, board_init_f must ensure that any clocks/etc for
  * DDR are enabled, ensure that the stack pointer is valid, clear the BSS
- * and call board_init_f.  We provide this version by default but mark it
+ * and call board_init_r.  We provide this version by default but mark it
  * as __weak to allow for platforms to do this in their own way if needed.
  */
 void __weak board_init_f(ulong dummy)
-- 
2.7.2

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

[U-Boot] should include/post.h have MPC8360-related macro refer to "CPM_POST_WORD_ADDR"?

[Robert P. J. Day]

  another POST-related bit of pedantry, but i'm curious about the best
way to deal with the question in the subject.

  i can see in include/post.h the logic involved in assigning a value
to the macro _POST_WORD_ADDR. first, deal with the trivial case:

#ifndef CONFIG_POST_EXTERNAL_WORD_FUNCS
#ifdef CONFIG_SYS_POST_WORD_ADDR
#define _POST_WORD_ADDR CONFIG_SYS_POST_WORD_ADDR
#else
   ...

at which point the subsequent preprocessor directives try to set
_POST_WORD_ADDR based on the target processor, as in:

#ifdef CONFIG_MPC5xxx
#define _POST_WORD_ADDR (MPC5XXX_SRAM + MPC5XXX_SRAM_POST_SIZE)

#elif defined(CONFIG_MPC512X)
#define _POST_WORD_ADDR \
(CONFIG_SYS_SRAM_BASE + CONFIG_SYS_GBL_DATA_OFFSET - 0x4)

... and so on and so on ...

but here's the oddity.

  as best as i can tell, all of those conditional assignments assign a
value to _POST_WORD_ADDR based on macros that have values based on
that target arch, until you get here:

#elif defined(CONFIG_MPC8260)
#include 
#define _POST_WORD_ADDR (CONFIG_SYS_IMMR + CPM_POST_WORD_ADDR)

#elif defined(CONFIG_MPC8360)
#include 
#define _POST_WORD_ADDR (CONFIG_SYS_IMMR + CPM_POST_WORD_ADDR)

  now the check for MPC8260 looks fine, since CONFIG_SYS_IMMR will
have a value, and the macro CPM_POST_WORD_ADDR is defined in
, so no problem.

  but in the next check for MPC8360, while that check includes the
header file , that header file does *not* define a
value for CPM_POST_WORD_ADDR. in fact, why is a check for MPC8360
making any reference to a CPM-related macro at all? that macro does
not seem to be assigned any value in the context of MPC8360. how can
that possibly expand correctly?

  i puzzled over this for a bit wondering how it could *ever* work
until i stumbled over the following example in
include/configs/km8360.h:

/* enable POST tests */
#define CONFIG_POST (CONFIG_SYS_POST_MEMORY|CONFIG_SYS_POST_MEM_REGIONS)
#define CONFIG_POST_EXTERNAL_WORD_FUNCS /* use own functions, not generic */
#define CPM_POST_WORD_ADDR  CONFIG_SYS_MEMTEST_END

  well, ok, *now* it makes sense but that seems disgustingly hacky --
reusing a variable from 8260 and earlier that has no relevance to
MPC8360. there's certainly nothing in the README or elsewhere to warn
the developer that, for MPC8360, one might trip over that.

  is there no cleaner way to do this? thoughts?

rday

p.s. i notice one other solution is what blackfin does in the header
file arch/blackfin/include/asm/config.h:

#ifndef CONFIG_SYS_POST_WORD_ADDR
# define CONFIG_SYS_POST_WORD_ADDR (L1_DATA_B_SRAM + L1_DATA_B_SRAM_SIZE - 4)
#endif

which seems perfectly reasonable.

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday



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

Re: [U-Boot] [PATCH V3] fsl: esdhc: support driver model

[york sun]

On 03/27/2016 08:02 AM, Peng Fan wrote:
> Hi York,
> 
> Could you test this patch for PPC and layerscape platform? Since I
> only test this on i.MX6 platform, I do not want to break PPC or else.
> 
> Thanks,
> Peng.
> 
> On Fri, Mar 25, 2016 at 02:16:56PM +0800, Peng Fan wrote:
>> Support Driver Model for fsl esdhc driver.
>>
>> 1. Introduce a new structure struct fsl_esdhc_priv
>> 2. Refactor fsl_esdhc_initialize which is originally used by board code.
>>   - Introduce fsl_esdhc_init to be common usage for DM and non-DM
>>   - Introduce fsl_esdhc_cfg_to_priv to build the bridge for non-DM part.
>>   - The original API for board code is still there, but we use
>> 'fsl_esdhc_cfg_to_priv' and 'fsl_esdhc_init' to serve it.
>> 3. All the functions are changed to use 'struct fsl_esdhc_priv', except
>>   fsl_esdhc_initialize.
>> 4. Since clk driver is not implemented, use mxc_get_clock to geth
>>   the clk and fill 'priv->sdhc_clk'.
>>
>> Has been tested on i.MX6UL 14X14 EVK board:
>> "
>> =>dm tree
>> 
>> simple_bus  [ + ]|   `-- aips-bus@0210
>>  mmc[ + ]|   |-- usdhc@0219
>>  mmc[ + ]|   |-- usdhc@02194000
>> 
>> => mmc list
>> FSL_SDHC: 0 (SD)
>> FSL_SDHC: 1 (SD)
>> "
>>
>> Signed-off-by: Peng Fan 
>> Cc: York Sun 
>> Cc: Yangbo Lu 
>> Cc: Hector Palacios 
>> Cc: Eric Nelson 
>> Cc: Stefano Babic 
>> Cc: Fabio Estevam 
>> Cc: Pantelis Antoniou 
>> Cc: Simon Glass 
>> ---
>>
>> V3:
>> Fix build error reported by York for PPC.
>>
>> V2:
>> restructure the V1 patch.
>> Introduce fsl_esdhc_priv structure.
>> Introduce code to handle cd-gpios and non-removable.



>> +
>> +#ifdef CONFIG_DM_MMC
>> +#include 
>> +static int fsl_esdhc_probe(struct udevice *dev)
>> +{
>> +struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
>> +struct fsl_esdhc_priv *priv = dev_get_priv(dev);
>> +const void *fdt = gd->fdt_blob;
>> +int node = dev->of_offset;
>> +fdt_addr_t addr;
>> +unsigned int val;
>> +int ret;
>> +
>> +addr = dev_get_addr(dev);
>> +if (addr == FDT_ADDR_T_NONE)
>> +return -EINVAL;
>> +
>> +priv->esdhc_regs = (struct fsl_esdhc *)addr;
>> +priv->dev = dev;
>> +
>> +val = fdtdec_get_int(fdt, node, "bus-width", -1);
>> +if (val == 8)
>> +priv->bus_width = 8;
>> +else if (val == 4)
>> +priv->bus_width = 4;
>> +else
>> +priv->bus_width = 1;
>> +
>> +if (fdt_get_property(fdt, node, "non-removable", NULL)) {
>> +priv->non_removable = 1;
>> + } else {
>> +priv->non_removable = 0;
>> +gpio_request_by_name_nodev(fdt, node, "cd-gpios", 0,
>> +   >cd_gpio, GPIOD_IS_IN);
>> +}
>> +
>> +/*
>> + * TODO:
>> + * Because lack of clk driver, if SDHC clk is not enabled,
>> + * need to enable it first before this driver is invoked.
>> + *
>> + * we use MXC_ESDHC_CLK to get clk freq.
>> + * If one would like to make this function work,
>> + * the aliases should be provided in dts as this:
>> + *
>> + *  aliases {
>> + *  mmc0 = 
>> + *  mmc1 = 
>> + *  mmc2 = 
>> + *  mmc3 = 
>> + *  };
>> + * Then if your board only supports mmc2 and mmc3, but we can
>> + * correctly get the seq as 2 and 3, then let mxc_get_clock
>> + * work as expected.
>> + */
>> +priv->sdhc_clk = mxc_get_clock(MXC_ESDHC_CLK + dev->seq);
>> +if (priv->sdhc_clk <= 0) {
>> +dev_err(dev, "Unable to get clk for %s\n", dev->name);
>> +return -EINVAL;
>> +}
>> +
>> +ret = fsl_esdhc_init(priv);
>> +if (ret) {
>> +dev_err(dev, "fsl_esdhc_init failure\n");
>> +return ret;
>> +}
>> +
>> +upriv->mmc = priv->mmc;
>> +
>> +return 0;
>> +}
>> +
>> +static const struct udevice_id fsl_esdhc_ids[] = {
>> +{ .compatible = "fsl,imx6ul-usdhc", },
>> +{ .compatible = "fsl,imx6sx-usdhc", },
>> +{ .compatible = "fsl,imx6sl-usdhc", },
>> +{ .compatible = "fsl,imx6q-usdhc", },
>> +{ .compatible = "fsl,imx7d-usdhc", },
>> +{ /* sentinel */ }
>> +};
>> +
>> +U_BOOT_DRIVER(fsl_esdhc) = {
>> +.name   = "fsl-esdhc-mmc",
>> +.id = UCLASS_MMC,
>> +.of_match = fsl_esdhc_ids,
>> +.probe  = fsl_esdhc_probe,
>> +.priv_auto_alloc_size = sizeof(struct fsl_esdhc_priv),
>> +};
>> +#endif
>> -- 
>> 2.6.2
>>
> 

Peng,

You are not breaking PPC yet. The new function you added fsl_esdhc_probe() is
gated by CONFIG_DM_MMC. This macro is not defined for any PPC platform.

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

Re: [U-Boot] [PATCH 1/9] imx: imx6qdl: add device tree files for i.MX6DQ

[Eric Nelson]

On 03/28/2016 10:26 AM, Eric Nelson wrote:
> Copy device tree headers and include (.dtsi) files for
> i.MX6 Dual and Quad variants.
> 
> These are copied as-is from Linux stable (4.4.1).
> 

This is the only patch in the set.

Sorry for not catching the "Patch 1/9" in the header.

I pulled this out of the tree I was working on for the block cache.


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

[U-Boot] [PATCH V3 1/3] drivers: block: add block device cache

[Eric Nelson]

Add a block device cache to speed up repeated reads of block devices by
various filesystems.

This small amount of cache can dramatically speed up filesystem
operations by skipping repeated reads of common areas of a block
device (typically directory structures).

This has shown to have some benefit on FAT filesystem operations of
loading a kernel and RAM disk, but more dramatic benefits on ext4
filesystems when the kernel and/or RAM disk are spread across
multiple extent header structures as described in commit fc0fc50.

The cache is implemented through a minimal list (block_cache) maintained
in most-recently-used order and count of the current number of entries
(cache_count). It uses a maximum block count setting to prevent copies
of large block reads and an upper bound on the number of cached areas.

The maximum number of entries in the cache defaults to 32 and the maximum
number of blocks per cache entry has a default of 2, which has shown to
produce the best results on testing of ext4 and FAT filesystems.

The 'blkcache' command (enabled through CONFIG_CMD_BLOCK_CACHE) allows
changing these values and can be used to tune for a particular filesystem
layout.

Signed-off-by: Eric Nelson 
---
Changes in V3:
   - replace remnant of "blkcache max" from sub-command name change

Changes in V2:
   - moved blkcache command into cmd/blkcache (Misc commands)
   - removed invalidate sub-command - done in max command
   - removed clear sub-command - done in show command
   - removed dump command (was only for debug)
   - removed run-time trace control in favor of debug() messages
   - use struct block_cache_stats instead of separate static vars
 to streamline block_cache_
   - rename max sub-command to configure to match API
   - change show sub-command to auto-clear statistics

 cmd/Kconfig|  11 +++
 cmd/Makefile   |   1 +
 cmd/blkcache.c |  90 +++
 disk/part.c|   2 +
 drivers/block/Kconfig  |   9 +++
 drivers/block/Makefile |   1 +
 drivers/block/blk-uclass.c |  13 +++-
 drivers/block/blkcache.c   | 173 +
 include/blk.h  | 105 ++-
 9 files changed, 403 insertions(+), 2 deletions(-)
 create mode 100644 cmd/blkcache.c
 create mode 100644 drivers/block/blkcache.c

diff --git a/cmd/Kconfig b/cmd/Kconfig
index 7cdff04..11106af 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -485,6 +485,17 @@ config SYS_AMBAPP_PRINT_ON_STARTUP
help
  Show AMBA Plug-n-Play information on startup.
 
+config CMD_BLOCK_CACHE
+   bool "blkcache - control and stats for block cache"
+   depends on BLOCK_CACHE
+   default y if BLOCK_CACHE
+   help
+ Enable the blkcache command, which can be used to control the
+ operation of the cache functions.
+ This is most useful when fine-tuning the operation of the cache
+ during development, but also allows the cache to be disabled when
+ it might hurt performance (e.g. when using the ums command).
+
 config CMD_TIME
bool "time"
help
diff --git a/cmd/Makefile b/cmd/Makefile
index 7604621..ba04197 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_SOURCE) += source.o
 obj-$(CONFIG_CMD_SOURCE) += source.o
 obj-$(CONFIG_CMD_BDI) += bdinfo.o
 obj-$(CONFIG_CMD_BEDBUG) += bedbug.o
+obj-$(CONFIG_CMD_BLOCK_CACHE) += blkcache.o
 obj-$(CONFIG_CMD_BMP) += bmp.o
 obj-$(CONFIG_CMD_BOOTEFI) += bootefi.o
 obj-$(CONFIG_CMD_BOOTMENU) += bootmenu.o
diff --git a/cmd/blkcache.c b/cmd/blkcache.c
new file mode 100644
index 000..725163a
--- /dev/null
+++ b/cmd/blkcache.c
@@ -0,0 +1,90 @@
+/*
+ * Copyright (C) Nelson Integration, LLC 2016
+ * Author: Eric Nelson
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+
+static int blkc_show(cmd_tbl_t *cmdtp, int flag,
+int argc, char * const argv[])
+{
+   struct block_cache_stats stats;
+   blkcache_stats();
+
+   printf("hits: %u\n"
+  "misses: %u\n"
+  "entries: %u\n"
+  "max blocks/entry: %u\n"
+  "max cache entries: %u\n",
+  stats.hits, stats.misses, stats.entries,
+  stats.max_blocks_per_entry, stats.max_entries);
+   return 0;
+}
+
+static int blkc_configure(cmd_tbl_t *cmdtp, int flag,
+ int argc, char * const argv[])
+{
+   unsigned blocks_per_entry, max_entries;
+   if (argc != 3)
+   return CMD_RET_USAGE;
+
+   blocks_per_entry = simple_strtoul(argv[1], 0, 0);
+   max_entries = simple_strtoul(argv[2], 0, 0);
+   blkcache_configure(blocks_per_entry, max_entries);
+   printf("changed to max of %u entries of %u blocks each\n",
+  max_entries, blocks_per_entry);
+   return 0;
+}
+
+static cmd_tbl_t cmd_blkc_sub[] = {

[U-Boot] [PATCH V2 1/3] drivers: block: add block device cache

[Eric Nelson]

Add a block device cache to speed up repeated reads of block devices by
various filesystems.

This small amount of cache can dramatically speed up filesystem
operations by skipping repeated reads of common areas of a block
device (typically directory structures).

This has shown to have some benefit on FAT filesystem operations of
loading a kernel and RAM disk, but more dramatic benefits on ext4
filesystems when the kernel and/or RAM disk are spread across
multiple extent header structures as described in commit fc0fc50.

The cache is implemented through a minimal list (block_cache) maintained
in most-recently-used order and count of the current number of entries
(cache_count). It uses a maximum block count setting to prevent copies
of large block reads and an upper bound on the number of cached areas.

The maximum number of entries in the cache defaults to 32 and the maximum
number of blocks per cache entry has a default of 2, which has shown to
produce the best results on testing of ext4 and FAT filesystems.

The 'blkcache' command (enabled through CONFIG_CMD_BLOCK_CACHE) allows
changing these values and can be used to tune for a particular filesystem
layout.

Signed-off-by: Eric Nelson 
---
Changes in V2:
   - moved blkcache command into cmd/blkcache (Misc commands)
   - removed invalidate sub-command - done in max command
   - removed clear sub-command - done in show command
   - removed dump command (was only for debug)
   - removed run-time trace control in favor of debug() messages
   - use struct block_cache_stats instead of separate static vars
 to streamline block_cache_
   - rename max sub-command to configure to match API
   - change show sub-command to auto-clear statistics

 cmd/Kconfig|  11 +++
 cmd/Makefile   |   1 +
 cmd/blkcache.c |  90 +++
 disk/part.c|   2 +
 drivers/block/Kconfig  |   9 +++
 drivers/block/Makefile |   1 +
 drivers/block/blk-uclass.c |  13 +++-
 drivers/block/blkcache.c   | 173 +
 include/blk.h  | 105 ++-
 9 files changed, 403 insertions(+), 2 deletions(-)
 create mode 100644 cmd/blkcache.c
 create mode 100644 drivers/block/blkcache.c

diff --git a/cmd/Kconfig b/cmd/Kconfig
index 7cdff04..11106af 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -485,6 +485,17 @@ config SYS_AMBAPP_PRINT_ON_STARTUP
help
  Show AMBA Plug-n-Play information on startup.
 
+config CMD_BLOCK_CACHE
+   bool "blkcache - control and stats for block cache"
+   depends on BLOCK_CACHE
+   default y if BLOCK_CACHE
+   help
+ Enable the blkcache command, which can be used to control the
+ operation of the cache functions.
+ This is most useful when fine-tuning the operation of the cache
+ during development, but also allows the cache to be disabled when
+ it might hurt performance (e.g. when using the ums command).
+
 config CMD_TIME
bool "time"
help
diff --git a/cmd/Makefile b/cmd/Makefile
index 7604621..ba04197 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_SOURCE) += source.o
 obj-$(CONFIG_CMD_SOURCE) += source.o
 obj-$(CONFIG_CMD_BDI) += bdinfo.o
 obj-$(CONFIG_CMD_BEDBUG) += bedbug.o
+obj-$(CONFIG_CMD_BLOCK_CACHE) += blkcache.o
 obj-$(CONFIG_CMD_BMP) += bmp.o
 obj-$(CONFIG_CMD_BOOTEFI) += bootefi.o
 obj-$(CONFIG_CMD_BOOTMENU) += bootmenu.o
diff --git a/cmd/blkcache.c b/cmd/blkcache.c
new file mode 100644
index 000..5c2a859
--- /dev/null
+++ b/cmd/blkcache.c
@@ -0,0 +1,90 @@
+/*
+ * Copyright (C) Nelson Integration, LLC 2016
+ * Author: Eric Nelson
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+
+static int blkc_show(cmd_tbl_t *cmdtp, int flag,
+int argc, char * const argv[])
+{
+   struct block_cache_stats stats;
+   blkcache_stats();
+
+   printf("hits: %u\n"
+  "misses: %u\n"
+  "entries: %u\n"
+  "max blocks/entry: %u\n"
+  "max cache entries: %u\n",
+  stats.hits, stats.misses, stats.entries,
+  stats.max_blocks_per_entry, stats.max_entries);
+   return 0;
+}
+
+static int blkc_configure(cmd_tbl_t *cmdtp, int flag,
+ int argc, char * const argv[])
+{
+   unsigned blocks_per_entry, max_entries;
+   if (argc != 3)
+   return CMD_RET_USAGE;
+
+   blocks_per_entry = simple_strtoul(argv[1], 0, 0);
+   max_entries = simple_strtoul(argv[2], 0, 0);
+   blkcache_configure(blocks_per_entry, max_entries);
+   printf("changed to max of %u entries of %u blocks each\n",
+  max_entries, blocks_per_entry);
+   return 0;
+}
+
+static cmd_tbl_t cmd_blkc_sub[] = {
+   U_BOOT_CMD_MKENT(show, 0, 0, blkc_show, "", ""),
+   

Re: [U-Boot] [PATCH v2 1/2] doc: driver-model: Update dm tests run using test.py

[Jagan Teki]

On 17 March 2016 at 12:23, Jagan Teki  wrote:
> Since all the tests are implemented in pytest infrastructure,
> So update the dm tests with the same instead of ./test/dm/test-dm.sh
>
> Cc: Tom Rini 
> Cc: Simon Glass 
> Acked-by: Stephen Warren 
> Signed-off-by: Jagan Teki 


Ping!

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

Re: [U-Boot] [PATCH v2 2/2] board: README.sandbox: Update dm test command

[Jagan Teki]

On 17 March 2016 at 12:23, Jagan Teki  wrote:
> Update dm test command with pytest instead of ./test/dm/test-dm.sh
>
> Cc: Tom Rini 
> Cc: Simon Glass 
> Acked-by: Stephen Warren 
> Signed-off-by: Jagan Teki 

Ping!

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

Re: [U-Boot] [PATCH] drivers: net: ldpaa: Memset pools_params as "0" before use

[Joe Hershberger]

On Mon, Mar 28, 2016 at 3:41 AM, Prabhakar Kushwaha
 wrote:
> Memset pools_params as "0" to avoid garbage value in dpni_set_pools.
>
> Signed-off-by: Prabhakar Kushwaha 
> Reported-by: Jose Rivera 

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

Re: [U-Boot] [PATCH v5 1/3] net: phy: Optionally force master mode for RTL PHY

[Joe Hershberger]

Hi Hans,

On Mon, Mar 28, 2016 at 7:54 AM, Hans de Goede  wrote:
> Hi,
>
>
> On 25-03-16 22:11, Joe Hershberger wrote:
>>
>> On Fri, Mar 25, 2016 at 12:22 PM, Michael Haas
>>  wrote:
>>>
>>> This patch introduces CONFIG_RTL8211X_PHY_FORCE_MASTER. If this
>>> define is set, RTL8211x PHYs (except for the RTL8211F) will have their
>>> 1000BASE-T master/slave autonegotiation disabled and forced to master
>>> mode.
>>>
>>> This is helpful for PHYs like the RTL8211C which produce unstable links
>>> in slave mode. Such problems have been found on the A20-Olimex-SOM-EVB
>>> and A20-OLinuXino-Lime2.
>>>
>>> There is no proper way to identify affected PHYs in software as the
>>> RTL8211C shares its UID with the RTL8211B. Thus, this fix requires
>>> the introduction of an #ifdef.
>>>
>>> CC: fra...@gmail.com
>>> CC: mer...@debian.org
>>> CC: hdego...@redhat.com
>>> CC: i...@hellion.org.uk
>>> CC: joe.hershber...@ni.com
>>>
>>> Signed-off-by: Michael Haas 
>>> Tested-by: Karsten Merker 
>>
>>
>> Acked-by: Joe Hershberger 
>
>
> Series looks good to me:
>
> Acked-by: Hans de Goede 
>
> Joe, how do you want to proceed with upstreaming this, shall I take
> all 3 patches upstream through u-boot-sunxi ?

Sounds good to me.

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

Re: [U-Boot] [PATCH] common: env: support sata device

[Tom Rini]

On Mon, Mar 28, 2016 at 05:37:16PM +0800, Peng Fan wrote:

> Introduce env support for sata device.
> 1. Implement write_env/read_env/env_relocate_spec/saveenv/sata_get_env_dev
> 2. If want to enable this feature, define CONFIG_ENV_IS_IN_SATA, and
>define CONFIG_SYS_SATA_ENV_DEV or implement your own sata_get_ev_dev.
[snip]
> +/*
> + * TODO: Support CONFIG_ENV_SIZE_REDUND CONFIG_ENV_OFFSET_REDUND
> + */

I'd like to see #error here as well, having been bit in the past in
cases of "Oh, redund doesn't work?".

> +#if !defined(CONFIG_ENV_OFFSET) || !defined(CONFIG_ENV_SIZE)
> +#error CONFIG_ENV_OFFSET or CONFIG_ENV_SIZE not defined
> +#endif
> +
> +char *env_name_spec = "SATA";
> +
> +#ifdef ENV_IS_EMBEDDED
> +env_t *env_ptr = (env_t *)([0]);

So, you're not adding (and I'm not suggesting you do) SATA to the list
of environment types where we support embedded env.  Please just remove
these tests here and elsewhere.  Thanks!

[snip]
> +static inline int read_env(struct blk_desc *sata, unsigned long size,
> +unsigned long offset, const void *buffer)
> +{
> + uint blk_start, blk_cnt, n;
> +
> + blk_start = ALIGN(offset, sata->blksz) / sata->blksz;
> + blk_cnt   = ALIGN(size, sata->blksz) / sata->blksz;
> +
> + n = sata->block_read(sata, blk_start, blk_cnt, (uchar *)buffer);

Here and elsewhere, please update to use blk_dread, etc, from blk.h to
help future proof this code, thanks!

-- 
Tom


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

[U-Boot] is "quicc engine" supported on non-powerpc architectures?

[Robert P. J. Day]

  possibly a silly question but does the "quicc engine" exist on any
architecture but the powerpc? i ask since i just ran across this
snippet in include/linux/immap_qe.h:

#ifdef CONFIG_PPC
#define QE_IMMR_OFFSET  0x0014
#else
#define QE_IMMR_OFFSET  0x0140
#endif

which confuses me since it's checking for PPC, suggesting it might be
something else?

  normally, i wouldn't care but i'm working on some code based on
qe_lib and i was simply assuming it was always powerpc, now i'm not
sure. can someone clarify the above?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

Re: [U-Boot] [PATCH 1/3] drivers: block: add block device cache

[Eric Nelson]

Thanks Tom,

On 03/28/2016 07:16 AM, Tom Rini wrote:
> On Sun, Mar 27, 2016 at 12:00:13PM -0700, Eric Nelson wrote:
> 
>> +++ b/drivers/block/blkcache.c
> [snip]
>> +static int trace;
> 
> I see where you can toggle this at run-time.  But do we really think
> that this will be useful outside of debug?  My first reaction is that we
> should move the trace stuff into debug() statements instead.
> 

Will do.

Stephen had the same comment.

> [snip]
>> +#ifdef CONFIG_CMD_BLOCK_CACHE
> 
> Please split the command code into cmd/blkcache.c.  And yes, this might
> require thinking harder about what to expose or making an API for some
> of it.  I'm also not sure that's a bad thing as tuning the cache seems
> useful long term but dumping the stats seems more like debug work.
> 

Okay. I started to do that but stopped when I looked at the number
of implementation details needed by the commands themselves.

> [snip]
>> +/* Strip off leading 'i2c' command argument */
>> +argc--;
>> +argv++;
> 
> I see you borrowed from i2c here :)
> 
Yep. Oops.

Regards,


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

Re: [U-Boot] [PATCH 3/3] sata: use block layer for sata command

[Tom Rini]

On Sun, Mar 27, 2016 at 12:00:15PM -0700, Eric Nelson wrote:

> Call blk_dread, blk_dwrite, blk_derase to ensure that the block cache is
> used if enabled and to remove build breakage when CONFIG_BLK is enabled.
> 
> Signed-off-by: Eric Nelson 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH 2/3] mmc: use block layer in mmc command

[Tom Rini]

On Sun, Mar 27, 2016 at 12:00:14PM -0700, Eric Nelson wrote:

> Call blk_dread, blk_dwrite, blk_derase to ensure that the block cache is
> used if enabled and to remove build breakage when CONFIG_BLK is enabled.
> 
> Signed-off-by: Eric Nelson 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH 1/3] drivers: block: add block device cache

[Tom Rini]

On Sun, Mar 27, 2016 at 12:00:13PM -0700, Eric Nelson wrote:

> +++ b/drivers/block/blkcache.c
[snip]
> +static int trace;

I see where you can toggle this at run-time.  But do we really think
that this will be useful outside of debug?  My first reaction is that we
should move the trace stuff into debug() statements instead.

[snip]
> +#ifdef CONFIG_CMD_BLOCK_CACHE

Please split the command code into cmd/blkcache.c.  And yes, this might
require thinking harder about what to expose or making an API for some
of it.  I'm also not sure that's a bad thing as tuning the cache seems
useful long term but dumping the stats seems more like debug work.

[snip]
> + /* Strip off leading 'i2c' command argument */
> + argc--;
> + argv++;

I see you borrowed from i2c here :)

-- 
Tom


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

Re: [U-Boot] [PATCH 4/7] kc1: Add some sysboot and devicetree-related environment variables

[Tom Rini]

On Mon, Mar 28, 2016 at 02:07:11PM +0200, Paul Kocialkowski wrote:

> This adds some environment variables for sysboot and devicetree.
> 
> Signed-off-by: Paul Kocialkowski 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH 7/7] sniper: Change vendor name from lge to lg, matching devicetree vendor prefix

[Tom Rini]

On Mon, Mar 28, 2016 at 02:07:14PM +0200, Paul Kocialkowski wrote:

> This moves the sniper board from the lge to lg, in order to match the 
> devicetree
> vendor prefix already defined in the kernel.
> 
> Signed-off-by: Paul Kocialkowski 
> ---
>  arch/arm/cpu/armv7/omap3/Kconfig |   2 +-
>  board/lg/sniper/Kconfig  |  12 ++
>  board/lg/sniper/MAINTAINERS  |   6 +
>  board/lg/sniper/Makefile |   9 +
>  board/lg/sniper/sniper.c | 191 
>  board/lg/sniper/sniper.h | 365 
> +++
>  board/lge/sniper/Kconfig |  12 --
>  board/lge/sniper/MAINTAINERS |   6 -
>  board/lge/sniper/Makefile|   9 -
>  board/lge/sniper/sniper.c| 191 
>  board/lge/sniper/sniper.h| 365 
> ---
>  11 files changed, 584 insertions(+), 584 deletions(-)
>  create mode 100644 board/lg/sniper/Kconfig
>  create mode 100644 board/lg/sniper/MAINTAINERS
>  create mode 100644 board/lg/sniper/Makefile
>  create mode 100644 board/lg/sniper/sniper.c
>  create mode 100644 board/lg/sniper/sniper.h
>  delete mode 100644 board/lge/sniper/Kconfig
>  delete mode 100644 board/lge/sniper/MAINTAINERS
>  delete mode 100644 board/lge/sniper/Makefile
>  delete mode 100644 board/lge/sniper/sniper.c
>  delete mode 100644 board/lge/sniper/sniper.h

Please use -M so that renames are caught better.  Also:

> +++ b/board/lg/sniper/MAINTAINERS
> @@ -0,0 +1,6 @@
> +SNIPER BOARD
> +M:   Paul Kocialkowski 
> +S:   Maintained
> +F:   board/lge/sniper/

Need to fixup that one :)

-- 
Tom


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

Re: [U-Boot] [PATCH 5/7] sniper: Proper reboot mode and boot reason validation

[Tom Rini]

On Mon, Mar 28, 2016 at 02:07:12PM +0200, Paul Kocialkowski wrote:

> With the previous implementation, rebooting without registering a recognized
> reboot mode (despite registering the magic) would end up with U-Boot checking
> for a valid power-on reason, which might result in the device turning off 
> (e.g.
> with no USB cable attached and no buttons pressed).
> 
> This was designed to catch reboots that are actually intended to be power-off,
> something that old Android kernels do, instead of properly turning the device
> off using the TWL4030.
> 
> However, since this approach is not viable (breaks reboot in most cases), the
> validity of the reboot mode magic is checked to detect a reboot and the 'o' 
> char
> is recognized to indicate that power-off is required. Still, that might be
> overridden by the detection of usual power-on reasons, on purpose.
> 
> Signed-off-by: Paul Kocialkowski 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH 6/7] kc1: Proper reboot mode and boot reason validation

[Tom Rini]

On Mon, Mar 28, 2016 at 02:07:13PM +0200, Paul Kocialkowski wrote:

> With the previous implementation, rebooting without registering a recognized
> reboot mode would end up with U-Boot checking for a valid power-on reason, 
> which
> might result in the device turning off (e.g. with no USB cable attached and no
> buttons pressed).
> 
> Since this approach is not viable (breaks reboot in most cases), the validity 
> of
> the reboot reason is checked (in turn, by checking that a warm reset happened,
> as there is no magic) to detect a reboot and the 'o' char is recognized to
> indicate that power-off is required. Still, that might be overridden by the
> detection of usual power-on reasons, on purpose.
> 
> Signed-off-by: Paul Kocialkowski 

Reviewed-by: Tom Rini 

... but since Sniper and KC1 are doing the same thing, and other OMAP
devices that are also Android devices will also be in the same camp, can
we perhaps include some of the above information in a comment, make
android_omap_reboot_mode (or something along those lines) in
arch/arm/cpu/armv7/omap-common/something-appropriate.c ?

-- 
Tom


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

Re: [U-Boot] [PATCH 3/7] kc1: Select libfdt to allow running devicetree-based kernels

[Tom Rini]

On Mon, Mar 28, 2016 at 02:07:10PM +0200, Paul Kocialkowski wrote:

> Selecting CONFIG_OF_LIBFDT allows running recent mainline kernels.
> 
> Signed-off-by: Paul Kocialkowski 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH 2/7] kc1: Include explicit serial baudrate on bootargs

[Tom Rini]

On Mon, Mar 28, 2016 at 02:07:09PM +0200, Paul Kocialkowski wrote:

> This makes the baudrate for the kernel command line explicit.
> 
> Signed-off-by: Paul Kocialkowski 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH 1/7] sniper: Include explicit serial baudrate on bootargs

[Tom Rini]

On Mon, Mar 28, 2016 at 02:07:08PM +0200, Paul Kocialkowski wrote:

> This makes the baudrate for the kernel command line explicit.
> 
> Signed-off-by: Paul Kocialkowski 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH] common: env_sf: Add exclamation mark

[Tom Rini]

On Mon, Mar 28, 2016 at 05:26:27PM +0800, Peng Fan wrote:

> Add exclamation mark to the errmsg, when error and set_default_env.

This is awkwardly worded.  We aren't adding a literal ! to the errmsg
itself, we're adding that as a flag.  I'll try and re-word this when
applying to be clearer.

> 
> Signed-off-by: Peng Fan 
> Cc: Mario Schuknecht 
> Cc: Vignesh R 
> Cc: Jagan Teki 
> Cc: Ravi Babu 
> Cc: York Sun 
> Cc: Tom Rini 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH 6/6] kc1: Add some sysboot and devicetree-related environment variables

[Tom Rini]

On Mon, Mar 28, 2016 at 01:55:15PM +0200, Paul Kocialkowski wrote:
> Le samedi 26 mars 2016 à 15:21 -0400, Tom Rini a écrit :
> > On Sat, Mar 26, 2016 at 12:20:04PM +0100, Paul Kocialkowski wrote:
> > 
> > > 
> > > This adds some environment variables for sysboot and devicetree.
> > > 
> > > Signed-off-by: Paul Kocialkowski 
> > > ---
> > >  include/configs/kc1.h | 2 ++
> > >  1 file changed, 2 insertions(+)
> > > 
> > > diff --git a/include/configs/kc1.h b/include/configs/kc1.h
> > > index 1e6b037..e19fa12 100644
> > > --- a/include/configs/kc1.h
> > > +++ b/include/configs/kc1.h
> > > @@ -233,6 +233,8 @@
> > >   "boot_mmc_dev=0\0" \
> > >   "kernel_mmc_part=7\0" \
> > >   "recovery_mmc_part=5\0" \
> > > + "fdtfile=omap4-kc1.dtb\0" \
> > > + "bootfile=/boot/extlinux/extlinux.conf\0" \
> > >   "bootargs=console=ttyO2,115200 mem=512M\0"
> > Maybe time to look in to config_distro_bootcmd too?
> 
> Well, both sniper and kc1 are mobile devices that people will likely want to 
> run
> Android on, so that's what I'm targetting as default.
> 
> At this point, there is no dt-enabled kernel capable of running Android for
> these devices, and mainline Linux is still a very early effort. Thus, I'm 
> making
> those variables available to make it easier to hack on mainline Linux, but I
> don't want it to be the default (yet).

OK, thanks.

-- 
Tom


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

Re: [U-Boot] [PATCH v7 00/87] mtd: Add SPI-NOR core support

[Tom Rini]

On Mon, Mar 28, 2016 at 05:02:45PM +0530, Jagan Teki wrote:
> On 22 March 2016 at 20:25, Tom Rini  wrote:
> > On Tue, Mar 22, 2016 at 01:19:25PM +0530, Jagan Teki wrote:
> > [snip]
> >> Issues:
> >> ---
> >> 1) undefined reference to `__aeabi_ldivmod'
> >>
> >> 59: config: Enable SPI-NOR framework
> >>arm:  +   nyan-big
> >> +drivers/mtd/spi-nor/built-in.o: In function `spi_nor_write':
> >> +build/../drivers/mtd/spi-nor/spi-nor.c:585: undefined reference to
> >> `__aeabi_ldivmod'
> >> +arm-unknown-linux-gnueabi-ld.bfd: BFD (GNU Binutils) 2.24 assertion
> >> fail /home/tony/buildall/src/binutils/bfd/elf32-arm.c:7696
> >> +arm-unknown-linux-gnueabi-ld.bfd: error: required section
> >> '.rel.plt' not found in the linker script
> >> +arm-unknown-linux-gnueabi-ld.bfd: final link failed: Invalid operation
> >> +make[1]: *** [u-boot] Error 1
> >> +make: *** [sub-make] Error 2
> >
> > So this is a 64bit division problem somewhere along the lines that needs
> > to be using one of the normal helper functions.
> >
> >> 2) Build issues on dra72_evm, dra74_evm
> >
> > What are they?
> 
> Build issue with spl, I guess this is because dm used for normal
> u-boot and not used for spl.

Yes, this is still true.  It sounds like you need to make sure that the
code continues to build for both cases?

> 
> Mugunthan, can you look in to this?
> 
> >
> >> 3) SPL image too big
> >>
> >> 59: config: Enable SPI-NOR framework
> >>arm:  +   axm
> >> +arm-unknown-linux-gnueabi-ld.bfd: SPL image too big
> >> +arm-unknown-linux-gnueabi-ld.bfd: SPL image BSS too big
> >> +make[2]: *** [spl/u-boot-spl] Error 1
> >> +make[1]: *** [spl/u-boot-spl] Error 2
> >> +make: *** [sub-make] Error 2
> >
> > Sounds like you need to go back and take some care about how we do this
> > in SPL.  Given the current gcc issue wrt merging strings together, we
> > may need to be more careful about what files we compile and link for SPL
> > in this case and perhaps need to split a file or two up.
> 
> With proper commenting code for SPL build on mtdcore and changes on
> SPL size macros, build look fine.
> 
> +++ b/include/configs/taurus.h
> -#define CONFIG_SPL_MAX_SIZE(31 * SZ_512)
> +#define CONFIG_SPL_MAX_SIZE(36 * SZ_512)
> -#define CONFIG_SPL_BSS_MAX_SIZE(3 * SZ_512)
> +#define CONFIG_SPL_BSS_MAX_SIZE(4 * SZ_512)

OK, but we can't just increase the sizes here, these platforms have a
small footprint we need to stick to.  We need to see what can be trimmed
out to make them continue to fit.

-- 
Tom


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

[U-Boot] [PATCH] post: Remove references to scrapped "netta" board.

[Robert P. J. Day]

Given that README.scrapyard shows scrapping of netta boards:

netta2   powerpc mpc8xx c51c1c9a2014-07-07
nettapowerpc mpc8xx c51c1c9a2014-07-07

delete netta example from POST tests.

Signed-off-by: Robert P. J. Day 

---

  this will slightly conflict with my earlier patch, removing "lwmon"
from the post/ Makefile.

 post/Makefile |  2 +-
 post/board/netta/Makefile |  8 
 post/board/netta/codec.c  | 29 -
 post/board/netta/dsp.c| 29 -
 4 files changed, 1 insertion(+), 67 deletions(-)
 delete mode 100644 post/board/netta/Makefile
 delete mode 100644 post/board/netta/codec.c
 delete mode 100644 post/board/netta/dsp.c

diff --git a/post/Makefile b/post/Makefile
index 2fa6f8a..4b148ef 100644
--- a/post/Makefile
+++ b/post/Makefile
@@ -13,6 +13,6 @@ obj-$(CONFIG_PPC) += lib_powerpc/
 obj-$(CONFIG_MPC83xx) += cpu/mpc83xx/
 obj-$(CONFIG_8xx) += cpu/mpc8xx/
 obj-$(CONFIG_4xx) += cpu/ppc4xx/
-ifneq ($(filter lwmon lwmon5 netta pdm360ng,$(BOARD)),)
+ifneq ($(filter lwmon lwmon5 pdm360ng,$(BOARD)),)
 obj-y += board/$(BOARD)/
 endif
diff --git a/post/board/netta/Makefile b/post/board/netta/Makefile
deleted file mode 100644
index 8fc1945..000
--- a/post/board/netta/Makefile
+++ /dev/null
@@ -1,8 +0,0 @@
-#
-# (C) Copyright 2002-2006
-# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
-#
-# SPDX-License-Identifier: GPL-2.0+
-#
-
-obj-y += codec.o dsp.o
diff --git a/post/board/netta/codec.c b/post/board/netta/codec.c
deleted file mode 100644
index 7ff890a..000
--- a/post/board/netta/codec.c
+++ /dev/null
@@ -1,29 +0,0 @@
-/*
- * (C) Copyright 2004
- * Pantelis Antoniou, Intracom S.A. , pa...@intracom.gr
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-#include 
-
-/*
- * CODEC test
- *
- * This test verifies the connection and performs a memory test
- * on any connected codec(s). The meat of the work is done
- * in the board specific function.
- */
-
-#include 
-
-#if CONFIG_POST & CONFIG_SYS_POST_CODEC
-
-extern int board_post_codec(int flags);
-
-int codec_post_test (int flags)
-{
-   return board_post_codec(flags);
-}
-
-#endif /* CONFIG_POST & CONFIG_SYS_POST_CODEC */
diff --git a/post/board/netta/dsp.c b/post/board/netta/dsp.c
deleted file mode 100644
index f88c379..000
--- a/post/board/netta/dsp.c
+++ /dev/null
@@ -1,29 +0,0 @@
-/*
- * (C) Copyright 2004
- * Pantelis Antoniou, Intracom S.A. , pa...@intracom.gr
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-#include 
-
-/*
- * DSP test
- *
- * This test verifies the connection and performs a memory test
- * on any connected DSP(s). The meat of the work is done
- * in the board specific function.
- */
-
-#include 
-
-#if CONFIG_POST & CONFIG_SYS_POST_DSP
-
-extern int board_post_dsp(int flags);
-
-int dsp_post_test (int flags)
-{
-   return board_post_dsp(flags);
-}
-
-#endif /* CONFIG_POST & CONFIG_SYS_POST_DSP */
-- 
2.5.5


-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

[U-Boot] [PATCH] ARM: uniphier: add PH1-LD20 SoC support

[Masahiro Yamada]

This is the first ARMv8 SoC from Socionext Inc.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/mach-uniphier/Kconfig|  5 ++
 arch/arm/mach-uniphier/Makefile   |  1 +
 arch/arm/mach-uniphier/arm64/Makefile |  8 +++
 arch/arm/mach-uniphier/arm64/mem_map.c| 28 +
 arch/arm/mach-uniphier/board_late_init.c  |  2 +-
 arch/arm/mach-uniphier/boards.c   | 25 
 arch/arm/mach-uniphier/boot-mode/Makefile |  1 +
 arch/arm/mach-uniphier/boot-mode/boot-device.h|  2 +
 arch/arm/mach-uniphier/boot-mode/boot-mode-ld20.c | 77 +++
 arch/arm/mach-uniphier/boot-mode/boot-mode.c  |  4 ++
 arch/arm/mach-uniphier/boot-mode/cmd_pinmon.c |  5 ++
 arch/arm/mach-uniphier/cpu_info.c |  2 +-
 arch/arm/mach-uniphier/dram/Makefile  |  1 +
 arch/arm/mach-uniphier/dram/umc-ld20.c| 14 +
 arch/arm/mach-uniphier/early-clk/Makefile |  1 +
 arch/arm/mach-uniphier/early-clk/early-clk-ld20.c | 12 
 arch/arm/mach-uniphier/init.h |  2 +
 arch/arm/mach-uniphier/init/Makefile  |  1 +
 arch/arm/mach-uniphier/init/init-ld20.c   | 55 
 arch/arm/mach-uniphier/init/init.c|  5 ++
 arch/arm/mach-uniphier/memconf/Makefile   |  1 +
 arch/arm/mach-uniphier/memconf/memconf-pxs2.c |  3 +
 arch/arm/mach-uniphier/sbc/Makefile   |  1 +
 arch/arm/mach-uniphier/sg-regs.h  |  3 +-
 configs/uniphier_ld20_defconfig   | 28 +
 include/configs/uniphier.h| 24 ++-
 26 files changed, 305 insertions(+), 6 deletions(-)
 create mode 100644 arch/arm/mach-uniphier/arm64/Makefile
 create mode 100644 arch/arm/mach-uniphier/arm64/mem_map.c
 create mode 100644 arch/arm/mach-uniphier/boot-mode/boot-mode-ld20.c
 create mode 100644 arch/arm/mach-uniphier/dram/umc-ld20.c
 create mode 100644 arch/arm/mach-uniphier/early-clk/early-clk-ld20.c
 create mode 100644 arch/arm/mach-uniphier/init/init-ld20.c
 create mode 100644 configs/uniphier_ld20_defconfig

diff --git a/arch/arm/mach-uniphier/Kconfig b/arch/arm/mach-uniphier/Kconfig
index 4724af5..87d1675 100644
--- a/arch/arm/mach-uniphier/Kconfig
+++ b/arch/arm/mach-uniphier/Kconfig
@@ -23,6 +23,11 @@ config ARCH_UNIPHIER_PRO5_PXS2_LD6B
bool "UniPhier PH1-Pro5/ProXstream2/PH1-LD6b SoC"
select CPU_V7
 
+config ARCH_UNIPHIER_LD20
+   bool "UniPhier PH1-LD20 SoC"
+   select ARM64
+   select SPL_SEPARATE_BSS
+
 endchoice
 
 config ARCH_UNIPHIER_LD4
diff --git a/arch/arm/mach-uniphier/Makefile b/arch/arm/mach-uniphier/Makefile
index 35edca1..774ea99 100644
--- a/arch/arm/mach-uniphier/Makefile
+++ b/arch/arm/mach-uniphier/Makefile
@@ -31,3 +31,4 @@ obj-$(CONFIG_MICRO_SUPPORT_CARD) += micro-support-card.o
 obj-$(CONFIG_DEBUG_UART_UNIPHIER) += debug-uart/
 
 obj-$(CONFIG_CPU_V7) += arm32/
+obj-$(CONFIG_ARM64) += arm64/
diff --git a/arch/arm/mach-uniphier/arm64/Makefile 
b/arch/arm/mach-uniphier/arm64/Makefile
new file mode 100644
index 000..3e69eab
--- /dev/null
+++ b/arch/arm/mach-uniphier/arm64/Makefile
@@ -0,0 +1,8 @@
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+obj- += dummy.o
+ifndef CONFIG_SPL_BUILD
+obj-y += mem_map.o
+endif
diff --git a/arch/arm/mach-uniphier/arm64/mem_map.c 
b/arch/arm/mach-uniphier/arm64/mem_map.c
new file mode 100644
index 000..74ef919
--- /dev/null
+++ b/arch/arm/mach-uniphier/arm64/mem_map.c
@@ -0,0 +1,28 @@
+/*
+ * Copyright (C) 2016 Masahiro Yamada 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+
+static struct mm_region uniphier_mem_map[] = {
+   {
+   .base = 0x,
+   .size = 0x8000,
+   .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
+PTE_BLOCK_NON_SHARE |
+PTE_BLOCK_PXN | PTE_BLOCK_UXN
+   },
+   {
+   .base = 0x8000,
+   .size = 0xc000,
+   .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
+PTE_BLOCK_INNER_SHARE
+   },
+   { /* sentinel */ }
+};
+
+struct mm_region *mem_map = uniphier_mem_map;
diff --git a/arch/arm/mach-uniphier/board_late_init.c 
b/arch/arm/mach-uniphier/board_late_init.c
index 6e2008c..a440a7e 100644
--- a/arch/arm/mach-uniphier/board_late_init.c
+++ b/arch/arm/mach-uniphier/board_late_init.c
@@ -36,7 +36,7 @@ struct uniphier_fdt_file {
 static const struct uniphier_fdt_file uniphier_fdt_files[] = {
{ "socionext,ph1-ld4-ref", "uniphier-ph1-ld4-ref.dtb", },
{ "socionext,ph1-ld6b-ref", "uniphier-ph1-ld6b-ref.dtb", },
-   { "socionext,ph1-ld10-ref", "uniphier-ph1-ld10-ref.dtb", },
+   { "socionext,ph1-ld20-ref", "uniphier-ph1-ld20-ref.dtb", },
{ "socionext,ph1-pro4-ace", "uniphier-ph1-pro4-ace.dtb", },

[U-Boot] [PATCH] ARM: dts: uniphier: move aliases node up to make fdtgrep happy

[Masahiro Yamada]

Currently, fdtgrep would not accept uniphier-ph1-ld20-ref.dtb
and uniphier-ph1-ld11-ref.dtb unless the aliases node comes
the first in the root node.

$ make -s uniphier_pxs2_ld6b_defconfig
$ make CROSS_COMPILE=arm-linux-gnueabi- DEVICE_TREE=uniphier-ph1-ld20-ref
  [snip]
  LDS spl/u-boot-spl.lds
  LD  spl/u-boot-spl
  OBJCOPY spl/u-boot-spl-nodtb.bin
  FDTGREP spl/u-boot-spl.dtb
Error at 'fdt_find_regions': FDT_ERR_BADLAYOUT
/aliases node must come before all other nodes
Error: FDT_ERR_BADMAGIC
make[1]: *** [spl/u-boot-spl.dtb] Error 1
make: *** [spl/u-boot-spl] Error 2

This commit moves the aliases node as the error message from the
fdtgrep tool suggests, although this requirement does not sound
reasonable to me.

Signed-off-by: Masahiro Yamada 
---

Simon,

I'd like to avoid this patch if possible.

Not figured out the root cause of the problem yet?



 arch/arm/dts/uniphier-ph1-ld11-ref.dts | 18 +-
 arch/arm/dts/uniphier-ph1-ld20-ref.dts | 18 +-
 2 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/arch/arm/dts/uniphier-ph1-ld11-ref.dts 
b/arch/arm/dts/uniphier-ph1-ld11-ref.dts
index a624a49..88e7f53 100644
--- a/arch/arm/dts/uniphier-ph1-ld11-ref.dts
+++ b/arch/arm/dts/uniphier-ph1-ld11-ref.dts
@@ -14,15 +14,6 @@
model = "UniPhier PH1-LD11 Reference Board";
compatible = "socionext,ph1-ld11-ref", "socionext,ph1-ld11";
 
-   memory {
-   device_type = "memory";
-   reg = <0 0x8000 0 0x4000>;
-   };
-
-   chosen {
-   stdout-path = "serial0:115200n8";
-   };
-
aliases {
serial0 = 
serial1 = 
@@ -35,6 +26,15 @@
i2c4 = 
i2c5 = 
};
+
+   memory {
+   device_type = "memory";
+   reg = <0 0x8000 0 0x4000>;
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
 };
 
  {
diff --git a/arch/arm/dts/uniphier-ph1-ld20-ref.dts 
b/arch/arm/dts/uniphier-ph1-ld20-ref.dts
index 108adeb..a55d90c 100644
--- a/arch/arm/dts/uniphier-ph1-ld20-ref.dts
+++ b/arch/arm/dts/uniphier-ph1-ld20-ref.dts
@@ -14,15 +14,6 @@
model = "UniPhier PH1-LD20 Reference Board";
compatible = "socionext,ph1-ld20-ref", "socionext,ph1-ld20";
 
-   memory {
-   device_type = "memory";
-   reg = <0 0x8000 0 0xc000>;
-   };
-
-   chosen {
-   stdout-path = "serial0:115200n8";
-   };
-
aliases {
serial0 = 
serial1 = 
@@ -35,6 +26,15 @@
i2c4 = 
i2c5 = 
};
+
+   memory {
+   device_type = "memory";
+   reg = <0 0x8000 0 0xc000>;
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
 };
 
  {
-- 
1.9.1

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

Re: [U-Boot] Linux hangs due to commit v2015.10-15-g02cc27c on loading i2c-mv64xx

[Hans de Goede]

Hi,

On 25-03-16 08:59, Michael Haas wrote:

On 03/20/2016 08:15 PM, Hans de Goede wrote:

I'm running Debian Jessie with Linux 4.3.0-0.bpo.1-armmp-lpae on my
a20-olinuxino-lime2.
I have noticed that my board hangs with my recent u-boot versions

when I

load the i2c module.

git-bisect narrowed the problem down to the following commit:

02cc27c74f9b884b538bcd1b93342a4c05b5d608 is the first bad commit
commit 02cc27c74f9b884b538bcd1b93342a4c05b5d608
Author: Hans de Goede 
Date:   Sat Oct 3 15:29:24 2015 +0200

sunxi: power: Change axp209 LDO3 and LDO4 default to disabled





The axp209 is attached to the i2c bus, so that is likely the real
culprit. In my setup, the axp209 drivers are loaded before I insert
i2c-mv64xxx.

What would be the best course of action here?

* Revert the commit
* Enable LDO3 and LDO4 for the a20-olinuxino-lime2 only?
* Fix linux


I would go for option 3: "Fix linux", looking at the lime2 dts I see:

 vcc_csi0: ldo3 {
 regulator-min-microvolt = <70>;
 regulator-max-microvolt = <350>;
 regulator-always-on;
 };

 vcc_csi1: ldo4 {
 regulator-min-microvolt = <125>;
 regulator-max-microvolt = <330>;
 regulator-always-on;
 };

The regulator-always-on will cause both regulators to get turned on,
but the min / max constraints match the datasheet constrains / the
absolute min / max values these ldo-s can deliver, not the constraints
which the board design puts on these.

So now these ldo-s end up getting turned on at whatever voltage
is the default (which according to the datasheet is unknown),
where as the schematic says that if these get turned on (which
is not necessary) they should be run at 2.8V.

This dts file is the only axp209 using dts file which:

1) Does not have proper constraints for LDO3 / LDO4
2) Uses regulator-always-on; for these

I would suggest fixing both, first you can try making min = max =
280. And if that fixes things, which I expect it will, I would
also drop the regulator-always-on from the dts, since we really
only need to turn these on when using the csi interface in which
case it would be up to the csi driver to explicitly turn them on.



Setting the voltage to 2.8V does not seem to fix things. Dropping the
'regulator-always-on' stance does allow me to
load and use i2c-mv64xx and axp20x-i2c.

Is that something I should submit upstream or is there further
investigation needed why simply setting a proper voltage
does not work?


See my reply in the kernel / dts patches thread about this,
TL;DR:

Lets change the Lime defconfig to enable ldo3/4 at 2800 mV in u-boot.

Regards,

Hans

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

Re: [U-Boot] Ethernet via USB on Sinlinx SinA33

[Hans de Goede]

Hi,

On 25-03-16 18:14, Quentin Schulz wrote:

Hi,

I am trying to get Ethernet to work through the USB port of the Sinlinx
SinA33 on U-Boot to use TFTP to get the kernel and dtb files.

However, I am getting 'data abort' when using dhcp or tftp after adding:
#define CONFIG_USB_HOST_ETHER
#define CONFIG_USB_ETHER_ASIX

to include/configs/sunxi-common.h and checking CONFIG_USB_EHCI_HCD as
told in the documentation [1]

I tested this configuration with the C.H.I.P. and it is working well.


Are you perhaps building u-boot with gcc6 ? There are some known issues
when building u-boot with gcc-6, which look pretty much like this.

Is the ethernet adapter connected to a regular usb host port, or to
the otg port ?

Regards,

Hans





Steps to reproduce:

1) Add the following lines to include/configs/sunxi-common.h:

#define CONFIG_USB_HOST_ETHER
#define CONFIG_USB_ETHER_ASIX

2) make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- Sinlinx_SinA33_defconfig
3) make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- menuconfig
4) Check CONFIG_USB_EHCI_HC and save configuration
5) make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- -j$(nproc)
6) Prepare SDCard:
sudo dd if=u-boot-sunxi-with-spl.bin of=/dev/sdX bs=1024 seek=8
7) Boot the board and run dhcp or tftp
8) Get 'data abort' and board gets reset (ethact is also not defined)

The log file is attached.

Thank you,

Quentin

[1] https://github.com/lentinj/u-boot/blob/master/doc/README.usb#L132


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

Re: [U-Boot] [PATCH v5 1/3] net: phy: Optionally force master mode for RTL PHY

[Hans de Goede]

Hi,

On 25-03-16 22:11, Joe Hershberger wrote:

On Fri, Mar 25, 2016 at 12:22 PM, Michael Haas
 wrote:

This patch introduces CONFIG_RTL8211X_PHY_FORCE_MASTER. If this
define is set, RTL8211x PHYs (except for the RTL8211F) will have their
1000BASE-T master/slave autonegotiation disabled and forced to master
mode.

This is helpful for PHYs like the RTL8211C which produce unstable links
in slave mode. Such problems have been found on the A20-Olimex-SOM-EVB
and A20-OLinuXino-Lime2.

There is no proper way to identify affected PHYs in software as the
RTL8211C shares its UID with the RTL8211B. Thus, this fix requires
the introduction of an #ifdef.

CC: fra...@gmail.com
CC: mer...@debian.org
CC: hdego...@redhat.com
CC: i...@hellion.org.uk
CC: joe.hershber...@ni.com

Signed-off-by: Michael Haas 
Tested-by: Karsten Merker 


Acked-by: Joe Hershberger 


Series looks good to me:

Acked-by: Hans de Goede 

Joe, how do you want to proceed with upstreaming this, shall I take
all 3 patches upstream through u-boot-sunxi ?

Regards,

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

[U-Boot] (brief?) question on POST, post_test "void (*reloc) (void)" member

[Robert P. J. Day]

  i was about to dig into this until i noticed that, since i'm working
on PPC, i shouldn't(?) care about it.

  as i read it, if one sets that function pointer, as in (from
post/tests.c):

#if CONFIG_POST & CONFIG_SYS_POST_SYSMON
{
"SYSMON test",
"sysmon",
"This test monitors system hardware.",
POST_RAM | POST_ALWAYS,
_post_test,
_init_f,
_reloc,   <- there
CONFIG_SYS_POST_SYSMON
},
#endif

the only place i see that function being invoked is in post/post.c,
and requires the config setting CONFIG_NEEDS_MANUAL_RELOC:

#ifdef CONFIG_NEEDS_MANUAL_RELOC
void post_reloc(void)
{
unsigned int i;

/*
 * We have to relocate the test table manually
 */
for (i = 0; i < post_list_size; i++) {

... snip ...

if (test->reloc) {
addr = (ulong)(test->reloc) + gd->reloc_off;
test->reloc = (void (*)(void)) addr;

test->reloc();<- invoke there
}
}
}
#endif

  but the only architectures that define that config option don't
appear to include PPC:

$ grep -r "define CONFIG_NEEDS_MANUAL_RELOC" *
arch/sparc/include/asm/config.h:#define CONFIG_NEEDS_MANUAL_RELOC
arch/nds32/include/asm/config.h:#define CONFIG_NEEDS_MANUAL_RELOC
arch/microblaze/include/asm/config.h:#define CONFIG_NEEDS_MANUAL_RELOC
arch/avr32/include/asm/config.h:#define CONFIG_NEEDS_MANUAL_RELOC
arch/m68k/include/asm/config.h:#define CONFIG_NEEDS_MANUAL_RELOC
include/configs/adp-ag101p.h:#define CONFIG_NEEDS_MANUAL_RELOC
$

  so unless there is some weird corner case where one would register a
function pointer there for some specific PPC board, am i safe to
ignore that for PPC? (i do notice that, for the sample board lwmon5,
one is forced to register a no-op routine there simply because you
*must* assign a function there if you select that test.)

  probably a couple more POST-related questions coming, at which point
i'll put together a patch to update doc/README.POST unless someone
else is already on that.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

[U-Boot] [PATCH] ARM: dts: uniphier: add NAND pinmux node

[Masahiro Yamada]

This will be used to set up pin-muxing for the NAND controller.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/dts/uniphier-pinctrl.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/dts/uniphier-pinctrl.dtsi 
b/arch/arm/dts/uniphier-pinctrl.dtsi
index 988e60a..2d36f98 100644
--- a/arch/arm/dts/uniphier-pinctrl.dtsi
+++ b/arch/arm/dts/uniphier-pinctrl.dtsi
@@ -42,6 +42,11 @@
function = "i2c4";
};
 
+   pinctrl_nand: nand_grp {
+   groups = "nand";
+   function = "nand";
+   };
+
pinctrl_sd: sd_grp {
groups = "sd";
function = "sd";
-- 
1.9.1

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

[U-Boot] [PATCH] ARM: dts: uniphier: add clock-frequency for LD11/LD20 DTSI

[Masahiro Yamada]

Since no clock driver is implemented for peripherals in U-Boot yet,
this property is needed for the serial driver to set up the divisor
register.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/dts/uniphier-ph1-ld11.dtsi | 4 
 arch/arm/dts/uniphier-ph1-ld20.dtsi | 4 
 2 files changed, 8 insertions(+)

diff --git a/arch/arm/dts/uniphier-ph1-ld11.dtsi 
b/arch/arm/dts/uniphier-ph1-ld11.dtsi
index 069cdf2..7d498ce 100644
--- a/arch/arm/dts/uniphier-ph1-ld11.dtsi
+++ b/arch/arm/dts/uniphier-ph1-ld11.dtsi
@@ -69,6 +69,7 @@
pinctrl-names = "default";
pinctrl-0 = <_uart0>;
clocks = <_clk>;
+   clock-frequency = <5882>;
};
 
serial1: serial@54006900 {
@@ -79,6 +80,7 @@
pinctrl-names = "default";
pinctrl-0 = <_uart1>;
clocks = <_clk>;
+   clock-frequency = <5882>;
};
 
serial2: serial@54006a00 {
@@ -89,6 +91,7 @@
pinctrl-names = "default";
pinctrl-0 = <_uart2>;
clocks = <_clk>;
+   clock-frequency = <5882>;
};
 
serial3: serial@54006b00 {
@@ -99,6 +102,7 @@
pinctrl-names = "default";
pinctrl-0 = <_uart3>;
clocks = <_clk>;
+   clock-frequency = <5882>;
};
 
i2c0: i2c@5878 {
diff --git a/arch/arm/dts/uniphier-ph1-ld20.dtsi 
b/arch/arm/dts/uniphier-ph1-ld20.dtsi
index 1bb45be..fc1c6bf 100644
--- a/arch/arm/dts/uniphier-ph1-ld20.dtsi
+++ b/arch/arm/dts/uniphier-ph1-ld20.dtsi
@@ -105,6 +105,7 @@
pinctrl-names = "default";
pinctrl-0 = <_uart0>;
clocks = <_clk>;
+   clock-frequency = <5882>;
};
 
serial1: serial@54006900 {
@@ -115,6 +116,7 @@
pinctrl-names = "default";
pinctrl-0 = <_uart1>;
clocks = <_clk>;
+   clock-frequency = <5882>;
};
 
serial2: serial@54006a00 {
@@ -125,6 +127,7 @@
pinctrl-names = "default";
pinctrl-0 = <_uart2>;
clocks = <_clk>;
+   clock-frequency = <5882>;
};
 
serial3: serial@54006b00 {
@@ -135,6 +138,7 @@
pinctrl-names = "default";
pinctrl-0 = <_uart3>;
clocks = <_clk>;
+   clock-frequency = <5882>;
};
 
i2c0: i2c@5878 {
-- 
1.9.1

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

[U-Boot] [PATCH 5/7] sniper: Proper reboot mode and boot reason validation

[Paul Kocialkowski]

With the previous implementation, rebooting without registering a recognized
reboot mode (despite registering the magic) would end up with U-Boot checking
for a valid power-on reason, which might result in the device turning off (e.g.
with no USB cable attached and no buttons pressed).

This was designed to catch reboots that are actually intended to be power-off,
something that old Android kernels do, instead of properly turning the device
off using the TWL4030.

However, since this approach is not viable (breaks reboot in most cases), the
validity of the reboot mode magic is checked to detect a reboot and the 'o' char
is recognized to indicate that power-off is required. Still, that might be
overridden by the detection of usual power-on reasons, on purpose.

Signed-off-by: Paul Kocialkowski 
---
 board/lge/sniper/sniper.c | 33 +++--
 1 file changed, 23 insertions(+), 10 deletions(-)

diff --git a/board/lge/sniper/sniper.c b/board/lge/sniper/sniper.c
index 29a7045..0662449 100644
--- a/board/lge/sniper/sniper.c
+++ b/board/lge/sniper/sniper.c
@@ -94,6 +94,7 @@ int misc_init_r(void)
char reboot_mode[2] = { 0 };
unsigned char keys[3];
unsigned char data = 0;
+   int rc;
 
/* Power button reset init */
 
@@ -109,22 +110,14 @@ int misc_init_r(void)
 
/* Reboot mode */
 
-   omap_reboot_mode(reboot_mode, sizeof(reboot_mode));
+   rc = omap_reboot_mode(reboot_mode, sizeof(reboot_mode));
 
if (keys[0])
reboot_mode[0] = 'r';
else if (keys[1])
reboot_mode[0] = 'b';
 
-   if (reboot_mode[0] > 0 && isascii(reboot_mode[0])) {
-   if (!getenv("reboot-mode"))
-   setenv("reboot-mode", (char *)reboot_mode);
-
-   omap_reboot_mode_clear();
-   } else {
-   /* Reboot mode garbage may still be valid, so clear it. */
-   omap_reboot_mode_clear();
-
+   if (rc < 0 || reboot_mode[0] == 'o') {
/*
 * When not rebooting, valid power on reasons are either the
 * power button, charger plug or USB plug.
@@ -138,6 +131,13 @@ int misc_init_r(void)
twl4030_power_off();
}
 
+   if (reboot_mode[0] > 0 && isascii(reboot_mode[0])) {
+   if (!getenv("reboot-mode"))
+   setenv("reboot-mode", (char *)reboot_mode);
+   }
+
+   omap_reboot_mode_clear();
+
/* Serial number */
 
omap_die_id_serial();
@@ -160,6 +160,19 @@ void get_board_serial(struct tag_serialnr *serialnr)
omap_die_id_get_board_serial(serialnr);
 }
 
+void reset_misc(void)
+{
+   char reboot_mode[2] = { 0 };
+
+   /*
+* Valid resets must contain the reboot mode magic, but we must not
+* override it when set previously (e.g. reboot to bootloader).
+*/
+
+   omap_reboot_mode(reboot_mode, sizeof(reboot_mode));
+   omap_reboot_mode_store(reboot_mode);
+}
+
 int fb_set_reboot_flag(void)
 {
return omap_reboot_mode_store("b");
-- 
2.7.4

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

[U-Boot] [PATCH 6/7] kc1: Proper reboot mode and boot reason validation

[Paul Kocialkowski]

With the previous implementation, rebooting without registering a recognized
reboot mode would end up with U-Boot checking for a valid power-on reason, which
might result in the device turning off (e.g. with no USB cable attached and no
buttons pressed).

Since this approach is not viable (breaks reboot in most cases), the validity of
the reboot reason is checked (in turn, by checking that a warm reset happened,
as there is no magic) to detect a reboot and the 'o' char is recognized to
indicate that power-off is required. Still, that might be overridden by the
detection of usual power-on reasons, on purpose.

Signed-off-by: Paul Kocialkowski 
---
 board/amazon/kc1/kc1.c | 23 ++-
 1 file changed, 10 insertions(+), 13 deletions(-)

diff --git a/board/amazon/kc1/kc1.c b/board/amazon/kc1/kc1.c
index ca63af8..469a83e 100644
--- a/board/amazon/kc1/kc1.c
+++ b/board/amazon/kc1/kc1.c
@@ -88,10 +88,11 @@ int misc_init_r(void)
char reboot_mode[2] = { 0 };
u32 data = 0;
u32 value;
+   int rc;
 
/* Reboot mode */
 
-   omap_reboot_mode(reboot_mode, sizeof(reboot_mode));
+   rc = omap_reboot_mode(reboot_mode, sizeof(reboot_mode));
 
/* USB ID pin pull-up indicates factory (fastboot) cable detection. */
gpio_request(KC1_GPIO_USB_ID, "USB_ID");
@@ -101,18 +102,7 @@ int misc_init_r(void)
if (value)
reboot_mode[0] = 'b';
 
-   if (reboot_mode[0] > 0 && isascii(reboot_mode[0])) {
-   if (reboot_mode[0] == 'o')
-   twl6030_power_off();
-
-   if (!getenv("reboot-mode"))
-   setenv("reboot-mode", (char *)reboot_mode);
-
-   omap_reboot_mode_clear();
-   } else {
-   /* Reboot mode garbage may still be valid, so clear it. */
-   omap_reboot_mode_clear();
-
+   if (rc < 0 || reboot_mode[0] == 'o') {
/*
 * When not rebooting, valid power on reasons are either the
 * power button, charger plug or USB plug.
@@ -126,6 +116,13 @@ int misc_init_r(void)
twl6030_power_off();
}
 
+   if (reboot_mode[0] > 0 && isascii(reboot_mode[0])) {
+   if (!getenv("reboot-mode"))
+   setenv("reboot-mode", (char *)reboot_mode);
+   }
+
+   omap_reboot_mode_clear();
+
/* Serial number */
 
omap_die_id_serial();
-- 
2.7.4

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

[U-Boot] [PATCH 7/7] sniper: Change vendor name from lge to lg, matching devicetree vendor prefix

[Paul Kocialkowski]

This moves the sniper board from the lge to lg, in order to match the devicetree
vendor prefix already defined in the kernel.

Signed-off-by: Paul Kocialkowski 
---
 arch/arm/cpu/armv7/omap3/Kconfig |   2 +-
 board/lg/sniper/Kconfig  |  12 ++
 board/lg/sniper/MAINTAINERS  |   6 +
 board/lg/sniper/Makefile |   9 +
 board/lg/sniper/sniper.c | 191 
 board/lg/sniper/sniper.h | 365 +++
 board/lge/sniper/Kconfig |  12 --
 board/lge/sniper/MAINTAINERS |   6 -
 board/lge/sniper/Makefile|   9 -
 board/lge/sniper/sniper.c| 191 
 board/lge/sniper/sniper.h| 365 ---
 11 files changed, 584 insertions(+), 584 deletions(-)
 create mode 100644 board/lg/sniper/Kconfig
 create mode 100644 board/lg/sniper/MAINTAINERS
 create mode 100644 board/lg/sniper/Makefile
 create mode 100644 board/lg/sniper/sniper.c
 create mode 100644 board/lg/sniper/sniper.h
 delete mode 100644 board/lge/sniper/Kconfig
 delete mode 100644 board/lge/sniper/MAINTAINERS
 delete mode 100644 board/lge/sniper/Makefile
 delete mode 100644 board/lge/sniper/sniper.c
 delete mode 100644 board/lge/sniper/sniper.h

diff --git a/arch/arm/cpu/armv7/omap3/Kconfig b/arch/arm/cpu/armv7/omap3/Kconfig
index c6168e9..85d6436 100644
--- a/arch/arm/cpu/armv7/omap3/Kconfig
+++ b/arch/arm/cpu/armv7/omap3/Kconfig
@@ -141,6 +141,6 @@ source "board/nokia/rx51/Kconfig"
 source "board/technexion/tao3530/Kconfig"
 source "board/technexion/twister/Kconfig"
 source "board/quipos/cairo/Kconfig"
-source "board/lge/sniper/Kconfig"
+source "board/lg/sniper/Kconfig"
 
 endif
diff --git a/board/lg/sniper/Kconfig b/board/lg/sniper/Kconfig
new file mode 100644
index 000..3f18d21
--- /dev/null
+++ b/board/lg/sniper/Kconfig
@@ -0,0 +1,12 @@
+if TARGET_SNIPER
+
+config SYS_BOARD
+   default "sniper"
+
+config SYS_VENDOR
+   default "lg"
+
+config SYS_CONFIG_NAME
+   default "sniper"
+
+endif
diff --git a/board/lg/sniper/MAINTAINERS b/board/lg/sniper/MAINTAINERS
new file mode 100644
index 000..0e7baa5
--- /dev/null
+++ b/board/lg/sniper/MAINTAINERS
@@ -0,0 +1,6 @@
+SNIPER BOARD
+M: Paul Kocialkowski 
+S: Maintained
+F: board/lge/sniper/
+F: include/configs/sniper.h
+F: configs/sniper_defconfig
diff --git a/board/lg/sniper/Makefile b/board/lg/sniper/Makefile
new file mode 100644
index 000..f32a481
--- /dev/null
+++ b/board/lg/sniper/Makefile
@@ -0,0 +1,9 @@
+#
+# LG Optimus Black codename sniper board
+#
+# Copyright (C) 2015 Paul Kocialkowski 
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+obj-y := sniper.o
diff --git a/board/lg/sniper/sniper.c b/board/lg/sniper/sniper.c
new file mode 100644
index 000..0662449
--- /dev/null
+++ b/board/lg/sniper/sniper.c
@@ -0,0 +1,191 @@
+/*
+ * LG Optimus Black codename sniper board
+ *
+ * Copyright (C) 2015 Paul Kocialkowski 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "sniper.h"
+
+DECLARE_GLOBAL_DATA_PTR;
+
+const omap3_sysinfo sysinfo = {
+   .mtype = DDR_STACKED,
+   .board_string = "sniper",
+   .nand_string = "MMC"
+};
+
+static const struct ns16550_platdata serial_omap_platdata = {
+   .base = OMAP34XX_UART3,
+   .reg_shift = 2,
+   .clock = V_NS16550_CLK
+};
+
+U_BOOT_DEVICE(sniper_serial) = {
+   .name = "ns16550_serial",
+   .platdata = _omap_platdata
+};
+
+static struct musb_hdrc_config musb_config = {
+   .multipoint = 1,
+   .dyn_fifo = 1,
+   .num_eps = 16,
+   .ram_bits = 12
+};
+
+static struct omap_musb_board_data musb_board_data = {
+   .interface_type = MUSB_INTERFACE_ULPI,
+};
+
+static struct musb_hdrc_platform_data musb_platform_data = {
+   .mode = MUSB_PERIPHERAL,
+   .config = _config,
+   .power = 100,
+   .platform_ops = _ops,
+   .board_data = _board_data,
+};
+
+void set_muxconf_regs(void)
+{
+   MUX_SNIPER();
+}
+
+#ifdef CONFIG_SPL_BUILD
+void get_board_mem_timings(struct board_sdrc_timings *timings)
+{
+   timings->mcfg = HYNIX_V_MCFG_200(256 << 20);
+   timings->ctrla = HYNIX_V_ACTIMA_200;
+   timings->ctrlb = HYNIX_V_ACTIMB_200;
+   timings->rfr_ctrl = SDP_3430_SDRC_RFR_CTRL_200MHz;
+   timings->mr = MICRON_V_MR_165;
+}
+#endif
+
+int board_init(void)
+{
+   /* GPMC init */
+   gpmc_init();
+
+   /* MACH number */
+   gd->bd->bi_arch_number = 3000;
+
+   /* ATAGs location */
+   gd->bd->bi_boot_params = OMAP34XX_SDRC_CS0 + 0x100;
+
+   return 0;
+}
+
+int misc_init_r(void)
+{
+   unsigned char keypad_matrix[64] = { 0 };
+   char reboot_mode[2] = { 0 };
+   unsigned char keys[3];
+   unsigned char data = 0;
+   int rc;
+
+   /* 

[U-Boot] [PATCH 2/7] kc1: Include explicit serial baudrate on bootargs

[Paul Kocialkowski]

This makes the baudrate for the kernel command line explicit.

Signed-off-by: Paul Kocialkowski 
---
 include/configs/kc1.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/configs/kc1.h b/include/configs/kc1.h
index c2ac148..444a0f3 100644
--- a/include/configs/kc1.h
+++ b/include/configs/kc1.h
@@ -233,7 +233,7 @@
"boot_mmc_dev=0\0" \
"kernel_mmc_part=7\0" \
"recovery_mmc_part=5\0" \
-   "bootargs=mem=512M console=ttyO2\0"
+   "bootargs=console=ttyO2,115200 mem=512M\0"
 
 /*
  * ATAGs
-- 
2.7.4

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

[U-Boot] [PATCH 1/7] sniper: Include explicit serial baudrate on bootargs

[Paul Kocialkowski]

This makes the baudrate for the kernel command line explicit.

Signed-off-by: Paul Kocialkowski 
---
 include/configs/sniper.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/configs/sniper.h b/include/configs/sniper.h
index 171a8c4..cb25c0a 100644
--- a/include/configs/sniper.h
+++ b/include/configs/sniper.h
@@ -252,7 +252,7 @@
"recovery_mmc_part=4\0" \
"fdtfile=omap3-sniper.dtb\0" \
"bootfile=/boot/extlinux/extlinux.conf\0" \
-   "bootargs=console=ttyO2 vram=5M,0x9FA0 omapfb.vram=0:5M\0"
+   "bootargs=console=ttyO2,115200 vram=5M,0x9FA0 omapfb.vram=0:5M\0"
 
 /*
  * ATAGs
-- 
2.7.4

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

[U-Boot] [PATCH 4/7] kc1: Add some sysboot and devicetree-related environment variables

[Paul Kocialkowski]

This adds some environment variables for sysboot and devicetree.

Signed-off-by: Paul Kocialkowski 
---
 include/configs/kc1.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/configs/kc1.h b/include/configs/kc1.h
index 444a0f3..4803acb 100644
--- a/include/configs/kc1.h
+++ b/include/configs/kc1.h
@@ -233,6 +233,8 @@
"boot_mmc_dev=0\0" \
"kernel_mmc_part=7\0" \
"recovery_mmc_part=5\0" \
+   "fdtfile=omap4-kc1.dtb\0" \
+   "bootfile=/boot/extlinux/extlinux.conf\0" \
"bootargs=console=ttyO2,115200 mem=512M\0"
 
 /*
-- 
2.7.4

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

[U-Boot] [PATCH 3/7] kc1: Select libfdt to allow running devicetree-based kernels

[Paul Kocialkowski]

Selecting CONFIG_OF_LIBFDT allows running recent mainline kernels.

Signed-off-by: Paul Kocialkowski 
---
 configs/kc1_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/kc1_defconfig b/configs/kc1_defconfig
index 1e5c918..4de0b34 100644
--- a/configs/kc1_defconfig
+++ b/configs/kc1_defconfig
@@ -12,3 +12,4 @@ CONFIG_CMD_GPIO=y
 CONFIG_SYS_NS16550=y
 CONFIG_USB=y
 CONFIG_USB_MUSB_GADGET=y
+CONFIG_OF_LIBFDT=y
-- 
2.7.4

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

Re: [U-Boot] [PATCH 6/6] kc1: Add some sysboot and devicetree-related environment variables

[Paul Kocialkowski]

Le samedi 26 mars 2016 à 15:21 -0400, Tom Rini a écrit :
> On Sat, Mar 26, 2016 at 12:20:04PM +0100, Paul Kocialkowski wrote:
> 
> > 
> > This adds some environment variables for sysboot and devicetree.
> > 
> > Signed-off-by: Paul Kocialkowski 
> > ---
> >  include/configs/kc1.h | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/include/configs/kc1.h b/include/configs/kc1.h
> > index 1e6b037..e19fa12 100644
> > --- a/include/configs/kc1.h
> > +++ b/include/configs/kc1.h
> > @@ -233,6 +233,8 @@
> >     "boot_mmc_dev=0\0" \
> >     "kernel_mmc_part=7\0" \
> >     "recovery_mmc_part=5\0" \
> > +   "fdtfile=omap4-kc1.dtb\0" \
> > +   "bootfile=/boot/extlinux/extlinux.conf\0" \
> >     "bootargs=console=ttyO2,115200 mem=512M\0"
> Maybe time to look in to config_distro_bootcmd too?

Well, both sniper and kc1 are mobile devices that people will likely want to run
Android on, so that's what I'm targetting as default.

At this point, there is no dt-enabled kernel capable of running Android for
these devices, and mainline Linux is still a very early effort. Thus, I'm making
those variables available to make it easier to hack on mainline Linux, but I
don't want it to be the default (yet).

-- 
Paul Kocialkowski, low-level free software developer on embedded devices

Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/


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

Re: [U-Boot] [PATCH 1/6] sniper: Move PXE file address to a viable location

[Paul Kocialkowski]

Le samedi 26 mars 2016 à 14:59 -0400, Tom Rini a écrit :
> On Sat, Mar 26, 2016 at 12:19:59PM +0100, Paul Kocialkowski wrote:
> > 
> > This moves the PXE file address out of the bounds of the U-Boot image (which
> > is
> > loaded at 0x8010).
> > 
> > This also moves the ramdisk address to a better-looking aligned location.
> > 
> > Signed-off-by: Paul Kocialkowski 
> > ---
> >  include/configs/sniper.h | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/include/configs/sniper.h b/include/configs/sniper.h
> > index 171a8c4..2598af1 100644
> > --- a/include/configs/sniper.h
> > +++ b/include/configs/sniper.h
> > @@ -243,8 +243,8 @@
> >     "loadaddr=0x8200\0" \
> >     "fdt_addr_r=0x8800\0" \
> >     "fdtaddr=0x8800\0" \
> > -   "ramdisk_addr_r=0x8808\0" \
> > -   "pxefile_addr_r=0x8010\0" \
> > +   "ramdisk_addr_r=0x8400\0" \
> > +   "pxefile_addr_r=0x8600\0" \
> >     "scriptaddr=0x8000\0" \
> >     "bootm_size=0x1000\0" \
> >     "boot_mmc_dev=0\0" \
> I strongly discourage these locations.  Quoting myself from
> ti_armv7_common.h:
> /*
>  * We setup defaults based on constraints from the Linux kernel, which should
>  * also be safe elsewhere.  We have the default load at 32MB into DDR (for
>  * the kernel), FDT above 128MB (the maximum location for the end of the
>  * kernel), and the ramdisk 512KB above that (allowing for hopefully never
>  * seen large trees).  We say all of this must be within the first 256MB
>  * as that will normally be within the kernel lowmem and thus visible via
>  * bootm_size and we only run on platforms with 256MB or more of memory.
>  */

Thanks for the clarification, I think the addresses make sense as they are then.

> Now, have you actually run into a problem with overwriting U-Boot?

Actually, I had forgotten that U-Boot relocates. This address only caught my eye
as being equal to CONFIG_SYS_TEXT_BASE when going through the header, but I
didn't investigate enough.

There is indeed no run-time problem, thanks to relocation. I'll simply drop
these patches.

> Since U-Boot will run-time relocate, this shouldn't be a problem in
> practice?  The minor games we play with locations here are due to Falcon
> Mode where the BSS in question here is the one for SPL and we don't want
> those two to conflict.

-- 
Paul Kocialkowski, low-level free software developer on embedded devices

Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/


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

Re: [U-Boot] [PATCH v7 00/87] mtd: Add SPI-NOR core support

[Jagan Teki]

On 22 March 2016 at 20:25, Tom Rini  wrote:
> On Tue, Mar 22, 2016 at 01:19:25PM +0530, Jagan Teki wrote:
> [snip]
>> Issues:
>> ---
>> 1) undefined reference to `__aeabi_ldivmod'
>>
>> 59: config: Enable SPI-NOR framework
>>arm:  +   nyan-big
>> +drivers/mtd/spi-nor/built-in.o: In function `spi_nor_write':
>> +build/../drivers/mtd/spi-nor/spi-nor.c:585: undefined reference to
>> `__aeabi_ldivmod'
>> +arm-unknown-linux-gnueabi-ld.bfd: BFD (GNU Binutils) 2.24 assertion
>> fail /home/tony/buildall/src/binutils/bfd/elf32-arm.c:7696
>> +arm-unknown-linux-gnueabi-ld.bfd: error: required section
>> '.rel.plt' not found in the linker script
>> +arm-unknown-linux-gnueabi-ld.bfd: final link failed: Invalid operation
>> +make[1]: *** [u-boot] Error 1
>> +make: *** [sub-make] Error 2
>
> So this is a 64bit division problem somewhere along the lines that needs
> to be using one of the normal helper functions.
>
>> 2) Build issues on dra72_evm, dra74_evm
>
> What are they?

Build issue with spl, I guess this is because dm used for normal
u-boot and not used for spl.

Mugunthan, can you look in to this?

>
>> 3) SPL image too big
>>
>> 59: config: Enable SPI-NOR framework
>>arm:  +   axm
>> +arm-unknown-linux-gnueabi-ld.bfd: SPL image too big
>> +arm-unknown-linux-gnueabi-ld.bfd: SPL image BSS too big
>> +make[2]: *** [spl/u-boot-spl] Error 1
>> +make[1]: *** [spl/u-boot-spl] Error 2
>> +make: *** [sub-make] Error 2
>
> Sounds like you need to go back and take some care about how we do this
> in SPL.  Given the current gcc issue wrt merging strings together, we
> may need to be more careful about what files we compile and link for SPL
> in this case and perhaps need to split a file or two up.

With proper commenting code for SPL build on mtdcore and changes on
SPL size macros, build look fine.

+++ b/include/configs/taurus.h
-#define CONFIG_SPL_MAX_SIZE(31 * SZ_512)
+#define CONFIG_SPL_MAX_SIZE(36 * SZ_512)
-#define CONFIG_SPL_BSS_MAX_SIZE(3 * SZ_512)
+#define CONFIG_SPL_BSS_MAX_SIZE(4 * SZ_512)

>
>> 60: spi-nor: Use CONFIG_MTD_SPI_NOR
>>
>>
>> Image size:
>> ---
>> $> ./tools/buildman/buildman -b master -c 87 -sS
>
> Per commit is good for development but I really prefer to see the final
> totals, can you please report that too?  Thanks.

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

Re: [U-Boot] [PATCH 5/5] meson: odroid-c2: enable serial

[Carlo Caione]

On Sun, Mar 27, 2016 at 10:22 PM, Beniamino Galvani  wrote:
> Enable serial support in the ODROID-C2 configuration.
>
> Signed-off-by: Beniamino Galvani 
> ---
>  configs/odroid-c2_defconfig | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/configs/odroid-c2_defconfig b/configs/odroid-c2_defconfig
> index 66d9ab7..e0cd403 100644
> --- a/configs/odroid-c2_defconfig
> +++ b/configs/odroid-c2_defconfig
> @@ -4,6 +4,11 @@ CONFIG_MESON_GXBB=y
>  CONFIG_TARGET_ODROID_C2=y
>  CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-odroidc2"
>  CONFIG_OF_CONTROL=y
> +CONFIG_MESON_SERIAL=y
> +CONFIG_DEBUG_UART_MESON=y
> +GONFIG_DEBUG_UART_BASE=0xc81004c0

s/GONFIG/CONFIG/

> +CONFIG_DEBUG_UART_ANNOUNCE=y
> +CONFIG_DEBUG_UART_SKIP_INIT=y
>  # CONFIG_CMD_BDI is not set
>  # CONFIG_CMD_IMI is not set
>  # CONFIG_CMD_IMLS is not set
> --
> 2.4.3

-- 
Carlo Caione  |  +39.340.80.30.096  |  Endless
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC PATCH v1] armv8: LS2080A: Consolidate LS2080A and LS2085A

[york sun]

On 03/26/2016 03:39 AM, Prabhakar Kushwaha wrote:
> 
>> -Original Message-
>> From: York Sun [mailto:york@nxp.com]
>> Sent: Thursday, March 24, 2016 1:43 AM
>> To: U-Boot Mailing List 
>> Cc: Stuart Yoder ; Scott Wood ;
>> Huan Wang ; york sun ;
>> Prabhakar Kushwaha ; Ramneek Mehresh
>> ; Pratiyush Mohan Srivastava
>> ; Li Yang ; Hou
>> Zhiqiang ; Shaohui Xie
>> ; Aneesh Bansal ;
>> Jaiprakash Singh ; Mingkai Hu
>> ; Haiying Wang
>> ; Albert Aribaud
>> ; Minghuan Lian
>> ; Alexander Graf ; Lijun
>> Pan ; Scott Wood ;
>> Gong Qianyu ; Joe Hershberger
>> ; Prabhakar Kushwaha
>> ; Simon Glass ; Shengzhou
>> Liu ; Bin Meng ; Bhupesh
>> Sharma ; Qianyu Gong
>> ; Ashish Kumar ; Thomas
>> Chou ; Tang Yuantian
>> ; Alison Wang 
>> Subject: [RFC PATCH v1] armv8: LS2080A: Consolidate LS2080A and LS2085A
>>
>> LS2080A is the primary SoC, and LS2085A is a personality with AIOP
>> and DPAA DDR. The RDB and QDS boards support both personality. By
>> detecting the SVR at runtime, a single image per board can support
>> both SoCs. It gives users flexibility to swtich SoC without the need
>> to reprogram the board.
>>
>> Signed-off-by: York Sun 
>> CC: Prabhakar Kushwaha 
>>
>> ---
>>
>>  arch/arm/cpu/armv8/fsl-layerscape/Makefile |4 ---
>>  arch/arm/cpu/armv8/fsl-layerscape/cpu.c|9 ---
>>  .../arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c |6 -
>>  arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S   |2 +-
>>  arch/arm/cpu/armv8/fsl-layerscape/soc.c|   14 +-
>>  arch/arm/cpu/armv8/fsl-layerscape/spl.c|4 +--
>>  arch/arm/include/asm/arch-fsl-layerscape/config.h  |9 ++-
>>  arch/arm/include/asm/arch-fsl-layerscape/cpu.h |2 +-
>>  .../include/asm/arch-fsl-layerscape/fsl_serdes.h   |2 +-
>>  arch/arm/include/asm/arch-fsl-layerscape/soc.h |2 ++
>>  board/freescale/ls2080a/ddr.c  |   27 
>> +++-
>>  board/freescale/ls2080a/ls2080a.c  |2 +-
>>  board/freescale/ls2080aqds/MAINTAINERS |2 --
>>  board/freescale/ls2080aqds/ddr.c   |   27 
>> +++-
>>  board/freescale/ls2080aqds/ls2080aqds.c|2 +-
>>  board/freescale/ls2080ardb/MAINTAINERS |2 --
>>  board/freescale/ls2080ardb/ddr.c   |   27 
>> +++-
>>  board/freescale/ls2080ardb/ls2080ardb.c|2 +-
>>  configs/ls2085aqds_defconfig   |   19 --
>>  configs/ls2085aqds_nand_defconfig  |   14 --
>>  configs/ls2085ardb_defconfig   |   19 --
>>  configs/ls2085ardb_nand_defconfig  |   14 --
>>  drivers/net/ldpaa_eth/Makefile |1 -
>>  include/configs/ls2080a_common.h   |7 +
>>  include/configs/ls2080a_emu.h  |7 -
>>  include/configs/ls2080a_simu.h |7 -
>>  include/linux/usb/xhci-fsl.h   |2 +-
>>  27 files changed, 83 insertions(+), 152 deletions(-)
>>  delete mode 100644 configs/ls2085aqds_defconfig
>>  delete mode 100644 configs/ls2085aqds_nand_defconfig
>>  delete mode 100644 configs/ls2085ardb_defconfig
>>  delete mode 100644 configs/ls2085ardb_nand_defconfig
>>
>> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Makefile
>> b/arch/arm/cpu/armv8/fsl-layerscape/Makefile
>> index cce7405..5f86ef9 100644
>> --- a/arch/arm/cpu/armv8/fsl-layerscape/Makefile
>> +++ b/arch/arm/cpu/armv8/fsl-layerscape/Makefile
>> @@ -25,10 +25,6 @@ ifneq ($(CONFIG_LS2080A),)
>>  obj-$(CONFIG_SYS_HAS_SERDES) += ls2080a_serdes.o
>>  endif
>>
>> -ifneq ($(CONFIG_LS2085A),)
>> -obj-$(CONFIG_SYS_HAS_SERDES) += ls2080a_serdes.o
>> -endif
>> -
>>  ifneq ($(CONFIG_LS1043A),)
>>  obj-$(CONFIG_SYS_HAS_SERDES) += ls1043a_serdes.o
>>  endif
>> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
>> b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
>> index 4b9e209..d939900 100644
>> --- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
>> +++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
>> @@ -538,12 +538,12 @@ 

Re: [U-Boot] [PATCH 0/5] Basic support for Amlogic GXBaby and ODROID-C2

[Carlo Caione]

On Sun, Mar 27, 2016 at 10:22 PM, Beniamino Galvani  wrote:
> Hi,
>
> this series adds a very basic support for Amlogic S905 SoC (GXBaby)
> and for the ODROID-C2 board [1], and is based on u-boot sources
> available from the board vendor [2].
>
> Mainline kernel support is still in early stages [3] and the plan is
> to add more features to u-boot (mmc, ethernet, ...) as soon as they
> are available in the kernel; this submission only includes definition
> of platform, board and UART support.

Tested-by: Carlo Caione 

Thank you Beniamino for this. Could you please keep
linux-me...@googlegroups.com in CC for the next submissions?

Cheers,

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

[U-Boot] what is the purpose of the "init_f" function pointer in struct post_test?

[Robert P. J. Day]

  continuing my journey through u-boot POST code, and i can see the
"init_f" function pointer here:

struct post_test {
char *name;
char *cmd;
char *desc;
int flags;
int (*test) (int flags);
int (*init_f) (void); <-
void (*reloc) (void);
unsigned long testid;
};

but what *specific* issue was it introduced to solve?

  i can see over in common/board_f.c the sequence of init routines,
including this snippet:


#if defined(CONFIG_ARM) || defined(CONFIG_X86) ||
defined(CONFIG_NDS32) || \
defined(CONFIG_MICROBLAZE) || defined(CONFIG_AVR32)
dram_init,  /* configure available RAM banks */
#endif
#if defined(CONFIG_MIPS) || defined(CONFIG_PPC) ||
defined(CONFIG_M68K)
init_func_ram,
#endif
#ifdef CONFIG_POST
post_init_f,<-
#endif
INIT_FUNC_WATCHDOG_RESET
#if defined(CONFIG_SYS_DRAM_TEST)
testdram,
#endif /* CONFIG_SYS_DRAM_TEST */
INIT_FUNC_WATCHDOG_RESET

#ifdef CONFIG_POST
init_post,
#endif


so, first, it seems clear that those callbacks are meant to be invoked
immediately after configuring RAM but before testing it. and over in
post/post.c, we have:


int post_init_f(void)
{
int res = 0;
unsigned int i;

for (i = 0; i < post_list_size; i++) {
struct post_test *test = post_list + i;

if (test->init_f && test->init_f())
res = -1;
}

gd->post_init_f_time = post_time_ms(0);
if (!gd->post_init_f_time)
printf("%s: post_time_ms not implemented\n", __FILE__);

return res;
}


so if any tests have that pointer set, the corresponding routine will
be invoked.

  so i can see that the post_init_f() routine is useful for setting
the start time of these tests (if, in fact, there are any), but i'm
still unclear on the value of allowing POST tests to register a
routine to be invoked at *precisely* that point in the startup.

  what is so magical about allowing POST test routines at that exact
point?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday




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

[U-Boot] [PATCH] common: env: support sata device

[Peng Fan]

Introduce env support for sata device.
1. Implement write_env/read_env/env_relocate_spec/saveenv/sata_get_env_dev
2. If want to enable this feature, define CONFIG_ENV_IS_IN_SATA, and
   define CONFIG_SYS_SATA_ENV_DEV or implement your own sata_get_ev_dev.

Signed-off-by: Peng Fan 
Cc: Simon Glass 
Cc: Joe Hershberger 
Cc: Bin Meng 
Cc: Stefan Roese 
Cc: Heiko Schocher 
Cc: Stuart Longland 
Cc: Maxime Ripard 
Cc: Tom Rini 
---
 cmd/nvedit.c  |   3 +-
 common/Makefile   |   1 +
 common/env_sata.c | 135 ++
 3 files changed, 138 insertions(+), 1 deletion(-)
 create mode 100644 common/env_sata.c

diff --git a/cmd/nvedit.c b/cmd/nvedit.c
index 9cf884e..b67563b 100644
--- a/cmd/nvedit.c
+++ b/cmd/nvedit.c
@@ -49,12 +49,13 @@ DECLARE_GLOBAL_DATA_PTR;
!defined(CONFIG_ENV_IS_IN_NAND) && \
!defined(CONFIG_ENV_IS_IN_NVRAM)&& \
!defined(CONFIG_ENV_IS_IN_ONENAND)  && \
+   !defined(CONFIG_ENV_IS_IN_SATA) && \
!defined(CONFIG_ENV_IS_IN_SPI_FLASH)&& \
!defined(CONFIG_ENV_IS_IN_REMOTE)   && \
!defined(CONFIG_ENV_IS_IN_UBI)  && \
!defined(CONFIG_ENV_IS_NOWHERE)
 # error Define one of CONFIG_ENV_IS_IN_{EEPROM|FLASH|DATAFLASH|ONENAND|\
-SPI_FLASH|NVRAM|MMC|FAT|EXT4|REMOTE|UBI} or CONFIG_ENV_IS_NOWHERE
+SATA|SPI_FLASH|NVRAM|MMC|FAT|EXT4|REMOTE|UBI} or CONFIG_ENV_IS_NOWHERE
 #endif
 
 /*
diff --git a/common/Makefile b/common/Makefile
index 9a4b817..b23f312 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -50,6 +50,7 @@ obj-$(CONFIG_ENV_IS_IN_EXT4) += env_ext4.o
 obj-$(CONFIG_ENV_IS_IN_NAND) += env_nand.o
 obj-$(CONFIG_ENV_IS_IN_NVRAM) += env_nvram.o
 obj-$(CONFIG_ENV_IS_IN_ONENAND) += env_onenand.o
+obj-$(CONFIG_ENV_IS_IN_SATA) += env_sata.o
 obj-$(CONFIG_ENV_IS_IN_SPI_FLASH) += env_sf.o
 obj-$(CONFIG_ENV_IS_IN_REMOTE) += env_remote.o
 obj-$(CONFIG_ENV_IS_IN_UBI) += env_ubi.o
diff --git a/common/env_sata.c b/common/env_sata.c
new file mode 100644
index 000..bc49900
--- /dev/null
+++ b/common/env_sata.c
@@ -0,0 +1,135 @@
+/*
+ * (C) Copyright 2010-2016 Freescale Semiconductor, Inc.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+/* #define DEBUG */
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * TODO: Support CONFIG_ENV_SIZE_REDUND CONFIG_ENV_OFFSET_REDUND
+ */
+
+#if !defined(CONFIG_ENV_OFFSET) || !defined(CONFIG_ENV_SIZE)
+#error CONFIG_ENV_OFFSET or CONFIG_ENV_SIZE not defined
+#endif
+
+char *env_name_spec = "SATA";
+
+#ifdef ENV_IS_EMBEDDED
+env_t *env_ptr = (env_t *)([0]);
+#else /* ! ENV_IS_EMBEDDED */
+env_t *env_ptr;
+#endif /* ENV_IS_EMBEDDED */
+
+DECLARE_GLOBAL_DATA_PTR;
+
+__weak int sata_get_env_dev(void)
+{
+   return CONFIG_SYS_SATA_ENV_DEV;
+}
+
+int env_init(void)
+{
+   /* use default */
+   gd->env_addr = (ulong)_environment[0];
+   gd->env_valid = 1;
+
+   return 0;
+}
+
+#ifdef CONFIG_CMD_SAVEENV
+static inline int write_env(struct blk_desc *sata, unsigned long size,
+   unsigned long offset, const void *buffer)
+{
+   uint blk_start, blk_cnt, n;
+
+   blk_start = ALIGN(offset, sata->blksz) / sata->blksz;
+   blk_cnt   = ALIGN(size, sata->blksz) / sata->blksz;
+
+   n = sata->block_write(sata, blk_start, blk_cnt, (u_char *)buffer);
+
+   return (n == blk_cnt) ? 0 : -1;
+}
+
+int saveenv(void)
+{
+   ALLOC_CACHE_ALIGN_BUFFER(env_t, env_new, 1);
+   struct blk_desc *sata = NULL;
+   int env_sata, ret;
+
+   if (sata_initialize())
+   return 1;
+
+   env_sata = sata_get_env_dev();
+
+   sata = sata_get_dev(env_sata);
+   if (sata == NULL) {
+   printf("Unknown SATA(%d) device for environment!\n",
+  env_sata);
+   return 1;
+   }
+
+   ret = env_export(env_new);
+   if (ret)
+   return 1;
+
+   printf("Writing to SATA(%d)...", env_sata);
+   if (write_env(sata, CONFIG_ENV_SIZE, CONFIG_ENV_OFFSET, _new)) {
+   puts("failed\n");
+   return 1;
+   }
+
+   puts("done\n");
+   return 0;
+}
+#endif /* CONFIG_CMD_SAVEENV */
+
+static inline int read_env(struct blk_desc *sata, unsigned long size,
+  unsigned long offset, const void *buffer)
+{
+   uint blk_start, blk_cnt, n;
+
+   blk_start = ALIGN(offset, sata->blksz) / sata->blksz;
+   blk_cnt   = ALIGN(size, sata->blksz) / sata->blksz;
+
+   n = sata->block_read(sata, blk_start, blk_cnt, (uchar *)buffer);
+
+   return (n == blk_cnt) ? 0 : -1;
+}
+
+void env_relocate_spec(void)
+{
+#if !defined(ENV_IS_EMBEDDED)
+   ALLOC_CACHE_ALIGN_BUFFER(char, buf, CONFIG_ENV_SIZE);
+   struct blk_desc *sata 

Re: [U-Boot] [PATCH] armv8/fsl-layerscape: add IFC fixup for LS1043A with QSPI enabled

[Qianyu Gong]

Hi Prabhakar,

> -Original Message-
> From: Prabhakar Kushwaha
> Sent: Monday, March 28, 2016 4:52 PM
> To: Qianyu Gong ; Scott Wood ; u-
> b...@lists.denx.de; york sun 
> Cc: Mingkai Hu 
> Subject: RE: [PATCH] armv8/fsl-layerscape: add IFC fixup for LS1043A with QSPI
> enabled
> 
> 
> > -Original Message-
> > From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Qianyu
> > Gong
> > Sent: Friday, March 11, 2016 3:49 PM
> > To: Scott Wood ; u-boot@lists.denx.de; york sun
> > 
> > Cc: Mingkai Hu 
> > Subject: Re: [U-Boot] [PATCH] armv8/fsl-layerscape: add IFC fixup for
> > LS1043A with QSPI enabled
> >
> > Hi Scott,
> >
> > > -Original Message-
> > > From: Scott Wood [mailto:o...@buserror.net]
> > > Sent: Tuesday, February 23, 2016 8:12 AM
> > > To: Qianyu Gong ; u-boot@lists.denx.de; york
> > sun
> > > 
> > > Cc: Mingkai Hu 
> > > Subject: Re: [PATCH] armv8/fsl-layerscape: add IFC fixup for LS1043A
> > > with QSPI enabled
> > >
> > > On Mon, 2016-02-22 at 18:05 +0800, Gong Qianyu wrote:
> > > > QSPI and IFC are pin-multiplexed on LS1043A. So if QSPI is
> > > > enabled, IFC should be disabled.
> > > > But just disable IFC driver in LS1043A Linux is not enough because
> > > > mdio-mux will access IFC address space -- actually it accesses
> > > > FPGA which is connected to IFC CS3. So disable the whole IFC node
> > > > in Linux device tree.
> > > >
> > > > Signed-off-by: Gong Qianyu 
> > > >
> > > > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > > > b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > > > index 4e4861d..5bb3048 100644
> > > > --- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > > > +++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > > > @@ -204,4 +204,11 @@ void ft_cpu_setup(void *blob, bd_t *bd)
> > > > #ifdef
> > > > CONFIG_FSL_LSCH3
> > > > fdt_fixup_smmu(blob);
> > > >  #endif
> > > > +
> > > > +#ifdef CONFIG_LS1043A
> > > > +#ifdef CONFIG_FSL_QSPI
> > > > +   do_fixup_by_compat(blob, "fsl,ifc",
> > > > +  "status", "disabled", 8 + 1, 1); #endif 
> > > > #endif
> > > >  }
> > >
> > > This muxing is done at runtime, right?  It isn't a case of the board
> > > hardwiring one or the other?  In that case, it should be handled at
> > > runtime here as well.  At a minimum, allow the user to use hwconfig
> > > to choose which they want to be accessible.  Ideally there would be
> > > something in the device tree to list the reason(s) for a device
> > > being disabled, so the OS knows it can regard the device as being
> > > enabled if it
> > knows about and enables them all.
> > >
> > > -Scott
> >
> > Sorry for the late reply. We have been asking the silicon team for the
> > details of the pin muxing these days.
> > The conclusion is that all IFC interfaces(cs0/cs1/cs2) are disabled as
> > long as QSPI is enabled on LS1043AQDS board.
> > As I know, this muxing won't be handled in kernel. Since IFC is
> > disabled in U- Boot, IFC node would better be disabled in kernel as well.
> > Also in such cases, users have no other choice.
> >
> 
> This may not be always true.
> 
>  In LS1088A, IFC-FPGA is available during QSPI boot.
> 
> --prabhakar
> 

Yes, you're right. That's why I added "#ifdef CONFIG_LS1043A".
So I think it only affects ls1043a so far.

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

[U-Boot] [PATCH] common: env_sf: Add exclamation mark

[Peng Fan]

Add exclamation mark to the errmsg, when error and set_default_env.

Signed-off-by: Peng Fan 
Cc: Mario Schuknecht 
Cc: Vignesh R 
Cc: Jagan Teki 
Cc: Ravi Babu 
Cc: York Sun 
Cc: Tom Rini 
---
 common/env_sf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/common/env_sf.c b/common/env_sf.c
index 892e6cb..273098c 100644
--- a/common/env_sf.c
+++ b/common/env_sf.c
@@ -225,7 +225,7 @@ void env_relocate_spec(void)
ret = env_import((char *)ep, 0);
if (!ret) {
error("Cannot import environment: errno = %d\n", errno);
-   set_default_env("env_import failed");
+   set_default_env("!env_import failed");
}
 
 err_read:
-- 
2.6.2

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

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

[Heiko Schocher]

Hello Tom,

please pull from u-boot-i2c.git master

The following changes since commit f3c2cab87878d2ecd5bd796ee940dff814aa3255:

  Revert "pxa_lcd: make driver cache-aware" (2016-03-27 20:58:08 -0400)

are available in the git repository at:

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

for you to fetch changes up to 32b9b556f7ca198e62646662e3260f8ef352094f:

  omap24xx_i2c: Implement CONFIG_SYS_I2C_EEPROM_ADDR_OVERFLOW (2016-03-28 
09:23:28 +0200)


Guy Thouret (1):
  omap24xx_i2c: Implement CONFIG_SYS_I2C_EEPROM_ADDR_OVERFLOW

Peng Fan (1):
  dm: i2c: mxc_i2c: implement i2c_idle_bus

 arch/arm/include/asm/imx-common/mxc_i2c.h |  10 ++
 drivers/i2c/mxc_i2c.c | 101 
-

 drivers/i2c/omap24xx_i2c.c|  34 
++
 3 files changed, 136 insertions(+), 9 deletions(-)

pollux:u-boot hs [master] $ ./tools/buildman/buildman -b master -s
boards.cfg is up to date. Nothing to do.
Summary of 3 commits for 1118 boards (8 threads, 1 job per thread)
01: Revert "pxa_lcd: make driver cache-aware"
02: dm: i2c: mxc_i2c: implement i2c_idle_bus
03: omap24xx_i2c: Implement CONFIG_SYS_I2C_EEPROM_ADDR_OVERFLOW
(no errors to report)
pollux:u-boot hs [master] $

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

[U-Boot] [PATCH] drivers: net: ldpaa: Memset pools_params as "0" before use

[Prabhakar Kushwaha]

Memset pools_params as "0" to avoid garbage value in dpni_set_pools.

Signed-off-by: Prabhakar Kushwaha 
Reported-by: Jose Rivera 
---
 drivers/net/ldpaa_eth/ldpaa_eth.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ldpaa_eth/ldpaa_eth.c 
b/drivers/net/ldpaa_eth/ldpaa_eth.c
index bc7f8bb..75b2b6b 100644
--- a/drivers/net/ldpaa_eth/ldpaa_eth.c
+++ b/drivers/net/ldpaa_eth/ldpaa_eth.c
@@ -920,6 +920,7 @@ static int ldpaa_dpni_bind(struct ldpaa_eth_priv *priv)
struct dpni_tx_conf_cfg tx_conf_cfg;
int err = 0;
 
+   memset(_params, 0, sizeof(pools_params));
pools_params.num_dpbp = 1;
pools_params.pools[0].dpbp_id = (uint16_t)dflt_dpbp->dpbp_attr.id;
pools_params.pools[0].buffer_size = LDPAA_ETH_RX_BUFFER_SIZE;
-- 
1.9.1


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

Re: [U-Boot] [PATCH] armv8/fsl-layerscape: add IFC fixup for LS1043A with QSPI enabled

[Prabhakar Kushwaha]

> -Original Message-
> From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Qianyu
> Gong
> Sent: Friday, March 11, 2016 3:49 PM
> To: Scott Wood ; u-boot@lists.denx.de; york sun
> 
> Cc: Mingkai Hu 
> Subject: Re: [U-Boot] [PATCH] armv8/fsl-layerscape: add IFC fixup for
> LS1043A with QSPI enabled
> 
> Hi Scott,
> 
> > -Original Message-
> > From: Scott Wood [mailto:o...@buserror.net]
> > Sent: Tuesday, February 23, 2016 8:12 AM
> > To: Qianyu Gong ; u-boot@lists.denx.de; york
> sun
> > 
> > Cc: Mingkai Hu 
> > Subject: Re: [PATCH] armv8/fsl-layerscape: add IFC fixup for LS1043A
> > with QSPI enabled
> >
> > On Mon, 2016-02-22 at 18:05 +0800, Gong Qianyu wrote:
> > > QSPI and IFC are pin-multiplexed on LS1043A. So if QSPI is enabled,
> > > IFC should be disabled.
> > > But just disable IFC driver in LS1043A Linux is not enough because
> > > mdio-mux will access IFC address space -- actually it accesses FPGA
> > > which is connected to IFC CS3. So disable the whole IFC node in
> > > Linux device tree.
> > >
> > > Signed-off-by: Gong Qianyu 
> > >
> > > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > > b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > > index 4e4861d..5bb3048 100644
> > > --- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > > +++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > > @@ -204,4 +204,11 @@ void ft_cpu_setup(void *blob, bd_t *bd)  #ifdef
> > > CONFIG_FSL_LSCH3
> > >   fdt_fixup_smmu(blob);
> > >  #endif
> > > +
> > > +#ifdef CONFIG_LS1043A
> > > +#ifdef CONFIG_FSL_QSPI
> > > + do_fixup_by_compat(blob, "fsl,ifc",
> > > +"status", "disabled", 8 + 1, 1); #endif #endif
> > >  }
> >
> > This muxing is done at runtime, right?  It isn't a case of the board
> > hardwiring one or the other?  In that case, it should be handled at
> > runtime here as well.  At a minimum, allow the user to use hwconfig to
> > choose which they want to be accessible.  Ideally there would be
> > something in the device tree to list the reason(s) for a device being
> > disabled, so the OS knows it can regard the device as being enabled if it
> knows about and enables them all.
> >
> > -Scott
> 
> Sorry for the late reply. We have been asking the silicon team for the details
> of the pin muxing these days.
> The conclusion is that all IFC interfaces(cs0/cs1/cs2) are disabled as long as
> QSPI is enabled on LS1043AQDS board.
> As I know, this muxing won't be handled in kernel. Since IFC is disabled in U-
> Boot, IFC node would better be disabled in kernel as well.
> Also in such cases, users have no other choice.
> 

This may not be always true.  

 In LS1088A, IFC-FPGA is available during QSPI boot.

--prabhakar


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

Re: [U-Boot] [PATCH] armv8/fsl-layerscape: add IFC fixup for LS1043A with QSPI enabled

[Qianyu Gong]

Hi all,

Any comments about this patch? Thanks!

Regards,
Qianyu

> -Original Message-
> From: Gong Qianyu [mailto:qianyu.g...@nxp.com]
> Sent: Monday, February 22, 2016 6:05 PM
> To: u-boot@lists.denx.de; york sun ; o...@buserror.net
> Cc: Mingkai Hu ; Qianyu Gong 
> Subject: [PATCH] armv8/fsl-layerscape: add IFC fixup for LS1043A with QSPI
> enabled
> 
> QSPI and IFC are pin-multiplexed on LS1043A. So if QSPI is enabled,
> IFC should be disabled.
> But just disable IFC driver in LS1043A Linux is not enough because
> mdio-mux will access IFC address space -- actually it accesses FPGA
> which is connected to IFC CS3. So disable the whole IFC node in
> Linux device tree.
> 
> Signed-off-by: Gong Qianyu 
> 
> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c b/arch/arm/cpu/armv8/fsl-
> layerscape/fdt.c
> index 4e4861d..5bb3048 100644
> --- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> +++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> @@ -204,4 +204,11 @@ void ft_cpu_setup(void *blob, bd_t *bd)
>  #ifdef CONFIG_FSL_LSCH3
>   fdt_fixup_smmu(blob);
>  #endif
> +
> +#ifdef CONFIG_LS1043A
> +#ifdef CONFIG_FSL_QSPI
> + do_fixup_by_compat(blob, "fsl,ifc",
> +"status", "disabled", 8 + 1, 1);
> +#endif
> +#endif
>  }
> --
> 2.1.0.27.g96db324

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

Re: [U-Boot] [PATCH 4/6 v2] i2c: designware_i2c: Prepare for DM driver conversion

[Heiko Schocher]

Hello Stefan,

Am 23.03.2016 um 06:46 schrieb Stefan Roese:

This patch prepares the designware I2C driver for the DM conversion.
This is mainly done by removing struct i2c_adapter from the functions
that shall be used by the DM driver version as well.

Signed-off-by: Stefan Roese 
Cc: Simon Glass 
Reviewed-by: Bin Meng 
Cc: Marek Vasut 
Cc: Heiko Schocher 
---
v2:
- Added Reviewed-by from Bin

  drivers/i2c/designware_i2c.c | 173 ++-
  1 file changed, 90 insertions(+), 83 deletions(-)


I tried to apply this patch, but get the following error:

Wende an: i2c: designware_i2c: Prepare for DM driver conversion
fatal: sha1 information is lacking or useless (drivers/i2c/designware_i2c.c).
Dem Repository fehlen notwendige Blobs um auf einen 3-Wege-Merge zurückzufallen.
Kann nicht zu 3-Wege-Merge zurückfallen.
Anwendung des Patches fehlgeschlagen bei 0001 i2c: designware_i2c: Prepare for 
DM driver conversion

I tried the this patch on current mainline, with the following
patches applied:

http://patchwork.ozlabs.org/patch/601112/
http://patchwork.ozlabs.org/patch/601128/
http://patchwork.ozlabs.org/patch/601117/

Could you take a look?

Thanks!

bye,
Heiko


diff --git a/drivers/i2c/designware_i2c.c b/drivers/i2c/designware_i2c.c
index aac56a7..8dd1de9 100644
--- a/drivers/i2c/designware_i2c.c
+++ b/drivers/i2c/designware_i2c.c
@@ -10,30 +10,6 @@
  #include 
  #include "designware_i2c.h"

-static struct i2c_regs *i2c_get_base(struct i2c_adapter *adap)
-{
-   switch (adap->hwadapnr) {
-#if CONFIG_SYS_I2C_BUS_MAX >= 4
-   case 3:
-   return (struct i2c_regs *)CONFIG_SYS_I2C_BASE3;
-#endif
-#if CONFIG_SYS_I2C_BUS_MAX >= 3
-   case 2:
-   return (struct i2c_regs *)CONFIG_SYS_I2C_BASE2;
-#endif
-#if CONFIG_SYS_I2C_BUS_MAX >= 2
-   case 1:
-   return (struct i2c_regs *)CONFIG_SYS_I2C_BASE1;
-#endif
-   case 0:
-   return (struct i2c_regs *)CONFIG_SYS_I2C_BASE;
-   default:
-   printf("Wrong I2C-adapter number %d\n", adap->hwadapnr);
-   }
-
-   return NULL;
-}
-
  static void dw_i2c_enable(struct i2c_regs *i2c_base, bool enable)
  {
int timeout = 100;
@@ -60,10 +36,9 @@ static void dw_i2c_enable(struct i2c_regs *i2c_base, bool 
enable)
   *
   * Set the i2c speed.
   */
-static unsigned int dw_i2c_set_bus_speed(struct i2c_adapter *adap,
-unsigned int speed)
+static unsigned int __dw_i2c_set_bus_speed(struct i2c_regs *i2c_base,
+  unsigned int speed)
  {
-   struct i2c_regs *i2c_base = i2c_get_base(adap);
unsigned int cntl;
unsigned int hcnt, lcnt;
int i2c_spd;
@@ -112,47 +87,17 @@ static unsigned int dw_i2c_set_bus_speed(struct 
i2c_adapter *adap,
/* Enable back i2c now speed set */
dw_i2c_enable(i2c_base, true);

-   adap->speed = speed;
-
return 0;
  }

  /*
- * i2c_init - Init function
- * @speed: required i2c speed
- * @slaveaddr: slave address for the device
- *
- * Initialization function.
- */
-static void dw_i2c_init(struct i2c_adapter *adap, int speed,
-   int slaveaddr)
-{
-   struct i2c_regs *i2c_base = i2c_get_base(adap);
-
-   /* Disable i2c */
-   dw_i2c_enable(i2c_base, false);
-
-   writel((IC_CON_SD | IC_CON_SPD_FS | IC_CON_MM), _base->ic_con);
-   writel(IC_RX_TL, _base->ic_rx_tl);
-   writel(IC_TX_TL, _base->ic_tx_tl);
-   dw_i2c_set_bus_speed(adap, speed);
-   writel(IC_STOP_DET, _base->ic_intr_mask);
-   writel(slaveaddr, _base->ic_sar);
-
-   /* Enable i2c */
-   dw_i2c_enable(i2c_base, true);
-}
-
-/*
   * i2c_setaddress - Sets the target slave address
   * @i2c_addr: target i2c address
   *
   * Sets the target slave address.
   */
-static void i2c_setaddress(struct i2c_adapter *adap, unsigned int i2c_addr)
+static void i2c_setaddress(struct i2c_regs *i2c_base, unsigned int i2c_addr)
  {
-   struct i2c_regs *i2c_base = i2c_get_base(adap);
-
/* Disable i2c */
dw_i2c_enable(i2c_base, false);

@@ -167,10 +112,8 @@ static void i2c_setaddress(struct i2c_adapter *adap, 
unsigned int i2c_addr)
   *
   * Flushes the i2c RX FIFO
   */
-static void i2c_flush_rxfifo(struct i2c_adapter *adap)
+static void i2c_flush_rxfifo(struct i2c_regs *i2c_base)
  {
-   struct i2c_regs *i2c_base = i2c_get_base(adap);
-
while (readl(_base->ic_status) & IC_STATUS_RFNE)
readl(_base->ic_cmd_data);
  }
@@ -180,9 +123,8 @@ static void i2c_flush_rxfifo(struct i2c_adapter *adap)
   *
   * Waits for bus busy
   */
-static int i2c_wait_for_bb(struct i2c_adapter *adap)
+static int i2c_wait_for_bb(struct i2c_regs *i2c_base)
  {
-   struct i2c_regs *i2c_base = i2c_get_base(adap);
unsigned long start_time_bb = get_timer(0);

while 

Re: [U-Boot] Possible mistake in the csu_cslx_ind enum (ns_access.h)

[Huan Wang]

Hi, Vincent,

> On 03/24/2016 01:17 AM, Vincent wrote:
> > Hi,
> > I started to port my kernel to the secure world on a LS1021a board, so
> > I started to read the reference manual on the CSU component. In Table
> > 9.8, we can see that
> >
> > - Debug EPU is CSL47[24:16]
> > - DDDI is CSL48[24:16]
> > - Debug GDI is CSL48[8:0]
> >
> > but in ns_access.h the order doesn't seem to fit. If I understand
> correctly:
> >
> > - CSU_CSLX_EPU and CSU_CSLX_COP_DCSR should be exchanged
> > - CSU_CSLX_DDI and CSU_CSLX_GDI should be exchanged
> > - CSU_CSLX_USB3_PHY should be = 116, not 117
[Alison Wang] Yes, you are right. These modifications should be done for 
LS1021A.
Please send a patch to fix them.
> >
> >
> > I don't have any Errata yet, and I might be wrong, so I'd rather have
> > a confirmation.
> >
> > By the way, there are a lot of 'Reserved' entry that have a name (like
> > CSU_CSLX_GIC for example), am I lacking some information ?
[Alison Wang] I am not sure how the author gets the information. Anyway,
I will try to find some docs about it.

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

Re: [U-Boot] [PATCH 6/6] i2c: designware_i2c: Add support for PCI(e) based I2C cores (x86)

[Bin Meng]

Hi Stefan,

On Mon, Mar 21, 2016 at 10:04 PM, Stefan Roese  wrote:
> Hi Bin,
>
> On 21.03.2016 13:43, Bin Meng wrote:
>> On Mon, Mar 21, 2016 at 8:04 PM, Stefan Roese  wrote:
>>> Hi Bin,
>>>
>>> On 21.03.2016 10:03, Stefan Roese wrote:
>>>
>>> 
>>>
>> static int designware_i2c_probe_chip(struct udevice *bus, uint 
>> chip_addr,
>> @@ -476,14 +519,45 @@ static int designware_i2c_probe(struct udevice 
>> *bus)
>> {
>>struct dw_i2c *priv = dev_get_priv(bus);
>>
>> +#ifdef CONFIG_X86
>> +   /* Save base address from PCI BAR */
>> +   priv->regs = (struct i2c_regs *)
>> +   dm_pci_map_bar(bus, PCI_BASE_ADDRESS_0, PCI_REGION_MEM);
>> +   /* Use BayTrail specific timing values */
>> +   priv->scl_sda_cfg = _config;
>> +#else
>
> How about:
>
>if (device_is_on_pci_bus(dev)) {
>do the PCI I2C stuff here;
>}

 I've tried this but it generated compilation errors on socfpga, as the
 dm_pci_xxx functions are not available there. So it definitely needs
 some #ifdef here. I could go with your suggestion and use
 #if CONFIG_DM_PCI as well.

> See driver/net/designware.c for example.
>
>>/* Save base address from device-tree */
>>priv->regs = (struct i2c_regs *)dev_get_addr(bus);
>> +#endif
>>>
>>> Enabling this code for x86 via if (device_is_on_pci_bus(dev)) results
>>> in this ugly compilation warning:
>>>
>>> drivers/i2c/designware_i2c.c: In function ‘designware_i2c_probe’:
>>> drivers/i2c/designware_i2c.c:530:16: warning: cast to pointer from integer 
>>> of different size [-Wint-to-pointer-cast]
>>> priv->regs = (struct i2c_regs *)dev_get_addr(bus);
>>>  ^
>>>
>>> This is because x86 defines fdt_addr_t / phys_addr_t as 64bit. So
>>> I'm wondering, how dev_get_addr() should get used on x86. Has it
>>> been used anywhere here at all? Should we perhaps go back to
>>> a 32bit phy_addr representation again? So that dev_get_addr()
>>> matches the (void *) size again?
>>>
>>
>> dev_get_addr() is being used on x86 drivers. See
>> ns16550_serial_ofdata_to_platdata() for example. There is no build
>> warning for the ns16550 driver.
>
> Looking closer, the warning does not occur here, since the registers
> are stored in a u32 variable "base". And assigning a 64bit value to a
> 32bit variable as in "plat->base = addr" in ns16550.c does not cause any
> warnings.
>
> Here in the I2C driver though, the base address is stored as a pointer
> (pointer size is 32 bit for x86). And this triggers this warning, even
> though its effectively the same assignment. I could cast to u32 but this
> would cause problems on 64 bit architectures using this driver (in the
> future). So I came up with this approach:

Thanks for digging out these.

>
> /*
>  * On x86, "fdt_addr_t" is 64bit but "void *" only 32bit. So assigning the
>  * register base directly in dev_get_addr() results in this compilation 
> warning:
>  * warning: cast to pointer from integer of different size
>  *
>  * Using this macro POINTER_SIZE_CAST, allows us to cast the result of
>  * dev_get_addr() into a 32bit value before casting it to the pointer
>  * (struct i2c_regs *).
>  */
> #ifdef CONFIG_X86
> #define POINTER_SIZE_CAST   u32
> #endif
>
> ...
>
> static int designware_i2c_probe(struct udevice *bus)
> {
> struct dw_i2c *priv = dev_get_priv(bus);
>
> if (device_is_on_pci_bus(bus)) {
> #ifdef CONFIG_DM_PCI
> /* Save base address from PCI BAR */
> priv->regs = (struct i2c_regs *)
> dm_pci_map_bar(bus, PCI_BASE_ADDRESS_0, 
> PCI_REGION_MEM);
> #ifdef CONFIG_X86
> /* Use BayTrail specific timing values */
> priv->scl_sda_cfg = _config;
> #endif
> #endif
> } else {
> /* Save base address from device-tree */
> priv->regs = (struct i2c_regs 
> *)(POINTER_SIZE_CAST)dev_get_addr(bus);
> }
>
> But I'm not 100% happy with this approach.
>

Yes, it's annoying.

> So what are the alternatives:
>
> a) Don't compile the  dev_get_addr() part for x86 similar to what I've
>done in v1
>
> b) This approach with POINTER_SIZE_CAST
>
> Any preferences of other ideas?
>
> Side note: My general feeling is, that dev_get_addr() should be able to
> get cast into a pointer on all platforms. This is how it is used in many
> drivers, btw. Since this is not possible on x86, we might have a problem
> here. Simon might have some ideas on this as well...
>

I would like to hear Simon's input. Simon?

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