[U-Boot] u-boot wiki page on "fdt" command full of "FDT_ERR_BADMAGIC"

[Robert P. J. Day]

  was perusing the wiki page on "fdt":

http://www.denx.de/wiki/view/DULG/UBootCmdFDT

and it's fairly loaded with examples of commands that generate only
the error message:

  libfdt fdt_path_offset() returned FDT_ERR_BADMAGIC

were those supposed to be eventually replaced by valid output?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

[U-Boot] [PATCH] x86: qemu: Move qfw command over to cmd and add Kconfig entry

[Tom Rini]

- Move the command portion of arch/x86/cpu/qemu/fw_cfg.c into
  cmd/qemu_fw_cfg.c
- Move arch/x86/include/asm/fw_cfg.h to include/qemu_fw_cfg.h
- Rename ACPI table portion to arch/x86/cpu/qemu/acpi_table.c

Signed-off-by: Tom Rini 
---
The QEMU firmware interface is more generic feature than just x86/qemu so
we need to start by moving the code out of arch/x86 and into cmd

 arch/x86/cpu/mp_init.c |   2 +-
 arch/x86/cpu/qemu/Makefile |   3 +-
 arch/x86/cpu/qemu/acpi_table.c | 243 
 arch/x86/cpu/qemu/cpu.c|   2 +-
 arch/x86/cpu/qemu/qemu.c   |   2 +-
 arch/x86/lib/acpi_table.c  |   2 +-
 cmd/Kconfig|   6 +
 cmd/Makefile   |   1 +
 arch/x86/cpu/qemu/fw_cfg.c => cmd/qemu_fw_cfg.c| 245 +
 configs/qemu-x86_defconfig |   1 +
 .../include/asm/fw_cfg.h => include/qemu_fw_cfg.h  |   5 +
 11 files changed, 271 insertions(+), 241 deletions(-)
 create mode 100644 arch/x86/cpu/qemu/acpi_table.c
 rename arch/x86/cpu/qemu/fw_cfg.c => cmd/qemu_fw_cfg.c (53%)
 rename arch/x86/include/asm/fw_cfg.h => include/qemu_fw_cfg.h (94%)

diff --git a/arch/x86/cpu/mp_init.c b/arch/x86/cpu/mp_init.c
index 2604a68..13bec7a 100644
--- a/arch/x86/cpu/mp_init.c
+++ b/arch/x86/cpu/mp_init.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -21,7 +22,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/cpu/qemu/Makefile b/arch/x86/cpu/qemu/Makefile
index 6eeddf1..97b965c 100644
--- a/arch/x86/cpu/qemu/Makefile
+++ b/arch/x86/cpu/qemu/Makefile
@@ -7,4 +7,5 @@
 ifndef CONFIG_EFI_STUB
 obj-y += car.o dram.o
 endif
-obj-y += cpu.o fw_cfg.o qemu.o
+obj-y += cpu.o qemu.o
+obj-$(CONFIG_QEMU_ACPI_TABLE) += acpi_table.o
diff --git a/arch/x86/cpu/qemu/acpi_table.c b/arch/x86/cpu/qemu/acpi_table.c
new file mode 100644
index 000..49381ac
--- /dev/null
+++ b/arch/x86/cpu/qemu/acpi_table.c
@@ -0,0 +1,243 @@
+/*
+ * (C) Copyright 2015 Miao Yan 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * This function allocates memory for ACPI tables
+ *
+ * @entry : BIOS linker command entry which tells where to allocate memory
+ *  (either high memory or low memory)
+ * @addr  : The address that should be used for low memory allcation. If the
+ *  memory allocation request is 'ZONE_HIGH' then this parameter will
+ *  be ignored.
+ * @return: 0 on success, or negative value on failure
+ */
+static int bios_linker_allocate(struct bios_linker_entry *entry, u32 *addr)
+{
+   uint32_t size, align;
+   struct fw_file *file;
+   unsigned long aligned_addr;
+
+   align = le32_to_cpu(entry->alloc.align);
+   /* align must be power of 2 */
+   if (align & (align - 1)) {
+   printf("error: wrong alignment %u\n", align);
+   return -EINVAL;
+   }
+
+   file = qemu_fwcfg_find_file(entry->alloc.file);
+   if (!file) {
+   printf("error: can't find file %s\n", entry->alloc.file);
+   return -ENOENT;
+   }
+
+   size = be32_to_cpu(file->cfg.size);
+
+   /*
+* ZONE_HIGH means we need to allocate from high memory, since
+* malloc space is already at the end of RAM, so we directly use it.
+* If allocation zone is ZONE_FSEG, then we use the 'addr' passed
+* in which is low memory
+*/
+   if (entry->alloc.zone == BIOS_LINKER_LOADER_ALLOC_ZONE_HIGH) {
+   aligned_addr = (unsigned long)memalign(align, size);
+   if (!aligned_addr) {
+   printf("error: allocating resource\n");
+   return -ENOMEM;
+   }
+   } else if (entry->alloc.zone == BIOS_LINKER_LOADER_ALLOC_ZONE_FSEG) {
+   aligned_addr = ALIGN(*addr, align);
+   } else {
+   printf("error: invalid allocation zone\n");
+   return -EINVAL;
+   }
+
+   debug("bios_linker_allocate: allocate file %s, size %u, zone %d, align 
%u, addr 0x%lx\n",
+ file->cfg.name, size, entry->alloc.zone, align, aligned_addr);
+
+   qemu_fwcfg_read_entry(be16_to_cpu(file->cfg.select),
+ size, (void *)aligned_addr);
+   file->addr = aligned_addr;
+
+   /* adjust address for low memory allocation */
+   if (entry->alloc.zone == BIOS_LINKER_LOADER_ALLOC_ZONE_FSEG)
+   *addr = (aligned_addr + size);
+
+   return 0;
+}
+
+/*
+ * This function patches ACPI tables previously loaded
+ * by bios_linker_allocate()
+ *
+ * @entry : BIOS linker command entry 

Re: [U-Boot] [verified-boot] Compile 'key store' DTB without mkimage and private key

[Teddy Reed]

On Fri, Apr 29, 2016 at 4:09 PM, Simon Glass  wrote:
> Hi Teddy,
>
> On 25 April 2016 at 10:25, Teddy Reed  wrote:
>> Hi all,
>>
>> I'm curious if anyone has a script (or if I've missed something within
>> the verified-boot documentation) to compile a DTB given only public
>> keying information, i.e., a x509 certificate.
>>
>> I have build/test bots that need to build a u-boot with an
>> extra/embedded DTB containing a signing public key. I do not want the
>> private key on those hosts and the only way I've found to build the
>> documented/required nodes in /signature/key-KEYNAME/
>> ('rsa,r-squared','rsa,modulus', 'rsa,n0-inverse' and 'rsa-num-bits')
>> is by using mkimage on a FIT with the -K switch. That requires a
>> private key to do the actual signing.
>>
>> I'm happy to write something, just want to ask first!
>
> Not on my side, sorry. Would be useful.
>

Ok!

I can't make any promises of completeness, but I quickly hacked
together https://github.com/theopolis/fit-certificate-store, to do
this.
I'll iterate on it over the next few weeks, and I'm more than happy to
take bugs/criticism via Github PRs.

>>
>> Thanks!
>>
>> --
>> Teddy Reed V
>
> Regards,
> Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] armv8: ls1043ardb: invert irq pin polarity for AQR105 PHY

[shh.xie]

From: Shaohui Xie 

To use AQR105 PHY's interrupt, we need to invert the IRQ pin polarity by
setting relative bit in SCFG_INTPCR register, because AQR105 interrupt
is low active but GIC accepts high active.

Signed-off-by: Shaohui Xie 
---
 board/freescale/ls1043ardb/ls1043ardb.c | 4 
 include/configs/ls1043ardb.h| 1 +
 2 files changed, 5 insertions(+)

diff --git a/board/freescale/ls1043ardb/ls1043ardb.c 
b/board/freescale/ls1043ardb/ls1043ardb.c
index ec5fdbf..9e9f24d 100644
--- a/board/freescale/ls1043ardb/ls1043ardb.c
+++ b/board/freescale/ls1043ardb/ls1043ardb.c
@@ -84,6 +84,8 @@ int board_early_init_f(void)
 int board_init(void)
 {
struct ccsr_cci400 *cci = (struct ccsr_cci400 *)CONFIG_SYS_CCI400_ADDR;
+   struct ccsr_scfg *scfg = (struct ccsr_scfg *)CONFIG_SYS_FSL_SCFG_ADDR;
+
 
/*
 * Set CCI-400 control override register to enable barrier
@@ -106,6 +108,8 @@ int board_init(void)
 #ifdef CONFIG_U_QE
u_qe_init();
 #endif
+   /* invert AQR105 IRQ pins polarity */
+   out_be32(>intpcr, AQR105_IRQ_MASK);
 
return 0;
 }
diff --git a/include/configs/ls1043ardb.h b/include/configs/ls1043ardb.h
index bc40b06..bfc1a5c 100644
--- a/include/configs/ls1043ardb.h
+++ b/include/configs/ls1043ardb.h
@@ -254,6 +254,7 @@
 #define CONFIG_PHY_VITESSE
 #define CONFIG_PHY_REALTEK
 #define CONFIG_PHY_AQUANTIA
+#define AQR105_IRQ_MASK0x4000
 
 #define RGMII_PHY1_ADDR0x1
 #define RGMII_PHY2_ADDR0x2
-- 
2.1.0.27.g96db324

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

[U-Boot] Devicetree specification process

[Grant Likely]

I'm pleased to announce the first *very early draft* of the new
devicetree specification that I and several others have been working
on since January. This document picks up where ePAPR left off in 2012.
I'm announcing it now along with the new devicetree.org organization
which will handle governance for the spec.

We're still in the process of getting all the details sorted out (not
everything on the website is accurate at the moment), but in the mean
time you can look at the current state of the document. At the moment,
it is little more than repackaging the ePAPR text. The next step will
be pulling in the new core bindings that were never covered by ePAPR.
You can look at a draft copy of the document here:

https://github.com/kvekaria/devicetree-specification-released/blob/master/prerelease/DevicetreeSpecification-20160429-pre1.pdf

If you want to help out, the document source markup can be cloned from
GitHub. You can find the project page here:

https://github.com/devicetree-org/devicetree-specification

Feedback is greatly appreciate. Please send any comments and/or
changes to the devicetree specification mailing list:

devicetree-s...@vger.kernel.org

For more information, you can refer to the slides presented at BKK16 and ELC[1].

[1] 
http://elinux.org/images/b/b7/Devicetree_specification_linaro_connect_bangkok_2016.pdf

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

Re: [U-Boot] [verified-boot] Compile 'key store' DTB without mkimage and private key

[Simon Glass]

Hi Teddy,

On 25 April 2016 at 10:25, Teddy Reed  wrote:
> Hi all,
>
> I'm curious if anyone has a script (or if I've missed something within
> the verified-boot documentation) to compile a DTB given only public
> keying information, i.e., a x509 certificate.
>
> I have build/test bots that need to build a u-boot with an
> extra/embedded DTB containing a signing public key. I do not want the
> private key on those hosts and the only way I've found to build the
> documented/required nodes in /signature/key-KEYNAME/
> ('rsa,r-squared','rsa,modulus', 'rsa,n0-inverse' and 'rsa-num-bits')
> is by using mkimage on a FIT with the -K switch. That requires a
> private key to do the actual signing.
>
> I'm happy to write something, just want to ask first!

Not on my side, sorry. Would be useful.

>
> Thanks!
>
> --
> Teddy Reed V

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

[U-Boot] precedence of specifying mtdparts using DTB versus "mtdparts="?

[Robert P. J. Day]

  i'm sure i'm just being an idiot here (pause for hysterical
laughter), but what is the precedence for overriding the partition
layout of flash using one of:

1) "mtdparts=" added to the kernel command line, or
2) using "fdt" command to hack DTB to change partition layout

  the scenario is a perfectly decent DTB defining the breakdown of 2M
of NOR flash ... that is unfortunately being used on a system with 4M
of flash, where the first 2M should be ignored and the second 2M is
what should be used. so all i want to do is tweak the flash definition
to say that, yes, i have 4M of NOR flash, but let's add a 2M "junk"
partition at the front so i can skip that and get to the normal stuff.

  (i realize that will shift all /dev/mtd* names by one, no problem,
i can handle that.)

  first question -- if i define flash layout both in the DTB and on
the kernel command line, which one takes precedence?

  second question -- if the DTB layout takes precedence (i'm guessing
it does), is it sufficient to use the "fdt" command to remove all of
the partition definitions so that the kernel command line will be
consulted? (i don't mean remove the entire flash node from the DTB,
just the set of internal partition definitions.)

  final question -- i was trying to use mtdparts= on the command
line, and it seemed like i was supplying the wrong value for 
in:

