Re: [U-Boot] [PATCH v3 2/5] usb: xhci: fsl: code cleanup for device tree fixup for fsl usb controllers

[Sriram Dash]

>From: Marek Vasut [mailto:ma...@denx.de]
>On 06/10/2016 05:47 AM, Sriram Dash wrote:
>>> -Original Message-
>>> From: Marek Vasut [mailto:ma...@denx.de]
>>> Sent: Thursday, June 09, 2016 7:01 PM
>>> To: Sriram Dash ; u-boot@lists.denx.de
>>> Cc: york sun ; albert.u.b...@aribaud.net; Rajesh
>>> Bhagat 
>>> Subject: Re: [PATCH v3 2/5] usb: xhci: fsl: code cleanup for device
>>> tree fixup for fsl usb controllers
>
>Would you please fix your mailer to omit this useless header ?
>
>[...]
>

Will take care next time onwards.

 diff --git a/include/fsl_usb.h b/include/fsl_usb.h index
 187e384..882a5f5 100644
 --- a/include/fsl_usb.h
 +++ b/include/fsl_usb.h
 @@ -85,6 +85,12 @@ struct ccsr_usb_phy {  #define
 CONFIG_SYS_FSL_USB_SQUELCH_PROG_MASK 0x07  #endif

 +/* USB Controllers */
 +#define FSL_USB2_MPH  "fsl-usb2-mph"
 +#define FSL_USB2_DR   "fsl-usb2-dr"
 +#define USB2_CI   "usb2-ci"
>
>What is this "usb2-ci" string ? Is this some DT property or DT compatible 
>property or
>just some random string?
>

Currently, for chipidea usb 2 controller, there is no generic 
DT compatible property. Some names used are "qcom,ci-hdrc",
"chipidea,usb2","fsl-usb2-dr","fsl-usb2-mph ". This string "usb2-ci"
is not used currently for DT property.

 +#define SNPS_DWC3 "snps,dwc3"
>>>
>>> Is this needed as a global macro or can it be local to fsl-dt-fixup.c ?
>>>
>>
>> Currently, the macro are only being used for dt fixup for fsl usb.
>> However, in the near future, they might be needed for some other
>> purpose, for example, board specific settings.
>
>If they will be used for other purpose, then they can be moved. They are local 
>now,
>so keep them local.
>

Ok. I will move the global macro to fsl-dt-fixup.c.

>> So, i think i will stick with the global macro.
>>
  /* USB Erratum Checking code */
  #ifdef CONFIG_PPC
  static inline bool has_dual_phy(void)

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

Re: [U-Boot] [PATCH v3 2/5] usb: xhci: fsl: code cleanup for device tree fixup for fsl usb controllers

[Marek Vasut]

On 06/10/2016 07:20 AM, Sriram Dash wrote:
>> From: Marek Vasut [mailto:ma...@denx.de]
>> On 06/10/2016 05:47 AM, Sriram Dash wrote:
 -Original Message-
 From: Marek Vasut [mailto:ma...@denx.de]
 Sent: Thursday, June 09, 2016 7:01 PM
 To: Sriram Dash ; u-boot@lists.denx.de
 Cc: york sun ; albert.u.b...@aribaud.net; Rajesh
 Bhagat 
 Subject: Re: [PATCH v3 2/5] usb: xhci: fsl: code cleanup for device
 tree fixup for fsl usb controllers
>>
>> Would you please fix your mailer to omit this useless header ?
>>
>> [...]
>>
> 
> Will take care next time onwards.
> 
> diff --git a/include/fsl_usb.h b/include/fsl_usb.h index
> 187e384..882a5f5 100644
> --- a/include/fsl_usb.h
> +++ b/include/fsl_usb.h
> @@ -85,6 +85,12 @@ struct ccsr_usb_phy {  #define
> CONFIG_SYS_FSL_USB_SQUELCH_PROG_MASK 0x07  #endif
>
> +/* USB Controllers */
> +#define FSL_USB2_MPH "fsl-usb2-mph"
> +#define FSL_USB2_DR  "fsl-usb2-dr"
> +#define USB2_CI  "usb2-ci"
>>
>> What is this "usb2-ci" string ? Is this some DT property or DT compatible 
>> property or
>> just some random string?
>>
> 
> Currently, for chipidea usb 2 controller, there is no generic 
> DT compatible property.

Linux kernel documentation says there is "chipidea,usb2":

https://www.kernel.org/doc/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt

> Some names used are "qcom,ci-hdrc",
> "chipidea,usb2","fsl-usb2-dr","fsl-usb2-mph ". This string "usb2-ci"
> is not used currently for DT property.

The "chipidea,usb2" is generic one, all the others are either heritage
from the past or more precise specifiers of the IP block. Do not invent
yet another new compatible property in this case, it makes zero sense.

> +#define SNPS_DWC3"snps,dwc3"

 Is this needed as a global macro or can it be local to fsl-dt-fixup.c ?

>>>
>>> Currently, the macro are only being used for dt fixup for fsl usb.
>>> However, in the near future, they might be needed for some other
>>> purpose, for example, board specific settings.
>>
>> If they will be used for other purpose, then they can be moved. They are 
>> local now,
>> so keep them local.
>>
> 
> Ok. I will move the global macro to fsl-dt-fixup.c.
> 
>>> So, i think i will stick with the global macro.
>>>
>  /* USB Erratum Checking code */
>  #ifdef CONFIG_PPC
>  static inline bool has_dual_phy(void)
>


 --
 Best regards,
 Marek Vasut
>>
>>
>> --
>> Best regards,
>> Marek Vasut


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

[U-Boot] [PATCH] board: am437x-hs: spl: Select right dtb from fit

[Lokesh Vutla]

Select a right dtb from FIT for am437x-hs platform.

Reported-by: Madan Srinivas 
Signed-off-by: Lokesh Vutla 
---
 board/ti/am43xx/board.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/ti/am43xx/board.c b/board/ti/am43xx/board.c
index bde5ac7..f005762 100644
--- a/board/ti/am43xx/board.c
+++ b/board/ti/am43xx/board.c
@@ -850,7 +850,7 @@ int board_eth_init(bd_t *bis)
 #ifdef CONFIG_SPL_LOAD_FIT
 int board_fit_config_name_match(const char *name)
 {
-   if (board_is_gpevm() && !strcmp(name, "am437x-gp-evm"))
+   if (board_is_evm() && !strcmp(name, "am437x-gp-evm"))
return 0;
else if (board_is_sk() && !strcmp(name, "am437x-sk-evm"))
return 0;
-- 
2.8.2

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

Re: [U-Boot] [PATCH v2] verified-boot: Minimal support for booting U-Boot proper from SPL

[Sumit Garg]

Hi Teddy,

> -Original Message-
> From: Andreas Dannenberg [mailto:dannenb...@ti.com]
> Sent: Friday, June 10, 2016 8:15 AM
> To: Teddy Reed 
> Cc: u-boot@lists.denx.de; s...@chromium.org; Sumit Garg
> 
> Subject: Re: [PATCH v2] verified-boot: Minimal support for booting U-Boot
> proper from SPL
> 
> On Thu, Jun 09, 2016 at 07:18:44PM -0700, Teddy Reed wrote:
> > This allows a board to configure verified boot within the SPL using a
> > FIT or FIT with external data. It also allows the SPL to perform
> > signature verification without needing relocation.
> >
> > The board configuration will need to add the following feature defines:
> > CONFIG_SPL_CRYPTO_SUPPORT
> > CONFIG_SPL_HASH_SUPPORT
> > CONFIG_SPL_SHA256
> >
> > In this example, SHA256 is the only selected hashing algorithm.
> >
> > And the following booleans:
> > CONFIG_SPL=y
> > CONFIG_SPL_DM=y
> > CONFIG_SPL_LOAD_FIT=y
> > CONFIG_SPL_FIT=y
> > CONFIG_SPL_OF_CONTROL=y
> > CONFIG_SPL_OF_LIBFDT=y
> > CONFIG_SPL_FIT_SIGNATURE=y
> >
> > Signed-off-by: Teddy Reed 
> > Acked-by: Simon Glass 
> 
> Applies cleanly now and builds without issues.
> 
> Acked-by: Andreas Dannenberg 

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

Re: [U-Boot] [PATCH v2] sunxi: Support booting from SPI flash

[Siarhei Siamashka]

On Thu, 9 Jun 2016 19:42:55 -0700
Simon Glass  wrote:

> Hi,
> 
> On 9 June 2016 at 18:33, Siarhei Siamashka  
> wrote:
> > Hi Simon,
> >
> > On Thu, 9 Jun 2016 17:36:10 -0700
> > Simon Glass  wrote:
> >  
> >> Hi,
> >>
> >> On 7 June 2016 at 05:28, Siarhei Siamashka  
> >> wrote:  
> >> > Allwinner devices support SPI flash as one of the possible
> >> > bootable media type. The SPI flash chip needs to be connected
> >> > to SPI0 pins (port C) to make this work. More information is
> >> > available at:
> >> >
> >> > https://linux-sunxi.org/Bootable_SPI_flash
> >> >
> >> > This patch adds the initial support for booting from SPI flash.
> >> > The existing SPI frameworks are not used in order to reduce the
> >> > SPL code size. Right now the SPL size grows by ~370 bytes when
> >> > CONFIG_SPL_SPI_SUNXI option is enabled.
> >> >
> >> > While there are no popular Allwinner devices with SPI flash at
> >> > the moment, testing can be done using a SPI flash module (it
> >> > can be bought for ~2$ on ebay) and jumper wires with the boards,
> >> > which expose relevant pins on the expansion header. The SPI flash
> >> > chips themselves are very cheap (some prices are even listed as
> >> > low as 4 cents) and should not cost much if somebody decides to
> >> > design a development board with an SPI flash chip soldered on
> >> > the PCB.
> >> >
> >> > Another nice feature of the SPI flash is that it can be safely
> >> > accessed in a device-independent way (since we know that the
> >> > boot ROM is already probing these pins during the boot time).
> >> > And if, for example, Olimex boards opted to use SPI flash instead
> >> > of EEPROM, then they would have been able to have U-Boot installed
> >> > in the SPI flash now and boot the rest of the system from the SATA
> >> > hard drive. Hopefully we may see new interesting Allwinner based
> >> > development boards in the future, now that the software support
> >> > for the SPI flash is in a better shape :-)
> >> >
> >> > Testing can be done by enabling the CONFIG_SPL_SPI_SUNXI option
> >> > in a board defconfig, then building U-Boot and finally flashing
> >> > the resulting u-boot-sunxi-with-spl.bin binary over USB OTG with
> >> > a help of the sunxi-fel tool:
> >> >
> >> >sunxi-fel spiflash-write 0 u-boot-sunxi-with-spl.bin
> >> >
> >> > The device needs to be switched into FEL (USB recovery) mode first.
> >> > The most suitable boards for testing are Orange Pi PC and Pine64.
> >> > Because these boards are cheap, have no built-in NAND/eMMC and
> >> > expose SPI0 pins on the Raspberry Pi compatible expansion header.
> >> > The A13-OLinuXino-Micro board also can be used.
> >> >
> >> > Signed-off-by: Siarhei Siamashka 
> >> > ---
> >> >
> >> > Changes in v2:
> >> >  - Add Kconfig option (CONFIG_SPL_SPI_SUNXI) and move the SPI flash
> >> >support code into a separate source file
> >> >  - Use CONFIG_SYS_SPI_U_BOOT_OFFS instead of the hardcoded constant
> >> >  - Deinitialize the SPI controller and undo pin muxing after the job
> >> >is done
> >> >  - Size reduction of the SPI transfer function
> >> >  - Add delay after each SPI transfer to ensure that the chip select
> >> >deassert timing requirements (tSHSL) are always satisfied
> >> >  - More comments in the code
> >> >
> >> >
> >> >  arch/arm/include/asm/arch-sunxi/gpio.h |   3 +
> >> >  arch/arm/mach-sunxi/board.c|   5 +
> >> >  common/spl/spl.c   |   4 +-
> >> >  drivers/mtd/spi/Kconfig|  12 ++
> >> >  drivers/mtd/spi/Makefile   |   1 +
> >> >  drivers/mtd/spi/sunxi_spi_spl.c| 283 
> >> > +
> >> >  include/configs/sunxi-common.h |   5 +
> >> >  7 files changed, 311 insertions(+), 2 deletions(-)
> >> >  create mode 100644 drivers/mtd/spi/sunxi_spi_spl.c  
> >>
> >> Shouldn't this be a normal SPI driver? Then you could put this in
> >> common/spl/spl_spi.c.  
> >
> > This source file contains both a sunxi SPI controller support and a
> > basic SPI flash read functionality glued together for size reduction
> > purposes.
> >
> > We are interested in implementing the "spl_spi_load_image()" function,
> > because this is what gets called when handling the BOOT_DEVICE_SPI
> > case.
> >
> > The "drivers/mtd/spi" directory contains the "spi_spl_load.c" file,
> > which implements this particular function with the help of the generic
> > SPI flash support code from "spi_flash.c" and the generic SPI bus
> > support provided by the code from the "drivers/spi" directory.
> >
> > What I'm doing in this patch is an implementation of a size reduced
> > sunxi-specific replacement for "spi_spl_load.c". But in U-Boot proper
> > (where the code size is not a problem anymore) we will need a real
> > sunxi SPI driver.  
> 
> OK I see, fair enough.
> 
> Do you know how much space this saves? 

Re: [U-Boot] [PATCH v4 1/2] powerpc/mpc85xx: SECURE BOOT- Enable chain of trust in SPL

[Sumit Garg]

Hi Andreas, Simon,

> -Original Message-
> From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass
> Sent: Friday, June 10, 2016 6:05 AM
> To: Andreas Dannenberg 
> Cc: Sumit Garg ; U-Boot Mailing List  b...@lists.denx.de>; york sun ; Ruchika Gupta
> ; Prabhakar Kushwaha
> ; Teddy Reed V ;
> Aneesh Bansal 
> Subject: Re: [PATCH v4 1/2] powerpc/mpc85xx: SECURE BOOT- Enable chain of
> trust in SPL
> 
> Hi,
> 
> On 9 June 2016 at 09:05, Andreas Dannenberg  wrote:
> > Hi Sumit,
> >
> > On Thu, Jun 02, 2016 at 08:16:37AM -0400, Sumit Garg wrote:
> >> As part of Chain of Trust for Secure boot, the SPL U-Boot will
> >> validate the next level U-boot image. Add a new function
> >> spl_validate_uboot to perform the validation.
> >
> > I noticed your patch series just now and I certainly don't want to
> > derail what you are trying to do here but I wanted to see what you
> > think about something that's pretty much related.
> >
> > In order to be more flexible in how we go from SPL to U-Boot (we have
> > a need to inject ROM-API calls for decryption in addition to
> > authentication) I've been experimenting with a method that basically
> > injects a generic post-process function call into
> > spl_load_simple_fit() that the platform-specific layer can
> > provide/override. This function will basically get invoked on the
> > U-Boot firmware itself as well as for the selected DTB after it gets
> > loaded, allowing to do things like custom authentication and/or
> > decryption through plugging in for example our ROM API calls. But this
> > should also be a starting point for someone to plug in the U-Boot RSA
> > libraries directly in a way that doesn't require using CONFIG_SPL_DM (for
> memory-constrained devices).

It’s a good idea to plug ROM API calls for decryption and authentication in
U-boot firmware. I think your main concern is DM framework in SPL for
memory constrained devices. But for our platforms memory constraint is not a
barrier in this case, so for time being we could use CONFIG_SPL_DM. So if you
come up with framework to add U-Boot RSA libraries without using DM in SPL,
we could enable it on our platforms too.
> >
> > So mostly I wanted to see if this is something that could be useful
> > for you as well, and any comments/concerns you may have on that.
> >
> > Thanks and Regards,
> >
> > --
> > Andreas Dannenberg
> > Texas Instruments Inc
> >
> >
> >> Enable hardware crypto operations in SPL using SEC block.
> >> In case of Secure Boot, PAMU is not bypassed. For allowing SEC block
> >> access to CPC configured as SRAM, configure PAMU.
> >>
> >> Reviewed-by: Ruchika Gupta 
> >> Signed-off-by: Aneesh Bansal 
> >> Signed-off-by: Sumit Garg 
> >> ---
> >> Changes in v2:
> >> Patches rebased
> >>
> >> Changes in v3:
> >> Patches rebased
> >>
> >> Changes in v4:
> >> Generic changes in lib, drivers, common Makefiles removed from this
> >> patchset. Rebased this patchset on top of patch [1], so this patchset
> >> is dependent on patch [1].
> >>
> >> [1]https://patchwork.ozlabs.org/patch/627664/
> >>
> >>  arch/powerpc/cpu/mpc8xxx/fsl_pamu.c |  8 +
> >>  arch/powerpc/cpu/mpc8xxx/pamu_table.c   |  8 +
> >>  arch/powerpc/include/asm/fsl_secure_boot.h  | 28 
> >> board/freescale/common/fsl_chain_of_trust.c | 50
> +
> >>  drivers/crypto/fsl/jr.c | 16 +
> >>  drivers/mtd/nand/fsl_ifc_spl.c  | 24 ++
> >>  include/fsl_validate.h  |  1 +
> >>  7 files changed, 135 insertions(+)
> >>
> >> diff --git a/arch/powerpc/cpu/mpc8xxx/fsl_pamu.c
> >> b/arch/powerpc/cpu/mpc8xxx/fsl_pamu.c
> >> index 9421f1e..ede8e66 100644
> >> --- a/arch/powerpc/cpu/mpc8xxx/fsl_pamu.c
> >> +++ b/arch/powerpc/cpu/mpc8xxx/fsl_pamu.c
> >> @@ -239,15 +239,23 @@ int pamu_init(void)
> >>   spaact_size = sizeof(struct paace) * NUM_SPAACT_ENTRIES;
> >>
> >>   /* Allocate space for Primary PAACT Table */
> >> +#if (defined(CONFIG_SPL_BUILD) &&
> defined(CONFIG_SPL_PPAACT_ADDR))
> >> + ppaact = (void *)CONFIG_SPL_PPAACT_ADDR; #else
> >>   ppaact = memalign(PAMU_TABLE_ALIGNMENT, ppaact_size);
> >>   if (!ppaact)
> >>   return -1;
> >> +#endif
> >>   memset(ppaact, 0, ppaact_size);
> >>
> >>   /* Allocate space for Secondary PAACT Table */
> >> +#if (defined(CONFIG_SPL_BUILD) &&
> defined(CONFIG_SPL_SPAACT_ADDR))
> >> + sec = (void *)CONFIG_SPL_SPAACT_ADDR; #else
> >>   sec = memalign(PAMU_TABLE_ALIGNMENT, spaact_size);
> >>   if (!sec)
> >>   return -1;
> >> +#endif
> >>   memset(sec, 0, spaact_size);
> >>
> >>   ppaact_phys = virt_to_phys((void *)ppaact); diff --git
> >> 

Re: [U-Boot] [PATCH v2 0/3] Add USB EHCI support for ls1012aqds

[Marek Vasut]

On 06/10/2016 05:41 AM, Rajesh Bhagat wrote:
> 
> 
>> -Original Message-
>> From: Marek Vasut [mailto:ma...@denx.de]
>> Sent: Thursday, June 09, 2016 7:12 PM
>> To: Rajesh Bhagat ; u-boot@lists.denx.de
>> Cc: Sriram Dash ; albert.u.b...@aribaud.net;
>> prabha...@freescale.com; york sun ; Rajat Srivastava
>> 
>> Subject: Re: [PATCH v2 0/3] Add USB EHCI support for ls1012aqds
>>
>> On 06/09/2016 08:57 AM, Rajesh Bhagat wrote:
>>> Adds USB EHCI support for ls1012qds by adding the support for NXP ULPI
>>> PHY and adding the support it configuration files. Also enables, USB2
>>> IP in ns access defines.
>>>
>>> Rajesh Bhagat (3):
>>>   drivers: usb: fsl: add USB ULPI init code
>>>   config: ls1012aqds: Add USB EHCI support for ls1012aqds
>>>   armv8: ls1012a: Added CSU assignment for USB2
>>>
>>>  .../include/asm/arch-fsl-layerscape/immap_lsch2.h  |1 +
>>>  .../include/asm/arch-fsl-layerscape/ns_access.h|2 +
>>>  drivers/usb/host/ehci-fsl.c|   21 
>>> 
>>>  include/configs/ls1012aqds.h   |5 
>>>  include/usb/ehci-ci.h  |2 +-
>>>  5 files changed, 30 insertions(+), 1 deletions(-)
>>>
> 
> Hello Marek, 
> 
>> I wanted to apply these on u-boot-usb/master , but patch 2 fails to apply. 
>> Please
>> rebase and repose.
>>
> 
> Can you apply below patch for Layerscape USB macro cleanup for various Soc to 
> apply above patch:
> 
> https://patchwork.ozlabs.org/patch/631595/

This has to go through soc tree, so I will have to wait for it to be
applied. Let me know when it's in, then I can pick these patches.

> [root@phoenix u-boot-usb]$ pw-am.sh 631595
> 2016-06-10 09:02:02 URL:https://patchwork.ozlabs.org/patch/631595/mbox/ 
> [6138] -> "pw-am-631595.patch" [1]
> Applying: include: usb: Rename USB controller base address mapping
> [root@phoenix u-boot-usb]$ pw-am.sh 632644
> 2016-06-10 09:02:18 URL:https://patchwork.ozlabs.org/patch/632644/mbox/ 
> [2104] -> "pw-am-632644.patch" [1]
> Applying: drivers: usb: fsl: add USB ULPI init code
> [root@phoenix u-boot-usb]$ pw-am.sh 632646
> 2016-06-10 09:02:28 URL:https://patchwork.ozlabs.org/patch/632646/mbox/ 
> [2819] -> "pw-am-632646.patch" [1]
> Applying: config: ls1012aqds: Add USB EHCI support for ls1012aqds
> [root@phoenix u-boot-usb]$ pw-am.sh 632645
> 2016-06-10 09:02:36 URL:https://patchwork.ozlabs.org/patch/632645/mbox/ 
> [1501] -> "pw-am-632645.patch" [1]
> Applying: armv8: ls1012a: Added CSU assignment for USB2
> 
> OR 
> 
> Please share if there is a need to rebase them. 
> 
> Best Regards,
> Rajesh Bhagat
> 
>> --
>> Best regards,
>> Marek Vasut


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

Re: [U-Boot] [PATCH v3 2/5] usb: xhci: fsl: code cleanup for device tree fixup for fsl usb controllers

[Marek Vasut]

On 06/10/2016 05:47 AM, Sriram Dash wrote:
>> -Original Message-
>> From: Marek Vasut [mailto:ma...@denx.de]
>> Sent: Thursday, June 09, 2016 7:01 PM
>> To: Sriram Dash ; u-boot@lists.denx.de
>> Cc: york sun ; albert.u.b...@aribaud.net; Rajesh Bhagat
>> 
>> Subject: Re: [PATCH v3 2/5] usb: xhci: fsl: code cleanup for device tree 
>> fixup for fsl
>> usb controllers

Would you please fix your mailer to omit this useless header ?

[...]

>>> diff --git a/include/fsl_usb.h b/include/fsl_usb.h index
>>> 187e384..882a5f5 100644
>>> --- a/include/fsl_usb.h
>>> +++ b/include/fsl_usb.h
>>> @@ -85,6 +85,12 @@ struct ccsr_usb_phy {  #define
>>> CONFIG_SYS_FSL_USB_SQUELCH_PROG_MASK 0x07  #endif
>>>
>>> +/* USB Controllers */
>>> +#define FSL_USB2_MPH   "fsl-usb2-mph"
>>> +#define FSL_USB2_DR"fsl-usb2-dr"
>>> +#define USB2_CI"usb2-ci"

What is this "usb2-ci" string ? Is this some DT property or DT
compatible property or just some random string?

>>> +#define SNPS_DWC3  "snps,dwc3"
>>
>> Is this needed as a global macro or can it be local to fsl-dt-fixup.c ?
>>
> 
> Currently, the macro are only being used for dt fixup for fsl usb.
> However, in the near future, they might be needed for some other purpose,
> for example, board specific settings.

If they will be used for other purpose, then they can be moved. They are
local now, so keep them local.

> So, i think i will stick with the global macro.
> 
>>>  /* USB Erratum Checking code */
>>>  #ifdef CONFIG_PPC
>>>  static inline bool has_dual_phy(void)
>>>
>>
>>
>> --
>> Best regards,
>> Marek Vasut


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

Re: [U-Boot] [PATCH 0/5] ARM: AM57xx: Enable fit support

[Lokesh Vutla]

On Thursday 09 June 2016 11:22 PM, Tom Rini wrote:
> On Thu, Jun 09, 2016 at 10:56:09PM +0530, Lokesh Vutla wrote:
> 
>> Hi Tom,
>>
>> On 5/9/2016 11:43 AM, Lokesh Vutla wrote:
>>> This series adds support for AM572x-IDK and FIT support on all AM57xx 
>>> platforms.
>>>
>>> Testing:
>>> AM57xx-evm: http://pastebin.ubuntu.com/16315497/
>>> AM572x-IDK: http://pastebin.ubuntu.com/16315517/
>>
>> If you are ok with this series can you merge it?
> 
> Hmm, oops.  I had marked this as superseded by accident.  I'm about to
> push the changes for moving BOOTDELAY into Kconfig and that means a
> re-sync on defconfigs, can you please pick up my reviewed-by from before
> and re-post once that's live?  Sorry & thanks!

Just posted the updated series.

Thanks and regards,
Lokesh

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

[U-Boot] [PATCH v2 5/5] ti_omap5_common: Add right dtb file for AM572x-IDK

[Lokesh Vutla]

Add proper dtb file name for AM572x-IDK in env.

Reviewed-by: Tom Rini 
Signed-off-by: Lokesh Vutla 
---
 include/configs/ti_omap5_common.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/configs/ti_omap5_common.h 
b/include/configs/ti_omap5_common.h
index 5c5a12d..2e4c8e9 100644
--- a/include/configs/ti_omap5_common.h
+++ b/include/configs/ti_omap5_common.h
@@ -104,6 +104,8 @@
"setenv fdtfile dra72-evm.dtb; fi;" \
"if test $board_name = beagle_x15; then " \
"setenv fdtfile am57xx-beagle-x15.dtb; fi;" \
+   "if test $board_name = am572x_idk; then " \
+   "setenv fdtfile am572x-idk.dtb; fi;" \
"if test $board_name = am57xx_evm; then " \
"setenv fdtfile am57xx-beagle-x15.dtb; fi;" \
"if test $fdtfile = undefined; then " \
-- 
2.8.2

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

[U-Boot] [PATCH v2 2/5] board: am57xx: fit: add support for selecting dtb dynamically

[Lokesh Vutla]

FIT allows for a multiple dtb in a single image. SPL needs away to
detect the right dtb to be used. Adding support for the same for am57xx
platforms.

Reviewed-by: Tom Rini 
Signed-off-by: Lokesh Vutla 
---
 board/ti/am57xx/board.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/board/ti/am57xx/board.c b/board/ti/am57xx/board.c
index ccf97b2..ac5b794 100644
--- a/board/ti/am57xx/board.c
+++ b/board/ti/am57xx/board.c
@@ -736,3 +736,15 @@ int ft_board_setup(void *blob, bd_t *bd)
return 0;
 }
 #endif
+
+#ifdef CONFIG_SPL_LOAD_FIT
+int board_fit_config_name_match(const char *name)
+{
+   if (board_is_x15() && !strcmp(name, "am57xx-beagle-x15"))
+   return 0;
+   else if (board_is_am572x_evm() && !strcmp(name, "am57xx-beagle-x15"))
+   return 0;
+   else
+   return -1;
+}
+#endif
-- 
2.8.2

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

[U-Boot] [PATCH v2 4/5] ARM: dts: AM572x-IDK Initial Support

[Lokesh Vutla]

From: Schuyler Patton 

Add initial DTS support for AM572-IDK evm.

Reviewed-by: Tom Rini 
Signed-off-by: Schuyler Patton 
Signed-off-by: Nishanth Menon 
Signed-off-by: Lokesh Vutla 
---
 arch/arm/dts/Makefile   |   3 +-
 arch/arm/dts/am572x-idk.dts |  89 +++
 arch/arm/dts/am57xx-idk-common.dtsi | 302 
 board/ti/am57xx/board.c |   2 +
 configs/am57xx_evm_defconfig|   2 +-
 5 files changed, 396 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/dts/am572x-idk.dts
 create mode 100644 arch/arm/dts/am57xx-idk-common.dtsi

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 65ca1f9..6fc49c7 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -114,7 +114,8 @@ dtb-$(CONFIG_ARCH_SOCFPGA) +=   
\
socfpga_cyclone5_vining_fpga.dtb
 
 dtb-$(CONFIG_TARGET_DRA7XX_EVM) += dra72-evm.dtb dra7-evm.dtb
-dtb-$(CONFIG_TARGET_AM57XX_EVM) += am57xx-beagle-x15.dtb
+dtb-$(CONFIG_TARGET_AM57XX_EVM) += am57xx-beagle-x15.dtb \
+   am572x-idk.dtb
 dtb-$(CONFIG_TARGET_STV0991) += stv0991.dtb
 
 dtb-$(CONFIG_LS102XA) += ls1021a-qds-duart.dtb \
