Re: [U-Boot] [PATCH] ARM: mx6: Enable MMC FS boot support

[Stefano Babic]

Hi Marek,

On 28/04/2016 04:24, Peng Fan wrote:
> Hi Marek,
> 
> On Thu, Apr 28, 2016 at 01:06:07AM +0200, Marek Vasut wrote:
>> Enable support for booting U-Boot image from filesystem instead of some
>> random offset on the SD card. This makes the board usable by putting the
>> u-boot.img to first partition of the SD card and writing the SPL this way:
>> $ dd if=u-boot-with-spl.imx of=/dev/sdX seek=2 bs=512
> 
> I once want to enable this for i.MX6UL, but was rejected.
> Anyway I prefer load u-boot.img from filesystem.
> 

Right - we have this discussion some times ago. The agreement we reach
was to maintain SPL loading only from a raw image.

https://www.mail-archive.com/u-boot@lists.denx.de/msg185432.html

Best regards,
Stefano Babic

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

Re: [U-Boot] [PATCH] kbuild: Do not append dtb for OF_EMBED case

[Masahiro Yamada]

Hi Michal,
(+cc Simon)

2016-04-27 21:28 GMT+09:00 Michal Simek :
> dtb is already included in binary that's why there is no need to replace
> u-boot-spl.bin with u-boot-spl-dtb.bin. This is only needed for
> OF_SEPARATE is enabled. Only copy -nodtb.bin version which is straight
> output from objcopy -O binary.

Correct.

(But, as you know, fdtgrep does not work for OF_EMBED,
so this is only useful when SPL has enough memory footprint.)


> Signed-off-by: Michal Simek 
> ---
>
>  scripts/Makefile.spl | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
> index 44242842db31..79c680c1d62f 100644
> --- a/scripts/Makefile.spl
> +++ b/scripts/Makefile.spl
> @@ -170,12 +170,17 @@ $(obj)/$(SPL_BIN)-dtb.bin: $(obj)/$(SPL_BIN)-nodtb.bin 
> $(obj)/$(SPL_BIN)-pad.bin
> $(obj)/$(SPL_BIN).dtb FORCE
> $(call if_changed,cat)
>
> +ifeq ($(CONFIG_OF_SEPARATE),y)
>  $(obj)/$(SPL_BIN).bin: $(obj)/$(SPL_BIN)-dtb.bin FORCE
> $(call if_changed,copy)
>  else
>  $(obj)/$(SPL_BIN).bin: $(obj)/$(SPL_BIN)-nodtb.bin FORCE
> $(call if_changed,copy)
>  endif
> +else
> +$(obj)/$(SPL_BIN).bin: $(obj)/$(SPL_BIN)-nodtb.bin FORCE
> +   $(call if_changed,copy)
> +endif
>
>  # Create a file that pads from the end of u-boot-spl-nodtb.bin to bss_end
>  $(obj)/$(SPL_BIN)-pad.bin: $(obj)/$(SPL_BIN)



The code is duplicated for
 - CONFIG_SPL_OF_CONTROL=y && CONFIG_OF_SEPARATE=n
 - CONFIG_SPL_OF_CONTROL=n

Could you refactor a bit like follows?


ifeq ($(CONFIG_SPL_OF_CONTROL)$(CONFIG_OF_SEPARATE),yy)
$(obj)/$(SPL_BIN)-dtb.bin: $(obj)/$(SPL_BIN)-nodtb.bin
$(obj)/$(SPL_BIN)-pad.bin \
  $(obj)/$(SPL_BIN).dtb FORCE
$(call if_changed,cat)

$(obj)/$(SPL_BIN).bin: $(obj)/$(SPL_BIN)-dtb.bin FORCE
$(call if_changed,copy)
else
$(obj)/$(SPL_BIN).bin: $(obj)/$(SPL_BIN)-nodtb.bin FORCE
$(call if_changed,copy)
endif






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

[U-Boot] [PATCH] arm: socfpga: socrates: Add 'time' command

[Stefan Roese]

The time command is very helpful for performance and regressions tests.
So lets enable it on SoCrates.

Signed-off-by: Stefan Roese 
Cc: Marek Vasut 
---
 configs/socfpga_socrates_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/socfpga_socrates_defconfig 
b/configs/socfpga_socrates_defconfig
index b64ea15..a17e9d0 100644
--- a/configs/socfpga_socrates_defconfig
+++ b/configs/socfpga_socrates_defconfig
@@ -27,6 +27,7 @@ CONFIG_CMD_DHCP=y
 CONFIG_CMD_MII=y
 CONFIG_CMD_PING=y
 CONFIG_CMD_CACHE=y
+CONFIG_CMD_TIME=y
 CONFIG_CMD_EXT4=y
 CONFIG_CMD_EXT4_WRITE=y
 CONFIG_CMD_FAT=y
-- 
2.8.1

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

[U-Boot] [PATCH v2] fs: ext4: fix symlink read function

[Stefan Roese]

From: Ronald Zachariah 

The function ext4fs_read_symlink was unable to handle a symlink
which had target name of exactly 60 characters.

Signed-off-by: Ronald Zachariah 
Signed-off-by: Stefan Roese 
Reviewed-by: Stephen Warren 
Cc: Tom Rini 
---
v2:
- Change '60' to sizeof(diro->inode.b.symlink) as suggested by Stephen

 fs/ext4/ext4_common.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/ext4/ext4_common.c b/fs/ext4/ext4_common.c
index 84fba76..40b798a 100644
--- a/fs/ext4/ext4_common.c
+++ b/fs/ext4/ext4_common.c
@@ -2040,7 +2040,7 @@ static char *ext4fs_read_symlink(struct ext2fs_node *node)
if (!symlink)
return 0;
 
-   if (__le32_to_cpu(diro->inode.size) <= 60) {
+   if (__le32_to_cpu(diro->inode.size) < sizeof(diro->inode.b.symlink)) {
strncpy(symlink, diro->inode.b.symlink,
 __le32_to_cpu(diro->inode.size));
} else {
-- 
2.8.1

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

Re: [U-Boot] [PATCH v3 1/2] drivers/video/am335x-fb: Add support for 16bpp format

[Hannes Schmelzer]

On 27.04.2016 21:39, Martin Pietryka wrote:

To support 16bpp we just need to change the raster_ctrl register
accordingly. Also 32bpp mode should work as well, but was not tested.
According to the TRM the uppermost byte will be ignored when
LCD_TFT_24BPP_UNPACK is set.

The switch logic is based on the Liunx kernel tilcdc driver:
drivers/gpu/drm/tilcdc/tilcdc_crtc.c: lines 407 through 419
(kernel was checked out at commit: bcc981e9ed8)

Signed-off-by: Martin Pietryka 
---

Changes in v3:
- Moved switch statement before changing any registers

  drivers/video/am335x-fb.c | 22 +++---
  1 file changed, 19 insertions(+), 3 deletions(-)

diff --git a/drivers/video/am335x-fb.c b/drivers/video/am335x-fb.c
index 0ec843f..d984435 100644
--- a/drivers/video/am335x-fb.c
+++ b/drivers/video/am335x-fb.c
@@ -5,7 +5,7 @@
   * minimal framebuffer driver for TI's AM335x SoC to be compatible with
   * Wolfgang Denk's LCD-Framework (CONFIG_LCD, common/lcd.c)
   *
- * - supporting only 24bit RGB/TFT raster Mode (not using palette)
+ * - supporting 16/24/32bit RGB/TFT raster Mode (not using palette)
   * - sets up LCD controller as in 'am335x_lcdpanel' struct given
   * - starts output DMA from gd->fb_base buffer
   *
@@ -106,6 +106,8 @@ int lcd_get_size(int *line_length)
  
  int am335xfb_init(struct am335x_lcdpanel *panel)

  {
+   u32 raster_ctrl = 0;
+
if (0 == gd->fb_base) {
printf("ERROR: no valid fb_base stored in GLOBAL_DATA_PTR!\n");
return -1;
@@ -115,6 +117,21 @@ int am335xfb_init(struct am335x_lcdpanel *panel)
return -1;
}
  
+	/* We can already set the bits for the raster_ctrl in this check */

+   switch (panel->bpp) {
+   case 16:
+   break;
+   case 32:
+   raster_ctrl |= LCD_TFT_24BPP_UNPACK;
+   /* fallthrough */
+   case 24:
+   raster_ctrl |= LCD_TFT_24BPP_MODE;
+   break;
+   default:
+   error("am335x-fb: invalid bpp value: %d\n", panel->bpp);
+   return -1;
+   }
+
debug("setting up LCD-Controller for %dx%dx%d (hfp=%d,hbp=%d,hsw=%d / ",
  panel->hactive, panel->vactive, panel->bpp,
  panel->hfp, panel->hbp, panel->hsw);
@@ -157,8 +174,7 @@ int am335xfb_init(struct am335x_lcdpanel *panel)
LCD_HBPMSB(panel->hbp) |
LCD_HFPMSB(panel->hfp) |
0xFF00; /* clk cycles for ac-bias */
-   lcdhw->raster_ctrl = LCD_TFT_24BPP_MODE |
-   LCD_TFT_24BPP_UNPACK |
+   lcdhw->raster_ctrl = raster_ctrl |
LCD_PALMODE_RAWDATA |
LCD_TFT_MODE |
LCD_RASTER_ENABLE;

Reviewed-by: Hannes Schmelzer 
Tested-by: Hannes Schmelzer 

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

Re: [U-Boot] Problem of git clone with http

[Wolfgang Denk]

Dear Sergey,

In message  you wrote:
> 
> This seems to be a widespread thing. It is definitely caused by buggy Cisco
> firewalls corrupting binary files. I had the same problem in corporate

I cannot comment on this.  In our case the cause was a different one.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
It's not an optical illusion, it just looks like one.   -- Phil White
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

[Joe Hershberger]

On Wed, Apr 27, 2016 at 10:46 AM, Dan Murphy  wrote:
> Joe
>
> On 04/26/2016 04:44 PM, Joe Hershberger wrote:
>> On Mon, Apr 25, 2016 at 4:35 PM, Joe Hershberger
>>  wrote:
>>> On Fri, Apr 15, 2016 at 7:27 AM, Dan Murphy  wrote:
 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 
>>> Acked-by: Joe Hershberger 
>> This patch is not checkpatch.pl clean. Please resubmit.
>>
>>
>> 610950.mbox:140: WARNING: line over 80 characters
>> 610950.mbox:153: WARNING: line over 80 characters
>> 610950.mbox:154: WARNING: line over 80 characters
>> 610950.mbox:165: WARNING: line over 80 characters
>> total: 0 errors, 4 warnings, 0 checks, 136 lines checked
>
> How do you want me to rebase these patches on the SGMII work from Michal on 
> the ti.c
> or off of master?  The patch I submitted was based off of the SGMII patchset.

I'm pulling in some of Michal's patches this release. Please reference
which patches this depends on (patchwork links).

> Need to know how you want to handle this as I see the SGMII code is not in 
> the base line
> yet.

If the patches you depend on are acceptable (no changes requested)
then definitely base your changes on them, but point them out to me.

Thanks,
-Joe
___
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 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 
> ---
> 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().
>
> 2) uclass_find_device_by_name() needs to look up the uclass pointer again
> even though device_bind() already knows it.
>
> 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?
> ---
> drivers/core/device-remove.c | 4 
> drivers/core/device.c | 23 ++-
> include/dm/device.h | 3 +++
> 3 files changed, 29 insertions(+), 1 deletion(-)

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?

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

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

[Joe Hershberger]

On Wed, Apr 27, 2016 at 10:44 AM, Dan Murphy  wrote:
> Joe
>
> On 04/26/2016 04:42 PM, Joe Hershberger wrote:
>> On Mon, Apr 25, 2016 at 4:32 PM, Joe Hershberger
>>  wrote:
>>> On Fri, Apr 15, 2016 at 7:27 AM, Dan Murphy  wrote:
 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.
>>> It would be great if the phy could be handled generically.
>>> Unfortunately there is no uniform description so far, so having each
>>> driver parse it is the best we can do for now.
>>>
 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 
>>> Acked-by: Joe Hershberger 
>> This patch is not checkpatch.pl clean. Please resubmit.
>>
>>
>> 610946.mbox:57: WARNING: line over 80 characters
>> 610946.mbox:59: WARNING: line over 80 characters
>> 610946.mbox:62: WARNING: line over 80 characters
>> 610946.mbox:62: CHECK: Alignment should match open parenthesis
>> 610946.mbox:65: WARNING: line over 80 characters
>> 610946.mbox:66: WARNING: line over 80 characters
>> total: 0 errors, 5 warnings, 1 checks, 39 lines checked
> I can only fix a few there will still be at least 2 LTL warnings on this file 
> and fixing
> it will break readability
>
> I don't see how to fix this.
>
> WARNING: line over 80 characters
> #46: FILE: drivers/net/cpsw.c:1230:
> +if (priv->data.slave_data[slave_index].phy_of_handle >= 0) {
>
> WARNING: line over 80 characters
> #49: FILE: drivers/net/cpsw.c:1233:
> +   
> priv->data.slave_data[slave_index].phy_of_handle,

If you plan to have a patch that you feel can't be clean, please
comment after the patch log with the reasoning. I had enough failures
in the patches this release that I have not investigated each one on
my own.

Thanks,
-Joe
___
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

[Joe Hershberger]

On Wed, Apr 27, 2016 at 1:40 PM, Stephen Warren  wrote:
> On 04/26/2016 03:36 PM, Stephen Warren wrote:
>>
>> On 04/26/2016 03: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().
>>>
>>> 2) uclass_find_device_by_name() needs to look up the uclass pointer again
>>> even though device_bind() already knows it.
>>>
>>> 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?
>>
>>
>> 4) This causes "ut dm autobind" to fail. I'll investigate that locally,
>> but won't bother reposting until the questions above are considered.
>
>
> It looks like that's because I need to add "gd->dm_root && " to the start of
> the following condition:
>
>> @@ -62,6 +62,23 @@ int device_bind(struct udevice *parent, const struct
>> driver *drv,
>> dev->driver = drv;
>> dev->uclass = uc;
>>
>> +   if (!uclass_find_device_by_name(uc->uc_drv->id, dev->name, ))
>> {
>
>
> ... otherwise, the uc_class_get/find() nested inside that end up creating a
> second root uclass.

Makes sense.

> I can fold that into v2, pending any other comments.
>
> ___
> 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] [RFC PATCH] dm: ensure device names are unique

[Joe Hershberger]

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.

> 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?

> 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.

>  drivers/core/device-remove.c |  4 
>  drivers/core/device.c| 23 ++-
>  include/dm/device.h  |  3 +++
>  3 files changed, 29 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/core/device-remove.c b/drivers/core/device-remove.c
> index e1714b2202b6..a2400989024a 100644
> --- a/drivers/core/device-remove.c
> +++ b/drivers/core/device-remove.c
> @@ -112,6 +112,10 @@ int device_unbind(struct udevice *dev)
>
> devres_release_all(dev);
>
> +   if (dev->flags & DM_FLAG_ALLOC_NAME) {
> +   free((char *)dev->name);
> +   dev->name = NULL;
> +   }
> free(dev);
>
> return 0;
> diff --git a/drivers/core/device.c b/drivers/core/device.c
> index 269087a084cf..fcac0073c642 100644
> --- a/drivers/core/device.c
> +++ b/drivers/core/device.c
> @@ -30,7 +30,7 @@ int device_bind(struct udevice *parent, const struct driver 
> *drv,
> const char *name, void *platdata, int of_offset,
> struct udevice **devp)
>  {
> -   struct udevice *dev;
> +   struct udevice *dev, *dev2;
> struct uclass *uc;
> int size, ret = 0;
>
> @@ -62,6 +62,23 @@ int device_bind(struct udevice *parent, const struct 
> driver *drv,
> dev->driver = drv;
> dev->uclass = uc;
>
> +   if (!uclass_find_device_by_name(uc->uc_drv->id, dev->name, )) {
> +   char *unique_name;
> +   int count;
> +   size = strlen(name) + 4 + 1;
> +   unique_name = malloc(size);
> +   if (!unique_name) {
> +   ret = -ENOMEM;
> +   goto fail_alloc1;
> +   }
> +   dev->flags |= DM_FLAG_ALLOC_NAME;
> +   dev->name = unique_name;
> +   count = 0;
> +   list_for_each_entry(dev2, >dev_head, uclass_node)
> +   count++;
> +   snprintf(unique_name, size, "%s.%d", name, count);
> +   }
> +
> dev->seq = -1;
> dev->req_seq = -1;
> if (CONFIG_IS_ENABLED(OF_CONTROL) && CONFIG_IS_ENABLED(DM_SEQ_ALIAS)) 
> {
> @@ -186,6 +203,10 @@ fail_alloc2:
> dev->platdata = NULL;
> }
>  fail_alloc1:
> +   if (dev->flags & DM_FLAG_ALLOC_NAME) {
> +   free((char *)dev->name);
> +   dev->name = NULL;
> +   }
> devres_release_all(dev);
>
> free(dev);
> diff --git a/include/dm/device.h b/include/dm/device.h
> index dad7591dfacb..976ba72a550c 100644
> --- a/include/dm/device.h
> +++ b/include/dm/device.h
> @@ -41,6 +41,9 @@ struct driver_info;
>  /* Device is bound */
>  #define DM_FLAG_BOUND  (1 << 6)
>
> +/* DM is responsible for allocating and freeing device name */
> +#define DM_FLAG_ALLOC_NAME (1 << 7)
> +
>  /**
>   * struct udevice - An instance of a driver
>   *
> --
> 2.8.1
>
> 

Re: [U-Boot] [PATCH v2 10/12] defconfig: am437x_gp_evm: enable eth driver model

[Joe Hershberger]

On Wed, Apr 27, 2016 at 1:37 AM, Mugunthan V N  wrote:
> On Wednesday 27 April 2016 03:08 AM, Joe Hershberger wrote:
>> On Mon, Apr 25, 2016 at 5:01 PM, Joe Hershberger
>>  wrote:
>>> On Tue, Apr 12, 2016 at 3:46 AM, Mugunthan V N  wrote:
 Enable eth driver model for am437x_gp_evm as cpsw supports
 driver model.

 Signed-off-by: Mugunthan V N 
 Reviewed-by: Tom Rini 
>>>
>>> Acked-by: Joe Hershberger 
>>
>> This patch does not apply cleanly.
>>
>
> Here is the fix on top of u-boot/master, do you want me to post a new
> version of these patches?

It would be helpful to resend the series on top of current master.

Thanks,
-Joe
___
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

[Joe Hershberger]

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?

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

Re: [U-Boot] [PATCH v2 03/15] arm: Kconfig: Add support for AM43xx SoC specific Kconfig

[Heiko Schocher]

Hello Daniel,

Am 27.04.2016 um 22:09 schrieb Daniel Allred:

From: Madan Srinivas 

Adding support for AM43xx secure devices require the addition
of some SOC specific config options like the amount of memory
used by public ROM and the address of the entry point of u-boot
or SPL, as seen by the ROM code, for the image to be built
correctly.

This mandates the addition of am AM43xx CONFIG option and the
ARM Kconfig file has been modified to source this SOC Kconfig
file. Moving the TARGET_AM43XX_EVM config option to the SOC
KConfig and out of the arch/arm/Kconfig.

Updating defconfigs to add the CONFIG_AM43XX=y statement and
removing the #define CONFIG_AM43XX from the header file.

Signed-off-by: Madan Srinivas 
Signed-off-by: Daniel Allred 

Tested-by: Andreas Dannenberg 
---

V2:
  Update more defconfigs
  Replace CREATE_BOARD_SYMLINK with TI_I2C_BOARD_DETECT
  Rebase against latest master

  arch/arm/Kconfig  | 19 +--
  arch/arm/cpu/armv7/am33xx/Kconfig | 13 +

   ^^
Is this correct?


  configs/am437x_gp_evm_defconfig   |  1 +
  configs/am437x_sk_evm_defconfig   |  1 +
  configs/am43xx_evm_defconfig  |  1 +
  configs/am43xx_evm_ethboot_defconfig  |  1 +
  configs/am43xx_evm_qspiboot_defconfig |  1 +
  configs/am43xx_evm_usbhost_boot_defconfig |  1 +
  include/configs/am43xx_evm.h  |  2 --
  9 files changed, 32 insertions(+), 8 deletions(-)


Thanks for your patchseries looks very interesting.

May you have patches for am335x ? I ask, because I have an am335x based
board, which also uses HS boot mode, so I can test your patches, and
we can may sync our work.


diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 6b65d8e..6577572 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -381,12 +381,6 @@ config TARGET_AM335X_SL50
select DM
select DM_SERIAL

-config TARGET_AM43XX_EVM
-   bool "Support am43xx_evm"
-   select CPU_V7
-   select SUPPORT_SPL
-   select TI_I2C_BOARD_DETECT
-
  config TARGET_BAV335X
bool "Support bav335x"
select CPU_V7
@@ -507,6 +501,17 @@ config OMAP54XX
select CPU_V7
select SUPPORT_SPL

+config AM43XX
+   bool "AM43XX SoC"
+   select CPU_V7
+   select SUPPORT_SPL
+   help
+ Support for AM43xx SOC from Texas Instruments.
+ The AM43xx high performance SOC features a Cortex-A9
+ ARM core, a quad core PRU-ICSS for industrial Ethernet
+ protocols, dual camera support, optional 3D graphics
+ and an optional customer programmable secure boot.
+
  config RMOBILE
bool "Renesas ARM SoCs"
select CPU_V7
@@ -777,6 +782,8 @@ source "arch/arm/cpu/armv7/omap4/Kconfig"

  source "arch/arm/cpu/armv7/omap5/Kconfig"

+source "arch/arm/cpu/armv7/am33xx/Kconfig"
+
  source "arch/arm/mach-orion5x/Kconfig"

  source "arch/arm/cpu/armv7/rmobile/Kconfig"
diff --git a/arch/arm/cpu/armv7/am33xx/Kconfig 
b/arch/arm/cpu/armv7/am33xx/Kconfig
index 39759cd..dc51e9b 100644
--- a/arch/arm/cpu/armv7/am33xx/Kconfig
+++ b/arch/arm/cpu/armv7/am33xx/Kconfig
@@ -1,3 +1,15 @@
+if AM43XX


AM43XX in am33xx/Kconfig? This seems bogus to me.

bye,
Heiko

+config TARGET_AM43XX_EVM
+   bool "Support am43xx_evm"
+   select TI_I2C_BOARD_DETECT
+   help
+ This option specifies support for the AM43xx
+ GP and HS EVM development platforms.The AM437x
+ GP EVM is a standalone test, development, and
+ evaluation module system that enables developers
+ to write software and develop hardware around
+ an AM43xx processor subsystem.
+
  config ISW_ENTRY_ADDR
hex "Address in memory or XIP flash of bootloader entry point"
help
@@ -25,3 +37,4 @@ config PUB_ROM_DATA_SIZE
  image, this area is no longer used, and can be reclaimed
  for run time use by the boot image.
default 0x8400
+endif
diff --git a/configs/am437x_gp_evm_defconfig b/configs/am437x_gp_evm_defconfig
index 03b02ac..f036bc7 100644
--- a/configs/am437x_gp_evm_defconfig
+++ b/configs/am437x_gp_evm_defconfig
@@ -1,4 +1,5 @@
  CONFIG_ARM=y
+CONFIG_AM43XX=y
  CONFIG_TARGET_AM43XX_EVM=y
  CONFIG_DM_SERIAL=y
  CONFIG_DM_GPIO=y
diff --git a/configs/am437x_sk_evm_defconfig b/configs/am437x_sk_evm_defconfig
index 48ec91f..0251270 100644
--- a/configs/am437x_sk_evm_defconfig
+++ b/configs/am437x_sk_evm_defconfig
@@ -1,4 +1,5 @@
  CONFIG_ARM=y
+CONFIG_AM43XX=y
  CONFIG_TARGET_AM43XX_EVM=y
  CONFIG_DM_SERIAL=y
  CONFIG_DM_SPI=y
diff --git a/configs/am43xx_evm_defconfig b/configs/am43xx_evm_defconfig
index a6ae011..c9b6e6a 100644
--- a/configs/am43xx_evm_defconfig
+++ b/configs/am43xx_evm_defconfig
@@ -1,4 +1,5 @@
  CONFIG_ARM=y
+CONFIG_AM43XX=y
  CONFIG_TARGET_AM43XX_EVM=y
  CONFIG_SPL=y
  CONFIG_SYS_EXTRA_OPTIONS="SERIAL1,CONS_INDEX=1,NAND"
diff --git 

Re: [U-Boot] [PATCH] ARM: mx6: Enable MMC FS boot support

[Peng Fan]

Hi Marek,

On Thu, Apr 28, 2016 at 01:06:07AM +0200, Marek Vasut wrote:
>Enable support for booting U-Boot image from filesystem instead of some
>random offset on the SD card. This makes the board usable by putting the
>u-boot.img to first partition of the SD card and writing the SPL this way:
>$ dd if=u-boot-with-spl.imx of=/dev/sdX seek=2 bs=512

I once want to enable this for i.MX6UL, but was rejected.
Anyway I prefer load u-boot.img from filesystem.

>
>Signed-off-by: Marek Vasut 
>Cc: Stefano Babic 

Acked-by: Peng Fan 

Regards,
Peng.
>---
> include/configs/wandboard.h | 2 ++
> 1 file changed, 2 insertions(+)
>
>diff --git a/include/configs/wandboard.h b/include/configs/wandboard.h
>index 99f5c0c..fbce730 100644
>--- a/include/configs/wandboard.h
>+++ b/include/configs/wandboard.h
>@@ -14,6 +14,8 @@
> 
> #define CONFIG_SPL_LIBCOMMON_SUPPORT
> #define CONFIG_SPL_MMC_SUPPORT
>+#define CONFIG_SPL_FAT_SUPPORT
>+#define CONFIG_SPL_EXT_SUPPORT
> #include "imx6_spl.h"
> 
> #define MACH_TYPE_WANDBOARD   4412
>-- 
>2.7.0
>
>___
>U-Boot mailing list
>U-Boot@lists.denx.de
>http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] video: ipu_common: fix build error

[Peng Fan]

Some toolchains fail to build
"clk->rate = (u64)(clk->parent->rate * 16) / div;"
And the cast usage is wrong.

Use the following code to fix the issue,
"
  do_div(parent_rate, div);
  clk->rate = parent_rate;
"

Reported-by: Peter Robinson 
Signed-off-by: Peng Fan 
Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Tom Rini 
Cc: Anatolij Gustschin 
Cc: Peter Robinson 
---

Hi Peter,

 Please help test this patch to see whether this fix your issue or not.
 Thanks for pointing out this issue.

Thanks,
Peng.

 drivers/video/ipu_common.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/video/ipu_common.c b/drivers/video/ipu_common.c
index 36d4b23..5676a0f 100644
--- a/drivers/video/ipu_common.c
+++ b/drivers/video/ipu_common.c
@@ -352,7 +352,9 @@ static int ipu_pixel_clk_set_rate(struct clk *clk, unsigned 
long rate)
 */
__raw_writel((div / 16) << 16, DI_BS_CLKGEN1(clk->id));
 
-   clk->rate = (u64)(clk->parent->rate * 16) / div;
+   do_div(parent_rate, div);
+
+   clk->rate = parent_rate;
 
return 0;
 }
-- 
2.6.2

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

Re: [U-Boot] [PATCH] arm: socfpga: Add samtec VIN|ING board

[Marek Vasut]

On 04/28/2016 02:57 AM, Tom Rini wrote:
> On Thu, Apr 28, 2016 at 01:49:38AM +0200, Marek Vasut wrote:
>> On 04/13/2016 11:53 PM, Dinh Nguyen wrote:
>>> On 04/13/2016 07:24 AM, Marek Vasut wrote:
 Add support for board based on the popular Altera Cyclone V SoC.
 This board has the following properties:
  - 1 GiB of DRAM
  - 1 Gigabit ethernet
  - 1 USB gadget port
  - 1 USB host port with an on-board hub
  - 2 QSPI NORs connected to the Cadence QSPI core
  - Multiple I2C EEPROMs and one I2C temperature sensor

 Signed-off-by: Marek Vasut 
 Cc: Dinh Nguyen 
 Cc: Chin Liang See 
 ---
>>>
>>> [snip]
>>>
 --- /dev/null
 +++ b/include/configs/socfpga_vining_fpga.h
 @@ -0,0 +1,246 @@
 +/*
 + * Copyright (C) 2015 Marek Vasut 
 + *
 + * SPDX-License-Identifier:   GPL-2.0+
 + */
 +#ifndef __CONFIG_SAMTEC_VINING_FPGA_H__
 +#define __CONFIG_SAMTEC_VINING_FPGA_H__
 +
 +#include 
 +
 +/* U-Boot Commands */
 +#define CONFIG_SYS_NO_FLASH
 +#define CONFIG_DOS_PARTITION
 +#define CONFIG_FAT_WRITE
 +#define CONFIG_HW_WATCHDOG
 +
 +#define CONFIG_CMD_ASKENV
 +#define CONFIG_CMD_BOOTZ
 +#define CONFIG_CMD_CACHE
 +#define CONFIG_CMD_DFU
 +#define CONFIG_CMD_DHCP
 +#define CONFIG_CMD_EEPROM
 +#define CONFIG_CMD_EXT4
 +#define CONFIG_CMD_EXT4_WRITE
 +#define CONFIG_CMD_FAT
 +#define CONFIG_CMD_FS_GENERIC
 +#define CONFIG_CMD_GREPENV
 +#define CONFIG_CMD_LED
 +#define CONFIG_CMD_MII
 +#define CONFIG_CMD_MMC
 +#define CONFIG_CMD_PING
 +#define CONFIG_CMD_USB
 +#define CONFIG_CMD_USB_MASS_STORAGE
 +
>>>
>>> With my patch[1], you don't need all of those common configs, all you
>>> need is:
>>>
>>> #define CONFIG_CMD_DFU
>>> #define CONFIG_CMD_USB
>>> #define CONFIG_CMD_USB_MASS_STORAGE
>>
>> Well since there are changes in that, are you fine if I pick this board
>> as-is for next ?
> 
> You, or anyone else, picking up "old" board ports

This is a new board port, about two weeks old. Technology is moving fast
nowadays ;-)

> to apply now need to
> either ask people to re-spin the series or run moveconfig yourself to
> make sure that everything (except CMD_NAND) in cmd/Kconfig is done in
> the defconfig and not the config.h file.  For example, those last 3
> Kconfig'd right now.

CMD_EEPROM and CMD_LED are not I believe. Do you have any example of the
moveconfig , so I can try it ?


-- 
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] ARM: mx6: Enable MMC FS boot support

[Robert Nelson]

On Wed, Apr 27, 2016 at 7:54 PM, Tom Rini  wrote:

> On Thu, Apr 28, 2016 at 02:02:05AM +0200, Marek Vasut wrote:
> > On 04/28/2016 01:49 AM, Robert Nelson wrote:
> [snip]
> > > 1:
> > >
> > > Yeap, end users like to delete "MLO/u-boot.img" that was in the "fat"
> > > boot partition in our production beaglebone images specifically
> > > "2014-05-14"  which was shipped by default on rev C.  Thus
> > > soft-bricking/etc boards..
> >
> > OK, so because hypothetical user is an idiot, we should use sub-par
> > solution ? User can also be an idiot and generate U-Boot which is over 1
> > MiB, in which case I will turn your argument around against you. Sorry,
> > I am not buying this.
>
> No, real users.  Lots of them.  From nearly every "community" oriented
> board ever.  Which is why the distros also go for this method, point #2.
>
> > > http://beagleboard.org/latest-images
> > >
> > > Moving it under the 1MB location, has solved that problem.
> >
> > Until u-boot grows over 1 MiB. This only postponed the problem.
> > Since there is filesystem support in the SPL, we should use that
> > as a superior solution which doesn't suffer from this problem.
>
> I thought people were supposed to be aligning their first partitions
> much higher these days, 4MiB? as the general case for being safe
> regardless of the actual flash in the SD card.  Setting aside sandbox
> which I hope grows extremely large for testing purposes, I really hope
> U-Boot + SPL can always stay under 1MiB.  Our job is to boot the next
> stage.  If we get so large in our design of implementing things that we
> forget this, we have a problem.
>

I've followed the 4kb convention and fdisk defaults to 1MB offset: (even
thou we aren't dealing spinning disks)

https://www.ibm.com/developerworks/library/l-linux-on-4kb-sector-disks/

I haven't looked at the latest eMMC spec, but the eMMC 'boot' sections on
current silicon is only 1MB (x2)

mmcblk1boot0 179:16   01M  1 disk
mmcblk1boot1 179:24   01M  1 disk
mmcblk1  179:80  1.8G  0 disk

Regards,

-- 
Robert Nelson
https://rcn-ee.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: socfpga: Add samtec VIN|ING board

[Tom Rini]

On Thu, Apr 28, 2016 at 01:49:38AM +0200, Marek Vasut wrote:
> On 04/13/2016 11:53 PM, Dinh Nguyen wrote:
> > On 04/13/2016 07:24 AM, Marek Vasut wrote:
> >> Add support for board based on the popular Altera Cyclone V SoC.
> >> This board has the following properties:
> >>  - 1 GiB of DRAM
> >>  - 1 Gigabit ethernet
> >>  - 1 USB gadget port
> >>  - 1 USB host port with an on-board hub
> >>  - 2 QSPI NORs connected to the Cadence QSPI core
> >>  - Multiple I2C EEPROMs and one I2C temperature sensor
> >>
> >> Signed-off-by: Marek Vasut 
> >> Cc: Dinh Nguyen 
> >> Cc: Chin Liang See 
> >> ---
> > 
> > [snip]
> > 
> >> --- /dev/null
> >> +++ b/include/configs/socfpga_vining_fpga.h
> >> @@ -0,0 +1,246 @@
> >> +/*
> >> + * Copyright (C) 2015 Marek Vasut 
> >> + *
> >> + * SPDX-License-Identifier:   GPL-2.0+
> >> + */
> >> +#ifndef __CONFIG_SAMTEC_VINING_FPGA_H__
> >> +#define __CONFIG_SAMTEC_VINING_FPGA_H__
> >> +
> >> +#include 
> >> +
> >> +/* U-Boot Commands */
> >> +#define CONFIG_SYS_NO_FLASH
> >> +#define CONFIG_DOS_PARTITION
> >> +#define CONFIG_FAT_WRITE
> >> +#define CONFIG_HW_WATCHDOG
> >> +
> >> +#define CONFIG_CMD_ASKENV
> >> +#define CONFIG_CMD_BOOTZ
> >> +#define CONFIG_CMD_CACHE
> >> +#define CONFIG_CMD_DFU
> >> +#define CONFIG_CMD_DHCP
> >> +#define CONFIG_CMD_EEPROM
> >> +#define CONFIG_CMD_EXT4
> >> +#define CONFIG_CMD_EXT4_WRITE
> >> +#define CONFIG_CMD_FAT
> >> +#define CONFIG_CMD_FS_GENERIC
> >> +#define CONFIG_CMD_GREPENV
> >> +#define CONFIG_CMD_LED
> >> +#define CONFIG_CMD_MII
> >> +#define CONFIG_CMD_MMC
> >> +#define CONFIG_CMD_PING
> >> +#define CONFIG_CMD_USB
> >> +#define CONFIG_CMD_USB_MASS_STORAGE
> >> +
> > 
> > With my patch[1], you don't need all of those common configs, all you
> > need is:
> > 
> > #define CONFIG_CMD_DFU
> > #define CONFIG_CMD_USB
> > #define CONFIG_CMD_USB_MASS_STORAGE
> 
> Well since there are changes in that, are you fine if I pick this board
> as-is for next ?

You, or anyone else, picking up "old" board ports to apply now need to
either ask people to re-spin the series or run moveconfig yourself to
make sure that everything (except CMD_NAND) in cmd/Kconfig is done in
the defconfig and not the config.h file.  For example, those last 3
Kconfig'd right now.

-- 
Tom


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

Re: [U-Boot] [PATCH] ARM: mx6: Enable MMC FS boot support

[Tom Rini]

On Thu, Apr 28, 2016 at 02:02:05AM +0200, Marek Vasut wrote:
> On 04/28/2016 01:49 AM, Robert Nelson wrote:
[snip]
> > 1: 
> > 
> > Yeap, end users like to delete "MLO/u-boot.img" that was in the "fat"
> > boot partition in our production beaglebone images specifically
> > "2014-05-14"  which was shipped by default on rev C.  Thus
> > soft-bricking/etc boards..
> 
> OK, so because hypothetical user is an idiot, we should use sub-par
> solution ? User can also be an idiot and generate U-Boot which is over 1
> MiB, in which case I will turn your argument around against you. Sorry,
> I am not buying this.

No, real users.  Lots of them.  From nearly every "community" oriented
board ever.  Which is why the distros also go for this method, point #2.

> > http://beagleboard.org/latest-images
> > 
> > Moving it under the 1MB location, has solved that problem.
> 
> Until u-boot grows over 1 MiB. This only postponed the problem.
> Since there is filesystem support in the SPL, we should use that
> as a superior solution which doesn't suffer from this problem.

I thought people were supposed to be aligning their first partitions
much higher these days, 4MiB? as the general case for being safe
regardless of the actual flash in the SD card.  Setting aside sandbox
which I hope grows extremely large for testing purposes, I really hope
U-Boot + SPL can always stay under 1MiB.  Our job is to boot the next
stage.  If we get so large in our design of implementing things that we
forget this, we have a problem.

-- 
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 1/5] arm: include: Import unified.h from Linux kernel

