Re: [U-Boot] arm: socfpga: unable to boot cyclone5 devkit or SocKit

[Dinh Nguyen]

On 04/10/2018 09:45 PM, Dinh Nguyen wrote:
> 
> 
> On 04/10/2018 09:21 PM, Dinh Nguyen wrote:
>>
>>
>> On 04/10/2018 05:37 PM, Marek Vasut wrote:
>>> On 04/10/2018 11:36 PM, Dinh Nguyen wrote:


 On 04/10/2018 02:25 PM, Marek Vasut wrote:
> On 04/10/2018 08:56 PM, Dinh Nguyen wrote:
>>
>>
>> On 04/10/2018 01:29 PM, Marek Vasut wrote:
>>> On 04/10/2018 08:28 PM, Dinh Nguyen wrote:
 Hi,

 I'm seeking advice with an observation that I'm seeing on the Cyclone5
 devkit/sockit.

 I'm working with U-Boot version v2018.05-rc1. Building the
 u-boot-with-spl.sfp, then writing the sfp file to the 0xa2 partition on
 the SD card, does not boot, all I get is this:

 U-Boot SPL 2018.05-rc1 (Apr 10 2018 - 13:03:48 -0500)

 U-Boot SPL 2018.05-rc1 (Apr 10 2018 - 13:03:48 -0500)

 U-Boot SPL 2018.05-rc1 (Apr 10 2018 - 13:03:48 -0500)


 This issue doesn't happen at all on the DE0 Nano SoC board. I compared
 the defconfig and came across this. If I remove these config options in
 the socfpga_sockit_defconfig, then SPL -> U-Boot works fine.

 -CONFIG_SPI_FLASH_MACRONIX=y
 -CONFIG_SPI_FLASH_SPANSION=y
 -CONFIG_SPI_FLASH_STMICRO=y

 I'll continue to debug of course, but was wondering if anyone might 
 have
 a better idea as to what could be happening, I'd appreciate the 
 insight.
>>>
>>> Check the size of the SPL , could it be too big ?
>>>
>>
>> That's a good thought...it could be. The size of the default
>> u-boot-spl-dtb.bin is 58048, removing the SPI, brings that down to
>> 55616, that's smaller than the 64k of OCRAM for SPL?
>
> Right, I think there's something about those last few kiB OR it's the
> stack that's overwriting piece of U-Boot or malloc area or something.
> How did it grow so big anyway ?
>

 Ah, looks like SYS_MALLOC_F_LEN is set to 8k, thus, we're over the 64k
 limit. Setting SYS_MALLOC_F_LEN to 4k makes it work again. I'm not sure
 how the SPL grew so big.
>>>
>>> I have a couple of theories, but anyway ...
>>>
>>> u-boot$ git reset --hard v2018.01 ; bu socfpga_cyclone5 ; ls -la
>>> spl/u-boot-spl.bin
>>> HEAD is now at f3dd87e0b9 Prepare v2018.01
>>> -rw-r--r-- 1 marex marex 52902 Apr 11 00:34 spl/u-boot-spl.bin
>>>
>>> u-boot$ git reset --hard v2018.03 ; bu socfpga_cyclone5 ; ls -la
>>> spl/u-boot-spl.bin
>>> HEAD is now at f95ab1fb6e Prepare v2018.03
>>> -rw-r--r-- 1 marex marex 59706 Apr 11 00:34 spl/u-boot-spl.bin
>>>
>>> Try bisecting out the commit which caused this 7 kiB growth between
>>> 2018.01 and 2018.03 . Even those 53 kiB are quite borderline, but it was
>>> at 53 kiB for a while (2017.05 is also ~53 kiB)
>>>
>>
>> Doing the bisect points me to this commit:
>>
>> commit fa2c14676c7c6f3115dd4d9b2a4cc3b35c3ad2a2
>> Author: Tom Rini 
>> Date:   Sat Feb 10 16:54:38 2018 -0500
>>
>> configs: Re-sync with CONFIG_DISTRO_DEFAULTS
>>
>> A number of platforms include config_distro_defaults.h but do not enable
>> CONFIG_DISTRO_DEFAULTS.  As they plainly intended to, set that flag and
>> re-sync config files.
>>
>> Signed-off-by: Tom Rini 
>>
>> Doing a revert of the above commit shrinks the SPL back down to ~7 kiB.
>>
>> Dinh
>>
> 
> It looks like the enablement of CONFIG_DISTRO_DEFAULTS, enables these
> configs:
> 
> CONFIG_ISO_PARTITION=y
> CONFIG_SPL_ISO_PARTITION=y
> # CONFIG_AMIGA_PARTITION is not set
> # CONFIG_SPL_AMIGA_PARTITION is not set
> CONFIG_EFI_PARTITION=y
> CONFIG_EFI_PARTITION_ENTRIES_NUMBERS=128
> CONFIG_EFI_PARTITION_ENTRIES_OFF=0
> CONFIG_SPL_EFI_PARTITION=y
> CONFIG_PARTITION_UUIDS=y
> CONFIG_SPL_PARTITION_UUIDS=y
> # CONFIG_PARTITION_TYPE_GUID is not set
> 
> Which is contributing to the SPL growth.
> 

Turning the following config options off subtracts 7k from the SPL:

+# CONFIG_SPL_ISO_PARTITION is not set
+# CONFIG_SPL_EFI_PARTITION is not set

Not sure if these are needed?

Dinh


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

Re: [U-Boot] arm: socfpga: unable to boot cyclone5 devkit or SocKit

[Dinh Nguyen]

On 04/10/2018 09:21 PM, Dinh Nguyen wrote:
> 
> 
> On 04/10/2018 05:37 PM, Marek Vasut wrote:
>> On 04/10/2018 11:36 PM, Dinh Nguyen wrote:
>>>
>>>
>>> On 04/10/2018 02:25 PM, Marek Vasut wrote:
 On 04/10/2018 08:56 PM, Dinh Nguyen wrote:
>
>
> On 04/10/2018 01:29 PM, Marek Vasut wrote:
>> On 04/10/2018 08:28 PM, Dinh Nguyen wrote:
>>> Hi,
>>>
>>> I'm seeking advice with an observation that I'm seeing on the Cyclone5
>>> devkit/sockit.
>>>
>>> I'm working with U-Boot version v2018.05-rc1. Building the
>>> u-boot-with-spl.sfp, then writing the sfp file to the 0xa2 partition on
>>> the SD card, does not boot, all I get is this:
>>>
>>> U-Boot SPL 2018.05-rc1 (Apr 10 2018 - 13:03:48 -0500)
>>>
>>> U-Boot SPL 2018.05-rc1 (Apr 10 2018 - 13:03:48 -0500)
>>>
>>> U-Boot SPL 2018.05-rc1 (Apr 10 2018 - 13:03:48 -0500)
>>>
>>>
>>> This issue doesn't happen at all on the DE0 Nano SoC board. I compared
>>> the defconfig and came across this. If I remove these config options in
>>> the socfpga_sockit_defconfig, then SPL -> U-Boot works fine.
>>>
>>> -CONFIG_SPI_FLASH_MACRONIX=y
>>> -CONFIG_SPI_FLASH_SPANSION=y
>>> -CONFIG_SPI_FLASH_STMICRO=y
>>>
>>> I'll continue to debug of course, but was wondering if anyone might have
>>> a better idea as to what could be happening, I'd appreciate the insight.
>>
>> Check the size of the SPL , could it be too big ?
>>
>
> That's a good thought...it could be. The size of the default
> u-boot-spl-dtb.bin is 58048, removing the SPI, brings that down to
> 55616, that's smaller than the 64k of OCRAM for SPL?

 Right, I think there's something about those last few kiB OR it's the
 stack that's overwriting piece of U-Boot or malloc area or something.
 How did it grow so big anyway ?

>>>
>>> Ah, looks like SYS_MALLOC_F_LEN is set to 8k, thus, we're over the 64k
>>> limit. Setting SYS_MALLOC_F_LEN to 4k makes it work again. I'm not sure
>>> how the SPL grew so big.
>>
>> I have a couple of theories, but anyway ...
>>
>> u-boot$ git reset --hard v2018.01 ; bu socfpga_cyclone5 ; ls -la
>> spl/u-boot-spl.bin
>> HEAD is now at f3dd87e0b9 Prepare v2018.01
>> -rw-r--r-- 1 marex marex 52902 Apr 11 00:34 spl/u-boot-spl.bin
>>
>> u-boot$ git reset --hard v2018.03 ; bu socfpga_cyclone5 ; ls -la
>> spl/u-boot-spl.bin
>> HEAD is now at f95ab1fb6e Prepare v2018.03
>> -rw-r--r-- 1 marex marex 59706 Apr 11 00:34 spl/u-boot-spl.bin
>>
>> Try bisecting out the commit which caused this 7 kiB growth between
>> 2018.01 and 2018.03 . Even those 53 kiB are quite borderline, but it was
>> at 53 kiB for a while (2017.05 is also ~53 kiB)
>>
> 
> Doing the bisect points me to this commit:
> 
> commit fa2c14676c7c6f3115dd4d9b2a4cc3b35c3ad2a2
> Author: Tom Rini 
> Date:   Sat Feb 10 16:54:38 2018 -0500
> 
> configs: Re-sync with CONFIG_DISTRO_DEFAULTS
> 
> A number of platforms include config_distro_defaults.h but do not enable
> CONFIG_DISTRO_DEFAULTS.  As they plainly intended to, set that flag and
> re-sync config files.
> 
> Signed-off-by: Tom Rini 
> 
> Doing a revert of the above commit shrinks the SPL back down to ~7 kiB.
> 
> Dinh
> 

It looks like the enablement of CONFIG_DISTRO_DEFAULTS, enables these
configs:

CONFIG_ISO_PARTITION=y
CONFIG_SPL_ISO_PARTITION=y
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_SPL_AMIGA_PARTITION is not set
CONFIG_EFI_PARTITION=y
CONFIG_EFI_PARTITION_ENTRIES_NUMBERS=128
CONFIG_EFI_PARTITION_ENTRIES_OFF=0
CONFIG_SPL_EFI_PARTITION=y
CONFIG_PARTITION_UUIDS=y
CONFIG_SPL_PARTITION_UUIDS=y
# CONFIG_PARTITION_TYPE_GUID is not set

Which is contributing to the SPL growth.

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

Re: [U-Boot] arm: socfpga: unable to boot cyclone5 devkit or SocKit

[Dinh Nguyen]

On 04/10/2018 05:37 PM, Marek Vasut wrote:
> On 04/10/2018 11:36 PM, Dinh Nguyen wrote:
>>
>>
>> On 04/10/2018 02:25 PM, Marek Vasut wrote:
>>> On 04/10/2018 08:56 PM, Dinh Nguyen wrote:


 On 04/10/2018 01:29 PM, Marek Vasut wrote:
> On 04/10/2018 08:28 PM, Dinh Nguyen wrote:
>> Hi,
>>
>> I'm seeking advice with an observation that I'm seeing on the Cyclone5
>> devkit/sockit.
>>
>> I'm working with U-Boot version v2018.05-rc1. Building the
>> u-boot-with-spl.sfp, then writing the sfp file to the 0xa2 partition on
>> the SD card, does not boot, all I get is this:
>>
>> U-Boot SPL 2018.05-rc1 (Apr 10 2018 - 13:03:48 -0500)
>>
>> U-Boot SPL 2018.05-rc1 (Apr 10 2018 - 13:03:48 -0500)
>>
>> U-Boot SPL 2018.05-rc1 (Apr 10 2018 - 13:03:48 -0500)
>>
>>
>> This issue doesn't happen at all on the DE0 Nano SoC board. I compared
>> the defconfig and came across this. If I remove these config options in
>> the socfpga_sockit_defconfig, then SPL -> U-Boot works fine.
>>
>> -CONFIG_SPI_FLASH_MACRONIX=y
>> -CONFIG_SPI_FLASH_SPANSION=y
>> -CONFIG_SPI_FLASH_STMICRO=y
>>
>> I'll continue to debug of course, but was wondering if anyone might have
>> a better idea as to what could be happening, I'd appreciate the insight.
>
> Check the size of the SPL , could it be too big ?
>

 That's a good thought...it could be. The size of the default
 u-boot-spl-dtb.bin is 58048, removing the SPI, brings that down to
 55616, that's smaller than the 64k of OCRAM for SPL?
>>>
>>> Right, I think there's something about those last few kiB OR it's the
>>> stack that's overwriting piece of U-Boot or malloc area or something.
>>> How did it grow so big anyway ?
>>>
>>
>> Ah, looks like SYS_MALLOC_F_LEN is set to 8k, thus, we're over the 64k
>> limit. Setting SYS_MALLOC_F_LEN to 4k makes it work again. I'm not sure
>> how the SPL grew so big.
> 
> I have a couple of theories, but anyway ...
> 
> u-boot$ git reset --hard v2018.01 ; bu socfpga_cyclone5 ; ls -la
> spl/u-boot-spl.bin
> HEAD is now at f3dd87e0b9 Prepare v2018.01
> -rw-r--r-- 1 marex marex 52902 Apr 11 00:34 spl/u-boot-spl.bin
> 
> u-boot$ git reset --hard v2018.03 ; bu socfpga_cyclone5 ; ls -la
> spl/u-boot-spl.bin
> HEAD is now at f95ab1fb6e Prepare v2018.03
> -rw-r--r-- 1 marex marex 59706 Apr 11 00:34 spl/u-boot-spl.bin
> 
> Try bisecting out the commit which caused this 7 kiB growth between
> 2018.01 and 2018.03 . Even those 53 kiB are quite borderline, but it was
> at 53 kiB for a while (2017.05 is also ~53 kiB)
> 

Doing the bisect points me to this commit:

commit fa2c14676c7c6f3115dd4d9b2a4cc3b35c3ad2a2
Author: Tom Rini 
Date:   Sat Feb 10 16:54:38 2018 -0500

configs: Re-sync with CONFIG_DISTRO_DEFAULTS

A number of platforms include config_distro_defaults.h but do not enable
CONFIG_DISTRO_DEFAULTS.  As they plainly intended to, set that flag and
re-sync config files.

Signed-off-by: Tom Rini 

Doing a revert of the above commit shrinks the SPL back down to ~7 kiB.

Dinh


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

Re: [U-Boot] [PATCH 3/4] elf: Add a very simple elf64 loader

[Bin Meng]

On Wed, Apr 11, 2018 at 3:04 AM, Calvin Johnson  wrote:
> On Mon, Apr 09, 2018 at 11:28:30PM -0700, Bin Meng wrote:
>> This adds a very simple elf64 loader via program headers, similar
>> to load_elf_image_phdr() that we already have.
>>
>> Signed-off-by: Bin Meng 
>> ---
>>
>>  cmd/elf.c | 34 ++
>>  1 file changed, 34 insertions(+)
>>
>> diff --git a/cmd/elf.c b/cmd/elf.c
>> index 501f935..91a04da 100644
>> --- a/cmd/elf.c
>> +++ b/cmd/elf.c
>> @@ -24,6 +24,37 @@
>>  #endif
>>
>>  /*
>> + * A very simple elf64 loader, assumes the image is valid, returns the
>> + * entry point address.
>> + */
>> +static unsigned long load_elf64_image_phdr(unsigned long addr)
>> +{
>> + Elf64_Ehdr *ehdr; /* Elf header structure pointer */
>> + Elf64_Phdr *phdr; /* Program header structure pointer */
>> + int i;
>> +
>> + ehdr = (Elf64_Ehdr *)addr;
>> + phdr = (Elf64_Phdr *)(addr + (ulong)ehdr->e_phoff);
>> +
>> + /* Load each program header */
>> + for (i = 0; i < ehdr->e_phnum; ++i) {
>> + void *dst = (void *)(ulong)phdr->p_paddr;
>> + void *src = (void *)addr + phdr->p_offset;
>> + debug("Loading phdr %i to 0x%p (%lu bytes)\n",
>> +   i, dst, (ulong)phdr->p_filesz);
>> + if (phdr->p_filesz)
>> + memcpy(dst, src, phdr->p_filesz);
>> + if (phdr->p_filesz != phdr->p_memsz)
>> + memset(dst + phdr->p_filesz, 0x00,
>> +phdr->p_memsz - phdr->p_filesz);
>> + flush_cache((unsigned long)dst, phdr->p_filesz);
>> + ++phdr;
>> + }
>> +
>> + return ehdr->e_entry;
>> +}
>> +
>> +/*
>>   * A very simple elf loader, assumes the image is valid, returns the
> Would it be good to modify this comment to indicate elf32 loader?

Will add some more comments in v2.

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

[U-Boot] [PATCH 1/1][for v2018.05] efi_loader: no support for ARMV7_NONSEC=y

[Heinrich Schuchardt]

We do not support bootefi booting ARMv7 in non-secure mode.

Signed-off-by: Heinrich Schuchardt 
---
 doc/README.uefi| 2 ++
 lib/efi_loader/Kconfig | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/doc/README.uefi b/doc/README.uefi
index 7403be3614..ba66b16743 100644
--- a/doc/README.uefi
+++ b/doc/README.uefi
@@ -324,6 +324,8 @@ This driver is only available if U-Boot is configured with
   * persistence
   * runtime support
 
+* support bootefi booting ARMv7 in non-secure mode (CONFIG_ARMV7_NONSEC=y)
+
 ## Links
 
 * [1](http://uefi.org/specifications)
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index 83d75c4fdc..d38780b604 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -1,6 +1,8 @@
 config EFI_LOADER
bool "Support running EFI Applications in U-Boot"
depends on (ARM || X86) && OF_LIBFDT
+   # We do not support bootefi booting ARMv7 in non-secure mode
+   depends on !ARMV7_NONSEC
# We need EFI_STUB_64BIT to be set on x86_64 with EFI_STUB
depends on !EFI_STUB || !X86_64 || EFI_STUB_64BIT
# We need EFI_STUB_32BIT to be set on x86_32 with EFI_STUB
-- 
2.14.2

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

Re: [U-Boot] arm: socfpga: unable to boot cyclone5 devkit or SocKit

[Marek Vasut]

On 04/10/2018 11:36 PM, Dinh Nguyen wrote:
> 
> 
> On 04/10/2018 02:25 PM, Marek Vasut wrote:
>> On 04/10/2018 08:56 PM, Dinh Nguyen wrote:
>>>
>>>
>>> On 04/10/2018 01:29 PM, Marek Vasut wrote:
 On 04/10/2018 08:28 PM, Dinh Nguyen wrote:
> Hi,
>
> I'm seeking advice with an observation that I'm seeing on the Cyclone5
> devkit/sockit.
>
> I'm working with U-Boot version v2018.05-rc1. Building the
> u-boot-with-spl.sfp, then writing the sfp file to the 0xa2 partition on
> the SD card, does not boot, all I get is this:
>
> U-Boot SPL 2018.05-rc1 (Apr 10 2018 - 13:03:48 -0500)
>
> U-Boot SPL 2018.05-rc1 (Apr 10 2018 - 13:03:48 -0500)
>
> U-Boot SPL 2018.05-rc1 (Apr 10 2018 - 13:03:48 -0500)
>
>
> This issue doesn't happen at all on the DE0 Nano SoC board. I compared
> the defconfig and came across this. If I remove these config options in
> the socfpga_sockit_defconfig, then SPL -> U-Boot works fine.
>
> -CONFIG_SPI_FLASH_MACRONIX=y
> -CONFIG_SPI_FLASH_SPANSION=y
> -CONFIG_SPI_FLASH_STMICRO=y
>
> I'll continue to debug of course, but was wondering if anyone might have
> a better idea as to what could be happening, I'd appreciate the insight.

 Check the size of the SPL , could it be too big ?

>>>
>>> That's a good thought...it could be. The size of the default
>>> u-boot-spl-dtb.bin is 58048, removing the SPI, brings that down to
>>> 55616, that's smaller than the 64k of OCRAM for SPL?
>>
>> Right, I think there's something about those last few kiB OR it's the
>> stack that's overwriting piece of U-Boot or malloc area or something.
>> How did it grow so big anyway ?
>>
> 
> Ah, looks like SYS_MALLOC_F_LEN is set to 8k, thus, we're over the 64k
> limit. Setting SYS_MALLOC_F_LEN to 4k makes it work again. I'm not sure
> how the SPL grew so big.

I have a couple of theories, but anyway ...

u-boot$ git reset --hard v2018.01 ; bu socfpga_cyclone5 ; ls -la
spl/u-boot-spl.bin
HEAD is now at f3dd87e0b9 Prepare v2018.01
-rw-r--r-- 1 marex marex 52902 Apr 11 00:34 spl/u-boot-spl.bin

u-boot$ git reset --hard v2018.03 ; bu socfpga_cyclone5 ; ls -la
spl/u-boot-spl.bin
HEAD is now at f95ab1fb6e Prepare v2018.03
-rw-r--r-- 1 marex marex 59706 Apr 11 00:34 spl/u-boot-spl.bin

Try bisecting out the commit which caused this 7 kiB growth between
2018.01 and 2018.03 . Even those 53 kiB are quite borderline, but it was
at 53 kiB for a while (2017.05 is also ~53 kiB)

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

Re: [U-Boot] [PATCH 03/12] libfdt: Safer access to strings section

[Tom Rini]

On Tue, Apr 10, 2018 at 10:42:45AM -0400, Simon Glass wrote:
> +U-Boot, Tom, Masahiro
> 
> Hi David,
> 
> On 10 April 2018 at 01:22, David Gibson  wrote:
> > On Wed, Apr 04, 2018 at 01:21:10AM +0800, Simon Glass wrote:
> >> Hi David,
> >>
> >> On 3 April 2018 at 23:02, David Gibson  wrote:
> >> >
> >> > On Fri, Mar 30, 2018 at 04:42:21PM +0800, Simon Glass wrote:
> >> > > Hi David,
> >> > >
> >> > > On 26 March 2018 at 07:25, David Gibson  
> >> > > wrote:
> >> > > > fdt_string() is used to retrieve strings from a DT blob's strings 
> >> > > > section.
> >> > > > It's rarely used directly, but is widely used internally.
> >> > > >
> >> > > > However, it doesn't do any bounds checking, which means in the case 
> >> > > > of a
> >> > > > corrupted blob it could access bad memory, which libfdt is supposed 
> >> > > > to
> >> > > > avoid.
> >> > > >
> >> > > > This write a safe alternative to fdt_string, fdt_get_string().  It 
> >> > > > checks
> >> > > > both that the given offset is within the string section and that the 
> >> > > > string
> >> > > > it points to is properly \0 terminated within the section.  It also 
> >> > > > returns
> >> > > > the string's length as a convenience (since it needs to determine to 
> >> > > > do the
> >> > > > checks anyway).
> >> > > >
> >> > > > fdt_string() is rewritten in terms of fdt_get_string() for 
> >> > > > compatibility.
> >> > > >
> >> > > > Most of the diff here is actually testing infrastructure.
> >> > > >
> >> > > > Signed-off-by: David Gibson 
> >> > > > ---
> >> > > >  libfdt/fdt_ro.c  | 61 +++--
> >> > > >  libfdt/libfdt.h  | 18 ++-
> >> > > >  libfdt/version.lds   |  2 +-
> >> > > >  tests/.gitignore |  1 +
> >> > > >  tests/Makefile.tests |  2 +-
> >> > > >  tests/run_tests.sh   |  1 +
> >> > > >  tests/testdata.h |  1 +
> >> > > >  tests/testutils.c| 11 +--
> >> > > >  tests/trees.S| 26 
> >> > > >  tests/truncated_string.c | 79 
> >> > > > 
> >> > > >  10 files changed, 193 insertions(+), 9 deletions(-)
> >> > > >  create mode 100644 tests/truncated_string.c
> >> > >
> >> > > Similar code-size quesiton here. It looks like a lot of checking code.
> >> > > Can we have an option to remove it?
> >> >
> >> > Again, I'm disinclined without a concrete example of a problem.  Fwiw
> >> > the code size change is +276 bytes on my setup.
> >>
> >> That might not sound like a lot, but the overhead of DT in U-Boot is
> >> about 3KB, so this adds nearly 10%.
> >
> > Hm.  And how much is it compared to the whole U-Boot blob?
> >
> >> The specific problem is that when U-Boot SPL gets too big boards don't
> >> boot. Because we take the upstream libfdt this will affect U-Boot.
> >>
> >> Do you have any thoughts on how we could avoid this size increase?
> >
> > So, again, I'm very disinclined to prioritize size over memory safety
> > without a *concrete* example.  i.e. "We hit this specific problem with
> > size on this specific board that we were really using" rather than
> > just "it might be a problem".

I'm either failing in my Google-fu or is there not an easy way to grab
the patches from patchwork/similar?  But, if you shoot me the series
off-list, I can tell you how much U-Boot targets grow here (we can use
the same script as the kernel to re-sync sources back in, so I can give
you a before/after).  But as Simon notes, we have a number of platforms
that need to use (parts of) libfdt and stick to ~30KiB or less in total,
sometimes including some memory for stack/etc and we've long been using
-ffunction-sections/etc (the latest round of trying to use LTO has me
thinking maybe we can see if that's a valid option finally, but that's
an aside). 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] arm: socfpga: unable to boot cyclone5 devkit or SocKit

[Dinh Nguyen]

On 04/10/2018 02:25 PM, Marek Vasut wrote:
> On 04/10/2018 08:56 PM, Dinh Nguyen wrote:
>>
>>
>> On 04/10/2018 01:29 PM, Marek Vasut wrote:
>>> On 04/10/2018 08:28 PM, Dinh Nguyen wrote:
 Hi,

 I'm seeking advice with an observation that I'm seeing on the Cyclone5
 devkit/sockit.

 I'm working with U-Boot version v2018.05-rc1. Building the
 u-boot-with-spl.sfp, then writing the sfp file to the 0xa2 partition on
 the SD card, does not boot, all I get is this:

 U-Boot SPL 2018.05-rc1 (Apr 10 2018 - 13:03:48 -0500)

 U-Boot SPL 2018.05-rc1 (Apr 10 2018 - 13:03:48 -0500)

 U-Boot SPL 2018.05-rc1 (Apr 10 2018 - 13:03:48 -0500)


 This issue doesn't happen at all on the DE0 Nano SoC board. I compared
 the defconfig and came across this. If I remove these config options in
 the socfpga_sockit_defconfig, then SPL -> U-Boot works fine.

 -CONFIG_SPI_FLASH_MACRONIX=y
 -CONFIG_SPI_FLASH_SPANSION=y
 -CONFIG_SPI_FLASH_STMICRO=y

 I'll continue to debug of course, but was wondering if anyone might have
 a better idea as to what could be happening, I'd appreciate the insight.
>>>
>>> Check the size of the SPL , could it be too big ?
>>>
>>
>> That's a good thought...it could be. The size of the default
>> u-boot-spl-dtb.bin is 58048, removing the SPI, brings that down to
>> 55616, that's smaller than the 64k of OCRAM for SPL?
> 
> Right, I think there's something about those last few kiB OR it's the
> stack that's overwriting piece of U-Boot or malloc area or something.
> How did it grow so big anyway ?
> 

Ah, looks like SYS_MALLOC_F_LEN is set to 8k, thus, we're over the 64k
limit. Setting SYS_MALLOC_F_LEN to 4k makes it work again. I'm not sure
how the SPL grew so big.

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

[U-Boot] [PATCH 1/1] vexpress: fix syntax error in armv7_boot_nonsec_default()

[Heinrich Schuchardt]

With CONFIG_ARMV7_BOOT_SEC_DEFAULT=y a syntax error occurs.
Add the missing semicolon.

Signed-off-by: Heinrich Schuchardt 
---
 board/armltd/vexpress/vexpress_tc2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/armltd/vexpress/vexpress_tc2.c 
b/board/armltd/vexpress/vexpress_tc2.c
index b143e04097..9cd0ec8ea0 100644
--- a/board/armltd/vexpress/vexpress_tc2.c
+++ b/board/armltd/vexpress/vexpress_tc2.c
@@ -18,7 +18,7 @@
 bool armv7_boot_nonsec_default(void)
 {
 #ifdef CONFIG_ARMV7_BOOT_SEC_DEFAULT
-   return false
+   return false;
 #else
/*
 * The Serial Configuration Controller (SCC) register at address 0x700
-- 
2.14.2

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

[U-Boot] [PATCH] mx6cuboxi: Fix some memory configuration errors

[Fabio Estevam]

From: Jon Nettleton 

These changes bring mainline back into line with the configurations
that were originally set in our stable BSP.

Signed-off-by: Jon Nettleton 
Signed-off-by: Fabio Estevam 
---
 board/solidrun/mx6cuboxi/mx6cuboxi.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/board/solidrun/mx6cuboxi/mx6cuboxi.c 
b/board/solidrun/mx6cuboxi/mx6cuboxi.c
index ee9e4f7..727b639 100644
--- a/board/solidrun/mx6cuboxi/mx6cuboxi.c
+++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c
@@ -428,7 +428,7 @@ static const struct mx6dq_iomux_ddr_regs mx6q_ddr_ioregs = {
.dram_sdclk_1 =  0x00020030,
.dram_cas =  0x00020030,
.dram_ras =  0x00020030,
-   .dram_reset =  0x00020030,
+   .dram_reset =  0x000c0030,
.dram_sdcke0 =  0x3000,
.dram_sdcke1 =  0x3000,
.dram_sdba2 =  0x,
@@ -584,7 +584,6 @@ static struct mx6_ddr3_cfg mem_ddr_2g = {
.trcd  = 1375,
.trcmin= 4875,
.trasmin   = 3500,
-   .SRT   = 1,
 };
 
 static struct mx6_ddr3_cfg mem_ddr_4g = {
-- 
2.7.4

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

Re: [U-Boot] arm: socfpga: unable to boot cyclone5 devkit or SocKit

[Marek Vasut]

On 04/10/2018 08:56 PM, Dinh Nguyen wrote:
> 
> 
> On 04/10/2018 01:29 PM, Marek Vasut wrote:
>> On 04/10/2018 08:28 PM, Dinh Nguyen wrote:
>>> Hi,
>>>
>>> I'm seeking advice with an observation that I'm seeing on the Cyclone5
>>> devkit/sockit.
>>>
>>> I'm working with U-Boot version v2018.05-rc1. Building the
>>> u-boot-with-spl.sfp, then writing the sfp file to the 0xa2 partition on
>>> the SD card, does not boot, all I get is this:
>>>
>>> U-Boot SPL 2018.05-rc1 (Apr 10 2018 - 13:03:48 -0500)
>>>
>>> U-Boot SPL 2018.05-rc1 (Apr 10 2018 - 13:03:48 -0500)
>>>
>>> U-Boot SPL 2018.05-rc1 (Apr 10 2018 - 13:03:48 -0500)
>>>
>>>
>>> This issue doesn't happen at all on the DE0 Nano SoC board. I compared
>>> the defconfig and came across this. If I remove these config options in
>>> the socfpga_sockit_defconfig, then SPL -> U-Boot works fine.
>>>
>>> -CONFIG_SPI_FLASH_MACRONIX=y
>>> -CONFIG_SPI_FLASH_SPANSION=y
>>> -CONFIG_SPI_FLASH_STMICRO=y
>>>
>>> I'll continue to debug of course, but was wondering if anyone might have
>>> a better idea as to what could be happening, I'd appreciate the insight.
>>
>> Check the size of the SPL , could it be too big ?
>>
> 
> That's a good thought...it could be. The size of the default
> u-boot-spl-dtb.bin is 58048, removing the SPI, brings that down to
> 55616, that's smaller than the 64k of OCRAM for SPL?

Right, I think there's something about those last few kiB OR it's the
stack that's overwriting piece of U-Boot or malloc area or something.
How did it grow so big anyway ?

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

[U-Boot] AM3517-EVM MMC broken

[Adam Ford]

It appears commit 4bafceff0e9e (" Merge git://git.denx.de/u-boot-mmc")
seems to have broken the AM3517-EVM board.  The AM3517 is similar to the
OMAP3, and the omap3_logic board (DM3730) works just fine.

The output does not show any text for SPL/MLO but 4bafceff0e9e is commit
which seems hard to traverse.  If anyone has any suggestions on something
to try, I'm open for ideas.

Thanks

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

Re: [U-Boot] [PATCH 3/4] elf: Add a very simple elf64 loader

[Calvin Johnson]

On Mon, Apr 09, 2018 at 11:28:30PM -0700, Bin Meng wrote:
> This adds a very simple elf64 loader via program headers, similar
> to load_elf_image_phdr() that we already have.
> 
> Signed-off-by: Bin Meng 
> ---
> 
>  cmd/elf.c | 34 ++
>  1 file changed, 34 insertions(+)
> 
> diff --git a/cmd/elf.c b/cmd/elf.c
> index 501f935..91a04da 100644
> --- a/cmd/elf.c
> +++ b/cmd/elf.c
> @@ -24,6 +24,37 @@
>  #endif
>  
>  /*
> + * A very simple elf64 loader, assumes the image is valid, returns the
> + * entry point address.
> + */
> +static unsigned long load_elf64_image_phdr(unsigned long addr)
> +{
> + Elf64_Ehdr *ehdr; /* Elf header structure pointer */
> + Elf64_Phdr *phdr; /* Program header structure pointer */
> + int i;
> +
> + ehdr = (Elf64_Ehdr *)addr;
> + phdr = (Elf64_Phdr *)(addr + (ulong)ehdr->e_phoff);
> +
> + /* Load each program header */
> + for (i = 0; i < ehdr->e_phnum; ++i) {
> + void *dst = (void *)(ulong)phdr->p_paddr;
> + void *src = (void *)addr + phdr->p_offset;
> + debug("Loading phdr %i to 0x%p (%lu bytes)\n",
> +   i, dst, (ulong)phdr->p_filesz);
> + if (phdr->p_filesz)
> + memcpy(dst, src, phdr->p_filesz);
> + if (phdr->p_filesz != phdr->p_memsz)
> + memset(dst + phdr->p_filesz, 0x00,
> +phdr->p_memsz - phdr->p_filesz);
> + flush_cache((unsigned long)dst, phdr->p_filesz);
> + ++phdr;
> + }
> +
> + return ehdr->e_entry;
> +}
> +
> +/*
>   * A very simple elf loader, assumes the image is valid, returns the
Would it be good to modify this comment to indicate elf32 loader?
>   * entry point address.
>   */
> @@ -34,6 +65,9 @@ static unsigned long load_elf_image_phdr(unsigned long addr)
>   int i;
>  
>   ehdr = (Elf32_Ehdr *)addr;
> + if (ehdr->e_ident[EI_CLASS] == ELFCLASS64)
> + return load_elf64_image_phdr(addr);
> +
>   phdr = (Elf32_Phdr *)(addr + ehdr->e_phoff);
>  
>   /* Load each program header */
> -- 
> 2.7.4
> 
> ___
> 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] arm: socfpga: unable to boot cyclone5 devkit or SocKit