diff --git a/arch/arm/dts/am572x-idk.dts b/arch/arm/dts/am572x-idk.dts
new file mode 100644
index 000..b340551
--- /dev/null
+++ b/arch/arm/dts/am572x-idk.dts
@@ -0,0 +1,89 @@
+/*
+ * Copyright (C) 2015-2016 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/dts-v1/;
+
+#include "dra74x.dtsi"
+#include 
+#include 
+#include "am57xx-idk-common.dtsi"
+
+/ {
+   model = "TI AM5728 IDK";
+   compatible = "ti,am5728-idk", "ti,am5728", "ti,dra742", "ti,dra74",
+"ti,dra7";
+
+   chosen {
+   stdout-path = 
+   };
+
+   memory {
+   device_type = "memory";
+   reg = <0x0 0x8000 0x0 0x8000>;
+   };
+
+   extcon_usb2: extcon_usb2 {
+   compatible = "linux,extcon-usb-gpio";
+   id-gpio = < 16 GPIO_ACTIVE_HIGH>;
+   };
+
+   status-leds {
+   compatible = "gpio-leds";
+   cpu0-led {
+   label = "status0:red:cpu0";
+   gpios = < 0 GPIO_ACTIVE_HIGH>;
+   default-state = "off";
+   linux,default-trigger = "cpu0";
+   };
+
+   usr0-led {
+   label = "status0:green:usr";
+   gpios = < 11 GPIO_ACTIVE_HIGH>;
+   default-state = "off";
+   };
+
+   heartbeat-led {
+   label = "status0:blue:heartbeat";
+   gpios = < 12 GPIO_ACTIVE_HIGH>;
+   default-state = "off";
+   linux,default-trigger = "heartbeat";
+   };
+
+   cpu1-led {
+   label = "status1:red:cpu1";
+   gpios = < 10 GPIO_ACTIVE_HIGH>;
+   default-state = "off";
+   linux,default-trigger = "cpu1";
+   };
+
+   usr1-led {
+   label = "status1:green:usr";
+   gpios = < 23 GPIO_ACTIVE_HIGH>;
+   default-state = "off";
+   };
+
+   mmc0-led {
+   label = "status1:blue:mmc0";
+   gpios = < 22 GPIO_ACTIVE_HIGH>;
+   default-state = "off";
+   linux,default-trigger = "mmc0";
+   };
+   };
+};
+
+_dwc3_2 {
+   extcon = <_usb2>;
+};
+
+ {
+   status = "okay";
+   vmmc-supply = <_3d>;
+   vmmc_aux-supply = <_reg>;
+   bus-width = <4>;
+   cd-gpios = < 27 GPIO_ACTIVE_LOW>; /* gpio 219 */
+};
diff --git a/arch/arm/dts/am57xx-idk-common.dtsi 
b/arch/arm/dts/am57xx-idk-common.dtsi
new file mode 100644
index 000..2805b68
--- /dev/null
+++ b/arch/arm/dts/am57xx-idk-common.dtsi
@@ -0,0 +1,302 @@
+/*
+ * Copyright (C) 2015-2016 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/ {
+   aliases {
+   rtc0 = _rtc;
+   rtc1 = 
+   };
+
+   vmain: fixedregulator-vmain {
+   compatible = "regulator-fixed";
+   regulator-name = "VMAIN";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+
+   v3_3d: 

[U-Boot] [PATCH v2 3/5] ARM: AM57xx: Enable FIT

[Lokesh Vutla]

Enable FIT support for AM57xx platforms

Reviewed-by: Tom Rini 
Signed-off-by: Lokesh Vutla 
---
 configs/am57xx_evm_defconfig | 4 
 1 file changed, 4 insertions(+)

diff --git a/configs/am57xx_evm_defconfig b/configs/am57xx_evm_defconfig
index 4d8fbcd..249a287 100644
--- a/configs/am57xx_evm_defconfig
+++ b/configs/am57xx_evm_defconfig
@@ -36,3 +36,7 @@ CONFIG_SYS_NS16550=y
 CONFIG_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
+CONFIG_FIT=y
+CONFIG_SPL_OF_LIBFDT=y
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_OF_LIST="am57xx-beagle-x15"
-- 
2.8.2

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

[U-Boot] [PATCH v2 1/5] board: am57xx: Rename TARGET_BEAGLE_X15 as TARGET_AM57XX_EVM

[Lokesh Vutla]

board/am57xx supports all boards based on am57xx. Rename the taget
as TARGET_AM57XX_EVM.

Fixes: 74cc8b097d9af ("board: ti: beagle_x15: Rename to indicate support for TI 
am57xx evms")
Reviewed-by: Tom Rini 
Signed-off-by: Lokesh Vutla 
---
 arch/arm/cpu/armv7/omap5/Kconfig  | 4 ++--
 arch/arm/dts/Makefile | 2 +-
 board/ti/am57xx/Kconfig   | 2 +-
 configs/am57xx_evm_defconfig  | 2 +-
 configs/am57xx_evm_nodt_defconfig | 2 +-
 configs/am57xx_hs_evm_defconfig   | 2 +-
 6 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/arm/cpu/armv7/omap5/Kconfig b/arch/arm/cpu/armv7/omap5/Kconfig
index 026bf24..4fb5ef9 100644
--- a/arch/arm/cpu/armv7/omap5/Kconfig
+++ b/arch/arm/cpu/armv7/omap5/Kconfig
@@ -14,8 +14,8 @@ config TARGET_DRA7XX_EVM
bool "TI DRA7XX"
select TI_I2C_BOARD_DETECT
 
-config TARGET_BEAGLE_X15
-   bool "BeagleBoard X15"
+config TARGET_AM57XX_EVM
+   bool "AM57XX"
select TI_I2C_BOARD_DETECT
 
 endchoice
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index a827613..65ca1f9 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -114,7 +114,7 @@ dtb-$(CONFIG_ARCH_SOCFPGA) +=   
\
socfpga_cyclone5_vining_fpga.dtb
 
 dtb-$(CONFIG_TARGET_DRA7XX_EVM) += dra72-evm.dtb dra7-evm.dtb
-dtb-$(CONFIG_TARGET_BEAGLE_X15) += am57xx-beagle-x15.dtb
+dtb-$(CONFIG_TARGET_AM57XX_EVM) += am57xx-beagle-x15.dtb
 dtb-$(CONFIG_TARGET_STV0991) += stv0991.dtb
 
 dtb-$(CONFIG_LS102XA) += ls1021a-qds-duart.dtb \
diff --git a/board/ti/am57xx/Kconfig b/board/ti/am57xx/Kconfig
index 87654f9..cead0f4 100644
--- a/board/ti/am57xx/Kconfig
+++ b/board/ti/am57xx/Kconfig
@@ -1,4 +1,4 @@
-if TARGET_BEAGLE_X15
+if TARGET_AM57XX_EVM
 
 config SYS_BOARD
default "am57xx"
diff --git a/configs/am57xx_evm_defconfig b/configs/am57xx_evm_defconfig
index b63ff89..4d8fbcd 100644
--- a/configs/am57xx_evm_defconfig
+++ b/configs/am57xx_evm_defconfig
@@ -1,6 +1,6 @@
 CONFIG_ARM=y
 CONFIG_OMAP54XX=y
-CONFIG_TARGET_BEAGLE_X15=y
+CONFIG_TARGET_AM57XX_EVM=y
 CONFIG_DM_SERIAL=y
 CONFIG_DM_GPIO=y
 CONFIG_SPL_STACK_R_ADDR=0x8200
diff --git a/configs/am57xx_evm_nodt_defconfig 
b/configs/am57xx_evm_nodt_defconfig
index 1cf82d2..4c5a0de 100644
--- a/configs/am57xx_evm_nodt_defconfig
+++ b/configs/am57xx_evm_nodt_defconfig
@@ -1,6 +1,6 @@
 CONFIG_ARM=y
 CONFIG_OMAP54XX=y
-CONFIG_TARGET_BEAGLE_X15=y
+CONFIG_TARGET_AM57XX_EVM=y
 CONFIG_SPL=y
 CONFIG_HUSH_PARSER=y
 CONFIG_CMD_BOOTZ=y
diff --git a/configs/am57xx_hs_evm_defconfig b/configs/am57xx_hs_evm_defconfig
index aa459a1..ce377cb 100644
--- a/configs/am57xx_hs_evm_defconfig
+++ b/configs/am57xx_hs_evm_defconfig
@@ -1,7 +1,7 @@
 CONFIG_ARM=y
 CONFIG_OMAP54XX=y
 CONFIG_TI_SECURE_DEVICE=y
-CONFIG_TARGET_BEAGLE_X15=y
+CONFIG_TARGET_AM57XX_EVM=y
 CONFIG_DM_SERIAL=y
 CONFIG_DM_GPIO=y
 CONFIG_SPL_STACK_R_ADDR=0x8200
-- 
2.8.2

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

[U-Boot] [PATCH v2 0/5] ARM: AM57xx: Enable fit support

[Lokesh Vutla]

This series adds support for AM572x-IDK and FIT support on all AM57xx
platforms.

Lokesh Vutla (4):
  board: am57xx: Rename TARGET_BEAGLE_X15 as TARGET_AM57XX_EVM
  board: am57xx: fit: add support for selecting dtb dynamically
  ARM: AM57xx: Enable FIT
  ti_omap5_common: Add right dtb file for AM572x-IDK

Schuyler Patton (1):
  ARM: dts: AM572x-IDK Initial Support

 arch/arm/cpu/armv7/omap5/Kconfig|   4 +-
 arch/arm/dts/Makefile   |   3 +-
 arch/arm/dts/am572x-idk.dts |  89 +++
 arch/arm/dts/am57xx-idk-common.dtsi | 302 
 board/ti/am57xx/Kconfig |   2 +-
 board/ti/am57xx/board.c |  14 ++
 configs/am57xx_evm_defconfig|   6 +-
 configs/am57xx_evm_nodt_defconfig   |   2 +-
 configs/am57xx_hs_evm_defconfig |   2 +-
 include/configs/ti_omap5_common.h   |   2 +
 10 files changed, 419 insertions(+), 7 deletions(-)
 create mode 100644 arch/arm/dts/am572x-idk.dts
 create mode 100644 arch/arm/dts/am57xx-idk-common.dtsi

-- 
2.8.2

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

Re: [U-Boot] U-Boot on Minnowboard Max

[Bin Meng]

Hi,

+Simon, ML and Stefan.

On Wed, Jun 8, 2016 at 11:58 PM, vinoth eswaran  wrote:
> Hello Bin,
>
>   Sorry that I don't know how not to reply without top-posting. I
> don't know which settings to change, google didn't help me in this
> case.
>

It's a posting style. See https://en.wikipedia.org/wiki/Posting_style.
We use bottom-posting.

> I have tested your patch on my target and found out that now mounting
> root file system by sd card is fine. Thanks a lot :)
>

Great!

> Now I am seeing another issue , the USB3.0 port (bottom) is not
> working. I am sure that both ports are working fine with UEFI
> Firmware. I tested by connecting a mouse to the USB port , in the
> USB2.0 port (upper) it is working fine but in the USB3.0 port the
> mouse is not getting detected. I am not sure why it is happening. I
> looked into the kernel logs but I didn't get any error/debug messages.
> Can you please check this on your board also.
>

Do you mean xHCI is not working under U-Boot? xHCI is not enabled in
U-Boot yet. IIRC, U-Boot's xHCI driver does not support Intel
controller yet.

> Do you have any documents regarding the u-boot to kernel handover,
> what all informations does u-boot  handover to Linux Kernel. It would
> be great help.

This is documented in kernel doc:
https://www.kernel.org/doc/Documentation/x86/boot.txt

> I thought that the MMC driver issue is on Linux Kernel side, but it
> was some offset and probing issue in the u-boot.
>

Umm, it's hard to tell. Starting from BayTrail, Intel's SoC is more
and more like an ARM SoC, with many GPIOs and pinmux that needs to be
configured. Linux kernel does provide driver for the BayTrail pinctrl,
but so far no mainline driver is making use of it. The generic x86
kernel image is not aware of any board-specific I/O configuration so
some peripherals (like in this case the SD controller) won't work out
of the box. The mainline Linux kernel expects the underlying
bootloader to do the I/O configuration, IOW, kernerl is not bootloader
agnostic yet on x86. It relies on whatever bootloader (UEFI BIOS,
coreboot, U-Boot) to do such kind of work.

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

Re: [U-Boot] [PATCH v2 8/9] cmd: fdt: add fdt overlay application subcommand

[Stefan Agner]

On 2016-05-27 02:13, Maxime Ripard wrote:
> The device tree overlays are a good way to deal with user-modifyable
> boards or boards with some kind of an expansion mechanism where we can
> easily plug new board in (like the BBB or the raspberry pi).
> 
> However, so far, the usual mechanism to deal with it was to have in Linux
> some driver detecting the expansion boards plugged in and then request
> these overlays using the firmware interface.
> 
> That works in most cases, but in some cases, you might want to have the
> overlays applied before the userspace comes in. Either because the new
> board requires some kind of an early initialization, or because your root
> filesystem is accessed through that expansion board.
> 
> The easiest solution in such a case is to simply have the component before
> Linux applying that overlay, removing all these drawbacks.
> 
> Signed-off-by: Maxime Ripard 
> ---
>  cmd/fdt.c | 20 
>  1 file changed, 20 insertions(+)

Reviewed-by: Stefan Agner 

> 
> diff --git a/cmd/fdt.c b/cmd/fdt.c
> index 0f5923e75a41..6cbc9e525d6c 100644
> --- a/cmd/fdt.c
> +++ b/cmd/fdt.c
> @@ -639,6 +639,25 @@ static int do_fdt(cmd_tbl_t *cmdtp, int flag, int
> argc, char * const argv[])
>  #endif
>  
>   }
> + /* apply an overlay */
> + else if (strncmp(argv[1], "ap", 2) == 0) {
> + unsigned long addr;
> + struct fdt_header *blob;
> +
> + if (argc != 3)
> + return CMD_RET_USAGE;
> +
> + if (!working_fdt)
> + return CMD_RET_FAILURE;
> +
> + addr = simple_strtoul(argv[2], NULL, 16);
> + blob = map_sysmem(addr, 0);
> + if (!fdt_valid())
> + return CMD_RET_FAILURE;
> +
> + if (fdt_overlay_apply(working_fdt, blob))
> + return CMD_RET_FAILURE;
> + }
>   /* resize the fdt */
>   else if (strncmp(argv[1], "re", 2) == 0) {
>   fdt_shrink_to_minimum(working_fdt);
> @@ -1025,6 +1044,7 @@ static int fdt_print(const char *pathp, char
> *prop, int depth)
>  #ifdef CONFIG_SYS_LONGHELP
>  static char fdt_help_text[] =
>   "addr [-c]   []   - Set the [control] fdt location to 
> \n"
> + "fdt apply - Apply overlay to the DT\n"
>  #ifdef CONFIG_OF_BOARD_SETUP
>   "fdt boardsetup  - Do board-specific set up\n"
>  #endif
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 2/5] usb: xhci: fsl: code cleanup for device tree fixup for fsl usb controllers

[Sriram Dash]