[Marek Vasut]

On 04/09/2016 08:34 PM, Simon Glass wrote:
> Hi Marek,
> 
> On 20 March 2016 at 10:15, Marek Vasut  wrote:
>> Import unified.h from Linux kernel 4.4.6 , commit
>> 0d1912303e54ed1b2a371be0bba51c384dd57326 . This header file contains
>> macros used in libgcc functions in Linux kernel on ARM and will be
>> needed for the libgcc sync.
>>
>> Since unified.h defines the W(instr) macro, we must drop this from
>> the macro from memcpy.S , otherwise this triggers a warning about
>> symbol redefinition. In order to keep the changes to unified.h to
>> the minimum, tweak arch/arm/lib/Makefile such that it defines new
>> CONFIG_THUMB2_KERNEL macro, which is already checked by unified.h,
>> only if Thumb build is enabled, but the target does not support
>> Thumb2 . This way we can remove ad-hoc -DMEMSET_NO_THUMB_BUILD and
>> -DMEMCPY_NO_THUMB_BUILD and we do not change the logic.
>>
>> Signed-off-by: Marek Vasut 
>> Cc: Albert Aribaud 
>> Cc: Masahiro Yamada 
>> Cc: Simon Glass 
>> Cc: Tom Rini 
>> ---
>>  arch/arm/include/asm/assembler.h |   1 +
>>  arch/arm/include/asm/unified.h   | 140 
>> +++
>>  arch/arm/lib/Makefile|   6 +-
>>  arch/arm/lib/memcpy.S|   6 --
>>  4 files changed, 144 insertions(+), 9 deletions(-)
>>  create mode 100644 arch/arm/include/asm/unified.h
> 
> Reviewed-by: Simon Glass 
> 
> Can we use SPDX?

Yes, done. Thanks!

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] ARM: mx6: Enable MMC FS boot support

[Marek Vasut]

On 04/28/2016 01:49 AM, Robert Nelson wrote:
> 
> 
> On Wed, Apr 27, 2016 at 6:41 PM, Marek Vasut  > wrote:
> 
> On 04/28/2016 01:32 AM, Robert Nelson wrote:
> >
> >
> > On Wed, Apr 27, 2016 at 6:28 PM, Marek Vasut  
> > >> wrote:
> >
> > On 04/28/2016 01:16 AM, Tom Rini wrote:
> > > On Thu, Apr 28, 2016 at 01:06:07AM +0200, Marek Vasut wrote:
> > >
> > >> Enable support for booting U-Boot image from filesystem instead 
> of some
> > >> random offset on the SD card. This makes the board usable by 
> putting the
> > >> u-boot.img to first partition of the SD card and writing the SPL 
> this way:
> > >> $ dd if=u-boot-with-spl.imx of=/dev/sdX seek=2 bs=512
> > >
> > > Wait, you're still writing u-boot + SPL to the device and not 
> just SPL,
> > > but it's still preferring the filesystem one over the appended 
> one?
> > >
> >
> > Ha, good point. I should've written the 'SPL' file instead, which is
> > just the SPL without U-Boot. I don't want to install U-Boot to 
> random
> > offset on the SD card as it has the potential to corrupt data if the
> > u-boot binary changes in size.
> >
> > If I install u-boot image to random offset 138 blocks from the 
> start of
> > SD card, it will boot that, otherwise it will load from FS.
> >
> > I will update the commit message with the correct info, sorry.
> >
> >
> > Oh, we went thru this last year...
> >
> > http://lists.denx.de/pipermail/u-boot/2015-August/222061.html
> >
> > If your serious about changing "one" i.mx6 board, you need to change
> > them "all".
> 
> No, I do not have to change and will not change any other boards I
> cannot test.
> 
> 
> Okay, so if you can't test, are you going to keep an updated database:
> 
> boardx = boots this way?
> boardy = boots that way?

I fail to see why should I do any sort of database, this patch supports
both behaviors -- the old (broken) and the new (booting from FS). All
new boards should load u-boot from filesystem and old boards should be
updated as people have time.

> Otherwise, keep like the other i.mx6's..

I can pick "other mx6s" which boot from filesystem, like Novena, and I
will never allow that board to boot from ad-hoc offset.

> Or throw it under a "kconfig" so you can easily enable either mode.

Both modes are enabled, which should allow seamless conversion.
If there is another problem, it should be addressed.

> > Otherwise leave a 1MB hole on your mmc partition and dd spl/u-boot.img
> > as that works for ti/imx/sunxi...
> 
> No, this design is utterly broken. If U-Boot grows beyond 1 MiB, it will
> corrupt my data, silently. I will not have this. I would much rather see
> these broken designs go away and have everyone move to
> SPL in random location as mandated by BootROM (unfortunately) and
> u-boot.img on a filesystem. That way, u-boot.img can grow and shrink
> either way, without endangering any surrounding data.
> 
> Can you give me any argument why writing u-boot.img to random location
> on the SD card is better than storing it on a filesystem ?
> 
> 
> 1: 
> 
> Yeap, end users like to delete "MLO/u-boot.img" that was in the "fat"
> boot partition in our production beaglebone images specifically
> "2014-05-14"  which was shipped by default on rev C.  Thus
> soft-bricking/etc boards..

OK, so because hypothetical user is an idiot, we should use sub-par
solution ? User can also be an idiot and generate U-Boot which is over 1
MiB, in which case I will turn your argument around against you. Sorry,
I am not buying this.

> http://beagleboard.org/latest-images
> 
> Moving it under the 1MB location, has solved that problem.

Until u-boot grows over 1 MiB. This only postponed the problem.
Since there is filesystem support in the SPL, we should use that
as a superior solution which doesn't suffer from this problem.

> 2:
> 
> fedora/debian/ubuntu/yocto all expect this board to have these settings..

Sadly, they are all broken and need fixing, but they are broken because
historically, there was no filesystem support in SPL. I have had this
discussion with debian guys already about fixing it.

> Regards,
> 
> -- 
> Robert Nelson
> https://rcn-ee.com/


-- 
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] ARM: mx6: Enable MMC FS boot support

[Robert Nelson]

On Wed, Apr 27, 2016 at 6:41 PM, Marek Vasut  wrote:

> On 04/28/2016 01:32 AM, Robert Nelson wrote:
> >
> >
> > On Wed, Apr 27, 2016 at 6:28 PM, Marek Vasut  > > wrote:
> >
> > On 04/28/2016 01:16 AM, Tom Rini wrote:
> > > On Thu, Apr 28, 2016 at 01:06:07AM +0200, Marek Vasut wrote:
> > >
> > >> Enable support for booting U-Boot image from filesystem instead
> of some
> > >> random offset on the SD card. This makes the board usable by
> putting the
> > >> u-boot.img to first partition of the SD card and writing the SPL
> this way:
> > >> $ dd if=u-boot-with-spl.imx of=/dev/sdX seek=2 bs=512
> > >
> > > Wait, you're still writing u-boot + SPL to the device and not just
> SPL,
> > > but it's still preferring the filesystem one over the appended one?
> > >
> >
> > Ha, good point. I should've written the 'SPL' file instead, which is
> > just the SPL without U-Boot. I don't want to install U-Boot to random
> > offset on the SD card as it has the potential to corrupt data if the
> > u-boot binary changes in size.
> >
> > If I install u-boot image to random offset 138 blocks from the start
> of
> > SD card, it will boot that, otherwise it will load from FS.
> >
> > I will update the commit message with the correct info, sorry.
> >
> >
> > Oh, we went thru this last year...
> >
> > http://lists.denx.de/pipermail/u-boot/2015-August/222061.html
> >
> > If your serious about changing "one" i.mx6 board, you need to change
> > them "all".
>
> No, I do not have to change and will not change any other boards I
> cannot test.
>

Okay, so if you can't test, are you going to keep an updated database:

boardx = boots this way?
boardy = boots that way?

Otherwise, keep like the other i.mx6's..

Or throw it under a "kconfig" so you can easily enable either mode.


>
> > Otherwise leave a 1MB hole on your mmc partition and dd spl/u-boot.img
> > as that works for ti/imx/sunxi...
>
> No, this design is utterly broken. If U-Boot grows beyond 1 MiB, it will
> corrupt my data, silently. I will not have this. I would much rather see
> these broken designs go away and have everyone move to
> SPL in random location as mandated by BootROM (unfortunately) and
> u-boot.img on a filesystem. That way, u-boot.img can grow and shrink
> either way, without endangering any surrounding data.
>
> Can you give me any argument why writing u-boot.img to random location
> on the SD card is better than storing it on a filesystem ?
>

1:

Yeap, end users like to delete "MLO/u-boot.img" that was in the "fat" boot
partition in our production beaglebone images specifically "2014-05-14"
 which was shipped by default on rev C.  Thus soft-bricking/etc boards..

http://beagleboard.org/latest-images

Moving it under the 1MB location, has solved that problem.

2:

fedora/debian/ubuntu/yocto all expect this board to have these settings..

Regards,

-- 
Robert Nelson
https://rcn-ee.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: socfpga: Add samtec VIN|ING board

[Marek Vasut]

On 04/13/2016 11:53 PM, Dinh Nguyen wrote:
> On 04/13/2016 07:24 AM, Marek Vasut wrote:
>> Add support for board based on the popular Altera Cyclone V SoC.
>> This board has the following properties:
>>  - 1 GiB of DRAM
>>  - 1 Gigabit ethernet
>>  - 1 USB gadget port
>>  - 1 USB host port with an on-board hub
>>  - 2 QSPI NORs connected to the Cadence QSPI core
>>  - Multiple I2C EEPROMs and one I2C temperature sensor
>>
>> Signed-off-by: Marek Vasut 
>> Cc: Dinh Nguyen 
>> Cc: Chin Liang See 
>> ---
> 
> [snip]
> 
>> --- /dev/null
>> +++ b/include/configs/socfpga_vining_fpga.h
>> @@ -0,0 +1,246 @@
>> +/*
>> + * Copyright (C) 2015 Marek Vasut 
>> + *
>> + * SPDX-License-Identifier: GPL-2.0+
>> + */
>> +#ifndef __CONFIG_SAMTEC_VINING_FPGA_H__
>> +#define __CONFIG_SAMTEC_VINING_FPGA_H__
>> +
>> +#include 
>> +
>> +/* U-Boot Commands */
>> +#define CONFIG_SYS_NO_FLASH
>> +#define CONFIG_DOS_PARTITION
>> +#define CONFIG_FAT_WRITE
>> +#define CONFIG_HW_WATCHDOG
>> +
>> +#define CONFIG_CMD_ASKENV
>> +#define CONFIG_CMD_BOOTZ
>> +#define CONFIG_CMD_CACHE
>> +#define CONFIG_CMD_DFU
>> +#define CONFIG_CMD_DHCP
>> +#define CONFIG_CMD_EEPROM
>> +#define CONFIG_CMD_EXT4
>> +#define CONFIG_CMD_EXT4_WRITE
>> +#define CONFIG_CMD_FAT
>> +#define CONFIG_CMD_FS_GENERIC
>> +#define CONFIG_CMD_GREPENV
>> +#define CONFIG_CMD_LED
>> +#define CONFIG_CMD_MII
>> +#define CONFIG_CMD_MMC
>> +#define CONFIG_CMD_PING
>> +#define CONFIG_CMD_USB
>> +#define CONFIG_CMD_USB_MASS_STORAGE
>> +
> 
> With my patch[1], you don't need all of those common configs, all you
> need is:
> 
> #define CONFIG_CMD_DFU
> #define CONFIG_CMD_USB
> #define CONFIG_CMD_USB_MASS_STORAGE

Well since there are changes in that, are you fine if I pick this board
as-is for next ?

-- 
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 v5 4/4] usb: Change power-on / scanning timeout handling

[Marek Vasut]

On 04/02/2016 11:21 PM, Hans de Goede wrote:
> Hi,

Hi!

> On 04/02/2016 12:22 AM, Marek Vasut wrote:
>> On 03/15/2016 01:59 PM, Stefan Roese wrote:
>>> This patch changes the USB port scanning procedure and timeout
>>> handling in the following ways:
>>>
>>> a)
>>> The power-on delay in usb_hub_power_on() is now reduced to a value of
>>> max(100ms, "hub->desc.bPwrOn2PwrGood * 2"). The code does not wait
>>> using mdelay, instead usb_hub_power_on() will wait before querying
>>> the device in the scanning loop later. The total timeout for this
>>> hub, which is 1 second + "hub->desc.bPwrOn2PwrGood * 2" is calculated
>>> and will be used in the following per-port scanning loop as the timeout
>>> to detect active USB devices on this hub.
>>>
>>> b)
>>> Don't delay the minimum delay (for power to stabilize) in
>>> usb_hub_power_on(). Instead skip querying these devices in the scannig
>>> loop until the delay time is reached.
>>>
>>> c)
>>> The ports are now scanned in a quasi parallel way. The current code did
>>> wait for each (unconnected) port to reach its timeout and only then
>>> continue with the next port. This patch now changes this to scan all
>>> ports of all USB hubs quasi simultaneously. For this, all ports are
>>> added
>>> to a scanning list. This list is scanned until all ports are ready
>>> by either a) reaching the connection timeout (calculated earlier), or
>>> by b) detecting a USB device. This results in a faster USB scan time as
>>> the recursive scanning of USB hubs connected to the hub that's currently
>>> being scanned will start earlier.
>>>
>>> One small functional change to the original code is, that ports with
>>> overcurrent detection will now get rescanned multiple times
>>> (PORT_OVERCURRENT_MAX_SCAN_COUNT).
>>>
>>> Without this patch:
>>> starting USB...
>>> USB0:   USB EHCI 1.00
>>> scanning bus 0 for devices... 9 USB Device(s) found
>>>
>>> time: 20.163 seconds
>>>
>>> With this patch:
>>> starting USB...
>>> USB0:   USB EHCI 1.00
>>> scanning bus 0 for devices... 9 USB Device(s) found
>>>
>>> time: 1.822 seconds
>>>
>>> So ~18.3 seconds of USB scanning time reduction.
>>>
>>> Signed-off-by: Stefan Roese 
>>> Acked-by: Hans de Goede 
>>> Tested-by: Stephen Warren 
>>
>> This breaks DWC2 on SoCkit, I can no longer detect any USB device.
>> USB works without this patch though. Ideas?
> 
> Have you tried simply adding a large sleep before the
> initial uart, or doing an "usb reset" after the initial
> scan ?

Yeah, that doesn't help. But I also sent a few fixes for the DWC2
controller, so let's see. I also finally got Stefan a working board,
so he can start poking around :)

> The biggest change here is the change in timing ...
> 
> Also try defining debug printf in usb_hub.c and see what
> output you get ?

I'll be offloading this to Stefan :)

> Regards,
> 
> Hans


-- 
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] ARM: mx6: Enable MMC FS boot support

[Marek Vasut]

On 04/28/2016 01:32 AM, Robert Nelson wrote:
> 
> 
> On Wed, Apr 27, 2016 at 6:28 PM, Marek Vasut  > wrote:
> 
> On 04/28/2016 01:16 AM, Tom Rini wrote:
> > On Thu, Apr 28, 2016 at 01:06:07AM +0200, Marek Vasut wrote:
> >
> >> Enable support for booting U-Boot image from filesystem instead of some
> >> random offset on the SD card. This makes the board usable by putting 
> the
> >> u-boot.img to first partition of the SD card and writing the SPL this 
> way:
> >> $ dd if=u-boot-with-spl.imx of=/dev/sdX seek=2 bs=512
> >
> > Wait, you're still writing u-boot + SPL to the device and not just SPL,
> > but it's still preferring the filesystem one over the appended one?
> >
> 
> Ha, good point. I should've written the 'SPL' file instead, which is
> just the SPL without U-Boot. I don't want to install U-Boot to random
> offset on the SD card as it has the potential to corrupt data if the
> u-boot binary changes in size.
> 
> If I install u-boot image to random offset 138 blocks from the start of
> SD card, it will boot that, otherwise it will load from FS.
> 
> I will update the commit message with the correct info, sorry.
> 
> 
> Oh, we went thru this last year...
> 
> http://lists.denx.de/pipermail/u-boot/2015-August/222061.html
> 
> If your serious about changing "one" i.mx6 board, you need to change
> them "all".

No, I do not have to change and will not change any other boards I
cannot test.

> Otherwise leave a 1MB hole on your mmc partition and dd spl/u-boot.img
> as that works for ti/imx/sunxi...

No, this design is utterly broken. If U-Boot grows beyond 1 MiB, it will
corrupt my data, silently. I will not have this. I would much rather see
these broken designs go away and have everyone move to
SPL in random location as mandated by BootROM (unfortunately) and
u-boot.img on a filesystem. That way, u-boot.img can grow and shrink
either way, without endangering any surrounding data.

Can you give me any argument why writing u-boot.img to random location
on the SD card is better than storing it on a filesystem ?

> Regards,
> 
> -- 
> Robert Nelson
> https://rcn-ee.com/


-- 
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] ARM: mx6: Enable MMC FS boot support

[Robert Nelson]

On Wed, Apr 27, 2016 at 6:28 PM, Marek Vasut  wrote:

> On 04/28/2016 01:16 AM, Tom Rini wrote:
> > On Thu, Apr 28, 2016 at 01:06:07AM +0200, Marek Vasut wrote:
> >
> >> Enable support for booting U-Boot image from filesystem instead of some
> >> random offset on the SD card. This makes the board usable by putting the
> >> u-boot.img to first partition of the SD card and writing the SPL this
> way:
> >> $ dd if=u-boot-with-spl.imx of=/dev/sdX seek=2 bs=512
> >
> > Wait, you're still writing u-boot + SPL to the device and not just SPL,
> > but it's still preferring the filesystem one over the appended one?
> >
>
> Ha, good point. I should've written the 'SPL' file instead, which is
> just the SPL without U-Boot. I don't want to install U-Boot to random
> offset on the SD card as it has the potential to corrupt data if the
> u-boot binary changes in size.
>
> If I install u-boot image to random offset 138 blocks from the start of
> SD card, it will boot that, otherwise it will load from FS.
>
> I will update the commit message with the correct info, sorry.
>

Oh, we went thru this last year...

http://lists.denx.de/pipermail/u-boot/2015-August/222061.html

If your serious about changing "one" i.mx6 board, you need to change them
"all".

Otherwise leave a 1MB hole on your mmc partition and dd spl/u-boot.img as
that works for ti/imx/sunxi...

Regards,

-- 
Robert Nelson
https://rcn-ee.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH V2] ARM: mx6: Enable MMC FS boot support on Wandboard

[Marek Vasut]

Enable support for booting U-Boot image from filesystem instead of some
random offset on the SD card. This makes the board usable by putting the
u-boot.img to first partition of the SD card and writing the SPL this way:
$ dd if=SPL of=/dev/sdX seek=2 bs=512

Signed-off-by: Marek Vasut 
Cc: Stefano Babic 
---
V2: Update the commit message to specify wandboard
Update the commit message dd command to write just the SPL
---
 include/configs/wandboard.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/configs/wandboard.h b/include/configs/wandboard.h
index 99f5c0c..fbce730 100644
--- a/include/configs/wandboard.h
+++ b/include/configs/wandboard.h
@@ -14,6 +14,8 @@
 
 #define CONFIG_SPL_LIBCOMMON_SUPPORT
 #define CONFIG_SPL_MMC_SUPPORT
+#define CONFIG_SPL_FAT_SUPPORT
+#define CONFIG_SPL_EXT_SUPPORT
 #include "imx6_spl.h"
 
 #define MACH_TYPE_WANDBOARD4412
-- 
2.7.0

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

Re: [U-Boot] [PATCH] ARM: mx6: Enable MMC FS boot support

[Marek Vasut]

On 04/28/2016 01:16 AM, Tom Rini wrote:
> On Thu, Apr 28, 2016 at 01:06:07AM +0200, Marek Vasut wrote:
> 
>> Enable support for booting U-Boot image from filesystem instead of some
>> random offset on the SD card. This makes the board usable by putting the
>> u-boot.img to first partition of the SD card and writing the SPL this way:
>> $ dd if=u-boot-with-spl.imx of=/dev/sdX seek=2 bs=512
> 
> Wait, you're still writing u-boot + SPL to the device and not just SPL,
> but it's still preferring the filesystem one over the appended one?
> 

Ha, good point. I should've written the 'SPL' file instead, which is
just the SPL without U-Boot. I don't want to install U-Boot to random
offset on the SD card as it has the potential to corrupt data if the
u-boot binary changes in size.

If I install u-boot image to random offset 138 blocks from the start of
SD card, it will boot that, otherwise it will load from FS.

I will update the commit message with the correct info, sorry.

-- 
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] ARM: mx6: Enable MMC FS boot support

[Tom Rini]

On Thu, Apr 28, 2016 at 01:06:07AM +0200, Marek Vasut wrote:

> Enable support for booting U-Boot image from filesystem instead of some
> random offset on the SD card. This makes the board usable by putting the
> u-boot.img to first partition of the SD card and writing the SPL this way:
> $ dd if=u-boot-with-spl.imx of=/dev/sdX seek=2 bs=512

Wait, you're still writing u-boot + SPL to the device and not just SPL,
but it's still preferring the filesystem one over the appended one?

-- 
Tom


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

[U-Boot] [PATCH] ARM: mx6: Enable MMC FS boot support

[Marek Vasut]

Enable support for booting U-Boot image from filesystem instead of some
random offset on the SD card. This makes the board usable by putting the
u-boot.img to first partition of the SD card and writing the SPL this way:
$ dd if=u-boot-with-spl.imx of=/dev/sdX seek=2 bs=512

Signed-off-by: Marek Vasut 
Cc: Stefano Babic 
---
 include/configs/wandboard.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/configs/wandboard.h b/include/configs/wandboard.h
index 99f5c0c..fbce730 100644
--- a/include/configs/wandboard.h
+++ b/include/configs/wandboard.h
@@ -14,6 +14,8 @@
 
 #define CONFIG_SPL_LIBCOMMON_SUPPORT
 #define CONFIG_SPL_MMC_SUPPORT
+#define CONFIG_SPL_FAT_SUPPORT
+#define CONFIG_SPL_EXT_SUPPORT
 #include "imx6_spl.h"
 
 #define MACH_TYPE_WANDBOARD4412
-- 
2.7.0

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

[U-Boot] [PATCH] ARM: mx6: Enable STDIO deregistering on Novena

[Marek Vasut]

Novena supports USB keyboard, which is a pluggable device and can be
unplugged. Thus, we need to be able to deregister it's stdio device.

Signed-off-by: Marek Vasut 
Cc: Stefano Babic 
---
 include/configs/novena.h | 1 +
 1 file changed, 1 insertion(+)

NOTE: Stefano, this is 2016.05 material , please apply for this release.

diff --git a/include/configs/novena.h b/include/configs/novena.h
index cfb92d6..e938fbc 100644
--- a/include/configs/novena.h
+++ b/include/configs/novena.h
@@ -150,6 +150,7 @@
 #define CONFIG_USB_EHCI_MX6
 #define CONFIG_USB_STORAGE
 #define CONFIG_USB_KEYBOARD
+#define CONFIG_SYS_STDIO_DEREGISTER
 #define CONFIG_SYS_USB_EVENT_POLL_VIA_CONTROL_EP
 #define CONFIG_USB_HOST_ETHER
 #define CONFIG_USB_ETHER_ASIX
-- 
2.7.0

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

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

[Tom Rini]

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 
---
 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

[U-Boot] [PATCH 2/2] mtd: cqspi: Simplify indirect read code

[Marek Vasut]

The indirect read code is a pile of nastiness. This patch replaces
the whole unmaintainable indirect read implementation with the one
from upcoming Linux CQSPI driver, which went through multiple rounds
of thorough review and testing. 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. There is no
speed change of the read operation.

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 
---
 drivers/spi/cadence_qspi_apb.c | 124 ++---
 1 file changed, 53 insertions(+), 71 deletions(-)

diff --git a/drivers/spi/cadence_qspi_apb.c b/drivers/spi/cadence_qspi_apb.c
index 00a50cb..ac47c6f 100644
--- a/drivers/spi/cadence_qspi_apb.c
+++ b/drivers/spi/cadence_qspi_apb.c
@@ -193,64 +193,6 @@ static unsigned int cadence_qspi_apb_cmd2addr(const 
unsigned char *addr_buf,
return addr;
 }
 
