date:20190430

On Wed, May 01, 2019 at 12:56:30AM +, Joe Hershberger wrote:
> On Tue, Apr 30, 2019 at 4:29 PM Tom Rini  wrote:
> >
> > On Tue, Apr 30, 2019 at 09:15:33PM +, Joe Hershberger wrote:
> > > On Tue, Mar 19, 2019 at 5:41 PM Tom Rini  wrote:
> > > >
> > > > On Tue, Mar 12, 2019 at 01:15:46PM -0500, Joe Hershberger wrote:
> > > >
> > > > > Hi Tom,
> > > > >
> > > > > These patches passed the CI build here: 
> > > > > https://travis-ci.org/jhershbe/u-boot/builds/501807294
> > > > >
> > > > > The following changes since commit 
> > > > > 2e8092d94f40a5692baf3ec768ce3216a7bf032a:
> > > > >
> > > > >   Merge branch 'master' of git://git.denx.de/u-boot-sunxi (2019-03-11 
> > > > > 15:48:57 -0400)
> > > > >
> > > > > are available in the git repository at:
> > > > >
> > > > >
> > > > >   git://git.denx.de/u-boot-net.git master
> > > > >
> > > > > for you to fetch changes up to 
> > > > > 85f05f72bacc2d047731fc64801e4f6b34cf:
> > > > >
> > > > >   net: phy: aquantia: Set only autoneg on in register 4.c441 
> > > > > (2019-03-12 13:13:37 -0500)
> > > > >
> > > >
> > > > NAK.  One of:
> > > > The first bad commit could be any of:
> > > > 30b2ca2e0fa274b875bb56f541b7dd33ce93c1d1
> > > > 8860e1563f38d16f7ae29053018cd445c0fa111d
> > > > ebb5027d69196dd83fd0fa5bd91fca07acfd77be
> > > > 09e0a36497c84273e5b22488d5af01bf0ba17469
> > > > 841b9df209e37fe1bfefa5f44e837a0ad497443f
> > > > 15e67d1cdc7258c0c07ad1fd6c2818f7e9f52447
> > > > 7aadf5134f2f5771689d0657b69875d0a464859d
> > > > d35488518f3c16d305092c816a5129f45a0b62d7
> > > > Breaks am335x_evm ethernet:
> > > > 18:39:52 => => dhcp
> > > > 18:39:52 ethernet@4a10 Waiting for PHY auto negotiation to
> > > > complete... done
> > > > 18:39:52 link up on port 0, speed 1000, full duplex
> > > > 18:39:52 BOOTP broadcast 1
> > > > 18:39:52 BOOTP broadcast 2
> > > > 18:39:52 BOOTP broadcast 3
> > > > 18:39:52 BOOTP broadcast 4
> > > > 18:39:52 BOOTP broadcast 5
> > > > 18:39:52 BOOTP broadcast 6
> > > > 18:39:52 BOOTP broadcast 7
> > > > 18:39:52 BOOTP broadcast 8
> > > > 18:39:52 BOOTP broadcast 9
> > > > 18:39:52 BOOTP broadcast 10
> > > > 18:39:52 BOOTP broadcast 11
> > > > 18:39:52 BOOTP broadcast 12
> > > > 18:39:52 BOOTP broadcast 13
> > > > 18:39:52 BOOTP broadcast 14
> > > > 18:39:52 BOOTP broadcast 15
> > > > 18:39:52 BOOTP broadcast 16
> > > > 18:39:52 BOOTP broadcast 17
> > >
> > > I rebased the series on the current master and I can't reproduce this
> > > dhcp issue. On the original series I saw broken DHCP only with "net:
> > > phy: micrel: Use correct skew values on KSZ9021" which doesn't make
> > > any sense because that phy is not used on BBB and isn't even compiled
> > > in. Also, the issue doesn't reproduce when the next patch is applied.
> > > Even that oddity doesn't happen after the rebase.
> > >
> > > Also the SPL for boneblack is too big to build with some of the
> > > patches in this series now, so I'm not sure how that should be
> > > handled.
> >
> > Drop those parts for now I guess and we'll have to look harder at them
> > stand-alone?  And I assume you mean am335x_boneblack_vboot is too large?
> > Or am335x_evm itself?  Thanks!
> 
> Meaning the SPL part of am335x_evm target fails by a few hundred bytes.

I need to grab the series that shaves a few hundred bytes I think then
from SPL for am335x.

-- 
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] Pull request: u-boot-net.git master

2019-04-30 Thread Joe Hershberger

On Tue, Apr 30, 2019 at 4:29 PM Tom Rini  wrote:
>
> On Tue, Apr 30, 2019 at 09:15:33PM +, Joe Hershberger wrote:
> > On Tue, Mar 19, 2019 at 5:41 PM Tom Rini  wrote:
> > >
> > > On Tue, Mar 12, 2019 at 01:15:46PM -0500, Joe Hershberger wrote:
> > >
> > > > Hi Tom,
> > > >
> > > > These patches passed the CI build here: 
> > > > https://travis-ci.org/jhershbe/u-boot/builds/501807294
> > > >
> > > > The following changes since commit 
> > > > 2e8092d94f40a5692baf3ec768ce3216a7bf032a:
> > > >
> > > >   Merge branch 'master' of git://git.denx.de/u-boot-sunxi (2019-03-11 
> > > > 15:48:57 -0400)
> > > >
> > > > are available in the git repository at:
> > > >
> > > >
> > > >   git://git.denx.de/u-boot-net.git master
> > > >
> > > > for you to fetch changes up to 85f05f72bacc2d047731fc64801e4f6b34cf:
> > > >
> > > >   net: phy: aquantia: Set only autoneg on in register 4.c441 
> > > > (2019-03-12 13:13:37 -0500)
> > > >
> > >
> > > NAK.  One of:
> > > The first bad commit could be any of:
> > > 30b2ca2e0fa274b875bb56f541b7dd33ce93c1d1
> > > 8860e1563f38d16f7ae29053018cd445c0fa111d
> > > ebb5027d69196dd83fd0fa5bd91fca07acfd77be
> > > 09e0a36497c84273e5b22488d5af01bf0ba17469
> > > 841b9df209e37fe1bfefa5f44e837a0ad497443f
> > > 15e67d1cdc7258c0c07ad1fd6c2818f7e9f52447
> > > 7aadf5134f2f5771689d0657b69875d0a464859d
> > > d35488518f3c16d305092c816a5129f45a0b62d7
> > > Breaks am335x_evm ethernet:
> > > 18:39:52 => => dhcp
> > > 18:39:52 ethernet@4a10 Waiting for PHY auto negotiation to
> > > complete... done
> > > 18:39:52 link up on port 0, speed 1000, full duplex
> > > 18:39:52 BOOTP broadcast 1
> > > 18:39:52 BOOTP broadcast 2
> > > 18:39:52 BOOTP broadcast 3
> > > 18:39:52 BOOTP broadcast 4
> > > 18:39:52 BOOTP broadcast 5
> > > 18:39:52 BOOTP broadcast 6
> > > 18:39:52 BOOTP broadcast 7
> > > 18:39:52 BOOTP broadcast 8
> > > 18:39:52 BOOTP broadcast 9
> > > 18:39:52 BOOTP broadcast 10
> > > 18:39:52 BOOTP broadcast 11
> > > 18:39:52 BOOTP broadcast 12
> > > 18:39:52 BOOTP broadcast 13
> > > 18:39:52 BOOTP broadcast 14
> > > 18:39:52 BOOTP broadcast 15
> > > 18:39:52 BOOTP broadcast 16
> > > 18:39:52 BOOTP broadcast 17
> >
> > I rebased the series on the current master and I can't reproduce this
> > dhcp issue. On the original series I saw broken DHCP only with "net:
> > phy: micrel: Use correct skew values on KSZ9021" which doesn't make
> > any sense because that phy is not used on BBB and isn't even compiled
> > in. Also, the issue doesn't reproduce when the next patch is applied.
> > Even that oddity doesn't happen after the rebase.
> >
> > Also the SPL for boneblack is too big to build with some of the
> > patches in this series now, so I'm not sure how that should be
> > handled.
>
> Drop those parts for now I guess and we'll have to look harder at them
> stand-alone?  And I assume you mean am335x_boneblack_vboot is too large?
> Or am335x_evm itself?  Thanks!

Meaning the SPL part of am335x_evm target fails by a few hundred bytes.

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

Re: [U-Boot] [PATCH 1/2 v2] fit: Support compression for non-kernel components (e.g. FDT)

2019-04-30 Thread Julius Werner

On Tue, Apr 30, 2019 at 11:25 AM Simon Goldschmidt
 wrote:
>
> Am 18.04.2019 um 23:08 schrieb Julius Werner:
> > This patch adds support for compressing non-kernel image nodes in a FIT
> > image (kernel nodes could already be compressed previously). This can
> > reduce the size of FIT images and therefore improve boot times
> > (especially when an image bundles many different kernel FDTs). The
> > images will automatically be decompressed on load.
> >
> > This patch does not support extracting compatible strings from
> > compressed FDTs, so it's not very helpful in conjunction with
> > CONFIG_FIT_BEST_MATCH yet, but it can already be used in environments
> > that select the configuration to load explicitly.
> >
> > Signed-off-by: Julius Werner 
> > ---
> >   common/image-fit.c | 83 +++---
> >   1 file changed, 49 insertions(+), 34 deletions(-)
> >
> > diff --git a/common/image-fit.c b/common/image-fit.c
> > index ac901e131c..006e828b79 100644
> > --- a/common/image-fit.c
> > +++ b/common/image-fit.c
> > @@ -22,6 +22,7 @@
> >   DECLARE_GLOBAL_DATA_PTR;
> >   #endif /* !USE_HOSTCC*/
> >
> > +#include 
> >   #include 
> >   #include 
> >   #include 
> > @@ -1576,6 +1577,13 @@ int fit_conf_find_compat(const void *fit, const void 
> > *fdt)
> > kfdt_name);
> >   continue;
> >   }
> > +
> > + if (!fit_image_check_comp(fit, kfdt_noffset, IH_COMP_NONE)) {
> > + debug("Can't extract compat from \"%s\" 
> > (compressed)\n",
> > +   kfdt_name);
> > + continue;
> > + }
> > +
>
> What's this block good for in this patch? Looks like it belongs to 2/2?