>-Original Message-
>From: Marek Vasut [mailto:ma...@denx.de]
>Sent: Thursday, June 09, 2016 7:01 PM
>To: Sriram Dash ; u-boot@lists.denx.de
>Cc: york sun ; albert.u.b...@aribaud.net; Rajesh Bhagat
>
>Subject: Re: [PATCH v3 2/5] usb: xhci: fsl: code cleanup for device tree fixup 
>for fsl
>usb controllers
>
>On 06/09/2016 02:21 PM, Sriram Dash wrote:
>> Performs code cleanup for device tree fixup for fsl usb controllers by
>> making functions to handle these similar errata checking code.
>>
>> Signed-off-by: Rajesh Bhagat 
>> Signed-off-by: Sriram Dash 
>> ---
>>
>> Changes in v3:
>>   - Inverted the condition for has_erratum for better readability
>>   - If fdt_fixup_usb_erratum fails, return ENOSPC and exit the fixup
>>   - Added logic for handling the condition with different controllers
>>  with different erratas
>>  - first check if the errata is applicable for the SoC
>>  - then check if it is applicable for the controller
>>  - if both are successful, then fix dt.
>>
>> Changes in v2:
>>   - Added patch description
>>   - Removed the MACRO and use fdt_fixup_erratum function instead
>>
>>  drivers/usb/common/fsl-dt-fixup.c | 88 
>> ++-
>>  include/fsl_usb.h |  6 +++
>>  2 files changed, 56 insertions(+), 38 deletions(-)
>>
>> diff --git a/drivers/usb/common/fsl-dt-fixup.c
>> b/drivers/usb/common/fsl-dt-fixup.c
>> index 6f31932..9cbd9d2 100644
>> --- a/drivers/usb/common/fsl-dt-fixup.c
>> +++ b/drivers/usb/common/fsl-dt-fixup.c
>> @@ -20,9 +20,9 @@
>>  #endif
>>
>>  static const char * const compat_usb_fsl[] = {
>> -"fsl-usb2-mph",
>> -"fsl-usb2-dr",
>> -"snps,dwc3",
>> +FSL_USB2_MPH,
>> +FSL_USB2_DR,
>> +SNPS_DWC3,
>>  NULL
>>  };
>>
>> @@ -80,16 +80,24 @@ static int fdt_fixup_usb_mode_phy_type(void *blob,
>> const char *mode,  }
>>
>>  static int fdt_fixup_usb_erratum(void *blob, const char *prop_erratum,
>> - int start_offset)
>> + const char *controller_type, int start_offset)
>>  {
>>  int node_offset, err;
>>  const char *node_type = NULL;
>> +const char *node_name = NULL;
>>
>>  err = fdt_usb_get_node_type(blob, start_offset,
>>  _offset, _type);
>>  if (err < 0)
>>  return err;
>>
>> +if (!strcmp(node_type, FSL_USB2_MPH) || !strcmp(node_type,
>FSL_USB2_DR))
>> +node_name = USB2_CI;
>> +else
>> +node_name = node_type;
>> +if (strcmp(node_name, controller_type))
>> +return err;
>> +
>>  err = fdt_setprop(blob, node_offset, prop_erratum, NULL, 0);
>>  if (err < 0) {
>>  printf("ERROR: could not set %s for %s: %s.\n", @@ -99,6 +107,23
>@@
>> static int fdt_fixup_usb_erratum(void *blob, const char *prop_erratum,
>>  return node_offset;
>>  }
>>
>> +static int fdt_fixup_erratum(int *usb_erratum_off, void *blob,
>> + const char *controller_type, char *str,
>> + bool (*has_erratum)(void))
>> +{
>> +char buf[32] = {0};
>> +
>> +snprintf(buf, sizeof(buf), "fsl,usb-erratum-%s", str);
>> +if (!(has_erratum()))
>
>No need for the extra parenthesis around has_erratum() .
>

Ok. Will remove parenthesis in v4.

>> +return -EINVAL;
>> +*usb_erratum_off = fdt_fixup_usb_erratum(blob, buf, controller_type,
>> + *usb_erratum_off);
>> +if (*usb_erratum_off < 0)
>> +return -ENOSPC;
>> +debug("Adding USB erratum %s\n", str);
>> +return 0;
>> +}
>> +
>>  void fdt_fixup_dr_usb(void *blob, bd_t *bd)  {
>>  static const char * const modes[] = { "host", "peripheral", "otg" };
>> @@ -111,6 +136,7 @@ void fdt_fixup_dr_usb(void *blob, bd_t *bd)
>>  int usb_phy_off = -1;
>>  char str[5];
>>  int i, j;
>> +int ret;
>>
>>  for (i = 1; i <= CONFIG_USB_MAX_CONTROLLER_COUNT; i++) {
>>  const char *dr_mode_type = NULL;
>> @@ -164,39 +190,25 @@ void fdt_fixup_dr_usb(void *blob, bd_t *bd)
>>  if (usb_phy_off < 0)
>>  return;
>>
>> -if (has_erratum_a006261()) {
>> -usb_erratum_a006261_off =  fdt_fixup_usb_erratum
>> -   (blob,
>> -"fsl,usb-erratum-a006261",
>> -usb_erratum_a006261_off);
>> -if (usb_erratum_a006261_off < 0)
>> -return;
>> -}
>> -
>> -if (has_erratum_a007075()) {
>> -usb_erratum_a007075_off =  fdt_fixup_usb_erratum
>> -   (blob,
>> -

Re: [U-Boot] [PATCH v3 1/5] arm64: fsl-layerscape: add get_svr and IS_SVR_REV helper

[Sriram Dash]

>-Original Message-
>From: Marek Vasut [mailto:ma...@denx.de]
>Sent: Thursday, June 09, 2016 6:58 PM
>To: Sriram Dash ; u-boot@lists.denx.de
>Cc: york sun ; albert.u.b...@aribaud.net; Rajesh Bhagat
>
>Subject: Re: [PATCH v3 1/5] arm64: fsl-layerscape: add get_svr and IS_SVR_REV
>helper
>
>On 06/09/2016 02:21 PM, Sriram Dash wrote:
>> Adds get_svr and IS_SVR_REV helpers for ARMv8 platforms, similar to
>> PPC and ARMv7.
>>
>> Signed-off-by: Sriram Dash 
>> Signed-off-by: Rajesh Bhagat 
>> ---
>>
>> Changes in v1:
>>   - Added commit message
>>
>> Changes in v2:
>>   - No update
>
>So what changed in V3 here ?
>

Typo mistake. Will take care in v4.

>>  arch/arm/cpu/armv8/fsl-layerscape/cpu.c| 7 +++
>>  arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h | 2 ++
>> arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h | 3 +++
>>  arch/arm/include/asm/arch-fsl-layerscape/soc.h | 2 ++
>>  4 files changed, 14 insertions(+)
>>
>> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
>> b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
>> index 9a5a6b5..9c575c1 100644
>> --- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
>> +++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
>> @@ -528,6 +528,13 @@ u32 fsl_qoriq_core_to_type(unsigned int core)
>>  return -1;  /* cannot identify the cluster */
>>  }
>>
>> +uint get_svr(void)
>> +{
>> +struct ccsr_gur __iomem *gur = (void *)(CONFIG_SYS_FSL_GUTS_ADDR);
>> +
>> +return gur_in32(>svr);
>> +}
>> +
>>  #ifdef CONFIG_DISPLAY_CPUINFO
>>  int print_cpuinfo(void)
>>  {
>> diff --git a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
>> b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
>> index e98e055..8b8a7c1 100644
>> --- a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
>> +++ b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
>> @@ -596,4 +596,6 @@ struct ccsr_cci400 {
>>  #define SCR0_CLIENTPD_MASK  0x0001
>>  #define SCR0_USFCFG_MASK0x0400
>>
>> +uint get_svr(void);
>> +
>>  #endif  /* __ARCH_FSL_LSCH2_IMMAP_H__*/
>> diff --git a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
>> b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
>> index 65b3357..e48bbaf 100644
>> --- a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
>> +++ b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
>> @@ -319,4 +319,7 @@ struct ccsr_reset {
>>  u32 ip_rev1;/* 0xbf8 */
>>  u32 ip_rev2;/* 0xbfc */
>>  };
>> +
>> +uint get_svr(void);
>> +
>>  #endif /* __ARCH_FSL_LSCH3_IMMAP_H_ */ diff --git
>> a/arch/arm/include/asm/arch-fsl-layerscape/soc.h
>> b/arch/arm/include/asm/arch-fsl-layerscape/soc.h
>> index 02ecc62..f244904 100644
>> --- a/arch/arm/include/asm/arch-fsl-layerscape/soc.h
>> +++ b/arch/arm/include/asm/arch-fsl-layerscape/soc.h
>> @@ -53,6 +53,8 @@ struct cpu_type {
>>  #define SVR_MIN(svr)(((svr) >> 0) & 0xf)
>>  #define SVR_SOC_VER(svr)(((svr) >> 8) & SVR_WO_E)
>>  #define IS_E_PROCESSOR(svr) (!((svr >> 8) & 0x1))
>> +#define IS_SVR_REV(svr, maj, min) \
>> +((SVR_MAJ(svr) == maj) && (SVR_MIN(svr) == min))
>
>This is susceptible to macro expansion problems, you need parenthesis around 
>all
>the macro args:
>((SVR_MAJ(svr) == (maj)) && (SVR_MIN(svr) == (min)))
>

Ok. Will take care in v4.

>>  /* ahci port register default value */
>>  #define AHCI_PORT_PHY_1_CFG0xa003fffe
>>
>
>
>--
>Best regards,
>Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 7/9] libfdt: Add overlay application function

[Stefan Agner]

On 2016-05-27 02:13, Maxime Ripard wrote:
> The device tree overlays are a good way to deal with user-modifyable
> boards or boards with some kind of an expansion mechanism where we can
> easily plug new board in (like the BBB, the Raspberry Pi or the CHIP).
> 
> Add a new function to merge overlays with a base device tree.
> 
> Signed-off-by: Maxime Ripard 
> ---
>  include/libfdt.h |  30 
>  lib/libfdt/Makefile  |   2 +-
>  lib/libfdt/fdt_overlay.c | 414 
> +++
>  3 files changed, 445 insertions(+), 1 deletion(-)
>  create mode 100644 lib/libfdt/fdt_overlay.c
> 

How big is the bloat? Did you thought about making it optional? e.g.
CONFIG_OF_LIBFDT_OVERLAY

What is the general opinion on that?


> diff --git a/include/libfdt.h b/include/libfdt.h
> index 1e01b2c7ebdf..783067e841a1 100644
> --- a/include/libfdt.h
> +++ b/include/libfdt.h
> @@ -1698,6 +1698,36 @@ int fdt_add_subnode(void *fdt, int
> parentoffset, const char *name);
>   */
>  int fdt_del_node(void *fdt, int nodeoffset);
>  
> +/**
> + * fdt_overlay_apply - Applies a DT overlay on a base DT
> + * @fdt: pointer to the base device tree blob
> + * @fdto: pointer to the device tree overlay blob
> + *
> + * fdt_overlay_apply() will apply the given device tree overlay on the
> + * given base device tree.
> + *
> + * Expect the base device tree to be modified, even if the function
> + * returns an error.

Hm this sounds somewhat contradicting to a comment inside that
function...

> + *
> + * returns:
> + *   0, on success
> + *   -FDT_ERR_NOSPACE, there's not enough space in the base device tree
> + *   -FDT_ERR_NOTFOUND, the overlay points to some inexistant nodes or
> + *   properties in the base DT
> + *   -FDT_ERR_BADPHANDLE, the phandles in the overlay do not have the right
> + *   magic
> + *   -FDT_ERR_INTERNAL,
> + *   -FDT_ERR_BADLAYOUT,
> + *   -FDT_ERR_BADMAGIC,
> + *   -FDT_ERR_BADOFFSET,
> + *   -FDT_ERR_BADPATH,
> + *   -FDT_ERR_BADVERSION,
> + *   -FDT_ERR_BADSTRUCTURE,
> + *   -FDT_ERR_BADSTATE,
> + *   -FDT_ERR_TRUNCATED, standard meanings
> + */
> +int fdt_overlay_apply(void *fdt, void *fdto);
> +
>  /**/
>  /* Debugging / informational functions*/
>  /**/
> diff --git a/lib/libfdt/Makefile b/lib/libfdt/Makefile
> index 934d6142c3e9..4935bf012a75 100644
> --- a/lib/libfdt/Makefile
> +++ b/lib/libfdt/Makefile
> @@ -6,4 +6,4 @@
>  #
>  
>  obj-y += fdt.o fdt_ro.o fdt_rw.o fdt_strerror.o fdt_sw.o fdt_wip.o \
> - fdt_empty_tree.o fdt_addresses.o fdt_region.o
> + fdt_empty_tree.o fdt_addresses.o fdt_region.o fdt_overlay.o
> diff --git a/lib/libfdt/fdt_overlay.c b/lib/libfdt/fdt_overlay.c
> new file mode 100644
> index ..1e68e903c734
> --- /dev/null
> +++ b/lib/libfdt/fdt_overlay.c
> @@ -0,0 +1,414 @@
> +#include "libfdt_env.h"
> +
> +#include 
> +#include 
> +
> +#include "libfdt_internal.h"
> +
> +static uint32_t fdt_overlay_get_target_phandle(const void *fdto, int node)
> +{
> + const uint32_t *val;
> + int len;
> +
> + val = fdt_getprop(fdto, node, "target", );
> + if (!val || (len != sizeof(*val)))
> + return 0;
> +
> + return fdt32_to_cpu(*val);
> +}
> +
> +static int fdt_overlay_get_target(const void *fdt, const void *fdto,
> +   int fragment)
> +{
> + uint32_t phandle;
> + const char *path;
> +
> + /* Try first to do a phandle based lookup */
> + phandle = fdt_overlay_get_target_phandle(fdto, fragment);
> + if (phandle)
> + return fdt_node_offset_by_phandle(fdt, phandle);
> +
> + /* And then a path based lookup */
> + path = fdt_getprop(fdto, fragment, "target-path", NULL);
> + if (!path)
> + return -FDT_ERR_NOTFOUND;
> +
> + return fdt_path_offset(fdt, path);
> +}
> +
> +static int fdt_overlay_adjust_node_phandles(void *fdto, int node,
> + uint32_t delta)
> +{
> + int property;
> + int child;
> +
> + fdt_for_each_property(fdto, node, property) {
> + const uint32_t *val;
> + const char *name;
> + uint32_t adj_val;
> + int len;
> + int ret;
> +
> + val = fdt_getprop_by_offset(fdto, property,
> + , );
> + if (!val || (len != sizeof(*val)))
> + continue;
> +
> + if (strcmp(name, "phandle") && strcmp(name, "linux,phandle"))
> + continue;
> +
> + adj_val = fdt32_to_cpu(*val);
> + adj_val += delta;
> + ret = fdt_setprop_inplace_u32(fdto, node, name, adj_val);
> + if (ret)
> + return ret;
> + }
> +
> + fdt_for_each_subnode(fdto, 

Re: [U-Boot] [PATCH v2 0/3] Add USB EHCI support for ls1012aqds

[Rajesh Bhagat]

> -Original Message-
> From: Marek Vasut [mailto:ma...@denx.de]
> Sent: Thursday, June 09, 2016 7:12 PM
> To: Rajesh Bhagat ; u-boot@lists.denx.de
> Cc: Sriram Dash ; albert.u.b...@aribaud.net;
> prabha...@freescale.com; york sun ; Rajat Srivastava
> 
> Subject: Re: [PATCH v2 0/3] Add USB EHCI support for ls1012aqds
> 
> On 06/09/2016 08:57 AM, Rajesh Bhagat wrote:
> > Adds USB EHCI support for ls1012qds by adding the support for NXP ULPI
> > PHY and adding the support it configuration files. Also enables, USB2
> > IP in ns access defines.
> >
> > Rajesh Bhagat (3):
> >   drivers: usb: fsl: add USB ULPI init code
> >   config: ls1012aqds: Add USB EHCI support for ls1012aqds
> >   armv8: ls1012a: Added CSU assignment for USB2
> >
> >  .../include/asm/arch-fsl-layerscape/immap_lsch2.h  |1 +
> >  .../include/asm/arch-fsl-layerscape/ns_access.h|2 +
> >  drivers/usb/host/ehci-fsl.c|   21 
> > 
> >  include/configs/ls1012aqds.h   |5 
> >  include/usb/ehci-ci.h  |2 +-
> >  5 files changed, 30 insertions(+), 1 deletions(-)
> >

Hello Marek, 

> I wanted to apply these on u-boot-usb/master , but patch 2 fails to apply. 
> Please
> rebase and repose.
> 

Can you apply below patch for Layerscape USB macro cleanup for various Soc to 
apply above patch:

https://patchwork.ozlabs.org/patch/631595/

[root@phoenix u-boot-usb]$ pw-am.sh 631595
2016-06-10 09:02:02 URL:https://patchwork.ozlabs.org/patch/631595/mbox/ [6138] 
-> "pw-am-631595.patch" [1]
Applying: include: usb: Rename USB controller base address mapping
[root@phoenix u-boot-usb]$ pw-am.sh 632644
2016-06-10 09:02:18 URL:https://patchwork.ozlabs.org/patch/632644/mbox/ [2104] 
-> "pw-am-632644.patch" [1]
Applying: drivers: usb: fsl: add USB ULPI init code
[root@phoenix u-boot-usb]$ pw-am.sh 632646
2016-06-10 09:02:28 URL:https://patchwork.ozlabs.org/patch/632646/mbox/ [2819] 
-> "pw-am-632646.patch" [1]
Applying: config: ls1012aqds: Add USB EHCI support for ls1012aqds
[root@phoenix u-boot-usb]$ pw-am.sh 632645
2016-06-10 09:02:36 URL:https://patchwork.ozlabs.org/patch/632645/mbox/ [1501] 
-> "pw-am-632645.patch" [1]
Applying: armv8: ls1012a: Added CSU assignment for USB2

OR 

Please share if there is a need to rebase them. 

Best Regards,
Rajesh Bhagat

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

Re: [U-Boot] [PATCH v2 6/9] libfdt: Add max phandle retrieval function

[Stefan Agner]

On 2016-05-27 02:13, Maxime Ripard wrote:
> Add a function to retrieve the highest phandle in a given device tree.
> 
> Signed-off-by: Maxime Ripard 
> ---
>  include/libfdt.h| 13 +
>  lib/libfdt/fdt_ro.c | 15 +++
>  2 files changed, 28 insertions(+)
> 
> diff --git a/include/libfdt.h b/include/libfdt.h
> index 4e8eb9ede3a4..1e01b2c7ebdf 100644
> --- a/include/libfdt.h
> +++ b/include/libfdt.h
> @@ -284,6 +284,19 @@ int fdt_move(const void *fdt, void *buf, int bufsize);
>  const char *fdt_string(const void *fdt, int stroffset);
>  
>  /**
> + * fdt_get_max_phandle - retrieves the highest phandle in a tree
> + * @fdt: pointer to the device tree blob
> + *
> + * fdt_get_max_phandle retrieves the highest phandlle in the given

Typo: phandlle

> + * device tree
> + *
> + * returns:
> + *  the highest phandle on success
> + *  0, if an error occured

Typo: occur(r)ed

Otherwise looks good to me!

Reviewed-by: Stefan Agner 

> + */
> +uint32_t fdt_get_max_phandle(const void *fdt);
> +
> +/**
>   * fdt_num_mem_rsv - retrieve the number of memory reserve map entries
>   * @fdt: pointer to the device tree blob
>   *
> diff --git a/lib/libfdt/fdt_ro.c b/lib/libfdt/fdt_ro.c
> index 7b0777b67eb3..9130ce718965 100644
> --- a/lib/libfdt/fdt_ro.c
> +++ b/lib/libfdt/fdt_ro.c
> @@ -47,6 +47,21 @@ static int _fdt_string_eq(const void *fdt, int stroffset,
>   return (strnlen(p, len + 1) == len) && (memcmp(p, s, len) == 0);
>  }
>  
> +uint32_t fdt_get_max_phandle(const void *fdt)
> +{
> + uint32_t max_phandle = 0, phandle;
> + int offset;
> +
> + for (offset = fdt_next_node(fdt, -1, NULL); offset >= 0;
> +  offset = fdt_next_node(fdt, offset, NULL)) {
> + phandle = fdt_get_phandle(fdt, offset);
> + if (phandle > max_phandle)
> + max_phandle = phandle;
> + }
> +
> + return max_phandle;
> +}
> +
>  int fdt_get_mem_rsv(const void *fdt, int n, uint64_t *address, uint64_t 
> *size)
>  {
>   FDT_CHECK_HEADER(fdt);
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 5/9] libfdt: Add iterator over properties

[Stefan Agner]

On 2016-05-27 02:13, Maxime Ripard wrote:
> Implement a macro based on fdt_first_property_offset and
> fdt_next_property_offset that provides a convenience to iterate over all
> the properties of a given node.
> 
> Signed-off-by: Maxime Ripard 
> ---
>  include/libfdt.h | 24 
>  1 file changed, 24 insertions(+)

Reviewed-by: Stefan Agner 

There would be already be several opportunities in existing code to use
that :-)

> 
> diff --git a/include/libfdt.h b/include/libfdt.h
> index 74b1d149c2dd..4e8eb9ede3a4 100644
> --- a/include/libfdt.h
> +++ b/include/libfdt.h
> @@ -441,6 +441,30 @@ int fdt_first_property_offset(const void *fdt,
> int nodeoffset);
>  int fdt_next_property_offset(const void *fdt, int offset);
>  
>  /**
> + * fdt_for_each_property - iterate over all properties of a node
> + * @fdt: FDT blob (const void *)
> + * @node:node offset (int)
> + * @property:property offset (int)
> + *
> + * This is actually a wrapper around a for loop and would be used like so:
> + *
> + *   fdt_for_each_property(fdt, node, property) {
> + *   ...
> + *   use property
> + *   ...
> + *   }
> + *
> + * Note that this is implemented as a macro and property is used as
> + * iterator in the loop. It should therefore be a locally allocated
> + * variable. The node variable on the other hand is never modified, so
> + * it can be constant or even a literal.
> + */
> +#define fdt_for_each_property(fdt, node, property)   \
> + for (property = fdt_first_property_offset(fdt, node);   \
> +  property >= 0; \
> +  property = fdt_next_property_offset(fdt, property))
> +
> +/**
>   * fdt_get_property_by_offset - retrieve the property at a given offset
>   * @fdt: pointer to the device tree blob
>   * @offset: offset of the property to retrieve
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V4 1/3] serial: 16550: Add getfcr accessor

[Simon Glass]

On 9 June 2016 at 19:44, Marek Vasut  wrote:
> Add function which allows fetching the default FCR register setting
> from platform data for DM , while retaining old behavior for non-DM
> by returning UART_FCRVAL.
>
> Signed-off-by: Marek Vasut 
> Cc: Tom Rini 
> Cc: Simon Glass 
> ---
> V2: If CONFIG_DM_SERIAL and DEBUG_UART are enabled, the ns16550_getfcr()
> can be invoked with NULL plat data . Check for this case and return
> the default UART_FCRVAL then.
> V3: It turns out that if DEBUG_UART is defined, $port points directly to
> hardware registers. Add additional ifdef to handle the case where
> debug uart is enabled with DM_SERIAL correctly.
> V4: Use UART_FCRVAL in _debug_uart_init() directly
> ---
>  drivers/serial/ns16550.c | 18 --
>  include/ns16550.h|  1 +
>  2 files changed, 17 insertions(+), 2 deletions(-)

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

Re: [U-Boot] [PATCH v2] mkimage: fit: spl: Add an optional static offset for external data

[Simon Glass]

Hi Teddy,

On 9 June 2016 at 19:02, Teddy Reed  wrote:
> Thanks for the review Simon!
>
> On Thu, Jun 9, 2016 at 6:03 PM, Simon Glass  wrote:
>> Hi Teddy,
>>
>> On 5 June 2016 at 15:18, Teddy Reed  wrote:
>>>
>>> When building a FIT with external data (-E), an SPL may require absolute
>>> positioning for executing the external firmware. To acheive this use the
>>> (-p) switch, which will replace the amended 'data-offset' with 
>>> 'data-position'
>>> indicating the absolute position of external data.
>>
>> Why does SPL require that? Is it because it is at an external address,
>> not inside the FIT?
>>
>
> Ah, it's more so the U-Boot proper that expects to have been built
> with a TEXT_BASE known to it and the SPL. I'm trying to accommodate a
> scenario where U-Boot proper executes after being verified by the SPL,
> without needing arguments or relocation.
>
> Given an execute-in-place without arguments U-Boot proper must know
> TEXT_BASE at build time. This is clobbered when the external FIT is
> generated, if the firmware is placed at a relative position. With a -p
> your U_BOOT_TEXT_BASE remains constant between build and external FIT
> generation.

I'm stil not quite clear on this.

SPL has to know where to load U-Boot. The existing FIT support uses
CONFIG_SYS_TEXT_BASE for this. spl_load_simple_fit() should load
U-Boot proper to that address. The position of U-Boot in the FIT
itself should not be relevant.

What sort of relocation are you trrying to avoid?


>
>>>
>>> It is considered an error if the requested absolute position overlaps with 
>>> the
>>> initial data required for the compact FIT.
>>>
>>> Cc: Simon Glass 
>>> ---
>>>
>>> Changes in v2:
>>> - Add -p argument to mkimage.1
>>> - Add -E, -p arguments to mkimage usage text
>>> - Add notes for static position within uImage.FIT docs
>>> - Rebased onto master
>>>
>>>  doc/mkimage.1 |  6 ++
>>>  doc/uImage.FIT/source_file_format.txt |  4 
>>>  tools/fit_image.c | 19 ++-
>>>  tools/imagetool.h |  1 +
>>>  tools/mkimage.c   | 13 +++--
>>>  5 files changed, 40 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/doc/mkimage.1 b/doc/mkimage.1
>>> index 4b3a255..ffa7d60 100644
>>> --- a/doc/mkimage.1
>>> +++ b/doc/mkimage.1
>>> @@ -152,6 +152,12 @@ verification. Typically the file here is the device 
>>> tree binary used by
>>>  CONFIG_OF_CONTROL in U-Boot.
>>>
>>>  .TP
>>> +.BI "\-p [" "external position" "]"
>>> +Place external data at a static external position. See \-E. Instead of 
>>> writing
>>> +a 'data-offset' property defining the offset from the end of the FIT, \-p 
>>> will
>>> +use 'data-position' as the absolute position from the base of the FIT.
>>> +
>>> +.TP
>>>  .BI "\-r
>>>  Specifies that keys used to sign the FIT are required. This means that they
>>>  must be verified for the image to boot. Without this option, the 
>>> verification
>>> diff --git a/doc/uImage.FIT/source_file_format.txt 
>>> b/doc/uImage.FIT/source_file_format.txt
>>> index 3f54180..ee72740 100644
>>> --- a/doc/uImage.FIT/source_file_format.txt
>>> +++ b/doc/uImage.FIT/source_file_format.txt
>>> @@ -282,6 +282,10 @@ In this case the 'data' property is omitted. Instead 
>>> you can use:
>>>  aligned to a 4-byte boundary.
>>>- data-size : size of the data in bytes
>>>
>>> +The 'data-offset' property can be substituted with 'data-position', which
>>> +defines a static position or address from the base of the FIT as the 
>>> offset.
>>> +A static position is helpful when booting U-Boot proper before performing
>>> +relocation.
>>
>> This confuses me since it mentions a static address, but then
>> references the base of the FIT, suggesting it is relative.
>>
>> Can you use the word 'absolute' instead of 'static'?
>>
>
> Absolutely! ;)

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

[U-Boot] [PATCH V4 1/3] serial: 16550: Add getfcr accessor

[Marek Vasut]

Add function which allows fetching the default FCR register setting
from platform data for DM , while retaining old behavior for non-DM
by returning UART_FCRVAL.

Signed-off-by: Marek Vasut 
Cc: Tom Rini 
Cc: Simon Glass 
---
V2: If CONFIG_DM_SERIAL and DEBUG_UART are enabled, the ns16550_getfcr()
can be invoked with NULL plat data . Check for this case and return
the default UART_FCRVAL then.
V3: It turns out that if DEBUG_UART is defined, $port points directly to
hardware registers. Add additional ifdef to handle the case where
debug uart is enabled with DM_SERIAL correctly.
V4: Use UART_FCRVAL in _debug_uart_init() directly
---
 drivers/serial/ns16550.c | 18 --
 include/ns16550.h|  1 +
 2 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
index c6cb3eb..880329b 100644
--- a/drivers/serial/ns16550.c
+++ b/drivers/serial/ns16550.c
@@ -120,6 +120,13 @@ static int ns16550_readb(NS16550_t port, int offset)
return serial_in_shift(addr + plat->reg_offset, plat->reg_shift);
 }
 
+static u32 ns16550_getfcr(NS16550_t port)
+{
+   struct ns16550_platdata *plat = port->plat;
+
+   return plat->fcr;
+}
+
 /* We can clean these up once everything is moved to driver model */
 #define serial_out(value, addr)\
ns16550_writeb(com_port, \
@@ -127,6 +134,11 @@ static int ns16550_readb(NS16550_t port, int offset)
 #define serial_in(addr) \
ns16550_readb(com_port, \
(unsigned char *)addr - (unsigned char *)com_port)
+#else
+static u32 ns16550_getfcr(NS16550_t port)
+{
+   return UART_FCRVAL;
+}
 #endif
 
 int ns16550_calc_divisor(NS16550_t port, int clock, int baudrate)
@@ -170,7 +182,7 @@ void NS16550_init(NS16550_t com_port, int baud_divisor)
serial_out(0x7, _port->mdr1);   /* mode select reset TL16C750*/
 #endif
serial_out(UART_MCRVAL, _port->mcr);
-   serial_out(UART_FCRVAL, _port->fcr);
+   serial_out(ns16550_getfcr(com_port), _port->fcr);
if (baud_divisor != -1)
NS16550_setbrg(com_port, baud_divisor);
 #if defined(CONFIG_OMAP) || \
@@ -191,7 +203,7 @@ void NS16550_reinit(NS16550_t com_port, int baud_divisor)
serial_out(CONFIG_SYS_NS16550_IER, _port->ier);
NS16550_setbrg(com_port, 0);
serial_out(UART_MCRVAL, _port->mcr);
-   serial_out(UART_FCRVAL, _port->fcr);
+   serial_out(ns16550_getfcr(com_port), _port->fcr);
NS16550_setbrg(com_port, baud_divisor);
 }
 #endif /* CONFIG_NS16550_MIN_FUNCTIONS */
@@ -405,6 +417,8 @@ int ns16550_serial_ofdata_to_platdata(struct udevice *dev)
return -EINVAL;
}
 
+   plat->fcr = UART_FCRVAL;
+
return 0;
 }
 #endif
diff --git a/include/ns16550.h b/include/ns16550.h
index 1311f4c..45fd68b 100644
--- a/include/ns16550.h
+++ b/include/ns16550.h
@@ -57,6 +57,7 @@ struct ns16550_platdata {
int reg_shift;
int clock;
int reg_offset;
+   u32 fcr;
 };
 
 struct udevice;
-- 
2.7.0

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

Re: [U-Boot] [PATCH v2] verified-boot: Minimal support for booting U-Boot proper from SPL

[Andreas Dannenberg]

On Thu, Jun 09, 2016 at 07:18:44PM -0700, Teddy Reed wrote:
> This allows a board to configure verified boot within the SPL using
> a FIT or FIT with external data. It also allows the SPL to perform
> signature verification without needing relocation.
> 
> The board configuration will need to add the following feature defines:
> CONFIG_SPL_CRYPTO_SUPPORT
> CONFIG_SPL_HASH_SUPPORT
> CONFIG_SPL_SHA256
> 
> In this example, SHA256 is the only selected hashing algorithm.
> 
> And the following booleans:
> CONFIG_SPL=y
> CONFIG_SPL_DM=y
> CONFIG_SPL_LOAD_FIT=y
> CONFIG_SPL_FIT=y
> CONFIG_SPL_OF_CONTROL=y
> CONFIG_SPL_OF_LIBFDT=y
> CONFIG_SPL_FIT_SIGNATURE=y
> 
> Signed-off-by: Teddy Reed 
> Acked-by: Simon Glass 

Applies cleanly now and builds without issues.

Acked-by: Andreas Dannenberg 

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

Re: [U-Boot] [PATCH v2] sunxi: Support booting from SPI flash

[Simon Glass]

Hi,

On 9 June 2016 at 18:33, Siarhei Siamashka  wrote:
> Hi Simon,
>
> On Thu, 9 Jun 2016 17:36:10 -0700
> Simon Glass  wrote:
>
>> Hi,
>>
>> On 7 June 2016 at 05:28, Siarhei Siamashka  
>> wrote:
>> > Allwinner devices support SPI flash as one of the possible
>> > bootable media type. The SPI flash chip needs to be connected
>> > to SPI0 pins (port C) to make this work. More information is
>> > available at:
>> >
>> > https://linux-sunxi.org/Bootable_SPI_flash
>> >
>> > This patch adds the initial support for booting from SPI flash.
>> > The existing SPI frameworks are not used in order to reduce the
>> > SPL code size. Right now the SPL size grows by ~370 bytes when
>> > CONFIG_SPL_SPI_SUNXI option is enabled.
>> >
>> > While there are no popular Allwinner devices with SPI flash at
>> > the moment, testing can be done using a SPI flash module (it
>> > can be bought for ~2$ on ebay) and jumper wires with the boards,
>> > which expose relevant pins on the expansion header. The SPI flash
>> > chips themselves are very cheap (some prices are even listed as
>> > low as 4 cents) and should not cost much if somebody decides to
>> > design a development board with an SPI flash chip soldered on
>> > the PCB.
>> >
>> > Another nice feature of the SPI flash is that it can be safely
>> > accessed in a device-independent way (since we know that the
>> > boot ROM is already probing these pins during the boot time).
>> > And if, for example, Olimex boards opted to use SPI flash instead
>> > of EEPROM, then they would have been able to have U-Boot installed
>> > in the SPI flash now and boot the rest of the system from the SATA
>> > hard drive. Hopefully we may see new interesting Allwinner based
>> > development boards in the future, now that the software support
>> > for the SPI flash is in a better shape :-)
>> >
>> > Testing can be done by enabling the CONFIG_SPL_SPI_SUNXI option
>> > in a board defconfig, then building U-Boot and finally flashing
>> > the resulting u-boot-sunxi-with-spl.bin binary over USB OTG with
>> > a help of the sunxi-fel tool:
>> >
>> >sunxi-fel spiflash-write 0 u-boot-sunxi-with-spl.bin
>> >
>> > The device needs to be switched into FEL (USB recovery) mode first.
>> > The most suitable boards for testing are Orange Pi PC and Pine64.
>> > Because these boards are cheap, have no built-in NAND/eMMC and
>> > expose SPI0 pins on the Raspberry Pi compatible expansion header.
>> > The A13-OLinuXino-Micro board also can be used.
>> >
>> > Signed-off-by: Siarhei Siamashka 
>> > ---
>> >
>> > Changes in v2:
>> >  - Add Kconfig option (CONFIG_SPL_SPI_SUNXI) and move the SPI flash
>> >support code into a separate source file
>> >  - Use CONFIG_SYS_SPI_U_BOOT_OFFS instead of the hardcoded constant
>> >  - Deinitialize the SPI controller and undo pin muxing after the job
>> >is done
>> >  - Size reduction of the SPI transfer function
>> >  - Add delay after each SPI transfer to ensure that the chip select
>> >deassert timing requirements (tSHSL) are always satisfied
>> >  - More comments in the code
>> >
>> >
>> >  arch/arm/include/asm/arch-sunxi/gpio.h |   3 +
>> >  arch/arm/mach-sunxi/board.c|   5 +
>> >  common/spl/spl.c   |   4 +-
>> >  drivers/mtd/spi/Kconfig|  12 ++
>> >  drivers/mtd/spi/Makefile   |   1 +
>> >  drivers/mtd/spi/sunxi_spi_spl.c| 283 
>> > +
>> >  include/configs/sunxi-common.h |   5 +
>> >  7 files changed, 311 insertions(+), 2 deletions(-)
>> >  create mode 100644 drivers/mtd/spi/sunxi_spi_spl.c
>>
>> Shouldn't this be a normal SPI driver? Then you could put this in
>> common/spl/spl_spi.c.
>
> This source file contains both a sunxi SPI controller support and a
> basic SPI flash read functionality glued together for size reduction
> purposes.
>
> We are interested in implementing the "spl_spi_load_image()" function,
> because this is what gets called when handling the BOOT_DEVICE_SPI
> case.
>
> The "drivers/mtd/spi" directory contains the "spi_spl_load.c" file,
> which implements this particular function with the help of the generic
> SPI flash support code from "spi_flash.c" and the generic SPI bus
> support provided by the code from the "drivers/spi" directory.
>
> What I'm doing in this patch is an implementation of a size reduced
> sunxi-specific replacement for "spi_spl_load.c". But in U-Boot proper
> (where the code size is not a problem anymore) we will need a real
> sunxi SPI driver.

OK I see, fair enough.

Do you know how much space this saves? I'm actually not sure how much
overhead the SPI flash layer adds.

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

Re: [U-Boot] [PATCH V3 1/3] serial: 16550: Add getfcr accessor

[Simon Glass]

Hi Marek,

On 9 June 2016 at 19:04, Marek Vasut  wrote:
> Add function which allows fetching the default FCR register setting
> from platform data for DM , while retaining old behavior for non-DM
> by returning UART_FCRVAL.
>
> Signed-off-by: Marek Vasut 
> Cc: Tom Rini 
> Cc: Simon Glass 
> ---
> V2: If CONFIG_DM_SERIAL and DEBUG_UART are enabled, the ns16550_getfcr()
> can be invoked with NULL plat data . Check for this case and return
> the default UART_FCRVAL then.
> V3: It turns out that if DEBUG_UART is defined, $port points directly to
> hardware registers. Add additional ifdef to handle the case where
> debug uart is enabled with DM_SERIAL correctly.
> ---
>  drivers/serial/ns16550.c | 24 +---
>  include/ns16550.h|  1 +
>  2 files changed, 22 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
> index c6cb3eb..728f338 100644
> --- a/drivers/serial/ns16550.c
> +++ b/drivers/serial/ns16550.c
> @@ -120,6 +120,17 @@ static int ns16550_readb(NS16550_t port, int offset)
> return serial_in_shift(addr + plat->reg_offset, plat->reg_shift);
>  }
>
> +static u32 ns16550_getfcr(NS16550_t port)
> +{
> +#ifdef CONFIG_DEBUG_UART_NS16550
> +   return UART_FCRVAL;
> +#else

Not here...

> +   struct ns16550_platdata *plat = port->plat;
> +
> +   return plat->fcr;
> +#endif
> +}
> +
>  /* We can clean these up once everything is moved to driver model */
>  #define serial_out(value, addr)\
> ns16550_writeb(com_port, \
> @@ -127,6 +138,11 @@ static int ns16550_readb(NS16550_t port, int offset)
>  #define serial_in(addr) \
> ns16550_readb(com_port, \
> (unsigned char *)addr - (unsigned char *)com_port)
> +#else
> +static u32 ns16550_getfcr(NS16550_t port)
> +{
> +   return UART_FCRVAL;
> +}
>  #endif
>
>  int ns16550_calc_divisor(NS16550_t port, int clock, int baudrate)
> @@ -170,7 +186,7 @@ void NS16550_init(NS16550_t com_port, int baud_divisor)
> serial_out(0x7, _port->mdr1);   /* mode select reset 
> TL16C750*/
>  #endif
> serial_out(UART_MCRVAL, _port->mcr);
> -   serial_out(UART_FCRVAL, _port->fcr);
> +   serial_out(ns16550_getfcr(com_port), _port->fcr);
> if (baud_divisor != -1)
> NS16550_setbrg(com_port, baud_divisor);
>  #if defined(CONFIG_OMAP) || \
> @@ -191,7 +207,7 @@ void NS16550_reinit(NS16550_t com_port, int baud_divisor)
> serial_out(CONFIG_SYS_NS16550_IER, _port->ier);
> NS16550_setbrg(com_port, 0);
> serial_out(UART_MCRVAL, _port->mcr);
> -   serial_out(UART_FCRVAL, _port->fcr);
> +   serial_out(ns16550_getfcr(com_port), _port->fcr);
> NS16550_setbrg(com_port, baud_divisor);
>  }
>  #endif /* CONFIG_NS16550_MIN_FUNCTIONS */
> @@ -262,7 +278,7 @@ static inline void _debug_uart_init(void)
> CONFIG_BAUDRATE);
> serial_dout(_port->ier, CONFIG_SYS_NS16550_IER);
> serial_dout(_port->mcr, UART_MCRVAL);
> -   serial_dout(_port->fcr, UART_FCRVAL);
> +   serial_dout(_port->fcr, ns16550_getfcr(com_port));

Just put UART_FCRVAL here instead of your function call.

>
> serial_dout(_port->lcr, UART_LCR_BKSE | UART_LCRVAL);
> serial_dout(_port->dll, baud_divisor & 0xff);
> @@ -405,6 +421,8 @@ int ns16550_serial_ofdata_to_platdata(struct udevice *dev)
> return -EINVAL;
> }
>
> +   plat->fcr = UART_FCRVAL;
> +
> return 0;
>  }
>  #endif
> diff --git a/include/ns16550.h b/include/ns16550.h
> index 1311f4c..45fd68b 100644
> --- a/include/ns16550.h
> +++ b/include/ns16550.h
> @@ -57,6 +57,7 @@ struct ns16550_platdata {
> int reg_shift;
> int clock;
> int reg_offset;
> +   u32 fcr;
>  };
>
>  struct udevice;
> --
> 2.7.0
>

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

[U-Boot] [PATCH v3] mkimage: fit: spl: Add an optional static offset for external data

[Teddy Reed]

When building a FIT with external data (-E), U-Boot proper may require
absolute positioning for executing the external firmware. To acheive this
use the (-p) switch, which will replace the amended 'data-offset' with
'data-position' indicating the absolute position of external data.

It is considered an error if the requested absolute position overlaps with the
initial data required for the compact FIT.

Signed-off-by: Teddy Reed 
---
Changes in v3:
- Improved documentation

Changes in v2:
- Add -p argument to mkimage.1
- Add -E, -p arguments to mkimage usage text
- Add notes for static position within uImage.FIT docs
- Rebased onto master

 doc/mkimage.1 |  6 ++
 doc/uImage.FIT/source_file_format.txt |  3 +++
 tools/fit_image.c | 19 ++-
 tools/imagetool.h |  1 +
 tools/mkimage.c   | 13 +++--
 5 files changed, 39 insertions(+), 3 deletions(-)

diff --git a/doc/mkimage.1 b/doc/mkimage.1
index 4b3a255..ffa7d60 100644
--- a/doc/mkimage.1
+++ b/doc/mkimage.1
@@ -152,6 +152,12 @@ verification. Typically the file here is the device tree 
binary used by
 CONFIG_OF_CONTROL in U-Boot.
 
 .TP
+.BI "\-p [" "external position" "]"
+Place external data at a static external position. See \-E. Instead of writing
+a 'data-offset' property defining the offset from the end of the FIT, \-p will
+use 'data-position' as the absolute position from the base of the FIT.
+
+.TP
 .BI "\-r
 Specifies that keys used to sign the FIT are required. This means that they
 must be verified for the image to boot. Without this option, the verification
diff --git a/doc/uImage.FIT/source_file_format.txt 
b/doc/uImage.FIT/source_file_format.txt
index 3f54180..91aa89a 100644
--- a/doc/uImage.FIT/source_file_format.txt
+++ b/doc/uImage.FIT/source_file_format.txt
@@ -282,6 +282,9 @@ In this case the 'data' property is omitted. Instead you 
can use:
 aligned to a 4-byte boundary.
   - data-size : size of the data in bytes
 
+The 'data-offset' property can be substituted with 'data-position', which
+defines an absolute position or address as the offset. This is helpful when
+booting U-Boot proper before performing relocation.
 
 9) Examples
 ---
diff --git a/tools/fit_image.c b/tools/fit_image.c
index 0551572..76a6de4 100644
--- a/tools/fit_image.c
+++ b/tools/fit_image.c
@@ -416,7 +416,13 @@ static int fit_extract_data(struct image_tool_params 
*params, const char *fname)
ret = -EPERM;
goto err_munmap;
}
-   fdt_setprop_u32(fdt, node, "data-offset", buf_ptr);
+   if (params->external_offset > 0) {
+   /* An external offset positions the data absolutely. */
+   fdt_setprop_u32(fdt, node, "data-position",
+   params->external_offset + buf_ptr);
+   } else {
+   fdt_setprop_u32(fdt, node, "data-offset", buf_ptr);
+   }
fdt_setprop_u32(fdt, node, "data-size", len);
 
buf_ptr += (len + 3) & ~3;
@@ -437,6 +443,17 @@ static int fit_extract_data(struct image_tool_params 
*params, const char *fname)
ret = -EIO;
goto err;
}
+
+   /* Check if an offset for the external data was set. */
+   if (params->external_offset > 0) {
+   if (params->external_offset < new_size) {
+   debug("External offset %x overlaps FIT length %x",
+ params->external_offset, new_size);
+   ret = -EINVAL;
+   goto err;
+   }
+   new_size = params->external_offset;
+   }
if (lseek(fd, new_size, SEEK_SET) < 0) {
debug("%s: Failed to seek to end of file: %s\n", __func__,
  strerror(errno));
diff --git a/tools/imagetool.h b/tools/imagetool.h
index a3ed0f4..1f2161c 100644
--- a/tools/imagetool.h
+++ b/tools/imagetool.h
@@ -74,6 +74,7 @@ struct image_tool_params {
struct content_info *content_tail;
bool external_data; /* Store data outside the FIT */
bool quiet; /* Don't output text in normal operation */
+   unsigned int external_offset;   /* Add padding to external data */
 };
 
 /*
diff --git a/tools/mkimage.c b/tools/mkimage.c
index aefe22f..ff3024a 100644
--- a/tools/mkimage.c
+++ b/tools/mkimage.c
@@ -93,11 +93,13 @@ static void usage(const char *msg)
"  -f => input filename for FIT source\n");
 #ifdef CONFIG_FIT_SIGNATURE
fprintf(stderr,
-   "Signing / verified boot options: [-k keydir] [-K dtb] [ -c 
] [-r]\n"
+   "Signing / verified boot options: [-E] [-k keydir] [-K dtb] [ 
-c ] [-p addr] [-r]\n"
+   "  -E => place data outside of the FIT structure\n"
"  

[U-Boot] [PATCH v2] verified-boot: Minimal support for booting U-Boot proper from SPL

[Teddy Reed]

This allows a board to configure verified boot within the SPL using
a FIT or FIT with external data. It also allows the SPL to perform
signature verification without needing relocation.

The board configuration will need to add the following feature defines:
CONFIG_SPL_CRYPTO_SUPPORT
CONFIG_SPL_HASH_SUPPORT
CONFIG_SPL_SHA256

In this example, SHA256 is the only selected hashing algorithm.

And the following booleans:
CONFIG_SPL=y
CONFIG_SPL_DM=y
CONFIG_SPL_LOAD_FIT=y
CONFIG_SPL_FIT=y
CONFIG_SPL_OF_CONTROL=y
CONFIG_SPL_OF_LIBFDT=y
CONFIG_SPL_FIT_SIGNATURE=y

Signed-off-by: Teddy Reed 
Acked-by: Simon Glass 
---
Changes in v2:
 - Rebase to master

 Kconfig | 11 +++
 common/Makefile |  1 +
 drivers/Makefile|  1 +
 drivers/crypto/rsa_mod_exp/mod_exp_sw.c |  1 +
 lib/Makefile|  9 -
 lib/rsa/Kconfig |  4 
 lib/rsa/Makefile|  2 +-
 7 files changed, 23 insertions(+), 6 deletions(-)

diff --git a/Kconfig b/Kconfig
index 4b46216..817f4f0 100644
--- a/Kconfig
+++ b/Kconfig
@@ -183,6 +183,11 @@ config FIT
  verified boot (secure boot using RSA). This option enables that
  feature.
 
+config SPL_FIT
+   bool "Support Flattened Image Tree within SPL"
+   depends on FIT
+   depends on SPL
+
 config FIT_VERBOSE
bool "Display verbose messages on FIT boot"
depends on FIT
@@ -205,6 +210,12 @@ config FIT_SIGNATURE
  format support in this case, enable it using
  CONFIG_IMAGE_FORMAT_LEGACY.
 
+config SPL_FIT_SIGNATURE
+   bool "Enable signature verification of FIT firmware within SPL"
+   depends on SPL_FIT
+   depends on SPL_DM
+   select SPL_RSA
+
 config FIT_BEST_MATCH
bool "Select the best match for the kernel device tree"
depends on FIT
diff --git a/common/Makefile b/common/Makefile
index 1557a04..97c59fe 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -93,6 +93,7 @@ obj-$(CONFIG_USB_KEYBOARD) += usb_kbd.o
 endif # !CONFIG_SPL_BUILD
 
 ifdef CONFIG_SPL_BUILD
+obj-$(CONFIG_SPL_HASH_SUPPORT) += hash.o
 obj-$(CONFIG_ENV_IS_IN_FLASH) += env_flash.o
 obj-$(CONFIG_SPL_YMODEM_SUPPORT) += xyzModem.o
 obj-$(CONFIG_SPL_NET_SUPPORT) += miiphyutil.o
diff --git a/drivers/Makefile b/drivers/Makefile
index f6295d2..db5317c 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_$(SPL_)RAM)  += ram/
 
 ifdef CONFIG_SPL_BUILD
 
+obj-$(CONFIG_SPL_CRYPTO_SUPPORT) += crypto/
 obj-$(CONFIG_SPL_I2C_SUPPORT) += i2c/
 obj-$(CONFIG_SPL_GPIO_SUPPORT) += gpio/
 obj-$(CONFIG_SPL_MMC_SUPPORT) += mmc/
diff --git a/drivers/crypto/rsa_mod_exp/mod_exp_sw.c 
b/drivers/crypto/rsa_mod_exp/mod_exp_sw.c
index dc6c064..3817fb3 100644
--- a/drivers/crypto/rsa_mod_exp/mod_exp_sw.c
+++ b/drivers/crypto/rsa_mod_exp/mod_exp_sw.c
@@ -32,6 +32,7 @@ U_BOOT_DRIVER(mod_exp_sw) = {
.name   = "mod_exp_sw",
.id = UCLASS_MOD_EXP,
.ops= _exp_ops_sw,
+   .flags  = DM_FLAG_PRE_RELOC,
 };
 
 U_BOOT_DEVICE(mod_exp_sw) = {
diff --git a/lib/Makefile b/lib/Makefile
index f77befe..f48d901 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -9,7 +9,6 @@ ifndef CONFIG_SPL_BUILD
 
 obj-$(CONFIG_EFI) += efi/
 obj-$(CONFIG_EFI_LOADER) += efi_loader/
-obj-$(CONFIG_RSA) += rsa/
 obj-$(CONFIG_LZMA) += lzma/
 obj-$(CONFIG_LZO) += lzo/
 obj-$(CONFIG_ZLIB) += zlib/
@@ -25,8 +24,6 @@ obj-y += crc8.o
 obj-y += crc16.o
 obj-$(CONFIG_ERRNO_STR) += errno_str.o
 obj-$(CONFIG_FIT) += fdtdec_common.o
-obj-$(CONFIG_$(SPL_)OF_CONTROL) += fdtdec_common.o
-obj-$(CONFIG_$(SPL_)OF_CONTROL) += fdtdec.o
 obj-$(CONFIG_TEST_FDTDEC) += fdtdec_test.o
 obj-$(CONFIG_GZIP) += gunzip.o
 obj-$(CONFIG_GZIP_COMPRESSED) += gzip.o
@@ -39,15 +36,17 @@ obj-y += net_utils.o
 obj-$(CONFIG_PHYSMEM) += physmem.o
 obj-y += qsort.o
 obj-y += rc4.o
-obj-$(CONFIG_SHA1) += sha1.o
 obj-$(CONFIG_SUPPORT_EMMC_RPMB) += sha256.o
-obj-$(CONFIG_SHA256) += sha256.o
 obj-$(CONFIG_TPM) += tpm.o
 obj-$(CONFIG_RBTREE)   += rbtree.o
 obj-$(CONFIG_BITREVERSE) += bitrev.o
 obj-y += list_sort.o
 endif
 
+obj-$(CONFIG_$(SPL_)RSA) += rsa/
+obj-$(CONFIG_$(SPL_)SHA1) += sha1.o
+obj-$(CONFIG_$(SPL_)SHA256) += sha256.o
+
 obj-$(CONFIG_$(SPL_)OF_LIBFDT) += libfdt/
 ifdef CONFIG_SPL_OF_CONTROL
 obj-$(CONFIG_OF_LIBFDT) += libfdt/
diff --git a/lib/rsa/Kconfig b/lib/rsa/Kconfig
index 86df0a0..09ec358 100644
--- a/lib/rsa/Kconfig
+++ b/lib/rsa/Kconfig
@@ -13,6 +13,10 @@ config RSA
  option. The software based modular exponentiation is built into
  mkimage irrespective of this option.
 
+config SPL_RSA
+   bool "Use RSA Library within SPL"
+   depends on RSA
+
 if RSA
 config RSA_SOFTWARE_EXP
bool "Enable driver for RSA Modular Exponentiation in software"
diff --git a/lib/rsa/Makefile b/lib/rsa/Makefile
index 6867e50..4b2c1ba 100644
--- a/lib/rsa/Makefile

Re: [U-Boot] [PATCH] mmc: Tinification of the mmc code

[Marek Vasut]

On 06/10/2016 03:16 AM, Simon Glass wrote:
> Hi Marek,

Hi,

> On 9 June 2016 at 18:12, Marek Vasut  wrote:
>> On 06/10/2016 02:34 AM, Simon Glass wrote:
>>> Hi Marek,
>>
>> Hi!
>>
>>> On 26 May 2016 at 12:41, Marek Vasut  wrote:
 Add new configuration option CONFIG_MMC_TINY which strips away all
 memory allocation within the MMC code and code for handling multiple
 cards. This allows extremely space-constrained SPL code use the MMC
 framework.

 Signed-off-by: Marek Vasut 
 Cc: Tom Rini 
 Cc: Simon Glass 
 ---
  common/spl/spl_mmc.c |  4 
  drivers/mmc/Makefile |  2 ++
  drivers/mmc/mmc.c| 59 
 +++-
  include/mmc.h|  1 +
  4 files changed, 65 insertions(+), 1 deletion(-)
>>>
>>> Can CONFIG_MMC_TINY be a Kconfig? Also I suggest CONFIG_SPL_MMC_TINY.
>>
>> It can, but how do I assure it's enabled only for SPL build ?
> 
> depends on SPL
> 
> and in the code:
> 
> #if CONFIG_IS_ENABLED(MMC_TINY)
> 
> will do it.

Ah right, thanks.

 diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
 index ae42221..51f0f24 100644
 --- a/common/spl/spl_mmc.c
 +++ b/common/spl/spl_mmc.c
 @@ -300,7 +300,11 @@ int spl_mmc_load_image(u32 boot_device)
 if (part == 7)
 part = 0;

 +#ifdef CONFIG_MMC_TINY
>>>
>>> if (CONFIG_IS_ENABLED(MMC_TINY))
>>>
>>> to avoid #ifdef
>>
>> The compiler complains about missing symbols blk_dselect_hwpart() and
>> such, so I will opt for the ifdef .
> 
> That's odd. It should not care about things which are not compiled in.

Must've been some oddity indeed.

 +   err = mmc_switch_part(mmc, part);
 +#else
 err = blk_dselect_hwpart(mmc_get_blk_desc(mmc), 
 part);
 +#endif
 if (err) {
  #ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
 puts("spl: mmc partition switch failed\n");
 diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
 index 3da4817..4d986cb 100644
 --- a/drivers/mmc/Makefile
 +++ b/drivers/mmc/Makefile
 @@ -10,8 +10,10 @@ obj-$(CONFIG_GENERIC_MMC) += mmc-uclass.o
  endif

  ifndef CONFIG_BLK
 +ifndef CONFIG_MMC_TINY
  obj-$(CONFIG_GENERIC_MMC) += mmc_legacy.o
  endif
 +endif

  obj-$(CONFIG_ARM_PL180_MMCI) += arm_pl180_mmci.o
  obj-$(CONFIG_ATMEL_SDHCI) += atmel_sdhci.o
 diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
 index d687345..1f240ed 100644
 --- a/drivers/mmc/mmc.c
 +++ b/drivers/mmc/mmc.c
 @@ -21,6 +21,29 @@
  #include 
  #include "mmc_private.h"

 +#if defined(CONFIG_MMC_TINY)
 +static struct mmc mmc_static;
 +struct mmc *find_mmc_device(int dev_num)
 +{
 +   return _static;
 +}
 +
 +void mmc_do_preinit(void)
 +{
 +   struct mmc *m = _static;
 +#ifdef CONFIG_FSL_ESDHC_ADAPTER_IDENT
 +   mmc_set_preinit(m, 1);
 +#endif
 +   if (m->preinit)
 +   mmc_start_init(m);
 +}
 +
 +struct blk_desc *mmc_get_blk_desc(struct mmc *mmc)
 +{
 +   return >block_dev;
 +}
 +#endif
 +
  __weak int board_mmc_getwp(struct mmc *mmc)
  {
 return -1;
 @@ -238,7 +261,11 @@ static ulong mmc_bread(struct blk_desc *block_dev, 
 lbaint_t start,
 if (!mmc)
 return 0;

 +#ifdef CONFIG_MMC_TINY
 +   err = mmc_switch_part(mmc, block_dev->hwpart);
 +#else
 err = blk_dselect_hwpart(block_dev, block_dev->hwpart);
 +#endif
 if (err < 0)
 return 0;

 @@ -568,7 +595,7 @@ static int mmc_set_capacity(struct mmc *mmc, int 
 part_num)
 return 0;
  }

 -static int mmc_switch_part(struct mmc *mmc, unsigned int part_num)
 +int mmc_switch_part(struct mmc *mmc, unsigned int part_num)
  {
 int ret;

 @@ -1585,6 +1612,34 @@ int mmc_unbind(struct udevice *dev)
 return 0;
  }

 +#elif defined(CONFIG_MMC_TINY)
 +static struct mmc mmc_static = {
 +   .dsr_imp= 0,
 +   .dsr= 0x,
 +   .block_dev = {
 +   .if_type= IF_TYPE_MMC,
 +   .removable  = 1,
 +   .devnum = 0,
 +   .block_read = mmc_bread,
 +   .block_write= mmc_bwrite,
 +   .block_erase= mmc_berase,
 +   .part_type  = 0,
 +   },
 +};
 +
 +struct mmc *mmc_create(const struct mmc_config *cfg, void *priv)
 +{
 +   struct mmc *mmc = _static;
 +
 +   mmc->cfg = cfg;
 +  

Re: [U-Boot] [PATCH 5/7] mtd: nand: Add+use mtd_to/from_nand and nand_get/set_controller_data

[Scott Wood]

On Mon, 2016-06-06 at 18:02 +0200, Boris Brezillon wrote:
> On Mon, 30 May 2016 13:57:56 -0500
> Scott Wood  wrote:
> 
> > These functions are part of the Linux 4.6 sync.  They are being added
> > before the main sync patch in order to make it easier to address the
> > issue across all NAND drivers (many/most of which do not closely track
> > their Linux counterparts) separately from other merge issues.
> 
> Some drivers are still directly accessing chip->mtd. Here is a patch
> fixing those places [1] (not tested).
> 
> [1] http://code.bulix.org/inu69a-100476

Could you send this as a proper patch?

Though some of the changes seem to be removing SPL mtd pointers rather than
converting chip->mtd.  I don't care much whether those pointers are retained
but it's not "directly accessing chip->mtd".

-Scott

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

[U-Boot] [PATCH V2] mmc: Tinification of the mmc code

[Marek Vasut]

Add new configuration option CONFIG_MMC_TINY which strips away all
memory allocation within the MMC code and code for handling multiple
cards. This allows extremely space-constrained SPL code use the MMC
framework.

Signed-off-by: Marek Vasut 
Cc: Tom Rini 
Cc: Simon Glass 
---
V2: Switch the MMC_TINY option to Kconfig
---
 common/spl/spl_mmc.c |  6 +-
 drivers/mmc/Kconfig  | 16 ++
 drivers/mmc/Makefile |  6 ++
 drivers/mmc/mmc.c| 61 ++--
 include/mmc.h|  1 +
 5 files changed, 87 insertions(+), 3 deletions(-)

diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
index dcfd842..6508b3e 100644
--- a/common/spl/spl_mmc.c
+++ b/common/spl/spl_mmc.c
@@ -300,7 +300,11 @@ int spl_mmc_load_image(u32 boot_device)
if (part == 7)
part = 0;
 
-   err = blk_dselect_hwpart(mmc_get_blk_desc(mmc), part);
+   if (CONFIG_IS_ENABLED(MMC_TINY))
+   err = mmc_switch_part(mmc, part);
+   else
+   err = blk_dselect_hwpart(mmc_get_blk_desc(mmc), 
part);
+
if (err) {
 #ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
puts("spl: mmc partition switch failed\n");
diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
index c80efc3..365057b 100644
--- a/drivers/mmc/Kconfig
+++ b/drivers/mmc/Kconfig
@@ -16,6 +16,22 @@ config DM_MMC
  appear as block devices in U-Boot and can support filesystems such
  as EXT4 and FAT.
 
+config SPL_MMC_TINY
+   bool "Tiny MMC framework in SPL"
+   default n
+   help
+ Enable MMC framework tinification support. This option is useful if
+ if your SPL is extremely size constrained. Heed the warning, enable
+ this option if and only if you know exactly what you are doing, if
+ you are reading this help text, you most likely have no idea :-)
+
+ The MMC framework is reduced to bare minimum to be useful. No malloc
+ support is needed for the MMC framework operation with this option
+ enabled. The framework supports exactly one MMC device and exactly
+ one MMC driver. The MMC driver can be adjusted to avoid any malloc
+ operations too, which can remove the need for malloc support in SPL
+ and thus further reduce footprint.
+
 config MSM_SDHCI
bool "Qualcomm SDHCI controller"
depends on DM_MMC
diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
index 3da4817..89578d2 100644
--- a/drivers/mmc/Makefile
+++ b/drivers/mmc/Makefile
@@ -10,8 +10,14 @@ obj-$(CONFIG_GENERIC_MMC) += mmc-uclass.o
 endif
 
 ifndef CONFIG_BLK
+ifdef CONFIG_SPL_BUILD
+ifndef CONFIG_SPL_MMC_TINY
 obj-$(CONFIG_GENERIC_MMC) += mmc_legacy.o
 endif
+else
+obj-$(CONFIG_GENERIC_MMC) += mmc_legacy.o
+endif
+endif
 
 obj-$(CONFIG_ARM_PL180_MMCI) += arm_pl180_mmci.o
 obj-$(CONFIG_ATMEL_SDHCI) += atmel_sdhci.o
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index a4a2161..4875f45 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -21,6 +21,29 @@
 #include 
 #include "mmc_private.h"
 
+#if CONFIG_IS_ENABLED(MMC_TINY)
+static struct mmc mmc_static;
+struct mmc *find_mmc_device(int dev_num)
+{
+   return _static;
+}
+
+void mmc_do_preinit(void)
+{
+   struct mmc *m = _static;
+#ifdef CONFIG_FSL_ESDHC_ADAPTER_IDENT
+   mmc_set_preinit(m, 1);
+#endif
+   if (m->preinit)
+   mmc_start_init(m);
+}
+
+struct blk_desc *mmc_get_blk_desc(struct mmc *mmc)
+{
+   return >block_dev;
+}
+#endif
+
 __weak int board_mmc_getwp(struct mmc *mmc)
 {
return -1;
@@ -238,7 +261,11 @@ static ulong mmc_bread(struct blk_desc *block_dev, 
lbaint_t start,
if (!mmc)
return 0;
 
-   err = blk_dselect_hwpart(block_dev, block_dev->hwpart);
+   if (CONFIG_IS_ENABLED(MMC_TINY))
+   err = mmc_switch_part(mmc, block_dev->hwpart);
+   else
+   err = blk_dselect_hwpart(block_dev, block_dev->hwpart);
+
if (err < 0)
return 0;
 
@@ -568,7 +595,7 @@ static int mmc_set_capacity(struct mmc *mmc, int part_num)
return 0;
 }
 
-static int mmc_switch_part(struct mmc *mmc, unsigned int part_num)
+int mmc_switch_part(struct mmc *mmc, unsigned int part_num)
 {
int ret;
 
@@ -1576,6 +1603,34 @@ int mmc_unbind(struct udevice *dev)
return 0;
 }
 
+#elif CONFIG_IS_ENABLED(MMC_TINY)
+static struct mmc mmc_static = {
+   .dsr_imp= 0,
+   .dsr= 0x,
+   .block_dev = {
+   .if_type= IF_TYPE_MMC,
+   .removable  = 1,
+   .devnum = 0,
+   .block_read = mmc_bread,
+   .block_write= mmc_bwrite,
+   .block_erase= mmc_berase,
+ 

Re: [U-Boot] [PATCH V2 1/3] serial: 16550: Add getfcr accessor

[Marek Vasut]

On 06/10/2016 03:39 AM, Simon Glass wrote:
> Hi Marek,

Hi,

> On 9 June 2016 at 18:21, Marek Vasut  wrote:
>> Add function which allows fetching the default FCR register setting
>> from platform data for DM , while retaining old behavior for non-DM
>> by returning UART_FCRVAL.
>>
>> Signed-off-by: Marek Vasut 
>> Cc: Tom Rini 
>> Cc: Simon Glass 
>> ---
>> V2: If CONFIG_DM_SERIAL and DEBUG_UART are enabled, the ns16550_getfcr()
>> can be invoked with NULL plat data . Check for this case and return
>> the default UART_FCRVAL then.
>> ---
>>  drivers/serial/ns16550.c | 20 +---
>>  include/ns16550.h|  1 +
>>  2 files changed, 18 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
>> index c6cb3eb..b7ff3d7 100644
>> --- a/drivers/serial/ns16550.c
>> +++ b/drivers/serial/ns16550.c
>> @@ -120,6 +120,13 @@ static int ns16550_readb(NS16550_t port, int offset)
>> return serial_in_shift(addr + plat->reg_offset, plat->reg_shift);
>>  }
>>
>> +static u32 ns16550_getfcr(NS16550_t port)
>> +{
>> +   struct ns16550_platdata *plat = port->plat;
> 
> port->plat does not exist when using the debug UART. The pointer
> 'port' points directly to the hardware...

Sigh, the code is really convoluted and nasty.

>> +
>> +   return plat ? plat->fcr : UART_FCRVAL;
>> +}
>> +
>>  /* We can clean these up once everything is moved to driver model */
>>  #define serial_out(value, addr)\
>> ns16550_writeb(com_port, \
>> @@ -127,6 +134,11 @@ static int ns16550_readb(NS16550_t port, int offset)
>>  #define serial_in(addr) \
>> ns16550_readb(com_port, \
>> (unsigned char *)addr - (unsigned char *)com_port)
>> +#else
>> +static u32 ns16550_getfcr(NS16550_t port)
>> +{
>> +   return UART_FCRVAL;
>> +}
>>  #endif
>>
>>  int ns16550_calc_divisor(NS16550_t port, int clock, int baudrate)
>> @@ -170,7 +182,7 @@ void NS16550_init(NS16550_t com_port, int baud_divisor)
>> serial_out(0x7, _port->mdr1);   /* mode select reset 
>> TL16C750*/
>>  #endif
>> serial_out(UART_MCRVAL, _port->mcr);
>> -   serial_out(UART_FCRVAL, _port->fcr);
>> +   serial_out(ns16550_getfcr(com_port), _port->fcr);
>> if (baud_divisor != -1)
>> NS16550_setbrg(com_port, baud_divisor);
>>  #if defined(CONFIG_OMAP) || \
>> @@ -191,7 +203,7 @@ void NS16550_reinit(NS16550_t com_port, int baud_divisor)
>> serial_out(CONFIG_SYS_NS16550_IER, _port->ier);
>> NS16550_setbrg(com_port, 0);
>> serial_out(UART_MCRVAL, _port->mcr);
>> -   serial_out(UART_FCRVAL, _port->fcr);
>> +   serial_out(ns16550_getfcr(com_port), _port->fcr);
> 
> So I think you need to just use the original value here, and thus not
> support debug UART on your board (unless you want a Kconfig).

I don't want more Kconfig options.

[...]

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

[U-Boot] [PATCH V3 1/3] serial: 16550: Add getfcr accessor

[Marek Vasut]

Add function which allows fetching the default FCR register setting
from platform data for DM , while retaining old behavior for non-DM
by returning UART_FCRVAL.

Signed-off-by: Marek Vasut 
Cc: Tom Rini 
Cc: Simon Glass 
---
V2: If CONFIG_DM_SERIAL and DEBUG_UART are enabled, the ns16550_getfcr()
can be invoked with NULL plat data . Check for this case and return
the default UART_FCRVAL then.
V3: It turns out that if DEBUG_UART is defined, $port points directly to
hardware registers. Add additional ifdef to handle the case where
debug uart is enabled with DM_SERIAL correctly.
---
 drivers/serial/ns16550.c | 24 +---
 include/ns16550.h|  1 +
 2 files changed, 22 insertions(+), 3 deletions(-)

diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
index c6cb3eb..728f338 100644
--- a/drivers/serial/ns16550.c
+++ b/drivers/serial/ns16550.c
@@ -120,6 +120,17 @@ static int ns16550_readb(NS16550_t port, int offset)
return serial_in_shift(addr + plat->reg_offset, plat->reg_shift);
 }
 
+static u32 ns16550_getfcr(NS16550_t port)
+{
+#ifdef CONFIG_DEBUG_UART_NS16550
+   return UART_FCRVAL;
+#else
+   struct ns16550_platdata *plat = port->plat;
+
+   return plat->fcr;
+#endif
+}
+
 /* We can clean these up once everything is moved to driver model */
 #define serial_out(value, addr)\
ns16550_writeb(com_port, \
@@ -127,6 +138,11 @@ static int ns16550_readb(NS16550_t port, int offset)
 #define serial_in(addr) \
ns16550_readb(com_port, \
(unsigned char *)addr - (unsigned char *)com_port)
+#else
+static u32 ns16550_getfcr(NS16550_t port)
+{
+   return UART_FCRVAL;
+}
 #endif
 
 int ns16550_calc_divisor(NS16550_t port, int clock, int baudrate)
@@ -170,7 +186,7 @@ void NS16550_init(NS16550_t com_port, int baud_divisor)
serial_out(0x7, _port->mdr1);   /* mode select reset TL16C750*/
 #endif
serial_out(UART_MCRVAL, _port->mcr);
-   serial_out(UART_FCRVAL, _port->fcr);
+   serial_out(ns16550_getfcr(com_port), _port->fcr);
if (baud_divisor != -1)
NS16550_setbrg(com_port, baud_divisor);
 #if defined(CONFIG_OMAP) || \
@@ -191,7 +207,7 @@ void NS16550_reinit(NS16550_t com_port, int baud_divisor)
serial_out(CONFIG_SYS_NS16550_IER, _port->ier);
NS16550_setbrg(com_port, 0);
serial_out(UART_MCRVAL, _port->mcr);
-   serial_out(UART_FCRVAL, _port->fcr);
+   serial_out(ns16550_getfcr(com_port), _port->fcr);
NS16550_setbrg(com_port, baud_divisor);
 }
 #endif /* CONFIG_NS16550_MIN_FUNCTIONS */
@@ -262,7 +278,7 @@ static inline void _debug_uart_init(void)
CONFIG_BAUDRATE);
serial_dout(_port->ier, CONFIG_SYS_NS16550_IER);
serial_dout(_port->mcr, UART_MCRVAL);
-   serial_dout(_port->fcr, UART_FCRVAL);
+   serial_dout(_port->fcr, ns16550_getfcr(com_port));
 