-static void cadence_qspi_apb_read_fifo_data(void *dest,
-   const void *src_ahb_addr, unsigned int bytes)
-{
-   unsigned int temp;
-   int remaining = bytes;
-   unsigned int *dest_ptr = (unsigned int *)dest;
-   unsigned int *src_ptr = (unsigned int *)src_ahb_addr;
-
-   while (remaining >= sizeof(dest_ptr)) {
-   *dest_ptr = readl(src_ptr);
-   remaining -= sizeof(src_ptr);
-   dest_ptr++;
-   }
-   if (remaining) {
-   /* dangling bytes */
-   temp = readl(src_ptr);
-   memcpy(dest_ptr, , remaining);
-   }
-
-   return;
-}
-
-/* Read from SRAM FIFO with polling SRAM fill level. */
-static int qspi_read_sram_fifo_poll(const void *reg_base, void *dest_addr,
-   const void *src_addr,  unsigned int num_bytes)
-{
-   unsigned int remaining = num_bytes;
-   unsigned int retry;
-   unsigned int sram_level = 0;
-   unsigned char *dest = (unsigned char *)dest_addr;
-
-   while (remaining > 0) {
-   retry = CQSPI_REG_RETRY;
-   while (retry--) {
-   sram_level = CQSPI_GET_RD_SRAM_LEVEL(reg_base);
-   if (sram_level)
-   break;
-   udelay(1);
-   }
-
-   if (!retry) {
-   printf("QSPI: No receive data after polling for %d 
times\n",
-  CQSPI_REG_RETRY);
-   return -1;
-   }
-
-   sram_level *= CQSPI_FIFO_WIDTH;
-   sram_level = sram_level > remaining ? remaining : sram_level;
-
-   /* Read data from FIFO. */
-   cadence_qspi_apb_read_fifo_data(dest, src_addr, sram_level);
-   dest += sram_level;
-   remaining -= sram_level;
-   udelay(1);
-   }
-   return 0;
-}
-
 void cadence_qspi_apb_controller_enable(void *reg_base)
 {
unsigned int reg;
@@ -679,40 +621,80 @@ int cadence_qspi_apb_indirect_read_setup(struct 
cadence_spi_platdata *plat,
return 0;
 }
 
+static u32 cadence_qspi_get_rd_sram_level(struct cadence_spi_platdata *plat)
+{
+   u32 reg = readl(plat->regbase + CQSPI_REG_SDRAMLEVEL);
+   reg >>= CQSPI_REG_SDRAMLEVEL_RD_LSB;
+   return reg & CQSPI_REG_SDRAMLEVEL_RD_MASK;
+}
+
+static int cadence_qspi_wait_for_data(struct cadence_spi_platdata *plat)
+{
+   unsigned int timeout = 1;
+   u32 reg;
+
+   while (timeout--) {
+   reg = cadence_qspi_get_rd_sram_level(plat);
+   if (reg)
+   return reg;
+   udelay(1);
+   }
+
+   return -ETIMEDOUT;
+}
+
 int cadence_qspi_apb_indirect_read_execute(struct cadence_spi_platdata *plat,
-   unsigned int rxlen, u8 *rxbuf)
+   unsigned int n_rx, u8 *rxbuf)
 {
-   unsigned int reg;
+   unsigned int remaining = n_rx;
+   unsigned int bytes_to_read = 0;
+   int ret;
 
-   writel(rxlen, plat->regbase + CQSPI_REG_INDIRECTRDBYTES);
+   writel(n_rx, plat->regbase + CQSPI_REG_INDIRECTRDBYTES);
 
/* Start the indirect read transfer */
writel(CQSPI_REG_INDIRECTRD_START_MASK,
   plat->regbase + CQSPI_REG_INDIRECTRD);
 
-   if (qspi_read_sram_fifo_poll(plat->regbase, (void *)rxbuf,
-(const void *)plat->ahbbase, rxlen))
-   goto failrd;
+   while (remaining > 0) {
+   ret = cadence_qspi_wait_for_data(plat);
+   if (ret < 0) {
+   printf("Indirect write timed out (%i)\n", ret);
+   goto failrd;
+   }
 
-   /* Check flash indirect controller */
-   reg = readl(plat->regbase 

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

[Marek Vasut]

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 
---
 drivers/spi/cadence_qspi_apb.c | 122 +
 1 file changed, 26 insertions(+), 96 deletions(-)

diff --git a/drivers/spi/cadence_qspi_apb.c b/drivers/spi/cadence_qspi_apb.c
index 7786dd6..00a50cb 100644
--- a/drivers/spi/cadence_qspi_apb.c
+++ b/drivers/spi/cadence_qspi_apb.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "cadence_qspi.h"
 
 #define CQSPI_REG_POLL_US  (1) /* 1us */
@@ -214,32 +215,6 @@ static void cadence_qspi_apb_read_fifo_data(void *dest,
return;
 }
 
-static void cadence_qspi_apb_write_fifo_data(const void *dest_ahb_addr,
-   const void *src, unsigned int bytes)
-{
-   unsigned int temp = 0;
-   int i;
-   int remaining = bytes;
-   unsigned int *dest_ptr = (unsigned int *)dest_ahb_addr;
-   unsigned int *src_ptr = (unsigned int *)src;
-
-   while (remaining >= CQSPI_FIFO_WIDTH) {
-   for (i = CQSPI_FIFO_WIDTH/sizeof(src_ptr) - 1; i >= 0; i--)
-   writel(*(src_ptr+i), dest_ptr+i);
-   src_ptr += CQSPI_FIFO_WIDTH/sizeof(src_ptr);
-   remaining -= CQSPI_FIFO_WIDTH;
-   }
-   if (remaining) {
-   /* dangling bytes */
-   i = remaining/sizeof(dest_ptr);
-   memcpy(, src_ptr+i, remaining % sizeof(dest_ptr));
-   writel(temp, dest_ptr+i);
-   for (--i; i >= 0; i--)
-   writel(*(src_ptr+i), dest_ptr+i);
-   }
-   return;
-}
-
 /* Read from SRAM FIFO with polling SRAM fill level. */
 static int qspi_read_sram_fifo_poll(const void *reg_base, void *dest_addr,
const void *src_addr,  unsigned int num_bytes)
@@ -276,44 +251,6 @@ static int qspi_read_sram_fifo_poll(const void *reg_base, 
void *dest_addr,
return 0;
 }
 
-/* Write to SRAM FIFO with polling SRAM fill level. */
-static int qpsi_write_sram_fifo_push(struct cadence_spi_platdata *plat,
-   const void *src_addr, unsigned int num_bytes)
-{
-   const void *reg_base = plat->regbase;
-   void *dest_addr = plat->ahbbase;
-   unsigned int retry = CQSPI_REG_RETRY;
-   unsigned int sram_level;
-   unsigned int wr_bytes;
-   unsigned char *src = (unsigned char *)src_addr;
-   int remaining = num_bytes;
-   unsigned int page_size = plat->page_size;
-   unsigned int sram_threshold_words = CQSPI_REG_SRAM_THRESHOLD_WORDS;
-
-   while (remaining > 0) {
-   retry = CQSPI_REG_RETRY;
-   while (retry--) {
-   sram_level = CQSPI_GET_WR_SRAM_LEVEL(reg_base);
-   if (sram_level <= sram_threshold_words)
-   break;
-   }
-   if (!retry) {
-   printf("QSPI: SRAM fill level (0x%08x) not hit lower 
expected level (0x%08x)",
-  sram_level, sram_threshold_words);
-   return -1;
-   }
-   /* Write a page or remaining bytes. */
-   wr_bytes = (remaining > page_size) ?
-   page_size : remaining;
-
-   cadence_qspi_apb_write_fifo_data(dest_addr, src, wr_bytes);
-   src += wr_bytes;
-   remaining -= wr_bytes;
-   }
-
-   return 0;
-}
-
 void cadence_qspi_apb_controller_enable(void *reg_base)
 {
unsigned int reg;
@@ -810,48 +747,41 @@ int cadence_qspi_apb_indirect_write_setup(struct 
cadence_spi_platdata *plat,
 }
 
 int cadence_qspi_apb_indirect_write_execute(struct cadence_spi_platdata *plat,
-   unsigned int txlen, const u8 *txbuf)
+   unsigned int n_tx, const u8 *txbuf)
 {
-   unsigned int reg = 0;
-   unsigned int retry;
+   unsigned int page_size = plat->page_size;
+   unsigned int remaining = n_tx;
+   unsigned int 

[U-Boot] [PATCH 0/2] Initial support for S32V234 - version 2

[Eddy Petrișor]

Here is the second version of the proposed inital support for S32V234.
Please excuse the delay, I was kept busy by some unplanned events.

Tom:
I did not spllit the MMU definitions into a separate file since they are not
used anywhere else yet.

Eddy Petrișor (1):
  armv8: s32v234: Introduce basic support for s32v234evb

Stoica Cosmin-Stefan (1):
  serial: Introduce linflex uart support

 arch/arm/Kconfig|   5 +
 arch/arm/cpu/armv8/Makefile |   1 +
 arch/arm/cpu/armv8/s32v234/Makefile |   8 +
 arch/arm/cpu/armv8/s32v234/cpu.c|  97 +++
 arch/arm/cpu/armv8/s32v234/cpu.h|   8 +
 arch/arm/cpu/armv8/s32v234/generic.c| 350 
 arch/arm/include/asm/arch-s32v234/clock.h   |  34 +++
 arch/arm/include/asm/arch-s32v234/ddr.h | 157 +++
 arch/arm/include/asm/arch-s32v234/imx-regs.h| 329 ++
 arch/arm/include/asm/arch-s32v234/lpddr2.h  |  75 +
 arch/arm/include/asm/arch-s32v234/mc_cgm_regs.h | 254 +
 arch/arm/include/asm/arch-s32v234/mc_me_regs.h  | 199 ++
 arch/arm/include/asm/arch-s32v234/mc_rgm_regs.h |  31 +++
 arch/arm/include/asm/arch-s32v234/mmdc.h|  89 ++
 arch/arm/include/asm/arch-s32v234/siul.h| 150 ++
 board/freescale/s32v234evb/Kconfig  |  23 ++
 board/freescale/s32v234evb/MAINTAINERS  |   8 +
 board/freescale/s32v234evb/Makefile |  11 +
 board/freescale/s32v234evb/clock.c  | 344 +++
 board/freescale/s32v234evb/lpddr2.c | 137 ++
 board/freescale/s32v234evb/s32v234evb.c | 183 +
 board/freescale/s32v234evb/s32v234evb.cfg   |  29 ++
 configs/s32v234evb_defconfig|   6 +
 drivers/mmc/fsl_esdhc.c |  10 +-
 drivers/serial/Makefile |   1 +
 drivers/serial/serial_linflexuart.c | 274 +++
 include/configs/s32v234evb.h| 305 +
 27 files changed, 3113 insertions(+), 5 deletions(-)
 create mode 100644 arch/arm/cpu/armv8/s32v234/Makefile
 create mode 100644 arch/arm/cpu/armv8/s32v234/cpu.c
 create mode 100644 arch/arm/cpu/armv8/s32v234/cpu.h
 create mode 100644 arch/arm/cpu/armv8/s32v234/generic.c
 create mode 100644 arch/arm/include/asm/arch-s32v234/clock.h
 create mode 100644 arch/arm/include/asm/arch-s32v234/ddr.h
 create mode 100644 arch/arm/include/asm/arch-s32v234/imx-regs.h
 create mode 100644 arch/arm/include/asm/arch-s32v234/lpddr2.h
 create mode 100644 arch/arm/include/asm/arch-s32v234/mc_cgm_regs.h
 create mode 100644 arch/arm/include/asm/arch-s32v234/mc_me_regs.h
 create mode 100644 arch/arm/include/asm/arch-s32v234/mc_rgm_regs.h
 create mode 100644 arch/arm/include/asm/arch-s32v234/mmdc.h
 create mode 100644 arch/arm/include/asm/arch-s32v234/siul.h
 create mode 100644 board/freescale/s32v234evb/Kconfig
 create mode 100644 board/freescale/s32v234evb/MAINTAINERS
 create mode 100644 board/freescale/s32v234evb/Makefile
 create mode 100644 board/freescale/s32v234evb/clock.c
 create mode 100644 board/freescale/s32v234evb/lpddr2.c
 create mode 100644 board/freescale/s32v234evb/s32v234evb.c
 create mode 100644 board/freescale/s32v234evb/s32v234evb.cfg
 create mode 100644 configs/s32v234evb_defconfig
 create mode 100644 drivers/serial/serial_linflexuart.c
 create mode 100644 include/configs/s32v234evb.h

-- 
2.1.4

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

[U-Boot] [PATCH v2 0/2] Initial S32V234 support - version 2 (with notes now)

[Eddy Petrișor]

Here are the reworked patches for initial S32V234 support, including the git
notes in both patches.

Sorry for the repost.

Eddy Petrișor (1):
  armv8: s32v234: Introduce basic support for s32v234evb

Stoica Cosmin-Stefan (1):
  serial: Introduce linflex uart support

 arch/arm/Kconfig|   5 +
 arch/arm/cpu/armv8/Makefile |   1 +
 arch/arm/cpu/armv8/s32v234/Makefile |   8 +
 arch/arm/cpu/armv8/s32v234/cpu.c|  97 +++
 arch/arm/cpu/armv8/s32v234/cpu.h|   8 +
 arch/arm/cpu/armv8/s32v234/generic.c| 350 
 arch/arm/include/asm/arch-s32v234/clock.h   |  34 +++
 arch/arm/include/asm/arch-s32v234/ddr.h | 157 +++
 arch/arm/include/asm/arch-s32v234/imx-regs.h| 329 ++
 arch/arm/include/asm/arch-s32v234/lpddr2.h  |  75 +
 arch/arm/include/asm/arch-s32v234/mc_cgm_regs.h | 254 +
 arch/arm/include/asm/arch-s32v234/mc_me_regs.h  | 199 ++
 arch/arm/include/asm/arch-s32v234/mc_rgm_regs.h |  31 +++
 arch/arm/include/asm/arch-s32v234/mmdc.h|  89 ++
 arch/arm/include/asm/arch-s32v234/siul.h| 150 ++
 board/freescale/s32v234evb/Kconfig  |  23 ++
 board/freescale/s32v234evb/MAINTAINERS  |   8 +
 board/freescale/s32v234evb/Makefile |  11 +
 board/freescale/s32v234evb/clock.c  | 344 +++
 board/freescale/s32v234evb/lpddr2.c | 137 ++
 board/freescale/s32v234evb/s32v234evb.c | 183 +
 board/freescale/s32v234evb/s32v234evb.cfg   |  29 ++
 configs/s32v234evb_defconfig|   6 +
 drivers/mmc/fsl_esdhc.c |  10 +-
 drivers/serial/Makefile |   1 +
 drivers/serial/serial_linflexuart.c | 274 +++
 include/configs/s32v234evb.h| 305 +
 27 files changed, 3113 insertions(+), 5 deletions(-)
 create mode 100644 arch/arm/cpu/armv8/s32v234/Makefile
 create mode 100644 arch/arm/cpu/armv8/s32v234/cpu.c
 create mode 100644 arch/arm/cpu/armv8/s32v234/cpu.h
 create mode 100644 arch/arm/cpu/armv8/s32v234/generic.c
 create mode 100644 arch/arm/include/asm/arch-s32v234/clock.h
 create mode 100644 arch/arm/include/asm/arch-s32v234/ddr.h
 create mode 100644 arch/arm/include/asm/arch-s32v234/imx-regs.h
 create mode 100644 arch/arm/include/asm/arch-s32v234/lpddr2.h
 create mode 100644 arch/arm/include/asm/arch-s32v234/mc_cgm_regs.h
 create mode 100644 arch/arm/include/asm/arch-s32v234/mc_me_regs.h
 create mode 100644 arch/arm/include/asm/arch-s32v234/mc_rgm_regs.h
 create mode 100644 arch/arm/include/asm/arch-s32v234/mmdc.h
 create mode 100644 arch/arm/include/asm/arch-s32v234/siul.h
 create mode 100644 board/freescale/s32v234evb/Kconfig
 create mode 100644 board/freescale/s32v234evb/MAINTAINERS
 create mode 100644 board/freescale/s32v234evb/Makefile
 create mode 100644 board/freescale/s32v234evb/clock.c
 create mode 100644 board/freescale/s32v234evb/lpddr2.c
 create mode 100644 board/freescale/s32v234evb/s32v234evb.c
 create mode 100644 board/freescale/s32v234evb/s32v234evb.cfg
 create mode 100644 configs/s32v234evb_defconfig
 create mode 100644 drivers/serial/serial_linflexuart.c
 create mode 100644 include/configs/s32v234evb.h

-- 
2.1.4

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

[U-Boot] [PATCH v2 2/2] armv8: s32v234: Introduce basic support for s32v234evb

[Eddy Petrișor]

From: Eddy Petrișor 

Add initial support for NXP's S32V234 SoC and S32V234EVB board.

The S32V230 family is designed to support computation-intensive applications
for image processing. The S32V234, as part of the S32V230 family, is a
high-performance automotive processor designed to support safe
computation-intensive applications in the area of vision and sensor fusion.

Code originally writen by:
Original-signed-off-by: Stoica Cosmin-Stefan 
Original-signed-off-by: Mihaela Martinas 
Original-signed-off-by: Eddy Petrișor 

Signed-off-by: Eddy Petrișor 
---

Notes:
Changes in v2:
- Added support for device model. Compatibility with non-DM code is kept
  for easier synchronization with the code on the vendor branch where the
  conversion to DM is not done for all boards.
- remove TODO-s
- remove '#if 0'-ed code
- switched to SPDX headers
- removed uselss guard around 'DECLARE_GLOBAL_DATA_PTR;'
- replaced 'CONFIG_SYS_FSL' with 'S32V234' in defines for MMU bases and 
sizes
- reset_cpu now says it's not implemented
- moved OF_LIBFDT and BOOTZ config options to Kconfig

 arch/arm/Kconfig|   5 +
 arch/arm/cpu/armv8/Makefile |   1 +
 arch/arm/cpu/armv8/s32v234/Makefile |   8 +
 arch/arm/cpu/armv8/s32v234/cpu.c|  97 +++
 arch/arm/cpu/armv8/s32v234/cpu.h|   8 +
 arch/arm/cpu/armv8/s32v234/generic.c| 350 
 arch/arm/include/asm/arch-s32v234/clock.h   |  34 +++
 arch/arm/include/asm/arch-s32v234/ddr.h | 157 +++
 arch/arm/include/asm/arch-s32v234/imx-regs.h| 329 ++
 arch/arm/include/asm/arch-s32v234/lpddr2.h  |  75 +
 arch/arm/include/asm/arch-s32v234/mc_cgm_regs.h | 254 +
 arch/arm/include/asm/arch-s32v234/mc_me_regs.h  | 199 ++
 arch/arm/include/asm/arch-s32v234/mc_rgm_regs.h |  31 +++
 arch/arm/include/asm/arch-s32v234/mmdc.h|  89 ++
 arch/arm/include/asm/arch-s32v234/siul.h| 150 ++
 board/freescale/s32v234evb/Kconfig  |  23 ++
 board/freescale/s32v234evb/MAINTAINERS  |   8 +
 board/freescale/s32v234evb/Makefile |  11 +
 board/freescale/s32v234evb/clock.c  | 344 +++
 board/freescale/s32v234evb/lpddr2.c | 137 ++
 board/freescale/s32v234evb/s32v234evb.c | 183 +
 board/freescale/s32v234evb/s32v234evb.cfg   |  29 ++
 configs/s32v234evb_defconfig|   6 +
 drivers/mmc/fsl_esdhc.c |  10 +-
 include/configs/s32v234evb.h| 305 +
 25 files changed, 2838 insertions(+), 5 deletions(-)
 create mode 100644 arch/arm/cpu/armv8/s32v234/Makefile
 create mode 100644 arch/arm/cpu/armv8/s32v234/cpu.c
 create mode 100644 arch/arm/cpu/armv8/s32v234/cpu.h
 create mode 100644 arch/arm/cpu/armv8/s32v234/generic.c
 create mode 100644 arch/arm/include/asm/arch-s32v234/clock.h
 create mode 100644 arch/arm/include/asm/arch-s32v234/ddr.h
 create mode 100644 arch/arm/include/asm/arch-s32v234/imx-regs.h
 create mode 100644 arch/arm/include/asm/arch-s32v234/lpddr2.h
 create mode 100644 arch/arm/include/asm/arch-s32v234/mc_cgm_regs.h
 create mode 100644 arch/arm/include/asm/arch-s32v234/mc_me_regs.h
 create mode 100644 arch/arm/include/asm/arch-s32v234/mc_rgm_regs.h
 create mode 100644 arch/arm/include/asm/arch-s32v234/mmdc.h
 create mode 100644 arch/arm/include/asm/arch-s32v234/siul.h
 create mode 100644 board/freescale/s32v234evb/Kconfig
 create mode 100644 board/freescale/s32v234evb/MAINTAINERS
 create mode 100644 board/freescale/s32v234evb/Makefile
 create mode 100644 board/freescale/s32v234evb/clock.c
 create mode 100644 board/freescale/s32v234evb/lpddr2.c
 create mode 100644 board/freescale/s32v234evb/s32v234evb.c
 create mode 100644 board/freescale/s32v234evb/s32v234evb.cfg
 create mode 100644 configs/s32v234evb_defconfig
 create mode 100644 include/configs/s32v234evb.h

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 6b65d8e..de04600 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -511,6 +511,10 @@ config RMOBILE
bool "Renesas ARM SoCs"
select CPU_V7
 
+config TARGET_S32V234EVB
+   bool "Support s32v234evb"
+   select ARM64
+
 config ARCH_SNAPDRAGON
bool "Qualcomm Snapdragon SoCs"
select ARM64
@@ -842,6 +846,7 @@ source "board/freescale/mx53ard/Kconfig"
 source "board/freescale/mx53evk/Kconfig"
 source "board/freescale/mx53loco/Kconfig"
 source "board/freescale/mx53smd/Kconfig"
+source "board/freescale/s32v234evb/Kconfig"
 source "board/freescale/vf610twr/Kconfig"
 source "board/gumstix/pepper/Kconfig"
 source "board/h2200/Kconfig"
diff --git a/arch/arm/cpu/armv8/Makefile 

[U-Boot] [PATCH v2 1/2] serial: Introduce linflex uart support

[Eddy Petrișor]

From: Stoica Cosmin-Stefan 

The Linflex module is integrated on some NXP automotive SoCs part of the former
Freescale portfolio, like S32V234, an SoC for Advanced Driver Assistance
Systems.

Original-signed-off-by: Stoica Cosmin-Stefan 
Original-signed-off-by: Chircu Bogdan 
Original-signed-off-by: Depons Eric 
Original-signed-off-by: Eddy Petrișor 

Signed-off-by: Eddy Petrișor 
---

Notes:
Changes in v2:
Added support for device model. Compatibility with non-DM code is kept
for easier synchronization with the code on the vendor branch where the
conversion to DM is not done for all boards.

 drivers/serial/Makefile |   1 +
 drivers/serial/serial_linflexuart.c | 274 
 2 files changed, 275 insertions(+)
 create mode 100644 drivers/serial/serial_linflexuart.c

diff --git a/drivers/serial/Makefile b/drivers/serial/Makefile
index b0ac9d8..98a00b9 100644
--- a/drivers/serial/Makefile
+++ b/drivers/serial/Makefile
@@ -33,6 +33,7 @@ obj-$(CONFIG_SCIF_CONSOLE) += serial_sh.o
 obj-$(CONFIG_ZYNQ_SERIAL) += serial_zynq.o
 obj-$(CONFIG_BFIN_SERIAL) += serial_bfin.o
 obj-$(CONFIG_FSL_LPUART) += serial_lpuart.o
+obj-$(CONFIG_FSL_LINFLEXUART) += serial_linflexuart.o
 obj-$(CONFIG_ARC_SERIAL) += serial_arc.o
 obj-$(CONFIG_UNIPHIER_SERIAL) += serial_uniphier.o
 obj-$(CONFIG_STM32_SERIAL) += serial_stm32.o
diff --git a/drivers/serial/serial_linflexuart.c 
b/drivers/serial/serial_linflexuart.c
new file mode 100644
index 000..a7dc89f
--- /dev/null
+++ b/drivers/serial/serial_linflexuart.c
@@ -0,0 +1,274 @@
+/*
+ * (C) Copyright 2013-2016 Freescale Semiconductor, Inc.
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define US1_TDRE(1 << 7)
+#define US1_RDRF(1 << 5)
+#define UC2_TE  (1 << 3)
+#define LINCR1_INIT (1 << 0)
+#define LINCR1_MME  (1 << 4)
+#define LINCR1_BF   (1 << 7)
+#define LINSR_LINS_INITMODE (0x1000)
+#define LINSR_LINS_MASK (0xF000)
+#define UARTCR_UART (1 << 0)
+#define UARTCR_WL0  (1 << 1)
+#define UARTCR_PCE  (1 << 2)
+#define UARTCR_PC0  (1 << 3)
+#define UARTCR_TXEN (1 << 4)
+#define UARTCR_RXEN (1 << 5)
+#define UARTCR_PC1  (1 << 6)
+#define UARTSR_DTF  (1 << 1)
+#define UARTSR_DRF  (1 << 2)
+#define UARTSR_RMB  (1 << 9)
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#ifndef CONFIG_DM_SERIAL
+struct linflex_fsl *lfbase = (struct linflex_fsl *)LINFLEXUART_BASE;
+#endif
+
+static void _linflex_serial_setbrg(struct linflex_fsl *base, int baudrate)
+{
+   u32 clk = mxc_get_clock(MXC_UART_CLK);
+   u32 ibr, fbr;
+
+   if (!baudrate)
+   baudrate = CONFIG_BAUDRATE;
+
+   ibr = (u32) (clk / (16 * gd->baudrate));
+   fbr = (u32) (clk % (16 * gd->baudrate)) * 16;
+
+   __raw_writel(ibr, >linibrr);
+   __raw_writel(fbr, >linfbrr);
+}
+
+static int _linflex_serial_getc(struct linflex_fsl *base)
+{
+   char c;
+
+#ifndef CONFIG_DM_SERIAL
+   /* waiting for data reception complete - TODO: add a timeout */
+   while ((__raw_readb(>uartsr) & UARTSR_DRF) != UARTSR_DRF);
+
+   /* waiting for data buffer to be ready - TODO: add a timeout */
+   while ((__raw_readl(>uartsr) & UARTSR_RMB) != UARTSR_RMB);
+#else
+   if (!(__raw_readb(>uartsr) & UARTSR_DRF))
+   return -EAGAIN;
+
+   if (!(__raw_readl(>uartsr) & UARTSR_RMB))
+   return -EAGAIN;
+
+#endif
+
+   c = __raw_readl(>bdrm);
+   __raw_writeb((__raw_readb(>uartsr) | (UARTSR_DRF | UARTSR_RMB)),
+>uartsr);
+   return c;
+}
+
+static int _linflex_serial_putc(struct linflex_fsl *base, const char c)
+{
+   #ifndef CONFIG_DM_SERIAL
+   if (c == '\n')
+   serial_putc('\r');
+   #endif
+
+   __raw_writeb(c, >bdrl);
+
+
+#ifndef CONFIG_DM_SERIAL
+   /* waiting for data transmission completed - TODO: add a timeout */
+   while ((__raw_readb(>uartsr) & UARTSR_DTF) != UARTSR_DTF);
+#else
+   if (!(__raw_readb(>uartsr) & UARTSR_DTF))
+   return -EAGAIN;
+#endif
+
+   __raw_writeb((__raw_readb(>uartsr) | UARTSR_DTF), >uartsr);
+
+   return 0;
+}
+
+/*
+ * Initialise the serial port with the given baudrate. The settings
+ * are always 8 data bits, no parity, 1 stop bit, no start bits.
+ */
+static int _linflex_serial_init(struct linflex_fsl *base)
+{
+   volatile u32 ctrl;
+
+   /* set the Linflex in master mode amd activate by-pass filter */
+   ctrl = LINCR1_BF | LINCR1_MME;
+   __raw_writel(ctrl, >lincr1);
+
+   /* init mode */
+   ctrl |= LINCR1_INIT;
+   __raw_writel(ctrl, >lincr1);
+
+ 

[U-Boot] [PATCH 2/2] armv8: s32v234: Introduce basic support for s32v234evb

[Eddy Petrișor]

From: Eddy Petrișor 

Add initial support for NXP's S32V234 SoC and S32V234EVB board.

The S32V230 family is designed to support computation-intensive applications
for image processing. The S32V234, as part of the S32V230 family, is a
high-performance automotive processor designed to support safe
computation-intensive applications in the area of vision and sensor fusion.

Code originally writen by:
Original-signed-off-by: Stoica Cosmin-Stefan 
Original-signed-off-by: Mihaela Martinas 
Original-signed-off-by: Eddy Petrișor 

Signed-off-by: Eddy Petrișor 
---
 arch/arm/Kconfig|   5 +
 arch/arm/cpu/armv8/Makefile |   1 +
 arch/arm/cpu/armv8/s32v234/Makefile |   8 +
 arch/arm/cpu/armv8/s32v234/cpu.c|  97 +++
 arch/arm/cpu/armv8/s32v234/cpu.h|   8 +
 arch/arm/cpu/armv8/s32v234/generic.c| 350 
 arch/arm/include/asm/arch-s32v234/clock.h   |  34 +++
 arch/arm/include/asm/arch-s32v234/ddr.h | 157 +++
 arch/arm/include/asm/arch-s32v234/imx-regs.h| 329 ++
 arch/arm/include/asm/arch-s32v234/lpddr2.h  |  75 +
 arch/arm/include/asm/arch-s32v234/mc_cgm_regs.h | 254 +
 arch/arm/include/asm/arch-s32v234/mc_me_regs.h  | 199 ++
 arch/arm/include/asm/arch-s32v234/mc_rgm_regs.h |  31 +++
 arch/arm/include/asm/arch-s32v234/mmdc.h|  89 ++
 arch/arm/include/asm/arch-s32v234/siul.h| 150 ++
 board/freescale/s32v234evb/Kconfig  |  23 ++
 board/freescale/s32v234evb/MAINTAINERS  |   8 +
 board/freescale/s32v234evb/Makefile |  11 +
 board/freescale/s32v234evb/clock.c  | 344 +++
 board/freescale/s32v234evb/lpddr2.c | 137 ++
 board/freescale/s32v234evb/s32v234evb.c | 183 +
 board/freescale/s32v234evb/s32v234evb.cfg   |  29 ++
 configs/s32v234evb_defconfig|   6 +
 drivers/mmc/fsl_esdhc.c |  10 +-
 include/configs/s32v234evb.h| 305 +
 25 files changed, 2838 insertions(+), 5 deletions(-)
 create mode 100644 arch/arm/cpu/armv8/s32v234/Makefile
 create mode 100644 arch/arm/cpu/armv8/s32v234/cpu.c
 create mode 100644 arch/arm/cpu/armv8/s32v234/cpu.h
 create mode 100644 arch/arm/cpu/armv8/s32v234/generic.c
 create mode 100644 arch/arm/include/asm/arch-s32v234/clock.h
 create mode 100644 arch/arm/include/asm/arch-s32v234/ddr.h
 create mode 100644 arch/arm/include/asm/arch-s32v234/imx-regs.h
 create mode 100644 arch/arm/include/asm/arch-s32v234/lpddr2.h
 create mode 100644 arch/arm/include/asm/arch-s32v234/mc_cgm_regs.h
 create mode 100644 arch/arm/include/asm/arch-s32v234/mc_me_regs.h
 create mode 100644 arch/arm/include/asm/arch-s32v234/mc_rgm_regs.h
 create mode 100644 arch/arm/include/asm/arch-s32v234/mmdc.h
 create mode 100644 arch/arm/include/asm/arch-s32v234/siul.h
 create mode 100644 board/freescale/s32v234evb/Kconfig
 create mode 100644 board/freescale/s32v234evb/MAINTAINERS
 create mode 100644 board/freescale/s32v234evb/Makefile
 create mode 100644 board/freescale/s32v234evb/clock.c
 create mode 100644 board/freescale/s32v234evb/lpddr2.c
 create mode 100644 board/freescale/s32v234evb/s32v234evb.c
 create mode 100644 board/freescale/s32v234evb/s32v234evb.cfg
 create mode 100644 configs/s32v234evb_defconfig
 create mode 100644 include/configs/s32v234evb.h

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 6b65d8e..de04600 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -511,6 +511,10 @@ config RMOBILE
bool "Renesas ARM SoCs"
select CPU_V7
 
+config TARGET_S32V234EVB
+   bool "Support s32v234evb"
+   select ARM64
+
 config ARCH_SNAPDRAGON
bool "Qualcomm Snapdragon SoCs"
select ARM64
@@ -842,6 +846,7 @@ source "board/freescale/mx53ard/Kconfig"
 source "board/freescale/mx53evk/Kconfig"
 source "board/freescale/mx53loco/Kconfig"
 source "board/freescale/mx53smd/Kconfig"
+source "board/freescale/s32v234evb/Kconfig"
 source "board/freescale/vf610twr/Kconfig"
 source "board/gumstix/pepper/Kconfig"
 source "board/h2200/Kconfig"
diff --git a/arch/arm/cpu/armv8/Makefile b/arch/arm/cpu/armv8/Makefile
index 1c85aa9..bf8644c 100644
--- a/arch/arm/cpu/armv8/Makefile
+++ b/arch/arm/cpu/armv8/Makefile
@@ -17,5 +17,6 @@ obj-y += transition.o
 obj-y  += fwcall.o
 
 obj-$(CONFIG_FSL_LAYERSCAPE) += fsl-layerscape/
+obj-$(CONFIG_S32V234) += s32v234/
 obj-$(CONFIG_ARCH_ZYNQMP) += zynqmp/
 obj-$(CONFIG_TARGET_HIKEY) += hisilicon/
diff --git a/arch/arm/cpu/armv8/s32v234/Makefile 
b/arch/arm/cpu/armv8/s32v234/Makefile
new file mode 100644
index 000..49774f6
--- /dev/null
+++ b/arch/arm/cpu/armv8/s32v234/Makefile
@@ -0,0 +1,8 @@
+#
+# (C) 

[U-Boot] [PATCH 1/2] serial: Introduce linflex uart support

[Eddy Petrișor]

From: Stoica Cosmin-Stefan 

The Linflex module is integrated on some NXP automotive SoCs part of the former
Freescale portfolio, like S32V234, an SoC for Advanced Driver Assistance
Systems.

Original-signed-off-by: Stoica Cosmin-Stefan 
Original-signed-off-by: Chircu Bogdan 
Original-signed-off-by: Depons Eric 
Original-signed-off-by: Eddy Petrișor 

Signed-off-by: Eddy Petrișor 
---
 drivers/serial/Makefile |   1 +
 drivers/serial/serial_linflexuart.c | 274 
 2 files changed, 275 insertions(+)
 create mode 100644 drivers/serial/serial_linflexuart.c

diff --git a/drivers/serial/Makefile b/drivers/serial/Makefile
index b0ac9d8..98a00b9 100644
--- a/drivers/serial/Makefile
+++ b/drivers/serial/Makefile
@@ -33,6 +33,7 @@ obj-$(CONFIG_SCIF_CONSOLE) += serial_sh.o
 obj-$(CONFIG_ZYNQ_SERIAL) += serial_zynq.o
 obj-$(CONFIG_BFIN_SERIAL) += serial_bfin.o
 obj-$(CONFIG_FSL_LPUART) += serial_lpuart.o
+obj-$(CONFIG_FSL_LINFLEXUART) += serial_linflexuart.o
 obj-$(CONFIG_ARC_SERIAL) += serial_arc.o
 obj-$(CONFIG_UNIPHIER_SERIAL) += serial_uniphier.o
 obj-$(CONFIG_STM32_SERIAL) += serial_stm32.o
diff --git a/drivers/serial/serial_linflexuart.c 
b/drivers/serial/serial_linflexuart.c
new file mode 100644
index 000..a7dc89f
--- /dev/null
+++ b/drivers/serial/serial_linflexuart.c
@@ -0,0 +1,274 @@
+/*
+ * (C) Copyright 2013-2016 Freescale Semiconductor, Inc.
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define US1_TDRE(1 << 7)
+#define US1_RDRF(1 << 5)
+#define UC2_TE  (1 << 3)
+#define LINCR1_INIT (1 << 0)
+#define LINCR1_MME  (1 << 4)
+#define LINCR1_BF   (1 << 7)
+#define LINSR_LINS_INITMODE (0x1000)
+#define LINSR_LINS_MASK (0xF000)
+#define UARTCR_UART (1 << 0)
+#define UARTCR_WL0  (1 << 1)
+#define UARTCR_PCE  (1 << 2)
+#define UARTCR_PC0  (1 << 3)
+#define UARTCR_TXEN (1 << 4)
+#define UARTCR_RXEN (1 << 5)
+#define UARTCR_PC1  (1 << 6)
+#define UARTSR_DTF  (1 << 1)
+#define UARTSR_DRF  (1 << 2)
+#define UARTSR_RMB  (1 << 9)
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#ifndef CONFIG_DM_SERIAL
+struct linflex_fsl *lfbase = (struct linflex_fsl *)LINFLEXUART_BASE;
+#endif
+
+static void _linflex_serial_setbrg(struct linflex_fsl *base, int baudrate)
+{
+   u32 clk = mxc_get_clock(MXC_UART_CLK);
+   u32 ibr, fbr;
+
+   if (!baudrate)
+   baudrate = CONFIG_BAUDRATE;
+
+   ibr = (u32) (clk / (16 * gd->baudrate));
+   fbr = (u32) (clk % (16 * gd->baudrate)) * 16;
+
+   __raw_writel(ibr, >linibrr);
+   __raw_writel(fbr, >linfbrr);
+}
+
+static int _linflex_serial_getc(struct linflex_fsl *base)
+{
+   char c;
+
+#ifndef CONFIG_DM_SERIAL
+   /* waiting for data reception complete - TODO: add a timeout */
+   while ((__raw_readb(>uartsr) & UARTSR_DRF) != UARTSR_DRF);
+
+   /* waiting for data buffer to be ready - TODO: add a timeout */
+   while ((__raw_readl(>uartsr) & UARTSR_RMB) != UARTSR_RMB);
+#else
+   if (!(__raw_readb(>uartsr) & UARTSR_DRF))
+   return -EAGAIN;
+
+   if (!(__raw_readl(>uartsr) & UARTSR_RMB))
+   return -EAGAIN;
+
+#endif
+
+   c = __raw_readl(>bdrm);
+   __raw_writeb((__raw_readb(>uartsr) | (UARTSR_DRF | UARTSR_RMB)),
+>uartsr);
+   return c;
+}
+
+static int _linflex_serial_putc(struct linflex_fsl *base, const char c)
+{
+   #ifndef CONFIG_DM_SERIAL
+   if (c == '\n')
+   serial_putc('\r');
+   #endif
+
+   __raw_writeb(c, >bdrl);
+
+
+#ifndef CONFIG_DM_SERIAL
+   /* waiting for data transmission completed - TODO: add a timeout */
+   while ((__raw_readb(>uartsr) & UARTSR_DTF) != UARTSR_DTF);
+#else
+   if (!(__raw_readb(>uartsr) & UARTSR_DTF))
+   return -EAGAIN;
+#endif
+
+   __raw_writeb((__raw_readb(>uartsr) | UARTSR_DTF), >uartsr);
+
+   return 0;
+}
+
+/*
+ * Initialise the serial port with the given baudrate. The settings
+ * are always 8 data bits, no parity, 1 stop bit, no start bits.
+ */
+static int _linflex_serial_init(struct linflex_fsl *base)
+{
+   volatile u32 ctrl;
+
+   /* set the Linflex in master mode amd activate by-pass filter */
+   ctrl = LINCR1_BF | LINCR1_MME;
+   __raw_writel(ctrl, >lincr1);
+
+   /* init mode */
+   ctrl |= LINCR1_INIT;
+   __raw_writel(ctrl, >lincr1);
+
+   /* waiting for init mode entry - TODO: add a timeout */
+   while ((__raw_readl(>linsr) & LINSR_LINS_MASK) !=
+  LINSR_LINS_INITMODE);
+
+   /* set UART bit to allow writing other bits */
+   

Re: [U-Boot] [PATCH v2 15/15] defconfig: ti: Add configs for OMAP5-class secure parts

[Andreas Dannenberg]

On Wed, Apr 27, 2016 at 03:09:19PM -0500, Daniel Allred wrote:
> Adds new defconfig files for DRA7xx and AM57xx secure devices.
> These are the same as the non-secure parts, but with the addition
> of the CONFIG_TI_SECURE_DEVICE option set to 'y'.
> 
> Signed-off-by: Daniel Allred 
> Signed-off-by: Madan Srinivas 
> ---

Successfully built and boot-tested on DRA74x, DRA72x, and AM572x high-security
EVMs.

Tested-by: Andreas Dannenberg 

Regards,

--
Andreas Dannenberg
Texas Instruments Inc
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 14/15] ARM: omap5: add ft_board_setup for dra7xx/am57xx

[Andreas Dannenberg]

On Wed, Apr 27, 2016 at 03:09:18PM -0500, Daniel Allred wrote:
> Adds the board specific ft_board_setup() functions that
> are called when CONFIG_OF_BOARD_SETUP is defined. These functions
> will currently just call the ft_cpu_setup() function.
> 
> Adds CONFIG_OF_BOARD_SETUP to the defconfig files
> for dra72_evm, dra74_evm, and am57xx_evm.
> 
> Signed-off-by: Daniel Allred 
> Signed-off-by: Madan Srinivas 

Successfully boot-tested on DRA74x, DRA72x, and AM572x high-security
EVMs.

Tested-by: Andreas Dannenberg 

Regards,

--
Andreas Dannenberg
Texas Instruments Inc
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 13/15] ARM: omap5: add hooks for cpu/SoC fdt fixups

[Andreas Dannenberg]

On Wed, Apr 27, 2016 at 03:09:17PM -0500, Daniel Allred wrote:
> Adds an fdt.c file in that defines the ft_cpu_setup() function,
> which should be called from a board-specific ft_board_setup()).
> This ft_cpu_setup() will currently do nothing for non-secure (GP)
> devices   but contains pertinent updates for booting on secure (HS)
> devices.
> 
> Update the omap5 Makefile to include the fdt.c in the build.
> 
> Signed-off-by: Daniel Allred 
> Signed-off-by: Madan Srinivas 

Successfully boot-tested on DRA74x, DRA72x, and AM572x high-security
EVMs.

Tested-by: Andreas Dannenberg 

Regards,

--
Andreas Dannenberg
Texas Instruments Inc
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 12/15] ARM: omap-common: Add device type to CPU string

