Re: [U-Boot] [PATCH v2 1/2] arm: add support for semihosting for ARMv7M targets

[Albert ARIBAUD]

Hello Vadzim,

On Mon, 19 Oct 2015 00:13:28 +0300, Vadzim Dambrouski
 wrote:
> It is possible to enable CONFIG_SEMIHOSTING for STM32F429 target, but it
> would result in compile error. This patch adds support for semihosting for
> STM32F429 or any other ARMv7M target. Tested on STM32F429-DISCOVERY board.

You should give some more indication of the reason for the compile
error and the nature of the fix. For instance, you could quote the
essential part of the error message (so that people googling for the
error message may find this commit and mail thread) and a very short
analysis (so that they can test if 'their' error is the same and can
be solved the same way).

> Signed-off-by: Vadzim Dambrouski 
> ---
> 
>  arch/arm/lib/semihosting.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/arm/lib/semihosting.c b/arch/arm/lib/semihosting.c
> index c3e964e..ed5e8e4 100644
> --- a/arch/arm/lib/semihosting.c
> +++ b/arch/arm/lib/semihosting.c
> @@ -31,6 +31,8 @@ static noinline long smh_trap(unsigned int sysnum, void 
> *addr)
>   register long result asm("r0");
>  #if defined(CONFIG_ARM64)
>   asm volatile ("hlt #0xf000" : "=r" (result) : "0"(sysnum), "r"(addr));
> +#elif defined(CONFIG_CPU_V7M)
> + asm volatile ("bkpt #0xAB" : "=r" (result) : "0"(sysnum), "r"(addr));
>  #else
>   /* Note - untested placeholder */
>   asm volatile ("svc #0x123456" : "=r" (result) : "0"(sysnum), "r"(addr));
> -- 
> 2.6.1
> 



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

[U-Boot] [PATCH] nios2: add README.nios2

[Thomas Chou]

Add README.nios2 about how to add nios2 boards to u-boot.

Signed-off-by: Thomas Chou 
---
 doc/README.nios2 | 86 
 1 file changed, 86 insertions(+)
 create mode 100644 doc/README.nios2

diff --git a/doc/README.nios2 b/doc/README.nios2
new file mode 100644
index 000..9f248ac
--- /dev/null
+++ b/doc/README.nios2
@@ -0,0 +1,86 @@
+Nios II is a 32-bit embedded-processor architecture designed 
+specifically for the Altera family of FPGAs. 
+
+Please refer to the link for more information on Nios II, 
+https://www.altera.com/products/processors/overview.html
+
+Please refer to the link for Linux port and toolchains,
+http://rocketboards.org/foswiki/view/Documentation/NiosIILinuxUserManual
+
+The Nios II port of u-boot is controlled by device tree. To add a new 
+board/configuration (eg, mysystem) to u-boot, you will need three files.
+
+1. The device tree source which descibe the hardware, dts file.
+arch/nios2/dts/mysystem.dts
+
+2. Default configuration of Kconfig, defconfig file.
+configs/mysystem_defconfig
+
+3. The legacy board header file.
+include/configs/mysystem.h
+
+The device tree source must be generated from your qsys/sopc design file 
+using the sopc2dts tool. Then modified to fit your configuration. Please 
+find the sopc2dts download and usage at the wiki,
+http://www.alterawiki.com/wiki/Sopc2dts
+
+java -jar sopc2dts.jar --force-altr -i mysystem.sopcinfo -o mysystem.dts
+
+You will need to add additional properties to the dts. Please find an 
+example at, arch/nios2/dts/3c120_devboard.dts.
+
+1. Add "u-boot,dm-pre-reloc" property to the cpu and the serial node 
+which you will use for console.
+
+2. Add "stdout-path=..." property with your serial path to the chosen 
+node.
+
+Next, you will need a default config file. You may start with 
+nios2-generic_defconfig, modify the options and save it.
+
+make nios2-generic_defconfig
+make menuconfig
+make savedefconfig
+cp defconfig configs/mysystem_defconfig
+
+You will need to change the names of board header file and device tree, 
+and select the drivers.
+
+Nios II architecture  --->
+  (mysystem) Board header file
+Device Tree Control  --->
+  (mysystem) Default Device Tree for DT control
+
+There is a selection of "Provider of DTB for DT control" in the Device 
+Tree Control menu.
+
+( ) Separate DTB for DT control, will cat the dtb to end of u-boot 
+binary, output u-boot-dtb.bin. This should be used for production.
+If you use boot copier, like epcs boot copier, make sure the copier 
+copies all the u-boot-dtb.bin, not just u-boot.bin.
+
+( ) Embedded DTB for DT control, will include the dtb inside the u-boot 
+binary. This is handy for development, eg, using gdb or nios2-download.
+
+The last thing, legacy board header file describes those config options 
+not covered in Kconfig yet. You may copy it from nios2-generic.h.
+
+cp include/configs/nios2-generic.h include/configs/mysystem.h
+
+Please change the sdram base and size to your board. The base should be 
+cached virtual address, for nios2 with mmu it is 0xCxxx- to 
+0xDxxx-.
+
+#define CONFIG_SYS_SDRAM_BASE  0xD000
+#define CONFIG_SYS_SDRAM_SIZE  0x0800
+
+You will need to change the environment variables location and setting, 
+too. You may change other configs to fit your board.
+
+After all these changes, you may build and test.
+
+export CROSS_COMPILE=nios2-elf-  (or nios2-linux-gnu-)
+make mysystem_defconfig
+make
+
+Enjoy!
-- 
2.1.4

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

Re: [U-Boot] [PATCH v2 2/2] arm: fix compile warnings when semihosting is enabled on ARMv7M target.

[Albert ARIBAUD]

Hello Vadzim,

On Mon, 19 Oct 2015 00:13:29 +0300, Vadzim Dambrouski
 wrote:
> Signed-off-by: Vadzim Dambrouski 
> ---
> 
>  arch/arm/lib/semihosting.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/lib/semihosting.c b/arch/arm/lib/semihosting.c
> index ed5e8e4..6541cb4 100644
> --- a/arch/arm/lib/semihosting.c
> +++ b/arch/arm/lib/semihosting.c
> @@ -92,7 +92,7 @@ static long smh_read(long fd, void *memp, size_t len)
>   size_t len;
>   } read;
>  
> - debug("%s: fd %ld, memp %p, len %lu\n", __func__, fd, memp, len);
> + debug("%s: fd %ld, memp %p, len %lu\n", __func__, fd, memp, (ulong)len);
>  
>   read.fd = fd;
>   read.memp = memp;
> @@ -107,7 +107,7 @@ static long smh_read(long fd, void *memp, size_t len)
>* with an error message.
>*/
>   printf("%s: ERROR ret %ld, fd %ld, len %lu memp %p\n",
> -__func__, ret, fd, len, memp);
> +__func__, ret, fd, (ulong)len, memp);
>   return -1;
>   }

len is a size_t; it should not be force-converted into a long, it
should be printed using a 'z' qualifier.

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

Re: [U-Boot] [PATCH] arm: add support for semihosting for ARMv7M targets

[Linus Walleij]

On Sun, Oct 18, 2015 at 11:45 AM, Vadzim Dambrouski  wrote:
> On 18.10.2015 12:20, Linus Walleij wrote:
>> Hey, cool. Technically the (ulong) typecasts should be another patch
>
> Sorry about that, this is my first time sending a patch.
>
>> Are you using this with the smload commands?
>
> Yes, I do use smhload command, and openocd on the other end.
> Useful for debugging targets without ethernet support.

That is *so* cool. You should make a blog post about this, I think
it's generally useful for developers to know they can use
U-Boot+JTAG+OpenOCD to get code into any platform (if they have
a scan chain definitions) like this.

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

Re: [U-Boot] [PATCH 1/3] ARM: relocate: fix hang when CONFIG_ARMV7_SECURE_BASE

[Peng Fan]

Hi Albert,
On Mon, Oct 19, 2015 at 08:48:56AM +0200, Albert ARIBAUD wrote:
>Hello Peng,
>
>On Mon, 19 Oct 2015 13:40:51 +0800, Peng Fan 
>wrote:
>> On Tue, Oct 06, 2015 at 05:13:24PM -0500, Frank Li wrote:
>> >When added above configuration, iram fix up plus relocate offset may locate
>> >in invalidate space. Write back fix up value will cause data abort.
>> >
>> >Add address check, skip psci code.
>> >
>> >Signed-off-by: Frank Li 
>> >---
>> > arch/arm/lib/relocate.S | 4 
>> > 1 file changed, 4 insertions(+)
>> >
>> >diff --git a/arch/arm/lib/relocate.S b/arch/arm/lib/relocate.S
>> >index 475d503..6795a1b 100644
>> >--- a/arch/arm/lib/relocate.S
>> >+++ b/arch/arm/lib/relocate.S
>> >@@ -99,6 +99,10 @@ fixloop:
>> >cmp r1, #23 /* relative fixup? */
>> >bne fixnext
>> > 
>> >+   ldr r1, =__image_copy_start
>> >+   cmp r0, r1
>> >+   blo fixnext
>> >+
>> 
>> Hi Tom, Albert,
>> 
>> This is a bug fix, please consider to apply this patch.
>
>Sorry for not spotting your patch earlier.

Not from me -:)

>
>Took me some time to understand the commit summary. Let me see if I'm
>getting this right by paraphrasing it:
>
>   If CONFIG_ARMV7_SECURE_BASE is defined and if there is
>   a fixup to the location at __image_copy_start, then U-Boot
>   will try to fix that location and since it is write-protected,
>   it will result in a data abort.

The commit msg needs to be refined.

>
>If I got this right, then this raises the following questions:
>
>1) if this location cannot be written into for relocation fixup, then
>how could it be written into for the copying which precedes relocation?
>
>2) if there is a fixup to the location, it means that either this
>location will not work properly without a fix, or the compiler emitted
>an erroneous relocation record. In either case, just ignoring the fixup
>seems like papering over the issue.
>
>Besides, this patch will prevent image base fixups on all targets, even
>those for which CONFIG_ARMV7_SECURE_BASE is not defined.

>From my understanding, U-Boot will be relocated to high address of the DRAM 
>space,
exactly code from __image_copy_start to __image_copy_end.

Following is part of the dump of .rel.dyn section of u-boot elf.
SECURE BASE is 0x18, uboot entry is 0x8780.

Relocation section '.rel.dyn' at offset 0x577d4 contains 4032 entries:
 Offset InfoTypeSym.Value  Sym. Name
 0018410c  0017 R_ARM_RELATIVE   
 00184154  0017 R_ARM_RELATIVE   
 0018415c  0017 R_ARM_RELATIVE   
 00184164  0017 R_ARM_RELATIVE   
 0018416c  0017 R_ARM_RELATIVE   
 00184304  0017 R_ARM_RELATIVE   
 00184368  0017 R_ARM_RELATIVE   
 87800020  0017 R_ARM_RELATIVE   
 87800024  0017 R_ARM_RELATIVE   
 87800028  0017 R_ARM_RELATIVE   
 8780002c  0017 R_ARM_RELATIVE

We can see that there are several relocate entries for secure code which is not
copied to high address of DRAM.

However SECURE code will not be copied to high address and should not be copied.
The code locates from __image_copy_start to __image_copy_end are copied to high
address, after copied, we need to fix variable and function reference, means
we need to fix this according to the relocation entry. The relocation entry
for SECURE code is not needed and should not to be fixed, alought they are in
the rel.dyn section.

>
>So, for now, I would NAK it.
>
>Now, assuming the answers to the two questions above do make a valid
>point that the fix above should indeed be implemented, then:
>
>> The secure code such as PSCI is not relocated, so there is no need to fix 
>> the code
>> which generate relocate entry in rel.dyn section. We should only need take
>> code from __image_copy_start to __image_copy_end into consideration.
>
>If some part of an image needs copying but not relocating,then the

part of an image not needs copying and not needs relocating.

>right solution is not to hard-code some arbitrary location as 'not
>relocatable' in the relocation routine; the right solution is to
>put in place a generic mechanism to allow the linker script to define
>which part of the image is relocatable. This can be done as follows:
>
>- in the linker script, border the non-relocatable part of the image
>  with two symbols, say 'relocatable_image_start' and '..._end', and
>  ensure that text (code) which should *not* be relocated is mapped
>  either before '..._start' or '..._end'. Not-to-be-relocated code
>  would be recognized by its text section name, e.g. '.nonreloc.text*'.

We have another fix is to add the following linker in u-boot.lds for arm
+   .rel.secure :
+   {
+   *(.rel._secure*)
+   }

Then relocation entry for secure code will not be touched.

But from my point, when doing relocation fix like the following c code:

if ((entry < __image_copy_end)  && (entry > __image_copy_start)) {
 /* fixup according relocation entry */
}

Re: [U-Boot] [ELCE2015] Question about schedule

[Bin Meng]

Hi Lukasz,

On Tue, Oct 13, 2015 at 7:17 PM, Lukasz Majewski  wrote:
> Hi Bin,
>
>> Hi,
>>
>> On Fri, Oct 2, 2015 at 6:34 AM, Tom Rini  wrote:
>> > On Thu, Oct 01, 2015 at 10:38:50AM +0200, Lukasz Majewski wrote:
>> >
>> >> Hi Tom,
>> >>
>> >> Is there any schedule for our ELCE2015 u-boot mini summit [1]?
>> >> To be more precise
>> >> - are know times when we will deliver our presentations?
>> >>
>> >>
>> >>
>> >> [1] - http://www.denx.de/wiki/U-Boot/SummitELCE2015
>> >
>> > So no, we don't have a formal schedule at this time.  My kind of
>> > plan at this point is to start off with the formal talks.  Then
>> > move into a "5 minute" status from the custodians present on where
>> > they're at in their area.  After that, sort out some priorities on
>> > Kconfig/DT.
>> >
>> > Oh, and I plan to try and have a Google Hangout up so that people
>> > that can't make it can at least watch and maybe chime in.
>> >
>> > --
>>
>> Are there any slides presented in the summit available somewhere? Or
>> any video clips?
>
> I'm going to upload my slides to the Mini-Summit webpage.
>

Thank you. But I don't see your slides on
http://www.denx.de/wiki/U-Boot/SummitELCE2015?

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

[U-Boot] (last minute) pull request: u-boot-arm/master

[Albert ARIBAUD]

Hello Tom,

A last-minute fix, maybe it can go in 2015.10 since this is a
single-target bugfix by the maintainer?

The following changes since commit ac6a53219a1bf5bd30b754d6d3f04f26e3921d15:

  Merge git://git.denx.de/u-boot-socfpga (2015-10-16 20:21:04 -0400)

are available in the git repository at:

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

for you to fetch changes up to d1a2f32fca16ce0ec01b3447cc4755a17aca7f0f:

  ARM: dockstar: move start of environment area (2015-10-19 07:28:54 +0200)


Eric Cooper (1):
  ARM: dockstar: move start of environment area

 include/configs/dockstar.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

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

Re: [U-Boot] [PATCH 11/20] dm: serial: Update binding for PL01x serial UART

[Linus Walleij]

On Thu, Jul 16, 2015 at 9:41 AM, Geert Uytterhoeven
 wrote:

>> Ah right. I don't think that naming is super critical though, as a lot
>> of properties in the DT just describe how things are at boot time.
>
> Hence those don't describe the hardware...
> Shouldn't they be in /chosen instead?

/chosen is used for system-wide things mostly, as alias.

I think this can go in the hardware node.

Simon can you please make a patch to
Documentation/devicetree/bindings/serial/pl011.txt in the kernel
and post to devicet...@vger.kernel.org *and*
linux-...@vger.kernel.org and Jonathan Corbet 
so he can merge it if we get some ACKs on it.

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

[U-Boot] (CORRECTED last minute) pull request: u-boot-arm/master

[Albert ARIBAUD]

On Mon, 19 Oct 2015 08:11:25 +0200, Albert ARIBAUD
 wrote:
> Hello Tom,
> 
> A last-minute fix, maybe it can go in 2015.10 since this is a
> single-target bugfix by the maintainer?

Actually, two bug-fixes:

The following changes since commit ac6a53219a1bf5bd30b754d6d3f04f26e3921d15:

  Merge git://git.denx.de/u-boot-socfpga (2015-10-16 20:21:04 -0400)

are available in the git repository at:

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

for you to fetch changes up to 79ad5cef151fff32432a31ce7fe92e170d8a95ae:

  ARM: rpi: add another revision of Raspberry Pi A+ (2015-10-19 08:12:25 +0200)


Eric Cooper (1):
  ARM: dockstar: move start of environment area

Lubomir Rintel (1):
  ARM: rpi: add another revision of Raspberry Pi A+

 arch/arm/mach-bcm283x/include/mach/mbox.h | 1 +
 board/raspberrypi/rpi/rpi.c   | 5 +
 include/configs/dockstar.h| 4 ++--
 3 files changed, 8 insertions(+), 2 deletions(-)

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

Re: [U-Boot] [PATCH 1/3] ARM: relocate: fix hang when CONFIG_ARMV7_SECURE_BASE

[Albert ARIBAUD]

Hello Peng,

On Mon, 19 Oct 2015 13:40:51 +0800, Peng Fan 
wrote:
> On Tue, Oct 06, 2015 at 05:13:24PM -0500, Frank Li wrote:
> >When added above configuration, iram fix up plus relocate offset may locate
> >in invalidate space. Write back fix up value will cause data abort.
> >
> >Add address check, skip psci code.
> >
> >Signed-off-by: Frank Li 
> >---
> > arch/arm/lib/relocate.S | 4 
> > 1 file changed, 4 insertions(+)
> >
> >diff --git a/arch/arm/lib/relocate.S b/arch/arm/lib/relocate.S
> >index 475d503..6795a1b 100644
> >--- a/arch/arm/lib/relocate.S
> >+++ b/arch/arm/lib/relocate.S
> >@@ -99,6 +99,10 @@ fixloop:
> > cmp r1, #23 /* relative fixup? */
> > bne fixnext
> > 
> >+ldr r1, =__image_copy_start
> >+cmp r0, r1
> >+blo fixnext
> >+
> 
> Hi Tom, Albert,
> 
> This is a bug fix, please consider to apply this patch.

Sorry for not spotting your patch earlier.

Took me some time to understand the commit summary. Let me see if I'm
getting this right by paraphrasing it:

If CONFIG_ARMV7_SECURE_BASE is defined and if there is
a fixup to the location at __image_copy_start, then U-Boot
will try to fix that location and since it is write-protected,
it will result in a data abort.

If I got this right, then this raises the following questions:

1) if this location cannot be written into for relocation fixup, then
how could it be written into for the copying which precedes relocation?

2) if there is a fixup to the location, it means that either this
location will not work properly without a fix, or the compiler emitted
an erroneous relocation record. In either case, just ignoring the fixup
seems like papering over the issue.

Besides, this patch will prevent image base fixups on all targets, even
those for which CONFIG_ARMV7_SECURE_BASE is not defined.

So, for now, I would NAK it.

Now, assuming the answers to the two questions above do make a valid
point that the fix above should indeed be implemented, then:

> The secure code such as PSCI is not relocated, so there is no need to fix the 
> code
> which generate relocate entry in rel.dyn section. We should only need take
> code from __image_copy_start to __image_copy_end into consideration.

If some part of an image needs copying but not relocating, then the
right solution is not to hard-code some arbitrary location as 'not
relocatable' in the relocation routine; the right solution is to
put in place a generic mechanism to allow the linker script to define
which part of the image is relocatable. This can be done as follows:

- in the linker script, border the non-relocatable part of the image
  with two symbols, say 'relocatable_image_start' and '..._end', and
  ensure that text (code) which should *not* be relocated is mapped
  either before '..._start' or '..._end'. Not-to-be-relocated code
  would be recognized by its text section name, e.g. '.nonreloc.text*'.

- in the relocation routine, only fix up those locations which lie
  between the 'relocatable_image_start' and '..._end' symbols.

- in the relevant makefile(s), make the non-relocatable object files
  use a test section name of the for defined in the first step (e.g.
  '.nonreloc.text*').

Again, this is suggested *only* if it is shown that the data abort
cannot be avoided some other way.

> Regards,
> Peng.

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

Re: [U-Boot] [PATCH v7 5/9] arm: serial: Add ability to use pre-initialized UARTs

[Linus Walleij]

On Sat, Oct 17, 2015 at 12:27 AM, Simon Glass  wrote:
> On 16 October 2015 at 15:23, Linus Walleij  wrote:

>> Again: get this merged in the Linux kernel FIRST. Is it?
>
> We had a little bit of a chat about this at ELCE. It would be great to
> get these changes merged with the kernel but the amount of
> push-back/energy it requires is still excessive IMO. Any thoughts?

I'm sorry but DT is standardization, and while I know how stinky it is to
be first somewhere and having to pave the road for everyone else,
in the long run it's worth it. I think when we switched the entire kernel
to DT it was to get "more order", and this is the cost that comes with
that order: more review.

I will go in and answer the comment on the DT mailing list so there is
some push atleast.

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

Re: [U-Boot] [PATCH] dfu: dfu_sf: Use the erase sector size for erase operations

[Lukasz Majewski]

Hi Fabio,

> Hi Lukasz,
> 
> On Tue, Sep 22, 2015 at 4:46 AM, Lukasz Majewski
>  wrote:
> > Hi Fabio,
> >
> >> From: Fabio Estevam 
> >>
> >> SPI NOR flashes need to erase the entire sector size and we cannot
> >> pass any arbitrary length for the erase operation.
> >>
> >> To illustrate the problem:
> >>
> >> Copying data from PC to DFU device
> >> Download[=] 100%   478208 bytes
> >> Download done.
> >> state(7) = dfuMANIFEST, status(0) = No error condition is present
> >> state(10) = dfuERROR, status(14) = Something went wrong, but the
> >> device does not know what it was
> >> Done!
> >>
> >> In this case, the binary has 478208 bytes and the M25P32 SPI NOR
> >> has an erase sector of 64kB.
> >>
> >> 478208  = 7 entire sectors of 64kiB + 19456 bytes.
> >>
> >> Erasing the first seven 64 kB sectors works fine, but when trying
> >> to erase the remainding 19456 causes problem and the board hangs.
> >>
> >> Fix the issue by always erasing with the erase sector size.
> >>
> >> Signed-off-by: Fabio Estevam 
> 
> > Acked-by: Lukasz Majewski 
> >
> > Applied to u-boot-dfu tree.
> >
> > Thanks for your work.
> >
> > I'm looking forward for more patches :-)
> 
> Any chance of getting this one applied for 2015.10?

Probably not :-( since we have now -rc5.

I plan to send pull request in the next merge window.

My apologies, since I was busy with ELCE2015 preparation, so I've
forgotten to send early PR to Marek.


-- 
Best regards,

Lukasz Majewski

Samsung R Institute Poland (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 00/14] Implement fastboot over NAND and sparse transfers

[Maxime Ripard]

On Sat, Oct 17, 2015 at 04:42:09PM +0200, Hans de Goede wrote:
> Hi,
> 
> On 17-10-15 15:59, Hans de Goede wrote:
> >Hi,
> >
> >On 15-10-15 14:34, Maxime Ripard wrote:
> >>Hi everyone,
> >>
> >>Here is the second attempt at getting fastboot flashing functions
> >>working on top of a NAND, for arbitraly large images.
> >>
> >>While the NAND support itself was quite easy to do, the support for
> >>the Android sparse images was quite difficult to add, and ended up
> >>being a quite huge refactoring of the sparse parse already in tree,
> >>that was tied to the MMC layer.
> >>
> >>This serie has been tested on a CHIP and an A13-Olinuxino, two
> >>Allwinner devices, the CHIP for the NAND, and the Cubietruck to test
> >>the MMC.
> >>
> >>Let me know what you think,
> >>Maxime
> >
> >Thanks, I've applied the 3 sunxi patches (12 - 14) to u-boot-sunxi/next,
> >with the commit msg fixup suggested by Ian.
> 
> Looks like I've spoken too soon, the patch for enabling otg on the cubietruck
> causes build errors:
> 
> arm-linux-gnu-ld.bfd: error: 
> /usr/lib/gcc/arm-linux-gnueabi/5.2.1/libgcc.a(_udivmoddi4.o) uses VFP 
> register arguments, u-boot does not
> arm-linux-gnu-ld.bfd: failed to merge target specific data of file 
> /usr/lib/gcc/arm-linux-gnueabi/5.2.1/libgcc.a(_udivmoddi4.o)
> Makefile:1173: recipe for target 'u-boot' failed
> make: *** [u-boot] Error 1
> 
> Usually this means that some code is using 64 bit int division
> without using the proper macros for this.
> 
> For some reason I'm not seeing the same on the A13-OlinuxIno, that patch
> for that seems to be missing the id pin, which could have something to do
> with this.
> 
> I think this is caused by some 64 bit math in the fastboot code somewhere ...
> 
> For now I've dropped these 2 patches from u-boot-sunxi/next

Which 2 patches then? Cubietruck and this one?

Do you have a toolchain tarball for this so that I can test easily?

Thanks!
Maxime

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


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

Re: [U-Boot] [PATCH v8 1/3] dm: implement a Timer uclass

[Thomas Chou]

Hi Simon,

On 10/19/2015 09:53 AM, Simon Glass wrote:

Please do create a test for this uclass using a fake sandbox timer.
Note also time_ut.c which might have some ideas.


I am learning sandbox and working on a sandbox timer now.

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

Re: [U-Boot] [PATCH] dfu: dfu_sf: Use the erase sector size for erase operations

[Otavio Salvador]

On Mon, Oct 19, 2015 at 6:07 AM, Lukasz Majewski  wrote:
>> On Tue, Sep 22, 2015 at 4:46 AM, Lukasz Majewski
>>  wrote:
>> >> From: Fabio Estevam 
>> >>
>> >> SPI NOR flashes need to erase the entire sector size and we cannot
>> >> pass any arbitrary length for the erase operation.
>> >>
>> >> To illustrate the problem:
>> >>
>> >> Copying data from PC to DFU device
>> >> Download[=] 100%   478208 bytes
>> >> Download done.
>> >> state(7) = dfuMANIFEST, status(0) = No error condition is present
>> >> state(10) = dfuERROR, status(14) = Something went wrong, but the
>> >> device does not know what it was
>> >> Done!
>> >>
>> >> In this case, the binary has 478208 bytes and the M25P32 SPI NOR
>> >> has an erase sector of 64kB.
>> >>
>> >> 478208  = 7 entire sectors of 64kiB + 19456 bytes.
>> >>
>> >> Erasing the first seven 64 kB sectors works fine, but when trying
>> >> to erase the remainding 19456 causes problem and the board hangs.
>> >>
>> >> Fix the issue by always erasing with the erase sector size.
>> >>
>> >> Signed-off-by: Fabio Estevam 
>>
>> > Acked-by: Lukasz Majewski 
>> >
>> > Applied to u-boot-dfu tree.
>> >
>> > Thanks for your work.
>> >
>> > I'm looking forward for more patches :-)
>>
>> Any chance of getting this one applied for 2015.10?
>
> Probably not :-( since we have now -rc5.
>
> I plan to send pull request in the next merge window.
>
> My apologies, since I was busy with ELCE2015 preparation, so I've
> forgotten to send early PR to Marek.

This has been acked in September and it is a very trivial change, why
not include it?

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

Re: [U-Boot] [PATCH] dfu: dfu_sf: Use the erase sector size for erase operations

[Lukasz Majewski]

Hi Otavio,

> On Mon, Oct 19, 2015 at 6:07 AM, Lukasz Majewski
>  wrote:
> >> On Tue, Sep 22, 2015 at 4:46 AM, Lukasz Majewski
> >>  wrote:
> >> >> From: Fabio Estevam 
> >> >>
> >> >> SPI NOR flashes need to erase the entire sector size and we
> >> >> cannot pass any arbitrary length for the erase operation.
> >> >>
> >> >> To illustrate the problem:
> >> >>
> >> >> Copying data from PC to DFU device
> >> >> Download[=] 100%   478208 bytes
> >> >> Download done.
> >> >> state(7) = dfuMANIFEST, status(0) = No error condition is
> >> >> present state(10) = dfuERROR, status(14) = Something went
> >> >> wrong, but the device does not know what it was
> >> >> Done!
> >> >>
> >> >> In this case, the binary has 478208 bytes and the M25P32 SPI NOR
> >> >> has an erase sector of 64kB.
> >> >>
> >> >> 478208  = 7 entire sectors of 64kiB + 19456 bytes.
> >> >>
> >> >> Erasing the first seven 64 kB sectors works fine, but when
> >> >> trying to erase the remainding 19456 causes problem and the
> >> >> board hangs.
> >> >>
> >> >> Fix the issue by always erasing with the erase sector size.
> >> >>
> >> >> Signed-off-by: Fabio Estevam 
> >>
> >> > Acked-by: Lukasz Majewski 
> >> >
> >> > Applied to u-boot-dfu tree.
> >> >
> >> > Thanks for your work.
> >> >
> >> > I'm looking forward for more patches :-)
> >>
> >> Any chance of getting this one applied for 2015.10?
> >
> > Probably not :-( since we have now -rc5.
> >
> > I plan to send pull request in the next merge window.
> >
> > My apologies, since I was busy with ELCE2015 preparation, so I've
> > forgotten to send early PR to Marek.
> 
> This has been acked in September and it is a very trivial change, why
> not include it?
> 

I'm discussing it now with Tom. I hope that he would take those two
patches.


-- 
Best regards,

Lukasz Majewski

Samsung R Institute Poland (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v3 2/2] vexpress64: Juno: Add initialisation code for Juno R1 PCIe host bridge.

[Liviu Dudau]

Juno R1 has an XpressRICH3 PCIe host bridge that needs to be initialised
in order for the Linux kernel to be able to enumerate the bus. Add
support code here that enables the host bridge, trains the links and
sets up the Address Translation Tables.

Signed-off-by: Liviu Dudau 
Tested-by: Ryan Harkin 
---
 board/armltd/vexpress64/Makefile |   2 +-
 board/armltd/vexpress64/pcie.c   | 197 +++
 board/armltd/vexpress64/pcie.h   |  12 +++
 board/armltd/vexpress64/vexpress64.c |   2 +
 4 files changed, 212 insertions(+), 1 deletion(-)
 create mode 100644 board/armltd/vexpress64/pcie.c
 create mode 100644 board/armltd/vexpress64/pcie.h

diff --git a/board/armltd/vexpress64/Makefile b/board/armltd/vexpress64/Makefile
index e009141..a35db40 100644
--- a/board/armltd/vexpress64/Makefile
+++ b/board/armltd/vexpress64/Makefile
@@ -5,4 +5,4 @@
 # SPDX-License-Identifier: GPL-2.0+
 #
 
-obj-y  := vexpress64.o
+obj-y  := vexpress64.o pcie.o
diff --git a/board/armltd/vexpress64/pcie.c b/board/armltd/vexpress64/pcie.c
new file mode 100644
index 000..7b999e8
--- /dev/null
+++ b/board/armltd/vexpress64/pcie.c
@@ -0,0 +1,197 @@
+/*
+ * Copyright (C) ARM Ltd 2015
+ *
+ * Author: Liviu Dudau 
+ *
+ * SPDX-Licence-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include "pcie.h"
+
+/* XpressRICH3 support */
+#define XR3_CONFIG_BASE0x7ff3
+#define XR3_RESET_BASE 0x7ff2
+
+#define XR3_PCI_ECAM_START 0x4000
+#define XR3_PCI_ECAM_SIZE  28  /* as power of 2 = 0x1000 */
+#define XR3_PCI_IOSPACE_START  0x5f80
+#define XR3_PCI_IOSPACE_SIZE   23  /* as power of 2 = 0x80 */
+#define XR3_PCI_MEMSPACE_START 0x5000
+#define XR3_PCI_MEMSPACE_SIZE  27  /* as power of 2 = 0x800 */
+#define XR3_PCI_MEMSPACE64_START   0x40
+#define XR3_PCI_MEMSPACE64_SIZE33  /* as power of 2 = 
0x2 */
+
+#define JUNO_V2M_MSI_START 0x2c1c
+#define JUNO_V2M_MSI_SIZE  12  /* as power of 2 = 4096 */
+
+#define XR3PCI_BASIC_STATUS0x18
+#define XR3PCI_BS_GEN_MASK (0xf << 8)
+#define XR3PCI_BS_LINK_MASK0xff
+
+#define XR3PCI_VIRTCHAN_CREDITS0x90
+#define XR3PCI_BRIDGE_PCI_IDS  0x9c
+#define XR3PCI_PEX_SPC20xd8
+
+#define XR3PCI_ATR_PCIE_WIN0   0x600
+#define XR3PCI_ATR_PCIE_WIN1   0x700
+#define XR3PCI_ATR_AXI4_SLV0   0x800
+
+#define XR3PCI_ATR_TABLE_SIZE  0x20
+#define XR3PCI_ATR_SRC_ADDR_LOW0x0
+#define XR3PCI_ATR_SRC_ADDR_HIGH   0x4
+#define XR3PCI_ATR_TRSL_ADDR_LOW   0x8
+#define XR3PCI_ATR_TRSL_ADDR_HIGH  0xc
+#define XR3PCI_ATR_TRSL_PARAM  0x10
+
+/* IDs used in the XR3PCI_ATR_TRSL_PARAM */
+#define XR3PCI_ATR_TRSLID_AXIDEVICE(0x420004)
+#define XR3PCI_ATR_TRSLID_AXIMEMORY(0x4e0004)  /* Write-through, 
read/write allocate */
+#define XR3PCI_ATR_TRSLID_PCIE_CONF(0x01)
+#define XR3PCI_ATR_TRSLID_PCIE_IO  (0x02)
+#define XR3PCI_ATR_TRSLID_PCIE_MEMORY  (0x00)
+
+#define XR3PCI_ECAM_OFFSET(b, d, o)(((b) << 20) | \
+   (PCI_SLOT(d) << 15) | \
+   (PCI_FUNC(d) << 12) | o)
+
+#define JUNO_RESET_CTRL0x1004
+#define JUNO_RESET_CTRL_PHYBIT(0)
+#define JUNO_RESET_CTRL_RC BIT(1)
+
+#define JUNO_RESET_STATUS  0x1008
+#define JUNO_RESET_STATUS_PLL  BIT(0)
+#define JUNO_RESET_STATUS_PHY  BIT(1)
+#define JUNO_RESET_STATUS_RC   BIT(2)
+#define JUNO_RESET_STATUS_MASK (JUNO_RESET_STATUS_PLL | \
+JUNO_RESET_STATUS_PHY | \
+JUNO_RESET_STATUS_RC)
+
+void xr3pci_set_atr_entry(unsigned long base, unsigned long src_addr,
+   unsigned long trsl_addr, int window_size,
+   int trsl_param)
+{
+   /* X3PCI_ATR_SRC_ADDR_LOW:
+- bit 0: enable entry,
+- bits 1-6: ATR window size: total size in bytes: 2^(ATR_WSIZE + 1)
+- bits 7-11: reserved
+- bits 12-31: start of source address
+   */
+   writel((u32)(src_addr & 0xf000) | (window_size - 1) << 1 | 1,
+  base + XR3PCI_ATR_SRC_ADDR_LOW);
+   writel((u32)(src_addr >> 32), base + XR3PCI_ATR_SRC_ADDR_HIGH);
+   writel((u32)(trsl_addr & 0xf000), base + XR3PCI_ATR_TRSL_ADDR_LOW);
+   writel((u32)(trsl_addr >> 32), base + XR3PCI_ATR_TRSL_ADDR_HIGH);
+   writel(trsl_param, base + XR3PCI_ATR_TRSL_PARAM);
+
+   printf("ATR entry: 0x%010lx %s 0x%010lx [0x%010llx] (param: 0x%06x)\n",
+  src_addr, (trsl_param & 0x40) ? "<-" : "->", 

[U-Boot] [PATCH v3 1/2] vexpress64: Juno: Declare all 8GB of RAM and make them visible to the kernel.

[Liviu Dudau]

Juno comes with 8GB RAM, but U-Boot only passes 2GB to the kernel.
Declare a secondary memory bank and set the sizes correctly.

Signed-off-by: Liviu Dudau 
Reviewed-by: Linus Walleij 
Reviewed-by: Ryan Harkin 
Tested-by: Ryan Harkin 
---
 board/armltd/vexpress64/vexpress64.c | 8 
 include/configs/vexpress_aemv8a.h| 4 +++-
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/board/armltd/vexpress64/vexpress64.c 
b/board/armltd/vexpress64/vexpress64.c
index 7cb4e00..6df9d60 100644
--- a/board/armltd/vexpress64/vexpress64.c
+++ b/board/armltd/vexpress64/vexpress64.c
@@ -38,6 +38,14 @@ int dram_init(void)
return 0;
 }
 
+void dram_init_banksize(void)
+{
+   gd->bd->bi_dram[0].start = PHYS_SDRAM_1;
+   gd->bd->bi_dram[0].size = PHYS_SDRAM_1_SIZE;
+   gd->bd->bi_dram[1].start = PHYS_SDRAM_2;
+   gd->bd->bi_dram[1].size = PHYS_SDRAM_2_SIZE;
+}
+
 /*
  * Board specific reset that is system reset.
  */
diff --git a/include/configs/vexpress_aemv8a.h 
b/include/configs/vexpress_aemv8a.h
index ef3014d..0f2f1a3 100644
--- a/include/configs/vexpress_aemv8a.h
+++ b/include/configs/vexpress_aemv8a.h
@@ -168,11 +168,13 @@
 #define CONFIG_SYS_LOAD_ADDR   (V2M_BASE + 0x1000)
 
 /* Physical Memory Map */
-#define CONFIG_NR_DRAM_BANKS   1
+#define CONFIG_NR_DRAM_BANKS   2
 #define PHYS_SDRAM_1   (V2M_BASE)  /* SDRAM Bank #1 */
+#define PHYS_SDRAM_2   (0x88000)
 /* Top 16MB reserved for secure world use */
 #define DRAM_SEC_SIZE  0x0100
 #define PHYS_SDRAM_1_SIZE  0x8000 - DRAM_SEC_SIZE
+#define PHYS_SDRAM_2_SIZE  0x18000
 #define CONFIG_SYS_SDRAM_BASE  PHYS_SDRAM_1
 
 /* Enable memtest */
-- 
2.6.0

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

[U-Boot] [PATCH v3 0/2] vexpress64: Juno: Add support for PCIe on Juno

[Liviu Dudau]

Hello,

This patchset enables PCIe for ARM's Juno boards and configures the
host bridge's address translation block. This enables the Linux kernel
to boot on Juno r1 using just a device tree and the generic host bridge
driver.

No support has been added at this phase for the SATA or Ethernet devices
present on the PCIe bus.

Changelog:
 - v3: Fix the error reported by Ryan Harkin on setting the virtual channel
   credits.
 - v3: fixed the check_patch.pl warnings on blank lines and use BIT() macro
 - v3: change from udelay() to mdelay()
 - v3: spelling fixes
 - v2: Split XpressRICH3 code into pcie.c file and introduce 
vexpress64_pcie_init()
   that can be called from board_init(). Suggested by Linus Walleij.
 - v2: Set up the XpressRICH3 bridge class code to a valid value to correct the
   incorrect reset value.
 - v1: Original submission 
http://lists.denx.de/pipermail/u-boot/2015-October/229669.html

Liviu Dudau (2):
  vexpress64: Juno: Declare all 8GB of RAM and make them visible to the kernel.
  vexpress64: Juno: Add initialisation code for Juno R1 PCIe host bridge.

 board/armltd/vexpress64/Makefile |   2 +-
 board/armltd/vexpress64/pcie.c   | 197 +++
 board/armltd/vexpress64/pcie.h   |  12 +++
 board/armltd/vexpress64/vexpress64.c |  10 ++
 include/configs/vexpress_aemv8a.h|   4 +-
 5 files changed, 223 insertions(+), 2 deletions(-)
 create mode 100644 board/armltd/vexpress64/pcie.c
 create mode 100644 board/armltd/vexpress64/pcie.h

-- 
2.6.0

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

[U-Boot] [Patch V6 06/18] net/fm: Make the return value logic consistent with convention

[Gong Qianyu]

From: Hou Zhiqiang 

In convention, the '0' is a normal return value indicating there isn't
an error. While some functions of FMan IM driver treat '0' as an error
return value.

Signed-off-by: Hou Zhiqiang 
Signed-off-by: Gong Qianyu 
---
V6:
 - No change.
V5:
 - No change.
V4:
 - No change.
V3:
 - New patch.

 drivers/net/fm/eth.c | 60 +++-
 1 file changed, 36 insertions(+), 24 deletions(-)

diff --git a/drivers/net/fm/eth.c b/drivers/net/fm/eth.c
index 6451dce..d7d064b 100644
--- a/drivers/net/fm/eth.c
+++ b/drivers/net/fm/eth.c
@@ -211,7 +211,7 @@ static int fm_eth_rx_port_parameter_init(struct fm_eth 
*fm_eth)
FM_PRAM_SIZE, FM_PRAM_ALIGN);
if (!pram) {
printf("%s: No muram for Rx global parameter\n", __func__);
-   return 0;
+   return -ENOMEM;
}
 
fm_eth->rx_pram = pram;
@@ -232,14 +232,16 @@ static int fm_eth_rx_port_parameter_init(struct fm_eth 
*fm_eth)
rx_bd_ring_base = malloc(sizeof(struct fm_port_bd)
* RX_BD_RING_SIZE);
if (!rx_bd_ring_base)
-   return 0;
+   return -ENOMEM;
+
memset(rx_bd_ring_base, 0, sizeof(struct fm_port_bd)
* RX_BD_RING_SIZE);
 
/* alloc Rx buffer from main memory */
rx_buf_pool = malloc(MAX_RXBUF_LEN * RX_BD_RING_SIZE);
if (!rx_buf_pool)
-   return 0;
+   return -ENOMEM;
+
memset(rx_buf_pool, 0, MAX_RXBUF_LEN * RX_BD_RING_SIZE);
debug("%s: rx_buf_pool = %p\n", __func__, rx_buf_pool);
 
@@ -277,7 +279,7 @@ static int fm_eth_rx_port_parameter_init(struct fm_eth 
*fm_eth)
/* set IM parameter ram pointer to Rx Frame Queue ID */
out_be32(_rx_port->fmbm_rfqid, pram_page_offset);
 
-   return 1;
+   return 0;
 }
 
 static int fm_eth_tx_port_parameter_init(struct fm_eth *fm_eth)
@@ -296,7 +298,7 @@ static int fm_eth_tx_port_parameter_init(struct fm_eth 
*fm_eth)
FM_PRAM_SIZE, FM_PRAM_ALIGN);
if (!pram) {
printf("%s: No muram for Tx global parameter\n", __func__);
-   return 0;
+   return -ENOMEM;
}
fm_eth->tx_pram = pram;
 
@@ -313,7 +315,8 @@ static int fm_eth_tx_port_parameter_init(struct fm_eth 
*fm_eth)
tx_bd_ring_base = malloc(sizeof(struct fm_port_bd)
* TX_BD_RING_SIZE);
if (!tx_bd_ring_base)
-   return 0;
+   return -ENOMEM;
+
memset(tx_bd_ring_base, 0, sizeof(struct fm_port_bd)
* TX_BD_RING_SIZE);
/* save it to fm_eth */
@@ -344,29 +347,35 @@ static int fm_eth_tx_port_parameter_init(struct fm_eth 
*fm_eth)
/* set IM parameter ram pointer to Tx Confirmation Frame Queue ID */
out_be32(_tx_port->fmbm_tcfqid, pram_page_offset);
 
-   return 1;
+   return 0;
 }
 
 static int fm_eth_init(struct fm_eth *fm_eth)
 {
+   int ret;
 
-   if (!fm_eth_rx_port_parameter_init(fm_eth))
-   return 0;
+   ret = fm_eth_rx_port_parameter_init(fm_eth);
+   if (ret)
+   return ret;
 
-   if (!fm_eth_tx_port_parameter_init(fm_eth))
-   return 0;
+   ret = fm_eth_tx_port_parameter_init(fm_eth);
+   if (ret)
+   return ret;
 
-   return 1;
+   return 0;
 }
 
 static int fm_eth_startup(struct fm_eth *fm_eth)
 {
struct fsl_enet_mac *mac;
+   int ret;
+
mac = fm_eth->mac;
 
/* Rx/TxBDs, Rx/TxQDs, Rx buff and parameter ram init */
-   if (!fm_eth_init(fm_eth))
-   return 0;
+   ret = fm_eth_init(fm_eth);
+   if (ret)
+   return ret;
/* setup the MAC controller */
mac->init_mac(mac);
 
@@ -381,7 +390,7 @@ static int fm_eth_startup(struct fm_eth *fm_eth)
/* init bmi tx port, IM mode and disable */
bmi_tx_port_init(fm_eth->tx_port);
 
-   return 1;
+   return 0;
 }
 
 static void fmc_tx_port_graceful_stop_enable(struct fm_eth *fm_eth)
@@ -628,7 +637,7 @@ static int fm_eth_init_mac(struct fm_eth *fm_eth, struct 
ccsr_fman *reg)
/* alloc mac controller */
mac = malloc(sizeof(struct fsl_enet_mac));
if (!mac)
-   return 0;
+   return -ENOMEM;
memset(mac, 0, sizeof(struct fsl_enet_mac));
 
/* save the mac to fm_eth struct */
@@ -643,7 +652,7 @@ static int fm_eth_init_mac(struct fm_eth *fm_eth, struct 
ccsr_fman *reg)
init_tgec(mac, base, phyregs, MAX_RXBUF_LEN);
 #endif
 
-   return 1;
+   return 0;
 }
 
 static int init_phy(struct eth_device *dev)
@@ -696,17 +705,18 @@ int fm_eth_initialize(struct ccsr_fman *reg, struct 
fm_eth_info *info)
struct eth_device *dev;
struct fm_eth *fm_eth;
int i, num = info->num;
+   int ret;
 
   

[U-Boot] [Patch V6 14/18] armv8/ls1043ardb: Add nand boot support

[Gong Qianyu]

From: Gong Qianyu 

Signed-off-by: Gong Qianyu 
Signed-off-by: Hou Zhiqiang 
Signed-off-by: Shaohui Xie 
Signed-off-by: Mingkai Hu 
---
V6:
 - No change.
V5:
 - No change.
V4:
 - Add enable_layerscape_ns_access() in fsl-layerscape/spl.c
V3:
 - No change.
V2:
 - Removed unecessary NAND_PAGE_SIZE in ls1043a_common.h.
 - Fixed "select SUPPORT_SPL" in arch/arm/Kconfig.
 - Used CONFIG_FSL_IFC instead of SPL_NAND_SUPPORT for init_early_memctl_regs()
 - Replaced ns_access.h with fsl_csu.h

 arch/arm/Kconfig   |  1 +
 arch/arm/cpu/armv8/fsl-layerscape/spl.c|  3 ++
 board/freescale/ls1043ardb/README  |  1 +
 board/freescale/ls1043ardb/cpld.c  | 19 +
 board/freescale/ls1043ardb/cpld.h  |  1 +
 board/freescale/ls1043ardb/ls1043ardb_pbi.cfg  | 14 +++
 board/freescale/ls1043ardb/ls1043ardb_rcw_nand.cfg |  7 
 configs/ls1043ardb_nand_defconfig  |  4 ++
 include/configs/ls1043a_common.h   | 27 +
 include/configs/ls1043ardb.h   | 46 ++
 10 files changed, 123 insertions(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index bd99bfb..6584e85 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -634,6 +634,7 @@ config TARGET_LS1021ATWR
 config TARGET_LS1043ARDB
bool "Support ls1043ardb"
select ARM64
+   select SUPPORT_SPL
help
  Support for Freescale LS1043ARDB platform.
 
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/spl.c 
b/arch/arm/cpu/armv8/fsl-layerscape/spl.c
index 2f30d4b..ba551aa 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/spl.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/spl.c
@@ -71,6 +71,9 @@ void board_init_f(ulong dummy)
/* Clear the BSS */
memset(__bss_start, 0, __bss_end - __bss_start);
 
+#ifdef CONFIG_LAYERSCAPE_NS_ACCESS
+   enable_layerscape_ns_access();
+#endif
board_init_r(NULL, 0);
 }
 #endif
diff --git a/board/freescale/ls1043ardb/README 
b/board/freescale/ls1043ardb/README
index d5925a9..4f15557 100644
--- a/board/freescale/ls1043ardb/README
+++ b/board/freescale/ls1043ardb/README
@@ -83,3 +83,4 @@ Start Address End Address Description Size
 Booting Options
 ---
 a) NOR boot
+b) NAND boot
diff --git a/board/freescale/ls1043ardb/cpld.c 
b/board/freescale/ls1043ardb/cpld.c
index 3f1101e..f29383d 100644
--- a/board/freescale/ls1043ardb/cpld.c
+++ b/board/freescale/ls1043ardb/cpld.c
@@ -45,6 +45,22 @@ void cpld_set_defbank(void)
CPLD_WRITE(global_rst, 1);
 }
 
+void cpld_set_nand(void)
+{
+   u16 reg = CPLD_CFG_RCW_SRC_NAND;
+   u8 reg5 = (u8)(reg >> 1);
+   u8 reg6 = (u8)(reg & 1);
+
+   cpld_rev_bit();
+
+   CPLD_WRITE(soft_mux_on, 1);
+
+   CPLD_WRITE(cfg_rcw_src1, reg5);
+   CPLD_WRITE(cfg_rcw_src2, reg6);
+
+   CPLD_WRITE(system_rst, 1);
+}
+
 #ifdef DEBUG
 static void cpld_dump_regs(void)
 {
@@ -91,6 +107,8 @@ int do_cpld(cmd_tbl_t *cmdtp, int flag, int argc, char * 
const argv[])
if (strcmp(argv[1], "reset") == 0) {
if (strcmp(argv[2], "altbank") == 0)
cpld_set_altbank();
+   else if (strcmp(argv[2], "nand") == 0)
+   cpld_set_nand();
else
cpld_set_defbank();
 #ifdef DEBUG
@@ -109,6 +127,7 @@ U_BOOT_CMD(
"Reset the board or alternate bank",
"reset: reset to default bank\n"
"cpld reset altbank: reset to alternate bank\n"
+   "cpld reset nand: reset to boot from NAND flash\n"
 #ifdef DEBUG
"cpld dump - display the CPLD registers\n"
 #endif
diff --git a/board/freescale/ls1043ardb/cpld.h 
b/board/freescale/ls1043ardb/cpld.h
index ea4efd8..5f43a8a 100644
--- a/board/freescale/ls1043ardb/cpld.h
+++ b/board/freescale/ls1043ardb/cpld.h
@@ -40,4 +40,5 @@ void cpld_rev_bit(unsigned char *value);
 #define CPLD_SW_MUX_BANK_SEL   0x40
 #define CPLD_BANK_SEL_MASK 0x07
 #define CPLD_BANK_SEL_ALTBANK  0x04
+#define CPLD_CFG_RCW_SRC_NAND  0x106
 #endif
diff --git a/board/freescale/ls1043ardb/ls1043ardb_pbi.cfg 
b/board/freescale/ls1043ardb/ls1043ardb_pbi.cfg
new file mode 100644
index 000..f072274
--- /dev/null
+++ b/board/freescale/ls1043ardb/ls1043ardb_pbi.cfg
@@ -0,0 +1,14 @@
+#Configure Scratch register
+09570600 
+09570604 1000
+#Alt base register
+09570158 1000
+#Disable CCI barrier tranaction
+09570178 e010
+0918 0008
+#USB PHY frequency sel
+09570418 009e
+0957041c 009e
+09570420 009e
+#flush PBI data
+096100c0 000f
diff --git a/board/freescale/ls1043ardb/ls1043ardb_rcw_nand.cfg 
b/board/freescale/ls1043ardb/ls1043ardb_rcw_nand.cfg
new file mode 100644
index 000..935ffc0
--- /dev/null
+++ b/board/freescale/ls1043ardb/ls1043ardb_rcw_nand.cfg

[U-Boot] [Patch V6 04/18] net/fm/eth: Use mb() to be compatible for both ARM and PowerPC

[Gong Qianyu]

From: Shaohui Xie 

Use mb() instead of sync() to be compatible for both ARM and PowerPC.

Signed-off-by: Shaohui Xie 
Signed-off-by: Mingkai Hu 
Signed-off-by: Gong Qianyu 
---
V6:
 - No change.
V5:
 - No change.
V4:
 - No change.
V3:
 - New patch. Separated from patch 'net: Move some header files to include/'

 drivers/net/fm/eth.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/net/fm/eth.c b/drivers/net/fm/eth.c
index 368d554..ad02c66 100644
--- a/drivers/net/fm/eth.c
+++ b/drivers/net/fm/eth.c
@@ -371,7 +371,7 @@ static void fmc_tx_port_graceful_stop_enable(struct fm_eth 
*fm_eth)
pram = fm_eth->tx_pram;
/* graceful stop transmission of frames */
setbits_be32(>mode, PRAM_MODE_GRACEFUL_STOP);
-   sync();
+   mb();
 }
 
 static void fmc_tx_port_graceful_stop_disable(struct fm_eth *fm_eth)
@@ -381,7 +381,7 @@ static void fmc_tx_port_graceful_stop_disable(struct fm_eth 
*fm_eth)
pram = fm_eth->tx_pram;
/* re-enable transmission of frames */
clrbits_be32(>mode, PRAM_MODE_GRACEFUL_STOP);
-   sync();
+   mb();
 }
 
 static int fm_eth_open(struct eth_device *dev, bd_t *bd)
@@ -483,9 +483,9 @@ static int fm_eth_send(struct eth_device *dev, void *buf, 
int len)
muram_writew(>buf_ptr_hi, 0);
out_be32(>buf_ptr_lo, (u32)buf);
muram_writew(>len, len);
-   sync();
+   mb();
muram_writew(>status, TxBD_READY | TxBD_LAST);
-   sync();
+   mb();
 
/* update TxQD, let RISC to send the packet */
offset_in = muram_readw(>txqd.offset_in);
@@ -493,7 +493,7 @@ static int fm_eth_send(struct eth_device *dev, void *buf, 
int len)
if (offset_in >= muram_readw(>txqd.bd_ring_size))
offset_in = 0;
muram_writew(>txqd.offset_in, offset_in);
-   sync();
+   mb();
 
/* wait for buffer to be transmitted */
for (i = 0; muram_readw(>status) & TxBD_READY; i++) {
@@ -544,7 +544,7 @@ static int fm_eth_recv(struct eth_device *dev)
/* clear the RxBDs */
muram_writew(>status, RxBD_EMPTY);
muram_writew(>len, 0);
-   sync();
+   mb();
 
/* advance RxBD */
rxbd++;
@@ -560,7 +560,7 @@ static int fm_eth_recv(struct eth_device *dev)
if (offset_out >= muram_readw(>rxqd.bd_ring_size))
offset_out = 0;
muram_writew(>rxqd.offset_out, offset_out);
-   sync();
+   mb();
}
fm_eth->cur_rxbd = (void *)rxbd;
 
-- 
2.1.0.27.g96db324

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

[U-Boot] [Patch V6 17/18] armv8/ls1043ardb: Add sd boot support

[Gong Qianyu]

From: Gong Qianyu 

Signed-off-by: Gong Qianyu 
---
V6:
 - No change.
V5:
 - No change.
V4:
 - No change.
V3:
 - Squash the add cpld command patch to it.
V2:
 - No change.

 board/freescale/ls1043ardb/README|  1 +
 board/freescale/ls1043ardb/cpld.c| 18 ++
 board/freescale/ls1043ardb/cpld.h|  1 +
 board/freescale/ls1043ardb/ls1043ardb.c  |  6 +
 board/freescale/ls1043ardb/ls1043ardb_rcw_sd.cfg |  7 ++
 configs/ls1043ardb_sdcard_defconfig  |  4 
 include/configs/ls1043a_common.h | 30 
 include/configs/ls1043ardb.h | 11 -
 8 files changed, 77 insertions(+), 1 deletion(-)

diff --git a/board/freescale/ls1043ardb/README 
b/board/freescale/ls1043ardb/README
index 4f15557..0556e73 100644
--- a/board/freescale/ls1043ardb/README
+++ b/board/freescale/ls1043ardb/README
@@ -84,3 +84,4 @@ Booting Options
 ---
 a) NOR boot
 b) NAND boot
+c) SD boot
diff --git a/board/freescale/ls1043ardb/cpld.c 
b/board/freescale/ls1043ardb/cpld.c
index f29383d..78c2824 100644
--- a/board/freescale/ls1043ardb/cpld.c
+++ b/board/freescale/ls1043ardb/cpld.c
@@ -61,6 +61,21 @@ void cpld_set_nand(void)
CPLD_WRITE(system_rst, 1);
 }
 
+void cpld_set_sd(void)
+{
+   u16 reg = CPLD_CFG_RCW_SRC_SD;
+   u8 reg5 = (u8)(reg >> 1);
+   u8 reg6 = (u8)(reg & 1);
+
+   cpld_rev_bit();
+
+   CPLD_WRITE(soft_mux_on, 1);
+
+   CPLD_WRITE(cfg_rcw_src1, reg5);
+   CPLD_WRITE(cfg_rcw_src2, reg6);
+
+   CPLD_WRITE(system_rst, 1);
+}
 #ifdef DEBUG
 static void cpld_dump_regs(void)
 {
@@ -109,6 +124,8 @@ int do_cpld(cmd_tbl_t *cmdtp, int flag, int argc, char * 
const argv[])
cpld_set_altbank();
else if (strcmp(argv[2], "nand") == 0)
cpld_set_nand();
+   else if (strcmp(argv[2], "sd") == 0)
+   cpld_set_sd();
else
cpld_set_defbank();
 #ifdef DEBUG
@@ -128,6 +145,7 @@ U_BOOT_CMD(
"reset: reset to default bank\n"
"cpld reset altbank: reset to alternate bank\n"
"cpld reset nand: reset to boot from NAND flash\n"
+   "cpld reset sd: reset to boot from SD card\n"
 #ifdef DEBUG
"cpld dump - display the CPLD registers\n"
 #endif
diff --git a/board/freescale/ls1043ardb/cpld.h 
b/board/freescale/ls1043ardb/cpld.h
index 5f43a8a..bd59c0e 100644
--- a/board/freescale/ls1043ardb/cpld.h
+++ b/board/freescale/ls1043ardb/cpld.h
@@ -41,4 +41,5 @@ void cpld_rev_bit(unsigned char *value);
 #define CPLD_BANK_SEL_MASK 0x07
 #define CPLD_BANK_SEL_ALTBANK  0x04
 #define CPLD_CFG_RCW_SRC_NAND  0x106
+#define CPLD_CFG_RCW_SRC_SD0x040
 #endif
diff --git a/board/freescale/ls1043ardb/ls1043ardb.c 
b/board/freescale/ls1043ardb/ls1043ardb.c
index 461a195..9032ed3 100644
--- a/board/freescale/ls1043ardb/ls1043ardb.c
+++ b/board/freescale/ls1043ardb/ls1043ardb.c
@@ -25,12 +25,17 @@ DECLARE_GLOBAL_DATA_PTR;
 int checkboard(void)
 {
static const char *freq[3] = {"100.00MHZ", "156.25MHZ"};
+#ifndef CONFIG_SD_BOOT
u8 cfg_rcw_src1, cfg_rcw_src2;
u32 cfg_rcw_src;
+#endif
u32 sd1refclk_sel;
 
printf("Board: LS1043ARDB, boot from ");
 
+#ifdef CONFIG_SD_BOOT
+   puts("SD\n");
+#else
cfg_rcw_src1 = CPLD_READ(cfg_rcw_src1);
cfg_rcw_src2 = CPLD_READ(cfg_rcw_src2);
cpld_rev_bit(_rcw_src1);
@@ -43,6 +48,7 @@ int checkboard(void)
puts("NAND\n");
else
printf("Invalid setting of SW4\n");
+#endif
 
printf("CPLD:  V%x.%x\nPCBA:  V%x.0\n", CPLD_READ(cpld_ver),
   CPLD_READ(cpld_ver_sub), CPLD_READ(pcba_ver));
diff --git a/board/freescale/ls1043ardb/ls1043ardb_rcw_sd.cfg 
b/board/freescale/ls1043ardb/ls1043ardb_rcw_sd.cfg
new file mode 100644
index 000..28cd958
--- /dev/null
+++ b/board/freescale/ls1043ardb/ls1043ardb_rcw_sd.cfg
@@ -0,0 +1,7 @@
+#PBL preamble and RCW header
+aa55aa55 01ee0100
+# RCW
+081f 0c00  
+14550002 80004012 6004 61002000
+   00038800
+ 1100 0096 0001
diff --git a/configs/ls1043ardb_sdcard_defconfig 
b/configs/ls1043ardb_sdcard_defconfig
new file mode 100644
index 000..5fe0470
--- /dev/null
+++ b/configs/ls1043ardb_sdcard_defconfig
@@ -0,0 +1,4 @@
+CONFIG_SPL=y
+CONFIG_SYS_EXTRA_OPTIONS="RAMBOOT_PBL,SPL_FSL_PBL,SD_BOOT,SYS_FSL_DDR4"
+CONFIG_ARM=y
+CONFIG_TARGET_LS1043ARDB=y
diff --git a/include/configs/ls1043a_common.h b/include/configs/ls1043a_common.h
index f1fc685..5b61fcc 100644
--- a/include/configs/ls1043a_common.h
+++ b/include/configs/ls1043a_common.h
@@ -62,6 +62,36 @@
 #define CONFIG_BAUDRATE115200
 #define CONFIG_SYS_BAUDRATE_TABLE  { 9600, 19200, 38400, 57600, 115200 }
 
+/* SD boot SPL */
+#ifdef 

Re: [U-Boot] [PATCH] net: convert altera_tse to driver model and phylib

[Marek Vasut]

On Monday, October 19, 2015 at 04:36:21 AM, Thomas Chou wrote:

Hi!

> Convert altera_tse to driver model and phylib.
> 
> Signed-off-by: Thomas Chou 
> ---
>  configs/nios2-generic_defconfig |   2 +
>  doc/device-tree-bindings/net/altera_tse.txt | 112 
>  drivers/net/Kconfig |   9 +
>  drivers/net/altera_tse.c| 938
> ++-- drivers/net/altera_tse.h|
> 283 +++--
>  include/configs/nios2-generic.h |   8 +
>  6 files changed, 536 insertions(+), 816 deletions(-)
>  create mode 100644 doc/device-tree-bindings/net/altera_tse.txt
> 
> diff --git a/configs/nios2-generic_defconfig

[...]

>  /* sgdma debug - print descriptor */
>  static void alt_sgdma_print_desc(volatile struct alt_sgdma_descriptor
> *desc) {
>   debug("SGDMA DEBUG :\n");
> - debug("desc->source : 0x%x \n", (unsigned int)desc->source);
> - debug("desc->destination : 0x%x \n", (unsigned int)desc->destination);
> - debug("desc->next : 0x%x \n", (unsigned int)desc->next);
> - debug("desc->source_pad : 0x%x \n", (unsigned int)desc->source_pad);
> - debug("desc->destination_pad : 0x%x \n",
> -   (unsigned int)desc->destination_pad);
> - debug("desc->next_pad : 0x%x \n", (unsigned int)desc->next_pad);
> - debug("desc->bytes_to_transfer : 0x%x \n",
> -   (unsigned int)desc->bytes_to_transfer);
> - debug("desc->actual_bytes_transferred : 0x%x \n",
> -   (unsigned int)desc->actual_bytes_transferred);
> - debug("desc->descriptor_status : 0x%x \n",
> -   (unsigned int)desc->descriptor_status);
> - debug("desc->descriptor_control : 0x%x \n",
> -   (unsigned int)desc->descriptor_control);
> + debug("desc->source : 0x%x\n", (unsigned int)desc->source);
> + debug("desc->destination : 0x%x\n", (unsigned int)desc->destination);
> + debug("desc->next : 0x%x\n", (unsigned int)desc->next);
> + debug("desc->source_pad : 0x%x\n", desc->source_pad);
> + debug("desc->destination_pad : 0x%x\n", desc->destination_pad);
> + debug("desc->next_pad : 0x%x\n", desc->next_pad);
> + debug("desc->bytes_to_transfer : 0x%x\n", desc->bytes_to_transfer);
> + debug("desc->actual_bytes_transferred : 0x%x\n",
> +   desc->actual_bytes_transferred);
> + debug("desc->descriptor_status : 0x%x\n", desc->descriptor_status);
> + debug("desc->descriptor_control : 0x%x\n", desc->descriptor_control);
>  }

Looks like a cleanup part of the patch, not a conversion, so you might want
to split this out. Btw. while at it, please drop those (unsigned int) casts.

> -/* This is a generic routine that the SGDMA mode-specific routines
> +/*
> + * This is a generic routine that the SGDMA mode-specific routines
>   * call to populate a descriptor.
>   * arg1  :pointer to first SGDMA descriptor.
>   * arg2  :pointer to next  SGDMA descriptor.
> @@ -108,7 +107,6 @@ static void alt_sgdma_construct_descriptor_burst(
>* pointing at this descriptor, it will not run (via the "owned by
>* hardware" bit) until all other descriptor has been set up.
>*/
> -
>   desc->descriptor_control =
>   ((ALT_SGDMA_DESCRIPTOR_CONTROL_OWNED_BY_HW_MSK) |
>(generate_eop ?
> @@ -121,18 +119,19 @@ static void alt_sgdma_construct_descriptor_burst(
>   );
>  }
> 
> -static int alt_sgdma_do_sync_transfer(volatile struct alt_sgdma_registers
> *dev, -  volatile struct alt_sgdma_descriptor 
*desc)
> +static int alt_sgdma_do_sync_transfer(
> + volatile struct alt_sgdma_registers *regs,
> + volatile struct alt_sgdma_descriptor *desc)

The volatiles are almost certainly wrong, so they should go.

Oh wait, is this driver NOT using any I/O accessors ? :-O

>  {
>   unsigned int status;
>   int counter = 0;
> 
>   /* Wait for any pending transfers to complete */
>   alt_sgdma_print_desc(desc);
> - status = dev->status;
> + status = regs->status;
> 
>   counter = 0;
> - while (dev->status & ALT_SGDMA_STATUS_BUSY_MSK) {
> + while (regs->status & ALT_SGDMA_STATUS_BUSY_MSK) {
>   if (counter++ > ALT_TSE_SGDMA_BUSY_WATCHDOG_CNTR)
>   break;
>   }
> @@ -144,12 +143,12 @@ static int alt_sgdma_do_sync_transfer(volatile struct
> alt_sgdma_registers *dev, * Clear any (previous) status register
> information
>* that might occlude our error checking later.
>*/
> - dev->status = 0xFF;
> + regs->status = 0xFF;
> 
>   /* Point the controller at the descriptor */
> - dev->next_descriptor_pointer = (unsigned int)desc & 0x1FFF;
> + regs->next_descriptor_pointer = (unsigned int)desc & 0x1FFF;

This looks pretty wrong, with the cast and all.

>   debug("next desc in sgdma 0x%x\n",
> -   (unsigned int)dev->next_descriptor_pointer);
> +   (unsigned 

Re: [U-Boot] Doubt in USB driver for Vybrid vf610

[Santhosh Kumar Janardhanam -ERS, HCL Tech]

Hi Sanchayan,
We are using a custom board with vybrid processor,in which we need to configure 
USB0 as host and USB1 as client.

Regards,
Santhosh

-Original Message-
From: maitysancha...@gmail.com [mailto:maitysancha...@gmail.com] 
Sent: Monday, October 19, 2015 10:59 AM
To: ma...@denx.de
Cc: u-boot@lists.denx.de; Santhosh Kumar Janardhanam -ERS, HCL Tech
Subject: Re: [U-Boot] Doubt in USB driver for Vybrid vf610

Hello Marek,

On 15-10-17 21:59:07, maitysancha...@gmail.com wrote:
> Hello,
> 
> On 15-10-16 16:20:07, Santhosh Kumar Janardhanam -ERS, HCL Tech wrote:
> > Hi All,
> > I am working on USB part for vybrid vf-610 processor, We have two 
> > ports in the board
> > 
> > when I type usb start in uboot command prompt, It returns as ENODEV 
> > for USB0 and when analyzed, It is returning from the below code in 
> > ehci-hcd_init function(in ehci-vf.c)
> > 
> > if (init == USB_INIT_HOST && index == 0)
> > return -ENODEV;
> > 

Along with the above
if (init == USB_INIT_DEVICE && index == 1)
return -ENODEV;

In the ehci-vf USB driver for Vybrid, currently we have two "if" cases as above 
which basically serve the purpose of preventing one of the USB ports from being 
configured as host, which we did like to keep as client. So for us, USB0 is 
client and USB1 is host and the above was put in with that intention to prevent 
USB0 from being configured as host, when usb start is called.
However this is bad for other users out there, sorry about that.

I checked and it seems even without the above, if both ports are configured as 
host with usb start and later dfu is called to used the intended as client for 
upgrade purposes, things still seem to work. Not sure if there are cases where 
this can break which I am missing.

Not being that well versed with USB I wanted to ask is this ok or this is 
completely wrong?
If it is ok, I guess we can go ahead and nuke the above checks? OR will be it 
be a better approach to introduce something like 
board_ehci_hch_init_with_type(int index, enum usb_init_type type) which will be 
a weak function and then have the board specific code hook call it?

- Sanchayan.

> >  If these two  lines are commented, the usb start is working and device is 
> > found on USB0.
> > Why is this check kept in the code? 
> 
> I am the author of the ehci-vf USB driver which is based on iMX6 
> implementation.
> The implementation was done as per our requirements where we have one 
> port as host and another as client. In hindsight my implementation is 
> severely restricting and at that time I missed thinking of it and did not had 
> other boards to test.
> 
> I will fix this up and send a patch. However I need to look a bit. The 
> ideal way would be to fix it up in board_ehci_hcd_init call however 
> that does not provide the init parameter to distinguish between 
> USB_INIT_DEVICE and USB_INIT_HOST.
> 
> May I ask are you using some module or you have your custom setup 
> around the Vybrid? Sorry for the trouble. Thanks for reporting.
> 
> - Sanchayan.
> 
> >
> > Regards,
> > Santhosh
> > 
> > 
> > ::DISCLAIMER::
> > 
> > 
> > 
> > 
> > The contents of this e-mail and any attachment(s) are confidential and 
> > intended for the named recipient(s) only.
> > E-mail transmission is not guaranteed to be secure or error-free as 
> > information could be intercepted, corrupted, lost, destroyed, arrive 
> > late or incomplete, or may contain viruses in transmission. The e mail and 
> > its contents (with or without referred errors) shall therefore not attach 
> > any liability on the originator or HCL or its affiliates.
> > Views or opinions, if any, presented in this email are solely those 
> > of the author and may not necessarily reflect the views or opinions 
> > of HCL or its affiliates. Any form of reproduction, dissemination, 
> > copying, disclosure, modification, distribution and / or publication of 
> > this message without the prior written consent of authorized representative 
> > of HCL is strictly prohibited. If you have received this email in error 
> > please delete it and notify the sender immediately.
> > Before opening any email and/or attachments, please check them for viruses 
> > and other defects.
> > 
> > 
> > 
> > 
> > 
> > ___
> > U-Boot mailing list
> > U-Boot@lists.denx.de
> > http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 2/2] vexpress64: Juno: Add initialisation code for Juno R1 PCIe host bridge.

[Liviu Dudau]

On Fri, 16 Oct 2015 17:58:44 +0100
Ryan Harkin  wrote:

> Hi Liviu,
> 
> These patches work well for me, so at the very least, you can add my
> Test-by for both:
> 
> Tested-by: Ryan Harkin 

Hi Ryan,

Thanks for testing this patchset.

> 
> But...
> 
> I ran checkpatch.pl across your patches and this one throws a few trivial
> warnings, mostly about 80 character lines and a few like this:
> 
> CHECK: Prefer using the BIT macro
> #97: FILE: board/armltd/vexpress64/pcie.c:60:
> +#define JUNO_RESET_CTRL_PHY(1 << 0)
> 
> But also these:
> 
> WARNING: long udelay - prefer mdelay; see arch/arm/include/asm/delay.h
> #208: FILE: board/armltd/vexpress64/pcie.c:171:
> +udelay(2);
> 
> CHECK: Please don't use multiple blank lines
> #227: FILE: board/armltd/vexpress64/pcie.c:190:
> +
> +
> 
> CHECK: Please don't use multiple blank lines
> #251: FILE: board/armltd/vexpress64/pcie.h:12:
> +
> +

Interesting, when running ./scripts/checkpatch.pl in my copy of U-Boot I
get the 7 warnings about lines over 80 characters long, and the
following message:

NOTE: Ignored message types: COMPLEX_MACRO CONSIDER_KSTRTO MINMAX 
MULTISTATEMENT_MACRO_USE_DO_WHILE NETWORKING_BLOCK_COMMENT_STYLE USLEEP_RANGE

Not sure how to enable all the types by default and also the reason why
I've missed them.

> 
> I'm not sure who strict the rules are followed for these types of warning.
> But if you are fixing up, I also noticed a couple of whitespace nits below.
> 
> 
> On 16 October 2015 at 15:41, Liviu Dudau  wrote:
> 
> > Juno R1 has an XpressRICH3 PCIe host bridge that needs to be initialised
> > in order for the Linux kernel to be able to enumerate the bus. Add
> > support code here that enables the host bridge, trains the links and
> > sets up the Address Translation Tables.
> >
> > Signed-off-by: Liviu Dudau 
> > ---
> >  board/armltd/vexpress64/Makefile |   2 +-
> >  board/armltd/vexpress64/pcie.c   | 196
> > +++
> >  board/armltd/vexpress64/pcie.h   |  13 +++
> >  board/armltd/vexpress64/vexpress64.c |   2 +
> >  4 files changed, 212 insertions(+), 1 deletion(-)
> >  create mode 100644 board/armltd/vexpress64/pcie.c
> >  create mode 100644 board/armltd/vexpress64/pcie.h
> >
> > diff --git a/board/armltd/vexpress64/Makefile
> > b/board/armltd/vexpress64/Makefile
> > index e009141..a35db40 100644
> > --- a/board/armltd/vexpress64/Makefile
> > +++ b/board/armltd/vexpress64/Makefile
> > @@ -5,4 +5,4 @@
> >  # SPDX-License-Identifier: GPL-2.0+
> >  #
> >
> > -obj-y  := vexpress64.o
> > +obj-y  := vexpress64.o pcie.o
> > diff --git a/board/armltd/vexpress64/pcie.c
> > b/board/armltd/vexpress64/pcie.c
> > new file mode 100644
> > index 000..367efd4
> > --- /dev/null
> > +++ b/board/armltd/vexpress64/pcie.c
> > @@ -0,0 +1,196 @@
> > +/*
> > + * Copyright (C) ARM Ltd 2015
> > + *
> > + * Author: Liviu Dudau 
> > + *
> > + * SPDX-Licence-Identifier:GPL-2.0+
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include "pcie.h"
> > +
> > +/* XpressRICH3 support */
> > +#define XR3_CONFIG_BASE0x7ff3
> > +#define XR3_RESET_BASE 0x7ff2
> > +
> > +#define XR3_PCI_ECAM_START 0x4000
> > +#define XR3_PCI_ECAM_SIZE  28  /* as power of 2 =
> > 0x1000 */
> > +#define XR3_PCI_IOSPACE_START  0x5f80
> > +#define XR3_PCI_IOSPACE_SIZE   23  /* as power of 2 =
> > 0x80 */
> > +#define XR3_PCI_MEMSPACE_START 0x5000
> > +#define XR3_PCI_MEMSPACE_SIZE  27  /* as power of 2 =
> > 0x800 */
> > +#define XR3_PCI_MEMSPACE64_START   0x40
> > +#define XR3_PCI_MEMSPACE64_SIZE33  /* as power of 2 =
> > 0x2 */
> > +
> > +#define JUNO_V2M_MSI_START 0x2c1c
> > +#define JUNO_V2M_MSI_SIZE  12  /* as power of 2 = 4096 */
> > +
> > +#define XR3PCI_BASIC_STATUS0x18
> > +#defineXR3PCI_BS_GEN_MASK  (0xf << 8)
> > +#defineXR3PCI_BS_LINK_MASK 0xff
> >
> 
> There's some strange extra whitespace in there...
> 
> +
> > +#define XR3PCI_VIRTCHAN_CREDITS0x90
> > +#define XR3PCI_BRIDGE_PCI_IDS  0x9c
> > +#define XR3PCI_PEX_SPC20xd8
> > +
> > +#define XR3PCI_ATR_PCIE_WIN0   0x600
> > +#define XR3PCI_ATR_PCIE_WIN1   0x700
> > +#define XR3PCI_ATR_AXI4_SLV0   0x800
> > +
> > +#define XR3PCI_ATR_TABLE_SIZE  0x20
> > +#define XR3PCI_ATR_SRC_ADDR_LOW0x0
> > +#define XR3PCI_ATR_SRC_ADDR_HIGH   0x4
> > +#define XR3PCI_ATR_TRSL_ADDR_LOW   0x8
> > +#define XR3PCI_ATR_TRSL_ADDR_HIGH  0xc
> > +#define XR3PCI_ATR_TRSL_PARAM  0x10
> >
> 
> Perhaps add a newline here if you need to respin?
> 
> 
> > +/* IDs used in the XR3PCI_ATR_TRSL_PARAM */
> > 

Re: [U-Boot] [PATCH 1/3] ARM: relocate: fix hang when CONFIG_ARMV7_SECURE_BASE

[Albert ARIBAUD]

Hello Peng,

(cutting a bit through the previous mails quoting)

> >This, in turn, leads to new questions:
> >
> >1. How is this PSCI code put in place? Is it bundled with the image,
> >   with a specificy copy routine which puts it in place then locks the
> Yeah.
> >   memory range against writing? Or is it loaded in place by some other
> >   agent than U-Boot, and how does this agent know what to put where?
> 
> In arch/arm/cpu/armv7/virt-v7.c, relocate_secure_section() does this job.
> 
> CONFIG_ARMV7_SECURE_BASE is the location that secure code will be copied
> to. To ARMV7, PSCI code is bundled with the uboot image.

Hmm, the 'relocate' part of the function name is a somewhat non-optimal
choice, since the routine just copies data without modifying it.

Looking at relocate_secure_section(), I see that it it is called long
after the U-Boot code was relocated -- actually, it is called during
bootm.

This means that for any one of the other boards around that seem to use
PSCI, either "their" PSCI code does not have any relocations (which I
doubt), or it has but they don't cause any data abort when done by the
relocate_code() routine.

So what's the difference between those and your board? My bet is that
their CONFIG_ARMV7_SECURE_BASE is not write-protected at the time the
relocate_code() routine executes (whereas on your board it is), and
will be unlocked in some way by the time relocate_secure_section()
executes.

I'm not saying that the correct solution would be to enable write
access to CONFIG_ARMV7_SECURE_BASE before running relocate_code(),
because doing that would be obviously wrong: relocate_code() would try
to fix code which is not there yet.

I'm just saying that's what actually happens, and if I am right, then
it confirms that the correct fix is to not let relocations to the
secure stay in the U-Boot ELF, or better yet, to not let them happen to
boot [pun half-intended].

> CONFIG_ARMV7_SECURE_BASE is the location that secure code will be copied
> to. To ARMV7, PSCI code is bundled with the uboot image.
> 
> >
> >2. Does this code and the relocatable image refer to symbols of one
> >   another,
> Yeah. There is asm function reference. You can see arch/arm/cpu/armv7/psci.S

Looking at this file, I suspect that actually, PSCI is called through a
software interrupt / exception vector, not through a function name, and
the only symbolic relationship is via __secure_start and __secure_end
-- and those must (and will) be correctly relocated along with the
U-Boot image.

> >or do they interact through an IPC independent of their
> >   respective location (in which case, one wonders why they are built
> >   into a single ELF file)?
> 
> This comes a question, why PSCI framework intergated into U-Boot? I have no 
> idea.

There could have been alternative designs, indeed. Here is the design
now, so let's handle it.

> >More generally... which target do you see this problem on? Reproducing
> >the build myself would save both you and me some time, I guess. :)
> 
> Build target: mx7dsabresd
> 
> Needs to apply the three patches:
> https://patchwork.ozlabs.org/patch/527040/
> https://patchwork.ozlabs.org/patch/527038/
> https://patchwork.ozlabs.org/patch/527039/
> 
> There is a small difference from my previous log, since my previous log use
> 0x18 as the secure address, but the patches use 0x90 as the secure
> address. But sure there will be relocation entry there.

Thanks. I'll try and play with compiler / linker options, but from
my own experience, this can be tricky. Meanwhile, I suggest you for for
the not-too-quick-and-not-too-dirty linker script solution.

> >Do you need these relocation records? If not, then just append the
> >'*(.rel._secure*) input section spec (with a suitable comment) to
> >the already existing DISCARD output section. By the way, doesn't this
> >linker script change alone fix the data abort?
> 
> Yeah. Since the relocation entry for secure section will be stored
> in rel.secure section. And this section will not be touched in relocate.S

Ok, so that's our first clean, linker-script-based, solution confirmed.

> >Still, if there *are* relocation records emitted, that's because the
> >toolchain considered them necessary -- IOW, it was (wrongly) told the
> >PSCI code must be relocatable [or the code really is relocatable and we
> >just haven't not hit a bug about this yet].
> 
> The PSCI code is bundled with the u-boot image. But it's running address
> is not same with u-boot. In my example, u-boot is compiled with starting
> address 0x8780, but to PSCI, it's running address is 0x18.
> relocate_secure_section is just copy the psci code from uboot to 0x18.
> 
> compliation address is same with running address, to PSCI part.

(I understand that. My question was not "why is PSCI built for its
run-time address?" but "Since PSCI is built for its run-time address,
and since there is little dependency on how come it is built as
relocatable?")

> >Testing every single 

Re: [U-Boot] [PATCH] arm: sunxi: Add icnova-a20-swac defconfig and dts file

[Stefan Roese]

Hi Hans,

On 19.10.2015 13:44, Hans de Goede wrote:




diff --git a/arch/arm/dts/sun7i-a20-icnova-a20-swac.dts
b/arch/arm/dts/sun7i-a20-icnova-a20-swac.dts
new file mode 100644


Please submit this file also to the upstream kernel.


Yes. The name of the DT especially doesn't really make sense. The
"SWAC" name isn't referenced anywhere, the module cannot be used
alone, and there's a single combination available (A20 SODIMM +
ADB4006)


At least one other combination is available. A custom board from SWAC
equipped with the SoM. What is the preferred method to support SoM's
with multiple baseboards? Something like:

sun7i-a20-icnova.dtsi
sun7i-a20-icnova-adb4006.dts
sun7i-a20-icnova-swac.dts

?




index 000..773fb6f
--- /dev/null
+++ b/arch/arm/dts/sun7i-a20-icnova-a20-swac.dts
@@ -0,0 +1,177 @@
+/*
+ * Copyright 2013 Maxime Ripard
+ *
+ * Maxime Ripard 


And I'm *not* the copyright owner here.


Okay. Hans, do you want me to change this (and potential other
changes as well - see file naming above) via a follow-up patch
once its available in mainline U-Boot?


Actually I would prefer to get this right in one go, esp. the
filename bits, having u-boot and the kernel disagreeing on the
dtb filename is no good. So I plan to remove this version of
the patch from u-boot-sunxi/next for now. Once you and Maxime
agree on a dts / dtb filename please submit a new version and
I'll merge that one instead.


Sure. Lets do it this way.

Thanks,
Stefan

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

[U-Boot] [Patch V6 13/18] armv8/ls1043ardb: Add LS1043ARDB board support

[Gong Qianyu]

From: Mingkai Hu 

LS1043ARDB Specification:
-
Memory subsystem:
 * 2GByte DDR4 SDRAM (32bit bus)
 * 128 Mbyte NOR flash single-chip memory
 * 512 Mbyte NAND flash
 * 16 Mbyte high-speed SPI flash
 * SD connector to interface with the SD memory card

Ethernet:
 * XFI 10G port
 * QSGMII with 4x 1G ports
 * Two RGMII ports

PCIe:
 * PCIe2 (Lanes C) to mini-PCIe slot
 * PCIe3 (Lanes D) to PCIe slot

USB 3.0: two super speed USB 3.0 type A ports

UART: supports two UARTs up to 115200 bps for console

Signed-off-by: Hou Zhiqiang 
Signed-off-by: Li Yang 
Signed-off-by: Mingkai Hu 
Signed-off-by: York Sun 
Signed-off-by: Gong Qianyu 
---
V6:
 - Move GIC SMMU macros out of ls1043a_common.h.
V5:
 - No change.
V4: 
 - Change arch to layerscape.
 - Add PCIe support.
 - Move SMMU_BASE, GICC_BASE, GICD_BASE to ls1043a_common.h.
V3:
 - Fix message typos.
 - Add ddr model number in comments.
 - Fix boot options in README.
 - Remove some dead code.
V2:
 - Replaced ns_access.h with fsl_csu.h.

 arch/arm/Kconfig   |   7 +
 arch/arm/cpu/armv8/fsl-layerscape/Makefile |   4 +
 arch/arm/cpu/armv8/fsl-layerscape/ls1043a_serdes.c |  86 ++
 board/freescale/ls1043ardb/Kconfig |  16 ++
 board/freescale/ls1043ardb/MAINTAINERS |   7 +
 board/freescale/ls1043ardb/Makefile|   9 +
 board/freescale/ls1043ardb/README  |  85 +
 board/freescale/ls1043ardb/cpld.c  | 115 +
 board/freescale/ls1043ardb/cpld.h  |  43 +
 board/freescale/ls1043ardb/ddr.c   | 191 +
 board/freescale/ls1043ardb/ddr.h   |  45 +
 board/freescale/ls1043ardb/ls1043ardb.c| 131 ++
 configs/ls1043ardb_defconfig   |   4 +
 include/configs/ls1043a_common.h   | 174 +++
 include/configs/ls1043ardb.h   | 191 +
 15 files changed, 1108 insertions(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 7981355..bd99bfb 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -631,6 +631,12 @@ config TARGET_LS1021ATWR
select CPU_V7
select SUPPORT_SPL
 
+config TARGET_LS1043ARDB
+   bool "Support ls1043ardb"
+   select ARM64
+   help
+ Support for Freescale LS1043ARDB platform.
+
 config TARGET_H2200
bool "Support h2200"
select CPU_PXA
@@ -745,6 +751,7 @@ source "board/freescale/ls2085aqds/Kconfig"
 source "board/freescale/ls2085ardb/Kconfig"
 source "board/freescale/ls1021aqds/Kconfig"
 source "board/freescale/ls1021atwr/Kconfig"
+source "board/freescale/ls1043ardb/Kconfig"
 source "board/freescale/mx23evk/Kconfig"
 source "board/freescale/mx25pdk/Kconfig"
 source "board/freescale/mx28evk/Kconfig"
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Makefile 
b/arch/arm/cpu/armv8/fsl-layerscape/Makefile
index 4754e59..6fa08c8 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/Makefile
+++ b/arch/arm/cpu/armv8/fsl-layerscape/Makefile
@@ -23,4 +23,8 @@ endif
 
 ifneq ($(CONFIG_LS2085A),)
 obj-$(CONFIG_SYS_HAS_SERDES) += ls2085a_serdes.o
+else
+ifneq ($(CONFIG_LS1043A),)
+obj-$(CONFIG_SYS_HAS_SERDES) += ls1043a_serdes.o
+endif
 endif
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/ls1043a_serdes.c 
b/arch/arm/cpu/armv8/fsl-layerscape/ls1043a_serdes.c
new file mode 100644
index 000..e54d389
--- /dev/null
+++ b/arch/arm/cpu/armv8/fsl-layerscape/ls1043a_serdes.c
@@ -0,0 +1,86 @@
+/*
+ * Copyright 2015 Freescale Semiconductor, Inc.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+
+struct serdes_config {
+   u32 protocol;
+   u8 lanes[SRDS_MAX_LANES];
+};
+
+static struct serdes_config serdes1_cfg_tbl[] = {
+   /* SerDes 1 */
+   {0x1555, {XFI_FM1_MAC9, PCIE1, PCIE2, PCIE3} },
+   {0x2555, {SGMII_2500_FM1_DTSEC9, PCIE1, PCIE2, PCIE3} },
+   {0x4555, {QSGMII_FM1_A, PCIE1, PCIE2, PCIE3} },
+   {0x4558, {QSGMII_FM1_A, PCIE1, PCIE2, SATA1} },
+   {0x1355, {XFI_FM1_MAC9, SGMII_FM1_DTSEC2, PCIE2, PCIE3} },
+   {0x2355, {SGMII_2500_FM1_DTSEC9, SGMII_FM1_DTSEC2, PCIE2, PCIE3} },
+   {0x3335, {SGMII_FM1_DTSEC9, SGMII_FM1_DTSEC2, SGMII_FM1_DTSEC5,
+ PCIE3} },
+   {0x3355, {SGMII_FM1_DTSEC9, SGMII_FM1_DTSEC2, PCIE2, PCIE3} },
+   {0x3358, {SGMII_FM1_DTSEC9, SGMII_FM1_DTSEC2, PCIE2, SATA1} },
+   {0x3555, {SGMII_FM1_DTSEC9, PCIE1, PCIE2, PCIE3} },
+   {0x3558, {SGMII_FM1_DTSEC9, PCIE1, PCIE2, SATA1} },
+   {0x7000, {PCIE1, PCIE1, PCIE1, PCIE1} },
+   {0x9998, {PCIE1, PCIE2, PCIE3, SATA1} },
+   {0x6058, {PCIE1, PCIE1, PCIE2, SATA1} },
+   {0x1455, {XFI_FM1_MAC9, QSGMII_FM1_A, PCIE2, PCIE3} },
+   {0x2455, {SGMII_2500_FM1_DTSEC9, 

[U-Boot] [Patch V6 09/18] net/fm: Add QSGMII PCS init

[Gong Qianyu]

From: Shaohui Xie 

QSGMII PCS needed to be programmed same as SGMII PCS, and there are
four ports in QSGMII PCS, port 0, 1, 2, 3, all the four ports shared
port 0's MDIO controller, so when programming port 0, we continue to
program other three ports.

Signed-off-by: Shaohui Xie 
Signed-off-by: Mingkai Hu 
Signed-off-by: Gong Qianyu 
---
V6:
 - No change.
V5:
 - No change.
V4:
 - Remove the "if(priv->phyaddr%4 != 0)" condition in qsgmii_loop.
V3:
 - No change.
V2:
 - No change.

 drivers/net/fm/eth.c | 18 +-
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/drivers/net/fm/eth.c b/drivers/net/fm/eth.c
index bf16101..1cb1f7a 100644
--- a/drivers/net/fm/eth.c
+++ b/drivers/net/fm/eth.c
@@ -41,28 +41,35 @@ static void dtsec_configure_serdes(struct fm_eth *priv)
bus.priv = priv->mac->phyregs;
bool sgmii_2500 = (priv->enet_if ==
PHY_INTERFACE_MODE_SGMII_2500) ? true : false;
+   int i = 0;
 
+qsgmii_loop:
/* SGMII IF mode + AN enable only for 1G SGMII, not for 2.5G */
value = PHY_SGMII_IF_MODE_SGMII;
if (!sgmii_2500)
value |= PHY_SGMII_IF_MODE_AN;
 
-   memac_mdio_write(, 0, MDIO_DEVAD_NONE, 0x14, value);
+   memac_mdio_write(, i, MDIO_DEVAD_NONE, 0x14, value);
 
/* Dev ability according to SGMII specification */
value = PHY_SGMII_DEV_ABILITY_SGMII;
-   memac_mdio_write(, 0, MDIO_DEVAD_NONE, 0x4, value);
+   memac_mdio_write(, i, MDIO_DEVAD_NONE, 0x4, value);
 
/* Adjust link timer for SGMII  -
1.6 ms in units of 8 ns = 2 * 10^5 = 0x30d40 */
-   memac_mdio_write(, 0, MDIO_DEVAD_NONE, 0x13, 0x3);
-   memac_mdio_write(, 0, MDIO_DEVAD_NONE, 0x12, 0xd40);
+   memac_mdio_write(, i, MDIO_DEVAD_NONE, 0x13, 0x3);
+   memac_mdio_write(, i, MDIO_DEVAD_NONE, 0x12, 0xd40);
 
/* Restart AN */
value = PHY_SGMII_CR_DEF_VAL;
if (!sgmii_2500)
value |= PHY_SGMII_CR_RESET_AN;
-   memac_mdio_write(, 0, MDIO_DEVAD_NONE, 0, value);
+   memac_mdio_write(, i, MDIO_DEVAD_NONE, 0, value);
+
+   if ((priv->enet_if == PHY_INTERFACE_MODE_QSGMII) && (i < 3)) {
+   i++;
+   goto qsgmii_loop;
+   }
 #else
struct dtsec *regs = priv->mac->base;
struct tsec_mii_mng *phyregs = priv->mac->phyregs;
@@ -91,6 +98,7 @@ static void dtsec_init_phy(struct eth_device *dev)
 #endif
 
if (fm_eth->enet_if == PHY_INTERFACE_MODE_SGMII ||
+   fm_eth->enet_if == PHY_INTERFACE_MODE_QSGMII ||
fm_eth->enet_if == PHY_INTERFACE_MODE_SGMII_2500)
dtsec_configure_serdes(fm_eth);
 }
-- 
2.1.0.27.g96db324

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

[U-Boot] [Patch V6 08/18] net: Move some header files to include/

[Gong Qianyu]

From: Shaohui Xie 

The fsl_dtsec.h & fsl_tgec.h & fsl_fman.h can be shared on both ARM
and PPC, move it out of ppc to include/, and change the path in
drivers accordingly.

Signed-off-by: Shaohui Xie 
Signed-off-by: Gong Qianyu 
---
V6:
 - No change.
V5:
 - No change.
V4:
 - No change.
V3:
 - No change.
V2:
 - No change.

 arch/powerpc/include/asm/immap_85xx.h | 2 +-
 board/freescale/b4860qds/eth_b4860qds.c   | 2 +-
 board/freescale/corenet_ds/eth_hydra.c| 2 +-
 board/freescale/corenet_ds/eth_p4080.c| 2 +-
 board/freescale/corenet_ds/eth_superhydra.c   | 2 +-
 board/freescale/p1023rdb/p1023rdb.c   | 2 +-
 board/freescale/p2041rdb/eth.c| 2 +-
 board/freescale/t102xqds/eth_t102xqds.c   | 2 +-
 board/freescale/t102xrdb/eth_t102xrdb.c   | 2 +-
 board/freescale/t1040qds/eth.c| 2 +-
 board/freescale/t104xrdb/eth.c| 2 +-
 board/freescale/t208xqds/eth_t208xqds.c   | 2 +-
 board/freescale/t208xrdb/eth_t208xrdb.c   | 2 +-
 board/freescale/t4qds/eth.c   | 2 +-
 board/freescale/t4rdb/eth.c   | 2 +-
 drivers/net/fm/dtsec.c| 2 +-
 drivers/net/fm/eth.c  | 4 ++--
 drivers/net/fm/fm.h   | 2 +-
 drivers/net/fm/tgec.c | 2 +-
 drivers/net/fm/tgec_phy.c | 2 +-
 {arch/powerpc/include/asm => include}/fsl_dtsec.h | 0
 {arch/powerpc/include/asm => include}/fsl_fman.h  | 0
 {arch/powerpc/include/asm => include}/fsl_tgec.h  | 0
 23 files changed, 21 insertions(+), 21 deletions(-)

diff --git a/arch/powerpc/include/asm/immap_85xx.h 
b/arch/powerpc/include/asm/immap_85xx.h
index 0c9d85e..101b8db 100644
--- a/arch/powerpc/include/asm/immap_85xx.h
+++ b/arch/powerpc/include/asm/immap_85xx.h
@@ -19,7 +19,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 
 typedef struct ccsr_local {
diff --git a/board/freescale/b4860qds/eth_b4860qds.c 
b/board/freescale/b4860qds/eth_b4860qds.c
index 501d4b3..df90476 100644
--- a/board/freescale/b4860qds/eth_b4860qds.c
+++ b/board/freescale/b4860qds/eth_b4860qds.c
@@ -26,7 +26,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include "../common/ngpixis.h"
 #include "../common/fman.h"
diff --git a/board/freescale/corenet_ds/eth_hydra.c 
b/board/freescale/corenet_ds/eth_hydra.c
index 396103f..172a55b 100644
--- a/board/freescale/corenet_ds/eth_hydra.c
+++ b/board/freescale/corenet_ds/eth_hydra.c
@@ -55,7 +55,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include "../common/ngpixis.h"
 #include "../common/fman.h"
diff --git a/board/freescale/corenet_ds/eth_p4080.c 
b/board/freescale/corenet_ds/eth_p4080.c
index 5cbec7f..c68dc2c 100644
--- a/board/freescale/corenet_ds/eth_p4080.c
+++ b/board/freescale/corenet_ds/eth_p4080.c
@@ -24,7 +24,7 @@
 
 #include "../common/ngpixis.h"
 #include "../common/fman.h"
-#include 
+#include 
 
 #define EMI_NONE   0x
 #define EMI_MASK   0xf000
diff --git a/board/freescale/corenet_ds/eth_superhydra.c 
b/board/freescale/corenet_ds/eth_superhydra.c
index ad1bffd..62b1635 100644
--- a/board/freescale/corenet_ds/eth_superhydra.c
+++ b/board/freescale/corenet_ds/eth_superhydra.c
@@ -55,7 +55,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include "../common/ngpixis.h"
 #include "../common/fman.h"
diff --git a/board/freescale/p1023rdb/p1023rdb.c 
b/board/freescale/p1023rdb/p1023rdb.c
index 56f561a..074b713 100644
--- a/board/freescale/p1023rdb/p1023rdb.c
+++ b/board/freescale/p1023rdb/p1023rdb.c
@@ -26,7 +26,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
diff --git a/board/freescale/p2041rdb/eth.c b/board/freescale/p2041rdb/eth.c
index 532eeac..95fe85b 100644
--- a/board/freescale/p2041rdb/eth.c
+++ b/board/freescale/p2041rdb/eth.c
@@ -19,7 +19,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include "cpld.h"
 #include "../common/fman.h"
diff --git a/board/freescale/t102xqds/eth_t102xqds.c 
b/board/freescale/t102xqds/eth_t102xqds.c
index 441d6a3..99c23f7 100644
--- a/board/freescale/t102xqds/eth_t102xqds.c
+++ b/board/freescale/t102xqds/eth_t102xqds.c
@@ -21,7 +21,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include "../common/qixis.h"
 #include "../common/fman.h"
diff --git a/board/freescale/t102xrdb/eth_t102xrdb.c 
b/board/freescale/t102xrdb/eth_t102xrdb.c
index 856ec6e..02b283d 100644
--- a/board/freescale/t102xrdb/eth_t102xrdb.c
+++ b/board/freescale/t102xrdb/eth_t102xrdb.c
@@ -21,7 +21,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include "../common/fman.h"
 
diff --git a/board/freescale/t1040qds/eth.c b/board/freescale/t1040qds/eth.c
index 8c82934..8bf34fa 100644
--- 

[U-Boot] [Patch V6 07/18] net: fm: bug fix when CONFIG_PHYLIB not defined

[Gong Qianyu]

From: Shaohui Xie 

codes related to phylib operations should be wrapped by CONFIG_PHYLIB.

Signed-off-by: Shaohui Xie 
Signed-off-by: Gong Qianyu 
---
V6:
 - Fix all codes related to phylib to be wrapped by CONFIG_PHYLIB.
V5:
 - No change.
V4:
 - No change.
V3:
 - New patch.

 drivers/net/fm/eth.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/net/fm/eth.c b/drivers/net/fm/eth.c
index d7d064b..e262859 100644
--- a/drivers/net/fm/eth.c
+++ b/drivers/net/fm/eth.c
@@ -95,6 +95,7 @@ static void dtsec_init_phy(struct eth_device *dev)
dtsec_configure_serdes(fm_eth);
 }
 
+#ifdef CONFIG_PHYLIB
 static int tgec_is_fibre(struct eth_device *dev)
 {
struct fm_eth *fm = dev->priv;
@@ -105,6 +106,7 @@ static int tgec_is_fibre(struct eth_device *dev)
return hwconfig_arg_cmp(phyopt, "xfi");
 }
 #endif
+#endif
 
 static u16 muram_readw(u16 *addr)
 {
@@ -483,8 +485,10 @@ static void fm_eth_halt(struct eth_device *dev)
/* disable bmi Rx port */
bmi_rx_port_disable(fm_eth->rx_port);
 
+#ifdef CONFIG_PHYLIB
if (fm_eth->phydev)
phy_shutdown(fm_eth->phydev);
+#endif
 }
 
 static int fm_eth_send(struct eth_device *dev, void *buf, int len)
@@ -658,13 +662,15 @@ static int fm_eth_init_mac(struct fm_eth *fm_eth, struct 
ccsr_fman *reg)
 static int init_phy(struct eth_device *dev)
 {
struct fm_eth *fm_eth = dev->priv;
+#ifdef CONFIG_PHYLIB
struct phy_device *phydev = NULL;
u32 supported;
+#endif
 
-#ifdef CONFIG_PHYLIB
if (fm_eth->type == FM_ETH_1G_E)
dtsec_init_phy(dev);
 
+#ifdef CONFIG_PHYLIB
if (fm_eth->bus) {
phydev = phy_connect(fm_eth->bus, fm_eth->phyaddr, dev,
fm_eth->enet_if);
-- 
2.1.0.27.g96db324

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

[U-Boot] [Patch V6 10/18] net/fm: fix MDIO controller base on FMAN2

[Gong Qianyu]

From: Shaohui Xie 

MDIO controller base on FMAN2 was defined as CONFIG_SYS_FSL_FM2_ADDR
plus offset, but CONFIG_SYS_FSL_FM2_ADDR only defined when there are two
FMANs, so we should only define MDIO controller base on FMAN2 when there
is FMAN2.

Signed-off-by: Shaohui Xie 
Signed-off-by: Mingkai Hu 
Signed-off-by: Gong Qianyu 
---
V6:
 - No change.
V5:
 - No change.
V4:
 - No change.
V3:
 - No change.
V2:
 - No change.

 include/fm_eth.h | 17 +
 1 file changed, 17 insertions(+)

diff --git a/include/fm_eth.h b/include/fm_eth.h
index 3e1b9f4..d43f801 100644
--- a/include/fm_eth.h
+++ b/include/fm_eth.h
@@ -45,8 +45,10 @@ enum fm_eth_type {
 #ifdef CONFIG_SYS_FMAN_V3
 #define CONFIG_SYS_FM1_DTSEC_MDIO_ADDR (CONFIG_SYS_FSL_FM1_ADDR + 0xfc000)
 #define CONFIG_SYS_FM1_TGEC_MDIO_ADDR  (CONFIG_SYS_FSL_FM1_ADDR + 0xfd000)
+#if (CONFIG_SYS_NUM_FMAN == 2)
 #define CONFIG_SYS_FM2_DTSEC_MDIO_ADDR (CONFIG_SYS_FSL_FM2_ADDR + 0xfc000)
 #define CONFIG_SYS_FM2_TGEC_MDIO_ADDR  (CONFIG_SYS_FSL_FM2_ADDR + 0xfd000)
+#endif
 #else
 #define CONFIG_SYS_FM1_DTSEC1_MDIO_ADDR(CONFIG_SYS_FSL_FM1_ADDR + 
0xe1120)
 #define CONFIG_SYS_FM1_TGEC_MDIO_ADDR  (CONFIG_SYS_FSL_FM1_ADDR + 0xf1000)
@@ -89,6 +91,7 @@ enum fm_eth_type {
 offsetof(struct ccsr_fman, memac[n-1]),\
 }
 #else
+#if (CONFIG_SYS_NUM_FMAN == 2)
 #define FM_TGEC_INFO_INITIALIZER(idx, n) \
 {  \
FM_ETH_INFO_INITIALIZER(idx, CONFIG_SYS_FM2_TGEC_MDIO_ADDR) \
@@ -101,6 +104,20 @@ enum fm_eth_type {
.compat_offset  = CONFIG_SYS_FSL_FM##idx##_OFFSET + \
offsetof(struct ccsr_fman, memac[n-1+8]),\
 }
+#else
+#define FM_TGEC_INFO_INITIALIZER(idx, n) \
+{  \
+   FM_ETH_INFO_INITIALIZER(idx, CONFIG_SYS_FM1_TGEC_MDIO_ADDR) \
+   .index  = idx,  \
+   .num= n - 1,\
+   .type   = FM_ETH_10G_E, \
+   .port   = FM##idx##_10GEC##n,   \
+   .rx_port_id = RX_PORT_10G_BASE + n - 1, \
+   .tx_port_id = TX_PORT_10G_BASE + n - 1, \
+   .compat_offset  = CONFIG_SYS_FSL_FM##idx##_OFFSET + \
+   offsetof(struct ccsr_fman, memac[n-1+8]),\
+}
+#endif
 #endif
 
 #if (CONFIG_SYS_NUM_FM1_10GEC >= 3)
-- 
2.1.0.27.g96db324

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

[U-Boot] [Patch V6 16/18] armv8/ls1043ardb: esdhc: Add esdhc support for ls1043ardb

[Gong Qianyu]

From: Yangbo Lu 

This patch adds esdhc support for ls1043ardb.

Signed-off-by: Yangbo Lu 
Signed-off-by: Gong Qianyu 
---
V6:
 - No change.
V5:
 - No change.
V4:
 - Use CONFIG_FSL_ESDHC to enable get_sdhc_freq().
 - Merge lsch2 and lsch3 into layerscape.
V3:
 - No change.
V2:
 - No change.

 .../arm/cpu/armv8/fsl-layerscape/fsl_lsch2_speed.c | 22 +-
 board/freescale/ls1043ardb/ls1043ardb.c|  1 +
 drivers/mmc/fsl_esdhc.c| 12 ++--
 include/configs/ls1043a_common.h   | 11 +++
 include/fsl_esdhc.h|  2 +-
 5 files changed, 40 insertions(+), 8 deletions(-)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_speed.c 
b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_speed.c
index 9d5bbe7..6f6a588 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_speed.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_speed.c
@@ -25,7 +25,7 @@ void get_sys_info(struct sys_info *sys_info)
struct fsl_ifc ifc_regs = {(void *)CONFIG_SYS_IFC_ADDR, (void *)NULL};
u32 ccr;
 #endif
-#ifdef CONFIG_SYS_DPAA_FMAN
+#if defined(CONFIG_FSL_ESDHC) || defined(CONFIG_SYS_DPAA_FMAN)
u32 rcw_tmp;
 #endif
struct ccsr_clk *clk = (void *)(CONFIG_SYS_FSL_CLK_ADDR);
@@ -105,6 +105,11 @@ void get_sys_info(struct sys_info *sys_info)
 
 #define HWA_CGA_M2_CLK_SEL 0x0007
 #define HWA_CGA_M2_CLK_SHIFT   0
+#ifdef CONFIG_FSL_ESDHC
+   rcw_tmp = in_be32(>rcwsr[15]);
+   rcw_tmp = (rcw_tmp & HWA_CGA_M2_CLK_SEL) >> HWA_CGA_M2_CLK_SHIFT;
+   sys_info->freq_sdhc = freq_c_pll[1] / rcw_tmp;
+#endif
 
 #if defined(CONFIG_FSL_IFC)
ccr = ifc_in32(_regs.gregs->ifc_ccr);
@@ -123,6 +128,10 @@ int get_clocks(void)
gd->bus_clk = sys_info.freq_systembus;
gd->mem_clk = sys_info.freq_ddrbus;
 
+#ifdef CONFIG_FSL_ESDHC
+   gd->arch.sdhc_clk = sys_info.freq_sdhc;
+#endif
+
if (gd->cpu_clk != 0)
return 0;
else
@@ -139,6 +148,13 @@ ulong get_ddr_freq(ulong dummy)
return gd->mem_clk;
 }
 
+#ifdef CONFIG_FSL_ESDHC
+int get_sdhc_freq(ulong dummy)
+{
+   return gd->arch.sdhc_clk;
+}
+#endif
+
 int get_serial_clock(void)
 {
return gd->bus_clk;
@@ -149,6 +165,10 @@ unsigned int mxc_get_clock(enum mxc_clock clk)
switch (clk) {
case MXC_I2C_CLK:
return get_bus_freq(0);
+#if defined(CONFIG_FSL_ESDHC)
+   case MXC_ESDHC_CLK:
+   return get_sdhc_freq(0);
+#endif
case MXC_DSPI_CLK:
return get_bus_freq(0);
case MXC_UART_CLK:
diff --git a/board/freescale/ls1043ardb/ls1043ardb.c 
b/board/freescale/ls1043ardb/ls1043ardb.c
index 6c0dd3f..461a195 100644
--- a/board/freescale/ls1043ardb/ls1043ardb.c
+++ b/board/freescale/ls1043ardb/ls1043ardb.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
index 0b37002..471d6ee 100644
--- a/drivers/mmc/fsl_esdhc.c
+++ b/drivers/mmc/fsl_esdhc.c
@@ -106,7 +106,7 @@ static uint esdhc_xfertyp(struct mmc_cmd *cmd, struct 
mmc_data *data)
xfertyp |= XFERTYP_RSPTYP_48;
 
 #if defined(CONFIG_MX53) || defined(CONFIG_PPC_T4240) || \
-   defined(CONFIG_LS102XA) || defined(CONFIG_LS2085A)
+   defined(CONFIG_LS102XA) || defined(CONFIG_FSL_LAYERSCAPE)
if (cmd->cmdidx == MMC_CMD_STOP_TRANSMISSION)
xfertyp |= XFERTYP_CMDTYP_ABORT;
 #endif
@@ -184,7 +184,7 @@ static int esdhc_setup_data(struct mmc *mmc, struct 
mmc_data *data)
int timeout;
struct fsl_esdhc_cfg *cfg = mmc->priv;
struct fsl_esdhc *regs = (struct fsl_esdhc *)cfg->esdhc_base;
-#ifdef CONFIG_LS2085A
+#ifdef CONFIG_FSL_LAYERSCAPE
dma_addr_t addr;
 #endif
uint wml_value;
@@ -197,7 +197,7 @@ static int esdhc_setup_data(struct mmc *mmc, struct 
mmc_data *data)
 
esdhc_clrsetbits32(>wml, WML_RD_WML_MASK, wml_value);
 #ifndef CONFIG_SYS_FSL_ESDHC_USE_PIO
-#ifdef CONFIG_LS2085A
+#ifdef CONFIG_FSL_LAYERSCAPE
addr = virt_to_phys((void *)(data->dest));
if (upper_32_bits(addr))
printf("Error found for upper 32 bits\n");
@@ -223,7 +223,7 @@ static int esdhc_setup_data(struct mmc *mmc, struct 
mmc_data *data)
esdhc_clrsetbits32(>wml, WML_WR_WML_MASK,
wml_value << 16);
 #ifndef CONFIG_SYS_FSL_ESDHC_USE_PIO
-#ifdef CONFIG_LS2085A
+#ifdef CONFIG_FSL_LAYERSCAPE
addr = virt_to_phys((void *)(data->src));
if (upper_32_bits(addr))
printf("Error found for upper 32 bits\n");
@@ -277,7 +277,7 @@ static int esdhc_setup_data(struct mmc *mmc, struct 
mmc_data *data)
 static void check_and_invalidate_dcache_range
(struct mmc_cmd *cmd,
 

[U-Boot] [Patch V6 05/18] net/fm: Add support for 64-bit platforms

[Gong Qianyu]

From: Hou Zhiqiang 

The FMan IM driver is developed for 32-bit platfroms and isn't
friendly to 64-bit platforms, so do the minimal refactor:

1. Refine the MURAM management and access.
2. Correct the initialization and operations for QDs and BDs.

Signed-off-by: Hou Zhiqiang 
Signed-off-by: Gong Qianyu 
---
V6:
 - No change.
V5:
 - No change.
V4:
 - No change.
V3:
 - New patch.

 drivers/net/fm/eth.c | 61 
 drivers/net/fm/fm.c  | 20 ++---
 drivers/net/fm/fm.h  | 12 +--
 3 files changed, 60 insertions(+), 33 deletions(-)

diff --git a/drivers/net/fm/eth.c b/drivers/net/fm/eth.c
index ad02c66..6451dce 100644
--- a/drivers/net/fm/eth.c
+++ b/drivers/net/fm/eth.c
@@ -108,12 +108,12 @@ static int tgec_is_fibre(struct eth_device *dev)
 
 static u16 muram_readw(u16 *addr)
 {
-   u32 base = (u32)addr & ~0x3;
-   u32 val32 = in_be32((u32 *)base);
+   ulong base = (ulong)addr & ~0x3UL;
+   u32 val32 = in_be32((void *)base);
int byte_pos;
u16 ret;
 
-   byte_pos = (u32)addr & 0x3;
+   byte_pos = (ulong)addr & 0x3UL;
if (byte_pos)
ret = (u16)(val32 & 0x);
else
@@ -124,18 +124,18 @@ static u16 muram_readw(u16 *addr)
 
 static void muram_writew(u16 *addr, u16 val)
 {
-   u32 base = (u32)addr & ~0x3;
-   u32 org32 = in_be32((u32 *)base);
+   ulong base = (ulong)addr & ~0x3UL;
+   u32 org32 = in_be32((void *)base);
u32 val32;
int byte_pos;
 
-   byte_pos = (u32)addr & 0x3;
+   byte_pos = (ulong)addr & 0x3UL;
if (byte_pos)
val32 = (org32 & 0x) | val;
else
val32 = (org32 & 0x) | ((u32)val << 16);
 
-   out_be32((u32 *)base, val32);
+   out_be32((void *)base, val32);
 }
 
 static void bmi_rx_port_disable(struct fm_bmi_rx_port *rx_port)
@@ -199,6 +199,8 @@ static int fm_eth_rx_port_parameter_init(struct fm_eth 
*fm_eth)
u32 pram_page_offset;
void *rx_bd_ring_base;
void *rx_buf_pool;
+   u32 bd_ring_base_lo, bd_ring_base_hi;
+   u32 buf_lo, buf_hi;
struct fm_port_bd *rxbd;
struct fm_port_qd *rxqd;
struct fm_bmi_rx_port *bmi_rx_port = fm_eth->rx_port;
@@ -207,10 +209,15 @@ static int fm_eth_rx_port_parameter_init(struct fm_eth 
*fm_eth)
/* alloc global parameter ram at MURAM */
pram = (struct fm_port_global_pram *)fm_muram_alloc(fm_eth->fm_index,
FM_PRAM_SIZE, FM_PRAM_ALIGN);
+   if (!pram) {
+   printf("%s: No muram for Rx global parameter\n", __func__);
+   return 0;
+   }
+
fm_eth->rx_pram = pram;
 
/* parameter page offset to MURAM */
-   pram_page_offset = (u32)pram - fm_muram_base(fm_eth->fm_index);
+   pram_page_offset = (void *)pram - fm_muram_base(fm_eth->fm_index);
 
/* enable global mode- snooping data buffers and BDs */
out_be32(>mode, PRAM_MODE_GLOBAL);
@@ -234,6 +241,7 @@ static int fm_eth_rx_port_parameter_init(struct fm_eth 
*fm_eth)
if (!rx_buf_pool)
return 0;
memset(rx_buf_pool, 0, MAX_RXBUF_LEN * RX_BD_RING_SIZE);
+   debug("%s: rx_buf_pool = %p\n", __func__, rx_buf_pool);
 
/* save them to fm_eth */
fm_eth->rx_bd_ring = rx_bd_ring_base;
@@ -245,17 +253,22 @@ static int fm_eth_rx_port_parameter_init(struct fm_eth 
*fm_eth)
for (i = 0; i < RX_BD_RING_SIZE; i++) {
muram_writew(>status, RxBD_EMPTY);
muram_writew(>len, 0);
-   muram_writew(>buf_ptr_hi, 0);
-   out_be32(>buf_ptr_lo, (u32)rx_buf_pool +
-   i * MAX_RXBUF_LEN);
+   buf_hi = upper_32_bits(virt_to_phys(rx_buf_pool +
+   i * MAX_RXBUF_LEN));
+   buf_lo = lower_32_bits(virt_to_phys(rx_buf_pool +
+   i * MAX_RXBUF_LEN));
+   muram_writew(>buf_ptr_hi, (u16)buf_hi);
+   out_be32(>buf_ptr_lo, buf_lo);
rxbd++;
}
 
/* set the Rx queue descriptor */
rxqd = >rxqd;
muram_writew(>gen, 0);
-   muram_writew(>bd_ring_base_hi, 0);
-   out_be32(>bd_ring_base_lo, (u32)rx_bd_ring_base);
+   bd_ring_base_hi = upper_32_bits(virt_to_phys(rx_bd_ring_base));
+   bd_ring_base_lo = lower_32_bits(virt_to_phys(rx_bd_ring_base));
+   muram_writew(>bd_ring_base_hi, (u16)bd_ring_base_hi);
+   out_be32(>bd_ring_base_lo, bd_ring_base_lo);
muram_writew(>bd_ring_size, sizeof(struct fm_port_bd)
* RX_BD_RING_SIZE);
muram_writew(>offset_in, 0);
@@ -272,6 +285,7 @@ static int fm_eth_tx_port_parameter_init(struct fm_eth 
*fm_eth)
struct fm_port_global_pram *pram;
u32 pram_page_offset;
void *tx_bd_ring_base;
+

Re: [U-Boot] [PATCH] nios2: add README.nios2

[Marek Vasut]

On Monday, October 19, 2015 at 08:06:16 AM, Thomas Chou wrote:

Hi!

> Add README.nios2 about how to add nios2 boards to u-boot.
> 
> Signed-off-by: Thomas Chou 
> ---
>  doc/README.nios2 | 86
>  1 file changed,
> 86 insertions(+)
>  create mode 100644 doc/README.nios2
> 
> diff --git a/doc/README.nios2 b/doc/README.nios2
> new file mode 100644
> index 000..9f248ac
> --- /dev/null
> +++ b/doc/README.nios2
> @@ -0,0 +1,86 @@
> +Nios II is a 32-bit embedded-processor architecture designed
> +specifically for the Altera family of FPGAs.
> +
> +Please refer to the link for more information on Nios II,
> +https://www.altera.com/products/processors/overview.html
> +
> +Please refer to the link for Linux port and toolchains,
> +http://rocketboards.org/foswiki/view/Documentation/NiosIILinuxUserManual
> +
> +The Nios II port of u-boot is controlled by device tree. To add a new
> +board/configuration (eg, mysystem) to u-boot, you will need three files.
> +
> +1. The device tree source which descibe the hardware, dts file.
> +arch/nios2/dts/mysystem.dts
> +
> +2. Default configuration of Kconfig, defconfig file.
> +configs/mysystem_defconfig
> +
> +3. The legacy board header file.
> +include/configs/mysystem.h
> +
> +The device tree source must be generated from your qsys/sopc design file
> +using the sopc2dts tool. Then modified to fit your configuration. Please
> +find the sopc2dts download and usage at the wiki,
> +http://www.alterawiki.com/wiki/Sopc2dts
> +
> +java -jar sopc2dts.jar --force-altr -i mysystem.sopcinfo -o mysystem.dts
> +
> +You will need to add additional properties to the dts. Please find an
> +example at, arch/nios2/dts/3c120_devboard.dts.
> +
> +1. Add "u-boot,dm-pre-reloc" property to the cpu and the serial node
> +which you will use for console.

Explanation why or link to another document in doc/ would help here I think.

> +2. Add "stdout-path=..." property with your serial path to the chosen
> +node.
> +
> +Next, you will need a default config file. You may start with
> +nios2-generic_defconfig, modify the options and save it.
> +
> +make nios2-generic_defconfig
> +make menuconfig
> +make savedefconfig
> +cp defconfig configs/mysystem_defconfig
> +
> +You will need to change the names of board header file and device tree,
> +and select the drivers.
> +
> +Nios II architecture  --->
> +  (mysystem) Board header file
> +Device Tree Control  --->
> +  (mysystem) Default Device Tree for DT control
> +
> +There is a selection of "Provider of DTB for DT control" in the Device
> +Tree Control menu.
> +
> +( ) Separate DTB for DT control, will cat the dtb to end of u-boot
> +binary, output u-boot-dtb.bin. This should be used for production.
> +If you use boot copier, like epcs boot copier, make sure the copier
> +copies all the u-boot-dtb.bin, not just u-boot.bin.
> +
> +( ) Embedded DTB for DT control, will include the dtb inside the u-boot
> +binary. This is handy for development, eg, using gdb or nios2-download.
> +
> +The last thing, legacy board header file describes those config options
> +not covered in Kconfig yet. You may copy it from nios2-generic.h.
> +
> +cp include/configs/nios2-generic.h include/configs/mysystem.h
> +
> +Please change the sdram base and size to your board. The base should be

s/to your/to match your/

> +cached virtual address, for nios2 with mmu it is 0xCxxx- to
> +0xDxxx-.

MMU should be in capitals I think. And the address should use underscore instead
of dash, the dash is really confusing there.

> +#define CONFIG_SYS_SDRAM_BASE0xD000
> +#define CONFIG_SYS_SDRAM_SIZE0x0800
> +
> +You will need to change the environment variables location and setting,
> +too. You may change other configs to fit your board.
> +
> +After all these changes, you may build and test.
> +
> +export CROSS_COMPILE=nios2-elf-  (or nios2-linux-gnu-)
> +make mysystem_defconfig
> +make
> +
> +Enjoy!

Thanks for the README, it's really helpful!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/3] ARM: relocate: fix hang when CONFIG_ARMV7_SECURE_BASE

[Peng Fan]

Hi Albert,
On Mon, Oct 19, 2015 at 01:48:25PM +0200, Albert ARIBAUD wrote:
>Hello Peng,
>
>(cutting a bit through the previous mails quoting)
>
>> >This, in turn, leads to new questions:
>> >
>> >1. How is this PSCI code put in place? Is it bundled with the image,
>> >   with a specificy copy routine which puts it in place then locks the
>> Yeah.
>> >   memory range against writing? Or is it loaded in place by some other
>> >   agent than U-Boot, and how does this agent know what to put where?
>> 
>> In arch/arm/cpu/armv7/virt-v7.c, relocate_secure_section() does this job.
>> 
>> CONFIG_ARMV7_SECURE_BASE is the location that secure code will be copied
>> to. To ARMV7, PSCI code is bundled with the uboot image.
>
>Hmm, the 'relocate' part of the function name is a somewhat non-optimal
>choice, since the routine just copies data without modifying it.
>
>Looking at relocate_secure_section(), I see that it it is called long
>after the U-Boot code was relocated -- actually, it is called during
>bootm.

oh. You remind me, thanks. There maybe something wrong with my previous 
analysis.

I am not the one who finds the issue, just my understanding.
The data abort may be triggered by line 104 or line 106.
96 fixloop:
97 ldmia   r2!, {r0-r1}/* (r0,r1) <- (SRC location,fixup) */
98 and r1, r1, #0xff   
99 cmp r1, #23 /* relative fixup? */
100 bne fixnext
101
102 /* relative fix: increase location by offset */
103 add r0, r0, r4
104 ldr r1, [r0]
105 add r1, r1, r4
106 str r1, [r0]

At line 104 or 106, the value of r0 may be an address that can not be accessed
which trigger data abort.

Frank, am I right?

I'll set up one board to test this.

>
>This means that for any one of the other boards around that seem to use
>PSCI, either "their" PSCI code does not have any relocations (which I
>doubt), or it has but they don't cause any data abort when done by the
>relocate_code() routine.

There maybe something wrong from me. See above.

>
>So what's the difference between those and your board? My bet is that
>their CONFIG_ARMV7_SECURE_BASE is not write-protected at the time the
>relocate_code() routine executes (whereas on your board it is), and
>will be unlocked in some way by the time relocate_secure_section()
>executes.
>
>I'm not saying that the correct solution would be to enable write
>access to CONFIG_ARMV7_SECURE_BASE before running relocate_code(),
>because doing that would be obviously wrong: relocate_code() would try
>to fix code which is not there yet.

Yeah. This is true, relocate_code may fix code which is not there.

>
>I'm just saying that's what actually happens, and if I am right, then
>it confirms that the correct fix is to not let relocations to the
>secure stay in the U-Boot ELF, or better yet, to not let them happen to
>boot [pun half-intended].

They do not happen to boot. My bad. See above.

>
>> CONFIG_ARMV7_SECURE_BASE is the location that secure code will be copied
>> to. To ARMV7, PSCI code is bundled with the uboot image.
>> 
>> >
>> >2. Does this code and the relocatable image refer to symbols of one
>> >   another,
>> Yeah. There is asm function reference. You can see arch/arm/cpu/armv7/psci.S
>
>Looking at this file, I suspect that actually, PSCI is called through a
>software interrupt / exception vector, not through a function name, and
>the only symbolic relationship is via __secure_start and __secure_end
>-- and those must (and will) be correctly relocated along with the
>U-Boot image.
>
>> >or do they interact through an IPC independent of their
>> >   respective location (in which case, one wonders why they are built
>> >   into a single ELF file)?
>> 
>> This comes a question, why PSCI framework intergated into U-Boot? I have no 
>> idea.
>
>There could have been alternative designs, indeed. Here is the design
>now, so let's handle it.
>
>> >More generally... which target do you see this problem on? Reproducing
>> >the build myself would save both you and me some time, I guess. :)
>> 
>> Build target: mx7dsabresd
>> 
>> Needs to apply the three patches:
>> https://patchwork.ozlabs.org/patch/527040/
>> https://patchwork.ozlabs.org/patch/527038/
>> https://patchwork.ozlabs.org/patch/527039/
>> 
>> There is a small difference from my previous log, since my previous log use
>> 0x18 as the secure address, but the patches use 0x90 as the secure
>> address. But sure there will be relocation entry there.
>
>Thanks. I'll try and play with compiler / linker options, but from
>my own experience, this can be tricky. Meanwhile, I suggest you for for
>the not-too-quick-and-not-too-dirty linker script solution.
>
>> >Do you need these relocation records? If not, then just append the
>> >'*(.rel._secure*) input section spec (with a suitable comment) to
>> >the already existing DISCARD output section. By the way, doesn't this
>> >linker script change alone fix the data 

Re: [U-Boot] [PATCH] dfu: dfu_sf: Use the erase sector size for erase operations

[Lukasz Majewski]

Hi Tom,

> On Mon, Oct 19, 2015 at 6:07 AM, Lukasz Majewski
>  wrote:
> >> On Tue, Sep 22, 2015 at 4:46 AM, Lukasz Majewski
> >>  wrote:
> >> >> From: Fabio Estevam 
> >> >>
> >> >> SPI NOR flashes need to erase the entire sector size and we
> >> >> cannot pass any arbitrary length for the erase operation.
> >> >>
> >> >> To illustrate the problem:
> >> >>
> >> >> Copying data from PC to DFU device
> >> >> Download[=] 100%   478208 bytes
> >> >> Download done.
> >> >> state(7) = dfuMANIFEST, status(0) = No error condition is
> >> >> present state(10) = dfuERROR, status(14) = Something went
> >> >> wrong, but the device does not know what it was
> >> >> Done!
> >> >>
> >> >> In this case, the binary has 478208 bytes and the M25P32 SPI NOR
> >> >> has an erase sector of 64kB.
> >> >>
> >> >> 478208  = 7 entire sectors of 64kiB + 19456 bytes.
> >> >>
> >> >> Erasing the first seven 64 kB sectors works fine, but when
> >> >> trying to erase the remainding 19456 causes problem and the
> >> >> board hangs.
> >> >>
> >> >> Fix the issue by always erasing with the erase sector size.
> >> >>
> >> >> Signed-off-by: Fabio Estevam 
> >>
> >> > Acked-by: Lukasz Majewski 
> >> >
> >> > Applied to u-boot-dfu tree.
> >> >
> >> > Thanks for your work.
> >> >
> >> > I'm looking forward for more patches :-)
> >>
> >> Any chance of getting this one applied for 2015.10?
> >
> > Probably not :-( since we have now -rc5.
> >
> > I plan to send pull request in the next merge window.
> >
> > My apologies, since I was busy with ELCE2015 preparation, so I've
> > forgotten to send early PR to Marek.
> 
> This has been acked in September and it is a very trivial change, why
> not include it?
> 

Two patches to be applied as fixes for dfu subsystem.

https://patchwork.ozlabs.org/patch/520827/
https://patchwork.ozlabs.org/patch/521575/


-- 
Best regards,

Lukasz Majewski

Samsung R Institute Poland (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v8 1/4] include: Add log2 and fls64 header fi

[Jagan Teki]

On 17 October 2015 at 02:11, Fabio Estevam  wrote:
> From: Fabio Estevam 
>
> Use the log2 and fls64 header files directly from the kernel.
>
> Signed-off-by: Fabio Estevam 
> ---
> Changes since v7:
> - None
>
>  include/asm-generic/bitops/fls64.h |  36 +++
>  include/linux/bitops.h |   9 ++
>  include/linux/log2.h   | 208 
> +
>  3 files changed, 253 insertions(+)
>  create mode 100644 include/asm-generic/bitops/fls64.h
>  create mode 100644 include/linux/log2.h
>
> diff --git a/include/asm-generic/bitops/fls64.h 
> b/include/asm-generic/bitops/fls64.h
> new file mode 100644
> index 000..86d403f
> --- /dev/null
> +++ b/include/asm-generic/bitops/fls64.h
> @@ -0,0 +1,36 @@
> +#ifndef _ASM_GENERIC_BITOPS_FLS64_H_
> +#define _ASM_GENERIC_BITOPS_FLS64_H_
> +
> +#include 
> +
> +/**
> + * fls64 - find last set bit in a 64-bit word
> + * @x: the word to search
> + *
> + * This is defined in a similar way as the libc and compiler builtin
> + * ffsll, but returns the position of the most significant set bit.
> + *
> + * fls64(value) returns 0 if value is 0 or the position of the last
> + * set bit if value is nonzero. The last (most significant) bit is
> + * at position 64.
> + */
> +#if BITS_PER_LONG == 32
> +static inline int fls64(__u64 x)
> +{
> +   __u32 h = x >> 32;
> +   if (h)
> +   return fls(h) + 32;
> +   return fls(x);
> +}
> +#elif BITS_PER_LONG == 64
> +static inline int fls64(__u64 x)
> +{
> +   if (x == 0)
> +   return 0;
> +   return __fls(x) + 1;
> +}
> +#else
> +#error BITS_PER_LONG not 32 or 64
> +#endif
> +
> +#endif /* _ASM_GENERIC_BITOPS_FLS64_H_ */
> diff --git a/include/linux/bitops.h b/include/linux/bitops.h
> index 7d30ace..647733f 100644
> --- a/include/linux/bitops.h
> +++ b/include/linux/bitops.h
> @@ -129,6 +129,15 @@ static inline unsigned int generic_hweight8(unsigned int 
> w)
>  # define fls generic_fls
>  #endif
>
> +#include 

Please check this include, we can't assume to use generic one in
common header file there is one more fls64 from powerpc?

> +
> +static inline unsigned fls_long(unsigned long l)
> +{
> +   if (sizeof(l) == 4)
> +   return fls(l);
> +   return fls64(l);
> +}
> +
>  /**
>   * __set_bit - Set a bit in memory
>   * @nr: the bit to set
> diff --git a/include/linux/log2.h b/include/linux/log2.h
> new file mode 100644
> index 000..fd7ff3d
> --- /dev/null
> +++ b/include/linux/log2.h
> @@ -0,0 +1,208 @@
> +/* Integer base 2 logarithm calculation
> + *
> + * Copyright (C) 2006 Red Hat, Inc. All Rights Reserved.
> + * Written by David Howells (dhowe...@redhat.com)
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version
> + * 2 of the License, or (at your option) any later version.
> + */

Wolfgang Denk/Tom,

This file is copied from Linux, will this license notes will also be
same or any changes?

> +
> +#ifndef _LINUX_LOG2_H
> +#define _LINUX_LOG2_H
> +
> +#include 
> +#include 
> +
> +/*
> + * deal with unrepresentable constant logarithms
> + */
> +extern __attribute__((const, noreturn))
> +int ilog2_NaN(void);
> +
> +/*
> + * non-constant log of base 2 calculators
> + * - the arch may override these in asm/bitops.h if they can be implemented
> + *   more efficiently than using fls() and fls64()
> + * - the arch is not required to handle n==0 if implementing the fallback
> + */
> +#ifndef CONFIG_ARCH_HAS_ILOG2_U32
> +static inline __attribute__((const))
> +int __ilog2_u32(u32 n)
> +{
> +   return fls(n) - 1;
> +}
> +#endif
> +
> +#ifndef CONFIG_ARCH_HAS_ILOG2_U64
> +static inline __attribute__((const))
> +int __ilog2_u64(u64 n)
> +{
> +   return fls64(n) - 1;
> +}
> +#endif
> +
> +/*
> + *  Determine whether some value is a power of two, where zero is
> + * *not* considered a power of two.
> + */
> +
> +static inline __attribute__((const))
> +bool is_power_of_2(unsigned long n)
> +{
> +   return (n != 0 && ((n & (n - 1)) == 0));
> +}
> +
> +/*
> + * round up to nearest power of two
> + */
> +static inline __attribute__((const))
> +unsigned long __roundup_pow_of_two(unsigned long n)
> +{
> +   return 1UL << fls_long(n - 1);
> +}
> +
> +/*
> + * round down to nearest power of two
> + */
> +static inline __attribute__((const))
> +unsigned long __rounddown_pow_of_two(unsigned long n)
> +{
> +   return 1UL << (fls_long(n) - 1);
> +}
> +
> +/**
> + * ilog2 - log of base 2 of 32-bit or a 64-bit unsigned value
> + * @n - parameter
> + *
> + * constant-capable log of base 2 calculation
> + * - this can be used to initialise global variables from constant data, 
> hence
> + *   the massive ternary operator construction
> + *
> + * selects the appropriately-sized optimised version 

[U-Boot] [Patch V6 11/18] armv8/fsl_lsch3: Change arch to fsl-layerscape

[Gong Qianyu]

From: Mingkai Hu 

There are two LS series processors are built on ARMv8 Layersacpe
architecture currently, LS2085A and LS1043A. They are based on
ARMv8 core although use different chassis, so create fsl-layerscape
to refactor the common code for the LS series processors which also
paves the way for adding LS1043A platform.

Signed-off-by: Mingkai Hu 
Signed-off-by: Gong Qianyu 
---
V6:
 - Remove GIC SMMU TZPC macros from ls2085a_common.h to config.h.
 - Modify fsl_lsch3_wake_secondary_cores() to 
fsl_layerscape_wake_seconday_cores()
 - Fix lsch3->layerscape changes for ls2085a emu and simu. 
V5:
 - Move LS2085A ddr macros out of soc #ifdef.
 - Move macros and structs from cpu.c to cpu.h.
 - Wrap le32 and be32 functions for ccsr gur and scfg. Defined in soc.h
 - Modify fsl-layerscape/Makefile.
V4:
 - New patch.

 arch/arm/cpu/armv8/Makefile|   2 +-
 arch/arm/cpu/armv8/fsl-layerscape/Makefile |  21 ++
 .../README => fsl-layerscape/README.lsch3} |   2 +-
 .../cpu/armv8/{fsl-lsch3 => fsl-layerscape}/cpu.c  | 248 ++---
 .../cpu/armv8/{fsl-lsch3 => fsl-layerscape}/cpu.h  |   2 +-
 .../cpu/armv8/{fsl-lsch3 => fsl-layerscape}/fdt.c  |  17 +-
 .../fsl_lsch3_serdes.c |   8 +-
 .../speed.c => fsl-layerscape/fsl_lsch3_speed.c}   |  12 +-
 .../armv8/{fsl-lsch3 => fsl-layerscape}/lowlevel.S |  14 +-
 .../{fsl-lsch3 => fsl-layerscape}/ls2085a_serdes.c |   3 +-
 .../cpu/armv8/{fsl-lsch3 => fsl-layerscape}/mp.c   |  16 +-
 .../cpu/armv8/{fsl-lsch3 => fsl-layerscape}/soc.c  |  35 +--
 arch/arm/cpu/armv8/fsl-layerscape/spl.c|  76 +++
 arch/arm/cpu/armv8/fsl-lsch3/Makefile  |  13 --
 arch/arm/cpu/armv8/fsl-lsch3/speed.h   |   7 -
 .../clock.h|   8 +-
 arch/arm/include/asm/arch-fsl-layerscape/config.h  |  96 
 arch/arm/include/asm/arch-fsl-layerscape/cpu.h | 165 ++
 .../{arch-fsl-lsch3 => arch-fsl-layerscape}/fdt.h  |   4 +
 .../fsl_serdes.h   |  11 +-
 .../immap_lsch3.h  | 119 --
 .../arm/include/asm/arch-fsl-layerscape/imx-regs.h |  55 +
 .../ls2085a_stream_id.h|   0
 arch/arm/include/asm/arch-fsl-layerscape/mmu.h |  10 +
 .../asm/arch-fsl-layerscape}/mp.h  |  10 +-
 .../{arch-fsl-lsch3 => arch-fsl-layerscape}/soc.h  |  21 +-
 arch/arm/include/asm/arch-fsl-layerscape/speed.h   |  10 +
 arch/arm/include/asm/arch-fsl-lsch3/config.h   | 185 ---
 arch/arm/include/asm/arch-fsl-lsch3/gpio.h |   9 -
 arch/arm/include/asm/arch-fsl-lsch3/imx-regs.h |  13 --
 arch/arm/include/asm/config.h  |   7 +-
 board/freescale/ls2085a/Kconfig|   4 +-
 board/freescale/ls2085a/ls2085a.c  |   2 +-
 board/freescale/ls2085aqds/Kconfig |   2 +-
 board/freescale/ls2085aqds/eth.c   |   1 -
 board/freescale/ls2085aqds/ls2085aqds.c|   2 +-
 board/freescale/ls2085ardb/Kconfig |   2 +-
 board/freescale/ls2085ardb/eth_ls2085rdb.c |   1 -
 board/freescale/ls2085ardb/ls2085ardb.c|   2 +-
 drivers/i2c/mxc_i2c.c  |   4 +-
 drivers/misc/fsl_debug_server.c|   1 -
 drivers/net/ldpaa_eth/ls2085a.c|   2 -
 drivers/pci/pcie_layerscape.c  |   4 +-
 include/common.h   |   3 +
 include/configs/ls2085a_common.h   |  10 +-
 45 files changed, 713 insertions(+), 526 deletions(-)

diff --git a/arch/arm/cpu/armv8/Makefile b/arch/arm/cpu/armv8/Makefile
index adb11b3..48c041b 100644
--- a/arch/arm/cpu/armv8/Makefile
+++ b/arch/arm/cpu/armv8/Makefile
@@ -15,6 +15,6 @@ obj-y += cache.o
 obj-y  += tlb.o
 obj-y  += transition.o
 
-obj-$(CONFIG_FSL_LSCH3) += fsl-lsch3/
+obj-$(CONFIG_FSL_LAYERSCAPE) += fsl-layerscape/
 obj-$(CONFIG_ARCH_ZYNQMP) += zynqmp/
 obj-$(CONFIG_TARGET_HIKEY) += hisilicon/
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Makefile 
b/arch/arm/cpu/armv8/fsl-layerscape/Makefile
new file mode 100644
index 000..ccb3aa5
--- /dev/null
+++ b/arch/arm/cpu/armv8/fsl-layerscape/Makefile
@@ -0,0 +1,21 @@
+#
+# Copyright 2014-2015, Freescale Semiconductor
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+obj-y += cpu.o
+obj-y += lowlevel.o
+obj-y += soc.o
+obj-$(CONFIG_MP) += mp.o
+obj-$(CONFIG_OF_LIBFDT) += fdt.o
+obj-$(CONFIG_SPL) += spl.o
+
+ifneq ($(CONFIG_FSL_LSCH3),)
+obj-y += fsl_lsch3_speed.o
+obj-$(CONFIG_SYS_HAS_SERDES) += fsl_lsch3_serdes.o
+endif
+
+ifneq ($(CONFIG_LS2085A),)
+obj-$(CONFIG_SYS_HAS_SERDES) += ls2085a_serdes.o
+endif
diff --git a/arch/arm/cpu/armv8/fsl-lsch3/README 
b/arch/arm/cpu/armv8/fsl-layerscape/README.lsch3
similarity index 99%
rename from 

[U-Boot] [Patch V6 18/18] armv8/ls1043a: Enable secondary cores

[Gong Qianyu]

From: Hou Zhiqiang 

After the secondary cores enter U-Boot, use CONFIG_ARMV8_MULTIENTRY to
make secondary cores to excute in spin loop.

Signed-off-by: Hou Zhiqiang 
Signed-off-by: Mingkai Hu 
Signed-off-by: Gong Qianyu 
---
V6:
 - New patch.

 arch/arm/Kconfig   |  1 +
 arch/arm/cpu/armv8/fsl-layerscape/mp.c | 14 ++
 include/configs/ls1043a_common.h   |  3 +++
 3 files changed, 18 insertions(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 6584e85..6e30a5d 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -634,6 +634,7 @@ config TARGET_LS1021ATWR
 config TARGET_LS1043ARDB
bool "Support ls1043ardb"
select ARM64
+   select ARMV8_MULTIENTRY
select SUPPORT_SPL
help
  Support for Freescale LS1043ARDB platform.
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/mp.c 
b/arch/arm/cpu/armv8/fsl-layerscape/mp.c
index 1b13d32..0d600db 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/mp.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/mp.c
@@ -25,7 +25,11 @@ phys_addr_t determine_mp_bootpg(void)
 int fsl_layerscape_wake_seconday_cores(void)
 {
struct ccsr_gur __iomem *gur = (void *)(CONFIG_SYS_FSL_GUTS_ADDR);
+#ifdef CONFIG_FSL_LSCH3
struct ccsr_reset __iomem *rst = (void *)(CONFIG_SYS_FSL_RST_ADDR);
+#elif defined(CONFIG_FSL_LSCH2)
+   struct ccsr_scfg __iomem *scfg = (void *)(CONFIG_SYS_FSL_SCFG_ADDR);
+#endif
u32 cores, cpu_up_mask = 1;
int i, timeout = 10;
u64 *table = get_spin_tbl_addr();
@@ -48,13 +52,23 @@ int fsl_layerscape_wake_seconday_cores(void)
 
printf("Waking secondary cores to start from %lx\n", gd->relocaddr);
 
+#ifdef CONFIG_FSL_LSCH3
gur_out32(>bootlocptrh, (u32)(gd->relocaddr >> 32));
gur_out32(>bootlocptrl, (u32)gd->relocaddr);
gur_out32(>scratchrw[6], 1);
asm volatile("dsb st" : : : "memory");
rst->brrl = cores;
asm volatile("dsb st" : : : "memory");
+#elif defined(CONFIG_FSL_LSCH2)
+   scfg_out32(>scratchrw[0], (u32)(gd->relocaddr >> 32));
+   scfg_out32(>scratchrw[1], (u32)gd->relocaddr);
+   asm volatile("dsb st" : : : "memory");
+   gur_out32(>brrl, cores);
+   asm volatile("dsb st" : : : "memory");
 
+   /* Bootup online cores */
+   scfg_out32(>corebcr, cores);
+#endif
/* This is needed as a precautionary measure.
 * If some code before this has accidentally  released the secondary
 * cores then the pre-bootloader code will trap them in a "wfe" unless
diff --git a/include/configs/ls1043a_common.h b/include/configs/ls1043a_common.h
index 5b61fcc..d245fc2 100644
--- a/include/configs/ls1043a_common.h
+++ b/include/configs/ls1043a_common.h
@@ -13,6 +13,7 @@
 #define CONFIG_FSL_LAYERSCAPE
 #define CONFIG_FSL_LSCH2
 #define CONFIG_LS1043A
+#define CONFIG_MP
 #define CONFIG_FSL_CLK
 #define CONFIG_GICV2
 
@@ -46,6 +47,8 @@
 #define CONFIG_SYS_FSL_DDR_SDRAM_BASE_PHY  0
 #define CONFIG_SYS_SDRAM_BASE  CONFIG_SYS_DDR_SDRAM_BASE
 
+#define CPU_RELEASE_ADDR   secondary_boot_func
+
 /* Generic Timer Definitions */
 #define COUNTER_FREQUENCY  2500/* 25MHz */
 
-- 
2.1.0.27.g96db324

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

Re: [U-Boot] [PATCH v7 5/9] arm: serial: Add ability to use pre-initialized UARTs

[Simon Glass]

Hi Linus,

On 19 October 2015 at 01:15, Linus Walleij  wrote:
> On Sat, Oct 17, 2015 at 12:27 AM, Simon Glass  wrote:
>> On 16 October 2015 at 15:23, Linus Walleij  wrote:
>
>>> Again: get this merged in the Linux kernel FIRST. Is it?
>>
>> We had a little bit of a chat about this at ELCE. It would be great to
>> get these changes merged with the kernel but the amount of
>> push-back/energy it requires is still excessive IMO. Any thoughts?
>
> I'm sorry but DT is standardization, and while I know how stinky it is to
> be first somewhere and having to pave the road for everyone else,
> in the long run it's worth it. I think when we switched the entire kernel
> to DT it was to get "more order", and this is the cost that comes with
> that order: more review.
>
> I will go in and answer the comment on the DT mailing list so there is
> some push atleast.

Perhaps if we could see some movement then it would provide
encouragement to continue. So far I cannot recall seeing a single
U-Boot device tree change accepted in the 4 years I've been involved.
That's not to say it hasn't happened, and I hope it is just a
reflection on my memory rather than the difficulty level.

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

[U-Boot] [PATCH v4 4/8] arm: Switch aarch64 to using generic global_data setup

[Simon Glass]

There is quite a bit of assembler code that can be removed if we use the
generic global_data setup. Less arch-specific code makes it easier to add
new features and maintain the start-up code.

Drop the unneeded code and adjust the hooks in board_f.c to cope.

Tested on LS2085ARDB and LS2085AQDS (armv8 SoC).
Tested-by: York Sun 

Signed-off-by: Simon Glass 
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/arm/lib/crt0_64.S | 15 +++
 1 file changed, 3 insertions(+), 12 deletions(-)

diff --git a/arch/arm/lib/crt0_64.S b/arch/arm/lib/crt0_64.S
index 8b34e04..cef1c71 100644
--- a/arch/arm/lib/crt0_64.S
+++ b/arch/arm/lib/crt0_64.S
@@ -74,19 +74,10 @@ ENTRY(_main)
 #else
ldr x0, =(CONFIG_SYS_INIT_SP_ADDR)
 #endif
-   sub x18, x0, #GD_SIZE   /* allocate one GD above SP */
-   bic x18, x18, #0x7  /* 8-byte alignment for GD */
-zero_gd:
-   sub x0, x0, #0x8
-   str xzr, [x0]
-   cmp x0, x18
-   b.gtzero_gd
-#if defined(CONFIG_SYS_MALLOC_F_LEN)
-   ldr x0, =CONFIG_SYS_MALLOC_F_LEN
-   sub x0, x18, x0
-   str x0, [x18, #GD_MALLOC_BASE]
-#endif
bic sp, x0, #0xf/* 16-byte alignment for ABI compliance */
+   bl  board_init_f_mem
+   mov sp, x0
+
mov x0, #0
bl  board_init_f
 
-- 
2.6.0.rc2.230.g3dd15c0

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

[U-Boot] [PATCH v4 5/8] arm: Switch 32-bit ARM to using generic global_data setup

[Simon Glass]

There is quite a bit of assembler code that can be removed if we use the
generic global_data setup. Less arch-specific code makes it easier to add
new features and maintain the start-up code.

Drop the unneeded code and adjust the hooks in board_f.c to cope.

Signed-off-by: Simon Glass 
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/arm/lib/crt0.S | 28 
 1 file changed, 4 insertions(+), 24 deletions(-)

diff --git a/arch/arm/lib/crt0.S b/arch/arm/lib/crt0.S
index 4c3a94a..80548eb 100644
--- a/arch/arm/lib/crt0.S
+++ b/arch/arm/lib/crt0.S
@@ -82,31 +82,11 @@ ENTRY(_main)
 #else
bic sp, sp, #7  /* 8-byte alignment for ABI compliance */
 #endif
-   mov r2, sp
-   sub sp, sp, #GD_SIZE/* allocate one GD above SP */
-#if defined(CONFIG_CPU_V7M)/* v7M forbids using SP as BIC destination */
-   mov r3, sp
-   bic r3, r3, #7
-   mov sp, r3
-#else
-   bic sp, sp, #7  /* 8-byte alignment for ABI compliance */
-#endif
-   mov r9, sp  /* GD is above SP */
-   mov r1, sp
+   mov r0, sp
+   bl  board_init_f_mem
+   mov sp, r0
+
mov r0, #0
-clr_gd:
-   cmp r1, r2  /* while not at end of GD */
-#if defined(CONFIG_CPU_V7M)
-   itt lo
-#endif
-   strlo   r0, [r1]/* clear 32-bit GD word */
-   addlo   r1, r1, #4  /* move to next */
-   blo clr_gd
-#if defined(CONFIG_SYS_MALLOC_F_LEN)
-   sub sp, sp, #CONFIG_SYS_MALLOC_F_LEN
-   str sp, [r9, #GD_MALLOC_BASE]
-#endif
-   /* mov r0, #0 not needed due to above code */
bl  board_init_f
 
 #if ! defined(CONFIG_SPL_BUILD)
-- 
2.6.0.rc2.230.g3dd15c0

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

[U-Boot] [PATCH v4 7/8] zynq: Move SPL console init out of board_init_f()

[Simon Glass]

We should not init the console this early since it precludes using driver
model for the UART, since it is not set up at the start of board_init_f().
See the README for more information. The debug UART does not have this
restriction. If we want to do early init with the console on it can be done
in spl_board_init().

Move the preloader_console_init() call from board_init_f() to board_init_r().

Signed-off-by: Simon Glass 
Tested-by: Masahiro Yamada 
Tested-by: Michal Simek 
---

Changes in v4:
- Update commit message to address Albert's comments

Changes in v3:
- Rebase to master

Changes in v2: None

 arch/arm/mach-zynq/spl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-zynq/spl.c b/arch/arm/mach-zynq/spl.c
index e7df6d3..7bdac3b 100644
--- a/arch/arm/mach-zynq/spl.c
+++ b/arch/arm/mach-zynq/spl.c
@@ -20,7 +20,6 @@ void board_init_f(ulong dummy)
/* Clear the BSS. */
memset(__bss_start, 0, __bss_end - __bss_start);
 
-   preloader_console_init();
arch_cpu_init();
board_init_r(NULL, 0);
 }
@@ -28,6 +27,7 @@ void board_init_f(ulong dummy)
 #ifdef CONFIG_SPL_BOARD_INIT
 void spl_board_init(void)
 {
+   preloader_console_init();
board_init();
 }
 #endif
-- 
2.6.0.rc2.230.g3dd15c0

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

[U-Boot] [PATCH v4 2/8] board_init_f_mem(): Don't require memset()

[Simon Glass]

Unfortunately memset() is not always available, so provide a substitute when
needed.

Signed-off-by: Simon Glass 
---

Changes in v4:
- Remove the 'end' variable in board_init_f_mem()

Changes in v3: None
Changes in v2:
- Add comments as to why this is needed, deal with arch-specific memset()

 common/init/board_init.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/common/init/board_init.c b/common/init/board_init.c
index e7ebca7..1c6126d 100644
--- a/common/init/board_init.c
+++ b/common/init/board_init.c
@@ -11,6 +11,16 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
+/*
+ * It isn't trivial to figure out whether memcpy() exists. The arch-specific
+ * memcpy() is not normally available in SPL due to code size.
+ */
+#if !defined(CONFIG_SPL_BUILD) || \
+   (defined(CONFIG_SPL_LIBGENERIC_SUPPORT) && \
+   !defined(CONFIG_USE_ARCH_MEMSET))
+#define _USE_MEMCPY
+#endif
+
 /* Unfortunately x86 can't compile this code as gd cannot be assigned */
 #ifndef CONFIG_X86
 __weak void arch_setup_gd(struct global_data *gd_ptr)
@@ -22,6 +32,9 @@ __weak void arch_setup_gd(struct global_data *gd_ptr)
 ulong board_init_f_mem(ulong top)
 {
struct global_data *gd_ptr;
+#ifndef _USE_MEMCPY
+   int *ptr;
+#endif
 
/* Leave space for the stack we are running with now */
top -= 0x40;
@@ -29,7 +42,12 @@ ulong board_init_f_mem(ulong top)
top -= sizeof(struct global_data);
top = ALIGN(top, 16);
gd_ptr = (struct global_data *)top;
+#ifdef _USE_MEMCPY
memset(gd_ptr, '\0', sizeof(*gd));
+#else
+   for (ptr = (int *)gd_ptr; ptr < (int *)(gd_ptr + 1); )
+   *ptr++ = 0;
+#endif
arch_setup_gd(gd_ptr);
 
 #if defined(CONFIG_SYS_MALLOC_F)
-- 
2.6.0.rc2.230.g3dd15c0

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

[U-Boot] [PATCH v4 1/8] Move board_init_f_mem() into a common location

[Simon Glass]

This function will be used by both SPL and U-Boot proper. So move it into
a common place. Also change the #ifdef so that the early malloc() area is
not set up in SPL if CONFIG_SYS_SPL_MALLOC_START is defined. In that case
it would never actually be used, and just chews up stack space.

Signed-off-by: Simon Glass 
---

Changes in v4: None
Changes in v3: None
Changes in v2:
- Put this into common/init/ and just Makefiles accordingly

 common/Makefile  |  1 +
 common/board_f.c | 29 -
 common/init/Makefile |  7 +++
 common/init/board_init.c | 41 +
 scripts/Makefile.spl |  1 +
 5 files changed, 50 insertions(+), 29 deletions(-)
 create mode 100644 common/init/Makefile
 create mode 100644 common/init/board_init.c

diff --git a/common/Makefile b/common/Makefile
index 491c565..e2f9401 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -7,6 +7,7 @@
 
 # core
 ifndef CONFIG_SPL_BUILD
+obj-y += init/
 obj-y += main.o
 obj-y += exports.o
 obj-y += hash.o
diff --git a/common/board_f.c b/common/board_f.c
index 613332e..62570ab 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -1030,32 +1030,3 @@ void board_init_f_r(void)
hang();
 }
 #endif /* CONFIG_X86 */
-
-/* Unfortunately x86 can't compile this code as gd cannot be assigned */
-#ifndef CONFIG_X86
-__weak void arch_setup_gd(struct global_data *gd_ptr)
-{
-   gd = gd_ptr;
-}
-#endif /* !CONFIG_X86 */
-
-ulong board_init_f_mem(ulong top)
-{
-   struct global_data *gd_ptr;
-
-   /* Leave space for the stack we are running with now */
-   top -= 0x40;
-
-   top -= sizeof(struct global_data);
-   top = ALIGN(top, 16);
-   gd_ptr = (struct global_data *)top;
-   memset(gd_ptr, '\0', sizeof(*gd));
-   arch_setup_gd(gd_ptr);
-
-#ifdef CONFIG_SYS_MALLOC_F_LEN
-   top -= CONFIG_SYS_MALLOC_F_LEN;
-   gd->malloc_base = top;
-#endif
-
-   return top;
-}
diff --git a/common/init/Makefile b/common/init/Makefile
new file mode 100644
index 000..4902635
--- /dev/null
+++ b/common/init/Makefile
@@ -0,0 +1,7 @@
+#
+# Copyright (c) 2015 Google, Inc
+#
+# SPDX-License-Identifier:  GPL-2.0+
+#
+
+obj-y += board_init.o
diff --git a/common/init/board_init.c b/common/init/board_init.c
new file mode 100644
index 000..e7ebca7
--- /dev/null
+++ b/common/init/board_init.c
@@ -0,0 +1,41 @@
+/*
+ * Code shared between SPL and U-Boot proper
+ *
+ * Copyright (c) 2015 Google, Inc
+ * Written by Simon Glass 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/* Unfortunately x86 can't compile this code as gd cannot be assigned */
+#ifndef CONFIG_X86
+__weak void arch_setup_gd(struct global_data *gd_ptr)
+{
+   gd = gd_ptr;
+}
+#endif /* !CONFIG_X86 */
+
+ulong board_init_f_mem(ulong top)
+{
+   struct global_data *gd_ptr;
+
+   /* Leave space for the stack we are running with now */
+   top -= 0x40;
+
+   top -= sizeof(struct global_data);
+   top = ALIGN(top, 16);
+   gd_ptr = (struct global_data *)top;
+   memset(gd_ptr, '\0', sizeof(*gd));
+   arch_setup_gd(gd_ptr);
+
+#if defined(CONFIG_SYS_MALLOC_F)
+   top -= CONFIG_SYS_MALLOC_F_LEN;
+   gd->malloc_base = top;
+#endif
+
+   return top;
+}
diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
index 58442f1..2df93c8 100644
--- a/scripts/Makefile.spl
+++ b/scripts/Makefile.spl
@@ -52,6 +52,7 @@ libs-y += $(if $(BOARDDIR),board/$(BOARDDIR)/)
 libs-$(HAVE_VENDOR_COMMON_LIB) += board/$(VENDOR)/common/
 
 libs-$(CONFIG_SPL_FRAMEWORK) += common/spl/
+libs-y += common/init/
 libs-$(CONFIG_SPL_LIBCOMMON_SUPPORT) += common/
 libs-$(CONFIG_SPL_LIBDISK_SUPPORT) += disk/
 libs-y += drivers/
-- 
2.6.0.rc2.230.g3dd15c0

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

[U-Boot] [PATCH v4 0/8] arm: Tidy up early init

[Simon Glass]

This series collects the previous RFT patches I sent out.

https://patchwork.ozlabs.org/patch/508167/
https://patchwork.ozlabs.org/patch/508168/

It turns out that I originally sent a version of these in April:

https://patchwork.ozlabs.org/patch/461687/
https://patchwork.ozlabs.org/patch/461690/

so this series mirrors that one and includes the Zynq patches from that
series.

I have tested this on a few ARM platforms: Zynq Zybo, Beaglebone Black,
pcduino3 (sunxi), Jetson-TK1 (tegra).

Changes in v4:
- Remove the 'end' variable in board_init_f_mem()
- Update commit message to address Albert's comments
- Fully revert the commit (some changes were lost in v3)

Changes in v3:
- Rebase to master
- Rebase to master

Changes in v2:
- Put this into common/init/ and just Makefiles accordingly
- Add comments as to why this is needed, deal with arch-specific memset()

Simon Glass (8):
  Move board_init_f_mem() into a common location
  board_init_f_mem(): Don't require memset()
  board_init_f_mem(): Don't create an unused early malloc() area
  arm: Switch aarch64 to using generic global_data setup
  arm: Switch 32-bit ARM to using generic global_data setup
  microblaze: Add a TODO to call board_init_f_mem()
  zynq: Move SPL console init out of board_init_f()
  Revert "ARM: zynq: disable CONFIG_SYS_MALLOC_F to fix MMC boot"

 arch/arm/lib/crt0.S| 28 +++---
 arch/arm/lib/crt0_64.S | 15 ++
 arch/arm/mach-zynq/spl.c   |  2 +-
 arch/microblaze/cpu/start.S|  2 ++
 common/Makefile|  1 +
 common/board_f.c   | 29 --
 common/init/Makefile   |  7 +
 common/init/board_init.c   | 60 ++
 configs/zynq_microzed_defconfig|  1 -
 configs/zynq_zc702_defconfig   |  1 -
 configs/zynq_zc706_defconfig   |  1 -
 configs/zynq_zc70x_defconfig   |  1 -
 configs/zynq_zc770_xm010_defconfig |  1 -
 configs/zynq_zc770_xm011_defconfig |  1 -
 configs/zynq_zc770_xm012_defconfig |  1 -
 configs/zynq_zc770_xm013_defconfig |  1 -
 configs/zynq_zed_defconfig |  1 -
 configs/zynq_zybo_defconfig|  1 -
 scripts/Makefile.spl   |  1 +
 19 files changed, 79 insertions(+), 76 deletions(-)
 create mode 100644 common/init/Makefile
 create mode 100644 common/init/board_init.c

-- 
2.6.0.rc2.230.g3dd15c0

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

Re: [U-Boot] [PATCH] arm: sunxi: Add icnova-a20-swac defconfig and dts file

[Hans de Goede]

Hi,

On 19-10-15 12:38, Stefan Roese wrote:

Hi Hans,

On 17.10.2015 15:47, Hans de Goede wrote:

On 01-10-15 11:41, Stefan Roese wrote:

The ICnova-A20-SWAC is a baseboard, equipped with the ICnova-A20 SoM from
In-Circuit:

http://wiki.in-circuit.de/index.php5?title=ICnova_A20_SODIMM
http://linux-sunxi.org/In-Circuit_ICnova_A20

This patch adds support for this board, including ethernet, LCD and USB
support.


Thanks, I've merged this and it will show up in u-boot-sunxi/next soon.


Thanks.


I've made 2 small changes, see comments inline.





diff --git a/configs/icnova-a20-swac_defconfig
b/configs/icnova-a20-swac_defconfig
new file mode 100644
index 000..bd6e0c5
--- /dev/null
+++ b/configs/icnova-a20-swac_defconfig
@@ -0,0 +1,21 @@
+CONFIG_ARM=y
+CONFIG_ARCH_SUNXI=y
+CONFIG_MACH_SUN7I=y
+CONFIG_DRAM_CLK=384
+CONFIG_OLD_SUNXI_KERNEL_COMPAT=y


I've dropped this, I understand that you need it, but I do not believe that
ANY defconfig's as shipped upstream should set this.


Hmmm. I would prefer to have this added to the defconfig as well.
As it very likely leads to confusion when updating to a newer
U-Boot version which will not support the old kernel. Why not give
the users / maintainers the freedom to choose this for themselves?


Users are free to choose this, they can always enable this themselves
after running make foo_defconfig.

As for why not give the MAINTAINERS a choice on this, as said
I believe that we should not shipp defconfigs with this set by default
as part of mainline u-boot. The reasons for this are:

1) It is inconsistent with what we are doing for all other sunxi boards
where we are primarily targetting mainline

2) It communicates that CONFIG_OLD_SUNXI_KERNEL_COMPAT is an officially
supported end-user feature, where as in reality it is targeted at developers
who need to run an old sunxi kernel every now and then to see how that
kernel exactly programs certain registers, etc.

3) It means we ship with a severely crippled defconfig for mainline kernel
users, mainline users will loose both smp and hyp mode support on the A20
when this option is set.

I'm sorry but I'm not going to budge on this one, having
CONFIG_OLD_SUNXI_KERNEL_COMPAT=y in a defconfig is simply not acceptable
IMHO. It is not a board specific thing, and there are very good reasons
why it defaults to n in board/sunxi/Kconfig


+CONFIG_MMC0_CD_PIN="PI5"
+CONFIG_USB0_VBUS_PIN="PG11"
+CONFIG_USB0_VBUS_DET="PH7"
+CONFIG_USB1_VBUS_PIN="PG10"
+CONFIG_VIDEO_LCD_MODE="x:800,y:480,depth:24,pclk_khz:33000,le:45,ri:209,up:22,lo:22,hs:1,vs:1,sync:3,vmode:0"

+CONFIG_VIDEO_LCD_POWER="PH22"
+CONFIG_VIDEO_LCD_PANEL_LVDS=y
+CONFIG_DEFAULT_DEVICE_TREE="sun7i-a20-icnova-a20-swac"
+# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
+CONFIG_SPL=y
+CONFIG_SYS_EXTRA_OPTIONS="AXP209_POWER,SUNXI_GMAC,CMD_BMP,CMD_UNZIP"


I've dropped AXP209_POWER from these, in u-boot-sunxi/next this has been
turned into a Kconfig bool which is enabled by default on sun7i.


Understood.

Thanks,
Stefan


Regards,

Hans

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

[U-Boot] [Patch V6 12/18] armv8/fsl_lsch2: Add fsl_lsch2 SoC

[Gong Qianyu]

From: Mingkai Hu 

Freescale LayerScape with Chassis Generation 2 is a set of SoCs with
ARMv8 cores and 2rd generation of Chassis.

Signed-off-by: Li Yang 
Signed-off-by: Hou Zhiqiang 
Signed-off-by: Mingkai Hu 
Signed-off-by: Gong Qianyu 
---
V6:
 - Remove GIC SMMU macros back to config.h.
V5:
 - Move LS1043A ddr macros out of soc #ifdef.
 - Move macros and structs from cpu.c to cpu.h.
 - Wrap le32 and be32 functions for ccsr gur and scfg. Defined in soc.h
 - Modify fsl-layerscape/Makefile.
V4:
 - Add fsl_lsch2 to fsl-layerscape framework.
V3:
 - Update MMU table initialization to match the latest code.
 - Remove some dead code
 - Rename #include to #include
V2:
 - remove FSL_LS102xA_DEVDISR3_PCIE from immap_lsch2.h

 arch/arm/cpu/armv8/fsl-layerscape/Makefile |   5 +
 arch/arm/cpu/armv8/fsl-layerscape/README.lsch2 |  10 +
 arch/arm/cpu/armv8/fsl-layerscape/cpu.c|  13 +
 .../cpu/armv8/fsl-layerscape/fsl_lsch2_serdes.c| 117 +
 .../arm/cpu/armv8/fsl-layerscape/fsl_lsch2_speed.c | 137 +
 arch/arm/cpu/armv8/fsl-layerscape/soc.c|  17 +
 arch/arm/include/asm/arch-fsl-layerscape/config.h  |  47 ++
 arch/arm/include/asm/arch-fsl-layerscape/cpu.h |  64 +++
 .../include/asm/arch-fsl-layerscape/fsl_serdes.h   |  91 
 .../include/asm/arch-fsl-layerscape/immap_lsch2.h  | 555 +
 .../include/asm/arch-fsl-layerscape/ns_access.h| 158 ++
 arch/arm/include/asm/arch-fsl-layerscape/soc.h |   6 +
 arch/arm/include/asm/armv8/mmu.h   |   1 +
 include/common.h   |   3 +
 14 files changed, 1224 insertions(+)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Makefile 
b/arch/arm/cpu/armv8/fsl-layerscape/Makefile
index ccb3aa5..4754e59 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/Makefile
+++ b/arch/arm/cpu/armv8/fsl-layerscape/Makefile
@@ -14,6 +14,11 @@ obj-$(CONFIG_SPL) += spl.o
 ifneq ($(CONFIG_FSL_LSCH3),)
 obj-y += fsl_lsch3_speed.o
 obj-$(CONFIG_SYS_HAS_SERDES) += fsl_lsch3_serdes.o
+else
+ifneq ($(CONFIG_FSL_LSCH2),)
+obj-y += fsl_lsch2_speed.o
+obj-$(CONFIG_SYS_HAS_SERDES) += fsl_lsch2_serdes.o
+endif
 endif
 
 ifneq ($(CONFIG_LS2085A),)
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/README.lsch2 
b/arch/arm/cpu/armv8/fsl-layerscape/README.lsch2
new file mode 100644
index 000..a6ef830
--- /dev/null
+++ b/arch/arm/cpu/armv8/fsl-layerscape/README.lsch2
@@ -0,0 +1,10 @@
+#
+# Copyright 2015 Freescale Semiconductor
+#
+# SPDX-License-Identifier:  GPL-2.0+
+#
+
+Freescale LayerScape with Chassis Generation 2
+
+This architecture supports Freescale ARMv8 SoCs with Chassis generation 2,
+for example LS1043A.
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c 
b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
index be7442d..fe9d982 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
@@ -180,6 +180,8 @@ static inline void early_mmu_setup(void)
set_pgtable_table(level1_table0,
  CONFIG_SYS_FLASH_BASE >> SECTION_SHIFT_L1,
  level2_table1);
+#elif defined(CONFIG_FSL_LSCH2)
+   set_pgtable_table(level1_table0, 1, level2_table1);
 #endif
/* Find the table and fill in the block entries */
for (i = 0; i < ARRAY_SIZE(early_mmu_table); i++) {
@@ -215,6 +217,9 @@ static inline void early_mmu_setup(void)
  *
  * For LSCH3:
  * Level 2 table 1 contains 512 entries for each 2MB from 32GB to 33GB.
+ * For LSCH2:
+ * Level 2 table 1 contains 512 entries for each 2MB from 1GB to 2GB.
+ * Level 2 table 2 contains 512 entries for each 2MB from 20GB to 21GB.
  */
 static inline void final_mmu_setup(void)
 {
@@ -225,6 +230,9 @@ static inline void final_mmu_setup(void)
u64 *level2_table0 = (u64 *)(gd->arch.tlb_addr + 0x3000);
 #ifdef CONFIG_FSL_LSCH3
u64 *level2_table1 = (u64 *)(gd->arch.tlb_addr + 0x4000);
+#elif defined(CONFIG_FSL_LSCH2)
+   u64 *level2_table1 = (u64 *)(gd->arch.tlb_addr + 0x4000);
+   u64 *level2_table2 = (u64 *)(gd->arch.tlb_addr + 0x5000);
 #endif
struct table_info table = {level0_table, 0, BLOCK_SIZE_L0};
 
@@ -239,6 +247,11 @@ static inline void final_mmu_setup(void)
set_pgtable_table(level1_table0,
  CONFIG_SYS_FSL_QBMAN_BASE >> SECTION_SHIFT_L1,
  level2_table1);
+#elif defined(CONFIG_FSL_LSCH2)
+   set_pgtable_table(level1_table0, 1, level2_table1);
+   set_pgtable_table(level1_table0,
+ CONFIG_SYS_FSL_QBMAN_BASE >> SECTION_SHIFT_L1,
+ level2_table2);
 #endif
 
/* Find the table and fill in the block entries */
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_serdes.c 
b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_serdes.c
new file mode 100644
index 000..f7178d1
--- /dev/null
+++ 

[U-Boot] [Patch V6 00/18] add LS1043A platform support

[Gong Qianyu]

Hi All,

Here are the changes for version 6 patchset. Please kindly help
to review the patchset.

 - Added secondary core support
 - Added ls2085a simulator/emulator into the arch-fsl-layerscape
   framework
 - Moved some SoC related macors from board header file into
   config.h

 - serdes_prtl enum is not merged between ls2085a platform and
   ls1043a platform due to the fact that they are using different
   DPAA implementation.

[Patch V6 01/18] armv7/ls1021a: move ns_access to common file
[Patch V6 02/18] common/board_f.c: modify the macro to use
[Patch V6 03/18] net/fm: Fix the endian issue to support both
[Patch V6 04/18] net/fm/eth: Use mb() to be compatible for both ARM
[Patch V6 05/18] net/fm: Add support for 64-bit platforms
[Patch V6 06/18] net/fm: Make the return value logic consistent with
[Patch V6 07/18] net: fm: bug fix when CONFIG_PHYLIB not defined
[Patch V6 08/18] net: Move some header files to include/
[Patch V6 09/18] net/fm: Add QSGMII PCS init
[Patch V6 10/18] net/fm: fix MDIO controller base on FMAN2
[Patch V6 11/18] armv8/fsl_lsch3: Change arch to fsl-layerscape
[Patch V6 12/18] armv8/fsl_lsch2: Add fsl_lsch2 SoC
[Patch V6 13/18] armv8/ls1043ardb: Add LS1043ARDB board support
[Patch V6 14/18] armv8/ls1043ardb: Add nand boot support
[Patch V6 15/18] armv8/ls1043a: Add Fman support
[Patch V6 16/18] armv8/ls1043ardb: esdhc: Add esdhc support for
[Patch V6 17/18] armv8/ls1043ardb: Add sd boot support
[Patch V6 18/18] armv8/ls1043a: Enable secondary cores

Thanks,
Qianyu

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

[U-Boot] [Patch V6 15/18] armv8/ls1043a: Add Fman support

[Gong Qianyu]

From: Shaohui Xie 

Signed-off-by: Hou Zhiqiang 
Signed-off-by: Shaohui Xie 
Signed-off-by: Mingkai Hu 
Signed-off-by: Gong Qianyu 
---
V6:
 - No change.
V5:
 - No change.
V4:
 - Change arch to layerscape.
V3:
 - No change.
V2:
 - No change.

 arch/arm/cpu/armv8/fsl-layerscape/cpu.c|  12 +++
 arch/arm/cpu/armv8/fsl-layerscape/fdt.c|   6 ++
 .../arm/cpu/armv8/fsl-layerscape/fsl_lsch2_speed.c |  23 
 board/freescale/common/fman.c  |   6 +-
 board/freescale/ls1043ardb/Makefile|   1 +
 board/freescale/ls1043ardb/eth.c   |  77 +
 board/freescale/ls1043ardb/ls1043ardb.c|   4 +
 doc/README.fsl-dpaa|   4 +-
 drivers/net/fm/Makefile|   1 +
 drivers/net/fm/init.c  |  10 +-
 drivers/net/fm/ls1043.c| 119 +
 include/configs/ls1043a_common.h   |  12 +++
 include/configs/ls1043ardb.h   |  25 +
 13 files changed, 295 insertions(+), 5 deletions(-)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c 
b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
index fe9d982..0cb0afa 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
@@ -274,6 +274,9 @@ static inline void final_mmu_setup(void)
flush_dcache_range(gd->arch.tlb_addr,
   gd->arch.tlb_addr + gd->arch.tlb_size);
 
+#ifdef CONFIG_SYS_DPAA_FMAN
+   flush_dcache_all();
+#endif
/* point TTBR to the new table */
el = current_el();
 
@@ -432,6 +435,9 @@ int print_cpuinfo(void)
printf("\n   Bus:  %-4s MHz  ",
   strmhz(buf, sysinfo.freq_systembus));
printf("DDR:  %-4s MT/s", strmhz(buf, sysinfo.freq_ddrbus));
+#ifdef CONFIG_SYS_DPAA_FMAN
+   printf("  FMAN: %-4s MHz", strmhz(buf, sysinfo.freq_fman[0]));
+#endif
 #ifdef CONFIG_FSL_LSCH3
printf(" DP-DDR:   %-4s MT/s", strmhz(buf, sysinfo.freq_ddrbus2));
 #endif
@@ -468,6 +474,9 @@ int cpu_eth_init(bd_t *bis)
 #ifdef CONFIG_FSL_MC_ENET
error = fsl_mc_ldpaa_init(bis);
 #endif
+#ifdef CONFIG_FMAN_ENET
+   fm_standard_init(bis);
+#endif
return error;
 }
 
@@ -484,6 +493,9 @@ int arch_early_init_r(void)
 #ifdef CONFIG_SYS_HAS_SERDES
fsl_serdes_init();
 #endif
+#ifdef CONFIG_FMAN_ENET
+   fman_enet_init();
+#endif
return 0;
 }
 
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c 
b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
index aa88d34..9c841c2 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
@@ -18,6 +18,12 @@
 #include 
 #endif
 
+int fdt_fixup_phy_connection(void *blob, int offset, phy_interface_t phyc)
+{
+   return fdt_setprop_string(blob, offset, "phy-connection-type",
+phy_string_for_interface(phyc));
+}
+
 #ifdef CONFIG_MP
 void ft_fixup_cpu(void *blob)
 {
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_speed.c 
b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_speed.c
index ea3723f..9d5bbe7 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_speed.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_speed.c
@@ -25,6 +25,9 @@ void get_sys_info(struct sys_info *sys_info)
struct fsl_ifc ifc_regs = {(void *)CONFIG_SYS_IFC_ADDR, (void *)NULL};
u32 ccr;
 #endif
+#ifdef CONFIG_SYS_DPAA_FMAN
+   u32 rcw_tmp;
+#endif
struct ccsr_clk *clk = (void *)(CONFIG_SYS_FSL_CLK_ADDR);
unsigned int cpu;
const u8 core_cplx_pll[8] = {
@@ -79,6 +82,26 @@ void get_sys_info(struct sys_info *sys_info)
 
 #define HWA_CGA_M1_CLK_SEL 0xe000
 #define HWA_CGA_M1_CLK_SHIFT   29
+#ifdef CONFIG_SYS_DPAA_FMAN
+   rcw_tmp = in_be32(>rcwsr[7]);
+   switch ((rcw_tmp & HWA_CGA_M1_CLK_SEL) >> HWA_CGA_M1_CLK_SHIFT) {
+   case 2:
+   sys_info->freq_fman[0] = freq_c_pll[0] / 2;
+   break;
+   case 3:
+   sys_info->freq_fman[0] = freq_c_pll[0] / 3;
+   break;
+   case 6:
+   sys_info->freq_fman[0] = freq_c_pll[1] / 2;
+   break;
+   case 7:
+   sys_info->freq_fman[0] = freq_c_pll[1] / 3;
+   break;
+   default:
+   printf("Error: Unknown FMan1 clock select!\n");
+   break;
+   }
+#endif
 
 #define HWA_CGA_M2_CLK_SEL 0x0007
 #define HWA_CGA_M2_CLK_SHIFT   0
diff --git a/board/freescale/common/fman.c b/board/freescale/common/fman.c
index 9dc5402..26cf517 100644
--- a/board/freescale/common/fman.c
+++ b/board/freescale/common/fman.c
@@ -1,5 +1,5 @@
 /*
- * Copyright 2011 Freescale Semiconductor, Inc.
+ * Copyright 2011-2015 Freescale Semiconductor, Inc.
  *
  * 

[U-Boot] [Patch V6 02/18] common/board_f.c: modify the macro to use get_clocks() more common

[Gong Qianyu]

From: Gong Qianyu 

get_clocks() should not be limited by ESDHC.

Signed-off-by: Gong Qianyu 
---
V6:
 - No change.
V5:
 - No change.
V4:
 - No change.
V3:
 - Removed defines in PPC configs that have no need to use.
V2:
 - No change.

 common/board_f.c  | 2 +-
 include/configs/colibri_vf.h  | 1 +
 include/configs/ls1021aqds.h  | 1 +
 include/configs/ls1021atwr.h  | 1 +
 include/configs/ls2085aqds.h  | 1 +
 include/configs/ls2085ardb.h  | 1 +
 include/configs/m53evk.h  | 1 +
 include/configs/mx25pdk.h | 1 +
 include/configs/mx35pdk.h | 1 +
 include/configs/mx51evk.h | 1 +
 include/configs/mx53ard.h | 1 +
 include/configs/mx53evk.h | 1 +
 include/configs/mx53loco.h| 1 +
 include/configs/mx53smd.h | 1 +
 include/configs/mx6_common.h  | 1 +
 include/configs/mx7_common.h  | 1 +
 include/configs/usbarmory.h   | 1 +
 include/configs/vf610twr.h| 1 +
 include/configs/woodburn_common.h | 1 +
 19 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/common/board_f.c b/common/board_f.c
index 613332e..1bb84b3 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -806,7 +806,7 @@ static init_fnc_t init_sequence_f[] = {
 #if defined(CONFIG_BOARD_POSTCLK_INIT)
board_postclk_init,
 #endif
-#ifdef CONFIG_FSL_ESDHC
+#ifdef CONFIG_FSL_CLK
get_clocks,
 #endif
 #ifdef CONFIG_M68K
diff --git a/include/configs/colibri_vf.h b/include/configs/colibri_vf.h
index 2583155..5bd742d 100644
--- a/include/configs/colibri_vf.h
+++ b/include/configs/colibri_vf.h
@@ -18,6 +18,7 @@
 #define CONFIG_SYS_THUMB_BUILD
 #define CONFIG_USE_ARCH_MEMCPY
 #define CONFIG_USE_ARCH_MEMSET
+#define CONFIG_FSL_CLK
 
 #define CONFIG_SYS_GENERIC_BOARD
 #define CONFIG_ARCH_MISC_INIT
diff --git a/include/configs/ls1021aqds.h b/include/configs/ls1021aqds.h
index 9b8b001..42b66b3 100644
--- a/include/configs/ls1021aqds.h
+++ b/include/configs/ls1021aqds.h
@@ -12,6 +12,7 @@
 #define CONFIG_ARMV7_PSCI
 
 #define CONFIG_SYS_GENERIC_BOARD
+#define CONFIG_FSL_CLK
 
 #define CONFIG_DISPLAY_CPUINFO
 #define CONFIG_DISPLAY_BOARDINFO
diff --git a/include/configs/ls1021atwr.h b/include/configs/ls1021atwr.h
index 676c096..8a86473 100644
--- a/include/configs/ls1021atwr.h
+++ b/include/configs/ls1021atwr.h
@@ -12,6 +12,7 @@
 #define CONFIG_ARMV7_PSCI
 
 #define CONFIG_SYS_GENERIC_BOARD
+#define CONFIG_FSL_CLK
 
 #define CONFIG_DISPLAY_CPUINFO
 #define CONFIG_DISPLAY_BOARDINFO
diff --git a/include/configs/ls2085aqds.h b/include/configs/ls2085aqds.h
index f7f3870..4cfcf98 100644
--- a/include/configs/ls2085aqds.h
+++ b/include/configs/ls2085aqds.h
@@ -16,6 +16,7 @@ unsigned long get_board_sys_clk(void);
 unsigned long get_board_ddr_clk(void);
 #endif
 
+#define CONFIG_FSL_CLK
 #define CONFIG_SYS_CLK_FREQget_board_sys_clk()
 #define CONFIG_DDR_CLK_FREQget_board_ddr_clk()
 #define COUNTER_FREQUENCY_REAL (CONFIG_SYS_CLK_FREQ/4)
diff --git a/include/configs/ls2085ardb.h b/include/configs/ls2085ardb.h
index a190bc7..583fed5 100644
--- a/include/configs/ls2085ardb.h
+++ b/include/configs/ls2085ardb.h
@@ -18,6 +18,7 @@
 unsigned long get_board_sys_clk(void);
 #endif
 
+#define CONFIG_FSL_CLK
 #define CONFIG_SYS_CLK_FREQget_board_sys_clk()
 #define CONFIG_DDR_CLK_FREQ1
 #define COUNTER_FREQUENCY_REAL (CONFIG_SYS_CLK_FREQ/4)
diff --git a/include/configs/m53evk.h b/include/configs/m53evk.h
index 8853d8f..456e5b4 100644
--- a/include/configs/m53evk.h
+++ b/include/configs/m53evk.h
@@ -18,6 +18,7 @@
 #define CONFIG_BOARD_EARLY_INIT_F
 #define CONFIG_REVISION_TAG
 #define CONFIG_SYS_NO_FLASH
+#define CONFIG_FSL_CLK
 
 #define CONFIG_FIT
 
diff --git a/include/configs/mx25pdk.h b/include/configs/mx25pdk.h
index 0414086..afe2a02 100644
--- a/include/configs/mx25pdk.h
+++ b/include/configs/mx25pdk.h
@@ -15,6 +15,7 @@
 #define CONFIG_SYS_TEXT_BASE   0x8120
 #define CONFIG_MXC_GPIO
 #define CONFIG_SYS_GENERIC_BOARD
+#define CONFIG_FSL_CLK
 
 #define CONFIG_SYS_TIMER_RATE  32768
 #define CONFIG_SYS_TIMER_COUNTER   \
diff --git a/include/configs/mx35pdk.h b/include/configs/mx35pdk.h
index 6bfdaa6..dca2f86 100644
--- a/include/configs/mx35pdk.h
+++ b/include/configs/mx35pdk.h
@@ -20,6 +20,7 @@
 
 #define CONFIG_DISPLAY_CPUINFO
 #define CONFIG_SYS_GENERIC_BOARD
+#define CONFIG_FSL_CLK
 
 /* Set TEXT at the beginning of the NOR flash */
 #define CONFIG_SYS_TEXT_BASE   0xA000
diff --git a/include/configs/mx51evk.h b/include/configs/mx51evk.h
index 2203c15..e3763c1 100644
--- a/include/configs/mx51evk.h
+++ b/include/configs/mx51evk.h
@@ -18,6 +18,7 @@
 #define CONFIG_DISPLAY_CPUINFO
 #define CONFIG_DISPLAY_BOARDINFO
 
+#define CONFIG_FSL_CLK
 #define CONFIG_SYS_TEXT_BASE   0x9780
 
 #include 
diff --git a/include/configs/mx53ard.h b/include/configs/mx53ard.h
index b889c25..9ef973d 100644
--- 

[U-Boot] [Patch V6 01/18] armv7/ls1021a: move ns_access to common file

[Gong Qianyu]

From: Mingkai Hu 

Config Security Level Register is different between different SoCs,
so put the CSL register definition into the arch specific directory.

Signed-off-by: Mingkai Hu 
Signed-off-by: Gong Qianyu 
---
V6:
 - No change.
V5:
 - No change.
V4:
 - No change.
V3:
 - No change.
V2:
 - Create include/fsl_csu.h instead of board/freescale/common/ns_access.h
 
 arch/arm/include/asm/arch-ls102xa/ns_access.h | 103 --
 board/freescale/common/Makefile   |   2 +-
 board/freescale/common/ns_access.c|   8 +-
 board/freescale/ls1021aqds/ls1021aqds.c   | 101 ++---
 board/freescale/ls1021atwr/ls1021atwr.c   |  92 +--
 include/configs/ls1021aqds.h  |   2 +-
 include/configs/ls1021atwr.h  |   2 +-
 include/fsl_csu.h |  34 +
 8 files changed, 136 insertions(+), 208 deletions(-)

diff --git a/arch/arm/include/asm/arch-ls102xa/ns_access.h 
b/arch/arm/include/asm/arch-ls102xa/ns_access.h
index b53f699..a921fb6 100644
--- a/arch/arm/include/asm/arch-ls102xa/ns_access.h
+++ b/arch/arm/include/asm/arch-ls102xa/ns_access.h
@@ -7,22 +7,6 @@
 #ifndef __FSL_NS_ACCESS_H_
 #define __FSL_NS_ACCESS_H_
 
-enum csu_cslx_access {
-   CSU_NS_SUP_R = 0x08,
-   CSU_NS_SUP_W = 0x80,
-   CSU_NS_SUP_RW = 0x88,
-   CSU_NS_USER_R = 0x04,
-   CSU_NS_USER_W = 0x40,
-   CSU_NS_USER_RW = 0x44,
-   CSU_S_SUP_R = 0x02,
-   CSU_S_SUP_W = 0x20,
-   CSU_S_SUP_RW = 0x22,
-   CSU_S_USER_R = 0x01,
-   CSU_S_USER_W = 0x10,
-   CSU_S_USER_RW = 0x11,
-   CSU_ALL_RW = 0xff,
-};
-
 enum csu_cslx_ind {
CSU_CSLX_PCIE2_IO = 0,
CSU_CSLX_PCIE1_IO,
@@ -108,11 +92,88 @@ enum csu_cslx_ind {
CSU_CSLX_MAX,
 };
 
-struct csu_ns_dev {
-   unsigned long ind;
-   uint32_t val;
+static struct csu_ns_dev ns_dev[] = {
+   { CSU_CSLX_PCIE2_IO, CSU_ALL_RW },
+   { CSU_CSLX_PCIE1_IO, CSU_ALL_RW },
+   { CSU_CSLX_MG2TPR_IP, CSU_ALL_RW },
+   { CSU_CSLX_IFC_MEM, CSU_ALL_RW },
+   { CSU_CSLX_OCRAM, CSU_ALL_RW },
+   { CSU_CSLX_GIC, CSU_ALL_RW },
+   { CSU_CSLX_PCIE1, CSU_ALL_RW },
+   { CSU_CSLX_OCRAM2, CSU_ALL_RW },
+   { CSU_CSLX_QSPI_MEM, CSU_ALL_RW },
+   { CSU_CSLX_PCIE2, CSU_ALL_RW },
+   { CSU_CSLX_SATA, CSU_ALL_RW },
+   { CSU_CSLX_USB3, CSU_ALL_RW },
+   { CSU_CSLX_SERDES, CSU_ALL_RW },
+   { CSU_CSLX_QDMA, CSU_ALL_RW },
+   { CSU_CSLX_LPUART2, CSU_ALL_RW },
+   { CSU_CSLX_LPUART1, CSU_ALL_RW },
+   { CSU_CSLX_LPUART4, CSU_ALL_RW },
+   { CSU_CSLX_LPUART3, CSU_ALL_RW },
+   { CSU_CSLX_LPUART6, CSU_ALL_RW },
+   { CSU_CSLX_LPUART5, CSU_ALL_RW },
+   { CSU_CSLX_DSPI2, CSU_ALL_RW },
+   { CSU_CSLX_DSPI1, CSU_ALL_RW },
+   { CSU_CSLX_QSPI, CSU_ALL_RW },
+   { CSU_CSLX_ESDHC, CSU_ALL_RW },
+   { CSU_CSLX_2D_ACE, CSU_ALL_RW },
+   { CSU_CSLX_IFC, CSU_ALL_RW },
+   { CSU_CSLX_I2C1, CSU_ALL_RW },
+   { CSU_CSLX_USB2, CSU_ALL_RW },
+   { CSU_CSLX_I2C3, CSU_ALL_RW },
+   { CSU_CSLX_I2C2, CSU_ALL_RW },
+   { CSU_CSLX_DUART2, CSU_ALL_RW },
+   { CSU_CSLX_DUART1, CSU_ALL_RW },
+   { CSU_CSLX_WDT2, CSU_ALL_RW },
+   { CSU_CSLX_WDT1, CSU_ALL_RW },
+   { CSU_CSLX_EDMA, CSU_ALL_RW },
+   { CSU_CSLX_SYS_CNT, CSU_ALL_RW },
+   { CSU_CSLX_DMA_MUX2, CSU_ALL_RW },
+   { CSU_CSLX_DMA_MUX1, CSU_ALL_RW },
+   { CSU_CSLX_DDR, CSU_ALL_RW },
+   { CSU_CSLX_QUICC, CSU_ALL_RW },
+   { CSU_CSLX_DCFG_CCU_RCPM, CSU_ALL_RW },
+   { CSU_CSLX_SECURE_BOOTROM, CSU_ALL_RW },
+   { CSU_CSLX_SFP, CSU_ALL_RW },
+   { CSU_CSLX_TMU, CSU_ALL_RW },
+   { CSU_CSLX_SECURE_MONITOR, CSU_ALL_RW },
+   { CSU_CSLX_RESERVED0, CSU_ALL_RW },
+   { CSU_CSLX_ETSEC1, CSU_ALL_RW },
+   { CSU_CSLX_SEC5_5, CSU_ALL_RW },
+   { CSU_CSLX_ETSEC3, CSU_ALL_RW },
+   { CSU_CSLX_ETSEC2, CSU_ALL_RW },
+   { CSU_CSLX_GPIO2, CSU_ALL_RW },
+   { CSU_CSLX_GPIO1, CSU_ALL_RW },
+   { CSU_CSLX_GPIO4, CSU_ALL_RW },
+   { CSU_CSLX_GPIO3, CSU_ALL_RW },
+   { CSU_CSLX_PLATFORM_CONT, CSU_ALL_RW },
+   { CSU_CSLX_CSU, CSU_ALL_RW },
+   { CSU_CSLX_ASRC, CSU_ALL_RW },
+   { CSU_CSLX_SPDIF, CSU_ALL_RW },
+   { CSU_CSLX_FLEXCAN2, CSU_ALL_RW },
+   { CSU_CSLX_FLEXCAN1, CSU_ALL_RW },
+   { CSU_CSLX_FLEXCAN4, CSU_ALL_RW },
+   { CSU_CSLX_FLEXCAN3, CSU_ALL_RW },
+   { CSU_CSLX_SAI2, CSU_ALL_RW },
+   { CSU_CSLX_SAI1, CSU_ALL_RW },
+   { CSU_CSLX_SAI4, CSU_ALL_RW },
+   { CSU_CSLX_SAI3, CSU_ALL_RW },
+   { CSU_CSLX_FTM2, CSU_ALL_RW },
+   { CSU_CSLX_FTM1, CSU_ALL_RW },
+   { CSU_CSLX_FTM4, CSU_ALL_RW },
+   { CSU_CSLX_FTM3, CSU_ALL_RW },
+   { CSU_CSLX_FTM6, CSU_ALL_RW },
+   { CSU_CSLX_FTM5, CSU_ALL_RW },
+   { CSU_CSLX_FTM8, CSU_ALL_RW },
+   { 

[U-Boot] [PATCH v4 3/8] board_init_f_mem(): Don't create an unused early malloc() area

[Simon Glass]

Change the #ifdef so that the early malloc() area is not set up in SPL if
CONFIG_SYS_SPL_MALLOC_START is defined. In that case it would never actually
be used, and just chews up stack space.

Signed-off-by: Simon Glass 
Tested-by: Masahiro Yamada 
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

 common/init/board_init.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/common/init/board_init.c b/common/init/board_init.c
index 1c6126d..e74b63b 100644
--- a/common/init/board_init.c
+++ b/common/init/board_init.c
@@ -50,7 +50,8 @@ ulong board_init_f_mem(ulong top)
 #endif
arch_setup_gd(gd_ptr);
 
-#if defined(CONFIG_SYS_MALLOC_F)
+#if defined(CONFIG_SYS_MALLOC_F) && \
+   (!defined(CONFIG_SPL_BUILD) || !defined(CONFIG_SYS_SPL_MALLOC_START))
top -= CONFIG_SYS_MALLOC_F_LEN;
gd->malloc_base = top;
 #endif
-- 
2.6.0.rc2.230.g3dd15c0

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

[U-Boot] [PATCH v4 8/8] Revert "ARM: zynq: disable CONFIG_SYS_MALLOC_F to fix MMC boot"

[Simon Glass]

This reverts commit 321f86e18d6aae9f7b7ba3ef1eb0cec769481874.

The original bug has been fixed.

Signed-off-by: Simon Glass 
Tested-on: Zedboard and ZC706 board
Tested-by: Masahiro Yamada 
Tested-on: zc702
Tested-by: Michal Simek 
---

Changes in v4:
- Fully revert the commit (some changes were lost in v3)

Changes in v3:
- Rebase to master

Changes in v2: None

 configs/zynq_microzed_defconfig| 1 -
 configs/zynq_zc702_defconfig   | 1 -
 configs/zynq_zc706_defconfig   | 1 -
 configs/zynq_zc70x_defconfig   | 1 -
 configs/zynq_zc770_xm010_defconfig | 1 -
 configs/zynq_zc770_xm011_defconfig | 1 -
 configs/zynq_zc770_xm012_defconfig | 1 -
 configs/zynq_zc770_xm013_defconfig | 1 -
 configs/zynq_zed_defconfig | 1 -
 configs/zynq_zybo_defconfig| 1 -
 10 files changed, 10 deletions(-)

diff --git a/configs/zynq_microzed_defconfig b/configs/zynq_microzed_defconfig
index a6757ac..e9c3209 100644
--- a/configs/zynq_microzed_defconfig
+++ b/configs/zynq_microzed_defconfig
@@ -1,6 +1,5 @@
 CONFIG_ARM=y
 CONFIG_ARCH_ZYNQ=y
-# CONFIG_SYS_MALLOC_F is not set
 CONFIG_TARGET_ZYNQ_MICROZED=y
 CONFIG_DEFAULT_DEVICE_TREE="zynq-microzed"
 CONFIG_SPL=y
diff --git a/configs/zynq_zc702_defconfig b/configs/zynq_zc702_defconfig
index 8a388f3..0abb7a8 100644
--- a/configs/zynq_zc702_defconfig
+++ b/configs/zynq_zc702_defconfig
@@ -1,6 +1,5 @@
 CONFIG_ARM=y
 CONFIG_ARCH_ZYNQ=y
-# CONFIG_SYS_MALLOC_F is not set
 CONFIG_DEFAULT_DEVICE_TREE="zynq-zc702"
 CONFIG_SPL=y
 CONFIG_FIT=y
diff --git a/configs/zynq_zc706_defconfig b/configs/zynq_zc706_defconfig
index f1009ee..d67f507 100644
--- a/configs/zynq_zc706_defconfig
+++ b/configs/zynq_zc706_defconfig
@@ -1,6 +1,5 @@
 CONFIG_ARM=y
 CONFIG_ARCH_ZYNQ=y
-# CONFIG_SYS_MALLOC_F is not set
 CONFIG_TARGET_ZYNQ_ZC706=y
 CONFIG_DEFAULT_DEVICE_TREE="zynq-zc706"
 CONFIG_SPL=y
diff --git a/configs/zynq_zc70x_defconfig b/configs/zynq_zc70x_defconfig
index 6465040..37c249f 100644
--- a/configs/zynq_zc70x_defconfig
+++ b/configs/zynq_zc70x_defconfig
@@ -1,6 +1,5 @@
 CONFIG_ARM=y
 CONFIG_ARCH_ZYNQ=y
-# CONFIG_SYS_MALLOC_F is not set
 CONFIG_TARGET_ZYNQ_ZC70X=y
 CONFIG_DEFAULT_DEVICE_TREE="zynq-zc702"
 CONFIG_SPL=y
diff --git a/configs/zynq_zc770_xm010_defconfig 
b/configs/zynq_zc770_xm010_defconfig
index cafbb09..0e826bb 100644
--- a/configs/zynq_zc770_xm010_defconfig
+++ b/configs/zynq_zc770_xm010_defconfig
@@ -1,6 +1,5 @@
 CONFIG_ARM=y
 CONFIG_ARCH_ZYNQ=y
-# CONFIG_SYS_MALLOC_F is not set
 CONFIG_TARGET_ZYNQ_ZC770=y
 CONFIG_DEFAULT_DEVICE_TREE="zynq-zc770-xm010"
 CONFIG_SPL=y
diff --git a/configs/zynq_zc770_xm011_defconfig 
b/configs/zynq_zc770_xm011_defconfig
index e6e1c30..46d043b 100644
--- a/configs/zynq_zc770_xm011_defconfig
+++ b/configs/zynq_zc770_xm011_defconfig
@@ -1,6 +1,5 @@
 CONFIG_ARM=y
 CONFIG_ARCH_ZYNQ=y
-# CONFIG_SYS_MALLOC_F is not set
 CONFIG_TARGET_ZYNQ_ZC770=y
 CONFIG_DEFAULT_DEVICE_TREE="zynq-zc770-xm011"
 CONFIG_SPL=y
diff --git a/configs/zynq_zc770_xm012_defconfig 
b/configs/zynq_zc770_xm012_defconfig
index 9a44009..34d479f 100644
--- a/configs/zynq_zc770_xm012_defconfig
+++ b/configs/zynq_zc770_xm012_defconfig
@@ -1,6 +1,5 @@
 CONFIG_ARM=y
 CONFIG_ARCH_ZYNQ=y
-# CONFIG_SYS_MALLOC_F is not set
 CONFIG_TARGET_ZYNQ_ZC770=y
 CONFIG_DEFAULT_DEVICE_TREE="zynq-zc770-xm012"
 CONFIG_SPL=y
diff --git a/configs/zynq_zc770_xm013_defconfig 
b/configs/zynq_zc770_xm013_defconfig
index 95e32a5..c59599f 100644
--- a/configs/zynq_zc770_xm013_defconfig
+++ b/configs/zynq_zc770_xm013_defconfig
@@ -1,6 +1,5 @@
 CONFIG_ARM=y
 CONFIG_ARCH_ZYNQ=y
-# CONFIG_SYS_MALLOC_F is not set
 CONFIG_TARGET_ZYNQ_ZC770=y
 CONFIG_DEFAULT_DEVICE_TREE="zynq-zc770-xm013"
 CONFIG_SPL=y
diff --git a/configs/zynq_zed_defconfig b/configs/zynq_zed_defconfig
index 43520d0..886b4a5 100644
--- a/configs/zynq_zed_defconfig
+++ b/configs/zynq_zed_defconfig
@@ -1,6 +1,5 @@
 CONFIG_ARM=y
 CONFIG_ARCH_ZYNQ=y
-# CONFIG_SYS_MALLOC_F is not set
 CONFIG_TARGET_ZYNQ_ZED=y
 CONFIG_DEFAULT_DEVICE_TREE="zynq-zed"
 CONFIG_SPL=y
diff --git a/configs/zynq_zybo_defconfig b/configs/zynq_zybo_defconfig
index 46379e5..77b9409 100644
--- a/configs/zynq_zybo_defconfig
+++ b/configs/zynq_zybo_defconfig
@@ -1,6 +1,5 @@
 CONFIG_ARM=y
 CONFIG_ARCH_ZYNQ=y
-# CONFIG_SYS_MALLOC_F is not set
 CONFIG_TARGET_ZYNQ_ZYBO=y
 CONFIG_DEFAULT_DEVICE_TREE="zynq-zybo"
 CONFIG_SPL=y
-- 
2.6.0.rc2.230.g3dd15c0

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

[U-Boot] [PATCH v4 6/8] microblaze: Add a TODO to call board_init_f_mem()

[Simon Glass]

This C function should be used to do the early memory layout and init. This
is beyond my powers, so just add a TODO for the maintainer.

Signed-off-by: Simon Glass 
Acked-by: Michal Simek 
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/microblaze/cpu/start.S | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/microblaze/cpu/start.S b/arch/microblaze/cpu/start.S
index 953d3a1..14f46a8 100644
--- a/arch/microblaze/cpu/start.S
+++ b/arch/microblaze/cpu/start.S
@@ -25,6 +25,7 @@ _start:
 
addir8, r0, __end
mts rslr, r8
+   /* TODO: Redo this code to call board_init_f_mem() */
 #if defined(CONFIG_SPL_BUILD)
addir1, r0, CONFIG_SPL_STACK_ADDR
mts rshr, r1
@@ -141,6 +142,7 @@ _start:
ori r12, r12, 0x1a0
mts rmsr, r12
 
+   /* TODO: Redo this code to call board_init_f_mem() */
 clear_bss:
/* clear BSS segments */
addir5, r0, __bss_start
-- 
2.6.0.rc2.230.g3dd15c0

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

Re: [U-Boot] [PATCH v7 5/9] arm: serial: Add ability to use pre-initialized UARTs

[Linus Walleij]

Jon & Grant especially:

On Mon, Oct 19, 2015 at 2:44 PM, Simon Glass  wrote:
> Me
>> I will go in and answer the comment on the DT mailing list so there is
>> some push atleast.
>
> Perhaps if we could see some movement then it would provide
> encouragement to continue. So far I cannot recall seeing a single
> U-Boot device tree change accepted in the 4 years I've been involved.
> That's not to say it hasn't happened, and I hope it is just a
> reflection on my memory rather than the difficulty level.

OK this isn't working.

I think the problem is that DT bindings have traditionally been merged to
the kernel by different subsystem maintainers. That means mailing them
and their mailing lists and this is IMO too complex for U-Boot people
(or other external people) to have to deal with. As subsystem
maintainer I'm not very happy about being the one responsible either.

The MAINTAINERS entry for device tree bindings does not state a
git tree and I've never seen any of the maintainers send a pull request for
DT binding files. (Beat me up properly if you have, guys.) I've seen
Grant send some at times.

I suggest sending U-Boot DT bindings to not only
devicet...@vger.kernel.org
but also, as indicated, to Jon Corbet and linux-doc.

If noone cares to comment in two weeks, Jon can merge them,
breaking the status quo on external DT bindings.

The DT bindings maintainance has sadly been a very sad story and if
the Linux kernel should be the canon repository for them, we
need to find a simple way for external projects to contribute. Just
mailing them to devicetree@vger obviously stands the risk of just
ending up in the memory hole.

Jon, are you OK with taking on this or do we need to find another way
of funneling external DT bindings? Or do you want to do this Grant?

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

Re: [U-Boot] mmc erase fails from U-Boot command line

[Hector Palacios]

Dear Cliff,

On 10/16/2015 01:46 PM, Cliff Brust wrote:
> I have the need to erase our eMMC from U-Boot on our custom board due to a 
> hard wired
> boot up configuration. Our design is based on the Freescale i.MX6Q SabreSD 
> Board
> reference design. The bottom line is the U-Boot command "mmc erase" is 
> failing with
> the error "Timeout waiting for DAT0 to go high!".  Here's a list of the U-Boot
> commands issued and the result of each so you can see what is going on.
> 
> => mmc list
> FSL_SDHC: 0
> FSL_SDHC: 1 (SD)
> FSL_SDHC: 2 (eMMC)
> 
> => mmc dev 2
> switch to partitions #0, OK
> mmc2(part 0) is current device
> 
> => mmc info
> Device: FSL_SDHC
> Manufacturer ID: 45
> OEM: 100
> Name: SEM08
> Tran Speed: 5200
> Rd Block Len: 512
> MMC version 4.4.1
> High Capacity: Yes
> Capacity: 7.4 GiB
> Bus Width: 8-bit
> Erase Group Size: 512 KiB
> HC WP Group Size: 16 MiB
> User Capacity: 7.4 GiB WRREL
> Boot Capacity: 2 MiB ENH
> RPMB Capacity: 128 KiB ENH
> 
> => mmc erase 0 0x400
> MMC erase: dev # 2, block # 0, count 1024 ...
> Timeout waiting for DAT0 to go high!
> mmc erase failed
> 0 blocks erased: ERROR
> 
> 
> Any insight on this issue is greatly appreciated.
> Thanks,  Cliff

This issue is reproducible on Freescale's SABRESD on both SD card and eMMC with
v2015.04. The issue has been there always, I believe.
Apparently the command erases the first block, but the operation returns an 
error, so
it aborts and it doesn't continue erasing futher blocks.

I opened a similar thread a while ago:
http://lists.denx.de/pipermail/u-boot/2015-June/215912.html

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

Re: [U-Boot] [PATCH] arm: sunxi: Add icnova-a20-swac defconfig and dts file

[Hans de Goede]

Hi,

On 19-10-15 12:48, Stefan Roese wrote:

Hi Maxime,

On 18.10.2015 11:34, Maxime Ripard wrote:

On 01-10-15 11:41, Stefan Roese wrote:

The ICnova-A20-SWAC is a baseboard, equipped with the ICnova-A20 SoM from
In-Circuit:

http://wiki.in-circuit.de/index.php5?title=ICnova_A20_SODIMM
http://linux-sunxi.org/In-Circuit_ICnova_A20

This patch adds support for this board, including ethernet, LCD and USB
support.


Thanks, I've merged this and it will show up in u-boot-sunxi/next soon.

I've made 2 small changes, see comments inline.


Signed-off-by: Stefan Roese 
Cc: Marcus Heuer 
Cc: Hans de Goede 
Cc: Ian Campbell 
---
  arch/arm/dts/Makefile  |   1 +
  arch/arm/dts/sun7i-a20-icnova-a20-swac.dts | 177 +
  board/sunxi/MAINTAINERS|   5 +
  configs/icnova-a20-swac_defconfig  |  21 
  4 files changed, 204 insertions(+)
  create mode 100644 arch/arm/dts/sun7i-a20-icnova-a20-swac.dts
  create mode 100644 configs/icnova-a20-swac_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 5f10243..1f2661c 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -134,6 +134,7 @@ dtb-$(CONFIG_MACH_SUN7I) += \
  sun7i-a20-cubietruck.dtb \
  sun7i-a20-hummingbird.dtb \
  sun7i-a20-i12-tvbox.dtb \
+sun7i-a20-icnova-a20-swac.dtb \
  sun7i-a20-m3.dtb \
  sun7i-a20-m5.dtb \
  sun7i-a20-mk808c.dtb \
diff --git a/arch/arm/dts/sun7i-a20-icnova-a20-swac.dts 
b/arch/arm/dts/sun7i-a20-icnova-a20-swac.dts
new file mode 100644


Please submit this file also to the upstream kernel.


Yes. The name of the DT especially doesn't really make sense. The
"SWAC" name isn't referenced anywhere, the module cannot be used
alone, and there's a single combination available (A20 SODIMM +
ADB4006)


At least one other combination is available. A custom board from SWAC
equipped with the SoM. What is the preferred method to support SoM's
with multiple baseboards? Something like:

sun7i-a20-icnova.dtsi
sun7i-a20-icnova-adb4006.dts
sun7i-a20-icnova-swac.dts

?




index 000..773fb6f
--- /dev/null
+++ b/arch/arm/dts/sun7i-a20-icnova-a20-swac.dts
@@ -0,0 +1,177 @@
+/*
+ * Copyright 2013 Maxime Ripard
+ *
+ * Maxime Ripard 


And I'm *not* the copyright owner here.


Okay. Hans, do you want me to change this (and potential other
changes as well - see file naming above) via a follow-up patch
once its available in mainline U-Boot?


Actually I would prefer to get this right in one go, esp. the
filename bits, having u-boot and the kernel disagreeing on the
dtb filename is no good. So I plan to remove this version of
the patch from u-boot-sunxi/next for now. Once you and Maxime
agree on a dts / dtb filename please submit a new version and
I'll merge that one instead.

Regards,

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

Re: [U-Boot] [PATCH] configs: ls1021atwr: Enable ID EEPROM for SD boot

[Sinan Akman]

  Hi Yuan

On 19/10/15 05:21 AM, Yao Yuan wrote:

Hi Sinan Akman,

Yes, I mean the Rev 1.0 silicon.
Sorry, I can't guarantee that there aren't any boards with Rev1.0 silicon are 
in user's hands.
Because we have also delivery very little board with Rev1.0 silicon to  
customer  or developer for developing, assessing and verifying in the early 
stages.


  Thanks for the follow up on this, but I don't think that there were only
very few rev1.0 boards delivered. These were the boards bought from
distributor and during the time span of many weeks.

  I don't know the details and the impact of this patch exactly but
if the patch will break any rev1.0 board I don't think this would be
acceptable. There are definitely enough number of rev1.0 boards
made generally available (not specifically for early adapters etc)
that we should not break u-boot running on them.


Also we haven't support Rev1.0 in our SDK now.


  Sorry, but this is a bit irrelevant here. I'd expect u-boot mainline
does not necessarily follow what your SDK stops supporting. If
u-boot supported rev1.0 boards and if there are still many of
 them out there I see no reason to break this.

  Regards
  Sinan Akman



Thanks.

Best Regards,
Yuan Yao


-Original Message-
From: Sinan Akman [mailto:si...@writeme.com]
Sent: Friday, October 16, 2015 3:37 AM
To: Sun York-R58495 ; Yuan Yao-B46683
; Wang Huan-B18965 
Cc: u-boot@lists.denx.de
Subject: Re: [U-Boot] [PATCH] configs: ls1021atwr: Enable ID EEPROM for SD
boot


Hi Yuan

On 15/10/15 12:40 PM, York Sun wrote:


On 10/15/2015 12:55 AM, Yuan Yao-B46683 wrote:

Hi york,

The earlier SoC is just LS1021a rev1.0, but rev1.0 haven't delivery to the

customer.

Also the rev1.0 has since gone out of production.
So we don't have necessary to support rev1.0 because no one will or

possibly to use rev1.0.

Just to make this clear, the boards we bought all show :

CPU:   Freescale LayerScape LS1021E, Version: 1.0, (0x87081110)

When you mention "rev1.0 haven't delivery to the customer" are you not
referring to Rev 1.0 silicon ?

Regards
Sinan Akman


OK.

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


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



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

[U-Boot] [Patch V6 03/18] net/fm: Fix the endian issue to support both endianness platforms

[Gong Qianyu]

From: Hou Zhiqiang 

The Frame Manager(FMan) is a big-endian peripheral, so the
registers, internal MURAM and BDs, which are allocated in main
memory and used to communication between core and FMan, should
be accessed in big-endian. The big-endian platforms can access
them directly as the code implemented so far, while for the
little-endian platforms it need to swap the byte-order.

Signed-off-by: Hou Zhiqiang 
Signed-off-by: Shaohui Xie 
Signed-off-by: Mingkai Hu 
Signed-off-by: Gong Qianyu 
---
V6:
 - No change.
V5:
 - No change.
V4:
 - No change.
V3:
 - Modify the subject to make the aim clear.
V2:
 - No change.

 drivers/net/fm/eth.c | 70 +++-
 drivers/net/fm/fm.c  | 11 +
 2 files changed, 43 insertions(+), 38 deletions(-)

diff --git a/drivers/net/fm/eth.c b/drivers/net/fm/eth.c
index 6702f5a..368d554 100644
--- a/drivers/net/fm/eth.c
+++ b/drivers/net/fm/eth.c
@@ -109,7 +109,7 @@ static int tgec_is_fibre(struct eth_device *dev)
 static u16 muram_readw(u16 *addr)
 {
u32 base = (u32)addr & ~0x3;
-   u32 val32 = *(u32 *)base;
+   u32 val32 = in_be32((u32 *)base);
int byte_pos;
u16 ret;
 
@@ -125,7 +125,7 @@ static u16 muram_readw(u16 *addr)
 static void muram_writew(u16 *addr, u16 val)
 {
u32 base = (u32)addr & ~0x3;
-   u32 org32 = *(u32 *)base;
+   u32 org32 = in_be32((u32 *)base);
u32 val32;
int byte_pos;
 
@@ -135,7 +135,7 @@ static void muram_writew(u16 *addr, u16 val)
else
val32 = (org32 & 0x) | ((u32)val << 16);
 
-   *(u32 *)base = val32;
+   out_be32((u32 *)base, val32);
 }
 
 static void bmi_rx_port_disable(struct fm_bmi_rx_port *rx_port)
@@ -213,10 +213,10 @@ static int fm_eth_rx_port_parameter_init(struct fm_eth 
*fm_eth)
pram_page_offset = (u32)pram - fm_muram_base(fm_eth->fm_index);
 
/* enable global mode- snooping data buffers and BDs */
-   pram->mode = PRAM_MODE_GLOBAL;
+   out_be32(>mode, PRAM_MODE_GLOBAL);
 
/* init the Rx queue descriptor pionter */
-   pram->rxqd_ptr = pram_page_offset + 0x20;
+   out_be32(>rxqd_ptr, pram_page_offset + 0x20);
 
/* set the max receive buffer length, power of 2 */
muram_writew(>mrblr, MAX_RXBUF_LOG2);
@@ -243,10 +243,11 @@ static int fm_eth_rx_port_parameter_init(struct fm_eth 
*fm_eth)
/* init Rx BDs ring */
rxbd = (struct fm_port_bd *)rx_bd_ring_base;
for (i = 0; i < RX_BD_RING_SIZE; i++) {
-   rxbd->status = RxBD_EMPTY;
-   rxbd->len = 0;
-   rxbd->buf_ptr_hi = 0;
-   rxbd->buf_ptr_lo = (u32)rx_buf_pool + i * MAX_RXBUF_LEN;
+   muram_writew(>status, RxBD_EMPTY);
+   muram_writew(>len, 0);
+   muram_writew(>buf_ptr_hi, 0);
+   out_be32(>buf_ptr_lo, (u32)rx_buf_pool +
+   i * MAX_RXBUF_LEN);
rxbd++;
}
 
@@ -254,7 +255,7 @@ static int fm_eth_rx_port_parameter_init(struct fm_eth 
*fm_eth)
rxqd = >rxqd;
muram_writew(>gen, 0);
muram_writew(>bd_ring_base_hi, 0);
-   rxqd->bd_ring_base_lo = (u32)rx_bd_ring_base;
+   out_be32(>bd_ring_base_lo, (u32)rx_bd_ring_base);
muram_writew(>bd_ring_size, sizeof(struct fm_port_bd)
* RX_BD_RING_SIZE);
muram_writew(>offset_in, 0);
@@ -285,10 +286,10 @@ static int fm_eth_tx_port_parameter_init(struct fm_eth 
*fm_eth)
pram_page_offset = (u32)pram - fm_muram_base(fm_eth->fm_index);
 
/* enable global mode- snooping data buffers and BDs */
-   pram->mode = PRAM_MODE_GLOBAL;
+   out_be32(>mode, PRAM_MODE_GLOBAL);
 
/* init the Tx queue descriptor pionter */
-   pram->txqd_ptr = pram_page_offset + 0x40;
+   out_be32(>txqd_ptr, pram_page_offset + 0x40);
 
/* alloc Tx buffer descriptors from main memory */
tx_bd_ring_base = malloc(sizeof(struct fm_port_bd)
@@ -304,16 +305,17 @@ static int fm_eth_tx_port_parameter_init(struct fm_eth 
*fm_eth)
/* init Tx BDs ring */
txbd = (struct fm_port_bd *)tx_bd_ring_base;
for (i = 0; i < TX_BD_RING_SIZE; i++) {
-   txbd->status = TxBD_LAST;
-   txbd->len = 0;
-   txbd->buf_ptr_hi = 0;
-   txbd->buf_ptr_lo = 0;
+   muram_writew(>status, TxBD_LAST);
+   muram_writew(>len, 0);
+   muram_writew(>buf_ptr_hi, 0);
+   out_be32(>buf_ptr_lo, 0);
+   txbd++;
}
 
/* set the Tx queue decriptor */
txqd = >txqd;
muram_writew(>bd_ring_base_hi, 0);
-   txqd->bd_ring_base_lo = (u32)tx_bd_ring_base;
+   out_be32(>bd_ring_base_lo, (u32)tx_bd_ring_base);
muram_writew(>bd_ring_size, sizeof(struct 

Re: [U-Boot] [PATCH 1/3] ARM: relocate: fix hang when CONFIG_ARMV7_SECURE_BASE

[Albert ARIBAUD]

Hello Peng,

On Mon, 19 Oct 2015 15:19:09 +0800, Peng Fan 
wrote:
> Hi Albert,
> On Mon, Oct 19, 2015 at 08:48:56AM +0200, Albert ARIBAUD wrote:
> >Hello Peng,
> >
> >On Mon, 19 Oct 2015 13:40:51 +0800, Peng Fan 
> >wrote:
> >> On Tue, Oct 06, 2015 at 05:13:24PM -0500, Frank Li wrote:
> >> >When added above configuration, iram fix up plus relocate offset may 
> >> >locate
> >> >in invalidate space. Write back fix up value will cause data abort.
> >> >
> >> >Add address check, skip psci code.
> >> >
> >> >Signed-off-by: Frank Li 
> >> >---
> >> > arch/arm/lib/relocate.S | 4 
> >> > 1 file changed, 4 insertions(+)
> >> >
> >> >diff --git a/arch/arm/lib/relocate.S b/arch/arm/lib/relocate.S
> >> >index 475d503..6795a1b 100644
> >> >--- a/arch/arm/lib/relocate.S
> >> >+++ b/arch/arm/lib/relocate.S
> >> >@@ -99,6 +99,10 @@ fixloop:
> >> >  cmp r1, #23 /* relative fixup? */
> >> >  bne fixnext
> >> > 
> >> >+ ldr r1, =__image_copy_start
> >> >+ cmp r0, r1
> >> >+ blo fixnext
> >> >+
> >> 
> >> Hi Tom, Albert,
> >> 
> >> This is a bug fix, please consider to apply this patch.
> >
> >Sorry for not spotting your patch earlier.
> 
> Not from me -:)
> 
> >
> >Took me some time to understand the commit summary. Let me see if I'm
> >getting this right by paraphrasing it:
> >
> > If CONFIG_ARMV7_SECURE_BASE is defined and if there is
> > a fixup to the location at __image_copy_start, then U-Boot
> > will try to fix that location and since it is write-protected,
> > it will result in a data abort.
> 
> The commit msg needs to be refined.
> 
> >
> >If I got this right, then this raises the following questions:
> >
> >1) if this location cannot be written into for relocation fixup, then
> >how could it be written into for the copying which precedes relocation?
> >
> >2) if there is a fixup to the location, it means that either this
> >location will not work properly without a fix, or the compiler emitted
> >an erroneous relocation record. In either case, just ignoring the fixup
> >seems like papering over the issue.
> >
> >Besides, this patch will prevent image base fixups on all targets, even
> >those for which CONFIG_ARMV7_SECURE_BASE is not defined.
> 
> From my understanding, U-Boot will be relocated to high address of the DRAM 
> space,
> exactly code from __image_copy_start to __image_copy_end.

Correct [minus the pedantic nitpick that __image_copy_start is included
in the copy while __image_copy_end is excluded from it].

> Following is part of the dump of .rel.dyn section of u-boot elf.
> SECURE BASE is 0x18, uboot entry is 0x8780.
> 
> Relocation section '.rel.dyn' at offset 0x577d4 contains 4032 entries:
>  Offset InfoTypeSym.Value  Sym. Name
>  0018410c  0017 R_ARM_RELATIVE   
>  00184154  0017 R_ARM_RELATIVE   
>  0018415c  0017 R_ARM_RELATIVE   
>  00184164  0017 R_ARM_RELATIVE   
>  0018416c  0017 R_ARM_RELATIVE   
>  00184304  0017 R_ARM_RELATIVE   
>  00184368  0017 R_ARM_RELATIVE   
>  87800020  0017 R_ARM_RELATIVE   
>  87800024  0017 R_ARM_RELATIVE   
>  87800028  0017 R_ARM_RELATIVE   
>  8780002c  0017 R_ARM_RELATIVE
> 
> We can see that there are several relocate entries for secure code which is 
> not
> copied to high address of DRAM.
> 
> However SECURE code will not be copied to high address and should not be 
> copied.
> The code locates from __image_copy_start to __image_copy_end are copied to 
> high
> address, after copied, we need to fix variable and function reference, means
> we need to fix this according to the relocation entry. The relocation entry
> for SECURE code is not needed and should not to be fixed, alought they are in
> the rel.dyn section.

Thanks, this makes the situation much clearer -- though not entirely.

Relocation is done by:

a) compiling and linking the image as relocatable code;

a) linking the image for loading and execution at the link-time base
   address (here 0x8780); the image won't work at any other address
   without relocation;

b) copying the code from wherever it was loaded (which may or may not
   be the link-time base address) to its run-time base address (as high
   in DDR as possible); this makes the code unfit for execution until it
   is relocated [pedantry: ... unless the run-time base address happens
   to be the link-time base address] ;

c) fixing the image based on the relocation records, the link-time base
   address, and the run-time base address; this makes the code fit for
   execution again.

So obviously, phase c should only operate on code which was linked
between __image_copy_start [included] and __image_copy_end [excluded].

This could be an argument for checking relocation targets against those
limits... But then, only code that *requires* relocation should have
any relocation record -- IOW, there is no reason for the PSCI code to
have such 

Re: [U-Boot] [PATCH] configs: ls1021atwr: Enable ID EEPROM for SD boot

[Yao Yuan]

Hi Sinan Akman,

Yes, I mean the Rev 1.0 silicon.
Sorry, I can't guarantee that there aren't any boards with Rev1.0 silicon are 
in user's hands.  
Because we have also delivery very little board with Rev1.0 silicon to  
customer  or developer for developing, assessing and verifying in the early 
stages. 
Also we haven't support Rev1.0 in our SDK now.

Thanks.

Best Regards,
Yuan Yao

> -Original Message-
> From: Sinan Akman [mailto:si...@writeme.com]
> Sent: Friday, October 16, 2015 3:37 AM
> To: Sun York-R58495 ; Yuan Yao-B46683
> ; Wang Huan-B18965 
> Cc: u-boot@lists.denx.de
> Subject: Re: [U-Boot] [PATCH] configs: ls1021atwr: Enable ID EEPROM for SD
> boot
> 
> 
>Hi Yuan
> 
> On 15/10/15 12:40 PM, York Sun wrote:
> >
> >
> > On 10/15/2015 12:55 AM, Yuan Yao-B46683 wrote:
> >> Hi york,
> >>
> >> The earlier SoC is just LS1021a rev1.0, but rev1.0 haven't delivery to the
> customer.
> >> Also the rev1.0 has since gone out of production.
> >> So we don't have necessary to support rev1.0 because no one will or
> possibly to use rev1.0.
> 
>Just to make this clear, the boards we bought all show :
> 
> CPU:   Freescale LayerScape LS1021E, Version: 1.0, (0x87081110)
> 
>When you mention "rev1.0 haven't delivery to the customer" are you not
> referring to Rev 1.0 silicon ?
> 
>Regards
>Sinan Akman
> 
> >>
> >
> > OK.
> >
> > York
> > ___
> > U-Boot mailing list
> > U-Boot@lists.denx.de
> > http://lists.denx.de/mailman/listinfo/u-boot
> >
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: sunxi: Add icnova-a20-swac defconfig and dts file

[Stefan Roese]

Hi Hans,

On 17.10.2015 15:47, Hans de Goede wrote:

On 01-10-15 11:41, Stefan Roese wrote:

The ICnova-A20-SWAC is a baseboard, equipped with the ICnova-A20 SoM from
In-Circuit:

http://wiki.in-circuit.de/index.php5?title=ICnova_A20_SODIMM
http://linux-sunxi.org/In-Circuit_ICnova_A20

This patch adds support for this board, including ethernet, LCD and USB
support.


Thanks, I've merged this and it will show up in u-boot-sunxi/next soon.


Thanks.


I've made 2 small changes, see comments inline.





diff --git a/configs/icnova-a20-swac_defconfig
b/configs/icnova-a20-swac_defconfig
new file mode 100644
index 000..bd6e0c5
--- /dev/null
+++ b/configs/icnova-a20-swac_defconfig
@@ -0,0 +1,21 @@
+CONFIG_ARM=y
+CONFIG_ARCH_SUNXI=y
+CONFIG_MACH_SUN7I=y
+CONFIG_DRAM_CLK=384
+CONFIG_OLD_SUNXI_KERNEL_COMPAT=y


I've dropped this, I understand that you need it, but I do not believe that
ANY defconfig's as shipped upstream should set this.


Hmmm. I would prefer to have this added to the defconfig as well.
As it very likely leads to confusion when updating to a newer
U-Boot version which will not support the old kernel. Why not give
the users / maintainers the freedom to choose this for themselves?


+CONFIG_MMC0_CD_PIN="PI5"
+CONFIG_USB0_VBUS_PIN="PG11"
+CONFIG_USB0_VBUS_DET="PH7"
+CONFIG_USB1_VBUS_PIN="PG10"
+CONFIG_VIDEO_LCD_MODE="x:800,y:480,depth:24,pclk_khz:33000,le:45,ri:209,up:22,lo:22,hs:1,vs:1,sync:3,vmode:0"

+CONFIG_VIDEO_LCD_POWER="PH22"
+CONFIG_VIDEO_LCD_PANEL_LVDS=y
+CONFIG_DEFAULT_DEVICE_TREE="sun7i-a20-icnova-a20-swac"
+# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
+CONFIG_SPL=y
+CONFIG_SYS_EXTRA_OPTIONS="AXP209_POWER,SUNXI_GMAC,CMD_BMP,CMD_UNZIP"


I've dropped AXP209_POWER from these, in u-boot-sunxi/next this has been
turned into a Kconfig bool which is enabled by default on sun7i.


Understood.

Thanks,
Stefan

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

Re: [U-Boot] [PATCH] arm: sunxi: Add icnova-a20-swac defconfig and dts file

[Stefan Roese]

Hi Maxime,

On 18.10.2015 11:34, Maxime Ripard wrote:

On 01-10-15 11:41, Stefan Roese wrote:

The ICnova-A20-SWAC is a baseboard, equipped with the ICnova-A20 SoM from
In-Circuit:

http://wiki.in-circuit.de/index.php5?title=ICnova_A20_SODIMM
http://linux-sunxi.org/In-Circuit_ICnova_A20

This patch adds support for this board, including ethernet, LCD and USB
support.


Thanks, I've merged this and it will show up in u-boot-sunxi/next soon.

I've made 2 small changes, see comments inline.


Signed-off-by: Stefan Roese 
Cc: Marcus Heuer 
Cc: Hans de Goede 
Cc: Ian Campbell 
---
  arch/arm/dts/Makefile  |   1 +
  arch/arm/dts/sun7i-a20-icnova-a20-swac.dts | 177 +
  board/sunxi/MAINTAINERS|   5 +
  configs/icnova-a20-swac_defconfig  |  21 
  4 files changed, 204 insertions(+)
  create mode 100644 arch/arm/dts/sun7i-a20-icnova-a20-swac.dts
  create mode 100644 configs/icnova-a20-swac_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 5f10243..1f2661c 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -134,6 +134,7 @@ dtb-$(CONFIG_MACH_SUN7I) += \
sun7i-a20-cubietruck.dtb \
sun7i-a20-hummingbird.dtb \
sun7i-a20-i12-tvbox.dtb \
+   sun7i-a20-icnova-a20-swac.dtb \
sun7i-a20-m3.dtb \
sun7i-a20-m5.dtb \
sun7i-a20-mk808c.dtb \
diff --git a/arch/arm/dts/sun7i-a20-icnova-a20-swac.dts 
b/arch/arm/dts/sun7i-a20-icnova-a20-swac.dts
new file mode 100644


Please submit this file also to the upstream kernel.


Yes. The name of the DT especially doesn't really make sense. The
"SWAC" name isn't referenced anywhere, the module cannot be used
alone, and there's a single combination available (A20 SODIMM +
ADB4006)


At least one other combination is available. A custom board from SWAC
equipped with the SoM. What is the preferred method to support SoM's
with multiple baseboards? Something like:

sun7i-a20-icnova.dtsi
sun7i-a20-icnova-adb4006.dts
sun7i-a20-icnova-swac.dts

?




index 000..773fb6f
--- /dev/null
+++ b/arch/arm/dts/sun7i-a20-icnova-a20-swac.dts
@@ -0,0 +1,177 @@
+/*
+ * Copyright 2013 Maxime Ripard
+ *
+ * Maxime Ripard 


And I'm *not* the copyright owner here.


Okay. Hans, do you want me to change this (and potential other
changes as well - see file naming above) via a follow-up patch
once its available in mainline U-Boot?

Thanks,
Stefan

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

Re: [U-Boot] [PATCH] RFC: dm: Add proposed timeline and guide for porting serial drivers

[Hans de Goede]

Hi,

On 18-10-15 14:18, Simon Glass wrote:

Hi,

On 9 September 2015 at 12:06, Simon Glass  wrote:

Hi,

On Saturday, 5 September 2015, Siarhei Siamashka
 wrote:


On Sat, 5 Sep 2015 15:52:03 +0200
Hans de Goede  wrote:


Hi,

On 05-09-15 15:45, Simon Glass wrote:

Add a README with a brief guide to porting serial drivers over to use
driver model.

Add a timeline also.

Signed-off-by: Simon Glass 




[snip]

Are there any more comments on this patch? Does December seem like a
reasonable deadline to convert serial drivers over?


December seems fine, with the caveat that we need to keep non a non dm
version around for SPL. That or maybe look into doing none dt instantiation
of dm serial ports for the SPL.

Regards,

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

Re: [U-Boot] [PATCH v3 2/2] vexpress64: Juno: Add initialisation code for Juno R1 PCIe host bridge.

[Ryan Harkin]

On 19 October 2015 at 11:08, Liviu Dudau  wrote:

> Juno R1 has an XpressRICH3 PCIe host bridge that needs to be initialised
> in order for the Linux kernel to be able to enumerate the bus. Add
> support code here that enables the host bridge, trains the links and
> sets up the Address Translation Tables.
>
> Signed-off-by: Liviu Dudau 
> Tested-by: Ryan Harkin 
>
Reviewed-by: Ryan Harkin 

---
>  board/armltd/vexpress64/Makefile |   2 +-
>  board/armltd/vexpress64/pcie.c   | 197
> +++
>  board/armltd/vexpress64/pcie.h   |  12 +++
>  board/armltd/vexpress64/vexpress64.c |   2 +
>  4 files changed, 212 insertions(+), 1 deletion(-)
>  create mode 100644 board/armltd/vexpress64/pcie.c
>  create mode 100644 board/armltd/vexpress64/pcie.h
>
> diff --git a/board/armltd/vexpress64/Makefile
> b/board/armltd/vexpress64/Makefile
> index e009141..a35db40 100644
> --- a/board/armltd/vexpress64/Makefile
> +++ b/board/armltd/vexpress64/Makefile
> @@ -5,4 +5,4 @@
>  # SPDX-License-Identifier: GPL-2.0+
>  #
>
> -obj-y  := vexpress64.o
> +obj-y  := vexpress64.o pcie.o
> diff --git a/board/armltd/vexpress64/pcie.c
> b/board/armltd/vexpress64/pcie.c
> new file mode 100644
> index 000..7b999e8
> --- /dev/null
> +++ b/board/armltd/vexpress64/pcie.c
> @@ -0,0 +1,197 @@
> +/*
> + * Copyright (C) ARM Ltd 2015
> + *
> + * Author: Liviu Dudau 
> + *
> + * SPDX-Licence-Identifier:GPL-2.0+
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include "pcie.h"
> +
> +/* XpressRICH3 support */
> +#define XR3_CONFIG_BASE0x7ff3
> +#define XR3_RESET_BASE 0x7ff2
> +
> +#define XR3_PCI_ECAM_START 0x4000
> +#define XR3_PCI_ECAM_SIZE  28  /* as power of 2 =
> 0x1000 */
> +#define XR3_PCI_IOSPACE_START  0x5f80
> +#define XR3_PCI_IOSPACE_SIZE   23  /* as power of 2 =
> 0x80 */
> +#define XR3_PCI_MEMSPACE_START 0x5000
> +#define XR3_PCI_MEMSPACE_SIZE  27  /* as power of 2 =
> 0x800 */
> +#define XR3_PCI_MEMSPACE64_START   0x40
> +#define XR3_PCI_MEMSPACE64_SIZE33  /* as power of 2 =
> 0x2 */
> +
> +#define JUNO_V2M_MSI_START 0x2c1c
> +#define JUNO_V2M_MSI_SIZE  12  /* as power of 2 = 4096 */
> +
> +#define XR3PCI_BASIC_STATUS0x18
> +#define XR3PCI_BS_GEN_MASK (0xf << 8)
> +#define XR3PCI_BS_LINK_MASK0xff
> +
> +#define XR3PCI_VIRTCHAN_CREDITS0x90
> +#define XR3PCI_BRIDGE_PCI_IDS  0x9c
> +#define XR3PCI_PEX_SPC20xd8
> +
> +#define XR3PCI_ATR_PCIE_WIN0   0x600
> +#define XR3PCI_ATR_PCIE_WIN1   0x700
> +#define XR3PCI_ATR_AXI4_SLV0   0x800
> +
> +#define XR3PCI_ATR_TABLE_SIZE  0x20
> +#define XR3PCI_ATR_SRC_ADDR_LOW0x0
> +#define XR3PCI_ATR_SRC_ADDR_HIGH   0x4
> +#define XR3PCI_ATR_TRSL_ADDR_LOW   0x8
> +#define XR3PCI_ATR_TRSL_ADDR_HIGH  0xc
> +#define XR3PCI_ATR_TRSL_PARAM  0x10
> +
> +/* IDs used in the XR3PCI_ATR_TRSL_PARAM */
> +#define XR3PCI_ATR_TRSLID_AXIDEVICE(0x420004)
> +#define XR3PCI_ATR_TRSLID_AXIMEMORY(0x4e0004)  /* Write-through,
> read/write allocate */
> +#define XR3PCI_ATR_TRSLID_PCIE_CONF(0x01)
> +#define XR3PCI_ATR_TRSLID_PCIE_IO  (0x02)
> +#define XR3PCI_ATR_TRSLID_PCIE_MEMORY  (0x00)
> +
> +#define XR3PCI_ECAM_OFFSET(b, d, o)(((b) << 20) | \
> +   (PCI_SLOT(d) << 15) | \
> +   (PCI_FUNC(d) << 12) | o)
> +
> +#define JUNO_RESET_CTRL0x1004
> +#define JUNO_RESET_CTRL_PHYBIT(0)
> +#define JUNO_RESET_CTRL_RC BIT(1)
> +
> +#define JUNO_RESET_STATUS  0x1008
> +#define JUNO_RESET_STATUS_PLL  BIT(0)
> +#define JUNO_RESET_STATUS_PHY  BIT(1)
> +#define JUNO_RESET_STATUS_RC   BIT(2)
> +#define JUNO_RESET_STATUS_MASK (JUNO_RESET_STATUS_PLL | \
> +JUNO_RESET_STATUS_PHY | \
> +JUNO_RESET_STATUS_RC)
> +
> +void xr3pci_set_atr_entry(unsigned long base, unsigned long src_addr,
> +   unsigned long trsl_addr, int window_size,
> +   int trsl_param)
> +{
> +   /* X3PCI_ATR_SRC_ADDR_LOW:
> +- bit 0: enable entry,
> +- bits 1-6: ATR window size: total size in bytes:
> 2^(ATR_WSIZE + 1)
> +- bits 7-11: reserved
> +- bits 12-31: start of source address
> +   */
> +   writel((u32)(src_addr & 0xf000) | (window_size - 1) << 1 | 1,
> +  base + XR3PCI_ATR_SRC_ADDR_LOW);
> +   writel((u32)(src_addr >> 32), base + 

Re: [U-Boot] [PATCH 1/3] ARM: relocate: fix hang when CONFIG_ARMV7_SECURE_BASE

[Peng Fan]

Hi Albert,
On Mon, Oct 19, 2015 at 10:23:40AM +0200, Albert ARIBAUD wrote:
>Hello Peng,
>
>On Mon, 19 Oct 2015 15:19:09 +0800, Peng Fan 
>wrote:
>> Hi Albert,
>> On Mon, Oct 19, 2015 at 08:48:56AM +0200, Albert ARIBAUD wrote:
>> >Hello Peng,
>> >
>> >On Mon, 19 Oct 2015 13:40:51 +0800, Peng Fan 
>> >wrote:
>> >> On Tue, Oct 06, 2015 at 05:13:24PM -0500, Frank Li wrote:
>> >> >When added above configuration, iram fix up plus relocate offset may 
>> >> >locate
>> >> >in invalidate space. Write back fix up value will cause data abort.
>> >> >
>> >> >Add address check, skip psci code.
>> >> >
>> >> >Signed-off-by: Frank Li 
>> >> >---
>> >> > arch/arm/lib/relocate.S | 4 
>> >> > 1 file changed, 4 insertions(+)
>> >> >
>> >> >diff --git a/arch/arm/lib/relocate.S b/arch/arm/lib/relocate.S
>> >> >index 475d503..6795a1b 100644
>> >> >--- a/arch/arm/lib/relocate.S
>> >> >+++ b/arch/arm/lib/relocate.S
>> >> >@@ -99,6 +99,10 @@ fixloop:
>> >> > cmp r1, #23 /* relative fixup? */
>> >> > bne fixnext
>> >> > 
>> >> >+ldr r1, =__image_copy_start
>> >> >+cmp r0, r1
>> >> >+blo fixnext
>> >> >+
>> >> 
>> >> Hi Tom, Albert,
>> >> 
>> >> This is a bug fix, please consider to apply this patch.
>> >
>> >Sorry for not spotting your patch earlier.
>> 
>> Not from me -:)
>> 
>> >
>> >Took me some time to understand the commit summary. Let me see if I'm
>> >getting this right by paraphrasing it:
>> >
>> >If CONFIG_ARMV7_SECURE_BASE is defined and if there is
>> >a fixup to the location at __image_copy_start, then U-Boot
>> >will try to fix that location and since it is write-protected,
>> >it will result in a data abort.
>> 
>> The commit msg needs to be refined.
>> 
>> >
>> >If I got this right, then this raises the following questions:
>> >
>> >1) if this location cannot be written into for relocation fixup, then
>> >how could it be written into for the copying which precedes relocation?
>> >
>> >2) if there is a fixup to the location, it means that either this
>> >location will not work properly without a fix, or the compiler emitted
>> >an erroneous relocation record. In either case, just ignoring the fixup
>> >seems like papering over the issue.
>> >
>> >Besides, this patch will prevent image base fixups on all targets, even
>> >those for which CONFIG_ARMV7_SECURE_BASE is not defined.
>> 
>> From my understanding, U-Boot will be relocated to high address of the DRAM 
>> space,
>> exactly code from __image_copy_start to __image_copy_end.
>
>Correct [minus the pedantic nitpick that __image_copy_start is included
>in the copy while __image_copy_end is excluded from it].
>
>> Following is part of the dump of .rel.dyn section of u-boot elf.
>> SECURE BASE is 0x18, uboot entry is 0x8780.
>> 
>> Relocation section '.rel.dyn' at offset 0x577d4 contains 4032 entries:
>>  Offset InfoTypeSym.Value  Sym. Name
>>  0018410c  0017 R_ARM_RELATIVE   
>>  00184154  0017 R_ARM_RELATIVE   
>>  0018415c  0017 R_ARM_RELATIVE   
>>  00184164  0017 R_ARM_RELATIVE   
>>  0018416c  0017 R_ARM_RELATIVE   
>>  00184304  0017 R_ARM_RELATIVE   
>>  00184368  0017 R_ARM_RELATIVE   
>>  87800020  0017 R_ARM_RELATIVE   
>>  87800024  0017 R_ARM_RELATIVE   
>>  87800028  0017 R_ARM_RELATIVE   
>>  8780002c  0017 R_ARM_RELATIVE
>> 
>> We can see that there are several relocate entries for secure code which is 
>> not
>> copied to high address of DRAM.
>> 
>> However SECURE code will not be copied to high address and should not be 
>> copied.
>> The code locates from __image_copy_start to __image_copy_end are copied to 
>> high
>> address, after copied, we need to fix variable and function reference, means
>> we need to fix this according to the relocation entry. The relocation entry
>> for SECURE code is not needed and should not to be fixed, alought they are in
>> the rel.dyn section.
>
>Thanks, this makes the situation much clearer -- though not entirely.
>
>Relocation is done by:
>
>a) compiling and linking the image as relocatable code;
>
>a) linking the image for loading and execution at the link-time base
>   address (here 0x8780); the image won't work at any other address
>   without relocation;
>
>b) copying the code from wherever it was loaded (which may or may not
>   be the link-time base address) to its run-time base address (as high
>   in DDR as possible); this makes the code unfit for execution until it
>   is relocated [pedantry: ... unless the run-time base address happens
>   to be the link-time base address] ;
>
>c) fixing the image based on the relocation records, the link-time base
>   address, and the run-time base address; this makes the code fit for
>   execution again.
>
>So obviously, phase c should only operate on code which was linked
>between __image_copy_start [included] and __image_copy_end 

Re: [U-Boot] [PATCH v2 2/2] vexpress64: Juno: Add initialisation code for Juno R1 PCIe host bridge.

[Ryan Harkin]

On 19 October 2015 at 10:10, Liviu Dudau  wrote:

> On Fri, 16 Oct 2015 17:58:44 +0100
> Ryan Harkin  wrote:
>
> > Hi Liviu,
> >
> > These patches work well for me, so at the very least, you can add my
> > Test-by for both:
> >
> > Tested-by: Ryan Harkin 
>
> Hi Ryan,
>
> Thanks for testing this patchset.
>
> >
> > But...
> >
> > I ran checkpatch.pl across your patches and this one throws a few
> trivial
> > warnings, mostly about 80 character lines and a few like this:
> >
> > CHECK: Prefer using the BIT macro
> > #97: FILE: board/armltd/vexpress64/pcie.c:60:
> > +#define JUNO_RESET_CTRL_PHY(1 << 0)
> >
> > But also these:
> >
> > WARNING: long udelay - prefer mdelay; see arch/arm/include/asm/delay.h
> > #208: FILE: board/armltd/vexpress64/pcie.c:171:
> > +udelay(2);
> >
> > CHECK: Please don't use multiple blank lines
> > #227: FILE: board/armltd/vexpress64/pcie.c:190:
> > +
> > +
> >
> > CHECK: Please don't use multiple blank lines
> > #251: FILE: board/armltd/vexpress64/pcie.h:12:
> > +
> > +
>
> Interesting, when running ./scripts/checkpatch.pl in my copy of U-Boot I
> get the 7 warnings about lines over 80 characters long, and the
> following message:
>
> NOTE: Ignored message types: COMPLEX_MACRO CONSIDER_KSTRTO MINMAX
> MULTISTATEMENT_MACRO_USE_DO_WHILE NETWORKING_BLOCK_COMMENT_STYLE
> USLEEP_RANGE
>
> I see the same message when I run checkpatch.


> Not sure how to enable all the types by default and also the reason why
> I've missed them.
>

Er, I think I have done something wrong... I ran checkpatch.pl from my
kernel tree, not from the u-boot tree.  U-boot's checkpatch.pl doesn't give
me those extra warnings.  Sorry about that!  It seems that u-boot is still
using an older checkpatch.  Still, your v3 patch looks much nicer now.
Ahem.


> >
> > I'm not sure who strict the rules are followed for these types of
> warning.
> > But if you are fixing up, I also noticed a couple of whitespace nits
> below.
> >
> >
> > On 16 October 2015 at 15:41, Liviu Dudau 
> wrote:
> >
> > > Juno R1 has an XpressRICH3 PCIe host bridge that needs to be
> initialised
> > > in order for the Linux kernel to be able to enumerate the bus. Add
> > > support code here that enables the host bridge, trains the links and
> > > sets up the Address Translation Tables.
> > >
> > > Signed-off-by: Liviu Dudau 
> > > ---
> > >  board/armltd/vexpress64/Makefile |   2 +-
> > >  board/armltd/vexpress64/pcie.c   | 196
> > > +++
> > >  board/armltd/vexpress64/pcie.h   |  13 +++
> > >  board/armltd/vexpress64/vexpress64.c |   2 +
> > >  4 files changed, 212 insertions(+), 1 deletion(-)
> > >  create mode 100644 board/armltd/vexpress64/pcie.c
> > >  create mode 100644 board/armltd/vexpress64/pcie.h
> > >
> > > diff --git a/board/armltd/vexpress64/Makefile
> > > b/board/armltd/vexpress64/Makefile
> > > index e009141..a35db40 100644
> > > --- a/board/armltd/vexpress64/Makefile
> > > +++ b/board/armltd/vexpress64/Makefile
> > > @@ -5,4 +5,4 @@
> > >  # SPDX-License-Identifier: GPL-2.0+
> > >  #
> > >
> > > -obj-y  := vexpress64.o
> > > +obj-y  := vexpress64.o pcie.o
> > > diff --git a/board/armltd/vexpress64/pcie.c
> > > b/board/armltd/vexpress64/pcie.c
> > > new file mode 100644
> > > index 000..367efd4
> > > --- /dev/null
> > > +++ b/board/armltd/vexpress64/pcie.c
> > > @@ -0,0 +1,196 @@
> > > +/*
> > > + * Copyright (C) ARM Ltd 2015
> > > + *
> > > + * Author: Liviu Dudau 
> > > + *
> > > + * SPDX-Licence-Identifier:GPL-2.0+
> > > + */
> > > +
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include "pcie.h"
> > > +
> > > +/* XpressRICH3 support */
> > > +#define XR3_CONFIG_BASE0x7ff3
> > > +#define XR3_RESET_BASE 0x7ff2
> > > +
> > > +#define XR3_PCI_ECAM_START 0x4000
> > > +#define XR3_PCI_ECAM_SIZE  28  /* as power of 2 =
> > > 0x1000 */
> > > +#define XR3_PCI_IOSPACE_START  0x5f80
> > > +#define XR3_PCI_IOSPACE_SIZE   23  /* as power of 2 =
> > > 0x80 */
> > > +#define XR3_PCI_MEMSPACE_START 0x5000
> > > +#define XR3_PCI_MEMSPACE_SIZE  27  /* as power of 2 =
> > > 0x800 */
> > > +#define XR3_PCI_MEMSPACE64_START   0x40
> > > +#define XR3_PCI_MEMSPACE64_SIZE33  /* as power of
> 2 =
> > > 0x2 */
> > > +
> > > +#define JUNO_V2M_MSI_START 0x2c1c
> > > +#define JUNO_V2M_MSI_SIZE  12  /* as power of 2 =
> 4096 */
> > > +
> > > +#define XR3PCI_BASIC_STATUS0x18
> > > +#defineXR3PCI_BS_GEN_MASK  (0xf << 8)
> > > +#defineXR3PCI_BS_LINK_MASK 0xff
> > >
> >
> > There's some strange extra whitespace in there...
> >
> > +
> > > +#define XR3PCI_VIRTCHAN_CREDITS0x90

Re: [U-Boot] [PATCH 4/5] dm: usb: Add support for USB keyboards with driver model

[Hans de Goede]

Hi,

On 19-10-15 01:17, Simon Glass wrote:

Hi Hans,

On 12 September 2015 at 09:15, Hans de Goede  wrote:

Hi,

On 08-09-15 19:15, Simon Glass wrote:


Switch USB keyboards over to use driver model instead of scanning with the
horrible usb_get_dev_index() function. This involves creating a new uclass
for keyboards, although so far there is no API.

Signed-off-by: Simon Glass 



In general I like this patch, so ack for the principle, but the
implementation has issues.

You're now allowing the registration of multiple usb keyb stdio
input devices, but you are still relying on usb_kbd_deregister()
to remove them from the stdio devices list, and when multiple
or used that one will only remove the first one.

This can be fixed by switching to stdio_register_dev, and
store the returned struct stdio_dev pointer for the new dev,
and add a dm remove callback which deregisters that specific
stdio_dev that will also remove the ugliness of looking up
the device by its name to unregister it.

The name which in itself is another, harder to fix issue,
when using iomux, and the stdin string contains usbkbd we
really want to get all usbkbd-s to work, but iomux will
only take the first one.

This can be fixed in 2 ways:

1) in the usbkbd driver by registering a shared stdio_dev
for all usbkbd's and deregistering that only when the
last usbkbd is removed (in the case of dm), this will
require a global list of usbkbd devices, and stdio
callbacks to walk over this list, I believe that this
is likely the best approach

2) Fix this in iomux, and make it look for multiple
devs with the same name and mux them all.

This seems cleaner at a conceptual level, but likely
somewhat hard to implement.



I've had another look at this and here are my comments so far:

1. The existing driver does not support multiple keyboards. It
implements this limitation in multiple ways which would be a real pain
to fix while keeping the old code. I think it makes much more sense to
remove this limitation when we have either a) moved all uses of USB
keyboard to driver model, or perhaps b) moved stdio to driver model.
For now the driver model approach provides the same functionality as
before so I think it is fine.


I think that supporting multiple keyboards the way I've outlined
above as "1)" should not be that hard. But I do not plan to make time
for this anytime soon, and as such I can hardly ask you to do this.

So I reluctantly agree to keep this as is (I was hoping the move
to dm would fix this).


2. The point about out-of-order devices in the 'usb tree'
displaywell if you disable unbinding that is what you get. I'm
sure we could fix it by sorting the devices before displaying them,
but it does not seem that important to me. It is more likely that the
unbind support will be enabled in U-Boot proper, and perhaps disabled
in SPL, which doesn't have commands anyway.


I'm fine with "usb tree" showing things the wrong way on builds where
unbinding is disabled. But if I remember the patch-set this thread is
about correctly, it completely removed unbinding from the usb code.

If you do a new version where unbinding is only skipped when compiled
out then that is fine with me.

Regards,

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

Re: [U-Boot] [PATCH] arm: sunxi: Add icnova-a20-swac defconfig and dts file

[Stefan Roese]

Hi Hans,

On 17.10.2015 15:47, Hans de Goede wrote:

On 01-10-15 11:41, Stefan Roese wrote:

The ICnova-A20-SWAC is a baseboard, equipped with the ICnova-A20 SoM from
In-Circuit:

http://wiki.in-circuit.de/index.php5?title=ICnova_A20_SODIMM
http://linux-sunxi.org/In-Circuit_ICnova_A20

This patch adds support for this board, including ethernet, LCD and USB
support.


Thanks, I've merged this and it will show up in u-boot-sunxi/next soon.


Thanks.


I've made 2 small changes, see comments inline.





diff --git a/configs/icnova-a20-swac_defconfig
b/configs/icnova-a20-swac_defconfig
new file mode 100644
index 000..bd6e0c5
--- /dev/null
+++ b/configs/icnova-a20-swac_defconfig
@@ -0,0 +1,21 @@
+CONFIG_ARM=y
+CONFIG_ARCH_SUNXI=y
+CONFIG_MACH_SUN7I=y
+CONFIG_DRAM_CLK=384
+CONFIG_OLD_SUNXI_KERNEL_COMPAT=y


I've dropped this, I understand that you need it, but I do not believe that
ANY defconfig's as shipped upstream should set this.


Hmmm. I would prefer to have this added to the defconfig as well.
As it very likely leads to confusion when updating to a newer
U-Boot version which will not support the old kernel. Why not give
the users / maintainers the freedom to choose this for themselves?


+CONFIG_MMC0_CD_PIN="PI5"
+CONFIG_USB0_VBUS_PIN="PG11"
+CONFIG_USB0_VBUS_DET="PH7"
+CONFIG_USB1_VBUS_PIN="PG10"
+CONFIG_VIDEO_LCD_MODE="x:800,y:480,depth:24,pclk_khz:33000,le:45,ri:209,up:22,lo:22,hs:1,vs:1,sync:3,vmode:0"

+CONFIG_VIDEO_LCD_POWER="PH22"
+CONFIG_VIDEO_LCD_PANEL_LVDS=y
+CONFIG_DEFAULT_DEVICE_TREE="sun7i-a20-icnova-a20-swac"
+# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
+CONFIG_SPL=y
+CONFIG_SYS_EXTRA_OPTIONS="AXP209_POWER,SUNXI_GMAC,CMD_BMP,CMD_UNZIP"


I've dropped AXP209_POWER from these, in u-boot-sunxi/next this has been
turned into a Kconfig bool which is enabled by default on sun7i.


Understood.

Thanks,
Stefan

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

Re: [U-Boot] [PATCH v4] nios2: convert dma_alloc_coherent to use malloc_cache_aligned

[Thomas Chou]

Hi Albert,

On 10/19/2015 01:52 PM, Albert ARIBAUD wrote:

Not sure I'm getting this, so for my own education: what prevents from
invalidating the cache, or IOW, what would happen if it was invalidated
at this point rather than flushed?


This is a hardware limitation. The nios2 cpu with 4 bytes dcache line 
size does not support the initda instruction, which is needed to 
invalidate dcache.


Recently we added a check, if the nios2 cpu support initda instruction, 
then we use invalidate_dcache, otherwise we use flush_dcache.


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

Re: [U-Boot] [PATCH v4 00/21] sf: Tunning spi-flash layer

[Jagan Teki]

Hi Simon,

On 19 October 2015 at 01:57, Simon Glass  wrote:
> Hi Jagan,
>
> On 12 October 2015 at 09:00, Jagan Teki  wrote:
>> Previous version link:
>> http://permalink.gmane.org/gmane.comp.boot-loaders.u-boot/233262
>>
>> spi-flash layer need to tune a lot for better code handling and
>> to sync with Linux spi-nor. So below areas got updated in this series.
>> - BAR handling
>> - spi_flash_cmd_wait_ready updates.
>> - Separate core spi-flash handling and spi-flash interface
>>   (interface between spi drivers vs spi-flash layer)
>>
>> Currently I'm working on spi-nor framework for u-boot which
>> is slighly same as Linux spi-nor core with addition of
>> u-boot driver model to it.
>>
>> This series will be starting point to add spi-nor functionalities.
>>
>> TODO:
>> - MTD core addition to spi-flash layer.
>> - spi-nor core addition.
>>
>> Code sizes:
>> After:
>> dm:
>>textdata bss dec hex filename
>>  354820   12016  221112  587948   8f8ac u-boot
>> non-dm
>>textdata bss dec hex filename
>>  354317   11876  221124  587317   8f635 u-boot
>>
>> Before:
>> dm
>>textdata bss dec hex filename
>>  354878   12016  221096  587990   8f8d6 u-boot
>> non-dm
>>textdata bss dec hex filename
>>  354447   11876  221124  587447   8f6b7 u-boot
>
> I don't think you should be adding new features to the
> non-driver-model SPI flash code. We are supposed to be migrating
> everything to driver model, so it would be better to move your boards
> over, and then work to deprecate and remove the old code. Adding new
> features to it sends the wrong message.

spi-flash core code doesn't require to add driver model, and cmd_sf to
spi-flash code is already supporting driver model.

OK, let me explain in-detail.

Code in sf_probe.c supports both dm and non dm-spi-flash and flash
initialization code using
spi_flash_validate_params. sf.c acts as interface between spi drivers
vs spi-flash code.
So the spi-flash initialization code(part of sf_probe) and code in
sf_ops are commonly categorized as spi-flash core code and this will
not require driver model, so-that the dm drivers will simply use this
common code for spi-flash core functionality.

This patch series will separate all the necessary existing code into
core and spi-flash vs spi drivers interface code. So at ends
- sf_probe is simply the copy of sf.c and dm and non-dm spi-flash code
so this will acts a spi-flash vs spi drivers interface. (which has dm
and non-dm as same as before)
- sf_ops is core spi-flash functionality.

On top of this I'm adding actual spi-nor core code, where sf_ops.c
will become spi-nor.c and sf_probe.c will become spi-nor-flash.c.
- spi-nor.c: Core SPI NOR
- spi-nor-flash: spi drivers vs spi-nor interface (which has dm and
non-dm as same as before)

The reason for adding this spi-nor is to move flash code from
spi-drivers, example fsl_qspi and at the end this fsl_qspi will move
from spi drivers to spi-nor that will be in driver model.

I'm simply adding new core functionality with adding new drivers as
dm-driven, I don't think this will not effect/change the driver model
growth.

 View of spi-nor framework:

-
cmd_sf
-
spi_flash
-
MTD Core
-
sf-uclass
-
SPI-NOR
-
spi-nor-flash   drivers/mtd/spi/*
-
spi-uclass
-
drivers/spi/*
-

drivers/mtd/spi/spi-nor.c: spi-nor core (not require to add dm)
drivers/mtd/spi/spi-flash-nor.c: spi-nor to spi drivers interface (dm-driven)
drivers/mtd/spi/fsl-quadspi.c: spi-nor controller driver (dm-driven)

Please let me know for any more comments.

>
> Sorry if I am misunderstanding your intent here.
>
>>
>> Testing:
>> $ git clone git://git.denx.de/u-boot-spi.git
>> $ cd u-boot-spi
>> $ git checkout -b spi-nor-tune origin/next-spi-nor-tune
>>
>> thanks!
>> Jagan.
>>
>> Jagan Teki (21):
>>   spi: zynq_spi: Remove unneeded headers
>>   sf: Return bank_sel, if flash->bank_curr == bank_sel
>>   sf: Add spi_flash_read_bar
>>   sf: Optimize BAR write code
>>   sf: Make flash->flags use for generic usage
>>   sf: Update status reg check in spi_flash_cmd_wait_ready
>>   sf: Add FSR support to spi_flash_cmd_wait_ready
>>   sf: spi_flash_validate_params => spi_flash_scan
>>   sf: Move spi_flash_scan code to sf_ops
>>   sf: Move the read_id code to sf_ops
>>   sf: Move BAR 

Re: [U-Boot] [PATCH v2 2/2] arm: fix compile warnings when semihosting is enabled on ARMv7M target.

[Vadzim Dambrouski]

On 19.10.2015 09:06, Albert ARIBAUD wrote:

Hello Vadzim,

On Mon, 19 Oct 2015 00:13:29 +0300, Vadzim Dambrouski
 wrote:

Signed-off-by: Vadzim Dambrouski 
---

  arch/arm/lib/semihosting.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/lib/semihosting.c b/arch/arm/lib/semihosting.c
index ed5e8e4..6541cb4 100644
--- a/arch/arm/lib/semihosting.c
+++ b/arch/arm/lib/semihosting.c
@@ -92,7 +92,7 @@ static long smh_read(long fd, void *memp, size_t len)
size_t len;
} read;

-   debug("%s: fd %ld, memp %p, len %lu\n", __func__, fd, memp, len);
+   debug("%s: fd %ld, memp %p, len %lu\n", __func__, fd, memp, (ulong)len);

read.fd = fd;
read.memp = memp;
@@ -107,7 +107,7 @@ static long smh_read(long fd, void *memp, size_t len)
 * with an error message.
 */
printf("%s: ERROR ret %ld, fd %ld, len %lu memp %p\n",
-  __func__, ret, fd, len, memp);
+  __func__, ret, fd, (ulong)len, memp);
return -1;
}


len is a size_t; it should not be force-converted into a long, it
should be printed using a 'z' qualifier.

Amicalement,



Well, you are right, I'll send another revision of this patch set.
Thank you for all your assistance.

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

Re: [U-Boot] [PATCH v4] nios2: convert dma_alloc_coherent to use malloc_cache_aligned

[Albert ARIBAUD]

Hello Thomas,

On Mon, 19 Oct 2015 16:18:06 +0800, Thomas Chou 
wrote:
> Hi Albert,
> 
> On 10/19/2015 01:52 PM, Albert ARIBAUD wrote:
> > Not sure I'm getting this, so for my own education: what prevents from
> > invalidating the cache, or IOW, what would happen if it was invalidated
> > at this point rather than flushed?
> 
> This is a hardware limitation. The nios2 cpu with 4 bytes dcache line 
> size does not support the initda instruction, which is needed to 
> invalidate dcache.
> 
> Recently we added a check, if the nios2 cpu support initda instruction, 
> then we use invalidate_dcache, otherwise we use flush_dcache.

Now I understand. Thanks!

> Best regards,
> Thomas

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

Re: [U-Boot] [ELCE2015] Question about schedule

[Lukasz Majewski]

Hi Bin,

> Hi Lukasz,
> 
> On Tue, Oct 13, 2015 at 7:17 PM, Lukasz Majewski
>  wrote:
> > Hi Bin,
> >
> >> Hi,
> >>
> >> On Fri, Oct 2, 2015 at 6:34 AM, Tom Rini 
> >> wrote:
> >> > On Thu, Oct 01, 2015 at 10:38:50AM +0200, Lukasz Majewski wrote:
> >> >
> >> >> Hi Tom,
> >> >>
> >> >> Is there any schedule for our ELCE2015 u-boot mini summit [1]?
> >> >> To be more precise
> >> >> - are know times when we will deliver our presentations?
> >> >>
> >> >>
> >> >>
> >> >> [1] - http://www.denx.de/wiki/U-Boot/SummitELCE2015
> >> >
> >> > So no, we don't have a formal schedule at this time.  My kind of
> >> > plan at this point is to start off with the formal talks.  Then
> >> > move into a "5 minute" status from the custodians present on
> >> > where they're at in their area.  After that, sort out some
> >> > priorities on Kconfig/DT.
> >> >
> >> > Oh, and I plan to try and have a Google Hangout up so that people
> >> > that can't make it can at least watch and maybe chime in.
> >> >
> >> > --
> >>
> >> Are there any slides presented in the summit available somewhere?
> >> Or any video clips?
> >
> > I'm going to upload my slides to the Mini-Summit webpage.
> >
> 
> Thank you. But I don't see your slides on
> http://www.denx.de/wiki/U-Boot/SummitELCE2015?

Please check now.

> 
> Regards,
> Bin



-- 
Best regards,

Lukasz Majewski

Samsung R Institute Poland (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [ELCE2015] Question about schedule

[Bin Meng]

Hi Lukasz,

On Mon, Oct 19, 2015 at 4:36 PM, Lukasz Majewski  wrote:
> Hi Bin,
>
>> Hi Lukasz,
>>
>> On Tue, Oct 13, 2015 at 7:17 PM, Lukasz Majewski
>>  wrote:
>> > Hi Bin,
>> >
>> >> Hi,
>> >>
>> >> On Fri, Oct 2, 2015 at 6:34 AM, Tom Rini 
>> >> wrote:
>> >> > On Thu, Oct 01, 2015 at 10:38:50AM +0200, Lukasz Majewski wrote:
>> >> >
>> >> >> Hi Tom,
>> >> >>
>> >> >> Is there any schedule for our ELCE2015 u-boot mini summit [1]?
>> >> >> To be more precise
>> >> >> - are know times when we will deliver our presentations?
>> >> >>
>> >> >>
>> >> >>
>> >> >> [1] - http://www.denx.de/wiki/U-Boot/SummitELCE2015
>> >> >
>> >> > So no, we don't have a formal schedule at this time.  My kind of
>> >> > plan at this point is to start off with the formal talks.  Then
>> >> > move into a "5 minute" status from the custodians present on
>> >> > where they're at in their area.  After that, sort out some
>> >> > priorities on Kconfig/DT.
>> >> >
>> >> > Oh, and I plan to try and have a Google Hangout up so that people
>> >> > that can't make it can at least watch and maybe chime in.
>> >> >
>> >> > --
>> >>
>> >> Are there any slides presented in the summit available somewhere?
>> >> Or any video clips?
>> >
>> > I'm going to upload my slides to the Mini-Summit webpage.
>> >
>>
>> Thank you. But I don't see your slides on
>> http://www.denx.de/wiki/U-Boot/SummitELCE2015?
>
> Please check now.
>

Yes, I see it now. Thanks!

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

Re: [U-Boot] [ELCE2015] Question about schedule

[Simon Glass]

Hi,

On 19 October 2015 at 03:17, Bin Meng  wrote:
> Hi Lukasz,
>
> On Mon, Oct 19, 2015 at 4:36 PM, Lukasz Majewski  
> wrote:
>> Hi Bin,
>>
>>> Hi Lukasz,
>>>
>>> On Tue, Oct 13, 2015 at 7:17 PM, Lukasz Majewski
>>>  wrote:
>>> > Hi Bin,
>>> >
>>> >> Hi,
>>> >>
>>> >> On Fri, Oct 2, 2015 at 6:34 AM, Tom Rini 
>>> >> wrote:
>>> >> > On Thu, Oct 01, 2015 at 10:38:50AM +0200, Lukasz Majewski wrote:
>>> >> >
>>> >> >> Hi Tom,
>>> >> >>
>>> >> >> Is there any schedule for our ELCE2015 u-boot mini summit [1]?
>>> >> >> To be more precise
>>> >> >> - are know times when we will deliver our presentations?
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> [1] - http://www.denx.de/wiki/U-Boot/SummitELCE2015
>>> >> >
>>> >> > So no, we don't have a formal schedule at this time.  My kind of
>>> >> > plan at this point is to start off with the formal talks.  Then
>>> >> > move into a "5 minute" status from the custodians present on
>>> >> > where they're at in their area.  After that, sort out some
>>> >> > priorities on Kconfig/DT.
>>> >> >
>>> >> > Oh, and I plan to try and have a Google Hangout up so that people
>>> >> > that can't make it can at least watch and maybe chime in.
>>> >> >
>>> >> > --
>>> >>
>>> >> Are there any slides presented in the summit available somewhere?
>>> >> Or any video clips?
>>> >
>>> > I'm going to upload my slides to the Mini-Summit webpage.
>>> >
>>>
>>> Thank you. But I don't see your slides on
>>> http://www.denx.de/wiki/U-Boot/SummitELCE2015?
>>
>> Please check now.
>>
>
> Yes, I see it now. Thanks!

I uploaded mine also. I did not do any for buildman.

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

Re: [U-Boot] Porting UBI fixes (specially fastmap's) to U-Boot

[Ezequiel Garcia]

On 19 October 2015 at 02:17, Heiko Schocher  wrote:
> Hello Ezequiel,
>
> Am 17.10.2015 um 20:07 schrieb Ezequiel Garcia:
>>
>> Hi Heiko,
>>
>> On 9 October 2015 at 09:30, Heiko Schocher  wrote:
>> [..]
>>>
>>>
>>>
>>> I just updated the "ubi_sync_with_linux" branch on u-boot-ubi.
>>>
>>> It seems UBI/UBIFS now work with the NAND on the aristainetos2
>>> board, but my stomach says, there are some subtile issues ...
>>>
>>> Still needs more testing, also not tested yet UBI on the SPI NOR on
>>> this board.
>>>
>>> If I "nand erase" the mtd device, and try "ubi part ..." it fails
>>>
>>> :-(
>>>
>>> But If I flash_eraseall under linux the device, and then make
>>> "ubi part..." in U-Boot, commmand succeeds ...
>>>
>>
>> Tested it on my custom AM335x board. Haven't used mainline U-Boot
>> but cherry-picked the following commits:
>>
>>linux, compat: add missing definitions for ubi
>>ubi/ubifs: some bugfixes
>>ubi,ubifs: sync with linux v4.2
>>ubi: reset mtd_devs when ubi part fail
>>
>> Commits apply cleanly except for "linux, compat: add missing
>> definitions for ubi"
>> which was trivial to backport anyway.
>>
>> U-Boot built fine, but there was a warning:
>>
>> drivers/mtd/ubi/fastmap.c: In function 'ubi_attach_fastmap':
>> drivers/mtd/ubi/fastmap.c:816:2: warning: pointer targets in passing
>> argument 3 of 'scan_pool' differ in signedness [-Wpointer-sign]
>>ret = scan_pool(ubi, ai, fmpl->pebs, pool_size, _sqnum, );
>>
>> Just sent this patch which should fix it:
>> http://patchwork.ozlabs.org/patch/531842/
>
>
> Thanks for fixing. With it, I see no compiler warning anymore.
> Applied to u-boot-ubi.git ubi_sync_with_linux
>
> Tried this branch on the aristainetos2 board with ubi/ubifs on nand and
> spi nor flash, worked fine, see log:
>
> http://xeidos.ddns.net/buildbot/builders/ari_ubi/builds/7
> http://xeidos.ddns.net/buildbot/builders/ari_ubi/builds/7/steps/shell/logs/tbotlog
>
>> The board seems to work fine, and I can even to "nand erase" and "ubi
>> part" without
>> any problem.
>
>
> Did you tried "ubi part" more than once in a row?
>

Yup, I can do "ubi part $mypart" several times. And can also do "nand
erase.part foo"
and then "ubi part foo" several times.

The patches seem to work fine here, so:

Tested-by: Ezequiel Garcia 

>> However, I'm still seeing the same warning I had before, when my partition
>> is attached:
>>
>> ubi0: default fastmap pool size: 200
>> ubi0: default fastmap WL pool size: 100
>> ubi0: attaching mtd1
>> WARNING in drivers/mtd/ubi/fastmap.c line 846
>> ubi0: scanning is finished
>> ubi0: attached mtd1 (name "mtd=7", size 509 MiB)
>> ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 129024 bytes
>> ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 512
>> ubi0: VID header offset: 512 (aligned 512), data offset: 2048
>> ubi0: good PEBs: 4072, bad PEBs: 4, corrupted PEBs: 0
>> ubi0: user volume: 4, internal volumes: 1, max. volumes count: 128
>> ubi0: max/mean erase counter: 5/3, WL threshold: 4096, image sequence
>> number: 2068197800
>> ubi0: available PEBs: 3504, total reserved PEBs: 568, PEBs reserved
>> for bad PEB handling: 76
>>
>> @Richard, any ideas? Do you know which of the fixes should fix that?
>

After some further investigation, printing the counters as Richard suggested
I found it was a bug on my side :-( The Linux partition and the U-Boot partition
had different size (i.e. PEB count) and so Fastmap complained :-(

We trimmed the Linux partition size, and forgot to change U-Boot's
(or thought it wouldn't matter).

Sorry for the noise guys!

>
> Does this warning raise also in linux? I do not see it on the aristainetos2
> board.
>
> U-Boot code:
>
>/*
>  * If fastmap is leaking PEBs (must not happen), raise a
>  * fat warning and fall back to scanning mode.
>  * We do this here because in ubi_wl_init() it's too late
>  * and we cannot fall back to scanning.
>  */
> #ifndef __UBOOT__
> if (WARN_ON(count_fastmap_pebs(ai) != ubi->peb_count -
> ai->bad_peb_count - fm->used_blocks))
> goto fail_bad;
> #else
> if (count_fastmap_pebs(ai) != ubi->peb_count -
> ai->bad_peb_count - fm->used_blocks) {
> WARN_ON(1);
> goto fail_bad;
> }
> #endif
>
> Hmm.. could not remember, why I did this U-Boot specific ...
> But that;s a good example, why I like the "#ifndef __UBOOT__"
> in Code ... I immediately see, if its linux or u-boot specific
> code ... maybe its worth to try the original linux code?
>

Linux WARN_xxx macros return a value, and so can be used inside
if statements. U-Boot on the other side, just prints a warning:

#define WARN_ON(x) if (x) {printf("WARNING in %s line %d\n" \
  , __FILE__, __LINE__); }

AFAICS, the above ifndef __UBOOT__ is needed, unless you fix
your WARN_ON in U-Boot.
-- 

Re: [U-Boot] [PATCH 3/3] x86: Added support for Advantech SOM-6896

[Simon Glass]

Hi George,

On 19 October 2015 at 08:29, George McCollister
 wrote:
> Simon,
>
> On Thu, Oct 15, 2015 at 8:25 AM, Simon Glass  wrote:
>> Hi Bin,
>>
>> On Monday, 12 October 2015, Bin Meng  wrote:
>>>
>>> Hi George,
>>>
>>> On Tue, Oct 13, 2015 at 10:52 AM, George McCollister
>>>  wrote:
>>> > On Mon, Oct 12, 2015 at 7:48 PM, Bin Meng  wrote:
>>> >> Hi George,
>>> >>
>>> >> On Tue, Oct 13, 2015 at 2:30 AM, George McCollister
>>> >>  wrote:
>>> >>> On Mon, Oct 12, 2015 at 8:34 AM, George McCollister
>>> >>>  wrote:
>>>  On Fri, Oct 9, 2015 at 10:31 PM, Bin Meng  wrote:
>>> > Hi George,
>>> >
>>> > On Sat, Oct 10, 2015 at 5:54 AM, George McCollister
>>> >  wrote:
>>> >> Advantech SOM-6896 is a Broadwell U based COM Express Compact Module
>>> >> Type 6. This patch adds support for it as a coreboot payload.
>>> >>
>>> >> On board SATA and SPI are functional. On board Ethernet isn't 
>>> >> functional
>>> >> but since it's optional and ties up a PCIe x4 that is otherwise 
>>> >> brought
>>> >> out, this isn't a concern at the moment. USB doesn't work since the
>>> >> xHCI driver appears to be broken.
>>> >>
>>> >> Signed-off-by: George McCollister 
>>> >> ---
>>> >>  arch/x86/dts/Makefile  |  3 ++-
>>> >>  arch/x86/dts/som-6896.dts  | 43 
>>> >> +++
>>> >>  include/configs/som-6896.h | 38 
>>> >> ++
>>> >>  3 files changed, 83 insertions(+), 1 deletion(-)
>>> >>  create mode 100644 arch/x86/dts/som-6896.dts
>>> >>  create mode 100644 include/configs/som-6896.h
>>> >>
>>> >> diff --git a/arch/x86/dts/Makefile b/arch/x86/dts/Makefile
>>> >> index 71595c7..9fa2e21 100644
>>> >> --- a/arch/x86/dts/Makefile
>>> >> +++ b/arch/x86/dts/Makefile
>>> >> @@ -6,7 +6,8 @@ dtb-y += bayleybay.dtb \
>>> >> galileo.dtb \
>>> >> minnowmax.dtb \
>>> >> qemu-x86_i440fx.dtb \
>>> >> -   qemu-x86_q35.dtb
>>> >> +   qemu-x86_q35.dtb \
>>> >> +   som-6896.dtb
>>> >>
>>> >>  targets += $(dtb-y)
>>> >>
>>> >> diff --git a/arch/x86/dts/som-6896.dts b/arch/x86/dts/som-6896.dts
>>> >> new file mode 100644
>>> >> index 000..ad904c9
>>> >> --- /dev/null
>>> >> +++ b/arch/x86/dts/som-6896.dts
>>> >> @@ -0,0 +1,43 @@
>>> >> +/dts-v1/;
>>> >> +
>>> >> +/include/ "skeleton.dtsi"
>>> >> +/include/ "serial.dtsi"
>>> >> +/include/ "rtc.dtsi"
>>> >> +
>>> >> +/ {
>>> >> +   model = "Advantech SOM-6896";
>>> >> +   compatible = "advantech,som-6896", "intel,broadwell";
>>> >> +
>>> >> +   aliases {
>>> >> +   spi0 = "/spi";
>>> >> +   };
>>> >> +
>>> >> +   config {
>>> >> +  silent_console = <0>;
>>> >> +   };
>>> >> +
>>> >> +   chosen {
>>> >> +   stdout-path = "/serial";
>>> >> +   };
>>> >> +
>>> >> +   pci {
>>> >> +   compatible = "intel,pci-broadwell", "pci-x86";
>>> >
>>> > I would just describe it as "pci-x86" as Intel chipset PCI is 
>>> > compatible.
>>>  Okay
>>> >
>>> >> +   #address-cells = <3>;
>>> >> +   #size-cells = <2>;
>>> >> +   u-boot,dm-pre-reloc;
>>> >> +   ranges = <0x0200 0x0 0xe000 0xe000 0 
>>> >> 0x1000
>>> >
>>> > Can you verify 0xe000 is not configured by coreboot as the PCIe
>>> > ECAM base address?
>>>  I'll try to verify these, it's quite possible they are incorrect.
>>> >>>
>>> >>> CONFIG_MMCONF_BASE_ADDRESS is set to 0xf000 in coreboot.
>>> >>>
>>> >>> For prefmem/mem coreboot is showing:
>>> >>> DOMAIN:  mem: base:d000 size:f120 align:28 gran:0 
>>> >>> limit:efff
>>> >>> PCI: 00:02.0 18 *  [0xd000 - 0xdfff] prefmem
>>> >>> PCI: 00:02.0 10 *  [0xe000 - 0xe0ff] mem
>>> >>> PCI: 00:1c.0 20 *  [0xe100 - 0xe10f] mem
>>> >>> PCI: 00:14.0 10 *  [0xe110 - 0xe110] mem
>>> >>> PCI: 00:1f.2 24 *  [0xe111 - 0xe1117fff] mem
>>> >>> PCI: 00:1b.0 10 *  [0xe1118000 - 0xe111bfff] mem
>>> >>> PCI: 00:15.0 10 *  [0xe111c000 - 0xe111cfff] mem
>>> >>> PCI: 00:15.0 14 *  [0xe111d000 - 0xe111dfff] mem
>>> >>> PCI: 00:1f.6 10 *  [0xe111e000 - 0xe111efff] mem
>>> >>> PCI: 00:1f.3 10 *  [0xe111f000 - 0xe111f0ff] mem
>>> >>> PCI: 00:16.0 10 *  [0xe111f100 - 0xe111f11f] mem
>>> >>> DOMAIN:  mem: next_base: e111f120 size: f120 align: 28 gran: 0 
>>> >>> done
>>> >>> PCI: 00:1c.0 prefmem: base:efff size:0 align:20 gran:20 
>>> 

Re: [U-Boot] [PATCH 1/3] ARM: relocate: fix hang when CONFIG_ARMV7_SECURE_BASE

[Li Frank]

> -Original Message-
> From: Peng Fan [mailto:b51...@freescale.com]
> Sent: Monday, October 19, 2015 7:47 AM
> To: Albert ARIBAUD 
> Cc: Li Frank-B20596 ; lzn...@gmail.com; u-
> b...@lists.denx.de; sba...@denx.de; Estevam Fabio-R49496
> ; ota...@ossystems.com.br;
> tr...@konsulko.com; hdego...@redhat.com; Fan Peng-B51431
> 
> Subject: Re: [U-Boot] [PATCH 1/3] ARM: relocate: fix hang when
> CONFIG_ARMV7_SECURE_BASE
> 
> Hi Albert,
> On Mon, Oct 19, 2015 at 01:48:25PM +0200, Albert ARIBAUD wrote:
> >Hello Peng,
> >
> >(cutting a bit through the previous mails quoting)
> >
> >> >This, in turn, leads to new questions:
> >> >
> >> >1. How is this PSCI code put in place? Is it bundled with the image,
> >> >   with a specificy copy routine which puts it in place then locks
> >> >the
> >> Yeah.
> >> >   memory range against writing? Or is it loaded in place by some other
> >> >   agent than U-Boot, and how does this agent know what to put where?
> >>
> >> In arch/arm/cpu/armv7/virt-v7.c, relocate_secure_section() does this job.
> >>
> >> CONFIG_ARMV7_SECURE_BASE is the location that secure code will be
> >> copied to. To ARMV7, PSCI code is bundled with the uboot image.
> >
> >Hmm, the 'relocate' part of the function name is a somewhat non-optimal
> >choice, since the routine just copies data without modifying it.
> >
> >Looking at relocate_secure_section(), I see that it it is called long
> >after the U-Boot code was relocated -- actually, it is called during
> >bootm.
> 
> oh. You remind me, thanks. There maybe something wrong with my previous
> analysis.
> 
> I am not the one who finds the issue, just my understanding.
> The data abort may be triggered by line 104 or line 106.
> 96 fixloop:
> 97 ldmia   r2!, {r0-r1}/* (r0,r1) <- (SRC location,fixup) 
> */
> 98 and r1, r1, #0xff
> 99 cmp r1, #23 /* relative fixup? */
> 100 bne fixnext
> 101
> 102 /* relative fix: increase location by offset */
> 103 add r0, r0, r4
> 104 ldr r1, [r0]
> 105 add r1, r1, r4
> 106 str r1, [r0]
> 
> At line 104 or 106, the value of r0 may be an address that can not be accessed
> which trigger data abort.
> 
> Frank, am I right?

Yes. 
Secure_text + relocate_offset will be invalidate address. 
So generate data abort. 

Best regards
Frank Li

> 
> I'll set up one board to test this.
> 
> >
> >This means that for any one of the other boards around that seem to use
> >PSCI, either "their" PSCI code does not have any relocations (which I
> >doubt), or it has but they don't cause any data abort when done by the
> >relocate_code() routine.


Their secure_text + relocate_offset is possible in unused validate memory 
region.
If not data abort, this don't hurt anything. 

Best regards
Frank Li

> 
> There maybe something wrong from me. See above.
> 
> >
> >So what's the difference between those and your board? My bet is that
> >their CONFIG_ARMV7_SECURE_BASE is not write-protected at the time the
> >relocate_code() routine executes (whereas on your board it is), and
> >will be unlocked in some way by the time relocate_secure_section()
> >executes.
> >
> >I'm not saying that the correct solution would be to enable write
> >access to CONFIG_ARMV7_SECURE_BASE before running relocate_code(),
> >because doing that would be obviously wrong: relocate_code() would try
> >to fix code which is not there yet.
> 
> Yeah. This is true, relocate_code may fix code which is not there.
> 
> >
> >I'm just saying that's what actually happens, and if I am right, then
> >it confirms that the correct fix is to not let relocations to the
> >secure stay in the U-Boot ELF, or better yet, to not let them happen to
> >boot [pun half-intended].
> 
> They do not happen to boot. My bad. See above.
> 
> >
> >> CONFIG_ARMV7_SECURE_BASE is the location that secure code will be
> >> copied to. To ARMV7, PSCI code is bundled with the uboot image.
> >>
> >> >
> >> >2. Does this code and the relocatable image refer to symbols of one
> >> >   another,
> >> Yeah. There is asm function reference. You can see
> >> arch/arm/cpu/armv7/psci.S
> >
> >Looking at this file, I suspect that actually, PSCI is called through a
> >software interrupt / exception vector, not through a function name, and
> >the only symbolic relationship is via __secure_start and __secure_end
> >-- and those must (and will) be correctly relocated along with the
> >U-Boot image.
> >
> >> >or do they interact through an IPC independent of their
> >> >   respective location (in which case, one wonders why they are built
> >> >   into a single ELF file)?
> >>
> >> This comes a question, why PSCI framework intergated into U-Boot? I have
> no idea.
> >
> >There could have been alternative designs, indeed. Here is the design
> >now, so let's handle it.
> >
> >> >More generally... 

Re: [U-Boot] [PATCH] configs: ls1021atwr: Enable ID EEPROM for SD boot

[York Sun]

On 10/19/2015 04:14 AM, Sinan Akman wrote:
> 
>Hi Yuan
> 
> On 19/10/15 05:21 AM, Yao Yuan wrote:
>> Hi Sinan Akman,
>>
>> Yes, I mean the Rev 1.0 silicon.
>> Sorry, I can't guarantee that there aren't any boards with Rev1.0 silicon 
>> are in user's hands.
>> Because we have also delivery very little board with Rev1.0 silicon to  
>> customer  or developer for developing, assessing and verifying in the early 
>> stages.
> 
>Thanks for the follow up on this, but I don't think that there were only
> very few rev1.0 boards delivered. These were the boards bought from
> distributor and during the time span of many weeks.
> 
>I don't know the details and the impact of this patch exactly but
> if the patch will break any rev1.0 board I don't think this would be
> acceptable. There are definitely enough number of rev1.0 boards
> made generally available (not specifically for early adapters etc)
> that we should not break u-boot running on them.
> 
>> Also we haven't support Rev1.0 in our SDK now.
> 
>Sorry, but this is a bit irrelevant here. I'd expect u-boot mainline
> does not necessarily follow what your SDK stops supporting. If
> u-boot supported rev1.0 boards and if there are still many of
>   them out there I see no reason to break this.
> 

Yuan,

Please test the patch on rev 1.0 SoC and make changes if needed. This feature
has been disabled for rev 1.0.

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

Re: [U-Boot] [PATCH v2 2/3] scrapyard: Add lines for recently removed ARM boards

[Tom Rini]

On Sun, Oct 18, 2015 at 04:44:59PM +0900, Masahiro Yamada wrote:
> 2015-10-18 3:58 GMT+09:00 Simon Glass :
> > A lot of boards were recently removed. Add them to the scrapyard.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> > Changes in v2: None
> >
> >  doc/README.scrapyard | 73 
> > 
> >  1 file changed, 73 insertions(+)
> >
> > diff --git a/doc/README.scrapyard b/doc/README.scrapyard
> > index a3482ef..1f157ec 100644
> > --- a/doc/README.scrapyard
> > +++ b/doc/README.scrapyard
> > @@ -40,6 +40,7 @@ atstk1004avr32   -  e5354b8a
> > 2015-06-10  Haavard Skin
> >  atstk1006avr32   -  e5354b8a2015-06-10  
> > Haavard Skinnemoen 
> >  B2   arm s3c44b05dcf536 2011-07-16  Andrea 
> > Scian 
> >  BAB7xx   powerpc MPC740/MPC750  c53043b 2011-12-07  Frank 
> > Gottschling 
> > +balloon3 arm pxa-   -
> >  barcopowerpc MPC8245afaa27b 2010-11-23  Marc 
> > Leeman 
> >  BC3450   powerpc mpc5xxxf8296d692015-03-17
> >  bluestonepowerpc ppc4xx 9ed32462014-10-10  
> > Tirumala Marri 
> > @@ -67,32 +68,57 @@ CPCI750  powerpc 74xx_7xx   03b0040 
> > 2014-10-27  Reinhard Arlt  >  CPCIISER4ppc4xx  405gp  370572602015-01-13  
> > Matthias Fuchs 
> >  CPU86powerpc mpc8260f7e1af862015-01-05  
> > Wolfgang Denk 
> >  CPU87powerpc mpc8260f7e1af862015-01-05
> > +cpu9260_128M arm arm926ejs  -   -
> > +cpu9260  arm arm926ejs  -   -
> > +cpu9260_nand_128M arm arm926ejs  -   -
> > +cpu9260_nand arm arm926ejs  -   -
> > +cpu9G20_128M arm arm926ejs  -   -
> > +cpu9G20  arm arm926ejs  -   -
> > +cpuat91  arm arm920t-   -
> > +cpuat91_ram  arm arm920t-   -
> >  cradle   arm pxa00c4aca 2011-11-25  Kyle 
> > Harris 
> >  CRAYL1   powerpc ppc4xx 1521cdc2014-10-10  David 
> > Updegraff 
> >  csb272/csb472powerpc ppc4xx -   -   
> > Tolunay Orkun 
> >  csb637   arm arm920td14af08 2011-07-17
> >  CU824powerpc mpc824xd622ac392015-01-05  
> > Wolfgang Denk 
> > +d2net_v2 arm arm926ejs  -   -
> > +da830evm arm arm926ejs  -   -
> >  DASA_SIM powerpc ppc4xx 99bcad1 2012-09-19  
> > Matthias Fuchs 
> > +davinci_dm355evm arm arm926ejs  -   -
> > +davinci_dm355leopard arm arm926ejs  -   -
> > +davinci_dm365evm arm arm926ejs  -   -
> > +davinci_dm6467evm arm arm926ejs  -   -
> > +davinci_dm6467Tevm arm arm926ejs  -   -
> > +davinci_dvevmarm arm926ejs  -   -
> > +davinci_schmoogie arm arm926ejs  -   -
> > +davinci_sffsdr   arm arm926ejs  -   -
> > +davinci_sonata   arm arm926ejs  -   -
> >  DB64360 powerpc 74xx_7xx   03b0040 2014-10-27
> >  DB64460 powerpc 74xx_7xx   03b0040 2014-10-27
> >  debris   powerpc mpc824x7edb1f7b2014-05-30  
> > Sangmoon Kim 
> >  deltaARM PXA2xx 75e2035 2010-10-20
> > +dig297   arm armv7  -   -
> >  dkb  arm arm926ejs  346cfba42015-02-24  Lei 
> > Wen 
> >  dnp1110  arm sa1100 fc5e5ce 2011-09-05  Alex 
> > Züpke 
> >  DP405ppc4xx  405ep  9a4018e02015-01-13  
> > Matthias Fuchs 
> >  DU405ppc4xx  405gpr bc1140762015-01-13  
> > Matthias Fuchs 
> >  DU440ppc4xx  440epx 7ac9d47a2015-01-13  
> > Matthias Fuchs 
> >  dvl_host arm ixpe317de6b2014-01-28  
> > Michael Schwingen 
> > +ea20 arm arm926ejs  -   -
> > +eb_cpux9k2   arm arm920t-   -
> > +eb_cpux9k2_ram   arm arm920t-   -
> >  edb9301  arm arm920t

[U-Boot] [PATCH] fill_scrapyard.py: Pass a directory to tempfile.mkstemp()

[Tom Rini]

In some cases os.rename() may later fail due to "Cross-device link"
issues.  The easy way to deal with this is to simply make our temporary
file here as well rather than TMPDIR.

Cc: Masahiro Yamada 
Signed-off-by: Tom Rini 
---
 scripts/fill_scrapyard.py |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/fill_scrapyard.py b/scripts/fill_scrapyard.py
index 9a94354..cd630ef 100755
--- a/scripts/fill_scrapyard.py
+++ b/scripts/fill_scrapyard.py
@@ -119,7 +119,7 @@ class TmpFile:
 
 def __init__(self):
 """Constructor - create a temporary file"""
-fd, self.filename = tempfile.mkstemp()
+fd, self.filename = tempfile.mkstemp(dir='.')
 self.file = os.fdopen(fd, 'w')
 
 def __del__(self):
-- 
1.7.9.5

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

Re: [U-Boot] Remove sparc archiecture?

[Francois Retief]

Hallo Daniel,

> -Original Message-
> From: Daniel Hellstrom [mailto:dan...@gaisler.com]
> Sent: 18 October 2015 11:30 PM
> To: Masahiro Yamada 
> Subject: Re: [U-Boot] Remove sparc archiecture?
>
> On 10/18/2015 05:20 PM, Masahiro Yamada wrote:
> > (+CC Francois)
> >
> >
> > 2015-10-18 21:24 GMT+09:00 Tom Rini :
> >> On Sun, Oct 18, 2015 at 06:19:16AM -0600, Simon Glass wrote:
> >>
> >>> Hi,
> >>>
> >>> It looks like sparc has no maintainer and has not been converted to
> >>> generic board. Should we remove it?
> >> Well, not quite "no maintainer", but... Daniel?  SPARC is in need of
> >> some work (and possibly a new toolchain too, I stopped building it all
> >> the time due to a false positive warning the 3.4.4 toolchain I have
> >> gives).  Thanks!
> >>
> >> --
> >> Tom
> >
> > I see generic board work for SPARC
> >
> > http://patchwork.ozlabs.org/patch/404616/
> > http://patchwork.ozlabs.org/patch/404618/
> > http://patchwork.ozlabs.org/patch/404617/
> > http://patchwork.ozlabs.org/patch/404619/
> > http://patchwork.ozlabs.org/patch/404620/
> > http://patchwork.ozlabs.org/patch/404622/
> > http://patchwork.ozlabs.org/patch/404621/
> > http://patchwork.ozlabs.org/patch/404624/
> > http://patchwork.ozlabs.org/patch/404623/
> >
> > but, Daniel was not responding...
> >
> >
> > Perhaps, replace the maintainer if Francois agrees?
>
> I regret to say that I've been too busy last two years and I don't see a
> change during 2015 either.
>
> I would not like to see the SPARC port removed now that the LEON
> community grows as new LEON3 and LEON4 chips comes to market. WIth
> multi-core and higher frequency there is a growing interest in u-boot
> from the LEON community.
>
> Nowadays there are LEON GCC targets mcpu=leon,leon3,leon3v7 so it should
> be possible to setup a working toolchain based on GCC-4.9 which we use
> for Linux and RTEMS. In the past I've used a GCC-4.4 toolchain from
> Cobham Gaisler.
>
> If Francois agrees it is probably a good idea to let him take over the
> SPARC as he has put work into both BSP and architecture. Although I
> would like to acknowledge my interest in u-boot and I hope and believe
> that my efforts will be resumed in the future. Francois, if you feel it
> is too much a temporary replacement could also be an option if the
> u-boot project allows it.

Yes, I am willing to take over as maintainer until such time that Daniel is 
ready
to resume his effort in future. We are investing in the LEON as archtecture and
would like to see U-Boot support for SPARC continuing into the future.

Daniel, I would just like to ask if you could stay on as an advisor, if at all 
possible.
I have only access to one LEON3FT board at the moment and may require advice
on other devices as time goes by.  I will try to keep questions consise and as
infrequent as possible for you.

Will rebase my patch set to the latest release this week and resend them for 
review.
Masahiro, what version of GCC is prefered (if any) for the next release  of 
U-Boot.
I am currently using the GCC-4.4 toolchain from Cobham Gaisler.

Regards,
  Francois



Disclaimer and confidentiality note – refer to our website for further details: 
www.spaceteq.co.za 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3] x86: Added support for Advantech SOM-6896

[George McCollister]

Simon,

On Thu, Oct 15, 2015 at 8:25 AM, Simon Glass  wrote:
> Hi Bin,
>
> On Monday, 12 October 2015, Bin Meng  wrote:
>>
>> Hi George,
>>
>> On Tue, Oct 13, 2015 at 10:52 AM, George McCollister
>>  wrote:
>> > On Mon, Oct 12, 2015 at 7:48 PM, Bin Meng  wrote:
>> >> Hi George,
>> >>
>> >> On Tue, Oct 13, 2015 at 2:30 AM, George McCollister
>> >>  wrote:
>> >>> On Mon, Oct 12, 2015 at 8:34 AM, George McCollister
>> >>>  wrote:
>>  On Fri, Oct 9, 2015 at 10:31 PM, Bin Meng  wrote:
>> > Hi George,
>> >
>> > On Sat, Oct 10, 2015 at 5:54 AM, George McCollister
>> >  wrote:
>> >> Advantech SOM-6896 is a Broadwell U based COM Express Compact Module
>> >> Type 6. This patch adds support for it as a coreboot payload.
>> >>
>> >> On board SATA and SPI are functional. On board Ethernet isn't 
>> >> functional
>> >> but since it's optional and ties up a PCIe x4 that is otherwise 
>> >> brought
>> >> out, this isn't a concern at the moment. USB doesn't work since the
>> >> xHCI driver appears to be broken.
>> >>
>> >> Signed-off-by: George McCollister 
>> >> ---
>> >>  arch/x86/dts/Makefile  |  3 ++-
>> >>  arch/x86/dts/som-6896.dts  | 43 
>> >> +++
>> >>  include/configs/som-6896.h | 38 
>> >> ++
>> >>  3 files changed, 83 insertions(+), 1 deletion(-)
>> >>  create mode 100644 arch/x86/dts/som-6896.dts
>> >>  create mode 100644 include/configs/som-6896.h
>> >>
>> >> diff --git a/arch/x86/dts/Makefile b/arch/x86/dts/Makefile
>> >> index 71595c7..9fa2e21 100644
>> >> --- a/arch/x86/dts/Makefile
>> >> +++ b/arch/x86/dts/Makefile
>> >> @@ -6,7 +6,8 @@ dtb-y += bayleybay.dtb \
>> >> galileo.dtb \
>> >> minnowmax.dtb \
>> >> qemu-x86_i440fx.dtb \
>> >> -   qemu-x86_q35.dtb
>> >> +   qemu-x86_q35.dtb \
>> >> +   som-6896.dtb
>> >>
>> >>  targets += $(dtb-y)
>> >>
>> >> diff --git a/arch/x86/dts/som-6896.dts b/arch/x86/dts/som-6896.dts
>> >> new file mode 100644
>> >> index 000..ad904c9
>> >> --- /dev/null
>> >> +++ b/arch/x86/dts/som-6896.dts
>> >> @@ -0,0 +1,43 @@
>> >> +/dts-v1/;
>> >> +
>> >> +/include/ "skeleton.dtsi"
>> >> +/include/ "serial.dtsi"
>> >> +/include/ "rtc.dtsi"
>> >> +
>> >> +/ {
>> >> +   model = "Advantech SOM-6896";
>> >> +   compatible = "advantech,som-6896", "intel,broadwell";
>> >> +
>> >> +   aliases {
>> >> +   spi0 = "/spi";
>> >> +   };
>> >> +
>> >> +   config {
>> >> +  silent_console = <0>;
>> >> +   };
>> >> +
>> >> +   chosen {
>> >> +   stdout-path = "/serial";
>> >> +   };
>> >> +
>> >> +   pci {
>> >> +   compatible = "intel,pci-broadwell", "pci-x86";
>> >
>> > I would just describe it as "pci-x86" as Intel chipset PCI is 
>> > compatible.
>>  Okay
>> >
>> >> +   #address-cells = <3>;
>> >> +   #size-cells = <2>;
>> >> +   u-boot,dm-pre-reloc;
>> >> +   ranges = <0x0200 0x0 0xe000 0xe000 0 
>> >> 0x1000
>> >
>> > Can you verify 0xe000 is not configured by coreboot as the PCIe
>> > ECAM base address?
>>  I'll try to verify these, it's quite possible they are incorrect.
>> >>>
>> >>> CONFIG_MMCONF_BASE_ADDRESS is set to 0xf000 in coreboot.
>> >>>
>> >>> For prefmem/mem coreboot is showing:
>> >>> DOMAIN:  mem: base:d000 size:f120 align:28 gran:0 
>> >>> limit:efff
>> >>> PCI: 00:02.0 18 *  [0xd000 - 0xdfff] prefmem
>> >>> PCI: 00:02.0 10 *  [0xe000 - 0xe0ff] mem
>> >>> PCI: 00:1c.0 20 *  [0xe100 - 0xe10f] mem
>> >>> PCI: 00:14.0 10 *  [0xe110 - 0xe110] mem
>> >>> PCI: 00:1f.2 24 *  [0xe111 - 0xe1117fff] mem
>> >>> PCI: 00:1b.0 10 *  [0xe1118000 - 0xe111bfff] mem
>> >>> PCI: 00:15.0 10 *  [0xe111c000 - 0xe111cfff] mem
>> >>> PCI: 00:15.0 14 *  [0xe111d000 - 0xe111dfff] mem
>> >>> PCI: 00:1f.6 10 *  [0xe111e000 - 0xe111efff] mem
>> >>> PCI: 00:1f.3 10 *  [0xe111f000 - 0xe111f0ff] mem
>> >>> PCI: 00:16.0 10 *  [0xe111f100 - 0xe111f11f] mem
>> >>> DOMAIN:  mem: next_base: e111f120 size: f120 align: 28 gran: 0 
>> >>> done
>> >>> PCI: 00:1c.0 prefmem: base:efff size:0 align:20 gran:20 
>> >>> limit:efff
>> >>> PCI: 00:1c.0 prefmem: next_base: efff size: 0 align: 20 gran: 20 done
>> >>> PCI: 00:1c.0 mem: base:e100 size:10 align:20 gran:20 
>> >>> limit:e10f
>> >>> PCI: 01:00.0 14 *  

Re: [U-Boot] [PATCH v2 1/3] Sort README.scrapyard

[Tom Rini]

On Sun, Oct 18, 2015 at 04:40:55PM +0900, Masahiro Yamada wrote:
> Hi Simon,
> 
> 2015-10-18 3:58 GMT+09:00 Simon Glass :
> > Sort this by board name to make it easier to find boards.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> > Changes in v2:
> > - Rebase to master
> > - Update the file comment to indicate the new ordering
> >
> >  doc/README.scrapyard | 531 
> > +--
> >  1 file changed, 265 insertions(+), 266 deletions(-)
> >
> > diff --git a/doc/README.scrapyard b/doc/README.scrapyard
> > index c7b4fa3..a3482ef 100644
> > --- a/doc/README.scrapyard
> > +++ b/doc/README.scrapyard
> > @@ -7,308 +7,307 @@ be removed from the U-Boot source tree.  The remainders 
> > rest in piece
> >  in the imperishable depths of the git history.  This document tries to
> >  maintain a list of such former fellows, so archaeologists can check
> >  easily if there is something they might want to dig for...
> > -The list should be sorted in reverse chronological order.
> > -
> > +The list should be sorted in case-insensitive alphabetical order.
> >
> >  BoardArchCPUCommit  Removed Last 
> > known maintainer/contact
> >  
> > =
> > -stxgp3   powerpc mpc85xx-   -   Dan 
> > Malek 
> > -stxssa   powerpc mpc85xx-   -   Dan 
> > Malek 
> > -cmi_mpc5xx   powerpc mpc5xx -   -
> > -zeus powerpc ppc4xx -   -   Stefan 
> > Roese 
> > -sbc405   powerpc ppc4xx -   -
> > -pcs440ep powerpc ppc4xx -   -   Stefan 
> > Roese 
> > -p3p440   powerpc ppc4xx -   -   Stefan 
> > Roese 
> > -csb272/csb472powerpc ppc4xx -   -   
> > Tolunay Orkun 
> 
> 
> scripts/fill_scrapyard.py must be run before sorting.
> 
> I added these entries at the commits where the boards were removed,
> so scripts/fill_scrapyard.py should fill Commit and Removed fields correctly.

So lets leave this sorted as-is and drop this patch (and locally I've
filled in the data with fill_scrapyard.py, thanks!)

-- 
Tom


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

Re: [U-Boot] [PATCH 2/3] gpt: add optional parameter guid in gpt command

[Patrick Delaunay]

2015-10-15 23:46 GMT+02:00 Tom Rini :

> On Thu, Oct 15, 2015 at 03:58:24PM -0500, Rob Herring wrote:
> > On Tue, Oct 13, 2015 at 9:23 AM, Patrick Delaunay
> >  wrote:
> > > code under flag CONFIG_PARTITION_TYPE_GUID
> > > add parameter guid to select partition type guid
> > >
> > > example of use with gpt command :
> > >
> > >   partitions = uuid_disk=${uuid_gpt_disk};name=boot,start=0x4400,
> > >   size=0x6bc00,uuid=${uuid_gpt_boot};name=root,start=0x7,
> > >   size=0x7538ba00,uuid=${uuid_gpt_root},
> > >   guid=0fc63daf-8483-4772-8e79-3d69d8477de4;
> >
> > The mixture of UUID and GUID is confusing. What we want are the
> > GUIDs/UUIDs for unique ID and the partition type. I would just call
> > the partition type "type". This would allow the same format to be used
> > for MBR partitions if someone wanted to do support for that.
>
> ... and if someone wants to add MBR support, there's enough use cases
> for it (mainly around flashing/factory stuff) that I wouldn't object.
> So yes, lets do this with that kind of thing in mind.
>


Hi,

if you prefer, I can modify the parameter name to "type" as proposed in a
version 2 of the patchset.

partitions =
uuid_disk=${uuid_gpt_disk}; \
name=boot,start=0x4400,size=0x6bc00,uuid=${uuid_gpt_boot}; \

name=root,start=0x7,size=0x7538ba00,uuid=${uuid_gpt_root},type=0fc63daf-8483-4772-8e79-3d69d8477de4;

and to be coherent, I will also modify the field in the struct
disk_partition_t to type_guid

+#ifdef CONFIG_PARTITION_TYPE_GUID
+chartype_guid[37];/* type GUID as string, if exists*/
+#endif
 } disk_partition_t;

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

[U-Boot] [PATCH] Revert "arm: Remove d2net_v2 defconfig file"

[Tom Rini]

Upon further review when populating README.scrapyard, d2net_v2 is a
variant on net2big_v2 and not just an orphan config.  To help in the
future also add this to board/LaCie/net2big_v2/MAINTAINERS which needed
a little consolidation anyhow.

This reverts commit 1363740e7948a8e4bee8d5adcdf0f63f7782879d.

Cc: Simon Guinot 
Cc: Simon Glass 
Signed-off-by: Tom Rini 
---
 board/LaCie/net2big_v2/MAINTAINERS |6 +-
 configs/d2net_v2_defconfig |8 
 2 files changed, 9 insertions(+), 5 deletions(-)
 create mode 100644 configs/d2net_v2_defconfig

diff --git a/board/LaCie/net2big_v2/MAINTAINERS 
b/board/LaCie/net2big_v2/MAINTAINERS
index 205c75e..8fec703 100644
--- a/board/LaCie/net2big_v2/MAINTAINERS
+++ b/board/LaCie/net2big_v2/MAINTAINERS
@@ -1,11 +1,7 @@
 NET2BIG_V2 BOARD
-#M:-
+M: Simon Guinot 
 S: Maintained
 F: board/LaCie/net2big_v2/
 F: include/configs/lacie_kw.h
 F: configs/d2net_v2_defconfig
-
-NET2BIG_V2 BOARD
-M: Simon Guinot 
-S: Maintained
 F: configs/net2big_v2_defconfig
diff --git a/configs/d2net_v2_defconfig b/configs/d2net_v2_defconfig
new file mode 100644
index 000..d5f783f
--- /dev/null
+++ b/configs/d2net_v2_defconfig
@@ -0,0 +1,8 @@
+CONFIG_ARM=y
+CONFIG_KIRKWOOD=y
+CONFIG_TARGET_NET2BIG_V2=y
+CONFIG_SYS_EXTRA_OPTIONS="D2NET_V2"
+# CONFIG_CMD_IMLS is not set
+# CONFIG_CMD_FLASH is not set
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_SPI_FLASH=y
-- 
1.7.9.5

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

Re: [U-Boot] Porting UBI fixes (specially fastmap's) to U-Boot

[Heiko Schocher]

Hello Ezequiel,

Am 19.10.2015 um 15:47 schrieb Ezequiel Garcia:

On 19 October 2015 at 02:17, Heiko Schocher  wrote:

Hello Ezequiel,

Am 17.10.2015 um 20:07 schrieb Ezequiel Garcia:


Hi Heiko,

On 9 October 2015 at 09:30, Heiko Schocher  wrote:
[..]




I just updated the "ubi_sync_with_linux" branch on u-boot-ubi.

It seems UBI/UBIFS now work with the NAND on the aristainetos2
board, but my stomach says, there are some subtile issues ...

Still needs more testing, also not tested yet UBI on the SPI NOR on
this board.

If I "nand erase" the mtd device, and try "ubi part ..." it fails

:-(

But If I flash_eraseall under linux the device, and then make
"ubi part..." in U-Boot, commmand succeeds ...



Tested it on my custom AM335x board. Haven't used mainline U-Boot
but cherry-picked the following commits:

linux, compat: add missing definitions for ubi
ubi/ubifs: some bugfixes
ubi,ubifs: sync with linux v4.2
ubi: reset mtd_devs when ubi part fail

Commits apply cleanly except for "linux, compat: add missing
definitions for ubi"
which was trivial to backport anyway.

U-Boot built fine, but there was a warning:

drivers/mtd/ubi/fastmap.c: In function 'ubi_attach_fastmap':
drivers/mtd/ubi/fastmap.c:816:2: warning: pointer targets in passing
argument 3 of 'scan_pool' differ in signedness [-Wpointer-sign]
ret = scan_pool(ubi, ai, fmpl->pebs, pool_size, _sqnum, );

Just sent this patch which should fix it:
http://patchwork.ozlabs.org/patch/531842/



Thanks for fixing. With it, I see no compiler warning anymore.
Applied to u-boot-ubi.git ubi_sync_with_linux

Tried this branch on the aristainetos2 board with ubi/ubifs on nand and
spi nor flash, worked fine, see log:

http://xeidos.ddns.net/buildbot/builders/ari_ubi/builds/7
http://xeidos.ddns.net/buildbot/builders/ari_ubi/builds/7/steps/shell/logs/tbotlog


The board seems to work fine, and I can even to "nand erase" and "ubi
part" without
any problem.



Did you tried "ubi part" more than once in a row?



Yup, I can do "ubi part $mypart" several times. And can also do "nand
erase.part foo"
and then "ubi part foo" several times.


Thanks for checking!


The patches seem to work fine here, so:

Tested-by: Ezequiel Garcia 


Updated it to u-boot-ubi.git ubi_sync_with_linux


However, I'm still seeing the same warning I had before, when my partition
is attached:

ubi0: default fastmap pool size: 200
ubi0: default fastmap WL pool size: 100
ubi0: attaching mtd1
WARNING in drivers/mtd/ubi/fastmap.c line 846
ubi0: scanning is finished
ubi0: attached mtd1 (name "mtd=7", size 509 MiB)
ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 129024 bytes
ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 512
ubi0: VID header offset: 512 (aligned 512), data offset: 2048
ubi0: good PEBs: 4072, bad PEBs: 4, corrupted PEBs: 0
ubi0: user volume: 4, internal volumes: 1, max. volumes count: 128
ubi0: max/mean erase counter: 5/3, WL threshold: 4096, image sequence
number: 2068197800
ubi0: available PEBs: 3504, total reserved PEBs: 568, PEBs reserved
for bad PEB handling: 76

@Richard, any ideas? Do you know which of the fixes should fix that?




After some further investigation, printing the counters as Richard suggested
I found it was a bug on my side :-( The Linux partition and the U-Boot partition
had different size (i.e. PEB count) and so Fastmap complained :-(

We trimmed the Linux partition size, and forgot to change U-Boot's
(or thought it wouldn't matter).

Sorry for the noise guys!


Ah, ok.


Does this warning raise also in linux? I do not see it on the aristainetos2
board.

U-Boot code:

/*
  * If fastmap is leaking PEBs (must not happen), raise a
  * fat warning and fall back to scanning mode.
  * We do this here because in ubi_wl_init() it's too late
  * and we cannot fall back to scanning.
  */
#ifndef __UBOOT__
 if (WARN_ON(count_fastmap_pebs(ai) != ubi->peb_count -
 ai->bad_peb_count - fm->used_blocks))
 goto fail_bad;
#else
 if (count_fastmap_pebs(ai) != ubi->peb_count -
 ai->bad_peb_count - fm->used_blocks) {
 WARN_ON(1);
 goto fail_bad;
 }
#endif

Hmm.. could not remember, why I did this U-Boot specific ...
But that;s a good example, why I like the "#ifndef __UBOOT__"
in Code ... I immediately see, if its linux or u-boot specific
code ... maybe its worth to try the original linux code?



Linux WARN_xxx macros return a value, and so can be used inside
if statements. U-Boot on the other side, just prints a warning:

#define WARN_ON(x) if (x) {printf("WARNING in %s line %d\n" \
   , __FILE__, __LINE__); }

AFAICS, the above ifndef __UBOOT__ is needed, unless you fix
your WARN_ON in U-Boot.


Yes, correct. Patches are welcome ;-)

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing 

Re: [U-Boot] Remove sparc archiecture?

[Francois Retief]

> -Original Message-
> From: Tom Rini [mailto:tr...@konsulko.com]
> Sent: 19 October 2015 05:47 PM
> To: Francois Retief 
> Subject: Re: [U-Boot] Remove sparc archiecture?
>
> On Mon, Oct 19, 2015 at 02:54:57PM +, Francois Retief wrote:
> > Hallo Daniel,
> >
> > > -Original Message-
> > > From: Daniel Hellstrom [mailto:dan...@gaisler.com]
> > > Sent: 18 October 2015 11:30 PM
> > > To: Masahiro Yamada 
> > > Subject: Re: [U-Boot] Remove sparc archiecture?
...
> > > Nowadays there are LEON GCC targets mcpu=leon,leon3,leon3v7 so it
> should
> > > be possible to setup a working toolchain based on GCC-4.9 which we use
> > > for Linux and RTEMS. In the past I've used a GCC-4.4 toolchain from
> > > Cobham Gaisler.
...
> > Will rebase my patch set to the latest release this week and resend them
> for review.
> > Masahiro, what version of GCC is prefered (if any) for the next release  of
> U-Boot.
> > I am currently using the GCC-4.4 toolchain from Cobham Gaisler.
>
> Any semi-modern toolchain is fine with me.  Can you point me at the 4.4
> toolchain and I'll put sparc back into my build-test cycle?  Thanks!

I have been using this compiler up to now:
  http://www.gaisler.com/anonftp/bcc/bin/linux/sparc-elf-4.4.2-1.0.44.tar.bz2

Daniel is that the one you have been refering to?

Regards,
  Francois



Disclaimer and confidentiality note – refer to our website for further details: 
www.spaceteq.co.za 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Remove sparc archiecture?

[Tom Rini]

On Mon, Oct 19, 2015 at 02:54:57PM +, Francois Retief wrote:
> Hallo Daniel,
> 
> > -Original Message-
> > From: Daniel Hellstrom [mailto:dan...@gaisler.com]
> > Sent: 18 October 2015 11:30 PM
> > To: Masahiro Yamada 
> > Subject: Re: [U-Boot] Remove sparc archiecture?
> >
> > On 10/18/2015 05:20 PM, Masahiro Yamada wrote:
> > > (+CC Francois)
> > >
> > >
> > > 2015-10-18 21:24 GMT+09:00 Tom Rini :
> > >> On Sun, Oct 18, 2015 at 06:19:16AM -0600, Simon Glass wrote:
> > >>
> > >>> Hi,
> > >>>
> > >>> It looks like sparc has no maintainer and has not been converted to
> > >>> generic board. Should we remove it?
> > >> Well, not quite "no maintainer", but... Daniel?  SPARC is in need of
> > >> some work (and possibly a new toolchain too, I stopped building it all
> > >> the time due to a false positive warning the 3.4.4 toolchain I have
> > >> gives).  Thanks!
> > >>
> > >> --
> > >> Tom
> > >
> > > I see generic board work for SPARC
> > >
> > > http://patchwork.ozlabs.org/patch/404616/
> > > http://patchwork.ozlabs.org/patch/404618/
> > > http://patchwork.ozlabs.org/patch/404617/
> > > http://patchwork.ozlabs.org/patch/404619/
> > > http://patchwork.ozlabs.org/patch/404620/
> > > http://patchwork.ozlabs.org/patch/404622/
> > > http://patchwork.ozlabs.org/patch/404621/
> > > http://patchwork.ozlabs.org/patch/404624/
> > > http://patchwork.ozlabs.org/patch/404623/
> > >
> > > but, Daniel was not responding...
> > >
> > >
> > > Perhaps, replace the maintainer if Francois agrees?
> >
> > I regret to say that I've been too busy last two years and I don't see a
> > change during 2015 either.
> >
> > I would not like to see the SPARC port removed now that the LEON
> > community grows as new LEON3 and LEON4 chips comes to market. WIth
> > multi-core and higher frequency there is a growing interest in u-boot
> > from the LEON community.
> >
> > Nowadays there are LEON GCC targets mcpu=leon,leon3,leon3v7 so it should
> > be possible to setup a working toolchain based on GCC-4.9 which we use
> > for Linux and RTEMS. In the past I've used a GCC-4.4 toolchain from
> > Cobham Gaisler.
> >
> > If Francois agrees it is probably a good idea to let him take over the
> > SPARC as he has put work into both BSP and architecture. Although I
> > would like to acknowledge my interest in u-boot and I hope and believe
> > that my efforts will be resumed in the future. Francois, if you feel it
> > is too much a temporary replacement could also be an option if the
> > u-boot project allows it.
> 
> Yes, I am willing to take over as maintainer until such time that Daniel is 
> ready
> to resume his effort in future. We are investing in the LEON as archtecture 
> and
> would like to see U-Boot support for SPARC continuing into the future.
> 
> Daniel, I would just like to ask if you could stay on as an advisor, if at 
> all possible.
> I have only access to one LEON3FT board at the moment and may require advice
> on other devices as time goes by.  I will try to keep questions consise and as
> infrequent as possible for you.
> 
> Will rebase my patch set to the latest release this week and resend them for 
> review.
> Masahiro, what version of GCC is prefered (if any) for the next release  of 
> U-Boot.
> I am currently using the GCC-4.4 toolchain from Cobham Gaisler.

Any semi-modern toolchain is fine with me.  Can you point me at the 4.4
toolchain and I'll put sparc back into my build-test cycle?  Thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH] arm: add support for semihosting for ARMv7M targets

[Tom Rini]

On Mon, Oct 19, 2015 at 09:12:25AM +0200, Linus Walleij wrote:
> On Sun, Oct 18, 2015 at 11:45 AM, Vadzim Dambrouski  wrote:
> > On 18.10.2015 12:20, Linus Walleij wrote:
> >> Hey, cool. Technically the (ulong) typecasts should be another patch
> >
> > Sorry about that, this is my first time sending a patch.
> >
> >> Are you using this with the smload commands?
> >
> > Yes, I do use smhload command, and openocd on the other end.
> > Useful for debugging targets without ethernet support.
> 
> That is *so* cool. You should make a blog post about this, I think
> it's generally useful for developers to know they can use
> U-Boot+JTAG+OpenOCD to get code into any platform (if they have
> a scan chain definitions) like this.

Yes, please!

-- 
Tom


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

[U-Boot] [PATCH 1/3] sf: Add dm_spi_flash_probe

[Jagan Teki]

Updated dm-spi-flash probe using dm_spi_flash_probe.

Signed-off-by: Jagan Teki 
Cc: Simon Glass 
---
 common/cmd_sf.c | 23 ---
 drivers/mtd/spi/sf-uclass.c | 27 ++-
 include/spi_flash.h |  5 ++---
 3 files changed, 32 insertions(+), 23 deletions(-)

diff --git a/common/cmd_sf.c b/common/cmd_sf.c
index ac7f5df..f1926e3 100644
--- a/common/cmd_sf.c
+++ b/common/cmd_sf.c
@@ -8,7 +8,6 @@
 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -17,7 +16,6 @@
 #include 
 
 #include 
-#include 
 
 static struct spi_flash *flash;
 
@@ -85,10 +83,7 @@ static int do_spi_flash_probe(int argc, char * const argv[])
unsigned int speed = CONFIG_SF_DEFAULT_SPEED;
unsigned int mode = CONFIG_SF_DEFAULT_MODE;
char *endp;
-#ifdef CONFIG_DM_SPI_FLASH
-   struct udevice *new, *bus_dev;
-   int ret;
-#else
+#ifndef CONFIG_DM_SPI_FLASH
struct spi_flash *new;
 #endif
 
@@ -119,21 +114,11 @@ static int do_spi_flash_probe(int argc, char * const 
argv[])
}
 
 #ifdef CONFIG_DM_SPI_FLASH
-   /* Remove the old device, otherwise probe will just be a nop */
-   ret = spi_find_bus_and_cs(bus, cs, _dev, );
-   if (!ret) {
-   device_remove(new);
-   device_unbind(new);
-   }
-   flash = NULL;
-   ret = spi_flash_probe_bus_cs(bus, cs, speed, mode, );
-   if (ret) {
-   printf("Failed to initialize SPI flash at %u:%u (error %d)\n",
-  bus, cs, ret);
+   flash = dm_spi_flash_probe(bus, cs, speed, mode);
+   if (!flash) {
+   printf("Failed to initialize SPI flash at %u:%u\n", bus, cs);
return 1;
}
-
-   flash = dev_get_uclass_priv(new);
 #else
if (flash)
spi_flash_free(flash);
diff --git a/drivers/mtd/spi/sf-uclass.c b/drivers/mtd/spi/sf-uclass.c
index 350e21a..9c109fa 100644
--- a/drivers/mtd/spi/sf-uclass.c
+++ b/drivers/mtd/spi/sf-uclass.c
@@ -47,7 +47,7 @@ void spi_flash_free(struct spi_flash *flash)
spi_flash_remove(flash->spi->dev);
 }
 
-int spi_flash_probe_bus_cs(unsigned int busnum, unsigned int cs,
+static int spi_flash_probe_bus_cs(unsigned int busnum, unsigned int cs,
   unsigned int max_hz, unsigned int spi_mode,
   struct udevice **devp)
 {
@@ -67,6 +67,31 @@ int spi_flash_probe_bus_cs(unsigned int busnum, unsigned int 
cs,
return 0;
 }
 
+struct spi_flash *dm_spi_flash_probe(unsigned int busnum, unsigned int cs,
+   unsigned int max_hz, unsigned int spi_mode)
+{
+   struct udevice *bus, *new;
+   struct spi_flash *flash;
+   int ret;
+
+   /* Remove the old device, otherwise probe will just be a nop */
+   ret = spi_find_bus_and_cs(busnum, cs, , );
+   if (!ret) {
+   device_remove(new);
+   device_unbind(new);
+   }
+   flash = NULL;
+
+   ret = spi_flash_probe_bus_cs(busnum, cs, max_hz, spi_mode, );
+   if (ret) {
+   printf("Failed to initialize SPI flash at %u:%u (error %d)\n",
+  busnum, cs, ret);
+   return flash;
+   }
+
+   return dev_get_uclass_priv(new);
+}
+
 int spi_flash_remove(struct udevice *dev)
 {
return device_remove(dev);
diff --git a/include/spi_flash.h b/include/spi_flash.h
index 3b2d555..5abbf99 100644
--- a/include/spi_flash.h
+++ b/include/spi_flash.h
@@ -154,9 +154,8 @@ int spi_flash_write_dm(struct udevice *dev, u32 offset, 
size_t len,
  */
 int spi_flash_erase_dm(struct udevice *dev, u32 offset, size_t len);
 
-int spi_flash_probe_bus_cs(unsigned int busnum, unsigned int cs,
-  unsigned int max_hz, unsigned int spi_mode,
-  struct udevice **devp);
+struct spi_flash *dm_spi_flash_probe(unsigned int busnum, unsigned int cs,
+   unsigned int max_hz, unsigned int spi_mode);
 
 /* Compatibility function - this is the old U-Boot API */
 struct spi_flash *spi_flash_probe(unsigned int bus, unsigned int cs,
-- 
1.9.1

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

[U-Boot] [PATCH 2/3] sf: spi_flash_probe for both dm/non-dm

[Jagan Teki]

Let's use spi_flash_probe for dm and no-dm spi-flash
and make respective function definations separately.

Signed-off-by: Jagan Teki 
Cc: Simon Glass 
---
 common/cmd_sf.c | 19 ++-
 drivers/mtd/spi/sf-uclass.c | 17 +
 include/spi_flash.h | 18 --
 3 files changed, 7 insertions(+), 47 deletions(-)

diff --git a/common/cmd_sf.c b/common/cmd_sf.c
index f1926e3..cdc6c26 100644
--- a/common/cmd_sf.c
+++ b/common/cmd_sf.c
@@ -83,9 +83,6 @@ static int do_spi_flash_probe(int argc, char * const argv[])
unsigned int speed = CONFIG_SF_DEFAULT_SPEED;
unsigned int mode = CONFIG_SF_DEFAULT_MODE;
char *endp;
-#ifndef CONFIG_DM_SPI_FLASH
-   struct spi_flash *new;
-#endif
 
if (argc >= 2) {
cs = simple_strtoul(argv[1], , 0);
@@ -113,27 +110,15 @@ static int do_spi_flash_probe(int argc, char * const 
argv[])
return -1;
}
 
-#ifdef CONFIG_DM_SPI_FLASH
-   flash = dm_spi_flash_probe(bus, cs, speed, mode);
-   if (!flash) {
-   printf("Failed to initialize SPI flash at %u:%u\n", bus, cs);
-   return 1;
-   }
-#else
if (flash)
spi_flash_free(flash);
 
-   new = spi_flash_probe(bus, cs, speed, mode);
-   flash = new;
-
-   if (!new) {
+   flash = spi_flash_probe(bus, cs, speed, mode);
+   if (!flash) {
printf("Failed to initialize SPI flash at %u:%u\n", bus, cs);
return 1;
}
 
-   flash = new;
-#endif
-
return 0;
 }
 
diff --git a/drivers/mtd/spi/sf-uclass.c b/drivers/mtd/spi/sf-uclass.c
index 9c109fa..a1c5810 100644
--- a/drivers/mtd/spi/sf-uclass.c
+++ b/drivers/mtd/spi/sf-uclass.c
@@ -27,21 +27,6 @@ int spi_flash_erase_dm(struct udevice *dev, u32 offset, 
size_t len)
return sf_get_ops(dev)->erase(dev, offset, len);
 }
 
-/*
- * TODO(s...@chromium.org): This is an old-style function. We should remove
- * it when all SPI flash drivers use dm
- */
-struct spi_flash *spi_flash_probe(unsigned int bus, unsigned int cs,
- unsigned int max_hz, unsigned int spi_mode)
-{
-   struct udevice *dev;
-
-   if (spi_flash_probe_bus_cs(bus, cs, max_hz, spi_mode, ))
-   return NULL;
-
-   return dev_get_uclass_priv(dev);
-}
-
 void spi_flash_free(struct spi_flash *flash)
 {
spi_flash_remove(flash->spi->dev);
@@ -67,7 +52,7 @@ static int spi_flash_probe_bus_cs(unsigned int busnum, 
unsigned int cs,
return 0;
 }
 
-struct spi_flash *dm_spi_flash_probe(unsigned int busnum, unsigned int cs,
+struct spi_flash *spi_flash_probe(unsigned int busnum, unsigned int cs,
unsigned int max_hz, unsigned int spi_mode)
 {
struct udevice *bus, *new;
diff --git a/include/spi_flash.h b/include/spi_flash.h
index 5abbf99..0afc9fb 100644
--- a/include/spi_flash.h
+++ b/include/spi_flash.h
@@ -154,16 +154,6 @@ int spi_flash_write_dm(struct udevice *dev, u32 offset, 
size_t len,
  */
 int spi_flash_erase_dm(struct udevice *dev, u32 offset, size_t len);
 
-struct spi_flash *dm_spi_flash_probe(unsigned int busnum, unsigned int cs,
-   unsigned int max_hz, unsigned int spi_mode);
-
-/* Compatibility function - this is the old U-Boot API */
-struct spi_flash *spi_flash_probe(unsigned int bus, unsigned int cs,
- unsigned int max_hz, unsigned int spi_mode);
-
-/* Compatibility function - this is the old U-Boot API */
-void spi_flash_free(struct spi_flash *flash);
-
 int spi_flash_remove(struct udevice *flash);
 
 static inline int spi_flash_read(struct spi_flash *flash, u32 offset,
@@ -192,8 +182,6 @@ int sandbox_sf_bind_emul(struct sandbox_state *state, int 
busnum, int cs,
 void sandbox_sf_unbind_emul(struct sandbox_state *state, int busnum, int cs);
 
 #else
-struct spi_flash *spi_flash_probe(unsigned int bus, unsigned int cs,
-   unsigned int max_hz, unsigned int spi_mode);
 
 /**
  * Set up a new SPI flash from an fdt node
@@ -207,8 +195,6 @@ struct spi_flash *spi_flash_probe(unsigned int bus, 
unsigned int cs,
 struct spi_flash *spi_flash_probe_fdt(const void *blob, int slave_node,
  int spi_node);
 
-void spi_flash_free(struct spi_flash *flash);
-
 static inline int spi_flash_read(struct spi_flash *flash, u32 offset,
size_t len, void *buf)
 {
@@ -228,6 +214,10 @@ static inline int spi_flash_erase(struct spi_flash *flash, 
u32 offset,
 }
 #endif
 
+struct spi_flash *spi_flash_probe(unsigned int bus, unsigned int cs,
+   unsigned int max_hz, unsigned int spi_mode);
+void spi_flash_free(struct spi_flash *flash);
+
 void spi_boot(void) __noreturn;
 void spi_spl_load_image(uint32_t offs, unsigned int size, void *vdst);
 
-- 
1.9.1

___
U-Boot mailing 

[U-Boot] [PATCH 3/3] sf: Remove spi_flash_remove

[Jagan Teki]

Use direct call to device_remove instead of exctra
spi_flash_remove defination.

Signed-off-by: Jagan Teki 
Cc: Simon Glass 
---
 drivers/mtd/spi/sf-uclass.c | 7 +--
 include/spi_flash.h | 2 --
 2 files changed, 1 insertion(+), 8 deletions(-)

diff --git a/drivers/mtd/spi/sf-uclass.c b/drivers/mtd/spi/sf-uclass.c
index a1c5810..60d6cd9 100644
--- a/drivers/mtd/spi/sf-uclass.c
+++ b/drivers/mtd/spi/sf-uclass.c
@@ -29,7 +29,7 @@ int spi_flash_erase_dm(struct udevice *dev, u32 offset, 
size_t len)
 
 void spi_flash_free(struct spi_flash *flash)
 {
-   spi_flash_remove(flash->spi->dev);
+   device_remove(flash->spi->dev);
 }
 
 static int spi_flash_probe_bus_cs(unsigned int busnum, unsigned int cs,
@@ -77,11 +77,6 @@ struct spi_flash *spi_flash_probe(unsigned int busnum, 
unsigned int cs,
return dev_get_uclass_priv(new);
 }
 
-int spi_flash_remove(struct udevice *dev)
-{
-   return device_remove(dev);
-}
-
 UCLASS_DRIVER(spi_flash) = {
.id = UCLASS_SPI_FLASH,
.name   = "spi_flash",
diff --git a/include/spi_flash.h b/include/spi_flash.h
index 0afc9fb..0037f0b 100644
--- a/include/spi_flash.h
+++ b/include/spi_flash.h
@@ -154,8 +154,6 @@ int spi_flash_write_dm(struct udevice *dev, u32 offset, 
size_t len,
  */
 int spi_flash_erase_dm(struct udevice *dev, u32 offset, size_t len);
 
-int spi_flash_remove(struct udevice *flash);
-
 static inline int spi_flash_read(struct spi_flash *flash, u32 offset,
 size_t len, void *buf)
 {
-- 
1.9.1

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

Re: [U-Boot] [PATCH v2] Tegra: T210: Add QSPI driver

[Stephen Warren]

On 10/16/2015 04:23 PM, Tom Warren wrote:

This is the normal Tegra SPI driver modified to work with the
QSPI controller in Tegra210. It does not do 2x/4x transfers
or any other QSPI protocol.


I've just realized we don't have a binding document for QSPI. I believe 
we need to get one into the Linux kernel's DT binding docs repo as part 
of the work on this driver. Presumably this controller is very similar 
to the other Tegra SPI controllers, so this will be a simple process.


The code looks OK at a quick glance, except for the nit below.


diff --git a/drivers/spi/tegra210_qspi.c b/drivers/spi/tegra210_qspi.c



+static int tegra210_qspi_claim_bus(struct udevice *bus)



+   /* Clear stale status here */
+   setbits_le32(>fifo_status,
+QSPI_FIFO_STS_ERR  |
+QSPI_FIFO_STS_TX_FIFO_OVF  |
+QSPI_FIFO_STS_TX_FIFO_UNR  |
+QSPI_FIFO_STS_RX_FIFO_OVF  |
+QSPI_FIFO_STS_RX_FIFO_UNR  |
+QSPI_FIFO_STS_TX_FIFO_FULL |
+QSPI_FIFO_STS_TX_FIFO_EMPTY|
+QSPI_FIFO_STS_RX_FIFO_FULL |
+QSPI_FIFO_STS_RX_FIFO_EMPTY);
+   debug("%s: FIFO STATUS = %08x\n", __func__, readl(>fifo_status));


Isn't this redundant with the status clear at the start of 
tegra210_qspi_xfer()?

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

Re: [U-Boot] Building for several archs

[York Sun]

On 10/19/2015 02:17 PM, Fabio Estevam wrote:
> Hi,
> 
> I am working on a patch series that I need to test across several
> architectures (Need to build all the boards that select
> CONFIG_SPI_FLASH_STMICRO).
> 
> I started trying to accomplish this task with buildman and it failed
> to build. After that I tried building it manually.
> 
> I am getting the following errors on top of head U-boot:
> 
> m68k:
> 
> http://pastebin.com/hX5KWDPK
> 
> powerpc:
> 
> http://pastebin.com/rK0MUp1F
> 
> With these toolchains I am able to build the kernel without issues.
> 
> Any ideas?
> 

For the powerpc build, I don't see you specify a target.

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

Re: [U-Boot] Building for several archs

[York Sun]

On 10/19/2015 02:27 PM, Fabio Estevam wrote:
> On Mon, Oct 19, 2015 at 7:21 PM, York Sun  wrote:
>> On 10/19/2015 02:17 PM, Fabio Estevam wrote:
>>> Hi,
>>>
>>> I am working on a patch series that I need to test across several
>>> architectures (Need to build all the boards that select
>>> CONFIG_SPI_FLASH_STMICRO).
>>>
>>> I started trying to accomplish this task with buildman and it failed
>>> to build. After that I tried building it manually.
>>>
>>> I am getting the following errors on top of head U-boot:
>>>
>>> m68k:
>>>
>>> http://pastebin.com/hX5KWDPK
>>>
>>> powerpc:
>>>
>>> http://pastebin.com/rK0MUp1F
>>>
>>> With these toolchains I am able to build the kernel without issues.
>>>
>>> Any ideas?
>>>
>>
>> For the powerpc build, I don't see you specify a target.
> 
> Sorry, here is the complete log:
> http://pastebin.com/ngp0WWB7
> 
> The target I am trying to build is T1024QDS_NAND_defconfig.
> 

I didn't have any compiling issue with rc5. Will try the latest later today.

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