mtdparts=[;

[U-Boot] [PATCH] tools: env: fix config file loading in env library

[Anatolij Gustschin]

env library is broken as the config file pointer is only initialized
in main(). When running in the env library parse_config() fails:

  Cannot parse config file '(null)': Bad address

Ensure that config file pointer is always initialized.

Signed-off-by: Anatolij Gustschin 
Cc: Stefano Babic 
---
 tools/env/fw_env.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/tools/env/fw_env.c b/tools/env/fw_env.c
index 1420ac5..06cf63d 100644
--- a/tools/env/fw_env.c
+++ b/tools/env/fw_env.c
@@ -1325,6 +1325,9 @@ static int parse_config ()
struct stat st;
 
 #if defined(CONFIG_FILE)
+   if (!common_args.config_file)
+   common_args.config_file = CONFIG_FILE;
+
/* Fills in DEVNAME(), ENVSIZE(), DEVESIZE(). Or don't. */
if (get_config(common_args.config_file)) {
fprintf(stderr, "Cannot parse config file '%s': %m\n",
-- 
1.7.9.5

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

Re: [U-Boot] [PATCH 38/60] ARM: tegra: remove tegra_get_chip()

[Stephen Warren]

On 04/29/2016 11:42 AM, Simon Glass wrote:

Hi Stephen,

On 29 April 2016 at 10:53, Simon Glass  wrote:

Hi Stephen,

On 29 April 2016 at 10:27, Stephen Warren  wrote:

On 04/29/2016 08:02 AM, Simon Glass wrote:


Hi Stephen,

On 27 April 2016 at 10:13, Stephen Warren  wrote:


On 04/27/2016 08:50 AM, Simon Glass wrote:



Hi Stephen,

On 25 April 2016 at 13:25, Stephen Warren  wrote:



On 04/23/2016 11:14 AM, Simon Glass wrote:




Hi Stephen,

On 19 April 2016 at 14:59, Stephen Warren 
wrote:




From: Stephen Warren 

U-Boot is compiled for a single board, which in turn uses a specific
SoC.
There's no need to make runtime decisions based on SoC ID. While
there's
certainly an argument for making the code support different SoCs at
run-time, the Tegra code is so far from that possible ideal that the
existing runtime code is an anomaly. If this changes in the future,
all
runtime decisions should likely be based on DT anyway.

Signed-off-by: Stephen Warren 
---
 arch/arm/mach-tegra/ap.c   | 106
++---
 arch/arm/mach-tegra/cache.c|  20 +++
 arch/arm/mach-tegra/cpu.c  |  16 ++---
 arch/arm/mach-tegra/cpu.h  |   6 --
 arch/arm/mach-tegra/tegra20/warmboot.c |  20 ++-
 5 files changed, 51 insertions(+), 117 deletions(-)




What exactly is missing to prevent multi-arch support?



In a word: everything:-)

Pretty much all decisions in core architecture code, core Tegra code,
drivers, and even board files are currently made at compile time. For
example, consider drivers where the register layouts are different
between
different SoCs; not just new fields added, but existing fields moved to
different offsets. Right now, we handle this by changing the register
struct
definition at compile time. To support multiple chips, we'd have to
either
(a) link in n copies of the driver, one per register layout, or (b)
rework
the driver to use #defines and runtime calculations for register
offsets,
like the Linux kernel drivers do. Tegra USB is one example. The pinmux
and
clock drivers have a significantly different sets of
pins/clocks/resets/...
per SoC, and enums/tables describing those sets are currently
configured at
compile time. Some PMIC constants (e.g. vdd_cpu voltage) are configured
at
compile-time, and even differ per board.



I wonder how far we would get by converting clock, pinctrl, reset to
driver model drivers?



Well, I expect we'll find out soon. The next SoC has radically different
clock/reset mechanisms, so we'll need to switch to standardized APIs for
clock/reset on Tegra to isolate drivers from those differences, and I
imagine that conversion would also involve conversion to DM since any
standard APIs probably assume use of DM. I haven't investigated this in
detail yet though.



That sounds like a good move.


I'm not sure if you still object to this patch for now, or would be happy
giving it an ack?


And just to be clear, I'm always keen to move things forward and I can
see you have put a lot of work into this series. It would be easier to
just apply it as is. What I am looking for is how we might get closer
to the goal, perhaps after this series. This series has exposed this
which is why I have brought it up.


So, just to be clear: TomW can apply this (once I post V2) even if 
you're not giving an ack?



Sorry, I still feel this is going in the wrong
direction...CONFIG_TEGRA124 should mean that the code supports it,
rather than the code exclusively supports it.


That's certainly not what it means right now, and my intention in this 
series was not to address any short-comings in the current meanings of 
Kconfig.


No matter what, if we do drive all this core SoC code from DT 
eventually, I don't imagine tegra_get_chip() will be the way code gets 
dispatched between multiple chips in the future, so removing it now 
shouldn't hurt any later conversion to runtime multi-chip support.


In practice in a DT-driven world, I'd expect:

- The code in enable_scu() to be part of some Tegra20-specific "SoC 
driver" or similar, and hence not need any runtime support restored.


- The code in cache.c to be part of some specific cache drivers, which 
would only be instantiated on Tegra20, and hence not need any runtime 
support restored.


- The code in cpu.c to be moved into a clock driver, and base on some 
per-SoC table in the clock driver, and hence not need any runtime 
special-casing.


As such, I don't see reverting any of this patch being reverted later, 
and I don't believe leaving in these runtime calls would make it any 
easier to refactor the code into drivers later.



In your commit message you say:

"While there's
certainly an argument for making the code support different SoCs at
run-time, the Tegra code is so far from that possible ideal 

Re: [U-Boot] spl_mmc: allow to load raw image

[Tom Rini]

On Fri, Apr 29, 2016 at 01:06:14PM -0500, Adam Ford wrote:
> On Fri, Apr 29, 2016 at 12:53 PM, Tom Rini  wrote:
> > On Fri, Apr 29, 2016 at 09:59:00AM -0500, Adam Ford wrote:
> >
> >> Does anyone with an OMAP3 board have any issues with this patch?  I
> >> will admit I haven't stayed on top of stuff due to moving, and other
> >> issues at home, but I pulled down the master to reviews some on
> >> related stuff, and found that master doesn't boot.  I used git bisect
> >> this morning and it narrowed down a problem with booting to this
> >> patch.
> >>
> >> With the patch, I get:
> >>
> >> U-Boot SPL 2016.03-00378-g4976f48 (Apr 29 2016 - 09:25:27)
> >> Trying to boot from MMC
> >
> > OK.  Do you have u-boot.bin or u-boot.img (which?) written to the raw
> > offset in MMC or from filesystem?  Based on the log it looks like
> > filesystem.
> 
> I have u-boot.img copied to the fatfs on the card, but I didn't put it
> in a specific location.
> 
> I never used to have to do that.  Is this a new behavior and is it
> documented somewhere?

No what you're doing is a valid use case that should be working, 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] spl_mmc: allow to load raw image

[Adam Ford]

On Fri, Apr 29, 2016 at 12:53 PM, Tom Rini  wrote:
> On Fri, Apr 29, 2016 at 09:59:00AM -0500, Adam Ford wrote:
>
>> Does anyone with an OMAP3 board have any issues with this patch?  I
>> will admit I haven't stayed on top of stuff due to moving, and other
>> issues at home, but I pulled down the master to reviews some on
>> related stuff, and found that master doesn't boot.  I used git bisect
>> this morning and it narrowed down a problem with booting to this
>> patch.
>>
>> With the patch, I get:
>>
>> U-Boot SPL 2016.03-00378-g4976f48 (Apr 29 2016 - 09:25:27)
>> Trying to boot from MMC
>
> OK.  Do you have u-boot.bin or u-boot.img (which?) written to the raw
> offset in MMC or from filesystem?  Based on the log it looks like
> filesystem.

I have u-boot.img copied to the fatfs on the card, but I didn't put it
in a specific location.

I never used to have to do that.  Is this a new behavior and is it
documented somewhere?

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

Re: [U-Boot] spl_mmc: allow to load raw image

[Tom Rini]

On Fri, Apr 29, 2016 at 09:59:00AM -0500, Adam Ford wrote:

> Does anyone with an OMAP3 board have any issues with this patch?  I
> will admit I haven't stayed on top of stuff due to moving, and other
> issues at home, but I pulled down the master to reviews some on
> related stuff, and found that master doesn't boot.  I used git bisect
> this morning and it narrowed down a problem with booting to this
> patch.
> 
> With the patch, I get:
> 
> U-Boot SPL 2016.03-00378-g4976f48 (Apr 29 2016 - 09:25:27)
> Trying to boot from MMC

OK.  Do you have u-boot.bin or u-boot.img (which?) written to the raw
offset in MMC or from filesystem?  Based on the log it looks like
filesystem.

-- 
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 38/60] ARM: tegra: remove tegra_get_chip()

[Simon Glass]

Hi Stephen,

On 29 April 2016 at 10:53, Simon Glass  wrote:
> Hi Stephen,
>
> On 29 April 2016 at 10:27, Stephen Warren  wrote:
>> On 04/29/2016 08:02 AM, Simon Glass wrote:
>>>
>>> Hi Stephen,
>>>
>>> On 27 April 2016 at 10:13, Stephen Warren  wrote:

 On 04/27/2016 08:50 AM, Simon Glass wrote:
>
>
> Hi Stephen,
>
> On 25 April 2016 at 13:25, Stephen Warren  wrote:
>>
>>
>> On 04/23/2016 11:14 AM, Simon Glass wrote:
>>>
>>>
>>>
>>> Hi Stephen,
>>>
>>> On 19 April 2016 at 14:59, Stephen Warren 
>>> wrote:



 From: Stephen Warren 

 U-Boot is compiled for a single board, which in turn uses a specific
 SoC.
 There's no need to make runtime decisions based on SoC ID. While
 there's
 certainly an argument for making the code support different SoCs at
 run-time, the Tegra code is so far from that possible ideal that the
 existing runtime code is an anomaly. If this changes in the future,
 all
 runtime decisions should likely be based on DT anyway.

 Signed-off-by: Stephen Warren 
 ---
 arch/arm/mach-tegra/ap.c   | 106
 ++---
 arch/arm/mach-tegra/cache.c|  20 +++
 arch/arm/mach-tegra/cpu.c  |  16 ++---
 arch/arm/mach-tegra/cpu.h  |   6 --
 arch/arm/mach-tegra/tegra20/warmboot.c |  20 ++-
 5 files changed, 51 insertions(+), 117 deletions(-)
>>>
>>>
>>>
>>> What exactly is missing to prevent multi-arch support?
>>
>>
>> In a word: everything:-)
>>
>> Pretty much all decisions in core architecture code, core Tegra code,
>> drivers, and even board files are currently made at compile time. For
>> example, consider drivers where the register layouts are different
>> between
>> different SoCs; not just new fields added, but existing fields moved to
>> different offsets. Right now, we handle this by changing the register
>> struct
>> definition at compile time. To support multiple chips, we'd have to
>> either
>> (a) link in n copies of the driver, one per register layout, or (b)
>> rework
>> the driver to use #defines and runtime calculations for register
>> offsets,
>> like the Linux kernel drivers do. Tegra USB is one example. The pinmux
>> and
>> clock drivers have a significantly different sets of
>> pins/clocks/resets/...
>> per SoC, and enums/tables describing those sets are currently
>> configured at
>> compile time. Some PMIC constants (e.g. vdd_cpu voltage) are configured
>> at
>> compile-time, and even differ per board.
>
>
> I wonder how far we would get by converting clock, pinctrl, reset to
> driver model drivers?


 Well, I expect we'll find out soon. The next SoC has radically different
 clock/reset mechanisms, so we'll need to switch to standardized APIs for
 clock/reset on Tegra to isolate drivers from those differences, and I
 imagine that conversion would also involve conversion to DM since any
 standard APIs probably assume use of DM. I haven't investigated this in
 detail yet though.
>>>
>>>
>>> That sounds like a good move.
>>
>>
>> I'm not sure if you still object to this patch for now, or would be happy
>> giving it an ack?

And just to be clear, I'm always keen to move things forward and I can
see you have put a lot of work into this series. It would be easier to
just apply it as is. What I am looking for is how we might get closer
to the goal, perhaps after this series. This series has exposed this
which is why I have brought it up.

>
> Sorry, I still feel this is going in the wrong
> direction...CONFIG_TEGRA124 should mean that the code supports it,
> rather than the code exclusively supports it.
>
> In your commit message you say:
>
> "While there's
> certainly an argument for making the code support different SoCs at
> run-time, the Tegra code is so far from that possible ideal that the
> existing runtime code is an anomaly. If this changes in the future, all
> runtime decisions should likely be based on DT anyway."
>
> Or even build time That statement  seems like saying that
> everything is so terrible that we might as well give up.
>
> What's your plan to move code into drivers? I am happy to help move
> things over and get towards the goal rather than further away. But
> really that should happen first.
>
> Also, the model that seems to be emerging is that SPL detects the
> platform and passes the correct DT to U-Boot proper.
>
> Specifically I think the end state should be:
> - Most SoC code is in drivers 

Re: [U-Boot] [RFC PATCH] dm: ensure device names are unique

[Simon Glass]

Hi Stephen,

On 29 April 2016 at 10:30, Stephen Warren  wrote:
> On 04/29/2016 10:28 AM, Simon Glass wrote:
>>
>> Hi Stephen,
>>
>> On 29 April 2016 at 10:23, Stephen Warren  wrote:
>>>
>>> On 04/29/2016 07:23 AM, Simon Glass wrote:


 Hi Stephen,

 On 28 April 2016 at 09:55, Stephen Warren  wrote:
>
>
> On 04/27/2016 10:50 PM, Simon Glass wrote:
>>
>>
>>
>> Hi Stephen,
>>
>> On 26 April 2016 at 15:30, Stephen Warren wrote:
>>> It is possible for HW to contain multiple instances of the same
>> device.
>> In
>>> this case, the name passed to device_bind() may not be unique
>> across
>> all
>>> devices within its uclass. One example is a system with multiple
>> identical
>>> PCI Ethernet devices. Another might be a system with multiple
>> identical
>>> I2C GPIO expanders, each connected to a separate I2C bus, yet
>> using
>> the
>>> same I2C address on that bus and hence having the same DT node
>> name.
>>>
>>> Enhance the code to detect this situation, and append a sequence
>> number so
>>> the device name to ensure uniqueness.
>>>
>>> Signed-off-by: Stephen Warren > >
>>
>> I would rather that the caller handles this. But failing this perhaps
>> a
>> new function that does it? Is this for the Ethernet use case?
>
>
>
>
> Wouldn't all callers of this function simply call the new function? I'm
> not
> aware of any case where the code to avoid duplicate names would not be
> desired.
>
> I hit this for the Ethernet case, but I believe it applies to any type
> of
> device at all; see another possible trigger case in the commit
> description.



 This does not happen with devices from the device tree. It only
 happens with auto-probed devices. Your I2C GPIO example is odd but I'd
 rather solve that by using the device tree node name.
>>>
>>>
>>>
>>> DT itself imposes no such rule; node names must be unique only within
>>> their
>>> parent node but there's no restriction on identical node names appearing
>>> in
>>> different parts of the tree.
>>>
>>> If U-Boot imposes that rule on DT, then there's no way in general that we
>>> can guarantee U-Boot will be able to use standard DTs (i.e. identical to
>>> those used by Linux or any other OS) for any platform; it'd be another
>>> change someone would need to make to transform a DT to be "U-Boot
>>> compatible", which rather reduces a potential benefit of DT for U-Boot;
>>> being able to just drop a DT in and have it work.
>>
>>
>> U-Boot does not impose a rule. If you want duplicate device names you
>> can have them. I think it is bad practice though.
>>
>>>
>>> It would be possible for U-Boot to decouple its internal device name from
>>> the DT node name. In which case, your statement would work. However, I
>>> don't
>>> think that's the case at the moment, and in fact it's effectively what
>>> this
>>> patch is doing, although admittedly there are other ways of doing this.
>>
>>
>> Anyway I believe my point stands. Whereas users can edit the device
>> tree and avoid conflicts they cannot do this with auto-probed devices.
>> So for that case we should have a way of allocating a name before
>> calling device_bind().
>
>
> OK. I'm just going to solve this by unplugging the second Ethernet card, or
> holding this patch locally for the case when I need to test the PCIe port.
>

Binding a device needs to be as cheap as possible. 99% of the time the
name is fine, and we know the cases where it might not be. This is
similar to the DM_UC_FLAG_SEQ_ALIAS - expensive functionality should
be separated out so we don't require everyone to use it. It just
creates bloat.

So please when contributing things to driver model (which is most
welcome and appreciated) be a little more flexible. It should not take
this much energy to explain the design principles and get a change to
a patch.

Also see u-boot-dm/blkb-working which includes the allocation of
device names. I need to resolve the comments and respin...

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

Re: [U-Boot] [PATCH 38/60] ARM: tegra: remove tegra_get_chip()

[Simon Glass]

Hi Stephen,

On 29 April 2016 at 10:27, Stephen Warren  wrote:
> On 04/29/2016 08:02 AM, Simon Glass wrote:
>>
>> Hi Stephen,
>>
>> On 27 April 2016 at 10:13, Stephen Warren  wrote:
>>>
>>> On 04/27/2016 08:50 AM, Simon Glass wrote:


 Hi Stephen,

 On 25 April 2016 at 13:25, Stephen Warren  wrote:
>
>
> On 04/23/2016 11:14 AM, Simon Glass wrote:
>>
>>
>>
>> Hi Stephen,
>>
>> On 19 April 2016 at 14:59, Stephen Warren 
>> wrote:
>>>
>>>
>>>
>>> From: Stephen Warren 
>>>
>>> U-Boot is compiled for a single board, which in turn uses a specific
>>> SoC.
>>> There's no need to make runtime decisions based on SoC ID. While
>>> there's
>>> certainly an argument for making the code support different SoCs at
>>> run-time, the Tegra code is so far from that possible ideal that the
>>> existing runtime code is an anomaly. If this changes in the future,
>>> all
>>> runtime decisions should likely be based on DT anyway.
>>>
>>> Signed-off-by: Stephen Warren 
>>> ---
>>> arch/arm/mach-tegra/ap.c   | 106
>>> ++---
>>> arch/arm/mach-tegra/cache.c|  20 +++
>>> arch/arm/mach-tegra/cpu.c  |  16 ++---
>>> arch/arm/mach-tegra/cpu.h  |   6 --
>>> arch/arm/mach-tegra/tegra20/warmboot.c |  20 ++-
>>> 5 files changed, 51 insertions(+), 117 deletions(-)
>>
>>
>>
>> What exactly is missing to prevent multi-arch support?
>
>
> In a word: everything:-)
>
> Pretty much all decisions in core architecture code, core Tegra code,
> drivers, and even board files are currently made at compile time. For
> example, consider drivers where the register layouts are different
> between
> different SoCs; not just new fields added, but existing fields moved to
> different offsets. Right now, we handle this by changing the register
> struct
> definition at compile time. To support multiple chips, we'd have to
> either
> (a) link in n copies of the driver, one per register layout, or (b)
> rework
> the driver to use #defines and runtime calculations for register
> offsets,
> like the Linux kernel drivers do. Tegra USB is one example. The pinmux
> and
> clock drivers have a significantly different sets of
> pins/clocks/resets/...
> per SoC, and enums/tables describing those sets are currently
> configured at
> compile time. Some PMIC constants (e.g. vdd_cpu voltage) are configured
> at
> compile-time, and even differ per board.


 I wonder how far we would get by converting clock, pinctrl, reset to
 driver model drivers?
>>>
>>>
>>> Well, I expect we'll find out soon. The next SoC has radically different
>>> clock/reset mechanisms, so we'll need to switch to standardized APIs for
>>> clock/reset on Tegra to isolate drivers from those differences, and I
>>> imagine that conversion would also involve conversion to DM since any
>>> standard APIs probably assume use of DM. I haven't investigated this in
>>> detail yet though.
>>
>>
>> That sounds like a good move.
>
>
> I'm not sure if you still object to this patch for now, or would be happy
> giving it an ack?

Sorry, I still feel this is going in the wrong
direction...CONFIG_TEGRA124 should mean that the code supports it,
rather than the code exclusively supports it.

In your commit message you say:

"While there's
certainly an argument for making the code support different SoCs at
run-time, the Tegra code is so far from that possible ideal that the
existing runtime code is an anomaly. If this changes in the future, all
runtime decisions should likely be based on DT anyway."

Or even build time That statement  seems like saying that
everything is so terrible that we might as well give up.

What's your plan to move code into drivers? I am happy to help move
things over and get towards the goal rather than further away. But
really that should happen first.

Also, the model that seems to be emerging is that SPL detects the
platform and passes the correct DT to U-Boot proper.