serial_dout(_port->lcr, UART_LCR_BKSE | UART_LCRVAL);
serial_dout(_port->dll, baud_divisor & 0xff);
@@ -405,6 +421,8 @@ int ns16550_serial_ofdata_to_platdata(struct udevice *dev)
return -EINVAL;
}
 
+   plat->fcr = UART_FCRVAL;
+
return 0;
 }
 #endif
diff --git a/include/ns16550.h b/include/ns16550.h
index 1311f4c..45fd68b 100644
--- a/include/ns16550.h
+++ b/include/ns16550.h
@@ -57,6 +57,7 @@ struct ns16550_platdata {
int reg_shift;
int clock;
int reg_offset;
+   u32 fcr;
 };
 
 struct udevice;
-- 
2.7.0

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

Re: [U-Boot] [PATCH v2] mkimage: fit: spl: Add an optional static offset for external data

[Teddy Reed]

Thanks for the review Simon!

On Thu, Jun 9, 2016 at 6:03 PM, Simon Glass  wrote:
> Hi Teddy,
>
> On 5 June 2016 at 15:18, Teddy Reed  wrote:
>>
>> When building a FIT with external data (-E), an SPL may require absolute
>> positioning for executing the external firmware. To acheive this use the
>> (-p) switch, which will replace the amended 'data-offset' with 
>> 'data-position'
>> indicating the absolute position of external data.
>
> Why does SPL require that? Is it because it is at an external address,
> not inside the FIT?
>

Ah, it's more so the U-Boot proper that expects to have been built
with a TEXT_BASE known to it and the SPL. I'm trying to accommodate a
scenario where U-Boot proper executes after being verified by the SPL,
without needing arguments or relocation.

Given an execute-in-place without arguments U-Boot proper must know
TEXT_BASE at build time. This is clobbered when the external FIT is
generated, if the firmware is placed at a relative position. With a -p
your U_BOOT_TEXT_BASE remains constant between build and external FIT
generation.

>>
>> It is considered an error if the requested absolute position overlaps with 
>> the
>> initial data required for the compact FIT.
>>
>> Cc: Simon Glass 
>> ---
>>
>> Changes in v2:
>> - Add -p argument to mkimage.1
>> - Add -E, -p arguments to mkimage usage text
>> - Add notes for static position within uImage.FIT docs
>> - Rebased onto master
>>
>>  doc/mkimage.1 |  6 ++
>>  doc/uImage.FIT/source_file_format.txt |  4 
>>  tools/fit_image.c | 19 ++-
>>  tools/imagetool.h |  1 +
>>  tools/mkimage.c   | 13 +++--
>>  5 files changed, 40 insertions(+), 3 deletions(-)
>>
>> diff --git a/doc/mkimage.1 b/doc/mkimage.1
>> index 4b3a255..ffa7d60 100644
>> --- a/doc/mkimage.1
>> +++ b/doc/mkimage.1
>> @@ -152,6 +152,12 @@ verification. Typically the file here is the device 
>> tree binary used by
>>  CONFIG_OF_CONTROL in U-Boot.
>>
>>  .TP
>> +.BI "\-p [" "external position" "]"
>> +Place external data at a static external position. See \-E. Instead of 
>> writing
>> +a 'data-offset' property defining the offset from the end of the FIT, \-p 
>> will
>> +use 'data-position' as the absolute position from the base of the FIT.
>> +
>> +.TP
>>  .BI "\-r
>>  Specifies that keys used to sign the FIT are required. This means that they
>>  must be verified for the image to boot. Without this option, the 
>> verification
>> diff --git a/doc/uImage.FIT/source_file_format.txt 
>> b/doc/uImage.FIT/source_file_format.txt
>> index 3f54180..ee72740 100644
>> --- a/doc/uImage.FIT/source_file_format.txt
>> +++ b/doc/uImage.FIT/source_file_format.txt
>> @@ -282,6 +282,10 @@ In this case the 'data' property is omitted. Instead 
>> you can use:
>>  aligned to a 4-byte boundary.
>>- data-size : size of the data in bytes
>>
>> +The 'data-offset' property can be substituted with 'data-position', which
>> +defines a static position or address from the base of the FIT as the offset.
>> +A static position is helpful when booting U-Boot proper before performing
>> +relocation.
>
> This confuses me since it mentions a static address, but then
> references the base of the FIT, suggesting it is relative.
>
> Can you use the word 'absolute' instead of 'static'?
>

Absolutely! ;)

>>
>>  9) Examples
>>  ---
>> diff --git a/tools/fit_image.c b/tools/fit_image.c
>> index 0551572..76a6de4 100644
>> --- a/tools/fit_image.c
>> +++ b/tools/fit_image.c
>> @@ -416,7 +416,13 @@ static int fit_extract_data(struct image_tool_params 
>> *params, const char *fname)
>> ret = -EPERM;
>> goto err_munmap;
>> }
>> -   fdt_setprop_u32(fdt, node, "data-offset", buf_ptr);
>> +   if (params->external_offset > 0) {
>> +   /* An external offset positions the data absolutely. 
>> */
>> +   fdt_setprop_u32(fdt, node, "data-position",
>> +   params->external_offset + buf_ptr);
>> +   } else {
>> +   fdt_setprop_u32(fdt, node, "data-offset", buf_ptr);
>> +   }
>> fdt_setprop_u32(fdt, node, "data-size", len);
>>
>> buf_ptr += (len + 3) & ~3;
>> @@ -437,6 +443,17 @@ static int fit_extract_data(struct image_tool_params 
>> *params, const char *fname)
>> ret = -EIO;
>> goto err;
>> }
>> +
>> +   /* Check if an offset for the external data was set. */
>> +   if (params->external_offset > 0) {
>> +   if (params->external_offset < new_size) {
>> +   debug("External offset %x overlaps FIT length %x",
>> + params->external_offset, new_size);
>> +   ret = -EINVAL;
>> +   

Re: [U-Boot] [PATCH V2 1/3] serial: 16550: Add getfcr accessor

[Simon Glass]

Hi Marek,

On 9 June 2016 at 18:21, Marek Vasut  wrote:
> Add function which allows fetching the default FCR register setting
> from platform data for DM , while retaining old behavior for non-DM
> by returning UART_FCRVAL.
>
> Signed-off-by: Marek Vasut 
> Cc: Tom Rini 
> Cc: Simon Glass 
> ---
> V2: If CONFIG_DM_SERIAL and DEBUG_UART are enabled, the ns16550_getfcr()
> can be invoked with NULL plat data . Check for this case and return
> the default UART_FCRVAL then.
> ---
>  drivers/serial/ns16550.c | 20 +---
>  include/ns16550.h|  1 +
>  2 files changed, 18 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
> index c6cb3eb..b7ff3d7 100644
> --- a/drivers/serial/ns16550.c
> +++ b/drivers/serial/ns16550.c
> @@ -120,6 +120,13 @@ static int ns16550_readb(NS16550_t port, int offset)
> return serial_in_shift(addr + plat->reg_offset, plat->reg_shift);
>  }
>
> +static u32 ns16550_getfcr(NS16550_t port)
> +{
> +   struct ns16550_platdata *plat = port->plat;

port->plat does not exist when using the debug UART. The pointer
'port' points directly to the hardware...

> +
> +   return plat ? plat->fcr : UART_FCRVAL;
> +}
> +
>  /* We can clean these up once everything is moved to driver model */
>  #define serial_out(value, addr)\
> ns16550_writeb(com_port, \
> @@ -127,6 +134,11 @@ static int ns16550_readb(NS16550_t port, int offset)
>  #define serial_in(addr) \
> ns16550_readb(com_port, \
> (unsigned char *)addr - (unsigned char *)com_port)
> +#else
> +static u32 ns16550_getfcr(NS16550_t port)
> +{
> +   return UART_FCRVAL;
> +}
>  #endif
>
>  int ns16550_calc_divisor(NS16550_t port, int clock, int baudrate)
> @@ -170,7 +182,7 @@ void NS16550_init(NS16550_t com_port, int baud_divisor)
> serial_out(0x7, _port->mdr1);   /* mode select reset 
> TL16C750*/
>  #endif
> serial_out(UART_MCRVAL, _port->mcr);
> -   serial_out(UART_FCRVAL, _port->fcr);
> +   serial_out(ns16550_getfcr(com_port), _port->fcr);
> if (baud_divisor != -1)
> NS16550_setbrg(com_port, baud_divisor);
>  #if defined(CONFIG_OMAP) || \
> @@ -191,7 +203,7 @@ void NS16550_reinit(NS16550_t com_port, int baud_divisor)
> serial_out(CONFIG_SYS_NS16550_IER, _port->ier);
> NS16550_setbrg(com_port, 0);
> serial_out(UART_MCRVAL, _port->mcr);
> -   serial_out(UART_FCRVAL, _port->fcr);
> +   serial_out(ns16550_getfcr(com_port), _port->fcr);

So I think you need to just use the original value here, and thus not
support debug UART on your board (unless you want a Kconfig).

> NS16550_setbrg(com_port, baud_divisor);
>  }
>  #endif /* CONFIG_NS16550_MIN_FUNCTIONS */
> @@ -262,7 +274,7 @@ static inline void _debug_uart_init(void)
> CONFIG_BAUDRATE);
> serial_dout(_port->ier, CONFIG_SYS_NS16550_IER);
> serial_dout(_port->mcr, UART_MCRVAL);
> -   serial_dout(_port->fcr, UART_FCRVAL);
> +   serial_dout(_port->fcr, ns16550_getfcr(com_port));
>
> serial_dout(_port->lcr, UART_LCR_BKSE | UART_LCRVAL);
> serial_dout(_port->dll, baud_divisor & 0xff);
> @@ -405,6 +417,8 @@ int ns16550_serial_ofdata_to_platdata(struct udevice *dev)
> return -EINVAL;
> }
>
> +   plat->fcr = UART_FCRVAL;
> +
> return 0;
>  }
>  #endif
> diff --git a/include/ns16550.h b/include/ns16550.h
> index 1311f4c..45fd68b 100644
> --- a/include/ns16550.h
> +++ b/include/ns16550.h
> @@ -57,6 +57,7 @@ struct ns16550_platdata {
> int reg_shift;
> int clock;
> int reg_offset;
> +   u32 fcr;
>  };
>
>  struct udevice;
> --
> 2.7.0
>

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

Re: [U-Boot] [PATCH v2] sunxi: Support booting from SPI flash

[Siarhei Siamashka]

Hi Simon,

On Thu, 9 Jun 2016 17:36:10 -0700
Simon Glass  wrote:

> Hi,
> 
> On 7 June 2016 at 05:28, Siarhei Siamashka  
> wrote:
> > Allwinner devices support SPI flash as one of the possible
> > bootable media type. The SPI flash chip needs to be connected
> > to SPI0 pins (port C) to make this work. More information is
> > available at:
> >
> > https://linux-sunxi.org/Bootable_SPI_flash
> >
> > This patch adds the initial support for booting from SPI flash.
> > The existing SPI frameworks are not used in order to reduce the
> > SPL code size. Right now the SPL size grows by ~370 bytes when
> > CONFIG_SPL_SPI_SUNXI option is enabled.
> >
> > While there are no popular Allwinner devices with SPI flash at
> > the moment, testing can be done using a SPI flash module (it
> > can be bought for ~2$ on ebay) and jumper wires with the boards,
> > which expose relevant pins on the expansion header. The SPI flash
> > chips themselves are very cheap (some prices are even listed as
> > low as 4 cents) and should not cost much if somebody decides to
> > design a development board with an SPI flash chip soldered on
> > the PCB.
> >
> > Another nice feature of the SPI flash is that it can be safely
> > accessed in a device-independent way (since we know that the
> > boot ROM is already probing these pins during the boot time).
> > And if, for example, Olimex boards opted to use SPI flash instead
> > of EEPROM, then they would have been able to have U-Boot installed
> > in the SPI flash now and boot the rest of the system from the SATA
> > hard drive. Hopefully we may see new interesting Allwinner based
> > development boards in the future, now that the software support
> > for the SPI flash is in a better shape :-)
> >
> > Testing can be done by enabling the CONFIG_SPL_SPI_SUNXI option
> > in a board defconfig, then building U-Boot and finally flashing
> > the resulting u-boot-sunxi-with-spl.bin binary over USB OTG with
> > a help of the sunxi-fel tool:
> >
> >sunxi-fel spiflash-write 0 u-boot-sunxi-with-spl.bin
> >
> > The device needs to be switched into FEL (USB recovery) mode first.
> > The most suitable boards for testing are Orange Pi PC and Pine64.
> > Because these boards are cheap, have no built-in NAND/eMMC and
> > expose SPI0 pins on the Raspberry Pi compatible expansion header.
> > The A13-OLinuXino-Micro board also can be used.
> >
> > Signed-off-by: Siarhei Siamashka 
> > ---
> >
> > Changes in v2:
> >  - Add Kconfig option (CONFIG_SPL_SPI_SUNXI) and move the SPI flash
> >support code into a separate source file
> >  - Use CONFIG_SYS_SPI_U_BOOT_OFFS instead of the hardcoded constant
> >  - Deinitialize the SPI controller and undo pin muxing after the job
> >is done
> >  - Size reduction of the SPI transfer function
> >  - Add delay after each SPI transfer to ensure that the chip select
> >deassert timing requirements (tSHSL) are always satisfied
> >  - More comments in the code
> >
> >
> >  arch/arm/include/asm/arch-sunxi/gpio.h |   3 +
> >  arch/arm/mach-sunxi/board.c|   5 +
> >  common/spl/spl.c   |   4 +-
> >  drivers/mtd/spi/Kconfig|  12 ++
> >  drivers/mtd/spi/Makefile   |   1 +
> >  drivers/mtd/spi/sunxi_spi_spl.c| 283 
> > +
> >  include/configs/sunxi-common.h |   5 +
> >  7 files changed, 311 insertions(+), 2 deletions(-)
> >  create mode 100644 drivers/mtd/spi/sunxi_spi_spl.c  
> 
> Shouldn't this be a normal SPI driver? Then you could put this in
> common/spl/spl_spi.c.

This source file contains both a sunxi SPI controller support and a
basic SPI flash read functionality glued together for size reduction
purposes.

We are interested in implementing the "spl_spi_load_image()" function,
because this is what gets called when handling the BOOT_DEVICE_SPI
case.

The "drivers/mtd/spi" directory contains the "spi_spl_load.c" file,
which implements this particular function with the help of the generic
SPI flash support code from "spi_flash.c" and the generic SPI bus
support provided by the code from the "drivers/spi" directory.

What I'm doing in this patch is an implementation of a size reduced
sunxi-specific replacement for "spi_spl_load.c". But in U-Boot proper
(where the code size is not a problem anymore) we will need a real
sunxi SPI driver.

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

[U-Boot] [PATCH V2 1/3] serial: 16550: Add getfcr accessor

[Marek Vasut]

Add function which allows fetching the default FCR register setting
from platform data for DM , while retaining old behavior for non-DM
by returning UART_FCRVAL.

Signed-off-by: Marek Vasut 
Cc: Tom Rini 
Cc: Simon Glass 
---
V2: If CONFIG_DM_SERIAL and DEBUG_UART are enabled, the ns16550_getfcr()
can be invoked with NULL plat data . Check for this case and return
the default UART_FCRVAL then.
---
 drivers/serial/ns16550.c | 20 +---
 include/ns16550.h|  1 +
 2 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
index c6cb3eb..b7ff3d7 100644
--- a/drivers/serial/ns16550.c
+++ b/drivers/serial/ns16550.c
@@ -120,6 +120,13 @@ static int ns16550_readb(NS16550_t port, int offset)
return serial_in_shift(addr + plat->reg_offset, plat->reg_shift);
 }
 
+static u32 ns16550_getfcr(NS16550_t port)
+{
+   struct ns16550_platdata *plat = port->plat;
+
+   return plat ? plat->fcr : UART_FCRVAL;
+}
+
 /* We can clean these up once everything is moved to driver model */
 #define serial_out(value, addr)\
ns16550_writeb(com_port, \
@@ -127,6 +134,11 @@ static int ns16550_readb(NS16550_t port, int offset)
 #define serial_in(addr) \
ns16550_readb(com_port, \
(unsigned char *)addr - (unsigned char *)com_port)
+#else
+static u32 ns16550_getfcr(NS16550_t port)
+{
+   return UART_FCRVAL;
+}
 #endif
 
 int ns16550_calc_divisor(NS16550_t port, int clock, int baudrate)
@@ -170,7 +182,7 @@ void NS16550_init(NS16550_t com_port, int baud_divisor)
serial_out(0x7, _port->mdr1);   /* mode select reset TL16C750*/
 #endif
serial_out(UART_MCRVAL, _port->mcr);
-   serial_out(UART_FCRVAL, _port->fcr);
+   serial_out(ns16550_getfcr(com_port), _port->fcr);
if (baud_divisor != -1)
NS16550_setbrg(com_port, baud_divisor);
 #if defined(CONFIG_OMAP) || \
@@ -191,7 +203,7 @@ void NS16550_reinit(NS16550_t com_port, int baud_divisor)
serial_out(CONFIG_SYS_NS16550_IER, _port->ier);
NS16550_setbrg(com_port, 0);
serial_out(UART_MCRVAL, _port->mcr);
-   serial_out(UART_FCRVAL, _port->fcr);
+   serial_out(ns16550_getfcr(com_port), _port->fcr);
NS16550_setbrg(com_port, baud_divisor);
 }
 #endif /* CONFIG_NS16550_MIN_FUNCTIONS */
@@ -262,7 +274,7 @@ static inline void _debug_uart_init(void)
CONFIG_BAUDRATE);
serial_dout(_port->ier, CONFIG_SYS_NS16550_IER);
serial_dout(_port->mcr, UART_MCRVAL);
-   serial_dout(_port->fcr, UART_FCRVAL);
+   serial_dout(_port->fcr, ns16550_getfcr(com_port));
 
serial_dout(_port->lcr, UART_LCR_BKSE | UART_LCRVAL);
serial_dout(_port->dll, baud_divisor & 0xff);
@@ -405,6 +417,8 @@ int ns16550_serial_ofdata_to_platdata(struct udevice *dev)
return -EINVAL;
}
 
+   plat->fcr = UART_FCRVAL;
+
return 0;
 }
 #endif
diff --git a/include/ns16550.h b/include/ns16550.h
index 1311f4c..45fd68b 100644
--- a/include/ns16550.h
+++ b/include/ns16550.h
@@ -57,6 +57,7 @@ struct ns16550_platdata {
int reg_shift;
int clock;
int reg_offset;
+   u32 fcr;
 };
 
 struct udevice;
-- 
2.7.0

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

Re: [U-Boot] [PATCH 1/3] serial: 16550: Add getfcr accessor

[Simon Glass]

Hi Marek,

On 9 June 2016 at 17:54, Marek Vasut  wrote:
> On 06/10/2016 02:34 AM, Simon Glass wrote:
>> Hi Marek,
>
> Hi,
>
>> On 26 May 2016 at 12:39, Marek Vasut  wrote:
>>> Add function which allows fetching the default FCR register setting
>>> from platform data for DM , while retaining old behavior for non-DM
>>> by returning UART_FCRVAL.
>>>
>>> Signed-off-by: Marek Vasut 
>>> Cc: Tom Rini 
>>> Cc: Simon Glass 
>>> ---
>>>  drivers/serial/ns16550.c | 20 +---
>>>  include/ns16550.h|  1 +
>>>  2 files changed, 18 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
>>> index c6cb3eb..b39ce02 100644
>>> --- a/drivers/serial/ns16550.c
>>> +++ b/drivers/serial/ns16550.c
>>> @@ -120,6 +120,13 @@ static int ns16550_readb(NS16550_t port, int offset)
>>> return serial_in_shift(addr + plat->reg_offset, plat->reg_shift);
>>>  }
>>>
>>> +static u32 ns16550_getfcr(NS16550_t port)
>>> +{
>>> +   struct ns16550_platdata *plat = port->plat;
>>> +
>>> +   return plat->fcr;
>>> +}
>>> +
>>>  /* We can clean these up once everything is moved to driver model */
>>>  #define serial_out(value, addr)\
>>> ns16550_writeb(com_port, \
>>> @@ -127,6 +134,11 @@ static int ns16550_readb(NS16550_t port, int offset)
>>>  #define serial_in(addr) \
>>> ns16550_readb(com_port, \
>>> (unsigned char *)addr - (unsigned char *)com_port)
>>> +#else
>>> +static u32 ns16550_getfcr(NS16550_t port)
>>> +{
>>> +   return UART_FCRVAL;
>>> +}
>>>  #endif
>>>
>>>  int ns16550_calc_divisor(NS16550_t port, int clock, int baudrate)
>>> @@ -170,7 +182,7 @@ void NS16550_init(NS16550_t com_port, int baud_divisor)
>>> serial_out(0x7, _port->mdr1);   /* mode select reset 
>>> TL16C750*/
>>>  #endif
>>> serial_out(UART_MCRVAL, _port->mcr);
>>> -   serial_out(UART_FCRVAL, _port->fcr);
>>> +   serial_out(ns16550_getfcr(com_port), _port->fcr);
>>> if (baud_divisor != -1)
>>> NS16550_setbrg(com_port, baud_divisor);
>>>  #if defined(CONFIG_OMAP) || \
>>> @@ -191,7 +203,7 @@ void NS16550_reinit(NS16550_t com_port, int 
>>> baud_divisor)
>>> serial_out(CONFIG_SYS_NS16550_IER, _port->ier);
>>> NS16550_setbrg(com_port, 0);
>>> serial_out(UART_MCRVAL, _port->mcr);
>>> -   serial_out(UART_FCRVAL, _port->fcr);
>>> +   serial_out(ns16550_getfcr(com_port), _port->fcr);
>>> NS16550_setbrg(com_port, baud_divisor);
>>>  }
>>>  #endif /* CONFIG_NS16550_MIN_FUNCTIONS */
>>> @@ -262,7 +274,7 @@ static inline void _debug_uart_init(void)
>>> CONFIG_BAUDRATE);
>>> serial_dout(_port->ier, CONFIG_SYS_NS16550_IER);
>>> serial_dout(_port->mcr, UART_MCRVAL);
>>> -   serial_dout(_port->fcr, UART_FCRVAL);
>>> +   serial_dout(_port->fcr, ns16550_getfcr(com_port));
>>
>> The debug UART does not have platdata, so I don't think this will
>> work.
>
> Hrm, true. If you have DM_SERIAL enabled and debug uart enabled,
> this will likely fail.

Right.

>
>> For the debug UART perhaps you can use the default value. If
>> not, then I think the only option is a new debug UART Kconfig.
>
> I don't use the debug uart, so I don't need the Kconfig option.

OK, then you could pass in the default value.

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

Re: [U-Boot] [PATCH] mmc: Tinification of the mmc code

[Simon Glass]

Hi Marek,

