Re: [U-Boot] [PATCH 1/1] kconfig/symbol.c: use correct pointer type argument for sizeof

2017-11-08 Thread Heinrich Schuchardt

On 11/09/2017 03:01 AM, Tom Rini wrote:

On Wed, Nov 08, 2017 at 10:13:54PM +0100, Heinrich Schuchardt wrote:

sym_arr is of type struct symbol **.
So in malloc we need sizeof(struct symbol *).

The problem was indicated by coccinelle.

Signed-off-by: Heinrich Schuchardt 
---
  scripts/kconfig/symbol.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/kconfig/symbol.c b/scripts/kconfig/symbol.c
index 20136ffefb..3c8bd9bb42 100644
--- a/scripts/kconfig/symbol.c
+++ b/scripts/kconfig/symbol.c
@@ -1061,7 +1061,7 @@ struct symbol **sym_re_search(const char *pattern)
}
if (sym_match_arr) {
qsort(sym_match_arr, cnt, sizeof(struct sym_match), 
sym_rel_comp);
-   sym_arr = malloc((cnt+1) * sizeof(struct symbol));
+   sym_arr = malloc((cnt+1) * sizeof(struct symbol *));
if (!sym_arr)
goto sym_re_search_free;
for (i = 0; i < cnt; i++)


Since this comes right from the kernel, shouldn't it be fixed there too?
Or is it already?  Thanks!


I already sent a mail upstream:
https://lkml.org/lkml/2017/11/8/898

Coccinelle indicated a few other problems (using the Linux coccicheck 
script):

https://patchwork.ozlabs.org/patch/836007/
https://patchwork.ozlabs.org/patch/836008/
https://patchwork.ozlabs.org/patch/836028/
https://patchwork.ozlabs.org/patch/836091/

Scripts like
scripts/coccinelle/iterators/itnull.cocci
are useful to search for API specific issues which generalized static 
analyzers like cppcheck miss.


To apply coccinelle I just copied scripts/coccicheck and 
scripts/coccinelle/* from Linux to U-Boot and ran


sudo apt-get install coccinelle
srctree=. scripts/coccicheck

Regards

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


Re: [U-Boot] [PATCH 1/2] common: Generic file system firmware loader

2017-11-08 Thread Chee, Tien Fong
On Kha, 2017-11-09 at 08:05 +0100, Marek Vasut wrote:
> On 11/09/2017 07:04 AM, Chee, Tien Fong wrote:
> > 
> > On Sel, 2017-11-07 at 10:34 +0100, Marek Vasut wrote:
> > > 
> > > On 11/07/2017 10:03 AM, Chee, Tien Fong wrote:
> > > > 
> > > > 
> > > > On Isn, 2017-11-06 at 11:56 +0100, Marek Vasut wrote:
> > > > > 
> > > > > 
> > > > > On 11/06/2017 05:15 AM, Chee, Tien Fong wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > On Ahd, 2017-11-05 at 17:43 +0100, Marek Vasut wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > On 11/02/2017 09:20 AM, Chee, Tien Fong wrote:
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > On Rab, 2017-11-01 at 10:26 +0100, Marek Vasut wrote:
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > On 11/01/2017 10:18 AM, tien.fong.c...@intel.com
> > > > > > > > > wrote:
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > From: Tien Fong Chee 
> > > > > > > > > > 
> > > > > > > > > > Generic firmware loader framework contains some
> > > > > > > > > > common
> > > > > > > > > > functionality
> > > > > > > > > > which is factored out from splash loader. It is
> > > > > > > > > > reusable by
> > > > > > > > > > any
> > > > > > > > > > specific driver file system firmware loader.
> > > > > > > > > > Specific
> > > > > > > > > > driver
> > > > > > > > > > file
> > > > > > > > > > system
> > > > > > > > > > firmware loader handling can be defined with both
> > > > > > > > > > weak
> > > > > > > > > > function
> > > > > > > > > > fsloader_preprocess and fs_loading.
> > > > > > > > > > 
> > > > > > > > > > Signed-off-by: Tien Fong Chee  > > > > > > > > > .com
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > ---
> > > > > > > > > >  common/Makefile   |   1 +
> > > > > > > > > >  common/load_fs.c  | 217
> > > > > > > > > > +++
> > > > > > > > > > +++
> > > > > > > > > >  include/load_fs.h |  38 ++
> > > > > > > > > >  3 files changed, 256 insertions(+)
> > > > > > > > > >  create mode 100644 common/load_fs.c
> > > > > > > > > >  create mode 100644 include/load_fs.h
> > > > > > > > > [...]
> > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > +int flash_select_fs_dev(struct flash_location
> > > > > > > > > > *location)
> > > > > > > > > Why does everything have flash_ prefix ?
> > > > > > > > > 
> > > > > > > > I can remove the flash_ prefix, this generic FS loader
> > > > > > > > should
> > > > > > > > support
> > > > > > > > for all filesystem instead of flash.
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > I also mentioned the API should copy the linux
> > > > > > > > > firmware
> > > > > > > > > loader
> > > > > > > > > API.
> > > > > > > > > 
> > > > > > > > If i'm not mistaken, you are referring firmware loader
> > > > > > > > API
> > > > > > > > in
> > > > > > > > this
> > > > > > > > link https://github.com/torvalds/linux/blob/f007cad159e
> > > > > > > > 99fa
> > > > > > > > 2acd
> > > > > > > > 3b2e
> > > > > > > > 9364
> > > > > > > > fbb32ad28b971/drivers/base/firmware_class.c#L1264.
> > > > > > > > 
> > > > > > I would like to confirm with you whether we are talking to
> > > > > > the
> > > > > > same
> > > > > > API
> > > > > > above?
> > > > > https://www.kernel.org/doc/html/v4.13/driver-api/firmware/ind
> > > > > ex.h
> > > > > tml
> > > > > 
> > > > > first link on google btw . You might be able to avoid the
> > > > > firmware
> > > > > structure.
> > > > > 
> > > > After assessment, i found that Linux loader is not suitable for
> > > > fpga
> > > > loader as fpga loader need
> > > > 1) Able to program FPGA image in SPL chunk bu chunk with small
> > > > memory
> > > > allocatted.
> > > > 2) Name of FPGA image defined in DTS, and path of FPGA image in
> > > > FAT
> > > > and
> > > > UBI partition.
> > > > 
> > > > Linux loader is strongly designed based on Linux environment,
> > > > always
> > > > assume having RFF, env support(which SPL don't have), sysfs and
> > > > udev
> > > > feature.
> > > Sigh, you can just have some additional function call to fetch
> > > smaller
> > > chunks from a file, I don't think it's that hard of a problem ...
> > > 
> > We already have that function to support smaller chunks, and it
> > also
> > work for single large image when enough memory is available in ver
> > 1
> > series of fpga loadfs.
> > 
> > Since the Linux loader API is totally not suitable for fpga loadfs,
> > and
> > also nothing i can leverage from there for fpga loadfs, could you
> > please consider to accept implementation for this series patches or
> > implementation for fpga loadfs series ver1?
> You mean going back to completely custom 

Re: [U-Boot] [PATCH 1/2] common: Generic file system firmware loader

2017-11-08 Thread Marek Vasut
On 11/09/2017 07:04 AM, Chee, Tien Fong wrote:
> On Sel, 2017-11-07 at 10:34 +0100, Marek Vasut wrote:
>> On 11/07/2017 10:03 AM, Chee, Tien Fong wrote:
>>>
>>> On Isn, 2017-11-06 at 11:56 +0100, Marek Vasut wrote:

 On 11/06/2017 05:15 AM, Chee, Tien Fong wrote:
>
>
> On Ahd, 2017-11-05 at 17:43 +0100, Marek Vasut wrote:
>>
>>
>> On 11/02/2017 09:20 AM, Chee, Tien Fong wrote:
>>>
>>>
>>>
>>> On Rab, 2017-11-01 at 10:26 +0100, Marek Vasut wrote:



 On 11/01/2017 10:18 AM, tien.fong.c...@intel.com wrote:
>
>
>
>
> From: Tien Fong Chee 
>
> Generic firmware loader framework contains some common
> functionality
> which is factored out from splash loader. It is
> reusable by
> any
> specific driver file system firmware loader. Specific
> driver
> file
> system
> firmware loader handling can be defined with both weak
> function
> fsloader_preprocess and fs_loading.
>
> Signed-off-by: Tien Fong Chee >
> ---
>  common/Makefile   |   1 +
>  common/load_fs.c  | 217
> ++
>  include/load_fs.h |  38 ++
>  3 files changed, 256 insertions(+)
>  create mode 100644 common/load_fs.c
>  create mode 100644 include/load_fs.h
 [...]

>
>
>
>
> +int flash_select_fs_dev(struct flash_location
> *location)
 Why does everything have flash_ prefix ?

>>> I can remove the flash_ prefix, this generic FS loader
>>> should
>>> support
>>> for all filesystem instead of flash.
>>>



 I also mentioned the API should copy the linux firmware
 loader
 API.

>>> If i'm not mistaken, you are referring firmware loader API
>>> in
>>> this
>>> link https://github.com/torvalds/linux/blob/f007cad159e99fa
>>> 2acd
>>> 3b2e
>>> 9364
>>> fbb32ad28b971/drivers/base/firmware_class.c#L1264.
>>>
> I would like to confirm with you whether we are talking to the
> same
> API
> above?
 https://www.kernel.org/doc/html/v4.13/driver-api/firmware/index.h
 tml

 first link on google btw . You might be able to avoid the
 firmware
 structure.

>>> After assessment, i found that Linux loader is not suitable for
>>> fpga
>>> loader as fpga loader need
>>> 1) Able to program FPGA image in SPL chunk bu chunk with small
>>> memory
>>> allocatted.
>>> 2) Name of FPGA image defined in DTS, and path of FPGA image in FAT
>>> and
>>> UBI partition.
>>>
>>> Linux loader is strongly designed based on Linux environment,
>>> always
>>> assume having RFF, env support(which SPL don't have), sysfs and
>>> udev
>>> feature.
>> Sigh, you can just have some additional function call to fetch
>> smaller
>> chunks from a file, I don't think it's that hard of a problem ...
>>
> We already have that function to support smaller chunks, and it also
> work for single large image when enough memory is available in ver 1
> series of fpga loadfs.
> 
> Since the Linux loader API is totally not suitable for fpga loadfs, and
> also nothing i can leverage from there for fpga loadfs, could you
> please consider to accept implementation for this series patches or
> implementation for fpga loadfs series ver1?

You mean going back to completely custom non-generic altera-only ad-hoc
interface ? I'd like to hear opinion of the others on CC ...

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


Re: [U-Boot] [PATCH 3/3] Powerpc: pcie: Make pcie link state judgement more specific

2017-11-08 Thread Xiaowei Bao


> -Original Message-
> From: York Sun
> Sent: Thursday, November 09, 2017 5:46 AM
> To: Joakim Tjernlund ; Xiaowei Bao
> 
> Cc: w...@denx.de; Mingkai Hu ;
> tony.obr...@alliedtelesis.co.nz; u-boot@lists.denx.de; Z.q. Hou
> ; hamish.mar...@alliedtelesis.co.nz; M.h. Lian
> 
> Subject: Re: [U-Boot] [PATCH 3/3] Powerpc: pcie: Make pcie link state
> judgement more specific
> 
> On 11/08/2017 01:30 PM, Joakim Tjernlund wrote:
> > On Wed, 2017-11-08 at 21:05 +, York Sun wrote:
> >> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and know the
> content is safe.
> >>
> >>
> >> On 10/22/2017 07:39 PM, Xiaowei Bao wrote:
> >>>
> >>> -Original Message-
> >>> From: Joakim Tjernlund [mailto:joakim.tjernl...@infinera.com]
> >>> Sent: Friday, October 20, 2017 9:13 PM
> >>> To: w...@denx.de; Mingkai Hu ;
> >>> tony.obr...@alliedtelesis.co.nz; u-boot@lists.denx.de; Z.q. Hou
> >>> ; York Sun ; Xiaowei Bao
> >>> ; hamish.mar...@alliedtelesis.co.nz; M.h. Lian
> >>> 
> >>> Subject: Re: [U-Boot] [PATCH 3/3] Powerpc: pcie: Make pcie link
> >>> state judgement more specific
> >>>
> >>> On Fri, 2017-10-20 at 18:16 +0800, Bao Xiaowei wrote:
>  CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and know the
> content is safe.
> 
> 
>  For some special reset times for longer pcie devices, the pcie
>  device may on polling compliance state, the RC considers the pcie
>  device is link up, but the pcie device is not link up, only the L0
>  state is link up state.
> 
>  Signed-off-by: Bao Xiaowei 
>  ---
>   arch/powerpc/include/asm/fsl_pci.h |  2 ++
>   drivers/pci/fsl_pci_init.c | 10 ++
>   2 files changed, 8 insertions(+), 4 deletions(-)
> 
>  diff --git a/arch/powerpc/include/asm/fsl_pci.h
>  b/arch/powerpc/include/asm/fsl_pci.h
>  index 70a5461..323b182 100644
>  --- a/arch/powerpc/include/asm/fsl_pci.h
>  +++ b/arch/powerpc/include/asm/fsl_pci.h
>  @@ -25,6 +25,8 @@
>   #define PCI_LTSSM  0x404   /* PCIe Link Training, Status State 
>  Machine
> */
>   #define PCI_LTSSM_L0   0x16/* L0 state */
>   #define PCI_LTSSM_L0_PEX_REV3  0x11/* L0 state for pex rev3*/
>  +#define LTSSM_PCIE_DETECT_QUIET0x00/* Detect state 
>  */
>  +#define LTSSM_PCIE_DETECT_ACTIVE   0x01/* Detect state */
> 
>   int fsl_setup_hose(struct pci_controller *hose, unsigned long
>  addr); int fsl_is_pci_agent(struct pci_controller *hose); diff
>  --git a/drivers/pci/fsl_pci_init.c b/drivers/pci/fsl_pci_init.c
>  index
>  be57e53..9b5f386 100644
>  --- a/drivers/pci/fsl_pci_init.c
>  +++ b/drivers/pci/fsl_pci_init.c
>  @@ -335,15 +335,17 @@ static int fsl_pci_link_up(struct pci_controller
> *hose,
>  pci_ltssm_l0 = PCI_LTSSM_L0;
> 
>  ltssm = fsl_get_ltssm(hose, pci_info);
>  -
>  -   if (ltssm == pci_ltssm_l0) {
>  +   if (ltssm == LTSSM_PCIE_DETECT_QUIET ||
>  +   ltssm == LTSSM_PCIE_DETECT_ACTIVE) {
>  +   enabled = 0;
>  +   } else if (ltssm == pci_ltssm_l0) {
>  enabled = 1;
>  } else {
>  -   for (i = 0; i < 100 && ltssm < pci_ltssm_l0; i++) {
>  +   for (i = 0; i < 100 && ltssm != pci_ltssm_l0; i++)
>  + {
>  ltssm = fsl_get_ltssm(hose, pci_info);
>  udelay(1000);
> >>>
> >>> Do you really need this long loop here ? It causes a long delay in
> >>> case the PCIe device is in permanent polling state. Our device is in
> >>> polling state until clocks is configured and that will be done from
> >>> user space in Linux
> >>>
> >>> Yes, if the pcie device is in permanent polling state, it will take 
> >>> probably
> 100ms delay, but this case is occur very few special devices, if we want to 
> use
> the pcie device in uboot, we have to wait the device link up state is ok, so 
> need
> some time to wait the pcie device ready. if the pcie slot have no device, the
> function will return at once, will not bring delay.
> >>
> >> Joakim,
> >>
> >> Are we OK with this change? Can you test it to make sure no negative
> >> impact on your boards?
> >
> > Not really happy, what device needs 100 ms extra to exit polling state?
> >
> 
> Joakim,
>  
> I understand your concern. I don't like the delay either.
> 
> Xiaowei,
> 
> You said this only occur for very few special devices. Can you explain more?
> How can you avoid this delay 

Re: [U-Boot] [PATCH 1/2] common: Generic file system firmware loader

2017-11-08 Thread Chee, Tien Fong
On Sel, 2017-11-07 at 10:34 +0100, Marek Vasut wrote:
> On 11/07/2017 10:03 AM, Chee, Tien Fong wrote:
> > 
> > On Isn, 2017-11-06 at 11:56 +0100, Marek Vasut wrote:
> > > 
> > > On 11/06/2017 05:15 AM, Chee, Tien Fong wrote:
> > > > 
> > > > 
> > > > On Ahd, 2017-11-05 at 17:43 +0100, Marek Vasut wrote:
> > > > > 
> > > > > 
> > > > > On 11/02/2017 09:20 AM, Chee, Tien Fong wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > On Rab, 2017-11-01 at 10:26 +0100, Marek Vasut wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > On 11/01/2017 10:18 AM, tien.fong.c...@intel.com wrote:
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > From: Tien Fong Chee 
> > > > > > > > 
> > > > > > > > Generic firmware loader framework contains some common
> > > > > > > > functionality
> > > > > > > > which is factored out from splash loader. It is
> > > > > > > > reusable by
> > > > > > > > any
> > > > > > > > specific driver file system firmware loader. Specific
> > > > > > > > driver
> > > > > > > > file
> > > > > > > > system
> > > > > > > > firmware loader handling can be defined with both weak
> > > > > > > > function
> > > > > > > > fsloader_preprocess and fs_loading.
> > > > > > > > 
> > > > > > > > Signed-off-by: Tien Fong Chee  > > > > > > > >
> > > > > > > > ---
> > > > > > > >  common/Makefile   |   1 +
> > > > > > > >  common/load_fs.c  | 217
> > > > > > > > ++
> > > > > > > >  include/load_fs.h |  38 ++
> > > > > > > >  3 files changed, 256 insertions(+)
> > > > > > > >  create mode 100644 common/load_fs.c
> > > > > > > >  create mode 100644 include/load_fs.h
> > > > > > > [...]
> > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > +int flash_select_fs_dev(struct flash_location
> > > > > > > > *location)
> > > > > > > Why does everything have flash_ prefix ?
> > > > > > > 
> > > > > > I can remove the flash_ prefix, this generic FS loader
> > > > > > should
> > > > > > support
> > > > > > for all filesystem instead of flash.
> > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > I also mentioned the API should copy the linux firmware
> > > > > > > loader
> > > > > > > API.
> > > > > > > 
> > > > > > If i'm not mistaken, you are referring firmware loader API
> > > > > > in
> > > > > > this
> > > > > > link https://github.com/torvalds/linux/blob/f007cad159e99fa
> > > > > > 2acd
> > > > > > 3b2e
> > > > > > 9364
> > > > > > fbb32ad28b971/drivers/base/firmware_class.c#L1264.
> > > > > > 
> > > > I would like to confirm with you whether we are talking to the
> > > > same
> > > > API
> > > > above?
> > > https://www.kernel.org/doc/html/v4.13/driver-api/firmware/index.h
> > > tml
> > > 
> > > first link on google btw . You might be able to avoid the
> > > firmware
> > > structure.
> > > 
> > After assessment, i found that Linux loader is not suitable for
> > fpga
> > loader as fpga loader need
> > 1) Able to program FPGA image in SPL chunk bu chunk with small
> > memory
> > allocatted.
> > 2) Name of FPGA image defined in DTS, and path of FPGA image in FAT
> > and
> > UBI partition.
> > 
> > Linux loader is strongly designed based on Linux environment,
> > always
> > assume having RFF, env support(which SPL don't have), sysfs and
> > udev
> > feature.
> Sigh, you can just have some additional function call to fetch
> smaller
> chunks from a file, I don't think it's that hard of a problem ...
> 
We already have that function to support smaller chunks, and it also
work for single large image when enough memory is available in ver 1
series of fpga loadfs.

Since the Linux loader API is totally not suitable for fpga loadfs, and
also nothing i can leverage from there for fpga loadfs, could you
please consider to accept implementation for this series patches or
implementation for fpga loadfs series ver1?

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


[U-Boot] [PATCH] armv8: ls1088: Add fsl_fdt_fixup_flash

2017-11-08 Thread Ashish Kumar
IFC-NOR and QSPI-NOR signals are muxed on SoC to save pins

Add fsl_fdt_fixup_flash() to disable IFC-NOR node in dts
if QSPI is enabled and vice-versa

Signed-off-by: Ashish Kumar 
---
 board/freescale/ls1088a/ls1088a.c | 29 +
 1 file changed, 29 insertions(+)

diff --git a/board/freescale/ls1088a/ls1088a.c 
b/board/freescale/ls1088a/ls1088a.c
index 96d9ae7..b8d015f 100644
--- a/board/freescale/ls1088a/ls1088a.c
+++ b/board/freescale/ls1088a/ls1088a.c
@@ -368,6 +368,33 @@ void fdt_fixup_board_enet(void *fdt)
 #endif
 
 #ifdef CONFIG_OF_BOARD_SETUP
+void fsl_fdt_fixup_flash(void *fdt)
+{
+   int offset;
+
+/*
+ * IFC-NOR and QSPI are muxed on SoC.
+ * So disable IFC node in dts if QSPI is enabled or
+ * disable QSPI node in dts in case QSPI is not enabled.
+ */
+
+#ifdef CONFIG_FSL_QSPI
+   offset = fdt_path_offset(fdt, "/soc/ifc/nor");
+
+   if (offset < 0)
+   offset = fdt_path_offset(fdt, "/ifc/nor");
+#else
+   offset = fdt_path_offset(fdt, "/soc/quadspi");
+
+   if (offset < 0)
+   offset = fdt_path_offset(fdt, "/quadspi");
+#endif
+   if (offset < 0)
+   return;
+
+   fdt_status_disabled(fdt, offset);
+}
+
 int ft_board_setup(void *blob, bd_t *bd)
 {
int err, i;
@@ -394,6 +421,8 @@ int ft_board_setup(void *blob, bd_t *bd)
 
fdt_fixup_memory_banks(blob, base, size, CONFIG_NR_DRAM_BANKS);
 
+   fsl_fdt_fixup_flash(blob);
+
 #ifdef CONFIG_FSL_MC_ENET
fdt_fixup_board_enet(blob);
err = fsl_mc_ldpaa_exit(bd);
-- 
2.7.4

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


Re: [U-Boot] [PATCH] driver: net: ldpaa_eth: Add PHY-less SGMII support

2017-11-08 Thread Ashish Kumar
-Original Message-
From: York Sun 
Sent: Thursday, November 09, 2017 2:07 AM
To: Ashish Kumar ; u-boot@lists.denx.de
Cc: joe.hershber...@ni.com; Prabhakar Kushwaha 
Subject: Re: [PATCH] driver: net: ldpaa_eth: Add PHY-less SGMII support

On 11/06/2017 01:09 AM, Ashish Kumar wrote:
> In case of PHY-less mode, there is no interaction with PHY so auto-neg 
> etc is not required and link will have fixed attributes
> 
> Signed-off-by: Ashish Kumar 
> Signed-off-by: Prabhakar Kushwaha 
> ---
>  drivers/net/ldpaa_eth/ldpaa_eth.c | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/ldpaa_eth/ldpaa_eth.c 
> b/drivers/net/ldpaa_eth/ldpaa_eth.c
> index 21be79a..85e7faa 100644
> --- a/drivers/net/ldpaa_eth/ldpaa_eth.c
> +++ b/drivers/net/ldpaa_eth/ldpaa_eth.c
> @@ -440,12 +440,17 @@ static int ldpaa_eth_open(struct eth_device *net_dev, 
> bd_t *bd)
>   bus = wriop_get_mdio(priv->dpmac_id);
>   enet_if = wriop_get_enet_if(priv->dpmac_id);
>   if ((bus == NULL) &&
> - (enet_if == PHY_INTERFACE_MODE_XGMII)) {
> +((enet_if == PHY_INTERFACE_MODE_XGMII) ||
> +(enet_if == PHY_INTERFACE_MODE_SGMII))) {
>   priv->phydev = (struct phy_device *)
>   malloc(sizeof(struct phy_device));
>   memset(priv->phydev, 0, sizeof(struct phy_device));
>  
> - priv->phydev->speed = SPEED_1;
> + if (enet_if == PHY_INTERFACE_MODE_XGMII)
> + priv->phydev->speed = SPEED_1;
> + else
> + priv->phydev->speed = SPEED_1000;
> +
>   priv->phydev->link = 1;
>   priv->phydev->duplex = DUPLEX_FULL;
>   }
> 

How was this patch tested?

>It can be tested with PHY-less SGMII riser cards after adding patches 
>attached. 
>With the existing Riser card, which are PHY enabled, the test is that PHYs are 
>not configured by adding these to patches.

>Do you suggest to add these patches in upstream?

Regards
Ashish

A little off-topic. I remember a similar discussion somewhere (maybe
internal) for PowerPC-based boards regarding fixed SGMII port. When the port 
doesn't have a PHY, it fails due to PHY id check. I don't find the change in 
U-Boot code. Does anyone remember it?

York


0001-armv8-ls1088-introduce-CONFIG_SGMII_PHYLIB.patch
Description: 0001-armv8-ls1088-introduce-CONFIG_SGMII_PHYLIB.patch


0002-ls1088aqds-Add-CONFIG_SGMII_PHYLIB-in-header-file-fo.patch
Description: 0002-ls1088aqds-Add-CONFIG_SGMII_PHYLIB-in-header-file-fo.patch
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v6 1/2] armv8: ls1088ardb: Add SD boot support for ls1088

2017-11-08 Thread Ashish Kumar


-Original Message-
From: York Sun 
Sent: Thursday, November 09, 2017 12:30 AM
To: Ashish Kumar ; u-boot@lists.denx.de
Cc: Prabhakar Kushwaha ; Raghav Dogra 

Subject: Re: [PATCH v6 1/2] armv8: ls1088ardb: Add SD boot support for ls1088

On 11/05/2017 11:48 PM, Ashish Kumar wrote:
> Signed-off-by: Prabhakar Kushwaha 
> Signed-off-by: Ashish Kumar 
> Signed-off-by: Raghav Dogra 
> ---
> v6:
> Incorporation of review comments in README wrt to line wrap.
> Sorting defconfig with help make savedefconfig
> 
>  arch/arm/Kconfig   |  1 +
>  arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch3 | 44 
> ++
>  board/freescale/ls1088a/MAINTAINERS|  1 +
>  board/freescale/ls1088a/ddr.c  |  5 ++-
>  configs/ls1088ardb_sdcard_qspi_defconfig   | 41 
>  include/configs/ls1088a_common.h   | 25 
>  include/configs/ls1088ardb.h   | 30 ++-
>  7 files changed, 144 insertions(+), 3 deletions(-)  create mode 
> 100644 configs/ls1088ardb_sdcard_qspi_defconfig
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 
> 83b7aa5..5707111 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -938,6 +938,7 @@ config TARGET_LS1088ARDB
>   select ARMV8_MULTIENTRY
>   select ARCH_MISC_INIT
>   select BOARD_LATE_INIT
> + select SUPPORT_SPL
>   help
> Support for NXP LS1088ARDB platform.
> The LS1088A Reference design board (RDB) is a high-performance 
> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch3 
> b/arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch3
> index 7867c37..522760b 100644
> --- a/arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch3
> +++ b/arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch3
> @@ -201,6 +201,50 @@ nand write  8  of u-boot image>  Notice the difference from QDS is SRC, SRC_ADDR and 
> the offset of u-boot image  to match board NAND device with 4KB/page, block 
> size 512KB.
>  
> +Booting from SD/eMMC
> +---
> +Booting from SD/eMMC requires two images, RCW and u-boot-with-spl.bin.
> +The difference between SD boot RCW image and QSPI-NOR boot image is 
> +the PBI command sequence. Below is one example for PBI commands for 
> +RDB and QDS which uses SD device with block size 512. Block location 
> +can be calculated by dividing offset with block size.
> +
> +1) Block Copy: SRC=0x0040, SRC_ADDR=0x0010, DEST_ADDR=0x1800a000,
> +BLOCK_SIZE=0x00016000
> +
> +This command copies u-boot image from SD device into OCRAM. The 
> +values need to adjust accordingly for SD/eMMC
> +
> +SRC  should match the cfg_rcw_src, the reset config pins.
> + The value for source(SRC) can be 0x0040 or 0x0041
> + depending upon SD or eMMC.
> +SRC_ADDR is the offset of u-boot-with-spl.bin image in SD device.
> + In the example above, 1MB. This is same as QSPI-NOR.
> +DEST_ADDRis configured at 0x1800a000, matching bootloc set above.
> +BLOCK_SIZE   is the size to be copied by PBI.
> +
> +2) CCSR 4-byte write to 0x01e00404, data=0x
> +3) CCSR 4-byte write to 0x01e00400, data=0x1800a000 The above two 
> +commands set bootloc register to 0x_1800a000 where the u-boot 
> +code will be running in OCRAM.
> +
> +
> +RCW image should be written at 8th block of device(SD/eMMC). Example 
> +of using u-boot command
> +
> +mmc erase 0x8 0x10
> +mmc write  0x8  +typical value=10>

It is not wrong to erase the sectors first. I think we don't need to erase the 
SD first. The write command should just work.
> It should work. To make is consistent with other boot types I have used this 
> command were write preceded by erase.

 On the other hand, the number of blocks to be erased seems too large The RCW 
is normally very small (less than 1 block). Would it be more appropriate to use 
a smaller number as the "typical" value, such as 1?
> 992256 bits are reserved for RCW as per the memory map. I just used safe 
> value, although 1 = 512bits which is the size of RCW

> +
> +To form the SD-Boot image, build u-boot with SD config, for example, 
> +ls1088ardb_sdcard_qspi_defconfig. The image needed is u-boot-with-spl.bin.
> +The u-boot image should be written to match SRC_ADDR, in above 
> +example offset 0x10 in other work it means block location 0x800

s/work/word

If you agree, I will fix them at the time of merging.
> I agree.

Regards
Ashish

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


Re: [U-Boot] [PATCH] gpt: add part-uuid and part-num subcommands

2017-11-08 Thread Andrey Yurovsky
On Wed, Nov 8, 2017 at 2:47 AM Otavio Salvador <
otavio.salva...@ossystems.com.br> wrote:

> On Tue, Nov 7, 2017 at 10:43 PM, your name  wrote:
> > From: Andrey Yurovsky 
> >
> > It is useful to be able to retrieve a partition UUID or number given
> > the partition label, for instance some systems use the partition label
> > to indicate the purpose of the partition (such as "rootfs0" being the
> > 0th root file system in an A/B image scheme).
> >
> > Add "gpt part-uuid" to retrieve the partition UUID for a given label and
> > "gpt part-num" to retrieve the partition number for a given label along
> > with some documentation.
> >
> > Signed-off-by: Andrey Yurovsky 
>
> Why not use the 'part' cmd? it provides it.
>

The use case is, given a label, find the UUID and/or the partition number.
I see that 'part' can give me the UUID if I knew the partition number, it
can print the whole table (but I don't think I can use that output
cleanly), and it can list the partition numbers. I don't think I can solve
my problem with 'part' as-is unless I have missed something.

If that's the case would it be alright to add these subcommands to 'part'?
Thank you again,

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


Re: [U-Boot] [PATCH] gpt: add part-uuid and part-num subcommands

2017-11-08 Thread Andrey Yurovsky
Hi Otavio,

On Wed, Nov 8, 2017 at 2:47 AM, Otavio Salvador
 wrote:
> On Tue, Nov 7, 2017 at 10:43 PM, your name  wrote:
>> From: Andrey Yurovsky 
>>
>> It is useful to be able to retrieve a partition UUID or number given
>> the partition label, for instance some systems use the partition label
>> to indicate the purpose of the partition (such as "rootfs0" being the
>> 0th root file system in an A/B image scheme).
>>
>> Add "gpt part-uuid" to retrieve the partition UUID for a given label and
>> "gpt part-num" to retrieve the partition number for a given label along
>> with some documentation.
>>
>> Signed-off-by: Andrey Yurovsky 
>
> Why not use the 'part' cmd? it provides it.

Sorry, I missed the part cmd, it doesn't seem to be documented in doc/
and it's unclear what  means there. I'll investigate and see if I
can use it for what I'm trying to do, it looks like it should work.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH] armv8: fsl-layerscape: Add support of disabling core prefetch

2017-11-08 Thread Prabhakar Kushwaha
Instruction prefetch feature is by default enabled during core
release.

This patch add support of disabling instruction prefetch by setting
core mask in PPA. Here each core mask bit represents a core and
prefetch is disabled at the time of core release.

Signed-off-by: Prabhakar Kushwaha 
---
 arch/arm/cpu/armv8/fsl-layerscape/cpu.c| 38 ++
 .../armv8/fsl-layerscape/doc/README.core_prefetch  | 18 ++
 2 files changed, 56 insertions(+)
 create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/doc/README.core_prefetch

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c 
b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
index ab5d76e..d082629 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
@@ -29,6 +29,7 @@
 #include 
 #endif
 #include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -494,6 +495,41 @@ static inline int check_psci(void)
return 0;
 }
 
+static void config_core_prefetch(void)
+{
+   char *buf = NULL;
+   char buffer[HWCONFIG_BUFFER_SIZE];
+   const char *prefetch_arg = NULL;
+   size_t arglen;
+   unsigned int mask;
+   struct pt_regs regs;
+
+   if (env_get_f("hwconfig", buffer, sizeof(buffer)) > 0)
+   buf = buffer;
+
+   prefetch_arg = hwconfig_subarg_f("core_prefetch", "disable",
+, buf);
+
+   if (prefetch_arg) {
+   mask = simple_strtoul(prefetch_arg, NULL, 0) & 0xff;
+   if (mask & 0x1) {
+   printf("Core0 prefetch can't be disabled\n");
+   return;
+   }
+
+#define SIP_PREFETCH_DISABLE_64 0xC200FF13
+   regs.regs[0] = SIP_PREFETCH_DISABLE_64;
+   regs.regs[1] = mask;
+   smc_call();
+
+   if (regs.regs[0])
+   printf("Prefetch disable config failed for mask ");
+   else
+   printf("Prefetch disable config passed for mask ");
+   printf("0x%x\n", mask);
+   }
+}
+
 int arch_early_init_r(void)
 {
 #ifdef CONFIG_SYS_FSL_ERRATUM_A009635
@@ -521,6 +557,8 @@ int arch_early_init_r(void)
fsl_rgmii_init();
 #endif
 
+   config_core_prefetch();
+
 #ifdef CONFIG_SYS_HAS_SERDES
fsl_serdes_init();
 #endif
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/doc/README.core_prefetch 
b/arch/arm/cpu/armv8/fsl-layerscape/doc/README.core_prefetch
new file mode 100644
index 000..f605a4c
--- /dev/null
+++ b/arch/arm/cpu/armv8/fsl-layerscape/doc/README.core_prefetch
@@ -0,0 +1,18 @@
+Core instruction prefetch disable
+-
+To disable instruction prefetch of core; hwconfig needs to be updated.
+for e.g.
+setenv hwconfig 'fsl_ddr:bank_intlv=auto;core_prefetch:disable=0x02'
+
+Here 0x02 can be replaced with any valid value. It represents 64 bit mask.
+The 64-bit Mask has one bit for each core.
+Mask[0] = core0
+Mask[1] = core1
+Mask[2] = core2
+etc
+If the bit is set ('b1) in the mask, then prefetch is disabled for
+that core when it is released from reset.
+core0 prefetch should not be disabled.
+
+Once disabled, prefetch remains disabled until the next reset.
+There is no function to re-enable prefetch.
-- 
2.7.4

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


Re: [U-Boot] [PATCH 1/1] kconfig/symbol.c: use correct pointer type argument for sizeof

2017-11-08 Thread Tom Rini
On Wed, Nov 08, 2017 at 10:13:54PM +0100, Heinrich Schuchardt wrote:
> sym_arr is of type struct symbol **.
> So in malloc we need sizeof(struct symbol *).
> 
> The problem was indicated by coccinelle.
> 
> Signed-off-by: Heinrich Schuchardt 
> ---
>  scripts/kconfig/symbol.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/scripts/kconfig/symbol.c b/scripts/kconfig/symbol.c
> index 20136ffefb..3c8bd9bb42 100644
> --- a/scripts/kconfig/symbol.c
> +++ b/scripts/kconfig/symbol.c
> @@ -1061,7 +1061,7 @@ struct symbol **sym_re_search(const char *pattern)
>   }
>   if (sym_match_arr) {
>   qsort(sym_match_arr, cnt, sizeof(struct sym_match), 
> sym_rel_comp);
> - sym_arr = malloc((cnt+1) * sizeof(struct symbol));
> + sym_arr = malloc((cnt+1) * sizeof(struct symbol *));
>   if (!sym_arr)
>   goto sym_re_search_free;
>   for (i = 0; i < cnt; i++)

Since this comes right from the kernel, shouldn't it be fixed there too?
Or is it already?  Thanks!

-- 
Tom


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


Re: [U-Boot] [PATCH 2/2] configs: dragonboard410c: Save environment data on eMMC

2017-11-08 Thread Tom Rini
On Wed, Nov 08, 2017 at 08:49:09AM +0100, Jorge Ramirez wrote:
> On 11/07/2017 11:50 PM, Tom Rini wrote:
> >On Mon, Nov 06, 2017 at 02:16:38PM +0100, Jorge Ramirez-Ortiz wrote:
> >
> >>Save the environment data at the end of the boot partition on emmc
> >>
> >>Signed-off-by: Jorge Ramirez-Ortiz 
> >>---
> >>  arch/arm/dts/dragonboard410c-uboot.dtsi | 7 +++
> >>  configs/dragonboard410c_defconfig   | 2 ++
> >>  include/configs/dragonboard410c.h   | 1 +
> >>  3 files changed, 10 insertions(+)
> >Implementation this seems fine.  Is there a reason to do this vs
> >ENV_IS_IN_FAT?  Or ENV_IS_IN_EXT ? And have it be in a filesystem
> >instead?  That usually seems to be best for eval/dev/etc style boards.
> 
> I think having it on a partition offset (a partition that typically just
> stores the uboot image) can be very convenient when having the filesystem on
> an NFS share.
> 
> It means that the user can completely ignore flashing and maintaining the
> filesystem until he is ready. The only issue I see is that it is up to the
> user - when he reprograms a new image or modifies the size of the
> environemnt- to make sure the environment and whatever image is in the
> partition dont overlap each other but I think that should be acceptable?

Well, if you think environment in flash is best, that's fine.  I just
want to make sure the alternatives are known as I keep surprising people
when I note that the env can be a file in FAT or similar.  Thanks!

-- 
Tom


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


Re: [U-Boot] Support of latest qemux86-64

2017-11-08 Thread Bin Meng
On Wed, Nov 8, 2017 at 9:05 PM, Anton Gerasimov
 wrote:
> Adding Igor Mammedov to the loop.
>

Really add Igor Mammedov.

Igor, can you help look at this?

> On 11/08/2017 01:59 PM, Anton Gerasimov wrote:
>> To whoever might be interested: I've bisected qemu and the breaking
>> commit is 208fa0e43645edd0b0d8f838857dfc79daff40a8 (pc: make 'pc.rom'
>> readonly when machine has PCI enabled). It's just three lines added,
>> I'll paste the whole patch here. Not quite sure what can we do here though.
>>
>>
>>   diff --git a/hw/i386/pc.c b/hw/i386/pc.c
>>   index 22e16031b0..59435390ba 100644
>>   --- a/hw/i386/pc.c
>>   +++ b/hw/i386/pc.c
>>   @@ -1443,6 +1443,9 @@ void pc_memory_init(PCMachineState *pcms,
>>option_rom_mr = g_malloc(sizeof(*option_rom_mr));
>>memory_region_init_ram(option_rom_mr, NULL, "pc.rom", PC_ROM_SIZE,
>>   _fatal);
>>   +if (pcmc->pci_enabled) {
>>   +memory_region_set_readonly(option_rom_mr, true);
>>   +}
>>memory_region_add_subregion_overlap(rom_memory,
>>PC_ROM_MIN_VGA,
>>option_rom_mr,
>>
>>

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


Re: [U-Boot] [PATCH] mx6: Fix imx6_is_bmode_from_gpr9 always returns 0

2017-11-08 Thread Fabio Estevam
Hi Jeroen,

On Wed, Nov 8, 2017 at 3:01 PM, Jeroen Vollenbrock  wrote:
> Due to the cast to u8, this function always returned 0.
>
> CC: Stefano Babic 
>
> ---
>  arch/arm/include/asm/mach-imx/sys_proto.h |3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/include/asm/mach-imx/sys_proto.h 
> b/arch/arm/include/asm/mach-imx/sys_proto.h
> index 970c4ca..0447eef 100644
> --- a/arch/arm/include/asm/mach-imx/sys_proto.h
> +++ b/arch/arm/include/asm/mach-imx/sys_proto.h
> @@ -86,7 +86,8 @@ enum imx6_bmode {
>
>  static inline u8 imx6_is_bmode_from_gpr9(void)

Maybe make it 'static inline bool' instead?

Regards,

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


[U-Boot] [PATCH] TCP and wget implementation.

2017-11-08 Thread Duncan Hare
his is the interface and Kconfig files for introducing TCP and wget
into u-boot.

Interfaces are in net.c and net.h, ping is modified to the new ip send
interface, and UDP and TCP have shim procedures call map the protocol
interface to the ip interface.

The UDP interface is unchanged, and the existing UDP programs need no
changes.

All the code is new, and not copied from any source.

The wget command and TCP stack are separately configured in Kconfig,
and provisioning wget without TCP will result in a number of error
messages. It might be possible to have Kconfig handle dependencies,
if so advice is welcome.

Makefile in the net directory is modified by hand. It appears not to be
generated by Kconfig. Again advice is welcome.

The rationale behind this change is that UDP file transfers elapsed time
is twice the sum of network latency x number of pcckets, and TCP file
transfer times are about 4x network latency plus data transit time.

In tests this reduces kernel trnasfer time from about 15 to 20 seconds
with tftp on a raspberry pi to about 0.4 seconds with wget.

The raspberry pi as a sink for the kernel runs at about 10 Mbits/sec.

Signed-off-by: Duncan Hare 
---

 cmd/Kconfig   |   5 +++
 cmd/net.c |  13 
 include/net.h |  26 ---
 net/Kconfig   |   5 +++
 net/Makefile  |   3 +-
 net/net.c | 100 --
 net/ping.c|   9 ++
 7 files changed, 132 insertions(+), 29 deletions(-)

diff --git a/cmd/Kconfig b/cmd/Kconfig
index 5a6afab99b..4e5bac685e 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -1035,6 +1035,11 @@ config CMD_ETHSW
  operations such as enabling / disabling a port and
  viewing/maintaining the filtering database (FDB)
 
+config CMD_WGET
+   bool "wget"
+   help
+ Download a kernel, or other files, from a web server over TCP.
+
 endmenu
 
 menu "Misc commands"
diff --git a/cmd/net.c b/cmd/net.c
index d7c776aacf..f5c2d0f8ed 100644
--- a/cmd/net.c
+++ b/cmd/net.c
@@ -110,6 +110,19 @@ U_BOOT_CMD(
 );
 #endif
 
+#if defined(CONFIG_CMD_WGET)
+static int do_wget(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+   return netboot_common(WGET, cmdtp, argc, argv);
+}
+
+U_BOOT_CMD(
+   wget,   3,  1,  do_wget,
+   "boot image via network using HTTP protocol",
+   "[loadAddress] [[hostIPaddr:]bootfilename]"
+);
+#endif
+
 static void netboot_update_env(void)
 {
char tmp[22];
diff --git a/include/net.h b/include/net.h
index 455b48f6c7..7787413816 100644
--- a/include/net.h
+++ b/include/net.h
@@ -24,8 +24,17 @@
  * The number of receive packet buffers, and the required packet buffer
  * alignment in memory.
  *
+ * The nuber of buffers for TCP is used to calculate a static TCP window
+ * size, becuse TCP window size is a promise to the sending TCP to be able
+ * to buffer up to the window size of data.
+ * When the sending TCP has a window size of outstanding unacknowledged
+ * data, the sending TCP will stop sending.
  */
 
+#if defined(CONFIG_TCP)
+#define CONFIG_SYS_RX_ETH_BUFFER 50/* For TCP */
+#endif
+
 #ifdef CONFIG_SYS_RX_ETH_BUFFER
 # define PKTBUFSRX CONFIG_SYS_RX_ETH_BUFFER
 #else
@@ -354,6 +363,8 @@ struct vlan_ethernet_hdr {
 
 #define IPPROTO_ICMP1  /* Internet Control Message Protocol*/
 #define IPPROTO_UDP17  /* User Datagram Protocol   */
+#define IPPROTO_TCP 6  /* Transmission Control Protocol*/
+
 
 /*
  * Internet Protocol (IP) header.
@@ -538,7 +549,7 @@ extern int  net_restart_wrap;   /* Tried all 
network devices */
 
 enum proto_t {
BOOTP, RARP, ARP, TFTPGET, DHCP, PING, DNS, NFS, CDP, NETCONS, SNTP,
-   TFTPSRV, TFTPPUT, LINKLOCAL
+   TFTPSRV, TFTPPUT, LINKLOCAL, WGET
 };
 
 extern charnet_boot_file_name[1024];/* Boot File name */
@@ -596,10 +607,10 @@ int net_set_ether(uchar *xet, const uchar *dest_ethaddr, 
uint prot);
 int net_update_ether(struct ethernet_hdr *et, uchar *addr, uint prot);
 
 /* Set IP header */
-void net_set_ip_header(uchar *pkt, struct in_addr dest, struct in_addr source);
+void net_set_ip_header(uchar *pkt, struct in_addr dest, struct in_addr source,
+  u16  pkt_len, u8 prot);
 void net_set_udp_header(uchar *pkt, struct in_addr dest, int dport,
-   int sport, int len);
-
+   int sport, int len);
 /**
  * compute_ip_checksum() - Compute IP checksum
  *
@@ -670,9 +681,16 @@ static inline void net_send_packet(uchar *pkt, int len)
  * @param sport Source UDP port
  * @param payload_len Length of data after the UDP header
  */
+int net_send_ip_packet(uchar *ether, struct in_addr dest, int dport, int sport,
+  int payload_len, int proto, u8 action, u32 tcp_seq_num,
+  u32 tcp_ack_num);
+
 int net_send_udp_packet(uchar *ether, struct in_addr dest, int dport,
   

Re: [U-Boot] [PATCH 1/1] efi_loader: helloworld.c: remove superfluous include

2017-11-08 Thread Heinrich Schuchardt

On 09/05/2017 09:41 AM, Alexander Graf wrote:



On 04.09.17 09:25, Heinrich Schuchardt wrote:

Remove a superfluous include from helloworld.c

Signed-off-by: Heinrich Schuchardt 


This patch breaks compilation:

   https://travis-ci.org/agraf/u-boot/jobs/271837141

I'll remove it from my queue again (and thus rebase it).


Alex

Rob's patch 0d6ab32e371 "part: move efi_guid_t" has moved the definition 
of efi_guid_t from included/part_efi.h to include/efi.h so that the 
patch is now applicable.


It is available at
https://patchwork.ozlabs.org/patch/809554/

Best regards

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


[U-Boot] [PATCH v2 1/1] yaffs2: rework yaffs_new_obj_id

2017-11-08 Thread Heinrich Schuchardt
The iterator variable of list_for_each is never NULL.
if (1 || A) is always true.
Use break if entry found.

Signed-off-by: Heinrich Schuchardt 
---
v2
Avoid changing logic.
---
 fs/yaffs2/yaffs_guts.c | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/fs/yaffs2/yaffs_guts.c b/fs/yaffs2/yaffs_guts.c
index 32e6ff2a04..bbe0d700fb 100644
--- a/fs/yaffs2/yaffs_guts.c
+++ b/fs/yaffs2/yaffs_guts.c
@@ -1870,13 +1870,12 @@ static int yaffs_new_obj_id(struct yaffs_dev *dev)
while (!found) {
found = 1;
n += YAFFS_NOBJECT_BUCKETS;
-   if (1 || dev->obj_bucket[bucket].count > 0) {
-   list_for_each(i, >obj_bucket[bucket].list) {
-   /* If there is already one in the list */
-   if (i && list_entry(i, struct yaffs_obj,
-   hash_link)->obj_id == n) {
-   found = 0;
-   }
+   list_for_each(i, >obj_bucket[bucket].list) {
+   /* If there is already one in the list */
+   if (i && list_entry(i, struct yaffs_obj,
+   hash_link)->obj_id == n) {
+   found = 0;
+   break;
}
}
}
-- 
2.14.2

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


[U-Boot] [PATCH] dra7x: fastboot: Increase recovery partition size

2017-11-08 Thread Praneeth Bajjuri
As per current android recommendation
https://source.android.com/devices/architecture/kernel/modular-kernels

1. Android recovery mode should contain both SOC and ODM
kernel modules in the recovery partition.

2. If a kernel module is required both in recovery and normal boot
mode,  the module has to be located in recovery and vendor
partition seperately.

3. Kernel modules used in recovery mode should be independent
of vendor and odm partition

4. Recovery image should contain atleast
storage, display, keypad, battery and pmic modules.

Due to these requirements, recovery image size has increased
to >10MB.

This patch is to increase recovery partition size for TI devices
so that we dont see such flashing error

log:
sending 'recovery' (12560 KB)...
OKAY [  0.436s]
writing 'recovery'...
FAILED (remote: too large for partition)
finished. total time: 0.458s

Signed-off-by: Praneeth Bajjuri 
---
 include/configs/am57xx_evm.h | 2 +-
 include/configs/dra7xx_evm.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/configs/am57xx_evm.h b/include/configs/am57xx_evm.h
index ebb0474..dc05bea 100644
--- a/include/configs/am57xx_evm.h
+++ b/include/configs/am57xx_evm.h
@@ -56,7 +56,7 @@
"name=reserved,size=256K,uuid=${uuid_gpt_reserved};" \
"name=efs,size=16M,uuid=${uuid_gpt_efs};" \
"name=crypto,size=16K,uuid=${uuid_gpt_crypto};" \
-   "name=recovery,size=10M,uuid=${uuid_gpt_recovery};" \
+   "name=recovery,size=40M,uuid=${uuid_gpt_recovery};" \
"name=boot,size=10M,uuid=${uuid_gpt_boot};" \
"name=system,size=768M,uuid=${uuid_gpt_system};" \
"name=vendor,size=256M,uuid=${uuid_gpt_vendor};" \
diff --git a/include/configs/dra7xx_evm.h b/include/configs/dra7xx_evm.h
index 34a4555..f84c1f0 100644
--- a/include/configs/dra7xx_evm.h
+++ b/include/configs/dra7xx_evm.h
@@ -63,7 +63,7 @@
"name=reserved,size=256K,uuid=${uuid_gpt_reserved};" \
"name=efs,size=16M,uuid=${uuid_gpt_efs};" \
"name=crypto,size=16K,uuid=${uuid_gpt_crypto};" \
-   "name=recovery,size=10M,uuid=${uuid_gpt_recovery};" \
+   "name=recovery,size=40M,uuid=${uuid_gpt_recovery};" \
"name=boot,size=10M,uuid=${uuid_gpt_boot};" \
"name=system,size=768M,uuid=${uuid_gpt_system};" \
"name=vendor,size=256M,uuid=${uuid_gpt_vendor};" \
-- 
1.9.1

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


[U-Boot] [PATCH v2 1/1] scripts/ld-version.sh: regular expression compile fails

2017-11-08 Thread Heinrich Schuchardt
ld --version | scripts/ld-version.sh
fails with
awk: scripts/ld-version.sh:
line 4: regular expression compile failed (missing '(')
.*)

So let's refresh the script from Linux kernel v4.14-rc8.

Signed-off-by: Heinrich Schuchardt 
---
v2
Add license identifier.
Update commit message.
---
 scripts/ld-version.sh | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/scripts/ld-version.sh b/scripts/ld-version.sh
index 198580d245..f2be0ff9a7 100755
--- a/scripts/ld-version.sh
+++ b/scripts/ld-version.sh
@@ -1,8 +1,11 @@
 #!/usr/bin/awk -f
+# SPDX-License-Identifier: GPL-2.0
 # extract linker version number from stdin and turn into single number
{
-   gsub(".*)", "");
+   gsub(".*\\)", "");
+   gsub(".*version ", "");
+   gsub("-.*", "");
split($1,a, ".");
-   print a[1]*1000 + a[2]*10 + a[3]*1 + a[4]*100 + a[5];
+   print a[1]*1 + a[2]*100 + a[3]*1;
exit
}
-- 
2.14.2

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


[U-Boot] [PATCH 1/1] yaffs2: iterator variable cannot be NULL

2017-11-08 Thread Heinrich Schuchardt
The iterator variable of list_for_each is never NULL.

Signed-off-by: Heinrich Schuchardt 
---
 fs/yaffs2/yaffsfs.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/fs/yaffs2/yaffsfs.c b/fs/yaffs2/yaffsfs.c
index ba76a5ccdb..47abc6beda 100644
--- a/fs/yaffs2/yaffsfs.c
+++ b/fs/yaffs2/yaffsfs.c
@@ -2847,12 +2847,9 @@ static void yaffsfs_RemoveObjectCallback(struct 
yaffs_obj *obj)
 * the next one to prevent a hanging ptr.
 */
list_for_each(i, _contexts) {
-   if (i) {
-   dsc = list_entry(i, struct yaffsfs_DirSearchContxt,
-others);
-   if (dsc->nextReturn == obj)
-   yaffsfs_DirAdvance(dsc);
-   }
+   dsc = list_entry(i, struct yaffsfs_DirSearchContxt, others);
+   if (dsc->nextReturn == obj)
+   yaffsfs_DirAdvance(dsc);
}
 
 }
-- 
2.14.2

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


[U-Boot] [PATCH 1/1] yaffs2: rework yaffs_new_obj_id

2017-11-08 Thread Heinrich Schuchardt
The iterator variable of list_for_each is never NULL.
if (1 || A) is always true.
Remove superfluous while.

Signed-off-by: Heinrich Schuchardt 
---
 fs/yaffs2/yaffs_guts.c | 17 -
 1 file changed, 4 insertions(+), 13 deletions(-)

diff --git a/fs/yaffs2/yaffs_guts.c b/fs/yaffs2/yaffs_guts.c
index 32e6ff2a04..509e9839f1 100644
--- a/fs/yaffs2/yaffs_guts.c
+++ b/fs/yaffs2/yaffs_guts.c
@@ -1859,26 +1859,17 @@ static int yaffs_find_nice_bucket(struct yaffs_dev *dev)
 static int yaffs_new_obj_id(struct yaffs_dev *dev)
 {
int bucket = yaffs_find_nice_bucket(dev);
-   int found = 0;
struct list_head *i;
u32 n = (u32) bucket;
 
/* Now find an object value that has not already been taken
 * by scanning the list.
 */
-
-   while (!found) {
-   found = 1;
+   n += YAFFS_NOBJECT_BUCKETS;
+   list_for_each(i, >obj_bucket[bucket].list) {
+   if (list_entry(i, struct yaffs_obj, hash_link)->obj_id != n)
+   break;
n += YAFFS_NOBJECT_BUCKETS;
-   if (1 || dev->obj_bucket[bucket].count > 0) {
-   list_for_each(i, >obj_bucket[bucket].list) {
-   /* If there is already one in the list */
-   if (i && list_entry(i, struct yaffs_obj,
-   hash_link)->obj_id == n) {
-   found = 0;
-   }
-   }
-   }
}
return n;
 }
-- 
2.14.2

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


Re: [U-Boot] SUNXI: A64: Increase SPL size

2017-11-08 Thread André Przywara
On 08/11/17 19:59, Jagan Teki wrote:
> Hi,
> 
> I'm trying to increase SPL size to 64K(with SRAM A2), so-that SPL can
> able to fit new features like falcon. I knew the limit about 32K but
> page[1] stating that we can use approximately 192 KiB of contiguous
> SRAM.

We are not really sure about this. The memory following SRAM A1 is
called SRAM C (not A2, that is secure memory at 0x44000). And this is
actually meant for use by the DisplayEngine, AFAIK. We found it unstable
to use from the ARM cores. With the default config is it not even
covering the whole region as described in the manual.

> eGON.BT0 has limit of reading 32KB, Can't we use > 32KB SPL here?

Well, how? As far as I know the *BROM* does not load more than 32KB, at
least not with the ("un-encrypted") eGON.BT0 format. Or could you
actually load more code?

I *think* we can load more with the "secure" payload, which requires the
"secure boot" fuse to be burned (with no return), which in turn will let
the BROM refuse to load a standard eGON.BT0 Boot0/SPL, but only the
secure packaged version (TOC0): http://linux-sunxi.org/TOC0

> because I've tried with 64K SPL size with existing SPL code and was
> able to boot, but with increasing SPL by enabling falcon seems like
> BROM unable read eGON.BT0 which eventually booting failed. Any inputs?

So why do you need falcon, desperately? You can put the kernel into the
SPL FIT image (u-boot.itb), then have the U-Boot proper just execute
booti (no further loading). That works from SPI flash, also. If you are
really want to, you can disable USB, Ethernet and the timeout and save
some time here. But those are .config options and shouldn't require code
changes.

Cheers,
Andre.

> diff:
> 
> diff --git a/common/spl/Kconfig b/common/spl/Kconfig
> index 0bd8370..b43c1ff 100644
> --- a/common/spl/Kconfig
> +++ b/common/spl/Kconfig
> @@ -139,7 +139,7 @@ config SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR
>  config SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR
> hex "Address on the MMC to load U-Boot from"
> depends on SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR
> -   default 0x50 if ARCH_SUNXI
> +   default 0x90 if ARCH_SUNXI
> default 0x75 if ARCH_DAVINCI
> default 0x8a if ARCH_MX6
> default 0x100 if ARCH_ROCKCHIP || ARCH_UNIPHIER
> diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
> index bc74dba..805489c 100644
> --- a/include/configs/sunxi-common.h
> +++ b/include/configs/sunxi-common.h
> @@ -99,7 +99,7 @@
>   * the 1 actually activates the mapping of the first 32 KiB to 0x.
>   */
>  #define CONFIG_SYS_INIT_RAM_ADDR   0x1
> -#define CONFIG_SYS_INIT_RAM_SIZE   0x08000 /* FIXME: 40 KiB ? */
> +#define CONFIG_SYS_INIT_RAM_SIZE   0x1 /* FIXME: 40 KiB ? */
>  #else
>  #define CONFIG_SYS_INIT_RAM_ADDR   0x0
>  #define CONFIG_SYS_INIT_RAM_SIZE   0x8000  /* 32 KiB */
> @@ -191,7 +191,7 @@
> 
>  #ifdef CONFIG_SUNXI_HIGH_SRAM
>  #define CONFIG_SPL_TEXT_BASE   0x10060 /* sram start+header 
> */
> -#define CONFIG_SPL_MAX_SIZE0x7fa0  /* 32 KiB */
> +#define CONFIG_SPL_MAX_SIZE0xffa0  /* 192 KiB */
>  #ifdef CONFIG_ARM64
>  /* end of SRAM A2 for now, as SRAM A1 is pretty tight for an ARM64 build */
>  #define LOW_LEVEL_SRAM_STACK   0x00054000
> @@ -206,7 +206,7 @@
> 
>  #define CONFIG_SPL_STACK   LOW_LEVEL_SRAM_STACK
> 
> -#define CONFIG_SPL_PAD_TO  32768   /* decimal for 'dd' */
> +#define CONFIG_SPL_PAD_TO  65536   /* decimal for 'dd' */
> diff --git a/tools/mksunxiboot.c b/tools/mksunxiboot.c
> index db0f10e..31df7e2 100644
> --- a/tools/mksunxiboot.c
> +++ b/tools/mksunxiboot.c
> @@ -48,7 +48,7 @@ int gen_check_sum(struct boot_file_head *head_p)
>  #define ALIGN(x, a) __ALIGN_MASK((x), (typeof(x))(a)-1)
>  #define __ALIGN_MASK(x, mask) (((x)+(mask))&~(mask))
> 
> -#define SUNXI_SRAM_SIZE 0x8000 /* SoC with smaller size are limited before */
> +#define SUNXI_SRAM_SIZE 0x1/* SoC with smaller size are
> limited before */
>  #define SRAM_LOAD_MAX_SIZE (SUNXI_SRAM_SIZE - sizeof(struct boot_file_head))
> 
> [1] http://linux-sunxi.org/BROM
> 
> thanks!
> 

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


Re: [U-Boot] [PATCH 3/3] Powerpc: pcie: Make pcie link state judgement more specific

2017-11-08 Thread York Sun
On 11/08/2017 01:30 PM, Joakim Tjernlund wrote:
> On Wed, 2017-11-08 at 21:05 +, York Sun wrote:
>> CAUTION: This email originated from outside of the organization. Do not 
>> click links or open attachments unless you recognize the sender and know the 
>> content is safe.
>>
>>
>> On 10/22/2017 07:39 PM, Xiaowei Bao wrote:
>>>
>>> -Original Message-
>>> From: Joakim Tjernlund [mailto:joakim.tjernl...@infinera.com]
>>> Sent: Friday, October 20, 2017 9:13 PM
>>> To: w...@denx.de; Mingkai Hu ; 
>>> tony.obr...@alliedtelesis.co.nz; u-boot@lists.denx.de; Z.q. Hou 
>>> ; York Sun ; Xiaowei Bao 
>>> ; hamish.mar...@alliedtelesis.co.nz; M.h. Lian 
>>> 
>>> Subject: Re: [U-Boot] [PATCH 3/3] Powerpc: pcie: Make pcie link state 
>>> judgement more specific
>>>
>>> On Fri, 2017-10-20 at 18:16 +0800, Bao Xiaowei wrote:
 CAUTION: This email originated from outside of the organization. Do not 
 click links or open attachments unless you recognize the sender and know 
 the content is safe.


 For some special reset times for longer pcie devices, the pcie device
 may on polling compliance state, the RC considers the pcie device is
 link up, but the pcie device is not link up, only the L0 state is link
 up state.

 Signed-off-by: Bao Xiaowei 
 ---
  arch/powerpc/include/asm/fsl_pci.h |  2 ++
  drivers/pci/fsl_pci_init.c | 10 ++
  2 files changed, 8 insertions(+), 4 deletions(-)

 diff --git a/arch/powerpc/include/asm/fsl_pci.h
 b/arch/powerpc/include/asm/fsl_pci.h
 index 70a5461..323b182 100644
 --- a/arch/powerpc/include/asm/fsl_pci.h
 +++ b/arch/powerpc/include/asm/fsl_pci.h
 @@ -25,6 +25,8 @@
  #define PCI_LTSSM  0x404   /* PCIe Link Training, Status State 
 Machine */
  #define PCI_LTSSM_L0   0x16/* L0 state */
  #define PCI_LTSSM_L0_PEX_REV3  0x11/* L0 state for pex rev3*/
 +#define LTSSM_PCIE_DETECT_QUIET0x00/* Detect state */
 +#define LTSSM_PCIE_DETECT_ACTIVE   0x01/* Detect state */

  int fsl_setup_hose(struct pci_controller *hose, unsigned long addr);
 int fsl_is_pci_agent(struct pci_controller *hose); diff --git
 a/drivers/pci/fsl_pci_init.c b/drivers/pci/fsl_pci_init.c index
 be57e53..9b5f386 100644
 --- a/drivers/pci/fsl_pci_init.c
 +++ b/drivers/pci/fsl_pci_init.c
 @@ -335,15 +335,17 @@ static int fsl_pci_link_up(struct pci_controller 
 *hose,
 pci_ltssm_l0 = PCI_LTSSM_L0;

 ltssm = fsl_get_ltssm(hose, pci_info);
 -
 -   if (ltssm == pci_ltssm_l0) {
 +   if (ltssm == LTSSM_PCIE_DETECT_QUIET ||
 +   ltssm == LTSSM_PCIE_DETECT_ACTIVE) {
 +   enabled = 0;
 +   } else if (ltssm == pci_ltssm_l0) {
 enabled = 1;
 } else {
 -   for (i = 0; i < 100 && ltssm < pci_ltssm_l0; i++) {
 +   for (i = 0; i < 100 && ltssm != pci_ltssm_l0; i++) {
 ltssm = fsl_get_ltssm(hose, pci_info);
 udelay(1000);
>>>
>>> Do you really need this long loop here ? It causes a long delay in case the 
>>> PCIe device is in permanent polling state. Our device is in polling state 
>>> until clocks is configured and that will be done from user space in Linux
>>>
>>> Yes, if the pcie device is in permanent polling state, it will take 
>>> probably 100ms delay, but this case is occur very few special devices, if 
>>> we want to use the pcie device in uboot, we have to wait the device link up 
>>> state is ok, so need some time to wait the pcie device ready. if the pcie 
>>> slot have no device, the function will return at once, will not bring delay.
>>
>> Joakim,
>>
>> Are we OK with this change? Can you test it to make sure no negative
>> impact on your boards?
> 
> Not really happy, what device needs 100 ms extra to exit polling state? 
> 

Joakim,

I understand your concern. I don't like the delay either.

Xiaowei,

You said this only occur for very few special devices. Can you explain
more? How can you avoid this delay for general cases?

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


[U-Boot] [PATCH 1/1] ubi: no NULL check needed before kmem_cache_destroy

2017-11-08 Thread Heinrich Schuchardt
kmem_cache_destroy calls free which checks for NULL.

Problem was indicated by coccinelle.

Signed-off-by: Heinrich Schuchardt 
---
 drivers/mtd/ubi/attach.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/mtd/ubi/attach.c b/drivers/mtd/ubi/attach.c
index 90fb74a5c9..33c176a77b 100644
--- a/drivers/mtd/ubi/attach.c
+++ b/drivers/mtd/ubi/attach.c
@@ -1205,8 +1205,7 @@ static void destroy_ai(struct ubi_attach_info *ai)
}
}
 
-   if (ai->aeb_slab_cache)
-   kmem_cache_destroy(ai->aeb_slab_cache);
+   kmem_cache_destroy(ai->aeb_slab_cache);
 
kfree(ai);
 }
-- 
2.14.2

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


Re: [U-Boot] [PATCH 3/3] Powerpc: pcie: Make pcie link state judgement more specific

2017-11-08 Thread Joakim Tjernlund
On Wed, 2017-11-08 at 21:05 +, York Sun wrote:
> CAUTION: This email originated from outside of the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe.
> 
> 
> On 10/22/2017 07:39 PM, Xiaowei Bao wrote:
> > 
> > -Original Message-
> > From: Joakim Tjernlund [mailto:joakim.tjernl...@infinera.com]
> > Sent: Friday, October 20, 2017 9:13 PM
> > To: w...@denx.de; Mingkai Hu ; 
> > tony.obr...@alliedtelesis.co.nz; u-boot@lists.denx.de; Z.q. Hou 
> > ; York Sun ; Xiaowei Bao 
> > ; hamish.mar...@alliedtelesis.co.nz; M.h. Lian 
> > 
> > Subject: Re: [U-Boot] [PATCH 3/3] Powerpc: pcie: Make pcie link state 
> > judgement more specific
> > 
> > On Fri, 2017-10-20 at 18:16 +0800, Bao Xiaowei wrote:
> > > CAUTION: This email originated from outside of the organization. Do not 
> > > click links or open attachments unless you recognize the sender and know 
> > > the content is safe.
> > > 
> > > 
> > > For some special reset times for longer pcie devices, the pcie device
> > > may on polling compliance state, the RC considers the pcie device is
> > > link up, but the pcie device is not link up, only the L0 state is link
> > > up state.
> > > 
> > > Signed-off-by: Bao Xiaowei 
> > > ---
> > >  arch/powerpc/include/asm/fsl_pci.h |  2 ++
> > >  drivers/pci/fsl_pci_init.c | 10 ++
> > >  2 files changed, 8 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/arch/powerpc/include/asm/fsl_pci.h
> > > b/arch/powerpc/include/asm/fsl_pci.h
> > > index 70a5461..323b182 100644
> > > --- a/arch/powerpc/include/asm/fsl_pci.h
> > > +++ b/arch/powerpc/include/asm/fsl_pci.h
> > > @@ -25,6 +25,8 @@
> > >  #define PCI_LTSSM  0x404   /* PCIe Link Training, Status State 
> > > Machine */
> > >  #define PCI_LTSSM_L0   0x16/* L0 state */
> > >  #define PCI_LTSSM_L0_PEX_REV3  0x11/* L0 state for pex rev3*/
> > > +#define LTSSM_PCIE_DETECT_QUIET0x00/* Detect state */
> > > +#define LTSSM_PCIE_DETECT_ACTIVE   0x01/* Detect state */
> > > 
> > >  int fsl_setup_hose(struct pci_controller *hose, unsigned long addr);
> > > int fsl_is_pci_agent(struct pci_controller *hose); diff --git
> > > a/drivers/pci/fsl_pci_init.c b/drivers/pci/fsl_pci_init.c index
> > > be57e53..9b5f386 100644
> > > --- a/drivers/pci/fsl_pci_init.c
> > > +++ b/drivers/pci/fsl_pci_init.c
> > > @@ -335,15 +335,17 @@ static int fsl_pci_link_up(struct pci_controller 
> > > *hose,
> > > pci_ltssm_l0 = PCI_LTSSM_L0;
> > > 
> > > ltssm = fsl_get_ltssm(hose, pci_info);
> > > -
> > > -   if (ltssm == pci_ltssm_l0) {
> > > +   if (ltssm == LTSSM_PCIE_DETECT_QUIET ||
> > > +   ltssm == LTSSM_PCIE_DETECT_ACTIVE) {
> > > +   enabled = 0;
> > > +   } else if (ltssm == pci_ltssm_l0) {
> > > enabled = 1;
> > > } else {
> > > -   for (i = 0; i < 100 && ltssm < pci_ltssm_l0; i++) {
> > > +   for (i = 0; i < 100 && ltssm != pci_ltssm_l0; i++) {
> > > ltssm = fsl_get_ltssm(hose, pci_info);
> > > udelay(1000);
> > 
> > Do you really need this long loop here ? It causes a long delay in case the 
> > PCIe device is in permanent polling state. Our device is in polling state 
> > until clocks is configured and that will be done from user space in Linux
> > 
> > Yes, if the pcie device is in permanent polling state, it will take 
> > probably 100ms delay, but this case is occur very few special devices, if 
> > we want to use the pcie device in uboot, we have to wait the device link up 
> > state is ok, so need some time to wait the pcie device ready. if the pcie 
> > slot have no device, the function will return at once, will not bring delay.
> 
> Joakim,
> 
> Are we OK with this change? Can you test it to make sure no negative
> impact on your boards?

Not really happy, what device needs 100 ms extra to exit polling state? 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 1/1] ubifs: no NULL check needed before free

2017-11-08 Thread Heinrich Schuchardt
kfree() calls free.
free() checks if the parameter is NULL.

Signed-off-by: Heinrich Schuchardt 
---
 fs/ubifs/ubifs.c | 12 
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/fs/ubifs/ubifs.c b/fs/ubifs/ubifs.c
index 8f1c9d167d..4465523d5f 100644
--- a/fs/ubifs/ubifs.c
+++ b/fs/ubifs/ubifs.c
@@ -462,14 +462,10 @@ out:
dbg_gen("cannot find next direntry, error %d", err);
 
 out_free:
-   if (file->private_data)
-   kfree(file->private_data);
-   if (file)
-   free(file);
-   if (dentry)
-   free(dentry);
-   if (dir)
-   free(dir);
+   kfree(file->private_data);
+   free(file);
+   free(dentry);
+   free(dir);
 
return ret;
 }
-- 
2.14.2

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


[U-Boot] [PATCH 1/1] kconfig/symbol.c: use correct pointer type argument for sizeof

2017-11-08 Thread Heinrich Schuchardt
sym_arr is of type struct symbol **.
So in malloc we need sizeof(struct symbol *).

The problem was indicated by coccinelle.

Signed-off-by: Heinrich Schuchardt 
---
 scripts/kconfig/symbol.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/kconfig/symbol.c b/scripts/kconfig/symbol.c
index 20136ffefb..3c8bd9bb42 100644
--- a/scripts/kconfig/symbol.c
+++ b/scripts/kconfig/symbol.c
@@ -1061,7 +1061,7 @@ struct symbol **sym_re_search(const char *pattern)
}
if (sym_match_arr) {
qsort(sym_match_arr, cnt, sizeof(struct sym_match), 
sym_rel_comp);
-   sym_arr = malloc((cnt+1) * sizeof(struct symbol));
+   sym_arr = malloc((cnt+1) * sizeof(struct symbol *));
if (!sym_arr)
goto sym_re_search_free;
for (i = 0; i < cnt; i++)
-- 
2.14.2

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


Re: [U-Boot] [PATCH 3/3] Powerpc: pcie: Make pcie link state judgement more specific

2017-11-08 Thread York Sun
On 10/22/2017 07:39 PM, Xiaowei Bao wrote:
> 
> -Original Message-
> From: Joakim Tjernlund [mailto:joakim.tjernl...@infinera.com] 
> Sent: Friday, October 20, 2017 9:13 PM
> To: w...@denx.de; Mingkai Hu ; 
> tony.obr...@alliedtelesis.co.nz; u-boot@lists.denx.de; Z.q. Hou 
> ; York Sun ; Xiaowei Bao 
> ; hamish.mar...@alliedtelesis.co.nz; M.h. Lian 
> 
> Subject: Re: [U-Boot] [PATCH 3/3] Powerpc: pcie: Make pcie link state 
> judgement more specific
> 
> On Fri, 2017-10-20 at 18:16 +0800, Bao Xiaowei wrote:
>> CAUTION: This email originated from outside of the organization. Do not 
>> click links or open attachments unless you recognize the sender and know the 
>> content is safe.
>>
>>
>> For some special reset times for longer pcie devices, the pcie device 
>> may on polling compliance state, the RC considers the pcie device is 
>> link up, but the pcie device is not link up, only the L0 state is link 
>> up state.
>>
>> Signed-off-by: Bao Xiaowei 
>> ---
>>  arch/powerpc/include/asm/fsl_pci.h |  2 ++
>>  drivers/pci/fsl_pci_init.c | 10 ++
>>  2 files changed, 8 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/powerpc/include/asm/fsl_pci.h 
>> b/arch/powerpc/include/asm/fsl_pci.h
>> index 70a5461..323b182 100644
>> --- a/arch/powerpc/include/asm/fsl_pci.h
>> +++ b/arch/powerpc/include/asm/fsl_pci.h
>> @@ -25,6 +25,8 @@
>>  #define PCI_LTSSM  0x404   /* PCIe Link Training, Status State Machine 
>> */
>>  #define PCI_LTSSM_L0   0x16/* L0 state */
>>  #define PCI_LTSSM_L0_PEX_REV3  0x11/* L0 state for pex rev3*/
>> +#define LTSSM_PCIE_DETECT_QUIET0x00/* Detect state */
>> +#define LTSSM_PCIE_DETECT_ACTIVE   0x01/* Detect state */
>>
>>  int fsl_setup_hose(struct pci_controller *hose, unsigned long addr);  
>> int fsl_is_pci_agent(struct pci_controller *hose); diff --git 
>> a/drivers/pci/fsl_pci_init.c b/drivers/pci/fsl_pci_init.c index 
>> be57e53..9b5f386 100644
>> --- a/drivers/pci/fsl_pci_init.c
>> +++ b/drivers/pci/fsl_pci_init.c
>> @@ -335,15 +335,17 @@ static int fsl_pci_link_up(struct pci_controller *hose,
>> pci_ltssm_l0 = PCI_LTSSM_L0;
>>
>> ltssm = fsl_get_ltssm(hose, pci_info);
>> -
>> -   if (ltssm == pci_ltssm_l0) {
>> +   if (ltssm == LTSSM_PCIE_DETECT_QUIET ||
>> +   ltssm == LTSSM_PCIE_DETECT_ACTIVE) {
>> +   enabled = 0;
>> +   } else if (ltssm == pci_ltssm_l0) {
>> enabled = 1;
>> } else {
>> -   for (i = 0; i < 100 && ltssm < pci_ltssm_l0; i++) {
>> +   for (i = 0; i < 100 && ltssm != pci_ltssm_l0; i++) {
>> ltssm = fsl_get_ltssm(hose, pci_info);
>> udelay(1000);
> Do you really need this long loop here ? It causes a long delay in case the 
> PCIe device is in permanent polling state. Our device is in polling state 
> until clocks is configured and that will be done from user space in Linux
> 
> Yes, if the pcie device is in permanent polling state, it will take probably 
> 100ms delay, but this case is occur very few special devices, if we want to 
> use the pcie device in uboot, we have to wait the device link up state is ok, 
> so need some time to wait the pcie device ready. if the pcie slot have no 
> device, the function will return at once, will not bring delay.

Joakim,

Are we OK with this change? Can you test it to make sure no negative
impact on your boards?

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


Re: [U-Boot] [PATCH] driver: net: ldpaa_eth: Add PHY-less SGMII support

2017-11-08 Thread York Sun
On 11/06/2017 01:09 AM, Ashish Kumar wrote:
> In case of PHY-less mode, there is no interaction with PHY
> so auto-neg etc is not required and link will have fixed
> attributes
> 
> Signed-off-by: Ashish Kumar 
> Signed-off-by: Prabhakar Kushwaha 
> ---
>  drivers/net/ldpaa_eth/ldpaa_eth.c | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/ldpaa_eth/ldpaa_eth.c 
> b/drivers/net/ldpaa_eth/ldpaa_eth.c
> index 21be79a..85e7faa 100644
> --- a/drivers/net/ldpaa_eth/ldpaa_eth.c
> +++ b/drivers/net/ldpaa_eth/ldpaa_eth.c
> @@ -440,12 +440,17 @@ static int ldpaa_eth_open(struct eth_device *net_dev, 
> bd_t *bd)
>   bus = wriop_get_mdio(priv->dpmac_id);
>   enet_if = wriop_get_enet_if(priv->dpmac_id);
>   if ((bus == NULL) &&
> - (enet_if == PHY_INTERFACE_MODE_XGMII)) {
> +((enet_if == PHY_INTERFACE_MODE_XGMII) ||
> +(enet_if == PHY_INTERFACE_MODE_SGMII))) {
>   priv->phydev = (struct phy_device *)
>   malloc(sizeof(struct phy_device));
>   memset(priv->phydev, 0, sizeof(struct phy_device));
>  
> - priv->phydev->speed = SPEED_1;
> + if (enet_if == PHY_INTERFACE_MODE_XGMII)
> + priv->phydev->speed = SPEED_1;
> + else
> + priv->phydev->speed = SPEED_1000;
> +
>   priv->phydev->link = 1;
>   priv->phydev->duplex = DUPLEX_FULL;
>   }
> 

How was this patch tested?

A little off-topic. I remember a similar discussion somewhere (maybe
internal) for PowerPC-based boards regarding fixed SGMII port. When the
port doesn't have a PHY, it fails due to PHY id check. I don't find the
change in U-Boot code. Does anyone remember it?

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


Re: [U-Boot] [PATCH v4 1/7] armv8: lsch3: Add serdes and DDR voltage setup

2017-11-08 Thread York Sun
On 11/07/2017 02:37 AM, Rajesh Bhagat wrote:
> Adds SERDES voltage and reset SERDES lanes API and makes
> enable/disable DDR controller support 0.9V API common.
> 
> Signed-off-by: Ashish Kumar 
> Signed-off-by: Rajesh Bhagat 
> ---
> Changes in v4:
>   
>   - Added local macros instead of magical numbers 
>   
>   - Created macros to remove duplicate code
> 
> Changes in v3:
>  Restructured LS1088A VID support to use common VID driver
>  Cosmetic review comments fixed
>  Added __iomem for accessing registers
> 
> Changes in v2:
>  Checkpatch errors fixed
> 
>  .../cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c| 263 
> +
>  arch/arm/cpu/armv8/fsl-layerscape/soc.c|  34 +--
>  .../include/asm/arch-fsl-layerscape/fsl_serdes.h   |   2 +-
>  .../include/asm/arch-fsl-layerscape/immap_lsch3.h  |  34 +++
>  arch/arm/include/asm/arch-fsl-layerscape/soc.h |   1 +
>  5 files changed, 316 insertions(+), 18 deletions(-)
> 
> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c 
> b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c
> index 179cac6..6fbfbed 100644
> --- a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c
> +++ b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c
> @@ -158,6 +158,269 @@ void serdes_init(u32 sd, u32 sd_addr, u32 rcwsr, u32 
> sd_prctl_mask,
>   serdes_prtcl_map[NONE] = 1;
>  }
>  
> +__weak int get_serdes_volt(void)
> +{
> + return -1;
> +}
> +
> +__weak int set_serdes_volt(int svdd)
> +{
> + return -1;
> +}
> +
> +#define LNAGCR0_RESET_MASK   0xFF9F
> +#define LNAGCR0_RT_RSTB  0x0060
> +#define RSTCTL_RESET_MASK_1  0xFFBF
> +#define RSTCTL_RESET_MASK_2  0xFF1F
> +#define RSTCTL_RESET_MASK_3  0xFFEF
> +#define RSTCTL_RSTREQ0x8000
> +#define RSTCTL_RSTERR0x2000
> +#define RSTCTL_SDEN  0x0020
> +#define RSTCTL_SDRST_B   0x0040
> +#define RSTCTL_PLLRST_B  0x0080
> +#define RSTCTL_RST_DONE  0x4000
> +#define TCALCR_RESET_MASK0xF7FF
> +#define TCALCR_CALRST_B  0x0800
> +
> +#define CAT2(x, y) CAT2_(x, y)
> +#define CAT2_(x, y) x ## y
> +
> +#define CAT3(x, y, z) CAT3_(x, y, z)
> +#define CAT3_(x, y, z) x ## y ## z
> +
> +#define DO_ENABLED_LANES_RESET(x) do {   
> \
> + cfg_tmp = CAT2(cfg_rcwsrds, x) &\
> + CAT3(FSL_CHASSIS3_SRDS, x, _PRTCL_MASK);\
> + cfg_tmp >>= CAT3(FSL_CHASSIS3_SRDS, x, _PRTCL_SHIFT);   \
> + \
> + for (i = 0; i < 4 && cfg_tmp & (0xf << (3 - i)); i++) { \
> + reg = in_le32((serdes, x, _base)->lane[i].gcr0);   \
> + reg &= LNAGCR0_RESET_MASK;  \
> + out_le32((serdes, x, _base)->lane[i].gcr0, reg);   \
> + }   \
> +} while (0)
> +

I don't like these macros. They break grep-ability. I understand you are
trying to simply the code and reuse. There are other technique to do the
same. I personally would use local functions with pointers to deal with
serdes base, and use array to handle things like
FSL_CHASSIS3_SRDS1_PRTCL_SHIFT and masks.

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


Re: [U-Boot] [PATCH 1/1] scripts/ld-version.sh: regular expression compile fails

2017-11-08 Thread Tom Rini
On Wed, Nov 08, 2017 at 09:01:12PM +0100, Heinrich Schuchardt wrote:

> ls --version | scripts/ld-version.sh

... ld? :)

> fails with
> awk: scripts/ld-version.sh:
> line 4: regular expression compile failed (missing '(')
> .*)
> 
> So let's refresh the script with the current Linux kernel
> version.

Please specify tag or git-hash not just "current", for ease of future
re-syncs, thanks!

-- 
Tom


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


[U-Boot] [PATCH 1/1] scripts/ld-version.sh: regular expression compile fails

2017-11-08 Thread Heinrich Schuchardt
ls --version | scripts/ld-version.sh
fails with
awk: scripts/ld-version.sh:
line 4: regular expression compile failed (missing '(')
.*)

So let's refresh the script with the current Linux kernel
version.

Signed-off-by: Heinrich Schuchardt 
---
 scripts/ld-version.sh | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/scripts/ld-version.sh b/scripts/ld-version.sh
index 198580d245..d135882e2c 100755
--- a/scripts/ld-version.sh
+++ b/scripts/ld-version.sh
@@ -1,8 +1,10 @@
 #!/usr/bin/awk -f
 # extract linker version number from stdin and turn into single number
{
-   gsub(".*)", "");
+   gsub(".*\\)", "");
+   gsub(".*version ", "");
+   gsub("-.*", "");
split($1,a, ".");
-   print a[1]*1000 + a[2]*10 + a[3]*1 + a[4]*100 + a[5];
+   print a[1]*1 + a[2]*100 + a[3]*1;
exit
}
-- 
2.14.2

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


[U-Boot] SUNXI: A64: Increase SPL size

2017-11-08 Thread Jagan Teki
Hi,

I'm trying to increase SPL size to 64K(with SRAM A2), so-that SPL can
able to fit new features like falcon. I knew the limit about 32K but
page[1] stating that we can use approximately 192 KiB of contiguous
SRAM.

eGON.BT0 has limit of reading 32KB, Can't we use > 32KB SPL here?
because I've tried with 64K SPL size with existing SPL code and was
able to boot, but with increasing SPL by enabling falcon seems like
BROM unable read eGON.BT0 which eventually booting failed. Any inputs?

diff:

diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index 0bd8370..b43c1ff 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -139,7 +139,7 @@ config SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR
 config SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR
hex "Address on the MMC to load U-Boot from"
depends on SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR
-   default 0x50 if ARCH_SUNXI
+   default 0x90 if ARCH_SUNXI
default 0x75 if ARCH_DAVINCI
default 0x8a if ARCH_MX6
default 0x100 if ARCH_ROCKCHIP || ARCH_UNIPHIER
diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index bc74dba..805489c 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -99,7 +99,7 @@
  * the 1 actually activates the mapping of the first 32 KiB to 0x.
  */
 #define CONFIG_SYS_INIT_RAM_ADDR   0x1
-#define CONFIG_SYS_INIT_RAM_SIZE   0x08000 /* FIXME: 40 KiB ? */
+#define CONFIG_SYS_INIT_RAM_SIZE   0x1 /* FIXME: 40 KiB ? */
 #else
 #define CONFIG_SYS_INIT_RAM_ADDR   0x0
 #define CONFIG_SYS_INIT_RAM_SIZE   0x8000  /* 32 KiB */
@@ -191,7 +191,7 @@

 #ifdef CONFIG_SUNXI_HIGH_SRAM
 #define CONFIG_SPL_TEXT_BASE   0x10060 /* sram start+header */
-#define CONFIG_SPL_MAX_SIZE0x7fa0  /* 32 KiB */
+#define CONFIG_SPL_MAX_SIZE0xffa0  /* 192 KiB */
 #ifdef CONFIG_ARM64
 /* end of SRAM A2 for now, as SRAM A1 is pretty tight for an ARM64 build */
 #define LOW_LEVEL_SRAM_STACK   0x00054000
@@ -206,7 +206,7 @@

 #define CONFIG_SPL_STACK   LOW_LEVEL_SRAM_STACK

-#define CONFIG_SPL_PAD_TO  32768   /* decimal for 'dd' */
+#define CONFIG_SPL_PAD_TO  65536   /* decimal for 'dd' */
diff --git a/tools/mksunxiboot.c b/tools/mksunxiboot.c
index db0f10e..31df7e2 100644
--- a/tools/mksunxiboot.c
+++ b/tools/mksunxiboot.c
@@ -48,7 +48,7 @@ int gen_check_sum(struct boot_file_head *head_p)
 #define ALIGN(x, a) __ALIGN_MASK((x), (typeof(x))(a)-1)
 #define __ALIGN_MASK(x, mask) (((x)+(mask))&~(mask))

-#define SUNXI_SRAM_SIZE 0x8000 /* SoC with smaller size are limited before */
+#define SUNXI_SRAM_SIZE 0x1/* SoC with smaller size are
limited before */
 #define SRAM_LOAD_MAX_SIZE (SUNXI_SRAM_SIZE - sizeof(struct boot_file_head))

[1] http://linux-sunxi.org/BROM

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 17/18] efi_loader: refactor efi_setup_loaded_image

2017-11-08 Thread Heinrich Schuchardt

On 11/08/2017 04:18 PM, Alexander Graf wrote:

On 10/26/2017 07:25 PM, Heinrich Schuchardt wrote:

Use helper functions to add protocols.

Signed-off-by: Heinrich Schuchardt 
---
  lib/efi_loader/efi_boottime.c | 39 
+--

  1 file changed, 25 insertions(+), 14 deletions(-)

diff --git a/lib/efi_loader/efi_boottime.c 
b/lib/efi_loader/efi_boottime.c

index a526280e4c..3f23e6d638 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -1193,34 +1193,45 @@ void efi_setup_loaded_image(struct 
efi_loaded_image *info, struct efi_object *ob

  struct efi_device_path *device_path,
  struct efi_device_path *file_path)
  {
+    efi_status_t ret;
+
  obj->handle = info;
+    info->file_path = file_path;
+    if (device_path)
+    info->device_handle = efi_dp_find_obj(device_path, NULL);
+
+    list_add_tail(>link, _obj_list);
  /*
   * When asking for the device path interface, return
   * bootefi_device_path
   */
-    obj->protocols[0].guid = _guid_device_path;
-    obj->protocols[0].protocol_interface = device_path;
+    ret = efi_add_protocol(obj->handle, _guid_device_path, 
device_path);


Can we always assume that there are no other protocols installed 
already? The current code simply overrides them if there are any.




efi_setup_loaded_image is called from efi_load_image with a newly 
allocated obj, from do_bootefi_exit and do_bootefi with an initial local 
obj. So there cannot be any protocol existing.


We unlink the image from the object list after use so none of the 
protocols will be available when calling the next EFI application.


Best regards

Heinrich



Alex


+    if (ret != EFI_SUCCESS)
+    goto failure;
  /*
   * When asking for the loaded_image interface, just
   * return handle which points to loaded_image_info
   */
-    obj->protocols[1].guid = _guid_loaded_image;
-    obj->protocols[1].protocol_interface = info;
-
-    obj->protocols[2].guid = _guid_console_control;
-    obj->protocols[2].protocol_interface = (void *)_console_control;
+    ret = efi_add_protocol(obj->handle, _guid_loaded_image, info);
+    if (ret != EFI_SUCCESS)
+    goto failure;
-    obj->protocols[3].guid = _guid_device_path_to_text_protocol;
-    obj->protocols[3].protocol_interface =
-    (void *)_device_path_to_text;
+    ret = efi_add_protocol(obj->handle, _guid_console_control,
+   (void *)_console_control);
+    if (ret != EFI_SUCCESS)
+    goto failure;
-    info->file_path = file_path;
-    if (device_path)
-    info->device_handle = efi_dp_find_obj(device_path, NULL);
+    ret = efi_add_protocol(obj->handle,
+   _guid_device_path_to_text_protocol,
+   (void *)_device_path_to_text);
+    if (ret != EFI_SUCCESS)
+    goto failure;
-    list_add_tail(>link, _obj_list);
+    return;
+failure:
+    printf("ERROR: Failure to install protocols for loaded image\n");
  }
  /*






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


Re: [U-Boot] [PATCH v4 12/18] efi_selftest: correctly cleanup after selftest

2017-11-08 Thread Heinrich Schuchardt

On 11/08/2017 03:40 PM, Alexander Graf wrote:

On 10/18/2017 06:13 PM, Heinrich Schuchardt wrote:

After executing bootefi selftest
* restore GD
* unlink the load image handle
* return 0 or 1 and not a truncated efi_status_t.

Signed-off-by: Heinrich Schuchardt 
---
v4
no change
v3
new patch split off
---
  cmd/bootefi.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 18331536dd..40834f3899 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -349,8 +349,10 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, 
int argc, char * const argv[])

  set_load_options(_image_info, "efi_selftest");
  /* Execute the test */
  r = efi_selftest(_image_info, );
+    efi_restore_gd();


Why don't we have to restore gd on normal efi binaries? Because Exit() 
is doing that for us?


In that case, why not call efi_selftest() through efi_do_enter()? That 
should give you the exit call for free ;)




efi_do_enter calls boottime->exit which should unload the EFI 
application image (something we still need to implement). efi_selftest 
does not have an image to be unloaded. Hence I would prefer to keep 
efi_selftest separate from image handling functions.


Best regards

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


Re: [U-Boot] [PATCH v6 1/2] armv8: ls1088ardb: Add SD boot support for ls1088

2017-11-08 Thread York Sun
On 11/05/2017 11:48 PM, Ashish Kumar wrote:
> Signed-off-by: Prabhakar Kushwaha 
> Signed-off-by: Ashish Kumar 
> Signed-off-by: Raghav Dogra 
> ---
> v6:
> Incorporation of review comments in README wrt to line wrap.
> Sorting defconfig with help make savedefconfig
> 
>  arch/arm/Kconfig   |  1 +
>  arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch3 | 44 
> ++
>  board/freescale/ls1088a/MAINTAINERS|  1 +
>  board/freescale/ls1088a/ddr.c  |  5 ++-
>  configs/ls1088ardb_sdcard_qspi_defconfig   | 41 
>  include/configs/ls1088a_common.h   | 25 
>  include/configs/ls1088ardb.h   | 30 ++-
>  7 files changed, 144 insertions(+), 3 deletions(-)
>  create mode 100644 configs/ls1088ardb_sdcard_qspi_defconfig
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 83b7aa5..5707111 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -938,6 +938,7 @@ config TARGET_LS1088ARDB
>   select ARMV8_MULTIENTRY
>   select ARCH_MISC_INIT
>   select BOARD_LATE_INIT
> + select SUPPORT_SPL
>   help
> Support for NXP LS1088ARDB platform.
> The LS1088A Reference design board (RDB) is a high-performance
> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch3 
> b/arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch3
> index 7867c37..522760b 100644
> --- a/arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch3
> +++ b/arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch3
> @@ -201,6 +201,50 @@ nand write  8  u-boot image>
>  Notice the difference from QDS is SRC, SRC_ADDR and the offset of u-boot 
> image
>  to match board NAND device with 4KB/page, block size 512KB.
>  
> +Booting from SD/eMMC
> +---
> +Booting from SD/eMMC requires two images, RCW and u-boot-with-spl.bin.
> +The difference between SD boot RCW image and QSPI-NOR boot image is the
> +PBI command sequence. Below is one example for PBI commands for RDB
> +and QDS which uses SD device with block size 512. Block location can be
> +calculated by dividing offset with block size.
> +
> +1) Block Copy: SRC=0x0040, SRC_ADDR=0x0010, DEST_ADDR=0x1800a000,
> +BLOCK_SIZE=0x00016000
> +
> +This command copies u-boot image from SD device into OCRAM. The values
> +need to adjust accordingly for SD/eMMC
> +
> +SRC  should match the cfg_rcw_src, the reset config pins.
> + The value for source(SRC) can be 0x0040 or 0x0041
> + depending upon SD or eMMC.
> +SRC_ADDR is the offset of u-boot-with-spl.bin image in SD device.
> + In the example above, 1MB. This is same as QSPI-NOR.
> +DEST_ADDRis configured at 0x1800a000, matching bootloc set above.
> +BLOCK_SIZE   is the size to be copied by PBI.
> +
> +2) CCSR 4-byte write to 0x01e00404, data=0x
> +3) CCSR 4-byte write to 0x01e00400, data=0x1800a000
> +The above two commands set bootloc register to 0x_1800a000 where
> +the u-boot code will be running in OCRAM.
> +
> +
> +RCW image should be written at 8th block of device(SD/eMMC). Example of
> +using u-boot command
> +
> +mmc erase 0x8 0x10
> +mmc write  0x8  value=10>

It is not wrong to erase the sectors first. I think we don't need to
erase the SD first. The write command should just work. On the other
hand, the number of blocks to be erased seems too large The RCW is
normally very small (less than 1 block). Would it be more appropriate to
use a smaller number as the "typical" value, such as 1?

> +
> +To form the SD-Boot image, build u-boot with SD config, for example,
> +ls1088ardb_sdcard_qspi_defconfig. The image needed is u-boot-with-spl.bin.
> +The u-boot image should be written to match SRC_ADDR, in above example
> +offset 0x10 in other work it means block location 0x800

s/work/word

If you agree, I will fix them at the time of merging.

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


Re: [U-Boot] [PATCH 12/13] efi_loader: manage protocols in a linked list

2017-11-08 Thread Heinrich Schuchardt

On 11/08/2017 04:43 PM, Alexander Graf wrote:

On 11/01/2017 09:31 AM, Heinrich Schuchardt wrote:

Signed-off-by: Heinrich Schuchardt 
---
  include/efi_loader.h  |   6 ++-
  lib/efi_loader/efi_boottime.c | 107 
--

  lib/efi_loader/efi_disk.c |   1 +
  lib/efi_loader/efi_gop.c  |   1 +
  lib/efi_loader/efi_net.c  |   1 +
  5 files changed, 58 insertions(+), 58 deletions(-)

diff --git a/include/efi_loader.h b/include/efi_loader.h
index e1f0af3496..a73bbc1269 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -101,6 +101,8 @@ extern unsigned int __efi_runtime_rel_start, 
__efi_runtime_rel_stop;
   * interface (usually a struct with callback functions), this struct 
maps the

   * protocol GUID to the respective protocol interface */
  struct efi_handler {
+    /* Link to the list of protocols of a handle */
+    struct list_head link;
  const efi_guid_t *guid;
  void *protocol_interface;
  };
@@ -115,8 +117,8 @@ struct efi_handler {
  struct efi_object {
  /* Every UEFI object is part of a global object list */
  struct list_head link;
-    /* We support up to 16 "protocols" an object can be accessed 
through */

-    struct efi_handler protocols[16];
+    /* The list of protocols */
+    struct list_head protocols;
  /* The object spawner can either use this for data or as 
identifier */

  void *handle;
  };
diff --git a/lib/efi_loader/efi_boottime.c 
b/lib/efi_loader/efi_boottime.c

index 2b3db162a1..cee0cb1390 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -339,6 +339,7 @@ efi_status_t efi_create_handle(void **handle)
  return r;
  memset(obj, 0, sizeof(struct efi_object));
  obj->handle = obj;
+    INIT_LIST_HEAD(>protocols);
  list_add_tail(>link, _obj_list);
  *handle = obj;
  return r;
@@ -715,18 +716,17 @@ efi_status_t efi_search_protocol(const void 
*handle,

   struct efi_handler **handler)
  {
  struct efi_object *efiobj;
-    size_t i;
-    struct efi_handler *protocol;
+    struct list_head *lhandle;
  if (!handle || !protocol_guid)
  return EFI_INVALID_PARAMETER;
  efiobj = efi_search_obj(handle);
  if (!efiobj)
  return EFI_INVALID_PARAMETER;
-    for (i = 0; i < ARRAY_SIZE(efiobj->protocols); i++) {
-    protocol = >protocols[i];
-    if (!protocol->guid)
-    continue;
+    list_for_each(lhandle, >protocols) {
+    struct efi_handler *protocol;
+
+    protocol = list_entry(lhandle, struct efi_handler, link);
  if (!guidcmp(protocol->guid, protocol_guid)) {
  if (handler)
  *handler = protocol;
@@ -750,7 +750,6 @@ efi_status_t efi_add_protocol(const void *handle, 
const efi_guid_t *protocol,

  struct efi_object *efiobj;
  struct efi_handler *handler;
  efi_status_t ret;
-    size_t i;
  efiobj = efi_search_obj(handle);
  if (!efiobj)
@@ -761,16 +760,10 @@ efi_status_t efi_add_protocol(const void 
*handle, const efi_guid_t *protocol,

  handler = calloc(1, sizeof(struct efi_handler));
  if (!handler)
  return EFI_OUT_OF_RESOURCES;
-    /* Install protocol in first empty slot. */
-    for (i = 0; i < ARRAY_SIZE(efiobj->protocols); i++) {
-    handler = >protocols[i];
-    if (handler->guid)
-    continue;
-    handler->guid = protocol;
-    handler->protocol_interface = protocol_interface;
-    return EFI_SUCCESS;
-    }
-    return EFI_OUT_OF_RESOURCES;
+    handler->guid = protocol;
+    handler->protocol_interface = protocol_interface;
+    list_add_tail(>link, >protocols);
+    return EFI_SUCCESS;
  }
  /*
@@ -790,10 +783,10 @@ efi_status_t efi_remove_protocol(const void 
*handle, const efi_guid_t *protocol,

  ret = efi_search_protocol(handle, protocol, );
  if (ret != EFI_SUCCESS)
  return ret;
-    if (handler->protocol_interface != protocol_interface)
-    return EFI_NOT_FOUND;
-    handler->guid = NULL;
-    handler->protocol_interface = NULL;
+    if (guidcmp(handler->guid, protocol))
+    return EFI_INVALID_PARAMETER;
+    list_del(>link);
+    free(handler);
  return EFI_SUCCESS;
  }
@@ -806,17 +799,22 @@ efi_status_t efi_remove_protocol(const void 
*handle, const efi_guid_t *protocol,

  efi_status_t efi_remove_all_protocols(const void *handle)
  {
  struct efi_object *efiobj;
-    struct efi_handler *handler;
-    size_t i;
+    struct list_head *lhandle;
+    struct list_head *pos;
  efiobj = efi_search_obj(handle);
  if (!efiobj)
  return EFI_INVALID_PARAMETER;
+    list_for_each_safe(lhandle, pos, >protocols) {
+    struct efi_handler *protocol;
+    efi_status_t ret;
-    for (i = 0; i < ARRAY_SIZE(efiobj->protocols); i++) {
-    handler = >protocols[i];
-    handler->guid = NULL;
-    handler->protocol_interface = NULL;
+    protocol = 

Re: [U-Boot] [PATCH 1/1] efi_loader: manage protocols in a linked list

2017-11-08 Thread Heinrich Schuchardt

On 11/08/2017 04:29 PM, Alexander Graf wrote:

On 11/01/2017 09:31 AM, Heinrich Schuchardt wrote:

Signed-off-by: Heinrich Schuchardt 


I guess you did not mean to send this email? :)


Alex



Yes this is duplicate to
[PATCH 12/13] efi_loader: manage protocols in a linked list

Regards

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


Re: [U-Boot] [PATCH] gpt: add part-uuid and part-num subcommands

2017-11-08 Thread Otavio Salvador
On Wed, Nov 8, 2017 at 3:16 PM, Andrey Yurovsky  wrote:
> On Wed, Nov 8, 2017 at 2:47 AM Otavio Salvador
>  wrote:
>>
>> On Tue, Nov 7, 2017 at 10:43 PM, your name  wrote:
>> > From: Andrey Yurovsky 
>> >
>> > It is useful to be able to retrieve a partition UUID or number given
>> > the partition label, for instance some systems use the partition label
>> > to indicate the purpose of the partition (such as "rootfs0" being the
>> > 0th root file system in an A/B image scheme).
>> >
>> > Add "gpt part-uuid" to retrieve the partition UUID for a given label and
>> > "gpt part-num" to retrieve the partition number for a given label along
>> > with some documentation.
>> >
>> > Signed-off-by: Andrey Yurovsky 
>>
>> Why not use the 'part' cmd? it provides it.
>
>
> The use case is, given a label, find the UUID and/or the partition number. I
> see that 'part' can give me the UUID if I knew the partition number, it can
> print the whole table (but I don't think I can use that output cleanly), and
> it can list the partition numbers. I don't think I can solve my problem with
> 'part' as-is unless I have missed something.
>
> If that's the case would it be alright to add these subcommands to 'part'?
> Thank you again,

It looks to be the best approach for me.

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


Re: [U-Boot] [PATCH 01/13] efi_loader: efi_bootmgr: do not make hidden assignments

2017-11-08 Thread Heinrich Schuchardt

On 11/08/2017 04:27 PM, Alexander Graf wrote:

On 11/01/2017 09:31 AM, Heinrich Schuchardt wrote:

Assignments should not be made in the middle of nowhere.

Signed-off-by: Heinrich Schuchardt 
---
  lib/efi_loader/efi_bootmgr.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/efi_loader/efi_bootmgr.c b/lib/efi_loader/efi_bootmgr.c
index 857d88a879..d8d0e495f7 100644
--- a/lib/efi_loader/efi_bootmgr.c
+++ b/lib/efi_loader/efi_bootmgr.c
@@ -120,10 +120,10 @@ static void *try_load_entry(uint16_t n, struct 
efi_device_path **device_path,

  if (lo.attributes & LOAD_OPTION_ACTIVE) {
  efi_status_t ret;
-    u16 *str = NULL;
+    u16 *str = efi_dp_str(lo.file_path);
  debug("%s: trying to load \"%ls\" from: %ls\n", __func__,
-  lo.label, (str = efi_dp_str(lo.file_path)));
+  lo.label, str);
  efi_free_pool(str);


I believe the idea was to only go through efi_dp_str() if debugging is 
enabled.


Maybe write it as

#ifdef DEBUG


We would have to evaluate _DEBUG here like debug does.

Regards

Heinrich


u16 *str = efi_dp_str(...);
#else
u16 *str = NULL,
#endif

instead?


Alex




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


[U-Boot] [PATCH] mx6: Fix imx6_is_bmode_from_gpr9 always returns 0

2017-11-08 Thread Jeroen Vollenbrock
Due to the cast to u8, this function always returned 0. 

CC: Stefano Babic 

---
 arch/arm/include/asm/mach-imx/sys_proto.h |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/mach-imx/sys_proto.h 
b/arch/arm/include/asm/mach-imx/sys_proto.h
index 970c4ca..0447eef 100644
--- a/arch/arm/include/asm/mach-imx/sys_proto.h
+++ b/arch/arm/include/asm/mach-imx/sys_proto.h
@@ -86,7 +86,8 @@ enum imx6_bmode {
 
 static inline u8 imx6_is_bmode_from_gpr9(void)
 {
-   return readl(_base->gpr10) & IMX6_SRC_GPR10_BMODE;
+   return (readl(_base->gpr10) & IMX6_SRC_GPR10_BMODE)
+       == IMX6_SRC_GPR10_BMODE;
 }
 
 u32 imx6_src_get_boot_mode(void);
-- 
1.7.10.4


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


[U-Boot] [PATCH 03/16] net: e1000: split e1000_read_mac_addr

2017-11-08 Thread Martyn Welch
From: Hannu Lounento 

Split the implementation of e1000_read_mac_addr into eeprom and register
versions called by e1000_read_mac_addr.

This allows for calling e1000_read_mac_addr when MAC address is needed
with no constraints where it is read from, and for calling the register
and, especially, the eeprom version directly in order to specify where
to read the address from.

Signed-off-by: Hannu Lounento 
CC: Joe Hershberger 
Signed-off-by: Martyn Welch 
---
 drivers/net/e1000.c | 81 +
 1 file changed, 63 insertions(+), 18 deletions(-)

diff --git a/drivers/net/e1000.c b/drivers/net/e1000.c
index 7aecdb9..9a3e8f8 100644
--- a/drivers/net/e1000.c
+++ b/drivers/net/e1000.c
@@ -1311,33 +1311,21 @@ static bool e1000_is_second_port(struct e1000_hw *hw)
 
 #ifndef CONFIG_E1000_NO_NVM
 /**
- * Reads the adapter's MAC address from the EEPROM and inverts the LSB for the
- * second function of dual function devices
+ * Reads the adapter's MAC address from the EEPROM
  *
- * nic - Struct containing variables accessed by shared code
+ * hw - Struct containing variables accessed by shared code
+ * enetaddr - buffering where the MAC address will be stored
  */
-static int
-e1000_read_mac_addr(struct e1000_hw *hw, unsigned char enetaddr[6])
+static int e1000_read_mac_addr_from_eeprom(struct e1000_hw *hw,
+  unsigned char enetaddr[6])
 {
uint16_t offset;
uint16_t eeprom_data;
-   uint32_t reg_data = 0;
int i;
 
-   DEBUGFUNC();
-
for (i = 0; i < NODE_ADDRESS_SIZE; i += 2) {
offset = i >> 1;
-   if (hw->mac_type == e1000_igb) {
-   /* i210 preloads MAC address into RAL/RAH registers */
-   if (offset == 0)
-   reg_data = E1000_READ_REG_ARRAY(hw, RA, 0);
-   else if (offset == 1)
-   reg_data >>= 16;
-   else if (offset == 2)
-   reg_data = E1000_READ_REG_ARRAY(hw, RA, 1);
-   eeprom_data = reg_data & 0x;
-   } else if (e1000_read_eeprom(hw, offset, 1, _data) < 0) {
+   if (e1000_read_eeprom(hw, offset, 1, _data) < 0) {
DEBUGOUT("EEPROM Read Error\n");
return -E1000_ERR_EEPROM;
}
@@ -1345,6 +1333,63 @@ e1000_read_mac_addr(struct e1000_hw *hw, unsigned char 
enetaddr[6])
enetaddr[i + 1] = (eeprom_data >> 8) & 0xff;
}
 
+   return 0;
+}
+
+/**
+ * Reads the adapter's MAC address from the RAL/RAH registers
+ *
+ * hw - Struct containing variables accessed by shared code
+ * enetaddr - buffering where the MAC address will be stored
+ */
+static int e1000_read_mac_addr_from_regs(struct e1000_hw *hw,
+unsigned char enetaddr[6])
+{
+   uint16_t offset, tmp;
+   uint32_t reg_data = 0;
+   int i;
+
+   if (hw->mac_type != e1000_igb)
+   return -E1000_ERR_MAC_TYPE;
+
+   for (i = 0; i < NODE_ADDRESS_SIZE; i += 2) {
+   offset = i >> 1;
+
+   if (offset == 0)
+   reg_data = E1000_READ_REG_ARRAY(hw, RA, 0);
+   else if (offset == 1)
+   reg_data >>= 16;
+   else if (offset == 2)
+   reg_data = E1000_READ_REG_ARRAY(hw, RA, 1);
+   tmp = reg_data & 0x;
+
+   enetaddr[i] = tmp & 0xff;
+   enetaddr[i + 1] = (tmp >> 8) & 0xff;
+   }
+
+   return 0;
+}
+
+/**
+ * Reads the adapter's MAC address from the EEPROM and inverts the LSB for the
+ * second function of dual function devices
+ *
+ * hw - Struct containing variables accessed by shared code
+ * enetaddr - buffering where the MAC address will be stored
+ */
+static int e1000_read_mac_addr(struct e1000_hw *hw, unsigned char enetaddr[6])
+{
+   int ret_val;
+
+   if (hw->mac_type == e1000_igb) {
+   /* i210 preloads MAC address into RAL/RAH registers */
+   ret_val = e1000_read_mac_addr_from_regs(hw, enetaddr);
+   } else {
+   ret_val = e1000_read_mac_addr_from_eeprom(hw, enetaddr);
+   }
+   if (ret_val)
+   return ret_val;
+
/* Invert the last bit if this is the second device */

[U-Boot] [PATCH 05/16] rtc: adding RX8010SJ rtc driver

2017-11-08 Thread Martyn Welch
From: Nandor Han 

Add a new driver for RX8010SJ rtc chip. The driver implements both
formats of U-Boot driver model.

Signed-off-by: Nandor Han 
Signed-off-by: Martyn Welch 
---
 drivers/rtc/Kconfig|   6 +
 drivers/rtc/Makefile   |   1 +
 drivers/rtc/rx8010sj.c | 378 +
 3 files changed, 385 insertions(+)
 create mode 100644 drivers/rtc/rx8010sj.c

diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 2964bb2..95ac031 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -30,6 +30,12 @@ config RTC_DS1307
  Support for Dallas Semiconductor (now Maxim) DS1307 and DS1338/9 and
  compatible Real Time Clock devices.
 
+config RTC_RX8010SJ
+   bool "Enable RX8010SJ driver"
+   depends on DM_RTC
+   help
+ Support for Epson RX8010SJ Real Time Clock devices.
+
 config RTC_S35392A
bool "Enable S35392A driver"
select BITREVERSE
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 7a8f97a..9723fb7 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -48,6 +48,7 @@ obj-$(CONFIG_RTC_PT7C4338) += pt7c4338.o
 obj-$(CONFIG_RTC_RS5C372A) += rs5c372.o
 obj-$(CONFIG_RTC_RV3029) += rv3029.o
 obj-$(CONFIG_RTC_RX8025) += rx8025.o
+obj-$(CONFIG_RTC_RX8010SJ) += rx8010sj.o
 obj-$(CONFIG_RTC_S3C24X0) += s3c24x0_rtc.o
 obj-$(CONFIG_RTC_S35392A) += s35392a.o
 obj-$(CONFIG_SANDBOX) += sandbox_rtc.o
diff --git a/drivers/rtc/rx8010sj.c b/drivers/rtc/rx8010sj.c
new file mode 100644
index 000..81560e1
--- /dev/null
+++ b/drivers/rtc/rx8010sj.c
@@ -0,0 +1,378 @@
+/*
+ * Epson RX8010 RTC driver.
+ *
+ * Copyright (c) 2017, General Electric Company
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*-*/
+/* #undef DEBUG_RTC */
+
+#ifdef DEBUG_RTC
+#define DEBUGR(fmt, args...) printf(fmt, ##args)
+#else
+#define DEBUGR(fmt, args...)
+#endif
+/*-*/
+
+#ifndef CONFIG_SYS_I2C_RTC_ADDR
+# define CONFIG_SYS_I2C_RTC_ADDR   0x32
+#endif
+
+/*
+ * RTC register addresses
+ */
+#define RX8010_SEC 0x10
+#define RX8010_MIN 0x11
+#define RX8010_HOUR0x12
+#define RX8010_WDAY0x13
+#define RX8010_MDAY0x14
+#define RX8010_MONTH   0x15
+#define RX8010_YEAR0x16
+#define RX8010_YEAR0x16
+#define RX8010_RESV17  0x17
+#define RX8010_ALMIN   0x18
+#define RX8010_ALHOUR  0x19
+#define RX8010_ALWDAY  0x1A
+#define RX8010_TCOUNT0 0x1B
+#define RX8010_TCOUNT1 0x1C
+#define RX8010_EXT 0x1D
+#define RX8010_FLAG0x1E
+#define RX8010_CTRL0x1F
+/* 0x20 to 0x2F are user registers */
+#define RX8010_RESV30  0x30
+#define RX8010_RESV31  0x32
+#define RX8010_IRQ 0x32
+
+#define RX8010_EXT_WADA  BIT(3)
+
+#define RX8010_FLAG_VLF  BIT(1)
+#define RX8010_FLAG_AF   BIT(3)
+#define RX8010_FLAG_TF   BIT(4)
+#define RX8010_FLAG_UF   BIT(5)
+
+#define RX8010_CTRL_AIE  BIT(3)
+#define RX8010_CTRL_UIE  BIT(5)
+#define RX8010_CTRL_STOP BIT(6)
+#define RX8010_CTRL_TEST BIT(7)
+
+#define RX8010_ALARM_AE  BIT(7)
+
+#ifdef CONFIG_DM_RTC
+
+#define DEV_TYPE struct udevice
+
+#else
+
+/* Local udevice */
+struct ludevice {
+   u8 chip;
+};
+
+#define DEV_TYPE struct ludevice
+
+#endif
+
+static int rx8010sj_rtc_read8(DEV_TYPE *dev, unsigned int reg)
+{
+   u8 val;
+   int ret;
+
+#ifdef CONFIG_DM_RTC
+   ret = dm_i2c_read(dev, reg, , sizeof(val));
+#else
+   ret = i2c_read(dev->chip, reg, 1, , 1);
+#endif
+
+   return ret < 0 ? ret : val;
+}
+
+static int rx8010sj_rtc_write8(DEV_TYPE *dev, unsigned int reg, int val)
+{
+   int ret;
+   u8 lval = val;
+
+#ifdef CONFIG_DM_RTC
+   ret = dm_i2c_write(dev, reg, , 1);
+#else
+   ret = i2c_write(dev->chip, reg, 1, , 1);
+#endif
+
+   return ret < 0 ? ret : 0;
+}
+
+static int validate_time(const struct rtc_time *tm)
+{
+   if ((tm->tm_year < 2000) || (tm->tm_year > 2099))
+   return -EINVAL;
+
+   if ((tm->tm_mon < 1) || (tm->tm_mon > 12))
+   return -EINVAL;
+
+   if ((tm->tm_mday < 1) || (tm->tm_mday > 31))
+   return -EINVAL;
+
+   if ((tm->tm_wday < 0) || (tm->tm_wday > 6))
+   return -EINVAL;
+
+   if ((tm->tm_hour < 0) || (tm->tm_hour 

[U-Boot] [PATCH 16/16] board,ge,bx50v3 - rtc time validation

2017-11-08 Thread Martyn Welch
From: Nandor Han 

Validate the time at startup:
 - in case rtc error add to kernel command line RTC_ERROR
 - clamp date to 1-Jan-2036

Signed-off-by: Nandor Han 
Signed-off-by: Martyn Welch 
---
 board/ge/bx50v3/bx50v3.c| 3 +++
 configs/ge_b850v3_defconfig | 1 +
 include/configs/ge_bx50v3.h | 6 +-
 3 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/board/ge/bx50v3/bx50v3.c b/board/ge/bx50v3/bx50v3.c
index e35afa03..c7a2918 100644
--- a/board/ge/bx50v3/bx50v3.c
+++ b/board/ge/bx50v3/bx50v3.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include "../common/ge_common.h"
 #include "../common/vpd_reader.h"
 #include "../../../drivers/net/e1000.h"
 DECLARE_GLOBAL_DATA_PTR;
@@ -805,6 +806,8 @@ int board_late_init(void)
/* board specific pmic init */
pmic_init();
 
+   check_time();
+
return 0;
 }
 
diff --git a/configs/ge_b850v3_defconfig b/configs/ge_b850v3_defconfig
index 4f9d77c..b786675 100644
--- a/configs/ge_b850v3_defconfig
+++ b/configs/ge_b850v3_defconfig
@@ -13,6 +13,7 @@ CONFIG_CMD_BOOTZ=y
 # CONFIG_CMD_FPGA is not set
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_I2C=y
+CONFIG_RTC_RX8010SJ=y
 CONFIG_CMD_MMC=y
 CONFIG_CMD_SF=y
 # CONFIG_CMD_NFS is not set
diff --git a/include/configs/ge_bx50v3.h b/include/configs/ge_bx50v3.h
index 90ea030..9d6afdd 100644
--- a/include/configs/ge_bx50v3.h
+++ b/include/configs/ge_bx50v3.h
@@ -123,7 +123,7 @@
"setargs=setenv bootargs root=/dev/${rootdev}${partnum} " \
"ro rootwait cma=128M " \
"bootcause=${bootcause} " \
-   "${quiet} console=${console} " \
+   "${quiet} console=${console} ${rtc_status} " \
BX50V3_BOOTARGS_EXTRA "\0" \
"doquiet=" \
"if ext2load ${dev} ${devnum}:5 0x7000A000 /boot/console; " \
@@ -244,6 +244,10 @@
 #define CONFIG_PCIE_IMX_PERST_GPIO IMX_GPIO_NR(7, 12)
 #define CONFIG_PCIE_IMX_POWER_GPIO IMX_GPIO_NR(1, 5)
 
+#define CONFIG_RTC_RX8010SJ
+#define CONFIG_SYS_RTC_BUS_NUM 2
+#define CONFIG_SYS_I2C_RTC_ADDR0x32
+
 /* I2C Configs */
 #define CONFIG_SYS_I2C
 #define CONFIG_SYS_I2C_MXC
-- 
2.1.4

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


[U-Boot] [PATCH 12/16] config: ge_bx50v3: read boot script

2017-11-08 Thread Martyn Welch
From: Ian Ray 

Read boot script from shared partition, if available.

Signed-off-by: Ian Ray 
Signed-off-by: Martyn Welch 
---
 include/configs/ge_bx50v3.h | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/include/configs/ge_bx50v3.h b/include/configs/ge_bx50v3.h
index 55719dd..ac69e85 100644
--- a/include/configs/ge_bx50v3.h
+++ b/include/configs/ge_bx50v3.h
@@ -133,15 +133,15 @@
 
 #define CONFIG_MMCBOOTCOMMAND \
"setenv dev mmc; " \
-   "setenv rootdev mmcblk0p${partnum}; " \
+   "setenv devnum ${emmcdev}; " \
\
-   "setenv devnum ${sddev}; " \
-   "if mmc dev ${devnum}; then " \
-   "run tryboot; " \
-   "setenv rootdev mmcblk1p${partnum}; " \
+   "if ext2load ${dev} ${devnum}:5 0x7000A000 /boot/active/boot.img ; " \
+   "then " \
+   "source 0x7000A000; " \
"fi; " \
\
-   "setenv devnum ${emmcdev}; " \
+   "setenv rootdev mmcblk0p${partnum}; " \
+   \
"if mmc dev ${devnum}; then " \
"run tryboot; " \
"fi; " \
-- 
2.1.4

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


[U-Boot] [PATCH 02/16] net: e1000: add support for writing to EEPROM

2017-11-08 Thread Martyn Welch
From: Hannu Lounento 

Port functions for writing to EEPROM, updating the checksum and
committing data to flash from the Linux kernel igb driver.

Functions were ported from Linux 4.8-rc2 (694d0d0bb20).

Signed-off-by: Hannu Lounento 
CC: Joe Hershberger 
Signed-off-by: Martyn Welch 
---
 drivers/net/e1000.c | 171 +++-
 drivers/net/e1000.h |   3 +
 2 files changed, 172 insertions(+), 2 deletions(-)

diff --git a/drivers/net/e1000.c b/drivers/net/e1000.c
index 875682b..7aecdb9 100644
--- a/drivers/net/e1000.c
+++ b/drivers/net/e1000.c
@@ -150,6 +150,7 @@ static int32_t e1000_check_phy_reset_block(struct e1000_hw 
*hw);
 
 #ifndef CONFIG_E1000_NO_NVM
 static void e1000_put_hw_eeprom_semaphore(struct e1000_hw *hw);
+static int32_t e1000_get_hw_eeprom_semaphore(struct e1000_hw *hw);
 static int32_t e1000_read_eeprom(struct e1000_hw *hw, uint16_t offset,
uint16_t words,
uint16_t *data);
@@ -862,6 +863,62 @@ e1000_read_eeprom(struct e1000_hw *hw, uint16_t offset,
 }
 
 /**
+ *  e1000_write_eeprom_srwr - Write to Shadow Ram using EEWR
+ *  @hw: pointer to the HW structure
+ *  @offset: offset within the Shadow Ram to be written to
+ *  @words: number of words to write
+ *  @data: 16 bit word(s) to be written to the Shadow Ram
+ *
+ *  Writes data to Shadow Ram at offset using EEWR register.
+ *
+ *  If e1000_update_eeprom_checksum_i210 is not called after this function, the
+ *  Shadow Ram will most likely contain an invalid checksum.
+ */
+static int32_t e1000_write_eeprom_srwr(struct e1000_hw *hw, uint16_t offset,
+  uint16_t words, uint16_t *data)
+{
+   struct e1000_eeprom_info *eeprom = >eeprom;
+   uint32_t i, k, eewr = 0;
+   uint32_t attempts = 10;
+   int32_t ret_val = 0;
+
+   /* A check for invalid values:  offset too large, too many words,
+* too many words for the offset, and not enough words.
+*/
+   if ((offset >= eeprom->word_size) ||
+   (words > (eeprom->word_size - offset)) || (words == 0)) {
+   DEBUGOUT("nvm parameter(s) out of bounds\n");
+   ret_val = -E1000_ERR_EEPROM;
+   goto out;
+   }
+
+   for (i = 0; i < words; i++) {
+   eewr = ((offset + i) << E1000_EEPROM_RW_ADDR_SHIFT)
+   | (data[i] << E1000_EEPROM_RW_REG_DATA) |
+   E1000_EEPROM_RW_REG_START;
+
+   E1000_WRITE_REG(hw, I210_EEWR, eewr);
+
+   for (k = 0; k < attempts; k++) {
+   if (E1000_EEPROM_RW_REG_DONE &
+   E1000_READ_REG(hw, I210_EEWR)) {
+   ret_val = 0;
+   break;
+   }
+   udelay(5);
+   }
+
+   if (ret_val) {
+   DEBUGOUT("Shadow RAM write EEWR timed out\n");
+   break;
+   }
+   }
+
+out:
+   return ret_val;
+}
+
+/**
  * Verifies that the EEPROM has a valid checksum
  *
  * hw - Struct containing variables accessed by shared code
@@ -907,6 +964,116 @@ static int e1000_validate_eeprom_checksum(struct e1000_hw 
*hw)
 
return -E1000_ERR_EEPROM;
 }
+
+/**
+ *  e1000_pool_flash_update_done_i210 - Pool FLUDONE status.
+ *  @hw: pointer to the HW structure
+ *
+ */
+static int32_t e1000_pool_flash_update_done_i210(struct e1000_hw *hw)
+{
+   int32_t ret_val = -E1000_ERR_EEPROM;
+   uint32_t i, reg;
+
+   for (i = 0; i < E1000_FLUDONE_ATTEMPTS; i++) {
+   reg = E1000_READ_REG(hw, EECD);
+   if (reg & E1000_EECD_FLUDONE_I210) {
+   ret_val = 0;
+   break;
+   }
+   udelay(5);
+   }
+
+   return ret_val;
+}
+
+/**
+ *  e1000_update_flash_i210 - Commit EEPROM to the flash
+ *  @hw: pointer to the HW structure
+ *
+ */
+static int32_t e1000_update_flash_i210(struct e1000_hw *hw)
+{
+   int32_t ret_val = 0;
+   uint32_t flup;
+
+   ret_val = e1000_pool_flash_update_done_i210(hw);
+   if (ret_val == -E1000_ERR_EEPROM) {
+   DEBUGOUT("Flash update time out\n");
+   goto out;
+   }
+
+   flup = E1000_READ_REG(hw, EECD) | 

[U-Boot] [PATCH 13/16] configs: ge_bx50v3: enable bootcount

2017-11-08 Thread Martyn Welch
From: Ian Ray 

Enable bootcount using an EXT file.

Signed-off-by: Ian Ray 
Signed-off-by: Martyn Welch 
---
 include/configs/ge_bx50v3.h | 8 
 1 file changed, 8 insertions(+)

diff --git a/include/configs/ge_bx50v3.h b/include/configs/ge_bx50v3.h
index ac69e85..ee5f6ab 100644
--- a/include/configs/ge_bx50v3.h
+++ b/include/configs/ge_bx50v3.h
@@ -112,6 +112,7 @@
 
 #define CONFIG_EXTRA_ENV_SETTINGS \
"script=boot.scr\0" \
+   "bootlimit=10\0" \
"image=/boot/fitImage\0" \
"console=" CONSOLE_DEV "\0" \
"fdt_high=0x\0"   \
@@ -244,4 +245,11 @@
 
 #define CONFIG_BCH
 
+#define CONFIG_BOOTCOUNT_LIMIT
+#define CONFIG_BOOTCOUNT_EXT
+#define CONFIG_SYS_BOOTCOUNT_EXT_INTERFACE "mmc"
+#define CONFIG_SYS_BOOTCOUNT_EXT_DEVPART   "1:5"
+#define CONFIG_SYS_BOOTCOUNT_EXT_NAME  "/boot/failures"
+#define CONFIG_SYS_BOOTCOUNT_ADDR  0x7000A000
+
 #endif /* __GE_BX50V3_CONFIG_H */
-- 
2.1.4

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


[U-Boot] [PATCH 14/16] board: ge: bx50v3: mount rootfs read-only

2017-11-08 Thread Martyn Welch
From: Hannu Lounento 

Change the kernel command line to mount the root filesystem read-only in
order to be able to run filesystem check on it on boot.

Signed-off-by: Hannu Lounento 
Signed-off-by: Martyn Welch 
---
 include/configs/ge_bx50v3.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/configs/ge_bx50v3.h b/include/configs/ge_bx50v3.h
index ee5f6ab..d15470f 100644
--- a/include/configs/ge_bx50v3.h
+++ b/include/configs/ge_bx50v3.h
@@ -120,7 +120,7 @@
"emmcdev=1\0" \
"partnum=1\0" \
"setargs=setenv bootargs console=${console},${baudrate} " \
-   "root=/dev/${rootdev} rw rootwait cma=128M " \
+   "root=/dev/${rootdev} ro rootwait cma=128M " \
BX50V3_BOOTARGS_EXTRA "\0" \
"loadimage=" \
"ext2load ${dev} ${devnum}:${partnum} ${loadaddr} ${image}\0" \
-- 
2.1.4

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


[U-Boot] [PATCH 04/16] net: e1000: implement eth_write_hwaddr

2017-11-08 Thread Martyn Welch
From: Hannu Lounento 

Implement programming MAC address to the hardware, i.e. external flash
seen as EEPROM.

MAC address is only written if it differs from what is already stored in
flash or if reading the current MAC address fails.

Signed-off-by: Hannu Lounento 
CC: Joe Hershberger 
Signed-off-by: Martyn Welch 
---
 drivers/net/e1000.c | 40 
 1 file changed, 40 insertions(+)

diff --git a/drivers/net/e1000.c b/drivers/net/e1000.c
index 9a3e8f8..d0028fc 100644
--- a/drivers/net/e1000.c
+++ b/drivers/net/e1000.c
@@ -5647,6 +5647,45 @@ e1000_poll(struct eth_device *nic)
return len ? 1 : 0;
 }
 
+static int e1000_write_hwaddr(struct eth_device *dev)
+{
+#ifndef CONFIG_E1000_NO_NVM
+   unsigned char *mac = dev->enetaddr;
+   unsigned char current_mac[6];
+   struct e1000_hw *hw = dev->priv;
+   uint16_t data[3];
+   int ret_val, i;
+
+   DEBUGOUT("%s: mac=%pM\n", __func__, mac);
+
+   memset(current_mac, 0, 6);
+
+   /* Read from EEPROM, not from registers, to make sure
+* the address is persistently configured
+*/
+   ret_val = e1000_read_mac_addr_from_eeprom(hw, current_mac);
+   DEBUGOUT("%s: current mac=%pM\n", __func__, current_mac);
+
+   /* Only write to EEPROM if the given address is different or
+* reading the current address failed
+*/
+   if (!ret_val && memcmp(current_mac, mac, 6) == 0)
+   return 0;
+
+   for (i = 0; i < 3; ++i)
+   data[i] = mac[i * 2 + 1] << 8 | mac[i * 2];
+
+   ret_val = e1000_write_eeprom_srwr(hw, 0x0, 3, data);
+
+   if (!ret_val)
+   ret_val = e1000_update_eeprom_checksum_i210(hw);
+
+   return ret_val;
+#else
+   return 0;
+#endif
+}
+
 /**
 PROBE - Look for an adapter, this routine's visible to the outside
 You should omit the last argument struct pci_device * for a non-PCI NIC
@@ -5696,6 +5735,7 @@ e1000_initialize(bd_t * bis)
nic->recv = e1000_poll;
nic->send = e1000_transmit;
nic->halt = e1000_disable;
+   nic->write_hwaddr = e1000_write_hwaddr;
eth_register(nic);
}
 
-- 
2.1.4

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


[U-Boot] [PATCH 10/16] board: ge: bx50v3: Enable hardware watchdog

2017-11-08 Thread Martyn Welch
Enable the hardware watchdog on bx50v3 to cause it to reset in the event
the board hangs.

Configure GPIO_9 pin as WDOG1_B so that a watchdog timeout results in a
full system reset.

The watchdog is used and reconfigured by systemd approximately 1.7 seconds
into boot. Adding a few seconds for U-Boot and a few more seconds as a
safety margin.

Note that the PCIe controller is _not_ put back into a safe state prior
to board reset.  This is a problem if board reset is implemented as CPU
reset.

Signed-off-by: Ian Ray 
Signed-off-by: Martyn Welch 
---
 board/ge/bx50v3/bx50v3.c| 1 +
 include/configs/ge_bx50v3.h | 4 
 2 files changed, 5 insertions(+)

diff --git a/board/ge/bx50v3/bx50v3.c b/board/ge/bx50v3/bx50v3.c
index 07b4298..48c26e0 100644
--- a/board/ge/bx50v3/bx50v3.c
+++ b/board/ge/bx50v3/bx50v3.c
@@ -659,6 +659,7 @@ static iomux_v3_cfg_t const misc_pads[] = {
MX6_PAD_EIM_OE__GPIO2_IO25  | MUX_PAD_CTRL(NC_PAD_CTRL),
MX6_PAD_EIM_BCLK__GPIO6_IO31| MUX_PAD_CTRL(NC_PAD_CTRL),
MX6_PAD_GPIO_1__GPIO1_IO01  | MUX_PAD_CTRL(NC_PAD_CTRL),
+   MX6_PAD_GPIO_9__WDOG1_B | MUX_PAD_CTRL(NC_PAD_CTRL),
 };
 #define SUS_S3_OUT IMX_GPIO_NR(4, 11)
 #define WIFI_ENIMX_GPIO_NR(6, 14)
diff --git a/include/configs/ge_bx50v3.h b/include/configs/ge_bx50v3.h
index 94e406c..162e915 100644
--- a/include/configs/ge_bx50v3.h
+++ b/include/configs/ge_bx50v3.h
@@ -44,6 +44,10 @@
 #define CONFIG_REVISION_TAG
 #define CONFIG_SYS_MALLOC_LEN  (10 * SZ_1M)
 
+#define CONFIG_HW_WATCHDOG
+#define CONFIG_IMX_WATCHDOG
+#define CONFIG_WATCHDOG_TIMEOUT_MSECS 6000
+
 #define CONFIG_LAST_STAGE_INIT
 
 #define CONFIG_MXC_GPIO
-- 
2.1.4

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


[U-Boot] [PATCH 08/16] board: ge: bx50v3: move FEC MAC address programming to driver

2017-11-08 Thread Martyn Welch
Instead of programming the hardware directly in the board
implementation, follow the flow documented in doc/README.enetaddr: set
the enet[0-9]*addr environment variable and let the driver program the
hardware.

This avoids duplicating the implementation as it already exists in the
driver (drivers/net/fec_mxc.c: fec_set_hwaddr).

The mapping from the driver's index to the environment variable's name
is documented in README: Note for Redundant Ethernet Interfaces. It is
assumed that eth_devices for the controllers on the board are always
indexed in the same order, i.e. FEC always has the index 2.

The FEC driver does *not* set the flag Set MAC Address on Transmit (bit
set_eth0_mac_address used to do but this is unnecessary as the Linux
networking stack fills in the MAC address.

Signed-off-by: Hannu Lounento 
Signed-off-by: Ian Ray 
Signed-off-by: Martyn Welch 
---
 board/ge/bx50v3/bx50v3.c| 79 ++---
 include/configs/ge_bx50v3.h |  2 ++
 2 files changed, 41 insertions(+), 40 deletions(-)

diff --git a/board/ge/bx50v3/bx50v3.c b/board/ge/bx50v3/bx50v3.c
index cb4deb0..0468dcf 100644
--- a/board/ge/bx50v3/bx50v3.c
+++ b/board/ge/bx50v3/bx50v3.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -546,63 +547,54 @@ int overwrite_console(void)
 #define VPD_PRODUCT_B850 1
 #define VPD_PRODUCT_B650 2
 #define VPD_PRODUCT_B450 3
+#define VPD_HAS_MAC1 0x1
+#define VPD_MAC_ADDRESS_LENGTH 6
 
 struct vpd_cache {
-   uint8_t product_id;
-   uint8_t macbits;
-   unsigned char mac1[6];
+   u8 product_id;
+   u8 has;
+   unsigned char mac1[VPD_MAC_ADDRESS_LENGTH];
 };
 
 /*
  * Extracts MAC and product information from the VPD.
  */
-static int vpd_callback(
-   void *userdata,
-   uint8_t id,
-   uint8_t version,
-   uint8_t type,
-   size_t size,
-   uint8_t const *data)
+static int vpd_callback(void *userdata, u8 id, u8 version, u8 type,
+   size_t size, u8 const *data)
 {
struct vpd_cache *vpd = (struct vpd_cache *)userdata;
 
-   if (   id == VPD_BLOCK_HWID
-   && version == 1
-   && type != VPD_TYPE_INVALID
-   && size >= 1) {
+   if (id == VPD_BLOCK_HWID && version == 1 && type != VPD_TYPE_INVALID &&
+   size >= 1) {
vpd->product_id = data[0];
-
-   } else if (   id == VPD_BLOCK_NETWORK
-  && version == 1
-  && type != VPD_TYPE_INVALID
-  && size >= 6) {
-   vpd->macbits |= 1;
-   memcpy(vpd->mac1, data, 6);
+   } else if (id == VPD_BLOCK_NETWORK && version == 1 &&
+  type != VPD_TYPE_INVALID) {
+   if (size >= 6) {
+   vpd->has |= VPD_HAS_MAC1;
+   memcpy(vpd->mac1, data, VPD_MAC_ADDRESS_LENGTH);
+   }
}
 
return 0;
 }
 
-static void set_eth0_mac_address(unsigned char * mac)
-{
-   uint32_t *ENET_TCR = (uint32_t*)0x21880c4;
-   uint32_t *ENET_PALR = (uint32_t*)0x21880e4;
-   uint32_t *ENET_PAUR = (uint32_t*)0x21880e8;
-
-   *ENET_TCR |= 0x100;  /* ADDINS */
-   *ENET_PALR |= (mac[0] << 24) | (mac[1] << 16) | (mac[2] << 8) | mac[3];
-   *ENET_PAUR |= (mac[4] << 24) | (mac[5] << 16);
-}
-
 static void process_vpd(struct vpd_cache *vpd)
 {
-   if (   vpd->product_id == VPD_PRODUCT_B850
-   || vpd->product_id == VPD_PRODUCT_B650
-   || vpd->product_id == VPD_PRODUCT_B450) {
-   if (vpd->macbits & 1) {
-   set_eth0_mac_address(vpd->mac1);
-   }
+   int fec_index = -1;
+
+   switch (vpd->product_id) {
+   case VPD_PRODUCT_B450:
+   /* fall thru */
+   case VPD_PRODUCT_B650:
+   fec_index = 1;
+   break;
+   case VPD_PRODUCT_B850:
+   fec_index = 2;
+   break;
}
+
+   if (fec_index >= 0 && (vpd->has & VPD_HAS_MAC1))
+   eth_env_set_enetaddr_by_index("eth", fec_index, vpd->mac1);
 }
 
 static int read_vpd(uint eeprom_bus)
@@ -694,8 +686,6 @@ int board_init(void)
setup_i2c(2, CONFIG_SYS_I2C_SPEED, 0x7f, _pad_info2);
setup_i2c(3, CONFIG_SYS_I2C_SPEED, 0x7f, _pad_info3);
 
-   read_vpd(CONFIG_SYS_I2C_EEPROM_BUS);
-
return 0;
 }
 
@@ -761,6 +751,8 @@ void pmic_init(void)
 
 int board_late_init(void)
 {
+   read_vpd(CONFIG_SYS_I2C_EEPROM_BUS);
+
 #ifdef CONFIG_CMD_BMODE
add_board_boot_modes(board_boot_modes);
 #endif
@@ -788,6 +780,13 @@ int board_late_init(void)
return 0;
 }
 
+int last_stage_init(void)
+{
+   env_set("ethaddr", NULL);
+
+   return 0;
+}
+
 int checkboard(void)
 {
printf("BOARD: %s\n", CONFIG_BOARD_NAME);
diff --git a/include/configs/ge_bx50v3.h b/include/configs/ge_bx50v3.h
index 4526d2f..94e406c 

[U-Boot] [PATCH 09/16] board: ge: bx50v3: program MAC address to I210

2017-11-08 Thread Martyn Welch
From: Hannu Lounento 

There are two I210s on the b850v3 and one on the b450v3 and b650v3.
One is connected to Marvell 88e6240 which is already programmed.

Follow the flow documented in doc/README.enetaddr: set the
enet[0-9]*addr environment variable and let the driver program the
hardware.

The mapping from the driver's index to the environment variable's name
is documented in README: Note for Redundant Ethernet Interfaces. It is
assumed that eth_devices for the controllers on the board are always
indexed in the same order.

The environment variables are removed after programming the hardware
because the variables seem to influence MAC addresses also after U-Boot.
Specifically the MAC address of FEC (MC interface) would be incorrectly
set: 'ethaddr', which maps to the first I210 chip and is set to I210's
default address read from the driver by eth_write_hwaddr in eth_legacy.c
because the variable is undefined (not set even by bx50v3.c), would
result in the eth0 interface's MAC address to be set to I210's default
address.

Signed-off-by: Hannu Lounento 
Signed-off-by: Ian Ray 
Signed-off-by: Martyn Welch 
---
 board/ge/bx50v3/bx50v3.c | 37 -
 1 file changed, 36 insertions(+), 1 deletion(-)

diff --git a/board/ge/bx50v3/bx50v3.c b/board/ge/bx50v3/bx50v3.c
index 0468dcf..07b4298 100644
--- a/board/ge/bx50v3/bx50v3.c
+++ b/board/ge/bx50v3/bx50v3.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include "../common/vpd_reader.h"
+#include "../../../drivers/net/e1000.h"
 DECLARE_GLOBAL_DATA_PTR;
 
 #ifndef CONFIG_SYS_I2C_EEPROM_ADDR
@@ -548,12 +549,14 @@ int overwrite_console(void)
 #define VPD_PRODUCT_B650 2
 #define VPD_PRODUCT_B450 3
 #define VPD_HAS_MAC1 0x1
+#define VPD_HAS_MAC2 0x2
 #define VPD_MAC_ADDRESS_LENGTH 6
 
 struct vpd_cache {
u8 product_id;
u8 has;
unsigned char mac1[VPD_MAC_ADDRESS_LENGTH];
+   unsigned char mac2[VPD_MAC_ADDRESS_LENGTH];
 };
 
 /*
@@ -573,6 +576,10 @@ static int vpd_callback(void *userdata, u8 id, u8 version, 
u8 type,
vpd->has |= VPD_HAS_MAC1;
memcpy(vpd->mac1, data, VPD_MAC_ADDRESS_LENGTH);
}
+   if (size >= 12) {
+   vpd->has |= VPD_HAS_MAC2;
+   memcpy(vpd->mac2, data + 6, VPD_MAC_ADDRESS_LENGTH);
+   }
}
 
return 0;
@@ -581,20 +588,26 @@ static int vpd_callback(void *userdata, u8 id, u8 
version, u8 type,
 static void process_vpd(struct vpd_cache *vpd)
 {
int fec_index = -1;
+   int i210_index = -1;
 
switch (vpd->product_id) {
case VPD_PRODUCT_B450:
/* fall thru */
case VPD_PRODUCT_B650:
+   i210_index = 0;
fec_index = 1;
break;
case VPD_PRODUCT_B850:
+   i210_index = 1;
fec_index = 2;
break;
}
 
if (fec_index >= 0 && (vpd->has & VPD_HAS_MAC1))
eth_env_set_enetaddr_by_index("eth", fec_index, vpd->mac1);
+
+   if (i210_index >= 0 && (vpd->has & VPD_HAS_MAC2))
+   eth_env_set_enetaddr_by_index("eth", i210_index, vpd->mac2);
 }
 
 static int read_vpd(uint eeprom_bus)
@@ -633,6 +646,8 @@ int board_eth_init(bd_t *bis)
setup_iomux_enet();
setup_pcie();
 
+   e1000_initialize(bis);
+
return cpu_eth_init(bis);
 }
 
@@ -780,9 +795,29 @@ int board_late_init(void)
return 0;
 }
 
+/*
+ * Removes the 'eth[0-9]*addr' environment variable with the given index
+ *
+ * @param index [in] the index of the eth_device whose variable is to be 
removed
+ */
+static void remove_ethaddr_env_var(int index)
+{
+   char env_var_name[9];
+
+   sprintf(env_var_name, index == 0 ? "ethaddr" : "eth%daddr", index);
+   env_set(env_var_name, NULL);
+}
+
 int last_stage_init(void)
 {
-   env_set("ethaddr", NULL);
+   int i;
+
+   /*
+* Remove first three ethaddr which may have been created by
+* function process_vpd().
+*/
+   for (i = 0; i < 3; ++i)
+   remove_ethaddr_env_var(i);
 
return 0;
 }
-- 
2.1.4

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


[U-Boot] [PATCH 11/16] board: ge: bx50v3: Support FIT and select configuration based on VPD

2017-11-08 Thread Martyn Welch
From: Ian Ray 

Modify configuration to support FIT. Set variable `confidx' from VPD,
in order to load the correct device tree. Modify/simplify U-Boot
environment to support loading FIT image.

Signed-off-by: Ian Ray 
Signed-off-by: Martyn Welch 
---
 board/ge/bx50v3/bx50v3.c| 12 +++
 configs/ge_b450v3_defconfig |  1 +
 configs/ge_b650v3_defconfig |  1 +
 configs/ge_b850v3_defconfig |  1 +
 include/configs/ge_bx50v3.h | 88 +++--
 5 files changed, 20 insertions(+), 83 deletions(-)

diff --git a/board/ge/bx50v3/bx50v3.c b/board/ge/bx50v3/bx50v3.c
index 48c26e0..e35afa03 100644
--- a/board/ge/bx50v3/bx50v3.c
+++ b/board/ge/bx50v3/bx50v3.c
@@ -592,6 +592,18 @@ static void process_vpd(struct vpd_cache *vpd)
 
switch (vpd->product_id) {
case VPD_PRODUCT_B450:
+   env_set("confidx", "1");
+   break;
+   case VPD_PRODUCT_B650:
+   env_set("confidx", "2");
+   break;
+   case VPD_PRODUCT_B850:
+   env_set("confidx", "3");
+   break;
+   }
+
+   switch (vpd->product_id) {
+   case VPD_PRODUCT_B450:
/* fall thru */
case VPD_PRODUCT_B650:
i210_index = 0;
diff --git a/configs/ge_b450v3_defconfig b/configs/ge_b450v3_defconfig
index f95c3cd..76cc407 100644
--- a/configs/ge_b450v3_defconfig
+++ b/configs/ge_b450v3_defconfig
@@ -32,3 +32,4 @@ CONFIG_CMD_NET=y
 CONFIG_CMD_PCI=y
 CONFIG_E1000=y
 CONFIG_CMD_E1000=y
+CONFIG_FIT=y
diff --git a/configs/ge_b650v3_defconfig b/configs/ge_b650v3_defconfig
index 3af0630..e82abe2 100644
--- a/configs/ge_b650v3_defconfig
+++ b/configs/ge_b650v3_defconfig
@@ -32,3 +32,4 @@ CONFIG_CMD_NET=y
 CONFIG_CMD_PCI=y
 CONFIG_E1000=y
 CONFIG_CMD_E1000=y
+CONFIG_FIT=y
diff --git a/configs/ge_b850v3_defconfig b/configs/ge_b850v3_defconfig
index 5f008ea..4f9d77c 100644
--- a/configs/ge_b850v3_defconfig
+++ b/configs/ge_b850v3_defconfig
@@ -32,3 +32,4 @@ CONFIG_CMD_NET=y
 CONFIG_CMD_PCI=y
 CONFIG_E1000=y
 CONFIG_CMD_E1000=y
+CONFIG_FIT=y
diff --git a/include/configs/ge_bx50v3.h b/include/configs/ge_bx50v3.h
index 162e915..55719dd 100644
--- a/include/configs/ge_bx50v3.h
+++ b/include/configs/ge_bx50v3.h
@@ -112,95 +112,24 @@
 
 #define CONFIG_EXTRA_ENV_SETTINGS \
"script=boot.scr\0" \
-   "image=/boot/uImage\0" \
-   "uboot=u-boot.imx\0" \
-   "fdt_file=" CONFIG_DEFAULT_FDT_FILE "\0" \
-   "fdt_addr=0x1800\0" \
-   "boot_fdt=yes\0" \
-   "ip_dyn=yes\0" \
+   "image=/boot/fitImage\0" \
"console=" CONSOLE_DEV "\0" \
"fdt_high=0x\0"   \
-   "initrd_high=0x\0" \
"sddev=0\0" \
"emmcdev=1\0" \
"partnum=1\0" \
-   "update_sd_firmware=" \
-   "if test ${ip_dyn} = yes; then " \
-   "setenv get_cmd dhcp; " \
-   "else " \
-   "setenv get_cmd tftp; " \
-   "fi; " \
-   "if mmc dev ${mmcdev}; then "   \
-   "if ${get_cmd} ${update_sd_firmware_filename}; then " \
-   "setexpr fw_sz ${filesize} / 0x200; " \
-   "setexpr fw_sz ${fw_sz} + 1; "  \
-   "mmc write ${loadaddr} 0x2 ${fw_sz}; " \
-   "fi; "  \
-   "fi\0" \
-   "update_sf_uboot=" \
-   "if tftp $loadaddr $uboot; then " \
-   "sf probe; " \
-   "sf erase 0 0xC; " \
-   "sf write $loadaddr 0x400 $filesize; " \
-   "echo 'U-Boot upgraded. Please reset'; " \
-   "fi\0" \
"setargs=setenv bootargs console=${console},${baudrate} " \
"root=/dev/${rootdev} rw rootwait cma=128M " \
BX50V3_BOOTARGS_EXTRA "\0" \
-   "loadbootscript=" \
-   "ext2load ${dev} ${devnum}:${partnum} ${loadaddr} ${script};\0" 
\
-   "bootscript=echo Running bootscript from ${dev}:${devnum}:${partnum};" \
-   " source\0" \
"loadimage=" \
"ext2load ${dev} ${devnum}:${partnum} ${loadaddr} ${image}\0" \
-   "loadfdt=ext2load ${dev} ${devnum}:${partnum} ${fdt_addr} 
${fdt_file}\0" \
"tryboot=" \
-   "if run loadbootscript; then " \
-   "run bootscript; " \
-   "else " \
-   "if run loadimage; then " \
-   "run doboot; " \
-   "fi; " \
+   "if run loadimage; then " \
+   "run doboot; " \
"fi;\0" \
"doboot=echo Booting from ${dev}:${devnum}:${partnum} ...; " \
"run setargs; " \
-   "if test ${boot_fdt} = yes || test ${boot_fdt} = try; then " \
-   "if run loadfdt; then " \
-   

[U-Boot] [PATCH 06/16] board: ge: Enable access to i2c bus 1 and 2

2017-11-08 Thread Martyn Welch
The change in i2c configuration added to support access to the VPD has
inadvertantly caused access to i2c buses 1 & 2 to be lost. This has
resulted in the configuration for the PMIC to be attempted on the wrong
bus and thus isn't taking effect.

Add the required configuration to return access to buses 1 & 2. In order
to ensure that any users of the bus numbering prior to addition in VPD
patches work, add buses before configuration related to mux on bus 0 and
tweak VPD bus usage to fit new numbering scheme.

Signed-off-by: Martyn Welch 
---
 board/ge/bx50v3/bx50v3.c| 2 +-
 include/configs/ge_bx50v3.h | 4 +++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/board/ge/bx50v3/bx50v3.c b/board/ge/bx50v3/bx50v3.c
index 37de990..cb4deb0 100644
--- a/board/ge/bx50v3/bx50v3.c
+++ b/board/ge/bx50v3/bx50v3.c
@@ -37,7 +37,7 @@ DECLARE_GLOBAL_DATA_PTR;
 #endif
 
 #ifndef CONFIG_SYS_I2C_EEPROM_BUS
-#define CONFIG_SYS_I2C_EEPROM_BUS   2
+#define CONFIG_SYS_I2C_EEPROM_BUS   4
 #endif
 
 #define NC_PAD_CTRL (PAD_CTL_PUS_100K_UP | \
diff --git a/include/configs/ge_bx50v3.h b/include/configs/ge_bx50v3.h
index 33f5101..eb8f923 100644
--- a/include/configs/ge_bx50v3.h
+++ b/include/configs/ge_bx50v3.h
@@ -299,9 +299,11 @@
 #define CONFIG_SYS_I2C_MXC_I2C2
 #define CONFIG_SYS_I2C_MXC_I2C3
 
-#define CONFIG_SYS_NUM_I2C_BUSES9
+#define CONFIG_SYS_NUM_I2C_BUSES11
 #define CONFIG_SYS_I2C_MAX_HOPS 1
 #define CONFIG_SYS_I2C_BUSES   {   {0, {I2C_NULL_HOP} }, \
+   {1, {I2C_NULL_HOP} }, \
+   {2, {I2C_NULL_HOP} }, \
{0, {{I2C_MUX_PCA9547, 0x70, 0} } }, \
{0, {{I2C_MUX_PCA9547, 0x70, 1} } }, \
{0, {{I2C_MUX_PCA9547, 0x70, 2} } }, \
-- 
2.1.4

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


[U-Boot] [PATCH 07/16] configs: Add network device support for bx50v3 products

2017-11-08 Thread Martyn Welch
From: Ian Ray 

Modify b450v3, b650v3 and b850v3 defconfigs to enable the network devices
found in these products.

Signed-off-by: Ian Ray 
Signed-off-by: Martyn Welch 
---
 configs/ge_b450v3_defconfig | 6 +-
 configs/ge_b650v3_defconfig | 6 +-
 configs/ge_b850v3_defconfig | 6 +-
 include/configs/ge_bx50v3.h | 4 ++--
 4 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/configs/ge_b450v3_defconfig b/configs/ge_b450v3_defconfig
index 43a6c12..f95c3cd 100644
--- a/configs/ge_b450v3_defconfig
+++ b/configs/ge_b450v3_defconfig
@@ -15,7 +15,6 @@ CONFIG_CMD_GPIO=y
 CONFIG_CMD_I2C=y
 CONFIG_CMD_MMC=y
 CONFIG_CMD_SF=y
-# CONFIG_CMD_NET is not set
 # CONFIG_CMD_NFS is not set
 CONFIG_CMD_CACHE=y
 CONFIG_CMD_EXT2=y
@@ -28,3 +27,8 @@ CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_OF_LIBFDT=y
 # CONFIG_EFI_LOADER is not set
+CONFIG_NETDEVICES=y
+CONFIG_CMD_NET=y
+CONFIG_CMD_PCI=y
+CONFIG_E1000=y
+CONFIG_CMD_E1000=y
diff --git a/configs/ge_b650v3_defconfig b/configs/ge_b650v3_defconfig
index 4e22e95..3af0630 100644
--- a/configs/ge_b650v3_defconfig
+++ b/configs/ge_b650v3_defconfig
@@ -15,7 +15,6 @@ CONFIG_CMD_GPIO=y
 CONFIG_CMD_I2C=y
 CONFIG_CMD_MMC=y
 CONFIG_CMD_SF=y
-# CONFIG_CMD_NET is not set
 # CONFIG_CMD_NFS is not set
 CONFIG_CMD_CACHE=y
 CONFIG_CMD_EXT2=y
@@ -28,3 +27,8 @@ CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_OF_LIBFDT=y
 # CONFIG_EFI_LOADER is not set
+CONFIG_NETDEVICES=y
+CONFIG_CMD_NET=y
+CONFIG_CMD_PCI=y
+CONFIG_E1000=y
+CONFIG_CMD_E1000=y
diff --git a/configs/ge_b850v3_defconfig b/configs/ge_b850v3_defconfig
index cb5899d..5f008ea 100644
--- a/configs/ge_b850v3_defconfig
+++ b/configs/ge_b850v3_defconfig
@@ -15,7 +15,6 @@ CONFIG_CMD_GPIO=y
 CONFIG_CMD_I2C=y
 CONFIG_CMD_MMC=y
 CONFIG_CMD_SF=y
-# CONFIG_CMD_NET is not set
 # CONFIG_CMD_NFS is not set
 CONFIG_CMD_CACHE=y
 CONFIG_CMD_EXT2=y
@@ -28,3 +27,8 @@ CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_OF_LIBFDT=y
 # CONFIG_EFI_LOADER is not set
+CONFIG_NETDEVICES=y
+CONFIG_CMD_NET=y
+CONFIG_CMD_PCI=y
+CONFIG_E1000=y
+CONFIG_CMD_E1000=y
diff --git a/include/configs/ge_bx50v3.h b/include/configs/ge_bx50v3.h
index eb8f923..4526d2f 100644
--- a/include/configs/ge_bx50v3.h
+++ b/include/configs/ge_bx50v3.h
@@ -284,12 +284,12 @@
 #define CONFIG_PWM_IMX
 #define CONFIG_IMX6_PWM_PER_CLK6600
 
-#ifdef CONFIG_CMD_PCI
+#define CONFIG_PCI
+#define CONFIG_PCI_PNP
 #define CONFIG_PCI_SCAN_SHOW
 #define CONFIG_PCIE_IMX
 #define CONFIG_PCIE_IMX_PERST_GPIO IMX_GPIO_NR(7, 12)
 #define CONFIG_PCIE_IMX_POWER_GPIO IMX_GPIO_NR(1, 5)
-#endif
 
 /* I2C Configs */
 #define CONFIG_SYS_I2C
-- 
2.1.4

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


[U-Boot] [PATCH 01/16] board: ge: mx53ppd: Move check_time() to common location

2017-11-08 Thread Martyn Welch
We are going to be using check_time() on more than the mx53ppd, move this
function to a common location.

Signed-off-by: Martyn Welch 
---
 board/ge/common/Makefile|  2 +-
 board/ge/common/ge_common.c | 55 +
 board/ge/common/ge_common.h |  7 ++
 board/ge/mx53ppd/mx53ppd.c  | 47 +-
 4 files changed, 64 insertions(+), 47 deletions(-)
 create mode 100644 board/ge/common/ge_common.c
 create mode 100644 board/ge/common/ge_common.h

diff --git a/board/ge/common/Makefile b/board/ge/common/Makefile
index 93e6c01..f5be11b 100644
--- a/board/ge/common/Makefile
+++ b/board/ge/common/Makefile
@@ -4,4 +4,4 @@
 # SPDX-License-Identifier: GPL-2.0+
 #
 
-obj-y  := vpd_reader.o
+obj-y  := vpd_reader.o ge_common.o
diff --git a/board/ge/common/ge_common.c b/board/ge/common/ge_common.c
new file mode 100644
index 000..c826096
--- /dev/null
+++ b/board/ge/common/ge_common.c
@@ -0,0 +1,55 @@
+/*
+ * Copyright 2017 General Electric Company
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+
+void check_time(void)
+{
+   int ret, i;
+   struct rtc_time tm;
+   u8 retry = 3;
+
+   unsigned int current_i2c_bus = i2c_get_bus_num();
+
+   ret = i2c_set_bus_num(CONFIG_SYS_RTC_BUS_NUM);
+   if (ret < 0)
+   return;
+
+   rtc_init();
+
+   for (i = 0; i < retry; i++) {
+   ret = rtc_get();
+   if (!ret || ret == -EINVAL)
+   break;
+   }
+
+   if (ret < 0)
+   env_set("rtc_status", "RTC_ERROR");
+
+   if (tm.tm_year > 2037) {
+   tm.tm_sec  = 0;
+   tm.tm_min  = 0;
+   tm.tm_hour = 0;
+   tm.tm_mday = 1;
+   tm.tm_wday = 2;
+   tm.tm_mon  = 1;
+   tm.tm_year = 2036;
+
+   for (i = 0; i < retry; i++) {
+   ret = rtc_set();
+   if (!ret)
+   break;
+   }
+
+   if (ret < 0)
+   env_set("rtc_status", "RTC_ERROR");
+   }
+
+   i2c_set_bus_num(current_i2c_bus);
+}
+
diff --git a/board/ge/common/ge_common.h b/board/ge/common/ge_common.h
new file mode 100644
index 000..b28aada
--- /dev/null
+++ b/board/ge/common/ge_common.h
@@ -0,0 +1,7 @@
+/*
+ * Copyright 2017 General Electric Company
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+void check_time(void);
diff --git a/board/ge/mx53ppd/mx53ppd.c b/board/ge/mx53ppd/mx53ppd.c
index 6a8a29d..90dbccc 100644
--- a/board/ge/mx53ppd/mx53ppd.c
+++ b/board/ge/mx53ppd/mx53ppd.c
@@ -33,8 +33,8 @@
 #include 
 #include "ppd_gpio.h"
 #include 
+#include "../../ge/common/ge_common.h"
 #include "../../ge/common/vpd_reader.h"
-#include 
 
 #define MX53PPD_LCD_POWER  IMX_GPIO_NR(3, 24)
 
@@ -357,51 +357,6 @@ static int read_vpd(uint eeprom_bus)
return res;
 }
 
-static void check_time(void)
-{
-   int ret, i;
-   struct rtc_time tm;
-   u8 retry = 3;
-
-   unsigned int current_i2c_bus = i2c_get_bus_num();
-
-   ret = i2c_set_bus_num(CONFIG_SYS_RTC_BUS_NUM);
-   if (ret < 0)
-   return;
-
-   rtc_init();
-
-   for (i = 0; i < retry; i++) {
-   ret = rtc_get();
-   if (!ret || ret == -EINVAL)
-   break;
-   }
-
-   if (ret < 0)
-   env_set("rtc_status", "RTC_ERROR");
-
-   if (tm.tm_year > 2037) {
-   tm.tm_sec  = 0;
-   tm.tm_min  = 0;
-   tm.tm_hour = 0;
-   tm.tm_mday = 1;
-   tm.tm_wday = 2;
-   tm.tm_mon  = 1;
-   tm.tm_year = 2036;
-
-   for (i = 0; i < retry; i++) {
-   ret = rtc_set();
-   if (!ret)
-   break;
-   }
-
-   if (ret < 0)
-   env_set("rtc_status", "RTC_ERROR");
-   }
-
-   i2c_set_bus_num(current_i2c_bus);
-}
-
 int board_init(void)
 {
gd->bd->bi_boot_params = PHYS_SDRAM_1 + 0x100;
-- 
2.1.4

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


[U-Boot] [PATCH 00/16] Updates / improvements to bx50v3 support

2017-11-08 Thread Martyn Welch
This series improves the support on the bx50v3 devices (b540v3, b650v3 and
b850v3) and utilising features recently added as part of the PPD 
implementation.

NOTE: This series requires the PPD series:
https://lists.denx.de/pipermail/u-boot/2017-November/310865.html

Changes outside of the bx50v3/ppd specifc areas:

 - Added driver for RX8010SJ RTC.
 - Added functionality to e1000 driver to enable wrting of EEPROM/MAC
   address.

Hannu Lounento (5):
  net: e1000: add support for writing to EEPROM
  net: e1000: split e1000_read_mac_addr
  net: e1000: implement eth_write_hwaddr
  board: ge: bx50v3: program MAC address to I210
  board: ge: bx50v3: mount rootfs read-only

Ian Ray (5):
  configs: Add network device support for bx50v3 products
  board: ge: bx50v3: Support FIT and select configuration based on VPD
  config: ge_bx50v3: read boot script
  configs: ge_bx50v3: enable bootcount
  configs: ge_bx50v3: automatic partition selection and video output
failure message

Martyn Welch (4):
  board: ge: mx53ppd: Move check_time() to common location
  board: ge: Enable access to i2c bus 1 and 2
  board: ge: bx50v3: move FEC MAC address programming to driver
  board: ge: bx50v3: Enable hardware watchdog

Nandor Han (2):
  rtc: adding RX8010SJ rtc driver
  board,ge,bx50v3 - rtc time validation

 board/ge/bx50v3/bx50v3.c| 130 ++-
 board/ge/common/Makefile|   2 +-
 board/ge/common/ge_common.c |  55 +++
 board/ge/common/ge_common.h |   7 +
 board/ge/mx53ppd/mx53ppd.c  |  47 +-
 configs/ge_b450v3_defconfig |   7 +-
 configs/ge_b650v3_defconfig |   7 +-
 configs/ge_b850v3_defconfig |   8 +-
 drivers/net/e1000.c | 292 +++---
 drivers/net/e1000.h |   3 +
 drivers/rtc/Kconfig |   6 +
 drivers/rtc/Makefile|   1 +
 drivers/rtc/rx8010sj.c  | 378 
 include/configs/ge_bx50v3.h | 190 +-
 14 files changed, 911 insertions(+), 222 deletions(-)
 create mode 100644 board/ge/common/ge_common.c
 create mode 100644 board/ge/common/ge_common.h
 create mode 100644 drivers/rtc/rx8010sj.c

-- 
2.1.4

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


Re: [U-Boot] [PATCH 12/13] efi_loader: manage protocols in a linked list

2017-11-08 Thread Alexander Graf

On 11/01/2017 09:31 AM, Heinrich Schuchardt wrote:

Signed-off-by: Heinrich Schuchardt 
---
  include/efi_loader.h  |   6 ++-
  lib/efi_loader/efi_boottime.c | 107 --
  lib/efi_loader/efi_disk.c |   1 +
  lib/efi_loader/efi_gop.c  |   1 +
  lib/efi_loader/efi_net.c  |   1 +
  5 files changed, 58 insertions(+), 58 deletions(-)

diff --git a/include/efi_loader.h b/include/efi_loader.h
index e1f0af3496..a73bbc1269 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -101,6 +101,8 @@ extern unsigned int __efi_runtime_rel_start, 
__efi_runtime_rel_stop;
   * interface (usually a struct with callback functions), this struct maps the
   * protocol GUID to the respective protocol interface */
  struct efi_handler {
+   /* Link to the list of protocols of a handle */
+   struct list_head link;
const efi_guid_t *guid;
void *protocol_interface;
  };
@@ -115,8 +117,8 @@ struct efi_handler {
  struct efi_object {
/* Every UEFI object is part of a global object list */
struct list_head link;
-   /* We support up to 16 "protocols" an object can be accessed through */
-   struct efi_handler protocols[16];
+   /* The list of protocols */
+   struct list_head protocols;
/* The object spawner can either use this for data or as identifier */
void *handle;
  };
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index 2b3db162a1..cee0cb1390 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -339,6 +339,7 @@ efi_status_t efi_create_handle(void **handle)
return r;
memset(obj, 0, sizeof(struct efi_object));
obj->handle = obj;
+   INIT_LIST_HEAD(>protocols);
list_add_tail(>link, _obj_list);
*handle = obj;
return r;
@@ -715,18 +716,17 @@ efi_status_t efi_search_protocol(const void *handle,
 struct efi_handler **handler)
  {
struct efi_object *efiobj;
-   size_t i;
-   struct efi_handler *protocol;
+   struct list_head *lhandle;
  
  	if (!handle || !protocol_guid)

return EFI_INVALID_PARAMETER;
efiobj = efi_search_obj(handle);
if (!efiobj)
return EFI_INVALID_PARAMETER;
-   for (i = 0; i < ARRAY_SIZE(efiobj->protocols); i++) {
-   protocol = >protocols[i];
-   if (!protocol->guid)
-   continue;
+   list_for_each(lhandle, >protocols) {
+   struct efi_handler *protocol;
+
+   protocol = list_entry(lhandle, struct efi_handler, link);
if (!guidcmp(protocol->guid, protocol_guid)) {
if (handler)
*handler = protocol;
@@ -750,7 +750,6 @@ efi_status_t efi_add_protocol(const void *handle, const 
efi_guid_t *protocol,
struct efi_object *efiobj;
struct efi_handler *handler;
efi_status_t ret;
-   size_t i;
  
  	efiobj = efi_search_obj(handle);

if (!efiobj)
@@ -761,16 +760,10 @@ efi_status_t efi_add_protocol(const void *handle, const 
efi_guid_t *protocol,
handler = calloc(1, sizeof(struct efi_handler));
if (!handler)
return EFI_OUT_OF_RESOURCES;
-   /* Install protocol in first empty slot. */
-   for (i = 0; i < ARRAY_SIZE(efiobj->protocols); i++) {
-   handler = >protocols[i];
-   if (handler->guid)
-   continue;
-   handler->guid = protocol;
-   handler->protocol_interface = protocol_interface;
-   return EFI_SUCCESS;
-   }
-   return EFI_OUT_OF_RESOURCES;
+   handler->guid = protocol;
+   handler->protocol_interface = protocol_interface;
+   list_add_tail(>link, >protocols);
+   return EFI_SUCCESS;
  }
  
  /*

@@ -790,10 +783,10 @@ efi_status_t efi_remove_protocol(const void *handle, 
const efi_guid_t *protocol,
ret = efi_search_protocol(handle, protocol, );
if (ret != EFI_SUCCESS)
return ret;
-   if (handler->protocol_interface != protocol_interface)
-   return EFI_NOT_FOUND;
-   handler->guid = NULL;
-   handler->protocol_interface = NULL;
+   if (guidcmp(handler->guid, protocol))
+   return EFI_INVALID_PARAMETER;
+   list_del(>link);
+   free(handler);
return EFI_SUCCESS;
  }
  
@@ -806,17 +799,22 @@ efi_status_t efi_remove_protocol(const void *handle, const efi_guid_t *protocol,

  efi_status_t efi_remove_all_protocols(const void *handle)
  {
struct efi_object *efiobj;
-   struct efi_handler *handler;
-   size_t i;
+   struct list_head *lhandle;
+   struct list_head *pos;
  
  	efiobj = efi_search_obj(handle);

if (!efiobj)
return EFI_INVALID_PARAMETER;
+   list_for_each_safe(lhandle, pos, >protocols) {
+ 

[U-Boot] [PATCH v5 6/8] rtc: add support for s35392a

2017-11-08 Thread Martyn Welch
From: Nandor Han 

Add support for S35392A RTC. The driver supports both U-Boot driver
models.

Signed-off-by: Nandor Han 
Signed-off-by: Martyn Welch 
Cc: Heiko Schocher 
---

Changes for v5:
   - Fixed checkpatch issues.

 drivers/rtc/Kconfig   |   6 +
 drivers/rtc/Makefile  |   1 +
 drivers/rtc/s35392a.c | 365 ++
 lib/Kconfig   |   3 +
 4 files changed, 375 insertions(+)
 create mode 100644 drivers/rtc/s35392a.c

diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index d06130c7..2964bb2 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -30,4 +30,10 @@ config RTC_DS1307
  Support for Dallas Semiconductor (now Maxim) DS1307 and DS1338/9 and
  compatible Real Time Clock devices.
 
+config RTC_S35392A
+   bool "Enable S35392A driver"
+   select BITREVERSE
+   help
+ Enable s35392a driver which provides rtc get and set function.
+
 endmenu
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 003e31a..7a8f97a 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -49,5 +49,6 @@ obj-$(CONFIG_RTC_RS5C372A) += rs5c372.o
 obj-$(CONFIG_RTC_RV3029) += rv3029.o
 obj-$(CONFIG_RTC_RX8025) += rx8025.o
 obj-$(CONFIG_RTC_S3C24X0) += s3c24x0_rtc.o
+obj-$(CONFIG_RTC_S35392A) += s35392a.o
 obj-$(CONFIG_SANDBOX) += sandbox_rtc.o
 obj-$(CONFIG_RTC_X1205) += x1205.o
diff --git a/drivers/rtc/s35392a.c b/drivers/rtc/s35392a.c
new file mode 100644
index 000..9adcefc
--- /dev/null
+++ b/drivers/rtc/s35392a.c
@@ -0,0 +1,365 @@
+/*
+ * SII Semiconductor Corporation S35392A RTC driver.
+ *
+ * Copyright (c) 2017, General Electric Company
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ *
+ * SPDX-License-Identifier:GPL-2.0
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define S35390A_CMD_STATUS10x30
+#define S35390A_CMD_STATUS20x31
+#define S35390A_CMD_TIME1  0x32
+#define S35390A_CMD_TIME2  0x33
+#define S35390A_CMD_INT2_REG1  0x35
+
+#define S35390A_BYTE_YEAR  0
+#define S35390A_BYTE_MONTH 1
+#define S35390A_BYTE_DAY   2
+#define S35390A_BYTE_WDAY  3
+#define S35390A_BYTE_HOURS 4
+#define S35390A_BYTE_MINS  5
+#define S35390A_BYTE_SECS  6
+
+/* flags for STATUS1 */
+#define S35390A_FLAG_POC   0x01
+#define S35390A_FLAG_BLD   0x02
+#define S35390A_FLAG_INT2  0x04
+#define S35390A_FLAG_24H   0x40
+#define S35390A_FLAG_RESET 0x80
+
+/*
+ * If either BLD or POC is set, then the chip has lost power long enough for
+ * the time value to become invalid.
+ */
+#define S35390A_LOW_VOLTAGE (S35390A_FLAG_POC | S35390A_FLAG_BLD)
+
+/*-*/
+#undef DEBUG_RTC
+
+#ifdef DEBUG_RTC
+#define DEBUGR(fmt, args...) printf(fmt, ##args)
+#else
+#define DEBUGR(fmt, args...)
+#endif
+/*-*/
+
+#ifdef CONFIG_DM_RTC
+#define DEV_TYPE struct udevice
+#else
+/* Local udevice */
+struct ludevice {
+   u8 chip;
+};
+
+#define DEV_TYPE struct ludevice
+struct ludevice dev;
+
+#endif
+
+#define msleep(a) udelay(a * 1000)
+
+int lowvoltage;
+
+static int s35392a_rtc_reset(DEV_TYPE *dev);
+
+static int s35392a_rtc_read(DEV_TYPE *dev, u8 reg, u8 *buf, int len)
+{
+   int ret;
+
+#ifdef CONFIG_DM_RTC
+   /* TODO: we need to tweak the chip address to reg */
+   ret = dm_i2c_read(dev, 0, buf, len);
+#else
+   (void)dev;
+   ret = i2c_read(reg, 0, -1, buf, len);
+#endif
+
+   return ret;
+}
+
+static int s35392a_rtc_write(DEV_TYPE *dev, u8 reg, u8 *buf, int len)
+{
+   int ret;
+
+#ifdef CONFIG_DM_RTC
+   /* TODO: we need to tweak the chip address to reg */
+   ret = dm_i2c_write(dev, 0, buf, 1);
+#else
+   (void)dev;
+   ret = i2c_write(reg, 0, 0, buf, len);
+#endif
+
+   return ret;
+}
+
+static int s35392a_rtc_read8(DEV_TYPE *dev, unsigned int reg)
+{
+   u8 val;
+   int ret;
+
+   ret = s35392a_rtc_read(dev, reg, , sizeof(val));
+   return ret < 0 ? ret : val;
+}
+
+static int s35392a_rtc_write8(DEV_TYPE *dev, unsigned int reg, int val)
+{
+   int ret;
+   u8 lval = val;
+
+   ret = s35392a_rtc_write(dev, reg, , sizeof(lval));
+   return ret < 0 ? ret : 0;
+}
+

[U-Boot] [PATCH v5 7/8] board: ge: make VPD code common

2017-11-08 Thread Martyn Welch
The VPD data is used on a number of GE products. Move the parsing code to
a common location so that we can share this code.

Signed-off-by: Martyn Welch 
---
Changes in v4:
   - New patch.

Changes in v5:
   - Fixed checkpatch issues.

board/ge/bx50v3/Makefile |   2 +-
 board/ge/bx50v3/bx50v3.c |   2 +-
 board/ge/bx50v3/vpd_reader.c | 228 ---
 board/ge/bx50v3/vpd_reader.h |  25 -
 board/ge/common/Makefile |   7 ++
 board/ge/common/vpd_reader.c | 197 +
 board/ge/common/vpd_reader.h |  17 
 7 files changed, 223 insertions(+), 255 deletions(-)
 delete mode 100644 board/ge/bx50v3/vpd_reader.c
 delete mode 100644 board/ge/bx50v3/vpd_reader.h
 create mode 100644 board/ge/common/Makefile
 create mode 100644 board/ge/common/vpd_reader.c
 create mode 100644 board/ge/common/vpd_reader.h

diff --git a/board/ge/bx50v3/Makefile b/board/ge/bx50v3/Makefile
index 2fff27b..bcd149f 100644
--- a/board/ge/bx50v3/Makefile
+++ b/board/ge/bx50v3/Makefile
@@ -5,4 +5,4 @@
 # SPDX-License-Identifier: GPL-2.0+
 #
 
-obj-y  := bx50v3.o vpd_reader.o
+obj-y  := bx50v3.o
diff --git a/board/ge/bx50v3/bx50v3.c b/board/ge/bx50v3/bx50v3.c
index 2e8f394..37de990 100644
--- a/board/ge/bx50v3/bx50v3.c
+++ b/board/ge/bx50v3/bx50v3.c
@@ -28,7 +28,7 @@
 #include 
 #include 
 #include 
-#include "vpd_reader.h"
+#include "../common/vpd_reader.h"
 DECLARE_GLOBAL_DATA_PTR;
 
 #ifndef CONFIG_SYS_I2C_EEPROM_ADDR
diff --git a/board/ge/bx50v3/vpd_reader.c b/board/ge/bx50v3/vpd_reader.c
deleted file mode 100644
index 98da893..000
--- a/board/ge/bx50v3/vpd_reader.c
+++ /dev/null
@@ -1,228 +0,0 @@
-/*
- * Copyright 2016 General Electric Company
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-#include "vpd_reader.h"
-
-#include 
-#include 
-
-
-/* BCH configuration */
-
-const struct {
-   int header_ecc_capability_bits;
-   int data_ecc_capability_bits;
-   unsigned int prim_poly;
-   struct {
-   int min;
-   int max;
-   } galois_field_order;
-} bch_configuration = {
-   .header_ecc_capability_bits = 4,
-   .data_ecc_capability_bits = 16,
-   .prim_poly = 0,
-   .galois_field_order = {
-   .min = 5,
-   .max = 15,
-   },
-};
-
-static int calculate_galois_field_order(size_t source_length)
-{
-   int gfo = bch_configuration.galois_field_order.min;
-
-   for (; gfo < bch_configuration.galois_field_order.max &&
-1 << gfo) - 1) - ((int)source_length * 8)) < 0);
-gfo++) {
-   }
-
-   if (gfo == bch_configuration.galois_field_order.max) {
-   return -1;
-   }
-
-   return gfo + 1;
-}
-
-static int verify_bch(int ecc_bits, unsigned int prim_poly,
-   uint8_t * data, size_t data_length,
-   const uint8_t * ecc, size_t ecc_length)
-{
-   int gfo = calculate_galois_field_order(data_length);
-   if (gfo < 0) {
-   return -1;
-   }
-
-   struct bch_control * bch = init_bch(gfo, ecc_bits, prim_poly);
-   if (!bch) {
-   return -1;
-   }
-
-   if (bch->ecc_bytes != ecc_length) {
-   free_bch(bch);
-   return -1;
-   }
-
-   unsigned * errloc = (unsigned *)calloc(data_length, sizeof(unsigned));
-   int errors = decode_bch(
-   bch, data, data_length, ecc, NULL, NULL, errloc);
-   free_bch(bch);
-   if (errors < 0) {
-   free(errloc);
-   return -1;
-   }
-
-   if (errors > 0) {
-   for (int n = 0; n < errors; n++) {
-   if (errloc[n] >= 8 * data_length) {
-   /* n-th error located in ecc (no need for data 
correction) */
-   } else {
-   /* n-th error located in data */
-   data[errloc[n] / 8] ^= 1 << (errloc[n] % 8);
-   }
-   }
-   }
-
-   free(errloc);
-   return 0;
-}
-
-
-static const int ID = 0;
-static const int LEN = 1;
-static const int VER = 2;
-static const int TYP = 3;
-static const int BLOCK_SIZE = 4;
-
-static const uint8_t HEADER_BLOCK_ID = 0x00;
-static const uint8_t HEADER_BLOCK_LEN = 18;
-static const uint32_t HEADER_BLOCK_MAGIC = 0xca53ca53;
-static const size_t HEADER_BLOCK_VERIFY_LEN = 14;
-static const size_t HEADER_BLOCK_ECC_OFF = 14;
-static const size_t HEADER_BLOCK_ECC_LEN = 4;
-
-static const uint8_t ECC_BLOCK_ID = 0xFF;
-
-int vpd_reader(
-   size_t size,
-   uint8_t * data,
-   void * userdata,
-   int (*fn)(
-   void * userdata,
-   uint8_t id,
-   uint8_t version,
-   uint8_t type,
-   size_t size,
-   uint8_t const * data))
-{
-   if (   size < HEADER_BLOCK_LEN
-   || data == NULL
-   || fn == NULL) {
-   return -EINVAL;
-   

[U-Boot] [PATCH v5 2/8] ext4: recover from filesystem corruption when reading

2017-11-08 Thread Martyn Welch
From: Ian Ray 

Some fixes when reading EXT files and directory entries were identified
after using e2fuzz to corrupt an EXT3 filesystem:

 - Stop reading directory entries if the offset becomes badly aligned.

 - Avoid overwriting memory by clamping the length used to zero the buffer
   in ext4fs_read_file.  Also sanity check blocksize.

Signed-off-by: Ian Ray 
Signed-off-by: Martyn Welch 
---
 fs/ext4/ext4_common.c | 10 ++
 fs/ext4/ext4fs.c  | 10 +-
 2 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/fs/ext4/ext4_common.c b/fs/ext4/ext4_common.c
index 31952f4..dac9545 100644
--- a/fs/ext4/ext4_common.c
+++ b/fs/ext4/ext4_common.c
@@ -660,6 +660,11 @@ static int search_dir(struct ext2_inode *parent_inode, 
char *dirname)
 
offset = 0;
do {
+   if (offset & 3) {
+   printf("Badly aligned ext2_dirent\n");
+   break;
+   }
+
dir = (struct ext2_dirent *)(block_buffer + offset);
direntname = (char*)(dir) + sizeof(struct ext2_dirent);
 
@@ -880,6 +885,11 @@ static int unlink_filename(char *filename, unsigned int 
blknr)
 
offset = 0;
do {
+   if (offset & 3) {
+   printf("Badly aligned ext2_dirent\n");
+   break;
+   }
+
previous_dir = dir;
dir = (struct ext2_dirent *)(block_buffer + offset);
direntname = (char *)(dir) + sizeof(struct ext2_dirent);
diff --git a/fs/ext4/ext4fs.c b/fs/ext4/ext4fs.c
index b0c7303..9ee2caf 100644
--- a/fs/ext4/ext4fs.c
+++ b/fs/ext4/ext4fs.c
@@ -64,6 +64,9 @@ int ext4fs_read_file(struct ext2fs_node *node, loff_t pos,
char *delayed_buf = NULL;
short status;
 
+   if (blocksize <= 0)
+   return -1;
+
/* Adjust len so it we can't read past the end of the file. */
if (len + pos > filesize)
len = (filesize - pos);
@@ -127,6 +130,7 @@ int ext4fs_read_file(struct ext2fs_node *node, loff_t pos,
(blockend >> log2blksz);
}
} else {
+   int n;
if (previous_block_number != -1) {
/* spill */
status = ext4fs_devread(delayed_start,
@@ -137,7 +141,11 @@ int ext4fs_read_file(struct ext2fs_node *node, loff_t pos,
return -1;
previous_block_number = -1;
}
-   memset(buf, 0, blocksize - skipfirst);
+   /* Zero no more than `len' bytes. */
+   n = blocksize - skipfirst;
+   if (n > len)
+   n = len;
+   memset(buf, 0, n);
}
buf += blocksize - skipfirst;
}
-- 
2.1.4

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


[U-Boot] [PATCH v5 4/8] arm: mx5: Add more register definitions

2017-11-08 Thread Martyn Welch
Add register definitions require for video configuration.

Signed-off-by: Nandor Han 
Signed-off-by: Martyn Welch 
Reviewed-by: Stefano Babic 
Cc: Stefano Babic 
---
Changes in v5:
  - Reduced checkpatch warnings.

 arch/arm/include/asm/arch-mx5/crm_regs.h |  8 
 arch/arm/include/asm/arch-mx5/imx-regs.h | 33 
 2 files changed, 41 insertions(+)

diff --git a/arch/arm/include/asm/arch-mx5/crm_regs.h 
b/arch/arm/include/asm/arch-mx5/crm_regs.h
index b61c7b9..7fea569 100644
--- a/arch/arm/include/asm/arch-mx5/crm_regs.h
+++ b/arch/arm/include/asm/arch-mx5/crm_regs.h
@@ -210,6 +210,14 @@ struct mxc_ccm_reg {
 #define MXC_CCM_CSCMR1_SSI_EXT2_COM_CLK_SEL(0x1 << 1)
 #define MXC_CCM_CSCMR1_SSI_EXT1_COM_CLK_SEL0x1
 
+/* Define the bits in register CSCMR2 */
+#define MXC_CCM_CSCMR2_DI0_CLK_SEL_OFFSET  26
+#define MXC_CCM_CSCMR2_DI0_CLK_SEL_MASK(0x7 << 26)
+#define MXC_CCM_CSCMR2_DI0_CLK_SEL(v)  (((v) & 0x7) << 26)
+#define MXC_CCM_CSCMR2_DI0_CLK_SEL_RD(r)   (((r) >> 26) & 0x7)
+
+#define MXC_CCM_CSCMR2_DI0_CLK_SEL_LDB_DI0_CLK 5
+
 /* Define the bits in register CSCDR2 */
 #define MXC_CCM_CSCDR2_CSPI_CLK_PRED_OFFSET25
 #define MXC_CCM_CSCDR2_CSPI_CLK_PRED_MASK  (0x7 << 25)
diff --git a/arch/arm/include/asm/arch-mx5/imx-regs.h 
b/arch/arm/include/asm/arch-mx5/imx-regs.h
index 2b0dc1e..61c8d44 100644
--- a/arch/arm/include/asm/arch-mx5/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx5/imx-regs.h
@@ -416,6 +416,39 @@ struct iomuxc {
 };
 #endif
 
+#define IOMUXC_GPR2_BITMAP_SPWG0
+#define IOMUXC_GPR2_BITMAP_JEIDA   1
+
+#define IOMUXC_GPR2_BIT_MAPPING_CH0_OFFSET 6
+#define IOMUXC_GPR2_BIT_MAPPING_CH0_MASK   (1 << 
IOMUXC_GPR2_BIT_MAPPING_CH0_OFFSET)
+#define IOMUXC_GPR2_BIT_MAPPING_CH0_JEIDA  (IOMUXC_GPR2_BITMAP_JEIDA << \
+
IOMUXC_GPR2_BIT_MAPPING_CH0_OFFSET)
+#define IOMUXC_GPR2_BIT_MAPPING_CH0_SPWG   (IOMUXC_GPR2_BITMAP_SPWG << \
+
IOMUXC_GPR2_BIT_MAPPING_CH0_OFFSET)
+
+#define IOMUXC_GPR2_DATA_WIDTH_18  0
+#define IOMUXC_GPR2_DATA_WIDTH_24  1
+
+#define IOMUXC_GPR2_DATA_WIDTH_CH0_OFFSET  5
+#define IOMUXC_GPR2_DATA_WIDTH_CH0_MASK(1 << 
IOMUXC_GPR2_DATA_WIDTH_CH0_OFFSET)
+#define IOMUXC_GPR2_DATA_WIDTH_CH0_18BIT   (IOMUXC_GPR2_DATA_WIDTH_18 << \
+
IOMUXC_GPR2_DATA_WIDTH_CH0_OFFSET)
+#define IOMUXC_GPR2_DATA_WIDTH_CH0_24BIT   (IOMUXC_GPR2_DATA_WIDTH_24 << \
+
IOMUXC_GPR2_DATA_WIDTH_CH0_OFFSET)
+
+#define IOMUXC_GPR2_MODE_DISABLED  0
+#define IOMUXC_GPR2_MODE_ENABLED_DI0   1
+#define IOMUXC_GPR2_MODE_ENABLED_DI1   3
+
+#define IOMUXC_GPR2_LVDS_CH0_MODE_OFFSET   0
+#define IOMUXC_GPR2_LVDS_CH0_MODE_MASK (3 << 
IOMUXC_GPR2_LVDS_CH0_MODE_OFFSET)
+#define IOMUXC_GPR2_LVDS_CH0_MODE_DISABLED (IOMUXC_GPR2_MODE_DISABLED << \
+
IOMUXC_GPR2_LVDS_CH0_MODE_OFFSET)
+#define IOMUXC_GPR2_LVDS_CH0_MODE_ENABLED_DI0  (IOMUXC_GPR2_MODE_ENABLED_DI0 
<< \
+
IOMUXC_GPR2_LVDS_CH0_MODE_OFFSET)
+#define IOMUXC_GPR2_LVDS_CH0_MODE_ENABLED_DI1  (IOMUXC_GPR2_MODE_ENABLED_DI1 
<< \
+
IOMUXC_GPR2_LVDS_CH0_MODE_OFFSET)
+
 /* System Reset Controller (SRC) */
 struct src {
u32 scr;
-- 
2.1.4

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


[U-Boot] [PATCH v5 5/8] bootcount: add support for bootcounter on EXT filesystem

2017-11-08 Thread Martyn Welch
From: Ian Ray 

Add support for bootcounter on an EXT filesystem.
Sync configuration whitelist.

Signed-off-by: Ian Ray 
Signed-off-by: Martyn Welch 
---
Changes for v2:
   - Adding Kconfig for EXT bootcount.

Changes for v3:
   - Add over-arching BOOTCOUNT Kconfig entry.

Changes for v5:
  - Improved BOOTCOUNT_EXT description.
  - Fixed checkpatch issues.


 README|  7 +
 drivers/Kconfig   |  2 ++
 drivers/bootcount/Kconfig | 58 
 drivers/bootcount/Makefile|  1 +
 drivers/bootcount/bootcount_ext.c | 62 +++
 5 files changed, 130 insertions(+)
 create mode 100644 drivers/bootcount/Kconfig
 create mode 100644 drivers/bootcount/bootcount_ext.c

diff --git a/README b/README
index f288176..6336c5c 100644
--- a/README
+++ b/README
@@ -2362,6 +2362,13 @@ The following options need to be configured:
CONFIG_SYS_BOOTCOUNT_ADDR = i2c addr which is used for
the bootcounter.
CONFIG_BOOTCOUNT_ALEN = address len
+   CONFIG_BOOTCOUNT_EXT
+   enable support for the bootcounter in EXT filesystem
+   CONFIG_SYS_BOOTCOUNT_ADDR = RAM address used for read
+and write.
+   CONFIG_SYS_BOOTCOUNT_EXT_INTERFACE = interface
+   CONFIG_SYS_BOOTCOUNT_EXT_DEVPART = device and part
+   CONFIG_SYS_BOOTCOUNT_EXT_NAME = filename
 
 - Show boot progress:
CONFIG_SHOW_BOOT_PROGRESS
diff --git a/drivers/Kconfig b/drivers/Kconfig
index 613e602..c2e813f 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -10,6 +10,8 @@ source "drivers/ata/Kconfig"
 
 source "drivers/block/Kconfig"
 
+source "drivers/bootcount/Kconfig"
+
 source "drivers/clk/Kconfig"
 
 source "drivers/cpu/Kconfig"
diff --git a/drivers/bootcount/Kconfig b/drivers/bootcount/Kconfig
new file mode 100644
index 000..c9d627c
--- /dev/null
+++ b/drivers/bootcount/Kconfig
@@ -0,0 +1,58 @@
+#
+# Boot count configuration
+#
+
+menu "Boot count support"
+
+config BOOTCOUNT
+   bool "Enable Boot count support"
+   help
+ Enable boot count support, which provides the ability to store the
+ number of times the board has booted on a number of different
+ persistent storage mediums.
+
+if BOOTCOUNT
+
+config BOOTCOUNT_EXT
+   bool "Boot counter on EXT filesystem"
+   help
+ Add support for maintaining boot count in a file on an EXT
+ filesystem.
+
+if BOOTCOUNT_EXT
+
+config SYS_BOOTCOUNT_EXT_INTERFACE
+   string "Interface on which to find boot counter EXT filesystem"
+   default "mmc"
+   depends on BOOTCOUNT_EXT
+   help
+ Set the interface to use when locating the filesystem to use for the
+ boot counter.
+
+config SYS_BOOTCOUNT_EXT_DEVPART
+   string "Partition of the boot counter EXT filesystem"
+   default "0:1"
+   depends on BOOTCOUNT_EXT
+   help
+ Set the partition to use when locating the filesystem to use for the
+ boot counter.
+
+config SYS_BOOTCOUNT_EXT_NAME
+   string "Path and filename of the EXT filesystem based boot counter"
+   default "/boot/failures"
+   depends on BOOTCOUNT_EXT
+   help
+ Set the filename and path of the file used to store the boot counter.
+
+config SYS_BOOTCOUNT_ADDR
+   hex "RAM address used for reading and writing the boot counter"
+   default 0x7000A000
+   depends on BOOTCOUNT_EXT
+   help
+ Set the address used for reading and writing the boot counter.
+
+endif
+
+endif
+
+endmenu
diff --git a/drivers/bootcount/Makefile b/drivers/bootcount/Makefile
index ed9659a..45445d2 100644
--- a/drivers/bootcount/Makefile
+++ b/drivers/bootcount/Makefile
@@ -9,3 +9,4 @@ obj-$(CONFIG_BOOTCOUNT_AM33XX)  += bootcount_davinci.o
 obj-$(CONFIG_BOOTCOUNT_RAM)+= bootcount_ram.o
 obj-$(CONFIG_BOOTCOUNT_ENV)+= bootcount_env.o
 obj-$(CONFIG_BOOTCOUNT_I2C)+= bootcount_i2c.o
+obj-$(CONFIG_BOOTCOUNT_EXT)+= bootcount_ext.o
diff --git a/drivers/bootcount/bootcount_ext.c 
b/drivers/bootcount/bootcount_ext.c
new file mode 100644
index 000..e0dd21b
--- /dev/null
+++ b/drivers/bootcount/bootcount_ext.c
@@ -0,0 +1,62 @@
+/*
+ * Copyright (c) 2017 General Electric Company. All rights reserved.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+
+#define BC_MAGIC   0xbc
+
+void bootcount_store(ulong a)
+{
+   u8 *buf;
+   loff_t len;
+   int ret;
+
+   if (fs_set_blk_dev(CONFIG_SYS_BOOTCOUNT_EXT_INTERFACE,
+  CONFIG_SYS_BOOTCOUNT_EXT_DEVPART, FS_TYPE_EXT)) {
+   puts("Error selecting device\n");
+   return;
+   }
+
+   

[U-Boot] [PATCH v5 3/8] pwm: imx: Enable PWM support on i.MX53

2017-11-08 Thread Martyn Welch
Add missing parts for i.MX53 PWM support

Acked-by: Nandor Han 
Signed-off-by: Martyn Welch 
Cc: Stefano Babic 
---
Changes for v4:
   - Removed ifdef.

 arch/arm/include/asm/arch-mx5/imx-regs.h | 17 +
 drivers/pwm/pwm-imx-util.c   |  2 ++
 2 files changed, 19 insertions(+)

diff --git a/arch/arm/include/asm/arch-mx5/imx-regs.h 
b/arch/arm/include/asm/arch-mx5/imx-regs.h
index 3e79fa3..2b0dc1e 100644
--- a/arch/arm/include/asm/arch-mx5/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx5/imx-regs.h
@@ -508,6 +508,23 @@ struct fuse_bank4_regs {
 };
 #endif
 
+#define PWMCR_PRESCALER(x) (((x - 1) & 0xFFF) << 4)
+#define PWMCR_DOZEEN   (1 << 24)
+#define PWMCR_WAITEN   (1 << 23)
+#define PWMCR_DBGEN(1 << 22)
+#define PWMCR_CLKSRC_IPG_HIGH  (2 << 16)
+#define PWMCR_CLKSRC_IPG   (1 << 16)
+#define PWMCR_EN   (1 << 0)
+
+struct pwm_regs {
+   u32 cr;
+   u32 sr;
+   u32 ir;
+   u32 sar;
+   u32 pr;
+   u32 cnr;
+};
+
 #endif /* __ASSEMBLER__*/
 
 #endif /* __ASM_ARCH_MX5_IMX_REGS_H__ */
diff --git a/drivers/pwm/pwm-imx-util.c b/drivers/pwm/pwm-imx-util.c
index 534dd8e..97ac0c8 100644
--- a/drivers/pwm/pwm-imx-util.c
+++ b/drivers/pwm/pwm-imx-util.c
@@ -23,10 +23,12 @@ struct pwm_regs *pwm_id_to_reg(int pwm_id)
return (struct pwm_regs *)PWM1_BASE_ADDR;
case 1:
return (struct pwm_regs *)PWM2_BASE_ADDR;
+#ifdef CONFIG_MX6
case 2:
return (struct pwm_regs *)PWM3_BASE_ADDR;
case 3:
return (struct pwm_regs *)PWM4_BASE_ADDR;
+#endif
 #ifdef CONFIG_MX6SX
case 4:
return (struct pwm_regs *)PWM5_BASE_ADDR;
-- 
2.1.4

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


[U-Boot] [PATCH v5 0/8] Add support for GE PPD

2017-11-08 Thread Martyn Welch
*** Resend due to previous use of unsubscribed email address ***

This series adds support for the GE PPD. The initial patches in this
series resolve issues found during development and testing, extend
existing support and add new support for devices in the PPD. The final
patch in the series adds the board support for the PPD.

Ian Ray (2):
  ext4: recover from filesystem corruption when reading
  bootcount: add support for bootcounter on EXT filesystem

Martyn Welch (3):
  pwm: imx: Enable PWM support on i.MX53
  arm: mx5: Add more register definitions
  board: ge: make VPD code common

Nandor Han (2):
  imx: mxc_i2c: tweak the i2c transfer method
  rtc: add support for s35392a

Peter Senna Tschudin (1):
  mx53: Add Board support for GE PPD

 README   |   7 +
 arch/arm/include/asm/arch-mx5/crm_regs.h |   8 +
 arch/arm/include/asm/arch-mx5/imx-regs.h |  50 
 arch/arm/mach-imx/mx5/Kconfig|   7 +
 board/ge/bx50v3/Makefile |   2 +-
 board/ge/bx50v3/bx50v3.c |   2 +-
 board/ge/bx50v3/vpd_reader.c | 228 ---
 board/ge/bx50v3/vpd_reader.h |  25 --
 board/ge/common/Makefile |   7 +
 board/ge/common/vpd_reader.c | 197 +
 board/ge/common/vpd_reader.h |  17 ++
 board/ge/mx53ppd/Kconfig |  17 ++
 board/ge/mx53ppd/MAINTAINERS |   7 +
 board/ge/mx53ppd/Makefile|  12 +
 board/ge/mx53ppd/imximage.cfg|  87 ++
 board/ge/mx53ppd/mx53ppd.c   | 457 +++
 board/ge/mx53ppd/mx53ppd_video.c | 135 +
 board/ge/mx53ppd/ppd_gpio.h  |  96 +++
 configs/mx53ppd_defconfig|  39 +++
 drivers/Kconfig  |   2 +
 drivers/bootcount/Kconfig|  58 
 drivers/bootcount/Makefile   |   1 +
 drivers/bootcount/bootcount_ext.c|  62 +
 drivers/i2c/mxc_i2c.c|  25 +-
 drivers/pwm/pwm-imx-util.c   |   2 +
 drivers/rtc/Kconfig  |   6 +
 drivers/rtc/Makefile |   1 +
 drivers/rtc/s35392a.c| 365 
 fs/ext4/ext4_common.c|  10 +
 fs/ext4/ext4fs.c |  10 +-
 include/configs/mx53ppd.h| 248 +
 lib/Kconfig  |   3 +
 32 files changed, 1927 insertions(+), 266 deletions(-)
 delete mode 100644 board/ge/bx50v3/vpd_reader.c
 delete mode 100644 board/ge/bx50v3/vpd_reader.h
 create mode 100644 board/ge/common/Makefile
 create mode 100644 board/ge/common/vpd_reader.c
 create mode 100644 board/ge/common/vpd_reader.h
 create mode 100644 board/ge/mx53ppd/Kconfig
 create mode 100644 board/ge/mx53ppd/MAINTAINERS
 create mode 100644 board/ge/mx53ppd/Makefile
 create mode 100644 board/ge/mx53ppd/imximage.cfg
 create mode 100644 board/ge/mx53ppd/mx53ppd.c
 create mode 100644 board/ge/mx53ppd/mx53ppd_video.c
 create mode 100644 board/ge/mx53ppd/ppd_gpio.h
 create mode 100644 configs/mx53ppd_defconfig
 create mode 100644 drivers/bootcount/Kconfig
 create mode 100644 drivers/bootcount/bootcount_ext.c
 create mode 100644 drivers/rtc/s35392a.c
 create mode 100644 include/configs/mx53ppd.h

-- 
2.1.4

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


Re: [U-Boot] [PATCH 1/1] efi_loader: manage protocols in a linked list

2017-11-08 Thread Alexander Graf

On 11/01/2017 09:31 AM, Heinrich Schuchardt wrote:

Signed-off-by: Heinrich Schuchardt 


I guess you did not mean to send this email? :)


Alex

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


Re: [U-Boot] [PATCH 17/18] efi_loader: refactor efi_setup_loaded_image

2017-11-08 Thread Alexander Graf

On 10/26/2017 07:25 PM, Heinrich Schuchardt wrote:

Use helper functions to add protocols.

Signed-off-by: Heinrich Schuchardt 
---
  lib/efi_loader/efi_boottime.c | 39 +--
  1 file changed, 25 insertions(+), 14 deletions(-)

diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index a526280e4c..3f23e6d638 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -1193,34 +1193,45 @@ void efi_setup_loaded_image(struct efi_loaded_image 
*info, struct efi_object *ob
struct efi_device_path *device_path,
struct efi_device_path *file_path)
  {
+   efi_status_t ret;
+
obj->handle = info;
  
+	info->file_path = file_path;

+   if (device_path)
+   info->device_handle = efi_dp_find_obj(device_path, NULL);
+
+   list_add_tail(>link, _obj_list);
/*
 * When asking for the device path interface, return
 * bootefi_device_path
 */
-   obj->protocols[0].guid = _guid_device_path;
-   obj->protocols[0].protocol_interface = device_path;
+   ret = efi_add_protocol(obj->handle, _guid_device_path, device_path);


Can we always assume that there are no other protocols installed 
already? The current code simply overrides them if there are any.



Alex


+   if (ret != EFI_SUCCESS)
+   goto failure;
  
  	/*

 * When asking for the loaded_image interface, just
 * return handle which points to loaded_image_info
 */
-   obj->protocols[1].guid = _guid_loaded_image;
-   obj->protocols[1].protocol_interface = info;
-
-   obj->protocols[2].guid = _guid_console_control;
-   obj->protocols[2].protocol_interface = (void *)_console_control;
+   ret = efi_add_protocol(obj->handle, _guid_loaded_image, info);
+   if (ret != EFI_SUCCESS)
+   goto failure;
  
-	obj->protocols[3].guid = _guid_device_path_to_text_protocol;

-   obj->protocols[3].protocol_interface =
-   (void *)_device_path_to_text;
+   ret = efi_add_protocol(obj->handle, _guid_console_control,
+  (void *)_console_control);
+   if (ret != EFI_SUCCESS)
+   goto failure;
  
-	info->file_path = file_path;

-   if (device_path)
-   info->device_handle = efi_dp_find_obj(device_path, NULL);
+   ret = efi_add_protocol(obj->handle,
+  _guid_device_path_to_text_protocol,
+  (void *)_device_path_to_text);
+   if (ret != EFI_SUCCESS)
+   goto failure;
  
-	list_add_tail(>link, _obj_list);

+   return;
+failure:
+   printf("ERROR: Failure to install protocols for loaded image\n");
  }
  
  /*



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


[U-Boot] [PATCH] arm64: zynqmp: Add revision to identification string

2017-11-08 Thread Michal Simek
It is good to see revision in boot log.

Signed-off-by: Michal Simek 
---

 configs/xilinx_zynqmp_zcu102_revA_defconfig | 2 +-
 configs/xilinx_zynqmp_zcu102_revB_defconfig | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/configs/xilinx_zynqmp_zcu102_revA_defconfig 
b/configs/xilinx_zynqmp_zcu102_revA_defconfig
index d8742a1bfec8..80c5e4934844 100644
--- a/configs/xilinx_zynqmp_zcu102_revA_defconfig
+++ b/configs/xilinx_zynqmp_zcu102_revA_defconfig
@@ -3,7 +3,7 @@ CONFIG_SYS_CONFIG_NAME="xilinx_zynqmp_zcu102"
 CONFIG_ARCH_ZYNQMP=y
 CONFIG_SYS_TEXT_BASE=0x800
 CONFIG_SYS_MALLOC_F_LEN=0x8000
-CONFIG_IDENT_STRING=" Xilinx ZynqMP ZCU102"
+CONFIG_IDENT_STRING=" Xilinx ZynqMP ZCU102 revA"
 CONFIG_ZYNQMP_USB=y
 CONFIG_DEFAULT_DEVICE_TREE="zynqmp-zcu102-revA"
 CONFIG_DEBUG_UART=y
diff --git a/configs/xilinx_zynqmp_zcu102_revB_defconfig 
b/configs/xilinx_zynqmp_zcu102_revB_defconfig
index e5d71bd5494e..328a00862989 100644
--- a/configs/xilinx_zynqmp_zcu102_revB_defconfig
+++ b/configs/xilinx_zynqmp_zcu102_revB_defconfig
@@ -3,7 +3,7 @@ CONFIG_SYS_CONFIG_NAME="xilinx_zynqmp_zcu102"
 CONFIG_ARCH_ZYNQMP=y
 CONFIG_SYS_TEXT_BASE=0x800
 CONFIG_SYS_MALLOC_F_LEN=0x8000
-CONFIG_IDENT_STRING=" Xilinx ZynqMP ZCU102"
+CONFIG_IDENT_STRING=" Xilinx ZynqMP ZCU102 revB
 CONFIG_ZYNQMP_USB=y
 CONFIG_DEFAULT_DEVICE_TREE="zynqmp-zcu102-revB"
 CONFIG_DEBUG_UART=y
-- 
1.9.1

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


Re: [U-Boot] [PATCH v4 12/18] efi_selftest: correctly cleanup after selftest

2017-11-08 Thread Alexander Graf

On 10/18/2017 06:13 PM, Heinrich Schuchardt wrote:

After executing bootefi selftest
* restore GD
* unlink the load image handle
* return 0 or 1 and not a truncated efi_status_t.

Signed-off-by: Heinrich Schuchardt 
---
v4
no change
v3
new patch split off
---
  cmd/bootefi.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 18331536dd..40834f3899 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -349,8 +349,10 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int 
argc, char * const argv[])
set_load_options(_image_info, "efi_selftest");
/* Execute the test */
r = efi_selftest(_image_info, );
+   efi_restore_gd();


Why don't we have to restore gd on normal efi binaries? Because Exit() 
is doing that for us?


In that case, why not call efi_selftest() through efi_do_enter()? That 
should give you the exit call for free ;)



Alex

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


[U-Boot] password for u-boot

2017-11-08 Thread necib yassine
Hi everyone,
I have a technical question about u-boot.
Is there any way to set up a security (for instance password...) either any
users cannot handle u-boot environments variables ?
When the user plug his serial sâble, I do not want to allow him to see any
the contents variable envrionments.
I found something about CONFIG_ENV_AES but it is no clear about what the
user can/cannot do.
http://events.linuxfoundation.org/sites/events/files/slides/elce-2014.pdf
Thank you :)


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


Re: [U-Boot] [RFC] efi_loader: frame buffers in EFI GOP and DM_VIDEO

2017-11-08 Thread Alexander Graf

On 11/07/2017 02:36 AM, Rob Clark wrote:

On Wed, Oct 25, 2017 at 3:45 PM, Heinrich Schuchardt  wrote:

Hello Alex, hello Simon,

I have just been reading through efi_gop and video_uclass.c and there seems
to be something missing in the support of video modes.

U-Boot configuration knows the following color models:

16-color
256-color
32k (1:5:5:5)
64k (5:6:5)
16.8M (8:8:8)

In lib/efi_loader/efi_gop.c I only found

VIDEO_BPP32
VIDEO_BPP16
Patch a812241091ce efi_loader: Add DM_VIDEO support (Alexander Graf)

Shouldn't gop_blt differentiate between 32k and 64k color mode?
Unfortunately video_uclass.c cannot tell the difference!
What about 4 and 8 bit modes?

When I look at the coding in video_uclass.c, function video_clear it seems
that this only correctly supports 32bit and 8bit mode.
Patch 1acafc73bfc7 dm: video: Add a video uclass (Simon Glass)

Shouldn't 4, 15 and 16 bit modes be added here?


(apologies for being a bit behind on u-boot mails but been busy on
other upstreams)

iirc UEFI only supports a subset of what u-boot supports (and I think
it is worse because u-boot doesn't do a good job of differentiating
between different component orders of a given bpp).. but we could
support more hw by not with the path that doesn't expose the scanout
buffer address and only supports blitting to scanout buffer (and doing
conversion as part of the blit).  I think it is mostly a matter of
someone who has this hw writing and testing the appropriate blit
paths..


My thinking was that the most useful bit of GOP support is efifb in 
Linux. Using that you can directly pass the frame buffer to Linux and 
use it from there, removing the need for a graphics driver in simple use 
cases and allowing early boot messages to appear on the screen.


This however only works well with 32bpp. Even 16bpp was essentially 
unused in the wild - we had to fix bugs in Linux first to actually make 
it work :). I don't think any other modes will realistically ever be 
supported.


So my base take on this is: Let's treat devices that have <16bpp depth 
as simply not having graphics at all, unless someone really needs it. 
Then they can implement it :).



Alex

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


Re: [U-Boot] Include FSP in u-boot.rom

2017-11-08 Thread vnktux
Hi,

Super it works, thanks!!

One more question, I am still trying to port Broadwell-DE in U-boot as bare 
metal boot-loader. Could you please tell me what are the files that I have to 
port from Coreboot/src/soc/intel/fsp_broadwell_de? And are there any files I 
can re-use from U-Boot/arch/x86/broadwell? (I think that Broadwell and 
Broadwell-DE should share some things).

If you would like to review what I have done so far, I can give you the link of 
my gitlab repo.
Thanks in advance!

Sent with [ProtonMail](https://protonmail.com) Secure Email.

>  Original Message 
> Subject: Re: [U-Boot] Include FSP in u-boot.rom
> Local Time: November 8, 2017 12:16 AM
> UTC Time: November 7, 2017 11:16 PM
> From: bmeng...@gmail.com
> To: vnktux , Simon Glass 
> u-boot@lists.denx.de 
>
> Hi,
>
> On Wed, Nov 8, 2017 at 7:13 AM, Bin Meng bmeng...@gmail.com wrote:
>
>> Hi,
>> On Tue, Nov 7, 2017 at 10:13 PM, vnktux vnk...@protonmail.com wrote:
>>
>>> Hi guys,
>>> I need to generate a u-boot.rom image of exactly 8Mb that include only 
>>> fsp.bin and vga.bin. The reason is because in my company we will use an 
>>> Intel tool that already contain descriptor and intel ME for our platform.
>>> Has been already 1 week that I am struggling to do this, if I specify the 
>>> build command BUILD_ROM=y u-boot keep asking for descriptor, fsp and 
>>> me.bin. And anyway if I give all the blobs in imput the building doesnt 
>>> succed and it complain that the rom file is bigger than my flash (which is 
>>> impossible since fsp=1.5Mb, vga=400Kb, me=8Mb, and the selected flash size 
>>> is 16Mb).
>>> Can someone please help me with this?
>>
>> Don't set BUILD_ROM=y and you should be able to generate a u-boot.rom
>> with FSP and VGA images.
>>
>> Sorry, just woke up.. I wanted to say:
>>
>> Don't set CONFIG_HAVE_INTEL_ME and you should be able to generate a
>> u-boot.rom with FSP and VGA images.
>>
>> Regards,
>> Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] Support of latest qemux86-64

2017-11-08 Thread Anton Gerasimov
Adding Igor Mammedov to the loop.

On 11/08/2017 01:59 PM, Anton Gerasimov wrote:
> To whoever might be interested: I've bisected qemu and the breaking
> commit is 208fa0e43645edd0b0d8f838857dfc79daff40a8 (pc: make 'pc.rom'
> readonly when machine has PCI enabled). It's just three lines added,
> I'll paste the whole patch here. Not quite sure what can we do here though.
>
>
>   diff --git a/hw/i386/pc.c b/hw/i386/pc.c
>   index 22e16031b0..59435390ba 100644
>   --- a/hw/i386/pc.c
>   +++ b/hw/i386/pc.c
>   @@ -1443,6 +1443,9 @@ void pc_memory_init(PCMachineState *pcms,
>        option_rom_mr = g_malloc(sizeof(*option_rom_mr));
>        memory_region_init_ram(option_rom_mr, NULL, "pc.rom", PC_ROM_SIZE,
>       _fatal);
>   +    if (pcmc->pci_enabled) {
>   +    memory_region_set_readonly(option_rom_mr, true);
>   +    }
>        memory_region_add_subregion_overlap(rom_memory,
>            PC_ROM_MIN_VGA,
>        option_rom_mr,
>
>
> Thanks,
> Anton
>
>
> On 11/06/2017 02:55 AM, Bin Meng wrote:
>> +QEMU dev list
>>
>> On Fri, Nov 3, 2017 at 10:07 PM, Anton Gerasimov
>>  wrote:
>>> Hi all,
>>>
>>> I'm trying to use u-boot (v2017.01) with qemu-system-x86_64 v2.10.0 and
>>> run into a "trying to execute code outside of RAM or ROM at x"
>>> issue. It happens both when I build and use u-boot as a bios and as EFI
>>> payload, just the addresses in the error message are different. On qemu
>>> v2.5.0 at least EFI option works fine.
>>>
>>> I understand that it can be (and probably is) a QEMU issue, but maybe
>>> someone on the list already encountered it and knows a workaround or has
>>> successfully used u-boot with QEMU >=2.10.0 and can share their experience.
>>>
>> Yes, I just tested latest U-Boot x86 ROM image with QEMU 2.9.1 and
>> 2.10.1. The same U-Boot ROM image boots with 2.9.1 but not with
>> 2.10.1.
>>
>> I built U-Boot as follows:
>>
>> $ make qemu-x86_defconfig
>> $ make
>>
>> Does anyone have any hints?
>>
>> Regards,
>> Bin
>

-- 
Anton Gerasimov, ATS Advanced Telematic Systems GmbH
Kantstrasse 162, 10623 Berlin
Managing Directors: Dirk Pöschl, Armin G. Schmidt
Register Court: HRB 151501 B, Amtsgericht Charlottenburg

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


Re: [U-Boot] Support of latest qemux86-64

2017-11-08 Thread Anton Gerasimov
To whoever might be interested: I've bisected qemu and the breaking
commit is 208fa0e43645edd0b0d8f838857dfc79daff40a8 (pc: make 'pc.rom'
readonly when machine has PCI enabled). It's just three lines added,
I'll paste the whole patch here. Not quite sure what can we do here though.


  diff --git a/hw/i386/pc.c b/hw/i386/pc.c
  index 22e16031b0..59435390ba 100644
  --- a/hw/i386/pc.c
  +++ b/hw/i386/pc.c
  @@ -1443,6 +1443,9 @@ void pc_memory_init(PCMachineState *pcms,
       option_rom_mr = g_malloc(sizeof(*option_rom_mr));
       memory_region_init_ram(option_rom_mr, NULL, "pc.rom", PC_ROM_SIZE,
      _fatal);
  +    if (pcmc->pci_enabled) {
  +    memory_region_set_readonly(option_rom_mr, true);
  +    }
       memory_region_add_subregion_overlap(rom_memory,
           PC_ROM_MIN_VGA,
       option_rom_mr,


Thanks,
Anton


On 11/06/2017 02:55 AM, Bin Meng wrote:
> +QEMU dev list
>
> On Fri, Nov 3, 2017 at 10:07 PM, Anton Gerasimov
>  wrote:
>> Hi all,
>>
>> I'm trying to use u-boot (v2017.01) with qemu-system-x86_64 v2.10.0 and
>> run into a "trying to execute code outside of RAM or ROM at x"
>> issue. It happens both when I build and use u-boot as a bios and as EFI
>> payload, just the addresses in the error message are different. On qemu
>> v2.5.0 at least EFI option works fine.
>>
>> I understand that it can be (and probably is) a QEMU issue, but maybe
>> someone on the list already encountered it and knows a workaround or has
>> successfully used u-boot with QEMU >=2.10.0 and can share their experience.
>>
> Yes, I just tested latest U-Boot x86 ROM image with QEMU 2.9.1 and
> 2.10.1. The same U-Boot ROM image boots with 2.9.1 but not with
> 2.10.1.
>
> I built U-Boot as follows:
>
> $ make qemu-x86_defconfig
> $ make
>
> Does anyone have any hints?
>
> Regards,
> Bin


-- 
Anton Gerasimov, ATS Advanced Telematic Systems GmbH
Kantstrasse 162, 10623 Berlin
Managing Directors: Dirk Pöschl, Armin G. Schmidt
Register Court: HRB 151501 B, Amtsgericht Charlottenburg

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


Re: [U-Boot] [U-Boot, 7/9] ARM: dts: rockchip: Add usb host for rk3288-vyasa

2017-11-08 Thread Philipp Tomsich
> Add usb host support for rk3288-vyasa, board support hub power
> through phy_pwr_en and usb2 host power through usb2_pwr_en and
> naming conversion followed as per schematic.
> 
> Signed-off-by: Jagan Teki 
> Acked-by: Philipp Tomsich 
> ---
>  arch/arm/dts/rk3288-vyasa.dts  | 48 
> ++
>  include/dt-bindings/pinctrl/rockchip.h |  1 +
>  2 files changed, 49 insertions(+)
> 

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


Re: [U-Boot] sunxi: SATA link timeout fix

2017-11-08 Thread Peter Robinson
On Wed, Nov 8, 2017 at 11:32 AM, Jagan Teki  wrote:
> On Tue, Nov 7, 2017 at 5:43 PM, Jagan Teki  wrote:
>> On Sun, Nov 5, 2017 at 7:11 PM, Werner Böllmann
>>  wrote:
>>> After updating u-boot from v2016.01 to 2017.09 i got a "SATA link 0 
>>> timeout." on my Cubietruck board.
>>> I tracked this down to this patch.
>>>
>>> http://git.denx.de/?p=u-boot.git;a=commitdiff_plain;h=9fbb0c3aa49f4604b0342cb527a6bd099f92eaeb.
>>
>> Look like mdelay missing while moving to board file.
>
> Can someone test this?

I boot my Cubietruck off a SATA drive without issues with any of those
intervening releases but it's a SSD so there would be no spin up time
compared to spinning rust, I don't have a spare spinning disk to test
it with though.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] ethernet: ROM MAC address vs env variable MAC address

2017-11-08 Thread Prabhakar Kushwaha
Hi All, 

I am seeing following type of code for MAC address write for a network device.

net/eth-uclass.c  eth_post_probe()   or net/eth_legacy.c eth_write_hwaddr()

eth_env_get_enetaddr_by_index("eth", dev->seq, env_enetaddr);
if (!is_zero_ethaddr(env_enetaddr)) {
if (!is_zero_ethaddr(pdata->enetaddr) &&
memcmp(pdata->enetaddr, env_enetaddr, ARP_HLEN)) {
printf("\nWarning: %s MAC addresses don't match:\n",
   dev->name);
printf("Address in ROM is  %pM\n",
   pdata->enetaddr);
printf("Address in environment is  %pM\n",
   env_enetaddr);
}

/* Override the ROM MAC address */
memcpy(pdata->enetaddr, env_enetaddr, ARP_HLEN);

Why ROM MAC address getting overwritten by environment env MAC address.  
MAC address is something unique and assigned to a particular device. So one 
should never change its MAC address.

Please suggest. 

Regards,
Prabhakar

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


Re: [U-Boot] [PATCH 1/2] sunxi: fix CONFIG_SUNXI_EMAC references

2017-11-08 Thread Jagan Teki
On Wed, Nov 8, 2017 at 8:38 AM, Artturi Alm  wrote:
> fixes CONFIG_SUNXI_EMAC references from drivers/net/Makefile and
> include/configs/sunxi-common.h likely forgotten in:
> commit abc3e4df59f5 ("sunxi: Convert SUNXI_EMAC to Kconfig")
>
> Signed-off-by: Artturi Alm 

Reviewed-by: Jagan Teki 

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 2/2] sunxi: restore PHYLIB for CONFIG_SUN4I_EMAC users

2017-11-08 Thread Jagan Teki
On Wed, Nov 8, 2017 at 8:38 AM, Artturi Alm  wrote:
> due misnaming of CONFIG_SUN4I_EMAC in include/configs/sunxi-common.h,
> likely missed in:
> commit 3146f0c017df ("Move PHYLIB to Kconfig")
>
> Signed-off-by: Artturi Alm 

Reviewed-by: Jagan Teki 

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] sunxi: SATA link timeout fix

2017-11-08 Thread Jagan Teki
On Tue, Nov 7, 2017 at 5:43 PM, Jagan Teki  wrote:
> On Sun, Nov 5, 2017 at 7:11 PM, Werner Böllmann
>  wrote:
>> After updating u-boot from v2016.01 to 2017.09 i got a "SATA link 0 
>> timeout." on my Cubietruck board.
>> I tracked this down to this patch.
>>
>> http://git.denx.de/?p=u-boot.git;a=commitdiff_plain;h=9fbb0c3aa49f4604b0342cb527a6bd099f92eaeb.
>
> Look like mdelay missing while moving to board file.

Can someone test this?

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] sunxi: a64: Add verified-boot support

2017-11-08 Thread Jagan Teki
On Wed, Nov 8, 2017 at 4:25 PM, Maxime Ripard
 wrote:
> Hi,
>
> On Wed, Nov 08, 2017 at 12:40:05AM +0530, Jagan Teki wrote:
>> Enable verified-boot support for sunxi a64, tested the
>> same in orangepi boards.
>>
>> Signed-off-by: Jagan Teki 
>
> How was it tested? Can you write some documentation for it?

Thought of adding the same, will add in next version.

>
>> ---
>>  arch/arm/mach-sunxi/Kconfig| 2 ++
>>  include/configs/sunxi-common.h | 2 ++
>>  2 files changed, 4 insertions(+)
>>
>> diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
>> index 09cfec6..cf6b264 100644
>> --- a/arch/arm/mach-sunxi/Kconfig
>> +++ b/arch/arm/mach-sunxi/Kconfig
>> @@ -178,6 +178,8 @@ config MACH_SUN50I
>>   select SUNXI_DRAM_DW
>>   select SUNXI_DRAM_DW_32BIT
>>   select FIT
>> + select FIT_SIGNATURE
>
> I'd rather not select it, given the recent issues with the binary
> size, and the fact that this has been tested only on one, quite
> recent, SoC so far.
>
> How about an imply? or a default y?
>
>> + select FIT_VERBOSE
>
> Why do you need this?

I usually used this(even with other SOC) for debug messages if FIT
image fail to load.

>
>>   select SPL_LOAD_FIT
>>
>>  config MACH_SUN50I_H5
>> diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
>> index 4207398..921eb4f 100644
>> --- a/include/configs/sunxi-common.h
>> +++ b/include/configs/sunxi-common.h
>> @@ -34,6 +34,8 @@
>>
>>  #ifdef CONFIG_ARM64
>>  #define CONFIG_BUILD_TARGET "u-boot.itb"
>> +/* Extend size of kernel image for uncompression */
>> +#define CONFIG_SYS_BOOTM_LEN (60 * 1024 * 1024)
>
> I thought the arm64 kernels were uncompressed?

I've tested with Image.gz

>
> That should probably be in a separate patch anyway.

Yes, will send in it another patch.

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [U-Boot, 7/9] ARM: dts: rockchip: Add usb host for rk3288-vyasa

2017-11-08 Thread Jagan Teki
On Wed, Nov 8, 2017 at 4:24 PM, Philipp Tomsich
 wrote:
>
>
> On Sat, 4 Nov 2017, Jagan Teki wrote:
>
>> Add usb host support for rk3288-vyasa, board support hub power
>> through phy_pwr_en and usb2 host power through usb2_pwr_en and
>> naming conversion followed as per schematic.
>>
>> Signed-off-by: Jagan Teki 
>> ---
>> arch/arm/dts/rk3288-vyasa.dts  | 48
>> ++
>> include/dt-bindings/pinctrl/rockchip.h |  1 +
>> 2 files changed, 49 insertions(+)
>>
>> diff --git a/arch/arm/dts/rk3288-vyasa.dts b/arch/arm/dts/rk3288-vyasa.dts
>> index 47fdd91..4113687 100644
>> --- a/arch/arm/dts/rk3288-vyasa.dts
>> +++ b/arch/arm/dts/rk3288-vyasa.dts
>> @@ -105,6 +105,30 @@
>> vin-supply = <_vbat>;
>> };
>>
>> +   vsus_5v: vsus-5v {
>> +   compatible = "regulator-fixed";
>> +   regulator-name = "vsus_5v";
>> +   regulator-min-microvolt = <500>;
>> +   regulator-max-microvolt = <500>;
>> +   regulator-always-on;
>> +   regulator-boot-on;
>> +   vin-supply = <_io>;
>> +   };
>> +
>> +   vusb2_5v: vusb2-5v {
>> +   compatible = "regulator-fixed";
>> +   regulator-name = "vusb2_5v";
>> +   enable-active-high;
>> +   gpio = < RK_PB1 GPIO_ACTIVE_HIGH>; /* USB2_PWR_EN */
>> +   pinctrl-names = "default";
>> +   pinctrl-0 = <_pwr_en>;
>> +   regulator-min-microvolt = <500>;
>> +   regulator-max-microvolt = <500>;
>> +   regulator-always-on;
>> +   regulator-boot-on;
>> +   vin-supply = <_5v>;
>> +   };
>> +
>> ext_gmac: external-gmac-clock {
>> compatible = "fixed-clock";
>> #clock-cells = <0>;
>> @@ -357,6 +381,20 @@
>> status = "okay";
>> };
>>
>> + {
>> +   status = "okay";
>> +};
>> +
>> +_host0_ehci {
>> +   status = "okay";
>> +};
>> +
>> +_host1 {
>> +   pinctrl-names = "default";
>> +   pinctrl-0 = <_pwr_en>;
>> +   status = "okay";
>> +};
>> +
>>  {
>> status = "okay";
>> };
>> @@ -401,4 +439,14 @@
>> rockchip,pins = > _pull_up>;
>> };
>> };
>> +
>> +   usb_host {
>> +   phy_pwr_en: phy-pwr-en {
>> +   rockchip,pins = > _output_high>;
>> +   };
>> +
>> +   usb2_pwr_en: usb2-pwr-en {
>> +   rockchip,pins = > _pull_none>;
>> +   };
>> +   };
>> };
>> diff --git a/include/dt-bindings/pinctrl/rockchip.h
>> b/include/dt-bindings/pinctrl/rockchip.h
>> index 0798287..fb59d23 100644
>> --- a/include/dt-bindings/pinctrl/rockchip.h
>> +++ b/include/dt-bindings/pinctrl/rockchip.h
>> @@ -16,6 +16,7 @@
>> #define RK_GPIO33
>> #define RK_GPIO44
>> #define RK_GPIO66
>> +#define RK_GPIO8   8
>
>
> This file is shared with Linux (and the way I understand it, the Linux side
> is leading): has the same already been committed on the Linux side?