[Dinh Nguyen]

On 04/10/2018 01:29 PM, Marek Vasut wrote:
> On 04/10/2018 08:28 PM, Dinh Nguyen wrote:
>> Hi,
>>
>> I'm seeking advice with an observation that I'm seeing on the Cyclone5
>> devkit/sockit.
>>
>> I'm working with U-Boot version v2018.05-rc1. Building the
>> u-boot-with-spl.sfp, then writing the sfp file to the 0xa2 partition on
>> the SD card, does not boot, all I get is this:
>>
>> U-Boot SPL 2018.05-rc1 (Apr 10 2018 - 13:03:48 -0500)
>>
>> U-Boot SPL 2018.05-rc1 (Apr 10 2018 - 13:03:48 -0500)
>>
>> U-Boot SPL 2018.05-rc1 (Apr 10 2018 - 13:03:48 -0500)
>>
>>
>> This issue doesn't happen at all on the DE0 Nano SoC board. I compared
>> the defconfig and came across this. If I remove these config options in
>> the socfpga_sockit_defconfig, then SPL -> U-Boot works fine.
>>
>> -CONFIG_SPI_FLASH_MACRONIX=y
>> -CONFIG_SPI_FLASH_SPANSION=y
>> -CONFIG_SPI_FLASH_STMICRO=y
>>
>> I'll continue to debug of course, but was wondering if anyone might have
>> a better idea as to what could be happening, I'd appreciate the insight.
> 
> Check the size of the SPL , could it be too big ?
> 

That's a good thought...it could be. The size of the default
u-boot-spl-dtb.bin is 58048, removing the SPI, brings that down to
55616, that's smaller than the 64k of OCRAM for SPL?

Dinh







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

Re: [U-Boot] arm: socfpga: unable to boot cyclone5 devkit or SocKit

[Marek Vasut]

On 04/10/2018 08:28 PM, Dinh Nguyen wrote:
> Hi,
> 
> I'm seeking advice with an observation that I'm seeing on the Cyclone5
> devkit/sockit.
> 
> I'm working with U-Boot version v2018.05-rc1. Building the
> u-boot-with-spl.sfp, then writing the sfp file to the 0xa2 partition on
> the SD card, does not boot, all I get is this:
> 
> U-Boot SPL 2018.05-rc1 (Apr 10 2018 - 13:03:48 -0500)
> 
> U-Boot SPL 2018.05-rc1 (Apr 10 2018 - 13:03:48 -0500)
> 
> U-Boot SPL 2018.05-rc1 (Apr 10 2018 - 13:03:48 -0500)
> 
> 
> This issue doesn't happen at all on the DE0 Nano SoC board. I compared
> the defconfig and came across this. If I remove these config options in
> the socfpga_sockit_defconfig, then SPL -> U-Boot works fine.
> 
> -CONFIG_SPI_FLASH_MACRONIX=y
> -CONFIG_SPI_FLASH_SPANSION=y
> -CONFIG_SPI_FLASH_STMICRO=y
> 
> I'll continue to debug of course, but was wondering if anyone might have
> a better idea as to what could be happening, I'd appreciate the insight.

Check the size of the SPL , could it be too big ?

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

[U-Boot] arm: socfpga: unable to boot cyclone5 devkit or SocKit

[Dinh Nguyen]

Hi,

I'm seeking advice with an observation that I'm seeing on the Cyclone5
devkit/sockit.

I'm working with U-Boot version v2018.05-rc1. Building the
u-boot-with-spl.sfp, then writing the sfp file to the 0xa2 partition on
the SD card, does not boot, all I get is this:

U-Boot SPL 2018.05-rc1 (Apr 10 2018 - 13:03:48 -0500)

U-Boot SPL 2018.05-rc1 (Apr 10 2018 - 13:03:48 -0500)

U-Boot SPL 2018.05-rc1 (Apr 10 2018 - 13:03:48 -0500)


This issue doesn't happen at all on the DE0 Nano SoC board. I compared
the defconfig and came across this. If I remove these config options in
the socfpga_sockit_defconfig, then SPL -> U-Boot works fine.

-CONFIG_SPI_FLASH_MACRONIX=y
-CONFIG_SPI_FLASH_SPANSION=y
-CONFIG_SPI_FLASH_STMICRO=y

I'll continue to debug of course, but was wondering if anyone might have
a better idea as to what could be happening, I'd appreciate the insight.

Dinh


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

[U-Boot] arm: socfpga: unable to boot cyclone5 devkit or SocKit

[Dinh Nguyen]

Hi,

I'm seeking advice with an observation that I'm seeing on the Cyclone5
devkit/sockit.

I'm working with U-Boot version v2018.05-rc1. Building the
u-boot-with-spl.sfp, then writing the sfp file to the 0xa2 partition on
the SD card, does not boot, all I get is this:

U-Boot SPL 2018.05-rc1 (Apr 10 2018 - 13:03:48 -0500)

U-Boot SPL 2018.05-rc1 (Apr 10 2018 - 13:03:48 -0500)

U-Boot SPL 2018.05-rc1 (Apr 10 2018 - 13:03:48 -0500)


This issue doesn't happen at all on the DE0 Nano SoC board. I compared
the defconfig and came across this. If I remove these config options in
the socfpga_sockit_defconfig, then SPL -> U-Boot works fine.

-CONFIG_SPI_FLASH_MACRONIX=y
-CONFIG_SPI_FLASH_SPANSION=y
-CONFIG_SPI_FLASH_STMICRO=y

I'll continue to debug of course, but was wondering if anyone might have
a better idea as to what could be happening, I'd appreciate the insight.

Dinh


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

Re: [U-Boot] [PATCH] configs: Fixup some CPSW-related items

[Felix Brack]

On 10.04.2018 17:51, Tom Rini wrote:
> - For am335x_pdu001 we do not want the CPSW driver, drop it
> - Re-sync the defconfig for am43xx_evm_rtconly as it came in after the
>   patch that converted CPSW to Kconfig was posted but before it was
>   applied.
> - Drop empty section / comments from pengwyn
> - Drop empty section / comments from baltos and drop unused
>   CONFIG_SPL_NET_VCI_STRING (it does not enable CONFIG_SPL_NET_SUPPORT
>   currently and SPL_NET_VCI_STRING has been migrated already).
> 
> Cc: Felix Brack 
> Cc: Lokesh Vutla 
> Cc: Yegor Yefremov 
> Cc: Lothar Felten 
> Fixes: f02b8d17619f ("Migrate CONFIG_DRIVER_TI_CPSW to Kconfig")
> Signed-off-by: Tom Rini 
> ---
>  configs/am335x_pdu001_defconfig  |  1 -
>  configs/am43xx_evm_rtconly_defconfig |  2 +-
>  include/configs/baltos.h | 13 -
>  include/configs/pengwyn.h|  7 ---
>  4 files changed, 1 insertion(+), 22 deletions(-)
>


Reviewed-by: Felix Brack 
and for the PDU001 board related part
Tested-by: Felix Brack 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v3, 3/3] dm: led: add testcase for "default-state" property

[Tom Rini]

On Wed, Apr 04, 2018 at 10:01:03AM +0200, linux-kernel-...@beckhoff.com wrote:

> From: Patrick Bruenn 
> 
> Add two more gpio-leds to sandbox test device tree with default-state
> property set to "on"/"off".
> Add dm_test_led_default_state() to check that these new LED's are set to
> LEDST_ON and LEDST_OFF.
> 
> Signed-off-by: Patrick Bruenn 
> Reviewed-by: Simon Glass 
> ---
> patman complains about: test/dm/led.c:45: check: Please use a blank line
> after function/struct/union/enum declarations.
> I compared with other DM_TEST() usage and decided to ignore this check.
> Should we fix the macro, patman or keep ignoring this?

This breaks tests actually, please try running 'make tests' after this
(and the rest of your series) is applied, 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 1/1] mmc: avoid division by zero in meson_mmc_config_clock - Please, consider for v2018.05-rc2

[Heinrich Schuchardt]

On 03/24/2018 03:57 PM, Heinrich Schuchardt wrote:
> On 03/18/2018 01:03 AM, Vagrant Cascadian wrote:
>> On 2018-03-17, Heinrich Schuchardt wrote:
>>> The Odroid C2 fails to read from mmc with U-Boot v2018.03.
>>> The change avoids a division by zero.
>>>
>>> The fix was suggested by Jaehoon in
>>> https://lists.denx.de/pipermail/u-boot/2018-January/318577.html
>>
>> Thanks!
>>
>> Works for me with odroid-c2 on u-boot 2018.03.
>>
>> Without the patch, mmc access immediately hangs the board.
>>
>> Tested-by: Vagrant Cascadian 
>>
>>
>> live well,
>>   vagrant
>>
>>> Reported-by: Vagrant Cascadian 
>>> Suggested-by: Jaehoon Chung 
>>> Signed-off-by: Heinrich Schuchardt 
>>> ---
>>> Resent due to missing cc u-boot@lists.denx.de.
>>> ---
>>>  drivers/mmc/meson_gx_mmc.c | 3 +++
>>>  1 file changed, 3 insertions(+)
>>>
>>> diff --git a/drivers/mmc/meson_gx_mmc.c b/drivers/mmc/meson_gx_mmc.c
>>> index a2cd5d3a44..454593eec4 100644
>>> --- a/drivers/mmc/meson_gx_mmc.c
>>> +++ b/drivers/mmc/meson_gx_mmc.c
>>> @@ -35,6 +35,9 @@ static void meson_mmc_config_clock(struct mmc *mmc)
>>> uint32_t meson_mmc_clk = 0;
>>> unsigned int clk, clk_src, clk_div;
>>>  
>>> +   if (!mmc->clock)
>>> +   return;
>>> +
>>> /* 1GHz / CLK_MAX_DIV = 15,9 MHz */
>>> if (mmc->clock > 1600) {
>>> clk = SD_EMMC_CLKSRC_DIV2;
>>> -- 
>>> 2.14.2
> 
> Hello Jaehoon,
> 
> will you pick the patch?
> 
> Best regards
> 
> Heinrich
> 

Hello Jaehoon,

since v2018.03 the Odroid C2 cannot be booted with U-Boot. This patch
fixes it and has been adopted by Debian:
https://packages.debian.org/de/buster/u-boot

Could you, please, consider it for v2018.05-rc2.

Best regards

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

[U-Boot] [PATCH] configs: Fixup some CPSW-related items

[Tom Rini]

- For am335x_pdu001 we do not want the CPSW driver, drop it
- Re-sync the defconfig for am43xx_evm_rtconly as it came in after the
  patch that converted CPSW to Kconfig was posted but before it was
  applied.
- Drop empty section / comments from pengwyn
- Drop empty section / comments from baltos and drop unused
  CONFIG_SPL_NET_VCI_STRING (it does not enable CONFIG_SPL_NET_SUPPORT
  currently and SPL_NET_VCI_STRING has been migrated already).

Cc: Felix Brack 
Cc: Lokesh Vutla 
Cc: Yegor Yefremov 
Cc: Lothar Felten 
Fixes: f02b8d17619f ("Migrate CONFIG_DRIVER_TI_CPSW to Kconfig")
Signed-off-by: Tom Rini 
---
 configs/am335x_pdu001_defconfig  |  1 -
 configs/am43xx_evm_rtconly_defconfig |  2 +-
 include/configs/baltos.h | 13 -
 include/configs/pengwyn.h|  7 ---
 4 files changed, 1 insertion(+), 22 deletions(-)

diff --git a/configs/am335x_pdu001_defconfig b/configs/am335x_pdu001_defconfig
index 87ae88ca6173..a9d0f8e01678 100644
--- a/configs/am335x_pdu001_defconfig
+++ b/configs/am335x_pdu001_defconfig
@@ -39,7 +39,6 @@ CONFIG_DM_GPIO=y
 CONFIG_DM_I2C=y
 CONFIG_MMC_OMAP_HS=y
 CONFIG_MMC_SDHCI=y
-CONFIG_DRIVER_TI_CPSW=y
 CONFIG_PINCTRL=y
 CONFIG_PINCTRL_SINGLE=y
 CONFIG_DM_PMIC=y
diff --git a/configs/am43xx_evm_rtconly_defconfig 
b/configs/am43xx_evm_rtconly_defconfig
index f37ceb064be3..339a1c6fc393 100644
--- a/configs/am43xx_evm_rtconly_defconfig
+++ b/configs/am43xx_evm_rtconly_defconfig
@@ -37,7 +37,7 @@ CONFIG_MMC_OMAP_HS=y
 CONFIG_NAND=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_MACRONIX=y
-CONFIG_PHYLIB=y
+CONFIG_DRIVER_TI_CPSW=y
 CONFIG_PHY_GIGE=y
 CONFIG_DM_SERIAL=y
 CONFIG_SYS_NS16550=y
diff --git a/include/configs/baltos.h b/include/configs/baltos.h
index 19db35052e9e..03559bd4f5f6 100644
--- a/include/configs/baltos.h
+++ b/include/configs/baltos.h
@@ -229,11 +229,6 @@
 /* SPL */
 #ifndef CONFIG_NOR_BOOT
 
-/* USB gadget RNDIS */
-
-/* General network SPL, both CPSW and USB gadget RNDIS */
-#define CONFIG_SPL_NET_VCI_STRING  "AM335x U-Boot SPL"*/
-
 #ifdef CONFIG_NAND
 #define CONFIG_SYS_NAND_5_ADDR_CYCLE
 #define CONFIG_SYS_NAND_PAGE_COUNT (CONFIG_SYS_NAND_BLOCK_SIZE / \
@@ -271,14 +266,6 @@
 #define CONFIG_AM335X_USB1
 #define CONFIG_AM335X_USB1_MODE MUSB_OTG
 
-#if defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_USB_ETHER)
-/* disable host part of MUSB in SPL */
-/* disable EFI partitions and partition UUID support */
-/*
- * Disable CPSW SPL support so we fit within the 101KiB limit.
- */
-#endif
-
 /* Network. */
 #define CONFIG_PHY_SMSC
 #define CONFIG_MII
diff --git a/include/configs/pengwyn.h b/include/configs/pengwyn.h
index 545f859e8587..863b6e7eb451 100644
--- a/include/configs/pengwyn.h
+++ b/include/configs/pengwyn.h
@@ -165,16 +165,9 @@
 #define CONFIG_AM335X_USB1
 #define CONFIG_AM335X_USB1_MODE MUSB_HOST
 
-#if defined(CONFIG_SPL_BUILD)
-/* disable host part of MUSB in SPL */
-/* Disable CPSW SPL support so we fit within the 101KiB limit. */
-#endif
-
 /* Network */
 #define CONFIG_PHY_RESET   1
 #define CONFIG_PHY_NATSEMI
 #define CONFIG_PHY_REALTEK
 
-/* CPSW support */
-
 #endif /* ! __CONFIG_PENGWYN_H */
-- 
2.7.4

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

Re: [U-Boot] [PATCH 1/1] log: fix typo LOGL_EFI - Please, pick for v2018.05-rc2

[Heinrich Schuchardt]

On 03/30/2018 10:42 AM, Simon Glass wrote:
> On 24 March 2018 at 04:12, Heinrich Schuchardt  wrote:
>> According to the documentation the EFI log category is called LOGC_EFI.
>> All other categories start with LOGC_. So let's fix it.
>>
>> Fixes: 1973b381a1b3 ("log: add category LOGC_EFI")
>> Signed-off-by: Heinrich Schuchardt 
>> ---
>>  include/log.h | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Reviewed-by: Simon Glass 
> 
Hello Alex,

in patchwork the patch is assigned to you.
https://patchwork.ozlabs.org/patch/890199/

Could you, please, pick it for v2018.05-rc2.

Best regards

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

Re: [U-Boot] [U-Boot, v2, 1/5] Migrate CONFIG_DRIVER_TI_CPSW to Kconfig

[Felix Brack]

On 10.04.2018 17:30, Tom Rini wrote:
> On Tue, Apr 10, 2018 at 05:26:25PM +0200, Felix Brack wrote:
>> On 10.04.2018 16:50, Tom Rini wrote:
>>> On Tue, Apr 10, 2018 at 04:11:09PM +0200, Felix Brack wrote:
 On 10.04.2018 15:30, Tom Rini wrote:
> On Tue, Apr 10, 2018 at 02:59:23PM +0200, Felix Brack wrote:
>> On 10.04.2018 14:54, Tom Rini wrote:
>>> On Tue, Apr 10, 2018 at 02:43:47PM +0200, Felix Brack wrote:
 On 10.04.2018 14:23, Tom Rini wrote:
> On Tue, Apr 10, 2018 at 09:21:06AM +0200, Felix Brack wrote:
>> Hi Tom,
>>
>> On 09.04.2018 17:03, Tom Rini wrote:
>>> On Sun, Apr 01, 2018 at 09:22:34AM +, Alex Kiernan wrote:
>>>
 This converts CONFIG_DRIVER_TI_CPSW to Kconfig

 Signed-off-by: Alex Kiernan 
 Acked-by: Joe Hershberger 
>>>
>>> Applied to u-boot/master, thanks!
>>
>> Why did you apply this patch? It introduces a build warning?
>
> Wait, where does it introduce a warning?  Thanks!
>
 Please see my post from April 2nd on top of this thread in reply to
 "[PATCH v2 1/5] Migrate CONFIG_DRIVER_TI_CPSW to Kconfig".
 It is identical to the warning that shows up in the log provide by
 Alex's link: https://travis-ci.org/akiernan/u-boot/jobs/360830565#L962.
>>>
>>> Ahhh.  Doesn't fail travis and I had a local goof-up and missed it in
>>> my build logs.  Sorry.  Now, you have the CPSW driver enabled, but don't
>>> want NET?  Or am I misunderstanding?  Thanks!
>>
>> Exactly, the board doesn't need NET.
>
> But then what are you using the CPSW driver for?
>
 I don't really understand your question. This patch is from Alex, i.e. I
 am not the author of the patch. I never asked for CPSW driver support
 for the PDU001 board. Here is what I wrote April 2nd:

 [quote on]
 Applying this patch series generates the following warning while
 creating the default configuration for board PDU001:

 warning: (BOARD_SPECIFIC_OPTIONS && BOARD_SPECIFIC_OPTIONS &&
 BOARD_SPECIFIC_OPTIONS && BOARD_SPECIFIC_OPTIONS && DRIVER_TI_CPSW &&
 AG7XXX && ALTERA_TSE && BCM_SF2_ETH && DWC_ETH_QOS && ETH_DESIGNWARE &&
 MVNETA && MVPP2 && MACB && PCH_GBE && SUN4I_EMAC && SUN8I_EMAC &&
 SH_ETHER && XILINX_AXIEMAC && XILINX_EMACLITE && ZYNQ_GEM && PIC32_ETH
 && RENESAS_RAVB) selects PHYLIB which has unmet direct dependencies (NET)

 This is due to the patch enabling CONFIG_DRIVER_TI_CPSW while leaving
 CONFIG_NET disabled.
 This board does not require/have network support for U-Boot so there is
 no need or benefit activating CONFIG_DRIVER_TI_CPSW here. Leaving the
 file configs/am355x_pdu001_defconfig without any modifications will make
 your patch work properly and result in a clean, warning and error free,
 build for the PDU001 board.
 [quote off]

 So the solution for the PDU001 board warning problem is _not_ to add NET
 but to remove CPSW. This leaves the file configs/am355x_pdu001_defconfig
 unchanged by this patch and that is what I suggested as solution.
 In other words: the PDU001 board (for now) does not provide any network
 support in U-Boot.
>>>
>>> So, ah-ha-ha! At heart, include/configs/pdu001.h grabs
>>> include/configs/ti_am335x_common.h which was always enabling the CPSW
>>> driver.  So the migration picked that up.  But since you're saying your
>>> platform does not want CPSW, we can just drop that now.  Thanks!
>>>
>> Ah, so you're going to drop configs/am355x_pdu001_defconfig from the
>> patch, correct?
> 
> I'm dropping that hunk out, and a few other small clean-ups
> (am43xx_evm_rtconly is out of sync, and there's a few places with
> non-applicable CPSW comments blocks now).
> 
Okay, sounds good. Please CC me for the modified patch.

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

Re: [U-Boot] [U-Boot, v2, 1/5] Migrate CONFIG_DRIVER_TI_CPSW to Kconfig

[Tom Rini]

On Tue, Apr 10, 2018 at 05:26:25PM +0200, Felix Brack wrote:
> On 10.04.2018 16:50, Tom Rini wrote:
> > On Tue, Apr 10, 2018 at 04:11:09PM +0200, Felix Brack wrote:
> >> On 10.04.2018 15:30, Tom Rini wrote:
> >>> On Tue, Apr 10, 2018 at 02:59:23PM +0200, Felix Brack wrote:
>  On 10.04.2018 14:54, Tom Rini wrote:
> > On Tue, Apr 10, 2018 at 02:43:47PM +0200, Felix Brack wrote:
> >> On 10.04.2018 14:23, Tom Rini wrote:
> >>> On Tue, Apr 10, 2018 at 09:21:06AM +0200, Felix Brack wrote:
>  Hi Tom,
> 
>  On 09.04.2018 17:03, Tom Rini wrote:
> > On Sun, Apr 01, 2018 at 09:22:34AM +, Alex Kiernan wrote:
> >
> >> This converts CONFIG_DRIVER_TI_CPSW to Kconfig
> >>
> >> Signed-off-by: Alex Kiernan 
> >> Acked-by: Joe Hershberger 
> >
> > Applied to u-boot/master, thanks!
> 
>  Why did you apply this patch? It introduces a build warning?
> >>>
> >>> Wait, where does it introduce a warning?  Thanks!
> >>>
> >> Please see my post from April 2nd on top of this thread in reply to
> >> "[PATCH v2 1/5] Migrate CONFIG_DRIVER_TI_CPSW to Kconfig".
> >> It is identical to the warning that shows up in the log provide by
> >> Alex's link: https://travis-ci.org/akiernan/u-boot/jobs/360830565#L962.
> >
> > Ahhh.  Doesn't fail travis and I had a local goof-up and missed it in
> > my build logs.  Sorry.  Now, you have the CPSW driver enabled, but don't
> > want NET?  Or am I misunderstanding?  Thanks!
> 
>  Exactly, the board doesn't need NET.
> >>>
> >>> But then what are you using the CPSW driver for?
> >>>
> >> I don't really understand your question. This patch is from Alex, i.e. I
> >> am not the author of the patch. I never asked for CPSW driver support
> >> for the PDU001 board. Here is what I wrote April 2nd:
> >>
> >> [quote on]
> >> Applying this patch series generates the following warning while
> >> creating the default configuration for board PDU001:
> >>
> >> warning: (BOARD_SPECIFIC_OPTIONS && BOARD_SPECIFIC_OPTIONS &&
> >> BOARD_SPECIFIC_OPTIONS && BOARD_SPECIFIC_OPTIONS && DRIVER_TI_CPSW &&
> >> AG7XXX && ALTERA_TSE && BCM_SF2_ETH && DWC_ETH_QOS && ETH_DESIGNWARE &&
> >> MVNETA && MVPP2 && MACB && PCH_GBE && SUN4I_EMAC && SUN8I_EMAC &&
> >> SH_ETHER && XILINX_AXIEMAC && XILINX_EMACLITE && ZYNQ_GEM && PIC32_ETH
> >> && RENESAS_RAVB) selects PHYLIB which has unmet direct dependencies (NET)
> >>
> >> This is due to the patch enabling CONFIG_DRIVER_TI_CPSW while leaving
> >> CONFIG_NET disabled.
> >> This board does not require/have network support for U-Boot so there is
> >> no need or benefit activating CONFIG_DRIVER_TI_CPSW here. Leaving the
> >> file configs/am355x_pdu001_defconfig without any modifications will make
> >> your patch work properly and result in a clean, warning and error free,
> >> build for the PDU001 board.
> >> [quote off]
> >>
> >> So the solution for the PDU001 board warning problem is _not_ to add NET
> >> but to remove CPSW. This leaves the file configs/am355x_pdu001_defconfig
> >> unchanged by this patch and that is what I suggested as solution.
> >> In other words: the PDU001 board (for now) does not provide any network
> >> support in U-Boot.
> > 
> > So, ah-ha-ha! At heart, include/configs/pdu001.h grabs
> > include/configs/ti_am335x_common.h which was always enabling the CPSW
> > driver.  So the migration picked that up.  But since you're saying your
> > platform does not want CPSW, we can just drop that now.  Thanks!
> > 
> Ah, so you're going to drop configs/am355x_pdu001_defconfig from the
> patch, correct?

I'm dropping that hunk out, and a few other small clean-ups
(am43xx_evm_rtconly is out of sync, and there's a few places with
non-applicable CPSW comments blocks now).

-- 
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] [U-Boot, v2, 1/5] Migrate CONFIG_DRIVER_TI_CPSW to Kconfig

[Felix Brack]

On 10.04.2018 16:50, Tom Rini wrote:
> On Tue, Apr 10, 2018 at 04:11:09PM +0200, Felix Brack wrote:
>> On 10.04.2018 15:30, Tom Rini wrote:
>>> On Tue, Apr 10, 2018 at 02:59:23PM +0200, Felix Brack wrote:
 On 10.04.2018 14:54, Tom Rini wrote:
> On Tue, Apr 10, 2018 at 02:43:47PM +0200, Felix Brack wrote:
>> On 10.04.2018 14:23, Tom Rini wrote:
>>> On Tue, Apr 10, 2018 at 09:21:06AM +0200, Felix Brack wrote:
 Hi Tom,

 On 09.04.2018 17:03, Tom Rini wrote:
> On Sun, Apr 01, 2018 at 09:22:34AM +, Alex Kiernan wrote:
>
>> This converts CONFIG_DRIVER_TI_CPSW to Kconfig
>>
>> Signed-off-by: Alex Kiernan 
>> Acked-by: Joe Hershberger 
>
> Applied to u-boot/master, thanks!

 Why did you apply this patch? It introduces a build warning?
>>>
>>> Wait, where does it introduce a warning?  Thanks!
>>>
>> Please see my post from April 2nd on top of this thread in reply to
>> "[PATCH v2 1/5] Migrate CONFIG_DRIVER_TI_CPSW to Kconfig".
>> It is identical to the warning that shows up in the log provide by
>> Alex's link: https://travis-ci.org/akiernan/u-boot/jobs/360830565#L962.
>
> Ahhh.  Doesn't fail travis and I had a local goof-up and missed it in
> my build logs.  Sorry.  Now, you have the CPSW driver enabled, but don't
> want NET?  Or am I misunderstanding?  Thanks!

 Exactly, the board doesn't need NET.
>>>
>>> But then what are you using the CPSW driver for?
>>>
>> I don't really understand your question. This patch is from Alex, i.e. I
>> am not the author of the patch. I never asked for CPSW driver support
>> for the PDU001 board. Here is what I wrote April 2nd:
>>
>> [quote on]
>> Applying this patch series generates the following warning while
>> creating the default configuration for board PDU001:
>>
>> warning: (BOARD_SPECIFIC_OPTIONS && BOARD_SPECIFIC_OPTIONS &&
>> BOARD_SPECIFIC_OPTIONS && BOARD_SPECIFIC_OPTIONS && DRIVER_TI_CPSW &&
>> AG7XXX && ALTERA_TSE && BCM_SF2_ETH && DWC_ETH_QOS && ETH_DESIGNWARE &&
>> MVNETA && MVPP2 && MACB && PCH_GBE && SUN4I_EMAC && SUN8I_EMAC &&
>> SH_ETHER && XILINX_AXIEMAC && XILINX_EMACLITE && ZYNQ_GEM && PIC32_ETH
>> && RENESAS_RAVB) selects PHYLIB which has unmet direct dependencies (NET)
>>
>> This is due to the patch enabling CONFIG_DRIVER_TI_CPSW while leaving
>> CONFIG_NET disabled.
>> This board does not require/have network support for U-Boot so there is
>> no need or benefit activating CONFIG_DRIVER_TI_CPSW here. Leaving the
>> file configs/am355x_pdu001_defconfig without any modifications will make
>> your patch work properly and result in a clean, warning and error free,
>> build for the PDU001 board.
>> [quote off]
>>
>> So the solution for the PDU001 board warning problem is _not_ to add NET
>> but to remove CPSW. This leaves the file configs/am355x_pdu001_defconfig
>> unchanged by this patch and that is what I suggested as solution.
>> In other words: the PDU001 board (for now) does not provide any network
>> support in U-Boot.
> 
> So, ah-ha-ha! At heart, include/configs/pdu001.h grabs
> include/configs/ti_am335x_common.h which was always enabling the CPSW
> driver.  So the migration picked that up.  But since you're saying your
> platform does not want CPSW, we can just drop that now.  Thanks!
> 
Ah, so you're going to drop configs/am355x_pdu001_defconfig from the
patch, correct?

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

Re: [U-Boot] [PATCH v2 1/2] spi: zynqmp_qspi: Add support for ZynqMP qspi driver

[Liam Beguin]

Hi Siva,

I've been working on a patch to add support for io-mode [1].
It's based on xilinx/master which is closer to v1 (no include file).
I haven't had much time to test it further but I can load a bitstream
from a ubifs partition with it.
Let me know if you have comments.

On Tue, 10 Apr 2018 at 02:27 Siva Durga Prasad Paladugu 
wrote:

> H Jagan,
>
> Any further comments on this. I am waiting for your reply on some of my
> replies to your comment.
>
> Thanks,
> Siva
>
>
Thanks,
Liam

[1] https://github.com/Liambeguin/u-boot/tree/io-mode
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 4/4] spi: sh_qspi: Make use of the 32byte FIFO

[Marek Vasut]

The QSPI controller on RCar Gen2 has 32byte FIFO. Instead of doing
the SPI transmission 1 byte at time, if there is a 32byte chunk of
data to be transferred, fill the FIFO completely and then transfer
the data to/from the FIFO. This increases the SPI NOR access speed
significantly.

Signed-off-by: Marek Vasut 
Cc: Nobuhiro Iwamatsu 
---
 drivers/spi/sh_qspi.c | 34 --
 1 file changed, 24 insertions(+), 10 deletions(-)

diff --git a/drivers/spi/sh_qspi.c b/drivers/spi/sh_qspi.c
index d7f558a541..5075be3cd1 100644
--- a/drivers/spi/sh_qspi.c
+++ b/drivers/spi/sh_qspi.c
@@ -36,6 +36,8 @@
SPCMD_BRDV0
 #define SPBFCR_TXRST   BIT(7)
 #define SPBFCR_RXRST   BIT(6)