On 9 June 2016 at 18:12, Marek Vasut  wrote:
> On 06/10/2016 02:34 AM, Simon Glass wrote:
>> Hi Marek,
>
> Hi!
>
>> On 26 May 2016 at 12:41, Marek Vasut  wrote:
>>> Add new configuration option CONFIG_MMC_TINY which strips away all
>>> memory allocation within the MMC code and code for handling multiple
>>> cards. This allows extremely space-constrained SPL code use the MMC
>>> framework.
>>>
>>> Signed-off-by: Marek Vasut 
>>> Cc: Tom Rini 
>>> Cc: Simon Glass 
>>> ---
>>>  common/spl/spl_mmc.c |  4 
>>>  drivers/mmc/Makefile |  2 ++
>>>  drivers/mmc/mmc.c| 59 
>>> +++-
>>>  include/mmc.h|  1 +
>>>  4 files changed, 65 insertions(+), 1 deletion(-)
>>
>> Can CONFIG_MMC_TINY be a Kconfig? Also I suggest CONFIG_SPL_MMC_TINY.
>
> It can, but how do I assure it's enabled only for SPL build ?

depends on SPL

and in the code:

#if CONFIG_IS_ENABLED(MMC_TINY)

will do it.

>
>>> diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
>>> index ae42221..51f0f24 100644
>>> --- a/common/spl/spl_mmc.c
>>> +++ b/common/spl/spl_mmc.c
>>> @@ -300,7 +300,11 @@ int spl_mmc_load_image(u32 boot_device)
>>> if (part == 7)
>>> part = 0;
>>>
>>> +#ifdef CONFIG_MMC_TINY
>>
>> if (CONFIG_IS_ENABLED(MMC_TINY))
>>
>> to avoid #ifdef
>
> The compiler complains about missing symbols blk_dselect_hwpart() and
> such, so I will opt for the ifdef .

That's odd. It should not care about things which are not compiled in.