Yeah, it's committed in linux-next.

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH] power: pmic/regulator: Add basic support for TPS65910

2017-11-08 Thread Felix Brack
Texas Instrument's TPS65910 PMIC contains 3 buck DC-DC converts, one
boost DC-DC converter and 8 LDOs. This patch implements driver model
support for the TPS65910 PMIC and its regulators making the get/set
API for regulator value/enable available.
This patch depends on the patch "am33xx: Add a function to query MPU
voltage in uV" to build correctly. For boards relying on the DT
include file tps65910.dtsi the v2 patch "power: extend prefix match
to regulator-name property" and an appropriate regulator naming is
also required.

Signed-off-by: Felix Brack 
---

 drivers/power/pmic/Kconfig   |   8 +
 drivers/power/pmic/Makefile  |   1 +
 drivers/power/pmic/pmic_tps65910_dm.c| 138 
 drivers/power/regulator/Kconfig  |   7 +
 drivers/power/regulator/Makefile |   1 +
 drivers/power/regulator/tps65910_regulator.c | 493 +++
 include/power/tps65910_pmic.h| 130 +++
 7 files changed, 778 insertions(+)
 create mode 100644 drivers/power/pmic/pmic_tps65910_dm.c
 create mode 100644 drivers/power/regulator/tps65910_regulator.c
 create mode 100644 include/power/tps65910_pmic.h