[Andreas Dannenberg]

On Wed, Apr 27, 2016 at 03:09:16PM -0500, Daniel Allred wrote:
> Update the CPU string output so that the device
> type is now included as part of the CPU string that
> is printed as the SPL or u-boot comes up. This update
> adds a suffix of the form "-GP" or "-HS" for production
> devices, so that general purpose (GP) and high security
> (HS) can be distiguished. Applies to all OMAP5 variants.
> 
> Signed-off-by: Daniel Allred 
> Signed-off-by: Madan Srinivas 

Successfully boot-tested on DRA74x, DRA72x, and AM572x high-security
EVMs. We still should apply similar device type reporting during SPL
boot for other TI SoCs as per Tom Rini's feedback however this out of
scope for this patch and has been recorded as an action item internally.

Tested-by: Andreas Dannenberg 

Regards,

--
Andreas Dannenberg
Texas Instruments Inc
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 10/15] ti_omap5_common: Update SPL start address on secure parts

[Andreas Dannenberg]

On Wed, Apr 27, 2016 at 03:09:14PM -0500, Daniel Allred wrote:
> Updated the CONFIG_SPL_TEXT_BASE to support secure parts (moving
> the start address past secure reserved memory and the size of the
> security certificate that precedes the boot image on secure devices).
> Updated the related CONFIG_SPL_MAX_SIZE to properly reflect the
> internal memory actually available on the various device flavors
> (Common minimum internal RAM guaranteed for various flavors of
> DRA7xx/AM57xx is 512KB).
> 
> Signed-off-by: Daniel Allred 
> Signed-off-by: Madan Srinivas 

Successfully boot-tested on DRA74x, DRA72x, and AM572x high-security
EVMs.

Tested-by: Andreas Dannenberg 

Regards,

--
Andreas Dannenberg
Texas Instruments Inc
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 09/15] defconfig: Add a config for AM43xx secure part

[Andreas Dannenberg]

On Wed, Apr 27, 2016 at 03:09:13PM -0500, Daniel Allred wrote:
> From: Madan Srinivas 
> 
> Adds a new defconfig file for the AM43xx secure device.
> This is the same as for the non-secure part, except for:
>   CONFIG_TI_SECURE_DEVICE option set to 'y'
>   CONFIG_ISW_ENTRY_ADDR updated for secure images.
> 
> Signed-off-by: Daniel Allred 
> Signed-off-by: Madan Srinivas 

Successfully boot-tested after applying to U-boot master branch on
AM437x high-security (HS) EVM.

Tested-by: Andreas Dannenberg 

Regards,

--
Andreas Dannenberg
Texas Instruments Inc
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Problem of git clone with http

[Andreas Dannenberg]

On Wed, Apr 27, 2016 at 02:05:47PM -0700, Sergey Kubushyn wrote:
> On Wed, 27 Apr 2016, Wolfgang Denk wrote:
> 
> >Dear Andreas,
> >
> >In message <20160427144315.gh2...@borg.dal.design.ti.com> you wrote:
> >>
> >But i can't pull and fetch anything with http..
> >...
> >>I was just banging my head not being able to fetch the latest U-Boot
> >>stuff, running into the same issue, and successfully worked around it by
> >>using the git:// URL. However it wasn't until I wanted to post about
> >>this on this mailing list that I found this thread :)
> >>
> >>Anyways it seems like this issue already persists for one month without
> >>a fix. For folks behind draconian corporate firewalls the http:// URLs
> >>are often easier to use, so this is a bit of a trap
> >
> >Agreed.  But the first step of getting something fixed is to report it
> >to the responsible admins, or here on the list.  I never use HTTP
> >myself to access the repository, as git protocol is so much more
> >efficient.  So unless somebody shouts about it, I will never notice
> >any such problems.
> >
> >I've tweaked things a bit - can you please give it another try?  If
> >you still see problems (either now or later) please make sure to
> >report them to me, and I will make sure someone looks into it.
> 
> This seems to be a widespread thing. It is definitely caused by buggy Cisco
> firewalls corrupting binary files.

In my case since I partially work off-site (enjoying unrestricted
Internet access during those times), the issue also occurred without any
type of firewall in-between (well, except my little home office router).
So it seems like there are several things that can go wrong, of course
corporate firewalls like you pointed out often being a major culprit.

Regards,
Andreas

> I had the same problem in corporate
> environment (where I have my day job right now) 100% traced to their proxy
> servers. All traffic is going through some Cisco proxies (don't know what
> devices/software it is) and it was impossible to clone a git repo because
> data was corrupted when going through those buggy things.
> 
> In my case, as I'm more like a principal engineer here, corporate IT made a
> hole for my development machines so they go to the Net directly. That solved
> the issue.
> 
> Before that cloning always failed when uncompressing objects. That also
> applied to _ANY_ compressed files downloaded from the Net if those were
> big enough. Smaller files were OK and small git repos didn't have any
> problems but when they were bigger than some threshold all such files
> arrived corrupted.
> 
> ---
> **
> *  KSI@homeKOI8 Net  < >  The impossible we do immediately.  *
> *  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
> **
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Problem of git clone with http

[Sergey Kubushyn]

On Wed, 27 Apr 2016, Wolfgang Denk wrote:


Dear Andreas,

In message <20160427144315.gh2...@borg.dal.design.ti.com> you wrote:



But i can't pull and fetch anything with http..

...

I was just banging my head not being able to fetch the latest U-Boot
stuff, running into the same issue, and successfully worked around it by
using the git:// URL. However it wasn't until I wanted to post about
this on this mailing list that I found this thread :)

Anyways it seems like this issue already persists for one month without
a fix. For folks behind draconian corporate firewalls the http:// URLs
are often easier to use, so this is a bit of a trap


Agreed.  But the first step of getting something fixed is to report it
to the responsible admins, or here on the list.  I never use HTTP
myself to access the repository, as git protocol is so much more
efficient.  So unless somebody shouts about it, I will never notice
any such problems.

I've tweaked things a bit - can you please give it another try?  If
you still see problems (either now or later) please make sure to
report them to me, and I will make sure someone looks into it.


This seems to be a widespread thing. It is definitely caused by buggy Cisco
firewalls corrupting binary files. I had the same problem in corporate
environment (where I have my day job right now) 100% traced to their proxy
servers. All traffic is going through some Cisco proxies (don't know what
devices/software it is) and it was impossible to clone a git repo because
data was corrupted when going through those buggy things.

In my case, as I'm more like a principal engineer here, corporate IT made a
hole for my development machines so they go to the Net directly. That solved
the issue.

Before that cloning always failed when uncompressing objects. That also
applied to _ANY_ compressed files downloaded from the Net if those were
big enough. Smaller files were OK and small git repos didn't have any
problems but when they were bigger than some threshold all such files
arrived corrupted.

---
**
*  KSI@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Problem of git clone with http

[Andreas Dannenberg]

On Wed, Apr 27, 2016 at 10:44:00PM +0200, Wolfgang Denk wrote:
> Dear Andreas,
> 
> In message <20160427144315.gh2...@borg.dal.design.ti.com> you wrote:
> >
> > > >> But i can't pull and fetch anything with http..
> ...
> > I was just banging my head not being able to fetch the latest U-Boot
> > stuff, running into the same issue, and successfully worked around it by
> > using the git:// URL. However it wasn't until I wanted to post about
> > this on this mailing list that I found this thread :)
> > 
> > Anyways it seems like this issue already persists for one month without
> > a fix. For folks behind draconian corporate firewalls the http:// URLs
> > are often easier to use, so this is a bit of a trap
> 
> Agreed.  But the first step of getting something fixed is to report it
> to the responsible admins, or here on the list.  I never use HTTP
> myself to access the repository, as git protocol is so much more
> efficient.  So unless somebody shouts about it, I will never notice
> any such problems.
> 
> I've tweaked things a bit - can you please give it another try?  If
> you still see problems (either now or later) please make sure to
> report them to me, and I will make sure someone looks into it.

Hallo Wolfgang,
I just did a fresh git clone http://git.denx.de/u-boot.git into a new
directory just to verify the current behavior and I can confirm that it
now works as expected. Thanks!

Regards,
Andreas

--
Andreas Dannenberg
Texas Instruments Inc
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Problem of git clone with http

[Wolfgang Denk]

Dear Andreas,

In message <20160427144315.gh2...@borg.dal.design.ti.com> you wrote:
>
> > >> But i can't pull and fetch anything with http..
...
> I was just banging my head not being able to fetch the latest U-Boot
> stuff, running into the same issue, and successfully worked around it by
> using the git:// URL. However it wasn't until I wanted to post about
> this on this mailing list that I found this thread :)
> 
> Anyways it seems like this issue already persists for one month without
> a fix. For folks behind draconian corporate firewalls the http:// URLs
> are often easier to use, so this is a bit of a trap

Agreed.  But the first step of getting something fixed is to report it
to the responsible admins, or here on the list.  I never use HTTP
myself to access the repository, as git protocol is so much more
efficient.  So unless somebody shouts about it, I will never notice
any such problems.

I've tweaked things a bit - can you please give it another try?  If
you still see problems (either now or later) please make sure to
report them to me, and I will make sure someone looks into it.

Thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
"Here's a fish hangs in the net like a poor man's right in  the  law.
'Twill hardly come out." - Shakespeare, Pericles, Act II, Scene 1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] usb: dwc2: Init desc_before_addr

[Marek Vasut]

On 04/27/2016 07:15 PM, Dinh Nguyen wrote:
> On 04/25/2016 08:08 PM, Marek Vasut wrote:
>> Initialize desc_before_addr, otherwise the USB core won't send the
>> first 64B Get Device Descriptor request in common/usb.c function
>> usb_setup_descriptor() . There are some USB devices which expect
>> this sequence and otherwise can misbehave.
>>
>> Signed-off-by: Marek Vasut 
>> Cc: Dinh Nguyen 
>> Cc: Tom Rini 
>> ---
>>  drivers/usb/host/dwc2.c | 3 +++
>>  1 file changed, 3 insertions(+)
>> ---
>> NOTE: I checked this with TotalPhase Beagle USB480 and it does what it is
>>   supposed to do now. It would be wonderful to get this into rc3.
>>
>> diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c
>> index b2f4bc6..559c43f 100644
>> --- a/drivers/usb/host/dwc2.c
>> +++ b/drivers/usb/host/dwc2.c
>> @@ -1182,6 +1182,9 @@ static int dwc2_usb_ofdata_to_platdata(struct udevice 
>> *dev)
>>  static int dwc2_usb_probe(struct udevice *dev)
>>  {
>>  struct dwc2_priv *priv = dev_get_priv(dev);
>> +struct usb_bus_priv *bus_priv = dev_get_uclass_priv(dev);
>> +
>> +bus_priv->desc_before_addr = true;
>>  
>>  return dwc2_init_common(priv);
>>  }
>>
> 
> With this patch, I no longer have to revert commit "c998da0d67091 usb:
> Change power-on / scanning timeout handling" for my problematic Kingston
> USB stick to work.
> 
> So feel free to add:
> 
> Tested-by: Dinh Nguyen 

Good for you, bad for me ;-) If we don't fix this USB horror before
ELCE, you can expect a nice gift :)

> Dinh
> 


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

[U-Boot] [PATCH v2 14/15] ARM: omap5: add ft_board_setup for dra7xx/am57xx

[Daniel Allred]

Adds the board specific ft_board_setup() functions that
are called when CONFIG_OF_BOARD_SETUP is defined. These functions
will currently just call the ft_cpu_setup() function.

Adds CONFIG_OF_BOARD_SETUP to the defconfig files
for dra72_evm, dra74_evm, and am57xx_evm.

Signed-off-by: Daniel Allred 
Signed-off-by: Madan Srinivas 
---

V2:
 Squash commits 14 and 15 from v1 to this one commit
 Move CONFIG_OF_BOARD_SETUP to defconfig files, instead of header files

 board/ti/am57xx/board.c  | 9 +
 board/ti/dra7xx/evm.c| 9 +
 configs/am57xx_evm_defconfig | 1 +
 configs/dra72_evm_defconfig  | 1 +
 configs/dra74_evm_defconfig  | 1 +
 5 files changed, 21 insertions(+)

diff --git a/board/ti/am57xx/board.c b/board/ti/am57xx/board.c
index 86b8f6e..9904047 100644
--- a/board/ti/am57xx/board.c
+++ b/board/ti/am57xx/board.c
@@ -686,3 +686,12 @@ int board_early_init_f(void)
return 0;
 }
 #endif
+
+#if defined(CONFIG_OF_LIBFDT) && defined(CONFIG_OF_BOARD_SETUP)
+int ft_board_setup(void *blob, bd_t *bd)
+{
+   ft_cpu_setup(blob, bd);
+
+   return 0;
+}
+#endif
diff --git a/board/ti/dra7xx/evm.c b/board/ti/dra7xx/evm.c
index 9bd71d8..d01c785 100644
--- a/board/ti/dra7xx/evm.c
+++ b/board/ti/dra7xx/evm.c
@@ -718,3 +718,12 @@ int board_early_init_f(void)
return 0;
 }
 #endif
+
+#if defined(CONFIG_OF_LIBFDT) && defined(CONFIG_OF_BOARD_SETUP)
+int ft_board_setup(void *blob, bd_t *bd)
+{
+   ft_cpu_setup(blob, bd);
+
+   return 0;
+}
+#endif
diff --git a/configs/am57xx_evm_defconfig b/configs/am57xx_evm_defconfig
index 8fc3ebb..cccdc10 100644
--- a/configs/am57xx_evm_defconfig
+++ b/configs/am57xx_evm_defconfig
@@ -9,6 +9,7 @@ CONFIG_SPL=y
 CONFIG_SPL_STACK_R=y
 CONFIG_HUSH_PARSER=y
 CONFIG_CMD_BOOTZ=y
+CONFIG_OF_BOARD_SETUP=y
 # CONFIG_CMD_IMLS is not set
 CONFIG_CMD_ASKENV=y
 # CONFIG_CMD_FLASH is not set
diff --git a/configs/dra72_evm_defconfig b/configs/dra72_evm_defconfig
index 00c6ac3..c85c0fb 100644
--- a/configs/dra72_evm_defconfig
+++ b/configs/dra72_evm_defconfig
@@ -12,6 +12,7 @@ CONFIG_SPL=y
 CONFIG_SPL_STACK_R=y
 CONFIG_HUSH_PARSER=y
 CONFIG_CMD_BOOTZ=y
+CONFIG_OF_BOARD_SETUP=y
 # CONFIG_CMD_IMLS is not set
 CONFIG_CMD_ASKENV=y
 # CONFIG_CMD_FLASH is not set
diff --git a/configs/dra74_evm_defconfig b/configs/dra74_evm_defconfig
index a11dcd5..fc121a1 100644
--- a/configs/dra74_evm_defconfig
+++ b/configs/dra74_evm_defconfig
@@ -11,6 +11,7 @@ CONFIG_SPL=y
 CONFIG_SPL_STACK_R=y
 CONFIG_HUSH_PARSER=y
 CONFIG_CMD_BOOTZ=y
+CONFIG_OF_BOARD_SETUP=y
 # CONFIG_CMD_IMLS is not set
 CONFIG_CMD_ASKENV=y
 # CONFIG_CMD_FLASH is not set
-- 
1.9.1

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

[U-Boot] [PATCH v2 15/15] defconfig: ti: Add configs for OMAP5-class secure parts

[Daniel Allred]

Adds new defconfig files for DRA7xx and AM57xx secure devices.
These are the same as the non-secure parts, but with the addition
of the CONFIG_TI_SECURE_DEVICE option set to 'y'.

Signed-off-by: Daniel Allred 
Signed-off-by: Madan Srinivas 
---

V2:
 Rebase from current master, create HS copies of defconfigs

 configs/am57xx_hs_evm_defconfig | 36 +++
 configs/dra72_hs_evm_defconfig  | 55 +
 configs/dra74_hs_evm_defconfig  | 54 
 3 files changed, 145 insertions(+)
 create mode 100644 configs/am57xx_hs_evm_defconfig
 create mode 100644 configs/dra72_hs_evm_defconfig
 create mode 100644 configs/dra74_hs_evm_defconfig

diff --git a/configs/am57xx_hs_evm_defconfig b/configs/am57xx_hs_evm_defconfig
new file mode 100644
index 000..60525cd
--- /dev/null
+++ b/configs/am57xx_hs_evm_defconfig
@@ -0,0 +1,36 @@
+CONFIG_ARM=y
+CONFIG_OMAP54XX=y
+CONFIG_TI_SECURE_DEVICE=y
+CONFIG_TARGET_BEAGLE_X15=y
+CONFIG_DM_SERIAL=y
+CONFIG_DM_GPIO=y
+CONFIG_SPL_STACK_R_ADDR=0x8200
+CONFIG_DEFAULT_DEVICE_TREE="am57xx-beagle-x15"
+CONFIG_SPL=y
+CONFIG_SPL_STACK_R=y
+CONFIG_HUSH_PARSER=y
+CONFIG_CMD_BOOTZ=y
+CONFIG_OF_BOARD_SETUP=y
+# CONFIG_CMD_IMLS is not set
+CONFIG_CMD_ASKENV=y
+# CONFIG_CMD_FLASH is not set
+CONFIG_CMD_MMC=y
+CONFIG_CMD_SPI=y
+CONFIG_CMD_I2C=y
+CONFIG_CMD_USB=y
+CONFIG_CMD_GPIO=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_DHCP=y
+CONFIG_CMD_MII=y
+CONFIG_CMD_PING=y
+CONFIG_CMD_EXT2=y
+CONFIG_CMD_EXT4=y
+CONFIG_CMD_EXT4_WRITE=y
+CONFIG_CMD_FAT=y
+CONFIG_CMD_FS_GENERIC=y
+CONFIG_OF_CONTROL=y
+CONFIG_DM=y
+CONFIG_DM_MMC=y
+CONFIG_SPI_FLASH=y
+CONFIG_SPI_FLASH_BAR=y
+CONFIG_SYS_NS16550=y
diff --git a/configs/dra72_hs_evm_defconfig b/configs/dra72_hs_evm_defconfig
new file mode 100644
index 000..01f985e
--- /dev/null
+++ b/configs/dra72_hs_evm_defconfig
@@ -0,0 +1,55 @@
+CONFIG_ARM=y
+CONFIG_OMAP54XX=y
+CONFIG_TI_SECURE_DEVICE=y
+CONFIG_SYS_MALLOC_F_LEN=0x2000
+CONFIG_TARGET_DRA7XX_EVM=y
+CONFIG_DM_SERIAL=y
+CONFIG_DM_SPI=y
+CONFIG_DM_SPI_FLASH=y
+CONFIG_DM_GPIO=y
+CONFIG_SPL_STACK_R_ADDR=0x8200
+CONFIG_DEFAULT_DEVICE_TREE="dra72-evm"
+CONFIG_SPL=y
+CONFIG_SPL_STACK_R=y
+CONFIG_HUSH_PARSER=y
+CONFIG_CMD_BOOTZ=y
+CONFIG_OF_BOARD_SETUP=y
+# CONFIG_CMD_IMLS is not set
+CONFIG_CMD_ASKENV=y
+# CONFIG_CMD_FLASH is not set
+CONFIG_CMD_MMC=y
+CONFIG_CMD_SF=y
+CONFIG_CMD_SPI=y
+CONFIG_CMD_I2C=y
+CONFIG_CMD_USB=y
+CONFIG_CMD_DFU=y
+CONFIG_CMD_GPIO=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_DHCP=y
+CONFIG_CMD_MII=y
+CONFIG_CMD_PING=y
+CONFIG_CMD_EXT2=y
+CONFIG_CMD_EXT4=y
+CONFIG_CMD_EXT4_WRITE=y
+CONFIG_CMD_FAT=y
+CONFIG_CMD_FS_GENERIC=y
+CONFIG_OF_CONTROL=y
+CONFIG_DM=y
+CONFIG_DM_MMC=y
+CONFIG_SPI_FLASH=y
+CONFIG_SPI_FLASH_BAR=y
+CONFIG_SPI_FLASH_SPANSION=y
+CONFIG_SYS_NS16550=y
+CONFIG_TI_QSPI=y
+CONFIG_TIMER=y
+CONFIG_OMAP_TIMER=y
+CONFIG_USB=y
+CONFIG_USB_DWC3=y
+CONFIG_USB_DWC3_GADGET=y
+CONFIG_USB_DWC3_OMAP=y
+CONFIG_USB_DWC3_PHY_OMAP=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_GADGET_DOWNLOAD=y
+CONFIG_G_DNL_MANUFACTURER="Texas Instruments"
+CONFIG_G_DNL_VENDOR_NUM=0x0451
+CONFIG_G_DNL_PRODUCT_NUM=0xd022
diff --git a/configs/dra74_hs_evm_defconfig b/configs/dra74_hs_evm_defconfig
new file mode 100644
index 000..1b30ad4
--- /dev/null
+++ b/configs/dra74_hs_evm_defconfig
@@ -0,0 +1,54 @@
+CONFIG_ARM=y
+CONFIG_OMAP54XX=y
+CONFIG_TI_SECURE_DEVICE=y
+CONFIG_TARGET_DRA7XX_EVM=y
+CONFIG_DM_SERIAL=y
+CONFIG_DM_SPI=y
+CONFIG_DM_SPI_FLASH=y
+CONFIG_DM_GPIO=y
+CONFIG_SPL_STACK_R_ADDR=0x8200
+CONFIG_DEFAULT_DEVICE_TREE="dra7-evm"
+CONFIG_SPL=y
+CONFIG_SPL_STACK_R=y
+CONFIG_HUSH_PARSER=y
+CONFIG_CMD_BOOTZ=y
+CONFIG_OF_BOARD_SETUP=y
+# CONFIG_CMD_IMLS is not set
+CONFIG_CMD_ASKENV=y
+# CONFIG_CMD_FLASH is not set
+CONFIG_CMD_MMC=y
+CONFIG_CMD_SF=y
+CONFIG_CMD_SPI=y
+CONFIG_CMD_I2C=y
+CONFIG_CMD_USB=y
+CONFIG_CMD_DFU=y
+CONFIG_CMD_GPIO=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_DHCP=y
+CONFIG_CMD_MII=y
+CONFIG_CMD_PING=y
+CONFIG_CMD_EXT2=y
+CONFIG_CMD_EXT4=y
+CONFIG_CMD_EXT4_WRITE=y
+CONFIG_CMD_FAT=y
+CONFIG_CMD_FS_GENERIC=y
+CONFIG_OF_CONTROL=y
+CONFIG_DM=y
+CONFIG_DM_MMC=y
+CONFIG_SPI_FLASH=y
+CONFIG_SPI_FLASH_BAR=y
+CONFIG_SPI_FLASH_SPANSION=y
+CONFIG_SYS_NS16550=y
+CONFIG_TI_QSPI=y
+CONFIG_TIMER=y
+CONFIG_OMAP_TIMER=y
+CONFIG_USB=y
+CONFIG_USB_DWC3=y
+CONFIG_USB_DWC3_GADGET=y
+CONFIG_USB_DWC3_OMAP=y
+CONFIG_USB_DWC3_PHY_OMAP=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_GADGET_DOWNLOAD=y
+CONFIG_G_DNL_MANUFACTURER="Texas Instruments"
+CONFIG_G_DNL_VENDOR_NUM=0x0451
+CONFIG_G_DNL_PRODUCT_NUM=0xd022
-- 
1.9.1

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