>
>>> +   err = mmc_switch_part(mmc, part);
>>> +#else
>>> err = blk_dselect_hwpart(mmc_get_blk_desc(mmc), 
>>> part);
>>> +#endif
>>> if (err) {
>>>  #ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
>>> puts("spl: mmc partition switch failed\n");
>>> diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
>>> index 3da4817..4d986cb 100644
>>> --- a/drivers/mmc/Makefile
>>> +++ b/drivers/mmc/Makefile
>>> @@ -10,8 +10,10 @@ obj-$(CONFIG_GENERIC_MMC) += mmc-uclass.o
>>>  endif
>>>
>>>  ifndef CONFIG_BLK
>>> +ifndef CONFIG_MMC_TINY
>>>  obj-$(CONFIG_GENERIC_MMC) += mmc_legacy.o
>>>  endif
>>> +endif
>>>
>>>  obj-$(CONFIG_ARM_PL180_MMCI) += arm_pl180_mmci.o
>>>  obj-$(CONFIG_ATMEL_SDHCI) += atmel_sdhci.o
>>> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
>>> index d687345..1f240ed 100644
>>> --- a/drivers/mmc/mmc.c
>>> +++ b/drivers/mmc/mmc.c
>>> @@ -21,6 +21,29 @@
>>>  #include 
>>>  #include "mmc_private.h"
>>>
>>> +#if defined(CONFIG_MMC_TINY)
>>> +static struct mmc mmc_static;
>>> +struct mmc *find_mmc_device(int dev_num)
>>> +{
>>> +   return _static;
>>> +}
>>> +
>>> +void mmc_do_preinit(void)
>>> +{
>>> +   struct mmc *m = _static;
>>> +#ifdef CONFIG_FSL_ESDHC_ADAPTER_IDENT
>>> +   mmc_set_preinit(m, 1);
>>> +#endif
>>> +   if (m->preinit)
>>> +   mmc_start_init(m);
>>> +}
>>> +
>>> +struct blk_desc *mmc_get_blk_desc(struct mmc *mmc)
>>> +{
>>> +   return >block_dev;
>>> +}
>>> +#endif
>>> +
>>>  __weak int board_mmc_getwp(struct mmc *mmc)
>>>  {
>>> return -1;
>>> @@ -238,7 +261,11 @@ static ulong mmc_bread(struct blk_desc *block_dev, 
>>> lbaint_t start,
>>> if (!mmc)
>>> return 0;
>>>
>>> +#ifdef CONFIG_MMC_TINY
>>> +   err = mmc_switch_part(mmc, block_dev->hwpart);
>>> +#else
>>> err = blk_dselect_hwpart(block_dev, block_dev->hwpart);
>>> +#endif
>>> if (err < 0)
>>> return 0;
>>>
>>> @@ -568,7 +595,7 @@ static int mmc_set_capacity(struct mmc *mmc, int 
>>> part_num)
>>> return 0;
>>>  }
>>>
>>> -static int mmc_switch_part(struct mmc *mmc, unsigned int part_num)
>>> +int mmc_switch_part(struct mmc *mmc, unsigned int part_num)
>>>  {
>>> int ret;
>>>
>>> @@ -1585,6 +1612,34 @@ int mmc_unbind(struct udevice *dev)
>>> return 0;
>>>  }
>>>
>>> +#elif defined(CONFIG_MMC_TINY)
>>> +static struct mmc mmc_static = {
>>> +   .dsr_imp= 0,
>>> +   .dsr= 0x,
>>> +   .block_dev = {
>>> +   .if_type= IF_TYPE_MMC,
>>> +   .removable  = 1,
>>> +   .devnum = 0,
>>> +   .block_read = mmc_bread,
>>> +   .block_write= mmc_bwrite,
>>> +   .block_erase= mmc_berase,
>>> +   .part_type  = 0,
>>> +   },
>>> +};
>>> +
>>> +struct mmc *mmc_create(const struct mmc_config *cfg, void *priv)
>>> +{
>>> +   struct mmc *mmc = _static;
>>> +
>>> +   mmc->cfg = cfg;
>>> +   mmc->priv = priv;
>>> +
>>> +   return mmc;
>>> +}
>>> +
>>> +void mmc_destroy(struct mmc *mmc)
>>> +{
>>> +}
>>>  #else
>>>  struct mmc *mmc_create(const struct mmc_config *cfg, void *priv)
>>>  {
>>> @@ -1834,8 +1889,10 @@ int mmc_initialize(bd_t *bis)
>>>

Re: [U-Boot] [PATCH] mmc: Tinification of the mmc code

[Marek Vasut]

On 06/10/2016 02:34 AM, Simon Glass wrote:
> Hi Marek,

Hi!

> On 26 May 2016 at 12:41, Marek Vasut  wrote:
>> Add new configuration option CONFIG_MMC_TINY which strips away all
>> memory allocation within the MMC code and code for handling multiple
>> cards. This allows extremely space-constrained SPL code use the MMC
>> framework.
>>
>> Signed-off-by: Marek Vasut 
>> Cc: Tom Rini 
>> Cc: Simon Glass 
>> ---
>>  common/spl/spl_mmc.c |  4 
>>  drivers/mmc/Makefile |  2 ++
>>  drivers/mmc/mmc.c| 59 
>> +++-
>>  include/mmc.h|  1 +
>>  4 files changed, 65 insertions(+), 1 deletion(-)
> 
> Can CONFIG_MMC_TINY be a Kconfig? Also I suggest CONFIG_SPL_MMC_TINY.

It can, but how do I assure it's enabled only for SPL build ?

>> diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
>> index ae42221..51f0f24 100644
>> --- a/common/spl/spl_mmc.c
>> +++ b/common/spl/spl_mmc.c
>> @@ -300,7 +300,11 @@ int spl_mmc_load_image(u32 boot_device)
>> if (part == 7)
>> part = 0;
>>
>> +#ifdef CONFIG_MMC_TINY
> 
> if (CONFIG_IS_ENABLED(MMC_TINY))
> 
> to avoid #ifdef

The compiler complains about missing symbols blk_dselect_hwpart() and
such, so I will opt for the ifdef .

>> +   err = mmc_switch_part(mmc, part);
>> +#else
>> err = blk_dselect_hwpart(mmc_get_blk_desc(mmc), 
>> part);
>> +#endif
>> if (err) {
>>  #ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
>> puts("spl: mmc partition switch failed\n");
>> diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
>> index 3da4817..4d986cb 100644
>> --- a/drivers/mmc/Makefile
>> +++ b/drivers/mmc/Makefile
>> @@ -10,8 +10,10 @@ obj-$(CONFIG_GENERIC_MMC) += mmc-uclass.o
>>  endif
>>
>>  ifndef CONFIG_BLK
>> +ifndef CONFIG_MMC_TINY
>>  obj-$(CONFIG_GENERIC_MMC) += mmc_legacy.o
>>  endif
>> +endif
>>
>>  obj-$(CONFIG_ARM_PL180_MMCI) += arm_pl180_mmci.o
>>  obj-$(CONFIG_ATMEL_SDHCI) += atmel_sdhci.o
>> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
>> index d687345..1f240ed 100644
>> --- a/drivers/mmc/mmc.c
>> +++ b/drivers/mmc/mmc.c
>> @@ -21,6 +21,29 @@
>>  #include 
>>  #include "mmc_private.h"
>>
>> +#if defined(CONFIG_MMC_TINY)
>> +static struct mmc mmc_static;
>> +struct mmc *find_mmc_device(int dev_num)
>> +{
>> +   return _static;
>> +}
>> +
>> +void mmc_do_preinit(void)
>> +{
>> +   struct mmc *m = _static;
>> +#ifdef CONFIG_FSL_ESDHC_ADAPTER_IDENT
>> +   mmc_set_preinit(m, 1);
>> +#endif
>> +   if (m->preinit)
>> +   mmc_start_init(m);
>> +}
>> +
>> +struct blk_desc *mmc_get_blk_desc(struct mmc *mmc)
>> +{
>> +   return >block_dev;
>> +}
>> +#endif
>> +
>>  __weak int board_mmc_getwp(struct mmc *mmc)
>>  {
>> return -1;
>> @@ -238,7 +261,11 @@ static ulong mmc_bread(struct blk_desc *block_dev, 
>> lbaint_t start,
>> if (!mmc)
>> return 0;
>>
>> +#ifdef CONFIG_MMC_TINY
>> +   err = mmc_switch_part(mmc, block_dev->hwpart);
>> +#else
>> err = blk_dselect_hwpart(block_dev, block_dev->hwpart);
>> +#endif
>> if (err < 0)
>> return 0;
>>
>> @@ -568,7 +595,7 @@ static int mmc_set_capacity(struct mmc *mmc, int 
>> part_num)
>> return 0;
>>  }
>>
>> -static int mmc_switch_part(struct mmc *mmc, unsigned int part_num)
>> +int mmc_switch_part(struct mmc *mmc, unsigned int part_num)
>>  {
>> int ret;
>>
>> @@ -1585,6 +1612,34 @@ int mmc_unbind(struct udevice *dev)
>> return 0;
>>  }
>>
>> +#elif defined(CONFIG_MMC_TINY)
>> +static struct mmc mmc_static = {
>> +   .dsr_imp= 0,
>> +   .dsr= 0x,
>> +   .block_dev = {
>> +   .if_type= IF_TYPE_MMC,
>> +   .removable  = 1,
>> +   .devnum = 0,
>> +   .block_read = mmc_bread,
>> +   .block_write= mmc_bwrite,
>> +   .block_erase= mmc_berase,
>> +   .part_type  = 0,
>> +   },
>> +};
>> +
>> +struct mmc *mmc_create(const struct mmc_config *cfg, void *priv)
>> +{
>> +   struct mmc *mmc = _static;
>> +
>> +   mmc->cfg = cfg;
>> +   mmc->priv = priv;
>> +
>> +   return mmc;
>> +}
>> +
>> +void mmc_destroy(struct mmc *mmc)
>> +{
>> +}
>>  #else
>>  struct mmc *mmc_create(const struct mmc_config *cfg, void *priv)
>>  {
>> @@ -1834,8 +1889,10 @@ int mmc_initialize(bd_t *bis)
>> initialized = 1;
>>
>>  #ifndef CONFIG_BLK
>> +#ifndef CONFIG_MMC_TINY
>> mmc_list_init();
>>  #endif
>> +#endif
>> ret = mmc_probe(bis);
>> if (ret)
>> return ret;
>> diff --git a/include/mmc.h b/include/mmc.h
>> index a5c6573..08a59c2 100644
>> --- a/include/mmc.h
>> +++ b/include/mmc.h
>> @@ -444,6 +444,7 @@ struct mmc 

Re: [U-Boot] [RFC][PATCH] arm: rk: Drop SYS_MALLOC_F and SPL_SYS_MALLOC_SIMPLE

[Marek Vasut]

On 06/10/2016 02:34 AM, Simon Glass wrote:
> Hi Marek,

Hi!

> On 8 June 2016 at 07:18, Marek Vasut  wrote:
>> On 06/08/2016 06:44 AM, Simon Glass wrote:
>>> Hi Marek,
>>>
>>> On 7 June 2016 at 20:02, Marek Vasut  wrote:
 On 06/08/2016 04:43 AM, Simon Glass wrote:
> Hi Marek,

 Hi!

> On 25 May 2016 at 05:26, Marek Vasut  wrote:
>> On 05/25/2016 05:29 AM, Simon Glass wrote:
>>> Hi Marek,
>>>
>>> On 24 May 2016 at 18:15, Marek Vasut  wrote:
 Both SYS_MALLOC_F and SPL_SYS_MALLOC_SIMPLE are generic config options,
 drop them from the rockchip-specific Kconfig file.

 Signed-off-by: Marek Vasut 
 Cc: Tom Rini 
 Cc: Simon Glass 
 ---
  arch/arm/mach-rockchip/Kconfig | 6 --
  1 file changed, 6 deletions(-)

 diff --git a/arch/arm/mach-rockchip/Kconfig 
 b/arch/arm/mach-rockchip/Kconfig
 index d3bddb7..5f6046a 100644
 --- a/arch/arm/mach-rockchip/Kconfig
 +++ b/arch/arm/mach-rockchip/Kconfig
 @@ -17,12 +17,6 @@ config ROCKCHIP_RK3036
   and video codec support. Peripherals include Gigabit 
 Ethernet,
   USB2 host and OTG, SDIO, I2S, UART, SPI, I2C and PWMs.

 -config SYS_MALLOC_F
 -   default y
 -
 -config SPL_SYS_MALLOC_SIMPLE
 -   default y
 -
  config SPL_DM
 default y

 --
 2.7.0

>>>
>>> Will these still be enabled some other way?
>>
>> That's why it's RFC, I believe the rockchip platforms would need to add
>> those to their defconfig, right ?
>
> Well, Rockchip boards cannot work without these, which is why they 
> default to y.

 I understand that, but these Kconfig options are generic, so they
 shouldn't be defined in the mach-rockchip/Kconfig file, but in some
 generic Kconfig file and then selected by ARCH_ROCKCHIP symbol or in
 some defconfig , right ?
>>>
>>> They are not being defined, just their default value is being set.
>>
>> Checking with git grep, they are defined in the top-level Kconfig.
>> I recall when I tried using those on mips, it complained about the
>> entries in mach-rockchip though. So why are the defaults selected
>> this way instead of using "select" in ARCH_ROCKCHIP symbol ? Isn't
>> that how it's usually done ?
> 
> That's odd, because these are inside an 'if ARCH_ROCKCHIP' clause. But
> I'm fine with moving to 'select' for these if that is better. It is
> unlikely anyone would want to disable these. But as it stands, your
> patch breaks things :-)

OK, I am not really sure about this patch and I have no real use for it,
so let's drop it for now.

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

Re: [U-Boot] [PATCH 1/3] serial: 16550: Add getfcr accessor

[Marek Vasut]

On 06/10/2016 02:34 AM, Simon Glass wrote:
> Hi Marek,

Hi,

> On 26 May 2016 at 12:39, Marek Vasut  wrote:
>> Add function which allows fetching the default FCR register setting
>> from platform data for DM , while retaining old behavior for non-DM
>> by returning UART_FCRVAL.
>>
>> Signed-off-by: Marek Vasut 
>> Cc: Tom Rini 
>> Cc: Simon Glass 
>> ---
>>  drivers/serial/ns16550.c | 20 +---
>>  include/ns16550.h|  1 +
>>  2 files changed, 18 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
>> index c6cb3eb..b39ce02 100644
>> --- a/drivers/serial/ns16550.c
>> +++ b/drivers/serial/ns16550.c
>> @@ -120,6 +120,13 @@ static int ns16550_readb(NS16550_t port, int offset)
>> return serial_in_shift(addr + plat->reg_offset, plat->reg_shift);
>>  }
>>
>> +static u32 ns16550_getfcr(NS16550_t port)
>> +{
>> +   struct ns16550_platdata *plat = port->plat;
>> +
>> +   return plat->fcr;
>> +}
>> +
>>  /* We can clean these up once everything is moved to driver model */
>>  #define serial_out(value, addr)\
>> ns16550_writeb(com_port, \
>> @@ -127,6 +134,11 @@ static int ns16550_readb(NS16550_t port, int offset)
>>  #define serial_in(addr) \
>> ns16550_readb(com_port, \
>> (unsigned char *)addr - (unsigned char *)com_port)
>> +#else
>> +static u32 ns16550_getfcr(NS16550_t port)
>> +{
>> +   return UART_FCRVAL;
>> +}
>>  #endif
>>
>>  int ns16550_calc_divisor(NS16550_t port, int clock, int baudrate)
>> @@ -170,7 +182,7 @@ void NS16550_init(NS16550_t com_port, int baud_divisor)
>> serial_out(0x7, _port->mdr1);   /* mode select reset 
>> TL16C750*/
>>  #endif
>> serial_out(UART_MCRVAL, _port->mcr);
>> -   serial_out(UART_FCRVAL, _port->fcr);
>> +   serial_out(ns16550_getfcr(com_port), _port->fcr);
>> if (baud_divisor != -1)
>> NS16550_setbrg(com_port, baud_divisor);
>>  #if defined(CONFIG_OMAP) || \
>> @@ -191,7 +203,7 @@ void NS16550_reinit(NS16550_t com_port, int baud_divisor)
>> serial_out(CONFIG_SYS_NS16550_IER, _port->ier);
>> NS16550_setbrg(com_port, 0);
>> serial_out(UART_MCRVAL, _port->mcr);
>> -   serial_out(UART_FCRVAL, _port->fcr);
>> +   serial_out(ns16550_getfcr(com_port), _port->fcr);
>> NS16550_setbrg(com_port, baud_divisor);
>>  }
>>  #endif /* CONFIG_NS16550_MIN_FUNCTIONS */
>> @@ -262,7 +274,7 @@ static inline void _debug_uart_init(void)
>> CONFIG_BAUDRATE);
>> serial_dout(_port->ier, CONFIG_SYS_NS16550_IER);
>> serial_dout(_port->mcr, UART_MCRVAL);
>> -   serial_dout(_port->fcr, UART_FCRVAL);
>> +   serial_dout(_port->fcr, ns16550_getfcr(com_port));
> 
> The debug UART does not have platdata, so I don't think this will
> work.

Hrm, true. If you have DM_SERIAL enabled and debug uart enabled,
this will likely fail.

> For the debug UART perhaps you can use the default value. If
> not, then I think the only option is a new debug UART Kconfig.

I don't use the debug uart, so I don't need the Kconfig option.


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

Re: [U-Boot] [PATCH v2] Make FIT support really optional

[Simon Glass]

Hi,

On 8 June 2016 at 05:17, Tom Rini  wrote:
> On Wed, Jun 08, 2016 at 07:47:12AM +0200, Thomas Petazzoni wrote:
>> Hello,
>>
>> On Tue, 7 Jun 2016 21:18:17 -0300 (BRT), Carlos Santos wrote:
>>
>> > There is already a configuration that makes FIT optional (CONFIG_FIT)
>> > but it is partially broken because it does not really remove
>> > FIT-related functionality from mkimage. That's the reason why it was
>> > not possible to disable FIT in the Buildroot package. My patch aims
>> > to fix that defect.
>>
>> Ah, indeed, I forgot that the CONFIG_FIT option already existed. In
>> this case, I agree that it should either exist and work, or not exist.
>
> Here is the problem with host tools living along side configurable
> binaries and sharing code.  With respect to mkimage, FIT support is
> non-optional.  The only reason that FIT signature stuff is optional is
> that it introduces too high of a set of dependencies for everyone else
> to have installed to even compile mkimage which is in turn required by
> the vast majority of targets.  If the failing message that we couldn't
> run dtc is not clear enoguh, I am happy to take a patch to make the
> problem and solution clearer.

I agree. I would prefer to always support signatures in mkimage, if we can.

The only purpose of turning off FIT in U-Boot is to reduce code size.
But IMO it should be enabled by default in U-Boot. It is suppose to be
the official format...

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

Re: [U-Boot] [PATCH] verified-boot: Minimal support for booting U-Boot proper from SPL

[Simon Glass]

Hi Teddy,

On 28 May 2016 at 18:58, Teddy Reed  wrote:
> This allows a board to configure verified boot within the SPL using
> a FIT or FIT with external data. It also allows the SPL to perform
> signature verification without needing relocation.
>
> The board configuration will need to add the following feature defines:
> CONFIG_SPL_CRYPTO_SUPPORT
> CONFIG_SPL_HASH_SUPPORT
> CONFIG_SPL_SHA256
>
> In this example, SHA256 is the only selected hashing algorithm.
>
> And the following booleans:
> CONFIG_SPL=y
> CONFIG_SPL_DM=y
> CONFIG_SPL_LOAD_FIT=y
> CONFIG_SPL_FIT=y
> CONFIG_SPL_OF_CONTROL=y
> CONFIG_SPL_OF_LIBFDT=y
> CONFIG_SPL_FIT_SIGNATURE=y
>
> Signed-off-by: Teddy Reed 
> Cc: Simon Glass 
> Cc: Andreas Dannenberg 
> ---
>  Kconfig | 11 +++
>  common/Makefile |  1 +
>  drivers/Makefile|  1 +
>  drivers/crypto/rsa_mod_exp/mod_exp_sw.c |  1 +
>  lib/Makefile|  9 -
>  lib/rsa/Kconfig |  4 
>  lib/rsa/Makefile|  2 +-
>  7 files changed, 23 insertions(+), 6 deletions(-)
>

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

Re: [U-Boot] [PATCH v2] mkimage: fit: spl: Add an optional static offset for external data

[Simon Glass]

Hi Teddy,

On 5 June 2016 at 15:18, Teddy Reed  wrote:
>
> When building a FIT with external data (-E), an SPL may require absolute
> positioning for executing the external firmware. To acheive this use the
> (-p) switch, which will replace the amended 'data-offset' with 'data-position'
> indicating the absolute position of external data.

Why does SPL require that? Is it because it is at an external address,
not inside the FIT?

>
> It is considered an error if the requested absolute position overlaps with the
> initial data required for the compact FIT.
>
> Cc: Simon Glass 
> ---
>
> Changes in v2:
> - Add -p argument to mkimage.1
> - Add -E, -p arguments to mkimage usage text
> - Add notes for static position within uImage.FIT docs
> - Rebased onto master
>
>  doc/mkimage.1 |  6 ++
>  doc/uImage.FIT/source_file_format.txt |  4 
>  tools/fit_image.c | 19 ++-
>  tools/imagetool.h |  1 +
>  tools/mkimage.c   | 13 +++--
>  5 files changed, 40 insertions(+), 3 deletions(-)
>
> diff --git a/doc/mkimage.1 b/doc/mkimage.1
> index 4b3a255..ffa7d60 100644
> --- a/doc/mkimage.1
> +++ b/doc/mkimage.1
> @@ -152,6 +152,12 @@ verification. Typically the file here is the device tree 
> binary used by
>  CONFIG_OF_CONTROL in U-Boot.
>
>  .TP
> +.BI "\-p [" "external position" "]"
> +Place external data at a static external position. See \-E. Instead of 
> writing
> +a 'data-offset' property defining the offset from the end of the FIT, \-p 
> will
> +use 'data-position' as the absolute position from the base of the FIT.
> +
> +.TP
>  .BI "\-r
>  Specifies that keys used to sign the FIT are required. This means that they
>  must be verified for the image to boot. Without this option, the verification
> diff --git a/doc/uImage.FIT/source_file_format.txt 
> b/doc/uImage.FIT/source_file_format.txt
> index 3f54180..ee72740 100644
> --- a/doc/uImage.FIT/source_file_format.txt
> +++ b/doc/uImage.FIT/source_file_format.txt
> @@ -282,6 +282,10 @@ In this case the 'data' property is omitted. Instead you 
> can use:
>  aligned to a 4-byte boundary.
>- data-size : size of the data in bytes
>
> +The 'data-offset' property can be substituted with 'data-position', which
> +defines a static position or address from the base of the FIT as the offset.
> +A static position is helpful when booting U-Boot proper before performing
> +relocation.

This confuses me since it mentions a static address, but then
references the base of the FIT, suggesting it is relative.

Can you use the word 'absolute' instead of 'static'?

>
>  9) Examples
>  ---
> diff --git a/tools/fit_image.c b/tools/fit_image.c
> index 0551572..76a6de4 100644
> --- a/tools/fit_image.c
> +++ b/tools/fit_image.c
> @@ -416,7 +416,13 @@ static int fit_extract_data(struct image_tool_params 
> *params, const char *fname)
> ret = -EPERM;
> goto err_munmap;
> }
> -   fdt_setprop_u32(fdt, node, "data-offset", buf_ptr);
> +   if (params->external_offset > 0) {
> +   /* An external offset positions the data absolutely. 
> */
> +   fdt_setprop_u32(fdt, node, "data-position",
> +   params->external_offset + buf_ptr);
> +   } else {
> +   fdt_setprop_u32(fdt, node, "data-offset", buf_ptr);
> +   }
> fdt_setprop_u32(fdt, node, "data-size", len);
>
> buf_ptr += (len + 3) & ~3;
> @@ -437,6 +443,17 @@ static int fit_extract_data(struct image_tool_params 
> *params, const char *fname)
> ret = -EIO;
> goto err;
> }
> +
> +   /* Check if an offset for the external data was set. */
> +   if (params->external_offset > 0) {
> +   if (params->external_offset < new_size) {
> +   debug("External offset %x overlaps FIT length %x",
> + params->external_offset, new_size);
> +   ret = -EINVAL;
> +   goto err;
> +   }
> +   new_size = params->external_offset;
> +   }
> if (lseek(fd, new_size, SEEK_SET) < 0) {
> debug("%s: Failed to seek to end of file: %s\n", __func__,
>   strerror(errno));
> diff --git a/tools/imagetool.h b/tools/imagetool.h
> index a3ed0f4..1f2161c 100644
> --- a/tools/imagetool.h
> +++ b/tools/imagetool.h
> @@ -74,6 +74,7 @@ struct image_tool_params {
> struct content_info *content_tail;
> bool external_data; /* Store data outside the FIT */
> bool quiet; /* Don't output text in normal operation */
> +   unsigned int external_offset;   /* Add padding to external data */
>  };
>
>  /*
> diff --git a/tools/mkimage.c 

Re: [U-Boot] [PATCH v2] serial: atmel_usart: Add device tree support

[Simon Glass]

On 31 May 2016 at 18:36, Wenyou Yang  wrote:
> Add device tree support.
>
> Signed-off-by: Wenyou Yang 
> ---
>
> Changes in v2:
>  - Add conditional for device tree support.
>
>  drivers/serial/atmel_usart.c | 19 +++
>  1 file changed, 19 insertions(+)

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

Re: [U-Boot] [PATCH v2] sunxi: Support booting from SPI flash

[Simon Glass]

Hi,

On 7 June 2016 at 05:28, Siarhei Siamashka  wrote:
> Allwinner devices support SPI flash as one of the possible
> bootable media type. The SPI flash chip needs to be connected
> to SPI0 pins (port C) to make this work. More information is
> available at:
>
> https://linux-sunxi.org/Bootable_SPI_flash
>
> This patch adds the initial support for booting from SPI flash.
> The existing SPI frameworks are not used in order to reduce the
> SPL code size. Right now the SPL size grows by ~370 bytes when
> CONFIG_SPL_SPI_SUNXI option is enabled.
>
> While there are no popular Allwinner devices with SPI flash at
> the moment, testing can be done using a SPI flash module (it
> can be bought for ~2$ on ebay) and jumper wires with the boards,
> which expose relevant pins on the expansion header. The SPI flash
> chips themselves are very cheap (some prices are even listed as
> low as 4 cents) and should not cost much if somebody decides to
> design a development board with an SPI flash chip soldered on
> the PCB.
>
> Another nice feature of the SPI flash is that it can be safely
> accessed in a device-independent way (since we know that the
> boot ROM is already probing these pins during the boot time).
> And if, for example, Olimex boards opted to use SPI flash instead
> of EEPROM, then they would have been able to have U-Boot installed
> in the SPI flash now and boot the rest of the system from the SATA
> hard drive. Hopefully we may see new interesting Allwinner based
> development boards in the future, now that the software support
> for the SPI flash is in a better shape :-)
>
> Testing can be done by enabling the CONFIG_SPL_SPI_SUNXI option
> in a board defconfig, then building U-Boot and finally flashing
> the resulting u-boot-sunxi-with-spl.bin binary over USB OTG with
> a help of the sunxi-fel tool:
>
>sunxi-fel spiflash-write 0 u-boot-sunxi-with-spl.bin
>
> The device needs to be switched into FEL (USB recovery) mode first.
> The most suitable boards for testing are Orange Pi PC and Pine64.
> Because these boards are cheap, have no built-in NAND/eMMC and
> expose SPI0 pins on the Raspberry Pi compatible expansion header.
> The A13-OLinuXino-Micro board also can be used.
>
> Signed-off-by: Siarhei Siamashka 
> ---
>
> Changes in v2:
>  - Add Kconfig option (CONFIG_SPL_SPI_SUNXI) and move the SPI flash
>support code into a separate source file
>  - Use CONFIG_SYS_SPI_U_BOOT_OFFS instead of the hardcoded constant
>  - Deinitialize the SPI controller and undo pin muxing after the job
>is done
>  - Size reduction of the SPI transfer function
>  - Add delay after each SPI transfer to ensure that the chip select
>deassert timing requirements (tSHSL) are always satisfied
>  - More comments in the code
>
>
>  arch/arm/include/asm/arch-sunxi/gpio.h |   3 +
>  arch/arm/mach-sunxi/board.c|   5 +
>  common/spl/spl.c   |   4 +-
>  drivers/mtd/spi/Kconfig|  12 ++
>  drivers/mtd/spi/Makefile   |   1 +
>  drivers/mtd/spi/sunxi_spi_spl.c| 283 
> +
>  include/configs/sunxi-common.h |   5 +
>  7 files changed, 311 insertions(+), 2 deletions(-)
>  create mode 100644 drivers/mtd/spi/sunxi_spi_spl.c

Shouldn't this be a normal SPI driver? Then you could put this in
common/spl/spl_spi.c.

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

Re: [U-Boot] [PATCH 2/2] board: amlogic: Rename folder for Amlogic boards

[Simon Glass]

On 9 June 2016 at 08:45, Carlo Caione  wrote:
> From: Carlo Caione 
>
> s/hardkernel/amlogic/ to have a single place for all the amlogic-based
> boards.
>
> Signed-off-by: Carlo Caione 
> ---
>  arch/arm/mach-meson/Kconfig|  2 +-
>  board/amlogic/odroid-c2/Kconfig| 12 ++
>  board/amlogic/odroid-c2/MAINTAINERS|  6 +++
>  board/amlogic/odroid-c2/Makefile   |  7 
>  board/amlogic/odroid-c2/README | 60 ++
>  board/amlogic/odroid-c2/odroid-c2.c| 67 
> ++
>  board/hardkernel/odroid-c2/Kconfig | 12 --
>  board/hardkernel/odroid-c2/MAINTAINERS |  6 ---
>  board/hardkernel/odroid-c2/Makefile|  7 
>  board/hardkernel/odroid-c2/README  | 60 --
>  board/hardkernel/odroid-c2/odroid-c2.c | 67 
> --
>  11 files changed, 153 insertions(+), 153 deletions(-)
>  create mode 100644 board/amlogic/odroid-c2/Kconfig
>  create mode 100644 board/amlogic/odroid-c2/MAINTAINERS
>  create mode 100644 board/amlogic/odroid-c2/Makefile
>  create mode 100644 board/amlogic/odroid-c2/README
>  create mode 100644 board/amlogic/odroid-c2/odroid-c2.c
>  delete mode 100644 board/hardkernel/odroid-c2/Kconfig
>  delete mode 100644 board/hardkernel/odroid-c2/MAINTAINERS
>  delete mode 100644 board/hardkernel/odroid-c2/Makefile
>  delete mode 100644 board/hardkernel/odroid-c2/README
>  delete mode 100644 board/hardkernel/odroid-c2/odroid-c2.c

Reviewed-by: Simon Glass 

Although I'm surprised this did not come through as a rename in your patch.

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

Re: [U-Boot] [PATCH 7/8] x86: Probe pinctrl driver in cpu_init_r()

[Simon Glass]

On 8 June 2016 at 06:07, Bin Meng  wrote:
> At present pinctrl driver gets probed in ich6_gpio driver's probe
> routine, which has two issues:
>
>  - Pin's PADs only gets configured when GPIO driver is probed, which
>is not done by default. This leaves the board in a partially
>functional state as we must initialize PADs correctly to get
>perepherals fully working.
>  - The probe routine of pinctrl driver is called multiple times, as
>normally there are multiple GPIO controllers. It should really
>be called just once.
>
> Move the call to syscon_get_by_driver_data() from ich6_gpio driver
> to cpu_init_r().
>
> Signed-off-by: Bin Meng 
>
> ---
>
>  arch/x86/cpu/cpu.c | 5 +
>  drivers/gpio/intel_ich6_gpio.c | 7 ---
>  2 files changed, 5 insertions(+), 7 deletions(-)

I suppose this is better. But will the pins always be set up even if
the GPIO driver is not used until later?

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

Re: [U-Boot] [PATCH 1/2] configs: gxbb: Introduce a common config header file

[Simon Glass]

On 9 June 2016 at 08:45, Carlo Caione  wrote:
> From: Carlo Caione 
>
> Introduce a meson-gxbb-common.h header file and derive the
> configuration for Hardkernel Odroid-C2 board from that.
>
> Signed-off-by: Carlo Caione 
> ---
>  include/configs/meson-gxbb-common.h | 45 
> +
>  include/configs/odroid-c2.h | 34 +---
>  2 files changed, 46 insertions(+), 33 deletions(-)
>  create mode 100644 include/configs/meson-gxbb-common.h

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

Re: [U-Boot] [PATCH 8/8] x86: broadwell: gpio: Remove the codes to set up pin control

[Simon Glass]

On 8 June 2016 at 06:07, Bin Meng  wrote:
> Now that we have set up pin control in cpu_init_r(), remove the
> duplicated codes in the broadwell gpio driver.
>
> Signed-off-by: Bin Meng 
> ---
>
>  drivers/gpio/intel_broadwell_gpio.c | 7 ---
>  1 file changed, 7 deletions(-)

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

Re: [U-Boot] [PATCH 6/8] x86: Enable regmap and syscon for coreboot and qemu-x86

[Simon Glass]

On 8 June 2016 at 06:07, Bin Meng  wrote:
> These are generic and should be turned on on coreboot and qemu-x86.
>
> Signed-off-by: Bin Meng 
> ---
>
>  configs/coreboot-x86_defconfig | 2 ++
>  configs/qemu-x86_defconfig | 2 ++
>  2 files changed, 4 insertions(+)

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

Re: [U-Boot] [PATCH 4/8] x86: baytrail: Configure card detect pin of the SD controller

[Simon Glass]

On 8 June 2016 at 06:07, Bin Meng  wrote:
> As of today, the latest version FSP (gold4) for BayTrail misses the
> PAD configuration of the SD controller's Card Detect signal. The
> default PAD value for the CD pin sets the pin to work in GPIO mode,
> which causes card detect status cannot be reflected by the Present
> State register in the SD controller (bit 16 & bit 18 are always zero).
>
> Add a configuration for this pin in the pinctrl node.
>
> Note I've checked the PAD configuration for all the pins in all the
> 3 controllers (eMMC/SDIO/SD). Only this SDMMC3_CD_B pin does not get
> initialized to correct mode by FSP. With fsp,emmc-boot-mode set to
> 2 (eMMC 4.1), eMMC pins are initialized to func 1, but if we set
> fsp,emmc-boot-mode to 1 (auto), those pins are initialized to func 3
> which is correct according to datasheet.
>
> Signed-off-by: Bin Meng 
> ---
>
>  arch/x86/dts/bayleybay.dts   | 15 +++
>  arch/x86/dts/conga-qeval20-qa3-e3845.dts | 15 +++
>  arch/x86/dts/minnowmax.dts   | 15 +++
>  3 files changed, 45 insertions(+)

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

Re: [U-Boot] [PATCH 3/8] x86: baytrail: Change fsp, emmc-boot-mode to "auto"

[Simon Glass]

On 8 June 2016 at 06:07, Bin Meng  wrote:
> At present all BayTrail boards configure fsp,emmc-boot-mode to 2,
> which means "eMMC 4.1" per FSP documentation. However, eMMC 4.1
> only shows up on some early stepping silicon of BayTrail SoC.
> Newer stepping SoC integrates an eMMC 4.5 controller. Intel FSP
> provides a config option fsp,emmc-boot-mode which tells FSP which
> eMMC controller it initializes. Instead of hardcoded to 2, now
> we change it to 1 which means "auto".
>
> With this change, MinnowMax board (with a D0 stepping BayTrail SoC)
> can see the eMMC 4.5 controller at PCI address 00.17.00 via U-Boot
> 'pci' command.
>
> Signed-off-by: Bin Meng 
> ---
>
>  arch/x86/dts/bayleybay.dts   | 2 +-
>  arch/x86/dts/conga-qeval20-qa3-e3845.dts | 2 +-
>  arch/x86/dts/minnowmax.dts   | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)

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

Re: [U-Boot] [RFC PATCH] cmd: gpt: add - partition size parsing

[Simon Glass]

On 8 June 2016 at 02:18, Michael Trimarchi  wrote:
> This patch try to parse name=userdata,size=-,uuid=${uuid_gpt_userdata};
>
> gpt mmc write 0 $partitions
> gpt mmc verify 0 $partitions
>
> Signed-off-by: Michael Trimarchi 
> ---
>  cmd/gpt.c | 13 +++--
>  1 file changed, 11 insertions(+), 2 deletions(-)

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

Re: [U-Boot] [PATCH 2/8] x86: baytrail: Add 'reg' property in the pinctrl node

[Simon Glass]

On 8 June 2016 at 06:07, Bin Meng  wrote:
> Without a 'reg' property, pinctrl driver probe routine fails in
> its pre_probe() with a return value of -EINVAL.
>
> Add 'reg' property for all BayTrail boards. Note for BayleyBay,
> the pinctrl node is newly added.
>
> Signed-off-by: Bin Meng 
> ---
>
>  arch/x86/dts/bayleybay.dts   | 5 +
>  arch/x86/dts/conga-qeval20-qa3-e3845.dts | 1 +
>  arch/x86/dts/minnowmax.dts   | 1 +
>  3 files changed, 7 insertions(+)

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

Re: [U-Boot] [PATCH 5/8] x86: Update x86-pinctrl driver device-tree-bindings doc

[Simon Glass]

On 8 June 2016 at 06:07, Bin Meng  wrote:
> This updates the device-tree-bindings doc for x86-pinctrl driver:
>
>  - clarify "gpio-offset" is required only when "mode-gpio" is set
>  - correct property name "pull-strength"
>  - use tab instead of space at several places
>
> Signed-off-by: Bin Meng 
> ---
>
>  doc/device-tree-bindings/gpio/intel,x86-pinctrl.txt | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)

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

Re: [U-Boot] [PATCH 1/8] x86: ich6_gpio: Output return value of syscon_get_by_driver_data()

[Simon Glass]

On 8 June 2016 at 06:07, Bin Meng  wrote:
> The call to syscon_get_by_driver_data() does not save its return value.
> Print it out to aid debugging.
>
> Signed-off-by: Bin Meng 
> ---
>
>  drivers/gpio/intel_ich6_gpio.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)

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

Re: [U-Boot] [PATCH v3] mmc: atmel_sdhci: Convert to the driver model support

[Simon Glass]

Hi Wenyou,

On 7 June 2016 at 01:28, Wenyou Yang  wrote:
> Convert the driver to the driver model while retaining the existing
> legacy code. This allows the driver to support boards that have
> converted to driver model as well as those that have not.
>
> Signed-off-by: Wenyou Yang 
> ---
>
> Changes in v3:
>  - Remove the redundant log print.
>
> Changes in v2:
>  - Add clock support, include enabling peripheral clock and
>generated clock.
>  - Retain the existing legacy code to support boards which have not
>converted to driver model.
>
>  drivers/mmc/Kconfig   | 10 ++
>  drivers/mmc/atmel_sdhci.c | 92 
> +++
>  2 files changed, 102 insertions(+)
>
> diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
> index dc8532f..7f6b2e1 100644
> --- a/drivers/mmc/Kconfig
> +++ b/drivers/mmc/Kconfig
> @@ -16,6 +16,16 @@ config DM_MMC
>   appear as block devices in U-Boot and can support filesystems such
>   as EXT4 and FAT.
>
> +config ATMEL_SDHCI
> +   bool "Atmel SDHCI controller support"
> +   depends on DM_MMC && ARCH_AT91
> +   help
> + This enables support for the Atmel SDHCI controller, which supports
> + the embedded MultiMedia Card (e.MMC) Specification V4.51, the SD
> + Memory Card Specification V3.0, and the SDIO V3.0 specification.
> + It is compliant with the SD Host Controller Standard V3.0
> + specification.
> +
>  config ROCKCHIP_DWMMC
> bool "Rockchip SD/MMC controller support"
> depends on DM_MMC && OF_CONTROL
> diff --git a/drivers/mmc/atmel_sdhci.c b/drivers/mmc/atmel_sdhci.c
> index 24b68b6..dc74704 100644
> --- a/drivers/mmc/atmel_sdhci.c
> +++ b/drivers/mmc/atmel_sdhci.c
> @@ -6,12 +6,16 @@
>   */
>
>  #include 
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
>
>  #define ATMEL_SDHC_MIN_FREQ40
>
> +#ifndef CONFIG_DM_MMC
> +
>  int atmel_sdhci_init(void *regbase, u32 id)
>  {
> struct sdhci_host *host;
> @@ -38,3 +42,91 @@ int atmel_sdhci_init(void *regbase, u32 id)
>
> return 0;
>  }
> +
> +#else
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +static int atmel_sdhci_probe(struct udevice *dev)
> +{
> +   struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
> +   struct sdhci_host *host = dev_get_priv(dev);
> +   u32 max_clk, min_clk = ATMEL_SDHC_MIN_FREQ;
> +   u32 caps0, caps1;
> +   u32 clk_base, clk_mul;
> +   u32 gck_rate;
> +   struct udevice *clkdev;
> +   int periph, ret;
> +
> +   ret = clk_get_by_index(dev, 0, );
> +   if (ret)
> +   return ret;
> +
> +   periph = fdtdec_get_uint(gd->fdt_blob, clkdev->of_offset, "reg", -1);
> +   if (periph < 0)
> +   return -EINVAL;
> +
> +   clkdev = dev_get_parent(clkdev);
> +   if (!clkdev)
> +   return -ENODEV;

This cannot happen, there is always a parent. Even if your device tree
has this as a root node, there is still the root device.

> +
> +   ret = clk_enable(clkdev, periph);
> +   if (ret)
> +   return ret;
> +
> +   host->name = (char *)dev->name;
> +   host->ioaddr = (void *)dev_get_addr(dev);
> +
> +   host->quirks = 0;
> +   host->version = sdhci_readw(host, SDHCI_HOST_VERSION);
> +
> +   host->bus_width = fdtdec_get_int(gd->fdt_blob, dev->of_offset,
> +"bus-width", 4);
> +
> +   caps0 = readl(host->ioaddr + SDHCI_CAPABILITIES);
> +   caps1 = readl(host->ioaddr + SDHCI_CAPABILITIES_1);
> +   clk_base = (caps0 & SDHCI_CLOCK_V3_BASE_MASK) >> 
> SDHCI_CLOCK_BASE_SHIFT;
> +   clk_mul = (caps1 & SDHCI_CLOCK_MUL_MASK) >> SDHCI_CLOCK_MUL_SHIFT;
> +   gck_rate = clk_base * 100 * (clk_mul + 1);
> +
> +   ret = clk_get_by_index(dev, 1, );
> +   if (ret)
> +   return ret;
> +
> +   periph = fdtdec_get_uint(gd->fdt_blob, clkdev->of_offset, "reg", -1);
> +   if (periph < 0)
> +   return -EINVAL;
> +
> +   clkdev = dev_get_parent(clkdev);
> +   if (!clkdev)
> +   return -ENODEV;

-EINVAL

> +
> +   ret = clk_set_periph_rate(clkdev, periph, gck_rate);
> +   if (ret)
> +   return -ENODEV;

return ret

> +
> +   max_clk = clk_get_periph_rate(clkdev, periph);
> +   if (!max_clk)
> +   return -ENODEV;

-EINVAL

> +
> +   add_sdhci(host, max_clk, min_clk);
> +
> +   upriv->mmc = host->mmc;
> +
> +   return 0;
> +}
> +
> +static const struct udevice_id atmel_sdhci_ids[] = {
> +   { .compatible = "atmel,sama5d2-sdhci" },
> +   { }
> +};
> +
> +U_BOOT_DRIVER(atmel_sdhci_drv) = {
> +   .name   = "atmel_sdhci",
> +   .id = UCLASS_MMC,
> +   .of_match   = atmel_sdhci_ids,
> +   .probe  = atmel_sdhci_probe,
> +   .priv_auto_alloc_size = sizeof(struct sdhci_host),
> +};
> +
> 

Re: [U-Boot] [PATCH v4 5/5] configs: sama5d2_xplained: Add #ifndef before CONFIG_ATMEL_PIO4

[Simon Glass]

On 7 June 2016 at 01:24, Wenyou Yang  wrote:
> Since CONFIG_ATMEL_PIO4 options is added to Kconfig, to avoid
> compilation warnings when the option is enabled,
> add #ifndef CONFIG_DM_GPIO before #define CONFIG_ATMEL_PIO4
> to avoid compilation warnings.
>
> Signed-off-by: Wenyou Yang 
> ---
>
> Changes in v4: None
> Changes in v3: None
> Changes in v2:
>  - integrate the gpio rework patch into this patch series.
>  - add the new patch to move the PIO4 definitions to head file
>and rephrase them.
>  - add the new patch to add #ifndef before CONFIG_ATMEL_PIO4
>in configs/sama5d2_xplained.h
>
>  include/configs/sama5d2_xplained.h | 2 ++
>  1 file changed, 2 insertions(+)

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

Re: [U-Boot] [PATCH] spl: fit: Fix non-matching DT names console output

[Simon Glass]

On 3 June 2016 at 13:05, Andreas Dannenberg  wrote:
> When no DTB can be matched successfully to the board that's being used
> a list of available FIT-embedded DTBs will be output to the console for
> diagnostic purposes. But rather than the contents of the "description"
> FDT property a non-existent property was accessed and as a result "NULL"
> was output instead of the actual name(s) of the DTB(s). Fix this issue
> by using the correct property which is also the exact same property
> that's used earlier during the actual board matching process.
>
> Signed-off-by: Andreas Dannenberg 
> ---
>  common/spl/spl_fit.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

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

Re: [U-Boot] [PATCH v3] dm: at91: Add driver model support for the spi driver

[Simon Glass]

On 7 June 2016 at 01:26, Wenyou Yang  wrote:
> Add driver model support while retaining the existing legacy code.
> This allows the driver to support boards that have converted to
> driver model as well as those that have not.
>
> Signed-off-by: Wenyou Yang 
> ---
>
> Changes in v3:
>  - Remove redundant log print.
>
> Changes in v2:
>  - Add clock support.
>
>  drivers/spi/Kconfig |   9 ++
>  drivers/spi/atmel_spi.c | 299 
> +++-
>  2 files changed, 307 insertions(+), 1 deletion(-)

Reviewed-by: Simon Glass 

Nits below.

>
> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
> index b7fd8e5..2ac145c 100644
> --- a/drivers/spi/Kconfig
> +++ b/drivers/spi/Kconfig
> @@ -32,6 +32,15 @@ config ATH79_SPI
>   uses driver model and requires a device tree binding to operate.
>   please refer to doc/device-tree-bindings/spi/spi-ath79.txt.
>
> +config ATMEL_SPI
> +   bool "Atmel SPI driver"
> +   depends on ARCH_AT91
> +   select SPI_FLASH
> +   select SPI_FLASH_ATMEL
> +   help
> + Enable the Atmel SPI driver. This driver can be used to access
> + the SPI Flash, such as AT25DF321.
> +
>  config CADENCE_QSPI
> bool "Cadence QSPI driver"
> help
> diff --git a/drivers/spi/atmel_spi.c b/drivers/spi/atmel_spi.c
> index ed6278b..0ddcdda 100644
> --- a/drivers/spi/atmel_spi.c
> +++ b/drivers/spi/atmel_spi.c
> @@ -4,16 +4,24 @@
>   * SPDX-License-Identifier:GPL-2.0+
>   */
>  #include 
> +#include 
> +#include 
> +#include 
>  #include 
>  #include 
>
>  #include 
>
> -#include 
>  #include 
> +#include 
> +#include 
>
>  #include "atmel_spi.h"
>
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +#ifndef CONFIG_DM_SPI
> +
>  static int spi_has_wdrbt(struct atmel_spi_slave *slave)
>  {
> unsigned int ver;
> @@ -209,3 +217,292 @@ out:
>
> return 0;
>  }
> +
> +#else
> +
> +#define MAX_CS_COUNT   4
> +
> +struct atmel_spi_platdata {
> +   struct at91_spi *regs;
> +};
> +
> +struct atmel_spi_priv {
> +   unsigned int freq;  /* Default frequency */
> +   unsigned int mode;
> +   ulong bus_clk_rate;
> +   struct gpio_desc cs_gpios[MAX_CS_COUNT];
> +};
> +
> +static int atmel_spi_claim_bus(struct udevice *dev)
> +{
> +   struct udevice *bus = dev_get_parent(dev);
> +   struct atmel_spi_platdata *bus_plat = dev_get_platdata(bus);
> +   struct atmel_spi_priv *priv = dev_get_priv(bus);
> +   struct dm_spi_slave_platdata *slave_plat = 
> dev_get_parent_platdata(dev);
> +   struct at91_spi *reg_base = bus_plat->regs;
> +   u32 cs = slave_plat->cs;
> +   u32 freq = priv->freq;
> +   u32 scbr, csrx, mode;
> +
> +   scbr = (priv->bus_clk_rate + freq - 1) / freq;
> +   if (scbr > ATMEL_SPI_CSRx_SCBR_MAX)
> +   return -EINVAL;
> +
> +   if (scbr < 1)
> +   scbr = 1;
> +
> +   csrx = ATMEL_SPI_CSRx_SCBR(scbr);
> +   csrx |= ATMEL_SPI_CSRx_BITS(ATMEL_SPI_BITS_8);
> +
> +   if (!(priv->mode & SPI_CPHA))
> +   csrx |= ATMEL_SPI_CSRx_NCPHA;
> +   if (priv->mode & SPI_CPOL)
> +   csrx |= ATMEL_SPI_CSRx_CPOL;
> +
> +   writel(csrx, _base->csr[cs]);
> +
> +   mode = ATMEL_SPI_MR_MSTR |
> +  ATMEL_SPI_MR_MODFDIS |
> +  ATMEL_SPI_MR_WDRBT |
> +  ATMEL_SPI_MR_PCS(~(1 << cs));
> +
> +   writel(mode, _base->mr);
> +
> +   writel(ATMEL_SPI_CR_SPIEN, _base->cr);
> +
> +   return 0;
> +}
> +
> +static int atmel_spi_release_bus(struct udevice *dev)
> +{
> +   struct udevice *bus = dev_get_parent(dev);
> +   struct atmel_spi_platdata *bus_plat = dev_get_platdata(bus);
> +
> +   writel(ATMEL_SPI_CR_SPIDIS, _plat->regs->cr);
> +
> +   return 0;
> +}
> +
> +static void atmel_spi_cs_activate(struct udevice *dev)
> +{
> +   struct udevice *bus = dev_get_parent(dev);
> +   struct atmel_spi_priv *priv = dev_get_priv(bus);
> +   struct dm_spi_slave_platdata *slave_plat = 
> dev_get_parent_platdata(dev);
> +   u32 cs = slave_plat->cs;
> +
> +   dm_gpio_set_value(>cs_gpios[cs], 0);
> +}
> +
> +static void atmel_spi_cs_deactivate(struct udevice *dev)
> +{
> +   struct udevice *bus = dev_get_parent(dev);
> +   struct atmel_spi_priv *priv = dev_get_priv(bus);
> +   struct dm_spi_slave_platdata *slave_plat = 
> dev_get_parent_platdata(dev);
> +   u32 cs = slave_plat->cs;
> +
> +   dm_gpio_set_value(>cs_gpios[cs], 1);
> +}
> +
> +static int atmel_spi_xfer(struct udevice *dev, unsigned int bitlen,
> + const void *dout, void *din, unsigned long flags)
> +{
> +   struct udevice *bus = dev_get_parent(dev);
> +   struct atmel_spi_platdata *bus_plat = dev_get_platdata(bus);
> +   struct at91_spi *reg_base = bus_plat->regs;
> +
> +   u32 len_tx, len_rx, len;
> +   u32 status;
> +   const u8 *txp = 

Re: [U-Boot] [PATCH v4 4/5] atmel: Bring in at91 pio4 device tree file and bindings

[Simon Glass]

2016-06-07 1:24 GMT-06:00 Wenyou Yang :
> Bring in required device tree file and bindings from Linux.
>
> Signed-off-by: Wenyou Yang 
> Reviewed-by: Andreas Bießmann 
> ---
>
> Changes in v4: None
> Changes in v3: None
> Changes in v2:
>  - add detailed example to show how to configure pinctrl for device.
>  - remove interrupt and gpio property description.
>  - add reviewed-by tag.
>
>  arch/arm/dts/sama5d2-pinfunc.h | 880 
> +
>  .../pinctrl/atmel,at91-pio4-pinctrl.txt|  66 ++
>  2 files changed, 946 insertions(+)
>  create mode 100644 arch/arm/dts/sama5d2-pinfunc.h
>  create mode 100644 
> doc/device-tree-bindings/pinctrl/atmel,at91-pio4-pinctrl.txt

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

Re: [U-Boot] [PATCH v4 2/5] gpio: atmel_pio4: Rework to support DM & DT

[Simon Glass]

Hi Wenyou,

On 7 June 2016 at 01:24, Wenyou Yang  wrote:
> Rework the driver to support driver model and device tree, and
> support to regard the pio4 pinctrl device as a child of
> atmel_pio4 device.
>
> Signed-off-by: Wenyou Yang 
> ---
>
> Changes in v4:
>  - Remove the redundant log print.
>
> Changes in v3:
>  - Add bind callback to support the pinctl device regarding as
>a child of atmel_pio4 device.
>  - Add clock support.
>
> Changes in v2: None
>
>  drivers/gpio/Kconfig  |   2 +-
>  drivers/gpio/atmel_pio4.c | 133 
> +++---
>  2 files changed, 114 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> index 93a7e8c..11f056d 100644
> --- a/drivers/gpio/Kconfig
> +++ b/drivers/gpio/Kconfig
> @@ -30,7 +30,7 @@ config DWAPB_GPIO
>
>  config ATMEL_PIO4
> bool "ATMEL PIO4 driver"
> -   depends on DM
> +   depends on DM_GPIO
> default n
> help
>   Say yes here to support the Atmel PIO4 driver.
> diff --git a/drivers/gpio/atmel_pio4.c b/drivers/gpio/atmel_pio4.c
> index 84e8cc5..8232bf2 100644
> --- a/drivers/gpio/atmel_pio4.c
> +++ b/drivers/gpio/atmel_pio4.c
> @@ -7,11 +7,17 @@
>   * SPDX-License-Identifier:GPL-2.0+
>   */
>  #include 
> +#include 
>  #include 
> +#include 
> +#include 
>  #include 
> +#include 
>  #include 
>  #include 
>
> +DECLARE_GLOBAL_DATA_PTR;
> +
>  static struct atmel_pio4_port *atmel_pio4_port_base(u32 port)
>  {
> struct atmel_pio4_port *base = NULL;
> @@ -165,14 +171,38 @@ int atmel_pio4_get_pio_input(u32 port, u32 pin)
>  }
>
>  #ifdef CONFIG_DM_GPIO
> +
> +struct atmel_pioctrl_data {
> +   u32 nbanks;
> +};
> +
> +struct atmel_pio4_platdata {
> +   struct atmel_pio4_port *reg_base;
> +};
> +
> +static struct atmel_pio4_port *atmel_pio4_bank_base(struct udevice *dev,
> +   u32 bank)
> +{
> +   struct atmel_pio4_platdata *plat = dev_get_platdata(dev);
> +   struct atmel_pio4_port *port_base =
> +   (struct atmel_pio4_port *)((u32)plat->reg_base +
> +   ATMEL_PIO_BANK_OFFSET * bank);
> +
> +   return port_base;
> +}
> +
>  static int atmel_pio4_direction_input(struct udevice *dev, unsigned offset)
>  {
> -   struct at91_port_platdata *plat = dev_get_platdata(dev);
> -   struct atmel_pio4_port *port_base = (atmel_pio4_port 
> *)plat->base_addr;
> -   u32 mask = 0x01 << offset;
> -   u32 reg = ATMEL_PIO_CFGR_FUNC_GPIO;
> +   u32 bank = ATMEL_PIO_BANK(offset);
> +   u32 line = ATMEL_PIO_LINE(offset);
> +   struct atmel_pio4_port *port_base = atmel_pio4_bank_base(dev, bank);
> +   u32 mask = BIT(line);
> +   u32 reg;
>
> writel(mask, _base->mskr);
> +   reg = readl(_base->cfgr);
> +   reg &= ~ATMEL_PIO_CFGR_FUNC_MASK;
> +   reg &= ~ATMEL_PIO_DIR_MASK;
> writel(reg, _base->cfgr);

You could use clrbits_le32() here.

>
> return 0;
> @@ -181,12 +211,16 @@ static int atmel_pio4_direction_input(struct udevice 
> *dev, unsigned offset)
>  static int atmel_pio4_direction_output(struct udevice *dev,
>unsigned offset, int value)
>  {
> -   struct at91_port_platdata *plat = dev_get_platdata(dev);
> -   struct atmel_pio4_port *port_base = (atmel_pio4_port 
> *)plat->base_addr;
> -   u32 mask = 0x01 << offset;
> -   u32 reg = ATMEL_PIO_CFGR_FUNC_GPIO | ATMEL_PIO_DIR_MASK;
> +   u32 bank = ATMEL_PIO_BANK(offset);
> +   u32 line = ATMEL_PIO_LINE(offset);
> +   struct atmel_pio4_port *port_base = atmel_pio4_bank_base(dev, bank);
> +   u32 mask = BIT(line);
> +   u32 reg;
>
> writel(mask, _base->mskr);
> +   reg = readl(_base->cfgr);
> +   reg &= ~ATMEL_PIO_CFGR_FUNC_MASK;
> +   reg |= ATMEL_PIO_DIR_MASK;
> writel(reg, _base->cfgr);

clrsetbits_le32()

>
> if (value)
> @@ -199,9 +233,10 @@ static int atmel_pio4_direction_output(struct udevice 
> *dev,
>
>  static int atmel_pio4_get_value(struct udevice *dev, unsigned offset)
>  {
> -   struct at91_port_platdata *plat = dev_get_platdata(dev);
> -   struct atmel_pio4_port *port_base = (atmel_pio4_port 
> *)plat->base_addr;
> -   u32 mask = 0x01 << offset;
> +   u32 bank = ATMEL_PIO_BANK(offset);
> +   u32 line = ATMEL_PIO_LINE(offset);
> +   struct atmel_pio4_port *port_base = atmel_pio4_bank_base(dev, bank);
> +   u32 mask = BIT(line);
>
> return (readl(_base->pdsr) & mask) ? 1 : 0;
>  }
> @@ -209,9 +244,10 @@ static int atmel_pio4_get_value(struct udevice *dev, 
> unsigned offset)
>  static int atmel_pio4_set_value(struct udevice *dev,
> unsigned offset, int value)
>  {
> -   struct at91_port_platdata *plat = dev_get_platdata(dev);
> -   struct atmel_pio4_port *port_base = (atmel_pio4_port 
> 

Re: [U-Boot] [PATCH v4 3/5] pinctrl: at91-pio4: Add pinctrl driver

[Simon Glass]

Hi Wenyou,

On 7 June 2016 at 01:24, Wenyou Yang  wrote:
> AT91 PIO4 controller is a combined gpio-controller, pin-mux and
> pin-config module. The peripheral's pins are assigned through
> per-pin based muxing logic.
>
> The pin configuration is performed on specific registers which
> are shared along with the gpio controller. So regard the pinctrl
> device as a child of atmel_pio4 device.
>
> Signed-off-by: Wenyou Yang 
> ---
>
> Changes in v4: None
> Changes in v3:
>  - Rework due to the pinctrl device is regarded as atmel_pio4
>device's child.
>
> Changes in v2:
>  - remove meaningless comment.
>  - add else path for argument of pinconf.
>  - add inline attribute for atmel_pio4_bank_base().
>  - add handle if the pinmux entries is greater maximum value.
>
>  drivers/pinctrl/Kconfig |   7 ++
>  drivers/pinctrl/Makefile|   1 +
>  drivers/pinctrl/pinctrl-at91-pio4.c | 185 
> 
>  3 files changed, 193 insertions(+)
>  create mode 100644 drivers/pinctrl/pinctrl-at91-pio4.c

Reviewed-by: Simon Glass 

With one nit below.

>
> diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
> index 567b766..68ecfbb 100644
> --- a/drivers/pinctrl/Kconfig
> +++ b/drivers/pinctrl/Kconfig
> @@ -123,6 +123,13 @@ config QCA953X_PINCTRL
>   both the GPIO definitions and pin control functions for each
>   available multiplex function.
>
> +config PINCTRL_AT91PIO4
> +   bool "AT91 PIO4 pinctrl driver"
> +   depends on DM
> +   help
> + This option is to enable the AT91 pinctrl driver for AT91 PIO4
> + controller which is available on SAMA5D2 SoC.
> +
>  config ROCKCHIP_PINCTRL
> bool "Rockchip pin control driver"
> depends on DM
> diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
> index b99ed2f..4df10a4 100644
> --- a/drivers/pinctrl/Makefile
> +++ b/drivers/pinctrl/Makefile
> @@ -5,6 +5,7 @@
>  obj-y  += pinctrl-uclass.o
>  obj-$(CONFIG_$(SPL_)PINCTRL_GENERIC)   += pinctrl-generic.o
>
> +obj-$(CONFIG_PINCTRL_AT91PIO4) += pinctrl-at91-pio4.o
>  obj-y  += nxp/
>  obj-$(CONFIG_ARCH_ATH79) += ath79/
>  obj-$(CONFIG_ARCH_ROCKCHIP) += rockchip/
> diff --git a/drivers/pinctrl/pinctrl-at91-pio4.c 
> b/drivers/pinctrl/pinctrl-at91-pio4.c
> new file mode 100644
> index 000..ed63f68
> --- /dev/null
> +++ b/drivers/pinctrl/pinctrl-at91-pio4.c
> @@ -0,0 +1,185 @@
> +/*
> + * Atmel PIO4 pinctrl driver
> + *
> + * Copyright (C) 2016 Atmel Corporation
> + *   Wenyou.Yang 
> + *
> + * SPDX-License-Identifier:GPL-2.0+
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +/*
> + * Warning:
> + * In order to not introduce confusion between Atmel PIO groups and pinctrl
> + * framework groups, Atmel PIO groups will be called banks.
> + */
> +
> +struct atmel_pio4_platdata {
> +   struct atmel_pio4_port *reg_base;
> +};
> +
> +static const struct pinconf_param conf_params[] = {
> +   { "bias-disable", PIN_CONFIG_BIAS_DISABLE, 0 },
> +   { "bias-pull-up", PIN_CONFIG_BIAS_PULL_UP, 1 },
> +   { "bias-pull-down", PIN_CONFIG_BIAS_PULL_DOWN, 1 },
> +   { "drive-open-drain", PIN_CONFIG_DRIVE_OPEN_DRAIN, 0 },
> +   { "input-schmitt-disable", PIN_CONFIG_INPUT_SCHMITT_ENABLE, 0 },
> +   { "input-schmitt-enable", PIN_CONFIG_INPUT_SCHMITT_ENABLE, 1 },
> +   { "input-debounce", PIN_CONFIG_INPUT_DEBOUNCE, 0 },
> +};
> +
> +static u32 atmel_pinctrl_get_pinconf(const void *blob, int node)
> +{
> +   const struct pinconf_param *params;
> +   u32 param, arg, conf = 0;
> +   u32 i;
> +
> +   for (i = 0; i < ARRAY_SIZE(conf_params); i++) {
> +   params = _params[i];
> +   if (!fdt_get_property(blob, node, params->property, NULL))
> +   continue;
> +
> +   param = params->param;
> +   arg = params->default_value;
> +
> +   switch (param) {
> +   case PIN_CONFIG_BIAS_DISABLE:
> +   conf &= (~ATMEL_PIO_PUEN_MASK);
> +   conf &= (~ATMEL_PIO_PDEN_MASK);
> +   break;
> +   case PIN_CONFIG_BIAS_PULL_UP:
> +   conf |= ATMEL_PIO_PUEN_MASK;
> +   break;
> +   case PIN_CONFIG_BIAS_PULL_DOWN:
> +   conf |= ATMEL_PIO_PDEN_MASK;
> +   break;
> +   case PIN_CONFIG_DRIVE_OPEN_DRAIN:
> +   if (arg == 0)
> +   conf &= (~ATMEL_PIO_OPD_MASK);
> +   else
> +   conf |= ATMEL_PIO_OPD_MASK;
> +   break;
> +   case PIN_CONFIG_INPUT_SCHMITT_ENABLE:
> +   

Re: [U-Boot] [PATCH v4 1/5] gpio: atmel_pio4: Move PIO4 definitions to head file

[Simon Glass]

On 7 June 2016 at 01:24, Wenyou Yang  wrote:
> In order to make these PIO4 definitions shared with AT91 PIO4
> pinctrl driver, move them from the existing gpio driver to the
> head file, and rephrase them.
>
> Signed-off-by: Wenyou Yang 
> ---
>
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
>
>  arch/arm/mach-at91/include/mach/atmel_pio4.h | 35 ++
>  drivers/gpio/atmel_pio4.c| 71 
> +++-
>  2 files changed, 53 insertions(+), 53 deletions(-)

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

Re: [U-Boot] [PATCH v2 3/4] armv8/fsl-layerscape: add dwc3 gadget driver support

[Simon Glass]

Hi,

On 6 June 2016 at 03:16, Rajat Srivastava  wrote:
> Implements the dwc3 gadget driver support for LS1043
> platform, and performs below operations:
> 1. Enables snooping support for DWC3 controller.
> 2. Enables cache coherency in LS1043 platform.
>
> Signed-off-by: Rajat Srivastava 
> Signed-off-by: Rajesh Bhagat 
> Reviewed-by: Lukasz Majewski 
> ---
> Changes in v2:
>  - Moves DWC3 driver specific code to helper functions
>  - Calls helper functions in SoC specific implementation
>
>  arch/arm/cpu/armv8/fsl-layerscape/soc.c| 93 
> ++
>  .../include/asm/arch-fsl-layerscape/immap_lsch2.h  |  6 ++
>  2 files changed, 99 insertions(+)
>
> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/soc.c 
> b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> index 0fb5c7f..cc07524 100644
> --- a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> +++ b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> @@ -17,6 +17,10 @@
>  #ifdef CONFIG_CHAIN_OF_TRUST
>  #include 
>  #endif
> +#include 
> +#include 
> +#include 
> +
>
>  DECLARE_GLOBAL_DATA_PTR;
>
> @@ -318,9 +322,18 @@ void fsl_lsch2_early_init_f(void)
>  #if defined(CONFIG_FSL_QSPI) && !defined(CONFIG_QSPI_BOOT)
> out_be32(>qspi_cfg, SCFG_QSPI_CLKSEL);
>  #endif
> +   /* Make SEC and USB reads and writes snoopable */
> +#if defined(CONFIG_LS1043A)
> +   setbits_be32(>snpcnfgcr, SCFG_SNPCNFGCR_SECRDSNP |
> +SCFG_SNPCNFGCR_SECWRSNP | SCFG_SNPCNFGCR_USB1RDSNP |
> +SCFG_SNPCNFGCR_USB1WRSNP | SCFG_SNPCNFGCR_USB2RDSNP |
> +SCFG_SNPCNFGCR_USB2WRSNP | SCFG_SNPCNFGCR_USB3RDSNP |
> +SCFG_SNPCNFGCR_USB3WRSNP);
> +#else
> /* Make SEC reads and writes snoopable */
> setbits_be32(>snpcnfgcr, SCFG_SNPCNFGCR_SECRDSNP |
>  SCFG_SNPCNFGCR_SECWRSNP);
> +#endif
>
> /*
>  * Enable snoop requests and DVM message requests for
> @@ -336,6 +349,86 @@ void fsl_lsch2_early_init_f(void)
>  }
>  #endif
>
> +#ifdef CONFIG_USB_DWC3
> +
> +#if defined(CONFIG_LS1043A)
> +static struct dwc3_device dwc3_device_data0 = {
> +   .maximum_speed = USB_SPEED_HIGH,
> +   .base = CONFIG_SYS_FSL_XHCI_USB1_ADDR,
> +   .dr_mode = USB_DR_MODE_PERIPHERAL,
> +   .index = 0,
> +};
> +
> +static struct dwc3_device dwc3_device_data1 = {
> +   .maximum_speed = USB_SPEED_HIGH,
> +   .base = CONFIG_SYS_FSL_XHCI_USB2_ADDR,
> +   .dr_mode = USB_DR_MODE_PERIPHERAL,
> +   .index = 1,
> +};
> +
> +static struct dwc3_device dwc3_device_data2 = {
> +   .maximum_speed = USB_SPEED_HIGH,
> +   .base = CONFIG_SYS_FSL_XHCI_USB3_ADDR,
> +   .dr_mode = USB_DR_MODE_PERIPHERAL,
> +   .index = 2,
> +};
> +
> +int usb_gadget_handle_interrupts(int index)
> +{
> +   dwc3_uboot_handle_interrupt(index);
> +   return 0;
> +}
> +#endif
> +
> +int board_usb_init(int index, enum usb_init_type init)
> +{
> +   switch (init) {
> +   case USB_INIT_DEVICE:
> +   switch (index) {
> +#if defined(CONFIG_LS1043A)
> +   case 0:
> +   dwc3_uboot_init(_device_data0);
> +   break;
> +   case 1:
> +   dwc3_uboot_init(_device_data1);
> +   break;
> +   case 2:
> +   dwc3_uboot_init(_device_data2);
> +   break;
> +#endif

Can this use driver model? It seems odd to be adding new code like this.

> +   default:
> +   printf("Invalid Controller Index\n");
> +   return -1;
> +   }
> +#if defined(CONFIG_LS1043A)
> +   dwc3_core_incr_burst_enable(index, 0xf, 0xf);
> +   dwc3_core_set_snooping(index, true);
> +#endif
> +   break;
> +   default:
> +   break;
> +   }
> +
> +   return 0;
> +}
> +
> +int board_usb_cleanup(int index, enum usb_init_type init)
> +{
> +   switch (init) {
> +   case USB_INIT_DEVICE:
> +#if defined(CONFIG_LS1043A)
> +   dwc3_uboot_exit(index);
> +#endif
> +   break;
> +   default:
> +   break;
> +   }
> +   return 0;
> +}
> +#endif
> +
> +
> +
>  #ifdef CONFIG_BOARD_LATE_INIT
>  int board_late_init(void)
>  {
> diff --git a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h 
> b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
> index 57b99d4..13ba1a6 100644
> --- a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
> +++ b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
> @@ -328,6 +328,12 @@ struct ccsr_gur {
>
>  #define SCFG_SNPCNFGCR_SECRDSNP0x8000
>  #define SCFG_SNPCNFGCR_SECWRSNP0x4000
> +#define SCFG_SNPCNFGCR_USB1RDSNP   0x0020
> +#define SCFG_SNPCNFGCR_USB1WRSNP   0x0010
> +#define 

Re: [U-Boot] [PATCH] linux/compat.h: add dev_warn()

[Simon Glass]

On 4 June 2016 at 14:27, Andreas Bießmann  wrote:
> In order to prevent build errors for copied code from linux introduce
> dev_warn().
>
> Suggested-by: Scott Wood 
> Signed-off-by: Andreas Bießmann 
> ---
> This is a replacement patch for '[PATCH v2 14/18] at91: mtd: nand: Add
> dev_warn() to correct build error in driver'
>
>  include/linux/compat.h | 2 ++
>  1 file changed, 2 insertions(+)

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

Re: [U-Boot] [PATCH] dm: atmel: Add driver model support for the ehci driver

[Simon Glass]

+Stephen

On 2 June 2016 at 22:33, Wenyou Yang  wrote:
> Add driver model support while retaining the existing legacy code.
> This allows the driver to support boards that have converted to
> driver model as well as those that have not.
>
> Signed-off-by: Wenyou Yang 
> ---
>
>  drivers/usb/host/Kconfig  |   7 +++
>  drivers/usb/host/ehci-atmel.c | 108 
> ++
>  2 files changed, 115 insertions(+)

Acked-by: Simon Glass 

But note that this may require a rebase due to:

http://patchwork.ozlabs.org/patch/625342/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v4 1/2] powerpc/mpc85xx: SECURE BOOT- Enable chain of trust in SPL

[Simon Glass]

Hi,

On 9 June 2016 at 09:05, Andreas Dannenberg  wrote:
> Hi Sumit,
>
> On Thu, Jun 02, 2016 at 08:16:37AM -0400, Sumit Garg wrote:
>> As part of Chain of Trust for Secure boot, the SPL U-Boot will validate
>> the next level U-boot image. Add a new function spl_validate_uboot to
>> perform the validation.
>
> I noticed your patch series just now and I certainly don't want to
> derail what you are trying to do here but I wanted to see what you think
> about something that's pretty much related.
>
> In order to be more flexible in how we go from SPL to U-Boot (we have a
> need to inject ROM-API calls for decryption in addition to
> authentication) I've been experimenting with a method that basically
> injects a generic post-process function call into spl_load_simple_fit()
> that the platform-specific layer can provide/override. This function
> will basically get invoked on the U-Boot firmware itself as well as for
> the selected DTB after it gets loaded, allowing to do things like custom
> authentication and/or decryption through plugging in for example our ROM
> API calls. But this should also be a starting point for someone to plug
> in the U-Boot RSA libraries directly in a way that doesn't require using
> CONFIG_SPL_DM (for memory-constrained devices).
>
> So mostly I wanted to see if this is something that could be useful for
> you as well, and any comments/concerns you may have on that.
>
> Thanks and Regards,
>
> --
> Andreas Dannenberg
> Texas Instruments Inc
>
>
>> Enable hardware crypto operations in SPL using SEC block.
>> In case of Secure Boot, PAMU is not bypassed. For allowing SEC block
>> access to CPC configured as SRAM, configure PAMU.
>>
>> Reviewed-by: Ruchika Gupta 
>> Signed-off-by: Aneesh Bansal 
>> Signed-off-by: Sumit Garg 
>> ---
>> Changes in v2:
>> Patches rebased
>>
>> Changes in v3:
>> Patches rebased
>>
>> Changes in v4:
>> Generic changes in lib, drivers, common Makefiles removed from
>> this patchset. Rebased this patchset on top of patch [1], so this
>> patchset is dependent on patch [1].
>>
>> [1]https://patchwork.ozlabs.org/patch/627664/
>>
>>  arch/powerpc/cpu/mpc8xxx/fsl_pamu.c |  8 +
>>  arch/powerpc/cpu/mpc8xxx/pamu_table.c   |  8 +
>>  arch/powerpc/include/asm/fsl_secure_boot.h  | 28 
>>  board/freescale/common/fsl_chain_of_trust.c | 50 
>> +
>>  drivers/crypto/fsl/jr.c | 16 +
>>  drivers/mtd/nand/fsl_ifc_spl.c  | 24 ++
>>  include/fsl_validate.h  |  1 +
>>  7 files changed, 135 insertions(+)
>>
>> diff --git a/arch/powerpc/cpu/mpc8xxx/fsl_pamu.c 
>> b/arch/powerpc/cpu/mpc8xxx/fsl_pamu.c
>> index 9421f1e..ede8e66 100644
>> --- a/arch/powerpc/cpu/mpc8xxx/fsl_pamu.c
>> +++ b/arch/powerpc/cpu/mpc8xxx/fsl_pamu.c
>> @@ -239,15 +239,23 @@ int pamu_init(void)
>>   spaact_size = sizeof(struct paace) * NUM_SPAACT_ENTRIES;
>>
>>   /* Allocate space for Primary PAACT Table */
>> +#if (defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_PPAACT_ADDR))
>> + ppaact = (void *)CONFIG_SPL_PPAACT_ADDR;
>> +#else
>>   ppaact = memalign(PAMU_TABLE_ALIGNMENT, ppaact_size);
>>   if (!ppaact)
>>   return -1;
>> +#endif
>>   memset(ppaact, 0, ppaact_size);
>>
>>   /* Allocate space for Secondary PAACT Table */
>> +#if (defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_SPAACT_ADDR))
>> + sec = (void *)CONFIG_SPL_SPAACT_ADDR;
>> +#else
>>   sec = memalign(PAMU_TABLE_ALIGNMENT, spaact_size);
>>   if (!sec)
>>   return -1;
>> +#endif
>>   memset(sec, 0, spaact_size);
>>
>>   ppaact_phys = virt_to_phys((void *)ppaact);
>> diff --git a/arch/powerpc/cpu/mpc8xxx/pamu_table.c 
>> b/arch/powerpc/cpu/mpc8xxx/pamu_table.c
>> index 26c5ea4..a8e6f51 100644
>> --- a/arch/powerpc/cpu/mpc8xxx/pamu_table.c
>> +++ b/arch/powerpc/cpu/mpc8xxx/pamu_table.c
>> @@ -28,6 +28,14 @@ void construct_pamu_addr_table(struct pamu_addr_tbl *tbl, 
>> int *num_entries)
>>
>>   i++;
>>  #endif
>> +#if (defined(CONFIG_SPL_BUILD) && (CONFIG_SYS_INIT_L3_VADDR))
>> + tbl->start_addr[i] =
>> + (uint64_t)virt_to_phys((void *)CONFIG_SYS_INIT_L3_VADDR);
>> + tbl->size[i] = 256 * 1024; /* 256K CPC flash */
>> + tbl->end_addr[i] = tbl->start_addr[i] +  tbl->size[i] - 1;
>> +
>> + i++;
>> +#endif
>>   debug("PAMU address\t\t\tsize\n");
>>   for (j = 0; j < i ; j++)
>>   debug("%llx \t\t\t%llx\n",  tbl->start_addr[j],  tbl->size[j]);
>> diff --git a/arch/powerpc/include/asm/fsl_secure_boot.h 
>> b/arch/powerpc/include/asm/fsl_secure_boot.h
>> index 826f9c9..99eec7f 100644
>> --- a/arch/powerpc/include/asm/fsl_secure_boot.h
>> +++ b/arch/powerpc/include/asm/fsl_secure_boot.h
>> @@ -72,6 +72,32 @@
>>
>>  #ifdef CONFIG_CHAIN_OF_TRUST
>>
>> +#ifdef CONFIG_SPL_BUILD
>> +#define CONFIG_SPL_DM

Re: [U-Boot] [PATCH] i2c_eeprom: Add reading support

[Simon Glass]

Hi Mario,

On 2 June 2016 at 07:07, Mario Six  wrote:
> This patch implements the reading functionality for the generic I2C
> EEPROM driver, which was just a non-functional stub until now.
>
> Since the page size will be of importance for the writing support, we
> add suitable members to the private data structure to keep track of it.
>
> Compatibility strings for a range of at24c* chips are added.
>
> Signed-off-by: Mario Six 
> ---
>
> Writing functionality doesn't quite work yet; but with these I2C EEPROMs
> reading is probably more important, anyway.
>

Looks OK to me, with some comments below.

> ---
>  drivers/misc/Kconfig  |  5 +
>  drivers/misc/i2c_eeprom.c | 57 
> ---
>  include/i2c_eeprom.h  |  4 
>  3 files changed, 58 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> index 2373037..66453d5 100644
> --- a/drivers/misc/Kconfig
> +++ b/drivers/misc/Kconfig
> @@ -144,4 +144,9 @@ config QFW
>   Hidden option to enable QEMU fw_cfg interface. This will be 
> selected by
>   either CONFIG_CMD_QFW or CONFIG_GENERATE_ACPI_TABLE.
>
> +config I2C_EEPROM
> +   bool "Enable driver for generic I2C-attached EEPROMs"
> +   depends on DM
> +   help
> + Enable a generic driver for EEPROMs attached via I2C.
>  endmenu
> diff --git a/drivers/misc/i2c_eeprom.c b/drivers/misc/i2c_eeprom.c
> index 814134a..d59f126 100644
> --- a/drivers/misc/i2c_eeprom.c
> +++ b/drivers/misc/i2c_eeprom.c
> @@ -10,10 +10,20 @@
>  #include 
>  #include 
>
> +DECLARE_GLOBAL_DATA_PTR;
> +
>  static int i2c_eeprom_read(struct udevice *dev, int offset, uint8_t *buf,
>int size)
>  {
> -   return -ENODEV;
> +   struct i2c_eeprom *data = dev_get_priv(dev);
> +   struct udevice *chip;
> +
> +   if (i2c_get_chip(dev->parent, data->addr, data->olen, )) {
> +   printf("i2c_get_chip failed\n");
> +   return -1;

What is this call for? Won't the I2C device already be set up? You
should be able to do:

struct udevice *chip = dev_get_parent_platdata(dev);

> +   }
> +
> +   return dm_i2c_read(chip, offset, buf, size);
>  }
>
>  static int i2c_eeprom_write(struct udevice *dev, int offset,
> @@ -27,23 +37,54 @@ struct i2c_eeprom_ops i2c_eeprom_std_ops = {
> .write  = i2c_eeprom_write,
>  };
>
> +static int i2c_eeprom_std_ofdata_to_platdata(struct udevice *dev)
> +{
> +   int addr, olen;
> +   struct i2c_eeprom *priv = dev_get_priv(dev);
> +   u64 data = dev_get_driver_data(dev);
> +
> +   addr = fdtdec_get_int(gd->fdt_blob, dev->of_offset, "reg", 0);
> +   priv->addr = addr;
> +
> +   olen = fdtdec_get_int(gd->fdt_blob, dev->of_offset,
> + "u-boot,i2c-offset-len", 1);
> +   priv->olen = olen;
> +
> +   /* 6 bit -> page size of up to 2^63 (should be sufficient) */
> +   priv->pagewidth = data & 0x3F;
> +   priv->pagesize = (1 << priv->pagewidth);
> +
> +   return 0;
> +}
> +
>  int i2c_eeprom_std_probe(struct udevice *dev)
>  {
> return 0;
>  }
>
>  static const struct udevice_id i2c_eeprom_std_ids[] = {
> -   { .compatible = "i2c-eeprom" },
> +   { .compatible = "i2c-eeprom", .data = 0 },
> +   { .compatible = "atmel,24c01a", .data = 3 },
> +   { .compatible = "atmel,24c02", .data = 3 },
> +   { .compatible = "atmel,24c04", .data = 4 },
> +   { .compatible = "atmel,24c08a", .data = 4 },
> +   { .compatible = "atmel,24c16a", .data = 4 },
> +   { .compatible = "atmel,24c32", .data = 5 },
> +   { .compatible = "atmel,24c64", .data = 5 },
> +   { .compatible = "atmel,24c128", .data = 6 },
> +   { .compatible = "atmel,24c256", .data = 6 },
> +   { .compatible = "atmel,24c512", .data = 6 },
> { }
>  };
>
>  U_BOOT_DRIVER(i2c_eeprom_std) = {
> -   .name   = "i2c_eeprom",
> -   .id = UCLASS_I2C_EEPROM,
> -   .of_match   = i2c_eeprom_std_ids,
> -   .probe  = i2c_eeprom_std_probe,
> -   .priv_auto_alloc_size = sizeof(struct i2c_eeprom),
> -   .ops= _eeprom_std_ops,
> +   .name   = "i2c_eeprom",
> +   .id = UCLASS_I2C_EEPROM,
> +   .of_match   = i2c_eeprom_std_ids,
> +   .probe  = i2c_eeprom_std_probe,
> +   .ofdata_to_platdata = i2c_eeprom_std_ofdata_to_platdata,
> +   .priv_auto_alloc_size   = sizeof(struct i2c_eeprom),
> +   .ops= _eeprom_std_ops,
>  };
>
>  UCLASS_DRIVER(i2c_eeprom) = {
> diff --git a/include/i2c_eeprom.h b/include/i2c_eeprom.h
> index ea6c962..52f4a6d 100644
> --- a/include/i2c_eeprom.h
> +++ b/include/i2c_eeprom.h
> @@ -14,6 +14,10 @@ struct i2c_eeprom_ops {
>  };
>
>  struct i2c_eeprom {
> +   int addr;
> +   int olen;
> +   unsigned long pagesize;
> + 

Re: [U-Boot] [PATCH] dm: gpio: MPC85XX GPIO platform data support

[Simon Glass]

Hi,

On 31 May 2016 at 14:44, Hamish Martin
 wrote:
> Define a platform data structure for the MPC85XX GPIO driver to allow
> use of the driver without device tree. Users should define the GPIO
> blocks for their platform like this:
>   struct mpc85xx_gpio_plat gpio_blocks[] = {
>  {
>  .addr = 0x13,
>  .ngpios = 32,
>  },
>  {
>  .addr = 0x131000,
>  .ngpios = 32,
>  },
>   };
>
>   U_BOOT_DEVICES(my_platform_gpios) = {
>  { "gpio_mpc85xx", _blocks[0] },
>  { "gpio_mpc85xx", _blocks[1] },
>   };
>
> This is intended to build upon the recent submission of the base
> MPC85XX driver from Mario Six. We need to use that new driver
> without dts support and this patch gives us that flexibility.
> This has been tested on a Freescale T2080 CPU, although only the first
> GPIO block.
>
> Signed-off-by: Hamish Martin 
> Reviewed-by: Mario Six 
> Tested-by: Mario Six 
> ---
>  arch/powerpc/include/asm/arch-mpc85xx/gpio.h |  6 +
>  drivers/gpio/mpc85xx_gpio.c  | 37 
> ++--
>  2 files changed, 36 insertions(+), 7 deletions(-)

Is this a v2/v3 patch? If so, can you please resend it with the version number?

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

Re: [U-Boot] [PATCH v4 2/2] common: usb_storage : Implement logic to calculate optimal usb maximum trasfer blocks

[Simon Glass]

On 9 June 2016 at 00:32, Rajesh Bhagat  wrote:
> From: Rajesh Bhagat 
>
> Implements the logic to calculate the optimal usb maximum trasfer blocks
> instead of sending USB_MAX_XFER_BLK blocks which is 65535 and 20 in case
> of EHCI and other USB protocols respectively.
>
> It defines USB_MIN_XFER_BLK/USB_MAX_XFER_BLK trasfer blocks that should
> be checked for success starting from minimum to maximum, and rest of the
> read/write are performed with that optimal value. It tries to increase/
> decrease the blocks in follwing scenarios:
>
> 1.decrease blocks: when read/write for a particular number of blocks
> fails.
> 2. increase blocks: when read/write for a particular number of blocks
> pass and amount left to trasfer is greater than current number of
> blocks.
>
> Currently changes are done for EHCI where min = 4096 and max = 65535
> is taken. And for other cases code is left unchanged by keeping min
> = max = 20.
>
> Signed-off-by: Sriram Dash 
> Signed-off-by: Rajesh Bhagat 
> ---
> Changes in v4:
>  - Adds udev paramater in dec/inc_cur_xfer_blks function and adds
>sanity check on it.
>  - Changes type of pos varible to unsigned int in dec/inc_cur_xfer_blks
>  - Removes usage of pos varible from usb_stor_read/write
>
> Changes in v3:
>  - Adds cur_xfer_blks in struct usb_device to retain values
>  - Adds functions dec/inc_cur_xfer_blks to remove code duplication
>  - Moves check from macro to calling functions
>
> Changes in v2:
>  - Removes table to store blocks and use formula (1 << (12 + n)) - 1
>  - Adds logic to start from minimum, go to maximum in each read/write
>
>  common/usb_storage.c | 68 
> 
>  include/usb.h|  1 +
>  2 files changed, 64 insertions(+), 5 deletions(-)

Reviewed-by: Simon Glass 

I'm not keen on the 'unsigned short' for the size. Perhaps add a
comment to your 65535 #define that it cannot go higher?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 9/9] tests: Introduce DT overlay tests

[Simon Glass]

On 27 May 2016 at 03:13, Maxime Ripard  wrote:
> This adds a bunch of unit tests for the "fdt apply" command.
>
> They've all been run successfully in the sandbox. However, as you still
> require an out-of-tree dtc with overlay support, this is disabled by
> default.
>
> Signed-off-by: Maxime Ripard 
> ---
>  Makefile  |   1 +
>  include/test/overlay.h|  16 
>  include/test/suites.h |   1 +
>  test/Kconfig  |   1 +
>  test/cmd_ut.c |   6 ++
>  test/overlay/Kconfig  |  10 +++
>  test/overlay/Makefile |  15 
>  test/overlay/cmd_ut_overlay.c | 176 
> ++
>  test/overlay/test-fdt-base.dts|  17 
>  test/overlay/test-fdt-overlay.dts |  60 +
>  10 files changed, 303 insertions(+)
>  create mode 100644 include/test/overlay.h
>  create mode 100644 test/overlay/Kconfig
>  create mode 100644 test/overlay/Makefile
>  create mode 100644 test/overlay/cmd_ut_overlay.c
>  create mode 100644 test/overlay/test-fdt-base.dts
>  create mode 100644 test/overlay/test-fdt-overlay.dts

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

Re: [U-Boot] [PATCH v2 8/9] cmd: fdt: add fdt overlay application subcommand

[Simon Glass]

Hi Maxime,

On 27 May 2016 at 03:13, Maxime Ripard  wrote:
> The device tree overlays are a good way to deal with user-modifyable

nit: modifiable

> boards or boards with some kind of an expansion mechanism where we can
> easily plug new board in (like the BBB or the raspberry pi).
>
> However, so far, the usual mechanism to deal with it was to have in Linux
> some driver detecting the expansion boards plugged in and then request
> these overlays using the firmware interface.
>
> That works in most cases, but in some cases, you might want to have the
> overlays applied before the userspace comes in. Either because the new
> board requires some kind of an early initialization, or because your root
> filesystem is accessed through that expansion board.
>
> The easiest solution in such a case is to simply have the component before
> Linux applying that overlay, removing all these drawbacks.
>
> Signed-off-by: Maxime Ripard 
> ---
>  cmd/fdt.c | 20 
>  1 file changed, 20 insertions(+)

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

Re: [U-Boot] [PATCH v2 2/4] usb: dwc3: Add helper functions to enable snooping and burst settings

[Simon Glass]

Hi,

On 6 June 2016 at 03:16, Rajat Srivastava  wrote:
> Adds helper functions to enable snooping and outstanding burst beat
> settings.
>
> Signed-off-by: Rajat Srivastava 
> Signed-off-by: Rajesh Bhagat 
> ---
> Changes in v2:
>  - Removes SoC specific flags and added helper functions
>
>  drivers/usb/dwc3/core.c | 45 +
>  drivers/usb/dwc3/core.h |  7 +++
>  2 files changed, 52 insertions(+)
>
> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> index 85cc96a..0b3c596 100644
> --- a/drivers/usb/dwc3/core.c
> +++ b/drivers/usb/dwc3/core.c
> @@ -599,6 +599,51 @@ static void dwc3_core_exit_mode(struct dwc3 *dwc)
>
>  #define DWC3_ALIGN_MASK(16 - 1)
>
> +void dwc3_core_incr_burst_enable(int index, int btype_incr_val,
> +int breq_limit)
> +{
> +   struct dwc3 *dwc;
> +   u32 reg;
> +
> +   list_for_each_entry(dwc, _list, list) {

Ick - can this be converted to use driver model?

> +   if (dwc->index != index)
> +   continue;
> +
> +   /*
> +* Change burst beat and outstanding pipelined
> +* transfers requests
> +*/
> +   reg = dwc3_readl(dwc->regs, DWC3_GSBUSCFG0);
> +   reg = (reg & ~DWC3_INCR_BTYPE_MASK) | btype_incr_val;
> +   dwc3_writel(dwc->regs, DWC3_GSBUSCFG0, reg);
> +
> +   reg = dwc3_readl(dwc->regs, DWC3_GSBUSCFG1);
> +   reg = (reg & ~DWC3_BREQ_LIMIT_MASK) | (breq_limit << 8);
> +   dwc3_writel(dwc->regs, DWC3_GSBUSCFG1, reg);
> +   break;
> +   }
> +}
> +
> +void dwc3_core_set_snooping(int index, bool snoop)
> +{
> +   struct dwc3 *dwc;
> +   u32 reg;
> +
> +   list_for_each_entry(dwc, _list, list) {
> +   if (dwc->index != index)
> +   continue;
> +
> +   /* Enable/Disable snooping */
> +   reg = dwc3_readl(dwc->regs, DWC3_GSBUSCFG0);
> +   if (snoop)
> +   reg = reg | DWC3_SNOOP_ENABLE;
> +   else
> +   reg = reg & ~DWC3_SNOOP_ENABLE;
> +   dwc3_writel(dwc->regs, DWC3_GSBUSCFG0, reg);
> +   break;
> +   }
> +}
> +
>  /**
>   * dwc3_uboot_init - dwc3 core uboot initialization code
>   * @dwc3_dev: struct dwc3_device containing initialization data
> diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
> index 72d2fcd..455e7fa 100644
> --- a/drivers/usb/dwc3/core.h
> +++ b/drivers/usb/dwc3/core.h
> @@ -593,6 +593,13 @@ struct dwc3_hwparams {
>  /* HWPARAMS7 */
>  #define DWC3_RAM1_DEPTH(n) ((n) & 0x)
>
> +/* GSBUSCFG0 */
> +#define DWC3_SNOOP_ENABLE  (0x)
> +#define DWC3_INCR_BTYPE_MASK   (0xff)
> +
> +/* GSBUSCFG1 */
> +#define DWC3_BREQ_LIMIT_MASK   (0xf00)
> +
>  struct dwc3_request {
> struct usb_request  request;
> struct list_headlist;
> --
> 2.6.2.198.g614a2ac
>

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

Re: [U-Boot] [RFC][PATCH] arm: rk: Drop SYS_MALLOC_F and SPL_SYS_MALLOC_SIMPLE

[Simon Glass]

Hi Marek,

On 8 June 2016 at 07:18, Marek Vasut  wrote:
> On 06/08/2016 06:44 AM, Simon Glass wrote:
>> Hi Marek,
>>
>> On 7 June 2016 at 20:02, Marek Vasut  wrote:
>>> On 06/08/2016 04:43 AM, Simon Glass wrote:
 Hi Marek,
>>>
>>> Hi!
>>>
 On 25 May 2016 at 05:26, Marek Vasut  wrote:
> On 05/25/2016 05:29 AM, Simon Glass wrote:
>> Hi Marek,
>>
>> On 24 May 2016 at 18:15, Marek Vasut  wrote:
>>> Both SYS_MALLOC_F and SPL_SYS_MALLOC_SIMPLE are generic config options,
>>> drop them from the rockchip-specific Kconfig file.
>>>
>>> Signed-off-by: Marek Vasut 
>>> Cc: Tom Rini 
>>> Cc: Simon Glass 
>>> ---
>>>  arch/arm/mach-rockchip/Kconfig | 6 --
>>>  1 file changed, 6 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-rockchip/Kconfig 
>>> b/arch/arm/mach-rockchip/Kconfig
>>> index d3bddb7..5f6046a 100644
>>> --- a/arch/arm/mach-rockchip/Kconfig
>>> +++ b/arch/arm/mach-rockchip/Kconfig
>>> @@ -17,12 +17,6 @@ config ROCKCHIP_RK3036
>>>   and video codec support. Peripherals include Gigabit Ethernet,
>>>   USB2 host and OTG, SDIO, I2S, UART, SPI, I2C and PWMs.
>>>
>>> -config SYS_MALLOC_F
>>> -   default y
>>> -
>>> -config SPL_SYS_MALLOC_SIMPLE
>>> -   default y
>>> -
>>>  config SPL_DM
>>> default y
>>>
>>> --
>>> 2.7.0
>>>
>>
>> Will these still be enabled some other way?
>
> That's why it's RFC, I believe the rockchip platforms would need to add
> those to their defconfig, right ?

 Well, Rockchip boards cannot work without these, which is why they default 
 to y.
>>>
>>> I understand that, but these Kconfig options are generic, so they
>>> shouldn't be defined in the mach-rockchip/Kconfig file, but in some
>>> generic Kconfig file and then selected by ARCH_ROCKCHIP symbol or in
>>> some defconfig , right ?
>>
>> They are not being defined, just their default value is being set.
>
> Checking with git grep, they are defined in the top-level Kconfig.
> I recall when I tried using those on mips, it complained about the
> entries in mach-rockchip though. So why are the defaults selected
> this way instead of using "select" in ARCH_ROCKCHIP symbol ? Isn't
> that how it's usually done ?

That's odd, because these are inside an 'if ARCH_ROCKCHIP' clause. But
I'm fine with moving to 'select' for these if that is better. It is
unlikely anyone would want to disable these. But as it stands, your
patch breaks things :-)

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

Re: [U-Boot] [PATCH v2 3/9] vsprintf: Include stdarg for va_list

[Simon Glass]

On 27 May 2016 at 03:13, Maxime Ripard  wrote:
> vsprintf.h doesn't include the stdarg.h file, which means that it relies on
> the files that include vsprintf.h to include stdarg.h as well.
>
> Add an explicit include to avoid build errors when simply including that
> file.
>
> Signed-off-by: Maxime Ripard 
> ---
>  include/vsprintf.h | 2 ++
>  1 file changed, 2 insertions(+)

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

Re: [U-Boot] [PATCH v2 4/9] libfdt: Add new headers and defines

[Simon Glass]

Hi Maxime,

On 27 May 2016 at 03:13, Maxime Ripard  wrote:
> The libfdt overlay support introduces a bunch of new includes and
> functions.
>
> Make sure we are able to build it by adding the needed glue.
>
> Signed-off-by: Maxime Ripard 
> ---
>  include/libfdt_env.h | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/include/libfdt_env.h b/include/libfdt_env.h
> index 273b5d30f867..2d2196031332 100644
> --- a/include/libfdt_env.h
> +++ b/include/libfdt_env.h
> @@ -23,6 +23,13 @@ typedef __be64 fdt64_t;
>  #define fdt64_to_cpu(x)be64_to_cpu(x)
>  #define cpu_to_fdt64(x)cpu_to_be64(x)
>
> +#ifdef __UBOOT__
> +#include "malloc.h"
> +#include "vsprintf.h"

Can we use  and  instead?

> +
> +#define strtol(cp, endp, base) simple_strtol(cp, endp, base)
> +#endif
> +
>  /* adding a ramdisk needs 0x44 bytes in version 2008.10 */
>  #define FDT_RAMDISK_OVERHEAD   0x80
>
> --
> 2.8.2
>

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

Re: [U-Boot] [PATCH v2 1/9] cmd: fdt: Narrow the check for fdt addr

[Simon Glass]

On 27 May 2016 at 03:13, Maxime Ripard  wrote:
> The current code only checks if the fdt subcommand is fdt addr by checking
> whether it starts with 'a'.
>
> Since this is a pretty widely used letter, narrow down that check a bit.
>
> Signed-off-by: Maxime Ripard 
> ---
>  cmd/fdt.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

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

Re: [U-Boot] [PATCH v2 2/9] scripts: Makefile.lib: Sanitize DTB names

[Simon Glass]

On 27 May 2016 at 03:13, Maxime Ripard  wrote:
> Having dashes as a separator in the DTB name is a quite common practice.
>
> However, the current code to generate objects from DTBs assumes the
> separator is an underscore, leading to a compilation error when building a
> device tree with dashes.
>
> Replace all the dashes in the DTB name to generate the symbols name, which
> should solve this issue.
>
> Signed-off-by: Maxime Ripard 
> ---
>  scripts/Makefile.lib | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)

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

Re: [U-Boot] [PATCH 2/3] serial: 16550: Add port type as driver data

[Simon Glass]

On 26 May 2016 at 12:39, Marek Vasut  wrote:
> Add driver data to each compatible string to identify the type of
> the port. Since all the ports in the driver are entirely compatible
> with 16550 for now, all are marked with PORT_NS16550. But, there
> are ports which have specific quirks, like the JZ4780 UART, which
> do not have any DT property to denote the quirks. Instead, Linux
> uses the compatible string to discern such ports and enable the
> necessary quirks.
>
> Signed-off-by: Marek Vasut 
> Cc: Tom Rini 
> Cc: Simon Glass 
> ---
>  drivers/serial/ns16550.c | 24 ++--
>  1 file changed, 14 insertions(+), 10 deletions(-)

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

Re: [U-Boot] [PATCH] mmc: Tinification of the mmc code

[Simon Glass]

Hi Marek,

On 26 May 2016 at 12:41, Marek Vasut  wrote:
> Add new configuration option CONFIG_MMC_TINY which strips away all
> memory allocation within the MMC code and code for handling multiple
> cards. This allows extremely space-constrained SPL code use the MMC
> framework.
>
> Signed-off-by: Marek Vasut 
> Cc: Tom Rini 
> Cc: Simon Glass 
> ---
>  common/spl/spl_mmc.c |  4 
>  drivers/mmc/Makefile |  2 ++
>  drivers/mmc/mmc.c| 59 
> +++-
>  include/mmc.h|  1 +
>  4 files changed, 65 insertions(+), 1 deletion(-)

Can CONFIG_MMC_TINY be a Kconfig? Also I suggest CONFIG_SPL_MMC_TINY.

>
> diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
> index ae42221..51f0f24 100644
> --- a/common/spl/spl_mmc.c
> +++ b/common/spl/spl_mmc.c
> @@ -300,7 +300,11 @@ int spl_mmc_load_image(u32 boot_device)
> if (part == 7)
> part = 0;
>
> +#ifdef CONFIG_MMC_TINY

if (CONFIG_IS_ENABLED(MMC_TINY))

to avoid #ifdef

> +   err = mmc_switch_part(mmc, part);
> +#else
> err = blk_dselect_hwpart(mmc_get_blk_desc(mmc), part);
> +#endif
> if (err) {
>  #ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
> puts("spl: mmc partition switch failed\n");
> diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
> index 3da4817..4d986cb 100644
> --- a/drivers/mmc/Makefile
> +++ b/drivers/mmc/Makefile
> @@ -10,8 +10,10 @@ obj-$(CONFIG_GENERIC_MMC) += mmc-uclass.o
>  endif
>
>  ifndef CONFIG_BLK
> +ifndef CONFIG_MMC_TINY
>  obj-$(CONFIG_GENERIC_MMC) += mmc_legacy.o
>  endif
> +endif
>
>  obj-$(CONFIG_ARM_PL180_MMCI) += arm_pl180_mmci.o
>  obj-$(CONFIG_ATMEL_SDHCI) += atmel_sdhci.o
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index d687345..1f240ed 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -21,6 +21,29 @@
>  #include 
>  #include "mmc_private.h"
>
> +#if defined(CONFIG_MMC_TINY)
> +static struct mmc mmc_static;
> +struct mmc *find_mmc_device(int dev_num)
> +{
> +   return _static;
> +}
> +
> +void mmc_do_preinit(void)
> +{
> +   struct mmc *m = _static;
> +#ifdef CONFIG_FSL_ESDHC_ADAPTER_IDENT
> +   mmc_set_preinit(m, 1);
> +#endif
> +   if (m->preinit)
> +   mmc_start_init(m);
> +}
> +
> +struct blk_desc *mmc_get_blk_desc(struct mmc *mmc)
> +{
> +   return >block_dev;
> +}
> +#endif
> +
>  __weak int board_mmc_getwp(struct mmc *mmc)
>  {
> return -1;
> @@ -238,7 +261,11 @@ static ulong mmc_bread(struct blk_desc *block_dev, 
> lbaint_t start,
> if (!mmc)
> return 0;
>
> +#ifdef CONFIG_MMC_TINY
> +   err = mmc_switch_part(mmc, block_dev->hwpart);
> +#else
> err = blk_dselect_hwpart(block_dev, block_dev->hwpart);
> +#endif
> if (err < 0)
> return 0;
>
> @@ -568,7 +595,7 @@ static int mmc_set_capacity(struct mmc *mmc, int part_num)
> return 0;
>  }
>
> -static int mmc_switch_part(struct mmc *mmc, unsigned int part_num)
> +int mmc_switch_part(struct mmc *mmc, unsigned int part_num)
>  {
> int ret;
>
> @@ -1585,6 +1612,34 @@ int mmc_unbind(struct udevice *dev)
> return 0;
>  }
>
> +#elif defined(CONFIG_MMC_TINY)
> +static struct mmc mmc_static = {
> +   .dsr_imp= 0,
> +   .dsr= 0x,
> +   .block_dev = {
> +   .if_type= IF_TYPE_MMC,
> +   .removable  = 1,
> +   .devnum = 0,
> +   .block_read = mmc_bread,
> +   .block_write= mmc_bwrite,
> +   .block_erase= mmc_berase,
> +   .part_type  = 0,
> +   },
> +};
> +
> +struct mmc *mmc_create(const struct mmc_config *cfg, void *priv)
> +{
> +   struct mmc *mmc = _static;
> +
> +   mmc->cfg = cfg;
> +   mmc->priv = priv;
> +
> +   return mmc;
> +}
> +
> +void mmc_destroy(struct mmc *mmc)
> +{
> +}
>  #else
>  struct mmc *mmc_create(const struct mmc_config *cfg, void *priv)
>  {
> @@ -1834,8 +1889,10 @@ int mmc_initialize(bd_t *bis)
> initialized = 1;
>
>  #ifndef CONFIG_BLK
> +#ifndef CONFIG_MMC_TINY
> mmc_list_init();
>  #endif
> +#endif
> ret = mmc_probe(bis);
> if (ret)
> return ret;
> diff --git a/include/mmc.h b/include/mmc.h
> index a5c6573..08a59c2 100644
> --- a/include/mmc.h
> +++ b/include/mmc.h
> @@ -444,6 +444,7 @@ struct mmc *find_mmc_device(int dev_num);
>  int mmc_set_dev(int dev_num);
>  void print_mmc_devices(char separator);
>  int get_mmc_num(void);
> +int mmc_switch_part(struct mmc *mmc, unsigned int part_num);
>  int mmc_hwpart_config(struct mmc *mmc, const struct mmc_hwpart_conf *conf,
>   enum mmc_hwpart_conf_mode mode);
>  int mmc_getcd(struct mmc *mmc);
> --
> 2.7.0
>

This is partially undoing 

Re: [U-Boot] [PATCH 3/3] serial: 16550: Add Ingenic JZ4780 support

[Simon Glass]

On 26 May 2016 at 12:39, Marek Vasut  wrote:
> Add compatibility string for the Ingenic JZ4780 SoC, the necessary
> UART enable bit into FCR and register shift. Neither are encoded
> in the DTS coming from Linux, so we need to support it this way.
>
> Signed-off-by: Marek Vasut 
> Cc: Tom Rini 
> Cc: Simon Glass 
> Cc: Daniel Schwierzeck 
> Cc: Paul Burton 
> ---
>  drivers/serial/ns16550.c | 7 +++
>  include/ns16550.h| 3 +++
>  2 files changed, 10 insertions(+)

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

Re: [U-Boot] [PATCH v2 2/2] clk: at91: Add new clock driver

[Simon Glass]

+Stephen

Hi Wenyou,

On 7 June 2016 at 01:11, Wenyou Yang  wrote:
> The patch is referred to at91 clock driver of Linux, to make
> the clock node descriptions in dt are aligned with the Linux.
>
> Signed-off-by: Wenyou Yang 
> ---
>
> Changes in v2:
>  - Remove the redundant log print.
>
>  arch/arm/mach-at91/include/mach/at91_pmc.h |  11 ++-
>  drivers/clk/Kconfig|   1 +
>  drivers/clk/Makefile   |   1 +
>  drivers/clk/at91/Kconfig   |  14 +++
>  drivers/clk/at91/Makefile  |  11 +++
>  drivers/clk/at91/clk-generated.c   | 138 
> +
>  drivers/clk/at91/clk-h32mx.c   |  56 
>  drivers/clk/at91/clk-main.c|  55 
>  drivers/clk/at91/clk-master.c  |  33 +++
>  drivers/clk/at91/clk-peripheral.c  |  68 ++
>  drivers/clk/at91/clk-plla.c|  55 
>  drivers/clk/at91/clk-slow.c|  37 
>  drivers/clk/at91/clk-system.c  |  65 ++
>  drivers/clk/at91/clk-utmi.c|  67 ++
>  drivers/clk/at91/pmc.c |  49 ++
>  drivers/clk/at91/pmc.h |  17 
>  drivers/clk/at91/sckc.c|  30 +++
>  17 files changed, 705 insertions(+), 3 deletions(-)
>  create mode 100644 drivers/clk/at91/Kconfig
>  create mode 100644 drivers/clk/at91/Makefile
>  create mode 100644 drivers/clk/at91/clk-generated.c
>  create mode 100644 drivers/clk/at91/clk-h32mx.c
>  create mode 100644 drivers/clk/at91/clk-main.c
>  create mode 100644 drivers/clk/at91/clk-master.c
>  create mode 100644 drivers/clk/at91/clk-peripheral.c
>  create mode 100644 drivers/clk/at91/clk-plla.c
>  create mode 100644 drivers/clk/at91/clk-slow.c
>  create mode 100644 drivers/clk/at91/clk-system.c
>  create mode 100644 drivers/clk/at91/clk-utmi.c
>  create mode 100644 drivers/clk/at91/pmc.c
>  create mode 100644 drivers/clk/at91/pmc.h
>  create mode 100644 drivers/clk/at91/sckc.c
>
> diff --git a/arch/arm/mach-at91/include/mach/at91_pmc.h 
> b/arch/arm/mach-at91/include/mach/at91_pmc.h
> index 7684f09..d02f3e1 100644
> --- a/arch/arm/mach-at91/include/mach/at91_pmc.h
> +++ b/arch/arm/mach-at91/include/mach/at91_pmc.h
> @@ -149,6 +149,9 @@ typedef struct at91_pmc {
>
>  #define AT91_PMC_PCR_PID_MASK  (0x3f)
>  #define AT91_PMC_PCR_GCKCSS(0x7 << 8)
> +#define AT91_PMC_PCR_GCKCSS_MASK   0x07
> +#define AT91_PMC_PCR_GCKCSS_OFFSET 8
> +#define AT91_PMC_PCR_GCKCSS_(x)((x & 0x07) << 8)
>  #defineAT91_PMC_PCR_GCKCSS_SLOW_CLK(0x0 << 8)
>  #defineAT91_PMC_PCR_GCKCSS_MAIN_CLK(0x1 << 8)
>  #defineAT91_PMC_PCR_GCKCSS_PLLA_CLK(0x2 << 8)
> @@ -158,8 +161,9 @@ typedef struct at91_pmc {
>  #define AT91_PMC_PCR_CMD_WRITE (0x1 << 12)
>  #define AT91_PMC_PCR_DIV   (0x3 << 16)
>  #define AT91_PMC_PCR_GCKDIV(0xff << 20)
> -#defineAT91_PMC_PCR_GCKDIV_(x) ((x & 0xff) << 20)
> -#defineAT91_PMC_PCR_GCKDIV_OFFSET  20
> +#define AT91_PMC_PCR_GCKDIV_MASK   0xff
> +#define AT91_PMC_PCR_GCKDIV_OFFSET 20
> +#define AT91_PMC_PCR_GCKDIV_(x)((x & 0xff) << 20)
>  #define AT91_PMC_PCR_EN(0x1 << 28)
>  #define AT91_PMC_PCR_GCKEN (0x1 << 29)
>
> @@ -243,8 +247,9 @@ typedef struct at91_pmc {
>  #defineAT91_PMC_PCK1RDY(1 <<  9)   /* 
> Programmable Clock 1 */
>  #defineAT91_PMC_PCK2RDY(1 << 10)   /* 
> Programmable Clock 2 */
>  #defineAT91_PMC_PCK3RDY(1 << 11)   /* 
> Programmable Clock 3 */
> +#defineAT91_PMC_MOSCSELS   BIT(16) /* 
> Main Oscillator Selection Status */
> +#defineAT91_PMC_MOSCRCSBIT(17) /* 12 
> MHz RC Oscillator Status */
>  #defineAT91_PMC_GCKRDY (1 << 24)
> -
>  #defineAT91_PMC_PROTKEY0x504d4301  /* Activation 
> Code */
>
>  /* PLL Charge Pump Current Register (PMC_PLLICPR) */
> diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
> index a98b74b..1fd1074 100644
> --- a/drivers/clk/Kconfig
> +++ b/drivers/clk/Kconfig
> @@ -21,5 +21,6 @@ config SPL_CLK
>   used as U-Boot proper.
>
>  source "drivers/clk/uniphier/Kconfig"
> +source "drivers/clk/at91/Kconfig"
>
>  endmenu
> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> index c51db15..2bb0f35 100644
> --- a/drivers/clk/Makefile
> +++ b/drivers/clk/Makefile
> @@ -11,3 +11,4 @@ obj-$(CONFIG_ROCKCHIP_RK3288) += clk_rk3288.o
>  obj-$(CONFIG_SANDBOX) += clk_sandbox.o
>  obj-$(CONFIG_MACH_PIC32) += clk_pic32.o
>  obj-$(CONFIG_CLK_UNIPHIER) += uniphier/
> 

Re: [U-Boot] [PATCH 1/3] serial: 16550: Add getfcr accessor

[Simon Glass]

Hi Marek,

On 26 May 2016 at 12:39, Marek Vasut  wrote:
> Add function which allows fetching the default FCR register setting
> from platform data for DM , while retaining old behavior for non-DM
> by returning UART_FCRVAL.
>
> Signed-off-by: Marek Vasut 
> Cc: Tom Rini 
> Cc: Simon Glass 
> ---
>  drivers/serial/ns16550.c | 20 +---
>  include/ns16550.h|  1 +
>  2 files changed, 18 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
> index c6cb3eb..b39ce02 100644
> --- a/drivers/serial/ns16550.c
> +++ b/drivers/serial/ns16550.c
> @@ -120,6 +120,13 @@ static int ns16550_readb(NS16550_t port, int offset)
> return serial_in_shift(addr + plat->reg_offset, plat->reg_shift);
>  }
>
> +static u32 ns16550_getfcr(NS16550_t port)
> +{
> +   struct ns16550_platdata *plat = port->plat;
> +
> +   return plat->fcr;
> +}
> +
>  /* We can clean these up once everything is moved to driver model */
>  #define serial_out(value, addr)\
> ns16550_writeb(com_port, \
> @@ -127,6 +134,11 @@ static int ns16550_readb(NS16550_t port, int offset)
>  #define serial_in(addr) \
> ns16550_readb(com_port, \
> (unsigned char *)addr - (unsigned char *)com_port)
> +#else
> +static u32 ns16550_getfcr(NS16550_t port)
> +{
> +   return UART_FCRVAL;
> +}
>  #endif
>
>  int ns16550_calc_divisor(NS16550_t port, int clock, int baudrate)
> @@ -170,7 +182,7 @@ void NS16550_init(NS16550_t com_port, int baud_divisor)
> serial_out(0x7, _port->mdr1);   /* mode select reset 
> TL16C750*/
>  #endif
> serial_out(UART_MCRVAL, _port->mcr);
> -   serial_out(UART_FCRVAL, _port->fcr);
> +   serial_out(ns16550_getfcr(com_port), _port->fcr);
> if (baud_divisor != -1)
> NS16550_setbrg(com_port, baud_divisor);
>  #if defined(CONFIG_OMAP) || \
> @@ -191,7 +203,7 @@ void NS16550_reinit(NS16550_t com_port, int baud_divisor)
> serial_out(CONFIG_SYS_NS16550_IER, _port->ier);
> NS16550_setbrg(com_port, 0);
> serial_out(UART_MCRVAL, _port->mcr);
> -   serial_out(UART_FCRVAL, _port->fcr);
> +   serial_out(ns16550_getfcr(com_port), _port->fcr);
> NS16550_setbrg(com_port, baud_divisor);
>  }
>  #endif /* CONFIG_NS16550_MIN_FUNCTIONS */
> @@ -262,7 +274,7 @@ static inline void _debug_uart_init(void)
> CONFIG_BAUDRATE);
> serial_dout(_port->ier, CONFIG_SYS_NS16550_IER);
> serial_dout(_port->mcr, UART_MCRVAL);
> -   serial_dout(_port->fcr, UART_FCRVAL);
> +   serial_dout(_port->fcr, ns16550_getfcr(com_port));

The debug UART does not have platdata, so I don't think this will
work. For the debug UART perhaps you can use the default value. If
not, then I think the only option is a new debug UART Kconfig.

>
> serial_dout(_port->lcr, UART_LCR_BKSE | UART_LCRVAL);
> serial_dout(_port->dll, baud_divisor & 0xff);
> @@ -405,6 +417,8 @@ int ns16550_serial_ofdata_to_platdata(struct udevice *dev)
> return -EINVAL;
> }
>
> +   plat->fcr = UART_FCRVAL;
> +
> return 0;
>  }
>  #endif
> diff --git a/include/ns16550.h b/include/ns16550.h
> index 1311f4c..45fd68b 100644
> --- a/include/ns16550.h
> +++ b/include/ns16550.h
> @@ -57,6 +57,7 @@ struct ns16550_platdata {
> int reg_shift;
> int clock;
> int reg_offset;
> +   u32 fcr;
>  };
>
>  struct udevice;
> --
> 2.7.0
>

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

Re: [U-Boot] [PATCH v2 1/2] clk: clk-uclass: Add post binding for CLK uclass

[Simon Glass]

Hi Wenyou,

On 7 June 2016 at 01:11, Wenyou Yang  wrote:
> Add post binding support for CLK uclass to recursively bind
> its children as clk devices.
>
> Signed-off-by: Wenyou Yang 
> ---
>
> Changes in v2: None
>
>  drivers/clk/clk-uclass.c | 51 
> 
>  1 file changed, 51 insertions(+)


Can you please explain what this is for? We would normally call
dm_scan_fdt_node() for this, but it seems that you are specifically to
create drivers for things with no compatible strings.

>
> diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
> index b483c1e..ee568e4 100644
> --- a/drivers/clk/clk-uclass.c
> +++ b/drivers/clk/clk-uclass.c
> @@ -106,7 +106,58 @@ int clk_get_by_index(struct udevice *dev, int index, 
> struct udevice **clk_devp)
>  }
>  #endif
>
> +/**
> + * clk_post-bind() - post binding for CLK uclass
> + * Recursively bind its children as clk devices.
> + *
> + * @dev: clk device
> + * @return: 0 on success, or negative error code on failure
> + */
> +static int clk_post_bind(struct udevice *dev)
> +{
> +   const void *fdt = gd->fdt_blob;
> +   int offset = dev->of_offset;
> +   bool pre_reloc_only = !(gd->flags & GD_FLG_RELOC);
> +   const char *name;
> +   int ret;
> +
> +   for (offset = fdt_first_subnode(fdt, offset);
> +offset > 0;
> +offset = fdt_next_subnode(fdt, offset)) {
> +   if (pre_reloc_only &&
> +   !fdt_getprop(fdt, offset, "u-boot,dm-pre-reloc", NULL))
> +   continue;
> +   /*
> +* If this node has "compatible" property, this is not a clk
> +* node, but a normal device. skip.
> +*/
> +   fdt_get_property(fdt, offset, "compatible", );
> +   if (ret >= 0)
> +   continue;
> +
> +   if (ret != -FDT_ERR_NOTFOUND)
> +   return ret;
> +
> +   name = fdt_get_name(fdt, offset, NULL);
> +   if (!name)
> +   return -EINVAL;
> +
> +   ret = device_bind_driver_to_node(dev, "clk", name,
> +offset, NULL);
> +   if (ret)
> +   return ret;
> +   }
> +
> +   return 0;
> +}
> +
>  UCLASS_DRIVER(clk) = {
> .id = UCLASS_CLK,
> +   .post_bind  = clk_post_bind,
> .name   = "clk",
>  };
> +
> +U_BOOT_DRIVER(clk_generic) = {
> +   .id = UCLASS_CLK,
> +   .name   = "clk",
> +};
> --
> 2.7.4
>

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

Re: [U-Boot] [PATCH v2 2/2] nand: extend nand torture

[Benoît Thébaudeau]

Hi Max,

On Thu, Jun 9, 2016 at 3:19 PM, Max Krummenacher  wrote:
> Hi Benoît,
>
> 2016-06-09 1:41 GMT+02:00 Benoît Thébaudeau :
>> On Tue, Jun 7, 2016 at 1:46 PM, Max Krummenacher  
>> wrote:
>>> diff --git a/cmd/nand.c b/cmd/nand.c
>>> index 583a18f..8ade5e2 100644
>>> --- a/cmd/nand.c
>>> +++ b/cmd/nand.c
[...]
>> +if (argc > 3 && !str2off(argv[3], )) {
>
> Here I prefer having that in 2 if() as the stuff tested is only loosely 
> related.

Usually, we keep things as compact as possible, which also limits the
number of indentation levels, but that's fine if you prefer otherwise.
I don't think it's a strong rule.

> I guess keeping it like this would also require parantheses around (argc > 3).

No: `>` has higher precedence than `&&`.

> Will revert to two if's in v3
>
>> +puts("Size is not a valid number\n");
>> +return 1;
>> +}
>>
>> -return ret == 0 ? 0 : 1;
>> +endoff = off + size;
>> +if (endoff > mtd->size) {
>> +puts("Arguments beyond end of NAND\n");
>> +return 1;
>> +}
>> +
>> +off = round_down(off, mtd->erasesize);
>> +endoff = round_up(endoff, mtd->erasesize);
>> +size = endoff - off;
>> +printf("\nNAND torture: device %d offset 0x%llx size 0x%llx "
>> +"(block size 0x%x)\n",
>
> patman.py/checkpatch.py warn here to keep quoted strings on one line
> even when the line length exceeds 80 characters.
> Will remove the line break / string concatenation for v3.

Normally, this rule is for grep-ability. Here, it's more complicated
with the '%' in-between, but it's still makes sense with a regular
expression, so OK.

>> +dev, off, size, mtd->erasesize);
>> +while (off < endoff) {
>> +ret = nand_torture(mtd, off);
>> +if (ret) {
>> +failed++;
>> +printf("  block at 0x%llx failed\n", off);
>> +} else {
>> +passed++;
>> +}
>> +off += mtd->erasesize;
>> +}
>> +printf(" Passed: %u, failed: %u\n", passed, failed);
>> +return failed != 0;
>>
>>> }
>>>  #endif
>
> Apart from above comments I merged your proposal.
>
>>>
>>> @@ -775,7 +792,8 @@ static char nand_help_text[] =
> ...
>>> diff --git a/doc/README.nand b/doc/README.nand
>>> index 96ffc48..5136f31 100644
>>> --- a/doc/README.nand
>>> +++ b/doc/README.nand
>>> @@ -307,7 +307,7 @@ Miscellaneous and testing commands:
>>>DANGEROUS!!! Factory set bad blocks will be lost. Use only
>>>to remove artificial bad blocks created with the "markbad" command.
>>>
>>> -  "torture offset"
>>> +  "torture offset [size]"
>>>Torture block to determine if it is still reliable.
>>>Enabled by the CONFIG_CMD_NAND_TORTURE configuration option.
>>>This command returns 0 if the block is still reliable, else 1.
>>> @@ -324,6 +324,10 @@ Miscellaneous and testing commands:
>>>automate actions following a nand->write() error. This would e.g. be 
>>> required
>>>in order to program or update safely firmware to NAND, especially for 
>>> the UBI
>>>part of such firmware.
>>> +  Optionally a second parameter size can be given to test multiple blocks 
>>> with
>>
>> "Optionally,"
>>
>>> +  one call. If size is not a multiple of the NAND's erasesize then the 
>>> block
>>
>> "erase size, then"
>>
>>> +  which contains offset + size will be tested in full. If used with size 
>>> this
>>
>> "that", not "which".
>> "size, this"
>>
>
> Agreed. Will add that to v3.

Thanks.

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

Re: [U-Boot] [PATCH v2 1/2] nand: nand torture: follow sync with linux v4.6

[Scott Wood]

On Thu, 2016-06-09 at 23:13 +0200, Max Krummenacher wrote:
> Am Donnerstag, den 09.06.2016, 12:10 -0500 schrieb Scott Wood:
> > On Thu, 2016-06-09 at 10:35 +0200, Max Krummenacher wrote:
> > > Hi Scott
> > > 
> > > 2016-06-09 1:47 GMT+02:00 Scott Wood :
> > > > On 06/07/2016 06:47 AM, Max Krummenacher wrote:
> > > > > follow parameter name change (nand to mtd) to fix compiler
> > > > > error.
> > > > > 
> > > > > Signed-off-by: Max Krummenacher 
> > > > > 
> > > > > ---
> > > > > 
> > > > > Changes in v2:
> > > > > - Patch v1 1/1 went into master, but Scott's patch series
> > > > > syncing
> > > > >   with kernel v4.6 introduced an additional compile time error.
> > > > > 
> > > > >  drivers/mtd/nand/nand_util.c | 2 +-
> > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/drivers/mtd/nand/nand_util.c
> > > > > b/drivers/mtd/nand/nand_util.c
> > > > > index 5bba66a..e8bcc34 100644
> > > > > --- a/drivers/mtd/nand/nand_util.c
> > > > > +++ b/drivers/mtd/nand/nand_util.c
> > > > > @@ -820,7 +820,7 @@ int nand_torture(struct mtd_info *mtd,
> > > > > loff_t
> > > > > offset)
> > > > >  {
> > > > >   u_char patterns[] = {0xa5, 0x5a, 0x00};
> > > > >   struct erase_info instr = {
> > > > > - .mtd = nand,
> > > > > + .mtd = mtd,
> > > > >   .addr = offset,
> > > > >   .len = mtd->erasesize,
> > > > >   };
> > > > 
> > > > This got missed because no boards enable CONFIG_CMD_NAND_TORTURE.
> > > >   If
> > > > you use this option could you enable it in the relevant board?
> > > 
> > > I believe this makes option makes only sense if you do HW bringup
> > > or
> > > have issues with
> > > your NAND driver. (Which I currently have with an i.MX 7 design)
> > > So likely one would not want to enable this for production code.
> > 
> > That's why I suggested the alternative of adding one or more targets
> > aimed at
> > build coverage.
> > 
> > > On the other hand people switching on the option should be able to
> > > fix
> > > whatever issue
> > > arises.
> > > 
> > > And, considering that it was broken since January 2013
> > > (dfe64e2c89731a3f9950d7acd8681b68df2bae03) it can not be that
> > > important.
> > 
> > This patch fixes a breakage that was merged within the past week. 
> >  What was
> > broken by the 2013 sync?
> 
> The 2013 sync did deprecate the outside use of the function pointers
> in the mtd_info struct. To force this it did also rename the struct
> members.
> Since the torture code did not follow the rename it did no longer
> compile.
> Now fixed with
> http://git.denx.de/?p=u-boot.git;a=commit;h=667067faa18334f1e28c01b4753
> 0b5cce1b6182f

Oh, from the description I didn't realize that the function pointers were
actually not working.  Usually "deprecated" means marked for removal/change,
not actually removed/changed.

-Scott

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

Re: [U-Boot] [PATCH v2 1/2] nand: nand torture: follow sync with linux v4.6

[Max Krummenacher]

Am Donnerstag, den 09.06.2016, 12:10 -0500 schrieb Scott Wood:
> On Thu, 2016-06-09 at 10:35 +0200, Max Krummenacher wrote:
> > Hi Scott
> > 
> > 2016-06-09 1:47 GMT+02:00 Scott Wood :
> > > On 06/07/2016 06:47 AM, Max Krummenacher wrote:
> > > > follow parameter name change (nand to mtd) to fix compiler
> > > > error.
> > > > 
> > > > Signed-off-by: Max Krummenacher 
> > > > 
> > > > ---
> > > > 
> > > > Changes in v2:
> > > > - Patch v1 1/1 went into master, but Scott's patch series
> > > > syncing
> > > >   with kernel v4.6 introduced an additional compile time error.
> > > > 
> > > >  drivers/mtd/nand/nand_util.c | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > 
> > > > diff --git a/drivers/mtd/nand/nand_util.c
> > > > b/drivers/mtd/nand/nand_util.c
> > > > index 5bba66a..e8bcc34 100644
> > > > --- a/drivers/mtd/nand/nand_util.c
> > > > +++ b/drivers/mtd/nand/nand_util.c
> > > > @@ -820,7 +820,7 @@ int nand_torture(struct mtd_info *mtd,
> > > > loff_t
> > > > offset)
> > > >  {
> > > >   u_char patterns[] = {0xa5, 0x5a, 0x00};
> > > >   struct erase_info instr = {
> > > > - .mtd = nand,
> > > > + .mtd = mtd,
> > > >   .addr = offset,
> > > >   .len = mtd->erasesize,
> > > >   };
> > > 
> > > This got missed because no boards enable CONFIG_CMD_NAND_TORTURE.
> > >   If
> > > you use this option could you enable it in the relevant board?
> > 
> > I believe this makes option makes only sense if you do HW bringup
> > or
> > have issues with
> > your NAND driver. (Which I currently have with an i.MX 7 design)
> > So likely one would not want to enable this for production code.
> 
> That's why I suggested the alternative of adding one or more targets
> aimed at
> build coverage.
> 
> > On the other hand people switching on the option should be able to
> > fix
> > whatever issue
> > arises.
> > 
> > And, considering that it was broken since January 2013
> > (dfe64e2c89731a3f9950d7acd8681b68df2bae03) it can not be that
> > important.
> 
> This patch fixes a breakage that was merged within the past week. 
>  What was
> broken by the 2013 sync?

The 2013 sync did deprecate the outside use of the function pointers
in the mtd_info struct. To force this it did also rename the struct
members.
Since the torture code did not follow the rename it did no longer
compile.
Now fixed with
http://git.denx.de/?p=u-boot.git;a=commit;h=667067faa18334f1e28c01b4753
0b5cce1b6182f

Max

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

[U-Boot] [RFC] x86: baytrail: azalia DT configuration mock-up

[George McCollister]

I'm looking for feedback on this mock-up of fsp,azalia-config DT
before I proceed to writing code. I included everything in fsp for
context.

fsp {
compatible = "intel,baytrail-fsp";
fsp,mrc-init-tseg-size = <0>;
fsp,mrc-init-mmio-size = <0x800>;
fsp,mrc-init-spd-addr1 = <0xa0>;
fsp,mrc-init-spd-addr2 = <0xa2>;
fsp,emmc-boot-mode = <2>;
fsp,enable-sdio;
fsp,enable-sdcard;
fsp,enable-hsuart1;
fsp,enable-spi;
fsp,enable-sata;
fsp,sata-mode = <1>;
fsp,enable-azalia;
fsp,azalia-config {
compatible = "intel,baytrail-fsp-azalia-config";
fsp,pme-enable = <1>;
fsp,docking-supported = <1>;
fsp,docking-attached = <0>;
fsp,hdmi-codec-enable = <1>;
fsp,azalia-v-ci-enable = <1>;
fsp,rsvdbits = <0>;
fsp,reset-wait-timer-us = <300>;
alc262 {
compatible = "fsp,azalia-verb-table";
fsp,vendor-device-id = <0x10ec0262>;
fsp,sub-system-id = <0>;
fsp,revision-id = <0xff>;
fsp,front-panel-support = <1>;
fsp,number-of-rear-jacks = <11>;
fsp,number-of-front-jacks = <2>;
fsp,verb-table-data = <
/* Pin Complex (NID 0x11) */
0x01171cf0
0x01171d11
0x01171e11
0x01171f41
/* Pin Complex (NID 0x12) */
0x01271cf0
0x01271d11
0x01271e11
0x01271f41
/* Pin Complex (NID 0x14) */
0x01471c10
0x01471d40
0x01471e01
0x01471f01
/* Pin Complex (NID 0x15) */
0x01571cf0
0x01571d11
0x01571e11
0x01571f41
/* Pin Complex (NID 0x16) */
0x01671cf0
0x01671d11
0x01671e11
0x01671f41
/* Pin Complex (NID 0x18) */
0x01871c20
0x01871d98
0x01871ea1
0x01871f01
/* Pin Complex (NID 0x19) */
0x01971c21
0x01971d98
0x01971ea1
0x01971f02
/* Pin Complex (NID 0x1A) */
0x01a71c2f
0x01a71d30
0x01a71e81
0x01a71f01
/* Pin Complex */
0x01b71c1f
0x01b71d40
0x01b71e21
0x01b71f02
/* Pin Complex */
0x01c71cf0
0x01c71d11
0x01c71e11
0x01c71f41
/* Pin Complex */
0x01d71c01
0x01d71dc6
0x01d71e14
0x01d71f40
/* Pin Complex */
0x01e71cf0
0x01e71d11
0x01e71e11
0x01e71f41
/* Pin Complex */
 

[U-Boot] socfpga 2016.05, CV socdk Rev E1, SPL and u-boot fail when booting from QSPI

[Christian Didriksson]

Hi All,

I have been struggling for quite some time now to get SPL and u-boot to run 
from QSPI-flash. Yesterday I was able to identify a workaround to get the SPL 
going by disabling quad mode for the flash (seems identified by 
http://lists.denx.de/pipermail/u-boot/2016-June/256671.html). However u-boot 
always hangs after printing memory size. I have tried to search the archive and 
have seen posts about hanging here, but nothing I can relate to my setup. I 
have tested to use Altera's SPL (2013.01.01) and u-boot-2016.5 and this combo 
seems to work.

I also notice that the frequency (max-spi-frequency) in the dts-file is not 
picked up for some reason?

Any help to fix the u-boot hang problem would be highly appreciated.

Current printout (with added debug output):

U-Boot SPL 2016.05 NGA QSPI -g133f59a-dirty (Jun 09 2016 - 17:06:20)
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 SPI
spl_spi_load_image: bus=0, cs=0, speed=5000, mode=3
cadence_spi_ofdata_to_platdata: regbase=ff705000 ahbbase=ffa0 
max-frequency=50 page-size=256
spi_flash_std_probe: slave=01100368, cs=0
SF: Read data capture delay calibrated to 7 (0 - 15)
cadence_spi_set_speed: speed=10
cadence_spi_xfer: len=1 [bytes]
cadence_spi_xfer: len=5 [bytes]
SF: Got idcodes
: 20 ba 20 10 00  . ..
SF: Detected N25Q512
cadence_spi_xfer: len=1 [bytes]
cadence_spi_xfer: len=1 [bytes]
spi_flash_decode_fdt: Cannot decode address
cadence_spi_xfer: len=0 [bytes]
cadence_spi_xfer: len=0 [bytes]
SF: Detected N25Q512 with page size 256 Bytes, erase size 64 KiB, total 64 MiB
SF: Read data capture delay calibrated to 7 (0 - 15)
cadence_spi_set_speed: speed=50
cadence_spi_xfer: len=5 [bytes]
cadence_spi_xfer: len=64 [bytes]
cadence_spi_xfer: len=5 [bytes]
cadence_spi_xfer: len=443714 [bytes]


U-Boot 2016.05 NGA QSPI -g133f59a-dirty (Jun 09 2016 - 17:06:20 +0200)

CPU:   Altera SoCFPGA Platform
FPGA:  Altera Cyclone V, SE/A6 or SX/C6 or ST/D6, version 0x0
BOOT:  QSPI Flash (1.8V)
   Watchdog enabled
I2C:   ready
DRAM:  1 GiB


Best regards,

Christian


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

Re: [U-Boot] [PATCH] lib/libfdt/: General aesthetic/style fixes.

[Simon Glass]

On 7 June 2016 at 20:43, Simon Glass  wrote:
> Hi Robert,
>
> On 23 May 2016 at 02:40, Robert P. J. Day  wrote:
>> A number of style fixes across the files in this directory, including:
>>
>>  * Correct invalid kernel-doc content.
>>  * Tidy up massive comment in fdt_region.c.
>>  * Use correct spelling of "U-Boot".
>>  * Replace tests of "! " with "!".
>>  * Replace "libfdt_env.h" with .
>>
>> Signed-off-by: Robert P. J. Day 
>>
>> ---
>
> Did you create this patch with patman? It seems to be missing the diffstat.
>
> Acked-by: Simon Glass 

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

Re: [U-Boot] [PATCH] sandbox: gpio: doc: Fix parameter documentation

[Simon Glass]

On 25 May 2016 at 17:17, Simon Glass  wrote:
> On 25 May 2016 at 07:18, Mario Six  wrote:
>> The documentation of parameters in arch/sandbox/include/asm/gpio.h is
>> either missing or faulty.
>>
>> This patch corrects the documentation.
>>
>> Signed-off-by: Mario Six 
>> ---
>>  arch/sandbox/include/asm/gpio.h | 16 ++--
>>  1 file changed, 10 insertions(+), 6 deletions(-)
>
> Acked-by: Simon Glass 

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

Re: [U-Boot] [PATCH] gpio: pca953x: Fix register reading past 8th GPIO

[Simon Glass]

On 7 June 2016 at 20:43, Simon Glass  wrote:
> On 23 May 2016 at 02:15, Peng Fan  wrote:
>> Hi Mario,
>>
>> On Mon, May 23, 2016 at 09:54:56AM +0200, Mario Six wrote:
>>>A bug in the pca953x driver prevents correct reading of GPIO input
>>>values beyond the 8th GPIO; all values are reported as zero. Setting of
>>>GPIO output values is not affected.
>>>
>>>This patch fixes the reading behavior.
>>>
>>>Signed-off-by: Mario Six 
>>
>> Reviewed-by: Peng Fan 
>
> Acked-by: Simon Glass 

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

Re: [U-Boot] [PATCH] dm: add manual relocation for devices

[Simon Glass]

On 7 June 2016 at 20:42, Simon Glass  wrote:
> On 21 May 2016 at 03:05, Angelo Dureghello  wrote:
>> Some architectures as m68k still need to use CONFIG_NEEDS_MANUAL_RELOC,
>> and are not still using the device tree.
>>
>> Signed-off-by: Angelo Dureghello 
>> ---
>>  drivers/core/root.c | 15 +++
>>  1 file changed, 15 insertions(+)
>
> Acked-by: Simon Glass 

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

Re: [U-Boot] [PATCH v2 3/3] mx6sxsabresd: Avoid hardcoded RAM size

[Fabio Estevam]

On Thu, Jun 9, 2016 at 3:28 PM, Vanessa Maegima  wrote:
> Instead of passing the total RAM size via PHYS_SDRAM_SIZE option,
> we should better use imx_ddr_size() function, which automatically
> determines the RAM size.
>
> Signed-off-by: Vanessa Maegima 

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