diff --git a/drivers/power/pmic/Kconfig b/drivers/power/pmic/Kconfig
index e3f9e4d..5d49c93 100644
--- a/drivers/power/pmic/Kconfig
+++ b/drivers/power/pmic/Kconfig
@@ -201,3 +201,11 @@ config POWER_MC34VR500
The MC34VR500 is used in conjunction with the FSL T1 and LS1 series
SoC. It provides 4 buck DC-DC convertors and 5 LDOs, and it is accessed
via an I2C interface.
+
+config DM_PMIC_TPS65910
+   bool "Enable driver for Texas Instruments TPS65910 PMIC"
+   depends on DM_PMIC
+   ---help---
+   The TPS65910 is a PMIC containing 3 buck DC-DC converters, one boost
+   DC-DC converter, 8 LDOs and a RTC. This driver binds the SMPS and LDO
+   pmic children.
diff --git a/drivers/power/pmic/Makefile b/drivers/power/pmic/Makefile
index f7bdfa5..7d6c583 100644
--- a/drivers/power/pmic/Makefile
+++ b/drivers/power/pmic/Makefile
@@ -19,6 +19,7 @@ obj-$(CONFIG_PMIC_RK8XX) += rk8xx.o
 obj-$(CONFIG_PMIC_RN5T567) += rn5t567.o
 obj-$(CONFIG_PMIC_TPS65090) += tps65090.o
 obj-$(CONFIG_PMIC_S5M8767) += s5m8767.o