[U-Boot] [PATCH v2 13/15] ARM: omap5: add hooks for cpu/SoC fdt fixups

[Daniel Allred]

Adds an fdt.c file in that defines the ft_cpu_setup() function,
which should be called from a board-specific ft_board_setup()).
This ft_cpu_setup() will currently do nothing for non-secure (GP)
devices but contains pertinent updates for booting on secure (HS)
devices.

Update the omap5 Makefile to include the fdt.c in the build.

Signed-off-by: Daniel Allred 
Signed-off-by: Madan Srinivas 
---

V2:
 Change CONFIG_SECURE_BOOT_SRAM to TI_OMAP5_SECURE_BOOT_RESV_SRAM_SZ
 Change CONFIG_SECURE_RUN_SRAM to CONFIG_SECURE_RUNTIME_RESV_SRAM_SZ

 arch/arm/cpu/armv7/omap5/Makefile |   1 +
 arch/arm/cpu/armv7/omap5/fdt.c| 184 ++
 2 files changed, 185 insertions(+)
 create mode 100644 arch/arm/cpu/armv7/omap5/fdt.c

diff --git a/arch/arm/cpu/armv7/omap5/Makefile 
b/arch/arm/cpu/armv7/omap5/Makefile
index f2930d5..3caba86 100644
--- a/arch/arm/cpu/armv7/omap5/Makefile
+++ b/arch/arm/cpu/armv7/omap5/Makefile
@@ -12,4 +12,5 @@ obj-y += sdram.o
 obj-y  += prcm-regs.o
 obj-y  += hw_data.o
 obj-y  += abb.o
+obj-y  += fdt.o
 obj-$(CONFIG_IODELAY_RECALIBRATION) += dra7xx_iodelay.o
diff --git a/arch/arm/cpu/armv7/omap5/fdt.c b/arch/arm/cpu/armv7/omap5/fdt.c
new file mode 100644
index 000..0493cd1
--- /dev/null
+++ b/arch/arm/cpu/armv7/omap5/fdt.c
@@ -0,0 +1,184 @@
+/*
+ * Copyright 2016 Texas Instruments, Inc.
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#ifdef CONFIG_TI_SECURE_DEVICE
+
+/* Give zero values if not already defined */
+#ifndef TI_OMAP5_SECURE_BOOT_RESV_SRAM_SZ
+#define TI_OMAP5_SECURE_BOOT_RESV_SRAM_SZ (0)
+#endif
+#ifndef CONFIG_SECURE_RUNTIME_RESV_SRAM_SZ
+#define CONFIG_SECURE_RUNTIME_RESV_SRAM_SZ (0)
+#endif
+
+static u32 hs_irq_skip[] = {
+   8,  /* Secure violation reporting interrupt */
+   15, /* One interrupt for SDMA by secure world */
+   118 /* One interrupt for Crypto DMA by secure world */
+};
+
+static int ft_hs_fixup_crossbar(void *fdt, bd_t *bd)
+{
+   const char *path;
+   int offs;
+   int ret;
+   int len, i, old_cnt, new_cnt;
+   u32 *temp;
+   const u32 *p_data;
+
+   /*
+* Increase the size of the fdt
+* so we have some breathing room
+*/
+   ret = fdt_increase_size(fdt, 512);
+   if (ret < 0) {
+   printf("Could not increase size of device tree: %s\n",
+  fdt_strerror(ret));
+   return ret;
+   }
+
+   /* Reserve IRQs that are used/needed by secure world */
+   path = "/ocp/crossbar";
+   offs = fdt_path_offset(fdt, path);
+   if (offs < 0) {
+   debug("Node %s not found.\n", path);
+   return 0;
+   }
+
+   /* Get current entries */
+   p_data = fdt_getprop(fdt, offs, "ti,irqs-skip", );
+   if (p_data)
+   old_cnt = len / sizeof(u32);
+   else
+   old_cnt = 0;
+
+   new_cnt = sizeof(hs_irq_skip) /
+   sizeof(hs_irq_skip[0]);
+
+   /* Create new/updated skip list for HS parts */
+   temp = malloc(sizeof(u32) * (old_cnt + new_cnt));
+   for (i = 0; i < new_cnt; i++)
+   temp[i] = cpu_to_fdt32(hs_irq_skip[i]);
+   for (i = 0; i < old_cnt; i++)
+   temp[i + new_cnt] = p_data[i];
+
+   /* Blow away old data and set new data */
+   fdt_delprop(fdt, offs, "ti,irqs-skip");
+   ret = fdt_setprop(fdt, offs, "ti,irqs-skip",
+ temp,
+ (old_cnt + new_cnt) * sizeof(u32));
+   free(temp);
+
+   /* Check if the update worked */
+   if (ret < 0) {
+   printf("Could not add ti,irqs-skip property to node %s: %s\n",
+  path, fdt_strerror(ret));
+   return ret;
+   }
+
+   return 0;
+}
+
+static int ft_hs_disable_rng(void *fdt, bd_t *bd)
+{
+   const char *path;
+   int offs;
+   int ret;
+
+   /* Make HW RNG reserved for secure world use */
+   path = "/ocp/rng";
+   offs = fdt_path_offset(fdt, path);
+   if (offs < 0) {
+   debug("Node %s not found.\n", path);
+   return 0;
+   }
+   ret = fdt_setprop_string(fdt, offs,
+"status", "disabled");
+   if (ret < 0) {
+   printf("Could not add status property to node %s: %s\n",
+  path, fdt_strerror(ret));
+   return ret;
+   }
+   return 0;
+}
+
+#if ((TI_OMAP5_SECURE_BOOT_RESV_SRAM_SZ != 0) || \
+(CONFIG_SECURE_RUNTIME_RESV_SRAM_SZ != 0))
+static int ft_hs_fixup_sram(void *fdt, bd_t *bd)
+{
+   const char *path;
+   int offs;
+   int ret;
+   u32 temp[2];
+
+   /*
+* Update SRAM reservations on secure devices. The OCMC RAM
+* is always reserved for secure use from the start of that
+* memory region
+*/
+   

[U-Boot] [PATCH v2 10/15] ti_omap5_common: Update SPL start address on secure parts

[Daniel Allred]

Updated the CONFIG_SPL_TEXT_BASE to support secure parts (moving
the start address past secure reserved memory and the size of the
security certificate that precedes the boot image on secure devices).
Updated the related CONFIG_SPL_MAX_SIZE to properly reflect the
internal memory actually available on the various device flavors
(Common minimum internal RAM guaranteed for various flavors of
DRA7xx/AM57xx is 512KB).

Signed-off-by: Daniel Allred 
Signed-off-by: Madan Srinivas 
---

V2:
 Rename CONFIG_SECURE_BOOT_SRAM to TI_OMAP5_SECURE_BOOT_RESV_SRAM_SZ since
  it is not configurable (dependent on ROM/secure code).

 include/configs/ti_omap5_common.h | 32 +++-
 1 file changed, 27 insertions(+), 5 deletions(-)

diff --git a/include/configs/ti_omap5_common.h 
b/include/configs/ti_omap5_common.h
index b049be4..d67860c 100644
--- a/include/configs/ti_omap5_common.h
+++ b/include/configs/ti_omap5_common.h
@@ -130,13 +130,35 @@
 
 /*
  * SPL related defines.  The Public RAM memory map the ROM defines the
- * area between 0x4030 and 0x4031E000 as a download area for OMAP5
- * (dra7xx is larger, but we do not need to be larger at this time).  We
- * set CONFIG_SPL_DISPLAY_PRINT to have omap_rev_string() called and
+ * area between 0x4030 and 0x4031E000 as a download area for OMAP5.
+ * On DRA7xx/AM57XX the download area is between 0x4030 and 0x4037E000.
+ * We set CONFIG_SPL_DISPLAY_PRINT to have omap_rev_string() called and
  * print some information.
  */
-#define CONFIG_SPL_TEXT_BASE   0x4030
-#define CONFIG_SPL_MAX_SIZE(0x4031E000 - CONFIG_SPL_TEXT_BASE)
+#ifdef CONFIG_TI_SECURE_DEVICE
+/*
+ * For memory booting on HS parts, the first 4KB of the internal RAM is
+ * reserved for secure world use and the flash loader image is
+ * preceded by a secure certificate. The SPL will therefore run in internal
+ * RAM from address 0x40301350 (0x4030+0x1000(reserved)+0x350(cert)).
+ */
+#define TI_OMAP5_SECURE_BOOT_RESV_SRAM_SZ  0x1000
+#define CONFIG_SPL_TEXT_BASE   0x40301350
+#else
+/*
+ * For all booting on GP parts, the flash loader image is
+ * downloaded into internal RAM at address 0x4030.
+ */
+#define CONFIG_SPL_TEXT_BASE   0x4030
+#endif
+
+/* DRA7xx/AM57xx have 512K of SRAM, OMAP5 only 128K */
+#if defined(CONFIG_DRA7XX) || defined(CONFIG_AM57XX)
+#define CONFIG_SPL_BOOT_END0x4037E000
+#else
+#define CONFIG_SPL_BOOT_END0x4031E000
+#endif
+#define CONFIG_SPL_MAX_SIZE (CONFIG_SPL_BOOT_END - CONFIG_SPL_TEXT_BASE)
 #define CONFIG_SPL_DISPLAY_PRINT
 #define CONFIG_SPL_LDSCRIPT "$(CPUDIR)/omap-common/u-boot-spl.lds"
 #define CONFIG_SYS_SPL_ARGS_ADDR   (CONFIG_SYS_SDRAM_BASE + \
-- 
1.9.1

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

[U-Boot] [PATCH v2 11/15] spl: build: ti: add support for secure boot images

[Daniel Allred]

Updates the SPL build so that when CONFIG_TI_SECURE_DEVICE
is in use (which it should be when building for secure parts),
the TI secure development package is used to create a valid
secure boot image. The u-boot SPL build processes is NOT aware
of the details of creating the boot image - all of that information
is encapsulated in the TI secure development package, which is
available from TI. More info can be found in README.ti-secure

Right now, two image types are generated, MLO and X-LOADER. The types
are important, as certain boot modes implemented by the device's ROM
boot loader require one or the other (they are not equivalent). The
output filenames are u-boot-spl_HS_MLO and u-boot-spl_HS_X-LOADER. The
u-boot-spl_HS_MLO image is also copied to a file named MLO, which is
the name that the device ROM bootloader requires for loading from the
FAT partition of an SD card (same as on non-secure devices).

Signed-off-by: Daniel Allred 
Signed-off-by: Madan Srinivas 

Reviewed-by: Lokesh Vutla 
Tested-by: Andreas Dannenberg 
Reviewed-by: Tom Rini 
---

V2:
 None

 arch/arm/cpu/armv7/omap5/config.mk | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/cpu/armv7/omap5/config.mk 
b/arch/arm/cpu/armv7/omap5/config.mk
index ef2725a..a7e55a5 100644
--- a/arch/arm/cpu/armv7/omap5/config.mk
+++ b/arch/arm/cpu/armv7/omap5/config.mk
@@ -6,8 +6,14 @@
 # SPDX-License-Identifier: GPL-2.0+
 #
 
+include  $(srctree)/$(CPUDIR)/omap-common/config_secure.mk
+
 ifdef CONFIG_SPL_BUILD
+ifeq ($(CONFIG_TI_SECURE_DEVICE),y)
+ALL-y  += u-boot-spl_HS_MLO u-boot-spl_HS_X-LOADER
+else
 ALL-y  += MLO
+endif
 else
 ALL-y  += u-boot.img
 endif
-- 
1.9.1

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

[U-Boot] [PATCH v2 08/15] ti: AM43xx: board: Detect AM43xx HS EVM

[Daniel Allred]

From: Madan Srinivas 

Adds code to detect AM43xx HS EVMS - the string in the
I2C EEPROM for HS EVMs differs from GP EVMs. Adds code to
for evm detection, regardless of whether the evm is for
GP or HS parts, and updates board init to use that.

Modifies findfdt command to pick up am437x-gp-evm.dtb for
the HS EVMs also, as the boards are similar except for
some security specific changes around power supply and
enclosure protection.

Signed-off-by: Madan Srinivas 
Signed-off-by: Daniel Allred 
Signed-off-by: Andreas Dannenberg 

Reviewed-by: Lokesh Vutla 
---

V2:
 Rebase against current master

 board/ti/am43xx/board.c  |  4 ++--
 board/ti/am43xx/board.h  | 14 --
 board/ti/am43xx/mux.c|  2 +-
 include/configs/am43xx_evm.h |  2 ++
 4 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/board/ti/am43xx/board.c b/board/ti/am43xx/board.c
index d208d2f..7247107 100644
--- a/board/ti/am43xx/board.c
+++ b/board/ti/am43xx/board.c
@@ -341,7 +341,7 @@ const struct dpll_params *get_dpll_ddr_params(void)
 
if (board_is_eposevm())
return _evm_dpll_ddr[ind];
-   else if (board_is_gpevm() || board_is_sk())
+   else if (board_is_evm() || board_is_sk())
return _evm_dpll_ddr;
else if (board_is_idk())
return _dpll_ddr;
@@ -553,7 +553,7 @@ void sdram_init(void)
enable_vtt_regulator();
config_ddr(0, _ddr3, NULL, NULL,
   _emif_regs_400Mhz_beta, 0);
-   } else if (board_is_gpevm()) {
+   } else if (board_is_evm()) {
enable_vtt_regulator();
config_ddr(0, _ddr3, NULL, NULL,
   _emif_regs_400Mhz, 0);
diff --git a/board/ti/am43xx/board.h b/board/ti/am43xx/board.h
index 2cf7a77..3f93d13 100644
--- a/board/ti/am43xx/board.h
+++ b/board/ti/am43xx/board.h
@@ -37,14 +37,24 @@ static inline int board_is_idk(void)
return board_ti_is("AM43_IDK");
 }
 
+static inline int board_is_hsevm(void)
+{
+   return board_ti_is("AM43XXHS");
+}
+
+static inline int board_is_evm(void)
+{
+   return board_is_gpevm() || board_is_hsevm();
+}
+
 static inline int board_is_evm_14_or_later(void)
 {
-   return (board_is_gpevm() && strncmp("1.4", board_ti_get_rev(), 3) <= 0);
+   return board_is_evm() && strncmp("1.4", board_ti_get_rev(), 3) <= 0;
 }
 
 static inline int board_is_evm_12_or_later(void)
 {
-   return (board_is_gpevm() && strncmp("1.2", board_ti_get_rev(), 3) <= 0);
+   return board_is_evm() && strncmp("1.2", board_ti_get_rev(), 3) <= 0;
 }
 
 void enable_uart0_pin_mux(void);
diff --git a/board/ti/am43xx/mux.c b/board/ti/am43xx/mux.c
index e03b1bc..f26b21e 100644
--- a/board/ti/am43xx/mux.c
+++ b/board/ti/am43xx/mux.c
@@ -126,7 +126,7 @@ void enable_board_pin_mux(void)
configure_module_pin_mux(i2c0_pin_mux);
configure_module_pin_mux(mdio_pin_mux);
 
-   if (board_is_gpevm()) {
+   if (board_is_evm()) {
configure_module_pin_mux(gpio5_7_pin_mux);
configure_module_pin_mux(rgmii1_pin_mux);
 #if defined(CONFIG_NAND)
diff --git a/include/configs/am43xx_evm.h b/include/configs/am43xx_evm.h
index 8a48a9a..a54303d 100644
--- a/include/configs/am43xx_evm.h
+++ b/include/configs/am43xx_evm.h
@@ -289,6 +289,8 @@
"setenv fdtfile am43x-epos-evm.dtb; fi; " \
"if test $board_name = AM43__GP; then " \
"setenv fdtfile am437x-gp-evm.dtb; fi; " \
+   "if test $board_name = AM43XXHS; then " \
+   "setenv fdtfile am437x-gp-evm.dtb; fi; " \
"if test $board_name = AM43__SK; then " \
"setenv fdtfile am437x-sk-evm.dtb; fi; " \
"if test $board_name = AM43_IDK; then " \
-- 
1.9.1

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

[U-Boot] [PATCH v2 12/15] ARM: omap-common: Add device type to CPU string

[Daniel Allred]

Update the CPU string output so that the device
type is now included as part of the CPU string that
is printed as the SPL or u-boot comes up. This update
adds a suffix of the form "-GP" or "-HS" for production
devices, so that general purpose (GP) and high security
(HS) can be distiguished. Applies to all OMAP5 variants.

Signed-off-by: Daniel Allred 
Signed-off-by: Madan Srinivas 
---

V2:
 Move device type defines to omap_common.h, remove duplicates

 arch/arm/cpu/armv7/omap-common/hwinit-common.c | 22 --
 arch/arm/include/asm/arch-omap3/cpu.h  |  7 +--
 arch/arm/include/asm/omap_common.h | 11 +++
 3 files changed, 32 insertions(+), 8 deletions(-)

diff --git a/arch/arm/cpu/armv7/omap-common/hwinit-common.c 
b/arch/arm/cpu/armv7/omap-common/hwinit-common.c
index 01c2d57..078bdd8 100644
--- a/arch/arm/cpu/armv7/omap-common/hwinit-common.c
+++ b/arch/arm/cpu/armv7/omap-common/hwinit-common.c
@@ -65,12 +65,30 @@ static void omap_rev_string(void)
u32 major_rev = (omap_rev & 0x0F00) >> 8;
u32 minor_rev = (omap_rev & 0x00F0) >> 4;
 
+   const char *sec_s;
+
+   switch (get_device_type()) {
+   case TST_DEVICE:
+   sec_s = "TST";
+   break;
+   case EMU_DEVICE:
+   sec_s = "EMU";
+   break;
+   case HS_DEVICE:
+   sec_s = "HS";
+   break;
+   case GP_DEVICE:
+   sec_s = "GP";
+   break;
+   default:
+   sec_s = "?";
+   }
+
if (soc_variant)
printf("OMAP");
else
printf("DRA");
-   printf("%x ES%x.%x\n", omap_variant, major_rev,
-  minor_rev);
+   printf("%x-%s ES%x.%x\n", omap_variant, sec_s, major_rev, minor_rev);
 }
 
 #ifdef CONFIG_SPL_BUILD
diff --git a/arch/arm/include/asm/arch-omap3/cpu.h 
b/arch/arm/include/asm/arch-omap3/cpu.h
index 53cc2b0..e8aa786 100644
--- a/arch/arm/include/asm/arch-omap3/cpu.h
+++ b/arch/arm/include/asm/arch-omap3/cpu.h
@@ -59,13 +59,8 @@ struct ctrl_id {
 #endif /* __ASSEMBLY__ */
 #endif /* __KERNEL_STRICT_NAMES */
 
-/* device type */
-#define DEVICE_MASK(0x7 << 8)
+/* boot pin mask */
 #define SYSBOOT_MASK   0x1F
-#define TST_DEVICE 0x0
-#define EMU_DEVICE 0x1
-#define HS_DEVICE  0x2
-#define GP_DEVICE  0x3
 
 /* device speed */
 #define SKUID_CLK_MASK 0xf
diff --git a/arch/arm/include/asm/omap_common.h 
b/arch/arm/include/asm/omap_common.h
index 8fb05e1..ac34b0e 100644
--- a/arch/arm/include/asm/omap_common.h
+++ b/arch/arm/include/asm/omap_common.h
@@ -717,6 +717,17 @@ static inline u8 is_dra72x(void)
 #define DRA722_ES2_0   0x07220200
 
 /*
+ * silicon device type
+ * Moving to common from cpu.h, since it is shared by various omap devices
+ */
+#define DEVICE_MASK (BIT(8) | BIT(9) | BIT(10))
+#define TST_DEVICE  0x0
+#define EMU_DEVICE  0x1
+#define HS_DEVICE   0x2
+#define GP_DEVICE   0x3
+
+
+/*
  * SRAM scratch space entries
  */
 #define OMAP_SRAM_SCRATCH_OMAP_REV SRAM_SCRATCH_SPACE_ADDR
-- 
1.9.1

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

[U-Boot] [PATCH v2 09/15] defconfig: Add a config for AM43xx secure part

[Daniel Allred]

From: Madan Srinivas 

Adds a new defconfig file for the AM43xx secure device.
This is the same as for the non-secure part, except for:
CONFIG_TI_SECURE_DEVICE option set to 'y'
CONFIG_ISW_ENTRY_ADDR updated for secure images.

Signed-off-by: Daniel Allred 
Signed-off-by: Madan Srinivas 
---

V2:
 Update to create a single HS defconfig, based off of the 
  one DT+DM version for AM437x.

 configs/am437x_hs_evm_defconfig | 53 +
 1 file changed, 53 insertions(+)
 create mode 100644 configs/am437x_hs_evm_defconfig

diff --git a/configs/am437x_hs_evm_defconfig b/configs/am437x_hs_evm_defconfig
new file mode 100644
index 000..c4accb6
--- /dev/null
+++ b/configs/am437x_hs_evm_defconfig
@@ -0,0 +1,53 @@
+CONFIG_ARM=y
+CONFIG_AM43XX=y
+CONFIG_TI_SECURE_DEVICE=y
+CONFIG_TARGET_AM43XX_EVM=y
+CONFIG_DM_SERIAL=y
+CONFIG_DM_GPIO=y
+CONFIG_SPL_STACK_R_ADDR=0x8200
+# Device tree file can be same on HS evm
+CONFIG_DEFAULT_DEVICE_TREE="am437x-gp-evm"
+CONFIG_SPL=y
+CONFIG_ISW_ENTRY_ADDR=0x40302ae0
+CONFIG_SPL_STACK_R=y
+CONFIG_SYS_EXTRA_OPTIONS="CONS_INDEX=1"
+CONFIG_HUSH_PARSER=y
+CONFIG_CMD_BOOTZ=y
+# CONFIG_CMD_IMLS is not set
+CONFIG_CMD_ASKENV=y
+# CONFIG_CMD_FLASH is not set
+CONFIG_CMD_MMC=y
+CONFIG_CMD_SF=y
+CONFIG_CMD_SPI=y
+CONFIG_CMD_I2C=y
+CONFIG_CMD_USB=y
+CONFIG_CMD_DFU=y
+CONFIG_CMD_GPIO=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_DHCP=y
+CONFIG_CMD_MII=y
+CONFIG_CMD_PING=y
+CONFIG_CMD_EXT2=y
+CONFIG_CMD_EXT4=y
+CONFIG_CMD_EXT4_WRITE=y
+CONFIG_CMD_FAT=y
+CONFIG_CMD_FS_GENERIC=y
+CONFIG_OF_CONTROL=y
+CONFIG_DM=y
+CONFIG_DM_MMC=y
+CONFIG_SPI_FLASH=y
+CONFIG_SPI_FLASH_MACRONIX=y
+CONFIG_SYS_NS16550=y
+CONFIG_TI_QSPI=y
+CONFIG_TIMER=y
+CONFIG_OMAP_TIMER=y
+CONFIG_USB=y
+CONFIG_USB_DWC3=y
+CONFIG_USB_DWC3_GADGET=y
+CONFIG_USB_DWC3_OMAP=y
+CONFIG_USB_DWC3_PHY_OMAP=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_GADGET_DOWNLOAD=y
+CONFIG_G_DNL_MANUFACTURER="Texas Instruments"
+CONFIG_G_DNL_VENDOR_NUM=0x0403
+CONFIG_G_DNL_PRODUCT_NUM=0xbd00
-- 
1.9.1

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

[U-Boot] [PATCH v2 05/15] ti: omap-common: Add commands for generating secure SPL images

[Daniel Allred]

Adds a centralized config_secure.mk in omap-common for
OMAP-style TI secure devices to use for boot image generation

Depending on the boot media, different images are needed for
secure devices. These commands generates u-boot*_HS_* files that
need to be used to boot secure devices.

Please refer to README.ti-secure for more information.

Signed-off-by: Daniel Allred 
Signed-off-by: Madan Srinivas 

Reviewed-by: Lokesh Vutla 
Tested-by: Andreas Dannenberg 
Reviewed-by: Tom Rini 
---

V2:
 None

 arch/arm/cpu/armv7/omap-common/config_secure.mk | 66 +
 1 file changed, 66 insertions(+)
 create mode 100644 arch/arm/cpu/armv7/omap-common/config_secure.mk

diff --git a/arch/arm/cpu/armv7/omap-common/config_secure.mk 
b/arch/arm/cpu/armv7/omap-common/config_secure.mk
new file mode 100644
index 000..c7bb101
--- /dev/null
+++ b/arch/arm/cpu/armv7/omap-common/config_secure.mk
@@ -0,0 +1,66 @@
+#
+# Copyright (C) 2016, Texas Instruments, Incorporated - http://www.ti.com/
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+quiet_cmd_mkomapsecimg = MKIMAGE $@
+ifneq ($(TI_SECURE_DEV_PKG),)
+ifneq ($(wildcard $(TI_SECURE_DEV_PKG)/scripts/create-boot-image.sh),)
+ifneq ($(CONFIG_SPL_BUILD),)
+cmd_mkomapsecimg = $(TI_SECURE_DEV_PKG)/scripts/create-boot-image.sh \
+   $(patsubst u-boot-spl_HS_%,%,$(@F)) $< $@ $(CONFIG_ISW_ENTRY_ADDR) \
+   $(if $(KBUILD_VERBOSE:1=), >/dev/null)
+else
+cmd_mkomapsecimg = $(TI_SECURE_DEV_PKG)/scripts/create-boot-image.sh \
+$(patsubst u-boot_HS_%,%,$(@F)) $< $@ $(CONFIG_ISW_ENTRY_ADDR) \
+$(if $(KBUILD_VERBOSE:1=), >/dev/null)
+endif
+else
+cmd_mkomapsecimg = echo "WARNING:" \
+   "$(TI_SECURE_DEV_PKG)/scripts/create-boot-image.sh not found." \
+   "$@ was NOT created!"
+endif
+else
+cmd_mkomapsecimg = echo "WARNING: TI_SECURE_DEV_PKG environment" \
+   "variable must be defined for TI secure devices. $@ was NOT created!"
+endif
+
+# Standard X-LOADER target (QPSI, NOR flash)
+u-boot-spl_HS_X-LOADER: $(obj)/u-boot-spl.bin
+   $(call if_changed,mkomapsecimg)
+
+# For MLO targets (SD card boot) the final file name
+# that is copied to the SD card fAT partition must
+# be MLO, so we make a copy of the output file to a
+# new file with that name
+u-boot-spl_HS_MLO: $(obj)/u-boot-spl.bin
+   $(call if_changed,mkomapsecimg)
+   @if [ -f $@ ]; then \
+   cp -f $@ MLO; \
+   fi
+
+# Standard 2ND target (certain peripheral boot modes)
+u-boot-spl_HS_2ND: $(obj)/u-boot-spl.bin
+   $(call if_changed,mkomapsecimg)
+
+# Standard ULO target (certain peripheral boot modes)
+u-boot-spl_HS_ULO: $(obj)/u-boot-spl.bin
+   $(call if_changed,mkomapsecimg)
+
+# Standard ISSW target (certain devices, various boot modes)
+u-boot-spl_HS_ISSW: $(obj)/u-boot-spl.bin
+   $(call if_changed,mkomapsecimg)
+
+# For SPI flash on AM335x and AM43xx, these
+# require special byte swap handling so we use
+# the SPI_X-LOADER target instead of X-LOADER
+# and let the create-boot-image.sh script handle
+# that
+u-boot-spl_HS_SPI_X-LOADER: $(obj)/u-boot-spl.bin
+   $(call if_changed,mkomapsecimg)
+
+# For supporting single stage XiP QSPI on AM43xx, the
+# image is a full u-boot file, not an SPL. In this case
+# the mkomapsecimg command looks for a u-boot-HS_* prefix
+u-boot_HS_XIP_X-LOADER: $(obj)/u-boot.bin
+   $(call if_changed,mkomapsecimg)
-- 
1.9.1

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

[U-Boot] [PATCH v2 07/15] ti: AM43xx: Use CONFIG options from SOC Kconfig

[Daniel Allred]

From: Madan Srinivas 

Updates configs/am43xx_evm.h to use CONFIG options from
SOC specific Kconfig file for various calculations.

On AM43x devices, the address of SPL entry point  depends on
the device type, i.e. whether it is secure or non-secure.

Further, for non-secure devices, the SPL entry point is different
between  USB HOST boot mode, other "memory" boot modes (MMC, NAND)
and "peripheral" boot modes (UART, USB)

To add to the complexity, on secure devices, in addition to the
above differences, the SPL entry point can change because of the
space occupied by other components (other than u-boot or spl)
that go into a secure boot image.

To prevent the user from having to modify source files every time
any component of the secure image changes, the value of
CONFIG_SPL_TEXT_BASE has been set using a Kconfig option that
is supplied in the am43xx_*_defconfig files

Using the CONFIG options also enables us to do away with some
compile time flags that were used to specify CONFIG_SPL_TEXT_BASE
for different boot modes.

On QSPI devices, the same problem described above occurs w.r.t. the
address of the u-boot entry point in flash, when booting secure
devices. To handle this, CONFIG_SYS_TEXT_BASE is also setup via
a Kconfig option and the defconfig files.

Signed-off-by: Madan Srinivas 
Signed-off-by: Daniel Allred 

Reviewed-by: Lokesh Vutla 
Tested-by: Andreas Dannenberg 
Reviewed-by: Tom Rini 
---
 
V2:
 Rebase against current master

 configs/am43xx_evm_qspiboot_defconfig |  1 +
 configs/am43xx_evm_usbhost_boot_defconfig |  1 +
 include/configs/am43xx_evm.h  | 19 +++
 3 files changed, 9 insertions(+), 12 deletions(-)

diff --git a/configs/am43xx_evm_qspiboot_defconfig 
b/configs/am43xx_evm_qspiboot_defconfig
index bda0ae1..79eac88 100644
--- a/configs/am43xx_evm_qspiboot_defconfig
+++ b/configs/am43xx_evm_qspiboot_defconfig
@@ -1,6 +1,7 @@
 CONFIG_ARM=y
 CONFIG_AM43XX=y
 CONFIG_TARGET_AM43XX_EVM=y
+CONFIG_ISW_ENTRY_ADDR=0x3000
 CONFIG_SYS_EXTRA_OPTIONS="SERIAL1,CONS_INDEX=1,QSPI,QSPI_BOOT"
 CONFIG_HUSH_PARSER=y
 CONFIG_CMD_BOOTZ=y
diff --git a/configs/am43xx_evm_usbhost_boot_defconfig 
b/configs/am43xx_evm_usbhost_boot_defconfig
index d9fc4de..9943be2 100644
--- a/configs/am43xx_evm_usbhost_boot_defconfig
+++ b/configs/am43xx_evm_usbhost_boot_defconfig
@@ -2,6 +2,7 @@ CONFIG_ARM=y
 CONFIG_AM43XX=y
 CONFIG_TARGET_AM43XX_EVM=y
 CONFIG_SPL=y
+CONFIG_ISW_ENTRY_ADDR=0x40300350
 CONFIG_SYS_EXTRA_OPTIONS="SERIAL1,CONS_INDEX=1,NAND,SPL_USB_HOST_SUPPORT"
 CONFIG_HUSH_PARSER=y
 CONFIG_CMD_BOOTZ=y
diff --git a/include/configs/am43xx_evm.h b/include/configs/am43xx_evm.h
index a35541b..8a48a9a 100644
--- a/include/configs/am43xx_evm.h
+++ b/include/configs/am43xx_evm.h
@@ -37,17 +37,10 @@
 #define CONFIG_POWER_TPS62362
 
 /* SPL defines. */
-#ifdef CONFIG_SPL_USB_HOST_SUPPORT
-/*
- * For USB host boot, ROM uses DMA for copying MLO from USB storage
- * and ARM internal ram is not accessible for DMA, so SPL text base
- * should be in OCMC ram
- */
-#define CONFIG_SPL_TEXT_BASE   0x40300350
-#else
-#define CONFIG_SPL_TEXT_BASE   0x402F4000
-#endif
-#define CONFIG_SPL_MAX_SIZE(220 << 10) /* 220KB */
+#define CONFIG_SPL_TEXT_BASE   CONFIG_ISW_ENTRY_ADDR
+#define CONFIG_SPL_MAX_SIZE(NON_SECURE_SRAM_END - \
+   CONFIG_PUB_ROM_DATA_SIZE - \
+   CONFIG_SPL_TEXT_BASE)
 #define CONFIG_SYS_SPL_ARGS_ADDR   (CONFIG_SYS_SDRAM_BASE + \
 (128 << 20))
 #define CONFIG_SPL_POWER_SUPPORT