Specifically I think the end state should be:
- Most SoC code is in drivers using driver model
- It is possible to build most of the tegra code without building each
SoC (just by having a 'tegra' board which enables all drivers)
- If someone wanted to support multiple SoCs it would not be
impossible to do so (even if mainline doesn't make it)
- New SoCs are supported mostly by adding new drivers (although there
is always of course some core/start-up code)

Do you agree with that?

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de

Re: [U-Boot] [RFC PATCH] dm: ensure device names are unique

[Stephen Warren]

On 04/29/2016 10:28 AM, Simon Glass wrote:

Hi Stephen,

On 29 April 2016 at 10:23, Stephen Warren  wrote:

On 04/29/2016 07:23 AM, Simon Glass wrote:


Hi Stephen,

On 28 April 2016 at 09:55, Stephen Warren  wrote:


On 04/27/2016 10:50 PM, Simon Glass wrote:



Hi Stephen,

On 26 April 2016 at 15:30, Stephen Warren wrote:
   > It is possible for HW to contain multiple instances of the same
device.
In
   > this case, the name passed to device_bind() may not be unique across
all
   > devices within its uclass. One example is a system with multiple
identical
   > PCI Ethernet devices. Another might be a system with multiple
identical
   > I2C GPIO expanders, each connected to a separate I2C bus, yet using
the
   > same I2C address on that bus and hence having the same DT node name.
   >
   > Enhance the code to detect this situation, and append a sequence
number so
   > the device name to ensure uniqueness.
   >
   > Signed-off-by: Stephen Warren >

I would rather that the caller handles this. But failing this perhaps a
new function that does it? Is this for the Ethernet use case?




Wouldn't all callers of this function simply call the new function? I'm
not
aware of any case where the code to avoid duplicate names would not be
desired.

I hit this for the Ethernet case, but I believe it applies to any type of
device at all; see another possible trigger case in the commit
description.



This does not happen with devices from the device tree. It only
happens with auto-probed devices. Your I2C GPIO example is odd but I'd
rather solve that by using the device tree node name.



DT itself imposes no such rule; node names must be unique only within their
parent node but there's no restriction on identical node names appearing in
different parts of the tree.

If U-Boot imposes that rule on DT, then there's no way in general that we
can guarantee U-Boot will be able to use standard DTs (i.e. identical to
those used by Linux or any other OS) for any platform; it'd be another
change someone would need to make to transform a DT to be "U-Boot
compatible", which rather reduces a potential benefit of DT for U-Boot;
being able to just drop a DT in and have it work.


U-Boot does not impose a rule. If you want duplicate device names you
can have them. I think it is bad practice though.



It would be possible for U-Boot to decouple its internal device name from
the DT node name. In which case, your statement would work. However, I don't
think that's the case at the moment, and in fact it's effectively what this
patch is doing, although admittedly there are other ways of doing this.


Anyway I believe my point stands. Whereas users can edit the device
tree and avoid conflicts they cannot do this with auto-probed devices.
So for that case we should have a way of allocating a name before
calling device_bind().


OK. I'm just going to solve this by unplugging the second Ethernet card, 
or holding this patch locally for the case when I need to test the PCIe 
port.


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

Re: [U-Boot] [RFC PATCH] dm: ensure device names are unique

[Simon Glass]

Hi Stephen,

On 29 April 2016 at 10:23, Stephen Warren  wrote:
> On 04/29/2016 07:23 AM, Simon Glass wrote:
>>
>> Hi Stephen,
>>
>> On 28 April 2016 at 09:55, Stephen Warren  wrote:
>>>
>>> On 04/27/2016 10:50 PM, Simon Glass wrote:


 Hi Stephen,

 On 26 April 2016 at 15:30, Stephen Warren wrote:
   > It is possible for HW to contain multiple instances of the same
 device.
 In
   > this case, the name passed to device_bind() may not be unique across
 all
   > devices within its uclass. One example is a system with multiple
 identical
   > PCI Ethernet devices. Another might be a system with multiple
 identical
   > I2C GPIO expanders, each connected to a separate I2C bus, yet using
 the
   > same I2C address on that bus and hence having the same DT node name.
   >
   > Enhance the code to detect this situation, and append a sequence
 number so
   > the device name to ensure uniqueness.
   >
   > Signed-off-by: Stephen Warren >

 I would rather that the caller handles this. But failing this perhaps a
 new function that does it? Is this for the Ethernet use case?
>>>
>>>
>>>
>>> Wouldn't all callers of this function simply call the new function? I'm
>>> not
>>> aware of any case where the code to avoid duplicate names would not be
>>> desired.
>>>
>>> I hit this for the Ethernet case, but I believe it applies to any type of
>>> device at all; see another possible trigger case in the commit
>>> description.
>>
>>
>> This does not happen with devices from the device tree. It only
>> happens with auto-probed devices. Your I2C GPIO example is odd but I'd
>> rather solve that by using the device tree node name.
>
>
> DT itself imposes no such rule; node names must be unique only within their
> parent node but there's no restriction on identical node names appearing in
> different parts of the tree.
>
> If U-Boot imposes that rule on DT, then there's no way in general that we
> can guarantee U-Boot will be able to use standard DTs (i.e. identical to
> those used by Linux or any other OS) for any platform; it'd be another
> change someone would need to make to transform a DT to be "U-Boot
> compatible", which rather reduces a potential benefit of DT for U-Boot;
> being able to just drop a DT in and have it work.

U-Boot does not impose a rule. If you want duplicate device names you
can have them. I think it is bad practice though.

>
> It would be possible for U-Boot to decouple its internal device name from
> the DT node name. In which case, your statement would work. However, I don't
> think that's the case at the moment, and in fact it's effectively what this
> patch is doing, although admittedly there are other ways of doing this.

Anyway I believe my point stands. Whereas users can edit the device
tree and avoid conflicts they cannot do this with auto-probed devices.
So for that case we should have a way of allocating a name before
calling device_bind().

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

Re: [U-Boot] [PATCH 38/60] ARM: tegra: remove tegra_get_chip()

[Stephen Warren]

On 04/29/2016 08:02 AM, Simon Glass wrote:

Hi Stephen,

On 27 April 2016 at 10:13, Stephen Warren  wrote:

On 04/27/2016 08:50 AM, Simon Glass wrote:


Hi Stephen,

On 25 April 2016 at 13:25, Stephen Warren  wrote:


On 04/23/2016 11:14 AM, Simon Glass wrote:



Hi Stephen,

On 19 April 2016 at 14:59, Stephen Warren  wrote:



From: Stephen Warren 

U-Boot is compiled for a single board, which in turn uses a specific
SoC.
There's no need to make runtime decisions based on SoC ID. While
there's
certainly an argument for making the code support different SoCs at
run-time, the Tegra code is so far from that possible ideal that the
existing runtime code is an anomaly. If this changes in the future, all
runtime decisions should likely be based on DT anyway.

Signed-off-by: Stephen Warren 
---
arch/arm/mach-tegra/ap.c   | 106 
++---
arch/arm/mach-tegra/cache.c|  20 +++
arch/arm/mach-tegra/cpu.c  |  16 ++---
arch/arm/mach-tegra/cpu.h  |   6 --
arch/arm/mach-tegra/tegra20/warmboot.c |  20 ++-
5 files changed, 51 insertions(+), 117 deletions(-)



What exactly is missing to prevent multi-arch support?


In a word: everything:-)

Pretty much all decisions in core architecture code, core Tegra code,
drivers, and even board files are currently made at compile time. For
example, consider drivers where the register layouts are different between
different SoCs; not just new fields added, but existing fields moved to
different offsets. Right now, we handle this by changing the register struct
definition at compile time. To support multiple chips, we'd have to either
(a) link in n copies of the driver, one per register layout, or (b) rework
the driver to use #defines and runtime calculations for register offsets,
like the Linux kernel drivers do. Tegra USB is one example. The pinmux and
clock drivers have a significantly different sets of pins/clocks/resets/...
per SoC, and enums/tables describing those sets are currently configured at
compile time. Some PMIC constants (e.g. vdd_cpu voltage) are configured at
compile-time, and even differ per board.


I wonder how far we would get by converting clock, pinctrl, reset to
driver model drivers?


Well, I expect we'll find out soon. The next SoC has radically different
clock/reset mechanisms, so we'll need to switch to standardized APIs for
clock/reset on Tegra to isolate drivers from those differences, and I
imagine that conversion would also involve conversion to DM since any
standard APIs probably assume use of DM. I haven't investigated this in
detail yet though.


That sounds like a good move.


I'm not sure if you still object to this patch for now, or would be 
happy giving it an ack?

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

Re: [U-Boot] [RFC PATCH] dm: ensure device names are unique

[Stephen Warren]

On 04/29/2016 07:23 AM, Simon Glass wrote:

Hi Stephen,

On 28 April 2016 at 09:55, Stephen Warren  wrote:

On 04/27/2016 10:50 PM, Simon Glass wrote:


Hi Stephen,

On 26 April 2016 at 15:30, Stephen Warren wrote:
  > It is possible for HW to contain multiple instances of the same device.
In
  > this case, the name passed to device_bind() may not be unique across
all
  > devices within its uclass. One example is a system with multiple
identical
  > PCI Ethernet devices. Another might be a system with multiple identical
  > I2C GPIO expanders, each connected to a separate I2C bus, yet using the
  > same I2C address on that bus and hence having the same DT node name.
  >
  > Enhance the code to detect this situation, and append a sequence
number so
  > the device name to ensure uniqueness.
  >
  > Signed-off-by: Stephen Warren >

I would rather that the caller handles this. But failing this perhaps a
new function that does it? Is this for the Ethernet use case?



Wouldn't all callers of this function simply call the new function? I'm not
aware of any case where the code to avoid duplicate names would not be
desired.

I hit this for the Ethernet case, but I believe it applies to any type of
device at all; see another possible trigger case in the commit description.


This does not happen with devices from the device tree. It only
happens with auto-probed devices. Your I2C GPIO example is odd but I'd
rather solve that by using the device tree node name.


DT itself imposes no such rule; node names must be unique only within 
their parent node but there's no restriction on identical node names 
appearing in different parts of the tree.


If U-Boot imposes that rule on DT, then there's no way in general that 
we can guarantee U-Boot will be able to use standard DTs (i.e. identical 
to those used by Linux or any other OS) for any platform; it'd be 
another change someone would need to make to transform a DT to be 
"U-Boot compatible", which rather reduces a potential benefit of DT for 
U-Boot; being able to just drop a DT in and have it work.


It would be possible for U-Boot to decouple its internal device name 
from the DT node name. In which case, your statement would work. 
However, I don't think that's the case at the moment, and in fact it's 
effectively what this patch is doing, although admittedly there are 
other ways of doing this.

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

Re: [U-Boot] [PATCH 2/2 v4] m68k: add DM model serial driver

[Simon Glass]

On 29 April 2016 at 08:02, Simon Glass  wrote:
> On 27 April 2016 at 13:51, Angelo Dureghello  wrote:
>> Boards can now use DM serial driver, or still legacy mcf uart
>> driver version.
>>
>> Signed-off-by: Angelo Dureghello 
>> ---
>> Changes for v2:
>>- fixed commit message
>>- added white lines in cmd/mmc.c
>>- fixed help in cmd/mmc.c
>> Changes for v3:
>>- fixed command output to a single printf
>>- fixed return codes
>>- fixed macroes with parenthesis around parameter
>> Changes for v4:
>>- fix missing include/dm/platform_data/serial_coldfire.h
>> ---
>>  drivers/serial/mcfuart.c   | 188 
>> ++---
>>  include/dm/platform_data/serial_coldfire.h |  23 
>>  2 files changed, 167 insertions(+), 44 deletions(-)
>>  create mode 100644 include/dm/platform_data/serial_coldfire.h
>
> Acked-by: Simon Glass 

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

Re: [U-Boot] [PATCH 1/2 v4] m68k: add malloc memory for early malloc

[Simon Glass]

On 29 April 2016 at 08:02, Simon Glass  wrote:
> On 27 April 2016 at 13:50, Angelo Dureghello  wrote:
>> To use serial uclass and DM, CONFIG_SYS_MALLOC_F must be used.
>> So CONFIG_SYS_GENERIC_GLOBAL_DATA has been undefined and
>> call to board_init_f_mem() is added for all cpu's.
>>
>> Signed-off-by: Angelo Dureghello 
>> ---
>> Changes for v2:
>>- none
>> Changes for v3:
>>- fix start.S using new board_init_f_alloc_reserve
>> Changes for v4:
>>- fix start.S for correct passage of boot_args to board_init_f
>> ---
>>  arch/m68k/cpu/mcf5227x/start.S   | 25 -
>>  arch/m68k/cpu/mcf523x/start.S| 27 ++-
>>  arch/m68k/cpu/mcf52x2/start.S| 26 ++
>>  arch/m68k/cpu/mcf530x/cpu_init.c |  2 +-
>>  arch/m68k/cpu/mcf530x/start.S| 25 ++---
>>  arch/m68k/cpu/mcf532x/start.S| 27 ++-
>>  arch/m68k/cpu/mcf5445x/start.S   | 27 ++-
>>  arch/m68k/cpu/mcf547x_8x/start.S | 25 -
>>  arch/m68k/include/asm/config.h   |  2 --
>>  9 files changed, 147 insertions(+), 39 deletions(-)
>
> Acked-by: Simon Glass 

Applied to u-boot-dm, thanks!

(Note, this is now too late for the release)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] omap3: Reduce logic/overo SPL max image size

[Adam Ford]

On Wed, Apr 27, 2016 at 5:46 PM, Tom Rini  wrote:
> While the OMAP3 has 64KiB of SRAM, per the TRM the download area is only
> from 0x4020 to 0x4020F000 and exceeding that will cause failure to
> boot.  Further, we need to make sure that we don't run into
> SRAM_SCRATCH_SPACE_ADDR as once SPL is running we will write values
> there and would corrupt our running image.
>
> Cc: Adam Ford 
> Cc: Steve Sakoman 
> Signed-off-by: Tom Rini 

Tested-By: Adam Ford 

> ---
>  include/configs/omap3_logic.h | 2 +-
>  include/configs/omap3_overo.h | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/include/configs/omap3_logic.h b/include/configs/omap3_logic.h
> index 055dcb7..6c79643 100644
> --- a/include/configs/omap3_logic.h
> +++ b/include/configs/omap3_logic.h
> @@ -34,7 +34,7 @@
>  #undef CONFIG_SPL_TEXT_BASE
>  #undef CONFIG_SPL_MAX_SIZE
>  #define CONFIG_SPL_TEXT_BASE   0x4020
> -#define CONFIG_SPL_MAX_SIZE(64 * 1024)
> +#define CONFIG_SPL_MAX_SIZE(SRAM_SCRATCH_SPACE_ADDR - 
> CONFIG_SPL_TEXT_BASE)
>
>  /* Display CPU and Board information */
>
> diff --git a/include/configs/omap3_overo.h b/include/configs/omap3_overo.h
> index c066eae5..fbd0c2a 100644
> --- a/include/configs/omap3_overo.h
> +++ b/include/configs/omap3_overo.h
> @@ -12,9 +12,9 @@
>
>  #include 
>  #undef CONFIG_SPL_MAX_SIZE
> -#define CONFIG_SPL_MAX_SIZE(64*1024)
>  #undef CONFIG_SPL_TEXT_BASE
>  #define CONFIG_SPL_TEXT_BASE   0x4020
> +#define CONFIG_SPL_MAX_SIZE(SRAM_SCRATCH_SPACE_ADDR - 
> CONFIG_SPL_TEXT_BASE)
>
>  #define CONFIG_BCH
>
> --
> 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] spl_mmc: allow to load raw image

[Adam Ford]

On Tue, Mar 15, 2016 at 10:10 PM, Masahiro Yamada
 wrote:
> The function spl_parse_image_header() falls back to a raw image
> if the U-Boot header is missing and CONFIG_SPL_PANIC_ON_RAW_IMAGE
> is undefined.  While, mmc_load_image_raw_sector() only accepts a
> U-Boot legacy image or an FIT image, preventing us from loading a
> raw image.
>
> Signed-off-by: Masahiro Yamada 
> ---

I know it's been pushed to the trunk already, but I think we have an
issue with at least one OMAP3 board.