+obj-$(CONFIG_DM_PMIC_TPS65910) += pmic_tps65910_dm.o
 obj-$(CONFIG_$(SPL_)PMIC_PALMAS) += palmas.o
 obj-$(CONFIG_$(SPL_)PMIC_LP873X) += lp873x.o
 obj-$(CONFIG_$(SPL_)PMIC_LP87565) += lp87565.o
diff --git a/drivers/power/pmic/pmic_tps65910_dm.c 
b/drivers/power/pmic/pmic_tps65910_dm.c
new file mode 100644
index 000..1410657
--- /dev/null
+++ b/drivers/power/pmic/pmic_tps65910_dm.c
@@ -0,0 +1,138 @@
+/*
+ * Copyright (C) EETS GmbH, 2017, Felix Brack 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+static const struct pmic_child_info pmic_children_info[] = {
+   { .prefix = "ldo_", .driver = TPS65910_LDO_DRIVER },
+   { .prefix = "buck_", .driver = TPS65910_BUCK_DRIVER },
+   { .prefix = "boost_", .driver = TPS65910_BOOST_DRIVER },
+   { },
+};
+
+static const char * const supply_names[] = {
+   "vccio-supply",
+   "vcc1-supply",
+   "vcc2-supply",
+   "vcc3-supply",
+   "vcc4-supply",
+   "vcc5-supply",
+   "vcc6-supply",
+   "vcc7-supply",
+};
+
+static int pmic_tps65910_reg_count(struct udevice *dev)
+{
+   return TPS65910_NUM_REGS;
+}
+
+static int pmic_tps65910_write(struct udevice *dev, uint reg, const u8 *buffer,
+  int len)
+{
+   if (dm_i2c_write(dev, reg, buffer, len)) {
+   error("%s write error on register %02x\n", dev->name, reg);
+   return -EIO;
+   }
+
+   return 0;
+}
+
+static int pmic_tps65910_read(struct udevice *dev, uint reg, u8 *buffer,
+ int len)
+{
+   if (dm_i2c_read(dev, reg, buffer, len)) {
+   error("%s read error on register %02x\n", dev->name, reg);
+   return -EIO;
+   }
+
+   return 0;
+}
+
+static int pmic_tps65910_bind(struct udevice *dev)
+{
+   ofnode regulators_node;
+   int children;
+
+   regulators_node = dev_read_subnode(dev, "regulators");
+   if (!ofnode_valid(regulators_node)) {
+   debug("%s regulators subnode not found\n", dev->name);
+   return -ENXIO;
+   }
+
+   children = pmic_bind_children(dev, regulators_node, pmic_children_info);
+   if (!children)
+   debug("%s has no children (regulators)\n", dev->name);
+
+   return 0;
+}
+
+static int pmic_tps65910_probe(struct udevice *dev)
+{
+   /* use I2C control interface instead of I2C smartreflex interface to
+* access smartrefelex registers VDD1_OP_REG, VDD1_SR_REG, VDD2_OP_REG
+* and VDD2_SR_REG
+*/
+   return pmic_clrsetbits(dev, TPS65910_REG_DEVICE_CTRL, 0,
+  

Re: [U-Boot] [U-Boot, 7/9] ARM: dts: rockchip: Add usb host for rk3288-vyasa

2017-11-08 Thread Philipp Tomsich



On Sat, 4 Nov 2017, Jagan Teki wrote:


Add usb host support for rk3288-vyasa, board support hub power
through phy_pwr_en and usb2 host power through usb2_pwr_en and
naming conversion followed as per schematic.

Signed-off-by: Jagan Teki 
---
arch/arm/dts/rk3288-vyasa.dts  | 48 ++
include/dt-bindings/pinctrl/rockchip.h |  1 +
2 files changed, 49 insertions(+)

diff --git a/arch/arm/dts/rk3288-vyasa.dts b/arch/arm/dts/rk3288-vyasa.dts
index 47fdd91..4113687 100644
--- a/arch/arm/dts/rk3288-vyasa.dts
+++ b/arch/arm/dts/rk3288-vyasa.dts
@@ -105,6 +105,30 @@
vin-supply = <_vbat>;
};