@@ -190,7 +183,9 @@
 #endif
 
 #ifdef CONFIG_QSPI_BOOT
-#define CONFIG_SYS_TEXT_BASE   0x3000
+#ifndef CONFIG_SYS_TEXT_BASE
+#define CONFIG_SYS_TEXT_BASE   CONFIG_ISW_ENTRY_ADDR
+#endif
 #undef CONFIG_ENV_IS_IN_FAT
 #define CONFIG_ENV_IS_IN_SPI_FLASH
 #define CONFIG_SYS_REDUNDAND_ENVIRONMENT
-- 
1.9.1

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

[U-Boot] [PATCH v2 06/15] ti: AM43xx: config.mk: Add support for generating secure boot images

[Daniel Allred]

Modifies the config.mk to build secure images when building
the SPL for secure devices.

Depending on the boot media, different images are needed
for secure devices. The build generates u-boot*_HS_* files
as appropriate for the different boot modes. The same u-boot
binary file is processed slightly differently to produce a
different boot image, depending on whether the user wants to
boot off SPI, QSPI or other boot media.

Refer to README.ti-secure for more information.

Signed-off-by: Madan Srinivas 
Signed-off-by: Daniel Allred 

Reviewed-by: Lokesh Vutla 
Tested-by: Andreas Dannenberg 
Reviewed-by: Tom Rini 
---

V2:
 None

 arch/arm/cpu/armv7/am33xx/config.mk | 20 
 1 file changed, 20 insertions(+)

diff --git a/arch/arm/cpu/armv7/am33xx/config.mk 
b/arch/arm/cpu/armv7/am33xx/config.mk
index 5294d16..6d95d32 100644
--- a/arch/arm/cpu/armv7/am33xx/config.mk
+++ b/arch/arm/cpu/armv7/am33xx/config.mk
@@ -3,9 +3,29 @@
 #
 # SPDX-License-Identifier: GPL-2.0+
 #
+
+include  $(srctree)/$(CPUDIR)/omap-common/config_secure.mk
+
 ifdef CONFIG_SPL_BUILD
+ifeq ($(CONFIG_TI_SECURE_DEVICE),y)
+#
+# For booting from SPI use
+# u-boot-spl_HS_SPI_X-LOADER to program flash
+#
+# For booting spl from all other  media
+# use u-boot-spl_HS_ISSW
+#
+# Refer to README.ti-secure for more info
+#
+ALL-y  += u-boot-spl_HS_ISSW
+ALL-$(CONFIG_SPL_SPI_SUPPORT) += u-boot-spl_HS_SPI_X-LOADER
+else
 ALL-y  += MLO
 ALL-$(CONFIG_SPL_SPI_SUPPORT) += MLO.byteswap
+endif
 else
+ifeq ($(CONFIG_TI_SECURE_DEVICE),y)
+ALL-$(CONFIG_QSPI_BOOT) += u-boot_HS_XIP_X-LOADER
+endif
 ALL-y  += u-boot.img
 endif
-- 
1.9.1

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

[U-Boot] [PATCH v2 04/15] ti: omap-common: Add Kconfig file for secure device support

[Daniel Allred]

From: Madan Srinivas 

Defines CONFIG_TI_SECURE_DEVICE which needs to be turned on
when building images for secure devices. This flag is used
to invoke the secure image creation tools for creating a
boot image that can be used on secure devices. This flag
may also be used to conditionally compile code specific
to secure devices.

This terminology will be used by all OMAP architecture devices,
hence introducing to a common location.

With the creation of Kconfig for omap-common, moved the
sourcing of the Kconfig files for the omap3/4/5 and am33xx
devices from arch/arm/KConfig to the omap-common one.

Signed-off-by: Madan Srinivas 
Signed-off-by: Daniel Allred 

Reviewed-by: Lokesh Vutla 
Tested-by: Andreas Dannenberg 
Reviewed-by: Tom Rini 
---

V2:
 None

 arch/arm/Kconfig   |  8 +---
 arch/arm/cpu/armv7/omap-common/Kconfig | 17 +
 2 files changed, 18 insertions(+), 7 deletions(-)
 create mode 100644 arch/arm/cpu/armv7/omap-common/Kconfig

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 6577572..3c545f0 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -776,13 +776,7 @@ source "arch/arm/cpu/armv7/mx6/Kconfig"
 
 source "arch/arm/cpu/armv7/mx5/Kconfig"
 
-source "arch/arm/cpu/armv7/omap3/Kconfig"
-
-source "arch/arm/cpu/armv7/omap4/Kconfig"
-
-source "arch/arm/cpu/armv7/omap5/Kconfig"
-
-source "arch/arm/cpu/armv7/am33xx/Kconfig"
+source "arch/arm/cpu/armv7/omap-common/Kconfig"
 
 source "arch/arm/mach-orion5x/Kconfig"
 
diff --git a/arch/arm/cpu/armv7/omap-common/Kconfig 
b/arch/arm/cpu/armv7/omap-common/Kconfig
new file mode 100644
index 000..7b39506
--- /dev/null
+++ b/arch/arm/cpu/armv7/omap-common/Kconfig
@@ -0,0 +1,17 @@
+config TI_SECURE_DEVICE
+   bool "HS Device Type Support"
+   depends on OMAP54XX || AM43XX
+   help
+ If a high secure (HS) device type is being used, this config
+ must be set. This option impacts various aspects of the
+ build system (to create signed boot images that can be
+ authenticated) and the code. See the doc/README.ti-secure
+ file for further details.
+
+source "arch/arm/cpu/armv7/omap3/Kconfig"
+
+source "arch/arm/cpu/armv7/omap4/Kconfig"
+
+source "arch/arm/cpu/armv7/omap5/Kconfig"
+
+source "arch/arm/cpu/armv7/am33xx/Kconfig"
-- 
1.9.1

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

[U-Boot] [PATCH v2 03/15] arm: Kconfig: Add support for AM43xx SoC specific Kconfig

[Daniel Allred]

From: Madan Srinivas 

Adding support for AM43xx secure devices require the addition
of some SOC specific config options like the amount of memory
used by public ROM and the address of the entry point of u-boot
or SPL, as seen by the ROM code, for the image to be built
correctly.

This mandates the addition of am AM43xx CONFIG option and the
ARM Kconfig file has been modified to source this SOC Kconfig
file. Moving the TARGET_AM43XX_EVM config option to the SOC
KConfig and out of the arch/arm/Kconfig.

Updating defconfigs to add the CONFIG_AM43XX=y statement and
removing the #define CONFIG_AM43XX from the header file.

Signed-off-by: Madan Srinivas 
Signed-off-by: Daniel Allred 

Tested-by: Andreas Dannenberg 
---

V2:
 Update more defconfigs
 Replace CREATE_BOARD_SYMLINK with TI_I2C_BOARD_DETECT
 Rebase against latest master

 arch/arm/Kconfig  | 19 +--
 arch/arm/cpu/armv7/am33xx/Kconfig | 13 +
 configs/am437x_gp_evm_defconfig   |  1 +
 configs/am437x_sk_evm_defconfig   |  1 +
 configs/am43xx_evm_defconfig  |  1 +
 configs/am43xx_evm_ethboot_defconfig  |  1 +
 configs/am43xx_evm_qspiboot_defconfig |  1 +
 configs/am43xx_evm_usbhost_boot_defconfig |  1 +
 include/configs/am43xx_evm.h  |  2 --
 9 files changed, 32 insertions(+), 8 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 6b65d8e..6577572 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -381,12 +381,6 @@ config TARGET_AM335X_SL50
select DM
select DM_SERIAL
 
-config TARGET_AM43XX_EVM
-   bool "Support am43xx_evm"
-   select CPU_V7
-   select SUPPORT_SPL
-   select TI_I2C_BOARD_DETECT
-
 config TARGET_BAV335X
bool "Support bav335x"
select CPU_V7
@@ -507,6 +501,17 @@ config OMAP54XX
select CPU_V7
select SUPPORT_SPL
 
+config AM43XX
+   bool "AM43XX SoC"
+   select CPU_V7
+   select SUPPORT_SPL
+   help
+ Support for AM43xx SOC from Texas Instruments.
+ The AM43xx high performance SOC features a Cortex-A9
+ ARM core, a quad core PRU-ICSS for industrial Ethernet
+ protocols, dual camera support, optional 3D graphics
+ and an optional customer programmable secure boot.
+
 config RMOBILE
bool "Renesas ARM SoCs"
select CPU_V7
@@ -777,6 +782,8 @@ source "arch/arm/cpu/armv7/omap4/Kconfig"
 
 source "arch/arm/cpu/armv7/omap5/Kconfig"
 
+source "arch/arm/cpu/armv7/am33xx/Kconfig"
+
 source "arch/arm/mach-orion5x/Kconfig"
 
 source "arch/arm/cpu/armv7/rmobile/Kconfig"
diff --git a/arch/arm/cpu/armv7/am33xx/Kconfig 
b/arch/arm/cpu/armv7/am33xx/Kconfig
index 39759cd..dc51e9b 100644
--- a/arch/arm/cpu/armv7/am33xx/Kconfig
+++ b/arch/arm/cpu/armv7/am33xx/Kconfig
@@ -1,3 +1,15 @@
+if AM43XX
+config TARGET_AM43XX_EVM
+   bool "Support am43xx_evm"
+   select TI_I2C_BOARD_DETECT
+   help
+ This option specifies support for the AM43xx
+ GP and HS EVM development platforms.The AM437x
+ GP EVM is a standalone test, development, and
+ evaluation module system that enables developers
+ to write software and develop hardware around
+ an AM43xx processor subsystem.
+
 config ISW_ENTRY_ADDR
hex "Address in memory or XIP flash of bootloader entry point"
help
@@ -25,3 +37,4 @@ config PUB_ROM_DATA_SIZE
  image, this area is no longer used, and can be reclaimed
  for run time use by the boot image.
default 0x8400
+endif
diff --git a/configs/am437x_gp_evm_defconfig b/configs/am437x_gp_evm_defconfig
index 03b02ac..f036bc7 100644
--- a/configs/am437x_gp_evm_defconfig
+++ b/configs/am437x_gp_evm_defconfig
@@ -1,4 +1,5 @@
 CONFIG_ARM=y
+CONFIG_AM43XX=y
 CONFIG_TARGET_AM43XX_EVM=y
 CONFIG_DM_SERIAL=y
 CONFIG_DM_GPIO=y
diff --git a/configs/am437x_sk_evm_defconfig b/configs/am437x_sk_evm_defconfig
index 48ec91f..0251270 100644
--- a/configs/am437x_sk_evm_defconfig
+++ b/configs/am437x_sk_evm_defconfig
@@ -1,4 +1,5 @@
 CONFIG_ARM=y
+CONFIG_AM43XX=y
 CONFIG_TARGET_AM43XX_EVM=y
 CONFIG_DM_SERIAL=y
 CONFIG_DM_SPI=y
diff --git a/configs/am43xx_evm_defconfig b/configs/am43xx_evm_defconfig
index a6ae011..c9b6e6a 100644
--- a/configs/am43xx_evm_defconfig
+++ b/configs/am43xx_evm_defconfig
@@ -1,4 +1,5 @@
 CONFIG_ARM=y
+CONFIG_AM43XX=y
 CONFIG_TARGET_AM43XX_EVM=y
 CONFIG_SPL=y
 CONFIG_SYS_EXTRA_OPTIONS="SERIAL1,CONS_INDEX=1,NAND"
diff --git a/configs/am43xx_evm_ethboot_defconfig 
b/configs/am43xx_evm_ethboot_defconfig
index 662556a..e1499ad 100644
--- a/configs/am43xx_evm_ethboot_defconfig
+++ b/configs/am43xx_evm_ethboot_defconfig
@@ -1,4 +1,5 @@
 CONFIG_ARM=y
+CONFIG_AM43XX=y
 CONFIG_TARGET_AM43XX_EVM=y
 CONFIG_SPL=y
 CONFIG_SYS_EXTRA_OPTIONS="SERIAL1,CONS_INDEX=1,NAND,SPL_ETH_SUPPORT"
diff --git a/configs/am43xx_evm_qspiboot_defconfig 

[U-Boot] [PATCH v2 02/15] arm: am33xx: Kconfig: Add secure device definitions

[Daniel Allred]

From: Madan Srinivas 

Adds a new Kconfig file for AM33xx class devices. We
need a common place to define CONFIG parameters
for these SOCs, especially for adding support
for secure devices.

a) Adds a definition for ISW_ENTRY_ADDR. This is the
address to which the ROM branches when the SOC
ROM hands off execution to the boot loader.
CONFIG_SYS_TEXT_BASE and CONFIG_SPL_TEXT_BASE are set
to this value for AM43xx devices.

b) Adds CONFIG_PUB_ROM_DATA_SIZE which is used to
calculate CONFIG_SPL_MAX_SIZE. This value indicates the
amount of memory needed by the ROM to store data during
the boot process.

Currently, these CONFIG options are used only by AM43xx,
but in future other AM33xx class SOCs will also use them.

Signed-off-by: Madan Srinivas 
Signed-off-by: Daniel Allred 

Reviewed-by: Lokesh Vutla 
Tested-by: Andreas Dannenberg 
Reviewed-by: Tom Rini 
---

V2:
 None

 arch/arm/cpu/armv7/am33xx/Kconfig | 27 +++
 1 file changed, 27 insertions(+)
 create mode 100644 arch/arm/cpu/armv7/am33xx/Kconfig

diff --git a/arch/arm/cpu/armv7/am33xx/Kconfig 
b/arch/arm/cpu/armv7/am33xx/Kconfig
new file mode 100644
index 000..39759cd
--- /dev/null
+++ b/arch/arm/cpu/armv7/am33xx/Kconfig
@@ -0,0 +1,27 @@
+config ISW_ENTRY_ADDR
+   hex "Address in memory or XIP flash of bootloader entry point"
+   help
+ After any reset, the boot ROM on the AM43XX SOC
+ searches the boot media for a valid boot image.
+ For non-XIP devices, the ROM then copies the
+ image into internal memory.
+ For all boot modes, after the ROM processes the
+ boot image it eventually computes the entry
+ point address depending on the device type
+ (secure/non-secure), boot media (xip/non-xip) and
+ image headers.
+   default 0x402F4000
+
+config PUB_ROM_DATA_SIZE
+   hex "Size in bytes of the L3 SRAM reserved by ROM to store data"
+   help
+ During the device boot, the public ROM uses the top of
+ the public L3 OCMC RAM to store r/w data like stack,
+ heap, globals etc. When the ROM is copying the boot
+ image from the boot media into memory, the image must
+ not spill over into this area. This value can be used
+ during compile time to determine the maximum size of a
+ boot image. Once the ROM transfers control to the boot
+ image, this area is no longer used, and can be reclaimed
+ for run time use by the boot image.
+   default 0x8400
-- 
1.9.1

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

[U-Boot] [PATCH v2 01/15] doc: Add info on using secure devices from TI

[Daniel Allred]

Adds doc/README.ti-secure file to explain in generic terms
how boot images need to be created for secure devices from
Texas Instruments.

Specific details for creating secure boot images for the
AM43xx, DRA7xx and AM57xx secure devices from Texas
Instruments are also provided in the README file.

Secure devices require a security development package (SECDEV)
package that can be downloaded from:

http://www.ti.com/mysecuresoftware

Login is required and access is granted under appropriate NDA
and export control restrictions.

Signed-off-by: Madan Srinivas 
Signed-off-by: Daniel Allred 

Reviewed-by: Lokesh Vutla 
Reviewed-by: Andreas Dannenberg 
Reviewed-by: Tom Rini 
---

V2:
 Minor whitespace fixes

 doc/README.ti-secure | 91 
 1 file changed, 91 insertions(+)
 create mode 100644 doc/README.ti-secure

diff --git a/doc/README.ti-secure b/doc/README.ti-secure
new file mode 100644
index 000..7fc9b9b
--- /dev/null
+++ b/doc/README.ti-secure
@@ -0,0 +1,91 @@
+README on how boot images are created for secure TI devices
+
+CONFIG_TI_SECURE_DEVICE:
+Secure TI devices require a boot image that is authenticated by ROM
+code to function. Without this, even JTAG remains locked and the
+device is essentially useless. In order to create a valid boot image for
+a secure device from TI, the initial public software image must be signed
+and combined with various headers, certificates, and other binary images.
+
+Information on the details on the complete boot image format can be obtained
+from Texas Instruments. The tools used to generate boot images for secure
+devices are part of a secure development package (SECDEV) that can be
+downloaded from:
+
+   http://www.ti.com/mysecuresoftware (login required)
+
+The secure development package is access controlled due to NDA and export
+control restrictions. Access must be requested and granted by TI before the
+package is viewable and downloadable. Contact TI, either online or by way
+of a local TI representative, to request access.
+
+When CONFIG_TI_SECURE_DEVICE is set, the U-Boot SPL build process requires
+the presence and use of these tools in order to create a viable boot image.
+The build process will look for the environment variable TI_SECURE_DEV_PKG,
+which should be the path of the installed SECDEV package. If the
+TI_SECURE_DEV_PKG variable is not defined or if it is defined but doesn't
+point to a valid SECDEV package, a warning is issued during the build to
+indicate that a final secure bootable image was not created.
+
+Within the SECDEV package exists an image creation script:
+
+${TI_SECURE_DEV_PKG}/scripts/create-boot-image.sh
+
+This is called as part of the SPL/u-boot build process. As the secure boot
+image formats and requirements differ between secure SOC from TI, the
+purpose of this script is to abstract these details as much as possible.
+
+The script is basically the only required interface to the TI SECDEV package
+for secure TI devices.
+
+Invoking the script for AM43xx Secure Devices
+=
+
+create-boot-image.sh
+
+ is a value that specifies the type of the image to generate OR
+the action the image generation tool will take. Valid values are:
+   SPI_X-LOADER - Generates an image for SPI flash (byte swapped)
+   XIP_X-LOADER - Generates a single stage u-boot for NOR/QSPI XiP
+   ISSW - Generates an image for all other boot modes
+
+ is the full path and filename of the public world boot loader
+binary file (depending on the boot media, this is usually either
+u-boot-spl.bin or u-boot.bin).
+
+ is the full path and filename of the final secure image. The
+output binary images should be used in place of the standard non-secure
+binary images (see the platform-specific user's guides and releases notes
+for how the non-secure images are typically used)
+   u-boot-spl_HS_SPI_X-LOADER - byte swapped boot image for SPI flash
+   u-boot_HS_XIP_X-LOADER - boot image for NOR or QSPI flash
+   u-boot-spl_HS_ISSW - boot image for all other boot media
+
+ is the address at which SOC ROM should load the 
+
+Invoking the script for DRA7xx/AM57xx Secure Devices
+
+
+create-boot-image.sh   
+
+ is a value that specifies the type of the image to generate OR
+the action the image generation tool will take. Valid values are:
+   X-LOADER - Generates an image for NOR or QSPI boot modes
+   MLO - Generates an image for SD/MMC/eMMC boot modes
+   ULO - Generates an image for USB/UART peripheral boot modes
+   Note: ULO is not yet used by the u-boot build process
+
+ is the full path and filename of the public world boot loader
+binary file (for this platform, this is always u-boot-spl.bin).
+
+ is the full path and filename of the final secure image. The
+output binary images 

[U-Boot] [PATCH v2 00/15] Support for boot image creation for TI secure devices

[Daniel Allred]

Adds support for creating bootable images for AM43xx HS
and DRA7xx/AM57xx HS devices.

Daniel Allred (9):
  doc: Add info on using secure devices from TI
  ti: omap-common: Add commands for generating secure SPL images
  ti: AM43xx: config.mk: Add support for generating secure boot images
  ti_omap5_common: Update SPL start address on secure parts
  spl: build: ti: add support for secure boot images
  ARM: omap-common: Add device type to CPU string
  ARM: omap5: add hooks for cpu/SoC fdt fixups
  ARM: omap5: add ft_board_setup for dra7xx/am57xx
  defconfig: ti: Add configs for OMAP5-class secure parts

Madan Srinivas (6):
  arm: am33xx: Kconfig: Add secure device definitions
  arm: Kconfig: Add support for AM43xx SoC specific Kconfig
  ti: omap-common: Add Kconfig file for secure device support
  ti: AM43xx: Use CONFIG options from SOC Kconfig
  ti: AM43xx: board: Detect AM43xx HS EVM
  defconfig: Add a config for AM43xx secure part

 arch/arm/Kconfig|  23 +--
 arch/arm/cpu/armv7/am33xx/Kconfig   |  40 ++
 arch/arm/cpu/armv7/am33xx/config.mk |  20 +++
 arch/arm/cpu/armv7/omap-common/Kconfig  |  17 +++
 arch/arm/cpu/armv7/omap-common/config_secure.mk |  66 +
 arch/arm/cpu/armv7/omap-common/hwinit-common.c  |  22 ++-
 arch/arm/cpu/armv7/omap5/Makefile   |   1 +
 arch/arm/cpu/armv7/omap5/config.mk  |   6 +
 arch/arm/cpu/armv7/omap5/fdt.c  | 184 
 arch/arm/include/asm/arch-omap3/cpu.h   |   7 +-
 arch/arm/include/asm/omap_common.h  |  11 ++
 board/ti/am43xx/board.c |   4 +-
 board/ti/am43xx/board.h |  14 +-
 board/ti/am43xx/mux.c   |   2 +-
 board/ti/am57xx/board.c |   9 ++
 board/ti/dra7xx/evm.c   |   9 ++
 configs/am437x_gp_evm_defconfig |   1 +
 configs/am437x_hs_evm_defconfig |  53 +++
 configs/am437x_sk_evm_defconfig |   1 +
 configs/am43xx_evm_defconfig|   1 +
 configs/am43xx_evm_ethboot_defconfig|   1 +
 configs/am43xx_evm_qspiboot_defconfig   |   2 +
 configs/am43xx_evm_usbhost_boot_defconfig   |   2 +
 configs/am57xx_evm_defconfig|   1 +
 configs/am57xx_hs_evm_defconfig |  36 +
 configs/dra72_evm_defconfig |   1 +
 configs/dra72_hs_evm_defconfig  |  55 +++
 configs/dra74_evm_defconfig |   1 +
 configs/dra74_hs_evm_defconfig  |  54 +++
 doc/README.ti-secure|  91 
 include/configs/am43xx_evm.h|  23 ++-
 include/configs/ti_omap5_common.h   |  32 -
 32 files changed, 747 insertions(+), 43 deletions(-)
 create mode 100644 arch/arm/cpu/armv7/am33xx/Kconfig
 create mode 100644 arch/arm/cpu/armv7/omap-common/Kconfig
 create mode 100644 arch/arm/cpu/armv7/omap-common/config_secure.mk
 create mode 100644 arch/arm/cpu/armv7/omap5/fdt.c
 create mode 100644 configs/am437x_hs_evm_defconfig
 create mode 100644 configs/am57xx_hs_evm_defconfig
 create mode 100644 configs/dra72_hs_evm_defconfig
 create mode 100644 configs/dra74_hs_evm_defconfig
 create mode 100644 doc/README.ti-secure

-- 
1.9.1

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

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

[Angelo Dureghello]

Hi Simon,

sent v4.

Tested

- legacy serial driver and DM serial driver in mcf5307 "amcore" board
- buildman, pass all boards
- checkpatch

Regards,
angelo


On 26/04/2016 17:26, Simon Glass wrote:

Hi Angelo,

On 26 April 2016 at 03:03, Angelo Dureghello  wrote:


Hi Simon,

i realized this patch (v3) is invalid, due to my tests done with 
"CONFIG_DM_SRIAL" (missing 'A'), so was using the legacy driver still.

Also, i found a small issue in start.S files.

I send v4 asap later.


OK, thank you. I'll look out for it.

Regards,
Simon



thanks,

regards,
Angelo Dureghello



On 25/04/2016 23:54, Simon Glass wrote:


Hi Angelo,

On 24 April 2016 at 16:20, 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:
 - remove while loops in putc and getc, replacing with return -EAGAIN
 - remove unneeded ifdef
Changes for v3:
 - no changes
---
   drivers/serial/mcfuart.c | 188 
---
   1 file changed, 144 insertions(+), 44 deletions(-)



Missing file?

02: dm: gpio: pca953x: introduce driver model support for pca953x
03: m68k: add malloc memory for early malloc
04: m68k: add DM model serial driver
m68k:  +   M5329AFEE M5249EVB M5208EVBE M5475FFE M54451EVB
astro_mcf5373l M54418TWR_serial_rmii M54455EVB_intel amcore M5282EVB
M54455EVB_i66 M54455EVB_a66 M5475GFE M5485GFE M5253DEMO
M54455EVB_stm33 M5475AFE M54455EVB M5485BFE M5329BFEE M52277EVB
M5475EFE M54418TWR_nand_mii M5475CFE cobra5272 M5485AFE M5485HFE
M54418TWR_nand_rmii_lowfreq M5485DFE M5475DFE M5275EVB M54418TWR
M52277EVB_stmicro eb_cpu5282 eb_cpu5282_internal M53017EVB M5485CFE
M5475BFE M5485EFE M5253EVBE M5485FFE M5235EVB_Flash32 M5373EVB
M54418TWR_nand_rmii M54418TWR_serial_mii M5235EVB M54451EVB_stmicro
M5272C3
+../drivers/serial/mcfuart.c:18:46: fatal error:
dm/platform_data/serial_coldfire.h: No such file or directory
+ #include 
+  ^
+compilation terminated.
+make[2]: *** [drivers/serial/mcfuart.o] Error 1
+make[1]: *** [drivers/serial] Error 2

Regards,
Simon


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

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

[Angelo Dureghello]

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

diff --git a/drivers/serial/mcfuart.c b/drivers/serial/mcfuart.c
index 407354f..059cb0f 100644
--- a/drivers/serial/mcfuart.c
+++ b/drivers/serial/mcfuart.c
@@ -2,6 +2,9 @@
  * (C) Copyright 2004-2007 Freescale Semiconductor, Inc.
  * TsiChung Liew, tsi-chung.l...@freescale.com.
  *