>
> Changes in v2:
>   - rebase on commit 41bccb814285 and rephrase git-log according to it
>
>  common/spl/spl_mmc.c | 18 --
>  1 file changed, 4 insertions(+), 14 deletions(-)
>
> diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
> index c0e76be..7d3bfc6 100644
> --- a/common/spl/spl_mmc.c
> +++ b/common/spl/spl_mmc.c
> @@ -41,7 +41,6 @@ static int mmc_load_legacy(struct mmc *mmc, ulong sector,
> return 0;
>  }
>
> -#ifdef CONFIG_SPL_LOAD_FIT
>  static ulong h_spl_load_read(struct spl_load_info *load, ulong sector,
>  ulong count, void *buf)
>  {
> @@ -49,7 +48,6 @@ static ulong h_spl_load_read(struct spl_load_info *load, 
> ulong sector,
>
> return mmc->block_dev.block_read(>block_dev, sector, count, buf);
>  }
> -#endif
>
>  static int mmc_load_image_raw_sector(struct mmc *mmc, unsigned long sector)
>  {
> @@ -68,12 +66,8 @@ static int mmc_load_image_raw_sector(struct mmc *mmc, 
> unsigned long sector)
> goto end;
> }
>
> -   switch (image_get_magic(header)) {
> -   case IH_MAGIC:
> -   ret = mmc_load_legacy(mmc, sector, header);
> -   break;
> -#ifdef CONFIG_SPL_LOAD_FIT
> -   case FDT_MAGIC: {
> +   if (IS_ENABLED(CONFIG_SPL_LOAD_FIT) &&
> +   image_get_magic(header) == FDT_MAGIC) {
> struct spl_load_info load;
>
> debug("Found FIT\n");
> @@ -82,12 +76,8 @@ static int mmc_load_image_raw_sector(struct mmc *mmc, 
> unsigned long sector)
> load.bl_len = mmc->read_bl_len;
> load.read = h_spl_load_read;
> ret = spl_load_simple_fit(, sector, header);
> -   break;
> -   }
> -#endif
> -   default:
> -   puts("bad magic\n");
> -   return -1;
> +   } else {

The following line makes my omap3 board hang.

> +   ret = mmc_load_legacy(mmc, sector, header);

However if we use "return -1" the board loads u-boot.img properly on
the omap3logic board.


> }
>
>  end:
> --
> 1.9.1
>
> ___
> 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] spl_mmc: allow to load raw image

[Adam Ford]

Does anyone with an OMAP3 board have any issues with this patch?  I
will admit I haven't stayed on top of stuff due to moving, and other
issues at home, but I pulled down the master to reviews some on
related stuff, and found that master doesn't boot.  I used git bisect
this morning and it narrowed down a problem with booting to this
patch.

With the patch, I get:

U-Boot SPL 2016.03-00378-g4976f48 (Apr 29 2016 - 09:25:27)
Trying to boot from MMC
(hang)


Without the patch, I get:

U-Boot SPL 2016.03-00377-g73b5b27 (Apr 29 2016 - 09:26:30)
Trying to boot from MMC
bad magic
bad magic
reading args
spl_load_image_fat_os: error reading image args, err - -1
reading u-boot.img
reading u-boot.img

(U-boot loads)

On Thu, Mar 17, 2016 at 11:12 AM, Tom Rini  wrote:
> On Fri, Mar 18, 2016 at 01:07:47AM +0900, Masahiro Yamada wrote:
>> Hi Tom,
>>
>> 2016-03-17 11:04 GMT+09:00 Tom Rini :
>> > On Mon, Feb 29, 2016 at 08:31:57PM +0900, Masahiro Yamada wrote:
>> >
>> >> The function spl_parse_image_header() falls back to a raw image
>> >> if the U-Boot header is missing and CONFIG_SPL_PANIC_ON_RAW_IMAGE
>> >> is undefined.  While, the bad magic checking here makes the
>> >> spl_parse_image_header() unreachable in case of the missing header.
>> >>
>> >> Signed-off-by: Masahiro Yamada 
>> >> Reviewed-by: Tom Rini 
>> >
>> > Applied to u-boot/master, thanks!
>>
>> I guess this is false.
>>
>> This is v1 that you said does not work as is.
>
> Yup, oops, forgot to delete it from my local bundle.
>
> --
> Tom
>
> ___
> 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 38/60] ARM: tegra: remove tegra_get_chip()

[Simon Glass]

Hi Stephen,

On 27 April 2016 at 10:13, Stephen Warren  wrote:
> On 04/27/2016 08:50 AM, Simon Glass wrote:
>>
>> Hi Stephen,
>>
>> On 25 April 2016 at 13:25, Stephen Warren  wrote:
>>>
>>> On 04/23/2016 11:14 AM, Simon Glass wrote:


 Hi Stephen,

 On 19 April 2016 at 14:59, Stephen Warren  wrote:
>
>
> From: Stephen Warren 
>
> U-Boot is compiled for a single board, which in turn uses a specific
> SoC.
> There's no need to make runtime decisions based on SoC ID. While
> there's
> certainly an argument for making the code support different SoCs at
> run-time, the Tegra code is so far from that possible ideal that the
> existing runtime code is an anomaly. If this changes in the future, all
> runtime decisions should likely be based on DT anyway.
>
> Signed-off-by: Stephen Warren 
> ---
>arch/arm/mach-tegra/ap.c   | 106
> ++---
>arch/arm/mach-tegra/cache.c|  20 +++
>arch/arm/mach-tegra/cpu.c  |  16 ++---
>arch/arm/mach-tegra/cpu.h  |   6 --
>arch/arm/mach-tegra/tegra20/warmboot.c |  20 ++-
>5 files changed, 51 insertions(+), 117 deletions(-)



 What exactly is missing to prevent multi-arch support?
>>>
>>>
>>> In a word: everything:-)
>>>
>>> Pretty much all decisions in core architecture code, core Tegra code,
>>> drivers, and even board files are currently made at compile time. For
>>> example, consider drivers where the register layouts are different
>>> between
>>> different SoCs; not just new fields added, but existing fields moved to
>>> different offsets. Right now, we handle this by changing the register
>>> struct
>>> definition at compile time. To support multiple chips, we'd have to
>>> either
>>> (a) link in n copies of the driver, one per register layout, or (b)
>>> rework
>>> the driver to use #defines and runtime calculations for register offsets,
>>> like the Linux kernel drivers do. Tegra USB is one example. The pinmux
>>> and
>>> clock drivers have a significantly different sets of
>>> pins/clocks/resets/...
>>> per SoC, and enums/tables describing those sets are currently configured
>>> at
>>> compile time. Some PMIC constants (e.g. vdd_cpu voltage) are configured
>>> at
>>> compile-time, and even differ per board.
>>
>>
>> I wonder how far we would get by converting clock, pinctrl, reset to
>> driver model drivers?
>
>
> Well, I expect we'll find out soon. The next SoC has radically different
> clock/reset mechanisms, so we'll need to switch to standardized APIs for
> clock/reset on Tegra to isolate drivers from those differences, and I
> imagine that conversion would also involve conversion to DM since any
> standard APIs probably assume use of DM. I haven't investigated this in
> detail yet though.

That sounds like a good move.

>
 Shouldn't we head towards that rather than making it harder?
>>>
>>>
>>> I don't see any need for that, no.
>>>
>>> U-Boot is built for a specific board (or in some cases a set of extremely
>>> closely related set of boards, such as the RPI A/B/A+/B+). There's no
>>> need
>>> to determine almost anything at run-time since almost all information is
>>> known at compile time, with exceptions such as standardized enumerable
>>> buses
>>> such as USB, PCIe. If we support multiple HW in a single binary, it gets
>>> bloated with code that simply isn't going to be used, since all the extra
>>> code is either for a platform that the build won't be installed on (e.g.
>>> clock/pinmux tables), or is overhead to add runtime detection of which
>>> block
>>> of code to use, which simply isn't needed in the current model.
>>
>>
>> It's not so much that. Presumably a build for a particular board would
>> not include support for and SoC it doesn't have. But it is still
>> useful to build the code. For example it would be nice to have an
>> overall Tegra build that enables all SoCs to avoid building every
>> board.
>>
>> So it is a serious question. I suspect the main impediment may be
>> moving the clock and other core stuff to driver model.
>
>
> Yes, everything is a bit too tightly coupled at the moment, and in many
> cases each SoC-specific implementation exposes the same global symbols which
> clients use. DM or similar conversions may well solve a lot of this.

With a suitable API (even it if is pretty basic) the coupling can
often go away. The current driver-model pinctrl/clock APIs are pretty
simple, but they are effective in this regard for the SoCs I've tried.

>
>>> In my opinion, firmware/bootloaders run on a single specific board,
>>> whereas
>>> full-featured operating systems support multiple systems.
>>
>>
>> Except when the boards are pretty similar. Also, doesn't barebox have
>> only one build for Tegra?
>
>
> I 

Re: [U-Boot] [PATCH 55/60] i2c: tegra: move pinmux setup to board files

[Simon Glass]

Hi Stephen,

On 27 April 2016 at 11:16, Stephen Warren  wrote:
> On 04/27/2016 10:58 AM, Simon Glass wrote:
>>
>> Hi Stephen,
>>
>> On 27 April 2016 at 10:24, Stephen Warren  wrote:
>>>
>>> On 04/27/2016 09:12 AM, Simon Glass wrote:


 Hi Stephen,

 On 19 April 2016 at 14:59, Stephen Warren  wrote:
>
>
> From: Stephen Warren 
>
> Remove funcmux calls from the Tegra I2C driver. Knowledge of pinmux
> setup must come from either board files or DT; it should not be
> embedded
> into board-agnostic driver code. The DT pinmux bindings do not allow
> drivers to derive funcmux-style information, since the DT bindings are
> pin-based whereas funcmux is controller-based, so there's no good way
> to
> call the existing funcmux APIs from drivers. Converting drivers to use
> a
> new (as yet non-existent in U-Boot) API that pulls pinmux information
> from
> DT isn't useful for Tegra, since Tegra's DT files don't contain any
> per-device pinmux tables, so this would simply be extra code that has
> no
> effect; doesn't actually set up the pinmux. We are left with moving the
> pinmux setup functionality into board files. In theory the board files
> could be converted later to use DT, but that would be a separate
> change.
>
> Signed-off-by: Stephen Warren 
> ---
>board/avionic-design/common/tamonten.c  |  5 +
>board/nvidia/seaboard/seaboard.c|  3 +++
>board/nvidia/whistler/whistler.c|  1 +
>board/toradex/colibri_t20/colibri_t20.c |  3 +++
>drivers/i2c/tegra_i2c.c | 19 ---
>5 files changed, 12 insertions(+), 19 deletions(-)



 This should use driver model, which handles pinmux automatically if
 you have a pinctrl driver.
>>>
>>>
>>>
>>> Can you define "automatic"? I don't understand exactly which benefit
>>> you're
>>> describing there.
>>
>>
>> When you probe a device, its pinmux is set up automatically, so the
>> explicit funcmux calls can go away.
>
>
> So the device here would be the pin controller device itself, not individual
> I2C/SPI/SD/... devices.
>
> That's because the Tegra HW does not support[1] dynamic or partial pinmux
> configuration. As such, we need to program the entire pinmux at once early
> during boot, not piece-by-piece as the individual U-Boot devices that use
> individual pins are probed. This is why for example the kernel DT contains a
> single pinmux table that the pin controller driver sets up at boot (with
> identical configuration to what U-Boot sets up, so it's a no-op), rather
> than splitting it into per-device chunks.

Is this the big table that I see in device tree files?

pinmux@0,7868 {
pinctrl-names = "default";
pinctrl-0 = <_default>;

pinmux_default: common {
clk_32k_out_pa0 {
nvidia,pins = "clk_32k_out_pa0";
nvidia,pull = ;
nvidia,tristate = ;
nvidia,enable-input = ;
};
...

>
> As such, there isn't any need for, say, an I2C device probe to call into
> pinmux at all; the pinmux would already have been set up entirely during
> early boot, and hence no I2C-specific actions would be needed later.

OK. As you know I don't like this monolithic pinmux stuff - at least
in early boot it is useful to enable (say) just the UART. Anyway I
still think a driver is useful and will provide a better base for the
future.

>
> So I'm not sure what benefit conversion to DM pinctrl has here. Sure it
> means things get set up the same way as with any other pinctrl device or
> SoC, but this is early SoC-specific configuration, without any interaction
> with common or driver code besides being implemented via some standard
> core->board callbacks/hooks. It seems reasonable to just program the pinmux
> directly using SoC-specific APIs rather than having to add a layer of
> abstraction on top of it just so we can route it through DM. In other words,
> what's already done by this patch series.
>
> Besides, I believe the programming happens before a DM pinctrl device would
> be ready, doesn't it, given it happens from tegra_board_early_init_f()? Or,
> would we be able to fully probe a DM device at that point? The UART console
> setup is even earlier, in SPL pre-T210, where I don't think we even have DM
> enabled.

DM is enabled pretty early, before board_early_init_f(). But if you
hit a problem we can look at it. There is no point in setting up
pinmux before driver model, since it is the drivers that use it.

Worst case, how about creating a pinctrl driver where everything
happens in the probe() method? Ideally you could do the minimum
necessary before relocation, and then the full table load afterwards.

>
> [1] Yes, the HW registers can in practice be programmed bit-by-bit, simply
> because there are a number of registers and the SoC doesn't have a way to
> 

Re: [U-Boot] [PATCH] fdt: fix dev_get_addr_name node offset

[Simon Glass]

On 28 April 2016 at 16:04, Stephen Warren  wrote:
> From: Stephen Warren 
>
> Use the device's own DT offset, not the device's parent's.
>
> Fixes: 43c4d44e3330 ("fdt: implement dev_get_addr_name()")
> Signed-off-by: Stephen Warren 
> ---
>  drivers/core/device.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

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

Re: [U-Boot] [PATCH 1/2 v4] m68k: add malloc memory for early malloc

[Simon Glass]

On 27 April 2016 at 13:50, Angelo Dureghello  wrote:
> To use serial uclass and DM, CONFIG_SYS_MALLOC_F must be used.
> So CONFIG_SYS_GENERIC_GLOBAL_DATA has been undefined and
> call to board_init_f_mem() is added for all cpu's.
>
> Signed-off-by: Angelo Dureghello 
> ---
> Changes for v2:
>- none
> Changes for v3:
>- fix start.S using new board_init_f_alloc_reserve
> Changes for v4:
>- fix start.S for correct passage of boot_args to board_init_f
> ---
>  arch/m68k/cpu/mcf5227x/start.S   | 25 -
>  arch/m68k/cpu/mcf523x/start.S| 27 ++-
>  arch/m68k/cpu/mcf52x2/start.S| 26 ++
>  arch/m68k/cpu/mcf530x/cpu_init.c |  2 +-
>  arch/m68k/cpu/mcf530x/start.S| 25 ++---
>  arch/m68k/cpu/mcf532x/start.S| 27 ++-
>  arch/m68k/cpu/mcf5445x/start.S   | 27 ++-
>  arch/m68k/cpu/mcf547x_8x/start.S | 25 -
>  arch/m68k/include/asm/config.h   |  2 --
>  9 files changed, 147 insertions(+), 39 deletions(-)

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

Re: [U-Boot] [RFC PATCH] gpio: add Tegra186 GPIO driver

[Simon Glass]

Hi Stephen,

On 27 April 2016 at 10:01, Stephen Warren  wrote:
> On 04/27/2016 09:12 AM, Simon Glass wrote:
>>
>> Hi Stephen,
>>
>> On 20 April 2016 at 17:28, Stephen Warren  wrote:
>>>
>>> From: Stephen Warren 
>>>
>>> Tegra186's GPIO controller register layout is significantly different
>>> from
>>> previous chips, so add a new driver for it. In fact, there are two
>>> different GPIO controllers in Tegra186 that share a similar register
>>> layout, but very different port mapping. This driver covers both.
>>>
>>> The DT binding is already present in the Linux kernel (FIXME: Validate
>>> this when submitting).
>>> FIXME: Add DT binding file to this commit.
>>>
>>> Signed-off-by: Stephen Warren 
>>> ---
>>>   arch/arm/mach-tegra/Kconfig  |   3 +
>>>   drivers/gpio/Kconfig |   9 +
>>>   drivers/gpio/Makefile|   1 +
>>>   drivers/gpio/tegra186_gpio.c | 271
>>> +++
>>>   drivers/gpio/tegra186_gpio_priv.h|  61 +++
>>>   include/dt-bindings/gpio/tegra186-gpio.h |  56 +++
>>>   6 files changed, 401 insertions(+)
>>>   create mode 100644 drivers/gpio/tegra186_gpio.c
>>>   create mode 100644 drivers/gpio/tegra186_gpio_priv.h
>>>   create mode 100644 include/dt-bindings/gpio/tegra186-gpio.h
>>
>>
>> Reviewed-by: Simon Glass 
>>
>> My only comment is that tegra186_gpio_get_value() should return 0 or 1.
>
>
> Thanks, fixed locally. As you may have noticed, I actually sent that patch
> out accidentally when I meant to send something else. Still, the remaining
> work is in the binding approval and addition to this patch, not the code you
> reviewed which I don't expect will change:-)
>
>> I haven't seen the device tree, but presumably it is just a single node?
>
>
> There's one DT node per top-level controller instance. The patch I sent for
> that is at:
>
> https://patchwork.ozlabs.org/patch/609516/
> [V2] ARM: tegra: add DT binding for Tegra186 GPIO controllers
>

Thanks, looks good.

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

Re: [U-Boot] [PATCH 2/2 v4] m68k: add DM model serial driver

[Simon Glass]

On 27 April 2016 at 13:51, Angelo Dureghello  wrote:
> Boards can now use DM serial driver, or still legacy mcf uart
> driver version.
>
> Signed-off-by: Angelo Dureghello 
> ---
> Changes for v2:
>- fixed commit message
>- added white lines in cmd/mmc.c
>- fixed help in cmd/mmc.c
> Changes for v3:
>- fixed command output to a single printf
>- fixed return codes
>- fixed macroes with parenthesis around parameter
> Changes for v4:
>- fix missing include/dm/platform_data/serial_coldfire.h
> ---
>  drivers/serial/mcfuart.c   | 188 
> ++---
>  include/dm/platform_data/serial_coldfire.h |  23 
>  2 files changed, 167 insertions(+), 44 deletions(-)
>  create mode 100644 include/dm/platform_data/serial_coldfire.h

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

Re: [U-Boot] test/py - test OS boot

[Michal Simek]

Hi Stephen,

2016-04-21 19:43 GMT+02:00 Stephen Warren :

> On 04/18/2016 07:46 AM, Michal Simek wrote:
>
>> Hi Stephen and Simon,
>>
>> have you thought how to use test/py for testing OS boot?
>> I am not experienced with python to quickly hack it myself but in
>> general I think we should support boot till OS (to test OS handoff,
>> legacy, fit formats, bootm subcommands, go, etc) till certain point and
>> then do reset and if that pattern is found test should pass.
>> I was trying to find out a way how to perform reset command and let test
>> pass.
>> Is there any way how to do it?
>>
>
> I think you'd want to do something like the following in the test:
>
> try:
> orig_to = u_boot_console.p.timeout
> # wait_for_prompt=False makes the core code not wait for the U-Boot
> # prompt code to be seen, since it won't be on a successful kernel
> # boot
> u_boot_console.run_command('run bootcmd', wait_for_prompt=False)
> u_boot_console.p.timeout = something_long
> # You might want to expand wait_for() with options to add extra bad
> # patterns which immediately indicate a failed boot, or add a new
> # "with object" function u_boot_console.enable_check() that can
> # cause extra patterns like the U-Boot console prompt, U-Boot boot
> # error messages, kernel boot error messages, etc. to fail the
> # wait_for().
> u_boot_console.wait_for('login:')
> finally:
> u_boot_console.p.timeout = orig_to
> # This forces the console object to be shutdown, so any subsequent
> # test will reset the board back into U-Boot. We want to force this
> # no matter whether the kernel boot passed or failed.
> u_boot_console.drain_console()
> u_boot_console.cleanup_spawn()
>
> You should probably wrap the timeout manipulation into an automatic object
> that you can use with a "with" statement, similar to how
> u_boot_console_base.py's ConsoleDisableCheck class and disable_check()
> function work. That will isolate the logic a bit.
>
> Perhaps the structure of the above logic could be wrapped into a
> function/"with object":
>
> # Shorter variable name just for email wrapping
> c = u_boot_console
> with c.needs_target_restart_afterwards():
> c.run_command('run bootcmd', wait_for_prompt=False)
> with c.temporary_timeout(120):
> u_boot_console.wait_for('login:')
>
>

This is working nicely. We should add an option to setup timeout to
tftpboot command too
because some images for reading can be quite large.

Thanks,
Michal


-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC PATCH] dm: ensure device names are unique

[Simon Glass]

Hi Stephen,

On 28 April 2016 at 10:00, Stephen Warren  wrote:
>
> On 04/27/2016 10:42 PM, Joe Hershberger wrote:
>>
>> On Tue, Apr 26, 2016 at 4:30 PM, Stephen Warren  
>> wrote:
>>>
>>> From: Stephen Warren 
>>>
>>> It is possible for HW to contain multiple instances of the same device. In
>>> this case, the name passed to device_bind() may not be unique across all
>>> devices within its uclass. One example is a system with multiple identical
>>> PCI Ethernet devices. Another might be a system with multiple identical
>>> I2C GPIO expanders, each connected to a separate I2C bus, yet using the
>>> same I2C address on that bus and hence having the same DT node name.
>>>
>>> Enhance the code to detect this situation, and append a sequence number so
>>> the device name to ensure uniqueness.
>>>
>>> Signed-off-by: Stephen Warren 
>>> ---
>>> Some possible issues with this patch:
>>>
>>> 1) Doing this in bind() rather than probe() means dev->seq isn't
>>> available, so can't be used to generate the unique name. This process
>>> should be done during bind() rather than probe() though, since devices can
>>> be seen (e.g. by running "dm tree") before they're probed. Perhaps the
>>> uclass_resolve_seq() should be called by bind() not probe().
>>
>>
>> We (Simon and I) had discussion about this when I first added support
>> for eth devices. He convinced me the correct time for seq to be
>> evaluated is at probe time. I can dig through the mail history for
>> reasons if you're interested.
>
>
> That might be interesting. Right now, about the only thing I see moving the 
> evaluation from probe to bind would do is very marginally increase the amount 
> of work done in bind, which potentially might be skipped if a particular 
> Ethernet device was never probed. I would not expect this to make a 
> noticeable difference, especially since IIRC when the network is first used, 
> all the Ethernet devices are probed anyway, so this just moves work around?

There's a somewhat deep design issue there, but so far I feel that
having the numbering resolved when a device is probed works best. It
is very seldom useful until then. Device names don't really need to
match there sequence number.

>
>>> 2) uclass_find_device_by_name() needs to look up the uclass pointer again
>>> even though device_bind() already knows it.
>>
>>
>> Maybe we could add a parameter to provide the pointer and if it's
>> NULL, then it gets looked up. Might be a bit noisy change, though. Is
>> that optimization very valuable?
>
>
> I don't imagine there are too many uclasses, so it's probably not going to 
> save too much time. Still, Simon has in the past objected to code that parses 
> DT scanning the DT to find parent offsets, and this feels like exactly the 
> same kind of thing. I'm not personally concerned about it; simply pointing it 
> out in case anyone wanted that to be addressed.
>
>>> 3) Iterating over the list to find the count of devices in the uclass is a
>>> bit annoying. Should the uclass maintain this count so it doesn't need to
>>> be re-calculated each time?
>>
>>
>> These lists aren't long, right? It seems like the optimization to
>> store the value is only helpful if the lists could be expected to be
>> long, or the size is looked up many times.