+   vsus_5v: vsus-5v {
+   compatible = "regulator-fixed";
+   regulator-name = "vsus_5v";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   regulator-always-on;
+   regulator-boot-on;
+   vin-supply = <_io>;
+   };
+
+   vusb2_5v: vusb2-5v {
+   compatible = "regulator-fixed";
+   regulator-name = "vusb2_5v";
+   enable-active-high;
+   gpio = < RK_PB1 GPIO_ACTIVE_HIGH>; /* USB2_PWR_EN */
+   pinctrl-names = "default";
+   pinctrl-0 = <_pwr_en>;
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   regulator-always-on;
+   regulator-boot-on;
+   vin-supply = <_5v>;
+   };
+
ext_gmac: external-gmac-clock {
compatible = "fixed-clock";
#clock-cells = <0>;
@@ -357,6 +381,20 @@
status = "okay";
};

+ {
+   status = "okay";
+};
+
+_host0_ehci {
+   status = "okay";
+};
+
+_host1 {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pwr_en>;
+   status = "okay";
+};
+
 {
status = "okay";
};
@@ -401,4 +439,14 @@
rockchip,pins = ;
};
};
+
+   usb_host {
+   phy_pwr_en: phy-pwr-en {
+   rockchip,pins = ;
+   };
+
+   usb2_pwr_en: usb2-pwr-en {
+   rockchip,pins = ;
+   };
+   };
};
diff --git a/include/dt-bindings/pinctrl/rockchip.h 
b/include/dt-bindings/pinctrl/rockchip.h
index 0798287..fb59d23 100644
--- a/include/dt-bindings/pinctrl/rockchip.h
+++ b/include/dt-bindings/pinctrl/rockchip.h
@@ -16,6 +16,7 @@
#define RK_GPIO33
#define RK_GPIO44
#define RK_GPIO66
+#define RK_GPIO8   8