+ * Modified to add device model (DM) support
+ * (C) Copyright 2015  Angelo Dureghello 
+ *
  * SPDX-License-Identifier:GPL-2.0+
  */
 
@@ -11,9 +14,10 @@
  */
 
 #include 
+#include 
+#include 
 #include 
 #include 
-
 #include 
 #include 
 
@@ -21,91 +25,110 @@ DECLARE_GLOBAL_DATA_PTR;
 
 extern void uart_port_conf(int port);
 
-static int mcf_serial_init(void)
+static int mcf_serial_init_common(uart_t *uart, int port_idx, int baudrate)
 {
-   volatile uart_t *uart;
u32 counter;
 
-   uart = (volatile uart_t *)(CONFIG_SYS_UART_BASE);
-
-   uart_port_conf(CONFIG_SYS_UART_PORT);
+   uart_port_conf(port_idx);
 
/* write to SICR: SIM2 = uart mode,dcd does not affect rx */
-   uart->ucr = UART_UCR_RESET_RX;
-   uart->ucr = UART_UCR_RESET_TX;
-   uart->ucr = UART_UCR_RESET_ERROR;
-   uart->ucr = UART_UCR_RESET_MR;
+   writeb(UART_UCR_RESET_RX, >ucr);
+   writeb(UART_UCR_RESET_TX, >ucr);
+   writeb(UART_UCR_RESET_ERROR, >ucr);
+   writeb(UART_UCR_RESET_MR, >ucr);
__asm__("nop");
 
-   uart->uimr = 0;
+   writeb(0, >uimr);
 
/* write to CSR: RX/TX baud rate from timers */
-   uart->ucsr = (UART_UCSR_RCS_SYS_CLK | UART_UCSR_TCS_SYS_CLK);
+   writeb(UART_UCSR_RCS_SYS_CLK | UART_UCSR_TCS_SYS_CLK, >ucsr);
 
-   uart->umr = (UART_UMR_BC_8 | UART_UMR_PM_NONE);
-   uart->umr = UART_UMR_SB_STOP_BITS_1;
+   writeb(UART_UMR_BC_8 | UART_UMR_PM_NONE, >umr);
+   writeb(UART_UMR_SB_STOP_BITS_1, >umr);
 
/* Setting up BaudRate */
-   counter = (u32) ((gd->bus_clk / 32) + (gd->baudrate / 2));
-   counter = counter / gd->baudrate;
+   counter = (u32) ((gd->bus_clk / 32) + (baudrate / 2));
+   counter = counter / baudrate;
 
/* write to CTUR: divide counter upper byte */
-   uart->ubg1 = (u8) ((counter & 0xff00) >> 8);
+   writeb((u8)((counter & 0xff00) >> 8), >ubg1);
/* write to CTLR: divide counter lower byte */
-   uart->ubg2 = (u8) (counter & 0x00ff);
+   writeb((u8)(counter & 0x00ff), >ubg2);
 
-   uart->ucr = (UART_UCR_RX_ENABLED | UART_UCR_TX_ENABLED);
+   writeb(UART_UCR_RX_ENABLED | UART_UCR_TX_ENABLED, >ucr);
 
return (0);
 }
 