There are essentially no optimisations in driver model at present. So
far the benefit hasn't shown itself. Perhaps it won't in a boot
loader...

>
>
> Yes, I don't imagine this would be a particular issue in practice.

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

Re: [U-Boot] [RFC PATCH] dm: ensure device names are unique

[Simon Glass]

Hi Stephen,

On 28 April 2016 at 09:55, Stephen Warren  wrote:
> On 04/27/2016 10:50 PM, Simon Glass wrote:
>>
>> Hi Stephen,
>>
>> On 26 April 2016 at 15:30, Stephen Warren wrote:
>>  > It is possible for HW to contain multiple instances of the same device.
>> In
>>  > this case, the name passed to device_bind() may not be unique across
>> all
>>  > devices within its uclass. One example is a system with multiple
>> identical
>>  > PCI Ethernet devices. Another might be a system with multiple identical
>>  > I2C GPIO expanders, each connected to a separate I2C bus, yet using the
>>  > same I2C address on that bus and hence having the same DT node name.
>>  >
>>  > Enhance the code to detect this situation, and append a sequence
>> number so
>>  > the device name to ensure uniqueness.
>>  >
>>  > Signed-off-by: Stephen Warren >
>>
>> I would rather that the caller handles this. But failing this perhaps a
>> new function that does it? Is this for the Ethernet use case?
>
>
> Wouldn't all callers of this function simply call the new function? I'm not
> aware of any case where the code to avoid duplicate names would not be
> desired.
>
> I hit this for the Ethernet case, but I believe it applies to any type of
> device at all; see another possible trigger case in the commit description.

This does not happen with devices from the device tree. It only
happens with auto-probed devices. Your I2C GPIO example is odd but I'd
rather solve that by using the device tree node name.

I'd like to avoid putting things in the base code that we don't need
early on in boot. How about a helper function for those subsystems
that create devices outside the device tree system?

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

[U-Boot] [PATCH 3/3] crypto/fsl: add support for multiple SEC engines initialization

[Alex Porosanu]

From: Alex Porosanu 

For SoCs that contain multiple SEC engines, each of them needs
to be initialized (by means of initializing among others the
random number generator).

Signed-off-by: Alex Porosanu 
---
 arch/powerpc/cpu/mpc85xx/cpu_init.c |   9 ++
 drivers/crypto/fsl/jr.c | 271 +---
 drivers/crypto/fsl/jr.h |   3 +
 include/fsl_sec.h   |   6 +-
 4 files changed, 172 insertions(+), 117 deletions(-)

diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init.c 
b/arch/powerpc/cpu/mpc85xx/cpu_init.c
index f168375..61f5639 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu_init.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu_init.c
@@ -958,6 +958,15 @@ int cpu_init_r(void)
 
 #ifdef CONFIG_FSL_CAAM
sec_init();
+
+#if defined(CONFIG_PPC_C29X)
+   if ((SVR_SOC_VER(svr) == SVR_C292) ||
+   (SVR_SOC_VER(svr) == SVR_C293))
+   sec_init_idx(1);
+
+   if (SVR_SOC_VER(svr) == SVR_C293)
+   sec_init_idx(2);
+#endif
 #endif
 
 #if defined(CONFIG_FSL_SATA_V2) && defined(CONFIG_FSL_SATA_ERRATUM_A001)
diff --git a/drivers/crypto/fsl/jr.c b/drivers/crypto/fsl/jr.c
index 8bc517d..510fa4e 100644
--- a/drivers/crypto/fsl/jr.c
+++ b/drivers/crypto/fsl/jr.c
@@ -19,11 +19,26 @@
 #define CIRC_CNT(head, tail, size) (((head) - (tail)) & (size - 1))
 #define CIRC_SPACE(head, tail, size)   CIRC_CNT((tail), (head) + 1, (size))
 
-struct jobring jr;
+uint32_t sec_offset[CONFIG_SYS_FSL_MAX_NUM_OF_SEC] = {
+   0,
+#if defined(CONFIG_PPC_C29X)
+   CONFIG_SYS_FSL_SEC_IDX_OFFSET,
+   2 * CONFIG_SYS_FSL_SEC_IDX_OFFSET
+#endif
+};
+
+#define SEC_ADDR(idx)  \
+   ((CONFIG_SYS_FSL_SEC_ADDR + sec_offset[idx]))
+
+#define SEC_JR0_ADDR(idx)  \
+   (SEC_ADDR(idx) +\
+(CONFIG_SYS_FSL_JR0_OFFSET - CONFIG_SYS_FSL_SEC_OFFSET))
+
+struct jobring jr0[CONFIG_SYS_FSL_MAX_NUM_OF_SEC];
 
-static inline void start_jr0(void)
+static inline void start_jr0(uint8_t sec_idx)
 {
-   ccsr_sec_t *sec = (void *)CONFIG_SYS_FSL_SEC_ADDR;
+   ccsr_sec_t *sec = (void *)SEC_ADDR(sec_idx);
u32 ctpr_ms = sec_in32(>ctpr_ms);
u32 scfgr = sec_in32(>scfgr);
 
@@ -42,15 +57,15 @@ static inline void start_jr0(void)
}
 }
 
-static inline void jr_reset_liodn(void)
+static inline void jr_reset_liodn(uint8_t sec_idx)
 {
-   ccsr_sec_t *sec = (void *)CONFIG_SYS_FSL_SEC_ADDR;
+   ccsr_sec_t *sec = (void *)SEC_ADDR(sec_idx);
sec_out32(>jrliodnr[0].ls, 0);
 }
 
-static inline void jr_disable_irq(void)
+static inline void jr_disable_irq(uint8_t sec_idx)
 {
-   struct jr_regs *regs = (struct jr_regs *)CONFIG_SYS_FSL_JR0_ADDR;
+   struct jr_regs *regs = (struct jr_regs *)SEC_JR0_ADDR(sec_idx);
uint32_t jrcfg = sec_in32(>jrcfg1);
 
jrcfg = jrcfg | JR_INTMASK;
@@ -58,11 +73,12 @@ static inline void jr_disable_irq(void)
sec_out32(>jrcfg1, jrcfg);
 }
 
-static void jr_initregs(void)
+static void jr_initregs(uint8_t sec_idx)
 {
-   struct jr_regs *regs = (struct jr_regs *)CONFIG_SYS_FSL_JR0_ADDR;
-   phys_addr_t ip_base = virt_to_phys((void *)jr.input_ring);
-   phys_addr_t op_base = virt_to_phys((void *)jr.output_ring);
+   struct jr_regs *regs = (struct jr_regs *)SEC_JR0_ADDR(sec_idx);
+   struct jobring *jr = [sec_idx];
+   phys_addr_t ip_base = virt_to_phys((void *)jr->input_ring);
+   phys_addr_t op_base = virt_to_phys((void *)jr->output_ring);
 
 #ifdef CONFIG_PHYS_64BIT
sec_out32(>irba_h, ip_base >> 32);
@@ -79,59 +95,63 @@ static void jr_initregs(void)
sec_out32(>ors, JR_SIZE);
sec_out32(>irs, JR_SIZE);
 
-   if (!jr.irq)
-   jr_disable_irq();
+   if (!jr->irq)
+   jr_disable_irq(sec_idx);
 }
 
-static int jr_init(void)
+static int jr_init(uint8_t sec_idx)
 {
-   memset(, 0, sizeof(struct jobring));
+   struct jobring *jr = [sec_idx];
 
-   jr.jq_id = DEFAULT_JR_ID;
-   jr.irq = DEFAULT_IRQ;
+   memset(jr, 0, sizeof(struct jobring));
+
+   jr->jq_id = DEFAULT_JR_ID;
+   jr->irq = DEFAULT_IRQ;
 
 #ifdef CONFIG_FSL_CORENET
-   jr.liodn = DEFAULT_JR_LIODN;
+   jr->liodn = DEFAULT_JR_LIODN;
 #endif
-   jr.size = JR_SIZE;
-   jr.input_ring = (dma_addr_t *)memalign(ARCH_DMA_MINALIGN,
+   jr->size = JR_SIZE;
+   jr->input_ring = (dma_addr_t *)memalign(ARCH_DMA_MINALIGN,
JR_SIZE * sizeof(dma_addr_t));
-   if (!jr.input_ring)
+   if (!jr->input_ring)
return -1;
 
-   jr.op_size = roundup(JR_SIZE * sizeof(struct op_ring),
-ARCH_DMA_MINALIGN);
-   jr.output_ring =
-   (struct op_ring *)memalign(ARCH_DMA_MINALIGN, jr.op_size);
-   if (!jr.output_ring)
+   jr->op_size = roundup(JR_SIZE * sizeof(struct op_ring),
+ ARCH_DMA_MINALIGN);
+   jr->output_ring =
+  

[U-Boot] [PATCH 1/3] arch/arm: add SEC JR0 offset

[Alex Porosanu]

From: Alex Porosanu 

Freescale PPC SoCs do not hard-code security engine's Job Ring 0
address, rather a define is used. This patch adds the same
functionality to the ARM based SoCs (i.e. LS1/LS2 and i.MX parts)

Signed-off-by: Alex Porosanu 
---
 arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h |  9 +++--
 arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h |  8 ++--
 arch/arm/include/asm/arch-ls102xa/config.h |  1 +
 arch/arm/include/asm/arch-mx6/imx-regs.h   |  9 +++--
 arch/arm/include/asm/arch-mx7/imx-regs.h   | 11 +++
 5 files changed, 28 insertions(+), 10 deletions(-)

diff --git a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h 
b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
index 0bad0c7..57b99d4 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
@@ -37,8 +37,6 @@
 #define CONFIG_SYS_PCIE1_ADDR  (CONFIG_SYS_IMMR + 0x240)
 #define CONFIG_SYS_PCIE2_ADDR  (CONFIG_SYS_IMMR + 0x250)
 #define CONFIG_SYS_PCIE3_ADDR  (CONFIG_SYS_IMMR + 0x260)
-#define CONFIG_SYS_FSL_SEC_ADDR(CONFIG_SYS_IMMR + 
0x70)
-#define CONFIG_SYS_FSL_JR0_ADDR(CONFIG_SYS_IMMR + 
0x71)
 #define CONFIG_SYS_SEC_MON_ADDR(CONFIG_SYS_IMMR + 
0xe9)
 #define CONFIG_SYS_SFP_ADDR(CONFIG_SYS_IMMR + 0xe80200)
 