This file is shared with Linux (and the way I understand it, the Linux 
side is leading): has the same already been committed on the Linux side?




#define RK_PA0  0
#define RK_PA1  1


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


Re: [U-Boot] [U-Boot, 5/9] ARM: dts: rockchip: Add gmac support for rk3288-vyasa board

2017-11-08 Thread Philipp Tomsich



On Sat, 4 Nov 2017, Jagan Teki wrote:


Signed-off-by: Jagan Teki 


Commit message?


---
arch/arm/dts/rk3288-vyasa.dts | 41 +
1 file changed, 41 insertions(+)

diff --git a/arch/arm/dts/rk3288-vyasa.dts b/arch/arm/dts/rk3288-vyasa.dts
index f56e10c..47fdd91 100644
--- a/arch/arm/dts/rk3288-vyasa.dts
+++ b/arch/arm/dts/rk3288-vyasa.dts
@@ -104,12 +104,35 @@
regulator-boot-on;
vin-supply = <_vbat>;
};
+
+   ext_gmac: external-gmac-clock {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <12500>;
+   clock-output-names = "ext_gmac";
+   };
};

 {
cpu0-supply = <_cpu>;
};

+ {
+   assigned-clocks = < SCLK_MAC>;
+   assigned-clock-parents = <_gmac>;
+   clock_in_out = "input";
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>, <_rst>, <_pmeb>, <_int>;
+   phy-supply = <_lan>;
+   phy-mode = "rgmii";
+   snps,reset-active-low;
+   snps,reset-delays-us = <0 1 100>;
+   snps,reset-gpio = < RK_PB0 GPIO_ACTIVE_LOW>;
+   tx_delay = <0x30>;
+   rx_delay = <0x10>;
+   status = "okay";
+};
+
 {
mali-supply = <_gpu>;
status = "okay";
@@ -355,6 +378,24 @@
};

 {
+   pcfg_output_high: pcfg-output-high {
+   output-high;
+   };
+
+   gmac {
+   phy_int: phy-int {
+   rockchip,pins = <0 RK_PB1 RK_FUNC_GPIO _pull_up>;
+   };
+
+   phy_pmeb: phy-pmeb {
+   rockchip,pins = <0 RK_PA6 RK_FUNC_GPIO _pull_up>;
+   };
+
+   phy_rst: phy-rst {
+   rockchip,pins = <4 RK_PB0 RK_FUNC_GPIO 
_output_high>;
+   };
+   };
+
pmic {
pmic_int: pmic-int {
rockchip,pins = ;


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


Re: [U-Boot] [PATCH] sunxi: a64: Add verified-boot support

2017-11-08 Thread Maxime Ripard
Hi,

On Wed, Nov 08, 2017 at 12:40:05AM +0530, Jagan Teki wrote:
> Enable verified-boot support for sunxi a64, tested the
> same in orangepi boards.
> 
> Signed-off-by: Jagan Teki 

How was it tested? Can you write some documentation for it?

> ---
>  arch/arm/mach-sunxi/Kconfig| 2 ++
>  include/configs/sunxi-common.h | 2 ++
>  2 files changed, 4 insertions(+)
> 
> diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> index 09cfec6..cf6b264 100644
> --- a/arch/arm/mach-sunxi/Kconfig
> +++ b/arch/arm/mach-sunxi/Kconfig
> @@ -178,6 +178,8 @@ config MACH_SUN50I
>   select SUNXI_DRAM_DW
>   select SUNXI_DRAM_DW_32BIT
>   select FIT
> + select FIT_SIGNATURE

I'd rather not select it, given the recent issues with the binary
size, and the fact that this has been tested only on one, quite
recent, SoC so far.

How about an imply? or a default y?

> + select FIT_VERBOSE

Why do you need this?

>   select SPL_LOAD_FIT
>  
>  config MACH_SUN50I_H5
> diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
> index 4207398..921eb4f 100644
> --- a/include/configs/sunxi-common.h
> +++ b/include/configs/sunxi-common.h
> @@ -34,6 +34,8 @@
>  
>  #ifdef CONFIG_ARM64
>  #define CONFIG_BUILD_TARGET "u-boot.itb"
> +/* Extend size of kernel image for uncompression */
> +#define CONFIG_SYS_BOOTM_LEN (60 * 1024 * 1024)

I thought the arm64 kernels were uncompressed?

That should probably be in a separate patch anyway.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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


Re: [U-Boot] [U-Boot, 4/9] ARM: dts: rockchip: Add regulators for rk3288-vyasa

2017-11-08 Thread Philipp Tomsich
> Add supporting regulators for rk3288-vyasa board, dc12_vbat is
> parent regulatorand followed regulators as are child regulators.
> regulator naming conversion followed as per schematic for better
> readability and easy for identification.
> 
> Signed-off-by: Jagan Teki 
> ---
>  arch/arm/dts/rk3288-vyasa.dts | 40 
>  1 file changed, 40 insertions(+)
> 

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


Re: [U-Boot] [U-Boot, 9/9] rockchip: rk3288-vyasa: defconfig: Enable USB host and otg

2017-11-08 Thread Philipp Tomsich
> Enable USB host and otg for rk3288-vyasa board.
> 
> Signed-off-by: Jagan Teki 
> ---
>  configs/vyasa-rk3288_defconfig | 13 +
>  1 file changed, 13 insertions(+)
> 

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


Re: [U-Boot] [U-Boot, 8/9] ARM: dts: rockchip: Add usb otg for rk3288-vyasa

2017-11-08 Thread Philipp Tomsich
> Add usb otg support for rk3288-vyasa, board support usb1 otg
> power through otg_vbus_drv and naming conversion followed
> as per schematic.
> 
> Signed-off-by: Jagan Teki 
> ---
>  arch/arm/dts/rk3288-vyasa.dts | 25 +
>  1 file changed, 25 insertions(+)
> 

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


Re: [U-Boot] [U-Boot, 6/9] rockchip: rk3288-vyasa: defconfig: Enable gmac support

2017-11-08 Thread Philipp Tomsich
> Enable gmac support for rk3288-vyasa board.
> 
> Signed-off-by: Jagan Teki 
> ---
>  configs/vyasa-rk3288_defconfig | 3 +++
>  1 file changed, 3 insertions(+)
> 

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


Re: [U-Boot] [U-Boot, 2/9] ARM: dts: rockchip: rk3288-vyasa: Remove vdd_log from rk808, DCDC_REG1

2017-11-08 Thread Philipp Tomsich
> vdd_log, never used on DCDC_REG1 of rk808 from latest schematic so
> remove the same and update the regulator-name as 'vdd_arm' to sync
> with existing rk3288 board dts files.
> 
> Signed-off-by: Jagan Teki 
> ---
>  arch/arm/dts/rk3288-vyasa.dts | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 

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


Re: [U-Boot] [U-Boot, 1/9] ARM: dts: rockchip: Sync rk3288-vyasa dts from Linux

2017-11-08 Thread Philipp Tomsich
> Sync rk3288-vyasa board dts from Linux for proper updates and maintenance
> - rk3288-vyasa.dts: Similar to Linux dts
> - rk3288-vyasa-u-boot.dtsi: u-boot dts changes
> 
> Also updated MAINTAINERS for these dts files.
> 
> Signed-off-by: Jagan Teki 
> ---
>  arch/arm/dts/rk3288-vyasa-u-boot.dtsi  |  65 
>  arch/arm/dts/rk3288-vyasa.dts  | 134 
> ++---
>  board/amarula/vyasa-rk3288/MAINTAINERS |   2 +
>  3 files changed, 141 insertions(+), 60 deletions(-)
>  create mode 100644 arch/arm/dts/rk3288-vyasa-u-boot.dtsi
> 

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


Re: [U-Boot] [U-Boot, 8/9] ARM: dts: rockchip: Add usb otg for rk3288-vyasa

2017-11-08 Thread Philipp Tomsich
> Add usb otg support for rk3288-vyasa, board support usb1 otg
> power through otg_vbus_drv and naming conversion followed
> as per schematic.
> 
> Signed-off-by: Jagan Teki 
> ---
>  arch/arm/dts/rk3288-vyasa.dts | 25 +
>  1 file changed, 25 insertions(+)
> 

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


Re: [U-Boot] [U-Boot, 5/9] ARM: dts: rockchip: Add gmac support for rk3288-vyasa board

2017-11-08 Thread Philipp Tomsich
> Signed-off-by: Jagan Teki 
> ---
>  arch/arm/dts/rk3288-vyasa.dts | 41 +
>  1 file changed, 41 insertions(+)
> 

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


Re: [U-Boot] [U-Boot, 3/9] ARM: dts: rockchip: rk3288-vyasa: Use vmmc-supply from PMIC

2017-11-08 Thread Philipp Tomsich
> rk808, SWITCH_REG1 has configured for sdmmc regulator as vcc_sd,
> so use the same by renaming vcc33_sd to vcc_sd(as per schematic)
> and drop explicit regulator definition from root.
> 
> Signed-off-by: Jagan Teki 
> ---
>  arch/arm/dts/rk3288-vyasa.dts | 22 ++
>  1 file changed, 2 insertions(+), 20 deletions(-)
> 

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


Re: [U-Boot] [U-Boot, 6/9] rockchip: rk3288-vyasa: defconfig: Enable gmac support

2017-11-08 Thread Philipp Tomsich
> Enable gmac support for rk3288-vyasa board.
> 
> Signed-off-by: Jagan Teki 
> ---
>  configs/vyasa-rk3288_defconfig | 3 +++
>  1 file changed, 3 insertions(+)
> 

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


Re: [U-Boot] [U-Boot, 7/9] ARM: dts: rockchip: Add usb host for rk3288-vyasa

2017-11-08 Thread Philipp Tomsich
> Add usb host support for rk3288-vyasa, board support hub power
> through phy_pwr_en and usb2 host power through usb2_pwr_en and
> naming conversion followed as per schematic.
> 
> Signed-off-by: Jagan Teki 
> ---
>  arch/arm/dts/rk3288-vyasa.dts  | 48 
> ++
>  include/dt-bindings/pinctrl/rockchip.h |  1 +
>  2 files changed, 49 insertions(+)
> 

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


Re: [U-Boot] [U-Boot, 9/9] rockchip: rk3288-vyasa: defconfig: Enable USB host and otg

2017-11-08 Thread Philipp Tomsich
> Enable USB host and otg for rk3288-vyasa board.
> 
> Signed-off-by: Jagan Teki 
> ---
>  configs/vyasa-rk3288_defconfig | 13 +
>  1 file changed, 13 insertions(+)
> 

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


Re: [U-Boot] [U-Boot, 3/9] ARM: dts: rockchip: rk3288-vyasa: Use vmmc-supply from PMIC

2017-11-08 Thread Philipp Tomsich
> rk808, SWITCH_REG1 has configured for sdmmc regulator as vcc_sd,
> so use the same by renaming vcc33_sd to vcc_sd(as per schematic)
> and drop explicit regulator definition from root.
> 
> Signed-off-by: Jagan Teki 
> ---
>  arch/arm/dts/rk3288-vyasa.dts | 22 ++
>  1 file changed, 2 insertions(+), 20 deletions(-)
> 

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


  1   2   >