+#define SPBFCR_TXTRG   0x30
+#define SPBFCR_RXTRG   0x07
 
 /* SH QSPI register set */
 struct sh_qspi_regs {
@@ -201,8 +203,8 @@ int spi_xfer(struct spi_slave *slave, unsigned int bitlen, 
const void *dout,
 void *din, unsigned long flags)
 {
struct sh_qspi_slave *ss = to_sh_qspi(slave);
-   u32 nbyte;
-   int ret = 0;
+   u32 nbyte, chunk;
+   int i, ret = 0;
u8 dtdata = 0, drdata;
u8 *tdata = , *rdata = 
u32 *spbmul0 = >regs->spbmul0;
@@ -237,26 +239,38 @@ int spi_xfer(struct spi_slave *slave, unsigned int 
bitlen, const void *dout,
rdata = din;
 
while (nbyte > 0) {
+   /*
+* Check if there is 32 Byte chunk and if there is, transfer
+* it in one burst, otherwise transfer on byte-by-byte basis.
+*/
+   chunk = (nbyte >= 32) ? 32 : 1;
+
+   clrsetbits_8(>regs->spbfcr, SPBFCR_TXTRG | SPBFCR_RXTRG,
+chunk == 32 ? SPBFCR_TXTRG | SPBFCR_RXTRG : 0);
+
ret = wait_for_bit_8(>regs->spsr, SPSR_SPTEF,
 true, 1000, true);
if (ret)
return ret;
 
-   writeb(*tdata, (u8 *)(>regs->spdr));
+   for (i = 0; i < chunk; i++) {
+   writeb(*tdata, >regs->spdr);
+   if (dout != NULL)
+   tdata++;
+   }
 
ret = wait_for_bit_8(>regs->spsr, SPSR_SPRFF,
 true, 1000, true);
if (ret)
return ret;
 
-   *rdata = readb((u8 *)(>regs->spdr));
-
-   if (dout != NULL)
-   tdata++;
-   if (din != NULL)
-   rdata++;
+   for (i = 0; i < chunk; i++) {
+   *rdata = readb(>regs->spdr);
+   if (din != NULL)
+   rdata++;
+   }
 
-   nbyte--;
+   nbyte -= chunk;
}
 
if (flags & SPI_XFER_END)
-- 
2.16.2

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

[U-Boot] [PATCH 1/4] spi: sh_qspi: Replace data types with short ones

[Marek Vasut]

Just replace unsigned {char,short,long} with u{8,16,32},
no functional change.

Signed-off-by: Marek Vasut 
Cc: Nobuhiro Iwamatsu 
---
 drivers/spi/sh_qspi.c | 62 +--
 1 file changed, 31 insertions(+), 31 deletions(-)

diff --git a/drivers/spi/sh_qspi.c b/drivers/spi/sh_qspi.c
index 75999c812d..fc0e1fc336 100644
--- a/drivers/spi/sh_qspi.c
+++ b/drivers/spi/sh_qspi.c
@@ -38,30 +38,30 @@
 
 /* SH QSPI register set */
 struct sh_qspi_regs {
-   unsigned char spcr;
-   unsigned char sslp;
-   unsigned char sppcr;
-   unsigned char spsr;
-   unsigned long spdr;
-   unsigned char spscr;
-   unsigned char spssr;
-   unsigned char spbr;
-   unsigned char spdcr;
-   unsigned char spckd;
-   unsigned char sslnd;
-   unsigned char spnd;
-   unsigned char dummy0;
-   unsigned short spcmd0;
-   unsigned short spcmd1;
-   unsigned short spcmd2;
-   unsigned short spcmd3;
-   unsigned char spbfcr;
-   unsigned char dummy1;
-   unsigned short spbdcr;
-   unsigned long spbmul0;
-   unsigned long spbmul1;
-   unsigned long spbmul2;
-   unsigned long spbmul3;
+   u8  spcr;
+   u8  sslp;
+   u8  sppcr;
+   u8  spsr;
+   u32 spdr;
+   u8  spscr;
+   u8  spssr;
+   u8  spbr;
+   u8  spdcr;
+   u8  spckd;
+   u8  sslnd;
+   u8  spnd;
+   u8  dummy0;
+   u16 spcmd0;
+   u16 spcmd1;
+   u16 spcmd2;
+   u16 spcmd3;
+   u8  spbfcr;
+   u8  dummy1;
+   u16 spbdcr;
+   u32 spbmul0;
+   u32 spbmul1;
+   u32 spbmul2;
+   u32 spbmul3;
 };
 
 struct sh_qspi_slave {
@@ -200,11 +200,11 @@ int spi_xfer(struct spi_slave *slave, unsigned int 
bitlen, const void *dout,
 void *din, unsigned long flags)
 {
struct sh_qspi_slave *ss = to_sh_qspi(slave);
-   unsigned long nbyte;
+   u32 nbyte;
int ret = 0;
-   unsigned char dtdata = 0, drdata;
-   unsigned char *tdata = , *rdata = 
-   unsigned long *spbmul0 = >regs->spbmul0;
+   u8 dtdata = 0, drdata;
+   u8 *tdata = , *rdata = 
+   u32 *spbmul0 = >regs->spbmul0;
 
if (dout == NULL && din == NULL) {
if (flags & SPI_XFER_END)
@@ -230,7 +230,7 @@ int spi_xfer(struct spi_slave *slave, unsigned int bitlen, 
const void *dout,
writel(nbyte, spbmul0);
 
if (dout != NULL)
-   tdata = (unsigned char *)dout;
+   tdata = (u8 *)dout;
 
if (din != NULL)
rdata = din;
@@ -244,7 +244,7 @@ int spi_xfer(struct spi_slave *slave, unsigned int bitlen, 
const void *dout,
udelay(10);
}
 
-   writeb(*tdata, (unsigned char *)(>regs->spdr));
+   writeb(*tdata, (u8 *)(>regs->spdr));
 
while ((readw(>regs->spbdcr) != SPBDCR_RXBC0)) {
if (ctrlc()) {
@@ -262,7 +262,7 @@ int spi_xfer(struct spi_slave *slave, unsigned int bitlen, 
const void *dout,
udelay(10);
}
 
-   *rdata = readb((unsigned char *)(>regs->spdr));
+   *rdata = readb((u8 *)(>regs->spdr));
 
if (dout != NULL)
tdata++;
-- 
2.16.2

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

[U-Boot] [PATCH 3/4] spi: sh_qspi: Replace ad hoc waiting with wait_for_bit

[Marek Vasut]

Replace the ad-hoc endless loops with wait_for_bit() with
reasonable timeout. Note that the loops had internal 10uS
delays, although there is no reason for those on this HW,
so they are dropped.

Signed-off-by: Marek Vasut 
Cc: Nobuhiro Iwamatsu 
---
 drivers/spi/sh_qspi.c | 23 +--
 1 file changed, 9 insertions(+), 14 deletions(-)

diff --git a/drivers/spi/sh_qspi.c b/drivers/spi/sh_qspi.c
index 8eaa6744cc..d7f558a541 100644
--- a/drivers/spi/sh_qspi.c
+++ b/drivers/spi/sh_qspi.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -236,23 +237,17 @@ int spi_xfer(struct spi_slave *slave, unsigned int 
bitlen, const void *dout,
rdata = din;
 
while (nbyte > 0) {
-   while (!(readb(>regs->spsr) & SPSR_SPTEF)) {
-   if (ctrlc()) {
-   puts("abort\n");
-   return 1;
-   }
-   udelay(10);
-   }
+   ret = wait_for_bit_8(>regs->spsr, SPSR_SPTEF,
+true, 1000, true);
+   if (ret)
+   return ret;
 
writeb(*tdata, (u8 *)(>regs->spdr));
 
-   while (!(readb(>regs->spsr) & SPSR_SPRFF)) {
-   if (ctrlc()) {
-   puts("abort\n");
-   return 1;
-   }
-   udelay(10);
-   }
+   ret = wait_for_bit_8(>regs->spsr, SPSR_SPRFF,
+true, 1000, true);
+   if (ret)
+   return ret;
 
*rdata = readb((u8 *)(>regs->spdr));
 
-- 
2.16.2

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

[U-Boot] [PATCH 2/4] spi: sh_qspi: Drop SPBDCR wait

[Marek Vasut]

Waiting for SPBDCR == 1 is not required and is covered by the
subsequent wait for SPSR_SPRFF, so drop this.

Signed-off-by: Marek Vasut 
Cc: Nobuhiro Iwamatsu 
---
 drivers/spi/sh_qspi.c | 8 
 1 file changed, 8 deletions(-)

diff --git a/drivers/spi/sh_qspi.c b/drivers/spi/sh_qspi.c
index fc0e1fc336..8eaa6744cc 100644
--- a/drivers/spi/sh_qspi.c
+++ b/drivers/spi/sh_qspi.c
@@ -246,14 +246,6 @@ int spi_xfer(struct spi_slave *slave, unsigned int bitlen, 
const void *dout,
 
writeb(*tdata, (u8 *)(>regs->spdr));
 
-   while ((readw(>regs->spbdcr) != SPBDCR_RXBC0)) {
-   if (ctrlc()) {
-   puts("abort\n");
-   return 1;
-   }
-   udelay(1);
-   }
-
while (!(readb(>regs->spsr) & SPSR_SPRFF)) {
if (ctrlc()) {
puts("abort\n");
-- 
2.16.2

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

[U-Boot] [PATCH] ARM: rmobile: Set maximum kernel size to 64 MiB on Gen3

[Marek Vasut]

The Gen3 kernel images are often above 8 MiB, increase the
maximum kernel size to 64 MiB to future-proof it, just like
many other ARM64 boards do.

Signed-off-by: Marek Vasut 
Cc: Nobuhiro Iwamatsu 
---
 include/configs/rcar-gen3-common.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/rcar-gen3-common.h 
b/include/configs/rcar-gen3-common.h
index bbaab80e23..da82e4442a 100644
--- a/include/configs/rcar-gen3-common.h
+++ b/include/configs/rcar-gen3-common.h
@@ -51,6 +51,7 @@
 #define CONFIG_SYS_MONITOR_LEN (256 * 1024)
 #define CONFIG_SYS_MALLOC_LEN  (1 * 1024 * 1024)
 #define CONFIG_SYS_BOOTMAPSZ   (8 * 1024 * 1024)
+#define CONFIG_SYS_BOOTM_LEN   (64 << 20)
 
 /* ENV setting */
 #define CONFIG_ENV_OVERWRITE
-- 
2.16.2

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

Re: [U-Boot] [U-Boot, v2, 1/5] Migrate CONFIG_DRIVER_TI_CPSW to Kconfig

[Tom Rini]

On Tue, Apr 10, 2018 at 04:11:09PM +0200, Felix Brack wrote:
> On 10.04.2018 15:30, Tom Rini wrote:
> > On Tue, Apr 10, 2018 at 02:59:23PM +0200, Felix Brack wrote:
> >> On 10.04.2018 14:54, Tom Rini wrote:
> >>> On Tue, Apr 10, 2018 at 02:43:47PM +0200, Felix Brack wrote:
>  On 10.04.2018 14:23, Tom Rini wrote:
> > On Tue, Apr 10, 2018 at 09:21:06AM +0200, Felix Brack wrote:
> >> Hi Tom,
> >>
> >> On 09.04.2018 17:03, Tom Rini wrote:
> >>> On Sun, Apr 01, 2018 at 09:22:34AM +, Alex Kiernan wrote:
> >>>
>  This converts CONFIG_DRIVER_TI_CPSW to Kconfig
> 
>  Signed-off-by: Alex Kiernan 
>  Acked-by: Joe Hershberger 
> >>>
> >>> Applied to u-boot/master, thanks!
> >>
> >> Why did you apply this patch? It introduces a build warning?
> >
> > Wait, where does it introduce a warning?  Thanks!
> >
>  Please see my post from April 2nd on top of this thread in reply to
>  "[PATCH v2 1/5] Migrate CONFIG_DRIVER_TI_CPSW to Kconfig".
>  It is identical to the warning that shows up in the log provide by
>  Alex's link: https://travis-ci.org/akiernan/u-boot/jobs/360830565#L962.
> >>>
> >>> Ahhh.  Doesn't fail travis and I had a local goof-up and missed it in
> >>> my build logs.  Sorry.  Now, you have the CPSW driver enabled, but don't
> >>> want NET?  Or am I misunderstanding?  Thanks!
> >>
> >> Exactly, the board doesn't need NET.
> > 
> > But then what are you using the CPSW driver for?
> > 
> I don't really understand your question. This patch is from Alex, i.e. I
> am not the author of the patch. I never asked for CPSW driver support
> for the PDU001 board. Here is what I wrote April 2nd:
> 
> [quote on]
> Applying this patch series generates the following warning while
> creating the default configuration for board PDU001:
> 
> warning: (BOARD_SPECIFIC_OPTIONS && BOARD_SPECIFIC_OPTIONS &&
> BOARD_SPECIFIC_OPTIONS && BOARD_SPECIFIC_OPTIONS && DRIVER_TI_CPSW &&
> AG7XXX && ALTERA_TSE && BCM_SF2_ETH && DWC_ETH_QOS && ETH_DESIGNWARE &&
> MVNETA && MVPP2 && MACB && PCH_GBE && SUN4I_EMAC && SUN8I_EMAC &&
> SH_ETHER && XILINX_AXIEMAC && XILINX_EMACLITE && ZYNQ_GEM && PIC32_ETH
> && RENESAS_RAVB) selects PHYLIB which has unmet direct dependencies (NET)
> 
> This is due to the patch enabling CONFIG_DRIVER_TI_CPSW while leaving
> CONFIG_NET disabled.
> This board does not require/have network support for U-Boot so there is
> no need or benefit activating CONFIG_DRIVER_TI_CPSW here. Leaving the
> file configs/am355x_pdu001_defconfig without any modifications will make
> your patch work properly and result in a clean, warning and error free,
> build for the PDU001 board.
> [quote off]
> 
> So the solution for the PDU001 board warning problem is _not_ to add NET
> but to remove CPSW. This leaves the file configs/am355x_pdu001_defconfig
> unchanged by this patch and that is what I suggested as solution.
> In other words: the PDU001 board (for now) does not provide any network
> support in U-Boot.

So, ah-ha-ha! At heart, include/configs/pdu001.h grabs
include/configs/ti_am335x_common.h which was always enabling the CPSW
driver.  So the migration picked that up.  But since you're saying your
platform does not want CPSW, we can just drop that now.  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 03/12] libfdt: Safer access to strings section

[Simon Glass]

+U-Boot, Tom, Masahiro

Hi David,

On 10 April 2018 at 01:22, David Gibson  wrote:
> On Wed, Apr 04, 2018 at 01:21:10AM +0800, Simon Glass wrote:
>> Hi David,
>>
>> On 3 April 2018 at 23:02, David Gibson  wrote:
>> >
>> > On Fri, Mar 30, 2018 at 04:42:21PM +0800, Simon Glass wrote:
>> > > Hi David,
>> > >
>> > > On 26 March 2018 at 07:25, David Gibson  
>> > > wrote:
>> > > > fdt_string() is used to retrieve strings from a DT blob's strings 
>> > > > section.
>> > > > It's rarely used directly, but is widely used internally.
>> > > >
>> > > > However, it doesn't do any bounds checking, which means in the case of 
>> > > > a
>> > > > corrupted blob it could access bad memory, which libfdt is supposed to
>> > > > avoid.
>> > > >
>> > > > This write a safe alternative to fdt_string, fdt_get_string().  It 
>> > > > checks
>> > > > both that the given offset is within the string section and that the 
>> > > > string
>> > > > it points to is properly \0 terminated within the section.  It also 
>> > > > returns
>> > > > the string's length as a convenience (since it needs to determine to 
>> > > > do the
>> > > > checks anyway).
>> > > >
>> > > > fdt_string() is rewritten in terms of fdt_get_string() for 
>> > > > compatibility.
>> > > >
>> > > > Most of the diff here is actually testing infrastructure.
>> > > >
>> > > > Signed-off-by: David Gibson 
>> > > > ---
>> > > >  libfdt/fdt_ro.c  | 61 +++--
>> > > >  libfdt/libfdt.h  | 18 ++-
>> > > >  libfdt/version.lds   |  2 +-
>> > > >  tests/.gitignore |  1 +
>> > > >  tests/Makefile.tests |  2 +-
>> > > >  tests/run_tests.sh   |  1 +
>> > > >  tests/testdata.h |  1 +
>> > > >  tests/testutils.c| 11 +--
>> > > >  tests/trees.S| 26 
>> > > >  tests/truncated_string.c | 79 
>> > > > 
>> > > >  10 files changed, 193 insertions(+), 9 deletions(-)
>> > > >  create mode 100644 tests/truncated_string.c
>> > >
>> > > Similar code-size quesiton here. It looks like a lot of checking code.
>> > > Can we have an option to remove it?
>> >
>> > Again, I'm disinclined without a concrete example of a problem.  Fwiw
>> > the code size change is +276 bytes on my setup.
>>
>> That might not sound like a lot, but the overhead of DT in U-Boot is
>> about 3KB, so this adds nearly 10%.
>
> Hm.  And how much is it compared to the whole U-Boot blob?
>
>> The specific problem is that when U-Boot SPL gets too big boards don't
>> boot. Because we take the upstream libfdt this will affect U-Boot.
>>
>> Do you have any thoughts on how we could avoid this size increase?
>
> So, again, I'm very disinclined to prioritize size over memory safety
> without a *concrete* example.  i.e. "We hit this specific problem with
> size on this specific board that we were really using" rather than
> just "it might be a problem".
>
> IMO, thinking of it in terms of the "increase" is the wrong way
> arond.  If size is really a problem for you, you want to consider how
> you can reduce it in any way, not just rolling back the most recent
> changes.  The most obvious one to me would be to try
> -ffunction-sections to exclude any functions that aren't actually used
> by u-boot (if this is helpful and the compiler's an issue, I'd be
> willing to consider splitting up libfdt into a bunch more C files).

Actually U-Boot does use that option. Believe me, a lot of work has
gone into making this small. There is constant pressure to
reduce/retain the size in SPL so that we can stay below limits. E.g.
firefly-rk3288 has a 30KB limit for SPL. Current problems are the
64-bit Allwinner parts which are right up against the limit at
present.

Also, Masahiro recently did some work to make U-Boot's version of
libfdt the same as is used by Linux, so any changes will impact us
quite quickly.

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

Re: [U-Boot] [PATCH u-boot 2/2] ARM: meson: Add cpu info display for GX SoCs

[Simon Glass]

Hi Neil,

On 10 April 2018 at 09:51, Neil Armstrong  wrote:
> On 08/04/2018 15:50, Simon Glass wrote:
>> Hi,
>>
>> On 28 March 2018 at 05:54, Neil Armstrong  wrote:
>>> The Amlogic SoCs have a registers containing the die revision
>>> and packaging type to determine the SoC family and package marketing
>>> name like S905X for the GXL SoC Family.
>>> This code is taken for the Linux meson-gx-socinfo driver and adapted
>>> to U-Boot printing.
>>>
>>> Signed-off-by: Neil Armstrong 
>>> ---
>>>  arch/arm/include/asm/arch-meson/gx.h |   1 +
>>>  arch/arm/mach-meson/Makefile |   2 +-
>>>  arch/arm/mach-meson/cpu_info.c   | 105 
>>> +++
>>>  configs/khadas-vim_defconfig |   2 +-
>>>  configs/libretech-cc_defconfig   |   2 +-
>>>  configs/odroid-c2_defconfig  |   2 +-
>>>  configs/odroid_defconfig |   1 +
>>>  configs/p212_defconfig   |   2 +-
>>>  8 files changed, 112 insertions(+), 5 deletions(-)
>>>  create mode 100644 arch/arm/mach-meson/cpu_info.c
>>
>> Please can you use driver model's CPU interface for this?
>>
>> Regards,
>> Simon
>>
>
> Hi Simon,
>
> The CPU uclass is designed for the /cpu/* nodes, here we fetch the SoC 
> information
> in some /soc/ subnodes which cannot be used with the current CPU uclass and
> won't be probed before relocation.
>
> Either I push is as a MISC driver (with the pre-reloc issue) or we leave this 
> in mach-meson.
>
> What do you think ?

Do you think it could search both /cpu and /soc ? They seem to be
fairly equivalent. Is that the only problem?

>
> Thanks,
> Neil

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

Re: [U-Boot] [GIT PULL] Xilinx patches for v2018.05-rc2

[Tom Rini]

On Tue, Apr 10, 2018 at 04:16:14PM +0200, Michal Simek wrote:
> On 10.4.2018 16:08, Tom Rini wrote:
> > On Mon, Apr 09, 2018 at 04:39:29PM +0200, Michal Simek wrote:
> > 
> >> Hi Tom,
> >>
> >> please pull these changes to your tree.
> >>
> >> Travis looks good.
> >> https://travis-ci.org/michalsimek/u-boot/builds/364047688
> >>
> >> And buildman output too.
> >>
> >> Thanks,
> >> Michal
> >>
> >>
> >> The following changes since commit 
> >> 5bc0543df3079add8152afa041b887d081d71839:
> >>
> >>   treewide: Convert CONFIG_HOSTNAME to a string option (2018-04-08
> >> 18:31:09 -0400)
> >>
> >> are available in the git repository at:
> >>
> >>   git://www.denx.de/git/u-boot-microblaze.git tags/xilinx-for-v2018.05-rc2
> >>
> >> for you to fetch changes up to f190eaf002bf1434587d57c726b3dabfabbc8074:
> >>
> >>   arm64: zynqmp: Add support for Xilinx zcu111-revA (2018-04-09 12:14:53
> >> +0200)
> >>
> > 
> > Applied to u-boot/master, thanks!
> > 
> > But a small request.  A number of Xilinx have commits in the form of:
> > Author: Their Name 
> > ...
> > Signed-off-by: Their Name: 
> > 
> > Which is fine in that it's clear that the Author also S-o-B'd it.  But
> > since the email doesn't match is does trigger my script that shows me
> > the log to manually confirm the author S-o-B'd it.  Can you please ask
> > the team to check their gitconfig?  Thanks!
> 
> Xilinx is allowing to have email setup in both forms.

That's fairly common.  FWIW, it pops up sometimes for TI and
NXP/Freescale (I don't know if it will follow over to qcom).

> I see that Siva, Nitin, Vipul and maybe others have that incorrect setting.
> Do you have that script somewhere to also include it to my flow to make
> sure that this is aligned when I accept these patches internally too?

Sure.  This is ugly, but functional:
#!/bin/bash
COMMITS=`git log --no-merges origin/master.. --oneline | wc -l`
SIGNS=`mktemp`

for HASH in `git log --no-merges origin/master.. --format=%h`;do EMAIL=`git log 
-n1 --format=%ae $HASH`; git log --grep="Signed-off-by.*$EMAIL" 
${HASH}^..${HASH} --format="Commit %h is OK";done > $SIGNS

if test $COMMITS -ne `cat $SIGNS | wc -l`;then
echo Problematic commits exist:
for HASH in `git log --no-merges origin/master.. --format=%h`;do 
EMAIL=`git log -n1 --format=%ae $HASH`; git log --grep="Signed-off-by.*$EMAIL" 
--invert-grep ${HASH}^..${HASH};done
rm -f $SIGNS
exit 1
else
rm -f $SIGNS
echo "All commits appear OK"
fi

-- 
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] [U-Boot, v2, 1/5] Migrate CONFIG_DRIVER_TI_CPSW to Kconfig

[Tom Rini]

On Tue, Apr 10, 2018 at 04:11:09PM +0200, Felix Brack wrote:
> On 10.04.2018 15:30, Tom Rini wrote:
> > On Tue, Apr 10, 2018 at 02:59:23PM +0200, Felix Brack wrote:
> >> On 10.04.2018 14:54, Tom Rini wrote:
> >>> On Tue, Apr 10, 2018 at 02:43:47PM +0200, Felix Brack wrote:
>  On 10.04.2018 14:23, Tom Rini wrote:
> > On Tue, Apr 10, 2018 at 09:21:06AM +0200, Felix Brack wrote:
> >> Hi Tom,
> >>
> >> On 09.04.2018 17:03, Tom Rini wrote:
> >>> On Sun, Apr 01, 2018 at 09:22:34AM +, Alex Kiernan wrote:
> >>>
>  This converts CONFIG_DRIVER_TI_CPSW to Kconfig
> 
>  Signed-off-by: Alex Kiernan 
>  Acked-by: Joe Hershberger 
> >>>
> >>> Applied to u-boot/master, thanks!
> >>
> >> Why did you apply this patch? It introduces a build warning?
> >
> > Wait, where does it introduce a warning?  Thanks!
> >
>  Please see my post from April 2nd on top of this thread in reply to
>  "[PATCH v2 1/5] Migrate CONFIG_DRIVER_TI_CPSW to Kconfig".
>  It is identical to the warning that shows up in the log provide by
>  Alex's link: https://travis-ci.org/akiernan/u-boot/jobs/360830565#L962.
> >>>
> >>> Ahhh.  Doesn't fail travis and I had a local goof-up and missed it in
> >>> my build logs.  Sorry.  Now, you have the CPSW driver enabled, but don't
> >>> want NET?  Or am I misunderstanding?  Thanks!
> >>
> >> Exactly, the board doesn't need NET.
> > 
> > But then what are you using the CPSW driver for?
> > 
> I don't really understand your question. This patch is from Alex, i.e. I
> am not the author of the patch. I never asked for CPSW driver support
> for the PDU001 board. Here is what I wrote April 2nd:
> 
> [quote on]
> Applying this patch series generates the following warning while
> creating the default configuration for board PDU001:
> 
> warning: (BOARD_SPECIFIC_OPTIONS && BOARD_SPECIFIC_OPTIONS &&
> BOARD_SPECIFIC_OPTIONS && BOARD_SPECIFIC_OPTIONS && DRIVER_TI_CPSW &&
> AG7XXX && ALTERA_TSE && BCM_SF2_ETH && DWC_ETH_QOS && ETH_DESIGNWARE &&
> MVNETA && MVPP2 && MACB && PCH_GBE && SUN4I_EMAC && SUN8I_EMAC &&
> SH_ETHER && XILINX_AXIEMAC && XILINX_EMACLITE && ZYNQ_GEM && PIC32_ETH
> && RENESAS_RAVB) selects PHYLIB which has unmet direct dependencies (NET)
> 
> This is due to the patch enabling CONFIG_DRIVER_TI_CPSW while leaving
> CONFIG_NET disabled.
> This board does not require/have network support for U-Boot so there is
> no need or benefit activating CONFIG_DRIVER_TI_CPSW here. Leaving the
> file configs/am355x_pdu001_defconfig without any modifications will make
> your patch work properly and result in a clean, warning and error free,
> build for the PDU001 board.
> [quote off]
> 
> So the solution for the PDU001 board warning problem is _not_ to add NET
> but to remove CPSW. This leaves the file configs/am355x_pdu001_defconfig
> unchanged by this patch and that is what I suggested as solution.
> In other words: the PDU001 board (for now) does not provide any network
> support in U-Boot.

Ah, OK.  My fault, I'll fixup the config and re-run migration to be sure
nothing else was wrong here.  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] [GIT PULL] Xilinx patches for v2018.05-rc2

[Michal Simek]

On 10.4.2018 16:08, Tom Rini wrote:
> On Mon, Apr 09, 2018 at 04:39:29PM +0200, Michal Simek wrote:
> 
>> Hi Tom,
>>
>> please pull these changes to your tree.
>>
>> Travis looks good.
>> https://travis-ci.org/michalsimek/u-boot/builds/364047688
>>
>> And buildman output too.
>>
>> Thanks,
>> Michal
>>
>>
>> The following changes since commit 5bc0543df3079add8152afa041b887d081d71839:
>>
>>   treewide: Convert CONFIG_HOSTNAME to a string option (2018-04-08
>> 18:31:09 -0400)
>>
>> are available in the git repository at:
>>
>>   git://www.denx.de/git/u-boot-microblaze.git tags/xilinx-for-v2018.05-rc2
>>
>> for you to fetch changes up to f190eaf002bf1434587d57c726b3dabfabbc8074:
>>
>>   arm64: zynqmp: Add support for Xilinx zcu111-revA (2018-04-09 12:14:53
>> +0200)
>>
> 
> Applied to u-boot/master, thanks!
> 
> But a small request.  A number of Xilinx have commits in the form of:
> Author: Their Name 
> ...
> Signed-off-by: Their Name: 
> 
> Which is fine in that it's clear that the Author also S-o-B'd it.  But
> since the email doesn't match is does trigger my script that shows me
> the log to manually confirm the author S-o-B'd it.  Can you please ask
> the team to check their gitconfig?  Thanks!

Xilinx is allowing to have email setup in both forms.
I see that Siva, Nitin, Vipul and maybe others have that incorrect setting.
Do you have that script somewhere to also include it to my flow to make
sure that this is aligned when I accept these patches internally too?

Thanks,
Michal


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

Re: [U-Boot] [U-Boot, v2, 1/5] Migrate CONFIG_DRIVER_TI_CPSW to Kconfig

[Felix Brack]

On 10.04.2018 15:30, Tom Rini wrote:
> On Tue, Apr 10, 2018 at 02:59:23PM +0200, Felix Brack wrote:
>> On 10.04.2018 14:54, Tom Rini wrote:
>>> On Tue, Apr 10, 2018 at 02:43:47PM +0200, Felix Brack wrote:
 On 10.04.2018 14:23, Tom Rini wrote:
> On Tue, Apr 10, 2018 at 09:21:06AM +0200, Felix Brack wrote:
>> Hi Tom,
>>
>> On 09.04.2018 17:03, Tom Rini wrote:
>>> On Sun, Apr 01, 2018 at 09:22:34AM +, Alex Kiernan wrote:
>>>
 This converts CONFIG_DRIVER_TI_CPSW to Kconfig

 Signed-off-by: Alex Kiernan 
 Acked-by: Joe Hershberger 
>>>
>>> Applied to u-boot/master, thanks!
>>
>> Why did you apply this patch? It introduces a build warning?
>
> Wait, where does it introduce a warning?  Thanks!
>
 Please see my post from April 2nd on top of this thread in reply to
 "[PATCH v2 1/5] Migrate CONFIG_DRIVER_TI_CPSW to Kconfig".
 It is identical to the warning that shows up in the log provide by
 Alex's link: https://travis-ci.org/akiernan/u-boot/jobs/360830565#L962.
>>>
>>> Ahhh.  Doesn't fail travis and I had a local goof-up and missed it in
>>> my build logs.  Sorry.  Now, you have the CPSW driver enabled, but don't
>>> want NET?  Or am I misunderstanding?  Thanks!
>>
>> Exactly, the board doesn't need NET.
> 
> But then what are you using the CPSW driver for?
> 
I don't really understand your question. This patch is from Alex, i.e. I
am not the author of the patch. I never asked for CPSW driver support
for the PDU001 board. Here is what I wrote April 2nd:

[quote on]
Applying this patch series generates the following warning while
creating the default configuration for board PDU001:

warning: (BOARD_SPECIFIC_OPTIONS && BOARD_SPECIFIC_OPTIONS &&
BOARD_SPECIFIC_OPTIONS && BOARD_SPECIFIC_OPTIONS && DRIVER_TI_CPSW &&
AG7XXX && ALTERA_TSE && BCM_SF2_ETH && DWC_ETH_QOS && ETH_DESIGNWARE &&
MVNETA && MVPP2 && MACB && PCH_GBE && SUN4I_EMAC && SUN8I_EMAC &&
SH_ETHER && XILINX_AXIEMAC && XILINX_EMACLITE && ZYNQ_GEM && PIC32_ETH
&& RENESAS_RAVB) selects PHYLIB which has unmet direct dependencies (NET)

This is due to the patch enabling CONFIG_DRIVER_TI_CPSW while leaving
CONFIG_NET disabled.
This board does not require/have network support for U-Boot so there is
no need or benefit activating CONFIG_DRIVER_TI_CPSW here. Leaving the
file configs/am355x_pdu001_defconfig without any modifications will make
your patch work properly and result in a clean, warning and error free,
build for the PDU001 board.
[quote off]

So the solution for the PDU001 board warning problem is _not_ to add NET
but to remove CPSW. This leaves the file configs/am355x_pdu001_defconfig
unchanged by this patch and that is what I suggested as solution.
In other words: the PDU001 board (for now) does not provide any network
support in U-Boot.

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

Re: [U-Boot] [PATCH v2] kconfig: add CONFIG_CC_COVERAGE

[Tom Rini]

On Mon, Apr 09, 2018 at 05:11:45PM +0200, Christian Gmeiner wrote:

> Make it possible to use gcc code coverage analysis.
> 
> v1 -> v2:
>  - Kconfig: remove not needed 'default n'
>  - Makefile: use consistent spacing
> 
> Signed-off-by: Christian Gmeiner 

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] [GIT PULL] Xilinx patches for v2018.05-rc2

[Tom Rini]

On Mon, Apr 09, 2018 at 04:39:29PM +0200, Michal Simek wrote:

> Hi Tom,
> 
> please pull these changes to your tree.
> 
> Travis looks good.
> https://travis-ci.org/michalsimek/u-boot/builds/364047688
> 
> And buildman output too.
> 
> Thanks,
> Michal
> 
> 
> The following changes since commit 5bc0543df3079add8152afa041b887d081d71839:
> 
>   treewide: Convert CONFIG_HOSTNAME to a string option (2018-04-08
> 18:31:09 -0400)
> 
> are available in the git repository at:
> 
>   git://www.denx.de/git/u-boot-microblaze.git tags/xilinx-for-v2018.05-rc2
> 
> for you to fetch changes up to f190eaf002bf1434587d57c726b3dabfabbc8074:
> 
>   arm64: zynqmp: Add support for Xilinx zcu111-revA (2018-04-09 12:14:53
> +0200)
> 

Applied to u-boot/master, thanks!

But a small request.  A number of Xilinx have commits in the form of:
Author: Their Name 
...
Signed-off-by: Their Name: 

Which is fine in that it's clear that the Author also S-o-B'd it.  But
since the email doesn't match is does trigger my script that shows me
the log to manually confirm the author S-o-B'd it.  Can you please ask
the team to check their gitconfig?  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] [PULL] efi patch queue 2018-04-09

[Tom Rini]

On Mon, Apr 09, 2018 at 03:07:11PM +0200, Alexander Graf wrote:

> Hi Tom,
> 
> Sorry the previous request failed travis checks. This one passes.
> 
> This is my current patch queue for efi.  Please pull.
> 
> Alex
> 
> 
> The following changes since commit 645b5afbb8215b3386cd6fc2dc3119bd68e4c760:
> 
>   Prepare v2018.05-rc1 (2018-04-02 20:31:36 -0400)
> 
> are available in the git repository at:
> 
>   git://github.com/agraf/u-boot.git tags/signed-efi-next
> 
> for you to fetch changes up to f4cf153a487486428a061b5d866fe2f68653b2f8:
> 
>   efi_loader: correctly set the machine type in the PE header (2018-04-09 
> 10:20:59 +0200)
> 

Applied to u-boot/master, 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 u-boot 2/2] ARM: meson: Add cpu info display for GX SoCs

[Neil Armstrong]

On 08/04/2018 15:50, Simon Glass wrote:
> Hi,
> 
> On 28 March 2018 at 05:54, Neil Armstrong  wrote:
>> The Amlogic SoCs have a registers containing the die revision
>> and packaging type to determine the SoC family and package marketing
>> name like S905X for the GXL SoC Family.
>> This code is taken for the Linux meson-gx-socinfo driver and adapted
>> to U-Boot printing.
>>
>> Signed-off-by: Neil Armstrong 
>> ---
>>  arch/arm/include/asm/arch-meson/gx.h |   1 +
>>  arch/arm/mach-meson/Makefile |   2 +-
>>  arch/arm/mach-meson/cpu_info.c   | 105 
>> +++
>>  configs/khadas-vim_defconfig |   2 +-
>>  configs/libretech-cc_defconfig   |   2 +-
>>  configs/odroid-c2_defconfig  |   2 +-
>>  configs/odroid_defconfig |   1 +
>>  configs/p212_defconfig   |   2 +-
>>  8 files changed, 112 insertions(+), 5 deletions(-)
>>  create mode 100644 arch/arm/mach-meson/cpu_info.c
> 
> Please can you use driver model's CPU interface for this?
> 
> Regards,
> Simon
> 

Hi Simon,

The CPU uclass is designed for the /cpu/* nodes, here we fetch the SoC 
information
in some /soc/ subnodes which cannot be used with the current CPU uclass and
won't be probed before relocation.

Either I push is as a MISC driver (with the pre-reloc issue) or we leave this 
in mach-meson.

What do you think ?

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

[U-Boot] [PATCH RFC] spi: mxs spi: DM conversion

[Akash Gajjar]

This is to announce that I have started working on DM driver support for 
mxs spi driver that adds basic skeleton of DM driver functionality along with 
legacy driver support. 

This is compilation tested only. 

Signed-off-by: Akash Gajjar 
---
 drivers/spi/mxs_spi.c | 74 +++
 1 file changed, 74 insertions(+)

diff --git a/drivers/spi/mxs_spi.c b/drivers/spi/mxs_spi.c
index 790db78..94e9ab3 100644
--- a/drivers/spi/mxs_spi.c
+++ b/drivers/spi/mxs_spi.c
@@ -20,6 +20,9 @@
 #include 
 #include 
 #include 
+#ifdef CONFIG_DM_SPI
+#include 
+#endif
 
 #defineMXS_SPI_MAX_TIMEOUT 100
 #defineMXS_SPI_PORT_OFFSET 0x2000
@@ -361,3 +364,74 @@ int spi_xfer(struct spi_slave *slave, unsigned int bitlen,
return mxs_spi_xfer_dma(mxs_slave, data, len, write, flags);
}
 }
+
+#ifdef CONFIG_DM_SPI
+struct mxs_spi_priv {
+   struct spi_slaveslave;
+   struct mxs_ssp_regs *regs;
+   u32 max_khz;
+   u32 mode;
+};
+
+struct mxs_spi_platdata {
+   struct spi_slaveslave;
+   struct mxs_ssp_regs *regs;
+   u32 bus;
+};
+
+static int mxs_spi_claim_bus(struct udevice *dev)
+{
+   struct udevice *bus = dev->parent;
+   struct mxs_spi_platdata *plat = dev_get_platdata(bus);
+   struct mxs_ssp_regs *ssp_regs = plat->regs;
+   u32 reg = 0;
+
+   writel((slave->cs << MXS_SSP_CHIPSELECT_SHIFT) |
+   SSP_CTRL0_BUS_WIDTH_ONE_BIT,
+   _regs->hw_ssp_ctrl0);
+
+   return 0;
+}
+
+static int mxs_spi_release_bus(struct udevice *dev)
+{
+   return 0;
+}
+
+static int mxs_spi_xfer(struct udevice *dev, unsigned int bitlen,
+   const void *dout, void *din, unsigned long flags)
+{
+   return 0;
+}
+
+static int mxs_spi_set_speed(struct udevice *bus, uint speed)
+{
+   return 0;
+}
+
+static int mxs_spi_set_mode(struct udevice *bus, uint mode)
+{
+   return 0;
+}
+
+static int mxs_spi_probe(struct udevice *dev)
+{
+   return 0;
+}
+
+static const struct dm_spi_ops mxs_spi_ops = {
+   .claim_bus  = mxs_spi_claim_bus,
+   .release_bus= mxs_spi_release_bus,
+   .xfer   = mxs_spi_xfer,
+   .set_speed  = mxs_spi_set_speed,
+   .set_mode   = mxs_spi_set_mode,
+};
+
+U_BOOT_DRIVER(mxs_spi) = {
+   .name   = "mxs_spi",
+   .id = UCLASS_SPI,
+   .ops= _spi_ops,
+   .priv_auto_alloc_size = sizeof(struct mxs_spi_priv),
+   .probe  = mxs_spi_probe,
+};
+#endif
-- 
1.9.1

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

[U-Boot] [PATCH RFC] spi: mxs spi: DM conversion

[Akash Gajjar]

This is to announce that I have started working on DM driver support for
mxs spi driver that adds basic skeleton of DM driver functionality along with
legacy driver support.

This is compilation tested only.

Signed-off-by: Akash Gajjar 
---
 drivers/spi/mxs_spi.c | 144 ++
 1 file changed, 144 insertions(+)

diff --git a/drivers/spi/mxs_spi.c b/drivers/spi/mxs_spi.c
index 790db78..ef970c0 100644
--- a/drivers/spi/mxs_spi.c
+++ b/drivers/spi/mxs_spi.c
@@ -20,6 +20,9 @@
 #include 
 #include 
 #include 
+#ifdef CONFIG_DM_SPI
+#include 
+#endif
 
 #defineMXS_SPI_MAX_TIMEOUT 100
 #defineMXS_SPI_PORT_OFFSET 0x2000
@@ -361,3 +364,144 @@ int spi_xfer(struct spi_slave *slave, unsigned int bitlen,
return mxs_spi_xfer_dma(mxs_slave, data, len, write, flags);
}
 }
+
+#ifdef CONFIG_DM_SPI
+struct mxs_spi_priv {
+   struct spi_slaveslave;
+   uint32_tmax_khz;
+   uint32_tmode;
+   struct mxs_ssp_regs *regs;
+};
+
+struct mxs_spi_platdata {
+   struct spi_slaveslave;
+   uint32_tbus;
+   struct mxs_ssp_regs *regs;
+};
+
+/* review */
+static int mxs_spi_claim_bus(struct udevice *dev)
+{
+   struct udevice *bus = dev->parent;
+   struct mxs_spi_platdata *plat = dev_get_platdata(bus);
+   struct mxs_ssp_regs *ssp_regs = plat->regs;
+   uint32_t reg = 0;
+
+   writel((slave->cs << MXS_SSP_CHIPSELECT_SHIFT) |
+   SSP_CTRL0_BUS_WIDTH_ONE_BIT,
+   _regs->hw_ssp_ctrl0);
+
+   return 0;   
+}
+
+static int mxs_spi_release_bus(struct udevice *dev)
+{
+   return 0;
+}
+
+/* review */
+static int mxs_spi_xfer(struct udevice *dev, unsigned int bitlen,
+   const void *dout, void *din, unsigned long flags)
+{
+   struct udevice *bus = dev->parent;
+   struct mxs_spi_platdata *plat = dev_get_platdata(bus);
+   struct mxs_ssp_regs *ssp_regs = plat->regs;
+   int len = bitlen / 8;
+   char dummy;
+   int write = 0;
+   char *data = NULL;
+   int dma = 1;
+
+   if (bitlen == 0) {
+   if (flags & SPI_XFER_END) {
+   din = (void *)
+   len = 1;
+   } else
+   return 0;
+   }
+
+   /* Half-duplex only */
+   if (din && dout)
+   return -EINVAL;
+   /* No data */
+   if (!din && !dout)
+   return 0;
+
+   if (dout) {
+   data = (char *)dout;
+   write = 1;
+   } else if (din) {
+   data = (char *)din;
+   write = 0;
+   }
+
+   /*
+* Check for alignment, if the buffer is aligned, do DMA transfer,
+* PIO otherwise. This is a temporary workaround until proper bounce
+* buffer is in place.
+*/
+   if (dma) {
+   if (((uint32_t)data) & (ARCH_DMA_MINALIGN - 1))
+   dma = 0;
+   if (((uint32_t)len) & (ARCH_DMA_MINALIGN - 1))
+   dma = 0;
+   }
+
+   if (!dma || (len < MXSSSP_SMALL_TRANSFER)) {
+   writel(SSP_CTRL1_DMA_ENABLE, _regs->hw_ssp_ctrl1_clr);
+   return mxs_spi_xfer_pio(mxs_slave, data, len, write, flags);
+   } else {
+   writel(SSP_CTRL1_DMA_ENABLE, _regs->hw_ssp_ctrl1_set);
+   return mxs_spi_xfer_dma(mxs_slave, data, len, write, flags);
+   }
+
+   return 0;
+}
+
+static int mxs_spi_set_speed(struct udevice *bus, uint speed)
+{
+   struct mxs_spi_platdata *plat = dev_get_platdata(bus);
+
+   debug("%s mode %u\n", __func__, mode);
+   priv->max_khz = speed;
+
+   return 0;
+}
+
+static int mxs_spi_set_mode(struct udevice *bus, uint mode)
+{
+   struct mxs_spi_priv *priv = dev_get_priv(bus);
+
+   debug("%s mode %u\n", __func__, mode);  
+   priv->mode = mode;
+
+   return 0;
+}
+
+static int mxs_spi_probe(struct udevice *dev)
+{
+   struct mxs_spi_platdata *plat = dev_get_platdata(dev);
+   struct mxs_spi_priv *priv;
+
+
+   priv->regs = mxs_ssp_regs_by_bus(plat->bus);
+
+   return 0;   
+}
+
+static const struct dm_spi_ops mxs_spi_ops = {
+   .claim_bus  = mxs_spi_claim_bus,
+   .release_bus= mxs_spi_release_bus,
+   .xfer   = mxs_spi_xfer,
+   .set_speed  = mxs_spi_set_speed,
+   .set_mode   = mxs_spi_set_mode,
+};
+
+U_BOOT_DRIVER(mxs_spi) = {
+   .name   = "mxs_spi",
+   .id = UCLASS_SPI,
+   .ops= _spi_ops,
+   .priv_auto_alloc_size = sizeof(struct mxs_spi_priv),
+   .probe  = mxs_spi_probe,
+};
+#endif
-- 
1.9.1

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

Re: [U-Boot] [U-Boot, v2, 1/5] Migrate CONFIG_DRIVER_TI_CPSW to Kconfig

[Tom Rini]

On Tue, Apr 10, 2018 at 02:59:23PM +0200, Felix Brack wrote:
> On 10.04.2018 14:54, Tom Rini wrote:
> > On Tue, Apr 10, 2018 at 02:43:47PM +0200, Felix Brack wrote:
> >> On 10.04.2018 14:23, Tom Rini wrote:
> >>> On Tue, Apr 10, 2018 at 09:21:06AM +0200, Felix Brack wrote:
>  Hi Tom,
> 
>  On 09.04.2018 17:03, Tom Rini wrote:
> > On Sun, Apr 01, 2018 at 09:22:34AM +, Alex Kiernan wrote:
> >
> >> This converts CONFIG_DRIVER_TI_CPSW to Kconfig
> >>
> >> Signed-off-by: Alex Kiernan 
> >> Acked-by: Joe Hershberger 
> >
> > Applied to u-boot/master, thanks!
> 
>  Why did you apply this patch? It introduces a build warning?
> >>>
> >>> Wait, where does it introduce a warning?  Thanks!
> >>>
> >> Please see my post from April 2nd on top of this thread in reply to
> >> "[PATCH v2 1/5] Migrate CONFIG_DRIVER_TI_CPSW to Kconfig".
> >> It is identical to the warning that shows up in the log provide by
> >> Alex's link: https://travis-ci.org/akiernan/u-boot/jobs/360830565#L962.
> > 
> > Ahhh.  Doesn't fail travis and I had a local goof-up and missed it in
> > my build logs.  Sorry.  Now, you have the CPSW driver enabled, but don't
> > want NET?  Or am I misunderstanding?  Thanks!
> 
> Exactly, the board doesn't need NET.

But then what are you using the CPSW driver for?

-- 
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] [U-Boot, v2, 1/5] Migrate CONFIG_DRIVER_TI_CPSW to Kconfig

[Felix Brack]

On 10.04.2018 14:54, Tom Rini wrote:
> On Tue, Apr 10, 2018 at 02:43:47PM +0200, Felix Brack wrote:
>> On 10.04.2018 14:23, Tom Rini wrote:
>>> On Tue, Apr 10, 2018 at 09:21:06AM +0200, Felix Brack wrote:
 Hi Tom,

 On 09.04.2018 17:03, Tom Rini wrote:
> On Sun, Apr 01, 2018 at 09:22:34AM +, Alex Kiernan wrote:
>
>> This converts CONFIG_DRIVER_TI_CPSW to Kconfig
>>
>> Signed-off-by: Alex Kiernan 
>> Acked-by: Joe Hershberger 
>
> Applied to u-boot/master, thanks!

 Why did you apply this patch? It introduces a build warning?
>>>
>>> Wait, where does it introduce a warning?  Thanks!
>>>
>> Please see my post from April 2nd on top of this thread in reply to
>> "[PATCH v2 1/5] Migrate CONFIG_DRIVER_TI_CPSW to Kconfig".
>> It is identical to the warning that shows up in the log provide by
>> Alex's link: https://travis-ci.org/akiernan/u-boot/jobs/360830565#L962.
> 
> Ahhh.  Doesn't fail travis and I had a local goof-up and missed it in
> my build logs.  Sorry.  Now, you have the CPSW driver enabled, but don't
> want NET?  Or am I misunderstanding?  Thanks!
> 
Exactly, the board doesn't need NET.

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

Re: [U-Boot] [U-Boot, v2, 1/5] Migrate CONFIG_DRIVER_TI_CPSW to Kconfig

[Tom Rini]

On Tue, Apr 10, 2018 at 02:43:47PM +0200, Felix Brack wrote:
> On 10.04.2018 14:23, Tom Rini wrote:
> > On Tue, Apr 10, 2018 at 09:21:06AM +0200, Felix Brack wrote:
> >> Hi Tom,
> >>
> >> On 09.04.2018 17:03, Tom Rini wrote:
> >>> On Sun, Apr 01, 2018 at 09:22:34AM +, Alex Kiernan wrote:
> >>>
>  This converts CONFIG_DRIVER_TI_CPSW to Kconfig
> 
>  Signed-off-by: Alex Kiernan 
>  Acked-by: Joe Hershberger 
> >>>
> >>> Applied to u-boot/master, thanks!
> >>
> >> Why did you apply this patch? It introduces a build warning?
> > 
> > Wait, where does it introduce a warning?  Thanks!
> > 
> Please see my post from April 2nd on top of this thread in reply to
> "[PATCH v2 1/5] Migrate CONFIG_DRIVER_TI_CPSW to Kconfig".
> It is identical to the warning that shows up in the log provide by
> Alex's link: https://travis-ci.org/akiernan/u-boot/jobs/360830565#L962.

Ahhh.  Doesn't fail travis and I had a local goof-up and missed it in
my build logs.  Sorry.  Now, you have the CPSW driver enabled, but don't
want NET?  Or am I misunderstanding?  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] [U-Boot, v2, 1/5] Migrate CONFIG_DRIVER_TI_CPSW to Kconfig

[Felix Brack]

On 10.04.2018 14:23, Tom Rini wrote:
> On Tue, Apr 10, 2018 at 09:21:06AM +0200, Felix Brack wrote:
>> Hi Tom,
>>
>> On 09.04.2018 17:03, Tom Rini wrote:
>>> On Sun, Apr 01, 2018 at 09:22:34AM +, Alex Kiernan wrote:
>>>
 This converts CONFIG_DRIVER_TI_CPSW to Kconfig

 Signed-off-by: Alex Kiernan 
 Acked-by: Joe Hershberger 
>>>
>>> Applied to u-boot/master, thanks!
>>
>> Why did you apply this patch? It introduces a build warning?
> 
> Wait, where does it introduce a warning?  Thanks!
> 
Please see my post from April 2nd on top of this thread in reply to
"[PATCH v2 1/5] Migrate CONFIG_DRIVER_TI_CPSW to Kconfig".
It is identical to the warning that shows up in the log provide by
Alex's link: https://travis-ci.org/akiernan/u-boot/jobs/360830565#L962.

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

Re: [U-Boot] [U-Boot, 36/36] rockchip: add common board file for rockchip platform

[Dr. Philipp Tomsich]

> On 10 Apr 2018, at 14:32, Tom Rini  wrote:
> 
> On Tue, Apr 10, 2018 at 02:54:09PM +0800, Kever Yang wrote:
>> Hi Tom,
>> 
>> 
>> On 04/09/2018 06:35 AM, Tom Rini wrote:
 I have do a lot of test and re-work in my local branch and at last make
 it landed in
 rockchip vendor U-Boot, with testing in most of SoCs(not including
 rk3066/rk3188).
 Well, I do try to split it into pieces, but I found that actually not
 help very much
 except waste much more time:
 - The target is(very clear) to make rockchip soc board file in a good
 shape with common files,
 instead of copy-paste for each soc(more than 10 of them now)
 - then we need to identify what's common and what should go to soc and
 board;
 - remove using common rockchip timer and use arm generic timer instead
 for armv7
 SoCs(rk3066 and rk3188 need still using rockchip timer)
 - most soc need to do uart init, boot order select, and some
 arch_cpu_init().
 - don't break the boards already working, so I still leave some code
 which not so common
 in board file, but I would like to remove or move them into right
 place if I got a board
 to verify;
 
 @Simon, @Tom,
 This patch set is to remove some common files and add some other common
 files for
 all Rockchip SoCs, I have to make sure the whole patch set can running
 good for all SoCs,
 but it's really hard to make every patch to build and work perfect for
 all SoCs, is there
 any mandatory rules for this?
>>> So you mean possibly breaking some existing platforms?  I don't like the
>>> idea of doing that...
>> 
>> No, I'm not intent to to breaking some existing platforms,
>> this patch set including 36 patches, all the platform should work fine
>> after apply all these patches, but if only some of them applied,
>> there is compile error or running error because of feature missing.
> 
> OK.  Similar to the Linux kernel, it's not a good thing to break
> buildability of things during a patch series.


Independent of this: this is not a single series, but multiple series rolled
into one.  Once the commit messages are reworked to convey what’s
changed in a more meaningful way, this will be even more apparent
than it already is today.

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

Re: [U-Boot] [U-Boot, 36/36] rockchip: add common board file for rockchip platform

[Tom Rini]

On Tue, Apr 10, 2018 at 02:54:09PM +0800, Kever Yang wrote:
> Hi Tom,
> 
> 
> On 04/09/2018 06:35 AM, Tom Rini wrote:
> >> I have do a lot of test and re-work in my local branch and at last make
> >> it landed in
> >> rockchip vendor U-Boot, with testing in most of SoCs(not including
> >> rk3066/rk3188).
> >> Well, I do try to split it into pieces, but I found that actually not
> >> help very much
> >> except waste much more time:
> >> - The target is(very clear) to make rockchip soc board file in a good
> >> shape with common files,
> >>     instead of copy-paste for each soc(more than 10 of them now)
> >> - then we need to identify what's common and what should go to soc and
> >> board;
> >> - remove using common rockchip timer and use arm generic timer instead
> >> for armv7
> >>     SoCs(rk3066 and rk3188 need still using rockchip timer)
> >> - most soc need to do uart init, boot order select, and some
> >> arch_cpu_init().
> >> - don't break the boards already working, so I still leave some code
> >> which not so common
> >>     in board file, but I would like to remove or move them into right
> >> place if I got a board
> >>     to verify;
> >>
> >> @Simon, @Tom,
> >> This patch set is to remove some common files and add some other common
> >> files for
> >> all Rockchip SoCs, I have to make sure the whole patch set can running
> >> good for all SoCs,
> >> but it's really hard to make every patch to build and work perfect for
> >> all SoCs, is there
> >> any mandatory rules for this?
> > So you mean possibly breaking some existing platforms?  I don't like the
> > idea of doing that...
> 
> No, I'm not intent to to breaking some existing platforms,
> this patch set including 36 patches, all the platform should work fine
> after apply all these patches, but if only some of them applied,
> there is compile error or running error because of feature missing.

OK.  Similar to the Linux kernel, it's not a good thing to break
buildability of things during a patch series.

-- 
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] [U-Boot, v2, 1/5] Migrate CONFIG_DRIVER_TI_CPSW to Kconfig

[Tom Rini]

On Tue, Apr 10, 2018 at 09:21:06AM +0200, Felix Brack wrote:
> Hi Tom,
> 
> On 09.04.2018 17:03, Tom Rini wrote:
> > On Sun, Apr 01, 2018 at 09:22:34AM +, Alex Kiernan wrote:
> > 
> >> This converts CONFIG_DRIVER_TI_CPSW to Kconfig
> >>
> >> Signed-off-by: Alex Kiernan 
> >> Acked-by: Joe Hershberger 
> > 
> > Applied to u-boot/master, thanks!
> 
> Why did you apply this patch? It introduces a build warning?

Wait, where does it introduce a warning?  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] imx: nitrogen6x: Convert Sabrelite to distro boot support

[Gary Bisson]

Hi Fabio,

On Mon, Apr 09, 2018 at 02:27:31PM -0300, Fabio Estevam wrote:
> Hi Gary,
> 
> On Mon, Apr 9, 2018 at 11:40 AM, Gary Bisson
>  wrote:
> 
> >>  #define CONFIG_EXTRA_ENV_SETTINGS \
> >> - "script=boot.scr\0" \
> >> - "uimage=uImage\0" \
> >>   "console=ttymxc1\0" \
> >>   "fdt_high=0x\0" \
> >>   "initrd_high=0x\0" \
> >> - "fdt_file=imx6q-sabrelite.dtb\0" \
> >> + "fdtfile=imx6q-sabrelite.dtb\0" \
> >
> > I wish the default efi_fdtfile would work, Fabio is there any plan to
> > populate the ${soc} variable like it is done for i.MX7? [2]
> 
> It seems we didn't need to do this yet, but if you see a need for it,
> please post a patch.

Will do.

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

Re: [U-Boot] [PATCH] imx: nitrogen6x: Convert Sabrelite to distro boot support

[Gary Bisson]

Hi Guillaume,

On Mon, Apr 09, 2018 at 05:17:44PM +0200, Guillaume Gardet wrote:
> 
> 
> Le 09/04/2018 à 16:40, Gary Bisson a écrit :
> > Hi Guillaume,
> > 
> > Thanks for your patch! Switching the upstream nitrogen6x configuration
> > to distro bootcmd has been in our todo list for some time since we also
> > use that in our own git repo.
> > 
> > On Fri, Apr 06, 2018 at 12:05:48PM +0200, Guillaume GARDET wrote:
> > > Boot tested with boot.scr script and EFI/Grub2 on mmc0 and mmc1 slots.
> > > 
> > > Signed-off-by: Guillaume GARDET 
> > > Cc: Troy Kisky 
> > > Cc: Stefano Babic 
> > > Cc: Fabio Estevam 
> > > ---
> > >   include/configs/nitrogen6x.h | 86 
> > > ++--
> > >   1 file changed, 18 insertions(+), 68 deletions(-)
> > > 
> > > diff --git a/include/configs/nitrogen6x.h b/include/configs/nitrogen6x.h
> > > index c73cfb7f7e..2e2c499cb6 100644
> > > --- a/include/configs/nitrogen6x.h
> > > +++ b/include/configs/nitrogen6x.h
> > > @@ -102,82 +102,32 @@
> > >   #define CONFIG_UMSDEVS CONFIG_DRIVE_SATA CONFIG_DRIVE_MMC
> > >   #if defined(CONFIG_SABRELITE)
> > Please also switch nitrogen6x to it, not only sabrelite.
> 
> Should we keep all the 6x scripts stuff or not?

No, we need to switch to something standard, let's remove it.

> > > +#define BOOT_TARGET_DEVICES(func) \
> > > + func(MMC, mmc, 0) \
> > > + func(MMC, mmc, 1) \
> > > + func(SATA, sata, 0) \
> > > + func(USB, usb, 0) \
> > > + func(PXE, pxe, na) \
> > That currently doesn't build because CMD_PXE isn't selected in the
> > sabrelite defconfig.
> > "include/config_distro_bootcmd.h:319:2: error: expected ‘}’ before
> > ‘BOOT_TARGET_DEVICES_references_PXE_without_CONFIG_CMD_DHCP_or_PXE’"
> > 
> > Which brings a good point, all the above should depend on the storage
> > command being present, like done here [1].
> 
> No, we just need to update the defconfig, see V2 of this patch sent earlier 
> today.

I know updating the defconfig makes it build. My point is that it would
be more flexible to do like in the link provided so that someone that
removes CMD_PXE from the defconfig for any reason can still build.

> > > + func(DHCP, dhcp, na)
> > > +
> > > +#include 
> > > +
> > >   #define CONFIG_EXTRA_ENV_SETTINGS \
> > > - "script=boot.scr\0" \
> > > - "uimage=uImage\0" \
> > >   "console=ttymxc1\0" \
> > >   "fdt_high=0x\0" \
> > >   "initrd_high=0x\0" \
> > > - "fdt_file=imx6q-sabrelite.dtb\0" \
> > > + "fdtfile=imx6q-sabrelite.dtb\0" \
> > I wish the default efi_fdtfile would work, Fabio is there any plan to
> > populate the ${soc} variable like it is done for i.MX7? [2]
> > Then a small patch in the nitrogen6x.c would set the proper board env
> > variable.
> > 
> > That way there would be no difference in this header between sabrelite
> > vs. nitrogen6x.
> > 
> > >   "fdt_addr=0x1800\0" \
> > Do we need to keep fdt_addr since we define fdt_addr_r below?
> 
> It was for backward compatibility, if people had some script using it.

I think it should be dropped.

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

Re: [U-Boot] [PATCH 3/3] core: Add dev_{disable,enable}_by_path

[Mario Six]

Hi Simon,

On Fri, Mar 30, 2018 at 12:43 AM, Simon Glass  wrote:
> Hi Mario,
>
> On 28 March 2018 at 20:37, Mario Six  wrote:
>> We cannot use device structures to disable devices, since getting
>> them with the API functions would bind and activate the device, which
>> would fail if the underlying device does not exist.
>>
>> Hence, add a function to disable devices by path in a live device tree.
>
> What is the use case here? Is it to disable something after it has
> already been bound / probed? Why can this not be done in the device
> tree before U-Boot starts?
>

The devices that may not be in the tree are all disabled in the device tree.
Then, we detect which devices are actually there, and enable those that are.
That way we can use a single device tree for lots of actual boards, which are
all very minor variants of each other.

> Also this needs a test.
>
>>
>> Signed-off-by: Mario Six 
>> ---
>>  drivers/core/device.c | 36 
>>  include/dm/device.h   | 20 
>>  2 files changed, 56 insertions(+)
>>
>> diff --git a/drivers/core/device.c b/drivers/core/device.c
>> index 940a153c58..c627453bb9 100644
>> --- a/drivers/core/device.c
>> +++ b/drivers/core/device.c
>> @@ -724,3 +724,39 @@ bool of_machine_is_compatible(const char *compat)
>>
>> return !fdt_node_check_compatible(fdt, 0, compat);
>>  }
>> +
>> +#ifdef CONFIG_OF_LIVE
>> +int dev_disable_by_path(const char *path)
>> +{
>> +   ofnode node = np_to_ofnode(of_find_node_by_path(path));
>
> Please see ofnode_path()
>
>> +   struct udevice *dev = ofnode_dev(node);
>> +   int res;
>> +
>> +   res = device_remove(dev, DM_REMOVE_NORMAL);
>> +   if (res)
>> +   return res;
>> +
>> +   res = device_unbind(dev);
>> +   if (res)
>> +   return res;
>> +
>> +   return ofnode_disable(node);
>> +}
>> +
>> +int dev_enable_by_path(const char *path)
>> +{
>> +   ofnode node = np_to_ofnode(of_find_node_by_path(path));
>> +   ofnode pnode = ofnode_get_parent(node);
>> +   struct udevice *parent = ofnode_dev(pnode);
>> +   int res;
>> +
>> +   if (!parent)
>> +   return -EINVAL;
>> +
>> +   res = ofnode_enable(node);
>> +   if (res)
>> +   return res;
>> +
>> +   return lists_bind_fdt(parent, node, NULL);
>> +}
>> +#endif /* CONFIG_OF_LIVE */
>> diff --git a/include/dm/device.h b/include/dm/device.h
>> index 7786b1cf4e..f55907966a 100644
>> --- a/include/dm/device.h
>> +++ b/include/dm/device.h
>> @@ -586,6 +586,26 @@ bool device_is_compatible(struct udevice *dev, const 
>> char *compat);
>>   */
>>  bool of_machine_is_compatible(const char *compat);
>>
>> +#ifdef CONFIG_OF_LIVE
>> +
>> +/**
>> + * dev_disable_by_path() - Disable a device given its device tree path
>> + *
>> + * @path:  The device tree path identifying the device to be disabled
>> + * @return 0 on success, -ve on error
>> + */
>> +int dev_disable_by_path(const char *path);
>> +
>> +/**
>> + * dev_enable_by_path() - Enable a device given its device tree path
>> + *
>> + * @path:  The device tree path identifying the device to be enabled
>> + * @return 0 on success, -ve on error
>> + */
>> +int dev_enable_by_path(const char *path);
>> +
>> +#endif /* CONFIG_OF_LIVE */
>> +
>>  /**
>>   * device_is_on_pci_bus - Test if a device is on a PCI bus
>>   *
>> --
>> 2.16.1
>>
>
> Regards,
> Simon

Everything else will be addressed in v2. Thanks for reviewing!

Best regards,

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

[U-Boot] [PATCH v5 2/2] SF: add support for sst26wf016, sst26wf032, sst26wf064

[Eugeniy Paltsev]

This commit adds support for the SST sst26wf016, sst26wf032
and sst26wf064 flash IC.

Signed-off-by: Eugeniy Paltsev 
---
Changes v4->v5:
 * None.

Changes v3->v4:
 * None.

Changes v2->v3:
 * None.

Changes v1->v2:
 * None.

 drivers/mtd/spi/spi_flash_ids.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/mtd/spi/spi_flash_ids.c b/drivers/mtd/spi/spi_flash_ids.c
index b789219e4e..dbb4ac4d32 100644
--- a/drivers/mtd/spi/spi_flash_ids.c
+++ b/drivers/mtd/spi/spi_flash_ids.c
@@ -151,6 +151,9 @@ const struct spi_flash_info spi_flash_ids[] = {
{"sst25wf040", INFO(0xbf2504, 0x0,  64 * 1024, 8, SECT_4K | 
SST_WR) },
{"sst25wf040b",INFO(0x621613, 0x0,  64 * 1024, 8, SECT_4K) },
{"sst25wf080", INFO(0xbf2505, 0x0,  64 * 1024,16, SECT_4K | 
SST_WR) },
+   {"sst26wf016", INFO(0xbf2651, 0x0,  64 * 1024,32, SECT_4K) },
+   {"sst26wf032", INFO(0xbf2622, 0x0,  64 * 1024,64, SECT_4K) },
+   {"sst26wf064", INFO(0xbf2643, 0x0,  64 * 1024,   128, SECT_4K) },
 #endif
 #ifdef CONFIG_SPI_FLASH_WINBOND/* WINBOND */
{"w25p80", INFO(0xef2014, 0x0,  64 * 1024,16, 0) },
-- 
2.14.3

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

[U-Boot] [PATCH v5 1/2] SPI Flash: add support of sst26wf* flash ICs protection ops

[Eugeniy Paltsev]

sst26wf flash series block protection implementation differs
from other SST series, so add specific implementation
flash_lock/flash_unlock/flash_is_locked functions for sst26wf
flash ICs.

Signed-off-by: Eugeniy Paltsev 
---
Changes v4->v5:
 * Return EACCES when flash is locked instead of custom define (SF_LOCKED)
 * Add SST26_CTL_* prefix to sst27 lock ops enum.
 * Move all sst26 code inside of existing CONFIG_SPI_FLASH_SST #ifdef.

Changes v3->v4:
 * Make sst26_process_bpr() and sst26_lock_ctl() functions static.

Changes v2->v3:
 * Move SST26 command defenition to sf_internal.h
 * Merge sst26_set_bpr, sst26_clear_bpr and sst26_check_bpr functions
   into single sst26_process_bpr function.
 * Use SF_UNLOCKED/SF_LOCKED instead of magic numbers in
   sst26_lock_ctl()

Changes v1->v2:
 * Use generic defines from linux/sizes.h instead of custom ones.

 drivers/mtd/spi/sf_internal.h |  13 
 drivers/mtd/spi/spi_flash.c   | 168 ++
 2 files changed, 181 insertions(+)

diff --git a/drivers/mtd/spi/sf_internal.h b/drivers/mtd/spi/sf_internal.h
index 839cdbe1b0..614a293234 100644
--- a/drivers/mtd/spi/sf_internal.h
+++ b/drivers/mtd/spi/sf_internal.h
@@ -87,6 +87,19 @@ enum spi_nor_option_flags {
 
 /* SST specific */
 #ifdef CONFIG_SPI_FLASH_SST
+#define SST26_CMD_READ_BPR 0x72
+#define SST26_CMD_WRITE_BPR0x42
+
+#define SST26_BPR_8K_NUM   4
+#define SST26_MAX_BPR_REG_LEN  (18 + 1)
+#define SST26_BOUND_REG_SIZE   ((32 + SST26_BPR_8K_NUM * 8) * SZ_1K)
+
+enum lock_ctl {
+   SST26_CTL_LOCK,
+   SST26_CTL_UNLOCK,
+   SST26_CTL_CHECK
+};
+
 # define CMD_SST_BP0x02/* Byte Program */
 # define CMD_SST_AAI_WP0xAD/* Auto Address Incr Word 
Program */
 
diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 2e61685d3e..5e5bd5d533 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "sf_internal.h"
@@ -541,6 +542,164 @@ int spi_flash_cmd_read_ops(struct spi_flash *flash, u32 
offset,
 }
 
 #ifdef CONFIG_SPI_FLASH_SST
+static bool sst26_process_bpr(u32 bpr_size, u8 *cmd, u32 bit, enum lock_ctl 
ctl)
+{
+   switch (ctl) {
+   case SST26_CTL_LOCK:
+   cmd[bpr_size - (bit / 8) - 1] |= BIT(bit % 8);
+   break;
+   case SST26_CTL_UNLOCK:
+   cmd[bpr_size - (bit / 8) - 1] &= ~BIT(bit % 8);
+   break;
+   case SST26_CTL_CHECK:
+   return !!(cmd[bpr_size - (bit / 8) - 1] & BIT(bit % 8));
+   }
+
+   return false;
+}
+
+/*
+ * sst26wf016/sst26wf032/sst26wf064 have next block protection:
+ * 4x   - 8  KByte blocks - read & write protection bits - upper addresses
+ * 1x   - 32 KByte blocks - write protection bits
+ * rest - 64 KByte blocks - write protection bits
+ * 1x   - 32 KByte blocks - write protection bits
+ * 4x   - 8  KByte blocks - read & write protection bits - lower addresses
+ *
+ * We'll support only per 64k lock/unlock so lower and upper 64 KByte region
+ * will be treated as single block.
+ */
+
+/*
+ * Lock, unlock or check lock status of the flash region of the flash 
(depending
+ * on the lock_ctl value)
+ */
+static int sst26_lock_ctl(struct spi_flash *flash, u32 ofs, size_t len, enum 
lock_ctl ctl)
+{
+   u32 i, bpr_ptr, rptr_64k, lptr_64k, bpr_size;
+   bool lower_64k = false, upper_64k = false;
+   u8 cmd, bpr_buff[SST26_MAX_BPR_REG_LEN] = {};
+   int ret;
+
+   /* Check length and offset for 64k alignment */
+   if ((ofs & (SZ_64K - 1)) || (len & (SZ_64K - 1)))
+   return -EINVAL;
+
+   if (ofs + len > flash->size)
+   return -EINVAL;
+
+   /* SST26 family has only 16 Mbit, 32 Mbit and 64 Mbit IC */
+   if (flash->size != SZ_2M &&
+   flash->size != SZ_4M &&
+   flash->size != SZ_8M)
+   return -EINVAL;
+
+   bpr_size = 2 + (flash->size / SZ_64K / 8);
+
+   cmd = SST26_CMD_READ_BPR;
+   ret = spi_flash_read_common(flash, , 1, bpr_buff, bpr_size);
+   if (ret < 0) {
+   printf("SF: fail to read block-protection register\n");
+   return ret;
+   }
+
+   rptr_64k = min_t(u32, ofs + len , flash->size - SST26_BOUND_REG_SIZE);
+   lptr_64k = max_t(u32, ofs, SST26_BOUND_REG_SIZE);
+
+   upper_64k = ((ofs + len) > (flash->size - SST26_BOUND_REG_SIZE));
+   lower_64k = (ofs < SST26_BOUND_REG_SIZE);
+
+   /* Lower bits in block-protection register are about 64k region */
+   bpr_ptr = lptr_64k / SZ_64K - 1;
+
+   /* Process 64K blocks region */
+   while (lptr_64k < rptr_64k) {
+   if (sst26_process_bpr(bpr_size, bpr_buff, bpr_ptr, ctl))
+   return EACCES;
+
+   bpr_ptr++;
+ 

[U-Boot] [PATCH v5 0/2] SF: add support for sst26wf016, sst26wf032, sst26wf064

[Eugeniy Paltsev]

Add support for the SST sst26wf016, sst26wf032 and sst26wf064 flash IC:

sst26wf*** flash series block protection implementation differs from other
SST series, so we add implementation for sst26wf*** lock/unlock/is_locked
functions.

Add sst26wf016, sst26wf032 and sst26wf064 flash IC info to spi_flash_ids list.

Changes v4->v5:
 * Return EACCES when flash is locked instead of custom define (SF_LOCKED)
 * Add SST26_CTL_* prefix to sst27 lock ops enum.
 * Move all sst26 code inside of existing CONFIG_SPI_FLASH_SST #ifdef.

Changes v3->v4:
 * Make sst26_process_bpr() and sst26_lock_ctl() functions static.

Changes v2->v3:
 * Move SST26 command defenition to sf_internal.h
 * Merge sst26_set_bpr, sst26_clear_bpr and sst26_check_bpr functions
   into single sst26_process_bpr function.
 * Use SF_UNLOCKED/SF_LOCKED instead of magic numbers in
   sst26_lock_ctl()

Changes v1->v2:
 * Use generic defines from linux/sizes.h instead of custom ones.

Eugeniy Paltsev (2):
  SPI Flash: add support of sst26wf* flash ICs protection ops
  SF: add support for sst26wf016, sst26wf032, sst26wf064

 drivers/mtd/spi/sf_internal.h   |  18 +
 drivers/mtd/spi/spi_flash.c | 165 
 drivers/mtd/spi/spi_flash_ids.c |   3 +
 3 files changed, 186 insertions(+)

-- 
2.14.3

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

Re: [U-Boot] [PATCH 1/3] drivers: Add OSD uclass

[Mario Six]

Hi Simon,

On Fri, Mar 30, 2018 at 12:42 AM, Simon Glass  wrote:
> Hi Mario,
>
> On 28 March 2018 at 20:39, Mario Six  wrote:
>> Some devices offer a text-based OSD (on-screen display) that can be
>> programmatically controlled (i.e. text displayed on).
>>
>> Add a uclass to support such devices.
>>
>> Signed-off-by: Mario Six 
>> ---
>>  drivers/video/Kconfig|   8 +++
>>  drivers/video/Makefile   |   2 +
>>  drivers/video/video_osd-uclass.c |  47 +
>>  include/dm/uclass-id.h   |   1 +
>>  include/video_osd.h  | 145 
>> +++
>>  5 files changed, 203 insertions(+)
>>  create mode 100644 drivers/video/video_osd-uclass.c
>>  create mode 100644 include/video_osd.h
>
> Please add a sandbox driver and simple test for this. All uclasses
> should have this.
>
>>
>> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
>> index 2fc0defcd0..da60bbe692 100644
>> --- a/drivers/video/Kconfig
>> +++ b/drivers/video/Kconfig
>> @@ -660,4 +660,12 @@ config VIDEO_DT_SIMPLEFB
>>   The video output is initialized by U-Boot, and kept by the
>>   kernel.
>>
>> +config OSD
>> +   bool "Enable OSD support"
>> +   depends on DM
>> +   default n
>> +   help
>> +  This supports drivers that provide a OSD (on-screen display), 
>> which
>> +  is a (usually text-oriented) graphics buffer to show information 
>> on
>> +  a display.
>>  endmenu
>> diff --git a/drivers/video/Makefile b/drivers/video/Makefile
>> index dfafe08fc5..209d5e3a75 100644
>> --- a/drivers/video/Makefile
>> +++ b/drivers/video/Makefile
>> @@ -58,5 +58,7 @@ obj-${CONFIG_EXYNOS_FB} += exynos/
>>  obj-${CONFIG_VIDEO_ROCKCHIP} += rockchip/
>>  obj-${CONFIG_VIDEO_STM32} += stm32/
>>
>> +obj-${CONFIG_OSD} += video_osd-uclass.o
>> +
>>  obj-y += bridge/
>>  obj-y += sunxi/
>> diff --git a/drivers/video/video_osd-uclass.c 
>> b/drivers/video/video_osd-uclass.c
>> new file mode 100644
>> index 00..b6dd7e59b1
>> --- /dev/null
>> +++ b/drivers/video/video_osd-uclass.c
>> @@ -0,0 +1,47 @@
>> +/*
>> + * (C) Copyright 2017
>> + * Mario Six,  Guntermann & Drunck GmbH, mario@gdsys.cc
>> + *
>> + * SPDX-License-Identifier:GPL-2.0+
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +
>> +int video_osd_get_data(struct udevice *dev, void *data)
>> +{
>> +   struct video_osd_ops *ops = video_osd_get_ops(dev);
>> +
>> +   return ops->get_data(dev, data);
>> +}
>> +
>> +int video_osd_set_mem(struct udevice *dev, uint x, uint y, u8 *buf,
>> + size_t buflen, uint count)
>> +{
>> +   struct video_osd_ops *ops = video_osd_get_ops(dev);
>> +
>> +   return ops->set_mem(dev, x, y, buf, buflen, count);
>> +}
>> +
>> +int video_osd_set_size(struct udevice *dev, uint x, uint y)
>> +{
>> +   struct video_osd_ops *ops = video_osd_get_ops(dev);
>> +
>> +   return ops->set_size(dev, x, y);
>> +}
>> +
>> +int video_osd_print(struct udevice *dev, uint x, uint y, ulong color,
>> +   char *text)
>> +{
>> +   struct video_osd_ops *ops = video_osd_get_ops(dev);
>> +
>> +   return ops->print(dev, x, y, color, text);
>> +}
>> +
>> +UCLASS_DRIVER(video_osd) = {
>> +   .id = UCLASS_VIDEO_OSD,
>> +   .name   = "video_osd",
>> +   .flags  = DM_UC_FLAG_SEQ_ALIAS,
>> +};
>> +
>> diff --git a/include/dm/uclass-id.h b/include/dm/uclass-id.h
>> index 07fabc3ce6..685f22550a 100644
>> --- a/include/dm/uclass-id.h
>> +++ b/include/dm/uclass-id.h
>> @@ -89,6 +89,7 @@ enum uclass_id {
>> UCLASS_VIDEO,   /* Video or LCD device */
>> UCLASS_VIDEO_BRIDGE,/* Video bridge, e.g. DisplayPort to LVDS */
>> UCLASS_VIDEO_CONSOLE,   /* Text console driver for video device */
>> +   UCLASS_VIDEO_OSD,   /* On-screen displays */
>
> please use singular
>
>> UCLASS_WDT, /* Watchdot Timer driver */
>>
>> UCLASS_COUNT,
>> diff --git a/include/video_osd.h b/include/video_osd.h
>> new file mode 100644
>> index 00..1ab5ff9b21
>> --- /dev/null
>> +++ b/include/video_osd.h
>> @@ -0,0 +1,145 @@
>> +/*
>> + * (C) Copyright 2017
>> + * Mario Six,  Guntermann & Drunck GmbH, mario@gdsys.cc
>> + *
>> + * SPDX-License-Identifier:GPL-2.0+
>> + */
>> +
>> +#ifndef _VIDEO_OSD_H_
>> +#define _VIDEO_OSD_H_
>> +
>> +/**
>> + * struct video_osd_ops - driver operations for OSD uclass
>> + *
>
> Please add a general description of what this uclass is and how it works
>
>> + * Drivers should support these operations unless otherwise noted. These
>> + * operations are intended to be used by uclass code, not directly from
>> + * other code.
>> + */
>> +struct video_osd_ops {
>> +   /**
>> +* get_data() - Get information about a OSD instance
>> +*
>> +* A OSD instance may keep some internal data about itself. This
>> 

Re: [U-Boot] [PATCH 1/3] core: Add function to get device for ofnode

[Mario Six]

Hi Simon,

On Fri, Mar 30, 2018 at 12:43 AM, Simon Glass  wrote:
> Hi Mario,
>
> On 28 March 2018 at 20:37, Mario Six  wrote:
>> It's sometimes useful to get the device associated with a given ofnode.
>> Implement a function to implement this lookup operation.
>
> Where would you use this? Can you not use phandles to find the device?
> Or uclass_get_device_by_ofnode() ?
>

The function is used with the dev_{enable,disable}_by_path in the next patch:
If I used any of the uclass_* functions or similar, the device would be probed,
which is not what I want, since the device may not actually be physically
present.

>>
>> Signed-off-by: Mario Six 
>> ---
>>  drivers/core/ofnode.c | 15 +++
>>  include/dm/ofnode.h   |  8 
>>  2 files changed, 23 insertions(+)
>>
>> diff --git a/drivers/core/ofnode.c b/drivers/core/ofnode.c
>> index 4e4532651f..ca002063b3 100644
>> --- a/drivers/core/ofnode.c
>> +++ b/drivers/core/ofnode.c
>> @@ -16,6 +16,21 @@
>>  #include 
>>  #include 
>>
>> +struct udevice *ofnode_dev(ofnode node)
>
> Can you please add a test for this?
>
> This seems like an internal function since it does not probe the
> device. So how about putting it in device.h:
>
> device_get_by_ofnode() - does probe the device it returns
> device_find_by_ofnode() - doesn't probe
>
>> +{
>> +   struct uclass *uc;
>> +   struct udevice *dev;
>> +
>> +   list_for_each_entry(uc, >uclass_root, sibling_node) {
>> +   list_for_each_entry(dev, >dev_head, uclass_node) {
>> +   if (ofnode_equal(dev_ofnode(dev), node))
>> +   return dev;
>> +   }
>> +   }
>> +
>> +   return NULL;
>> +}
>> +
>>  int ofnode_read_u32(ofnode node, const char *propname, u32 *outp)
>>  {
>> assert(ofnode_valid(node));
>> diff --git a/include/dm/ofnode.h b/include/dm/ofnode.h
>> index 0d008404f9..aec205eb80 100644
>> --- a/include/dm/ofnode.h
>> +++ b/include/dm/ofnode.h
>> @@ -193,6 +193,14 @@ static inline ofnode ofnode_null(void)
>> return node;
>>  }
>>
>> +/**
>> + * ofnode_dev() - Get the device associated with a given ofnode
>> + *
>> + * @node:  valid node reference to get the corresponding device for
>> + * @return a pointer to the udevice if OK, NULL on error
>> + */
>> +struct udevice *ofnode_dev(ofnode node);
>> +
>>  /**
>>   * ofnode_read_u32() - Read a 32-bit integer from a property
>>   *
>> --
>> 2.16.1
>>
>
> Regards,
> Simon
>

Everything else will be addressed in v2. Thanks for reviewing!

Best regards,

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

Re: [U-Boot] [PATCH 2/3] core: Add functions to set properties in live-tree

[Mario Six]

Hi Simon,

On Fri, Mar 30, 2018 at 12:43 AM, Simon Glass  wrote:
> Hi Mario,
>
> On 28 March 2018 at 20:37, Mario Six  wrote:
>> Implement a set of functions to manipulate properties in a live device
>> tree:
>>
>> * ofnode_set_property() to set generic properties of a node
>> * ofnode_write_string() to set string properties of a node
>> * ofnode_enable() to enable a node
>> * ofnode_disable() to disable a node
>>
>
> Please add a test for these functions.
>
>> Signed-off-by: Mario Six 
>> ---
>>  drivers/core/ofnode.c | 58 
>> +++
>>  include/dm/ofnode.h   | 49 +++
>>  2 files changed, 107 insertions(+)
>>
>> diff --git a/drivers/core/ofnode.c b/drivers/core/ofnode.c
>> index ca002063b3..90d05aa559 100644
>> --- a/drivers/core/ofnode.c
>> +++ b/drivers/core/ofnode.c
>> @@ -699,3 +699,61 @@ u64 ofnode_translate_address(ofnode node, const fdt32_t 
>> *in_addr)
>> else
>> return fdt_translate_address(gd->fdt_blob, 
>> ofnode_to_offset(node), in_addr);
>>  }
>> +
>> +#ifdef CONFIG_OF_LIVE
>
> Is this needed?
>

See below, these functions don't make sense if there is no livetree.

>> +int ofnode_set_property(ofnode node, const char *propname, int len,
>> +   const void *value)
>> +{
>> +   const struct device_node *np = ofnode_to_np(node);
>> +   struct property *pp;
>> +   struct property *new;
>> +
>> +   if (!np)
>> +   return -EINVAL;
>> +
>> +   for (pp = np->properties; pp; pp = pp->next) {
>> +   if (strcmp(pp->name, propname) == 0) {
>> +   /* Property exists -> change value */
>> +   pp->value = (void *)value;
>> +   pp->length = len;
>> +   return 0;
>> +   }
>> +   }
>> +
>> +   /* Property does not exist -> append new property */
>> +   new = malloc(sizeof(struct property));
>> +
>> +   new->name = strdup(propname);
>> +   new->value = malloc(len);
>> +   memcpy(new->value, value, len);
>> +   new->length = len;
>> +   new->next = NULL;
>> +
>> +   pp->next = new;
>> +
>> +   return 0;
>> +}
>> +
>> +int ofnode_write_string(ofnode node, const char *propname, const char 
>> *value)
>> +{
>> +   assert(ofnode_valid(node));
>
> What does this function do if livetree is not enabled?
>

The idea was to not make them available if livetree is not enabled (hence the
#ifdef CONFIG_OF_LIVE).

Making them nops in case livetree is not available would work as well if
that's preferable.

>> +   debug("%s: %s = %s", __func__, propname, value);
>> +
>> +   return ofnode_set_property(node, propname, strlen(value) + 1, value);
>> +}
>> +
>> +int ofnode_enable(ofnode node)
>> +{
>> +   assert(ofnode_valid(node));
>> +
>> +   return ofnode_write_string(node, "status", "okay");
>> +}
>> +
>> +int ofnode_disable(ofnode node)
>> +{
>> +   assert(ofnode_valid(node));
>> +
>> +   return ofnode_write_string(node, "status", "disable");
>> +}
>> +
>> +#endif
>> diff --git a/include/dm/ofnode.h b/include/dm/ofnode.h
>> index aec205eb80..e82ebf19c5 100644
>> --- a/include/dm/ofnode.h
>> +++ b/include/dm/ofnode.h
>> @@ -689,4 +689,53 @@ int ofnode_read_resource_byname(ofnode node, const char 
>> *name,
>>   * @return the translated address; OF_BAD_ADDR on error
>>   */
>>  u64 ofnode_translate_address(ofnode node, const fdt32_t *in_addr);
>> +
>> +#ifdef CONFIG_OF_LIVE
>> +
>> +/**
>> + * ofnode_set_property() - Set a property of a ofnode
>> + *
>> + * @node:  The node for whose property should be set
>> + * @propname:  The name of the property to set
>> + * @len:   The length of the new value of the property
>> + * @value: The new value of the property
>> + * @return 0 if successful, -ve on error
>> + */
>> +int ofnode_set_property(ofnode node, const char *propname, int len,
>> +   const void *value);
>
> We should think about consistency here. Maybe
>
> ofnode_write_prop()?
>
>> +
>> +/**
>> + * ofnode_write_string() - Set a string property of a ofnode
>> + *
>> + * @node:  The node for whose string property should be set
>> + * @propname:  The name of the string property to set
>> + * @value: The new value of the string property
>> + * @return 0 if successful, -ve on error
>> + */
>> +int ofnode_write_string(ofnode node, const char *propname, const char 
>> *value);
>> +
>> +/**
>> + * ofnode_enable() - Enable a device tree node given by its ofnode
>> + *
>> + * This function effectively sets the node's "status" property to "okay", 
>> hence
>> + * making it available for driver model initialization.
>> + *
>> + * @node:  The node to enable
>> + * @return 0 if successful, -ve on error
>> + */
>> +int ofnode_enable(ofnode node);
>> +
>> +/**
>> + * ofnode_disable() - Disable a device tree node 

Re: [U-Boot] [PATCH 3/3] cmd: Add osd commands

[Mario Six]

Hi Simon,

On Fri, Mar 30, 2018 at 12:42 AM, Simon Glass  wrote:
> Hi Mario,
>
> On 28 March 2018 at 20:39, Mario Six  wrote:
>> Add command to query information from and write text to IHS OSDs.
>>
>> Signed-off-by: Mario Six 
>> ---
>>  cmd/Kconfig  |  16 +++
>>  cmd/Makefile |   1 +
>>  cmd/osd.c| 366 
>> +++
>>  3 files changed, 383 insertions(+)
>>  create mode 100644 cmd/osd.c
>>
>> diff --git a/cmd/Kconfig b/cmd/Kconfig
>> index 136836d146..0d60051960 100644
>> --- a/cmd/Kconfig
>> +++ b/cmd/Kconfig
>> @@ -846,6 +846,22 @@ config CMD_ONENAND
>>   and erasing blocks. It allso provides a way to show and change
>>   bad blocks, and test the device.
>>
>> +config CMD_OSD
>> +   bool "osd"
>> +   help
>> + Enable the 'osd' command which allows to query information from and
>> + write text data to a OSD.
>
> Please expand help. E.g. what is an OSD?
>
>> +
>> +if CMD_OSD
>> +
>> +config GDSYS_LEGACY_OSD_CMDS
>> +   bool "Use legacy gdsys-specific commands"
>> +   help
>> + Use the 'osdw', 'osdp', and 'osdsize' legacy commands required by
>> + gdsys devices.
>> +
>> +endif
>> +
>>  config CMD_PART
>> bool "part"
>> select PARTITION_UUIDS
>> diff --git a/cmd/Makefile b/cmd/Makefile
>> index 9a358e4801..d3f7522700 100644
>> --- a/cmd/Makefile
>> +++ b/cmd/Makefile
>> @@ -61,6 +61,7 @@ obj-$(CONFIG_CMD_FS_GENERIC) += fs.o
>>  obj-$(CONFIG_CMD_FUSE) += fuse.o
>>  obj-$(CONFIG_CMD_GETTIME) += gettime.o
>>  obj-$(CONFIG_CMD_GPIO) += gpio.o
>> +obj-$(CONFIG_CMD_OSD) += osd.o
>>  obj-$(CONFIG_CMD_I2C) += i2c.o
>>  obj-$(CONFIG_CMD_IOTRACE) += iotrace.o
>>  obj-$(CONFIG_CMD_HASH) += hash.o
>> diff --git a/cmd/osd.c b/cmd/osd.c
>> new file mode 100644
>> index 00..bbabfc3c54
>> --- /dev/null
>> +++ b/cmd/osd.c
>> @@ -0,0 +1,366 @@
>> +/*
>> + * (C) Copyright 2017
>> + * Mario Six,  Guntermann & Drunck GmbH, mario@gdsys.cc
>> + *
>> + * based on the gdsys osd driver, which is
>> + *
>> + * (C) Copyright 2010
>> + * Dirk Eibach,  Guntermann & Drunck GmbH, eib...@gdsys.de
>> + *
>> + * SPDX-License-Identifier:GPL-2.0+
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#ifndef CONFIG_GDSYS_LEGACY_OSD_CMDS
>> +static struct udevice *osd_cur;
>> +#endif
>> +
>> +void hexstr_to_u8_array(char *hexstr, u8 *array, size_t arrsize)
>> +{
>> +   size_t pos;
>> +
>> +   for (pos = 0; pos < arrsize; ++pos) {
>> +   char substr[3];
>> +
>> +   memcpy(substr, hexstr, 2);
>> +   substr[2] = 0;
>> +   *array = simple_strtoul(substr, NULL, 16);
>> +
>> +   hexstr += 2;
>> +   array++;
>> +   if (*hexstr == 0)
>> +   break;
>> +   }
>> +}
>
> Feels like we have a function like this already in U-Boot?
>

If I haven't completely overlooked it, there isn't. The Linux kernel has
hexdump.c, which we could (partially?) import for this purpose. It seems pretty
useful in general.

>> +
>> +#ifdef CONFIG_GDSYS_LEGACY_OSD_CMDS
>> +int do_osd_write(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
>> +{
>> +   struct udevice *dev;
>> +   uint x, y;
>> +   uint count;
>> +   char *hexstr;
>> +   u8 *buffer;
>> +   size_t buflen;
>> +
>> +   if (argc < 4 || (strlen(argv[3])) % 2) {
>> +   cmd_usage(cmdtp);
>> +   return 1;
>> +   }
>> +
>> +   x = simple_strtoul(argv[1], NULL, 16);
>> +   y = simple_strtoul(argv[2], NULL, 16);
>> +   hexstr = argv[3];
>> +   count = (argc > 4) ? simple_strtoul(argv[4], NULL, 16) : 1;
>> +
>> +   buflen = strlen(hexstr) / 2;
>> +   buffer = malloc(buflen);
>> +   hexstr_to_u8_array(hexstr, buffer, buflen);
>> +
>> +   for (uclass_first_device(UCLASS_VIDEO_OSD, );
>> +dev;
>> +uclass_next_device())
>> +   if (video_osd_set_mem(dev, x, y, buffer, buflen, count))
>> +   printf("Could not write to video mem on osd %s\n",
>> +  dev->name);
>
> It seems odd to write it on all devices. If you want to do this, it
> should be implemented in the uclass I think.
>
> Also you ignore errors here.
>
> Most commands allow you to select a particular device to work with.
> You have this feature below, so why not use it here?
>

This is actually the case if CONFIG_GDSYS_LEGACY_OSD_CMDS is not defined (which
is probably not that well-suited in the cmd/Kconfig now that I think about it;
I'll move that). This is because this command should be backwards-compatible
with our current OSD commands (which write to all available OSDs by default).
If CONFIG_GDSYS_LEGACY_OSD_CMDS is not defined, the commands work on a
by-device basis, and you can select the one you want to work with.

> Same below.
>
>> +
>> +   

[U-Boot] [PATCH 17/19] spi: mpc8xxx: Use get_timer

[Mario Six]

The comment before the transmission loop in conjunction with the
definition of SPI_TIMEOUT as 1000 implies that the loop is supposed to
have a timeout value of 1000 ms. But since there is no mdelay(1) or
similar in the loop body, the loop just runs 1000 times, without regard
for the time elapsed.

To correct this, use the standard get_timer functionality to properly
time out the loop after 1000 ms.

Signed-off-by: Mario Six 
---
 drivers/spi/mpc8xxx_spi.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/spi/mpc8xxx_spi.c b/drivers/spi/mpc8xxx_spi.c
index b3ed00fcb7..4aa5db8821 100644
--- a/drivers/spi/mpc8xxx_spi.c
+++ b/drivers/spi/mpc8xxx_spi.c
@@ -113,9 +113,9 @@ int spi_xfer(struct spi_slave *slave, uint bitlen, const 
void *dout, void *din,
 
/* Handle data in 32-bit chunks */
while (num_blks--) {
-   int tm;
u32 tmpdout = 0;
uchar xfer_bitlen = (bitlen >= 32 ? 32 : bitlen);
+   ulong start;
 
clrbits_be32(>mode, SPI_MODE_EN);
 
@@ -149,7 +149,8 @@ int spi_xfer(struct spi_slave *slave, uint bitlen, const 
void *dout, void *din,
 * or time out (1 second = 1000 ms)
 * The NE event must be read and cleared first
 */
-   for (tm = 0; tm < SPI_TIMEOUT; ++tm) {
+   start = get_timer(0);
+   do {
u32 event = in_be32(>event);
bool have_ne = event & SPI_EV_NE;
bool have_nf = event & SPI_EV_NF;
@@ -174,9 +175,11 @@ int spi_xfer(struct spi_slave *slave, uint bitlen, const 
void *dout, void *din,
 */
if (have_nf)
break;
-   }
 
-   if (tm >= SPI_TIMEOUT)
+   mdelay(1);
+   } while (get_timer(start) < SPI_TIMEOUT);
+
+   if (get_timer(start) >= SPI_TIMEOUT)
debug("*** %s: Time out during SPI transfer\n",
  __func__);
 
-- 
2.11.0

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

[U-Boot] [PATCH 03/19] spi: mpc8xxx: Rename camel-case variables

[Mario Six]

There are three variables that have camel-case names, which is not the
preferred naming style.

Give those variables more compliant names instead.

Signed-off-by: Mario Six 
---
 drivers/spi/mpc8xxx_spi.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/spi/mpc8xxx_spi.c b/drivers/spi/mpc8xxx_spi.c
index 2f6afaf7ac..3ac9f2f8e8 100644
--- a/drivers/spi/mpc8xxx_spi.c
+++ b/drivers/spi/mpc8xxx_spi.c
@@ -78,9 +78,9 @@ int spi_xfer(struct spi_slave *slave, uint bitlen, const void 
*dout, void *din,
 {
volatile spi8xxx_t *spi = &((immap_t *) (CONFIG_SYS_IMMR))->spi;
uint tmpdout, tmpdin, event;
-   int numBlks = DIV_ROUND_UP(bitlen, 32);
-   int tm, isRead = 0;
-   uchar charSize = 32;
+   int num_blks = DIV_ROUND_UP(bitlen, 32);
+   int tm, is_read = 0;
+   uchar char_size = 32;
 
debug("spi_xfer: slave %u:%u dout %08X din %08X bitlen %u\n",
  slave->bus, slave->cs, *(uint *) dout, *(uint *) din, bitlen);
@@ -92,12 +92,12 @@ int spi_xfer(struct spi_slave *slave, uint bitlen, const 
void *dout, void *din,
spi->event = 0x;
 
/* Handle data in 32-bit chunks */
-   while (numBlks--) {
+   while (num_blks--) {
tmpdout = 0;
-   charSize = (bitlen >= 32 ? 32 : bitlen);
+   char_size = (bitlen >= 32 ? 32 : bitlen);
 
/* Shift data so it's msb-justified */
-   tmpdout = *(u32 *) dout >> (32 - charSize);
+   tmpdout = *(u32 *) dout >> (32 - char_size);
 
/* The LEN field of the SPMODE register is set as follows:
 *
@@ -135,15 +135,15 @@ int spi_xfer(struct spi_slave *slave, uint bitlen, const 
void *dout, void *din,
 * or time out (1 second = 1000 ms)
 * The NE event must be read and cleared first
 */
-   for (tm = 0, isRead = 0; tm < SPI_TIMEOUT; ++tm) {
+   for (tm = 0, is_read = 0; tm < SPI_TIMEOUT; ++tm) {
event = spi->event;
if (event & SPI_EV_NE) {
tmpdin = spi->rx;
spi->event |= SPI_EV_NE;
-   isRead = 1;
+   is_read = 1;
 
-   *(u32 *) din = (tmpdin << (32 - charSize));
-   if (charSize == 32) {
+   *(u32 *) din = (tmpdin << (32 - char_size));
+   if (char_size == 32) {
/* Advance output buffer by 32 bits */
din += 4;
}
@@ -154,7 +154,7 @@ int spi_xfer(struct spi_slave *slave, uint bitlen, const 
void *dout, void *din,
 * in the future put an arbitrary delay after writing
 * the device.  Arbitrary delays suck, though...
 */
-   if (isRead && (event & SPI_EV_NF))
+   if (is_read && (event & SPI_EV_NF))
break;
}
if (tm >= SPI_TIMEOUT)
-- 
2.11.0

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

[U-Boot] [PATCH 16/19] spi: mpc8xxx: Fix if check

[Mario Six]

Decreasing the bit length and increasing the write data pointer should
be done when there are more than 32 bit of data, not 16 bit.

This did not produce incorrect behavior, because the only time where the
two checks produce different outcomes is the case of 16 < bitlen < 32,
and in this case the subsequent transmission is the last one regardless,
hence the additional bit length decrease and write data pointer increase
has no effect anyway.

Still, the correct check is the check for "bitlen > 32", so correct this
behavior.

Signed-off-by: Mario Six 
---
 drivers/spi/mpc8xxx_spi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/spi/mpc8xxx_spi.c b/drivers/spi/mpc8xxx_spi.c
index fe493f6d40..b3ed00fcb7 100644
--- a/drivers/spi/mpc8xxx_spi.c
+++ b/drivers/spi/mpc8xxx_spi.c
@@ -133,7 +133,7 @@ int spi_xfer(struct spi_slave *slave, uint bitlen, const 
void *dout, void *din,
/* Shift data so it's msb-justified */
tmpdout = *(u32 *)dout >> (32 - xfer_bitlen);
 
-   if (bitlen > 16) {
+   if (bitlen > 32) {
/* Set up the next iteration if sending > 32 bits */
bitlen -= 32;
dout += 4;
-- 
2.11.0

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

[U-Boot] [PATCH 12/19] spi: mpc8xxx: Make code more readable

[Mario Six]

Introduce the to_prescale_mod and set_char_len inline functions to make
the code more readable.

Note that the added "if (bitlen > 16)" check does not change the
semantics of the current code, and hence only preserves the current
error (this will be fixed in a later patch in the series).

Signed-off-by: Mario Six 
---
 drivers/spi/mpc8xxx_spi.c | 27 +++
 1 file changed, 19 insertions(+), 8 deletions(-)

diff --git a/drivers/spi/mpc8xxx_spi.c b/drivers/spi/mpc8xxx_spi.c
index 5bf84aaec6..af3762737f 100644
--- a/drivers/spi/mpc8xxx_spi.c
+++ b/drivers/spi/mpc8xxx_spi.c
@@ -31,6 +31,16 @@ enum {
SPI_COM_LST = BIT(31 - 9),
 };
 
+static inline u32 to_prescale_mod(u32 val)
+{
+   return (min(val, (u32)15) << 16);
+}
+
+static void set_char_len(spi8xxx_t *spi, u32 val)
+{
+   clrsetbits_be32(>mode, SPI_MODE_LEN_MASK, (val << 20));
+}
+
 #define SPI_TIMEOUT1000
 
 struct spi_slave *spi_setup_slave(uint bus, uint cs, uint max_hz, uint mode)
@@ -67,7 +77,7 @@ void spi_init(void)
 */
out_be32(>mode, SPI_MODE_REV | SPI_MODE_MS | SPI_MODE_EN);
/* Use SYSCLK / 8 (16.67MHz typ.) */
-   clrsetbits_be32(>mode, 0x000f, BIT(16));
+   clrsetbits_be32(>mode, SPI_MODE_PM_MASK, to_prescale_mod(1));
/* Clear all SPI events */
setbits_be32(>event, 0x);
/* Mask  all SPI interrupts */
@@ -120,13 +130,14 @@ int spi_xfer(struct spi_slave *slave, uint bitlen, const 
void *dout, void *din,
 
clrbits_be32(>mode, SPI_MODE_EN);
 
-   if (bitlen <= 4) {
-   clrsetbits_be32(>mode, 0x00f0, (3 << 20));
-   } else if (bitlen <= 16) {
-   clrsetbits_be32(>mode, 0x00f0,
-   ((bitlen - 1) << 20));
-   } else {
-   clrbits_be32(>mode, 0x00f0);
+   if (bitlen <= 4)
+   set_char_len(spi, 3);
+   else if (bitlen <= 16)
+   set_char_len(spi, bitlen - 1);
+   else
+   set_char_len(spi, 0);
+
+   if (bitlen > 16) {
/* Set up the next iteration if sending > 32 bits */
bitlen -= 32;
dout += 4;
-- 
2.11.0

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

[U-Boot] [PATCH 13/19] spi: mpc8xxx: Rename variable

[Mario Six]

The variable "char_size" holds the number of bits to be transferred in
the current loop iteration. A better name would be "xfer_bitlen", which
we rename this variable to.

Signed-off-by: Mario Six 
---
 drivers/spi/mpc8xxx_spi.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/spi/mpc8xxx_spi.c b/drivers/spi/mpc8xxx_spi.c
index af3762737f..ce2a77c1aa 100644
--- a/drivers/spi/mpc8xxx_spi.c
+++ b/drivers/spi/mpc8xxx_spi.c
@@ -115,10 +115,10 @@ int spi_xfer(struct spi_slave *slave, uint bitlen, const 
void *dout, void *din,
while (num_blks--) {
int tm;
u32 tmpdout = 0;
-   uchar char_size = (bitlen >= 32 ? 32 : bitlen);
+   uchar xfer_bitlen = (bitlen >= 32 ? 32 : bitlen);
 
/* Shift data so it's msb-justified */
-   tmpdout = *(u32 *)dout >> (32 - char_size);
+   tmpdout = *(u32 *)dout >> (32 - xfer_bitlen);
 
/* The LEN field of the SPMODE register is set as follows:
 *
@@ -166,8 +166,8 @@ int spi_xfer(struct spi_slave *slave, uint bitlen, const 
void *dout, void *din,
tmpdin = in_be32(>rx);
setbits_be32(>event, SPI_EV_NE);
 
-   *(u32 *)din = (tmpdin << (32 - char_size));
-   if (char_size == 32) {
+   *(u32 *)din = (tmpdin << (32 - xfer_bitlen));
+   if (xfer_bitlen == 32) {
/* Advance output buffer by 32 bits */
din += 4;
}
-- 
2.11.0

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

[U-Boot] [PATCH 14/19] spi: mpc8xxx: Document LEN setting better

[Mario Six]

Instead of having a table right before the code implementing the length
setting for documentation, have inline comments for the if branches
actually implementing the length setting described table's entries
(which is readable thanks to the set_char_len function).

Signed-off-by: Mario Six 
---
 drivers/spi/mpc8xxx_spi.c | 16 +---
 1 file changed, 5 insertions(+), 11 deletions(-)

diff --git a/drivers/spi/mpc8xxx_spi.c b/drivers/spi/mpc8xxx_spi.c
index ce2a77c1aa..d22206f4b7 100644
--- a/drivers/spi/mpc8xxx_spi.c
+++ b/drivers/spi/mpc8xxx_spi.c
@@ -120,21 +120,15 @@ int spi_xfer(struct spi_slave *slave, uint bitlen, const 
void *dout, void *din,
/* Shift data so it's msb-justified */
tmpdout = *(u32 *)dout >> (32 - xfer_bitlen);
 
-   /* The LEN field of the SPMODE register is set as follows:
-*
-* Bit length setting
-* len <= 4   3
-* 4 < len <= 16  len - 1
-* len > 16   0
-*/
-
clrbits_be32(>mode, SPI_MODE_EN);
 
-   if (bitlen <= 4)
+   /* Set up length for this transfer */
+
+   if (bitlen <= 4) /* 4 bits or less */
set_char_len(spi, 3);
-   else if (bitlen <= 16)
+   else if (bitlen <= 16) /* at most 16 bits */
set_char_len(spi, bitlen - 1);
-   else
+   else /* more than 16 bits -> full 32 bit transfer */
set_char_len(spi, 0);
 
if (bitlen > 16) {
-- 
2.11.0

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

[U-Boot] [PATCH 18/19] spi: mpc8xxx: Prepare DM conversion

[Mario Six]

To prepare DM conversion, move all driver functionality into separate
functions, and call them from the driver functions; these functions will
also be called from the DM-driver functions, so that we can keep the
legacy functions for the boards that still need them.

Signed-off-by: Mario Six 
---
 drivers/spi/mpc8xxx_spi.c | 120 +-
 1 file changed, 75 insertions(+), 45 deletions(-)

diff --git a/drivers/spi/mpc8xxx_spi.c b/drivers/spi/mpc8xxx_spi.c
index 4aa5db8821..5724a00585 100644
--- a/drivers/spi/mpc8xxx_spi.c
+++ b/drivers/spi/mpc8xxx_spi.c
@@ -43,41 +43,27 @@ static void set_char_len(spi8xxx_t *spi, u32 val)
 
 #define SPI_TIMEOUT1000
 
-struct spi_slave *spi_setup_slave(uint bus, uint cs, uint max_hz, uint mode)
+static void __spi_init_head(spi8xxx_t *spi)
 {
-   struct spi_slave *slave;
-
-   if (!spi_cs_is_valid(bus, cs))
-   return NULL;
-
-   slave = spi_alloc_slave_base(bus, cs);
-   if (!slave)
-   return NULL;
-
/*
-* TODO: Some of the code in spi_init() should probably move
-* here, or into spi_claim_bus() below.
+* SPI pins on the MPC83xx are not muxed, so all we do is initialize
+* some registers
 */
-
-   return slave;
-}
-
-void spi_free_slave(struct spi_slave *slave)
-{
-   free(slave);
+   out_be32(>mode, SPI_MODE_REV | SPI_MODE_MS | SPI_MODE_EN);
 }
 
-void spi_init(void)
+static int __spi_set_speed(spi8xxx_t *spi, uint speed)
 {
-   spi8xxx_t *spi = &((immap_t *)(CONFIG_SYS_IMMR))->spi;
+   /* TODO: This only ever sets one fixed speed */
 
-   /*
-* SPI pins on the MPC83xx are not muxed, so all we do is initialize
-* some registers
-*/
-   out_be32(>mode, SPI_MODE_REV | SPI_MODE_MS | SPI_MODE_EN);
/* Use SYSCLK / 8 (16.67MHz typ.) */
clrsetbits_be32(>mode, SPI_MODE_PM_MASK, to_prescale_mod(1));
+
+   return 0;
+}
+
+static void __spi_init_tail(spi8xxx_t *spi)
+{
/* Clear all SPI events */
setbits_be32(>event, 0x);
/* Mask  all SPI interrupts */
@@ -86,28 +72,12 @@ void spi_init(void)
out_be32(>com, 0);
 }
 
-int spi_claim_bus(struct spi_slave *slave)
+static int __spi_xfer(spi8xxx_t *spi, uint bitlen, const u8 *dout, u8 *din,
+ ulong flags)
 {
-   return 0;
-}
-
-void spi_release_bus(struct spi_slave *slave)
-{
-}
-
-int spi_xfer(struct spi_slave *slave, uint bitlen, const void *dout, void *din,
-ulong flags)
-{
-   spi8xxx_t *spi = &((immap_t *)(CONFIG_SYS_IMMR))->spi;
u32 tmpdin;
int num_blks = DIV_ROUND_UP(bitlen, 32);
 
-   debug("%s: slave %u:%u dout %08X din %08X bitlen %u\n", __func__,
- slave->bus, slave->cs, *(uint *)dout, *(uint *)din, bitlen);
-
-   if (flags & SPI_XFER_BEGIN)
-   spi_cs_activate(slave);
-
/* Clear all SPI events */
setbits_be32(>event, 0x);
 
@@ -186,8 +156,68 @@ int spi_xfer(struct spi_slave *slave, uint bitlen, const 
void *dout, void *din,
debug("*** %s: transfer ended. Value=%08x\n", __func__, tmpdin);
}
 
+   return 0;
+}
+
+struct spi_slave *spi_setup_slave(uint bus, uint cs, uint max_hz, uint mode)
+{
+   struct spi_slave *slave;
+
+   if (!spi_cs_is_valid(bus, cs))
+   return NULL;
+
+   slave = spi_alloc_slave_base(bus, cs);
+   if (!slave)
+   return NULL;
+
+   /*
+* TODO: Some of the code in spi_init() should probably move
+* here, or into spi_claim_bus() below.
+*/
+
+   return slave;
+}
+
+void spi_free_slave(struct spi_slave *slave)
+{
+   free(slave);
+}
+
+void spi_init(void)
+{
+   spi8xxx_t *spi = &((immap_t *)(CONFIG_SYS_IMMR))->spi;
+
+   out_be32(>mode, SPI_MODE_REV | SPI_MODE_MS | SPI_MODE_EN);
+   __spi_init_head(spi);
+   __spi_set_speed(spi, 1667);
+   __spi_init_tail(spi);
+}
+
+int spi_claim_bus(struct spi_slave *slave)
+{
+   return 0;
+}
+
+void spi_release_bus(struct spi_slave *slave)
+{
+}
+
+int spi_xfer(struct spi_slave *slave, uint bitlen, const void *dout, void *din,
+ulong flags)
+{
+   spi8xxx_t *spi = &((immap_t *)(CONFIG_SYS_IMMR))->spi;
+   int ret;
+
+   debug("%s: slave %u:%u dout %08X din %08X bitlen %u\n", __func__,
+ slave->bus, slave->cs, *(uint *)dout, *(uint *)din, bitlen);
+
+   if (flags & SPI_XFER_BEGIN)
+   spi_cs_activate(slave);
+
+   ret = __spi_xfer(spi, bitlen, dout, din, flags);
+
if (flags & SPI_XFER_END)
spi_cs_deactivate(slave);
 
-   return 0;
+   return ret;
 }
-- 
2.11.0

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

[U-Boot] [PATCH 09/19] spi: mpc8xxx: Get rid of is_read

[Mario Six]

Get rid of the is_read variable, and just keep the state of the "not
empty" and "not full" events in two boolean variables within the loop
body.

Signed-off-by: Mario Six 
---
 drivers/spi/mpc8xxx_spi.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/spi/mpc8xxx_spi.c b/drivers/spi/mpc8xxx_spi.c
index c4a9ef53ef..a69987ef54 100644
--- a/drivers/spi/mpc8xxx_spi.c
+++ b/drivers/spi/mpc8xxx_spi.c
@@ -91,7 +91,7 @@ int spi_xfer(struct spi_slave *slave, uint bitlen, const void 
*dout, void *din,
spi8xxx_t *spi = &((immap_t *)(CONFIG_SYS_IMMR))->spi;
uint tmpdout, tmpdin, event;
int num_blks = DIV_ROUND_UP(bitlen, 32);
-   int tm, is_read = 0;
+   int tm;
uchar char_size = 32;
 
debug("%s: slave %u:%u dout %08X din %08X bitlen %u\n", __func__,
@@ -145,12 +145,14 @@ int spi_xfer(struct spi_slave *slave, uint bitlen, const 
void *dout, void *din,
 * or time out (1 second = 1000 ms)
 * The NE event must be read and cleared first
 */
-   for (tm = 0, is_read = 0; tm < SPI_TIMEOUT; ++tm) {
+   for (tm = 0; tm < SPI_TIMEOUT; ++tm) {
event = in_be32(>event);
-   if (event & SPI_EV_NE) {
+   bool have_ne = event & SPI_EV_NE;
+   bool have_nf = event & SPI_EV_NF;
+
+   if (have_ne) {
tmpdin = in_be32(>rx);
setbits_be32(>event, SPI_EV_NE);
-   is_read = 1;
 
*(u32 *)din = (tmpdin << (32 - char_size));
if (char_size == 32) {
@@ -164,7 +166,7 @@ int spi_xfer(struct spi_slave *slave, uint bitlen, const 
void *dout, void *din,
 * in the future put an arbitrary delay after writing
 * the device.  Arbitrary delays suck, though...
 */
-   if (is_read && (event & SPI_EV_NF))
+   if (have_ne && have_nf)
break;
}
if (tm >= SPI_TIMEOUT)
-- 
2.11.0

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

[U-Boot] [PATCH 04/19] spi: mpc8xxx: Fix space after cast

[Mario Six]

Fix all "superfluous space after case" style errors.

Signed-off-by: Mario Six 
---
 drivers/spi/mpc8xxx_spi.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/spi/mpc8xxx_spi.c b/drivers/spi/mpc8xxx_spi.c
index 3ac9f2f8e8..079476c3ee 100644
--- a/drivers/spi/mpc8xxx_spi.c
+++ b/drivers/spi/mpc8xxx_spi.c
@@ -83,7 +83,7 @@ int spi_xfer(struct spi_slave *slave, uint bitlen, const void 
*dout, void *din,
uchar char_size = 32;
 
debug("spi_xfer: slave %u:%u dout %08X din %08X bitlen %u\n",
- slave->bus, slave->cs, *(uint *) dout, *(uint *) din, bitlen);
+ slave->bus, slave->cs, *(uint *)dout, *(uint *)din, bitlen);
 
if (flags & SPI_XFER_BEGIN)
spi_cs_activate(slave);
@@ -97,7 +97,7 @@ int spi_xfer(struct spi_slave *slave, uint bitlen, const void 
*dout, void *din,
char_size = (bitlen >= 32 ? 32 : bitlen);
 
/* Shift data so it's msb-justified */
-   tmpdout = *(u32 *) dout >> (32 - char_size);
+   tmpdout = *(u32 *)dout >> (32 - char_size);
 
/* The LEN field of the SPMODE register is set as follows:
 *
@@ -142,7 +142,7 @@ int spi_xfer(struct spi_slave *slave, uint bitlen, const 
void *dout, void *din,
spi->event |= SPI_EV_NE;
is_read = 1;
 
-   *(u32 *) din = (tmpdin << (32 - char_size));
+   *(u32 *)din = (tmpdin << (32 - char_size));
if (char_size == 32) {
/* Advance output buffer by 32 bits */
din += 4;
-- 
2.11.0

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

[U-Boot] [PATCH 10/19] spi: mpc8xxx: Simplify logic a bit

[Mario Six]

We do nothing in the loop if the "not empty" event was not detected. To
simplify the logic, check if this is the case, and skip the execution of
the loop early to reduce the nesting level and flag checking.

Signed-off-by: Mario Six 
---
 drivers/spi/mpc8xxx_spi.c | 23 +--
 1 file changed, 13 insertions(+), 10 deletions(-)

diff --git a/drivers/spi/mpc8xxx_spi.c b/drivers/spi/mpc8xxx_spi.c
index a69987ef54..30249cce57 100644
--- a/drivers/spi/mpc8xxx_spi.c
+++ b/drivers/spi/mpc8xxx_spi.c
@@ -150,25 +150,28 @@ int spi_xfer(struct spi_slave *slave, uint bitlen, const 
void *dout, void *din,
bool have_ne = event & SPI_EV_NE;
bool have_nf = event & SPI_EV_NF;
 
-   if (have_ne) {
-   tmpdin = in_be32(>rx);
-   setbits_be32(>event, SPI_EV_NE);
-
-   *(u32 *)din = (tmpdin << (32 - char_size));
-   if (char_size == 32) {
-   /* Advance output buffer by 32 bits */
-   din += 4;
-   }
+   if (!have_ne)
+   continue;
+
+   tmpdin = in_be32(>rx);
+   setbits_be32(>event, SPI_EV_NE);
+
+   *(u32 *)din = (tmpdin << (32 - char_size));
+   if (char_size == 32) {
+   /* Advance output buffer by 32 bits */
+   din += 4;
}
+
/*
 * Only bail when we've had both NE and NF events.
 * This will cause timeouts on RO devices, so maybe
 * in the future put an arbitrary delay after writing
 * the device.  Arbitrary delays suck, though...
 */
-   if (have_ne && have_nf)
+   if (have_nf)
break;
}
+
if (tm >= SPI_TIMEOUT)
debug("*** %s: Time out during SPI transfer\n",
  __func__);
-- 
2.11.0

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

[U-Boot] [PATCH 00/19] spi: mpc8xxx: DM conversion

[Mario Six]

This patch series adds support for DM to the MPC8XXX SPI driver, cleans
up the driver code, fixes a few minor problems.

Some TODOs are left over for later, such as proper SPI speed setting,
and support for SPI mode setting. These would be enhancements to the
original functionality, and can come later.

The legacy functionality is retained, so older boards will still work
after the patches are applied.

Mario Six (19):
  spi: mpc8xxx: Use short type names
  spi: mpc8xxx: Fix comments
  spi: mpc8xxx: Rename camel-case variables
  spi: mpc8xxx: Fix space after cast
  spi: mpc8xxx: Fix function names in strings
  spi: mpc8xxx: Replace defines with enums
  spi: mpc8xxx: Use IO accessors
  spi: mpc8xxx: Simplify if
  spi: mpc8xxx: Get rid of is_read
  spi: mpc8xxx: Simplify logic a bit
  spi: mpc8xxx: Reduce scope of loop variables
  spi: mpc8xxx: Make code more readable
  spi: mpc8xxx: Rename variable
  spi: mpc8xxx: Document LEN setting better
  spi: mpc8xxx: Re-order transfer setup
  spi: mpc8xxx: Fix if check
  spi: mpc8xxx: Use get_timer
  spi: mpc8xxx: Prepare DM conversion
  spi: mpc8xxx: Add DM support

 drivers/spi/mpc8xxx_spi.c | 386 ++
 1 file changed, 287 insertions(+), 99 deletions(-)

--
2.11.0

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

[U-Boot] [PATCH 19/19] spi: mpc8xxx: Add DM support

[Mario Six]

Support DM for the MPC8XXX SPI driver.

Signed-off-by: Mario Six 
---
 drivers/spi/mpc8xxx_spi.c | 135 +-
 1 file changed, 133 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/mpc8xxx_spi.c b/drivers/spi/mpc8xxx_spi.c
index 5724a00585..6e51826665 100644
--- a/drivers/spi/mpc8xxx_spi.c
+++ b/drivers/spi/mpc8xxx_spi.c
@@ -10,6 +10,11 @@
 #include 
 #include 
 #include 
+#ifdef CONFIG_DM_SPI
+#include 
+#include 
+#include 
+#endif
 
 enum {
SPI_EV_NE = BIT(31 - 22),   /* Receiver Not Empty */
@@ -31,6 +36,14 @@ enum {
SPI_COM_LST = BIT(31 - 9),
 };
 
+#ifdef CONFIG_DM_SPI
+struct mpc8xxx_priv {
+   spi8xxx_t *spi;
+   struct gpio_desc gpios[16];
+   int max_cs;
+};
+#endif
+
 static inline u32 to_prescale_mod(u32 val)
 {
return (min(val, (u32)15) << 16);
@@ -54,7 +67,7 @@ static void __spi_init_head(spi8xxx_t *spi)
 
 static int __spi_set_speed(spi8xxx_t *spi, uint speed)
 {
-   /* TODO: This only ever sets one fixed speed */
+   /* TODO(mario@gdsys.cc): This only ever sets one fixed speed */
 
/* Use SYSCLK / 8 (16.67MHz typ.) */
clrsetbits_be32(>mode, SPI_MODE_PM_MASK, to_prescale_mod(1));
@@ -75,7 +88,7 @@ static void __spi_init_tail(spi8xxx_t *spi)
 static int __spi_xfer(spi8xxx_t *spi, uint bitlen, const u8 *dout, u8 *din,
  ulong flags)
 {
-   u32 tmpdin;
+   u32 tmpdin = 0;
int num_blks = DIV_ROUND_UP(bitlen, 32);
 
/* Clear all SPI events */
@@ -159,6 +172,110 @@ static int __spi_xfer(spi8xxx_t *spi, uint bitlen, const 
u8 *dout, u8 *din,
return 0;
 }
 
+#ifdef CONFIG_DM_SPI
+
+static int mpc8xxx_spi_ofdata_to_platdata(struct udevice *dev)
+{
+   struct mpc8xxx_priv *priv = dev_get_priv(dev);
+   int ret;
+
+   priv->spi = (spi8xxx_t *)dev_read_addr(dev);
+
+   /* TODO(mario@gdsys.cc): Read clock and save the value */
+
+   ret = gpio_request_list_by_name(dev, "gpios", priv->gpios,
+   ARRAY_SIZE(priv->gpios), GPIOD_IS_OUT | 
GPIOD_ACTIVE_LOW);
+   if (ret < 0)
+   return -EINVAL;
+
+   priv->max_cs = ret;
+
+   return 0;
+}
+
+static int mpc8xxx_spi_probe(struct udevice *dev)
+{
+   struct mpc8xxx_priv *priv = dev_get_priv(dev);
+
+   __spi_init_head(priv->spi);
+   __spi_set_speed(priv->spi, 1667);
+   __spi_init_tail(priv->spi);
+
+   return 0;
+}
+
+static void mpc8xxx_spi_cs_activate(struct udevice *dev)
+{
+   struct mpc8xxx_priv *priv = dev_get_priv(dev->parent);
+   struct dm_spi_slave_platdata *platdata = dev_get_parent_platdata(dev);
+
+   dm_gpio_set_dir_flags(>gpios[platdata->cs], GPIOD_IS_OUT);
+   dm_gpio_set_value(>gpios[platdata->cs], 0);
+}
+
+static void mpc8xxx_spi_cs_deactivate(struct udevice *dev)
+{
+   struct mpc8xxx_priv *priv = dev_get_priv(dev->parent);
+   struct dm_spi_slave_platdata *platdata = dev_get_parent_platdata(dev);
+
+   dm_gpio_set_dir_flags(>gpios[platdata->cs], GPIOD_IS_OUT);
+   dm_gpio_set_value(>gpios[platdata->cs], 1);
+}
+
+static int mpc8xxx_spi_xfer(struct udevice *dev, uint bitlen,
+   const void *dout, void *din, ulong flags)
+{
+   int ret;
+   struct udevice *bus = dev->parent;
+   struct mpc8xxx_priv *priv = dev_get_priv(bus);
+   struct dm_spi_slave_platdata *platdata = dev_get_parent_platdata(dev);
+
+   debug("%s: slave %s:%u dout %08X din %08X bitlen %u\n", __func__,
+ bus->name, platdata->cs, *(uint *)dout, *(uint *)din, bitlen);
+
+   if (flags & SPI_XFER_BEGIN)
+   mpc8xxx_spi_cs_activate(dev);
+
+   ret = __spi_xfer(priv->spi, bitlen, dout, din, flags);
+
+   if (flags & SPI_XFER_END)
+   mpc8xxx_spi_cs_deactivate(dev);
+
+   return ret;
+}
+
+static int mpc8xxx_spi_set_speed(struct udevice *dev, uint speed)
+{
+   struct mpc8xxx_priv *priv = dev_get_priv(dev);
+
+   return __spi_set_speed(priv->spi, speed);
+}
+
+static int mpc8xxx_spi_set_mode(struct udevice *dev, uint mode)
+{
+   /* TODO(mario@gdsys.cc): Using SPI_CPHA (for clock phase) and
+* SPI_CPOL (for clock polarity) should work
+*/
+   return 0;
+}
+
+static const struct dm_spi_ops mpc8xxx_spi_ops = {
+   .xfer   = mpc8xxx_spi_xfer,
+   .set_speed  = mpc8xxx_spi_set_speed,
+   .set_mode   = mpc8xxx_spi_set_mode,
+   /*
+* cs_info is not needed, since we require all chip selects to be
+* in the device tree explicitly
+*/
+};
+
+static const struct udevice_id mpc8xxx_spi_ids[] = {
+   { .compatible = "fsl,spi" },
+   { }
+};
+
+#else
+
 struct spi_slave *spi_setup_slave(uint bus, uint cs, uint max_hz, uint mode)
 {
struct spi_slave *slave;
@@ -221,3 +338,17 @@ int spi_xfer(struct spi_slave *slave, uint bitlen, const 
void *dout, void *din,
 
return 

[U-Boot] [PATCH 06/19] spi: mpc8xxx: Replace defines with enums

[Mario Six]

Replace pre-processor defines with proper enums, and use the BIT macro
where applicable.

Signed-off-by: Mario Six 
---
 drivers/spi/mpc8xxx_spi.c | 26 +++---
 1 file changed, 19 insertions(+), 7 deletions(-)

diff --git a/drivers/spi/mpc8xxx_spi.c b/drivers/spi/mpc8xxx_spi.c
index 0b81db959e..bd2857ce1a 100644
--- a/drivers/spi/mpc8xxx_spi.c
+++ b/drivers/spi/mpc8xxx_spi.c
@@ -11,13 +11,25 @@
 #include 
 #include 
 
-#define SPI_EV_NE  (0x8000 >> 22)  /* Receiver Not Empty */
-#define SPI_EV_NF  (0x8000 >> 23)  /* Transmitter Not Full */
-
-#define SPI_MODE_LOOP  (0x8000 >> 1)   /* Loopback mode */
-#define SPI_MODE_REV   (0x8000 >> 5)   /* Reverse mode - MSB first */
-#define SPI_MODE_MS(0x8000 >> 6)   /* Always master */
-#define SPI_MODE_EN(0x8000 >> 7)   /* Enable interface */
+enum {
+   SPI_EV_NE = BIT(31 - 22),   /* Receiver Not Empty */
+   SPI_EV_NF = BIT(31 - 23),   /* Transmitter Not Full */
+};
+
+enum {
+   SPI_MODE_LOOP  = BIT(31 - 1),   /* Loopback mode */
+   SPI_MODE_CI= BIT(31 - 2),   /* Clock invert */
+   SPI_MODE_CP= BIT(31 - 3),   /* Clock phase */
+   SPI_MODE_DIV16 = BIT(31 - 4),   /* Divide clock source by 16 */
+   SPI_MODE_REV   = BIT(31 - 5),   /* Reverse mode - MSB first */
+   SPI_MODE_MS= BIT(31 - 6),   /* Always master */
+   SPI_MODE_EN= BIT(31 - 7),   /* Enable interface */
+
+   SPI_MODE_LEN_MASK = 0xf0,
+   SPI_MODE_PM_MASK = 0xf,
+
+   SPI_COM_LST = BIT(31 - 9),
+};
 
 #define SPI_TIMEOUT1000
 
-- 
2.11.0

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

[U-Boot] [PATCH 15/19] spi: mpc8xxx: Re-order transfer setup

[Mario Six]

Minize the time the adapter is disabled (via SPI_MODE_EN
clearing/setting) to just the character length setting, and only set up
the temporary data writing variable right before we need it, so there is
a more clear distinction between setting up the SPI adapter, and setting
up the data to be written.

Signed-off-by: Mario Six 
---
 drivers/spi/mpc8xxx_spi.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/spi/mpc8xxx_spi.c b/drivers/spi/mpc8xxx_spi.c
index d22206f4b7..fe493f6d40 100644
--- a/drivers/spi/mpc8xxx_spi.c
+++ b/drivers/spi/mpc8xxx_spi.c
@@ -117,9 +117,6 @@ int spi_xfer(struct spi_slave *slave, uint bitlen, const 
void *dout, void *din,
u32 tmpdout = 0;
uchar xfer_bitlen = (bitlen >= 32 ? 32 : bitlen);
 
-   /* Shift data so it's msb-justified */
-   tmpdout = *(u32 *)dout >> (32 - xfer_bitlen);
-
clrbits_be32(>mode, SPI_MODE_EN);
 
/* Set up length for this transfer */
@@ -131,14 +128,17 @@ int spi_xfer(struct spi_slave *slave, uint bitlen, const 
void *dout, void *din,
else /* more than 16 bits -> full 32 bit transfer */
set_char_len(spi, 0);
 
+   setbits_be32(>mode, SPI_MODE_EN);
+
+   /* Shift data so it's msb-justified */
+   tmpdout = *(u32 *)dout >> (32 - xfer_bitlen);
+
if (bitlen > 16) {
/* Set up the next iteration if sending > 32 bits */
bitlen -= 32;
dout += 4;
}
 
-   setbits_be32(>mode, SPI_MODE_EN);
-
/* Write the data out */
out_be32(>tx, tmpdout);
 
-- 
2.11.0

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

[U-Boot] [PATCH 07/19] spi: mpc8xxx: Use IO accessors

[Mario Six]

Accesses to the register map are currently done by directly reading and
writing the structure.

Switch to the appropriate IO accessors instead.

Signed-off-by: Mario Six 
---
 drivers/spi/mpc8xxx_spi.c | 38 +++---
 1 file changed, 19 insertions(+), 19 deletions(-)

diff --git a/drivers/spi/mpc8xxx_spi.c b/drivers/spi/mpc8xxx_spi.c
index bd2857ce1a..b5546aa502 100644
--- a/drivers/spi/mpc8xxx_spi.c
+++ b/drivers/spi/mpc8xxx_spi.c
@@ -59,21 +59,21 @@ void spi_free_slave(struct spi_slave *slave)
 
 void spi_init(void)
 {
-   volatile spi8xxx_t *spi = &((immap_t *) (CONFIG_SYS_IMMR))->spi;
+   spi8xxx_t *spi = &((immap_t *)(CONFIG_SYS_IMMR))->spi;
 
/*
 * SPI pins on the MPC83xx are not muxed, so all we do is initialize
 * some registers
 */
-   spi->mode = SPI_MODE_REV | SPI_MODE_MS | SPI_MODE_EN;
+   out_be32(>mode, SPI_MODE_REV | SPI_MODE_MS | SPI_MODE_EN);
/* Use SYSCLK / 8 (16.67MHz typ.) */
-   spi->mode = (spi->mode & 0xfff0) | BIT(16);
+   clrsetbits_be32(>mode, 0x000f, BIT(16));
/* Clear all SPI events */
-   spi->event = 0x;
+   setbits_be32(>event, 0x);
/* Mask  all SPI interrupts */
-   spi->mask = 0x;
+   clrbits_be32(>mask, 0x);
/* LST bit doesn't do anything, so disregard */
-   spi->com = 0;
+   out_be32(>com, 0);
 }
 
 int spi_claim_bus(struct spi_slave *slave)
@@ -88,7 +88,7 @@ void spi_release_bus(struct spi_slave *slave)
 int spi_xfer(struct spi_slave *slave, uint bitlen, const void *dout, void *din,
 ulong flags)
 {
-   volatile spi8xxx_t *spi = &((immap_t *) (CONFIG_SYS_IMMR))->spi;
+   spi8xxx_t *spi = &((immap_t *)(CONFIG_SYS_IMMR))->spi;
uint tmpdout, tmpdin, event;
int num_blks = DIV_ROUND_UP(bitlen, 32);
int tm, is_read = 0;
@@ -101,7 +101,7 @@ int spi_xfer(struct spi_slave *slave, uint bitlen, const 
void *dout, void *din,
spi_cs_activate(slave);
 
/* Clear all SPI events */
-   spi->event = 0x;
+   setbits_be32(>event, 0x);
 
/* Handle data in 32-bit chunks */
while (num_blks--) {
@@ -119,26 +119,26 @@ int spi_xfer(struct spi_slave *slave, uint bitlen, const 
void *dout, void *din,
 * len > 16   0
 */
 
-   spi->mode &= ~SPI_MODE_EN;
+   clrbits_be32(>mode, SPI_MODE_EN);
 
if (bitlen <= 16) {
if (bitlen <= 4)
-   spi->mode = (spi->mode & 0xff0f) |
-   (3 << 20);
+   clrsetbits_be32(>mode, 0x00f0,
+   (3 << 20));
else
-   spi->mode = (spi->mode & 0xff0f) |
-   ((bitlen - 1) << 20);
+   clrsetbits_be32(>mode, 0x00f0,
+   ((bitlen - 1) << 20));
} else {
-   spi->mode = (spi->mode & 0xff0f);
+   clrbits_be32(>mode, 0x00f0);
/* Set up the next iteration if sending > 32 bits */
bitlen -= 32;
dout += 4;
}
 
-   spi->mode |= SPI_MODE_EN;
+   setbits_be32(>mode, SPI_MODE_EN);
 
/* Write the data out */
-   spi->tx = tmpdout;
+   out_be32(>tx, tmpdout);
 
debug("*** %s: ... %08x written\n", __func__, tmpdout);
 
@@ -148,10 +148,10 @@ int spi_xfer(struct spi_slave *slave, uint bitlen, const 
void *dout, void *din,
 * The NE event must be read and cleared first
 */
for (tm = 0, is_read = 0; tm < SPI_TIMEOUT; ++tm) {
-   event = spi->event;
+   event = in_be32(>event);
if (event & SPI_EV_NE) {
-   tmpdin = spi->rx;
-   spi->event |= SPI_EV_NE;
+   tmpdin = in_be32(>rx);
+   setbits_be32(>event, SPI_EV_NE);
is_read = 1;
 
*(u32 *)din = (tmpdin << (32 - char_size));
-- 
2.11.0

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

[U-Boot] [PATCH 02/19] spi: mpc8xxx: Fix comments

[Mario Six]

There are some comments on the same line as the code they document. Put
comments above the code lines they document, so the line length is not
unnecessarily increased.

Signed-off-by: Mario Six 
---
 drivers/spi/mpc8xxx_spi.c | 22 ++
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/drivers/spi/mpc8xxx_spi.c b/drivers/spi/mpc8xxx_spi.c
index 2e1a6caf03..2f6afaf7ac 100644
--- a/drivers/spi/mpc8xxx_spi.c
+++ b/drivers/spi/mpc8xxx_spi.c
@@ -54,11 +54,14 @@ void spi_init(void)
 * some registers
 */
spi->mode = SPI_MODE_REV | SPI_MODE_MS | SPI_MODE_EN;
-   spi->mode = (spi->mode & 0xfff0) | BIT(16); /* Use SYSCLK / 8
-(16.67MHz typ.) */
-   spi->event = 0x;/* Clear all SPI events */
-   spi->mask = 0x; /* Mask  all SPI interrupts */
-   spi->com = 0;   /* LST bit doesn't do anything, so disregard */
+   /* Use SYSCLK / 8 (16.67MHz typ.) */
+   spi->mode = (spi->mode & 0xfff0) | BIT(16);
+   /* Clear all SPI events */
+   spi->event = 0x;
+   /* Mask  all SPI interrupts */
+   spi->mask = 0x;
+   /* LST bit doesn't do anything, so disregard */
+   spi->com = 0;
 }
 
 int spi_claim_bus(struct spi_slave *slave)
@@ -85,9 +88,10 @@ int spi_xfer(struct spi_slave *slave, uint bitlen, const 
void *dout, void *din,
if (flags & SPI_XFER_BEGIN)
spi_cs_activate(slave);
 
-   spi->event = 0x;/* Clear all SPI events */
+   /* Clear all SPI events */
+   spi->event = 0x;
 
-   /* handle data in 32-bit chunks */
+   /* Handle data in 32-bit chunks */
while (numBlks--) {
tmpdout = 0;
charSize = (bitlen >= 32 ? 32 : bitlen);
@@ -121,7 +125,9 @@ int spi_xfer(struct spi_slave *slave, uint bitlen, const 
void *dout, void *din,
 
spi->mode |= SPI_MODE_EN;
 
-   spi->tx = tmpdout;  /* Write the data out */
+   /* Write the data out */
+   spi->tx = tmpdout;
+
debug("*** spi_xfer: ... %08x written\n", tmpdout);
 
/*
-- 
2.11.0

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

[U-Boot] [PATCH 05/19] spi: mpc8xxx: Fix function names in strings

[Mario Six]

Replace the function name with a "%s" format string and the __func__
variable in debug statements (as proposed by checkpatch).

Signed-off-by: Mario Six 
---
 drivers/spi/mpc8xxx_spi.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/spi/mpc8xxx_spi.c b/drivers/spi/mpc8xxx_spi.c
index 079476c3ee..0b81db959e 100644
--- a/drivers/spi/mpc8xxx_spi.c
+++ b/drivers/spi/mpc8xxx_spi.c
@@ -82,7 +82,7 @@ int spi_xfer(struct spi_slave *slave, uint bitlen, const void 
*dout, void *din,
int tm, is_read = 0;
uchar char_size = 32;
 
-   debug("spi_xfer: slave %u:%u dout %08X din %08X bitlen %u\n",
+   debug("%s: slave %u:%u dout %08X din %08X bitlen %u\n", __func__,
  slave->bus, slave->cs, *(uint *)dout, *(uint *)din, bitlen);
 
if (flags & SPI_XFER_BEGIN)
@@ -128,7 +128,7 @@ int spi_xfer(struct spi_slave *slave, uint bitlen, const 
void *dout, void *din,
/* Write the data out */
spi->tx = tmpdout;
 
-   debug("*** spi_xfer: ... %08x written\n", tmpdout);
+   debug("*** %s: ... %08x written\n", __func__, tmpdout);
 
/*
 * Wait for SPI transmit to get out
@@ -158,9 +158,10 @@ int spi_xfer(struct spi_slave *slave, uint bitlen, const 
void *dout, void *din,
break;
}
if (tm >= SPI_TIMEOUT)
-   puts("*** spi_xfer: Time out during SPI transfer");
+   debug("*** %s: Time out during SPI transfer\n",
+ __func__);
 
-   debug("*** spi_xfer: transfer ended. Value=%08x\n", tmpdin);
+   debug("*** %s: transfer ended. Value=%08x\n", __func__, tmpdin);
}
 
if (flags & SPI_XFER_END)
-- 
2.11.0

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

[U-Boot] [PATCH 08/19] spi: mpc8xxx: Simplify if

[Mario Six]

Instead of having a nested if block, just have two branches within the
overarching if block to eliminate one nesting level.

Signed-off-by: Mario Six 
---
 drivers/spi/mpc8xxx_spi.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/spi/mpc8xxx_spi.c b/drivers/spi/mpc8xxx_spi.c
index b5546aa502..c4a9ef53ef 100644
--- a/drivers/spi/mpc8xxx_spi.c
+++ b/drivers/spi/mpc8xxx_spi.c
@@ -121,13 +121,11 @@ int spi_xfer(struct spi_slave *slave, uint bitlen, const 
void *dout, void *din,
 
clrbits_be32(>mode, SPI_MODE_EN);
 
-   if (bitlen <= 16) {
-   if (bitlen <= 4)
-   clrsetbits_be32(>mode, 0x00f0,
-   (3 << 20));
-   else
-   clrsetbits_be32(>mode, 0x00f0,
-   ((bitlen - 1) << 20));
+   if (bitlen <= 4) {
+   clrsetbits_be32(>mode, 0x00f0, (3 << 20));
+   } else if (bitlen <= 16) {
+   clrsetbits_be32(>mode, 0x00f0,
+   ((bitlen - 1) << 20));
} else {
clrbits_be32(>mode, 0x00f0);
/* Set up the next iteration if sending > 32 bits */
-- 
2.11.0

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

[U-Boot] [PATCH 01/19] spi: mpc8xxx: Use short type names

[Mario Six]

The function signatures in the driver are quite long as is. Use short
type names (uint etc.) to make them more readable.

Signed-off-by: Mario Six 
---
 drivers/spi/mpc8xxx_spi.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/spi/mpc8xxx_spi.c b/drivers/spi/mpc8xxx_spi.c
index 00cbcbf9fc..2e1a6caf03 100644
--- a/drivers/spi/mpc8xxx_spi.c
+++ b/drivers/spi/mpc8xxx_spi.c
@@ -21,8 +21,7 @@
 
 #define SPI_TIMEOUT1000
 
-struct spi_slave *spi_setup_slave(unsigned int bus, unsigned int cs,
-   unsigned int max_hz, unsigned int mode)
+struct spi_slave *spi_setup_slave(uint bus, uint cs, uint max_hz, uint mode)
 {
struct spi_slave *slave;
 
@@ -69,17 +68,16 @@ int spi_claim_bus(struct spi_slave *slave)
 
 void spi_release_bus(struct spi_slave *slave)
 {
-
 }
 
-int spi_xfer(struct spi_slave *slave, unsigned int bitlen, const void *dout,
-   void *din, unsigned long flags)
+int spi_xfer(struct spi_slave *slave, uint bitlen, const void *dout, void *din,
+ulong flags)
 {
volatile spi8xxx_t *spi = &((immap_t *) (CONFIG_SYS_IMMR))->spi;
-   unsigned int tmpdout, tmpdin, event;
+   uint tmpdout, tmpdin, event;
int numBlks = DIV_ROUND_UP(bitlen, 32);
int tm, isRead = 0;
-   unsigned char charSize = 32;
+   uchar charSize = 32;
 
debug("spi_xfer: slave %u:%u dout %08X din %08X bitlen %u\n",
  slave->bus, slave->cs, *(uint *) dout, *(uint *) din, bitlen);
-- 
2.11.0

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

[U-Boot] [PATCH 11/19] spi: mpc8xxx: Reduce scope of loop variables

[Mario Six]

The transmission loop starts with setting some variables, which are only
used inside the loop. Reduce the scope to the loop to make the
declaration and initialization of these variables coincide.

In the case of char_size this also always initializes the variable
immediately with the final value actually used in the loop (instead of
the placeholder value 32).

Signed-off-by: Mario Six 
---
 drivers/spi/mpc8xxx_spi.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/spi/mpc8xxx_spi.c b/drivers/spi/mpc8xxx_spi.c
index 30249cce57..5bf84aaec6 100644
--- a/drivers/spi/mpc8xxx_spi.c
+++ b/drivers/spi/mpc8xxx_spi.c
@@ -89,10 +89,8 @@ int spi_xfer(struct spi_slave *slave, uint bitlen, const 
void *dout, void *din,
 ulong flags)
 {
spi8xxx_t *spi = &((immap_t *)(CONFIG_SYS_IMMR))->spi;
-   uint tmpdout, tmpdin, event;
+   u32 tmpdin;
int num_blks = DIV_ROUND_UP(bitlen, 32);
-   int tm;
-   uchar char_size = 32;
 
debug("%s: slave %u:%u dout %08X din %08X bitlen %u\n", __func__,
  slave->bus, slave->cs, *(uint *)dout, *(uint *)din, bitlen);
@@ -105,8 +103,9 @@ int spi_xfer(struct spi_slave *slave, uint bitlen, const 
void *dout, void *din,
 
/* Handle data in 32-bit chunks */
while (num_blks--) {
-   tmpdout = 0;
-   char_size = (bitlen >= 32 ? 32 : bitlen);
+   int tm;
+   u32 tmpdout = 0;
+   uchar char_size = (bitlen >= 32 ? 32 : bitlen);
 
/* Shift data so it's msb-justified */
tmpdout = *(u32 *)dout >> (32 - char_size);
@@ -146,7 +145,7 @@ int spi_xfer(struct spi_slave *slave, uint bitlen, const 
void *dout, void *din,
 * The NE event must be read and cleared first
 */
for (tm = 0; tm < SPI_TIMEOUT; ++tm) {
-   event = in_be32(>event);
+   u32 event = in_be32(>event);
bool have_ne = event & SPI_EV_NE;
bool have_nf = event & SPI_EV_NF;
 
-- 
2.11.0

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

Re: [U-Boot] [PATCH] x86: queensbay: switche P state to the highest freq

[Bin Meng]

Hi Christian,

On Tue, Apr 10, 2018 at 5:48 PM, Christian Gmeiner
 wrote:
> 2018-04-10 11:11 GMT+02:00 Bin Meng :
>> Hi Christian,
>>
>> On Tue, Apr 10, 2018 at 5:09 PM, Christian Gmeiner
>>  wrote:
>>> Hi Bin,
>>>
>>> 2018-04-10 11:07 GMT+02:00 Bin Meng :
 Hi Christian,

 On Tue, Apr 10, 2018 at 4:47 PM, Christian Gmeiner
  wrote:
> Hi Bin
>
> Thanks for you quick review!
>
>>
>> On Tue, Apr 10, 2018 at 4:01 PM, Christian Gmeiner
>>  wrote:
>>> Fixes performance issue when running vx5/vx7 images.
>>
>> Could you elaborate more on what performance issue you are seeing?
>>
>
> The cache performance was bad without this change. We found this problem
> when switching from bldk to u-boot.
>
> old: https://imagebin.ca/v/3xssw7stbY6A
> new: https://imagebin.ca/v/3xstHMCC9fmJ

 Thank you for the benchmark data. Then please consider describing your
 benchmark test suite and on what configuration the data is worse
 without this patch (eg: sequential 128-bit read) in the commit
 message. This will help other people understand the patch and the
 commit in the future.

>>>
>>> Will do.
>>>
>
>> nits: better to spell out "VxWorks"
>
> ok
>
>>
>>>
>>> Signed-off-by: Christian Gmeiner 
>>> ---
>>>  arch/x86/cpu/queensbay/Makefile |  2 +-
>>>  arch/x86/cpu/queensbay/cpu.c| 61 
>>> +
>>>  2 files changed, 62 insertions(+), 1 deletion(-)
>>>  create mode 100644 arch/x86/cpu/queensbay/cpu.c
>>>
>>> diff --git a/arch/x86/cpu/queensbay/Makefile 
>>> b/arch/x86/cpu/queensbay/Makefile
>>> index c0681995bd..3dd23465d4 100644
>>> --- a/arch/x86/cpu/queensbay/Makefile
>>> +++ b/arch/x86/cpu/queensbay/Makefile
>>> @@ -5,4 +5,4 @@
>>>  #
>>>
>>>  obj-y += fsp_configs.o irq.o
>>> -obj-y += tnc.o
>>> +obj-y += tnc.o cpu.o
>>> diff --git a/arch/x86/cpu/queensbay/cpu.c b/arch/x86/cpu/queensbay/cpu.c
>>> new file mode 100644
>>> index 00..e98e4ac8ef
>>> --- /dev/null
>>> +++ b/arch/x86/cpu/queensbay/cpu.c
>>> @@ -0,0 +1,61 @@
>>> +/*
>>> + * Copyright (C) 2016, Bachmann electronic GmbH
>>
>> nits: 2018?
>>
>
> This change was made some months ago :) But yeah.. can change it.
>
>>> + *
>>> + * SPDX-License-Identifier:GPL-2.0+
>>> + */
>>> +
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +static void set_max_freq(void)
>>> +{
>>> +   msr_t msr;
>>> +
>>> +   msr = msr_read(MSR_IA32_MISC_ENABLES);
>>> +   msr.lo |= (1 << 16);
>>
>> Please use macro instead of magic numbers
>
> ok
>
>>
>>> +   msr_write(MSR_IA32_MISC_ENABLES, msr);
>>> +
>>> +   msr = msr_read(MSR_IA32_PERF_CTL);
>>> +   msr.lo = 0x101f;
>>
>> ditto
>
> ok
>
> I *think* I have read this msr running under a 'good' bios so I am not
> really sure
> what the meaning of the bits are. I tried a quick google and did not found any
> E6xx datasheet containing the description. Is it okay to just use the
> magic value here?
>

I will see if I can find anything.

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

Re: [U-Boot] [PATCH 1/3] doc: vxworks: Minor update for clarity

[Christian Gmeiner]

2018-04-10 4:31 GMT+02:00 Bin Meng :
> This corrects a typo and updates several places for clarity.
>
> Signed-off-by: Bin Meng 

Reviewed-by: Christian Gmeiner 

> ---
>
>  doc/README.vxworks | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/doc/README.vxworks b/doc/README.vxworks
> index 3433e4f..eb1f458 100644
> --- a/doc/README.vxworks
> +++ b/doc/README.vxworks
> @@ -30,11 +30,11 @@ the ePAPR standard, which is shown below (see ePAPR for 
> more details):
>
>  void (*kernel_entry)(fdt_addr, 0, 0, EPAPR_MAGIC, boot_IMA, 0, 0)
>
> -For ARM, the calling convention is show below:
> +For ARM, the calling convention is shown below:
>
>  void (*kernel_entry)(void *fdt_addr)
>
> -When booting new VxWorks kernel (uImage format), the parameters passed to 
> bootm
> +When booting a VxWorks 7 kernel (uImage format), the parameters passed to 
> bootm
>  is like below:
>
>  bootm  - 
> @@ -46,7 +46,7 @@ board-specific address before loading VxWorks. U-Boot 
> supplies its address
>  via "bootaddr" environment variable. To check where the bootline should be
>  for a specific board, go to the VxWorks BSP for that board, and look for a
>  parameter called BOOT_LINE_ADRS. Assign its value to "bootaddr". A typical
> -value for "bootaddr" is 0x101200.
> +value for "bootaddr" on an x86 board is 0x101200.
>
>  If a "bootargs" variable is defined, its content will be copied to the memory
>  location pointed by "bootaddr" as the kernel bootline. If "bootargs" is not
> @@ -79,7 +79,7 @@ for "e820data" and "e820info" are 0x104000 and 0x104a00. 
> But there is one
>  exception on Intel Galileo, where "e820data" and "e820info" should be left
>  unset, which assume the default location for VxWorks.
>
> -Note since currently U-Boot does not support ACPI yet, VxWorks kernel must
> +For boards on which ACPI is not supported by U-Boot yet, VxWorks kernel must
>  be configured to use MP table and virtual wire interrupt mode. This requires
>  INCLUDE_MPTABLE_BOOT_OP and INCLUDE_VIRTUAL_WIRE_MODE to be included in a
>  VxWorks kernel configuration.
> --
> 2.7.4
>



-- 
greets
--
Christian Gmeiner, MSc

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

Re: [U-Boot] [PATCH] x86: queensbay: switche P state to the highest freq

[Christian Gmeiner]

2018-04-10 11:11 GMT+02:00 Bin Meng :
> Hi Christian,
>
> On Tue, Apr 10, 2018 at 5:09 PM, Christian Gmeiner
>  wrote:
>> Hi Bin,
>>
>> 2018-04-10 11:07 GMT+02:00 Bin Meng :
>>> Hi Christian,
>>>
>>> On Tue, Apr 10, 2018 at 4:47 PM, Christian Gmeiner
>>>  wrote:
 Hi Bin

 Thanks for you quick review!

>
> On Tue, Apr 10, 2018 at 4:01 PM, Christian Gmeiner
>  wrote:
>> Fixes performance issue when running vx5/vx7 images.
>
> Could you elaborate more on what performance issue you are seeing?
>

 The cache performance was bad without this change. We found this problem
 when switching from bldk to u-boot.

 old: https://imagebin.ca/v/3xssw7stbY6A
 new: https://imagebin.ca/v/3xstHMCC9fmJ
>>>
>>> Thank you for the benchmark data. Then please consider describing your
>>> benchmark test suite and on what configuration the data is worse
>>> without this patch (eg: sequential 128-bit read) in the commit
>>> message. This will help other people understand the patch and the
>>> commit in the future.
>>>
>>
>> Will do.
>>

> nits: better to spell out "VxWorks"

 ok

>
>>
>> Signed-off-by: Christian Gmeiner 
>> ---
>>  arch/x86/cpu/queensbay/Makefile |  2 +-
>>  arch/x86/cpu/queensbay/cpu.c| 61 
>> +
>>  2 files changed, 62 insertions(+), 1 deletion(-)
>>  create mode 100644 arch/x86/cpu/queensbay/cpu.c
>>
>> diff --git a/arch/x86/cpu/queensbay/Makefile 
>> b/arch/x86/cpu/queensbay/Makefile
>> index c0681995bd..3dd23465d4 100644
>> --- a/arch/x86/cpu/queensbay/Makefile
>> +++ b/arch/x86/cpu/queensbay/Makefile
>> @@ -5,4 +5,4 @@
>>  #
>>
>>  obj-y += fsp_configs.o irq.o
>> -obj-y += tnc.o
>> +obj-y += tnc.o cpu.o
>> diff --git a/arch/x86/cpu/queensbay/cpu.c b/arch/x86/cpu/queensbay/cpu.c
>> new file mode 100644
>> index 00..e98e4ac8ef
>> --- /dev/null
>> +++ b/arch/x86/cpu/queensbay/cpu.c
>> @@ -0,0 +1,61 @@
>> +/*
>> + * Copyright (C) 2016, Bachmann electronic GmbH
>
> nits: 2018?
>

 This change was made some months ago :) But yeah.. can change it.

>> + *
>> + * SPDX-License-Identifier:GPL-2.0+
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +static void set_max_freq(void)
>> +{
>> +   msr_t msr;
>> +
>> +   msr = msr_read(MSR_IA32_MISC_ENABLES);
>> +   msr.lo |= (1 << 16);
>
> Please use macro instead of magic numbers

 ok

>
>> +   msr_write(MSR_IA32_MISC_ENABLES, msr);
>> +
>> +   msr = msr_read(MSR_IA32_PERF_CTL);
>> +   msr.lo = 0x101f;
>
> ditto

 ok

I *think* I have read this msr running under a 'good' bios so I am not
really sure
what the meaning of the bits are. I tried a quick google and did not found any
E6xx datasheet containing the description. Is it okay to just use the
magic value here?

-- 
greets
--
Christian Gmeiner, MSc

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

[U-Boot] [PATCH v2] vxworks: fixed cpu enable using PSCI on armv8

[Vasyl Vavrychuk]

Without armv8_setup_psci register VBAR_EL3 is not set up property which
makes SMC calls jump to invalid location.

smp_kick_all_cpus is required to make slave cpus leave gic_wait_for_interrupt.
Without this they will never pursue booting process.

Fix was applied to the two ways of booting VxWorks: bootvx and bootm commands.

This implementation is very similiar to what is done in boot_jump_linux
in arch/arm/lib/bootm.c file.

Tested on VxWorks 7 release SR0520 2017-12-08 Intel Stratix 10 SX SoC
Development Kit board.

Signed-off-by: Vasyl Vavrychuk 
Reviewed-by: Bin Meng 
---
 arch/arm/lib/bootm.c | 5 +
 cmd/elf.c| 5 +
 2 files changed, 10 insertions(+)

diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
index cfc236f964..91a64bec34 100644
--- a/arch/arm/lib/bootm.c
+++ b/arch/arm/lib/bootm.c
@@ -448,6 +448,11 @@ void boot_prep_vxworks(bootm_headers_t *images)
 }
 void boot_jump_vxworks(bootm_headers_t *images)
 {
+#if defined(CONFIG_ARM64) && defined(CONFIG_ARMV8_PSCI)
+   armv8_setup_psci();
+   smp_kick_all_cpus();
+#endif
+
/* ARM VxWorks requires device tree physical address to be passed */
((void (*)(void *))images->ep)(images->ft_addr);
 }
diff --git a/cmd/elf.c b/cmd/elf.c
index 5b59fc6329..b476202908 100644
--- a/cmd/elf.c
+++ b/cmd/elf.c
@@ -368,6 +368,11 @@ int do_bootvx(cmd_tbl_t *cmdtp, int flag, int argc, char * 
const argv[])
printf("## Starting vxWorks at 0x%08lx ...\n", addr);
 
dcache_disable();
+#if defined(CONFIG_ARM64) && defined(CONFIG_ARMV8_PSCI)
+   armv8_setup_psci();
+   smp_kick_all_cpus();
+#endif
+
 #ifdef CONFIG_X86
/* VxWorks on x86 uses stack to pass parameters */
((asmlinkage void (*)(int))addr)(0);
-- 
2.11.0

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

Re: [U-Boot] [PATCH] vxworks: fixed cpu enable using PSCI on armv8

[Bin Meng]

Hi Vasyl,

On Tue, Apr 10, 2018 at 5:16 PM, Vasyl Vavrychuk  wrote:
> Without armv8_setup_psci register VBAR_EL3 is not set up property which
> makes SMC calls jump to invalid location.
>
> smp_kick_all_cpus is required to make slave cpus leave gic_wait_for_interrupt.
> Without this they will never pursue booting process.
>
> Fix was applied to the two ways of booting VxWorks: bootvx and bootm commands.
>
> This implementation is very similiar to what is done in boot_jump_linux
> in arch/arm/lib/bootm.c file.
>
> Tested on VxWorks 7 release SR0520 2017-12-08.

Could you please indicate the board you used for the testing as well? Thanks!

>
> Signed-off-by: Vasyl Vavrychuk 
> ---
>  arch/arm/lib/bootm.c | 5 +
>  cmd/elf.c| 5 +
>  2 files changed, 10 insertions(+)
>

Otherwise,
Reviewed-by: Bin Meng 

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

[U-Boot] [PATCH] vxworks: fixed cpu enable using PSCI on armv8

[Vasyl Vavrychuk]

Without armv8_setup_psci register VBAR_EL3 is not set up property which
makes SMC calls jump to invalid location.

smp_kick_all_cpus is required to make slave cpus leave gic_wait_for_interrupt.
Without this they will never pursue booting process.

Fix was applied to the two ways of booting VxWorks: bootvx and bootm commands.

This implementation is very similiar to what is done in boot_jump_linux
in arch/arm/lib/bootm.c file.

Tested on VxWorks 7 release SR0520 2017-12-08.

Signed-off-by: Vasyl Vavrychuk 
---
 arch/arm/lib/bootm.c | 5 +
 cmd/elf.c| 5 +
 2 files changed, 10 insertions(+)

diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
index cfc236f964..91a64bec34 100644
--- a/arch/arm/lib/bootm.c
+++ b/arch/arm/lib/bootm.c
@@ -448,6 +448,11 @@ void boot_prep_vxworks(bootm_headers_t *images)
 }
 void boot_jump_vxworks(bootm_headers_t *images)
 {
+#if defined(CONFIG_ARM64) && defined(CONFIG_ARMV8_PSCI)
+   armv8_setup_psci();
+   smp_kick_all_cpus();
+#endif
+
/* ARM VxWorks requires device tree physical address to be passed */
((void (*)(void *))images->ep)(images->ft_addr);
 }
diff --git a/cmd/elf.c b/cmd/elf.c
index 5b59fc6329..b476202908 100644
--- a/cmd/elf.c
+++ b/cmd/elf.c
@@ -368,6 +368,11 @@ int do_bootvx(cmd_tbl_t *cmdtp, int flag, int argc, char * 
const argv[])
printf("## Starting vxWorks at 0x%08lx ...\n", addr);
 
dcache_disable();
+#if defined(CONFIG_ARM64) && defined(CONFIG_ARMV8_PSCI)
+   armv8_setup_psci();
+   smp_kick_all_cpus();
+#endif
+
 #ifdef CONFIG_X86
/* VxWorks on x86 uses stack to pass parameters */
((asmlinkage void (*)(int))addr)(0);
-- 
2.11.0

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

Re: [U-Boot] [PATCH] x86: queensbay: switche P state to the highest freq

[Bin Meng]

Hi Christian,

On Tue, Apr 10, 2018 at 5:09 PM, Christian Gmeiner
 wrote:
> Hi Bin,
>
> 2018-04-10 11:07 GMT+02:00 Bin Meng :
>> Hi Christian,
>>
>> On Tue, Apr 10, 2018 at 4:47 PM, Christian Gmeiner
>>  wrote:
>>> Hi Bin
>>>
>>> Thanks for you quick review!
>>>

 On Tue, Apr 10, 2018 at 4:01 PM, Christian Gmeiner
  wrote:
> Fixes performance issue when running vx5/vx7 images.

 Could you elaborate more on what performance issue you are seeing?

>>>
>>> The cache performance was bad without this change. We found this problem
>>> when switching from bldk to u-boot.
>>>
>>> old: https://imagebin.ca/v/3xssw7stbY6A
>>> new: https://imagebin.ca/v/3xstHMCC9fmJ
>>
>> Thank you for the benchmark data. Then please consider describing your
>> benchmark test suite and on what configuration the data is worse
>> without this patch (eg: sequential 128-bit read) in the commit
>> message. This will help other people understand the patch and the
>> commit in the future.
>>
>
> Will do.
>
>>>
 nits: better to spell out "VxWorks"
>>>
>>> ok
>>>

>
> Signed-off-by: Christian Gmeiner 
> ---
>  arch/x86/cpu/queensbay/Makefile |  2 +-
>  arch/x86/cpu/queensbay/cpu.c| 61 
> +
>  2 files changed, 62 insertions(+), 1 deletion(-)
>  create mode 100644 arch/x86/cpu/queensbay/cpu.c
>
> diff --git a/arch/x86/cpu/queensbay/Makefile 
> b/arch/x86/cpu/queensbay/Makefile
> index c0681995bd..3dd23465d4 100644
> --- a/arch/x86/cpu/queensbay/Makefile
> +++ b/arch/x86/cpu/queensbay/Makefile
> @@ -5,4 +5,4 @@
>  #
>
>  obj-y += fsp_configs.o irq.o
> -obj-y += tnc.o
> +obj-y += tnc.o cpu.o
> diff --git a/arch/x86/cpu/queensbay/cpu.c b/arch/x86/cpu/queensbay/cpu.c
> new file mode 100644
> index 00..e98e4ac8ef
> --- /dev/null
> +++ b/arch/x86/cpu/queensbay/cpu.c
> @@ -0,0 +1,61 @@
> +/*
> + * Copyright (C) 2016, Bachmann electronic GmbH

 nits: 2018?

>>>
>>> This change was made some months ago :) But yeah.. can change it.
>>>
> + *
> + * SPDX-License-Identifier:GPL-2.0+
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +static void set_max_freq(void)
> +{
> +   msr_t msr;
> +
> +   msr = msr_read(MSR_IA32_MISC_ENABLES);
> +   msr.lo |= (1 << 16);

 Please use macro instead of magic numbers
>>>
>>> ok
>>>

> +   msr_write(MSR_IA32_MISC_ENABLES, msr);
> +
> +   msr = msr_read(MSR_IA32_PERF_CTL);
> +   msr.lo = 0x101f;

 ditto
>>>
>>> ok
>>>

> +   msr_write(MSR_IA32_PERF_CTL, msr);
> +}
> +
> +static int cpu_x86_queensbay_probe(struct udevice *dev)

 Queensbay is the platform codename, not the core codename. Queensbay =
 TunnelCreek (the processor) + Topcliff (the bridge chipset).

> +{
> +   if (!ll_boot_init())
> +   return 0;
> +   debug("Init Queensbay core\n");

 Should be "TunnelCreek"

>>>
>>> ok
>>>
> +
> +   /* Set core to max frequency ratio */
> +   set_max_freq();
> +
> +   return 0;
> +}
> +
> +static int queensbay_get_count(struct udevice *dev)
> +{
> +   return 2;
> +}

 Please use cpu_x86_get_count() instead of hard code.

>>>
>>> That one uses the dts as basis for this information and I need to
>>> add two cpu nodes. I also thought about using cpuid for this. Not
>>> sure what is better.
>>>
>>
>> I don't understand. Isn't your board U-Boot ported from Intel Crown
>> Bay? There is arch/x86/dts/crownbay.dts already. You don't need do any
>> mods in the dts.
>>
>
> The dts is not in its ideal state I would say but that is fixable. I
> hope to send
> out patches for this board soon.
>

Great. Looking forward to your board support patch.

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

Re: [U-Boot] [PATCH] x86: queensbay: switche P state to the highest freq

[Christian Gmeiner]

Hi Bin,

2018-04-10 11:07 GMT+02:00 Bin Meng :
> Hi Christian,
>
> On Tue, Apr 10, 2018 at 4:47 PM, Christian Gmeiner
>  wrote:
>> Hi Bin
>>
>> Thanks for you quick review!
>>
>>>
>>> On Tue, Apr 10, 2018 at 4:01 PM, Christian Gmeiner
>>>  wrote:
 Fixes performance issue when running vx5/vx7 images.
>>>
>>> Could you elaborate more on what performance issue you are seeing?
>>>
>>
>> The cache performance was bad without this change. We found this problem
>> when switching from bldk to u-boot.
>>
>> old: https://imagebin.ca/v/3xssw7stbY6A
>> new: https://imagebin.ca/v/3xstHMCC9fmJ
>
> Thank you for the benchmark data. Then please consider describing your
> benchmark test suite and on what configuration the data is worse
> without this patch (eg: sequential 128-bit read) in the commit
> message. This will help other people understand the patch and the
> commit in the future.
>

Will do.

>>
>>> nits: better to spell out "VxWorks"
>>
>> ok
>>
>>>

 Signed-off-by: Christian Gmeiner 
 ---
  arch/x86/cpu/queensbay/Makefile |  2 +-
  arch/x86/cpu/queensbay/cpu.c| 61 
 +
  2 files changed, 62 insertions(+), 1 deletion(-)
  create mode 100644 arch/x86/cpu/queensbay/cpu.c

 diff --git a/arch/x86/cpu/queensbay/Makefile 
 b/arch/x86/cpu/queensbay/Makefile
 index c0681995bd..3dd23465d4 100644
 --- a/arch/x86/cpu/queensbay/Makefile
 +++ b/arch/x86/cpu/queensbay/Makefile
 @@ -5,4 +5,4 @@
  #

  obj-y += fsp_configs.o irq.o
 -obj-y += tnc.o
 +obj-y += tnc.o cpu.o
 diff --git a/arch/x86/cpu/queensbay/cpu.c b/arch/x86/cpu/queensbay/cpu.c
 new file mode 100644
 index 00..e98e4ac8ef
 --- /dev/null
 +++ b/arch/x86/cpu/queensbay/cpu.c
 @@ -0,0 +1,61 @@
 +/*
 + * Copyright (C) 2016, Bachmann electronic GmbH
>>>
>>> nits: 2018?
>>>
>>
>> This change was made some months ago :) But yeah.. can change it.
>>
 + *
 + * SPDX-License-Identifier:GPL-2.0+
 + */
 +
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +
 +static void set_max_freq(void)
 +{
 +   msr_t msr;
 +
 +   msr = msr_read(MSR_IA32_MISC_ENABLES);
 +   msr.lo |= (1 << 16);
>>>
>>> Please use macro instead of magic numbers
>>
>> ok
>>
>>>
 +   msr_write(MSR_IA32_MISC_ENABLES, msr);
 +
 +   msr = msr_read(MSR_IA32_PERF_CTL);
 +   msr.lo = 0x101f;
>>>
>>> ditto
>>
>> ok
>>
>>>
 +   msr_write(MSR_IA32_PERF_CTL, msr);
 +}
 +
 +static int cpu_x86_queensbay_probe(struct udevice *dev)
>>>
>>> Queensbay is the platform codename, not the core codename. Queensbay =
>>> TunnelCreek (the processor) + Topcliff (the bridge chipset).
>>>
 +{
 +   if (!ll_boot_init())
 +   return 0;
 +   debug("Init Queensbay core\n");
>>>
>>> Should be "TunnelCreek"
>>>
>>
>> ok
>>
 +
 +   /* Set core to max frequency ratio */
 +   set_max_freq();
 +
 +   return 0;
 +}
 +
 +static int queensbay_get_count(struct udevice *dev)
 +{
 +   return 2;
 +}
>>>
>>> Please use cpu_x86_get_count() instead of hard code.
>>>
>>
>> That one uses the dts as basis for this information and I need to
>> add two cpu nodes. I also thought about using cpuid for this. Not
>> sure what is better.
>>
>
> I don't understand. Isn't your board U-Boot ported from Intel Crown
> Bay? There is arch/x86/dts/crownbay.dts already. You don't need do any
> mods in the dts.
>

The dts is not in its ideal state I would say but that is fixable. I
hope to send
out patches for this board soon.

 +
 +static const struct cpu_ops cpu_x86_queensbay_ops = {
 +   .get_desc   = cpu_x86_get_desc,
 +   .get_count  = queensbay_get_count,
 +};
 +
 +static const struct udevice_id cpu_x86_queensbay_ids[] = {
 +   { .compatible = "intel,queensbay-cpu" },
>>>
>>> This should be "intel,tunnelcreek-cpu"
>>
>> ok
>>
>>>
 +   { }
 +};
 +
 +U_BOOT_DRIVER(cpu_x86_queensbay_drv) = {
 +   .name   = "cpu_x86_queensbay",
 +   .id = UCLASS_CPU,
 +   .of_match   = cpu_x86_queensbay_ids,
 +   .bind   = cpu_x86_bind,
 +   .probe  = cpu_x86_queensbay_probe,
 +   .ops= _x86_queensbay_ops,
 +};
 --

-- 
greets
--
Christian Gmeiner, MSc

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

Re: [U-Boot] [PATCH] x86: queensbay: switche P state to the highest freq

[Bin Meng]

Hi Christian,

On Tue, Apr 10, 2018 at 4:47 PM, Christian Gmeiner
 wrote:
> Hi Bin
>
> Thanks for you quick review!
>
>>
>> On Tue, Apr 10, 2018 at 4:01 PM, Christian Gmeiner
>>  wrote:
>>> Fixes performance issue when running vx5/vx7 images.
>>
>> Could you elaborate more on what performance issue you are seeing?
>>
>
> The cache performance was bad without this change. We found this problem
> when switching from bldk to u-boot.
>
> old: https://imagebin.ca/v/3xssw7stbY6A
> new: https://imagebin.ca/v/3xstHMCC9fmJ

Thank you for the benchmark data. Then please consider describing your
benchmark test suite and on what configuration the data is worse
without this patch (eg: sequential 128-bit read) in the commit
message. This will help other people understand the patch and the
commit in the future.

>
>> nits: better to spell out "VxWorks"
>
> ok
>
>>
>>>
>>> Signed-off-by: Christian Gmeiner 
>>> ---
>>>  arch/x86/cpu/queensbay/Makefile |  2 +-
>>>  arch/x86/cpu/queensbay/cpu.c| 61 
>>> +
>>>  2 files changed, 62 insertions(+), 1 deletion(-)
>>>  create mode 100644 arch/x86/cpu/queensbay/cpu.c
>>>
>>> diff --git a/arch/x86/cpu/queensbay/Makefile 
>>> b/arch/x86/cpu/queensbay/Makefile
>>> index c0681995bd..3dd23465d4 100644
>>> --- a/arch/x86/cpu/queensbay/Makefile
>>> +++ b/arch/x86/cpu/queensbay/Makefile
>>> @@ -5,4 +5,4 @@
>>>  #
>>>
>>>  obj-y += fsp_configs.o irq.o
>>> -obj-y += tnc.o
>>> +obj-y += tnc.o cpu.o
>>> diff --git a/arch/x86/cpu/queensbay/cpu.c b/arch/x86/cpu/queensbay/cpu.c
>>> new file mode 100644
>>> index 00..e98e4ac8ef
>>> --- /dev/null
>>> +++ b/arch/x86/cpu/queensbay/cpu.c
>>> @@ -0,0 +1,61 @@
>>> +/*
>>> + * Copyright (C) 2016, Bachmann electronic GmbH
>>
>> nits: 2018?
>>
>
> This change was made some months ago :) But yeah.. can change it.
>
>>> + *
>>> + * SPDX-License-Identifier:GPL-2.0+
>>> + */
>>> +
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +static void set_max_freq(void)
>>> +{
>>> +   msr_t msr;
>>> +
>>> +   msr = msr_read(MSR_IA32_MISC_ENABLES);
>>> +   msr.lo |= (1 << 16);
>>
>> Please use macro instead of magic numbers
>
> ok
>
>>
>>> +   msr_write(MSR_IA32_MISC_ENABLES, msr);
>>> +
>>> +   msr = msr_read(MSR_IA32_PERF_CTL);
>>> +   msr.lo = 0x101f;
>>
>> ditto
>
> ok
>
>>
>>> +   msr_write(MSR_IA32_PERF_CTL, msr);
>>> +}
>>> +
>>> +static int cpu_x86_queensbay_probe(struct udevice *dev)
>>
>> Queensbay is the platform codename, not the core codename. Queensbay =
>> TunnelCreek (the processor) + Topcliff (the bridge chipset).
>>
>>> +{
>>> +   if (!ll_boot_init())
>>> +   return 0;
>>> +   debug("Init Queensbay core\n");
>>
>> Should be "TunnelCreek"
>>
>
> ok
>
>>> +
>>> +   /* Set core to max frequency ratio */
>>> +   set_max_freq();
>>> +
>>> +   return 0;
>>> +}
>>> +
>>> +static int queensbay_get_count(struct udevice *dev)
>>> +{
>>> +   return 2;
>>> +}
>>
>> Please use cpu_x86_get_count() instead of hard code.
>>
>
> That one uses the dts as basis for this information and I need to
> add two cpu nodes. I also thought about using cpuid for this. Not
> sure what is better.
>

I don't understand. Isn't your board U-Boot ported from Intel Crown
Bay? There is arch/x86/dts/crownbay.dts already. You don't need do any
mods in the dts.

>>> +
>>> +static const struct cpu_ops cpu_x86_queensbay_ops = {
>>> +   .get_desc   = cpu_x86_get_desc,
>>> +   .get_count  = queensbay_get_count,
>>> +};
>>> +
>>> +static const struct udevice_id cpu_x86_queensbay_ids[] = {
>>> +   { .compatible = "intel,queensbay-cpu" },
>>
>> This should be "intel,tunnelcreek-cpu"
>
> ok
>
>>
>>> +   { }
>>> +};
>>> +
>>> +U_BOOT_DRIVER(cpu_x86_queensbay_drv) = {
>>> +   .name   = "cpu_x86_queensbay",
>>> +   .id = UCLASS_CPU,
>>> +   .of_match   = cpu_x86_queensbay_ids,
>>> +   .bind   = cpu_x86_bind,
>>> +   .probe  = cpu_x86_queensbay_probe,
>>> +   .ops= _x86_queensbay_ops,
>>> +};
>>> --

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

Re: [U-Boot] [PATCH] x86: queensbay: switche P state to the highest freq

[Christian Gmeiner]

Hi Bin

Thanks for you quick review!

>
> On Tue, Apr 10, 2018 at 4:01 PM, Christian Gmeiner
>  wrote:
>> Fixes performance issue when running vx5/vx7 images.
>
> Could you elaborate more on what performance issue you are seeing?
>

The cache performance was bad without this change. We found this problem
when switching from bldk to u-boot.

old: https://imagebin.ca/v/3xssw7stbY6A
new: https://imagebin.ca/v/3xstHMCC9fmJ

> nits: better to spell out "VxWorks"

ok

>
>>
>> Signed-off-by: Christian Gmeiner 
>> ---
>>  arch/x86/cpu/queensbay/Makefile |  2 +-
>>  arch/x86/cpu/queensbay/cpu.c| 61 
>> +
>>  2 files changed, 62 insertions(+), 1 deletion(-)
>>  create mode 100644 arch/x86/cpu/queensbay/cpu.c
>>
>> diff --git a/arch/x86/cpu/queensbay/Makefile 
>> b/arch/x86/cpu/queensbay/Makefile
>> index c0681995bd..3dd23465d4 100644
>> --- a/arch/x86/cpu/queensbay/Makefile
>> +++ b/arch/x86/cpu/queensbay/Makefile
>> @@ -5,4 +5,4 @@
>>  #
>>
>>  obj-y += fsp_configs.o irq.o
>> -obj-y += tnc.o
>> +obj-y += tnc.o cpu.o
>> diff --git a/arch/x86/cpu/queensbay/cpu.c b/arch/x86/cpu/queensbay/cpu.c
>> new file mode 100644
>> index 00..e98e4ac8ef
>> --- /dev/null
>> +++ b/arch/x86/cpu/queensbay/cpu.c
>> @@ -0,0 +1,61 @@
>> +/*
>> + * Copyright (C) 2016, Bachmann electronic GmbH
>
> nits: 2018?
>

This change was made some months ago :) But yeah.. can change it.

>> + *
>> + * SPDX-License-Identifier:GPL-2.0+
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +static void set_max_freq(void)
>> +{
>> +   msr_t msr;
>> +
>> +   msr = msr_read(MSR_IA32_MISC_ENABLES);
>> +   msr.lo |= (1 << 16);
>
> Please use macro instead of magic numbers

ok

>
>> +   msr_write(MSR_IA32_MISC_ENABLES, msr);
>> +
>> +   msr = msr_read(MSR_IA32_PERF_CTL);
>> +   msr.lo = 0x101f;
>
> ditto

ok

>
>> +   msr_write(MSR_IA32_PERF_CTL, msr);
>> +}
>> +
>> +static int cpu_x86_queensbay_probe(struct udevice *dev)
>
> Queensbay is the platform codename, not the core codename. Queensbay =
> TunnelCreek (the processor) + Topcliff (the bridge chipset).
>
>> +{
>> +   if (!ll_boot_init())
>> +   return 0;
>> +   debug("Init Queensbay core\n");
>
> Should be "TunnelCreek"
>

ok

>> +
>> +   /* Set core to max frequency ratio */
>> +   set_max_freq();
>> +
>> +   return 0;
>> +}
>> +
>> +static int queensbay_get_count(struct udevice *dev)
>> +{
>> +   return 2;
>> +}
>
> Please use cpu_x86_get_count() instead of hard code.
>

That one uses the dts as basis for this information and I need to
add two cpu nodes. I also thought about using cpuid for this. Not
sure what is better.

>> +
>> +static const struct cpu_ops cpu_x86_queensbay_ops = {
>> +   .get_desc   = cpu_x86_get_desc,
>> +   .get_count  = queensbay_get_count,
>> +};
>> +
>> +static const struct udevice_id cpu_x86_queensbay_ids[] = {
>> +   { .compatible = "intel,queensbay-cpu" },
>
> This should be "intel,tunnelcreek-cpu"

ok

>
>> +   { }
>> +};
>> +
>> +U_BOOT_DRIVER(cpu_x86_queensbay_drv) = {
>> +   .name   = "cpu_x86_queensbay",
>> +   .id = UCLASS_CPU,
>> +   .of_match   = cpu_x86_queensbay_ids,
>> +   .bind   = cpu_x86_bind,
>> +   .probe  = cpu_x86_queensbay_probe,
>> +   .ops= _x86_queensbay_ops,
>> +};
>> --

-- 
greets
--
Christian Gmeiner, MSc

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

Re: [U-Boot] [U-Boot, v2, 1/5] Migrate CONFIG_DRIVER_TI_CPSW to Kconfig

[Felix Brack]

On 10.04.2018 10:09, Alex Kiernan wrote:
> On Tue, Apr 10, 2018 at 8:04 AM, Felix Brack  wrote:
>>
>> On 10.04.2018 09:47, Alex Kiernan wrote:
>>> On Tue, Apr 10, 2018 at 7:21 AM, Felix Brack  wrote:
 Hi Tom,

 On 09.04.2018 17:03, Tom Rini wrote:
> On Sun, Apr 01, 2018 at 09:22:34AM +, Alex Kiernan wrote:
>
>> This converts CONFIG_DRIVER_TI_CPSW to Kconfig
>>
>> Signed-off-by: Alex Kiernan 
>> Acked-by: Joe Hershberger 
>
> Applied to u-boot/master, thanks!
>
 Why did you apply this patch? It introduces a build warning?

>>>
>>> Sorry, we probably want to revert this one, or try adding "depends on
>>> NET" to DRIVER_TI_CPSW in drivers/net/Kconfig; I'm stuck without a
>>> laptop until the end of the week so I've not been able to get back to
>>> fix this :(
>>>
>> Please do _not_ add this dependency to "solve" the build problem I
>> reported. This would just blow up the U-Boot code for the PDU001 board.
>>
>> As already stated: it is best to remove CONFIG_DRIVER_TI_CPSW=y from
>> configs/am335x_pdu001_defconfig leaving this file unchanged.
>>
> 
> That only fixes that one board - agreed, it wants removing from that
> config, but there's doubtless others which don't have NET enabled. My
> thinking was add the depends and then redo the moveconfig which would
> then remove it from all other boards too.
> 
Okay, I see. As I'm the maintainer of this board, that was my only
focus. My focus was not on the patch as a whole, sorry.

> Tom, probably best to revert this one and I'll get a correct patch
> done when I'm back (should be early next week).
> 
Agreed. However, knowing that it will get fixed, I could also live with
that warning for some weeks ;)

Felix

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

Re: [U-Boot] [PATCH] x86: queensbay: switche P state to the highest freq

[Bin Meng]

Hi Christian,

On Tue, Apr 10, 2018 at 4:01 PM, Christian Gmeiner
 wrote:
> Fixes performance issue when running vx5/vx7 images.

Could you elaborate more on what performance issue you are seeing?

nits: better to spell out "VxWorks"

>
> Signed-off-by: Christian Gmeiner 
> ---
>  arch/x86/cpu/queensbay/Makefile |  2 +-
>  arch/x86/cpu/queensbay/cpu.c| 61 
> +
>  2 files changed, 62 insertions(+), 1 deletion(-)
>  create mode 100644 arch/x86/cpu/queensbay/cpu.c
>
> diff --git a/arch/x86/cpu/queensbay/Makefile b/arch/x86/cpu/queensbay/Makefile
> index c0681995bd..3dd23465d4 100644
> --- a/arch/x86/cpu/queensbay/Makefile
> +++ b/arch/x86/cpu/queensbay/Makefile
> @@ -5,4 +5,4 @@
>  #
>
>  obj-y += fsp_configs.o irq.o
> -obj-y += tnc.o
> +obj-y += tnc.o cpu.o
> diff --git a/arch/x86/cpu/queensbay/cpu.c b/arch/x86/cpu/queensbay/cpu.c
> new file mode 100644
> index 00..e98e4ac8ef
> --- /dev/null
> +++ b/arch/x86/cpu/queensbay/cpu.c
> @@ -0,0 +1,61 @@
> +/*
> + * Copyright (C) 2016, Bachmann electronic GmbH

nits: 2018?

> + *
> + * SPDX-License-Identifier:GPL-2.0+
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +static void set_max_freq(void)
> +{
> +   msr_t msr;
> +
> +   msr = msr_read(MSR_IA32_MISC_ENABLES);
> +   msr.lo |= (1 << 16);

Please use macro instead of magic numbers

> +   msr_write(MSR_IA32_MISC_ENABLES, msr);
> +
> +   msr = msr_read(MSR_IA32_PERF_CTL);
> +   msr.lo = 0x101f;

ditto

> +   msr_write(MSR_IA32_PERF_CTL, msr);
> +}
> +
> +static int cpu_x86_queensbay_probe(struct udevice *dev)

Queensbay is the platform codename, not the core codename. Queensbay =
TunnelCreek (the processor) + Topcliff (the bridge chipset).

> +{
> +   if (!ll_boot_init())
> +   return 0;
> +   debug("Init Queensbay core\n");

Should be "TunnelCreek"

> +
> +   /* Set core to max frequency ratio */
> +   set_max_freq();
> +
> +   return 0;
> +}
> +
> +static int queensbay_get_count(struct udevice *dev)
> +{
> +   return 2;
> +}

Please use cpu_x86_get_count() instead of hard code.

> +
> +static const struct cpu_ops cpu_x86_queensbay_ops = {
> +   .get_desc   = cpu_x86_get_desc,
> +   .get_count  = queensbay_get_count,
> +};
> +
> +static const struct udevice_id cpu_x86_queensbay_ids[] = {
> +   { .compatible = "intel,queensbay-cpu" },

This should be "intel,tunnelcreek-cpu"

> +   { }
> +};
> +
> +U_BOOT_DRIVER(cpu_x86_queensbay_drv) = {
> +   .name   = "cpu_x86_queensbay",
> +   .id = UCLASS_CPU,
> +   .of_match   = cpu_x86_queensbay_ids,
> +   .bind   = cpu_x86_bind,
> +   .probe  = cpu_x86_queensbay_probe,
> +   .ops= _x86_queensbay_ops,
> +};
> --

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

Re: [U-Boot] [U-Boot, v2, 1/5] Migrate CONFIG_DRIVER_TI_CPSW to Kconfig

[Alex Kiernan]

On Tue, Apr 10, 2018 at 8:04 AM, Felix Brack  wrote:
>
> On 10.04.2018 09:47, Alex Kiernan wrote:
>> On Tue, Apr 10, 2018 at 7:21 AM, Felix Brack  wrote:
>>> Hi Tom,
>>>
>>> On 09.04.2018 17:03, Tom Rini wrote:
 On Sun, Apr 01, 2018 at 09:22:34AM +, Alex Kiernan wrote:

> This converts CONFIG_DRIVER_TI_CPSW to Kconfig
>
> Signed-off-by: Alex Kiernan 
> Acked-by: Joe Hershberger 

 Applied to u-boot/master, thanks!

>>> Why did you apply this patch? It introduces a build warning?
>>>
>>
>> Sorry, we probably want to revert this one, or try adding "depends on
>> NET" to DRIVER_TI_CPSW in drivers/net/Kconfig; I'm stuck without a
>> laptop until the end of the week so I've not been able to get back to
>> fix this :(
>>
> Please do _not_ add this dependency to "solve" the build problem I
> reported. This would just blow up the U-Boot code for the PDU001 board.
>
> As already stated: it is best to remove CONFIG_DRIVER_TI_CPSW=y from
> configs/am335x_pdu001_defconfig leaving this file unchanged.
>

That only fixes that one board - agreed, it wants removing from that
config, but there's doubtless others which don't have NET enabled. My
thinking was add the depends and then redo the moveconfig which would
then remove it from all other boards too.

Tom, probably best to revert this one and I'll get a correct patch
done when I'm back (should be early next week).




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

Re: [U-Boot] [U-Boot, v2, 1/5] Migrate CONFIG_DRIVER_TI_CPSW to Kconfig

[Felix Brack]

On 10.04.2018 09:47, Alex Kiernan wrote:
> On Tue, Apr 10, 2018 at 7:21 AM, Felix Brack  wrote:
>> Hi Tom,
>>
>> On 09.04.2018 17:03, Tom Rini wrote:
>>> On Sun, Apr 01, 2018 at 09:22:34AM +, Alex Kiernan wrote:
>>>
 This converts CONFIG_DRIVER_TI_CPSW to Kconfig

 Signed-off-by: Alex Kiernan 
 Acked-by: Joe Hershberger 
>>>
>>> Applied to u-boot/master, thanks!
>>>
>> Why did you apply this patch? It introduces a build warning?
>>
> 
> Sorry, we probably want to revert this one, or try adding "depends on
> NET" to DRIVER_TI_CPSW in drivers/net/Kconfig; I'm stuck without a
> laptop until the end of the week so I've not been able to get back to
> fix this :(
> 
Please do _not_ add this dependency to "solve" the build problem I
reported. This would just blow up the U-Boot code for the PDU001 board.

As already stated: it is best to remove CONFIG_DRIVER_TI_CPSW=y from
configs/am335x_pdu001_defconfig leaving this file unchanged.

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

[U-Boot] [PATCH] x86: queensbay: switche P state to the highest freq

[Christian Gmeiner]

Fixes performance issue when running vx5/vx7 images.

Signed-off-by: Christian Gmeiner 
---
 arch/x86/cpu/queensbay/Makefile |  2 +-
 arch/x86/cpu/queensbay/cpu.c| 61 +
 2 files changed, 62 insertions(+), 1 deletion(-)
 create mode 100644 arch/x86/cpu/queensbay/cpu.c

diff --git a/arch/x86/cpu/queensbay/Makefile b/arch/x86/cpu/queensbay/Makefile
index c0681995bd..3dd23465d4 100644
--- a/arch/x86/cpu/queensbay/Makefile
+++ b/arch/x86/cpu/queensbay/Makefile
@@ -5,4 +5,4 @@
 #
 
 obj-y += fsp_configs.o irq.o
-obj-y += tnc.o
+obj-y += tnc.o cpu.o
diff --git a/arch/x86/cpu/queensbay/cpu.c b/arch/x86/cpu/queensbay/cpu.c
new file mode 100644
index 00..e98e4ac8ef
--- /dev/null
+++ b/arch/x86/cpu/queensbay/cpu.c
@@ -0,0 +1,61 @@
+/*
+ * Copyright (C) 2016, Bachmann electronic GmbH
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static void set_max_freq(void)
+{
+   msr_t msr;
+
+   msr = msr_read(MSR_IA32_MISC_ENABLES);
+   msr.lo |= (1 << 16);
+   msr_write(MSR_IA32_MISC_ENABLES, msr);
+
+   msr = msr_read(MSR_IA32_PERF_CTL);
+   msr.lo = 0x101f;
+   msr_write(MSR_IA32_PERF_CTL, msr);
+}
+
+static int cpu_x86_queensbay_probe(struct udevice *dev)
+{
+   if (!ll_boot_init())
+   return 0;
+   debug("Init Queensbay core\n");
+
+   /* Set core to max frequency ratio */
+   set_max_freq();
+
+   return 0;
+}
+
+static int queensbay_get_count(struct udevice *dev)
+{
+   return 2;
+}
+
+static const struct cpu_ops cpu_x86_queensbay_ops = {
+   .get_desc   = cpu_x86_get_desc,
+   .get_count  = queensbay_get_count,
+};
+
+static const struct udevice_id cpu_x86_queensbay_ids[] = {
+   { .compatible = "intel,queensbay-cpu" },
+   { }
+};
+
+U_BOOT_DRIVER(cpu_x86_queensbay_drv) = {
+   .name   = "cpu_x86_queensbay",
+   .id = UCLASS_CPU,
+   .of_match   = cpu_x86_queensbay_ids,
+   .bind   = cpu_x86_bind,
+   .probe  = cpu_x86_queensbay_probe,
+   .ops= _x86_queensbay_ops,
+};
-- 
2.14.3

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

Re: [U-Boot] [U-Boot, v2, 1/5] Migrate CONFIG_DRIVER_TI_CPSW to Kconfig

[Alex Kiernan]

On Tue, Apr 10, 2018 at 7:21 AM, Felix Brack  wrote:
> Hi Tom,
>
> On 09.04.2018 17:03, Tom Rini wrote:
>> On Sun, Apr 01, 2018 at 09:22:34AM +, Alex Kiernan wrote:
>>
>>> This converts CONFIG_DRIVER_TI_CPSW to Kconfig
>>>
>>> Signed-off-by: Alex Kiernan 
>>> Acked-by: Joe Hershberger 
>>
>> Applied to u-boot/master, thanks!
>>
> Why did you apply this patch? It introduces a build warning?
>

Sorry, we probably want to revert this one, or try adding "depends on
NET" to DRIVER_TI_CPSW in drivers/net/Kconfig; I'm stuck without a
laptop until the end of the week so I've not been able to get back to
fix this :(

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

Re: [U-Boot] [U-Boot, v2, 1/5] Migrate CONFIG_DRIVER_TI_CPSW to Kconfig

[Felix Brack]

Hi Tom,

On 09.04.2018 17:03, Tom Rini wrote:
> On Sun, Apr 01, 2018 at 09:22:34AM +, Alex Kiernan wrote:
> 
>> This converts CONFIG_DRIVER_TI_CPSW to Kconfig
>>
>> Signed-off-by: Alex Kiernan 
>> Acked-by: Joe Hershberger 
> 
> Applied to u-boot/master, thanks!
> 
Why did you apply this patch? It introduces a build warning?

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

Re: [U-Boot] [U-Boot, 36/36] rockchip: add common board file for rockchip platform

[Kever Yang]

Hi Tom,


On 04/09/2018 06:35 AM, Tom Rini wrote:
>> I have do a lot of test and re-work in my local branch and at last make
>> it landed in
>> rockchip vendor U-Boot, with testing in most of SoCs(not including
>> rk3066/rk3188).
>> Well, I do try to split it into pieces, but I found that actually not
>> help very much
>> except waste much more time:
>> - The target is(very clear) to make rockchip soc board file in a good
>> shape with common files,
>>     instead of copy-paste for each soc(more than 10 of them now)
>> - then we need to identify what's common and what should go to soc and
>> board;
>> - remove using common rockchip timer and use arm generic timer instead
>> for armv7
>>     SoCs(rk3066 and rk3188 need still using rockchip timer)
>> - most soc need to do uart init, boot order select, and some
>> arch_cpu_init().
>> - don't break the boards already working, so I still leave some code
>> which not so common
>>     in board file, but I would like to remove or move them into right
>> place if I got a board
>>     to verify;
>>
>> @Simon, @Tom,
>> This patch set is to remove some common files and add some other common
>> files for
>> all Rockchip SoCs, I have to make sure the whole patch set can running
>> good for all SoCs,
>> but it's really hard to make every patch to build and work perfect for
>> all SoCs, is there
>> any mandatory rules for this?
> So you mean possibly breaking some existing platforms?  I don't like the
> idea of doing that...

No, I'm not intent to to breaking some existing platforms,
this patch set including 36 patches, all the platform should work fine
after apply all these patches, but if only some of them applied,
there is compile error or running error because of feature missing.

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

Re: [U-Boot] [PATCH v2 0/7] Add support of SD3.0 UHS modes for ZynqMP

[Siva Durga Prasad Paladugu]

Hi Jaehoon,

I would like to send v3 for this series, Any specific branch that you want me 
to rebase the series?

Thanks,
DP

> -Original Message-
> From: Jaehoon Chung [mailto:jh80.ch...@samsung.com]
> Sent: Wednesday, January 17, 2018 8:04 AM
> To: Siva Durga Prasad Paladugu ; u-
> b...@lists.denx.de
> Subject: Re: [PATCH v2 0/7] Add support of SD3.0 UHS modes for ZynqMP
> 
> Hi Siva,
> 
> On 01/16/2018 07:10 PM, Siva Durga Prasad Paladugu wrote:
> > Hi Jaehoon,
> >
> > Any review comments on this.
> 
> Thanks for reminding. Will check! :)
> 
> Best Regards,
> Jaehoon Chung
> >
> > Thanks,
> > Siva
> >
> >> -Original Message-
> >> From: Siva Durga Prasad Paladugu
> >> [mailto:siva.durga.palad...@xilinx.com]
> >> Sent: Thursday, January 04, 2018 3:11 PM
> >> To: u-boot@lists.denx.de
> >> Cc: jh80.ch...@samsung.com; Siva Durga Prasad Paladugu
> >> 
> >> Subject: [PATCH v2 0/7] Add support of SD3.0 UHS modes for ZynqMP
> >>
> >> This patch series is meant to add SD3.0 support for ZynqMP platform.
> >> The first five patches in the series mostly setting up things in
> >> sdhci layer to support SD3.0 , the sixth patch is to add SD3.0
> >> support for ZynqMP platform and the last patch is to enable this
> >> support for ZynqMP zcu102
> >> rev1.0 eval board.
> >>
> >> Repo: u-boot-mmc.git
> >> Branch: hs200-working
> >>
> >> Siva Durga Prasad Paladugu (7):
> >>   mmc: sdhci: Add support for disabling clock
> >>   mmc: sdhci: Handle execute tuning command in sdhci_send_command
> >>   sdhci: Add new sdhci ops for platform specific tuning and delays
> >>   mmc: sdhci: Invoke platform specific tuning and delay routines
> >>   mmc : sdhci: Read capabilities register1 and update host caps
> >>   mmc: zynq_sdhci: Add support for SD3.0
> >>   zynqmp: zcu102: Enable UHS support for ZCU102 Rev1.0 board
> >>
> >>  board/xilinx/zynqmp/Makefile  |   2 +
> >>  board/xilinx/zynqmp/tap_delays.c  | 230
> >> ++
> >>  configs/xilinx_zynqmp_zcu102_rev1_0_defconfig |   2 +
> >>  drivers/mmc/sdhci.c   |  67 +++-
> >>  drivers/mmc/zynq_sdhci.c  | 230
> >> +-
> >>  include/sdhci.h   |   9 +
> >>  include/zynqmp_tap_delay.h|  20 +++
> >>  7 files changed, 550 insertions(+), 10 deletions(-)  create mode
> >> 100644 board/xilinx/zynqmp/tap_delays.c  create mode 100644
> >> include/zynqmp_tap_delay.h
> >>
> >> --
> >> 2.7.4
> >
> >
> >
> >

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