@@ -157,6 +155,13 @@ struct sys_info {
 #define CONFIG_SYS_FSL_FM1_DTSEC1_ADDR \
(CONFIG_SYS_IMMR + CONFIG_SYS_FSL_FM1_DTSEC1_OFFSET)
 
+#define CONFIG_SYS_FSL_SEC_OFFSET  0x70ull
+#define CONFIG_SYS_FSL_JR0_OFFSET  0x71ull
+#define CONFIG_SYS_FSL_SEC_ADDR \
+   (CONFIG_SYS_IMMR + CONFIG_SYS_FSL_SEC_OFFSET)
+#define CONFIG_SYS_FSL_JR0_ADDR \
+   (CONFIG_SYS_IMMR + CONFIG_SYS_FSL_JR0_OFFSET)
+
 /* Device Configuration and Pin Control */
 struct ccsr_gur {
u32 porsr1; /* POR status 1 */
diff --git a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h 
b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
index 1d3b336..65b3357 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
@@ -77,8 +77,12 @@
 #define CONFIG_SYS_SFP_ADDR(CONFIG_SYS_IMMR + 0x00e80200)
 
 /* SEC */
-#define CONFIG_SYS_FSL_SEC_ADDR(CONFIG_SYS_IMMR + 0x0700)
-#define CONFIG_SYS_FSL_JR0_ADDR(CONFIG_SYS_IMMR + 0x0701)
+#define CONFIG_SYS_FSL_SEC_OFFSET  0x0700ull
+#define CONFIG_SYS_FSL_JR0_OFFSET  0x0701ull
+#define CONFIG_SYS_FSL_SEC_ADDR \
+   (CONFIG_SYS_IMMR + CONFIG_SYS_FSL_SEC_OFFSET)
+#define CONFIG_SYS_FSL_JR0_ADDR \
+   (CONFIG_SYS_IMMR + CONFIG_SYS_FSL_JR0_OFFSET)
 
 /* Security Monitor */
 #define CONFIG_SYS_SEC_MON_ADDR(CONFIG_SYS_IMMR + 0x00e9)
diff --git a/arch/arm/include/asm/arch-ls102xa/config.h 
b/arch/arm/include/asm/arch-ls102xa/config.h
index 267bd17..92f30e2 100644
--- a/arch/arm/include/asm/arch-ls102xa/config.h
+++ b/arch/arm/include/asm/arch-ls102xa/config.h
@@ -40,6 +40,7 @@
(CONFIG_SYS_IMMR + CONFIG_SYS_LS102XA_USB1_OFFSET)
 
 #define CONFIG_SYS_FSL_SEC_OFFSET  0x0070
+#define CONFIG_SYS_FSL_JR0_OFFSET  0x0071
 #define CONFIG_SYS_LS102XA_USB1_OFFSET 0x0760
 #define CONFIG_SYS_TSEC1_OFFSET0x01d1
 #define CONFIG_SYS_TSEC2_OFFSET0x01d5
diff --git a/arch/arm/include/asm/arch-mx6/imx-regs.h 
b/arch/arm/include/asm/arch-mx6/imx-regs.h
index 3ab04bf..ac37e4f 100644
--- a/arch/arm/include/asm/arch-mx6/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx6/imx-regs.h
@@ -227,8 +227,13 @@
 #define CAAM_BASE_ADDR  (ATZ2_BASE_ADDR)
 #define ARM_BASE_ADDR  (ATZ2_BASE_ADDR + 0x4)
 
-#define CONFIG_SYS_FSL_SEC_ADDR CAAM_BASE_ADDR
-#define CONFIG_SYS_FSL_JR0_ADDR (CAAM_BASE_ADDR + 0x1000)
+#define CONFIG_SYS_FSL_SEC_OFFSET   0
+#define CONFIG_SYS_FSL_SEC_ADDR (CAAM_BASE_ADDR + \
+CONFIG_SYS_FSL_SEC_OFFSET)
+#define CONFIG_SYS_FSL_JR0_OFFSET   0x1000
+#define CONFIG_SYS_FSL_JR0_ADDR (CAAM_BASE_ADDR + \
+CONFIG_SYS_FSL_JR0_OFFSET)
+#define CONFIG_SYS_FSL_MAX_NUM_OF_SEC  1
 
 #define USB_PL301_BASE_ADDR (AIPS2_OFF_BASE_ADDR + 0x)
 #define USB_BASE_ADDR   (AIPS2_OFF_BASE_ADDR + 0x4000)
diff --git a/arch/arm/include/asm/arch-mx7/imx-regs.h 
b/arch/arm/include/asm/arch-mx7/imx-regs.h
index a3106e7..74917f0 100644
--- a/arch/arm/include/asm/arch-mx7/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx7/imx-regs.h
@@ -218,10 +218,13 @@
 
 #define FEC_QUIRK_ENET_MAC
 #define SNVS_LPGPR 

[U-Boot] [PATCH 0/3] Multiple FSL Security Engine RNG instantation

[Alex Porosanu]

This series of patches add the neccesary support for allowing multi-SEC
SoCs, like the C292 & C293 to instantiate the respecting RNGs.

Alex Porosanu (3):
  arch/arm: add SEC JR0 offset
  arch/arm, arch/powerpc: add # of SEC engines on the SOC
  crypto/fsl: add support for multiple SEC engines initialization

 arch/arm/include/asm/arch-fsl-layerscape/config.h  |   2 +
 .../include/asm/arch-fsl-layerscape/immap_lsch2.h  |   9 +-
 .../include/asm/arch-fsl-layerscape/immap_lsch3.h  |   8 +-
 arch/arm/include/asm/arch-ls102xa/config.h |   2 +
 arch/arm/include/asm/arch-mx6/imx-regs.h   |   9 +-
 arch/arm/include/asm/arch-mx7/imx-regs.h   |  11 +-
 arch/powerpc/cpu/mpc85xx/cpu_init.c|   9 +
 arch/powerpc/include/asm/config_mpc85xx.h  |   6 +
 board/freescale/c29xpcie/c29xpcie.c|   2 +-
 drivers/crypto/fsl/jr.c| 271 -
 drivers/crypto/fsl/jr.h|   3 +
 include/fsl_sec.h  |   6 +-
 12 files changed, 210 insertions(+), 128 deletions(-)

-- 
1.9.3

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

[U-Boot] [PATCH 2/3] arch/arm, arch/powerpc: add # of SEC engines on the SOC

[Alex Porosanu]

From: Alex Porosanu 

Some SOCs, specifically the ones in the C29x familiy can have
multiple security engines. This patch adds a system configuration
define which indicates the maximum number of SEC engines that
can be found on a SoC.

Signed-off-by: Alex Porosanu 
---
 arch/arm/include/asm/arch-fsl-layerscape/config.h | 2 ++
 arch/arm/include/asm/arch-ls102xa/config.h| 1 +
 arch/powerpc/include/asm/config_mpc85xx.h | 6 ++
 board/freescale/c29xpcie/c29xpcie.c   | 2 +-
 4 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/arch-fsl-layerscape/config.h 
b/arch/arm/include/asm/arch-fsl-layerscape/config.h
index 10d17b2..5771b28 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/config.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/config.h
@@ -143,6 +143,7 @@
 #define CONFIG_ARM_ERRATA_829520
 #define CONFIG_ARM_ERRATA_833471
 
+#define CONFIG_SYS_FSL_MAX_NUM_OF_SEC  1
 #elif defined(CONFIG_LS1043A)
 #define CONFIG_MAX_CPUS4
 #define CONFIG_SYS_CACHELINE_SIZE  64
@@ -195,6 +196,7 @@
 #define CONFIG_SYS_FSL_ERRATUM_A009929
 #define CONFIG_SYS_FSL_ERRATUM_A009942
 #define CONFIG_SYS_FSL_ERRATUM_A009660
+#define CONFIG_SYS_FSL_MAX_NUM_OF_SEC  1
 #else
 #error SoC not defined
 #endif
diff --git a/arch/arm/include/asm/arch-ls102xa/config.h 
b/arch/arm/include/asm/arch-ls102xa/config.h
index 92f30e2..139a623 100644
--- a/arch/arm/include/asm/arch-ls102xa/config.h
+++ b/arch/arm/include/asm/arch-ls102xa/config.h
@@ -132,6 +132,7 @@
 #define CONFIG_USB_MAX_CONTROLLER_COUNT1
 #define CONFIG_SYS_FSL_ERRATUM_A008378
 #define CONFIG_SYS_FSL_ERRATUM_A009663
+#define CONFIG_SYS_FSL_MAX_NUM_OF_SEC  1
 #else
 #error SoC not defined
 #endif
diff --git a/arch/powerpc/include/asm/config_mpc85xx.h 
b/arch/powerpc/include/asm/config_mpc85xx.h
index eccc146..505d355 100644
--- a/arch/powerpc/include/asm/config_mpc85xx.h
+++ b/arch/powerpc/include/asm/config_mpc85xx.h
@@ -928,6 +928,8 @@ defined(CONFIG_PPC_T1014) || defined(CONFIG_PPC_T1013)
 #define CONFIG_SYS_FSL_IFC_BANK_COUNT  8
 #define CONFIG_SYS_CCSRBAR_DEFAULT 0xff70
 #define CONFIG_SYS_FSL_ERRATUM_A005125
+#define CONFIG_SYS_FSL_MAX_NUM_OF_SEC  3
+#define CONFIG_SYS_FSL_SEC_IDX_OFFSET  0x2
 
 #elif defined(CONFIG_QEMU_E500)
 #define CONFIG_MAX_CPUS1
@@ -954,4 +956,8 @@ defined(CONFIG_PPC_T1014) || defined(CONFIG_PPC_T1013)
 #define CONFIG_SYS_FSL_DDRC_GEN3
 #endif
 
+#if !defined(CONFIG_PPC_C29X)
+#define CONFIG_SYS_FSL_MAX_NUM_OF_SEC  1
+#endif
+
 #endif /* _ASM_MPC85xx_CONFIG_H_ */
diff --git a/board/freescale/c29xpcie/c29xpcie.c 
b/board/freescale/c29xpcie/c29xpcie.c
index e325b4d..45f463f 100644
--- a/board/freescale/c29xpcie/c29xpcie.c
+++ b/board/freescale/c29xpcie/c29xpcie.c
@@ -122,7 +122,7 @@ void fdt_del_sec(void *blob, int offset)
 
while ((nodeoff = fdt_node_offset_by_compat_reg(blob, "fsl,sec-v6.0",
CONFIG_SYS_CCSRBAR_PHYS + CONFIG_SYS_FSL_SEC_OFFSET
-   + offset * 0x2)) >= 0) {
+   + offset * CONFIG_SYS_FSL_SEC_IDX_OFFSET)) >= 0) {
fdt_del_node(blob, nodeoff);
offset++;
}
-- 
1.9.3

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

[U-Boot] Marvell Switch // U-Boot

[Hannes Schmelzer]

Hi Prafulla,

i've just received the new i.mx6 board from our hardware-development team 
and i'm going to start board bringup.
One of the next things is to bring up ethernet.

I have a 88E6321 switch soldered down on the board, connected through 
rgmii.

A quick look into u-boot's tree showed me that there are a few marvell 
switches supported but not exactly this one.
Do you know if one of the supported ones (88e61xx and 88e6352) is 
compatible with the 88e6321 ?

If not, is marvell planning to provide some  support for the 6321 in 
future? or have i to build the support by my own?

many thanks and best regards,

Hannes

_
Hannes Schmelzer


Bernecker + Rainer Industrie-Elektronik Ges.m.b.H.
B Straße 1
5142 Eggelsberg
Austria

Tel: +43 7748 6586 - 1612
Fax: +43 7748 6586 - 26
Email: hannes.schmel...@br-automation.com
http://www.br-automation.com 

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

[U-Boot] [PATCH v7 6/7] net: phy: Add phy_interface_is_sgmii to phy.h

[Dan Murphy]

Add a helper to phy.h to identify whether the
phy is configured for SGMII all variables.

Signed-off-by: Dan Murphy 
Reviewed-by: Mugunthan V N 
Reviewed-by: Michal Simek 
---

v7 - no changes from v6

 include/phy.h | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/include/phy.h b/include/phy.h
index 7b2d1ff..ef3eb51 100644
--- a/include/phy.h
+++ b/include/phy.h
@@ -288,6 +288,17 @@ static inline bool phy_interface_is_rgmii(struct 
phy_device *phydev)
phydev->interface <= PHY_INTERFACE_MODE_RGMII_TXID;
 }
 
+/**
+ * phy_interface_is_sgmii - Convenience function for testing if a PHY interface
+ * is SGMII (all variants)
+ * @phydev: the phy_device struct
+ */
+static inline bool phy_interface_is_sgmii(struct phy_device *phydev)
+{
+   return phydev->interface >= PHY_INTERFACE_MODE_SGMII &&
+   phydev->interface <= PHY_INTERFACE_MODE_QSGMII;
+}
+
 /* PHY UIDs for various PHYs that are referenced in external code */
 #define PHY_UID_CS4340  0x13e51002
 #define PHY_UID_TN2020 0x00a19410
-- 
2.8.1.116.g7b0d47b

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

[U-Boot] [PATCH v7 4/7] net: phy: ti: Allow the driver to be more configurable

[Dan Murphy]

Not all devices use the same internal delay or fifo depth.
Add the ability to set the internal delay for rx or tx and the
fifo depth via the devicetree.  If the value is not set in the
devicetree then set the delay to the default.

If devicetree is not used then use the default defines within the
driver.

Signed-off-by: Dan Murphy 
---

v7 - Fixed checkpatch issues - https://patchwork.ozlabs.org/patch/610950/
Checkpatch LTL issues still remain and resolving will break readability

WARNING: line over 80 characters
#127: FILE: drivers/net/phy/ti.c:232:
WARNING: line over 80 characters
#140: FILE: drivers/net/phy/ti.c:255:
WARNING: line over 80 characters
#141: FILE: drivers/net/phy/ti.c:256:
WARNING: line over 80 characters
#152: FILE: drivers/net/phy/ti.c:279:

 drivers/net/phy/ti.c | 87 ++--
 1 file changed, 77 insertions(+), 10 deletions(-)

diff --git a/drivers/net/phy/ti.c b/drivers/net/phy/ti.c
index 937426b..4c4f0c1 100644
--- a/drivers/net/phy/ti.c
+++ b/drivers/net/phy/ti.c
@@ -6,6 +6,14 @@
  */
 #include 
 #include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
 
 /* TI DP83867 */
 #define DP83867_DEVADDR0x1f
@@ -71,6 +79,17 @@
 #define MII_MMD_CTRL_INCR_RDWT 0x8000 /* post increment on reads & writes */
 #define MII_MMD_CTRL_INCR_ON_WT0xC000 /* post increment on writes only 
*/
 