This is necessary because I'm removing the (image_type ==
IH_TYPE_FLATDT && !fit_image_check_comp(fit, noffset, IH_COMP_NONE))
check below. Previously, this function would just always hard fail
with compressed FDTs. With this patch, compressed FDTs can be loaded,
but they can't be used for compat string matching -- that's why I need
to add this check here to prevent it. You can still use compressed
FDTs when selecting a configuration explicitly (e.g. bootm
0x100#conf@1). The next patch will then add another feature that
makes it possible to have compat string matching with compressed FDTs.

>
> >   /*
> >* Get a pointer to this configuration's fdt.
> >*/
> > @@ -1795,11 +1803,12 @@ int fit_image_load(bootm_headers_t *images, ulong 
> > addr,
> >   const char *fit_uname_config;
> >   const char *fit_base_uname_config;
> >   const void *fit;
> > - const void *buf;
> > + void *buf;
> > + void *loadbuf;
> >   size_t size;
> >   int type_ok, os_ok;
> > - ulong load, data, len;
> > - uint8_t os;
> > + ulong load, load_end, data, len;
> > + uint8_t os, comp;
> >   #ifndef USE_HOSTCC
> >   uint8_t os_arch;
> >   #endif
> > @@ -1895,12 +1904,6 @@ int fit_image_load(bootm_headers_t *images, ulong 
> > addr,
> >   images->os.arch = os_arch;
> >   #endif
> >
> > - if (image_type == IH_TYPE_FLATDT &&
> > - !fit_image_check_comp(fit, noffset, IH_COMP_NONE)) {
> > - puts("FDT image is compressed");
> > - return -EPROTONOSUPPORT;
> > - }
> > -
> >   bootstage_mark(bootstage_id + BOOTSTAGE_SUB_CHECK_ALL);
> >   type_ok = fit_image_check_type(fit, noffset, image_type) ||
> > fit_image_check_type(fit, noffset, IH_TYPE_FIRMWARE) ||
> > @@ -1931,7 +1934,8 @@ int fit_image_load(bootm_headers_t *images, ulong 
> > addr,
> >   bootstage_mark(bootstage_id + BOOTSTAGE_SUB_CHECK_ALL_OK);
> >
> >   /* get image data address and length */
> > - if (fit_image_get_data_and_size(fit, noffset, , )) {
> > + if (fit_image_get_data_and_size(fit, noffset,
> > + (const void **), )) {
> >   printf("Could not find %s subimage data!\n", prop_name);
> >   bootstage_error(bootstage_id + BOOTSTAGE_SUB_GET_DATA);
> >   return -ENOENT;
> > @@ -1939,30 +1943,15 @@ int fit_image_load(bootm_headers_t *images, ulong 
> > addr,
> >
> >   #if !defined(USE_HOSTCC) && defined(CONFIG_FIT_IMAGE_POST_PROCESS)
> >   /* perform any post-processing on the image data */
> > - board_fit_image_post_process((void **), );
> > + board_fit_image_post_process(, );
> >   #endif
> >
> >   len = (ulong)size;
> >
> > - /* verify that image data is a proper FDT blob */
> > - if (image_type == IH_TYPE_FLATDT && fdt_check_header(buf)) {
> > - puts("Subimage data is not a FDT");
> > - return -ENOEXEC;
> > - }
> > -
> >   bootstage_mark(bootstage_id + BOOTSTAGE_SUB_GET_DATA_OK);
> >
> > - /*
> > -  * Work-around for eldk-4.2 which gives this warning if we try to
> > -  * cast in the unmap_sysmem() call:
> > -  * warning: initialization

Re: [U-Boot] [RESEND PATCH 0/3] arm: Introduce writel/readl_relaxed accessors

2019-04-30 Thread André Przywara

On 29/04/2019 18:16, Jagan Teki wrote:

Hi,

> On Sun, Feb 10, 2019 at 9:49 PM Andre Przywara  wrote:
>>
>> Hi, this is a resend of what I posted some weeks ago, just adding the
>> missing Signed-off-by: in patch 2/3, as pointed out by Philipp. I used
>> the opportunity to add his Reviewed-by: tags on the first two patches.
>> (Many thanks for that!) The rest is unchanged.
>> ---
>>
>> Admittedly this is the long way round to solve some nasty SPL code size
>> problem, but it looked beneficial to others as well, so here we go:
>>
>> arch/arm/include/asm/io.h looks like it's been around since the dawn of
>> time, and was more or less blindly copied from Linux.
>> We don't use and don't need most of the definitions, and mainline Linux
>> got rid of them anyway, so patch 1/3 cleans up this header file to
>> just contain what we need in U-Boot.
>>
>> Patch 2/3 introduces readl/writel_relaxed accessors, which are cheaper,
>> but more importantly save one (barrier) instruction per accessor. This
>> helps to bring down code size, since especially DRAM controller inits in
>> SPLs tend to do a lot of MMIO.
>>
>> Consequently patch 3/3 introduces them in the Allwinner H6 DRAM driver,
>> which reduces the SPL size by a whopping 2KB, due to a twist:
>> The AArch64 exception table needs to be 2KB aligned, but we don't do
>> anything special about it the linker script. So depending on where the
>> code before the vectors ends, we have potentially large padding:
>> At the moment this last address is 0x1824 for the H6, so the vectors can
>> only start at 0x2000. By reducing the code size before the vectors by just
>> (at least) 9 instructions, the vectors start at 0x1800 and we save most of
>> the padding.
>>
>> I understand that the proper solution is to fill the gap before the vectors
>> with code instead of NOPs, but I couldn't find any obvious way doing this
>> in the linker script. If anyone has any idea here, I am all ears.
>>
>> Cheers,
>> Andre.
>>
>> Andre Przywara (3):
>>   arm: clean up asm/io.h
>>   arm: introduce _relaxed MMIO accessors
>>   sunxi: H6: use writel_relaxed for DRAM timing register accesses
> 
> These have build issues with arm32, please send another series.

Thanks for the elaborate error report ;-)

There is commit 6478848d165b63293f7021db9b70ce25a1e1062c, which does
basically the same thing as patch 2/3 in this series and was merged by
Tom already. This causes the double definition.
So just dropping the middle patch from this series should do the trick.

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

Re: [U-Boot] [PATCH v2 2/2] RISCV: image: Parse Image.gz support in booti.

2019-04-30 Thread Atish Patra


On 4/30/19 2:42 PM, Marek Vasut wrote:

On 4/30/19 10:38 PM, Atish Patra wrote:

On 4/30/19 12:11 PM, Marek Vasut wrote:

On 4/30/19 8:13 PM, Atish Patra wrote:

On 4/30/19 2:52 AM, Marek Vasut wrote:

On 4/30/19 3:27 AM, Atish Patra wrote:

[...]


Yes. FIT image parsing can be done in that way. However, the idea
was
here to load Image.gz directly. Image.gz is default compressed Linux
kernel image format in RISC-V.


Sigh, and the image header is compressed as well, so there's no
way to
identify the image format, right ? And there's no decompressor, so
the
dcompressing has to be done by bootloader, which would need some
sort of
very smart way of figuring out which exact compression method is
used ?


Yes. Image.gz is always gunzip. So checking first two bytes is
enough to
confirm that it is a gz file.


What happens once people start feeding it more exotic compression
methods, like LZ4 or LZO or LZMA for example ?



booti command help will clearly state that it can only boot kernel from
Image or Image.gz.

static char booti_help_text[] =
   "[addr [initrd[:size]] [fdt]]\n"
-    "    - boot arm64 Linux Image stored in memory\n"
+    "    - boot arm64 Linux Image or riscv Linux Image/Image.gz stored
in memory\n"


Obvious question -- does this Image.gz stuff apply to arm64 ?



arm64 builds Image.gz but booti for arm64 doesn't use it. I guess
Image.gz can be used in FIT image for ARM64 but I am not sure which
platform actually uses it.

This patch only enables support for RISC-V.


Can't this be made generic ?



I think so if I just move the gzip detection and decompression code to 
cmd/booti.c.


I will update the v3 patch with this.

Regards,
Atish


[...]



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

Re: [U-Boot] [PATCH v2 2/2] RISCV: image: Parse Image.gz support in booti.

On 4/30/19 10:38 PM, Atish Patra wrote:
> On 4/30/19 12:11 PM, Marek Vasut wrote:
>> On 4/30/19 8:13 PM, Atish Patra wrote:
>>> On 4/30/19 2:52 AM, Marek Vasut wrote:
 On 4/30/19 3:27 AM, Atish Patra wrote:

 [...]

>>> Yes. FIT image parsing can be done in that way. However, the idea
>>> was
>>> here to load Image.gz directly. Image.gz is default compressed Linux
>>> kernel image format in RISC-V.
>>
>> Sigh, and the image header is compressed as well, so there's no
>> way to
>> identify the image format, right ? And there's no decompressor, so
>> the
>> dcompressing has to be done by bootloader, which would need some
>> sort of
>> very smart way of figuring out which exact compression method is
>> used ?
>>
> Yes. Image.gz is always gunzip. So checking first two bytes is
> enough to
> confirm that it is a gz file.

 What happens once people start feeding it more exotic compression
 methods, like LZ4 or LZO or LZMA for example ?

>>>
>>> booti command help will clearly state that it can only boot kernel from
>>> Image or Image.gz.
>>>
>>> static char booti_help_text[] =
>>>   "[addr [initrd[:size]] [fdt]]\n"
>>> -    "    - boot arm64 Linux Image stored in memory\n"
>>> +    "    - boot arm64 Linux Image or riscv Linux Image/Image.gz stored
>>> in memory\n"
>>
>> Obvious question -- does this Image.gz stuff apply to arm64 ?
>>
> 
> arm64 builds Image.gz but booti for arm64 doesn't use it. I guess
> Image.gz can be used in FIT image for ARM64 but I am not sure which
> platform actually uses it.
> 
> This patch only enables support for RISC-V.

Can't this be made generic ?

[...]

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

Re: [U-Boot] cyclone5 reboot: warm or cold reset?

2019-04-30 Thread Westergreen, Dalon

On Tue, 2019-04-30 at 22:09 +0200, Marek Vasut wrote:
> On 4/30/19 10:05 PM, Simon Goldschmidt wrote:
> > Am 30.04.2019 um 22:01 schrieb Marek Vasut:
> > > On 4/30/19 9:19 PM, Simon Goldschmidt wrote:
> > > > Am 30.04.2019 um 21:08 schrieb Marek Vasut:
> > > > > On 4/30/19 8:56 PM, Simon Goldschmidt wrote:
> > > > > > Hi all,
> > > > > 
> > > > > Hi,
> > > > > 
> > > > > > I added some of those I think worth discussing this.
> > > > > > 
> > > > > > I was chasing a reboot problem on one of our cyclone5 boards today.
> > > > > > That
> > > > > > board boots from a "n25q256a" qspi flash. Up to now, U-Boot
> > > > > > configures
> > > > > > the boot ROM to just jump to OCRAM when rebooting and hope that the
> > > > > > SPL
> > > > > > is still there and fully working (nothing's overwritten).
> > > > > > 
> > > > > > For a long running production board, this is of course crap, as a
> > > > > > pointer running wild could always overwrite the SRAM. But there was
> > > > > > not
> > > > > > much we could do about it as long as U-Boot and/or Linux were
> > > > > > putting
> > > > > > out 32 Mbyte chip into 4-byte mode: it's not accessible by the Boot
> > > > > > ROM
> > > > > > unless in 3-byte mode. And while Linux "reboot" could reset the chip
> > > > > > into 3-byte mode, "reboot -f" and U-Boot "reset" can't.
> > > > > > 
> > > > > > Now with U-Boot and Linux having everything in place to leave the
> > > > > > spi-nor in 3-byte mode (as required for the Boot ROM) using 4-byte
> > > > > > opcodes, I thought rebooting from Linux would now work with loading
> > > > > > the
> > > > > > SPL from qspi (by disabling the magic that tells the Boot ROM to
> > > > > > jump to
> > > > > > OCRAM).
> > > > > 
> > > > > Well, if the chip is in the middle of some operation (erase or page
> > > > > program) and you reset the CPU just at the right moment, leaving the
> > > > > chip in 3byte addressing mode won't help you anyway.
> > > > 
> > > > Right, but unfortunately, that's not an issue for us :-)
> > > > 
> > > > > The only reliable solution is to connect reset to the SPI NOR chip and
> > > > > trigger the reset. Of course, some SPI NORs have a reset line, but
> > > > > it is
> > > > > not connected internally, which is a fantastic design. I think the
> > > > > N25Q256 had exactly such a problem, but only on some revisions, to
> > > > > make
> > > > > it even more messed up.
> > > > 
> > > > Yeah, well, let's just assume there *are* boards that either use spi-nor
> > > > chips without a working reset line and there *are* boards with spi-nor
> > > > chips having a reset line that is just not connected...
> > > > 
> > > > > > However, I found the Boot ROM still cannot load the SPL because it
> > > > > > tries
> > > > > > to load at 100 MHz (while on cold boot, it loads with 6.25 MHz).
> > > > > 
> > > > > Look at 
> > > > > https://patchwork.ozlabs.org/patch/729738/
> > > > > 
> > > > 
> > > > Interesting, I didn't know that one. I doesn't seem to have made it into
> > > > the tree, but it's a different thing slightly: it prevents the Boot ROM
> > > > jumping to OCRAM, but that's what I did and it still fails as the Boot
> > > > ROM uses a constant divider "4" resulting in loading SPL with 100 MHz
> > > > from the qspi chip. And that somehow fails.
> > > 
> > > It makes the bootrom jump "somewhere else" in OCRAM upon warm reset, to
> > > a code which resets the PLLs and then triggers another warm reset, this
> > > time with a jump address pointing to the SPL.
> > 
> > Well, what I read from hat patch is that it only writes the magic to
> > make Boot ROM jump to OCRAM if csel != 0. So it would try to load SPL
> > from QSPI for csel == 0 in my case (and I do have csel ==0 0).
> > 
> > I fail to see the "somewhere else" in the link you sent. Maybe that was
> > in an older version?
> 
> That's quite possible , there were a few iterations.

In some ES silicon for C5, which happens to be what is used on the DE0 board,
there was an issue that required CSEL=0.  As noted in the comments, for CSEL=0
the bootrom does not reset the PLL/clock configurations and as a result the QSPI
clock in your case is not being modified to a useable clock for the bootrom.
The patch just forced a cold reset when csel=0.   personally, i would like a
default to cold resets, with an option to use warm resets should a use case
exist (such as preserving DDR contents).

What changed with 4-byte access in the QSPI?

--dalon

> 
> > > > If I change the handoff files so that the qspi core runs at 200 MHz
> > > > instead of 400 MHz, it works (qspi loaded with 50 MHz), but I think cold
> > > > reset would still be better...
> > > > 
> > > > > > However, when triggering cold reset instead of warm reset in rstmgr
> > > > > > ctrl
> > > > > > register [1], it works fine (and qspi clock is 6.25 MHz).
> > > > > > 
> > > > > > Now the question is: why do we trigger warm reset instead of cold
> > > > > > reset?
> > > > > 
> > > > > I'd like to know that too. But it's

Re: [U-Boot] Pull request: u-boot-net.git master

On Tue, Apr 30, 2019 at 09:15:33PM +, Joe Hershberger wrote:
> On Tue, Mar 19, 2019 at 5:41 PM Tom Rini  wrote:
> >
> > On Tue, Mar 12, 2019 at 01:15:46PM -0500, Joe Hershberger wrote:
> >
> > > Hi Tom,
> > >
> > > These patches passed the CI build here: 
> > > https://travis-ci.org/jhershbe/u-boot/builds/501807294
> > >
> > > The following changes since commit 
> > > 2e8092d94f40a5692baf3ec768ce3216a7bf032a:
> > >
> > >   Merge branch 'master' of git://git.denx.de/u-boot-sunxi (2019-03-11 
> > > 15:48:57 -0400)
> > >
> > > are available in the git repository at:
> > >
> > >
> > >   git://git.denx.de/u-boot-net.git master
> > >
> > > for you to fetch changes up to 85f05f72bacc2d047731fc64801e4f6b34cf:
> > >
> > >   net: phy: aquantia: Set only autoneg on in register 4.c441 (2019-03-12 
> > > 13:13:37 -0500)
> > >
> >
> > NAK.  One of:
> > The first bad commit could be any of:
> > 30b2ca2e0fa274b875bb56f541b7dd33ce93c1d1
> > 8860e1563f38d16f7ae29053018cd445c0fa111d
> > ebb5027d69196dd83fd0fa5bd91fca07acfd77be
> > 09e0a36497c84273e5b22488d5af01bf0ba17469
> > 841b9df209e37fe1bfefa5f44e837a0ad497443f
> > 15e67d1cdc7258c0c07ad1fd6c2818f7e9f52447
> > 7aadf5134f2f5771689d0657b69875d0a464859d
> > d35488518f3c16d305092c816a5129f45a0b62d7
> > Breaks am335x_evm ethernet:
> > 18:39:52 => => dhcp
> > 18:39:52 ethernet@4a10 Waiting for PHY auto negotiation to
> > complete... done
> > 18:39:52 link up on port 0, speed 1000, full duplex
> > 18:39:52 BOOTP broadcast 1
> > 18:39:52 BOOTP broadcast 2
> > 18:39:52 BOOTP broadcast 3
> > 18:39:52 BOOTP broadcast 4
> > 18:39:52 BOOTP broadcast 5
> > 18:39:52 BOOTP broadcast 6
> > 18:39:52 BOOTP broadcast 7
> > 18:39:52 BOOTP broadcast 8
> > 18:39:52 BOOTP broadcast 9
> > 18:39:52 BOOTP broadcast 10
> > 18:39:52 BOOTP broadcast 11
> > 18:39:52 BOOTP broadcast 12
> > 18:39:52 BOOTP broadcast 13
> > 18:39:52 BOOTP broadcast 14
> > 18:39:52 BOOTP broadcast 15
> > 18:39:52 BOOTP broadcast 16
> > 18:39:52 BOOTP broadcast 17
> 
> I rebased the series on the current master and I can't reproduce this
> dhcp issue. On the original series I saw broken DHCP only with "net:
> phy: micrel: Use correct skew values on KSZ9021" which doesn't make
> any sense because that phy is not used on BBB and isn't even compiled
> in. Also, the issue doesn't reproduce when the next patch is applied.
> Even that oddity doesn't happen after the rebase.
> 
> Also the SPL for boneblack is too big to build with some of the
> patches in this series now, so I'm not sure how that should be
> handled.

Drop those parts for now I guess and we'll have to look harder at them
stand-alone?  And I assume you mean am335x_boneblack_vboot is too large?
Or am335x_evm itself?  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 3/3] common: bouncebuf: handle address in sram for rockchip platform

2019-04-30 Thread Christoph Müllner

Hi Kever,

On 4/2/19 10:46 AM, Kever Yang wrote:
> Rockchip SOC's mmc controller does not support read data
> from mmc to sram, we need a bounce buffer(in sdram), and then
> copy to sram.

what exactly is the limitation here?
I mean a DMA engine does not care where it is copying to.

Additionally I was observing recently, that copying from SD card
to SRAM works on RK3399 boards with 4 GB of RAM.
I see a data error in dwmci_data_transfer() only on 2 GB boards.

Therefore my question:
Is this maybe just a problem of the memory area not being mapped in SPL?

Thanks,
Christoph

> 
> Signed-off-by: Kever Yang 
> ---
> 
>  common/bouncebuf.c | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/common/bouncebuf.c b/common/bouncebuf.c
> index a7098e2caf..364fb17c96 100644
> --- a/common/bouncebuf.c
> +++ b/common/bouncebuf.c
> @@ -26,6 +26,18 @@ static int addr_aligned(struct bounce_buffer *state)
>   return 0;
>   }
>  
> +#ifdef CONFIG_ARCH_ROCKCHIP
> + /*
> +  * Rockchip SOC's mmc controller does not support read data
> +  * from mmc to sram, we need a bounce buffer(in sdram), and then
> +  * copy to sram.
> +  */
> + if (((ulong)state->user_buffer & 0xfff8) ==
> + CONFIG_ROCKCHIP_IRAM_BASE) {
> + debug("Unsupport IRAM space %p\n", state->user_buffer);
> + return 0;
> + }
> +#endif
>   /* Aligned */
>   return 1;
>  }
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Pull request: u-boot-net.git master

2019-04-30 Thread Joe Hershberger

On Tue, Mar 19, 2019 at 5:41 PM Tom Rini  wrote:
>
> On Tue, Mar 12, 2019 at 01:15:46PM -0500, Joe Hershberger wrote:
>
> > Hi Tom,
> >
> > These patches passed the CI build here: 
> > https://travis-ci.org/jhershbe/u-boot/builds/501807294
> >
> > The following changes since commit 2e8092d94f40a5692baf3ec768ce3216a7bf032a:
> >
> >   Merge branch 'master' of git://git.denx.de/u-boot-sunxi (2019-03-11 
> > 15:48:57 -0400)
> >
> > are available in the git repository at:
> >
> >
> >   git://git.denx.de/u-boot-net.git master
> >
> > for you to fetch changes up to 85f05f72bacc2d047731fc64801e4f6b34cf:
> >
> >   net: phy: aquantia: Set only autoneg on in register 4.c441 (2019-03-12 
> > 13:13:37 -0500)
> >
>
> NAK.  One of:
> The first bad commit could be any of:
> 30b2ca2e0fa274b875bb56f541b7dd33ce93c1d1
> 8860e1563f38d16f7ae29053018cd445c0fa111d
> ebb5027d69196dd83fd0fa5bd91fca07acfd77be
> 09e0a36497c84273e5b22488d5af01bf0ba17469
> 841b9df209e37fe1bfefa5f44e837a0ad497443f
> 15e67d1cdc7258c0c07ad1fd6c2818f7e9f52447
> 7aadf5134f2f5771689d0657b69875d0a464859d
> d35488518f3c16d305092c816a5129f45a0b62d7
> Breaks am335x_evm ethernet:
> 18:39:52 => => dhcp
> 18:39:52 ethernet@4a10 Waiting for PHY auto negotiation to
> complete... done
> 18:39:52 link up on port 0, speed 1000, full duplex
> 18:39:52 BOOTP broadcast 1
> 18:39:52 BOOTP broadcast 2
> 18:39:52 BOOTP broadcast 3
> 18:39:52 BOOTP broadcast 4
> 18:39:52 BOOTP broadcast 5
> 18:39:52 BOOTP broadcast 6
> 18:39:52 BOOTP broadcast 7
> 18:39:52 BOOTP broadcast 8
> 18:39:52 BOOTP broadcast 9
> 18:39:52 BOOTP broadcast 10
> 18:39:52 BOOTP broadcast 11
> 18:39:52 BOOTP broadcast 12
> 18:39:52 BOOTP broadcast 13
> 18:39:52 BOOTP broadcast 14
> 18:39:52 BOOTP broadcast 15
> 18:39:52 BOOTP broadcast 16
> 18:39:52 BOOTP broadcast 17

I rebased the series on the current master and I can't reproduce this
dhcp issue. On the original series I saw broken DHCP only with "net:
phy: micrel: Use correct skew values on KSZ9021" which doesn't make
any sense because that phy is not used on BBB and isn't even compiled
in. Also, the issue doesn't reproduce when the next patch is applied.
Even that oddity doesn't happen after the rebase.

Also the SPL for boneblack is too big to build with some of the
patches in this series now, so I'm not sure how that should be
handled.

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

Re: [U-Boot] [PATCH v4 5/5] riscv: configs: AE350 will use CONFIG_OF_SEPARATE when boots from flash

2019-04-30 Thread Auer, Lukas

Hi Rick,

On Tue, 2019-04-30 at 13:49 +0800, Andes wrote:
> From: Rick Chen 
> 
> When AE350 boots from flash, use CONFIG_OF_SEPARATE instead of
> CONFIG_OF_BOARD.
> 
> Also remove unused code about prior_stage_fdt_address.
> And modify CONFIG_SYS_FDT_BASE as flash address.
> 
> Signed-off-by: Rick Chen 
> Cc: Greentime Hu 
> ---
>  board/AndesTech/ax25-ae350/ax25-ae350.c | 4 
>  configs/ae350_rv32_xip_defconfig| 2 +-
>  configs/ae350_rv64_xip_defconfig| 2 +-
>  include/configs/ax25-ae350.h| 2 +-
>  4 files changed, 3 insertions(+), 7 deletions(-)
> 
> diff --git a/board/AndesTech/ax25-ae350/ax25-ae350.c 
> b/board/AndesTech/ax25-ae350/ax25-ae350.c
> index d343453..3d65ce7 100644
> --- a/board/AndesTech/ax25-ae350/ax25-ae350.c
> +++ b/board/AndesTech/ax25-ae350/ax25-ae350.c
> @@ -67,10 +67,6 @@ ulong board_flash_get_legacy(ulong base, int banknum, 
> flash_info_t *info)
>  
>  void *board_fdt_blob_setup(void)
>  {
> - void **ptr = (void *)_stage_fdt_address;
> - if (fdt_magic(*ptr) == FDT_MAGIC)
> - return (void *)*ptr;
> -
>   return (void *)CONFIG_SYS_FDT_BASE;
>  }
>  
> diff --git a/configs/ae350_rv32_xip_defconfig 
> b/configs/ae350_rv32_xip_defconfig
> index 76534f2..07f1ecc 100644
> --- a/configs/ae350_rv32_xip_defconfig
> +++ b/configs/ae350_rv32_xip_defconfig
> @@ -15,7 +15,7 @@ CONFIG_CMD_SF_TEST=y
>  # CONFIG_CMD_SETEXPR is not set
>  CONFIG_BOOTP_PREFER_SERVERIP=y
>  CONFIG_CMD_CACHE=y
> -CONFIG_OF_BOARD=y
> +CONFIG_OF_SEPARATE=y
>  CONFIG_DEFAULT_DEVICE_TREE="ae350_32"
>  CONFIG_ENV_IS_IN_SPI_FLASH=y
>  CONFIG_NET_RANDOM_ETHADDR=y
> diff --git a/configs/ae350_rv64_xip_defconfig 
> b/configs/ae350_rv64_xip_defconfig
> index f7f2925..28afd81 100644
> --- a/configs/ae350_rv64_xip_defconfig
> +++ b/configs/ae350_rv64_xip_defconfig
> @@ -16,7 +16,7 @@ CONFIG_CMD_SF_TEST=y
>  # CONFIG_CMD_SETEXPR is not set
>  CONFIG_BOOTP_PREFER_SERVERIP=y
>  CONFIG_CMD_CACHE=y
> -CONFIG_OF_BOARD=y
> +CONFIG_OF_SEPARATE=y
>  CONFIG_DEFAULT_DEVICE_TREE="ae350_64"
>  CONFIG_ENV_IS_IN_SPI_FLASH=y
>  CONFIG_NET_RANDOM_ETHADDR=y
> diff --git a/include/configs/ax25-ae350.h b/include/configs/ax25-ae350.h
> index 395f3a4..a4037f3 100644
> --- a/include/configs/ax25-ae350.h
> +++ b/include/configs/ax25-ae350.h
> @@ -40,7 +40,7 @@
>  #define CONFIG_SYS_MALLOC_LEN   (512 << 10)
>  
>  /* DT blob (fdt) address */
> -#define CONFIG_SYS_FDT_BASE  0x000f
> +#define CONFIG_SYS_FDT_BASE  0x800f
>  
>  /*
>   * Physical Memory Map

As a note, with CONFIG_OF_SEPARATE, the device tree will be
automatically appended to the U-Boot binary. A fixed location for the
device tree therefore does not have to be defined, meaning that you
could remove the CONFIG_SYS_FDT_BASE define and the
board_fdt_blob_setup() function.

There are also reasons for using a fixed location for the device tree,
so this is also fine. :)

Reviewed-by: Lukas Auer 

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

Re: [U-Boot] [PATCH v4 3/5] riscv: prior_stage_fdt_address should only be used when OF_PRIOR_STAGE is enabled

2019-04-30 Thread Auer, Lukas

On Tue, 2019-04-30 at 13:49 +0800, Andes wrote:
> From: Rick Chen 
> 
> This patch will fix prior_stage_fdt_address write failure problem, when
> AE350 boots from flash.
> 
> When AE350 boots from flash, prior_stage_fdt_address will be flash
> address, we shall avoid it to be written.
> 
> Signed-off-by: Rick Chen 
> Cc: Greentime Hu 
> ---
>  arch/riscv/cpu/cpu.c   | 2 ++
>  arch/riscv/cpu/start.S | 2 ++
>  2 files changed, 4 insertions(+)
> 

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

Re: [U-Boot] [PATCH 8/8] spi: Kconfig: Mark LPC32XX_SSP has BROKEN

2019-04-30 Thread Vladimir Zapolskiy

Hi Jagan,

On 04/28/2019 11:48 PM, Jagan Teki wrote:
> Mark LPC32XX_SSP has BROKEN, this so the resulting build shows
> warning for broken configuration enabled and associated code
> will remove in v2019.07 release.
> 
> Cc: Vladimir Zapolskiy 
> Cc: Albert ARIBAUD 
> Signed-off-by: Jagan Teki 
> ---
>  drivers/spi/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
> index 55f0d6cf2b..5fbe17bb20 100644
> --- a/drivers/spi/Kconfig
> +++ b/drivers/spi/Kconfig
> @@ -369,6 +369,7 @@ config KIRKWOOD_SPI
>  
>  config LPC32XX_SSP
>   bool "LPC32XX SPI Driver"
> + select BROKEN
>   help
> Enable support for SPI on LPC32xx
>  
> 

Acked-by: Vladimir Zapolskiy 

Thank you for the change, as we've discussed earlier I won't have
objections against the driver removal when time is up.

Thus you can locally prepare a removal change in advance, the one
which you've sent earlier needs a minor update, please also remove
lpc32xx_ssp_init() function and its usage in the board files.

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

Re: [U-Boot] [PATCH v2 2/2] RISCV: image: Parse Image.gz support in booti.

2019-04-30 Thread Atish Patra


On 4/30/19 12:11 PM, Marek Vasut wrote:

On 4/30/19 8:13 PM, Atish Patra wrote:

On 4/30/19 2:52 AM, Marek Vasut wrote:

On 4/30/19 3:27 AM, Atish Patra wrote:

[...]


Yes. FIT image parsing can be done in that way. However, the idea was
here to load Image.gz directly. Image.gz is default compressed Linux
kernel image format in RISC-V.


Sigh, and the image header is compressed as well, so there's no way to
identify the image format, right ? And there's no decompressor, so the
dcompressing has to be done by bootloader, which would need some
sort of
very smart way of figuring out which exact compression method is used ?


Yes. Image.gz is always gunzip. So checking first two bytes is enough to
confirm that it is a gz file.


What happens once people start feeding it more exotic compression
methods, like LZ4 or LZO or LZMA for example ?



booti command help will clearly state that it can only boot kernel from
Image or Image.gz.

static char booti_help_text[] =
  "[addr [initrd[:size]] [fdt]]\n"
-    "    - boot arm64 Linux Image stored in memory\n"
+    "    - boot arm64 Linux Image or riscv Linux Image/Image.gz stored
in memory\n"


Obvious question -- does this Image.gz stuff apply to arm64 ?



arm64 builds Image.gz but booti for arm64 doesn't use it. I guess 
Image.gz can be used in FIT image for ARM64 but I am not sure which 
platform actually uses it.


This patch only enables support for RISC-V.



(I will update the help text with Image.gz part)

Anything other than that, it will fail with following error.

"Bad Linux RISCV Image magic!"


Right, so we're implementing file(1)-lite here to detect the format.


The tricky part is length of the compressed file. I took another look at
the gunzip implementation in U-Boot. It looks like to me that compressed
header length just to parse the header correctly. It doesn't actually
use the "length" to decompress. In fact, it updates the length with
uncompressed bytes after the decompression.


That's possible.



David suggested a better idea.

1. User can supply kernel_size and we can store in environment variable.
2. If the size is empty or greater than CONFIG_SYS_BOOTM_LEN, booti
fails with appropriate error message.


You can keep decompressing until you reach $bootm_len, sure .


Decompression happens for actual uncompressed length which is encoded 
into the compressed file footer. So we don't have to worry about how 
much we decompress. But a correct file_size helps to avoid decompressing 
a possible corrupt compressed file.


I will update the patch as per David's suggestion.

Regards,
Atish



We will update the documents to add the additional step for Image.gz

I am fine with either approach. Any preference ?

Regards,
Atish





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

[U-Boot] [BUG] test_avb_persistent_values() fails


Hello Igor,

when I run `make tests` with current origin/master
commit a69120a0d7c8d4044cdaceea9eb03913ba4e49c7
I get an error. I think your submitted this test recently:
commit fc1fe01b08ce ("avb: add support for named persistent values")

u_boot_console = 

@pytest.mark.buildconfigspec('cmd_avb')
@pytest.mark.buildconfigspec('optee_ta_avb')
def test_avb_persistent_values(u_boot_console):
"""Test reading/writing persistent storage to avb
"""

response = u_boot_console.run_command('avb init %s' % str(mmc_dev))
assert response == ''

response = u_boot_console.run_command('avb write_pvalue test
value_value')
assert response == 'Wrote 12 bytes'

response = u_boot_console.run_command('avb read_pvalue test 12')
>   assert response == 'Read 12 bytes, value = value_value'
E   AssertionError: assert 'Read 12 byte...alue_value/XU' == 'Read
12 bytes...= value_value'
E - Read 12 bytes, value = value_value/XU
E ?   ---
E + Read 12 bytes, value = value_value

test/py/tests/test_avb.py:134: AssertionError

Best regards

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

Re: [U-Boot] [PATCH] Convert CONFIG_SUPPORT_EMMC_BOOT to Kconfig

2019-04-30 Thread Sébastien Szymanski

Hi,

On 4/19/19 6:38 AM, Alex Kiernan wrote:
> This converts the following to Kconfig:
>CONFIG_SUPPORT_EMMC_BOOT
> 
> Signed-off-by: Alex Kiernan 
> ---
> Green travis build:
> 
> https://travis-ci.org/akiernan/u-boot/builds/521906850
> 
> Testing affected boards for configuration changes:
> 
>   boards.cfg is up to date. Nothing to do.
>   Summary of 3 commits for 95 boards (4 threads, 1 job per thread)
>   01: Merge tag 'u-boot-imx-20190415' of git://git.denx.de/u-boot-imx
>  aarch64:  w+   xilinx_zynqmp_mini_emmc1 xilinx_zynqmp_mini_emmc0 
> xilinx_zynqmp_mini_qspi clearfog_gt_8k imx8qxp_mek xilinx_zynqmp_mini 
> xilinx_zynqmp_mini_nand imx8mq_evk
>  arm:  w+   cm_t54 cl-som-imx7 marsboard clearfog apalis_imx6 warp7 
> pico-hobbit-imx7d pico-pi-imx6ul dms-ba16 arndale riotboard 
> pico-hobbit-imx6ul colibri_imx7 pico-imx7d xpress_spl opos6uldev warp7_bl33 
> imx6dl_mamoj ge_bx50v3 display5 mx7dsabresd_qspi display5_factory 
> colibri_imx7_emmc gwventana_nand mx7dsabresd gwventana_gw5904 gwventana_emmc 
> am57xx_hs_evm_usb omap5_uevm brppt1_spi xilinx_zynqmp_r5 vinco mx6sabresd 
> warp riotboard_spl vining_2000 zc5601 zc5202 xpress pico-imx6ul dms-ba16-1g 
> pico-pi-imx7d
>   02: configs: Resync with savedefconfig
>   03: Convert CONFIG_SUPPORT_EMMC_BOOT to Kconfig
> 

>  configs/opos6uldev_defconfig | 1 +

>  include/configs/opos6uldev.h | 3 ---


Tested-by: Sébastien Szymanski 

Regards,


-- 
Sébastien Szymanski
Software engineer, Armadeus Systems
Tel: +33 (0)9 72 29 41 44
Fax: +33 (0)9 72 28 79 26
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] cyclone5 reboot: warm or cold reset?

On 4/30/19 10:05 PM, Simon Goldschmidt wrote:
> Am 30.04.2019 um 22:01 schrieb Marek Vasut:
>> On 4/30/19 9:19 PM, Simon Goldschmidt wrote:
>>> Am 30.04.2019 um 21:08 schrieb Marek Vasut:
 On 4/30/19 8:56 PM, Simon Goldschmidt wrote:
> Hi all,

 Hi,

> I added some of those I think worth discussing this.
>
> I was chasing a reboot problem on one of our cyclone5 boards today.
> That
> board boots from a "n25q256a" qspi flash. Up to now, U-Boot configures
> the boot ROM to just jump to OCRAM when rebooting and hope that the
> SPL
> is still there and fully working (nothing's overwritten).
>
> For a long running production board, this is of course crap, as a
> pointer running wild could always overwrite the SRAM. But there was
> not
> much we could do about it as long as U-Boot and/or Linux were putting
> out 32 Mbyte chip into 4-byte mode: it's not accessible by the Boot
> ROM
> unless in 3-byte mode. And while Linux "reboot" could reset the chip
> into 3-byte mode, "reboot -f" and U-Boot "reset" can't.
>
> Now with U-Boot and Linux having everything in place to leave the
> spi-nor in 3-byte mode (as required for the Boot ROM) using 4-byte
> opcodes, I thought rebooting from Linux would now work with loading
> the
> SPL from qspi (by disabling the magic that tells the Boot ROM to
> jump to
> OCRAM).

 Well, if the chip is in the middle of some operation (erase or page
 program) and you reset the CPU just at the right moment, leaving the
 chip in 3byte addressing mode won't help you anyway.
>>>
>>> Right, but unfortunately, that's not an issue for us :-)
>>>

 The only reliable solution is to connect reset to the SPI NOR chip and
 trigger the reset. Of course, some SPI NORs have a reset line, but
 it is
 not connected internally, which is a fantastic design. I think the
 N25Q256 had exactly such a problem, but only on some revisions, to make
 it even more messed up.
>>>
>>> Yeah, well, let's just assume there *are* boards that either use spi-nor
>>> chips without a working reset line and there *are* boards with spi-nor
>>> chips having a reset line that is just not connected...
>>>

> However, I found the Boot ROM still cannot load the SPL because it
> tries
> to load at 100 MHz (while on cold boot, it loads with 6.25 MHz).

 Look at https://patchwork.ozlabs.org/patch/729738/
>>>
>>> Interesting, I didn't know that one. I doesn't seem to have made it into
>>> the tree, but it's a different thing slightly: it prevents the Boot ROM
>>> jumping to OCRAM, but that's what I did and it still fails as the Boot
>>> ROM uses a constant divider "4" resulting in loading SPL with 100 MHz
>>> from the qspi chip. And that somehow fails.
>>
>> It makes the bootrom jump "somewhere else" in OCRAM upon warm reset, to
>> a code which resets the PLLs and then triggers another warm reset, this
>> time with a jump address pointing to the SPL.
> 
> Well, what I read from hat patch is that it only writes the magic to
> make Boot ROM jump to OCRAM if csel != 0. So it would try to load SPL
> from QSPI for csel == 0 in my case (and I do have csel ==0 0).
> 
> I fail to see the "somewhere else" in the link you sent. Maybe that was
> in an older version?

That's quite possible , there were a few iterations.

>>> If I change the handoff files so that the qspi core runs at 200 MHz
>>> instead of 400 MHz, it works (qspi loaded with 50 MHz), but I think cold
>>> reset would still be better...
>>>

> However, when triggering cold reset instead of warm reset in rstmgr
> ctrl
> register [1], it works fine (and qspi clock is 6.25 MHz).
>
> Now the question is: why do we trigger warm reset instead of cold
> reset?

 I'd like to know that too. But it's likely because of various AMP
 setups, where the second CPU or the FPGA do something and you don't
 want
 to interrupt that operation by the primary CPU's reset. I haven't seen
 such deployments much myself though.
>>>
>>> Ok, from reading the above thread, I guess there might be use cases for
>>> the warm reset but not for us. So I can make Linux using cold reset via
>>> a Kernel command line parameter but I can't do it for U-Boot.
>>>
>>> Looks like we need a method to control this for U-Boot. Unless someone
>>> comes up with a better explanation, that is.
>>
>> Update the "reset" command to take a parameter -- type of reset.
>> It's been on my list of things to do for a while, but didn't get around
>> to it.
> 
> Right, something like that. Probably the same enum Linux uses (enum
> reboot_mode), to make things clearer.

Right

> Regards,
> Simon
> 
>>
>>> Regards,
>>> Simon
>>>

> Isn't cold reset more stable, e.g. when rebooting watchdog-like? Linux
> also uses warm reset by default, but I'm tempted to send a patch for
> both U-Boot and Linux

Re: [U-Boot] cyclone5 reboot: warm or cold reset?

Am 30.04.2019 um 22:01 schrieb Marek Vasut:

On 4/30/19 9:19 PM, Simon Goldschmidt wrote:

Am 30.04.2019 um 21:08 schrieb Marek Vasut:

On 4/30/19 8:56 PM, Simon Goldschmidt wrote:

Hi all,

Hi,

I added some of those I think worth discussing this.

I was chasing a reboot problem on one of our cyclone5 boards today. That
board boots from a "n25q256a" qspi flash. Up to now, U-Boot configures
the boot ROM to just jump to OCRAM when rebooting and hope that the SPL
is still there and fully working (nothing's overwritten).

For a long running production board, this is of course crap, as a
pointer running wild could always overwrite the SRAM. But there was not
much we could do about it as long as U-Boot and/or Linux were putting
out 32 Mbyte chip into 4-byte mode: it's not accessible by the Boot ROM
unless in 3-byte mode. And while Linux "reboot" could reset the chip
into 3-byte mode, "reboot -f" and U-Boot "reset" can't.

Now with U-Boot and Linux having everything in place to leave the
spi-nor in 3-byte mode (as required for the Boot ROM) using 4-byte
opcodes, I thought rebooting from Linux would now work with loading the
SPL from qspi (by disabling the magic that tells the Boot ROM to jump to
OCRAM).

Well, if the chip is in the middle of some operation (erase or page
program) and you reset the CPU just at the right moment, leaving the
chip in 3byte addressing mode won't help you anyway.

Right, but unfortunately, that's not an issue for us :-)

The only reliable solution is to connect reset to the SPI NOR chip and
trigger the reset. Of course, some SPI NORs have a reset line, but it is
not connected internally, which is a fantastic design. I think the
N25Q256 had exactly such a problem, but only on some revisions, to make
it even more messed up.

Yeah, well, let's just assume there *are* boards that either use spi-nor
chips without a working reset line and there *are* boards with spi-nor
chips having a reset line that is just not connected...

However, I found the Boot ROM still cannot load the SPL because it tries
to load at 100 MHz (while on cold boot, it loads with 6.25 MHz).

Look at https://patchwork.ozlabs.org/patch/729738/

Interesting, I didn't know that one. I doesn't seem to have made it into
the tree, but it's a different thing slightly: it prevents the Boot ROM
jumping to OCRAM, but that's what I did and it still fails as the Boot
ROM uses a constant divider "4" resulting in loading SPL with 100 MHz
from the qspi chip. And that somehow fails.

It makes the bootrom jump "somewhere else" in OCRAM upon warm reset, to
a code which resets the PLLs and then triggers another warm reset, this
time with a jump address pointing to the SPL.

Well, what I read from hat patch is that it only writes the magic to
make Boot ROM jump to OCRAM if csel != 0. So it would try to load SPL
from QSPI for csel == 0 in my case (and I do have csel ==0 0).

I fail to see the "somewhere else" in the link you sent. Maybe that was
in an older version?

If I change the handoff files so that the qspi core runs at 200 MHz
instead of 400 MHz, it works (qspi loaded with 50 MHz), but I think cold
reset would still be better...

However, when triggering cold reset instead of warm reset in rstmgr ctrl
register [1], it works fine (and qspi clock is 6.25 MHz).

Now the question is: why do we trigger warm reset instead of cold reset?

I'd like to know that too. But it's likely because of various AMP
setups, where the second CPU or the FPGA do something and you don't want
to interrupt that operation by the primary CPU's reset. I haven't seen
such deployments much myself though.

Ok, from reading the above thread, I guess there might be use cases for
the warm reset but not for us. So I can make Linux using cold reset via
a Kernel command line parameter but I can't do it for U-Boot.

Looks like we need a method to control this for U-Boot. Unless someone
comes up with a better explanation, that is.

Update the "reset" command to take a parameter -- type of reset.
It's been on my list of things to do for a while, but didn't get around
to it.

Right, something like that. Probably the same enum Linux uses (enum
reboot_mode), to make things clearer.

Regards,
Simon

Isn't cold reset more stable, e.g. when rebooting watchdog-like? Linux
also uses warm reset by default, but I'm tempted to send a patch for
both U-Boot and Linux to use cold reset by default.

Any insight on the consequences of using cold reset instead of warm
reset would be really appreciated!

Regards,
Simon

[1]
https://www.intel.com/content/www/us/en/programmable/hps/cyclone-v/hps.html#topic/sfo1410067764332.html

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

Re: [U-Boot] cyclone5 reboot: warm or cold reset?

On 4/30/19 9:19 PM, Simon Goldschmidt wrote:
> Am 30.04.2019 um 21:08 schrieb Marek Vasut:
>> On 4/30/19 8:56 PM, Simon Goldschmidt wrote:
>>> Hi all,
>>
>> Hi,
>>
>>> I added some of those I think worth discussing this.
>>>
>>> I was chasing a reboot problem on one of our cyclone5 boards today. That
>>> board boots from a "n25q256a" qspi flash. Up to now, U-Boot configures
>>> the boot ROM to just jump to OCRAM when rebooting and hope that the SPL
>>> is still there and fully working (nothing's overwritten).
>>>
>>> For a long running production board, this is of course crap, as a
>>> pointer running wild could always overwrite the SRAM. But there was not
>>> much we could do about it as long as U-Boot and/or Linux were putting
>>> out 32 Mbyte chip into 4-byte mode: it's not accessible by the Boot ROM
>>> unless in 3-byte mode. And while Linux "reboot" could reset the chip
>>> into 3-byte mode, "reboot -f" and U-Boot "reset" can't.
>>>
>>> Now with U-Boot and Linux having everything in place to leave the
>>> spi-nor in 3-byte mode (as required for the Boot ROM) using 4-byte
>>> opcodes, I thought rebooting from Linux would now work with loading the
>>> SPL from qspi (by disabling the magic that tells the Boot ROM to jump to
>>> OCRAM).
>>
>> Well, if the chip is in the middle of some operation (erase or page
>> program) and you reset the CPU just at the right moment, leaving the
>> chip in 3byte addressing mode won't help you anyway.
> 
> Right, but unfortunately, that's not an issue for us :-)
> 
>>
>> The only reliable solution is to connect reset to the SPI NOR chip and
>> trigger the reset. Of course, some SPI NORs have a reset line, but it is
>> not connected internally, which is a fantastic design. I think the
>> N25Q256 had exactly such a problem, but only on some revisions, to make
>> it even more messed up.
> 
> Yeah, well, let's just assume there *are* boards that either use spi-nor
> chips without a working reset line and there *are* boards with spi-nor
> chips having a reset line that is just not connected...
> 
>>
>>> However, I found the Boot ROM still cannot load the SPL because it tries
>>> to load at 100 MHz (while on cold boot, it loads with 6.25 MHz).
>>
>> Look at https://patchwork.ozlabs.org/patch/729738/
> 
> Interesting, I didn't know that one. I doesn't seem to have made it into
> the tree, but it's a different thing slightly: it prevents the Boot ROM
> jumping to OCRAM, but that's what I did and it still fails as the Boot
> ROM uses a constant divider "4" resulting in loading SPL with 100 MHz
> from the qspi chip. And that somehow fails.

It makes the bootrom jump "somewhere else" in OCRAM upon warm reset, to
a code which resets the PLLs and then triggers another warm reset, this
time with a jump address pointing to the SPL.

> If I change the handoff files so that the qspi core runs at 200 MHz
> instead of 400 MHz, it works (qspi loaded with 50 MHz), but I think cold
> reset would still be better...
> 
>>
>>> However, when triggering cold reset instead of warm reset in rstmgr ctrl
>>> register [1], it works fine (and qspi clock is 6.25 MHz).
>>>
>>> Now the question is: why do we trigger warm reset instead of cold reset?
>>
>> I'd like to know that too. But it's likely because of various AMP
>> setups, where the second CPU or the FPGA do something and you don't want
>> to interrupt that operation by the primary CPU's reset. I haven't seen
>> such deployments much myself though.
> 
> Ok, from reading the above thread, I guess there might be use cases for
> the warm reset but not for us. So I can make Linux using cold reset via
> a Kernel command line parameter but I can't do it for U-Boot.
> 
> Looks like we need a method to control this for U-Boot. Unless someone
> comes up with a better explanation, that is.

Update the "reset" command to take a parameter -- type of reset.
It's been on my list of things to do for a while, but didn't get around
to it.

> Regards,
> Simon
> 
>>
>>> Isn't cold reset more stable, e.g. when rebooting watchdog-like? Linux
>>> also uses warm reset by default, but I'm tempted to send a patch for
>>> both U-Boot and Linux to use cold reset by default.
>>>
>>> Any insight on the consequences of using cold reset instead of warm
>>> reset would be really appreciated!
>>>
>>> Regards,
>>> Simon
>>>
>>> [1]
>>> https://www.intel.com/content/www/us/en/programmable/hps/cyclone-v/hps.html#topic/sfo1410067764332.html
>>>
>>>
>>> ___
>>> U-Boot mailing list
>>> U-Boot@lists.denx.de
>>> https://lists.denx.de/listinfo/u-boot
>>
>>
> 


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

Re: [U-Boot] Booting MX6 via Serial Download after DM conversion

On Tue, Apr 30, 2019 at 02:39:17PM -0300, Fabio Estevam wrote:
> Hi Tom,
> 
> On Mon, Apr 29, 2019 at 2:57 PM Tom Rini  wrote:
> 
> > imx_usb is doing some checking of the second binary it sends along?
> > That sounds odd to start with, is there some specific history there?
> 
> My understanding is that imx_usb_loader expects to find a valid IVT entry.
> 
> After the conversion to DM, a FIT image is used on
> mx6sabresd_defconfig and such IVT can no longer be found, causing
> imx_usb_loader to fail to loading u-boot-dtb.img.
> 
> It would be nice if we can come up with a solution, as loosing the
> ability to load via imx_usb_loader has a negative impact for users.

Right, what I'm getting at is, why does imx_usb_loader need to find a
specific anything in the binary?  What is that IVT used for exactly?

-- 
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 V2 1/2] usb: ohci: ohci-da8xx: Enable da850-ohci driver with DM support

On 4/30/19 12:21 PM, Adam Ford wrote:
[..]

> +#if CONFIG_IS_ENABLED(DM_USB)
> +static int ohci_da8xx_probe(struct udevice *dev)
> +{
> + struct ohci_regs *regs = (struct ohci_regs *)devfdt_get_addr(dev);
> + struct da8xx_ohci *priv = dev_get_priv(dev);
> + int i, err, ret, clock_nb;
> +
> + err = 0;
> + priv->clock_count = 0;
> + clock_nb = dev_count_phandle_with_args(dev, "clocks", "#clock-cells");
> + if (clock_nb > 0) {

What happens if clock_nb == -ENOENT ?

I think what you want here is

if (clock_nb < 0) {
...
return clock_nb;
}

if (clock_nb > 0) {
...
}

> + priv->clocks = devm_kcalloc(dev, clock_nb, sizeof(struct clk),
> + GFP_KERNEL);
> + if (!priv->clocks)
> + return -ENOMEM;
> +
> + for (i = 0; i < clock_nb; i++) {
> + err = clk_get_by_index(dev, i, >clocks[i]);
> + if (err < 0)
> + break;
> +
> + err = clk_enable(>clocks[i]);
> + if (err) {
> + dev_err(dev, "failed to enable clock %d\n", i);
> + clk_free(>clocks[i]);
> + goto clk_err;
> + }
> + priv->clock_count++;
> + }
> + } else if (clock_nb != -ENOENT) {
> + dev_err(dev, "failed to get clock phandle(%d)\n", clock_nb);
> + return clock_nb;
> + }
> +
> + err = usb_cpu_init();
> +
> + if (err)
> + goto clk_err;
> +
> + err = ohci_register(dev, regs);
> + if (err)
> + goto phy_err;
> +
> + return 0;
> +
> +phy_err:
> + ret = usb_cpu_stop();
> + if (ret)
> + dev_err(dev, "failed to shutdown usb phy\n");
> +
> +clk_err:
> + ret = clk_release_all(priv->clocks, priv->clock_count);
> + if (ret)
> + dev_err(dev, "failed to disable all clocks\n");
> +
> + return err;
> +}
> +
> +static int ohci_da8xx_remove(struct udevice *dev)
> +{
> + struct da8xx_ohci *priv = dev_get_priv(dev);
> + int ret;
> +
> + ret = ohci_deregister(dev);
> + if (ret)
> + return ret;
> +
> + ret = usb_cpu_stop();
> + if (ret)
> + return ret;
> +
> + return clk_release_all(priv->clocks, priv->clock_count);
> +}
> +
> +static const struct udevice_id da8xx_ohci_ids[] = {
> + { .compatible = "ti,da830-ohci" },
> + { }
> +};
> +
> +U_BOOT_DRIVER(ohci_generic) = {
> + .name   = "ohci-da8xx",
> + .id = UCLASS_USB,
> + .of_match = da8xx_ohci_ids,
> + .probe = ohci_da8xx_probe,
> + .remove = ohci_da8xx_remove,

Add DM_FLAG_OS_PREPARE for this to work IIRC.

> + .ops= _usb_ops,
> + .priv_auto_alloc_size = sizeof(struct da8xx_ohci),
> + .flags  = DM_FLAG_ALLOC_PRIV_DMA,
> +};
> +#endif
> 


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

Re: [U-Boot] cyclone5 reboot: warm or cold reset?

Am 30.04.2019 um 21:08 schrieb Marek Vasut:

On 4/30/19 8:56 PM, Simon Goldschmidt wrote:

Hi all,

Hi,

I added some of those I think worth discussing this.

Well, if the chip is in the middle of some operation (erase or page
program) and you reset the CPU just at the right moment, leaving the
chip in 3byte addressing mode won't help you anyway.

Right, but unfortunately, that's not an issue for us :-)

Yeah, well, let's just assume there *are* boards that either use spi-nor
chips without a working reset line and there *are* boards with spi-nor
chips having a reset line that is just not connected...

However, I found the Boot ROM still cannot load the SPL because it tries
to load at 100 MHz (while on cold boot, it loads with 6.25 MHz).

Look at https://patchwork.ozlabs.org/patch/729738/

If I change the handoff files so that the qspi core runs at 200 MHz
instead of 400 MHz, it works (qspi loaded with 50 MHz), but I think cold
reset would still be better...

However, when triggering cold reset instead of warm reset in rstmgr ctrl
register [1], it works fine (and qspi clock is 6.25 MHz).

Now the question is: why do we trigger warm reset instead of cold reset?

Looks like we need a method to control this for U-Boot. Unless someone
comes up with a better explanation, that is.

Regards,
Simon

Isn't cold reset more stable, e.g. when rebooting watchdog-like? Linux
also uses warm reset by default, but I'm tempted to send a patch for
both U-Boot and Linux to use cold reset by default.

Any insight on the consequences of using cold reset instead of warm
reset would be really appreciated!

Regards,
Simon

[1]
https://www.intel.com/content/www/us/en/programmable/hps/cyclone-v/hps.html#topic/sfo1410067764332.html

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

Re: [U-Boot] [PATCH v2 2/2] RISCV: image: Parse Image.gz support in booti.

On 4/30/19 8:13 PM, Atish Patra wrote:
> On 4/30/19 2:52 AM, Marek Vasut wrote:
>> On 4/30/19 3:27 AM, Atish Patra wrote:
>>
>> [...]
>>
> Yes. FIT image parsing can be done in that way. However, the idea was
> here to load Image.gz directly. Image.gz is default compressed Linux
> kernel image format in RISC-V.

 Sigh, and the image header is compressed as well, so there's no way to
 identify the image format, right ? And there's no decompressor, so the
 dcompressing has to be done by bootloader, which would need some
 sort of
 very smart way of figuring out which exact compression method is used ?

>>> Yes. Image.gz is always gunzip. So checking first two bytes is enough to
>>> confirm that it is a gz file.
>>
>> What happens once people start feeding it more exotic compression
>> methods, like LZ4 or LZO or LZMA for example ?
>>
> 
> booti command help will clearly state that it can only boot kernel from
> Image or Image.gz.
> 
> static char booti_help_text[] =
>  "[addr [initrd[:size]] [fdt]]\n"
> -    "    - boot arm64 Linux Image stored in memory\n"
> +    "    - boot arm64 Linux Image or riscv Linux Image/Image.gz stored
> in memory\n"

Obvious question -- does this Image.gz stuff apply to arm64 ?

> 
> (I will update the help text with Image.gz part)
> 
> Anything other than that, it will fail with following error.
> 
> "Bad Linux RISCV Image magic!"

Right, so we're implementing file(1)-lite here to detect the format.

>>> The tricky part is length of the compressed file. I took another look at
>>> the gunzip implementation in U-Boot. It looks like to me that compressed
>>> header length just to parse the header correctly. It doesn't actually
>>> use the "length" to decompress. In fact, it updates the length with
>>> uncompressed bytes after the decompression.
>>
>> That's possible.
>>
> 
> David suggested a better idea.
> 
> 1. User can supply kernel_size and we can store in environment variable.
> 2. If the size is empty or greater than CONFIG_SYS_BOOTM_LEN, booti
> fails with appropriate error message.

You can keep decompressing until you reach $bootm_len, sure .

> We will update the documents to add the additional step for Image.gz
> 
> I am fine with either approach. Any preference ?
> 
> Regards,
> Atish


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

Re: [U-Boot] cyclone5 reboot: warm or cold reset?

On 4/30/19 8:56 PM, Simon Goldschmidt wrote:
> Hi all,

Hi,

> I added some of those I think worth discussing this.
> 
> I was chasing a reboot problem on one of our cyclone5 boards today. That
> board boots from a "n25q256a" qspi flash. Up to now, U-Boot configures
> the boot ROM to just jump to OCRAM when rebooting and hope that the SPL
> is still there and fully working (nothing's overwritten).
> 
> For a long running production board, this is of course crap, as a
> pointer running wild could always overwrite the SRAM. But there was not
> much we could do about it as long as U-Boot and/or Linux were putting
> out 32 Mbyte chip into 4-byte mode: it's not accessible by the Boot ROM
> unless in 3-byte mode. And while Linux "reboot" could reset the chip
> into 3-byte mode, "reboot -f" and U-Boot "reset" can't.
> 
> Now with U-Boot and Linux having everything in place to leave the
> spi-nor in 3-byte mode (as required for the Boot ROM) using 4-byte
> opcodes, I thought rebooting from Linux would now work with loading the
> SPL from qspi (by disabling the magic that tells the Boot ROM to jump to
> OCRAM).

Well, if the chip is in the middle of some operation (erase or page
program) and you reset the CPU just at the right moment, leaving the
chip in 3byte addressing mode won't help you anyway.

The only reliable solution is to connect reset to the SPI NOR chip and
trigger the reset. Of course, some SPI NORs have a reset line, but it is
not connected internally, which is a fantastic design. I think the
N25Q256 had exactly such a problem, but only on some revisions, to make
it even more messed up.

> However, I found the Boot ROM still cannot load the SPL because it tries
> to load at 100 MHz (while on cold boot, it loads with 6.25 MHz).

Look at https://patchwork.ozlabs.org/patch/729738/

> However, when triggering cold reset instead of warm reset in rstmgr ctrl
> register [1], it works fine (and qspi clock is 6.25 MHz).
> 
> Now the question is: why do we trigger warm reset instead of cold reset?

I'd like to know that too. But it's likely because of various AMP
setups, where the second CPU or the FPGA do something and you don't want
to interrupt that operation by the primary CPU's reset. I haven't seen
such deployments much myself though.

> Isn't cold reset more stable, e.g. when rebooting watchdog-like? Linux
> also uses warm reset by default, but I'm tempted to send a patch for
> both U-Boot and Linux to use cold reset by default.
> 
> Any insight on the consequences of using cold reset instead of warm
> reset would be really appreciated!
> 
> Regards,
> Simon
> 
> [1]
> https://www.intel.com/content/www/us/en/programmable/hps/cyclone-v/hps.html#topic/sfo1410067764332.html
> 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot


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

Re: [U-Boot] [PATCH 4/4] lib: uuid: Improve randomness of uuid values on RANDOM_UUID=y


On 4/30/19 4:53 AM, Eugeniu Rosca wrote:

The random uuid values (enabled via CONFIG_RANDOM_UUID=y) on our
platform are always the same. Below is consistent on each cold boot:

  => ### interrupt autoboot
  => env default -a; gpt write mmc 1 $partitions; print uuid_gpt_misc
  ...
  uuid_gpt_misc=d117f98e-6f2c-d04b-a5b2-331a19f91cb2
  => env default -a; gpt write mmc 1 $partitions; print uuid_gpt_misc
  ...
  uuid_gpt_misc=ad5ec4b6-2d9f-8544-9417-fe3bd1c9b1b3
  => env default -a; gpt write mmc 1 $partitions; print uuid_gpt_misc
  ...
  uuid_gpt_misc=cceb0b18-39cb-d547-9db7-03b405fa77d4
  => env default -a; gpt write mmc 1 $partitions; print uuid_gpt_misc
  ...
  uuid_gpt_misc=d4981a2b-0478-544e-9607-7fd3c651068d
  => env default -a; gpt write mmc 1 $partitions; print uuid_gpt_misc
  ...
  uuid_gpt_misc=6d6c9a36-e919-264d-a9ee-bd00379686c7

While the uuids do change on every 'gpt write' command, the values
appear to be taken from the same pool, in the same order.

As a user, I expect a trully random uuid value in the above example.
Otherwise, system/RFS designers and OS people might assume they have
a reliable/consistent uuid passed by the bootloader, while the truth
is U-Boot simply lacks entropy to generate a random string.

In its first attempt [1] to improve the uuid randomness, this patch
updated the seed based on the output of get_timer(), similar to [2].

There are two problems with this approach:
  - get_timer() has a poor _ms_ resolution
  - when gen_rand_uuid() is called in a loop, get_timer() returns the
same result, leading to the same seed being passed to srand(),
leading to the same uuid being generated for several partitions
with different names

This second patch addresses both drawbacks.

My R-Car3 testing [3] consists of running 'gpt write mmc 1 $partitions'
in a loop for several minutes collecting 8844 randomly generated UUIDS.
Two consecutive cold boots are concatenated in the log. As a result,
all uuid values are unique (scripted check).

Thanks to Roman, who reported the issue and provided support in fixing.

[1] https://patchwork.ozlabs.org/patch/1091802/
[2] commit da384a9d7628 ("net: rename and refactor eth_rand_ethaddr() function")
[3] https://gist.github.com/erosca/2820be9d554f76b982edd48474d0e7ca
  => while true; do \
 env default -a; \
 gpt write mmc 1 $partitions; \
 print; done

Reported-by: Roman Stratiienko 
Signed-off-by: Eugeniu Rosca 


This patch may ameliorate the situation for GUIDs a bit. But I dislike:

- This patch is a uuid only solution to introduce time ticks as source
  of entropy.
- With timer ticks you possibly introduce very little entropy.
- Our random number generator with only 32 state bits remains
  sub-standard.

This is the current situation:

net/bootp.c uses the MAC address to seed the random number generator and
uses random numbers for defining waits.

lib/uuid.c is using it for UUID generation.

In the UEFI sub-system I would like to implement the EFI_RNG_PROTOCOL.
Linux uses it for randomizing memory layout. iPXE needs it for secure
network connections. This requires a good random number generator with
sufficient entropy.

We already have implemented a single hardware random number generator in
drivers/crypto/ace_sha.c (CONFIG_EXYNOS_ACE_SHA).

Many other CPUs come with a hardware random number generator. In Linux's
drivers/char/hw_random/ I found, e.g.

- meson-rng.c (Amlogic)
- mtk-rng.c (MediaTek)
- st-rng.c (STMicroelectronics)
- imx-rng.c (Freescale)

I think we should have a u-class for hardware RNGs as one source of entropy.

I would like a random number generator with a high number of state bits
(> 127) that we initialize with hardware RNG bits and other sources of
entropy. A nice discussion of how Linux does it can be found in [1].

Best regards

Heinrich

[1]
https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/Studies/LinuxRNG/LinuxRNG_EN.pdf



---
v2:
  - Replaced get_timer(0) with get_ticks() and added rand() to seed value
  - Performed extensive testing on R-Car3 (ARMv8)
v1:
  - https://patchwork.ozlabs.org/patch/1091802/
---
  lib/uuid.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/lib/uuid.c b/lib/uuid.c
index fa20ee39fc32..2d4d6ef7e461 100644
--- a/lib/uuid.c
+++ b/lib/uuid.c
@@ -238,6 +238,8 @@ void gen_rand_uuid(unsigned char *uuid_bin)
unsigned int *ptr = (unsigned int *)
int i;

+   srand(get_ticks() + rand());
+
/* Set all fields randomly */
for (i = 0; i < sizeof(struct uuid) / sizeof(*ptr); i++)
*(ptr + i) = cpu_to_be32(rand());



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

[U-Boot] cyclone5 reboot: warm or cold reset?

Hi all,

I added some of those I think worth discussing this.

However, I found the Boot ROM still cannot load the SPL because it tries
to load at 100 MHz (while on cold boot, it loads with 6.25 MHz).

However, when triggering cold reset instead of warm reset in rstmgr ctrl
register [1], it works fine (and qspi clock is 6.25 MHz).

Now the question is: why do we trigger warm reset instead of cold reset?
Isn't cold reset more stable, e.g. when rebooting watchdog-like? Linux
also uses warm reset by default, but I'm tempted to send a patch for
both U-Boot and Linux to use cold reset by default.

Any insight on the consequences of using cold reset instead of warm
reset would be really appreciated!

Regards,
Simon

[1]
https://www.intel.com/content/www/us/en/programmable/hps/cyclone-v/hps.html#topic/sfo1410067764332.html

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

Re: [U-Boot] [PATCH 1/2 v2] fit: Support compression for non-kernel components (e.g. FDT)


Am 18.04.2019 um 23:08 schrieb Julius Werner:

This patch adds support for compressing non-kernel image nodes in a FIT
image (kernel nodes could already be compressed previously). This can
reduce the size of FIT images and therefore improve boot times
(especially when an image bundles many different kernel FDTs). The
images will automatically be decompressed on load.

This patch does not support extracting compatible strings from
compressed FDTs, so it's not very helpful in conjunction with
CONFIG_FIT_BEST_MATCH yet, but it can already be used in environments
that select the configuration to load explicitly.

Signed-off-by: Julius Werner 
---
  common/image-fit.c | 83 +++---
  1 file changed, 49 insertions(+), 34 deletions(-)

diff --git a/common/image-fit.c b/common/image-fit.c
index ac901e131c..006e828b79 100644
--- a/common/image-fit.c
+++ b/common/image-fit.c
@@ -22,6 +22,7 @@
  DECLARE_GLOBAL_DATA_PTR;
  #endif /* !USE_HOSTCC*/
  
+#include 

  #include 
  #include 
  #include 
@@ -1576,6 +1577,13 @@ int fit_conf_find_compat(const void *fit, const void 
*fdt)
  kfdt_name);
continue;
}
+
+   if (!fit_image_check_comp(fit, kfdt_noffset, IH_COMP_NONE)) {
+   debug("Can't extract compat from \"%s\" (compressed)\n",
+ kfdt_name);
+   continue;
+   }
+


What's this block good for in this patch? Looks like it belongs to 2/2?


/*
 * Get a pointer to this configuration's fdt.
 */
@@ -1795,11 +1803,12 @@ int fit_image_load(bootm_headers_t *images, ulong addr,
const char *fit_uname_config;
const char *fit_base_uname_config;
const void *fit;
-   const void *buf;
+   void *buf;
+   void *loadbuf;
size_t size;
int type_ok, os_ok;
-   ulong load, data, len;
-   uint8_t os;
+   ulong load, load_end, data, len;
+   uint8_t os, comp;
  #ifndef USE_HOSTCC
uint8_t os_arch;
  #endif
@@ -1895,12 +1904,6 @@ int fit_image_load(bootm_headers_t *images, ulong addr,
images->os.arch = os_arch;
  #endif
  
-	if (image_type == IH_TYPE_FLATDT &&

-   !fit_image_check_comp(fit, noffset, IH_COMP_NONE)) {
-   puts("FDT image is compressed");
-   return -EPROTONOSUPPORT;
-   }
-
bootstage_mark(bootstage_id + BOOTSTAGE_SUB_CHECK_ALL);
type_ok = fit_image_check_type(fit, noffset, image_type) ||
  fit_image_check_type(fit, noffset, IH_TYPE_FIRMWARE) ||
@@ -1931,7 +1934,8 @@ int fit_image_load(bootm_headers_t *images, ulong addr,
bootstage_mark(bootstage_id + BOOTSTAGE_SUB_CHECK_ALL_OK);
  
  	/* get image data address and length */

-   if (fit_image_get_data_and_size(fit, noffset, , )) {
+   if (fit_image_get_data_and_size(fit, noffset,
+   (const void **), )) {
printf("Could not find %s subimage data!\n", prop_name);
bootstage_error(bootstage_id + BOOTSTAGE_SUB_GET_DATA);
return -ENOENT;
@@ -1939,30 +1943,15 @@ int fit_image_load(bootm_headers_t *images, ulong addr,
  
  #if !defined(USE_HOSTCC) && defined(CONFIG_FIT_IMAGE_POST_PROCESS)

/* perform any post-processing on the image data */
-   board_fit_image_post_process((void **), );
+   board_fit_image_post_process(, );
  #endif
  
  	len = (ulong)size;
  
-	/* verify that image data is a proper FDT blob */

-   if (image_type == IH_TYPE_FLATDT && fdt_check_header(buf)) {
-   puts("Subimage data is not a FDT");
-   return -ENOEXEC;
-   }
-
bootstage_mark(bootstage_id + BOOTSTAGE_SUB_GET_DATA_OK);
  
-	/*

-* Work-around for eldk-4.2 which gives this warning if we try to
-* cast in the unmap_sysmem() call:
-* warning: initialization discards qualifiers from pointer target type
-*/
-   {
-   void *vbuf = (void *)buf;
-
-   data = map_to_sysmem(vbuf);
-   }
-
+   data = map_to_sysmem(buf);
+   load = data;
if (load_op == FIT_LOAD_IGNORED) {
/* Don't load */
} else if (fit_image_get_load(fit, noffset, )) {
@@ -1974,8 +1963,6 @@ int fit_image_load(bootm_headers_t *images, ulong addr,
}
} else if (load_op != FIT_LOAD_OPTIONAL_NON_ZERO || load) {
ulong image_start, image_end;
-   ulong load_end;
-   void *dst;
  
  		/*

 * move image data to the load address,
@@ -1993,14 +1980,42 @@ int fit_image_load(bootm_headers_t *images, ulong addr,
  
  		printf("   Loading %s from 0x%08lx to 0x%08lx\n",

   prop_name, data, load);
+   }
  
-		dst = map_sysmem(load, len);

-   memmove(dst, buf, len);
-   data = load;
+

Re: [U-Boot] [PATCH 1/2 v2] fit: Support compression for non-kernel components (e.g. FDT)


Am 30.04.2019 um 06:05 schrieb Simon Goldschmidt:



Julius Werner mailto:jwer...@chromium.org>> 
schrieb am Di., 30. Apr. 2019, 02:38:


 > However, compared to my above mentioned RFC patch, this here somehow
 > fails when loading something from the image, e.g. using the cmd 'fpga
 > loadmk'. Seems like this one doesn't transparently uncompress?

It looks to me like do_fpga_loadmk() doesn't actually call
fit_load_image()? It calls fit_image_get_data() directly, so it
bypasses the code I'm adding. Maybe it should be using
fit_load_image() instead, but that's moving pretty far away from what
I was trying to do... it could be left for a later patch?


Ah, ok. I wasn't aware I had changed that command too :-) let me 
concentrate on finding out why booting the compressed fit,image doesn't 
work, then.


OK, so it turns out the error was on my side somewhere. I tested this 
with a known-to-work configuration at work today and it works like a 
charm, so I'll start to comment the contents of the patch again ;-)


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

Re: [U-Boot] [PATCH v2 2/2] RISCV: image: Parse Image.gz support in booti.

2019-04-30 Thread Atish Patra


On 4/30/19 2:52 AM, Marek Vasut wrote:

On 4/30/19 3:27 AM, Atish Patra wrote:

[...]


Yes. FIT image parsing can be done in that way. However, the idea was
here to load Image.gz directly. Image.gz is default compressed Linux
kernel image format in RISC-V.


Sigh, and the image header is compressed as well, so there's no way to
identify the image format, right ? And there's no decompressor, so the
dcompressing has to be done by bootloader, which would need some sort of
very smart way of figuring out which exact compression method is used ?


Yes. Image.gz is always gunzip. So checking first two bytes is enough to
confirm that it is a gz file.


What happens once people start feeding it more exotic compression
methods, like LZ4 or LZO or LZMA for example ?



booti command help will clearly state that it can only boot kernel from 
Image or Image.gz.


static char booti_help_text[] =
"[addr [initrd[:size]] [fdt]]\n"
-   "- boot arm64 Linux Image stored in memory\n"
+	"- boot arm64 Linux Image or riscv Linux Image/Image.gz stored in 
memory\n"


(I will update the help text with Image.gz part)

Anything other than that, it will fail with following error.

"Bad Linux RISCV Image magic!"


The tricky part is length of the compressed file. I took another look at
the gunzip implementation in U-Boot. It looks like to me that compressed
header length just to parse the header correctly. It doesn't actually
use the "length" to decompress. In fact, it updates the length with
uncompressed bytes after the decompression.


That's possible.



David suggested a better idea.

1. User can supply kernel_size and we can store in environment variable.
2. If the size is empty or greater than CONFIG_SYS_BOOTM_LEN, booti 
fails with appropriate error message.


We will update the documents to add the additional step for Image.gz

I am fine with either approach. Any preference ?

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

Re: [U-Boot] [PATCH 3/4] cmd: gpt: fix and tidy up help message


On 4/30/19 4:53 AM, Eugeniu Rosca wrote:

Apply the following changes:
  - Guard the 'gpt read' command by 'ifdef CONFIG_CMD_GPT_RENAME',
since 'gpt read' is not available on CMD_GPT_RENAME=n
  - Prefix the {read,swap,rename} commands with one space for consistency
  - Prefix the 'guid' commands with 'gpt' for consistency

Signed-off-by: Eugeniu Rosca 


Reviewed-by: Heinrich Schuchardt 

Non-related:
doc/README.commands describes the preferred way to implement sub-commands.


---
  cmd/gpt.c | 12 ++--
  1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/cmd/gpt.c b/cmd/gpt.c
index 638870352f40..33cda513969f 100644
--- a/cmd/gpt.c
+++ b/cmd/gpt.c
@@ -876,21 +876,21 @@ U_BOOT_CMD(gpt, CONFIG_SYS_MAXARGS, 1, do_gpt,
" Example usage:\n"
" gpt write mmc 0 $partitions\n"
" gpt verify mmc 0 $partitions\n"
-   " read  \n"
-   "- read GPT into a data structure for manipulation\n"
-   " guid  \n"
+   " gpt guid  \n"
"- print disk GUID\n"
-   " guid   \n"
+   " gpt guid   \n"
"- set environment variable to disk GUID\n"
" Example usage:\n"
" gpt guid mmc 0\n"
" gpt guid mmc 0 varname\n"
  #ifdef CONFIG_CMD_GPT_RENAME
"gpt partition renaming commands:\n"
-   "gpt swap\n"
+   " gpt read  \n"
+   "- read GPT into a data structure for manipulation\n"
+   " gpt swap\n"
"- change all partitions named name1 to name2\n"
"  and vice-versa\n"
-   "gpt rename\n"
+   " gpt rename\n"
"- rename the specified partition\n"
" Example usage:\n"
" gpt swap mmc 0 foo bar\n"



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

Re: [U-Boot] [PATCH 2/4] disk: efi: Fix memory leak on 'gpt verify'


On 4/30/19 4:53 AM, Eugeniu Rosca wrote:

Below is what happens on R-Car H3ULCB-KF using clean U-Boot
v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig:

  => ### interrupt autoboot
  => gpt verify mmc 1
  No partition list provided - only basic check
  Verify GPT: success!
  => ### keep calling 'gpt verify mmc 1'
  => ### on 58th call, we are out of memory:
  => gpt verify mmc 1
  alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries
  GPT: Failed to allocate memory for PTE
  gpt_verify_headers: *** ERROR: Invalid Backup GPT ***
  Verify GPT: error!

This is caused by calling is_gpt_valid() twice (hence allocating pte
also twice via alloc_read_gpt_entries()) while freeing pte only _once_
in the caller of gpt_verify_headers(). Fix that by freeing the pte
allocated and populated for primary GPT _before_ allocating and
populating the pte for backup GPT. The latter will be freed by the
caller of gpt_verify_headers().

With the fix applied, the reproduction scenario [1-2] has been run
hundreds of times in a loop w/o running into OOM.

[1] gpt verify mmc 1
[2] gpt verify mmc 1 $partitions

Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification 
functions")
Signed-off-by: Eugeniu Rosca 

Reviewed-by: Heinrich Schuchardt 


---
  disk/part_efi.c | 4 
  1 file changed, 4 insertions(+)

diff --git a/disk/part_efi.c b/disk/part_efi.c
index 812d14cdd871..c0fa753339c8 100644
--- a/disk/part_efi.c
+++ b/disk/part_efi.c
@@ -698,6 +698,10 @@ int gpt_verify_headers(struct blk_desc *dev_desc, 
gpt_header *gpt_head,
   __func__);
return -1;
}
+
+   /* Free pte before allocating again */
+   free(*gpt_pte);
+
if (is_gpt_valid(dev_desc, (dev_desc->lba - 1),
 gpt_head, gpt_pte) != 1) {
printf("%s: *** ERROR: Invalid Backup GPT ***\n",



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

Re: [U-Boot] [PATCH 1/4] disk: efi: Fix memory leak on 'gpt guid'


On 4/30/19 4:53 AM, Eugeniu Rosca wrote:

Below is what happens on R-Car H3ULCB-KF using clean U-Boot
v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig:

  => ### interrupt autoboot
  => gpt guid mmc 1
  21200400-0804-0146-9dcc-a8c51255994f
  success!
  => ### keep calling 'gpt guid mmc 1'
  => ### on 59th call, we are out of memory:
  => gpt guid mmc 1
  alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries
  GPT: Failed to allocate memory for PTE
  get_disk_guid: *** ERROR: Invalid GPT ***
  alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries
  GPT: Failed to allocate memory for PTE
  get_disk_guid: *** ERROR: Invalid Backup GPT ***
  error!

After some inspection, it looks like get_disk_guid(), added via v2017.09
commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"),
unlike other callers of is_gpt_valid(), doesn't free the memory pointed
out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid()
via alloc_read_gpt_entries().

With the fix applied, the reproduction scenario has been run hundreds
of times ('while true; do gpt guid mmc 1; done') w/o running into OOM.

Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID")
Signed-off-by: Eugeniu Rosca 


Reviewed-by: Heinrich Schuchardt 


---
  disk/part_efi.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/disk/part_efi.c b/disk/part_efi.c
index 239455b8161e..812d14cdd871 100644
--- a/disk/part_efi.c
+++ b/disk/part_efi.c
@@ -209,6 +209,8 @@ int get_disk_guid(struct blk_desc * dev_desc, char *guid)
guid_bin = gpt_head->disk_guid.b;
uuid_bin_to_str(guid_bin, guid, UUID_STR_FORMAT_GUID);

+   /* Remember to free pte */
+   free(gpt_pte);
return 0;
  }




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

Re: [U-Boot] Booting MX6 via Serial Download after DM conversion

2019-04-30 Thread Fabio Estevam

Hi Tom,

On Mon, Apr 29, 2019 at 2:57 PM Tom Rini  wrote:

> imx_usb is doing some checking of the second binary it sends along?
> That sounds odd to start with, is there some specific history there?

My understanding is that imx_usb_loader expects to find a valid IVT entry.

After the conversion to DM, a FIT image is used on
mx6sabresd_defconfig and such IVT can no longer be found, causing
imx_usb_loader to fail to loading u-boot-dtb.img.

It would be nice if we can come up with a solution, as loosing the
ability to load via imx_usb_loader has a negative impact for users.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] ti: Add am335x-pocketbeagle to am335x_evm_defconfig.

On Tue, Apr 30, 2019 at 10:02:11AM -0700, Vagrant Cascadian wrote:
> On 2019-04-30, Tom Rini wrote:
> > On Mon, Apr 29, 2019 at 04:12:30PM -0700, Vagrant Cascadian wrote:
> >
> >> Add am335x-pocketbeagle to CONFIG_OF_LIST in am335x_evm_defconfig.
> >> 
> >> Signed-off-by: Vagrant Cascadian 
> >
> > We need to update include/configs/am335x_evm.h too so that it detects
> > this variant and loads the right dtb.
> 
> I believe this was already added in the original commit that added
> partial support:
> 
>   "findfdt="\
> ...
>   "if test $board_name = A335PBGL; then " \
>   "setenv fdtfile am335x-pocketbeagle.dtb; fi; " \
> 
> 
> In my tests, it loaded the correct .dtb file; Is there something I'm
> missing?

Nope, I missed that it was there, 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] i2c: mxc: Hide kconfig based control in DM_I2C mode

On Tue, 2019-04-30 at 09:20 +0200, Heiko Schocher wrote:
> > Am 12.04.2019 um 21:19 schrieb Trent Piepho:
> > > These options only apply when not using DM_I2C.  When using device
> > > trees, the dt will enable and control the speeds of the I2C
> > > controller(s) and these configuration options have no effect.
> > > 
> > > So disable them in DM_I2C mode.  Otherwise they show up as decoys, and
> > > make it look like one is enabling I2C controllers and setting the speed
> > > when really it's doing nothing.

> arm:  +   wandboard
> +board/wandboard/wandboard.c: In function 'board_init':
> +board/wandboard/wandboard.c:466:15: error: 'CONFIG_SYS_MXC_I2C1_SPEED' 
> undeclared (first use in 
> this function); did you mean 'CONFIG_SYS_MMC_ENV_DEV'?
> +  setup_i2c(1, CONFIG_SYS_MXC_I2C1_SPEED, 0x7f, _i2c2_pad_info);
> +   ^
> +   CONFIG_SYS_MMC_ENV_DEV
> +board/wandboard/wandboard.c:466:15: note: each undeclared identifier is 
> reported only once for each 
> function it appears in
> +board/wandboard/wandboard.c:469:16: error: 'CONFIG_SYS_MXC_I2C2_SPEED' 
> undeclared (first use in 
> this function); did you mean 'CONFIG_SYS_MXC_I2C1_SPEED'?
> +   setup_i2c(2, CONFIG_SYS_MXC_I2C2_SPEED, 0x7f, _i2c3_pad_info);
> +^
> +CONFIG_SYS_MXC_I2C1_SPEED
> +make[2]: *** [board/wandboard/wandboard.o] Error 1
> +make[1]: *** [board/wandboard] Error 2
> +make: *** [sub-make] Error 2
> 
> Please check.

This is caused by a conflict with "imx6: wandboard: convert to DM_I2C",
which was applied after I sent my patch.  

I'm not sure if that commit is correct. Copying Anatolij.

It's the only place where non-DM_I2C code uses the kconfig based
configuration of I2C.  If we look at the code in question:

setup_i2c(1, CONFIG_SYS_MXC_I2C1_SPEED, 0x7f, _i2c2_pad_info);

Seems a bit odd bus 1 is being configured with i2c*2* pad info?  But
let's take a look at setup_i2c().

int setup_i2c(unsigned i2c_index, int speed, int slave_addr,
  struct i2c_pads_info *p)
{

/* Enable i2c clock */
ret = enable_i2c_clk(1, i2c_index);
if (ret)
goto err_clk;

/* Make sure bus is idle */
ret = force_idle_bus(p);
if (ret)
goto err_idle;

#ifndef CONFIG_DM_I2C
bus_i2c_init(i2c_index, speed, slave_addr, force_idle_bus, p);
#endif
return 0;
 
err_idle:
err_clk:
gpio_free(p->scl.gp);
err_req:
gpio_free(p->sda.gp);

return ret;
}

Nothing in the elided section uses "speed".  It's only used in the
bus_i2c_init() call, and that call is not made when using DM_I2C!

So while the wandboard code references CONFIG_SYS_MXC_I2C1_SPEED when
using DM_i2C, it's never used by anything.

So I believe I'm still correct, even after the wandboard change that
CONFIG_SYS_MXC_I2C1_SPEED et al are decoys that aren't used.

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

Re: [U-Boot] [PATCH] Makefile: Create single image for imx6 socs based boards

On 30/04/19 19:08, Jagan Teki wrote:
> On Tue, Apr 30, 2019 at 10:30 PM Stefano Babic  wrote:
>>
>> On 30/04/19 18:56, Jagan Teki wrote:
>>> Hi Stefano,
>>>
>>> On Tue, Apr 30, 2019 at 9:36 PM Stefano Babic  wrote:

 Hi Shyam,

 On 30/04/19 12:33, Shyam Saini wrote:
> IMX6 platform has two stage boot loaders like SPL and
> U-Boot proper. For each stage we need to burn the image
> on to flash with respective offsets.
>
> This patch create a single image using binman, so that
> user can get rid of burning different stage boot images.
>
> without this patch:
> --
> $ sudo dd if=SPL of=/dev/mmcblk0 bs=1k seek=1
> $ sudo dd if=u-boot-dtb.img of=/dev/mmcblk0 bs=1k seek=69
>
> with this patch:
> ---
> $ sudo dd if=u-boot-imx6-with-spl.bin of=/dev/mmcblk0 bs=1k seek=1
>

 I am quite confused. There is already a "u-boot-with-spl.imx" target,
 this works since a lot of time. Which is the reason to duplicate this
 feature or where is the difference ?
>>>
>>> At-least I did noticed this now,  since it require explicit 'make
>>> u-boot-with-spl.bin'  I hardly unaware before this been available for
>>> i.mx6.
>>>
>>> But, this binman feature more extensible than the Makefile oriented
>>> and the same been adopting by many platforms. May be we can come-up
>>> with common solution with binman, what do you think?
>>
>> First, I would like to avoid to have the same feature implemented
>> multiple times in different ways.
> 
> As I said, we didn't know this was supported before since it require
> an explicit argument to build..it's our bad.

No problem ;-) - there are so many new features / targets in U-Boot, I
think I know just a small percentage of them.. ;-)

> 
>>
>> If we can get the same solution for all platform, fine. But I guess i.MX
>> is not the only one having such as target, socFPGA has the same solution.
> 
> Okay.

Best regards,
Stefano


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

Re: [U-Boot] [PATCH] Makefile: Create single image for imx6 socs based boards

2019-04-30 Thread Jagan Teki

On Tue, Apr 30, 2019 at 10:30 PM Stefano Babic  wrote:
>
> On 30/04/19 18:56, Jagan Teki wrote:
> > Hi Stefano,
> >
> > On Tue, Apr 30, 2019 at 9:36 PM Stefano Babic  wrote:
> >>
> >> Hi Shyam,
> >>
> >> On 30/04/19 12:33, Shyam Saini wrote:
> >>> IMX6 platform has two stage boot loaders like SPL and
> >>> U-Boot proper. For each stage we need to burn the image
> >>> on to flash with respective offsets.
> >>>
> >>> This patch create a single image using binman, so that
> >>> user can get rid of burning different stage boot images.
> >>>
> >>> without this patch:
> >>> --
> >>> $ sudo dd if=SPL of=/dev/mmcblk0 bs=1k seek=1
> >>> $ sudo dd if=u-boot-dtb.img of=/dev/mmcblk0 bs=1k seek=69
> >>>
> >>> with this patch:
> >>> ---
> >>> $ sudo dd if=u-boot-imx6-with-spl.bin of=/dev/mmcblk0 bs=1k seek=1
> >>>
> >>
> >> I am quite confused. There is already a "u-boot-with-spl.imx" target,
> >> this works since a lot of time. Which is the reason to duplicate this
> >> feature or where is the difference ?
> >
> > At-least I did noticed this now,  since it require explicit 'make
> > u-boot-with-spl.bin'  I hardly unaware before this been available for
> > i.mx6.
> >
> > But, this binman feature more extensible than the Makefile oriented
> > and the same been adopting by many platforms. May be we can come-up
> > with common solution with binman, what do you think?
>
> First, I would like to avoid to have the same feature implemented
> multiple times in different ways.

As I said, we didn't know this was supported before since it require
an explicit argument to build..it's our bad.

>
> If we can get the same solution for all platform, fine. But I guess i.MX
> is not the only one having such as target, socFPGA has the same solution.

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

Re: [U-Boot] [PATCH 2/2] ti: Add am335x-pocketbeagle to am335x_evm_defconfig.

2019-04-30 Thread Vagrant Cascadian

On 2019-04-30, Tom Rini wrote:
> On Mon, Apr 29, 2019 at 04:12:30PM -0700, Vagrant Cascadian wrote:
>
>> Add am335x-pocketbeagle to CONFIG_OF_LIST in am335x_evm_defconfig.
>> 
>> Signed-off-by: Vagrant Cascadian 
>
> We need to update include/configs/am335x_evm.h too so that it detects
> this variant and loads the right dtb.

I believe this was already added in the original commit that added
partial support:

"findfdt="\
...
"if test $board_name = A335PBGL; then " \
"setenv fdtfile am335x-pocketbeagle.dtb; fi; " \


In my tests, it loaded the correct .dtb file; Is there something I'm
missing?


live well,
  vagrant


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] Makefile: Create single image for imx6 socs based boards

On 30/04/19 18:56, Jagan Teki wrote:
> Hi Stefano,
> 
> On Tue, Apr 30, 2019 at 9:36 PM Stefano Babic  wrote:
>>
>> Hi Shyam,
>>
>> On 30/04/19 12:33, Shyam Saini wrote:
>>> IMX6 platform has two stage boot loaders like SPL and
>>> U-Boot proper. For each stage we need to burn the image
>>> on to flash with respective offsets.
>>>
>>> This patch create a single image using binman, so that
>>> user can get rid of burning different stage boot images.
>>>
>>> without this patch:
>>> --
>>> $ sudo dd if=SPL of=/dev/mmcblk0 bs=1k seek=1
>>> $ sudo dd if=u-boot-dtb.img of=/dev/mmcblk0 bs=1k seek=69
>>>
>>> with this patch:
>>> ---
>>> $ sudo dd if=u-boot-imx6-with-spl.bin of=/dev/mmcblk0 bs=1k seek=1
>>>
>>
>> I am quite confused. There is already a "u-boot-with-spl.imx" target,
>> this works since a lot of time. Which is the reason to duplicate this
>> feature or where is the difference ?
> 
> At-least I did noticed this now,  since it require explicit 'make
> u-boot-with-spl.bin'  I hardly unaware before this been available for
> i.mx6.
> 
> But, this binman feature more extensible than the Makefile oriented
> and the same been adopting by many platforms. May be we can come-up
> with common solution with binman, what do you think?

First, I would like to avoid to have the same feature implemented
multiple times in different ways.

If we can get the same solution for all platform, fine. But I guess i.MX
is not the only one having such as target, socFPGA has the same solution.

Regards,
Stefano


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

Re: [U-Boot] [PATCH] Makefile: Create single image for imx6 socs based boards

2019-04-30 Thread Jagan Teki

Hi Stefano,

On Tue, Apr 30, 2019 at 9:36 PM Stefano Babic  wrote:
>
> Hi Shyam,
>
> On 30/04/19 12:33, Shyam Saini wrote:
> > IMX6 platform has two stage boot loaders like SPL and
> > U-Boot proper. For each stage we need to burn the image
> > on to flash with respective offsets.
> >
> > This patch create a single image using binman, so that
> > user can get rid of burning different stage boot images.
> >
> > without this patch:
> > --
> > $ sudo dd if=SPL of=/dev/mmcblk0 bs=1k seek=1
> > $ sudo dd if=u-boot-dtb.img of=/dev/mmcblk0 bs=1k seek=69
> >
> > with this patch:
> > ---
> > $ sudo dd if=u-boot-imx6-with-spl.bin of=/dev/mmcblk0 bs=1k seek=1
> >
>
> I am quite confused. There is already a "u-boot-with-spl.imx" target,
> this works since a lot of time. Which is the reason to duplicate this
> feature or where is the difference ?

At-least I did noticed this now,  since it require explicit 'make
u-boot-with-spl.bin'  I hardly unaware before this been available for
i.mx6.

But, this binman feature more extensible than the Makefile oriented
and the same been adopting by many platforms. May be we can come-up
with common solution with binman, what do you think?

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

Re: [U-Boot] [PATCH] test/py: don't use mmc_rd config for other mmc tests

On 4/30/19 5:29 PM, Stephen Warren wrote:
> On 4/16/19 4:04 PM, Stephen Warren wrote:
>> From: Stephen Warren 
>>
>> Fix test_mmc_dev(), test_mmc_rescan(), test_mmc_info() not to use the
>> same configuration data that test_mmc_rd() does. Doing so causes the
>> following issues:
>>
>> * The new code uncondtionally expects certain keys to exist in the
>> configuration data. These keys do not exist in existing configuration
>> data since they were not previously required, and there was no
>> notification re: a requirement to add these new keys. This causes test
>> failures due to thrown exceptions when accessing the non-existent keys.
>>
>> * The new tests logically operate on different objects. test_mmc_rd()
>> operates on ranges of sectors on an MMC device (which may be the entire
>> set of sectors of a device, or a part of a device), whereas all the new
>> tests operate solely on entire devices. These are separate things, and
>> it's entirely likely that the user will wish to runs the two types of
>> tests on different sets of data; see the example configuration data that
>> this commit adds. Ideally, the new tests would have been added to a
>> separate Python file, since they aren' closely related to the existing
>> tests.
>>
>> FIXME: Marek, can you please replace the "???" in this patch with some
>> reasonable looking data? Thanks.
> 
> Tom, Marek, any chance of applying this? Right now, every mainline
> branch is failing 5 tests on every push, which wastes my time having to
> go through all the logs to manually check that the failures aren't
> anything new/unknown. Thanks.

I'm still overloaded, and didn't have time to look into this. But I'm
really not fond of the duplication here -- now we have two big tables
describing very much the same thing, which SD/MMC to test .

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

[U-Boot] [PATCH] board: stm32mp1: Update power supply check via USB TYPE-C

Add 2 new checks:
 - detect when USB TYPE-C cable is not plugged correctly.
   In this case, GND and VBUS pins are connected but not CC1
   and CC2 pins.

 - detect is an USB Type-C charger supplies more than 3 Amps
   which is not compliant with the USB Type-C specification

In these 2 situations, stop the boot process and let red led
blinks forever.

   V cc1  |   V cc2 | power supply | red led | console message
range (Volts) |range (Volts)|   (Amps) | blinks  |
--|-|--|-|---
> 2.15|   < 0.2 | > 3  | for ever| USB TYPE-C charger not 
compliant with specification
[2.15 - 1.23[ |   < 0.2 | 3|   NO| NO
[1.23 - 0.66[ |   < 0.2 | 1.5  | 3 times | WARNING 1.5A power 
supply detected
[0.66 - 0]|   < 0.2 | 0.5  | 2 times | WARNING 500mA power 
supply detected
< 0.2 |   < 0.2 |  | for ever| ERROR USB TYPE-C 
connection in unattached mode
> 0.2 |   > 0.2 |  | for ever| ERROR USB TYPE-C 
connection in unattached mode

Signed-off-by: Patrice Chotard 
---

 board/st/stm32mp1/stm32mp1.c | 69 +++-
 1 file changed, 56 insertions(+), 13 deletions(-)

diff --git a/board/st/stm32mp1/stm32mp1.c b/board/st/stm32mp1/stm32mp1.c
index 76917b0..8c591a5 100644
--- a/board/st/stm32mp1/stm32mp1.c
+++ b/board/st/stm32mp1/stm32mp1.c
@@ -60,9 +60,10 @@
  */
 DECLARE_GLOBAL_DATA_PTR;
 
+#define USB_LOW_THRESHOLD_UV   20
 #define USB_WARNING_LOW_THRESHOLD_UV   66
 #define USB_START_LOW_THRESHOLD_UV 123
-#define USB_START_HIGH_THRESHOLD_UV210
+#define USB_START_HIGH_THRESHOLD_UV215
 
 int checkboard(void)
 {
@@ -263,9 +264,10 @@ static int board_check_usb_power(void)
ofnode node;
unsigned int raw;
int max_uV = 0;
+   int min_uV = USB_START_HIGH_THRESHOLD_UV;
int ret, uV, adc_count;
-   u8 i, nb_blink;
-
+   u32 nb_blink;
+   u8 i;
node = ofnode_path("/config");
if (!ofnode_valid(node)) {
debug("%s: no /config node?\n", __func__);
@@ -317,6 +319,8 @@ static int board_check_usb_power(void)
if (!adc_raw_to_uV(adc, raw, )) {
if (uV > max_uV)
max_uV = uV;
+   if (uV < min_uV)
+   min_uV = uV;
pr_debug("%s: %s[%02d] = %u, %d uV\n", __func__,
 adc->name, adc_args.args[0], raw, uV);
} else {
@@ -331,27 +335,66 @@ static int board_check_usb_power(void)
 * continue.
 */
if (max_uV > USB_START_LOW_THRESHOLD_UV &&
-   max_uV < USB_START_HIGH_THRESHOLD_UV)
+   max_uV <= USB_START_HIGH_THRESHOLD_UV &&
+   min_uV <= USB_LOW_THRESHOLD_UV)
return 0;
 
-   /* Display warning message and make u-boot,error-led blinking */
-   pr_err("\n***\n");
+   pr_err("\n");
+
+   /*
+* If highest and lowest value are either both below
+* USB_LOW_THRESHOLD_UV or both above USB_LOW_THRESHOLD_UV, that
+* means USB TYPE-C is in unattached mode, this is an issue, make
+* u-boot,error-led blinking and stop boot process.
+*/
+   if ((max_uV > USB_LOW_THRESHOLD_UV &&
+min_uV > USB_LOW_THRESHOLD_UV) ||
+(max_uV <= USB_LOW_THRESHOLD_UV &&
+min_uV <= USB_LOW_THRESHOLD_UV)) {
+   pr_err("* ERROR USB TYPE-C connection in unattached mode   
*\n");
+   pr_err("* Check that USB TYPE-C cable is correctly plugged 
*\n");
+   /* with 125ms interval, led will blink for 17.02 years */
+   nb_blink = U32_MAX;
+   }
 
-   if (max_uV < USB_WARNING_LOW_THRESHOLD_UV) {
-   pr_err("*   WARNING 500mA power supply detected   *\n");
+   if (max_uV > USB_LOW_THRESHOLD_UV &&
+   max_uV <= USB_WARNING_LOW_THRESHOLD_UV &&
+   min_uV <= USB_LOW_THRESHOLD_UV) {
+   pr_err("*WARNING 500mA power supply detected   
*\n");
nb_blink = 2;
-   } else {
-   pr_err("* WARNING 1.5A power supply detected  *\n");
+   }
+
+   if (max_uV > USB_WARNING_LOW_THRESHOLD_UV &&
+   max_uV <= USB_START_LOW_THRESHOLD_UV &&
+   min_uV <= USB_LOW_THRESHOLD_UV) {
+   pr_err("*   WARNING 1.5mA power supply detected
*\n");
nb_blink = 3;
}
 
-   pr_err("* Current too low, use a 3A power supply! *\n");
-   pr_err("***\n\n");
+   /*
+* If highest value is above 2.15 Volts that means that the USB TypeC
+* supplies more than 3 Amp, this is not compliant

[U-Boot] Pull request: u-boot-imx u-boot-imx-20190426

Hi Tom,

next chunk of patches, another big chunk will follow. Please pull from
u-boot-imx, thanks !

Travis:
---
https://travis-ci.org/sbabic/u-boot-imx/builds/524580462

The following changes since commit 3fbd2dce351ab5d40d3244f26bd713caa4f826e2:

  Merge branch '2019-04-22-master-imports' (2019-04-24 09:04:23 -0400)

are available in the Git repository at:

  git://www.denx.de/git/u-boot-imx.git tags/u-boot-imx-20190426

for you to fetch changes up to 0d3912fcd41dc2a85891f78e8fc255a379323619:

  colibri_imx6: use UUID for rootfs (2019-04-25 19:21:40 +0200)


Porting to DM and i.MX8


- warp7 to DM
- kp_imx53 to DM
- Warnings in DT
- MX8QM support
- colibri-imx6ull to DM
- imx7d-pico to DM
- ocotp for MX8


Adam Ford (3):
  ARM: imx6q_logic: Allow optional arguments to cmd line
  ARM: imx6q_logic: Allow storing environment in FAT on eMMC
  ARM: omap3_logic: Enable UUID

Chris Packham (1):
  ARM: imx: Fix typo in select option for ZMX25

Filip Brozovic (1):
  dts: imx6ull: add USB aliases to support DM

Gerard Salvatella (1):
  tdx-cfg-block: add support for new colibri iMX6ull skus

Igor Opaniuk (1):
  colibri_imx6: use UUID for rootfs

Joris Offouga (5):
  Arm: imx7d-pico: Import all Linux device tree for Pico i.MX7D SOM
  pico-imx7d: defconfig: Add DT file hooks
  pico-imx7d: defconfig Enable DM gpio pinctrl and pinctrl_imx7
  pico-imx7d: Convert DM MMC
  pico-imx7d: Increase u-boot size for dfu request

Ludwig Zenz (2):
  ARM: imx6: update 1GB DDR3 calibration for DHCOM i.MX6qd PDK
  ARM: imx6: DHCOM i.MX6 PDK: use Kconfig for inclusion of DDR
calibration

Lukasz Majewski (14):
  ARM: Remove HSC|DDC ETH PHY reset code after switching to DM/DTS
  DTS: Add esdhc3 device tree description tuning for HSC|DDC boards
  ARM: Enable CONFIG_DM_MMC and CONFIG_DM_BLK on HSC and DDC boards
  ARM: defconfig: Move CONFIG_FSL_ESDHC to Kconfig
  ARM: Remove non DM/DTS esdhc3 code from HSC|DDC board related files
  ARM: kp_imx53: config: Do not use ${boardtype} to setup update wic
file
  DTS: Provide USB host DTS description for i.MX53 devices
  DTS: Enable USB host support (including regulators) on HSC|DDC boards
  ARM: Remove EHCI specific code from HSC|DDC board file
  USB: DM: Convert i.MX5 ehci code to driver model
  ARM: defconfig: kp_imx53: Enable DM_USB support on HSC|DDC boards
  ARM: config: Remove not needed CONFIG_MXC_USB_PORT define
  Convert CONFIG_USB_EHCI_MX5 to Kconfig
  boot.src: Provide dsa_core.blacklist bootarg when booting via NFS

Marcel Ziswiler (16):
  colibri_vf: fix ethernet by adding explicit phy node
  colibri_vf: fix tab vs. spaces
  colibri-imx6ull: fix ethernet phy power on
  colibri-imx6ull: configuration clean-up
  colibri-imx6ull: migrate pinctrl and regulators to dtb/dm
  colibri-imx6ull: migrate mmc to using driver model
  colibri-imx6ull: migrate usb to using driver model
  colibri-imx6ull: migrate fec to using driver model
  ARM: dts: colibri-imx6ull: fix uart-has-rtscts property
  misc: imx8: remove duplicates from scfw api
  arm: dts: imx8dx: add lpuart1, lpuart2, lpuart3
  board: toradex: tdx-cfg-block: clean-up sku handling
  board: toradex: tdx-cfg-block: add new skus
  ARM: dts: i.MX6Q: fix avoid_unnecessary_addr_size warnings
  ARM: dts: colibri-imx6ull: add osc32k_32k_out pinctrl
  ARM: dts: colibri-imx6ull: update device tree

Parthiban Nallathambi (1):
  imx: Add variscite DART-6UL Evaluation Kit

Peng Fan (19):
  imx: sip: add call_imx_sip_ret2
  imx8: fuse: add fuse driver
  imx8qxp: mek: Enable CMD_FUSE
  imx8: mek: move HUSH_PARSER to defconfig
  imx8qxp: mek: enable dm-spl for pm
  pinctrl: imx8: add i.MX8QM compatible
  dt-bindings: pinctrl: add i.MX8QM pads definition
  dt-bindings: clock: dt-bindings: pinctrl: add i.MX8QM clocks
definition
  arm: dts: introduce dtsi for i.MX8QM
  imx8: add cpu support
  clk: imx8: split code into common and soc specific part
  clk: imx8: add i.MX8QM clk driver
  imx8: imx8-pins: add i.MX8QM
  misc: imx8: scu: add i.MX8QM support
  imx: support i.MX8QM MEK board
  imx: add lowlevel init for ARM64
  imx: 8qxp_mek: fix fdt_file and console
  imx: i.MX8MQ: clear ocotp error bit
  ddr: imx8m: hide i.MX8M DDR options from device driver entry

Philippe Schenker (1):
  board: imx6ull: Add disable PMIC_STBY_REQ

Pierre-Jean Texier (3):
  warp7: Fix dfu_alt_info setting after DM conversion
  warp7: Switch to DM Serial
  warp7: Switch to DM USB

Stefan Agner (3):
  tdx-cfg-block: simplify i.MX 6 module detection
  colibri-imx6ull: set module variant depending on config block
  apalis/colibri_imx6/imx6ull:

[U-Boot] [PATCH 2/3] spi: stm32: Add Serial Peripheral Interface driver for STM32MP

Add SPI driver support for STM32MP SoCs family.

Signed-off-by: Patrice Chotard 
---

 MAINTAINERS |   1 +
 drivers/spi/Kconfig |   8 +
 drivers/spi/Makefile|   1 +
 drivers/spi/stm32_spi.c | 615 
 4 files changed, 625 insertions(+)
 create mode 100644 drivers/spi/stm32_spi.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 09f31cd..020dcd2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -311,6 +311,7 @@ F:  drivers/ram/stm32mp1/
 F: drivers/misc/stm32_rcc.c
 F: drivers/reset/stm32-reset.c
 F: drivers/spi/stm32_qspi.c
+F: drivers/spi/stm32_spi.c
 
 ARM STM STV0991
 M: Vikas Manocha 
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index fb794ad..49bc940 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -228,6 +228,14 @@ config STM32_QSPI
  used to access the SPI NOR flash chips on platforms embedding
  this ST IP core.
 
+config STM32_SPI
+   bool "STM32 SPI driver"
+   depends on ARCH_STM32MP
+   help
+ Enable the STM32 Serial Peripheral Interface (SPI) driver for STM32MP
+ SoCs. This uses driver model and requires a device tree binding to
+ operate.
+
 config TEGRA114_SPI
bool "nVidia Tegra114 SPI driver"
help
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 8be9a4b..3f9f2fa 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -53,6 +53,7 @@ obj-$(CONFIG_SPI_SUNXI) += spi-sunxi.o
 obj-$(CONFIG_SH_SPI) += sh_spi.o
 obj-$(CONFIG_SH_QSPI) += sh_qspi.o
 obj-$(CONFIG_STM32_QSPI) += stm32_qspi.o
+obj-$(CONFIG_STM32_SPI) += stm32_spi.o
 obj-$(CONFIG_TEGRA114_SPI) += tegra114_spi.o
 obj-$(CONFIG_TEGRA20_SFLASH) += tegra20_sflash.o
 obj-$(CONFIG_TEGRA20_SLINK) += tegra20_slink.o
diff --git a/drivers/spi/stm32_spi.c b/drivers/spi/stm32_spi.c
new file mode 100644
index 000..34b2175
--- /dev/null
+++ b/drivers/spi/stm32_spi.c
@@ -0,0 +1,615 @@
+// SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause
+/*
+ * Copyright (C) 2019, STMicroelectronics - All Rights Reserved
+ *
+ * Driver for STMicroelectronics Serial peripheral interface (SPI)
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+/* STM32 SPI registers */
+#define STM32_SPI_CR1  0x00
+#define STM32_SPI_CR2  0x04
+#define STM32_SPI_CFG1 0x08
+#define STM32_SPI_CFG2 0x0C
+#define STM32_SPI_SR   0x14
+#define STM32_SPI_IFCR 0x18
+#define STM32_SPI_TXDR 0x20
+#define STM32_SPI_RXDR 0x30
+#define STM32_SPI_I2SCFGR  0x50
+
+/* STM32_SPI_CR1 bit fields */
+#define SPI_CR1_SPEBIT(0)
+#define SPI_CR1_MASRX  BIT(8)
+#define SPI_CR1_CSTART BIT(9)
+#define SPI_CR1_CSUSP  BIT(10)
+#define SPI_CR1_HDDIR  BIT(11)
+#define SPI_CR1_SSIBIT(12)
+
+/* STM32_SPI_CR2 bit fields */
+#define SPI_CR2_TSIZE  GENMASK(15, 0)
+
+/* STM32_SPI_CFG1 bit fields */
+#define SPI_CFG1_DSIZE GENMASK(4, 0)
+#define SPI_CFG1_DSIZE_MIN 3
+#define SPI_CFG1_FTHLV_SHIFT   5
+#define SPI_CFG1_FTHLV GENMASK(8, 5)
+#define SPI_CFG1_MBR_SHIFT 28
+#define SPI_CFG1_MBR   GENMASK(30, 28)
+#define SPI_CFG1_MBR_MIN   0
+#define SPI_CFG1_MBR_MAX   FIELD_GET(SPI_CFG1_MBR, SPI_CFG1_MBR)
+
+/* STM32_SPI_CFG2 bit fields */
+#define SPI_CFG2_COMM_SHIFT17
+#define SPI_CFG2_COMM  GENMASK(18, 17)
+#define SPI_CFG2_MASTERBIT(22)
+#define SPI_CFG2_LSBFRST   BIT(23)
+#define SPI_CFG2_CPHA  BIT(24)
+#define SPI_CFG2_CPOL  BIT(25)
+#define SPI_CFG2_SSM   BIT(26)
+#define SPI_CFG2_AFCNTRBIT(31)
+
+/* STM32_SPI_SR bit fields */
+#define SPI_SR_RXP BIT(0)
+#define SPI_SR_TXP BIT(1)
+#define SPI_SR_EOT BIT(3)
+#define SPI_SR_TXTFBIT(4)
+#define SPI_SR_OVR BIT(6)
+#define SPI_SR_SUSPBIT(11)
+#define SPI_SR_RXPLVL_SHIFT13
+#define SPI_SR_RXPLVL  GENMASK(14, 13)
+#define SPI_SR_RXWNE   BIT(15)
+
+/* STM32_SPI_IFCR bit fields */
+#define SPI_IFCR_ALL   GENMASK(11, 3)
+
+/* STM32_SPI_I2SCFGR bit fields */
+#define SPI_I2SCFGR_I2SMOD BIT(0)
+
+#define MAX_CS_COUNT   4
+
+/* SPI Master Baud Rate min/max divisor */
+#define STM32_MBR_DIV_MIN  (2 << SPI_CFG1_MBR_MIN)
+#define STM32_MBR_DIV_MAX  (2 << SPI_CFG1_MBR_MAX)
+
+#define STM32_SPI_TIMEOUT_US   10
+
+/* SPI Communication mode */
+#define SPI_FULL_DUPLEX0
+#define SPI_SIMPLEX_TX 1
+#define SPI_SIMPLEX_RX 2
+#define SPI_HALF_DUPLEX3
+
+struct stm32_spi_priv {
+   void __iomem *base;
+   struct clk clk;
+   struct reset_ctl rst_ctl;
+   struct gpio_desc cs_gpios[MAX_CS_COUNT];
+   ulong bus_clk_rate;
+   unsigned int fifo_size;
+   unsigned int cur_bpw;
+   unsigned int cur_hz;
+

[U-Boot] [PATCH 3/3] configs: stm32mp15: Enable SPI relative flags

Enable STM32_SPI, SPI, DM_SPI and CMD_SPI flags.
This enables the SPI support for STM32MP15.

Signed-off-by: Patrice Chotard 
---

 configs/stm32mp15_basic_defconfig   | 4 
 configs/stm32mp15_trusted_defconfig | 4 
 2 files changed, 8 insertions(+)

diff --git a/configs/stm32mp15_basic_defconfig 
b/configs/stm32mp15_basic_defconfig
index bd75df8..1fe7e1d 100644
--- a/configs/stm32mp15_basic_defconfig
+++ b/configs/stm32mp15_basic_defconfig
@@ -29,6 +29,7 @@ CONFIG_CMD_GPIO=y
 CONFIG_CMD_GPT=y
 CONFIG_CMD_I2C=y
 CONFIG_CMD_MMC=y
+CONFIG_CMD_SPI=y
 CONFIG_CMD_USB=y
 CONFIG_CMD_USB_MASS_STORAGE=y
 CONFIG_CMD_CACHE=y
@@ -68,6 +69,9 @@ CONFIG_DM_REGULATOR_STM32_VREFBUF=y
 CONFIG_DM_REGULATOR_STPMIC1=y
 CONFIG_SERIAL_RX_BUFFER=y
 CONFIG_STM32_SERIAL=y
+CONFIG_SPI=y
+CONFIG_DM_SPI=y
+CONFIG_STM32_SPI=y
 CONFIG_USB=y
 CONFIG_DM_USB=y
 CONFIG_DM_USB_GADGET=y
diff --git a/configs/stm32mp15_trusted_defconfig 
b/configs/stm32mp15_trusted_defconfig
index f82b770..f29cd55 100644
--- a/configs/stm32mp15_trusted_defconfig
+++ b/configs/stm32mp15_trusted_defconfig
@@ -22,6 +22,7 @@ CONFIG_CMD_GPIO=y
 CONFIG_CMD_GPT=y
 CONFIG_CMD_I2C=y
 CONFIG_CMD_MMC=y
+CONFIG_CMD_SPI=y
 CONFIG_CMD_USB=y
 CONFIG_CMD_USB_MASS_STORAGE=y
 CONFIG_CMD_CACHE=y
@@ -58,6 +59,9 @@ CONFIG_DM_REGULATOR_STM32_VREFBUF=y
 CONFIG_DM_REGULATOR_STPMIC1=y
 CONFIG_SERIAL_RX_BUFFER=y
 CONFIG_STM32_SERIAL=y
+CONFIG_SPI=y
+CONFIG_DM_SPI=y
+CONFIG_STM32_SPI=y
 CONFIG_USB=y
 CONFIG_DM_USB=y
 CONFIG_DM_USB_GADGET=y
-- 
1.9.1

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

[U-Boot] [PATCH 1/3] clk: stm32mp1: Add SPI1 clock entry

Add missing SPI1 clock needed by SPI1 instance.

Signed-off-by: Patrice Chotard 
---

 drivers/clk/clk_stm32mp1.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/clk/clk_stm32mp1.c b/drivers/clk/clk_stm32mp1.c
index 24859fd..800ded7 100644
--- a/drivers/clk/clk_stm32mp1.c
+++ b/drivers/clk/clk_stm32mp1.c
@@ -90,6 +90,7 @@
 #define RCC_PLL4CSGR   0x8A4
 #define RCC_I2C12CKSELR0x8C0
 #define RCC_I2C35CKSELR0x8C4
+#define RCC_SPI2S1CKSELR   0x8D8
 #define RCC_UART6CKSELR0x8E4
 #define RCC_UART24CKSELR   0x8E8
 #define RCC_UART35CKSELR   0x8EC
@@ -298,6 +299,7 @@ enum stm32mp1_parent_sel {
_STGEN_SEL,
_DSI_SEL,
_ADC12_SEL,
+   _SPI1_SEL,
_PARENT_SEL_NB,
_UNKNOWN_SEL = 0xff,
 };
@@ -519,6 +521,7 @@ static const struct stm32mp1_clk_gate stm32mp1_clk_gate[] = 
{
STM32MP1_CLK_SET_CLR(RCC_MP_APB1ENSETR, 23, I2C3_K, _I2C35_SEL),
STM32MP1_CLK_SET_CLR(RCC_MP_APB1ENSETR, 24, I2C5_K, _I2C35_SEL),
 
+   STM32MP1_CLK_SET_CLR(RCC_MP_APB2ENSETR, 8, SPI1_K, _SPI1_SEL),
STM32MP1_CLK_SET_CLR(RCC_MP_APB2ENSETR, 13, USART6_K, _UART6_SEL),
 
STM32MP1_CLK_SET_CLR_F(RCC_MP_APB3ENSETR, 13, VREF, _PCLK3),
@@ -589,6 +592,8 @@ static const u8 usbo_parents[] = {_PLL4_R, _USB_PHY_48};
 static const u8 stgen_parents[] = {_HSI_KER, _HSE_KER};
 static const u8 dsi_parents[] = {_DSI_PHY, _PLL4_P};
 static const u8 adc_parents[] = {_PLL4_R, _CK_PER, _PLL3_Q};
+static const u8 spi_parents[] = {_PLL4_P, _PLL3_Q, _I2S_CKIN, _CK_PER,
+_PLL3_R};
 
 static const struct stm32mp1_clk_sel stm32mp1_clk_sel[_PARENT_SEL_NB] = {
STM32MP1_CLK_PARENT(_I2C12_SEL, RCC_I2C12CKSELR, 0, 0x7, i2c12_parents),
@@ -613,6 +618,7 @@ static const struct stm32mp1_clk_sel 
stm32mp1_clk_sel[_PARENT_SEL_NB] = {
STM32MP1_CLK_PARENT(_STGEN_SEL, RCC_STGENCKSELR, 0, 0x3, stgen_parents),
STM32MP1_CLK_PARENT(_DSI_SEL, RCC_DSICKSELR, 0, 0x1, dsi_parents),
STM32MP1_CLK_PARENT(_ADC12_SEL, RCC_ADCCKSELR, 0, 0x1, adc_parents),
+   STM32MP1_CLK_PARENT(_SPI1_SEL, RCC_SPI2S1CKSELR, 0, 0x7, spi_parents),
 };
 
 #ifdef STM32MP1_CLOCK_TREE_INIT
@@ -727,6 +733,7 @@ char * const stm32mp1_clk_parent_sel_name[_PARENT_SEL_NB] = 
{
[_STGEN_SEL] = "STGEN",
[_DSI_SEL] = "DSI",
[_ADC12_SEL] = "ADC12",
+   [_SPI1_SEL] = "SPI1",
 };
 
 static const struct stm32mp1_clk_data stm32mp1_data = {
-- 
1.9.1

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

[U-Boot] [PATCH 0/3] Add SPI driver suport for STM32MP1


This series:
 - adds SPI1 clock entry in clock driver
 - adds STM32MP1 SPI driver
 - enables SPI for STM32MP1


Patrice Chotard (3):
  clk: stm32mp1: Add SPI1 clock entry
  spi: stm32: Add Serial Peripheral Interface driver for STM32MP
  configs: stm32mp15: Enable SPI relative flags

 MAINTAINERS |   1 +
 configs/stm32mp15_basic_defconfig   |   4 +
 configs/stm32mp15_trusted_defconfig |   4 +
 drivers/clk/clk_stm32mp1.c  |   7 +
 drivers/spi/Kconfig |   8 +
 drivers/spi/Makefile|   1 +
 drivers/spi/stm32_spi.c | 615 
 7 files changed, 640 insertions(+)
 create mode 100644 drivers/spi/stm32_spi.c

-- 
1.9.1

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

[U-Boot] [PATCH 2/2 v2] i2c: mxc_i2c: Fix read and read->write xfers in DM mode

This is an old driver that supports both device mapped and non-mapped
mode, and covers a wide range of hardware.  It's hard to change without
risking breaking something.  I have to tried to be exceedingly detailed
in this patch, so please excuse the length of the commit essay that
follows.

In device mapped mode the I2C xfer function does not handle plain read,
and some other, transfers correctly.

What it can't handle are transactions that:
Start with a read, or,
Have a write followed by a read, or,
Have more than one read in a row.

The common I2C/SMBUS read register and write register transactions
always start with a write, followed by a write or a read, and then end.
These work, so the bug is not apparent for most I2C slaves that only use
these common xfer forms.

The existing xfer loop initializes by sending the chip address in write
mode after it deals with bus arbitration and master setup.  When
processing each message, if the next message will be a read, it sends a
repeated start followed by the chip address in read mode after the
current message.

Obviously, this does not work if the first message is a read, as the
chip is always addressed in write mode initially by i2c_init_transfer().

A write following a read does not work because the repeated start is
only sent when the next message is a read.  There is no logic to send it
when the current message is a read and next is write.  It should be sent
every time the bus changes direction.

The ability to use a plain read was added to this driver in
commit 2feec4eafd40 ("imx: mxc_i2c: tweak the i2c transfer method"),
but this applied only the non-DM code path.

This patch fixes the DM code path.  The xfer function will call
i2c_init_transfer() with an alen of -1 to avoid sending the chip
address.  The same way the non-DM code achieves this.  The xfer
function's message loop will send the address and mode before each
message if the bus changes direction, and on the first message.

When reading data, the master hardware is one byte ahead of what we
receive.  I.e., reading a byte from the data register returns a byte
*already received* by the master, and causes the master to start the RX
of the *next* byte.  Therefor, before we read the final byte of a
message, we must tell the master what to do next.  I add a "last" flag
to i2c_read_data() to tell it if the message is to be followed by a stop
or a repeated start.  When last == true it acts exactly as before.

The non-DM code can only create an xfer where the read, if any, is the
final message of the xfer.  And so the only callsite of i2c_read_data()
in the non-DM code has the "last" parameter as true.  Therefore, this
change has no effect on the non-DM code.  As all other changes are in
the DM xfer function, which is not even compiled in non-DM code, I am
confident that this patch has no effect on boards not using I2C_DM.
This greatly reduces the range of hardware that could be affected.

For DM boards, I have verified every transaction the "i2c" command can
create on a scope and they are all exactly as they are supposed to be.
I also tested write->read->write, which isn't possible with the i2c
command, and it works as well.  I didn't fix multiple reads in a row, as
it's a lot more invasive and obviously no one has every wanted them
since they've never worked.  It didn't seem like the extra complexity
was justified to support something no one uses.

Cc: Nandor Han 
Cc: Heiko Schocher 
Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Breno Matheus Lima 
Signed-off-by: Trent Piepho 
---
Changes from v1:
  Typo in commit message fixed.
  Re-sending as base64 to avoid Microsoft email mangling.

 drivers/i2c/mxc_i2c.c | 95 ++-
 1 file changed, 64 insertions(+), 31 deletions(-)

diff --git a/drivers/i2c/mxc_i2c.c b/drivers/i2c/mxc_i2c.c
index f17a47f600..23119cce65 100644
--- a/drivers/i2c/mxc_i2c.c
+++ b/drivers/i2c/mxc_i2c.c
@@ -482,8 +482,13 @@ static int i2c_write_data(struct mxc_i2c_bus *i2c_bus, u8 
chip, const u8 *buf,
return ret;
 }
 
+/* Will generate a STOP after the last byte if "last" is true, i.e. this is the
+ * final message of a transaction.  If not, it switches the bus back to TX mode
+ * and does not send a STOP, leaving the bus in a state where a repeated start
+ * and address can be sent for another message.
+ */
 static int i2c_read_data(struct mxc_i2c_bus *i2c_bus, uchar chip, uchar *buf,
-int len)
+int len, bool last)
 {
int ret;
unsigned int temp;
@@ -513,17 +518,31 @@ static int i2c_read_data(struct mxc_i2c_bus *i2c_bus, 
uchar chip, uchar *buf,
return ret;
}
 
-   /*
-* It must generate STOP before read I2DR to prevent
-* controller from generating another clock cycle
-*/
if (i == (len - 1)) {
-   i2c_imx_stop(i2c_bus);
+

[U-Boot] [PATCH 1/2 v2] i2c: mxc_i2c: Document how non-DM functions work

It is not very clear how these work in relation to the exact I2C xfers
they produce.  In paticular, the address length is somewhat overloaded
in the read method.  Clearly document the existing behavior.  Maybe this
will help the next person who needs to work on this driver and not break
non-DM boards.

Cc: Nandor Han 
Cc: Heiko Schocher 
Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Breno Matheus Lima 
Signed-off-by: Trent Piepho 
---
Changes from v1:
  None, re-sending as base64 to avoid Microsoft email mangling.

 drivers/i2c/mxc_i2c.c | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/drivers/i2c/mxc_i2c.c b/drivers/i2c/mxc_i2c.c
index 5420afbc8e..f17a47f600 100644
--- a/drivers/i2c/mxc_i2c.c
+++ b/drivers/i2c/mxc_i2c.c
@@ -540,6 +540,25 @@ static int i2c_read_data(struct mxc_i2c_bus *i2c_bus, 
uchar chip, uchar *buf,
 #ifndef CONFIG_DM_I2C
 /*
  * Read data from I2C device
+ *
+ * The transactions use the syntax defined in the Linux kernel I2C docs.
+ *
+ * If alen is > 0, then this function will send a transaction of the form:
+ * S Chip Wr [A] Addr [A] S Chip Rd [A] [data] A ... NA P
+ * This is a normal I2C register read: writing the register address, then doing
+ * a repeated start and reading the data.
+ *
+ * If alen == 0, then we get this transaction:
+ * S Chip Wr [A] S Chip Rd [A] [data] A ... NA P
+ * This is somewhat unusual, though valid, transaction.  It addresses the chip
+ * in write mode, but doesn't actually write any register address or data, then
+ * does a repeated start and reads data.
+ *
+ * If alen < 0, then we get this transaction:
+ * S Chip Rd [A] [data] A ... NA P
+ * The chip is addressed in read mode and then data is read.  No register
+ * address is written first.  This is perfectly valid on most devices and
+ * required on some (usually those that don't act like an array of registers).
  */
 static int bus_i2c_read(struct mxc_i2c_bus *i2c_bus, u8 chip, u32 addr,
int alen, u8 *buf, int len)
@@ -574,6 +593,20 @@ static int bus_i2c_read(struct mxc_i2c_bus *i2c_bus, u8 
chip, u32 addr,
 
 /*
  * Write data to I2C device
+ *
+ * If alen > 0, we get this transaction:
+ *S Chip Wr [A] addr [A] data [A] ... [A] P
+ * An ordinary write register command.
+ *
+ * If alen == 0, then we get this:
+ *S Chip Wr [A] data [A] ... [A] P
+ * This is a simple I2C write.
+ *
+ * If alen < 0, then we get this:
+ *S data [A] ... [A] P
+ * This is most likely NOT something that should be used.  It doesn't send the
+ * chip address first, so in effect, the first byte of data will be used as the
+ * address.
  */
 static int bus_i2c_write(struct mxc_i2c_bus *i2c_bus, u8 chip, u32 addr,
 int alen, const u8 *buf, int len)
@@ -881,6 +914,7 @@ static int mxc_i2c_probe(struct udevice *bus)
return 0;
 }
 
+/* Sends: S Addr Wr [A|NA] P */
 static int mxc_i2c_probe_chip(struct udevice *bus, u32 chip_addr,
  u32 chip_flags)
 {
-- 
2.14.5

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

Re: [U-Boot] [PATCH] Makefile: Create single image for imx6 socs based boards

Hi Shyam,

On 30/04/19 12:33, Shyam Saini wrote:
> IMX6 platform has two stage boot loaders like SPL and
> U-Boot proper. For each stage we need to burn the image
> on to flash with respective offsets.
> 
> This patch create a single image using binman, so that
> user can get rid of burning different stage boot images.
> 
> without this patch:
> --
> $ sudo dd if=SPL of=/dev/mmcblk0 bs=1k seek=1
> $ sudo dd if=u-boot-dtb.img of=/dev/mmcblk0 bs=1k seek=69
> 
> with this patch:
> ---
> $ sudo dd if=u-boot-imx6-with-spl.bin of=/dev/mmcblk0 bs=1k seek=1
> 

I am quite confused. There is already a "u-boot-with-spl.imx" target,
this works since a lot of time. Which is the reason to duplicate this
feature or where is the difference ?

Best regards,
Stefano Babic

> This would be easily extended to single image creation
> for other imx6 soc boards.
> 
> This was tested on engicam imx6qdl and imx6ul boards
> 
> Reviewed-by: Jagan Teki 
> Signed-off-by: Shyam Saini 
> ---
>  Makefile | 10 ++
>  arch/arm/dts/imx6-u-boot-binman.dtsi | 16 
>  arch/arm/dts/imx6qdl-u-boot.dtsi |  1 +
>  arch/arm/dts/imx6ul-u-boot.dtsi  |  1 +
>  arch/arm/mach-imx/mx6/Kconfig|  2 ++
>  doc/imx/common/imx6.txt  |  5 +
>  6 files changed, 35 insertions(+)
>  create mode 100644 arch/arm/dts/imx6-u-boot-binman.dtsi
> 
> diff --git a/Makefile b/Makefile
> index f2c7bb6041..474271a1d0 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -851,6 +851,11 @@ ifeq ($(CONFIG_ARCH_SUNXI)$(CONFIG_SPL),yy)
>  ALL-y += u-boot-sunxi-with-spl.bin
>  endif
>  
> +# Build a combined spl + u-boot image for imx6
> +ifeq ($(filter y, $(CONFIG_MX6QDL) 
> $(CONFIG_MX6UL))$(CONFIG_SPL)$(CONFIG_OF_CONTROL),yyy)
> +ALL-$(CONFIG_ARCH_MX6) += u-boot-imx6-with-spl.bin
> +endif
> +
>  # enable combined SPL/u-boot/dtb rules for tegra
>  ifeq ($(CONFIG_TEGRA)$(CONFIG_SPL),yy)
>  ALL-y += u-boot-tegra.bin u-boot-nodtb-tegra.bin
> @@ -1364,6 +1369,11 @@ u-boot-br.bin: u-boot FORCE
>  endif
>  endif
>  
> +ifeq ($(filter y, $(CONFIG_MX6QDL) 
> $(CONFIG_MX6UL))$(CONFIG_SPL)$(CONFIG_OF_CONTROL),yyy)
> +u-boot-imx6-with-spl.bin: SPL u-boot-dtb.img FORCE
> + @$(call if_changed,binman)
> +endif
> +
>  # x86 uses a large ROM. We fill it with 0xff, put the 16-bit stuff (including
>  # reset vector) at the top, Intel ME descriptor at the bottom, and U-Boot in
>  # the middle. This is handled by binman based on an image description in the
> diff --git a/arch/arm/dts/imx6-u-boot-binman.dtsi 
> b/arch/arm/dts/imx6-u-boot-binman.dtsi
> new file mode 100644
> index 00..fa02d5f61f
> --- /dev/null
> +++ b/arch/arm/dts/imx6-u-boot-binman.dtsi
> @@ -0,0 +1,16 @@
> +#include 
> +
> +/ {
> + binman {
> + filename = "u-boot-imx6-with-spl.bin";
> + pad-byte = <0xff>;
> +
> + blob {
> + filename = "SPL";
> + };
> +
> + u-boot-img {
> + offset = ;
> + };
> + };
> +};
> diff --git a/arch/arm/dts/imx6qdl-u-boot.dtsi 
> b/arch/arm/dts/imx6qdl-u-boot.dtsi
> index 0aa29e38b8..3dfa84dcac 100644
> --- a/arch/arm/dts/imx6qdl-u-boot.dtsi
> +++ b/arch/arm/dts/imx6qdl-u-boot.dtsi
> @@ -2,6 +2,7 @@
>  /*
>   * Copyright (C) 2018 Jagan Teki 
>   */
> +#include "imx6-u-boot-binman.dtsi"
>  
>  / {
>   soc {
> diff --git a/arch/arm/dts/imx6ul-u-boot.dtsi b/arch/arm/dts/imx6ul-u-boot.dtsi
> index eb190cf8c8..4e769da0d5 100644
> --- a/arch/arm/dts/imx6ul-u-boot.dtsi
> +++ b/arch/arm/dts/imx6ul-u-boot.dtsi
> @@ -2,6 +2,7 @@
>  /*
>   * Copyright (C) 2018 Jagan Teki 
>   */
> +#include "imx6-u-boot-binman.dtsi"
>  
>  / {
>   soc {
> diff --git a/arch/arm/mach-imx/mx6/Kconfig b/arch/arm/mach-imx/mx6/Kconfig
> index e782859b1e..7de1a00935 100644
> --- a/arch/arm/mach-imx/mx6/Kconfig
> +++ b/arch/arm/mach-imx/mx6/Kconfig
> @@ -34,6 +34,7 @@ config MX6QDL
>   bool
>   select HAS_CAAM
>   select MX6_SMP
> + select BINMAN if SPL && OF_CONTROL
>  
>  config MX6S
>   bool
> @@ -57,6 +58,7 @@ config MX6UL
>   select ROM_UNIFIED_SECTIONS
>   select SYSCOUNTER_TIMER
>   select SYS_L2CACHE_OFF
> + select BINMAN if SPL && OF_CONTROL
>  
>  config MX6UL_LITESOM
>   bool
> diff --git a/doc/imx/common/imx6.txt b/doc/imx/common/imx6.txt
> index eab88353f6..5a10f94957 100644
> --- a/doc/imx/common/imx6.txt
> +++ b/doc/imx/common/imx6.txt
> @@ -88,3 +88,8 @@ Reading bank 4:
>  
>  Word 0x0002: 9f027772 0004
>  
> +2. Single Boot Image
> +-
> +Write your single imx6 uboot image as:
> +
> +$ sudo dd if=u-boot-imx6-with-spl.bin of=/dev/mmcblk0 bs=1k seek=1
> 


-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email:

Re: [U-Boot] [PATCH 2/4] crypto/fsl: Use __sec_set_jr_context_normal

2019-04-30 Thread Breno Matheus Lima

Hi Bryan,

Em ter, 30 de abr de 2019 às 05:13, Bryan O'Donoghue
 escreveu:
>
>
>
> On 30/04/2019 02:28, Bryan O'Donoghue wrote:
> >
> >
> > On 25/04/2019 04:24, Breno Matheus Lima wrote:
> >> I couldn't get encrypted boot working in my first attempt, doing the
> >> exact same procedure with commit 22191ac35344 ("drivers/crypto/fsl:
> >> assign job-rings to non-TrustZone") reverted works fine.
> >
> > Hi Breno,
> >
> > I noticed another patch from you re: dek blob, does that address this
> > issue for you are is this still a live thing ?

No, the patch I have recently submitted does not address the JR
TrustZone issue we are currently seeing with DEK blob decapsulation at
ROM level. I was not following AN12056 when I tried so I couldn't see
this other issue at first moment.

> >
> > If you are running in secure-world, and the BootROM dek blob stuff
> > validates job-ring ownership it _should_ be possible to flip the
> > ownership bits to what the BootROM expects and then back again.
> >
> > If its not working, presumably its because we aren't flipping ownership
> > at the right time.
>
> It occurred to me after I went to bed.
>
> The right thing to do is leave the BootROM settings up until we hand-off
> and then set the required post-boot settings.
>
> Something I reckon can be ~easily done in some sort of architectural
> handover preparation function.
>
> I'll spin that patchset.

Thanks for preparing a second version for this patchset, I see that
you have also replied to my other e-mail in "[PATCH 1/4] crypto/fsl:
Introduce API to save/restore job-ring context".

Your new proposal looks fine to me, I can test again.

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

Re: [U-Boot] [PATCH 2/2] i2c: mxc_i2c: Fix read and read->write xfers in DM mode

On Tue, 2019-04-30 at 06:34 +0200, Heiko Schocher wrote:
> Hello Trent,
> 
> Am 16.04.2019 um 00:02 schrieb Trent Piepho:
> > This is an old driver that supports both device mapped and non-mapped
> > mode, and covers a wide range of hardware.  It's hard to change without
> > risking breaking something.  I have to tried to be exceedingly detailed
> > in this patch, so please excuse the length of the commit essay that
> > follows.
> > 
> Thanks for this work!
> 
> Your patch has
> 
> total: 64 errors, 2 warnings, 0 checks, 145 lines checked
> 
> Please fix and send a v2.
> 
> It would be good to become here some Tested by tags ...
> 
> Reviewed-by: Heiko Schocher 

My patches are fine before I send them.  They are getting DOS line
endings added in transit.  It seems Microsoft has recently changed
their mail server used for office365 to automatically add DOS line
endings to all text emails.  It didn't use to do this.  It seems the
only way to avoid this is to use base64 encoding with git send-email. 
It works went I send a test message to myself and export from
Evolution.  No way to test if the list software can handle it without
re-sending.

The patches should be automatically fixed by git am, as it will strip
DOS endings by default.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] net: davinci_emac: use driver model (CONFIG_DM_ETH)

2019-04-30 Thread Bartosz Golaszewski

From: Bartosz Golaszewski 

Add support for CONFIG_DM_ETH to the davinci_emac driver. Optimally
we should only support DM-enabled platforms but there are several
non-DT boards that still use it so either we need to keep supporting
it or drop the boards from u-boot. For now we're stuck with ugly
ifdefs.

This patch adds support for driver-model to the driver and converts
all platforms that use the driver model to selecting CONFIG_DM_ETH.

Tested on da850-evm and da850-lcdk.

Signed-off-by: Bartosz Golaszewski 
---
NOTE: I'm currently working on modernizing da850 support in u-boot.
This patch is just the first step - I plan on improving the emac driver
in general but I'll be OoO until end of next week, so I decided to post
it already for reviews.

Does anyone know what the status is on boards like twister, ea20 etc.
that use davinci_emac, but don't use the driver model? Dropping them
would make it easier to clean up this driver.

This patch applies on top of my previous series[1].

[1] https://lists.denx.de/pipermail/u-boot/2019-April/367236.html

 arch/arm/mach-davinci/cpu.c|  13 ---
 arch/arm/mach-omap2/omap3/emac.c   |   3 +-
 board/davinci/da8xxevm/da850evm.c  |   5 --
 board/davinci/da8xxevm/omapl138_lcdk.c |  14 
 board/logicpd/am3517evm/am3517evm.c|   1 -
 board/ti/ti816x/evm.c  |   3 +-
 configs/am3517_evm_defconfig   |   1 +
 configs/da850_am18xxevm_defconfig  |   1 +
 configs/da850evm_defconfig |   1 +
 configs/da850evm_direct_nor_defconfig  |   1 +
 configs/omapl138_lcdk_defconfig|   1 +
 configs/ti816x_evm_defconfig   |   1 +
 drivers/net/ti/davinci_emac.c  | 109 +
 13 files changed, 100 insertions(+), 54 deletions(-)

diff --git a/arch/arm/mach-davinci/cpu.c b/arch/arm/mach-davinci/cpu.c
index f97ad3fc74..9fd6564d04 100644
--- a/arch/arm/mach-davinci/cpu.c
+++ b/arch/arm/mach-davinci/cpu.c
@@ -5,7 +5,6 @@
  */
 
 #include 
-#include 
 #include 
 #include 
 
@@ -90,15 +89,3 @@ int set_cpu_clk_info(void)
gd->bd->bi_dsp_freq = 0;
return 0;
 }
-
-/*
- * Initializes on-chip ethernet controllers.
- * to override, implement board_eth_init()
- */
-int cpu_eth_init(bd_t *bis)
-{
-#if defined(CONFIG_DRIVER_TI_EMAC)
-   davinci_emac_initialize();
-#endif
-   return 0;
-}
diff --git a/arch/arm/mach-omap2/omap3/emac.c b/arch/arm/mach-omap2/omap3/emac.c
index c79e870183..fb0c9188f5 100644
--- a/arch/arm/mach-omap2/omap3/emac.c
+++ b/arch/arm/mach-omap2/omap3/emac.c
@@ -7,7 +7,6 @@
  */
 
 #include 
-#include 
 #include 
 #include 
 
@@ -24,5 +23,5 @@ int cpu_eth_init(bd_t *bis)
reset &= ~CPGMACSS_SW_RST;
writel(reset, _scm_general_regs->ip_sw_reset);
 
-   return davinci_emac_initialize();
+   return 0;
 }
diff --git a/board/davinci/da8xxevm/da850evm.c 
b/board/davinci/da8xxevm/da850evm.c
index 1bc26828bf..0d2bc5fb32 100644
--- a/board/davinci/da8xxevm/da850evm.c
+++ b/board/davinci/da8xxevm/da850evm.c
@@ -13,7 +13,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -472,10 +471,6 @@ int board_eth_init(bd_t *bis)
if (rmii_hw_init())
printf("RMII hardware init failed!!!\n");
 #endif
-   if (!davinci_emac_initialize()) {
-   printf("Error: Ethernet init failed!\n");
-   return -1;
-   }
 
return 0;
 }
diff --git a/board/davinci/da8xxevm/omapl138_lcdk.c 
b/board/davinci/da8xxevm/omapl138_lcdk.c
index 2c2f885d43..ef9656add8 100644
--- a/board/davinci/da8xxevm/omapl138_lcdk.c
+++ b/board/davinci/da8xxevm/omapl138_lcdk.c
@@ -11,7 +11,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -229,19 +228,6 @@ int board_init(void)
 
 #ifdef CONFIG_DRIVER_TI_EMAC
 
-/*
- * Initializes on-board ethernet controllers.
- */
-int board_eth_init(bd_t *bis)
-{
-   if (!davinci_emac_initialize()) {
-   printf("Error: Ethernet init failed!\n");
-   return -1;
-   }
-
-   return 0;
-}
-
 #endif /* CONFIG_DRIVER_TI_EMAC */
 
 #define CFG_MAC_ADDR_SPI_BUS   0
diff --git a/board/logicpd/am3517evm/am3517evm.c 
b/board/logicpd/am3517evm/am3517evm.c
index 10031a4801..bfd4e78274 100644
--- a/board/logicpd/am3517evm/am3517evm.c
+++ b/board/logicpd/am3517evm/am3517evm.c
@@ -28,7 +28,6 @@
 #include 
 #include 
 #include 
-#include 
 #include "am3517evm.h"
 
 DECLARE_GLOBAL_DATA_PTR;
diff --git a/board/ti/ti816x/evm.c b/board/ti/ti816x/evm.c
index 07a084bab8..240df8cbe1 100644
--- a/board/ti/ti816x/evm.c
+++ b/board/ti/ti816x/evm.c
@@ -9,7 +9,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -56,7 +55,7 @@ int board_eth_init(bd_t *bis)
printf("Unable to read MAC address. Set \n");
}
 
-   return davinci_emac_initialize();
+   return 0;
 }
 
 #ifdef CONFIG_SPL_BUILD
diff --git a/configs/am3517_evm_defconfig b/configs/am3517_evm_defconfig
index

Re: [U-Boot] [PATCH] test/py: don't use mmc_rd config for other mmc tests

2019-04-30 Thread Stephen Warren


On 4/16/19 4:04 PM, Stephen Warren wrote:

From: Stephen Warren 

Fix test_mmc_dev(), test_mmc_rescan(), test_mmc_info() not to use the
same configuration data that test_mmc_rd() does. Doing so causes the
following issues:

* The new code uncondtionally expects certain keys to exist in the
configuration data. These keys do not exist in existing configuration
data since they were not previously required, and there was no
notification re: a requirement to add these new keys. This causes test
failures due to thrown exceptions when accessing the non-existent keys.

* The new tests logically operate on different objects. test_mmc_rd()
operates on ranges of sectors on an MMC device (which may be the entire
set of sectors of a device, or a part of a device), whereas all the new
tests operate solely on entire devices. These are separate things, and
it's entirely likely that the user will wish to runs the two types of
tests on different sets of data; see the example configuration data that
this commit adds. Ideally, the new tests would have been added to a
separate Python file, since they aren' closely related to the existing
tests.

FIXME: Marek, can you please replace the "???" in this patch with some
reasonable looking data? Thanks.


Tom, Marek, any chance of applying this? Right now, every mainline 
branch is failing 5 tests on every push, which wastes my time having to 
go through all the logs to manually check that the failures aren't 
anything new/unknown. Thanks.

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

[U-Boot] [PATCH v2 3/4] watchdog: stm32mp: Add watchdog driver

This patch adds IWDG (Independent WatchDoG) support for
STM32MP platform.

Signed-off-by: Christophe Kerello 
Signed-off-by: Patrice Chotard 
---

Changes in v2:
   - Rename timeout variable in timeout_ms in stm32mp_wdt_start()

 MAINTAINERS|   1 +
 arch/arm/mach-stm32mp/Kconfig  |   1 +
 drivers/watchdog/Kconfig   |   8 +++
 drivers/watchdog/Makefile  |   1 +
 drivers/watchdog/stm32mp_wdt.c | 135 +
 5 files changed, 146 insertions(+)
 create mode 100644 drivers/watchdog/stm32mp_wdt.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 09f31cd..eec2603 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -311,6 +311,7 @@ F:  drivers/ram/stm32mp1/
 F: drivers/misc/stm32_rcc.c
 F: drivers/reset/stm32-reset.c
 F: drivers/spi/stm32_qspi.c
+F: drivers/watchdog/stm32mp_wdt.c
 
 ARM STM STV0991
 M: Vikas Manocha 
diff --git a/arch/arm/mach-stm32mp/Kconfig b/arch/arm/mach-stm32mp/Kconfig
index 73aa382..4e7cc2e 100644
--- a/arch/arm/mach-stm32mp/Kconfig
+++ b/arch/arm/mach-stm32mp/Kconfig
@@ -17,6 +17,7 @@ config SPL
select SPL_DM_RESET
select SPL_SERIAL_SUPPORT
select SPL_SYSCON
+   select SPL_WATCHDOG_SUPPORT
imply SPL_DISPLAY_PRINT
imply SPL_LIBDISK_SUPPORT
 
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 4a3ff7a..d582abe 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -147,6 +147,14 @@ config WDT_SANDBOX
  can be probed and supports all of the methods of WDT, but does not
  really do anything.
 
+config WDT_STM32MP
+   bool "IWDG watchdog driver for STM32 MP's family"
+   depends on WDT
+   imply WATCHDOG
+   help
+ Enable the STM32 watchdog (IWDG) driver. Enable support to
+ configure STM32's on-SoC watchdog.
+
 config XILINX_TB_WATCHDOG
bool "Xilinx Axi watchdog timer support"
depends on WDT
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 40b2f4b..a3ebff8 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -27,3 +27,4 @@ obj-$(CONFIG_WDT_CDNS) += cdns_wdt.o
 obj-$(CONFIG_WDT_MPC8xx) += mpc8xx_wdt.o
 obj-$(CONFIG_WDT_MT7621) += mt7621_wdt.o
 obj-$(CONFIG_WDT_MTK) += mtk_wdt.o
+obj-$(CONFIG_WDT_STM32MP) += stm32mp_wdt.o
diff --git a/drivers/watchdog/stm32mp_wdt.c b/drivers/watchdog/stm32mp_wdt.c
new file mode 100644
index 000..8093d0a
--- /dev/null
+++ b/drivers/watchdog/stm32mp_wdt.c
@@ -0,0 +1,135 @@
+// SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause
+/*
+ * Copyright (C) 2019, STMicroelectronics - All Rights Reserved
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* IWDG registers */
+#define IWDG_KR0x00/* Key register */
+#define IWDG_PR0x04/* Prescaler Register */
+#define IWDG_RLR   0x08/* ReLoad Register */
+#define IWDG_SR0x0C/* Status Register */
+
+/* IWDG_KR register bit mask */
+#define KR_KEY_RELOAD  0x  /* Reload counter enable */
+#define KR_KEY_ENABLE  0x  /* Peripheral enable */
+#define KR_KEY_EWA 0x  /* Write access enable */
+
+/* IWDG_PR register bit values */
+#define PR_256 0x06/* Prescaler set to 256 */
+
+/* IWDG_RLR register values */
+#define RLR_MAX0xFFF   /* Max value supported by reload 
register */
+
+/* IWDG_SR register bit values */
+#define SR_PVU BIT(0)  /* Watchdog prescaler value update */
+#define SR_RVU BIT(1)  /* Watchdog counter reload value update */
+
+struct stm32mp_wdt_priv {
+   fdt_addr_t base;/* registers addr in physical memory */
+   unsigned long wdt_clk_rate; /* Watchdog dedicated clock rate */
+};
+
+static int stm32mp_wdt_reset(struct udevice *dev)
+{
+   struct stm32mp_wdt_priv *priv = dev_get_priv(dev);
+
+   writel(KR_KEY_RELOAD, priv->base + IWDG_KR);
+
+   return 0;
+}
+
+static int stm32mp_wdt_start(struct udevice *dev, u64 timeout_ms, ulong flags)
+{
+   struct stm32mp_wdt_priv *priv = dev_get_priv(dev);
+   int reload;
+   u32 val;
+   int ret;
+
+   /* Prescaler fixed to 256 */
+   reload = timeout_ms * priv->wdt_clk_rate / 256;
+   if (reload > RLR_MAX + 1)
+   /* Force to max watchdog counter reload value */
+   reload = RLR_MAX + 1;
+   else if (!reload)
+   /* Force to min watchdog counter reload value */
+   reload = priv->wdt_clk_rate / 256;
+
+   /* Set prescaler & reload registers */
+   writel(KR_KEY_EWA, priv->base + IWDG_KR);
+   writel(PR_256, priv->base + IWDG_PR);
+   writel(reload - 1, priv->base + IWDG_RLR);
+
+   /* Enable watchdog */
+   writel(KR_KEY_ENABLE, priv->base + IWDG_KR);
+
+   /* Wait for the registers to be updated */
+   ret = readl_poll_timeout(priv->base + IWDG_SR, val,
+val & (SR_PVU |

[U-Boot] [PATCH v2 4/4] configs: stm32mp15: Enable WDT flags

This allows to enable WATCHDOG and WDT flags to
be able to reset the watchdog and to support watchdog driver
model.

Signed-off-by: Patrice Chotard 
---

Changes in v2: None

 configs/stm32mp15_basic_defconfig   | 2 ++
 configs/stm32mp15_trusted_defconfig | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/configs/stm32mp15_basic_defconfig 
b/configs/stm32mp15_basic_defconfig
index fd164fa..7252c14 100644
--- a/configs/stm32mp15_basic_defconfig
+++ b/configs/stm32mp15_basic_defconfig
@@ -77,3 +77,5 @@ CONFIG_USB_GADGET_MANUFACTURER="STMicroelectronics"
 CONFIG_USB_GADGET_VENDOR_NUM=0x0483
 CONFIG_USB_GADGET_PRODUCT_NUM=0x5720
 CONFIG_USB_GADGET_DWC2_OTG=y
+CONFIG_WDT=y
+CONFIG_WDT_STM32MP=y
diff --git a/configs/stm32mp15_trusted_defconfig 
b/configs/stm32mp15_trusted_defconfig
index f82b770..52ee280 100644
--- a/configs/stm32mp15_trusted_defconfig
+++ b/configs/stm32mp15_trusted_defconfig
@@ -68,3 +68,5 @@ CONFIG_USB_GADGET_MANUFACTURER="STMicroelectronics"
 CONFIG_USB_GADGET_VENDOR_NUM=0x0483
 CONFIG_USB_GADGET_PRODUCT_NUM=0x5720
 CONFIG_USB_GADGET_DWC2_OTG=y
+CONFIG_WDT=y
+CONFIG_WDT_STM32MP=y
-- 
1.9.1

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

[U-Boot] [PATCH v2 1/4] watchdog: Kconfig: Sort entry alphabetically

To make adding new entry easier, sort Kconfig entries in
alphabetical order.

Signed-off-by: Patrice Chotard 
Reviewed-by: Stefan Roese 
---

Changes in v2: None

 drivers/watchdog/Kconfig | 87 
 1 file changed, 44 insertions(+), 43 deletions(-)

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 3bce0aa..4a3ff7a 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -26,6 +26,13 @@ config BCM2835_WDT
  This provides basic infrastructure to support BCM2835/2836 watchdog
  hardware, with a max timeout of ~15secs.
 
+config IMX_WATCHDOG
+   bool "Enable Watchdog Timer support for IMX and LSCH2 of NXP"
+   select HW_WATCHDOG
+   help
+  Select this to enable the IMX and LSCH2 of Layerscape watchdog
+  driver.
+
 config OMAP_WATCHDOG
bool "TI OMAP watchdog driver"
depends on ARCH_OMAP2PLUS
@@ -59,14 +66,6 @@ config WDT
  What exactly happens when the timer expires is up to a particular
  device/driver.
 
-config WDT_SANDBOX
-   bool "Enable Watchdog Timer support for Sandbox"
-   depends on SANDBOX && WDT
-   help
- Enable Watchdog Timer support in Sandbox. This is a dummy device that
- can be probed and supports all of the methods of WDT, but does not
- really do anything.
-
 config WDT_ARMADA_37XX
bool "Marvell Armada 37xx watchdog timer support"
depends on WDT && ARMADA_3700
@@ -87,6 +86,13 @@ config WDT_ASPEED
  It currently does not support Boot Flash Addressing Mode Detection or
  Second Boot.
 
+config WDT_AT91
+   bool "AT91 watchdog timer support"
+   depends on WDT
+   help
+  Select this to enable Microchip watchdog timer, which can be found on
+  some AT91 devices.
+
 config WDT_BCM6345
bool "BCM6345 watchdog timer support"
depends on WDT && (ARCH_BMIPS || ARCH_BCM6858 || ARCH_BCM63158)
@@ -95,14 +101,6 @@ config WDT_BCM6345
  The watchdog timer is stopped when initialized.
  It performs full SoC reset.
 
-config WDT_ORION
-   bool "Orion watchdog timer support"
-   depends on WDT
-   select CLK
-   help
-  Select this to enable Orion watchdog timer, which can be found on 
some
-  Marvell Armada chips.
-
 config WDT_CDNS
bool "Cadence watchdog timer support"
depends on WDT
@@ -111,6 +109,20 @@ config WDT_CDNS
   Select this to enable Cadence watchdog timer, which can be found on 
some
   Xilinx Microzed Platform.
 
+config WDT_MPC8xx
+   bool "MPC8xx watchdog timer support"
+   depends on WDT && MPC8xx
+   select CONFIG_MPC8xx_WATCHDOG
+   help
+  Select this to enable mpc8xx watchdog timer
+
+config WDT_MT7621
+   bool "MediaTek MT7621 watchdog timer support"
+   depends on WDT && ARCH_MT7620
+   help
+  Select this to enable Ralink / Mediatek watchdog timer,
+  which can be found on some MediaTek chips.
+
 config WDT_MTK
bool "MediaTek watchdog timer support"
depends on WDT && ARCH_MEDIATEK
@@ -119,39 +131,28 @@ config WDT_MTK
  The watchdog timer is stopped when initialized.
  It performs full SoC reset.
 
-config XILINX_TB_WATCHDOG
-   bool "Xilinx Axi watchdog timer support"
+config WDT_ORION
+   bool "Orion watchdog timer support"
depends on WDT
-   imply WATCHDOG
+   select CLK
help
-  Select this to enable Xilinx Axi watchdog timer, which can be found 
on some
-  Xilinx Microblaze Platforms.
+  Select this to enable Orion watchdog timer, which can be found on 
some
+  Marvell Armada chips.
 
-config IMX_WATCHDOG
-   bool "Enable Watchdog Timer support for IMX and LSCH2 of NXP"
-   select HW_WATCHDOG
+config WDT_SANDBOX
+   bool "Enable Watchdog Timer support for Sandbox"
+   depends on SANDBOX && WDT
help
-  Select this to enable the IMX and LSCH2 of Layerscape watchdog
-  driver.
+ Enable Watchdog Timer support in Sandbox. This is a dummy device that
+ can be probed and supports all of the methods of WDT, but does not
+ really do anything.
 
-config WDT_AT91
-   bool "AT91 watchdog timer support"
+config XILINX_TB_WATCHDOG
+   bool "Xilinx Axi watchdog timer support"
depends on WDT
+   imply WATCHDOG
help
-  Select this to enable Microchip watchdog timer, which can be found on
-  some AT91 devices.
-
-config WDT_MT7621
-   bool "MediaTek MT7621 watchdog timer support"
-   depends on WDT && ARCH_MT7620
-   help
-  Select this to enable Ralink / Mediatek watchdog timer,
-  which can be found on some MediaTek chips.
-
-config WDT_MPC8xx
-   bool "MPC8xx watchdog timer support"
-   depends on WDT && MPC8xx
-   help
-  Select this to enable mpc8xx

[U-Boot] [PATCH v2 2/4] ARM: dts: stm32mp: Add iwdg2 support for stm32mp157c

This patch adds independent watchdog support for stm32mp157c
in SPL.

Signed-off-by: Patrice Chotard 
---

Changes in v2: None

 arch/arm/dts/stm32mp157-u-boot.dtsi | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/dts/stm32mp157-u-boot.dtsi 
b/arch/arm/dts/stm32mp157-u-boot.dtsi
index ab6f673..09560e2 100644
--- a/arch/arm/dts/stm32mp157-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157-u-boot.dtsi
@@ -140,3 +140,7 @@
compatible = "st,stm32-gpio";
u-boot,dm-pre-reloc;
 };
+
+ {
+   u-boot,dm-pre-reloc;
+};
-- 
1.9.1

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

[U-Boot] [PATCH v2 0/4] Add watchdog support for STM32MP1


This series:
  - sorts Kconfig entries in alphabetical order
  - enable watchdog support in SPL for STM32MP1
  - adds watchdog support to STM32MP1 boards


Changes in v2:
   - Rename timeout variable in timeout_ms in stm32mp_wdt_start()

Patrice Chotard (4):
  watchdog: Kconfig: Sort entry alphabetically
  ARM: dts: stm32mp: Add iwdg2 support for stm32mp157c
  watchdog: stm32mp: Add watchdog driver
  configs: stm32mp15: Enable WDT flags

 MAINTAINERS |   1 +
 arch/arm/dts/stm32mp157-u-boot.dtsi |   4 ++
 arch/arm/mach-stm32mp/Kconfig   |   1 +
 configs/stm32mp15_basic_defconfig   |   2 +
 configs/stm32mp15_trusted_defconfig |   2 +
 drivers/watchdog/Kconfig|  91 +---
 drivers/watchdog/Makefile   |   1 +
 drivers/watchdog/stm32mp_wdt.c  | 135 
 8 files changed, 196 insertions(+), 41 deletions(-)
 create mode 100644 drivers/watchdog/stm32mp_wdt.c

-- 
1.9.1

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

Re: [U-Boot] [PATCH 1/2] ti: Add device-tree for am335x-pocketbeagle.

On Mon, Apr 29, 2019 at 04:12:29PM -0700, Vagrant Cascadian wrote:

> Add device-tree files from linux 5.1-rc7 needed to complete support
> for PocketBeagle.
> 
> Signed-off-by: Vagrant Cascadian 

Reviewed-by: Tom Rini 

-- 
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] ti: Add am335x-pocketbeagle to am335x_evm_defconfig.

On Mon, Apr 29, 2019 at 04:12:30PM -0700, Vagrant Cascadian wrote:

> Add am335x-pocketbeagle to CONFIG_OF_LIST in am335x_evm_defconfig.
> 
> Signed-off-by: Vagrant Cascadian 

We need to update include/configs/am335x_evm.h too so that it detects
this variant and loads the right dtb.

-- 
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] Makefile: Create single image for imx6 socs based boards

2019-04-30 Thread Jagan Teki

Hi Fabio,

On Tue, Apr 30, 2019 at 6:17 PM Fabio Estevam  wrote:
>
> Hi Shyam,
>
> On Tue, Apr 30, 2019 at 7:34 AM Shyam Saini
>  wrote:
> >
> > IMX6 platform has two stage boot loaders like SPL and
> > U-Boot proper. For each stage we need to burn the image
> > on to flash with respective offsets.
> >
> > This patch create a single image using binman, so that
> > user can get rid of burning different stage boot images.
> >
> > without this patch:
> > --
> > $ sudo dd if=SPL of=/dev/mmcblk0 bs=1k seek=1
> > $ sudo dd if=u-boot-dtb.img of=/dev/mmcblk0 bs=1k seek=69
> >
> > with this patch:
> > ---
> > $ sudo dd if=u-boot-imx6-with-spl.bin of=/dev/mmcblk0 bs=1k seek=1
> >
> > This would be easily extended to single image creation
> > for other imx6 soc boards.
> >
> > This was tested on engicam imx6qdl and imx6ul boards
> >
> > Reviewed-by: Jagan Teki 
> > Signed-off-by: Shyam Saini 
>
> I like the idea, but this breaks the build for mx6sabresd_defconfig:
>
>   COPYspl/u-boot-spl.bin
>   CFGSspl/u-boot-spl.cfgout
>   MKIMAGE SPL
>   BINMAN  u-boot-imx6-with-spl.bin
> Wrote map file './image.map' to show errors
> binman: Node '/binman/u-boot-img': Offset 0x11000 (69632) overlaps
> with previous entry '/binman/blob' ending at 0x11c00 (72704)
> Makefile:1374: recipe for target 'u-boot-imx6-with-spl.bin' failed
> make: *** [u-boot-imx6-with-spl.bin] Error 1

Look like few of boards are crossing size > 68K which is the default
CONFIG_SPL_PAD_TO value.

This is the value in sabresd case,
₹ cat image.map
ImagePosOffset  Size  Name
  0009c8b8  main-section
   00011c00  blob
 00011000  0008b8b8  u-boot-img

But if this the case the existing u-boot right from
board/freescale/mx6sabresd/README
$ sudo dd if=u-boot-dtb.img of=/dev/sdX bs=1K seek=69

will override the SPL, isn't it?

>
> I am interested to see if this solution could load
> u-boot-imx6-with-spl.bin via imx_usb_loader in Serial Download Mode.
>
> Currently it is not possible to load SPL + u-boot-dtb.img + FIT via
> imx_usb_loader. Does it work with your proposal?

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

Re: [U-Boot] [PATCH 1/4] crypto/fsl: Introduce API to save/restore job-ring context

2019-04-30 Thread Bryan O'Donoghue




On 25/04/2019 23:13, Breno Matheus Lima wrote:

Hi Bryan,

Em ter, 23 de abr de 2019 às 07:20, Bryan O'Donoghue
 escreveu:


We need to handle the case where DEK blobs are passed to the BootROM. In
this case, unlike in HAB authentication the BootROM checks job-ring
ownership set to secure world.

One possible solution is to set the job-ring ownership to the expected
state for DEK blobs and then restore to whatever the run-time wants.

For the case where Linux runs in normal-world we would want to set the
job-ring ownership to normal-world.

The first step in the ownership context switch dance is making an API to do
it.

This patch introduces:

void __weak sec_set_jr_context_secure(void);
void __weak sec_set_jr_context_normal(void);

This can be over-ridden for a given architecture, as will be necessary for
the MPC85xxx

Signed-off-by: Bryan O'Donoghue 
---
  drivers/crypto/fsl/jr.c | 38 ++
  include/fsl_sec.h   |  3 +++
  2 files changed, 41 insertions(+)

diff --git a/drivers/crypto/fsl/jr.c b/drivers/crypto/fsl/jr.c
index cc8d3b02a5..7b13aa4a61 100644
--- a/drivers/crypto/fsl/jr.c
+++ b/drivers/crypto/fsl/jr.c
@@ -574,6 +574,44 @@ static int rng_init(uint8_t sec_idx)
 return ret;
  }
  #endif
+
+static void __sec_set_jr_context_secure(uint8_t sec_idx)
+{
+   ccsr_sec_t *sec = (void *)SEC_ADDR(sec_idx);
+   uint32_t jrown_ns;
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(sec->jrliodnr); i++) {
+   jrown_ns = sec_in32(>jrliodnr[i].ms);
+   jrown_ns &= ~(JROWN_NS | JRMID_NS);


We have the following definition at drivers/crypto/fsl/jr.h:

#define JRMID_NS 0x0001

Seems that we are setting JROWN_MID field which is not TrustZone
related, from i.MX7D Security Reference Manual:

Job Ring Owner's MID. This field defines the MID of the bus master
that is permitted to read or write the registers that are specific to
a particular Job Ring. These registers include the job ring
configuration registers, the interrupt registers, the CAAM Secure
Memory Access Permissions and Secure Memory Access Group registers and
the ring buffer registers.


Hrmm, just seeing your response now Breno.

What we have is:
include/fsl_sec.h:#define JR_MID2/* Matches ROM configuration */

There's a decent argument to read what the BootROM has set for JR_MID 
and write it back ...


Let me include that in v2.

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

Re: [U-Boot] [PATCH 0/4] Tidy up some dangling OP-TEE gotchas

2019-04-30 Thread Fabio Estevam

On Mon, Apr 29, 2019 at 10:31 PM Bryan O'Donoghue
 wrote:
>
>
>
> On 24/04/2019 01:43, Bryan O'Donoghue wrote:
> > Rober P Day rightly pointed out that some odd OP-TEE specific defines were
> > appearing in his defconfig, despite not having CONFIG_OPTEE=y set in his
> > defconfig.
>
> Ping,
>
> Robert, Rui, Fabio - do you guys want changes here ?

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

[U-Boot] [PATCH] ARM: dts: logicpd-som-lv: Fix MMC1 card detect

The card detect pin was incorrectly using IRQ_TYPE_LEVEL_LOW
instead of GPIO_ACTIVE_LOW when reading the state of the CD pin.

Without this patch, MMC1 won't be detected.

This is the same patch submitted to linux-omap, but I was hoping
to get it applied to U-Boot without having to wait for the
linux adoption and then backporting.

Fixes: 5448ff33f281 ("ARM: DTS: Resync Logic PD SOM-LV 37xx
devkit with Linux 4.18-RC4")

Signed-off-by: Adam Ford 

diff --git a/arch/arm/dts/logicpd-som-lv-baseboard.dtsi 
b/arch/arm/dts/logicpd-som-lv-baseboard.dtsi
index 4990ed90dc..3524766515 100644
--- a/arch/arm/dts/logicpd-som-lv-baseboard.dtsi
+++ b/arch/arm/dts/logicpd-som-lv-baseboard.dtsi
@@ -152,8 +152,8 @@
interrupts-extended = < 83 _pmx_core 0x11a>;
pinctrl-names = "default";
pinctrl-0 = <_pins>;
-   wp-gpios = < 30 GPIO_ACTIVE_HIGH>;/* gpio_126 */
-   cd-gpios = < 14 IRQ_TYPE_LEVEL_LOW>;  /* gpio_110 */
+   wp-gpios = < 30 GPIO_ACTIVE_HIGH>;/* gpio_126 */
+   cd-gpios = < 14 GPIO_ACTIVE_LOW>; /* gpio_110 */
vmmc-supply = <>;
bus-width = <4>;
cap-power-off-card;
-- 
2.17.1

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

Re: [U-Boot] [PATCH] Makefile: Create single image for imx6 socs based boards

2019-04-30 Thread Fabio Estevam

Hi Shyam,

On Tue, Apr 30, 2019 at 7:34 AM Shyam Saini
 wrote:
>
> IMX6 platform has two stage boot loaders like SPL and
> U-Boot proper. For each stage we need to burn the image
> on to flash with respective offsets.
>
> This patch create a single image using binman, so that
> user can get rid of burning different stage boot images.
>
> without this patch:
> --
> $ sudo dd if=SPL of=/dev/mmcblk0 bs=1k seek=1
> $ sudo dd if=u-boot-dtb.img of=/dev/mmcblk0 bs=1k seek=69
>
> with this patch:
> ---
> $ sudo dd if=u-boot-imx6-with-spl.bin of=/dev/mmcblk0 bs=1k seek=1
>
> This would be easily extended to single image creation
> for other imx6 soc boards.
>
> This was tested on engicam imx6qdl and imx6ul boards
>
> Reviewed-by: Jagan Teki 
> Signed-off-by: Shyam Saini 

I like the idea, but this breaks the build for mx6sabresd_defconfig:

  COPYspl/u-boot-spl.bin
  CFGSspl/u-boot-spl.cfgout
  MKIMAGE SPL
  BINMAN  u-boot-imx6-with-spl.bin
Wrote map file './image.map' to show errors
binman: Node '/binman/u-boot-img': Offset 0x11000 (69632) overlaps
with previous entry '/binman/blob' ending at 0x11c00 (72704)
Makefile:1374: recipe for target 'u-boot-imx6-with-spl.bin' failed
make: *** [u-boot-imx6-with-spl.bin] Error 1

I am interested to see if this solution could load
u-boot-imx6-with-spl.bin via imx_usb_loader in Serial Download Mode.

Currently it is not possible to load SPL + u-boot-dtb.img + FIT via
imx_usb_loader. Does it work with your proposal?

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

Re: [U-Boot] [PATCH] core: ofnode: Fix ASAN-reported stack-buffer-overflow in of_get_address

2019-04-30 Thread Eugeniu Rosca

Hi Jeremy,

Would you kindly feedback if it's possible to include commit
https://github.com/getpatchwork/patchwork/commit/67faf96ab96d932
into U-Boot's patchwork to avoid occasional glitches in the
description of U-Boot commits?

On Sun, Apr 14, 2019 at 07:39:19PM -0400, Tom Rini wrote:
> On Sun, Apr 14, 2019 at 10:13:15PM +0200, Eugeniu Rosca wrote:
> > Hi Simon,
> >  CC: Tom, Yamada-san, Jiri, Stephen,
> > 
> > On Sat, Mar 30, 2019 at 03:19:23PM -0600, Simon Glass wrote:
> > > Hi Eugeniu,
> > > 
> > > On Mon, 25 Mar 2019 at 04:44, Eugeniu Rosca  wrote:
> > > >
> > > > Hello Simon,
> > > >
> > > > On Sun, Mar 10, 2019 at 03:51:47PM -0600, Simon Glass wrote:
> > > > [..]
> > > > > Reviewed-by: Simon Glass 
> > > >
> > > > Can this fix go to u-boot-dm or is more review required?
> > > >
> > > 
> > > Yes it looks like it is in my queue.
> > > 
> > > Regards,
> > > Simon
> > 
> > First, many thanks for pushing the fix to u-boot-dm.
> > 
> > Second, I would like to (repeatedly [0]) point out a pretty rare
> > corruption of patch metadata, which places the 'Reviewed-by:'
> > (and actually any other "*-by: ") signature on top of the '='
> > line if the latter is present in commit description (see [1]).
> > 
> > As Yamada-san pointed out in [0], this is presumably caused by a
> > patchwork bug and after some grepping through the patchwork git
> > history, it looks like the issue is already fixed in patchwork master
> > thanks to Jiri and Stephen via commit [2].
> > 
> > My guess is that the U-Boot patchwork version might not be containing
> > this recent fix, hence still showcasing the wrong behavior?
> > 
> > FWIW, at least below U-Boot commits exhibit the same inconsistency:
> > 
> > u-boot $> for c in $(git log --format=%h --grep "^==="); \
> >   do \
> >   git log --format=%B -1 $c | grep -B 2 "^===" | \
> >   grep -q "by:.*@" && git --no-pager log --oneline -1 $c; \
> >   done
> > 
> > 0506620f4f49 sata: sata_mv: Add DM support to enable CONFIG_BLK usage
> > 9bfacf249b10 core: ofnode: Fix ASAN-reported stack-buffer-overflow in 
> > of_get_address
> > e1904f4530a3 common: avb_verify: Fix division by zero in mmc_byte_io()
> > e91610da7c8a kconfig: re-sync with Linux 4.17-rc4
> > e810565e23cd i.MX6DL: mamoj: Add PFUZE100 support
> > dda9892171c3 i.MX6DL: mamoj: Add I2C support
> > a0b0ff0ae643 arm: dra7xx: Fix Linux boot from eMMC
> > f6d245b8c56c arm: am57xx: Fix Linux boot from eMMC
> > 67ff9e11f397 wandboard: move environment partition farther from u-boot.img
> > 
> > [0] https://marc.info/?l=u-boot=152643616902958=2
> > [1] http://git.denx.de/?p=u-boot.git;a=commitdiff;h=9bfacf249b10
> > [2] https://github.com/getpatchwork/patchwork/commit/67faf96ab96d932
> > ("parser: fix parsing of patches with headings")
> 
> Adding in Jeremy since we just use the ozlabs patchwork, thanks!
> 
> -- 
> Tom

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

Re: [U-Boot] [PATCH v12 9/9] ARM: socfpga: Increase Malloc pool size to support FAT filesystem in SPL

On Tue, Apr 30, 2019 at 2:19 PM Chee, Tien Fong
 wrote:
>
> On Sat, 2019-04-27 at 21:50 +0200, Simon Goldschmidt wrote:
> >
> > On 19.03.19 09:50, tien.fong.c...@intel.com wrote:
> > >
> > > From: Tien Fong Chee 
> > >
> > > Increasing Malloc pool size up to 0x15000 is required to support
> > > FAT in SPL
> > > . The result of calculation is come from after applying some few
> > > patches
> > "Some few patches"? What should that mean? Either you refer to the
> > current state or you can refer to the patchwork items.
> >
> > >
> > > which are required for optimizing vfat and maximizing resusable of
> > > the
> > > memory pool, and then followed by the size required come from
> > > default max
> > > cluster(0x1) + others(0x2000) + additional memory for
> > > headroom(0x3000).
> > > Previous records of describing these few patches can be checked
> > > from here
> > > [v7]: https://www.mail-archive.com/u-boot@lists.denx.de/msg314511.h
> > > tml .
> > Why do you refer to mail-archive.com instead of patchwork?
> Contains the cover letter in case reviewer need to know more
> information.

I think you understood that wrong. Why do you reference a 3rd party
host (mail-archive.com) instead of the official list archive or patchwork?

And please note patchwork keeps the cover letter as well.

Also note, this is the commit message which will got into the git lot.
Referencing v7 and older history seems misplaced here. Better move
it below the '---'.

Regards,
Simon

>
> Thanks.
> >
> > >
> > >
> > > Signed-off-by: Tien Fong Chee 
> > >
> > > ---
> > >
> > > changes for v12
> > > - Improved the commit messages.
> > >
> > > changes for v11
> > > - No changes.
> > >
> > > changes for v10
> > > - No changes.
> > >
> > > changes for v9
> > > - No changes.
> > >
> > > changes for v8
> > > - Moved the FIT related configs to the patch of configuration for
> > > FPGA
> > >SoCFPGA A10 SoCDK.
> > >
> > > changes for v7
> > > - Keep minimal configs.
> > > ---
> > >   include/configs/socfpga_common.h | 4 ++--
> > >   1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/include/configs/socfpga_common.h
> > > b/include/configs/socfpga_common.h
> > > index 181af9b646..22533036ed 100644
> > > --- a/include/configs/socfpga_common.h
> > > +++ b/include/configs/socfpga_common.h
> > > @@ -1,6 +1,6 @@
> > >   /* SPDX-License-Identifier: GPL-2.0+ */
> > >   /*
> > > - * Copyright (C) 2012 Altera Corporation 
> > > + * Copyright (C) 2012-2019 Altera Corporation 
> > >*/
> > >   #ifndef __CONFIG_SOCFPGA_COMMON_H__
> > >   #define __CONFIG_SOCFPGA_COMMON_H__
> > > @@ -254,7 +254,7 @@ unsigned int
> > > cm_get_qspi_controller_clk_hz(void);
> > >   #if defined(CONFIG_TARGET_SOCFPGA_ARRIA10)
> > >   /* SPL memory allocation configuration, this is for FAT
> > > implementation */
> > >   #ifndef CONFIG_SYS_SPL_MALLOC_START
> > > -#define CONFIG_SYS_SPL_MALLOC_SIZE 0x0001
> > > +#define CONFIG_SYS_SPL_MALLOC_SIZE 0x00015000
> > >   #define CONFIG_SYS_SPL_MALLOC_START   (CONFIG_SYS_INIT_RAM_S
> > > IZE - \
> > >  CONFIG_SYS_SPL_MALLOC_SI
> > > ZE + \
> > >  CONFIG_SYS_INIT_RAM_ADDR
> > > )
> > >
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v12 5/9] ARM: socfpga: Add FPGA drivers for Arria 10 FPGA bitstream loading

On Tue, Apr 30, 2019 at 2:09 PM Chee, Tien Fong
 wrote:
>
> On Sat, 2019-04-27 at 21:57 +0200, Simon Goldschmidt wrote:
> >
> > On 19.03.19 09:50, tien.fong.c...@intel.com wrote:
> > >
> > > From: Tien Fong Chee 
> > >
> > > Add FPGA driver to support program FPGA with FPGA bitstream loading
> > > from
> > > filesystem. The driver are designed based on generic firmware
> > > loader
> > > framework. The driver can handle FPGA program operation from
> > > loading FPGA
> > > bitstream in flash to memory and then to program FPGA.
> > >
> > > Signed-off-by: Tien Fong Chee 
> > >
> > > ---
> > >
> > > changes for v12
> > > - No changes.
> > >
> > > changes for v11
> > > - No changes.
> > >
> > > changes for v10
> > > -Cleaned up the codes.
> > > -Return -EPERM when programing core on non early IO release mode. >
> > > -Using live function to get rid of gd->
> > You got rid of gd-> in v10? How come I see numerous references to it
> > below?
>
> get rid of using gd->fdt_blob for finding the node_offset.
> Details in https://patchwork.ozlabs.org/patch/1044415/

Ah, ok. But still, here you're introducing yet more references to gd->fdt_blob.
That wouldn't work with a live tree, either, or would it?

Regards,
Simon

>
> -/*
> - * FPGA Manager to program the FPGA. This is the interface used by
> FPGA driver.
> - * Return 0 for sucess, non-zero for error.
> - */
> +ofnode get_fpga_mgr_ofnode(void)
> +{
> +   int node_offset;
> +
> +   fdtdec_find_aliases_for_id(gd->fdt_blob, "fpga_mgr",
>
> nit: using of live functions would be better to get rid of gd->.
>
> +   COMPAT_ALTERA_SOCFPGA_FPGA0,
> +   _offset, 1);
>
> Thanks.
> >
> > >
> > > -Removed @0 for fs-loader node
> > >
> > > changes for v9
> > > - Support data offset
> > > - Added default DDR load address
> > > - Squashed the image.h
> > > - Changed to phandle
> > > - Ensure the DDR is fully up running by checking the gd->ram
> > >
> > > changes for v8
> > > - Added codes to discern bitstream type based on fpga node name.
> > >
> > > changes for v7
> > > - Restructure the FPGA driver to support both peripheral bitstream
> > > and core
> > >bitstream bundled into FIT image.
> > > - Support loadable property for core bitstream. User can set
> > > loadable
> > >in DDR for better performance. This loading would be done in one
> > > large
> > >chunk instead of chunk by chunk loading with small memory
> > > buffer.
> > > ---
> > >   arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts   |  17 +
> > >   .../include/mach/fpga_manager_arria10.h|  39 +-
> > >   drivers/fpga/socfpga_arria10.c | 497
> > > -
> > >   include/image.h|   4 +
> > >   4 files changed, 542 insertions(+), 15 deletions(-)
> > >
> > > diff --git a/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
> > > b/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
> > > index 998d811210..cc761967c7 100644
> > > --- a/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
> > > +++ b/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
> > > @@ -18,6 +18,23 @@
> > >   /dts-v1/;
> > >   #include "socfpga_arria10_socdk.dtsi"
> > >
> > > +/ {
> > > +   chosen {
> > > +   firmware-loader = <_loader0>;
> > > +   };
> > > +
> > > +   fs_loader0: fs-loader {
> > > +   u-boot,dm-pre-reloc;
> > > +   compatible = "u-boot,fs-loader";
> > > +   phandlepart = < 1>;
> > > +   };
> > > +};
> > > +
> > > +_mgr {
> > > +   u-boot,dm-pre-reloc;
> > > +   altr,bitstream = "fit_spl_fpga.itb";
> > > +};
> > > +
> > >{
> > > u-boot,dm-pre-reloc;
> > > status = "okay";
> > > diff --git a/arch/arm/mach-
> > > socfpga/include/mach/fpga_manager_arria10.h b/arch/arm/mach-
> > > socfpga/include/mach/fpga_manager_arria10.h
> > > index 09d13f6fd3..c5f67714aa 100644
> > > --- a/arch/arm/mach-socfpga/include/mach/fpga_manager_arria10.h
> > > +++ b/arch/arm/mach-socfpga/include/mach/fpga_manager_arria10.h
> > > @@ -1,9 +1,13 @@
> > >   /* SPDX-License-Identifier: GPL-2.0 */
> > >   /*
> > > - * Copyright (C) 2017 Intel Corporation 
> > > + * Copyright (C) 2017-2019 Intel Corporation 
> > >* All rights reserved.
> > >*/
> > >
> > > +#include 
> > > +#include 
> > > +#include 
> > > +
> > >   #ifndef _FPGA_MANAGER_ARRIA10_H_
> > >   #define _FPGA_MANAGER_ARRIA10_H_
> > >
> > > @@ -51,6 +55,10 @@
> > >   #define ALT_FPGAMGR_IMGCFG_CTL_02_CFGWIDTH_SET_MSK
> > > BIT(24)
> > >   #define ALT_FPGAMGR_IMGCFG_CTL_02_CDRATIO_LSB
> > > 16
> > >
> > > +#define FPGA_SOCFPGA_A10_RBF_UNENCRYPTED   0xa65c
> > > +#define FPGA_SOCFPGA_A10_RBF_ENCRYPTED 0xa65d
> > > +#define FPGA_SOCFPGA_A10_RBF_PERIPH0x0001
> > > +#define FPGA_SOCFPGA_A10_RBF_CORE  0x8001
> > >   #ifndef __ASSEMBLY__
> > >
> > >   struct socfpga_fpga_manager {
> > > @@ -88,12 +96,39 @@ struct socfpga_fpga_manager {
> > > u32  imgcfg_fifo_status;
> > >   };
> > >
> > > +enum

Re: [U-Boot] [PATCH] README: davinci: update the documentation for DaVinci

2019-04-30 Thread Sekhar Nori

On 30/04/19 2:38 PM, Adam Ford wrote:
> On Tue, Apr 30, 2019 at 2:39 AM Bartosz Golaszewski  wrote:
>>
>> From: Bartosz Golaszewski 
>>
>> The DM* family of SOCs is no longer supported. We now support the
>> omap-l138 lcdk board and Lego EV3 platform. Reflect those changes
> 
> Don't forget about the da850 EVM

Apart from this:

Reviewed-by: Sekhar Nori 

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

Re: [U-Boot] [PATCH v12 9/9] ARM: socfpga: Increase Malloc pool size to support FAT filesystem in SPL

2019-04-30 Thread Chee, Tien Fong

On Sat, 2019-04-27 at 21:50 +0200, Simon Goldschmidt wrote:
> 
> On 19.03.19 09:50, tien.fong.c...@intel.com wrote:
> > 
> > From: Tien Fong Chee 
> > 
> > Increasing Malloc pool size up to 0x15000 is required to support
> > FAT in SPL
> > . The result of calculation is come from after applying some few
> > patches
> "Some few patches"? What should that mean? Either you refer to the 
> current state or you can refer to the patchwork items.
> 
> > 
> > which are required for optimizing vfat and maximizing resusable of
> > the
> > memory pool, and then followed by the size required come from
> > default max
> > cluster(0x1) + others(0x2000) + additional memory for
> > headroom(0x3000).
> > Previous records of describing these few patches can be checked
> > from here
> > [v7]: https://www.mail-archive.com/u-boot@lists.denx.de/msg314511.h
> > tml .
> Why do you refer to mail-archive.com instead of patchwork?
Contains the cover letter in case reviewer need to know more
information.

Thanks.
> 
> > 
> > 
> > Signed-off-by: Tien Fong Chee 
> > 
> > ---
> > 
> > changes for v12
> > - Improved the commit messages.
> > 
> > changes for v11
> > - No changes.
> > 
> > changes for v10
> > - No changes.
> > 
> > changes for v9
> > - No changes.
> > 
> > changes for v8
> > - Moved the FIT related configs to the patch of configuration for
> > FPGA
> >    SoCFPGA A10 SoCDK.
> > 
> > changes for v7
> > - Keep minimal configs.
> > ---
> >   include/configs/socfpga_common.h | 4 ++--
> >   1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/include/configs/socfpga_common.h
> > b/include/configs/socfpga_common.h
> > index 181af9b646..22533036ed 100644
> > --- a/include/configs/socfpga_common.h
> > +++ b/include/configs/socfpga_common.h
> > @@ -1,6 +1,6 @@
> >   /* SPDX-License-Identifier: GPL-2.0+ */
> >   /*
> > - * Copyright (C) 2012 Altera Corporation 
> > + * Copyright (C) 2012-2019 Altera Corporation 
> >    */
> >   #ifndef __CONFIG_SOCFPGA_COMMON_H__
> >   #define __CONFIG_SOCFPGA_COMMON_H__
> > @@ -254,7 +254,7 @@ unsigned int
> > cm_get_qspi_controller_clk_hz(void);
> >   #if defined(CONFIG_TARGET_SOCFPGA_ARRIA10)
> >   /* SPL memory allocation configuration, this is for FAT
> > implementation */
> >   #ifndef CONFIG_SYS_SPL_MALLOC_START
> > -#define CONFIG_SYS_SPL_MALLOC_SIZE 0x0001
> > +#define CONFIG_SYS_SPL_MALLOC_SIZE 0x00015000
> >   #define CONFIG_SYS_SPL_MALLOC_START   (CONFIG_SYS_INIT_RAM_S
> > IZE - \
> >      CONFIG_SYS_SPL_MALLOC_SI
> > ZE + \
> >      CONFIG_SYS_INIT_RAM_ADDR
> > )
> > 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v12 5/9] ARM: socfpga: Add FPGA drivers for Arria 10 FPGA bitstream loading

2019-04-30 Thread Chee, Tien Fong

On Sat, 2019-04-27 at 21:57 +0200, Simon Goldschmidt wrote:
> 
> On 19.03.19 09:50, tien.fong.c...@intel.com wrote:
> > 
> > From: Tien Fong Chee 
> > 
> > Add FPGA driver to support program FPGA with FPGA bitstream loading
> > from
> > filesystem. The driver are designed based on generic firmware
> > loader
> > framework. The driver can handle FPGA program operation from
> > loading FPGA
> > bitstream in flash to memory and then to program FPGA.
> > 
> > Signed-off-by: Tien Fong Chee 
> > 
> > ---
> > 
> > changes for v12
> > - No changes.
> > 
> > changes for v11
> > - No changes.
> > 
> > changes for v10
> > -Cleaned up the codes.
> > -Return -EPERM when programing core on non early IO release mode. >
> > -Using live function to get rid of gd->
> You got rid of gd-> in v10? How come I see numerous references to it
> below?

get rid of using gd->fdt_blob for finding the node_offset.
Details in https://patchwork.ozlabs.org/patch/1044415/ 

-/*
- * FPGA Manager to program the FPGA. This is the interface used by
FPGA driver.
- * Return 0 for sucess, non-zero for error.
- */
+ofnode get_fpga_mgr_ofnode(void)
+{
+   int node_offset;
+
+   fdtdec_find_aliases_for_id(gd->fdt_blob, "fpga_mgr",

nit: using of live functions would be better to get rid of gd->.

+   COMPAT_ALTERA_SOCFPGA_FPGA0,
+   _offset, 1);

Thanks.
> 
> > 
> > -Removed @0 for fs-loader node
> > 
> > changes for v9
> > - Support data offset
> > - Added default DDR load address
> > - Squashed the image.h
> > - Changed to phandle
> > - Ensure the DDR is fully up running by checking the gd->ram
> > 
> > changes for v8
> > - Added codes to discern bitstream type based on fpga node name.
> > 
> > changes for v7
> > - Restructure the FPGA driver to support both peripheral bitstream
> > and core
> >    bitstream bundled into FIT image.
> > - Support loadable property for core bitstream. User can set
> > loadable
> >    in DDR for better performance. This loading would be done in one
> > large
> >    chunk instead of chunk by chunk loading with small memory
> > buffer.
> > ---
> >   arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts   |  17 +
> >   .../include/mach/fpga_manager_arria10.h|  39 +-
> >   drivers/fpga/socfpga_arria10.c | 497
> > -
> >   include/image.h|   4 +
> >   4 files changed, 542 insertions(+), 15 deletions(-)
> > 
> > diff --git a/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
> > b/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
> > index 998d811210..cc761967c7 100644
> > --- a/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
> > +++ b/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
> > @@ -18,6 +18,23 @@
> >   /dts-v1/;
> >   #include "socfpga_arria10_socdk.dtsi"
> >   
> > +/ {
> > +   chosen {
> > +   firmware-loader = <_loader0>;
> > +   };
> > +
> > +   fs_loader0: fs-loader {
> > +   u-boot,dm-pre-reloc;
> > +   compatible = "u-boot,fs-loader";
> > +   phandlepart = < 1>;
> > +   };
> > +};
> > +
> > +_mgr {
> > +   u-boot,dm-pre-reloc;
> > +   altr,bitstream = "fit_spl_fpga.itb";
> > +};
> > +
> >    {
> >     u-boot,dm-pre-reloc;
> >     status = "okay";
> > diff --git a/arch/arm/mach-
> > socfpga/include/mach/fpga_manager_arria10.h b/arch/arm/mach-
> > socfpga/include/mach/fpga_manager_arria10.h
> > index 09d13f6fd3..c5f67714aa 100644
> > --- a/arch/arm/mach-socfpga/include/mach/fpga_manager_arria10.h
> > +++ b/arch/arm/mach-socfpga/include/mach/fpga_manager_arria10.h
> > @@ -1,9 +1,13 @@
> >   /* SPDX-License-Identifier: GPL-2.0 */
> >   /*
> > - * Copyright (C) 2017 Intel Corporation 
> > + * Copyright (C) 2017-2019 Intel Corporation 
> >    * All rights reserved.
> >    */
> >   
> > +#include 
> > +#include 
> > +#include 
> > +
> >   #ifndef _FPGA_MANAGER_ARRIA10_H_
> >   #define _FPGA_MANAGER_ARRIA10_H_
> >   
> > @@ -51,6 +55,10 @@
> >   #define ALT_FPGAMGR_IMGCFG_CTL_02_CFGWIDTH_SET_MSK
> > BIT(24)
> >   #define ALT_FPGAMGR_IMGCFG_CTL_02_CDRATIO_LSB 
> > 16
> >   
> > +#define FPGA_SOCFPGA_A10_RBF_UNENCRYPTED   0xa65c
> > +#define FPGA_SOCFPGA_A10_RBF_ENCRYPTED 0xa65d
> > +#define FPGA_SOCFPGA_A10_RBF_PERIPH0x0001
> > +#define FPGA_SOCFPGA_A10_RBF_CORE  0x8001
> >   #ifndef __ASSEMBLY__
> >   
> >   struct socfpga_fpga_manager {
> > @@ -88,12 +96,39 @@ struct socfpga_fpga_manager {
> >     u32  imgcfg_fifo_status;
> >   };
> >   
> > +enum rbf_type {
> > +   unknown,
> > +   periph_section,
> > +   core_section
> > +};
> > +
> > +enum rbf_security {
> > +   invalid,
> > +   unencrypted,
> > +   encrypted
> > +};
> > +
> > +struct rbf_info {
> > +   enum rbf_type section;
> > +   enum rbf_security security;
> > +};
> > +
> > +struct fpga_loadfs_info {
> > +   fpga_fs_info *fpga_fsinfo;
> > +   u32 remaining;
> > +   u32 offset;
> > +   struct rbf_info rbfinfo;
> > +};
> > +
> >

Re: [U-Boot] [PATCH v12 4/9] ARM: socfpga: Moving the watchdog reset to the for-loop status polling

2019-04-30 Thread Chee, Tien Fong

On Sat, 2019-04-27 at 21:34 +0200, Simon Goldschmidt wrote:
> 
> On 19.03.19 09:50, tien.fong.c...@intel.com wrote:
> > 
> > From: Tien Fong Chee 
> > 
> > Ensure the watchdog is reset timely on each status polling.
> I would have expected a longer commit message here explaining why
> this 
> is done, and from where, where to, and why the watchdog reset has
> been 
> moved.
> 
> Anyway, I don't want to hold back this series again for this, but
> please 
> next time: write longer commit messages. Better write too much than
> risk 
> someone in the future doesn't get what or why you did things.
> 
Noted.

Thanks.
> 
> > 
> > 
> > Signed-off-by: Tien Fong Chee 
> > 
> > ---
> > 
> > changes for v12
> > - Improved the commit messages.
> > 
> > changes for v11
> > - No changes.
> > 
> > changes for v10
> > - This patch was split out from [PATCH v10 5/9]
> >    ARM: socfpga: Add FPGA drivers for Arria 10 FPGA.
> > ---
> >   drivers/fpga/socfpga_arria10.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/fpga/socfpga_arria10.c
> > b/drivers/fpga/socfpga_arria10.c
> > index b0abe1955c..9499d1a014 100644
> > --- a/drivers/fpga/socfpga_arria10.c
> > +++ b/drivers/fpga/socfpga_arria10.c
> > @@ -360,6 +360,7 @@ static int fpgamgr_program_poll_cd(void)
> >     printf("nstatus == 0 while waiting for
> > condone\n");
> >     return -EPERM;
> >     }
> > +   WATCHDOG_RESET();
> >     }
> >   
> >     if (i == FPGA_TIMEOUT_CNT)
> > @@ -433,7 +434,6 @@ int fpgamgr_program_finish(void)
> >     printf("FPGA: Poll CD failed with error code
> > %d\n", status);
> >     return -EPERM;
> >     }
> > -   WATCHDOG_RESET();
> >   
> >     /* Ensure the FPGA entering user mode */
> >     status = fpgamgr_program_poll_usermode();
> > 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 0/4] Tidy up some dangling OP-TEE gotchas

2019-04-30 Thread Rui Miguel Silva

Hi Bryan,
On Tue 30 Apr 2019 at 02:30, Bryan O'Donoghue wrote:
> On 24/04/2019 01:43, Bryan O'Donoghue wrote:
>> Rober P Day rightly pointed out that some odd OP-TEE specific defines were
>> appearing in his defconfig, despite not having CONFIG_OPTEE=y set in his
>> defconfig.
>
> Ping,
>
> Robert, Rui, Fabio - do you guys want changes here ?

Regarding OPTEE, patches 1/4 and 2/4:
Acked-by: Rui Miguel Silva 

---
Cheers,
Rui

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

[U-Boot] [PATCH] Makefile: Create single image for imx6 socs based boards

2019-04-30 Thread Shyam Saini

IMX6 platform has two stage boot loaders like SPL and
U-Boot proper. For each stage we need to burn the image
on to flash with respective offsets.

This patch create a single image using binman, so that
user can get rid of burning different stage boot images.

without this patch:
--
$ sudo dd if=SPL of=/dev/mmcblk0 bs=1k seek=1
$ sudo dd if=u-boot-dtb.img of=/dev/mmcblk0 bs=1k seek=69

with this patch:
---
$ sudo dd if=u-boot-imx6-with-spl.bin of=/dev/mmcblk0 bs=1k seek=1

This would be easily extended to single image creation
for other imx6 soc boards.

This was tested on engicam imx6qdl and imx6ul boards

Reviewed-by: Jagan Teki 
Signed-off-by: Shyam Saini 
---
 Makefile | 10 ++
 arch/arm/dts/imx6-u-boot-binman.dtsi | 16 
 arch/arm/dts/imx6qdl-u-boot.dtsi |  1 +
 arch/arm/dts/imx6ul-u-boot.dtsi  |  1 +
 arch/arm/mach-imx/mx6/Kconfig|  2 ++
 doc/imx/common/imx6.txt  |  5 +
 6 files changed, 35 insertions(+)
 create mode 100644 arch/arm/dts/imx6-u-boot-binman.dtsi

diff --git a/Makefile b/Makefile
index f2c7bb6041..474271a1d0 100644
--- a/Makefile
+++ b/Makefile
@@ -851,6 +851,11 @@ ifeq ($(CONFIG_ARCH_SUNXI)$(CONFIG_SPL),yy)
 ALL-y += u-boot-sunxi-with-spl.bin
 endif
 
+# Build a combined spl + u-boot image for imx6
+ifeq ($(filter y, $(CONFIG_MX6QDL) 
$(CONFIG_MX6UL))$(CONFIG_SPL)$(CONFIG_OF_CONTROL),yyy)
+ALL-$(CONFIG_ARCH_MX6) += u-boot-imx6-with-spl.bin
+endif
+
 # enable combined SPL/u-boot/dtb rules for tegra
 ifeq ($(CONFIG_TEGRA)$(CONFIG_SPL),yy)
 ALL-y += u-boot-tegra.bin u-boot-nodtb-tegra.bin
@@ -1364,6 +1369,11 @@ u-boot-br.bin: u-boot FORCE
 endif
 endif
 
+ifeq ($(filter y, $(CONFIG_MX6QDL) 
$(CONFIG_MX6UL))$(CONFIG_SPL)$(CONFIG_OF_CONTROL),yyy)
+u-boot-imx6-with-spl.bin: SPL u-boot-dtb.img FORCE
+   @$(call if_changed,binman)
+endif
+
 # x86 uses a large ROM. We fill it with 0xff, put the 16-bit stuff (including
 # reset vector) at the top, Intel ME descriptor at the bottom, and U-Boot in
 # the middle. This is handled by binman based on an image description in the
diff --git a/arch/arm/dts/imx6-u-boot-binman.dtsi 
b/arch/arm/dts/imx6-u-boot-binman.dtsi
new file mode 100644
index 00..fa02d5f61f
--- /dev/null
+++ b/arch/arm/dts/imx6-u-boot-binman.dtsi
@@ -0,0 +1,16 @@
+#include 
+
+/ {
+   binman {
+   filename = "u-boot-imx6-with-spl.bin";
+   pad-byte = <0xff>;
+
+   blob {
+   filename = "SPL";
+   };
+
+   u-boot-img {
+   offset = ;
+   };
+   };
+};
diff --git a/arch/arm/dts/imx6qdl-u-boot.dtsi b/arch/arm/dts/imx6qdl-u-boot.dtsi
index 0aa29e38b8..3dfa84dcac 100644
--- a/arch/arm/dts/imx6qdl-u-boot.dtsi
+++ b/arch/arm/dts/imx6qdl-u-boot.dtsi
@@ -2,6 +2,7 @@
 /*
  * Copyright (C) 2018 Jagan Teki 
  */
+#include "imx6-u-boot-binman.dtsi"
 
 / {
soc {
diff --git a/arch/arm/dts/imx6ul-u-boot.dtsi b/arch/arm/dts/imx6ul-u-boot.dtsi
index eb190cf8c8..4e769da0d5 100644
--- a/arch/arm/dts/imx6ul-u-boot.dtsi
+++ b/arch/arm/dts/imx6ul-u-boot.dtsi
@@ -2,6 +2,7 @@
 /*
  * Copyright (C) 2018 Jagan Teki 
  */
+#include "imx6-u-boot-binman.dtsi"
 
 / {
soc {
diff --git a/arch/arm/mach-imx/mx6/Kconfig b/arch/arm/mach-imx/mx6/Kconfig
index e782859b1e..7de1a00935 100644
--- a/arch/arm/mach-imx/mx6/Kconfig
+++ b/arch/arm/mach-imx/mx6/Kconfig
@@ -34,6 +34,7 @@ config MX6QDL
bool
select HAS_CAAM
select MX6_SMP
+   select BINMAN if SPL && OF_CONTROL
 
 config MX6S
bool
@@ -57,6 +58,7 @@ config MX6UL
select ROM_UNIFIED_SECTIONS
select SYSCOUNTER_TIMER
select SYS_L2CACHE_OFF
+   select BINMAN if SPL && OF_CONTROL
 
 config MX6UL_LITESOM
bool
diff --git a/doc/imx/common/imx6.txt b/doc/imx/common/imx6.txt
index eab88353f6..5a10f94957 100644
--- a/doc/imx/common/imx6.txt
+++ b/doc/imx/common/imx6.txt
@@ -88,3 +88,8 @@ Reading bank 4:
 
 Word 0x0002: 9f027772 0004
 
+2. Single Boot Image
+-
+Write your single imx6 uboot image as:
+
+$ sudo dd if=u-boot-imx6-with-spl.bin of=/dev/mmcblk0 bs=1k seek=1
-- 
2.11.0

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

[U-Boot] [PATCH 2/2] ARM: da850evm: Enable da850-ohci USB host controller

The DA850 EVM has one USB 1.1 OHCI Host controller.  With the
host controller now support DM_USB, this patch enables
the respective functions for the da850evm.

Signed-off-by: Adam Ford 
---
V2: No changes

diff --git a/configs/da850evm_defconfig b/configs/da850evm_defconfig
index ee39b0b1bc..1845813b2e 100644
--- a/configs/da850evm_defconfig
+++ b/configs/da850evm_defconfig
@@ -8,8 +8,8 @@ CONFIG_SPL_LIBCOMMON_SUPPORT=y
 CONFIG_SPL_LIBGENERIC_SUPPORT=y
 CONFIG_SYS_MALLOC_F_LEN=0x800
 CONFIG_SPL_SERIAL_SUPPORT=y
-CONFIG_SPL=y
 CONFIG_NR_DRAM_BANKS=1
+CONFIG_SPL=y
 CONFIG_SPL_SPI_FLASH_SUPPORT=y
 CONFIG_SPL_SPI_SUPPORT=y
 CONFIG_SYS_EXTRA_OPTIONS="MAC_ADDR_IN_SPIFLASH"
@@ -67,5 +67,10 @@ CONFIG_SYS_NS16550=y
 CONFIG_SPI=y
 CONFIG_DM_SPI=y
 CONFIG_DAVINCI_SPI=y
+CONFIG_USB=y
+CONFIG_DM_USB=y
+# CONFIG_SPL_DM_USB is not set
+CONFIG_USB_OHCI_HCD=y
+CONFIG_USB_OHCI_DA8XX=y
 # CONFIG_FAT_WRITE is not set
 CONFIG_USE_TINY_PRINTF=y
diff --git a/include/configs/da850evm.h b/include/configs/da850evm.h
index 94848f5128..9aaecdd1d5 100644
--- a/include/configs/da850evm.h
+++ b/include/configs/da850evm.h
@@ -267,6 +267,14 @@
 #define CONFIG_ENV_SIZE(16 << 10)
 #endif
 
+/* USB Configs */
+#define CONFIG_SYS_USB_OHCI_CPU_INIT
+#define CONFIG_USB_OHCI_NEW
+#define CONFIG_USB_STORAGE
+#define CONFIG_SYS_USB_OHCI_REGS_BASE  0x01E25000
+#define CONFIG_SYS_USB_OHCI_MAX_ROOT_PORTS 15
+#define CONFIG_SYS_USB_OHCI_SLOT_NAME  "da850evm"
+
 #ifndef CONFIG_DIRECT_NOR_BOOT
 /* defines for SPL */
 #define CONFIG_SYS_SPL_MALLOC_START(CONFIG_SYS_TEXT_BASE - \
-- 
2.17.1

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

[U-Boot] [i.MX8MM+CCF 38/41] clk: add composite clk support

Import clk composite clk support from Linux Kernel 5.1-rc5

Signed-off-by: Peng Fan 
---
 drivers/clk/Kconfig  |  14 
 drivers/clk/Makefile |   1 +
 drivers/clk/clk-composite.c  | 165 +++
 include/linux/clk-provider.h |  22 ++
 4 files changed, 202 insertions(+)
 create mode 100644 drivers/clk/clk-composite.c

diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 9df3bc731a..3735e235f5 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -53,6 +53,13 @@ config SPL_CLK_CCF
  Enable this option if you want to (re-)use the Linux kernel's Common
  Clock Framework [CCF] code in U-Boot's SPL.
 
+config SPL_CLK_COMPOSITE_CCF
+   bool "SPL Common Clock Framework [CCF] composite clk support "
+   depends on SPL_CLK_CCF
+   help
+ Enable this option if you want to (re-)use the Linux kernel's Common
+ Clock Framework [CCF] composite code in U-Boot's SPL.
+
 config CLK_CCF
bool "Common Clock Framework [CCF] support "
depends on CLK
@@ -60,6 +67,13 @@ config CLK_CCF
  Enable this option if you want to (re-)use the Linux kernel's Common
  Clock Framework [CCF] code in U-Boot's clock driver.
 
+config CLK_COMPOSITE_CCF
+   bool "Common Clock Framework [CCF] composite clk support "
+   depends on CLK_CCF
+   help
+ Enable this option if you want to (re-)use the Linux kernel's Common
+ Clock Framework [CCF] composite code in U-Boot's clock driver.
+
 config CLK_STM32F
bool "Enable clock driver support for STM32F family"
depends on CLK && (STM32F7 || STM32F4)
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 0bc8f7e5ce..6c71b0fc16 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_$(SPL_TPL_)CLK) += clk_fixed_rate.o
 obj-$(CONFIG_$(SPL_TPL_)CLK) += clk_fixed_factor.o
 obj-$(CONFIG_$(SPL_TPL_)CLK_CCF) += clk.o clk-divider.o clk-mux.o clk-gate.o
 obj-$(CONFIG_$(SPL_TPL_)CLK_CCF) += clk-fixed-factor.o
+obj-$(CONFIG_$(SPL_TPL_)CLK_COMPOSITE_CCF) += clk-composite.o
 
 obj-y += imx/
 obj-y += tegra/
diff --git a/drivers/clk/clk-composite.c b/drivers/clk/clk-composite.c
new file mode 100644
index 00..18adfd9850
--- /dev/null
+++ b/drivers/clk/clk-composite.c
@@ -0,0 +1,165 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2013 NVIDIA CORPORATION.  All rights reserved.
+ * Copyright 2019 NXP
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "clk.h"
+
+#define UBOOT_DM_CLK_COMPOSITE "clk_composite"
+
+static u8 clk_composite_get_parent(struct clk *clk)
+{
+   struct clk_composite *composite = to_clk_composite(
+   clk_dev_binded(clk) ?
+   (struct clk *)dev_get_driver_data(clk->dev) : clk);
+   struct clk *mux = composite->mux;
+
+   return clk_mux_get_parent(mux);
+}
+
+static int clk_composite_set_parent(struct clk *clk, struct clk *parent)
+{
+   struct clk_composite *composite = to_clk_composite(
+   clk_dev_binded(clk) ?
+   (struct clk *)dev_get_driver_data(clk->dev) : clk);
+   const struct clk_ops *mux_ops = composite->mux_ops;
+   struct clk *mux = composite->mux;
+
+   return mux_ops->set_parent(mux, parent);
+}
+
+static unsigned long clk_composite_recalc_rate(struct clk *clk)
+{
+   struct clk_composite *composite = to_clk_composite(
+   clk_dev_binded(clk) ?
+   (struct clk *)dev_get_driver_data(clk->dev) : clk);
+   const struct clk_ops *rate_ops = composite->rate_ops;
+   struct clk *rate = composite->rate;
+
+   return rate_ops->get_rate(rate);
+}
+
+static ulong clk_composite_set_rate(struct clk *clk, unsigned long rate)
+{
+   struct clk_composite *composite = to_clk_composite(
+   clk_dev_binded(clk) ?
+   (struct clk *)dev_get_driver_data(clk->dev) : clk);
+   const struct clk_ops *rate_ops = composite->rate_ops;
+   struct clk *clk_rate = composite->rate;
+
+   return rate_ops->set_rate(clk_rate, rate);
+}
+
+static int clk_composite_enable(struct clk *clk)
+{
+   struct clk_composite *composite = to_clk_composite(
+   clk_dev_binded(clk) ?
+   (struct clk *)dev_get_driver_data(clk->dev) : clk);
+   const struct clk_ops *gate_ops = composite->gate_ops;
+   struct clk *gate = composite->gate;
+
+   return gate_ops->enable(gate);
+}
+
+static int clk_composite_disable(struct clk *clk)
+{
+   struct clk_composite *composite = to_clk_composite(
+   clk_dev_binded(clk) ?
+   (struct clk *)dev_get_driver_data(clk->dev) : clk);
+   const struct clk_ops *gate_ops = composite->gate_ops;
+   struct clk *gate = composite->gate;
+
+   gate_ops->disable(gate);
+
+   return 0;
+}
+
+struct clk_ops clk_composite_ops = {
+   /* This will be set according to

[U-Boot] [i.MX8MM+CCF 24/41] imx: add get_cpu_rev support for i.MX8MM

There are several variants based on i.MX8MM, add the support in
get_cpu_rev

Signed-off-by: Peng Fan 
---
 arch/arm/mach-imx/imx8m/soc.c | 57 +++
 1 file changed, 47 insertions(+), 10 deletions(-)

diff --git a/arch/arm/mach-imx/imx8m/soc.c b/arch/arm/mach-imx/imx8m/soc.c
index 11251c5f9a..42b99945b4 100644
--- a/arch/arm/mach-imx/imx8m/soc.c
+++ b/arch/arm/mach-imx/imx8m/soc.c
@@ -130,25 +130,62 @@ static struct mm_region imx8m_mem_map[] = {
 
 struct mm_region *mem_map = imx8m_mem_map;
 
+static u32 get_cpu_variant_type(u32 type)
+{
+   struct ocotp_regs *ocotp = (struct ocotp_regs *)OCOTP_BASE_ADDR;
+   struct fuse_bank *bank = >bank[1];
+   struct fuse_bank1_regs *fuse =
+   (struct fuse_bank1_regs *)bank->fuse_regs;
+
+   u32 value = readl(>tester4);
+
+   if (type == MXC_CPU_IMX8MM) {
+   switch (value & 0x3) {
+   case 2:
+   if (value & 0x1c)
+   return MXC_CPU_IMX8MMDL;
+   else
+   return MXC_CPU_IMX8MMD;
+   case 3:
+   if (value & 0x1c)
+   return MXC_CPU_IMX8MMSL;
+   else
+   return MXC_CPU_IMX8MMS;
+   default:
+   if (value & 0x1c)
+   return MXC_CPU_IMX8MML;
+   break;
+   }
+   }
+
+   return type;
+}
+
 u32 get_cpu_rev(void)
 {
struct anamix_pll *ana_pll = (struct anamix_pll *)ANATOP_BASE_ADDR;
u32 reg = readl(_pll->digprog);
u32 type = (reg >> 16) & 0xff;
+   u32 major_low = (reg >> 8) & 0xff;
u32 rom_version;
 
reg &= 0xff;
 
-   if (reg == CHIP_REV_1_0) {
-   /*
-* For B0 chip, the DIGPROG is not updated, still TO1.0.
-* we have to check ROM version further
-*/
-   rom_version = readl((void __iomem *)ROM_VERSION_A0);
-   if (rom_version != CHIP_REV_1_0) {
-   rom_version = readl((void __iomem *)ROM_VERSION_B0);
-   if (rom_version >= CHIP_REV_2_0)
-   reg = CHIP_REV_2_0;
+   /* i.MX8MM */
+   if (major_low == 0x41) {
+   type = get_cpu_variant_type(MXC_CPU_IMX8MM);
+   } else {
+   if (reg == CHIP_REV_1_0) {
+   /*
+* For B0 chip, the DIGPROG is not updated, still TO1.0.
+* we have to check ROM version further
+*/
+   rom_version = readl((void __iomem *)ROM_VERSION_A0);
+   if (rom_version != CHIP_REV_1_0) {
+   rom_version = readl((void __iomem 
*)ROM_VERSION_B0);
+   if (rom_version >= CHIP_REV_2_0)
+   reg = CHIP_REV_2_0;
+   }
}
}
 
-- 
2.16.4

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

[U-Boot] [PATCH V2 0/2] Enable DA830 OHCI USB Controller with DM_USB

This patch enables the DA830 USB Host controller with DM_USB.

Adam Ford (2):
  usb: ohci: ohci-da8xx: Enable da850-ohci driver with DM support
  ARM: da850evm: Enable da850-ohci USB host controller

 configs/da850evm_defconfig|   7 +-
 drivers/usb/host/Kconfig  |   5 ++
 drivers/usb/host/ohci-da8xx.c | 138 +-
 include/configs/da850evm.h|   8 ++
 4 files changed, 156 insertions(+), 2 deletions(-)

-- 
2.17.1

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

[U-Boot] [i.MX8MM+CCF 28/41] imx8m: soc: probe clk before relocation

probe clk device before relocation to get cpu clk.

Signed-off-by: Peng Fan 
---
 arch/arm/mach-imx/imx8m/soc.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/arch/arm/mach-imx/imx8m/soc.c b/arch/arm/mach-imx/imx8m/soc.c
index 42b99945b4..07cda86bdd 100644
--- a/arch/arm/mach-imx/imx8m/soc.c
+++ b/arch/arm/mach-imx/imx8m/soc.c
@@ -14,6 +14,10 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -277,3 +281,20 @@ void reset_cpu(ulong addr)
 */
}
 }
+
+/* TODO: Add i.MX8MQ */
+#ifdef CONFIG_IMX8MM
+int arch_cpu_init_dm(void)
+{
+   struct udevice *dev;
+
+   uclass_find_first_device(UCLASS_CLK, );
+
+   for (; dev; uclass_find_next_device()) {
+   if (device_probe(dev))
+   continue;
+   }
+
+   return 0;
+}
+#endif
-- 
2.16.4

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

[U-Boot] [i.MX8MM+CCF 30/41] imx: add i.MX8MM PE property

i.MX8MM does not have LVTTL, it has a PE property

Signed-off-by: Peng Fan 
---
 arch/arm/include/asm/mach-imx/iomux-v3.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/include/asm/mach-imx/iomux-v3.h 
b/arch/arm/include/asm/mach-imx/iomux-v3.h
index b899a4ff6f..720e8f7043 100644
--- a/arch/arm/include/asm/mach-imx/iomux-v3.h
+++ b/arch/arm/include/asm/mach-imx/iomux-v3.h
@@ -104,7 +104,11 @@ typedef u64 iomux_v3_cfg_t;
 #define PAD_CTL_ODE(0x1 << 5)
 #define PAD_CTL_PUE(0x1 << 6)
 #define PAD_CTL_HYS(0x1 << 7)
+#ifdef CONFIG_IMX8MM
+#define PAD_CTL_PE (0x1 << 8)
+#else
 #define PAD_CTL_LVTTL  (0x1 << 8)
+#endif
 
 #elif defined CONFIG_MX7
 
-- 
2.16.4

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

[U-Boot] [i.MX8MM+CCF 35/41] serial: Kconfig: make MXC_UART usable for MX7 and IMX8M

i.MX7 and i.MX8M use mxc uart driver, so let's make the SoC could
use MXC_UART kconfig.

Signed-off-by: Peng Fan 
---
 drivers/serial/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
index fcbb0a81ed..a37b2d60f2 100644
--- a/drivers/serial/Kconfig
+++ b/drivers/serial/Kconfig
@@ -561,7 +561,7 @@ config MVEBU_A3700_UART
 
 config MXC_UART
bool "IMX serial port support"
-   depends on MX5 || MX6
+   depends on MX5 || MX6 || MX7 || IMX8M
help
  If you have a machine based on a Motorola IMX CPU you
  can enable its onboard serial port by enabling this option.
-- 
2.16.4

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

[U-Boot] [i.MX8MM+CCF 25/41] imx8m: rename clock to clock_imx8mq

i.MX8MQ and i.MX8MM has totally different pll design, so
rename clock to clock_imx8mq.

Signed-off-by: Peng Fan 
---
 arch/arm/mach-imx/imx8m/Makefile| 3 ++-
 arch/arm/mach-imx/imx8m/{clock.c => clock_imx8mq.c} | 0
 2 files changed, 2 insertions(+), 1 deletion(-)
 rename arch/arm/mach-imx/imx8m/{clock.c => clock_imx8mq.c} (100%)

diff --git a/arch/arm/mach-imx/imx8m/Makefile b/arch/arm/mach-imx/imx8m/Makefile
index feff4941c1..42a1544c6b 100644
--- a/arch/arm/mach-imx/imx8m/Makefile
+++ b/arch/arm/mach-imx/imx8m/Makefile
@@ -3,4 +3,5 @@
 # Copyright 2017 NXP
 
 obj-y += lowlevel_init.o
-obj-y += clock.o clock_slice.o soc.o
+obj-y += clock_slice.o soc.o
+obj-$(CONFIG_IMX8MQ) += clock_imx8mq.o
diff --git a/arch/arm/mach-imx/imx8m/clock.c 
b/arch/arm/mach-imx/imx8m/clock_imx8mq.c
similarity index 100%
rename from arch/arm/mach-imx/imx8m/clock.c
rename to arch/arm/mach-imx/imx8m/clock_imx8mq.c
-- 
2.16.4

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

[U-Boot] [PATCH V2 1/2] usb: ohci: ohci-da8xx: Enable da850-ohci driver with DM support

This patch reuses some former code for the hawkboard, combines it
with some some similar DM_USB compatible code for the OHCI driver,
and enables the use of the da850's OHCI controller with DM_USB
compatibility.

Signed-off-by: Adam Ford 
---
V2:  Replace timeout with get_timer and read/modify/write registers with
 clrsetbits_le32 instead of doing it manually.

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 0fbc115801..0d8ab3b651 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -239,6 +239,11 @@ config USB_OHCI_GENERIC
---help---
  Enables support for generic OHCI controller.
 
+config USB_OHCI_DA8XX
+   bool "Support for da850 OHCI USB controller"
+   help
+ Enable support for the da850 USB controller.
+
 endif # USB_OHCI_HCD
 
 config USB_UHCI_HCD
diff --git a/drivers/usb/host/ohci-da8xx.c b/drivers/usb/host/ohci-da8xx.c
index 47ad3f34d5..e8a495fde5 100644
--- a/drivers/usb/host/ohci-da8xx.c
+++ b/drivers/usb/host/ohci-da8xx.c
@@ -4,9 +4,54 @@
  */
 
 #include 
-
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "ohci.h"
 #include 
 
+struct da8xx_ohci {
+   ohci_t ohci;
+   struct clk *clocks; /* clock list */
+   struct phy phy;
+   int clock_count;/* number of clock in clock list */
+};
+
+static int usb_phy_on(void)
+{
+   unsigned long timeout;
+
+   clrsetbits_le32(_syscfg_regs->cfgchip2,
+   (CFGCHIP2_RESET | CFGCHIP2_PHYPWRDN |
+   CFGCHIP2_OTGPWRDN | CFGCHIP2_OTGMODE |
+   CFGCHIP2_REFFREQ | CFGCHIP2_USB1PHYCLKMUX),
+   (CFGCHIP2_SESENDEN | CFGCHIP2_VBDTCTEN |
+   CFGCHIP2_PHY_PLLON | CFGCHIP2_REFFREQ_24MHZ |
+   CFGCHIP2_USB2PHYCLKMUX | CFGCHIP2_USB1SUSPENDM));
+
+   /* wait until the usb phy pll locks */
+   timeout = get_timer(0);
+   while (get_timer(timeout) < 10) {
+   if (readl(_syscfg_regs->cfgchip2) & CFGCHIP2_PHYCLKGD)
+   return 1;
+   }
+
+   /* USB phy was not turned on */
+   return 0;
+}
+
+static void usb_phy_off(void)
+{
+   /* Power down the on-chip PHY. */
+   clrsetbits_le32(_syscfg_regs->cfgchip2,
+   CFGCHIP2_PHY_PLLON | CFGCHIP2_USB1SUSPENDM,
+   CFGCHIP2_PHYPWRDN | CFGCHIP2_OTGPWRDN |
+   CFGCHIP2_RESET);
+}
+
 int usb_cpu_init(void)
 {
/* enable psc for usb2.0 */
@@ -37,3 +82,94 @@ int usb_cpu_init_fail(void)
 {
return usb_cpu_stop();
 }
+
+#if CONFIG_IS_ENABLED(DM_USB)
+static int ohci_da8xx_probe(struct udevice *dev)
+{
+   struct ohci_regs *regs = (struct ohci_regs *)devfdt_get_addr(dev);
+   struct da8xx_ohci *priv = dev_get_priv(dev);
+   int i, err, ret, clock_nb;
+
+   err = 0;
+   priv->clock_count = 0;
+   clock_nb = dev_count_phandle_with_args(dev, "clocks", "#clock-cells");
+   if (clock_nb > 0) {
+   priv->clocks = devm_kcalloc(dev, clock_nb, sizeof(struct clk),
+   GFP_KERNEL);
+   if (!priv->clocks)
+   return -ENOMEM;
+
+   for (i = 0; i < clock_nb; i++) {
+   err = clk_get_by_index(dev, i, >clocks[i]);
+   if (err < 0)
+   break;
+
+   err = clk_enable(>clocks[i]);
+   if (err) {
+   dev_err(dev, "failed to enable clock %d\n", i);
+   clk_free(>clocks[i]);
+   goto clk_err;
+   }
+   priv->clock_count++;
+   }
+   } else if (clock_nb != -ENOENT) {
+   dev_err(dev, "failed to get clock phandle(%d)\n", clock_nb);
+   return clock_nb;
+   }
+
+   err = usb_cpu_init();
+
+   if (err)
+   goto clk_err;
+
+   err = ohci_register(dev, regs);
+   if (err)
+   goto phy_err;
+
+   return 0;
+
+phy_err:
+   ret = usb_cpu_stop();
+   if (ret)
+   dev_err(dev, "failed to shutdown usb phy\n");
+
+clk_err:
+   ret = clk_release_all(priv->clocks, priv->clock_count);
+   if (ret)
+   dev_err(dev, "failed to disable all clocks\n");
+
+   return err;
+}
+
+static int ohci_da8xx_remove(struct udevice *dev)
+{
+   struct da8xx_ohci *priv = dev_get_priv(dev);
+   int ret;
+
+   ret = ohci_deregister(dev);
+   if (ret)
+   return ret;
+
+   ret = usb_cpu_stop();
+   if (ret)
+   return ret;
+
+   return clk_release_all(priv->clocks, priv->clock_count);
+}
+
+static const struct udevice_id da8xx_ohci_ids[] = {
+   { .compatible = "ti,da830-ohci" },
+   { }
+};
+
+U_BOOT_DRIVER(ohci_generic) = {
+   .name   = "ohci-da8xx",
+   .id =

[U-Boot] [i.MX8MM+CCF 18/41] imx: add IMX8MQ kconfig entry

Add IMX8MQ kconfig entry, preparing support IMX8MM

Signed-off-by: Peng Fan 
---
 arch/arm/mach-imx/imx8m/Kconfig | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-imx/imx8m/Kconfig b/arch/arm/mach-imx/imx8m/Kconfig
index 317dee9bc1..9c487870a6 100644
--- a/arch/arm/mach-imx/imx8m/Kconfig
+++ b/arch/arm/mach-imx/imx8m/Kconfig
@@ -4,6 +4,10 @@ config IMX8M
bool
select ROM_UNIFIED_SECTIONS
 
+config IMX8MQ
+   bool
+   select IMX8M
+
 config SYS_SOC
default "imx8m"
 
@@ -13,7 +17,7 @@ choice
 
 config TARGET_IMX8MQ_EVK
bool "imx8mq_evk"
-   select IMX8M
+   select IMX8MQ
select IMX8M_LPDDR4
 
 endchoice
-- 
2.16.4

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

[U-Boot] [i.MX8MM+CCF 26/41] imx8m: restructure clock.h

i.MX8MQ and i.MX8MM use different analog pll design, but they
share same ccm design.
Add clock_imx8mq.h for i.MX8MQ
keep common part in clock.h

Signed-off-by: Peng Fan 
---
 arch/arm/include/asm/arch-imx8m/clock.h| 491 +++--
 arch/arm/include/asm/arch-imx8m/clock_imx8mq.h | 424 +
 arch/arm/mach-imx/imx8m/clock_imx8mq.c |   5 +-
 3 files changed, 467 insertions(+), 453 deletions(-)
 create mode 100644 arch/arm/include/asm/arch-imx8m/clock_imx8mq.h

diff --git a/arch/arm/include/asm/arch-imx8m/clock.h 
b/arch/arm/include/asm/arch-imx8m/clock.h
index e7c1670f6b..7225c760fe 100644
--- a/arch/arm/include/asm/arch-imx8m/clock.h
+++ b/arch/arm/include/asm/arch-imx8m/clock.h
@@ -1,28 +1,29 @@
 /* SPDX-License-Identifier: GPL-2.0+ */
 /*
- * Copyright 2017 NXP
- *
- * Peng Fan 
+ * Copyright 2017-2019 NXP
  */
 
-#ifndef _ASM_ARCH_IMX8M_CLOCK_H
-#define _ASM_ARCH_IMX8M_CLOCK_H
-
 #include 
 
+#ifdef CONFIG_IMX8MQ
+#include 
+#else
+#error "Error no clock.h"
+#endif
+
 #define MHZ(X) ((X) * 100UL)
 
-enum pll_clocks {
-   ANATOP_ARM_PLL,
-   ANATOP_GPU_PLL,
-   ANATOP_SYSTEM_PLL1,
-   ANATOP_SYSTEM_PLL2,
-   ANATOP_SYSTEM_PLL3,
-   ANATOP_AUDIO_PLL1,
-   ANATOP_AUDIO_PLL2,
-   ANATOP_VIDEO_PLL1,
-   ANATOP_VIDEO_PLL2,
-   ANATOP_DRAM_PLL,
+/* Mainly for compatible to imx common code. */
+enum mxc_clock {
+   MXC_ARM_CLK = 0,
+   MXC_IPG_CLK,
+   MXC_CSPI_CLK,
+   MXC_ESDHC_CLK,
+   MXC_ESDHC2_CLK,
+   MXC_ESDHC3_CLK,
+   MXC_I2C_CLK,
+   MXC_UART_CLK,
+   MXC_QSPI_CLK,
 };
 
 enum clk_slice_type {
@@ -35,297 +36,6 @@ enum clk_slice_type {
DRAM_SEL_CLOCK_SLICE,
 };
 
-enum clk_root_index {
-   MXC_ARM_CLK = 0,
-   ARM_A53_CLK_ROOT= 0,
-   ARM_M4_CLK_ROOT = 1,
-   VPU_A53_CLK_ROOT= 2,
-   GPU_CORE_CLK_ROOT   = 3,
-   GPU_SHADER_CLK_ROOT = 4,
-   MAIN_AXI_CLK_ROOT   = 16,
-   ENET_AXI_CLK_ROOT   = 17,
-   NAND_USDHC_BUS_CLK_ROOT = 18,
-   VPU_BUS_CLK_ROOT= 19,
-   DISPLAY_AXI_CLK_ROOT= 20,
-   DISPLAY_APB_CLK_ROOT= 21,
-   DISPLAY_RTRM_CLK_ROOT   = 22,
-   USB_BUS_CLK_ROOT= 23,
-   GPU_AXI_CLK_ROOT= 24,
-   GPU_AHB_CLK_ROOT= 25,
-   NOC_CLK_ROOT= 26,
-   NOC_APB_CLK_ROOT= 27,
-   AHB_CLK_ROOT= 32,
-   IPG_CLK_ROOT= 33,
-   MXC_IPG_CLK = 33,
-   AUDIO_AHB_CLK_ROOT  = 34,
-   MIPI_DSI_ESC_RX_CLK_ROOT= 36,
-   DRAM_SEL_CFG= 48,
-   CORE_SEL_CFG= 49,
-   DRAM_ALT_CLK_ROOT   = 64,
-   DRAM_APB_CLK_ROOT   = 65,
-   VPU_G1_CLK_ROOT = 66,
-   VPU_G2_CLK_ROOT = 67,
-   DISPLAY_DTRC_CLK_ROOT   = 68,
-   DISPLAY_DC8000_CLK_ROOT = 69,
-   PCIE1_CTRL_CLK_ROOT = 70,
-   PCIE1_PHY_CLK_ROOT  = 71,
-   PCIE1_AUX_CLK_ROOT  = 72,
-   DC_PIXEL_CLK_ROOT   = 73,
-   LCDIF_PIXEL_CLK_ROOT= 74,
-   SAI1_CLK_ROOT   = 75,
-   SAI2_CLK_ROOT   = 76,
-   SAI3_CLK_ROOT   = 77,
-   SAI4_CLK_ROOT   = 78,
-   SAI5_CLK_ROOT   = 79,
-   SAI6_CLK_ROOT   = 80,
-   SPDIF1_CLK_ROOT = 81,
-   SPDIF2_CLK_ROOT = 82,
-   ENET_REF_CLK_ROOT   = 83,
-   ENET_TIMER_CLK_ROOT = 84,
-   ENET_PHY_REF_CLK_ROOT   = 85,
-   NAND_CLK_ROOT   = 86,
-   QSPI_CLK_ROOT   = 87,
-   MXC_ESDHC_CLK   = 88,
-   USDHC1_CLK_ROOT = 88,
-   MXC_ESDHC2_CLK  = 89,
-   USDHC2_CLK_ROOT = 89,
-   I2C1_CLK_ROOT   = 90,
-   MXC_I2C_CLK = 90,
-   I2C2_CLK_ROOT   = 91,
-   I2C3_CLK_ROOT   = 92,
-   I2C4_CLK_ROOT   = 93,
-   UART1_CLK_ROOT  = 94,
-   UART2_CLK_ROOT  = 95,
-   UART3_CLK_ROOT  = 96,
-   UART4_CLK_ROOT  = 97,
-   USB_CORE_REF_CLK_ROOT   = 98,
-   USB_PHY_REF_CLK_ROOT= 99,
-   GIC_CLK_ROOT= 100,
-   ECSPI1_CLK_ROOT = 101,
-   ECSPI2_CLK_ROOT = 102,
-   PWM1_CLK_ROOT   = 103,
-   PWM2_CLK_ROOT   = 104,
-   PWM3_CLK_ROOT   = 105,
-   PWM4_CLK_ROOT

[U-Boot] [i.MX8MM+CCF 31/41] imx8m: Fix MMU table issue for OPTEE memory

When running with OPTEE, the MMU table in u-boot does not remove the OPTEE
memory from its settings. So ARM speculative prefetch in u-boot may access
that OPTEE memory. Due to trust zone is enabled by OPTEE and that memory
is set to secure access, then the speculative prefetch will fail and cause
various memory issue in u-boot.
The fail address register and int_status register in trustzone has logged
that speculative access from u-boot.

Signed-off-by: Peng Fan 
---
 arch/arm/mach-imx/imx8m/soc.c | 20 ++--
 1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-imx/imx8m/soc.c b/arch/arm/mach-imx/imx8m/soc.c
index 07cda86bdd..5e9481c565 100644
--- a/arch/arm/mach-imx/imx8m/soc.c
+++ b/arch/arm/mach-imx/imx8m/soc.c
@@ -116,16 +116,18 @@ static struct mm_region imx8m_mem_map[] = {
/* DRAM1 */
.virt = 0x4000UL,
.phys = 0x4000UL,
-   .size = 0xC000UL,
+   .size = PHYS_SDRAM_SIZE,
.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
 PTE_BLOCK_OUTER_SHARE
+#ifdef PHYS_SDRAM_2_SIZE
}, {
/* DRAM2 */
.virt = 0x1UL,
.phys = 0x1UL,
-   .size = 0x04000UL,
+   .size = PHYS_SDRAM_2_SIZE,
.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
 PTE_BLOCK_OUTER_SHARE
+#endif
}, {
/* List terminator */
0,
@@ -134,6 +136,20 @@ static struct mm_region imx8m_mem_map[] = {
 
 struct mm_region *mem_map = imx8m_mem_map;
 
+void enable_caches(void)
+{
+   /*
+* If OPTEE runs, remove OPTEE memory from MMU table to
+* avoid speculative prefetch. OPTEE runs at the top of
+* the first memory bank
+*/
+   if (rom_pointer[1])
+   imx8m_mem_map[5].size -= rom_pointer[1];
+
+   icache_enable();
+   dcache_enable();
+}
+
 static u32 get_cpu_variant_type(u32 type)
 {
struct ocotp_regs *ocotp = (struct ocotp_regs *)OCOTP_BASE_ADDR;
-- 
2.16.4

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

[U-Boot] [i.MX8MM+CCF 21/41] imx: add i.MX8MM cpu type

Add i.MX8MM cpu type and related helper functions

Signed-off-by: Peng Fan 
---
 arch/arm/include/asm/arch-imx/cpu.h   |  6 ++
 arch/arm/include/asm/mach-imx/sys_proto.h |  8 
 arch/arm/mach-imx/cpu.c   | 12 
 3 files changed, 26 insertions(+)

diff --git a/arch/arm/include/asm/arch-imx/cpu.h 
b/arch/arm/include/asm/arch-imx/cpu.h
index 667badbc06..fab530e324 100644
--- a/arch/arm/include/asm/arch-imx/cpu.h
+++ b/arch/arm/include/asm/arch-imx/cpu.h
@@ -25,6 +25,12 @@
 #define MXC_CPU_MX7S   0x71 /* dummy ID */
 #define MXC_CPU_MX7D   0x72
 #define MXC_CPU_IMX8MQ 0x82
+#define MXC_CPU_IMX8MM 0x85 /* dummy ID */
+#define MXC_CPU_IMX8MML0x86 /* dummy ID */
+#define MXC_CPU_IMX8MMD0x87 /* dummy ID */
+#define MXC_CPU_IMX8MMDL   0x88 /* dummy ID */
+#define MXC_CPU_IMX8MMS0x89 /* dummy ID */
+#define MXC_CPU_IMX8MMSL   0x8a /* dummy ID */
 #define MXC_CPU_IMX8QXP_A0 0x90 /* dummy ID */
 #define MXC_CPU_IMX8QXP0x92 /* dummy ID */
 #define MXC_CPU_MX7ULP 0xE1 /* Temporally hard code */
diff --git a/arch/arm/include/asm/mach-imx/sys_proto.h 
b/arch/arm/include/asm/mach-imx/sys_proto.h
index d0f866b630..88927aeb6b 100644
--- a/arch/arm/include/asm/mach-imx/sys_proto.h
+++ b/arch/arm/include/asm/mach-imx/sys_proto.h
@@ -43,6 +43,14 @@
 #define is_mx7ulp() (is_cpu_type(MXC_CPU_MX7ULP))
 
 #define is_imx8mq() (is_cpu_type(MXC_CPU_IMX8MQ))
+#define is_imx8mm() (is_cpu_type(MXC_CPU_IMX8MM) || 
is_cpu_type(MXC_CPU_IMX8MML) ||\
+   is_cpu_type(MXC_CPU_IMX8MMD) || is_cpu_type(MXC_CPU_IMX8MMDL) || \
+   is_cpu_type(MXC_CPU_IMX8MMS) || is_cpu_type(MXC_CPU_IMX8MMSL))
+#define is_imx8mml() (is_cpu_type(MXC_CPU_IMX8MML))
+#define is_imx8mmd() (is_cpu_type(MXC_CPU_IMX8MMD))
+#define is_imx8mmdl() (is_cpu_type(MXC_CPU_IMX8MMDL))
+#define is_imx8mms() (is_cpu_type(MXC_CPU_IMX8MMS))
+#define is_imx8mmsl() (is_cpu_type(MXC_CPU_IMX8MMSL))
 #define is_imx8qxp() (is_cpu_type(MXC_CPU_IMX8QXP))
 
 #ifdef CONFIG_MX6
diff --git a/arch/arm/mach-imx/cpu.c b/arch/arm/mach-imx/cpu.c
index 6b83f92662..14370929de 100644
--- a/arch/arm/mach-imx/cpu.c
+++ b/arch/arm/mach-imx/cpu.c
@@ -145,6 +145,18 @@ unsigned imx_ddr_size(void)
 const char *get_imx_type(u32 imxtype)
 {
switch (imxtype) {
+   case MXC_CPU_IMX8MM:
+   return "8MMQ";  /* Quad-core version of the imx8mm */
+   case MXC_CPU_IMX8MML:
+   return "8MMQL"; /* Quad-core Lite version of the imx8mm */
+   case MXC_CPU_IMX8MMD:
+   return "8MMD";  /* Dual-core version of the imx8mm */
+   case MXC_CPU_IMX8MMDL:
+   return "8MMDL"; /* Dual-core Lite version of the imx8mm */
+   case MXC_CPU_IMX8MMS:
+   return "8MMS";  /* Single-core version of the imx8mm */
+   case MXC_CPU_IMX8MMSL:
+   return "8MMSL"; /* Single-core Lite version of the imx8mm */
case MXC_CPU_IMX8MQ:
return "8MQ";   /* Quad-core version of the imx8m */
case MXC_CPU_MX7S:
-- 
2.16.4

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

[U-Boot] [i.MX8MM+CCF 40/41] clk: imx: add i.MX8MM clk driver

Add i.MX8MM clk driver support.

Signed-off-by: Peng Fan 
---
 drivers/clk/imx/Makefile |   1 +
 drivers/clk/imx/clk-imx8mm.c | 415 +++
 2 files changed, 416 insertions(+)
 create mode 100644 drivers/clk/imx/clk-imx8mm.c

diff --git a/drivers/clk/imx/Makefile b/drivers/clk/imx/Makefile
index beba3bff39..e8cac4127a 100644
--- a/drivers/clk/imx/Makefile
+++ b/drivers/clk/imx/Makefile
@@ -5,3 +5,4 @@
 obj-$(CONFIG_$(SPL_TPL_)CLK_CCF) += clk-gate2.o clk-pllv3.o clk-pfd.o
 obj-$(CONFIG_CLK_IMX6Q) += clk-imx6q.o
 obj-$(CONFIG_CLK_IMX8) += clk-imx8.o
+obj-$(CONFIG_CLK_IMX8MM) += clk-imx8mm.o clk-pll14xx.o clk-composite-8m.o
diff --git a/drivers/clk/imx/clk-imx8mm.c b/drivers/clk/imx/clk-imx8mm.c
new file mode 100644
index 00..329fd8ed06
--- /dev/null
+++ b/drivers/clk/imx/clk-imx8mm.c
@@ -0,0 +1,415 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2019 NXP
+ * Peng Fan 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "clk.h"
+
+#define PLL_1416X_RATE(_rate, _m, _p, _s)  \
+   {   \
+   .rate   =   (_rate),\
+   .mdiv   =   (_m),   \
+   .pdiv   =   (_p),   \
+   .sdiv   =   (_s),   \
+   }
+
+#define PLL_1443X_RATE(_rate, _m, _p, _s, _k)  \
+   {   \
+   .rate   =   (_rate),\
+   .mdiv   =   (_m),   \
+   .pdiv   =   (_p),   \
+   .sdiv   =   (_s),   \
+   .kdiv   =   (_k),   \
+   }
+
+static const struct imx_pll14xx_rate_table imx8mm_pll1416x_tbl[] = {
+   PLL_1416X_RATE(18U, 225, 3, 0),
+   PLL_1416X_RATE(16U, 200, 3, 0),
+   PLL_1416X_RATE(12U, 300, 3, 1),
+   PLL_1416X_RATE(10U, 250, 3, 1),
+   PLL_1416X_RATE(8U,  200, 3, 1),
+   PLL_1416X_RATE(75000U,  250, 2, 2),
+   PLL_1416X_RATE(7U,  350, 3, 2),
+   PLL_1416X_RATE(6U,  300, 3, 2),
+};
+
+static const struct imx_pll14xx_rate_table imx8mm_drampll_tbl[] = {
+   PLL_1443X_RATE(65000U, 325, 3, 2, 0),
+};
+
+static struct imx_pll14xx_clk imx8mm_dram_pll __initdata = {
+   .type = PLL_1443X,
+   .rate_table = imx8mm_drampll_tbl,
+   .rate_count = ARRAY_SIZE(imx8mm_drampll_tbl),
+};
+
+static struct imx_pll14xx_clk imx8mm_arm_pll __initdata = {
+   .type = PLL_1416X,
+   .rate_table = imx8mm_pll1416x_tbl,
+   .rate_count = ARRAY_SIZE(imx8mm_pll1416x_tbl),
+};
+
+static struct imx_pll14xx_clk imx8mm_sys_pll __initdata = {
+   .type = PLL_1416X,
+   .rate_table = imx8mm_pll1416x_tbl,
+   .rate_count = ARRAY_SIZE(imx8mm_pll1416x_tbl),
+};
+
+static const char *pll_ref_sels[] = { "clock-osc-24m", "dummy", "dummy", 
"dummy", };
+static const char *dram_pll_bypass_sels[] = {"dram_pll", "dram_pll_ref_sel", };
+static const char *arm_pll_bypass_sels[] = {"arm_pll", "arm_pll_ref_sel", };
+static const char *sys_pll1_bypass_sels[] = {"sys_pll1", "sys_pll1_ref_sel", };
+static const char *sys_pll2_bypass_sels[] = {"sys_pll2", "sys_pll2_ref_sel", };
+static const char *sys_pll3_bypass_sels[] = {"sys_pll3", "sys_pll3_ref_sel", };
+
+static const char *imx8mm_a53_sels[] = {"clock-osc-24m", "arm_pll_out", 
"sys_pll2_500m", "sys_pll2_1000m",
+   "sys_pll1_800m", "sys_pll1_400m", 
"audio_pll1_out", "sys_pll3_out", };
+
+static const char *imx8mm_ahb_sels[] = {"osc_24m", "sys_pll1_133m", 
"sys_pll1_800m", "sys_pll1_400m",
+   "sys_pll2_125m", "sys_pll3_out", 
"audio_pll1_out", "video_pll1_out", };
+
+static const char *imx8mm_enet_axi_sels[] = {"clock-osc-24m", "sys_pll1_266m", 
"sys_pll1_800m", "sys_pll2_250m",
+"sys_pll2_200m", "audio_pll1_out", 
"video_pll1_out", "sys_pll3_out", };
+
+static const char *imx8mm_nand_usdhc_sels[] = {"clock-osc-24m", 
"sys_pll1_266m", "sys_pll1_800m", "sys_pll2_200m",
+  "sys_pll1_133m", "sys_pll3_out", 
"sys_pll2_250m", "audio_pll1_out", };
+
+static const char *imx8mm_usdhc1_sels[] = {"clock-osc-24m", "sys_pll1_400m", 
"sys_pll1_800m", "sys_pll2_500m",
+  "sys_pll3_out", "sys_pll1_266m", 
"audio_pll2_out", "sys_pll1_100m", };
+
+static const char *imx8mm_usdhc2_sels[] = {"clock-osc-24m", "sys_pll1_400m", 
"sys_pll1_800m", "sys_pll2_500m",
+  "sys_pll3_out", "sys_pll1_266m", 
"audio_pll2_out", "sys_pll1_100m", };
+
+static const char *imx8mm_i2c1_sels[] = {"clock-osc-24m", "sys_pll1_160m",

[U-Boot] [i.MX8MM+CCF 34/41] imx8m: soc: enable SCTR clock before timer init

To i.MX8MM SCTR clock is disabled by ROM, so before timer init
need to enable it.
To i.MX8MQ, it does not hurt the clock is enabled again.

Signed-off-by: Peng Fan 
---
 arch/arm/mach-imx/imx8m/soc.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/mach-imx/imx8m/soc.c b/arch/arm/mach-imx/imx8m/soc.c
index abf526bc68..ea83a495c2 100644
--- a/arch/arm/mach-imx/imx8m/soc.c
+++ b/arch/arm/mach-imx/imx8m/soc.c
@@ -234,6 +234,12 @@ static void imx_set_wdog_powerdown(bool enable)
 
 int arch_cpu_init(void)
 {
+   /*
+* ROM might disable clock for SCTR,
+* enable the clock before timer_init.
+*/
+   if (IS_ENABLED(CONFIG_SPL_BUILD))
+   clock_enable(CCGR_SCTR, 1);
/*
 * Init timer at very early state, because sscg pll setting
 * will use it
-- 
2.16.4

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

[U-Boot] [i.MX8MM+CCF 23/41] imx8m: update imx-regs for i.MX8MM

i.MX8MM has similar architecture with i.MX8MQ, but it has totally
different PLL design and some register layout change.

Note: Some registers in this file are not updated because not used now.

Signed-off-by: Peng Fan 
---
 arch/arm/include/asm/arch-imx8m/imx-regs.h | 75 --
 1 file changed, 71 insertions(+), 4 deletions(-)

diff --git a/arch/arm/include/asm/arch-imx8m/imx-regs.h 
b/arch/arm/include/asm/arch-imx8m/imx-regs.h
index 3facd5450c..44b2f728ee 100644
--- a/arch/arm/include/asm/arch-imx8m/imx-regs.h
+++ b/arch/arm/include/asm/arch-imx8m/imx-regs.h
@@ -8,8 +8,8 @@
 
 #include 
 
-#define ROM_VERSION_A0 0x800
-#define ROM_VERSION_B0 0x83C
+#define ROM_VERSION_A0 IS_ENABLED(CONFIG_IMX8MQ) ? 0x800 : 0x800
+#define ROM_VERSION_B0 IS_ENABLED(CONFIG_IMX8MQ) ? 0x83C : 0x800
 
 #define M4_BOOTROM_BASE_ADDR   0x007E
 
@@ -91,7 +91,11 @@
 #define SEMAPHOR_HS_BASE_ADDR  0x30AC
 #define USDHC1_BASE_ADDR   0x30B4
 #define USDHC2_BASE_ADDR   0x30B5
+#ifdef CONFIG_IMX8MM
+#define USDHC3_BASE_ADDR   0x30B6
+#else
 #define MIPI_CS2_BASE_ADDR 0x30B6
+#endif
 #define MIPI_CSI_PHY2_BASE_ADDR0x30B7
 #define CSI2_BASE_ADDR 0x30B8
 #define QSPI0_BASE_ADDR0x30BB
@@ -118,7 +122,8 @@
 #define USB1_PHY_BASE_ADDR 0x381F
 #define USB2_PHY_BASE_ADDR 0x382F
 
-#define MXS_LCDIF_BASE LCDIF_BASE_ADDR
+#define MXS_LCDIF_BASE is_enable(CONFIG_IMX8MQ) ? \
+   0x3032 : 0x32e0
 
 #define SRC_IPS_BASE_ADDR  0x3039
 #define SRC_DDRC_RCR_ADDR  0x30391000
@@ -147,6 +152,9 @@
 #define SRC_DDR1_RCR_CORE_RESET_N_MASK BIT(1)
 #define SRC_DDR1_RCR_PRESET_N_MASK BIT(0)
 
+#define IOMUXC_GPR_GPR1_GPR_ENET1_TX_CLK_SEL_MASK 0x2000u
+#define IOMUXC_GPR_GPR1_GPR_ENET1_TX_CLK_SEL_SHIFT 13
+
 struct iomuxc_gpr_base_regs {
u32 gpr[47];
 };
@@ -203,6 +211,7 @@ struct fuse_bank1_regs {
u32 rsvd3[3];
 };
 
+#ifdef CONFIG_IMX8MQ
 struct anamix_pll {
u32 audio_pll1_cfg0;
u32 audio_pll1_cfg1;
@@ -237,6 +246,60 @@ struct anamix_pll {
u32 frac_pllout_div_cfg;
u32 sscg_pllout_div_cfg;
 };
+#else
+struct anamix_pll {
+   u32 audio_pll1_gnrl_ctl;
+   u32 audio_pll1_fdiv_ctl0;
+   u32 audio_pll1_fdiv_ctl1;
+   u32 audio_pll1_sscg_ctl;
+   u32 audio_pll1_mnit_ctl;
+   u32 audio_pll2_gnrl_ctl;
+   u32 audio_pll2_fdiv_ctl0;
+   u32 audio_pll2_fdiv_ctl1;
+   u32 audio_pll2_sscg_ctl;
+   u32 audio_pll2_mnit_ctl;
+   u32 video_pll1_gnrl_ctl;
+   u32 video_pll1_fdiv_ctl0;
+   u32 video_pll1_fdiv_ctl1;
+   u32 video_pll1_sscg_ctl;
+   u32 video_pll1_mnit_ctl;
+   u32 reserved[5];
+   u32 dram_pll_gnrl_ctl;
+   u32 dram_pll_fdiv_ctl0;
+   u32 dram_pll_fdiv_ctl1;
+   u32 dram_pll_sscg_ctl;
+   u32 dram_pll_mnit_ctl;
+   u32 gpu_pll_gnrl_ctl;
+   u32 gpu_pll_div_ctl;
+   u32 gpu_pll_locked_ctl1;
+   u32 gpu_pll_mnit_ctl;
+   u32 vpu_pll_gnrl_ctl;
+   u32 vpu_pll_div_ctl;
+   u32 vpu_pll_locked_ctl1;
+   u32 vpu_pll_mnit_ctl;
+   u32 arm_pll_gnrl_ctl;
+   u32 arm_pll_div_ctl;
+   u32 arm_pll_locked_ctl1;
+   u32 arm_pll_mnit_ctl;
+   u32 sys_pll1_gnrl_ctl;
+   u32 sys_pll1_div_ctl;
+   u32 sys_pll1_locked_ctl1;
+   u32 reserved2[24];
+   u32 sys_pll1_mnit_ctl;
+   u32 sys_pll2_gnrl_ctl;
+   u32 sys_pll2_div_ctl;
+   u32 sys_pll2_locked_ctl1;
+   u32 sys_pll2_mnit_ctl;
+   u32 sys_pll3_gnrl_ctl;
+   u32 sys_pll3_div_ctl;
+   u32 sys_pll3_locked_ctl1;
+   u32 sys_pll3_mnit_ctl;
+   u32 anamix_misc_ctl;
+   u32 anamix_clk_mnit_ctl;
+   u32 reserved3[437];
+   u32 digprog;
+};
+#endif
 
 struct fuse_bank9_regs {
u32 mac_addr0;
@@ -256,11 +319,13 @@ struct src {
u32 usbophy2_rcr;
u32 mipiphy_rcr;
u32 pciephy_rcr;
+   /* Exits on i.MX8MQ */
u32 hdmi_rcr;
u32 disp_rcr;
u32 reserved2[2];
u32 gpu_rcr;
u32 vpu_rcr;
+   /* The following four exits on i.MX8MQ */
u32 pcie2_rcr;
u32 mipiphy1_rcr;
u32 mipiphy2_rcr;
@@ -283,6 +348,7 @@ struct src {
u32 gpr10;
u32 reserved5[985];
u32 ddr1_rcr;
+   /* Exist on i.MX8MQ */
u32 ddr2_rcr;
 };
 
@@ -457,7 +523,8 @@ struct bootrom_sw_info {
u32 reserved_3[3];
 };
 
-#define ROM_SW_INFO_ADDR_B00x0968
+#define ROM_SW_INFO_ADDR_B0(IS_ENABLED(CONFIG_IMX8MQ) ? 0x0968 :\
+0x09e8)
 #define ROM_SW_INFO_ADDR_A00x09e8
 
 #define ROM_SW_INFO_ADDR is_soc_rev(CHIP_REV_1_0) ? \
-- 
2.16.4

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

[U-Boot] [i.MX8MM+CCF 27/41] imx8m: add clk support for i.MX8MM

Introduce clk implementation for i.MX8MM, including pll configuration,
ccm configuration. Mostly will be done clk dm driver,
but such as DRAM part, we still use non clk dm driver, because we
have limited sram.

Signed-off-by: Peng Fan 
---
 arch/arm/include/asm/arch-imx8m/clock.h|   2 +
 arch/arm/include/asm/arch-imx8m/clock_imx8mm.h | 387 +
 arch/arm/mach-imx/imx8m/Makefile   |   1 +
 arch/arm/mach-imx/imx8m/clock_imx8mm.c | 292 
 arch/arm/mach-imx/imx8m/clock_slice.c  | 461 +
 5 files changed, 1143 insertions(+)
 create mode 100644 arch/arm/include/asm/arch-imx8m/clock_imx8mm.h
 create mode 100644 arch/arm/mach-imx/imx8m/clock_imx8mm.c

diff --git a/arch/arm/include/asm/arch-imx8m/clock.h 
b/arch/arm/include/asm/arch-imx8m/clock.h
index 7225c760fe..ead4b8d3dc 100644
--- a/arch/arm/include/asm/arch-imx8m/clock.h
+++ b/arch/arm/include/asm/arch-imx8m/clock.h
@@ -7,6 +7,8 @@
 
 #ifdef CONFIG_IMX8MQ
 #include 
+#elif defined(CONFIG_IMX8MM)
+#include 
 #else
 #error "Error no clock.h"
 #endif
diff --git a/arch/arm/include/asm/arch-imx8m/clock_imx8mm.h 
b/arch/arm/include/asm/arch-imx8m/clock_imx8mm.h
new file mode 100644
index 00..305514a4ec
--- /dev/null
+++ b/arch/arm/include/asm/arch-imx8m/clock_imx8mm.h
@@ -0,0 +1,387 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright 2018-2019 NXP
+ *
+ * Peng Fan 
+ */
+
+#ifndef _ASM_ARCH_IMX8MM_CLOCK_H
+#define _ASM_ARCH_IMX8MM_CLOCK_H
+
+#define PLL_1443X_RATE(_rate, _m, _p, _s, _k)  \
+   {   \
+   .rate   =   (_rate),\
+   .mdiv   =   (_m),   \
+   .pdiv   =   (_p),   \
+   .sdiv   =   (_s),   \
+   .kdiv   =   (_k),   \
+   }
+
+#define LOCK_STATUSBIT(31)
+#define LOCK_SEL_MASK  BIT(29)
+#define CLKE_MASK  BIT(11)
+#define RST_MASK   BIT(9)
+#define BYPASS_MASKBIT(4)
+#defineMDIV_SHIFT  12
+#defineMDIV_MASK   GENMASK(21, 12)
+#define PDIV_SHIFT 4
+#define PDIV_MASK  GENMASK(9, 4)
+#define SDIV_SHIFT 0
+#define SDIV_MASK  GENMASK(2, 0)
+#define KDIV_SHIFT 0
+#define KDIV_MASK  GENMASK(15, 0)
+
+struct imx_int_pll_rate_table {
+   u32 rate;
+   int mdiv;
+   int pdiv;
+   int sdiv;
+   int kdiv;
+};
+
+enum pll_clocks {
+   ANATOP_ARM_PLL,
+   ANATOP_VPU_PLL,
+   ANATOP_GPU_PLL,
+   ANATOP_SYSTEM_PLL1,
+   ANATOP_SYSTEM_PLL2,
+   ANATOP_SYSTEM_PLL3,
+   ANATOP_AUDIO_PLL1,
+   ANATOP_AUDIO_PLL2,
+   ANATOP_VIDEO_PLL,
+   ANATOP_DRAM_PLL,
+};
+
+enum clk_root_index {
+   ARM_A53_CLK_ROOT= 0,
+   ARM_M4_CLK_ROOT = 1,
+   VPU_A53_CLK_ROOT= 2,
+   GPU3D_CLK_ROOT  = 3,
+   GPU2D_CLK_ROOT  = 4,
+   MAIN_AXI_CLK_ROOT   = 16,
+   ENET_AXI_CLK_ROOT   = 17,
+   NAND_USDHC_BUS_CLK_ROOT = 18,
+   VPU_BUS_CLK_ROOT= 19,
+   DISPLAY_AXI_CLK_ROOT= 20,
+   DISPLAY_APB_CLK_ROOT= 21,
+   DISPLAY_RTRM_CLK_ROOT   = 22,
+   USB_BUS_CLK_ROOT= 23,
+   GPU_AXI_CLK_ROOT= 24,
+   GPU_AHB_CLK_ROOT= 25,
+   NOC_CLK_ROOT= 26,
+   NOC_APB_CLK_ROOT= 27,
+   AHB_CLK_ROOT= 32,
+   IPG_CLK_ROOT= 33,
+   AUDIO_AHB_CLK_ROOT  = 34,
+   MIPI_DSI_ESC_RX_CLK_ROOT= 36,
+   DRAM_SEL_CFG= 48,
+   CORE_SEL_CFG= 49,
+   DRAM_ALT_CLK_ROOT   = 64,
+   DRAM_APB_CLK_ROOT   = 65,
+   VPU_G1_CLK_ROOT = 66,
+   VPU_G2_CLK_ROOT = 67,
+   DISPLAY_DTRC_CLK_ROOT   = 68,
+   DISPLAY_DC8000_CLK_ROOT = 69,
+   PCIE_CTRL_CLK_ROOT  = 70,
+   PCIE_PHY_CLK_ROOT   = 71,
+   PCIE_AUX_CLK_ROOT   = 72,
+   DC_PIXEL_CLK_ROOT   = 73,
+   LCDIF_PIXEL_CLK_ROOT= 74,
+   SAI1_CLK_ROOT   = 75,
+   SAI2_CLK_ROOT   = 76,
+   SAI3_CLK_ROOT   = 77,
+   SAI4_CLK_ROOT   = 78,
+   SAI5_CLK_ROOT   = 79,
+   SAI6_CLK_ROOT   = 80,
+   SPDIF1_CLK_ROOT = 81,
+   SPDIF2_CLK_ROOT = 82,
+   ENET_REF_CLK_ROOT   = 83,
+   ENET_TIMER_CLK_ROOT = 84,
+   ENET_PHY_REF_CLK_ROOT   = 85,
+   NAND_CLK_ROOT   = 86,
+   QSPI_CLK_ROOT

[U-Boot] [i.MX8MM+CCF 32/41] imx8m: set BYPASS ID SWAP to avoid AXI bus errors

set the BYPASS ID SWAP bit (GPR10 bit 1) in order for GPU not to
generated AXI bus errors with TZC380 enabled.

Signed-off-by: Peng Fan 
---
 arch/arm/mach-imx/imx8m/soc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-imx/imx8m/soc.c b/arch/arm/mach-imx/imx8m/soc.c
index 5e9481c565..3918578399 100644
--- a/arch/arm/mach-imx/imx8m/soc.c
+++ b/arch/arm/mach-imx/imx8m/soc.c
@@ -59,6 +59,8 @@ void enable_tzc380(void)
/* Enable TZASC and lock setting */
setbits_le32(>gpr[10], GPR_TZASC_EN);
setbits_le32(>gpr[10], GPR_TZASC_EN_LOCK);
+   if (IS_ENABLED(CONFIG_IMX8MM))
+   setbits_le32(>gpr[10], BIT(1));
 }
 
 void set_wdog_reset(struct wdog_regs *wdog)
-- 
2.16.4

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

[U-Boot] [i.MX8MM+CCF 17/41] ddr: imx8m: fix ddr firmware location when enable SPL OF

With SPL_OF_SPERATE, the device tree will be padded to
end of the u-boot-spl-nodtb.bin, however we also put
the ddr firmware file to this location, so need to adapt
the code with SPL OF and align to 16bytes to ease copy firmware.

Signed-off-by: Peng Fan 
---
 drivers/ddr/imx/imx8m/helper.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/ddr/imx/imx8m/helper.c b/drivers/ddr/imx/imx8m/helper.c
index 61cd4f6db1..1bf580d306 100644
--- a/drivers/ddr/imx/imx8m/helper.c
+++ b/drivers/ddr/imx/imx8m/helper.c
@@ -31,7 +31,17 @@ void ddr_load_train_firmware(enum fw_type type)
unsigned long pr_to32, pr_from32;
unsigned long fw_offset = type ? IMEM_2D_OFFSET : 0;
unsigned long imem_start = (unsigned long)&_end + fw_offset;
-   unsigned long dmem_start = imem_start + IMEM_LEN;
+   unsigned long dmem_start;
+
+#ifdef CONFIG_SPL_OF_CONTROL
+   if (gd->fdt_blob && !fdt_check_header(gd->fdt_blob)) {
+   imem_start = roundup((unsigned long)&_end +
+fdt_totalsize(gd->fdt_blob), 16) +
+   fw_offset;
+   }
+#endif
+
+   dmem_start = imem_start + IMEM_LEN;
 
pr_from32 = imem_start;
pr_to32 = DDR_TRAIN_CODE_BASE_ADDR + 4 * IMEM_OFFSET_ADDR;
-- 
2.16.4

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

[U-Boot] [i.MX8MM+CCF 29/41] imx8m: add pin header for i.MX8MM

Add pin header file for i.MX8MM

To IMX8MM_PAD_NAND_WE_B_USDHC3_CLK, IOMUX_CONFIG_SION needs to be
selected.

Signed-off-by: Peng Fan 
---
 arch/arm/include/asm/arch-imx8m/imx8mm_pins.h | 691 ++
 1 file changed, 691 insertions(+)
 create mode 100644 arch/arm/include/asm/arch-imx8m/imx8mm_pins.h

diff --git a/arch/arm/include/asm/arch-imx8m/imx8mm_pins.h 
b/arch/arm/include/asm/arch-imx8m/imx8mm_pins.h
new file mode 100644
index 00..210e96e1db
--- /dev/null
+++ b/arch/arm/include/asm/arch-imx8m/imx8mm_pins.h
@@ -0,0 +1,691 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright 2018-2019 NXP
+ */
+
+#ifndef __ASM_ARCH_IMX8MM_PINS_H__
+#define __ASM_ARCH_IMX8MM_PINS_H__
+
+#include 
+
+enum {
+   IMX8MM_PAD_GPIO1_IO00_GPIO1_IO0   =  
IOMUX_PAD(0x0290, 0x0028, 0, 0x, 0, 0),
+   IMX8MM_PAD_GPIO1_IO00_CCM_ENET_PHY_REF_CLK_ROOT   =  
IOMUX_PAD(0x0290, 0x0028, 1, 0x, 0, 0),
+   IMX8MM_PAD_GPIO1_IO00_XTALOSC_REF_CLK_32K =  
IOMUX_PAD(0x0290, 0x0028, 5, 0x, 0, 0),
+   IMX8MM_PAD_GPIO1_IO00_CCM_EXT_CLK1=  
IOMUX_PAD(0x0290, 0x0028, 6, 0x, 0, 0),
+
+   IMX8MM_PAD_GPIO1_IO01_GPIO1_IO1   =  
IOMUX_PAD(0x0294, 0x002C, 0, 0x, 0, 0),
+   IMX8MM_PAD_GPIO1_IO01_PWM1_OUT=  
IOMUX_PAD(0x0294, 0x002C, 1, 0x, 0, 0),
+   IMX8MM_PAD_GPIO1_IO01_XTALOSC_REF_CLK_24M =  
IOMUX_PAD(0x0294, 0x002C, 5, 0x, 0, 0),
+   IMX8MM_PAD_GPIO1_IO01_CCM_EXT_CLK2=  
IOMUX_PAD(0x0294, 0x002C, 6, 0x, 0, 0),
+
+   IMX8MM_PAD_GPIO1_IO02_GPIO1_IO2   =  
IOMUX_PAD(0x0298, 0x0030, 0, 0x, 0, 0),
+   IMX8MM_PAD_GPIO1_IO02_WDOG1_WDOG_B=  
IOMUX_PAD(0x0298, 0x0030, 1, 0x, 0, 0),
+   IMX8MM_PAD_GPIO1_IO02_WDOG1_WDOG_ANY  =  
IOMUX_PAD(0x0298, 0x0030, 5, 0x, 0, 0),
+
+   IMX8MM_PAD_GPIO1_IO03_GPIO1_IO3   =  
IOMUX_PAD(0x029C, 0x0034, 0, 0x, 0, 0),
+   IMX8MM_PAD_GPIO1_IO03_USDHC1_VSELECT  =  
IOMUX_PAD(0x029C, 0x0034, 1, 0x, 0, 0),
+   IMX8MM_PAD_GPIO1_IO03_SDMA1_EXT_EVENT0=  
IOMUX_PAD(0x029C, 0x0034, 5, 0x, 0, 0),
+
+   IMX8MM_PAD_GPIO1_IO04_GPIO1_IO4   =  
IOMUX_PAD(0x02A0, 0x0038, 0, 0x, 0, 0),
+   IMX8MM_PAD_GPIO1_IO04_USDHC2_VSELECT  =  
IOMUX_PAD(0x02A0, 0x0038, 1, 0x, 0, 0),
+   IMX8MM_PAD_GPIO1_IO04_SDMA1_EXT_EVENT1=  
IOMUX_PAD(0x02A0, 0x0038, 5, 0x, 0, 0),
+
+   IMX8MM_PAD_GPIO1_IO05_GPIO1_IO5   =  
IOMUX_PAD(0x02A4, 0x003C, 0, 0x, 0, 0),
+   IMX8MM_PAD_GPIO1_IO05_ARM_PLATFORM_M4_NMI =  
IOMUX_PAD(0x02A4, 0x003C, 1, 0x, 0, 0),
+   IMX8MM_PAD_GPIO1_IO05_CCM_PMIC_READY  =  
IOMUX_PAD(0x02A4, 0x003C, 5, 0x04BC, 0, 0),
+   IMX8MM_PAD_GPIO1_IO05_SRC_INT_BOOT=  
IOMUX_PAD(0x02A4, 0x003C, 6, 0x, 0, 0),
+
+   IMX8MM_PAD_GPIO1_IO06_GPIO1_IO6   =  
IOMUX_PAD(0x02A8, 0x0040, 0, 0x, 0, 0),
+   IMX8MM_PAD_GPIO1_IO06_ENET1_MDC   =  
IOMUX_PAD(0x02A8, 0x0040, 1, 0x, 0, 0),
+   IMX8MM_PAD_GPIO1_IO06_USDHC1_CD_B =  
IOMUX_PAD(0x02A8, 0x0040, 5, 0x, 0, 0),
+   IMX8MM_PAD_GPIO1_IO06_CCM_EXT_CLK3=  
IOMUX_PAD(0x02A8, 0x0040, 6, 0x, 0, 0),
+
+   IMX8MM_PAD_GPIO1_IO07_GPIO1_IO7   =  
IOMUX_PAD(0x02AC, 0x0044, 0, 0x, 0, 0),
+   IMX8MM_PAD_GPIO1_IO07_ENET1_MDIO  =  
IOMUX_PAD(0x02AC, 0x0044, 1, 0x04C0, 0, 0),
+   IMX8MM_PAD_GPIO1_IO07_USDHC1_WP   =  
IOMUX_PAD(0x02AC, 0x0044, 5, 0x, 0, 0),
+   IMX8MM_PAD_GPIO1_IO07_CCM_EXT_CLK4=  
IOMUX_PAD(0x02AC, 0x0044, 6, 0x, 0, 0),
+
+   IMX8MM_PAD_GPIO1_IO08_GPIO1_IO8   =  
IOMUX_PAD(0x02B0, 0x0048, 0, 0x, 0, 0),
+   IMX8MM_PAD_GPIO1_IO08_ENET1_1588_EVENT0_IN=  
IOMUX_PAD(0x02B0, 0x0048, 1, 0x, 0, 0),
+   IMX8MM_PAD_GPIO1_IO08_USDHC2_RESET_B  =  
IOMUX_PAD(0x02B0, 0x0048, 5, 0x, 0, 0),
+   IMX8MM_PAD_GPIO1_IO08_CCM_WAIT=  
IOMUX_PAD(0x02B0, 0x0048, 6, 0x, 0, 0),
+
+   IMX8MM_PAD_GPIO1_IO09_GPIO1_IO9   =  
IOMUX_PAD(0x02B4, 0x004C, 0, 0x, 0, 0),
+   IMX8MM_PAD_GPIO1_IO09_ENET1_1588_EVENT0_OUT   =  
IOMUX_PAD(0x02B4, 0x004C, 1, 0x, 0, 0),
+   IMX8MM_PAD_GPIO1_IO09_USDHC3_RESET_B  =  
IOMUX_PAD(0x02B4, 0x004C, 4, 0x,

[U-Boot] [i.MX8MM+CCF 33/41] imx8m: Configure trustzone region 0 for non-secure access

From: Ye Li 

Set trustzone region 0 to allow both non-secure and secure access
when trust zone is enabled. We found USB controller fails to access
DDR if the default region 0 is secure access only.

Signed-off-by: Ye Li 
Signed-off-by: Peng Fan 
---
 arch/arm/mach-imx/imx8m/soc.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/mach-imx/imx8m/soc.c b/arch/arm/mach-imx/imx8m/soc.c
index 3918578399..abf526bc68 100644
--- a/arch/arm/mach-imx/imx8m/soc.c
+++ b/arch/arm/mach-imx/imx8m/soc.c
@@ -61,6 +61,12 @@ void enable_tzc380(void)
setbits_le32(>gpr[10], GPR_TZASC_EN_LOCK);
if (IS_ENABLED(CONFIG_IMX8MM))
setbits_le32(>gpr[10], BIT(1));
+   /*
+* set Region 0 attribute to allow secure and non-secure
+* read/write permission. Found some masters like usb dwc3
+* controllers can't work with secure memory.
+*/
+   writel(0xf000, TZASC_BASE_ADDR + 0x108);
 }
 
 void set_wdog_reset(struct wdog_regs *wdog)
-- 
2.16.4

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

[U-Boot] [i.MX8MM+CCF 16/41] drivers: core: use strcmp when find device by name

`if (!strncmp(dev->name, name, strlen(name)))` might find out
the wrong device, it might find out `dram_pll_ref_sel`, when name is
`dram_pll`. So use strcmp to avoid such issue.

Signed-off-by: Peng Fan 
---
 drivers/core/uclass.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/core/uclass.c b/drivers/core/uclass.c
index fc3157de39..e2f35393a9 100644
--- a/drivers/core/uclass.c
+++ b/drivers/core/uclass.c
@@ -260,7 +260,7 @@ int uclass_find_device_by_name(enum uclass_id id, const 
char *name,
return ret;
 
uclass_foreach_dev(dev, uc) {
-   if (!strncmp(dev->name, name, strlen(name))) {
+   if (!strcmp(dev->name, name)) {
*devp = dev;
return 0;
}
-- 
2.16.4

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

[U-Boot] [i.MX8MM+CCF 37/41] clk: imx: add pll14xx driver

Add pll14xx driver

Signed-off-by: Peng Fan 
---
 drivers/clk/imx/clk-pll14xx.c | 377 ++
 drivers/clk/imx/clk.h |  25 +++
 2 files changed, 402 insertions(+)
 create mode 100644 drivers/clk/imx/clk-pll14xx.c

diff --git a/drivers/clk/imx/clk-pll14xx.c b/drivers/clk/imx/clk-pll14xx.c
new file mode 100644
index 00..a398b0bbc4
--- /dev/null
+++ b/drivers/clk/imx/clk-pll14xx.c
@@ -0,0 +1,377 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2017-2019 NXP.
+ *
+ * Peng Fan 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "clk.h"
+
+#define UBOOT_DM_CLK_IMX_PLL1443X "imx_clk_pll1443x"
+#define UBOOT_DM_CLK_IMX_PLL1416X "imx_clk_pll1416x"
+
+#define GNRL_CTL   0x0
+#define DIV_CTL0x4
+#define LOCK_STATUSBIT(31)
+#define LOCK_SEL_MASK  BIT(29)
+#define CLKE_MASK  BIT(11)
+#define RST_MASK   BIT(9)
+#define BYPASS_MASKBIT(4)
+#define MDIV_SHIFT 12
+#define MDIV_MASK  GENMASK(21, 12)
+#define PDIV_SHIFT 4
+#define PDIV_MASK  GENMASK(9, 4)
+#define SDIV_SHIFT 0
+#define SDIV_MASK  GENMASK(2, 0)
+#define KDIV_SHIFT 0
+#define KDIV_MASK  GENMASK(15, 0)
+
+#define LOCK_TIMEOUT_US1
+
+struct clk_pll14xx {
+   struct clk  clk;
+   void __iomem*base;
+   enum imx_pll14xx_type   type;
+   const struct imx_pll14xx_rate_table *rate_table;
+   int rate_count;
+};
+
+#define to_clk_pll14xx(_clk) container_of(_clk, struct clk_pll14xx, clk)
+
+static const struct imx_pll14xx_rate_table *imx_get_pll_settings(
+   struct clk_pll14xx *pll, unsigned long rate)
+{
+   const struct imx_pll14xx_rate_table *rate_table = pll->rate_table;
+   int i;
+
+   for (i = 0; i < pll->rate_count; i++)
+   if (rate == rate_table[i].rate)
+   return _table[i];
+
+   return NULL;
+}
+
+static unsigned long clk_pll1416x_recalc_rate(struct clk *clk)
+{
+   struct clk_pll14xx *pll = to_clk_pll14xx(
+   (struct clk *)dev_get_driver_data(clk->dev));
+   u32 mdiv, pdiv, sdiv, pll_div;
+   u64 fvco = clk_get_parent_rate(clk);
+
+   pll_div = readl(pll->base + 4);
+   mdiv = (pll_div & MDIV_MASK) >> MDIV_SHIFT;
+   pdiv = (pll_div & PDIV_MASK) >> PDIV_SHIFT;
+   sdiv = (pll_div & SDIV_MASK) >> SDIV_SHIFT;
+
+   fvco *= mdiv;
+   do_div(fvco, pdiv << sdiv);
+
+   return fvco;
+}
+
+static unsigned long clk_pll1443x_recalc_rate(struct clk *clk)
+{
+   struct clk_pll14xx *pll = to_clk_pll14xx(
+   (struct clk *)dev_get_driver_data(clk->dev));
+   u32 mdiv, pdiv, sdiv, pll_div_ctl0, pll_div_ctl1;
+   short int kdiv;
+   u64 fvco = clk_get_parent_rate(clk);
+
+   pll_div_ctl0 = readl(pll->base + 4);
+   pll_div_ctl1 = readl(pll->base + 8);
+   mdiv = (pll_div_ctl0 & MDIV_MASK) >> MDIV_SHIFT;
+   pdiv = (pll_div_ctl0 & PDIV_MASK) >> PDIV_SHIFT;
+   sdiv = (pll_div_ctl0 & SDIV_MASK) >> SDIV_SHIFT;
+   kdiv = pll_div_ctl1 & KDIV_MASK;
+
+   /* fvco = (m * 65536 + k) * Fin / (p * 65536) */
+   fvco *= (mdiv * 65536 + kdiv);
+   pdiv *= 65536;
+
+   do_div(fvco, pdiv << sdiv);
+
+   return fvco;
+}
+
+static inline bool clk_pll1416x_mp_change(const struct imx_pll14xx_rate_table 
*rate,
+ u32 pll_div)
+{
+   u32 old_mdiv, old_pdiv;
+
+   old_mdiv = (pll_div >> MDIV_SHIFT) & MDIV_MASK;
+   old_pdiv = (pll_div >> PDIV_SHIFT) & PDIV_MASK;
+
+   return rate->mdiv != old_mdiv || rate->pdiv != old_pdiv;
+}
+
+static inline bool clk_pll1443x_mpk_change(const struct imx_pll14xx_rate_table 
*rate,
+ u32 pll_div_ctl0, u32 pll_div_ctl1)
+{
+   u32 old_mdiv, old_pdiv, old_kdiv;
+
+   old_mdiv = (pll_div_ctl0 >> MDIV_SHIFT) & MDIV_MASK;
+   old_pdiv = (pll_div_ctl0 >> PDIV_SHIFT) & PDIV_MASK;
+   old_kdiv = (pll_div_ctl1 >> KDIV_SHIFT) & KDIV_MASK;
+
+   return rate->mdiv != old_mdiv || rate->pdiv != old_pdiv ||
+   rate->kdiv != old_kdiv;
+}
+
+static inline bool clk_pll1443x_mp_change(const struct imx_pll14xx_rate_table 
*rate,
+ u32 pll_div_ctl0, u32 pll_div_ctl1)
+{
+   u32 old_mdiv, old_pdiv, old_kdiv;
+
+   old_mdiv = (pll_div_ctl0 >> MDIV_SHIFT) & MDIV_MASK;
+   old_pdiv = (pll_div_ctl0 >> PDIV_SHIFT) & PDIV_MASK;
+   old_kdiv = (pll_div_ctl1 >> KDIV_SHIFT) & KDIV_MASK;
+
+   return rate->mdiv != old_mdiv || rate->pdiv != old_pdiv ||
+   rate->kdiv != old_kdiv;
+}
+
+static int clk_pll14xx_wait_lock(struct clk_pll14xx *pll)
+{
+   u32 val;
+
+   return readl_poll_timeout(pll->base, val, val & LOCK_TIMEOUT_US,
+   LOCK_TIMEOUT_US);
+}
+
+static ulong clk_pll1416x_set_rate(struct clk

[U-Boot] [i.MX8MM+CCF 36/41] clk: imx: add Kconfig entry for i.MX8MM