+static void mcf_serial_setbrg_common(uart_t *uart, int baudrate)
+{
+   u32 counter;
+
+   /* Setting up BaudRate */
+   counter = (u32) ((gd->bus_clk / 32) + (baudrate / 2));
+   counter = counter / baudrate;
+
+   /* write to CTUR: divide counter upper byte */
+   writeb(((counter & 0xff00) >> 8), >ubg1);
+   /* write to CTLR: divide counter lower byte */
+   writeb((counter & 0x00ff), >ubg2);
+
+   writeb(UART_UCR_RESET_RX, >ucr);
+   writeb(UART_UCR_RESET_TX, >ucr);
+
+   writeb(UART_UCR_RX_ENABLED | UART_UCR_TX_ENABLED, >ucr);
+}
+
+#ifndef CONFIG_DM_SERIAL
+
+static int mcf_serial_init(void)
+{
+   uart_t *uart_base;
+   int port_idx;
+
+   uart_base = (uart_t *)CONFIG_SYS_UART_BASE;
+   port_idx = CONFIG_SYS_UART_PORT;
+
+   return mcf_serial_init_common(uart_base, port_idx, gd->baudrate);
+}
+
 static void mcf_serial_putc(const char c)
 {
-   volatile uart_t *uart = (volatile uart_t *)(CONFIG_SYS_UART_BASE);
+   uart_t *uart = (uart_t *)CONFIG_SYS_UART_BASE;
 
if (c == '\n')
serial_putc('\r');
 
/* Wait for last character to go. */
-   while (!(uart->usr & UART_USR_TXRDY)) ;
+   while (!(readb(>usr) & UART_USR_TXRDY))
+   ;
 
-   uart->utb = c;
+   writeb(c, >utb);
 }
 
 static int mcf_serial_getc(void)
 {
-   volatile uart_t *uart = (volatile uart_t *)(CONFIG_SYS_UART_BASE);
+   uart_t *uart = (uart_t *)CONFIG_SYS_UART_BASE;
 
/* Wait for a character to arrive. */
-   while (!(uart->usr & UART_USR_RXRDY)) ;
-   return uart->urb;
-}
-
-static int mcf_serial_tstc(void)
-{
-   volatile uart_t *uart = (volatile uart_t *)(CONFIG_SYS_UART_BASE);
+   

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

[Angelo Dureghello]

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(-)

diff --git a/arch/m68k/cpu/mcf5227x/start.S b/arch/m68k/cpu/mcf5227x/start.S
index 23024f9..13c036f 100644
--- a/arch/m68k/cpu/mcf5227x/start.S
+++ b/arch/m68k/cpu/mcf5227x/start.S
@@ -372,14 +372,29 @@ _start:
move.l %d0, (%a1)
move.l %d0, (%a2)
 
-   /* set stackpointer to end of internal ram to get some stackspace for
-  the first c-code */
-   move.l  #(CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_SP_OFFSET), %sp
-   clr.l %sp@-
+   /* put relocation table address to a5 */
+   move.l #__got_start, %a5
+
+   /* setup stack initially on top of internal static ram  */
+   move.l  #(CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_RAM_SIZE), %sp
+
+   /*
+* if configured, malloc_f arena will be reserved first,
+* then (and always) gd struct space will be reserved
+*/
+   move.l  %sp, -(%sp)
+   bsr board_init_f_alloc_reserve
+
+   /* update stack and frame-pointers */
+   move.l  %d0, %sp
+   move.l  %sp, %fp
 
-   move.l #__got_start, %a5/* put relocation table address to a5 */
+   /* initialize reserved area */
+   move.l  %d0, -(%sp)
+   bsr board_init_f_init_reserve
 
bsr cpu_init_f  /* run low-level CPU init code (from 
flash) */
+   clr.l   %sp@-
bsr board_init_f/* run low-level board init code (from 
flash) */
 
/* board_init_f() does not return */
diff --git a/arch/m68k/cpu/mcf523x/start.S b/arch/m68k/cpu/mcf523x/start.S
index 1702f98..3aa4dd6 100644
--- a/arch/m68k/cpu/mcf523x/start.S
+++ b/arch/m68k/cpu/mcf523x/start.S
@@ -134,17 +134,34 @@ _start:
move.l %d0, (%a1)
move.l %d0, (%a2)
 
-   /* set stackpointer to end of internal ram to get some stackspace for 
the
-  first c-code */
-   move.l  #(CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_SP_OFFSET), %sp
-   clr.l %sp@-
+   /* put relocation table address to a5 */
+   move.l #__got_start, %a5
 
-   move.l #__got_start, %a5/* put relocation table address to a5 */
+   /* setup stack initially on top of internal static ram  */
+   move.l  #(CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_RAM_SIZE), %sp
+
+   /*
+* if configured, malloc_f arena will be reserved first,
+* then (and always) gd struct space will be reserved
+*/
+   move.l  %sp, -(%sp)
+   move.l  #board_init_f_alloc_reserve, %a1
+   jsr (%a1)
+
+   /* update stack and frame-pointers */
+   move.l  %d0, %sp
+   move.l  %sp, %fp
+
+   /* initialize reserved area */
+   move.l  %d0, -(%sp)
+   move.l  #board_init_f_init_reserve, %a1
+   jsr (%a1)
 
/* run low-level CPU init code (from flash) */
move.l #cpu_init_f, %a1
jsr (%a1)
/* run low-level board init code (from flash) */
+   clr.l   %sp@-
move.l #board_init_f, %a1
jsr (%a1)
 
diff --git a/arch/m68k/cpu/mcf52x2/start.S b/arch/m68k/cpu/mcf52x2/start.S
index 4af691f..a048884 100644
--- a/arch/m68k/cpu/mcf52x2/start.S
+++ b/arch/m68k/cpu/mcf52x2/start.S
@@ -192,16 +192,34 @@ _after_flashbar_copy:
move.l %d0, (%a1)
move.l %d0, (%a2)
 
-   /* set stackpointer to end of internal ram to get some stackspace for 
the first c-code */
-   move.l  #(CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_SP_OFFSET), %sp
-   clr.l %sp@-
+   /* put relocation table address to a5 */
+   move.l #__got_start, %a5
 
-   move.l #__got_start, %a5/* put relocation table address 
to a5 */
+   /* setup stack initially on top of internal static ram  */
+   move.l  #(CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_RAM_SIZE), %sp
+
+   /*
+* if configured, malloc_f arena will be reserved first,
+* then (and always) gd struct space will be reserved
+*/
+   move.l  %sp, -(%sp)
+   move.l  #board_init_f_alloc_reserve, %a1
+   

Re: [U-Boot] [PATCH v2 1/2] drivers/video/am335x-fb: Add support for 16bpp format

[Martin Pietryka]

Hi Hannes,

I used git send-email and git format-patch manually, which was a bit of 
a hassle.


Now I used patman which seems to be really handy, thanks for the hint.


Martin

On 04/27/2016 12:07 PM, Hannes Schmelzer wrote:

Martin,

you have to send also a v2 from "2/2] drivers/video/am335x-fb: 
Properly point framebuffer behind palette".

v1 doesn't apply after your v2 patch below has been applied.

how do you manage your patch-generation and emailing?

have a look to: tools/patman/README, a really great tool for managing 
patch-series.


best regards,
Hannes

On 04/27/2016 11:42 AM, Martin Pietryka wrote:

To support 16bpp we just need to change the raster_ctrl register
accordingly. Also 32bpp mode should work as well, but was not tested.
According to the TRM the uppermost byte will be ignored when
LCD_TFT_24BPP_UNPACK is set.

The switch logic is based on the Liunx kernel tilcdc driver:
drivers/gpu/drm/tilcdc/tilcdc_crtc.c: lines 407 through 419
(kernel was checked out at commit: bcc981e9ed8)

Signed-off-by: Martin Pietryka 
---
  drivers/video/am335x-fb.c | 22 +++---
  1 file changed, 19 insertions(+), 3 deletions(-)

diff --git a/drivers/video/am335x-fb.c b/drivers/video/am335x-fb.c
index 0ec843f..569ecb6 100644
--- a/drivers/video/am335x-fb.c
+++ b/drivers/video/am335x-fb.c
@@ -5,7 +5,7 @@
   * minimal framebuffer driver for TI's AM335x SoC to be compatible 
with

   * Wolfgang Denk's LCD-Framework (CONFIG_LCD, common/lcd.c)
   *
- * - supporting only 24bit RGB/TFT raster Mode (not using palette)
+ * - supporting 16/24/32bit RGB/TFT raster Mode (not using palette)
   * - sets up LCD controller as in 'am335x_lcdpanel' struct given
   * - starts output DMA from gd->fb_base buffer
   *
@@ -106,6 +106,8 @@ int lcd_get_size(int *line_length)
int am335xfb_init(struct am335x_lcdpanel *panel)
  {
+u32 raster_ctrl = 0;
+
  if (0 == gd->fb_base) {
  printf("ERROR: no valid fb_base stored in 
GLOBAL_DATA_PTR!\n");

  return -1;
@@ -115,6 +117,21 @@ int am335xfb_init(struct am335x_lcdpanel *panel)
  return -1;
  }
  +/* We can already set the bits for the raster_ctrl in this 
check */

+switch (panel->bpp) {
+case 16:
+break;
+case 32:
+raster_ctrl |= LCD_TFT_24BPP_UNPACK;
+/* fallthrough */
+case 24:
+raster_ctrl |= LCD_TFT_24BPP_MODE;
+break;
+default:
+error("am335x-fb: invalid bpp value: %d\n", panel->bpp);
+return -1;
+}
+
  debug("setting up LCD-Controller for %dx%dx%d 
(hfp=%d,hbp=%d,hsw=%d / ",

panel->hactive, panel->vactive, panel->bpp,
panel->hfp, panel->hbp, panel->hsw);
@@ -157,8 +174,7 @@ int am335xfb_init(struct am335x_lcdpanel *panel)
  LCD_HBPMSB(panel->hbp) |
  LCD_HFPMSB(panel->hfp) |
  0xFF00;/* clk cycles for ac-bias */
-lcdhw->raster_ctrl =LCD_TFT_24BPP_MODE |
-LCD_TFT_24BPP_UNPACK |
+lcdhw->raster_ctrl =raster_ctrl |/* contains the bits 
for the pixel format */

  LCD_PALMODE_RAWDATA |
  LCD_TFT_MODE |
  LCD_RASTER_ENABLE;





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

[U-Boot] [PATCH v3 2/2] drivers/video/am335x-fb: Properly point framebuffer behind palette

[Martin Pietryka]

The DMA was outputting the palette on the screen because the base
for the DMA was not after the palette. In addition to that, the ceiling was
also too high, this led that the output on the screen was shifted.

NOTE: According to the TRM, even in 16/24bit mode a palette is required
in the first 32 bytes of the framebuffer.

See also:
https://e2e.ti.com/support/arm/sitara_arm/f/791/p/234967/834483#834483

"In this mode, the LCDC will assume all information is data and thus you
need to ensure that the DMA points to the first pixel of data and not the
first entry in the frame buffer which is the beginning of the 512 byte
palette."

Signed-off-by: Martin Pietryka 
Reviewed-by: Hannes Schmelzer 
Tested-by: Hannes Schmelzer 
---

Changes in v3: None

 drivers/video/am335x-fb.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/video/am335x-fb.c b/drivers/video/am335x-fb.c
index d984435..bb5cc97 100644
--- a/drivers/video/am335x-fb.c
+++ b/drivers/video/am335x-fb.c
@@ -143,6 +143,8 @@ int am335xfb_init(struct am335x_lcdpanel *panel)
/* palette default entry */
memset((void *)gd->fb_base, 0, 0x20);
*(unsigned int *)gd->fb_base = 0x4000;
+   /* point fb behind palette */
+   gd->fb_base += 0x20;
 
/* turn ON display through powercontrol function if accessible */
if (0 != panel->panel_power_ctrl)
@@ -154,9 +156,9 @@ int am335xfb_init(struct am335x_lcdpanel *panel)
lcdhw->raster_ctrl = 0;
lcdhw->ctrl = LCD_CLK_DIVISOR(panel->pxl_clk_div) | LCD_RASTER_MODE;
lcdhw->lcddma_fb0_base = gd->fb_base;
-   lcdhw->lcddma_fb0_ceiling = gd->fb_base + FBSIZE(panel) + 0x20;
+   lcdhw->lcddma_fb0_ceiling = gd->fb_base + FBSIZE(panel);
lcdhw->lcddma_fb1_base = gd->fb_base;
-   lcdhw->lcddma_fb1_ceiling = gd->fb_base + FBSIZE(panel) + 0x20;
+   lcdhw->lcddma_fb1_ceiling = gd->fb_base + FBSIZE(panel);
lcdhw->lcddma_ctrl = LCD_DMA_BURST_SIZE(LCD_DMA_BURST_16);
 
lcdhw->raster_timing0 = LCD_HORLSB(panel->hactive) |
@@ -179,8 +181,6 @@ int am335xfb_init(struct am335x_lcdpanel *panel)
LCD_TFT_MODE |
LCD_RASTER_ENABLE;
 
-   gd->fb_base += 0x20;/* point fb behind palette */
-
debug("am335x-fb: waiting picture to be stable.\n.");
mdelay(panel->pon_delay);
 
-- 
2.8.0

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

[U-Boot] [PATCH v3 1/2] drivers/video/am335x-fb: Add support for 16bpp format

[Martin Pietryka]

To support 16bpp we just need to change the raster_ctrl register
accordingly. Also 32bpp mode should work as well, but was not tested.
According to the TRM the uppermost byte will be ignored when
LCD_TFT_24BPP_UNPACK is set.

The switch logic is based on the Liunx kernel tilcdc driver:
drivers/gpu/drm/tilcdc/tilcdc_crtc.c: lines 407 through 419
(kernel was checked out at commit: bcc981e9ed8)

Signed-off-by: Martin Pietryka 
---

Changes in v3:
- Moved switch statement before changing any registers

 drivers/video/am335x-fb.c | 22 +++---
 1 file changed, 19 insertions(+), 3 deletions(-)

diff --git a/drivers/video/am335x-fb.c b/drivers/video/am335x-fb.c
index 0ec843f..d984435 100644
--- a/drivers/video/am335x-fb.c
+++ b/drivers/video/am335x-fb.c
@@ -5,7 +5,7 @@
  * minimal framebuffer driver for TI's AM335x SoC to be compatible with
  * Wolfgang Denk's LCD-Framework (CONFIG_LCD, common/lcd.c)
  *
- * - supporting only 24bit RGB/TFT raster Mode (not using palette)
+ * - supporting 16/24/32bit RGB/TFT raster Mode (not using palette)
  * - sets up LCD controller as in 'am335x_lcdpanel' struct given
  * - starts output DMA from gd->fb_base buffer
  *
@@ -106,6 +106,8 @@ int lcd_get_size(int *line_length)
 
 int am335xfb_init(struct am335x_lcdpanel *panel)
 {
+   u32 raster_ctrl = 0;
+
if (0 == gd->fb_base) {
printf("ERROR: no valid fb_base stored in GLOBAL_DATA_PTR!\n");
return -1;
@@ -115,6 +117,21 @@ int am335xfb_init(struct am335x_lcdpanel *panel)
return -1;
}
 
+   /* We can already set the bits for the raster_ctrl in this check */
+   switch (panel->bpp) {
+   case 16:
+   break;
+   case 32:
+   raster_ctrl |= LCD_TFT_24BPP_UNPACK;
+   /* fallthrough */
+   case 24:
+   raster_ctrl |= LCD_TFT_24BPP_MODE;
+   break;
+   default:
+   error("am335x-fb: invalid bpp value: %d\n", panel->bpp);
+   return -1;
+   }
+
debug("setting up LCD-Controller for %dx%dx%d (hfp=%d,hbp=%d,hsw=%d / ",
  panel->hactive, panel->vactive, panel->bpp,
  panel->hfp, panel->hbp, panel->hsw);
@@ -157,8 +174,7 @@ int am335xfb_init(struct am335x_lcdpanel *panel)
LCD_HBPMSB(panel->hbp) |
LCD_HFPMSB(panel->hfp) |
0xFF00; /* clk cycles for ac-bias */
-   lcdhw->raster_ctrl =LCD_TFT_24BPP_MODE |
-   LCD_TFT_24BPP_UNPACK |
+   lcdhw->raster_ctrl =raster_ctrl |
LCD_PALMODE_RAWDATA |
LCD_TFT_MODE |
LCD_RASTER_ENABLE;
-- 
2.8.0

___
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/26/2016 03:36 PM, Stephen Warren wrote:

On 04/26/2016 03: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().

2) uclass_find_device_by_name() needs to look up the uclass pointer again
even though device_bind() already knows it.

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?


4) This causes "ut dm autobind" to fail. I'll investigate that locally,
but won't bother reposting until the questions above are considered.


It looks like that's because I need to add "gd->dm_root && " to the 
start of the following condition:



@@ -62,6 +62,23 @@ int device_bind(struct udevice *parent, const struct driver 
*drv,
dev->driver = drv;
dev->uclass = uc;

+   if (!uclass_find_device_by_name(uc->uc_drv->id, dev->name, )) {


... otherwise, the uc_class_get/find() nested inside that end up 
creating a second root uclass.


I can fold that into v2, pending any other comments.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] imx6 devices failing to build with 2016.05

[Tom Rini]

On Wed, Apr 27, 2016 at 05:50:35PM +0200, Stefano Babic wrote:
> Hi Peter,
> 
> On 27/04/2016 12:15, Peter Robinson wrote:
> > Hi All,
> > 
> > I didn't look closely when it happened with rc1 because I saw a pull
> > req from Stefano shortly afterwards and I decided to try again after
> > that landed. With rc3 I'm still seeing the same issue.
> > 
> > Basically all the i.MX6 devices
> > (cm_fx6,mx6cuboxi,novena,riotboard,udoo,wandboard,warp) we currently
> > build for Fedora are failing to build. It looks very similar to some
> > 64 bit math issues [1] [2] a search gives me although from the linker
> > command I'm failing to see what code is at fault so any assistance in
> > debugging this would be great. I've checked it failed on < gcc6 too
> > and 2016.03 builds so it appears a regression in 05rcX.
> > 
> > The (for cuboxi example) basic error is:
> >   ld.bfd   -pie  --gc-sections -Bstatic -Ttext 0x1780 -o u-boot -T
> > u-boot.lds arch/arm/cpu/armv7/start.o --start-group
> > arch/arm/cpu/built-in.o  arch/arm/cpu/armv7/built-in.o
> > arch/arm/imx-common/built-in.o  arch/arm/lib/built-in.o
> > board/solidrun/mx6cuboxi/built-in.o  cmd/built-in.o  common/built-in.o
> >  disk/built-in.o  drivers/built-in.o  drivers/dma/built-in.o
> > drivers/gpio/built-in.o  drivers/i2c/built-in.o
> > drivers/mmc/built-in.o  drivers/mtd/built-in.o
> > drivers/mtd/onenand/built-in.o  drivers/mtd/spi/built-in.o
> > drivers/net/built-in.o  drivers/net/phy/built-in.o
> > drivers/pci/built-in.o  drivers/power/built-in.o
> > drivers/power/battery/built-in.o  drivers/power/fuel_gauge/built-in.o
> > drivers/power/mfd/built-in.o  drivers/power/pmic/built-in.o
> > drivers/power/regulator/built-in.o  drivers/serial/built-in.o
> > drivers/spi/built-in.o  drivers/usb/common/built-in.o
> > drivers/usb/dwc3/built-in.o  drivers/usb/emul/built-in.o
> > drivers/usb/eth/built-in.o  drivers/usb/gadget/built-in.o
> > drivers/usb/gadget/udc/built-in.o  drivers/usb/host/built-in.o
> > drivers/usb/musb-new/built-in.o  drivers/usb/musb/built-in.o
> > drivers/usb/phy/built-in.o  drivers/usb/ulpi/built-in.o  fs/built-in.o
> >  lib/built-in.o  net/built-in.o  test/built-in.o  test/dm/built-in.o
> > --end-group arch/arm/lib/eabi_compat.o  -L
> > /usr/lib/gcc/armv7hl-redhat-linux-gnueabi/6.0.0 -lgcc -Map u-boot.map
> > ld.bfd: error: 
> > /usr/lib/gcc/armv7hl-redhat-linux-gnueabi/6.0.0/libgcc.a(_udivmoddi4.o)
> > uses VFP register arguments, u-boot does not
> > ld.bfd: failed to merge target specific data of file
> > /usr/lib/gcc/armv7hl-redhat-linux-gnueabi/6.0.0/libgcc.a(_udivmoddi4.o)
> > 
> > Full log at https://pbrobinson.fedorapeople.org/u-boot-mx6cuboxi-fail.txt
> > 
> 
> I can confirm this - I started bisect and I have found this one:
> 
> commit 3cb4f25cc702db17455583599d0940c81337a17a
> Author: Peng Fan 
> Date:   Wed Mar 9 16:07:21 2016 +0800
> 
> video: ipu: avoid overflow issue
> 
> Multiplication, as "clk->parent->rate * 16" may overflow. So use
> do_div to avoid such issue.
> 
> Signed-off-by: Peng Fan 
> Signed-off-by: Sandor Yu 
> Cc: Anatolij Gustschin 
> Cc: Stefano Babic 
> Cc: Fabio Estevam 
> 
> :04 04 9672cb921a1051b5357931e8835884e2cccf8ec6
> 3cbbeea448780bb4855f5458dd98d017239b729a Mdrivers
> 
> 
> Checking the patch, I have found:
> 
> clk->rate = (u64)(clk->parent->rate * 16) / div;
> 
> 
> This seems the cause for the failing build.
> 
> This confirms an issue. IMHO we can replace it with:
> 
> clk->rate = (u64)lldiv(clk->parent->rate * 16, div);
> 
> Peng, what do you mind ?

I think other than the cast being in the wrong place for lldiv (rate is
ulong, but we want to treat clk->parent->rate * 16 as possibly u64) this
is right.  Can you send out a formal patch?  Thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH] fs: ext4: fix symlink read function

[Stephen Warren]

On 04/27/2016 10:40 AM, Stefan Roese wrote:

From: Ronald Zachariah 

The function ext4fs_read_symlink was unable to handle a symlink
which had target name of exactly 60 characters.


Reviewed-by: Stephen Warren 

This seems to match how the Linux kernel encodes symlinks.


-   if (__le32_to_cpu(diro->inode.size) <= 60) {
+   if (__le32_to_cpu(diro->inode.size) < 60) {


It'd be nice if "60" was replaced with sizeof(diro->inode.b.symlink), 
but that's probably a topic for a different patch.

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

[U-Boot] [verified-boot] Multiple levels of signing keys

[Teddy Reed]

Hello all,

I'm looking to support "multiple levels" of keys within u-boot's
verified boot. I need something similar to UEFI's key enrollment key
(KEK) and db/dbx model such that I can support on-line signing of new
kernels/rootfs/configurations.

To make this work we need a KEK that is not online (kept in a safe),
that can be used to sign expirations (revocations) of on-line signing
keys in the case of compromise or private key reveals. I know Chrome's
Coreboot verified boot model supports this, wondering if there's any
staged / WIP for u-boot?

Off the top of my head I'd imagine this requires extending the FIT to
include sets of public keys and a blacklist of keys and expired or bad
kernel/rootfs/etc hashes. Then either extending the boot code to
inspect multiple FITs or extending mkimage to combine multiple sources
to amalgamate a FIT containing the PK-signed set of keys + hashes and
the on-line key-signed kernels/rootfs/configurations.

P.S. This may be strongly linked to the need for a TPM to prevent
rollbacks. But as far as I can tell, the two features are distinct and
a TPM is not completely required for a multi-level key approach to
signing FITs.

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

Re: [U-Boot] imx6 devices failing to build with 2016.05

[Tom Rini]

On Wed, Apr 27, 2016 at 09:28:51AM -0700, Sergey Kubushyn wrote:

> Guys, it looks like it is already time to finally get that series of ARM lib
> patches in. This will occur again and again until it is done.
> 
> Face the reality -- not everybody uses a special softfloat toolchain just
> for building U-Boot. And it is simply pathetic to expect this when there is
> well proven solution which is in Linux kernel since the dawn of times.
> 
> Get those patches in please.

So, here's the problem, and partially why I didn't bring in Marek's last
series.  Even for just ARM it's not enough today and some combinations
of THUMB1 or ARMv8 targets were then starting to fail to build.  My hope
is that Marek can find the time to fix those up for v2016.07.

-- 
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] usb: dwc2: Init desc_before_addr

[Dinh Nguyen]

On 04/25/2016 08:08 PM, Marek Vasut wrote:
> Initialize desc_before_addr, otherwise the USB core won't send the
> first 64B Get Device Descriptor request in common/usb.c function
> usb_setup_descriptor() . There are some USB devices which expect
> this sequence and otherwise can misbehave.
> 
> Signed-off-by: Marek Vasut 
> Cc: Dinh Nguyen 
> Cc: Tom Rini 
> ---
>  drivers/usb/host/dwc2.c | 3 +++
>  1 file changed, 3 insertions(+)
> ---
> NOTE: I checked this with TotalPhase Beagle USB480 and it does what it is
>   supposed to do now. It would be wonderful to get this into rc3.
> 
> diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c
> index b2f4bc6..559c43f 100644
> --- a/drivers/usb/host/dwc2.c
> +++ b/drivers/usb/host/dwc2.c
> @@ -1182,6 +1182,9 @@ static int dwc2_usb_ofdata_to_platdata(struct udevice 
> *dev)
>  static int dwc2_usb_probe(struct udevice *dev)
>  {
>   struct dwc2_priv *priv = dev_get_priv(dev);
> + struct usb_bus_priv *bus_priv = dev_get_uclass_priv(dev);
> +
> + bus_priv->desc_before_addr = true;
>  
>   return dwc2_init_common(priv);
>  }
> 

With this patch, I no longer have to revert commit "c998da0d67091 usb:
Change power-on / scanning timeout handling" for my problematic Kingston
USB stick to work.

So feel free to add:

Tested-by: Dinh Nguyen 

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

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

[Stephen Warren]

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.


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.


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.


[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 physically force SW to write to each of those registers. 
"Support" here refers to what the ASIC team will guarantee will work 
correctly without causing glitches or similar issues. There are a few 
limited exceptions, e.g. console UART muxing on its own has been at 
least partially thought out (although there are still conflicts in some 
cases on older chips), and IO controllers that may contain boot media 
are generally OK to mux on their own. However, for anything else, i.e. 
the majority of cases, the supported model is to program everything 
up-front in one go, and not change it later. Sticking to that general 
model in absolutely all cases removes special cases and simplifies the code.

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

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

[Simon Glass]

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.

>
> I'd rather keep this series as simple cleanup of existing code, and handle
> any large-scale DM conversions separately later. That said, as full
> disclosure, I'm certainly not signing up for any more work on pinctrl,
> especially if it involves reading the pinmux tables from DT, as I see no
> benefit in that. Note that in future chips the boot ROM will handle 100% of
> static pinmux setup so there won't be a U-Boot driver for those SoCs going
> forward. I'd rather not invest any more than minimal effort in something
> that's going away.

There's no need for it to read from DT, and it doesn't have to be
comprehensive but I think you should create a pinctrl driver and put
the funcmux stuff in that (along with processing your big tables of
pinmux stuff).

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

Re: [U-Boot] imx6 devices failing to build with 2016.05

[Peter Robinson]

Hi Stefano,

>> I didn't look closely when it happened with rc1 because I saw a pull
>> req from Stefano shortly afterwards and I decided to try again after
>> that landed. With rc3 I'm still seeing the same issue.
>>
>> Basically all the i.MX6 devices
>> (cm_fx6,mx6cuboxi,novena,riotboard,udoo,wandboard,warp) we currently
>> build for Fedora are failing to build. It looks very similar to some
>> 64 bit math issues [1] [2] a search gives me although from the linker
>> command I'm failing to see what code is at fault so any assistance in
>> debugging this would be great. I've checked it failed on < gcc6 too
>> and 2016.03 builds so it appears a regression in 05rcX.
>>
>> The (for cuboxi example) basic error is:
>>   ld.bfd   -pie  --gc-sections -Bstatic -Ttext 0x1780 -o u-boot -T
>> u-boot.lds arch/arm/cpu/armv7/start.o --start-group
>> arch/arm/cpu/built-in.o  arch/arm/cpu/armv7/built-in.o
>> arch/arm/imx-common/built-in.o  arch/arm/lib/built-in.o
>> board/solidrun/mx6cuboxi/built-in.o  cmd/built-in.o  common/built-in.o
>>  disk/built-in.o  drivers/built-in.o  drivers/dma/built-in.o
>> drivers/gpio/built-in.o  drivers/i2c/built-in.o
>> drivers/mmc/built-in.o  drivers/mtd/built-in.o
>> drivers/mtd/onenand/built-in.o  drivers/mtd/spi/built-in.o
>> drivers/net/built-in.o  drivers/net/phy/built-in.o
>> drivers/pci/built-in.o  drivers/power/built-in.o
>> drivers/power/battery/built-in.o  drivers/power/fuel_gauge/built-in.o
>> drivers/power/mfd/built-in.o  drivers/power/pmic/built-in.o
>> drivers/power/regulator/built-in.o  drivers/serial/built-in.o
>> drivers/spi/built-in.o  drivers/usb/common/built-in.o
>> drivers/usb/dwc3/built-in.o  drivers/usb/emul/built-in.o
>> drivers/usb/eth/built-in.o  drivers/usb/gadget/built-in.o
>> drivers/usb/gadget/udc/built-in.o  drivers/usb/host/built-in.o
>> drivers/usb/musb-new/built-in.o  drivers/usb/musb/built-in.o
>> drivers/usb/phy/built-in.o  drivers/usb/ulpi/built-in.o  fs/built-in.o
>>  lib/built-in.o  net/built-in.o  test/built-in.o  test/dm/built-in.o
>> --end-group arch/arm/lib/eabi_compat.o  -L
>> /usr/lib/gcc/armv7hl-redhat-linux-gnueabi/6.0.0 -lgcc -Map u-boot.map
>> ld.bfd: error: 
>> /usr/lib/gcc/armv7hl-redhat-linux-gnueabi/6.0.0/libgcc.a(_udivmoddi4.o)
>> uses VFP register arguments, u-boot does not
>> ld.bfd: failed to merge target specific data of file
>> /usr/lib/gcc/armv7hl-redhat-linux-gnueabi/6.0.0/libgcc.a(_udivmoddi4.o)
>>
>> Full log at https://pbrobinson.fedorapeople.org/u-boot-mx6cuboxi-fail.txt
>>
>
> I can confirm this - I started bisect and I have found this one:

I can confirm reverting that allows them to build again. Will test
further once the build completes.

Peter

> commit 3cb4f25cc702db17455583599d0940c81337a17a
> Author: Peng Fan 
> Date:   Wed Mar 9 16:07:21 2016 +0800
>
> video: ipu: avoid overflow issue
>
> Multiplication, as "clk->parent->rate * 16" may overflow. So use
> do_div to avoid such issue.
>
> Signed-off-by: Peng Fan 
> Signed-off-by: Sandor Yu 
> Cc: Anatolij Gustschin 
> Cc: Stefano Babic 
> Cc: Fabio Estevam 
>
> :04 04 9672cb921a1051b5357931e8835884e2cccf8ec6
> 3cbbeea448780bb4855f5458dd98d017239b729a M  drivers
>
>
> Checking the patch, I have found:
>
> clk->rate = (u64)(clk->parent->rate * 16) / div;
>
>
> This seems the cause for the failing build.
>
> This confirms an issue. IMHO we can replace it with:
>
> clk->rate = (u64)lldiv(clk->parent->rate * 16, div);
>
> Peng, what do you mind ?
>
> Best regards,
> Stefano Babic
>
> --
> =
> DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
> =
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] fs: ext4: fix symlink read function

[Stefan Roese]

From: Ronald Zachariah 

The function ext4fs_read_symlink was unable to handle a symlink
which had target name of exactly 60 characters.

Signed-off-by: Ronald Zachariah 
Signed-off-by: Stefan Roese 
Cc: Stephen Warren 
Cc: Tom Rini 
---
 fs/ext4/ext4_common.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/ext4/ext4_common.c b/fs/ext4/ext4_common.c
index 84fba76..868c281 100644
--- a/fs/ext4/ext4_common.c
+++ b/fs/ext4/ext4_common.c
@@ -2040,7 +2040,7 @@ static char *ext4fs_read_symlink(struct ext2fs_node *node)
if (!symlink)
return 0;
 
-   if (__le32_to_cpu(diro->inode.size) <= 60) {
+   if (__le32_to_cpu(diro->inode.size) < 60) {
strncpy(symlink, diro->inode.b.symlink,
 __le32_to_cpu(diro->inode.size));
} else {
-- 
2.8.1

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

Re: [U-Boot] imx6 devices failing to build with 2016.05

[Sergey Kubushyn]

On Wed, 27 Apr 2016, Stefano Babic wrote:

Guys, it looks like it is already time to finally get that series of ARM lib
patches in. This will occur again and again until it is done.

Face the reality -- not everybody uses a special softfloat toolchain just
for building U-Boot. And it is simply pathetic to expect this when there is
well proven solution which is in Linux kernel since the dawn of times.

Get those patches in please.


Hi Peter,

On 27/04/2016 12:15, Peter Robinson wrote:

Hi All,

I didn't look closely when it happened with rc1 because I saw a pull
req from Stefano shortly afterwards and I decided to try again after
that landed. With rc3 I'm still seeing the same issue.

Basically all the i.MX6 devices
(cm_fx6,mx6cuboxi,novena,riotboard,udoo,wandboard,warp) we currently
build for Fedora are failing to build. It looks very similar to some
64 bit math issues [1] [2] a search gives me although from the linker
command I'm failing to see what code is at fault so any assistance in
debugging this would be great. I've checked it failed on < gcc6 too
and 2016.03 builds so it appears a regression in 05rcX.

The (for cuboxi example) basic error is:
  ld.bfd   -pie  --gc-sections -Bstatic -Ttext 0x1780 -o u-boot -T
u-boot.lds arch/arm/cpu/armv7/start.o --start-group
arch/arm/cpu/built-in.o  arch/arm/cpu/armv7/built-in.o
arch/arm/imx-common/built-in.o  arch/arm/lib/built-in.o
board/solidrun/mx6cuboxi/built-in.o  cmd/built-in.o  common/built-in.o
 disk/built-in.o  drivers/built-in.o  drivers/dma/built-in.o
drivers/gpio/built-in.o  drivers/i2c/built-in.o
drivers/mmc/built-in.o  drivers/mtd/built-in.o
drivers/mtd/onenand/built-in.o  drivers/mtd/spi/built-in.o
drivers/net/built-in.o  drivers/net/phy/built-in.o
drivers/pci/built-in.o  drivers/power/built-in.o
drivers/power/battery/built-in.o  drivers/power/fuel_gauge/built-in.o
drivers/power/mfd/built-in.o  drivers/power/pmic/built-in.o
drivers/power/regulator/built-in.o  drivers/serial/built-in.o
drivers/spi/built-in.o  drivers/usb/common/built-in.o
drivers/usb/dwc3/built-in.o  drivers/usb/emul/built-in.o
drivers/usb/eth/built-in.o  drivers/usb/gadget/built-in.o
drivers/usb/gadget/udc/built-in.o  drivers/usb/host/built-in.o
drivers/usb/musb-new/built-in.o  drivers/usb/musb/built-in.o
drivers/usb/phy/built-in.o  drivers/usb/ulpi/built-in.o  fs/built-in.o
 lib/built-in.o  net/built-in.o  test/built-in.o  test/dm/built-in.o
--end-group arch/arm/lib/eabi_compat.o  -L
/usr/lib/gcc/armv7hl-redhat-linux-gnueabi/6.0.0 -lgcc -Map u-boot.map
ld.bfd: error: 
/usr/lib/gcc/armv7hl-redhat-linux-gnueabi/6.0.0/libgcc.a(_udivmoddi4.o)
uses VFP register arguments, u-boot does not
ld.bfd: failed to merge target specific data of file
/usr/lib/gcc/armv7hl-redhat-linux-gnueabi/6.0.0/libgcc.a(_udivmoddi4.o)

Full log at https://pbrobinson.fedorapeople.org/u-boot-mx6cuboxi-fail.txt



I can confirm this - I started bisect and I have found this one:

commit 3cb4f25cc702db17455583599d0940c81337a17a
Author: Peng Fan 
Date:   Wed Mar 9 16:07:21 2016 +0800

   video: ipu: avoid overflow issue

   Multiplication, as "clk->parent->rate * 16" may overflow. So use
   do_div to avoid such issue.

   Signed-off-by: Peng Fan 
   Signed-off-by: Sandor Yu 
   Cc: Anatolij Gustschin 
   Cc: Stefano Babic 
   Cc: Fabio Estevam 

:04 04 9672cb921a1051b5357931e8835884e2cccf8ec6
3cbbeea448780bb4855f5458dd98d017239b729a M  drivers


Checking the patch, I have found:

clk->rate = (u64)(clk->parent->rate * 16) / div;


This seems the cause for the failing build.

This confirms an issue. IMHO we can replace it with:

clk->rate = (u64)lldiv(clk->parent->rate * 16, div);

Peng, what do you mind ?

Best regards,
Stefano Babic

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



---
**
*  KSI@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

[Stephen Warren]

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.


I'd rather keep this series as simple cleanup of existing code, and 
handle any large-scale DM conversions separately later. That said, as 
full disclosure, I'm certainly not signing up for any more work on 
pinctrl, especially if it involves reading the pinmux tables from DT, as 
I see no benefit in that. Note that in future chips the boot ROM will 
handle 100% of static pinmux setup so there won't be a U-Boot driver for 
those SoCs going forward. I'd rather not invest any more than minimal 
effort in something that's going away.

___
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/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.



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.



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 haven't looked at Barebox much. IIRC it only supports Tegra20 and not 
later SoCs which could simplify things. Besides, I'm not arguing that 
it's impossible to make a unified binary, simply that I don't see any 
need to do so, except perhaps your compile-coverage suggestion.



As an aside, I've wondered whether U-Boot should be split into multiple
parts; one HW-specific binary providing various drivers (e.g. via DM-related
APIs?) and the other containing just high-level user-interface code such as
the shell, high-level USB/... protocols, which would only call into those
APIs. Still, I don't think we're anywhere close to that, and I'm not aware
that it's a goal of the project at the moment.


Well it gets built as one binary, but there's a 

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

[Marek Vasut]

On 04/27/2016 11:04 AM, Diego wrote:
> 
> 
> Il 27 aprile 2016 04:14:45 CEST, Marek Vasut  ha scritto:
>> On 04/15/2016 02:13 PM, Diego wrote:
>>>
>>> Hi Marek,
>>>
>>> yes, I was getting the following error with the Kingston DTSE9 USB
>> 2.0:
>>> EHCI timed out on TD - token=0x1e008d80
>>> EHCI timed out on TD - token=0x1e008d80
>>> EHCI timed out on TD - token=0x1e008d80
>>> The model is the one in this photo:
>>>
>> http://katteway.com/images/Kingston-DataTraveler-DTSE9-8GB-USB-Flash-Drive-Silver.jpg
>>> ID 0951:1689 Kingston Technology DataTraveler SE9
>>>
>>> I'm available if you want any additional info.
>>
>> This Kingston DTSE9 seems to be really pure evil. I connected it to
>> TotalPhase Beagle USB 480 and plugged it into a PC and the bloody
>> stick generates broken packets at the beginning. I suspect this is
>> so bad that it crashes DWC2 controller if plugged directly into it.
>>
>> I didn't try investigating it with another EHCI controller yet.
>> Which CPU do you use on your system?
>>
> 
> Hi Marek,
> 
> I'm using a Boundary Devices Nitrogen6x with Freescale / NXP i.MX6Q SOC.

OK, I have to two identical sticks and neither has the same USB ID as
yours. Can you do lsusb -vvv -d 0951:1689 ?


-- 
Best regards,
Marek Vasut
___
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

[Stephen Warren]

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

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

Re: [U-Boot] imx6 devices failing to build with 2016.05

[Stefano Babic]

Hi Peter,

On 27/04/2016 12:15, Peter Robinson wrote:
> Hi All,
> 
> I didn't look closely when it happened with rc1 because I saw a pull
> req from Stefano shortly afterwards and I decided to try again after
> that landed. With rc3 I'm still seeing the same issue.
> 
> Basically all the i.MX6 devices
> (cm_fx6,mx6cuboxi,novena,riotboard,udoo,wandboard,warp) we currently
> build for Fedora are failing to build. It looks very similar to some
> 64 bit math issues [1] [2] a search gives me although from the linker
> command I'm failing to see what code is at fault so any assistance in
> debugging this would be great. I've checked it failed on < gcc6 too
> and 2016.03 builds so it appears a regression in 05rcX.
> 
> The (for cuboxi example) basic error is:
>   ld.bfd   -pie  --gc-sections -Bstatic -Ttext 0x1780 -o u-boot -T
> u-boot.lds arch/arm/cpu/armv7/start.o --start-group
> arch/arm/cpu/built-in.o  arch/arm/cpu/armv7/built-in.o
> arch/arm/imx-common/built-in.o  arch/arm/lib/built-in.o
> board/solidrun/mx6cuboxi/built-in.o  cmd/built-in.o  common/built-in.o
>  disk/built-in.o  drivers/built-in.o  drivers/dma/built-in.o
> drivers/gpio/built-in.o  drivers/i2c/built-in.o
> drivers/mmc/built-in.o  drivers/mtd/built-in.o
> drivers/mtd/onenand/built-in.o  drivers/mtd/spi/built-in.o
> drivers/net/built-in.o  drivers/net/phy/built-in.o
> drivers/pci/built-in.o  drivers/power/built-in.o
> drivers/power/battery/built-in.o  drivers/power/fuel_gauge/built-in.o
> drivers/power/mfd/built-in.o  drivers/power/pmic/built-in.o
> drivers/power/regulator/built-in.o  drivers/serial/built-in.o
> drivers/spi/built-in.o  drivers/usb/common/built-in.o
> drivers/usb/dwc3/built-in.o  drivers/usb/emul/built-in.o
> drivers/usb/eth/built-in.o  drivers/usb/gadget/built-in.o
> drivers/usb/gadget/udc/built-in.o  drivers/usb/host/built-in.o
> drivers/usb/musb-new/built-in.o  drivers/usb/musb/built-in.o
> drivers/usb/phy/built-in.o  drivers/usb/ulpi/built-in.o  fs/built-in.o
>  lib/built-in.o  net/built-in.o  test/built-in.o  test/dm/built-in.o
> --end-group arch/arm/lib/eabi_compat.o  -L
> /usr/lib/gcc/armv7hl-redhat-linux-gnueabi/6.0.0 -lgcc -Map u-boot.map
> ld.bfd: error: 
> /usr/lib/gcc/armv7hl-redhat-linux-gnueabi/6.0.0/libgcc.a(_udivmoddi4.o)
> uses VFP register arguments, u-boot does not
> ld.bfd: failed to merge target specific data of file
> /usr/lib/gcc/armv7hl-redhat-linux-gnueabi/6.0.0/libgcc.a(_udivmoddi4.o)
> 
> Full log at https://pbrobinson.fedorapeople.org/u-boot-mx6cuboxi-fail.txt
> 

I can confirm this - I started bisect and I have found this one:

commit 3cb4f25cc702db17455583599d0940c81337a17a
Author: Peng Fan 
Date:   Wed Mar 9 16:07:21 2016 +0800

video: ipu: avoid overflow issue

Multiplication, as "clk->parent->rate * 16" may overflow. So use
do_div to avoid such issue.

Signed-off-by: Peng Fan 
Signed-off-by: Sandor Yu 
Cc: Anatolij Gustschin 
Cc: Stefano Babic 
Cc: Fabio Estevam 

:04 04 9672cb921a1051b5357931e8835884e2cccf8ec6
3cbbeea448780bb4855f5458dd98d017239b729a M  drivers


Checking the patch, I have found:

clk->rate = (u64)(clk->parent->rate * 16) / div;


This seems the cause for the failing build.

This confirms an issue. IMHO we can replace it with:

clk->rate = (u64)lldiv(clk->parent->rate * 16, div);

Peng, what do you mind ?

Best regards,
Stefano Babic

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

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

[Dan Murphy]

Joe

On 04/26/2016 04:44 PM, Joe Hershberger wrote:
> On Mon, Apr 25, 2016 at 4:35 PM, Joe Hershberger
>  wrote:
>> On Fri, Apr 15, 2016 at 7:27 AM, Dan Murphy  wrote:
>>> 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 
>> Acked-by: Joe Hershberger 
> This patch is not checkpatch.pl clean. Please resubmit.
>
>
> 610950.mbox:140: WARNING: line over 80 characters
> 610950.mbox:153: WARNING: line over 80 characters
> 610950.mbox:154: WARNING: line over 80 characters
> 610950.mbox:165: WARNING: line over 80 characters
> total: 0 errors, 4 warnings, 0 checks, 136 lines checked

How do you want me to rebase these patches on the SGMII work from Michal on the 
ti.c
or off of master?  The patch I submitted was based off of the SGMII patchset.

Need to know how you want to handle this as I see the SGMII code is not in the 
base line
yet.

Dan

-- 
--
Dan Murphy

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

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

[Dan Murphy]

Joe

On 04/26/2016 04:42 PM, Joe Hershberger wrote:
> On Mon, Apr 25, 2016 at 4:32 PM, Joe Hershberger
>  wrote:
>> On Fri, Apr 15, 2016 at 7:27 AM, Dan Murphy  wrote:
>>> 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.
>> It would be great if the phy could be handled generically.
>> Unfortunately there is no uniform description so far, so having each
>> driver parse it is the best we can do for now.
>>
>>> 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 
>> Acked-by: Joe Hershberger 
> This patch is not checkpatch.pl clean. Please resubmit.
>
>
> 610946.mbox:57: WARNING: line over 80 characters
> 610946.mbox:59: WARNING: line over 80 characters
> 610946.mbox:62: WARNING: line over 80 characters
> 610946.mbox:62: CHECK: Alignment should match open parenthesis
> 610946.mbox:65: WARNING: line over 80 characters
> 610946.mbox:66: WARNING: line over 80 characters
> total: 0 errors, 5 warnings, 1 checks, 39 lines checked
I can only fix a few there will still be at least 2 LTL warnings on this file 
and fixing
it will break readability

I don't see how to fix this.

WARNING: line over 80 characters
#46: FILE: drivers/net/cpsw.c:1230:
+if (priv->data.slave_data[slave_index].phy_of_handle >= 0) {

WARNING: line over 80 characters
#49: FILE: drivers/net/cpsw.c:1233:
+   
priv->data.slave_data[slave_index].phy_of_handle,

Dan

-- 
--
Dan Murphy

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

Re: [U-Boot] [RFC] SPL -> U-Boot Chain of Trust

[Andreas Dannenberg]

On Wed, Apr 27, 2016 at 08:34:50AM -0600, Simon Glass wrote:
> Hi Andreas,
> 
> On 14 April 2016 at 17:07, Andreas Dannenberg  wrote:
> >
> > Hi Simon, thanks for the feedback. Additional comments inlined...
> >
> > On Mon, Apr 04, 2016 at 06:04:15PM -0600, Simon Glass wrote:
> > > Hi Andreas,
> > >
> > > On 28 March 2016 at 14:19, Andreas Dannenberg  wrote:
> > > > On Mon, Mar 28, 2016 at 03:32:40PM -0400, Tom Rini wrote:
> > > >> I'm interested in getting secure device support going, but it seems
> > > >> like we should need more than that, ie something to keep the chain of
> > > >> trust going.
> > > >
> > > > Tom et al.,
> > > > I just saw your reply to Vitaly's email and I'm actually just looking
> > > > into something along the lines you brought up but I didn't want to
> > > > hijack that discussion so here's a new thread.
> > > >
> > > > As for the chain of trust for ARMv7, my understanding is that when
> > > > using a combination of SPL and U-Boot there will always be a vendor-
> > > > specific initial boot (ROM) code that authenticates SPL, and then there
> > > > will need to be some code inserted into SPL that authenticates U-Boot
> > > > after it's loaded (for example by using some secure ROM API call and
> > > > such).
> > > >
> > > > So I was looking into if there is already some generic framework for
> > > > this in U-Boot but didn't see anything obvious. One "easy" way would be
> > > > to add a simple call to an authentication routine to board_init_r
> > > > (u-boot/common/spl/spl.c) but let's say we add such a call for TI or
> > > > other vendor's stuff I suppose this would not scale very well.
> > > >
> > > > But what about adding one generic call to a default authentication
> > > > function declared as __weak for spl_image that doesn't do anything, but
> > > > can be overwritten in vendor-specific files to provide means of
> > > > authenticating spl_image. Would this be a good approach?
> > > >
> > > >
> > > >
> > > > Beyond that I was reviewing some of the awesome work from the Chromium
> > > > team and I think on ARMv7 after we get MLO to authenticate U-Boot
> > > > everything beyond that is already looking very solid and thorough (with
> > > > FIT, DTB/Kernel and initramfs authentication).
> > >
> > > It should be possible to use this from SPL, if you can enable FIT in
> > > SPL. The current implementation does not support verification, and is
> > > deliberately cut down. See common/spl/spl_fit.c.
> >
> > Oh, I just noticed this file after doing a pull, that's really one step
> > ahead of the U-Boot versions I've worked with so far. Upon further
> > digging I found that the general SPL FIT approach is actually something
> > we are trying to enable for our own customers moving forward. So adding/
> > enabling FIT auth in SPL would really help connecting the dots and
> > closing the current authentication gap not just for us but actually for
> > all U-Boot users.
> 
> Agreed.
> 
> >
> > Will look at this more closely and see how much overhead this would
> > involve since for SPL memory can be of an issue, as using SPL
> > authenticated FIT will probably mean pulling in the U-Boot crypto stuff
> > as in such case we would be using U-Boot tooling to generate the signed
> > FIT image (as opposed to a vendor-specific signing tool generating an
> > image compatible with a simple SoC ROM API auth call). But looking at
> > the already memory-optimized U-Boot RSA verification code in
> > rsa-verify.c and rsa-checksum.c I would hope the impact would not be too
> > bad. I'd guess maybe 10-20KB total with SHA256, RSA, and the needed code
> > changes to spl_fit.c.
> 
> The overhead for U-Boot itself is covered in the 'Verified Boot on
> Chrome OS and How to do it yourself' talk here:
> 
> http://elinux.org/ELC_Europe_2013_Presentations
> 
> Verified boot itself is about 6KB on Thumb 2, on top of the FIT overhead.

Hi Simon,
I had actually seen/reviewed this presentation earlier and thought it was
very helpful to get started so thanks for pointing this out again.

> > > but you could perhaps
> > > provide an option to use the full U-Boot implementation instead.
> >
> > ...which would mean that the entire U-Boot would need to be loaded
> > initially as one piece which wouldn't work on some of our SoCs due to
> > memory constraints (hence the SPL approach).
> 
> No I don't mean that. I mean use the full U-Boot FIT implementation,
> i.e. just the same code. It would still run in FIT.

Ok understood, that would seem to make it easier/cleaner from an
implementation POV. Still, I've concerns specifically with one of our
SoCs of which its high-security device variant apparently only has
something to the order of 45KB for SPL use, which folks had to make a
lot of effort to strip down/squeeze in a custom SPL, even going as far
as trimming down strings (and that's using a proprietary authentication
scheme for U-Boot that almost doesn't take any space at all). I need to

Re: [U-Boot] [PATCH] pci: tegra: fix DM conversion issues on Tegra20

[Simon Glass]

Hi Stephen,

On 20 April 2016 at 15:46, Stephen Warren  wrote:
> From: Stephen Warren 
>
> Tegra20's PCIe controller has a couple of quirks. There are workarounds in
> the driver for these, but they don't work after the DM conversion:
>
> 1) The PCI_CLASS value is wrong in HW.
>
> This is worked around in pci_tegra_read_config() by patching up the value
> read from that register. Pre-DM, the PCIe core always read this via a
> 16-bit access to the 16-bit offset 0xa. With DM, 32-bit accesses are used,
> so we need to check for offset 0x8 instead. Mask the offset value back to
> 32-bit alignment to make this work in all cases.
>
> 2) Accessing devices other than dev 1 causes a data abort.
>
> Pre-DM, this was worked around in pci_skip_dev(), which the PCIe core code
> called during enumeration while iterating over a bus. The DM PCIe core
> doesn't use this function. Instead, enhance tegra_pcie_conf_address() to
> validate the bdf being accessed, and refuse to access invalid devices.
> Since pci_skip_dev() isn't used, delete it.
>
> I've also validated that both these WARs are only needed for Tegra20, by
> testing on Tegra30/Cardhu and Tegra124/Jetson TKx. So, compile them in
> conditionally.
>
> Fixes: e81ca88451cf ("dm: tegra: pci: Convert tegra boards to driver model 
> for PCI")
> Signed-off-by: Stephen Warren 
> ---
>  drivers/pci/pci_tegra.c | 21 ++---
>  1 file changed, 10 insertions(+), 11 deletions(-)

Nice patch.

Reviewed-by: Simon Glass 

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

Re: [U-Boot] [PATCH V4, 1/6] dm: gpio: add a default gpio xlate routine

[Simon Glass]

On 24 April 2016 at 17:32, Eric Nelson  wrote:
> Many drivers use a common form of offset + flags for device
> tree nodes. e.g.:
> < 2 GPIO_ACTIVE_LOW>
>
> This patch adds a common implementation of this type of parsing
> and calls it when a gpio driver doesn't supply its' own xlate
> routine.
>
> This will allow removal of the driver-specific versions in a
> handful of drivers and simplify the addition of new drivers.
>
> Signed-off-by: Eric Nelson 
> Reviewed-by: Stephen Warren 
> ---
>   V2 removes parsing of offset from the gpio_find_and_xlate routine,
>   and only parses the offset and GPIO_ACTIVE_LOW flag when a
>   driver-specific xlate is unavailable.
>
>   V3 re-works tests of the argument count as suggested by Stephen Warren
>   and will allow parsing of nodes with no flags field:
> < 2>
>
>   V4 fixes an indent with spaces instead of tabs
>
>  drivers/gpio/gpio-uclass.c | 30 +++---
>  include/asm-generic/gpio.h | 19 ++-
>  2 files changed, 37 insertions(+), 12 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 v2] dm: core: Add dev_get_addr_ptr() to return a pointer to the reg address

[Simon Glass]

On 20 April 2016 at 23:11, Stefan Roese  wrote:
> On some platforms (e.g. x86), the return value of dev_get_addr() can't
> be assigned to a pointer type variable directly. As there might be a
> difference between the size of fdt_addr_t and the pointer type. On
> x86 for example, "fdt_addr_t" is 64bit but "void *" only 32bit. So
> assigning the register base directly in dev_get_addr() results in this
> compilation warning:
>   warning: cast to pointer from integer of different size
>
> This patch introduces the new function dev_get_addr_ptr() that
> returns a pointer to the 'reg' address that can be used by drivers
> in this case.
>
> Signed-off-by: Stefan Roese 
> Reviewed-by: Simon Glass 
> ---
> v2:
> - Mention error condition in function prototype as suggested by Simon
>
>  drivers/core/device.c |  5 +
>  include/dm/device.h   | 10 ++
>  2 files changed, 15 insertions(+)

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 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.

I haven't seen the device tree, but presumably it is just a single node?

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

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

[Simon Glass]

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.

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

Re: [U-Boot] [PATCH] arm: dra7xx: Extend bootloader partition

[Tom Rini]

On Tue, Apr 26, 2016 at 09:16:56PM +0300, Sam Protsenko wrote:

> With FIT images support enabled, u-boot.img size increases up to 612 KiB.
> Extend "bootloader" partition size accordingly.
> 
> With extended "bootloader" partition there is no gap between "misc" and
> "efs" partitions anymore. Keep "efs" partition alignment intact anyway
> (start=1280K), so that Android partitions addresses  are compatible with
> older versions of u-boot, while size of rest partitions can be adjusted.
> 
> Signed-off-by: Sam Protsenko 

That's... really huge.  Is there something else that can perhaps come
out to allow that to fit in?  Can you share the rest of the config?  I'm
not seeing anything close to that by default here.  And I bring this up
because...

> ---
>  include/configs/dra7xx_evm.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/configs/dra7xx_evm.h b/include/configs/dra7xx_evm.h
> index 79b6c09..92373ac 100644
> --- a/include/configs/dra7xx_evm.h
> +++ b/include/configs/dra7xx_evm.h
> @@ -56,7 +56,7 @@
>   "partitions_android=" \
>   "uuid_disk=${uuid_gpt_disk};" \
>   "name=xloader,start=128K,size=128K,uuid=${uuid_gpt_xloader};" \
> - "name=bootloader,size=384K,uuid=${uuid_gpt_bootloader};" \
> + "name=bootloader,size=768K,uuid=${uuid_gpt_bootloader};" \
>   "name=environment,size=128K,uuid=${uuid_gpt_environment};" \
>   "name=misc,size=128K,uuid=${uuid_gpt_misc};" \
>   "name=efs,start=1280K,size=16M,uuid=${uuid_gpt_efs};" \

Given the problem with compatibility with other systems, I think we need
to have xloader-a and xloader-b, or to make the names still be
compatible:
"uuid_disk=${uuid_gpt_disk};" \
"name=xloader-b,start=128K,size=128K,uuid=${uuid_gpt_xloader};" \
"name=xloader,start=128K,size=128K,uuid=${uuid_gpt_xloader};" \
"name=bootloader,size=512K,uuid=${uuid_gpt_bootloader};" \

So that the first xloader is written to what the ROM considers the 3rd
try location.  If dra7xx won't actually try from that (I can't easily
test right this moment) then we need another misc inbetween xloader @
128KiB in and u-boot @ 386KiB in so that the U-Boot location is
compatible with the non-Android option.

-- 
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] [ANN] v2016.05-rc3

[Tom Rini]

On Tue, Apr 26, 2016 at 12:05:58PM -0700, Vagrant Cascadian wrote:
> On 2016-04-25, Tom Rini wrote:
> > I know I did v2016.05-rc2 just last week, but that's because I was off
> > schedule.  We are two weeks out from scheduled release, so he's -rc3.
> > Please test this everywhere you can.
> 
> I'm having issues with v2016.05-rc3 booting beaglebone black from eMMC
> and microSD, reverting ef5ebe951bec72631cdbc7cef9079e6c684e5d0b
> "ti_armv7_common.h: Fix U-Boot location on eMMC" seems to fix the issue
> for me.
> 
> It appears this patch changed where the raw offsets for loading
> u-boot.img are, though the "old" offsets are already in widespread use,
> so would be unfortunate to have to change them everywhere else.

Indeed this is a problem.  I think for this release we might have to
revert the change and then moving forward extend SPL to allow this
location to come via the environment (which we do for example with
bootcount) so that other use-cases can change things as needed.  Sorry
for the confusion, I had thought the patch was doing something slightly
different than it is.

-- 
Tom


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