+/* User setting - can be taken from DTS */
+#define DEFAULT_RX_ID_DELAYDP83867_RGMIIDCTL_2_25_NS
+#define DEFAULT_TX_ID_DELAYDP83867_RGMIIDCTL_2_75_NS
+#define DEFAULT_FIFO_DEPTH DP83867_PHYCR_FIFO_DEPTH_4_B_NIB
+
+struct dp83867_private {
+   int rx_id_delay;
+   int tx_id_delay;
+   int fifo_depth;
+};
+
 /**
  * phy_read_mmd_indirect - reads data from the MMD registers
  * @phydev: The PHY device bus
@@ -148,16 +167,60 @@ static inline bool phy_interface_is_rgmii(struct 
phy_device *phydev)
phydev->interface <= PHY_INTERFACE_MODE_RGMII_TXID;
 }
 
-/* User setting - can be taken from DTS */
-#define RX_ID_DELAY8
-#define TX_ID_DELAY0xa
-#define FIFO_DEPTH 1
+#if defined(CONFIG_DM_ETH)
+/**
+ * dp83867_data_init - Convenience function for setting PHY specific data
+ *
+ * @phydev: the phy_device struct
+ */
+static int dp83867_of_init(struct phy_device *phydev)
+{
+   struct dp83867_private *dp83867 = phydev->priv;
+   struct udevice *dev = phydev->dev;
+
+   dp83867->rx_id_delay = fdtdec_get_uint(gd->fdt_blob, dev->of_offset,
+"ti,rx-internal-delay", -1);
+
+   dp83867->tx_id_delay = fdtdec_get_uint(gd->fdt_blob, dev->of_offset,
+"ti,tx-internal-delay", -1);
+
+   dp83867->fifo_depth = fdtdec_get_uint(gd->fdt_blob, dev->of_offset,
+"ti,fifo-depth", -1);
+
+   return 0;
+}
+#else
+static int dp83867_of_init(struct phy_device *phydev)
+{
+   struct dp83867_private *dp83867 = phydev->priv;
+
+   dp83867->rx_id_delay = DEFAULT_RX_ID_DELAY;
+   dp83867->tx_id_delay = DEFAULT_TX_ID_DELAY;
+   dp83867->fifo_depth = DEFAULT_FIFO_DEPTH;
+
+   return 0;
+}
+#endif
 
 static int dp83867_config(struct phy_device *phydev)
 {
+   struct dp83867_private *dp83867;
unsigned int val, delay, cfg2;
int ret;
 
+   if (!phydev->priv) {
+   dp83867 = kzalloc(sizeof(*dp83867), GFP_KERNEL);
+   if (!dp83867)
+   return -ENOMEM;
+
+   phydev->priv = dp83867;
+   ret = dp83867_of_init(phydev);
+   if (ret)
+   goto err_out;
+   } else {
+   dp83867 = (struct dp83867_private *)phydev->priv;
+   }
+
/* Restart the PHY.  */
val = phy_read(phydev, MDIO_DEVAD_NONE, DP83867_CTRL);
phy_write(phydev, MDIO_DEVAD_NONE, DP83867_CTRL,
@@ -166,9 +229,9 @@ static int dp83867_config(struct phy_device *phydev)
if (phy_interface_is_rgmii(phydev)) {
ret = phy_write(phydev, MDIO_DEVAD_NONE, MII_DP83867_PHYCTRL,
(DP83867_MDI_CROSSOVER_AUTO << DP83867_MDI_CROSSOVER) |
-   (FIFO_DEPTH << DP83867_PHYCR_FIFO_DEPTH_SHIFT));
+   (dp83867->fifo_depth << 
DP83867_PHYCR_FIFO_DEPTH_SHIFT));
if (ret)
-   return ret;
+   goto err_out;
} else {
phy_write(phydev, MDIO_DEVAD_NONE, MII_BMCR,
  (BMCR_ANENABLE | BMCR_FULLDPLX | BMCR_SPEED1000));
@@ -189,8 +252,8 @@ static int dp83867_config(struct phy_device *phydev)
  DP83867_PHYCTRL_SGMIIEN |
  (DP83867_MDI_CROSSOVER_MDIX <<
  DP83867_MDI_CROSSOVER) |
- (FIFO_DEPTH << DP83867_PHYCTRL_RXFIFO_SHIFT) |
- (FIFO_DEPTH  << 

[U-Boot] [PATCH v7 5/7] net: phy: Move is_rgmii helper to phy.h

[Dan Murphy]

Move the phy_interface_is_rgmii to the phy.h
file for all phy's to be able to use the API.

This now aligns with the Linux kernel based on
commit e463d88c36d42211aa72ed76d32fb8bf37820ef1

Signed-off-by: Dan Murphy 
Reviewed-by: Mugunthan V N 
Reviewed-by: Michal Simek 
---

v7 - no changes from v6

 drivers/net/phy/ti.c | 11 ---
 include/phy.h| 11 +++
 2 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/net/phy/ti.c b/drivers/net/phy/ti.c
index 4c4f0c1..4c19353 100644
--- a/drivers/net/phy/ti.c
+++ b/drivers/net/phy/ti.c
@@ -156,17 +156,6 @@ void phy_write_mmd_indirect(struct phy_device *phydev, int 
prtad,
phy_write(phydev, addr, MII_MMD_DATA, data);
 }
 
-/**
- * phy_interface_is_rgmii - Convenience function for testing if a PHY interface
- * is RGMII (all variants)
- * @phydev: the phy_device struct
- */
-static inline bool phy_interface_is_rgmii(struct phy_device *phydev)
-{
-   return phydev->interface >= PHY_INTERFACE_MODE_RGMII &&
-   phydev->interface <= PHY_INTERFACE_MODE_RGMII_TXID;
-}
-
 #if defined(CONFIG_DM_ETH)
 /**
  * dp83867_data_init - Convenience function for setting PHY specific data
diff --git a/include/phy.h b/include/phy.h
index 21459a8..7b2d1ff 100644
--- a/include/phy.h
+++ b/include/phy.h
@@ -277,6 +277,17 @@ int get_phy_id(struct mii_dev *bus, int addr, int devad, 
u32 *phy_id);
  */
 int phy_get_interface_by_name(const char *str);
 
+/**
+ * phy_interface_is_rgmii - Convenience function for testing if a PHY interface
+ * is RGMII (all variants)
+ * @phydev: the phy_device struct
+ */
+static inline bool phy_interface_is_rgmii(struct phy_device *phydev)
+{
+   return phydev->interface >= PHY_INTERFACE_MODE_RGMII &&
+   phydev->interface <= PHY_INTERFACE_MODE_RGMII_TXID;
+}
+
 /* PHY UIDs for various PHYs that are referenced in external code */
 #define PHY_UID_CS4340  0x13e51002
 #define PHY_UID_TN2020 0x00a19410
-- 
2.8.1.116.g7b0d47b

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

[U-Boot] [PATCH v7 3/7] net: phy: dp83867: Add device tree bindings and documentation

[Dan Murphy]

Add the device tree bindings and the accompanying documentation
for the TI DP83867 Giga bit ethernet phy driver.

The original document was from:
[commit 2a10154abcb75ad0d7b6bfea6210ac743ec60897 from the Linux kernel]

Signed-off-by: Dan Murphy 
Reviewed-by: Mugunthan V N 
---

v7 - no changes from v6

 doc/device-tree-bindings/net/ti,dp83867.txt | 25 +
 include/dt-bindings/net/ti-dp83867.h| 35 +
 2 files changed, 60 insertions(+)
 create mode 100644 doc/device-tree-bindings/net/ti,dp83867.txt
 create mode 100644 include/dt-bindings/net/ti-dp83867.h

diff --git a/doc/device-tree-bindings/net/ti,dp83867.txt 
b/doc/device-tree-bindings/net/ti,dp83867.txt
new file mode 100644
index 000..cb77fdf
--- /dev/null
+++ b/doc/device-tree-bindings/net/ti,dp83867.txt
@@ -0,0 +1,25 @@
+* Texas Instruments - dp83867 Giga bit ethernet phy
+
+Required properties:
+   - reg - The ID number for the phy, usually a small integer
+   - ti,rx-internal-delay - RGMII Recieve Clock Delay - see 
dt-bindings/net/ti-dp83867.h
+   for applicable values
+   - ti,tx-internal-delay - RGMII Transmit Clock Delay - see 
dt-bindings/net/ti-dp83867.h
+   for applicable values
+   - ti,fifo-depth - Transmitt FIFO depth- see dt-bindings/net/ti-dp83867.h
+   for applicable values
+
+Default child nodes are standard Ethernet PHY device
+nodes as described in doc/devicetree/bindings/net/ethernet.txt
+
+Example:
+
+   ethernet-phy@0 {
+   reg = <0>;
+   ti,rx-internal-delay = ;
+   ti,tx-internal-delay = ;
+   ti,fifo-depth = ;
+   };
+
+Datasheet can be found:
+http://www.ti.com/product/DP83867IR/datasheet
diff --git a/include/dt-bindings/net/ti-dp83867.h 
b/include/dt-bindings/net/ti-dp83867.h
new file mode 100644
index 000..1843757
--- /dev/null
+++ b/include/dt-bindings/net/ti-dp83867.h
@@ -0,0 +1,35 @@
+/*
+ * TI DP83867 PHY drivers
+ *
+ * SPDX-License-Identifier:GPL-2.0
+ *
+ */
+
+#ifndef _DT_BINDINGS_TI_DP83867_H
+#define _DT_BINDINGS_TI_DP83867_H
+
+/* PHY CTRL bits */
+#define DP83867_PHYCR_FIFO_DEPTH_3_B_NIB   0x00
+#define DP83867_PHYCR_FIFO_DEPTH_4_B_NIB   0x01
+#define DP83867_PHYCR_FIFO_DEPTH_6_B_NIB   0x02
+#define DP83867_PHYCR_FIFO_DEPTH_8_B_NIB   0x03
+
+/* RGMIIDCTL internal delay for rx and tx */
+#define DP83867_RGMIIDCTL_250_PS   0x0
+#define DP83867_RGMIIDCTL_500_PS   0x1
+#define DP83867_RGMIIDCTL_750_PS   0x2
+#define DP83867_RGMIIDCTL_1_NS 0x3
+#define DP83867_RGMIIDCTL_1_25_NS  0x4
+#define DP83867_RGMIIDCTL_1_50_NS  0x5
+#define DP83867_RGMIIDCTL_1_75_NS  0x6
+#define DP83867_RGMIIDCTL_2_00_NS  0x7
+#define DP83867_RGMIIDCTL_2_25_NS  0x8
+#define DP83867_RGMIIDCTL_2_50_NS  0x9
+#define DP83867_RGMIIDCTL_2_75_NS  0xa
+#define DP83867_RGMIIDCTL_3_00_NS  0xb
+#define DP83867_RGMIIDCTL_3_25_NS  0xc
+#define DP83867_RGMIIDCTL_3_50_NS  0xd
+#define DP83867_RGMIIDCTL_3_75_NS  0xe
+#define DP83867_RGMIIDCTL_4_00_NS  0xf
+
+#endif
-- 
2.8.1.116.g7b0d47b

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

[U-Boot] [PATCH v7 7/7] net: phy: dp83867: Add SGMII helper for configuration

[Dan Murphy]

The code assumed that if the interface is not RGMII configured
then it must be SGMII configured.  This device has the ability
to support most of the MII interfaces.  Therefore add the
helper for SGMII and only configure the device if the interface is
configured for SGMII.

Signed-off-by: Dan Murphy 
Reviewed-by: Mugunthan V N 
Reviewed-by: Michal Simek 
---

v7 - no changes from v6

 drivers/net/phy/ti.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/phy/ti.c b/drivers/net/phy/ti.c
index 4c19353..c55dd97 100644
--- a/drivers/net/phy/ti.c
+++ b/drivers/net/phy/ti.c
@@ -221,7 +221,7 @@ static int dp83867_config(struct phy_device *phydev)
(dp83867->fifo_depth << 
DP83867_PHYCR_FIFO_DEPTH_SHIFT));
if (ret)
goto err_out;
-   } else {
+   } else if (phy_interface_is_sgmii(phydev)) {
phy_write(phydev, MDIO_DEVAD_NONE, MII_BMCR,
  (BMCR_ANENABLE | BMCR_FULLDPLX | BMCR_SPEED1000));
 
-- 
2.8.1.116.g7b0d47b

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

[U-Boot] [PATCH v7 2/7] net: zynq_gem: Add the passing of the phy-handle node

[Dan Murphy]

Add the ability to pass the phy-handle node offset
to the phy driver.  This allows the phy driver
to access the DT subnode's data and parse accordingly.

Signed-off-by: Dan Murphy 
Tested-by: Michal Simek 
---

v7 - no changes from v6

 drivers/net/zynq_gem.c | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/net/zynq_gem.c b/drivers/net/zynq_gem.c
index aec8077..f9b22c4 100644
--- a/drivers/net/zynq_gem.c
+++ b/drivers/net/zynq_gem.c
@@ -179,6 +179,7 @@ struct zynq_gem_priv {
struct zynq_gem_regs *iobase;
phy_interface_t interface;
struct phy_device *phydev;
+   int phy_of_handle;
struct mii_dev *bus;
 };
 
@@ -352,6 +353,10 @@ static int zynq_phy_init(struct udevice *dev)
priv->phydev->supported = supported | ADVERTISED_Pause |
  ADVERTISED_Asym_Pause;
priv->phydev->advertising = priv->phydev->supported;
+
+   if (priv->phy_of_handle > 0)
+   priv->phydev->dev->of_offset = priv->phy_of_handle;
+
phy_config(priv->phydev);
 
return 0;
@@ -675,7 +680,6 @@ static int zynq_gem_ofdata_to_platdata(struct udevice *dev)
 {
struct eth_pdata *pdata = dev_get_platdata(dev);
struct zynq_gem_priv *priv = dev_get_priv(dev);
-   int offset = 0;
const char *phy_mode;
 
pdata->iobase = (phys_addr_t)dev_get_addr(dev);
@@ -684,10 +688,11 @@ static int zynq_gem_ofdata_to_platdata(struct udevice 
*dev)
priv->emio = 0;
priv->phyaddr = -1;
 
-   offset = fdtdec_lookup_phandle(gd->fdt_blob, dev->of_offset,
-  "phy-handle");
-   if (offset > 0)
-   priv->phyaddr = fdtdec_get_int(gd->fdt_blob, offset, "reg", -1);
+   priv->phy_of_handle = fdtdec_lookup_phandle(gd->fdt_blob,
+   dev->of_offset, "phy-handle");
+   if (priv->phy_of_handle > 0)
+   priv->phyaddr = fdtdec_get_int(gd->fdt_blob,
+   priv->phy_of_handle, "reg", -1);
 
phy_mode = fdt_getprop(gd->fdt_blob, dev->of_offset, "phy-mode", NULL);
if (phy_mode)
-- 
2.8.1.116.g7b0d47b

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

[U-Boot] [PATCH v7 1/7] drivers: net: cpsw: Add reading of DT phy-handle node

[Dan Murphy]

Add the ability to read the phy-handle node of the
cpsw slave.  Upon reading this handle the phy-id
can be stored based on the reg node in the DT.

The phy-handle also needs to be stored and passed
to the phy to access any phy data that is available.

Signed-off-by: Dan Murphy 
---

v7 - Fixed checkpatch issues - https://patchwork.ozlabs.org/patch/610946/
Checkpatch LTL issues still remain and resolving will break readability

WARNING: line over 80 characters
#47: FILE: drivers/net/cpsw.c:1230:
WARNING: line over 80 characters
#50: FILE: drivers/net/cpsw.c:1233:


 drivers/net/cpsw.c | 23 +--
 include/cpsw.h |  1 +
 2 files changed, 22 insertions(+), 2 deletions(-)

diff --git a/drivers/net/cpsw.c b/drivers/net/cpsw.c
index 7104754..a2d9527 100644
--- a/drivers/net/cpsw.c
+++ b/drivers/net/cpsw.c
@@ -965,6 +965,11 @@ static int cpsw_phy_init(struct cpsw_priv *priv, struct 
cpsw_slave *slave)
phydev->supported &= supported;
phydev->advertising = phydev->supported;
 
+#ifdef CONFIG_DM_ETH
+   if (slave->data->phy_of_handle)
+   phydev->dev->of_offset = slave->data->phy_of_handle;
+#endif
+
priv->phydev = phydev;
phy_config(phydev);
 
@@ -1217,8 +1222,22 @@ static int cpsw_eth_ofdata_to_platdata(struct udevice 
*dev)
if (phy_mode)
priv->data.slave_data[slave_index].phy_if =
phy_get_interface_by_name(phy_mode);
-   fdtdec_get_int_array(fdt, subnode, "phy_id", phy_id, 2);
-   priv->data.slave_data[slave_index].phy_addr = phy_id[1];
+
+   priv->data.slave_data[slave_index].phy_of_handle =
+   fdtdec_lookup_phandle(fdt, subnode,
+ "phy-handle");
+
+   if (priv->data.slave_data[slave_index].phy_of_handle >= 
0) {
+   priv->data.slave_data[slave_index].phy_addr =
+   fdtdec_get_int(gd->fdt_blob,
+  
priv->data.slave_data[slave_index].phy_of_handle,
+  "reg", -1);
+   } else {
+   fdtdec_get_int_array(fdt, subnode, "phy_id",
+phy_id, 2);
+   priv->data.slave_data[slave_index].phy_addr =
+   phy_id[1];
+   }
slave_index++;
}
 
diff --git a/include/cpsw.h b/include/cpsw.h
index cf1d30b..ff95cd8 100644
--- a/include/cpsw.h
+++ b/include/cpsw.h
@@ -21,6 +21,7 @@ struct cpsw_slave_data {
u32 sliver_reg_ofs;
int phy_addr;
int phy_if;
+   int phy_of_handle;
 };
 
 enum {
-- 
2.8.1.116.g7b0d47b

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

[U-Boot] [PATCH] ARM64: zynqmp: Enable SPI_FLASH and FLASH_BAR for ep108

[Michal Simek]

Add missing SPI flash options.

Signed-off-by: Michal Simek 
---

 configs/xilinx_zynqmp_ep_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/xilinx_zynqmp_ep_defconfig 
b/configs/xilinx_zynqmp_ep_defconfig
index dbf490674dc5..903dc48d5423 100644
--- a/configs/xilinx_zynqmp_ep_defconfig
+++ b/configs/xilinx_zynqmp_ep_defconfig
@@ -44,6 +44,8 @@ CONFIG_SYS_I2C_CADENCE=y
 CONFIG_DM_MMC=y
 CONFIG_ZYNQ_SDHCI=y
 CONFIG_NAND_ARASAN=y
+CONFIG_SPI_FLASH=y
+CONFIG_SPI_FLASH_BAR=y
 CONFIG_DM_ETH=y
 CONFIG_ZYNQ_GEM=y
 CONFIG_DEBUG_UART=y
-- 
1.9.1

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

[U-Boot] [PATCH] ARm64: zynqmp: Remove CONFIG_PREBOOT

[Michal Simek]

CONFIG_PREBOOT variable is breaking ./test/py framework.
Remove it.

Signed-off-by: Michal Simek 
---

 include/configs/xilinx_zynqmp.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/include/configs/xilinx_zynqmp.h b/include/configs/xilinx_zynqmp.h
index c6a93de4bbd9..346318dcea4f 100644
--- a/include/configs/xilinx_zynqmp.h
+++ b/include/configs/xilinx_zynqmp.h
@@ -159,7 +159,6 @@
"booti $kernel_addr - $fdt_addr\0" \
DFU_ALT_INFO
 
-#define CONFIG_PREBOOT "run bootargs"
 #define CONFIG_BOOTCOMMAND "run $modeboot"
 #define CONFIG_BOOTDELAY   3
 
-- 
1.9.1

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

Re: [U-Boot] [PATCH 1/2] mtd: cqspi: Simplify indirect write code

[Marek Vasut]

On 04/29/2016 11:35 AM, Stefan Roese wrote:
> Hi Marek,
> 
> On 28.04.2016 00:36, Marek Vasut wrote:
>> The indirect write code is buggy pile of nastiness which fails horribly
>> when the system runs fast enough to saturate the controller. The failure
>> results in some pages (256B) not being written to the flash. This can be
>> observed on systems which run with Dcache enabled and L2 cache enabled,
>> like the Altera SoCFPGA.
>>
>> This patch replaces the whole unmaintainable indirect write implementation
>> with the one from upcoming Linux CQSPI driver, which went through multiple
>> rounds of thorough review and testing. While this makes the patch look
>> terrifying and violates all best-practices of software development, all
>> the patch does is it plucks out duplicate ad-hoc code distributed across
>> the driver and replaces it with more compact code doing exactly the same
>> thing.
>>
>> Signed-off-by: Marek Vasut 
>> Cc: Anatolij Gustschin 
>> Cc: Chin Liang See 
>> Cc: Dinh Nguyen 
>> Cc: Jagan Teki 
>> Cc: Pavel Machek 
>> Cc: Stefan Roese 
>> Cc: Vignesh R 
> 
> I've applied both patches and tested them on SR1500 (SPI-NOR used
> for booting and redundant environment). This is what I get upon
> "saveeenv":
> 
> => saveenv
> Saving Environment to SPI Flash...
> SF: Detected N25Q128 with page size 256 Bytes, erase size 64 KiB, total 16 MiB
> Erasing SPI flash...Writing to SPI flash...data abort
> pc : [<3ff8368a>]  lr : [<3ff8301b>]
> reloc pc : [<010216ca>]lr : [<0102105b>]
> sp : 3bf54eb8  ip : 3ff82f69 fp : 0002
> r10:   r9 : 3bf5dee8 r8 : 
> r7 : 0001  r6 : 3bf54f9b r5 : 0001  r4 : 3bf5e520
> r3 :   r2 : 3bf54f9b r1 : 0001  r0 : ffa0
> Flags: nZCv  IRQs off  FIQs off  Mode SVC_32
> Resetting CPU ...
> 
> resetting ...
> 
> U-Boot SPL 2016.05-rc3-9-ge1bf9b8 (Apr 29 2016 - 11:25:46)
> 
> 
> Any idea, what might be going wrong here?

Does it work without the patch ? Where does your PC point to at the time
of the crash ,which function is it ?

> Thanks,
> Stefan
> 


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

Re: [U-Boot] [PATCH 1/2] mtd: cqspi: Simplify indirect write code

[Stefan Roese]

Hi Marek,

On 28.04.2016 00:36, Marek Vasut wrote:
> The indirect write code is buggy pile of nastiness which fails horribly
> when the system runs fast enough to saturate the controller. The failure
> results in some pages (256B) not being written to the flash. This can be
> observed on systems which run with Dcache enabled and L2 cache enabled,
> like the Altera SoCFPGA.
> 
> This patch replaces the whole unmaintainable indirect write implementation
> with the one from upcoming Linux CQSPI driver, which went through multiple
> rounds of thorough review and testing. While this makes the patch look
> terrifying and violates all best-practices of software development, all
> the patch does is it plucks out duplicate ad-hoc code distributed across
> the driver and replaces it with more compact code doing exactly the same
> thing.
> 
> Signed-off-by: Marek Vasut 
> Cc: Anatolij Gustschin 
> Cc: Chin Liang See 
> Cc: Dinh Nguyen 
> Cc: Jagan Teki 
> Cc: Pavel Machek 
> Cc: Stefan Roese 
> Cc: Vignesh R 

I've applied both patches and tested them on SR1500 (SPI-NOR used
for booting and redundant environment). This is what I get upon
"saveeenv":

=> saveenv
Saving Environment to SPI Flash...
SF: Detected N25Q128 with page size 256 Bytes, erase size 64 KiB, total 16 MiB
Erasing SPI flash...Writing to SPI flash...data abort
pc : [<3ff8368a>]  lr : [<3ff8301b>]
reloc pc : [<010216ca>]lr : [<0102105b>]
sp : 3bf54eb8  ip : 3ff82f69 fp : 0002
r10:   r9 : 3bf5dee8 r8 : 
r7 : 0001  r6 : 3bf54f9b r5 : 0001  r4 : 3bf5e520
r3 :   r2 : 3bf54f9b r1 : 0001  r0 : ffa0
Flags: nZCv  IRQs off  FIQs off  Mode SVC_32
Resetting CPU ...

resetting ...

U-Boot SPL 2016.05-rc3-9-ge1bf9b8 (Apr 29 2016 - 11:25:46)


Any idea, what might be going wrong here?

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

[U-Boot] chainloading u-boot on an acer cb5 chromebook (nyan_big)

[Thomas Hoff]

Hello,

Could someone help point me in the right direction about chainloading
u-boot on an acer cb5 chromebook (nyan_big)? I'd like to be able to do a
nonverified uboot similar to what was done here:
https://www.chromium.org/chromium-os/firmware-porting-guide/using-nv-u-boot-on-the-samsung-arm-chromebook#TOC-Installing-nv-U-Boot-chained-U-Boot-method-

I'd really appreciate the help.

Cheers,

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

[U-Boot] u-boot hangs after enabling secured boot : gumstix-overo

[Arun Kuttiyara Varghese]

Hi All,

I was trying to enable the secured boot in u-boot for gumstix overo storm.

based on http://www.denx-cs.de/doku/?q=m28verifiedboot

After I prepared by SD cards, u-boot is not able to boot
and gives the below error message.


U-Boot SPL 2015.07 (Apr 28 2016 - 13:53:06)
SPL: Please implement spl_start_uboot() for your board
SPL: Direct Linux boot not active!
reading u-boot.img
spl_load_image_fat: error reading image u-boot.img, err - -1
SPL: Please implement spl_start_uboot() for your board
SPL: Direct Linux boot not active!
Failed to mount ext2 filesystem...
spl_load_image_ext: ext4fs mount err - 0



This is the u-boot.dts file that I am using.


/dts-v1/;

/ {
model = "Keys";

signature {
key-dev {
required = "conf";
algo = "sha1,rsa2048";
key-name-hint = "my_key";
};
};
};

compilation using :
dtc -p 0x1000 /work/u-boot.dts -O dtb -o /work/u-boot.dtb

And these are the conf that I have added to include/configs/omap3_overo.h

 #define CONFIG_OF_CONTROL
 #define CONFIG_OF_SEPARATE
 #define CONFIG_FIT
 #define CONFIG_FIT_SIGNATURE
 #define CONFIG_RSA
 #define CONFIG_FIT_VERBOSE

and I am compiling u-boot by using below line :

make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- EXT_DTB=/work/u-boot.dtb all
-j4

Please let me know if you have any ideas on how to debug this issue.

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

[U-Boot] Fwd: change the relocate address of u-boot

[Marwa Hamza]

-- Forwarded message --
From: Tom Rini 
Date: 2016-04-28 20:08 GMT+02:00
Subject: Re: [U-Boot] change the relocate address of u-boot
To: Marwa Hamza 
Cc: u-boot@lists.denx.de


On Thu, Apr 28, 2016 at 02:47:21PM +0100, Marwa Hamza wrote:

> hey
> i 'm trying to start a whole system on qemu (kernel ,
> bootloader,filesystem) and i need to change the relocate address , so i'm
> wondering if there is a patch to change this address 0x1000

You need to provide a lot more details as without any changes today
U-Boot is able to run in qemu for a number of boards that qemu supports
today.  In fact, I need to get around to converting some kernelci.org
rootfs tarballs into images to pass along and use...

--
Tom
well qemu doesn't need a bootloader to emulate a linux kernel , it needs
only zImage and rootfs file system
qemu-system-arm -M versatilepb -kernel zImage -initrd rootfs.img.gz
I played with QEMU emulation of an ARM Versatile Platform Board
,
making it run bare metal programs
,
the U-Boot
 boot-loader
and a Linux kernel

complete
with a Busybox-based file system
. I
tried to put everything together to emulate a complete boot procedure, but
it was not so simple
as we on execution the code copies itself into another address, which by
default is 0x100 (16MiB). This feature comes handy in this scenario
because it frees lower memory space in order to copy the Linux kernel. The
compressed kernel image size is about 1.5MiB, so the first 1.5MiB from the
start address must be free and usable when U-Boot copies the kernel
that works perfectly when the kernel 's size is small but when i use a
kernel 's size over 4MiB that wouldn't work that 's why changing the
relocate address will free more space
regards
marwa
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Issue with USB mass storage (thumb drives)

[Diego]

In data venerdì 29 aprile 2016 00:49:22, Marek Vasut ha scritto:
> 
> Urgh, so you seem to have third revision of this stick. I have two
> sticks which are exactly the same and work in U-Boot on MX6 wandboard:
> 

Hi Marek,

how big is the file you're trying to load?
For me it fails for files bigger than 16MB:
U-Boot > usb info
1: Hub,  USB Revision 2.0
 - u-boot EHCI Host Controller 
 - Class: Hub
 - PacketSize: 64  Configurations: 1
 - Vendor: 0x  Product 0x Version 1.0
   Configuration: 1
   - Interfaces: 1 Self Powered 0mA
 Interface: 0
 - Alternate Setting 0, Endpoints: 1
 - Class Hub
 - Endpoint 1 In Interrupt MaxPacket 8 Interval 255ms

2: Hub,  USB Revision 2.0
 - Class: Hub
 - PacketSize: 64  Configurations: 1
 - Vendor: 0x0424  Product 0x2513 Version 11.179
   Configuration: 1
   - Interfaces: 1 Self Powered Remote Wakeup 2mA
 Interface: 0
 - Alternate Setting 0, Endpoints: 1
 - Class Hub
 - Endpoint 1 In Interrupt MaxPacket 1 Interval 12ms
 - Endpoint 1 In Interrupt MaxPacket 1 Interval 12ms

3: Mass Storage,  USB Revision 2.0
 - Kingston DataTraveler SE9 0019E06B084BFD10470133E8
 - Class: (from Interface) Mass Storage
 - PacketSize: 64  Configurations: 1
 - Vendor: 0x0951  Product 0x1689 Version 1.0
   Configuration: 1
   - Interfaces: 1 Bus Powered 100mA
 Interface: 0
 - Alternate Setting 0, Endpoints: 2
 - Class Mass Storage, Transp. SCSI, Bulk only
 - Endpoint 1 In Bulk MaxPacket 512
 - Endpoint 2 Out Bulk MaxPacket 512

U-Boot > load usb 0:1 0x10008000 file1.raw
reading file1.raw
1048576 bytes read in 59 ms (16.9 MiB/s)
U-Boot > load usb 0:1 0x10008000 file2.raw
reading file2.raw
2097152 bytes read in 102 ms (19.6 MiB/s)
U-Boot > load usb 0:1 0x10008000 file4.raw
reading file4.raw
4194304 bytes read in 175 ms (22.9 MiB/s)
U-Boot > load usb 0:1 0x10008000 file6.raw
reading file6.raw
6291456 bytes read in 255 ms (23.5 MiB/s)
U-Boot > load usb 0:1 0x10008000 file8.raw
reading file8.raw
8388608 bytes read in 334 ms (24 MiB/s)
U-Boot > load usb 0:1 0x10008000 file10.raw
reading file10.raw
10485760 bytes read in 408 ms (24.5 MiB/s)
U-Boot > load usb 0:1 0x10008000 file15.raw
reading file15.raw
15728640 bytes read in 603 ms (24.9 MiB/s)
U-Boot > load usb 0:1 0x10008000 file16.raw
reading file16.raw
EHCI timed out on TD - token=0x90008d80
EHCI timed out on TD - token=0x10008d80
EHCI timed out on TD - token=0x10008d80
Error reading cluster
** Unable to read file file16.raw **
U-Boot > load usb 0:1 0x10008000 file20.raw
reading file20.raw
EHCI timed out on TD - token=0xd0008d80
EHCI timed out on TD - token=0x50008d80
EHCI timed out on TD - token=0x50008d80
Error reading cluster
** Unable to read file file20.raw **
U-Boot > load usb 0:1 0x10008000 file40.raw
reading file40.raw
EHCI timed out on TD - token=0x1e008d80
EHCI timed out on TD - token=0x1e008d80
EHCI timed out on TD - token=0x1e008d80
Error reading cluster
** Unable to read file file40.raw **
U-Boot >

Bests,
Diego

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

Re: [U-Boot] [PATCH v2 27/27] RFC: sunxi: Enable SPL FIT support

[Michal Simek]

On 28.4.2016 21:05, Tom Rini wrote:
> On Thu, Apr 28, 2016 at 03:12:19PM +0200, Michal Simek wrote:
>> On 28.4.2016 15:07, Tom Rini wrote:
>>> On Thu, Apr 28, 2016 at 11:44:50AM +0200, Michal Simek wrote:
 Hi Simon and Tom,

 On 23.2.2016 06:55, Simon Glass wrote:
> Enable SPL FIT support for the Linksprite pcDuino3 as an example of how 
> this
> feature is used.
>
> This is only for demonstration purposes and is not to be applied.
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  arch/arm/cpu/armv7/sunxi/board.c  | 5 +
>  configs/Linksprite_pcDuino3_defconfig | 4 
>  2 files changed, 9 insertions(+)

 I have played with SPL_FIT support and find some things
 First of all
 "mkimage: Support placing data outside the FIT"
 (722ebc8f84d5bccd2e70fad1079a0dd40cceddec)
 is missing description in usage function to see what -E options does.

 Then I have found a problem with fit address calculation because it has
 to be aligned.
 I have sent an RFC for it
 "SPL: FIT: Align loading address for header"

 I have also added support for ram load for FIT - please review.
 "SPL: FIT: Enable SPL_FIT_LOAD in RAM based boot mode"
>>>
>>> I think these are reasonable.
>>>
 And also for SD fat based images.
 "SPL: FIT: Enable SPL_FIT_LOAD for sd bootmode for fat partions"
>>>
>>> Ug, sorry.  You missed the series from Lokesh that added a bunch more
>>> features along those lines.  I didn't pull them in since it was past the
>>> merge window but will for the next release.
>>
>> Ah ok. Will look.
>>
>>>
 Is there any plan to support falcon mode?
 Also I see kind of interesting to have one fit image with ATF, Secure
 OS, bitstreams and U-Boot and Linux kernel + dtbs
 Currently spl_load_simple_fit() seems to me expecting to blindly read
 the first fit partition and say this is u-boot and then based
 configuration description choose dtb.

 Do you have any plan to get even u-boot image from configurations instead?
 The we should get a support for loadables.
>>>
>>> Well, the first itch I needed scratched was supporting many similar
>>> platforms in DM+DT from a single binary, and that's what's there today.
>>> So long as we can do things in a clean way, all of these other use cases
>>> sound interesting and clearly useful to some people, so I don't object.
>>
>>
>> How do you identify platform you are running at?
> 
> In these cases we know there is an I2C EEPROM with information in a
> given format so we can go from there.

OK. I see. We have eeproms on boards too which could be used for it too.
It means there is sort of plan to add i2c DM eeprom support to SPL.

Thanks,
Michal


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

Re: [U-Boot] [PATCH v2 06/12] drivers: net: cpsw: add support for reading mac address from efuse

[Mugunthan V N]

On Thursday 28 April 2016 10:01 AM, Joe Hershberger wrote:
> On Wed, Apr 27, 2016 at 1:33 AM, Mugunthan V N  wrote:
>> On Wednesday 27 April 2016 03:06 AM, Joe Hershberger wrote:
>>> On Mon, Apr 25, 2016 at 4:53 PM, Joe Hershberger
>>>  wrote:
 On Tue, Apr 12, 2016 at 3:46 AM, Mugunthan V N  wrote:
> Different TI platforms has to read with different combination to
> get the mac address from efuse. So add support to read mac address
> based on machine/device compatibles.
>
> The code is taken from Linux drivers/net/ethernet/ti/cpsw-common.c
> done by Tony Lindgren.
>
> Signed-off-by: Mugunthan V N 

 Acked-by: Joe Hershberger 
>>>
>>> This is not checkpatch.pl clean. Please resubmit.
>>>
>>> 609306.mbox:92: WARNING: line over 80 characters
>>> 609306.mbox:132: WARNING: line over 80 characters
>>>
>>
>> WARNING: line over 80 characters
>> #103: FILE: drivers/net/cpsw-common.c:39:
>> +   error("Not able to get syscon address to get mac efuse 
>> address\n");
>>
>> WARNING: line over 80 characters
>> #143: FILE: drivers/net/cpsw-common.c:79:
>> +   error("Not able to get syscon address to get mac efuse 
>> address\n");
>>
>> total: 0 errors, 2 warnings, 0 checks, 184 lines checked
>>
>> These warnings are from error logs which can be ignored as it makes life
>> easier to grep the source when issue is found. The same is followed in
>> kernel as well.
> 
> OK. Please address the other patch as well. Are all failures
> justifiable for the same reason?
> 

I just reposted the v3 of this patches with rebase to u-boot/master.
I get only the above two checkpatch warning for the whole series, is
there some other warning else you get in your testing?

Regards
Mugunthan V N

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

Re: [U-Boot] [PATCH 1/2] mtd: cqspi: Simplify indirect write code

[Vignesh R]

On 04/28/2016 04:06 AM, Marek Vasut wrote:
> The indirect write code is buggy pile of nastiness which fails horribly
> when the system runs fast enough to saturate the controller. The failure
> results in some pages (256B) not being written to the flash. This can be
> observed on systems which run with Dcache enabled and L2 cache enabled,
> like the Altera SoCFPGA.
> 
> This patch replaces the whole unmaintainable indirect write implementation
> with the one from upcoming Linux CQSPI driver, which went through multiple
> rounds of thorough review and testing. While this makes the patch look
> terrifying and violates all best-practices of software development, all
> the patch does is it plucks out duplicate ad-hoc code distributed across
> the driver and replaces it with more compact code doing exactly the same
> thing.
> 
> Signed-off-by: Marek Vasut 
> Cc: Anatolij Gustschin 
> Cc: Chin Liang See 
> Cc: Dinh Nguyen 
> Cc: Jagan Teki 
> Cc: Pavel Machek 
> Cc: Stefan Roese 
> Cc: Vignesh R 
> ---

Tested on K2G EVM that has Cadence QSPI controller and s25fl512s
Spansion flash
For both the patches:

Tested-by: Vignesh R 



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